JP2013522768A - ネットワーク化サービスとしての情報に対するクエリモデル - Google Patents

Abstract

データは発行者によって、データセットを受信するように構成され、消費者がそのデータセットをクエリにより消費するのを可能にする情報サービスに発行される。データセットの構成情報（例えば、コラム情報）は、データセットのどの情報を検索パラメータとすることができるか、およびどの情報をクエリ結果として返すことができるかを選択するために発行者に提示される。クエリインタフェースは、発行者による選択に基づいて自動的に生成され、バックエンドデータベースは、そのようなクエリインタフェースについて、例えば、発行者によって選択された選択パラメータまたはクエリ結果に基づいたインデックスの作成のために最適化される。クエリアグリゲータは、所与のクエリインタフェースを他のクエリインタフェースと自動的に組み合わせて、所与のクエリインタフェースと他のクエリインタフェースとの許可の共通部分に基づいてより複雑な（それでも許可された）クエリを形成する。

Description

本開示は、発行者によって様々な消費オプションのためにネットワーク化されたストレージサービスに発行されたデータセットに対して、異なるクエリを柔軟に定義することに関する。

いくつかの従来のシステムに関する背景としては、コンピューティング装置は従来的に、その装置に対してローカルに、アプリケーション、およびデータサービスを実行する。さらに、オンラインおよびクラウドサービスの進化により、アプリケーションおよびデータサービスは、装置の代わりに所与のサービスの一部または全てを行うネットワークプロバイダに移動しつつある。テラバイトのデータ（将来的に、ペタバイト、エクサバイト等のデータの可能性もある）を記憶することができるネットワークストレージファームの進化は、主装置と外部記憶装置との分離により、クラウドにおいてローカルシナリオを模倣する機会を作っている。

しかしながら、データ所有者および発行者からのデータの記憶の分離は、アプリケーション開発者およびデータの消費者からの分離のように、データが以前のように消費者のローカル装置で無制限に表現される場合には存在しない問題を作り出す。それはデータの情報漏洩、再分配、無制限使用の可能性のためにコンテンツ所有者に関係した状況である。しかしながら、いずれのクラウドサービスおよびネットワークストレージプロバイダも、任意のプラットフォームにおけるサービスとしての情報を、容易に発行し、アプリケーションを指定し、および任意の種類のデータを使用することができるように発行者、開発者および消費者に、関与される全てについて追跡および監査することができ、そしてその結果それらのコンテンツに対する制限を実施できることを発行者に保証することができる方法で効果的に提供することができていない。さらに、特に有益なデータを有するコンテンツ所有者または発行者のために、データへのアクセスを制御することに関する問題はさらに重要になる。そのような有益なデータをネットワーク化ストレージサービスに渡してしまうと、誰がアクセスを得るのか、どのような種類のクエリが消費者または開発者に提示されるのか等の問題に、特定の種類のデータ用に設計された専用のカスタム解決策なしに回答することは難しい。

上記した今日のネットワーク化ストレージサービスの欠陥は単に、従来のシステムの問題のいくつかの概要を提供することを意図しており、網羅的なものではない。先端の技術分野に関連する他の問題および様々な非限定的な実施形態の一部の対応する利点は、以下の詳細な説明からさらに明らかになる。

本明細書において、詳細な説明および添付図面に続く例示の非限定的な実施形態の様々な態様の基本的なまたは一般的な理解を可能にするのを助けるため簡略な要約を提供する。しかしながら、本概要は、広範囲のまたは完全な概要として意図されていない。代わって、本概要の１つの目的は、一部の例示的の非限定的な実施形態に関連する一部の概念を、以下の様々な実施形態の詳細な説明の前置きとして簡略化した形提示することである。

様々な実施形態において、データは、発行者によって、データセットを受信するように構成された情報サービスに発行され、消費者がクエリを介してそのデータセットを使用することを可能にする。そのデータセットの構造情報（例えば、コラム情報）は、発行者が、データセットのどの情報を検索パラメータとするか、およびどの情報がクエリ結果として返されるべきかを選択するために、個別の対話の一部として発行時またはその後に発行者に提示される。

発行者による選択に基づいてクエリインタフェースを自動的に作成することができ、そのようなクエリインタフェース、例えば、発行者によって選択された検索パラメータまたはクエリ結果に基づいたインデックスの作成のため、バックエンドデータベースを自動的に最適化することができる。クエリアグリゲータは、所与のクエリインタフェースおよび他のクエリインタフェースに対する許可のインタセクションに基づいて、所与のクエリインタフェースを他のクエリインタフェースと自動的に組み合わせて、より複雑な（しかし、まだ許可されている）クエリを形成することができる。

他の実施形態および様々な非限定的な実施例、シナリオおよび実施を、以下に詳細に説明する。

様々な非限定の実施形態は添付図面を参照してさらに説明される。

一実施形態に係るテーブルまたは他の構造化データの例を示すブロック図である。 本明細書で説明される１つまたは複数の実施形態によって対処される従来のシステムの１つまたは複数の制限を示すブロック図である。 １つまたは複数の実施形態に従って、発行されたデータセットに対して異なるクエリを定義するクエリ定義モデルおよび対応するインタフェースを示すブロック図である。 １つまたは複数の実施形態について本明細書で説明される、クエリの形成および最適化に関連して使用するための検索の述語および結果に対する制限を含むデータセットからの構造化情報の選択を示すブロック図である。 １つまたは複数の実施形態について本明細書で説明される、クエリの形成および最適化に関連して使用するための検索の述語および結果に対する制限を含むデータセットからの構造化情報の選択を示すブロック図である。 一実施形態に従って、指定された検索可能な情報および指定された戻り結果に基づいたアクセスクエリの生成を示すブロック図である。 １つまたは複数の実施形態に従って自動的に生成されるクエリＡＰＩの消費を示すブロック図である。 クエリ比較および／または類似に基づいたＡＰＩの集合またはハイブリッドＡＰＩの形成のブロック図である。 一実施形態に従って、指定された検索可能な情報および指定された戻り結果に基づいたデータベース最適化を示すブロック図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャに従ってデータをホストするか、またはホストされたデータに接続して、クエリインタフェースを自動的に作成するシーケンスの例を示すフロー図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャと関連して、データを発行し、クエリのための検索パラメータの入力を指定するシーケンスの例を示すフロー図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャと関連して、データを発行し、クエリのための検索結果を指定するシーケンス例を示すフロー図である。 任意のプラットフォームからサービスとして提供された情報に対する１つまたは複数の非限定的なインフラストラクチャの実施形態に従って生成されたクエリに基づいて、データストアを最適化するシーケンス例を示すフロー図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャによってトラッキングされたパートナー識別子メタデータを含む、メタデータの非限定の態様の例を示すブロック図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャのシーケンス例を示すフロー図である。 任意のプラットフォームからサービスとして提供された情報に対する非限定のインフラストラクチャの例を示すブロック図である。 任意のプラットフォームからサービスとして提供された情報に対するインフラストラクチャの実装の詳細の非限定なセットの例を示すブロック図である。 任意のプラットフォームからサービスとして提供された情報に対する例示のインフラストラクチャからのデータの使用例を示している。 本明細書で説明された様々な実施形態を実装することができる非限定のネットワーク化環境例を表すブロック図である。 本明細書で説明された様々な実施形態の１つまたは複数の態様を実装することができる非限定のコンピューティングシステムまたはオペレーティング環境を表すブロック図である。

＜概要＞
背景技術で説明したように、有益なデータを有するコンテンツ所有者または発行者のために、データへのアクセスを制御することに関する懸念事項は、今日のネットワーク化ストレージサービスに沢山ある。今日、ネットワーク化ストレージサービスにそのような有益なデータを渡してしまうと、誰がアクセスを得るのか、どのような種類のクエリが消費者または開発者に提示されるのか等の問題に、特定の種類のデータのために設計された専用のカスタムの解決策なしに回答することは難しい。

この点について、ダンアンドブラッドストリート（Dun and Bradstreet）の企業情報やレキシス−ネキシス（Lexis-Nexis）のオンラインケース法律およびニュースサービス等の「数百万」ドルのデータセットに関して、異なるユーザまたはユーザのクラスによってデータまたはデータの一部にアクセスするために異なる複数の最小在庫管理単位（ＳＫＵ：stock-keeping unit）へのアクセスをユーザに与えるという観点から、あまり多くの柔軟性がない。この理由のため、様々な加入モデルが考え出されているが、事実上、利用不足に対する過大請求、または大量消費者の過少請求がある。

よって、様々な実施形態において、発行者は、発行者が発行したデータについてクエリを行い、また異なるＳＫＵに対応する生成されたＡＰＩ（application programming interface）等のクエリインタフェースを自動的に備えるために、異なるＳＫＵを容易に選択する。データの構造情報がクエリインタフェースの検索パラメータおよび／または検索結果の一部であることを制御することによって、発行者はデータを検索することができること、および結果が戻されることを制御することができる。これを可能にする多くの例およびシナリオの１つとして、熱心なスポーツリーダ（消費者）は、発行者が結果セットの一部としてスポーツコンテンツだけのＳＫＵを作ることによって、新聞のスポーツコンテンツだけを見て、支払いをすることができる。あるいはまた、発行者は、元となるデータへのアクセスにわたって自由でおよび無制限な状態を可能にする（例えば、データのサブセットを検索すること、またはそのデータのサブセットに関する結果の戻りを拒否することによって、消費コンピュータにおいて１つずつ有益なデータセットの再構築を防ぐこと）のではなく、所与のデータセットについてどのコラムを検索することができるかを制御することができる。サービスとしての情報のコンテキストにおいて発行されたデータをクエリするために異なるＳＫＵの作成を可能にすることによって、価格を可変的に設定することができ、価格モデルを定期的に変えるよりも、柔軟で容易な方法で新しいＳＫＵを作り、または古いＳＫＵを削除することができる。この点について、クエリの類似が存在する複数のＳＫＵを統合することができる。加えて、発行者によって指定された検索基準に基づいて、そのような検索に対して例えば、指定の検索クエリＳＫＵによって関係された検索コラムについてのインデックスを作成するなど、バックエンドでデータを自動的に最適化することができる。

さらに、それらのおよび他の様々な例としての非限定の実施形態およびシナリオの詳細は以下に提供される。

＜ネットワーク化サービスとしての情報に対するクエリモデル＞
上記したように、サービスとしての情報のコンテキストにおいて、様々な実施形態では、クエリモデルは異なる検索ＳＫＵを作成ために検索するデータの異なるコラムを取り出すために発行者に対して提供される。例えば、名称（Name）、緯度（latitude）、経度（longitude）、クレジット（Credit）というコラムを有するテーブルのために、本明細書で説明された１つまたは複数の実施形態の使用例は、入力として企業の名称＋クレジットをとり、企業の名称と関連付けられた緯度および経度を返すクエリＡＰＩを自動的に作成することを含む（例えば、ダン（Dun）＋ブラッドストリート（Bradstreet）データ）。ＳＫＵなどの結果を用いて、信用力のある企業のヒートマップを作成することができる。これを達成するための非限定のシーケンス例が図１〜６に示されている。

例えば、図１のテーブルに示されているように、発行者が企業名称１０２、緯度１０４、経度１０６およびクレジット１０６のコラムを含む有益なデータセット１００を発行することを望むとする。しかしながら、それにも関わらず、誰かのアクセスのためにデータセットをクラウドに簡単に手放すのではなく、その制御を維持するために、どのようにそのデータが検索され得るのか、また、どの結果セットが検索に基づいて戻され得るのかについて制御を保持する。この問題は図２のブロック図によって示され、複数の発行者２００はサービス２２０として情報を提供するインフラストラクチャにデータセット２１０を発行することを望む一方、複数の開発者２３０または複数の消費者２４０に対するそれらのデータの普及および検索エントリポイントを制御することを望む。

様々な実施形態に応じて、図３に示されたように、データセット３１０を発行する複数の発行者３００はサービス３２０として情報のために発行するが、クエリ定義モデルおよびインタフェースコンポーネント３３０へのアクセスを有し、ここで、発行者はインタラクション３４０を介して発行されたデータセットにわたって異なるクエリを定義することができる。

図４に示された一実施形態において、サービスとしての情報は、発行されたデータセットの分析に基づいてクエリ定義ユーザインタフェース４００を表し、そのデータセットに関する情報の様々な構造的ビットを提示する。例えば、名称４０２、緯度４０４、経度４０６、およびクレジット４０８を有するテーブルの本例では、発行者は名称４０２とクレジット４０８等のコラム名称を選択することができ、それは結果を戻すためにクエリの検索述語の一部として用いられ得る。同様に、発行者は図５に示されたように、インタフェース４００を介して戻り結果情報４２０を指定することができる。例えば、発行者は、検索からクエリ結果４２０の一部として、クレジット４０８を除いて（全ての情報を返すことができる場合、ユーザはそのテーブルを再度作成し、発行者も「除外する」ことができる）、名称４０２、緯度４０４および経度４０６が返されるように指定することができる。

そして、クエリ生成器４３０によって、クエリについて指定された検索可能な情報４１０に基づいて、およびクエリ戻り情報４２０に基づいて、クエリＡＰＩ６００は自動的に生成される。例えば、本例では、クエリＡＰＩまたはＳＫＵを、図６にも示すように、次のように定義することができる。
Get（Name,latitude,longitude）
{
Name
Credit
}

この点について、発行者は任意の数のＳＫＵを定義し、それに応じて、例えば、アクセスされている情報の範囲および価値に一致するように、ＳＫＵの使用に対する価格を設定することができる。また、どのエンティティが検索しているのか（例えば、学生または非営利エンティティ、対営利エンティティ）に応じて、価格設定を行うこともできる。図７に示されるように、図６のＡＰＩ６００は、複数の開発者２３０によって、一方では複数の消費者２４によって使用されているように示されている。示されたように、異なる価格設定を、例えば、以下に詳細に説明されるように、会計監査能力およびトランザクショントラッキング能力に基づいてクエリＡＰＩ６００の使用のために実装することができる。

図８は例示的な非限定の実施形態を示すブロック図であり、ここで自動的に生成されたＡＰＩの消費者の観点から、消費者が第１のクエリ６００を使用する能力を有し、および第２のクエリ６０２を使用する能力を有する場合に、そのクエリ間に論理的な重複があれば、ＡＰＩ集約コンポーネントは、（非限定の例として）ハイブリッドＡＰＩ６０４を作成することができ、その後ハイブリッドＡＰＩ６０４は、開発者２３０または消費者２４０によって使用され得る。この意味において、その許可が適所にある限り、開発者２３０および消費者２４０は、コラム等の同一または類似の構造情報を有する個々のクエリから集約されたクエリの一部がより複雑なほどより豊富なデータを返すように権限を与えられる。

図９は、使用すべき検索パラメータまたは戻されるべき検索結果の仕様に基づいたＡＰＩの生成の別の態様を示している。例えば、検索可能な情報４１０が発行者によって指定され、戻り結果４２０も指定される図４および図５の例では、クエリインタフェース６００の作成をパラメータ４１０および結果４２０またはクエリインタフェース６００に基づいて導き、クエリ最適化エンジン９００は、それがデータに対して提示されている既知のＳＫＵであるので、クエリ６００の実行のために基礎となるストレージ９１０を自動的に最適化することができる。例えば、データを実際に予めソートすることによって、またはクエリをより速くまたはより効率的にする他の最適化技術の適用によってクエリ６００などのクエリの実行をスピードアップするインデックス９２０を作成することができる。この意味において、システムは検索されることを自動的に学習し、それによりデータベースを最適化し、関連付けられたＳＫＵについてより高いパフォーマンスを可能にし、経時的なストレージスケーリングとして自己回復ストレージエコシステムを可能にする。

上記したように、データについて問い合わせを行うため異なる複数のＳＫＵを容易に発行者に選択させ、かつ基礎となるデータの所与のストレージのために最適化された対応するＡＰＩを自動的に作成する能力は、発行者が、データを消費する方法を柔軟に定義することを可能にする。例えば、通常、世界ニュースを読まない熱心なスポーツ読者は、検索だけを必要とし、そのようにＳＫＵを利用可能できると仮定するならば、新聞のスポーツコンテンツだけために支払いを行う。加えて、複数のＳＫＵを集約することができ、価格をクエリの使用量または戻されたデータ量に基づいて可変的に設定することができる。加えて、発行者によって指定された検索基準に基づいて、そのような検索のために、例えば、検索コラムにわたるインデックスを作成するなど、データをバックエンドで自動的に最適化することができる。

一実施形態において、複数の発行者によって発行され、かつクエリを介して複数の消費者によって消費されたデータをホストするためのシステムまたはホストされたデータに接続するためのシステムは、発行装置によって発行された少なくとも１つのデータセットを受信するように構成された情報サービスと、情報サービスによって判別された少なくとも１つのデータセットのデータの少なくとも１つのサブセットと関連付けられた構造情報を表すように構成され、かつ構造情報からの少なくとも１つの入力の選択を受信して、情報サービスによる少なくとも１つのデータセットにわたる実施のための少なくとも１つのクエリ能力を定義するように構成されたクエリ定義コンポーネントと、を含む。

そのシステムは、少なくとも１つの入力の選択を受信することに応答して、少なくとも１つの消費装置によって少なくとも１つのデータセットにわたる問い合わせを行うために、クエリインタフェースを生成するように構成されたクエリ生成器をさらに含むことができる。そのシステムは、クエリインタフェースを、少なくとも１つの他のクエリインタフェースと組み合わせるように構成されたクエリアグリゲータをさらに含むことができる。クエリインタフェースのその少なくとも１つの他のクエリインタフェースとの比較に基づいて同一または類似のクエリ定義に従ってクエリインタフェースを少なくとも１つの他のクエリインタフェースと組み合わせるようにそのクエリアグリゲータを設定することができる。

そのシステムは、その入力の少なくとも１つの選択を受信することに応答して、少なくとも１つのデータセットにわたる問い合わせの最適化のために、少なくとも１つのデータセットを保存する少なくとも１つのデータストアを最適化するように構成されたクエリオプティマイザをさらに含む。少なくとも１つのデータセットの分析から情報サービスによって判別された少なくとも１つのデータセットのコラム情報を表すようにクエリ定義コンポーネントを構成することができる。

図１０は、データをホストするか、ホストされたデータを接続するための非限定的方法を示すフロー図である。１０００において、第１の制御領域内のコンピューティング装置（複数を含む）は第２の制御領域内のコンピューティング装置（複数を含む）から少なくとも１つのネットワークを介して、第２の制御領域内のコンピューティング装置によって発行されたデータセット（複数を含む）を受信する。１０１０において、データセットは、そのデータセットのデータの少なくとも１つのサブセットと関連付けられた構造情報（例えば、コラム情報）を判別するために分析される。１０２０において、構造情報は第１の制御領域内のコンピューティング装置によってそのデータセット（複数を含む）にわたって実施するクエリ能力についての入力を受信するために、第２の制御領域内のコンピューティング装置に対してレンダリングされる。

１０３０において、検索パラメータ入力が、構造情報の第１の構造情報を定義する第２の制御領域内のコンピューティング装置から受信される。少なくとも１つの許可された消費装置に、構造情報にわたるデータセット（複数を含む）を検索する権限が与えられる。１０４０において、検索結果入力が、構造情報の第２の構造情報を定義する第２の制御領域内のコンピューティング装置から受信される。少なくとも１つの許可された消費装置に、構造情報に関してデータセット（複数を含む）からの結果を受信するように権限が与えられる。当該方法を繰り返して、データセットにわたる様々な任意のクエリを定義することができる。

検索パラメータ入力および検索結果入力によって定義されたクエリ制約に従ってデータセット（複数を含む）を検索するために使用する少なくとも１つの許可された消費装置について、検索パラメータ入力および検索結果入力に基づいてクエリインタフェースを自動的に生成することができる。加えて、クエリインタフェースを、少なくとも１つの他のクエリインタフェースとの比較に基づいてクエリインタフェースを同一または類似の検索パラメータ入力に従って、例えば、クエリインタフェースと少なくとも１つの他のクエリインタフェースとの比較に基づいて同一または類似の検索結果入力に従って、少なくとも１つの他のクエリインタフェースと組み合わせることができる。

図１１は、データを発行する非限定の方法を例示するフロー図である。１１００において、第１の制御領域内の発行コンピューティング装置が、第２の制御領域内の受信コンピューティング装置にデータセット（複数を含む）を発行する。１１１０において、発行コンピューティング装置は、例えば、受信コンピューティング装置によるデータセット（複数を含む）の分析に基づいてデータセット（複数を含む）に関連付けられた構造情報（例えば、コラム情報）に関係した情報に対してインタフェースする。１１２０において、検索パラメータに基づいてデータセット（複数を含む）にわたる消費装置による検索のために構造情報から検索パラメータを選択することができる。１１３０において、検索パラメータを受信コンピューティング装置に送信してデータセット（複数を含む）にわたって問い合わせを行うクエリインタフェースを自動的に生成することができる。

図１２は、データを発行する非限定の方法を例示するフロー図である。１２００において、発行コンピューティング装置は、第２の制御領域内の受信コンピューティング装置に第１の制御領域内でデータセット（複数を含む）を発行する。１２１０において、発行コンピューティング装置は、例えば、受信コンピューティング装置によるデータセット（複数を含む）の分析に基づいてデータセット（複数を含む）に関連付けられた構造情報（例えば、コラム情報）に関係した情報に対してインタフェースを行う。１２２０において、検索パラメータによる検索に応答して消費装置により結果を受信するために、検索パラメータを構造情報から選択することができる。１２３０において、検索結果オプション（複数を含む）を受信コンピューティング装置に送信してデータセット（複数を含む）にわたって問い合わせを行うクエリインタフェースを自動的に生成することができる。

図１３は、データをホストするか、ホストされたデータを接続するための非限定の方法を例示するフロー図である。１３００において、第１の制御領域内のコンピューティング装置（複数を含む）は、第２の制御領域内のコンピューティング装置（複数を含む）から少なくとも１つのネットワークを介して、第２の制御領域内のコンピューティング装置（複数を含む）によって発行されたデータセット（複数を含む）を受信する。１３１０において、データセット（複数を含む）を分析して、該データセットのデータの少なくとも１つのサブセットと関連付けられた構造情報を判別する。１３２０において、構造情報（例えば、コラム情報）が第２の制御領域内のコンピューティング装置（複数を含む）に対してレンダリングされる。１３３０において、そのデータセット（複数を含む）にわたって実行する少なくとも１つのクエリ能力についての構造情報からの入力が第１の制御領域内のコンピューティング装置（複数を含む）によって受信される。１３４０において、データセット（複数を含む）と関連付けられたデータストレージメタデータが、データセット（複数を含む）にわたるクエリの実行を最適化するために入力の受信に応答して自動的に増大される。例えば、データストレージメタデータの増大は構造情報からの入力に基づいてデータセット（複数を含む）と関連付けられたインデックス情報を生成するか、増大させることを含むことができる。

次に図１４を参照すると、一実施形態に係る、発行されたデータセット（複数を含む）にわたるＡＰＩリクエストの例が図示されている。示されているように、ＡＰＩ要求１４００は、ヘッダ部１４１０および本体部１４２０を含むことができる。一態様において、ヘッダ部１４１０は開発者キーフィールド１４１２、一意の識別子フィールド１４１４、およびパートナー識別子フィールド１４１６を含むことができる。この実施形態では、一意の識別子フィールド１４１４は、複数のユーザに対する一意の識別子を含むことによってマルチシート（multi-seat）ＡＰＩ使用のトラッキングを容易にすることができることを理解されたい。さらに、パートナー識別子１４１６に関しては、特定のＡＰＩ要求と関連するパートナーがいないこと示すヌル値を指定することができることを理解されたい。

この点に関して、図１３について説明したように、様々なデータストレージメタデータを、クエリの実行を最適化するためにデータセット（複数を含む）の発行の一部として記憶し、自動的に更新することができる。加えて、発行時に、データセット（複数を含む）と関連付けられたメタデータを、パートナー識別子フィールド１４１４を含むように自動的に更新することができ、これを、所与のパートナーのデータセット（複数を含む）の会計検査等の使用へのアクセスをトラッキングする目的で所与のパートナーに適用する所与のパートナー識別子に関してクエリとマッチングさせるために用いることができる。この方法において、複数のパートナーのデータセット（複数を含む）が、開発者、消費者、加入者等からのＡＰＩ要求によって消費される場合、全てのパートナーのデータセットは適用可能なデータアクセスのためにクレジットを与え得る。

追加の実施形態においては、データを発行する方法が、第２の制御領域内の受信コンピューティング装置（複数を含む）に第１の制御領域内の発行コンピューティング装置（複数を含む）によって、データセット（複数を含む）を発行し、第２の制御領域内の受信コンピューティング装置（複数を含む）によって生成され、かつ受信コンピューティング装置（複数を含む）によるデータセット（複数を含む）の分析に基づいてデータセット（複数を含む）と関連付けられた構造情報と関係した情報を含むインタフェースに対してインターフェーシングを行うことを含むことができる。その方法は、検索バラメータ（複数を含む）で検索することに応答して消費装置によって結果を受信するために構造情報から検索結果オプション（複数を含む）を選択することをさらに含むことができる。インターフェーシングを行うことはデータセット（複数を含む）と関連付けられたコラムと関係した情報を含むインタフェースにインターフェーシングを行うことを含むことができる。

その方法は、検索結果オプション（複数を含む）に基づいて検索結果を戻すクエリインタフェースの自動生成のために、受信装置に検索結果オプション（複数を含む）を送信することを含むことができる。その方法は、検索パラメータ（複数を含む）に基づいてデータセット（複数を含む）にわたって消費装置によって検索する構造情報から検索パラメータ（複数を含む）を選択することができる。その方法は、データセット（複数を含む）にわたって問い合わせを行うクエリインタフェースの自動生成のために受信装置に検索パラメータ（複数を含む）を送信することを含むことができる。

他の実施形態においては、データを管理するまたは管理されたデータに繋ぐ方法が、第２の制御領域内のコンピューティング装置（複数を含む）から第１の制御領域内のコンピューティング装置（複数を含む）によって、第２の制御領域内のコンピューティング装置によって発行されたデータセット（複数を含む）を受信し、そのデータセット（複数を含む）のデータのサブセット（複数を含む）と関連付けられた構造情報を判別するためにデータセット（複数を含む）を分析することを含むことができる。その方法は、第２の制御領域内のコンピューティング装置（複数を含む）に構造情報を提供し、第１の制御領域内のコンピューティング装置（複数を含む）によってデータセット（複数を含む）にわたって実行するクエリ能力についての構造情報から入力を受信し、その入力の受信に応答して、そのデータセット（複数を含む）と関連付けられたデータストレージメタデータを自動的に増大させることを含むことができる。

その増大は、構造情報からの入力に基づいてデータセット（複数を含む）と関連付けられたインデックス情報を生成するまたは増大させることを含むことができる。また、その増大は、データセット（複数を含む）と関連付けられたパートナー識別子（複数を含む）を含むためにデータストレージメタデータを更新することを含むことができる。その分析はデータセット（複数を含む）と関連付けられたコラム情報を判別することを含むことができる。

＜サービスとしての情報についての追加コンテキスト＞
次の説明は、可能性のある非限定のインフラストラクチャ、アーキテクチャ、および／または関連付けられたサービスを含み、上記した実施形態の１つまたは複数を理解することにおいてさらに手助けとなる。この章に説明される追加の特徴の１つまたは複数は、様々な消費オプションのためのネットワーク化ストレージサービスに複数の発行者によって発行されたデータのセット（複数を含む）にわたって異なるクエリを柔軟に定義することについて上記した実施形態の１つまたは複数に適応させることができる。そのような実施形態または特徴の組み合わせが可能である一方、誤解を避けるために、本開示で示した実施形態は本明細書で説明した他の実施形態での限定を考慮すべきではない。

いくつかの追加の背景として、今日、インターネット等のネットワークを介して情報を得ることができる一方、今日の提供はアクセスおよびフレームワークの観点から独占する傾向にあり、サードパーティのプロバイダ加入の観点から限定される。例えば、現在、商業用コンテンツの価値の少なくとも一部を手放さない方法でそれらのデータを発行する、商業用コンテンツプロバイダのための適正なビジネスモデルがなく、歴史的に、有益なコンテンツの所有者は限定された所有手段を介してそのコンテンツを提示する傾向にある。あるいは、そのようなコンテンツの記憶が安全なクラウドストレージプロバイダによって提供される場合には、消費者が、興味があるアイテムを潜在的に見つけ出すために何千ものテーブルをかき分けなければならないときに単独での記憶に少しの価値がある。加えて、クラウドストレージプロバイダが様々なプロバイダからデータを収集することを試みる場合にさえ、よくてもそのようなプロバイダは適度の、小さいまたは不完全なデータのカタログを誇ることができる程度である。

この領域の潜在的な成長の妨げの多くは、取り扱いおよびＩＰ（例えば、著作権）についての不信の結果である。要するに、ビッグプレーヤは重要資産を有するクラウドプロバイダを信じていないが、これは、１つの情報漏洩がデータの価値を終わらせる可能性があるからである。加えて、そのような時代遅れのクラウドプロバイダは、それらの情報の必要性のためにそのようなデータから価値を取り出すことを望む情報インフォメーションワーカーについて弱い立場におり、さらに、そのようなシステムの財産的価値のため、開発者は情報上の可能性を発展させるツールを拡張するのに能力が制限されている。

よって、１つまたは複数の実施形態について説明したように、個々の、すなわち、発行者、開発者、インフォメーションワーカー、および消費者の全てのクラスを適応させるサービスとしての情報用のインフラストラクチャが提供される。そのインフラストラクチャは、情報発見、例えば、任意のプラットフォームおよび任意の形成要因（例えば、スクリーンサイズ）で任意のアプリケーションにパワーを与えるために構造化されかつブロブ（blob）のデータセットを発見し、獲得し、消費する能力を可能にする。インフラストラクチャは、仲介業、例えば、パートナー駆動エコシステム、並びに開発者およびインフォメーションワーカーにデータおよび機能を配信する世界的規模をさらに可能にする。また、インフラストラクチャは、分析および報告、例えば、私的データを公的データで補強するシングルクリック分析を可能にする。この点において、インフラストラクチャの様々な実施の分かり易い性質のため、どんなアプリケーション開発者でもモバイル、クラウド、および／またはデスクトップアプリケーションを開発してデータの発行、処理問い合わせ、および／または取り出しを容易にすることができる。

アプリケーションを書くために、人はアカウント情報（例えば、ライブＩＤで署名）を登録することができ、本明細書で１つまたは複数の実施形態のために説明されたようにサービスとしての情報用のインフラストラクチャのために可能にされた構造化されかつリアルタイムウェブサービスを介して「ブロブ」にアクセスするためにアカウントキーが人には提供され得る。１つの態様において、開発者はコーディング（符号化）を始める前にＡＰＩを視覚的に探索することができる。例えば、限定されないが、ＸＭＬ（extensible markup language）、ＡＴＯＭ、ＲＡＷ（ブロブおよびリアルタイムコンテンツ用）等の様々なパッケージに従って、またはテーブルビュー（例えば、構造化データ用）において、ＲＥＳＴ（representational state transfer）ＡＰＩクエリを視覚的に構築し、コンテンツをプレビューするために開発者によってサービスエキスブロワーモジュールまたはモジュールのセットを用いることができる。例えば、開発者は単に彼または彼女のアカウントキーを提供し、コンテンツをプレビューするのを選択する。

よって、開発者は任意のプラットフォーム上でモバイル、デスクトップまたはサービスアプリケーションを作ることができる。結果としてのＲＥＳＴクエリを新しい開発者アプリケーションに複製することができる一方、サービスとしての情報用のインフラストラクチャは、ローカルオブジェクトモデルを作る、またはＸＭＬまたはウェブサービスコードの詳細を生成および理解する必要性を排除するために自動的に生成されたＣ＃プロキシクラスを消費する能力を有効にする。この点において、他の非限定の有利な態様では、プロキシクラスをダウンロードすることができ、わずか２〜３ラインのコードを有するサービスデータを消費することを開発者のアプリケーションに含むことができる。

この点では、サービスとしての情報用のインフラストラクチャの様々な実施形態は、開発者およびインフォメーションワーカーがそれらのアプリケーションおよび分析のシナリオにおいて瞬時に、定期的に、またはアプリケーション開発者によって指定された時間のいくつかの他の機能にわたってデータを見つけ出し、獲得し、そして消費することを可能にする。上記したように、開発者は、コンテンツ要求のために本明細書では１つまたは複数の実施形態のために説明されたようにサービスとしての情報を有効にし、興味があるコンテンツに登録するネットワークサービスに対するウェブサービスコールに付随するアカウントキーを取得する。

よって、１つの態様では、本明細書では１つまたは複数の実施形態について説明されたようにサービスとしての情報用のインフラストラクチャによって提供されたアカウントキーは開発者の秘密鍵である。このキーは、開発者のアプリケーションと関連して使用されるコンテンツについて課金および報告を可能にする。このように、この秘密の開発者キーは目的もなく共有されることはなく、また、そのキーを安全にすることにおいての予防措置をとることができ、そこではモバイルまたはデスクトップソリューション上で動作しているネイティブアプリケーションを開発し、また展開の一部としてキーを統合することを計画する。例えば、暗号ストレージを、キーが割れていないことを確認するために使用することができる。

コンテンツを消費するアプリケーションをトラッキングするために使用されるアカウントキーに加えて、一意のユーザＩＤは、開発者の個々のユーザを表すＧＵＩＤ（グローバル一意の識別子）である。このフィールドは、プログラムでユーザ単位に販売されているコンテンツに対する課金を可能にする。例えば、開発者がアプリケーションを消費して個々のユーザを持つモバイルアプリケーションを開発しているならば、開発者は各時刻要求がその個々のユーザに代わって行われているのと同じＧＵＩＤを戻すことができる。しかしながら、開発者がウェブポータルを開発し、様々なユーザに代わってウェブサービス要求を発しているならば、ポータルを訪れる一意のユーザ毎に新しいＧＵＩＤを割り当てることは開発者に任されている。例えば、各登録ユーザにはＧＵＩＤ、または一意のＩＤ ＧＵＩＤ等を割り当てた各ＩＰアドレス／ポートの組み合わせを割り当ていることができる。

ＲＥＳＴ ＡＰＩは本明細書で１つまたは複数の実施形態について説明されたように、サービスとしての情報用のインフラストラクチャからコンテンツを消費する任意のプラットフォーム上で構築することができる一方、一実施形態では、プロキシクラスを動的にＣ＃でのサービスのために動的に生成することができる。これを達成することは、オブジェクトモデルをダウンロードし、それらを現在の開発者プロジェクトに追加し、アカウントおよび一意のユーザ値を更新するということである。

開発者が手動でリクエストを発したいならば、一例が以下に提供されるが、任意のサービスに対して、プレビュー機能を使用することができ、またはサービスエクスプローラ（Service Explorer）から作成された複数のＵＲＬもその上呼び出すことができる。サンプルデータセットに対する非限定的なＲＥＳＴクエリ例が以下に示される。なお、一部または全てのコールを保護されたＳＳＬ（secure socket layer）にすることができる。
https://api.sqlazureservices.com/UnService.svc/UNESCO(120)

$accountKeyおよびSuniqueUserldエレメントはリクエストのヘッダに配置され、それは次のように表され、例えば、
SaccountKey={developer acccount key}
$uniqueUserID={a GUID representing the unique user}

SaccountKeyの値はアカウントタブ（Accounts Tab）で見つけ出される開発者のアカウントキーを表し、$uniqueUserIDはサービスにアクセスする一意のユーザのＧＵＩＤを表す。

よって、本明細書で１つまたは複数の実施形態で説明したように、サービスとしての情報用のインフラストラクチャは、開発者およびインフォメーションワーカーが任意のプラットフォームにおけるプレミアムデータサブスクリプションを簡単に検索、購入、および管理することを可能にする新しいサービスおよびフレームワークである。インフラストラクチャは、共通のプロビジョニングおよび課金のフレームワークの元で統一している単一または複数の場所に一緒に、非正式発行者と共に、リードする商用データプロバイダおよび権威ある公的データソースデータから画像、およびリアルタイムのウェブサービスをもたらす情報市場である。さらに、開発者およびインフォメーションワーカーは、任意のプラットフォーム、アプリケーションまたはビジネスワークフローを視覚的に用いてこのプレミアムコンテンツを消費することができる。

本明細書で１つまたは複数の実施形態で説明したように、サービスとしての情報用のインフラストラクチャを使用するいくつかの非限定的なシナリオ例は、（a）消費者および企業のシナリオのための次世代の「キラーアプリ」にプレミアムコンテンツを見つけること、（b）既存のアプリケーションおよびレポートを改善するために有益なデータを発見してライセンス供与すること、（c）は本質的に異なるデータを持って来ることは、ビジネスのパフォーマンスと処理、例えば、集約アルゴリズムに新たな洞察（インサイト）を得るために革新的な方法で一緒に全く異なるデータセットをもたらすこと、（d）ブロブ、構造化された、およびリアルタイムのウェブサービスのための全てのコンテンツブロブのプロバイダにわたってＡＰＩを瞬時にかつ視覚的に探索すること、および（e）既存のアプリケーション、および既存のワープロ、表計算、データベースクエリシステム等のデータベースシステム内で豊富なレポートおよび分析のためにサードパーティのデータを消費することを含む。

開発者のための利点は、（a）試用サブスクリプションがデータのロイヤリティを支払うことなくコンテンツの調査およびアプリケーションの開発を可能にすること、（b）簡単なトランザクションおよびサブスクリプションモデルが数百万ドル規模のデータセットへの「あなたが行くかまたは成長に合わせて支払う（pay as you go or grow）」アクセスを可能にすること、（c）任意のプラットフォーム上での開発を容易にするデータセットにわたるＡＰＩに基づいた一貫したＲＥＳＴ、（d）ＡＰＩを視覚的に構築し、模索し、結果をプレビューすること、および（e）自動Ｃ＃プロキシクラスが、インスタントオブジェクトモデルを提供し、面倒なＸＭＬおよびウェブサービスのコードを記述する必要性を除去すること、を含む。

インフォメーションワーカーのための利点は、（a）限定されないがＥｘｃｅｌ既存の表計算ソフトでデータを簡単に操作するためにＰｏｗｅｒＰｉｖｏｔとの統合、（b）コンテンツを取得する単純で予測可能なライセンスモデル、 および（c）ＳＱＬ Ｓｅｒｖｅｒ、ＳＱＬ Ａｚｕｒｅデータベース、および他の既存資産からデータを消費する能力、を含む。

コンテンツパートナーのための利点は、（a）ブロブデータ、構造化されたデータ、または動的なウェブサービスに関係なく簡単な発行およびオンボーディング処理、（b）例えば、Ｖｉｓｕａｌ Ｓｔｕｄｉｏおよび.ＮＥＴまたはその他のランタイムシステム開発を通じて開発を容易にするために選択されたプラットフォーム上での開発者ツーリング、（c）グローバル開発者およびインフォメーションワーカーコミュニティに開発者向けコンテンツを公開すること、（d）既存のコンテンツ消費アプリケーション内部のコンテンツの発見および統合、および（e）スケーラブルクラウドコンピューティングプラットフォームが全ての当事者に代わって、記憶、配信、課金、および報告を処理すること、を含む。

本明細書で１つまたは複数の実施形態で説明したように、サービスとしての情報用のインフラストラクチャの非限定的な実装では、Ｒｉｃｈ Ｗｅｂ Ｓｅｒｖｉｃｅのためのいくつかの特徴は、（a）全コンテンツカタログにわたるサービスを消費する安全でＲＥＳＴベースのモデル、（b）アクセスを簡素化するためにＡＰＩに組み込まれたダイナミックページネーション、（c）Ｓｔａｎｄａｒｄ ＡＴＯＭ １.０フィードはサービスの大部分のために利用可能であること、および（d）一貫性のある課金、プロビジョニング、および全てのサービスにわたる使用報告、を含む。

本明細書で１つまたは複数の実施形態で説明したように、サービスとしての情報用のインフラストラクチャの非限定的な実装では、Ｓｅｒｖｉｃｅ Ｅｘｐｌｏｒｅｒコンポーネントのためのいくつかの特徴は、（a）開発を簡素化するために生成されたＣ＃のプロキシクラス、（b）サポートされるならば表形式でおよびＡＴＯＭ １.０フィード等のフィードのようにデータのプレビュー、（c）コンパイルされたサービスコールが戻す結果を理解するためにサービスの呼び出し、（d）パラメータ毎のドキュメントおよびサンプル値の発見、および（e）開発を容易にするためのクリップボードへのサービスコールの視覚的に構築されたＵＲＬのインスタントコピー動作、を含む。

本明細書で１つまたは複数の実施形態で説明したように、サービスとしての情報用のインフラストラクチャの非限定的な実装では、Ｍａｒｋｅｔｐｌａｃｅ ＩｎｔｅｇｒａｔｉｏｎおよびＤｉｓｃｏｖｅｒｙ Ｐｏｒｔａｌコンポーネントのためのいくつかの特徴は、（a）消費者および企業を含むドメインにわたる新しいデータの発見、（b）サービスのサブスクリプションと使用制限の管理、（c）サービスにアクセスするためのアカウントキーの管理、および（d）アクセスされ、かつ日付とアカウントキーによってグループ化されたサービス/データセットを含む詳細なアクセス報告、を含む。

そのインフラストラクチャは、コンテンツ所有者、アプリケーション開発者/ＩＳＶのため、並びにインフォメーションワーカーおよび他の消費者/加入者のために様々な価値ある提案を提供する。コンテンツ所有者に対しては、インフラストラクチャはデータに課金しないデータプロバイダのための社会的な利点に加えて、データ（データに課金するデータプロバイダのための）から収益化を可能とするが、他の方法でそのようなデータの発行から利益を得る。インフラストラクチャの開放のために、コンテンツの所有者は、ＩＳＶや消費者/インフォメーションワーカーに対するデータのより大きな可用性および広がりを享受し、これの全ては、特に過去のように、独自のモデルを開発する上で低コストで生じる。

アプリケーション開発者/ＩＳＶのために、そのインフラストラクチャは、一貫した形式、データアクセスのための可変および低コストの価格設定モデル、予測可能な価格設定、データを用いて構築されたアプリケーションを使用して消費者/ＩＷからの潜在的利益、任意のプラットフォームを介して消費者へのより広い範囲および単一の課金とデータソースでデータへのアクセスを可能にする。

インフォメーションワーカー/消費者のために、そのインフラストラクチャは、単一の課金やデータに加えて、アプリケーションからの追加の値、現在のラージオブジェクト（ＬＯＢ）またはＩＷソフトウェアにおけるデータの消費、データアクセスのための可変および低コスト価格設定を可能にする。

よって、インフラストラクチャは、潜在的に大きな収益上昇傾向を有して現在の顧客と開発者の悩みの種を解決し、モデリング、報告、分析、および傾向のためのインスタントデータが付加された一意のビジネスインテリジェンスの機会を作り、インフラストラクチャを介してそれらのデータの保存をデータ所有者を促すことによって任意のプラットフォームについての適用と粘りを作り出し、それによって従来のクラウドストレージ環境と比較したときインフラストラクチャの価値課題を差別化する。

図１５のフローに示されるように、１５００では、インフラストラクチャを介してデータを発行するためのコンテンツの所有者または発行者のために様々な方法が本明細書に説明されている。１５１０では、インフラストラクチャを介してデータを消費するために開発者がアプリケーションを開発することを可能にする様々なツールがある。１５２０では、消費者またはインフォメーションワーカーはデータを消費するためにアプリケーションを使用するかまたはそのデータにわたって直接問い合わせを行うことができる。最後に、インフラストラクチャは、１５３０でトランザクションモデルでは有効になって、コンテンツチェーン内の全ての当事者に代わって自動管理、監査、課金等を可能にする様々なツールを提供する。

この点においては、インフラストラクチャ内のいくつかの主要当事者は、データ所有者、アプリケーション開発者/ＩＳＶおよび消費者/インフォメーションワーカーを含む。一般的に、データ所有者はデータに課金したいエンティティ（実在者）、あるいは他の理由のために無料でデータを提供するかまたはデータを介して他の条件を実行したいエンティティである。同様に、アプリケーション開発者/ＩＳＶは、それらのアプリケーションを収益化したいエンティティ（例えば、広告を通じて、直接支払い、間接的な支払い等）、またはそのようなエンティティにいくつかの有益な理由で無料でそれらのアプリケーションを提供するエンティティである。インフォメーションワーカーおよび消費者は生データを使用することができる人々、またはアプリケーション開発者によって提供されたアプリケーションを使用する人々である。

図１６は本明細書で説明されたようにサービスとしての情報を提供するエコシステムに参加することができる様々な当事者を概略的に示すブロック図である。例えば、ネットワークアクセス可能な情報サービス１６００のセットは、データの感度および他の特性に応じて、様々な信頼できるまたは信頼のないデータストア１６１０へのアクセスを提供する。よって、示されたように、エコシステムは、あらゆる種類のデータ、ブロブ、構造化、非構造化等をサポートしているので、データストア１６１２，１６１４，．．．，１６１６がどんな種類であるかはそれほど重要ではない。上記したように、システムは、エコシステムにデータを加える発行者１６２０、データを消費する加入者１６３０、並びにそれらのアプリケーションとのデータの消費を助けるアプリケーションの開発者およびプロバイダ１６５０を含む。また、アクセス情報生成部１６７０は、アカウント情報、キー情報等を維持しまたは実行することを介して様々な当事者によってデータへのアクセスを管理することができる。この点において、コンテンツ所有者１６６０は、コンテンツ所有者１６６０が発行者１６２０、加入者１６３０および／またはその上アプリケーション開発者であることができるという点において役割のいずれかに広がることができる。１つの態様では、全ての当事者のための共通のインフラストラクチャは、管理１６６５、監査１６７５、課金１６７５、およびインフラストラクチャにわたって生じるデータトランザクションに対する他の目的の補助的なサービスを可能にする。

この点において、任意のプラットフォームからのサービスとしての情報を可能にするユーザーフレンドリなデータプラットフォームのための様々な実施形態は、データの消費者（ＩＷ、開発者、ＩＳＶ）およびデータの消費者が簡単で、費用効率が高くかつ便利な方法で取り引きすることを可能にする。インフラストラクチャは、ＩＷＳが急速に洞察（インサイト）を描くことを可能にし、開発者が創造的方法で多くのデータソースを用いて革新的なアプリケーションを構築することを可能にし、また、開発者が任意のプラットフォーム上でそれらの努力を収益化することを可能するために現実的な方法でプレミアム（私的）およびコミュニティ（公的）データを民主的にする。例えば、そのインフラストラクチャは、Ｐａｙ Ｐｅｒ Ｕｓｅ（使用当たりの支払い）およびＳｕｂｓｃｒｉｐｔｉｏｎ Ｐｒｉｃｉｎｇ ｆｏｒ Ｃｏｎｔｅｎｔ（コンテンツに対するサブスクリプション価格）、さらに、Ｐａｙ ｆｏｒ Ｃｏｎｔｅｎｔ（コンテンツに対する支払い）（「小売価格」−コンテンツ所有者によって設定された）、Ｐａｙ Ｄａｔａ Ｆｅｅ（支払いデータ料）（「配送および処理」）並びにＢＷをサポートし、さらに論理トランザクションベース単位（報告当たり、ＡＰＩ当たり、ダウンロード当たり等）で仲介手数料としてのデータ費用をサポートする。

インフォメーションワーカー（例えば、オフィス、ＳＱＬ Ｓｅｒｖｅｒ、Ｄｙｎａｍｉｃｓのユーザ）のために、インフラストラクチャは、将来のＥＡの統合だけでなく、予測可能なスペンド特性（オンおよびオフプレミスＢＩ並びに「ＨＰＣ」ワードロードをサポートするためにキャッシングすること）を可能にするためにサブスクリプションをサポートする。よって、代替はユーザ毎の月額価格のコンテンツを含み、それは、コンテンツパックまたはトランザクションごとの価格設定を配信するためにバンドリングするまたはしないかもしれず、例えば、大量のデータを移動する必要性を排除するために、クラウド報告/ビジネスインテリジェンスオンデマンドの価格設定を可能にする一方、データ報告ギャラリを介して、従量料金、またはバーティカルアプリを可能にする。

コンテンツプロバイダ（任意のデータタイプ；任意のクラウド）のために、任意のプラットフォームを使用して、インフラストラクチャは任意の特定の所望のプラットフォーム内でインセントセールに対して価値問題となる。自動スケーリング、追加費用なしでより高いレベルのＳＬＡの可能性。いくつかの非限定的な例では、データは次のドメイン：ロケーションアウェアサービス＆データ、商業用および住宅用不動産、財務データおよびサービス等内の安全および関連したデータであることができる。非制限的なシナリオは、非政府組織（ＮＧＯ）のデータセットのトップ３０までのデータの配信を含んでも良い。加えて、インフラストラクチャは、ＨＰＣの「サービスとしての情報についてビング」を通して、ＢＩ＆ビジュアライゼーションを披露する能力を含んでいても良い。バーティカルアプリケーションの機会も同様に存在する。

１つの非限定的な実施形態において、データの仲介を、従来のブリックおよびモルタル戦略になぞらえることができる。例えば、容量を棚スペース（例えば、構造化、および非構造化/ブログデータの混合）として表すことができ、商品原価（ＣＯＧＳ）を面積（ＳＡ、プラットフォーム依存性、バンド幅）として表すことができ、コンテンツを商品（例えば、ＣＯＧＳをカバーするためにコンテンツプロバイダを最適化し、ＩＷおよび開発者からの利益を最大化する）として表すことができる。様々な実施形態において、サービスレベルアグリーメント（ＳＬＡ：サービス品質保証制度）の適応と共に、データやサービスのために品質バーでオンボーディング処理を実装することができる。

図１７は、１以上の特徴に応じて上記のようにサービスとしての情報用のインフラストラクチャ１７１０の非限定的な実装例である。インタラクション側では、インフラストラクチャとＳＳＬ／ＲＥＳＴベースのＡＰＩ１７０６を介して通信することができるインフォメーションワーカー１７００、開発者１７０２、および消費者１７０４はインタラクション側である。最適な方法でトラフィックの誘導を助けるためにロードバランサ１７０８を用いることができる。この点において、入力は、ポータルウェブロール１７２０またはＡＰＩウェブロール１７２２にルーティングされる。インフラストラクチャ１７１０からデータ側までは、クラウドストレージフレームワーク１７４０のブロブデータセット１７４２またはブロブデータセット１７５５、またはリレーショナルデータベースフレームワーク１７５０のデータセット１７５２またはデータセット１７６２にアクセスするための追加のロードバランシング１７２４または１７２６（例えば、ＷＡまたはＳＡ）である。サードパーティのクラウド１７６０のデータ１７６２またはデータ１７６４にアクセするためにプロキシレイヤ１７２８を用いることができる。必要に応じ、コンテンツにアクセスするためにコンテンツデータアブストラクトレイヤ（ＤＡＬ）１７３０を用いることができる。この点において、異なる種類のストレージにわたってデータセットの複製または重複して存在することができ、例えば、同一のデータをブロブデータとして、また、構造化されたデータ、例えば、ＳＱＬとして表される可能性がある。

データに対する補足サービスとして、課金およびディスカバリサービス１７７０がオンライン課金１７７２（例えば、ＭＯＣＰ）またはディスカバリサービス１７７４（例えば、ピンポイント）を含むことができ、認証サービス１７８０は、認証情報管理１７８２（例えば、ライブＩＤ）またはコンテンツ認証１７８４、例えば、認証コンテンツサービス（ＡＣＳ）を含むことができる。アカウントサービス１７９０は、ロギング/監査サービス１７８６またはアカウント管理１７８８を含むことができる。管理および運用サービス１７９２は、運用ダッシュボードサービス１７９４およびネットワーク運用サービス１７９６、例えば、ゴメス（Ｇｏｍｅｚ）を含むことができる。

図１８は、サービスとしての情報を有効にする一般的なインフラストラクチャの１つまたは複数の実施形態に応じて、データからデータの消費者への流れを終了するエンドを例示するブロック図である。例えば、サービス１８００としての情報は、商用データ１８０２および無料データ１８０４を含むことができ、それは営利の開発者１８１０、非営利の動機の非営利の開発者１８１２、および生産的目標に対して一般的にデータを消費することに興味を持っている他のインフォメーションワーカーのために様々に興味を持つことができる。これらのエンティティは、どのアプリケーション１８２２，１８２４，．．．，１８２６がそれらに興味があるかを判別し、最終的にデータを似ているＩＬＡ消費者１８３０およびＤＬＡ消費者１８３２に送信するためにディスカバリサービス１８２０を使用することができる。

＜オープンデータプロトコル＞
この分野の当業者は、ネットワークインタラクションおよび情報サービスを様々なコンピュータシステム設定およびプロトコルで実施することができることを理解し得る。この点において、本明細書で説明さけた１つまたは複数の実施形態で使用することができるデータの問い合わせおよび更新のための非限定的な１つの実装には、オープンデータプロトコル（Open Data Protocol：ＯＤａｔａ）てある。

ＯＤａｔａは、データを問い合わせおよび更新するためのウェブプロトコルである。ＯＤａｔａは、様々なアプリケーション、サービスおよびストアから情報へのアクセスを提供するためにＨＴＴＰ（ハイパーテキスト転送プロトコル）、アトム出版プロトコル（ＡｔｏｍＰｕｂ）およびＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）等のウェブ技術を適用する。いくつかの一般的な背景については、ＯＤａｔａは過去数年間にわたる様々な製品に、ＡｔｏｍＰｕｂクライアントおよびサーバの実装の経験に基づいて組織的に出現した。限定されないが、リレーショナルデータベース、ファイルシステム、コンテンツ管理システム、および伝統的なウェブサイトを含む様々なソースからの情報を公開しかつアクセスするためにＯＤａｔａを用いることができる。エコシステムの成長を促すために、誰でもＯＤａｔａの実装と自由に相互運用できるようにＯＳＰ（Open Specification Promise）の元でリリースされた。ネットワークデータの問い合わせおよび更新を行う類似の機能を有するハイブリッドプロトコルを形成するために同様に他のプロトコルにＯＤａｔａの特徴を組み込むことができる。

ＯＤａｔａはウェブワークの方法と一致している。１つの態様では、ＯＤａｔａは、リソースを識別するための方法としてＵＲＩ（ユニバーサルリソース識別子）を使用し、例えば、インターネットワークの方法と類似し、それらのリソースとインタラクションを行う一定のインタフェースを有するＨＴＴＰ中心プロトコルを使用する。１つの非限定の態様では、ＯＤａｔａは、独自に開発された複数のシステムにわたってデータ、コンテンツおよび情報を共有するプロセスを簡略化しているＡｔｏｍＰｕｂによって普及されたＨＴＴＰ上での規則に基づいている。ＯＤａｔａは、実装が交換されるべき基本的なクエリおよびスキーマ情報をサポートするために任意に実行できるという追加の規則を定義している。ＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）クライアントとの統合を簡素化するため、ＯＤａｔａは、ＸＭＬベースのＡｔｏｍＰｕｂ形式を補完するプロトコルの任意のＪＳＯＮ表現を定義している。理解できるように、ＯＤａｔａプロトコルに関する追加実装仕様または他の詳細はwww.odata.orgで見つけ出すことができる。

＜例示的なネットワークおよび分散環境＞
この分野の当業者は、本明細書で説明された任意のプラットフォームおよび関連した実施形態から、サービスとしての情報用のインフラストラクチャのための方法および装置の様々な実施形態を、任意のコンピュータまたは他のクライアントまたはサーバ装置と関連して実現することができることを理解され得る。それは、コンピュータネットワークの一部として、または分散コンピューティング環境で展開することができ、データストアのいずれかの種類に接続され得る。この点において、いくつかのメモリまたはストレージユニット、およびいくつかのストレージユニットを有する任意のコンピュータシステムまたは環境、およびいくつかのストレージユニットにわたって起きるいくつかのアプリケーションおよびプロセスで、本明細書で説明された様々な実施形態を実行することができる。これは、限定されないが、リモートまたはローカルストレージを有する、ネットワーク環境または分散コンピューティング環境に展開されたサーバコンピュータおよびクライアントコンピュータを有する環境を含む。

図１９はネットワーク化または分散コンピューティング環境例の非限定的な概略図を提供している。分散コンピューティング環境は、コンピューティングオブジェクトまたは装置１９１０，１９１２等、およびコンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等を備え、それらは、アプリケーション１９３０，１９３２，１９３４，１９３６，１９３８によって表されたように、プログラム、メソッド、データストア、プログラマブルロジック等を含むことができる。当然のことであるが、コンピューティングオブジェクトまたは装置１９１０，１９１２等、およびコンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等はＰＤＡ、オーディオ/ビデオ装置、モバイルフォン、ＭＰ３プレーヤ、ラップトップ等の異なる装置を備えても良い。

各オブジェクト１９１０，１９１２等およびコンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等は、１以上の他のコンピューティングオブジェクトまたは装置１９１０，１９１２等およびコンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等と通信ネットワーク１９４０によって直接または間接的に通信することができる。図１９には単一の要素として示されたけれども、ネットワーク１９４０は、図１９のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティング装置を備えても良く、および／または多数の相互接続された図示しないネットワークを表しても良い。また、各コンピューティングオブジェクトまたは装置１９１０，１９１２等、または１９２０，１９２２，１９２４，１９２６，１９２８等は、様々な実施形態に従って提供される任意のプラットフォームからのサービスとしての情報用のインフラストラクチャとの通信またはそれの実装に適した、ＡＰＩ、または他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを利用することがあるアプリケーション１９３０，１９３２，１９３４，１９３６，１９３８等のアプリケーションを含むことができる。

分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワーク設定がある。例えば、コンピューティングシステムを、ローカルネットワークまたは広域分散ネットワークにより、有線または無線のシステムによって一緒に接続することができる。様々な実施形態で説明したように技術に伴った典型的な通信のために多くのネットワークインフラストラクチャを用いることができるけれども、現在、多くのネットワークは、広く分散コンピューティングのためのインフラストラクチャを提供し、多くの異なるネットワークを包含するインターネットに接続されている。

よって、クライアント/サーバ、ピアツーピア、またはハイブリッドアーキテクチャ等のネットワークトポロジーおよびネットワークインフラストラクチャのホストを利用することができる。クライアント/サーバアーキテクチャ、特にネットワーク化システムでは、クライアントは通常、他のコンピュータ、例えば、サーバによって提供される共有ネットワークリソースにアクセスするコンピュータである。任意のコンピュータを状況に応じてクライアント、サーバ、またはその両方と考えることができるけれども、図１９の描画では、非限定的な例として、コンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等をクライアントとして考えることができ、コンピューティングオブジェクトまたは装置１９１０，１９１２等をサーバとして考えることができ、ここで、コンピューティングオブジェクトまたは装置１９１０，１９１２等は、コンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等からデータを受信し、データを保存し、データを処理し、コンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等へデータを送信する等のデータサービスを提供する。これらのコンピューティング装置のいずれかがデータを処理し、１つまたは複数の実施形態のために本明細書に説明されたように任意のプラットフォームおよび関連した技術からサービスとしての情報用のインフラストラクチャを関係させることができるサービスまたはタスクを要求することができる。

サーバは、通常、インターネットまたはワイヤレスネットワークインフラストラクチャ等のリモートまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアント処理は、第１のコンピュータシステム内でアクティブであることができ、サーバ処理は、通信媒体を介して互いに通信する第２のコンピュータシステム内でアクティブであることができ、それにより分散機能を提供し、複数のクライアントがサーバの情報収集能力を活用することができる。ユーザプロファイルに従って利用される任意のソフトウェアオブジェクトはスタンドアロンで提供されるか、または複数のコンピューティング装置またはオブジェクトに分散させることができる。

通信ネットワーク/バス１９４０がインターネットであるネットワーク環境では、例えば、コンピューティングオブジェクトまたは装置１９１０，１９１２等は、コンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等がＨＴＴＰ等の既知のプロトコルのいくつかを介して通信するウェブサーバであることができる。上記したように、コンピューティングオブジェクトまたは装置１９１０，１９１２等はまた、分散コンピューティング環境の特性であるように、コンピューティングオブジェクトまたは装置１９２０，１９２２，１９２４，１９２６，１９２８等またはその逆として機能しても良い。

＜例示的なコンピューティング装置＞
前述したように、本明細書で説明された様々な実施形態は任意の装置に適用し、そこにおいては任意のプラットフォームからサービスとしての情報用の１つのインフラストラクチャまたはその一部（複数を含む）を実装することが望ましいこともある。よって、ハンドヘルド、ポータブル、並びに全ての種類の他のコンピューティング装置およびコンピューティングオブジェクトが、本明細書で説明された様々な実施形態と関連して使用のために、すなわち、装置は任意のプラットフォームからサービスとしての情報用のインフラストラクチャと関連していくつかの機能を提供することができるところならばどこでも考慮されることが理解され得る。よって、図１９に説明された以下の汎用リモートコンピュータは、一例であるが、ネットワーク/バス相互運用性およびインタラクションを有する任意のクライアントを使用して本開示の実施形態を実装することができる。

必須ではないけれども、装置またはオブジェクトのためのサービスの開発者による使用のために、および／または動作可能なコンポーネント（複数を含む）と関連して動作するアプリケーションソフトウェア内に含まれた、オペレーティングシステムを介して実施形態のいずれかを部分的に実行することができる。ソフトウェアは、クライアントワークステーション、サーバ、またはその他の装置等の１以上のコンピュータによって実行されているプログラムモジュール等のコンピュータ実行可能な命令の一般的なコンテキストで説明されても良い。この分野の当業者は、ネットワークインタラクションが様々なコンピュータシステム設定およびプロトコルで実施されても良いことを理解し得る。

図２０は適切なコンピューティングシステム環境２０００の例を示しており、そこにおいて１つまたは複数の実施形態を実装することができる。上記したように明らかにされているが、コンピューティングシステム環境２０００は、適切なコンピューティング環境の一例に過ぎず、実施形態のいずれかの使用または機能の範囲について何らかの限定を示唆するつもりはない。また、コンピューティング環境２０００は、動作環境２０００例に示されたコンポーネントのいずれか１つまたは組み合わせに関連して何らかの依存または要件を有するものとして解釈されるべきではない。

図２０を参照すると、本明細書の１つまたは複数の実施形態を実行するためのリモート装置例は、ハンドヘルドコンピュータ２０１０の形で汎用コンピューティング装置を含むことができる。ハンドヘルドコンピュータ２０１０のコンポーネントは、限定されないが、処理ユニット２０２０、システムメモリ２０３０、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット２０２０に接続するシステムバス２０２１を含むことができる。

コンピュータ２０１０は、通常、様々なコンピュータ可読媒体を含み、コンピュータ２０１０によってアクセス可能な任意の利用可能な媒体であることができる。システムメモリ２０３０は、ＲＯＭ（リードオンリメモリ）および/またはＲＡＭ（ランダムアクセスメモリ）等の揮発性および/または不揮発性メモリの形でコンピュータ記憶媒体を含むことができる。例えば、限定はしないが、メモリ２０３０はオペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含んでも良い。

ユーザが入力装置２０４０を介してコンピュータ２０１０にコマンドおよび情報を入力することができる。また、モニタおよびディスプレイ装置の他のタイプは、出力インタフェース２０５０等のインタフェースを介してシステムバス２０２１に接続されている。モニタに加えて、コンピュータは、出力インタフェース２０５０を介して接続することができるスピーカおよびプリンタ等の他の周辺出力装置を含むことができる。

コンピュータ２０１０は、リモートコンピュータ２０７０等の１以上の他のリモートコンピュータとの論理接続を用いてネットワーク化または分散環境で動作することができる。リモートコンピュータ２０７０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置または他の共通ネットワークノード、あるいは他の任意のリモートメディア消費または伝送装置であっても良いし、コンピュータ２０１０に関連して上記した様相のいずれかまたは全てを含んでも良い。図２０に示した論理接続は、ＬＡＮ（ローカルエリアネットワーク）またはＷＡＮ（広域ネットワーク）等のネットワーク２０７１を含むが、他のネットワーク/バスを含んでも良い。このようなネットワーキング環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。

上記したように、例示的な実施形態は、様々なコンピューティング装置、ネットワーク、および広告アーキテクチャと関連して説明されているが、任意のネットワークシステムおよび任意のコンピューティング装置またはシステムに根本的なコンセプトを適用することができ、そこでは、クラウドまたはネットワークサービスとのインタラクションと関連してデータを発行し、データについてアプリケーションを構築し、データを消費することが望まれる。

本明細書で説明された１つまたは複数の実施形態を実行する多くの方法があり、アプリケーションおよびサービスが任意のプラットフォームからのサービスとしての情報用のインフラストラクチャを使用することを可能にする、例えば、適切なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、制御、スタンドアロンまたはダウンロード可能なソフトウェアオブジェクト等である。実施形態は、ＡＰＩ（または他のソフトウェアオブジェクト）の観点から、同様に、説明した実施形態の１以上に従って任意のプラットフォームからサービスとしての情報用インフラストラクチャの提供を容易にするソフトウェアまたはハードウェアオブジェクトから検討されても良い。本明細書で説明された様々な実装および実施形態は、ハードウェアで全体的、ハードウェアで部分的、ソフトウェアで、およびソフトウェアで部分的である態様を持っても良い。

用語「例示」は、例えば、例、事例、または実例として意味するために使用される。誤解を避けるために、本明細書で開示された主題は、そのような例によって限定されない。加えて、「例示」として本明細書で説明された任意の態様または設計は、他の態様または設計より好ましいまたは有利であると必ずしも解釈されるべきではなく、この分野の当業者に知られている同等の例示的な構造および技術を排除することを意味しない。さらに、用語「含む」、「有する」、「含有する」および他の類似の言葉は詳細な説明または請求の範囲で使用される限りでは、誤解を避けるために、そのような用語は、いくつかの追加のまたは他の要素を排除することなくオープントランジッションワードとして用語「備える」に類似した方法で包括的であることを意図している。

上記したように、ハードウェアまたはソフトウェア、あるいは、必要に応じてその両方の組み合わせに関連して本明細書で説明した様々な技術を実装することができる。本明細書において使用されるように、用語「コンポーネント」、「システム」等は同様に、コンピュータに関連したエンティティ、ハードウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、または実行中のソフトウェアを指すものとする。例えば、コンポーネントは限定されないが、プロセッサ上で動作する処理、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、および／またはコンピュータであっても良い。例としては、コンピュータ上で動作するアプリケーションおよびそのコンピュータをコンポーネントとしても良い。１以上のコンポーネントは、処理内および／または実行中スレッド内に常駐しても良く、コンポーネントは、１つのコンピュータ上にローカライズおよび／または２以上のコンピュータ間で分配されても良い。

上記したシステムは、いくつかのコンポーネント間でのインタラクションについて説明されている。当然のことであるが、そのようにシステムおよびコンポーネントは、それらのコンポーネントまたは指定のサブコンポーネント、その指定のコンポーネント他はサブコンポーネント、および／または追加のコンポーネントを含み、また様々な置換と前述の組み合わせに応じてすることができる。また、親コンポーネント（階層）内に含まれるよりむしろ他のコンポーネントに通信可能で接続されたコンポーネントとしてサブコンポーネントを実装することができる。加えて、１以上のコンポーネントは集合機能を提供する単一のコンポーネントに組み合わされてもまたはいくつかの独立したサブコンポーネントに分割されても良い。管理レイヤ等の何らかの１以上中間レイヤが統合機能を提供するためにそのようなサブコンポーネントに通信可能に接続されても良い。本明細書で説明された、いくつかのコンポーネントは、特に本明細書では説明されていないが、この分野の当業者によって一般的に知られた１以上の他のコンポーネントとインタラクションを行っても良い。

上記した例示的なシステムの観点からは、開示された構成に従って実装され得る方法は様々な図のフローチャートを参照して理解され得る。説明を簡単にするために、方法が示され、かつ一連のブロックとして説明されているが、いくつかのブロックが本明細書で図示または説明されたことから異なる順序とおよび／または他のブロックと同時に生じる可能性があるので、請求項に記載の構成はブロックの順については限定されないことは理解されるべきである。非シーケンシャルなまたは分岐したフローがフローチャートを介して示されている場合に、同じまたは類似の結果を達成する様々な他の枝路、フロー、ブロックの順番を実施しても良い。さらに、図示していない全てのブロックは以下に説明された手法を実装するために必要とされても良い。

いくつかの実施形態では、クライアント側の視点が示されているが、それは疑いを避けるために、対応するサーバの視点またはその逆が存在していると理解されるべきである。同様に、方法が実行されている場合には、対応する装置はストレージと、１以上のコンポーネントを介する方法を実行するように構成された少なくとも１つのプロセッサとを有して提供されても良い。

様々な実施形態が様々な図により好ましい実施形態に関連して説明されたが、他の同様の実施形態が用いられても良く、または変更や追加がそこから逸脱することなく、同じ機能を実行するために、説明された実施形態に行われても良いことが理解されるべきである。さらに、上記した実施形態の１以上の態様は複数の処理チップまたは装置内で、または全体にわたって実装されても良く、ストレージは同様に複数の装置にわたって変化を与えても良い。よって、本発明は、何らかの単一の実施形態に限定されるべきではなく、添付の特許請求の範囲に応じた大きさおよび範囲で解釈されるべきである。

Claims (20)

1. データをホストするか、またはホストされたデータに接続するための方法であって、
   第１の制御領域内の少なくとも１つのコンピューティング装置によって、第２の制御領域内の少なくとも１つのコンピューティング装置から少なくとも１つのネットワークを介して、前記第２の制御領域内の少なくとも１つのコンピューティング装置によって発行された少なくとも１つのデータセットを受信するステップと、
   前記少なくとも１つのデータセットを分析して、前記少なくとも１つのデータセットのデータの少なくともサブセットと関連付けられた構造情報を判定するステップと、
   前記構造情報を前記第２の制御領域内の少なくとも１つのコンピューティング装置に対してレンダリングして、前記第１の制御領域内の少なくとも１つのコンピューティング装置によって前記少なくとも１つのデータセットに対して実施する少なくとも１つのクエリ能力に関する入力を受信するステップと
   を含むことを特徴とする方法。
2. 前記分析することは、前記少なくとも１つのデータセットと関連付けられたコラム情報を決定することを含むことを特徴とする請求項１記載の方法。
3. 前記レンダリングすることは、前記構造情報を前記第２の制御領域内の少なくとも１つのコンピューティング装置にレンダリングして前記少なくとも１つのデータセットに対して実施する複数の異なるクエリ能力に関する入力を受信することを含むことを特徴とする請求項１記載の方法。
4. 前記構造情報のうち第１の構造情報を定義する前記第２の制御領域内の少なくとも１つのコンピューティング装置から、検索パラメータ入力を受信するステップをさらに含み、少なくとも１つの許可された消費装置が、前記第１の構造情報に対して前記少なくとも１つのデータセットを検索する権限を与えられていることを特徴とする請求項１記載の方法。
5. 前記構造情報のうち第２の構造情報を定義する前記第２の制御領域内の少なくとも１つのコンピューティング装置から、検索結果入力を受信するステップをさらに含み、少なくとも１つの許可された消費装置が、前記第２の構造情報について前記少なくとも１つのデータセットから結果を受信する権限を与えられていることを特徴とする請求項１記載の方法。
6. 前記構造情報のうち第２の構造情報を定義する前記第２の制御領域内の少なくとも１つのコンピューティング装置から、検索結果入力を受信するステップをさらに含み、少なくとも１つの許可された消費装置が、前記第２の構造情報について前記少なくとも１つのデータセットから結果を受信する権限を与えられていることを特徴とする請求項４記載の方法。
7. 少なくとも１つの許可された消費装置が使用するために前記検索パラメータ入力および前記検索結果入力に基づいてクエリインタフェースを自動的に生成し、前記検索パラメータ入力および前記検索結果入力によって定義されたクエリ制約に従って前記少なくとも１つのデータセットを検索するステップをさらに含むことを特徴とする請求項６記載の方法。
8. 前記クエリインタフェースを少なくとも１つの他のクエリインタフェースと比較することに基づいて同一または類似の検索パラメータ入力に従って前記クエリインタフェースを前記少なくとも１つの他のクエリインタフェースと組み合わせるステップをさらに含むことを特徴とする請求項７記載の方法。
9. 前記クエリインタフェースを少なくとも１つの他のクエリインタフェースと比較することに基づいて同一または類似の検索結果入力に従って前記クエリインタフェースを前記少なくとも１つの他のクエリインタフェースと組み合わせるステップをさらに含むことを特徴とする請求項７記載の方法。
10. クエリにより発行者によって発行され、消費者によって消費されたデータをホストするか、またはホストされたデータに接続するためのシステムであって、
    発行装置によって発行された少なくとも１つのデータセットを受信するように構成された情報サービスと、
    前記情報サービスによって決定された前記少なくとも１つのデータセットのデータの少なくとも１つのサブセットと関連付けられた構造情報を表すように構成され、および前記構造情報からの入力の少なくとも１つの選択を受信して、前記情報サービスによる前記少なくとも１つのデータセットに対する実施のための少なくとも１つのクエリ能力を定義するように構成されたクエリ定義コンポーネントと
    を備えたことを特徴とするシステム。
11. 前記入力の前記少なくとも１つの選択を受信することに応答して、少なくとも１つの消費装置によって前記少なくとも１つのデータセットに対してクエリするためのクエリインタフェースを生成するように構成されたクエリ生成器をさらに含むことを特徴とする請求項１０記載のシステム。
12. 前記クエリインタフェースを少なくとも１つの他のクエリインタフェースと組み合わせるように構成されたクエリアグリゲータをさらに含むことを特徴とする請求項１０記載のシステム。
13. 前記クエリアグリゲータは、前記クエリインタフェースの前記少なくとも１つの他のクエリインタフェースとの比較に基づいて同一または類似のクエリ定義に従って前記クエリインタフェースを前記少なくとも１つの他のクエリインタフェースと組み合わせるように構成されていることを特徴とする請求項１２記載のシステム。
14. 前記入力の前記少なくとも１つの選択を受信することに応答して、前記少なくとも１つのデータセットを記憶する少なくとも１つのデータストアを最適化するように構成された、前記少なくとも１つのデータセットに対するクエリの最適化のためのクエリオプティマイザをさらに含むことを特徴とする請求項１０記載のシステム。
15. 前記クエリ定義コンポーネントは、前記少なくとも１つのデータセットの分析から前記情報サービスによって決定された前記少なくとも１つのデータセットのコラム情報を表すように構成されていることを特徴とする請求項１０記載のシステム。
16. データを発行するための方法であって、
    第１の制御領域内の少なくとも１つの発行コンピューティング装置によって、第２の制御領域内の少なくとも１つの受信コンピューティング装置に対して少なくとも１つのデータセットを発行するステップと、
    前記第２の制御領域内の前記少なくとも１つの受信コンピューティング装置によって生成され、前記少なくとも１つの受信コンピューティング装置による前記少なくとも１つのデータセットの分析に基づいて前記少なくとも１つのデータセットと関連付けられた構造化情報に関連する情報を含むインタフェースに対してインタフェースするステップと、
    少なくとも１つの検索パラメータに基づいて少なくとも１つの消費装置によって前記少なくとも１つのデータセットに対して検索するために前記構成化情報から前記少なくとも１つの検索パラメータを選択するステップと
    を含むことを特徴とする方法。
17. 前記少なくとも１つのデータセットに対してクエリするためのクエリインタフェースの自動生成のために、前記少なくとも１つの検索パラメータを前記少なくとも１つの受信装置に送信するステップをさらに含むことを特徴とする請求項１６記載の方法。
18. 前記少なくとも１つの検索パラメータを用いた前記検索に応答して前記少なくとも１つの消費装置によって結果を受信するために、前記構造化情報から少なくとも１つの検索結果オプションを選択するステップをさらに含むことを特徴とする請求項１６記載の方法。
19. 前記少なくとも１つの検索結果オプションに基づいて検索結果を戻すクエリインタフェースの自動生成のために、前記少なくとも１つの検索結果オプションを前記少なくとも１つの受信装置に送信するステップをさらに含むことを特徴とする請求項１８記載の方法。
20. 前記インタフェースすることは、前記少なくとも１つのデータセットと関連付けられたコラムに関連する情報を含む前記インタフェースに対してインタフェースすることを含むことを特徴とする請求項１６記載の方法。

Images