JP2018526699A - 複数の装置の制御 - Google Patents

Abstract

手術システムを制御するための方法、システム、及び装置に関する。一態様では、方法は、手術システムに関連する制御サブシステムにおいて、制御サブシステムに通信可能に結合され且つ制御サブシステムによって制御される第１の患者側サブシステムからハードウェア構成情報を取得するステップと；制御サブシステム及び第１の患者側サブシステムによって使用すべきソフトウェア・バージョンを決定するステップであって、ソフトウェア・バージョンを決定するステップは、複数のソフトウェア・バージョンの中からソフトウェア・バージョンを選択するステップを含み、複数のソフトウェア・バージョンの各ソフトウェア・バージョンは、特定の患者側サブシステムに関連付けられる、決定するステップと；第１の患者側サブシステムにソフトウェア・バージョンを使用するように指示するステップと；ソフトウェア・バージョンが制御サブシステムに現在ロードされているかどうかを判定するステップと；ソフトウェア・バージョンが制御サブシステムに現在ロードされていないと判定したことに応答して、ソフトウェア・バージョンを制御サブシステムにロードするステップと；手術システムを初期化するステップと；を含む。

Description

関連出願
この特許出願は、２０１５年７月７日に出願された、”CONTROL OF MULTIPLE DEVICES”という標題の米国仮特許出願第６２／１８９，５２３号について優先権及び出願日の利益を主張するものであり、この文献は、その全体が参照により本明細書に組み込まれる。

本明細書は、制御システムに関する。

最小侵襲性医療技術は、診断的処置又は外科的処置中に損傷を受ける無関係な組織の量を減らし、それによって患者の回復時間、不快感、及び有害な副作用を低減させることを目的としている。米国で毎年数百万回の手術が行われている。これらの外科手術の多くは、潜在的に最小侵襲的な方法で行うことができる。

手術で使用する最小侵襲性システムは、遠隔操作、ロボット操作、又は遠隔操作及びロボット操作の両方が可能である。遠隔操作とは、ある距離を置いてマシンを制御するように作動させることをいう。遠隔操作可能な手術システムでは、外科医は、器具を手で直接的に保持して動かすのではなく、コントローラを使用して体腔に挿入された手術用器具を制御する。

一般に、本明細書に記載される主題の１つの革新的な態様は、以下の動作を含む方法において具体化することができ、この方法は、手術システムに関連する制御サブシステムにおいて、制御サブシステムに通信可能に結合され且つ制御サブシステムによって制御される手術システムの第１の患者側サブシステムからハードウェア構成情報を取得するステップと；制御サブシステム及び第１の患者側サブシステムによって使用すべきソフトウェア・バージョンを決定するステップであって、ソフトウェア・バージョンを決定するステップは、複数のソフトウェア・バージョンの中からソフトウェア・バージョンを選択するステップを含み、複数のソフトウェア・バージョンの各ソフトウェア・バージョンは、特定の患者側サブシステムに関連付けられる、決定するステップと；第１の患者側サブシステムにソフトウェア・バージョンを使用するように指示するステップと；ソフトウェア・バージョンが制御サブシステムに現在ロードされているかどうかを判定するステップと；ソフトウェア・バージョンが制御サブシステムに現在ロードされていないと判定したことに応答して、ソフトウェア・バージョンを制御サブシステムにロードするステップと；制御サブシステム及び第１の患者側サブシステムにロードされたソフトウェア・バージョンを有効化するステップと；手術システムをそのソフトウェア・バージョンで初期化するステップと；を含む。

この態様の他の実施形態は、対応するコンピュータシステム、装置、及び１つ又は複数のコンピュータ記憶装置に記録されたコンピュータプログラムを含み、それぞれが、この方法の動作を実行するように構成される。特定の操作又は動作を行うように構成された１つ又は複数のコンピュータから構成されるシステムでは、システムが、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せでインストールされ、動作時にシステムに操作又は動作を実行させるようにすることを意味する。特定の操作又は動作を行うように構成される１つ又は複数のコンピュータプログラムでは、１つ又は複数のプログラムが、データ処理装置によって実行されると、この装置に操作又は動作を実行させる命令を含むことを意味する。

前述の実施形態及び他の実施形態は、それぞれ、必要に応じて、以下の特徴のうちの１つ又は複数を単独で又は組み合わせて含むことができる。特に、一実施形態は、以下の特徴の全てを組み合わせて含む。この方法は、ソフトウェア・バージョンを決定する前に、第１の患者側サブシステムのハードウェア構成を検証するステップを含む。ハードウェア構成を検証するステップには、ハードウェア構成が制御サブシステムと互換性があると判定するステップが含まれる。制御サブシステムは、手術システムの外科医コンソールの構成要素を含み、外科医コンソールは、手術システムのオペレータに制御機能を提供するように構成される。第１の患者側サブシステムは、１つ又は複数の対応する手術用器具を保持して位置付けするように構成される１つ又は複数のマニピュレータを含む。

ソフトウェア・バージョンを第１の患者側サブシステムにロードするステップは、複数のブートイメージのうちの特定のブートイメージを決定するステップであって、特定のブートイメージはソフトウェア・バージョンを含む、決定するステップと；現在のブートイメージから特定のブートイメージに第１の患者側サブシステムをリブートするステップと；を含む。現在のブートイメージから特定のブートイメージに第１の患者側サブシステムをリブートするステップは、特定のブートイメージのための第１のヘッダブロックを取得するステップと；取得した第１のヘッダブロックを特定のブートイメージに復元するステップと；現在のブートイメージのための第２のヘッダブロックのコピーを格納するステップと；復元及び格納するステップの後に、現在のブートイメージのための第２のヘッダブロックを無効化するステップと；を含む。現在のブートイメージから特定のブートイメージに第１の患者側サブシステムをリブートするステップは、特定のブートイメージを特定するパラメータを格納するステップと；ブートローダ（boot loader）によって、格納したパラメータを読み出すステップと；ブートローダによって、格納したパラメータに基づいて特定のブートイメージを選択するステップと；を含む。ソフトウェア・バージョンを第１の患者側サブシステムにロードするステップは、複数のモジュールのうちの１つ又は複数の特定のモジュールを決定するステップであって、特定のモジュールはソフトウェア・バージョンを含む、決定するステップと；特定のモジュールをロードするステップと；を含む。

ソフトウェア・バージョンを決定するステップは、制御サブシステムと第１の患者側サブシステムとの間の協働に基づいている。ソフトウェア・バージョンを有効化するステップは、制御サブシステム及び第１の患者側サブシステムがソフトウェア・バージョンをロードしたかどうかを決定するステップと；制御サブシステム又は第１の患者側サブシステムのうちの１つ又は複数が決定されたソフトウェア・バージョンをロードしていないと判定したことに応答して、エラーメッセージを生成し、手術システムでの使用のために少なくとも制御サブシステム又は第１の患者側サブシステムの初期化を防止するステップと；を含む。

この方法は、１つ又は複数のアクセサリ装置を手術システムに結合するステップを含み、１つ又は複数のアクセサリ装置は、第１の患者側サブシステムに特有の装置ではない。この方法は、第２の患者側サブシステムが制御サブシステムに通信可能に結合されていることを認識するステップと；第２の患者側サブシステムに関するハードウェア情報を取得するステップと；第２の患者側サブシステムのハードウェア情報を検証するステップと；第２の患者側サブシステムに決定されたソフトウェア・バージョンをロードするように指示するステップと；をさらに含む。この方法は、第２の患者側サブシステムが制御サブシステムに通信可能に結合されていることを認識するステップと；第２の患者側サブシステムに関するハードウェア情報を取得するステップと；第２の患者側サブシステムのハードウェア情報を検証するステップと；第２のソフトウェア・バージョンを制御サブシステムにロードするステップであって、第２のソフトウェア・バージョンは、第２の患者側サブシステムにロードされたソフトウェアに対応する、ロードするステップと；をさらに含む。ソフトウェア・バージョンは、制御サブシステムに現在ロードされているソフトウェア・バージョンに基づいて決定される。ソフトウェア・バージョンは、第１の患者側サブシステムに現在ロードされているソフトウェア・バージョンに基づいて決定される。

一般に、本明細書に記載される主題の１つの革新的な態様は、以下の動作を含む方法において具体化することができ、この方法は、手術システムの第１のサブシステムにおいて、特定のソフトウェア・バージョンを第１のサブシステムにロードする命令を受信するステップであって、特定のソフトウェア・バージョンは、複数のサブシステムのそれぞれのサブシステムに関連する複数のソフトウェア・バージョンのうちの１つであり、第１のサブシステムは複数の構成を含み、この複数の構成には、第１のサブシステムに現在構成されている第１の構成が含まれる、受信するステップと；特定のソフトウェア・バージョンが第２の構成に位置していることを判定するステップと；第２の構成に対応するデータを格納するステップと；サブシステムを第２の構成に構成するステップと；特定のソフトウェア・バージョンをロードするステップと；を含む。

この態様の他の実施形態は、対応するコンピュータシステム、装置、及び１つ又は複数のコンピュータ記憶装置に記録されたコンピュータプログラムを含み、それぞれが、この方法の動作を実行するように構成される。特定の操作又は動作を行うように構成された１つ又は複数のコンピュータから構成されるシステムでは、システムが、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せでインストールされ、動作時にシステムに操作又は動作を実行させるようにすることを意味する。特定の操作又は動作を行うように構成される１つ又は複数のコンピュータプログラムでは、１つ又は複数のプログラムが、データ処理装置によって実行されると、この装置に操作又は動作を実行させる命令を含むことを意味する。

前述の実施形態及び他の実施形態は、それぞれ、必要に応じて、以下の特徴のうちの１つ又は複数を単独で又は組み合わせて含むことができる。この方法は、特定のソフトウェア・バージョンをロードする命令を受信することに応答して、第２の構成をダウンロードするステップを含む。第１の構成は第１のブートイメージを含み、第２の構成は第２のブートイメージを含み、第２の構成に対応するデータを格納するステップは、第２のブートの第１のヘッダブロックを復元して第２のブートイメージを有効化するステップと；第１のブートイメージのための第２のヘッダブロックのコピーを格納するステップと；復元及び格納するステップの後に、第１のブートイメージのためのヘッダブロックを無効化するステップと；を含む。

サブシステムを構成する前の割込みに応答して、第１のブートイメージ及び第２のブートイメージから有効なブートイメージを決定するステップと；サブシステムを有効なブートイメージにリブートするステップと；有効なブートイメージが第２のブートイメージであるかどうかを判定するステップと；有効なブートイメージが第２のブートイメージでないとの判定に応答して、第１のヘッダブロックを第２のブートイメージに復元し、第１のブートイメージのためのヘッダブロックを無効化し、サブシステムを第２のブートイメージにリブートするステップと；を含む。

第１の構成は第１のブートイメージを含み、第２の構成は第２のブートイメージを含み、サブシステムを第２の構成にリブートするステップは、ブートローダによって、格納したデータを読み出すことによって、サブシステムを第２の構成にリブートするステップと；ブートローダによって、格納したデータに基づいて第２のブートイメージを選択するステップと；を含む。第１の構成は第１セットのモジュールを含み、第２の構成は第２セットのモジュールを含み、サブシステムを第２の構成に構成するステップは、特定のモジュールをロードするステップを含む。

一般に、本明細書に記載される主題の１つの革新的な態様は、複数のサブシステムを含むシステムで具体化することができ、複数のサブシステムは、制御サブシステムと、第１の患者側サブシステムと、第２の患者側サブシステムとを含み、第１の患者側サブシステムは、第１のソフトウェア構成に関連付けられ、第２の患者側サブシステムは、第１のソフトウェア構成とは異なる第２のソフトウェア構成に関連付けられ、制御サブシステムはシステムを構成し、システムを構成することは、制御サブシステムと第１の患者側サブシステムとの第１の組合せ、又は制御サブシステムと第２の患者側サブシステムとの第２の組合せが共に通信可能に結合されているかどうかを判定することを含み、この判定に応じて、第１又は第２の組合せによって使用すべき特定のソフトウェア構成を選択し、ソフトウェア構成を有効化した後にシステムを初期化することを含む。

前述の実施形態及び他の実施形態は、それぞれ、必要に応じて、以下の特徴のうちの１つ又は複数を単独で又は組み合わせて含むことができる。システムを構成することは、決定されたソフトウェア構成を制御サブシステムにロードすることを含む。第１の患者側サブシステムは第１のハードウェア構成を有し、制御サブシステムは、特定のソフトウェア構成を決定する前に、制御サブシステム及び第１の患者側サブシステムを含むシステムについて第１のハードウェア構成が有効であると判定する。第１の組合せでは、第１の患者側サブシステムは制御サブシステムに通信可能に結合され、システムを構成することは、制御サブシステムから第１の患者側サブシステムに命令を送信して、決定されたソフトウェア構成をロードさせることを含む。制御サブシステムは、手術システムの外科医コンソールの構成要素を含み、外科医コンソールは、手術システムのオペレータに制御機能を提供するように構成される。

一般に、本明細書に記載される主題の１つの革新的な態様は、以下の動作を含む方法で具体化することができ、その動作は、制御サブシステムに通信可能に結合するための第１の患者側サブシステムを選択するステップであって、第１の患者側サブシステムは複数の患者側サブシステムから選択され、各患者側サブシステムは別個のデフォルトのソフトウェア構成を有する、選択するステップと；制御サブシステム及び第１の患者側サブシステムを含む手術システムを構成するステップと；を含み、手術システムを構成するステップは、制御サブシステム及び第１の患者側サブシステムのそれぞれによって使用すべき特定のソフトウェア構成を決定するステップと；特定のソフトウェア構成が、第１の患者側サブシステムに現在ロードされている第１のソフトウェア構成とは異なると判定したことに応答して、第１の患者側サブシステムに特定のソフトウェア・バージョンを使用するように指示するステップと；特定のソフトウェア構成が制御サブシステムに現在ロードされている第２のソフトウェア構成とは異なると判定したことに応答して、特定のソフトウェア構成を制御サブシステムにロードするステップと；手術システムを特定のソフトウェア・バージョンで初期化するステップと；を含む。この態様の他の実施形態は、対応するコンピュータシステム、装置、及び１つ又は複数のコンピュータ記憶装置に記録されたコンピュータプログラムを含み、それぞれが、この方法の動作を実行するように構成される。特定の操作又は動作を行うように構成された１つ又は複数のコンピュータのシステムでは、システムが、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せでインストールされ、動作時にシステムに操作又は動作を実行させるようにすることを意味する。特定の操作又は動作を行うように構成される１つ又は複数のコンピュータプログラムでは、１つ又は複数のプログラムが、データ処理装置によって実行されると、装置に操作又は動作を実行させる命令を含むことを意味する。

一般に、本明細書に記載される主題の１つの革新的な態様は、以下の動作を含む方法で具体化することができ、その動作は、手術システムの第１の制御サブシステム及び第１の患者側サブシステムに手術機能を提供するステップと；手術システムが手術機能を提供している間に手術システムへの通信可能な結合のために、第２の制御サブシステム及び第２の患者側サブシステムから構成されるグループのうちの１つである新しい手術サブシステムを選択するステップと；手術システムが手術機能を提供している間に、手術システムによって使用される特定のソフトウェア構成が新しい手術サブシステムにロードされていないと判定するステップと、第１の制御サブシステム及び第１の患者側サブシステムとの手術機能を維持しながら、特定のソフトウェア構成を新しい手術サブシステムにロードするステップと、によって、手術機能を中断することなく新しい手術サブシステムを手術システムに追加するステップと；を含む。

この態様の他の実施形態は、対応するコンピュータシステム、装置、及び１つ又は複数のコンピュータ記憶装置に記録されたコンピュータプログラムを含み、それぞれが、この方法の動作を実行するように構成される。特定の操作又は動作を行うように構成された１つ又は複数のコンピュータのシステムでは、システムが、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組合せでインストールされ、動作時にシステムに操作又は動作を実行させるようにすることを意味する。特定の操作又は動作を行うように構成される１つ又は複数のコンピュータプログラムでは、１つ又は複数のプログラムが、データ処理装置によって実行されると、この装置に操作又は動作を実行させる命令を含むことを意味する。

前述の実施形態及び他の実施形態は、それぞれ、必要に応じて、以下の特徴のうちの１つ又は複数を単独で又は組み合わせて含むことができる。特定のソフトウェア構成を新しい手術サブシステムにロードするステップは、複数のブートイメージのうちの特定のブートイメージを決定するステップであって、特定のブートイメージは特定のソフトウェア構成を含む、決定するステップと；新しい手術サブシステムを現在のブートイメージから特定のブートイメージにリブートするステップと；を含む。新しい手術サブシステムを現在のブートイメージから特定のブートイメージにリブートするステップは、特定のブートイメージのための第１のヘッダブロックを取得するステップと；取得した第１のヘッダブロックを特定のブートイメージに復元するステップと；現在のブートイメージのための第２のヘッダブロックのコピーを格納するステップと；復元及び格納するステップの後に、現在のブートイメージのための第２のヘッダブロックを無効化するステップと；を含む。新しい手術サブシステムを現在のブートイメージから特定のブートイメージへリブートするステップは、特定のブートイメージを特定するパラメータを格納するステップと；ブートローダによって、格納したパラメータを読み出すステップと；ブートローダによって、格納したパラメータに基づいて特定のブートイメージを選択するステップと；を含む。特定のソフトウェア構成を新しい手術サブシステムにロードするステップは、複数のモジュールのうちの１つ又は複数の特定のモジュールを決定するステップであって、特定のモジュールは特定の構成を含む、決定するステップと；特定のモジュールをロードするステップと；を含む。手術システムによって使用される特定のソフトウェア構成が新しい手術サブシステムにロードされていないと判定するステップは、第１の制御サブシステムに現在ロードされている特定のソフトウェア構成に基づく。手術システムによって使用される特定のソフトウェア構成が新しい手術サブシステムにロードされていないと判定するステップは、第１の患者側サブシステムに現在ロードされている特定のソフトウェア構成に基づく。

本明細書に記載される主題の特定の実施形態は、以下の利点のうちの１つ又は複数を実現する、又は実現しないように実施され得る。複数のサブシステムを有する手術システムは、共通のソフトウェア・バージョンを使用するようにセットアップされ且つ構成され得る。その結果、異なるハードウェア及びソフトウェア構成を有するサブシステムを共通システムで使用して、プロバイダが複数の完全な別個の手術システムを取得する必要がないようにすることができる。手術システムが無効の構成で動作するのを防ぐために、ハードウェア及びソフトウェアの構成が検証される。

異なるハードウェア及びサブシステム及びソフトウェア構成を使用する能力は、製造業者にとって試験の利点を与える。現場に複数のハードウェアサブシステムがあり、それぞれに複数のソフトウェア構成がある場合に、製造業者の試験負担は非常に大きくなる可能性がある。従来のシステムでは、顧客がハードウェア及びソフトウェアを互換性を有した状態で使用できるようにするために、製造業者は可能な全ての組合せを試験しなければならない。この明細書に記載されるように複数のサブシステムを共に結合した後にシステムを再プログラム及び／又は再構成する能力によって、全ての可能な組合せを試験することなく、１つの特定のサブシステムを異なるシステム構成で使用することが可能になる。有効なサブシステムの各組合せには、特定の試験済みのソフトウェア・バージョンが関連付けられており、サブシステムは、そのソフトウェア・バージョンに即座に再構成される。

本明細書に記載される主題の１つ又は複数の実施形態の詳細は、以下の添付図面及び詳細な説明に記載される。主題の他の特徴、態様、及び利点は、詳細な説明、図面、及び特許請求の範囲から明らかになるであろう。

遠隔操作可能な手術を行うための例示的な環境の平面図である。 異なる手術システムに関連するサブシステムを結合する例示的なシステムの図である 手術システムにおいて共に使用される制御コンソール及び他のサブシステムを構成するための例示的プロセスのフロー図である。 予め構成された手術システムに新しいサブシステムを追加するための例示的なプロセスのフロー図である。 ソフトウェア・バージョンをロードするための例示的なプロセスのフロー図である。 サブシステムを特定のソフトウェア・バージョンに再構成するための例示的なプロセスのフロー図である。 サブシステムを特定のソフトウェア・バージョンに再構成するための例示的なプロセスのフロー図である。 サブシステムを特定のソフトウェア・バージョンに再構成するための例示的なプロセスのフロー図である。

様々な図面における同様の参照符号及び表示は同様の要素を示す。
最小侵襲性手術は、手術用器具を患者の身体のポートを通して挿入することによって行われる。いくつかの実施態様では、手術用器具は、外科医コンソールを使用する外科医によって少なくとも部分的に遠隔操作される。遠隔操作可能な手術システムでは、外科医には、例えば立体画像を使用して、手術部位の画像が提供される。外科医は、適切なビューア又はディスプレイ上で手術部位を見ながら、１つ又は複数の制御入力装置を移動させ、対応する遠隔操作可能な手術用器具の動きを制御することによって、患者に対して外科的処置を行う。

遠隔操作可能な手術用器具は、典型的には、例えば患者内の手術部位の組織を治療するために１つ又は複数のポートを通して挿入される。ポートは、手術用器具が患者の身体に入る位置を示す一般的な用語である。ポートは人工的に形成することも、自然の開口部とすることもできる。例えば、ポートは切開部によって形成されるか、又は自然の身体オリフィス、例えば口に対応することができる。

手術システムは、典型的には、２つ以上のサブシステムの構成要素を含む。サブシステムの構成要素は、手術用器具を保持して位置付けする１つ又は複数の患者側サブシステム、患者側サブシステムによって保持される手術用器具を外科医が制御するために使用する１つ又は複数の制御コンソールサブシステム、及び、手術野画像を取り込むために使用される１つ又は複数のカメラ用のカメラ制御機器、手術野照明機器、電気外科エネルギー生成器、手術システムのための中央型又は分散型データ処理装置等、手術システムに関連する機器を含む１つ又は複数の補助装置ユニットを含んでもよい。いくつかの実施態様では、手術コンソールの設定及び構成を管理するために制御コンソールも使用される。手術システムの一例は、カリフォルニア州サニーベールのIntuitive Surgical, Inc.によって市販されているda Vinci（登録商標）Xi手術システム（モデルＩＳ４０００）である。

図１は、遠隔操作可能な手術を行うための例示的な環境１００の平面図を示す。環境１００は、例えば手術室の環境とすることができる。環境１００は、手術台１０２と、第１の制御コンソール１０４と、第１の患者側サブシステム１０６と、第２の患者側サブシステム１０８と、この例ではオプションの第２の制御コンソール１１０とを含む。

第１及び第２の患者側サブシステム１０６及び１０８は、それぞれ、１つ又は複数の手術用器具又はカメラを支持する。例えば、第１の患者側サブシステム１０６は、それぞれが対応する手術用器具を保持する１つ又は複数のマニピュレータを含む患者側サブシステムである。各手術用器具のチップの動きは、例えば１つ又は複数の対応するコントローラへのユーザ入力に応答して、第１の制御コンソール１０４によって制御される。マニピュレータは、ロボット式、遠隔操作式、又はその両方であってもよい。

第２の患者側サブシステム１０８は、第１の患者側サブシステムと同様であり得る。例えば、第２の患者側サブシステム１０８は、患者内の手術野の視覚化を提供するためのカメラを含むことができる。第２の患者側サブシステム１０８は、体腔に挿入され、手術野の視覚化を提供することができる内視鏡を含むことができる。手術野のビューを制御コンソール１０４に提供することができる。いくつかの実施態様では、第２の患者側サブシステム１０８は、カメラと、対応する手術用器具を保持し位置付けするための１つ又は複数のマニピュレータとの両方を含むことができる。

第１の制御コンソール１０４は、手術台１０２上に位置する患者に対して行われる外科的処置の一部として、１つ又は複数の手術用装置を制御するために使用される外科医コンソールである。第１の制御コンソール１０４を使用して、１つ又は複数の手術用器具の動きを制御し、特定の外科的処置を行うことができる。第１の制御コンソール１０４は、対応する手術用器具を外科医が制御するために使用する１つ又は複数のコントローラを含むことができる。例えば、第１の制御コンソール１０４は、対応する手術用器具を操作するために動かすことができるハンドコントロールを含むことができる。いくつかの実施態様では、第１の制御コンソール１０４は、１つ又は複数のカメラによって提供される手術野の画像を提供するビューアも含む。第２の制御コンソール１１０は、典型的には、第１の制御コンソール１０４と同様に構成され、例えば、第１の制御コンソール１０４で外科医を訓練するために、又は第１の制御コンソール１０４からの制御入力に加えて制御入力を提供することによって複雑な処置を行うために、第２のオペレータによって患者側サブシステムのマニピュレータを制御するために使用することができる。

様々な遠隔操作可能な患者側サブシステムが存在し、それぞれが固有のハードウェア構成及び関連する制御要件を有する。例えば、１つの遠隔操作可能な患者側手術システムは、各手術用器具が固有の対応するポートを介して患者の身体に入るマルチポート手術システムであってもよい。マルチポートシステムの一例は、米国特許出願公開第２０１３／０３２５０３号明細書（２０１３年５月３１日出願）に開示される。第２の遠隔操作可能な患者側手術システムは、全ての手術用器具が単一ポートを介して患者の身体に入る単一ポート手術システムであってもよい。単一ポートシステムの一例は、米国特許出願公開第２０１１／０２８２３５６号明細書（２０１０年８月１２日出願）に開示される。患者側手術システムは、米国特許出願公開第２００４／０１８６３４５号明細書（２００３年１２月１５日出願）、米国特許出願公開第２００７／００１３３３６号明細書（２００５年５月１９日出願）、米国特許出願公開第２００７／０１７３９７５号明細書（２００７年１月１５日出願）、及び米国特許出願公開第２００９／０１６３９２８号明細書（２００７年１２月２１日出願）に開示されているような、様々な位置に取り付けられたアームを含むシングル又はマルチアームシステムを含むことができる。

同様に、それぞれが固有の構成を有する様々な遠隔操作可能な制御サブシステムが存在してもよく、各制御サブシステムは、（追加の補助機器と共に）固有の制御サブシステムと患者側サブシステムとの対が遠隔操作可能な手術システムを形成するような単一の患者側サブシステムを制御するように設計される。例えば、米国特許第６，１３２，３６８号（１９９７年１１月２１日出願）、米国特許第６，２４６，２００号（１９９９年８月３日出願）、米国特許第６，７１４，８３９号（１９９９年９月１７日出願）、米国特許第６，７９３，６５３号（２００１年１２月８日出願）
、及び米国特許第８，５２１，３３１号（２００９年１１月１３日出願）は、遠隔操作可能な制御サブシステムを開示する。

単一の遠隔操作可能な手術システムは、２つ以上の遠隔操作可能な制御サブシステムを含んでもよい。例えば、米国特許第６，７２８，５９９号（２００１年９月７日出願）及び米国特許第８，５２７，０９４号（２００５年１２月２７日出願）には、２つ以上の制御サブシステムが開示されており、各制御サブシステムは、対応する外科医によって別々に操作され、２つの制御サブシステムは共に、単一の遠隔操作可能な手術システムの制御に関連付けられる。２つ以上の制御サブシステムを使用することにより、一方の外科医が別の外科医を訓練することが容易になり、又は（外科医が単独で制御できる）患者側サブシステム内の遠隔操作可能な外科装置の数が複数の場合に、２人の外科医が共に作業するのを容易にする。

こうして、既知の手術システムでは、単一の患者側サブシステム（１つ又は複数の別個の構成要素を含むことができる）は、単一の患者側サブシステムと一意に関連する１つ又は複数の制御サブシステムによって制御される。しかしながら、医療提供者が２つ以上の患者側サブシステムを望み、各患者側サブシステムが固有のハードウェア・アーキテクチャと関連する制御ソフトウェア構成とを含む場合に、経済性等の様々な理由により、その提供者が２つの手術システムを取得できない可能性がある。

従って、一態様では、２つ以上の固有に構成された患者側サブシステムと共に使用することができる単一の制御サブシステムハードウェア構成を有することが望ましい。例えば、単一の制御サブシステム及び第１の患者側サブシステムが共に第１の遠隔操作可能な手術システムを形成し、単一の制御システム及び第２の患者側サブシステムが共に第２の遠隔操作可能な手術システムを形成する。

同様に、別の態様では、それぞれが同様又は同一のハードウェア構成を有する２つ以上の制御サブシステムを有することが望ましく、制御サブシステムは、２つ以上の固有に構成された患者側サブシステムと共に使用することができる。例えば、２つ以上の制御システム及び第１の患者側サブシステムが共に第１の遠隔操作可能な手術システムを形成し、２つ以上の制御システム及び第２の患者側サブシステムが共に第２の遠隔操作可能な手術システムを形成する。

さらに別の態様では、手術用器具を制御する患者側サブシステム以外の手術システムのサブシステムと共に使用することができる、単一の制御サブシステムのハードウェア構成又は一緒に機能する２つ以上の制御システムのハードウェア構成を有することが望ましい。例えば、単一の制御サブシステム及び第１の補助サブシステムが共に第１の遠隔操作可能な手術システムを形成し、単一の制御システム及び第２の補助システムが共に第２の遠隔操作可能な手術システムを形成する。同様に、２つ以上の制御サブシステム及び第１の補助サブシステムが共に第１の遠隔操作可能な手術システムを形成し、２つ以上の制御サブシステム及び第２の補助サブシステムが共に第２の遠隔操作可能な手術システムを形成する。

さらに別の態様では、システム又はサブシステムの現在のソフトウェア及び／又はハードウェア構成に拘わらず、２つ以上の固有の手術システムを形成する手術システムのサブシステム同士の間に同一のソフトウェア構成を決定及び実装する技術を有することが望ましい。

図２は、異なる手術システムに関連するサブシステムを結合する例示的なシステムの図２００である。特に、図２は、制御コンソール２０２と、第１の患者側サブシステム２０４と、第２の患者側サブシステム２０６とを示す。例示の目的で、第１の患者側サブシステム２０４及び第２の患者側サブシステム２０６は、それぞれ、異なるハードウェア及びソフトウェア構成に関連付けられ、例えば異なる手術システムのモデルに関連付けられた特定のソフトウェア・バージョンを含む。図３〜図６に関して以下に詳細に説明するように、実行中に（on the fly）再プログラミングする技術を使用し、複数のシステムは、外科医制御コンソール２０２と、第１の患者側サブシステム２０４又は第２の患者側サブシステム２０６のいずれかとを使用して構成及び操作することができる。

例えば、第１の手術システム２０８は、外科医制御コンソール２０２を第１の患者側サブシステム２０４と結合し、且つ特定のソフトウェア構成に従って動作するようにシステムを構成することによって形成することができる。第２の手術システム２１０は、外科医制御コンソール２０２を第２の患者側サブシステム２０６と結合し、且つ特定のソフトウェア構成に従って動作するようにシステムを構成することによって形成することができる。第２の手術システム２１０の特定のソフトウェア構成は、第１の手術システム２０８の特定のソフトウェア構成とは異なるものであってもよい。例えば、第１の手術システム２０８の特定のソフトウェア構成は、第１の患者側サブシステム２０４の特定のハードウェアに関連付けられた第１のソフトウェア・バージョンであってもよく、第２の手術システム２１０の特定のソフトウェア構成は、外科医制御コンソール２０２に関連付けられ、且つ第２の患者側サブシステム２０６にロードされる第２のソフトウェア・バージョンであってもよい。

各患者側サブシステムは、有線又は無線であってもよい１つ又は複数のデータリンクを使用する特定の手術システムを形成するために、外科医制御コンソールに結合され得る。これらの手術システムのそれぞれは、各患者側サブシステムの有効なハードウェア構成と、以下に説明するようにシステムの全てのサブシステムに使用するための共通のソフトウェア・バージョンの決定とを考慮可能である。いくつかの実施態様では、第１の患者側サブシステム２０４及び第２の患者側サブシステム２０６は、同じハードウェア構成であるが、異なるソフトウェア・バージョンを有する。いくつかの他の実施態様では、第１の患者側サブシステム２０４及び第２の患者側サブシステム２０６は、異なるハードウェア構成を有し、且つ異なるソフトウェア・バージョンを有する。さらに、各システムが形成されるときに有効な構成を決定することによって、全ての可能性のあるソフトウェア構成を試験する必要はない。図２には示されていないが、追加の患者側サブシステム又は追加の外科医制御コンソール又は追加の補助装置ユニットに基づいて、更なるシステムを形成することができる。

場合によっては、外科医制御コンソール２０２及び／又は患者側サブシステム２０４のセットアップ後に、別の外科医制御コンソール又は別の患者側サブシステムを接続することができる。例えば、別の外科医制御コンソール又は別の患者側サブシステムが必要であることが見出されたときに、外科医制御コンソール２０２及び／又は患者側サブシステム２０４を手術で使用することができる。例えば、第２の外科医が手術タスクを観察又は補助することを可能にするために、別の外科医制御コンソールが必要とされ得る。別の例では、既存の患者側サブシステム２０４又は２０６のいずれかによって提供されない手術用ツールを提供するために、別の患者側サブシステムが必要とされ得る。

このような状況では、新しく追加されたシステムのソフトウェアを更新する必要がある。以下により詳細に説明するように、システムの残りの部分は、新たに追加されたシステムが更新される間に、使用可能なままであり得る。

図３は、手術システムにおいて共に使用される制御コンソール及び他のサブシステムを構成するための例示的なプロセス３００のフロー図である。プロセス３００は、この例では、図１の第１の制御コンソール１０４等の制御コンソールによって実行することができる。しかしながら、手術システムのセットアップ及び構成を制御するように指定された特定のサブシステムによって、同様のプロセスを使用することができる。

ハードウェア構成情報は、１つ又は複数のサブシステムのそれぞれから取得される（ステップ３０２）。例えば、制御コンソールは、第１の手術システムのモデルに関連するハードウェア構成を有することができる。第２の異なるサブシステム、例えば患者側サブシステムは、第２の手術システムのモデルに関連するハードウェア構成を有することができる。あるいはまた、サブシステムは、同じハードウェア構成であるが、異なるソフトウェア構成を有してもよい。

いくつかの実施態様では、サブシステムが制御コンソールに結合され、且つ制御コンソールが起動されると、制御コンソールは、各サブシステムに、そのサブシステムのハードウェア構成の要求を送信する。いくつかの他の実施態様では、サブシステムが制御コンソールに結合されると、それぞれのサブシステムは、そのサブシステムのハードウェア構成を対応する制御コンソールに送信する。

１つ又は複数のサブシステムのそれぞれのハードウェア構成が有効であるという判定がなされる（ステップ３０４）。いくつかの実施態様では、この判定は、各サブシステムから受信したハードウェアの識別子を、制御コンソールと互換性のあるハードウェア構成のルックアップテーブルと比較することを含む。例えば、特定のハードウェア設計は、制御コンソールの特定の制御ハードウェアと互換性がない場合がある。別の例では、別の製造元のハードウェアが制御コンソールとペア設定する権限を与えられていない可能性がある。

特定のサブシステムのハードウェア構成が有効でないと判定された場合に、エラーが生成される。このエラーによって、サブシステムが制御コンソールにより制御されないようにすることができる。エラーを制御コンソールに報告することができる。エラーを個々のサブシステムに報告することもできる。

各サブシステムのハードウェア構成が有効であると判定したことに応答して、制御コンソールを含む全てのサブシステム上で実行されるソフトウェア・バージョンが決定される（ステップ３０６）。サブシステムによって実行される共通のソフトウェア・バージョンは、様々な方法で決定することができる。いくつかの実施態様では、各ハードウェア構成は、デフォルトのソフトウェア構成に関連付けられる。全てのサブシステムがデフォルトの同じソフトウェア構成に関連付けられる場合に、そのソフトウェア構成を維持できる。ソフトウェア・バージョンを決定することは、複数のソフトウェア・バージョンの中からソフトウェア・バージョンを選択することを含み、各ソフトウェア・バージョンは、特定のサブシステムに関連付けられる。

いくつかの実施態様では、特定のサブシステムのデフォルトのソフトウェア構成は、手術システム全体に使用すべきソフトウェア構成を決定する。例えば、患者カートとして動作し且つそれぞれの手術用器具を保持する１つ又は複数のマニピュレータを含むサブシステムのデフォルトのソフトウェア構成は、制御コンソール及び他のサブシステム（例えば視覚化カート）によって使用すべきソフトウェア構成を決定することができる。いくつかの実施態様では、制御コンソールのソフトウェア構成は、全てのサブシステムによって使用すべきソフトウェア構成を制御することができる。最後に、複数のサブシステムがシステムに含まれる場合に、個々のサブシステムのうちの最大数に関連するソフトウェア構成を、全てのサブシステムが使用すべきソフトウェア構成として指定することができる。

いくつかの実施態様では、各サブシステムは、例えば対応するハードウェア構成によってサポートされるソフトウェア・バージョンを示す追加の情報を制御コンソールに提供する。制御コンソールは、この追加情報を使用して、どのソフトウェア・バージョンをシステムに使用すべきかを決定することができる。

幾つかの代替実施態様では、特定のサブシステムがリーダーとして指定されない協調的技術が使用されるが、それらサブシステムは、互いに協議して、サブシステム同士の間のハードウェア及びソフトウェアの特定の組合せが有効な試験済み構成に指定されているかどうかを確認する。

ソフトウェア・バージョンが決定されると、実行すべきソフトウェア・バージョンを特定する命令が、制御コンソールによって各サブシステムに送信される（ステップ３０８）。いくつかの実施態様では、命令を受け取る各サブシステムは、そのソフトウェア・バージョンが現在のソフトウェア・バージョンであるかどうかを判定する。現在のバージョンが決定されたソフトウェア・バージョンでない場合に、サブシステムは、決定されたソフトウェア・バージョンをロードする。ソフトウェア・バージョンは、別個のディスクイメージに格納することができる。

決定されたソフトウェア・バージョンが制御コンソールに現在ロードされていない場合に、制御コンソールは、決定されたソフトウェア・バージョンをロードするべくリブート（reboot）するように構成することができる（ステップ３１０）。いくつかの実施態様では、制御コンソールは複数のディスクイメージを含む。各ディスクイメージには特定のソフトウェア・バージョンが含まれる。特定のソフトウェア・バージョンをロードすることについては、図５及び図６に関して以下で説明する。

各サブシステムにロードされたソフトウェア・バージョンが有効化される（ステップ３１２）。特に、有効化では、正しいソフトウェア・バージョンが各サブシステムにロードされているかを判定する。正しいソフトウェア・バージョンがロードされていない場合に、解決されるまでエラーを生成して、手術システムの動作を阻止することができる。いくつかの実施態様では、制御コンソールは各サブシステムを検証する。いくつかの実施態様では、各サブシステムは自己検証を実行し、結果を制御コンソールに報告する。検証後に、手術システムは、ロードされたソフトウェア・バージョンで初期化することができる。初期化された手術システムを使用して、例えば１つ又は複数の外科的処置を行うことができる。

図４は、構成済みの手術システムに新しいサブシステムを追加するための例示的なプロセス４００のフロー図である。プロセス４００は、この例では、図１の第１の制御コンソール１０４等の制御コンソールによって実行することができる。しかしながら、同様のプロセスを適切なサブシステムによって使用することができる。

新しいサブシステムは、手術システムに通信可能に結合される（例えば、手術システムの制御コンソールに通信可能に結合される）（ステップ４０２）。例えば、手術システムは、制御コンソールと、１つ又は複数の手術用器具を保持して位置付けするための１つ又は複数のマニピュレータを含む第１のサブシステムとを含む環境（例えば、環境１００）内で最初にセットアップされる。手術システムは、図３に関して上述したような特定のソフトウェア・バージョンのためにセットアップすることができる。ある時点で、追加のサブシステムを追加することができる。例えば、対応するマニピュレータを有する追加のサブシステムが、外科的処置の一部に必要とされ得る。

新しいサブシステムためのハードウェア構成が取得される（４０４）。いくつかの実施態様では、新しいサブシステムが制御コンソールに結合されると、制御コンソールは、サブシステムに、そのサブシステムのハードウェア構成の要求を送信する。いくつかの実施態様では、新しいサブシステムが制御コンソールに結合されると、サブシステムは、そのサブシステムのハードウェア構成を制御コンソールに自動的に報告する。

新しいサブシステムのハードウェア構成が有効であるという判定がなされる（ステップ４０６）。図３に関して上述したように、いくつかの実施態様では、判定は、新しいサブシステムのハードウェアに関連する識別子を、制御コンソールと互換性のあるハードウェア構成のルックアップテーブルと比較することを含む。

新しいサブシステムに対する有効なハードウェア構成を判定することに応答して、手術システムのソフトウェア・バージョンと一致するソフトウェア・バージョンが新しいサブシステムにロードされるように決定される（ステップ４０８）。手術システムが以前に構成されていたので、決定は、制御コンソールの現在のソフトウェア・バージョン及び／又は制御コンソールに結合され現在構成された１つ又は複数のサブシステムを決定することを含むことができる。

ソフトウェア・バージョンが決定されると、実行すべきソフトウェア・バージョンを特定する命令が、制御コンソールによって新しいサブシステムに送信される（ステップ４１０）。いくつかの実施態様では、新しいサブシステムは、ソフトウェア・バージョンが新しいサブシステムの現在のソフトウェア・バージョンであるかどうかを判定する。現在のバージョンが決定されたソフトウェア・バージョンでない場合に、新しいサブシステムは決定されたソフトウェア・バージョンをロードする。

制御コンソールは、新しいサブシステムのソフトウェア構成を有効化する（ステップ４１２）。特に、有効化では、正しいソフトウェア・バージョンが新しいサブシステムにロードされているかを判定する。いくつかの実施態様では、手術システムを使用する前に、全てのサブシステムについて検証が行われる。

新しいサブシステムが構成されている間に、制御コンソールが、サブシステムと通信できない、又はサブシステムを制御できないエラー状態になる可能性がある。しかしながら、新しいサブシステムがエラー状態にある間に、制御コンソール及び古いサブシステムは、動作可能であり、手術機能を提供し続けることができる。すなわち、新しいサブシステムがその構成プロセスを完了するのを待っている間に、制御コンソール及び第１のサブシステムを外科医が使用することができる。

この更新は手術前のセットアップで行うことができるが、手術の途中で新しいサブシステムを追加すべき場合には、この機能は特に重要となり得る。例えば、手術の途中で合併症が起こり、新しいサブシステムが必要であると判断されることがある。第２の視野角が必要とされ、こうして、第２のビューカートが必要とされ得る。別の例では、予期しない処置を行うべく追加の手術用器具が必要とされ、必要な器具を含む患者側カートを追加してもよい。これらの場合に、これらの技術の使用によって、既存の制御コンソール及び既存のサブシステムの手術機能を中断することなく、新しいカートの追加を可能にすることができる。

いくつかの実施態様では、ステップ４０８で新しいサブシステムに特定のソフトウェア・バージョンをロードするように指示するのではなく、制御コンソールは、例えば、新しいサブシステムのソフトウェア・バージョンと一致する決定されたソフトウェア・バージョンをロードする。決定されたソフトウェア・バージョンを制御コンソールにロードした後に、制御コンソールは、例えば１つ又は複数の外科的処置を行うために手術システムを初期化する前に、システム全体のソフトウェア構成を有効化することができる。

第２の制御コンソールが利用可能であり、且つ新しいサブシステムに応答して新しいソフトウェアをロードする必要がない場合に、第２の制御コンソールは、他の制御コンソールが構成されている間に、既存のサブシステムの制御を保持し、新しいサブシステムを制御することができる。

例えば、外科手術は、２人の外科医、第１の外科医及び第２の外科医で行われる。第１の外科医は、第１の制御コンソールを使用して第１の患者側カートを制御してもよく、第２の外科医は、第２の制御コンソールを使用して第２の患者側カートを制御してもよい。手術の過程で、第３のサブシステムを追加する必要があるかを判断することができる。第３のサブシステムが追加されると、第１の制御コンソールはその構成を使用することができるが、第２の制御コンソールはアップグレードする必要がある。

この場合に、第２の制御コンソールは、新しいソフトウェア・バージョンをロードして第３のサブシステムを制御することができる。第２の制御コンソールがこの更新のためのエラーモードにある間に、第１の制御コンソールは、第１のサブシステムの制御に留まり、第３のサブシステム及びオプションで第２のサブシステムを制御することができる。

図５は、ソフトウェア・バージョンをロードするための例示的なプロセス５００のフロー図である。このプロセスは、手術システムに対して実行すべきソフトウェア・バージョンに関する決定がなされた後に、例えば制御コンソールによって実行され得る。このプロセスは、制御コンソールから受け取った、手術システムに対して実行すべき特定のソフトウェア・バージョンを特定する命令に応答して、サブシステムによって実行することもできる。

サブシステムによって使用すべき、現在のソフトウェア・バージョンではない特定のソフトウェア・バージョンが特定される（ステップ５０２）。特定のソフトウェア・バージョンが特定されると、ソフトウェア・バージョンを実行するためにリブートが開始される（ステップ５０４）。リブートを開始することに応答して、複数のブートイメージ又はブートルーチンの中からソフトウェア・バージョンを含む特定のブートイメージ又はブートルーチンが決定される（ステップ５０６）。例えば、サブシステムは、それぞれがイメージにロードされた特定のソフトウェア・バージョンを有する複数のブートイメージを含むことができる。サブシステムは、特定のブートイメージをロードされたソフトウェア・バージョンにマップするデータ、例えばファイルも含むことができる。サブシステムは、マッピングデータを使用して、複数のブートイメージからどのブートイメージをロードすべきかを決定できる。別の例では、ブートルーチンは、全てのバージョンに共通しており、バージョン特有のモジュールをロードすることができる。決定されたソフトウェア・バージョンは、サブシステムによってロードされる（ステップ５０８）。イメージをロードすることは、図６に関してより詳細に説明する。

リブート後に、サブシステムは、ブートイメージからロードされたソフトウェア・バージョンを使用して、サブシステムの機能を実行する（ステップ５１０）。例えば、サブシステムが１つ又は複数のマニピュレータを有する患者カートである場合に、ソフトウェアは、制御コンソールからの制御入力に応答して、マニピュレータの動きを制御するために使用される。

図６Ａ〜図６Ｃは、サブシステムを特定のソフトウェア・バージョンに再構成するための例示的なプロセス６００、６２５、及び６５０のフロー図である。これらのプロセス６００、６２５、及び６５０は、例えば、制御コンソールによって、又は制御コンソールから受け取った命令に応答してサブシステムによって実行することができる。プロセス６００、６２５、及び６５０は全て、一般に、サブシステムの動作に必要な特定のソフトウェア・バージョンをロードするために、リブート後に制御コンソール又はサブシステムの後で使用することができる。２つの異なるタイプの構成について説明する。プロセス６００及び６２５によって使用される第１のタイプの構成は、異なるバージョンのソフトウェアにアクセスするために異なるブートイメージを提供する。プロセス６５０によって使用される第２のタイプの構成は、異なるバージョンのソフトウェアにアクセスするための異なるモジュールを提供する。

プロセス６００において、特定のソフトウェア・バージョンを使用する決定がなされる（ステップ６０２）。例えば、決定は、手術システムに使用すべき特定のソフトウェア・バージョンを決定する制御コンソールによって行われ、又はサブシステムで受け取られた命令に応答して、制御コンソールによって、特定のソフトウェア・バージョンを使用するように決定することができる。例えば、サブシステムは、ブートイメージＡ内に見出されるソフトウェア・バージョンＡを現在実行している可能性がある。この決定は、ブートイメージＢ内に見出されるソフトウェア・バージョンＢを使用することであってもよい。

プロセス６００において、特定のソフトウェア・バージョンの位置に関する決定が行われる。特に、そのソフトウェア・バージョンが現在使用されていない場合に、ソフトウェア・バージョンが現在のブートイメージとは異なるブートイメージ上にあると判定される（ステップ６０４）。制御コンソール又は他のサブシステムは、複数のブートイメージを含むことができる。各ブートイメージは、ブートイメージにロードされる特定のソフトウェア・バージョンに関連付けることができる。

特定のソフトウェア・バージョンを含む異なるブートイメージを決定することに応答して、ブートイメージのためのヘッダブロックが復元される（ステップ６０６）。特に、他の未使用の各ブートイメージは、サブシステム上の記憶位置に格納されたヘッダブロックのコピーを有することができる。それぞれのヘッダブロックは、必要に応じて取り出すことができる。こうして、この例に戻って、ブートイメージＢのヘッダブロックは、別個の記憶位置から取り出されたブートイメージＢからのヘッダブロックのコピーから復元される。ヘッダブロックを復元することにより、ブートイメージは、例えば、サブシステム上のブートローダプログラムによってブート可能となる。

現在のブートイメージのためのヘッダブロックのコピーが格納される（ステップ６０８）。例えば、ヘッダのコピーは、他の未使用のブートイメージのコピーされたヘッダブロックと共に格納され得る。特に、この例に従って、ブートイメージＡのヘッダブロックは、記憶位置にコピーされる。

現在のブートイメージのためのヘッダブロックは、例えば、ヘッダブロックをゼロ設定する（zeroing）ことによって無効化される（ステップ６１０）。ブートイメージＡのヘッダブロックが無効化された後に、ブートイメージＡは再起動（restart）に応答してもはやブート（booted）することができなくなる。しかしながら、ヘッダがブートイメージＢに復元されたので、再起動がブートイメージＢからブートし、ソフトウェア・バージョンＢをロードする。サブシステムは、異なるブートイメージにリブートされる（ステップ６１２）。

いくつかのシナリオでは、プロセス６００に関して説明した再構成プロセス中に割込みが発生する。これらのシナリオでは、システムは、プロセスの状態に応じてどのブートイメージをロードすべきかを決定する。現在のブートイメージをゼロ設定する前に、ヘッダブロックを異なるブートイメージに復元するシーケンスのため、割込みの場合に再起動時にロードできる有効なブートイメージが常に少なくとも１つ存在する。

例えば、ヘッダがブートイメージＢに復元される前に割込みが発生した場合に、ブートイメージＡのヘッダは有効であるが、ブートイメージＢは有効ではない。割込み後に再起動すると、サブシステムは、ブートイメージＡにブートすることを決定し、ブートイメージＢへのスイッチを再試行することができる。例えば、ブートイメージＢへのヘッダを復元することができ、ブートイメージＡのヘッダは、上述したように無効化することができる。

別の例では、ヘッダがブートイメージＢに復元され、且つブートイメージＡのヘッダブロックがゼロ設定された後に割込みが発生した場合に、ブートイメージＢのみが有効である。再起動すると、サブシステムはブートイメージＢにブートすることを決定し、対応するソフトウェア・バージョンをロードする。

別の例では、ヘッダがブートイメージＢに復元された後であって、ブートイメージＡのヘッダブロックがゼロ設定される前に割込みが発生した場合に、ブートイメージＡとブートイメージＢとの両方が有効である。サブシステムは、１つ又は複数の基準に従って、２つの有効なブートイメージからどのブートイメージをロードすべきかを決定する。例えば、サブシステムは、最後にロードされたブートイメージ、この例ではブートイメージＡをデフォルト設定することができる。ブートイメージＡをロードした後に、サブシステムは、ブートイメージＢへの変更が依然として必要であると判定し、有効なブートイメージをブートイメージＢに変更するプロセスに進むように決定することができる。どのブートイメージをロードすべきかを決定するために他の基準を使用することができる。例えば、サブシステムは、最も小さい番号の有効なブートイメージを使用するか、又は有効なブートイメージの中からランダムに選択できる。

プロセス６２５において、特定のソフトウェア・バージョンを使用することが決定された後に（ステップ６０２）、ソフトウェア・バージョンが現在のブートイメージとは異なるブートイメージ上に位置するという判定がなされる（ステップ６０４）。ブートイメージのためのヘッダがリブート後に使用されるブートイメージを制御するために使用されるプロセス６００とは異なり、プロセス６２５は、選択したソフトウェア・バージョンをロードするために、複数の利用可能なブートイメージから選択可能なブートローダを使用する。

ブートローダには、必要とされる特定のソフトウェア・バージョンに対応するブートイメージを特定するパラメータが与えられる（ステップ６２７）。例えば、制御コンソールは、これらのパラメータをブートローダによってアクセス可能な不揮発性コンピュータメモリに格納することができ、又はそのようなメモリに格納するためにパラメータをサブシステムに送ることができる。

選択したブートイメージを特定するパラメータが格納された状態で、再起動がブートローダ内でブートする（ステップ６２９）。ブートローダは、選択したブートイメージをロードすることを含む、ブート処理の命令の実行に進むことができる（ステップ６３１）。例えば、ブートローダは、コンピュータメモリの内容を読み出して、どのブートイメージをブートすべきかを特定するパラメータを取り出し、そのブートイメージにブートすることができる。

プロセス６５０において、特定のソフトウェア・バージョンを使用することが決定された後に（ステップ６０２）、異なるバージョン特有のモジュールが必要であるという決定がなされる。異なるブートイメージを使用して異なるソフトウェアにアクセスを得るプロセス６００及びプロセス６２５とは異なり、プロセス６５０は、必要なソフトウェア・バージョンに拘わらず同じオペレーティングシステムにブートする。次に、バージョン特有のモジュールがロードされる。

バージョン識別子が格納される（ステップ６５２）。例えば、制御コンソールは、リブート後にオペレーティングシステムがアクセス可能なコンピュータメモリに所望のバージョンを格納することができ、又はそのようなメモリに格納するためにバージョンをサブシステムに送ることができる。

バージョン識別子が格納された状態で、再起動がオペレーティングシステム内でブートする（ステップ６５４）。このリブートは、バージョン特有のモジュールをロードせずにオペレーティングシステムをロードするという効果がある。オペレーティングシステムは、メモリ、ネットワーク通信、診断機能からのデータの検索等のいくつかの機能を提供することができる。ただし、対応するサブシステムのバージョン特有のモジュールがロードされたり、制御が制限されたり、制御されたりすることはない。場合によっては、オペレーティングシステムを再構成する他の方法を使用してもよい。例えば、リブートする代わりに、ソフトウェアモジュールの一部又は全部をアンロードしてもよい。これにより、例えば、リブートによって中断される可能性がある、オペレーティングシステム又はオペレーティングシステム内の無関係なアプリケーションの継続的な動作が可能になる。

オペレーティングシステムは、モジュールロードスクリプトを実行することができる（ステップ６５６）。例えば、オペレーティングシステムは、スタートアップの一部として、又はスタートアッププロセスの完了に応答して、特定のディレクトリに格納された１つ又は複数のスクリプトを実行するように構成することができる。このスクリプトは、コンピュータメモリからバージョン識別子を読み出し、バージョン特有のモジュールをロードするための命令を含むことができる（ステップ６５８）。これらのバージョン特有のモジュールは、制御コンソール及びサブシステムに、プロセス６００及び６２５のブートイメージと同じ又は同様の機能を提供する。バージョン特有のモジュールは、オペレーティングシステムと互換性のあるアプリケーション、ライブラリ、サービス、又は他のソフトウェア・オブジェクトを含むことができる。

いくつかの実施態様では、必要に応じて、１つ又は複数のブートイメージ又はモジュールをネットワーク・ロケーションからダウンロードすることができる。例えば、特定のソフトウェア・バージョンを使用すべきであるが、サブシステムに現在格納されていないと判定したことに応答して、対応するブートイメージをサブシステムのメモリにダウンロードすることができる。ダウンロードしたブートイメージは、上記のように現在のブートイメージに切り替えることができる。

いくつかの実施態様では、手術システムは、ハードウェア構成が手術システムと共に使用するのに有効である限り、追加のアクセサリに接続することができる。例えば、第２の制御コンソールをシステムに接続することができる。第２の制御コンソールは、処置の間に又は例えば複雑な処置の間に、１つ又は複数の手術用器具を独立して操作するための訓練装置として使用することができる。システム・セットアップの全体の制御を含む第１の制御コンソールは、第２の制御コンソールのソフトウェア・バージョンを決定し、対応する命令を第２の制御コンソールに与えてソフトウェア・バージョンをロードすることができる。例えば、特定の手術システムに特有ではない追加のマニピュレータ等の、他のアクセサリを使用することができる。

本明細書に記載される主題の実施形態及び動作は、本明細書開示される構造物及びそれらの構造的均等物、又はそれらの１つ又は複数の組合せを含むデジタル電子回路、又はコンピュータソフトウェア、ファームウェア、又はハードウェアに実装することができる。本明細書に記載される主題の実施形態は、データ処理装置によって実行されるか、又はデータ処理装置の動作を制御するためのコンピュータ記憶媒体上に符号化された１つ又は複数のコンピュータプログラム、すなわちコンピュータプログラム命令の１つ又は複数のモジュールとして実装することができる。代替的に又は追加的に、プログラム命令は、人為的に生成された伝播信号、例えば、データ処理装置によって実行するために適切な受信機へ送信するために情報を符号化するために生成されたマシンによって生成された電気、光、電磁信号に符号化される。コンピュータ記憶媒体は、コンピュータ可読記憶装置、コンピュータ可読記憶基板、ランダム又はシリアル・アクセスメモリ・アレイ又は装置、又はそれらの１つ又は複数の組合せであり得るか、又はそれらに含まれ得る。さらに、コンピュータ記憶媒体は伝播信号ではないが、コンピュータ記憶媒体は、人為的に生成された伝播信号で符号化されたコンピュータプログラム命令のソース又は宛先であり得る。コンピュータ記憶媒体は、１つ又は複数の別個の物理的構成要素又は媒体（例えば、複数のＣＤ、ディスク、又は他の記憶装置）であってもよく、又はこれに含まれてもよい。

本明細書に記載される動作は、１つ又は複数のコンピュータ可読記憶装置に格納したデータ又は他のソースから受信したデータに対してデータ処理装置によって実行される動作として実施することができる。

「データ処理装置」という用語は、例えば、プログラム可能なプロセッサ、コンピュータ、システムオンチップ、又はこれらの複数のもの、又はこれらの組合せを含む、データを処理するためのあらゆる種類の装置、装置及びマシンを包含する。装置は、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）等の専用論理回路を含むことができる。装置は、ハードウェアに加えて、当のコンピュータプログラムの実行環境を生成するコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォーム実行時環境、仮想マシン、又はこれらのうちの１つ又は複数の組合せを構成するコードも含むことができる。装置及び実行環境は、ウェブサービス、分散コンピュータ及びグリッドコンピュータインフラストラクチャ等、様々な異なるコンピュータモデルインフラストラクチャを実現することができる。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェア・アプリケーション、スクリプト、又はコードとしても知られている）は、コンパイル型言語又はインタープリタ型言語、宣言型言語又は手続型言語を含む、任意の形式のプログラミング言語で記述することができ、独立型プログラムとして、又はコンピュータ環境での使用に適したモジュール、コンポーネント、サブルーチン、オブジェクト、又はその他のユニットとして含まれる任意の形式で配置することができる。コンピュータプログラムは、ファイルシステム内のファイルに対応することができるが、必ずしも対応する必要はない。プログラムは、他のプログラム又はデータ（例えば、マークアップ言語ドキュメントに格納された１つ又は複数のスクリプト）を当のプログラム専用の単一ファイルに、又は複数の協調ファイル（例えば、１つ又は複数のモジュール、サブプログラム、又はコードの一部を格納するファイル）に保持するファイルの一部に格納される。コンピュータプログラムは、１つのコンピュータ上で、又は１つのサイトに位置するか又は複数のサイトに亘って分散され、及び通信ネットワークによって相互接続された複数のコンピュータ上で実行されるように配置することができる。

本明細書に記載されるプロセス及び論理フローは、１つ又は複数のコンピュータプログラムを実行する１つ又は複数のプログラマブルプロセッサによって実行され、入力データを操作して出力を生成することによって動作を実行することができる。プロセス及び論理フローは、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）等の専用論理回路によっても実行することができ、装置を専用論理回路として実装することもできる。

コンピュータプログラムの実行に適したプロセッサは、一例として、汎用マイクロプロセッサと専用マイクロプロセッサとの両方、及び任意の種類のデジタルコンピュータの任意の１つ又は複数のプロセッサを含む。一般に、プロセッサは、読出し専用メモリ又はランダムアクセスメモリ又はその両方から命令及びデータを受け取る。コンピュータの必須要素は、命令に従って動作を実行するためのプロセッサと、命令及びデータを格納するための１つ又は複数のメモリ装置とである。一般に、コンピュータは、磁気ディスク、光磁気ディスク、又は光ディスク等のデータを格納するための１つ又は複数の大容量記憶装置を含むか、又はこの大容量記憶装置からデータを受信し、又はその大容量記憶装置にデータを転送するか、又はその両方を行うように動作可能に結合される。しかしながら、コンピュータは必ずしもそのような装置を有する必要はない。さらに、コンピュータは、別の装置、例えば例を挙げると、携帯電話、携帯情報端末（PDA）、モバイルオーディオ又はビデオプレーヤ、ゲームコンソール、全地球測位システム（GPS）受信機、又はポータブル記憶装置（例えば、ユニバーサル・シリアル・バス（USB）フラッシュ・ドライブ）に組み込むことができる。コンピュータプログラム命令及びデータを格納するのに適した装置は、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリ装置等の半導体メモリ装置を含む全ての形式の不揮発性メモリ、メディア、及びメモリ装置；例えば内部ハードディスク又はリムーバブルディスク等の磁気ディスク；光磁気ディスク；及びＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む。プロセッサ及びメモリは、専用論理回路によって補完することができ、又は専用論理回路に組み込むことができる。

ユーザとの対話を提供するために、本明細書に記載される主題の実施形態は、情報をユーザ及びキーボードに表示するためのＣＲＴ（陰極線管）又はＬＣＤ（液晶ディスプレイ）モニタ等のディスプレイ装置と、ユーザがコンピュータに入力を与えることができるマウス又はトラックボール等のポインティング装置とを有するコンピュータ上に実装することができる。他の種類の装置を使用して、同様にユーザとの対話を提供することもできる。例えば、ユーザに提供されるフィードバックは、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック等の任意の形態の感覚フィードバックとすることができ、ユーザからの入力は、音響、音声、又は触覚入力を含む任意の形態で受け取ることができる。さらに、コンピュータは、ユーザによって使用される装置との間でドキュメントを送受信することによりユーザと対話することができ、例えば、ウェブブラウザから受信した要求に応答して、ユーザのクライアント装置上のウェブブラウザにウェブページを送信することによりユーザと対話することができる。

本明細書に記載される主題の実施形態は、例えばデータサーバ等のバックエンド・コンポーネントを含むコンピュータシステム、又はアプリケーションサーバ等のミドルウェア・コンポーネントを含むコンピュータシステム、又はユーザが本明細書に記載される主題の実施態様と対話することができるグラフィカル・ユーザインタフェース又はウェブブラウザを有するクライアントコンピュータ等のフロントエンド・コンポーネントを含むコンピュータシステム、又は１つ又は複数のこのようなバックエンド、ミドルウェア、又はフロントエンド・コンポーネントを含むコンピュータシステムに実装することができる。システムのコンポーネントは、任意の形式又は媒体のデジタルデータ通信（例えば、通信ネットワーク）によって相互接続することができる。通信ネットワークの例には、ローカルエリアネットワーク（LAN）及びワイドエリアネットワーク（WAN）、インターネットワーク（例えば、インターネット）、及びピアツーピアネットワーク（例えば、アドホック・ピアツーピアネットワーク）が含まれる。

コンピュータシステムは、マスタ装置と、１つ又は複数のスレーブ装置とを含むことができる。マスタ装置及びスレーブ装置は、一般に、互いに遠隔にあり、典型的には、通信ネットワークを介して相互作用する。マスタとスレーブとの関係は、それぞれのコンピュータ上で動作し、互いにマスタ／スレーブ関係を有するコンピュータプログラムによって生じる。いくつかの実施形態では、（例えば、手術用器具を動かす目的で）マスタが制御コマンド等のデータをスレーブ装置に送信する。スレーブ装置で生成されたデータ（例えば、カメラ画像）は、マスタ装置に戻すことができる。

いくつかの実施形態では、マニピュレータのジョイントは、能動ジョイント及び受動ジョイントを含むことができる。能動ジョイントは、その動作が、手術システム内から供給される電力によって、例えば関節に関連するモータによって制御されるジョイントである。受動ジョイントは、システムの外部に設けられた動力のみによって動くジョイント、又はより簡単には非動力型ジョイントである。能動ジョイントは、必ずしも遠隔操作又はロボット制御の必要はない。能動ジョイントの動きは、１つ又は複数の関連するモータによって提供され得る。いくつかの実施態様では、モータはブラシレス直流モータである。いくつかの他の実施態様では、閉ループフィードバックシステムにおいて能動ジョイントを制御するためにサーボ機構が使用される。外科医が特定のマニピュレータのためにマスタコントローラに入力を提供するとき、外科医が手術用器具を特定の位置に操作できるように動きが計算される。

安全の理由から、手術システムに使用されるマニピュレータのジョイントは、一般に、マニピュレータの制御されない動きを防止するためのロック機構を含む。いくつかの実施態様では、ロックは、動力がブレーキから除かれるときに係合されるブレーキによって提供される。これらのタイプのブレーキの例には、電気機械式又は電磁式のロックが含まれる。いくつかの実施態様では、これらのブレーキを解除してマニピュレータの手動の、電力が供給されない動作を可能にすることができる。

本明細書は、多くの具体的な実施態様の詳細を含むが、これらは、本発明の範囲又は特許請求の範囲に記載される範囲を限定するものではなく、むしろ特定の発明の特定の実施形態に特有の特徴の説明として解釈すべきである。別個の実施形態の文脈において本明細書に記載される特定の特徴は、単一の実施形態において組み合わせて実施してもよい。逆に、単一の実施形態の文脈において記載される様々な特徴は、複数の実施形態で別々に又は任意の適切なサブコンビネーションで実施してもよい。さらに、特徴は、特定の組合せで動作するものとして上記で説明しており、当初はそのように主張されていても、ある場合には、その組合せから切り出すことができ、主張された組合せは、サブコンビネーション又はサブコンビネーションの変形形態を指してもよい。

同様に、動作が特定の順序で図面に示されているが、これは、このような動作が、望ましい動作を達成するために、示された特定の順序又は順番通りに実行される、又は図示された全ての動作が実行されることを必要とするものとして理解すべきではない。特定の状況では、マルチタスク処理及び並列処理が有利な場合がある。さらに、上述の実施形態における様々なシステム構成要素の分離は、全ての実施形態においてそのような分離を必要とするものとして理解すべきではなく、記載されたプログラム構成要素及びシステムは、一般に、単一のソフトウェア製品内に一体化され、複数のソフトウェア製品内にパケージ化することができる。

こうして、主題の特定の実施形態について説明した。他の実施形態は、以下の特許請求の範囲内にある。場合によっては、特許請求の範囲に列挙された動作は様々な順序で実行され、依然として望ましい結果を達成することができる。さらに、添付図面に示されるプロセスは、望ましい結果を達成するために、示された特定の順序又は連続的な順序を必ずしも必要としない。特定の実施態様では、マルチタスク処理及び並列処理が有利となり得る。

Claims (36)

1. 方法であって、当該方法は、
   手術システムに関連する制御サブシステムにおいて、該制御サブシステムに通信可能に結合され且つ前記制御サブシステムによって制御される前記手術システムの第１の患者側サブシステムからハードウェア構成情報を取得するステップと、
   前記制御サブシステム及び第１の患者側サブシステムによって使用すべきソフトウェア・バージョンを決定するステップであって、該ソフトウェア・バージョンを決定するステップは、複数のソフトウェア・バージョンの中から前記ソフトウェア・バージョンを選択するステップを含み、前記複数のソフトウェア・バージョンの各ソフトウェア・バージョンは、特定の患者側サブシステムに関連付けられる、決定するステップと、
   第１の患者側サブシステムに前記ソフトウェア・バージョンを使用するように指示するステップと、
   前記ソフトウェア・バージョンが前記制御サブシステムに現在ロードされているかどうかを判定するステップと、
   前記ソフトウェア・バージョンが前記制御サブシステムに現在ロードされていないと判定したことに応答して、前記ソフトウェア・バージョンを前記制御サブシステムにロードするステップと、
   前記制御サブシステム及び第１の患者側サブシステムにロードされた前記ソフトウェア・バージョンを有効化するステップと、
   前記手術システムを前記ソフトウェア・バージョンで初期化するステップと、を含む、
   方法。
2. 前記ソフトウェア・バージョンを決定する前に、第１の患者側サブシステムの前記ハードウェア構成を検証するステップを含む、請求項１に記載の方法。
3. 前記ハードウェア構成を検証するステップには、前記ハードウェア構成が前記制御サブシステムと互換性があると判定するステップが含まれる、請求項２に記載の方法。
4. 前記制御サブシステムは、前記手術システムの外科医コンソールの構成要素を含み、前記外科医コンソールは、前記手術システムのオペレータに制御機能を提供するように構成される、請求項１に記載の方法。
5. 第１の患者側サブシステムは、１つ又は複数の対応する手術用器具を保持して位置付けするように構成される１つ又は複数のマニピュレータを含む、請求項１に記載の方法。
6. 前記ソフトウェア・バージョンを第１の患者側サブシステムにロードするステップは、
   複数のブートイメージのうちの特定のブートイメージを決定するステップであって、該特定のブートイメージは前記ソフトウェア・バージョンを含む、決定するステップと、
   現在のブートイメージから特定のブートイメージに第１の患者側サブシステムをリブートするステップと、を含む、
   請求項１乃至５のいずれか一項に記載の方法。
7. 前記現在のブートイメージから前記特定のブートイメージに第１の患者側サブシステムをリブートするステップは、
   前記特定のブートイメージのための第１のヘッダブロックを取得するステップと、
   該取得した第１のヘッダブロックを前記特定のブートイメージに復元するステップと、
   前記現在のブートイメージのための第２のヘッダブロックのコピーを格納するステップと、
   復元及び格納するステップの後で、前記現在のブートイメージのための第２のヘッダブロックを無効化するステップと、を含む、
   請求項６に記載の方法。
8. 前記現在のブートイメージから前記特定のブートイメージに第１の患者側サブシステムをリブートするステップは、
   前記特定のブートイメージを特定するパラメータを格納するステップと、
   ブートローダによって、前記格納したパラメータを読み出すステップと、
   前記ブートローダによって、前記格納したパラメータに基づいて前記特定のブートイメージを選択するステップと、を含む、
   請求項６に記載の方法。
9. 前記ソフトウェア・バージョンを第１の患者側サブシステムにロードするステップは、
   複数のモジュールのうちの１つ又は複数の特定のモジュールを決定するステップであって、該特定のモジュールは前記ソフトウェア・バージョンを含む、決定するステップと、
   前記特定のモジュールをロードするステップと、を含む、
   請求項１乃至５のいずれか一項に記載の方法。
10. 前記ソフトウェア・バージョンを決定するステップは、前記制御サブシステムと第１の患者側サブシステムとの間の協働に基づく、請求項１乃至５のいずれか一項に記載の方法。
11. 前記ソフトウェア・バージョンを有効化するステップは、
    前記制御サブシステム及び第１の患者側サブシステムが前記ソフトウェア・バージョンをロードしたかどうかを判定するステップと、
    前記制御サブシステム又は第１の患者側サブシステムのうちの１つ又は複数が前記決定されたソフトウェア・バージョンをロードしていないと判定することに応答して、エラーメッセージを生成し、前記手術システムでの使用のために少なくとも前記制御サブシステム又は第１の患者側サブシステムの初期化を防止するステップと、を含む、
    請求項１乃至５のいずれか一項に記載の方法。
12. １つ又は複数のアクセサリ装置を前記手術システムに結合するステップを含み、前記１つ又は複数のアクセサリ装置は、第１の患者側サブシステムに特有の装置ではない、請求項１乃至５のいずれか一項に記載の方法。
13. 第２の患者側サブシステムが前記制御サブシステムに通信可能に接続されていることを認識するステップと、
    第２の患者側サブシステムに関するハードウェア情報を取得するステップと、
    第２の患者側サブシステムの前記ハードウェア情報を検証するステップと、
    第２の患者側サブシステムに前記決定されたソフトウェア・バージョンをロードするように指示するステップと、をさらに含む、
    請求項１乃至５のいずれか一項に記載の方法。
14. 第２の患者側サブシステムが前記制御サブシステムに通信可能に結合されていることを認識するステップと、
    第２の患者側サブシステムに関するハードウェア情報を取得するステップと、
    第２の患者側サブシステムの前記ハードウェア情報を検証するステップと、
    第２のソフトウェア・バージョンを前記制御サブシステムにロードするステップであって、第２のソフトウェア・バージョンは、第２の患者側サブシステムにロードされたソフトウェアに対応する、ロードするステップと、をさらに含む、
    請求項１乃至５のいずれか一項に記載の方法。
15. 前記ソフトウェア・バージョンは、前記制御サブシステムに現在ロードされているソフトウェア・バージョンに基づいて決定される、請求項１乃至５のいずれか一項に記載の方法。
16. 前記ソフトウェア・バージョンは、第１の患者側サブシステムに現在ロードされているソフトウェア・バージョンに基づいて決定される、請求項１乃至５のいずれか一項に記載の方法。
17. 方法であって、当該方法は、
    手術システムの第１のサブシステムにおいて、特定のソフトウェア・バージョンを第１のサブシステムにロードする命令を受信するステップであって、前記特定のソフトウェア・バージョンは、複数のサブシステムのそれぞれのサブシステムに関連する複数のソフトウェア・バージョンの１つであり、第１のサブシステムは、複数の構成を含み、該複数の構成には、第１のサブシステムに現在構成されている第１の構成が含まれる、受信するステップと、
    前記特定のソフトウェア・バージョンが第２の構成に位置していることを判定するステップと、
    第２の構成に対応するデータを格納するステップと、
    前記サブシステムを第２の構成に構成するステップと、
    特定のソフトウェア・バージョンをロードするステップと、を含む、
    方法。
18. 前記特定のソフトウェア・バージョンをロードする命令を受信することに応答して、第２の構成をダウンロードするステップを含む、請求項１７に記載の方法。
19. 第１の構成は第１のブートイメージを含み、第２の構成は第２のブートイメージを含み、第２の構成に対応するデータを格納するステップは、
    第２のブートの第１のヘッダブロックを復元して第２のブートイメージを有効化するステップと、
    第１のブートイメージのための第２のヘッダブロックのコピーを格納するステップと、
    前記復元及び格納するステップの後に、第１のブートイメージのためのヘッダブロックを無効化するステップと、を含む、
    請求項１７又は１８に記載の方法。
20. 前記サブシステムを構成する前の割込みに応答して、
    第１のブートイメージ及び第２のブートイメージから有効なブートイメージを決定するステップと、
    前記サブシステムを前記有効なブートイメージにリブートするステップと、
    前記有効なブートイメージが第２のブートイメージであるかどうかを判定するステップと、
    前記有効なブートイメージが第２のブートイメージではないとの判定に応答して、第１のヘッダブロックを第２のブートイメージに復元し、第１のブートイメージの前記ヘッダブロックを無効化し、前記サブシステムを第２のブートイメージにリブートするステップと、を含む、
    請求項１９に記載の方法。
21. 第１の構成は第１のブートイメージを含み、第２の構成は第２のブートイメージを含み、前記サブシステムを第２の構成に構成するステップは、
    ブートローダによって、格納したデータを読み出すことにより、前記サブシステムを第２の構成にリブートするステップと、
    前記ブートローダによって、前記格納したデータに基づいて第２のブートイメージを選択するステップと、を含む、
    請求項１７又は１８に記載の方法。
22. 第１の構成は第１セットのモジュールを含み、第２の構成は第２セットのモジュールを含み、前記特定のソフトウェア・バージョンをロードするステップは、
    前記特定のモジュールをロードするステップを含む、
    請求項１７又は１８に記載の方法。
23. 複数のサブシステムを含むシステムであって、
    前記複数のサブシステムは、
    制御サブシステムと、
    第１の患者側サブシステムと、
    第２の患者側サブシステムと、を含み、
    第１の患者側サブシステムは、第１のソフトウェア構成に関連付けられ、第２の患者側サブシステムは、第１のソフトウェア構成とは異なる第２のソフトウェア構成に関連付けられ、
    前記制御サブシステムは当該システムを構成し、当該システムを構成することは、前記制御サブシステムと第１の患者側サブシステムとの第１の組合せ、又は前記制御サブシステムと第２の患者側サブシステムとの第２の組合せが共に通信可能に結合されているかどうかを判定することを含み、該判定に応答して、第１又は第２の組合せによって使用すべき特定のソフトウェア構成を選択し、前記ソフトウェア構成を有効化した後に当該システムを初期化することを含む、
    システム。
24. 当該システムを構成することは、決定されたソフトウェア構成を前記制御サブシステムにロードすることを含む、請求項２３に記載のシステム。
25. 第１の患者側サブシステムは第１のハードウェア構成を有し、前記制御サブシステムは、前記特定のソフトウェア構成を決定する前に、前記制御サブシステム及び第１の患者側サブシステムを含むシステムについて第１のハードウェア構成が有効であると判定する、請求項２３又は２４に記載のシステム。
26. 第１の組合せにおいて、第１の患者側サブシステムは、前記制御サブシステムに通信可能に結合され、当該システムを構成することは、前記制御サブシステムから第１の患者側サブシステムに命令を送信して、決定されたソフトウェア構成をロードさせることを含む、請求項２３乃至２５のいずれか一項に記載のシステム。
27. 前記制御サブシステムは、手術システムの外科医コンソールの構成要素を含み、前記外科医コンソールは、前記手術システムのオペレータに制御機能を提供するように構成される、請求項２３乃至２６のいずれか一項に記載のシステム。
28. 第１の患者側サブシステムは、前記制御サブシステムへのユーザ入力に応答して、１つ又は複数の対応する手術用器具を保持して位置付けするように構成される１つ又は複数のマニピュレータを含む、請求項２３乃至２７のいずれか一項に記載のシステム。
29. 方法であって、当該方法は、
    制御サブシステムに通信可能に結合するための第１の患者側サブシステムを選択するステップであって、第１の患者側サブシステムは、複数の患者側サブシステムから選択され、各患者側サブシステムは、別個のデフォルトのソフトウェア構成を有する、選択するステップと、
    前記制御サブシステム及び第１の患者側サブシステムを含む手術システムを構成するステップと、を含み、
    該手術システムを構成するステップは、
    前記制御サブシステム及び第１の患者側サブシステムのそれぞれによって使用すべき特定のソフトウェア構成を決定するステップと、
    前記特定のソフトウェア構成が第１の患者側サブシステムに現在ロードされている第１のソフトウェア構成とは異なると判定したことに応答して、第１の患者側サブシステムに前記特定のソフトウェア・バージョンを使用するように指示するステップと、
    前記特定のソフトウェア構成が前記制御サブシステムに現在ロードされている第２のソフトウェア構成と異なると判定したことに応答して、前記特定のソフトウェア構成を前記制御サブシステムにロードするステップと、
    前記手術システムを前記特定のソフトウェア・バージョンで初期化するステップと、を含む、
    方法。
30. 方法であって、当該方法は、
    手術システムの第１の制御サブシステム及び第１の患者側サブシステムに手術機能を提供するステップと、
    前記手術システムが前記手術機能を提供している間に前記手術システムへの通信可能な結合のために、第２の制御サブシステム及び第２の患者側サブシステムから構成されるグループのうちの１つである新しい手術サブシステムを選択するステップと、
    前記手術システムが前記手術機能を提供している間に、
    前記手術システムによって使用される特定のソフトウェア構成が前記新しい手術サブシステムにロードされていないことを判定するステップと、
    第１の制御サブシステム及び第１の患者側サブシステムとの手術機能を維持しながら、特定のソフトウェア構成を前記新しい手術サブシステムにロードするステップと、によって、
    前記手術機能を中断することなく前記新しい手術サブシステムを前記手術システムに追加するステップと、を含む、
    方法。
31. 前記特定のソフトウェア構成を前記新しい手術サブシステムにロードするステップは、
    複数のブートイメージのうちの特定のブートイメージを決定するステップであって、該特定のブートイメージは前記特定のソフトウェア構成を含む、決定するステップと、
    前記新しい手術サブシステムを現在のブートイメージから前記特定のブートイメージにリブートするステップと、を含む、
    請求項３０に記載の方法。
32. 前記新しい手術サブシステムを前記現在のブートイメージから前記特定のブートイメージにリブートするステップは、
    前記特定のブートイメージのための第１のヘッダブロックを取得するステップと、
    該取得した第１のヘッダブロックを前記特定のブートイメージに復元するステップと、
    前記現在のブートイメージのための第２のヘッダブロックのコピーを格納するステップと、
    復元及び格納するステップの後に、前記現在のブートイメージのための第２のヘッダブロックを無効化するステップと、を含む、
    請求項３１に記載の方法。
33. 前記新しい手術サブシステムを現在のブートイメージから前記特定のブートイメージにリブートするステップは、
    前記特定のブートイメージを特定するパラメータを格納するステップと、
    ブートローダによって、前記格納したパラメータを読み出すステップと、
    前記ブートローダによって、前記格納したパラメータに基づいて前記特定のブートイメージを選択するステップと、を含む、
    請求項３１に記載の方法。
34. 前記特定のソフトウェア構成を前記新しい手術サブシステムにロードするステップは、
    複数のモジュールのうちの１つ又は複数の特定のモジュールを決定するステップであって、前記特定のモジュールは前記特定の構成を含む、決定するステップと、
    該特定のモジュールをロードするステップと、を含む、
    請求項３０に記載の方法。
35. 前記手術システムによって使用される特定のソフトウェア構成が前記新しい手術サブシステムにロードされていないと判定するステップは、第１の制御サブシステムに現在ロードされている前記特定のソフトウェア構成に基づく、請求項３０乃至３４のいずれか一項に記載の方法。
36. 前記手術システムによって使用される特定のソフトウェア構成が前記新しい手術サブシステムにロードされていないと判定するステップは、第１の患者側サブシステムに現在ロードされている前記特定のソフトウェア構成に基づく、請求項３０乃至３５のいずれか一項に記載の方法。
    
    

Images