(57)【要約】  拡張可能なメッセージ送信と相互通信（相互通信）を可能にするシステム、アーキテクチュア及びモデルが提供される。このメッセージ・システムは、ドメインメッセージモデル、開始メッセージモデル、及び通信フォーマットを含むメッセージ送信アーキテテクチュアを使用できる。通信フォーマットは、追加の、あるいは、更に複雑なデータフォーマットを定義する開始メッセージモデルによって用いられる基本データタイプを実施できる。開始メッセージモデルは、相互通信規則（語形変化表）、一般的メッセージ、及び、メッセージとトランスポート属性を更に特定する。一般的メッセージは、その意味、文脈、ドメインメッセージモデルを用いて定義されるペイロード（搭載物）・データを含んでいる。ドメインメッセージモデルは、データと目的タイプとを構築し、データ文脈と関連性とを特定するためのコンテンツ定義モデルと、項目タイプモデルとを含むものである。このように、メッセージ・システムは、異なるメッセージと項目タイプとを生成するために、一般的なメッセージとフォーマットとを用いることができる。【選択図】  図２
2010504690.tif 000002
【特許請求の範囲】
【請求項１】
消費者とプロバイダーの間の相互通信を可能にするコンピュータにおいて実行されるデータモデルであって、このデータモデルは、
消費者とプロバイダー間の相互通信を分類し、１つ以上の一般メッセージタイプを定義するための１つ以上の相互通信規則を定義するトランスポート層と、
１つ以上の一般データフォーマットを定義するデータ層とから構成され、
前記データ層では、少なくとも１つ以上の一般データフォーマットの１つにしたがってフォーマットされたペイロードを含み、前記データ層では、１つ以上の一般メッセージタイプがメッセージに関連付けられた文脈にかかわりなく消費者とプロバイダー間でのメッセージを発生するために用いられることを特徴とするコンピュータにおいて実行されるデータモデル。
【請求項２】
前記データモデルにおける１つ以上の相互通信規則は、少なくとも要求/応答規則、株式規則を伴う要求/応答、リスト/送信規則の１つを含むことを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項３】
前記データモデルにおける１つ以上の一般メッセージタイプは、少なくとも要求メッセージ、リフレッシュメッセージ、更新メッセージ、状態メッセージ、終了メッセージおよび確認メッセージの１つを含むことを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項４】
前記データモデルにおける１つ以上の一般メッセージタイプは、１つ以上の基本属性を含むことを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項５】
前記データモデルにおける１つ以上の基本属性は、少なくとも項目タイプ、ストリーム識別子および拡張ヘッダーの１つを含むことを特徴とする請求項4に記載のコンピュータにおいて実行されるデータモデル。
【請求項６】
前記データモデルにおけるメッセージに関連付けられた文脈は、ドメインメッセージモデルに基づき定義され、そのドメインメッセージモデルは、項目タイプモデルとコンテンツ定義モデルとを含むことを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項７】
前記データモデルにおける項目タイプモデルは、市場価格モデルに対応することを特徴とする請求項6に記載のコンピュータにおいて実行されるデータモデル。
【請求項８】
前記データモデルにおけるメッセージに関連付けられた文脈は、一般メッセージタイプを維持しながら、メッセージに関連付けられたドメインメッセージモデルを変化させて変更されることを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項９】
前記データモデルにおけるトランスポート層は、さらに、少なくともサービス識別子、名称および名称タイプの１つを含む１つ以上のトランスポート属性を定義することを特徴とする請求項1に記載のコンピュータにおいて実行されるデータモデル。
【請求項１０】
望まれた相互通信に対応する相互通信規則を決定し、
要求メッセージをプロバイダーへ送信し、この送信においては、前記要求メッセージは相互通信規則を含み、前記要求メッセージは開始メッセージモデルにより定義される一般要求メッセージタイプに従って生成され、
前記プロバイダーからリフレッシュメッセージを受信し、この受信においては、前記リフレッシュメッセージは、前記開始メッセージモデルにより特定される一般データフォーマットに従ってフォーマットされるペイロードデータを含み、
ドメインメッセージモデルにて定義される文脈に従って前記ペイロードデータを処理し、この処理においては、前記ドメインメッセージモデルは、前記開始メッセージモデルとは無関係であることを特徴とするプロバイダーとの相互通信方法。
【請求項１１】
前記相互通信規則は、関心相互通信を伴う要求/応答であるとの決定に応答して、
イベントストリームを定義し、
前記イベントストリーム内で１つ以上の更新メッセージを受信することを特徴とする請求項10記載のプロバイダーとの相互通信方法。
【請求項１２】
前記一般データフォーマットは、少なくとも要素リスト、フィールドリスト、ベクトル、マップ、シリーズおよびフィルターリストの１つを含むことを特徴とする請求項10記載のプロバイダーとの相互通信方法。
【請求項１３】
前記一般データフォーマットがフィールドリストを含む場合は、前記リフレッシュメッセージに関連付けられたデータ辞書を識別するステップと、
前記データ辞書に基づいて、ペイロードの少なくとも１部を解釈するステップをさらに含むことを特徴とする請求項11記載のプロバイダーとの相互通信方法。
【請求項１４】
前記リフレッシュメッセージ内に特定された全体のカウント値示唆に従ってキャッシュメモリーを割り当てるステップをさらに有することを特徴とする請求項10記載のプロバイダーとの相互通信方法。
【請求項１５】
ドメインメッセージモデルが第二のドメインメッセージモデルが変更された場合、第二の文脈に従って前記ペイロードデータを処理するステップをさらに有し、前記第二の文脈は、前記第二のドメインメッセージモデルにより定義されることを特徴とする請求項10記載のプロバイダーとの相互通信方法。
【請求項１６】
第一の消費者および第二の消費者と、
データフォーマットを定義するデータ層および前記データフォーマットに従ってフォーマットされたペイロードデータを含む一般メッセージタイプを定義するトランスポート層とを含むメッセージモデルと、
第一のドメインモデルおよび第二のドメインモデルとを備え、
前記一般メッセージタイプに従ってフォーマットされた第一のメッセージは、前記第一のドメインモデルにより特定された第一の文脈に基づき前記第一の消費者により処理され、
前記一般メッセージタイプに従ってフォーマットされた第二のメッセージは、前記第二のドメインモデルにより特定された前記第一の文脈とは異なる第二の文脈に基づき第二の消費者により処理されるものであることを特徴とする消費者とプロバイダー間での相互通信を可能にするシステム。
【請求項１７】
前記第一のドメインモデルは、項目タイプと文脈定義モデルとを含むことを特徴とする請求項16記載の消費者とプロバイダー間での相互通信を可能にするシステム。
【請求項１８】
前記文脈定義モデルは、ペイロードデータの少なくとも一部を解釈するために１つ以上のデータ辞書を定義することを特徴とする請求項17記載の消費者とプロバイダー間での相互通信を可能にするシステム。
【請求項１９】
前記トランスポート層は、一般メッセージタイプに関連付けられた少なくとも１つの基本属性を定義し、かつ、前記少なくとも１つの基本属性が少なくとも項目タイプ、ストリーム識別子および拡張ヘッダーの１つをさらに含むものであることを特徴とする請求項16記載の消費者とプロバイダー間での相互通信を可能にするシステム。
【請求項２０】
前記トランスポート層は、キー、状態、サービスの質およびグループ識別子の１つを含む少なくとも１つのトランスポート属性をさらに定義することを特徴とする請求項16記載の消費者とプロバイダー間での相互通信を可能にするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、一般的には、メッセージ送信アーキテクチュア、モデル、及び関連する演算子に関し、特に、定義、構造、アクセス、及びコンテンツの各種タイプと形式の生産を可能にするための再使用可能な送信とデータ抽出とを定義するデータ・メッセージ送信モデルに関する。
【背景技術】
【０００２】
メッセージ送信の速度と便利性により、異なるタイプのデータとメッセージ送信とを支援するための多数のメッセージ送信とトランスポート・プロトコルの向上がもたらされてきた。メッセージ送信とトランスポート・プロトコルとは、それによってコンテンツが通信され処理される標準規格を定義するために使用されてきた。たとえば、ファイナンシャル会社あるいは機関とに用いられるメッセージ・プロトコルは、株価と市場データの効果的な保存と表示のための特定のデータ構造を定義できる。別の例では、トランスポート・プロトコルは、送信装置と受信装置との間で通信が標準化されるように、１つ以上の所定のカテゴリーに相互通信を分類している。このように、各種のソースからデータを受信するアプリケーションやその他のプログラムは、固有のメッセージ送信プロトコルに従ってフォーマットされたデータ送信を処理し解釈するように具体的に構成されねばならない。想像し得るように、アプリケーションは、異なるトランスポートあるいはメッセージ送信プロトコルを用いる複数のソースからの通信とデータを取扱い得るように、数種の機能あるいはプログラムを有することが求められる。
【０００３】
更に、多くの例において、要求されるデータあるいはコンテンツは、メッセージ送信、あるいはトランスポート・プロトコルによって特定されるフォーマットに翻訳されあるいは、変換されることは容易ではなくあるいは全くできなかった。よって、データ、あるいは、コンテンツのある部分は、送信がメッセージ送信、あるいは、トランスポート仕様に一致できるようにメッセージ送信から除かれることがある。
【０００４】
具体的には、ある種のトランスポート・プロトコルは、コンテンツのあるタイプ、あるいは、フォーマットのみを受け入れるものである。ファイナンシャル取引システムでは、たとえば、メッセージ送信プロトコルは、メッセージ゛構造、及び、株式記号、株価のための二つのフィールドのみを定義し得る。よって、消費会社あるいはユーザーは、そのようなメッセージ送信プロトコルを用いるメッセージにおける取引量データを送信することが不可能な場合もある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記理由のために、各種データタイプとフォーマットを扱うための拡張可能なメッセージ送信モデルが求められる。
【課題を解決するための手段】
【０００６】
上述した課題の多くは、ドメインメッセージモデルを用いた拡張性のある柔軟なメッセージ送信アーキテクチュアとモデルとを提供することにより解決される。ドメインメッセージモデルは、潜在的なメッセージ送信アーキテクチュアとモデルを変更することなしに、それらの性能を増幅可能である。メッセージ送信アーキテクチュアおよびモデルは、要素リスト、フィールドリスト、ベクトル、マップ、フィルターのリストとシリ−ズのような一般的なデータフォーマットを定義するためにデータ層を含む一方で、トランスポート、メッセージ送信構文、セマンテック（意味論）を特定するドメインメッセージモデルを可能とする構成体を定義するためのトランスポート層を含むものである。一般的データフォーマットは、通信フォーマットにより実施される基本データタイプ、または、構築ブロックを用いて構築できる。さらに、一般的データフォーマットは、たとえばメーセージ内に各種データフォーマットを合成して別途のデータフォーマット、あるいはタイプを生成するために用いることができる。一方、トランスポート層は、適用可能な文脈をさらに特定するために、ドメインメッセージモデルを許容するメッセージ送信とトランスポート構築とを提供し得る。かくして、トランスポートとデータの層により定義される構造を変更せずに、ドメインメッセージモデルの変形、あるいは、置き換えにより、メッセージとトランスポート構築に関連付けられた文脈は、変更可能である。文脈は、アプリケーションによりデータがどのようにして処理されるかあるいはデータが何を表わすかを特定し得る。
【０００７】
１つ以上の構成において、トランスポート層は、さらに、全ての相互通信を、要求/応答、関心を伴う要求/応答および聴取/送付のような、予め定められた相互通信規則の組に分類できる。要求/応答相互通信は、消費者が寸評データを要求する相互通信を引用する。しかしながら、関心を伴う要求/応答の相互通信は、時間を変更するデ−タあるいは性能の要求に関連させ得る。聴取/送付の相互通信は、プロバイダーについての知識無しに、消費者が公表されたデータを聞いた相互通信に対応する。
【０００８】
他の観点においては、各種の相互通信規則を支援するために、トランスポート層は、メッセージタイプ内の属性とともに、１つあるいは複数の一般的メッセージタイプを定義することができる。たとえば、一般的メッセージタイプは、要求メッセージ、リフレッシュメッセージ、アップデート・メッセージ、状態メッセージ、終了メッセージあるいは確認メッセージを含む。一般メッセージあるいはメッセージタイプは、１つあるいは複数の、タイプ、ストリーム識別子と拡張ヘッダーを含む基本属性によりさらに特徴づけられる。タイプ情報は、メッセージ内に表わされた項目タイプモデルを特定するのに用いられる。一方、拡張ヘッダーは一般的属性が適さないメッセージ属性を取り扱うため使用されるが、ストリーム識別子は、イベントストリーム（たとえば関心を伴う相互通信を伴う要求/応答）用の識別属性として使用される。一般メッセージ、またはメッセージタイプは、更に、キー属性、状態属性、サービス属性の品質、あるいは、グループ識別子属性のような追加の属性と要素とを含むものである。
【０００９】
さらに他の観点においては、ドメインメッセージモデルは、対象タイプ、トランスポート行動、データ表示、意味および関連性を定義するために、メッセージ・アーキテクチュアの中に含まれる。たとえば、ドメインメッセージモデルは、二つの層、すなわち、項目タイプモデル層とコンテンツ定義モデル層とを含む。メッセージとその中でトランスポートされるペイロードデータ（データ本体）は、トランスポート行為、メッセージ構文、メッセージ動作を運ぶ項目タイプに従って構築あるいは構成される。たとえば、項目タイプモデルは、搭載物・データを表示するのに用いられたデータフォーマットを決定する。１つ以上の属性が項目タイプモデルに基づいて要求あるいは定義される。これに対して、コンテンツ定義モデルは、内在する開始メッセージモデル（すなわち、トランスポート層とデータ層）を変形あるいは変更させることなく、データフィールドとデータ自身に対して意味を与える。たとえば、コンテンツ定義モデルは、データを解釈するために用いられる１つあるいは複数のデータ辞書を識別する。コンテンツ定義モデルは、一覧表情報あるいは要求された/オプションのフィールドの定義をもまた含む。
【００１０】
この発明の他の利点および観点は、以下の詳細な記述、請求項、付随する図面から明白に理解される。
【００１１】
この発明は、一例として図示されるものであって、同じ参照数字は同じ構成要素を示す以下の図面によって制限されるものではない。
【図面の簡単な説明】
【００１２】
【図１】本願に記載された１つあるいは複数の態様が実施されるコンピュータの実施例のブロック・ダイヤグラムを図示する。
【図２】本発明の実施形態を示すメッセージ・システムと、構造図である。
【図３】本発明の実施形態による、異なるアクセスポイントを経てサービスプロバイダーと相互通信を行う複数のアプリケーションを示すネットワーク図である。
【図４】本発明の実施形態による、メッセージを定義する複数のモデル層を含むメッセージ構造図である。
【図５】本発明の実施形態による、一般メッセージタイプに関連付けられた基本属性を示す図である。
【図６Ａ】本発明の実施形態によるメッセージと相互通信に関連付けられたトランスポート属性を示す図である。
【図６Ｂ】本発明の実施形態によるメッセージと相互通信に関連付けられたトランスポート属性を示す図である。
【図６Ｃ】本発明の実施形態によるメッセージと相互通信に関連付けられたトランスポート属性を示す図である。
【図７Ａ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図７Ｂ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図７Ｃ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図７Ｄ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図７Ｅ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図７Ｆ】本発明の実施形態による、複数の一般的メッセージタイプを示す図である。
【図８】本発明の実施形態による、記録の二つの形式を示す図である。
【図９】本発明の実施形態による、記録のセットを用いて符号化されたデータを示す図である。
【図１０】本発明の実施形態による、要素リスト・データ形式を示す図である。
【図１１】本発明の実施形態による、フィールドリストのデータ形式を示す図である。
【図１２】本発明の実施形態による、ベクトルデータ形式を示す図である。
【図１３】本願に記載された１つないし複数の態様に従って、マップデータ形式を図示する。
【図１４】本発明の実施形態による、シリーズデータ形式を示す図である。
【図１５】本発明の実施形態による、フィルター・入力データ形式を示す図である。
【図１６Ａ】本発明の実施形態による、ログイン項目タイプモデルの構成成分と使用方法を示す図である。
【図１６Ｂ】本発明の実施形態による、ログイン項目タイプモデルの構成成分と使用方法を示す図である。
【図１６Ｃ】本発明の実施形態による、ログイン項目タイプモデルの構成成分と使用方法を示す図である。
【図１６Ｄ】本発明の実施形態による、ログイン項目タイプモデルの構成成分と使用方法を示す図である。
【図１７Ａ】本発明の実施形態による、市場価格項目タイプモデルの構成成分と使用方法とを示す図である。
【図１７Ｂ】本発明の実施形態による、市場価格項目タイプモデルの構成成分と使用方法とを示す図である。
【図１７Ｃ】本発明の実施形態による、市場価格項目タイプモデルの構成成分と使用方法とを示す図である。
【図１７Ｄ】本発明の実施形態による、市場価格項目タイプモデルの構成成分と使用方法とを示す図である。
【図１８】本発明の実施形態による、サービスプロバイダーと相互通信する方法を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下の各種の実施例に関する記載においては、実施例の一部を形成する図面が参照されるが、この発明の主旨から離れることなく、その他の実施例あるいは構造的、機能的変形が可能であることは理解されよう。
【００１４】
図1は、本発明の実施形態が適用されるコンピュータ環境を示す図である。コンピュータ100で示すようなコンピュータ装置は、データを入力し、出力し、保存し、処理するための各種の構成成分を含んでいる。たとえば、プロセッサー105は、１つないし複数のアプリケーションを実行し、記憶装置115からデータを検索し、あるいは、データを表示装置120に出力するような各種作業を行う。プロセッサー105は、アプリケーション・データ、あるいは、命令が一時的に保持されるランダムアクセスメモリー（ＲＡＭ）モシュール110に接続されている。ＲＡＭモシュール110においては、ＲＡＭモシュール110内の記憶箇所に、同等なアクセス可能性を与えるための順序によって記憶およびアクセスがなされる。コンピュータ100は、コンピュータ100の電源がオフされた後でも、記憶されたデータが存続しあるいは残るようなリードオンリーメモリー（ＲＯＭ）112をも有している。ＲＯＭ112は、コンピュータ100のバイオス（ＢＩＯＳ）の保存を含む各種目的のために用いられる。ＲＯＭ112は、電源遮断と再立ち上げの際であっても情報が持続するように、データと時刻を保持する。さらに、記憶装置115は、アプリケーションとデータファイルを含む各種データのために、長期間記憶が可能である。一例として、プロセッサー105は、アプリケーションが実行中であっても、記憶装置115からアプリケーションを検索し、アプリケーションＲＡＭモシュール110に関連付けられた命令を一時的に記憶できる。
【００１５】
コンピュータ100は、各種の構成成分と装置を介してデータを出力する。上述のように、それらの内の１つは、表示装置120である。別の出力装置は、スピーカ125のようなオーディオ出力装置である。各出力装置120、125は、表示アダプター122とオーディオ・アダプター127のような出力アダプターを含み、そこでは、プロセッサーからの命令を対応するオーディオおよびビデオ信号へ変換する。コンピュータ100は、出力装置に加えて、キーボード130、記憶メディア・ドライブ135、あるいは、マイクロホン（図示せず）のような各種の入力装置からの入力を受信する。出力装置120、125のように、各入力装置130,135は、入力をコンピュータ解読可能/認識可能なデータへ変換するために、アダプター140に関連付けられる。例えば、マイクロホン（図示せず）から受信された音声入力は、ディジタル形式に変換されてデータファイルに保存される。場合により、メディア・ドライブ135のような装置は、ユーザーに記憶メディア（たとえば、ＤＶＤ-Ｒ，ＣＤ-ＲＷ等）との間でのデータの書き込み、読み取りを可能にする入力・出力装置として作動する。
【００１６】
コンピュータ100は、ネトワークでデータを受信、送信するための１つないし複数の通信構成成分を有している。ネットワークの各種タイプは、携帯ネットワーク、ディジタル広帯域ネットワーク、インターネットプロトコル（ＩＰ）ネットワーク等を含んでいる。とりわけ、コンピュータ100は、１つ以上のコンピュータと、あるいは、ＩＰネットワーク上の演算装置と通信するためのネットワークアダプター150を有している。一例では、アダプター150は、企業、または、組織のネットワーク上の電子メール・メッセージ、または、財務データの送信を可能にする。アダプター150は、１つないし複数のネットワーク・プロトコルに関連する命令の１つ以上の組を含む。たとえば、アダプター150は、ＩＰネットワークパケット処理のための命令の第一の組を、携帯ネットワークパケット処理に関連付けられた命令の第二の組と共に含むものである。１つあるいは複数の構成において、ネットワークアダプター150は、コンピュータ100への無線ネットワークアクセスを提供し得る。
【００１７】
この分野の技術者ならば、コンピュータ100のような計算装置は、他の各種の構成成分を含み、図1に示された装置やシステムに制限されないことを理解できる。
【００１８】
図2は、プロバイダー205から消費者のアプリケーション210への情報とサービスを提供するためのメッセージシステムとそのインフラストラクチャを示す図である。プロバイダー205には、データ（たとえば、市場データ、取引情報、医療記録等）を公表するアプリケーションあるいはシステムあるいはそれらの供給サービスあるいは能力を含めることができる。たとえば、取引ゲートウェイ205ｆのようなプロバイダーは、消費者アプリケーションの要求に応じて取引処理を可能にする。一方では、消費者210は、電子部品ニュース（ＥＣＮ）供給部205ｅのようなニュースプロバイダーから見出しや記事を検索できる。他のタイプのプロバイダーは、直接交換供給部205ａ、価値付加データサーバー205ｂ、売主供給部205ｃ、ローカルデータ収納部205ｄ、寄付供給部205ｇを含んでいる。
【００１９】
消費者アプリケーション210とプロバイダー205とは、直接接続を介して、あるいは、市場データシステム215のようなデータシステムを介して通信を確立する。とりわけ、市場データシステム215は、消費者アプリケーション210とプロバイダー205との間で両者間の通信とサービスを可能にするように配置される。ある構成においては、市場データシステム215は、ＲＥＵＴＥＲＳ市場データシステム（ＲＭＤＳ）6.0のようなシステムに対応している。市場データシステム215は、プロバイダー205により消費者アプリケーション210による使用のために公表されたデータの構文解析、分析、フォーマット化、あるいは、処理のためのアプリケーションプロトコルインターフェース（ＡＰＩ）を供給するために用いられる。市場データシステム215は、プロバイダー205から獲得した大規模データあるいは能力を組織化可能なプロキシ（代理）サービスを供給する。それに加えて、プロキシサービスは、異なるプロバイダーを１つあるいは複数のサービスタイプカテゴリーへ区分する識別スキームを提供できる。たとえば、市場データシステム215は、データおよび性能を、ビジネス種類、連結企業、直接交換供給部、交換ゲートウェイ等の基準に従って分類する。プロキシサービスは、概して動的で、間断なく（すなわち、他の処理の中断無しに）生成され、あるいは、取り除かれる。ある構成では、プロキシサービスは、消費者アプリケーション210により動的に見出される。承認と管理のブロック220,225は、データの性能を、データがシステムを流れる間に変更するために使用される。たとえば、承認ブロック220は、データへの消費者のアクセスを拒否する権限を与えるように、データへの承認制御を加える。
【００２０】
図3は、消費者アプリケーション310の、サービスプロバイダー305と市場データシステム315のそれぞれとの間の、通信および取引を可能にする複数のアクセスポイント307,308を含むデータシステム構成を示す。特に、アクセスポイント307は直接あるいは具体的なアクセスポントと成り得るのに対し、アクセスポイント308はプロキシアクセスポイントを構成することができる。すなわち、アプリケーション310ａ、310ｄは、アクセスポイント307に接続することによって、サービスプロバイダー305のコンテンツと性能に直接アクセスできる。それと対照的に、アプリケーション310ｂ、310ｃは、データシステム315あるいはそのプロキシサービスプロバイダーと関連付けられたアクセスポイント308を介してサービスプロバイダー305のコンテンツと性能にアクセスし得る。直接アクセスポイントは、一般に、消費者アプリケーションがそれらの直接アクセスポイントに対応するサービスプロバイダーによって提起されたコンテンツと性能に直接相互に通信することを承認する。一方、プロキシアクセスポイントは、消費者アプリケーションと１つないし複数のサービスプロバイダー間の通信と取引をコーディネイトするデータシステムあるいはプロキシサービスプロバイダーに関連付けられている。プロキシサービスプロバイダーは、サービスプロバイダーの直接供給されないある性能が必要とされるとき、消費者アプリケーション310ｂ、310ｃにより使用される。たとえば、プロキシサービスプロバイダーは、複数のサービスプロバイダーに渡ってコンパイルされたデータの大規模検索のようなサービスの提供に利用される。
【００２１】
現在の多くのシステムにおいて、図2のサービスプロバイダー205のようなサービスプロバイダーに送信され受信されるメッセージは、メッセージのタイプとコンテンツに依存するメッセージ仕様とトランスポート・プロトコルに応じ、あるいは準拠することが要求される。新しいデータとメッセージタイプは、新しい相互通信あるいはメッセージタイプとの互換性を保証するために、介在データシステム（たとえば、図2の市場データシステム215）に通常内蔵されねばならない。本実施態様は、各潜在的なメッセージあるいはデータをあらかじめ定義する必要性を減らすことによって、データシステムの拡張性を向上させるアーキテクチュアとモデルとを提供する。
【００２２】
図4は、３つの機能、すなわち、ドメインメッセージモデル401、開始メッセージモデル402、通信フォーマット403を含む拡張可能メッセージ送信モデルとアーキテクチャを示す図である。通信フォーマット403は、データあるいはタイプに関係なく全ての通信のために定義されるような汎用の符号化フォーマットを定義する。汎用の符号化フォーマットは、たとえば、複数の異なる通信フォーマット（たとえば、市場供給部、Ｑ形式、Ｔｉｂメッセージ、ＡＮＳＩページ、ＳＳＬ，ＲＲＭＰ）が現在用いられている財務アプリケーションにて用いられる。よって、複数の通信フォーマットとの互換性を要求する代わりに、データシステムは、単一の通信フォーマットを採用してもよい。この通信フォーマットは、データネットワーク（たとえば、消費者アプリケーションとサービスプロバイダー間）において複数の構成部品あるいは装置間で送信可能な基本的データタイプまたは構築ブロックを送信実行する。通信フォーマットの基本的データタイプは、より複雑なトランスポートおよびデータフォーマット（詳細は後述される）を構築し、表現するために本実施態様に従って用いられる。通信フォーマットの基本的タイプは、以下のものを含んでいる。すなわち、符号付、符号無しの固定サイズ8ビット、16ビット、32ビット、64ビット整数、特殊値可変サイズ符号無し16ビット、32ビット整数、予約済みビット可変サイズ符号無し15ビット、30ビット、62ビット整数、32ビットあるいは64ビット整数係数を含む実価、6ビット整数指数、ＩＥＥＥ標準754浮動小数点数、時刻と日付、各種長さのバッファー、ＡＳＣＩＩ文字列、ＲＭＴＥＳ文字列、ＵＴＦ8文字列、上記可変タイプまたはその組み合わせの任意のアレイを含んでいる。
【００２３】
本発明の１つあるいは複数の観点によれば、開始メッセージモデル層402は、トランスポートサブ層410とデータサブレイヤー411のような複数のサブ層の上に構築される。サブ層410と411は、各種タイプのコンテンツを定義し、構成し、通信するための性能を提供する。たとえば、トランスポートサブ層410は、それらのメッセージに関連付けられた特定の文法あるいはセマンテック（意味）には無関係にメッセージをカプセル化することに用いられる。特に、トランスポートサブ層410は、ドメインメッセージモデル401により生成された項目タイプモデルとコンテンツ定義モデルとに意味あるいは文脈が従う一般メッセージタイプおよび属性とを定義する。ある場合には、一般のメッセージタイプに関連付けられた文脈あるいは意味は、消費者アプリケーションによりメッセージが処理される方法に対応する。ここで用いられる項目は、サービスプロバイダーから公表され、あるいは利用可能とされるデータ、性能、あるいは、サービスを定義する。項目には、市場価格情報、株取引、価格見積もり等を含んでいる。トランスポートサブ層410は、通信あるいは相互通信を分類するための１つないしは複数の相互通信規則（パラダイム）をさらに定義する。これらの相互通信規則は、要求/応答、関心を伴う要求/応答および聴取/送信を含む。一例においては、要求/応答相互通信は、応答の受信時に完了される情報を定義する。一方、関心を伴う要求/応答は、データの要求あるいは時間とともに変化する性能に関連する。かくして、関心規則を有する要求/応答において、初期応答は、確認メッセージのみを含むことができる。しかしながら、要求しているユーザーあるいは、アプリケーションへの更新応答（すなわち、イベント）を提供する初期応答（イベントストリームが生成された）の後でも、相互通信は活性化されたままである。たとえばイベントストリームは、定期的あるいは直ちに変動しがちな株式の市場価格またはニュースの見出しを、提供できる。聴取/送付（すなわち、公表/申し込み）相互通信は、可能な消費者についての知識も持たないサービスプロバイダーからの送信をカバーするものである。その代わりに、消費者は、サービスプロバイダーにより公表され/送られたデータに対して、匿名で申し込みすることあるいは聴取することができる。
【００２４】
代わりにあるいはそれに追加して、トランスポートサブ層410は、各種の相互通信規則に関連付けられた１つ以上の一般メッセージタイプをさらに定義できる。そのような一般メッセージタイプは、要求メッセージ、リフレッシュメッセージ、更新メッセージ、状態メッセージ、終了メッセージ、確認メッセージを含む。リフレッシュメッセージは、属性情報あるいはコンテンツを持つ要求メッセージに応答するように用いられる。リフレッシュメッセージは、既に開放されたイベントストリームのデータを非同期的に変更するために用いられる。一方、更新データは、既に開放されたイベントストリームに関連付けられた非同期データイベントに対応する。１つあるいは複数の構成において、更新メッセージは変更された初期メッセージ内でデータを変形するのに用いられるが、リフレッシュメッセージは、要求に応じて消費者に送られる初期メッセージを定義する。状態メッセージは、既に開放されたイベントストリームに関連付けられた非同期属性変化を表示するために用いられる。たとえば、状態メッセージは、データまたはイベントストリームが別のプロバイダーに再送信されると、送信される。確認メッセージが発行済みの要求あるいは閉鎖要求/メッセージを確認するために用いられる一方で、さらに、終了メッセージは、現存するイベントストリームのための発行済の要求を閉鎖するために使用される。ドメインメッセージモデル（たとえば、図4のモデル401）を用いると、一般メッセージタイプは、内在するセマンテック（意味）、構造、またはコンテンツを維持しながら、各種のメッセージとデータとを送るのに用いられる。一例では、財務データは、ニュースレポートを定義し送信するのに用いられるように、同じ一般メッセージタイプと送信セマンテックを用いてトランスポートされ定義される。文脈と送信されたデータが処理され定義される方法とは、トランスポートとデータの層により定義されるセマンテック、構文、構造を変化させ、あるいは、変更する必要無しに適応可能なドメインメッセージモデルを変化させあるいは置き換えることによって変形され得る。言い換えれば、メッセージの文脈を変化させることは、トランスポート層とデータ層とを維持しながら実行し得るものである。従って、コンテンツメッセージモデルの拡張性は、コンテンツメッセージモデルが用いられるための文脈とは無関係である。
【００２５】
一般メッセージタイプのそれぞれは、１つないし複数の基本属性セットにより特徴付けられている。そのような基本属性の例は、図5に示されたように、タイプ、ストリーム識別子、拡張ヘッダーを含む。ストリーム識別子が、アプリケーションが全キーの代わりに異なる値（たとえば、符号無し32ビット値）を持つイベントストリームを定義するのを容認するための最適化特性として用いられる一方で、タイプ属性は、メッセージ内で表示される項目タイプモデルを識別するのに一般的に用いられる。全キーの代わりにストリーム識別子を用いることは、帯域幅の使用を節約することになる。さらに、メッセージに関連付けられた項目タイプモデルを識別することにより、消費者、あるいは、メッセージの受信者は、メッセージ内に含まれたデータを適正に構文分析し処理することを可能にする。そのように、各種の実社会における対象（たとえば、見積もり、注文書等）は、ここに述べた一般メッセージモデルを用いて送信される。それに加えて、メッセージ属性がいずれの一般メッセージ属性内でも適さないと確認される１つないし複数のイベントにおいて、拡張ヘッダーが、この情報を保存するために用いられる。１つあるいは複数の基本属性は、項目タイプモデルの選択あるいは仕様に依拠して一層選択が自由となる。
【００２６】
本発明の構成においては、図4のサブ層410のようなトランスポートサブ層により定義された一般メッセージタイプは、メッセージ属性に加えてトランスポート属性を含む。トランスポート属性は、そこに含まれるメッセージより、むしろ送信を特徴付けるために用いられる。たとえば、図6Ａ-6Ｃは，１つあるいは複数の一般メッセージタイプに含まれるキー、状態、サービスの品質（ＱｏＳ）を含む複数のトランスポート属性とモデルとを示している。図6Ａのキー属性は、サービス識別子、要求された情報の名称、名称のタイプ、オプションのコンテンツ/フォーマット、異なる情報（たとえば、バージョン番号）、他の識別メカニズム（たとえば、問い合わせ、複雑なフィルター等）、不明瞭なバッファーを特定する不明瞭なデータフォーマットのような情報を特定するためのフィールドまたはデータ要素をさらに含んでいる。不明瞭なバッファーの使用の一例は、歴史的データベースへ、ＳＱＬ/ＸＭＬ問い合わせを出すことである。別の例では、フィルターフィールドは１つあるいは複数の望まれるコンテンツを選択するための選択可能値の特定に使用される。とりわけ、消費者が辞書のタイプが何かを判断するための要約された情報のみを求めた場合は、対応する値は、フィルターフィールドで消費者によって特定される。
【００２７】
図6Ｂは、相互通信を特徴付けるように用いられる各種の状態表示器を定義する一般状態モデルを示す。状態情報は、ストリーム状態、データ状態、コード、テキストを含む複数のカテゴリーに分割される。関心規則を有する要求/応答を用いる際、ストリーム状態は、イベントストリームの状態に関する情報を伝達する。しかしながら、非ストリーム規則（たとえば、要求/応答）では、状態は、“非トリーミング”に設定される。“特定されない”ストリーム状態は、状態は特定されなかったことあるいは要求が保留されていることを示す。“開放”ストリーム状態はイベントストリームが活発に開放されていて、非同期イベントがいつでも発生しうることを特定する。一方、“閉鎖”状態は、“開放”状態の反対の状態を意味するものである。換言すれば、“閉鎖”状態は、ストリームが閉じられており、プロバイダーを利用することはできないことを示している。“閉鎖回復”状態は、消費者アプリケーションにより再開される閉鎖ストリームに対応している。ストリーム状態は、さらに、“再送信”された状態に設定され、その状態は、要求された情報あるいは性能が別のサービスプロバイダーまたは場所で利用可能であることを表わしている。その情報あるいは性能が利用可能であるようなサービスプロバイダーあるいはそのような利用可能な場所はキーによって特定される。
【００２８】
データ状態は。イベントストリーム内での応答により伝達されたデータ品質を表わすのに用いられる。データストリームは、特定されていない（すなわち、データが特定されていない）状態、ＯＫ（すなわち、データ状態が有効あるいは更新されている）状態および疑わしい（すなわち、データは未知あるいは古い）状態を含んでいる。ストリーム状態とデータ状態情報に加えて、状態符号は、ストリームあるいはデータ状態に対する追加の情報を供給するために定義される。これらの状態符号は、何もない（付加情報は入手不能）、見つからない（項目はプロバイダーから入手不能）、時間切れ（要求が既に時間切れ）、無効な議論（要求内に持ち込まれた無効な議論）、使用エラー（メッセージあるいは、メッセージ内容の不規則な使用）、先取り（別のイベントストリームに余地を生成するために先取りされたイベントストリーム）、ジャストインタイム方式（ＪＩＴ）合成開始（必要の都度に行われるデータの合成）、実時間への復旧（ジャストインタイム方式の合成の終了）、障害迂回開放（サービスにおいてソースミラーリング障害迂回が開始された）、障害迂回完了（１つのプロバイダーから別のプロバイダーへサービスのための復旧）、ギャップの検出（データ発信者からのメッセージ・ギャップの検出）、リソース無し（要求を扱うリソースがこれ以上存在しない）、多すぎる項目（許容されるイベントストリームの数がユーザーあるいは、消費者にとり既に最大数に到達）、既に開放（イベントストリームはすでに消費者に開放されている）、未知のサービス（キーにて特定されるサービス識別子は存在していない）、開放されていない（イベントストリームが開放されず終了できない）を含んでいる。さらに、テキストは、また、ストリームあるいはデータ状態の説明情報を供給する状態モデルに含まれている。
【００２９】
図6Ｃは、データあるいはイベントをサービスの層に分類するためのＱｏＳモデルを示す図である。ＱｏＳは、一般に二つの特性、時間経過、速度を含んでいる。速度が（ストリーミングイベント用の）データにおける変化の最大周期を示す一方で、時間経過（timeliness）、データの経過年を表わしている。時間経過は、二つの特性、実時間と遅延とに分解される。実時間は、データには全く遅れが生じないことを暗示している。換言すれば、データは常に更新され、データが発生するとすぐにプロバイダーに送られる。一方、遅延は、データが要求情報の歴史的な観点を反映していることを示している。データが遅延すると、ユーザーまたは消費者がその遅延を補償できるように遅延時間属性あるいは特性が定義される。
【００３０】
ＱｏＳにて使用されるように、変化の速度は、時々刻々方式と時間合成あるいはジャストインタイム方式（ＪＩＴ）合成に分類される。時々刻々方式は、消費者が内容についての全ての更新あるいは変化を受信することを暗示する一方、合成は、複数のイベントが、コンテンツの最終視聴を維持するような方法で結合されることを暗示している。合成は、時間、または、チャンネル容量、通信回線混雑状態のような他のパラメータに基づいてなされる。時間合成とジャストインタイム方式合成とは、データが合成される時間間隔に関して異なるものである。とりわけ、時間合成は、ジャストインタイム方式合成が必要に応じた合成に関連する一方で、標準の時間間隔での合成を意味している。よって、一例においては、消費者は、要求の中で、実時間データ、あるいは遅延情報を要求するか否か、時々刻々方式のプロトコルあるいは合成のメカニズムに従って更新されるか否かを特定し得る。実時間データあるいは時々刻々方式のデータは、消費者またはユーザーに、遅延したあるいは合成されたデータサービスよりも高い料金を課すことができる、より高度なサービスとして分類されている。
【００３１】
送信を特徴付けるように用いられる別のトランスポート属性は、グループ識別子である。グループ識別子は、イベントストリームが属する（たとえば、関心相互通信を伴う応答/要求のための）項目グループを特定し得る。項目グループは、プロバイダーの優先権と必要性とに従って定義される。一例では、プロバイダーは、データサービスのために複数のデータリンクを維持する。そのように、第一のデータリンクに対応する複数の消費者の要求は、第一の項目グループに分類される。同様に、第二のデータリンクに対応する消費者の要求は、第二の項目グループに分類される。データリンクが疑わしくなると、プロバイダーは、疑わしいデータリンクに対応する項目グループにおける全てのイベントストリームの状態をマークする。項目グル−プの割り当ては、初期リフレッシュメッセージを含む各種時刻で、消費者との間で確立あるいは連絡される。
【００３２】
トランスポートサブ層（たとえば、図4のトランスポートサブ層410）により定義される一般メッセージタイプは、１つ以上のメッセージとトランスポート属性によりそれぞれ定義され得る。たとえば、図7Ａは、複数のデータフィールドと要素を含む要求メッセージを示す。図5に関して記載された基本属性に加えて、要求メッセージモデル700は、搭載物データとサービス要求/データストリームの比較重要性を特定する一般フォーマットを表示するデータフォーマット仕様を含む。要求メッセージモデル700は、また、許容可能なＱｏＳウィンドウを定義するための最良のＱｏＳフィールドと最悪ＱｏＳフィールドを用いるサービス品質（ＱＯＳ）を特定する。要求キーは、さらに、メッセージモデル700に含まれ、コンテンツあるいは要求される性能を識別する。ペイロード（搭載物）データは、データフォーマット要素により特定されたフォーマット内に符号化された行データ・バッファーを表わす。たとえば、取引要求メッセージは、ペイロード（搭載物）データフィールド内の取引情報を含む。
【００３３】
本発明の１つあるいは複数の実施形態において、要求メッセージモデル700は、ストリーミング、更新中のキー、更新中の合成情報、リフレッシュ無しのような、１つあるいは複数のオプション要求を含む。たとえば、ストリーミング・オプションは、要求（たとえば、関心ある規則を有する要求/応答）に基づくイベントストリームを生成する要望に対応している。更新中のキーは、符号化された全ての更新メッセージキーを消費者が希望していることを示す。更新オプションにおける合成情報は、更新に含まれる更新合成情報を消費者が望んでいることを特定するものである。これに対して、リフレッシュ無しオプションがリフレッシュ無しのメッセージ（すなわち、応答）が必要とされ、あるいは要望されていることを示すのに用いられる。消費者は、要求メッセージが以前の要求に関する優先情報を更新するためにのみに用いられるような場合においては、応答は望まないであろう。要求メッセージモデル700により表示される１つないし複数のフィールドは、オプション（すなわち、メッセージ内で設定／定義される必要のないもの）である。
【００３４】
サービスプロバイダーは、図7Ｂのリフェレッシュメッセージモデルにて定義されるリフレッシュメッセージを介してリクエストモデル700に従って構築された要求メッセージに応答できる。リクエストモデル700と同様に、リフレッシュメッセージモデル720は、タイプ、ストリーム識別子、拡張ヘッダーのような基本属性を含むものである。さらに、リフレッシュメッセージモデル720は、ＱｏＳ仕様、状態情報、グループ識別子、キー情報のようなトランスポート属性をも含む。ペイロード（搭載物）データは、データフォーマットフィールド内に特定されるフォーマットに従って符号化された要求されたデータをバッファーに記憶する。リフレッシュメッセージモデル720は、要求された項目データイベントストリームへのアクセスを必要とする要求を定義する承認表示フィールドを含む。たとえば、ファイナンシャル予測へのアクセスがある人物に制約された場合、認証情報（たとえば、ログイン/パスワード）がデーダを検索するために要求される。リフレッシュメッセージモデル720は、イベントストリームに関連付けられた最後のシークエンス番号を示すための一連番号をさらに含むものである。一連番号は、消費者が適切な順序でイベント（データ）の時間列を構築することを容認する。
【００３５】
さらに、リフレッシュメッセージモデル720は、勧誘型、リフレッシュ完了、トラッシュキャッシュ、キャッシュに保存しない、およびプロバイダー主導オプションを含む１つないし複数のリフレッシュオプションに関連付けられる。勧誘型表示はメッセージが要求への勧誘型リフレッシュであるか、既存のイベントストリームへの非勧誘型リフレッシュであるかに関連する。リフレッシュフラグは、リフレッシュあるいは非勧誘型リフレッシュが完了したか否かを示す。たとえば、いくつかの項目タイプモデル（ドメインメッセージモデルに定義されるように）、データを伴うリフレッシュ完了フラグセットを有する単一リフレッシュを要求する。トラッシュキャッシュオプションは、過去のペイロード（搭載物）データが消去される必要があるか否かを特定する表示子である。一方、キャッシュに保存しないオプションは、消費者に現在のリフレッシュに含まれるデータをキャッシュしないように命令する。さらに、プロバイダー主導オプションを含むことは、要求（すなわち、放送モード）無しに、消費者へ項目が送られることを示すものである。１つないし複数の上記オプションにおいて、属性とメッセージ要素は、オプションと成り得るものである。
【００３６】
更新メッセージモデル740は、図7Ｃに示すように、イベントストリームに関連付けられた非同期データイベントを表示するように構成された更新メッセージを定義する。更新メッセージは、項目データモデルあるいはドメインに依存する、異なる使用あるいは意味に割り当てられる。更新メッセージモデル740は、場合によっては、多くのリフレッシュメッセージモデル720と同じメッセージ要素とフィールドとを共有する（図7Ｂ）。たとえば、更新メッセージモデル740は、承認表示と一連番号のようなフィールドと要素をも含んでいる。更新メッセージモデル740は、更新タイプと合成情報のような追加のフィールドを含んでいる。合成情報は、上記イベントに適用されている合成論理に関連する情報を提供する。他方、更新タイプは、更新が対応している更新のタイプを定義するために用いられる。１つまたはそれ以上の更新タイプは、特定の項目タイプモデルにより定義される。
【００３７】
それにくわえて、更新メッセージモデル740は、キャッシュしない、合成しない、波紋（リップル）を立てない、プロバイダー主導を含んだ複数のオプションに関連付けられている。リップルを立てないオプションの選択あるいは使用は、更新内の任意のフィールドでのリップルを制約する。一方、合成をしないことは、消費者又はメッセージの受信者に対して、更新データ内のペイロード（搭載物）データを合成しないよう命令する。たとえば、サービスプロバイダーは、消費者にニュースの見出しを合成しないように命令を出せる。
【００３８】
図7Ｄは、データの状態あるいはイベントストリームを変形するための状態メッセージモデルを示す。新しい状態は、状態メッセージモデル760の状態フィールド内に特定される。たとえば、イベントストリームの状態は、“開始（オープン）”から“再指示（リディレクト）”に変更される。状態メッセージモデル760は、プロバイダーに、単一メッセージを用いるグループ内での複数イベントストリームの状態の変更を許可する。状態モデル760は、トラッシュキャッシュとプロバイダー主導のようなオプションをさらに含む。
【００３９】
図7Ｅと7Ｆとは、それぞれ、終了（close）メッセージと確認メッセージとに対応するモデルを示す。終了メッセージモデル780は、基本メッセージ属性と確認オプションとを含む。確認オプションは、それを受信あるいは適用したときには、プロバイダーが終了を確認すべきことを示す。こうして、消費者がイベントストリームの終了を求める際は、消費者は、プロバイダーが確認オプションを介して要求を確認するよう要求できる。確認メッセージモシュール790は、ある場合においては、消費者から終了要求メッセージを確認するために用いられる確認メッセージを定義する。確認メッセージモシュール790は、確認識別子（すなわち、ＡｃｋＩＤ）と、ＩｓＮａｋオプションを含む。ＩｓＮａｋオプションが設定されると、メッセージは、否定的確認メッセージとして扱われる。さらに、ＩｓＮａｋオプションの使用起動は、さらに、メッセージがＮａｋコードとＮａｋテキストとを含むことを示す。
【００４０】
上記一般メッセージタイプはいずれも、消費者とプロバイダーのいずれかあるいは双方から情報を作成し分配するために用いることができる。すなわち、要求は、プロバイダーから消費者へ送信でき、また、その逆の送信もできる。開始メッセージモデルの柔軟性は、情報の2方向通信と分配とを可能とする。
【００４１】
要求、リフレッシュ、更新メッセージのそれぞれに含まれるペイロードデータは、１つないし複数のデータフォーマットあるいは演算子（abstraction）に従って定義される。これらのデータフォーマットあるいは演算子は、一般に開始メッセージモデルのデータサブレイヤー（たとえば、図4のデータサブレイヤー411）によって管理される。１つまたはそれ以上の構成によれば、モデル402のような開始メッセージモデルは、より複雑なデータフォーマットとタイプとを定義するための通信フォーマット403のような通信フォーマットにより実施される基本データタイプを使用できる。既に述べたように、通信フォーマット403は、符号付整数値、ＩＥＥＥ754浮動小数点数、ＵＴＦ８文字列のような基本データタイプを含む。データフォーマットとタイプ用のデータサブレイヤーにより供給されるその他のデータ構造は、記録セットと要約データとを含む。とりわけ、要約データは、複数のデータフィールドあるいはデータ構造への入力に関連する情報を保存できる。たとえば、要約データは、データ構造内に保存される複数の株価に関連付けられた通貨を特定するのに用いられる。よって、データ構造へ各株価記入することにより、現在情報を個々に保存する必要は生じない。
【００４２】
記録セットは、記録データの帯域幅を最適化するためにデータサブレイヤーにより定義される。記録データは、フィールド/値のペアにより一般的に表示される。たとえば、フィールド成分は、値が入力識別子に対応する情報またはデータを保存する一方で、入力識別子を保存する。たとえば、フィールド/値のペアは、株価データを保存するのに使用される。すなわち、フィールドの成分は、一方で、値が識別された株式の価格の値に対応するのに対し、株価フィールドを保存するために使用される。図8は、２つの記録に基づくデータ構造、すなわち、一方の標準記録符号化の上に構築されたデータ構造と、他方の記録セット符号化を用いて構築されたデータとを示す。標準記録符号化構造805は、記録データを、繰り返すフィールド成分と値のペアとして保存し符号化する。これに対して記録セット符号化構造810は、値816からフィールド成分815とそれらのデータタイプを分離させて、保存し符号化する。こうして、単一の記録セット定義、あるいは、入力定義815は、複数のフィールド成分815とそのタイプによって送られ/定義され／保存される。その後、複数の記録は、各記録に対して、単一の入力定義815と１つの入力データ810により表現される。
【００４３】
上記の代わりに、あるいは、上記に加えて、標準記録符号化と記録セット符号化とは、図9に示すように、単一メッセージ内に混ぜ合わせることも可能である。このことは、一方では、開放システムの拡張性を支援しながら記録セットが共通の場合のために定義されるのを承認することになる。たとえば、図9において、単一入力定義901は、記録905,906,907と908の4組のために生成される。記録905,906と908とは、入力定義901により定義されたフォーマットに全て対応あるいはそれを順守している。しかしながら、記録907は、入力定義901にて定義されているだけでなく、入力定義901には定義されない付加データをも含むことができる。したがって、付加データ値909は、標準記録符号化を用いて符号化され、記録907の符号化された部分の記録セットに加えられる。
【００４４】
記録セットは、地域的に、あるいは、全地域的に識別され定義される。地域性は、入力データとして同じメッセージ内で送られ/定義される入力定義に関連する。それと対照的に、全地域性では、たとえば、記録セット辞書にて一度送信され/定義された、多くの異なるメッセージ（すなわち、記録）に亘り、再使用された入力定義を参照する。たとえば、全地域性の記録セットは、資産評価あるいは取引の符号化のために使用される。さらに、１つあるいは複数の構成では、消費者アプリケーションは、符号化フォーマット間の相違を知る必要はない。そのような構成において、復号化ライブラリーは、異なって符号化された記録データを、１つの符号化フォーマット、あるいは他の符号化フォーマット、すなわち、標準記録符号化あるいは記録セット符号化に変換する。
【００４５】
データサブレイヤーは、さらに大規模記録データを管理可能な断片あるいはメッセージに機能的に分割するように、細分化機能をサポートする。受信アプリケーションの受信と復号化処理を簡素化するために、細分化は、記録データ内に論理入力境界に基づいて生成される。受信アプリケーションは、こうして、全ての断片を待つ必要は無く、個々の断片を受信し、それらの断片を復号することができる。本発明の１つあるいは複数の実施態様によれば、受信アプリケーションに対して全体のカウント値の示唆がさらに提供される。全体のカウント値示唆は、全ての断片に渡っての構造内への入力の個数を示す。受信アプリケーションは、全体のカウント値の示唆を（データをメモリーへ保存する）キャッシングのために予め十分なメモリーを割り当てるために使用する。
【００４６】
トランスポートサブ層とそれによって定義される一般メッセージタイプモデルと同様に、データサブレイヤーは、各種タイプとコンテンツの形式をモデル化するために用いる１つあるいは複数の一般データフォーマットをも定義する。そのような一般データフォーマットは、要素リスト、フィールドリスト、ベクトル、マップ、シリ−ズおよびフィルターリストを含む。たとえば、図10は、複数のフィールド/値のペア入力1005を保存する要素リスト構造1000を示す。フィールド/値のペア入力1005は、要素リスト1000に連続して保存され、それぞれ文字列に基づくタグ1010、データタイプ1015、値/データ1020のような属性を含む。データタイプ1015は、データフィールド1020に保存されたデータのタイプを識別するのに対して、文字列に基づくタグ1010は、フィールドの名称を特定するのに使用される。要素リストの番号は、キャッシング論理を最適化するために要素リスト1000に関連付けられあるいは割り当てられる。たとえば、キャッシング論理により行われる想定は、同じ要素リスト番号を持つ要素リストは、同じ入力/タグ/タイプを含むとされる。それに加えて、要素リスト番号は、あるサービスプロバイダーに固有のものである。リスト1000内に保存された入力、あるいは記録の数を追跡するために、カウント値が要素リスト1000内に定義される。
【００４７】
図11は、記録ベースのコンテンツを保存するためのフィールドのリスト構造を示す。フィールドリスト1100は、フィールド識別子/値ペアをフィールド入力1105に保存する。フィールド識別子は、データ辞書1110に対応する符号付の2バイト整数である。データ辞書1110を用いることにより、フィールド識別子1112のようなフィールド識別子1112は、タグ名、データタイプと最大キャッシュ長へ変換される。フィールドリスト1100の各入力1105は、各フィールド識別子、たとえば、フィールド識別子1112に関連付けられたデータ1113を保存する。データ辞書1110から検索された情報は、データ1113へ意味と構造とを提供する。要素リストと同様に、フィールドリスト1100は、フィールドのリスト番号とカウント値を含む。さらに、フィールドリスト1110は、入力1105を処理あるいは解釈するのに必要な１つないし複数の辞書を特定する。辞書は、サービスプロバイダーあるいは消費者アプリケーションにより生成され又は定義される。１つまたはそれ以上の構成によれば、データ辞書は、フィールドのリストに保存されたデータあるいは項目タイプに関連付けられたコンテンツメッセージモデルによって特定される。
【００４８】
図12は、位置指向性入力（すなわち、ベクトル入力）を保存するためのベクトルデータ構造を示す。各ベクトル入力の位置は、索引値により定義される。たとえば、索引値“0”（ゼロ）はベクトルの最初の位置に対応する。ベクトル1200のようなベクトルは、ベクトル1200内に保存される全ての入力のデータフォーマットを特定する。言い換えれば、全ベクトル入力1205は、同じデータフォーマットを有するように要求される。各種のデータフォーマットは、フィールドリスト、要素リスト、マップ、シリーズおよびフィルターリストを含むベクトルとして保存される。ベクトル1200は、全ての入力1205を供給するコンテンツ、あるいは、情報用の要約データをも含む。あるいはこれに加えて、もし、ベクトル入力1205が同じ記録データ構造（たとえば、同じフィールド/値ペア）によって定義されるならば、記録セット定義は、ベクトル1200により特定され、そして、ベクトル入力1205を特徴付けるのに用いられる。ベクトル1200内の入力1205は、さらに設定され、更新され、あるいは、クリアされ、かつ、きめ細かい制御を加えるために個々の承認表示を含んでいる。ベクトル1200内の入力1205は、ベクトル1200から１つあるいは複数の入力をセットし、クリアするための挿入と消去のような保存動作を支援する。ベクトル1200のようなベクトルは、リフレッシュメッセージとして送信された際、さらに細分化される。そのように、ベクトル1200は、受信アプリケーションにおけるキャッシングを可能にするために全カウント値示唆を特定する。
【００４９】
図13は、キーを用いた入力を保存するマップデータ構造を表す。マップ1300内の各マップ入力1305は、任意の基本データタイプの形式を採るキーにより識別される。たとえば、マップ入力1305は、ＡＳＣＩＩ文字列コード、バイナリーバッファーキーあるいは実番号キーにより定義される。ベクトルについては、マップ1300のようなマップはマップ入力1305の管理のために、加算、更新あるいは除去機能性を含む。さらに、各マップ入力1305は、個別の承認表示を含む。マップ入力1305は、マップ1300により特定されるものと同じデータフォーマットを有する。
【００５０】
図14は、暗示的な索引を用いて入力1405を組織化するシリーズデータ構造を表す。シリ−ズ1400のようなシリーズは、マップおよびベクトルに類似しているが、典型的には、入力1405が１つまたは複数のフィールド（たとえば、時刻、データ等）により黙示的に索引付けされる、繰り返し構造のデータを表示あるいは保存するために用いられる。すなわち、シリーズ入力1405は、明白な識別を有することはない。シリーズ1400は、ベクトルやマップのように、データフォーマット仕様、カウント値、記録セット定義、要約データ、全体のカウント値示唆を含む。データ記録の細分化は、シリーズ1400にて支援される。
【００５１】
図15は、ビットマップ識別子に基づくフィルターリスト入力1505を組織化し保存するよう構成されたフィルターリストデータ構造を示す。フィルターリスト1500のようなフィルターリストは、プロバイダーにより一般的に定義され、情報を選択可能な入力1505に分解するように用いられる。可能なフィルター入力1505の数は、識別子のサイズによって定義される。すなわち、識別子が8ビット符号無し整数に対応するならば、32個の入力のみがフィルターリスト1500に保存される。
【００５２】
ここで述べられている一般的なデータフォーマットは、他の一般的なデータフォーマット内に含まれあるいは保存される。すなわち、一般なデータフォーマットは、互いにネスト（入れ子）される。たとえば、ベクトルデータ構造は、フィルターリストデータ構造内に保存され、また、その逆の場合もあり得る。別の例では、図10は、要素リスト1000内のフィールド/値ペア入力1005のデータ1020内においてネストされたフィールドリスト、要素リスト、ベクトル、マップ、シリーズおよびフィルターリストを示す。こうして、本発明の上述した追加的かつ代替的な態様によれば、ネストされたデータフォーマットは、一般的なデータフォーマットの深さと幅に亘って検索され、復号される。
【００５３】
再度、図4を参照すると、ドメインメッセージモデル401は、実世界の対象（たとえば、市場価格とニュースの見出し）をそれらの要求と特性にしたがって定義するために用いられる。たとえば、ニュース見出し対象が主題、著者、新聞のソース情報を含むのに対し、市場価格対象は、株式記号と株式価格を含んでいる。したがって、対象は、メッセージドメインモデル401を用いて、特に固有の産業、組織あるいはアプリケーションのニーズに適するように定義される。とりわけ、ドメインメッセージモデル401は、開始メッセージモデル402により供給される上記の対象を構築する一般的メッセージタイプとデータモデルとを用いる。たとえば、ドメインメッセージモデル401は、対象タイプ、対応する送信行為あるいはデータ表示（すなわち、データフォーマット）を定義する項目タイプモデル420を含む。これらの対象の概念と構成成分は、開始メッセージモデル402により展開され支援される抽出、モデル、及び概念を用いて定義される。項目タイプモデル420はさらに、対象タイプ、対象タイプの送信行為およびデータ表示（たとえば、データフォーマット）の構造あるいはコンテンツを定義するために用いられる。ドメインメッセージモデル401はさらに、項目タイプモデル420により使用されるフィールド意義と関係とを定義するために項目タイプモデル420上に構築されるコンテンツ定義モデル421を含む。コンテンツ定義モデル421は、データ辞書、一覧表情報と、要求された／オプションのフィールド定義を含む。一覧表情報は、対応するデータあるいはデータのタイプに列挙されたフィールドを変換するために用いられる。それに加えて、項目タイプモデル420は、或る場合においては、コンテンツ定義モデル421のように、多くのコンテンツ定義モデルに関連付けられる。
【００５４】
図16Ａ-Ｄは、開始メッセージモデルの概念、抽出、モデルを用いてで生成したログイン項目タイプモデルの各種態様を示す。図16Ａは、サービスプロバイダーへの認証されたアクセスに使用されるログインタイプモデル1600の構成成分と要素とを示す図である。ログインタイプモデル1600はさらに、全ての相互通信タイプの構築のためのアクセスポイント（たとえば、図3のアクセスポイント307）内の文脈を構築する。すなわち、ログインタイプモデル1600は、ログイン項目タイプに関連付けられたメッセージとデータへ適用されるある情報タイプとメッセージとを定義する。たとえば、ログインタイプモデル1600は、ログインタイプに関連付けられた相互通信に利用可能なメッセージ種類1605を定義する。ログインタイプモデル1600は、さらに、メッセージキー要素1610内に保存された名前フィールドに関連付けられたデータフォーマットあるいはタイプを特定する。メッセージキー1610の名前フィールドは、名前タイプ1615、たとえば、ドメイン・モデル（すなわち、ログイン項目タイプモデル1600）により特定されたユーザー名、メールアドレスにしたがって定義される。
【００５５】
図16Ｂは、図16Ａのログインタイプモデル1600に関連付けられた送信セマンテック（意味論）を識別するテーブルである。送信セマンテックは、ドメインメッセージモデルにより承認あるいは、支援された各種の相互通信を定義しあるいは特定する。たとえば、ログインタイプモデル1600は、ログイン項目タイプに関連付けられた相互通信は、関心相互通信規則を伴う要求/応答に従うことを示している。ログインタイプモデル1600は、開始メッセージモデルにより定義される１つないし複数の一般的メッセージタイプ（たとえば、要求、リフレッシュ、状態等）の意味あるいは文脈をさらに定義付けする。本発明の１つないし複数の実施形態によると、一般的メッセージは、送信とデータの層により定義されるメッセージ送信セマンテック、データフォーマットを維持しあるいは用いながら、ドメインメッセージモデルに基づく意味が提供される。一例のように、ログインタイプに関連付けられた要求メッセージは、ログインタイプモデル1600によって定義される。さらに、要求メッセージのペイロードは、ログインタイプモデル1600によって、ログインオプション/パラメータとして特徴づけられる。したがって、受信消費者、装置あるいはユーザーは、そのような定義と意味を、各種のメッセージタイプとそこに保存されるデータを復号あるいは解釈するために適用し得る。
【００５６】
図16Ｃは、ログイン項目タイプに関連付けられた要求と応答データにより用いられるデータフォーマットを示す。本発明の１つあるいは複数の実施形態において、ログイン項目タイプの要求と返答は、要素リスト（たとえば、図10の要素リスト1000）を用いてフォーマットされ得る。よって、各要求と応答（たとえば、メッセージのリフレッシュ、あるいは更新）は、“タグ、タイプ、値”データフォーマットに従う。たとえば、要求データ1620において、要素リストは、その他の中で、バッファーデータタイプはもちろん、ＡＳＣＩＩ文字列タイプのアプリケーションＩＤを保存する。返答データ1630は、ＡＳＣＩＩ文字列データタイプのアクセスポイントとバッファーデータタイプの承認プロフィールのようなデータを保存する。承認プロフィール情報は、特定のユーザーに関連付けられた状態、認証、承認を参照する。要求とリフレッシュデータは、各種の方法で使用される。たとえば、“非リフレッシュ”要求データは、アクセスポイントのパラメータの変更に使用される。一方では、非応答型のリフレッシュメッセージは、全ての返答データ（たとえば、新しいユーザープロフィール）に用いられる。その代わりに、あるいは、それに加えて、更新メッセージは、リフレッシュメッセージ（たとえば、ユーザープロフィールの変更部分）において送られるデータの部分を更新するために使用される。
【００５７】
図16Ｄは、ログイン項目タイプを含む相互通信例を示す図である。ステップ1において、消費者は、プロバイダーあるいはそのアクセスポイントへログイン要求（すなわち、要求メッセージ）を最初に送信する。その要求メッセージは、ユーザー識別キー、相互通信ストリーミングを示すフラッグ、各種のパラメータを含む要素リストを含むものである。ステップ2において、プロバイダーは、ログイン成功メッセージを持つ要求メッセージに応答する。ログイン成功メッセージは、開放ストリームデータとＯＫデータ状態を特定し、要求された情報（たとえば、承認プロフィール）あるいはパラメータを含む要素リストを含むリフレッシュメッセージとしてフォーマット可能である。ログインの後、消費者は望む方法でアクセスポイント/プロバイダーとの相互通信へ進むことができ、そのような相互通信において、他の項目タイプを使用することができる。ステップ3のような場合に、プロバイダーは、ステップ2において送られ、要求されたあるいはデフォールトデータのいずれをも更新するために消費者へ更新メッセージを送ることができる。たとえば、更新メッセージを用いて、承認プロフィールへの変更が更新される。消費者がプロバイダーあるいはアクセスポイントとの相互通信を完了した後に、消費者は、ステップ4で図示したように、ログオフを発行する。ログオフ要求は消費者が終了したいと望むストリームを識別する終了メッセージの形式を採ることができる。終了メッセージは、さらに、ログオフの成功を確認するステップ5において、プロバイダーからの確認メッセージを引き出す確認オプションを示す。
【００５８】
図17Ａ-Ｄは、取引、指示見積もり、最高予約見積もりに関する情報を保存しあるいは送信するために用いられる市場価格項目タイプモデルを示す。市場価格項目タイプは、純資産、固定収益、商品、通過、ＦＸ（すなわち、外貨交換レート）、寄付見積もりデータを含む各種市場機器のために定義されあるいは適用される。これらの機器に関連付けられた市場データと価格とは、メッセージクラス1705ａ、機器キー1705ｂ、キータイプ1705ｃ、データフォーマット1705ｄを用いて送られる。とりわけ、機器キー1705は、対応する機器の名前または記号を保存する。たとえば、株式機器キーは、株式についてのデータを検索するためにその記号により株式を識別する。機器キータイプ1705ｃは、市場価格モデル1700により理解されあるいは受け入れられる識別子（すなわち、名称）の各種タイプを定義する。さらに、モデル1700は、市場情報あるいはデータが保存されている特定のデータフォーマット1705ｄを定義する。一例によれば、市場価格データは、フィールドのリストフォーマット内に表示される。そのように、１つないし複数のデータ辞書は、フィールドのリスト、あるいは、フィールドＩＤ指定の解釈と説明を可能にするための対応コンテンツ定義モデルにより特定される。
【００５９】
本発明の１つないし複数の実施形態において、市場価格情報は、要求/応答規則（関心付、関心無し）を用いて通信され、あるいは、アクセスされる。言い換えれば、市場価格データは、単一の要求/応答メッセージペアを経てあるいはイベントストリームを経て通信され、更新リフレッシュメッセージが定期的にあるいは断続的に通信される通信される。図17Ｂは、市場価格モデル1700の各種送信セマンテックを記述するテーブルである。たとえば、送信セマンテックは、要求された機器のための市場価格に対応し、あるいは固有の機器に関連付けられた識別子の再定義（たとえば、機器キーにおける名前タイプの変更）による、市場価格/イベントストリームデータのリセットを含むリフレッシュメッセージのために複数の責任を割り当てる。送信セマンテックは、また、優先サポート、サービス品質、均一ストリームのグループ分け、一連番号付けのような複数の操作をサポートする。この技術分野のエキスパートならば、多くの他のタイプの送信セマンテックが、拡張可能なシステムは、ここで記載したアーキテクチュアの各種の態様を用いた市場価格タイプモデル1700によって定義されることを理解するはずである。
【００６０】
図17Ｃは、市場価格メッセージの３つのタイプのデータ符号化を示す。リフレッシュメッセージ1715のような応答は、一般的にそのメッセージに対応する機器を構成するフィールド/値ペアの全てを含み符号化する。たとえば、株式機器は、寄り付き値、終り値、一日の高値と底値、52週の高値と底値のようなフィールドを有している。それと対照的に、見積もり更新1725と取引更新1720のような更新メッセージは、更新されるべきフィールド/値ペアのみを含むこともあり得る。フィールドリストはさらに、標準記録符号化と記録セットの符号化のいずれかあるいは双方を用いることができる。
【００６１】
図17Ｄは、市場価格データを含む相互通信の一例と、消費者とプロバイダー間の機器を示している。その相互通信は、要求、リフレッシュ、更新のような複数のステップを含む。ステップ1では、たとえば、要求メッセージは、項目タイプを“市場価格”と特定し、サービス、記号、あるいは、要求キーにおけるコードフィールドを識別する。要求に応じて、プロバイダーは、ステップ2において、リフレッシュメッセージ内の市場価格データを受け取る。市場価格データは、フィールドリストとしてフォーマットされ、リフレッシュメッセージのペイロード区分に保存される。市場価格は一日中変化するので、消費者は、１つないし複数のフィールドのためにそのデータを修正するステップ3、4において、更新メッセージを受け取る。１つ以上の事例では、消費者は、フィールドリストのある区分の更新を受信するのみである。そのような場合には、変更されたフィールド/値ペアのみが送信されることになろう。
【００６２】
図18は、メッセージモデルに基づいてサービスプロバイダーと相互通信を行う方法を示すフローチャートである。ステップ1800において、消費者アプリケーションは、サービスプロバイダーとの希望する相互通信を決定する。たとえば、消費者アプリケーションは、見積もりを要求し、入札し、あるいは、株価を監視することを望む。ステップ1805において、消費者アプリケーションはさらに、望んだ相互通信に関連付けられた相互通信規則を識別する。たとえば、監視中の株価のような相互通信は、ストリーミングイベントを用いる定期的あるいは断続的な株価更新がなされるように、関心規則を伴う要求／応答に応答する。ステップ1810において、消費者アプリケーションは、サービスプロバイダーへ要求メッセージを送信する。要求メッセージは、メッセージモデルにより定義された一般的要求メッセージに従がってフォーマットされる。たとえば、要求メッセージは、サービスの質、データフォーマット、情報の優先権、ストリーム識別のようなフィールドを含む。本発明の１つあるいは複数の実施形態では、要求メッセージは、相互通信が対応している相互通信規則を特定し得る。要求メッセージは、直接的よりはむしろデータシステムを介することによって送信されるものである。要求は、要求メッセージが関連している（たとえば、イベントストリームが過去に起動され、あるいは、生成されていた場合に）イベントストリームを識別するストリーム識別子を識別しあるいは特定する。
【００６３】
要求メッセージに応じて、消費者アプリケーションは、ステップ1815にて、リフレッシュメッセージを受信する。リフレッシュメッセージは、メッセージモデルによって定義されたデータフォーマットにしたがってフォーマットされる搭載物を含む。たとえば、市場価格情報は、１つ又は複数のフィールドのリストにて搭載物データ内に表示される。フィールドリストあるいはペイロードデータは、さらに、フィールドリストあるいはペイロードデータに保存された情報を解釈するための１つないし複数のデータ辞書を特定できる。本発明の１つまたはそれ以上の実施態様によると、消費者アプリケーションにより要求されたデータは、一度に送信するにはバンド幅が大きすぎる場合は、より小さな部分に細分化することができる。そのようなイベントでは、リフレッシュメッセージは、全部のカウント値示唆を示す。かくして、ステップ1820では、消費者アプリケーションは、細分化されたデータをキャッシングするために充分なメモリーを割り当て可能である。このことは、見込みバッファーあるいはメモリーがあふれるのを防止する。
【００６４】
ステップ1825では、消費者アプリケーションは、要求されたデータ又は相互通信に関連付けられた追加情報を提供する１つ以上の更新メッセージを受信する。たとえば、株価監視サービスは、監視された株価が変化した日の一日中、定期的あるいは不定期に複数の更新メッセージを受け取ることを含む。別の例では、株式取引を要求する消費者は、リフレッシュメッセージの中で、指し値確認を始めに受信する。取引が一度終了した後で、終了メッセージが受信される。一旦、要求したサービスがなされあるいは要求したデータが受信されると、消費者アプリケーションは、ステップ1830における相互通信に関連付けられたイベントストリームを終了するために、終了メッセージをサービスプロバイダーへ送信する。消費者アプリケーションが終了メッセージ内に確認を要求する場合は、消費者アプリケ−ションは、ステップ1835において、サービスプロバイダーから確認メッセージを受信する。
【００６５】
本発明の方法における様々な実施態様では、ここで述べられたモデルとアーキテクチュアは、コンピュータでの読み取り可能な命令の形式でのコンピュータ読み取り可能な媒体に保存され得る。コンピュータ読み取り可能な媒体のタイプには、磁気テープドライブ、光記憶装置、フラッシュドライブ、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）等がある。それに加えて、ここで述べた方法、モデル、アーキテクチュアは、他の業界やアプリケーションにおいても使用される。たとえば、開始メッセージモデルにて定義される一般メッセージは、図書館アプリケーション用の書籍情報を記述し表示するのに用いられる。
【００６６】
この発明は、好ましい例示的な実施例に関して述べられたものである。他の多くの実施例、変形、変更は、以下の請求項に記載されるこの発明の要旨を逸脱しない範囲で、上記記述の観点から、通常の同業者が思いつくものである。
【図１】
2010504690.tif 000003
【図２】
2010504690.tif 000004
【図３】
2010504690.tif 000005
【図４】
2010504690.tif 000006
【図５】
2010504690.tif 000007
【図６Ａ】
2010504690.tif 000008
【図６Ｂ】
2010504690.tif 000009
【図６Ｃ】
2010504690.tif 000010
【図７Ａ】
2010504690.tif 000011
【図７Ｂ】
2010504690.tif 000012
【図７Ｃ】
2010504690.tif 000013
【図７Ｄ】
2010504690.tif 000014
【図７Ｅ】
2010504690.tif 000015
【図７Ｆ】
2010504690.tif 000016
【図８】
2010504690.tif 000017
【図９】
2010504690.tif 000018
【図１０】
2010504690.tif 000019
【図１１】
2010504690.tif 000020
【図１２】
2010504690.tif 000021
【図１３】
2010504690.tif 000022
【図１４】
2010504690.tif 000023
【図１５】
2010504690.tif 000024
【図１６Ａ】
2010504690.tif 000025
【図１６Ｂ】
2010504690.tif 000026
【図１６Ｃ】
2010504690.tif 000027
【図１６Ｄ】
2010504690.tif 000028
【図１７Ａ】
2010504690.tif 000029
【図１７Ｂ】
2010504690.tif 000030
【図１７Ｃ】
2010504690.tif 000031
【図１７Ｄ】
2010504690.tif 000032
【図１８】
2010504690.tif 000033
【国際調査報告】
2010504690.tif 000034
2010504690.tif 000035