(57)【要約】本発明は、分散アプリケーション及びサービス／情報／コンテンツプロバイダ又は情報保持手段を含む環境において、汎用マークアップ言語をサポートするプロトコルを伴う要求システムと情報保持手段の間の通信を提供するためのシステム（ノード、取り決め）に関する。分散アプリケーションは、汎用マークアップ言語中の文書のフォームにおけるリクエストを、リクエストを表現する汎用マークアップ言語中の文書における位置へのポインタに関連付けられた情報保持手段へのアクセスのためのアクセスプロトコルを使用するアクセス要求に変換／コンバートするための手段を含み、又は、それに関連する。前記情報保持手段アクセス要求は、情報保持手段に対する従来のクエリとして呼び出され、前記変換／コンバート手段は、ポインタによって与えられる（指示される）ようにリクエスト文書中の適切な位置へ、情報保持手段アクセス要求に関する応答を返し、データは、情報保持手段の構造及び内容から独立して、情報保持手段から取得されうる。
2006520941.tif 000002
【特許請求の範囲】
【請求項１】
分散アプリケーション及びサービス／情報／コンテンツのプロバイダ又は情報保持手段を含む環境において、汎用マークアップ言語をサポートするプロトコルを用いる要求システムと情報保持手段との間の通信を提供するシステムであって、
分散アプリケーションは、前記汎用マークアップ言語による文書の形態をした、情報保持手段に対するリクエストを、前記リクエストを表現する前記汎用マークアップ言語による文書中の位置へのポインタと関連付けられた前記情報保持手段のアクセスのためのアクセスプロトコルを使用するアクセス要求に変換／コンバートする手段を含むか、又は、前記変換／コンバートする手段に関連付けられ、
前記情報保持手段アクセス要求は、前記情報保持手段への従来のクエリとして呼び出され、
前記情報保持手段の構造及び内容から独立して前記情報保持手段からデータが取得されるようにするために、前記変換／コンバート手段は、前記ポインタによって与えられ（示され）る、前記リクエストの文書中の適切な位置へ、前記情報保持手段のアクセス要求に関連する応答を返す
ことを特徴とするシステム。
【請求項２】
前記汎用マークアップ言語はＸＭＬであることを特徴とする請求項１に記載のシステム。
【請求項３】
前記文書はＸＭＬ  ＤＯＭノードツリー文書を含むことを特徴とする請求項２に記載のシステム。
【請求項４】
前記ＸＭＬの構造は前記変換手段に知られているが、前記ＤＯＭノードツリーの属性及び属性値の内容は知られていないことを特徴とする請求項３に記載のシステム。
【請求項５】
ＸＳＬＴ変換ファイルが、前記ポインタに接続され又は関連付けられる前記情報保持手段アクセスクエリを生成するために使用されることを特徴とする請求項４に記載のシステム。
【請求項６】
前記ポインタは、ＸＰａｔｈポインタすなわちＸＰａｔｈロケーションパスを含むことを特徴とする請求項５に記載のシステム。
【請求項７】
前記ポインタは、ＸＭＬ  ＤＯＭエレメント名を含むことを特徴とする請求項５又は６に記載のシステム。
【請求項８】
前記情報保持手段アクセス要求は、ＸＳＬＴファイル及びＸＰａｔｈロケーションパスを使用して生成され、
前記生成された情報保持手段アクセス要求の実行後、前記応答が、ロケーションパス（ＬＰ）ナビゲーションを使用して前記ＸＭＬ  ＤＯＭノードツリー中の前記適切な位置（ノード）に返される
ことを特徴とする請求項５、６、又は７に記載のシステム。
【請求項９】
前記要求は、ＸＭＬ転送文字列として情報要求アプリケーションから情報提供アプリケーションによって受信され、前記ＸＭＬ転送文字列は、前記情報保持手段との通信において前記提供サイドで、ＸＭＬ  ＤＯＭパーサを使用してＸＭＬオブジェクトに構文解析されることを特徴とする請求項８に記載のシステム。
【請求項１０】
前記要求は、タグ付けされたＸＭＬ転送文字列として情報要求アプリケーションから情報提供アプリケーションによって受信され、
前記タグ付けされたＸＭＬ文字列の前記要求は、情報保持手段のコールのために変換／コンバートされる
ことを特徴とする請求項８に記載のシステム。
【請求項１１】
同一の情報保持手段アクセス要求／クエリが、情報要求／回答のパフォーマンスを向上させるために、同一の情報保持手段、例えばデータベース、テーブルなど、の異なるデータエレメントに使用されることを特徴とする請求項８に記載のシステム。
【請求項１２】
前記システムはプライバシー保護ネットワークにおいて使用され、
前記文書は、ＸＭＬフォーム（文字列）として前記情報提供サイドへ転送される例えばＤＴＤのような取り決めの情報を使用して前記要求ノードにおいて生成されるＸＭＬフォームを含み、前記ＸＭＬフォームは、前記情報保持手段アクセス要求によって前記情報保持手段から前記データが取得された後に埋められ、前記提供アプリケーションの前記ＤＯＭノードツリー／文字列中の前記適切な位置に返される
ことを特徴とする請求項９に記載のシステム。
【請求項１３】
前記ＸＭＬ  ＤＯＭノードツリー文書は、前記変換手段に格納されるＤＴＤ又はスキーマに照らして検証されることを特徴とする請求項５乃至１２のいずれか１項に記載のシステム。
【請求項１４】
前記ＸＭＬ  ＤＯＭノードツリーは、ＤＴＤ  ＩＤによって与えられたものとして選択されたＸＳＬＴファイルを使用して変換され、
ＸＳＬＴ及びＸＰａｔｈ文字列／ファイルは、前記変換を提供するために実装される
ことを特徴とする請求項８乃至１２のいずれか１項に記載のシステム。
【請求項１５】
Ｊａｖａ（登録商標）が、前記情報保持手段アクセス要求／ステートメントを伴うＪＤＢＣ上で、前記情報保持手段を呼び出すために使用され、
前記データにアクセスする前記Ｊａｖａ（登録商標）クラスは、前記応答データを前記ＸＭＬ  ＤＯＭノードツリー中の関連するノードへ返すためにロケーションパスを使用する
ことを特徴とする請求項１３又は１４に記載のシステム。
【請求項１６】
ＸＰａｔｈシンタックスが、絶対ノードエレメントパスの「ｇｅｔ」又は「ｓｅｔ」属性値とのマッチングを提供するために使用され、
前記マッチした属性値を介して、汎用可変名が、同一の変換文字列又はターゲット文字列中の、情報保持手段アクセス要求ステートメント／コマンドに加えられうる
ことを特徴とする請求項１乃至１５のいずれか１項に記載のシステム。
【請求項１７】
ＳＱＬが、前記情報保持手段アクセス要求のために使用されることを特徴とする請求項１乃至１６のいずれか１項に記載のシステム。
【請求項１８】
ＬＤＡＰが、前記情報保持手段アクセス要求のために使用されることを特徴とする請求項１乃至１６のいずれか１項に記載のシステム。
【請求項１９】
汎用可変名は、プログラムコードによって、前記情報提供アプリケーションから受信された帯域外データから取得された実際の名前に翻訳されることを特徴とする請求項９乃至１６のいずれか１項に記載のシステム。
【請求項２０】
分散アプリケーションを含む環境において、汎用マークアップ言語をサポートするプロトコルを伴うシステムと情報保持手段との間の通信を提供する方法であって、
汎用マークアップ言語による要求文を、アプリケーションに含まれる又は関連付けられるコンバート／変換手段に提供する、又は、前記コンバート／変換手段で受信するステップと、
前記要求を、前記汎用マークアップ言語による前記要求文中の適切な位置へのポインタに関連付けられた情報保持手段アクセスプロトコル／言語を使用して、情報保持手段アクセス要求に変換／コンバートし、前記要求を表現するステップと、
従来のクエリとして前記情報保持手段に対する前記情報保持手段アクセス要求を呼び出すステップと、
前記ポインタによって与えられる、前記要求文中の前記適切な位置へ、前記クエリに関連する応答データを返し、それにより情報データが前記情報保持手段の構造及び内容から独立して情報保持手段から取得され適切に割り当てられるようにするステップと、
を備えることを特徴とする方法。
【請求項２１】
前記汎用マークアップ言語はＸＭＬであり、
前記要求文はＸＭＬ  ＤＯＭノードツリーを含み、前記ＸＭＬ  ＤＯＭノードツリーに対するエレメント及び属性の内容は未知である
ことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記変換／コンバートステップは、
ＸＳＬＴを発見／選択するステップと、
前記発見／選択されたＸＳＬＴを使用して前記変換を実行するステップと、
前記ＸＭＬ  ＤＯＭノードツリーの位置（例えばノードエレメント）を機能的に確立するためにポインタとしてＸＰａｔｈロケーションパスを使用するステップと、
ノードエレメントパスのＸＰａｔｈポインタ（シンタックス）を、応答情報データの返す位置（ノード）に関する情報を含むターゲット文字列を提供するために、前記情報保持手段アクセス要求に追加するステップと、
前記応答を、ＸＰａｔｈポインタを使用して前記ＸＭＬ  ＤＯＭノードツリーの関連する位置（ノード）へ返すステップと、
を備えることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記方法は、変換ステップの実行中に、
汎用可変名を提供するために、前記ＸＭＬ  ＤＯＭノードツリーの絶対ノードエレメントのパスに関連する「ｇｅｔ」又は「ｓｅｔ」属性値とマッチングするためのＸＰａｔｈを使用するステップと、
前記汎用可変名を、共通の（単一の）変換された文字列又はターゲット文字列を提供するために、前記情報保持手段アクセス要求に追加するステップと、
を備えることを特徴とする請求項２２に記載の方法。
【請求項２４】
さらに、
提供サイドのユーザＩＤのための置換タグとして前記汎用可変名を使用するステップと、
帯域外情報として前記提供サイドのＩＤを取得するステップと、
要求された情報を取得するために前記情報保持手段中の適切なレコードにアクセスするための帯域外情報として取得された実際のＩＤによって、前記置換タグの前記汎用可変名を置き換えるステップと、
返答（応答）データを前記ＸＭＬ  ＤＯＭノードツリー中の適切なノードへナビゲートするためにロケーションパス情報を使用するステップと、
を備えることを特徴とする請求項２３に記載の方法。
【請求項２５】
さらに、複数の情報保持手段アクセス要求ステートメント／コマンドを１つのアクセス要求ステートメント／コマンドに連結し、それによって、情報を要求し、要求された情報を取得する際のパフォーマンスを向上させるために、例えば格納アレイ中の格納手段に前記ＸＰａｔｈシンタックスを格納するステップを備えることを特徴とする請求項２２乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記方法は、プライバシー保護ネットワークにおいて使用され、ＸＭＬフォームは、前記情報保持手段から前記情報を取得する提供アプリケーションを介して情報を要求するための要求アプリケーションサイド上で生成されることを特徴とする請求項２０乃至２５のいずれか１項に記載の方法。
【請求項２７】
前記情報保持手段アクセス要求のために、ＳＱＬが使用され、ＳＱＬステートメント／コマンドを提供することを特徴とする請求項２０乃至２６のいずれか１項に記載の方法。
【請求項２８】
前記情報保持手段アクセス要求のためにＬＤＡＰが使用されることを特徴とする請求項２０乃至２６のいずれか１項に記載の方法。
【請求項２９】
前記情報保持手段は、データベース（ＤＢ）を含むことを特徴とする請求項２０乃至２８のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はそれぞれ、分散アプリケーションを備える環境において、汎用マークアップ言語をサポートするプロトコルシステムと、情報保持手段、又は、サービスプロバイダ／情報プロバイダ／コンテンツプロバイダとの間の通信を提供するシステム及び方法に関する。本発明は、特に、プライバシー保護ネットワーク中の情報保持手段にある情報へのアクセスに関する。
【背景技術】
【０００２】
情報要求サイドが情報提供サイドに存在する情報にアクセスすることを要求したり、アプリケーションが提供サイドから情報を、特に動的情報へのクエリに対してではなく、要求したりする状況で満足に機能する公知の技術は存在しない。すべての公知技術は、例えば使用されているテーブルのような、アプリケーションに含まれていたり関連付けられていたりする情報保持手段の実装面の構造に、強く依存する。ＳＱＬ（構造化照会言語）は、そのような技術の１つであり、特定かつ既定の基準に一致する１つ又は複数の情報が検索されることに、特に適している。ＳＱＬは、極めて特定された入力データを必要とし、データベース及びその関係(relations)の構造について熟知していることを前提としている。動的な入力パラメータを使用して、適切な動的回答を得ることは不可能であり、適切な位置に戻すことは特に不可能である。一般的に、情報へのアクセスがＩＰベースのデータ通信ネットワーク上で要求されると、いくつかのＴＣＰ（伝送制御プロトコル）接続のセットアップが要求される。特に、既知のシステムは、種々のアプリケーションや情報提供サイトなどネットワークのいたる所に置かれている個人プロファイルに含まれるデータを保護するというエンドユーザのニーズも満たすようには容易に構成されえない。一般的に、特に分散アプリケーションによる環境では、特定の情報保持手段の構造及び内容を知っているとともに、この情報保持手段に適合されたアプリケーション無しには、情報保持手段からの情報にアクセスするための満足な解決法はない。アクセスシステムと情報保持手段の間のハードコードされたリンクを使用することによりこの問題を解決する方法が知られている。しかし、商業的な視点からは、ハードコードされたリンクを伴う解決法は不都合である。ＳＷ（ソフトウェア）プログラマが関与すること無しに変更を行うことは、困難又は不可能である。この問題は、例えばデータベース中の情報構造が頻繁に変化し、それゆえソフトウェア開発が大規模にならざるをえないときに、特に顕在化する。そのアプリケーションを実行している会社がＳＷ会社ではない場合、常にＳＷプログラマを雇用しなければならなかったり、又は、広域的なサポート機関によるＳＷインテグレータを提供しなければならなかったりすることは、費用がかかる。これでは収益を上げられない。今まではハードコードされたリンクによって解決してきたとしても、アプリケーションは種々の内容を伴う多くの異なるデータベース構造にカスタマイズされる必要があることも、問題となる。特に、例えばデータベースから取得された回答を、要求文やクエリ中の「位置」に結びつけたり関連付けたりすることは、問題となる。一般的に、要求文に対する回答を返すことは容易であるが、それを関連するクエリの適切な「位置」にどのようにして関連付けるかに関する解決法は現在のところ存在しない。特に、例えばＸＭＬのような汎用マークアップ言語を活用するときに、上述した問題に対する解決法は存在しない。その場合、例えばＸＭＬ  ＤＯＭノードツリー（クエリ）とデータベースとの間のリンクはハードコードされたＳＱＬ命令文であり、それは上述したように不都合なものである。
【０００３】
特に、どの情報を誰に提供するかなどをユーザフレンドリーな方法でエンドユーザが制御する簡単な方法も、実質的に存在しない。また、より一般的には、どの動的情報やメッセージが２つのアプリケーション間で交換されてもよいかに関する簡単でユーザフレンドリーな手続き（プロシージャ）は存在しない。使用されているデータベースの構造などを明らかにしたくないという要望が存在するときに、企業間の通信に使用可能で、かつ、満足に機能する解決法も存在しない。
【特許文献１】国際公開０２／３１６９０号パンフレット
【発明の開示】
【発明が解決しようとする課題】
【０００４】
それゆえ、本発明の目的は、アクセスするアプリケーションと例えばデータベースなどの間にある、特定の情報保持手段の構造及び内容であるハードコードされたリンクに頼る必要なしに、例えばデータベースのような情報保持手段へのアクセスが提供されるシステム及び方法を提供することである。このシステム及び方法は、汎用的かつ標準的な方法によるものであり、ハードコートされたリンクに依存することも関連することもない。
【０００５】
本発明の他の目的は、容易で分かりやすい方法で汎用マークアップ言語を使用するときに、クエリに対するどの回答が要求文中の適切な位置に返されうるかに関する解決法を提供することである。特に、情報保持手段に対するどのインタフェースが、その情報保持手段のソフトウェア開発に関する知識を必要とすることなく、標準化された方法で構成されうるかに関する解決法を提供することが目的である。
【課題を解決するための手段】
【０００６】
情報要求サイドと情報提供又は保持サイドとの間の情報／メッセージの交換を効率的に処理することのできる取り決めもまた、必要とされるものである。どの機能が、あらゆる情報保持手段の実装、構造、及び関連付けと独立しているかという取り決めも必要とされる。使用することが容易で、その機能が簡単な取り決めも必要とされる。動的情報に関するクエリに使用されうる取り決めは、特に必要とされる。最も具体的には、個人のプライバシーを十分に配慮可能な、すなわち、エンドユーザの個人プロファイルに含まれるデータへのアクセス制御を同時にサポートできる、上述した取り決めが必要とされる。
【０００７】
それゆえ、冒頭で述べたシステム及び方法はそれぞれ、独立項の特徴を伴って提案される。好適な実施形態は、添付の従属項によって定められる。システムはここでは、取り決め又はノードとしても解釈される。
【発明を実施するための最良の形態】
【０００８】
添付の図面を参照して、以下に、限定的でない方法で、本発明をより詳細に説明する。
【０００９】
まず、この説明において使用されるいくつかのコンセプトを簡潔に説明する。要求する側のシステムは、ここでは、要求を行うアプリケーション（要求アプリケーション）及び提供を行うアプリケーション（提供アプリケーション）のうち少なくともいずれかとして考えられる。
【００１０】
最も好適な実施形態では、汎用マークアップ言語はＸＭＬ（拡張マークアップ言語）である。２つの当事者間の合意は、特に、ＤＴＤ（文書型定義）を含み、それは以下ではＤＴＤ合意として言及される。その合意は、すなわち、どのデータやどんな種類のデータが２つの当事者間で交換するのを許可されるかを指定するものである。特に、あるフォームが要求目的のために使用される。このフォームは、データを「設定」又は「取得」することに関する情報と、該当する場合は要求されるデータ自体とによってタグ付けされた、ＸＭＬ（ノード）ツリーを含みうる。
【００１１】
ＤＴＤは、ＸＭＬ文書中にあるコンテンツの構造の雛形（モデル）を記述する。その雛形は、提供されるべきエレメントと、どのエレメントが任意であるかと、それらの属性がどれであるかと、それらがお互いに対してどのように構造化されるかと、を指定する。比較として、ＨＴＭＬ（ハイパーテキストマークアップ言語）は、１つだけＤＴＤを持つ。ＸＭＬを使用すると、ユーザアプリケーションごとに独自の複数のＤＴＤを作ることが可能となり、それは、アプリケーションのために作られたＸＭＬ文書の内容及び構造を制御する処理の完全な制御を提供する。ＤＴＤは、文書型宣言手段によって、ＸＭＬ文書に関連付けられる。文書型定義であるＤＴＤは、ここでは、文書の種類（又はクラス）のコンテンツモデルのＸＭＬによる記述である。文書型宣言は、ある特定のＤＴＤがある文書に属することを説明する、ＸＭＬファイルにおける宣言である。
【００１２】
特に、フォームは、クエリを伴うＸＭＬ（ノード）ツリーを例えば属性の形で含む。この属性は、フォームを埋めるために付与される値であってもよい。特定の実施形態では、属性は、１つ又は複数の「ｆｒｏｍ」、「ｇｅｔ」、「ｎｕｌｌ」、「ｅｒｒｏｒ」、「ｓｅｔ」を含み、その重要性は読むことによって明らかになるであろう。
【００１３】
１つの実施形態では、タグの付いたＸＭＬフォームは、ＸＭＬ文字列を含む。好適な実施形態において、タグの付いたＸＭＬフォームは、ＸＭＬオブジェクト（ＤＯＭノードツリーオブジェクト）を含む。ＤＯＭは、Ｗ３Ｃ、ワールドワイドウェブコンソーシアム、によって規定されるドキュメントオブジェクトモデルの略語である。ＤＯＭは、ＸＭＬ用の、標準化されたツリーベースのアプリケーションプログラミングインタフェース（ＡＰＩ）である。オブジェクトフォームは、それぞれのアプリケーションにおいて変換／構文解析手段に関するプロビジョニングを前提としている。すなわち、要求アプリケーション及び情報提供アプリケーションでは、ＸＳＬ変換スタイルシート（ＸＳＬＴ）を使用してＸＭＬオブジェクトをＸＭＬ文字列に変換し、ＸＭＬ文字列をＸＭＬオブジェクトに構文解析するためである。特定の実施形態では、サーバ手段は、要求及び提供アプリケーションにそれぞれ関連付けられている。ＸＭＬ文字列はユーザにとって「可視的」、すなわち読むことができ、反対に、ＸＭＬオブジェクトは「不可視」、すなわち読むことができない。
【００１４】
本発明によれば、（提供）アプリケーションは、要求された情報を取得するために、受信したＸＭＬフォームクエリを、例えばＳＱＬ形式のデータベースコールに変換する手段を備える。（もしそれがｐｕｌｌ又は「ｇｅｔ」（取得）処理なら）要求された情報が抽出されると、この抽出された情報が、要求アプリケーションに再送するための形式でフォームに入力又は埋めこまれる。アプリケーションは、特に、要求及び提供という両方のアプリケーションとして機能しうる。しかしながら、いくつかのアプリケーションにとって、取り決めは、複数のアプリケーションのうち１つは常に要求者の機能を果たし、他のものは常に提供者又は保持者の機能を果たすという仮定に基づいている場合もある。なお、本発明は、ＳＱＬでの実施形態に限定されてはおらず、それどころか、あらゆるアクセスプロトコル又は情報保持手段にアクセスするための言語、例えばＬＤＡＰ（簡易ディレクトリアクセスプロトコル）や他のあらゆる類似のプロトコル、が使用されうることは明らかである。
【００１５】
ＸＭＬリクエスト、例えばＸＭＬフォームは、あらゆる情報保持／提供手段、例えばデータベースや類似の手段、および、あらゆるアプリケーションについての構造上の実装から完全に独立している。
【００１６】
好適な実施形態において、リクエストの検証のために、検証手段が提供される。検証手段は、エンドユーザに制御され、ユーザ固有の、取り決め情報格納手段中に格納される複数のＤＴＤを含む。リクエストアプリケーションからの入力済みＸＭＬフォームは、そのリクエストが許可されるか否かを確認するために、エンドユーザ固有の適切なＤＴＤに照らして検証される。
【００１７】
他の実施形態によれば、システムによって提供される、情報要求アプリケーションへのそれぞれのサービスには、固有のＤＴＤ（文書型定義）が割り当てられる。ＤＴＤは、どのデータが２つの部分又はサイドの間で転送されることを許可されているかと、転送される関連データとを規定することにより、例えば要求サイドと提供サイドの間の通信を制御するルールを構成すると言える。
【００１８】
それぞれの情報提供アプリケーションは、「汎用ＤＴＤ」について中央サーバ手段と合意する。これによって、情報提供当事者が提供するデータフィールドの最大数が特定される。特定のエンドユーザは、中央サーバ手段とやりとりすることにより、ユーザ固有のＤＴＤを生成し、それによって、提供することが許可される、彼らのＩＤに関連するデータを減少させる。さらに、中央サーバ手段は、特定のサービスが何を提供しているかを説明するために、情報提供アプリケーションに「汎用ＤＴＤ」を提供する。これは、あらゆるエンドユーザ固有の提供されるデータの減少に先立って提供される。
【００１９】
特に、「汎用」又は基本ＤＴＤは、取り決めに対して与えられ、それは、基本ＸＭＬフォームを構築するために使用されうる。そのような基本ＤＴＤは、同様のサービスに関連するアプリケーション間の情報交換にも適用可能である。すなわち、同じ基本ＸＭＬフォームは、第１のアプリケーションが、同じ種類又は範疇に属する第２のアプリケーションのいくつかと情報を交換するために使用されうる。検証が実装される場合、ＤＴＤはＸＭＬフォームと共に送信される。検証が実装されない場合、ＤＴＤを含めることは任意である。しかしながら、また、検証処理にとって、ＤＴＤを含めることは常に必須なわけではない。
【００２０】
最も好適な実施形態では、検証を含めることにより、アクセス手段（例えばプラグインサーバ手段）がそれぞれの要求及び提供アプリケーションに具備されるか又は関連付けされる。これらのアクセス手段は、１つ又はそれ以上の中央保護サーバ手段と通信しており、中央保護サーバ手段と共に、アクセス手段は個人保護プロファイルネットワークを構成する。中央保護サーバ手段は、個人保護プロファイル保持手段を含むか、又は、それと通信する。特に、個人保護プロファイル保持手段は、エンドユーザ固有の保護プロファイルを保持する。このプロファイルは、個人プロファイルに含まれるどのデータがどのアプリケーションに対してアクセス可能又はアクセス不可能であるかを指定する。エンドユーザ保護プロファイルは、好ましくは、エンドユーザに制御され、ユーザ固有の複数のＤＴＤを含む。
【００２１】
特に、アプリケーション及びそれに関連するアクセス手段は、ＸＭＬトランスポートオブジェクト中のＸＭＬオブジェクト、例えばＸＭＬノードツリーコンテナ中のＸＭＬノードツリーなどの手段によって、例えばＲＭＩ（遠隔メソッド呼出し）又はＣＯＲＢＡ（商標）を使用して、通信する。要求アプリケーションに関連付けられたアクセス手段は、特に、要求アプリケーションから提供された汎用取り決め（汎用又は基本ＤＴＤ）に関する情報を使用して中央保護サーバ手段中のユーザ固有のＤＴＤ、すなわち個人保護プロファイルを探索する。入力済みのＸＭＬフォームは、ユーザ固有のＤＴＤに照らして検証される。
【００２２】
図１は、（外部）システム、又は、ＸＭＬをサポートし、分散環境においてアプリケーション２にリクエストを提供するノード１を示す単なる概略的な図である。アプリケーション２は、例えばリクエストを、例えばＳＱＬリクエスト（例えばＤＢコール（又はより一般的には情報保持手段に対するアクセスのアクセス要求））、に変換するための変換手段３（例えばコンポーネント）を備え、情報を取得し、特に図６〜８を参照してさらに説明するように、それを（ＸＭＬ）リクエストにおける（例えばＸＭＬ  ＤＯＭノードツリーの）適切な位置／ノードに返す。
【００２３】
以下では主にＳＱＬリクエストに言及するが、例えばＬＤＡＰやそれに似たものも使用されうることは明らかである。
【００２４】
図２は、２つの通信アプリケーションを極めて概略的に示している。ここでは、情報要求アプリケーションＡ１０と情報提供アプリケーションＢ２０が示される。それぞれのアプリケーション１０及び２０は、それぞれのアプリケーション間で確立された取り決めに関する情報を保持するための取り決め保持部（不図示）を含み、又は取り決め保持部と通信する。それゆえ、２つのアプリケーション間、ここではアプリケーションＡ及びＢ、の取り決めは、それぞれ両方のアプリケーションに格納されているということが想定される。アプリケーションの取り決め保持部は、実装される場合、複数の異なる取り決めを含む。これらの取り決めは、例えば、相互のアプリケーションにとって、どの関係しているアプリケーションが取り決めを決定し、どの又はどんな種類の情報がそれぞれの１対のアプリケーション間で交換されることが許可されるかを規定するものである。図において、それぞれのアプリケーションが、リクエストが送信されたときに入力済みのＸＭＬフォームを生成するための、ＸＭＬリクエストハンドラを含み、実際にはソフトウェア（すなわち、必ずしも特定の手段ではない）を含むことが示されている。この第１の実施形態において、アプリケーションＡ１０はアプリケーションＢ２０から情報を要求することが想定されている。
【００２５】
なお、本発明のコンセプトは、ＸＭＬ「フォーム」に限定されるものではなく、また要求及び提供アプリケーションである必要もない。主なコンセプトは（ここでは）アプリケーションＢ、すなわち、あらゆる分散アプリケーション及び情報保持手段（ＤＢ）２３の間の処理を扱うことである。
【００２６】
アプリケーションＡ及びＢの間で確立された取り決めは、取り決め情報保持部（不図示）において特にＤＴＤ（文書型定義）取り決めの形式で得られるのだが、特定のリクエストに従って与えられる値の属性の形式のクエリと共に、ＸＭＬフォームを例えばＸＭＬ  ＤＯＭノードツリーの形式で生成する、ＸＭＬフォームハンドリング機能によって使用される。それゆえ、ＸＭＬフォームが生成されると、属性に値が与えられ、（属性及びエレメントデータ中の）情報でタグ付けされた、要求された情報に関係するＸＭＬフォームは、例えばＨＴＴＰ（Ｓ）を使用するＩＰネットワーク上で、ＸＭＬ転送ファイル、例えばＸＭＬ文字列として、転送される。
【００２７】
好適な実施形態において、ＸＭＬノードツリーは、ＸＭＬ  ＤＯＭノードツリーを含む。あるいは、ＸＭＬツリーは、ＸＭＬ文字列として実装される。もしＸＭＬフォームがオブジェクトとして構築されると、ＸＭＬ転送文字列への変換が、転送目的のために要求される。アプリケーションＢ２０において受信されたＸＭＬフォームは、ここでは特に変換手段により、データベースコールに変換される。それは特に、クエリによって指示されるデータを、要求された情報を保持するデータベース２３からアクセス又は取得するために、ＳＱＬリクエストに変換される。要求された情報がデータベース２３から取得されると、特に、属性及びエレメントデータに、適切な値、すなわち本発明に従ってデータベース２３から取得される値、を与えることによって、フォームが埋められる。もしリクエストが代わりにデータの設定に関するものである場合、「要求された」データが例えばＳＱＬの手段によってアクセスされ、属性に従うデータが設定される。
【００２８】
完成したＸＭＬフォームが、次いで、アプリケーションＡ１０に返され、入力済みのフォームがユーザに提供される。図２は、値の与えられた属性を含むＸＭＬフォームが与えられる機能についての概略図である。属性に与えられる値は、（設定又は取得の目的で）どの情報が要求されたかを規定すると共に、要求アプリケーションに返されたときに（もし関係があれば）その要求された情報を含む。ＸＭＬフォームが文字列として実装される場合は、データベースコール（ＳＱＬリクエスト）への変換（コンバージョン）を除き、いずれの変換／構文解析手段も要求されない。しかしながら、ＸＭＬフォームがＸＭＬ  ＤＯＭノードツリーの形式で表現される場合は、アプリケーション間で変換する目的のために、変換手段（及び文字列フォーマットのフォームをＤＯＭノードツリーに変換するための構文解析手段）が要求される。本発明は特に、ＳＱＬリクエストの変換と、要求文、例えばＸＭＬノードツリーのノードなどの適切な位置に応答を返すことに関する。
【００２９】
図３は、少し異なる実施形態を概略的に示す図である。要求アプリケーション１００は提供アプリケーション２００から情報を要求する。取り決めは、アプリケーション１００と２００の間で確立している。ここで、取り決め情報は、要求アプリケーション１００と提供アプリケーション２００の両方と通信する、外部の取り決め保持部に格納されているということが想定されている。取り決め保持部３０Ｃと提供アプリケーション２００との間の通信は、ここでは、破線によって示されており、要求アプリケーション１００が提供アプリケーション２００から情報を要求しても（又は提供／保持サイドのデータにアクセスすることを欲しても）、提供アプリケーション２００は取り決めを取得する必要がない（少なくとも、検証が要求されないときだけでなく、好適な実施形態によれば全く必要ない）。ここでは、取り決めは文書型定義ＤＴＤの形態で生成されていることが想定されている。要求アプリケーション１００と提供アプリケーション２００の間の取り決めは、ここでは、ＤＴＤ１として示されるものとする。アプリケーション１００がアプリケーション２００から情報を取得することを欲すると、ＤＴＤ１が取得され、ＸＭＬ  ＤＯＭノードツリーオブジェクト（又はＸＭＬ文字列）が、要求アプリケーション１００のＸＭＬフォームハンドラにおいて生成される。ＸＭＬノードツリーにおける属性に、要求されたデータに関する（割り当てられた）値が与えられる。属性の例には、「ｆｒｏｍ」、「ｇｅｔ」、「ｓｅｔ」、「ｎｕｌｌ」、「ｅｒｒｏｒ」がある。
【００３０】
このアプリケーションにおいて、すべての実施形態は、提供サイドからデータを取得（プルする：取り寄せる）ための実装を参照して説明されている。本発明のコンセプトは、もちろん、データをプッシュする、すなわち提供サイド又は情報保持サイトにデータをセットする、というコンセプトにも適用可能である。
【００３１】
ＸＭＬフォームは、それが文字列の形態であれば、属性に適切な値が与えられたときに、ＸＭＬ文字列として提供アプリケーション２００に転送される。なお、任意でＤＴＤ１を含んでもよい。提供アプリケーション２００において、変換手段、すなわち、必ずしも「手段」の中で提供される必要のないソフトウェア、の中で、ＳＱＬフォーマットのデータベースコールに対して変換が実行される。なお、データベースコールは、データベース２３０に転送される。要求されたデータは、続いて、提供アプリケーションに返され、関係する属性とエレメントのデータ上の値としてＸＭＬフォーム上に埋められる。そのフォームは、ＸＭＬ文字列として要求アプリケーションに返される（任意でＤＴＤが含まれる。特にこの場合、ＤＴＤ１である）。他の好適な実施形態において、ＸＭＬツリーフォームは、ＸＭＬ  ＤＯＭノードツリーオブジェクトとして実装される。そのオブジェクトは、要求アプリケーションＡ１００から提供アプリケーションＢ２００への転送のために、文字列に変換されなければならない。ＸＭＬ文字列は、ＤＯＭパーサの手段によって提供サイドで構文解析され、オブジェクトの形態にされる。しかしながら、要求アプリケーションへの再送のために、ＸＭＬ  ＤＯＭノードツリーはＸＭＬノード文字列に変換される。
【００３２】
図４は、２００１年１０月１２日に米国で出願された、特許出願番号０９／９７６，５００の「アクセス制御に関するシステム及び方法」に記載されている検証処理を含む、特有の実施形態を示す。その特許出願の記載内容は、本願に援用される。図４を参照すると、情報要求アプリケーション１０１が情報提供アプリケーション２０１から、その情報自体がどこで見つかるかを知ること無しに、情報を取り寄せる（取得する）ことを欲するものとする。本実施形態において、中央サーバ手段３１１との通信は、要求アプリケーション１０１のインタフェースであるアクセス手段１１１によって提供されるものとする。そのような実施形態の利点は、要求されたトランザクションが可能かどうかについて、プライバシーネットワークから、すなわち中央サーバ手段３０１からの高速な応答が取得されるということである。情報提供アプリケーション２０１のアクセス手段２１１（又は情報提供アプリケーション自体）を必要とすることもない。情報提供サイドのアクセス手段２１１において拒絶されたトランザクションに起因する負荷は、提供サイドが初期段階に含まれる場合に比べて、大幅に減少される。
【００３３】
それゆえ、情報要求アプリケーション１０１が情報提供部又は保持部に情報を設定したりそこから情報を取得したりすることを欲すると、情報要求アプリケーション１０１は、「自身」のアクセス手段１１１に対するＸＭＬリクエストを生成する。要求アプリケーションは情報提供部のアドレスを知らない。さらに、アクセス手段１１１は公開鍵と秘密鍵を保持するものとする。ノードの秘密鍵ＰＫＩ（公開鍵基盤）は、例えばキーオブジェクトとして、例えば安全なオブジェクトファイルに格納される。
【００３４】
特定の実施形態において、リクエストはＲＭＩ上で送信され（Ｉ）、好ましくは、以下のものを含む。
・リクエストに関連付けられ、要求アプリケーションに使用されるユーザ識別情報（ＩＤ）
・ＤＴＤ  ＩＤ（サービスＩＤと同等）
・トランザクションＩＤ
・要求アプリケーションのＩＤ
・ゲートウェイＩＤ
・ＸＭＬノードツリーコンテナ
ＸＭＬノードツリーコンテナは、要求アプリケーションが取得することを欲する情報又は設定したり更新したりすることが望まれるデータを含む個人データフィールドを用いてタグ付けされたＸＭＬ（ノード）ツリーを含む。タグ付けされたＸＭＬ（ノード）ツリーは、例えばフォームとして説明される、ＸＭＬノードツリーフォームである。
【００３５】
ＸＭＬノードツリーコンテナは、要求アプリケーションとそのアクセス手段１１１間でのＸＭＬノードツリーの転送のためのオブジェクトである。Ｉは、要求アプリケーション１０１からアクセス手段１１１へのリクエストを示す。アクセス手段１１１は、汎用ＤＴＤを見つける。すなわち、ＤＴＤはまだ、個人データの転送、汎用ＸＳＬＴファイル、中央サーバ手段の公開鍵、ＤＮＳ（ドメイン名システム）ネーム、及びＩＰアドレス（１つより多くの中央サーバ手段がそれぞれＩＤを持つ場合、ＤＴＤ  ＩＤのためのメイン中央サーバ手段からの１つ又は複数のＩＰ番号ベースのＵＲＬ）上で、特定のエンドユーザの好みに合わせられてはいない。
【００３６】
ある実施形態では、具体的な中央サーバ手段ＩＤを調べることは、当該ＩＤが特定の中央サーバ手段の公開鍵を用いてデータベース（ＤＢ−Ａ１２）により特定されるならば、任意で用いられてもよい。これは、中央サーバ手段が同一の公開鍵を持つクラスタにあるものではなく、例えば同一のドメイン名を使用するものであるときに、使用されうる。中央サーバ手段ＩＤに関係する情報、すなわちＤＴＤ情報などは、アクセス手段１１１によって、関連するデータベース１２１から取得される。
【００３７】
要求アプリケーション１０１のアクセス手段１１１は、次いで、ＩＩで、この特定のサービス及びエンドユーザＩＤのための特定のＤＴＤを見つけるために中央サーバ手段３０１にリクエストを送信する。特に、ＨＴＴＰＳが使用される。リクエストは特に以下のものを含む。
・要求アプリケーションアクセス手段１１１の識別情報
・秘密鍵を伴う、要求アプリケーションアクセス手段の電子署名
・要求アプリケーション１０１によって使用されるエンドユーザＩＤ
・ＤＴＤ  ＩＤ（サービスＩＤと同等）
・トランザクションＩＤ
・ゲートウェイＩＤ
・要求アプリケーションのＩＤ
アクセス手段１１１によって、中央サーバ手段３０１からの応答が待ち受けられ、期待される。一方、要求アプリケーションのアクセス手段１１１は、任意で、ＤＴＤ  ＩＤ（サービスＩＤ）のための汎用ＤＴＤによりＸＭＬノードツリーを検証してもよい。これは基本的な検証を構成し、サーバが起動して要求アプリケーションアクセス手段１１１の負荷を制限するために動作するときから、ＤＴＤが最初に使用されるときになされる。
【００３８】
中央サーバ３１１は、制御ロジックを含み、アクセス手段の識別情報と、ＩＰアドレスと（任意）、アクセス手段１１１の公開鍵に対する電子署名を含むリクエストの認証を検査する。要求アプリケーションユーザＩＤとＤＴＤ  ＩＤは、次いで、情報提供アプリケーションユーザＩＤにマッピングされる。なお、要求アプリケーションによって使用されるエンドユーザＩＤ（識別情報）は、情報提供アプリケーションによって使用されるエンドユーザ識別情報と異なっていてもよいし、通常、異なっている。すなわち、ある人と同一のエンドユーザに対して、複数のアプリケーションは異なる複数のＩＤを使用することができる。
【００３９】
情報提供アプリケーション２０１のユーザＩＤは、情報提供アプリケーション２０１のアクセス手段２１１の公開鍵を使用して日付／時刻と共に暗号化され、情報提供アプリケーションアクセス手段２１１によってのみ読まれ、理解されることができる。暗号化パターンは、要求アプリケーション１０１のアクセス手段１１１がリクエストを行うたびに異なっているべきである。中央サーバ３１１は、中央サーバ手段３０１の秘密鍵で署名されたデータベース保持保護プロファイル情報３２１から、エンドユーザ固有のＤＴＤのための電子署名を取得する。よいパフォーマンスを得るために、すべてのＤＴＤは事前に署名されている。「帯域外(out of band)」の情報エレメントも、署名されている。（「帯域外」の情報はここでは、例えばアクセス手段のための制御情報を含む、システムレベルの通信レイヤを意味する。これは例えば、順方向のＨＴＴＰ  ＰＯＳＴ及び逆方向のクッキーとして、実装され得る。）
中央サーバ手段３１１は次いで、要求アプリケーションアクセス手段１１１に対して、帯域内情報としてエンドユーザ固有のＤＴＤを含むメッセージを返す（ＩＩＩ）。（「帯域内(in-band)」は、ここでは、アプリケーションデータ通信レイヤ、例えばＸＭＬ文書レベルにおける情報を意味する。）中央サーバ手段３１１はまた、以下のような「帯域外」情報を返す。
・エンドユーザ固有のＤＴＤの電子署名
・中央サーバ手段「帯域外」情報の電子署名
・中央サーバ手段の識別情報
・暗号化されたエンドユーザＩＤ、すなわち情報提供アプリケーションエンドユーザＩＤ
・有効期限
・不活性期間
・応答期限
・情報提供アプリケーション２０１のアクセス手段２１１のドメイン名
・そのＩＰアドレス
・それぞれのアクセス手段１１１と２１１の公開鍵
（アクセス手段１１１を介した）要求アプリケーション１０１からのトランザクションＩＤ、要求アプリケーション１０１のユーザＩＤ、及び情報提供アプリケーションの暗号化されたユーザＩＤは、中央サーバ手段３０１でログが記録される。
【００４０】
要求アプリケーション１０１のアクセス手段１１１において、中央サーバ手段３１１の公開鍵による電子署名が認証される。要求アクセス手段１１１は、ＸＭＬノードツリーを汎用ＸＳＬＴファイル（その特定のＤＴＤ  ＩＤのためのＸＳＬＴファイル）を伴うＸＭＬ転送ファイル（文字列）に変換することを実行する（ＸＳＬ変換；ＸＳＬは、例えば、１９９９年１１月１０日のＸＳＬ変換（ＸＳＬＴ）バージョン１．０、Ｗ３Ｃ  Ｒｅｃ．や、２０００年１２月１２日のＸＳＬ変換（ＸＳＬＴ）バージョン１．１、Ｗ３Ｃワーキングドラフトで説明されており、これらの文書はこれにより本願に援用される）。
【００４１】
要求アプリケーションアクセス手段１１１は、ＸＭＬ転送ファイル（文字列）を、受信されたエンドユーザ固有のＤＴＤに対して検証する。次に、ＸＭＬファイルは署名される。ＸＭＬ属性を介して何らかのリクエストがあり、それへのアクセスが許可されなかった場合、アクセス手段１１１と２１１のうちの１つによってエラーメッセージが要求アプリケーション１０１に返される。
【００４２】
しかしながら、もし検証がエラーなく完了できた場合、要求アプリケーションアクセス手段１１１は、情報提供アプリケーションのアクセス手段２１１に以下のものを送信する（ＩＶ）。
・（帯域内情報としての）ＸＭＬ転送（文字列）及び例えばクッキーの形態での帯域外情報、すなわち、アクセス手段１１１の秘密鍵によるＸＭＬ転送ファイル（文字列）のためのデジタル署名
・中央サーバ手段３０１からの、帯域外情報（サーバＩＤ）の電子署名
・暗号化されたエンドユーザＩＤ（情報提供アプリケーションのユーザＩＤ）
・有効期限
・不活性期間
・応答期限
・情報提供サイドの検証
・ＤＴＤ  ＩＤ
・それぞれのアクセス手段１１１、２１１の公開鍵
すべての電子署名が必要なわけではなく、要求されるセキュリティの程度によっては、それらのいくつかは任意である。
【００４３】
要求アプリケーションアクセス手段１１１はここで、情報提供サイドのアクセス手段との通信のためにＨＴＴＰＳを使用する（ＩＶ）。
【００４４】
要求アプリケーションアクセス手段１１１が情報提供アプリケーションのアクセス手段２１１から所定の時間内にいかなる応答も受信しなかった場合は、要求アプリケーションアクセス手段１１１は（ＴＣＰ；伝送制御プロトコル）接続を切断する。情報提供サイド上の同一のアクセス手段からの応答を取得しようとする試みが所定回数実行された後で、要求アプリケーションはセッションデータを空にもする。あるいは、例えばクラスタや複数のアクセス手段や複製されたアクセス手段のようなものが存在する場合、情報提供手段の他のアクセス手段における１回又は複数回の試みが実行された後で、セッションデータを空にする処理が実行されてもよい。
【００４５】
情報提供アプリケーションアクセス手段２１１がリクエストを受信すると（ＩＶ）、ＤＴＤ  ＩＤを使用してそれは以下のものを取得する。
・中央サーバの公開鍵
・中央サーバ及び汎用ＤＴＤのＩＤ
・データベース２２１からの特定のＤＴＤ  ＩＤのための汎用ＸＳＬＴファイル
要求サイドアクセス手段１１１によるＸＭＬ転送ファイルの電子署名は、帯域外情報（ＤＴＤ  ＩＤ、中央サーバＩＤ、及びデータベース２２１に対する帯域外情報の中央サーバ３１１署名）からの要求サイドアクセス手段の公開鍵に対して、検証される。ＸＭＬリクエストは、中央サーバ３１１からのエンドユーザ固有のＤＴＤに対して検証される。リクエストが無効である場合、エラーメッセージがアクセス手段１１１に返される。リクエストが有効である場合、情報提供サイドのユーザＩＤが復号化される。提供サイドのセッションがまだアクティブであったり、帯域外情報によって与えられるものとして継続していたりする場合、情報提供サイドユーザＩＤの復号化は不要である。なぜなら、セッションは復号化されたフォームの中でまだ生きているからである。ＸＭＬファイルは次いで、構文解析されてＸＭＬノードツリーにされ、ここで、情報提供アプリケーション２０１は、ＸＭＬノードツリーコンテナにＲＭＩ上のＤＴＤのＩＤである生成されたトランザクションＩＤを送信することにより、呼び出される。すべての新しいＤＴＤ  ＩＤは、情報提供サイドアクセス手段２１１によって、サーバがアクティブになるたびに汎用ＤＴＤに対して検証される。この汎用ＤＴＤは、情報提供アプリケーションが提供、又は設定「ｐｕｓｈ」の場合は修正、する準備のできている最大数のデータエレメントを示す。
【００４６】
特定のセッションにとって、そして、情報提供アプリケーション２０１との通信において、アクセス手段２１１は帯域外の生存期間（又は不活性期間）パラメータを使用する（Ｖ）。
【００４７】
情報提供アプリケーション２０１は、次いで、どの情報がＸＭＬノードツリーフォームから取得又は設定されるべきかを調べ、要求された情報で埋められたＸＭＬノードツリーと完了状態に関する情報を含む対応するアクセス手段２１１に応答を送信する。情報保持部２３から情報を取得して（ＶＩ）ＸＭＬノードツリーコンテナ中のそれぞれのアクセス手段２１１に返された後に、ＸＭＬノードツリーが情報提供アプリケーション２０１から返される。
【００４８】
情報提供アプリケーションアクセス手段２１１は、次いで、アプリケーション２０１から受信したＸＭＬノードツリーを、ＤＴＤ  ＩＤのための汎用ＸＳＬＴを伴うＸＭＬ転送ファイルに変換する。返答が、次いで、新たなＸＭＬ転送返答ファイルを伴ってＨＴＴＰＳ上で要求アプリケーション１０１のアクセス手段１１１に送信される（ＶＩＩＩ）。
【００４９】
ＶＩは、以下でさらに詳細に説明されるように、本発明のＳＱＬリクエストへの変換と、適切な位置／ノードに情報や応答を返すことに関する。
【００５０】
図５のフローチャートにおいて、データをリクエストして提供するためにどのようにＸＭＬフォームが使用されるかが概略的に示されている。本実施形態では、ＸＭＬのオブジェクトフォームが実装されている。
【００５１】
第１に（１００）、要求アプリケーションＡ４と提供アプリケーションＢ４の間の汎用取り決め（汎用ＤＴＤ）が、確立されるものとする。（もちろん、取り決めは既に利用可能で、より早い段階で確立されていてもよい。これはアプリケーションの機能とは関係がないが、本発明では、確立された取り決めが存在する。）。汎用取り決めを使用して、どの情報がＡ４とＢ４の間で交換を許可されるかを規定するＤＴＤ取り決めが生成される（１０１）。先行するステップにおいて、ＤＴＤ取り決め（ＤＴＤ  ＩＤ）は、既に利用可能とされていてもよい。なお、本発明のコンセプトは、いかなる取り決めの確立にも依存せず、これは単に特定の実施形態に関係するに過ぎないことが明らかになるであろう。
【００５２】
ＤＴＤ  ＩＤは、次いで、ＸＭＬフォームを生成するために使用され、ここで、フォームに含まれるクエリを表現する属性を伴うＸＭＬ  ＤＯＭノードツリーオブジェクトとして実装される（１０２）。
【００５３】
Ａ４で、以下でさらに説明するように、関係する属性に適切な値を与えることにより、フォームが埋められる（１０３）。続いて、ＸＭＬ  ＤＯＭノードツリーオブジェクト、すなわちオブジェクトフォーム中の埋められたフォームは、例えばＸＳＬＴ（ＸＳＬスタイルシート（拡張スタイルシート言語））を使用して、ＸＭＬ転送文字列に変換される（１０４）。タグ付けされたＸＭＬノードツリー（すなわち、その中で属性及びエレメントデータに例えば取得した値が与えられてタグ付けされている）は、ＸＭＬ転送文字列として、提供アプリケーションＢ４に送信される（１０５）。提供サイド、すなわちＢ４のサイドでは、ＸＭＬ  ＤＯＭパーサを使用して、ＸＭＬ転送文字列が構文解析され、ＸＭＬオブジェクトにされる（１０６）。提供サイドでは、ＸＭＬフォームのリクエストも、例えばＳＱＬフォーマット（構造化照会言語）のデータベースコールに変換される。データベースコールは、情報を保持する関連するデータベースに送信される（１０７）。データベースから、要求された情報がＢ４に返される（１０８）。取得された情報は、データベースからの情報に従って属性とエレメントデータに適切な値を与えることにより、ＸＭＬ  ＤＯＭノードツリー（フォーム）上で埋められる（１０９）。これは以下でさらに説明される。
【００５４】
続いて、ＸＭＬノードツリーオブジェクト（フォーム）が、例えば上述したＸＳＬＴを使用して、ＸＭＬ転送文字列に変換される（１１０）。ＸＭＬ転送文字列は、要求アプリケーションＡ４を含む要求サイドに返される（１１１）。
【００５５】
他の実施形態では、ＸＭＬフォームは、文字列として実装され、転送される。取り決めの確立とＤＴＤ取り決め（ＤＴＤ  ＩＤ）の生成（又はＤＴＤ取り決めの検索）に関するステップは、図５の１００と１０１に対応する。
【００５６】
ＤＴＤ取り決めはここで、フォームに含まれるクエリを表現する属性を伴う文字列として、ＸＭＬフォームを実装するために使用される。要求アプリケーションにおいて、フォームは、選択された／関係する属性に値を与える（割り当てる）ことによって埋められる（情報に関係する適切な値が要求される）。説明した方法でタグ付けされたＸＭＬツリーフォームは、（文字列として）提供アプリケーションに送信され、タグ付けされたＸＭＬ文字列の要求は、ＳＡＸパーサを使用してＳＱＬフォーマットのデータベースコールに変換される（ＳＡＸは、ＸＭＬに対するＳｉｍｐｌｅＡＰＩであり、図５を参照して説明したオブジェクトベースのＡＰＩとは対照的に、イベントベースのアプリケーションプログラミングインタフェースである）。ＳＱＬリクエストは、要求された情報を保持する関係するデータベースに送信される。情報がデータベースによって取得されると、それは、提供アプリケーションに転送され、それによって受信される。ＸＭＬフォームは、（ＳＡＸパーサを使用して）取得された情報に従う又は対応する適切な値を属性及びエレメントデータに与えることにより、要求された情報で埋められる。完成した、すなわち埋められたＸＭＬフォームは、次いで、ＸＭＬ文字列として要求アプリケーションに返される。
【００５７】
提供及び要求アプリケーションのうち少なくとも一方は、情報保持手段（ＤＢ）との通信において、種々のコンテンツを含む種々のデータベース構造に合わせてカスタマイズされる必要があり、これは上述したように問題である。
【００５８】
ＸＭＬフォーム文字列がＸＭＬ  ＤＯＭノードツリーに構文解析されたときに例えばＳＱＬステートメント／コマンドに対する変換が存在すると、特有の問題がさらに発生する。これは、属性値とノードエレメント名の組み合わせがＳＱＬステートメント／コマンドに変換されなければならないという事実のためである。ＸＭＬ文字列の実施形態において、すなわち、ＤＯＭノードツリーが実装されていないと、ＳＱＬステートメントへの変換も必要である。この場合、ＸＭＬ文字列において適切なエレメント（タグ）を探すステップが、データベースから取得された情報を文字列のどこに挿入するかを決定するために、必要である。この点において最も困難な問題は、ＸＭＬ  ＤＯＭノードツリー中の適切な位置に応答（すなわち、情報保持手段、例えばデータベースからの要求に対する応答）を返すことである。これは、以下のように解決される。
【００５９】
図６は、説明的な方法で、ＸＭＬ  ＤＯＭノードツリーとデータベースを示す。ＸＭＬ  ＤＯＭノードツリーは、従来の方法では、ルートノード、複数のエレメントノード、及び複数の属性ノードを含む。変換手段におけるＳＱＬステートメントへの変換のために、ポインタとしてＬＰ（ロケーションパス）のためのＸＰａｔｈを実装するＸＳＬＴが使用される。これがどのようになされるかについてのルールが、ＸＳＬＴにおいて生成される（ｉ）。ＸＭＬファイルの構造が知られている（例えば上で説明したようにＸＭＬ検証から）ということが前提条件であるが、属性及びエレメントの内容は知られていない。このことは、多数のＸＳＬＴスタイルシートが利用可能であり、ＤＴＤに依存して、その中の１つが選択されるということを意味する。
【００６０】
それゆえ、変換ステップの間に、ＸＳＬＴはＸＰａｔｈと共に使用される。変換結果は、変換された文字列又はロケーションパス情報を伴うターゲット文字列と、生成されたＳＱＬステートメントである。ＧＥＴ処理のために、ロケーションパス情報は、ＸＭＬ  ＤＯＭノードツリーにおいて情報保持手段（例えばデータベース）から取得された情報がどこに挿入されるべきかを示す。ＳＱＬステートメントは、情報保持手段（例えばデータベース）から情報をどのように取得するかを指定する。ＳＥＴ処理のために、ロケーションパス情報は、ＸＭＬ  ＤＯＭノードツリーにおいて情報保持手段に設定される情報がどこから取得されるべきかを示す。ＳＱＬは、情報保持手段において情報をどのように設定するかを指定する。
【００６１】
ＸＳＬＴ変換の間、絶対エレメント／ノードパス（すなわちロケーションパス情報）中の「ｇｅｔ」又は「ｓｅｔ」属性値とのマッチングは、ＸＰａｔｈシンタックスの手段によって実現される。ＸＰａｔｈは、適切なノードエレメントを見つけるために使用される。ノードエレメント中の適合した「ｇｅｔ」又は「ｓｅｔ」属性値によって、同一のターゲット文字列に含まれる汎用可変名（ユーザ名）をＳＱＬステートメント／コマンドに追加することが可能となる（ｉｉ）。
【００６２】
変換されて完成したターゲット文字列は、関連するエレメントノードへのパスのＸＰａｔｈシンタックスを含む。それゆえ、このパスによって、関与するエレメント／テキストノードに返されそして配置される応答データのためのナビゲーションが表されることになる。プログラムコードの関連する部分は、そこで、ＳＱＬステートメント／コマンドを使用し、汎用可変名を、帯域外情報として取得された現実の可変名に翻訳する。それゆえ、文書がＳＱＬに変換されると、変換された文書へのＪａｖａ（登録商標）クラスがデータベースに対してＪＤＢＣ上で使用される（ｉｉｉ）（ｉｖ）。それゆえ、すべての「タグ付けされた変数」は、実際の変数に交換されて置き換えられると、ターゲットの文字列ファイル上で１行ごとに処理するプログラムは、ＳＱＬコマンドとＬＰを「パスアウト」し、そしてＸＳＬＴ変換から結果として得られた文字列ファイルを処理する。
【００６３】
特に、置換タグが、ユーザのＩＤを規定するために使用される。ここでは、このユーザをユーザＢと呼ぶことにする。これは、ユーザＢのＩＤ置換タグ（汎用可変名）のために呼ばれる。上述したように、ユーザＢのＩＤは、ＩＤを置換タグ中で与えられたように置き換えることにより追加される。上述したように、これは、帯域外情報（ユーザＢのＩＤ）として取得される。続いて、ロケーションパスナビゲーションを実装することにより、ＸＭＬ  ＤＯＭノードツリーへの応答が返され（ｖ）、適切なノード（テキストノード）が、パスのＸＰａｔｈシンタックスを使用することにより発見されうる。
【００６４】
図７は、本発明のコンセプトを使用したＧＥＴ処理（例えば誰かの住所を取得する処理）のための手続きを示す。ここで、ＸＭＬフォームは、提供アプリケーション中で（上で使用された用語である要求アプリケーションから）受信されるものとする。提供アプリケーションは、情報保持手段、ここでは例えばデータベースなど、と通信するアプリケーションである。図中、Ａｄｄｒｅｓｓ＝「ｇｅｔ」は属性であり、ｇｅｔは引数であり、エレメントデータ（テキストノード）は＞と＜の間に挿入される。フォームが、ＸＭＬ  ＤＯＭパーサに提供され（ｉ’）、パーサはそれを、ルートや複数のエレメントノード、複数のテキストノード、複数の属性などを伴うＸＭＬ  ＤＯＭノードツリーへと構文解析する（ｉｉ'）。リクエストは、次いで、ＪＡＶＡ（登録商標）コードによって実行され、上で説明したＸＳＬＴ変換を実行する（ｉｉｉ’）。この目的のために、（ＤＴＤに依存する）適切なＸＳＬＴシートがＸＳＬＴシート格納手段から取得され、ＸＳＬＴ変換手段に提供される（ｉｖ’）。これから、ロケーションパス情報を伴うターゲット文字列と、汎用可変名（タグ）を伴うＳＱＬステートメントという結果が得られる（ｖ’）。これはまた、入力ターゲット文字列とも呼ばれる。
【００６５】
Ｊａｖａ（登録商標）クラスコードは、次に、（汎用可変名を伴う）入力ターゲット文字列を処理し、実際の可変名の「値」によって前記汎用可変名を置き換える（ｖｉ’）。実際の可変名は、帯域外データとして取得される（ｖｉｉ’）。これから、実際の可変名を伴う出力ターゲット文字列が得られる。（このことは、例えばユーザＢの置換タグが実際のユーザＢのＩＤによって置き換えられたことを意味する。）ＳＱＬステートメントは、次に、ＪＡＶＡ（登録商標）クラスプログラムコードを使用して実行され（ｖｉｉｉ’）、ＪＡＶＡ（登録商標）クラスプログラムコードは図中破線によって示される２つの部分を含み、１つはＳＱＬステートメントの実行のために真の実際の可変名伴うターゲット文字列を使用し（ｉｘ’）、もう１つは取得された情報がＸＭＬ  ＤＯＭノードツリー中のどこ（位置）に挿入されるべきかに関するロケーションパス情報を提供する。ロケーションパス情報は、次に、取得された情報を関連するノードに挿入するために使用される（ｘ’）。ＸＳＬＴ変換を介して、取得された情報（データ）は、次に、フォームに提供される（ｘｉ’）（ｘｉｉ’）。
【００６６】
図８は、図７に類似した図であるが、代わりに、本発明のコンセプトに従うＳＥＴ処理（例えば誰かの住所を設定する処理など）の手続きを示す。ここでは、ＸＭＬフォームが提供アプリケーションにおいて受信されるものとする（要求アプリケーションからであり、ＧＥＴ処理の対応する手続きを参照されたい）。提供アプリケーションはここでは、情報保持手段、例えばデータベースと通信するものとする。図８において、Ａｄｄｒｅｓｓ＝「ｓｅｔ」は、属性であり、ｓｅｔは引数であり、エレメントデータ（テキストノード）は＞と＜の間に＞ｄａｔａ＜として設定され、ｄａｔａは、テキストノードから取得され、データベースに例えば実際の住所を設定するデータである。ＧＥＴの場合のように、フォームがＸＭＬ  ＤＯＭパーサに提供され（ｉ’）、パーサはそれを、ルート、複数のエレメントノード、複数のテキストノード、複数の属性などを伴うＸＭＬ  ＤＯＭノードツリーに構文解析する（ｉｉ’）。リクエストは次に、上で説明したようにＪａｖａ（登録商標）コードによってＸＳＬＴ変換を実行するために処理される（ｉｉｉ’）。この目的のために、（ＤＴＤに依存する）適切なＸＳＬＴシートがＸＳＬＴシート格納手段から取得され、ＸＳＬＴ変換手段に提供される（ｉｖ’）。
【００６７】
変換により、ロケーションパス情報を伴うターゲット文字列と、汎用可変名（タグ）を伴うＳＱＬステートメントが提供される（ｖ’）。これは、入力ターゲット文字列と呼ばれる。
【００６８】
Ｊａｖａ（登録商標）クラスコードは、次に、（汎用可変名を伴う）前入力力ターゲット文字列を処理し、汎用可変名を実際の可変名に置き換える。これにより、実際の可変名（値）を伴う出力ターゲット文字列を得られる（ｖｉ’）。実際の可変名は、帯域外データとして取得される（ｖｉｉ’）。（このことは、例えばユーザＢ置換タグが実際のユーザＢのＩＤによって置き換えられたことを意味する。）設定されるデータは、ターゲット文字列からのロケーションパス情報を使用して、テキストノードから取得される。取得されたデータは、適切なタグ、例えばＶａｌｕｅＴｏＲｅｐｌａｃｅのＳＱＬステートメントに挿入される。適切なタグは、例えば、データが挿入されるＳＱＬ置換タグをＳＱＬステートメント中で探すことにより、発見されうる。
【００６９】
次に、ＳＱＬステートメントが、Ｊａｖａ（登録商標）クラスプログラムコードを使用して実行される（ｖｉｉｉ’）。このコードは、図８において破線で示される２つの部分を含み、１つは、ＳＱＬステートメントを実行するための真の、実際の可変名を伴うターゲット格納部を使用し（ｉｘ’）、もう１つは、ＸＭＬ  ＤＯＭノードツリー中のどこ（位置）にデータ（例えば結果）を挿入するべきかに関するロケーションパス情報を提供する。ロケーションパス情報が、次に、結果を関連するノードに挿入するために使用される（ｘ’）。結果は例えば実行された処理の結果に関し、例えば、成功した場合は「ＯＫ」である。ＸＳＬＴ変換の手段によって、次にこれは、フォームに提供される（ｘｉ’）（ｘｉｉ’）。
【００７０】
図９のフローチャートには、主要な機能ステップが示される。第１に、リクエスト（クエリ）はＸＭＬ  ＤＯＭノードツリーに含まれるものとする（図６参照）（２００）。
【００７１】
変換手段、例えば「提供」アプリケーションのコンポーネント、において、ＸＳＬＴファイル（適切な又は事前により十分に評価されて選択されたＸＳＬＴファイル）が、ＳＱＬステートメントを生成するために使用される。ＸＰａｔｈの使用を介して、ロケーションパス（ＬＰ）が確立される（２０１）。次いで、タグは実際の変数によって置き換えられる（２０２）。
【００７２】
続いて、生成されたＳＱＬステートメントが、情報保持手段、例えばデータベースに対して呼び出される（２０３）。返ってきた情報が（変換手段において）データベースから受信されると、ＬＰが、返答（応答）データ情報をＸＭＬ  ＤＯＭノードツリーの適切な（テキスト）ノード（すなわち、ＸＭＬ  ＤＯＭノードツリーの適切な位置）に提供するために使用される。
【００７３】
図１０は、図９に似たフローチャートであるが、少々より詳細にステップを示す。第１のステップ３００において、変換された文書ファイル／文字列を提供するために、ＤＯＭノードツリーからのクエリが発見され、ＸＳＬＴファイルを使用して変換が実行され、クエリへの複数のＸＰａｔｈ  ＬＰが発見される。特定の実施形態において、Ｊａｖａ（登録商標）クラスが、変換された文書のために呼び出される（図６、７も参照）。
【００７４】
次いで、タグは実際の変数によって置き換えられる（３０２）。Ｊａｖａ（登録商標）クラスは、次に、ＪＤＢＣによりＳＱＬステートメントを伴うデータベースを呼び出す（３０３）。
【００７５】
応答データは、次に、Ｊａｖａ（登録商標）クラスによって受信され、それはまた、応答データをロケーションパスに従うＸＭＬ  ＤＯＭノードツリーの適切な位置に返すために使用される（３０４）。
【００７６】
次に、変換されたＸＭＬ  ＤＯＭ文書が完成したかどうかが検査される（３０５）。もし完成したのであれば、処理は完了し、未完成であれば、ステップ３０３と３０４が、変換されたＤＯＭ文書が完成するまで繰り返される。次いで、処理が終了する（３０６）。
【００７７】
本発明によれば、データベースがどれであるかに関わらず、提供、要求どちらのアプリケーションも（それらは同一でもよい）、データベースの構造に適合される必要はなく、すべての必要なことは、他の又は新しいＸＳＬＴのプロビジョニング（発見）又は書き込みと、リクエストを伴うロケーションパス情報の使用である。これは著しい利点である。
【００７８】
それゆえ、いかなるハードコードされたリンクも、最初に述べたように、必要とされない。ロケーションパスは、例えばＸＭＬファイル間の変換のために使用されることは知られているが、本発明のような目的のために使用されることは知られていなかった。
【００７９】
以下に、アプリケーションにおいて先に説明したようなＸＭＬフォームの形態をしたリクエスト文の一例を示す。
【００８０】
「Ｇｅｔ」処理のためのＸＭＬフォームの例：
2006520941.tif 000003
（１）は、ＸＳＬＴによって発見されるデータクエリのためのタグである。
（２）は、挿入されるデータである。
ＸＳＬＴ変換ファイルを以下に示す：
ＸＳＬＴ変換ファイル
2006520941.tif 000004
（５）は、ＸＰａｔｈに適合するロケーションパス（ＬＰ）である。
ＸＳＬＴ変換ファイル（ＳＱＬセレクト）
2006520941.tif 000005
（３）は、セパレータ（＆＃１０）である。
（４）は、入力データがテキストパーサにおいて置き換えられることを示す。
以下に、「Ｓｅｔ」処理のためのＸＭＬフォームの例を示す。
2006520941.tif 000006
続いて、ＸＳＬＴ変換ファイルの続きである、ＸＳＬＴ変換ファイル（ＳＱＬアップデート）を示す。
ＸＳＬＴ変換ファイル（ＳＱＬアップデート）
2006520941.tif 000007
ＶａｌｕｅＴｏＲｅｐｌａｃｅ（１）と（２）は、それらが検索されるように選択されなければならず、ＸＭＬツリーからの情報は、そこに入力される。
【００８１】
ＸＭＬフォームとＸＳＬＴ変換ファイルのこれらの例は、単に説明的で例示的な目的のために与えられたことは明らかである。また、その他の点では、本発明はもちろん、具体的に示された実施形態に限定されず、むしろ、添付の請求項の範囲から逸脱しない限り、多くの方法で変形されうる。
【図面の簡単な説明】
【００８２】
【図１】アプリケーションを介して情報保持手段から情報を要求するシステムを極めて概略的に示す図である。
【図２】情報を保持する情報保持手段との通信のためのリクエストを変換する提供アプリケーションから、ＸＭＬを使用して情報を要求するアプリケーションを概略的に示す図である。
【図３】データを要求し、提供するために、ＸＭＬフォームが使用され、取り決め情報が外部に格納されている、他の実施形態を示す図である。
【図４】個人プロファイル保護ネットワークの手段によって検証が実行される実施形態を示す図である。
【図５】リクエストがＤＯＭノードツリーオブジェクトとして実装されるＸＭＬフォームを含む場合の、流れを示すフローチャートである。
【図６】リクエスト文書がＸＭＬ  ＤＯＭノードツリーとして実装される場合の発明のコンセプトを概略的に示すブロック図である。
【図７】情報保持手段から情報を取得する処理を少々より詳細に示す図である。
【図８】情報保持手段に情報を設定する処理を示す図である。
【図９】発明のコンセプトを実現するための主要な機能ステップを示す簡略化されたフローチャートである。
【図１０】発明のコンセプトの１つの実施形態を示すフローチャートである。
【図１】
2006520941.tif 000008
【図２】
2006520941.tif 000009
【図３】
2006520941.tif 000010
【図４】
2006520941.tif 000011
【図５】
2006520941.tif 000012
【図６】
2006520941.tif 000013
【図７】
2006520941.tif 000014
【図８】
2006520941.tif 000015
【図９】
2006520941.tif 000016
【図１０】
2006520941.tif 000017
【手続補正書】
【提出日】平成17年2月25日(2005.2.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
分散アプリケーション及びサービス／情報／コンテンツのプロバイダ又は情報保持手段を含む環境において、汎用マークアップ言語をサポートするプロトコルを用いる要求システムと情報保持手段との間の通信を提供するシステムであって、
分散アプリケーションは、前記汎用マークアップ言語ＸＭＬによるフォームを含む文書の形態をした、情報保持手段に対するリクエストを、前記リクエストを表現する前記汎用マークアップ言語による文書中の位置へのポインタと関連付けられた前記情報保持手段のアクセスのためのアクセスプロトコルを使用するアクセス要求に変換／コンバートする手段を含むか、又は、前記変換／コンバートする手段に関連付けられ、
前記情報保持手段アクセス要求は、前記情報保持手段への従来のクエリとして呼び出され、
前記情報保持手段の構造及び内容から独立して前記情報保持手段からデータが取得されるようにするために、前記変換／コンバート手段は、前記ポインタによって与えられ（示され）る、前記リクエストの文書中の適切な位置へ、前記情報保持手段のアクセス要求に関連する応答を返す
ことを特徴とするシステム。
【請求項２】
前記文書はＸＭＬ  ＤＯＭノードツリー文書を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＸＭＬの構造は前記変換手段に知られているが、前記ＤＯＭノードツリーの属性及び属性値の内容は知られていないことを特徴とする請求項２に記載のシステム。
【請求項４】
ＸＳＬＴ変換ファイルが、前記ポインタに接続され又は関連付けられる前記情報保持手段アクセスクエリを生成するために使用されることを特徴とする請求項３に記載のシステム。
【請求項５】
前記ポインタは、ＸＰａｔｈポインタすなわちＸＰａｔｈロケーションパスを含むことを特徴とする請求項４に記載のシステム。
【請求項６】
前記ポインタは、ＸＭＬ  ＤＯＭエレメント名を含むことを特徴とする請求項４又は５に記載のシステム。
【請求項７】
前記情報保持手段アクセス要求は、ＸＳＬＴファイル及びＸＰａｔｈロケーションパスを使用して生成され、
前記生成された情報保持手段アクセス要求の実行後、前記応答が、ロケーションパス（ＬＰ）ナビゲーションを使用して前記ＸＭＬ  ＤＯＭノードツリー中の前記適切な位置（ノード）に返される
ことを特徴とする請求項４、５、又は６に記載のシステム。
【請求項８】
前記要求は、ＸＭＬ転送文字列として情報要求アプリケーションから情報提供アプリケーションによって受信され、前記ＸＭＬ転送文字列は、前記情報保持手段との通信において前記提供サイドで、ＸＭＬ  ＤＯＭパーサを使用してＸＭＬオブジェクトに構文解析されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記要求は、タグ付けされたＸＭＬ転送文字列として情報要求アプリケーションから情報提供アプリケーションによって受信され、
前記タグ付けされたＸＭＬ文字列の前記要求は、情報保持手段のコールのために変換／コンバートされる
ことを特徴とする請求項７に記載のシステム。
【請求項１０】
同一の情報保持手段アクセス要求／クエリが、情報要求／回答のパフォーマンスを向上させるために、同一の情報保持手段、例えばデータベース、テーブルなど、の異なるデータエレメントに使用されることを特徴とする請求項７に記載のシステム。
【請求項１１】
前記システムはプライバシー保護ネットワークにおいて使用され、
前記ＸＭＬフォームは、ＸＭＬフォームとして前記情報提供サイドへ転送される例えばＤＴＤのような取り決めの情報を使用して前記要求ノードにおいて生成され、前記ＸＭＬフォームは、前記情報保持手段アクセス要求によって前記情報保持手段から前記データが取得された後に埋められ、前記提供アプリケーションの前記ＤＯＭノードツリー／文字列中の前記適切な位置に返される
ことを特徴とする請求項８に記載のシステム。
【請求項１２】
前記ＸＭＬ  ＤＯＭノードツリー文書は、前記変換手段に格納されるＤＴＤ又はスキーマに照らして検証されることを特徴とする請求項４乃至１１のいずれか１項に記載のシステム。
【請求項１３】
前記ＸＭＬ  ＤＯＭノードツリーは、ＤＴＤ  ＩＤによって与えられたものとして選択されたＸＳＬＴファイルを使用して変換され、
ＸＳＬＴ及びＸＰａｔｈ文字列／ファイルは、前記変換を提供するために実装される
ことを特徴とする請求項７乃至１１のいずれか１項に記載のシステム。
【請求項１４】
Ｊａｖａ（登録商標）が、前記情報保持手段アクセス要求／ステートメントを伴うＪＤＢＣ上で、前記情報保持手段を呼び出すために使用され、
前記データにアクセスする前記Ｊａｖａ（登録商標）クラスは、前記応答データを前記ＸＭＬ  ＤＯＭノードツリー中の関連するノードへ返すためにロケーションパスを使用する
ことを特徴とする請求項１２又は１３に記載のシステム。
【請求項１５】
ＸＰａｔｈシンタックスが、絶対ノードエレメントパスの「ｇｅｔ」又は「ｓｅｔ」属性値とのマッチングを提供するために使用され、
前記マッチした属性値を介して、汎用可変名が、同一の変換文字列又はターゲット文字列中の、情報保持手段アクセス要求ステートメント／コマンドに加えられうる
ことを特徴とする請求項１乃至１４のいずれか１項に記載のシステム。
【請求項１６】
ＳＱＬが、前記情報保持手段アクセス要求のために使用されることを特徴とする請求項１乃至１５のいずれか１項に記載のシステム。
【請求項１７】
ＬＤＡＰが、前記情報保持手段アクセス要求のために使用されることを特徴とする請求項１乃至１５のいずれか１項に記載のシステム。
【請求項１８】
汎用可変名は、プログラムコードによって、前記情報提供アプリケーションから受信された帯域外データから取得された実際の名前に翻訳されることを特徴とする請求項８乃至１５のいずれか１項に記載のシステム。
【請求項１９】
分散アプリケーションを含む環境において、汎用マークアップ言語をサポートするプロトコルを伴うシステムと情報保持手段との間の通信を提供する方法であって、
汎用マークアップ言語ＸＭＬによるフォームを含む要求文を、アプリケーションに含まれる又は関連付けられるコンバート／変換手段に提供する、又は、前記コンバート／変換手段で受信するステップと、
前記要求を、前記汎用マークアップ言語による前記ＸＭＬフォームを含む前記要求文中の適切な位置へのポインタに関連付けられた情報保持手段アクセスプロトコル／言語を使用して、情報保持手段アクセス要求に変換／コンバートし、前記要求を表現するステップと、
従来のクエリとして前記情報保持手段に対する前記情報保持手段アクセス要求を呼び出すステップと、
前記ポインタによって与えられる、前記要求文中の前記適切な位置へ、前記クエリに関連する応答データを返し、それにより情報データが前記情報保持手段の構造及び内容から独立して情報保持手段から取得され適切に割り当てられるようにするステップと、
を備えることを特徴とする方法。
【請求項２０】
前記要求文はＸＭＬ  ＤＯＭノードツリーを含み、前記ＸＭＬ  ＤＯＭノードツリーに対するエレメント及び属性の内容は未知である
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記変換／コンバートステップは、
ＸＳＬＴを発見／選択するステップと、
前記発見／選択されたＸＳＬＴを使用して前記変換を実行するステップと、
前記ＸＭＬ  ＤＯＭノードツリーの位置（例えばノードエレメント）を機能的に確立するためにポインタとしてＸＰａｔｈロケーションパスを使用するステップと、
ノードエレメントパスのＸＰａｔｈポインタ（シンタックス）を、応答情報データの返す位置（ノード）に関する情報を含むターゲット文字列を提供するために、前記情報保持手段アクセス要求に追加するステップと、
前記応答を、ＸＰａｔｈポインタを使用して前記ＸＭＬ  ＤＯＭノードツリーの関連する位置（ノード）へ返すステップと、
を備えることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記方法は、変換ステップの実行中に、
汎用可変名を提供するために、前記ＸＭＬ  ＤＯＭノードツリーの絶対ノードエレメントのパスに関連する「ｇｅｔ」又は「ｓｅｔ」属性値とマッチングするためのＸＰａｔｈを使用するステップと、
前記汎用可変名を、共通の（単一の）変換された文字列又はターゲット文字列を提供するために、前記情報保持手段アクセス要求に追加するステップと、
を備えることを特徴とする請求項２１に記載の方法。
【請求項２３】
さらに、
提供サイドのユーザＩＤのための置換タグとして前記汎用可変名を使用するステップと、
帯域外情報として前記提供サイドのＩＤを取得するステップと、
要求された情報を取得するために前記情報保持手段中の適切なレコードにアクセスするための帯域外情報として取得された実際のＩＤによって、前記置換タグの前記汎用可変名を置き換えるステップと、
返答（応答）データを前記ＸＭＬ  ＤＯＭノードツリー中の適切なノードへナビゲートするためにロケーションパス情報を使用するステップと、
を備えることを特徴とする請求項２２に記載の方法。
【請求項２４】
さらに、複数の情報保持手段アクセス要求ステートメント／コマンドを１つのアクセス要求ステートメント／コマンドに連結し、それによって、情報を要求し、要求された情報を取得する際のパフォーマンスを向上させるために、例えば格納アレイ中の格納手段に前記ＸＰａｔｈシンタックスを格納するステップを備えることを特徴とする請求項２１乃至２３のいずれか１項に記載の方法。
【請求項２５】
前記方法は、プライバシー保護ネットワークにおいて使用され、ＸＭＬフォームは、前記情報保持手段から前記情報を取得する提供アプリケーションを介して情報を要求するための要求アプリケーションサイド上で生成されることを特徴とする請求項１９乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記情報保持手段アクセス要求のために、ＳＱＬが使用され、ＳＱＬステートメント／コマンドを提供することを特徴とする請求項１９乃至２５のいずれか１項に記載の方法。
【請求項２７】
前記情報保持手段アクセス要求のためにＬＤＡＰが使用されることを特徴とする請求項１９乃至２５のいずれか１項に記載の方法。
【請求項２８】
前記情報保持手段は、データベース（ＤＢ）を含むことを特徴とする請求項１９乃至２７のいずれか１項に記載の方法。
【国際調査報告】
2006520941.tif 000018
2006520941.tif 000019
2006520941.tif 000020
2006520941.tif 000021
2006520941.tif 000022