JP3938047B2 - ディレクトリ品質保証のための装置、方法及びシステム - Google Patents

Description

［関連出願］
本出願では以下の米国特許仮出願に対して、ここに優先権を主張する。（１）２００１年１月２５日に申請された、シリアル番号６０／２６４，３３３の「ＤＯＩとのレファレンス・リンキング」（弁護士ドケット番号４１８８−４００１）、（２）２００１年２月１４日に申請された、シリアル番号６０／２６８，７６６の「情報アクセスを実行する多重解決（マルチプル・レゾリューション）のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００２）、（３）２００１年３月１６日に申請された、シリアル番号６０／２７６，４５９の「情報アクセスを実行する登録のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００３）、（４）２００１年３月２９日に申請された、シリアル番号６０／２７９，７９２の「ディレクトリの品質保証のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００４）、（５）２００１年７月１０日に申請された、シリアル番号６０／３０３，７６８の「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５）、（６）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７５の「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５ＵＳ１）、（７）２００１年２月８日に申請された、シリアル番号６０／２６７，８７５の「情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００６）、（８）２００１年２月９日に申請された、シリアル番号６０／２６７，８９９の「情報にアクセスするのための装置、方法及びシステムのための仮申請」（弁護士ドケット番号４１８８−４００７）、（９）２００１年２月２１日に申請された、シリアル番号６０／２７０，４７３の「ＤＯＩのためのビジネス・バリューと実施の考慮」（弁護士ドケット番号４１８８−４００８）、（１０）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７４の「ピア環境において情報アクセスを実行するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１０）、（１１）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７０の「情報アクセスを追跡するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１１）。これらの出願書はそれぞれ参照により開示に含まれる。
本出願書にはまた、以下の特許協力条約（ＰＣＴ）出願も参照により含まれる。（１２）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「情報アクセスを実行する多重解決のための装置、方法及びシステ厶」（弁護士ドケット番号４１８８−４００２ＰＣ）、（１３）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「情報アクセスを実行する登録のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００３ＰＣ）、（１４）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５ＰＣ１）、（１５）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「ピア環境において情報アクセスを実行するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１０ＰＣ）及び（１６）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「情報アクセスを追跡するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１１ＰＣ）。
本発明は一般に通信ネットワークを通して情報アクセスの有効化を確認するための装置、方法及びシステムに関するものである。より詳しくは、ここに開示する発明は通信ネットワーク上で使用される様々なコンテキストにおける永続的な識別子とその関連情報にアクセスし解決する能力を確認するための装置、方法及びシステムに関する。

［インターネット］
インターネットの利用が増えるにつれて、インターネット上で利用可能な情報の量も増加する。インターネット上に存在する情報は、コンピュータ・ソフトウェア、データベース、検討リスト、電子ジャーナル、ライブラリ・カタログ、オンライン情報サービス、メーリング・リスト、ニュース・グループ、ストリーミング・メディア等、数多くのフォーマットのドキュメントを含む様々な種類のものがある。幸いにもインターネット上のほとんどの情報には、ユーザーが利用しやすい方法でネットワークとインタラクションするためのウェブ・ブラウザを用いワールド・ワイド・ウェブを介してアクセスすることができる。
［ネットワーク］
一般にネットワークは、クライアント、サーバー及びグラフ・トポロジーにおける中間のノードの相互接続と相互運用から成ると考えられている。注意すべきことは、ここでは「サーバー」という用語は通常、通信ネットワーク全体の遠隔ユーザーのリクエストを処理したりそれに応答したりするためのコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせを指すということである。サーバーはリクエストしてくる「クライアント」に情報を提供する。情報やリクエストを可能にしたり、処理、及び／またはソース・ユーザーからデスティネーション・ユーザーへの情報の流れを支援するコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせは、通常「ノード」と呼ばれる。ネットワークは一般的にソース・ポイントからデスティネーションへの情報の転送を可能にするものと考えられている。
［伝送制御プロトコルとインターネット・プロトコル（ＴＣＰ／ＩＰ）］
コンピュータ・システム、データベース及びコンピュータ・ネットワークの拡散と拡大は、一般的にインターネットと称されるそのようなシステムの相互接続と国境を越えた通信ネットワークによって促進されてきた。インターネットは伝送制御プロトコルとインターネット・プロトコル（ＴＣＰ／ＩＰ）を発展させ、またその大部分においてそれらを用いている。ＴＣＰ／ＩＰは様々な変化するネットワーク業者によって形成された複数のネットワークを、ネットワークのネットワークのための基礎として相互接続するための、つまりインターネットのための米国国防総省（ＤｏＤ）の研究プロジェクトによって開発された。一つにはＤｏＤが、戦闘の最中に損害を受けても作動し続けることによって、通信ネットワークの損害を受けた部分を回避してデスティネーション・アドレスに情報を送るネットワークを必要としたことがＴＣＰ／ＩＰの開発の原動力となった。もちろん、ソース・アドレスのロケーションまたはデスティネーション・アドレスのロケーション自体が動作不能になった場合は、そのような伝達は不可能である。
インターネットはパケット交換型のネットワークであるため、インターネット上の情報はパケットと呼ばれる幾つもの断片に分割され、パケット形式で送信される。パケットはヘッダーと呼ばれるＩＰアドレス情報を含み、それらはルータがインターネット上の中間ノードを通してパケットをソースからデスティネーションへ配信することを可能にする。デスティネーションに到着すると、パケットは再構築されオリジナルのメッセージを形成し、欠落しているパケットがあれば、それらは再びリクエストされる。
プロトコルのＩＰ部分は、４バイトのアドレス・メカニズムに基づいて情報パケットをルーティングする役目を担う。アドレスはドットによって分離された４つの数字であり、各数字は０から２５５の範囲内で、例えば、「１２３．２５５．０．１２３」というようになる。ＩＰアドレスはインターネット当局及び登録機関が指定し、それぞれ固有のものである。
プロトコルのＴＣＰ部分は情報のパケットがソースからデスティネーションに正確に受信されたかを確認し、またもし正確に受信されなかった場合は、間違ったパケットを再送信するために用いられる。ユーザー・データグラム・プロトコル（ＵＤＰ）等の、配信を保証しないその他の伝送制御プロトコルも一般的に利用されている。
［ワールド・ワイド・ウェブ］
インターネット、特にワールド・ワイド・ウェブ（ウェブ）が広く受け入れられ拡大し、膨大且つ多様な情報が集めらた。情報技術システムを有するユーザー同士（つまりコンピュータ利用者）のインタラクションを可能にする様々なユーザー・インターフェースが現在利用されている。ＷｏｒｌｄＷｉｄｅＷｅｂ．ａｐｐ（ウェブ）と呼ばれる情報ナビゲーション・インターフェースは、１９９０年後半に開発された。その後、ウェブ・ブラウザ等の情報ナビゲーション・インターフェースがほぼ全てのコンピュータ・オペレーティング・システム・プラットフォームにおいて広く利用可能になった。
一般的にウェブは、複数のユーザー・インターフェース（例えばウェブ・ブラウザ）、サーバー、配信された情報、プロトコル及び仕様の、相乗相互運用の発現でありその結果である。ウェブ・ブラウザは情報へのナビゲーションとアクセスを促進するために設計され、一方情報サーバーは情報の供給を促進するために設計されている。通常ウェブ・ブラウザと情報サーバーは通信ネットワークを介してお互いに交信するように配置してある。情報サーバーは、通常ウェブ・ブラウザを用いて情報にアクセスするユーザーに対し情報を提供する機能を果たす。従って、情報サーバーは主にウェブ上の情報へのナビゲーションやアクセスにウェブ・ブラウザを用いるユーザーに対し情報を提供する。ウェブ・ブラウザの例としては、マイクロソフト社のインターネット・エクスプローラや、ネットスケープ・ナビゲーターがある。加えて、ウェブＴＶのようなナビゲーション・ユーザー・インターフェース機器もウェブ・ナビゲーションを容易にするために実現されている。マイクロソフト社のインフォメーション・サーバーやアパッチが情報サーバーの例として挙げられる。
［ユニバーサル・リソース・ロケーター（ＵＲＬ）］
ウェブの拡大は膨大な量の情報をもたらし、かかる膨大な情報はユニバーサル・リソース・ロケーター（ＵＲＬ）を利用することによりアクセス可能である。ＵＲＬとは通常ウェブ・ページ中にハイパーリンクとして組み入れられるアドレス、あるいはウェブ・ブラウザにタイプ入力されるアドレスである。所与のリソース（最も一般的には遠隔コンピュータ上にあるファイル）のＵＲＬはそのリソースのみを指す。一般的に、当該場所へのレファレンスは、例えば「ｈｔｔｐ：／／ｗｗｗ．ａＷｅｂＳｉｔｅ．ｃｏｍ／ａＦｏｌｄｅｒ／ａＦｉｌｅ／ａＦｉｌｅ．ｈｔｍｌ」というように、ディレクトリ・パス及びファイル名と併せて未解決のＩＰアドレスを用いて達成される。この例では、このＵＲＬが「ａＷｅｂＳｉｔｅ．ｃｏｍ」というドメインの「ｗｗｗ」という名前のコンピュータに接続し、そのコンピュータの「ａＦｏｌｄｅｒ」というディレクトリに保存されている「ａＦｉｌｅ．ｈｔｍｌ」という名前のファイルをリクエストするように、ブラウザに命じることになる。
［ユニバーサル・ネーム識別子（ＵＮＩ）］
Ｔｈｅ Ｃｏｒｐｏｒａｔｉｏｎ ｆｏｒ Ｎａｔｉｏｎａｌ Ｒｅｓｅａｒｃｈ Ｉｎｉｔｉａｔｉｖｅは、情報の名前と所在を指定するハンドル・システムと呼ばれる新しい手段を創り出し実施した。ハンドル・システムは現在のＵＲＬの利用状況を改善するために設計された。
ハンドル・システムは、インターネット上で情報の所在を確認したり情報を配信するための間接指定のレベルを導入する。ハンドル・システムは、リソースに名前を付けるための汎用システムである。特定のリソースの現在の場所に基づくＵＲＬを指定する代わりに、リソースにユニバーサル・ネーム識別子を指定する。ＵＮＩはユニバーサル・リソース識別子（ＵＲＩ）の一形式である。ＵＲＩはＵＮＩとＵＲＬの両方を含む。ＵＮＩはＵＲＬと違い、リソースの場所やその他の属性の変化に関わらず永続的なリソースの名前として機能し、またこれ以降そのような名前であるものとみなす。言い換えると、ユニバーサル・リソース・ネーム（ＵＲＮ）はＵＮＩの一種である（即ち、ＵＮＩはＵＲＮの概念を含む）。更に、ハンドルとはＵＲＮの一種である。またデジタル・オブジェクト識別子（ＤＯＩ）はハンドルの一種である。従って、ハンドル、ＵＲＮ、ＤＯＩ及び／またはその他が様々な形式のＵＮＩに含まれる。ＵＮＩの様々な用語及び／または形式は、本文全体にわたって置換可能なように用いられ、特に明記しない限り置換可能と想定してよいものとする。ハンドルは、名付けられたリソースの現在のネットワーク上の場所と共にハンドル・システムに登録される固有の名前である。この場所に関する情報は通常ＵＲＬの形式をとる。一般的なハンドルの種類の一つとしてデジタル・オブジェクト識別子（ＤＯＩ）が知られている。その場合ハンドルはＵＲＬの代わりにユーザーに配信され、表面上はハイパーリンクと同様に機能するかに見える。ユーザーがハンドルに遭遇すると、ユーザーのブラウザにハンドル・リクエストを行う作成する機能がある限りは、ユーザーはＵＲＬハイパーリンクを選択したり入力したりするのと同様にハンドルを選択したり入力したりする。そのような遭遇により、リソースの現在の場所を検索する自動のプロセスが始動する。リソースの現在の場所は、ハンドル・システムが提供するディレクトリの中のリソースのハンドルに関連付けられていて、ユーザーをリソースの現在の場所へと導く。ＵＲＬとは違い、リソースが移動した場合、ハンドル・システムのディレクトリのエントリーは更新可能なので、ハンドルと、ハンドルが特定するリソースとの永続的な関連付けが確保される。これを現実の世界に喩えるならば、所与のリソースのＵＲＬのみを知っているということは、ある人の住所だけ知っていて名前は知らないようなものである。もしその人が街の反対側へ引っ越した場合、名前を知らなければ探すのは非常に困難になる。ハンドル・システムにより、ハンドルを用いてリソースに永続的な名前を付けることができ、ハンドル・システム・ディレクトリの中のリソースの名前に基づいて、リソースの現在の場所を検索することができる。

デジタル・オブジェクト識別子はＩＰ及び他の場所に基づくアドレス方式の欠点の多くを克服するものである。ＤＯＩは頻繁に移動する可能性のある情報に永続的な識別子を与え、通信ネットワーク上の情報にアクセスすることを可能にする。ＤＯＩは、識別子を場所と関連付けるのではなく、更なるレベルの間接指定を加えて識別子を情報と関連付けるメカニズムを設けることによって、場所をアドレスで指定することに限定されたネットワーク・アドレス方式の限界を克服する。
ＤＯＩは、識別子を場所ではなく情報と関連付けることを可能にするメカニズムを提供するが、ＤＯＩ自体は、様々な場所、様々なフォーマットの情報の多重及び／または様々なインスタンスのアクセス、あるいは様々な使用コンテキストに基づいて、所与の情報に関連する様々なサービスへのアクセスを提供するものではない。さらに、本発明が成されるまで、例えばＤＯＩといったそのような識別子が適当な関連情報へのリクエストを適切に解決することの有効性を確認するメカニズムは存在していなかった。
一実施例において、本開示は、ソースのための固有で永続的なユニバーサル・ネー厶識別子を一つ得ることと、該固有で永続的なユニバーサル・ネーム識別子を持つ解決のためのソースの場所アドレスを得ることと、該場所アドレスへアクセス可能であることの有効性を確かめることと、から成る、コンピュータを用いて有効性を確認する方法を教示している。
別の実施例において、本開示は、タギング・コードを決定し、該タギング・コードが一旦認識された際は、ソースの有効性を確立することと、該タギング・コードでソースを一つタグ付けし、該ソースへと一つの固有で永続的なユニバーサル・ネーム識別子によって解決されることと、から成る、コンピュータを用いて有効性を確認する方法を教示している。
別の実施例において、本開示は、タギング・コードを決定し、該タギング・コードが一旦認識された際は、ソースの有効性を確立することと、該タギング・コードでソースを一つタグ付けすることと、該ソースと関連する固有で永続的なユニバーサル・ネーム識別子を一つ生成することと、該ソースのための場所のアドレスを一つ受信することと、、該ソースの場所と関連した該アドレスを持つ該固有で永続的なユニバーサル・ネーム識別子の、関連したソースの固有で永続的なユニバーサル・ネーム識別子と関連したソースの場所を解決するための一つのデータベースへの登録を実行し、該固有で永続的なユニバーサル・ネーム識別子が、該データベースにて固有であることと、から成る、コンピュータを用いて情報にアクセスする方法を教示している。
別の実施例において、本開示は、タギング・コードを決定し、該タギング・コードが一旦認識された際は、ソースの有効性を確立することと、該タギング・コードでソースを一つタグ付けすることと、該ソースのための記憶ファシリティ内にスペースを割り当てることと、通信ネットワーク上で該割り当てられたスペースの場所をアドレス可能でアクセス可能にすることと、該ソースを該割り当てられたスペースへ保存することと、該ソースと関連する固有で永続的なユニバーサル・ネーム識別子を一つ生成することと、該ソースが保存されている該場所と関連した一つのアドレスを持つ該固有で永続的なユニバーサル・ネーム識別子の、関連したソースの固有で永続的なユニバーサル・ネーム識別子と関連したソースの場所を解決するための一つのデータベースへの登録を実行し、該固有で永続的なユニバーサル・ネーム識別子が該データベースにて固有であることと、から成る、コンピュータを用いて情報にアクセスする方法を教示している。
上記の効果と特徴は代表的な例のみであって、全てのものを示すものでもなく、その他に無いということでもない。これらは本発明の理解の助けとなるように示したに過ぎない。これらは請求項が定義する発明の全てを代表するものではなく、請求項が定義する発明を限定することや、請求項と同等のものを限定することはない旨、理解されるべきである。例えばこれらの効果のうちの幾つかは、同時に一つの実施例中には存在し得ないという点で、お互いに矛盾している。同様に、これらの効果のうちの幾つかは、本発明の一つの特徴には当てはまるものの、他の特徴には当てはまらない。更に、請求項にある本発明にはここには記載していない特徴もある。しかしながら、紙面の節約と繰り返しを減らすという目的で記述しなかったということ以外で、ここに記載する内容と記述していないものとの関係について、これといった推論を引き出すべきではない。かくして、かかる特徴と効果の要約は、どの様なものを同等なものとするかを決定するものと考えるべきではない。本発明のその他の特徴と効果については以下の記述、図及び請求項から明確になる。
添付した図面は本開示の幾つかの実施例を図示するものである。

ディレクトリ品質保証サーバー（ＤＱＡＳ）コントローラに組み込まれた一実施例を図示している。 移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを図示している。 移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを図示している。 ＤＯＩを介した情報へのアクセスを図示している。 ハンドルの概要を示している。 ハンドルの概要を示している。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示している。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示している。 ユーザーがＤＯＩを用いて情報をアクセスするために行う典型的な一連のアクションの概要を示している。 ユーザーがＤＯＩを用いて情報の内容をアクセスするために行う典型的な一連のアクションのより完全な概要を示している。 通信ネットワーク上で情報をアクセスするための典型的なメカニズムを図示している。 通信ネットワーク上で情報を入手するための典型的なメカニズムの別の実施例の概要を図示している。 典型的なＤＯＩシステムの概要を示している。 様々なエンティティとインタラクションするディレクトリ品質保証サーバー（ＤＱＡＳ）の非限定的な一例を図示している。 様々なエンティティとインタラクションするＤＱＡＳの非限定的な例を図示している。 様々なエンティティとインタラクションするＤＱＡＳの非限定的な例を図示している。 ハンドルの有効性を確認する際に、様々なエンティティとインタラクションするＤＱＡＳの非限定的な例を図示している。 フィーダーとデータ・フローの非限定的な例の概要を図示している。 品質保証ＵＮＩデータ・マイナー・ファシリティ（マイナー）の非限定的な一例のフロー・ダイヤグラムを図示している。 品質保証エンキュー・フィーダー（ＮＱフィーダー）の非限定的な一例のフロー・ダイヤグラムを図示している。 品質保証デキュー・フィーダー（ＤＱフィーダー）の非限定的な一例のフロー・ダイヤグラムを図示している。 ディレクトリ品質保証ピンガー・ファシリティ（ピンガー）の非限定的な一例のフロー・ダイヤグラムを図示している。 品質保証エラー・プロセッサ（エラー・プロセッサ）の非限定的な一例のフロー・ダイヤグラムを図示している。 品質保証エラー・レポート・ポリシー（ポリシー）の非限定的な一例のフロー・ダイヤグラムを図示している。 ポリシー・マネジャー・ツールの非限定的な一例を図示している。

［ディレクトリ品質保証サーバー・コントローラ］
図１は、ディレクトリ品質保証サーバー（ＤＱＡＳ）コントローラ１０１に取り入れられた一実施例を図示している。この実施例では、ＤＱＡＳコントローラ１０１はハンドル、任意の関連した情報の登録、解決、処理、更新、有効性の確認及び／またはその他の役割を担う。
一実施例において、ＤＱＡＳコントローラ１０１は、ユーザー入力デバイス１１１、周辺デバイス１１２及び／または通信ネットワーク１１３からの一人以上のユーザー等のエンティティと、接続及び／または通信することができるが、エンティティはこれらに限定されるものではない。当該ＤＱＡＳコントローラは、暗号プロセッサ・デバイス１２８とさえも接続及び／または通信することが可能である。
典型的なＤＱＡＳコントローラ１０１は、メモリ１２９に接続されたコンピュータの系統的システム１０２等の部品から成る一般的なコンピュータ・システムに基づくものであるが、部品はこれに限定されるものではない。
［コンピュータの系統的システム］
コンピュータの系統的システム１０２はクロック１３０、中央演算処理装置（ＣＰＵ）１０３、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）及び／またはインターフェース・バス１０７から成り、従来は、必ずしもというわけではないが、全てシステム・バス１０４を介して相互接続及び／または交信している。システム・クロックは通常水晶発振器を有し、基本信号を供給する。クロックは通常システム・バス及びコンピュータの系統的システ厶に取り入れられた他の部品の基本動作周波数を増加させたり減少させたりする様々な手段に結合している。クロック及びコンピュータの系統的システムの様々な部品は、システム内全てにおいて情報を具現する信号を駆動する。コンピュータの系統的システム内において情報を具現する信号のこのような送信及び受信は、通常、通信と呼んでいる。これらの通信に関する信号は、更に、本コンピュータの系統的システムを超え通信ネットワーク、入力機器、他のコンピュータの系統的システム、周辺機器及び／またはその他へ、送信、受信してもよく、返信信号及び／または応答信号を生じさせてもよい。オプションとして、暗号プロセッサ１２６を同様にシステム・バスに接続することもできる。もちろん、上記の部品の何れもお互いに直接接続したり、ＣＰＵに接続したり及び／または様々なコンピュータ・システムにより具現されるような数多くのバリエーションで組織化したりしてもよい。
ＣＰＵはユーザー及び／またはシステムにより出されたリクエストを実行するためのプログラム・モジュールの実行に適した少なくとも一つの高速データ・プロセッサから成る。ＣＰＵはインテル社のペンティアム・プロセッサ及び／またはその他のようなマイクロプロセッサでもよい。従来のデータ処理技術により、ＣＰＵは導電性の経路を介して送信される信号を介してメモリと交信し、保存されているプログラム・コードを実行する。そのような信号送信は、様々なインターフェースを通じてＤＱＡＳコントローラ内の通信及び様々なインターフェース域を越える通信を可能にする。
［インターフェース・アダプター］
インターフェース・バス１０７は数多くのインターフェース・アダプターを受け入れ接続し、及び／または通信し、必ずしもアダプター・カードの形である必要はないが、従来その例として、入出力インターフェース（Ｉ／Ｏ）１０８、記憶インターフェース１０９、ネットワーク・インターフェース１１０及び／またはその他があるが、それらに限定されるわけではない。オプションとして、暗号プロセッサ・インターフェース１２７も同様に、任意にインターフェース・バスに接続してもよい。インターフェース・バスは、インターフェース・アダプター同士の通信を提供すると共に、コンピュータの系統的システムにおける他の部品への通信を提供する。インターフェース・アダプターは、コンパチブル・インターフェース・バスに適応している。インターフェース・アダプターは従来、スロット・アーキテクチャーを通じてインターフェース・バスに接続する。アクセラレイテッド・グラフィックス・ポート（ＡＧＰ）、カード・バス（拡張）、業界標準アーキテクチャ（（Ｅ）ＩＳＡ）、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）、Ｎｕバス、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）、ＰＣメモリ・カード国際協会（ＰＣＭＣＩＡ）及び／またはその他の、従来のスロット・アーキテクチャーを用いればよいが、これらに限定されるわけではない。
記憶インターフェース１０９は、例えば記憶装置１１４、リムーバブル・ディスク・デバイス及び／またはその他といった数多くの記憶装置を受け入れ通信し、及び／または接続するが、記憶装置はそれらに限定されるわけではない。記憶インターフェースは、例えば（ウルトラ）アドバンスト・テクノロジー・アタッチメント（パケット・インターフェース）（（ウルトラ）ＡＴＡ（ＰＩ））、（拡張）インテグレイテッド・ドライブ・エレクトロニクス（（Ｅ）ＩＤＥ）、電気電子技術者協会（ＩＥＥＥ）１３９４、ファイバー・チャネル、小型コンピュータ用周辺機器インターフェース（ＳＣＳＩ）、ユニバーサル・シリアル・バス（ＵＳＢ）及び／またはその他といった接続プロトコルを用いるが、これらに限定されるわけではない。
ネットワーク・インターフェース１１０は、通信ネットワーク１１３を受け入れ通信し、及び／または、接続する。ネットワーク・インターフェースは、例えば直接接続、イーサネット（厚型、薄型、ねじれペア１０／１００／１０００ベースＴ及び／またはその他）、トークン・リング、ＩＥＥＥ８０２．１１ｂ等のワイヤレス接続、及び／またはその他といった接続プロトコルを用いるが、これらに限定されるわけではない。通信ネットワークは、以下に挙げるものの一つ及び／またはそれらの組み合わせである。即ち、ダイレクト・インターコネクション、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、インターネット上のノードとしてのオペレーティング・ミッション（ＯＭＮＩ）、安全なカスタム・コネクション、ワイド・エリア・ネットワーク（ＷＡＮ）、ワイヤレス・ネットワーク（例えば、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）、Ｉモード及び／またはその他等のプロトコルを用いるが、これに限定されるわけではない）及び／またはその他である。ネットワーク・インターフェースは、入出力インターフェースの特別な形態であると見なされる。
入出力インターフェース（Ｉ／Ｏ）１０８は、ユーザー入力デバイス１１１、周辺機器１１２、暗号プロセッサ・デバイス１２８及び／またはその他を受け入れ通信し、及び／または接続する。Ｉ／Ｏは、例えばアップル・デスクトップ・バス（ＡＤＢ）、アップル・デスクトップ・コネクター（ＡＤＣ）、アナログ、デジタル、モノラル、ＲＣＡ、ステレオ、及び／またはその他のオーディオ、ＩＥＥＥ１３９４、インフラレッド、ジョイスティック、キーボード、ミディ、オプティカル、ＰＣ ＡＴ、ＲＳ／２、パラレル、ラジオ、シリアル、ＵＳＢ、それからＢＮＣ、コンポジット、デジタル、ＲＣＡ、Ｓビデオ、ＶＧＡ、及び／またはその他のビデオ・インターフェース、ワイヤレス及び／またはその他といった接続プロトコルを用いるが、それらに限定されるわけではない。一般的な出力デバイスはビデオ・ディスプレイであり、通常、ビデオ・インターフェースから信号を受け取るインターフェース（例えば、ＶＧＡ回路やケーブル）を有するＣＲＴモニターかＬＣＤモニターから成る。ビデオ・インターフェースは、コンピュータの系統的システムが生み出した情報を合成し、合成された情報に基づいたビデオ信号を生成する。通常、ビデオ・インターフェースは、ビデオ・コネクション・インターフェースを通じて合成されたビデオ情報を提供し、ビデオ・コネクション・インターフェースはビデオ・ディスプレイ・インターフェース（例えば、ＶＧＡディスプレイ・ケーブルを受け入れるＶＧＡコネクター等）を受け入れる。
ユーザー入力デバイス１１１は、カード読み取り装置、ドングル、指紋読み取り装置、手袋、グラフィック・パッド、ジョイスティック、キーボード、マウス（マイス）、トラックボール、トラックパッド、網膜読み取り装置、及び／またはその他といったものである。
周辺機器１１２はＩ／Ｏに、及び／またはネットワーク・インターフェース、記憶インターフェース及び／またはその他といった他のファシリティに接続し、及び／またはそれらと通信したり、またはそれらと交信したりする。周辺機器とは、カメラ、（コピーの防止、デジタル署名としてトランザクションの安全性強化、及び／またはその他のための）ドングル、（追加的な機能としての）外付けプロセッサ、ゴーグル、マイクロフォン、モニター、ネットワーク・インターフェース、プリンター、スキャナー、記憶装置、バイザー及び／またはその他といったものである。
例えばマイクロコントローラ、プロセッサ１２６、インターフェース１２７及び／またはデバイス１２８のような暗号ユニットをＤＱＡＳコントローラに付け、及び／または通信してもよいが、暗号ユニットはこれらに限定されるわけではない。通常モトローラ社製であるＭＣ６８ＨＣ１６マイクロコントローラは暗号ユニットとして使用してもよいし、及び／または暗号ユニット内にあってもよい。同等のマイクロコントローラ及び／またはプロセッサを使用してもよい。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚの設定において１６ビットの積算加算インストラクションを活用し、５１２ビットのＲＳＡ秘密鍵機能を実行するために１秒以下しか必要としない。暗号ユニットは交信エージェントからの通信の認証をサポートすると共に、匿名のトランザクションを可能にする。暗号ユニットはまた、ＣＰＵの一部として設定されていてもよい。他に市販されている専門の暗号プロセッサとしては、ＶＬＳＩテクノロジー社の３３ＭＨｚ６８６８や、セマフォ・コミュニケーション社の４０ＭＨｚのロードランナー２８４がある。
［メモリ］
記憶装置１１４は、従来のコンピュータ・システムの記憶装置ならばどれであってもい。記憶装置は、固定ハード・ディスク・ドライブ及び／またはその他の装置でよい。しかしながら、ＤＱＡＳコントローラ及び／またはコンピュータの系統的システムは、様々な形態のメモリ１２９を用い得ることは理解されるものである。例えば、コンピュータの系統的システムは、チップ内のＣＰＵメモリ（例えば、レジスタ）、ＲＡＭ、ＲＯＭ、他の記憶装置の機能がパンチ・テープまたは、パンチ・カード・メカニズムによって与えられるように構成されてもよい。もちろん、そのような実施例は好まれるものではなく、動作が極端に遅くなる結果となる。一般的な構成では、メモリ１２９は、ＲＯＭ、ＲＡＭ、記憶装置１１４を含む。通常、プロセッサが情報の記憶及び／または情報の取り出しを実行することを可能にする機械化及び／または実施化は、メモリ１２９と見なされる。それゆえ、コンピュータの系統的システムは一般にメモリを必要とし、メモリを使用する。しかしながら、メモリは、代替可能な技術及びリソースであり、それゆえメモリは任意の数の実施例を代替として利用したり、一緒に利用したりできる。
［モジュール・コレクション］
記憶装置１１４は、プログラム・モジュール及び／またはデータベース・モジュール及び／またはデータといったもののコレクションを含む。それらの例には、オペレーティング・システ厶・モジュール１１５（オペレーティング・システム）、情報サーバー・モジュール１１６（情報サーバー）、ユーザー・インターフェース・モジュール１１７（ユーザー・インターフェース）、ウェブ・ブラウザ・モジュール１１８（ウェブ・ブラウザ）、データベース１１９、暗号サーバー・モジュール１２０（暗号サーバー）、ディレクトリ品質保証サーヴバー（ＤＱＡＳ）モジュール１２５、及び／またはその他（つまり、全体としてモジュール・コレクション）といったものがあるが、それらに限定されるわけではない。これらモジュールは記憶され、記憶装置及び／またはインターフェース・バスを通じてアクセス可能な記憶装置からアクセスできる。モジュール・コレクションにあるような非従来的なソフトウェア・モジュールは一般的に、かつ望ましくはローカル記憶装置１１４に記憶されるが、例えば周辺機器、ＲＡＭ、通信ネットワークを通じた遠隔記憶ファシリティ、ＲＯＭ、様々な形態のメモリ及び／またはその他といったメモリに取り込み及び／または記憶してもよい。
［オペレーティング・システム］
オペレーティング・システム・モジュール１１５は、ＤＱＡＳコントローラの動作を可能にする実行可能なプログラム・コードである。一般的に、オペレーティング・システムは、Ｉ／Ｏ、ネットワーク・インターフェース、周辺機器、記憶装置、及び／またはその他のアクセスを可能にする。オペレーティング・システムは、アップル・マッキントッシュＯＳ Ｘサーバー、ＡＴ＆Ｔプラン９、マイクロソフト・ウィンドウズＮＴサーバー、ユニックス及び／またはその他のオペレーティング・システムのような従来型の製品が好ましい。好ましくは、オペレーティング・システムは、非常にフォールト・トレラントであり、拡張可能かつ安全であるのがよい。オペレーティング・システムは、モジュール・コレクション内のそのモジュール自体及び／またはその他のファシリティを含む他のモジュールと通信したり、及び／または交信したりする。従来オペレーティング・システムは、他のプログラ厶・モジュールやユーザー・インターフェース及び／またはその他と通信する。例えば、オペレーティング・システムは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト及び／またはレスポンスを含み、通信、生成、入手及び／または提供する。オペレーティング・システムは一度ＣＰＵによって実行されると、通信ネットワーク、データ、Ｉ／Ｏ、周辺機器、プログラム・モジュール、メモリ、ユーザー入力デバイス及び／またはその他とインタラクションすることが可能になる。好ましくはオペレーティング・システムは、通信ネットワーク１１３を通じて、ＤＱＡＳコントローラが他のエンティティと通信できるようにする通信プロトコルを提供する。ハンドル・システムとインタラクションするためのサブキャリア・トランスポート機構として様々な通信プロトコルが、ＤＱＡＳコントローラによって使用される。通信プロトコルとしては例えばマルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト及び／またはその他といったものがあるが、これらに限定されるわけではない。
［情報サーバー］
情報サーバー・モジュール１１６は、記憶されたプログラム・コードであり、ＣＰＵにより実行される。情報サーバーは、マイクロソフト社のインターネット・インフォメーション・サーバー及び／またはアパッチ・ソフトウェア・ファンデーションのアパッチ等、従来のインターネット情報サーバーでよいが、それらに限定されるわけではない。好ましくは、情報サーバーはＣ＋＋、ジャバ、ジャバスプリクト、アクティブ・エックス、共通ゲートウエイ・インターフェース（ＣＧＩ）スクリプト、アクティブ・サーバー・ページ（ＡＳＰ）及び／またはその他のようなファシリティを通じて、プログラム・モジュールの実行を可能にする。好ましくは、情報サーバーは、安全な通信プロトコルをサポートする。その通信プロトコルは、例えば、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュア・ソケット・レイヤー（ＳＳＬ）及び／またはその他であるが、これらに限定されるわけではない。従来は、情報サーバーは、結果をウェブ・ページの形でウェブ・ブラウザへ提供し、他のプログラムのモジュールとのインタラクションを通じて手を入れられたウェブ・ページの生成を可能にする。ＨＴＴＰリクエストにおけるＤＮＳ解決部分が特定の情報サーバーに解決されると、その情報サーバーは、ＨＴＴＰリクエストの残りの部分に基づいて、ＤＱＡＳコントローラー内の特定の場所にある情報を解決する。例えば、ｈｔｔｐ：／／１２３．１２４．１２５．１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌというリクエストは、ＤＮＳサーバーからそのＩＰアドレスの情報サーバーに解決した“１２３．１２４．１２５．１２６”というリクエストのＩＰ部分を有する。その情報サーバーは次に、リクエストの“／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ”部分に関してｈｔｔｐリクエストを更に解析し、“／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ”という情報を含んだメモリ内の場所へと解決する。情報サーバーは、そのモジュール自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールへと通信したり、及び／またはそれらと交信したりする。情報サーバーが、オペレーティング・システム、他のプログラム・モジュール、ユーザー・インターフェース、ウェブ・ブラウザ及び／またはその他と通信する頻度は非常に高い。情報サーバーは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
［ユーザー・インターフェース］
ユーザー・インターフェース・モジュール１１７は記憶されたプログラム・コードであり、ＣＰＵにより実行される。好ましくはユーザー・インターフェースは、オペレーティング・システム及び／またはオペレーティング環境によって、あるいはそれらと一緒に、及び／またはそれらの上に与えられる従来型の画像ユーザー・インターフェースであり、システム及び／またはオペレーティング環境とは、例えばアップル・マッキントッシュＯＳ、アクア、マイクロソフト・ウィンドウズ（ＮＴ）、（ＫＤＥ、Ｇｎｏｍｅ及び／またはその他の）ユニックスＸウインドウズ、及び／またはその他である。ユーザー・インターフェースはテキスト・ファシリティ及び／または画像ファシリティを通じて、プログラム・モジュール及び／またはシステム機能を表示、実施、インタラクション、操作及び／またはオペレーションすることを可能にしてもよい。ユーザー・インターフェースはファシリティを提供するが、そのファシリティとは、ユーザーが、コンピュータのシステムを実行し、インタラクションし及び／または働くものである。ユーザー・インターフェースは、それ自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールへと通信したり及び／またはそれらと交信する。ユーザー・インターフェースがオペレーティング・システムや他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。ユーザー・インターフェースは、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
［ウェブ・ブラウザ］
ウェブ・ブラウザ・モジュール１１８は記憶されたプログラム・コードであり、ＣＰＵにより実行される。ウェブ・ブラウザは従来のハイパーテキスト・ビューイング・アプリケーションであることが好ましく、例えば、（好ましくは、ＨＴＴＰＳ、ＳＳＬ及び／またはその他のような１２８ビットの暗号を有する）マイクロソフト・インターネット・エクスプローラーやネットスケープ・ナビゲーターである。ジャバ、ジャバスプリクト、アクティブ・エックス及び／またはその他のようなファシリティを通じて、プログラム・モジュールを実施することが可能なウェブ・ブラウザもある。一実施例では、例えばｗｗｗ．ｃｎｒｉ．ｏｒｇから入手可能なハンドル・システム・プラグイン等のブラウザ・プラグイン・ソフトウェアを用いてウェブ・ブラウザをハンドル対応にすることが可能である。別の実施例では、ハンドル・サポートは、ウェブ・ブラウザに組み込まれている。ウェブ・ブラウザやそのような情報アクセス・ツールは、ＰＤＡ、携帯電話及び／または他のモバイル・デバイスに組み込まれていてもよい。ウェブ・ブラウザは、それ自体及びその他のようなファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／またはと交信する。ウェブ・ブラウザが、情報サービス、オペレーティング・システム、インテグレートされたプログラム・モジュール（例えばプラグ・イン）、及び／またはその他と通信する頻度は非常に高い。例えば、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりするものである。もちろん、ウェブ・ブラウザや情報サーバーの代わりに、両者と同様の機能を持つような複合的なアプリケーションを開発してもよい。複合的なアプリケーションは、ＤＱＡＳ対応のノードからユーザー、ユーザー・エージェント及び／またはその他への情報の入手および提供を同様に実行する。複合的なアプリケーションは、標準的なウェブ・ブラウザを用いるシステムに対しては役に立たないこともある。そのような複合的なモジュールは、安全性をさらに強化するような中間の情報サーバーが存在しなくても、ＤＱＡＳと直接通信するように構成することができる。
［ＤＱＡＳデータベース］
ＩＡＭＲＳデータベース・モジュール１１９は、ＣＰＵにより実行される記憶されたプログラム・コードでデータベース内において具現し得て、記憶されたデータであり、記憶された部分のプログラ厶・コードが記憶されたデータを処理するためのＣＰＵを設定する。好ましくは、データベースは、例えばオラクルまたはサイベースといった、従来型、フォールト・トレラント、相関的、拡張可能で安全なデータベースであるのがよい。リレーショナル・データベースとは、フラット・ファイルの拡張である。リレーショナル・データベースは、一連の関連し合うテーブルから成る。鍵フィールドを通じてテーブル同士が相互接続する。鍵フィールドの使用によって、鍵フィールドに対するインデキシングによるテーブルの結合が可能になる。つまり、鍵フィールドが様々なテーブルから情報を組み合わせるための、次元的回転軸のような作用をするのである。一般に主要鍵を合わせることによって、相互関係におけるテーブル間に維持されるリンクを識別する。主要鍵は、リレーショナル・データベース内において、テーブルの行を固有に識別するフィールドを表す。より厳密には、主要鍵は、一対多数の関係における「一つの」面にあるテーブルの行を固有に識別するのである。
代わりに、配列、ハッシュ、（リンクした）リスト、ストラクト及び／またはその他の様々な標準的なデータ構造を用いて、ＤＱＡＳデータベースを実施してもよい。そのようなデータ構造は、メモリ及び／または（構造的な）ファイルに保存してもよい。仮にＤＱＡＳデータベースをデータ構造として実施すると、ＤＱＡＳデータベースの使用は例えばＤＱＡＳモジュールのような他のモジュールに組み込まれ得る。データベースは、標準的なデータ処理技術を介した無数のバリエーションによって、統合及び／または分散される。データベースの一部分、例えばテーブルは、エクスポート及び／またはインポートでき、それによって、分散したり及び／または統合したりする。非限定的な一実施例では、データベース・モジュール１１９は、例えばＵＮＩ（例えばハンドルや他のＵＮＩ）、テーブル１１９ａ、ＵＲＬテーブル１１９ｂ、メタデータ・テーブル１１９ｃ、多重解決テーブル１１９ｄ、ポリシー・テーブル１１９ｅ及び／またはその他といったテーブルを含むが、これらに限定されるわけではない。全てのテーブルは、（強化）ＤＯＩ鍵フィールド・エントリーが固有なので、このエントリーについて関係し得る。別の実施例では、これらのテーブルは、自身のデータベースとそれぞれのデータベース・コントローラ（つまり、上記テーブルそれぞれの個別のデータベース・コントローラ）に分散化されている。もちろん、標準的なデータ処理技術を用いて、データベースを幾つかのコンピュータのシステム的系統及び／または保存装置にわたってさらにデータベースを分散してもよい。同様に、分散したデータベース・コントローラの構成は、様々なデータベース・モジュール１１９ａ−ｅを統合及び／または分散することによって、変えることができる。ＤＱＡＳは、データベース・コントローラを通じたユーザーのリクエスト及び様々なトランザクションを追跡するように構成してもよい。
ＤＱＡＳデータベースは、それ自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／または交信したりする。ＤＱＡＳデータベースがＤＱＡＳＩＡＲＳモジュール、他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。データベースは、他のノード及びデータに関する情報を入手し、保持し、提供する。
［暗号サーバー］
暗号サーバー・モジュール１２０とは、保存されたプログラム・コードであり、ＣＰＵ１０３、暗号プロセッサ１２６、暗号プロセッサ・インターフェース１２７、暗号プロセッサ装置１２８、及び／またはその他のものにより実行される。暗号プロセッサ・インターフェースが暗号モジュールにより暗号化及び／または暗号解読のリクエストを迅速に実施することを可能にすることが望ましいが、代わりに暗号モジュールを従来のＣＰＵに実行させても良い。暗号モジュールが、供給されたデータの暗号化及び／または暗号解読を可能にすることが望ましい。暗号モジュールが対称及び非対称（例えばＰｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＲ））双方の暗号化及び／または暗号解読を可能にすることが望ましい。暗号モジュールは従来の暗号技術、例えば、デジタル証明（例えば、Ｘ．５０９認証枠組み）、デジタル署名、複式署名、エンベロッピング、パスワードのアクセス保護、公開鍵管理、及び／またはその他のものを可能にすることが望ましいが、暗号技術はそれらに限定されるわけではない。暗号モジュールは数々の（暗号化及び／または暗号解読）セキュリティ・プロトコル、例えば、チェックサム、データ暗号化基準（ＤＥＳ）、楕円曲線暗号化（ＥＣＣ）、国際データ暗号化アルゴリズム（ＩＤＥＡ）、メッセージ・ダイジェスト５（ＭＤ５、即ち一方向ハッシュ関数）、パスワード、ＲＣ５（リベスト暗号）、リジンデール、ＲＳＡ（インターネット暗号化及び認証システ厶で、１９７７年にロン・リベスト、アデイ・シャミル及びレオナルド・エイドウルマンが開発したもの）、セキュア・ハッシュ・アルゴリズム（ＳＨＡ）、セキュア・ソケット・レイヤー（ＳＳＬ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、及び／またはその他のものを可能にすることが望ましいが、セキュリティ・プロトコルはそれらに限定されるわけではない。暗号モジュールは、「セキュリティ許可」の処理を可能にする。こうしてセキュリティ・プロトコルがリソースへのアクセスを抑制しているが、暗号モジュールが安全化されたリソースへの許可されたアクセスを実行するのである。暗号モジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中には暗号モジュール自体及び／その他のファシリティも含まれる。暗号モジュールは、通信ネットワーク上での情報の安全な転送を可能にする暗号化方式を支援することが好ましく、もしユーザーが希望すれば、ＤＱＡＳモジュールが安全なトランザクションに用いられ得るようにする。暗号モジュールは、ＤＱＡＳ上のリソースの安全なアクセスを可能にし、遠隔システム上の安全化されたリソースのアクセスを可能にする。つまり安全化されたリソースのクライアント及び／またはサーバーとして機能することができる。暗号モジュールが情報サーバー、オペレーティング・システム、その他のプログラム・モジュール及び／またはその他のものと交信する頻度は非常に高い。暗号モジュールはプログラム・モジュール、システム、ユーザー及び／またはデータの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成、入手及び／または提供したりする。
［情報アクセス多重解決サーバー（ＩＡＭＲＳ）］
ＩＡＭＲＳモジュール１２５は保存されたプログラム・コードであり、ＣＰＵにより実行される。一般にＤＱＡＳは、通信ネットワーク上のノード間における情報のアクセス、入手、提供、及び／またはその他を実行する。ＩＡＭＲＳはＵＮＩを多重のインスタンス化へと解決する能力を有している。一般に、ＩＡＭＲＳはルックアップ・ファシリティとして役を果たし、与えられた情報、そのＤＯＩ、及びその現在の場所との間の関連性の作成、維持、及び更新を行う。ＩＡＭＲＳはＤＱＡＳデータベースと提携して、リクエストされた情報のデータ転送の向上、リクエストされた情報の種々のフォーマットへの解決、情報についてのクエリー作成用の強化されたメカニズムの提供及び／またはその他に役立つと思われるノードを識別する。ＩＡＭＲＳによるノード間の情報アクセス可能化の開発にあたっては、標準開発ツールを使用してもよい。例えば、Ｃ＋＋、シェル・スクリプト、ジャバ、ジャバ・スクリプト、ＳＱＬコマンド、ウエブ・アプリケーション・サーバー・エクステンション、アパッチ・モジュール、パール・スクプリト、バイナリ・エクセキュータブル、及び／またはその他のマッピング・ツール及び／またはその他を用いることができるが、それらに限定されるわけではない。一つの非限定的な実施例においては、ＩＡＭＲＳサーバーは暗号サーバーを用いて通信の暗号化及び暗号解読にあたっている。ＩＡＭＲＳはリクエストのサービス、ＵＮＩのための関連性情報の更新、その他多くのことにあたることができる。ＤＱＡＳモジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中にはＩＡＭＲＳモジュール自体及び／またはその他のファシリティも含まれる。ＩＡＭＲＳモジュールがＤＱＡＳデーターベース、オペレイティングシステム、その他のプログラム・モジュール及び／またはその他と交信する頻度は非常に高い。ＩＡＭＲＳはプログラムモジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンス等を含んだり、通信、生成、入手及び／または提供したりする。
［ディレクトリ品質保証サーバー（ＤＱＡＳ）］
ＤＱＡＳモジュール１３５は保存されたプログラム・コードであり、ＣＰＵにより実行される。一般にＤＱＡＳは、ＵＮＩをテストし、有効性を確認し及び／または検証し、故に、ユーザーは通信ネットワーク上のノード間における情報のアクセス、入手、提供及び／またはその他を行うことができる。ＤＱＡＳは、適切なデータが、ＵＮＩと関連した場所にて利用可能であることをテストすることによって、ＵＮＩと関連した情報の間の完全性を維持する。非限定的な一実施例においては、ＤＱＡＳは、ＵＮＩ登録システム（例えば情報アクセス登録サーバー・コントローラ（ＩＡＲＳ））に組み込まれてもよく、ＵＮＩ登録システムは、リソース・ネームを登録する能力（例えばハンドル）を有しており、リソース・ネームと情報及び／または情報の場所の間の関連を実行する。リソース・ネームの登録は、多重のインスタンス化に関連している。一般にＩＡＲＳは与えられた情報、そのＤＯＩ、及びその現在の場所との間の関連性の作成、維持、登録、及び更新を行うファシリティの役目を果たす。ＤＱＡＳは、ＵＮＩの有効性を確かめる能力をＩＡＲＳへ追加することもできる。代わりに、ＤＱＡＳは、ＩＡＲＳから分離したスタンド・アロン形式で作動してもよい。どちらの実施例においても、ＤＱＡＳはタグの生成に用いられ、タグは、情報の有効性が確認されるように、ＤＯＩに表された情報に組み込まれている。ＤＱＡＳはＤＱＡＳデータベースと提携して、ＵＮＩと関連した情報の完全性の有効性を確認すること、リクエストされた情報のデータ転送の向上、リクエストされた情報の様々なフォーマットへの解決、情報についてのクエリー作成用の強化されたメカニズムの提供及び／またはその他に役立つと思われるノードを識別する。ＤＱＡＳによるノード間の情報アクセス可能化の開発にあたっては、標準開発ツールを使用してもよい。例えば、Ｃ＋＋、シェル・スクリプト、ジャバ、ジャバ・スクリプト、ＳＱＬコマンド、ウエブ・アプリケーション・サーバー・エクステンション、アパッチ・モジュール、パール・スクプリト、バイナリ・エクセキュータブル、及び／またはその他のマッピング・ツール及び／またはその他を用いることができるが、標準開発ツールはそれらに限定されるわけではない。一つの非限定的な実施例においては、ＤＱＡＳサーバーは暗号サーバーを用いて通信の暗号化及び暗号解読にあたっている。ＤＱＡＳはリクエストのサービス、リクエストのリダイレクト、ＵＮＩのための関連性情報の更新、その他多くのことにあたることができる。ＤＱＡＳモジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中にはＤＱＡＳモジュール自体及び／またはその他のファシリティも含まれる。ＤＱＡＳモジュールがＤＱＡＳデーターベース、ＩＡＭＲＳモジュール、ＩＡＲＳモジュール、オペレイティングシステム、その他のプログラム・モジュール及び／またはその他と交信する頻度は非常に高い。ＤＱＡＳはプログラムモジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンス等を含んだり、通信、生成、入手及び／または提供したりする。
［分散型ＤＱＡＳ］
ＤＱＡＳノード・コントローラの構成要素は何れもあらゆる方法で、その機能性を組み合わせ、統合及び／または分散することが可能であり、開発及び／または配備を可能にすることができる。同様に、モジュール・コレクションも開発及び／または配備を可能にすべくあらゆる方法で組み合わせることができる。これを達成するには、単に各構成要素を共通のコード・ベースに統合するか、あるいは必要に応じて統合的に構成要素をダイナミックにロードできるファシリティに統合すれば良いのである。
モジュール・コレクションを統合及び／または分散するにあたっては、標準的なデータ処理及び／または開発技術を介した無数のバリエーションがある。プログラム・モジュール・コレクション中の何れのプログラムの多重のインスタンスをも単一のノードでインスタンス化でき、及び／または負荷バランシング・データ処理技術を通し、多数のノードを使用し性能を向上することもできる。更に、単一のインスタンスもまた複数のコントローラ及び／または記憶装置、例えばデータベースに分散することができる。
全てのプログラム・モジュールのインスタンスとコントローラは、標準的なデータ処理通信技術を通じ、共同作業を行う。
好ましいＤＱＡＳコントローラの構成は、システム配備のコンテキストによって異なる。例えば、元となるハードウェア・リソースの能力及び／または場所等のファクターが配置条件や構成に影響するが、こうしたファクターはそれらに限定されるわけではない。例え構成がプログラム・モジュールを合同及び／または統合する結果になろうが、分散化されたプログラム・モジュールより成り立つ結果になろうが、及び／または統合型と分散型の何らかの組み合わせになろうが、データの通信にあたっては、通信、入手、提供が可能である。プログラム・モジュール・コレクション中からの共通コード・ベースに統合された（モジュール・コレクション中の）モジュールのインスタンスは、データの交信、入手及び／または提供にあたることができる。これは、例えば、データ・レファレンシング（例えば、ポインタ等）、内部メッセージ、オブジェクト・インスタンス可変通信、共有メモリ・スペース、可変パッシング及び／またはその他のもの（アプリケーション内部の通信）等の基準データ処理技術を用いることにより達成されるが、これらに限定されるわけではない。
もしモジュールコレクションの構成要素がお互いに個別的、分離的、及び／または外部的である場合は、データの通信、入手、及び／または提供を他のモジュール構成要素と行う及び／または他のモジュール構成要素へと行うにあたっては、標準的なデータ処理技術を用いればよい。標準的なデータ処理技術には例えば、アプリケーション・プログラム・インターフェース（ＡＰＩ）情報パッセージ；（分散型）コンポーネント・オブジェクト・モデル（（Ｄ）ＣＯＭ）、（分散型）オブジェクト・リンキング・アンド・エンベディング（（Ｄ）ＯＬＥ）、及び／またはその他のもの）、コモン・オブジェクト・リクエスト・ブローカー・アーキテクチャー（ＣＯＲＢＡ）、プロセス・パイプ、共有ファイル及び／またはその他のもの（アプリケーション間の通信）があるが、これらに限定されるわけではない。グラマーの生成及び解析は、アプリケーション間の通信のための個別のモジュールの構成要素間で送ったメッセージや、アプリケーション内部の通信のための単一モジュールにおけるメモリ空間内で送ったメッセージを促進する。グラマーは、例えばｌｅｘ、ｙａｃｃ及び／またはその他といった標準的な開発ツールを使用して開発してもよい。それらの標準的な開発ツールは、グラマーの生成及び機能性の解析を可能にし、これらは今度はモジュール内及びモジュール間の通信メッセージの基礎を形成する。この場合もまた、好ましい実施例はシステム配備のコンテキスト次第である。
最後に、モジュール・コレクションの如何なる組み合わせにおける、及び／または、図及び開示全体を通して記述した本発明における、論理上の構造、及び／あるいはまたは、トポロジー構造も、固定的な実施順位及び／またはアレンジメントに限定されるわけではなく、むしろ、開示した順位は典型的なものであり、順位にかかわらず全て機能的に等価であるものを本開示は意図していることを理解すべきである。更に、こうした構造は順次の実行に限られず、むしろ非同期的、同時の、同期的、及び／またはその他のように実行する任意の数の、スレッド、処理、サービス、サーバー及び／またはその他を本開示は意図していることを理解すべきである。
［ＩＰアドレッシング］
ユーザーはアドレスを介して通信ネットワークにアクセスする。アドレスは場所を表している。ユーザーは通信ネットワークにおいて、情報を探し出すべく場所から場所へ移動する。一般的な通信アドレス方式はＩＰアドレスを用いている。ＩＰアドレスは現実の世界では住所に例えることができる。ＩＰアドレス自体は、例えば２０９．５４．９４．９９といった一連の数字であり、通常は、例えばｗｗｗ．ｃｏｎｔｅｎｔｄｉｒｅｃｔｉｏｎｓ．ｃｏｍというような関連する名前を有する。分散型データベース・レジストリは名前とＩＰアドレスの関連するペアを維持し、関連する名前を対応するＩＰアドレスへと解決する役目を担う。これにより、ユーザーは、２０９．５４．９４．９９といった一連の数字を暗記して用いる代わりに、例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍといった名前を覚えておいて使用することが可能になる。ＩＰアドレスの名前解決を支援するこれらの分散型データベースは、一般的にドメイン・ネーム・サーバー（ＤＮＳ）と呼ばれている。
ＩＰアドレスを、アドレスに更なるナビゲーション情報を付加したユニバーサル・リソース・ロケーター（ＵＲＬ）として具現することが一般的である。ユーザーは、ＨＴＴＰを用いてＵＲＬに保存されている情報をアクセスするためにソフトウェアを用いてもよい。一例を挙げると、ユーザーが「ｈｔｔｐ：／／ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」とウェブ・ブラウザに指定する。すると通常この更なるナビゲーション情報である「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」がコンピュータ・サーバー内の特定の保存場所を提示する。この更なるナビゲーション場所は、現実の世界では番地よりも詳しい、会社名や部署名、部屋番号等を含む住所に例えることができる。この更なるナビゲーション場所の取り扱いや解決は、通常ＤＮＳではなく解決されたＩＰアドレスにある情報サーバーにより行われる。例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍに対して解決したアドレスである１２３．１２３．１２３．１２３にある情報サーバーは、サーバー内のローカルの場所「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」にある情報を解釈し返送する。情報サーバーとは、通信ネットワークと特定のＩＰアドレスにあるコンピュータ・サーバーの間の通信を可能にする手段である。情報サーバーの商業的な例としては、アパッチが挙げられる。情報サーバーは、企業内の該当部署へ郵便物を仕分ける企業えのメール室に例えることができる。
図２と図３は、ＩＰアドレッシング・メカニズムは、情報が通信ネットワーク上で移動する間に、情報との関連を維持しないということを図示している。一般的にウェブ・ページのリンクにはＨＴＴＰを用い、ＨＴＴＰはＩＰアドレッシングに依存している。従って、ＵＲＬリンクは単に通信ネットワーク上の場所を示すだけで、必ずしも特定の情報と関連しているわけではない。例えば、ｗｗｗ．ｎｅｗｓ．ｃｏｍをレファレンスするＵＲＬリンクによってＵＲＬとｗｗｗ．ｎｅｗｓ．ｃｏｍで入手可能な情報を関連付けてもたらされる情報は、その場所では毎日情報が更新されるため、異なる情報となる。多くの場合、企業が情報を移動させたり、事業を移動させたり、廃業したりすると、場所そのものが消失する。
例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ２０８という場所に存在した「１９９９年度売り上げ」というタイトルのレポート２２２が、当該情報があるエンティティから別のエンティティに売られたり、アーカイブされたり、あるいはその他様々な理由で、例えばｗｗｗ．ｒｅｐｏｒｔ．ａｒｃｈｉｖｅｓ．ｃｏｍ／１９９９／Ｏｌｄ−ｒｅｐｏｒｔ．ｈｔｍｌ３１０という場所に移動することもある。ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ２０８という場所に存在したレポートは５００万ウェブ・ページ及び場所２４４をレファレンスするＵＲＬリンクを有したかもしれず、ユーザーが当該情報へのアクセスを試みると、その場所は既に存在しないため及び／またはその場所はユーザーが所望した情報を含まないため、ユーザーは「４０４Ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」のエラー３０９を受け取る可能性もある。結果としてエラーが出るのは、ＤＮＳは常にユーザーのリクエストを場所へと解決するよう設計されているためであり、またＤＮＳはＵＲＬと特定の情報のインスタンス化との関連を維持するように設計されていないためである。
図２はウェブ・ページ２０１、ユーザーが入力したアドレス２０２、ドキュメント２０３及びメモリ・デバイス２０４を描写し、何れも一つの情報（「１９９９年度売り上げ」のレポート）２２２をレファレンスするためにＵＲＬを、従ってＩＰアドレッシングを用いる。次に図２では、情報２２２は元の場所２０８（例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）から図２の新しい場所３１０（例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）へ移動する。図３において、この結果として当該の場所をレファレンスする全てのＵＲＬ２４４のブレーキング３０１−３０４が起こり、あの恐ろしい「４０４Ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」のエラー３０９を、当該の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８へレファレンスする全てのユーザーとＵＲＬに提示することになる。
［ハンドル・システム］
ひとたび一つの情報にＤＯＩが指定され利用可能になると、ＤＯＩシステムはＤＯＩのユーザーがアクセスを望むものを解決できるようになる必要がある。ＤＯＩの解決を成し遂げるために用いる技術は、「ハンドル・システム」としてより広く知られており、以下により詳しく説明する。ＤＯＩハンドブックには基本的なＤＯＩの一般的な概要が記載されている。一言で言えば、ハンドル・システムはプロトコルのオープンなセット、ネームスペース及びプロトコルの実施化を含む。プロトコルは分散型コンピュータ・システムが、デジタル・コンテンツのハンドル（ＤＯＩ等）を保存し、コンテンツの所在を確認しアクセスするため、当該コンテンツに関係する情報の所在を確認しアクセスするため、あるいは当該コンテンツに関連するサービスの所在を確認しアクセスするために（即ちそのようなサービスへのインターフェースを提供するために）必要な情報へと、それらのハンドルを解決することを可能にする。必要に応じて、ＤＯＩを変更することなく識別されたコンテンツの現状を反映するために、この関連情報を変更することができるので、場所やその他の状況の情報の変更を経てもアイテムの名前が存続することが可能になる。一元管理されたＤＯＩ登録機関と共に、ハンドル・システムは長期にわたるネットワーク上の情報及びサービスの信頼性のある管理のための、汎用且つ分散型のグローバル・ネーミング・サービスを提供する。本開示全体にわたり、ＤＯＩシステムを介してアクセス可能になった「ソース」、「コンテンツ」及び／または「情報」とは、特定が可能な全てのコンテンツ、ソース、情報、サービス、トランザクション及び記事、書籍、無形オブジェクト、音楽アルバムを含む著作物、人物、有形で物理的なオブジェクト、その他及び／またはそれらの選択された個別の部分及び／またはそれらの組み合わせを更に含む、から成り得ることに注意することが重要である。アクセス可能な情報は、サービスやトランザクションを開始するアプリケーションや、選択のメカニズム及び／またはその他を提供するアプリケーション等へのＵＲＬでもよい。一つの非限定的な例では、ＤＯＩは、ソーシャル・セキュリティ番号、電話番号及び／またはその他のある人物を識別する情報と関連付けられることすらあり得る。別の非限定的な例においては、ＤＯＩはソフトウェア・モジュール、プログラミング「オブジェクト」またはその他のネットワークに基づくリソースの何かと関連付けられたりもする。更に、実際の製品（現在ＵＰＣやバーコードで識別されている品物等）のオンラインでの表示を含むほとんど全てのものを表示するためにＤＯＩを用いることができる。そのような例では、ＤＯＩはある製品を説明したり販売したりしている製造者のカタログ・ページへと解決することができ、多重解決シナリオにおいては、ある品物を修理してもらうにはどこへ行けばよいか、交換用の部品はどこへ行けば見つかるか、新製品あるいは交換用の製品はどのようなものか、どのような価格またはリースのオプションがあるのか等、当該オブジェクトに関係する全てのサービスへと解決することができる。ＤＯＩを実施するその他の実施例に含まれるのは、通信ネットワークを介して分散型の方法で動作することができるソフトウェアの異なるモジュールの表示、ボイス・オーバーＩＰ技術のための電話番号、遺伝子配列、医療記録及び／またはその他の恒久的な記録（ＤＯＩは、サーティフィケートあるいは暗号解読鍵を呼び出すこともある暗号化及び／またはその他の方法で保護された恒久的な記録に特に有用）及び／または同様のもの、である。別の実施例ではＤＯＩは、例えば現在の株価、（株及び／またはその他全てのオークション及び／または為替の）最新の競売価格や売り出し価格、（別の過去の年次報告書には異なるＤＯＩが割り当てられているのに対して）企業の最新の年次報告書、及び／またはその他のようなもので、しかしこれらに限定されない一時的及び／または動的なバリューの恒久的な場所を表す。
ユーザーはデジタル・オブジェクト・アイデンティファイアー（ＤＯＩ）を介して情報にアクセスし得る。ＤＯＩは情報そのものに関連付けられている（即ち情報自体の名前である）。ＤＯＩは「ハンドル」のインスタンスであり、「ハンドル・システム」の枠組みの中で動作する。ＤＯＩは永続的に関連付けられた情報へのアクセスを可能にする。ＤＯＩは、一連の文字の後にセパレーターが付き、その更に後に一連の文字が付いたもので、例えば１０．１０６５／ａｂｃ１２３ｄｅｆというようになる。注意すべき、そして再び強調すべきことは、本開示は「ＵＲＮ」「ＤＯＩ」「ハンドル」といったＵＮＩの特定のサブ・タイプについて記載することもあるが、本開示はより一般的なタイプのＵＮＩにも同等に適用されるものであり、従って特に断りの無い限り本開示はＵＮＩのあるサブ・タイプに言及する場合はＵＮＩ全般にわたって適用されるものと見做されるべきものである。更に、今日使用されているハンドル・システム、ＤＯＩ及びそれらの支援技術や仕様は、本開示の意図したフォーラムではあるものの、本開示は最新の、または今後考案される仕様やシステムに基づいた他のフォーラムにも応用できることを意図していることに注意すべきである。
［ＤＯＩ］
情報にアクセスするためにＤＯＩを使用しているユーザーは、ＤＯＩが関連付けられた情報のみを解決しアクセスすることを知っている。場所をレファレンスするＵＲＬとは対照的に、ＤＯＩとは情報に対する名前であり、その情報の場所やその他の属性、と共に関係するサービスをも見るために用いることができる。情報とは、電子書籍、音楽ファイル、ビデオ・ファイル、電子ジャーナル、ソフトウェア及び前記のコンテンツの一部及び／またはそれらの組み合わせも含む情報と共にコンピュータで読み取り可能なファイル全てを含むと考えられる。電子コンテンツは通信ネットワーク上で利用可能となっているので、これ以降本出願書はそのような利用可能な情報は、通信ネットワーク上で発行されたものとみなすということに注意されたい。
ＤＯＩは、通信ネットワーク上で利用可能な情報に与えられた恒久的で永続的な識別子で、仮にコンテンツあるいは関連するデータの場所（即ちＵＲＬ）、フォーマット、所有権等が変更されたとしてもユーザーが関連データにアクセスすることができるように、電子的形態で登録されている。ＤＯＩまたはハンドルは、ＵＲＬの代わりにユーザーに配信できる。ユーザーは、ハンドル対応のウェブ・ブラウザに、ＵＲＬハイパーリンクと同様にＤＯＩを選択したり入力したりすることにより、ある特定のＤＯＩに関連付けられた情報にアクセスする。例えばｗｗｗ．ｃｎｒｉ．ｏｒｇから入手可能なハンドル・システム・プラグイン等のブラウザ・プラグイン・ソフトウェアを用いて、数多くの種類のブラウザをハンドル対応にすることが可能である。ＤＯＩに関連付けられた情報にアクセスするためのそのような試みにより、リソースの現在の所在を確認する自動のプロセスが起動する。当該リソースの現在の場所は、ハンドル・システムによって利用可能な一元管理されたディレクトリ内の当該リソースのＤＯＩに関連付けられており、それが今度はユーザーを（即ちユーザーのウェブ・ブラウザを）当該リソースの現在の場所へと導く。この誘導はしばしば、選択されたＤＯＩに関連する現在のＵＲＬと、対応する情報を返信することによって実行される。
図４はＤＯＩを介した情報へのアクセスを上記の図２及び図３と対比して図示している。最初に、登録プロセスを経て情報（「１９９９年度売り上げ」のレポート）２２２にＤＯＩが与えられる。ＵＲＬを用いる代わりに、ユーザーはＤＯＩを用いウェブ・ページ４０１、ウェブ・ブラウザへのタイプ入力４０２、ドキュメント４０３、デバイス４０４、バーコード４０６及び／またはその他を介して当該情報のレファレンス４４４を行う。ユーザーがＤＯＩリンク４４４を行うと、それらは一元管理されたＤＯＩディレクトリ４１１において解決され、リクエストしたユーザーは情報２２２の最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８へのＵＲＬリンク２４４を与えられる。当該情報が最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８から新たな場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）３１０へ移動４３４すると、当該情報の発行者４１０は新たな場所をレファレンスする更新されたＵＲＬ２４５を送ることにより、ＤＯＩ一元管理ディレクトリ４４５に当該情報の新しい場所を知らせる。それ以降、ユーザー４０１−４０４がＤＯＩリンク４４４を介して当該情報にアクセスを試みると、ＤＯＩディレクトリは更新されたＵＲＬ２４５を通して適正に新しい場所３１０を提示する。
上記のように、ＤＯＩは情報のみならず、その一部を識別するために用いることもできる。例えば、ＤＯＩシステムによれば、１冊の書籍が一つのＤＯＩを有することが可能な一方、その書籍のそれぞれの章が別の、それぞれの章を識別するための固有のＤＯＩを有することもあり、更にはその書籍中の図面一つ一つがそれら図面を識別するための固有のＤＯＩを有することも可能である。言い換えれば、ＤＯＩシステムによると、コンテンツ発行者の希望通りに様々な細かさのデータの塊として情報を識別することができる。なお、ユニバーサル・プロダクト・コード（一般的には消費者向け製品の「バーコード」として表示されている）によって例えば、スーパーのレジ、在庫コンピュータ、財務システム及び流通業者が現実の世界でサプライ・チェーンを自動化することが可能になるように、本開示はＤＯＩを用いて世界中の全ての電子発行エージェントがインターネットを介したデジタル・コンテンツ（及びそのコンテンツに対する権利のライセンス）の販売を効率的な方法で自動化することを可能にするメカニズムを提供すると想定している。何故ならば、販売可能なコンテンツのそれぞれが世界で唯一のＤＯＩを有しており、それをエージェント同士のトランザクションにおいて製品の識別コードとして使用することが可能だからである。
［ハンドル構造］
ハンドル・システムは、効率的でユーザーに分かり易い利用を可能にするための前もって決められた方針の一群を採っており、そのうち幾つかを以下に挙げる。発行者がオペレーション・コストを負担して、ＤＯＩ解決のためのハンドル・システムの使用がユーザーには無料となるのが理想的である。ＤＯＩは全て世界的なＤＯＩ機関に登録される。登録者は、登録したＤＯＩに関する状態データ及びメタデータを維持する責任がある。ＤＯＩのシンタックスは標準化されたシンタックスに準じる。使用にあたっては、ＤＯＩはオペーク・ストリング（ダム・ナンバー）になる。ＤＯＩ登録機関はＤＯＩの指定、登録、ＤＯＩに関連するメタデータの申告を管理する。
図５及び図６は、ハンドル６００の概略図である。ハンドル６００は二つの構成要素である、プレフィックス５０１とサフィックス６０２を有する。プレフィックス５０１とサフィックス５０２は、フォワード・スラッシュ５０７により区切られている。ハンドル５００には、印刷できる文字であれば、今日書かれたり使用されたりしているほとんど全ての主要な言語のどれを取り入れてもよい。プレフィックス５０１にもサフィックス５０２にも特に長さの制限はない。結果として、利用可能なハンドルの数はほとんど無限であると想定される。プレフィックス５０１とサフィックス５０２の組み合わせを確実に唯一固有なものにすることが、ハンドル・システムの完全性を維持するためには重要である。そのため、ＤＯＩ登録機関は発行者に固有のプレフィックス５０１を与え、一実施例では登録機関が、指定するサフィックス５０２もまた確実に固有のものであるようにする責任を発行者に課す。これはユーザーのクライアント・コンピュータ・システム上で動作している登録ツールによって達成され得る。別の実施例では、本開示全体にわたって記載しているように、様々なサフィックス生成アルゴリズムを適用することによって、登録機関がサフィックス５０２が固有なものもであること確実にする。登録機関とハンドル・システム管理者は共に、新しいハンドルについては全てその固有性を確認してからハンドル・システムに入れる。登録機関はハンドル・システムにＤＯＩ記録を入れ、それを受けてハンドル・システムはＤＯＩディレクトリを介してＤＯＩ解決リクエストに対し情報を提供する。
プレフィックス５０１自体は、プレフィックス・セパレーター５０６、即ちピリオドにより区切られる二つの構成要素を有する。ハンドル・プレフィックスの第一の部分はハンドル・タイプ５０４で、第二の部分はハンドル・クリエーター５０５である。ハンドル・タイプ５０４は、どのようなタイプのハンドル・システムが使用されているかを識別する。ハンドル・タイプ５０４が「１０」で始まる場合、当該ハンドルはＤＯＩであると識別され、ハンドル・システムの他の実施タイプではないと分かる。ピリオドにより区切られたプレフィックスの次の要素であるハンドル・クリエーター５０５は、ＤＯＩの登録を希望する団体に与えられる番号（または文字列）である。これら二つの要素５０４と５０５が一緒になり、ＤＯＩの固有の発行者プレフィックス部分を形成する。どの団体が申請するハンドル（より詳しくはＤＯＩ）プレフィックスの数にも制限はない。結果として、例えば出版社は一つのＤＯＩプレフィックス５０１を有してもよいし、ジャーナルごとに異なるプレフィックスを有することも、そのジャーナルの刷り込み毎に一つのプレフィックスを有することもできる。通常プレフィックス５０１は単純な数字列だが、ハンドル・システムの範囲はそれに限定されるものではない。従って、プレフィックス５０１にアルファベットやその他の文字を用いてもよい。
サフィックス５０２は固有の英数字列であり、特定のプレフィックスと共に、固有情報を識別する。発行者のプレフィックス５０１と発行者の提示する固有のサフィックス５０２の組み合わせにより、ＤＯＩ番号の一元割り当ての必要性を免れる。サフィックス５０２は、当該発行者がプレフィックスと共に登録した他のどのサフィックスとも異なる固有のものである限り、当該発行者の選択する如何なる英数字列でもよい。
図６は、ＤＯＩ６００の別の実施例を示しており、図中ではテキストブックのＩＳＢＮ番号がサフィックス６０２として機能している。従って便宜上、元と成るコンテンツの発行者は、サフィックス６０２として元のコンテンツに合致する他のどのような識別コードを選択してもよい。
［強化ＤＯＩ］
図５は更に、強化ＤＯＩ５１０グラマーを図示している。ＤＯＩグラマーを強化する非限定的な実施例は、強化されたプレフィックス５１１として具現される。しかしながら、別の及び／または相補的な強化されたサフィックス（図示はしていない）を同様にＤＯＩ５１１に付けてもよいと、全面的に意図されている。強化されたサフィックス５１１は、強化グラマー・ターゲット５１７と強化セパレーター５１４から成る。強化セパレーター５１４は＠という記号であるが、当然のことながら、他の文字を強化セパレーターとして指定しても良い。強化グラマー・ターゲット５１７自体は、強化セパレーター５１４以外の任意の文字列である。強化グラマー・ターゲット５１７は、ＤＯＩ５００が特定の情報を多重の種類で解決する目的で用いられ、本開示の中で詳しく述べる。さらに強化された実施例では、強化グラマー・ターゲット５１７自体が更に、強化グラマー動詞５１２と、例えばピリオドのような強化ターゲット・セパレータ５１６によって分離される強化グラマー・ターゲット・オブジェクト５１３から成り得る。もちろん、強化ターゲット・セパレーター５１６は、任意の文字で指定できる。一実施例では、強化グラマー動詞５１２は修飾語として働き、一つのＤＯＩのための複数の多重解決ターゲットの中から選択し、強化グラマー・ターゲット・オブジェクト５１３は、更なるアクションのために、ターゲット・オブジェクト及び／またはハンドル・システム解決サーバーへと手渡される一つの値である。
［ハンドル・システム・メタデータ］
ＤＯＩ５００は識別番号に過ぎず、必ずしもそれに関連付けられた情報について何らかの情報を伝達するわけではない。結果として、ＤＯＩにアドレスする情報に関する追加情報を補足して、ユーザーが効率的且つ分かり易いサーチを行い、所望のコンテンツを通信ネットワーク上で入手できるようにすることが望ましい。情報を識別し易くするために、本発明は識別される情報の説明的なデータであるメタデータを使用する。メタデータはＤＯＩに関連するどのようなデータ構造であってもよいが、一実施例によると、メタデータは発行された情報を正確且つ簡潔に識別できる幾つかの基本的なフィールドから成る。この実施例によれば、メタデータは書籍の国際標準図書番号（ＩＳＢＮ）等のレガシー識別スキームからのエンティティと関連する識別子、発行されたコンテンツのタイトル、発行されたコンテンツの種類（書籍、音楽、ビデオ等）、当該コンテンツはオリジナルか派生したものか、コンテンツの主要な著者、コンテンツ作成の際の主要著者の役割、発行者の名前及び／またはその他等から成る。異なる種類のコンテンツはそれを説明する異なるデータを必要とするため、異なる種類のコンテンツには異なるメタデータを使用することを想定しているということがＤＯＩシステムの特徴の一つである。
一実施例によると、メタデータはＤＯＩシステムのユーザー全てに利用可能となっており、それによってユーザーは特定のＤＯＩが識別するエンティティの基本的な説明を検出することが可能である。この基本的な説明によりユーザーはコンテンツを発行したエンティティの、あるいはコンテンツ自体の、幾つかの基本的な事柄を理解することができる。
結果として、ＤＯＩが何の情報を識別するのかを調べるには、それを解決した後、関連するメタデータをレビューすることが望ましい。何故ならばＤＯＩはメタデータを識別するコンテンツや、同じまたは関係するコンテンツに関する別のメタデータとリンクするからである。一実施例では、メタデータによりＤＯＩ５００が識別する情報と共に、その明確な仕様の認識が可能になる。またメタデータにより当該情報とネットワーク上のその他の情報（及びそれらのエンティティに関するメタデータ）とのインタラクションが可能になる。
［ＤＯＩ情報アクセス］
図７と図８は、ＤＯＩハンドル・システ厶にＤＯＩを提示するだけでユーザーが所望の情報にアクセスできるようにする解決メカニズムの概要を示している。本状況での解決とは、識別子をネットワーク・サービスに提示し、引き換えに当該識別子に関連する最新の情報を一つ以上受け取ることを含む。図７に示すＤＯＩシステムの一実施例では、ユーザーはウェブ・ブラウザ７００クライアントを用いて特定のＤＯＩ７１０が識別するコンテンツを指し示す。このＤＯＩ７１０は関連するＵＲＬを一つしか持っていないため、そのＵＲＬへと解決されるはずである。その結果、ユーザーが特定の識別子７１０が識別する、元と成るコンテンツをリクエストすると、ユーザーは所望のコンテンツがあるＵＲＬ７２０へと導かれる。
従って、このメカニズムにより情報の場所が変更されても、アクション可能な識別子としてエンティティの名前を維持することが可能になる。発行者がコンテンツの場所を変更した場合、発行者はハンドル・システムのデータベース内のＤＯＩエントリーを更新するだけで既存のＤＯＩ７１０は確実にコンテンツの新しい場所を提示する。結果として、コンテンツの場所は変更されてもＤＯＩは変更されず、ユーザーは既存のＤＯＩを用いて新しい場所にある当該コンテンツにアクセスすることが可能である。
図８は、ユーザーがＤＯＩを用いて、同一のＤＯＩが識別した同一のコンテンツの利用可能な複数のコピーの中から、コンテンツへのリクエストと共にコンテンツについてのデータの場所と（例えばコンテンツの購入といった）そのコンテンツに関連するサービスを解決するＤＯＩシステムの概要を示している。従って、ユーザーはウェブ・ブラウザ８００を用いて必要なＤＯＩ８３０を提示する。ＤＯＩ８３０は、所望のサービス８３５の種類を説明するように構築することもできる。その結果、ＤＯＩシステムはユーザーがアクセスすることを所望している特定のコンテンツ８４０へと解決することが可能になる。
図９は、本発明に基づき、ユーザーが情報にアクセスするために行う一連のアクションの概要を示している。まず初めに、ユーザーはブラウザ・クライアント９００をパソコン、携帯情報端末（ＰＤＡ）及び／またはその他のコンピューティング・デバイス９０５上に立ち上げる。ユーザーはブラウザ９００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワークを通してＤＯＩディレクトリ・サーバー９１０に送られる。ＤＯＩディレクトリ・サーバー９１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べ、正しいＵＲＬをユーザーのコンピュータ９００上のブラウザ９００に送るが、こうしたアクションはユーザーには見えないようになっている。結果として、ブラウザは正しい発行者情報９２０があるサーバー上の所望のコンテンツへと導かれる。最終的に、ユーザーのブラウザからのリクエストを受け取ると、発行者９２０は所望の情報をユーザーに送り、その情報にはブラウザ・クライアント９００でアクセスすることができる。
図１０は、図９に示すようにユーザーがコンテンツの情報にアクセスするために行う一連のアクションをより詳しく示している。上述したように、ユーザーはブラウザ・クライアント１０００をコンピューティング・デバイス１００５上に立ち上げる。ユーザーはブラウザ１０００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワーク上でＤＯＩディレクトリ・サーバー１０１０に送られる。ＤＯＩディレクトリ・サーバー１０１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べる。ＤＯＩをＤＯＩディレクトリ・サーバー１０１０に保存されているエントリーに照らし合わせて調べた結果、ユーザー１０２５をどこへ導くべきかをＤＯＩディレクトリ・サーバー１０１０は決定する。当該コンテンツの正しいＵＲＬは、何らの中間介入あるいはユーザーによるアクションなしに、自動的にユーザーのブラウザ１０００に送られる。その結果、ブラウザ１０００は元と成るＵＲＬによりアドレスされたサーバーを有する正しい発行者１０２０へと導かれる。当該ＵＲＬは発行者のサーバー１０２０によりユーザーの所望するコンテンツの厳密な場所を決定するために用いられ、発行者のサーバー１０２０は正しいコンテンツ１０３０をユーザーに送る。
図１１は、本発明に基づいて、ＤＯＩを解決して所望のコンテンツが位置するＵＲＬを得ることにより、通信ネットワーク上で情報にアクセスするための幾つかの典型的なメカニズムの概要を示している。一実施例によると、ユーザーは直接ＤＯＩを提示し、ＤＯＩシステムは正しいコンテンツを入手し単に正しいＵＲＬにリンクすることによりそれをユーザーに送信する。別の実施例によると、ユーザーはメタデータに含まれるフィールドの幾つかに関係する情報を提示し、するとＤＯＩルックアップ・サービスは正しいＤＯＩを識別し、それが今度は所望するコンテンツの場所を解決する。図１１に示すように、一実施例によれば、サーチ・エンジン１１０１０をユーザーに提供してもよい。一実施例では、登録機関のＤＯＩ及びメタデータ・データベースの通信において、サーチエンジンをオファーし配備する。別の実施例では、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍのようなサーチ・エンジンを用いて登録機関のデーターベースにクエリーを出す。ユーザーは、サーチ・エンジン１１０１０に何らかの識別情報を提示することにより正しいＤＯＩを検索する。サーチ・エンジン１１０１０は提示された識別情報を用いてメタデータに関する自分のデータベースを検索し、提示されたメタデータの情報に関連するＤＯＩを入手する。したがって、サーチを行うユーザーに、メタデータ・データベースから返送したＤＯＩ及び／または前記返送したＤＯＩから解決したＵＲＬを提示し得る。入手したＤＯＩはＤＯＩディレクトリ１１０１１に送られ、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを解決する。最終的に、ユーザーのブラウザは正しいコンテンツ１１０６０へと導かれる。
別の実施例によると、ユーザーはＤＯＩ１１０１５をブラウザ１１０２５のアドレス・ウィンドウ１１０２０に提示する。ユーザーのウェブ・ブラウザが元々ＤＯＩを処理する能力がない場合、ＤＯＩ１１０１５はＤＯＩディレクトリ１１０１１用のプロキシ・サーバーのアドレスを含んでいてもよく、それは図１１においては「ｄｘ．ｄｏｉ．ｏｒｇ」である。その結果、ブラウザはｄｘ．ｄｏｉ．ｏｒｇに位置するＤＯＩディレクトリ１１０１１へと導かれ、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを解決し、ユーザーのブラウザをそこへと導く。
別の実施例によれば、ＤＯＩはドキュメントあるいは何らかの形式の情報１１０３０の中に埋め込むこともでき、それによりＤＯＩをクリックすることによってユーザーを正しいＤＯＩディレクトリ１１０１１に導き、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬ決定し、ユーザーのブラウザをそこへと導く。
別の実施例によると、ＤＯＩはＣＤ−ＲＯＭまたはフロッピー・ディスク等のメモリ１１０４０上に提示してもよく、するとメモリは自動的に、または起動されると、ユーザーを正しいＤＯＩディレクトリ１１０１１に導き、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを割り出し、ユーザーのブラウザをそこへと導く。
また別の実施例によれば、ＤＯＩは印刷物としてユーザーに提供してもよく、ユーザーは当該ＤＯＩを上記の如く光学的及び／または機械的周辺入力機器を用いてマニュアルで入力する。
図１２は、通信ネットワーク上で情報を入手し、ＤＯＩシステムがＤＯＩを解決して所望の情報が位置するＵＲＬを得るための典型的なメカニズムの別の実施例の概要を示している。この一実施例によると、複数のＤＯＩディレクトリ１２１０が分散型ＤＯＩディレクトリとして存在し、ハンドル・システム１２００を形成している。一実施例では、分散型ＤＯＩディレクトリはあたかも単一のディレクトリ１１０１１であるかのように動作し、リクエストに応える。その点を除いては解決は図１１と同様に行われる。
図１３は、本発明に基づいた典型的なＤＯＩシステムの概要であり、発行者、ＤＯＩ登録サービス及びハンドル・システムが連携して創り出す効果的なＤＯＩシステムの概要を示している。プレフィックス・ホルダー１３３５は、ＤＯＩ情報サービス１３００にＤＯＩ１３４２と、関連するメタデータ１３６６から成る情報を提出する。既に固有のプレフィックス５０１を与えられているプレフィックス・ホルダーは、コンテンツ１３６６にサフィックス５０２を指定するように要求する。登録サービス１３００は、情報１３４２、ハンドル・システム１３５０内に次に預けるための情報１３６６といったユーザーから提出された情報、及び／またはメタデータ・データベース１３１０を解析及び／または再形式設定する役目を担う。上記のように、ＤＯＩを用いてアドレスできるコンテンツの範囲は無限である。その結果、コンテンツ１３６６は如何なる情報及び記事、書籍、音楽アルバムを含む著作物、またはそれらの選択された個別の部分から成ってもよい。ＤＯＩ５００を提供することに加え、発行者１３４２は、コンテンツ１３６６用のメタデータを収集する。当該メタデータは当該コンテンツのＤＯＩ５００、ＤＯＩジャンル、識別子、タイトル、タイプ、起源、主要エージェント、エージェントの役割及び／またはその他から成る。様々な相手から提供され識別されたコンテンツに関係のある関連サービスのリストから成っていてもよい。様々な相手とは例えば、コンテンツをオンラインで購入できるウェブ・ページの場所である。
発行者１３４２がコンテンツ１３６６にサフィックス５０２を指定し必要なメタデータを収集すると、ＤＯＩ５００と当該メタデータはＤＯＩ登録サービス１３００に送信される。ＤＯＩ登録サービス１３００はＤＯＩ５００のデータベース、登録されたコンテンツ１３６６全てのメタデータと共にコンテンツ１３６６が位置するＵＲＬを維持する。本発明によると、ＤＯＩ登録サービス１３００は当該メタデータをメタデータ・データベース１３１０、図１では１１９ｃに送信する。メタデータ・データベース１３１０はＤＯＩ登録サービス１３００が一元管理することもできるし、またそうしなくてもよい。
ＤＯＩ登録サービス１３００は、収集されたメタデータを別のデータ・サービス１３２０に提供したり、付加価値を付けたリソース１３３０をユーザーに提供したりするために利用することもできる。加えて、ＤＯＩ登録サービス１３００は正しいＤＯＩハンドル・データをハンドル・システム１３５０に送り、ハンドル・システムは複数のＤＯＩディレクトリ・サーバー１３４１から成っていてもよい。
［ハンドル・システム多重解決モデル］
図１４は、様々なエンティティと交信しているＩＡＭＲＳ１４００６の非限定的な一例を図示している。発行者１４０１２は、自らの情報を異なる場所から、異なるフォーマットで、異なるコンテキストにおいて、異なる目的や用途のために利用可能にしたいと望むかもしれない。そうする際に、発行者は単一のＤＯＩ１４００１を、多重解決１４００５、１４０２１−１４０２３で強化されたハンドル・システム１４００８に登録できる。部分的には、当該の強化されたシステムは多重解決システムである。発行者はＤＯＩの多重解決を提供して、個人、図書館、企業、大学及び／またはその他のような顧客１４００１、卸売業者／流通業者、集積業者、シンジゲート運営者、検索サービス、アブストラクトとインデクシングのサービス、定期購読エージェント、バーティカル・ポータル及び／またはその他のような情報再販業者（情報仲介業者）１４００２に対する自らの情報の用途とアクセスを強化したいと希望するかもしれない。例えば、卸売業者／流通業者１４００２が、正しく情報へのアクセスを計上し代金を請求するために、自らのサーバーに発行者の当該情報を置いておく必要がある場合、通信ネットワーク１４００４を介した顧客１４００１による強化されたハンドル・システム１４００８への強化されたＤＯＩサービスのリクエスト１４０１０が、ＵＲＬ１１４００５に関連する購入記録を選択１４０３０する。その後ＵＲＬ１は、通信ネットワーク１４００４を介して顧客１４００７へとリダイレクトして戻される。発行者はまた権利認可１４０２１、価格見積１４０２２及びメタデータのアクセス１４００９、１４０２３についての様々な場所をも提供する。
［ハンドル・システ厶登録モデル］
図１５及び図１６は、様々なエンティティとインタラクションするＤＱＡＳ１５００１の非限定的な例を図示している。図１５及び図１６は、図１４で描写された環境の概要図であり、ＤＱＡＳ１５００１の登録ファシリティ１５００２を強調したものである。発行者１４０１２は、自らの情報を異なる場所から、異なるフォーマットで、異なるコンテキストにおいて、異なる目的や用途のために利用可能にしたいと望むかもしれない。そうする際に、発行者はＤＯＩ１５０２０及び関連するメタデータ１５０１０を、登録機能１５００２を持つ強化されたハンドル・システム１４００８及びメタデータ・データベース１４００９に登録する。一実施例においては、メタデータは、登録ファシリティ１５００２においてＤＯＩ１５０２０から分離され、メタデータ１５０１１は、二段階コミット手続きの第一段階においてメタデータ・データベース１４００９に送られる。第二段階において、ＤＯＩ、ＵＲＬ及びその他の関連するポインタ１５０１２は、メタデータ１５０１０から分離され、その他のセキュリティ許可情報（例えば、パスワード等）と共に通信ネットワーク１４００４を通じハンドル・システム１４００８に送られる。一つの代替実施例では、ユーザーは公開されないよう、及び／または検索の対象にならないようにメタデータ無しでＤＯＩの登録をリクエストできる。一つの実例においては、登録機関はユーザーに対しこのような「非発行ＤＯＩ」に料金を科している。関連するメタデータ１５０１１のメタデータ・データベース１４００９への登録、及びＤＯＩ１５０１２のハンドル・システム１４００８への登録が両方とも成功すると、登録は成功したものと見なされる。もし、何れかの登録段階で失敗すると、もう一つの段階、または両方の段階の関連データはデータベースより取り除かれる。登録ファシリティは、この二段階のコミット手続きに関するＸＭＬまたはタグ・ベースのレポーティング及びエラー・ハンドリングを提供し、登録者がエラー状態のハンドリングを自動化することを可能にしている。更にまた、発行者は、情報がハンドル・システムを介して利用可能であり、アクセス可能であり続けることを確かなものとしたり、登録ファシリティ１５００２が様々な品質保証テストを行い、ハンドル・システム１４００８にあるＤＯＩが、関連した情報へと正しく解決することの有効性を確認するようにリクエストすることを望んでもよい。
一実施例では、登録プロセスの一環として、登録ファシリティは発行者にタグを提供し、タグは登録される情報に組み込まれ、故に、情報が後に検証され得る。このタグは、チェックサム、デジタル証明、デジタル署名、ＤＯＩ、暗号鍵、パスワード、セキュリティ許可のほぼ如何なる形式及び／またはその他であってよい。コードが、一旦認識された際は情報の有効性を確立するために用いられ得る限りは、如何なるコードをもタグとして組み込むことができる。一実施例ではタグが固有であることを保証する必要はなく、例えば、タグは単に＜ＳＯＵＲＣＥＴＡＧ ＶＡＬＩＤＡＴＯＲ＞有効な情報＜／ＳＯＵＲＣＥ ＴＡＧ ＶＡＬＩＤＡＴＯＲ＞というタグであることも可能である。もちろん、より固有なタグを使用することによって、タグ情報を間違えて有効性を確認するような可能性は低くなる。タグ自体は、情報所有者に特定された如何なるフォーマットであってもよい。レスポンス解析器は、ポリシーによってカスタム・タグを探すようにプログラム化されていてもよい。一実施例では、ＸＭＬコードは、ソース・タグの有効性の確認のために情報へ加えられる。更にまた、三つの段階の自動ホスティングと登録プロセス（つまり、追加の段階を加えた二つの段階のコミットメントで、この追加の段階では自動的にユーザーからコンテンツを取り出し、それをホスティングし、登録されたＤＯＩ及び／または任意の関連したメタデータによる解決のために、それを利用可能にする）は、そのようなピングによる有効性の確認を用いることもできる。そのような実施例では、コンテンツをクライアントから適切な記憶ファシリティへ転送すると、ＤＱＡＳはソース及び／またはソースの場所アドレスの有効性を確認することもでき、これは、本開示全体にわたって説明されているように、場所アドレス及び／またはソースをピングによってテストしたり、及び／または様々な有効性を確認する技術を用いることによって可能となる。そのような実施例では、ＤＱＡＳは、情報アクセス登録サーバー（ＩＡＲＳ）コントローラ及び／またはその他のような三つの段階の自動ホスティングと登録が可能な登録機関に組み込まれる。三つの段階の自動ホスティングと登録ファシィリティへ有効性を確認することを加えることにより、三つの段階のコミットメントが可能となる。そのような実施例では、有効性を確認する（つまりピングによるテスト）及び／または二つの段階のコミットメントの内どちらか片方が機能しない場合は（つまり、ハンドル・システムでのメタデータ及び／またはＤＯＩ登録のどちらか）、ＤＯＩの登録は完了されず、ＩＡＲＳがエラーを生成し、エラーを知らせる。もちろん、二つの段階のコミットメントと同様に、ユーザーがどのようなエラーの取り扱いを望むかによっては、三つの段階のコミットメントでのエラーが出たときは、ＤＯＩの登録の完全な失敗を引き起こすようにもできるし、及び／または、代わりに三つの段階のコミットメントのある部分だけを完了することも可能で、この場合は単に重大ではないと特定された残りのエラーをユーザー及び／または登録機関へ警告する。このような自動化された三つの段階コミットメント登録プロセスは、ソースを迅速に発行する保証を要するユーザーのために役に立つ。
図１６は、図１５で描写された環境を詳しく述べたものである。図１６は、様々な登録フランチャイズ加盟者１６００２が発行者１４０１２からのＤＯＩ登録を処理し受け入れて、登録リクエストを登録ファシリティ１５００２に送るということが意図されていることを強調している。フランチャイズ加盟者には、ＩＳＰ、ウェブ・ホスティング・プロバイダー、シンジケート、流通業者、集積業者、及び／またはその他がある。様々なフランチャイズ加盟者は、更に発行者獲得のため、登録ファシリティの届く範囲を広げたり、登録ファシリティの登録のための構造基盤に基づいて、登録ファシリティのパートナーに金銭的奨励を提供してもよい（例えば、コミッションの提供）。一つの非限定的な実施例においては、登録ファシリティはフランチャイズ加盟者にコミッション（つまり、フランチャイズ加盟者が登録ファシリティにもたらした各ＤＯＩ登録からの収入の歩合）の支払いをしている。そのような実施例では、フランチャイズ加盟者は登録リクエストを自分が「店頭」として受け入れるが、実際には登録リクエストは登録ファシリティに送り戻している。登録ファシリティは登録を実行し、登録するユーザーから直接支払いを受け、代金受領後、コミッションをフランチャイズ加盟者に支払う。別の実施例では、「店頭」フランチャイズ加盟者は登録するユーザーからの支払いを受け付け、登録代金を登録ファシリティに転送している。別の非限定的な実施例では、フランチャイズ加盟者は、登録サービスより登録技術のライセンスを受け、実質的には独立して運営するが、その場合には、登録サービスとフランチャイズ加盟者間において情報共用または他の協定が存在している。
［品質保証システム概要］
図１７は、ハンドル・システムにおいてハンドルを有効性を確認する際に、様々なエンティティとインタラクションするＤＱＡＳ１７０１の非限定的な例を図示している。ＤＯＩの有効性を確認する一般的な概要はＤＱＡＳ１７０１を伴い、ＤＱＡＳはＤＯＩデータベース１１９から特定されたターゲットのためのターゲット場所１７１８をピングする。本開示全体にわたってピングするという時は、通信をリクエストし、前記通信リクエストの確認が予想されることを意味することと理解すべきである。ピングするということは、Ｕｎｉｘでのｎｅｔｓｔａｔ、ｐｉｎｇ、ｓｐｒａｙ、ｔｒａｃｅｒｏｕｔｅｓ及び／またはその他のリクエストといった単純なものであり得る。しかしながら、ピングするということは、また、より複雑なリクエスト、例えばＨＴＴＰ経由のデータ、ＦＴＰ、音声認識機能付き電話、読み取りレシート経由の電子メール確認、電話応答及び／またはその他のリクエストを意味することもあり、その際は複雑なデータが返信され、有効性を確認する目的で解析されることもある。別の実施例では、単一の及び／または多数の単純ピング・リクエストと、より複雑なデータ・リクエストの様々な組み合わせが、単一「ピング」アクションを構築することも可能で、単一「ピング」アクションはピング・ターゲットの利用可能性について様々な度合いの情報を提供する。
ＤＱＡＳは、ＤＯＩがＤＯＩに表される情報を含む場所へ正しく解決することの有効性を確認する。例えば、ＤＯＩ「１０．１２３／ａｂｃｄｅｆｇ」が情報「Ｍｏｂｙ Ｄｉｃｋ」を表し、これが場所「ａ．ｂ．ｃｏｍ／ｆｉｌｅ」にて見つかるべきである場合、ＤＱＡＳ１７０１がＤＯＩデータベース１１９からＤＯＩ「１０．１２３／ａｂｃｄｅｆｇ」の有効性を確認することを決定する際に、ＤＱＡＳは場所「ａ．ｂ．ｃｏｍ／ｆｉｌｅ」を調べ、この場所が利用可能であることを確かなものとする。別の実施例では、ＤＱＡＳは、また、場所が関連した情報「Ｍｏｂｙ Ｄｉｃｋ」を実際に含むことを確かなものとすることもできる。
有効性の確認の非限定的な例において、ユーザー１７３０は、ＤＱＡＳ１７０１を用いて、通信ネットワーク１１３経由でＤＯＩの有効性を確認するポリシーを提出及び／またはポリシーを確立する。ユーザーは、図２５と本開示の全体にわたって更に詳述されるポリシー・マネジャー・ツール１７３１を用いることにより、前記を行うことができる。ポリシー・マネジャーは、様々なＤＱＡＳ構成要素、例えばレスポンス解析器１７１８、フィーダー１７０２、マイナー１７０３、エラー・プロセッサ及び／またはその他を通してポリシーを設定及び／またはポリシーを実行する。通常、ポリシーはＤＯＩが登録された後に確立される。別の実施例では、ポリシー・マネジャー・ツールは登録ツール内から呼び出される。ポリシー・マネジャー・ツールは、ウェブ・ページまたはクライアント・アプリケーションとして具現され、単一及び／またはバッチとしてＤＯＩの有効性の確認を可能にする。ポリシー・マネジャー・ツールへ正しいエントリーを提供すると、ポリシー・マネジャー・ツールは、通信ネットワーク１１３を介して特定されたＤＯＩのためのＤＯＩ有効性確認ポリシーをＤＱＡＳ（例えば、登録機関）に提供する。代わりに、受信するＤＱＡＳ１７０１は、登録機関のポリシーによって確立された自動化された方法で、ＤＯＩデータベース１１９からのＤＯＩを処理してもよい。ユーザー１７３０、ポリシー・マネジャー１７３１及び／または登録機関によって、どのようにポリシーが確立されるにかかわらず、ＤＱＡＳ１７０１は登録機関のデータベース１１９からのＤＯＩの有効性を確かめる作業に参加する。
非限定的な一実施例において、ＤＱＡＳ１７０１は、フィーダー１７０２、ピンガー１７１６、レスポンス・コレクター１７１７、レスポンス解析器１７１８、エラー・プロセッサ１７１９から成る。フィーダーは、更にマイナー１７１３、エンキュー（ＮＱ）フィーダー１７１４、デキュー（ＤＱ）フィーダー１７１５から成る。もちろん、図１ですでに記載したようにあらゆる方法にて全ての上記構成要素を組み合わせ及び／または分散してもよい。一実施例では、ＮＱフィーダーとＤＱフィーダーはマイナー１７１３とは別のモジュールであり、拡張性を促進するために通信ネットワーク１１３を介して通信するように配置されている。明瞭性上描写されてはいないが、図１７の構成要素と本開示のその他の構成要素の間の全ての通信は、直接接続及び／または通信ネットワーク１１３のどちらを介してもよく、好ましい実施例は配備条件次第である。
最初に、マイナー１７１３は、ＤＯＩデータベース１１９からＤＯＩをエンキューすることをリクエストする。ＤＯＩデータベースは登録機関、ハンドル・システム、ミラー及び／またはその他によって維持される。マイナー１７１２からのクエリー・リクエストを処理すると、データベース１１９は、マイナー１７１３へクエリー結果を提供する。別の実施例では、マイナーはグローバル・ハンドル・システム以外のソース・データベースからＤＯＩの割り当てを受信し、マイナーは、同じＤＯＩのための別のソースから受信された記録とグローバル・ハンドル・システムに存在する記録を比較し、よって、ＤＯＩシステムの一般ユーザーに表示される記録を検証していることを確かなものとする。次にマイナーは利用可能なＮＱフィーダーを探し出して、返信されたクエリー結果１７１４をフィードできるが、このクエリー結果１７１４は様々なＤＯＩの様々な解決のための情報の場所である。ＮＱフィーダーはキューを維持するが、キューにおいてＮＱフィーダーは、ＤＱＡＳ（つまり、マイナーから受信されたＮＱメッセージのリスト）によって有効性を確認されるＤＯＩ解決を指示する。このキューは、図１８で詳細に記載される。ＮＱフィーダーは、その後、ＤＯＩデータベース１１９からエンキューされたＤＯＩ（またはそれらの様々な解決）についての統計をリクエストする。一実施例では、そのような統計はピング統計テーブル１１９にて維持される。リクエストされたクエリー結果は、ＤＯＩデータベース１１９からＮＱフィーダー１７１４へ送り返される。別の実施例では、これらの統計は、ＤＯＩをエンキューするための最初のリクエストと共にマイナー１７１３によって取得されることもある。ＤＯＩピング統計は、あるＤＯＩのために行われた任意の過去の品質保証の有効性確認に関する、またはそれらの任意の所定の解決に関するエラー率、成功したピングの回数、失敗したピングの回数、ランク及び／またはその他を含む。ＤＯＩピング統計は、フィーダー１７０２においてエンキューされたＤＯＩ解決を配列、順番付け及び／または或いはランク付けするために用いられる。そのような順番付けされたＤＯＩ解決は、今度はピンガー１７１６へフィードしてもよい。
ＮＱフィーダー１７１４がマイナーからのＮＱメッセージ（つまり、有効性を確認する目的でエンキューするＤＯＩ解決）と、ＤＯＩデータベースからＤＯＩのピング統計と、キューの中で配列すると、ＤＱフィーダー１７１５は順番付けされたＮＱメッセージをこのキューからデキューする。ＤＱフィーダーはデキューされたピング・ターゲットをピンガー１７１６へ提供する。ピンガー１７１６がデキューされたメッセージ（つまり、キューからデキューされたメッセージ）を入手すると、ピンガーはデキューされたメッセージ１７１８のターゲットをピングする。別の実施例では、ピンガーは、あるＤＯＩの所定の解決ではなくＤＯＩ自体を渡され、マイナーによってＤＯＩデータベース１１９からエンキューされた状態のＤＯＩと関連した全ての場所を解決しようと試みる。また別の実施例ではピンガーは、ハンドル・システムに保存されマイナーによってエンキューされた状態のＤＯＩと関連した全ての場所を解決しようと試みる。ピング・ターゲット１７１８がレスポンスを送り返した場合、レスポンス・コレクター１７１７がピング・レスポンスを入手する。その後、レスポンス解析器１７１８がレスポンス・コレクター１７１７から集められたレスポンスを入手し、集められたピング・レスポンスをピング統計テーブル１１９におけるＤＯＩデータベースに保存する。ピング統計テーブル１１９に保存された解析されたピング・レスポンスは、ピング時間、レイテンシー値、エラー・メッセージ及び／またはその他を含むことができる。
ＤＯＩデータベース及び／またはピング統計テーブル１１９が、有効性のためにすでにピングされたＤＯＩと関連した統計とエラーを集めると、エラー・プロセッサ１７１９は、ピング・レスポンス・エラーをＤＯＩデータベース１１９へリクエストすることができる。エラー・プロセッサ１７１９が、ピング・エラーを詳述するクエリー結果をＤＯＩデータベースから入手すると、エラー・プロセッサはエラーを解析し、エラーを訂正し、ユーザーにエラーのレポートを送り及び／または異なる媒体によって異なるコンタクトへのエラー・レポートをエスカレートすることができる。エラー・プロセッサは、確立されたポリシー及び／または任意の所定のＤＯＩを支配するポリシーに基づいてエラーを解析、訂正、レポート、エスカレートする。エラー・プロセッサによる如何なるレポート及び／またはエスカレーションでも、今度はユーザー１７３０へ提供され得る。ユーザーは、そのようなレポートを自動化された電話、電子メール、ポケットベル及び／またはその他の手段によって受身的に入手する。別の実施例では、ユーザーはまた、アクセス・マネジャーによって積極的にエラー・レポートをクエリーすることもできる。このアクセス・マネジャーは、ユーザーがポリシー・マネジャー及び／またはその他のファシリティ経由でウェブ・ページを介してエラーを検索することを可能とするものである。
［フィーダー概要］
図１８は、フィーダーとデータ・フローの非限定的な例の概要を図示している。フィーダー１７１２は優先データ構造１８０５を維持している。優先データ構造は、データベース、ハッシュ・テーブル、キュー、ソートされて（二重に）リンクされたリスト及び／またはその他の形式をとってもよい（以下「キュー」と称する）。キューは順番付けられていて１８０１、各ＤＯＩエントリー１８０３とＤＯＩに関連した情報場所１８０４全てのピング重要度１８０２を含むことができる。各ＤＯＩ１８０３のアイテム１８０１は、そのピング重要度１８０２及び／またはランクをコンポジットから入手することができ、このコンポジットはＤＱＡＳデータベース１１９にて維持されたピング統計から計算されており、これは図１９で更に詳述される。別の実施例では、キューは拡張されてより多くのコラムを持ち、キューのランク付けを行う実際のピング統計を含むことができる。このキュー１８０５の例では、最高のピング重要度を持つＤＯＩは、順番としてキューの最後の方に置かれる。一実施例において、より高いピング重要度はより優先されていることを示す。そのような実施例では、より高い優先権の可能性のあるピング・イベントは、フィーダーによってピング・テストのためにピンガーへと早く持っていかれる。この非限定的な例では、キューの最後とは、そこから高い重要度のＤＯＩがデキューされて、ピンガー１７１８へ供給されるところである。ＮＱメッセージ１８１１は、ＤＱＡＳデータベース１１９からマイナーによって（図示はしていない）フィーダーへ提供される。図にて図示された例では、ＮＱリクエスト１８１１は、ピング重要度「５」を有しており、アイテム１３としてキュー１８０５の最後の方に挿入される。ピンガーはＤＱメッセージを用いて、ＤＯＩに関連した情報が見つかることになっている通信ネットワーク１１３を介して場所をピングする。
［品質保証フィーダー］
［ＵＮＩデータ・マイナー］
図１９は、品質保証ＵＮＩデータ・マイナー・ファシリティ（マイナー）の非限定的な一例のフロー・ダイヤグラムを図示している。オプションとしてマイナーは、特定された周期的な時間間隔１９０１においてクロン・ジョブを通じて設定される様々な時間間隔で作動できる。マイナーが特定された時間に作動する場合は、ＤＱＡＳはマイナーの作動時間が経過したかを決定する１９０２。もし経過していない場合は、ＤＱＡＳは特定された時間が来るまで調べ続ける１９０２。代わりに、マイナーが継続的に作動することも、または単一イテレーション作動することも可能である。
また、マイナーは必要に応じて、例えばユーザーから及び／またはシステム・リクエストから実行されてもよい。例えば、ユーザーが直ちにサイトをテストする必要がある場合（例えば、インターネット・ウェブ・プレゼンスを開設したばかりで、一般からのアクセスが可能となる前にそのコンテンツの利用可能性の品質テストをしたいと望む場合）、そのようなユーザーが優先リクエストすることも可能であり、この優先リクエストはマイナーに提供され、ユーザーのコンテンツのための解決ＤＯＩの品質を入手、テストする。更にまた、この必要に応じた実行は、ＤＱＡＳにモニターされた様々なイベントによってトリガされる。そのような実施例では、幾つかの基準は、ポリシーにて確立された通りＤＱＡＳによって監視される。この基準は、特定された発行者、特定されたＤＯＩ、特定された所定のタイプの問題及び／またはその他を含む。例えば、トリガ・イベントとは、所定の発行者プレフィックスの任意のＤＯＩと遭遇する際、マイナーが品質保証テストを行うことである。別の非限定的な実施例では、トリガ・イベントとは、ＤＯＩの所定の範囲がマイナーに遭遇する際はいつも無視されて、品質保証テストのためにエンキューされないことである。更に別の実施例では、トリガ・イベントとは所定のエラーが（例えば三つの連続するレイテンシー・エラーが、個々のポリシーにかかわらず任意のＤＯＩに対して検出される際はいつも）、マイナーをフィーダーにエンキューさせることである。本質的に、マイナーはマイナー自身のトリガ・ポリシーを持つことができる。そのような一実施例では、トリガ・ポリシーは、個々の発行者及び／または個々の発行者ＤＯＩによって、及び／または個々の発行者及び／または個々の発行者ＤＯＩのために生成された如何なる個々のポリシーを超越した、個別で包括的なポリシーである。別の実施例では、マイナーは個々の発行者及び／または個々の発行者ＤＯＩのためのトリガ・ポリシーを持つ。更に別の実施例では、マイナーは、個々のポリシーを包括するトリガ・ポリシーを維持し、個々のポリシーを組み合わせた中でも個々のポリシーをサポートすることができる。更にまた、全てのポリシーはダイナミックに更新されてもよい。
インスタンス化され実在する状態になると、マイナーはＤＯＩに対する割り当てセグメントをＤＱＡＳデータベース１９０３から入手する。言い換えれば、マイナーは、有効性の確認を要するＤＯＩのある部分をＤＱＡＳデータベース１１９にあるＤＯＩテーブルから入手する。この部分はＤＱＡＳ及び／またはマイナーによるポリシーによって確立される。マイナーはＤＱＡＳデータベースへのクエリー・リクエストを作成する。マイナーがＤＱＡＳへリクエストするインスタンスが多重にあり得るので、中央ＤＱＡＳによってマイナーを管理して、同じＤＯＩ、同じデッドロック及び／またはその他のリクエストを繰り返すことを避けるようにすることもできる。そのような実施例では、多重のスレッド、多重のプロセッサ、多重のサーバーは全てＤＱＡＳデータベースに同時にアクセスして、ＤＱＡＳによる有効性の確認を要する多数あり得るＤＯＩを分割する。別の実施例では、単一のＤＱＡＳがＤＯＩの全ての有効性の確認を行う。一実施例では、マイナーはＤＯＩ識別子、関連した解決場所、情報タグ識別子及び／またはその他をリクエストする。別の実施例では、ピング統計もリクエストされる。クエリー・リクエストは、最初の基準１９０４に基づいてデータベース・クエリー結果に対する最初のソートを供給してもよい。一実施例では、先に計算された有効性確認ランクはクエリー結果をソートするために用いられ、よって最高のランク付けをされた結果が最初に有効性確認される。
ソートされたクエリー結果をＤＱＡＳデータベース１９０４から入手すると、マイナーは、データベース・セグメント１９０５の返信されたクエリー結果にある各ＤＯＩに対してイテレートする。返信された結果１９０５にある各ＤＯＩに対して、マイナーはオプションとしてハンドル・システム１９０６をもってＤＯＩ記録を検証してもよい。マイナーはハンドル・システムの権力を行使するリクエスト、及び／またはハンドル・システムの通常のリクエストをすることができる。別の実施例では、この追加的な検証は、ピンガーと後にマイニングするためにＤＱＡＳデータベースに保存された結果によって行われる。選択されたデータベース・セグメント１９０５にある各ＤＯＩに対してイテレートすると、マイナーは各ＤＯＩ１９０７に対してイテレートする。例えば、強化ＤＯＩが二つのフォーマット（例えば、Ｆｏｒｍａｔ．１＠１０．１２３／ａｂｃｄｅｆとＦｏｒｍａｔ．２＠１０．１２３／ａｂｃｄｅｆ）を持つ場合、各フォーマットは、各フォーマットと関連した解決場所（例えば、フォーマット１はｗｗｗ．ｌｏｃａｔｉｏｎ．ｃｏｍ／ｓｐｏｔ１、フォーマット２はｗｗｗ．ｌｏｃａｔｉｏｎ２．ｃｏｍ／ｓｐｏｔ２）１９０７を持つ。従って、そのような各解決場所１９０７に対して、マイナーはそのＤＯＩ解決１９０８のためのピング統計を入手する。別の実施例では、マイナーは、ＤＱＡＳ１９０３への元のクエリーに伴うピング統計を入手する。ＤＯＩ解決場所の有効性が確認されたり、ランク付けをされたり、及び／またはその他である場合は、このピング統計は例えば該ＤＯＩ解決場所をピングした時のエラー、該ＤＯＩ解決場所への最新の成功したピング時間・日付、該ＤＯＩ解決場所に対して繰り返されたエラーの数といった情報を含む。
ピング統計１９０８を用いて、マイナーはＤＯＩ解決場所の新しいランクを決定する１９０９。非限定的な一実施例では、この新しいランク（つまりピング重要度）は重要度を付けられたエラーと重要度を付けられたピング統計に基づいている１９１０。例えば、
新しいランク＝
＋ １＊（Ｔｏｄａｙ−ＬａｓｔＰｉｎｇＤａｙ）
｛上の行は、ＤＯＩ解決場所の有効性が確認されなかった一日毎に
ランクを１ポイント加算する。｝
＋ １００＊（ｉｆＮｅｖｅｒＶｅｒｉｆｉｅｄＤＯＩ）
｛ＤＯＩの有効性が一度も確認されていない場合、上の行はランク
を１００ポイント加算する。｝
＋ １０＊（ｉｆＮｅｗＡｄｄｒｅｓｓＮｅｖｅｒＶｅｒｉｆｉｅ
ｄ）
｛ＤＯＩ解決場所の有効性が一度も確認されていない場合、上の行
はランクを１０ポイント加算する。｝
＋ １＊（ｆｏｒＥａｃｈＵｎｉｔＰｅｒＸ＄ＰａｉｄＦｏｒＶｅｒｉ
ｆｉｃａｔｉｏｎ）
｛上の行は、購入されたランクのポイント毎にランクを１ポイント
加算する。これは、ＤＱＡＳオペレーターがランク優先の一つのレ
ベル毎に特定の金額を請求する場合の例である。｝
＋
５＊（ｉｆＬａｓｔＰｉｎｇＷａｓＤＮＳＥｒｒｏｒ）＊（Ｎｕｍｂ
ｅｒＯｆＲｅｐｅａｔｅｄＤＮＳＥｒｒｏｒｓ／ＤＮＳＢａｔｃｈＳ
ｉｚｅ）
｛上の行は、ＤＮＳエラーを繰り返したバッチ毎にランクを５ポイ
ント加算する。ＤＮＳバッチ・サイズは特定できる。バッチ・サイ
ズとは、ランク・ポイントを増やすようにシステムが気付くまでの
発生回数を特定したものである。最新のピングがエラーに終わった
場合、繰り返されたＤＮＳエラーの回数をバッチ・サイズで割った
ものを、ランクの５ポイントに掛ける。｝
＋ ３＊（ｉｆＬａｓｔＰｉｎｇＷａｓ４０４Ｅｒｒｏｒ）＊（Ｎｕ
ｍｂｅｒＯｆＲｅｐｅａｔｅｄ４０４Ｅｒｒｏｒｓ／４０４Ｂａｔｃ
ｈＳｉｚｅ）
｛上の行は、ＨＴＴＰ４０４エラーを繰り返したバッチ毎にランク
を３ポイント加算する。４０４バッチ・サイズは特定できる。最近
のピングがエラーに終わった場合、繰り返された４０４エラーの回
数をバッチ・サイズで割ったものを、ランクの３ポイントに掛け
る。｝
＋
１＊（ｉｆＬａｓｔＰｉｎｇＷａｓＨｉｇｈＬａｔｅｎｃｙ）＊（Ｎ
ｕｍｂｅｒＯｆＲｅｐｅａｔｅｄＬａｔｅｎｃｙ／ＬａｔｅｎｃｙＢ
ａｔｃｈＳｉｚｅ）
｛上の行は、レイテンシー・エラーを繰り返したバッチ毎に一つの
ランク・ポイント加算する。レイテンシー・バッチ・サイズは特定
できる。最近のピングがエラーに終わった場合、繰り返されたレイ
テンシー・エラーの回数をバッチ・サイズで割ったものを、ランク
の１ポイントに掛ける。｝
＋ ５＊（ｉｆＥｒｒｏｒＲｅｐｅａｔｅｄ３ｒｄＰａｒｔｙＲｅｐｏｒ
ｔｓ）＊（ＮｕｍｂｅｒＯｆＲｅｐｅａｔｅｄＲｅｐｏｒｔｓ／Ｂａｔｃ
ｈＳｉｚｅ）
｛上の行は、第三者がレポートするエラーを繰り返したバッチ毎に
ランクを５ポイント加算する。第三者がレポートするバッチ・サイ
ズは特定できる。最新のピングがエラーに終わった場合、第三者が
レポートするエラーの繰り返し回数をバッチ・サイズで割ったもの
を、ランクの５ポイントに掛ける。｝
上記の合計は、新しく算出されたランクとして設定される。もちろん、これは一つのランク付け方式にすぎず、無数の他の方式がポリシーによって用いられ得るし、及び／または確立され得る。
新しいランク１９０９を決定すると、マイナーはフィーダー１９１１を見つける。フィーダーは多くの基準について識別され、この基準は例えばシステム負荷が最も軽いもの、平均ピング経時が最も短い可能性のもの、ＤＯＩ解決場所に最も近いもの、ＤＯＩ解決場所に最も遠いもの、及び／またはその他のフィーダーを見つける、といったものである。「ピングの可能性」とは、フィーダーにエンキューされているＤＯＩ解決場所のことである。可能性のあるピングとは、ピンガーにエンキューされているが、まだデキューされていないピングのことである。そのようなピング可能性統計はデータベース、ログ及び／またはその他データ構造にてフィーダーによって維持されている。一実施例では、フィーダーはフィーダーの最新ピング潜在的統計をマイナーへ送り、故にマイナーはそのような負荷を分散する決定を下すことができる。適切な及び／または利用可能なフィーダーを識別すると、マイナーはＮＱメッセージを識別されたフィーダーへ提供する１９１２。有効性を確認する（つまりピングすること）ためにＤＯＩ解決場所をエンキューすると１９１２、マイナーは現在のＤＯＩ１９０７に対して次の解決をイテレートする。
現在のＤＯＩの全ての多重解決がイテレートされた際は１９０７ループは終了し、ＤＱＡＳデータベースによって返信されたデータベース・セグメントにある次のＤＯＩがイテレートされる１９０５。返信されたデータベース・セグメントからの全てのＤＯＩがイテレートされた際は１９０５、マイナーは終了イベントが発生したかを決定する１９１３。終了イベントが発生しなかった場合は、マイナーは、終了イベント１９１３が検出され、その段階で実行が終了する１９１４まで、次のクロンのイテレーション１９０１、１９０２を待ち、及び／または実行を継続する１９０３。
［エンキュー・フィーダー］
図２０は、品質保証エンキュー・フィーダー（ＮＱフィーダー）の非限定的な一例のフロー・ダイヤグラムを図示している。オプションとして、ＮＱフィーダーは、特定された周期的な時間間隔２００１においてクロン・ジョブを通じて設定される様々な時間間隔で作動できる。ＮＱフィーダーが特定された時間に作動する場合は、ＤＱＡＳはＮＱフィーダーの作動時間が経過したかを決定する２００２。もし経過していない場合は、ＤＱＡＳは特定された時間が来るまで調べ続ける２００２。代わりに、ＮＱフィーダーが継続的に作動することも、または単一イテレーション作動することも可能である。また、ＮＱフィーダーは必要に応じて、例えばユーザーから及び／またはシステム・リクエストから実行されてもよい。
インスタンス化され実在する状態になると、ＮＱフィーダーはメッセージを入手する２００３。通常、このメッセージは、図１９と全体にわたって上記記載されたようにマイナーからのＮＱメッセージである。しかしながら、別の実施例では、ＤＱメッセージがピンガーから入手される２００３。メッセージを入手すると、メッセージは解析される２００４。メッセージは様々なフィールドに分解解析される（例えば、タイプ：マイナーからのエンキュー・リクエスト、ピンガーからのデキュー・リクエスト、及び／またはその他、エントリー：ＤＯＩ、関連した場所、メタデータ、及び／またはその他；エンキューＤＯＩ統計：ピング統計、ランク、及び／またはその他；除去：ピンガー・アドレス、及び／またはその他、及び／またはその他）。メッセージを解析すると２００４、ＮＱフィーダーはオプションとして、メッセージがＮＱメッセージであるかＤＱメッセージであるか決定する２００５。これを達成するには単に、メッセージ・タイプがエンキュー・リクエストであるのかデキュー・リクエストであるのかを明記しているタイプ・フィールドを解析すればよい。
ＤＱメッセージが検出された場合２００５、ＮＱフィーダーはオプションとして利用可能な最適のピンガー２０１１を決定する。あるピンガーがＤＱイベント２００５をリクエストしているとしても、フィーダーは、リクエストしているピンガーよりも好ましいより適切なピンガーが存在することを更に決定する場合もある。一例では、ＤＯＩ所有者が確立したポリシーにより、特定されたピンガーのみがＤＯＩの有効性を確認することを要する。別の実施例は、ピンガーのレイテンシー、顧客の場所及び／またはその他を考慮した三角測量に基づいたアルゴリズムを含んでいる。最適のピンガーを決定すると、及び／またはリクエストしているピンガーを単に識別すると２０１１、ＮＱフィーダーは次のＤＯＩ解決場所をデキューし、可能性のあるピングから実際のピング・リクエストへ変換する２０１２。ピング・リクエストが決められたピンガーへ提供されると、ピングの可能性の統計がログされる２０１３。非限定的な一実施例では、ログされたピングの可能性の統計は可能性のあるピング、システム負荷、及び／またはその他の平均経時に基づいている２０１３。例えば、
新平均経時＝
（
（
（
（ＴｉｍｅＤＱ−ＴｉｍｅＮＱｏｆＴｈｉｓＤＯ
Ｉ）／＃ＤＯＩｓＩｎＯｌｄＡｖｇ
｛上の行は、ＮＱフィーダーからデキューされ
る次のアイテムが可能性のあるピング候補とし
て留まる時間を、ＮＱフィーダーの以前の可能
性のあるピングの平均経時を算出するために用
いられた可能性のあるピングの数（つまりピン
グされていないＤＯＩ場所解決）で割る。｝
）
＋ ＯｌｄＡｖｇＴｉｍｅ
｛上の行はＮＱフィーダーの以前の可能性のあ
るピングの平均経時を前行の結果に加算す
る。｝
）／＃ＤＯＩｓＮＯＷ
｛上の行はＮＱフィーダーに残っている可能性
のある新しいピングの数で前行の結果で割
る。｝
）
上記計算の結果が、あるＮＱフィーダーにおける全てのピングの可能性の新しい平均経時である。もちろん、これは一つのフィーダーの統計にすぎず、無数のその他の統計がポリシーによって用いたり及び／または確立したりできる。その他の統計は、システム負荷、接続バンド幅、利用可能なメモリ及び／またはその他を含む。そのようなフィーダー統計はログされて、リクエストに応じてマイナーに提供され、故にマイナーは図１９と全体にわたって記載されたように、どのピンガーを用いるべきかを決定できる２０１３。代わりに、フィーダーはログ統計及び／またはキューの長さを用いて、より多くのＮＱメッセージまたはより少ないＮＱメッセージを得るためにマイナーへリクエストすることを決定することに役立ててもよい。
ＮＱメッセージが検出された場合は２００５、ＮＱフィーダーはオプションとして、キューに対する新しいエントリーがすでにリストに存在しているかを決定する２００６。言い換えれば、ＤＯＩ解決場所がすでにＮＱフィーダーのキューにてエンキューされている場合は２００６、キューにある古いエントリーは置き換えられ、よって新しいエントリーが、ＤＱＡＳデータベースにある現在のＤＯＩ記録から最新の関連したエラー、更新された最新の成功したピングの値等を持つことができる２００７。しかしながら、ＮＱリクエストがリストに既に存在しない場合、及び／または複製エントリーが置き換えられた場合は２００７、ＮＱフィーダーはＤＯＩ解決のためのピング統計を入手する２００８。別の実施例では、ＮＱフィーダーはＤＱＡＳへの元のクエリーに伴うピング統計を入手している２００３。ピング統計を入手すると２００８、ＮＱフィーダーはキューにおけるＮＱリクエストの位置を決定する２００９。一実施例では、キューはスタックの形式を取り、Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ（ＦＩＦＯ）データ・フローが用いられる。別の実施例では、キューはスタックの形式を取り、Ｆｉｒｓｔ Ｉｎ Ｌａｓｔ Ｏｕｔ（ＦＩＬＯ）データ・フローが用いられる。別の実施例では、キューはハッシュ・テーブル、リンクされたリスト及び／またはキューの形式を取り、重要度によるランクがアイテムがエンキューされデキューされる順序を決定する。一実施例では図１８に図示されたように、重要度が高いアイテムはキューの最後の方にソートされ、キューの最後の方からデキューされる。ＮＱリクエストの位置を決定すると２００９、ＮＱフィーダーはＮＱリクエストを決められた場所へとキューに挿入する２０１０。エンキューすると２０１０及び／またはピングの可能性をログすると２０１３、ＮＱフィーダーは終了イベントが発生したかを決定する２０１４。終了イベントが発生しなかった場合は、ＮＱフィーダーは、終了イベント２０１４が検出され、その段階で実行が終了する２０１５まで、次のクロンのイテレーション２００１、２００２を待つか、及び／または実行を継続する２００３。
［デキュー・フィーダー］
図２１は、品質保証デキュー・フィーダー（ＤＱフィーダー）の非限定的な一例のフロー・ダイヤグラムを図示している。オプションとして、ＤＱフィーダーは、特定された周期的な時間間隔２１０１においてクロン・ジョブを通じて設定される様々な時間間隔で作動できる。ＤＱフィーダーが特定された時間に作動する場合は、ＤＱＡＳはＤＱフィーダーの作動時間が経過したかを決定する２１０２。もし経過していない場合は、ＤＱＡＳは特定された時間が来るまで調べ続ける２１０２。代わりに、ＤＱフィーダーが継続的に作動することも、または単一イテレーション作動することも可能である。また、ＤＱフィーダーは必要に応じて、例えばユーザーから及び／またはシステム・リクエストから実行されてもよい。
インスタンス化され実在する状態になると、図２０でＮＱフィーダーが決定する２０１１のと同様に、ＤＱフィーダーは利用可能な最適のピンガーを決定する２１０３。最適のピンガーを決定するか、及び／またはリクエストしているピンガーを単に識別すると２１０３、ＤＱフィーダーは、次のＤＯＩ解決場所をデキューし、可能性のあるピングから実際のピング・リクエストへ変換する２１０４。ピング・リクエストを決められたピンガーへ提供すると２１０４、図２０でＮＱフィーダーが決定する２０１３のと同様に、ピングの可能性の統計がログされる２１０５。ピングの可能性２１０５をログすると、ＤＱフィーダーは終了イベントが発生したかを決定する２１０６。終了イベントが発生しなかった場合は、ＤＱフィーダーは、終了イベント２１０６が検出され、その段階で実行が終了する２１０７まで、次のクロン・イテレーション２１０１、２１０２を待ち、及び／または実行を継続する２１０３。
［ピンガーとレスポンダ］
［ピンガー］
図２２は、ディレクトリ品質保証ピンガー・ファシリティ（ピンガー）の非限定的な一例のフロー・ダイヤグラムを図示している。ピンガー１７１６は最初に、次にピングするアイテム２２０１を入手する。ピンガーは、図２０と図２１と全体にわたって上記説明されたように、次のピング・アイテムをフィーダーから入手できる。別の実施例では、ピンガーはピングするアイテムをフィーダーからリクエストしてもよいが、これはマイナーとフィーダーの間で使用された負荷統計ログと同様の負荷統計ログを用いて、更にピングするために利用可能であることを決定してから行われる。ピンガーは受信されたピング・アイテム２２０１をキャッシュ、キュー及び／またはその他にて維持し得る。次のピング・アイテム２２０１を入手すると、その場所がピングされる２２０２。別の実施例では、ピンガーはパスワード、デジタル証明、暗号鍵及び／またはその他のセキュリティ許可を持つピング・アイテムを入手し、こうしたものがなければアクセス不可能な場所にある情報をピングすることに成功できる。そのようなセキュリティ許可は、図２５と全体にわたって詳述されるようにポリシー・マネジャー・ツールによって提供される。ピング・リクエストは、通信ネットワーク１１３上で、ターゲットへの非同期的及び／または独立したデータ・フロー・スレッドとして開始され、レスポンス・フローはレスポンス・コレクター１７２２へ戻る。場所２２０２をピングすると、ピンガーは終了イベントが発生したかを決定する２２０３。終了イベントが発生しなかった場合は、ピンガーは、終了イベント２２０３が検出され、その段階で実行が終了する２２０４まで、実行を継続する２２０１。
［レスポンス・コレクター］
ピンガー１７１６が場所２２０２をピングすると、レスポンス・コレクター１７２２は最初にピング・レスポンス２２０５を入手する。レスポンス・コレクターは受信されたピング結果２２０５をキャッシュ、キュー及び／またはその他にて維持する。ピング・レスポンス２２０５を入手すると、オプションとしてレスポンス・コレクターは、ピング結果が特定された時間内２２０８に入手されたかを決定することもできる。この決定は、分散型ＤＱＡＳ（例えば、アプリケーション内部の通信、アプリケーション相互の通信及び／またはその他）について図１で説明されたように、ピンガーとレスポンス・コレクターが情報を共有することによって達成される。一実施例では、ピンガーは全てのピングされたアイテムの時系列のリストを維持しており、このリストは、レスポンス・コレクターが全てのピングされたアイテムが特定された時間内にピング・レスポンス２２０５を受信したかを調べる２２０８ために用いられる。ピング・レスポンスがあるピングされた場所に対して入手されていない場合は２２０８、エラーがログされる２２１０。そうでなければ、返信されたピング・レスポンス（及びレスポンスの代わりにエラー・ログ・エントリー）はレスポンス解析器１７１８へ提供される２２０７。代わりに、ピング・レスポンスがＤＱＡＳデータベース１１にある生のピング結果データベースへ直接提供されてもよく、そのような実施例では、レスポンス解析器は継続的にＤＱＡＳデータベースをマイニングして、生のピング・レスポンスを適切なフィールド、例えばピング・レイテンシー、エラー・コード、情報タグ及び／またはその他に分解解析する。ピング結果は、非同期的及び／または独立したデータ・フロー・スレッドとして通信ネットワーク上でレスポンス解析器１５１８へ提供される。ピング結果及び／またはエラー結果を解析するために提供すると２２０７、レスポンス・コレクターは終了イベントが発生したかを決定する２２０８。終了イベントが発生しなかった場合は、レスポンス・コレクターは、終了イベント２２０８が検出され、その段階で実行が終了する２２０９まで、実行を継続する２２０５。
［レスポンス解析器］
レスポンス・コレクター１７２２がピング結果を提供すると２２０７、レスポンス解析器１７１８は最初にピング結果２２１０を入手する。レスポンス解析器は受信されたピング結果２２１０をキャッシュ、キュー及び／またはその他にて維持する。ピング結果２２１０を入手すると、レスポンス解析器はピング結果を解析する２２１１。レスポンス解析器は生のピング結果を適切なフィールド、例えばエラー：ＤＮＳルックアップ、ホスト、ＨＴＴＰ４０４、レイテンシー、タイム・アウト及び／またはその他；情報タグ（ＤＯＩと情報の間の関連性の有効性を確認するために組み込まれたタグを持つ情報のためのタグ）及び／またはその他）及び／またはその他に分解解析する２２１１。ピング結果を解析すると２２１１、解析されたピング結果はＤＱＡデータベース１１９にあるピング統計データベース・テーブルに保存される２２１２。解析されたピング結果を保存すると２２１２、レスポンス解析器は終了イベントが発生したかを決定する２２１３。終了イベントが発生しなかった場合は、レスポンス解析器は、終了イベント２２１３が検出され、その段階で実行が終了する２２１４まで、実行を継続する２２１０。
［エラー・プロセッサ］
図２３は、品質保証エラー・プロセッサ（エラー・プロセッサ）の非限定的な一例のフロー・ダイヤグラムを図示している。オプションとして、エラー・プロセッサは、特定された周期的な時間間隔２３０１においてクロン・ジョブを通じて設定される様々な時間間隔で実行できる。エラー・プロセッサが特定された時間に作動する場合は、ＤＱＡＳは、エラー・プロセッサの作動時間が経過したかを決定する２３０２。もし経過していない場合は、ＤＱＡＳは特定された時間が来るまで調べ続ける２３０２。代わりに、エラー・プロセッサが継続的に作動することも、または単一イテレーション作動することも可能である。また、エラー・プロセッサは必要に応じて、例えばユーザーから及び／またはシステム・リクエストから実行されてもよい。
インスタンス化され実在する状態になると、エラー・プロセッサはＤＯＩの割り当てセグメントをＤＱＡＳデータベースから入手する２３０３。言い換えれば、エラー・プロセッサは、有効性の確認を要するＤＯＩのある部分をＤＱＡＳデータベース１１９にあるエラー・テーブルから入手する。この部分はＤＱＡＳ及び／またはエラー・プロセッサによるポリシーによって確立される。エラー・プロセッサはＤＱＡＳデータベースへのクエリー・リクエストを作成する。ＤＱＡＳへリクエストするエラー・プロセッサのインスタンスが多重にある場合は、中央ＤＱＡＳによってエラー・プロセッサを管理して、同じＤＯＩ、同じデッドロック及び／またはその他のリクエストを繰り返すことを避けるようにすることもできる。そのような実施例では、多重のスレッド、多重のプロセッサ、多重のサーバーは全てＤＱＡＳデータベースに同時にアクセスして、エラー・プロセッサによる解析を要する多数になる可能性のあるピング・レスポンスを分割する。別の実施例では、単一のＤＱＡＳがＤＯＩ全ての有効性のを確認を行う。別の実施例では、単一のＤＱＡＳがＤＯＩの全ての有効性の確認を行う。一実施例では、エラー・プロセッサはＤＯＩ識別子、関連した解決場所、情報タグ識別子及び／またはその他をリクエストする。別の実施例では、ピング統計もリクエストされる。クエリー・リクエストは、最初の基準に基づいてデータベース・クエリー結果に対する最初のソートを供給してもよい２３０４。一実施例では、先に計算された有効性確認ランクはクエリー結果をソートするために用いられ、これよって最高のランク付けをされた結果が最初に有効性を確認される。他の実施例は、ピンガー、次にホスト、次にコンタクト、次にエラー・タイプ、次にＤＯＩ、次にＤＯＩ場所によるソート順序を含む２３０４。
ソートされたクエリー結果をＤＱＡＳデータベースから入手すると２３０４、エラー・プロセッサは、不良ピンガーが共通のエラーであるかを決定する２３０５。これは、ソート順序によって決定され、エラー・テーブル１１９から得た結果が同一のピンガーに対するエントリーを繰り返し、一方で、他のピンガーからクエリーされた際は、同一の解決がエラーを生成しないまたは異なるエラーを生成することとなる。単一のピンガーに対するエントリーが数多く繰り返された場合はピンガー・エラーを示し、エラー・レポートをＤＱＡＳの管理者に送るに値する２３０６。一実施例では、ピンガー・エラーが決定された際は２３０５、全ての返信されたピンガー・エラー２３０４は不良ピンガー・エラーとしてフラッグされ、そのようなエラーは、ユーザーへのエラー・レポートには含まれてはおらず、よってＤＱＡＳ管理者は、ＤＯＩ所有者を間違ったアラームで過度に邪魔することなくピンガー・エラーを直すことができる。
エラー・レポートを管理者に送るか２３０６、または不良ピンガーが一つも検出されない場合は２３０５、オプションとしてエラー・プロセッサは不良ＤＯＩ解決場所サーバーが共通のエラーであるかを決定する２３０７。これは、エラー・テーブル１１９から得た結果が、ＤＯＩが解決される同一のサーバー・ホスティング情報のためのエントリーを繰り返すソート順序によって決定される。単一のホストに対してエントリーが数多く繰り返される場合はＤＯＩ記録におけるエラーではなく、ホスト・エラーを示し、エラー・レポートをホストの管理者に送るに値する２３０８。一実施例では、ホスト・エラーが決定された際は２３０７、全ての返信されたホスト・エラー２３０４は不良ホスト・エラーとしてフラッグされ、そのようなエラーは、ユーザーへのエラー・レポートには含まれてはおらず、よってホスト管理者は如何なるホスト・エラーをも直すことができる。
エラー・レポートを管理者に送るか２３０６、２３０８、または不良ピンガーまたは不良ホストが一つも検出されない場合は２３０５、２３０７、エラー・プロセッサはデータベース・セグメントの返信されたクエリー結果の中の各コンタクトに対してイテレーションする２３０９。別の実施例では、コンタクト別にイテレーションするのではなく、エラー・プロセッサは発行者別及び／または他の識別するフィールド別にイテレーションすることができる。ＤＱＡＳデータベース１１９のメタデータ・テーブルにあるコンタクト・メタデータを介して、及び／または図１７のポリシー・マネジャー１７３１から、コンタクト情報を入手できる。コンタクト情報は、任意のＤＯＩ及び／または発行者についてコンタクトする人及び／またはエンティティを識別する。返信された結果２３０９にある各コンタクトに対して、エラー・プロセッサはエラー・レポートを作成することができる２３０９。一実施例では、最初にレポートを作成することは、単にエラー・レポートのタイトル、コンタクト・メタデータ情報及び／またはその他を持つＸＭＬファイルのためにメモリにスペースを割り当てることを伴う。
最初にコンタクトに対するエラー・レポートをインスタンス化すると２３１０、エラー・プロセッサは各コンタクトに対する各エラー・タイプに対してイテレーションする２３１１。従って、そのような各エラー・タイプに対して２３１１、エラー・プロセッサは各コンタクトに対する２３０９各エラー・レポート２３１０にエラー・タイプ・エントリーを作成する２３１４。レポートにエラー・タイプ・エントリーを作成すると２３１４、エラー・プロセッサはＤＯＩが参照する各場所２３１５に対してイテレーションする２３１５。従って、ＤＯＩが参照する各場所２３１５に対して、エラー・プロセッサは各コンタクト２３０９に対する各エラー・レポート２３１０にあるエラー・タイプ・エントリー２３１４にエラー場所エントリー２３１６を作成する。一実施例では、エラー場所エントリーはエラーの日時、エラーを決定する役割を果たしたピンガー及び／またはその他を含む。エラー場所エントリー２３１６をコンタクトのエラー・レポートに作成すると、エラー・プロセッサは、ＤＯＩが参照した現在イテレーションした場所２３１７が体験したエラーの数を計算するが、これはＤＯＩが参照した場所の以前のエラー・カウントに「１」を加算して計算される。現在イテレーションした場所２３１７が体験したエラーの数を計算すると、エラー・プロセッサは、現在のＤＯＩ２３１５に対してＤＯＩが参照する次の場所をイテレーションする。
全ての場所がイテレーションされた際は２３１５、ループが終了し、エラー・プロセッサはそのＤＯＩに対するポリシーを実行する２３９９。このポリシーはどのようにエラー訂正、エラー通知、レポートのエスカレーション及び／またはその他が各ＤＯＩ２３１５に対して行われるべきかを確立する。ＤＯＩの全ての場所に対してポリシーを実行すると２３１５、２３９９（図２４に更に詳述が続けられている）、フローは実行されたポリシーから戻る２３８８。合計数は全てＤＯＩループ２３１５の最後に実施される。どのレポートするポリシーの実行から戻ってきた時でも２３８８、ＤＯＩループが終了し、次のエラー・タイプ・エントリーがイテレーションされる２３１１。全てのエラー・タイプがイテレーションされた際は２３１１、ループが終了し、エラー・プロセッサは、生成されたエラー・レポートを送るフラッグ（ＳｅｎｄＥｒｒｏｒＲｅｐｏｒｔＦｌａｇ）が「はい」に設定されているかを決定する２３１２。「はい」に設定されている場合は、終了したエラー・レポートがコンタクト２３１３へ送られる。レポートを送るフラッグが「はい」に設定されていない場合は、次のコンタクトがイテレーションされる２３０９。合計数の算出も全てエラー・タイプ・ループの最後に２３１１実施され、送られる前にエラー・レポートに提供される。全てのコンタクトがイテレーションされた際は２３０９、コンタクト・ループが終了し、エラー・プロセッサはは終了イベントが発生したかを決定する２３１８。終了イベントが発生しなかった場合は、マイナーは、終了イベント２３１８が検出され、その段階で実行が終了する２３１９まで、次のクロンイテレーションを待つか２３０１、２３０２、及び／または実行を継続する２３０３。
［ＤＱＡＳポリシー例］
図２４は、品質保証エラー・レポート・ポリシー（ポリシー）の非限定的な一例のフロー・ダイヤグラムを図示している。最初に、ポリシーは図１７のエラー・プロセッサ１７１９と図２３のエラー・プロセッサ２３９９に呼び出される２４９９。このポリシーはエラー・プロセッサに統合され、ＤＱＡＳデータベース１１９にあるポリシー・テーブルから入手される。ポリシー・マネジャー１７１３は様々なポリシーを作成するために用いられる。ポリシーを呼び出した２４９９後、エラー・プロセッサは、図２３のエラー・プロセッサ２３１７が計算した現在のエラーの数が１より小さいか、つまり、エラーが一つもないか、を決定する２４０１。エラーが一つもない場合は２４０１、ＳｅｎｄＥｒｒｏｒＲｅｐｏｒｔＦｌａｇは「いいえ」に設定され２４０２、このポリシーが終了し２４８８、実行フローは図２３の呼び出し２３８８地点に戻る。エラーがある場合は２４０１、ＳｅｎｄＥｒｒｏｒＲｅｐｏｒｔＦｌａｇは「はい」に設定される２４０３。
次に、エラー・プロセッサは、図２３のエラー・プロセッサ２３１７が計算した現在のエラーの数が１より大きいか、つまり、エラーが少なくとも二つあるか、を決定する２４０１。エラーが一つしかない場合は２４０４、つまり、現在のエラー数が１より大きくない場合は、ポリシーが終了し２４８８、実行フローは図２３の呼び出し２３８８地点に戻る。二つ以上のエラーがある場合は２４０４、エラー・プロセッサは、図２３の現在のエラー・タイプ２３１１がＨＴＴＰ４０４であるか、及び／またはＤＮＳルックアップ・エラー２４０５であると検証されるかを決定する。検証された４０４及び／または検証されたＤＮＳエラーである場合は２４０５、次にエラー・プロセッサは、バックアップ解決場所が存在するかを決定する２４０６。一実施例では、強化ＤＯＩはバックアップ場所を有し、バックアップ場所にはそのＤＯＩが表わす情報が保存される。例えば、強化ＤＯＩが二つのバックアップ（例えばＢａｃｋｕｐ．１＠１０．１２３／ａｂｃｄｅｆ、Ｂａｃｋｕｐ．２＠１０．１２３／ａｂｃｄｅｆ）を有すると、各フォーマットはそれに関連した解決場所を有する（例えば、それぞれ、バックアップ１にはｗｗｗ．ｌｏｃａｔｉｏｎ．ｃｏｍ／ｂａｃｋｕｐ１、バックアップ２にはｗｗｗ．ｌｏｃａｔｉｏｎ２．ｃｏｍ／ｂａｃｋｕｐ２）。バックアップが存在する場合は２４０６、エラー・プロセッサは図２３の現在のＤＯＩ場所２３１５の解決のバックアップ場所への変更を実行する。例えば、情報（ｗｗｗ．ｌｏｃａｔｉｏｎ．ｃｏｍ／ｄａｔａ）に対する第一のＤＯＩの（１０．１２３／ａｂｃｄｅｆ）通常の場所が、二回目には利用不可能であるとエラー・プロセッサによってレポートされると、ポリシー２４０７は新しい関連性を実行する。すなわち、第一のＤＯＩのバックアップ場所は一時的に第一のＤＯＩを解決するように設定される（例えば１０．１２３／ａｂｃｄｅｆはｗｗｗ．ｌｏｃａｔｉｏｎ．ｃｏｍ／ｂａｃｋｕｐ１へと解決されるように設定される）。この一時的な解決の変更は、登録機関によってハンドル・システムにある参照更新を実行することによって達成される。
しかしながら、バックアップ強化ＤＯＩが存在しない場合か２４０６、またはレイテンシー・エラーがある場合か２４０９、またはタグ・エラーがない場合は２４１０、ＤＯＩの解決が、ＤＱＡＳに提供されるプロキシ・エラー・ページ２４０８へと変更される。エラー・ページ２４０８はＤＱＡＳ及び／または登録機関にて維持されているウェブ・ページである得る。エラー・ページは、リクエストされたＤＯＩが技術的困難に陥っているという通知、ＤＯＩは一時的に利用不可能であるという通知、ユーザーがアクセスを望んでいる場所へのリンクが問題を抱えている可能性がることをユーザーに知らせる通知、ウェブ・ページが自動的に正しい場所にリダイレクトしようと試みているという通知、ウェブ・ページが発行者はもはや存在せず、ＤＯＩの最新の既知のコンタクト情報を知らせる通知、及び／またはその他を提供することができる２４１３。現在のエラーが識別されていないタグ・エラーではない場合は２４１０、全ての他のエラー・タイプが、キャッチオールとしてプロキシ・エラー・メッセージによって取り扱われる２４０８。しかしながら、現在のエラーがタグ・エラーではない場合は２４１０、エラー・プロセッサは現在のＤＯＩ場所に対するＤＯＩメタデータを入手して、メタデータをＤＯＩが参照する場所における情報と比較することができる。タグ・エラーが起こりうるのは、ユーザーが、エラー・プロセッサがＤＯＩによって参照された現在の場所が利用可能であるかを決定することのみならず、場所が実際に正しい関連した情報を保存することをリクエストする時である。別の実施例では、エラー・プロセッサは、比較のために情報及び／またはドキュメントに組み込まれたＤＯＩ番号を持つタグを探す。メタデータ及び／またはタグを比較すると、エラー・プロセッサは、ＤＯＩが参照した場所にある情報が正しい情報であることがどれ程あり得るかを表す確信度ランク付けを決定する。エラー・プロセッサが５０％以上確信していない場合は２４１２、ＤＯＩ解決はプロキシ・エラー・ページ２４０８へと変更される。しかしながら、エラー・プロセッサが５０％以上確信している場合は２４１２、エラー・プロセッサは、その情報に対するＤＯＩ検証タグを生成し、ＤＯＩ検証タグは任意のエラー・レポートと、生成されたタグ２４１３を追加する旨の指示と共に送られることとなる。この情報に対するＤＯＩ検証タグの生成は、ＤＯＩというフィールドと、コンテンツの関連したＤＯＩを持つエントリーとを持つＸＭＬタグを組み込むことをユーザーに知らせるだけで達成される２４１３。別の実施例では、エラー・プロセッサは、ターゲット情報のファイルに基づいてハッシュ、チェックサム、鍵及び／またはその他を計算する２４１３。一実施例では、そのようなタグを追加する指示は、ファイルの最後に単にタグを付け加わることである２４１３。一実施例では、この指示はエラー・レポートの一部として送られる２４１３。
更なる別の実施例では、タグは登録ツールを介してＤＯＩを登録する際に生成される。そのような実施例では、ハンドル・システムにＤＯＩを安全に登録すると、そのＤＯＩは入手され、実際のコンテンツにタグとして組み込まれる。そのような実施例では、登録ツールは、タグ・コードをソースのローカル・コピーへと付け加わえ、例えば「＜ＳＯＵＲＣＥ ＴＡＧ ＶＡＬＩＤＡＴＯＲ＞１０．１２３／ａｂｃｄｅｆｇ＜／ＳＯＵＲＣＥ ＴＡＧ ＶＡＬＩＤＡＴＯＲ＞」といったＤＯＩを含むＸＭＬタグを持ったファイルを作成し、ＵＮＩＸのｃａｔオペレーションを用いてタグをソースへと付け加わえる。それ以降、登録ツールは、ＤＯＩに対する全ての解決場所へ新しい修正されたソースを実行し伝搬し、よってソースの利用可能性の有効性を確認することを可能にするソースのタグ付けされたバージョンが提供される。更に別の実施例では、タグ付けされたソースは自動的に記憶ファシィリティによってホストされる。そのような自動的ホスティングが求められるのは、ソースが如何なる場所でも未だに利用可能ではない場合や、及び／またはユーザーが新しい場所でソースを利用可能にすることを望む場合である。
ＤＯＩ場所解決を変更し２４０７、解決をプロキシ・エラー・ページへと変更し２４０８、及び／または実際のコンテンツのためのＤＯＩ検証タグを生成すると２４１２、エラー・プロセッサは二つより多くのエラーがあるか２４１２、つまり三つ以上のエラーがあるかを決定し、その後通知がエスカレートされ、電話でコンタクトを自動ダイアルする２４１５。コンタクトは、コンタクト情報をＤＱＡＳデータベースにあるメタデータ・データから探すると、ダイアルされる。ダイアル・アウトは留守番電話と付いた電話モデム及び／またはその他によって達成することができる。二つより多くのエラーがない場合は２４１４、ポリシーは終了し２４８８、実行フローは図２３の呼び出し２３８８の地点に戻る。電話コンタクトを呼び出すと２４１５、エラー・プロセッサはこれが三番目のレイテンシー・エラーであるかを調べる２４１６。レイテンシーに対する二つより多くのエラー２４１４がある場合は２４１６、エラー・マネジャーはＤＯＩに対する解決を変更して、キャッチオール・プロキシ・エラー・ページ２４０８と同様にレイテンシー・プロキシ・エラー・ページ２４１７へとポイントする。しかしながら、このレイテンシー・プロキシ・エラー・ページを使ってユーザーは電子メールのフィールドに電子メールアドレスを入力することができ、リクエストしたＤＯＩが参照したコンテンツ２４１７がユーザーに電子メールされる。
ＤＯＩ場所解決を変更すると２４１７、エラー・プロセッサは三つより多くののエラーがあるか２４１８、つまり四つ以上のエラーがあるかを決定し、その後通知は、今度人によるコンタクトを追跡するＤＱＡＳエージェントへエスカレートされ、ＤＯＩの正しい解決を実行する２４１９。三つより多くのエラーがない場合か２４１８、またはＤＱＡＳエージェントがコンタクトされた２４１９場合は、ポリシーは終了し２４８８、実行フローは図２３の呼び出し２３８８の地点に戻る。
［ポリシー・マネジャー］
図２５は、ポリシー・マネジャー・ツールの非限定的な一例を図示している。ポリシー・マネジャー・ツールはウェブ・ページ２５７５で具現され、ウェブ・ブラウザを介して実行される。ポリシー・マネジャー・ツールは例えばテキスト・ボックス、ポップアップ・メニュー及び／またはその他といった標準画像ユーザー・インターフェース・ウィジェトを用いることができる。ウィジェトは、ユーザーがコントロールしたカーソル選択２５３２及び／またはテキスト挿入ツール２５３３に反応するように構成されている。様々なユーザー・インターフェース・ウィジェトが、ここに利用するどの例のウィジェトのファシリティとでも代替して用いることができることを理解すべきである。例えば、ポップアップ・テキスト・エントリー・メニュー２５０４を、ここ及び本開示全体にわたって記載されているプレーン・テキスト・フィールド及び／またはその他と置き換えてもよい。
一実施例では、ユーザーはデータベース１１９をクエリーして、所望するＤＯＩのポリシーを入手することとなる２５０１。一実施例では、このポリシーは、発行者プレフィックス一般に当てはまるポリシー２５２１、プロファイルに保存されたテンプレート・ポリシー２５２２、またはポリシー・マネジャーにて特定されたカスタム・ポリシー２５２２を利用して継承してもよい２５７５。
カスタム・ポリシー２５２２を特定する際は、ユーザーは、ＤＱＡＳから通知を受信する２５０３、２５０７多重のコンタクトを特定できる。描写された実施例では二つのコンタクトが提供されるが、他の実施例では、より少ないコンタクトまたはより多いコンタクトがを想定している。コンタクトは名前、電子メール、電話番号及び／またはその他によって特定される。別の実施例では、アドレス、ファックス、ポケットベル及び／またはその他を通知目的でコンタクト情報２５０３、２５９７に追加してもよい。
各コンタクトに対してユーザーは、チェック・ボックスを選択してモードを２５５５、ポップアップ・メニューから選択を選んで通知優先を２５５６、同じくポップアップ・メニューによって時間制限を２５５７特定することができ、これら全てはそのコンタクトへの通知のポリシーを確立する。モード・チェック・ボックスを選択することにより、コンタクトを例えば電子メール２５０４、勤務先の電話２５０５、ポケットベル２５０６及び／またはその他といった、どのモードによって通知するかを決定する。通知優先オプション２５５６を選択することによってユーザーは、例えば最初のエラーがレポートされた時点、平日の午前８時から午後５時にエラーが発生した時はいつでも、最初の電子メール通知から一時間以内に電子メール・レスポンスがＤＱＡＳによって受信されていない場合、最初の電子メール通知から三時間以内に電子メール・レスポンスがＤＱＡＳによって受信されていない場合及び／またはその他のような場合にコンタクトが通知を望むかどうかを特定することができる２５１７。また、通知２５５６、２５５７への時間制約２５５７を、ユーザーが確立することもできる。通知は四六時中、または平日の午前８時から午後５時までの間に発行できる。もちろん、別の実施例ではこれらの制約は異なり、秒、分、時間、日、週、月、年及び／またはその他の時間制限の個々の特定が可能である。同様に、通知優先はモードと共に変えることができる。
任意のエスカレート順序で特定可能な通知モードの階層分け（つまり、電子メール、ファクシミリ、ポケットベル、電話、音声メッセージ、人によるコンタクト等）に加えて、ＤＱＡＳエージェントにはＤＯＩ所有者を代表してエラー・レポートを取り成し管理すべく通知することができることに注意することが重要である。そのような実施例では、ＤＱＡＳエージェント（例えばシステム・オペレーター、管理者及び／またはその他）はレポートを受信し、エラーの原因をトラブルシューティングすることもある。一実施例では、そのようなエージェントはＤＯＩ所有者のＤＯＩで参照したコンテンツへのアクセスができ、ＤＯＩ所有者とは独立して、及び／またはＤＯＩ所有者の監視の下でアクセス権についての問題を改善を試みることができる。問題を管理すると、ＤＱＡＳエージェントはＤＯＩ所有者にサービス活動をレポートするステータスを提供する。そのような委任された管理は契約期間によって及び／または出来事毎に請求できる。こうして委任することによって、ＤＯＩ所有者を殺到するエラー・レポートから開放することにもなる。もちろんＤＯＩ所有者は、任意の特定された期間エラー・レポートの停止をリクエストすることもできる。
そのような委任された管理システムは、情報共有システム、例えばＬｏｔｕｓＮｏｔｅｓ及び／または市販のソフトウェア及び／または特注開発されたソフトウェアといったものを利用し、そこにステータス通知を転送するようにすることによって可能なものとなる。各テータス通知には、請求と管理目的でジョブ・チケット番号が与えられる。そのような一実施例では、ジョブ・チケット番号がＤＯＩ自体であってもよい。他の実施例では、ステータス通知はコンタクト情報を含むこともあり、コンタクト情報はメタデータ・データベース及び／またはその他から入手可能である。
ユーザーはまた要約レポート２５１０を一定の時間制限２５５７、２５１１内に生成するようにも特定できる。要約レポートは、一日一回（週七日）作成するか２５１１、特定された日に週一回作成するか、ほぼ如何なるその他考えられる間隔にて作成できる。特定されたコンタクトと特定されたＤＯＩのコンタクトとポリシー情報がエントリーされると、ユーザーは、コンタクト情報を加えるファシリティ（例えばコンタクト追加ボタン２５１２）を作動させることによって、ＤＱＡＳデータベース１１９へのポリシーの保存を実行にし、これによってポリシー・マネジャー・ツールは、ポリシーを保存するためにＤＱＡＳデータベースへ送信することができる。
一実施例では、ポリシー・マネジャー２５７５は品質保証設定２５８５、例えば加入コントロール２５８６、ピング設定２５８７、エラー追跡のアクセス２５８８及び／またはその他を設定する能力を提供する。加入アクセスと方法コントロール２５８６を追加することにより、ユーザーは、テストされているＤＯＩ参照場所が、セキュリティ許可２５０８なしで一般が利用可能な情報であるか、ＤＯＩ参照情報２５０９のホストをピングするために特定したＩＰアドレスを持つ特定されたピンガーからのテストに限定されるのか、セキュリティ許可を要する情報にピンガーがアクセスできるようにするＰＯＳＴコマンドを発行するために用いられるユーザー名とパスワードを要するのか２５１３、クッキー・アクセスを介したファイルに基づいた他のセキュリティ許可を要し、それによってユーザーが例えばユーザー名、パスワード、デジタル証明、暗号鍵及び／またはその他といったセキュリティ許可を含むクッキーを特定できるのか２５１４及び／またはその他を、特定することができる。一旦作動された「Ｐｏｓｔ ＣｏｏｋｉｅＤａｔａ．．．」ファシリティは、ファイル選択ファシリティを表示し、そこでユーザーが必要なセキュリティ許可情報を識別することが可能となる。
ＤＯＩ所有者はセキュリティ許可を使って、及び／またはセキュリティ許可を使わずにＤＯＩソースへアクセスする有効性を確認したいと望むことがあることに注意すべきである。例えば、ＤＯＩ所有者はコンテンツ毎に支払うオペレーションを実行していて、コンテンツのピング・テストをして、正しいアクセス不能なラーが返信されることを確認したいと望むかもしれないし、またはその代わりにＤＯＩ所有者は、例えばアクセスすると支払いをリクエストするＵＲＬといった他の場所へと解決するようにして、そのアクセス毎には料金を支払わないことを望むかもしれない。別の例では、ＤＯＩ所有者は料金を請求するコンテンツに対してアクセス可能かどうかをテストし、アクセスの有効性を確認したいと望み、従ってＤＱＡＳは正しくコンテンツの有効性を確認するためのパスワード及び／または他のセキュリティ許可を提供しなければならない。一実施例では、ＤＱＡＳは例えばセキュリティ許可された有効性確認に対しては余分に料金を請求するというように、セキュリティ許可された有効性確認に対して異なる料金を請求することもできる。
一実施例では、ポリシー・マネジャーによってユーザーは、ピングする時間間隔と用いられるピンガーの地理的場所を調整して２５１５ピングの設定２５８７を定めることができる。また、ポリシー・マネジャーによってユーザーは、ＤＱＡＳ２５１６からの様々なエラー・ログへ手動でアクセスすることを選択してエラー追跡にアクセスする２５８８こともできる（例えば、ユーザーがトラブル・データベースへのウェブ・アクセスを許しＸＭＬに基づいたエラー・ログ及び／またはその他を生成するポリシーを構築することを可能にする２５１６）。
ここで理解すべきことは、上記の記載は単に実施例の説明のためだけのものであるということである。読者の便宜上、上述の記載は、本発明の原理を教える上でのサンプルで、全ての可能な実施例の内の代表的なサンプルに焦点をあてたものである。記載にあたっては、可能なバリエーションの全てを徹底的に列挙したわけではない。本発明の特定の部分に対して実施例を他に示さなかったこと、または、ある部分に関して記載されていない他の実施例があり得ることが、これらの他の実施例を否認することになる、と考えるべきではない。記載されていない実施例の多くは本発明と同じ原理のものであり、またあるものは同様のものであると理解できる。従って、ここに示されたり記載されたりした実施例及びそのバリエーションは、単に本発明の原理を示すものであり、種々の変更が本発明の範囲及びその精神から逸脱することなく実施できるということを理解するべきである。

Claims (25)

1. 入力部と、インターネットに接続された通信部と、ユニバーサル・ネーム識別子と場所アドレスとの関連を格納したメモリとを備えたコンピュータを用いて場所アドレスの有効性を確認する方法であって、
   ソースのための固有で永続的なユニバーサル・ネーム識別子を前記入力部又は前記通信部を介して受け取る工程と、
   前記受け取り工程で受け取った前記ユニバーサル・ネーム識別子に基づいて前記メモリから前記固有で永続的なユニバーサル・ネーム識別子を持つ解決のためのソースの場所アドレスを取得する工程と、
   前記取得工程で取得若しくは前記ソースに含まれるべき前記場所アドレスを識別する情報を前記通信部を介して取得して解析することによって前記場所アドレスへアクセス可能であることの有効性を確認する工程とを有することを特徴とする方法。
2. 前記確認工程において、品質保証テストとしてのトリガ・イベントが有効性を与えることを特徴とする請求項１に記載の方法。
3. 前記確認工程は、該ソースに組み込まれて情報の有効性を確認するのに使用されるタギング・コードを認識することに基づくことを特徴とする請求項１に記載の方法。
4. 場所アドレスにおいて該ソースへアクセス可能であることの有効性を確認する工程を更に有することを特徴とする請求項１に記載の方法。
5. 有効性に関するステータス通知を提供する工程を更に有することを特徴とする請求項１に記載の方法。
6. 該ステータス通知が、該固有で永続的なユニバーサル・ネーム識別子の有効性に関するものであることを特徴とする請求項５に記載の方法。
7. 該ステータス通知が、該場所アドレスの有効性に関するものであることを特徴とする請求項５に記載の方法。
8. 該ステータス通知が、該ソースの有効性に関するものであることを特徴とする請求項５に記載の方法。
9. 該ステータス通知が、エラー管理のための委任エージェントへ提供されることを特徴とする請求項５に記載の方法。
10. 該ステータス通知が、ポリシーに支配されることを特徴とする請求項５に記載の方法。
11. 有効性を確認することが、該場所アドレスをピングすることによって達成されることを特徴とする請求項１に記載の方法。
12. ピングすることが、安全化されたソースへのアクセスを可能にするセキュリティ許可を含むことを特徴とする請求項１１に記載の方法。
13. 前記タギング・コードは、一つの固有で永続的なユニバーサル・ネーム識別子の登録中に形成されることを特徴とする請求項３項に記載の方法。
14. 前記タギング・コードは、該ソースの作成中に形成されることを特徴とする請求項３に記載の方法。
15. タギング・コードを決定し、該タギング・コードが一旦認識された際は、ソースの有効性を確立する工程と、
    該タギング・コードでソースを一つタグ付けする工程と、
    該ソースと関連する固有で永続的なユニバーサル・ネーム識別子を一つ生成する工程と、
    該ソースのための場所のアドレスを一つ受信する工程と、
    該ソースの場所と関連した該アドレスを持つ該固有で永続的なユニバーサル・ネーム識別子の、関連したソースの固有で永続的なユニバーサル・ネーム識別子と関連したソースの場所を解決するための一つのデータベースへの登録を実行し、該固有で永続的なユニバーサル・ネーム識別子が、該データベースにて固有である工程とを有し、コンピュータを用いて登録を実行することを特徴とする方法。
16. 該場所アドレスへアクセス可能であることの有効性を確認する工程を更に有することを特徴とする請求項１５に記載の方法。
17. 前記確認工程において、品質保証テストとしてのトリガ・イベントが有効性を与えることを特徴とする請求項１６に記載の方法。
18. 該ソースに組み込まれた該タギング・コードを認識することによって該ソースの有効性を確認する工程を更に有することを特徴とする請求項１５に記載の方法。
19. タギング・コードを決定し、該タギング・コードが一旦認識された際は、ソースの有効性を確立する工程と、
    該タギング・コードでソースを一つタグ付けする工程と、
    該ソースのための記憶ファシリティ内にスペースを割り当てる工程と、
    通信ネットワーク上で該割り当てられたスペースの場所をアドレス可能でアクセス可能にする工程と、
    該ソースを該割り当てられたスペースへ保存する工程と、
    該ソースと関連する固有で永続的なユニバーサル・ネーム識別子を一つ生成する工程と、
    該ソースが保存されている該場所と関連した一つのアドレスを持つ該固有で永続的なユニバーサル・ネーム識別子の、関連したソースの固有で永続的なユニバーサル・ネーム識別子と関連したソースの場所を解決するための一つのデータベースへの登録を実行し、該固有で永続的なユニバーサル・ネーム識別子が該データベースにて固有である工程とを有し、コンピュータを用いて登録を実行することを特徴とする方法。
20. 該タギング・コードが、セキュリティ許可メカニズムであることを特徴とする請求項１９に記載の方法。
21. 該ソースに組み込まれた該タギング・コードを認識することによって該ソースの有効性を確認する工程を更に有することを特徴とする請求項１９に記載の方法。
22. 前記確認工程において、品質保証テストとしてのトリガ・イベントが有効性を与えることを特徴とする請求項２１に記載の方法。
23. 該場所アドレスへアクセス可能であることの有効性を確認する工程を更に有することを特徴とする請求項１９に記載の方法。
24. ソースのための記憶ファシリティにてスペースを割り当てることと、
    通信ネットワーク上で該割り当てられたスペースの一つの場所へアドレス可能でアクセス可能にすることと、
    該ソースを該割り当てられたスペースへ保存することと、
    該ソースと関連する固有で永続的なユニバーサル・ネーム識別子を一つ生成することと、
    該ソースが保存されている該場所と関連した一つのアドレスを持つ該固有で永続的なユニバーサル・ネーム識別子の、関連したソースの固有で永続的なユニバーサル・ネーム識別子と関連したソースの場所を解決するための一つのデータベースへの登録を実行し、該固有で永続的なユニバーサル・ネーム識別子が、該データベースにて固有であることと、
    該ユニバーサル・ネーム識別子のためのメタデータを受信し、該メタデータが該固有で永続的なユニバーサル・ネーム識別子について説明的なデータを提供することと、
    該固有で永続的なユニバーサル・ネーム識別子と該メタデータがお互いにより識別可能になるように、該固有で永続的なユニバーサル・ネーム識別子を該メタデータに関連付けることと、
    多重段階登録コミットメントの内一つの段階において、該固有で永続的なユニバーサル・ネーム識別子の登録を実行する前に、メタデータをメタデータ・データベースに登録することと、
    該メタデータが該メタデータ・データベースへの登録に失敗した場合にエラーを一つ生成することと、
    多重段階登録コミットメントの内もう一つの段階において該データベースに該固有で永続的なユニバーサル・ネーム識別子を登録することと、
    該固有で永続的なユニバーサル・ネーム識別子が該データベースへの登録に失敗した場合にエラーを一つ生成することと、
    多重段階登録コミットメントの内更にもう一つの段階において該ソースの有効性を確認することと、
    該有効性の確認が失敗した場合にエラーを一つ生成することと、
    該多重段階登録コミットメントの何れかの段階でエラーが生成された場合、該固有で永続的なユニバーサル・ネーム識別子の登録に失敗することと、
    から成る、コンピュータを用いてソースにアクセスする方法。
25. 該多重段階登録コミットが、メタデータを登録することと、固有で永続的なユニバーサル・ネーム識別子を登録することと、該ソースの有効性を確認することから成る最低３つの段階コミットメントであることを特徴とする請求項２４に記載の方法。

Images