JP4401074B2 - デジタル権利管理情報にアクセスするための装置、方法及びシステム - Google Patents

Description

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

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

ここに開示する発明は、デジタル権利管理システムによって保護されているデジタル著作物にアクセスするための装置、方法及びシステムである。より詳しくは、ここに開示する発明は、デジタル・オブジェクト識別子をデジタル権利管理システムに組み込み、システムをより耐久性があるものにし、多重解決、レポート、ウォーターマーキング、有効性確認の機能を提供する。

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

［ネットワーク］
一般にネットワークは、クライアント、サーバー及びグラフ・トポロジーにおける中間のノードの相互接続と相互運用から成ると考えられている。注意すべきことは、ここでは「サーバー」という用語は通常、通信ネットワーク全体の遠隔ユーザーのリクエストを処理したりそれに応答したりするためのコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせを指すということである。サーバーはリクエストしてくる「クライアント」に情報を提供する。情報やリクエストを可能にしたり、処理、及び／またはソース・ユーザーからデスティネーション・ユーザーへの情報の流れを支援するコンピュータ、その他の機器、ソフトウェア、またはそれらの組み合わせは、通常「ノード」と呼ばれる。ネットワークは一般的にソース・ポイントからデスティネーションへの情報の転送を可能にするものと考えられている。
［伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）］
コンピュータ・システム、データベース及びコンピュータ・ネットワークの拡散と拡大は、一般的にインターネットと称されるそのようなシステムの相互接続と国境を越えた通信ネットワークによって促進されてきた。インターネットは伝送制御プロトコルとインターネット・プロトコル（ＴＣＰ／ＩＰ）を発展させ、またその大部分においてそれらを用いている。ＴＣＰ／ＩＰは様々な変化するネットワーク業者によって形成された複数のネットワークを、ネットワークのネットワークのための基礎として相互接続するための、つまりインターネットのための米国国防総省（ＤｏＤ）の研究プロジェクトによって開発された。一つにはＤｏＤが、戦闘の最中に損害を受けても作動し続けることによって、通信ネットワークの損害を受けた部分を回避してデスティネーション・アドレスに情報を送るネットワークを必要としたことがＴＣＰ／ＩＰの開発の原動力となった。もちろん、ソース・アドレスのロケーションまたはデスティネーション・アドレスのロケーション自体が動作不能になった場合は、そのような伝達は不可能である。



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

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

プロトコルのＴＣＰ部分は情報のパケットがソースからデスティネーションに正確に受信されたかを確認し、またもし正確に受信されなかった場合は、間違ったパケットを再送信するために用いられる。ユーザー・データグラム・プロトコル（ＵＤＰ）等の、配信を保証しないその他の伝送制御プロトコルも一般的に利用されている。
［ワールド・ワイド・ウェブ］
インターネット、特にワールド・ワイド・ウェブ（ウェブ）が広く受け入れられ拡大し、膨大且つ多様な情報が集めらた。情報技術システムを有するユーザー同士（つまりコンピュータ利用者）のインタラクションを可能にする様々なユーザー・インターフェースが現在利用されている。ＷｏｒｌｄＷｉｄｅＷｅｂ．ａｐｐ（ウェブ）と呼ばれる情報ナビゲーション・インターフェースは、１９９０年後半に開発された。その後、ウェブ・ブラウザ等の情報ナビゲーション・インターフェースがほぼ全てのコンピュータ・オペレーティング・システム・プラットフォームにおいて広く利用可能になった。



一般的にウェブは、複数のユーザー・インターフェース（例えばウェブ・ブラウザ）、サーバー、配信された情報、プロトコル及び仕様の、相乗相互運用の発現でありその結果である。ウェブ・ブラウザは情報へのナビゲーションとアクセスを促進するために設計され、一方情報サーバーは情報の供給を促進するために設計されている。通常ウェブ・ブラウザと情報サーバーは通信ネットワークを介してお互いに交信するように配置してある。情報サーバーは、通常ウェブ・ブラウザを用いて情報にアクセスするユーザーに対し情報を提供する機能を果たす。従って、情報サーバーは主にウェブ上の情報へのナビゲーションやアクセスにウェブ・ブラウザを用いるユーザーに対し情報を提供する。ウェブ・ブラウザの例としては、マイクロソフト社のインターネット・エクスプローラや、ネットスケープ・ナビゲーターがある。加えて、ウェブＴＶのようなナビゲーション・ユーザー・インターフェース機器もウェブ・ナビゲーションを容易にするために実現されている。マイクロソフト社のインフォメーション・サーバーやアパッチが情報サーバーの例として挙げられる。
［ユニバーサル・リソース・ロケーター（ＵＲＬ）］
ウェブの拡大は膨大な量の情報をもたらし、かかる膨大な情報はユニバーサル・リソース・ロケーター（ＵＲＬ）を利用することによりアクセス可能である。ＵＲＬとは通常ウェブ・ページ中にハイパーリンクとして組み入れられるアドレス、あるいはウェブ・ブラウザにタイプ入力されるアドレスである。所与のリソース（最も一般的には遠隔コンピュータ上にあるファイル）のＵＲＬはそのリソースのみを指す。一般的に、当該場所へのレファレンスは、例えば「ｈｔｔｐ：／／ｗｗｗ．ａＷｅｂＳｉｔｅ．ｃｏｍ／ａＦｏｌｄｅｒ／ａＦｉｌｅ／ａＦｉｌｅ．ｈｔｍｌ」というように、ディレクトリ・パス及びファイル名と併せて未解決のＩＰアドレスを用いて達成される。この例では、このＵＲＬが「ａＷｅｂＳｉｔｅ．ｃｏｍ」というドメインの「ｗｗｗ」という名前のコンピュータに接続し、そのコンピュータの「ａＦｏｌｄｅｒ」というディレクトリに保存されている「ａＦｉｌｅ．ｈｔｍｌ」という名前のファイルをリクエストするように、ブラウザに命じることになる。
［ユニバーサル・ネーム識別子（ＵＮＩ）］
Ｔｈｅ Ｃｏｒｐｏｒａｔｉｏｎ ｆｏｒ Ｎａｔｉｏｎａｌ Ｒｅｓｅａｒｃｈ Ｉｎｉｔｉａｔｉｖｅは、情報の名前と所在を指定するハンドル・システムと呼ばれる新しい手段を創り出し実施した。ハンドル・システムは現在のＵＲＬの利用状況を改善するために設計された。


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


［デジタル権利管理（ＤＲＭ）］
デジタル権利管理（ＤＲＭ）は、所有者の資産に対する所有権の説明、階層化、分析、評価、取引及びモニタリングに関係する。ＤＲＭは、ワークの物理的マニフェステーション（例えばテキストブック等）に対する所有権、あるいはワークのデジタル・マニフェステーション（例えばウェブ・ページ等）に対する所有権の管理を網羅する。ＤＲＭはまた、資産価値の有形・無形に関わらず、資産の管理を網羅する。現在のＤＲＭシステムは、資産の使用についての条件を説明するための文言、コントロールされた環境またはエンコードされた資産マニフェステーションを施行することにより資産の使用を追跡すること、及びデジタル権利の全体的管理のためのクローズド・アーキテクチャを含む。現在のＤＲＭシステムは一般に、ＵＲＬのような場所に基づく識別子に依存するため、場所に基づく識別子の柔軟性の無さによる制限を受けている。

そのため、ＤＲＭシステムに保護されたデジタル化された著作物に確実にアクセスするための装置、方法及びシステムが必要とされている。ここに開示する当該の装置、方法及びシステムはＤＲＭシステムの耐久性を改善し、ＤＲＭの顧客とコンテンツ発行者の両方に更なる能力を提供し、電子商取引の成長を促進するものである。

デジタル権利管理（ＤＲＭ）とコンテンツ流通システムは、配給、アクセス管理及び使用の追跡とワークのレポートを可能にするために、固有の著作物をレファレンスする必要がある。ここに開示する装置、方法及びシステムは、当該システム内でのトランザクションの対象となり、著作物のインスタンス化に伴い移動する著作物の固有な識別子としてのデジタル・オブジェクト識別子（ＤＯＩ）を用いたＤＲＭ及びコンテンツ流通システムである。

コンピュータからデジタル・ワークにアクセスする一つの方法を開示する。当該方法は、デジタル・ワークに少なくとも一つの使用権を関連付け、保護されたデジタル・ワークを作る。使用権はデジタル・ワークの表示、デジタル・ワークの複製、デジタル・ワークの別のコンピュータへの転送またはデジタル・ワークの印刷を含む。当該方法はデジタル・ワークに対しＤＯＩのような固有の識別子を選択し、保護されたデジタル・ワークと固有の識別子をデジタル著作物のライブラリやピア・ツー・ピア・ネットワークの一部のようなディレクトリに保存する。当該方法はコンピュータからディレクトリにクエリーを発行し、固有の識別子を含む結果を一セット生成する。当該方法は固有の識別子を用い、保護されたデジタル・ワークをディレクトリから入手する。

別の実施例では、当該方法は保護されたデジタル・ワークを、従来技術の暗号化アルゴリズムを用いて暗号化するか、及び／または保護されたデジタル・ワークを安全なコンテナでラッピングする。安全なコンテナとは、従来技術のウォーターマーキング・アルゴリズムを用いたデジタル・ウォーターマークを含むこともできるし、デジタル・ワークに関連する固有の識別子を含むウォーターマーキング・アルゴリズムを用いることもできる。


別の実施例においては、当該方法は保護されたデジタル・ワークを説明するメタデータを保存し、メタデータをコンピュータからのクエリーに含む。更にまた、クエリーはユーザーに連結したコンピュータから生成されてもよいし、コンテンツ流通業者、コンテテンツ・シンジゲーターあるいはコンテンツ集積業者等の第三者からされてもよい。

添付した図面は、デジタル・オブジェクト識別子をデジタル権利管理システムに組み込むための装置、方法及びシステムの詳細を、その構造と動作の両方に関して最も良く図示したものである。これらの図面中の同じ参照番号及び記号は同じ要素を指すものである。

デジタル権利管理（ＤＲＭ）コントローラに組み込まれた一実施例を図示している。 移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを図示している。 移動する情報についての通信ネットワーク上でのＵＲＬアドレッシングを図示している。 ＤＯＩを介した情報へのアクセスを図示している。 ハンドルの概要を示している。 ハンドルの概要を示している。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示している。 ユーザーの所望する情報へのアクセスを可能にするための解決メカニズムの概要を示している。 ユーザーがＤＯＩを用いて情報をアクセスするために行う典型的な一連のアクションの概要を示している。 ユーザーが情報の内容をアクセスするために行う典型的な一連のアクションのより完全な概要を示している。 通信ネットワーク上で情報をアクセスするための典型的なメカニズムを図示している。 通信ネットワーク上で情報を入手するための典型的なメカニズムの別の実施例の概要を図示している。 典型的なＤＯＩ登録システムの概要を示している。 デジタル・オブジェクト識別子を用いてシステムの耐久性を高める従来のデジタル権利管理シナリオに関わる各者間のインタラクションを図示した機能ブロック図である。 ウォーターマークを図１４に示したデジタル権利管理シナリオに組み込むことを図示した機能ブロック図である。 図１６Ａは、図１５に示したウォーターマーキング・プロセスの一実施例のフロー図で、結果としてユーザーは保護されたデジタル・ワークを開く。図１６Ｂは、図１５に示したウォーターマーキング・プロセスの一実施例のフロー図で、結果としてユーザーはハッキングされたデジタル・ワークにアクセスする。図１６Ｃは、図１５に示したウォーターマーキング・プロセスの一実施例のフロー図で、結果としてユーザーは非公式に流通されたデジタル・ワークにアクセスする。 有効性確認アーキテクチャを図１４に示したデジタル権利管理シナリオに組み込むことを図示した機能ブロック図である。 インタラクティブ・インターフェース多重解決メニュー・ファシリティ（ＭＲＭＦ）の非限定的な例を図示した概略図である。 インタラクティブ・インターフェース多重解決メニュー・ファシリティ（ＭＲＭＦ）の非限定的な例を図示した概略図である。

［デジタル権利管理コントローラ］
図１は、デジタル権利管理システム（ＤＲＭＳ）コントローラ１０１に取り入れられた一実施例を図示している。この実施例では、ＤＲＭコントローラ１０１はハンドルと関連する全ての情報及び／またはその他の登録、解決、処理、保存、更新及び有効性確認の役割を担う。


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

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


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


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

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

入出力インターフェース（Ｉ／Ｏ）１０８は、ユーザー入力デバイス１１１、周辺機器１１２、暗号プロセッサ・デバイス１２８及び／またはその他を受け入れ通信し、及び／または接続する。Ｉ／Ｏは、例えばアップル・デスクトップ・バス（ＡＤＢ）、アップル・デスクトップ・コネクター（ＡＤＣ）、アナログ、デジタル、モノラル、ＲＣＡ、ステレオ、及び／またはその他に基づくオーディオ、ＩＥＥＥ１３９４、インフラレッド、ジョイスティック、キーボード、ミディ、オプティカル、ＰＣ ＡＴ、ＰＳ／２、

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

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

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

例えばマイクロコントローラ、プロセッサ１２６、インターフェース１２７、及び／またはデバイス１２８のような暗号ユニットをＤＲＭコントローラに付け、及び／または通信してもよいが、暗号ユニットはこれらに限定されるわけではない。通常モトローラ社製であるＭＣ６８ＨＣ１６マイクロコントローラは暗号ユニットとして使用してもよいし、及び／または暗号ユニット内にあってもよい。同等のマイクロコントローラ及び／またはプロセッサを使用してもよい。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚの設定において１６ビットの積算加算インストラクションを活用し、５１２ビットの


ＲＳＡ秘密鍵機能を実行するために１秒以下しか必要としない。暗号ユニットは交信エージェントからの通信の認証をサポートすると共に、匿名のトランザクションを可能にする。暗号ユニットはまた、ＣＰＵ１０３の一部として設定されていてもよい。他に市販されている専門の暗号プロセッサとしては、ＶＬＳＩテクノロジー社の３３ＭＨｚ６８６８や、セマフォ・コミュニケーション社の４０ＭＨｚのロードランナー２８４がある。
［メモリ］
記憶装置１１４は、従来のコンピュータ・システムの記憶装置のどれであってもい。記憶装置は、固定ハード・ディスク・ドライブ及び／またはその他同類の装置でよい。しかしながら、ＤＲＭコントローラ及び／またはコンピュータの系統的システムは、様々な形態のメモリ１２９を用い得ることは理解されるものである。例えば、コンピュータの系統的システムは、チップ内のＣＰＵメモリ（例えば、レジスタ）、ＲＡＭ、ＲＯＭ、他の記憶装置の機能がパンチ・テープまたは、パンチ・カード・メカニズムによって与えられるように構成されてもよい。もちろん、そのような実施例は好まれるものではなく、動作が極端に遅くなる結果となる。一般的な構成では、メモリ１２９は、ＲＯＭ、ＲＡＭ、記憶装置１１４を含む。通常、プロセッサが情報の記憶及び／または情報の取り出しを実行することを可能にする機械化及び／または実施化は、メモリ１２９と見なされる。それゆえ、コンピュータの系統的システムは一般にメモリを必要とし、メモリを使用する。メモリは、代替可能な技術及びリソースであり、それゆえメモリは任意の数の実施例を代替として利用したり、一緒に利用したりできる。
［モジュール・コレクション］
記憶装置１１４は、プログラム・モジュール及び／またはデータベース・モジュール及び／またはデータといったもののコレクションを含む。それらの例には、オペレーティング・システム・モジュール１１５（即ちオペレーティング・システム）、情報サーバー・モジュール１１６（即ち情報サーバー）、ユーザー・インターフェース・モジュール１１７（即ちユーザー・インターフェース）、


ウェブ・ブラウザ・モジュール１１８（即ちウェブ・ブラウザ）、ＤＲＭデータベース１１９、暗号サーバー・モジュール１２０（即ち暗号サーバー）、情報アクセス多重解決サーバー（ＩＡＭＲＳ）モジュール１２５、及び／またはその他（つまり、全体としてモジュール・コレクション）といったものがあるが、それらに限定されるわけではない。これらモジュールは記憶され、記憶装置及び／またはインターフェース・バスを通じてアクセス可能な記憶装置からアクセスできる。モジュール・コレクションにあるような非従来的なソフトウェア・モジュールは一般的に、かつ望ましくはローカル記憶装置１１４に記憶されるが、周辺機器、ＲＡＭ、通信ネットワークを通じた遠隔記憶ファシリティ、ＲＯＭ、様々な形態のメモリ及び／またはその他に取り込み及び／または記憶してもよい。
［オペレーティング・システム］
オペレーティング・システム・モジュール１１５は、ＤＲＭコントローラの動作を可能にする実行可能なプログラム・コードである。一般的に、オペレーティング・システムは、Ｉ／Ｏ、ネットワーク・インターフェース、周辺機器、記憶装置、及び／またはその他のアクセスを可能にする。オペレーティング・システムは、アップル・マッキントッシュＯＳ Ｘ サーバー、ＡＴ＆Ｔ プラン９、マイクロソフト・ウィンドウズＮＴサーバー、ユニックス及び／またはその他のオペレーティング・システムのような従来型の製品が好ましい。好ましくは、オペレーティング・システムは、非常にフォールト・トレラントであり、拡張可能かつ安全であるのがよい。オペレーティング・システムは、モジュール・コレクション内のそのモジュール自体及び／またはその他のファシリティを含む他のモジュールと通信したり、及び／または交信したりする。従来オペレーティング・システムは、他のプログラム・モジュールやユーザー・インターフェース及び／またはその他と通信する。例えば、オペレーティング・システムは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト及び／またはレスポンスを含み、通信、生成、入手及び／または提供する。オペレーティング・システムは一度ＣＰＵ１０３によって実行されると、通信ネットワーク、データ、Ｉ／Ｏ、周辺機器、プログラム・モジュール、メモリ、ユーザー入力デバイス及び／またはその他とのインタラクションを可能にする。好ましくは


オペレーティング・システムは、通信ネットワーク１１３を通じて、ＤＲＭコントローラが他のエンティティと通信できるようにする通信プロトコルを提供する。ハンドル・システムとインタラクションするためのサブキャリア・トランスポート機構として様々な通信プロトコルが、ＤＲＭコントローラによって使用される。通信プロトコルとしては例えばマルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト及び／またはその他といったものがあるが、これらに限定されるわけではない。
［情報サーバー］
情報サーバー・モジュール１１６は、記憶されたプログラム・コードであり、ＣＰＵ１０３により実行される。情報サーバーは、マイクロソフト社のインターネット・インフォメーション・サーバー及び／またはアパッチ・ソフトウェア・ファンデーションのアパッチ等、従来のインターネット情報サーバーでよいが、それらに限定されるわけではない。好ましくは、情報サーバーはＣ＋＋、ジャバ、ジャバスプリクト、アクティブ・エックス、共通ゲートウエイ・インターフェース（ＣＧＩ）スクリプト、アクティブ・サーバー・ページ（ＡＳＰ）及び／またはその他のようなファシリティを通じて、プログラム・モジュールの実行を可能にする。好ましくは、情報サーバーは、安全な通信プロトコルをサポートする。その通信プロトコルは、例えばファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュア・ソケット・レイヤー（ＳＳＬ）及び／またはその他であるが、通信プロトコルはこれらに限定されるわけではない。従来は、情報サーバーは、結果をウェブ・ページの形でウェブ・ブラウザへ提供し、他のプログラムのモジュールとのインタラクションを通じて手を入れられたウェブ・ページの生成を可能にする。ＨＴＴＰリクエストのＤＮＳ解決部分がある特定の情報サーバーへと解決された後、当該情報サーバーは、ＤＲＭコントローラ上の特定された場所情報に対するリクエストを当該ＨＴＴＰリクエストのリマインダーに基づいて解決する。例えば、ｈｔｔｐ：／／１２３／１２４／１２５／１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌのようなリクエストは、当該リクエストのＩＰ部分である「１２３／１２４／１２５／１２６」を有しており、それがＤＮＳサーバーによりＩＰアドレスにある一つの情報サーバーへと解決され、するとその情報サーバーが「ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」


の部分に対する当該ｈｔｔｐリクエストを更に解析し、それを「ｍｙＩｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」の情報を含むメモリの場所へと解決するかもしれない。情報サーバーは、そのモジュール自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールへと通信したり、及び／またはそれらと交信したりする。情報サーバーが、オペレーティング・システム、他のプログラム・モジュール、ユーザー・インターフェース、ウェブ・ブラウザ及び／またはその他と通信する頻度は非常に高い。情報サーバーは、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
［ユーザー・インターフェース］
ユーザー・インターフェース・モジュール１１７は記憶されたプログラム・コードであり、ＣＰＵ１０３により実行される。好ましくはユーザー・インターフェースは、オペレーティング・システム及び／またはオペレーティング環境によって、あるいはそれらと一緒に、及び／またはそれらの上に与えられる従来型の画像ユーザー・インターフェースであり、システム及び／またはオペレーティング環境とは、例えばアップル・マッキントッシュＯＳ、アクア、マイクロソフト・ウィンドウズ（ＮＴ）、（ＫＤＥ、Ｇｎｏｍｅ及び／またはその他の）ユニックスＸウインドウズ、及び／またはその他である。ユーザー・インターフェースはテキスト・ファシリティ及び／または画像ファシリティを通じて、プログラム・モジュール及び／またはシステム機能を表示、実施、インタラクション、操作及び／またはオペレーションすることを可能にしてもよい。ユーザー・インターフェースは機能を提供するが、その機能とは、ユーザーが、コンピュータのシステムを実行し、インタラクションし及び／または働くものである。ユーザー・インターフェースは、それ自体及び／またはその他の機器を含むモジュール・コレクション内の他のモジュールへと通信及び／またはそれらと交信する。ユーザー・インターフェースがオペレーティング・システムや他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。ユーザー・インターフェースは、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりする。
［ウェブ・ブラウザ］
ウェブ・ブラウザ・モジュール１１８は記憶されたプログラム・コードであり、ＣＰＵ１０３により


実行される。ウェブ・ブラウザは従来のハイパーテキスト・ビューイング・アプリケーションであることが好ましく、例えば、（好ましくは、ＨＴＴＰＳ、ＳＳＬ及び／またはその他のような１２８ビットの暗号化を有する）マイクロソフト・インターネット・エクスプローラーやネットスケープ・ナビゲーターである。ジャバ、ジャバスプリクト、アクティブ・エックス及び／またはその他のようなファシリティを通じて、プログラム・モジュールを実施することが可能なウェブ・ブラウザもある。一実施例では、ウェブ・ブラウザはｗｗｗ．ｃｎｒｉ．ｏｒｇ．から入手可能なハンドル・システム・プラグインのようなブラウザ・プラグイン・ソフトウェアを経てハンドル対応となる。一つの代替実施例においては、ウェブ・ブラウザにハンドル・サポートが組み込まれている。ウェブ・ブラウザやそのような情報アクセス・ツールは、ＰＤＡ、携帯電話及び／または他のモバイル・デバイスに組み込まれていてもよい。ウェブ・ブラウザは、それ自体及びその他のようなファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／またはと交信する。ウェブ・ブラウザが、情報サービス、オペレーティング・システム、インテグレートされたプログラム・モジュール（例えばプラグ・イン）、及び／またはその他と通信する頻度は非常に高い。例えば、プログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含んだり、通信、生成及び／または入手したりするものである。もちろん、ウェブ・ブラウザや情報サーバーの代わりに、両者と同様の機能を持つような複合的なアプリケーションを開発してもよい。複合的なアプリケーションは、ＤＲＭ対応のノードからユーザー、ユーザー・エージェント及び／またはその他への情報の入手および提供を同様に実行する。複合的なアプリケーションは、標準的なウェブ・ブラウザを用いるシステムに対しては役に立たないこともある。安全性を強化するために、そのような複合的なモジュールは、安全性をさらに強化するような中間の情報サーバーが存在しなくても、ＤＲＭと直接通信するように構成することができる。

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

［ＤＲＭデータベース］
ＤＲＭデータベース・モジュール１１９は、ＣＰＵ１０３により実行される記憶されたプログラム・コードでデータベース内において具現し得て、記憶されたデータであり、記憶された部分のプログラム・コードが記憶されたデータを処理するためのＣＰＵ１０３を設定する。好ましくは、データベースは、例えばオラクルまたはサイベースといった、従来型、フォールト・トレラント、相関的、拡張可能で安全なデータベースであるのがよい。リレーショナル・データベースとは、フラット・ファイルの拡張である。リレーショナル・データベースは、一連の関連し合うテーブルから成る。鍵フィールドを通じてテーブル同士が相互接続する。鍵フィールドの使用によって、鍵フィールドに対するインデキシングによるテーブルの結合が可能になる。つまり、鍵フィールドが様々なテーブルから情報を組み合わせるための、次元的回転軸のような作用をするのである。一般に主要鍵を合わせることによって、相互関係におけるテーブル間に維持されるリンクを識別する。主要鍵は、リレーショナル・データベース内において、テーブルの行を固有に識別するフィールドを表す。より厳密には、主要鍵は、一対多数の関係における「一つの」面にあるテーブルの行を固有に識別するのである。

代わりに、配列、ハッシュ、（リンクした）リスト、ストラクト及び／またはその他の様々な標準的なデータ構造を用いて、ＤＲＭデータベースを実施してもよい。そのようなデータ構造は、メモリ及び／または（構造的な）ファイルに保存してもよい。仮にＤＲＭデータベースをデータ構造として実施すると、ＤＲＭデータベースの使用は例えばＤＲＭモジュールのような他のモジュールに組み込まれ得る。データベースは、標準的なデータ処理技術を介した無数のバリエーションによって、統合及び／または分散される。データベースの一部分、例えばテーブルは、エクスポート及び／またはインポートでき、それによって、分散したり及び／または統合したりする。非限定的な一実施例では、ＤＲＭデータベース１１９は、例えばＵＮＩ（例えばハンドル、ＤＯＩ及び／または他のＵＮＩ）、テーブル１１９ａ、ＵＲＬテーブル１１９ｂ、メタデータ・テーブル１１９ｃ、多重解決テーブル１１９ｄ、ポリシー・テーブル１１９ｅ及び／またはその他といったテーブルを含むが、これらに限定されるわけではない。全てのテーブルは、（強化）ＤＯＩ鍵フィールド・エントリーが固有なので、このエントリーについて関係し得る。別の実施例では、これらのテーブルは、自身のデータベースとそれぞれのデータベース・コントローラ（つまり、上記テーブルそれぞれの個別のデータベース・コントローラ）に分散化されている。もちろん、標準的なデータ処理技術を用いて、データベースを幾つかのコンピュータのシステム的系統及び／または保存装置にわたってさらにデータベースを分散してもよい。同様に、分散したデータベース・コントローラの構成は、様々なデータベース・モジュール１１９ａ―ｅを統合及び／または分散することによって、変えることができる。ＤＲＭデータベース１１９は、データベース・コントローラを通じたユーザーのリクエスト及び様々なトランザクションを追跡するように構成してもよい。

ＤＲＭデータベース１１９は、それ自体及び／またはその他のファシリティを含むモジュール・コレクション内の他のモジュールと通信したり、及び／または交信したりする。ＤＲＭデータベース１１９がＤＲＭモジュール、他のプログラム・モジュール及び／またはその他と通信する頻度は非常に高い。データベースは、他のノード及びデータに関する情報を入手し、保持し、提供する。

［暗号サーバー］
暗号サーバー・モジュール１２０とは、保存されたプログラム・コードであり、ＣＰＵ１０３、暗号プロセッサ１２６、暗号プロセッサ・インターフェース１２７、暗号プロセッサ装置１２８、及び／またはその他のものにより実行される。暗号プロセッサ・インターフェースが暗号モジュールにより暗号化及び／または暗号解読のリクエストを迅速に実施することを可能にすることが望ましい。代わりに暗号サーバー・モジュール１２０を従来のＣＰＵに実行させても良い。暗号サーバー・モジュール１２０が、供給されたデータの暗号化及び／または暗号解読を可能にすることが望ましい。暗号サーバー・モジュール１２０が対称及び非対称（例えばＰｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＲ））双方の暗号化及び／または暗号解読を可能にすることが望ましい。暗号サーバー・モジュール１２０は従来の暗号技術、例えば、デジタル証明（例えば、Ｘ．５０９認証枠組み）、デジタル署名、複式署名、エンベロッピング、パスワード・アクセス保護、公開鍵管理、及び／またはその他のものを可能にすることが望ましいが、従来の暗号技術はそれらに限定されるわけではない。暗号サーバー・モジュール１２０は数々の（暗号化及び／または暗号解読）セキュリティ・プロトコル、例えば、チェックサム、データ暗号化基準（ＤＥＳ）、楕円曲線暗号化（ＥＣＣ）、国際データ暗号化アルゴリズム（ＩＤＥＡ）、メッセージ・ダイジェスト５（ＭＤ５、即ち一方向ハッシュ関数）、パスワード、ＲＣ５（リベスト暗号）、リジンデール、ＲＳＡ（インターネット暗号化及び認証システムで、１９７７年にロン・リベスト、アデイ・シャミル及びレオナルド・エイドウルマンが開発したもの）、セキュア・ハッシュ・アルゴリズム（ＳＨＡ）、セキュア・ソケット・レイヤー（ＳＳＬ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、及び／またはその他のものを可能にすることが望ましいが、セキュリティ・プロトコルはそれらに限定されるわけではない。暗号モジュールは「セキュリティ許可」のプロセスを可能にし、それによってリソースへのアクセスはセキュリティ・プロトコルにより阻害され、暗号モジュールは安全性を保たれたリソースへの許可されたアクセスを実行する。暗号モジュールは


モジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中には暗号モジュール自体及び／その他のファシリティも含まれる。暗号サーバー・モジュール１２０は、通信ネットワーク上での情報の安全な送信を可能にする暗号化方式を支援することが好ましく、もしユーザーが希望すれば、ＤＲＭモジュールが安全なトランザクションに用いられ得るようにする。暗号モジュールは、ＤＲＭ上のソースの安全なアクセスを可能にするが、つまり安全化されたソースのクライアント及び／またはサーバーとして機能する。暗号サーバー・モジュール１２０が情報サーバー、オペレーティング・システム、その他のプログラム・モジュール及び／またはその他のものと交信する頻度は非常に高い。暗号サーバー・モジュール１２０はプログラム・モジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンスを含み、通信、生成、入手及び／または提供する。

［情報アクセス多重解決サーバー（ＩＡＭＲＳ）］
ＩＡＭＲＳモジュール１２５は保存されたプログラム・コードであり、ＣＰＵ１０３により実行される。一般にＤＲＭは、通信ネットワーク上のノード間における情報のアクセス、入手、提供、及び／またはその他を実行する。ＩＡＭＲＳはＵＮＩを、入ってくるリクエストのタイプに応じて多重のインスタンス化及びサービスへと解決する能力を有している。一般に、ＩＡＭＲＳはルックアップ機能として役を果たし、与えられた情報、そのＤＯＩ、その現在の場所及び関連するサービスへのポインターとの間の関連性の作成、維持、登録、及び更新を行う。ＩＡＭＲＳはＤＲＭデータベースと提携して、リクエストされた情報のデータ転送の向上、リクエストされた情報の種々のフォーマットへの解決、情報についてのクエリー作成用の強化されたメカニズムの提供及び／またはその他に役立つと思われるノードを識別する。ＩＡＭＲＳによるノード間の情報アクセス可能化の開発にあたっては、標準開発ツールを使用してもよい。例えば、Ｃ＋＋、シェル・スクリプト、ジャバ、ジャバ・スクリプト、ＳＱＬコマンド、ウエブ・アプリケーション・サーバー・エクステンション、アパッチ・モジュール、パール・スクプリト、バイナリ・エクセキュータブル、及び／またはその他のマッピング・ツール及び／またはその他を用いることができるが、標準開発ツールはそれらに限定されるわけではない。一つの非限定的な実施例においては、ＩＡＭＲＳサーバーは暗号化サーバーを用いて通信の暗号化及び暗号解読にあたっている。ＩＡＭＲＳはリクエストのサービス、ＵＮＩのための関連性情報の更新、その他多くのことにあたることができる。ＤＲＭモジュールはモジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中にはＤＲＭモジュール自体及び／またはその他のファシリティも含まれる。ＩＡＭＲＳモジュールがＤＲＭデーターベース、オペレーティングシステム、その他のプログラム・モジュール及び／またはその他と交信する頻度は非常に高い。ＩＡＭＲＳはプログラムモジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンス等を含み、通信、生成、入手及び／または提供する。


［デジタル権利管理サーバー（ＤＲＭＳ）］
ＤＲＭモジュール１３５は保存されたプログラム・コードであり、ＣＰＵ１０３により実行される。ＤＲＭモジュール１３５は、情報アクセス登録システム（ＩＡＲＳ）のようなＵＮＩ登録システムからは分離して独立モードで動作可能である。ＤＲＭモジュール１３５は、情報の有効性を確認できるようにＤＯＩによって表される情報に組み込まれたタグを生成することができる。ＤＲＭモジュール１３５は、ＤＲＭデータベースと提携して、ＵＮＩと関連する情報の完全性の有効性の確認、リクエストされた情報のデータ転送の向上、リクエストされた情報の種々のフォーマットへの解決、情報についてのクエリー作成用の強化されたメカニズムの提供及び／またはその他に役立つと思われるノードを識別する。ＤＲＭによるノード間の情報アクセス可能化の開発にあたっては、標準開発ツールを使用してもよい。例えば、Ｃ＋＋、シェル・スクリプト、ジャバ、ジャバ・スクリプト、ＳＱＬコマンド、ウエブ・アプリケーション・サーバー・エクステンション、アパッチ・モジュール、パール・スクプリト、バイナリ・エクセキュータブル、及び／またはその他のマッピング・ツール及び／またはその他を用いることができるが、標準開発ツールはそれらに限定されるわけではない。一つの非限定的な実施例においては、ＤＲＭモジュール１３５は暗号サーバーを用いて通信の暗号化及び暗号解読にあたっている。ＤＲＭモジュール１３５は、リクエストのサービス、リクエストのリダイレクト、ＵＮＩのための関連性情報の更新、その他多くのことにあたることができる。ＤＲＭモジュール１３５は、モジュール・コレクション中の他のモジュールと通信及び／または交信してもよく、その中にはＤＲＭモジュール１３５自体及び／またはその他のファシリティも含まれる。ＤＲＭモジュール１３５がＤＲＭデーターベース、ＩＡＭＲＳモジュール、ＩＡＲＳモジュール、オペレイティングシステム、その他のプログラム・モジュール及び／またはその他と交信する頻度は非常に高い。ＤＲＭモジュール１３５はプログラムモジュール、システム、ユーザー及び／またはデータとの通信、リクエスト、及び／またはレスポンス等を含み、通信、生成、入手及び／または提供する。


［分散型ＤＲＭＳ］
ＤＲＭノード・コントローラの構成要素は何れもあらゆる方法で、その機能性を組み合わせ、統合及び／または分散することが可能であり、開発及び／または配備を可能にすることができる。同様に、モジュール・コレクションも開発及び／または配備を可能にすべくあらゆる方法で組み合わせることができる。これを達成するには、単に各構成要素を共通のコード・ベースに統合するか、あるいは必要に応じて統合的に構成要素をダイナミックにロードできるファシリティに統合すれば良いのである。

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

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

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

もしモジュールコレクションの構成要素がお互いに個別的、分離的、及び／または外部的である場合は、データの通信、入手、及び／または提供を他のモジュール構成要素と行う及び／または他のモジュール構成要素へと行うにあたっては、標準的なデータ処理技術を用いればよい。標準的なデータ処理技術には例えば、アプリケーション・プログラム・インターフェース（ＡＰＩ）情報パッセージ；（分散型）コンポーネント・オブジェクト・モデル（（Ｄ）ＣＯＭ）、（分散型）オブジェクト・リンキング・アンド・エンベディング（（Ｄ）ＯＬＥ）、及び／またはその他のもの）、コモン・オブジェクト・リクエスト・ブローカー・アーキテクチャー（ＣＯＲＢＡ）、プロセス・パイプ、共有ファイル及び／またはその他のもの（アプリケーション間の通信）があるが、これらに限定されるわけではない。グラマーの生成及び解析は、アプリケーション間の通信のための個別のモジュールの構成要素間で送ったメッセージや、アプリケーション内部の通信のための単一モジュールにおけるメモリ空間内で送ったメッセージを促進する。グラマーは、例えばｌｅｘ、ｙａｃｃ及び／またはその他といった標準的な開発ツールを使用して開発してもよい。それらの標準的な開発ツールは、グラマーの生成及び機能性の解析を可能にし、これらは今度はモジュール内及びモジュール間の通信メッセージの基礎を形成する。この場合もまた、好ましい実施例はシステム配備のコンテキスト次第である。

最後に、モジュール・コレクションの如何なる組み合わせ及び／または図と全体に渡って説明される本発明の如何なる組み合わせにおける論理上な構造及び／またはトポロジー構造は、固定された実施順位及び／またはアレンジメントに限定されるわけではなく、むしろ、開示した順位は典型的なものであり、順位にかかわらず全て機能的に等価であるものを本開示は意図していることを理解すべきである。更に、そのような構造は連続実行に限定されるものではなく、むしろ、非同期的に、同時的に、同期的に及び／またはその他に実行できる如何なる数のスレッド、プロセス、サービス、サーバー及び／またはその他を本開示は意図していることにも注意すべきである。

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

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

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

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

図２はウェブ・ページ２０１、ユーザーが入力したアドレス２０２、ドキュメント２０３及びメモリ・デバイス２０４を描写し、それぞれ一つの情報（「１９９９年度売り上げ」のレポート２２２）をレファレンスするためにＵＲＬを、従ってＩＰアドレッシングを用いる。次に図２では、情報２２２は元の場所２０８（例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）から図３の新しい場所３１０（例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）へ移動する。図３において、この結果として当該の場所をレファレンスする全てのＵＲＬ２４４のブレーキング３０１−３０４が起こり、あの恐ろしい「４０４Ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」のエラー３０９を、当該の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）２０８へレファレンスする全てのユーザーとＵＲＬに提示することになる。

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

ユーザーはデジタル・オブジェクト・アイデンティファイアー（ＤＯＩ）を介して情報にアクセスし得る。ＤＯＩは情報そのものに関連付けられている（即ち情報自体の名前である）。ＤＯＩは「ハンドル」のインスタンスであり、「ハンドル・システム」の枠組みの中で動作する。ＤＯＩは永続的に関連付けられた情報へのアクセスを可能にする。ＤＯＩは、一連の文字の後にセパレーターが付き、その更に後に一連の文字が付いたもので、例えば１０．１０６５／ａｂｃ１２３ｄｅｆというようになる。注意すべき、そして再び強調すべきことは、本開示は「ＵＲＮ」「ＤＯＩ」「ハンドル」といったＵＮＩの特定のサブ・タイプについて記載することもあるが、本開示はより一般的なタイプのＵＮＩにも同等に適用されるものであり、従って特に断りの無い限り本開示はＵＮＩのあるサブ・タイプに言及する場合はＵＮＩ全般にわたって適用されるものと見做されるべきものである。更に、今日使用されているハンドル・システム、ＤＯＩ及びそれらの支援技術や仕様は、本開示の意図したフォーラムではあるものの、本開示は最新の、または今後考案される仕様やシステムに基づいた他のフォーラムにも応用できることを意図していることに注意すべきである。

［ＤＯＩ］
情報にアクセスするためにＤＯＩを使用しているユーザーは、ＤＯＩが関連付けられた情報のみを解決しアクセスすることを知っている。場所をレファレンスするＵＲＬとは対照的に、ＤＯＩとは情報に対する名前であり、その情報の場所やその他の属性、と共に関係するサービスをも見るために用いることができる。情報とは、電子書籍、音楽ファイル、ビデオ・ファイル、電子ジャーナル、ソフトウェア及び前記のコンテンツの一部及び／またはそれらの組み合わせも含む情報と共にコンピュータで読み取り可能なファイル全てを含むと考えられる。電子コンテンツは通信ネットワーク上で利用可能となっているので、これ以降本出願書はそのような利用可能な情報は、通信ネットワーク上で発行されたものとみなすということに注意されたい。

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

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

上記のように、ＤＯＩは情報のみならず、その一部を識別するために用いることもできる。例えば、ＤＯＩシステムによれば、１冊の書籍が一つのＤＯＩを有することが可能な一方、その書籍のそれぞれの章が別の、それぞれの章を識別するための固有のＤＯＩを有することもあり、更にはその書籍中の図面一つ一つがそれら図面を識別するための固有のＤＯＩを有することも可能である。言い換えれば、ＤＯＩシステムによると、コンテンツ発行者の希望通りに様々な細かさのデータの塊として情報を識別することができる。なお、ユニバーサル・プロダクト・コード（一般的には消費者向け製品の「バーコード」として表示されている）によって例えば、スーパーのレジ、在庫コンピュータ、財務システム及び流通業者が現実の世界でサプライ・チェーンを自動化することが可能になるように、本開示はＤＯＩを用いて世界中の全ての電子発行エージェントがインターネットを介したデジタル・コンテンツ（及びそのコンテンツに対する権利のライセンス）の販売を効率的な方法で自動化することを可能にするメカニズムを提供すると想定している。何故ならば、販売可能なコンテンツのそれぞれが世界で唯一のＤＯＩを有しており、それをエージェント同士のトランザクションにおいて製品の識別コードとして使用することが可能だからである。


［ハンドル構造］
ハンドル・システムは、効率的でユーザーに分かり易い利用を可能にするための前もって決められた方針の一群を採っており、そのうち幾つかを以下に挙げる。発行者がオペレーション・コストを負担して、ＤＯＩ解決のためのハンドル・システムの使用がユーザーには無料となるのが理想的である。ＤＯＩは全て世界的なＤＯＩ機関に登録される。登録者は、登録したＤＯＩに関する状態データ及びメタデータを維持する責任がある。ＤＯＩのシンタックスは標準化されたシンタックスに準じる。使用にあたっては、ＤＯＩはオペーク・ストリング（ダム・ナンバー）になる。ＤＯＩ登録機関はＤＯＩの指定、登録、ＤＯＩに関連するメタデータの申告を管理する。

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

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

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

図６は、ＤＯＩ６００の別の実施例を示しており、図中ではテキストブックのＩＳＢＮ番号がサフィックス６０２として機能している。従って便宜上、元と成るコンテンツの発行者は、サフィックス６０２として元のコンテンツに合致する他のどのような識別コードを選択してもよい。
［強化ＤＯＩ］
図５は更に、強化ＤＯＩ５１０グラマーを図示している。ＤＯＩグラマーを強化する非限定的な実施例は、強化されたプレフィックス５１１として具現される。しかしながら、別の及び／または相補的な強化されたサフィックス（図示はしていない）を同様にＤＯＩ５００に付けてもよいと、全面的に意図されている。強化されたサフィックス５１１は、強化グラマー・ターゲット５１７と強化セパレーター５１４から成る。強化セパレーター５１４は＠という記号であるが、当然のことながら、他の文字を強化セパレーターとして指定しても良い。強化グラマー・ターゲット５１７自体は、強化セパレーター５１４以外の任意の文字列である。強化グラマー・ターゲット５１７は、ＤＯＩ５００が特定の情報を多重の種類で解決する目的で用いられ、本開示の中で詳しく述べる。さらに強化された実施例では、強化グラマー・ターゲット５１７自体が更に、強化グラマー動詞５１２と、例えばピリオドのような強化ターゲット・セパレータ５１６によって分離される強化グラマー・ターゲット・オブジェクト５１３から成り得る。もちろん、強化ターゲット・セパレーター５１６は、任意の文字で指定できる。一実施例では、強化グラマー動詞５１２は修飾語として働き、一つのＤＯＩのための複数の多重解決ターゲットの中から選択し、強化グラマー・ターゲット・オブジェクト５１３は、更なるアクションのために、ターゲット・オブジェクト及び／またはハンドル・システム解決サーバーへと手渡される一つの値である。

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

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

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

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

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

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

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

図１１は、本発明に基づいて、ＤＯＩを解決して所望のコンテンツが位置するＵＲＬを得ることにより、通信ネットワーク上で情報にアクセスするための幾つかの典型的なメカニズムの概要を示している。一実施例によると、ユーザーは直接ＤＯＩを提示し、ＤＯＩシステムは正しいコンテンツを入手し単に正しいＵＲＬにリンクすることによりそれをユーザーに送信する。別の実施例によると、ユーザーはメタデータに含まれるフィールドの幾つかに関係する情報を提示し、するとＤＯＩルックアップ・サービスは正しいＤＯＩを識別し、それが今度は所望するコンテンツの場所を解決する。図１１に示すように、一実施例によれば、サーチ・エンジン１１０１０をユーザーに提供してもよい。一実施例では、登録機関のＤＯＩとメタデータ・データベースとの通信において、サーチ・エンジンをオファーし配備する。別の実施例では、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍのようなサーチ・エンジンを用いて登録機関のデータベースにクエリーを出す。ユーザーは、サーチ・エンジン１１０１０に何らかの識別情報を提示することにより正しいＤＯＩを検索する。サーチ・エンジン１１０１０は提示された識別情報を用いてメタデータに関する自分のデータベースを検索し、提示されたメタデータの情報に関連するＤＯＩを入手する。したがって、サーチを行うユーザーには、メタデータ・データベースから返送したＤＯＩ及び／または前記返送したＯＤＩから解決したＵＲＬを提示し得る。入手したＤＯＩはＤＯＩディレクトリ１１０１１に送られ、ＤＯＩディレクトリ１１０１１は所望のコンテンツを発行者１１０４０が置いている場所のＵＲＬを解決する。最終的に、ユーザーのブラウザは正しいコンテンツ１１０６０へと導かれる。

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

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

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

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

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

図１３は、本発明に基づいた典型的なＤＯＩシステムの概要であり、発行者、ＤＯＩ登録サービス及びハンドル・システムが連携して創り出す効率的なＤＯＩシステムの概要を示している。プレフィックス・ホルダー１３５５は、ＤＯＩ１３４２と関連するメタデータ１３６６から成るＤＯＩ登録サービス１３００に情報を提出する。既に固有のプレフィックス５０１を与えられているプレフィックス・ホルダーは、コンテンツ１３６６にサフィックス５０２を指定するように要求する。登録サービス１３００は、情報１３４２、ハンドル・システム１３５０内に次に預けるための情報１３６６、及び／またはメタデータ・データベース１３１０といったユーザーから提出された情報を解析及び／または再形式設定する役目を担う。上記のように、ＤＯＩを用いてアドレスできるコンテンツの範囲は無限である。その結果、コンテンツ１３６６は如何なる情報及び記事、書籍、音楽アルバムを含む著作物、またはそれらの選択された個別の部分から成ってもよい。ＤＯＩ５００を提供することに加え、発行者１３４２は、コンテンツ１３６６用のメタデータを収集する。当該メタデータは当該コンテンツのＤＯＩ５００、ＤＯＩジャンル、識別子、タイトル、タイプ、起源、主要エージェント、エージェントの役割及び／またはその他から成る。また、様々な相手から提供され識別された、コンテンツに関係のある関連サービスのリストから成っていてもよい。様々な相手とは例えば、コンテンツをオンラインで購入できるウェブ・ページの場所である。

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

ＤＯＩ登録サービス１３００は、収集されたメタデータを別のデータ・サービス１３２０に提供したり、付加価値を付けたリソース１３３０をユーザーに提供したりするために利用することもできる。加えて、ＤＯＩ登録サービス１３００は正しいＤＯＩハンドル・データをハンドル・システム１３５０に送り、ハンドル・システムは複数のＤＯＩディレクトリ・サーバー１３４１から成っていてもよい。


［デジタル権利管理］
図１４は従来のデジタル権利管理（ＤＲＭ）シナリオに関わる各者間のインタラクションを図示した機能ブロック図である。従来の

ＤＲＭシナリオは、発行者１４１０が保護を必要とするデジタル・ワークを作り出すか、手に入れるかすることから始まる。ワーク１４１１はデジタル資産の一例である。発行者１４１０はワーク１４１１をＤＲＭパッケージング・ソフトウェア１４１２に送り、ワーク１４１１と関連付ける権利を特定する。これらの権利は顧客１４５０が行うことができるアクションを規制するもので、顧客がワークを読むこと、ワークを複製すること、ワークを別の顧客に転送すること及びワークを印刷することを含むが、これらに限定されるものではない。これらの権利はまた、時間ベースのものである（例えば、前述のアクションは全て、例えば二週間またはある特定の日から別の日までというような、特定された期間に許可する）。これらの権利はまた特定された回数のイベントに対して許可してもよい（例えば、顧客に二十回だけコンテンツを読むためのアクセスを許可したり、顧客に前もって特定された数の印刷を許可したり、顧客にある人数の受信者にのみコンテンツの転送を許可したり、あるいは顧客に何人の受信者にでも転送することを許可するものの、最初の二十人のリクエスト者にのみアクセスを認めるカウンターを有するセントラル・サーバーからアクセス権利を確保することを全ての受信者に対し要求することにより、最初の二十人の受信者のみにアクセスを許可したりする）。これらの権利はまた様々なセールス・プロモーション、製品またはサービス・バンドリング、あるいはディスカウント及びその他に関連させてもよい。発行者１４１０が指定できるこれらの権利には、数限りないバリエーション、組み合わせ及び順列がある。発行者１４１０はこれらの権利を一つずつ独立に特定してもよい。権利が特定された後、ＤＲＭパッケージング・ソフトウェア１４１２は保護されたワーク１４１３を安全なラッピング及び暗号化１４１４へと転送して、ワークの内容１４１３を暗号化し、ワークを安全なコンテナに入れることができる。ラッピングされた安全なワークは、安全なワーク１４１５として発行者へと戻される。理解されるべきことは、発行者１４１０、ＤＲＭパッケージング・ソフトウェア１４１２、安全なラッピング及び暗号化１４１４は、上記の機能を単一のコンピュータまたは分散型コンピュータ・ネットワークにおいて実行できるということである。更にまた、


ＤＲＭパッケージング・ソフトウェア１４１２と安全なラッピング及び暗号化１４１４によって実行される機能は、発行者１４１０に代わって発行者１４１０以外のエンティティにより実行されることもできるということも理解されるべきである。更にまた理解されるべきことは、上記の機能は異なるソフトウェア・モジュールによって、あるいはこれらの様々な機能を組み合わせて一緒にしたりその他の関係する機能や関係の無い機能と組み合わせたりしたソフトウェア・モジュールによって実行されてもよいということである。

発行者１４１０は安全なワーク１４１５をコンテンツ・ホスティング１４２０データベースに保存する。それに加えて、安全なワーク１４１５を説明するデータがメタデータ・データベース１４２２に保存される。理解されるべきことは、発行者１４１０、コンテンツ・ホスティング１４２０及びメタデータ・データベース１４２２は、上記の機能を単一のコンピュータまたは分散型コンピュータ・ネットワークにおいて実行できるということである。更にまた、ＤＲＭコンテンツ・ホスティング１４２０及びメタデータ１４２２によって実行される機能は、発行者１４１０以外のエンティティにより実行されることもできるということも理解されるべきである。

顧客１４５０は安全なワーク１４１５の複製をデジタル流通という手段を介して得る。顧客１４５０は、発行者１４１０のウェブ・サイトにアクセスして安全なワーク１４１５の複製をダウンロードすることもできる。別の方法として、顧客１４５０がインデックスまたはライブラリ・カタログを閲覧し、発行者１４１０のウェブ・サイトあるいは発行者１４１０以外のエンティティによりホストされているミラー・サイトにある安全なワーク１４１５へのリンクを偶然見つけることもあり得る。あるいは、顧客１４５０は安全なワーク１４１５を別の顧客から直接受信することもでき、つまりそれは「超流通」を介して行われる。上記のように安全なワーク１４１５は発行者１４１０によって安全にラッピングされ暗号化されているので、当該デジタル資産は顧客１４５０にとって無駄なものとなる。

顧客１４５０が安全なワーク１４１５へのアクセスを試みると、権利処理機関１４３０への接続が確立される。権利処理機関１４３０は安全なワーク１４１５に関連するユーザーが誰であるかをチェックし、発行者１４１０が安全なワーク１４１５に関連付けた権利を割り出し、


顧客１４５０から安全なワーク１４１５を使用するための代金支払いを受ける。権利処理機関１４３０は電子商取引業者１４３２と関係を築いており、クレジット・カード及びデビット・カードのトランザクションの有効性を確認したり、顧客１４５０に請求書を送ったり、発行者１４１０にトランザクションを報告したりする。電子商取引業者１４３２から肯定的なレスポンスを受信すると、権利処理機関１４３０は顧客１４５０に対し安全なワーク１４１５への鍵または許可証を発行する。顧客１４５０は当該鍵または許可証を用いて保護されたワーク１４１３にアクセスできるようになる。権利処理機関１４３０は、発行者１４１０に総売上額及び個々の顧客情報を報告するためにログまたはデータベースを更新する。理解されるべきことは、発行者１４１０、権利処理機関１４３０及び電子商取引業者１４３２は、上記の機能を単一のコンピュータまたは分散型コンピュータ・ネットワークにおいて実行できるということである。更にまた、権利処理機関１４３０及び電子商取引業者１４３２によって実行される機能は、発行者１４１０以外のエンティティにより実行されることもできるということも理解されるべきである。

別の実施例においては、顧客１４５０はコンテンツ流通業者、シンジゲーターまたは集積業者１４４０を介して安全なワーク１４１５にアクセスすることができる。コンテンツ流通業者、シンジゲーターまたは集積業者１４４０は顧客１４５０がメタデータ・データベース１４２２を閲覧することを許可する。メタデータ・データベース１４２２は、例えばリスティング・サービス、カタログ・サービスまたはセールス・ディレクトリ・サービスを含むが、これらに限定されるわけではない。顧客１４５０が安全なワーク１４１５のようなワークに興味を示すと、コンテンツ流通業者、シンジゲーターまたは集積業者１４４０はコンテンツ・ホスティング１４２０にリクエストを送り、安全なワーク１４１５を入手する。コンテンツ流通業者、シンジゲーターまたは集積業者１４４０はまた権利処理機間１４３０と連結しており、上記のように、安全なワーク１４１５に関連する権利に対する顧客１４５０からの代金支払いをコーディネートする。理解されるべきことは、発行者１４１０、コンテンツ流通業者、シンジゲーターまたは集積業者１４４０は、上記の機能を単一のコンピュータまたは分散型コンピュータ・ネットワークにおいて


実行できるということである。更にまた、コンテンツ流通業者、シンジゲーターまたは集積業者１４４０によって実行される機能は、発行者１４１０以外のエンティティにより実行されることもできるということも理解されるべきである。

図１４に図示したシナリオは脆いシステムである。一般的に、オリジナル・デジタル・ワーク１４１１の各インスタンス（即ち保護されたワーク１４１３及び安全なワーク１４１５）は別々のリソースである。更に、オリジナル・デジタル・ワーク１４１１の各インスタンスのコントロールと流通に関わる幾つかのエンティティ（例えば、発行者１４１０、ＤＲＭパッケージング・ソフトウェア１４１２、安全なラッピング及び暗号化１４１４、コンテンツ・ホスティング１４２０及びメタデータ１４２２データベース）があり得る。インターネットをサーチしたり、カタログやピア・ツー・ピア・サーバーを閲覧したりしていて顧客１４５０が見つけるリンクは、古いものであることが多い。同様に、コンテンツ流通業者、シンジゲーターまたは集積業者１４４０も安全なワーク１４１５や保護されたワーク１４１３へのリンクやレファレンスの質を保証することはできない。従って、リンクの脆さを排除しシステムの耐久性を高める装置、方法及びシステムが求められている。

図１４に図示したシナリオは、関係するシステム間に永続的なリンクが無いということだけでなく、別の理由からも脆いシステムである。その理由とは、コンテンツ自体に固有で、明確で、全世界で認識される識別子が無いということである。一般的に、オリジナル・デジタル・ワーク１４１１の各インスタンス（即ち保護されたワーク１４１３及び安全なワーク１４１５）は別々のリソースである。更に、オリジナル・デジタル・ワーク１４１１の各インスタンスのコントロールと流通に関わる幾つかのエンティティ（例えば、発行者１４１０、ＤＲＭパッケージング・ソフトウェア１４１２、安全なラッピング及び暗号化１４１４、コンテンツ・ホスティング１４２０及びメタデータ１４２２データベース）があり得る。仮にこれらのエンティティがコンテンツの固有の識別子に依存できないとすると、これらは簡易性と信頼性を持ってお互いと相互運用すること、つまりコンテンツにレファレンスするための信頼性のある方法を通じてお互いと通信することができない。これは、（バーコードとして知られている）ユニバーサル・プロダクト・コードが必ず信頼性を持って物理的なオブジェクトを


レファレンスする数多くのエンティティ間の相互運用性を可能にする方法に似ている。例えば、在庫管理システムと通信しているポイント・オブ・セール（ＰＯＳ）システム、「ジャスト・イン・タイム」補充−注文システムと通信している在庫管理システム、店舗から流通業者または製造元の注文システムに通信している補充−注文システムといったものである。しかしＤＯＩを除けばデジタル・コンテンツのオブジェクトに対しては対応する識別子がなく、よってシステム間通信及び相互運用性を可能にする識別子の欠如に表される脆さをなくすことによりシステムの耐久性を高める装置、方法及びシステムが求められているのである。

図１４はまた、デジタル・オブジェクト識別子（ＤＯＩ）を従来のデジタル権利管理シナリオに組み込むことを図示している。ワークの発行の際に発行者１４１０はそのワークに対し固有のＤＯＩを発行し、それからそれをＤＯＩ登録機関１５５０に登録する。その後ＤＯＩはシステム全体の全てのトランザクションにおいて明確に識別されたワークを指すために用いられる。例えば、コンテンツ・ホスティング・プロバイダー１４２０はＤＯＩに基づいてワークを保存し入手する。この方法ならば、発行者１４１０がコンテンツ・ホスティング・プロバイダーによってホストされているファイル１４１５を更新したい場合は、更新したファイルを同一のＤＯＩにより識別される当該ワークの古いバージョンと置き換えるような指示を付けて送信すればよい。

また別の例では、顧客１４５０にアクセス許可証を販売した権利処理機間１４３０がＤＯＩを用いて発行者の様々なワーク全ての売上額を発行者に継続的ベースで報告する。現在、多くの権利処理機関が発行者に対し売上額の報告を自動化不可能な、マニュアルの方法で、例えばタイトル、著者名及び発行年等の図書目録情報を用いて行い、販売されたワークを明確に識別しようと試みている。これにより発行者１４１０はマニュアルでセールスの情報を発行者自身のシステムに


移さなければならず、また別々に売られたものの殆ど同じ図書目録情報を共有している同一のワークの複数のバージョン間の違いを明らかにする必要があるが、これは保証されていない。各ワークの、そのワークを指す固有のＤＯＩを用いることで全ての当事者が確実に同一のワークを指すようにでき、例えば権利処理機間のセールス・システムと発行者の財務システムといった異なるコンピュータ・システム間の自動相互運用性を可能にする。

信頼性が有り、明確な識別と自動相互運用性の同じ効果は、図１４に図示したＤＲＭシステムのその他の全ての通信チャネルに適用する。例えば、顧客１４５０が保護されたワーク１４１３にアクセスするための鍵を購入すると、当該鍵は正しいもので、同じ著者による別のワークで似通ったタイトルに関連するもの、あるいは異なるフォーマットや言語のものためのものではないと確信できる。また別の例では、一群の顧客１４５０に対し一人の著者による多数の利用可能なワークを提示したいコンテンツ流通業者、シンジゲーターまたは集積業者１４４０は、メタデータ・データベース１４２２と通信して関係するワークのＤＯＩを調べ、識別されたワークそれぞれのＤＯＩを用いて権利処理リクエストを権利処理機関１４３０に送信し、その後必要に応じて適宜のワークのＤＯＩを用いてコンテンツ・ホスティング・サービス１４２０からワークをダウンロードできる。


［多重解決］
再び第１４図を参照すると、カスタマー１４５０は、ＤＯＩシステムにＤＯＩ解決のリクエストが出されるようにするには、ＤＯＩを直接装置に入力してもよいし、コンテンツ流通業者、シンジゲーターまた集積業者１４４０に頼ってＤＯＩを入力してももよいし、ＤＯＩリクエストを作ることのできるエンド・ユーザーＤＲＭソフトウェアを使用してもよい。ＤＯＩリクエストは、ＤＯＩサーバーに送られ、

安全なワーク１４１１に関連するデータに解決するが、これは、しばしばＵＲＬの形をとるポインターである。ＤＯＩは、ＤＯＩシステムになされたリクエストのタイプに応じて、多くのデータの内の一つに解決する。カスタマー１４５０またはコンテンツ流通業者、シンジゲーターまたは集積業者１４４０は、強化ＤＯＩの形をとるＤＯＩリクエストへと解決リクエストのタイプを統合するように選択し得る。一般に、強化ＤＯＩは「ＸＸＸＸ＠１０：１０００／ａｂｃ１２３ｄｅｆｇ」の形態をとる。この場合、ＸＸＸＸはＤＯＩシステムへの一つの引数または引数のリストである。発行者１４１０は、引数ＸＸＸＸのためのタイプをＤＯＩサーバーにおいて生成し登録する。例えば、安全にラップされたワークは、ラッパーの中に強化ＤＯＩを含み得る。強化ＤＯＩは、ＧＥＴ．ＲＩＧＨＴＳ＠１０．１０００／ａｂｃ１２３ｄｅｆｇといったものであり、権利処理機関の場所に解決する。権利処理機関は代金支払いを受け入れ、許可されたユーザーにコンテンツの鍵を開ける。もし、権利処理機関の場所が移動した場合にか、あるいは発行者が異なる権利処理機関と契約を結んでだ場合には、発行者１４１０がハンドル・システム・ディレクトリ入力を容易に更新でき、全ての既存のＤＯＩに基づいたリンクが、権利処理機関の変更が成される前に生成されたもにもかかわらず、機能し続ける。

更に別の例では、安全化されたコンテンツを受信し、ワークを購入するかどうか決定する前にワークの抜粋にアクセスしたいと希望する顧客がＤＯＩシステムにそのような抜粋のある場所をリクエストすることができる。ＤＯＩシステムは、抜粋を含むページのＵＲＬをもって対応するか、またはユーザーのＤＲＭソフトウェアを安全化されたファイルの僅かな一部分だけを限られた期間において無料で鍵解除できるアクセス鍵へと案内することができる。
［デジタル・ウォーターマーキング］
図１５は図１４に示したデジタル権利管理シナリオにウォーターマークを取り入れることを図示している。発行者１５４４はワーク１５４５に指定する固有のＤＯＩを受け取るためには該ワークをＤＯＩ登録機関１５５０に登録しなければならない。登録機関１５５０はワーク１５４５を説明するメタデータをＤＯＩルックアップ・データベース１５５２に保存する。それに加えて、当該の固有のＤＯＩに関連する数々のサービスが登録され、登録機関１５５０によってＤＯＩシステム１５３０に登録される。図１５は、発行者１５４４を直接通信接続により登録機関１５５０に連結しているものとして描写している。理解すべきことは、発行者１５４４、登録機関１５５０、ＤＯＩルックアップ・データベース１５５２及びＤＯＩシステム１５３０の間の通信はインターネット１５２０のようなネットワーク上で起こり得るということである。

ワーク１５４５がＤＯＩ登録機関１５５０に登録されると、発行者１５４４はワーク１５４５をウォーターマーキング及びタグ付けシステム１５４２へと転送する。ウォーターマーキング及びタグ付けシステム１５４２は、追加情報がデジタル・ワークの品質を劣化させないような方法で追加情報をデジタル・ワークに加えることにより、ウォーターマークをデジタル・ワーク中に組み込んでいる。デジタル・イメージ、動画またはオーディオ・ファイルにウォーターマークを適用するには数多くの許容可能な従来法が存在するが、本開示ではウォーターマーキングの方法を一つだけ詳細に説明する。ここで開示する新奇な特徴は、



デジタル・ウォーターマークに含まれる情報の一部としてのＤＯＩの利用に関する。ＤＯＩは解決可能あるいはアクション可能であるため、ウォーターマークを抽出することができる者なら誰でもＤＯＩを用いてワーク１５４５に関連する所有権の現在の所有者とコンタクトし、当該ワークに関連する様々な登録されたサービスの最新の場所にアクセスすることができる。例えば、あるデジタル・イメージが当該デジタル・イメージのＤＯＩでウォーターマーキングされている場合、ウェブ・サイトで当該デジタル・イメージに遭遇したユーザーはＤＯＩを抽出し自動的に当該デジタル・イメージを再使用する権利のリクエストを出すことができる。ユーザーはまたフォトグラファー及び写真の対象についての最新の情報を入手することもでき、同一の写真の高解像度バージョンを提供してもらい自らの印刷物に使用することもできる。理解すべきことは、発行者１５４４とウォーターマーキング及びタグ付けシステム１５４２は上述の機能を単一のコンピュータまたは分散型コンピュータ・ネットワークにおいて実行できるということである。更にまた、ウォーターマーキング及びタグ付けシステム１５４２によって実行される機能は、発行者１４１０以外のエンティティにより実行されることもできるということも理解されるべきである。

イメージ・ファイルをウォーターマーキングする従来の方法の一つは、最下位ビット・ウォーターマーキングである。標準のイメージ・ファイルはイメージを画像要素つまり画素の格子として表し、各画素はイメージの一領域に対応している。高品質の画像には、画像の各平方インチを表すのに９０，０００画素が必要となる。各画素に、当該画素が対応するイメージの領域を最も良く描写する色と輝度を示す数字が指定される。例えば８ビットのグレー・スケールのイメージでは、各画素に０から２５５の数字を指定してイメージの当該領域の輝度を示し、その場合のバリュー０は黒を表し、バリュー２５５は白を表し、バリュー１２７は中間の濃さのグレーを表す。０から２５５の範囲はベース２つまり二進法で８ビットで表すことができるので、各画素のバリューには８ビットの保存容量が必要となる。例えば、十進法の１５５の画素のバリューを

ベース２表示に変換したものは「１００１１０１１」（即ち、１００１１０１１（ベース２）＝１＊１２８＋０＊６４＋０＊３２＋１＊１６＋１＊８＋０＊４＋１＊２＋１＊１＝１５５（ベース１０つまり十進法）となる。従って、イメージは二進法の数字の長い数列、つまり０または１にしかならないビットによって表される。

上記の例では、「１００１１０１１」の右端の数字にベースの小さい方の指数をかけるので、右端の数字のバリューがその数字のバリューに最小の影響を与える。従って、右端の数字は「最下位数字」または二進法の数字では「最下位ビット」と呼ばれる。従って十分な深さの（つまり可能なバリューの範囲が十分に広い）イメージ・ファイルの各画素の最下位ビット変更することがイメージの劣化に繋がることは滅多に無い。

最下位ビット・ウォーターマーキングは、選択した画素のバリューの範囲にある各画素バリューの最下位ビットを置き換えることにより、ビットの数列としてのメッセージをイメージ内にエンコードする。このデジタル・ウォーターマーキングの方法は、変更によって変わる各画素のバリューは最高でも１ユニットなので、一般的に人間の目で検知できない。低品質の８ビットのグレー・スケールのイメージでさえも、色の濃度の１ユニットの変更は通常人間の目では検知できない。イメージを観る者が、ウォーターマークを予期し、イメージを分析する方法を知っている場合、ユーザーはエンコードされたメッセージを抽出することができる。

最下位ビット・ウォーターマーキングは「脆いウォーターマーク」として知られている。何故ならば、最下位ビット・ウォーターマーキングは容易に意図的に（即ち、各画素の最下位ビットをゼロに置き換えることによって）または無意識に（つまり、ロスの多いコンプレッサーを用いてイメージを圧縮したり、またはイメージをクロップしたりズームすることにより）ファイルから取り除かれてしまうからである。ウォーターマークをデジタル・ファイル中にエンコードするための、誰でも利用可能な、よりロバストな方法は他にもあり、当該分野で訓練を受けた者にはよく知られている。

図１６Ａは、図１５で示した、結果としてユーザーが保護されたデジタル・ワークを開くことになるウォータ―マーキング・プロセスの一実施例の

フロー図である。図１６Ａで示すプロセスは、発行者がデジタル・ワークを作成するステップ１６１０から始まる。ワークが作成されると、ステップ１６１２において発行者は登録機関にコンタクトしてワークに固有のＤＯＩを指定する。ステップ１６１４で、発行者はワークにＤＯＩサービス・バインディングを確立し登録する。最後に、ステップ１６１６で発行者は登録機関にメタデータを登録、保存する。メタデータは、図書目録データ、知覚指紋データ及びチェックサム・データを含むが、これらに限定されるわけではない。ステップ１６１８で、発行者はソフトウェアを用いて、ＤＯＩをウォーターマークとして用いてワークをラッピングし暗号化する。ステップ１６２０で、ユーザーはラッピングされ暗号化されたワークに遭遇し、ＤＯＩに基づくウォーターマークを抽出するＤＲＭソフトウェアを用いてコンテンツを開き、コンテンツへのアクセスを得る。

図１６Ｂは、図１５で示した、結果としてユーザーがハッキングされたデジタル・ワークにアクセスすることになるウォータ―マーキング・プロセスの一実施例のフロー図である。図１６Ｂで示すプロセスは、発行者がデジタル・ワークを作成するステップ１６３０から始まる。ワークが作成されると、ステップ１６３２において発行者は登録機関にコンタクトしてワークに固有のＤＯＩを指定する。ステップ１６３４で、発行者はワークにＤＯＩサービス・バインディングを確立し登録する。最後に、ステップ１６３６で発行者は登録機関にメタデータを登録、保存する。メタデータは、図書目録データ、知覚指紋データ及びチェックサム・データを含むが、これらに限定さるわけではない。ステップ１６３８で、発行者はソフトウェアを用いて、ＤＯＩをウォーターマークとして用いてワークをラッピングし暗号化する。ステップ１６４０で、ユーザーはラッピングされ暗号化されたワークに、当該ワークがハッキングされたりコラプトしてから流通した後に遭遇する。従って、ＤＯＩウォーターマークは有効ではないか、とりだすし不可能である。ステップ１６４４で、再合法化ソフトウェアがハッキングされたりコラプトしたワークを分析し当該ワークの知覚指紋を計算する。ステップ１６４６で、再合法化ソフトウェアがＤＯＩシステムにコンタクトし、メタデータに基づきワークのＤＯＩを探し出し、

これによりユーザーはＤＯＩを用いるＤＲＭソフトウェアを用いてコンテンツを開き、コンテンツ及びワークに関連するその他のサービスへのアクセスを得ることができるようになる。

図１６Ｃは、図１５で示した、結果としてユーザーが非公式に流通したデジタル・ワークにアクセスすることになるウォーターマーキング・プロセスの一実施例のフロー図である。図１６Ｃで示すプロセスは、発行者がワークを含むジャーナルの印刷されたバージョンを流通する等の従来の手段を用いてワークを発行するステップ１６５０から始まる。ワークの従来型の発行に続いて、フローは二つの経路に別れる。一つの経路は誰かがワークのデジタル表現を作成するステップ１６５８から始まり、ステップ１６６０で、非公式の手段を介してデジタル・ワークを流通する。ワークの非公式の流通とは、例えば、ワークのポータブル・データ・フォーマット（ＰＤＦ）バージョンを誰でもアクセスできるウェブサイトにポスティングすることを含む。別の経路は発行者が登録機関にコンタクトしワークに固有のＤＯＩを指定するステップ１６５２から始まる。ステップ１６５４で、発行者はワークにＤＯＩサービス・バインディングを確立し登録する。最後に、ステップ１６５６で発行者は登録機関にメタデータを登録、保存する。ステップ１６６２が、再合法化ソフトウェアを用いてステップ１６５２の固有のＤＯＩをステップ１６６０でワークの非公式に流通したバージョンに付けることによって二つに別れたフローを一つにする。ユーザーはワークの非公式に流通したＰＤＦバージョンをＤＯＩを用いるＤＲＭソフトウェアを用いて開き、コンテンツ及びワークに関連するその他のサービスへのアクセスを得ることができるようになる。
［有効性確認］
図１７は、図１４に示したデジタル権利管理シナリオに有効性確認アーキテクチャを取り入れることを図示している。有効性確認コンピュータ１７３０が保護されたワーク１４１３のようなデジタル・ワークをインターネット１７２０等のネットワークを介して入手する。デジタル・ワークは電子メール・サーバー１７１０、

ウェブ・サーバー１７１２または他のユーザー１７１４のコンピュータを含む電子転送ソースから出るものでもよい。代わりに、有効性確認コンピュータ１７３０が取り外し可能なディスク、メモリ保存カードあるいはその他のような物理的な媒体から直接ファイルを読み出すことによりデジタル・ワークを入手してもよい。

有効性確認コンピュータ１７３０上のソフトウェアが入手したばかりのファイルに具現されているワークのＤＯＩを割り出す。これを達成するには様々な方法がある。第一に、ＤＯＩはファイルをダウンロードし有効性確認コンピュータ１７３０のメモリに保存した際にファイルと共に入手することができる。第二に、ＤＯＩはファイルの発行者がファイルに設置したウォーターマークから抽出することもできる。第三に、ワークのＤＯＩはＤＯＩサーチ・エンジン１７４０を使って、周知の図書目録情報（タイトル、著者、発行日等）またはファイルのメタデータ（曲の長さ、イメージ・ファイルまたは曲ファイルの知覚「指紋」、実行可能なファイルのチェックサムまたはハッシュ結果等）を用いたルックアップにより入手することができる。

有効性確認コンピュータ１７３０上のソフトウェアはそれからＤＯＩシステム１７４２にクエリーを発行して、所与のＤＯＩによって識別されたワークのための有効性確認資格認定資料をリクエストする。ＤＯＩシステム１７４２はファイルの資格認定資料もって返答するか、または有効性確認データ収納庫１７４４内のそれらの資格認定資料の場所へのポインター（例えばＵＲＬ）をもって返答する。資格認定資料は周知のタイプのものか、または有効性確認プロセスをどのようにして進めるかについての情報を提供するものでなくてはならない。

有効性確認コンピュータ１７３０上で実行される有効性確認ソフトウェアはそれから、元々入手したファイルの分析を行い、入手した有効性確認資格認定資料と一致するかどうかを判断する。通常、これは元のファイルを入力として用いて一連の計算を行うことに関係し、それらの計算の結果は固定の短い長さとなり、ファイルが最初に発行されてから変更があった場合には異なるものとなる。このようにして、ユーザーはファイルが元々発行されたドキュメントの正当な複製であるかどうか判断できる。ファイルが

有効でないか、またはコラプトしたバージョンであると判断された場合は、ソフトウェアは発見したＤＯＩを用いて販路を探し出し、ユーザーは直ちにワークの有効な複製を購入あるいは取得する機会を与えられる。

ＭＤ−５やＳＨＡのような、異なる入力に対し同一の出力を生成する可能性の低い、多くの単純なハッシュ・アルゴリズムが存在する。イメージ、音声、動画またはその他のマルチメディア・ファイルの場合は、人間が認知可能なファイル間の差異を検知する有効性確認の方法を用いるのが望ましいかもしれない。そうすれば、曲がユーザーによってＣＤから複製され、別のファイル・フォーマットに変換された場合、それでもアルゴリズムは、認知可能判断基準を用いて、曲が発行されてから変更されたかを判断し、ワークの有効性を確認する。そのような認知アルゴリズムは現在ナップスターがナップスターのファイル共有ネットワーク上でどの曲が取り引きされたかを追跡するために用いられている。ナップスターの認知アルゴリズムについてのより詳細な情報は「ｗｗｗ．ｒｅｌａｔａｂｌｅ．ｃｏｍ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅｓ／０１０４２０．ｒｅｌｅａｓｅ．ｈｔｍｌ」で見ることができる。

ここに開示した実施例は、デジタル権利管理システムに保護されたデジタル化した著作物にアクセスするための十分に機能する装置、方法及びシステムを描写しているが、読者は他の同等の実施例が存在するということを理解するべきである。本開示を検討する者は数多くの変更やバリエーションを思いつくであろうから、デジタル権利管理システムに保護されたデジタル化した著作物にアクセスするための装置、方法及びシステムは、ここに図示し開示した構成と動作に限定されない。従って、本開示は請求項の範囲を逸脱しない好適な変更全てと同等のもの全てを意図するものとする。
［多重解決メニュー・ファシリティ（ＭＲＭＦ）］
図１８と図１９は、インタラクティブ・インターフェース多重解決メニュー・ファシリティ（ＭＲＭＦ）の

一つの非限定的な実施例の概略図である。図１８では、数多くの方法でユーザーにＤＯＩを提供することができる。一例では、ＤＯＩはポータブル・ドキュメント・フォーマット（ＰＤＦ）１８０１に組み込まれ、アドビのアクロバット、アドビのＥブック・リーダー、マイクロソフトのＥブック・リーダー、及び／またはその他のような電子書籍（ｅブック）リーダー１８０５で閲覧される。ＤＯＩ１８０２（例えば図１８では、ＤＯＩはハイライトされたテキスト「ここをクリック」であって、実際にＤＯＩ番号及び／またはレファレンスを、ハイライトされたテキストとしてユーザーに提示されるメタデータとして組み込んでいる）は、ポインティング・カーソル１８０３等のユーザー選択ファシリティにより発動されるが、ユーザー選択ファシリティはこれに限定されるわけではない。ＤＯＩ１８０２を選択することにより、インタラクティブ・インターフェース・メニューが生成される１８０４。ＭＲＭＦは、例えばＣ、Ｃ＋＋、ジャバ、ジャバ・スクリプト、オブジェクティブＣ、パール、パイソン及び／またはその他の数多くの標準開発ツールを用いてモジュールとして実現することができるが、標準開発ツールはそれらに限定されるわけではない。ＭＲＭＦはＤＲＭＳコントローラのユーザー・インターフェースに組み込んでもよい。一つの代替実施例においては、ＭＲＭＦは閲覧アプリケーションのためのプラグ・イン、例えばアドビのアクロバット、アドビのＥブック・リーダー、マイクロソフトのＥブック・リーダー、マイクロソフト・エクスプローラ、マイクロソフト・インターネット・エクスプローラ、ネットスケープ・ナビゲーター及び／またはその他として実現することができるが、プラグ・インはこれらに限定されるものではない。ＭＲＭＦモジュールのロジックは通常、閲覧アプリケーションによって搭載されると発動し、より詳しくはユーザーがＤＯＩ１８０２を選択すると発動する。

カーソル１８０３でＤＯＩ１８０２を発動すると、ＭＲＭＦは、表示し更に選択するための多重解決オプションのリストを得る。当該リストはドキュメントに組み込まれたＤＯＩを読み出しＤＯＩをＤＯＩ解決サーバーで解決することにより生成されるようにしてもよい。一例においては、例えばｐｏｌｌ．ａｌｌＲｅｓｏｌｕｔｉｏｎｓ＠ＤＯＩ、ｐｏｌｌ．ａｌｌＡｃｍｅＩｎｃＲｅｓｏｌｕｔｉｏｎｓ＠ＤＯＩといった強化ＤＯＩグラマーを用いて、ＤＯＩ解決サーバーからの多重解決オプションを全てをポールすることができる。その後ＤＯＩ解決サーバーは、

ＤＯＩ解決サーバーから特定のＤＯＩの記録内に保存されている全ての及び／または幾つかの解決オプションのリストを返信する。ＤＯＩ解決サーバーからこのリストを得ると、ＭＲＭＦは必要に応じて結果を解析し、ＤＯＩ解決サーバー１８０４から返信されてきた解決オプションに対応するメニュー・リストを生成する。

ユーザーに対しオプションのリストを表示すると１８０４、ユーザーは続けてオプションが拡充されたＭＲＭＦ内の表示されたオプションの何れかを選択することができる。それ以降ユーザーは、オプションが拡充されたＭＲＭＦ内に提示され表示された多重解決オプションの一つを、例えばマウスのマウス・ボタンをクリックして、カーソルの選択肢発動メカニズムを発動することによって、選択することができる１８０６、１８０７。注意すべきことは、メニュー・ヒエラルキー１８０４、１８０６、１８０７は、ＤＯＩ解決サーバーのポールの結果を解析することにより構築されるということである。得られた結果は、共通のヘッダーを有する。例えば、ＤＯＩ解決サーバーはポールの結果を、ＢｕｙＢｏｏｋ．Ｐｒｉｎｔ＠ＤＯＩ、ＢｕｙＢｏｏｋ．ＡｄｏｂｅＥＢｏｏｋＲｅａｄｅｒ＠ＤＯＩ、及びＢｕｙＢｏｏｋ．ＭｉｃｒｏｓｏｆｔＲｅａｄｅｒ＠ＤＯＩ、といった強化ＤＯＩの形態で返信し、それらを全て解析して「ＢｕｙＢｏｏｋ」というルートと、「Ｐｒｉｎｔ」、「ＡｄｏｂｅＥＢｏｏｋ」、「ＭｉｃｒｏｓｏｆｔＲｅａｄｅｒ」というサブ・メニューを持つメニューを構築することができる。更に注意すべきことは、ＤＯＩ解決サーバーからのポールの結果それ自体がＤＯＩであってもよく、その場合ＭＲＭＦがかかるポールの結果基づき更に再帰的にポールすることによって、ユーザーのためのより大きな多重解決オプションのメニューを作り上げる。オプションの一つを発動することにより、ＭＲＭＦはユーザーが選択した多重解決オプションへの特定のＤＯＩ解決を開始する。例えば、「ＢｕｙＢｏｏｋ」１８０４、「Ｐｒｉｎｔ」１８０６、「Ａｍａｚｏｎ．ｃｏｍ」１８０７のオプションを選択することにより１８０３、ＭＲＭＦはオプションを、ＤＯＩが表す情報の印刷されたバージョン（及び／またはその他全ての特定されたバージョン）を購入することのできるＡｍａｚｏｎ．ｃｏｍのウェブ・ページへと解決する。

図１９では、一実施例において、ＭＲＭＦは更にユーザーに

「Ｅ−ｍａｉｌ ａ Ｆｒｉｅｎｄ」のオプション１８０５を提示する。ユーザーが「Ｅ−ｍａｉｌ ａ Ｆｒｉｅｎｄ」のオプション１８０５を発動した場合、ＭＲＭＦはオペレーティング・システムに新規の電子メールを生成する信号を生成する。ＭＲＭＦはシステムＡＰＩ、例えばウィン３２ディベロップメント・ライブラリにあるもの、ロータス・ノートＡＰＩ、マイクロソフト・アウトルック・エクスプレスＡＰＩ、マイクロソフト・アウトルック・エクスプレスＡＰＩ及び／またはその他を幾つ用いてでも信号を生成することができる。ＭＲＭＦは適切なＡＰＩを介してコールをして、（必要に応じて電子メール・アプリケーションの立ち上げとインスタンス化と）新規の電子メール・ウィンドウのインスタンス化をリクエストする１９０８。ＭＲＭＦはインスタンス化した電子メール・アプリケーションをそのＡＰＩを介して指示し、ユーザーがそこから選択したＤＯＩ１９０６の複製を持つ新規の電子メールのメッセージを作成する。それ以降、ユーザーはユーザーの友人の電子メール・アドレス１９０７（またはそれ以外の如何なる受信者、例えば配布リスト）に所望のコメント１９０９、１９１０と共に電子メールを宛てて、ＤＯＩを電子メールを介して送り、別のユーザーが当該ＤＯＩとインタラクションできるようにする。

一実施例において、新規の電子メールのメッセージは自動的に生成され、ＭＲＭＦプラグ・インが当該の電子メールのメッセージにプラグ・インをインストールする旨の指示と共に添付され、従ってＭＲＭＦがないところでＭＲＭＦファシリティが可能になるようにしている。別の実施例では、ＤＯＩは、例えばｈｔｔｐ：／／ｗｗｗ．ｄｏｉＲｅｓｏｌｕｔｉｏｎＲｅＲｏｕｔｉｎｇＳｅｒｖｅｒ．ｃｏｍ／ｐｏｌｌ．ａｌｌＲｅｓｏｌｕｔｉｏｎｓ＠ＤＯＩというようなハイパーリンクとして組み込まれ、それによって指定されたサーバーがＭＲＭＦ機能を提供できるようにしてある。更に別の実施例では、ＭＲＭＦ機能は、指定されたサーバーから例えばジャバスクリプト、サーバーとの通信に携わるウィンドウ、及び／またはその他等のモジュールをダウンロードすることにより、サーバーによってユーザーのデバイスに提供されている。

Claims (3)

1. コンピュータの通信手段が、ネットワークを介して、デジタル著作物を取得するステップと、
   前記コンピュータのプロセッサが、前記デジタル著作物に含まれる、当該デジタル著作物に固有で永続的なユニバーサルネーム識別子を識別するステップと、
   前記通信手段が、前記ネットワークを介して、前記デジタル著作物と前記固有で永続的なユニバーサルネーム識別子を関連付けて登録する登録機関に、前記固有で永続的なユニバーサルネーム識別子を送信して前記デジタル著作物に関する資料を要求するステップと、
   前記プロセッサが、前記デジタル著作物が前記資料から得られるものと一致するかどうかに基づいて前記デジタル著作物の有効性を判断するステップと、
   前記プロセッサが、前記判断ステップにおいて前記デジタル著作物の有効性が確認できない場合に、前記ネットワークを介して、前記識別ステップにおいて前記プロセッサが識別した前記固有で永続的なユニバーサルネーム識別子に基づいて、前記デジタル著作物の入手経路を探し出すステップと、
   を有することを特徴とする、コンピュータを用いてデジタル著作物にアクセスする方法。
2. ネットワークに接続された通信手段とプロセッサとを有するコンピュータに、
   前記通信手段と前記ネットワークを介して、デジタル著作物を取得する機能と、
   前記プロセッサを介して、前記デジタル著作物に含まれる、当該デジタル著作物に固有で永続的なユニバーサルネーム識別子を識別する機能と、
   前記通信手段と前記ネットワークを介して、前記デジタル著作物と前記固有で永続的なユニバーサルネーム識別子を関連付けて登録する登録機関に、前記固有で永続的なユニバーサルネーム識別子を送信して前記デジタル著作物に関する資料を要求する機能と、
   前記プロセッサを介して、前記デジタル著作物が前記資料から得られるものと一致するかどうかに基づいて前記デジタル著作物の有効性を判断する機能と、
   前記デジタル著作物の有効性が確認できない場合に、前記ネットワークを介して、前記プロセッサが識別した前記固有で永続的なユニバーサルネーム識別子に基づいて、前記デジタル著作物の入手経路を探し出すステップと、
   を実現させるためのプログラム。
3. プロセッサと、ネットワークに接続可能な通信手段と、当該プロセッサに通信するように接続されていると共に請求項２に記載のプログラムを格納したメモリと、を有することを特徴とする装置。