(57)【特許請求の範囲】
【請求項１】
画像サーバ上の持続的なデータ記憶領域に保存されるクライアント・ビューア画像データについての閲覧のために、コンピュータ実行させる方法であって、保存画像が複数の解像度での画像データ及び画像のベース解像度に対して特定の位置と関連させる注釈データを含んでおり、前記方法は、
前記画像サーバで前記クライアント・ビューアからの画像要求を受け付けるステップであって、該要求は、保存画像の特定領域および該要求画像のための、前記ベース解像度ではない特定の解像度を識別することを含み、
前記保存画像の前記ベース解像度で要求された領域が注釈データと関連させたと判断するステップと、
前記関連させた注釈データのための、前記保存画像の前記ベース解像度に関連して座標を決定するステップと、
前記座標に従って前記ベース解像度から要求された解像度に、前記関連させた注釈データをスケーリングするステップと、
前記要求された画像データおよび前記座標で要求された画像データのオーバレイであって一つ以上の注釈レイヤーを含むオーバレイとして示されるスケーリングされた関連させた注釈データを、前記クライアント・ビューアの表示において提供するステップと、
注釈コントローラとして、前記クライアント・ビューアの表示において移動可能なフローティング・ダイアログ・ボックスが設けられ、前記フローティング・ダイアログ・ボックスは、一つ以上の注釈レイヤーの中から注釈レイヤーを選択すること、および、選択された注釈レイヤー内で個々の注釈を追加し、編集し、削除する能力を提供するステップと、を備え、
前記注釈データを、前記クライアント・ビューアの表示において提供する前記ステップは、ユーザが前記要求された解像度で前記要求された画像データの上に自由形状の注釈領域を引き出し得る、ペン・ツール、形状ツール、矢印ツールのうちの少なくとも一つが提供されるとともに、前記ベース解像度に関連した座標を用いて前記注釈領域が保存されるステップをさらに含む、
方法。
【請求項２】
それぞれの注釈レイヤーは、ユーザによって選択される一つ以上の表示される特徴または領域を含む請求項１の方法。
【請求項３】
注釈レイヤーに含まれる各々の注釈が異なる色で表示される請求項１の方法。
【請求項４】
各々の注釈レイヤーは、選択的に有効または無効にされ得る請求項１の方法。
【請求項５】
前記注釈データは、一連の構造化言語として保存される請求項１の方法。
【請求項６】
前記注釈データは、構造化言語で書かれるデータの列として保存される請求項５の方法。
【請求項７】
前記注釈データは、拡張可能マークアップ言語（「ＸＭＬ」）ストリングとして保存される請求項６の方法。
【請求項８】
バーチャル顕微鏡スライド画像サーバ上の持続的なデータ記憶領域に保存されるバーチャル顕微鏡スライドのバーチャル顕微鏡スライド・クライアント・ビューアについての閲覧のために、コンピュータ実行させる方法であって、保存されるバーチャル顕微鏡スライド画像が複数の解像度での画像データを含んでおり、前記方法は、
前記バーチャル顕微鏡スライド画像サーバで前記バーチャル顕微鏡スライド・クライアント・ビューアからのバーチャル顕微鏡スライド要求を受け付けるステップであって、該要求は、バーチャルスライド全体の複数の画像を有する保存されたバーチャル顕微鏡スライドを識別し、前記バーチャルスライド全体の複数の画像のそれぞれは、ベース画像を含む、異なる解像度でのものであり、該要求はさらに前記要求されたバーチャル顕微鏡スライド画像データ用に特定の解像度を識別するものであり、
前記保存されたバーチャル顕微鏡スライドの複数の解像度の一つとは違う要求される解像度を判断するステップと、
前記保存されたバーチャル顕微鏡スライド画像からバーチャル顕微鏡スライド画像データを取得するステップであって、該取得された画像データは前記複数の保存された解像度のうちの前記要求された解像度に最も近い解像度であり、
前記バーチャル顕微鏡スライド・クライアント・ビューアに前記取得されたバーチャルスライド画像データを送信するステップと、
前記保存された解像度から要求された解像度に前記バーチャル顕微鏡スライド・クライアント・ビューアでバーチャルスライド画像データをスケーリングするステップと、
を含み、該スケーリングするステップにおいては、前記バーチャル顕微鏡スライド・クライアント・ビューアでユーザが前記要求された解像度でスケーリングされた前記バーチャルスライド画像データの上に自由形状の注釈領域を引き出し得る、前記バーチャル顕微鏡スライド・クライアント・ビューアにおけるペン・ツール、形状ツール、矢印ツールのうちの少なくとも一つが提供されるとともに、前記ベース解像度に関連した座標を用いて前記注釈領域が保存され、
前記バーチャル顕微鏡スライド・クライアント・ビューアが複数参加することにより行われるバーチャル顕微鏡カンファレンスにおいては、参加しているバーチャル顕微鏡スライド・クライアント・ビューアのうち、リーダ・クライアント・ビューアとなっているものが前記スケーリングを実行すると、参加している他のバーチャル顕微鏡スライド・クライアント・ビューアに該スケーリングの動作が反映され、非リーダ・クライアント・ビューアとなっているものが前記スケーリングを実行すると、参加している他のバーチャル顕微鏡スライド・クライアント・ビューアに該スケーリングの動作が反映されないようにする、方法。
【請求項９】
前記バーチャル顕微鏡スライド要求は、前記保存されたバーチャル顕微鏡スライド画像の特定領域を識別し、
前記バーチャル顕微鏡スライド画像データを取得するステップは、保存されたバーチャル顕微鏡スライド画像から一つ以上のデータブロックを取得するステップを更に含み、前記取得された一つ以上データブロックは、前記要求された領域に対応して、要求された領域より多くの画像データを含み、
前記クライアント・ビューアで一つ以上のデータブロックから前記要求された領域を構築するステップを更に含む、請求項８記載のコンピュータ実行させる方法。
【請求項１０】
前記バーチャルスライド画像は、バーチャルスライド画像の完全性を検証するために、ブロック・レベルで算出されるチェックサムを含む、請求項８記載のコンピュータ実行させる方法。
【請求項１１】
前記バーチャルスライドの複数の画像すべてが一連のブロックとして構成される、請求項８記載のコンピュータ実行させる方法。
【請求項１２】
前記ブロックが個々に圧縮される、請求項１１記載のコンピュータ実行させる方法。
【請求項１３】
前記要求されたバーチャル顕微鏡スライドに関連して前記バーチャル顕微鏡スライド画像サーバでスケーリング画像を保存するステップを更に含む、請求項８記載のコンピュータ実行させる方法。
【請求項１４】
前記スケーリング画像を保存するステップは、前記スケーリング画像をビューア・キャッシュに保存するステップを更に含む、請求項１３記載のコンピュータ実行させる方法。
【請求項１５】
前記スケーリング画像を保存するステップは、前記スケーリング画像をサーバ・キャッシュに保存するステップを更に含む、請求項１３記載のコンピュータ実行させる方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータの支援による大型の画像の閲覧に関し、さらに詳しくは、コンピュータの支援によるバーチャル顕微鏡スライドの閲覧に関する。
本出願は、本出願と同時に係属中である「全自動高速顕微鏡スライド・スキャナ（ＦＵＬＬＹ  ＡＵＴＯＭＡＴＩＣ  ＲＡＰＩＤ  ＭＩＣＲＯＳＣＯＰＥ  ＳＬＩＤＥ  ＳＣＡＮＮＥＲ）」という名称の米国特許出願第０９／５６３，４３７号の部分継続出願であり、かつ本出願と同時に係属中である「直線アレイ・ベースの顕微鏡スライド・スキャナにおけるデータ管理のためのシステムおよび方法（ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＤＡＴＡ  ＭＡＮＡＧＥＭＥＮＴ  ＩＮ  Ａ  ＬＩＮＥＡＲ‐ＡＲＲＡＹ‐ＢＡＳＥＤ  ＭＩＣＲＯＳＣＯＰＥ  ＳＬＩＤＥ  ＳＣＡＮＮＥＲ）」という名称の米国特許出願第１０／３７１，５８６号の部分継続出願であって、２００３年２月２８日付の米国特許仮出願第６０／４５１，０７９号および２００３年７月９日付の米国特許仮出願第６０／４８５，８７３号の優先権を主張している。これらの出願のそれぞれは、その全体がここで参照によって本明細書に組み込まれるものとする。
【背景技術】
【０００２】
大視野バーチャル顕微鏡観察において、乗り越えるべき最初の課題は、顕微鏡スライドのデジタル画像化（「スキャン」）に関連していた。従来からの画像タイル法が、バーチャル顕微鏡業界で広く普及している手法の１つである。顕微鏡スライドをスキャンするための画像タイル法では、面積固定の電荷結合素子（「ＣＣＤ」）カメラを使用し、顕微鏡スライドにおいて隣り合う領域について、数百または数千の別個独立の画像（「画像タイル」）を撮影する。これらの画像タイルがコンピュータに保存されるとともに、各画像タイルの名前および大型画像内におけるそれらの位置を特定するために、インデックスが使用される。従来からの画像タイル法が、米国特許第６，１０１，２６５号に説明されている。速度が遅くかつ扱いにくいものではあるが、従来からの画像タイル法は、バーチャルスライド生成のための顕微鏡スライドのスキャンにおいて、成功を収めた。
【０００３】
ひとたびバーチャルスライドがコンピュータ・システム内に収められると、数千の画像タイルという固有の性質ゆえ、スライドの各部位の閲覧は比較的単純である。ユーザは、バーチャルスライドの或る部位を閲覧したいと望む場合、その部位を選択するだけでよく、システムが対応する個々の画像タイルを認識し、それらのタイルを表示することができる。このように、バーチャル顕微鏡観察における閲覧の局面は、従来からの画像タイル法にとってそれほど困難ではなかった。
【０００４】
とくに、新規な直線アレイ・ベースの線スキャン法が、アペリオ・テクノロジーズ社（Ａｐｅｒｉｏ  Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）によって開発されている。この手法は、「全自動高速顕微鏡スライド・スキャナ（Ｆｕｌｌｙ  Ａｕｔｏｍａｔｉｃ  Ｒａｐｉｄ  Ｍｉｃｒｏｓｃｏｐｅ  Ｓｌｉｄｅ  Ｓｃａｎｎｅｒ）」という名称の米国特許第  号に記載されているように、直線アレイの検出器を専用の光学系と組み合わせて使用しており、スキャンスコープ（ＳｃａｎＳｃｏｐｅ（登録商標））という名称で現在市販されている。
【０００５】
さらに最近では、バーチャル顕微鏡観察産業に、バーチャルスライドを生成するためのきわめて優れたシステムが導入されている。アペリオ・テクノロジーズ社が、今や、米国特許第  号に記載の直線アレイ・ベースの線スキャン法を提供している。この革新的な線スキャン法によって、バーチャルスライドの生成のための時間が、数時間から数分へと短縮される。高速なデータ取得に加え、線スキャンは、一貫して優れた画像データを確保する幾つかの利点からも利益をもたらす。第１に、画像タイルの全体が必然的にただ１つの焦点面に制限される画像タイル・システムと対照的に、直線アレイの焦点を、或る１つの線から次の線へと調節することが可能である。第２に、線スキャン・システムにおける直線アレイ・センサは一次元であるため、スキャン軸に沿った光学収差が存在しない。画像タイル・システムにおいては、光学収差が、画像タイルの中央を中心として環状に対称である。第３に、非隣接ピクセルからの色値を（例えばベイヤー・マスク（Ｂａｙｅｒ  Ｍａｓｋ）を使用して）補間しなければならないために空間分解能を喪失してしまうカラーＣＣＤカメラと異なり、直線アレイ・センサは、完全な（１００％の）開口率（ｆｉｌｌ  ｆａｃｔｏｒ）を有しており、完全なピクセル分解能（色チャネルごとに８ビット）をもたらす。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
線スキャン法によってもたらされる他の大きな進歩は、従来からの画像タイル・システムが数千もの別個独立の画像タイルを生成するのとまったく対照的に、バーチャルスライドがコンピュータ・システム上のただ１つの画像ファイルに含まれるという点にある。１つのバーチャルスライドについてただ１つの画像ファイルを管理すればよいため、数千もの別個独立の画像タイルを対応するインデックスとともに管理することに比べ、オペレーティング・システムに必要とされるオーバヘッドがきわめて小さくなる。しかしながら、１つのバーチャルスライドについて画像ファイルをただ１つ生成するということは、きわめて効率的であって要する時間も少ない反面、それらバーチャルスライドの閲覧に関して、挑戦すべき新たな困難を生じさせる。画像タイルのサイズが１ＭＢ程度であるのと対照的に、線スキャナによって生成されるバーチャルスライド・ファイルは、４ギガバイト（「ＧＢ」）にもなる可能性がある。
【０００７】
したがって、バーチャルスライドを生成するための優れた線スキャン・システムを導入することにより、この新規な技法によって課される固有の必要性に適合するバーチャルスライド閲覧システムおよび閲覧方法に対するニーズが、この業界において生じている。
【課題を解決するための手段】
【０００８】
本発明は、大量の視覚画像データについて、スタンドアロン装置での閲覧あるいは構内または広域通信網を介しての閲覧を容易にするバーチャルスライド画像ファイル・フォーマットを提供する。バーチャルスライド画像データおよび対応する情報が、バーチャルスライド画像データおよび対応する情報への高性能なアクセスを提供するバーチャルスライド画像サーバ上のデータ記憶領域に保存される。バーチャルスライド画像データを効率的に表示および操作するように構成されたクライアント・ビューアが、特定の解像度で画像データを要求する。画像サーバが、要求された解像度に最も近い解像度で、データ記憶領域から対応する画像データを取得する。次いで、この画像データがクライアント・ビューアへと送信される。バーチャルスライド・クライアント・ビューアは、バーチャルスライド画像データを保存された解像度で受信し、次いでこの画像データを閲覧のため適切な解像度へと拡大縮小する。したがって、ベースライン解像度でスキャンされたバーチャルスライド画像を、より高い任意の解像度で画像の忠実度を損なうことなく閲覧することができる。さらに、ウェブ・ベースのシステムも提供される。
【０００９】
さらに、バーチャルスライド画像サーバは、リーダ・クライアント・ビューアおよび幾つかの参加者クライアント・ビューアによるバーチャルスライドの同時協働閲覧を容易にする。参加者クライアント・ビューアは、閲覧するバーチャルスライドの操作について制限されているが、協働セッションのリーダは、リーダの役割を参加者クライアント・ビューアに引き継ぐことができ、引き継ぎののち、新たなリーダが閲覧の制御を行なうことができ、先のリーダは参加者クライアントへと格下げされる。
【００１０】
さらに本発明は、バーチャルスライドの三次元閲覧を提供する。顕微鏡スライドの標本が、複数の垂直レベルでスキャンされ、それぞれの垂直レベルについて別個のバーチャルスライド画像が生成される。この複合バーチャルスライド画像の閲覧が要求され、要求されたレベルが２つのスキャン・レベルの間にあるとき、要求された閲覧レベルを画像の忠実度を損なうことなく生成するため、直上のレベルおよび直下のレベルが補間される。さらに、直上のレベルの画像の画像ピクセルを第１の方向にずらすとともに直下のレベルの画像の画像ピクセルを反対方向にずらして、要求されたレベルについてスキューされた画像を提供することによって、三次元閲覧を提供することができ、複合画像の三次元閲覧が可能である。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なシステムを示したネットワーク図である。
【図２Ａ】本発明の一実施の形態による典型的なバーチャルスライド・サーバを示したブロック図である。
【図２Ｂ】本発明の一実施の形態による典型的なバーチャルスライド・モジュールを示したブロック図である。
【図２Ｃ】本発明の一実施の形態に従ってバーチャルスライド画像のブロックの要求を取り扱うための典型的なプロセスを示したフロー図である。
【図２Ｄ】本発明の一実施の形態に従ってバーチャルスライド画像のサブ領域の要求を取り扱うための典型的なプロセスを示したフロー図である。
【図３】本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なウェブ・サーバを示したネットワーク図である。
【図４Ａ】本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｂ】本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｃ】本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｄ】本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｅ】本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｆ】本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。
【図４Ｇ】本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを、種々の解像度レベルとの関連について示したブロック図である。
【図５Ａ】本発明の一実施の形態による典型的なクライアント・ビューアを示したブロック図である。
【図５Ｂ】本発明の一実施の形態による典型的な表示域コントローラを示したブロック図である。
【図５Ｃ】本発明の一実施の形態による典型的なレンダリング・エンジンを示したブロック図である。
【図５Ｄ】本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。
【図５Ｅ】本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。
【図５Ｆ】本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。
【図５Ｇ】本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。
【図５Ｈ】本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。
【図６Ａ】本発明の一実施の形態による典型的な注釈モジュールを示したブロック図である。
【図６Ｂ】本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。
【図６Ｃ】本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。
【図７Ａ】本発明の一実施の形態による典型的なバーチャル顕微鏡カンファレンス閲  覧システムを示したネットワーク図である。
【図７Ｂ】本発明の一実施の形態によるバーチャル顕微鏡カンファレンスのための典型的なバーチャルスライド・サーバを示したブロック図である。
【図７Ｃ】本発明の一実施の形態による典型的なバーチャル顕微鏡カンファレンス・クライアント示したスクリーンショットである。
【図８Ａ】本発明の一実施の形態による典型的な三次元バーチャルスライドを示したブロック図である。
【図８Ｂ】本発明の一実施の形態による典型的なスキュー済み三次元バーチャルスライドを示したブロック図である。
【図８Ｃ】本発明の一実施の形態による典型的な三次元バーチャルスライド閲覧ウインドウを示したスクリーンショットである。
【図９Ａ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図９Ｂ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図９Ｃ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図９Ｄ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図９Ｅ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図９Ｆ】バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。
【図１０】本明細書に記載の種々の実施の形態に関連して使用できる典型的なコンピュータ・システムを示したブロック図である。
【発明を実施するための形態】
【００１２】
添付の図面を検討することによって、本発明の詳細を、その構成および動作の両者に関して或る程度学ぶことができるであろう。添付の図面において、同様の参照番号は同様な部分を指し示している。
【００１３】
本明細書に開示する或る幾つかの実施の形態は、ファイル・サイズが４ＧＢにもなるきわめて大きな画像（１００ＧＢにもなる圧縮前の生の画像データを含んでいる）であるバーチャル顕微鏡スライドを閲覧するためのシステムおよび方法を提供する。本発明は、このような大型の画像ファイルにアクセスし、対応する画像データをローカルまたはリモートの閲覧用ステーションに表示するための高速かつ効率的なシステムおよび方法を提供する。例えば、本明細書に開示の一方法によれば、クライアント・ビューアが、バーチャルスライド画像ファイルからの画像データを特定の解像度で要求できる。サーバ・システムが、要求された解像度に近い解像度にある画像データを含んでいる画像データの圧縮済みブロックを取得し、このデータ・ブロックをクライアントへと送信する。次いで、クライアントは、この画像データを拡大縮小し、要求された解像度で画像を提示する。
【００１４】
当業者であれば、この説明を読むことによって、他のさまざまな実施の形態および他のさまざまな用途において本発明をどのように実行するのかを、理解できるであろう。本発明の種々の実施の形態を本明細書にて説明するが、これらの実施の形態があくまで例であって、本発明を限定するものではないことを理解すべきである。すなわち、種々の代替となる実施の形態についてここで詳細に説明するが、それらを添付の特許請求の範囲に記載される本発明の技術的範囲を制限するものとして解釈すべきではない。
【００１５】
図１は、本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なシステム１０を示したネットワーク図である。図示の実施の形態において、システム１０は、クライアント・ビューア７０およびウェブ・ビューア８０にネットワーク６０を介して通信可能に接続したバーチャルスライド・サーバ３０を有している。複数のクライアント・ビューア７０が存在してもよく、複数のウェブ・ビューア８０が存在してもよい。さらに、システム１０がウェブ・サーバ４０を備えていてもよい。図示のとおり、ウェブ・サーバ４０は別個独立であってよく、あるいは複合サーバ２０としてバーチャルスライド・サーバと同じ場所に位置してもよい。複合サーバ５０は、データ記憶領域５０を備えて構成される。あるいは、バーチャルスライド・サーバ３０がウェブ・サーバ４０と別個独立である場合には、別個のサーバのそれぞれが、好ましくは自身のデータ記憶領域（図示されていない）を備えて構成される。そのような実施の形態においては、バーチャルスライド・サーバ３０が、バーチャルスライド画像データを保存する（他のデータとともに）ためのデータ記憶領域を有することができ、ウェブ・サーバ４０が、ウェブページ・データを保存する（他のデータとともに）ためのデータ記憶領域を有することができる。
【００１６】
クライアント・ビューア７０も、データ記憶領域７２を備えて構成される。このデータ記憶領域は、好ましくはバーチャルスライド画像、ならびにバーチャルスライドの閲覧を容易にするための他のデータまたは情報を、ローカルに保存するために使用することができる。ウェブ・ビューア８０は、キャッシュが好ましくはローカルのディスク式記憶装置ではなくコンピュータのメモリを使用して実行されるため、データ記憶領域を必要としない。他の実施の形態においては、データ記憶領域を備えてもよい。
【００１７】
ネットワーク６０は、種々ある任意のネットワーク形態および物理層を含むことができる。例えば、ネットワーク６０は、構内通信網（「ＬＡＮ」）、広域通信網（「ＷＡＮ」）、無線広域通信網（「ＷＷＡＮ」）、またはインターネットなどのネットワークの組み合わせであってよい。さらに、ネットワーク６０は、ＴＣＰ／ＩＰなどのさまざまな通信プロトコルを使用でき、ＨＴＴＰなどのアプリケーション・プロトコルを使用することができる。
【００１８】
図２Ａは、本発明の一実施の形態による典型的なバーチャルスライド・サーバ２０を示したブロック図である。図示の実施の形態においては、バーチャルスライド・サーバ２０が、接続モジュール１００、バーチャルスライド・モジュール１１０、注釈モジュール１６０、認証モジュール１３０、およびデータベース・モジュール１４０を有している。このサーバ２０は、データ記憶領域５０を備えて構成されている。代案として、データ記憶領域５０を、データ記憶領域１２０とデータ記憶領域１５０など、２つ以上の別個のデータ記憶領域へと物理的または論理的（あるいは両方）に分割することができる。データ記憶領域１２０が、バーチャルスライド画像データを含んでおり、データ記憶領域１５０が、注釈およびユーザ認証情報、ならびにおそらくはバーチャルスライド状況情報などの他の管理上のデータを含んでいる。
【００１９】
接続モジュール１００は、好ましくは、クライアント・ビューアまたはウェブ・ビューアからの要求を受信するように構成されている。要求によって、情報または画像データあるいは両者を求めることができる。さらに、要求によって、認証情報または注釈情報などの情報をもたらすことができる。別個に図示されているが、注釈モジュール１６０および認証モジュール１３０は、接続モジュール１００の一部であってよい。
【００２０】
バーチャルスライド画像に関する要求は、接続モジュール１００によって、バーチャルスライド・モジュール１１０へと導かれる。バーチャルスライド・モジュールは、データ記憶領域１２０から画像データを取得し、この画像データを必要に応じて処理し、要求元のビューア（クライアント・ビューアまたはウェブ・ビューア）へと応答を送り返す。さらに、バーチャルスライド・モジュールは、注釈モジュール１６０と通信し、バーチャルスライド画像に注釈の重ね合わせをもたらすことができる。注釈モジュール１６０は、種々のバーチャルスライド画像についての注釈を、別個のレイヤーにて保持しており、バーチャルスライド・モジュール１１０と関連して、注釈の生成および変更ならびに注釈レイヤーの表示を容易にする。
【００２１】
認証モジュール１３０は、要求を送信しているビューアを検証するように構成されている。認証モジュール１３０は、秘密に属するバーチャルスライド画像データおよび／または関連のデータベース情報が、権限のない要求元ビューアへと誤って提供されてしまうことがないよう、ユーザおよびパスワードまたは他の認証情報（例えば、ＩＰアドレス）についてのデータベースを保持できる。このデータベースは、データ記憶領域１５０内に保持できる。データ記憶領域１５０内にデータを保存するさまざまなモジュールは、データベース・モジュール１４０を介して当該データにアクセスできる。一実施の形態においては、モジュールが、従来からのファイル・システムにてデータ記憶領域１５０にデータを保存でき、したがって実際のデータベース構造のオーバヘッドを必要としない。しかしながら、データ記憶領域１５０と関連してデータベースを使用することによって、或る幾つかの利点および最適化を実現することができ、そのような場合、データベース・モジュール１４０によって、照会、取り出し、および保存などのデータベースとの通信を、容易にすることができる。
【００２２】
図２Ｂは、本発明の一実施の形態による典型的なバーチャルスライド・モジュール１１０を示したブロック図である。図示の実施の形態においては、バーチャルスライド・モジュール１１０は、要求ハンドラ１７０、入出力（「Ｉ／Ｏ」）モジュール１７２、１つ以上のデータ符号器／復号器（「コーデック」）１７４、および画像キャッシュ１７６を含んでいる。Ｉ／Ｏモジュール１７２が、データ記憶領域１２０にアクセスし、バーチャルスライド画像データおよび他の関連のバーチャルスライド情報の取り出しおよび保存を行なう。例えば、バーチャルスライド画像データの要求に応じ、Ｉ／Ｏモジュール１７２によってデータ記憶領域１２０からの取り出しが行なわれる。さらに、バーチャルスライド画像について直角回転または新規に拡大縮小（スケーリング）されたレベルを、Ｉ／Ｏモジュール１７２によって画像キャッシュ１７６に保存することができる。
【００２３】
要求ハンドラは、受信した要求の種類を特定するように構成されている。例えば、要求は、バーチャルスライド画像の特定のブロックを要求するものであってよく、あるいはバーチャルスライド画像の特定のサブ領域を要求するものであってよい。要求は、バーチャルスライドについての情報を要求するものであってもよい。バーチャルスライド画像ファイルのブロックとサブ領域との間の相違は、図４Ａ〜４Ｆに関して後で詳しく説明するとおり、バーチャルスライド画像ファイルの構造にもとづいている。しかしながら、基本的には、ブロックは、保存されたバーチャルスライド画像のファイル構造に固有の所定のデータ・ブロックである。一方、サブ領域は、バーチャルスライド画像の任意の領域であって、ただ１つのブロックまたは２つ以上のブロックの任意の組み合わせからなる部分集合であってよい。したがって、ブロックの読み出しがきわめて効率的である一方で、サブ領域の読み出しおよび構成は、プロセッサをより多く使用する。
【００２４】
コーデック１７４は、好ましくは、種々さまざまな圧縮技法を実行するように構成されている。好ましい実施の形態においては、バーチャルスライド画像ファイルについてＪＰＥＧ２０００圧縮が使用され、したがってコーデック１７４が、ＪＰＥＧ２０００の規格に従って圧縮および解凍を行なうように構成されている。さらに、コーデック１７４を、ＪＰＥＧおよびレンペル‐ジブ‐ウェルチ（Ｌｅｍｐｅｌ‐Ｚｉｖ  Ｗｅｌｃｈ）（「ＬＺＷ」）の圧縮の規格、ならびに他の可逆および不可逆の画像圧縮技法に従って圧縮および解凍を行なうように構成してもよい。バーチャルスライド・モジュール１１０は、複数の圧縮技法を同時にサポートすることができ、その場合、画像の属性にもとづいて選択されるコーデック１７４の複数のインスタンスが存在するであろう。
【００２５】
キャッシュ１７６は、ただ１つの物理的なキャッシュとして、あるいは複数の別個の物理的なキャッシュとして、実装することができる。一実施の形態においては、画像ブロックのためのキャッシュ、画像サブ領域のためのキャッシュ、およびバーチャルスライド情報のためのキャッシュなど、論理的に別個である複数のキャッシュが、バーチャルスライド・モジュール１１０によって使用される。
【００２６】
図２Ｃは、本発明の一実施の形態に従ってバーチャルスライド画像のブロックの要求を取り扱うための典型的なプロセスを示したフロー図である。最初に、ステップ１７８において、バーチャルスライド・モジュールが、クライアント・ビューアからの要求を受信する。要求は、要求ハンドラによって受信され、処理のためにＩ／Ｏモジュールへと渡される。ステップ１８０において、Ｉ／Ｏモジュールが、要求されたブロックをデータ記憶領域から取り出し、当該ブロックを要求ハンドラへと返す。あるいは、画像データがキャッシュにあるかどうかを調べるため、Ｉ／Ｏモジュールが、最初にキャッシュをチェックしてもよい。次に、要求ハンドラは、要求されたブロックをステップ１８２において要求元のビューアへと送り返し、さらにステップ１８４に示されているとおり、要求されたブロックをブロック・キャッシュに保存する。
【００２７】
さらに、要求ハンドラまたはＩ／Ｏモジュールが、要求されるであろう隣接または他のブロックの可能性を判断するため、予測機能を実行してもよい。この可能性が或る閾値を超えると判断される場合、その特定されたブロックを、要求を先取りすべくＩ／Ｏモジュールによってデータ記憶領域からあらかじめ読み出し、一時的にブロック・キャッシュに配置することができる。このような先読み機能によれば、閲覧システムの動作全体を大幅に改善することができ好都合である。この先読みの予測機能は、それまでの要求およびユーザのアクセスのパターンにもとづく経験則を実装することができる。
【００２８】
図２Ｄは、本発明の一実施の形態に従ってバーチャルスライド画像のサブ領域の要求を取り扱うための典型的なプロセスを示したフロー図である。ステップ１８８において、要求ハンドラが要求を受信し、その要求をデータの取り出しのためＩ／Ｏモジュールへと渡す。ステップ１９０に示すとおり、Ｉ／Ｏモジュールが、当該サブ領域の構築に必要とされる１つまたは複数のブロックを、キャッシュまたはデータ記憶領域から取り出す。１つまたは複数のブロックが入手されると、ステップ１９２でサブ領域が構築され、ステップ１９４でサブ領域のフォーマットが変換される。
【００２９】
画像データをウェブ・ビューアへと提供するときに、特定のウェブ・ビューア・クライアントが本来のフォーマット（例えばＪＰＥＧ２０００）に対応しない場合に、サブ領域のフォーマットの変換は必要になることが多い。圧縮形式の他に、画像データの拡大縮小、画像データの変形（回転または反転）、色の補正、コンボリューションマトリクスの適用、などのため、さらなる変換を実行してもよい。これらのステップは、すべて要求元クライアントの代理として要求ハンドラによって実行することができる。さらに、他の実施の形態においては、画像データの変換によってサブ領域を構築するステップを、本閲覧システムにおいて要求側に位置するクライアント・ビューアのプログラムによって好都合に実行することができる。したがって、サブ領域の構築および変換のステップは、より効率的であるブロック・レベルの画像を要求および処理することができないウェブ・ビューア・クライアントまたは他のビューア・クライアントから要求を受け取った場合にのみ、必要とすることができる。
【００３０】
ひとたびサブ領域が構築されて、画像が（必要であれば）変換されると、得られたサブ領域が、ステップ１９６に示すとおり、要求元のビューアへと送信される。サブ領域が送信されると、バーチャルスライド・モジュールは、好ましくはステップ１９８に示すとおり、当該サブ領域をサブ領域キャッシュに保存する。
【００３１】
図３は、本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なウェブ・サーバ４０を示したネットワーク図である。図示の実施の形態においては、ウェブ・ビューア・クライアント８０が、ネットワーク（図示されていない）を介してウェブ・サーバ４０に通信可能に接続されている。好都合なことに、ウェブ・ビューア・クライアントは、特別なソフトウェア・モジュールを必要とせず標準的なウェブ・ブラウザ２１０を備えているだけである。
【００３２】
ウェブ・サーバ４０は、コモン・ゲートウェイ・インターフェイス（「ＣＧＩ」）２２０、ウェブ・ビューア２３０、およびＨＴＭＬビルダを有している。一実施の形態においては、ＨＴＭＬビルダを、ウェブ・ビューア２３０の一部として実装できる。さらに、図示の実施の形態には、バーチャルスライドに関する画像データおよび他の情報を保持および提供するバーチャルスライド・サーバ３０が示されている。
【００３３】
図示のとおり、ウェブ・ビューア８０がウェブ・サーバ４０へとＨＴＴＰ要求を送信して、バーチャルスライドを要求する。ＣＧＩ２２０が、この要求を受信してウェブ・ビューア２３０に渡し、ウェブ・ビューア２３０が、対応するバーチャルスライド要求を、ＨＴＴＰ要求によってバーチャルスライド・サーバ３０へと送信する。バーチャルスライド・サーバ３０は、画像情報を含んでなるＨＴＴＰ応答によって、この要求に応答する。ウェブ・サーバ４０へのＨＴＴＰ応答は、実際の画像データは含んでおらず、画像属性などの他の情報を含んでいる。バーチャルスライド・サーバ３０からＨＴＴＰ応答を受信したのち、ウェブ・サーバ４０において、ウェブ・ビューア２３０がＨＴＴＰビルダ２４０と協働し、ウェブ・ビューア８０のためのＨＴＴＰ応答を構築する。好ましくは、ＨＴＴＰ応答が、バーチャルスライド画像を表示するためのＨＴＭＬの枠組みをウェブ・ブラウザ２１０に提供するとともに、本来の画像データ（例えば、ＪＰＥＧ）についての画像タグ参照を含んでいる。ウェブ・ブラウザ２１０は、ウェブ・サーバ４０からのＨＴＴＰ応答を処理する際に画像タグ参照を発見し、これに従ってウェブ・ビューア８０に、画像データを求めるＨＴＴＰ要求をバーチャルスライド・サーバ３０へと送信させる。ウェブ・ビューア８０からの要求に応じ、バーチャルスライド・サーバが、画像データをウェブ・ブラウザ２１０によって表示できるフォーマットで送信する。
【００３４】
図４Ａは、本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマット２５０を示したブロック図である。バーチャルスライド画像ファイルが複数の画像を含んでおり、これら複数の画像はそれぞれ、バーチャルスライドの全体についての異なる解像度での画像である。一実施の形態においては、バーチャルスライドを閲覧する際により効率的な拡大縮小の入手を提供するため、バーチャルスライドが生成されるときに、中間レベルの画像もいくつか生成され、バーチャルスライド画像ファイルに保存される。
【００３５】
図示の実施の形態においては、ファイル・フォーマットが、ヘッダ２６０およびチェックサム３１０を含んでいる。チェックサム３１０は、任意であってよい。一実施の形態においては、バーチャルスライド画像が大きく、全画像についてチェックサムを計算することが現実的でないため、チェックサムをブロック・レベルに使用することができる。さらに、ブロック・レベルにおける他の検証または保全も、使用することができる。ヘッダは、好ましくはファイル情報およびベースライン画像２７０への参照を含んでおり、ベースライン画像２７０は、バーチャルスライド画像を線スキャナ装置から受け取ったままの本来の解像度で含んでいる。一実施の形態においては、ファイルにおいてベースライン画像２７０の次に、バーチャルスライド全体の低解像度のサムネイル画像を含んでいるサムネイル画像２８０が続いている。同様に、ファイルにおいてサムネイル画像２８０の次には、ベースレベルから作られた中間画像のすべてについて、中間画像レベル２９０が続き、さらに中間レベル２９１が続き、以下同様である。
【００３６】
ベースライン画像２７０および中間レベル画像２９０、２９１は、ランダム・アクセスを容易にするため、ブロックの連続として組織されている。個々のブロックを圧縮してもよい。好ましくは、ブロックは、ＪＰＥＧ２０００の規格に従って圧縮される。代案として、あるいはこれに加えて、個々のブロックをＪＰＥＧ規格に従って圧縮してもよく、あるいはＬＺＷ（可逆）符号化によって圧縮してもよい。さらに、個々のブロックが、画像の完全性を検証すべく使用されるチェックサムを含んでもよく、さらに／あるいは元の圧縮なしの画像データからの平均二乗平均平方根（「ＲＭＳ」）または平均三乗平均立方根（「ＲＭＣ」）距離など、圧縮後の画像の忠実度についての指標を含んでもよい。
【００３７】
一実施の形態においては、バーチャルスライド画像ファイル・フォーマットが、ここでの参照によってその全体が本明細書に組み込まれる１９９２年６月３日付の最終のＴＩＦＦ規格、リビジョン６．０に記載のファイル・フォーマットに、事実上合致している。
【００３８】
図４Ｂ〜Ｆは、ファイル中に種々の解像度レベルを含んでなる本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。図から理解されるように、ベースライン画像の種々のレベルを解像度が小さくなっていく順序で垂直に積層させたとき、ピラミッドが形成される。図４Ｂに示すとおり、ピラミッドの底部はベースライン画像２７０である。次のレベルは、図４Ｃに示すとおり中間画像２９０である。中間画像２９０は、バーチャルスライド中の他のすべての解像度のなかで、最もベースライン解像度に近いバーチャルスライド画像である。図４Ｄは、ピラミッドにおいてベースライン画像および第１の中間レベル画像の上方に位置する第２の中間レベル画像２９１を示している。任意の数の中間画像を含むことができる。例えば、一実施の形態においては、隣り合う中間画像が、それぞれ先の画像の１／４の解像度を有している。最後に、図４Ｅにおいて、サムネイル画像２８０が、バーチャルスライド画像ファイルを構成する画像のピラミッドの最上部に位置している。これら種々のレベルの解像度およびそれらに対応するバーチャルスライド・ファイル中の各画像によって、バーチャルスライドの閲覧時に、解像度レベルをまたがるより効率的な拡大縮小を、好都合に提供できる。
【００３９】
例えば、図４Ｆは、第２の中間レベル画像２９１とサムネイル画像２８０との間にある現在閲覧中のレベル３２０を示している。一実施の形態においては、ビューアが現在の閲覧レベル３２０の解像度でのバーチャルスライドの閲覧を選択したとき、バーチャルスライド・サーバは、クライアント・ビューアへと第２の中間レベル画像２９１からの１つ以上のブロックを提供でき、クライアント・ビューアが、それらを現在の閲覧レベルの解像度へと縮小（スケールダウン）することができる。他の実施の形態においては、ビューアが現在の閲覧レベル３２０の解像度でバーチャルスライドを閲覧することを選択したとき、バーチャルスライド・サーバが、より低い解像度レベルの画像をクライアント・ビューアへと提供でき、クライアント・ビューアが、それを現在の閲覧レベルの解像度へと拡大（スケールアップ）することができる。好ましくは、画像の忠実度を保つため、より高解像度の画像が縮小される。または、バーチャルスライド・サーバは相互レベル補間を実行できる。一実施の形態においては、バーチャルスライドの種々の解像度レベルにまたがっての高速な拡大縮小をさらに改善するため、補間によって中間レベルを得たのち、当該新しいレベルを、ビューアまたはサーバのキャッシュに加えることができる。或る状況においては、最初のレンダリングの後に現在の閲覧をディスクに保存するよりもむしろ、現在の閲覧レベルを後続の第２の時に再度解釈し、後の第２の閲覧のために保存された画像を後に取り出すことがより効率的であり得る。
【００４０】
図４Ｇは、本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを、種々の解像度レベルとの関連について示したブロック図である。
【００４１】
図５Ａは、本発明の一実施の形態による典型的なクライアント・ビューア７０を示したブロック図である。クライアント・ビューア７０は、ネットワークを介してバーチャルスライド・サーバと通信可能に接続され、あるいは場合によってはコンピュータ・ケーブルなどで直接接続されるリモート装置上で動作するアプリケーションである。図示の実施の形態においては、クライアント・ビューア７０は、グラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）ハンドラ３５０、バーチャル顕微鏡カンファレンス（ｖｉｒｔｕａｌ  ｍｉｃｒｏｓｃｏｐｙ  ｃｏｎｆｅｒｅｎｃｉｎｇ）（「ＶＭＣ」）モジュール３６０、および表示域コントローラ（ｖｉｅｗｐｏｒｔ  ｃｏｎｔｒｏｌ）３７０を有している。
【００４２】
ＧＵＩハンドラ３５０は、ウインドウおよびそれらウインドウの中身の閲覧装置上への表示を管理する。さらに、ＧＵＩハンドラ３５０は、クライアント・ビューア７０へのすべてのキーボードおよびマウス入力を管理する。ＶＭＣモジュール３６０は、図７Ａ〜７Ｂに関して後に詳述するバーチャル顕微鏡カンファレンス・セッションのために使用される。表示域コントローラ３７０は、ローカルのバーチャルスライド・ファイルへの直接アクセスを介し、あるいはすでに述べたとおりバーチャルスライド・サーバへのリモート・アクセスを介するバーチャルスライドについてのすべてのやり取りを管理する。
【００４３】
図５Ｂは、本発明の一実施の形態による典型的な表示域コントローラ３７０を示したブロック図である。図示の実施の形態では、表示域コントローラが、注釈コントローラ４００、レンダリング・エンジン４２０、先読み器４３０、Ｉ／Ｏモジュール４４０、通信モジュール４５０、１つ以上のコーデック４６０、およびキャッシュ４７０を有している。
【００４４】
注釈コントローラ４００は、新規注釈の追加、注釈の削除、種々の注釈レイヤーの提示などの注釈要求を処理する。レンダリング・エンジン４２０は、バーチャルスライド画像データの表示および操作を管理する。レンダリング・エンジン４２０は、バーチャルスライド画像についてバーチャルスライド内の任意の位置、任意の寸法、および任意の解像度で可能な限り良好な閲覧を提供するため、キャッシュされた画像データを使用するように構成されている。より多くのデータがバーチャルスライド・サーバから受信されるとき、レンダリング・エンジン４２０は、画像を向上させるべく現在表示されている画像を好都合に更新する。
【００４５】
先読み器４３０は、バーチャルスライドの画像データを、レンダリング・エンジン４２０からの要求を先取りして動的に取り出す。先読み器４３０は、表示域コントローラ３７０によって表示されたバーチャルスライドにおけるユーザのナビゲーション動作を追跡し、バーチャルスライド画像の特定の方向への動きを判断する。これにより、先読み器４３０は、スライドの動きの方向に従って画像データを取り出し、レンダリング・エンジン４２０によって要求される画像データを先取りする。
【００４６】
Ｉ／Ｏモジュール４４０は、ローカル・データ記憶領域（図示せず）からのバーチャルスライド・データについてのすべての要求を処理する。好都合には、ローカル・クライアント・ビューアは、スタンドアロンでバーチャルスライドを閲覧できるよう、画像データをローカルに記憶することができる。これらの画像は、好ましくは、Ｉ／Ｏモジュール４４０によってアクセス可能なローカル・データ記憶領域に保存される。通信モジュール４５０は、バーチャルスライド・サーバとのネットワーク通信を取り扱う。好ましくは、通信モジュール４５０は、先読み器４３０、レンダリング・エンジン４２０、および表示域コントローラ３７０の他のコンポーネント、ならびにクライアント・ビューアと協働し、バーチャルスライド・サーバのデータおよび情報にアクセスする。さらに、通信モジュール４５０は、好ましくは、注釈コントローラ４００と協働し、バーチャルスライド・サーバに新規の注釈、注釈の変更、および注釈の削除を提供する。
【００４７】
さらに、表示域コントローラは、好ましくは種々さまざまな圧縮および解凍技法を実行するように構成された１つ以上のコーデック４６０を有している。好ましい実施の形態においては、バーチャルスライド画像ファイルについてＪＰＥＧ２０００圧縮が使用され、したがってコーデック４６０は、ＪＰＥＧ２０００の規格に従って圧縮および解凍を実行するように構成されている。さらに、コーデック４６０を、ＪＰＥＧおよびレンペル‐ジブ‐ウェルチ（「ＬＺＷ」）の圧縮規格に従って圧縮および解凍を実行するように構成してもよい。表示域コントローラは、複数の圧縮技法を同時にサポートすることができ、その場合、画像の属性にもとづいて選択されるコーデック４６０の複数のインスタンスが存在するであろう。
【００４８】
最後に、表示域コントローラは、キャッシュ４７０を有している。キャッシュ４７０は、ただ１つの物理的なキャッシュとして、あるいは複数の別個の物理的なキャッシュとして、実装することができる。一実施の形態においては、ブロックのためのキャッシュ、画像サブ領域のためのキャッシュ、およびバーチャルスライド情報のためのキャッシュなど、論理的に別個である複数のキャッシュが、表示域コントローラ３７０によって使用される。Ｉ／Ｏモジュール４４０が、データをローカル・ディスクまたはリモート・サーバから取り出す前に、ブロックおよび／または画像データについて適切なキャッシュ４７０をチェックするとともに、新たに取り出したデータでキャッシュを更新する。
【００４９】
図５Ｃは、本発明の一実施の形態による典型的なレンダリング・エンジン４２０を示したブロック図である。レンダリング・エンジン４２０は、表示域コントローラの主要コンポーネントであり、ガンマ調節器５００、フィルタ処理モジュール５１０、拡大縮小（スケーリング）モジュール５２０、および変形モジュール５３０を有している。
【００５０】
ガンマ調節器５００は、画像データ内の赤‐緑‐青（「ＲＧＢ」）値の実際にモニタ上に表示されるピクセルへのカラーマッピングについて、リアルタイムでの調節を提供する。この能力の利点は、バーチャルスライドを閲覧するときに環境光およびモニタ特性の相違を補償できる点にある。フィルタ処理モジュール５１０は、所定またはユーザ指定のコンボリューションマトリクスを画像データに適用することによって、バーチャルスライド画像データのフィルタ処理を可能にし、コントラストの強調、エッジの鮮鋭化、および他の画像処理能力を提供する。
【００５１】
拡大縮小モジュール５２０は、画像の忠実度の喪失を小さく抑えつつ、バーチャルスライド画像の解像度の増減を可能にする。好都合なことに、拡大縮小に必要な時間は、バーチャルスライド画像ファイルに種々の中間レベル解像度画像２９０、２９１を前もって備えておくことによって、大幅に低減される。変形モジュール５３０は、９０°回転などバーチャルスライド画像の直角回転を可能にし、さらに画像の水平および垂直反転を実現できる。
【００５２】
図５Ｄ〜Ｈは、本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。図５Ｄは、典型的なクライアント・ビューア・ウインドウを示している。このウインドウは、それぞれ別個のスライドの画像を表示している２つの表示域５４０に分割されている。右側の表示域５４０がアクティブなウインドウであり、このウインドウについての情報が、ステータス・バー５４２に示されている。ステータス・バーには、この画像が７３，０４２×６２，６３３ピクセルであり、このバーチャルスライドの画像データが約１３．１ＧＢである旨が示されている。さらに、ステータス・バーは、表示域５４０が現在データを先読みしていることを示している。
【００５３】
さらに、それぞれの表示域５４０には、サムネイル画像５４４など、バーチャルスライド全体のサムネイル画像が示されている。好都合なことに、サムネイル画像内でマウスをクリックまたはドラッグすると、これに対応して表示域ウインドウ内の拡大画像を位置させることができる。さらに、現在の閲覧の相対位置およびサイズを示すため、サムネイル画像内に四角形が表示されている。
【００５４】
さらに、それぞれの表示域５４０に拡大鏡ウインドウ５４６を開くことができる。好都合なことに、拡大鏡ウインドウ５４６は、カーソルの周囲の領域を２倍の相対倍率で表示することができる。マウスをドラッグすることによって、マウスの周囲の拡大領域を移動させることができる。コンピュータ画面上のピクセルのサイズが小さいため、好都合には、ビューア（すなわち、人物）により多くの情報を提供すべく、スキャンした解像度レベルを超えて画像を拡大することができる。拡大鏡ウインドウ５４６によって、ユーザは、追加の２倍の解像度を得るべく表示された画像データ上を移動することができる。この追加の解像度は、ベースライン画像についても利用可能である。
【００５５】
さらに、各表示域ウインドウの解像度を所定の特定の解像度に設定できるよう、ツールバー５４８も用意されている。好都合には、この所定の解像度が、バーチャルスライド画像ファイルにすでに存在しているベースラインおよび中間レベルに、直接対応しているとよい。最後に、ズーム・スライダ５５０によって、任意の解像度レベルを選択することができるとともに、表示域コントローラ内のバーチャルスライド画像について迅速な拡大縮小が可能である。
【００５６】
図５Ｅは、典型的なガンマ調節ウインドウを示している。画像の明るさ／コントラスト、画像のカラーバランス、および画像のカラー曲線を調節し、さらに調節設定の読み込みおよび保存を行なうため、さまざまなタブが利用可能である。図示の実施の形態では、カラー曲線タブが示されている。カラー曲線５５２によって、ユーザは、スペクトルに沿ってカラーマッピングを調節することができる。左側のカラー・ボックスによって、ユーザは、変更しようとする特定のカラー・チャネルについての曲線を独立に選択でき、あるいはすべてのカラー・チャネルを同時に変更すべく選択することができる。
【００５７】
図５Ｆは、典型的なフィルタ処理ウインドウを示している。ウインドウの上部には、あらかじめ定められたいくつかのフィルタが挙げられており、所望のラジオ・ボタンを選択することによって適用することができる。さらに、カスタム設定できる５×５のコンボリューションマトリクスを、ダイアログ・ボックスの入力フィールド５５６に適当な値を入力することによって定義することができる。コンボリューションマトリクスによって、コントラストの強調、エッジの強調、および他の画像処理機能が可能である。
【００５８】
図５Ｇは、典型的な変形ウインドウを示している。変形ウインドウにより、所望のラジオ・ボタンを選択することによって、ユーザは、バーチャルスライド画像を９０°回転させることができ、あるいは水平または垂直の中心線を横切って画像を鏡像反転させることができる。
【００５９】
図５Ｈは、典型的なウェブ・ビューア・ウインドウを示している。ウェブ・ビューア・ウインドウは、ＨＴＭＬおよび埋め込みされた画像で作られている。標準的なテキスト５６０を、図３に関してすでに説明したとおりウェブ・ビューアによって生成し、所望のとおり表示および配置することができる。また、サムネイル画像５６２も、内部サイズおよび中間解像度画像５６４の位置確認のための位置基準とともに提供されている。さらに、中間解像度画像５６４の内部には、高解像度画像５６６の現在の位置を示す同様の基準が提示されている。
【００６０】
図６Ａは、本発明の一実施の形態による典型的な注釈モジュール１６０を示したブロック図である。注釈モジュール１６０は、注釈ビューア１６４および注釈ハンドラ１６２を有している。注釈ビューア１６４は、バーチャルスライド・モジュール１１０と関連して動作し、バーチャルスライド画像データに重ねて表示すべく注釈情報（すなわち、レイヤー）を提供する。注釈ハンドラ１６２が、クライアント・ビューア８０などのビューアからの注釈の生成、編集、および削除の要求を処理する。さらに、注釈ハンドラ１６２は、データ記憶領域１５０への注釈情報の保持を管理するとともに、適切な場合、注釈データを取り出して、当該注釈情報を注釈ビューア１６４に提供する。
【００６１】
一実施の形態において、ユーザはクライアント・ビューア８０において、例えば注釈コントローラ４００を使用して注釈を生成することができる。注釈情報が、クライアント・ビューア８０の通信モジュール４５０によって、バーチャルスライド・サーバ２０へと送信される。注釈の生成を含んでいる要求が、通信モジュール１００によって処理され、注釈ハンドラ１６２に渡される。次いで、注釈ハンドラ１６２が、注釈をデータ記憶領域１５０への保存のためにデータベース・モジュール１４０へと提供する。
【００６２】
図６Ｂ〜Ｃは、本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。図６Ｂは、構造化言語による典型的な注釈を示している。図示の実施の形態においては、注釈が拡張可能マークアップ言語（「ＸＭＬ」）で示されているが、他の構造化言語も使用可能である。好都合には、当業者であれば理解できるとおり、このような注釈を、単純な文字列としてデータベースに保存することができる。
【００６３】
注釈は、バーチャルスライドのベース解像度レベルに対応する座標を使用して記述でき、保存でき、取り出すことができる。これにより、注釈を、それらが説明している画像データとともに、任意の解像度レベルへと拡大縮小することができる。図示の実施の形態においては、注釈が、表示される１つ以上の特徴または領域で構成されており、レイヤーへとグループ化されている。一実施の形態においては、個々の注釈レイヤーを選択的に有効にでき、あるいは無効にできる。
【００６４】
図６Ｃは、注釈を有する典型的な表示域ウインドウを示している。フローティング（移動可能な）ダイアログ・ボックス６０２が、ユーザに注釈コントローラを提供し、注釈レイヤーおよびレイヤー属性の選択を容易にする。同様に、ダイアログ・ボックス６０４が、現在のレイヤー内で個々の注釈および注釈属性を追加し、編集し、削除する能力を、ユーザに提供する。
【００６５】
個々の注釈６０６は、いくつか例を挙げると、楕円、矢印、自由形状多角形、および矩形など、種々さまざまな形態を具現化できる。一実施の形態においては、或る特定のレイヤー内の各注釈が、例えば現在選択されている注釈が黒の縁取りを有するなど、異なる色で表示される。注釈作成ツールがメニューバー６０８に出現し、いくつか例を挙げると、ペン・ツール、形状ツール（矩形および楕円形）、および矢印ツールを含んでいる。
【００６６】
一実施の形態においては、注釈が、バーチャルスライドのベースライン画像に対して特定の位置に関連付けられた注釈領域で構成されている。各注釈領域に関してさまざまな値を設定でき、注釈文字列にｋｅｙ＝ｖａｌｕｅの形式で保存することができる。注釈レイヤーが、複数の注釈領域を含んでもよい。さらに、注釈レイヤーが、さまざまな値を例えばｋｅｙ＝ｖａｌｕｅの形式でレイヤーに関連付け、注釈文字列とともに保存して有してもよい。
【００６７】
図７Ａは、本発明の一実施の形態による典型的なＶＭＣ閲覧システム１２を示したネットワーク図である。図示の実施の形態においては、ＶＭＣサーバ３２が、リーダ・クライアント・ビューア７４および参加者クライアント・ビューア７６に、ネットワーク６２を介して通信可能に接続されている。一実施の形態においては、複数の参加者クライアント・ビューア７６が存在してよいが、リーダ・クライアント・ビューア７４は、カンファレンスのセッションごとに１つだけである。リーダ・クライアント・ビューア７４は、ローカルなデータ記憶領域７５を備えて構成でき、各参加者クライアント・ビューア７６も、同様にローカルなデータ記憶領域７７を備えて構成できる。代案となる実施の形態においては、２つ以上のリーダ・クライアント・ビューア７４が存在してもよい。
【００６８】
図７Ａに示すとおり、本発明の一実施の形態においては、バーチャルスライド・サーバ３４が、データ記憶領域５０または画像キャッシュ（図示せず）から、バーチャル顕微鏡カンファレンス・セッションのすべての参加者７４および７６に、画像データを供給する。任意により、バーチャルスライド・サーバ３４が、バーチャル顕微鏡カンファレンス・サーバ３２と同じ位置にあってもよく、さらに／あるいはサーバ３４および３２を、１つの共有サーバ２１へと一体に組み合わせてもよい。
【００６９】
バーチャル顕微鏡カンファレンスにおいては、リーダ・クライアント・ビューア７４が、セッションの閲覧を管理する。リーダ・クライアント・ビューア７４から受け取ったバーチャルスライド指令により、ＶＭＣサーバ３２が、それらの指令を当該セッションの他の参加者ビューアに伝達する。例えば、注釈レイヤーの表示および注釈領域の生成を含め、リーダ・クライアント・ビューア７４から受信される視点の移動および拡大縮小ならびに他の相互作用の指令がすべて、ローカルで実行され、他のすべての参加者ビューアへと伝達される。さらに、画像を開く指令および閉じる指令、ならびに他のセッション制御行為は、当該セッション・リーダによって開始される。参加者クライアントは、自身の画像表示をローカルで変更（視点移動、拡大縮小、など）してもよいが、これらの動作がＶＭＣサーバ３２を介して他のセッション参加者に伝えられることはない。
【００７０】
図７Ｂは、本発明の一実施の形態によるバーチャル顕微鏡カンファレンスのための典型的なＶＭＣサーバ３２を示したブロック図である。ＶＭＣサーバ３２は、ＶＭＣセッション・マネージャ６２０およびＶＭＣセッション・テーブル６３０を備えている。認証モジュール１３０およびデータベース・モジュール１４０が、ＶＭＣセッションの参加者を認証するために使用される。
【００７１】
好都合には、ＶＭＣセッション・マネージャが、リーダ・クライアント・ビューアから受け取るすべてのＶＭＣ要求を処理する。さらに、ＶＭＣセッション・マネージャ６２０は、どのクライアントがリーダであるのかを把握し、リーダシップを要求したクライアントの待ち行列を保持するため、ＶＭＣセッション・テーブル６３０を維持する。さらに、ＶＭＣセッション・テーブル６３０は、好ましくは、各参加者クライアント・ビューアの現在のバーチャルスライド閲覧をリーダ・クライアント・ビューアのものと同期させるため、各参加者クライアント・ビューアの状態を保持する。
【００７２】
一実施の形態においては、ＶＭＣセッション・テーブル６３０が、リーダ・クライアント・ビューアになることを要求した参加者クライアント・ビューアのリストを含んでいる。好都合には、リーダ・クライアント・ビューアが、ＶＭＣサーバ３２においてセッション・リーダーシップ待ち行列中で順番を待っている次の参加者クライアントを選択するように要求することで、明示的または暗黙裡に、セッションのリーダシップをいずれかの参加者クライアント・ビューアへと、いつでも渡すことができる。
【００７３】
ＶＭＣセッション・マネージャ６２０は、まず、第１のクライアント・ビューアからセッションを確立するためのＶＭＣ要求を受信する。この第１のクライアント・ビューアがリーダ・クライアント・ビューアとなって、パスワードおよびセッション識別子を設定する。このセッション識別子を指定し、かつ正しいパスワードを提示するさらなるクライアント・ビューアが、参加者クライアント・ビューアになる。一実施の形態においては、各参加者クライアント・ビューアが、当該参加者クライアント・ビューアの状態を追跡すべく生成された固有のＶＭＣセッション・テーブルを有している。
【００７４】
リーダ７４およびすべての参加者７６を含むＶＭＣセッションのクライアントは、すでに述べたとおり、画像データを取得するための１つ以上のバーチャルスライド・サーバ３４へのアクセスを共有する。画像データへのアクセスは、画像ブロック・レベルであって、ブロックの処理がクライアントによって行なわれてもよく、あるいは画像サブ領域のレベルであって、サブ領域を描くためのブロックの処理がクライアントの代理としてサーバによって行なわれてもよい。
【００７５】
一実施の形態においては、バーチャルスライド画像のガンマ調節が、個々の参加者ベースで利用可能である。ガンマ調節は、個々のモニタおよび環境光のそれぞれに固有であって、したがってＶＭＣセッションの個々の参加者クライアント・ビューアのそれぞれによって制御可能であると好都合である。ガンマ調節の操作は、バーチャルスライド・サーバ３４上で実行できるが、より一般的には、ローカルのクライアント・ビューアにて実行される。
【００７６】
図７Ｃは、バーチャルスライド・ビューア７０内へと作りこまれたバーチャル顕微鏡カンファレンス・クライアント（リーダまたは参加者のいずれか）の典型的な一実施の形態を示している。フローティング（移動可能な）ダイアログ・ボックスが、参加者のリスト７０２など現在のセッションの状態を表示している。セッションのリーダシップを要求し、割り当て、放棄するため、コントローラ７０４が設けられている。
【００７７】
図８Ａは、本発明の一実施の形態による典型的な三次元バーチャルスライドを示したブロック図である。三次元バーチャルスライドは、垂直の次元に複数の画像平面を含んでいる。例えば、顕微鏡スライドにおいて組織標本がかなりの厚さを有している場合、標本全体を垂直方向のただ１つの焦点面で捉えることは、多くの場合困難である。したがって、顕微鏡スライドが、焦点面の異なるいくつかの垂直レイヤーにてスキャン（すなわち、デジタル化）され、垂直レイヤーのそれぞれが別個の垂直スライド画像を構成する。
【００７８】
図示の実施の形態においては、顕微鏡スライドが５つの別個の垂直レイヤーにてスキャンされ、これら５つのレイヤー（０〜４）のそれぞれについてバーチャルスライドが生成され、保存される。さらに、各レイヤーについての垂直軸（本明細書において「Ｚ軸」とも称する）方向のオフセットが、各レイヤーについてのバーチャルスライドと垂直軸方向のオフセット７１６とからなる複合画像ファイルを生成するため、保存される。したがって、クライアント・ビューアが、レイヤー０の画像７１２とレイヤー１の画像７１４との間に位置する現閲覧レイヤー７１２など、Ｚ軸において５つあるレイヤーのうちの２つのレイヤーの間の閲覧を要求したとき、直上のレイヤーおよび直下のレイヤーが、要求された垂直レベルについての閲覧をユーザに提供すべく補間される。
【００７９】
図８Ｂは、本発明の一実施の形態による三次元バーチャルスライド・スキュー７２０を示したブロック図である。垂直軸について現閲覧レベルを補間することの利点は、得られる現在の閲覧をスキューできる点にある。例えば、レイヤー０の画像７１０からの画像ピクセルを或る一方向にずらすことができ、レイヤー１の画像７１４からの画像ピクセルを、反対方向にずらすことができる。この結果、得られる現在の閲覧レベルの画像が、実際のスキャン方向への角度を近似する視点をもたらすことになる。三次元バーチャルスライドのスキューを操作することによって、ユーザは、好都合にも、スライド上の対象組織または細胞の回転三次元画像を見ることができる。
【００８０】
図８Ｃは、バーチャルスライド・ビューア７０内へと作りこまれた本発明の一実施の形態による典型的な三次元バーチャルスライド閲覧ウインドウを示したスクリーンショットである。図示の実施の形態においては、表示域画像５４０が、直上の画像レイヤーと直下の画像レイヤーとから補間された現在の閲覧レベルを表示している。垂直方向のレイヤーの奥行きについてのスライダ・コントローラ７３０によって、ユーザは、表示域の表示をＺ軸に沿って変化させることができる。さらに、スキュー・コントローラ７３２によって、ユーザは、表示域内のバーチャルスライド画像について、スキュー方向およびスキューの量を動的に変化させることができる。一実施の形態においては、スキュー制御ウインドウ内の十字線をドラッグすることによって、三次元の視点を変化させることができる。好都合には、暗い影の円が、対象物（例えば、白い円）に対する視点（例えば、十字線）の関係を示している。
【００８１】
典型的な実施の形態
以下で、本発明の典型的な実装例を、図９Ａ〜９Ｆに関して説明する。この典型的な実施の形態は、あくまで例として説明されるものであり、これまでに記載し添付の特許請求の範囲にも記載される本発明の広がりおよび技術的範囲を限定するものとして解釈するべきではない。
【００８２】
図９Ａ〜９Ｆは、バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。図９Ａは、バーチャルスライド閲覧システムの各コンポーネントおよびそれらの間のインターフェイスを、下記のとおり説明している。
【００８３】
図示の実施の形態は、デジタル化スキャンによる顕微鏡スライド（「バーチャルスライド」）の閲覧および管理のためのコンピュータ・システムを含んでいる。このコンピュータ・システムは、バーチャルスライド情報を保存する１つ以上のサーバ装置、およびスライド情報の閲覧に使用される１つ以上のクライアント装置を有している。システム内のコンピュータは、ＴＣＰ／ＩＰ（インターネットで使用される標準的なネットワーク・プロトコル）によるＨＴＴＰ要求を使用して通信する。システムのコンピュータは、互いに物理的に近くにあって構内通信網（「ＬＡＮ」）によって通信してもよく、あるいは物理的に離れていて広域通信網（「ＷＡＮ」）によって通信してもよい。このシステムの重要な特徴は、ＷＡＮにおいて優秀な性能を示す点にあり、すなわちＬＡＮの装置間帯域幅を必要としない点にある。
【００８４】
サーバ装置は、典型的には、インテル社（Ｉｎｔｅｌ）のアーキテクチャのプロセッサを特徴として備え、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）のウインドウズ（Ｗｉｎｄｏｗｓ（登録商標））またはリナックス（Ｌｉｎｕｘ）（登録商標）を動作させる強力なＰＣである。システムのアーキテクチャは、サーバの実装の詳細とは無関係である。システムのすべてのサーバ・コンポーネントは、１つのサーバ装置に同居してもよく、あるいは性能向上または保守性を考慮して別個独立であってもよい。
【００８５】
このシステムは、２つの閲覧環境を提供する。クライアント閲覧インターフェイスは、簡単かつ簡潔なグラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）を提供するスタンドアロンの閲覧プログラム（「イメージスコープ（ＩｍａｇｅＳｃｏｐｅ）」）を使用する。ウェブ閲覧インターフェイスは、任意の標準的なインターネットブラウザを使用し、クライアント側にアプレット、プラグイン、または他のソフトウェアを必要としない。クライアント閲覧インターフェイスは、任意のインテル・アーキテクチャのコンピュータ上で、マイクロソフト・ウインドウズの任意のバージョン上で動作する。このシステムの特徴は、クライアント装置の構成とは無関係である。ウェブ閲覧インターフェイスは、そのような環境がＨＴＭＬページの処理およびＪＰＥＧ画像の表示という標準的なウェブ・ブラウザの能力を提供する限りにおいて、あらゆるコンピュータ上で、あらゆるオペレーティング・システムのあらゆるバージョン上で動作する。
【００８６】
Ａ‐イメージサーバ（ＩｍａｇｅＳｅｒｖｅｒ）装置
このコンピュータは、バーチャルスライド画像を収容し、スライド・データへのアクセスのために使用されるネットワーク・アプリケーション・プログラム・インターフェイス（「ＡＰＩ」）を提供する。この装置は、インテル‐アーキテクチャのコンピュータであってマイクロソフト・ウインドウズまたはリナックス（登録商標）を動作させており、典型的には、かなりのメモリ（キャッシュ用）および大量のディスク記憶領域（バーチャルスライドの保存用）を装備する強力なＰＣである。
【００８７】
Ｂ‐ウェブ・サーバ装置
このコンピュータは、ウェブ・インターフェイスを使用してバーチャルスライド・データにアクセスするために使用されるウェブサイトを収容している。ウェブビューア（ＷｅｂＶｉｅｗｅｒ）ソフトウェアが、ウェブサーバに一体化されている。この装置は、マイクロソフト・ウインドウズおよびマイクロソフト・インターネット・インフォメーション・サーバ（ＩＩＳ）を動作させるインテル‐アーキテクチャのコンピュータであってよく、あるいはアパッチ（Ａｐａｃｈｅ）を動作させる任意のアーキテクチャのコンピュータであってよい。ウェブ・サーバ装置が、イメージサーバ装置と同じであることも可能である。
【００８８】
Ｃ‐バーチャルスライド画像ファイル
バーチャルスライドは、典型的には２００ＭＢ〜４ＧＢのサイズの別個独立のファイルとして保存される。イメージサーバ装置は、容量および堅牢性の理由で、複数の別個独立のディスクからなる冗長アレイ（「ＲＡＩＤ」）を備えて構成されることが多い。
【００８９】
Ｄ‐データベース
認証用のデータおよび注釈を含むバーチャルスライド情報が、ＳＱＬデータベースに保存される。このデータベースは、通常はイメージサーバ装置に位置するが、必ずしもそのようである必要はない。典型的な実装例は、マイクロソフト・データベース・エンジン（「ＭＳＤＥ」）またはマイクロソフトＳＱＬサーバを使用する。データベースへのアクセスは、システムの一部として提供されるサービスを経由する。このサービスへのインターフェイスは、ＴＣＰ／ＩＰによるＨＴＴＰであり、データベース・アクセスの分散を可能にする。
【００９０】
Ｅ‐イメージサーバ（ＩｍａｇｅＳｅｒｖｅｒ）
イメージサーバは、バーチャルスライド・データへのアクセスのためのネットワークＡＰＩを提供するスタンドアロンのアプリケーションである。イメージサーバは、バーチャルスライド画像ファイルにアクセスするとともに、認証および注釈データへのアクセスのため、データベースへのインターフェイスを有している。
【００９１】
Ｆ‐イメージスコープ（ＩｍａｇｅＳｃｏｐｅ）ビューア
イメージスコープは、スライド情報の閲覧のために簡単かつ簡潔なグラフィカル・ユーザ・インターフェイスを提供するスタンドアロンのアプリケーションである。イメージスコープは、イメージサーバのネットワークＡＰＩを利用してイメージサーバとやり取りし、あるいはバーチャルスライド・ファイルを直接読み出すことができる。
【００９２】
Ｇ‐ウェブビューア（ＷｅｂＶｉｅｗｅｒ）
ウェブビューア・ソフトウェアは、スライド情報を閲覧するためのＨＴＭＬユーザ・インターフェイスをウェブ・ブラウザに届けるため、標準的なウェブ・サーバのもとで動作する。ＨＴＭＬページは、ウェブ・ブラウザにイメージサーバからのＪＰＥＧ画像情報を要求させる画像タグ（＜ＩＭＧ＞）を含んでいる。ＨＴＭＬページとＪＰＥＧ画像の組み合わせが、ウェブビューア・インターフェイスを構成する。
【００９３】
Ｈ‐ウェブ・ブラウザ
任意のプラットフォーム上のあらゆる標準的なウェブ・ブラウザを、ウェブビューアを利用してバーチャルスライド・データを閲覧すべく使用することができる。
【００９４】
Ｘ‐画像ブロックＡＰＩ
イメージサーバは、バーチャルスライド・ファイルのブロックにアクセスするため、ＴＣＰ／ＩＰによるＨＴＴＰメッセージ・インターフェイスをサポートしている。これらのブロックは、イメージビューア（クライアント側）によって解凍され、処理される。
【００９５】
Ｙ‐画像サブ領域ＡＰＩ
イメージサーバは、バーチャルスライド・ファイルのサブ領域にアクセスするため、ＴＣＰ／ＩＰによるＨＴＴＰメッセージ・インターフェイスをサポートしている。これらの領域は、イメージサーバ（サーバ側）によって解凍および処理され、ＪＰＥＧ画像として再圧縮されてブラウザへと送信される。
【００９６】
Ｚ‐ウェブ・サーバへのＨＴＭＬインターフェイス
これは、ウェブ・ブラウザとウェブ・サーバとの間の標準的なＴＣＰ／ＩＰによるＨＴＴＰインターフェイスであって、ブラウザへとＨＴＭＬページを届けるために使用される。ウェブビューアが、ページの動的な生成、および応答データの処理を行なう。
【００９７】
図９Ｂは、イメージ・サーバの内部の実装の詳細を、以下に説明するとおり示している。
【００９８】
イメージサーバは、バーチャルスライド画像データへのアクセスのため、クライアントにネットワークＡＰＩを提供するスタンドアロンのアプリケーションである。クライアントは、画像ブロック（圧縮された生の画像データ）または画像領域（解凍され、拡大縮小され、変形され、フィルタ処理され、ＪＰＥＧフォーマットへと再圧縮された画像データ）にアクセスすることができる。さらに、種々の画像属性（寸法、説明文、など）および注釈情報へのアクセスも提供される。
【００９９】
イメージサーバは、複数のクライアントに同時にサービスを提供することができ、画像データへのアクセスを高速化するために複数のメモリ・キャッシュを使用する。サーバへの要求はすべて、状態と無関係（ｓｔａｔｅｌｅｓｓ）である。要求は、ＴＣＰ／ＩＰによってＨＴＴＰで行なわれる。ＨＴＴＰ  １．１の要求パイプラインがサポートされている（１つのソケット接続によって複数の要求を順次に行なうことができる）。
【０１００】
イメージサーバは、クライアントからの新規ソケット接続を受け入れて、すべてのクライアント要求を管理する接続マネージャ・コンポーネントを含んでいる。各クライアント要求は、任意により、ＨＴＴＰ認証ヘッダを含むことができる。このヘッダは、ウェブ・ブラウザ（ユーザが、ユーザＩＤ／パスワード認証情報を入力したとき）およびイメージスコープなどのスタンドアロン・クライアント・プログラムによって生成される。接続マネージャは、届いた要求のすべての認証情報を検証する。認証は、ディレクトリ・レベルで実行される。いくつかのディレクトリは「パブリック」であってよく（認証が要求されない）、他のディレクトリは、当該ディレクトリ内のあらゆる画像を閲覧可能にする前に、明示的な認証を要求することができる。
【０１０１】
Ａ‐接続マネージャ・コンポーネントが、クライアントからの新規ソケット接続を受け入れ、すべてのクライアント要求を管理し、認証の確認を実行する。
【０１０２】
Ｂ‐各要求（すべての接続は状況と無関係である）においてクライアントが、ＨＴＴＰ認証ヘッダ内にユーザＩＤ／パスワード情報を供給することによって、認証証明を提示する。
【０１０３】
Ｃ‐要求ごとに認証データベースにアクセスしなくてもよいよう、認証キャッシュが、イメージサーバによって保持される。このキャッシュは、定期的に新規の接続が確立されたときに書き換えられ、あるいは明示的にリセット（ＲＥＳＥＴ）要求が受信されたときに書き換えられる。
【０１０４】
Ｄ‐データベース・サービスが、データベースへのインターフェイスを提供する。このサービスは、ＨＴＴＰ要求を受け入れ、データベースをイメージサーバとは別個の装置に配置できるようにする。このサービスは、データベース情報にアクセスするために標準的なＳＱＬ要求を使用する。
【０１０５】
Ｅ‐認証および注釈の情報を保存するため、ＳＱＬデータベースが使用される。このデータベースは、通常は、マイクロソフト・データベース・エンジン（「ＭＳＤＥ」）を使用して実装されるが、ＳＱＬサーバであってもよく、あるいは他の任意のＳＱＬ準拠のデータベースであってよい。
【０１０６】
Ｆ‐クライアントによって画像情報要求が行なわれ、画像の寸法、説明文、およびピラミッド構造などの属性が返される。情報要求は、データを返すためにイメージオブジェクト（Ｉｍａｇｅ  Ｏｂｊｅｃｔ）のプロパティ（ｐｒｏｐｅｒｔｉｅｓ）を使用する。
【０１０７】
Ｇ‐イメージサーバによって管理される別個のバーチャルスライド画像のそれぞれについて、イメージオブジェクトがインスタンス作成され、バーチャルスライドとやり取りするためのプロパティおよび方法が提供される。性能上の目的で、最近アクセスされたオブジェクトのキャッシュが保持される。イメージオブジェクトは、バーチャルスライドの詳細な実装からアプリケーションを切り離すため、システム全体において使用される。
【０１０８】
Ｈ‐バーチャルスライド・ファイルへのアクセスをカプセル化（ｅｎｃａｐｓｕｌａｔｅ）するため、イメージオブジェクト内にファイルオブジェクト（Ｆｉｌｅ  Ｏｂｊｅｃｔ）がインスタンス作成され、そのようなファイルとやり取りするためのプロパティおよび方法が提供される。
【０１０９】
Ｉ‐性能上の目的で、ファイル情報キャッシュが、すべてのファイルオブジェクトにわたって保持される。これにより、要求がなされたとき、最近アクセスされたファイルについてのすべての情報を再ロードする必要なく、イメージオブジェクトをインスタンス作成し、破壊することが可能である。ファイル情報キャッシュは、ファイルオブジェクトがインスタンス作成されたときに定期的に書き換えられ、あるいは明示的にリセット要求が受信されたときに書き換えられる。
【０１１０】
Ｊ‐バーチャルスライド・ファイル情報にアクセスするため、Ｉ／Ｏライブラリが、ファイルオブジェクトによって使用される。このライブラリは、タグ付き画像ファイル・フォーマット（「ＴＩＦＦ」）ファイル・ヘッダの詳細をカプセル化している。
【０１１１】
Ｋ‐バーチャルスライド画像ファイルは、通常のファイルと同様にイメージサーバ装置上に保存される（たとえ、きわめて大きいファイルであっても）。
【０１１２】
Ｌ‐ブロック要求は、画像ファイル・ブロックを直接デコードできるクライアント（すなわち、イメージオブジェクトを含んでいるクライアント）によってなされる。これは、スキャンスコープ・ビューアならびにアルゴリズム・フレームワーク（Ａｌｇｏｒｉｔｈｍ  Ｆｒａｍｅｗｏｒｋ）を含んでいる。ブロック要求は、直接ファイルオブジェクトへとイメージオブジェクトを通過し、Ｉ／Ｏライブラリへと渡される。ブロック要求は、サーバにおいて必要とされる処理がきわめて少ないため高速であり、バーチャルスライド画像の元のＪＰＥＧ２０００圧縮がクライアント／サーバ・インターフェイスを横断して保たれるため、高密度である。
【０１１３】
Ｍ‐性能上の目的で、ブロック・キャッシュが、最近使用（「ＭＲＵ」）基準にもとづき、すべてのファイルオブジェクトを横断して保持される。ブロック・キャッシュの大きさは、イメージサーバ装置上に構成されたメモリの量の関数であり、イメージサーバ・プロセスに渡されたパラメータによる。
【０１１４】
Ｎ‐領域要求は、画像ファイル・ブロックを直接デコードすることができないクライアント（ウェブ・ブラウザ、など）によってなされる。「領域」が、画像の任意のサブサーフェイス領域を指しており、画像ファイルまたは画像ファイルが取得されたやり方についての固定の属性ではないことに、注意すべきである。この点で、ここに記載の典型的な実施の形態は、画像データがタイルとして取得されてタイルとして保存されていて、タイルが画像の物理的なプロパティである他のシステムと、根本的に相違している。画像のサブ領域は、画像内の任意の（Ｘ，Ｙ）位置について、任意の解像度および任意の寸法で要求することができる。領域は、ＪＰＥＧ２０００データを理解できないクライアントとの互換性のため、ＪＰＥＧ画像としてエンコードされて返される。領域要求は、サーバにおいて必要とされる前処理の量ゆえにブロック要求よりも低速であり、画像データがＪＰＥＧ２０００ではなくＪＰＥＧにエンコードされて返されるため、ブロック要求よりも密度が低い。
【０１１５】
Ｏ‐さまざまな圧縮機構をカプセル化するため、コーデックオブジェクト（Ｃｏｄｅｃ  Ｏｂｊｅｃｔ）が、イメージオブジェクトとともにインスタンス作成される。バーチャルスライド画像については、通常は、高い画像忠実度ゆえＪＰＥＧ２０００が好ましいが、ＪＰＥＧおよびＬＺＷならびに生の画像（圧縮なし）もサポートされる。
【０１１６】
Ｐ‐性能上の目的で、領域キャッシュが、最近使用基準にもとづき、すべてのイメージオブジェクトを横断して保持される。領域キャッシュの大きさは、イメージサーバ装置上に構成されたメモリの量の関数であり、イメージサーバ・プロセスに渡されたパラメータによる。
【０１１７】
Ｑ‐画像についての注釈情報を要求および更新するため、注釈要求がクライアントによってなされる。注釈は、ＸＭＬにて保存され、データベース・サービスへとなされた要求によって、データベースからクライアントへと直接、「ブロブ（ｂｌｏｂ）」として返される。クライアントは、適切な認証を有している場合に、画像についての注釈情報を更新することができる。
【０１１８】
Ｗ‐注釈データ・インターフェイス
クライアントがＨＴＴＰ要求を行い、応答としてＸＭＬフォーマットの画像注釈データを受け取る。さらに、注釈データを、ＸＭＬフォーマットの画像注釈データを含んでいるＨＴＴＰ投稿によって、更新することができる。
【０１１９】
Ｘ‐画像ファイル情報インターフェイス
クライアントがＨＴＴＰ要求を行い、画像属性を取得するためのＸＭＬフォーマットの応答データを受け取る。
【０１２０】
Ｙ‐画像ブロック・インターフェイス
クライアントがＨＴＴＰ要求を行い、応答として画像ファイル・ブロックを受け取る。ブロックは、（Ｘ，Ｙ）位置およびレベルによって要求される。クライアントが、画像ファイル・ブロックの解凍（ＪＰＥＧ２０００コーデックを使用）および適切な解像度への拡大縮小を担当する。
【０１２１】
Ｚ‐画像領域インターフェイス
クライアントがＨＴＴＰ要求を行い、応答としてＪＰＥＧ画像を受け取る。領域は、画像の任意のサブ領域であり、（Ｘ，Ｙ）位置および解像度ならびに所望の寸法によって要求される。ＪＰＥＧ２０００の解凍および適切な解像度への拡大縮小は、イメージサーバ・プロセスによってなされる。
【０１２２】
図９Ｃは、イメージスコープ・ビューアの内部の実装の詳細を、以下に説明するとおり示している。
【０１２３】
イメージスコープは、スライド情報の閲覧のために簡単かつ簡潔なグラフィカル・ユーザ・インターフェイスを提供するスタンドアロンのアプリケーションである。イメージスコープは、イメージサーバのネットワークＡＰＩを利用してイメージサーバとやり取りし、あるいはバーチャルスライド・ファイルを直接読み出すことができる。
【０１２４】
イメージスコープは、きわめて大きなバーチャルスライドについてのリアルタイムでの視点移動および拡大縮小、複数の同時画像および表示窓の同期のサポート、ＪＰＥＧ２０００（ウェーブレット）の画像品質、性能を改善するための予測によるデータの先読み、性能向上のためのブロックおよび領域のキャッシュ、リアルタイムで調節可能なガンマ（ＲＧＢカラーマッピング）、コンボリューションフィルタのリアルタイム適用、リアルタイムでの直角変形（９０°回転および鏡像反転）、レイヤーによる注釈の表示および編集のサポート、バーチャル顕微鏡カンファレンス（「ＶＭＣ」）のサポート、および複数のＺ軸スキャンにて得たスライド・データの３Ｄ閲覧、など、バーチャルスライドの精査を容易にするための独自の特徴を提供する。
【０１２５】
イメージスコープは、その機能の大部分をビューポート（ｖｉｅｗｐｏｒｔ）と呼ばれるアクティブエックス（ＡｃｔｉｖｅＸ）コントローラにカプセル化する新規なアーキテクチャで実装される。ビューポート・コントローラは、バーチャルスライド閲覧能力を提供するため、さまざまなアプリケーションに容易に組み込むことができる。
【０１２６】
ビューポート・コントローラは、性能を最適化するため広範囲にわたるキャッシュおよび先読みの技法を使用する。アプリケーションは、性能の最大化および利用可能なメモリの活用のため、オブジェクト間キャッシュを共有する複数の表示域をインスタンス化できる。ビューポートそのものがイメージオブジェクトをカプセル化し、次にイメージオブジェクトが、ファイルオブジェクトをカプセル化し、イメージオブジェクトおよびファイルオブジェクトが、イメージサーバ・プログラムと共有される。
【０１２７】
イメージスコープ・プログラムおよびビューポート・コントローラの重要な属性は、きわめて大きいバーチャルスライド画像を、ネットワーク帯域幅が比較的低速（３００Ｋ）である広域通信網を介して閲覧できるという能力にある。この理由のため、画面の書き換えは決して同時性ではなく、代わりにビューポートは、現在キャッシュから利用可能である画像ビューの最良のバージョンを表示し、このビューのますます高い解像度のバージョンをイメージサーバから取り出すように継続的に試み、それがなされると画面を更新する。エンドユーザにとっての効用は、応答を感じることができ、接続の帯域幅を意識することがないという点にある。
【０１２８】
Ａ‐イメージスコープ・アプリケーションは、バーチャルスライドへのアクセスのためのグラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）を収容し、ビューポート・アクティブエックス・コントローラの複数のインスタンスのための容器として機能する。
【０１２９】
Ｂ‐ＧＵＩスクリーン・マネージャは、イメージスコープ・プログラムの主たる論理をカプセル化し、バーチャルスライド表示窓ならびにすべてのキーボードおよびマウス入力を管理する。
【０１３０】
Ｃ‐ビューポート・アクティブエックス・コントローラ
このコントローラのプロパティおよび方法は、バーチャルスライドへのすべてのアクセスをカプセル化する。コントローラのウインドウが、スライド情報を表示する表示窓の表面である。
【０１３１】
Ｄ‐「レンダリング・エンジン」が、ビューポート・コントローラの核心である。このエンジンは、任意の位置、寸法、および解像度におけるバーチャルスライド画像の任意の閲覧の「最良」のバージョンを構築するため、キャッシュされたデータを使用する。「より良い」バージョンが入手可能である（より多くのデータがイメージサーバから取り出される）とき、エンジンは、現在表示されている画面を更新する。
【０１３２】
Ｅ‐バーチャルスライド画像をカプセル化すべく、ビューポート・コントローラによってイメージオブジェクトがインスタンス作成され、バーチャルスライドとやり取りするためのプロパティおよび方法が提供される。
【０１３３】
Ｆ‐イメージオブジェクトは、領域配置のためのロジックを含んでおり、バーチャルスライドの任意の領域を所望の任意のレベルの解像度で描く。このロジックは、先読みスレッド（ｐｒｅｆｅｔｃｈ  ｔｈｒｅａｄ）によって惹起されたときなど、同期的（必要な画像情報を要求する）であってよく、あるいはレンダリング・エンジンによって惹起されたときなど、非同期（入手できる画像情報のみを使用する）であってよい。
【０１３４】
Ｇ‐コーデックオブジェクトが、種々の圧縮機構をカプセル化するため、イメージオブジェクトとともにインスタンス作成される。バーチャルスライド画像については、通常は、高い画像忠実度ゆえＪＰＥＧ２０００が好ましいが、ＪＰＥＧおよびＬＺＷならびに「生の」画像（圧縮なし）もサポートされる。
【０１３５】
Ｈ‐バーチャルスライド・ファイルへのアクセスをカプセル化するため、イメージオブジェクト内にファイルオブジェクトがインスタンス作成され、そのようなファイルとやり取りするためのプロパティおよび方法が提供される。ファイルオブジェクトは、リモート（ＴＣＰ／ＩＰライブラリを介してイメージサーバからアクセスされる）またはローカル（Ｉ／Ｏライブラリを介してローカルのファイルシステムからアクセスされる）であってよいバーチャルスライド・ファイルについて、場所に依存しないアクセスを可能にする。
【０１３６】
Ｉ‐ＴＣＰ／ＩＰライブラリが、イメージサーバへのネットワーク・インターフェイスをカプセル化するため、ファイルオブジェクトによって使用される。このライブラリは、サーバへのブロック・インターフェイスを使用する。
【０１３７】
Ｊ‐Ｉ／Ｏライブラリが、ローカルのバーチャルスライド・ファイルにアクセスするためファイルオブジェクトによって使用される。このライブラリは、ＴＩＦＦファイル・ヘッダ（タグ付き画像ファイル・フォーマット）の詳細をカプセル化している。
【０１３８】
Ｋ‐バーチャルスライド画像ファイルをローカルに保存でき、ビューポートを使用してアクセスする（そして、イメージスコープを使用して閲覧する）ことができる。
【０１３９】
Ｌ‐性能上の目的で、ブロック・キャッシュが、最近使用（ＭＲＵ）基準にもとづき、すべてのファイルオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。ブロック・キャッシュの大きさは、イメージスコープ装置上に構成されたメモリの量の関数であり、イメージスコープ・プログラムに渡されたパラメータによる。
【０１４０】
Ｍ‐性能上の目的で、ファイル情報キャッシュが、すべてのファイルオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。
【０１４１】
Ｎ‐性能上の目的で、領域キャッシュが、最近使用（ＭＲＵ）基準にもとづき、すべてのイメージオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。領域キャッシュの大きさは、イメージスコープ装置上に構成されたメモリの量の関数であり、イメージスコープ・プログラムに渡されたパラメータによる。
【０１４２】
Ｏ‐ビューポートは、リアルタイムでの直角変形（９０°回転および鏡像反転）をサポートする。これらの変形は、レンダリング・エンジンにて適用される。
【０１４３】
Ｐ‐ビューポートは、所望の任意の解像度へのリアルタイムでの拡大縮小をサポートする。この能力は、バーチャルスライド画像レベルの上に作られる。拡大縮小は、レンダリング・エンジンに作り込まれる。
【０１４４】
Ｑ‐ビューポートは、リアルタイムでのフィルタ処理をサポートし、所定またはカスタム設定の５×５のコンボリューション・カーネルを画像に適用できる。フィルタ処理は、レンダリング・エンジンに作り込まれる。
【０１４５】
Ｒ‐ビューポートは、リアルタイムでのガンマ調節をサポートし、実際に表示されるピクセルへのＲＧＢ値のカラーマッピングを、調節できるようにする。この能力は、バーチャルスライドが閲覧されるときの環境光およびモニタ特性の相違を補償するために、きわめて重要である。ガンマ調節は、レンダリング・エンジンに作り込まれる。
【０１４６】
Ｓ‐ビューポートは、注釈レイヤーの表示および編集をサポートする。注釈の表示は、レンダリング・エンジンに作り込まれる。
【０１４７】
Ｔ‐ビューポートは、表示されているバーチャルスライドについての画像データをレンダリング・エンジンの要求を先取りして動的に取り出す先読みスレッドを組み込んでなる。先読みのロジックが、現在のユーザの画像とのやり取りについて「動き」を割り出し、これを先読みを案内するために使用する（例えば、ユーザが画像を右へとスクロールしている場合、さらに右側の新しい画像データが先読みされる）。
【０１４８】
Ｕ‐イメージスコープは、ＧＵＩスクリーン・マネージャとビューポート・コントローラとの間に位置するＶＭＣインターセプト（ＶＭＣ  Ｉｎｔｅｒｃｅｐｔ）を含んでいる。ＶＭＣインターセプトは、ビューポートへのユーザ指令をＶＭＣサーバへと伝達し、さらにＶＭＣサーバからの指令を受け付けて、あたかもＧＵＩスクリーン・マネージャからのものであるようにビューポートへと供給する。
【０１４９】
Ｘ‐イメージサーバ・インターフェイス
ビューポート／ファイルオブジェクト／ＴＣＰ／ＩＰライブラリが、イメージサーバへのＨＴＴＰ要求を生成し、応答としてバーチャル・ファイル・ブロックを受け取る。さらに、このインターフェイスは、画像属性を取り出すためにも使用される。
【０１５０】
Ｙ‐ＶＭＣサーバ・インターフェイス
ＭＶＣインターセプトが、ＶＭＣサーバへのＨＴＴＰ要求を生成し、ＸＭＬフォーマットの応答を受け取る。このインターフェイスは、インターセプトした指令をＶＭＣサーバへと渡すために使用され（このアプリケーションがセッションを「リード」している場合）、ＶＭＣサーバからの指令を受信するために使用される（このアプリケーションが「従」である場合）。
【０１５１】
図９Ｄは、ウェブビューアの各コンポーネントおよびそれらの間のインターフェイスを示し、以下に説明するとおりである。
【０１５２】
ウェブビューア・ソフトウェアは、標準的なウェブ・サーバの元で動作し、ウェブ・ブラウザでスライド情報を閲覧するためのＨＴＭＬユーザ・インターフェイスを届ける。ＨＴＭＬページは、ウェブ・ブラウザにイメージサーバからのＪＰＥＧ画像情報を要求せしめる画像タグ（＜ＩＭＧ＞）を含んでいる。ＨＴＭＬページとＪＰＥＧ画像との組み合わせが、ウェブビューア・インターフェイスを構成する。
【０１５３】
ウェブビューア・インターフェイスの重要な特徴は、追加のアプレット、プラグイン、または他のソフトウェアを一切必要とせず、あらゆる標準的なウェブ・ブラウザで利用できる点にある。これにより、きわめて可搬性に富んだ（事実上あらゆるプラットフォームで利用できる）ものとなり、新たなユーザも、すぐにバーチャルスライド・データを閲覧することができる。
【０１５４】
Ａ‐ウェブ・ブラウザ
あらゆるプラットフォーム上のあらゆる標準的なブラウザがサポートされる。
【０１５５】
Ｂ‐ウェブ・サーバ装置
これは、通常は、ウインドウズのもとで動作するマイクロソフト・インターネット・インフォメーション・サーバ（ＩＩＳ）、またはリナックス（登録商標）またはユニックス（Ｕｎｉｘ（登録商標））のもとで動作するアパッチである。コーン・シェル（Ｋｏｒｎ  Ｓｈｅｌｌ）をサポートするプラットフォーム上でＣＧＩインターフェイスをサポートするあらゆるウェブ・サーバが、サポートされる。
【０１５６】
Ｃ‐ウェブビューア・スクリプト
これらは、ウェブ・サーバ・プロセスのもとで動作し、コモン・ゲートウェイ・インターフェイス（ＣＧＩ）を通じて惹起される。これらのスクリプトは、常駐のコーン・シェル・インタプリタを必要とする。ウェブビューアが、ウェブ閲覧のためのインターフェイスを有するＨＴＭＬページを構築し、インターフェイスからの入力（マウスのクリック）を処理する。
【０１５７】
Ｄ‐ＣＧＩは、コモン・ゲートウェイ・インターフェイスであり、ウェブ環境にてＨＴＴＰ入力を処理して出力としてＨＴＭＬページ・コンテンツを生成するプログラムを動作させるためにウェブ・サーバによって提供される標準的な機構である。
【０１５８】
Ｅ‐ウェブビューアは、バーチャルスライドの表示に使用されるＨＴＭＬを生成するＨＴＭＬページビルダ・モジュールを含んでいる。各スライド領域が、ウェブ・ブラウザが複数の画像サブ領域を並行して取り出すことができ、さらに画像サブ領域をキャッシュすることができるよう、多数の小さな領域から構成される。
【０１５９】
Ｆ‐イメージサーバ・プロセスが、実際の画像データを提供する。画像属性が、ＨＴＭＬページビルダによって要求される。ＨＴＭＬページは、イメージサーバの画像データを要求するＵＲＬを含んでいるＩＭＧタグのアレイを含んでいる。これらのＵＲＬは、イメージサーバへの領域インターフェイスを使用してＪＰＥＧサブ領域を要求し、次いで、これらサブ領域がウェブ・ブラウザによって表示される。
【０１６０】
Ｘ‐ウェブ・ブラウザとウェブ・サーバとの間のＨＴＴＰインターフェイスは、標準的である。ＨＴＴＰ要求がブラウザによって送信され、ＣＧＩを通じてウェブビューアへと導かれ、ＨＴＭＬページが生成されてブラウザへと返される。
【０１６１】
Ｙ‐ウェブビューアは、画像属性を取得するため、イメージサーバへと直接にＨＴＴＰ要求を行なう。
【０１６２】
Ｚ‐ウェブ・ブラウザは、ＨＴＭＬページに生成されたＩＭＧタグから、イメージサーバへとＨＴＴＰ要求を行なう。これらの要求は、イメージサーバへの領域インターフェイスを使用し、応答としてＪＰＥＧ画像が返される。
【０１６３】
図９Ｅは、バーチャルスライド閲覧システムにおける注釈サポートの詳細な実装を、以下に説明するとおり示している。
【０１６４】
このバーチャルスライド閲覧システムは、画像ごとに複数のレイヤー上の複数の注釈をサポートしている。注釈は、（ｉ）矩形領域、（ｉｉ）楕円形領域、（ｉｉｉ）特定のスポットを指し示す矢印、および（ｉｖ）任意の数の頂点を有する任意の多角形領域、という４つの形態のうちの１つをとる注釈領域で構成される。
【０１６５】
領域は、常にバーチャルスライドのベースライン画像に対して配置され、解像度とは無関係である（すなわち、注釈領域が画像とともに拡大縮小される）。各注釈領域は、１つ以上の属性を、「ｋｅｙ＝ｖａｌｕｅ」のかたちで自身に関連付けて有することができる。「ｋｅｙ」のセットは、注釈内のすべての領域について同じである。
【０１６６】
注釈内のすべての領域がまとまって、注釈レイヤーを構成する。注釈レイヤーは、画像上へのプラスチックの重ね合わせと考えることができる。各レイヤーを個々に表示でき、あるいは隠すことができる。レイヤーは、１つ以上の属性を、「ｋｅｙ＝ｖａｌｕｅ」のかたちで自身に関連付けて有することができる。注釈レイヤーについての「ｋｅｙ」は、任意の１つのレイヤーの領域についての「ｋｅｙ」と異なっていてもよい。
【０１６７】
表示域コントローラが、画像注釈の表示を管理するためのプロパティおよび方法を提供する。画像データが表示のためにフォーマットされるとき、有効にされている注釈レイヤーが画像上に描かれる。
【０１６８】
イメージスコープ・アプリケーションが、注釈を編集するためのＧＵＩツール一式を提供する。これらのツールを使用し、ユーザは、表示域コントローラの表面上のバーチャルスライドに注釈領域を対話的に「描く」ことができる。移動可能なウインドウが、注釈領域およびレイヤーに関する属性を入力するためのインターフェイスを提供する。
【０１６９】
画像についてのすべての注釈は、ＸＭＬ文字列として保存される。表示域コントローラがＸＭＬ文字列をフォーマットし、これをローカル・ファイルとしてディスクに保存でき、あるいはデータベースへの保存のためにイメージサーバへと送信できる。同様に、注釈を、データベースまたはローカル・ファイルから取り出すことができる。
【０１７０】
Ａ‐閲覧クライアント装置
イメージスコープが動作しているコンピュータ。
【０１７１】
Ｂ‐イメージスコープ・ビューア
注釈の表示および編集のためのユーザ・インターフェイスを提供するアプリケーション。
【０１７２】
Ｃ‐イメージサーバ装置
イメージサーバが動作しているコンピュータ。
【０１７３】
Ｄ‐イメージサーバ・アプリケーション
注釈を含むバーチャルスライド画像データへのアクセスのためのネットワークＡＰＩを提供するプロセス。
【０１７４】
Ｅ‐データベース
このＳＱＬデータベース（典型的には、ＭＳＤＥまたはＳＱＬサーバ）が、サーバ上に注釈情報を保存する。
【０１７５】
Ｆ‐イメージスコープのＧＵＩスクリーン・マネージャ・コンポーネントが、注釈の編集に使用される入力ツールおよびマウスの動きを管理する。
【０１７６】
Ｇ‐表示域コントローラが、注釈表示ロジックを含むバーチャルスライドへのすべてのアクセスをカプセル化する。注釈へのアクセスは、オープンＡＰＩによって提供される。
【０１７７】
Ｈ‐ビューポート内の注釈ロジックが、バーチャルスライドについてのすべての注釈を、画像データ上に要求どおりに描く。
【０１７８】
Ｉ‐表示域コントローラのレンダリング・エンジンが、表示のための画像領域を構成し、これが注釈表示ロジックへと渡される。
【０１７９】
Ｊ‐バーチャルスライド・ファイルそのものへのアクセスをカプセル化するため、イメージオブジェクトが、各表示域コントローラ内でインスタンス作成される。
【０１８０】
Ｋ‐イメージサーバと要求／応答の通信を行なうため、ＴＣＰ／ＩＰライブラリが、イメージオブジェクトによって使用される。
【０１８１】
Ｌ‐イメージサーバの接続マネージャが、新規のソケット接続を受け付け、クライアントからのすべての要求を管理する。
【０１８２】
Ｍ‐接続マネージャ内の認証レイヤーが、注釈についての要求を含む各要求について、認証証明を検証する。認証情報は、画像のための注釈レイヤーのそれぞれについて別個に保持され、すなわち、或る何人かのユーザが、或る幾つかのレイヤーについて読み出しのみのアクセスを有し、他のレイヤーについて更新アクセスを有してもよい。
【０１８３】
Ｎ‐注釈要求は、ＨＴＴＰインターフェイスを使用してデータベース・サービスに渡される。
【０１８４】
Ｏ‐データベース・サービスは、イメージサーバとデータベースとの間のインターフェイスを提供し、データベースを別個の装置上に配置してもよいようにする。
【０１８５】
Ｐ‐イメージスコープ内のＶＭＣインターセプトが、表示域コントローラへのすべての指令をＶＭＣサーバへと導き（ユーザが、セッションの「リーダ」である場合）、さらに／あるいはＶＭＣサーバからの指令をビューポートへと導く（ユーザが、セッションの「追従者」である場合）。これは、注釈の表示および編集の指令を含んでいる。
【０１８６】
図９Ｆは、以下に説明するバーチャルスライド閲覧システムにおけるＶＭＣサポートの内部の実装の詳細を示している。
【０１８７】
ＶＭＣは、複数のユーザが同時に閲覧セッションに参加して同じバーチャルスライドを閲覧する技法である。各ユーザのビューが他のユーザのビューに同期され、すなわち全員が同じ情報を眺めることになる。
【０１８８】
あらゆる瞬間について、各セッションにおいては１人のユーザがセッション「リーダ」であり、他のユーザは「追従者」である。リーダが、視点の移動および拡大縮小、ビューの変更、注釈の作成、などを実行し、これらの指令のそれぞれが、すべての追従者に伝達される。リーダは、いつでも、セッションのリーダシップを他の任意のユーザに譲り渡すことができる。追従者は、当該セッションのリーダになりたい旨をリーダに伝えることができる。ＶＭＣサーバが、各セッションについてリーダになることを希望する追従者の待ち行列を保持する（先入れ先出し（ＦＩＦＯ）の順番で）。リーダは、セッションのリーダシップを他のユーザに渡そうとするときに、特定のユーザを明示的に指名することができ、あるいは先頭で待っている追従者へとリーダシップを渡してもよい。
【０１８９】
ＶＭＣセッションは、ＶＭＣサーバ装置を使用して確立される。ＶＭＣサーバへと接続する最初のユーザが、セッションを生成し、説明用の名称を与え、パスワードを割り当てる。ＶＭＣサーバへと接続する後続のユーザは、説明用の名称によってセッションを特定でき、パスワードを入力することによって参加をすることができる。同時にＶＭＣセッションに参加できるユーザの数に、制限はない。新規セッションを定めた最初のユーザが、最初のリーダになる。
【０１９０】
必要であれば、特定のＶＭＣサーバへの接続のために認証を要求することができる。この認証は、サーバそのものにアクセスするためのものであり、個々のセッションは、固有のパスワードを最初に接続したユーザが確立したとおり有している。
【０１９１】
新たなユーザが進行中のＶＭＣセッションに加わるとき、当該セッションのために現在開かれているあらゆる画像が、この新規ユーザのために開かれ、すべての表示窓が、当該セッションにおける現在の位置に同期させられる。
【０１９２】
セッションにおいて、リーダは、１つ以上のバーチャルスライドを開くことができる。それらのスライドは、当該セッションのすべてのユーザにとってアクセスできるイメージサーバ上になければならない。画像が開かれるとき、セッションの他のすべてのユーザも、その画像を同時に開く。イメージサーバは、ＶＭＣサーバと同じ装置であってよいが、必ずしも同じ装置である必要はなく、同じ場所に位置している必要もない。
【０１９３】
セッション・リーダが画像を閉じるとき、その画像は、セッションのすべてのユーザについても閉じられる。
【０１９４】
セッション・リーダは、セッションの一部である任意の画像において、任意の位置および任意の倍率へと視点の移動および拡大縮小を行なうことができる。他のすべてのユーザは、これに自動的に倣う。閲覧ウインドウの寸法および構成は、個々のユーザが寸法の異なるモニタを使用している可能性がある点などを考慮するため、各ユーザの制御下に残される。各画像の配置は、常に閲覧ウインドウの中心を基準にする。
【０１９５】
セッションにおいて、各ユーザのイメージサーバへの接続の帯域幅が異なっている可能性があり、この結果、視点移動および拡大縮小において、応答時間が異なる可能性がある。ビューポート更新の非同期の性質ゆえ、これらの操作において、最悪でも或るユーザが他のユーザと同じ解像度では画像ビューを眺めることができない（より高解像度のデータがサーバから取り出されるまで）だけであり、いずれのユーザも「阻止」されることがないようにされる。
【０１９６】
イメージスコープ・ビューアのガンマ調節設備は、セッションのすべてのユーザについて同期されてはいない。これは、各ユーザが自身の好みに合わせて調節する余地を残している。これは、ガンマ調節が、通常は室内光およびモニタ温度ならびに個人の好みを補償するために行なわれるからであり、したがってリーダのガンマ設定をすべての追従者に渡しても意味がないからである。
【０１９７】
セッション・リーダは、ＶＭＣセッションの一部として開かれたバーチャルスライドについて、注釈を有効および無効にすることができる。すべてのユーザが、同時に注釈を有効および無効にする。さらに、セッション・リーダは、新規の注釈レイヤーおよび領域を生み出すことができる。セッションの各ユーザは、部分的に完成したレイヤーおよび領域を見る。これは、注釈が本質的に一時的である可能性があるため、イメージサーバ上の注釈データベースを通じて同期をするのではなく、リーダの注釈コマンドをすべてのユーザに伝達することによって、達成される。
【０１９８】
幾つかのセッションでは、１つの注釈レイヤー上で協働（リーダシップをお互いに渡すことによって）でき、他のセッションにおいては、各ユーザが自身の注釈レイヤーを有することができる。この決定は、セッションのユーザの責任である。
【０１９９】
ユーザは、いつでもＶＭＣセッションを離れることができる。ユーザがセッションを離れるとき、当該セッションの一部であったすべての画像表示窓が閉じられる。そのユーザがセッション・リーダであった場合、待ち行列中の「次の」追従者が、セッション・リーダになる。リーダになるのを待っている追従者がいない場合、リーダはランダムに選ばれる（いずれの瞬間においても、１ユーザがセッション・リーダでなければならない）。
【０２００】
最後のユーザがＶＭＣセッションを離れることによって、当該セッションが終息する。サーバは、終息したセッションについてはいかなる情報も保持しない。
【０２０１】
Ａ‐閲覧クライアント装置
各ユーザがイメージスコープ・ビューアを動作させているコンピュータ。
【０２０２】
Ｂ‐イメージスコープ・ビューア
ＶＭＣセッションのためのクライアント・インターフェイスを実装するアプリケーション・プログラム。
【０２０３】
Ｃ‐ＶＭＣサーバ装置
ＶＭＣサーバ・アプリケーションが動作しているコンピュータ。このコンピュータは、ＶＭＣセッションにおいて閲覧される画像を提供するイメージサーバ装置と同じであってよいが、必ずしも同じである必要はない。
【０２０４】
Ｄ‐ＶＭＣサーバ・プロセス
イメージスコープ・ビューアを一体に相互接続することによってＶＭＣセッションを管理するアプリケーション。各クライアントは、ＴＣＰ／ＩＰによるＨＴＴＰ要求を使用してＶＭＣサーバと通信する。
【０２０５】
Ｅ‐データベース
ＳＱＬデータベース（典型的には、ＭＳＤＥまたはＳＱＬサーバ）が、認証情報を保存する。これがＶＭＣサーバへとアクセスするための認証情報であり、イメージサーバ装置上の画像にアクセスするために必要とされる認証情報と相違していてよいことに、注意すべきである。
【０２０６】
Ｆ‐イメージスコープのＧＵＩスクリーン・マネージャが、各ユーザに彼らのセッションを管理するためのインターフェイスを提供する。ユーザがセッションの「追従者」である場合、当該セッションにおいて開かれている画像の視点移動または拡大縮小あるいは注釈の作成を、行なうことはできない。
【０２０７】
Ｇ‐ＶＭＣインターセプトが、ＧＵＩスクリーン・マネージャと表示域コントローラとの間に位置し、セッション・リーダによって与えられたすべての指令をＶＭＣサーバへと導く。セッションの追従者によって与えられたあらゆる指令は、無視される。さらに、ＶＭＣインターセプトは、セッションの追従者へのＶＭＣサーバからの指令を受信し、あたかもＧＵＩスクリーン・マネージャからのものであるように表示域コントローラへと導く。
【０２０８】
Ｈ‐表示域コントローラは、バーチャルスライドへのすべてのアクセスをカプセル化する。このコントローラのプロパティおよび方法は、ＧＵＩとバーチャルスライドとの間（ならびにＶＭＣセッションとバーチャルスライドとの間）のインターフェイスである。各表示域コントローラが、ＶＭＣセッションの各画像についてイメージサーバへの接続を行なう点、およびそれらの接続がＶＭＣサーバへの接続とは別個である点に、注意すべきである。
【０２０９】
Ｉ‐ＶＭＣサーバ・プログラム内の接続マネージャが、すべてのソケット接続を取り扱い、すべてのクライアント要求を処理する。永続のソケット接続が、各ＶＭＣセッションの動作中のクライアントのそれぞれへと保たれる（通常のＨＴＴＰ  １．１要求と異なり、これらの接続はタイムアウトしない）。これにより、セッション・リーダからの指令を、各追従者のＶＭＣインターセプトへと非同期で送り返すことができる。
【０２１０】
Ｊ‐ＶＭＣセッション・マネージャが、各ＶＭＣセッションにおける指令の流れを制御する（各ＶＭＣサーバ・プロセスが、複数のＶＭＣセッションを同時に管理してもよい）。
【０２１１】
Ｋ‐ＶＭＣセッション・テーブルが、現在のリーダ、すべての画像表示窓の現在の状態、リーダになることを希望する追従者の待ち行列、など、活動中の各ＶＭＣセッションおよび各セッション中のすべてのユーザについて、情報を保存する。
【０２１２】
Ｌ‐接続マネージャの認証レイヤーが、ＶＭＣサーバへと接続する新規ユーザのそれぞれについて認証証明を検証する。この認証は、サーバへのアクセスを可能にし、次いでユーザは、既存のセッションに参加するために正しいパスワードを提示しなければならない。
【０２１３】
Ｍ‐データベース・サービスが、ＶＭＣサーバとデータベースとの間のインターフェイスを提供し、データベースを別個の装置上に配置してもよいようにする。
【０２１４】
Ｘ‐イメージスコープ・クライアント（ＶＭＣインターセプト）とＶＭＣサーバ・プログラムとの間のインターフェイスは、ＴＣＰ／ＩＰによるＨＴＴＰである。各クライアントは、ＶＭＣセッションの間、サーバへの恒久的なソケット接続を有する。セッション・リーダであるクライアントが、サーバへと要求を送信し、応答を受信する。セッションの追従者であるクライアントは、サーバからの要求を受信し、応答を送信する。
【０２１５】
図１０は、本明細書に記載の種々の実施の形態に関連して使用できる典型的なコンピュータ・システム９５０を示したブロック図である。例えば、コンピュータ・システム９５０を、すでに述べたとおりバーチャルスライド・サーバ、ウェブ・サーバ、または閲覧クライアントと関連して使用することができる。しかしながら、当業者にとっては明白であるとおり、他のコンピュータ・システムおよび／またはアーキテクチャも使用可能である。
【０２１６】
コンピュータ・システム９５０は、好ましくは、プロセッサ９５２などの１つ以上のプロセッサを備えている。入／出力を管理するための補助プロセッサ、浮動小数点演算操作を行なうための補助プロセッサ、信号処理アルゴリズムの高速な実行のために適したアーキテクチャを有する特殊目的のマイクロプロセッサ（例えば、デジタル・シグナル・プロセッサ）、主処理システムに従属するスレーブ・プロセッサ（例えば、バックエンド・プロセッサ）、デュアルまたは複数プロセッサ・システムのための追加のマイクロプロセッサまたはコントローラ、あるいはコプロセッサなど、追加のプロセッサを設けてもよい。このような補助的なプロセッサは、別個のプロセッサであってよく、あるいはプロセッサ９５２と統合されてもよい。
【０２１７】
プロセッサ９５２は、好ましくは通信バス９５４に接続される。通信バス９５４は、記憶領域とコンピュータ・システム９５０の他の周辺コンポーネントとの間の情報の伝達を容易にするため、データ・チャネルを含むことができる。さらに、通信バス９５４は、データ・バス、アドレス・バス、および制御バスなど（図示されていない）、プロセッサ９５２との通信に使用される信号一式を提供することができる。通信バス９５４は、例えばインダストリ・スタンダード・アーキテクチャ（「ＩＳＡ」）、拡張インダストリ・スタンダード・アーキテクチャ（「ＥＩＳＡ」）、マイクロ・チャネル・アーキテクチャ（「ＭＣＡ」）、ペリフェラル・コンポーネント・インターコネクト（「ＰＣＩ」）ローカル・バス、あるいはＩＥＥＥ４８８汎用インターフェイス・バス（「ＧＰＩＢ」）やＩＥＥＥ６９６／Ｓ‐１００などの米国電気電子技術者協会（「ＩＥＥＥ」）によって広められた規格に準拠したバス・アーキテクチャなど、任意の標準的または標準的でないバス・アーキテクチャからなることができる。
【０２１８】
コンピュータ・システム９５０は、好ましくは主メモリ９９６を備えており、さらに二次メモリ９５８を備えることができる。主メモリ９９６は、プロセッサ９５２上で動作するプログラムのためのインストラクションおよびデータの記憶領域を提供する。主メモリ９９６は、通常は、ダイナミック・ランダム・アクセス・メモリ（「ＤＲＡＭ」）および／またはスタティック・ランダム・アクセス・メモリ（「ＳＲＡＭ」）などの半導体ベースのメモリである。半導体ベースの他の種類のメモリには、読み出し専用メモリ（「ＲＯＭ」）を含み、シンクロナス・ダイナミック・ランダム・アクセス・メモリ（「ＳＤＲＡＭ」）、ラムバス（Ｒａｍｂｕｓ）ダイナミック・ランダム・アクセス・メモリ（「ＲＤＲＡＭ」）、強誘電体ランダム・アクセス・メモリ（「ＦＲＡＭ」（登録商標））、などがある。
【０２１９】
二次メモリ９５８は、任意により、ハードディスク・ドライブ９６０、および／または例えばフロッピー（登録商標）ディスク・ドライブ、磁気テープ・ドライブ、コンパクトディスク（「ＣＤ」）ドライブ、デジタル多用途ディスク（「ＤＶＤ」）ドライブなどのリムーバブルストレージ・ドライブ９６２を備えることができる。リムーバブルストレージ・ドライブ９６２は、広く知られたやり方で、着脱可能な記憶媒体９６４からの読み出し、および／または着脱可能な記憶媒体９６４への書き込みを行なう。着脱可能な記憶媒体９６４は、例えば、フロッピー（登録商標）ディスク、磁気テープ、ＣＤ、ＤＶＤなどであってよい。
【０２２０】
着脱可能な記憶媒体９６４は、好ましくは、コンピュータで実行可能なコード（すなわち、ソフトウェア）および／またはデータが保存されているコンピュータで読み取り可能な媒体である。着脱可能な記憶媒体９６４に保存されているコンピュータ・ソフトウェアまたはデータは、電気通信信号９７８としてコンピュータ・システム９５０に読み込まれる。
【０２２１】
他の実施の形態においては、二次メモリ９５８が、コンピュータ・プログラムまたは他のデータあるいはインストラクションをコンピュータ・システム９５０へとロードできるようにするための他の同様の手段を備えることができる。そのような手段には、例えば、外部記憶媒体９７２およびインターフェイス９７０が含まれる。外部記憶媒体９７２の例としては、外部のハードディスク・ドライブまたは外部の光学式ドライブ、あるいは外部の光磁気ドライブがある。
【０２２２】
二次メモリ９５８の他の例には、プログラマブル読み出し専用メモリ（「ＰＲＯＭ」）、消去可能プログラマブル読み出し専用メモリ（「ＥＰＲＯＭ」）、電気的に消去可能な読み出し専用メモリ（「ＥＥＰＲＯＭ」）、またはフラッシュメモリ（ＥＥＰＲＯＭに類似するブロック指向のメモリ）など、半導体ベースのメモリが含まれる。さらには、リムーバブルストレージ・ユニット９７２からコンピュータ・システム９５０へとソフトウェアおよびデータを伝送できる他の任意のリムーバブルストレージ・ユニット９７２およびインターフェイス９７０も含まれる。
【０２２３】
さらに、コンピュータ・システム９５０は、通信インターフェイス９７４を含むことができる。通信インターフェイス９７４は、ソフトウェアおよびデータを、コンピュータ・システム９５０と外部の装置（例えば、プリンタ）、ネットワーク、または情報源との間で伝送できるようにする。例えば、コンピュータ・ソフトウェアまたは実行可能コードを、通信インターフェイス９７４を介してネットワーク・サーバからコンピュータ・システム９５０へと伝送することができる。通信インターフェイス９７４の例としては、いくつか例を挙げると、モデム、ネットワーク・インターフェイス・カード（「ＮＩＣ」）、通信ポート、ＰＣＭＣＩＡスロットおよびカード、赤外線インターフェイス、およびＩＥＥＥ１３９４ファイアワイヤ（ｆｉｒｅ‐ｗｉｒｅ）がある。
【０２２４】
通信インターフェイス９７４は、好ましくは、イーサネット（登録商標）ＩＥＥＥ８０２規格、ファイバーチャネル（Ｆｉｂｅｒ  Ｃｈａｎｎｅｌ）、デジタル加入者線（「ＤＳＬ」）、非同期デジタル加入者線（「ＡＤＳＬ」）、フレームリレー、非同期転送モード（「ＡＴＭ」）、総合デジタル・サービス網（「ＩＳＤＮ」）、パーソナル通信サービス（「ＰＣＳ」）、伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）、シリアル線インターネット・プロトコル／ポイント・トゥー・ポイント・プロトコル（「ＳＬＩＰ／ＰＰＰ」）、など、この業界で普及しているプロトコル規格を実装するが、専用または非標準のインターフェイス・プロトコルを実装することも可能である。
【０２２５】
通信インターフェイス９７４を介して伝送されるソフトウェアおよびデータは、一般に、電気通信信号９７８の形式である。これらの信号９７８は、好ましくは、通信チャネル９７６を介して通信インターフェイス９７４へともたらされる。通信チャネル９７６が信号９７８を運ぶが、いくつか例を挙げると、ワイヤまたはケーブル、光ファイバ、従来からの電話線、携帯電話リンク、無線（ＲＦ）リンク、または赤外線リンクなど、種々の通信手段を使用して実装することができる。
【０２２６】
コンピュータで実行可能なコード（すなわち、コンピュータ・プログラムまたはソフトウェア）が、主メモリ９９６および／または二次メモリ９５８に記憶される。さらに、コンピュータ・プログラムを、通信インターフェイス９７４を介して受信して、主メモリ９９６および／または二次メモリ９５８に記憶することができる。そのようなコンピュータ・プログラムを実行することで、コンピュータ・システム９５０は、すでに説明したとおり本発明のさまざまな機能を実行することができる。
【０２２７】
本明細書において、「コンピュータで読み取り可能な媒体」という用語は、コンピュータで実行可能なコード（例えば、ソフトウェアおよびコンピュータ・プログラム）をコンピュータ・システム９５０へともたらすために使用されるあらゆる媒体を指して使用されている。それら媒体の例には、主メモリ９９６、二次メモリ９５８（ハードディスク・ドライブ９６０、リムーバブル記憶媒体９６４、および外部の記憶媒体９７２を含む）、および通信インターフェイス９７４に通信可能に接続される任意の周辺機器（ネットワーク情報サーバまたは他のネットワーク装置を含む）が含まれる。これらコンピュータで読み取り可能な媒体は、コンピュータ・システム９５０に実行可能コード、プログラミング・インストラクション、およびソフトウェアをもたらすための手段である。
【０２２８】
ソフトウェアを使用して実装される一実施の形態においては、当該ソフトウェアをコンピュータで読み取り可能な媒体に保存し、リムーバブルストレージ・ドライブ９６２、インターフェイス９７０、または通信インターフェイス９７４によって、コンピュータ・システム９５０にロードすることができる。そのような実施の形態においては、ソフトウェアが、電気通信信号９７８の形式でコンピュータ・システム９５０へとロードされる。プロセッサ９５２によって実行されるとき、当該ソフトウェアが、本明細書にてすでに説明した本発明の特徴および機能を、プロセッサ９５２に実行せしめる。
【０２２９】
さらに、さまざまな実施の形態を、例えば特定用途向け集積回路（「ＡＳＩＣ」）またはフィールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）などのコンポーネントを使用して、ハードウェア主体で実装することも可能である。本明細書に記載の機能を実行できるハードウェア状態機械の実装も、当業者にとって明らかであろう。さらに、種々の実施の形態を、ハードウェアおよびソフトウェアの両者の組み合わせを使用して実装することも可能である。
【０２３０】
本明細書に示して詳しく説明した特定のシステムおよび方法は、本発明の前記目的を完全に達成することができるが、本明細書に提示した説明および図面が本発明の現時点での好ましい実施の形態を示したものであって、本発明が広く想定する主題の代表であることを、理解すべきである。さらに、本発明の技術的範囲が、当業者にとって自明になるであろう他の実施の形態を完全に包含しており、したがって本発明の技術的範囲は、添付の特許請求の範囲以外のなにものによっても限定されないことを、理解すべきである。
【図１】
0005584193.tif 000002
【図２Ａ】
0005584193.tif 000003
【図２Ｂ】
0005584193.tif 000004
【図２Ｃ】
0005584193.tif 000005
【図２Ｄ】
0005584193.tif 000006
【図３】
0005584193.tif 000007
【図４Ａ】
0005584193.tif 000008
【図４Ｂ】
0005584193.tif 000009
【図４Ｃ】
0005584193.tif 000010
【図４Ｄ】
0005584193.tif 000011
【図４Ｅ】
0005584193.tif 000012
【図４Ｆ】
0005584193.tif 000013
【図４Ｇ】
0005584193.tif 000014
【図５Ａ】
0005584193.tif 000015
【図５Ｂ】
0005584193.tif 000016
【図５Ｃ】
0005584193.tif 000017
【図５Ｄ】
0005584193.tif 000018
【図５Ｅ】
0005584193.tif 000019
【図５Ｆ】
0005584193.tif 000020
【図５Ｇ】
0005584193.tif 000021
【図５Ｈ】
0005584193.tif 000022
【図６Ａ】
0005584193.tif 000023
【図６Ｂ】
0005584193.tif 000024
【図６Ｃ】
0005584193.tif 000025
【図７Ａ】
0005584193.tif 000026
【図７Ｂ】
0005584193.tif 000027
【図７Ｃ】
0005584193.tif 000028
【図８Ａ】
0005584193.tif 000029
【図８Ｂ】
0005584193.tif 000030
【図８Ｃ】
0005584193.tif 000031
【図９Ａ】
0005584193.tif 000032
【図９Ｂ】
0005584193.tif 000033
【図９Ｃ】
0005584193.tif 000034
【図９Ｄ】
0005584193.tif 000035
【図９Ｅ】
0005584193.tif 000036
【図９Ｆ】
0005584193.tif 000037
【図１０】
0005584193.tif 000038