(57)【特許請求の範囲】
【請求項１】
画像処理システム内の１以上のウェブブラウザに採用されるＨＴＭＬ５の機能を有効にしつつ、大きな画像ファイルを処理するように構成された画像処理システムであって、前記画像処理システムは、
生の、処理された、または部分的に処理された画像ファイル、および、前記画像ファイルに関連付けられたメタデータを保存するように構成されたファイルサーバであって、ウェブビューアキャッシュを備え、前記ウェブビューアキャッシュが、動的に保存される前記ファイルおよびメタデータが、最も多く使用されるもの、および／または、近い将来に使用される可能性が最も高いものに限られるように、このようなファイルおよびメタデータを動的に保存するように構成されたファイルサーバと、
可用性および処理能力に応じて割り当てられたとおりに、画像処理機能の一部または全てを実行するように構成された複数の専用のウェブサーバであって、プリフェッチ画像処理部とリアルタイム画像処理部とを備え、前者は、クライアント側のユーザによる後のアクセスのためにウェブビューアキャッシュに保存するべく画像を読出および処理するように構成され、後者は、クライアント側のユーザによるリアルタイムアクセスのためにウェブビューアキャッシュに保存するべく画像を読出および処理するように構成された複数の専用のウェブサーバと、
を備え、
前記画像処理システムは、独立したサーバおよび／または専用の記憶装置に格納された専用の画像アーカイブと、複数のクライアント側のコンピュータのユーザとを、インターフェースするように構成されており、前記複数のコンピュータのそれぞれは、ＨＴＭＬ５の機能を採用するウェブブラウザを備える画像処理システム。
【請求項２】
請求項１に記載の画像処理システムであって、
前記システムは、それぞれが前記画像処理機能の一部または全てを行うように構成された複数のウェブサーバの間で処理作業負荷を分配することによって、１以上のクライアント側のユーザによる同時の、同一または異なる画像セットからの多数画像を、効率的に処理するように構成され、前記システムはさらに、ロードバランササーバであって、クライアント側のコンピュータからの１以上のウェブブラウザとのインターフェースを専門に行い、プリフェッチ画像処理リクエストまたはリアルタイム画像処理リクエストが、前記クライアント側のコンピュータのユーザによって作成されたかどうかにかかわらず、前記専用のウェブサーバによる画像の読出および処理を、指示、分配、および管理するロードバランササーバを備え、前記専用のウェブサーバは、前記ウェブサーバの可用性および処理能力に応じて前記ロードバランササーバによって割り当てられたとおりに、前記画像処理機能の一部または全部を実行するように構成される画像処理システム。
【請求項３】
請求項１に記載の画像処理システムであって、
画像アーカイブと、ＨＴＭＬ５の機能を採用するウェブブラウザを備える複数のクライアント側のコンピュータと、をさらに備える画像処理システム。
【請求項４】
請求項１に記載の画像処理システムであって、
前記複数のウェブサーバの少なくとも１つは、前記ウェブビューアキャッシュおよび／または前記画像アーカイブに保存された１以上の画像セットに関連付けられたタイムスタンプを検知し、前記クライアント側のコンピュータのユーザがこのような１以上の画像セットの最新のバージョンを閲覧することが可能となるように、１以上の画像セットのいずれが最新のものであるかを判定するように構成される画像処理システム。
【請求項５】
請求項３に記載の画像処理システムであって、
医用環境においてＤＩＣＯＭ画像を処理するように構成される画像処理システム。
【請求項６】
請求項４に記載の画像処理システムであって、
前記少なくとも１つのウェブサーバは、複数画像を、タイムスタンプに関連付けられた画像の系列に整理するように構成され、前記系列は、調査報告内にファイルされる画像処理システム。
【請求項７】
請求項３に記載の画像処理システムであって、
医用環境においてＤＩＣＯＭ画像を処理するように構成される画像処理システム。
【請求項８】
画像処理システム内の１以上のウェブブラウザに採用されるＨＴＭＬ５の機能を有効にしつつ、大きな画像ファイルを処理する方法であって、当該画像ファイル処理方法は、
生の、処理された、または部分的に処理された画像ファイルおよび前記画像ファイルに関連付けられたメタデータを、ウェブビューアキャッシュであって、動的に保存される前記ファイルおよびメタデータが、最も使用されるもの、および／または、近い将来に使用される可能性が最も高いものに限られるように、このようなファイルおよびメタデータを動的に保存するように構成されたウェブビューアキャッシュ、を備えるファイルサーバに保存することと、
複数の専用のウェブサーバであって、前記複数のウェブサーバが、プリフェッチ画像処理部とリアルタイム画像処理部とを備え、前者が、クライアント側のユーザによる後のアクセスのために、ウェブビューアキャッシュに保存するべく画像を読出および処理するように構成され、後者が、クライアント側のユーザによるリアルタイムアクセスのために、ウェブビューアキャッシュに保存するべく画像を読出および処理するように構成された前記複数の専用のウェブサーバの１つであるウェブサーバを用いて、少なくとも画像処理機能の一部を実行することと、を備え、
前記画像処理システムは、独立したサーバおよび／または専用の記憶装置に格納された専用の画像アーカイブと、複数のクライアント側のコンピュータのユーザと、をインターフェースするように構成され、前記複数のコンピュータのそれぞれは、ＨＴＭＬ５の機能を採用するウェブブラウザを備える画像ファイル処理方法。
【請求項９】
請求項８に記載の画像ファイル処理方法であって、
前記システムは、それぞれが前記画像処理機能の一部または全てを行うように構成された複数のウェブサーバの間で処理作業負荷を分配することによって、１以上のクライアント側のユーザによる同時の、同一または異なる画像セットからの多数画像を、効率的に処理するように構成され、前記方法はさらに、プリフェッチ画像処理リクエストまたはリアルタイム画像処理リクエストが、前記クライアント側のコンピュータのユーザによって作成されたかどうかにかかわらず、前記専用のウェブサーバによる読出および処理を、クライアント側のコンピュータからの１以上のウェブブラウザとのインターフェースを専門に行うロードバランササーバを用いてバランシングすること、を備え、前記専用のウェブサーバは、前記ウェブサーバの可用性および処理能力に応じて前記ロードバランササーバによって割り当てられたとおりに、前記画像処理機能の一部または全部を実行するように構成される画像ファイル処理方法。
【請求項１０】
請求項８に記載の画像ファイル処理方法であって、
画像アーカイブと、ＨＴＭＬ５の機能を採用するウェブブラウザを備える複数のクライアント側のコンピュータと、をさらに備える画像ファイル処理方法。
【請求項１１】
請求項８に記載の画像ファイル処理方法であって、
前記複数のウェブサーバの少なくとも１つは、前記ウェブビューアキャッシュおよび／または前記画像アーカイブに保存された１以上の画像セットに関連付けられたタイムスタンプを検知し、前記クライアント側のコンピュータのユーザがこのような１以上の画像セットの最新のバージョンを閲覧することが可能となるように、１以上の画像セットのいずれが最新のものであるかを判定するように構成される画像ファイル処理方法。
【請求項１２】
請求項１１に記載の画像ファイル処理方法であって、
前記方法は、医用環境においてＤＩＣＯＭ画像を処理するために使用可能である画像ファイル処理方法。
【請求項１３】
請求項１２に記載の画像ファイル処理方法であって、
前記少なくとも１つのウェブサーバは、複数画像を、タイムスタンプに関連付けられた画像の系列に整理するように構成され、前記系列は、調査報告内にファイルされる画像ファイル処理方法。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
［関連出願］
本願は、２０１２年７月４日に発明者らにより提出された米国特許出願第１３／５４１，７１９号、および、２０１２年１２月３日に発明者らにより提出された米国特許出願第１３／６９２，９１６の優先権を主張し、これらの出願の全内容は、参照により本願に援用される。
【０００２】
［背景］
本願の実施形態は、概して、ＨＴＭＬ５技術を通常用いて大きな医用画像の保存および読出を容易にする改良されたウェブサーバに関し、具体的には、その容易にする機能を実現し、複数のサーバが用いられる場合には、複数のウェブサーバの負荷をバランシングさせるように構成されたインベンティブ的なウェブサーバキャッシュの構成に関する。
【０００３】
背景として、読み手の利益のために定義しておくのがよいいくつかの用語が、ここでは用いられる。その点に関して、ウェブサーバは、インターネットを介してアクセス可能なウェブコンテンツの伝達を助けるハードウェア（コンピュータ）またはソフトウェア（コンピュータアプリケーション）のいずれかを指し得る。ウェブサーバの最も一般的な利用方法は、ウェブサイトを提供することであるが、ゲーミング、データ保存またはエンタープライズアプリケーションを実行する等、他の利用方法もある。ウェブサーバの主要な機能は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いてクライアントによりリクエストされたウェブページを読み出すことである。これは、ＨＴＭＬドキュメントや、画像、スタイルシートおよびスクリプト等の、ドキュメントに含まれ得る付加的なコンテンツを届けるということである。
【０００４】
ユーザエージェント、一般的にはウェブブラウザまたはウェブクローラは、ＨＴＴＰを用いて特定のリソースをリクエストすることによって通信を開始し、サーバは、そのリソースのコンテンツ、またはそれが不可能な場合はエラーメッセージで応答する。リソースは、通常サーバの補助記憶装置上の実ファイルであるが、必ずしもそうである必要はなく、ウェブサーバがどのように実行されているかによる。主要な機能がコンテンツ配信であるのに対して、ＨＴＴＰの完全な実行には、クライアントからコンテンツを受信する方法も含む。この機能は、ファイルのアップロードを含む、ウェブフォームの送信、および、本発明の実施形態のケースでは、非同期ＪａｖａスクリプトおよびＸＭＬ（ＡＪＡＸ）リクエスト（例えば、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ａｊａｘ（プログラミング）参照）に用いられる。
【０００５】
多数の一般的なウェブサーバはまた、アクティブサーバページ（ＡＳＰ）、ＰＨＰ、または、他のスクリプティング言語を用いて、サーバ側のスクリプティングをサポートする。これは、実際のサーバソフトウェアが変化しないまま、ウェブサーバの挙動が個別のファイルでスクリプトされるということである。通常、この機能は、動的にＨＴＭＬドキュメントを作成するために用いられ、静的ドキュメントを返すのとは対照的である。前者は、データベースからの情報を読み出すために、および／または、修正するために主に用いられる。後者は、一般に、より早くかつ簡単にキャッシュされる。
【０００６】
ウェブサーバは、常にワールドワイドウェブの提供のために用いられるわけではない。ウェブサーバは、プリンタ、ルータ、ウェブカメラ等の装置に埋め込まれ、ローカルネットワークにのみ対応することも見受けられる。ウェブサーバは、その場合、当該装置を監視および／または管理するためのシステムの一部として用いられ得る。これは、通常、ウェブブラウザのみが必要とされ、追加のソフトウェアをクライアントコンピュータにインストールする必要が全くないということを意味する。
【０００７】
ウェブブラウザは、ワールドワイドウェブ上の情報リソースを引き出し、提示および横断するためのソフトウェアアプリケーションである。情報リソースは、統一資源識別子（ＵＲＬ）によって識別され、ウェブページ、画像、ビデオまたはその他のコンテンツ片であり得る。リソースの中に存在するハイパーリンクによって、ユーザは、容易に関連するリソースまで、ブラウザをナビゲートすることが可能である。ブラウザは、主にワールドワイドウェブの使用を意図しているが、ブラウザは、プライベートネットワーク内のウェブサーバ、または、ファイルシステム内のファイルによって提供される情報へのアクセスに用いられてもよい。ウェブブラウザの例には、ＧｏｏｇｌｅＣｈｒｏｍｅ（登録商標）、ＭｏｚｉｌｌａＦｉｒｅｆｏｘ（登録商標）、インターネットエクスプローラ（登録商標）、Ｏｐｅｒａ（登録商標）、およびＳａｆａｒｉ（登録商標）が含まれる。
【０００８】
ＨＴＭＬ５は、ワールドワイドウェブのコンテンツを構成および提示するために用いられるマークアップ言語であり、インターネットのコア技術である。ＨＴＭＬ５は、ＨＴＭＬ規格（１９９０年に作成、１９９７年現在ＨＴＭＬ４で標準化）の第５次改訂版である。その主要な目的は、人間が容易に読むことが可能で、かつ、コンピュータおよびデバイス（ウェブブラウザ、パーサ等）によって一貫して理解されるようにしつつ、最新のマルチメディアのサポートにより言語を改善することである。ＨＴＭＬ５は、ＨＴＭＬ４だけでなく、ＸＨＴＭＬ１およびＤＯＭ  Ｌｅｖｅｌ２  ＨＴＭＬも包含するようになっている。
【０００９】
その直近の先行版のＨＴＭＬ４．０１およびＸＨＴＭＬ１．１に続いて、ＨＴＭＬ５は、ワールドワイドウェブで一般的に使用されるＨＴＭＬおよびＸＨＴＭＬが、ウェブブラウザなどのソフトウェア製品によって導入された特徴、一般的な方法によって確立された特徴、および既存のＷｅｂ文書に存在する多くの構文エラー等と共に、様々な仕様によって導入された特徴を混ぜ合わせたものであるという事実に対する反応である。また、ＨＴＭＬまたはＸＨＴＭＬ構文のいずれかに記述可能な、１つのマークアップ言語を定義するための試みでもある。ＨＴＭＬ５には、相互運用が可能な方法をより奨励するため、詳細な処理モデルが含まれる。ＨＴＭＬ５は、ドキュメントに利用可能なマークアップを拡張、改善、および、合理化し、複雑なＷｅｂアプリケーションに、マークアップとアプリケーションプログラミングインターフェース（ＡＰＩ）とを導入する。以下に説明されるように、この特徴は、以下に詳細に記載されるように本発明の実施形態で採用されている。なぜなら、ＨＴＭＬが、ＪａｖａＳｃｒｉｐｔで書かれ、ブラウザ内で実行されるＷｅｂアプリケーションのフロントエンドとして使用されるためである。よって、ブラウザによって読み出されるＨＴＭＬページには、
ａ．アプリケーションのロジックを実行し、ユーザ入力に基づいてＡＪＡＸリクエストを用いてウェブサーバから情報を動的に読み出し、インターフェースをアップデートするＪａｖａスクリプトコードと、
ｂ．アプリケーションのインターフェース（ボタン、テキスト、レイアウト等）を定義するＨＴＭＬ５と、が含まれる。アプリケーションインターフェースのコンテンツは、ＨＴＭＬ５  ＡＰＩを呼び出し、ＨＴＭＬ５オブジェクトの作成および／または破壊を行うＪａｖａスクリプトによって動的に変更される。
【００１０】
背景情報に戻ると、従来のロードバランシングは、コンピュータ、コンピュータクラスタ、ネットワークリンク、中央処理装置やディスクドライブ等の複数のコンピューティングリソースで作業負荷を分配するコンピュータネットワーキング方式である。ロードバランシングは、リソースの使用を最適化し、スループットを最大化し、応答時間を最小にし、いずれのリソースの過負荷を回避することを目的とする。１つのコンポーネントの代わりに、ロードバランシングで複数のコンポーネントを使用することは、冗長性によって信頼性を高め得る。ロードバランシングは、通常、マルチレイヤスイッチまたはドメインネームシステムサーバプロセス等の、専用のソフトウェアまたはハードウェアによって提供される。
【００１１】
医療におけるデジタル画像と通信  Ｄｉｇｉｔａｌ  Ｉｍａｇｉｎｇ  ａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｉｎ  Ｍｅｄｉｃｉｎｅ（ＤＩＣＯＭ）は、医用画像情報のハンドリング、保存、印刷、および伝送を行うための規格である。ＤＩＣＯＭは、ファイルフォーマット定義およびネットワーク通信プロトコルを含む。ＤＩＣＯＭは、多数のメーカーのスキャナ、サーバ、ワークステーション、プリンタ、およびネットワークハードウェアの、画像アーカイビング通信システム（ＰＡＣＳ）への統合を可能にする。様々な装置には、サポートするＤＩＣＯＭクラスを特定するＤＩＣＯＭ適合性宣言書が付属する。ＤＩＣＯＭは、病院で広く使用されており、歯科医院や診療所などの小規模用途にも進出している。
【００１２】
病院環境において、とりわけ、デジタル画像をアーカイブし、デジタル画像を処理するように機能するウェブサーバ（すなわち、画像アーカイブ）上で提供される医用画像を、ウェブブラウザを用いて閲覧することによって、それらの画像を閲覧することは、非常に一般的なことである。医用画像はＤＩＣＯＭ形式であることが最も多く、通常は非常に大きなサイズのファイルである。図１Ａおよび１Ｂを参照すると、ＤＩＣＯＭ画像（または他の形式のファイル）は、ＤＩＣＯＭネットワーク、または他のインターネットまたはネットワークパスウェイ２を介して、専用のウェブサーバ３に接続されたＤＩＣＯＭアーカイブ１（またはアーカイブもしくは他のフォーマッタファイル）に保存され、ウェブサーバ３は、コンピュータモニタ６等のビューアに対してＨＴＭＬを用いるウェブブラウザ５を使用するコンピュータ４へ伝送するために当該画像を処理する。いくつかのケースでは、当該画像は、臨床医がコンピュータを介してアクセス可能な遠隔のウェブサイト上に、または、臨床医のコンピュータに関連付けられたローカルメモリに、保存される。
【００１３】
ｊｐｅｇ画像は８ビット（よって０から２５６まで）しかないのに対し、ＤＩＣＯＭ画像は、各画素あたり１６ビットまで（よって０から６５５３６まで）の値を保存する。通常のコンピュータモニタは、通常２５６値のみを表示することが可能であるため、このことは重要である。したがって、ＤＩＣＯＭ画像を表示する場合、システムは、どのように０から６５５３６までの１６ビット値を２５６値にマッピングするかを決定しなければならない。この動作は「ウィンドウレベル」と呼ばれ、医用画像に対して非常に頻繁に行われる。これによって画像の明るさおよびコントラストを視覚的に変更することができる。当該ウィンドウレベルは通常、特定の解剖学的構造を画像で見るために、医師によって設定される。医用画像の閲覧の際に、臨床医は表示パラメータ（明るさ、コントラスト、およびズーム等）を何度も変える。その他の動作には、最も該当する部分を視覚化するための画像のパニング、および／または、画像の計測も含まれる。
【００１４】
従来のＤＩＣＯＭ画像ファイルのサイズを想定すれば、従来のウェブブラウザは、ＤＩＣＯＭ画像を読み出し、伝送することは不可能である。ＨＴＭＬ４規格では、ウェブサーバ上に存在するウェブページを単に表示することが可能である。これは「ｉｍｇ」タグを用いることによって達成される。この制限下で、ウェブサーバは、パニング、ズームおよびウィンドウレベル等の、全ての画像操作を行わなければならない。よって、ＨＴＭＬ４言語を用いる多くの病院のコンピュータシステムは、サーバ側のレンダリングに依存しており、そのことが処理を遅くしている。
【００１５】
図１Ｂを参照すると、サーバ側レンダリングの一例には、ＤＩＣＯＭ画像を専用のウェブサーバを用いて圧縮画像（例えば、ｊｐｅｇ）に操作することが含まれる。ｊｐｅｇ画像を伝送可能であるユーザの（または病院のシステムの）ウェブブラウザは、その後画像を読み出すのに用いることが可能であり、それにより、クライアントは、当該画像の質および／または効果を変化させることによって画像を改良し得る。このインフラストラクチャを用いて、ウェブサーバは、ウェブブラウザによってより容易にアクセスおよび伝送される画像を作成するレンダリングエンジンとして機能する。このように、ウェブブラウザは、ウェブサーバのキャッシュ内の画像ファイルに直接アクセスせず、むしろ専用のウェブサーバによって処理されたオリジナルの画像ファイルの「レンダリングされた」バージョンにアクセスする。通常のトランザクションは、次のように進み得る。即ち、ウェブブラウザが、画像を閲覧するためにリクエストをする。画像がＤＩＣＯＭアーカイブからウェブサーバへと伝送される。画像がｊｐｅｇ（またはそれと同等のもの）に変換され、ウェブブラウザに対して利用可能となる。ウェブブラウザは、特定の操作（レンダリング）が当該画像に適用されるようにリクエストする。ウェブサーバは、リクエストされた操作を適用して、ウェブブラウザ６に対して利用可能な変換画像（例えば、変換したｊｐｅｇ画像）を作成し、変換された画像は、その後ユーザが当該画像を閲覧するのに用いられる。
【００１６】
新しいＨＴＭＬ５規格では、ウェブページが、画像をウェブサーバからそれらをリクエストする必要なく、生成および表示することが可能である。これは、「ｃａｎｖａｓ」タグを用いることによって達成される。本発明の実施形態は、以下にさらに説明されるように、この特徴およびその他の特徴を利用して、ウェブブラウザ、より具体的にはウェブページに含まれるＪａｖａスクリプトコードを用いて、ウェブサーバから表示用の画像の１６ビットデータを読み出し、ユーザによってローカルに設定された表示パラメータ（ウィンドウレベル、パニングおよびズーム）を適用して画像を表示することが可能である。ディスプレイに依存した操作は、専用のウェブサーバからの処理を必要とせずに、ウェブブラウザを用いてローカルに行われる。
【００１７】
［概要］
画像処理システムの実施形態が提供され、画像処理システムは、当該画像処理システム内の１以上のウェブブラウザに採用されるＨＴＭＬ５の機能を有効にしつつ、大きな画像ファイルを処理するように構成され、当該システムは、好ましくは、それぞれが画像処理機能の一部または全てを行うように構成された複数のウェブサーバの間で処理作業負荷を分配することによって、１以上のクライアント側のユーザによる同時の、同一または異なる画像セットからの多数（ｍｕｌｔｉｐｌｅ）画像を、効率的に処理するように構成される。いくつかの実施形態において、画像処理システムは、生（ｎａｔｉｖｅ）の、処理された、または部分的に処理された画像ファイル、および、画像ファイルに関連付けられたメタデータを保存するように構成されたファイルサーバであって、ウェブビューアキャッシュを備え、ウェブビューアキャッシュが、動的に保存されるファイルおよびメタデータが、最も多く使用されるもの、および／または、近い将来に使用される可能性が最も高いものに限られるように、このようなファイルおよびメタデータを動的に保存するように構成されたファイルサーバと、可用性および処理能力に応じて割り当てられたとおりに、画像処理機能の一部または全てを実行するように構成された複数の専用のウェブサーバであって、プリフェッチ画像処理部（ｐｒｏｃｅｓｓｏｒ）とリアルタイム画像処理部（ｐｒｏｃｅｓｓｏｒ）とを備え、前者は、クライアント側のユーザによる後のアクセスのためにウェブビューアキャッシュに保存するべく画像を読出および処理するように構成され、後者は、クライアント側のユーザによるリアルタイムアクセスのためにウェブビューアキャッシュに保存するべく画像を読出および処理するように構成された複数の専用のウェブサーバと、ロードバランササーバであって、クライアント側のコンピュータからの１以上のウェブブラウザとのインターフェースを専門に行い、プリフェッチ画像処理リクエストまたはリアルタイム画像処理リクエストが、クライアント側のコンピュータのユーザによって作成されたかどうかにかかわらず、専用のウェブサーバによる画像の読出および処理を、指示、分配、および管理するロードバランササーバと、を備え、当該画像処理システムは、独立したサーバおよび／または専用の記憶装置（ｍｅｍｏｒｙ）に格納された専用の画像アーカイブと、複数のクライアント側のコンピュータのユーザと、をインターフェースするように構成され、複数のコンピュータのそれぞれは、ＨＴＭＬ５の機能を採用するウェブブラウザを備える。
【図面の簡単な説明】
【００１８】
本発明のいくつかの実施形態の詳細な説明が、添付の図面を参照して以下に説明される。類似の符号は、図の対応する部分を示している。
【図１Ａ−１Ｂ】図１Ａおよび１Ｂは、通常サーバ側レンダリングと呼ばれる、従来技術のシステムの動作の概略図およびフローチャートである。
【図２Ａ】図２Ａおよび２Ｂは、クライアント側レンダリングシステムとして機能する本発明の一実施形態のシステム及び動作の概略図、および、対応するフローチャートを示し、ここでは、病院環境において臨床医にリクエストされたＤＩＣＯＭ画像を含む１以上の調査報告（ｓｔｕｄｙ）を効率的に処理するために、１以上の専用のウェブサーバが、ロードバランササーバ、および、ＨＴＭＬ５の機能を採用する１以上のウェブブラウザと共に用いられている。
【図２Ｂ】図２Ａおよび２Ｂは、クライアント側レンダリングシステムとして機能する本発明の一実施形態のシステム及び動作の概略図、および、対応するフローチャートを示し、ここでは、病院環境において臨床医にリクエストされたＤＩＣＯＭ画像を含む１以上の調査報告（ｓｔｕｄｙ）を効率的に処理するために、１以上の専用のウェブサーバが、ロードバランササーバ、および、ＨＴＭＬ５の機能を採用する１以上のウェブブラウザと共に用いられている。
【図３】図３は、図２Ａおよび２Ｂに示される実施形態を含む本発明の実施形態で実行される、プリフェッチおよびリアルタイムリクエストの動作のフローチャートである。
【図４】図４は、ウェブビューアキャッシュの一実施形態に保存された調査報告の内容の一例を示す。
【図５Ａ】図５Ａおよび５Ｂは、本発明の実施形態において用いられる４つの一連のステップの例を、動作の詳細と共に含む、１つのフローチャートを示している。
【図５Ｂ】図５Ａおよび５Ｂは、本発明の実施形態において用いられる４つの一連のステップの例を、動作の詳細と共に含む、１つのフローチャートを示している。
【図６Ａ】図６Ａおよび６Ｂは、本発明の実施形態の動作の詳細を含むフローチャートを示す。
【図６Ｂ】図６Ａおよび６Ｂは、本発明の実施形態の動作の詳細を含むフローチャートを示す。
【発明を実施するための形態】
【００１９】
［発明の詳細な説明］
本発明の実施形態は、複数のウェブサーバと、ロードバランササーバと、ウェブビューアキャッシュサーバと、１以上のコンピュータからアクセス可能なウェブブラウザと、の組み合わせを備える。ウェブブラウザ、ひいては当該実施形態は、ＨＴＭＬ５の機能の一部を利用し、医用画像の閲覧をより効率的にしている。インベンティブな実施形態での使用が想定されたウェブブラウザは、ＨＴＭＬ５画像に導入された新しい‘ｃａｎｖａｓ’タグで、画像を機能的にレンダリング可能であるため、ウェブサーバの役割は、サーバ側レンダリングマシンから、データを前処理し、その結果をウェブキャッシュに保存する、すなわち、医用画像を、ＨＴＴＰを使用して転送可能なフォーマットへと変換する、データプロセッサへと変化する。高いレベルでは、当該処理は、例えばＡＪＡＸを用いて、情報をＨＴＭＬページのＪａｖａスクリプトによって容易に読出可能なように、ＤＩＣＯＭファイルを解析（ｐａｒｓｉｎｇ）することを備える。あるケースでは、ウェブブラウザは、画像のピクセルデータ（１６ビット）を抽出し、ＤＩＣＯＭタグを画像から抽出し、これらをウェブブラウザウェブページによってすばやくアクセス可能となるようにＪＳＯＮに保存し得る。その他のケースでは、ウェブサーバは、当該画像のサムネイル等の補助ファイルを作成してもよく、クライアント側では、ユーザは表示パラメータを変更してもよく、これは、従来技術ではサーバで処理していたが、ここではウェブブラウザで処理可能である。
【００２０】
本発明のいくつかの実施形態は、画像処理が表示調整から独立しているということを利用した、プリフェッチ機能を備える。このような機能を用いて、１以上のウェブサーバは、リアルタイムよりもむしろ、いずれ近いうちにリクエストされる可能性がある画像を、事前に前処理するように構成される。当然のことながら、ウェブサーバは、画像をリアルタイムでも、すなわち、ユーザが特定の画像にアクセスすることをリクエストした時に、当該リクエストの時点で処理するように構成される。よって、本発明のいくつかの実施形態は、複数のウェブサーバによるリアルタイム処理およびプリフェッチ処理の両方を備える。その点に関して、とりわけ多数のクライアント側のユーザが同一または異なる調査報告内のＤＩＣＯＭ画像へのアクセスを求めている状況において、１以上のウェブサーバによって行われる作業負荷を分配および管理し、これにより処理を最適化するために、ロードバランササーバがいくつかの実施形態において設けられることが好ましい。
【００２１】
図２Ａを参照すると、１つの例示的な実施形態において、クライアント側システム１０は、ＨＴＭＬ５ソフトウェアを採用するウェブブラウザ２２と、画像を閲覧するためのモニタ２４と、を備える１以上のコンピュータ２０を備える。クライアント側システム１０は更に、病院情報システム（ＨＩＳ）３０および／または放射線科情報システム（ＲＩＳ）４０と、ＤＩＣＯＭアーカイブ５０と、を備えてもよく、ここでは、コンピュータ２０が、ＨＩＳ３０またはＲＩＳ４０の中もしくは外にある。換言すると、閲覧コンピュータの位置はクライアント側のシステム内の任意の場所であり得て、コンピュータは、一部が画像処理リクエストに使用され、一部が画像の閲覧および表示操作に使用されるように構成されてもよい。本発明の実施形態は、ＤＩＣＯＭ画像以外の他のタイプの画像に適用可能であり得て、したがってＤＩＣＯＭ画像は、単に例としてここで言及される。
【００２２】
ＨＩＳ３０またはＲＩＳ４０の中もしくは外のコンピュータ２０のユーザを介したＤＩＣＯＭ画像へのリクエストおよびアクセスは、システムコンポーネント６０の使用を通じて行われてもよい。いくつかの実施形態１０において、システムコンポーネント６０は、１以上のウェブサーバ７０ａ、７０ｂと、ビューアキャッシュ能力がプログラムされた単なるファイルサーバであり得るウェブビューアキャッシュサーバ８０と、所望によりロードバランササーバ９０と、を備える。システムコンポーネント６０における個々のコンポーネント間の接続、ならびに、ＨＩＳ３０およびＲＩＳ４０の中または外のコンピュータ２０間の接続は、プライベートネットワーク、パブリックネットワーク、および／またはインターネット等の、とり得る多数のインターフェースの１以上を介して行われる。接続媒体は、本発明の実施形態の機能には、重要というわけではない。
【００２３】
画像へのアクセスが望まれる時、クライアント（以下に説明されるとおり、ＨＩＳまたはＲＩＳであってもよい）は、ウェブブラウザを開き、サーバに、次の数時間において画像の閲覧が望まれることを通知する。プリフェッチ機能の実施形態には、少なくとも２つの利点がある。１つ目は、当該実施形態が、サーバのピーク使用量、したがって資本コストを低減するという点であり（サーバは要求されるピーク使用量に基づいて規模調整されるため）、２つ目は、当該実施形態が、ユーザがもはや画像をサーバのウェブキャッシュ内で見つけるため、サーバがＤＩＣＯＭアーカイブから画像を受信し、解析するのを待つ必要がなく、システムへの応答時間を向上させるという点である。これは、クライアント側レンダリングと呼ばれ、表示フレームレートと、圧縮されていない画像の質を向上させる。ウェブサーバは、レンダリングをすることがなくなり、保存することによってアクセスを可能にするだけであるため、もはやウェブサーバははるかに少ない仕事を行う。ウェブサーバキャッシュに関する更なる詳細は、以下に提供される。
【００２４】
その点に関して、本発明の実施形態は、ウェブサーバキャッシュの構造のデザインを、ウェブサーバのデータ処理の役割のために有利に最適化する。複数のウェブブラウザは、データをウェブサーバキャッシュから直接ロードし、データをユーザに対してローカルに表示する。ウェブサーバは、機能的にはユーザへの表示に関与していないため、当該構成はより効率的である。いくつかの実施形態によれば、ウェブサーバキャッシュは、複数のサーバ間の同期を行って、データの一貫性を長期間保持するように構成される。これは、最も効率的にデータを処理するためのロードバランシング機能を備える。重要なことに、改良されたウェブサーバは、複数のサーバが同期動作に使用されている時でさえも、多数のウェブブラウザによって同時にアクセスされるように構成される。ウェブサーバキャッシュはまた、データ処理に使用されているサーバの故障を検知し、故障したサーバによって行われていた処理ステップを、別のサーバを用いて再開するようにも構成される。
【００２５】
本発明のいくつかの実施形態において、システムは、ユーザリクエストに対するシステムの応答性を最大化する機能を用いて、複数のサーバ間でのロードバランシングを最適化するように構成される。１つの例示的な実施形態において、ロードバランシングは、医用画像の処理を全てのサーバに亘って均等に分割するように構成することによって達成される。本発明を用いて、大きな病院環境等の、複数のウェブサーバを利用して、特に、特定のシステムアプリケーションを自動的に処理するようにプログラムおよび調節されたロードバランサが提供され得る。下記の機能の一部から分かるように、いくつかの実施形態のロードバランサは、同一の調査報告に対してリクエストが同時に発生した時に、２つの異なるウェブサーバが同一の機能を実行することを防止するように構成されることが考えられる。他のケースでは、同一の機能はそれほど高機能でないロードバランサによって割り当てられてもよいが、図６Ｂの下方に関連して述べられているように、内部機能が用いられてもよい。実際いくつかのケースでは、既成のロードバランサが、システムの実施形態と共に用いられ得る。例としてここで説明されているとおり、ある実施形態において、アプリケーションのサイズ（すなわち、１以上の大きな画像アーカイブをシェアしているユーザの数）がウェブサーバの一定のグループに一定の機能を割り当てるのに十分に大きい場合、多数のロードバランサが用いられてもよい。
【００２６】
上で説明したように、インベンティブなウェブサーバの実施形態は、患者情報、画像情報、および／または、画像位置が提供され得るデータへのアクセスを、臨床医がリクエストできるように構成される。データへのアクセスリクエストは、好ましくは、臨床医のコンピュータのウェブブラウザによって生成される。その後、ウェブサーバは、臨床医がクエリの結果を待っている間に、データアクセスリクエストを満たすのに必要な、適切な処理を行うことが好ましい。いくつかの実施形態では、例えば、２０１２年１２月３日に提出され、出願の全内容が参照により本願に援用される米国特許出願番号第１３／６９２，９１６において発明者によって説明されているとおり、プリフェッチデータ処理がリクエストされてもよい。好適なシステムの実施形態では、プリフェッチおよびリアルタイムデータリクエストの両方が可能であり、当該実施形態は、１以上のユーザがいくつかの調査報告についてのプリフェッチリクエストを、他のユーザが同一又は異なる調査報告についてのリアルタイムリクエストを行い得る間に行えるように構成される。リクエストの重複が生じた場合の可用性の順序は、リクエストの優先順位および／または時間順配列に基づき、複数のウェブサーバと共同して、ロードバランサによってハンドリングされる。調査報告に対してアップデートを行う場合、システムの実施形態は、調査報告の最新バージョンがサーバに利用可能となることを確実にし、かつ、１度に１つのサーバのみが調査報告をアップデートすることを確実にするように構成される。いくつかの実施形態では、（調査報告の最新版に対する後のアクセスで意図しないエラーが引き起こされるのを避けるために）調査報告に対する変更が許可されていない場合、同一の調査報告についての同時期のリクエストが、二重可視のために、その調査報告の複製を一時的に作成することになってもよいと考えられる。調停機能を使用して、二重に変更された調査報告を自動的に結び付けて、両方の変更を調停可能な程度に組み入れて、最新のバージョンを更に作成するように、二重可視および変更が行われてもよいと考えられる。要するに、付加的な機能を使用して、当該システムは、特定のアプリケーションに対して所望されるように調整され得る。よって、いくつかの実施形態は、所望のまたは必要とされるとおりにシステムのこのような調整を可能とするように構成される。
【００２７】
多くの場合、大病院では、何百人ものユーザが医用画像を閲覧し、多数のウェブサーバの使用を必要とする。同一の臨床医または多数の臨床医のいずれかにより多数のウェブブラウザを使用して作成される多数のリクエストを伴って、インベンティブなウェブサーバの実施形態は、当該リクエストを、ロードバランサ機能を用いて、利用可能な全てのサーバに分配するように構成される。いくつかのケースでは、リアルタイム処理およびプリフェッチデータ処理リクエストは、１つの画像の処理が複数のサーバに分配されるといったように、２つのステップに分割される。いくつかの実施形態では、これは、全てのウェブサーバにシェアされる画像の共通のディスクウェブキャッシュを用いて提供されてもよく、ウェブサーバは全て医用画像アーカイブに接続している。ウェブサーバは、例えばＷｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ２００８Ｒ２、ＭｉｃｒｏｓｏｆｔＩＩＳ（登録商標）、および／または、同等のものを用いて作成される。ロードバランサは、ウェブサーバ機能から分離したコンポーネントであってもよく、または、ウェブサーバもしくはウェブサーバキャッシュに組み込まれていてもよい。
【００２８】
図３を参照して、ロードバランシング機能の一実施形態がより詳細に説明され得る。その点に関して、プリフェッチおよびリアルタイムリクエストの両者は、フローチャートに示されているように作成され、処理され得る。いずれの場合でも、ロードバランサは、この例では、リクエストをプリフェッチエンドポイント（機能）が配置されている適切な利用可能なウェブサーバに転送するように構成される。特定の実施形態において、各グループのリクエストは、先入れ先出し（ＦＩＦＯ）に基づくキューとして管理される。上記のグループのリクエストは、作業がロードバランサを用いてサーバ全体に自動的に分配されるように、ウェブサーバエンドポイントにマッピングされる。各グループの優先順位はサーバレベルで容易に設定可能である。このため、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＩＩＳ等のツールは、ウェブアプリケーション、よって複数のエンドポイントの集合によって用いられるリソースの制御を可能にする、「アプリケーションプール」等の基礎的なインフラストラクチャを提供する。
【００２９】
図４を参照すると、ウェブキャッシュの構造の一例が分かるであろう。調査報告および調査報告内の系列（ｓｅｒｉｅｓ）を識別するためにユニークＩＤが用いられることが好ましい。各系列フォルダの下には、最も高い番号が割り当てられたバージョンが作成された時間を示すタイムスタンプファイルがある。これらのファイルを用いて、ウェブサーバは、調査報告のリクエストの際に、このような調査報告内の各系列のタイムスタンプが、ＤＩＣＯＭアーカイブによって示される最近のものであるかをチェックすることができ、もしそうでなければ処理を開始することができる。系列の処理が完了すると、系列プロセッサは「ｃｏｍｐｌｅｔｅ．ｔｘｔ」ファイルを系列の修正フォルダにドロップする。ウェブサーバは、調査報告のデータアクセスリクエストを受信すると、ウェブブラウザに最も高い番号を有するフォルダのファイルへのリンクを提供する。ウェブサーバは、系列の最上のバージョンが全て完結したものとしてマークされている場合（「ｃｏｍｐｌｅｔｅ．ｔｘｔ」ファイルを含むもの）は、調査報告を完結したものとしてマークする。系列が削除された時、ウェブサーバは、データアクセス機能に当該系列がそれ以上ウェブサーバクエリに戻される必要がないということを示すために、「ｄｅｌｅｔｅ．ｔｘｔ」と呼ばれるファイルを当該シリーズのフォルダにドロップする。
【００３０】
タイムスタンプが、系列または調査報告に対する最後の変更が行われた時を表す値であるということは特筆に価する。値は序数（例えばティック（ｔｉｃｋ）の数、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｓｙｓｔｅｍ＿ｔｉｍｅ参照）または実際の日付および時間であってもよい。系列のタイムスタンプは、したがって、画像が追加、削除または置き換えられたこと、および／または、画像が追加、削除、または置き換えられた時を反映することが好ましい。同様に、調査報告のタイムスタンプは、最後の系列が修正されたか、いつ最後の系列が修正されたか（画像が追加、削除、または置き換えられたか）、および／または、系列が追加もしくは削除されたか、および／または、何時を反映させる。ＤＩＣＯＭアーカイブは、アーカイブ内の系列および調査報告のタイムスタンプの跡をたどるように構成されていてもよいが、現在のところＤＩＣＯＭにおいてこのような値に関して通信を行うための規定はない。よって、タイムスタンプは、ウェブサーバがＤＩＣＯＭエクステンションを実行することによって、または、アーカイブとの非ＤＩＣＯＭ通信を一度に実行することによって決定されてもよい。あるいは、系列のタイムスタンプは、系列取得日および系列における画像の数の組み合わせを用いてウェブサーバによって実現されてもよい。同様に、調査報告のタイムスタンプは、全ての系列および系列の数の最新のタイムスタンプとして実現されてもよい。種々の可能な配列およびフォーマットが、本発明の実施形態で考えられる。
【００３１】
ウェブキャッシュサーバ８０内のウェブキャッシュ８２の一例において、調査報告８４は、調査報告に関連したタイムスタンプを含む、タイムスタンプファイル８６を備えて保存されていてもよい。調査報告は、画像のサブセットが所望のものであるのか適切なものであるのかに応じて、多数の系列を有していてもよい。例えば、系列Ａ８８および系列Ｂ９２が存在してもよく、各系列は、以前のおよび最近の更新および／または修正を反映するバージョンを有している。系列Ａ８８は、タイムスタンプファイル９６を有するバージョン１  ９４を備えていてもよく、バージョン１  ９４自体が画像処理機能によって作成されたファイル９８を同期ファイル１０２と共に備えている。系列Ｂ９２についても同様であり、系列Ｂ９２は、１以上のバージョン１０４、１０６を備えてよく、各バージョンは、同様に処理済の画像ファイル１１２、１１６および同期ファイル１１４、１１８を、全て例として備える。
【００３２】
図５Ａ、５Ｂ、６Ａおよび６Ｂを参照して、当該システムの実施形態の動作がより詳細に説明され得る。参考までに、ステップ２１０は、ＤＩＣＯＭ（または大きな画像）アーカイブおよびウェブサーバキャッシュに調査報告が存在し、キャッシュバージョンはアップデートされてアクセスに対する準備ができている状況を備える。ステップ２２０は、ＤＩＣＯＭ（または大きな画像）アーカイブおよびウェブサーバキャッシュに調査報告が存在しているが、キャッシュバージョンはアーカイブに対してアップデートされていないという状況を備える。ステップ２３０は、アーカイブに調査報告が存在しているが、キャッシュには、そのバージョンが存在しないという状況を備える。ステップ２４０は、調査報告がキャッシュに存在しているが、アーカイブにはもはや存在していない状況を備える。このようなケースにおいて、キャッシュバージョンは削除されてもよい。
【００３３】
例としてここで説明されたアーキテクチャを用いて、ウェブサーバがデータアクセスリクエストを受信すると、ウェブサーバは、リクエストされた調査報告がウェブキャッシュに存在するかをチェックし、存在しない場合には、好ましくはロードバランサに送信され得るリアルタイム処理リクエストを発行し、ロードバランサは、リクエストを、利用可能な第１のサーバに転送する。サーバは、処理を以下のように開始する。病院情報システム（ＨＩＳ）または放射線科情報システム（ＲＩＳ）がプリフェッチリクエストを発行すると、サーバは、リクエストされた調査報告がウェブキャッシュに存在するかをチェックする。無い場合、調査報告を処理するために、プリフェッチデータ処理リクエストを発行する。例として、データアクセスリクエストは、調査報告情報および画像を読み出し、ビューアに表示する意図で、ウェブブラウザによって生成されることが考えられ得る。例として、このグループの１つのリクエストは、「調査報告リクエスト」として参照されてもよい。ウェブキャッシュに存在しない調査報告、または、最新のバージョンをウェブキャッシュが含んでいない調査報告へのデータアクセスがリクエストされる際には、クライアントデータ処理リクエストがウェブサーバによって発行される。系列処理および画像処理の２つのタイプのリアルタイム処理リクエストがあり、これらは以下で説明される。同様に、プリフェッチリクエストは、外部エージェント（通常はＨＩＳまたはＲＩＳ）によって、ウェブサーバに対して発行される。ウェブサーバは、リクエストされた調査報告がウェブキャッシュ内にあるか、かつコピーが最新のものであるかをチェックすることが好ましい。ない場合、ウェブサーバは、プリフェッチデータリクエストを発行する。リアルタイム処理と同様に、系列処理および画像処理の２つのプリフェッチデータ処理機能がある。
【００３４】
ウェブキャッシュ内に存在しない調査報告のデータへのアクセスリクエストをウェブブラウザが発行すると、ウェブサーバは、調査報告フォルダを作成し、他のサーバに処理が発生した旨を通知し、その後、調査報告内の各系列に対する系列処理リクエストを発行する。当該プリフェッチデータ処理リクエストは、ある調査報告が数時間以内にリクエストされる旨をウェブサーバに通知するために、ＨＩＳまたはＲＩＳによって発行される「プリフェッチ」リクエストを含んでいる。このリクエストの処理が行われる際、サーバは、その調査報告がウェブキャッシュ内に存在するかをチェックし、ない場合は、調査報告フォルダを作成し、その後「系列処理リクエスト」を発行する。リクエストは、このグループに含まれており、「リアルタイム処理」グループの一部ではない。次に「系列処理リクエスト」は、こちらもリアルタイム処理というよりはむしろ、プリフェッチデータ処理グループの一部である複数の「画像処理リクエスト」を発行する。「リアルタイム処理」および「プリフェッチデータ処理」の両者は、「系列処理リクエスト」および「画像処理リクエスト」を提供し、これらのリクエストは、同一の動作を行うが、リクエストが処理される優先順位は、そのリクエストが属するグループに左右されるため、別々に保持しておくことが重要である。データ処理リクエストは概して処理に非常に時間がかかり得るため、データアクセスによって発行された系列および画像処理リクエスト（従って「リアルタイム処理」のグループ）は、プリフェッチによって発行される系列および画像処理リクエストよりも、はるかに高い優先順位で処理されることが非常に重要である。前者が、ウェブブラウザの前にユーザがデータ表示を待っており、後者が、ユーザがそれ待っていないためである。上述のとおり、データ処理タスクは、調査報告のサイズに起因して処理時間が大きく異なり得る。
【００３５】
これを適切に処理し、作業を複数のサーバに拡散させるために、データ処理（クライアントにリクエストされた、またはプリフェッチ）は、以下のようにウェブサーバエンドポイントとして実行される。系列処理は、ａ．系列をアーカイブからウェブキャッシュへと転送することと、ｂ．これは全てのウェブサーバのインスタンスに共通であるが、系列フォルダのタイムスタンプをアップデートすることと、ｃ．ＤＩＣＯＭ画像ファイルおよび出力ファイルの位置を提供しつつ、転送された各画像に対する画像処理リクエストを発行することと、ｄ．系列情報を生成して、場合によっては全ての画像の処理が完了した際に、系列の画像の後処理を行い、系列の処理を完了したものとしてマーキングすることとを備える。画像処理に関して、当該画像処理は、いくつかの例において、ａ．入力画像を処理する（メタ情報、ピクセルデータ等を抽出する）ことと、ｂ．画像ウェブキャッシュに当該処理の出力を保存することと、ｃ．必要な場合は、入力画像を削除することとを備える。
【００３６】
処理の粒度は、画像レベルでのものであり、この決定は、系統ごとに大きく異なる画像の数によって決定されるため、作業が複数のサーバに拡散されず、サーバがアイドル状態にあるのに、一方では他のサーバが全てのリクエストを処理できないということが起こり得ること、に留意するのが重要である。複数のサーバ一式全体が同一のウェブキャッシュを共有するならば、これら全てのサーバが余分な転送コストを負うことなく、同一の画像セットにアクセスすることができる。更にウェブサーバエンドポイントを呼び出すコストはかなり少ないので、複数のサーバに処理を分散することによって、処理時間が増加することにはならない。ロードバランサポリシーは、システムのユーザおよびプロバイダに所望されているものと同じように複雑かもしれないが、ラウンドロビンのように、相当に単純化されていることが好ましい。言い換えれば、ロードバランサは、エンドポイントアクセスに関する作業を複数のサーバに分配している時、サーバがビジー状態であるか否かをチェックしない。よって、ロードバランサが最も低粒度のレベル（画像）で作業を分配しているということは、最適なロードバランシングが確実に行われる助けとなる。いくつかの実施形態では、複数のサーバが同一の調査報告を複数回処理することを避けることが可能なため、全てのウェブサーバがアクセス可能な１つのウェブキャッシュを有することが好ましいという点に留意されたい。またこのことによって、系列プロセッサを実行するサーバが、あらゆるサーバがアクセス可能な位置に画像を保存すること、よって異なるサーバに画像の処理をリクエストすることが可能になる。ＤＩＣＯＭアーカイブから系列を転送することは、１つの画像を転送するよりも効率的であるということに留意されたい。したがって、ウェブキャッシュが全てのサーバにシェアされていることによって、システムがこの最適化の利益を受けることが可能になる。
【００３７】
ウェブキャッシュは、最大のサイズを有することが必要であり、その容量を超えたら、クリーンアップ処理が自動的にウェブキャッシュの全てのデータを分析し、その一部を削除することが好ましい。いかなるデータアクセスリクエストにおいても、ウェブブラウザは、処理済でかつウェブキャッシュで利用可能なＤＩＣＯＭ画像のリストを受信する。ウェブサーバは、ウェブブラウザに処理が完了したか否かを示す。完了していない場合、ウェブブラウザは通常、完了したという表示を受け取るまで、数秒内に調査報告情報の再リクエストを行う。
【００３８】
各ＤＩＣＯＭ画像に関して、ブラウザは、次のものへのリンクを受信する。ＤＩＣＯＭ画像のメタ情報を有するファイル、すなわち、ＤＩＣＯＭタグに保存された情報、例えば、ＪＳＯＮフォーマットで保存された情報、プリビューとして用いられるｊｐｅｇフォーマットのＤＩＣＯＭ画像の様々な解像度の画像、および、ＤＩＣＯＭ画像の１６ビットのピクセルデータを保存する複数のファイル。一実施形態において、ファイルはＲＡＷ１２ビット値として保存され、その後ＩＩＳ圧縮部（例えばｈｔｔｐ：／／ｔｅｃｈｎｅｔ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｃｃ７７１００３（ｖ＝ｗｓ．１０）．ａｓｐｘ参照）がファイルをブラウザに送信する時に、ファイルを動的に圧縮することを可能にしている。ファイルをＨＴＭＬ対応フォーマットに保存する他の方法は、本願に援用されている特許出願に記載されている。
【００３９】
ブラウザが上記ファイルのリストを受信すると、ブラウザはユーザにリクエストされたとおりに当該ファイルにアクセスする。ウェブサーバのコストを最小限にするため、ブラウザは、ウェブサーバ（ただしＩＩＳではない）をバイパスして、上記ファイルに直接アクセスする。したがってウェブブラウザが画像を表すファイルのリストを受信すると、ブラウザは完全にサーバから独立して、いつでも当該画像にアクセス可能となる。ブラウザとサーバとの通信は、その際完全に終了する。
【００４０】
インベンティブなウェブサーバキャッシュの実施形態は、このようなウェブキャッシュが直面するであろう難局を克服する。１つ目は、ウェブキャッシュのインテグリティである。全てのウェブサーバはウェブキャッシュにおけるデータの読み書きが可能であるため、ウェブキャッシュインテグリティを保証するための同期のメカニズムが必要である。例えば、同一の調査報告が複数のサーバにリクエストされた時は、１つのサーバのみが上記の処理手順を開始することを保証する必要がある。２つ目は、フォルトトレランスである。サーバは、ハードウェアまたはネットワークの故障で、タスクを完了させることができないかもしれない。当該インベンティブな実施形態は、それを解決し、別のサーバに処理タスクを引き継ぎ、完了させるように指示する。３つ目は、制御されていないクライアントのアクセスである。ウェブサーバは、ウェブブラウザからのウェブキャッシュへのアクセスを監視していないかもしれない。ブラウザは、ウェブキャッシュ内のファイルリストを受信すると、いつでもそのファイルにアクセスすることが可能である。よって、本発明の実施形態は、同一の調査報告または系列の異なるバージョンに、異なるブラウザによって同時にアクセスすることが可能なように構成されており、サーバは、ウェブキャッシュから周期的にファイルを削除するように構成されている。
【００４１】
同一の調査報告の異なるバージョンが、異なるクライアントによって同時に閲覧可能であるため、ウェブサーバは、クライアントに対して提供される画像のリンクに、１つのバージョンを割り当てるように構成される。いくつかの実施形態では、調査報告全体ではなく、実際の系列に１つのバージョンが割り当てられる。これは、ある調査報告において変更（追加、削除または修正）される系列が通常、数個のみである状況において好ましい。当該系列は、ウェブキャッシュにおいて、１つのバージョンが割り当てられ、アップデートされる要素である。この理由で、データプロセッサは、系列全体を処理する機能を提供する。
【００４２】
複数のウェブサーバは、データベースの使用も含めて、様々な方法で同期させることが可能である。インベンティブなウェブサーバのいくつかの実施形態において、同期させるための効率的な方法の１つは、ファイルシステムを用いることである。これは、ファイル作成動作がアトミックである、すなわち、多数のウェブサーバが同時に同一のファイルを作成しようと試みる場合、１つのサーバのみが成功し、他のサーバは全て失敗するということによる。成功したウェブサーバのみが処理を続行することができ、他のファイルはその処理の完了を単に待機する。よって、同一の調査報告が複数のサーバを介して同時にリクエストされた場合、複数のサーバは全て、調査報告フォルダ、系列フォルダ、およびバージョンフォルダを作成する。これで問題は起こらない。それは、すでに存在するフォルダの作成がアプリケーションエラーを引き起こさないためである。よって全てのサーバは、好ましくは同一の系列フォルダおよびバージョンフォルダに向けて系列プロセッサを開始する。系列プロセッサの第１の動作は、「ａｃｔｉｖｅ．ｔｘｔ」と呼ばれるファイルを、目的のフォルダに作成することである。ウェブサーバによってファイルが作成された時、そのファイルを作成したサーバだけが、その系列を完了まで処理できるサーバである。割り当てられたサーバが作動しなくなる場合、システムは「ｃｏｍｐｌｅｔｅ．ｔｘｔ」ファイルが存在しないことを検知することができ、そうすると異なるサーバが割り当てられて始めからその処理を再開する。言い換えると、ファイルの作成がアトミックな動作である場合、１つの系列プロセッサのみが成功し、他のプロセッサは失敗する。成功した系列プロセッサのみが処理を続行し、他のプロセッサは計算を停止する。このスキームの例を用いることは、任意の時点で１つのサーバのみがフォルダ内のデータを処理することを確実にする助けとなる。
【００４３】
任意の時点において、１つのウェブサーバのみがアーカイブから特定の系列のデータをリクエストし、そのデータに対応する分配画像処理タスクを生成してもよい。このウェブサーバは、タイムスタンプおよび「ｃｏｍｐｌｅｔｅ」フラグ等の、その系列に関連した情報を保存する役割を果たすウェブサーバである。サーバは、当該系列の全ての画像の後処理を行い、例えば系列サムネイルを選択してもよく、または一連の画像を用いてビデオを生成してもよい。
【００４４】
ウェブブラウザがいつその調査報告データが完成したかをチェックし続けることが好ましく、そのため、開始後、系列プロセッサは、データアクセスによって監視される。系列プロセッサは、処理を開始すると、「ａｃｔｉｖｅ．ｔｘｔ」と呼ばれるファイルを作成し、タスクが完成すると予想される時間を書き込む。ファイルは、画像の数およびサーバが画像を処理可能な速度が前もってわからないことがあるので、データがアーカイブから受信されると、そのデータの実情に従いアップデートされる。データアクセスがリクエストされると、ウェブサーバは、「ｃｏｍｐｌｅｔｅ．ｔｘｔ」が存在しない系列を探し、予想される完了時間を「ａｒｃｈｉｖｅ．ｔｘｔ．」においてチェックする。時間が経過している場合、ウェブサーバは処理タスクが失敗したとみなす。よって、いくつかの実施形態において、ウェブサーバは、新たなバージョンフォルダを作成し、このような系列に対する新たな系列プロセッサを開始する。このようなアプローチがいくつかのレベルにおけるフォルトトレランスである。系列プロセッサが単に完了時間を低く見積もっている場合、システムは、作業が適切に行われても、同一の系列を２度処理することになる。複数のプロセッサが異なるバージョンフォルダで作業しているためである。ウェブブラウザが、完了していないバージョンフォルダのデータに対するリンクを有する場合、当該リンクは依然として有効である。系列プロセッサが「ａｃｔｉｖｅ．ｔｘｔ」ファイルの作成にさえ失敗するという稀なケースにおいては、当該データアクセスによってフォルダの作成時間がチェックされ、相当な時間が経過している場合にのみ、新たな系列のバージョンフォルダを作成する試みが行われる。障害検知は、調査報告の転送が完了するまでデータアクセスのポーリング情報に依存しているため、プリフェッチの場合、障害検知は延期される。このような場合、障害はユーザが調査報告へのアクセスを試みようとする際に、検知される。代替的に、サーバ自体がこのような調査報告に対するデータアクセスリクエストを自動的に生成してもよい。
【００４５】
ウェブキャッシュの追い出し（ｅｖｉｃｔｉｏｎ）に関して、ＨＴＭＬ５ビューアのためにウェブキャッシュは、接続されているウェブブラウザによって閲覧されている全てのデータを保存するように構成されていることが好ましい。最適なパフォーマンスのため、ウェブキャッシュは、ウェブサーバによって生成されたデータを適度に長い時間、例えば２４時間保持するサイズにされる必要がある。一例において、ウェブキャッシュが、少なくともＨ時間の結果を保持するように設定されているとする。通常の間隔、ウェブサーバが処理を開始する各インスタンスにおいて、ウェブキャッシュのサイズをチェックし、当該サイズが一定の閾値より大きい場合、ウェブサーバは、いくつかの調査報告を削除しようとする。どの調査報告を削除するかを決定するために、当該処理は、各調査報告フォルダの各ファイルの「最終アクセス時間」属性を調べ、その後、全ての調査報告を、検知された最近のアクセス時間に基づいて分類する。ウェブサーバはその後、検知された最近のアクセス時間が、少なくともＨ時間経過している調査報告の削除を検討し始める。ウェブブラウザが所定の時間数（すなわち、制限時間）より長く、同一の調査報告に関して開かれているという偶のケースにおいて、ウェブブラウザにおけるＪａｖａスクリプトコードは、当該調査報告の１つファイルに自動的にアクセスし、場合によってはその内容を無視することが好ましい。これによって、このようなファイルの「最終アクセス時間」がサーバのウェブキャッシュにおいてアップデートされ、よって当該調査報告はウェブキャッシュによって追い出されることはない。「最終アクセス時間」を用いることは、可能な方法の１つに過ぎないということに留意されたい。この機能は、時としてＷｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイルシステムにおいて、パフォーマンス上の理由から無効にされている場合がある。上記の方法を実行するための代替的な方法は、ウェブブラウザがコンテンツ情報をリクエストした際に、データアクセスによって空のファイル（ｌａｓｔａｃｃｅｓｓ．ｔｘｔと呼ぶ）が、調査報告フォルダに作成されるようにすることである。当該ウェブキャッシュの追い出し処理は、ｌａｓｔａｃｃｅｓｓ．ｔｘｔファイルの作成時間をチェックするだけで、当該調査報告に最後にアクセスした時間を識別することが好ましい。このアプローチは、いくつかの利点を有する、なぜなら、このアプローチがファイルシステムの設定に依存せず、ウェブキャッシュ追い出し処理では調査報告フォルダの全てのファイルにアクセスする必要がなく、１回でよいため、より効率的だからである。ｌａｓｔａｃｃｅｓｓ．ｔｘｔファイルがフォルダ内に存在しない場合は、その状況は、当該調査報告がプリフェッチされたが、ウェブブラウザによってまだ閲覧されておらず、手付かずのままであるはずだということを示している。しかし、プリフェッチされた調査報告がアクセスされなかったという可能性もある。したがって、ウェブキャッシュ追い出し処理は、調査報告フォルダの作成時間をチェックして、追い出す必要があるかを決定することが好ましい。
【００４６】
よって、本発明の実施形態はいくつかの利益をもたらす。当該システムは、いくつかのビューアを同一の調査報告の異なるバージョンにアクセスさせることが可能である。当該ウェブキャッシュは、アクセスされているファイルを監視するように構成されている。そうすることによって、ウェブキャッシュの保存レベルがユーザ（またはメモリの製造会社）によって設定されたものを超えた時、当該ウェブサーバキャッシュは、どのファイルが最も使用されていないか、または最近使用されていないかを特定し、これらのファイルをウェブキャッシュメモリから、ウェブブラウザの作業に影響を与えることなく削除することが可能である。タイムスタンプをファイルに適用することによって、ウェブキャッシュのデータが最近アップデートされたバージョンであるか、すなわち、処理が再開されなければならなかったのか、または、更なるデータ処理が後にまたは異なるサーバで発生したか、をウェブサーバが判別することができる。当該システムは、フォルトトレランスであり、いかなる条件であってもウェブブラウザに提供されたファイルのインテグリティを保持する。当該システムは、ビューアがウェブキャッシュにおいて必要とするファイルに常時アクセス可能であり、閲覧されている調査報告が追い出されないことを確実にする助けとなる。
【００４７】
本発明の実施形態の一用途において、ウェブサーバは、以下のように機能するように構成およびプログラムされる。
ａ．各医用調査報告に対し、調査報告独自の識別子を有する名前でフォルダが作成される。
【００４８】
ｂ．調査報告における各系列に対し、系列独自の識別子を有する名前でサブフォルダが作成される。
ｃ．系列の各バージョンに対し、系列番号を有する名前でサブフォルダが作成される。
【００４９】
ｄ．各系列のバージョンフォルダに、処理済ファイルが保存され、同期ファイル（すなわちａｃｔｉｖｅ．ｔｘｔおよびｃｏｍｐｌｅｔｅ．ｔｘｔ）が保存され、更には当該系列のタイムスタンプ。
【００５０】
ｅ．失敗が検知されたサーバに保存された各フォルダに対し、新たな系列バージョンが作成される。
ウェブブラウザがウェブサーバからの調査報告をリクエストすると、本発明の実施形態のいくつかのアプリケーションは、以下のことを行う。
【００５１】
ｗ．ウェブサーバが、系列のリストおよびそれぞれに関連したタイムスタンプを含むＤＩＣＯＭアーカイブからの調査報告情報をリクエストする。
ｘ．ウェブサーバは、調査報告フォルダが作成されたかをチェックし、作成されていない場合、サーバは、その作成を試みる。作成が失敗した場合、その作成は無視される。
【００５２】
ｙ．調査報告フォルダ内の各系列フォルダに対して、当該ウェブサーバは上記タイムスタンプをアーカイブから返されたタイムスタンプと比較する。これらのタイムスタンプが異なる場合は、当該ウェブサーバは、系列フォルダ内の番号より大きなバージョン番号のフォルダの作成を試みる。当該ウェブサーバはその後、このバージョンフォルダの、この系列に対する系列プロセッサを呼び出す。
【００５３】
ｚ．アーカイブによって返されたリスト内の各系列に対して、ただし調査報告フォルダにフォルダがないとき、ウェブサーバは、バージョン１のフォルダおよびサブフォルダを作成し、その後、このような系列の系列プロセッサを呼び出す。
【００５４】
系列プロセッサは、処理を行うための系列のユニーク識別子および（当該バージョンを含む）送り先フォルダを受け取る。場合によっては、いくつかの系列プロセッサは、上述のステップ「ｙ」および「ｚ」のように、同一系列および同一の送り先に対して同時に起動されてもよい。系列プロセッサの最初の動作は、ａｃｔｉｖｅ．ｔｘｔと呼ばれるファイルを、送り先フォルダにおいて「新規作成」として作成することである。最初の系列プロセッサのみがファイルの作成に成功し、このプロセッサが当該系列を処理するものとなり、他の系列プロセッサは、終了する。
【００５５】
当然のことながら、本発明の実施形態は、特定の医用ファイルまたはＤＩＣＯＭファイルだけでなく、全てのタイプのデータおよびフォーマットされたファイルに適用されてもよいことが理解されよう。また、当該実施形態は、非破壊検査（ｎｏｎ−ｄｅｓｔｒｕｃｔｉｖｅ  ｔｅｓｔｉｎｇ）に用いられ得る。インベンティブなシステムの機能的な利点を享受するため、多数の設計コンフィギュレーションが可能であるということは、当業者が理解するところであろう。よって、本発明の実施形態の幅広い種類の構成および配置を考慮すると、本発明の範囲は、上述の実施形態によって狭められるというよりも、むしろ以下の請求項の広さが反映される。
【図１Ａ−１Ｂ】
0006453881.tif 000002
【図２Ａ】
0006453881.tif 000003
【図２Ｂ】
0006453881.tif 000004
【図３】
0006453881.tif 000005
【図４】
0006453881.tif 000006
【図５Ａ】
0006453881.tif 000007
【図５Ｂ】
0006453881.tif 000008
【図６Ａ】
0006453881.tif 000009
【図６Ｂ】
0006453881.tif 000010