JP4681643B2 - 情報アクセスを実行する多重解決のための装置、方法及びシステム - Google Patents

Description

本出願では以下の米国特許仮出願に対して、ここに優先権を主張する。（１）２００１年１月２５日に申請された、シリアル番号６０／２６４，３３３の「ＤＯＩとのレファレンス・リンキング」（弁護士ドケット番号４１８８−４００１）、（２）２００１年２月１４日に申請された、シリアル番号６０／２６８，７６６の「情報アクセスを実行する多重解決（マルチプル・レゾリューション）のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００２）、（３）２００１年３月１６日に申請された、シリアル番号６０／２７６，４５９の「情報アクセスを実行する登録のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００３）、（４）２００１年３月２９日に申請された、シリアル番号６０／２７９，７９２の「ディレクトリの品質保証のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００４）、（５）２００１年７月１０日に申請された、シリアル番号６０／３０３，７６８の「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５）、（６）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７５の「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５ＵＳ１）、（７）２００１年２月８日に申請された、シリアル番号６０／２６７，８７５の「情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００６）、（８）２００１年２月９日に申請された、シリアル番号６０／２６７，８９９の「情報にアクセスするのための装置、方法及びシステムのための仮申請」（弁護士ドケット番号４１８８−４００７）、（９）２００１年２月２１日に申請された、シリアル番号６０／２７０，４７３の「ＤＯＩのためのビジネス・バリューと実施の考慮」（弁護士ドケット番号４１８８−４００８）、（１０）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７４の「ピア環境において情報アクセスを実行するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１０）、（１１）２００１年１０月９日に申請された、シリアル番号６０／３２８，２７０の「情報アクセスを追跡するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１１）。これらの出願書はそれぞれ参照により開示に含まれる。

本出願書にはまた、以下の特許協力条約（ＰＣＴ）出願も参照により含まれる。（１２）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「情報アクセスを実行する登録のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００３ＰＣ）、（１３）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「ディレクトリ品質保証のための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００４ＰＣ）、（１４）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「デジタル権利管理情報にアクセスするのための装置、方法及びシステム」（弁護士ドケット番号４１８８−４００５ＰＣ１）、（１５）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「ピア環境において情報アクセスを実行するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１０ＰＣ）及び（１６）デイビッド・シドマンの名義で２００２年１月２５日に申請された、「情報アクセスを追跡するための装置、方法及びシステム」（弁護士ドケット番号４１８８−４０１１ＰＣ）。

ここに開示する発明は一般に通信ネットワークを通して情報にアクセスするための装置、方法及びシステムに関するものである。より詳しくは、ここに開示する発明は通信ネットワーク上で使用される様々なコンテキストに基づく電子的に発行された情報に多重のインスタンスにアクセスするための装置、方法及びシステムに関する。

インターネットの利用が増えるにつれて、インターネット上で利用可能な情報の量も増加する。インターネット上に存在する情報は、コンピュータ・ソフトウェア、データベース、検討リスト、電子ジャーナル、ライブラリ・カタログ、オンライン情報サービス、メーリング・リスト、ニュース・グループ、ストリーミング・メディア等、数多くのフォーマットのドキュメントを含む様々な種類のものがある。幸いにもインターネット上のほとんどの情報には、ユーザーが利用しやすい方法でネットワークとインタラクションするためのウェブ・ブラウザを用いワールド・ワイド・ウェブを介してアクセスすることができる。

一般にネットワークは、クライアント、ピア、サーバー及びグラフ・トポロジーにおける中間のノードの相互接続と相互運用から成ると考えられている。注意すべきことは、ここでは「サーバー」という用語は通常、通信ネットワーク全体の遠隔ユーザーのリクエストを処理したりそれに応答したりするためのコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせを指すということである。サーバーはリクエストしてくる「クライアント」に情報を提供する。情報やリクエストを可能にしたり、処理、及び／またはソース・ユーザーからデスティネーション・ユーザーへの情報の流れを支援するコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせは、通常「ノード」と呼ばれる。ネットワークは一般的にソース・ポイントからデスティネーションへの情報の転送を可能にするものと考えられている。

コンピュータ・システム、データベース及びコンピュータ・ネットワークの拡散と拡大は、一般的にインターネットと称されるそのようなシステムの相互接続と国境を越えた通信ネットワークによって促進されてきた。インターネットは伝送制御プロトコルとインターネット・プロトコル（ＴＣＰ／ＩＰ）を発展させ、またその大部分においてそれらを用いている。ＴＣＰ／ＩＰは様々な変化するネットワーク業者によって形成された複数のネットワークを、ネットワークのための基礎として相互接続するための、つまりインターネットのための米国国防総省（ＤｏＤ）の研究プロジェクトによって開発された。一つにはＤｏＤが、戦闘の最中に損害を受けても作動し続けることによって、通信ネットワークの損害を受けた部分を回避してデスティネーション・アドレスに情報を送るネットワークを必要としたことがＴＣＰ／ＩＰの開発の原動力となった。もちろん、ソース・アドレスのロケーションまたはデスティネーション・アドレスのロケーション自体が動作不能になった場合は、そのような伝達は不可能である。

インターネットはパケット交換型のネットワークであるため、インターネット上の情報はパケットと呼ばれる幾つもの断片に分割され、パケット形式で送信される。パケットはヘッダーと呼ばれるＩＰアドレス情報を含み、それらはルータがインターネット上の中間ノードを通してパケットをソースからデスティネーションへ配信することを可能にする。デスティネーションに到着すると、パケットは再構築されオリジナルのメッセージを形成し、欠落しているパケットがあれば、それらは再びリクエストされる。

プロトコルのＩＰ部分は、４バイトのアドレス・メカニズムに基づいて情報パケットをルーティングする役目を担う。アドレスはドットによって分離された４つの数字であり、各数字は０から２５５の範囲内で、例えば、「１２３．２５５．０．１２３」というようになる。ＩＰアドレスはインターネット当局及び登録機関が指定し、それぞれ固有のものである。

プロトコルのＴＣＰ部分は情報のパケットがソースからデスティネーションに正確に受信されたかを確認し、またもし正確に受信されなかった場合は、間違ったパケットを再送信するために用いられる。ユーザー・データグラム・プロトコル（ＵＤＰ）等の、配信を保証しないその他の伝送制御プロトコルも一般的に利用されている。

インターネット、特にワールド・ワイド・ウェブ（ウェブ）が広く受け入れられ拡大し、膨大且つ多様な情報が集めらた。情報技術システムを有するユーザー同士（つまりコンピュータ利用者）のインタラクションを可能にする様々なユーザー・インターフェースが現在利用されている。ＷｏｒｌｄＷｉｄｅＷｅｂ．ａｐｐ（ウェブ）と呼ばれる情報ナビゲーション・インターフェースは、１９９０年後半に開発された。その後、ウェブ・ブラウザ等の情報ナビゲーション・インターフェースがほぼ全てのコンピュータ・オペレーティング・システム・プラットフォームにおいて広く利用可能になった。

一般的にウェブは、複数のユーザー・インターフェース（例えばウェブ・ブラウザ）、サーバー、配信された情報、プロトコル及び仕様の、相乗相互運用の発現でありその結果である。ウェブ・ブラウザは情報へのナビゲーションとアクセスを促進するために設計され、一方情報サーバーは情報の供給を促進するために設計されている。通常ウェブ・ブラウザと情報サーバーは通信ネットワークを介してお互いに交信するように配置してある。情報サーバーは、通常ウェブ・ブラウザを用いて情報にアクセスするユーザーに対し情報を提供する機能を果たす。従って、情報サーバーは主にウェブ上の情報へのナビゲーションやアクセスにウェブ・ブラウザを用いるユーザーに対し情報を提供する。ウェブ・ブラウザの例としては、マイクロソフト社のインターネット・エクスプローラや、ネットスケープ・ナビゲーターがある。加えて、ウェブＴＶのようなナビゲーション・ユーザー・インターフェース機器もウェブ・ナビゲーションを容易にするために実現されている。マイクロソフト社のインフォメーション・サーバーやアパッチが情報サーバーの例として挙げられる。

ウェブの拡大は膨大な量の情報をもたらし、かかる膨大な情報はユニバーサル・リソース・ロケーター（ＵＲＬ）を利用することによりアクセス可能である。ＵＲＬとは通常ウェブ・ページ中にハイパーリンクとして組み入れられるアドレス、あるいはウェブ・ブラウザにタイプ入力されるアドレスである。所与のリソース（最も一般的には遠隔コンピュータ上にあるファイル）のＵＲＬはそのリソースのみを指す。一般的に、当該場所へのレファレンスは、例えば「ｈｔｔｐ：／／ｗｗｗ．ａＷｅｂＳｉｔｅ．ｃｏｍ／ａＦｏｌｄｅｒ／ａＦｉｌｅ／ａＦｉｌｅ．ｈｔｍｌ」というように、ディレクトリ・パス及びファイル名と併せて未解決のＩＰアドレスを用いて達成される。この例では、このＵＲＬが「ａＷｅｂＳｉｔｅ．ｃｏｍ」というドメインの「ｗｗｗ」という名前のコンピュータに接続し、そのコンピュータの「ａＦｏｌｄｅｒ」というディレクトリに保存されている「ａＦｉｌｅ．ｈｔｍｌ」という名前のファイルをリクエストするように、ブラウザに命じることになる。

Ｔｈｅ Ｃｏｒｐｏｒａｔｉｏｎ ｆｏｒ Ｎａｔｉｏｎａｌ Ｒｅｓｅａｒｃｈ Ｉｎｉｔｉａｔｉｖｅは、情報の名前と所在を指定するハンドル・システムと呼ばれる新しい手段を創り出し実施した。ハンドル・システムは現在のＵＲＬの利用状況を改善するために設計された。

ハンドル・システムは、インターネット上で情報の所在を確認したり情報を配信するための間接指定のレベルを導入する。ハンドル・システムは、リソースに名前を付けるための汎用システムである。特定のリソースの現在の場所に基づくＵＲＬを指定する代わりに、リソースにユニバーサル・ネーム識別子を指定する。ＵＮＩはユニバーサル・リソース識別子（ＵＲＩ）の一形式である。ＵＲＩはＵＮＩとＵＲＬの両方を含む。ＵＮＩはＵＲＬと違い、リソースの場所やその他の属性の変化に関わらず永続的なリソースの名前として機能し、またこれ以降そのような名前であるものとみなす。言い換えると、ユニバーサル・リソース・ネーム（ＵＲＮ）はＵＮＩの一種である（即ち、ＵＮＩはＵＲＮの概念を含む）。更に、ハンドルとはＵＲＮの一種である。またデジタル・オブジェクト識別子（ＤＯＩ）はハンドルの一種である。従って、ハンドル、ＵＲＮ、ＤＯＩ及び／またはその他が様々な形式のＵＮＩに含まれる。ＵＮＩの様々な用語及び／または形式は、本文全体にわたって置換可能なように用いられ、特に明記しない限り置換可能と想定してよいものとする。ハンドルは、名付けられたリソースの現在のネットワーク上の場所と共にハンドル・システムに登録される固有の名前である。この場所に関する情報は通常ＵＲＬの形式をとる。一般的なハンドルの種類の一つとしてデジタル・オブジェクト識別子（ＤＯＩ）が知られている。その場合ハンドルはＵＲＬの代わりにユーザーに配信され、表面上はハイパーリンクと同様に機能するかに見える。ユーザーがハンドルに遭遇すると、ユーザーのブラウザにハンドル・リクエストを行う作成する機能がある限りは、ユーザーはＵＲＬハイパーリンクを選択したり入力したりするのと同様にハンドルを選択したり入力したりする。そのような遭遇により、リソースの現在の場所を検索する自動のプロセスが始動する。リソースの現在の場所は、ハンドル・システムが提供するディレクトリの中のリソースのハンドルに関連付けられていて、ユーザーをリソースの現在の場所へと導く。ＵＲＬとは違い、リソースが移動した場合、ハンドル・システムのディレクトリのエントリーは更新可能なので、ハンドルと、ハンドルが特定するリソースとの永続的な関連付けが確保される。これを現実の世界に喩えるならば、所与のリソースのＵＲＬのみを知っているということは、ある人の住所だけ知っていて名前は知らないようなものである。もしその人が街の反対側へ引っ越した場合、名前を知らなければ探すのは非常に困難になる。ハンドル・システムにより、ハンドルを用いてリソースに永続的な名前を付けることができ、ハンドル・システム・ディレクトリの中のリソースの名前に基づいて、リソースの現在の場所を検索することができる。

デジタル・オブジェクト識別子はＩＰ及び場所に基づくアドレス方式の欠点の多くを克服するものである。ＤＯＩは頻繁に移動する可能性のある情報に永続的な識別子を与え、通信ネットワーク上の情報にアクセスすることを可能にする。ＤＯＩは、識別子を場所と関連付けるのではなく、更なるレベルの間接指定を加えて識別子を情報と関連付けるメカニズムを設けることによって、場所をアドレスで指定することに限定されたネットワーク・アドレス方式の限界を克服する。

ＤＯＩは、識別子を場所ではなく情報と関連付けることを可能にするメカニズムを提供するが、ＤＯＩ自体は、様々な場所、様々なフォーマットの情報の多重及び／または様々なインスタンスのアクセス、あるいは様々な使用コンテキストに基づいて、所与の情報に関連する様々なサービスへのアクセスを可能にするものではない。

開示した発明の一実施例は、どのようにして通信ネットワークを介して多重の場所から、多重のフォーマットで、変化する使用コンテキストに基づく可変の方法でアクセス可能なように、情報にアクセスするかを教示している。本発明ではまた、様々な条件下で様々な場所から様々なフォーマットで様々なアクセスのコンテキストに基づいてアクセス可能なように、一つの識別子を利用可能な情報と関連付ける新規な能力をもってして、従来のアドレス方式の限界を克服するものである。

一般に本発明の特徴によれば、本文ではこれ以降発行者と呼ぶコンテンツの発行者が、ＤＯＩ登録機関に登録することによって情報にデジタル・オブジェクト識別子を指定する。

本発明の別の特徴によると、登録の際に、登録者または登録機関が、登録するＤＯＩと関連する多数のタイプとバリューのペアを更に登録することもできる。本発明のまた別の特徴によれば、登録されたタイプと関連するバリューは、登録されたＤＯＩのための多重解決を提供するために用いられる。ＤＯＩハンドブックが定義する「解決」とは、ＤＯＩ識別子を提出し、それに応じて提出した識別子に関係する現在の一つの情報を一つ以上受信することである。単一解決とはＤＯＩが一つの情報、通常はＤＯＩが識別したリソースに関連するウェブ・ページのＵＲＬ（即ち現在の場所）をもってして解決するものである。これとは対照的に、本発明に基づく多重解決とは一つ以上の解決が、様々なコンテキストにおいて可能なものである。

上記の効果と特徴は代表例なもののみであって、全てのものを示すものでもなく、その他に無いということでもない。これらは本発明の理解の助けとなるように示したに過ぎない。これらは請求項が定義する発明の全てを代表するものではなく、請求項が定義する発明を限定することや、請求項と同等のものを限定することはない旨、理解されるべきである。例えばこれらの効果のうちの幾つかは、同時に一つの実施例中には存在し得ないという点で、お互いに矛盾している。同様に、これらの効果のうちの幾つかは、本発明の一つの特徴には当てはまるものの、他の特徴には当てはまらない。更に、請求項にある本発明にはここには記載していない特徴もある。しかしながら、紙面の節約と繰り返しを減らすという目的で記述しなかったということ以外で、ここに記載する内容と記述していないものとの関係について、これといった推論を引き出すべきではない。かくして、かかる特徴と効果の要約は、どの様なものを同等なものとするかを決定するものと考えるべきではない。本発明のその他の特徴と効果については以下の記述、図及び請求項から明確になる。

本発明によれば、通信ネットワークを介して多重の場所から多重のフォーマットで変化する使用コンテキストに基づく可変の方法で情報にアクセスすることができる。

（ＩＰアドレッシング）
ユーザーはアドレスを介して通信ネットワークにアクセスする。アドレスは場所を表している。ユーザーは通信ネットワークにおいて、情報を探し出すべく場所から場所へ移動する。一般的な通信アドレスはＩＰアドレスを用いている。ＩＰアドレスは現実の世界では住所に例えることができる。ＩＰアドレス自体は、例えば２０９．５４．９４．９９といった一連の数字であり、通常は、例えばｗｗｗ．ｃｏｎｔｅｎｔｄｉｒｅｃｔｉｏｎｓ．ｃｏｍというような関連する名前を有する。分散型データベース・レジストリは名前とＩＰアドレスの関連するペアを維持し、関連する名前を対応するＩＰアドレスへと解決する役目を担う。これにより、ユーザーは、２０９．５４．９４．９９といった一連の数字を暗記して用いる代わりに、例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍといった名前を覚えておいて使用することが可能になる。ＩＰアドレスの名前解決を支援するこれらの分散型データベースは、一般的にドメイン・ネーム・サーバー（ＤＮＳ）と呼ばれている。

ＩＰアドレスを、アドレスに更なるナビゲーション情報を付加したユニバーサル・リソース・ロケーター（ＵＲＬ）として具現することが一般的である。ユーザーは、ＨＴＴＰを用いてＵＲＬに保存されている情報をアクセスするためにソフトウェアを用いてもよい。一例を挙げると、ユーザーが「ｈｔｔｐ：／／ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」とウェブ・ブラウザに指定する。すると通常この更なるナビゲーション情報である「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」がコンピュータ・サーバー内の特定の保存場所を提示する。この更なるナビゲーション場所は、現実の世界では番地よりも詳しい、会社名や部署名、部屋番号等を含む住所に例えることができる。この更なるナビゲーション場所の取り扱いや解決は、通常ＤＮＳではなく解決されたＩＰアドレスにある情報サーバーにより行われる。例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍに対して解決したアドレスである１２３．１２３．１２３．１２３にある情報サーバーは、サーバー内のローカルの場所「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」にある情報を解釈し返送する。情報サーバーとは、通信ネットワークと特定のＩＰアドレスにあるコンピュータ・サーバーの間の通信を可能にする手段である。情報サーバーの商業的な例としては、アパッチが挙げられる。情報サーバーは、企業内の該当部署へ郵便物を仕分ける企業のメール室に例えることができる。

図１と図２は、ＩＰアドレッシング・メカニズムは、情報が通信ネットワーク上で移動する間に、情報との関連を維持しないということを図示している。一般的にウェブ・ページのリンクにはＨＴＴＰを用い、ＨＴＴＰはＩＰアドレッシングに依存している。従って、ＵＲＬリンクは単に通信ネットワーク上の場所を示すだけで、必ずしも特定の情報と関連しているわけではない。例えば、ｗｗｗ．ｎｅｗｓ．ｃｏｍをレファレンスするＵＲＬリンクによってＵＲＬとｗｗｗ．ｎｅｗｓ．ｃｏｍで入手可能な情報を関連付けてもたらされる情報は、その場所では毎日情報が更新されるため、異なる情報となる。多くの場合、企業が情報を移動させたり、事業を移動させたり、廃業したりすると、場所そのものが消失する。

例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ２０８という場所に存在した「１９９９年度売り上げ」というタイトルのレポート２２２が、当該情報があるエンティティから別のエンティティに売られたり、アーカイブされたり、あるいはその他様々な理由で、例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ３１０という場所に移動することもある。ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ２０８という場所に存在したレポートは５００万ウェブ・ページ及び場所２４４をレファレンスするＵＲＬリンクを有したかもしれず、ユーザーが当該情報へのアクセスを試みると、その場所は既に存在しないため及び／またはその場所はユーザーが所望した情報を含まないため、ユーザーは「４０４Ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」のエラー３０９を受け取る可能性もある。結果としてエラーが出るのは、ＤＮＳは常にユーザーのリクエストを場所へと解決するよう設計されているためであり、またＤＮＳはＵＲＬと特定の情報のインスタンス化との関連を維持するように設計されていないためである。

図１はウェブ・ページ２０１、ユーザーが入力したアドレス２０２、ドキュメント２０３及びメモリ・デバイス２０４を描写し、何れも一つの情報（「１９９９年度売り上げ」のレポート）２２２をレファレンスするためにＵＲＬを、従ってＩＰアドレッシングを用いる。次に図２では、情報２２２は元の場所２０８（例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）から図２の新しい場所３１０（例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）へ移動する。図２において、この結果として当該の場所をレファレンスする全てのＵＲＬ２４４のブレーキング３０１−３０４が起こり、あの恐ろしい「４０４Ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」のエラー３０９を、当該の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８へレファレンスする全てのユーザーとＵＲＬに提示することになる。
（ハンドル・システム）
ひとたび一つの情報にＤＯＩが指定され利用可能になると、ＤＯＩシステムはＤＯＩのユーザーがアクセスを望むものを解決できるようになる必要がある。ＤＯＩの解決を成し遂げるために用いる技術は、「ハンドル・システム」としてより広く知られており、以下により詳しく説明する。ＤＯＩハンドブックには基本的なＤＯＩの一般的な概要が記載されている。一言で言えば、ハンドル・システムはプロトコルのオープンなセット、ネームスペース及びプロトコルの実施化を含む。プロトコルは分散型コンピュータ・システムが、デジタル・コンテンツのハンドル（ＤＯＩ等）を保存し、コンテンツの所在を確認しアクセスするため、当該コンテンツに関係する情報の所在を確認しアクセスするため、あるいは当該コンテンツに関連するサービスの所在を確認しアクセスするために（即ちそのようなサービスへのインターフェースを提供するために）必要な情報へと、それらのハンドルを解決することを可能にする。必要に応じて、ＤＯＩを変更することなく識別されたコンテンツの現状を反映するために、この関連情報を変更することができるので、場所やその他の状況の情報の変更を経てもアイテムの名前が存続することが可能になる。一元管理されたＤＯＩ登録機関と共に、ハンドル・システムは長期にわたるネットワーク上の情報及びサービスの信頼性のある管理のための、汎用且つ分散型のグローバル・ネーミング・サービスを提供する。本開示全体にわたり、ＤＯＩシステムを介してアクセス可能になった「ソース」、「コンテンツ」及び／または「情報」とは、特定が可能な全てのコンテンツ、ソース、情報、サービス、トランザクション及び記事、書籍、無形オブジェクト、音楽アルバムを含む著作物、人物、有形で物理的なオブジェクト、その他及び／またはそれらの選択された個別の部分及び／またはそれらの組み合わせを更に含む、から成り得ることに注意することが重要である。アクセス可能な情報は、サービスやトランザクションを開始するアプリケーションや、選択のメカニズム及び／またはその他を提供するアプリケーション等へのＵＲＬでもよい。一つの非限定的な例では、ＤＯＩは、ソーシャル・セキュリティ番号、電話番号及び／またはその他のある人物を識別する情報と関連付けられることすらあり得る。別の非限定的な例においては、ＤＯＩはソフトウェア・モジュール、プログラミング「オブジェクト」またはその他のネットワークに基づくリソースの何かと関連付けられたりもする。更に、実際の製品（現在ＵＰＣやバーコードで識別されている品物等）のオンラインでの表示を含むほとんど全てのものを表示するためにＤＯＩを用いることができる。そのような例では、ＤＯＩはある製品を説明したり販売したりしている製造者のカタログ・ページへと解決することができ、多重解決シナリオにおいては、ある品物を修理してもらうにはどこへ行けばよいか、交換用の部品はどこへ行けば見つかるか、新製品あるいは交換用の製品はどのようなものか、どのような価格またはリースのオプションがあるのか等、当該オブジェクトに関係する全てのサービスへと解決することができる。ＤＯＩを実施するその他の実施例に含まれるのは、通信ネットワークを介して分散型の方法で動作することができるソフトウェアの異なるモジュールの表示、ボイス・オーバーＩＰ技術のための電話番号、遺伝子配列、医療記録及び／またはその他の恒久的な記録（ＤＯＩは、サーティフィケートあるいは暗号解読鍵を呼び出すこともある暗号化及び／またはその他の方法で保護された恒久的な記録に特に有用）及び／または同様のもの、である。別の実施例ではＤＯＩは、例えば現在の株価、（株及び／またはその他全てのオークション及び／または為替の）最新の競売価格や売り出し価格、（別の過去の年次報告書には異なるＤＯＩが割り当てられているのに対して）企業の最新の年次報告書、及び／またはその他のようなもので、しかしこれらに限定されない一時的及び／または動的なバリューの恒久的な場所を表す。

ユーザーはデジタル・オブジェクト・アイデンティファイアー（ＤＯＩ）を介して情報にアクセスし得る。ＤＯＩは情報そのものに関連付けられている（即ち情報自体の名前である）。ＤＯＩは「ハンドル」のインスタンスであり、「ハンドル・システム」の枠組みの中で動作する。ＤＯＩは永続的に関連付けられた情報へのアクセスを可能にする。ＤＯＩは、一連の文字の後にセパレーターが付き、その更に後に一連の文字が付いたもので、例えば１０．１０６５／ａｂｃ１２３ｄｅｆというようになる。注意すべき、そして再び強調すべきことは、本開示は「ＵＲＮ」「ＤＯＩ」「ハンドル」といったＵＮＩの特定のサブ・タイプについて記載することもあるが、本開示はより一般的なタイプのＵＮＩにも同等に適用されるものであり、従って特に断りの無い限り本開示はＵＮＩのあるサブ・タイプに言及する場合はＵＮＩ全般にわたって適用されるものと見做されるべきものである。更に、今日使用されているハンドル・システム、ＤＯＩ及びそれらの支援技術や仕様は、本開示の意図したフォーラムではあるものの、本開示は最新の、または今後考案される仕様やシステムに基づいた他のフォーラムにも応用できることを意図していることに注意すべきである。
（ＤＯＩ）
情報にアクセスするためにＤＯＩを使用しているユーザーは、ＤＯＩが関連付けられた情報のみを解決しアクセスすることを知っている。場所をレファレンスするＵＲＬとは対照的に、ＤＯＩとは情報に対する名前であり、その情報の場所やその他の属性、と共に関係するサービスをも見るために用いることができる。情報とは、電子書籍、音楽ファイル、ビデオ・ファイル、電子ジャーナル、ソフトウェア及び前記のコンテンツの一部及び／またはそれらの組み合わせも含む情報と共にコンピュータで読み取り可能なファイル全てを含むと考えられる。電子コンテンツは通信ネットワーク上で利用可能となっているので、これ以降本出願書はそのような利用可能な情報は、通信ネットワーク上で発行されたものとみなすということに注意されたい。

ＤＯＩは、通信ネットワーク上で利用可能な情報に与えられた恒久的で永続的な識別子で、仮にコンテンツあるいは関連するデータの場所（即ちＵＲＬ）、フォーマット、所有権等が変更されたとしてもユーザーが関連データにアクセスすることができるように、電子的形態で登録されている。ＤＯＩまたはハンドルは、ＵＲＬの代わりにユーザーに配信できる。ユーザーは、ハンドル対応のウェブ・ブラウザに、ＵＲＬハイパーリンクと同様にＤＯＩを選択したり入力したりすることにより、ある特定のＤＯＩに関連付けられた情報にアクセスする。例えばｗｗｗ．ｃｎｒｉ．ｏｒｇから入手可能なハンドル・システム・プラグイン等のブラウザ・プラグイン・ソフトウェアを用いて、数多くの種類のブラウザをハンドル対応にすることが可能である。ＤＯＩに関連付けられた情報にアクセスするためのそのような試みにより、リソースの現在の所在を確認する自動のプロセスが起動する。当該リソースの現在の場所は、ハンドル・システムによって利用可能な一元管理されたディレクトリ内の当該リソースのＤＯＩに関連付けられており、それが今度はユーザーを（即ちユーザーのウェブ・ブラウザを）当該リソースの現在の場所へと導く。この誘導はしばしば、選択されたＤＯＩに関連する現在のＵＲＬと、対応する情報を返信することによって実行される。

図３はＤＯＩを介した情報へのアクセスを上記の図１及び図２と対比して図示している。最初に、登録プロセスを経て情報（「１９９９年度売り上げ」のレポート）２２２にＤＯＩが与えられる。ＵＲＬを用いる代わりに、ユーザーはＤＯＩを用いウェブ・ページ４０１、ウェブ・ブラウザへのタイプ入力４０２、ドキュメント４０３、デバイス４０４及び／またはその他を介して当該情報のレファレンス４４４を行う。ユーザーがＤＯＩリンク４４４を行うと、それらは一元管理されたＤＯＩディレクトリ４１１において解決され、リクエストしたユーザーは情報２２２の最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８へのＵＲＬリンク２４４を与えられる。当該情報が最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８から新たな場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）３１０へ移動４３４すると、当該情報の発行者４１０は新たな場所をレファレンスする更新されたＵＲＬ２４５を送ることにより、ＤＯＩ一元管理ディレクトリ４４５に当該情報の新しい場所を知らせる。それ以降、ユーザー４０１−４０４がＤＯＩリンク４４４を介して当該情報にアクセスを試みると、ＤＯＩディレクトリは更新されたＵＲＬ２４５を通して適正に新しい場所３１０を提示する。

上記のように、ＤＯＩは情報のみならず、その一部を識別するために用いることもできる。例えば、ＤＯＩシステムによれば、１冊の書籍が一つのＤＯＩを有することが可能な一方、その書籍のそれぞれの章が別の、それぞれの章を識別するための固有のＤＯＩを有することもあり、更にはその書籍中の図面一つ一つがそれら図面を識別するための固有のＤＯＩを有することも可能である。言い換えれば、ＤＯＩシステムによると、コンテンツ発行者の希望通りに様々な細かさのデータの塊として情報を識別することができる。なお、ユニバーサル・プロダクト・コード（一般的には消費者向け製品の「バーコード」として表示されている）によって例えば、スーパーのレジ、在庫コンピュータ、財務システム及び流通業者が現実の世界でサプライ・チェーンを自動化することが可能になるように、本開示はＤＯＩを用いて世界中の全ての電子発行エージェントがインターネットを介したデジタル・コンテンツ（及びそのコンテンツに対する権利のライセンス）の販売を効率的な方法で自動化することを可能にするメカニズムを提供すると想定している。何故ならば、販売可能なコンテンツのそれぞれが世界で唯一のＤＯＩを有しており、それをエージェント同士のトランザクションにおいて製品の識別コードとして使用することが可能だからである。
（ハンドル構造）
ハンドル・システムは、効率的でユーザーに分かり易い利用を可能にするための前もって決められた方針の一群を採っており、そのうち幾つかを以下に挙げる。発行者がオペレーション・コストを負担して、ＤＯＩ解決のためのハンドル・システムの使用がユーザーには無料となるのが理想的である。ＤＯＩは全て世界的なＤＯＩ機関に登録される。登録者は、登録したＤＯＩに関する状態データ及びメタデータを維持する責任がある。ＤＯＩのシンタックスは標準化されたシンタックスに準じる。使用にあたっては、ＤＯＩはオペーク・ストリング（ダム・ナンバー）になる。ＤＯＩ登録機関はＤＯＩの指定、登録、ＤＯＩに関連するメタデータの申告を管理する。

図４及び図５は、ハンドル５００の概略図である。ハンドル５００は二つの構成要素である、プレフィックス５０１とサフィックス５０２を有する。プレフィックス５０１とサフィックス５０２は、フォワード・スラッシュ５０７により区切られている。ハンドル５００には、印刷できる文字であれば、今日書かれたり使用されたりしているほとんど全ての主要な言語のどれを取り入れてもよい。プレフィックス５０１にもサフィックス５０２にも特に長さの制限はない。結果として、利用可能なハンドルの数はほとんど無限であると想定される。プレフィックス５０１とサフィックス５０２の組み合わせを確実に唯一固有なものにすることが、ハンドル・システムの完全性を維持するためには重要である。そのため、ＤＯＩ登録機関は発行者に固有のプレフィックス５０１を与え、指定するサフィックス５０２もまた確実に固有のものであるようにする責任を発行者に課す。登録機関とハンドル・システム管理者は共に、新しいハンドルについては全てその固有性を確認してからハンドル・システムに入れる。登録機関はハンドル・システムにＤＯＩ記録を入れ、それを受けてハンドル・システムはＤＯＩディレクトリを介してＤＯＩ解決リクエストに対し情報を提供する。

プレフィックス５０１自体は、プレフィックス・セパレーター５０６、即ちピリオドにより区切られる二つの構成要素を有する。ハンドル・プレフィックスの第一の部分はハンドル・タイプ５０４で、第二の部分はハンドル・クリエーター５０５である。ハンドル・タイプ５０４は、どのようなタイプのハンドル・システムが使用されているかを識別する。ハンドル・タイプ５０４が「１０」で始まる場合、当該ハンドルはＤＯＩであると識別され、ハンドル・システムの他の実施タイプではないと分かる。ピリオドにより区切られたプレフィックスの次の要素であるハンドル・クリエーター５０５は、ＤＯＩの登録を希望する団体に与えられる番号（または文字列）である。これら二つの要素５０４と５０５が一緒になり、ＤＯＩの固有の発行者プレフィックス部分を形成する。どの団体が申請するハンドル（より詳しくはＤＯＩ）プレフィックスの数にも制限はない。結果として、例えば出版社は一つのＤＯＩプレフィックス５０１を有してもよいし、ジャーナルごとに異なるプレフィックスを有することも、そのジャーナルの刷り込み毎に一つのプレフィックスを有することもできる。通常プレフィックス５０１は単純な数字列だが、ハンドル・システムの範囲はそれに限定されるものではない。従って、プレフィックス５０１にアルファベットやその他の文字を用いてもよい。

サフィックス５０２は固有の英数字列であり、特定のプレフィックスと共に、固有情報を識別する。発行者のプレフィックス５０１と発行者の提示する固有のサフィックス５０２の組み合わせにより、ＤＯＩ番号の一元割り当ての必要性を免れる。サフィックス５０２は、当該発行者がプレフィックスと共に登録した他のどのサフィックスとも異なる固有のものである限り、当該発行者の選択する如何なる英数字列でもよい。

図５は、ＤＯＩ６００の別の実施例を示しており、図中ではテキストブックのＩＳＢＮ番号がサフィックス６０２として機能している。従って便宜上、元と成るコンテンツの発行者は、サフィックス６０２として元のコンテンツに合致する他のどのような識別コードを選択してもよい。
（ハンドル・システム・メタデータ）
ＤＯＩ５００は識別番号に過ぎず、必ずしもそれに関連付けられた情報について何らかの情報を伝達するわけではない。結果として、ＤＯＩにアドレスする情報に関する追加情報を補足して、ユーザーが効率的且つ分かり易いサーチを行い、所望のコンテンツを通信ネットワーク上で入手できるようにすることが望ましい。情報を識別し易くするために、本発明は識別される情報の説明的なデータであるメタデータを使用する。メタデータはＤＯＩに関連するどのようなデータ構造であってもよいが、一実施例によると、メタデータは発行された情報を正確且つ簡潔に識別できる幾つかの基本的なフィールドから成る。この実施例によれば、メタデータは書籍の国際標準図書番号（ＩＳＢＮ）等のレガシー識別スキームからのエンティティと関連する識別子、発行されたコンテンツのタイトル、発行されたコンテンツの種類（書籍、音楽、ビデオ等）、当該コンテンツはオリジナルか派生したものか、コンテンツの主要な著者、コンテンツ作成の際の主要著者の役割、発行者の名前及び／またはその他等から成る。異なる種類のコンテンツはそれを説明する異なるデータを必要とするため、異なる種類のコンテンツには異なるメタデータを使用することを想定しているということがＤＯＩシステムの特徴の一つである。

一実施例によると、メタデータはＤＯＩシステムのユーザー全てに利用可能となっており、それによってユーザーは特定のＤＯＩが識別するエンティティの基本的な説明を検出することが可能である。この基本的な説明によりユーザーはコンテンツを発行したエンティティの、あるいはコンテンツ自体の、幾つかの基本的な事柄を理解することができる。

結果として、ＤＯＩが何の情報を識別するのかを調べるには、それを解決した後、関連するメタデータをレビューすることが望ましい。何故ならばＤＯＩはメタデータを識別するコンテンツや、同じまたは関係するコンテンツに関する別のメタデータとリンクするからである。一実施例では、メタデータによりＤＯＩ５００が識別する情報と共に、その明確な仕様の認識が可能になる。またメタデータにより当該情報とネットワーク上のその他の情報（及びそれらのエンティティに関するメタデータ）とのインタラクションが可能になる。
（ＤＯＩ情報アクセス）
図６と図７は、ＤＯＩシステムにＤＯＩを提示するだけでユーザーが所望の情報にアクセスできるようにする解決メカニズムの概要を示している。本状況での解決とは、識別子をネットワーク・サービスに提示し、引き換えに当該識別子に関連する最新の情報を一つ以上受け取ることを含む。図６に示すＤＯＩシステムの一実施例では、ユーザーはウェブ・ブラウザ７００クライアントを用いて特定のＤＯＩ７１０が識別するコンテンツを指し示す。このＤＯＩ７１０は関連するＵＲＬを一つしか持っていないため、そのＵＲＬへと解決されるはずである。その結果、ユーザーが特定の識別子７１０が識別する、元と成るコンテンツをリクエストすると、ユーザーは所望のコンテンツがあるＵＲＬ７２０へと導かれる。

従って、このメカニズムにより情報の場所が変更されても、アクション可能な識別子としてエンティティの名前を維持することが可能になる。発行者がコンテンツの場所を変更した場合、発行者はハンドル・システムのデータベース内のＤＯＩエントリーを更新するだけで既存のＤＯＩ７１０は確実にコンテンツの新しい場所を提示する。結果として、コンテンツの場所は変更されてもＤＯＩは変更されず、ユーザーは既存のＤＯＩを用いて新しい場所にある当該コンテンツにアクセスすることが可能である。

図７は、ユーザーがＤＯＩを用いて、同一のＤＯＩが識別した同一のコンテンツの利用可能な複数のコピーの中から、コンテンツへのリクエストを解決するＤＯＩシステムの概要を示している。従って、ユーザーはウェブ・ブラウザ８００を用いて必要なＤＯＩ８３０を提示する。ＤＯＩ８３０は、所望のサービス８３５の種類を説明するように構築することもできる。その結果、ＤＯＩシステムはユーザーがアクセスすることを所望している特定のコンテンツ８４０へと解決することが可能になる。

図８は、本発明に基づき、ユーザーが情報にアクセスするために行う一連のアクションの概要を示している。まず初めに、ユーザーはブラウザ・クライアント９００をパソコン、携帯情報端末（ＰＤＡ）またはその他のコンピューティング・デバイス９０５上に立ち上げる。ユーザーはブラウザ９００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワークを通してＤＯＩディレクトリ・サーバー９１０に送られる。ＤＯＩディレクトリ・サーバー９１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べ、正しいＵＲＬをユーザーのコンピュータ９００上のブラウザ９００に送るが、こうしたアクションはユーザーには見えないようになっている。結果として、ブラウザは正しい発行者９２０のサーバー上の所望のコンテンツへと導かれる。最終的に、ユーザーのブラウザからのリクエストを受け取ると、発行者９２０は所望の情報をユーザーに送り、その情報にはブラウザ・クライアント９００でアクセスすることができる。

図９は、図８に示すようにユーザーがコンテンツの情報にアクセスするために行う一連のアクションをより詳しく示している。上述したように、ユーザーはブラウザ・クライアント１０００をコンピューティング・デバイス１００５上に立ち上げる。ユーザーはブラウザ１０００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワーク上でＤＯＩディレクトリ・サーバー１０１０に送られる。ＤＯＩディレクトリ・サーバー１０１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べる。ＤＯＩをＤＯＩディレクトリ・サーバー１０１０に保存されているエントリーに照らし合わせて調べた結果、ユーザー１０５０をどこへ導くべきかをＤＯＩディレクトリ・サーバー１０１０は決定する。当該コンテンツの正しいＵＲＬは、何らの中間介入あるいはユーザーによるアクションなしに、自動的にユーザーのブラウザ１０００に送られる。その結果、ブラウザ１０００は元と成るＵＲＬによりアドレスされたサーバーを有する正しい発行者１０２０へと導かれる。当該ＵＲＬは発行者のサーバー１０２０によりユーザーの所望するコンテンツを厳密に決定するために用いられ、発行者のサーバー１０２０は正しいコンテンツ１０３０をユーザーに送る。

図１０は、本発明に基づいて、ＤＯＩを解決して所望のコンテンツが位置するＵＲＬを得ることにより、通信ネットワーク上で情報にアクセスするための幾つかの典型的なメカニズムの概要を示している。一実施例によると、ユーザーは直接ＤＯＩを提示し、ＤＯＩシステムは正しいコンテンツを入手し単に正しいＵＲＬにリンクすることによりそれをユーザーに送信する。別の実施例によると、ユーザーはメタデータに含まれるフィールドの幾つかに関係する情報を提示し、するとＤＯＩシステムは所望のコンテンツが位置する正しいＵＲＬを識別する。

図１０に示すように、一実施例によれば、サーチ・エンジン１１０１０をユーザーに提供してもよい。別の実施例では、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍのようなサーチ・エンジンを用いてクエリーを出す。ユーザーは、サーチ・エンジン１１０１０に何らかの識別情報を提示することにより正しいＤＯＩを検索する。サーチ・エンジン１１０１０は提示された識別情報を用いてメタデータに関する自分のデータベースを検索し、提示されたメタデータの情報に関連するＤＯＩを入手する。入手したＤＯＩはＤＯＩディレクトリ１１０１１に送られ、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを解決する。最終的に、ユーザーのブラウザは正しいコンテンツ１１０６０へと導かれる。

別の実施例によると、ユーザーはＤＯＩ１１０１５をブラウザ１１０２５のアドレス・ウィンドウ１１０２０に提示する。ＤＯＩ１１０１５はＤＯＩディレクトリ１１０１１用のプロキシ・サーバーのアドレスを含み、それは図１０においては「ｄｘ．ｄｏｉ．ｏｒｇ」である。その結果、ブラウザはｄｘ．ｄｏｉ．ｏｒｇに位置するＤＯＩディレクトリ１１０１１へと導かれ、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを解決し、ユーザーのブラウザをそこへと導く。

別の実施例によれば、ＤＯＩはドキュメントあるいは何らかの形式の情報１１０３０の中に埋め込むこともでき、それによりＤＯＩをクリックすることによってユーザーを正しいＤＯＩディレクトリ１１０１１に導き、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬ決定し、ユーザーのブラウザをそこへと導く。

別の実施例によると、ＤＯＩはＣＤ−ＲＯＭまたはフロッピー・ディスク等のメモリ１１０４０上に提示してもよく、するとメモリは自動的に、または起動されると、ユーザーを正しいＤＯＩディレクトリ１１０１１に導き、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを割り出し、ユーザーのブラウザをそこへと導く。

また別の実施例によれば、ＤＯＩは印刷物としてユーザーに提供してもよく、ユーザーは当該ＤＯＩを上記の如く光学的または機械的周辺入力機器を用いてマニュアルで入力する。

図１１は、通信ネットワーク上で情報を入手し、ＤＯＩシステムがＤＯＩを解決して所望の情報が位置するＵＲＬを得るための典型的なメカニズムの別の実施例の概要を示している。この一実施例によると、複数のＤＯＩディレクトリ１２１０が分散型ＤＯＩディレクトリとして存在し、ハンドル・システム１２００を形成している。一実施例では、分散型ＤＯＩディレクトリはあたかも単一のディレクトリ１１０１１であるかのように動作し、リクエストに応える。その点を除いては解決は図１０と同様に行われる。

図１２は、本発明に基づいて、発行者、ＤＯＩ登録サービス及びハンドル・システムが連携して創り出す効率的なＤＯＩシステムの概要を示している。既に固有のプレフィックス５０１を与えられている発行者１３４２は、コンテンツ１３６６にサフィックス５０２を指定する。上記のように、ＤＯＩを用いてアドレスできるコンテンツの範囲は無限である。その結果、コンテンツ１３６６は如何なる情報及び記事、書籍、音楽アルバムを含む著作物、またはそれらの選択された個別の部分から成ってもよい。ＤＯＩ５００を提供することに加え、発行者１３４２は、コンテンツ１３６６用のメタデータを収集する。当該メタデータは当該コンテンツのＤＯＩ５００、ＤＯＩジャンル、識別子、タイトル、タイプ、起源、主要エージェント及びエージェントの役割から成る。

発行者１３４２がコンテンツ１３６６にサフィックス５０２を指定し必要なメタデータを収集すると、ＤＯＩ５００と当該メタデータはＤＯＩ登録機関１３００に送信される。ＤＯＩ登録機関１３００はＤＯＩ５００のデータベース、登録されたコンテンツ１３６６全てのメタデータと共にコンテンツ１３６６が位置するＵＲＬを維持する。本発明によると、ＤＯＩ登録機関１３００は当該メタデータをメタデータ・データベース１３１０、図１４では１１１９ｃに送信する。メタデータ・データベース１３１０はＤＯＩ登録機関１３００が一元管理することもできるし、またそうしなくてもよい。

ＤＯＩ登録機関１３００は、収集されたメタデータを別のデータ・サービス１３２０にフィードしたり、付加価値を付けたリソース１３３０をユーザーに提供したりするために利用することもできる。加えて、ＤＯＩ登録機関１３００は正しいＤＯＩハンドル・データをハンドル・システム１３５０に送り、ハンドル・システムは複数のＤＯＩディレクトリ・サーバー１３４１から成っていてもよい。
（ハンドル・システム・モデル）
図１３は、様々なエンティティと交信しているＩＡＭＲＳ１４００６の非限定的な一例を図示している。発行者１４０１２は、自らの情報を異なる場所から、異なるフォーマットで、異なるコンテキストにおいて、異なる目的や用途のために利用可能にしたいと望むかもしれない。そうする際に、発行者は単一のＤＯＩ１４００１を、多重解決１４００５、１４０２１−１４０２３で強化されたハンドル・システム１４００８に登録できる。部分的には、当該の強化されたシステムは図１４−１６で詳しく述べる多重解決システムである。発行者はＤＯＩの多重解決を提供して、個人、図書館、企業、大学及び／またはその他のような顧客１４００１、卸売業者／流通業者、集積業者、シンジゲート運営者、検索サービス、Ａ＆Ｉサービス、定期購読エージェント、バーティカル・ポータル及び／またはその他のような情報再販業者（情報仲介業者）１４００２に対する自らの情報の用途とアクセスを強化したいと希望するかもしれない。例えば、卸売業者／流通業者１４００２が、正しく情報へのアクセスを計上し代金を請求するために、自らのサーバーに発行者の当該情報を置いておく必要がある場合、通信ネットワーク１４００４を介した顧客１４００１による強化されたハンドル・システム１４００８への強化されたＤＯＩサービスのリクエスト１４０１０が、ＵＲＬ１ １４００５に関連する購入記録を選択１４０３０する。その後ＵＲＬ１は、通信ネットワーク１４００４を介して顧客１４００７へとリダイレクトして戻される。発行者はまた権利処理１４０２１、価格見積１４０２２及びメタデータのアクセス１４００９、１４０２３についての様々な場所をも提供する。
（情報アクセス多重解決サーバー・コントロー）
図１４は、情報アクセス多重解決サーバー（ＩＡＭＲＳ）コントローラに取り入れられた一実施例を図示している。この実施例では、ＩＡＭＲＳコントローラ１１０１はＵＮＩの登録、解決、処理、更新及び／またはその他の役割を担う。

一実施例において、ＩＡＭＲＳコントローラ１１０１は、ユーザー入力デバイス１１１１、周辺デバイス１１１２及び／または通信ネットワーク１１１３からの一人以上のユーザー等のエンティティと、接続及び／または通信することができるが、エンティティはこれらに限定されるものではない。当該ＩＡＭＲＳコントローラは、暗号プロセッサ・デバイス１１２８とさえも接続及び／または通信することが可能である。

典型的なＩＡＭＲＳコントローラ１１０１は、メモリ１１２９に接続されたコンピュータの系統的システム１１０２等の部品から成る一般的なコンピュータ・システムに基づくものであるが、部品はこれらに限定されるものではない。
（コンピュータの系統的システム）
コンピュータの系統的システム１１０２はクロック１１３０、中央演算処理装置（ＣＰＵ）１１０３、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）及び／またはインターフェース・バス１１０７から成り、従来は、必ずしもというわけではないが、全てシステム・バス１１０４を介して相互接続及び／または交信している。システム・クロックは通常水晶発振器を有し、基本信号を供給する。クロックは通常システム・バス及びコンピュータの系統的システムに取り入れられた他の部品の基本動作周波数を増加させたり減少させたりする様々な手段に結合している。クロック及びコンピュータの系統的システムの様々な部品は、システム内全てにおいて情報を具現する信号を駆動する。オプションとして、暗号プロセッサ１１２６を同様にシステム・バスに接続することもできる。もちろん、上記の部品の何れもお互いに直接接続したり、ＣＰＵに接続したり及び／または様々なコンピュータ・システムにより具現されるような数多くのバリエーションで組織化したりしてもよい。

ＣＰＵはユーザー及び／またはシステムにより出されたリクエストを実行するためのプログラム・モジュールの実行に適した少なくとも一つの高速データ・プロセッサから成る。ＣＰＵはインテル社のペンティアム・プロセッサ及び／またはその他のようなマイクロプロセッサでもよい。従来のデータ処理技術により、ＣＰＵは導電性の経路を介して送信される信号を介してメモリと交信し、保存されているプログラム・コードを実行する。そのような信号送信は、様々なインターフェースを通じてＩＡＭＲＳコントローラ内の通信及びＩＡＭＲＳコントローラの域を越える通信を可能にする。
（インターフェース・アダプター）
インターフェース・バス１００７は数多くのインターフェース・アダプターを受け入れ接続し、及び／または通信し、必ずしもアダプター・カードの形である必要はないが、従来その例として、入出力インターフェース（Ｉ／Ｏ）１００８、記憶インターフェース１００９、ネットワーク・インターフェース１１１０及び／またはその他があるが、それらに限定されるわけではない。暗号プロセッサ・インターフェース１１２７も同様に、任意にインターフェース・バスに接続してもよい。インターフェース・バスは、インターフェース・アダプター同士の通信を提供すると共に、コンピュータの系統的システムにおける他の部品への通信を提供する。インターフェース・アダプターは、コンパチブル・インターフェース・バスに適応している。インターフェース・アダプターは従来、スロット・アーキテクチャーを通じてインターフェース・バスに接続する。アクセラレイテッド・グラフィックス・ポート（ＡＧＰ）、カード・バス（拡張）、業界標準アーキテクチャ（（Ｅ）ＩＳＡ）、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）、Ｎｕバス、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）、ＰＣメモリ・カード国際協会（ＰＣＭＣＩＡ）及び／またはその他の、従来のスロット・アーキテクチャーを用いればよいが、これらに限定されるわけではない。

記憶インターフェース１１０９は、例えば記憶装置１１１４、リムーバブル・ディスク・デバイス及び／またはその他といった数多くの記憶装置を受け入れ通信し、及び／または接続するが、それらに限定されるわけではない。記憶インターフェースは、例えば（ウルトラ）アドバンスト・テクノロジー・アタッチメント（パケット・インターフェース）（（ウルトラ）ＡＴＡ（ＰＩ））、（拡張）インテグレイテッド・ドライブ・エレクトロニクス（（Ｅ）ＩＤＥ）、電気電子技術者協会（ＩＥＥＥ）１３９４、ファイバー・チャネル、小型コンピュータ用周辺機器インターフェース（ＳＣＳＩ）、ユニバーサル・シリアル・バス（ＵＳＢ）及び／またはその他といった接続プロトコルを用いるが、これらに限定されるわけではない。

ネットワーク・インターフェース１１１０は、通信ネットワーク１１１３を受け入れ通信し、及び／または、接続する。ネットワーク・インターフェースは、例えば直接接続、イーサネット（厚型、薄型、ねじれペア１０／１００／１０００ベースＴ及び／またはその他）、トークン・リング、ＩＥＥＥ８０２．１１ｂ等のワイヤレス接続、及び／またはその他といった接続プロトコルを用いるが、これらに限定されるわけではない。通信ネットワークは、以下に挙げるものの一つ及び／またはそれらの組み合わせである。即ち、ダイレクト・インターコネクション、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、インターネット上のノードとしてのオペレーティング・ミッション（ＯＭＮＩ）、安全化されたカスタム・コネクション、ワイド・エリア・ネットワーク（ＷＡＮ）、ワイヤレス・ネットワーク（例えば、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）、Ｉモード及び／またはその他等のプロトコルを用いるが、これに限定されるわけではない）及び／またはその他である。ネットワーク・インターフェースは、入出力インターフェースの特別な形態であると見なされる。

入出力インターフェース（Ｉ／Ｏ）１１０８は、ユーザー入力デバイス１１１１、周辺機器１１１２、暗号プロセッサ・デバイス１１２８及び／またはその他を受け入れ通信し、及び／または接続する。Ｉ／Ｏは、例えばアップル・デスクトップ・バス（ＡＤＢ）、アップル・デスクトップ・コネクター（ＡＤＣ）、アナログ、デジタル、モノラル、ＲＣＡ、ステレオ、及び／またはその他のオーディオ、ＩＥＥＥ１３９４、インフラレッド、ジョイスティック、キーボード、ミディ、オプティカル、ＰＣ ＡＴ、ＲＳ／２、パラレル、ラジオ、シリアル、ＵＳＢ、それからＢＮＣ、コンポジット、デジタル、ＲＣＡ、Ｓビデオ、ＶＧＡ、及び／またはその他のビデオ・インターフェース、ワイヤレス及び／またはその他といった接続プロトコルを用いるが、それらに限定されるわけではない。一般的な出力デバイスはビデオ・ディスプレイであり、通常、ビデオ・インターフェースから信号を受け取るインターフェース（例えば、ＶＧＡ回路やケーブル）を有するＣＲＴモニターかＬＣＤモニターから成る。ビデオ・インターフェースは、コンピュータの系統的システムが生み出した情報を合成し、合成された情報に基づいたビデオ信号を生成する。通常、ビデオ・インターフェースは、ビデオ・コネクション・インターフェースを通じて合成されたビデオ情報を提供し、ビデオ・コネクション・インターフェースはビデオ・ディスプレイ・インターフェース（例えば、ＶＧＡディスプレイ・ケーブルを受け入れるＶＧＡコネクター等）を受け入れる。

ユーザー入力デバイス１１１１は、カード読み取り装置、ドングル、指紋読み取り装置、手袋、グラフィック・パッド、ジョイスティック、キーボード、マウス（マイス）、トラックボール、トラックパッド、網膜読み取り装置、及び／またはその他といったものである。

周辺機器１１１２はＩ／Ｏに、及び／またはネットワーク・インターフェース、記憶インターフェース及び／またはその他といった他のファシリティに接続し、及び／またはそれらと通信したり、またはそれらと交信したりする。周辺機器とは、カメラ、（コピーの防止、デジタル署名としてトランザクションの安全性を確かなものにする、及び／またはその他のための）ドングル、（追加的な機能としての）外付けプロセッサ、ゴーグル、マイクロフォン、モニター、ネットワーク・インターフェース、プリンター、スキャナー、記憶装置、バイザー及び／またはその他といったものである。

例えばマイクロコントローラ、プロセッサ１１２６、インターフェース１１２７、及び／またはデバイス１１２８のような暗号ユニットをＩＡＭＲＳコントローラに付け、及び／または通信してもよいが、暗号ユニットはこれらに限定されるわけではない。通常モトローラ社製であるＭＣ６８ＨＣ１６マイクロコントローラは暗号ユニットとして使用してもよいし、及び／または暗号ユニット内にあってもよい。同等のマイクロコントローラ及び／またはプロセッサを使用してもよい。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚの設定において１６ビットの積算加算インストラクションを活用し、５１２ビットのＲＳＡ秘密鍵機能を実行するために１秒以下しか必要としない。暗号ユニットは交信エージェントからの通信の認証をサポートすると共に、匿名のトランザクションを可能にする。暗号ユニットはまた、ＣＰＵの一部として設定されていてもよい。他に市販されている専門の暗号プロセッサとしては、ＶＬＳＩテクノロジー社の３３ＭＨｚ６８６８や、セマフォ・コミュニケーション社の４０ＭＨｚのロードランナー２８４がある。
（メモリ）
記憶装置１１１４は、従来のコンピュータ・システムの記憶装置ならばどれであってもい。記憶装置は、固定ハード・ディスク・ドライブ及び／またはその他の装置でよい。しかしながら、ＩＡＭＲＳコントローラ及び／またはコンピュータの系統的システムは、様々な形態のメモリ１１２９を用い得ることは理解されるものである。例えば、コンピュータの系統的システムは、チップ内のＣＰＵメモリ（例えば、レジスタ）、ＲＡＭ、ＲＯＭ、他の記憶装置の機能がパンチ・テープまたは、パンチ・カード・メカニズムによって与えられるように構成されてもよい。もちろん、そのような実施例は好まれるものではなく、動作が極端に遅くなる結果となる。一般的な構成では、メモリ１２９は、ＲＯＭ、ＲＡＭ、記憶装置１１１４を含む。通常、プロセッサが情報の記憶及び／または情報の取り出しを実行することを可能にする機械化及び／または実施化は、メモリ１１２９と見なされる。それゆえ、コンピュータの系統的システムは一般にメモリを必要とし、メモリを使用する。しかしながら、メモリは、代替可能な技術及びリソースであり、それゆえメモリは任意の数の実施例を代替として利用したり、一緒に利用したりできる。
（モジュール・コレクション）
記憶装置１１１４は、プログラム・モジュール及び／またはデータベース・モジュール及び／またはデータといったもののコレクションを含む。それらの例には、オペレーティング・システム・モジュール１１１５（オペレーティング・システム）、情報サーバー・モジュール１１１６（情報サーバー）、ユーザー・インターフェース・モジュール１１１７（ユーザー・インターフェース）、ウェブ・ブラウザ・モジュール１１１８（ウェブ・ブラウザ）、例えばＤＯＩテーブル１１１９ａ、ＵＲＬテーブル１１１９ｂ、（追跡リクエスト、宣伝及び／またはその他の）メタデータ・テーブル１１１９ｃ、多重解決テーブル１１１９ｄ、テーブル１１１９ｅ及び／またはその他のテーブルを含むが、それらには限定されないものを含むデータベース１１１９、暗号サーバー・モジュール１１２０（暗号サーバー）、情報アクセス多重解決サーバー（ＩＡＭＲＳ）モジュール１１２５、及び／またはその他（つまり、全体としてモジュール・コレクション）といったものがあるが、それらに限定されるわけではない。これらモジュールは記憶され、記憶装置及び／またはインターフェース・バスを通じてアクセス可能な記憶装置からアクセスできる。モジュール・コレクションにあるような非従来的なソフトウェア・モジュールは一般的に、かつ望ましくはローカル記憶装置１１１４に記憶されるが、周辺機器、ＲＡＭ、通信ネットワークを通じた遠隔記憶ファシリティ、ＲＯＭ、様々な形態のメモリ及び／またはその他に取り込み及び／または記憶してもよい。
（オペレーティング・システム）
オペレーティング・システム・モジュール１１１５は、ＩＡＭＲＳコントローラの動作を可能にする実行可能なプログラム・コードである。一般的に、オペレーティング・システムは、Ｉ／Ｏ、ネットワーク・インターフェース、周辺機器、記憶装置、及び／またはその他のアクセスを可能にする。オペレーティング・システムは、マイクロソフト・ウィンドウズＮＴサーバー及び／またはユニックス・オペレーティング・システムのような従来型の製品が好ましい。好ましくは、オペレーティング・システムは、非常にフォールト・トレラントであり、拡張可能かつ安全であるのがよい。オペレーティング・システムは、モジュール・コレクション内のそのモジュール自体及び／または類似のファシリティを含む他のモジュールと通信したり、及び／または交信したりする。従来オペレーティング・システムは、他のプログラム・モジュールやユーザー・インターフェース及び／またはその他と通信する。例えば、オペレーティング・システムは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト及び／またはレスポンスを含み、通信、生成、入手及び／または提供する。オペレーティング・システムは一度ＣＰＵによって実行されると、通信ネットワーク、データ、Ｉ／Ｏ、周辺機器、プログラム・モジュール、メモリ、ユーザー入力デバイス及び／またはその他とインタラクションする。好ましくはオペレーティング・システムは、通信ネットワーク１１１３を通じて、ＬＡＭＲＳコントローラが他のエンティティと通信できるようにする通信プロトコルを提供する。ハンドル・システムとインタラクションするためのサブキャリア・トランスポート機構として様々な通信プロトコルが、ＬＡＭＲＳコントローラによって使用される。通信プロトコルとしては例えばマルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト及び／またはその他といったものがあるが、これらに限定されるわけではない。
（情報サーバー）
情報サーバー・モジュール１１１６は、記憶されたプログラム・コードであり、ＣＰＵにより実行される。情報サーバーは、マイクロソフト社のインターネット・インフォメーション・サーバー及び／またはアパッチ・ソフトウェア・ファンデーションのアパッチ等、従来のインターネット情報サーバーでよいが、それらに限定されるわけではない。好ましくは、情報サーバーはＣ＋＋、ジャバ、ジャバスプリクト、アクティブ・エックス、共通ゲートウエイ・インターフェース（ＣＧＩ）スクリプト、アクティブ・サーバー・ページ（ＡＳＰ）及び／またはその他のようなファシリティを通じて、プログラム・モジュールの実行を可能にする。好ましくは、情報サーバーは、安全な通信プロトコルをサポートする。その通信プロトコルは、例えばセキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュア・ソケット・レイヤー（ＳＳＬ）及び／またはその他であるが、これらに限定されるわけではない。従来は、情報サーバーは、結果をウェブ・ページの形でウェブ・ブラウザへ提供し、他のプログラムのモジュールとのインタラクションを通じて手を入れられたウェブ・ページの生成を可能にする。情報サーバーは、そのモジュール自体及び／または同類のファシリティを含むモジュール・コレクション内の他のモジュールへと通信したり、及び／またはそれらと交信したりする。情報サーバーが、オペレーティング・システム、他のプログラム・モジュール、ユーザー・インターフェース、ウェブ・ブラウザ及び／またはその他と通信する頻度は非常に高い。情報サーバーは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
（ユーザー・インターフェース）
ユーザー・インターフェース・モジュール１１１７は記憶されたプログラム・コードであり、ＣＰＵにより実行される。好ましくはユーザー・インターフェースは、オペレーティング・システム及び／またはオペレーティング環境によって、あるいはそれらと一緒に、及び／またはそれらの上に与えられる従来型のユーザー・インターフェースであり、システム及び／またはオペレーティング環境とは、例えばアップル・マッキントッシュＯＳ、アクア、マイクロソフト・ウィンドウズ（ＮＴ）、（ＫＤＥ、Ｇｎｏｍｅ及び／またはその他の）ユニックスＸウインドウズ、及び／またはその他である。ユーザー・インターフェースは画像ファシリティを通じて、プログラム・モジュール及び／またはシステム・ファシリティを表示、実施、インタラクション、操作及び／またはオペレーションすることを可能にしてもよい。ユーザー・インターフェースはファシリティを提供するが、そのファシリティとは、ユーザーが、コンピュータのシステムを実行し、インタラクションし及び／または働くものである。ユーザー・インターフェースは、それ自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールへと通信したり及び／またはそれらと交信する。ユーザー・インターフェースがオペレーティング・システムや他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。ユーザー・インターフェースは、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
（ウェブ・ブラウザ）
ウェブ・ブラウザ・モジュール１１１８は記憶されたプログラム・コードであり、ＣＰＵにより実行される。ウェブ・ブラウザは従来のハイパーテキスト・ビューイング・アプリケーションであることが好ましく、例えば、（好ましくは、ＨＴＴＰＳ、ＳＳＬ及び／またはその他のような１２８ビットの暗号を有する）マイクロソフト・インターネット・エクスプローラーやネットスケープ・ナビゲーターである。ジャバ、ジャバスプリクト、アクティブ・エックス及び／またはその他のようなファシリティを通じて、プログラム・モジュールを実施することが可能なウェブ・ブラウザもある。ウェブ・ブラウザやそのような情報アクセス・ツールは、ＰＤＡ、携帯電話及び／または他のモバイル・デバイスに組み込まれていてもよい。ウェブ・ブラウザは、それ自体及びその他のようなファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／またはと交信する。ウェブ・ブラウザが、情報サービス、オペレーティング・システム、インテグレートされたプログラム・モジュール（例えばプラグ・イン）、及び／またはその他と通信する頻度は非常に高い。例えば、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりするものである。もちろん、ウェブ・ブラウザや情報サーバーの代わりに、両者と同様の機能を持つような複合的なアプリケーションを開発してもよい。複合的なアプリケーションは、ＩＡＭＲＳ対応のノードからユーザー、ユーザー・エージェント及び／またはその他への情報の入手および提供を同様に実行する。複合的なアプリケーションは、標準的なウェブ・ブラウザを用いるシステムに対しては役に立たないこともある。セキュリティを強化するために、そのような複合的なモジュールは、安全性をさらに強化するような中間の情報サーバーが存在しなくても、ＩＡＭＲＳと直接通信するように構成することができる。
（ＩＡＭＲＳデータベース）
ＩＡＭＲＳデータベース・モジュール１１１９は、ＣＰＵにより実行される記憶されたプログラム・コードでデータベース内において具現し得て、記憶されたデータであり、記憶された部分のプログラム・コードが記憶されたデータを処理するためのＣＰＵを設定する。代わりに、リスト、配列、ストラクト及び／またはその他の様々な標準的なデータ構造を用いて、ＩＡＭＲＳデータベースを実施してもよい。仮にＩＡＭＲＳデータベースをデータ構造として実施すると、ＩＡＭＲＳデータベースの使用はＩＡＭＲＳモジュールのような他のモジュールに組み込まれてもよい。ＩＡＭＲＳデータベースは、それ自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／または交信したりする。ＩＡＭＲＳデータベースがＩＡＭＲＳモジュール、他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。データベースは、他のノード及びデータに関する情報を入手し、保持し、提供する。
（暗号サーバー）
暗号サーバー・モジュール１１２０とは、保存されたプログラム・コードであり、ＣＰＵ１１０３、暗号プロセッサ１１２６、暗号プロセッサ・インターフェース１１２７、暗号プロセッサ装置１１２８、及び／またはその他のものにより実行される。暗号プロセッサ・インターフェースが暗号モジュールにより暗号化及び／または暗号解読のリクエストを迅速に実施することを可能にすることが望ましいが、代わりに暗号モジュールを従来のＣＰＵに実行させても良い。暗号モジュールが、供給されたデータの暗号化及び／または暗号解読を可能にすることが望ましい。暗号モジュールが対称及び非対称（例えばＰｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＲ））双方の暗号化及び／または暗号解読を可能にすることが望ましい。暗号モジュールは従来の暗号技術、例えば、デジタル証明（例えば、Ｘ．５０９認証枠組み）、デジタル署名、複式署名、エンベロッピング、公開鍵管理、及び／またはその他のものを可能にすることが望ましいが、暗号技術はそれらに限定されるわけではない。暗号モジュールは数々の暗号化及び／または暗号解読プロトコル、例えば、データ暗号化基準（ＤＥＳ）、楕円曲線暗号化（ＥＣＣ）、国際データ暗号化アルゴリズム（ＩＤＥＡ）、メッセージ・ダイジェスト５（ＭＤ５、即ち一方向ハッシュ関数）、ＲＣ５（リベスト暗号）、リジンデール、ＲＳＡ（インターネット暗号化及び認証システムで、１９７７年にロン・リベスト、アデイ・シャミル及びレオナルド・エイドウルマンが開発したもの）、セキュア・ハッシュ・アルゴリズム（ＳＨＡ）、セキュア・ソケット・レイヤー（ＳＳＬ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、及び／またはその他のものを可能にすることが望ましいが、暗号化及び／または暗号解読プロトコルはそれらに限定されるわけではない。暗号モジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中には暗号モジュール自体及び／その他のファシリティも含まれる。暗号モジュールは、通信ネットワーク上での情報の安全な転送を可能にする暗号化方式を支援することが好ましく、もしユーザーが希望すれば、ＩＡＭＲＳモジュールが安全なトランザクションに用いられ得るようにする。暗号化モジュールが情報サーバー、オペレーティング・システム、その他のプログラム・モジュール及び／またはその他のものと交信する頻度は非常に高い。暗号化モジュールはプログラム・モジュール、システム、ユーザー及び／またはデータの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成、入手及び／または提供したりする。
（情報アクセス多重解決サーバー）
ＩＡＭＲＳモジュール１１２５は保存されたプログラム・コードであり、ＣＰＵにより実行される。一般にＩＡＭＲＳは、通信ネットワーク上のノード間における情報のアクセス、入手、提供、及び／またはその他を実行する。ＩＡＭＲＳはＵＮＩを多重のインスタンス化へと解決する能力を有している。一般に、ＩＡＭＲＳはルックアップ・ファシリティとして役を果たし、与えられた情報、そのＵＮＩ、及びその現在の場所との間の関連性の作成、維持、登録、及び更新を行う。ＩＡＭＲＳはＩＡＭＲＳデータベースと提携して、リクエストされた情報のデータ転送の向上、リクエストされた情報の種々のフォーマットへの解決、情報についてのクエリー作成用の強化されたメカニズムの提供及び／またはその他に役立つと思われるノードを識別する。ＩＡＭＲＳによるノード間の情報アクセス可能化の開発にあたっては、標準開発ツールを使用してもよい。例えば、Ｃ＋＋、シェル・スクリプト、ジャバ、ジャバ・スクリプト、ＳＱＬコマンド、ウエブ・アプリケーション・サーバー・エクステンション、アパッチ・モジュール、パール・スクプリト、バイナリ・エクセキュータブル、及び／またはその他のマッピング・ツール及び／またはその他を用いることができるが、それらに限定されるわけではない。一つの非限定的な実施例においては、ＩＡＭＲＳサーバーは暗号サーバーを用いて通信の暗号化及び暗号解読にあたっている。ＩＡＭＲＳはリクエストのサービス、ＵＮＩのための関連性情報の更新、ＵＮＩの登録、その他多くのことにあたることができる。ＩＡＭＲＳモジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中にはＩＡＭＲＳモジュール自体及び／またはその他のファシリティも含まれる。ＩＡＭＲＳモジュールがＩＡＭＲＳデーターベース、オペレイティングシステム、その他のプログラム・モジュール及び／またはその他と交信する頻度は非常に高い。ＩＡＭＲＳはプログラムモジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンス等を含んだり、通信、生成、入手及び／または提供したりする。
（分散型ＩＡＭＲＳ）
ＩＡＭＲＳノード・コントローラの構成要素は何れもあらゆる方法で、その機能性を組み合わせ、統合及び／または分散することが可能であり、開発及び／または配備を可能にすることができる。同様に、モジュール・コレクションも開発及び／または配備を可能にすべくあらゆる方法で組み合わせることができる。これを達成するには、単に各構成要素を共通のコード・ベースに統合するか、あるいは必要に応じて統合的に構成要素をダイナミックにロードできるファシリティに統合すれば良いのである。

モジュール・コレクションを統合及び／または分散するにあたっては、標準的なデータ処理及び／または開発技術を介した無数のバリエーションがある。プログラム・モジュール・コレクション中の何れのプログラムの多重のインスタンスをも単一のノードでインスタンス化でき、及び／または負荷バランシング・データ処理技術を通し、多数のノードを使用し性能を向上することもできる。更に、単一のインスタンスもまた複数のコントローラ及び／または記憶装置、例えばデータベースに分散することができる。

全てのプログラム・モジュールのインスタンスとコントローラは、標準的なデータ処理通信技術を通じ、共同作業を行う。

好ましいノード・コントローラの構成は、システム配備のコンテキストによって異なる。例えば、元となるハードウェア・リソースの能力及び／または場所等のファクターが配置条件や構成に影響するが、こうしたファクターはそれらに限定されるわけではない。例え構成がプログラム・モジュールを合同及び／または統合する結果になろうが、分散化されたプログラム・モジュールより成り立つ結果になろうが、及び／または統合型と分散型の何らかの組み合わせになろうが、データの通信にあたっては、通信、入手、提供が可能である。プログラム・モジュール・コレクション中からの共通コード・ベースに統合された（モジュール・コレクション中の）モジュールのインスタンスは、データの交信、入手及び／または提供にあたることができる。これは、例えば、データ・レファレンシング（例えば、ポインタ等）、内部メッセージ、オブジェクト・インスタンス可変通信、共有メモリ・スペース、可変パッシング及び／またはその他のもの（アプリケーション内部の通信）等の基準データ処理技術を用いることにより達成されるが、これらに限定されるわけではない。

もしモジュールコレクションの構成要素がお互いに個別的、分離的、及び／または外部的である場合は、データの通信、入手、及び／または提供を他のモジュール構成要素と行う及び／または他のモジュール構成要素へと行うにあたっては、標準的なデータ処理技術を用いればよい。標準的なデータ処理技術には例えば、アプリケーション・プログラム・インターフェース（ＡＰＩ）情報パッセージ；（分散型）コンポーネント・オブジェクト・モデル（（Ｄ）ＣＯＭ）、（分散型）オブジェクト・リンキング・アンド・エンベディング（（Ｄ）ＯＬＥ）、及び／またはその他のもの）、コモン・オブジェクト・リクエスト・プロバイダー・アーキテクチャー（ＣＯＲＢＡ）、プロセス・パイプ、共有ファイル及び／またはその他のもの（アプリケーション内部の通信）があるが、これらに限定されるわけではない。この場合もまた、好ましい実施例はシステム配備のコンテキスト次第である。
（多重解決）
第１５図を参照すると、本発明の一つの特徴に基づくシステム及び方法の実施にふさわしいシステム１５１０が図示してある。一般に、システム１５１０には、適宜なマイクロプロセッサに基づく装置２０が含まれ、これには第１４図の場合においてはパソコン（ＰＣ）が用いられていて、通信チャネル１５２５を通し、通信ネットワーク１５３０と交信できるようになっている。通信チャネル１５２５は、第１４図のＩ／Ｏ１１０８もしくはネットワーク・インターフェース１１１０を通して設けることができる。また、通信チャネル１５３２を通しての通信ネットワーク１５３０との交信が可能なものには、ＤＯＩ登録サーバー１５４０及びサーバー１５５０Ａ−１５５０Ｃがある。もちろん、装置１５２０、サーバー１５４０及びサーバー１５５０Ａ−１５５０Ｃの数は説明の目的用のみである。同様に、サーバー１５４０及び１５５０Ａ−１５５０Ｃは、単一装置として示されているが、当然のことながら、これらは多重装置でも分散型サーバー・システムの形態をとっても良い。
引き続き第１５図を参照すると、装置１５２０のユーザーは、ＤＯＩシステムにＤＯＩ解決のリクエストが出されるようにするには、マイクロソフト社のインターネット・エクスプローラーやネットスケープ・ナビゲーター等のブラウザ・ソフトウェアを使用してＤＯＩを直接装置に入力してもよいし、ユーザーがＤＯＩのリクエストを直接入力できるような適宜なエクステンションまたは能力を有するブラウザ・ソフトウェアを使用してＤＯＩを直接装置に入力してもよいし、ユーザーに代わってＤＯＩリクエストを作る能力のあるソフトウェアを使用してもよい。装置１５２０はリクエストをＤＯＩサーバー１５４０に通信する。これに対して、ＤＯＩサーバー１５４０は一個またはそれ以上のデータベース１５４５にクエリーをして、リクエストされたＤＯＩと関連した記録を識別する。データベース１５４５はサーバー１５４０上、またはサーバー１５４０がアクセスできる場所ならどこにでも格納できる。単一解決の例としては、電子ドキュメントに関連したＵＲＬ、サーバー１５５０Ａ（ＵＲＬ５０Ａ）経由で使用可能またはサーバー１５５０Ａが管理するその他のコンテンツに関連したＵＲＬがあげられる。ＤＯＩサーバー１５４０は、ＵＲＬ５０Ａを装置１５２０に提供することにより、あるいは、その代わりに装置１５２０を例えばサーバー１５５０Ａと通信するというようなブラウザ・リダイレクト指令により宛先を変更して、装置１５２０をサーバー１５５０Ａへとリダイレクトする。そこでサーバー１５５０Ａは、リクエストされたＤＯＩに関連のある電子ドキュメント及びその他のコンテンツを装置１５２０に提供する。多重解決の場合には、装置２０は、入力されたリクエストをサーバー１５４０に通信すると、一個の、または数個の、または任意の数の多重解決へと導かれる。例えば、ＵＲＬ５０Ａまたは、ＵＲＬ５０ＢもしくはＵＲＬ５０Ｃのようなサーバー１５５０Ｂもしくは１５５０Ｃと関連のあるＵＲＬである。解決リクエストの結果は必ずしもＵＲＬもしくはネットワーク位置へのポインターとは限らない。ＤＯＩが割り当てられたワークと関連のある情報であるかもしれない。例を挙げるなら、参考文献情報、暗号解読の鍵、または当該ワークと関連したサービスをアクセスする手段であるかもしれない。

本発明の別の特徴によると、ユーザーからの解決リクエストの種類またはＤＯＩシステムへのその他の引数はＤＯＩリクエストに統合される。引数はＤＯＩのプレフィックスもしくはサフィックスとなることもあれば、タグ付きフォーマット済み付きのテキストとして渡されることもあれば、単一のもしくは多重の適切な解決をリクエストするために用いられる。応用の例を挙げると、異なった業者から購入することによる売り上げの促進、登録されたワークの異なるフォーマットの供給、権利処理、認可及び再使用リクエストの処理、正当性確認、メタデータ・リクエストのサービス、機密保全、登録されたワークの適当なコピーを届けるため及び価格問い合わせのサービスを可能にすること等である。

意味を明確にするために、ＤＯＩシステムに引数を足したＤＯＩは、ここでは強化ＤＯＩと呼ぶことにする。一般に、本発明の特徴の一つによると、強化ＤＯＩはＸＸＸＸ＠１０：１０００／ａｂｃ１２３ｄｅｆｇの形態をとることができる。この場合、ＸＸＸＸはＤＯＩシステムへの一つの引数または引数のリストである。

本発明の他の特徴として、強化ＤＯＩはユーザーに供給される。これは、ユーザーに配信できるように第三者に供給したり、他のウエブサイトに掲示したり、従来の方式で発行されるワーク及びパッケージにプリントしたり、あるいは、電子的にまたはディスケット、コンパクト・ディスク（ＣＤ）等の有形の記憶媒体を通してユーザーに届けることにより達成される。更に、強化ＤＯＩは、例えば記事や電子メール等の他のコンテンツ中に埋め込むことができる。これらの非限定的なの例は単に説明の目的ために記載しただけなので、もちろん強化ＤＯＩをユーザーに供給できる確実な方法ならどの様なものを用いてもよい。ＤＯＩをリクエストしたいと望んでいるユーザーは、通信された強化ＤＯＩをアクティベートするか、そのためのリクエストを提出し、すると強化ＤＯＩは今迄に示してきたように、リクエストしたユーザーの装置に対して適宜な単一解決または多重解決を供給することに用いられる。

第１６図を参照すると、本発明の他の特徴によると、登録されたタイプ及び関連したタイプの値もやはり保存され、サーバー１５４０がアクセスできるようになっている（第１５図参照）。登録タイプ及びタイプの値は例を挙げると、データベース１５４５、または第１４図の１１１９、またはサーバー１５４０がアクセスできる他のデータベース（第１５図参照）に保存できる。従って、ＤＯＩ登録は強化ＤＯＩの解決ができるようになる。理由はその中に、種々の登録タイプを対応するタイプの値に解決するために使用されるデータを含んでいるからである。

引き続き第１６図を参照すると、本発明の一つの特徴に基づくＤＯＩシステムのオペレーションの概要１６１００が示されている。ここでは、発行者１６１１０が強化ＤＯＩ登録データを提供している。つまり、強化ＤＯＩを登録機関１６５５５に通信１６１１２として登録している。登録機関はそこでＤＯＩ及び関連するタイプとバリューのペアをＤＯＩディレクトリ１６１２０に通信１６５５６として登録する。発行者１６１１４は、登録された強化ＤＯＩをユーザー１６１３０に提供する。ユーザー１６１３０は、ＤＯＩレジストリ１６１２０に、通信１６１２４として、登録された強化ＤＯＩのリクエストを提出する。ＤＯＩレジストリ１６１２０は、通信１６１２６として、登録された強化ＤＯＩの解決１６１４０を示すデータをユーザー１６１３０に提供するか、または、ユーザー１６１３０を解決１６１４０に導く。そこで、ユーザー１６１３０は、解決１６１４０を通信１６１３５としてアクセスすることになる。ここで了解すべきことは、解決１６１４０は、登録された強化ＤＯＩに対する種々の可能な解決の一つに過ぎないということである。例を挙げるなら、解決の解析はクライアントの場所、プロキシ、サーバー、その他で行うことができる。

再び第１５図を参照すると、更に、本発明が登録された著作物、即ちコンテンツの購入にかかわる例を用いて詳しく示されている。強化ＤＯＩの登録されたタイプの一つが「購入」ということがあり得る。これまでに述べてきたように、データベース１５４５、第１４図においては１１１９はサーバー１５４０に使用され、通信されたＤＯＩに対しての解決を提供している。もちろん、認識し易いテキストの代わりに、任意の識別コードを使用してもよい。例えば、「１」、「Ａ」、その他の文字列等、登録者が購入リクエストと同一視する旨意図した記号である。この種の記号をタイプを多数登録し対応する数多くの業者に割り当てることができる。「ＡＭＡＺＯＮ」、「ＰＲＥＦＥＲＲＥＤ」、「１」等、リクエストのタイプ等から成り立つ文字列や更に追加の文字列を用いてもよい。購入リクエストのために多くの異なる業者へと導くそのような強化ＤＯＩの例を挙げると、業者の一人からの購入には、ＰＵＲＣＨＡＳＥ．ＡＭＡＺＯＮ＠１０．１０００／ａｂｃ１２３ｄｅｆｇ、またはＰＵＲＣＨＡＳＥ．ＶＥＮＤＯＲ_１＠１０．１０００／ａｂｃ１２３ｄｅｆｇ、またはＡ．１＠１０．１０００／ａｂｃ１２３ｄｅｆｇという形を採り、そして別の業者からコンテンツを購入するにあたっては、ＰＵＲＣＨＡＳＥ．ＢＮ＠１０．１０００／ａｂｃ１２３ｄｅｆｇ、またはＰＵＲＣＨＡＳＥ．ＶＥＮＤＯＲ_２＠１０．０００／ａｂｃ１２３ｄｅｆｇ、またはＡ．２＠１０．０００／ａｂｃ１２３ｄｅｆｇという形を採ることができる。

リクエストのタイプ（例えば、「ＰＵＲＣＨＡＳＥ．１」）の名前の階層的構築は、ハンドル・システムがそのようなリクエストが何種類もある「購入」の一つであるということを理解できることを必ずしも意味しない。実際現在のハンドル・システムは、リクエストされたタイプの名前が所与のＤＯＩ記録中のタイプとバリューのペアとはっきりと一致した時にのみ、一つまたは複数のバリューを返信することができるようになっている。しかしながら、そのような名前の階層的構築により、より洗練されたクライアント・ソフトウェアにおいてタイプとバリューのペアをまとめて有益な目的にあてることができる。例えばＤＯＩレジストリは、リクエストされたタイプがタイプ・リストと正確に一致した時にのみバリューを返信してくるが、より洗練されたクライアントにおいては、例えば与えられたＤＯＩに関連するタイプとバリューのペアを全部リクエストし、「購入」という言葉で始まる可能な解決を全部選び出し、これらのみを選択肢としてユーザーに提供する。この階層的に構築した名前の利用は下記の他の応用例全てにおいて適用されている。

従って、本発明の強化ＤＯＩは、リクエストを出したユーザーを、異なる業者に対応する多重解決の任意の数の異なるもの、または異なるクラスに永続的にまた選択的に導くことに使用できる。

強化ＤＯＩを使用したリダイレクトの度合いは、発行者にとって有益である。例を挙げると、仮に、ＰＵＲＣＨＡＳＥ_ＰＲＥＦＥＲＲＥＤ＠１０．１０００／ａｂｃ１２３ｄｅｆｇという形態の強化ＤＯＩが登録され、数多くのユーザーに例えばＣＤ等の大量分布により提供されたとすると、有利なことに、登録者は敏速かつ簡単に各々のユーザーの購入プロセスを透過的に更新することができる。例えば、ＣＤが最初に配布された際、登録者が最初のオンライン業者からユーザーがコンテンツを購入するように、もしくは代わりに第二のオンライン業者へ、その順序で導きたいと希望したとする。仮に登録者が今度はユーザーを第二のオンライン業者へ、それから代わりに第一のオンライン業者へ、その順序で導きたいと希望する場合、登録者はＤＯＩレジストリが使用するデータベースへのエントリーを再配列すればよい。

本発明によると、この必要性はなくなる。更にこのアプローチにより登録者はダイナミックに長期にわたり、リダイレクトをコントロールすることができる。例えば登録者は、将来のある時点において、望ましい購入アウトレットの宛先（タイプ・バリュー）を変更して、「優先購入先」ＤＯＩは全て、古い販売アウトレットではなく、新しい優先販売アウトレットに宛先を変えることができる。

本発明の特徴の一つによると、業者の数は幾らでも発行者の好みの順序でＤＯＩ記録に記録することができる。例えば、「ＰＵＲＣＨＡＳＥ．１＠１０．１０００／ａｂｃ１２３ｄｅｆｇ」はＡｍａｚｏｎ．ｃｏｍの一つのページに解決され得るが、「ＰＵＲＣＨＡＳＥ．２＠１０．１０００／ａｂｃ１２３ｄｅｆｇ」はＢａｒｎｅｓａｎｄｎｏｂｌｅ．ｃｏｍの一つのページのＵＲＬに解決するかもしれない。「ＰＵＲＣＨＡＳＥ．３＠１０．１０００／ａｂｃ１２３ｄｅｆｇ」はオンライン書籍販売業者であるＦａｔＢｒａｉｎ．ｃｏｍの購入ページのＵＲＬに解決されることもあり得る。このような方法で、業者の数は幾らでも好みの順序でリストすることができる。もし発行者がこのリストの順位を変更したい場合はいつでも、対応するタイプとバリューのペアの値を変えることができ、そうすることによって、「ＰＵＲＣＨＡＳＥ．２＠１０．１０００／ａｂｃ１２３ｄｅｆｇ」へのリクエストは、例えば、オンライン書籍販売者であるＦａｔＢｒａｉｎ．ｃｏｍの購入ページに解決され、一方ＢａｒｎｅｓａｎｄＮｏｂｌｅ．ｃｏｍよりその本を購入するためのＵＲＬは、例えば「ＰＵＲＣＨＡＳＥ．３＠１０．１０００／ａｂｃ１２３ｄｅｆｇ」に割り当てられることになる。このようにして、発行者は各ＤＯＩの優先業者のリストをダイナミックにコントロールできる。このアプローチはまた、ここで説明される全ての多重解決の応用例にまでわたるようにすることができる。

本発明の別の特徴の一つによると、コンテンツの異なるフォーマットを識別するために、別のタイプを使うことができる。例えば、文学作品は種々の異なる電子フォーマットで入手できる。代表的なものには、ＲｏｃｋｅｔｂｏｏｋやＥ−ｂｏｏｋコンパチブル・フォーマット、Ａｄｏｂｅ Ｓｙｓｔｅｍ社が開発したＰｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ （ＰＤＦ）等がある。登録者にとっては、一つのＤＯＩでこれらのフォーマットを永続的にまた安易に識別できることが望ましい。こうした場合には、例えばＦＯＲＭＡＴ．１＠１０：ＹＹＹＹ／ＺＺＺ、ＦＯＲＭＡＴ．２＠１０：ＹＹＹＹ／ＺＺＺまたはＦＯＲＭＡＴ．３＠１０：ＹＹＹＹ／ＺＺＺの強化ＤＯＩを指定することができる。

権利処理のリクエストは発行者にとって相当な仕事を意味する。権利処理のリクエストを処理するにあたっては、例えば再使用のリクエストに応えることと共に、関連分野は当然とみなされているその他従来の権利処理のリクエストが含まれる。本発明の別の特徴の一つによると、登録された別のタイプが、例えば「ＲＣ」といった権利認可のリクエストの形態をとることができる。対応するタイプのバリューにはどのタイプの権利認可が求められているかが含まれることもある。例えば、再使用のリクエストはタイプのバリュー「１」ということもある。そのような場合には、強化ＤＯＩはＲＣ．１＠１０：ＹＹＹＹ／ＺＺＺの形態をとることができる。

本発明のもう一つの特徴として、強化ＤＯＩは登録されたコンテンツの正当性確認に使用することができる。電子ドキュメント等のコンテンツの正当性確認の具体的な方法は、よく知られている。使用に適したテクニックにおいては、基本的に登録されたコンテンツの構成に基づいた固有の数の計算を用いる。そこで当該固有な数と関連のある公開コードが発行される。計算は、当該公開コードと当該固有の数を用いて後日行うことができる。バージニア州レストン市のＳＵＲＥＴＹ．ＣＯＭは、デジタル・ノータリー・サービスと呼ばれるそのようなサービスを提供しており、これは１９９２年８月４日発行の米国特許番号５，１３６，６４７及び、米国特許Ｒｅ．３４，９５４で説明されており、これらの開示の全体は参照により本開示に含まれる。強化ＤＯＩ「ＡＵＴＨＥＮＴＩＣＡＴＥ＠１０.１０００／ａｂｃ１２３ｄｅｆｇ」の解決をリクエストすると、ユーザーは当人が持つコンテンツの正当性確認をすることができるサービスへとリダイレクトされる。

本発明の別の特徴によると、強化ＤＯＩはメタデータのリクエストのサービスに用いることができる。ここで用いられるメタデータとは、登録されたコンテンツに関するデータを指す。このようなメタデータには、例えば著者、発行者、初版日、参考リスト、要約及びその他の有用な情報を含むことができる。本発明の別の特徴によると、登録されたタイプは「ＭＥＴＡＤＡＴＡ」の形態をとることができる一方、これに対応するバリュー・タイプは、例えば使用可能なメタデータのサブ・グループを指定したりする。これは、異なったユーザーに異なったレベルのメタデータの特異性を提供するにあたって利用することができる。例えば、登録されたタイプ・バリュー「ＡＬＬ」は使用可能なメタデータ全てを指定する一方、別の登録されたタイプ・バリュー「ＡＮＡＬＹＳＩＳ」は、ＤＴＤ（ドキュメント・タイプの定義）そのものを返信してくる、といったものである。これらの強化ＤＯＩの解決として、例えば異なる方法で構築されたＵＲＬを用いることにより、発行者はよく知られたテクニックを用い、メタデータのセット及びサブ・セットを提供することができる。ＭＥＴＡＤＡＴＡ．ＡＬＬ＠１０：ＹＹＹＹ／ＺＺＺ及びＭＥＴＡＤＡＴＡ．ＡＮＡＬＹＳＩＳ＠１０：ＹＹＹＹ／ＺＺＺのような強化ＤＯＩは、本発明の特徴の一つにより効果的に使用することができる。

本発明の別の特徴によると、強化ＤＯＩは暗号鍵のリクエストのサービスに用いることができる。ここで言う暗号鍵とは、暗号を解読するために用いられる鍵のことである。このような鍵は暗号サーバーに関して図１４で記載したように暗号化の技術に用いることができる。これは、ハンドル・システムに保存された公開／秘密の鍵のペアの公開鍵や秘密鍵を異なった方法で入手するために用いることができる。、このような強化ＤＯＩの利用は、ありとあらゆる一般的な暗号化機能を可能にするだけではなく、正当性の確認、ユーザーのアイデンティティの確認及び／またはその他により、ディジタル権利管理の応用において、ロバストな解除鍵・メカニズムを提供する。例えば、登録したタイプのバリュー「ＰＵＢＬＩＣ＿ＫＥＹ」及び「ＰＲＩＶＡＴＥ＿ＫＥＹ」は、解決後公開及び秘密の鍵を指定し返信することができる。

本発明の別の特徴によると、強化ＤＯＩはＤＯＩ記録の管理に用いることができる。ここでいう管理とは、ＤＯＩレジストリ１７２２０及びＤＯＩ強化レジストリ１７２５０の何れかまたは双方に保存されたＤＯＩレコードをアクセス、維持、及び更新することを指す。このような管理はＤＯＩレジストリ自体の更新を可能にするためにも用いることができる。これは、ハンドル・システムに保存されたバリューのアクセス及び更新に用いることもできる。例えば、登録されたタイプのバリュー「ＡＤＭＩＮ」は、特定のＤＯＩの管理情報を指定し返信することができる。これらの強化ＤＯＩ解決として、例えば異なる方法で構築されたＵＲＬを用いることにより、（強化）ＤＯＩを発行者の管理することが可能な場所へと、よく知られたテクニックを用いて発行者をリダイレクトすることができる。ＡＤＭＩＮ．１＠１０．１０００／ａｂｃ１２３ｄｅｆｇ及びＡＤＭＩＮ．２＠１０．１０００／ａｂｃ１２３ｄｅｆｇのような強化ＤＯＩは、本発明の特徴の一つにより効果的に使用されることができる。

本発明の別の特徴によると、強化ＤＯＩは、いわゆる「ハーバード問題」を解決し、登録されたワークの適切なコピーが配信されるようにすることができる。図書館業界で「ハーバード問題」とか「適切コピー」問題として知られているが、大学図書館の希望として、ユーザーがメタデータのクエリーを出し、その結果としてある場所でコンテンツのコピーを見出した場合、発行者より直接入手するのではなく、第三者サービスを通じ大学が購読することによって、アクセス権利を管理し使用をモニターできるようにするというものである。本発明の特徴の一つによると、登録したＤＯＩの対応するタイプ及びタイプのバリューを使用して、適切なコピーを提供することができる。本発明の別の特徴によると、ワークの複数のコピーは多重の場所に保存でき、使用可能な各コピーの反応をモニターするソフトウェアをクライアント側で開発することにより、強化ＤＯＩを最適のアベイラビリテイ及びパフォーマンスの向上を確保するために用いることができる。（例えば、各々を順番にリクエストし、各々のレスポンス・タイムを計ることにより、その後に続くリクエストはデフォルトとして最初にそのコピーに導かれることになる）。

本発明の別の特徴によると、購入リクエストと同様に、強化ＤＯＩは価格リクエストをサービスするために用いることができる。登録されたタイプは、例えば「ＰＲＩＣＥ」の形態をとることができる。対応するタイプのバリューも、価格に関した物質的情報の指定にあたって使用でき、その例は、リクエストしているユーザーが割引の適応を受けることができるかどうか等である。このような場合、強化ＤＯＩ、例えば、ＰＲＩＣＥ．１＠１０．１０００／ａｂｃ１２３ｄｅｆｇを使い、タイプのバリュー「１」と関連した区分の価格を得る資格のあるユーザーが登録されたコンテンツの価格をリクエストすることができる。これにより、所有者はダイナミックな価格付けを長期的に実施することができ、それによって期間限定のオファー、臨時セール等も実施可能になると共に異なる価格指定（例えば、ＰＲＩＣＥ．１、ＰＲＩＣＥ．２等）を用いることにより、異なった価格設定をすることができる。

ここで理解すべきことは、上記の記載は単に実施例の説明のためだけのものであるということである。読者の便宜上、上述の記載は、本発明の原理を教える上でのサンプルで、全ての可能な実施例の内の代表的なサンプルに焦点をあてたものである。記載にあたっては、可能なバリエーションの全てを徹底的に列挙したわけではない。本発明の特定の部分に対して実施例を他に示さなかったこと、または、ある部分に関して記載されていない他の実施例があり得ることが、これらの他の実施例を否認することになる、と考えるべきではない。記載されていない実施例の多くは本発明と同じ原理のものであり、またあるものは同様のものであると理解できる。従って、ここに示されたり記載されたりした実施例及びそのバリエーションは、単に本発明の原理を示すものであり、種々の変更が本発明の範囲及びその精神から逸脱することなく実施できるということを理解するべきである。

移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを示す図。 移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを示す図。 ＤＯＩを介した情報へのアクセスを示す図。 ハンドルの概要を示す図。 ハンドルの概要を示す図。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示す図。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示す図。 ユーザーがＤＯＩを用いて情報をアクセスするために行う一連のアクションの概要を示す図。 ユーザーがＤＯＩを用いて情報の内容をアクセスするために行う一連のアクションのより完全な概要を示す図。 通信ネットワーク上で情報をアクセスするための典型的なメカニズムを示す図。 通信ネットワーク上で情報を入手するための典型的なメカニズムの別の実施例の概要を示す図 ＤＯＩシステムの概要を示す図。 様々なエンティティとインタラクションする情報アクセス多重解決サーバー（ＩＡＭＲＳ）１４００６の非限定的な例を示す図。 ＩＡＭＲＳコントローラに組み込まれた一実施例を示す図。 情報への多重解決アクセスを提供するグラフ・トポロジーの非限定的な一例 情報の多重解決登録及び情報への多重解決アクセスを提供するグラフ・トポロジーの非限定的な一例を示す図。

符号の説明

１１０３ ＣＰＵ
１１１４ 記憶装置
１１１９ ＩＡＭＲＳデータベース

Claims (11)

1. リソースへのアクセスを可能にする方法であって、
   第１コンピュータのプロセッサが、前記リソースに関する特定の情報を識別すると共に前記リソースに固有で永続的なユニバーサル・ネーム識別子と前記特定の情報を表す引数を含む第１識別子をインターネット上の第１場所アドレスに関連付けて前記第１コンピュータの第１ディレクトリに登録する第１登録ステップと、
   前記プロセッサが、前記第１識別子の解決要求を、ネットワークを介して、第２コンピュータから受信する第１受信ステップと、
   前記プロセッサが、前記第１受信ステップで受信した前記第１識別子に含まれる前記リソースに固有で永続的なユニバーサル・ネーム識別子と前記引数を使用して前記第１ディレクトリから前記第１識別子を前記第１場所アドレスに解決する第１データを取得する第１取得ステップと、
   前記プロセッサが前記第１データを、前記ネットワークを介して前記第２コンピュータに送信するステップと、
   を有することを特徴とする方法。
2. 前記特定の情報は、前記リソースを購入するための情報、前記リソースのフォーマットの情報、前記リソースの権利に関する情報、前記リソースの有効性の情報、前記リソースのメタデータの情報、前記リソースを解読する鍵の情報のうち少なくとも一つを含むことを特徴とする請求項１に記載の方法。
3. 前記引数は、前記特定の情報の種類と値を表すことを特徴とする請求項１に記載の方法。
4. 前記リソースに固有で永続的なユニバーサル・ネーム識別子は、デジタル・オブジェクト識別子であることを特徴とする請求項１に記載の方法。
5. 前記第１登録ステップは、前記リソースのメタデータを更に登録し、
   前記第１受信ステップで受信した前記第１識別子の解決要求は前記リソースのメタデータを含み、
   前記第１取得ステップにおいて、前記プロセッサは前記メタデータを更に使用することを特徴とする請求項１に記載の方法。
6. 前記第１場所アドレスはインターネット上の複数の場所アドレスからなることを特徴とする請求項１に記載の方法。
7. 前記プロセッサは、前記第１ディレクトリにおける前記複数の場所アドレスの配列を変更するステップを更に有することを特徴とする請求項６に記載の方法。
8. 前記プロセッサが、前記引数を含まない前記リソースに固有で永続的なユニバーサル・ネーム識別子である第２識別子をインターネット上の第２場所アドレスに関連付けて前記コンピュータの第２ディレクトリに登録する第２登録ステップと、
   前記プロセッサが、前記第２識別子の解決要求を、前記ネットワークを介して前記第２コンピュータから受信する第２受信ステップと、
   前記プロセッサが、前記第２受信ステップで受信した前記第２識別子に含まれる前記リソースに固有で永続的なユニバーサル・ネーム識別子を使用して前記第２ディレクトリから前記第２識別子を前記第２場所アドレスに解決する第２データを取得する第２取得ステップと、
   前記プロセッサが、前記第２データを、前記ネットワークを介して前記第２コンピュータに送信するステップと、
   を有する請求項１に記載の方法。
9. 前記第２登録ステップは、前記リソースのメタデータを更に登録し、
   前記第２受信ステップが受信する前記第２識別子の解決要求は前記リソースのメタデータを含み、
   前記第２取得するステップにおいて、前記プロセッサは前記メタデータを更に使用することを特徴とする請求項８に記載の方法。
10. ネットワークに接続され、プロセッサと第１ディレクトリを有する第１コンピュータに、
    前記プロセッサを介して、前記リソースに関する特定の情報を識別すると共に前記リソースに固有で永続的なユニバーサル・ネーム識別子と前記特定の情報を表す引数を含む第１識別子をインターネット上の第１場所アドレスに関連付けて前記第１ディレクトリに登録する機能と、
    前記プロセッサを介して、前記第１識別子の解決要求を、前記ネットワークを介して、第２コンピュータから受信する機能と、
    前記プロセッサを介して、受信した前記第１識別子に含まれる前記リソースに固有で永続的なユニバーサル・ネーム識別子と前記引数を使用して前記第１ディレクトリから前記第１識別子を前記第１場所アドレスに解決する第１データを取得する機能と、
    前記プロセッサと前記ネットワークを介して、前記第１データを前記第２コンピュータに送信する機能と、
    を実現させるためのプログラム。
11. プロセッサと、当該プロセッサに通信するように接続されていると共に請求項１０に記載のプログラムを格納したメモリと、を有することを特徴とするコンピュータ。