(57)【要約】  本発明は、ＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）アーキテクチャにより特徴付けられるデータ・ストア上にＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒ）インタフェースを提供する。係る特徴付けをエンティティ・フレームワークにより提示することができ、このエンティティ・フレームワークにより、リレーショナル・データベース側で或る方法で特徴付けたデータをＥＤＭの特性に変換することができ、このＥＤＭの特性をさらに外部のプロセスまたは装置に公開することができる。ＥＤＭストア上のＲＥＳＴインタフェースは、表現力が高い方法でモデル化したデータをインターネットまたはウェブ規模のイントラネットに公開するためのエンド・ツー・エンドのフレームワークを提供することができる。
2010519624.tif 000002
【特許請求の範囲】
【請求項１】
ＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）ストアへのアクセスを容易にするシステム（１００）であって、
ＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）ストア（１０４）と、
前記ＥＤＭストアに関係する要求および結果を移送するステートレスで均一なインタフェースと、
を備えるシステム。
【請求項２】
前記ＥＤＭストアは１つまたは複数の論理記憶コンポーネント、または物理記憶コンポーネント、またはその両方にマップしたＥＤＭスキーマにより記述される、請求項１に記載のシステム。
【請求項３】
前記ＥＤＭストアに関係する前記要求および結果はさらに、前記ＥＤＭストアに関係するか、または前記ＥＤＭストアに含まれるか、またはその両方である情報を公開するために、前記ＥＤＭストアでの識別、アクセス、更新、または検索の相互作用、またはそれらの組合せのうち少なくとも１つを備える、請求項１に記載のシステム。
【請求項４】
前記ＥＤＭスキーマはさらに、エンティティ・タイプ、エンティティ・インスタンス、もしくはエンティティ・セット、またはリレーションシップ・タイプ、リレーションシップ・インスタンス、もしくはリレーションシップ・セット、またはアクション・タイプ、アクション・インスタンス、もしくはアクション・セット、またはそれらの組合せのうち少なくとも１つから成る定式化を備える、請求項２に記載のシステム。
【請求項５】
前記ＥＤＭスキーマはさらに、リレーションシップ・タイプ、リレーションシップ・インスタンス、もしくはリレーションシップ・セット、またはその組合せのうち少なくとも１つから成る定式化を備えて、エンティティ・タイプ、エンティティ・インスタンス、もしくはエンティティ・セット、またはその組合せのうち少なくとも１つに対する実世界のコンテクストを提供する、請求項４に記載のシステム。
【請求項６】
前記ステートレスで均一なインタフェースはＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒ）インタフェースである、請求項１に記載のシステム。
【請求項７】
前記識別、アクセス、更新、または検索の相互作用はさらに、前記ＥＤＭスキーマに従うＵＲＩ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｉｎｄｉｃａｔｏｒ）を備える、請求項１に記載のシステム。
【請求項８】
ＥＤＭ構成概念の意味を保存する前記ステートレスで均一なインタフェースを通して公開される少なくとも１つのＥＤＭエンティティ表現形式をさらに備える、請求項１に記載のシステム。
【請求項９】
ＥＤＭ構成概念の意味にはリレーションシップと継承が含まれる、請求項８に記載のシステム。
【請求項１０】
ＥＤＭストアに関係する情報を提供する方法（５００）であって、
少なくとも１つのＥＤＭ項目により特徴付けられるリソース・ストアを明示的に定義するステップ（５０２）と、
少なくとも１つのＥＤＭ項目を、前記リソース・ストアに関係する要求および結果を移送するためのステートレスで均一なインタフェースにマップするステップ（５０４）と、
を備える方法。
【請求項１１】
前記ＥＤＭ項目はさらに、ＥＤＭエンティティ、ＥＤＭリレーションシップ、またはＥＤＭエンティティとＥＤＭリレーションシップの組合せを備える、請求項１０に記載の方法。
【請求項１２】
前記均一でステートレスなインタフェースを通して前記リソース・ストアを問い合わせるステップをさらに備える請求項１０に記載の方法。
【請求項１３】
問合せ結果をＥＤＭエンティティの表現形式で受け取るステップをさらに備える請求項１０に記載の方法。
【請求項１４】
前記ＥＤＭエンティティを、前記ＥＤＭリレーションシップによって少なくとも１つの追加のＥＤＭエンティティに関係付けるステップをさらに備える請求項１３に記載の方法。
【請求項１５】
前記少なくとも１つの追加のＥＤＭエンティティに関係する前記ＥＤＭエンティティの少なくともアソシエーション、または継承、またはその両方を、前記ＥＤＭリレーションシップにより、前記１つまたは複数のＥＤＭ表現形式を介して保存するステップをさらに備える請求項１４に記載の方法。
【請求項１６】
前記ＥＤＭエンティティ表現形式は、ＰＯＸ（ｐｌａｉｎ  ｏｌｄ  ＸＭＬ）、ＲＤＦ（ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｒａｍｅｗｏｒｋ）、ＲＳＳ（ｒｉｃｈ  ｓｉｔｅ  ｓｕｍｍａｒｙ）、またはＪＳＯＮ（ｊａｖａ  ｓｃｒｉｐｔ  ｏｂｊｅｃｔ  ｎｏｔａｔｉｏｎ）、またはそれらの組合せのうちの１つである、請求項１３に記載の方法。
【請求項１７】
ステートレスで均一なインタフェースを通してＥＤＭストアに対するアクセスを提供するシステム（１００）であって、
ＥＤＭスキーマをデータ・ストア（１０４）にマップするデータを特徴付けるための手段と、
前記ＥＤＭスキーマにステートレスで均一なＵＲＩインタフェース（１０２）を重ねるデータ・ストアにインタフェースをマップするための手段と、
を備えるシステム。
【請求項１８】
前記ステートレスで均一なＵＲＩインタフェースはＲＥＳＴ  ＵＲＩインタフェースである、請求項１７に記載のシステム。
【請求項１９】
前記ＥＤＭスキーマに従って前記データ・ストアを問い合わせる問合せ手段をさらに備える請求項１７に記載のシステム。
【請求項２０】
前記問合せ手段からの問合せにＥＤＭデータ表現形式で指定したデータで応答する表現手段をさらに備える請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
従来のデータベースは、データ・ストア内部に記憶したデータを表すためにリレーショナル・モデルを使用している。リレーショナル・モデルはデータの独立を可能とするシステムであり、データベース内部に記憶したデータの物理的表現はデータベースのユーザに提示される論理的なビューとは異なる。リレーショナル・データベース・モデルは３０年以上前に導入され、記憶データを有用な形式で提示するための手段として大きな成功を収めた。時間とともに、より新しく様々な技術（例えば、インターネットにより生み出された技術）にリレーショナル・モデルが適用されると幾つかの欠点が浮き彫りになった。特に、ＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ  ｑｕｅｒｙ  ｌａｎｇｕａｇｅ）はリレーショナル・モデルのデータ・ストアに対する問合せ言語としてほぼ独占的に使用されるようになり、十分な適応が不足したために当該言語は幾つかの現代的なアプリケーションに対しては比較的扱い難いものとなった。さらに、リレーショナル・モデルは、数学的関係を基礎とし、後に開発されたオブジェクト・ベースのデータ・モデルと比べて理論的に構築された。その概念的な簡潔さのために、多くのアプリケーション・プログラマは従来のリレーショナル・モデルよりオブジェクト・モデルおよび後続のモデリング方式を好んだ。
【０００２】
近年、計算システム、特に緩く相関するシステムの通信方式に関してかなり議論が行われた。一部の議論はウェブ・サービスと、特定のウェブ・サービスのローカル・プロセスを定式化するための構想とに集中した。これらのウェブ・サービスのうち幾つかはアプリケーションおよびサービスの両方の性質を示し、インターネット上のエージェントがこれらのサービスを、すぐに利用可能なインタフェースまたはデータ・ストアへの直接アクセスを提供するより洗練されたアプリケーション・プログラミング・インタフェースを通して消費できるようにしている。或る特定の業界には、サービスおよびアプリケーションの２相構成は良く適合した。しかし、これらの構成は比較的複雑で、幾つかのコンシューマ、特に、データベース、アプリケーション、ウェブサイトの開発者のニーズには適合しなかった。アプリケーションおよびサービスがデータ・ストアと対話するための単一インタフェースに着目した、代替的なアーキテクチャ・スタイルが開発され始めた。具体的なアーキテクチャの１つは、インターネットを大規模なネットワーキング・エンティティとして成功させた特徴に関連して設計され、ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒ  ｍｏｄｅｌ）モデルと名づけられた。
【０００３】
ＲＥＳＴインタフェース・アーキテクチャは単純なインタフェースを中心とし、インターネットの成功に寄与する様々な特徴を生かしている。例えば、ＲＥＳＴモデルは、反復的なコンポーネントの対話を軽減するサーバ側およびクライアント側のキャッシュ構造を利用している。さらに、ＲＥＳＴは、各対話がその対話を実行するのに必要な全ての情報を定義するように、処理状態を把握しないステートレスな環境を提供している。このステートレスな環境のためＲＥＳＴモデルは部分的に成功し、或るコンポーネントが他のコンポーネントとの以前の対話履歴または通信履歴を追跡することは必要ではなかった。今日のウェブ・サービスのアプリケーション・プログラミング構造の大部分は、このＲＥＳＴプラットフォーム、およびＸＭＬスキーマのような従来のデータ・モデリング・スキーマを基礎としていた。
【発明の概要】
【０００４】
以下で本発明の簡単な要約を示し、本発明の幾つかの態様の基本的な理解を規定する。本要約は本発明の広範囲の概要ではない。また本要約は、本発明の主要または重要な要素を特定することは意図しておらず、本発明の範囲を線引きすることも意図していない。その唯一の目的は、後に提示する発明を実施するための形態の前置きとして本発明の幾つかの概念を簡単な形で提示することである。
【０００５】
本明細書で開示および主張する発明は、その１態様において、ＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）ストアを、当該ＥＤＭストアに関連する要求および結果を移送できるステートレスで均一なインタフェースにより公開する。本インタフェースはエンティティ・データ・モデリングにより確立された構造的関係に従って問合せ、例えば、ＵＲＩ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｉｄｅｎｔｉｆｉｅｒ）問合せを受け入れることができ、問合せ結果を、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ）、ＲＤＦ（ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｒａｍｅｗｏｒｋ）、ＪＳＯＮ（ｊａｖａ  ｓｃｒｉｐｔ  ｏｂｊｅｃｔ  ｎｏｔａｔｉｏｎ）、等を含む単純な表現形式を介して返すことができる。従って、データを単純で均一な方法でインターネットに公開しつつ、エンティティ・データ・モデリングを介して使用できる表現力の高いデータ・モデリングを利用する、エンド・ツー・エンドのフレームワークを提供することができる。
【０００６】
本発明の別の態様によると、リレーショナル・データベースのようなデータ・ストアをＥＤＭスキーマにマップさせ、ＥＤＭエンティティおよびリレーションシップを指定することができる。続いて、係るＥＤＭエンティティおよびリレーションシップをＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒ）関連のＵＲＩ空間にマップすることができる。結果として、表現力のあるＥＤＭエンティティおよびリレーションシップにより表されるデータ・ストアを公知なＵＲＩフォーマットで問い合わせることができる。エンティティ自体を安定なＲＥＳＴ関連のＵＲＩでリソースとして公開することができ、係るＵＲＩはＥＤＭスキーマにより記述した構造およびストアを反映する。ＲＥＳＴに関係する環境は均一かつステートレスでありうるので、意味は分かりやすく、スケーラビリティを妨げずに済む。
【０００７】
本発明の１つの特定の態様において、エンティティ・フレームワーク（例えば、．ＮＥＴブランドのフレームワーク）はリレーショナル・データ・ストアとインタフェースし、リレーショナル層の上に概念層を重ねることができる。より具体的には、エンティティ・フレームワークに関連するクライアント側のビュー・エンジンはリレーショナル・スキーマを利用するリレーショナル・データ・モデルを、潜在的によりリッチなＥＤＭデータ・モデルおよびＥＤＭスキーマにマップすることができる。さらに、ＲＥＳＴインタフェースを利用して、係るデータ・ストアをインターネット、大規模な企業イントラネット、等のようなウェブ規模のネットワークに公開し、外部クライアントが当該データ・ストアを係るウェブ規模のネットワーク上のＥＤＭストアとみなすことができるようにすることができる。エンティティ・フレームワークおよびＲＥＳＴインタフェースは高レベルのデータ独立性を広大なウェブ空間のスケーラビリティ要件と結び付け、係るアクセス・ネットワーク上の概念的なアプリケーション・プログラミング環境を以前に係る環境に対して使用可能であったものより非常に大規模なものとすることができる。
【０００８】
以下の説明および添付図面で、本発明の或る特定の例示的な態様を説明する。しかし、これらの態様は本発明の原理を使用できる様々な方法のうち幾つかを示すに過ぎず、本発明は係る態様およびその均等物の全てを含むように意図している。本発明の他の利点および際立った特徴は、後の本発明の詳細な説明を添付図面と関連させて考慮することにより明らかになろう。
【図面の簡単な説明】
【０００９】
【図１】本発明の態様に従う、ＥＤＭストア上の処理状態を把握しないステートレスで均一なインタフェースの高レベルなブロック図である。
【図２】特定の態様に従う、従来のリレーショナル・データベースに適用されるＥＤＭスキーマを示す高レベルなブロック図である。
【図３】本発明に従う、複数のクライアント側のインタフェースを示す例示的なブロック図である。
【図４】本発明の態様に従って、エンティティ・フレームワーク・アーキテクチャのコンポーネントをマップすることで変換されるリレーショナル・ストアのＥＤＭビューをＲＥＳＴインタフェースが公開することを示す例示的なブロック図を示す図である。
【図５】特定の態様に従う、ＥＤＭストアをステートレスで均一なインタフェースを介して公開するための例示的な方法を示す図である。
【図６】本発明の１態様に従う、問合せをインターネットＥＤＭストアで受け取り応答を提供する例示的な方法を示す図である。
【図７】本発明の特定の態様に従う、ＥＤＭストアを問合せてＲＥＳＴインタフェースを介して応答を受け取るための例示的な方法を示す図である。
【図８】本発明の新規な態様を使用できる例示的なネットワーク環境を示す図である。
【図９】本発明の例示的なコンピューティング環境を示す図である。
【図１０】本発明の特定の態様に従うアーキテクチャを実行するように動作する例示的なコンピュータ集合システムの略ブロック図である。
【発明を実施するための形態】
【００１０】
図面を参照して本発明を説明する。図面全体を通じて同様な参照番号を使用して同様な要素を参照する。以下の記述では、説明を目的として、多数の具体的な詳細を示して本発明の徹底的な理解を図る。しかし、本発明をこれらの具体的な詳細なしに実施できることは明らかであろう。他の事例では、本発明の説明を容易にするために公知な構造および装置をブロック図の形で示してある。
【００１１】
本明細書で使用するとき、「コンポーネント」、「モジュール」、「システム」、「インタフェース」、「エンティティ・データ・モデル」等は一般にコンピュータ関連の実体、即ち、ハードウェア、ハードウェアおよびソフトウェアの組合せ、ソフトウェアまたは実行中のソフトウェアの何れかを指すことを意図している。例えば、コンポーネントは、プロセッサ上で稼動しているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであることができるがこれらに限定されない。例として、コントローラ上で稼動しているアプリケーションおよびコントローラはともにコンポーネントであることができる。１つまたは複数のコンポーネントがプロセスおよび／または実行スレッド内部に常住することができ、コンポーネントを１つのコンピュータ上に配置してもよく、かつ／または複数のコンピュータ間に分散させてもよい。別の例として、インタフェースはＩ／Ｏコンポーネントだけでなく関連するプロセッサ、アプリケーション、および／またはＡＰＩコンポーネントを含むことができ、コマンド・ラインと同程度に単純であるか、それより複雑なＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ｅｎｖｉｒｏｎｍｅｎｔ）であることができる。
【００１２】
さらに、本発明を方法、機器、またはソフトウェア、ファームウェア、ハードウェア、もしくはその任意の組合せを生産するための標準的なプログラミングおよび／もしくは製造技術を用いた製品として実装して、本発明を実装するためのコンピュータを制御することができる。本明細書で使用する「製品」という用語は、任意のコンピュータ読取可能装置、キャリア、または媒体からアクセスできるコンピュータ・プログラムを含むことを意図している。例えば、コンピュータ読取可能媒体には磁気記憶装置（例えば、ハード・ディスク、フロッピ・ディスク、磁気ストリップなど）、光ディスク（例えば、ＣＤ（ｃｏｍｐａｃｔ  ｄｉｓｋ）、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）など）、スマート・カード、およびフラッシュ・メモリ装置（例えば、カード、スティック、キー・ドライブなど）が含まれるがこれらに限らない。さらに、搬送波を使用して、電子メールの送受信の際またはインターネットもしくはＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）などのネットワークへのアクセスの際に使用されるようなコンピュータ読取可能な電子データを運搬できることは理解されよう。もちろん、この構成に本発明の範囲または趣旨を逸脱しない多数の修正を加えうることは当業者には理解されよう。
【００１３】
さらに、「例示的」という単語は本明細書では例、事例、または例示を意味するように使用する。「例示的」として本明細書で説明する任意の態様または設計は必ずしも他の態様または設計に対して好適または有利であると解釈すべきではない。むしろ、例示的という単語を使用することは、概念を具体的に提示することを意図している。本明細書で使用する際、「または」という用語は、排他的な「または」ではなく両立的な「または」を意味することを意図している。即ち、特に明記しない限り、または文脈から明らかでない限り、「ＸがＡまたはＢを使用する」は自然な両立的順列の何れかを意味することを意図している。即ち、ＸがＡを使用し、ＸがＢを使用し、またはＸがＡおよびＢの両方を使用するならば、「ＸがＡまたはＢを使用する」はＸ、Ａ、Ｂがどのようなものであっても成り立つ。さらに、本明細書および添付の特許請求の範囲で使用する際、冠詞「ａ」および「ａｎ」は一般に、単数形を指すと特に明記しない限り、または文脈から明らかでない限り、「１つまたは複数」を意味するとして解釈すべきである。
【００１４】
本明細書で使用する際、「推論する」または「推論」は一般にシステム、環境、および／またはユーザの状態を事象および／またはデータを介して得た一組の観測結果から推測または推論することを指す。推論を使用して、例えば特定の文脈もしくは動作を特定するか、状態の確率分布を生成することができる。推論は確率的であることができる。即ち、着目する状態の確率分布の計算はデータおよび事象に基づいて行われる。推論は、高レベルな事象を一組の事象および／またはデータから構成するために使用される技法を指すこともできる。係る推論の結果、事象が時間的に緊密に相関していようといまいと、かつ事象およびデータが複数の事象およびデータのソースから来る来ないに関わらず、新たな事象または動作は一組の観測した事象および／または記憶した事象データから構築されることになる。
【００１５】
次に図面を参照する。先ず図１を参照すると、本発明の態様に従うＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）記憶（複数可）１０４上のインタフェース１０２を示すシステム１００が図示されている。インタフェース１０２は、ＥＤＭストア１０４に関係する要求および結果を移送することができ、ステートレスかつ均一であることができる。均一なインタフェースとして、インタフェース１０２は情報交換プラットフォームを提供して、情報が係る情報を要求するアプリケーションと独立に転送されるようにすることができる。結果として、各アプリケーションは互いと独立に発展することができ、実質的に同様な形式で情報を提示するための（後で論ずる）表現を利用することができる。従って、ＥＤＭデータ・ストア（複数可）１０４に対する均一なインタフェースにより、複数のクライアント型のコンポーネント（図示せず）がそのインタフェースにアクセスできる。例えば、係るプラットフォーム（例えば、ウェブサイト）を利用するための、すぐに利用可能なユーザ・インタフェースを開発することができる。さらに、複雑または専用のプロトコルを必要としないＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）を開発することができる。係るＡＰＩインタフェースをプログラマまたは開発者（例えば、ウェブサイト開発者、等）が利用することもできる。
【００１６】
ステートレスなインタフェースとしてのインタフェース１０２により、記憶コンポーネント、例えば、ＥＤＭデータ・ストア（複数可）１０４は、別のエンティティとの以前のトランザクションに関するデータを殆どまたは全く保持しなくてよい。換言すれば、２つの接続されたシステム、例えば、クライアントおよびサーバの間での要求または応答は当該要求または応答を理解するために必要な情報の全てを含むことができる。例えば、クライアント・システムが、サーバ・システムに記憶した情報を要求する場合、その要求は、当該サーバが当該要求を完了するために必要な全ての情報を指定しなければならない。さらに、クライアントによる後続の要求はそれより前の要求に依存せず、サーバ・システムは他のコンポーネントとの以前の対話に関する情報を保持しない。係るインタフェースにより、サーバ側のメモリ・リソースの同時使用可能性を実質的に最大化することができ、当該サーバ・システムが様々な要求を通してリソース使用を管理する必要がないことを示唆することができる。本例のサーバ・システムをＥＤＭデータ・ストア、例えばＥＤＭデータ・ストア（複数可）１０４と同等と見なすと、ステートレスなインタフェースにより係るＥＤＭストア１０４は、増加する要求動作を満たすように迅速にその応答動作を拡大することができる。インターネットまたは大規模なイントラネットのような広大で複雑なネットワーク上では、要求動作が急速に増える、時にはサーバの観点からはランダムに増える可能性がある。従って、スケーラビリティはサーバ性能に関して有利な態様でありうる。
【００１７】
ＥＤＭデータ・ストア（複数可）１０４は、ＥＤＭデータ・モデリングの仕組みに従って（例えば、リレーショナル・スキーマをＥＤＭスキーマとして提示できるマッピング機能により）情報を記憶し、その情報を外部に提示できる１つまたは複数の仮想装置または物理装置であることができる。ＥＤＭは、エンティティを明示的に定義するデータをモデル化する形式的な方法であることができる。ＥＤＭはさらに、係る定義に対して高い表現力の構成概念、例えば、継承およびリレーションシップのような概念を使用して、データを適切かつ具体的な抽象化レベルでモデル化することができる。伝統的には、データ・ストアはリレーショナル・モデルを使用してデータの構造を記述する。対照的に、ＥＤＭは高レベルの抽象化によりデータの記述を可能とする層状のアーキテクチャを生成することができる。例えば、ＥＤＭアプローチでは、データ・モデラ（例えば、ウェブサイト、データベース、ＡＰＩの開発者、等）により分かるように、システムに関係する構造的な詳細にあまり気にせずともよく、データ自体の構造的および意味的特徴に、より集中することができる。
【００１８】
ＥＤＭスキーマは、エンティティの構造を定義する１つまたは複数のエンティティ・タイプを有することができる。ここで、エンティティとはエンティティ・タイプの特定のインスタンスである。例えば、或るエンティティ・タイプが「コンシューマ」であることができ、「コンシューマ」の記述に適合する任意の仮想または実世界のオブジェクトを含むことができる。「コンシューマ」エンティティ・タイプに関係するエンティティは「コンシューマ・ボブ」であることもできる。「コンシューマ・ボブ」は従って「コンシューマ」エンティティ・タイプの或る特定のインスタンスであることができ、そのエンティティ・タイプのうち他の多くのインスタンスが存在することができる（例えば、「コンシューマ・ジェーン」、「企業Ｂ」、「ワシントン州」も全て「コンシューマ」エンティティ・タイプのエンティティであることができる）。従って、エンティティ（インスタンス）はエンティティ・タイプと特定の関係を有することができ、同様にＥＤＭの他の態様との関係を有することができる。
【００１９】
エンティティ・タイプはそれに関連するプロパティ（例えば、記述子、品質、属性、等）を有することができる。プロパティを利用してエンティティ・タイプを記述することができ、かつ／または特定のタイプのエンティティを特定のタイプの他のエンティティと区別することができる。さらに、係るプロパティを利用して、（後で論じる）問合せ断片を介して或る組のＥＤＭデータを別の組のＥＤＭデータからフィルタすることができる。前の例を続けると、「コンシューマ」エンティティ・タイプは「名前」、「住所」、「電話番号」、「電子メール」、等のような、それに関連するプロパティを有することができる。係るプロパティにより、データ・モデリングの継承概念の１態様の形成を支援することができる。
【００２０】
大部分の実際の適用では、エンティティは何らかの方法で他のエンティティと関係する。ＥＤＭはこの概念をリレーションシップの概念を通して取り込むことができる。リレーションシップは、リレーションシップ・タイプのインスタンスで、エンティティがエンティティ・タイプのインスタンスであることと同様であり、複数のエンティティ・タイプのインスタンス間の関連を表現することができる（例えば、「コンシューマ・ボブ」が「オペレーティング・システム」を購入した、では、「購入した」というリレーションシップのインスタンスが２つのエンティティ、即ち、「コンシューマ・ボブ」と「オペレーティング・システム」の間の関連を表現することができる）。データ・モデリングにおけるリレーションシップの概念は新しくはないが、リレーションシップ・タイプに関連するリレーションシップ・インスタンスの存在または潜在性により、リレーショナル・モデルで以前に使用できたものを超えて、データ・モデリングに関する新しいレベルの抽象化を提示することができる。
【００２１】
１つの具体的なＥＤＭリレーションシップは継承リレーションシップであり、実際には第１のオブジェクト（例えば、インスタンス、タイプまたはセット、等）から第２のオブジェクトへプロパティを完全または部分的に移すことにより実装される。ＥＤＭデータ・モデリングでは、エンティティ・タイプは属性を他のエンティティ・タイプから獲得することができ、それによりスーパータイプ・サブタイプ形式を利用した構造的な継承が可能になる。サブタイプ・エンティティはスーパータイプに属する属性（例えば、前述のプロパティ）のセットまたはサブセットを獲得することができ、サブタイプ・エンティティにさらに追加の属性（例えば、追加のプロパティ、リレーションシップ、等）を割り当てることができる。第２のＥＤＭリレーションシップはアソシエーション・リレーションシップであり、ＥＤＭモデリング・システム全体を通じてサポートされる第１のクラスのリレーションシップの構成概念であることができる。アソシエーション・リレーションシップによりピア・ツー・ピアのモデリングが可能となる。リレーションシップのインスタンス「購入した」に関して上で述べた例は、ピア・ツー・ピア関係を示すことができる。より具体的には、２つのエンティティのインスタンス、「コンシューマ・ボブ」と「オペレーティング・システム」は、それぞれ異なるエンティティ・タイプ、即ち「コンシューマ」および「商品」であり、「購入した」というリレーションシップ・インスタンスを介して関係する。従って、アソシエーションは１つまたは複数の独立なエンティティのインスタンスをピア・ツー・ピアの形式を介して関係させることができ、一方でコンテインメントは１つまたは複数の依存エンティティのインスタンスを、親子形式を介して関係させることができる。インスタンスレベルでは、エンティティを第３のＥＤＭトポロジであるエンティティ・セット、具体的にはエンティティ・タイプまたはリレーションシップ・タイプに相関するエンティティ・セットまたはリレーションシップ・セット、に含めることができる。例えば、「コンシューマ」エンティティ・タイプに関連する全ての「コンシューマ」インスタンス（例えば、「コンシューマ・ボブ」および「コンシューマ」タイプの他の全てのインスタンス）をエンティティ・セットに纏めてグループ化することができる。
【００２２】
ＥＤＭセットは特定のエンティティ・タイプの複数のエンティティ・インスタンスを含むことができ、従ってＥＤＭセットをエンティティ・タイプに関連付けることができる。エンティティ・セットをテーブル（例えば、列および行を有するスプレッドシート・テーブル）として近似的に概念化することができる。複数のエンティティ・セットをエンティティ・コンテナにグループ化することができ、エンティティ・コンテナをデータベースとして近似的に概念化することができる。
【００２３】
前述のように、ＥＤＭデータ・ストア（複数可）１０４は、ＥＤＭのアーキテクチャ・スタイルに従って編成したデータを有する１つまたは複数の物理記憶装置または仮想記憶装置である。例えば、ＥＤＭデータ・ストア（複数可）（１０４）を、物理ストア、論理ストア、またはリレーショナル・ストア、等のような１つまたは複数の記憶コンポーネントにマップしたＥＤＭスキーマにより記述することができる。係る構成により、表現力の高い形のデータ・モデリングまたはデータ形成が可能となる。ステートレスで均一なインタフェース、例えば、インタフェース１０２によりデータ・ストアを公開することで、コンシューマはカスタム・プロトコルおよび複雑な対話モデリングを必要とせずにデータを利用および操作することができる。例えば、インタフェース１０２により、ＥＤＭデータ・ストア（複数可）１０４に関係する情報の識別、問合せ、読み出し、および／もしくは更新、ならびに／または高い表現力のデータをインターネット、大規模なイントラネット、等のような広大なウェブ環境に公開するためのエンド・ツー・エンドのフレームワークの提供を容易にすることができる。
【００２４】
次に図２を参照すると、本発明の特定の態様に従う、従来のリレーショナル・データベースに適用されるＥＤＭスキーマを含むシステム２００が図示されている。物理データ・ストア（複数可）２０２は任意の種類の仮想データ記憶媒体または物理データ記憶媒体であることができ、例えば、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンビューティング装置、等）、サーバ、データベース、等が含まれる。ＥＤＭスキーマ２０４は上述のものと同様なエンティティ・データ・モデル構造であることができ、エンティティ・タイプ、エンティティ・インスタンス、およびエンティティ・セットに従って情報を形成および編成することができる。さらに、ＥＤＭスキーマ２０４は１つまたは複数のリレーションシップ・タイプ、インスタンス、またはセットを介してエンティティのタイプ、インスタンスおよびセットを相関させることができる。リレーションシップはアソシエーションおよび／または継承ベースの関係であることができ、ピア・ツー・ピアおよび／またはスーパータイプ・サブタイプの特性を保存する役割を果たすことができる。さらに、係る関係は、両方向のエンティティ間の明示的および暗黙的な関連付けを可能とする第１クラスのリレーションであることができる。例えば、第１クラスのリレーションにより、クライアント装置（図示せず）は第１のエンティティから第２のエンティティへリレーションを辿り、次に第２のエンティティから第１のエンティティへ戻ることができる。
【００２５】
インタフェース２０６は、ＥＤＭスキーマ２０４により指定された物理データ・ストア（複数可）２０２へのステートレスで均一なアクセスを提供することができる。係るアクセスにより、コンポーネント（例えば、クライアント装置）は、インターネットまたは大規模なイントラネットのような大規模なウェブスタイルのアーキテクチャのストアからエンティティを発見、取得および／または更新することができる。前に論じたように、ステートレスで均一なインタフェースによりスケーラビリティを提供することができ、開発者は（後述）単純なデータ表現に基づいてアプリケーションを作成することができる。さらに、係るアーキテクチャにより、プログラミング環境、例えば、（後でより詳細に論じる）エンティティ・フレームワークはクライアント側のビュー・エンジンを適用してＥＤＭスキーマ（例えば、ＥＤＭスキーマ２０４）を形式化することができる。
【００２６】
クライアント側のビュー・エンジンは、従来のリレーショナル・ストア（例えば、物理データ・ストア（複数可）２０２）に関する記憶スキーマとは異なるインタフェース・スキーマ（例えば、ＥＤＭスキーマ）をクライアント装置で提示するための宣言的マッピング仕様を解釈することができる。（従って、図１に示すＥＤＭデータスキーマ（複数可）１０４は、本明細書で説明する［例えば、ＥＤＭスキーマ２０４のようなＥＤＭの適用する］マッピング仕様を伴うリレーショナル・データベースでもありうることは理解されよう）。エンティティ・フレームワーク環境と係るインタフェースへのその適用は後に図４でより詳細に論ずる。
【００２７】
図３を参照すると、例示的なブロック図により、本発明に従う複数のクライアント側インタフェースを伴うシステム３００が示されている。ＥＤＭデータ・ストア（複数可）３０２は、上で論じたように、ＥＤＭ構造（例えば、ＥＤＭスキーマ）により特徴付けられる情報を含む。ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  ｓｔａｔｅ  ｔｒａｎｓｆｅｒ  ｍｏｄｅｌ）層３０４は、インターネットのような大規模なネットワーク環境に関する特定のデータ・インタフェースであることができる。ＲＥＳＴモデルは、大規模なネットワーク環境で効果的と証明された幾つかの装置インタフェースの制約を提供することができる。ＲＥＳＴ層３０４と関連付けることができるインタフェース特性の例は、（上で論じた）ステートレスな対話であり、それによりクライアント側要求のスケーラビリティ、粒度の大きなハイパーメディアのデータ（例えば、ビデオ、オーディオ、等のような大きなデータ・ファイル）の転送に理想的な均一なコンポーネント・インタフェース、反復的な要求の結果生ずるリソース要求の軽減を支援するクライアント側およびサーバ側のキャッシュ、およびシステムの複雑性に上限を設け、コンポーネント間の独立性を推進する層状コンポーネント・アーキテクチャが可能となる。ＲＥＳＴ層３０４はこれらの特性の一部または全部から成る組合せだけでなく、大規模なネットワーク環境におけるデータ転送を容易にする追加の特性を含むことができることは理解されよう。
【００２８】
一般に、ＲＥＳＴ層３０４はＥＤＭデータ・ストア（複数可）３０２および外部インタフェースの間で要求および結果を移送するための機構を提供する（例えば、外部インタフェースはクライアントのユーザ・インタフェース３０６、クライアント側ＡＰＩインタフェース３０８、等を含むことができる）。より具体的には、ＲＥＳＴ層３０４によりクライアントインタフェースは大規模なウェブスタイルのネットワーク３１０（例えば、インターネット、大規模なイントラネット、等）上のＥＤＭデータ・ストア（複数可）３０２からエンティティを発見、取得、および更新することができる。ＲＥＳＴ層３０４は要求を管理するために単純なリソース中心モデルを使用する。ＲＥＳＴ層３０４は上で論じたようにステートレスでもあり、リレーショナルな意味を単純化し、ＥＤＭデータ・ストアまたはＲＥＳＴ層のインタフェースのスケーラビリティを最適化する。
【００２９】
ＲＥＳＴ構造は、その少なくとも一部がＲＥＳＴ層３０４を定義し、ＥＤＭエンティティと良く動作する。ＥＤＭエンティティは安定なＵＲＩを伴うリソースとして公開される。係るＵＲＩはＥＤＭスキーマ（例えば、ＥＤＭデータ・ストア（複数可）３０２）により記述される記憶構造を反映する。より具体的には、ＥＤＭスキーマに従ってＥＤＭデータ・ストア（複数可）３０２上のリソースを定義するＵＲＩ名前空間の形で構造化される、ウェブスタイルの転送プロトコル（例えば、ＨＴＴＰプロトコル、等）によって、ＥＤＭデータ・ストア（複数可）３０２にアクセスすることができる。１つのフォーマット例は以下の通りである。
<base URI>/<entity container refx file>[/<entityset>[/<entity key>[/<association navigation property>]]]?<options>
「ｂａｓｅ  ＵＲＩ」は、エンティティ環境（例えば、後でより詳細に論ずる、エンティティ・フレームワーク）およびＲＥＳＴ拡張をホストできるウェブ・サーバまたはウェブ・ディレクトリを指すことができる。「ｒｅｆｘ  ｆｉｌｅ」は、ストアまたはコンテナ（例えば、ＥＤＭデータ・ストア（複数可）３０２）への接続を表し、またエンティティ・セット、エンティティ・キー、およびナビゲーション・プロパティは上で部分的に定義した正規のＥＤＭ構成概念である。オプションとしてデータ表現があり、後でこのオプションをより詳細に説明する。
【００３０】
例として、所与のＥＤＭスキーマがエンティティ・タイプの「カスタマ」をもつ場合、そのインスタンスは「カスタマ」エンティティ・セット内部でグループ化され、後続のＵＲＩが（ＥＤＭデータ・ストア（複数可）３０２内部に含まれるデータ・ストアのサブセットまたはセットを定義できる）エンティティ・セット内部に含まれるカスタマの全てを列挙することができる。即ち、
http://entities.live.com/refx/northwind.refx/Customers
である。さらに、ＥＤＭ構造内にさらに進んで、カスタマのエンティティ・セット内部に含まれる特定のカスタマのインスタンスを、その特定のカスタマのインスタンスに関連するエンティティ・キーを利用することにより識別することができる。前の例を続けると、カスタマ・インスタンスに対するエンティティ・キーが「ＡＬＦＫＩ」である場合、当該カスタマ・インスタンスに関するリソースに移動できるＵＲＩは
http://entities.live.com/refx/northwind.refx/Customers/ALFKI
と書ける。または、代替例として、
http://entities.live.com/refx/northwind/refx/Customers/[ALFKI].
と書ける。係る代替例により、非キー・フィールドを利用するデータ検索機能を可能とすることができる。例えば、
http://entities.live.com/refx/northwind.refx/Customersf[CompanyName =
“Company_One”]
である。
【００３１】
ＥＤＭデータ・ストア（複数可）３０２は、それに関連するＥＤＭスキーマにより記述され、ＲＥＳＴ層３０４を介して公開されるリレーションシップ（例えば、リレーション・エンティティ、リレーション・インスタンス、リレーション・セット、等）を有することができる。前の例を続けると、エンティティ・タイプ「カスタマ」は、それに関係し、ＥＤＭスキーマの一部として定義される、ナビゲーション・プロパティ「ＳａｌｅｓＯｒｄｅｒｓ」をもつ。ナビゲーション・プロパティは、例えば、所与のカスタマとその販売注文との間の関係を表すことができる。エンティティ・タイプ「カスタマ」に関係する販売注文を表すことができるＵＲＩは
http://entities. live.com/refx/northwind.refx/Customers/ALFKI/SalesOrders or, 
alternatively:
のように表すことができる。または代替的に、
http://entities.live.com/refx/northwind.refx/Customersf[ALFKI]/SalesOrders
のように表すことができる。
【００３２】
現在の例で示したＵＲＩはウェブスタイルのネットワーク３１０におけるエンティティへの安定したポインタであり、それにより、例えば、過渡的なアプリケーションまたは長期間の記憶域、またはその両方と関連して、係るＵＲＩが有用となる。さらに例示するため、エンティティ（例えば、「カスタマ」エンティティ・タイプのインスタンス）を指すＵＲＩは、当該エンティティのコピーを取得するための「ＧＥＴ」ＨＴＴＰコマンドを含むことができるか、当該ＵＲＩをそのコマンドと関連して使用することができる。さらに、ＵＲＩはデータ・ストア内部のエンティティ（例えば、上述のＥＤＭデータ・ストア（複数可）３０２内部に含まれる「カスタマ」エンティティ・タイプのインスタンス）を挿入または更新するための「ＰＵＴ」または「ＰＯＳＴ」コマンドを含むことができるか、当該ＵＲＩをそれらのコマンドと関連して使用することができる。
【００３３】
高度なエンティティのタイプ、セット、およびインスタンスを、現在のＥＤＭデータ・モデリング手法を拡張するアクション集合を含むＥＤＭデータ・ストア（複数）３０２によって表すこともできる。アクションは、例えば、ＥＤＭスキーマ中のエンティティを参照することによりＥＤＭの用語で表現することができ、アクションを、（例えば、後の図４でも示す）ＥＤＭスキーマをリレーショナル・ストアおよび／または物理ストアにマップする方式に類似する、実際の実装形態にマップすることができる。ＥＤＭアクションのインスタンスをステートレスで均一なインタフェース（例えば、上のインタフェース１０２、またはＲＥＳＴインタフェース３０４）により公開することができるが、ＥＤＭアクションのインスタンスはリソースの代わりにアクションを表すことができる。例えば、「カスタマ」エンティティ・タイプのようなカスタマ・リソースと対話するとき、以下のＵＲＩを提示した。
http://entities.live.com/refx/northwind.refx/CustomersALFKI (or [ALFKI])
「販売キャンペーンを開始」のようなアクションの例では、カスタマのカテゴリをパラメータとして取り、例えば、以下のＵＲＩによってそのアクションを起動することができる。
http://entities.live.com/refx/northwind.refx/Actions/StartCampaign7customersCategory=/Categories/SMB
【００３４】
さらに、汎用目的の同期インフラを、提示したエンティティの概念に自然に統合することができる。係るインフラが整うと、ＲＥＳＴインタフェース３０４およびＥＤＭデータ・ストア３０２の上に（例えば、ユーザ・インタフェース３０６の一部またはユーザ・インタフェース３０６と関連して）構築したアプリケーションはウェブ規模のネットワークを横断して情報にアクセスできるだけでなく、その情報をローカル・データ・ストア（例えば、ＳＱＬタイプのサーバ管理スキーマ）と同期して、幾つかの電子メールおよび通信アプリケーションと同様なオフラインの動作モードを効果的に提供することもできる。従来のクライアント・サーバ間の複製を超えて、係る同期インフラはピア・ツー・ピアの複製をサポートすることができる。係る複製により、エンティティを伴うＥＤＭストアを保持する複数のピアを有し、システムが長期間同期すると収束する「メッシュ記憶」を形成するアプリケーションを生成することができる。
【００３５】
上述の複製システムに加えて、ＳＳＥ（ｓｉｍｐｌｅ  ｓｈａｒｉｎｇ  ｅｘｔｅｎｓｉｏｎ）の新バージョンとの互換性により、ＳＳＥの条件で動作できるエージェントに渡って相互運用可能な同期が可能となる。ＳＳＥ拡張システム３００を利用すると、ＳＳＥ対応クライアントおよび類似のアプリケーションにより消費可能な、エンティティ・ストア（例えば、エンティティ・データ・ストア（複数可）３０２）の変化を供給することができる。
【００３６】
次に図４を参照すると、ここにはシステム４００が図示されており、それはデータ・ストア（複数可）４０８のＥＤＭ特性（ビュー）４０６を公開するためのＥＤＭ  ＲＥＳＴインタフェース４０４を提供できる中間サーバ・コンポーネント４０２を示す。データ・ストア（複数可）４０８に関するモデリング・スキーマを、エンティティ・フレームワーク４１２に関するマッピング・コンポーネント４１０によりリレーショナル・データ・モデルからＥＤＭモデルに変換することができる。エンティティ・フレームワーク４１２は、データ・プログラミングで利用される抽象化レベルを上げることができる、プログラミング・アーキテクチャである。さらに、エンティティ・フレームワーク４１２はＥＤＭアーキテクチャを取り込むことができ、（例えば、マッピング・コンポーネント４１０を介した）リレーションからＥＤＭへのマッピングを提供することができ、ＬＩＮＱ（ｌａｎｇｕａｇｅ−ｉｎｔｅｇｒａｔｅｄ  ｑｕｅｒｙ）システム（図示せず）を取り込むことができる。
【００３７】
幾つかの特性を一般に、リレーショナル・スキーマをＥＤＭビュー４０６にマップする文脈においてエンティティ・フレームワーク４１２と関連付けることができる。第１に、ＥＤＭビュー４０６は、エンティティを通るために人工的な構成概念を必要としないデータ・モデルを提示する。より具体的には、ＥＤＭビュー４０６では、従来のリレーショナル・データベースとは対照的に、データ・ストアのリソースにアクセスするために必要なＥＤＭ構造以外の特性が規定されない。第２に、エンティティ・フレームワーク４１２のコードはデータベース集約的でありうるが、データベース接続オブジェクトは存在せず、外部言語（例えば、問合せを定式化するためのＳＱＬ）は必要ではなく、パラメータ・バインディングも必要ではない、等である。従って、エンティティ・フレームワーク４１２は、データ中心アプリケーションに対して一般に必要とされる余分な対話を排除することができ、所与のアプリケーションまたはサービスに対して適切なデータのビューからデータベース・スキーマ（例えば、従来のリレーショナル・データベース・スキーマ）を分離することで、新しいレベルのデータ独立を導入することもできる。マッピング・コンポーネント４１０はこのデータ独立を、上で論じたようにリレーショナル・モデルで提示されたデータをＥＤＭモデルに変換できるマッピング仕様によりもたらすことができる。係る変換により、例えば、データ・モデラおよび開発者はリレーショナル・スキーマからよりリッチなＥＤＭスキーマへマップすることができ、続いて実際のデータベース・スキーマとは異なり、かつＥＤＭ構造により定義されるデータの形状を提示することができる。
【００３８】
例えば、「カスタマ」エンティティ・セットはエンティティ・タイプ「カスタマ」のインスタンスを含むことができる。例えば、テーブルが、そのテーブルの列および／または行に含まれるエンティティ・タイプ「カスタマ」のインスタンスをもつエンティティを表すことができる。あるいは、係るテーブルを、それぞれが垂直に配置したデータと、元の従来のデータベースにおける列の部分集合であって例えば異なる名前でありうる列とをもつ、２つのテーブルに変換することができる。さらに、「ＳａｌｅｓＯｒｄｅｒｓ」を定義するＥＤＭスキーマを列として係るテーブルに含めることができる。伝統的には、リレーショナル・データベースにはカスタマのインスタンスに関連する販売注文を指すことができるリレーション・インスタンスはなく、従って係る構成概念は、マッピング・コンポーネント４１０および／またはエンティティ・フレームワーク４１２により提供されるような、ＥＤＭスキーマを提供できる宣言的マッピング仕様により提供されなければならなかったであろう。
【００３９】
ＥＤＭビュー４０６は、エンティティ・モデル（例えば、上で論じたエンティティ・タイプ、インスタンス、およびセット）、リレーションシップ・モデル（例えば、上で論じたリレーションシップ・タイプ、インスタンス、およびセット）、および／またはアクション・タイプのエンティティのような高度なエンティティ・タイプを利用してデータ・ストア（複数可）４０８内部のデータに対してＥＤＭ構造を規定することができる（例えば、アクションをＥＤＭの項で表現し、ＥＤＭスキーマ中のエンティティの名詞に関連付け、データ・ストア内部の実装形態にマップすることができる）。「販売キャンペーンを開始」のような状況は、「カスタマ」エンティティのようなエンティティ・アクションに関係するパラメータを定義し、「カスタマ」エンティティ、「アクション」エンティティ、および幾つかの結果のエンティティ、例えば行使する予算上の制約または「販売キャンペーンを開始」アクションに関係する対象者を相関させることができる。さらに、係るアクションを上述のＲＥＳＴベースの問合せまたはＵＲＩを介して呼び出すことができる）。ＥＤＭ  ＲＥＳＴインタフェース４０４は、上で論じたＬＩＮＱ問合せ（例えば、エンティティに対するＬＩＮＱ）に加えて、データ・ストア（複数可）４０８とインタフェースするためのＵＲＩ問合せ４１８をサポートすることができる。クライアントのプラットフォーム４１６に返された応答４２０は一般に、問合せたデータを指定できる表現形式を利用することができる。さらに、エンティティはインターネット上の特定の表現形式により表されるので、ＵＲＩ問合せ４２０は表現形式問合せ言語を含むこともできる。幾つかの例には、ともにＲＤＦベースの表現問合せ言語であるＲＱＬおよびＳＰＡＲＱＬが含まれる。あるいは、エンティティ・フレームワーク４１２に関する問合せ断片をＵＲＩ問合せ４１８内部で利用することができる。例として、エンティティ・タイプ「カスタマ」に関する全てのエンティティ・インスタンスを要求する問合せを、問合せ断片を介してさらにフィルタすることができる。問合せは、「フィルタ「ｉｔ．Ｓｔａｔｅ＝‘ｗａ’」を適用せよ」を指定するフィルタを適用して、「カスタマ」エンティティ問合せを修正し、関連する「ワシントン」州をもつ、エンティティ・タイプ「カスタマ」の唯一のインスタンスを返すことができることができる。
【００４０】
ビュー・エンジン４１４は、リッチで概念的なＥＤＭスキーマ（例えば、ＥＤＭビュー４０６）からのデータを解釈し、それをクライアントのプラットフォーム４１６側で表示できる強力なクライアント側のエンジンである。より具体的には、クライアントのプラットフォーム４１６はＲＥＳＴベースのＵＲＩ問合せ４１８（または例えば、問合せ情報が要求と応答の対話の内容に取り込まれる他の問合せ形式の）言語を利用して、データ・ストア（複数可）４０８のＥＤＭビュー４０６とインタフェースすることができる。ＲＥＳＴベースの問合せによりクライアントは、上で論じたようにＲＥＳＴアーキテクチャに本来備わるスケーラビリティと均一性のため、インターネットまたは大規模なイントラネットのようなウェブ規模のネットワーク４２２上でＥＤＭビュー４０６とインタフェースすることができる。問合せの結果を、基礎となるデータベースがあたかも物理ストアまたは論理ストアではなくリッチなＥＤＭストアであるかのように、クライアントに対して表現することができる。
【００４１】
ＲＥＳＴスタイルのインタフェース（例えば、ＥＤＭ  ＲＥＳＴインタフェース４０４）は一般に、データ・ストアおよび参照リソースとの対話のための機構を規定するが、問い合わせたデータの形式に関する情報は規定しない。その代わり、応答ではエンティティ表現形式を利用して、クライアントのプラットフォーム４１６に見える（例えば、ビュー・エンジン４１４により表示される）ようにデータ構造を規定することができる。表現形式の例には、ＡＴＯＭ、ＲＳＳ（ｒｉｃｈ  ｓｉｔｅ  ｓｕｍｍａｒｙ）、ＲＤＦ（ｒｅｓｏｕｒｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｆｒａｍｅｗｏｒｋ）、お．よびＪＳＯＮ（ｊａｖａ  ｓｃｒｉｐｔ  ｏｂｊｅｃｔ  ｎｏｔａｔｉｏｎ）、およびＰＯＸ（ｐｌａｉｎ  ｏｌｄ  ＸＭＬ）が含まれる。
【００４２】
ＰＯＸ形式は、準拠すべき特定の仕様をもたない単純でアドホックなデータ形式を指す。係る形式では、エンティティに対する要求の結果、単純なＸＭＬ文書が応答で生成される。図３に関連して与えた例を再び参照すると、
http://entities.live.com/refx/northwind.refx/Customers/ALFKI (or alternatively http://entities. live. com/refx/northwind.refx/Customers/[ ALFKI])
のようなエンティティ・インスタンス「ＡＬＦＫＩ」を指定するＵＲＩは、ＰＯＸエンティティ表現形式を利用する場合は、実質的に
(l.)<Customer>
(2.)<CustomerID>ALFKI</CustomerID>
(3.)<CompanyName> Alfreds Futterkiste</CompanyName>
(4.)<ContactName>Maria Anders</ContactName> 
(5.)<City>Berlin</City> 
(6.)<Country>Germany</Country>
(7.)<SalesOrders href="Customers/ALFKI/SalesOrders" /> 
(8.)</Customer>
のように見えるＸＭＬの結果を生成することができる。応答により提供されるデータを表現するために必要なもの以外のスキーマ、名前空間、または他の構造はＰＯＸエンティティ表現形式には含まれない。例えば、２行目から６行目で与えた値は、例えばエンティティ・インスタンス（ＡＬＦＫＩ）に関連する企業名（Ａｌｆｒｅｄｓ  Ｆｕｔｔｅｒｋｉｓｔｅ）および都市（Ｂｅｒｌｉｎ）のような、エンティティ・タイプ（例えば、「カスタマ」）に関連する（上述の）プロパティしか含まない。行７で与えた値、ＳａｌｅｓＯｒｄｅｒｓはエンティティ・タイプのプロパティではないが、リレーションシップ（例えば、このカスタマと関連する販売注文との関連を規定するリレーションシップ）を表す（上述の）ナビゲーション・プロパティである。
【００４３】
前の例で示したＰＯＸ形式は、システム４００のデータ・ストア（複数可）４１０への要求に対するデフォルトの応答形式であることができる。係るシステム４００により期待される形式を、単純に標準的な「Ａｃｃｅｐｔ」ＨＴＴＰヘッダを用いることでさらに示すことができる。ＨＴＴＰヘッダ形式により、エンティティのアドレスまたは識別子を任意の特定の表現から分離することができる。係る分類により、特定の要件に従ってＵＲＩをカスタマイズすることができる。さらに、データ表現形式をＵＲＩ内部で指定できることに留意されたい。ｒｅｓｐｏｎｓｅＴｙｐｅオプションが「Ａｃｃｅｐｔ」ＭＩＭＥ（ｍｕｌｔｉ−ｐｕｒｐｏｓｅ  ｉｎｔｅｒｎｅｔ  ｍａｉｌ  ｅｘｔｅｎｓｉｏｎ）タイプの「ｔｅｘｔ／ｘｍｌ」（「＊／＊」でもよい）を指定する場合、ＰＯＸ表現形式はデータ表現に対しても使用される。ＨＴＴＰヘッダがカスタマイズできないか、または不十分である場合、問合せ文字列パラメータの使用をシステム４００によりサポートすることができる。
【００４４】
ＵＲＩ問合せ４１８が、「ａｐｐｌｉｃａｔｉｏｎ／ｒｄｆ＋ｘｍｌ」を指定する「Ａｃｃｅｐｔ」ＭＩＭＥタイプに関する場合、応答４２０はＲＤＦ表現形式を利用して、送信されたデータを表現する。ＲＤＦは、民間業界の幾つかの部門（例えば、Ｗｅｂ２．０およびセマンティック・ウェブに関心がある団体）により好まれている既存の表現プロトコルである。ＲＤＦは表現力の高い形式であり、リソース間の関係を上手く扱い、ＵＲＩ要求を介してリレーションシップを公開する（システム４００のような）システムに良く適合する。前の例で提示したＵＲＩ要求
http://entities.live.com/refx/northwind.refx/Customers/ALFKI?responseType= application/rdf+xml
は
<rdf:RDF xml:base=http://entities. live.com/refx/northwind.rfx
Xmlns :rdf="http ://www. w3.org/ 1999/02/22-rdf-syntax-ns#>
<Customer rdf : about="Customers/ALFKI"> 
<CustomerID>ALFKI</CustomerID> 
(3.)<CompanyName> Alfreds 
Futterkiste</CompanyName>
(4.)<ContactName>Maria Anders</ContactName> 
(5.)<City>Berlin</City> 
(6.)<Country>Germany</Country> 
(7.)<SalesOrders 
rdf:resource="Customers/ALFKI/SalesOrders"/>
</Customer) 
</rdf:RDF>
に実質的に類似するＲＤＦ表現形式をクライアントのプラットフォーム４１６側で提供することができる。係る結果は上述のＰＯＸ形式により提供される結果の例と類似しており、コンパクトな符号化を利用するときの妨害を最小限とすることができる。このＲＤＦの例で提示される結果は、「カスタマ」エンティティ・インスタンスも表現する。さらに、この結果は、やはりＲＤＦリソース（例えば、ＳａｌｅｓＯｒｄｅｒ要素のｒｄｆ：ｒｅｓｏｕｃｅ属性）として表現される問合せ元に関する情報（例えば、ルート要素内の「ｘｍｌ：ｂａｓｅ」）およびリレーションシップ・インスタンスを含む。ＲＤＦプロセッサ（図示せず）は、このカスタマが与えられると、単純に特定のＲＤＦプロパティに対する「ｂａｓｅ」および「ｒｅｓｏｕｒｃｅ」ポインタから新規ＵＲＩを公開することでその注文を調査することができる。
【００４５】
応答４２０を介してクライアントのプラットフォーム４１６に送達されるデータに対する別の表現形式の例はＪＳＯＮ形式である。「Ａｃｃｅｐｔ」ＭＩＭＥタイプが「ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ」、「ｔｅｘｔ／ｊｓｏｎ」または「ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ」、あるいはそれらの組合せを指定すると、応答データに対するＪＳＯＮ形式が生成されるであろう。ＪＳＯＮはクライアント・エージェント（例えば、クライアント・プラットフォーム４１６、ウェブ・ブラウザ、等）に、データをオブジェクトとして提示するためのサポートを実質的に即座に与えることができる。ＡＳＰ．ＮＥＴ  Ａｊａｘ（ａｔｌａｓ）のようなツールをＪＡＳＯＮ形式で構築することができる。
【００４６】
前の例を続けると、ＵＲＩの例
http://entities.live.com/refx/northwind.refx/Customers/ALFKI?responseType=text/ json
内部で「ｔｅｘｔ／ｊｓｏｎ」の「Ａｃｃｅｐｔ」ＭＩＭＥヘッダを利用すると、
{
'_base': 'http://entities. live.com/refx/northwind.refx',
' about': 'Customers/ALFKF,
'CustomerID': 'ALFKI',
'CompanyName': 'Alfreds Futterkiste',
'ContactName': 'Maria Anders ' ,
'City': 'Berlin'
'Country': 'Germany'
'SalesOrders': { '_resource': 'Customers/ALFKI/SalesOrders'}
}; 
と実質的に類似するデータ形式を提供することができる。本発明の様々な態様に従う、ＪＳＯＮ、ＰＯＸ、およびＲＤＦ以外の他の表現形式が返されたデータに対する形式を提供できることは理解されよう。
【００４７】
次に図５を参照すると、本発明の特定の態様に従う、ステートレスで均一なインタフェースを介してＥＤＭストアを公開するための方法の例が示されている。参照番号５０２で、リソース・ストアを少なくとも１つのＥＤＭ（ｅｎｔｉｔｙ  ｄａｔａ  ｍｏｄｅｌ）の項目により定義する。リソース・ストアは、任意の適切な物理記憶装置または仮想記憶装置であることができ、例えば、サーバを含む。ＥＤＭ項目は例えば、エンティティ・タイプ、エンティティ・インスタンス、エンティティ・セット、またはそれらの組合せであることができる。さらに、ＥＤＭ項目は、例えばエンティティ・タイプ、インスタンス、またはセットの特性を提供するか、複数のエンティティ・タイプ、インスタンス、またはセットを相互に関連づけるリレーションシップ・タイプ、リレーション・インスタンス、またはリレーション・セットを含むことができる。方法５００によると、エンティティ・セットを、特定のエンティティ・インスタンスを含むテーブルと実質的に同様に表すことができる。さらに、エンティティ・セットまたはリレーション・セットを、係るセットまたは係るセットの組合せに関係するエンティティ・コンテナにグループ化することができる。エンティティ・セットをテーブルと実質的に同様に表すことができる一方、エンティティ・コンテナをデータベースと実質的に同様に表すことができる。本明細書で開示したシステムに関連して上述したＥＤＭ項目とデータ・ストアの間の相関は、参照番号５０２での方法５００を含めて、同様に本明細書で説明した方法に適用可能であることは理解されよう。
【００４８】
参照番号５０４で、ステートレスで均一なインタフェースを少なくとも１つのＥＤＭ項目にマップする。係るインタフェースはＥＤＭ項目および／またはリソース・ストアに関係する情報を公開し、リソース・ストアに関係する問合せおよび応答を移送する。当該インタフェースは係るデータを要求するアプリケーションと独立してデータを転送する。係るインタフェースによりアプリケーションは独立して発展し、リソース・ストア内に含まれるデータを表示するデータ表現形式をサポートすることができる。さらに、当該インタフェースにより、リソース・ストアと他のコンポーネントとの間でのステートレスな対話が可能となる。従って、記憶コンポーネントは他のコンポーネントとの以前のトランザクションに関するデータを保持する必要はないことになる。従って、ステートレスな対話が、インターネットおよび大規模なネットワークを含む広大でウェブスタイルのネットワークが必要とするネットワークのスケーラビリティの提供において重要でありうる。結果として、方法５００により、リソース・ストア上で高い表現力の方法でモデル化したデータをインターネットに公開し、スケーラビリティ要件を満たしつつ、アプリケーションの独立性、即ち、係る環境での成功に必要な特性を提供することができる。
【００４９】
次に図６を参照すると、ＥＤＭ構造を介して表現力の高い方法でモデル化したデータを、インターネット上のデータ・ストアに間い合わせ、そこから受け取るための方法が示されている。参照番号６０２で、リソース・ストア、および／またはそこに含まれるデータを少なくとも１つのＥＤＭ項目により定義する。上述のように、ＥＤＭ項目は、仮想エンティティまたは実世界エンティティを、係る定義に対する高い表現力の構成概念を用いて明示的に定義し、さらにその定義をリソース・ストアと見なすことができる。ＥＤＭ項目は、従来のリレーショナル・モデルより高レベルの抽象化によりデータまたはリソース・ストアの記述を可能とする層状構造を生成することができる。６０４で、少なくとも１つのＥＤＭ項目をステートレスで均一なインタフェースにマップする。係るインタフェースにより、問合せと問合せへの応答とをリソース・ストアへ送信およびリソース・ストアから送信することができる。ステートレスで均一な対話により、インターネットのような広大なウェブスタイルのネットワークを優れたエンティティとするスケーラビリティおよびアプリケーション独立が実現される。結果として、リソース・ストアが指定のインタフェースにマップされるとき、インターネットを介して当該リソース・ストアを公開することができる。
【００５０】
参照番号６０６で、インタフェースを介して問合せをリソース・ストアに移送する。係る問合せは、適切に応答することが必要な全ての情報を含むことができる。問合せを、ＥＤＭ項目を表すＥＤＭスキーマに従って構成することができる。例えば、問合せは上述のようにＥＤＭ構造を表現するＵＲＩ形式に基づくことができる。さらに、問合せは、ＥＤＭでモデル化したリソース・ストアを区別するのに十分なＬＩＮＱ形式であることができる。さらに、問合せは、ＲＱＬまたはＳＰＡＲＱＬのような表現形式問合せ言語であることができる。インターネット・ストア上でモデル化されたエンティティを表現形式で記述できるので、係る言語は適切でありうる。
【００５１】
上で規定したＥＤＭ問合せにより、リソース・ストアは、当該問合せ自体のみを利用して特定のＥＤＭエンティティまたはリレーションシップの状態に対応するデータを発見することができる。参照番号６０８で、その中にエンティティ表現形式で表現したデータを含む問合せの結果をインタフェースを介して受け取る。係る表現形式は、１つまたは複数のリソース・ストア内部に含まれるデータを適切に記述することができる。方法６００の様々な態様に従う表現形式の例にはＪＳＯＮ、ＲＤＦおよびＰＯＸが含まれる。他の形式にＡＴＯＭおよびＲＳＳを含めることができるが、装置側でＥＤＭ構造化データを表すために最も適切な形式であればどのような形式でも方法６００の文脈内で適切である。
【００５２】
図７を参照すると、ＲＥＳＴインタフェースを介してＥＤＭ構造に従ってモデル化したインターネット上のデータ・ストアで問合せを受け取り、問合せに応答する方法が示されている。７０２で、問合せを、ＥＤＭでモデル化したインターネットのデータベースにおいてＲＥＳＴインタフェースを介して受け取る。ＲＥＳＴモデルは、大規模なネットワーク環境で効果的と証明されている、幾つかの装置インタフェースの制約を提供する。係る制約の幾つかの例を以下に列挙する。第１に、ＲＥＳＴはステートレスな対話を提供し、それによりネットワーク・コンポーネントは以前のデータ転送動作に関係する情報を保持する必要がなくなる。これにより、コンポーネントのリソースを迅速に消去し、ネットワークのスケーラビリティを拡大することができる。第２に、均一なコンポーネントのインタフェースにより、ハイパーメディア・データ（例えば、ストリーミング・ビデオ、オーディオ、ボイス・オーバ・インターネット・プロトコルＩＰ、等）の粒度の大きな転送が実現される。第３に、クライアント側およびサーバ側のキャッシュにより、反復的な要求から生ずるリソース要求の軽減を支援することができる。第４に、システムの複雑性に上限を設け、コンポーネント間の独立を促進する、層状コンポーネント・アーキテクチャである。
【００５３】
ＲＥＳＴモデルは、インターネットのような大規模なネットワーク環境におけるデータベースとの対話に対しては非常に良好であったが、従来は、表現力が高く、モデル化されたデータを単純かつ均一な方法でインターネットに公開するためのエンド・ツー・エンドのフレームワークは存在していなかった。ＲＥＳＴインタフェースをＥＤＭモデリングのアプローチと対にすることで、係るフレームワークを提供することができる。参照番号７０２で明記するように、インターネット・データベースに対する問合せではＥＤＭアーキテクチャに関連する単純な形式を利用することができ、その形式には、例えば、本明細書で説明したようにＥＤＭ構造にマップされ、エンティティ・タイプ、インスタンス、および／またはセット、プロパティ、等を規定するＵＲＩ、ＬＩＮＱ問合せ言語、あるいは上で規定したデータ表現形式問合せ言語が含まれる。係る問合せは一般に、エンティティ・インスタンス、セット、コンテナ、タイプ、または同様なＥＤＭ構成概念により表されるリソース・ストアを指すことに留意されたい。データを係るストアに含めないことも可能であるが、係る問合せは依然として有効であり、係るリソース・ストア中にデータがないことを示す応答をなお送信することができる。
【００５４】
７０４で、１つまたは複数のリレーショナル・データベース・ストアに記憶された問合せに関係するデータを表現形式に従ってフォーマットすることができる。一般に、ＲＥＳＴアーキテクチャはデータ自体をどのようにフォーマットすべきかについては規定しない。例えばＪＳＯＮ、ＲＤＦ、およびＰＯＸを含む独立な形式により、係るデータを規定することができる。７０６で、フォーマットされたデータを含む応答を、ＲＥＳＴインタフェースを介して送信する。
【００５５】
次に図８を参照すると、リレーショナル・データベースと対話し、そこに記憶したリレーショナル・データをよりリッチなＥＤＭ形式にクライアント装置側で変換する方法８００が示されている。８０２で、問合せを（上述の）ＲＥＳＴインタフェースを介してインターネットのリレーショナル・データベースに送信する。問合せは、リレーショナル・データベースにアクセスするための当分野で公知な任意の標準的な形式であることができる。さらに、問合せは、本明細書で説明したエンティティ・フレームワーク・アーキテクチャ内部で利用される、ＬＩＮＱ問合せ、リレーショナル・データベース構造にマップしたＵＲＩ、等のような形式であることもできる。８０４で、データを含む問合せの結果をリレーショナル構造で受け取る。８０６で、データをよりリッチなＥＤＭ形式にクライアント装置側で構造化し、場合によってはクライアント装置上にそのように表示することができる。係る変換を、クライアント側の、宣言的マッピング仕様を利用する（例えば、上で論じたエンティティ・フレームワークに関連する）ビュー・エンジンにより実行することができる。方法８００に従う宣言的マッピング仕様により、データを、リレーショナル・データベース構造により指定されるものとは異なる形で提示することができる。より具体的には、ウェブ開発者およびデータ・モデラはデータをよりリッチなＥＤＭ構造でクライアント・コンポーネント側に提示することができる。
【００５６】
次に図９を参照すると、開示したアーキテクチャを実行するように動作できる例示的なコンピュータ・システムのブロック図が示されている。本発明の様々な態様に対して追加の文脈を与えるため、図９およびそれに続く議論では、本発明の様々な態様を実装できる適切なコンピューティング環境９００の簡潔で一般的な説明を与えることを意図している。さらに、本発明を１つまたは複数のコンピュータ上で実行できるコンピュータ実行可能命令の一般的な文脈で上述したが、本発明を他のプログラム・モジュールならびに／またはハードウェアおよびソフトウェアの組合せとして実装することもできることは、当業者には理解されよう。
【００５７】
一般に、プログラム・モジュールには、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造、等が含まれる。さらに、本発明を、単一プロセッサまたはマルチプロセッサのコンピュータ・システム、ミニコンピュータ、メインフレーム・コンピュータだけでなく、パーソナル・コンピュータ、ハンドヘルド・コンピューティング装置、マイクロプロセッサベースまたはプログラム可能な消費家電、等を含む他のコンピュータ・システム構成で実施でき、それらの各々を１つまたは複数の関連装置に動作可能に結合できることは当業者には理解されよう。
【００５８】
例示した本発明の態様を、或る種のタスクが通信ネットワークを通して接続されたリモート処理装置により実行される、分散コンピューティング環境で実施してもよい。分散コンピューティング環境では、プログラム・モジュールをローカル・メモリ記憶およびリモート・メモリ記憶の両方に配置することができる。
【００５９】
コンピュータは一般に様々なコンピュータ読取可能媒体を含む。コンピュータ読取可能媒体は、コンピュータがアクセスできる任意の使用可能な媒体であることができ、揮発性および不揮発性媒体、取外し可能および取外し不能媒体の両方を含むことができる。限定ではなく例として、コンピュータ読取可能媒体はコンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読取可能命令、データ構造、プログラム・モジュールまたは他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性および不揮発性媒体、取外し可能および取外し不能媒体の両方を含むことができる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または所望の情報の記憶に使用できコンピュータによりアクセスできる他の任意の媒体が含まれるが、これらに限定されない。
【００６０】
通信媒体は一般にコンピュータ読取可能命令、データ構造、プログラム・モジュールまたは他のデータを搬送波または他の伝送方式で具現化し、任意の情報送達媒体を含む。「変調データ信号」という用語は、その１つまたは複数の特性集合を有するか信号内の情報をエンコードするよう変化した信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線および他の無線媒体のような無線媒体が含まれる。上の何れかの組合せもコンピュータ読取可能媒体の範囲に含まれるべきである。
【００６１】
図９を再度参照すると、本発明の様々な態様を実装するための例示的な環境９００はコンピュータ９０２を含み、コンピュータ９０２は処理装置９０４、システム・メモリ９０６およびシステム・バス９０８を含む。システム・バス９０８はシステム・コンポーネントを処理装置９０４に結合させる。当該システム・コンポーネントにはシステム・メモリ９０６が含まれるがこれに限らない。処理装置９０４は様々な商用的に使用可能なプロセッサの何れかであることができる。デュアル・マイクロプロセッサおよび他のマルチプロセッサ・アーキテクチャを処理装置９０４として使用してもよい。
【００６２】
システム・バス９０８は、（メモリ・コントローラを伴うかまたは伴わない）メモリ・バス、周辺バス、および様々な商用的に使用可能なバス・アーキテクチャの何れかを用いたローカル・バスにさらに相互接続できる数種のバス構造の何れかであることができる。システム・メモリ９０６は、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）９１０およびＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）９１２を含むことができる。ＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）はＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭのような不揮発性メモリ９１０に記憶される。ＢＩＯＳは、例えば起動中に、コンピュータ９０２内部の要素間での情報の伝送を支援する基本ルーチンを含む。ＲＡＭ９１２はデータをキャッシュするためのスタティックＲＡＭのような高速ＲＡＭを含むこともできる。
【００６３】
コンピュータ９０２はさらに、内部ＨＤＤ（ｈａｒｄ  ｄｉｓｋ  ｄｒｉｖｅ）９１４（例えば、ＥＩＤＥ、ＳＡＴＡ）、（例えば、取外し可能ディスク９１８を読み書きするための）磁気ＦＤＤ（ｆｌｏｐｐｙ  ｄｉｓｋ  ｄｒｉｖｅ）９１６、（例えば、ＣＤ−ＲＯＭディスク９２２を読むか、ＤＶＤのような他の大容量光媒体を読み書きするための）光ディスク・ドライブ９２０を含む。内部ＨＤＤ９１４を、適切なシャーシ（図示せず）内で外付け使用するために構成してもよい。ハード・ディスク・ドライブ９１４、磁気ディスク・ドライブ９１６および光ディスク・ドライブ９２０を、それぞれハード・ディスク・ドライブ・インタフェース９２４、磁気ディスク・ドライブ・インタフェース９２６および光ドライブ・インタフェース９２８によりシステム・バス９０８に接続することができる。外付けドライブの実装形態のためのインタフェース９２４は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）およびＩＥＥＥ１３９４インタフェース技術のうち少なくとも１つまたはその両方を含む。他の外付けドライブ接続技術も本発明では考慮している。
【００６４】
ドライブおよびその関連コンピュータ読取可能媒体は、データ、データ構造、コンピュータ実行可能命令、等の不揮発性記憶を提供する。コンピュータ９０２の場合、当該ドライブおよび媒体は適切なデジタル形式での任意のデータの記憶に対応する。上のコンピュータ読取可能媒体の説明ではＨＤＤ、取外し可能磁気ディスク、ＣＤまたはＤＶＤのような取外し可能光媒体に言及したが、ジップ・ドライブ、磁気カセット、フラッシュ・メモリ・カード、カートリッジ、等のような、コンピュータにより読取可能な他種の媒体を例示的な動作環境で使用してもよく、さらに、係る媒体は本発明の方法を実施するためのコンピュータ実行可能命令を含むことができることは当業者には理解されよう。
【００６５】
オペレーティング・システム９３０、１つまたは複数のアプリケーション・プログラム９３２、他のプログラム・モジュール９３４およびプログラム・データ９３６を含む、幾つかのプログラム・モジュールをドライブおよびＲＡＭ９１２に記憶することができる。オペレーティング・システム、アプリケーション、モジュール、および／またはデータの全てまたは一部をＲＡＭ９１２にキャッシュすることもできる。本発明を様々な商用的に使用可能なオペレーティング・システムまたはオペレーティング・システムの組合せで実装できることは理解されよう。
【００６６】
ユーザは１つまたは複数の有線または無線の入力装置、例えば、キーボード９３８およびマウス９４０のようなポインティング・デバイスを通してコンピュータ９０２にコマンドおよび情報を入力することができる。他の入力装置（図示せず）としてマイクロフォン、ＩＲリモート・コントロール、ジョイスティック、ゲーム・パッド、スタイラス・ペン、タッチ・スクリーン、等を含めることができる。これらおよび他の入力装置は、システム・バス９０８に接続される入力装置インタフェース９４２を通して処理装置９０４に接続されることがよくあるが、パラレル・ポート、ＩＥＥＥ１３９４シリアル・ポート、ゲーム・ポート、ＵＳＢポート、ＩＲインタフェース、等のような他のインタフェースにより接続することができる。
【００６７】
モニタ９４４または他種の表示装置も、ビデオ・アダプタ９４６のようなインタフェースを介してシステム・バス９０８に接続される。モニタ９４４に加えて、コンピュータは一般にスピーカ、プリンタ、等のような他の周辺出力装置（図示せず）を含む。
【００６８】
コンピュータ９０２は、リモート・コンピュータ（複数可）９４８のような１つまたは複数のリモート・コンピュータへの有線および／または無線通信を介した論理接続を用いてネットワーク環境で動作することができる。リモート・コンピュータ（複数可）９４８はワークステーション、サーバ・コンピュータ、ルータ、パーソナル・コンピュータ、ポータブル・コンピュータ、マイクロプロセッサベースの娯楽機器、ピア・デバイスまたは他の一般的なネットワーク・ノードであることができ、一般にコンピュータ９０２に関して説明した要素の多くまたは全てを含むが、簡潔さのため、メモリまたは記憶装置９５０のみを示してある。図示した論理接続はＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）９５２および／またはそれより大きいネットワーク、例えば、ＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）９５４への有線または無線接続を含む。係るＬＡＮおよびＷＡＮネットワーク環境は職場および企業で一般的であり、イントラネットのような企業規模のコンピュータ・ネットワークを円滑にする。これらの全てを、グローバル通信ネットワーク、例えばインターネットに接続することができる。
【００６９】
ＬＡＮネットワーク環境で使用するとき、コンピュータ９０２は有線および／または無線通信ネットワーク・インタフェースまたはアダプタ９５６を通してローカル・ネットワーク９５２に接続される。アダプタ９５６はＬＡＮ９５２への有線または無線通信を容易にすることができ、無線アダプタ９５６と通信するためのそれ自体に配置した無線アクセス・ポイントを含むこともできる。
【００７０】
ＷＡＮネットワーク環境で使用するとき、コンピュータ９０２はモデム９５８を含むことができ、またはＷＡＮ９５４上の通信サーバに接続され、または例えばインターネットによってＷＡＮ９５４上で通信を確立するための他の手段を有する。モデム９５８は、内部または外部にあることができ、かつ有線または無線装置であることができ、シリアル・ポート・インタフェース９４２を介してシステム・バス９０８に接続される。ネットワーク環境では、コンピュータ９０２に対して図示したプログラム・モジュール、またはその一部をリモートのメモリまたは記憶装置９５０に記憶することができる。図示したネットワーク接続は例であってコンピュータ間の通信リンクを確立する他の手段を使用できることは理解されよう。
【００７１】
コンピュータ９０２は無線接続において動作可能に配置した任意の無線装置またはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルなコンピュータ、ポータブル・データ・アシスタント、通信衛星、無線検出可能なタグに関連する任意の装置または位置（例えば、キオスク、新聞販売店、化粧室）、および電話と通信するよう動作可能である。これは少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ「商標」の無線技術を含む。従って、通信は、従来のネットワークまたは単純に少なくとも２つの装置間のアドホック通信を伴う所定の構造であることができる。
【００７２】
Ｗｉ−Ｆｉすなわちワイヤレス・フィデリティにより、家のソファ、ホテルの部屋のベッド、または職場の会議室から、配線なしにインターネットに接続することができる。Ｗｉ−Ｆｉは、例えばコンピュータのような装置が基地局の範囲内でればどこでも部屋の内外でデータを送受信できるようにする携帯電話で使用されるものと同様な無線技術である。Ｗｉ−Ｆｉネットワークは、安全で信頼度が高く、高速な無線接続を提供するためのＩＥＥＥ８０２．１１（ａ，ｂ，ｇ、等）と呼ばれる無線技術を使用する。Ｗｉ−Ｆｉネットワークを使用してコンピュータを互いのコンピュータと、インターネットと、および（ＩＥＥＥ８０２．３またはイーサネット（登録商標）を使用する）有線ネットワークと接続することができる。Ｗｉ−Ｆｉネットワークは、例えば、無許可の２．４および５ＧＨｚ無線帯域において、１１Ｍｂｐｓ（８０２．１１ａ）もしくは５４Ｍｂｐｓ（８０２．１１ｂ）データ速度で、または両方の帯域（デュアル・バンド）を含む製品とともに動作し、従ってネットワークは多くの職場で使用される基本的な９ＢａｓｅＴの有線イーサネット（登録商標）・ネットワークと同様な実世界の性能を提供することができる。
【００７３】
次に図１０を参照すると、開示したアーキテクチャを実行するように動作する例示的なコンピュータ集合システムの略ブロック図が示されている。システム１０００は１つまたは複数のクライアント（複数可）１００２を含む。クライアント（複数可）１００２はハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）であることができる。クライアント（複数可）１００２は、例えば、本発明を使用することでクッキー（複数可）および／または関連するコンテクスト情報を収容することができる。
【００７４】
システム１０００は１つまたは複数のサーバ（複数可）１００４も含む。サーバ（複数可）１００４はハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）であることができる。サーバ１００４は、例えば、本発明を使用することで、変換を実施するためのスレッドを収容することができる。クライアント１００２およびサーバ１００４の間の１つの可能な通信形態は、複数のコンピュータ・プロセス間で送信されるよう適応させたデータ・パケットである。当該データ・パケットは例えばクッキーおよび／または関連するコンテクスト情報を含むことができる。システム１０００は、クライアント（複数可）１００２およびサーバ（複数可）１００４の間での通信を容易にするために使用できる通信フレームワーク１００６（例えば、インターネットのようなグローバル通信ネットワーク）を含む。
【００７５】
通信を有線（光ファイバを含む）および／または無線技術を介して円滑にすることができる。クライアント（複数可）１００２は、クライアント（複数可）１００２にローカルな情報（例えば、クッキー（複数可）および／または関連するコンテクスト情報）の記憶に使用できる１つまたは複数のクライアント・データ・ストア（複数可）１００８に動作可能に接続される。同様に、サーバ（複数可）１００４は、サーバ（複数可）１００４にローカルな情報の記憶に使用できる１つまたは複数のサーバ・データ・ストア（複数可）１０１０と動作可能に接続される。
【００７６】
以上で説明したことには様々な実施形態の例が含まれる。もちろん、実施形態を説明する目的で構成要素または方法の考えられる組合せの全てを説明することは不可能であるが、多くのさらなる組合せおよび並びが可能であることは当業者には理解されよう。従って、詳細な説明では、添付の特許請求の範囲の趣旨および範囲内にある全ての係る変更、修正、および変更を含むことを意図している。
【００７７】
特に、上述のコンポーネント、装置、回路、システム、等により実行される様々な機能に関して、係る構成要素を説明するために使用した用語（「手段」への参照を含む）は、特に明記しない限り、説明した構成要素の特定の機能を実行する任意の構成要素（例えば、機能的な相当物）に対応し、開示した構造と構造的に均等でなくとも、本明細書で説明した実施形態の例示的な態様における機能を実行することを意図している。この点で、実施形態はシステムだけでなく、様々な方法の動作および／またはイベントを実行するためのコンピュータ実行可能命令を有するコンピュータ読取可能媒体も含むことは理解されよう。
【００７８】
さらに、特定の特徴を幾つかの実装形態のうちの１つのみに関して開示したが、係る特徴を、任意の所与または特定の適用に対して望ましく有利でありうる他の実装形態の１つまたは複数の他の特徴と組み合わせてもよい。さらに、発明を実施するための形態または特許請求の範囲において用語「含む」およびその変形を使用する限りでは、これらの用語は用語「備える」と同様に包括的であることを意図している。
【図１】
2010519624.tif 000003
【図２】
2010519624.tif 000004
【図３】
2010519624.tif 000005
【図４】
2010519624.tif 000006
【図５】
2010519624.tif 000007
【図６】
2010519624.tif 000008
【図７】
2010519624.tif 000009
【図８】
2010519624.tif 000010
【図９】
2010519624.tif 000011
2010519624.tif 000012
【図１０】
2010519624.tif 000013
【国際調査報告】
2010519624.tif 000014
2010519624.tif 000015
2010519624.tif 000016