JP2010061678A - バーチャルスライドを閲覧するためのシステムおよび方法 - Google Patents

Abstract

【課題】バーチャルスライドを生成するための優れた線スキャン・システムを導入することにより課される固有の必要性に適合するバーチャルスライド閲覧システムを提供する。
【解決手段】バーチャルスライド画像データおよび対応する情報が、バーチャルスライド画像サーバ３０上のデータ記憶領域５０に保存される。クライアント・ビューア７０が、特定の解像度で画像データを要求する。画像サーバが、要求された解像度に最も近い解像度で、データ記憶領域から対応する画像データを取得する。次いで、この画像データがクライアント・ビューアへと送信される。クライアント・ビューアは、画像データを受信し、この画像データを表示に先立って要求された解像度へと拡大縮小する。
【選択図】図１

Description

本発明は、一般に、コンピュータの支援による大型の画像の閲覧に関し、さらに詳しくは、コンピュータの支援によるバーチャル顕微鏡スライドの閲覧に関する。
本出願は、本出願と同時に係属中である「全自動高速顕微鏡スライド・スキャナ（ＦＵＬＬＹ ＡＵＴＯＭＡＴＩＣ ＲＡＰＩＤ ＭＩＣＲＯＳＣＯＰＥ ＳＬＩＤＥ ＳＣＡＮＮＥＲ）」という名称の米国特許出願第０９／５６３，４３７号の部分継続出願であり、かつ本出願と同時に係属中である「直線アレイ・ベースの顕微鏡スライド・スキャナにおけるデータ管理のためのシステムおよび方法（ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＤＡＴＡ ＭＡＮＡＧＥＭＥＮＴ ＩＮ Ａ ＬＩＮＥＡＲ‐ＡＲＲＡＹ‐ＢＡＳＥＤ ＭＩＣＲＯＳＣＯＰＥ ＳＬＩＤＥ ＳＣＡＮＮＥＲ）」という名称の米国特許出願第１０／３７１，５８６号の部分継続出願であって、２００３年２月２８日付の米国特許仮出願第６０／４５１，０７９号および２００３年７月９日付の米国特許仮出願第６０／４８５，８７３号の優先権を主張している。これらの出願のそれぞれは、その全体がここで参照によって本明細書に組み込まれるものとする。

大視野バーチャル顕微鏡観察において、乗り越えるべき最初の課題は、顕微鏡スライドのデジタル画像化（「スキャン」）に関連していた。従来からの画像タイル法が、バーチャル顕微鏡業界で広く普及している手法の１つである。顕微鏡スライドをスキャンするための画像タイル法では、面積固定の電荷結合素子（「ＣＣＤ」）カメラを使用し、顕微鏡スライドにおいて隣り合う領域について、数百または数千の別個独立の画像（「画像タイル」）を撮影する。これらの画像タイルがコンピュータに保存されるとともに、各画像タイルの名前および大型画像内におけるそれらの位置を特定するために、インデックスが使用される。従来からの画像タイル法が、米国特許第６，１０１，２６５号に説明されている。速度が遅くかつ扱いにくいものではあるが、従来からの画像タイル法は、バーチャルスライド生成のための顕微鏡スライドのスキャンにおいて、成功を収めた。

ひとたびバーチャルスライドがコンピュータ・システム内に収められると、数千の画像タイルという固有の性質ゆえ、スライドの各部位の閲覧は比較的単純である。ユーザは、バーチャルスライドの或る部位を閲覧したいと望む場合、その部位を選択するだけでよく、システムが対応する個々の画像タイルを認識し、それらのタイルを表示することができる。このように、バーチャル顕微鏡観察における閲覧の局面は、従来からの画像タイル法にとってそれほど困難ではなかった。

とくに、新規な直線アレイ・ベースの線スキャン法が、アペリオ・テクノロジーズ社（Ａｐｅｒｉｏ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）によって開発されている。この手法は、「全自動高速顕微鏡スライド・スキャナ（Ｆｕｌｌｙ Ａｕｔｏｍａｔｉｃ Ｒａｐｉｄ Ｍｉｃｒｏｓｃｏｐｅ Ｓｌｉｄｅ Ｓｃａｎｎｅｒ）」という名称の米国特許第 号に記載されているように、直線アレイの検出器を専用の光学系と組み合わせて使用しており、スキャンスコープ（ＳｃａｎＳｃｏｐｅ（登録商標））という名称で現在市販されている。

さらに最近では、バーチャル顕微鏡観察産業に、バーチャルスライドを生成するためのきわめて優れたシステムが導入されている。アペリオ・テクノロジーズ社が、今や、米国特許第 号に記載の直線アレイ・ベースの線スキャン法を提供している。この革新的な線スキャン法によって、バーチャルスライドの生成のための時間が、数時間から数分へと短縮される。高速なデータ取得に加え、線スキャンは、一貫して優れた画像データを確保する幾つかの利点からも利益をもたらす。第１に、画像タイルの全体が必然的にただ１つの焦点面に制限される画像タイル・システムと対照的に、直線アレイの焦点を、或る１つの線から次の線へと調節することが可能である。第２に、線スキャン・システムにおける直線アレイ・センサは一次元であるため、スキャン軸に沿った光学収差が存在しない。画像タイル・システムにおいては、光学収差が、画像タイルの中央を中心として環状に対称である。第３に、非隣接ピクセルからの色値を（例えばベイヤー・マスク（Ｂａｙｅｒ Ｍａｓｋ）を使用して）補間しなければならないために空間分解能を喪失してしまうカラーＣＣＤカメラと異なり、直線アレイ・センサは、完全な（１００％の）開口率（ｆｉｌｌ ｆａｃｔｏｒ）を有しており、完全なピクセル分解能（色チャネルごとに８ビット）をもたらす。

線スキャン法によってもたらされる他の大きな進歩は、従来からの画像タイル・システムが数千もの別個独立の画像タイルを生成するのとまったく対照的に、バーチャルスライドがコンピュータ・システム上のただ１つの画像ファイルに含まれるという点にある。１つのバーチャルスライドについてただ１つの画像ファイルを管理すればよいため、数千もの別個独立の画像タイルを対応するインデックスとともに管理することに比べ、オペレーティング・システムに必要とされるオーバヘッドがきわめて小さくなる。しかしながら、１つのバーチャルスライドについて画像ファイルをただ１つ生成するということは、きわめて効率的であって要する時間も少ない反面、それらバーチャルスライドの閲覧に関して、挑戦すべき新たな困難を生じさせる。画像タイルのサイズが１ＭＢ程度であるのと対照的に、線スキャナによって生成されるバーチャルスライド・ファイルは、４ギガバイト（「ＧＢ」）にもなる可能性がある。

したがって、バーチャルスライドを生成するための優れた線スキャン・システムを導入することにより、この新規な技法によって課される固有の必要性に適合するバーチャルスライド閲覧システムおよび閲覧方法に対するニーズが、この業界において生じている。

本発明は、大量の視覚画像データについて、スタンドアロン装置での閲覧あるいは構内または広域通信網を介しての閲覧を容易にするバーチャルスライド画像ファイル・フォーマットを提供する。バーチャルスライド画像データおよび対応する情報が、バーチャルスライド画像データおよび対応する情報への高性能なアクセスを提供するバーチャルスライド画像サーバ上のデータ記憶領域に保存される。バーチャルスライド画像データを効率的に表示および操作するように構成されたクライアント・ビューアが、特定の解像度で画像データを要求する。画像サーバが、要求された解像度に最も近い解像度で、データ記憶領域から対応する画像データを取得する。次いで、この画像データがクライアント・ビューアへと送信される。バーチャルスライド・クライアント・ビューアは、バーチャルスライド画像データを保存された解像度で受信し、次いでこの画像データを閲覧のため適切な解像度へと拡大縮小する。したがって、ベースライン解像度でスキャンされたバーチャルスライド画像を、より高い任意の解像度で画像の忠実度を損なうことなく閲覧することができる。さらに、ウェブ・ベースのシステムも提供される。

さらに、バーチャルスライド画像サーバは、リーダ・クライアント・ビューアおよび幾つかの参加者クライアント・ビューアによるバーチャルスライドの同時協働閲覧を容易にする。参加者クライアント・ビューアは、閲覧するバーチャルスライドの操作について制限されているが、協働セッションのリーダは、リーダの役割を参加者クライアント・ビューアに引き継ぐことができ、引き継ぎののち、新たなリーダが閲覧の制御を行なうことができ、先のリーダは参加者クライアントへと格下げされる。

さらに本発明は、バーチャルスライドの三次元閲覧を提供する。顕微鏡スライドの標本が、複数の垂直レベルでスキャンされ、それぞれの垂直レベルについて別個のバーチャルスライド画像が生成される。この複合バーチャルスライド画像の閲覧が要求され、要求されたレベルが２つのスキャン・レベルの間にあるとき、要求された閲覧レベルを画像の忠実度を損なうことなく生成するため、直上のレベルおよび直下のレベルが補間される。さらに、直上のレベルの画像の画像ピクセルを第１の方向にずらすとともに直下のレベルの画像の画像ピクセルを反対方向にずらして、要求されたレベルについてスキューされた画像を提供することによって、三次元閲覧を提供することができ、複合画像の三次元閲覧が可能である。

本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なシステムを示したネットワーク図である。 本発明の一実施の形態による典型的なバーチャルスライド・サーバを示したブロック図である。 本発明の一実施の形態による典型的なバーチャルスライド・モジュールを示したブロック図である。 本発明の一実施の形態に従ってバーチャルスライド画像のブロックの要求を取り扱うための典型的なプロセスを示したフロー図である。 本発明の一実施の形態に従ってバーチャルスライド画像のサブ領域の要求を取り扱うための典型的なプロセスを示したフロー図である。 本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なウェブ・サーバを示したネットワーク図である。 本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による種々の解像度レベルを含む典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。 本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを、種々の解像度レベルとの関連について示したブロック図である。 本発明の一実施の形態による典型的なクライアント・ビューアを示したブロック図である。 本発明の一実施の形態による典型的な表示域コントローラを示したブロック図である。 本発明の一実施の形態による典型的なレンダリング・エンジンを示したブロック図である。 本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。 本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。 本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。 本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。 本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。 本発明の一実施の形態による典型的な注釈モジュールを示したブロック図である。 本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。 本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。 本発明の一実施の形態による典型的なバーチャル顕微鏡カンファレンス閲 覧システムを示したネットワーク図である。 本発明の一実施の形態によるバーチャル顕微鏡カンファレンスのための典型的なバーチャルスライド・サーバを示したブロック図である。 本発明の一実施の形態による典型的なバーチャル顕微鏡カンファレンス・クライアント示したスクリーンショットである。 本発明の一実施の形態による典型的な三次元バーチャルスライドを示したブロック図である。 本発明の一実施の形態による典型的なスキュー済み三次元バーチャルスライドを示したブロック図である。 本発明の一実施の形態による典型的な三次元バーチャルスライド閲覧ウインドウを示したスクリーンショットである。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。 本明細書に記載の種々の実施の形態に関連して使用できる典型的なコンピュータ・システムを示したブロック図である。

添付の図面を検討することによって、本発明の詳細を、その構成および動作の両者に関して或る程度学ぶことができるであろう。添付の図面において、同様の参照番号は同様な部分を指し示している。

本明細書に開示する或る幾つかの実施の形態は、ファイル・サイズが４ＧＢにもなるきわめて大きな画像（１００ＧＢにもなる圧縮前の生の画像データを含んでいる）であるバーチャル顕微鏡スライドを閲覧するためのシステムおよび方法を提供する。本発明は、このような大型の画像ファイルにアクセスし、対応する画像データをローカルまたはリモートの閲覧用ステーションに表示するための高速かつ効率的なシステムおよび方法を提供する。例えば、本明細書に開示の一方法によれば、クライアント・ビューアが、バーチャルスライド画像ファイルからの画像データを特定の解像度で要求できる。サーバ・システムが、要求された解像度に近い解像度にある画像データを含んでいる画像データの圧縮済みブロックを取得し、このデータ・ブロックをクライアントへと送信する。次いで、クライアントは、この画像データを拡大縮小し、要求された解像度で画像を提示する。

当業者であれば、この説明を読むことによって、他のさまざまな実施の形態および他のさまざまな用途において本発明をどのように実行するのかを、理解できるであろう。本発明の種々の実施の形態を本明細書にて説明するが、これらの実施の形態があくまで例であって、本発明を限定するものではないことを理解すべきである。すなわち、種々の代替となる実施の形態についてここで詳細に説明するが、それらを添付の特許請求の範囲に記載される本発明の技術的範囲を制限するものとして解釈すべきではない。

図１は、本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なシステム１０を示したネットワーク図である。図示の実施の形態において、システム１０は、クライアント・ビューア７０およびウェブ・ビューア８０にネットワーク６０を介して通信可能に接続したバーチャルスライド・サーバ３０を有している。複数のクライアント・ビューア７０が存在してもよく、複数のウェブ・ビューア８０が存在してもよい。さらに、システム１０がウェブ・サーバ４０を備えていてもよい。図示のとおり、ウェブ・サーバ４０は別個独立であってよく、あるいは複合サーバ２０としてバーチャルスライド・サーバと同じ場所に位置してもよい。複合サーバ５０は、データ記憶領域５０を備えて構成される。あるいは、バーチャルスライド・サーバ３０がウェブ・サーバ４０と別個独立である場合には、別個のサーバのそれぞれが、好ましくは自身のデータ記憶領域（図示されていない）を備えて構成される。そのような実施の形態においては、バーチャルスライド・サーバ３０が、バーチャルスライド画像データを保存する（他のデータとともに）ためのデータ記憶領域を有することができ、ウェブ・サーバ４０が、ウェブページ・データを保存する（他のデータとともに）ためのデータ記憶領域を有することができる。

クライアント・ビューア７０も、データ記憶領域７２を備えて構成される。このデータ記憶領域は、好ましくはバーチャルスライド画像、ならびにバーチャルスライドの閲覧を容易にするための他のデータまたは情報を、ローカルに保存するために使用することができる。ウェブ・ビューア８０は、キャッシュが好ましくはローカルのディスク式記憶装置ではなくコンピュータのメモリを使用して実行されるため、データ記憶領域を必要としない。他の実施の形態においては、データ記憶領域を備えてもよい。

ネットワーク６０は、種々ある任意のネットワーク形態および物理層を含むことができる。例えば、ネットワーク６０は、構内通信網（「ＬＡＮ」）、広域通信網（「ＷＡＮ」）、無線広域通信網（「ＷＷＡＮ」）、またはインターネットなどのネットワークの組み合わせであってよい。さらに、ネットワーク６０は、ＴＣＰ／ＩＰなどのさまざまな通信プロトコルを使用でき、ＨＴＴＰなどのアプリケーション・プロトコルを使用することができる。

図２Ａは、本発明の一実施の形態による典型的なバーチャルスライド・サーバ２０を示したブロック図である。図示の実施の形態においては、バーチャルスライド・サーバ２０が、接続モジュール１００、バーチャルスライド・モジュール１１０、注釈モジュール１６０、認証モジュール１３０、およびデータベース・モジュール１４０を有している。このサーバ２０は、データ記憶領域５０を備えて構成されている。代案として、データ記憶領域５０を、データ記憶領域１２０とデータ記憶領域１５０など、２つ以上の別個のデータ記憶領域へと物理的または論理的（あるいは両方）に分割することができる。データ記憶領域１２０が、バーチャルスライド画像データを含んでおり、データ記憶領域１５０が、注釈およびユーザ認証情報、ならびにおそらくはバーチャルスライド状況情報などの他の管理上のデータを含んでいる。

接続モジュール１００は、好ましくは、クライアント・ビューアまたはウェブ・ビューアからの要求を受信するように構成されている。要求によって、情報または画像データあるいは両者を求めることができる。さらに、要求によって、認証情報または注釈情報などの情報をもたらすことができる。別個に図示されているが、注釈モジュール１６０および認証モジュール１３０は、接続モジュール１００の一部であってよい。

バーチャルスライド画像に関する要求は、接続モジュール１００によって、バーチャルスライド・モジュール１１０へと導かれる。バーチャルスライド・モジュールは、データ記憶領域１２０から画像データを取得し、この画像データを必要に応じて処理し、要求元のビューア（クライアント・ビューアまたはウェブ・ビューア）へと応答を送り返す。さらに、バーチャルスライド・モジュールは、注釈モジュール１６０と通信し、バーチャルスライド画像に注釈の重ね合わせをもたらすことができる。注釈モジュール１６０は、種々のバーチャルスライド画像についての注釈を、別個のレイヤーにて保持しており、バーチャルスライド・モジュール１１０と関連して、注釈の生成および変更ならびに注釈レイヤーの表示を容易にする。

認証モジュール１３０は、要求を送信しているビューアを検証するように構成されている。認証モジュール１３０は、秘密に属するバーチャルスライド画像データおよび／または関連のデータベース情報が、権限のない要求元ビューアへと誤って提供されてしまうことがないよう、ユーザおよびパスワードまたは他の認証情報（例えば、ＩＰアドレス）についてのデータベースを保持できる。このデータベースは、データ記憶領域１５０内に保持できる。データ記憶領域１５０内にデータを保存するさまざまなモジュールは、データベース・モジュール１４０を介して当該データにアクセスできる。一実施の形態においては、モジュールが、従来からのファイル・システムにてデータ記憶領域１５０にデータを保存でき、したがって実際のデータベース構造のオーバヘッドを必要としない。しかしながら、データ記憶領域１５０と関連してデータベースを使用することによって、或る幾つかの利点および最適化を実現することができ、そのような場合、データベース・モジュール１４０によって、照会、取り出し、および保存などのデータベースとの通信を、容易にすることができる。

図２Ｂは、本発明の一実施の形態による典型的なバーチャルスライド・モジュール１１０を示したブロック図である。図示の実施の形態においては、バーチャルスライド・モジュール１１０は、要求ハンドラ１７０、入出力（「Ｉ／Ｏ」）モジュール１７２、１つ以上のデータ符号器／復号器（「コーデック」）１７４、および画像キャッシュ１７６を含んでいる。Ｉ／Ｏモジュール１７２が、データ記憶領域１２０にアクセスし、バーチャルスライド画像データおよび他の関連のバーチャルスライド情報の取り出しおよび保存を行なう。例えば、バーチャルスライド画像データの要求に応じ、Ｉ／Ｏモジュール１７２によってデータ記憶領域１２０からの取り出しが行なわれる。さらに、バーチャルスライド画像について直角回転または新規に拡大縮小（スケーリング）されたレベルを、Ｉ／Ｏモジュール１７２によって画像キャッシュ１７６に保存することができる。

要求ハンドラは、受信した要求の種類を特定するように構成されている。例えば、要求は、バーチャルスライド画像の特定のブロックを要求するものであってよく、あるいはバーチャルスライド画像の特定のサブ領域を要求するものであってよい。要求は、バーチャルスライドについての情報を要求するものであってもよい。バーチャルスライド画像ファイルのブロックとサブ領域との間の相違は、図４Ａ〜４Ｆに関して後で詳しく説明するとおり、バーチャルスライド画像ファイルの構造にもとづいている。しかしながら、基本的には、ブロックは、保存されたバーチャルスライド画像のファイル構造に固有の所定のデータ・ブロックである。一方、サブ領域は、バーチャルスライド画像の任意の領域であって、ただ１つのブロックまたは２つ以上のブロックの任意の組み合わせからなる部分集合であってよい。したがって、ブロックの読み出しがきわめて効率的である一方で、サブ領域の読み出しおよび構成は、プロセッサをより多く使用する。

コーデック１７４は、好ましくは、種々さまざまな圧縮技法を実行するように構成されている。好ましい実施の形態においては、バーチャルスライド画像ファイルについてＪＰＥＧ２０００圧縮が使用され、したがってコーデック１７４が、ＪＰＥＧ２０００の規格に従って圧縮および解凍を行なうように構成されている。さらに、コーデック１７４を、ＪＰＥＧおよびレンペル‐ジブ‐ウェルチ（Ｌｅｍｐｅｌ‐Ｚｉｖ Ｗｅｌｃｈ）（「ＬＺＷ」）の圧縮の規格、ならびに他の可逆および不可逆の画像圧縮技法に従って圧縮および解凍を行なうように構成してもよい。バーチャルスライド・モジュール１１０は、複数の圧縮技法を同時にサポートすることができ、その場合、画像の属性にもとづいて選択されるコーデック１７４の複数のインスタンスが存在するであろう。

キャッシュ１７６は、ただ１つの物理的なキャッシュとして、あるいは複数の別個の物理的なキャッシュとして、実装することができる。一実施の形態においては、画像ブロックのためのキャッシュ、画像サブ領域のためのキャッシュ、およびバーチャルスライド情報のためのキャッシュなど、論理的に別個である複数のキャッシュが、バーチャルスライド・モジュール１１０によって使用される。

図２Ｃは、本発明の一実施の形態に従ってバーチャルスライド画像のブロックの要求を取り扱うための典型的なプロセスを示したフロー図である。最初に、ステップ１７８において、バーチャルスライド・モジュールが、クライアント・ビューアからの要求を受信する。要求は、要求ハンドラによって受信され、処理のためにＩ／Ｏモジュールへと渡される。ステップ１８０において、Ｉ／Ｏモジュールが、要求されたブロックをデータ記憶領域から取り出し、当該ブロックを要求ハンドラへと返す。あるいは、画像データがキャッシュにあるかどうかを調べるため、Ｉ／Ｏモジュールが、最初にキャッシュをチェックしてもよい。次に、要求ハンドラは、要求されたブロックをステップ１８２において要求元のビューアへと送り返し、さらにステップ１８４に示されているとおり、要求されたブロックをブロック・キャッシュに保存する。

さらに、要求ハンドラまたはＩ／Ｏモジュールが、要求されるであろう隣接または他のブロックの可能性を判断するため、予測機能を実行してもよい。この可能性が或る閾値を超えると判断される場合、その特定されたブロックを、要求を先取りすべくＩ／Ｏモジュールによってデータ記憶領域からあらかじめ読み出し、一時的にブロック・キャッシュに配置することができる。このような先読み機能によれば、閲覧システムの動作全体を大幅に改善することができ好都合である。この先読みの予測機能は、それまでの要求およびユーザのアクセスのパターンにもとづく経験則を実装することができる。

図２Ｄは、本発明の一実施の形態に従ってバーチャルスライド画像のサブ領域の要求を取り扱うための典型的なプロセスを示したフロー図である。ステップ１８８において、要求ハンドラが要求を受信し、その要求をデータの取り出しのためＩ／Ｏモジュールへと渡す。ステップ１９０に示すとおり、Ｉ／Ｏモジュールが、当該サブ領域の構築に必要とされる１つまたは複数のブロックを、キャッシュまたはデータ記憶領域から取り出す。１つまたは複数のブロックが入手されると、ステップ１９２でサブ領域が構築され、ステップ１９４でサブ領域のフォーマットが変換される。

画像データをウェブ・ビューアへと提供するときに、特定のウェブ・ビューア・クライアントが本来のフォーマット（例えばＪＰＥＧ２０００）に対応しない場合に、サブ領域のフォーマットの変換は必要になることが多い。圧縮形式の他に、画像データの拡大縮小、画像データの変形（回転または反転）、色の補正、コンボリューションマトリクスの適用、などのため、さらなる変換を実行してもよい。これらのステップは、すべて要求元クライアントの代理として要求ハンドラによって実行することができる。さらに、他の実施の形態においては、画像データの変換によってサブ領域を構築するステップを、本閲覧システムにおいて要求側に位置するクライアント・ビューアのプログラムによって好都合に実行することができる。したがって、サブ領域の構築および変換のステップは、より効率的であるブロック・レベルの画像を要求および処理することができないウェブ・ビューア・クライアントまたは他のビューア・クライアントから要求を受け取った場合にのみ、必要とすることができる。

ひとたびサブ領域が構築されて、画像が（必要であれば）変換されると、得られたサブ領域が、ステップ１９６に示すとおり、要求元のビューアへと送信される。サブ領域が送信されると、バーチャルスライド・モジュールは、好ましくはステップ１９８に示すとおり、当該サブ領域をサブ領域キャッシュに保存する。

図３は、本発明の一実施の形態に従ってバーチャルスライド画像を閲覧するための典型的なウェブ・サーバ４０を示したネットワーク図である。図示の実施の形態においては、ウェブ・ビューア・クライアント８０が、ネットワーク（図示されていない）を介してウェブ・サーバ４０に通信可能に接続されている。好都合なことに、ウェブ・ビューア・クライアントは、特別なソフトウェア・モジュールを必要とせず標準的なウェブ・ブラウザ２１０を備えているだけである。

ウェブ・サーバ４０は、コモン・ゲートウェイ・インターフェイス（「ＣＧＩ」）２２０、ウェブ・ビューア２３０、およびＨＴＭＬビルダを有している。一実施の形態においては、ＨＴＭＬビルダを、ウェブ・ビューア２３０の一部として実装できる。さらに、図示の実施の形態には、バーチャルスライドに関する画像データおよび他の情報を保持および提供するバーチャルスライド・サーバ３０が示されている。

図示のとおり、ウェブ・ビューア８０がウェブ・サーバ４０へとＨＴＴＰ要求を送信して、バーチャルスライドを要求する。ＣＧＩ２２０が、この要求を受信してウェブ・ビューア２３０に渡し、ウェブ・ビューア２３０が、対応するバーチャルスライド要求を、ＨＴＴＰ要求によってバーチャルスライド・サーバ３０へと送信する。バーチャルスライド・サーバ３０は、画像情報を含んでなるＨＴＴＰ応答によって、この要求に応答する。ウェブ・サーバ４０へのＨＴＴＰ応答は、実際の画像データは含んでおらず、画像属性などの他の情報を含んでいる。バーチャルスライド・サーバ３０からＨＴＴＰ応答を受信したのち、ウェブ・サーバ４０において、ウェブ・ビューア２３０がＨＴＴＰビルダ２４０と協働し、ウェブ・ビューア８０のためのＨＴＴＰ応答を構築する。好ましくは、ＨＴＴＰ応答が、バーチャルスライド画像を表示するためのＨＴＭＬの枠組みをウェブ・ブラウザ２１０に提供するとともに、本来の画像データ（例えば、ＪＰＥＧ）についての画像タグ参照を含んでいる。ウェブ・ブラウザ２１０は、ウェブ・サーバ４０からのＨＴＴＰ応答を処理する際に画像タグ参照を発見し、これに従ってウェブ・ビューア８０に、画像データを求めるＨＴＴＰ要求をバーチャルスライド・サーバ３０へと送信させる。ウェブ・ビューア８０からの要求に応じ、バーチャルスライド・サーバが、画像データをウェブ・ブラウザ２１０によって表示できるフォーマットで送信する。

図４Ａは、本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマット２５０を示したブロック図である。バーチャルスライド画像ファイルが複数の画像を含んでおり、これら複数の画像はそれぞれ、バーチャルスライドの全体についての異なる解像度での画像である。一実施の形態においては、バーチャルスライドを閲覧する際により効率的な拡大縮小の入手を提供するため、バーチャルスライドが生成されるときに、中間レベルの画像もいくつか生成され、バーチャルスライド画像ファイルに保存される。

図示の実施の形態においては、ファイル・フォーマットが、ヘッダ２６０およびチェックサム３１０を含んでいる。チェックサム３１０は、任意であってよい。一実施の形態においては、バーチャルスライド画像が大きく、全画像についてチェックサムを計算することが現実的でないため、チェックサムをブロック・レベルに使用することができる。さらに、ブロック・レベルにおける他の検証または保全も、使用することができる。ヘッダは、好ましくはファイル情報およびベースライン画像２７０への参照を含んでおり、ベースライン画像２７０は、バーチャルスライド画像を線スキャナ装置から受け取ったままの本来の解像度で含んでいる。一実施の形態においては、ファイルにおいてベースライン画像２７０の次に、バーチャルスライド全体の低解像度のサムネイル画像を含んでいるサムネイル画像２８０が続いている。同様に、ファイルにおいてサムネイル画像２８０の次には、ベースレベルから作られた中間画像のすべてについて、中間画像レベル２９０が続き、さらに中間レベル２９１が続き、以下同様である。

ベースライン画像２７０および中間レベル画像２９０、２９１は、ランダム・アクセスを容易にするため、ブロックの連続として組織されている。個々のブロックを圧縮してもよい。好ましくは、ブロックは、ＪＰＥＧ２０００の規格に従って圧縮される。代案として、あるいはこれに加えて、個々のブロックをＪＰＥＧ規格に従って圧縮してもよく、あるいはＬＺＷ（可逆）符号化によって圧縮してもよい。さらに、個々のブロックが、画像の完全性を検証すべく使用されるチェックサムを含んでもよく、さらに／あるいは元の圧縮なしの画像データからの平均二乗平均平方根（「ＲＭＳ」）または平均三乗平均立方根（「ＲＭＣ」）距離など、圧縮後の画像の忠実度についての指標を含んでもよい。

一実施の形態においては、バーチャルスライド画像ファイル・フォーマットが、ここでの参照によってその全体が本明細書に組み込まれる１９９２年６月３日付の最終のＴＩＦＦ規格、リビジョン６．０に記載のファイル・フォーマットに、事実上合致している。

図４Ｂ〜Ｆは、ファイル中に種々の解像度レベルを含んでなる本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを示したブロック図である。図から理解されるように、ベースライン画像の種々のレベルを解像度が小さくなっていく順序で垂直に積層させたとき、ピラミッドが形成される。図４Ｂに示すとおり、ピラミッドの底部はベースライン画像２７０である。次のレベルは、図４Ｃに示すとおり中間画像２９０である。中間画像２９０は、バーチャルスライド中の他のすべての解像度のなかで、最もベースライン解像度に近いバーチャルスライド画像である。図４Ｄは、ピラミッドにおいてベースライン画像および第１の中間レベル画像の上方に位置する第２の中間レベル画像２９１を示している。任意の数の中間画像を含むことができる。例えば、一実施の形態においては、隣り合う中間画像が、それぞれ先の画像の１／４の解像度を有している。最後に、図４Ｅにおいて、サムネイル画像２８０が、バーチャルスライド画像ファイルを構成する画像のピラミッドの最上部に位置している。これら種々のレベルの解像度およびそれらに対応するバーチャルスライド・ファイル中の各画像によって、バーチャルスライドの閲覧時に、解像度レベルをまたがるより効率的な拡大縮小を、好都合に提供できる。

例えば、図４Ｆは、第２の中間レベル画像２９１とサムネイル画像２８０との間にある現在閲覧中のレベル３２０を示している。一実施の形態においては、ビューアが現在の閲覧レベル３２０の解像度でのバーチャルスライドの閲覧を選択したとき、バーチャルスライド・サーバは、クライアント・ビューアへと第２の中間レベル画像２９１からの１つ以上のブロックを提供でき、クライアント・ビューアが、それらを現在の閲覧レベルの解像度へと縮小（スケールダウン）することができる。他の実施の形態においては、ビューアが現在の閲覧レベル３２０の解像度でバーチャルスライドを閲覧することを選択したとき、バーチャルスライド・サーバが、より低い解像度レベルの画像をクライアント・ビューアへと提供でき、クライアント・ビューアが、それを現在の閲覧レベルの解像度へと拡大（スケールアップ）することができる。好ましくは、画像の忠実度を保つため、より高解像度の画像が縮小される。または、バーチャルスライド・サーバは相互レベル補間を実行できる。一実施の形態においては、バーチャルスライドの種々の解像度レベルにまたがっての高速な拡大縮小をさらに改善するため、補間によって中間レベルを得たのち、当該新しいレベルを、ビューアまたはサーバのキャッシュに加えることができる。或る状況においては、最初のレンダリングの後に現在の閲覧をディスクに保存するよりもむしろ、現在の閲覧レベルを後続の第２の時に再度解釈し、後の第２の閲覧のために保存された画像を後に取り出すことがより効率的であり得る。

図４Ｇは、本発明の一実施の形態による典型的なバーチャルスライド・ファイル・フォーマットを、種々の解像度レベルとの関連について示したブロック図である。

図５Ａは、本発明の一実施の形態による典型的なクライアント・ビューア７０を示したブロック図である。クライアント・ビューア７０は、ネットワークを介してバーチャルスライド・サーバと通信可能に接続され、あるいは場合によってはコンピュータ・ケーブルなどで直接接続されるリモート装置上で動作するアプリケーションである。図示の実施の形態においては、クライアント・ビューア７０は、グラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）ハンドラ３５０、バーチャル顕微鏡カンファレンス（ｖｉｒｔｕａｌ ｍｉｃｒｏｓｃｏｐｙ ｃｏｎｆｅｒｅｎｃｉｎｇ）（「ＶＭＣ」）モジュール３６０、および表示域コントローラ（ｖｉｅｗｐｏｒｔ ｃｏｎｔｒｏｌ）３７０を有している。

ＧＵＩハンドラ３５０は、ウインドウおよびそれらウインドウの中身の閲覧装置上への表示を管理する。さらに、ＧＵＩハンドラ３５０は、クライアント・ビューア７０へのすべてのキーボードおよびマウス入力を管理する。ＶＭＣモジュール３６０は、図７Ａ〜７Ｂに関して後に詳述するバーチャル顕微鏡カンファレンス・セッションのために使用される。表示域コントローラ３７０は、ローカルのバーチャルスライド・ファイルへの直接アクセスを介し、あるいはすでに述べたとおりバーチャルスライド・サーバへのリモート・アクセスを介するバーチャルスライドについてのすべてのやり取りを管理する。

図５Ｂは、本発明の一実施の形態による典型的な表示域コントローラ３７０を示したブロック図である。図示の実施の形態では、表示域コントローラが、注釈コントローラ４００、レンダリング・エンジン４２０、先読み器４３０、Ｉ／Ｏモジュール４４０、通信モジュール４５０、１つ以上のコーデック４６０、およびキャッシュ４７０を有している。

注釈コントローラ４００は、新規注釈の追加、注釈の削除、種々の注釈レイヤーの提示などの注釈要求を処理する。レンダリング・エンジン４２０は、バーチャルスライド画像データの表示および操作を管理する。レンダリング・エンジン４２０は、バーチャルスライド画像についてバーチャルスライド内の任意の位置、任意の寸法、および任意の解像度で可能な限り良好な閲覧を提供するため、キャッシュされた画像データを使用するように構成されている。より多くのデータがバーチャルスライド・サーバから受信されるとき、レンダリング・エンジン４２０は、画像を向上させるべく現在表示されている画像を好都合に更新する。

先読み器４３０は、バーチャルスライドの画像データを、レンダリング・エンジン４２０からの要求を先取りして動的に取り出す。先読み器４３０は、表示域コントローラ３７０によって表示されたバーチャルスライドにおけるユーザのナビゲーション動作を追跡し、バーチャルスライド画像の特定の方向への動きを判断する。これにより、先読み器４３０は、スライドの動きの方向に従って画像データを取り出し、レンダリング・エンジン４２０によって要求される画像データを先取りする。

Ｉ／Ｏモジュール４４０は、ローカル・データ記憶領域（図示せず）からのバーチャルスライド・データについてのすべての要求を処理する。好都合には、ローカル・クライアント・ビューアは、スタンドアロンでバーチャルスライドを閲覧できるよう、画像データをローカルに記憶することができる。これらの画像は、好ましくは、Ｉ／Ｏモジュール４４０によってアクセス可能なローカル・データ記憶領域に保存される。通信モジュール４５０は、バーチャルスライド・サーバとのネットワーク通信を取り扱う。好ましくは、通信モジュール４５０は、先読み器４３０、レンダリング・エンジン４２０、および表示域コントローラ３７０の他のコンポーネント、ならびにクライアント・ビューアと協働し、バーチャルスライド・サーバのデータおよび情報にアクセスする。さらに、通信モジュール４５０は、好ましくは、注釈コントローラ４００と協働し、バーチャルスライド・サーバに新規の注釈、注釈の変更、および注釈の削除を提供する。

さらに、表示域コントローラは、好ましくは種々さまざまな圧縮および解凍技法を実行するように構成された１つ以上のコーデック４６０を有している。好ましい実施の形態においては、バーチャルスライド画像ファイルについてＪＰＥＧ２０００圧縮が使用され、したがってコーデック４６０は、ＪＰＥＧ２０００の規格に従って圧縮および解凍を実行するように構成されている。さらに、コーデック４６０を、ＪＰＥＧおよびレンペル‐ジブ‐ウェルチ（「ＬＺＷ」）の圧縮規格に従って圧縮および解凍を実行するように構成してもよい。表示域コントローラは、複数の圧縮技法を同時にサポートすることができ、その場合、画像の属性にもとづいて選択されるコーデック４６０の複数のインスタンスが存在するであろう。

最後に、表示域コントローラは、キャッシュ４７０を有している。キャッシュ４７０は、ただ１つの物理的なキャッシュとして、あるいは複数の別個の物理的なキャッシュとして、実装することができる。一実施の形態においては、ブロックのためのキャッシュ、画像サブ領域のためのキャッシュ、およびバーチャルスライド情報のためのキャッシュなど、論理的に別個である複数のキャッシュが、表示域コントローラ３７０によって使用される。Ｉ／Ｏモジュール４４０が、データをローカル・ディスクまたはリモート・サーバから取り出す前に、ブロックおよび／または画像データについて適切なキャッシュ４７０をチェックするとともに、新たに取り出したデータでキャッシュを更新する。

図５Ｃは、本発明の一実施の形態による典型的なレンダリング・エンジン４２０を示したブロック図である。レンダリング・エンジン４２０は、表示域コントローラの主要コンポーネントであり、ガンマ調節器５００、フィルタ処理モジュール５１０、拡大縮小（スケーリング）モジュール５２０、および変形モジュール５３０を有している。

ガンマ調節器５００は、画像データ内の赤‐緑‐青（「ＲＧＢ」）値の実際にモニタ上に表示されるピクセルへのカラーマッピングについて、リアルタイムでの調節を提供する。この能力の利点は、バーチャルスライドを閲覧するときに環境光およびモニタ特性の相違を補償できる点にある。フィルタ処理モジュール５１０は、所定またはユーザ指定のコンボリューションマトリクスを画像データに適用することによって、バーチャルスライド画像データのフィルタ処理を可能にし、コントラストの強調、エッジの鮮鋭化、および他の画像処理能力を提供する。

拡大縮小モジュール５２０は、画像の忠実度の喪失を小さく抑えつつ、バーチャルスライド画像の解像度の増減を可能にする。好都合なことに、拡大縮小に必要な時間は、バーチャルスライド画像ファイルに種々の中間レベル解像度画像２９０、２９１を前もって備えておくことによって、大幅に低減される。変形モジュール５３０は、９０°回転などバーチャルスライド画像の直角回転を可能にし、さらに画像の水平および垂直反転を実現できる。

図５Ｄ〜Ｈは、本発明の一実施の形態による典型的な閲覧ウインドウおよび操作制御ウインドウを示したスクリーンショットである。図５Ｄは、典型的なクライアント・ビューア・ウインドウを示している。このウインドウは、それぞれ別個のスライドの画像を表示している２つの表示域５４０に分割されている。右側の表示域５４０がアクティブなウインドウであり、このウインドウについての情報が、ステータス・バー５４２に示されている。ステータス・バーには、この画像が７３，０４２×６２，６３３ピクセルであり、このバーチャルスライドの画像データが約１３．１ＧＢである旨が示されている。さらに、ステータス・バーは、表示域５４０が現在データを先読みしていることを示している。

さらに、それぞれの表示域５４０には、サムネイル画像５４４など、バーチャルスライド全体のサムネイル画像が示されている。好都合なことに、サムネイル画像内でマウスをクリックまたはドラッグすると、これに対応して表示域ウインドウ内の拡大画像を位置させることができる。さらに、現在の閲覧の相対位置およびサイズを示すため、サムネイル画像内に四角形が表示されている。

さらに、それぞれの表示域５４０に拡大鏡ウインドウ５４６を開くことができる。好都合なことに、拡大鏡ウインドウ５４６は、カーソルの周囲の領域を２倍の相対倍率で表示することができる。マウスをドラッグすることによって、マウスの周囲の拡大領域を移動させることができる。コンピュータ画面上のピクセルのサイズが小さいため、好都合には、ビューア（すなわち、人物）により多くの情報を提供すべく、スキャンした解像度レベルを超えて画像を拡大することができる。拡大鏡ウインドウ５４６によって、ユーザは、追加の２倍の解像度を得るべく表示された画像データ上を移動することができる。この追加の解像度は、ベースライン画像についても利用可能である。

さらに、各表示域ウインドウの解像度を所定の特定の解像度に設定できるよう、ツールバー５４８も用意されている。好都合には、この所定の解像度が、バーチャルスライド画像ファイルにすでに存在しているベースラインおよび中間レベルに、直接対応しているとよい。最後に、ズーム・スライダ５５０によって、任意の解像度レベルを選択することができるとともに、表示域コントローラ内のバーチャルスライド画像について迅速な拡大縮小が可能である。

図５Ｅは、典型的なガンマ調節ウインドウを示している。画像の明るさ／コントラスト、画像のカラーバランス、および画像のカラー曲線を調節し、さらに調節設定の読み込みおよび保存を行なうため、さまざまなタブが利用可能である。図示の実施の形態では、カラー曲線タブが示されている。カラー曲線５５２によって、ユーザは、スペクトルに沿ってカラーマッピングを調節することができる。左側のカラー・ボックスによって、ユーザは、変更しようとする特定のカラー・チャネルについての曲線を独立に選択でき、あるいはすべてのカラー・チャネルを同時に変更すべく選択することができる。

図５Ｆは、典型的なフィルタ処理ウインドウを示している。ウインドウの上部には、あらかじめ定められたいくつかのフィルタが挙げられており、所望のラジオ・ボタンを選択することによって適用することができる。さらに、カスタム設定できる５×５のコンボリューションマトリクスを、ダイアログ・ボックスの入力フィールド５５６に適当な値を入力することによって定義することができる。コンボリューションマトリクスによって、コントラストの強調、エッジの強調、および他の画像処理機能が可能である。

図５Ｇは、典型的な変形ウインドウを示している。変形ウインドウにより、所望のラジオ・ボタンを選択することによって、ユーザは、バーチャルスライド画像を９０°回転させることができ、あるいは水平または垂直の中心線を横切って画像を鏡像反転させることができる。

図５Ｈは、典型的なウェブ・ビューア・ウインドウを示している。ウェブ・ビューア・ウインドウは、ＨＴＭＬおよび埋め込みされた画像で作られている。標準的なテキスト５６０を、図３に関してすでに説明したとおりウェブ・ビューアによって生成し、所望のとおり表示および配置することができる。また、サムネイル画像５６２も、内部サイズおよび中間解像度画像５６４の位置確認のための位置基準とともに提供されている。さらに、中間解像度画像５６４の内部には、高解像度画像５６６の現在の位置を示す同様の基準が提示されている。

図６Ａは、本発明の一実施の形態による典型的な注釈モジュール１６０を示したブロック図である。注釈モジュール１６０は、注釈ビューア１６４および注釈ハンドラ１６２を有している。注釈ビューア１６４は、バーチャルスライド・モジュール１１０と関連して動作し、バーチャルスライド画像データに重ねて表示すべく注釈情報（すなわち、レイヤー）を提供する。注釈ハンドラ１６２が、クライアント・ビューア８０などのビューアからの注釈の生成、編集、および削除の要求を処理する。さらに、注釈ハンドラ１６２は、データ記憶領域１５０への注釈情報の保持を管理するとともに、適切な場合、注釈データを取り出して、当該注釈情報を注釈ビューア１６４に提供する。

一実施の形態において、ユーザはクライアント・ビューア８０において、例えば注釈コントローラ４００を使用して注釈を生成することができる。注釈情報が、クライアント・ビューア８０の通信モジュール４５０によって、バーチャルスライド・サーバ２０へと送信される。注釈の生成を含んでいる要求が、通信モジュール１００によって処理され、注釈ハンドラ１６２に渡される。次いで、注釈ハンドラ１６２が、注釈をデータ記憶領域１５０への保存のためにデータベース・モジュール１４０へと提供する。

図６Ｂ〜Ｃは、本発明の一実施の形態による典型的な注釈を示したスクリーンショットである。図６Ｂは、構造化言語による典型的な注釈を示している。図示の実施の形態においては、注釈が拡張可能マークアップ言語（「ＸＭＬ」）で示されているが、他の構造化言語も使用可能である。好都合には、当業者であれば理解できるとおり、このような注釈を、単純な文字列としてデータベースに保存することができる。

注釈は、バーチャルスライドのベース解像度レベルに対応する座標を使用して記述でき、保存でき、取り出すことができる。これにより、注釈を、それらが説明している画像データとともに、任意の解像度レベルへと拡大縮小することができる。図示の実施の形態においては、注釈が、表示される１つ以上の特徴または領域で構成されており、レイヤーへとグループ化されている。一実施の形態においては、個々の注釈レイヤーを選択的に有効にでき、あるいは無効にできる。

図６Ｃは、注釈を有する典型的な表示域ウインドウを示している。フローティング（移動可能な）ダイアログ・ボックス６０２が、ユーザに注釈コントローラを提供し、注釈レイヤーおよびレイヤー属性の選択を容易にする。同様に、ダイアログ・ボックス６０４が、現在のレイヤー内で個々の注釈および注釈属性を追加し、編集し、削除する能力を、ユーザに提供する。

個々の注釈６０６は、いくつか例を挙げると、楕円、矢印、自由形状多角形、および矩形など、種々さまざまな形態を具現化できる。一実施の形態においては、或る特定のレイヤー内の各注釈が、例えば現在選択されている注釈が黒の縁取りを有するなど、異なる色で表示される。注釈作成ツールがメニューバー６０８に出現し、いくつか例を挙げると、ペン・ツール、形状ツール（矩形および楕円形）、および矢印ツールを含んでいる。

一実施の形態においては、注釈が、バーチャルスライドのベースライン画像に対して特定の位置に関連付けられた注釈領域で構成されている。各注釈領域に関してさまざまな値を設定でき、注釈文字列にｋｅｙ＝ｖａｌｕｅの形式で保存することができる。注釈レイヤーが、複数の注釈領域を含んでもよい。さらに、注釈レイヤーが、さまざまな値を例えばｋｅｙ＝ｖａｌｕｅの形式でレイヤーに関連付け、注釈文字列とともに保存して有してもよい。

図７Ａは、本発明の一実施の形態による典型的なＶＭＣ閲覧システム１２を示したネットワーク図である。図示の実施の形態においては、ＶＭＣサーバ３２が、リーダ・クライアント・ビューア７４および参加者クライアント・ビューア７６に、ネットワーク６２を介して通信可能に接続されている。一実施の形態においては、複数の参加者クライアント・ビューア７６が存在してよいが、リーダ・クライアント・ビューア７４は、カンファレンスのセッションごとに１つだけである。リーダ・クライアント・ビューア７４は、ローカルなデータ記憶領域７５を備えて構成でき、各参加者クライアント・ビューア７６も、同様にローカルなデータ記憶領域７７を備えて構成できる。代案となる実施の形態においては、２つ以上のリーダ・クライアント・ビューア７４が存在してもよい。

図７Ａに示すとおり、本発明の一実施の形態においては、バーチャルスライド・サーバ３４が、データ記憶領域５０または画像キャッシュ（図示せず）から、バーチャル顕微鏡カンファレンス・セッションのすべての参加者７４および７６に、画像データを供給する。任意により、バーチャルスライド・サーバ３４が、バーチャル顕微鏡カンファレンス・サーバ３２と同じ位置にあってもよく、さらに／あるいはサーバ３４および３２を、１つの共有サーバ２１へと一体に組み合わせてもよい。

バーチャル顕微鏡カンファレンスにおいては、リーダ・クライアント・ビューア７４が、セッションの閲覧を管理する。リーダ・クライアント・ビューア７４から受け取ったバーチャルスライド指令により、ＶＭＣサーバ３２が、それらの指令を当該セッションの他の参加者ビューアに伝達する。例えば、注釈レイヤーの表示および注釈領域の生成を含め、リーダ・クライアント・ビューア７４から受信される視点の移動および拡大縮小ならびに他の相互作用の指令がすべて、ローカルで実行され、他のすべての参加者ビューアへと伝達される。さらに、画像を開く指令および閉じる指令、ならびに他のセッション制御行為は、当該セッション・リーダによって開始される。参加者クライアントは、自身の画像表示をローカルで変更（視点移動、拡大縮小、など）してもよいが、これらの動作がＶＭＣサーバ３２を介して他のセッション参加者に伝えられることはない。

図７Ｂは、本発明の一実施の形態によるバーチャル顕微鏡カンファレンスのための典型的なＶＭＣサーバ３２を示したブロック図である。ＶＭＣサーバ３２は、ＶＭＣセッション・マネージャ６２０およびＶＭＣセッション・テーブル６３０を備えている。認証モジュール１３０およびデータベース・モジュール１４０が、ＶＭＣセッションの参加者を認証するために使用される。

好都合には、ＶＭＣセッション・マネージャが、リーダ・クライアント・ビューアから受け取るすべてのＶＭＣ要求を処理する。さらに、ＶＭＣセッション・マネージャ６２０は、どのクライアントがリーダであるのかを把握し、リーダシップを要求したクライアントの待ち行列を保持するため、ＶＭＣセッション・テーブル６３０を維持する。さらに、ＶＭＣセッション・テーブル６３０は、好ましくは、各参加者クライアント・ビューアの現在のバーチャルスライド閲覧をリーダ・クライアント・ビューアのものと同期させるため、各参加者クライアント・ビューアの状態を保持する。

一実施の形態においては、ＶＭＣセッション・テーブル６３０が、リーダ・クライアント・ビューアになることを要求した参加者クライアント・ビューアのリストを含んでいる。好都合には、リーダ・クライアント・ビューアが、ＶＭＣサーバ３２においてセッション・リーダーシップ待ち行列中で順番を待っている次の参加者クライアントを選択するように要求することで、明示的または暗黙裡に、セッションのリーダシップをいずれかの参加者クライアント・ビューアへと、いつでも渡すことができる。

ＶＭＣセッション・マネージャ６２０は、まず、第１のクライアント・ビューアからセッションを確立するためのＶＭＣ要求を受信する。この第１のクライアント・ビューアがリーダ・クライアント・ビューアとなって、パスワードおよびセッション識別子を設定する。このセッション識別子を指定し、かつ正しいパスワードを提示するさらなるクライアント・ビューアが、参加者クライアント・ビューアになる。一実施の形態においては、各参加者クライアント・ビューアが、当該参加者クライアント・ビューアの状態を追跡すべく生成された固有のＶＭＣセッション・テーブルを有している。

リーダ７４およびすべての参加者７６を含むＶＭＣセッションのクライアントは、すでに述べたとおり、画像データを取得するための１つ以上のバーチャルスライド・サーバ３４へのアクセスを共有する。画像データへのアクセスは、画像ブロック・レベルであって、ブロックの処理がクライアントによって行なわれてもよく、あるいは画像サブ領域のレベルであって、サブ領域を描くためのブロックの処理がクライアントの代理としてサーバによって行なわれてもよい。

一実施の形態においては、バーチャルスライド画像のガンマ調節が、個々の参加者ベースで利用可能である。ガンマ調節は、個々のモニタおよび環境光のそれぞれに固有であって、したがってＶＭＣセッションの個々の参加者クライアント・ビューアのそれぞれによって制御可能であると好都合である。ガンマ調節の操作は、バーチャルスライド・サーバ３４上で実行できるが、より一般的には、ローカルのクライアント・ビューアにて実行される。

図７Ｃは、バーチャルスライド・ビューア７０内へと作りこまれたバーチャル顕微鏡カンファレンス・クライアント（リーダまたは参加者のいずれか）の典型的な一実施の形態を示している。フローティング（移動可能な）ダイアログ・ボックスが、参加者のリスト７０２など現在のセッションの状態を表示している。セッションのリーダシップを要求し、割り当て、放棄するため、コントローラ７０４が設けられている。

図８Ａは、本発明の一実施の形態による典型的な三次元バーチャルスライドを示したブロック図である。三次元バーチャルスライドは、垂直の次元に複数の画像平面を含んでいる。例えば、顕微鏡スライドにおいて組織標本がかなりの厚さを有している場合、標本全体を垂直方向のただ１つの焦点面で捉えることは、多くの場合困難である。したがって、顕微鏡スライドが、焦点面の異なるいくつかの垂直レイヤーにてスキャン（すなわち、デジタル化）され、垂直レイヤーのそれぞれが別個の垂直スライド画像を構成する。

図示の実施の形態においては、顕微鏡スライドが５つの別個の垂直レイヤーにてスキャンされ、これら５つのレイヤー（０〜４）のそれぞれについてバーチャルスライドが生成され、保存される。さらに、各レイヤーについての垂直軸（本明細書において「Ｚ軸」とも称する）方向のオフセットが、各レイヤーについてのバーチャルスライドと垂直軸方向のオフセット７１６とからなる複合画像ファイルを生成するため、保存される。したがって、クライアント・ビューアが、レイヤー０の画像７１２とレイヤー１の画像７１４との間に位置する現閲覧レイヤー７１２など、Ｚ軸において５つあるレイヤーのうちの２つのレイヤーの間の閲覧を要求したとき、直上のレイヤーおよび直下のレイヤーが、要求された垂直レベルについての閲覧をユーザに提供すべく補間される。

図８Ｂは、本発明の一実施の形態による三次元バーチャルスライド・スキュー７２０を示したブロック図である。垂直軸について現閲覧レベルを補間することの利点は、得られる現在の閲覧をスキューできる点にある。例えば、レイヤー０の画像７１０からの画像ピクセルを或る一方向にずらすことができ、レイヤー１の画像７１４からの画像ピクセルを、反対方向にずらすことができる。この結果、得られる現在の閲覧レベルの画像が、実際のスキャン方向への角度を近似する視点をもたらすことになる。三次元バーチャルスライドのスキューを操作することによって、ユーザは、好都合にも、スライド上の対象組織または細胞の回転三次元画像を見ることができる。

図８Ｃは、バーチャルスライド・ビューア７０内へと作りこまれた本発明の一実施の形態による典型的な三次元バーチャルスライド閲覧ウインドウを示したスクリーンショットである。図示の実施の形態においては、表示域画像５４０が、直上の画像レイヤーと直下の画像レイヤーとから補間された現在の閲覧レベルを表示している。垂直方向のレイヤーの奥行きについてのスライダ・コントローラ７３０によって、ユーザは、表示域の表示をＺ軸に沿って変化させることができる。さらに、スキュー・コントローラ７３２によって、ユーザは、表示域内のバーチャルスライド画像について、スキュー方向およびスキューの量を動的に変化させることができる。一実施の形態においては、スキュー制御ウインドウ内の十字線をドラッグすることによって、三次元の視点を変化させることができる。好都合には、暗い影の円が、対象物（例えば、白い円）に対する視点（例えば、十字線）の関係を示している。

典型的な実施の形態
以下で、本発明の典型的な実装例を、図９Ａ〜９Ｆに関して説明する。この典型的な実施の形態は、あくまで例として説明されるものであり、これまでに記載し添付の特許請求の範囲にも記載される本発明の広がりおよび技術的範囲を限定するものとして解釈するべきではない。

図９Ａ〜９Ｆは、バーチャル顕微鏡スライド画像を閲覧するための典型的な実施の形態を示したブロック図である。図９Ａは、バーチャルスライド閲覧システムの各コンポーネントおよびそれらの間のインターフェイスを、下記のとおり説明している。

図示の実施の形態は、デジタル化スキャンによる顕微鏡スライド（「バーチャルスライド」）の閲覧および管理のためのコンピュータ・システムを含んでいる。このコンピュータ・システムは、バーチャルスライド情報を保存する１つ以上のサーバ装置、およびスライド情報の閲覧に使用される１つ以上のクライアント装置を有している。システム内のコンピュータは、ＴＣＰ／ＩＰ（インターネットで使用される標準的なネットワーク・プロトコル）によるＨＴＴＰ要求を使用して通信する。システムのコンピュータは、互いに物理的に近くにあって構内通信網（「ＬＡＮ」）によって通信してもよく、あるいは物理的に離れていて広域通信網（「ＷＡＮ」）によって通信してもよい。このシステムの重要な特徴は、ＷＡＮにおいて優秀な性能を示す点にあり、すなわちＬＡＮの装置間帯域幅を必要としない点にある。

サーバ装置は、典型的には、インテル社（Ｉｎｔｅｌ）のアーキテクチャのプロセッサを特徴として備え、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）のウインドウズ（Ｗｉｎｄｏｗｓ（登録商標））またはリナックス（Ｌｉｎｕｘ）を動作させる強力なＰＣである。システムのアーキテクチャは、サーバの実装の詳細とは無関係である。システムのすべてのサーバ・コンポーネントは、１つのサーバ装置に同居してもよく、あるいは性能向上または保守性を考慮して別個独立であってもよい。

このシステムは、２つの閲覧環境を提供する。クライアント閲覧インターフェイスは、簡単かつ簡潔なグラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）を提供するスタンドアロンの閲覧プログラム（「イメージスコープ（ＩｍａｇｅＳｃｏｐｅ）」）を使用する。ウェブ閲覧インターフェイスは、任意の標準的なインターネットブラウザを使用し、クライアント側にアプレット、プラグイン、または他のソフトウェアを必要としない。クライアント閲覧インターフェイスは、任意のインテル・アーキテクチャのコンピュータ上で、マイクロソフト・ウインドウズの任意のバージョン上で動作する。このシステムの特徴は、クライアント装置の構成とは無関係である。ウェブ閲覧インターフェイスは、そのような環境がＨＴＭＬページの処理およびＪＰＥＧ画像の表示という標準的なウェブ・ブラウザの能力を提供する限りにおいて、あらゆるコンピュータ上で、あらゆるオペレーティング・システムのあらゆるバージョン上で動作する。

Ａ‐イメージサーバ（ＩｍａｇｅＳｅｒｖｅｒ）装置
このコンピュータは、バーチャルスライド画像を収容し、スライド・データへのアクセスのために使用されるネットワーク・アプリケーション・プログラム・インターフェイス（「ＡＰＩ」）を提供する。この装置は、インテル‐アーキテクチャのコンピュータであってマイクロソフト・ウインドウズまたはリナックスを動作させており、典型的には、かなりのメモリ（キャッシュ用）および大量のディスク記憶領域（バーチャルスライドの保存用）を装備する強力なＰＣである。

Ｂ‐ウェブ・サーバ装置
このコンピュータは、ウェブ・インターフェイスを使用してバーチャルスライド・データにアクセスするために使用されるウェブサイトを収容している。ウェブビューア（ＷｅｂＶｉｅｗｅｒ）ソフトウェアが、ウェブサーバに一体化されている。この装置は、マイクロソフト・ウインドウズおよびマイクロソフト・インターネット・インフォメーション・サーバ（ＩＩＳ）を動作させるインテル‐アーキテクチャのコンピュータであってよく、あるいはアパッチ（Ａｐａｃｈｅ）を動作させる任意のアーキテクチャのコンピュータであってよい。ウェブ・サーバ装置が、イメージサーバ装置と同じであることも可能である。

Ｃ‐バーチャルスライド画像ファイル
バーチャルスライドは、典型的には２００ＭＢ〜４ＧＢのサイズの別個独立のファイルとして保存される。イメージサーバ装置は、容量および堅牢性の理由で、複数の別個独立のディスクからなる冗長アレイ（「ＲＡＩＤ」）を備えて構成されることが多い。

Ｄ‐データベース
認証用のデータおよび注釈を含むバーチャルスライド情報が、ＳＱＬデータベースに保存される。このデータベースは、通常はイメージサーバ装置に位置するが、必ずしもそのようである必要はない。典型的な実装例は、マイクロソフト・データベース・エンジン（「ＭＳＤＥ」）またはマイクロソフトＳＱＬサーバを使用する。データベースへのアクセスは、システムの一部として提供されるサービスを経由する。このサービスへのインターフェイスは、ＴＣＰ／ＩＰによるＨＴＴＰであり、データベース・アクセスの分散を可能にする。

Ｅ‐イメージサーバ（ＩｍａｇｅＳｅｒｖｅｒ）
イメージサーバは、バーチャルスライド・データへのアクセスのためのネットワークＡＰＩを提供するスタンドアロンのアプリケーションである。イメージサーバは、バーチャルスライド画像ファイルにアクセスするとともに、認証および注釈データへのアクセスのため、データベースへのインターフェイスを有している。

Ｆ‐イメージスコープ（ＩｍａｇｅＳｃｏｐｅ）ビューア
イメージスコープは、スライド情報の閲覧のために簡単かつ簡潔なグラフィカル・ユーザ・インターフェイスを提供するスタンドアロンのアプリケーションである。イメージスコープは、イメージサーバのネットワークＡＰＩを利用してイメージサーバとやり取りし、あるいはバーチャルスライド・ファイルを直接読み出すことができる。

Ｇ‐ウェブビューア（ＷｅｂＶｉｅｗｅｒ）
ウェブビューア・ソフトウェアは、スライド情報を閲覧するためのＨＴＭＬユーザ・インターフェイスをウェブ・ブラウザに届けるため、標準的なウェブ・サーバのもとで動作する。ＨＴＭＬページは、ウェブ・ブラウザにイメージサーバからのＪＰＥＧ画像情報を要求させる画像タグ（＜ＩＭＧ＞）を含んでいる。ＨＴＭＬページとＪＰＥＧ画像の組み合わせが、ウェブビューア・インターフェイスを構成する。

Ｈ‐ウェブ・ブラウザ
任意のプラットフォーム上のあらゆる標準的なウェブ・ブラウザを、ウェブビューアを利用してバーチャルスライド・データを閲覧すべく使用することができる。

Ｘ‐画像ブロックＡＰＩ
イメージサーバは、バーチャルスライド・ファイルのブロックにアクセスするため、ＴＣＰ／ＩＰによるＨＴＴＰメッセージ・インターフェイスをサポートしている。これらのブロックは、イメージビューア（クライアント側）によって解凍され、処理される。

Ｙ‐画像サブ領域ＡＰＩ
イメージサーバは、バーチャルスライド・ファイルのサブ領域にアクセスするため、ＴＣＰ／ＩＰによるＨＴＴＰメッセージ・インターフェイスをサポートしている。これらの領域は、イメージサーバ（サーバ側）によって解凍および処理され、ＪＰＥＧ画像として再圧縮されてブラウザへと送信される。

Ｚ‐ウェブ・サーバへのＨＴＭＬインターフェイス
これは、ウェブ・ブラウザとウェブ・サーバとの間の標準的なＴＣＰ／ＩＰによるＨＴＴＰインターフェイスであって、ブラウザへとＨＴＭＬページを届けるために使用される。ウェブビューアが、ページの動的な生成、および応答データの処理を行なう。

図９Ｂは、イメージ・サーバの内部の実装の詳細を、以下に説明するとおり示している。

イメージサーバは、バーチャルスライド画像データへのアクセスのため、クライアントにネットワークＡＰＩを提供するスタンドアロンのアプリケーションである。クライアントは、画像ブロック（圧縮された生の画像データ）または画像領域（解凍され、拡大縮小され、変形され、フィルタ処理され、ＪＰＥＧフォーマットへと再圧縮された画像データ）にアクセスすることができる。さらに、種々の画像属性（寸法、説明文、など）および注釈情報へのアクセスも提供される。

イメージサーバは、複数のクライアントに同時にサービスを提供することができ、画像データへのアクセスを高速化するために複数のメモリ・キャッシュを使用する。サーバへの要求はすべて、状態と無関係（ｓｔａｔｅｌｅｓｓ）である。要求は、ＴＣＰ／ＩＰによってＨＴＴＰで行なわれる。ＨＴＴＰ １．１の要求パイプラインがサポートされている（１つのソケット接続によって複数の要求を順次に行なうことができる）。

イメージサーバは、クライアントからの新規ソケット接続を受け入れて、すべてのクライアント要求を管理する接続マネージャ・コンポーネントを含んでいる。各クライアント要求は、任意により、ＨＴＴＰ認証ヘッダを含むことができる。このヘッダは、ウェブ・ブラウザ（ユーザが、ユーザＩＤ／パスワード認証情報を入力したとき）およびイメージスコープなどのスタンドアロン・クライアント・プログラムによって生成される。接続マネージャは、届いた要求のすべての認証情報を検証する。認証は、ディレクトリ・レベルで実行される。いくつかのディレクトリは「パブリック」であってよく（認証が要求されない）、他のディレクトリは、当該ディレクトリ内のあらゆる画像を閲覧可能にする前に、明示的な認証を要求することができる。

Ａ‐接続マネージャ・コンポーネントが、クライアントからの新規ソケット接続を受け入れ、すべてのクライアント要求を管理し、認証の確認を実行する。

Ｂ‐各要求（すべての接続は状況と無関係である）においてクライアントが、ＨＴＴＰ認証ヘッダ内にユーザＩＤ／パスワード情報を供給することによって、認証証明を提示する。

Ｃ‐要求ごとに認証データベースにアクセスしなくてもよいよう、認証キャッシュが、イメージサーバによって保持される。このキャッシュは、定期的に新規の接続が確立されたときに書き換えられ、あるいは明示的にリセット（ＲＥＳＥＴ）要求が受信されたときに書き換えられる。

Ｄ‐データベース・サービスが、データベースへのインターフェイスを提供する。このサービスは、ＨＴＴＰ要求を受け入れ、データベースをイメージサーバとは別個の装置に配置できるようにする。このサービスは、データベース情報にアクセスするために標準的なＳＱＬ要求を使用する。

Ｅ‐認証および注釈の情報を保存するため、ＳＱＬデータベースが使用される。このデータベースは、通常は、マイクロソフト・データベース・エンジン（「ＭＳＤＥ」）を使用して実装されるが、ＳＱＬサーバであってもよく、あるいは他の任意のＳＱＬ準拠のデータベースであってよい。

Ｆ‐クライアントによって画像情報要求が行なわれ、画像の寸法、説明文、およびピラミッド構造などの属性が返される。情報要求は、データを返すためにイメージオブジェクト（Ｉｍａｇｅ Ｏｂｊｅｃｔ）のプロパティ（ｐｒｏｐｅｒｔｉｅｓ）を使用する。

Ｇ‐イメージサーバによって管理される別個のバーチャルスライド画像のそれぞれについて、イメージオブジェクトがインスタンス作成され、バーチャルスライドとやり取りするためのプロパティおよび方法が提供される。性能上の目的で、最近アクセスされたオブジェクトのキャッシュが保持される。イメージオブジェクトは、バーチャルスライドの詳細な実装からアプリケーションを切り離すため、システム全体において使用される。

Ｈ‐バーチャルスライド・ファイルへのアクセスをカプセル化（ｅｎｃａｐｓｕｌａｔｅ）するため、イメージオブジェクト内にファイルオブジェクト（Ｆｉｌｅ Ｏｂｊｅｃｔ）がインスタンス作成され、そのようなファイルとやり取りするためのプロパティおよび方法が提供される。

Ｉ‐性能上の目的で、ファイル情報キャッシュが、すべてのファイルオブジェクトにわたって保持される。これにより、要求がなされたとき、最近アクセスされたファイルについてのすべての情報を再ロードする必要なく、イメージオブジェクトをインスタンス作成し、破壊することが可能である。ファイル情報キャッシュは、ファイルオブジェクトがインスタンス作成されたときに定期的に書き換えられ、あるいは明示的にリセット要求が受信されたときに書き換えられる。

Ｊ‐バーチャルスライド・ファイル情報にアクセスするため、Ｉ／Ｏライブラリが、ファイルオブジェクトによって使用される。このライブラリは、タグ付き画像ファイル・フォーマット（「ＴＩＦＦ」）ファイル・ヘッダの詳細をカプセル化している。

Ｋ‐バーチャルスライド画像ファイルは、通常のファイルと同様にイメージサーバ装置上に保存される（たとえ、きわめて大きいファイルであっても）。

Ｌ‐ブロック要求は、画像ファイル・ブロックを直接デコードできるクライアント（すなわち、イメージオブジェクトを含んでいるクライアント）によってなされる。これは、スキャンスコープ・ビューアならびにアルゴリズム・フレームワーク（Ａｌｇｏｒｉｔｈｍ Ｆｒａｍｅｗｏｒｋ）を含んでいる。ブロック要求は、直接ファイルオブジェクトへとイメージオブジェクトを通過し、Ｉ／Ｏライブラリへと渡される。ブロック要求は、サーバにおいて必要とされる処理がきわめて少ないため高速であり、バーチャルスライド画像の元のＪＰＥＧ２０００圧縮がクライアント／サーバ・インターフェイスを横断して保たれるため、高密度である。

Ｍ‐性能上の目的で、ブロック・キャッシュが、最近使用（「ＭＲＵ」）基準にもとづき、すべてのファイルオブジェクトを横断して保持される。ブロック・キャッシュの大きさは、イメージサーバ装置上に構成されたメモリの量の関数であり、イメージサーバ・プロセスに渡されたパラメータによる。

Ｎ‐領域要求は、画像ファイル・ブロックを直接デコードすることができないクライアント（ウェブ・ブラウザ、など）によってなされる。「領域」が、画像の任意のサブサーフェイス領域を指しており、画像ファイルまたは画像ファイルが取得されたやり方についての固定の属性ではないことに、注意すべきである。この点で、ここに記載の典型的な実施の形態は、画像データがタイルとして取得されてタイルとして保存されていて、タイルが画像の物理的なプロパティである他のシステムと、根本的に相違している。画像のサブ領域は、画像内の任意の（Ｘ，Ｙ）位置について、任意の解像度および任意の寸法で要求することができる。領域は、ＪＰＥＧ２０００データを理解できないクライアントとの互換性のため、ＪＰＥＧ画像としてエンコードされて返される。領域要求は、サーバにおいて必要とされる前処理の量ゆえにブロック要求よりも低速であり、画像データがＪＰＥＧ２０００ではなくＪＰＥＧにエンコードされて返されるため、ブロック要求よりも密度が低い。

Ｏ‐さまざまな圧縮機構をカプセル化するため、コーデックオブジェクト（Ｃｏｄｅｃ Ｏｂｊｅｃｔ）が、イメージオブジェクトとともにインスタンス作成される。バーチャルスライド画像については、通常は、高い画像忠実度ゆえＪＰＥＧ２０００が好ましいが、ＪＰＥＧおよびＬＺＷならびに生の画像（圧縮なし）もサポートされる。

Ｐ‐性能上の目的で、領域キャッシュが、最近使用基準にもとづき、すべてのイメージオブジェクトを横断して保持される。領域キャッシュの大きさは、イメージサーバ装置上に構成されたメモリの量の関数であり、イメージサーバ・プロセスに渡されたパラメータによる。

Ｑ‐画像についての注釈情報を要求および更新するため、注釈要求がクライアントによってなされる。注釈は、ＸＭＬにて保存され、データベース・サービスへとなされた要求によって、データベースからクライアントへと直接、「ブロブ（ｂｌｏｂ）」として返される。クライアントは、適切な認証を有している場合に、画像についての注釈情報を更新することができる。

Ｗ‐注釈データ・インターフェイス
クライアントがＨＴＴＰ要求を行い、応答としてＸＭＬフォーマットの画像注釈データを受け取る。さらに、注釈データを、ＸＭＬフォーマットの画像注釈データを含んでいるＨＴＴＰ投稿によって、更新することができる。

Ｘ‐画像ファイル情報インターフェイス
クライアントがＨＴＴＰ要求を行い、画像属性を取得するためのＸＭＬフォーマットの応答データを受け取る。

Ｙ‐画像ブロック・インターフェイス
クライアントがＨＴＴＰ要求を行い、応答として画像ファイル・ブロックを受け取る。ブロックは、（Ｘ，Ｙ）位置およびレベルによって要求される。クライアントが、画像ファイル・ブロックの解凍（ＪＰＥＧ２０００コーデックを使用）および適切な解像度への拡大縮小を担当する。

Ｚ‐画像領域インターフェイス
クライアントがＨＴＴＰ要求を行い、応答としてＪＰＥＧ画像を受け取る。領域は、画像の任意のサブ領域であり、（Ｘ，Ｙ）位置および解像度ならびに所望の寸法によって要求される。ＪＰＥＧ２０００の解凍および適切な解像度への拡大縮小は、イメージサーバ・プロセスによってなされる。

図９Ｃは、イメージスコープ・ビューアの内部の実装の詳細を、以下に説明するとおり示している。

イメージスコープは、スライド情報の閲覧のために簡単かつ簡潔なグラフィカル・ユーザ・インターフェイスを提供するスタンドアロンのアプリケーションである。イメージスコープは、イメージサーバのネットワークＡＰＩを利用してイメージサーバとやり取りし、あるいはバーチャルスライド・ファイルを直接読み出すことができる。

イメージスコープは、きわめて大きなバーチャルスライドについてのリアルタイムでの視点移動および拡大縮小、複数の同時画像および表示窓の同期のサポート、ＪＰＥＧ２０００（ウェーブレット）の画像品質、性能を改善するための予測によるデータの先読み、性能向上のためのブロックおよび領域のキャッシュ、リアルタイムで調節可能なガンマ（ＲＧＢカラーマッピング）、コンボリューションフィルタのリアルタイム適用、リアルタイムでの直角変形（９０°回転および鏡像反転）、レイヤーによる注釈の表示および編集のサポート、バーチャル顕微鏡カンファレンス（「ＶＭＣ」）のサポート、および複数のＺ軸スキャンにて得たスライド・データの３Ｄ閲覧、など、バーチャルスライドの精査を容易にするための独自の特徴を提供する。

イメージスコープは、その機能の大部分をビューポート（ｖｉｅｗｐｏｒｔ）と呼ばれるアクティブエックス（ＡｃｔｉｖｅＸ）コントローラにカプセル化する新規なアーキテクチャで実装される。ビューポート・コントローラは、バーチャルスライド閲覧能力を提供するため、さまざまなアプリケーションに容易に組み込むことができる。

ビューポート・コントローラは、性能を最適化するため広範囲にわたるキャッシュおよび先読みの技法を使用する。アプリケーションは、性能の最大化および利用可能なメモリの活用のため、オブジェクト間キャッシュを共有する複数の表示域をインスタンス化できる。ビューポートそのものがイメージオブジェクトをカプセル化し、次にイメージオブジェクトが、ファイルオブジェクトをカプセル化し、イメージオブジェクトおよびファイルオブジェクトが、イメージサーバ・プログラムと共有される。

イメージスコープ・プログラムおよびビューポート・コントローラの重要な属性は、きわめて大きいバーチャルスライド画像を、ネットワーク帯域幅が比較的低速（３００Ｋ）である広域通信網を介して閲覧できるという能力にある。この理由のため、画面の書き換えは決して同時性ではなく、代わりにビューポートは、現在キャッシュから利用可能である画像ビューの最良のバージョンを表示し、このビューのますます高い解像度のバージョンをイメージサーバから取り出すように継続的に試み、それがなされると画面を更新する。エンドユーザにとっての効用は、応答を感じることができ、接続の帯域幅を意識することがないという点にある。

Ａ‐イメージスコープ・アプリケーションは、バーチャルスライドへのアクセスのためのグラフィカル・ユーザ・インターフェイス（「ＧＵＩ」）を収容し、ビューポート・アクティブエックス・コントローラの複数のインスタンスのための容器として機能する。

Ｂ‐ＧＵＩスクリーン・マネージャは、イメージスコープ・プログラムの主たる論理をカプセル化し、バーチャルスライド表示窓ならびにすべてのキーボードおよびマウス入力を管理する。

Ｃ‐ビューポート・アクティブエックス・コントローラ
このコントローラのプロパティおよび方法は、バーチャルスライドへのすべてのアクセスをカプセル化する。コントローラのウインドウが、スライド情報を表示する表示窓の表面である。

Ｄ‐「レンダリング・エンジン」が、ビューポート・コントローラの核心である。このエンジンは、任意の位置、寸法、および解像度におけるバーチャルスライド画像の任意の閲覧の「最良」のバージョンを構築するため、キャッシュされたデータを使用する。「より良い」バージョンが入手可能である（より多くのデータがイメージサーバから取り出される）とき、エンジンは、現在表示されている画面を更新する。

Ｅ‐バーチャルスライド画像をカプセル化すべく、ビューポート・コントローラによってイメージオブジェクトがインスタンス作成され、バーチャルスライドとやり取りするためのプロパティおよび方法が提供される。

Ｆ‐イメージオブジェクトは、領域配置のためのロジックを含んでおり、バーチャルスライドの任意の領域を所望の任意のレベルの解像度で描く。このロジックは、先読みスレッド（ｐｒｅｆｅｔｃｈ ｔｈｒｅａｄ）によって惹起されたときなど、同期的（必要な画像情報を要求する）であってよく、あるいはレンダリング・エンジンによって惹起されたときなど、非同期（入手できる画像情報のみを使用する）であってよい。

Ｇ‐コーデックオブジェクトが、種々の圧縮機構をカプセル化するため、イメージオブジェクトとともにインスタンス作成される。バーチャルスライド画像については、通常は、高い画像忠実度ゆえＪＰＥＧ２０００が好ましいが、ＪＰＥＧおよびＬＺＷならびに「生の」画像（圧縮なし）もサポートされる。

Ｈ‐バーチャルスライド・ファイルへのアクセスをカプセル化するため、イメージオブジェクト内にファイルオブジェクトがインスタンス作成され、そのようなファイルとやり取りするためのプロパティおよび方法が提供される。ファイルオブジェクトは、リモート（ＴＣＰ／ＩＰライブラリを介してイメージサーバからアクセスされる）またはローカル（Ｉ／Ｏライブラリを介してローカルのファイルシステムからアクセスされる）であってよいバーチャルスライド・ファイルについて、場所に依存しないアクセスを可能にする。

Ｉ‐ＴＣＰ／ＩＰライブラリが、イメージサーバへのネットワーク・インターフェイスをカプセル化するため、ファイルオブジェクトによって使用される。このライブラリは、サーバへのブロック・インターフェイスを使用する。

Ｊ‐Ｉ／Ｏライブラリが、ローカルのバーチャルスライド・ファイルにアクセスするためファイルオブジェクトによって使用される。このライブラリは、ＴＩＦＦファイル・ヘッダ（タグ付き画像ファイル・フォーマット）の詳細をカプセル化している。

Ｋ‐バーチャルスライド画像ファイルをローカルに保存でき、ビューポートを使用してアクセスする（そして、イメージスコープを使用して閲覧する）ことができる。

Ｌ‐性能上の目的で、ブロック・キャッシュが、最近使用（ＭＲＵ）基準にもとづき、すべてのファイルオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。ブロック・キャッシュの大きさは、イメージスコープ装置上に構成されたメモリの量の関数であり、イメージスコープ・プログラムに渡されたパラメータによる。

Ｍ‐性能上の目的で、ファイル情報キャッシュが、すべてのファイルオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。

Ｎ‐性能上の目的で、領域キャッシュが、最近使用（ＭＲＵ）基準にもとづき、すべてのイメージオブジェクトを横断して保持される（このキャッシュは、１つのプログラム内の複数のビューポートにまたがる）。領域キャッシュの大きさは、イメージスコープ装置上に構成されたメモリの量の関数であり、イメージスコープ・プログラムに渡されたパラメータによる。

Ｏ‐ビューポートは、リアルタイムでの直角変形（９０°回転および鏡像反転）をサポートする。これらの変形は、レンダリング・エンジンにて適用される。

Ｐ‐ビューポートは、所望の任意の解像度へのリアルタイムでの拡大縮小をサポートする。この能力は、バーチャルスライド画像レベルの上に作られる。拡大縮小は、レンダリング・エンジンに作り込まれる。

Ｑ‐ビューポートは、リアルタイムでのフィルタ処理をサポートし、所定またはカスタム設定の５×５のコンボリューション・カーネルを画像に適用できる。フィルタ処理は、レンダリング・エンジンに作り込まれる。

Ｒ‐ビューポートは、リアルタイムでのガンマ調節をサポートし、実際に表示されるピクセルへのＲＧＢ値のカラーマッピングを、調節できるようにする。この能力は、バーチャルスライドが閲覧されるときの環境光およびモニタ特性の相違を補償するために、きわめて重要である。ガンマ調節は、レンダリング・エンジンに作り込まれる。

Ｓ‐ビューポートは、注釈レイヤーの表示および編集をサポートする。注釈の表示は、レンダリング・エンジンに作り込まれる。

Ｔ‐ビューポートは、表示されているバーチャルスライドについての画像データをレンダリング・エンジンの要求を先取りして動的に取り出す先読みスレッドを組み込んでなる。先読みのロジックが、現在のユーザの画像とのやり取りについて「動き」を割り出し、これを先読みを案内するために使用する（例えば、ユーザが画像を右へとスクロールしている場合、さらに右側の新しい画像データが先読みされる）。

Ｕ‐イメージスコープは、ＧＵＩスクリーン・マネージャとビューポート・コントローラとの間に位置するＶＭＣインターセプト（ＶＭＣ Ｉｎｔｅｒｃｅｐｔ）を含んでいる。ＶＭＣインターセプトは、ビューポートへのユーザ指令をＶＭＣサーバへと伝達し、さらにＶＭＣサーバからの指令を受け付けて、あたかもＧＵＩスクリーン・マネージャからのものであるようにビューポートへと供給する。

Ｘ‐イメージサーバ・インターフェイス
ビューポート／ファイルオブジェクト／ＴＣＰ／ＩＰライブラリが、イメージサーバへのＨＴＴＰ要求を生成し、応答としてバーチャル・ファイル・ブロックを受け取る。さらに、このインターフェイスは、画像属性を取り出すためにも使用される。

Ｙ‐ＶＭＣサーバ・インターフェイス
ＭＶＣインターセプトが、ＶＭＣサーバへのＨＴＴＰ要求を生成し、ＸＭＬフォーマットの応答を受け取る。このインターフェイスは、インターセプトした指令をＶＭＣサーバへと渡すために使用され（このアプリケーションがセッションを「リード」している場合）、ＶＭＣサーバからの指令を受信するために使用される（このアプリケーションが「従」である場合）。

図９Ｄは、ウェブビューアの各コンポーネントおよびそれらの間のインターフェイスを示し、以下に説明するとおりである。

ウェブビューア・ソフトウェアは、標準的なウェブ・サーバの元で動作し、ウェブ・ブラウザでスライド情報を閲覧するためのＨＴＭＬユーザ・インターフェイスを届ける。ＨＴＭＬページは、ウェブ・ブラウザにイメージサーバからのＪＰＥＧ画像情報を要求せしめる画像タグ（＜ＩＭＧ＞）を含んでいる。ＨＴＭＬページとＪＰＥＧ画像との組み合わせが、ウェブビューア・インターフェイスを構成する。

ウェブビューア・インターフェイスの重要な特徴は、追加のアプレット、プラグイン、または他のソフトウェアを一切必要とせず、あらゆる標準的なウェブ・ブラウザで利用できる点にある。これにより、きわめて可搬性に富んだ（事実上あらゆるプラットフォームで利用できる）ものとなり、新たなユーザも、すぐにバーチャルスライド・データを閲覧することができる。

Ａ‐ウェブ・ブラウザ
あらゆるプラットフォーム上のあらゆる標準的なブラウザがサポートされる。

Ｂ‐ウェブ・サーバ装置
これは、通常は、ウインドウズのもとで動作するマイクロソフト・インターネット・インフォメーション・サーバ（ＩＩＳ）、またはリナックスまたはユニックス（Ｕｎｉｘ（登録商標））のもとで動作するアパッチである。コーン・シェル（Ｋｏｒｎ Ｓｈｅｌｌ）をサポートするプラットフォーム上でＣＧＩインターフェイスをサポートするあらゆるウェブ・サーバが、サポートされる。

Ｃ‐ウェブビューア・スクリプト
これらは、ウェブ・サーバ・プロセスのもとで動作し、コモン・ゲートウェイ・インターフェイス（ＣＧＩ）を通じて惹起される。これらのスクリプトは、常駐のコーン・シェル・インタプリタを必要とする。ウェブビューアが、ウェブ閲覧のためのインターフェイスを有するＨＴＭＬページを構築し、インターフェイスからの入力（マウスのクリック）を処理する。

Ｄ‐ＣＧＩは、コモン・ゲートウェイ・インターフェイスであり、ウェブ環境にてＨＴＴＰ入力を処理して出力としてＨＴＭＬページ・コンテンツを生成するプログラムを動作させるためにウェブ・サーバによって提供される標準的な機構である。

Ｅ‐ウェブビューアは、バーチャルスライドの表示に使用されるＨＴＭＬを生成するＨＴＭＬページビルダ・モジュールを含んでいる。各スライド領域が、ウェブ・ブラウザが複数の画像サブ領域を並行して取り出すことができ、さらに画像サブ領域をキャッシュすることができるよう、多数の小さな領域から構成される。

Ｆ‐イメージサーバ・プロセスが、実際の画像データを提供する。画像属性が、ＨＴＭＬページビルダによって要求される。ＨＴＭＬページは、イメージサーバの画像データを要求するＵＲＬを含んでいるＩＭＧタグのアレイを含んでいる。これらのＵＲＬは、イメージサーバへの領域インターフェイスを使用してＪＰＥＧサブ領域を要求し、次いで、これらサブ領域がウェブ・ブラウザによって表示される。

Ｘ‐ウェブ・ブラウザとウェブ・サーバとの間のＨＴＴＰインターフェイスは、標準的である。ＨＴＴＰ要求がブラウザによって送信され、ＣＧＩを通じてウェブビューアへと導かれ、ＨＴＭＬページが生成されてブラウザへと返される。

Ｙ‐ウェブビューアは、画像属性を取得するため、イメージサーバへと直接にＨＴＴＰ要求を行なう。

Ｚ‐ウェブ・ブラウザは、ＨＴＭＬページに生成されたＩＭＧタグから、イメージサーバへとＨＴＴＰ要求を行なう。これらの要求は、イメージサーバへの領域インターフェイスを使用し、応答としてＪＰＥＧ画像が返される。

図９Ｅは、バーチャルスライド閲覧システムにおける注釈サポートの詳細な実装を、以下に説明するとおり示している。

このバーチャルスライド閲覧システムは、画像ごとに複数のレイヤー上の複数の注釈をサポートしている。注釈は、（ｉ）矩形領域、（ｉｉ）楕円形領域、（ｉｉｉ）特定のスポットを指し示す矢印、および（ｉｖ）任意の数の頂点を有する任意の多角形領域、という４つの形態のうちの１つをとる注釈領域で構成される。

領域は、常にバーチャルスライドのベースライン画像に対して配置され、解像度とは無関係である（すなわち、注釈領域が画像とともに拡大縮小される）。各注釈領域は、１つ以上の属性を、「ｋｅｙ＝ｖａｌｕｅ」のかたちで自身に関連付けて有することができる。「ｋｅｙ」のセットは、注釈内のすべての領域について同じである。

注釈内のすべての領域がまとまって、注釈レイヤーを構成する。注釈レイヤーは、画像上へのプラスチックの重ね合わせと考えることができる。各レイヤーを個々に表示でき、あるいは隠すことができる。レイヤーは、１つ以上の属性を、「ｋｅｙ＝ｖａｌｕｅ」のかたちで自身に関連付けて有することができる。注釈レイヤーについての「ｋｅｙ」は、任意の１つのレイヤーの領域についての「ｋｅｙ」と異なっていてもよい。

表示域コントローラが、画像注釈の表示を管理するためのプロパティおよび方法を提供する。画像データが表示のためにフォーマットされるとき、有効にされている注釈レイヤーが画像上に描かれる。

イメージスコープ・アプリケーションが、注釈を編集するためのＧＵＩツール一式を提供する。これらのツールを使用し、ユーザは、表示域コントローラの表面上のバーチャルスライドに注釈領域を対話的に「描く」ことができる。移動可能なウインドウが、注釈領域およびレイヤーに関する属性を入力するためのインターフェイスを提供する。

画像についてのすべての注釈は、ＸＭＬ文字列として保存される。表示域コントローラがＸＭＬ文字列をフォーマットし、これをローカル・ファイルとしてディスクに保存でき、あるいはデータベースへの保存のためにイメージサーバへと送信できる。同様に、注釈を、データベースまたはローカル・ファイルから取り出すことができる。

Ａ‐閲覧クライアント装置
イメージスコープが動作しているコンピュータ。

Ｂ‐イメージスコープ・ビューア
注釈の表示および編集のためのユーザ・インターフェイスを提供するアプリケーション。

Ｃ‐イメージサーバ装置
イメージサーバが動作しているコンピュータ。

Ｄ‐イメージサーバ・アプリケーション
注釈を含むバーチャルスライド画像データへのアクセスのためのネットワークＡＰＩを提供するプロセス。

Ｅ‐データベース
このＳＱＬデータベース（典型的には、ＭＳＤＥまたはＳＱＬサーバ）が、サーバ上に注釈情報を保存する。

Ｆ‐イメージスコープのＧＵＩスクリーン・マネージャ・コンポーネントが、注釈の編集に使用される入力ツールおよびマウスの動きを管理する。

Ｇ‐表示域コントローラが、注釈表示ロジックを含むバーチャルスライドへのすべてのアクセスをカプセル化する。注釈へのアクセスは、オープンＡＰＩによって提供される。

Ｈ‐ビューポート内の注釈ロジックが、バーチャルスライドについてのすべての注釈を、画像データ上に要求どおりに描く。

Ｉ‐表示域コントローラのレンダリング・エンジンが、表示のための画像領域を構成し、これが注釈表示ロジックへと渡される。

Ｊ‐バーチャルスライド・ファイルそのものへのアクセスをカプセル化するため、イメージオブジェクトが、各表示域コントローラ内でインスタンス作成される。

Ｋ‐イメージサーバと要求／応答の通信を行なうため、ＴＣＰ／ＩＰライブラリが、イメージオブジェクトによって使用される。

Ｌ‐イメージサーバの接続マネージャが、新規のソケット接続を受け付け、クライアントからのすべての要求を管理する。

Ｍ‐接続マネージャ内の認証レイヤーが、注釈についての要求を含む各要求について、認証証明を検証する。認証情報は、画像のための注釈レイヤーのそれぞれについて別個に保持され、すなわち、或る何人かのユーザが、或る幾つかのレイヤーについて読み出しのみのアクセスを有し、他のレイヤーについて更新アクセスを有してもよい。

Ｎ‐注釈要求は、ＨＴＴＰインターフェイスを使用してデータベース・サービスに渡される。

Ｏ‐データベース・サービスは、イメージサーバとデータベースとの間のインターフェイスを提供し、データベースを別個の装置上に配置してもよいようにする。

Ｐ‐イメージスコープ内のＶＭＣインターセプトが、表示域コントローラへのすべての指令をＶＭＣサーバへと導き（ユーザが、セッションの「リーダ」である場合）、さらに／あるいはＶＭＣサーバからの指令をビューポートへと導く（ユーザが、セッションの「追従者」である場合）。これは、注釈の表示および編集の指令を含んでいる。

図９Ｆは、以下に説明するバーチャルスライド閲覧システムにおけるＶＭＣサポートの内部の実装の詳細を示している。

ＶＭＣは、複数のユーザが同時に閲覧セッションに参加して同じバーチャルスライドを閲覧する技法である。各ユーザのビューが他のユーザのビューに同期され、すなわち全員が同じ情報を眺めることになる。

あらゆる瞬間について、各セッションにおいては１人のユーザがセッション「リーダ」であり、他のユーザは「追従者」である。リーダが、視点の移動および拡大縮小、ビューの変更、注釈の作成、などを実行し、これらの指令のそれぞれが、すべての追従者に伝達される。リーダは、いつでも、セッションのリーダシップを他の任意のユーザに譲り渡すことができる。追従者は、当該セッションのリーダになりたい旨をリーダに伝えることができる。ＶＭＣサーバが、各セッションについてリーダになることを希望する追従者の待ち行列を保持する（先入れ先出し（ＦＩＦＯ）の順番で）。リーダは、セッションのリーダシップを他のユーザに渡そうとするときに、特定のユーザを明示的に指名することができ、あるいは先頭で待っている追従者へとリーダシップを渡してもよい。

ＶＭＣセッションは、ＶＭＣサーバ装置を使用して確立される。ＶＭＣサーバへと接続する最初のユーザが、セッションを生成し、説明用の名称を与え、パスワードを割り当てる。ＶＭＣサーバへと接続する後続のユーザは、説明用の名称によってセッションを特定でき、パスワードを入力することによって参加をすることができる。同時にＶＭＣセッションに参加できるユーザの数に、制限はない。新規セッションを定めた最初のユーザが、最初のリーダになる。

必要であれば、特定のＶＭＣサーバへの接続のために認証を要求することができる。この認証は、サーバそのものにアクセスするためのものであり、個々のセッションは、固有のパスワードを最初に接続したユーザが確立したとおり有している。

新たなユーザが進行中のＶＭＣセッションに加わるとき、当該セッションのために現在開かれているあらゆる画像が、この新規ユーザのために開かれ、すべての表示窓が、当該セッションにおける現在の位置に同期させられる。

セッションにおいて、リーダは、１つ以上のバーチャルスライドを開くことができる。それらのスライドは、当該セッションのすべてのユーザにとってアクセスできるイメージサーバ上になければならない。画像が開かれるとき、セッションの他のすべてのユーザも、その画像を同時に開く。イメージサーバは、ＶＭＣサーバと同じ装置であってよいが、必ずしも同じ装置である必要はなく、同じ場所に位置している必要もない。

セッション・リーダが画像を閉じるとき、その画像は、セッションのすべてのユーザについても閉じられる。

セッション・リーダは、セッションの一部である任意の画像において、任意の位置および任意の倍率へと視点の移動および拡大縮小を行なうことができる。他のすべてのユーザは、これに自動的に倣う。閲覧ウインドウの寸法および構成は、個々のユーザが寸法の異なるモニタを使用している可能性がある点などを考慮するため、各ユーザの制御下に残される。各画像の配置は、常に閲覧ウインドウの中心を基準にする。

セッションにおいて、各ユーザのイメージサーバへの接続の帯域幅が異なっている可能性があり、この結果、視点移動および拡大縮小において、応答時間が異なる可能性がある。ビューポート更新の非同期の性質ゆえ、これらの操作において、最悪でも或るユーザが他のユーザと同じ解像度では画像ビューを眺めることができない（より高解像度のデータがサーバから取り出されるまで）だけであり、いずれのユーザも「阻止」されることがないようにされる。

イメージスコープ・ビューアのガンマ調節設備は、セッションのすべてのユーザについて同期されてはいない。これは、各ユーザが自身の好みに合わせて調節する余地を残している。これは、ガンマ調節が、通常は室内光およびモニタ温度ならびに個人の好みを補償するために行なわれるからであり、したがってリーダのガンマ設定をすべての追従者に渡しても意味がないからである。

セッション・リーダは、ＶＭＣセッションの一部として開かれたバーチャルスライドについて、注釈を有効および無効にすることができる。すべてのユーザが、同時に注釈を有効および無効にする。さらに、セッション・リーダは、新規の注釈レイヤーおよび領域を生み出すことができる。セッションの各ユーザは、部分的に完成したレイヤーおよび領域を見る。これは、注釈が本質的に一時的である可能性があるため、イメージサーバ上の注釈データベースを通じて同期をするのではなく、リーダの注釈コマンドをすべてのユーザに伝達することによって、達成される。

幾つかのセッションでは、１つの注釈レイヤー上で協働（リーダシップをお互いに渡すことによって）でき、他のセッションにおいては、各ユーザが自身の注釈レイヤーを有することができる。この決定は、セッションのユーザの責任である。

ユーザは、いつでもＶＭＣセッションを離れることができる。ユーザがセッションを離れるとき、当該セッションの一部であったすべての画像表示窓が閉じられる。そのユーザがセッション・リーダであった場合、待ち行列中の「次の」追従者が、セッション・リーダになる。リーダになるのを待っている追従者がいない場合、リーダはランダムに選ばれる（いずれの瞬間においても、１ユーザがセッション・リーダでなければならない）。

最後のユーザがＶＭＣセッションを離れることによって、当該セッションが終息する。サーバは、終息したセッションについてはいかなる情報も保持しない。

Ａ‐閲覧クライアント装置
各ユーザがイメージスコープ・ビューアを動作させているコンピュータ。

Ｂ‐イメージスコープ・ビューア
ＶＭＣセッションのためのクライアント・インターフェイスを実装するアプリケーション・プログラム。

Ｃ‐ＶＭＣサーバ装置
ＶＭＣサーバ・アプリケーションが動作しているコンピュータ。このコンピュータは、ＶＭＣセッションにおいて閲覧される画像を提供するイメージサーバ装置と同じであってよいが、必ずしも同じである必要はない。

Ｄ‐ＶＭＣサーバ・プロセス
イメージスコープ・ビューアを一体に相互接続することによってＶＭＣセッションを管理するアプリケーション。各クライアントは、ＴＣＰ／ＩＰによるＨＴＴＰ要求を使用してＶＭＣサーバと通信する。

Ｅ‐データベース
ＳＱＬデータベース（典型的には、ＭＳＤＥまたはＳＱＬサーバ）が、認証情報を保存する。これがＶＭＣサーバへとアクセスするための認証情報であり、イメージサーバ装置上の画像にアクセスするために必要とされる認証情報と相違していてよいことに、注意すべきである。

Ｆ‐イメージスコープのＧＵＩスクリーン・マネージャが、各ユーザに彼らのセッションを管理するためのインターフェイスを提供する。ユーザがセッションの「追従者」である場合、当該セッションにおいて開かれている画像の視点移動または拡大縮小あるいは注釈の作成を、行なうことはできない。

Ｇ‐ＶＭＣインターセプトが、ＧＵＩスクリーン・マネージャと表示域コントローラとの間に位置し、セッション・リーダによって与えられたすべての指令をＶＭＣサーバへと導く。セッションの追従者によって与えられたあらゆる指令は、無視される。さらに、ＶＭＣインターセプトは、セッションの追従者へのＶＭＣサーバからの指令を受信し、あたかもＧＵＩスクリーン・マネージャからのものであるように表示域コントローラへと導く。

Ｈ‐表示域コントローラは、バーチャルスライドへのすべてのアクセスをカプセル化する。このコントローラのプロパティおよび方法は、ＧＵＩとバーチャルスライドとの間（ならびにＶＭＣセッションとバーチャルスライドとの間）のインターフェイスである。各表示域コントローラが、ＶＭＣセッションの各画像についてイメージサーバへの接続を行なう点、およびそれらの接続がＶＭＣサーバへの接続とは別個である点に、注意すべきである。

Ｉ‐ＶＭＣサーバ・プログラム内の接続マネージャが、すべてのソケット接続を取り扱い、すべてのクライアント要求を処理する。永続のソケット接続が、各ＶＭＣセッションの動作中のクライアントのそれぞれへと保たれる（通常のＨＴＴＰ １．１要求と異なり、これらの接続はタイムアウトしない）。これにより、セッション・リーダからの指令を、各追従者のＶＭＣインターセプトへと非同期で送り返すことができる。

Ｊ‐ＶＭＣセッション・マネージャが、各ＶＭＣセッションにおける指令の流れを制御する（各ＶＭＣサーバ・プロセスが、複数のＶＭＣセッションを同時に管理してもよい）。

Ｋ‐ＶＭＣセッション・テーブルが、現在のリーダ、すべての画像表示窓の現在の状態、リーダになることを希望する追従者の待ち行列、など、活動中の各ＶＭＣセッションおよび各セッション中のすべてのユーザについて、情報を保存する。

Ｌ‐接続マネージャの認証レイヤーが、ＶＭＣサーバへと接続する新規ユーザのそれぞれについて認証証明を検証する。この認証は、サーバへのアクセスを可能にし、次いでユーザは、既存のセッションに参加するために正しいパスワードを提示しなければならない。

Ｍ‐データベース・サービスが、ＶＭＣサーバとデータベースとの間のインターフェイスを提供し、データベースを別個の装置上に配置してもよいようにする。

Ｘ‐イメージスコープ・クライアント（ＶＭＣインターセプト）とＶＭＣサーバ・プログラムとの間のインターフェイスは、ＴＣＰ／ＩＰによるＨＴＴＰである。各クライアントは、ＶＭＣセッションの間、サーバへの恒久的なソケット接続を有する。セッション・リーダであるクライアントが、サーバへと要求を送信し、応答を受信する。セッションの追従者であるクライアントは、サーバからの要求を受信し、応答を送信する。

図１０は、本明細書に記載の種々の実施の形態に関連して使用できる典型的なコンピュータ・システム９５０を示したブロック図である。例えば、コンピュータ・システム９５０を、すでに述べたとおりバーチャルスライド・サーバ、ウェブ・サーバ、または閲覧クライアントと関連して使用することができる。しかしながら、当業者にとっては明白であるとおり、他のコンピュータ・システムおよび／またはアーキテクチャも使用可能である。

コンピュータ・システム９５０は、好ましくは、プロセッサ９５２などの１つ以上のプロセッサを備えている。入／出力を管理するための補助プロセッサ、浮動小数点演算操作を行なうための補助プロセッサ、信号処理アルゴリズムの高速な実行のために適したアーキテクチャを有する特殊目的のマイクロプロセッサ（例えば、デジタル・シグナル・プロセッサ）、主処理システムに従属するスレーブ・プロセッサ（例えば、バックエンド・プロセッサ）、デュアルまたは複数プロセッサ・システムのための追加のマイクロプロセッサまたはコントローラ、あるいはコプロセッサなど、追加のプロセッサを設けてもよい。このような補助的なプロセッサは、別個のプロセッサであってよく、あるいはプロセッサ９５２と統合されてもよい。

プロセッサ９５２は、好ましくは通信バス９５４に接続される。通信バス９５４は、記憶領域とコンピュータ・システム９５０の他の周辺コンポーネントとの間の情報の伝達を容易にするため、データ・チャネルを含むことができる。さらに、通信バス９５４は、データ・バス、アドレス・バス、および制御バスなど（図示されていない）、プロセッサ９５２との通信に使用される信号一式を提供することができる。通信バス９５４は、例えばインダストリ・スタンダード・アーキテクチャ（「ＩＳＡ」）、拡張インダストリ・スタンダード・アーキテクチャ（「ＥＩＳＡ」）、マイクロ・チャネル・アーキテクチャ（「ＭＣＡ」）、ペリフェラル・コンポーネント・インターコネクト（「ＰＣＩ」）ローカル・バス、あるいはＩＥＥＥ４８８汎用インターフェイス・バス（「ＧＰＩＢ」）やＩＥＥＥ６９６／Ｓ‐１００などの米国電気電子技術者協会（「ＩＥＥＥ」）によって広められた規格に準拠したバス・アーキテクチャなど、任意の標準的または標準的でないバス・アーキテクチャからなることができる。

コンピュータ・システム９５０は、好ましくは主メモリ９９６を備えており、さらに二次メモリ９５８を備えることができる。主メモリ９９６は、プロセッサ９５２上で動作するプログラムのためのインストラクションおよびデータの記憶領域を提供する。主メモリ９９６は、通常は、ダイナミック・ランダム・アクセス・メモリ（「ＤＲＡＭ」）および／またはスタティック・ランダム・アクセス・メモリ（「ＳＲＡＭ」）などの半導体ベースのメモリである。半導体ベースの他の種類のメモリには、読み出し専用メモリ（「ＲＯＭ」）を含み、シンクロナス・ダイナミック・ランダム・アクセス・メモリ（「ＳＤＲＡＭ」）、ラムバス（Ｒａｍｂｕｓ）ダイナミック・ランダム・アクセス・メモリ（「ＲＤＲＡＭ」）、強誘電体ランダム・アクセス・メモリ（「ＦＲＡＭ」）、などがある。

二次メモリ９５８は、任意により、ハードディスク・ドライブ９６０、および／または例えばフロッピー（登録商標）ディスク・ドライブ、磁気テープ・ドライブ、コンパクトディスク（「ＣＤ」）ドライブ、デジタル多用途ディスク（「ＤＶＤ」）ドライブなどのリムーバブルストレージ・ドライブ９６２を備えることができる。リムーバブルストレージ・ドライブ９６２は、広く知られたやり方で、着脱可能な記憶媒体９６４からの読み出し、および／または着脱可能な記憶媒体９６４への書き込みを行なう。着脱可能な記憶媒体９６４は、例えば、フロッピー（登録商標）ディスク、磁気テープ、ＣＤ、ＤＶＤなどであってよい。

着脱可能な記憶媒体９６４は、好ましくは、コンピュータで実行可能なコード（すなわち、ソフトウェア）および／またはデータが保存されているコンピュータで読み取り可能な媒体である。着脱可能な記憶媒体９６４に保存されているコンピュータ・ソフトウェアまたはデータは、電気通信信号９７８としてコンピュータ・システム９５０に読み込まれる。

他の実施の形態においては、二次メモリ９５８が、コンピュータ・プログラムまたは他のデータあるいはインストラクションをコンピュータ・システム９５０へとロードできるようにするための他の同様の手段を備えることができる。そのような手段には、例えば、外部記憶媒体９７２およびインターフェイス９７０が含まれる。外部記憶媒体９７２の例としては、外部のハードディスク・ドライブまたは外部の光学式ドライブ、あるいは外部の光磁気ドライブがある。

二次メモリ９５８の他の例には、プログラマブル読み出し専用メモリ（「ＰＲＯＭ」）、消去可能プログラマブル読み出し専用メモリ（「ＥＰＲＯＭ」）、電気的に消去可能な読み出し専用メモリ（「ＥＥＰＲＯＭ」）、またはフラッシュメモリ（ＥＥＰＲＯＭに類似するブロック指向のメモリ）など、半導体ベースのメモリが含まれる。さらには、リムーバブルストレージ・ユニット９７２からコンピュータ・システム９５０へとソフトウェアおよびデータを伝送できる他の任意のリムーバブルストレージ・ユニット９７２およびインターフェイス９７０も含まれる。

さらに、コンピュータ・システム９５０は、通信インターフェイス９７４を含むことができる。通信インターフェイス９７４は、ソフトウェアおよびデータを、コンピュータ・システム９５０と外部の装置（例えば、プリンタ）、ネットワーク、または情報源との間で伝送できるようにする。例えば、コンピュータ・ソフトウェアまたは実行可能コードを、通信インターフェイス９７４を介してネットワーク・サーバからコンピュータ・システム９５０へと伝送することができる。通信インターフェイス９７４の例としては、いくつか例を挙げると、モデム、ネットワーク・インターフェイス・カード（「ＮＩＣ」）、通信ポート、ＰＣＭＣＩＡスロットおよびカード、赤外線インターフェイス、およびＩＥＥＥ１３９４ファイアワイヤ（ｆｉｒｅ‐ｗｉｒｅ）がある。

通信インターフェイス９７４は、好ましくは、イーサネット（登録商標）ＩＥＥＥ８０２規格、ファイバーチャネル（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ）、デジタル加入者線（「ＤＳＬ」）、非同期デジタル加入者線（「ＡＤＳＬ」）、フレームリレー、非同期転送モード（「ＡＴＭ」）、総合デジタル・サービス網（「ＩＳＤＮ」）、パーソナル通信サービス（「ＰＣＳ」）、伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）、シリアル線インターネット・プロトコル／ポイント・トゥー・ポイント・プロトコル（「ＳＬＩＰ／ＰＰＰ」）、など、この業界で普及しているプロトコル規格を実装するが、専用または非標準のインターフェイス・プロトコルを実装することも可能である。

通信インターフェイス９７４を介して伝送されるソフトウェアおよびデータは、一般に、電気通信信号９７８の形式である。これらの信号９７８は、好ましくは、通信チャネル９７６を介して通信インターフェイス９７４へともたらされる。通信チャネル９７６が信号９７８を運ぶが、いくつか例を挙げると、ワイヤまたはケーブル、光ファイバ、従来からの電話線、携帯電話リンク、無線（ＲＦ）リンク、または赤外線リンクなど、種々の通信手段を使用して実装することができる。

コンピュータで実行可能なコード（すなわち、コンピュータ・プログラムまたはソフトウェア）が、主メモリ９９６および／または二次メモリ９５８に記憶される。さらに、コンピュータ・プログラムを、通信インターフェイス９７４を介して受信して、主メモリ９９６および／または二次メモリ９５８に記憶することができる。そのようなコンピュータ・プログラムを実行することで、コンピュータ・システム９５０は、すでに説明したとおり本発明のさまざまな機能を実行することができる。

本明細書において、「コンピュータで読み取り可能な媒体」という用語は、コンピュータで実行可能なコード（例えば、ソフトウェアおよびコンピュータ・プログラム）をコンピュータ・システム９５０へともたらすために使用されるあらゆる媒体を指して使用されている。それら媒体の例には、主メモリ９９６、二次メモリ９５８（ハードディスク・ドライブ９６０、リムーバブル記憶媒体９６４、および外部の記憶媒体９７２を含む）、および通信インターフェイス９７４に通信可能に接続される任意の周辺機器（ネットワーク情報サーバまたは他のネットワーク装置を含む）が含まれる。これらコンピュータで読み取り可能な媒体は、コンピュータ・システム９５０に実行可能コード、プログラミング・インストラクション、およびソフトウェアをもたらすための手段である。

ソフトウェアを使用して実装される一実施の形態においては、当該ソフトウェアをコンピュータで読み取り可能な媒体に保存し、リムーバブルストレージ・ドライブ９６２、インターフェイス９７０、または通信インターフェイス９７４によって、コンピュータ・システム９５０にロードすることができる。そのような実施の形態においては、ソフトウェアが、電気通信信号９７８の形式でコンピュータ・システム９５０へとロードされる。プロセッサ９５２によって実行されるとき、当該ソフトウェアが、本明細書にてすでに説明した本発明の特徴および機能を、プロセッサ９５２に実行せしめる。

さらに、さまざまな実施の形態を、例えば特定用途向け集積回路（「ＡＳＩＣ」）またはフィールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）などのコンポーネントを使用して、ハードウェア主体で実装することも可能である。本明細書に記載の機能を実行できるハードウェア状態機械の実装も、当業者にとって明らかであろう。さらに、種々の実施の形態を、ハードウェアおよびソフトウェアの両者の組み合わせを使用して実装することも可能である。

本明細書に示して詳しく説明した特定のシステムおよび方法は、本発明の前記目的を完全に達成することができるが、本明細書に提示した説明および図面が本発明の現時点での好ましい実施の形態を示したものであって、本発明が広く想定する主題の代表であることを、理解すべきである。さらに、本発明の技術的範囲が、当業者にとって自明になるであろう他の実施の形態を完全に包含しており、したがって本発明の技術的範囲は、添付の特許請求の範囲以外のなにものによっても限定されないことを、理解すべきである。

Claims (27)

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. 前記バーチャルスライド画像ファイルが、タグ付き画像ファイル・フォーマット規格を使用して保存される請求項２０に記載のバーチャルスライド画像ファイルの構造。

Images