データ要素の発信元と受信側を通じてＤＩＣＯＭ画像をストリーミングする方法と装置
【課題】データ要素の発信元と受信側を通じてＤＩＣＯＭ画像とオブジェクトをストリーミングする方法と装置を提供する。
【解決手段】あらゆるサイズの比較的大きなＤＩＣＯＭオブジェクトに含まれるデジタル・データは、ネットワーク内のアプリケーション、装置、記憶媒体の間で転送できる。データ要素の発信元とデータ要素の受信側を使用して１回に１つずつデータ要素とデータ値を段階的に処理するので、ＤＩＣＯＭオペレーションを実行するのに必要なメモリ量が最小になる。本発明による方法と装置は、メモリ資源の消費を限定すると共に、比較的大きなＤＩＣＯＭオブジェクトの処理のために比較的小さな固定量のメモリを供給してＤＩＣＯＭ内で動作するアプリケーションの性能を維持する。
【解決手段】あらゆるサイズの比較的大きなＤＩＣＯＭオブジェクトに含まれるデジタル・データは、ネットワーク内のアプリケーション、装置、記憶媒体の間で転送できる。データ要素の発信元とデータ要素の受信側を使用して１回に１つずつデータ要素とデータ値を段階的に処理するので、ＤＩＣＯＭオペレーションを実行するのに必要なメモリ量が最小になる。本発明による方法と装置は、メモリ資源の消費を限定すると共に、比較的大きなＤＩＣＯＭオブジェクトの処理のために比較的小さな固定量のメモリを供給してＤＩＣＯＭ内で動作するアプリケーションの性能を維持する。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は、一般に画像伝送に関し、特に、データ要素の発信元と受信側を通じてＤＩＣＯＭ画像をストリーミングする方法と装置に関する。
【背景技術】
【０００２】
医療画像は、医療ディジタル画像通信（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（ＤＩＣＯＭ）と呼ばれるネットワーク・プロトコル規格を使用して、コンピュータ間で通信できる。このＤＩＣＯＭネットワーク・プロトコルは、心電図波形、コンピュータ断層撮影（ＣＴ）、磁気共鳴（ＭＲ）および超音波などの医療画像およびオブジェクトの配信と表示を支援するために作成された。
【０００３】
ＤＩＣＯＭネットワーク・プロトコルは、デジタル画像データとオブジェクトを記憶し、受信し、伝送するのに使用されるフォーマットを定義する。ＤＩＣＯＭオブジェクト・フォーマットは、典型的にヘッダと画像データを含む。ヘッダは、患者の名前、医療手順または断層撮影のタイプ、画像次元などに関する情報を含む。たとえば、あるＤＩＣＯＭ画像ファイルは、ある医療画像の物理的次元を記述するデータを内容とするヘッダを含む。ヘッダは、この画像内に含まれる断層撮影についてのテキスト情報を内容とするデータを含む。ヘッダのサイズは、画像に記憶される情報量により異なる。ヘッダ内のデータは、１つまたはそれ以上のグループに組織できる。１つのグループは、グループ長さ、ファイル・バージョン、転送構文のような１つまたはそれ以上のデータ要素を定義するメタ・ファイル情報である。データ要素の数は、画像タイプとこの特定画像タイプの特性により異なる。
【０００４】
オブジェクト・データは、典型的にヘッダ・データに続く。オブジェクト・データは、特定のオブジェクト・タイプの特性を定義するデータ要素および特定のオブジェクト・タイプに関連するオブジェクト・データを有する。オブジェクト・データは、２つおよび／または３つの次元で遂行される医療走査で得られる情報を含むことができる。たとえば、磁気共鳴画像（ＭＲＩ）データは、そのＭＲＩエコー時間を詳細に定義するデータ要素を含むＤＩＣＯＭ画像データを有する。その上、画像ファイル・サイズを小さくするために画像データを圧縮したりカプセル化したりする。
【０００５】
ほとんどのＤＩＣＯＭデータ要素は、小さくて、それらが収納できるデータのタイプによりサイズが限定される。たとえば、整数データ要素は、少しの整数を含む。これらのデータ要素は、いつも比較的小さく、それらの比較的小さなサイズのゆえに、ネットワークの効率と拡張性に重要または大きな影響を与えることはない。画像データなど他のタイプのＤＩＣＯＭデータ要素は、比較的大きいことがある。２つのタイプのＤＩＣＯＭデータ要素は、大きいことがあるので、特別な注意に値するが、それは、シーケンスとピクセル・データである。ＤＩＣＯＭにおけるシーケンスは、他のデータ・セットを再帰的に収納できるデータ要素のタイプである。それらは他のデータ・セットを収納できるので、小さなデータ要素を非常に多数収納する場合またはピクセル・データを収納する場合は、それらが相対的に大きくなる。ピクセル・データは、実際の画像データに対応するタイプのデータ要素である。ピクセル・データは、相対的に大きくなるタイプのデータ要素であって、ある場合には極端に大きくなる。非常に大きなデータ・セットが通信される場合、そのデータ・セット内のほとんど全てのバイトがピクセル・データである。他のほとんどのタイプのデータ要素は、患者名、画像のタイプ、画像の日付と時間などの画像についての情報（メタ・データ）を通信する。
【０００６】
ＤＩＣＯＭは、データ・セットを伝送することにより通信する。データ・セットは、シーケンス・データ、ピクセル・データまたは他のタイプのデータなどのデータ要素の順序付き集合である。各データ要素は、通信される情報を表現する。各データ要素は、特定のタイプを有し、データ要素タイプによりサイズが異なる。たとえば、ある画像ファイルのサイズにおいて、異なった範囲を例示すれば、ＤＩＣＯＭ画像のファイル・サイズは、単一ＤＩＣＯＭ画像について約１２８キロバイトからあるし、または時間シーケンス、すなわちマルチ・フレームＤＩＣＯＭ画像について約６００メガバイトまでの範囲にわたる。
【０００７】
ＤＩＣＯＭデータ・セットは、１つまたはそれ以上の転送構文を使用して通信できる。転送構文は、特定のデータ・セットについてのデータのエンコーディングのタイプを決定する。ＤＩＣＯＭネットワーク・プロトコルは、少なくとも３つのタイプの転送構文をサポートできる。すなわち、小エンディアン（ｅｎｄｉａｎ）明示値表現、小エンディアン暗示値表現および大エンディアン明示値表現である。
【０００８】
ＤＩＣＯＭネットワーク・プロトコルの独自な機能により移送時にデータを異なった形式に変換することができる。通常のＤＩＣＯＭネットワーク上でＤＩＣＯＭ画像を伝送中のＤＩＣＯＭデータ変換の独自な機能は、ＤＩＣＯＭネットワーク内にメモリ資源への相対的に大きな要求を作り出す。
【０００９】
ＤＩＣＯＭネットワーク・プロトコルは、多重の層から構成される。ＤＩＣＯＭネットワーク・プロトコルは、標準的なＴＣＰ／ＩＰプロトコルの上に構築できる。通信ネットワーク上でデータを伝送する時に、ＤＩＣＯＭプロトコルはネットワーク上でデータを送信する以前にデータ・セットを１つまたはそれ以上のデータ・パケットに分解する。各データ・パケットは、１つまたはそれ以上のプロトコル・データ・ユニット（ＰＤＵ）を定義する。ＴＣＰ／ＩＰプロトコルにおけるような下にあるプロトコル層がデータをデータ・パケットに変換すれば、ＤＩＣＯＭプロトコルは、ネットワーク上で通信されているデータ・セットもプロトコル・データ・ユニット（ＰＤＵ）としてパッケージされることを要求する。たとえば、ＴＣＰ／ＩＰプロトコルの上にＤＩＣＯＭネットワーク・プロトコルが走る時に、これは実効的にデータを二重パケット化する。つまり、ＤＩＣＯＭは、データ・セットをプロトコル・データ・ユニット（ＰＤＵ）としてパッケージし、またＴＣＰ／ＩＰは、データ・セットをデータ・パケットとしてパッケージする。このタイプのＤＩＣＯＭ／ＴＣＰ／ＩＰ層化したプロトコル構造は、通常のＤＩＣＯＭネットワークにおいて、メモリ資源に対して相対的に大きな要求を作り出す。その上、ＤＩＣＯＭネットワーク・プロトコルの多重層を通じてＤＩＣＯＭ画像を伝送することも、通常のＤＩＣＯＭネットワーク内でメモリ資源に対して相対的に大きな要求を作り出す。
【００１０】
ＤＩＣＯＭプロトコルは、通信を設立し維持するのに厳密な順序に従う。ＤＩＣＯＭプロトコルのアッパ・サービス・レベル層により作動される状態機械は、ＤＩＣＯＭネットワーク内の２つの装置の間で通信を設立し維持するための厳密な順序を規定する。たとえば、ＤＩＣＯＭプロトコルは、接続方向性なので、ＤＩＣＯＭ結合または接続が２つの装置の間で設立済みになるまで、ＤＩＣＯＭデータの通信は、何も起こらない。つまり、ＤＩＣＯＭ結合または接続を設立するためには、少なくとも２つのＤＩＣＯＭプロトコルに基づく装置が互いに通信していなければならない。ＤＩＣＯＭ結合または接続が設立済みになった後に、通信は、厳密な手順に従い続けなければならず、それからＤＩＣＯＭ結合または接続は、順序に従った仕方で終結しなければならない。ＤＩＣＯＭネットワーク・プロトコルにより指示される厳密な順序は、通常のＤＩＣＯＭネットワーク内に相対的に大きなメモリ資源の要求を作出する。
【００１１】
各ＤＩＣＯＭ結合または接続は、ＤＩＣＯＭネットワーク内でＤＩＣＯＭデータ・オペレーションを遂行するために使用される。ＤＩＣＯＭオペレーションは、逐次的に、すなわち１つずつ、または並行的に遂行できる。並行的オペレーションは、ＤＩＣＯＭ内の結合ごとの非同期オペレーションと呼ばれる。通常のＤＩＣＯＭネットワークは、典型的にＤＩＣＯＭデータを含む多重の並行的または非同期オペレーションを処理し、大きなＤＩＣＯＭファイル・サイズは、通常のＤＩＣＯＭネットワーク内にメモリ資源に対する相対的に大きな要求を作出する。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
通常のＤＩＣＯＭ通信ネットワークによる相対的に大きなオブジェクトの急速な処理は、ＤＩＣＯＭプロトコル・オペレーションが効率的で高性能な仕方で遂行されることを要求する。相対的に大きなＤＩＣＯＭオブジェクト・ファイルを処理する時に、通常のＤＩＣＯＭ通信ネットワークは、スピードと性能が著しく低下する。ＤＩＣＯＭオブジェクトは、相対的に大きくなる傾向があるので、ＤＩＣＯＭオブジェクトの通信がこの大きな画像オブジェクトを収容するように設計されていない通信ネットワークを急速に圧倒する。多重で同時的なＤＩＣＯＭオペレーションを処理するために、通常のＤＩＣＯＭ通信ネットワークは、サーバに依存している。単一のＤＩＣＯＭファイルまたは記憶装置のオペレーションがメモリおよび処理時間などのサーバの資源の大部分を消費する場合は、ＤＩＣＯＭサーバは、この大きなオブジェクトを処理する時に貧弱な拡張性と性能に苦しむ。これらのネットワークとサーバの性能の問題は、多重のクライアントが同時的または並行的にネットワークを使用することを試みる時に著しく悪化する。
【００１３】
したがって、ネットワーク内でＤＩＣＯＭオブジェクトの処理中にメモリ資源の消費を限定する方法と装置の要求が存在する。
【００１４】
ネットワーク内で通信されるＤＩＣＯＭオブジェクトのサイズに関係なくメモリの使用を限定するために、ＤＩＣＯＭ通信ネットワーク内で１つまたはそれ以上のアプリケーションを可能にする方法と装置の要求がさらに存在する。
【００１５】
通信ネットワーク内の２つの装置の間でデジタル・データを伝送する改良された方法と装置のさらなる要求が存在する。
【００１６】
通信ネットワーク内で作動する１つまたはそれ以上のアプリケーションを維持または改良すると共に、ネットワーク内でＤＩＣＯＭオブジェクトを伝送する改良された方法と装置の更なる要求が存在する。
【００１７】
データ要素の発信元とデータ要素の受信側を通じてネットワーク内でＤＩＣＯＭオブジェクトをストリーミングする方法と装置の更なる要求が存在する。
【課題を解決するための手段】
【００１８】
本発明は、データ要素の発信元とデータ要素の受信側を通じてネットワーク内のＤＩＣＯＭオブジェクトをストリーミングする方法と装置を供給することにより、上記の諸問題を解決する。本発明による方法と装置は、ネットワーク内のＤＩＣＯＭオブジェクトの処理中にメモリ資源の消費を限定する。更に本発明による方法と装置は、ＤＩＣＯＭ通信ネットワーク内の１つまたはそれ以上のアプリケーションがネットワーク内に通信されるＤＩＣＯＭオブジェクトのサイズに係りなくメモリの使用を限定できるようにする。その上、本発明による方法と装置は、通信ネットワーク内の２つの装置の間でデジタル・データを伝送できるようにする。最後に本発明による方法と装置は、ネットワーク内で作動する１つまたはそれ以上のアプリケーションの性能を維持または改良すると共に、ネットワーク内でＤＩＣＯＭオブジェクトを伝送することを可能にする。
【００１９】
本発明による方法と装置は、一定量のメモリを使用して通信ネットワーク内の２つの装置の間のデジタル・データの伝送することを可能にする。たとえば、本発明による方法と装置は、限定された固定サイズのメモリのみを使用して、ＤＩＣＯＭネットワーク内の２つの装置の間で比較的大きなファイル・サイズのＤＩＣＯＭオブジェクトをストリーミングできるようにする。ＤＩＣＯＭオブジェクトまたは他のデジタル・データまたは比較的大きなファイル・サイズのオブジェクトを処理するために、本発明による方法と装置は、このオブジェクトをデータ要素の小さな固定された部分に配分する。それから本発明による方法と装置は、単一オペレーションのために一回にメモリに記憶できるデータ要素の数を限定する。それから、各データ要素がデータ要素の発信元またはデータ要素の受信側により段階的に処理され、単一のオペレーションについて多すぎるメモリの使用を回避する。こうして、本発明による方法と装置は、通信されるＤＩＣＯＭオブジェクトまたは画像のサイズに係りなく、小さな固定量のメモリのみを使用してＤＩＣＯＭオブジェクトまたは画像をストリーミングすることをＤＩＣＯＭ通信ネットワークに可能とする。
【００２０】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信する第１の例示的な方法において、この方法は、データ・ストリーム内に記憶される限定された数のデータ値を最初に定義する。次に、この方法は、第１の装置から一組のデータ素子を段階的に読み取ることにより、各データ要素が一回に１つずつ読み取られるようにする。次に、各データ要素からデータ値が抽出される。あるデータ要素が閾値サイズよりも大きければ、このデータは、比較的小さな固定サイズ・データの部分で伝送できる。最後に、この方法は、所定の限定された数のデータ値を含むデータ・ストリームを第２の装置へ伝送することにより、データ値が第２の装置にエンコードされるようにする。
【００２１】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信するもう１つの例示的な方法において、本発明は、第１の装置からデジタル・データを含むファイルを受信する。次に、この方法は、デジタル・データを含むファイルについてのデータ値を含むデータ・ストリームを生成する。このデータ・ストリームに基づいて、本発明は、データ要素の発信元を生成する。それから本発明は、データ要素の発信元を通じて、このデータ・ストリームから一回に１つずつデータ要素を段階的に処理する。最後に、これらのデータ要素は、データ要素の受信側に伝送されて、データ要素の受信側の第２の装置にデータ要素をエンコードする。
【００２２】
本発明の装置の実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の発信元と通信エンジンを含む。データ要素の発信元は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の発信元も、一組のデータ要素から一回に１つずつデータ要素を段階的に処理するように構成される。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータをデータ受信側に渡すことにより、抽出されたデータからデータ・ストリームを生成するように構成され、データ要素の受信側は、抽出されたデータ値を第２の装置へエンコードする。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２３】
本発明の装置のもう１つの実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の受信側と通信エンジンを含む。データ要素の受信側は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の受信側も、一組のデータ要素から一回に１つずつデータ要素を段階的に書き込むように構成される。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータ値からデータ・ストリームを生成するように形成される。その上、通信エンジンは、さらに、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２４】
このように本発明の方法と装置は、上記のように、あらゆるサイズの比較的大きなＤＩＣＯＭオブジェクトに含まれるデジタル・データをネットワーク内の２つのアプリケーション、装置または記憶媒体の間で伝送することができる。データ要素の発信元とデータ要素の受信側を使用して、一回に１つずつデータ要素とデータ値を段階的に処理することは、ＤＩＣＯＭオペレーションを実行するのに必要なメモリ量を最小化する。本発明による方法と装置は、比較的大きなＤＩＣＯＭオブジェクトを処理するために比較的小さな一定量のメモリを供給すると共に、メモリ資源の消費を制限し、一方ではＤＩＣＯＭネットワーク内で作動するアプリケーションの性能を維持する。
【実施例】
【００２５】
さて、図面を参照しながら本発明の特定の実施例を一層詳細に説明する。
【００２６】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信する第１の例示的な方法において、この方法は、最初に、データ・ストリーム内に記憶されるデータ値の限定された数を定義する。次に、この方法は、第１の装置から一組のデータ要素を段階的に読み取って、一回に１つずつデータ要素が読み取られるようにする。次に、各データ要素からデータ値が抽出される。あるデータ要素が閾値サイズよりも大きければ、このデータは、比較的小さな固定サイズのデータの複数の部分で伝送できる。最後に、この方法は、所定の限定された数のデータ値を含むデータ・ストリームを第２の装置に伝送して、これにより、これらデータ値は、第２の装置にエンコードされるようにする。
【００２７】
一定量のメモリの使用して第１の装置から第２の装置へデジタル・データを通信するもう１つの例示的な方法において、本発明は、第１の装置からのデジタル・データを含むファイルを受信する。次に、この方法は、デジタル・データを含むファイルについてデータ値を含むデータ・ストリームを生成する。このデータ・ストリームに基づいて、本発明は、データ要素の発信元を生成する。それから、この方法は、データ要素の発信元を通じて、データ・ストリームから一回に１つずつデータ要素を段階的に処理する。最後に、これらのデータ要素は、データ要素の受信側に伝送されて、データ要素の受信側は、これらデータ要素を第２の装置にエンコードする。
【００２８】
本発明の装置の例示的な実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の発信元と通信エンジンを含む。データ要素の発信元は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の発信元もまた一組のデータ要素から一回に１つずつデータ要素を段階的に処理するように構成されている。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータ値をデータ要素の受信側に渡すことにより、抽出されたデータ値からデータ・ストリームを生成するように構成され、データ要素の受信側は、抽出されたデータ値を第２の装置にエンコードする。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２９】
本発明の装置のもう１つの実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の受信側と通信エンジンを含む。データ要素の受信側は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の受信側は、また一組のデータ要素から一回に１つずつデータ要素を段階的に書き込むように構成される。通信エンジンは、データ要素からデータ値を抽出して、これら抽出された１つのデータ値からデータ・ストリームを生成するように構成される。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００３０】
図１は、本発明の実施例によるシステムの機能的なブロック図を示す。このシステムは、通信モジュール１００を含む。通信モジュール１００は、関連アプリケーション・プログラム１０１とネットワークを介する他のアプリケーション・プログラムの間で伝送またはオブジェクトのストリーミングをするように構成される。その上、通信モジュール１００は、関連アプリケーション・プログラム１０１とネットワークを介する他のアプリケーション・プログラムの間で、ＤＩＣＯＭ画像ファイルまたは他の類似タイプのデジタル画像を含むＤＩＣＯＭオブジェクトの伝送またはストリーミングのために構成される。たとえば、通信モジュール１００は、関連アプリケーション・プログラム１０１とＤＩＣＯＭネットワーク１０２のような通信ネットワークを介するアプリケーション・プログラム１３０の間で通信して、ＤＩＣＯＭ画像ファイルまたは他の類似タイプのデジタル・オブジェクトを含むＤＩＣＯＭオブジェクトを送信または受信できる。
【００３１】
注意すべきは、通信モジュール１００は、一般にサービス・クラス・プロバイダ（ＳＣＰ）と、サービス・クラス・ユーザ（ＳＣＵ）の間で通信することである。ＳＣＰは、ＤＩＣＯＭネットワーク・プロトコルで定義されたサービスへの要求を受信し、一方、ＳＣＵは、ＤＩＣＯＭネットワーク・プロトコルで定義されたサービスへの要求を開始する。たとえば、関連アプリケーション・プログラム１０１は、ＳＣＵであることができ、またアプリケーション・プログラム１３０を実行するサーバ１２８ａ／ｎは、ＳＣＰであることができる。
【００３２】
関連アプリケーション・プログラム１０１は、医療画像プログラムまたはアプリケーション・プログラムのようなＤＩＣＯＭアプリケーション・プログラムであり、これらはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用する通信モジュール１００により通信できる。関連アプリケーション・プログラム１０１は、１つまたはそれ以上のクライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワーク・ステーション、獲得モジュール、理学療法装置、表示システム、ＤＩＣＯＭ媒体、デジタル・アーカイブまたはＤＩＣＯＭ通信プロトコルかＤＩＣＯＭ規格を使用して作動できる他のタイプの装置上で実行できる。ＤＩＣＯＭ画像ファイルおよびＤＩＣＯＭ画像ファイル内に収容される関連情報の代表的な例を図７と図８に示す。
【００３３】
通信モジュール１００は、通信エンジン１０４、データ要素発信元１０６、データ要素の受信側１０８、状態機械１１０、バッファ１１２およびＤＩＣＯＭプロトコル１１４のような多層プロトコルを含む。通信エンジン１０４は、関連アプリケーション・プログラム１０１と通信モジュール１００の間および通信モジュール１００とＤＩＣＯＭネットワーク１０２の間で、データおよび関連データ要素を処理するように構成される。通信エンジン１０４は、また通信モジュール１００の種々の構成要素の間およびＤＩＣＯＭプロトコル１１４の多重の層の間でデータを伝送するように構成される。他の実施例による通信モジュールは、類似の機能を提供する、より少ない、または、より多くの要素を有する。
【００３４】
データ要素の発信元１０６は、データ要素のための概念的なソースである。データ要素の発信元は、データ要素の概念的なセット上で順方向の繰返し器として機能できる。データ要素の発信元１０６は、一回に１つずつまたはブロックで、データ要素をサービス・クラス・ユーザー（ＳＣＵ）またはクライアントまたはサーバ１２８ａ−ｎのようなサービス・クラス・プロバイダ（ＳＣＰ）に供給する。たとえば、データ要素の発信元１０６は、シーケンス・データ（ＳＱ）要素を処理できる。
【００３５】
データ要素の発信元１０６は、また１つのピクセル・データ・デコーダを含む。ピクセル・データ・レコーダは、ピクセル・データを一回に１つずつ段階的に処理する。たとえば、ピクセル・データ・レコーダは、ピクセル・データ（ＰＤ）要素を処理する。単一のピクセル・データ要素は、数メガバイトのデータを含むので、ピクセル・データ・レコーダは、比較的小さな固定サイズのチャンクのデータを読み取ることを可能にする。ピクセル・データ要素に遭遇すると、ピクセル・データ・レコーダは、一回に全部のデータ要素を読まず、代わりに１１２と図示したバッファのような固定サイズのバッファにピクセル・データが段階的に読み込まれる。
【００３６】
データ要素の発信元１０６は、ストリーミング・データ要素を含む。同様に、ストリーミング・データ要素を段階的に処理できる。
【００３７】
データ要素の受信側１０８は、データ要素のための概念的な記憶装置である。データ要素の受信側１０８は、一回に１つずつまたはブロックでデータ要素をクライアントまたはサーバ１２８ａ−ｎのようなサービス・クラス・ユーザ（ＳＣＵ）に書き込むことができる。たとえば、データ要素の受信側１０８は、シーケンス・データ（ＳＱ）要素を処理できる。
【００３８】
データ要素の受信側１０８は、またピクセル・データ・エンコーダを含む。ピクセル・データ・エンコーダは、ピクセル・データを一回に１つずつ段階的に処理する。たとえば、ピクセル・データ・エンコーダは、ピクセル・データ（ＰＤ）要素を処理する。単一のピクセル・データ要素は、数メガバイトのデータを含むので、ピクセル・データ・エンコーダは、比較的小さな固定サイズのチャンクのデータでピクセル・データを書き込むことを可能にする。ピクセル・データ要素に遭遇すると、ピクセル・データ・エンコーダは、一度に全てのデータ要素を書き込まず、代わりに１１２として示されるバッファのような固定サイズ・バッファに段階的にピクセル・データを書き込む。
【００３９】
データ要素の受信側１０８は、ストリーミング・データ要素を含む。同様に、ストリーミング・データ要素を段階的に処理できる。
【００４０】
状態機械１１０は、サービス・クラス・プロバイダ（ＳＣＰ）とサービス・クラス・ユーザ（ＳＣＵ）の間の結合または接続の開始、監視および処理をする。
【００４１】
バッファ１１２は、データ要素、データ値または他のタイプのデータを記憶するように構成されたメモリ記憶装置である。バッファ１１２は、またデータ要素、データ値または他のタイプのデータを記憶する、より小さなバッファまたは類似のタイプのメモリ装置を含む。
【００４２】
ＤＩＣＯＭプロトコル１１４は、トランスポート層１１６、アッパ・レベル・サービス層１１８、データ・サービス層１２０およびサービス・クラス層１２を含む多重層を収容する。ＤＩＣＯＭプロトコルおよび関連層１１６−１２２の仕様、機能性および一層詳細な説明は、医療デジタル画像および通信（ＤＩＣＯＭ）規格書、ＰＳ３．１−２０００、米国電気製造業協会、２０００年に掲示されているが、これは参考文献として本明細書に組み込まれている。
【００４３】
通信モジュール１００は、関連アプリケーション・プログラム１０１と連絡する。通信モジュール１００は、またＤＩＣＯＭネットワーク１０２などの通信ネットワークを通じて、もう１つのアプリケーション・プログラム１３０と連絡する。典型的に、もう１つのアプリケーション・プログラム１３０は、物理層１２４、すなわちＥＴＨＥＲＮＥＴ（登録商標）、ＡＴＭ、ＦＤＤＩのようなインターフェイスを通じて通信モジュール１００とＤＩＣＯＭネットワーク経由で連絡する。さらにＤＩＣＯＭネットワーク１０２が伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）１２６を使用して他のネットワーク、コンピュータ、フラットフォームおよびアプリケーションとの連絡を更に容易にすることは、当業者には理解される。こうして、通信モジュール１００は、トランスポート層１１２により、ＴＣＰ／ＩＰ１２６に隣接して配置され、これによりＤＩＣＯＭネットワーク１０２と通信モジュール１００の間にインターフェイスを生成する。当業者は、この構成を容易にするのに必要な方法とシステムを理解する。
【００４４】
ＤＩＣＯＭネットワーク１０２は、図示のようにネットワーク構成に接続される１つまたはそれ以上のサーバ１２８ａ−ｎを含む。いくつかの場合、ローカル・エリア・ネットワーク、すなわちＬＡＮ構成内で作動するためにＤＩＣＯＭネットワーク１０２が設立される。
【００４５】
サーバ１２８ａ−ｎには、クライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワークステーション、獲得モジュール、理学療法装置、表示システム、ＤＩＣＯＭ媒体、デジタル・アーカイブまたはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用して動作可能な他のタイプの装置が含まれる。ＤＩＣＯＭネットワーク１０２においては、サーバ１２８ａ−ｎは、サービス・クラス・プロバイダ（ＳＣＰ）またはサービス・クラス・ユーザ（ＳＣＵ）である。
【００４６】
当業者は、ＤＩＣＯＭネットワーク１０２に類似して作動する通信ネットワークの他の構成をよく知っている。
【００４７】
アプリケーション・プログラム１３０は、サーバ１２８ａ−ｎ上で実行するように構成される。一般にアプリケーション・プログラム１３０は、医療画像プログラムのようなＤＩＣＯＭアプリケーション・プログラムまたはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用して通信モジュール１００と通信できるアプリケーション・プログラムである。アプリケーション・プログラム１３０は、クライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワークステーション、獲得システム、理学療法装置、表示システムのような他のプラットフォーム上で実行可能であり、これらのプラットフォームは、ＤＩＣＯＭネットワーク１０２に接続される。
【００４８】
通信モジュール１００は、また媒体記憶モジュール１３２およびメタ・データベース・モジュール１３０と連絡する。媒体記憶モジュール１３２は、通信モジュール１００と連絡し、一時的または永久的なベースでデジタル画像データを記憶するように構成される。媒体記憶モジュール１３２は、ハード・ドライブ、光磁気ディスク・ドライブ、ＣＤ−ＲＷドライブ、ＣＤ−ＲＯＭドライブのような記憶媒体または他の類似のタイプの記憶媒体を含む。注意すべきは、アプリケーション・プログラム１３０は、また媒体記憶モジュール１３２から実行されるように構成できることである。
【００４９】
メタ・データベース・モジュール１３４は、また通信モジュール１００と連絡して、一時的または永久的ベースでデジタル画像データを記憶するように構成される。メタ・データベース・モジュール１３４は、デジタル・データを記憶する通常のデータベースのような記憶媒体を含む。
【００５０】
図２は、本発明の実施例の一般的なデータの流れの図である。この図は、ネットワークとアプリケーションの間でオブジェクトまたは画像ファイルを伝送中に、ＤＩＣＯＭプロトコルの多重層を通るデータ・フロー２００の実施例を示す。この例において、ネットワークは、ネットワーク・レベル２０２により表現され、アプリケーションは、アプリケーション・レベル２０４により表現される。図１と図２の両方における要素を参照すると、ネットワーク・レベル２０２は、サーバ１２８ａ−ｎを有するＤＩＣＯＭネットワーク１０２を含む。アプリケーション・レベル２０４は、通信モジュール１００に関連する医療画像プログラムのような関連アプリケーション・プログラム１０１を含む。代わりにアプリケーション・レベルは、他のサーバ１２８ａ−ｎ、すなわちＤＩＣＯＭネットワーク１０２内のクライアント・コンピュータなどのＤＩＣＯＭプロトコル可能な装置上で実行できる。通信モジュール１００は、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間の結合または接続を生成することにより、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間のデータ通信を容易にする。通信モジュール１００は、どのサービス・オブジェクト・ペア（ＳＯＰ）クラスが使用されるかを決定し、ＳＣＰおよびＳＣＵの役割を定義し、プロトコル層の間で通信するのに使用される転送構文のタイプを折衝し、ＤＩＣＯＭネットワーク・プロトコルまたはオブジェクトかデジタル画像を処理する類似のタイプのプロトコルにより他の通信パラメータを決定することなどの標準的なＤＩＣＯＭネットワーク・プロトコルの詳細を処理する。注意すべきは、代わりの構成において他の装置がＳＣＰ、ＳＣＵとして機能し得ることであり、またはＳＣＰＵおよびＳＣＵの両方として機能し得ることである。
【００５１】
その上、通信モジュール１００は、メモリ記憶装置、ハード・ドライブ、ＣＤ−Ｒ、ＣＤ−ＲＷなど２つの装置の間または２つの異なったメモリ記憶装置のあらゆる他の組合せの間でデジタル・データを伝送し、またはストリーミングするのに使用される。ネットワークから装置へまたは装置からネットワークなど他の構成の間でデジタル・データを通信するためにも通信モジュール１００が使用され、これらの装置は、メモリ記憶装置、ハード・ドライブ、ＣＤ−Ｒ、ＣＤ−ＲＷまたは他の類似のタイプの装置を含むことは、当業者に理解される。
【００５２】
その上、通信モジュール１００は、関連アプリケーション・プログラム１０１およびサーバ１２８ａ−ｎと折衝して、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間で伝送されるプロトコル・データ・ユニット（ＰＤＵ）の最大サイズを定義する。ＰＤＵの最大サイズは、利用できるメモリのカレント・サイズおよび通信ネットワークの全体的な効率によって異なる。
【００５３】
その上、通信モジュール１００は、表示データ値の入力ストリームに読み込める所定または限定された数の表示データ値（ＰＤＶ）を定義するために折衝する。所定または限定された数の表示データ値（ＰＤＶ）は、利用できるメモリ記憶域のカレント・サイズおよび／または通信ネットワークの全体的な効率によって異なる。代わりに通信モジュール１００は、データ入力ストリームに読み込めるデータ要素の所定または限定されたサイズを定義することができる。データ要素の所定または限定された数は、利用可能なメモリ記憶域のカレント・サイズおよび／または通信ネットワークの全体的な効率により異なる。通信装置１００により処理されるデータ要素のタイプにより、これらの技法の１つまたはそれ以上が使用され、本発明により特定のデータ要素を伝送する間にメモリ資源の消費を比較的小さな固定された量に限定する。注意すべきは、表示データ値（ＰＤＶ）がヘッダとペイロードを含み、これらは、バイトの配列であることである。
【００５４】
通信モジュール１００により上述の結合または接続の詳細が完了した後に、通信モジュール１００は、ネットワーク・レベル２０２からアプリケーション・レベル２０４にデータ２０６を伝送することに進む。つまり、通信モジュール１００は、サーバ１２８ａ−ｎ（この例では、ＳＣＰとして作用している）から受信するデータ２０６を処理して、処理されたデータを関連アプリケーション・プログラム１０１（この例では、ＳＣＵとして作用する）に送る。典型的にデータ２０６は、１つまたはそれ以上のデータ要素を含むＤＩＣＯＭオブジェクトまたはＤＩＣＯＭ画像ファイルである。データ２０６は、最初にネットワーク・レベル２０２において、サーバ１２８ａ−ｎにより処理される。サーバ１２８ａ−ｎは、ＥＴＨＥＲＮＥＴ（登録商標）、ＡＴＭ、ＦＤＤＩのような標準的なネットワーク物理層２０８を通じてデータ２０６を伝送する。
【００５５】
次に、データ２０６は、ＴＣＰ／ＩＰ２１０を通じて１つまたはそれ以上のデータ・パケット２１２の形式で、標準的なネットワーク物理層から伝送される。ＴＣＰ／ＩＰ２１０は、ＤＩＣＯＭオブジェクトまたはＤＩＣＯＭ画像ファイルを含むデータ２０６を、１つまたはそれ以上のデータ・パケット２１２に変換する。この変換を実行するのに必要な方法とシステムは、当業者には理解される。
【００５６】
ＴＣＰ／ＩＰ２１０は、ソケット２１６を使用して、データ・パケット２１２をＤＩＣＯＭプロトコル層２１４に伝送する。ＤＩＣＯＭプロトコル層２１４は、トランスポート２１８、アッパ・レベル・サービス２２０、データ・サービス２２２、サービス・クラス２２４を含む多重の層を収容する。ソケット２１６は、ＴＣＰ／ＩＰ２１０とＤＩＣＯＭネットワーク・プロトコルなど、他のネットワーク・プロトコルの間の通信を容易にするアプリケーション・プログラム・インターフェイス（ＡＰＩ）である。ＴＣＰ／ＩＰ２１０、ＤＩＣＯＭプロトコル層２１４、ソケット２１６を実施するのに必要な方法とシステムは、当業者には理解される。
【００５７】
ＴＣＰ／ＩＰ２１０は、データ・パケット２１２をトランスポート層２１６として知られるＤＩＣＯＭプロトコル層２１４の第１の層に伝送する。通信モジュール１００は、トランス・ポート層２１６においてデータ・パケット２１２を受信して、ＴＣＰ／ＩＰ２１０からデータ・パケット２１２の各々を段階的に読み取る。つまり、通信モジュール１００に結合された通信エンジン（図１に１０４として示す）がトランスポート層２１６を使用して、一回に１つずつデータ・パケット２１２を読み取る。データ・パケット２１２が処理されると、通信エンジン１０４がデータ・パケット２０８をプロトコル・データ・ユニット２２６に変換する。プロトコル・データ・ユニット（ＰＤＵ）２２６は、ヘッダ２２８と１つまたはそれ以上の表示データ値（ＰＤＶ）２３０を含む。
【００５８】
それから、各ＰＤＵ２２６は、トランスポート層２１８からアッパ・レベル・サービス層２１８に通信エンジン１０４によって送られる。それから、ＰＤＵは、データ・サービス層２２２に伝送される。
【００５９】
それから、通信エンジン１０４は、データ・サービス層２２２により受信された各ＰＤＵ２２６から表示データ値（ＰＤＶ）２３０を抽出する。一般に、通信エンジン１０４は、ＰＤＶ２３０から表示データ値の入力ストリーム（ＰＤＶＩＳ）２３２を生成する。通信エンジン１０４は、ＰＤＶＩＳ２３２を使用してメッセージ２３４を形成する。
【００６０】
通信エンジン１０４は、ＰＤＶＩＳ２３２を含むメッセージ２３４をサービス・クラス層２２４に伝送する。サービス・クラス層２２４でデータ要素の発信元２３６は、各メッセージからの表示データ値の入力ストリーム（ＰＤＶＩＳ）２３２からデータ要素を抽出する。データ要素の発信元２３６は、新しい入力転送構文（ＩＴＳ）２３８になり、これはＰＤＶＩＳ２３２内に含まれるデータを構文解析するために使用できる。
【００６１】
アプリケーション・レベル２０４で、入力転送構文２３８がバイトの入力ストリームからデータ要素２４０を抽出して、このデータ要素２４０を関連アプリケーション・プログラム１０１により要求される時に使用する。入力転送構文２３８は、ストリーミング閾値と呼ばれる属性を有する。抽出されたデータ要素がストリーミング閾値よりも長ければ、データ要素２４０は、ストリーミング・データ要素である。ストリーミング・データ要素は、入力転送構文２３８になお存在する実際のデータ素子２４０の代りである。このストリーミング・データ要素は、入力転送構文２３８を使用して、その値に段階的にアクセスすることを可能にする。段階的アクセスは、ストリーミング・データ要素が書き込まれているデータのブロックにより供給される。
【００６２】
アプリケーション・レベル２０４からネットワーク・レベル２０２への下向きのデータ・フロー２４２のために、データ要素の発信元２３６が最初にサービス・クラス２２４を通じて移動する。それからデータ要素の発信元２３６は、データ・サービス２２２を通過する。データ・サービス２２２でパケッタイザ２４４は、データ要素の発信元２３６を取って出力転送構文２３８を生成する。出力転送構文２３８は、データ要素の発信元２３６からのデータ要素の各々を処理して、エンコードされたデータ要素をパケッタイザ２４４に渡す。それから、パケッタイザ２４４は、エンコードされたデータ要素をとって表示データ値（ＰＤＶ）を生成する。
【００６３】
ＰＤＶが生成されると、このＰＤＶは、ＤＩＣＯＭ状態機械２４６に渡されて、そこで処理される。それからＰＤＶは、ＤＩＣＯＭ状態機械２４６により、トランスポート・レベル２１８に渡される。トランスポート２１８は、ＰＤＶをＴＣＰ／ＩＰ層２１０へ書き出すが、それは、ネットワーク接続であるバイトの出力ストリーム２４８を通じて行う。
【００６４】
図２を参照して上記した例示的なデータ・フローは、比較的大きなＤＩＣＯＭオブジェクトを処理するために限定された固定量のメモリのみを使用する。使用するメモリは、メモリ使用シナリオに関して下記のように説明できる。ネットワーク・レベルからアプリケーション・レベルに送られる１つのＤＩＣＯＭオブジェクトは、そのサイズが約６００メガバイト（ＭＢ）であり、その内の５９９ＭＢは、ピクセル・データ（ＰＤ）要素である。最大のプロトコル・データ・ユニット（ＰＤＵ）サイズは、結合または接続中に折衝され、その最大サイズは、約２０キロバイト（ＫＢ）である。さらに、この結合または接続は、表示データ値の入力ストリーム（ＰＤＶＩＳ）内の表示データ値（ＰＤＶ）の最大数を所定の限度、すなわち最大数の５に定義できる。注意すべきは、この所定の限度は、表示データ値（ＰＤＶ）を記憶するのに使用されるバッファまたはメモリ記憶装置のサイズにより選択できることである。
【００６５】
ＰＤＶＩＳがＰＤＶの数を５に限定すれば、ネットワークからＤＩＣＯＭオブジェクトを読み取るのに必要なメモリの最大量は、（５ Ｘ ２０ＫＢ）＋２０ＫＢ、すなわち１２０ＫＢである。この「＋２０ＫＢ」は、ＰＤＶＩＳに配置されるＰＤＵ待ちが原因である。
【００６６】
それから、アプリケーション・プログラムは、入ってくるＤＩＣＯＭオブジェクトをファイルに書き込み、入力転送構文（ＩＴＳ）をデータ要素の発信元として出力転送構文（ＯＴＳ）にファイルのために渡す。ＯＴＳは、ピクセル・データ要素をエンコードするために約１０ＫＢを使用する。その他の全てのデータ要素は、全体として個別にエンコードできるが、シーケンス・データ（ＳＱ）要素は、例外である。全ての他のデータ要素は、通常１０ＫＢよりも比較的に小さいので、ファイルするためにデータ要素をデコードするのに使用されるメモリの最大量は、１０ＫＢになるはずである。
【００６７】
こうして、ネットワークからデコードするために使用されるメモリおよびファイルにエンコードするために使用されるメモリの総量は、デコードのために約１２０ＫＢ、エンコードのために１０ＫＢであり、合計で１３０ＫＢになるはずである。
【００６８】
図３から図６は、本発明に使用される方法の実施例のフローチャートを示す。図３ａから図３ｃおよび図４ａと図４ｂは、ネットワークからの読取りおよびそこへの書込みのようなオペレーションを示し、図５と図６は、ファイルからの読取りと、そこへの書込みのようなオペレーションを示す。図３から図６に示す方法を採用することにより、比較的小さな固定量のメモリのみを使用して、全てのあり得るＤＩＣＯＭデータの相互作用を処理することができる。これらのＤＩＣＯＭデータの相互作用は、ネットワークからメモリ記憶装置へのデータの読取りと書込み、メモリ記憶装置からネットワークへのデータの読取りと書込み、およびネットワークからネットワークへの読取りと書込みのようなＤＩＣＯＭネットワークの相互作用を含む。注意すべきは、種々の構成のメモリ記憶装置およびネットワークを使用する他のタイプのＤＩＣＯＭデータの相互作用が本発明により実行できることである。
【００６９】
図３ａから図３ｃは、デジタル・データをネットワークからアプリケーションへ読み込む方法３００を示す。一般に、デジタル・データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ネットワークは、ＤＩＣＯＭ通信ネットワークであり、アプリケーションは、ＤＩＣＯＭネットワーク・プロトコルを使用して通信できる医療画像アプリケーション・プログラムである。この方法３００は、３０２で開始する。
【００７０】
３０２に続く３０４において、通信エンジン１０４は、プロトコル・データ・ユニット（ＰＤＵ）のサイズを折衝する。ＰＤＵのサイズを設立することにより、通信エンジン１０４は、デジタル・データを処理するのに必要または望ましいバッファ１１２内のメモリの量を監視できるようになる。その上、表示データ値（ＰＤＶ）の所定の数、限度またはサイズまたは他のタイプのデータ要素または品質も、デジタル・データを処理するのに必要または望ましいバッファ１１２内のメモリ記憶域の量によって設立できる。典型的に、これらのステップは、状態機械１１０によるサービス・コントロール・プロバイダ（ＳＣＰ）とサービス・コントロール・ユニット（ＳＣＵ）の間の結合または接続の設立と共に実行される。アッパ・レベル・サービス層１１８を通じて、通信エンジン１０４は、方法３００全体を通じて状態機械１１０を監視し制御する。
【００７１】
３０４に続く３０６で通信エンジン１０４は、ネットワークからデジタル・データを段階的に読み取る。たとえば、通信エンジン１０４は、ＤＩＣＯＭネットワーク１０２内のサーバ１２８ａ−ｎからＤＩＣＯＭ画像ファイルなどのデジタル・データを要求する。ＤＩＣＯＭ画像ファイルは、デジタル画像データの１つまたはそれ以上のセットを含む。サーバ１２８ａ−ｎは、ソケット、アプリケーション・プログラム・インターフェイスを介してＴＣＰ／ＩＰ１２６を通じて通信エンジン１０４にデジタル画像データ・セットを伝送する。通信エンジン１０４は、サーバ１２８ａ−ｎからＤＩＣＯＭパケットまたはプロトコル・データ・ユニット（ＰＤＵ）の形式でデジタル画像データ・セットを受信する。
【００７２】
注意すべきは、ソケットを使用してＴＣＰ／ＩＰを通じてデジタル・データを生成し伝送するのに必要な方法とシステムは、当業者に理解されることである。さらに、プロトコル・データ・ユニット（ＰＤＵ）とＤＩＣＯＭパケットは、すでに上述のＤＩＣＯＭネットワーク・プロトコルの下で定義されている。
【００７３】
３０６に続く３０８で通信エンジン１０４は、各ＰＤＵまたはＤＩＣＯＭパケットを段階的に読み取る。つまり、通信エンジン１０４は、ＤＩＣＯＭプロトコル１１４のトランスポート層１１６を通じて読取りスレッド（図示なし）を開始する。読取りスレッドは、ＤＩＣＯＭプロトコル１１４のトランスポート層１１６のいたるところに、一回に１つずつＰＤＵまたはＤＩＣＯＭパケットの各々を段階的に読み取って伝送する。読取りスレッドは、ネットワークから伝送すべきデジタル・データのＰＤＵまたはＤＩＣＯＭパケットの全てが処理されるまで、ＰＤＵまたはＤＩＣＯＭを処理し続ける。
【００７４】
３０８に続く３１０で通信エンジン１０４は、ＰＤＵをアッパ・レベル・サービス層１１８に伝送する。結合または接続中にＰＤＵが適当な時間に達すると、通信エンジン１０４によりＰＤＵは、データ・サービス層１２０に伝送される。
【００７５】
３１０に続く３１２で通信エンジン１０４は、各プロトコル・データ・ユニット（ＰＤＵ）から表示データ値（ＰＤＶ）を抽出する。つまり、ＰＤＵがデータ・サービス層１２０に受信されると、通信エンジン１０４は、ＰＤＵから表示データ値（ＰＤＶ）を抽出する。各プロトコル・データ・ユニットは、１つまたはそれ以上の表示データ値を含む。
【００７６】
３１２に続くサブルーチン３１４でオペレーション・メッセージのために表示データ値の入力ストリームが生成される。サブルーチン３１４は、図３ｃを参照して一層詳細に説明される。
【００７７】
図３ｂにおいて、サーブ・ルーチン３１４は、３５０で始まる。３５０において通信エンジン１０４は、表示データ値を使用して、表示データ値の入力ストリームを生成する。最初、すなわち第１のプロトコル・データ・ユニット（ＰＤＵ）のために、通信エンジン１０４で受信された抽出表示データ値（ＰＤＶ）が使用されて、表示データ値の入力ストリーム（ＰＤＶＩＳ）が生成される。後続のＰＤＵのために抽出ＰＤＶが既存の表示データ値の入力ストリームに挿入されるか、または必要な場合は、新しい表示データ値の入力ストリームが生成される。表示データ値の入力ストリームは、本質的に比較的小さな固定量のメモリを使用して伝送できる１つまたはそれ以上のＰＤＵからの表示データ値（ＰＤＶ）のストリングである。表示データ値の入力ストリーム（ＰＤＶＩＳ）は、オペレーション・メッセージの基礎を形成する。
【００７８】
通信エンジンは、各抽出ＰＤＶを一回に１つずつデータ・サービス層１２０に段階的に伝送し続ける。データ・サービス層１２０は、上記のように各ＰＤＶを表示データ値の入力ストリーム（ＰＤＶＩＳ）に挿入する。ＰＤＶＩＳは、ある与えられた瞬間において、所定または限られた数のＰＤＶを記憶するように限定される。典型的にＰＤＶＩＳは、一回に５ＰＤＶを記憶するように限定される。注意すべきは、所定または限定された数は、ＰＤＶおよび／またはＰＤＶＩＳに記憶すべきバッファまたは他のメモリ記憶装置のサイズによって決定されることである。
【００７９】
３５０に続く決定ブロック３５２でデータ・サービス層は、所定または限定された数のＰＤＶに到達したかどうかを決定する。この方法で、画像データの伝送が段階的に制御されて、全ての画像データを処理するのに必要なメモリ記憶空間の量を最小化することができる。データ要素の発信元１０６は、一回に１つずつ段階的にＰＤＶを処理して、各ＰＤＶをＰＤＶＩＳに伝送する。所定または限定されたＰＤＶの数に達すると、「ＹＥＳ」分岐をたどって３５４に行く。たとえば、所定または限定された数のＰＤＶが事前に５に設定され、特定のＰＤＶＩＳ内に、この所定または限定された数のＰＤＶがすでに存在すれば、そのときは、すでに限界に達している。この方法で、本発明は、メモリの使用をＤＩＣＯＭデータなどのデジタル・データの伝送のために使用し得る比較的小さな固定したメモリの量に監視し限定することができる。いくつかの場合には、バッファ１１２またはメモリ記憶装置のサイズによって、所定または限定されたサイズが設定されることに注意される。この方法により、ピクセル・データ（ＰＤ）要素および比較的大きなＤＩＣＯＭオブジェクトを比較的小さな固定サイズのメモリ部分で処理することができる。
【００８０】
３５４において通信エンジン１０４は、表示データ値の入力ストリームから表示データ値が読み取られるまで、表示データ値の更なる処理を遅らせる。通信エンジン１０４は、データ・サービス層１２０に命令して、表示データ値の入力ストリーム（ＰＤＶＩＳ）から表示データ値（ＰＤＶ）が読み取られるまで待たされる。つまり、通信エンジン１０４は、１つのＰＤＶがデータ・サービス層１２０にＰＤＶＩＳから読み取られるまで、トランスポート層１１６が更なるＰＤＶをＰＤＶＩＳに読み込むのを防止するように命令する。１つのＰＤＶがＰＤＶＩＳから読み取られると、通信エンジン１０４は、データ・サービス層に命令し、トランスポート層１１６が所定または限定された数のＰＤＶに達するまでＰＤＶをＰＤＶＩＳに渡し続けられる。
【００８１】
決定ブロック３５２に戻ると、ＰＤＶの所定または限定された数に達していなければ、「ＮＯ」分岐をたどって、そこでサブルーチン３１４が終了して、３１６で方法３００が継続する。
【００８２】
３１６において、メッセージ・サービスは、どのオペレーションにオペレーション・メッセージが対応するかを決定する。典型的にサブ・ルーチン３１４内で通信エンジン１０４により１つのオペレーション・メッセージが生成されると、通信エンジン１０４は、メッセージ・サービス（図示なし）にＰＤＶとＰＤＶＩＳを含むオペレーション・メッセージを送る。メッセージ・サービスは、ＤＩＣＯＭプロトコル１１４のデータ・サービス層１２０の構成要素である。
【００８３】
ＤＩＣＯＭネットワーク・プロトコルにおいて、オペレーションは、サービス・オブジェクト・ペア（ＳＯＰ）により定義される。状態機械１１０により設立される最初の結合または接続の間に、１つまたはそれ以上のＳＯＰが識別できる。ＳＯＰを使用することにより、メッセージ・サービスは、メッセージが一致または対応するオペレーションを有するかどうかを決定する。
【００８４】
３１６に続く３１８において、メッセージ・サービスは、オペレーション・メッセージを対応するオペレーションに伝送する。メッセージ・サービスにより、ＳＯＰがあるメッセージに対して対応する一致と識別されると、オペレーション・メッセージは、対応するオペレーションに伝送される。
【００８５】
３１８に続く３２０において、オペレーション・メッセージは、後続の処理のために対応するオペレーショにより待ち行列に入れられる。メッセージが待ち行列に入れられると、この方法３００は、図３ｃの３２０で継続する。
【００８６】
３２０に続く３２２において、待ち行列に入れられたメッセージは、それぞれのオペレーションにより処理される。少なくとも１つの待ち行列に入れられたオペレーション・メッセージを受信する全てのオペレーションは、１つのスレッドを開始する。それから、各オペレーションについて、各スレッドが各待ち行列に入れられたオペレーション・メッセージを一回に１つずつ処理する。それから、各待ち行列に入れられたオペレーション・メッセージは、オペレーション・メッセージがそのために生成された対応するサービスに渡される。注意すべきは、ＤＩＣＯＭネットワーク・プロトコルにより定義されるように、各オペレーションが１つの対応するサービスまたはＳＯＰを有することである。それぞれのオペレーションのために各待ち行列に入れられたメッセージの処理が完了するまで、各スレッドは、各オペレーション・メッセージの処理を続ける。
【００８７】
３２２に続く３２４において、サービスは、表示データ値の入力ストリーム（ＰＤＶＩＳ）からデータ要素を抽出する。
【００８８】
３２４に続く３２６において、サービスは、新しい入力転送構文（ＩＴＳ）を生成する。サービスは、表示データ値の入力ストリーム（ＰＤＶＩＳ）を使用して、新しいＩＴＳを生成し、この新しいＩＴＳは、ＰＤＶＩＳに含まれるデータを構文解析するために使用できる。ＰＤＶＩＳに含まれるデータは、一連の表示データ値（ＰＤＶ）である。典型的にはデータ値は、エンコードされ、コーディングをデータ要素の標準的なメモリ表現として理解できる表現に変換するために、入力転送構文が使用できる。それから、構文解析されたデータは、通信エンジン１０４によりデータ要素の発信元１０６にストリームされる。
【００８９】
３２６に続く３２８において、データ要素の発信元１０６は、構文解析されたデータ・ストリームを段階的に読み取る。各サービスは、データ要素の発信元１０６を使用して、表示データ値の入力ストリーム（ＰＤＶＩＳ）内に収納されたデータ・ストリームから、一回にデータ要素の１つのブロックを読み取る。入力転送構文（ＩＴＳ）は、またデータ要素の発信元１０６を通じてデータ要素を段階的に読むために使用される。
【００９０】
データ要素の発信元１０６において、サービスにより少なくとも２つのタイプのデータ要素を処理できるが、それはシーケンス・データ（ＳＱ）とピクセル・データ（ＰＤ）である。ＳＱデータ要素は、データ要素の１つまたはそれ以上のセットを含むデータ要素である。ＳＱデータ要素は、再帰的に処理できる。つまり、データ要素の１セットは、一回に１つずつのデータ要素が処理される。ＰＤ要素は、ＤＩＣＯＭオブジェクトまたは画像ファイル内で最大のデータ要素の１つである。ＰＤ要素は、バイト（８ビット）またはワード（１６ビット）の未加工のデータ配列により構成される。このタイプのデータ要素は、ストリーミングの追加の層を可能にする。サービスは、ピクセル・データを段階的に獲得でき、こうして時間の単一インスタンスにおいて、メモリ内に全てのＰＤ値を獲得する必要性を最小化できる。ピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトが比較的大きいものであることに注意される。本発明は、全てのサイズのピクセル・データ（ＰＤ）要素とＤＩＣＯＭオブジェクトを比較的小さな時間上の部分の中で処理できる。
【００９１】
３２６に続く３２８において方法３００が終了する。
【００９２】
図４ａと図４ｂは、本発明の第２の例示的な方法を示す。後述するが、図４ａと図４ｂは、あるアプリケーションからネットワークまたは他のアプリケーションにデータを書き込む方法４００を記述する。一般に、データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ネットワークは、ＤＩＣＯＭ通信ネットワークであり、アプリケーションは、ＤＩＣＯＭネットワーク・プロトコルを使用して通信できる医療画像アプリケーション・プログラムである。
【００９３】
４０２において方法４００が開始する。
【００９４】
４０２に続く４０４において、通信エンジン１０４は、１つのデータ・セットを求める。典型的にあるユーザが結合アプリケーション・プログラム１０１と対話するときに、または代わりにＤＩＣＯＭネットワーク１０２内のサーバ１２８ａ−ｎ上で実行するアプリケーション・プログラム１３０と対話するときに、このユーザは、特定のＤＩＣＯＭオブジェクトまたは画像上で特定の機能を実行したいと望むかも知れない。ユーザは、アプリケーション・プログラム１０１、１３０またはネットワーク１０２の特定サービスに対応する関連アプリケーション１０１またはアプリケーション・プログラム１３０内の対応するコマンド機能を選択する。このコマンド機能を受信すると、サービスは、通信エンジン１０４のために対応するデータ・セットを配置する。注意すべきは、あるデータ・セットは１つまたはそれ以上のデータ・セットであって、各データ・セットが１つまたはそれ以上のデータ要素を含むことである。ＤＩＣＯＭオブジェクトまたは画像のためのデータ・セットは、媒体記憶装置モジュール１３２またはメタ・データ・ベース・モジュール１３４のような関連メモリ装置内に記憶される。
【００９５】
４０４に続く４０６において選択されたサービスは、データ・セットのために新しい出力転送構文（ＯＴＳ）を生成する。サービスがコマンド機能を受信すると、このサービスは、データ・セットを処理するために新しい出力転送構文（ＯＴＳ）を生成する。ＯＴＳは、データ・セットをバイト・ストリームのようなデータ・ストリームにフォーマットまたは変換できる。データ・セットは、データ要素の発信元である。ＯＴＳは、データ要素の発信元をバイト・ストリームのようなデータ・ストリームにフォーマットまたは変換できる。データ要素の発信元（ＤＥＳ）は、データ要素の概念的なセット上の順方向イテレータである。たとえば、入力転送構文（ＩＴＳ）は、表示データ値（ＰＤＶ）の特定セットのためにデータ要素（ＤＥＳ）を生成できる。
【００９６】
４０６に続く４０８においてサービスは、統率データ・セット入力ストリーム（ＧＤＳＩＳ）を生成する。出力転送構文を使用してサービスは、統率データ・セット入力ストリーム（ＧＤＳＩＳ）を生成する。それからＧＤＳＩＳは、それ自身のスレッドを使用してデータ・セットまたはデータ要素の発信元を出力転送構文を使用するバイト・ストリームのようなデータ・ストリームに変換する。ＧＤＳＩＳは、比較的小さな固定量のメモリのみを使用して、データ・セットまたはデータ要素の発信元をデータ・ストリームに変換する。
【００９７】
典型的に、出力転送構文は、データ・セットまたはデータ要素の発信元から一回に１つずつデータ要素を取り、各データ要素を一連のデータ要素またはデータ・ストリームにエンコードする。少なくとも２つのタイプのデータ要素が出力転送構文により処理されるが、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合は、ＳＱ要素がデータ要素のセットを含む。ＳＱ要素が出力転送構文（ＯＴＳ）により読み取られると、ＯＴＳは、１つの特定データ要素のセットから一回に１つずつデータ要素を再帰的に処理する。ＰＤ要素の場合は、ＰＤ要素がバイトまたはワードの大きな配列を含む。出力転送構文（ＯＴＳ）によりＰＤ要素が読み取られると、ＯＴＳは、これらをデータ要素の片または小さな固定サイズとして処理する。いずれの場合もメモリの比較的小さな固定サイズのみがデータ要素を処理するためにＯＴＳにより使用される。サービスは、ピクセルを段階的に獲得できるので、ある１つの瞬間にメモリ内の全てのＰＤ値を獲得する必要性を最小化できる。注意すべきは、ピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトが比較的大きいことである。本発明は、全てのサイズのピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトを比較的小さな時間で処理できる。
【００９８】
４０８に続く４１０においてサービスは、統率データ・セット入力ストリームをオペレーション・メッセージ内にパッケージする。
【００９９】
４１０に続く４１２においてサービスは、メッセージ・サービスにメッセージを送る。
【０１００】
４１４に続く４１６においてメッセージ・サービスは、メッセージに対応するオペレーションを決定する。
【０１０１】
４１６に続く４１８においてメッセージ・サービスは、データ・サービス層１２０にメッセージを渡す。
【０１０２】
４１８に続く４２０においてデータ・サービス層１２０は、メッセージから統率データ・セット入力ストリームをデコードする。一般に、データ・サービス層１２０は、メッセージ・サービスからメッセージを受信する。メッセージ・サービスは、メッセージから統率データ・セット入力ストリーム（ＧＤＳＩＳ）を抽出して、ＧＤＳＩＳからバイトを読み取る。メッセージ・サービスが１つのプロトコル・データ・ユニット（ＰＤＵ）を構築できるまで、メッセージ・サービスは、ＧＤＳＩＳからバイトを読み取り続ける。それから方法４００は、図４ｂの４２０で継続する。
【０１０３】
４２０に続く４２２においてメッセージ・サービスは、トランスポート層１１６にプロトコル・データ・ユニット（ＰＤＵ）を送る。典型的に、結合または接続が開放されているときに、メッセージ・サービスは、ＰＤＵをアッパ・サービス・レベル層１１８を通じてトランスポート層１１６に送ることができる。
【０１０４】
４２２に続く４２４においてトランスポート層１１６は、プロトコル・データ・ユニットを受信アプリケーションに伝送する。一般に、トランスポート層１１６は、プロトコル・データ・ユニット（ＰＤＵ）をＴＣＰ／ＩＰ層１２６経由で伝送し、それからＤＩＣＯＭネットワーク１０２を通じてアプリケーション・プログラム１３０に伝送する。
【０１０５】
４２４に続く決定ブロック４２６において、データ要素の発信元１０６により、メッセージ・サービスは、全てのデータ要素が１つのバイト・ストリームに変換済みであるかどうかを決定する。全てのデータ要素が変換済みであれば、「ＹＥＳ」分岐に４２８が続く。
【０１０６】
４２８において方法４００が終了する。
【０１０７】
残りのデータ要素の全てが変換済みでなければ、決定ブロック４２６に戻って、「ＮＯ」分岐に４２０が続く。統率データ・セット入力ストリーム（ＧＤＳＩＳ）の処理を完了する必要があるので、方法４００は、４２０に戻る。
【０１０８】
図５は、本発明の第３の例示的な方法を図示する。図５は、ファイルからデータを読み取る方法５００を説明する。一般に、このデータは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、このファイルは、関連アプリケーション・プログラム１０１またはＤＩＣＯＭプロトコルを使用して通信できる医療画像プログラムなどのアプリケーション・プログラム１３０である。このファイルは、ＤＩＣＯＭネットワーク１０２などの通信ネットワークと共に動作する前記のサーバ１２８ａ−ｎまたは媒体記憶モジュール１３２またはメタ・データベース・モジュール１３４など前記の記憶装置またはシステム上にあらかじめ記憶される。図５において方法５００は、５０２で開始する。
【０１０９】
５０２に続く５０４において通信エンジン１０４は、画像ファイルについてファイル入力ストリームを生成する。ファイル入力ストリームは、バイトの入力ストリームである。典型的に、ユーザがファイルから画像データまたはオブジェクトを読み取ることを決定すると、ユーザは、オブジェクトまたは画像ファイルを読み取るアプリケーション・コマンドを選択する。たとえば、結合アプリケーション・プログラム１０１は、ユーザがＤＩＣＯＭオブジェクトまたは画像ファイルを含むファイルを読み取るためにコマンドを選択できるようにする。特定のコマンドが選択されると、関連アプリケーション・プログラム１０１は、ＤＩＣＯＭオブジェクトまたは画像ファイルを含むシステム内に読み取られるＤＩＣＯＭオブジェクトまたは画像ファイルについてのファイル入力ストリームを生成する。このファイル入力ストリームは、ファイル内のバイトまたはデータ要素の一部分にわたる順方向イテレータである。ファイル入力ストリームは、最初から終わりまで単一方向に読み取られる。以前に定義したように、システムは、サーバ１２８ａ−ｎ、媒体記憶モジュール１３２またはメタ・データベース・モジュール１３４である。
【０１１０】
５０４に続く５０６において通信エンジン１０４は、画像ファイルを読み取るために入力転送構文（ＩＴＳ）を生成する。一般に、通信エンジン１０４は、あらかじめ生成されたファイル入力ストリームを使用して、入力転送構文（ＩＴＳ）を生成する。それから、この入力転送構文を使用して対応するオブジェクトまたは画像ファイルからデータ要素を読み取ることができる。
【０１１１】
５０６に続く５０８においてデータ要素の発信元１０６は、ファイル入力ストリームから各データ要素を段階的に読み取る。各データ要素１０６は、入力転送構文（ＩＴＳ）を使用して、ファイル入力ストリームから一回に１つのデータ要素またはデータ要素の１つのブロックを段階的に読み取る。少なくとも２つの異なったデータ要素が処理されるが、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合、ＳＱ要素は、データ要素のセットを含む。入力転送構文（ＩＴＳ）によりＳＱ要素が読み取られると、ＩＴＳは、データ要素の１つの特定セットから一回に１つずつデータ再帰的に処理する。ＰＤ要素の場合、ＰＤ要素は、バイトまたはワードの大きなアレイを含む。入力転送構文（ＩＴＳ）によりＰＤ要素が読み取られると、ＩＴＳは、これらを片または小さな固定サイズのデータ要素として処理する。いずれの場合も、比較的小さな固定サイズのメモリのみを使用してデータ要素を処理する。
【０１１２】
５０８に続く５１０において通信エンジン１０４は、入力転送構文（ＩＴＳ）を閉じる。つまり、データ要素の発信元により全てのデータ要素が読み込まれてしまった後で、入力転送構文を閉鎖する通信エンジンが閉じて、データ要素の発信元１０６によりデータ要素の更なる処理は、何も行われない。
【０１１３】
５１０に続く５１２において方法５００が終了する。
【０１１４】
図６は、本発明の第４実施例を示す。図６は、ファイルにデータを書き込む方法６００を示す。一般に、データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ファイルは、ＤＩＣＯＭプロトコルを使用して通信できる医療画像プログラムなどのアプリケーションに結合できる。ファイルは、ＤＩＣＯＭ通信ネットワークなどのネットワークと共に動作するサーバなどのシステムまたは記憶装置上にあらかじめ記憶される。図６において方法６００は、６０２で開始する。
【０１１５】
６０２に続く６０４において通信エンジン１０４は、ファイル出力ストリームを生成する。ファイル出力ストリームは、バイト出力ストリームである。典型的に、ユーザがファイルに画像データを書き込むことを決定すると、ユーザは、関連アプリケーション・プログラム１０１またはアプリケーション・プログラム１３０からコマンドを選択して、オブジェクトまたは画像ファイルにデータを書き込む。たとえば、関連アソシエーション・プログラム１０１は、ユーザがコマンドを選択して、ＤＩＣＯＭオブジェクトまたは画像の記憶用に構成されたファイルに画像データを書き込めるようにする。ある特定のコマンドが選択されると、アプリケーション・プログラム１３０は、ＤＩＣＯＭオブジェクトまたは画像ファイルを含むシステムに書き込まれる画像データのためのファイル出力ストリームを生成する。このシステムは、前に定義したように、サーバ１２８ａ−ｎ、媒体記憶モジュール１３２またメタ・データベース・モジュール１３４である。
【０１１６】
６０４に続く６０６においてアプリケーション・プログラム１３０は、出力転送構文（ＯＴＳ）を生成して、オブジェクトまたは画像ファイルへ画像データを書き込む。一般に、関連アプリケーション・プログラム１０１またはアプリケーション・プログラム１３０は、事前に生成されたファイル出力ストリームを使用して出力転送構文（ＯＴＳ）を生成する。出力転送構文（ＯＴＳ）が生成されるとき、ファイル出力ストリームは、出力転送構文を生成するのに使用される１つのアーギュメントである。それから、ＯＴＳは、対応するオブジェクトまたは画像ファイルに画像データを書き込むために使用される。
【０１１７】
６０６に続く６０８においてデータ要素の受信側１０８は、各データ要素をファイル出力ストリームに段階的に書き込む。つまり、データ要素の受信側１０８が出力転送構文（ＯＴＳ）を使用して、一回に１つずつデータ要素またはデータ要素のブロックをファイル出力ストリームに段階的に書き込む。図５に上述したように、少なくとも２つのタイプのデータ要素が処理され、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合は、ＳＱ要素は、データ要素を含む。出力転送構文（ＯＴＳ）によりＳＱ要素が書き込まれると、ＯＴＳは、データ要素の一特定セットから一回に１つずつデータ要素を再帰的に処理する。ＰＤ要素の場合は、ＰＤ要素は、バイトまたはワードの大きなアレイを含む。出力転送構文（ＯＴＳ）によりＰＤ要素が書き込まれると、ＯＴＳは、これらをデータ要素の片または小さな固定サイズとして処理する。いずれの場合も、比較的小さな固定サイズのメモリが出力転送構文（ＯＴＳ）により使用されてデータ要素を処理する。
【０１１８】
６０８に続く６１０において通信エンジン１０４は、出力転送構文（ＯＴＳ）を閉じる。つまり、データ要素の受信側１０８により全てのデータ要素をファイル出力構文に書き込んだ後で出力転送構文は、通信エンジン１０４を閉じて、こうしてオブジェクトまたは画像ファイルを含むファイルを効果的に閉じる。
【０１１９】
６１０に続く６１２において方法６００が終了する。
【０１２０】
図７は、ＤＩＣＯＭ画像ファイル内に含まれるデータの代表的な図を示す。この特定の例は、磁気共鳴映像（ＭＲＩ）ＤＩＣＯＭ画像ファイル７００である。この例において、最初の７９４バイトは、ＤＩＣＯＭフォーマット・ヘッダ７０２のために使用される。フォーマット・ヘッダ７０２は、画像寸法を記述し、走査に関する他のテキスト情報を保持する。ヘッダ７０２のサイズは、どれだけ多くの情報が記憶されるかにより変わる。この例は、１０９ｘ９１ｘ２ピクセルの画像寸法であり、ピクセルあたり１バイトの解像度を有し、こうして全画像サイズが約１９，８３８バイトであることを示す。
【０１２１】
画像データ７０４ｈは、ヘッダ７０２に続くファイル部分に記憶される。画像データも、ヘッダ７０２と関連情報として同一ファイル内に記憶される。
【０１２２】
図８は、ＤＩＣＯＭ画像ファイル内に含まれるデータを示す。この例において、ＤＩＣＯＭヘッダ・フォーマットは、１２８バイトのプリアンブルを必要とする。典型的に、ＤＩＣＯＭヘッダ・フォーマットにおいて１２８バイトのプリアンブルは、通常、ゼロに設定される。この１２８バイトのプリアンブルには、それから「Ｄ」、「Ｉ」、「Ｃ」、「Ｍ」の文字が続く。それからヘッダ情報が最後の文字「Ｍ」に続く。ヘッダ情報は「グループ」と呼ばれる１つまたはそれ以上の部分で組織される。たとえば、グループ「０００２ｈｅｘ」は、ファイル・メタ情報グループを指定できる。このグループは、グループ長さ、ファイル・バージョン、転送構文のような３つの要素を定義できる。各グループ内で定義されるＤＩＣＯＭデータ要素は、画像タイプにより異なる。定義されるデータ要素の代表的な例は、２０００ＤＩＣＯＭ規格のパート３にリストされている。たとえば、磁気共鳴（ＭＲ）画像ファイルは、要素０００８，００６０により指定できる。このタイプの画像ファイルは、ＭＲＩエコー・タイムを記述するために１つまたはそれ以上の画像ファイルを含む。
【０１２３】
本発明の精神と範囲から離れることなく本発明に付随する代替実施例は、当業者に明らかにある。したがって、本発明の範囲は、前記の記載よりも、むしろ特許請求の範囲により定義される。
【図面の簡単な説明】
【０１２４】
【図１】本発明の例示的な実施例によるシステムの機能的なブロック図である。
【図２】本発明の例示的な実施例のデータ・フロー図を示す。
【図３ａ】本発明の１つの例示的な方法を図示する。
【図３ｂ】本発明の１つの例示的な方法を図示する。
【図３ｃ】本発明の１つの例示的な方法を図示する。
【図４ａ】本発明の第２の例示的な方法を図示する。
【図４ｂ】本発明の第２の例示的な方法を図示する。
【図５】本発明の第３の例示的な方法を図示する。
【図６】本発明の第４の例示的な方法を図示する。
【図７】ＤＩＣＯＭ画像ファイル内に含まれるデータの代表的な例を示す。
【図８】ＤＩＣＯＭ画像ファイル内に含まれるデータを示す。
【技術分野】
【０００１】
（発明の分野）
本発明は、一般に画像伝送に関し、特に、データ要素の発信元と受信側を通じてＤＩＣＯＭ画像をストリーミングする方法と装置に関する。
【背景技術】
【０００２】
医療画像は、医療ディジタル画像通信（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（ＤＩＣＯＭ）と呼ばれるネットワーク・プロトコル規格を使用して、コンピュータ間で通信できる。このＤＩＣＯＭネットワーク・プロトコルは、心電図波形、コンピュータ断層撮影（ＣＴ）、磁気共鳴（ＭＲ）および超音波などの医療画像およびオブジェクトの配信と表示を支援するために作成された。
【０００３】
ＤＩＣＯＭネットワーク・プロトコルは、デジタル画像データとオブジェクトを記憶し、受信し、伝送するのに使用されるフォーマットを定義する。ＤＩＣＯＭオブジェクト・フォーマットは、典型的にヘッダと画像データを含む。ヘッダは、患者の名前、医療手順または断層撮影のタイプ、画像次元などに関する情報を含む。たとえば、あるＤＩＣＯＭ画像ファイルは、ある医療画像の物理的次元を記述するデータを内容とするヘッダを含む。ヘッダは、この画像内に含まれる断層撮影についてのテキスト情報を内容とするデータを含む。ヘッダのサイズは、画像に記憶される情報量により異なる。ヘッダ内のデータは、１つまたはそれ以上のグループに組織できる。１つのグループは、グループ長さ、ファイル・バージョン、転送構文のような１つまたはそれ以上のデータ要素を定義するメタ・ファイル情報である。データ要素の数は、画像タイプとこの特定画像タイプの特性により異なる。
【０００４】
オブジェクト・データは、典型的にヘッダ・データに続く。オブジェクト・データは、特定のオブジェクト・タイプの特性を定義するデータ要素および特定のオブジェクト・タイプに関連するオブジェクト・データを有する。オブジェクト・データは、２つおよび／または３つの次元で遂行される医療走査で得られる情報を含むことができる。たとえば、磁気共鳴画像（ＭＲＩ）データは、そのＭＲＩエコー時間を詳細に定義するデータ要素を含むＤＩＣＯＭ画像データを有する。その上、画像ファイル・サイズを小さくするために画像データを圧縮したりカプセル化したりする。
【０００５】
ほとんどのＤＩＣＯＭデータ要素は、小さくて、それらが収納できるデータのタイプによりサイズが限定される。たとえば、整数データ要素は、少しの整数を含む。これらのデータ要素は、いつも比較的小さく、それらの比較的小さなサイズのゆえに、ネットワークの効率と拡張性に重要または大きな影響を与えることはない。画像データなど他のタイプのＤＩＣＯＭデータ要素は、比較的大きいことがある。２つのタイプのＤＩＣＯＭデータ要素は、大きいことがあるので、特別な注意に値するが、それは、シーケンスとピクセル・データである。ＤＩＣＯＭにおけるシーケンスは、他のデータ・セットを再帰的に収納できるデータ要素のタイプである。それらは他のデータ・セットを収納できるので、小さなデータ要素を非常に多数収納する場合またはピクセル・データを収納する場合は、それらが相対的に大きくなる。ピクセル・データは、実際の画像データに対応するタイプのデータ要素である。ピクセル・データは、相対的に大きくなるタイプのデータ要素であって、ある場合には極端に大きくなる。非常に大きなデータ・セットが通信される場合、そのデータ・セット内のほとんど全てのバイトがピクセル・データである。他のほとんどのタイプのデータ要素は、患者名、画像のタイプ、画像の日付と時間などの画像についての情報（メタ・データ）を通信する。
【０００６】
ＤＩＣＯＭは、データ・セットを伝送することにより通信する。データ・セットは、シーケンス・データ、ピクセル・データまたは他のタイプのデータなどのデータ要素の順序付き集合である。各データ要素は、通信される情報を表現する。各データ要素は、特定のタイプを有し、データ要素タイプによりサイズが異なる。たとえば、ある画像ファイルのサイズにおいて、異なった範囲を例示すれば、ＤＩＣＯＭ画像のファイル・サイズは、単一ＤＩＣＯＭ画像について約１２８キロバイトからあるし、または時間シーケンス、すなわちマルチ・フレームＤＩＣＯＭ画像について約６００メガバイトまでの範囲にわたる。
【０００７】
ＤＩＣＯＭデータ・セットは、１つまたはそれ以上の転送構文を使用して通信できる。転送構文は、特定のデータ・セットについてのデータのエンコーディングのタイプを決定する。ＤＩＣＯＭネットワーク・プロトコルは、少なくとも３つのタイプの転送構文をサポートできる。すなわち、小エンディアン（ｅｎｄｉａｎ）明示値表現、小エンディアン暗示値表現および大エンディアン明示値表現である。
【０００８】
ＤＩＣＯＭネットワーク・プロトコルの独自な機能により移送時にデータを異なった形式に変換することができる。通常のＤＩＣＯＭネットワーク上でＤＩＣＯＭ画像を伝送中のＤＩＣＯＭデータ変換の独自な機能は、ＤＩＣＯＭネットワーク内にメモリ資源への相対的に大きな要求を作り出す。
【０００９】
ＤＩＣＯＭネットワーク・プロトコルは、多重の層から構成される。ＤＩＣＯＭネットワーク・プロトコルは、標準的なＴＣＰ／ＩＰプロトコルの上に構築できる。通信ネットワーク上でデータを伝送する時に、ＤＩＣＯＭプロトコルはネットワーク上でデータを送信する以前にデータ・セットを１つまたはそれ以上のデータ・パケットに分解する。各データ・パケットは、１つまたはそれ以上のプロトコル・データ・ユニット（ＰＤＵ）を定義する。ＴＣＰ／ＩＰプロトコルにおけるような下にあるプロトコル層がデータをデータ・パケットに変換すれば、ＤＩＣＯＭプロトコルは、ネットワーク上で通信されているデータ・セットもプロトコル・データ・ユニット（ＰＤＵ）としてパッケージされることを要求する。たとえば、ＴＣＰ／ＩＰプロトコルの上にＤＩＣＯＭネットワーク・プロトコルが走る時に、これは実効的にデータを二重パケット化する。つまり、ＤＩＣＯＭは、データ・セットをプロトコル・データ・ユニット（ＰＤＵ）としてパッケージし、またＴＣＰ／ＩＰは、データ・セットをデータ・パケットとしてパッケージする。このタイプのＤＩＣＯＭ／ＴＣＰ／ＩＰ層化したプロトコル構造は、通常のＤＩＣＯＭネットワークにおいて、メモリ資源に対して相対的に大きな要求を作り出す。その上、ＤＩＣＯＭネットワーク・プロトコルの多重層を通じてＤＩＣＯＭ画像を伝送することも、通常のＤＩＣＯＭネットワーク内でメモリ資源に対して相対的に大きな要求を作り出す。
【００１０】
ＤＩＣＯＭプロトコルは、通信を設立し維持するのに厳密な順序に従う。ＤＩＣＯＭプロトコルのアッパ・サービス・レベル層により作動される状態機械は、ＤＩＣＯＭネットワーク内の２つの装置の間で通信を設立し維持するための厳密な順序を規定する。たとえば、ＤＩＣＯＭプロトコルは、接続方向性なので、ＤＩＣＯＭ結合または接続が２つの装置の間で設立済みになるまで、ＤＩＣＯＭデータの通信は、何も起こらない。つまり、ＤＩＣＯＭ結合または接続を設立するためには、少なくとも２つのＤＩＣＯＭプロトコルに基づく装置が互いに通信していなければならない。ＤＩＣＯＭ結合または接続が設立済みになった後に、通信は、厳密な手順に従い続けなければならず、それからＤＩＣＯＭ結合または接続は、順序に従った仕方で終結しなければならない。ＤＩＣＯＭネットワーク・プロトコルにより指示される厳密な順序は、通常のＤＩＣＯＭネットワーク内に相対的に大きなメモリ資源の要求を作出する。
【００１１】
各ＤＩＣＯＭ結合または接続は、ＤＩＣＯＭネットワーク内でＤＩＣＯＭデータ・オペレーションを遂行するために使用される。ＤＩＣＯＭオペレーションは、逐次的に、すなわち１つずつ、または並行的に遂行できる。並行的オペレーションは、ＤＩＣＯＭ内の結合ごとの非同期オペレーションと呼ばれる。通常のＤＩＣＯＭネットワークは、典型的にＤＩＣＯＭデータを含む多重の並行的または非同期オペレーションを処理し、大きなＤＩＣＯＭファイル・サイズは、通常のＤＩＣＯＭネットワーク内にメモリ資源に対する相対的に大きな要求を作出する。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
通常のＤＩＣＯＭ通信ネットワークによる相対的に大きなオブジェクトの急速な処理は、ＤＩＣＯＭプロトコル・オペレーションが効率的で高性能な仕方で遂行されることを要求する。相対的に大きなＤＩＣＯＭオブジェクト・ファイルを処理する時に、通常のＤＩＣＯＭ通信ネットワークは、スピードと性能が著しく低下する。ＤＩＣＯＭオブジェクトは、相対的に大きくなる傾向があるので、ＤＩＣＯＭオブジェクトの通信がこの大きな画像オブジェクトを収容するように設計されていない通信ネットワークを急速に圧倒する。多重で同時的なＤＩＣＯＭオペレーションを処理するために、通常のＤＩＣＯＭ通信ネットワークは、サーバに依存している。単一のＤＩＣＯＭファイルまたは記憶装置のオペレーションがメモリおよび処理時間などのサーバの資源の大部分を消費する場合は、ＤＩＣＯＭサーバは、この大きなオブジェクトを処理する時に貧弱な拡張性と性能に苦しむ。これらのネットワークとサーバの性能の問題は、多重のクライアントが同時的または並行的にネットワークを使用することを試みる時に著しく悪化する。
【００１３】
したがって、ネットワーク内でＤＩＣＯＭオブジェクトの処理中にメモリ資源の消費を限定する方法と装置の要求が存在する。
【００１４】
ネットワーク内で通信されるＤＩＣＯＭオブジェクトのサイズに関係なくメモリの使用を限定するために、ＤＩＣＯＭ通信ネットワーク内で１つまたはそれ以上のアプリケーションを可能にする方法と装置の要求がさらに存在する。
【００１５】
通信ネットワーク内の２つの装置の間でデジタル・データを伝送する改良された方法と装置のさらなる要求が存在する。
【００１６】
通信ネットワーク内で作動する１つまたはそれ以上のアプリケーションを維持または改良すると共に、ネットワーク内でＤＩＣＯＭオブジェクトを伝送する改良された方法と装置の更なる要求が存在する。
【００１７】
データ要素の発信元とデータ要素の受信側を通じてネットワーク内でＤＩＣＯＭオブジェクトをストリーミングする方法と装置の更なる要求が存在する。
【課題を解決するための手段】
【００１８】
本発明は、データ要素の発信元とデータ要素の受信側を通じてネットワーク内のＤＩＣＯＭオブジェクトをストリーミングする方法と装置を供給することにより、上記の諸問題を解決する。本発明による方法と装置は、ネットワーク内のＤＩＣＯＭオブジェクトの処理中にメモリ資源の消費を限定する。更に本発明による方法と装置は、ＤＩＣＯＭ通信ネットワーク内の１つまたはそれ以上のアプリケーションがネットワーク内に通信されるＤＩＣＯＭオブジェクトのサイズに係りなくメモリの使用を限定できるようにする。その上、本発明による方法と装置は、通信ネットワーク内の２つの装置の間でデジタル・データを伝送できるようにする。最後に本発明による方法と装置は、ネットワーク内で作動する１つまたはそれ以上のアプリケーションの性能を維持または改良すると共に、ネットワーク内でＤＩＣＯＭオブジェクトを伝送することを可能にする。
【００１９】
本発明による方法と装置は、一定量のメモリを使用して通信ネットワーク内の２つの装置の間のデジタル・データの伝送することを可能にする。たとえば、本発明による方法と装置は、限定された固定サイズのメモリのみを使用して、ＤＩＣＯＭネットワーク内の２つの装置の間で比較的大きなファイル・サイズのＤＩＣＯＭオブジェクトをストリーミングできるようにする。ＤＩＣＯＭオブジェクトまたは他のデジタル・データまたは比較的大きなファイル・サイズのオブジェクトを処理するために、本発明による方法と装置は、このオブジェクトをデータ要素の小さな固定された部分に配分する。それから本発明による方法と装置は、単一オペレーションのために一回にメモリに記憶できるデータ要素の数を限定する。それから、各データ要素がデータ要素の発信元またはデータ要素の受信側により段階的に処理され、単一のオペレーションについて多すぎるメモリの使用を回避する。こうして、本発明による方法と装置は、通信されるＤＩＣＯＭオブジェクトまたは画像のサイズに係りなく、小さな固定量のメモリのみを使用してＤＩＣＯＭオブジェクトまたは画像をストリーミングすることをＤＩＣＯＭ通信ネットワークに可能とする。
【００２０】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信する第１の例示的な方法において、この方法は、データ・ストリーム内に記憶される限定された数のデータ値を最初に定義する。次に、この方法は、第１の装置から一組のデータ素子を段階的に読み取ることにより、各データ要素が一回に１つずつ読み取られるようにする。次に、各データ要素からデータ値が抽出される。あるデータ要素が閾値サイズよりも大きければ、このデータは、比較的小さな固定サイズ・データの部分で伝送できる。最後に、この方法は、所定の限定された数のデータ値を含むデータ・ストリームを第２の装置へ伝送することにより、データ値が第２の装置にエンコードされるようにする。
【００２１】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信するもう１つの例示的な方法において、本発明は、第１の装置からデジタル・データを含むファイルを受信する。次に、この方法は、デジタル・データを含むファイルについてのデータ値を含むデータ・ストリームを生成する。このデータ・ストリームに基づいて、本発明は、データ要素の発信元を生成する。それから本発明は、データ要素の発信元を通じて、このデータ・ストリームから一回に１つずつデータ要素を段階的に処理する。最後に、これらのデータ要素は、データ要素の受信側に伝送されて、データ要素の受信側の第２の装置にデータ要素をエンコードする。
【００２２】
本発明の装置の実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の発信元と通信エンジンを含む。データ要素の発信元は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の発信元も、一組のデータ要素から一回に１つずつデータ要素を段階的に処理するように構成される。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータをデータ受信側に渡すことにより、抽出されたデータからデータ・ストリームを生成するように構成され、データ要素の受信側は、抽出されたデータ値を第２の装置へエンコードする。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２３】
本発明の装置のもう１つの実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の受信側と通信エンジンを含む。データ要素の受信側は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の受信側も、一組のデータ要素から一回に１つずつデータ要素を段階的に書き込むように構成される。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータ値からデータ・ストリームを生成するように形成される。その上、通信エンジンは、さらに、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２４】
このように本発明の方法と装置は、上記のように、あらゆるサイズの比較的大きなＤＩＣＯＭオブジェクトに含まれるデジタル・データをネットワーク内の２つのアプリケーション、装置または記憶媒体の間で伝送することができる。データ要素の発信元とデータ要素の受信側を使用して、一回に１つずつデータ要素とデータ値を段階的に処理することは、ＤＩＣＯＭオペレーションを実行するのに必要なメモリ量を最小化する。本発明による方法と装置は、比較的大きなＤＩＣＯＭオブジェクトを処理するために比較的小さな一定量のメモリを供給すると共に、メモリ資源の消費を制限し、一方ではＤＩＣＯＭネットワーク内で作動するアプリケーションの性能を維持する。
【実施例】
【００２５】
さて、図面を参照しながら本発明の特定の実施例を一層詳細に説明する。
【００２６】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを通信する第１の例示的な方法において、この方法は、最初に、データ・ストリーム内に記憶されるデータ値の限定された数を定義する。次に、この方法は、第１の装置から一組のデータ要素を段階的に読み取って、一回に１つずつデータ要素が読み取られるようにする。次に、各データ要素からデータ値が抽出される。あるデータ要素が閾値サイズよりも大きければ、このデータは、比較的小さな固定サイズのデータの複数の部分で伝送できる。最後に、この方法は、所定の限定された数のデータ値を含むデータ・ストリームを第２の装置に伝送して、これにより、これらデータ値は、第２の装置にエンコードされるようにする。
【００２７】
一定量のメモリの使用して第１の装置から第２の装置へデジタル・データを通信するもう１つの例示的な方法において、本発明は、第１の装置からのデジタル・データを含むファイルを受信する。次に、この方法は、デジタル・データを含むファイルについてデータ値を含むデータ・ストリームを生成する。このデータ・ストリームに基づいて、本発明は、データ要素の発信元を生成する。それから、この方法は、データ要素の発信元を通じて、データ・ストリームから一回に１つずつデータ要素を段階的に処理する。最後に、これらのデータ要素は、データ要素の受信側に伝送されて、データ要素の受信側は、これらデータ要素を第２の装置にエンコードする。
【００２８】
本発明の装置の例示的な実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の発信元と通信エンジンを含む。データ要素の発信元は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の発信元もまた一組のデータ要素から一回に１つずつデータ要素を段階的に処理するように構成されている。通信エンジンは、データ要素からデータ値を抽出して、抽出されたデータ値をデータ要素の受信側に渡すことにより、抽出されたデータ値からデータ・ストリームを生成するように構成され、データ要素の受信側は、抽出されたデータ値を第２の装置にエンコードする。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００２９】
本発明の装置のもう１つの実施例は、一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする通信モジュールを含む。この通信モジュールは、データ要素の受信側と通信エンジンを含む。データ要素の受信側は、第１の装置から一組のデータ要素を受信するように構成される。データ要素の受信側は、また一組のデータ要素から一回に１つずつデータ要素を段階的に書き込むように構成される。通信エンジンは、データ要素からデータ値を抽出して、これら抽出された１つのデータ値からデータ・ストリームを生成するように構成される。その上、通信エンジンは、更に、抽出されたデータ値を含むデータ・ストリームを第２の装置に伝送するように構成される。
【００３０】
図１は、本発明の実施例によるシステムの機能的なブロック図を示す。このシステムは、通信モジュール１００を含む。通信モジュール１００は、関連アプリケーション・プログラム１０１とネットワークを介する他のアプリケーション・プログラムの間で伝送またはオブジェクトのストリーミングをするように構成される。その上、通信モジュール１００は、関連アプリケーション・プログラム１０１とネットワークを介する他のアプリケーション・プログラムの間で、ＤＩＣＯＭ画像ファイルまたは他の類似タイプのデジタル画像を含むＤＩＣＯＭオブジェクトの伝送またはストリーミングのために構成される。たとえば、通信モジュール１００は、関連アプリケーション・プログラム１０１とＤＩＣＯＭネットワーク１０２のような通信ネットワークを介するアプリケーション・プログラム１３０の間で通信して、ＤＩＣＯＭ画像ファイルまたは他の類似タイプのデジタル・オブジェクトを含むＤＩＣＯＭオブジェクトを送信または受信できる。
【００３１】
注意すべきは、通信モジュール１００は、一般にサービス・クラス・プロバイダ（ＳＣＰ）と、サービス・クラス・ユーザ（ＳＣＵ）の間で通信することである。ＳＣＰは、ＤＩＣＯＭネットワーク・プロトコルで定義されたサービスへの要求を受信し、一方、ＳＣＵは、ＤＩＣＯＭネットワーク・プロトコルで定義されたサービスへの要求を開始する。たとえば、関連アプリケーション・プログラム１０１は、ＳＣＵであることができ、またアプリケーション・プログラム１３０を実行するサーバ１２８ａ／ｎは、ＳＣＰであることができる。
【００３２】
関連アプリケーション・プログラム１０１は、医療画像プログラムまたはアプリケーション・プログラムのようなＤＩＣＯＭアプリケーション・プログラムであり、これらはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用する通信モジュール１００により通信できる。関連アプリケーション・プログラム１０１は、１つまたはそれ以上のクライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワーク・ステーション、獲得モジュール、理学療法装置、表示システム、ＤＩＣＯＭ媒体、デジタル・アーカイブまたはＤＩＣＯＭ通信プロトコルかＤＩＣＯＭ規格を使用して作動できる他のタイプの装置上で実行できる。ＤＩＣＯＭ画像ファイルおよびＤＩＣＯＭ画像ファイル内に収容される関連情報の代表的な例を図７と図８に示す。
【００３３】
通信モジュール１００は、通信エンジン１０４、データ要素発信元１０６、データ要素の受信側１０８、状態機械１１０、バッファ１１２およびＤＩＣＯＭプロトコル１１４のような多層プロトコルを含む。通信エンジン１０４は、関連アプリケーション・プログラム１０１と通信モジュール１００の間および通信モジュール１００とＤＩＣＯＭネットワーク１０２の間で、データおよび関連データ要素を処理するように構成される。通信エンジン１０４は、また通信モジュール１００の種々の構成要素の間およびＤＩＣＯＭプロトコル１１４の多重の層の間でデータを伝送するように構成される。他の実施例による通信モジュールは、類似の機能を提供する、より少ない、または、より多くの要素を有する。
【００３４】
データ要素の発信元１０６は、データ要素のための概念的なソースである。データ要素の発信元は、データ要素の概念的なセット上で順方向の繰返し器として機能できる。データ要素の発信元１０６は、一回に１つずつまたはブロックで、データ要素をサービス・クラス・ユーザー（ＳＣＵ）またはクライアントまたはサーバ１２８ａ−ｎのようなサービス・クラス・プロバイダ（ＳＣＰ）に供給する。たとえば、データ要素の発信元１０６は、シーケンス・データ（ＳＱ）要素を処理できる。
【００３５】
データ要素の発信元１０６は、また１つのピクセル・データ・デコーダを含む。ピクセル・データ・レコーダは、ピクセル・データを一回に１つずつ段階的に処理する。たとえば、ピクセル・データ・レコーダは、ピクセル・データ（ＰＤ）要素を処理する。単一のピクセル・データ要素は、数メガバイトのデータを含むので、ピクセル・データ・レコーダは、比較的小さな固定サイズのチャンクのデータを読み取ることを可能にする。ピクセル・データ要素に遭遇すると、ピクセル・データ・レコーダは、一回に全部のデータ要素を読まず、代わりに１１２と図示したバッファのような固定サイズのバッファにピクセル・データが段階的に読み込まれる。
【００３６】
データ要素の発信元１０６は、ストリーミング・データ要素を含む。同様に、ストリーミング・データ要素を段階的に処理できる。
【００３７】
データ要素の受信側１０８は、データ要素のための概念的な記憶装置である。データ要素の受信側１０８は、一回に１つずつまたはブロックでデータ要素をクライアントまたはサーバ１２８ａ−ｎのようなサービス・クラス・ユーザ（ＳＣＵ）に書き込むことができる。たとえば、データ要素の受信側１０８は、シーケンス・データ（ＳＱ）要素を処理できる。
【００３８】
データ要素の受信側１０８は、またピクセル・データ・エンコーダを含む。ピクセル・データ・エンコーダは、ピクセル・データを一回に１つずつ段階的に処理する。たとえば、ピクセル・データ・エンコーダは、ピクセル・データ（ＰＤ）要素を処理する。単一のピクセル・データ要素は、数メガバイトのデータを含むので、ピクセル・データ・エンコーダは、比較的小さな固定サイズのチャンクのデータでピクセル・データを書き込むことを可能にする。ピクセル・データ要素に遭遇すると、ピクセル・データ・エンコーダは、一度に全てのデータ要素を書き込まず、代わりに１１２として示されるバッファのような固定サイズ・バッファに段階的にピクセル・データを書き込む。
【００３９】
データ要素の受信側１０８は、ストリーミング・データ要素を含む。同様に、ストリーミング・データ要素を段階的に処理できる。
【００４０】
状態機械１１０は、サービス・クラス・プロバイダ（ＳＣＰ）とサービス・クラス・ユーザ（ＳＣＵ）の間の結合または接続の開始、監視および処理をする。
【００４１】
バッファ１１２は、データ要素、データ値または他のタイプのデータを記憶するように構成されたメモリ記憶装置である。バッファ１１２は、またデータ要素、データ値または他のタイプのデータを記憶する、より小さなバッファまたは類似のタイプのメモリ装置を含む。
【００４２】
ＤＩＣＯＭプロトコル１１４は、トランスポート層１１６、アッパ・レベル・サービス層１１８、データ・サービス層１２０およびサービス・クラス層１２を含む多重層を収容する。ＤＩＣＯＭプロトコルおよび関連層１１６−１２２の仕様、機能性および一層詳細な説明は、医療デジタル画像および通信（ＤＩＣＯＭ）規格書、ＰＳ３．１−２０００、米国電気製造業協会、２０００年に掲示されているが、これは参考文献として本明細書に組み込まれている。
【００４３】
通信モジュール１００は、関連アプリケーション・プログラム１０１と連絡する。通信モジュール１００は、またＤＩＣＯＭネットワーク１０２などの通信ネットワークを通じて、もう１つのアプリケーション・プログラム１３０と連絡する。典型的に、もう１つのアプリケーション・プログラム１３０は、物理層１２４、すなわちＥＴＨＥＲＮＥＴ（登録商標）、ＡＴＭ、ＦＤＤＩのようなインターフェイスを通じて通信モジュール１００とＤＩＣＯＭネットワーク経由で連絡する。さらにＤＩＣＯＭネットワーク１０２が伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）１２６を使用して他のネットワーク、コンピュータ、フラットフォームおよびアプリケーションとの連絡を更に容易にすることは、当業者には理解される。こうして、通信モジュール１００は、トランスポート層１１２により、ＴＣＰ／ＩＰ１２６に隣接して配置され、これによりＤＩＣＯＭネットワーク１０２と通信モジュール１００の間にインターフェイスを生成する。当業者は、この構成を容易にするのに必要な方法とシステムを理解する。
【００４４】
ＤＩＣＯＭネットワーク１０２は、図示のようにネットワーク構成に接続される１つまたはそれ以上のサーバ１２８ａ−ｎを含む。いくつかの場合、ローカル・エリア・ネットワーク、すなわちＬＡＮ構成内で作動するためにＤＩＣＯＭネットワーク１０２が設立される。
【００４５】
サーバ１２８ａ−ｎには、クライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワークステーション、獲得モジュール、理学療法装置、表示システム、ＤＩＣＯＭ媒体、デジタル・アーカイブまたはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用して動作可能な他のタイプの装置が含まれる。ＤＩＣＯＭネットワーク１０２においては、サーバ１２８ａ−ｎは、サービス・クラス・プロバイダ（ＳＣＰ）またはサービス・クラス・ユーザ（ＳＣＵ）である。
【００４６】
当業者は、ＤＩＣＯＭネットワーク１０２に類似して作動する通信ネットワークの他の構成をよく知っている。
【００４７】
アプリケーション・プログラム１３０は、サーバ１２８ａ−ｎ上で実行するように構成される。一般にアプリケーション・プログラム１３０は、医療画像プログラムのようなＤＩＣＯＭアプリケーション・プログラムまたはＤＩＣＯＭ通信プロトコルまたはＤＩＣＯＭ規格を使用して通信モジュール１００と通信できるアプリケーション・プログラムである。アプリケーション・プログラム１３０は、クライアント、医療画像装置、記憶装置、情報システム、データベース、プリンタ、ワークステーション、獲得システム、理学療法装置、表示システムのような他のプラットフォーム上で実行可能であり、これらのプラットフォームは、ＤＩＣＯＭネットワーク１０２に接続される。
【００４８】
通信モジュール１００は、また媒体記憶モジュール１３２およびメタ・データベース・モジュール１３０と連絡する。媒体記憶モジュール１３２は、通信モジュール１００と連絡し、一時的または永久的なベースでデジタル画像データを記憶するように構成される。媒体記憶モジュール１３２は、ハード・ドライブ、光磁気ディスク・ドライブ、ＣＤ−ＲＷドライブ、ＣＤ−ＲＯＭドライブのような記憶媒体または他の類似のタイプの記憶媒体を含む。注意すべきは、アプリケーション・プログラム１３０は、また媒体記憶モジュール１３２から実行されるように構成できることである。
【００４９】
メタ・データベース・モジュール１３４は、また通信モジュール１００と連絡して、一時的または永久的ベースでデジタル画像データを記憶するように構成される。メタ・データベース・モジュール１３４は、デジタル・データを記憶する通常のデータベースのような記憶媒体を含む。
【００５０】
図２は、本発明の実施例の一般的なデータの流れの図である。この図は、ネットワークとアプリケーションの間でオブジェクトまたは画像ファイルを伝送中に、ＤＩＣＯＭプロトコルの多重層を通るデータ・フロー２００の実施例を示す。この例において、ネットワークは、ネットワーク・レベル２０２により表現され、アプリケーションは、アプリケーション・レベル２０４により表現される。図１と図２の両方における要素を参照すると、ネットワーク・レベル２０２は、サーバ１２８ａ−ｎを有するＤＩＣＯＭネットワーク１０２を含む。アプリケーション・レベル２０４は、通信モジュール１００に関連する医療画像プログラムのような関連アプリケーション・プログラム１０１を含む。代わりにアプリケーション・レベルは、他のサーバ１２８ａ−ｎ、すなわちＤＩＣＯＭネットワーク１０２内のクライアント・コンピュータなどのＤＩＣＯＭプロトコル可能な装置上で実行できる。通信モジュール１００は、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間の結合または接続を生成することにより、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間のデータ通信を容易にする。通信モジュール１００は、どのサービス・オブジェクト・ペア（ＳＯＰ）クラスが使用されるかを決定し、ＳＣＰおよびＳＣＵの役割を定義し、プロトコル層の間で通信するのに使用される転送構文のタイプを折衝し、ＤＩＣＯＭネットワーク・プロトコルまたはオブジェクトかデジタル画像を処理する類似のタイプのプロトコルにより他の通信パラメータを決定することなどの標準的なＤＩＣＯＭネットワーク・プロトコルの詳細を処理する。注意すべきは、代わりの構成において他の装置がＳＣＰ、ＳＣＵとして機能し得ることであり、またはＳＣＰＵおよびＳＣＵの両方として機能し得ることである。
【００５１】
その上、通信モジュール１００は、メモリ記憶装置、ハード・ドライブ、ＣＤ−Ｒ、ＣＤ−ＲＷなど２つの装置の間または２つの異なったメモリ記憶装置のあらゆる他の組合せの間でデジタル・データを伝送し、またはストリーミングするのに使用される。ネットワークから装置へまたは装置からネットワークなど他の構成の間でデジタル・データを通信するためにも通信モジュール１００が使用され、これらの装置は、メモリ記憶装置、ハード・ドライブ、ＣＤ−Ｒ、ＣＤ−ＲＷまたは他の類似のタイプの装置を含むことは、当業者に理解される。
【００５２】
その上、通信モジュール１００は、関連アプリケーション・プログラム１０１およびサーバ１２８ａ−ｎと折衝して、関連アプリケーション・プログラム１０１とサーバ１２８ａ−ｎの間で伝送されるプロトコル・データ・ユニット（ＰＤＵ）の最大サイズを定義する。ＰＤＵの最大サイズは、利用できるメモリのカレント・サイズおよび通信ネットワークの全体的な効率によって異なる。
【００５３】
その上、通信モジュール１００は、表示データ値の入力ストリームに読み込める所定または限定された数の表示データ値（ＰＤＶ）を定義するために折衝する。所定または限定された数の表示データ値（ＰＤＶ）は、利用できるメモリ記憶域のカレント・サイズおよび／または通信ネットワークの全体的な効率によって異なる。代わりに通信モジュール１００は、データ入力ストリームに読み込めるデータ要素の所定または限定されたサイズを定義することができる。データ要素の所定または限定された数は、利用可能なメモリ記憶域のカレント・サイズおよび／または通信ネットワークの全体的な効率により異なる。通信装置１００により処理されるデータ要素のタイプにより、これらの技法の１つまたはそれ以上が使用され、本発明により特定のデータ要素を伝送する間にメモリ資源の消費を比較的小さな固定された量に限定する。注意すべきは、表示データ値（ＰＤＶ）がヘッダとペイロードを含み、これらは、バイトの配列であることである。
【００５４】
通信モジュール１００により上述の結合または接続の詳細が完了した後に、通信モジュール１００は、ネットワーク・レベル２０２からアプリケーション・レベル２０４にデータ２０６を伝送することに進む。つまり、通信モジュール１００は、サーバ１２８ａ−ｎ（この例では、ＳＣＰとして作用している）から受信するデータ２０６を処理して、処理されたデータを関連アプリケーション・プログラム１０１（この例では、ＳＣＵとして作用する）に送る。典型的にデータ２０６は、１つまたはそれ以上のデータ要素を含むＤＩＣＯＭオブジェクトまたはＤＩＣＯＭ画像ファイルである。データ２０６は、最初にネットワーク・レベル２０２において、サーバ１２８ａ−ｎにより処理される。サーバ１２８ａ−ｎは、ＥＴＨＥＲＮＥＴ（登録商標）、ＡＴＭ、ＦＤＤＩのような標準的なネットワーク物理層２０８を通じてデータ２０６を伝送する。
【００５５】
次に、データ２０６は、ＴＣＰ／ＩＰ２１０を通じて１つまたはそれ以上のデータ・パケット２１２の形式で、標準的なネットワーク物理層から伝送される。ＴＣＰ／ＩＰ２１０は、ＤＩＣＯＭオブジェクトまたはＤＩＣＯＭ画像ファイルを含むデータ２０６を、１つまたはそれ以上のデータ・パケット２１２に変換する。この変換を実行するのに必要な方法とシステムは、当業者には理解される。
【００５６】
ＴＣＰ／ＩＰ２１０は、ソケット２１６を使用して、データ・パケット２１２をＤＩＣＯＭプロトコル層２１４に伝送する。ＤＩＣＯＭプロトコル層２１４は、トランスポート２１８、アッパ・レベル・サービス２２０、データ・サービス２２２、サービス・クラス２２４を含む多重の層を収容する。ソケット２１６は、ＴＣＰ／ＩＰ２１０とＤＩＣＯＭネットワーク・プロトコルなど、他のネットワーク・プロトコルの間の通信を容易にするアプリケーション・プログラム・インターフェイス（ＡＰＩ）である。ＴＣＰ／ＩＰ２１０、ＤＩＣＯＭプロトコル層２１４、ソケット２１６を実施するのに必要な方法とシステムは、当業者には理解される。
【００５７】
ＴＣＰ／ＩＰ２１０は、データ・パケット２１２をトランスポート層２１６として知られるＤＩＣＯＭプロトコル層２１４の第１の層に伝送する。通信モジュール１００は、トランス・ポート層２１６においてデータ・パケット２１２を受信して、ＴＣＰ／ＩＰ２１０からデータ・パケット２１２の各々を段階的に読み取る。つまり、通信モジュール１００に結合された通信エンジン（図１に１０４として示す）がトランスポート層２１６を使用して、一回に１つずつデータ・パケット２１２を読み取る。データ・パケット２１２が処理されると、通信エンジン１０４がデータ・パケット２０８をプロトコル・データ・ユニット２２６に変換する。プロトコル・データ・ユニット（ＰＤＵ）２２６は、ヘッダ２２８と１つまたはそれ以上の表示データ値（ＰＤＶ）２３０を含む。
【００５８】
それから、各ＰＤＵ２２６は、トランスポート層２１８からアッパ・レベル・サービス層２１８に通信エンジン１０４によって送られる。それから、ＰＤＵは、データ・サービス層２２２に伝送される。
【００５９】
それから、通信エンジン１０４は、データ・サービス層２２２により受信された各ＰＤＵ２２６から表示データ値（ＰＤＶ）２３０を抽出する。一般に、通信エンジン１０４は、ＰＤＶ２３０から表示データ値の入力ストリーム（ＰＤＶＩＳ）２３２を生成する。通信エンジン１０４は、ＰＤＶＩＳ２３２を使用してメッセージ２３４を形成する。
【００６０】
通信エンジン１０４は、ＰＤＶＩＳ２３２を含むメッセージ２３４をサービス・クラス層２２４に伝送する。サービス・クラス層２２４でデータ要素の発信元２３６は、各メッセージからの表示データ値の入力ストリーム（ＰＤＶＩＳ）２３２からデータ要素を抽出する。データ要素の発信元２３６は、新しい入力転送構文（ＩＴＳ）２３８になり、これはＰＤＶＩＳ２３２内に含まれるデータを構文解析するために使用できる。
【００６１】
アプリケーション・レベル２０４で、入力転送構文２３８がバイトの入力ストリームからデータ要素２４０を抽出して、このデータ要素２４０を関連アプリケーション・プログラム１０１により要求される時に使用する。入力転送構文２３８は、ストリーミング閾値と呼ばれる属性を有する。抽出されたデータ要素がストリーミング閾値よりも長ければ、データ要素２４０は、ストリーミング・データ要素である。ストリーミング・データ要素は、入力転送構文２３８になお存在する実際のデータ素子２４０の代りである。このストリーミング・データ要素は、入力転送構文２３８を使用して、その値に段階的にアクセスすることを可能にする。段階的アクセスは、ストリーミング・データ要素が書き込まれているデータのブロックにより供給される。
【００６２】
アプリケーション・レベル２０４からネットワーク・レベル２０２への下向きのデータ・フロー２４２のために、データ要素の発信元２３６が最初にサービス・クラス２２４を通じて移動する。それからデータ要素の発信元２３６は、データ・サービス２２２を通過する。データ・サービス２２２でパケッタイザ２４４は、データ要素の発信元２３６を取って出力転送構文２３８を生成する。出力転送構文２３８は、データ要素の発信元２３６からのデータ要素の各々を処理して、エンコードされたデータ要素をパケッタイザ２４４に渡す。それから、パケッタイザ２４４は、エンコードされたデータ要素をとって表示データ値（ＰＤＶ）を生成する。
【００６３】
ＰＤＶが生成されると、このＰＤＶは、ＤＩＣＯＭ状態機械２４６に渡されて、そこで処理される。それからＰＤＶは、ＤＩＣＯＭ状態機械２４６により、トランスポート・レベル２１８に渡される。トランスポート２１８は、ＰＤＶをＴＣＰ／ＩＰ層２１０へ書き出すが、それは、ネットワーク接続であるバイトの出力ストリーム２４８を通じて行う。
【００６４】
図２を参照して上記した例示的なデータ・フローは、比較的大きなＤＩＣＯＭオブジェクトを処理するために限定された固定量のメモリのみを使用する。使用するメモリは、メモリ使用シナリオに関して下記のように説明できる。ネットワーク・レベルからアプリケーション・レベルに送られる１つのＤＩＣＯＭオブジェクトは、そのサイズが約６００メガバイト（ＭＢ）であり、その内の５９９ＭＢは、ピクセル・データ（ＰＤ）要素である。最大のプロトコル・データ・ユニット（ＰＤＵ）サイズは、結合または接続中に折衝され、その最大サイズは、約２０キロバイト（ＫＢ）である。さらに、この結合または接続は、表示データ値の入力ストリーム（ＰＤＶＩＳ）内の表示データ値（ＰＤＶ）の最大数を所定の限度、すなわち最大数の５に定義できる。注意すべきは、この所定の限度は、表示データ値（ＰＤＶ）を記憶するのに使用されるバッファまたはメモリ記憶装置のサイズにより選択できることである。
【００６５】
ＰＤＶＩＳがＰＤＶの数を５に限定すれば、ネットワークからＤＩＣＯＭオブジェクトを読み取るのに必要なメモリの最大量は、（５ Ｘ ２０ＫＢ）＋２０ＫＢ、すなわち１２０ＫＢである。この「＋２０ＫＢ」は、ＰＤＶＩＳに配置されるＰＤＵ待ちが原因である。
【００６６】
それから、アプリケーション・プログラムは、入ってくるＤＩＣＯＭオブジェクトをファイルに書き込み、入力転送構文（ＩＴＳ）をデータ要素の発信元として出力転送構文（ＯＴＳ）にファイルのために渡す。ＯＴＳは、ピクセル・データ要素をエンコードするために約１０ＫＢを使用する。その他の全てのデータ要素は、全体として個別にエンコードできるが、シーケンス・データ（ＳＱ）要素は、例外である。全ての他のデータ要素は、通常１０ＫＢよりも比較的に小さいので、ファイルするためにデータ要素をデコードするのに使用されるメモリの最大量は、１０ＫＢになるはずである。
【００６７】
こうして、ネットワークからデコードするために使用されるメモリおよびファイルにエンコードするために使用されるメモリの総量は、デコードのために約１２０ＫＢ、エンコードのために１０ＫＢであり、合計で１３０ＫＢになるはずである。
【００６８】
図３から図６は、本発明に使用される方法の実施例のフローチャートを示す。図３ａから図３ｃおよび図４ａと図４ｂは、ネットワークからの読取りおよびそこへの書込みのようなオペレーションを示し、図５と図６は、ファイルからの読取りと、そこへの書込みのようなオペレーションを示す。図３から図６に示す方法を採用することにより、比較的小さな固定量のメモリのみを使用して、全てのあり得るＤＩＣＯＭデータの相互作用を処理することができる。これらのＤＩＣＯＭデータの相互作用は、ネットワークからメモリ記憶装置へのデータの読取りと書込み、メモリ記憶装置からネットワークへのデータの読取りと書込み、およびネットワークからネットワークへの読取りと書込みのようなＤＩＣＯＭネットワークの相互作用を含む。注意すべきは、種々の構成のメモリ記憶装置およびネットワークを使用する他のタイプのＤＩＣＯＭデータの相互作用が本発明により実行できることである。
【００６９】
図３ａから図３ｃは、デジタル・データをネットワークからアプリケーションへ読み込む方法３００を示す。一般に、デジタル・データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ネットワークは、ＤＩＣＯＭ通信ネットワークであり、アプリケーションは、ＤＩＣＯＭネットワーク・プロトコルを使用して通信できる医療画像アプリケーション・プログラムである。この方法３００は、３０２で開始する。
【００７０】
３０２に続く３０４において、通信エンジン１０４は、プロトコル・データ・ユニット（ＰＤＵ）のサイズを折衝する。ＰＤＵのサイズを設立することにより、通信エンジン１０４は、デジタル・データを処理するのに必要または望ましいバッファ１１２内のメモリの量を監視できるようになる。その上、表示データ値（ＰＤＶ）の所定の数、限度またはサイズまたは他のタイプのデータ要素または品質も、デジタル・データを処理するのに必要または望ましいバッファ１１２内のメモリ記憶域の量によって設立できる。典型的に、これらのステップは、状態機械１１０によるサービス・コントロール・プロバイダ（ＳＣＰ）とサービス・コントロール・ユニット（ＳＣＵ）の間の結合または接続の設立と共に実行される。アッパ・レベル・サービス層１１８を通じて、通信エンジン１０４は、方法３００全体を通じて状態機械１１０を監視し制御する。
【００７１】
３０４に続く３０６で通信エンジン１０４は、ネットワークからデジタル・データを段階的に読み取る。たとえば、通信エンジン１０４は、ＤＩＣＯＭネットワーク１０２内のサーバ１２８ａ−ｎからＤＩＣＯＭ画像ファイルなどのデジタル・データを要求する。ＤＩＣＯＭ画像ファイルは、デジタル画像データの１つまたはそれ以上のセットを含む。サーバ１２８ａ−ｎは、ソケット、アプリケーション・プログラム・インターフェイスを介してＴＣＰ／ＩＰ１２６を通じて通信エンジン１０４にデジタル画像データ・セットを伝送する。通信エンジン１０４は、サーバ１２８ａ−ｎからＤＩＣＯＭパケットまたはプロトコル・データ・ユニット（ＰＤＵ）の形式でデジタル画像データ・セットを受信する。
【００７２】
注意すべきは、ソケットを使用してＴＣＰ／ＩＰを通じてデジタル・データを生成し伝送するのに必要な方法とシステムは、当業者に理解されることである。さらに、プロトコル・データ・ユニット（ＰＤＵ）とＤＩＣＯＭパケットは、すでに上述のＤＩＣＯＭネットワーク・プロトコルの下で定義されている。
【００７３】
３０６に続く３０８で通信エンジン１０４は、各ＰＤＵまたはＤＩＣＯＭパケットを段階的に読み取る。つまり、通信エンジン１０４は、ＤＩＣＯＭプロトコル１１４のトランスポート層１１６を通じて読取りスレッド（図示なし）を開始する。読取りスレッドは、ＤＩＣＯＭプロトコル１１４のトランスポート層１１６のいたるところに、一回に１つずつＰＤＵまたはＤＩＣＯＭパケットの各々を段階的に読み取って伝送する。読取りスレッドは、ネットワークから伝送すべきデジタル・データのＰＤＵまたはＤＩＣＯＭパケットの全てが処理されるまで、ＰＤＵまたはＤＩＣＯＭを処理し続ける。
【００７４】
３０８に続く３１０で通信エンジン１０４は、ＰＤＵをアッパ・レベル・サービス層１１８に伝送する。結合または接続中にＰＤＵが適当な時間に達すると、通信エンジン１０４によりＰＤＵは、データ・サービス層１２０に伝送される。
【００７５】
３１０に続く３１２で通信エンジン１０４は、各プロトコル・データ・ユニット（ＰＤＵ）から表示データ値（ＰＤＶ）を抽出する。つまり、ＰＤＵがデータ・サービス層１２０に受信されると、通信エンジン１０４は、ＰＤＵから表示データ値（ＰＤＶ）を抽出する。各プロトコル・データ・ユニットは、１つまたはそれ以上の表示データ値を含む。
【００７６】
３１２に続くサブルーチン３１４でオペレーション・メッセージのために表示データ値の入力ストリームが生成される。サブルーチン３１４は、図３ｃを参照して一層詳細に説明される。
【００７７】
図３ｂにおいて、サーブ・ルーチン３１４は、３５０で始まる。３５０において通信エンジン１０４は、表示データ値を使用して、表示データ値の入力ストリームを生成する。最初、すなわち第１のプロトコル・データ・ユニット（ＰＤＵ）のために、通信エンジン１０４で受信された抽出表示データ値（ＰＤＶ）が使用されて、表示データ値の入力ストリーム（ＰＤＶＩＳ）が生成される。後続のＰＤＵのために抽出ＰＤＶが既存の表示データ値の入力ストリームに挿入されるか、または必要な場合は、新しい表示データ値の入力ストリームが生成される。表示データ値の入力ストリームは、本質的に比較的小さな固定量のメモリを使用して伝送できる１つまたはそれ以上のＰＤＵからの表示データ値（ＰＤＶ）のストリングである。表示データ値の入力ストリーム（ＰＤＶＩＳ）は、オペレーション・メッセージの基礎を形成する。
【００７８】
通信エンジンは、各抽出ＰＤＶを一回に１つずつデータ・サービス層１２０に段階的に伝送し続ける。データ・サービス層１２０は、上記のように各ＰＤＶを表示データ値の入力ストリーム（ＰＤＶＩＳ）に挿入する。ＰＤＶＩＳは、ある与えられた瞬間において、所定または限られた数のＰＤＶを記憶するように限定される。典型的にＰＤＶＩＳは、一回に５ＰＤＶを記憶するように限定される。注意すべきは、所定または限定された数は、ＰＤＶおよび／またはＰＤＶＩＳに記憶すべきバッファまたは他のメモリ記憶装置のサイズによって決定されることである。
【００７９】
３５０に続く決定ブロック３５２でデータ・サービス層は、所定または限定された数のＰＤＶに到達したかどうかを決定する。この方法で、画像データの伝送が段階的に制御されて、全ての画像データを処理するのに必要なメモリ記憶空間の量を最小化することができる。データ要素の発信元１０６は、一回に１つずつ段階的にＰＤＶを処理して、各ＰＤＶをＰＤＶＩＳに伝送する。所定または限定されたＰＤＶの数に達すると、「ＹＥＳ」分岐をたどって３５４に行く。たとえば、所定または限定された数のＰＤＶが事前に５に設定され、特定のＰＤＶＩＳ内に、この所定または限定された数のＰＤＶがすでに存在すれば、そのときは、すでに限界に達している。この方法で、本発明は、メモリの使用をＤＩＣＯＭデータなどのデジタル・データの伝送のために使用し得る比較的小さな固定したメモリの量に監視し限定することができる。いくつかの場合には、バッファ１１２またはメモリ記憶装置のサイズによって、所定または限定されたサイズが設定されることに注意される。この方法により、ピクセル・データ（ＰＤ）要素および比較的大きなＤＩＣＯＭオブジェクトを比較的小さな固定サイズのメモリ部分で処理することができる。
【００８０】
３５４において通信エンジン１０４は、表示データ値の入力ストリームから表示データ値が読み取られるまで、表示データ値の更なる処理を遅らせる。通信エンジン１０４は、データ・サービス層１２０に命令して、表示データ値の入力ストリーム（ＰＤＶＩＳ）から表示データ値（ＰＤＶ）が読み取られるまで待たされる。つまり、通信エンジン１０４は、１つのＰＤＶがデータ・サービス層１２０にＰＤＶＩＳから読み取られるまで、トランスポート層１１６が更なるＰＤＶをＰＤＶＩＳに読み込むのを防止するように命令する。１つのＰＤＶがＰＤＶＩＳから読み取られると、通信エンジン１０４は、データ・サービス層に命令し、トランスポート層１１６が所定または限定された数のＰＤＶに達するまでＰＤＶをＰＤＶＩＳに渡し続けられる。
【００８１】
決定ブロック３５２に戻ると、ＰＤＶの所定または限定された数に達していなければ、「ＮＯ」分岐をたどって、そこでサブルーチン３１４が終了して、３１６で方法３００が継続する。
【００８２】
３１６において、メッセージ・サービスは、どのオペレーションにオペレーション・メッセージが対応するかを決定する。典型的にサブ・ルーチン３１４内で通信エンジン１０４により１つのオペレーション・メッセージが生成されると、通信エンジン１０４は、メッセージ・サービス（図示なし）にＰＤＶとＰＤＶＩＳを含むオペレーション・メッセージを送る。メッセージ・サービスは、ＤＩＣＯＭプロトコル１１４のデータ・サービス層１２０の構成要素である。
【００８３】
ＤＩＣＯＭネットワーク・プロトコルにおいて、オペレーションは、サービス・オブジェクト・ペア（ＳＯＰ）により定義される。状態機械１１０により設立される最初の結合または接続の間に、１つまたはそれ以上のＳＯＰが識別できる。ＳＯＰを使用することにより、メッセージ・サービスは、メッセージが一致または対応するオペレーションを有するかどうかを決定する。
【００８４】
３１６に続く３１８において、メッセージ・サービスは、オペレーション・メッセージを対応するオペレーションに伝送する。メッセージ・サービスにより、ＳＯＰがあるメッセージに対して対応する一致と識別されると、オペレーション・メッセージは、対応するオペレーションに伝送される。
【００８５】
３１８に続く３２０において、オペレーション・メッセージは、後続の処理のために対応するオペレーショにより待ち行列に入れられる。メッセージが待ち行列に入れられると、この方法３００は、図３ｃの３２０で継続する。
【００８６】
３２０に続く３２２において、待ち行列に入れられたメッセージは、それぞれのオペレーションにより処理される。少なくとも１つの待ち行列に入れられたオペレーション・メッセージを受信する全てのオペレーションは、１つのスレッドを開始する。それから、各オペレーションについて、各スレッドが各待ち行列に入れられたオペレーション・メッセージを一回に１つずつ処理する。それから、各待ち行列に入れられたオペレーション・メッセージは、オペレーション・メッセージがそのために生成された対応するサービスに渡される。注意すべきは、ＤＩＣＯＭネットワーク・プロトコルにより定義されるように、各オペレーションが１つの対応するサービスまたはＳＯＰを有することである。それぞれのオペレーションのために各待ち行列に入れられたメッセージの処理が完了するまで、各スレッドは、各オペレーション・メッセージの処理を続ける。
【００８７】
３２２に続く３２４において、サービスは、表示データ値の入力ストリーム（ＰＤＶＩＳ）からデータ要素を抽出する。
【００８８】
３２４に続く３２６において、サービスは、新しい入力転送構文（ＩＴＳ）を生成する。サービスは、表示データ値の入力ストリーム（ＰＤＶＩＳ）を使用して、新しいＩＴＳを生成し、この新しいＩＴＳは、ＰＤＶＩＳに含まれるデータを構文解析するために使用できる。ＰＤＶＩＳに含まれるデータは、一連の表示データ値（ＰＤＶ）である。典型的にはデータ値は、エンコードされ、コーディングをデータ要素の標準的なメモリ表現として理解できる表現に変換するために、入力転送構文が使用できる。それから、構文解析されたデータは、通信エンジン１０４によりデータ要素の発信元１０６にストリームされる。
【００８９】
３２６に続く３２８において、データ要素の発信元１０６は、構文解析されたデータ・ストリームを段階的に読み取る。各サービスは、データ要素の発信元１０６を使用して、表示データ値の入力ストリーム（ＰＤＶＩＳ）内に収納されたデータ・ストリームから、一回にデータ要素の１つのブロックを読み取る。入力転送構文（ＩＴＳ）は、またデータ要素の発信元１０６を通じてデータ要素を段階的に読むために使用される。
【００９０】
データ要素の発信元１０６において、サービスにより少なくとも２つのタイプのデータ要素を処理できるが、それはシーケンス・データ（ＳＱ）とピクセル・データ（ＰＤ）である。ＳＱデータ要素は、データ要素の１つまたはそれ以上のセットを含むデータ要素である。ＳＱデータ要素は、再帰的に処理できる。つまり、データ要素の１セットは、一回に１つずつのデータ要素が処理される。ＰＤ要素は、ＤＩＣＯＭオブジェクトまたは画像ファイル内で最大のデータ要素の１つである。ＰＤ要素は、バイト（８ビット）またはワード（１６ビット）の未加工のデータ配列により構成される。このタイプのデータ要素は、ストリーミングの追加の層を可能にする。サービスは、ピクセル・データを段階的に獲得でき、こうして時間の単一インスタンスにおいて、メモリ内に全てのＰＤ値を獲得する必要性を最小化できる。ピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトが比較的大きいものであることに注意される。本発明は、全てのサイズのピクセル・データ（ＰＤ）要素とＤＩＣＯＭオブジェクトを比較的小さな時間上の部分の中で処理できる。
【００９１】
３２６に続く３２８において方法３００が終了する。
【００９２】
図４ａと図４ｂは、本発明の第２の例示的な方法を示す。後述するが、図４ａと図４ｂは、あるアプリケーションからネットワークまたは他のアプリケーションにデータを書き込む方法４００を記述する。一般に、データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ネットワークは、ＤＩＣＯＭ通信ネットワークであり、アプリケーションは、ＤＩＣＯＭネットワーク・プロトコルを使用して通信できる医療画像アプリケーション・プログラムである。
【００９３】
４０２において方法４００が開始する。
【００９４】
４０２に続く４０４において、通信エンジン１０４は、１つのデータ・セットを求める。典型的にあるユーザが結合アプリケーション・プログラム１０１と対話するときに、または代わりにＤＩＣＯＭネットワーク１０２内のサーバ１２８ａ−ｎ上で実行するアプリケーション・プログラム１３０と対話するときに、このユーザは、特定のＤＩＣＯＭオブジェクトまたは画像上で特定の機能を実行したいと望むかも知れない。ユーザは、アプリケーション・プログラム１０１、１３０またはネットワーク１０２の特定サービスに対応する関連アプリケーション１０１またはアプリケーション・プログラム１３０内の対応するコマンド機能を選択する。このコマンド機能を受信すると、サービスは、通信エンジン１０４のために対応するデータ・セットを配置する。注意すべきは、あるデータ・セットは１つまたはそれ以上のデータ・セットであって、各データ・セットが１つまたはそれ以上のデータ要素を含むことである。ＤＩＣＯＭオブジェクトまたは画像のためのデータ・セットは、媒体記憶装置モジュール１３２またはメタ・データ・ベース・モジュール１３４のような関連メモリ装置内に記憶される。
【００９５】
４０４に続く４０６において選択されたサービスは、データ・セットのために新しい出力転送構文（ＯＴＳ）を生成する。サービスがコマンド機能を受信すると、このサービスは、データ・セットを処理するために新しい出力転送構文（ＯＴＳ）を生成する。ＯＴＳは、データ・セットをバイト・ストリームのようなデータ・ストリームにフォーマットまたは変換できる。データ・セットは、データ要素の発信元である。ＯＴＳは、データ要素の発信元をバイト・ストリームのようなデータ・ストリームにフォーマットまたは変換できる。データ要素の発信元（ＤＥＳ）は、データ要素の概念的なセット上の順方向イテレータである。たとえば、入力転送構文（ＩＴＳ）は、表示データ値（ＰＤＶ）の特定セットのためにデータ要素（ＤＥＳ）を生成できる。
【００９６】
４０６に続く４０８においてサービスは、統率データ・セット入力ストリーム（ＧＤＳＩＳ）を生成する。出力転送構文を使用してサービスは、統率データ・セット入力ストリーム（ＧＤＳＩＳ）を生成する。それからＧＤＳＩＳは、それ自身のスレッドを使用してデータ・セットまたはデータ要素の発信元を出力転送構文を使用するバイト・ストリームのようなデータ・ストリームに変換する。ＧＤＳＩＳは、比較的小さな固定量のメモリのみを使用して、データ・セットまたはデータ要素の発信元をデータ・ストリームに変換する。
【００９７】
典型的に、出力転送構文は、データ・セットまたはデータ要素の発信元から一回に１つずつデータ要素を取り、各データ要素を一連のデータ要素またはデータ・ストリームにエンコードする。少なくとも２つのタイプのデータ要素が出力転送構文により処理されるが、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合は、ＳＱ要素がデータ要素のセットを含む。ＳＱ要素が出力転送構文（ＯＴＳ）により読み取られると、ＯＴＳは、１つの特定データ要素のセットから一回に１つずつデータ要素を再帰的に処理する。ＰＤ要素の場合は、ＰＤ要素がバイトまたはワードの大きな配列を含む。出力転送構文（ＯＴＳ）によりＰＤ要素が読み取られると、ＯＴＳは、これらをデータ要素の片または小さな固定サイズとして処理する。いずれの場合もメモリの比較的小さな固定サイズのみがデータ要素を処理するためにＯＴＳにより使用される。サービスは、ピクセルを段階的に獲得できるので、ある１つの瞬間にメモリ内の全てのＰＤ値を獲得する必要性を最小化できる。注意すべきは、ピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトが比較的大きいことである。本発明は、全てのサイズのピクセル・データ（ＰＤ）要素および他のＤＩＣＯＭオブジェクトを比較的小さな時間で処理できる。
【００９８】
４０８に続く４１０においてサービスは、統率データ・セット入力ストリームをオペレーション・メッセージ内にパッケージする。
【００９９】
４１０に続く４１２においてサービスは、メッセージ・サービスにメッセージを送る。
【０１００】
４１４に続く４１６においてメッセージ・サービスは、メッセージに対応するオペレーションを決定する。
【０１０１】
４１６に続く４１８においてメッセージ・サービスは、データ・サービス層１２０にメッセージを渡す。
【０１０２】
４１８に続く４２０においてデータ・サービス層１２０は、メッセージから統率データ・セット入力ストリームをデコードする。一般に、データ・サービス層１２０は、メッセージ・サービスからメッセージを受信する。メッセージ・サービスは、メッセージから統率データ・セット入力ストリーム（ＧＤＳＩＳ）を抽出して、ＧＤＳＩＳからバイトを読み取る。メッセージ・サービスが１つのプロトコル・データ・ユニット（ＰＤＵ）を構築できるまで、メッセージ・サービスは、ＧＤＳＩＳからバイトを読み取り続ける。それから方法４００は、図４ｂの４２０で継続する。
【０１０３】
４２０に続く４２２においてメッセージ・サービスは、トランスポート層１１６にプロトコル・データ・ユニット（ＰＤＵ）を送る。典型的に、結合または接続が開放されているときに、メッセージ・サービスは、ＰＤＵをアッパ・サービス・レベル層１１８を通じてトランスポート層１１６に送ることができる。
【０１０４】
４２２に続く４２４においてトランスポート層１１６は、プロトコル・データ・ユニットを受信アプリケーションに伝送する。一般に、トランスポート層１１６は、プロトコル・データ・ユニット（ＰＤＵ）をＴＣＰ／ＩＰ層１２６経由で伝送し、それからＤＩＣＯＭネットワーク１０２を通じてアプリケーション・プログラム１３０に伝送する。
【０１０５】
４２４に続く決定ブロック４２６において、データ要素の発信元１０６により、メッセージ・サービスは、全てのデータ要素が１つのバイト・ストリームに変換済みであるかどうかを決定する。全てのデータ要素が変換済みであれば、「ＹＥＳ」分岐に４２８が続く。
【０１０６】
４２８において方法４００が終了する。
【０１０７】
残りのデータ要素の全てが変換済みでなければ、決定ブロック４２６に戻って、「ＮＯ」分岐に４２０が続く。統率データ・セット入力ストリーム（ＧＤＳＩＳ）の処理を完了する必要があるので、方法４００は、４２０に戻る。
【０１０８】
図５は、本発明の第３の例示的な方法を図示する。図５は、ファイルからデータを読み取る方法５００を説明する。一般に、このデータは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、このファイルは、関連アプリケーション・プログラム１０１またはＤＩＣＯＭプロトコルを使用して通信できる医療画像プログラムなどのアプリケーション・プログラム１３０である。このファイルは、ＤＩＣＯＭネットワーク１０２などの通信ネットワークと共に動作する前記のサーバ１２８ａ−ｎまたは媒体記憶モジュール１３２またはメタ・データベース・モジュール１３４など前記の記憶装置またはシステム上にあらかじめ記憶される。図５において方法５００は、５０２で開始する。
【０１０９】
５０２に続く５０４において通信エンジン１０４は、画像ファイルについてファイル入力ストリームを生成する。ファイル入力ストリームは、バイトの入力ストリームである。典型的に、ユーザがファイルから画像データまたはオブジェクトを読み取ることを決定すると、ユーザは、オブジェクトまたは画像ファイルを読み取るアプリケーション・コマンドを選択する。たとえば、結合アプリケーション・プログラム１０１は、ユーザがＤＩＣＯＭオブジェクトまたは画像ファイルを含むファイルを読み取るためにコマンドを選択できるようにする。特定のコマンドが選択されると、関連アプリケーション・プログラム１０１は、ＤＩＣＯＭオブジェクトまたは画像ファイルを含むシステム内に読み取られるＤＩＣＯＭオブジェクトまたは画像ファイルについてのファイル入力ストリームを生成する。このファイル入力ストリームは、ファイル内のバイトまたはデータ要素の一部分にわたる順方向イテレータである。ファイル入力ストリームは、最初から終わりまで単一方向に読み取られる。以前に定義したように、システムは、サーバ１２８ａ−ｎ、媒体記憶モジュール１３２またはメタ・データベース・モジュール１３４である。
【０１１０】
５０４に続く５０６において通信エンジン１０４は、画像ファイルを読み取るために入力転送構文（ＩＴＳ）を生成する。一般に、通信エンジン１０４は、あらかじめ生成されたファイル入力ストリームを使用して、入力転送構文（ＩＴＳ）を生成する。それから、この入力転送構文を使用して対応するオブジェクトまたは画像ファイルからデータ要素を読み取ることができる。
【０１１１】
５０６に続く５０８においてデータ要素の発信元１０６は、ファイル入力ストリームから各データ要素を段階的に読み取る。各データ要素１０６は、入力転送構文（ＩＴＳ）を使用して、ファイル入力ストリームから一回に１つのデータ要素またはデータ要素の１つのブロックを段階的に読み取る。少なくとも２つの異なったデータ要素が処理されるが、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合、ＳＱ要素は、データ要素のセットを含む。入力転送構文（ＩＴＳ）によりＳＱ要素が読み取られると、ＩＴＳは、データ要素の１つの特定セットから一回に１つずつデータ再帰的に処理する。ＰＤ要素の場合、ＰＤ要素は、バイトまたはワードの大きなアレイを含む。入力転送構文（ＩＴＳ）によりＰＤ要素が読み取られると、ＩＴＳは、これらを片または小さな固定サイズのデータ要素として処理する。いずれの場合も、比較的小さな固定サイズのメモリのみを使用してデータ要素を処理する。
【０１１２】
５０８に続く５１０において通信エンジン１０４は、入力転送構文（ＩＴＳ）を閉じる。つまり、データ要素の発信元により全てのデータ要素が読み込まれてしまった後で、入力転送構文を閉鎖する通信エンジンが閉じて、データ要素の発信元１０６によりデータ要素の更なる処理は、何も行われない。
【０１１３】
５１０に続く５１２において方法５００が終了する。
【０１１４】
図６は、本発明の第４実施例を示す。図６は、ファイルにデータを書き込む方法６００を示す。一般に、データは、ＤＩＣＯＭオブジェクトまたは画像ファイルであり、ファイルは、ＤＩＣＯＭプロトコルを使用して通信できる医療画像プログラムなどのアプリケーションに結合できる。ファイルは、ＤＩＣＯＭ通信ネットワークなどのネットワークと共に動作するサーバなどのシステムまたは記憶装置上にあらかじめ記憶される。図６において方法６００は、６０２で開始する。
【０１１５】
６０２に続く６０４において通信エンジン１０４は、ファイル出力ストリームを生成する。ファイル出力ストリームは、バイト出力ストリームである。典型的に、ユーザがファイルに画像データを書き込むことを決定すると、ユーザは、関連アプリケーション・プログラム１０１またはアプリケーション・プログラム１３０からコマンドを選択して、オブジェクトまたは画像ファイルにデータを書き込む。たとえば、関連アソシエーション・プログラム１０１は、ユーザがコマンドを選択して、ＤＩＣＯＭオブジェクトまたは画像の記憶用に構成されたファイルに画像データを書き込めるようにする。ある特定のコマンドが選択されると、アプリケーション・プログラム１３０は、ＤＩＣＯＭオブジェクトまたは画像ファイルを含むシステムに書き込まれる画像データのためのファイル出力ストリームを生成する。このシステムは、前に定義したように、サーバ１２８ａ−ｎ、媒体記憶モジュール１３２またメタ・データベース・モジュール１３４である。
【０１１６】
６０４に続く６０６においてアプリケーション・プログラム１３０は、出力転送構文（ＯＴＳ）を生成して、オブジェクトまたは画像ファイルへ画像データを書き込む。一般に、関連アプリケーション・プログラム１０１またはアプリケーション・プログラム１３０は、事前に生成されたファイル出力ストリームを使用して出力転送構文（ＯＴＳ）を生成する。出力転送構文（ＯＴＳ）が生成されるとき、ファイル出力ストリームは、出力転送構文を生成するのに使用される１つのアーギュメントである。それから、ＯＴＳは、対応するオブジェクトまたは画像ファイルに画像データを書き込むために使用される。
【０１１７】
６０６に続く６０８においてデータ要素の受信側１０８は、各データ要素をファイル出力ストリームに段階的に書き込む。つまり、データ要素の受信側１０８が出力転送構文（ＯＴＳ）を使用して、一回に１つずつデータ要素またはデータ要素のブロックをファイル出力ストリームに段階的に書き込む。図５に上述したように、少なくとも２つのタイプのデータ要素が処理され、それはシーケンス・データ（ＳＱ）要素とピクセル・データ（ＰＤ）要素である。シーケンス・データ（ＳＱ）要素の場合は、ＳＱ要素は、データ要素を含む。出力転送構文（ＯＴＳ）によりＳＱ要素が書き込まれると、ＯＴＳは、データ要素の一特定セットから一回に１つずつデータ要素を再帰的に処理する。ＰＤ要素の場合は、ＰＤ要素は、バイトまたはワードの大きなアレイを含む。出力転送構文（ＯＴＳ）によりＰＤ要素が書き込まれると、ＯＴＳは、これらをデータ要素の片または小さな固定サイズとして処理する。いずれの場合も、比較的小さな固定サイズのメモリが出力転送構文（ＯＴＳ）により使用されてデータ要素を処理する。
【０１１８】
６０８に続く６１０において通信エンジン１０４は、出力転送構文（ＯＴＳ）を閉じる。つまり、データ要素の受信側１０８により全てのデータ要素をファイル出力構文に書き込んだ後で出力転送構文は、通信エンジン１０４を閉じて、こうしてオブジェクトまたは画像ファイルを含むファイルを効果的に閉じる。
【０１１９】
６１０に続く６１２において方法６００が終了する。
【０１２０】
図７は、ＤＩＣＯＭ画像ファイル内に含まれるデータの代表的な図を示す。この特定の例は、磁気共鳴映像（ＭＲＩ）ＤＩＣＯＭ画像ファイル７００である。この例において、最初の７９４バイトは、ＤＩＣＯＭフォーマット・ヘッダ７０２のために使用される。フォーマット・ヘッダ７０２は、画像寸法を記述し、走査に関する他のテキスト情報を保持する。ヘッダ７０２のサイズは、どれだけ多くの情報が記憶されるかにより変わる。この例は、１０９ｘ９１ｘ２ピクセルの画像寸法であり、ピクセルあたり１バイトの解像度を有し、こうして全画像サイズが約１９，８３８バイトであることを示す。
【０１２１】
画像データ７０４ｈは、ヘッダ７０２に続くファイル部分に記憶される。画像データも、ヘッダ７０２と関連情報として同一ファイル内に記憶される。
【０１２２】
図８は、ＤＩＣＯＭ画像ファイル内に含まれるデータを示す。この例において、ＤＩＣＯＭヘッダ・フォーマットは、１２８バイトのプリアンブルを必要とする。典型的に、ＤＩＣＯＭヘッダ・フォーマットにおいて１２８バイトのプリアンブルは、通常、ゼロに設定される。この１２８バイトのプリアンブルには、それから「Ｄ」、「Ｉ」、「Ｃ」、「Ｍ」の文字が続く。それからヘッダ情報が最後の文字「Ｍ」に続く。ヘッダ情報は「グループ」と呼ばれる１つまたはそれ以上の部分で組織される。たとえば、グループ「０００２ｈｅｘ」は、ファイル・メタ情報グループを指定できる。このグループは、グループ長さ、ファイル・バージョン、転送構文のような３つの要素を定義できる。各グループ内で定義されるＤＩＣＯＭデータ要素は、画像タイプにより異なる。定義されるデータ要素の代表的な例は、２０００ＤＩＣＯＭ規格のパート３にリストされている。たとえば、磁気共鳴（ＭＲ）画像ファイルは、要素０００８，００６０により指定できる。このタイプの画像ファイルは、ＭＲＩエコー・タイムを記述するために１つまたはそれ以上の画像ファイルを含む。
【０１２３】
本発明の精神と範囲から離れることなく本発明に付随する代替実施例は、当業者に明らかにある。したがって、本発明の範囲は、前記の記載よりも、むしろ特許請求の範囲により定義される。
【図面の簡単な説明】
【０１２４】
【図１】本発明の例示的な実施例によるシステムの機能的なブロック図である。
【図２】本発明の例示的な実施例のデータ・フロー図を示す。
【図３ａ】本発明の１つの例示的な方法を図示する。
【図３ｂ】本発明の１つの例示的な方法を図示する。
【図３ｃ】本発明の１つの例示的な方法を図示する。
【図４ａ】本発明の第２の例示的な方法を図示する。
【図４ｂ】本発明の第２の例示的な方法を図示する。
【図５】本発明の第３の例示的な方法を図示する。
【図６】本発明の第４の例示的な方法を図示する。
【図７】ＤＩＣＯＭ画像ファイル内に含まれるデータの代表的な例を示す。
【図８】ＤＩＣＯＭ画像ファイル内に含まれるデータを示す。
【特許請求の範囲】
【請求項１】
一定量のメモリを使用して第１の装置から第２の装置にデジタル・データを通信する方法であって、前記デジタル・データがデータ要素を定義し、
前記第１の装置からの前記デジタル・データを表現するバイトの入力ストリームを供給し、
前記バイトの入力ストリームからデータ要素の発信元を生成し、
第２の装置で受信される前記デジタル・データを表現するバイトの出力ストリームを生成し、
前記バイトの出力ストリームに１つまたはそれ以上のバイトを供給するように構成されたデータ要素の受信側を生成し、
前記データ要素の発信元およびデータ要素の受信側を使用するように構成された通信エンジンを生成し、
前記データ要素の発信元からデータを要求し、
前記バイトの入力ストリームからデータ要素に次のバイトを変換し、
前記データ要素の受信側に前記データ要素を供給し、
前記データ要素をバイトに変換し前記バイトの出力ストリームに前記バイトを供給することを含む前記方法。
【請求項２】
前記第１の装置は、バイトのストリームへの変換のために構成された選択可能な少なくとも１つのファイルを含み、前記データ要素の発信元が生成される請求項１記載の方法。
【請求項３】
前記データ要素の発信元は、入力転送構文を含む請求項２記載の方法。
【請求項４】
前記第１の装置は、前記バイトの入力ストリームを供給するように構成されたネットワーク接続を含む請求項１記載の方法。
【請求項５】
前記バイトの入力ストリームは、表示データ値を含むプロトコル・データ・ユニットを含み、前記表示データ値は、バイト配列を含む請求項４記載の方法。
【請求項６】
前記バイト配列は、表示データ値の入力ストリーム内に配置できる請求項４記載の方法。
【請求項７】
前記データ要素の発信元は、前記表示データ値の入力ストリームから生成される入力転送構文を含む請求項６記載の方法。
【請求項８】
前記表示データ値の入力ストリームは、所定または限定数の表示データ値をバッファすることに限定されている請求項６記載の方法。
【請求項９】
前記第２の装置は、バイトの出力ストリームを含むファイル・システムである請求項１記載の方法。
【請求項１０】
前記データ要素の受信側は、前記バイトの出力ストリームから生成される請求項９記載の方法。
【請求項１１】
前記データ要素の受信側は、前記バイトの出力ストリームから生成される出力転送構文を含む請求項１０記載の方法。
【請求項１２】
前記第２の装置は、バイトの出力ストリームを受信するように構成されたネットワーク接続を含むネットワークである請求項１記載の方法。
【請求項１３】
前記バイトの出力ストリームは、表示データ値を含むプロトコル・データ・ユニットを生成するように構成されたパケッタイザを含む請求項１２記載の方法。
【請求項１４】
前記データ要素の受信側は、前記パケッタイザにバイトを供給する請求項１３記載の方法。
【請求項１５】
前記データ要素の受信側は、前記パケッタイザにより生成される出力転送構文である請求項１４記載の方法。
【請求項１６】
入力データ構文を前記データ要素の発信元は、バイト・リミットを供給するように構成されたストリーミング閾値を更に含む請求項１記載の方法。
【請求項１７】
データ要素を含むバイトのストリームが前記バイト・リミットを超える場合は、前記データ要素は、ストリーミング・データ要素である請求項１６記載の方法。
【請求項１８】
前記ストリーミング・データ要素は、前記入力転送構文から得られる増分値を含む請求項１７記載の方法。
【請求項１９】
前記データ要素の受信側は、ストリーミング・データ要素を供給し、前記データ要素の受信側は、出力転送構文を含む請求項１記載の方法。
【請求項２０】
前記データ要素の受信側は、前記ストリーミング・データ要素から値を固定ブロック・サイズで要求する請求項１９記載の方法。
【請求項２１】
各ブロックが受信されると、前記出力転送構文が前記ストリーミング・データ要素値をエンコードする請求項２０記載の方法。
【請求項２２】
前記第１の装置は、バイトの入力ストリームを供給できる装置である請求項１記載の方法。
【請求項２３】
前記第１の装置は、データベース、テープ、ＣＤ、記憶媒体のうちの１つからなる請求項２２記載の方法。
【請求項２４】
前記第２の装置は、バイトの出力ストリームを受信できる装置である請求項１記載の方法。
【請求項２５】
前記第１の装置は、データベース、テープ、ＣＤ、記憶媒体のうちの１つからなる請求項２３記載の方法。
【請求項２６】
一定量のメモリを使用して第１の装置から第２の装置にデータを通信する方法であって、前記デジタル・データがデータ要素とデータ値を定義し、
データ・ストリーム内に記憶すべき限定された数のデータ値を定義し、
前記第１の装置からデータ要素のセットを段階的に読み取り、各データ要素を１回に１つずつ読み取り、
各データ要素から１つのデータ値を抽出し、
限定数のデータ値のみによってデータ・ストリームを生成し、
データ値の所定の限度に達すれば、限定数のデータ値を含むデータ・ストリームを第２の装置に伝送し、
前記データ・ストリームからデータ値を抽出することを含む前記方法。
【請求項２７】
限定された数のデータ値を定義することは、前記第１の装置と前記第２の装置の間の結合を折衝することを更に含む請求項１記載の方法。
【請求項２８】
前記データ・ストリームを伝送することは、前記データ・ストリームとデータ値を含む伝送に先立ってメッセージを定義し、前記メッセージのために適当なオペレーションを決定し、後続の処理のために前記メッセージを待ち行列に入れることを更に含む請求項１記載の方法。
【請求項２９】
前記データ・ストリームから前記データ値を抽出することは、前記データ・ストリーム内に含まれる前記データ値を構文解析するために使用できる転送構文を生成することを更に含む請求項１記載の方法。
【請求項３０】
前記デジタル・データは、ＤＩＣＯＭオブジェクト、ＤＩＣＯＭ画像ファイルまたはＤＩＣＯＭに基づく通信ネットワーク・プロトコルを使用して伝送できるオブジェクトの１つから構成される請求項１記載の方法。
【請求項３１】
データ・ストリーム内に記憶される限定された数のデータ値の定義は、前記データ値の数を５またはそれ以下にセットする請求項１記載の方法。
【請求項３２】
前記データ要素は、プロトコル・データ・ユニットであり、前記データ値は、表示データ値である請求項１記載の方法。
【請求項３３】
前記データは、データ要素のセットを定義するシーケンス・データ要素からなり、受信されるデータ要素のセットを段階的に読み取ることにより、各データ要素は、一回に１つずつ読み取られるようにされる請求項１記載の方法であって、一回に１つずつデータ要素を処理して段階的にデータのセットを処理し、データ要素の全てのセットから全てのデータ要素が処理されるまで段階的に処理する請求項１記載の方法。
【請求項３４】
前記データは、ビットのデータ配列を定義するピクセル・データ要素から構成され、受信されるデータ要素のセットを段階的に読み取ることにより一回に１つずつ各データ要素を読み取ることは、データ要素のブロックとしてバイトのデータ配列を段階的に処理することを更に含む請求項１記載の方法。
【請求項３５】
前記データ・ストリームは、表示データ値の入力ストリームである請求項１記載の方法。
【請求項３６】
前記第１の装置は、ネットワークであり、前記第２の装置は、ネットワークである請求項１記載の方法。
【請求項３７】
前記第１の装置は、ネットワークであり、前記第２の装置は、記憶媒体である請求項１記載の方法。
【請求項３８】
前記第１装置は、記憶媒体であり、前記第２の装置は、ネットワークである請求項１記載の方法。
【請求項３９】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを含むファイルを通信する方法であって、前記デジタル・データは、
データ要素とデータ値を定義し、
第１の装置からデジタル・データを含むファイルを受信し、
通信される各データ要素から１つのデータ値を抽出し、
デジタル・データを含む前記ファイルについてデータ値を含む１つのデータ・ストリームを生成し、
前記データ・ストリームに基づいて１つのデータ要素の発信元を生成し、
前記データ要素の発信元を通じて前記データ・ストリームから一回に１つずつデータ値を段階的に処理し、
第２の装置に前記データ値を伝送するステップを含む前記方法。
【請求項４０】
前記ファイルは、ＤＩＣＯＭオブジェクト、ＤＩＣＯＭ画像ファイルまたはＤＩＣＯＭに基づく通信ネットワーク・プロトコルを使用して送信できるオブジェクトのうちの１つからなる請求項３９記載の方法。
【請求項４１】
データ要素発信元を生成することは、一回に１つずつデータ値を段階的に読み取るように構成された入力転送構文を生成することを更に含む請求項３９記載の方法。
【請求項４２】
データ要素の発信元を生成することは、一回に１つずつデータ値を段階的に書き込むように構成された出力転送構文を生成することを更に含む請求項３９記載の方法。
【請求項４３】
前記データ要素の発信元を通じて前記データ・ストリームから一回に１つずつ前記データ値を段階的に処理することは、１つのデータ・ストリーム内に記憶されるデータ値の最大数を５またはそれ以下に定義することを更に含む請求項３９記載の方法。
【請求項４４】
前記データ要素は、プロトコル・データ・ユニットであり、前記データ値は、表示データ値である請求項３９記載の方法。
【請求項４５】
前記データは、データ要素のセットを定義するシーケンス・データ要素により構成され、前記受信されるデータ値のセットを実施可能に処理することにより一回に１つずつ各データ値が読み取られることは、一回に１つずつデータ値を読み取ってデータ値を段階的に処理し、データ要素の全てのセットから全てのデータ値を処理済みになるまで処理することを更に含む請求項３９記載の方法。
【請求項４６】
前記データは、バイトのデータ配列を定義するピクセル・データ要素で構成され、受信されるデータ値のセットを段階的に処理することにより一回に１つずつ各データが読み取られることは、データ値のブロックとしてバイトのデータ配列を段階的に処理することを更に含む請求項３９記載の方法。
【請求項４７】
前記データ・ストリームは、表示データ値の入力ストリームである請求項３９記載の方法。
【請求項４８】
前記第１の装置は、記憶媒体であり、前記第２の装置は、ネットワークである請求項３９記載の方法。
【請求項４９】
前記第１の装置は、ネットワークであり、前記第２の装置は、記憶媒体である請求項３９記載の方法。
【請求項５０】
一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする装置であって、
１つの通信モジュールを含み、この通信モジュールは、
第１の装置からデータ要素のセットを供給するように構成され、更に前記データ要素のセットから一回に１つずつデータ要素を段階的に読み取るように構成されたデータ要素の発信元と、
前記データ要素の発信元から各データ要素を送信するように構成された通信エンジンと、
前記データ通信エンジンからデータ要素を段階的に受信して各データ要素をデータ・ストリームにエンコードするように構成され、前記エンコードされたデータ・ストリームを第２の装置に送信するように更に構成されたデータ要素の受信側を含む前記装置。
【請求項１】
一定量のメモリを使用して第１の装置から第２の装置にデジタル・データを通信する方法であって、前記デジタル・データがデータ要素を定義し、
前記第１の装置からの前記デジタル・データを表現するバイトの入力ストリームを供給し、
前記バイトの入力ストリームからデータ要素の発信元を生成し、
第２の装置で受信される前記デジタル・データを表現するバイトの出力ストリームを生成し、
前記バイトの出力ストリームに１つまたはそれ以上のバイトを供給するように構成されたデータ要素の受信側を生成し、
前記データ要素の発信元およびデータ要素の受信側を使用するように構成された通信エンジンを生成し、
前記データ要素の発信元からデータを要求し、
前記バイトの入力ストリームからデータ要素に次のバイトを変換し、
前記データ要素の受信側に前記データ要素を供給し、
前記データ要素をバイトに変換し前記バイトの出力ストリームに前記バイトを供給することを含む前記方法。
【請求項２】
前記第１の装置は、バイトのストリームへの変換のために構成された選択可能な少なくとも１つのファイルを含み、前記データ要素の発信元が生成される請求項１記載の方法。
【請求項３】
前記データ要素の発信元は、入力転送構文を含む請求項２記載の方法。
【請求項４】
前記第１の装置は、前記バイトの入力ストリームを供給するように構成されたネットワーク接続を含む請求項１記載の方法。
【請求項５】
前記バイトの入力ストリームは、表示データ値を含むプロトコル・データ・ユニットを含み、前記表示データ値は、バイト配列を含む請求項４記載の方法。
【請求項６】
前記バイト配列は、表示データ値の入力ストリーム内に配置できる請求項４記載の方法。
【請求項７】
前記データ要素の発信元は、前記表示データ値の入力ストリームから生成される入力転送構文を含む請求項６記載の方法。
【請求項８】
前記表示データ値の入力ストリームは、所定または限定数の表示データ値をバッファすることに限定されている請求項６記載の方法。
【請求項９】
前記第２の装置は、バイトの出力ストリームを含むファイル・システムである請求項１記載の方法。
【請求項１０】
前記データ要素の受信側は、前記バイトの出力ストリームから生成される請求項９記載の方法。
【請求項１１】
前記データ要素の受信側は、前記バイトの出力ストリームから生成される出力転送構文を含む請求項１０記載の方法。
【請求項１２】
前記第２の装置は、バイトの出力ストリームを受信するように構成されたネットワーク接続を含むネットワークである請求項１記載の方法。
【請求項１３】
前記バイトの出力ストリームは、表示データ値を含むプロトコル・データ・ユニットを生成するように構成されたパケッタイザを含む請求項１２記載の方法。
【請求項１４】
前記データ要素の受信側は、前記パケッタイザにバイトを供給する請求項１３記載の方法。
【請求項１５】
前記データ要素の受信側は、前記パケッタイザにより生成される出力転送構文である請求項１４記載の方法。
【請求項１６】
入力データ構文を前記データ要素の発信元は、バイト・リミットを供給するように構成されたストリーミング閾値を更に含む請求項１記載の方法。
【請求項１７】
データ要素を含むバイトのストリームが前記バイト・リミットを超える場合は、前記データ要素は、ストリーミング・データ要素である請求項１６記載の方法。
【請求項１８】
前記ストリーミング・データ要素は、前記入力転送構文から得られる増分値を含む請求項１７記載の方法。
【請求項１９】
前記データ要素の受信側は、ストリーミング・データ要素を供給し、前記データ要素の受信側は、出力転送構文を含む請求項１記載の方法。
【請求項２０】
前記データ要素の受信側は、前記ストリーミング・データ要素から値を固定ブロック・サイズで要求する請求項１９記載の方法。
【請求項２１】
各ブロックが受信されると、前記出力転送構文が前記ストリーミング・データ要素値をエンコードする請求項２０記載の方法。
【請求項２２】
前記第１の装置は、バイトの入力ストリームを供給できる装置である請求項１記載の方法。
【請求項２３】
前記第１の装置は、データベース、テープ、ＣＤ、記憶媒体のうちの１つからなる請求項２２記載の方法。
【請求項２４】
前記第２の装置は、バイトの出力ストリームを受信できる装置である請求項１記載の方法。
【請求項２５】
前記第１の装置は、データベース、テープ、ＣＤ、記憶媒体のうちの１つからなる請求項２３記載の方法。
【請求項２６】
一定量のメモリを使用して第１の装置から第２の装置にデータを通信する方法であって、前記デジタル・データがデータ要素とデータ値を定義し、
データ・ストリーム内に記憶すべき限定された数のデータ値を定義し、
前記第１の装置からデータ要素のセットを段階的に読み取り、各データ要素を１回に１つずつ読み取り、
各データ要素から１つのデータ値を抽出し、
限定数のデータ値のみによってデータ・ストリームを生成し、
データ値の所定の限度に達すれば、限定数のデータ値を含むデータ・ストリームを第２の装置に伝送し、
前記データ・ストリームからデータ値を抽出することを含む前記方法。
【請求項２７】
限定された数のデータ値を定義することは、前記第１の装置と前記第２の装置の間の結合を折衝することを更に含む請求項１記載の方法。
【請求項２８】
前記データ・ストリームを伝送することは、前記データ・ストリームとデータ値を含む伝送に先立ってメッセージを定義し、前記メッセージのために適当なオペレーションを決定し、後続の処理のために前記メッセージを待ち行列に入れることを更に含む請求項１記載の方法。
【請求項２９】
前記データ・ストリームから前記データ値を抽出することは、前記データ・ストリーム内に含まれる前記データ値を構文解析するために使用できる転送構文を生成することを更に含む請求項１記載の方法。
【請求項３０】
前記デジタル・データは、ＤＩＣＯＭオブジェクト、ＤＩＣＯＭ画像ファイルまたはＤＩＣＯＭに基づく通信ネットワーク・プロトコルを使用して伝送できるオブジェクトの１つから構成される請求項１記載の方法。
【請求項３１】
データ・ストリーム内に記憶される限定された数のデータ値の定義は、前記データ値の数を５またはそれ以下にセットする請求項１記載の方法。
【請求項３２】
前記データ要素は、プロトコル・データ・ユニットであり、前記データ値は、表示データ値である請求項１記載の方法。
【請求項３３】
前記データは、データ要素のセットを定義するシーケンス・データ要素からなり、受信されるデータ要素のセットを段階的に読み取ることにより、各データ要素は、一回に１つずつ読み取られるようにされる請求項１記載の方法であって、一回に１つずつデータ要素を処理して段階的にデータのセットを処理し、データ要素の全てのセットから全てのデータ要素が処理されるまで段階的に処理する請求項１記載の方法。
【請求項３４】
前記データは、ビットのデータ配列を定義するピクセル・データ要素から構成され、受信されるデータ要素のセットを段階的に読み取ることにより一回に１つずつ各データ要素を読み取ることは、データ要素のブロックとしてバイトのデータ配列を段階的に処理することを更に含む請求項１記載の方法。
【請求項３５】
前記データ・ストリームは、表示データ値の入力ストリームである請求項１記載の方法。
【請求項３６】
前記第１の装置は、ネットワークであり、前記第２の装置は、ネットワークである請求項１記載の方法。
【請求項３７】
前記第１の装置は、ネットワークであり、前記第２の装置は、記憶媒体である請求項１記載の方法。
【請求項３８】
前記第１装置は、記憶媒体であり、前記第２の装置は、ネットワークである請求項１記載の方法。
【請求項３９】
一定量のメモリを使用して第１の装置から第２の装置へデジタル・データを含むファイルを通信する方法であって、前記デジタル・データは、
データ要素とデータ値を定義し、
第１の装置からデジタル・データを含むファイルを受信し、
通信される各データ要素から１つのデータ値を抽出し、
デジタル・データを含む前記ファイルについてデータ値を含む１つのデータ・ストリームを生成し、
前記データ・ストリームに基づいて１つのデータ要素の発信元を生成し、
前記データ要素の発信元を通じて前記データ・ストリームから一回に１つずつデータ値を段階的に処理し、
第２の装置に前記データ値を伝送するステップを含む前記方法。
【請求項４０】
前記ファイルは、ＤＩＣＯＭオブジェクト、ＤＩＣＯＭ画像ファイルまたはＤＩＣＯＭに基づく通信ネットワーク・プロトコルを使用して送信できるオブジェクトのうちの１つからなる請求項３９記載の方法。
【請求項４１】
データ要素発信元を生成することは、一回に１つずつデータ値を段階的に読み取るように構成された入力転送構文を生成することを更に含む請求項３９記載の方法。
【請求項４２】
データ要素の発信元を生成することは、一回に１つずつデータ値を段階的に書き込むように構成された出力転送構文を生成することを更に含む請求項３９記載の方法。
【請求項４３】
前記データ要素の発信元を通じて前記データ・ストリームから一回に１つずつ前記データ値を段階的に処理することは、１つのデータ・ストリーム内に記憶されるデータ値の最大数を５またはそれ以下に定義することを更に含む請求項３９記載の方法。
【請求項４４】
前記データ要素は、プロトコル・データ・ユニットであり、前記データ値は、表示データ値である請求項３９記載の方法。
【請求項４５】
前記データは、データ要素のセットを定義するシーケンス・データ要素により構成され、前記受信されるデータ値のセットを実施可能に処理することにより一回に１つずつ各データ値が読み取られることは、一回に１つずつデータ値を読み取ってデータ値を段階的に処理し、データ要素の全てのセットから全てのデータ値を処理済みになるまで処理することを更に含む請求項３９記載の方法。
【請求項４６】
前記データは、バイトのデータ配列を定義するピクセル・データ要素で構成され、受信されるデータ値のセットを段階的に処理することにより一回に１つずつ各データが読み取られることは、データ値のブロックとしてバイトのデータ配列を段階的に処理することを更に含む請求項３９記載の方法。
【請求項４７】
前記データ・ストリームは、表示データ値の入力ストリームである請求項３９記載の方法。
【請求項４８】
前記第１の装置は、記憶媒体であり、前記第２の装置は、ネットワークである請求項３９記載の方法。
【請求項４９】
前記第１の装置は、ネットワークであり、前記第２の装置は、記憶媒体である請求項３９記載の方法。
【請求項５０】
一定量のメモリを使用してネットワーク内の２つの装置の間でデジタル・データをストリーミングする装置であって、
１つの通信モジュールを含み、この通信モジュールは、
第１の装置からデータ要素のセットを供給するように構成され、更に前記データ要素のセットから一回に１つずつデータ要素を段階的に読み取るように構成されたデータ要素の発信元と、
前記データ要素の発信元から各データ要素を送信するように構成された通信エンジンと、
前記データ通信エンジンからデータ要素を段階的に受信して各データ要素をデータ・ストリームにエンコードするように構成され、前記エンコードされたデータ・ストリームを第２の装置に送信するように更に構成されたデータ要素の受信側を含む前記装置。
【図１】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図４ａ】
【図４ｂ】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図４ａ】
【図４ｂ】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００８−１７８１４０（Ｐ２００８−１７８１４０Ａ）
【公開日】平成２０年７月３１日（２００８．７．３１）
【国際特許分類】
【出願番号】特願２００８−６４４２３（Ｐ２００８−６４４２３）
【出願日】平成２０年３月１３日（２００８．３．１３）
【分割の表示】特願２００２−５２６１０６（Ｐ２００２−５２６１０６）の分割
【原出願日】平成１３年９月４日（２００１．９．４）
【出願人】（５０３０８０４８６）エマジェオン、インコーポレイテッド (1)
【Ｆターム（参考）】
【公開日】平成２０年７月３１日（２００８．７．３１）
【国際特許分類】
【出願日】平成２０年３月１３日（２００８．３．１３）
【分割の表示】特願２００２−５２６１０６（Ｐ２００２−５２６１０６）の分割
【原出願日】平成１３年９月４日（２００１．９．４）
【出願人】（５０３０８０４８６）エマジェオン、インコーポレイテッド (1)
【Ｆターム（参考）】
[ Back to top ]