(57)【特許請求の範囲】
【請求項１】
コンテンツオブジェクトに対するメタデータを提供する方法であって、
ユーザからメタデータ要求を受け取るステップであり、該メタデータ要求が、コンテンツ識別子が抽出されるところのコンテンツオブジェクトから一部分導出され、更に、該メタデータ要求が、ユーザのメタデータ嗜好を含む、該ステップと、
前記コンテンツ識別子を使用して、前記コンテンツオブジェクトに対するメタデータのセットを決定するステップであり、データベースにおいて前記コンテンツ識別子により前記コンテンツオブジェクトにリンクされた該メタデータのセットを決定することを含み、前記データベースが前記コンテンツ識別子とメタデータの異なる複数のソースとの間のリンクを維持する、該ステップと、
前記ユーザの前記メタデータ嗜好を前記メタデータのセットに適用して、該ユーザに対するメタデータ応答を生成するステップと、
を備え、
該方法は、前記コンテンツオブジェクトに対するメタデータの複数の要求を行った複数のユーザの嗜好を該複数の要求に含まれる情報に基づいて追跡して共通の嗜好に基づき前記コンテンツオブジェクトに対するユーザのグループを特定するステップと、該グループに基づいて前記メタデータ応答を調整するステップと、を更に含む、方法。
【請求項２】
前記コンテンツ識別子は、前記コンテンツオブジェクトを示す電子的コンテンツ信号の知覚可能な属性から導出される、請求項１に記載の方法。
【請求項３】
前記異なる複数のメタデータソースの１つは、ユーザのグループからのユーザ発生メタデータを含み、更に、前記データベースは、前記コンテンツオブジェクトがネットワーク内の複数の装置にわたり配布されるときに前記ユーザ発生メタデータが該コンテンツオブジェクトにリンクされたままとなるように前記コンテンツ識別子と前記ユーザ発生メタデータとの間のリンクを管理する、請求項１に記載の方法。
【請求項４】
前記メタデータ応答は、メタデータ使用情報に依存し、
該方法は、更に、該メタデータ使用情報を特定するようメタデータに対する複数の要求を追跡するステップと、前記メタデータ要求に対する応答を前記メタデータ使用情報に基づいて調整するステップと、を備える、
請求項１に記載の方法。
【請求項５】
メタデータに対する複数の要求を追跡する前記ステップは、ユーザ発生メタデータに対する複数の要求を追跡することを含み、更に、前記データベースは、前記コンテンツオブジェクトがネットワーク内の複数の装置にわたり配布されるときに前記ユーザ発生メタデータが前記コンテンツオブジェクトにリンクされたままとなるように前記コンテンツ識別子と前記ユーザ発生メタデータとの間のリンクを管理する、請求項４に記載の方法。
【請求項６】
コンテンツオブジェクトに対するメタデータを提供するシステムであって、
ユーザからメタデータ要求を受け取るハンドラーであり、該メタデータ要求が、コンテンツ識別子が抽出される部位のコンテンツオブジェクトから一部分導出され、更に、該メタデータ要求が、前記ユーザのメタデータ嗜好を含むものである、該ハンドラーと、
前記コンテンツ識別子を使用して、前記コンテンツオブジェクトに対するメタデータのセットを決定するデータベースシステムであり、データベースにおいて前記コンテンツ識別子により前記コンテンツオブジェクトにリンクされた前記メタデータのセットを決定することを含み、前記データベースが前記コンテンツ識別子とメタデータの異なる複数のソースとの間のリンクを維持する、該データベースシステムと、
前記ユーザの前記メタデータ嗜好を前記メタデータのセットに適用して、該ユーザに対するメタデータ応答を生成するルールプロセッサと、
前記コンテンツオブジェクトのメタデータに対する複数の要求を追跡して、メタデータに対する該複数の要求に関するデータを前記コンテンツオブジェクトに対応づけて記録するトラフィックモニタと、
を備え、
前記トラフィックモニタは、前記複数の要求に含まれる情報に基づいて該複数の要求を行った複数のユーザの嗜好を追跡して、共通の嗜好に基づいて前記コンテンツオブジェクトに対するユーザのグループを特定し、前記メタデータ応答は該グループに基づいて調整される、システム。
【請求項７】
コンテンツオブジェクトに対するメタデータの要求を処理するルーティングシステムであって、
前記コンテンツオブジェクトから抽出されたコンテンツ識別子を受け取って、関連のメタデータ応答を決定するＩＤリゾルバーと、
前記コンテンツオブジェクトのメタデータに対する複数の要求を追跡して、メタデータに対する該複数の要求に関するデータを前記コンテンツオブジェクトに対応づけて記録するトラフィックモニタと、
を備え、
前記トラフィックモニタは、前記複数の要求に含まれる情報に基づいて該複数の要求を行った複数のユーザの嗜好を追跡して、共通の嗜好に基づいて前記コンテンツオブジェクトに対するユーザのグループを特定し、前記メタデータ応答は該グループに基づいて調整される、ルーティングシステム。
【請求項８】
メタデータレポジトリーを更に備え、
前記コンテンツオブジェクトに対して前記トラフィックモニタによって特定されたグループは、前記メタデータレポジトリーにおいて、前記コンテンツオブジェクトに関連するコンテンツオブジェクト、製品、又はサービスにリンクされる、請求項７に記載のルーティングシステム。
【請求項９】
前記トラフィックモニタは、第１のコンテンツオブジェクトのメタデータに対する複数の要求のトラフィックを分析し、該第１のコンテンツオブジェトのメタデータに対する前記複数の要求を行った複数のユーザの嗜好を、該複数の要求に含まれている情報に基づいて分析し、共通の嗜好に基づいて該第１のコンテンツオブジェクトに対するユーザのグループを特定するように動作可能である、請求項８に記載のルーティングシステム。
【請求項１０】
前記メタデータレポジトリーは、前記コンテンツオブジェクトに対する前記グループのユーザが前記コンテンツオブジェクトに対するメタデータを協働的に追加するのを許容するように動作可能である、請求項８に記載のルーティングシステム。
【発明の詳細な説明】
【関連出願】
【０００１】
本出願は、２００６年５月１６日に出願された米国プロビジョナル特許出願第６０／７４７，４０８号、及び２００５年１２月２１日に出願された第６０／７５３，２５７号の利益を主張するもので、これら特許出願は、参考としてここに援用される。
【技術分野】
【０００２】
本発明は、物理的オブジェクト及び電子的オブジェクトの両方を含むコンテンツを、ネットワークを通してメタデータに関連付けるための方法及びシステムに係る。
【背景及び概要】
【０００３】
本明細書は、「クリエイティブワーク」と称されるグランドアンブレラのもとに集合的に入り得るピクチャー、音楽、映画、及びそれらの様々な全てのクリエイティブな仲間を参照するために、「コンテンツ」、「メディア」及び「メディアコンテンツ」という語を交換可能に使用する。一般に、所与のクリエイティブワークは、エンティティ又は「コンテンツオブジェクト」として考えることができ、また、クリエイティブワークは、名前又は識別番号の単独のコンパニオンで孤立したものであるか、又は非常に広範囲の種々の配布方法及びチャンネルに対して何らかの仕方で複写されパッケージされたものである。
【０００４】
主として後者のケースでは、所与の単数コンテンツオブジェクトに対しある形式の明示的又は暗示的関係を有する付加的なクリエイティブワークを指す「メタデータ」のコンセプトが人気を得ている。メタデータとは、一般的に、コンテンツオブジェクトに関連した情報を指す。典型的に、メタデータは、イメージ、並びにビデオ及びオーディオプログラムのようなマルチメディアコンテンツにしばしば関連付けられ、ソース、オーナー、コンテンツタイトル、等のコンテンツに関する情報を指すのに使用される。メタデータのより簡単な形式の１つは、著者の名前や、コンテンツオブジェクトが自然に入るカテゴリーのようなコンテンツオブジェクトに関する付加的な情報を述べるビットフィールドである。メタデータのより複雑な形態は、関連コンテンツオブジェクトの「ポインタ」又はアドレス（例えば、ＵＲＬ）であり、これは、参考として、ユーザ又はコンシューマが第２のコンテンツオブジェクトに容易にアクセスできるようにする。最も一般的に、コンテンツプロバイダー及び／又はコンテンツ配布者の観点からの重要なコンセプトは、配布されたコンテンツオブジェクトの１つを経験するコンシューマとそれら自体との間にメタデータにより瞬間的な電子的関係を形成できることである。
【０００５】
本明細書において、メタデータは、コンテンツオブジェクトに関する広いクラスの情報を指し、また、物理的及び電子的の両オブジェクトを含む広いクラスのコンテンツオブジェクトに適用される。また、メタデータは、１つ又は複数のマシンにより実行されて、オブジェクトに関連した振舞いを実行する（例えば、オンライントランザクションを実行し、コンテンツを送信又は転送し、ユーザ、コンテンツ、アクセストークンを認証／検証し、プログラムを更新／パッチし、等々）インストラクション又はインストラクションセット（おそらく１つ以上の装置にわたって配布される）も含む。また、メタデータは、種々のフォーマットにフォーマット化して記憶することができる。１つのフォーマットは、ＸＭＬであるが、他のフォーマットもある。特定のコンテンツオブジェクトに対するメタデータを異なる記憶装置にわたって配布してもよい。このような配布型記憶解決策では、１つの位置のメタデータは、他の位置のメタデータへの参照を含む（インデックス、ポインタ、アドレス、ＵＲＬ、等の）。
【０００６】
本発明の１つの態様は、この電子的関係が最初に起きるように確保し、且つこの関係がいつか一次メディア配布収入発生のライバルとなってそれを陰らせ得る二次収入発生機会を導くことのできるメタデータルーティング及び関連ネットワークサービスを含む技術的インフラストラクチャーに係る。
【０００７】
パッケージされたメディアを販売するか、さもなければ、特定のメディアを、ターゲットとする聴衆に配信するビジネスは、そのメディアの一次配信を現金化する長い歴史を有する。レコードを販売するか、又はテレビのショーにおける３０秒の広告を販売するか、或いは映画のチケットを販売することは、各々、一次配布現金化ビジネスモデルに適合している。インターネットが成長し、種々のデジタル配布チャンネルが花開くことは、確かに、一次メディア配布それ自体の説明を複雑にしたが、クリエイティブワークを「パッケージアップ」してそれを何らかの明示的補償戦略で配信するという一般的な観念は、そのままになっている。
【０００８】
一次配布モデルの一種の直接的外挿において、デジタルライツマネージメント（ＤＲＭ）の発明及び解決策は、現在それらの集合的ベルトのもとに、少なくとも１０年の価値ある努力、設計、試行、部分的成功及び貴重なレッスンを有している。このレッスンに少なからずあるものは、ＤＲＭ解決策のコアプロパティと考えられるものは何か、即ち「誰が規格を所有し、誰がチャンネルを所有し、誰が最終的にコンシューマ関係を所有するか？」という質問にまつわるタイタンの舞台裏でのビジネスコミュニティレスリング及び衝突である。このようにフレーズにすると、なぜ均一なグローバル規格がおそらく数十年も離れているかが若干不可解である。
【０００９】
２つの若干異なる力が過去１０年間又は２０年間に生じており、これは、古典的な一次メディア配布現金化に対して完全に有害ではないが、それでも、現金化の二次方法を探索するのに一次配布収入に依存しているビジネスに著しい圧力をかけている。少なくとも、これらの力は、一次配布方法をどのように利用するかについて基本的な戦略変更を招いている。
【００１０】
第１の力は、クリエイティブワークを無許可の形態でコピーして再配布することのできる容易さである。第２の力は、クリエイティブワークを経験するのに使用される高度に配布されるメディア配布チャンネル及び等しく高度に配布される最終装置、最も確かなものでは移動装置を含む、の出現である。これら２つの力は、互いに若干異なり、その各は、絶え間ない起業家の努力及び会社により「機会」へと部分的に変換されるが、両方の力は、一次メディア配布の現金化に対する慣習的な解決策を停止不能に混乱させているという事実が残っている。
【００１１】
クリエイティブワークを比較的容易にコピーできることは、人々が家族休暇からの写真を共有するだけでなく、昨夜楽しんだ最新の映画も共有するというピア・ツー・ピアネットワークの現在馴染みのある観念を創造する上で一次燃料となっている。技術的思案及び工業規格イニシアティブの数えられない年月は、一次パッケージメディア配布及びそれに関連した現金化の中心的役割を再確立するように求め、ある程度の成功がないでもないが、創造−消費の現金化の古き善き日を再現するよう求める者にとって精霊はボトルの外にいるように思われる。整合された一次及び二次の現金化戦略及び現金発生メカニズムは、当然、高度に配布された配布チャンネル及び消費装置の第２の力を定着させ、おそらく、それを取り込むことである。偏在する接続性が偏在する配信を満足するような有望な「移動」メディア消費トレンドが特に注目される。
【００１２】
一次及び二次の現金化方法のこの当然のバランスを依然失わせているのは、二次現金化方法及びシステムの重要な細部と、一次配布方法及び戦略に対するそれらの存在の影響である。換言すれば、二次現金化がどのように作用するか（リングトーンの宣伝一次配布を越えて）、及び一次配布生産プロセスをどのようにシームレスに変更して、全体的なメディア産業の利益及び収入ラインを、肯定的な、強力に成長する経路に戻すかである。本明細書は、ルーティングシステム及び方法を説明すると共に、著しく複雑なメディア配布及び消費分野においてそれを機能できるようにするシステム及びネットワークコンポーネントのハードウェア及びソフトウェアを詳細に説明する。
【００１３】
［メタデータの源泉の管理］
配布者がコンシューマへのメディアオブジェクトの一次配信を行うと、次に「管理」すべき最良のことは、その配信されたオブジェクトに価値を追加するメタデータサービスである。これは、メディア消費振舞いに対するパッケージング及びモノリシックＤＲＭシステム解決策の最近１０年間の価値の基石に対して書かれたワードである「コントロール」と称される破滅に至る道ではなく、基本的には、最初にメディアコンテンツに自然に引き付けられる個人又はグループに対する最高のクオリティの関係を管理することに関する。「良い資料」メタデータをオリジナルメディアコンテンツの一次配信へ最初にパッケージングすることは、コンシューマが、公式に容認されたメディアに対して控え目な額を支払う主たる理由の１つであったが、それは、高いクオリティのメディアへの進行中アクセス、グループの緊密性、及び正直なコンシューマを正直であるよう強要する関連メディアへのシームレスなアクセスとなり、それらは、単に、時間及び金銭に対してそのように高い値を得るだけである。
【００１４】
明らかに、メディアオブジェクトをスタティックなメタデータに結合するか、又は本来動的なウェブベースコンテンツへの「スタティックなリンク」にも結合することは、この時点で開発された技術であって、幾つかのＰ２Ｐネットワークチャンネルに勝る一次配布チャンネルの進行中の存続力をある程度考慮している。換言すれば、「良い特別な資料」でのパッキングは、依然、レコード及び映画並びに写真を販売する。Ｐ２Ｐコピーは、これを維持するよう試みることはできるが、合法的な配布者は、正確には、法的な所有者又は配布権保有者であるので、法的に認めざるを得ないコンテンツの入手性について支援することができる。
【００１５】
ある広告ベースのビジネスモデルでは、コンテンツオブジェクトが無料又は低コストで配布され、広告収入のためのビヒクルをなす。これらのモデルは、コンテンツ所有者が、コンテンツ内に広告を搬送することによりコンテンツを現金化するための機会を与える。更に、ワイヤレスネットワーク及びインターネットのような配布ネットワークにおいてこの機会を資本化するために、コンテンツの消費を収入の機会に結び付け、例えば、コンテンツを電子的トランザクションにリンクして、そのコンテンツ内で広告された関連コンテンツ又は製品及びサービスを購入するためのメカニズムが要望される。
【００１６】
好都合なことに、全てのメディア配布及びメディア消費のデノミネータの中で、決して消えうせることがなく、且つコンテンツプロバイダーとコンテンツコンシューマとの間に安定な関係を確保する熱意のある共通のデノミネータは僅かである。１つの共通のデノミネータは、単に、コンテンツそれ自体のアイデンティティである。別の共通のデノミネータは、「法的な配布及び消費」の常識的な観念と、コンテンツプロバイダーへの投資に対する返礼の関連観念とを集合的に定義する基本的なビジネスルール及び法的なフレームワークの存在である。第３の共通のデノミネータは、消費されているコンテンツに関連した最良の情報へアクセスするためのコンシューマのほぼ普遍的な希望である。最後に、第４の共通のデノミネータは、コンテンツプロバイダーが、自分で配布するコンテンツに関連した「関係のルール」の所有を希望することであり、即ちビジネスルール及び契約は、合法的で且つコンシューマに馴染みのあるメタデータ関係をどのように実施するか定義しなければならない。
【００１７】
本発明の１つの態様は、この章のタイトル、即ちコンシューマが希望し最終的に期待するメタデータの源泉の管理、が示すように、この観念に係る。このコインの他の側は、コンシューマを満足する背後の古典的なビジネス原理、即ちこの源泉の管理に最高クオリティの「報酬」を与えて繰り返しのビジネスを確保する、ことである。
【００１８】
メディアフローのグローバルな不協和音においてこの管理をどのように行うかの生のメカニックは、これらの出現するコンテンツ配布及び現金化モデルに対する技術的な基礎をなす。注意深い読者であれば、明らかなように、ここに述べるシステム及びネットワークメカニズムは、一方では、インターネット及び古典的専用メディアチャンネル配信ネットワークの「デジタル収容」ワールドにおいてＤＲＭベースの解決策に対して完全に相補的であり、また、他方では、移動装置消費の複雑さ及び急激な成長を完全に取り扱うことができる。
【００１９】
図９に示す一実施形態では、ルーティングシステムは、コンシューマにより保持されたメディアオブジェクトをメタデータのソースにリンクするのに使用される２つの一次処理エンジンを備えている。ＩＤリゾルバー及びレジストリコンポーネントを含む第１エンジンは、識別システム、方法、技術等のリンガフランカとして説明することができる。また、これは、実質上「コンテンツオブジェクトのＤＮＳ」として効果的に説明することもできる。というのは、この識別エンジンは、コンテンツ識別に対する任意の及び全てのネーティブな又はモノリシックな解決策を尊重するからである。従って、ＤＮＳの前に、修飾子「実質上」がつく。その機能は、異種のコンテンツ識別システムから発生する識別情報に基づいてコンテンツＩＤを解明することである。
【００２０】
第２エンジンであるルールデータベース及びプロセッサは、解明されたコンテンツＩＤに基づいてコンシューマをどこに再方向付けするかを決定する。このルールエンジンは、二次収入発生機会を容易にする。というのは、メタデータ応答を調整して、関連コンテンツ、製品及びサービスを提供するように、システムを更にイネーブルできるからである。コンテンツプロバイダーの分野は、複雑であると共に、プレイ時に種々様々なビジネス関心事をしばしば有している。このような関心事は、ほとんどの場合に、最初に作品を創造するアーチストを含む種々のエンティティ間の契約においてカプセル化され、また、このような契約は、メディア消費セッション中に通常の及び／又は先を見越したメタデータ要求に対するメタデータ応答の詳細なルールへと拡張することができる。コンシューマに対する応答のクオリティ、及び古典的な眼球／広告経路を含む付加的な収入発生活動にコンシューマを方向付けする機会は、このルールエンジンによってイネーブルすることができる。
【００２１】
図９は、第１及び第２のエンジンをルーターシステムの一部分として示しており、これらのエンジンは、仕切られ、装置を経て配布され、更に、異なる参加者により制御することができる。ルールプロセッサ及びデータベースは、ルーターシステムから仕切られ、異なる参加者により各々制御される別々のインスタンス生成において実施することができる。この場合、例えば、リゾルバーは、ＩＤレジストリを経てオブジェクトにリンクされた参加者の制御のもとでコンシューマをルールエンジンへ再方向付けし、次いで、このルールエンジンは、コンシューマ（特定のメタデータに対するＵＲＬ又はＵＲＬのセット）に対するメタデータ応答を決定するルールを実行する。また、ルールプロセッサは、クライアントのコントロールのもとで少なくとも一部分は装置において実行されてもよい。この場合、例えば、ＩＤレジストリを経てコンテンツオブジェクトにリンクされたＵＲＬのセットがクライアントに返送され、クライアントは、次いで、コンシューマに対して調整されたメタデータ応答を決定するためのルールを実行する。
【００２２】
パッケージされたメディアを販売する古き善き日は、依然として我々にある。販売されているコンテンツは、ここでは、古典的な「ブランド化」をかろうじて推測できる仕方での進行中の関係に対する種である。この開示は、コンテンツプロバイダー及びコンテンツコンシューマの同様の商品に対してこれら２つのコアエンジンをどのように構築して動作できるかを詳細に述べる。
【００２３】
［メタデータとコンテンツオブジェクトとの間の関係の管理］
上述したように、メタデータは、コンテンツオブジェクトにおいてトランザクションを管理し容易にする上で重要な役割を演じる。幾つかの意義深い実施例は、コンテンツのデジタル配布、電子コマース、並びに膨大なデータ記憶部（例えば、インターネット）のオンラインサーチ及び編成にメタデータを使用することを含む。デジタルワールドが激増し且つコンテンツオブジェクトで多数のトランザクションが行われるにつれて、メタデータとコンテンツオブジェクトの関連付けを管理することがやむを得ず必要となる。
【００２４】
この必要性は、デジタル領域に限定されない。人間は物理的及びアナログ領域に住んでいるので、デジタル領域とアナログ領域との間を行ったり来たりするための効率的な機構が常に必要とされる。特に、物理的オブジェクトは、電子的なオブジェクトと同様の対応するメタデータを有している。例えば、製品は、製品情報、マニュアル、関連製品のカタログ、等の形態の対応するメタデータを有する。印刷されたオブジェクトは、オブジェクトの電子的バージョン、所有権、ソース、創作時刻及び場所、等の形態のメタデータを有する。物理的オブジェクトは、製品又は関連ドキュメンテーション（例えば、パッケージ、ラベル、等）の上の、又はそこから導出された識別子を経てそれらのメタデータにリンクされる。従って、この物理的／電子的インターフェイスをサポートできるためにはメタデータ管理技術が必要になる。新生のアプリケーションは、参考としてここに援用する米国特許第６，９４７，５７１号及び第６，５０５，１６０号、並びに国際特許出願ＷＯ９７／４３７３６号に説明されたように、インターネット関連情報及び電子的トランザクションに物理的オブジェクトをリンクすることを含む。
【００２５】
異種コンテンツデータのメタデータを管理する意義深い態様は、コンテンツ識別のための有効な技術及び機構を提供する。これは、多数の潜在的に競合するコンテンツ識別技術及びアーキテクチャーが存在するデジタル領域において重要である。また、物理的オブジェクトから抽出され又は導出された識別子がデジタルワールドにおいて物理的オブジェクトのデジタルアイデンティティの一形式を与えるようなデジタル領域では物理的オブジェクトに対してメタデータを管理するのが重要である。本明細書におけるメタデータシステム及び方法は、デジタル領域のみで動作する識別システム、並びにデジタル領域及び物理的領域に及ぶ識別システムで機能するように設計される。後者のカテゴリーは、オーディオ又はイメージのアナログ表現から捕獲された電磁信号からコンテンツ識別子（例えば、デジタル透かし、コンテンツ指紋、視覚記号、パターン認識、音声認識、ＯＣＲ、等）を導出すると共に、磁気ストライプ（及び他の磁気データキャリア）、ＲＦ  ＩＤタグ、スマートカード等のような物理的データキャリア装置の電磁リーダーを経て読み取られるコンテンツ識別子を導出する識別方法を含む。例えば、ｗｗｗ．ｅｐｃｇｌｏｂａｌｉｎｃ．ｏｒｇ、及び参考としてここに援用する概略ドキュメント（www.epcglobalinc.org/news/EPCglobal_Network_Overview_10072004.pdf）に説明されたように、ＲＦＩＤタグを経て物理的オブジェクトを識別することができる。
【００２６】
このようなコンテンツ識別技術は、コンテンツオブジェクトを識別する手段を提供するが、種々のコンテンツ識別機構及びフォーマットが適合性及び相互運用性に課題を有している。更に、このようなシステムは、種々の識別子を適当なメタデータに関連付けるための有効なシステム及び方法がないと、有用な情報を与えることができない。
【００２７】
デジタル配布がコンテンツをパッケージングから分離し、新規な１−１マーケッティング機会が最小限利用され、且つデジタル分布が独占的チャンネルで前方に移動され、これが、価値チェーンを簡単ではなくより複雑にするという事実により、問題が幾重にも重なって形成される。
【００２８】
例えば、コンテンツがデジタル化されると、物理的パッケージングで典型的に搬送される情報がコンテンツから失われる。デジタルダウンロードは、部分的な製品で、「パッケージング及び関連メタデータのないファイル」である。メタデータロスは、デジタルコンテンツ管理、海賊行為、及びｅ−コマースにまつわる問題の中心である。複数の分布チャンネルのメタデータレポジトリーを手動でポピュレーションすると、人為的エラー及び不正確なメタデータを生じる。
【００２９】
コンテンツが配布されると、マーケッティングの機会が失われる。というのは、コンテンツ所有者及び保有者がコンシューマとの接触を失うからである。特にデジタル配布獲得トランザクションで１−１マーケッティング能力を失うと、潜在的な収入のロスを招く。
【００３０】
配布のチャンネル（例えば、オンライン音楽リテーラー、ポッドキャスト、社交的ネットワークサイト、ユーザ発生コンテンツサイト、及びＰ２Ｐネットワーク）、及び単一のデジタル製品から由来するデジタル派生物（リングトーン、移動ビデオ、等）が増加しつつある。コンテンツを有効に管理するためには、正確且つ有効なコンテンツ識別が絶対的に必要である。コンテンツ所有者は、現在、それらのメタデータレポジトリーを評価し、コスト効率の良い仕方でどのように合理化するか理解する試みをしている。
【００３１】
独占的なコンテンツ識別及びメタデータシステムは、価値チェーンを簡単にするのではなく、複雑にする。コンテンツは、相互動作しない多数の識別子と共に埋め込まれる。幾つかの独占的システムは、コンテンツ所有者を入力せずにメタデータにコンテンツをリンクし、従って、価値チェーン参加者の数を増加させる。
【００３２】
中央コンテンツメタデータレポジトリーを生成するための以前のイニシアティブは、ディレクトリサービスではなくレポジトリーを生成する独占的、政略的及び技術的問題のために、失敗していた。コンテンツ所有者及び保有者は、それらの独占的メタデータを管理し、コンシューマとの関係の構築に参加することを希望する。第三者のメタデータ会社、及びその関連会社、例えば、編成し、分類し、サーチし、そしてサーチ結果をメタデータに基づいて与える会社（例えば、サーチエンジンプロバイダー）は、コンテンツ所有者のメタデータの潜在的な無断使用から利益を得る状態にある。
【００３３】
本明細書は、メタデータをコンテンツオブジェクトに関連付けるためのシステム及び方法を説明する。コンテンツメタデータディレクトリサービスと称される新規なルーティング方法及びシステムの実施形態について説明する。
【００３４】
［グルーバル一意識別子機構］
コンテンツオブジェクトをメタデータに関連付ける１つの新規な方法は、コンテンツ識別子と境界識別子の組合せを使用して、潜在的に競合するコンテンツ識別子を伴うコンテンツオブジェクトに対してコンテンツ識別子の異種セットを取り扱うことができるようにする。この方法は、コンテンツ識別子のセットの中からコンテンツオブジェクトに対するコンテンツ識別子を受け取る。これは、コンテンツ識別子のセットに対して一意境界識別子を与える。この一意境界識別子は、コンテンツ識別子と組み合わせて使用されて、コンテンツオブジェクトに対するグルーバル一意識別子を形成する。このグルーバル一意識別子は、メタデータソースに関連付けられ、これは、メタデータソースへのユーザのルーティングを可能にする。
【００３５】
この解決策は、ＩＤプロバイダーがコンテンツ識別子のセットをオブジェクトに予め指定し、次いで、後でそれらを本出願人の新規なディレクトリシステムに登録するケースを有効に管理する。また、これは、ＩＤプロバイダーによりコンテンツオブジェクトにコンテンツ識別子を挿入する前にディレクトリシステムがコンテンツ識別子を指定するケースも管理する。
【００３６】
ＣＭＤＳ実施形態で述べたように、一意境界識別子は、ＩＤプロバイダー識別子を含むことができる。例えば、ＲＦＩＤ、ＥＰＣ、デジタル透かし及び指紋技術のプロバイダーは、コンテンツＩＤ番号は重畳するが、一意ＩＤプロバイダーＩＰをもつシステムにおいてＩＤプロバイダーとして働くことができる。また、各ＩＤプロバイダーは、ＩＤバージョンを使用して、その技術又はコンテンツＩＤスペースの異なるバージョンを区別することができる。
【００３７】
適当な登録の後に、ディレクトリシステムを使用して、ユーザをメタデータソースへルーティングする。例えば、ユーザ（例えば、ユーザ装置で実行するリーダー）は、コンテンツオブジェクトからのコンテンツＩＤ及び境界識別子を与える。ディレクトリシステムは、次いで、コンテンツオブジェクトに対するグルーバル一意識別子に関連したメタデータソースへユーザをルーティングする。
【００３８】
［複数のコンテンツ識別子でコンテンツオブジェクトをサポートするメタデータディレクトリ］
別の新規な方法は、異なるメタデータソースを潜在的に参照する２つ以上のコンテンツ識別子でコンテンツオブジェクトに対処する。この方法は、コンテンツオブジェクトに対してグルーバル一意異なる識別子を登録する。これらのグルーバル一意識別子は、各々、コンテンツオブジェクトと共に与えられるコンテンツ識別子と、コンテンツ識別子がメンバーであるところのコンテンツ識別子のセットを識別する境界識別子とを含む。グルーバル一意識別子の各々に対し、メタデータソースに関する情報が維持される。この方法は、コンテンツオブジェクトに対して第１のコンテンツ識別子を受け取り、その第１のコンテンツ識別子のセットに関連した境界識別子を使用して、第１のコンテンツ識別子に対するグルーバル一意識別子を決定する。ユーザは、グルーバル一意識別子に関連したメタデータソースへルーティングされる。
【００３９】
この解決策は、登録又は解明のためにコンテンツオブジェクトに対して２つ以上のコンテンツ識別子が与えられる種々のケースを取り扱う。メタデータディレクトリシステムは、コンテンツオブジェクトの異なるコンテンツ識別子に対応する異なるメタデータソースの登録及びそこへのルーティングの両方をサポートし、管理する。これらのケースは、次のものを含む。
【００４０】
１．コンテンツ識別子は、異なるＩＤプロバイダーにより埋め込まれ又は計算され、そしてこれらの技術に関連した異なるリーダーを使用してコンテンツオブジェクトから後で導出される。例えば、リーダーは、異なるコンテンツ識別方法を使用して（例えば、ファイルヘッダ／フッタ、デジタル透かし、指紋、ビデオプログラミングにおける垂直帰線消去インターバルデータ等により）コンテンツ識別子を導出するので、異なるものである。
【００４１】
２．異なるリーダーは、例えば、コンテンツオブジェクトの異なる属性を使用してコンテンツ識別子を導出することができる。これらの異なる属性は、異なる形式の埋め込まれた補助的データ（異なる透かし埋め込み器／リーダー、透かし・対・埋め込まれたヘッダ／フッタデータ）を含んでもよい。また、これらの異なる属性は、異なるデジタル透かし又は健全なハッシュが導出されるところの属性を含んでもよい。異なる属性は、コンテンツオブジェクトのインバンド及びアウトオブバンド属性に対応してもよい。「インバンド」とは、人間が知覚するようにレンダリングされるコンテンツオブジェクトのコンテンツから導出される識別子を指す。「アウトオブバンド」とは、コンテンツオブジェクトで搬送されるが、人間が知覚するようにレンダリングされるコンテンツの部分を形成しない補助的データを指す。ある形式のコンテンツオブジェクトは、ビデオ及びオーディオトラック並びにクローズドキャプションテキストのように、人間が知覚するようにレンダリングされる複数のコンテンツプログラムを含む。インバンド識別子は、コンテンツオブジェクト内のこれらコンテンツ信号の１つ以上から導出されてもよい。あるケースでは、オーディオビジュアル作品のオーディオ又はビデオプログラムにクローズドキャプションテキストが埋め込まれる場合のように、あるコンテンツプログラムが単一のコンテンツオブジェクト内の別のコンテンツプログラムに埋め込まれてもよい。
【００４２】
３．コンテンツオブジェクトに対する異なるコンテンツ識別子は、異なるインバンド及びアウトオブバンド部分を含むコンテンツオブジェクトの異なる部分、並びにオブジェクトのインバンド部分内の異なる部分及びアウトオブバンド部分内の異なる部分を使用して、コンテンツオブジェクトから導出されてもよい。これら部分は、コンテンツ信号のあるドメインの個別の位置で、しかも、他のドメインの重畳する位置にあってもよい。ドメインは、例えば、コンテンツオブジェクトにおけるコンテンツ信号の空間的、時間的及び変換ドメイン（例えば、周波数ドメイン、圧縮されたドメイン、等）を含む。
【００４３】
［異なるＩＤプロバイダー及びコンテンツプロバイダーの参加者のイネーブリング］
幾つかのメタデータシステムでは、登録権威者（ＲＡ）として働くシステム所有者が識別技術を提供し、そしてコンテンツ所有者がその技術を使用して、彼らをコンテンツプロバイダーとして登録し、コンテンツを登録し、更に、コンテンツをメタデータにリンクする。
【００４４】
本明細書は、システムを登録して使用するように複数のアイデンティティプロバイダー（ＩＤプロバイダー）をイネーブルする新規なシステムを説明する。ＩＤプロバイダーは、メタデータディレクトリシステムに登録を行い、独特な境界識別子を受信し、この境界ＩＤ（例えば、ＩＤプロバイダーのＩＤ）を、メタデータディレクトリシステムとのその後の対話で使用する。それとは別に、メタデータソースプロバイダーがメタデータソースをメタデータディレクトリシステムに登録する。これは、１つ以上の識別プロバイダーを使用してコンテンツオブジェクトをメタデータソースに関連付けるように多数の異なる参加者をイネーブルする。メタデータソースプロバイダーは、例えば、異なるＩＤプロバイダーと共に機能してコンテンツオブジェクトをメタデータに関連付けるという融通性を有するコンテンツ所有者又はリテーラーのようなコンテンツプロバイダーを含む。コンテンツプロバイダー及びＩＤプロバイダーは、両方とも、システムを登録して使用することができる。メタデータソースは、ウェブサイトのような、メタデータを提供するシステム又は装置である。ディレクトリシステムは、メタデータソースに対する識別子を使用し、コンテンツオブジェクトと、それに対応するメタデータソースとの間の関連性を維持するようにそれをイネーブルする。例えば、幾つかの実施形態では、ＵＲＬは、ソースの位置を識別するように働く。
【００４５】
ディレクトリシステムの一実施形態は、ＣＭＤＳと称される。ＣＭＤＳは、このＣＭＤＳを使用するようにコンテンツプロバイダーをイネーブルし、異種の以前に不適合であったＩＤプロバイダー技術を使用してコンテンツに関連付けられたメタデータソースを編み合わせるようにする。ＣＭＤＳは、独占的情報を管理するようにコンテンツプロバイダーをイネーブルし（即ち、彼らは、メタデータを記憶し配布するために独占的メタデータの制御をＲＡへ引き渡す必要がなく）、全ての価値チェーン参加者に対してｅ−コマースをイネーブルし（例えば、コンテンツ所有者及びリテーラーの両方がＣＩＤを埋め込むことができ）、全てのコンテンツアイデンティティプロバイダー技術（ＥＰＣのような既存のＩＤシステムでも）との相互運用性を容易にし、ＰＣ及び移動装置の両方との適合性を許し、共通の識別アルゴリズムを認可する複数のＩＤプロバイダーに対する相互運用性を容易にし、更に、使用報告及び必要不可欠なマーケッティング統計学的情報をイネーブルする。
【図面の簡単な説明】
【００４６】
【図１】コンテンツオブジェクトをメタデータソースに関連付ける方法を示すフローチャートである。
【図２】コンテンツオブジェクトをメタデータソースにリンクするためのリーダーとディレクトリシステムとの間の対話を示すフローチャートである。
【図３】メタデータディレクトリシステムを示すと共に、コンテンツＩＤを登録するための該システムとＩＤプロバイダーとの対話、及びコンテンツＩＤを解明するための該システムとリーダーとの対話を示すシステム図である。
【図４】コンテンツ識別及びルーティングシステムを概略的に示すシステム図である。
【図５】ユーザのコンテンツオブジェクトから抽出されたコンテンツ識別子に基づき、ルーティングシステムを使用してユーザをコンテンツプロバイダーに方向付けする使用モデルを示す図である。
【図６】ルーターの実施をより詳細に示す図である。
【図７】ディレクトリシステムの一実施形態における分散型ルーターシステムを示す図である。
【図８】異なるコンテンツ所有者参加者を伴うディレクトリシステムアーキテクチャーの一例で、このシステムを使用して、コンテンツ識別子を、それらが制御するメタデータソースに関連付けるところを示す図である。
【図９】ルールプロセッサ及びトラフィックモニタを含むルーティングシステムを示す図である。
【詳細な説明】
【００４７】
図１は、コンテンツオブジェクトをメタデータソースに関連付ける方法を示すフローチャートである。この図は、コンテンツメタデータディレクトリシステムがコンテンツＩＤの登録をどのように遂行するかを示すように意図され、これは、次の２つの目的を達成する。
１．異なるコンテンツ識別機構を、潜在的に重畳するコンテンツＩＤ機構と一体化できるようにし、及び
２．各コンテンツＩＤを１つ以上のメタデータソースに関連付ける。
【００４８】
ブロック１００に示すように、ディレクトリシステムは、コンテンツＩＤを受け取る。これらのコンテンツＩＤは、予め存在するセット（例えば、ＩＤプロバイダーにより予め指定された）から発生するか、又はディレクトリシステムそれ自身が要求のあったときにＩＤプロバイダーに対するコンテンツＩＤを発行する。ＩＤプロバイダーは、コンテンツオブジェクトに対してコンテンツ識別を与えるエンティティを指す。典型的に、これは、コンテンツ識別技術プロバイダーであり、例えば、コンテンツオブジェクトに対してインバンド識別子（例えば、透かし又は指紋）又はアウトオブバンド識別子（ＤＲＭコンテナ技術、ＶＢＩインサーター、等）を計算するためのプロバイダー技術である。
【００４９】
コンテンツＩＤの異なるセット間を区別するために、ディレクトリシステムは、ディレクトリに登録されたコンテンツＩＤの各一意セットに対してブロック１０２に示すように一意境界識別子を与える。これは、コンテンツＩＤの異なるセットに対するＢＩが衝突しないことを保証する。従って、衝突しない既存のＢＩを登録することはできるが、ディレクトリシステムが、ＢＩを発行するか、又は少なくとも、衝突を防止するのに使用するためのガイドラインを発行するのが好ましい。
【００５０】
ディレクトリシステムは、オブジェクトに対するコンテンツＩＤを、当該コンテンツＩＤがメンバーであるところのコンテンツＩＤのセットに対するＢＩと結合することにより、それが管理する全てのコンテンツオブジェクトに対してグルーバル一意識別子（ＧＵI）を形成する（ブロック１０４）。
【００５１】
ディレクトリシステムは、ブロック１０６に示したように、コンテンツオブジェクトに対するＧＵＩをメタデータソースに関連付ける。以下に述べるように、このメタデータソースは、コンテンツオブジェクトに対するコンテンツＩＤを供給するエンティティからの要求に応答してメタデータを与える。ディレクトリシステムは、要求側のエンティティをメタデータソースへ迅速に効率的にルーティングできるように、コンテンツオブジェクトのＧＵＩとメタデータソースとの間の関連性を記憶する。一実施形態において、ディレクトリシステムは、ＵＲＬのような、ネットワークにおけるメタデータソースの位置を記憶する。これは、要求側エンティティがメタデータソースに接続し、コンテンツオブジェクトに関連したメタデータを検索できるようにする。多数のメタデータソースをＧＵＩに関連付けて、要求側エンティティに返送することができる。
【００５２】
図２は、コンテンツオブジェクトをメタデータのソースにリンクするためのリーダーとディレクトリシステムとの間の対話を示すフローチャートである。ブロック１１０に示すように、リーダーは、コンテンツオブジェクトからコンテンツ識別子を抽出する。次いで、コンテンツＩＤをディレクトリシステムへ転送し、そして抽出されたコンテンツＩＤがメンバーであるところのコンテンツＩＤのセットに対してＢＩを暗示的又は明示的に識別する（１１２）。ＢＩを明示的に識別する実施例は、リーダーが、それに指定された一意プロバイダー識別子を、バージョン識別子と共に供給するというものである。バージョン識別子は、識別技術のプロバイダーが異なるコンテンツＩＤセットを生成できるようにするために使用され、これは、異なるバージョンとの融通性及びＩＤプロバイダーの技術のアップグレードを可能にする。幾つかの実施例は、異なる顧客、アプリケーション、又はコンテンツオブジェクトグルーピングのための特定のＲＦＩＤ、バーコード、デジタル透かし、指紋、又はＤＲＭ技術の異なるバージョンを含む。
【００５３】
ＢＩを暗示的に実施する実施例は、ディレクトリシステムが、リーダーにより与えられるデータの幾つかの固有の属性、例えば、そのフォーマット、データ形式等に基づいて、プロバイダーのアイデンティティを決定するというものである。
【００５４】
ディレクトリシステムは、リーダーから受け取ったコンテンツＩＤ及びＢＩを使用してＧＵＩを形成する（１１４）。正確な形成の仕方は、変化してもよい。１つの解決策は、コンテンツＩＤ及びＢＩをある形態で連結することである（例えば、それらを一緒に付加して、１つのＧＵＩを生成する）。別の解決策は、コンテンツＩＤ及びＢＩの１つ以上の部分をハッシュし、それらの部分を結合して、１つのＧＵＩを生成することである。ＧＵＩのコンテンツＩＤ及びＢＩ部分を供給するプロセスに１人以上の第三者が含まれることも考えられる。例えば、指紋データベースは、コンテンツＩＤと、それに関連したＢＩとを供給してもよい。更に別の解決策は、各ＩＤがデータベース内の個別フィールドに位置され、全てのＩＤフィールドに一致するエントリーのみを使用して、ＧＵＩを登録し又は解明することである。ディレクトリシステムは、コンテンツＩＤ及びＢＩをネーミング、ナンバリング又はアドレススペースにマッピングし、これが各コンテンツオブジェクトに対するＧＵＩを与えるようにする。
【００５５】
次いで、ディレクトリシステムは、ＧＵＩに関連した１つ又は複数のメタデータソースをルックアップし（１１６）、ソースのある識別をリーダーへ返送する。一形式のソース識別はＵＲＬであるが、他の形式の識別も考えられる。例えば、ポインタ、アドレス、メタデータのデータベースへのインデックス、ソースにアクセスするためのマシンインストラクションが含まれる。ソースの識別又は位置をリーダーへ返送する解決策は、リーダーがソースとの直接接続を確立してメタデータを取得できるようにすることである。別の解決策では、ディレクトリシステムは、リーダーのアドレスを与えることによりリーダーとの接続を確立するようにソースに命令することができる。また、ディレクトリシステムは、一方では、リーダー（又はリーダーのユーザにより指定された位置）と、他方では、メタデータソースとの間の仲介者として働いてもよい。この解決策は、ディレクトリ又はそれと通信する他の何らかの仲介者を使用して、メタデータの付加的な処理を行い、その後、要求側エンティティの選択する位置において要求側エンティティにそれを供給する場合に、使用することができる。
【００５６】
図３は、メタデータディレクトリシステムを示すと共に、コンテンツＩＤを登録するための該システムとＩＤプロバイダーとの対話、及びコンテンツＩＤを解明するための該システムとリーダーとの対話を示すシステム図である。図示されたように、異なるＩＤプロバイダーシステム２００、２０２は、コンテンツオブジェクトに対応するコンテンツＩＤのセットを確立する。ＩＤプロバイダーシステムは、コンテンツＩＤのセットをオブジェクトに予め指定し、次いで、ディレクトリシステムの登録インターフェイス２０６を経てディレクトリシステムにそれらを登録することができる。又は、登録インターフェイス２０６を経て、ディレクトリシステム２０４がコンテンツＩＤを発行するように要求してもよい。
【００５７】
ディレクトリシステムは、各コンテンツオブジェクト及びそれに対応するメタデータソースＩＤ２１２に対してＧＵＩ２１０の関連性を記憶するデータベース２０８を備えており及び／又はそれと通信する。図３は、ＧＵＩの、対応するメタデータソースへの関連付けの一般化を示す。このデータベースは、ＧＵＩの態様を使用して、プロバイダー、バージョン、位置、等でセグメント化された異なるハンドラー及び／又はデータベースをインデックスするところの１つ以上の指示層で構成することができる。
【００５８】
図３は、異なるＩＤプロバイダー（例えば、プロバイダーＡ及びＢ）又は単一プロバイダーの技術の異なるバージョン（バージョンＡ及びＢ）がコンテンツＩＤの複数のセットをディレクトリシステムに登録できるという点を示す。更に、異なるセットからの複数のコンテンツＩＤは、同じコンテンツオブジェクト２１４に関連付けられてもよい。例えば、ＩＤプロバイダーＡ及びＩＤプロバイダーＢは、リーダーＡ及びＢ（２１６、２１８）を各々配布する。これらのリーダーは、プログラム、装置、又はその組み合わせでよい（装置のコンポーネントを含むか、又はウェブサービス形式の実施形態のように異なる装置を経て配布される）。この説明において、コンテンツオブジェクト２１４は、セットＡのＣＩＤ  １（２２０）及びセットＢのＣＩＤ  １（２２２）を含む。メディアプレーヤプログラム又は装置のような単一プログラム又は装置は、リーダーＡ及びＢの両方を含み、そしてユーザに共通のグラフィックユーザインターフェイスを与えることができる。或いはまた、リーダーは、ユーザ装置又はネットワークドメイン内で実行される個別のコンポーネント又はプログラムでもよい。
【００５９】
リーダー２１６、２１８は、装置、ネットワークゲートウェイ又はフィルタへの入力であるファイルオープン／コピー／転送／編集コマンドのようなオブジェクトに遭遇すると、コンテンツＩＤを抽出して、それを（暗示的又は明示的ＢＩデータと共に）ディレクトリシステムの解明インターフェイス２２４へ転送する。解明インターフェイスは、それに応答して、複数のソース（例えば、ＵＲＬ又はＵＲＬのセット）がある場合は、１つ又は複数のメタデータソースＩＤをルックアップし、それらを各リーダー（或いはリーダーによって指定されるか又はディレクトリシステムに予め登録された何らかのプログラム又は装置）へ返送する。
【００６０】
リーダー２１６、２１８は、次いで、メタデータソースＩＤを使用して、各メタデータソースプロバイダーシステム２３０、２３２との接続を確立し、それらの異なるソースからコンテンツオブジェクト２１４に関連したメタデータを得る。例えば、これらのソースは、ディレクトリシステムにより返送される位置にあるウェブサーバー上のウェブコンテンツファイルでもよい。これらのソースは、コンテンツの所有者、リテーラー、カタログ会社、製品の製造者、サービスプロバイダー、等のコンテンツ配布価値チェーンにおける異なる参加者により維持され又は制御されてもよい。メタデータの１つのソースは、コンテンツ所有者と提携したウェブコンテンツを提供するコンテンツ所有者でよく、また、メタデータの別のソースは、リテーラーと提携したウェブコンテンツ（例えば、関連娯楽コンテンツ又は商品を購入するためのｅ−コマース機会）を提供するコンテンツリテーラーでよい。
【００６１】
本明細書は、前記で要約した技術並びに本発明の付加的なシステム及び方法の実施形態を詳細に述べる。図４−８は、ここに簡単に要約するが、ＣＭＤＳと称されるシステムに関連した実施例で詳細に説明する。
【００６２】
図４は、コンテンツ識別及びルーティングシステムを概略的に示すシステム図である。
【００６３】
図５は、ユーザのコンテンツオブジェクトから抽出されたコンテンツ識別子に基づき、ルーティングシステムを使用してユーザをコンテンツプロバイダーに方向付けする使用モデルを示す図である。
【００６４】
図６は、ルーターの実施をより詳細に示す図である。
【００６５】
図７は、ディレクトリシステムの一実施形態における配布型ルーターシステムを示す図である。
【００６６】
図８は、異なるコンテンツ所有者参加者を伴うディレクトリシステムアーキテクチャーの一例で、このシステムを使用して、コンテンツ識別子を、それらが制御するメタデータソースに関連付けるところを示す図である。
【００６７】
前記で要約したように、システムは、電子的及び物理的の両オブジェクトに対して多数の異なるコンテンツ識別技術で機能する。また、アウトオブバンド及びインバンドコンテンツ識別の両方にも適用される。コンテンツオブジェクトに対するアウトオブバンドコンテンツ識別は、例えば、ファイルヘッダ及びフッタにおける補助的データ、垂直帰線消去インターバル（ＶＢＩ）挿入データ、コンテナ内のコンテンツ信号を識別するためのＤＲＭコンテナ機構、等に基づく識別を含む。
【００６８】
インバンドコンテンツ識別の幾つかの例を以下に詳細に述べる。
【００６９】
［デジタル透かし］
インバンドコンテンツ識別の１つの方法は、人間に表示又は再生するためにレンダリングされるコンテンツオブジェクトの知覚部分に埋め込まれるデジタル透かしにおいてコンテンツ識別子を搬送することである。デジタル透かしは、コンテンツ識別子のような補助的データ（例えば、メッセージ「ペイロード」）を搬送する補助的信号を含むようにコンテンツを変更することにより、コンテンツに隠され、又は「ステガノグラフィー的に埋め込まれる」。
【００７０】
デジタル透かしは、隠されたマシン読み取り可能なコードをメディアに埋め込むように物理的又は電子的メディアを変更するためのプロセスである。メディアは、埋め込まれたコードがユーザとって知覚不能であるか又はほぼ知覚不能であるが、自動検出プロセスを通して検出できるように、変更することができる。最も一般的には、デジタル透かしは、イメージ、オーディオ信号、及びビデオ信号のようなメディア信号に適用される。しかしながら、ドキュメント（例えば、スルーライン、ワード又はキャラクタシフト）、ソフトウェア、多次元グラフィックモデル、及びオブジェクトの表面テクスチャを含む他の形式のメディアオブジェクトに適用することもできる。
【００７１】
デジタル透かしシステムは、典型的に、２つの一次コンポーネントを有し、即ちホストメディア信号に透かしを埋め込むエンコーダと、透かしを含む疑いのある信号（疑わしい信号）から埋め込まれた透かしを検出し読み取るデコーダとを有する。エンコーダは、ホストメディア信号を微妙に変更することにより透かしを埋め込む。読み取りコンポーネントは、疑わしい信号を分析して、透かしが存在するかどうか検出する。透かしが情報をエンコードするアプリケーションでは、リーダーが、検出された透かしからこの情報を抽出する。
【００７２】
多数の特定の透かし技術が開発されている。読者は、この分野の文献に精通していると仮定する。知覚不能な透かしをメディア信号に埋め込み、検出するための特定の技術は、参考としてここに援用する本譲受人の米国特許第６，１２２，４０３号及び第６，６１４，９１４号に詳細に述べられている。
【００７３】
［健全なコンテンツハッシュ及び指紋生成］
インバンドコンテンツ識別の別の方法は、コンテンツ「指紋」と時々称されるコンテンツデータのハッシュである。コンテンツの歪により変化されない状態を保つために、クリッピング、時間又は幾何学的変化、圧縮、送信、等の配信チャンネルの歪によりそのまま残存することが予想されるコンテンツの特徴からハッシュが導出されるような健全な形態のハッシュが時々使用される。これら特徴は、例えば、周波数ドメイン値（例えば、健全な低周波数及び中間周波数）のベクトル、知覚的に重要な特徴（時間的、空間的又は周波数ドメイン特徴を含む）、コンテンツの統計学的情報、個別のビンへ量子化される特徴値を含み、これらは、全て、必ずしも相互に排他的ではなく、且つ一般的には、チャンネル内の予想歪（例えば、圧縮、送信、Ｄ／Ａ及びＡ／Ｄ変換）により質低下されないことを特徴とする。明瞭化のために、健全な指紋生成方法は、コンテンツ信号にある程度の変化を許すが、その歪んだ信号から計算される指紋は、依然、同じ識別子へマップされる。換言すれば、予想される質低下は、データベース内の異なる指紋へマップしたり又はマップする指紋が全くなかったりするほど、信号を実質的に変化させない。一貫性のために、コンテンツ指紋を発生する方法を指紋生成と称する。
【００７４】
コンテンツ識別に対するこの指紋生成解決策は、補助的なデータ埋め込みプロセスが不要であるという効果を有する。むしろ、リーダープロセスは、補助的な識別データを含ませるためのコンテンツオブジェクトの従来の明示的変更を伴わずにコンテンツオブジェクトから識別子を発生することができる。潜在的な欠点は、同じコンテンツプログラム（例えば、同じ音楽トラック、歌、映画）のコピーが同じ指紋を有し、同じコンテンツプログラムの異なるコピーを区別するために付加的な手段を使用する必要があることである。また、補助的な埋め込みを必要としない効果は、計算された指紋と登録された指紋とを一致させられるようにするために指紋を指紋データベースに登録して保持する必要があるという事実によって軽減される。一致が見つかると、データベースは、一致する指紋に対するコンテンツ識別子を与える。これは、潜在的に、コンテンツ識別子を発生するための付加的な処理及びネットワーク通信を追加する。
【００７５】
本アーキテクチャーの状況において理解を容易にするために、計算器、リーダー、及び指紋データベースの３つのコンポーネントを含む指紋方法について説明する。計算器は、次のことを行う。（１）リーダーと同じ（又は変化が既知の歪又は推定歪に基づく場合には同様の）アルゴリズムを使用して指紋を生成し、（２）指紋を指紋データベースに登録し、そして（３）指紋をコンテンツ識別子にリンクする。指紋は、１つの値でもよいし、或いは幾つかの又は全てのコンテンツ全体にわたりコンテンツの諸部分から取り出されたサブ指紋のセットでもよい。サブ指紋が使用されるときには、各サブ指紋又はサブ指紋のセットが同じコンテンツ識別子にリンクされる。リーダーは、指紋（例えば、サブ指紋のセット）を計算し、それらを指紋データベースへ送信し、そしてコンテンツ識別子を受け取る。
【００７６】
計算器及びリーダーに使用される指紋アルゴリズムは、知覚コンテンツ信号を使用する。指紋は、信号の統計学的に一意識別子として働くコンテンツ信号から導出される数値構造（例えば、値の配列）であり、これは、同様に聞こえるか又は見える異なるコンテンツ信号ではなく当該コンテンツ信号から指紋が導出された見込みが高いことを意味する。指紋アルゴリズムの１つのコンポーネントは、一形式のハッシュアルゴリズムである。このハッシュアルゴリズムは、指紋を生成するためにコンテンツ信号の選択された部分（例えば、最初の１０秒）に適用されてもよいし、或いは健全なハッシュのシーケンスを生成するために繰り返し適用されてもよく、この場合、このシーケンスの指定のサブセットでコンテンツを識別することができる。例えば、このシーケンスは、歌の各１／１６秒からのサブ指紋を使用し、音声を識別するのに３２個のサブ指紋（即ち、２秒の音声）を必要としてもよい。更に、精度を改善するために３秒を使用してもよい。
【００７７】
［ディレクトリシステムのアプリケーション］
上述したように、ディレクトリシステム及び方法は、電子的及び物理的の両コンテンツオブジェクト（並びにアナログ及びデジタルドメインへ／から通過するオブジェクト）に適用することができる。コンテンツオブジェクトを有する装置（コンピュータ又はワイヤレス電話ハンドセットのような）を、コンテンツオブジェクトに関するメタデータを有する別の装置へ通信しルーティングするためのネットワーク方法が、インターネットのような通信ネットワーク及びワイヤレス電話ネットワークを含む異なる形式のネットワークに適用される。オブジェクトからセルラー電話ハンドセットを経てそのメタデータにリンクするような移動電話アプリケーションの例を以下に述べる。ルーターは、例えば、セルラー電話ネットワーク、インターネット、或いはそのセルラー電話及びインターネットの両ネットワークにミラールーターが存在するときには、セルラー電話ネットワーク、インターネット、或いはそのセルラー電話及びインターネットの両方にわたって実施することもできる。また、ＷＡＰ、ＷＭＩ及び「フル」のような異なる形式のＵＲＬを、ディレクトリシステムに維持されたメタデータソース識別子として使用してもよい。
【００７８】
［メタデータルーティング及びルール］
コンテンツメタデータディレクトリシステムは、コンテンツオブジェクトに対して制御権を有する方がメタデータ応答をコンテンツに関連付けできるようにする。多くのアプリケーションでは、特定のコンテンツオブジェクトに対して異なるメタデータ応答を許すのが好都合である。メタデータ応答を制御するシステム内のインストラクション及び／又はデータを「ルール」と称する。ディレクトリシステムにおけるルールの一例は、特定のコンテンツＩＤを指定するメタデータ要求に応答して返送すべきＵＲＬ又はＵＲＬのリストを指定するデータ又はインストラクションである。ある場合には、ユーザ属性（例えば、ユーザの嗜好、セキュリティ、アカウント情報及び状態、位置、等）又はトランザクション属性のような特定のコンテクストに対して調整されるメタデータ応答をサポートするために、より複雑なルールが必要とされる。
【００７９】
これらルールの実施形態を説明するために、これらルールが作用するルーターシステムのコンポーネントを示す図で始めるのが良かろう。図９は、ルーターシステム、及びこれとコンシューマ及びコンテンツ配布参加者との関係を示すブロック図である。この図において、コンシューマ、ルーターサービスプロバイダー（１つ又は複数）、及びコンテンツ配布参加者、の少なくとも３つのエンティティが表示されている。図９は、ルーターシステムのコンポーネントがこれら参加者にわたって分布されたコンフィギュレーションを示している。コンポーネントは、装置及び／又はソフトウェアモジュールを備え、それらの例は、本明細書全体にわたって与えられる。コンポーネントの１セットは、コンシューマドメイン９００の一部分と称される。これらは、コンシューマが制御するコンポーネント、例えば、自分の装置、及びその装置に埋め込まれたソフトウェア（例えば、ワイヤレス電話、ホームネットワーク、ＰＣ、家庭用娯楽システム装置、等）である。別のセットは、ルーターシステム９０２と称される。これらは、コンテンツ識別及び関連コンテクストからメタデータ応答へのルーティング、並びに関連ネットワークサービス、例えば、メタデータトラフィック監視及び応答アグレゲーターに含まれるコンポーネントである。最後のセットは、コンテンツ配布参加者９０４と称される。これらは、コンテンツオブジェクトを与え、それらの配布を管理し、且つメタデータコンテンツ配布を供給及び／又は制御する参加者である。
【００８０】
コンテンツ配布参加者９０４は、コンテンツ所有者９０６及びコンテンツ配布者９０８を含むが、これらに限定されない。これらの所有者は、娯楽コンテンツの慣習的なプロバイダーを含むだけでなく、他の製品及びサービスを市場に出すのに使用される広告を含むコンテンツを提供するプロバイダーも含む。これら参加者は、それらのコンテンツオブジェクト９１０をルーターシステム９０２に登録し、そしてそれらをコンシューマ９１２へ配布する。登録コンポーネント９１４を通して、参加者９０４は、本明細書の種々の実施形態で述べるように、それらのコンテンツオブジェクトをルーティングシステムに登録する。特に、参加者は、コンテンツ識別子と、これら識別子に対するメタデータ要求への応答を与えるための関連ルールとを提供する。これらコンテンツ識別子及びルールは、ＩＤレジストリーデータベース９１４及びルールデータベース９１８に各々記憶される。これらのデータベースは、１つのデータベースに一体化されてもよいし、或いはコンテンツオブジェクトを、メタデータ応答を支配する対応ルールに関連付けるキー又は同様の識別子（例えば、一意識別子）を伴う個別のデータベースで実施されてもよい。
【００８１】
ルーターシステムは、コンシューマが、コンテンツ識別子を抽出するためのリーダーと、メタデータ要求をパッケージングしてルーターシステムへ送信するための関連モジュールとを有する限り、コンテンツオブジェクトがその配布チェーンを進行するときに、コンシューマがメタデータ応答を要求できるようにする。図９は、メタデータ要求をコンシューマドメインからの「ＩＤ表示付き要求」として示している。この点において「コンシューマドメイン」は、コンテンツのリテールユーザのみに限定されるものではない。むしろ、これは、コンテンツに対するメタデータ、コンテンツの購入者／被免許者へのアクセスを求めるコンテンツ所有者又は配布者を表すか、或いは娯楽、情報又は商取引のためのコンテンツを受け取って消費する顧客を表すかに関わらず、ルーターシステムの実質上いかなるユーザも含む。実際に、ルールは、ルーターシステムの種々の形式のコンシューマの間での異なるレベルのアクセスを容易にする上で助けとなる。
【００８２】
ルーターシステムは、ＩＤリゾルバー９２０を備え、これは、ＩＤ表示付き要求を受け取り、そしてコンテンツＩＤと、要求側装置により供給される関連識別システム情報とに基づいて、コンテンツオブジェクトに対するＩＤを決定する。コンテンツ識別子及びプロバイダー識別子を、コンテンツオブジェクトに対する一意識別子へマップするための検討は、このようなプロセスの一例である。コンテンツ識別機構を統合するこの解決策は、ルーティングシステムがコンテンツ識別のための一形式の共通語として働いて、異種のコンテンツネーミング機構を一緒に縫合できるようにする。
【００８３】
コンテンツＩＤは、それに対して登録された１つ以上のメタデータ応答を有してもよい。ルールプロセッサ９２２は、コンテンツオブジェクトに関連したルールを実行し（例えば、コンテンツＩＤを経て）、要求において供給される情報、要求側ユーザに関する情報（ユーザ装置の能力、接続性、等を含む）、及び／又はルーティングシステムに保持された情報、例えば、コンテンツオブジェクトに対するトランザクションデータ、又はコンテンツオブジェクトを発信するところのクラス（コンテンツのジャンル、コンテンツのジャンルに対するコンシューマの緊密なグループ、等で定義されたクラス）に基づいて、メタデータ応答を決定する。
【００８４】
ＩＤを解明し、コンテンツオブジェクトに対するルールを実行するのに加えて、ルーティングシステムは、付加的なサービスを提供することもできる。図９のルーターシステムは、使用統計学的情報をログして使用レポートを発生するトラフィックモニタ９２４を備えている。この使用監視及び報告の実施形態は、ＣＭＤＳの実施形態を参照して以下に説明する。
【００８５】
また、ルールプロセッサは、コンテンツオブジェクトの動的メタデータに基づいてルールを実行することもできる。動的メタデータとは、時間と共に変化するメタデータを指す。このような動的メタデータの一例は、コンテンツオブジェクトの使用データである。メタデータ応答を支配するルールは、使用データに依存したものとすることができる。例えば、メタデータの対する要求の数がスレッシュホールドを越える場合には、メタデータ応答は、それに応じたものとされる。例えば、特定オブジェクトにおける関心レベルが時間と共に高くなるにつれて、関連コンテンツ及び商取引機会に関する情報を含むより多くのメタデータデータが与えられる。応答は、メタデータ要求者から導出されるユーザ情報に基づいて調整され、オブジェクトに対するメタデータを要求しているユーザのクラスの共通の属性に対して応答を調整することができる。使用データが時間と共に追跡されるにつれて、ユーザの共通の属性、コンテンツ、又はコンテンツメタデータのパターンが出現する。これは、システムが、コンテンツオブジェクトに対するメタデータ応答を識別して動的に追加できるようにする。例えば、コンテンツオブジェクトの関心が高まるにつれて、ルーティングシステムは、関連コンテンツオブジェクト、並びに製品及びサービスへの付加的なリンクを、コンテンツオブジェクトの緊密なグループ又はオブジェクトのクラスに追加する。緊密なグループは、例えば、コンテンツオブジェクトにおける共通の嗜好又は関心をもつグループとして定義することができる。
【００８６】
更に別のサービスとして、ルーティングシステムは、メタデータ応答のメタデータレポジトリー及びアグレゲーターとして働くこともできる。図９は、この機能のサポートにおいてメタデータ応答を与えそしてコンテンツオブジェクトに対するメタデータを記憶する応答アグレゲーター９２６を含む。幾つかの実施形態では、ルーティングシステムは、メタデータ要求をコンテンツ所有者／配布者に単に再方向付けし、これが、次いで、要求側コンシューマにメタデータを与える。この解決策を実施する仕方は別にもある。ＣＭＤＳ実施形態で述べられたように、一方が、他方により制御されるメタデータソースのためのＵＲＬ又はＵＲＬのセットをコンシューマへ返送する。次いで、コンシューマの装置は（例えば、ウェブブラウザ又は同様のアプリケーションプログラムを経て）メタデータに対する要求をこのＵＲＬにおけるメタデータレポジトリーへ送信する。別の解決策は、コンテンツ所有者のメタデータレポジトリーに対してプロキシーサーバーとして働くことである。この場合には、ルーティングシステムは、ＩＤの解明及びルール実行（ルールが存在すれば）に基づいてメタデータソースのＵＲＬを決定し、そしてこのＵＲＬにおけるメタデータレポジトリーにメタデータ要求を発行する。複数のＵＲＬが含まれる場合には、その各への問合せを行う。ルーティングサービスは、メタデータレポジトリーからのメタデータ応答を総計し、そして総計されたメタデータを要求側コンシューマへ返送する。別の解決策は、ルーティングシステムがメタデータ要求をコンシューマからメタデータレポジトリーのＵＲＬへ転送し、これが、次いで、要求側コンシューマへメタデータで直接応答することである。要約すれば、あるケースでは、ブロック９３０に示すように、コンテンツ所有者／配布者がメタデータ応答を制御し、他のケースでは、ルーティングシステムが応答を制御する。
【００８７】
追加の機能として、ルーティングサービスがメタデータレポジトリーとして働く。ルールがそれを指令するか、ユーザがそれを要求するか、又は他のメタデータソースが使用できないケースでは、ルーティングシステムは、その制御内でメタデータレポジトリーのＵＲＬを識別し、メタデータ応答を応答アグレゲーターでパッケージし、そしてメタデータを要求側コンシューマへ返送する。
【００８８】
メタデータレポジトリーとして働く能力は、ルーティングシステムが付加的なネットワークサービスを提供できるようにする。１つのこのようなサービスは、推薦、嗜好、及びメタデータレポジトリー内のコンテンツオブジェクトに関する他の関連情報をポスティングすることにより、コンテンツオブジェクトに対するメタデータの生成においてユーザが協力できるようにすることである。これは、ルーティングシステムによって識別及び管理される緊密なグループに付加次元を追加する。特に、これらグループのメンバーを、最も関心のあるコンテンツオブジェクトに対するメタデータに対して能動的な貢献者にすることができる。
【００８９】
ルーティングシステムについて説明したが、ルールの実施形態を以下に詳細に述べる。コンテンツオブジェクトに対して複数の異なるルールをサポートする１つの解決策は、オブジェクトを制御する１人以上の参加者が、そのオブジェクトに関連した異なるコンテンツＩＤをＩＤレジストリに登録することができ、その各々が、関連するＵＲＬ又はＵＲＬのセットをレジストリーデータベースに有するようにすることである。例えば、各コンテンツＩＤは、各参加者のＵＲＬを参照する（例えば、コンテンツ所有者、配布者、リテーラーが、各々、データベースにおいて対応するＵＲＬに異なるメタデータソースを準備する）。
【００９０】
この解決策では、ルーターシステムにおいて更に別のルールが実施され及び／又はコンシューマ装置においてクライアントプログラムが実行されることになる。例えば、プロセスは、コンシューマ装置の１つ又は複数のクライアントリーダープログラムがコンテンツオブジェクトから複数のＣＩＤを抽出して、それらをルーターシステムへ転送することで開始される。ルーターシステムは、次いで、各ＣＩＤのための対応するＵＲＬ又はＵＲＬリストをルックアップする。次いで、ルーターは、どのＣＩＤがプライオリティを有するかを支配するルールを実行し、プライオリティを有するＣＩＤに関連したＵＲＬのサブセットを返送する。或いはまた、ルーターは、要求をプライオリティ決めするのを控え、各コンテンツＩＤに関連した全てのＵＲＬをコンシューマ装置のクライアントリーダープログラムへ返送する。クライアントプログラムは、各ＵＲＬへのハイパーリンクをもつウェブページを表示するか、又はどのＵＲＬ又はＵＲＬのセットがプライオリティを有するか選択するためのルールを実行し、次いで、最も高いプライオリティをもつＵＲＬへ再方向付けする（例えば、メタデータ要求を送信する）。
【００９１】
単一のＣＩＤが多数の異なる参加者（サーチエンジンプロバイダー、メタデータアグレゲーター、ｉＴｕｎｅのような配布者、レコードラベル、広告主、等）からのメタデータ応答に関連付けられてもよい。このケースでは、ＣＩＤの登録者は、そのＣＩＤに対するメタデータ応答の各々に対応するＵＲＬ又はＵＲＬリストを指定する。更に、その登録者は、異なるメタデータ応答がトリガーされる条件を支配するルールを指定する。登録プロセスは、ネットワークを経てアクセスできるグラフィックユーザインターフェイス、例えば、登録者がメタデータ応答ごとに次のものをリストできるようにするウェブインターフェイスによって容易にされる。
１．希望のメタデータ応答に対するＵＲＬ又はＵＲＬのセット、
２．ルーティングシステムがメタデータ応答を選択するようにさせる条件
【００９２】
条件は、ルーティングトランザクションの属性の関数である。これらの属性は、ユーザ属性及び非ユーザ属性の２つのカテゴリーに分けられる。ユーザ属性は、メタデータ要求で与えられるデータにおいて、及び／又はユーザからの要求の経歴に基づいてルーターにより導出されるデータにおいて、ルーターにより、ユーザ登録プロセスを通して得られる。ユーザは、登録を通して又はメタデータ要求においてメタデータ嗜好を指定することができる。嗜好は、コンテンツジャンルの好き／嫌い、製品／サービス広告の好き／嫌い、コンテンツフォーマットの嗜好、メディアプレーヤの形式及びメディアプレーヤの設定、装置能力、等の嗜好を含むことができる。非ユーザ属性は、システムにより導出されるトランザクションに関する属性、例えば、時刻、地理的テリトリー、コンテンツオブジェクトと同じジャンルにおける１つ又は複数のコンテンツオブジェクトに関するトランザクションの経歴、オブジェクトの形式、等を含む。例えば、ルーターの使用データは、コンテンツオブジェクトの人気、オブジェクトのためのメタデータを要求した他の者の嗜好に対する相関性、等に関する情報を与える。幾つかのアプリケーションでは、リーダーは、オブジェクト形式及びフォーマットのようなオブジェクトに関する情報を、抽出されたコンテンツＩＤと共にパッケージする。これは、ユーザが自分の装置でレンダリングする能力を有するところのオブジェクト形式及びフォーマットに対してメタデータ応答を調整できるようにする。
【００９３】
典型的なルール登録インターフェイスは、登録者がルーティングトランザクションの属性に基づいて異なるＵＲＬを選択できるようにする。例えば、ルール１は、次のように指令する。アーチストの嗜好＝真、アカウント状態＝アクティブな加入者、及び広告トレランス＝低であるときに、ＵＲＬ１を使用する。
【００９４】
ルールプロセッサは、メタデータ要求及び応答経路に沿った１つ以上の異なる位置内で実施し且つ実行することができる。これらの位置を列挙する前に、ＣＭＤＳ実施形態における位置の概要を検討する。第１の位置は、図９に示すコンシューマドメイン内の要求側クライアントである。その次は、ルール処理に貢献できる異なるコンポーネントをそれ自身が有するルーターシステムである。簡単化のために、図９は、ルールプロセッサを単一ブロックとして示すが、ルール処理機能が分散されてもよい。経路に沿った次の位置は、要求側クライアントへ戻るか、又は要求がルーターにより再方向付けされたメタデータソースへ戻るかのいずれかである。
【００９５】
コンテンツ識別及びメタデータ要求において、次のものを制御するためのルールが実行される。
１．どんな形式のＣＩＤをクライアントが抽出するか（クライアントは、ＣＩＤ検索、ＤＷＭ  ＣＩＤ検索又はヘッダ／フッタＣＩＤ検索に基づいて指紋をトリガーしようとしているか？）
２．どんなクライアントがルーターへ送信するか（１つ又は複数のＣＩＤ）
【００９６】
ルーターにおいて、ルールプロセッサは、次のものを制御するための１つ又は複数のルールを実行する。
１．１つのコンテンツオブジェクトに対して複数のＣＩＤが設けられる場合に、どのＣＩＤがプライオリティを有するか？
２．どのＵＲＬをルーターがクライアントに返送するか（例えば、ＣＩＤごとに単一／複数のＵＲＬか、又は１つのＣＩＤが優位を占めるか？）
３．コンテンツオブジェクトの登録者は、それが制御する装置のＵＲＬへ要求を再方向付けすることを要求し、次いで、その装置がメタデータ応答をクライアントへ与えるようにするかどうか
【００９７】
クライアントにおいて、上述したルーター又は他の装置から応答があったときに、次のものを制御するためのルールが実行される。
１．どんなクライアントが表示するか（プライオリティ決めされたＵＲＬか否か？）
２．ルーターにより返送されたパケットに応答してどんなクライアントがウェブサーバーに送信するか
【００９８】
クライアントにおいて、コンテンツを消費又は管理するのに使用されるクライアントプログラムには、１つ又は幾つかの形式のコンテンツＩＤに対するリーダーが装備される。このクライアントは、どんなＩＤがルーターへ送信されるか制御し、従って、どんなエンティティがリンクされるか制御する。
【００９９】
或いはまた、自分自身のルールに基づいて各々独立して動作する複数のリーダーがある。
【０１００】
或いはまた、ルーターは、対応するＣＩＤに関連したメタデータソースに対する全てのＵＲＬをクライアントへ返送し、そしてクライアントは、どれを使用すべきか判断する。また、クライアントは、ユーザが位置に基づくサービスを受けたいか又はそれに対して支払いしたかに基づいて、どんな形式のコンテクストデータ、例えば、ＧＰＳ情報を、メタデータソースに与えるか決定することもできる。
【０１０１】
ユーザのプライバシーを尊重するために、ユーザの嗜好は、クライアントのみに維持することができる。クライアントは、ユーザの嗜好及び属性がルーター及び／又はメタデータソース／レポジトリーへ転送されるかどうか及びいつ転送されるかに対して制御を維持する。あるケースでは、それらが全く与えられず、クライアントは、ユーザの嗜好に基づいて複数のＵＲＬからメタデータ応答を総計し調整する。他のケースでは、クライアントは、メタデータソースに対する嗜好を、そのＵＲＬを受け取った後に直接ルーターへ転送する。この場合、ルーターは、ユーザの嗜好にアクセスしない。
【０１０２】
ルーターにおいて、ルーターは、クライアントからのコンテクスト又は他の情報に基づいて、ＵＲＬに位置したメタデータソースへクライアントをどのように再方向付けするか決定する。
【０１０３】
ＵＲＬのメタデータソースは、異なる形式のメタデータ又はリンクを要求側クライアントへ送信し、これは、クライアントのユーザインターフェイスに提示されるメタデータ／リンクの中からクライアント又はユーザがピックアップできるようにする。
【０１０４】
上述したように、メタデータ応答は、ユーザの嗜好に基づいてプライオリティ決めすることができる。このような実施形態では、クライアントは、ユーザの嗜好を得又は学習し、そしてそれに従ってシステムにより返送されるメタデータへのリンクをプライオリティ決めするようにプログラムされる。
【０１０５】
別の実施形態では、ルーターシステムは、ユーザを管理するための付加的なサービスを提供し、これは、例えば、ユーザを認証し、ユーザのアカウントを管理することを含む。これは、ユーザにより供給される情報の明示的管理でもよいし、又はユーザにより与えられる承諾に基づくユーザトランザクションの管理でもよい。いずれの場合にも、ルーターは、コンテンツを消費するためのユーザの嗜好に関して収集した情報に基づいてユーザの分類を導出する。一実施形態では、ルーターシステムは、製品及びサービスに対して支払いするユーザの意志に基づいてルーティングトランザクションを分類する。プレミアムコンテンツに対して支払おうとする者は、このプレミアムコンテンツにアクセスするための機会を伴うメタデータ応答を得るが、支払おうとしない者は、例えば、広告により補助される無料のメタデータ応答を得る。更に、ルーターがユーザ及びユーザのアカウント状態を認証した場合には、ユーザのアイデンティティに基づいて初期化される安全な電子商取引サイトであるＵＲＬへユーザを再方向付けする。これは、ルーティングシステムが、認証処理を取り扱うようにメタデータソースに要求することなく、ユーザを電子的トランザクションに直接リンクできるようにする。
【０１０６】
ルーターにおける認証サービスの１つの特定例は、クライアントが予め認証される状態において、デジタルライツマネージメント（ＤＲＭ）サーバー又は他のｅ−コマースサーバーへ直接リンクできるようにすることである。クライアント及びルーターは、プライベート及び／又は暗号化データフィールドを通して、又はパブリック及びプライベートフィールドの組合せを通して、電子的購入を完了するのに必要な認証情報を与え、但し、プライベートは、あるエンティティでしか読み取りできない。
【０１０７】
ルーターの別のサービスは、ネットワークを経て共有されるコンテンツオブジェクトのフローを追跡することである。デジタル証明書、又はユーザの他の識別情報を使用して、コンテンツ識別子により独特に識別される特定のコンテンツオブジェクトに対するメタデータを要求する異なるユーザを検出する。コンテンツＩＤ及びユーザ証明書によるコンテンツオブジェクトフローのこの追跡は、コンテンツオブジェクトがユーザのネットワークをどのように流れるかに関するデータをコンテンツ所有者に与える。これは、コンテンツに対する緊密なグループを識別するための別の手段を与え、緊密なグループの嗜好に対するコンテンツ及びメタデータの配布を調整する。このトレース方法は、新規な且つ異なるユーザによりコンテンツオブジェクトが処理されるときにそれらをトレースする。メタデータに対する要求が受け取られるたびに、ルーターは、要求をログし、そして要求に対するユーザ識別がもし得られれば、それも記録する。ルーターは、このログを分析して、新たなユーザを通るコンテンツオブジェクトの経路を識別する。
【０１０８】
前記実施例で実証されたように、ルーターにおいて実施されて返送すべきＵＲＬを指定するマクロルール、及びクライアントにおいて実施されてクライアントがどのようにそれらＵＲＬへ提示してリンクするか更に制御するマクロルールを含む、システムにわたって分布されたルールのハイアラーキーにより、ルーターは、メタデータ応答を支配することができる。
【０１０９】
マクロルールは、例えば、異なる形式のメタデータソースへアクセスできるようにするためにユーザの認証をどのように行うかを支配するルール（例えば、アイデンティティの三角形の使用、即ちユーザは何を知っているか−パスワード、ユーザは何を有しているか−アクセストークン、ＩＤカード、及びユーザは何であるか−生物測定ログイン及びユーザ検証）を含む。認証のレベルは、与えられるメタデータの性質を指令する（どんなリンク、メタデータ、等が与えられるか）。また、認証のレベルは、購入限界及び使用権利（再配布又は他のユーザとの共有の権利）も指令する。
【０１１０】
ルーターシステムの付加的なサービスは、メタデータ要求としてルーターへ送信されるデータパケットにおけるプライベート及びパブリックフィールドを取り扱うためのサポートである。例えば、コンシューマドメインにおけるクライアント装置は、パブリック及びプライベートフィールドを送信する（パブリックフィールドは、一般的に読み取り可能であり、プライベートフィールドは、クライアントによってパッケージされそしておそらく暗号化され、ルーターがリンクする安全なトランザクションサーバーのような許可された装置のみによって読み取られるように意図される）。ルーターは、パブリックフィールドを、例えば、メタデータ応答のためのＵＲＬを決定するルールに対するデータ入力として使用する。メタデータソースは、プライベートフィールドのデータを解読し、それを使用して、調整された情報をユーザへ与えながら、ユーザ情報のプライバシー及び安全性を保持する。
【０１１１】
また、あるシステムのルールは、メタデータトランザクションに対して割り当てられるネットワークリソースの量を支配する。特に、メタデータソースとクライアントとの間にオープンされるソケット、データパイプ、又はチャンネルのサイズは、クライアントの認証レベル及びユーザアカウント状態（例えば、支払いの意志及び能力を指示する）の関数である。
【０１１２】
ネットワークインフラストラクチャーを通してルールを伝播する仕方は、多数ある。一実施形態では、コンテンツオブジェクト（例えば、ファイルヘッダ／フッタ、暗号化コンテナ、デジタル透かし、等）におけるコンテンツ補助チャンネルを通してクライアントにルールがプッシュされる。別の実施形態では、マイクロソフト社からのウインドウズメディア及びアップルコンピュータ社からのｉＴｕｎｅｓのようなメディアプレーヤ等のメディア消費プログラムでルールが配布される。
【０１１３】
各コンポーネント（クライアント、ルーター及びメタデータソース）は、ユーザに関して何を学んだかに基づいて確立されるルールのそれ自身のセットを実行する。
【０１１４】
上述したように、ルールへの入力は、ユーザ属性及び非ユーザ属性を含み、これは、ユーザ人口統計学情報、装置プラットホーム、年齢、地理（ＧＰＳ）、時間、コンテンツの形式に対する嗜好を指示するユーザサーチ経歴に基づいてコンテンツサーチに対する結果をプライオリティ決めするサーチエンジンメトリックを含むが、これらに限定されない。
【０１１５】
ルールへの入力は、ユーザの振舞いから導出される嗜好、コンテンツ消費経歴、最も頻繁にアクセスされるコンテンツ、等を含む。
【０１１６】
別の入力は、ユーザ又はユーザのレンダリング装置のコンテンツ形式の嗜好でコンテンツに狙いを定められるようにするコンテンツ形式を含む。また、ルールは、クライアント装置がオンラインモードで動作するかオフラインモードで動作するかに基づいて異なるメタデータ応答を指定する。オフラインモードは、ローカルメタデータレポジトリーとして働くメタデータのキャッシュにおけるメタデータソースへメタデータ要求を再方向付けさせるようにクライアントに命令する。
【０１１７】
ルーターシステムは、収入発生データサービスのための多数の機会を与える。１つのこのようなサービスは、メタデータを配布するために収集された料金を、使用データの関数としてコンテンツ所有者と分配する収入分配分担モデルである。このサービスの実施形態では、ルーターは、コンテンツオブジェクトのためのメタデータ要求に対応する使用データを追跡し、これらコンテンツオブジェクトに対する使用データを用いて、コンテンツ所有者及び配布者の間で収入分配を決定する。ルーターは、使用データを追跡し、この使用データを用いて、コンテンツオブジェクトのためのメタデータ要求の配布に依存するメトリックに基づいてその収集した料金をアーチストに配分するというライセンスのもとで、コンテンツを生成したアーチストがその収集した料金の分け前をどのように得るか決定する。収入分配の付加的なモデルは、料金に基づくもので、メタデータ応答に対してコンシューマにより支払われた料金の一部分がコンテンツ所有者に配分される。
【０１１８】
ルーターの別のサービスは、監査機能である。１つのこのような監査は、登録中に供給されるＵＲＬの有効性をチェックすることである。ルーターは、データベースのＵＲＬを周期的にチェックし、それらが現在のもので、有効であり、応答し、等々であることを確かめる。また、ルーターは、メタデータ要求のトレンドの分析も行い、これは、メタデータソースがメタデータ要求ワークロードを予想して、その予想されるワークロードに基づきより多くのリソースを割り当ててメタデータに応対できるようにする。
【０１１９】
ルーターそれ自体が配布され、それ自身のインスタンスがネットワークにわたって鏡像のようにされる。ルーターは、ルーティングサービスのためのその後の要求に対して多数のＵＲＬの中でどれを使用すべきかクライアントに指定する。
【０１２０】
ルーターの別のサービスは、トランザクションごとにコンテンツオブジェクトを識別するのに使用されるコンテンツ識別の形式を追跡することである。これは、ルーターが、異なるコンテンツＩＤのレイヤを含むその後のコンテンツラベリングのためにコンテンツにフラグを立てられるようにする。例えば、指紋を使用して識別されるコンテンツオブジェクトは、デジタル透かしを埋め込むためにフラグが立てられる。デジタル透かしは、同じコンテンツのコピー間を区別することにより指紋より微細粒度の識別を与える。次いで、透かしにおけるコンテンツＩＤが登録され、コンテンツオブジェクトの特定コピーに対して調整されたメタデータ応答に関連付けられる。
【０１２１】
［ユーザ発生メタデータ及びルールについての更なる説明］
以上、ユーザ発生メタデータをメタデータルーティングシステムにどのように合体するかを説明した。ルーティングシステムは、ユーザ生成メタデータに対してそれ自身のメタデータレポジトリーを合体し、他の者により維持されるユーザ発生メタデータレポジトリーへリンクし、そして両形式のメタデータソースの組合せを一体化するという融通性を有している。メタデータプロバイダーがコンテンツとメタデータソースとの間のリンクを登録するのを許すインターフェイスを確立することにより、ルーティングシステムは、異なるメタデータソースを１つの統合されたメタデータサービスへ一体化するという融通性を有する。例えば、ルーティングシステムは、コンテンツの断片（例えば、歌、ＴＶ又はラジオ番組、映画、ポッドキャスト、広告、等）に対する識別子（１つ又は複数）と、ルーティングシステムドメインの内外のユーザ発生メタデータを含むメタデータのソースとの間のリンクを維持する。データベースは、特に、コンテンツの断片の一意識別子と、そのコンテンツの断片に対するユーザ発生メタデータの関連ＵＲＬとを記憶する。
【０１２２】
特に、ルーティングシステムは、インターネット上の異なるユーザ発生メタデータサイトに維持されたユーザ発生メタデータに特にリンクすることができる。ユーザ発生メタデータに対して実施されたシステムを有するウェブサイトは、例えば、Ｙａｈｏｏによって運営されるウェブサービスを提供するＦｌｉｃｋｒ及びＤｅｌ．ｉｃｉｏ．ｕｓを含む。これらのシステムは、ユーザが「タグ」と称するメタデータをコンテンツの断片に適用できるようにする。特に、Ｆｌｉｃｋｒは、ユーザが、Ｆｉｃｋｒシステムの環境内でイメージをアップロードしそしてイメージにタグを追加するのを許す。しかしながら、タグはコンテンツに持続的にリンクされず、それ故、コンテンツがＦｌｉｃｋｒシステム（例えば、Ｆｌｉｃｋｒサーバー又は接続されたクライアント装置）の境界の外へ移動すると、タグは容易に失われる。ルーティングシステムは、オブジェクトが異なるドメイン、装置及びネットワークにわたって配布されても、コンテンツオブジェクトとそのメタデータとの間のリンクを持続的に維持するための手段を備えている。更に、コンテンツオブジェクトを、多数の異なるユーザ発生メタデータサイトに持続的にリンクすることも許す。
【０１２３】
異なるメタデータソースにわたって持続的にリンクするこれらの能力をルールベースの処理に組み合わせたときには、システムは、メタデータソースの広い配列にわたるメタデータ要求のより精巧な配列を満足する。コンテンツの各断片は、それ自身のノード又はポータルが、異種の配布方法、ネットワーク、コンテンツフォーマット及び装置にわたって異種のメタデータソースと相互接続された状態になる。更に、システムにおけるルール処理は、ユーザの嗜好に基づいてメタデータをフィルタリングする。
【０１２４】
多くのアプリケーションでは、ユーザが、コンテンツ所有者又は配布者からのオリジナルメタデータよりもユーザコミュニティ発生のメタデータを好むことが予想される。その一例は、親制御のためにコンテンツにコンテンツ格付けを指定するユーザ発生メタデータである。特に、ユーザは、自分がメンバーである信頼のあるコミュニティにより適用されたコンテンツ格付けを、業界グループにより適用された格付けより信頼できる。今日、ユーザが、信頼性あるコンテンツのプロバイダーのドメイン内（例えば、ウェブサービスへ接続されたセッション内）に留まる限り、ユーザは、そのドメイン内のコンテンツに関連したメタデータの利点を取り入れることができる。しかしながら、コンテンツがドメインの外側へ移動するときには（例えば、ドメインからのプロトコル又はメタデータがオフラインになるか、トランスコード化又はプレイされるか、又は友人へｅ−メールされたことを尊重もせず又は理解もしない装置に記憶されるときには）、メタデータを再関連付けしてユーザの嗜好を適用する機構が必要となる。ルーティングシステムは、ある環境において、業界のコンテンツ格付けではなくユーザグループのメタデータのコンテンツ格付けを使用すべきであることを指定するユーザのルールでユーザがメタデータを要求するのを許すことにより、この再関連付け及びユーザ嗜好の強制をサポートする。
【０１２５】
格付けを適用するためのシステムの典型的な使用シナリオは、次の通りである。即ち、ユーザがコンテンツに遭遇し（無数のやり方のいずれかで：例えば、友人から受け取り、社交的ネットワークサイトからダウンロードし、生放送から記録し、アーカイブをサーチし）、ユーザの装置がリーダーを合体するアプリケーションを備え、リーダーがコンテンツからコンテンツＩＤを抽出し（或いは、ユーザがコンテンツを選択し、これが、リモートリーダーへのコンテンツの送信をトリガーし、リモートリーダーが同じことを行い）、リーダーがコンテンツＩＤをユーザの嗜好と共にルーティングシステムへ転送し、ルーティングシステムがその関連ＵＲＬにより指定されたリンクされたサイトから関連メタデータを抽出し、ルーティングシステムが、コンテンツに適用できるルールであってユーザの嗜好に基づくものを含むルールを適用すると共に、格付けをユーザに通知するメタデータ応答をユーザへ返送し、及び／又はリーダーが、コンテンツからのプレイを制御することにより格付けを自動的に強制する。
【０１２６】
これらのメタデータソースは、上述したように、サーチ、ＲＳＳフィード及びマッシュアップからの動的に発生されたメタデータに基づく動的メタデータソースでよい。ＵＲＬは、物理的装置の単なるＩＰアドレス以上のものを識別し、そしてＳｅｃｏｎｄ  Ｌｉｋｅのようなバーチャル環境において動的なメタデータソースへ拡張する（Ｓｅｃｏｎｄ  ＬｉｆｅのためのプロトコルにおけるＵＲＬは、ＳＬＴＰプロトコルと首尾一貫したものである）。
【０１２７】
［連合コンテンツアイデンティティ］
異種のドメインを横切って（例えば、コンテンツ配布者、コンテンツ所有者、社交的ネットワークサイト、Ｆｌｉｃｋｒ及びｄｅｌ．ｉｃｉｏ．ｕｓのようなメタデータタグ付けサイト、のメタデータサービスのような異なるエンティティのデータベースの周りに組み立てられたセキュリティ壁を横切って）ユーザアイデンティティを確立するためのユーザに馴染み易く且つ相互運用可能なフレームワークの需要に応じて連合アイデンティティのコンセプトが出現した。ユーザの観点から簡単に述べると、「連合アイデンティティ」とは、ユーザが、各々、それらの一意安全なログイン手順で、また、単一のログインで、異種のデータサービスにアクセスできるようにするアイデンティティ管理フレームワークである。以下に述べるように、ルーティングシステムの実施形態は、ＳＡＭＬ及びＷＳ−Ｔｒｕｓｔのような連合アイデンティティ技術をレバレッジして、メタデータのプロバイダー及びコンシューマの両方を含むルーティングシステムのユーザに対してユーザアイデンティティを確立して強制する。
【０１２８】
コンテンツ識別とメタデータプロトコルとの差異は、連合コンテンツアイデンティティの機構に対して同様の需要を生成する。ルーティングシステムは、異種のコンテンツ識別技術（例えば、デジタル透かし、コンテンツ指紋、暗号化されないか暗号コンテナの一部分であるかのファイルのヘッダ）並びにコンテンツ識別子のための非適合プロトコルを統合するフレームワークを生成することにより需要を満足する。更に、これは、異種のメタデータソース及び異なるメタデータフォーマットも統合する。手短に言えば、クロスプラットホームコンテンツアイデンティティ及びメタデータサービスを提供する。これらの能力をレバレッジするための典型的な使用例は、次の通りである。ユーザは、特定の歌に関連した特定のコンサートツアーに関する全てのメタデータを見出すことを望み、ユーザは、その歌に対するユーザの嗜好「コンサートツアー」及び「年度＝２００５」を提示し、リーダーは、その歌から１つ以上のコンテンツ識別子を抽出し、それらをユーザの嗜好でパッケージし、そしてルーティングシステムへ要求を送信し、ルーティングシステムは、リーダーからのＩＤプロバイダー及びコンテンツＩＤを知った上でその歌に対する連合コンテンツアイデンティティを確立し、ルーティングシステムは、このコンテンツアイデンティティを使用して、リンクされたメタデータソースをそのデータベースにおいて見出し（例えば、これらメタデータソースのＵＲＬを得）、ルーティングシステムは、異なるドメインからのこれらＵＲＬからのメタデータ応答を総計し、ルーティングシステムは、ユーザの嗜好を適用し、そしてコンサートツアー及び年度２００５に関するメタデータ応答をユーザへ返送する。ユーザは、コンテンツを識別したり又は異種のメタデータソースへのアクセスを得たりする細部に自身で関与する必要はない。
【０１２９】
［メタデータシステム、メタデータのマッシュアップ及びメタデータ使用統計情報のためのパブリックインターフェイス］
ルーティングシステムは、異種のコンテンツ識別及びメタデータシステムを横切ってコンテンツをメタデータに関連付けるための相互運用可能なシステムを確立する。また、このようにするとき、コンテンツの起点及び消費の異種のドメインを横切ってコンテンツ及びメタデータの消費を監視するためのメカニズムも提供する。ユーザ発生メタデータをサポートすることは、更に、ユーザがおそらく高く評価するか又はコンテンツそれ自体よりも評価する新規なメタデータソースを可能にする。これは、メタデータ使用及びコンテンツ使用を分析しそしてコンテンツにリンクされた付加的なメタデータとして情報を利用できるようにするシステムについて特に言えることである。というのは、ユーザに特に関心の高いコンテンツをユーザがサーチする能力を容易にするからである。認めざるを得ない形式のメタデータの１つは、あるグループ内の人気（例えば、テイストメーカー、緊密なグループ、コンテンツの隙間ジャンル、等によって定義される人気）によってコンテンツを識別するメタデータである。
【０１３０】
認めざるを得ないメタデータを識別するこの重要な機能に鑑み、インターフェイスには相応値があって、このインターフェイスは、メタデータ及びメタデータ統計情報へのプログラムアクセスを確立することによりこの値を効率的にアンロックする。メタデータ発生のための単一のシステム内には、その特定のシステムのためのプログラムインターフェイスが設けられる。しかしながら、本明細書に述べるルーティングシステムの実施形態は、異種のコンテンツ識別技術及びメタデータソースを横切るプログラムインターフェイスを備え、更に、それらの異種のメタデータソースを横切って収集されて、種々のコンテンツ識別技術を通して個々のコンテンツアイテムへリンクして戻されるメタデータ使用データに対するプログラムインターフェイスも備えている。
【０１３１】
ルーティングシステムがレバレッジするプログラム可能なインターフェイス技術は、例えば、ウェブ２．０、プログラマブルウェブ、及びセマンティックウェブプログラミング構成並びにアプリケーションプログラミングインターフェイス（ＡＰＩ）に構築されたマッシュアップを含む。実施者は、これらの技術を使用して、上述したメタデータ応答アグレゲーター、トラフィックモニタ及びルールプロセッサを構築すると共に、これらモジュールのそれ自身のバージョンをルーティングシステムのトップに構築することができる。例えば、システムは、マッシュアップのハイアラーキーに埋め込まれ、各マッシュアップは、システムにより提供されるメタデータサービスの他のマッシュアップのＡＰＩのトップに付加的な機能を与える。ルーティングシステムは、コンテンツ識別子にメタデータソースをリンクするメカニズムを設けることで、コンテンツオブジェクトネームサービスを生成する（それをコンテンツアイテムに対するドメインネームサービスとして考える）。更に、このサービスのトップに構築される応答アグレゲーター、ルールプロセス、及び／又はトラフィックモニタは、上述したように、ルーティングシステムのマッシュアップとして実施することができる。これらのメタデータサービスがこの形式の相互接続されたマッシュアップにおいて構成されるときには、ルーティングシステムは、コンテンツメタデータマッシュアップに対して一形式のＤＮＳを与える。
【０１３２】
［メタデータ人気の測定及びテイストメーカーの識別］
システムにおけるコンテンツ及びメタデータの消費を追跡し、そのデータをユーザコミュニティに後で公表することで、ユーザは、その嗜好に一致するメタデータを有効に識別することができる。また、コンテンツ所有者がこれらの嗜好を分析し、そしてコンテンツを人気のあるユーザ発生メタデータと共に再パッケージする機会も与える。また、コンテンツ所有者は、一意緊密なグループを識別し、そしてそれらグループの嗜好に対する新たな解放を調整することができる。上述したように、システムは、多数の形式の使用データを追跡する。これら形式の使用データは、コンテンツオブジェクトのトラフィックの監視（オブジェクト配布の追跡）、メタデータ要求のトラフィック（例えば、特定メタデータに対する要求の数、又は特定ソースからのメタデータ）、並びにユーザの嗜好及びルールの処理（例えば、緊密なグループの分析のようなメタデータの分析から導出されるユーザの嗜好）を含む。動的なメタデータ（オブジェクトが消費されるときに時間と共に発生されるメタデータ）に対するサポート、並びにメタデータ及びそのプロバイダーの人気を測定するための手段と共に、システムは、コンテンツオブジェクトの所有者及び広告主がこの人気のあるメタデータをパッケージしそしてそれを現金化する（それを販売するか又はユーザによる消費と共に提示される広告を販売する）機会を与える高い価値のメタデータを識別する。
【０１３３】
また、システムは、メタデータ発生及び消費データの経歴的アーカイブを捕獲することができ、これは、更に、コンテンツ及びメタデータの配布を分析して、パッケージ及び現金化されるべき時点から同様に捕獲された過渡的なメタデータを識別できるようにする。例えば、動的なメタデータは、その発生及び配布を生じさせたコンテンツオブジェクトと共にパッケージすることができる。例えば、ユーザの緊密なグループのテイスト、時間周期、地理的マーケット、等によりパッケージされるコンテンツを含む。
【０１３４】
［ＣＭＤＳ実施例の概要］
コンテンツメタデータディレクトリサービス（ＣＭＤＳ）は、識別されたコンテンツのコンシューマを、コンテンツプロバイダー許可及び管理のメタデータデータベース及び他のデジタルリソースに接続するグローバルに信頼性のあるディレクトリサービスを提供する。
【０１３５】
これは、デジタル配布がコンテンツをパッケージングから分離し、新たな１−１マーケッティング機会がコンテンツ配布に最適に利用されず、且つ価値チェーンを簡単にするのはなく複雑にする独占的チャンネルでデジタル配布が前方に移動されることにより生じる問題を解決する。このＣＭＤＳシステムは、全ての既存の価値チェーン参加者に、メタデータ使用に合意して、別の独占的メタデータレポジトリーではなく、それらの独占的メタデータを管理するための環境を与える。また、クロス販売／アップ販売のｅ−コマース機会も与える。ＣＭＤＳシステムは、全てのコンテンツ識別子、ＰＣ及び移動装置と相互運用可能であり、バーチャルマーケッティング統計情報を伴う使用報告を可能にする。
【０１３６】
ＣＭＤＳシステムは、（１）登録インターフェイス、（２）解明インターフェイス及び（３）ルーター要件、の３つのコンポーネントを標準化する。これらのインターフェイスは、簡単化及び相互運用性のために、既存の工業規格であるＸＭＬベースのウェブサービスに関して指定される。ルーター要件は、システムが適切に機能し、売り主及びユーザに対する価値を最大にすることを保証する。これらの最小仕様で、売り主及びユーザが相互運用するために簡単でありながら、非常に融通性のあるワークフロー及びアーキテクチャーを与えるシステムが生成される。例えば、ＣＭＤＳは、（１）デジタル透かし（ＤＷＭ）又はサイン入りヘッダのような技術で埋め込むことのできる一意コンテンツ識別子（ＣＩＤ）を生成するか、又は（２）コンテンツ指紋（ａ．ｋ．ａ．健全なハッシュ）、電子製品コード（ＥＰＣ）、ＩＦＰＩのＧｒｉｄ及びＵＲＩのような既存のシステムにより生成されたＣＩＤを利用することができる。更に、ユーザは、アーチスト、同様のコンテンツ、及び関連アイテムについてより多くを学習し、そしてコンテンツ及び関連アイテムを購入することができる。
【０１３７】
ＣＭＤＳシステムは、ユーザに貴重な情報及び簡単な購入オプションを与えると共に、コンテンツ使用についてのコンテンツ所有者及びリテーラーの知識を拡張し且つコンシューマがコンテンツ及び関連アイテムを購入し易くすることで、コンテンツ所有者及びリテーラーがＲＯＩを増加するのを助ける。
【０１３８】
［ＣＭＤＳ実施の定義］
次の章で使用する用語を、ここに、アルファベット順に定義する。
【表１−１】
0005555271.tif 000002
【表１−２】
0005555271.tif 000003
【表１−３】
0005555271.tif 000004
【０１３９】
［ＣＭＤＳ背景］
コンテンツメタデータディレクトリサービス（ＣＭＤＳ）システムが必要であるのは、コンテンツ識別技術では、ＩＤを当該情報（ａ．ｋ．ａ．メタデータ）にリンクするバックエンドシステムにアクセスせずに有用な情報を与えることができないからである。中央メタデータレポジトリーに対して有益であるのは、ルーターベースシステムであり、コンテンツプロバイダーは、それらの独占的情報を管理することができ、そしてコンテンツは、いかなる位置からでもこの情報にルーティングすることができる。
【０１４０】
ＣＭＤＳは、識別されたコンテンツのコンシューマを、認証された「ソース起点」データベース及び他のコンテンツプロバイダー許可のデジタルソースに接続するグローバルに信頼性のあるメタデータディレクトリサービスを提供する。
【０１４１】
ＣＭＤＳは、コンテンツ所有者が次のことを行えるようにする。
●社内のデジタル資産管理システムをレバレッジする
●規模の経済から利益を得る
●自身のデジタル資産に対してコンテンツ当局として働く
●断片化した解決策ではなく、単一の統合した解決策からデジタル配布問題に対処する
●クロス販売／アップ販売
また、ＣＭＤＳは、コンシューマのメタデータ及びｅ−コマースの機会も提供する。
【０１４２】
●ルーティングに集中する
○コンテンツプロバイダーは、それらの独占的情報を管理する
●全ての価値チェーン参加者に対してｅ−コマースをイネーブルする
○例えば、コンテンツ所有者及びリテーラーの両方がＣＩＤを埋め込むことができる
●全てのコンテンツアイデンティティプロバイダー技術との相互運用性
●ＰＣ及び移動装置の両方との適合性
●共通のアルゴリズムを認可する複数のＩＤプロバイダーに対する相互運用性
●使用報告及び重要なマーケッティング統計情報をイネーブルする
【０１４３】
［ＣＭＤＳシステム実施形態の概略］
コンテンツ識別システムは、図４に示したように、登録、埋め込み／計算、読み取り、解明、及びルーター、の５つのメインコンポーネントを有する。これらのコンポーネントは、コンテンツ識別及びコンテンツルーティング（例えば、ＣＭＤＳ）カテゴリーにグループ分けすることができる。コンテンツ識別コンポーネントは、コンテンツ識別を埋め込み（又はそれを指紋に対して計算し）、そしてコンテンツ識別を読み取る（ａ．ｋ．ａ．検出）ことを含む。コンテンツ所有者は、通常、埋め込みを取り扱い、コンシューマ製品は、通常、読み取りを取り扱う。
【０１４４】
ＣＭＤＳコンポーネントは、次のものを含む。
１．登録インターフェイス
２．解明インターフェイス
３．ルーター
【０１４５】
これら３つのコンポーネントは、コンテンツ識別技術が相互運用できるようにコンパニオン仕様で標準化される。また、識別子のビットが少ないほど、良好であるＤＷＭのような技術、及び非整数ネームスペースを有するＵＲＩのような技術の両方に対して、実施例が最適化される。実施例は、ＰＣ又は移動環境（或いは将来のハイブリッド環境）に対して最適化される融通性を有する。
【０１４６】
図４において、コンテンツは、このプロセスのために配布されるときに識別されるので保護及び識別されたコンテンツと表示付けされ、また、他の手段によって保護されてもよい。この実施例の焦点は、識別を使用してコンテンツを向上させることであるが、識別は、コンテンツを保護するために使用されてもよく、及び／又は他の技術を使用して、コンテンツを保護してもよい。識別を使用してコンテンツを向上させると共に保護するときには、相互利益があり、例えば、識別をもたない海賊版コンテンツは、ユーザに向上特徴を与えない。換言すれば、この実施例は、コンテンツ保護に置き換わるものではなく、それと相乗効果的なものである。
【０１４７】
登録当局は、これら３つのコンテンツルーティングコンポーネントを取り扱う。Ｂ２Ｃ環境で使用されるパブリックシステムの場合、登録当局は、信頼性のある第三者売り主である。１つのパブリック登録当局がある。Ｂ２Ｂ環境で使用されるプライベートシステムの場合、登録当局は、通常、プライベートシステムプロバイダー（及び通常は、ＩＤプロバイダーのみ）である。プライベート登録当局は多数あってもよく、このＢ２Ｂ環境では各システムが別のシステムと対話する見込みが高い。
【０１４８】
このシステムの設計は、コンテンツプロバイダー（Record Label、Movie Studio及びStock Photo Agenciesのようなコンテンツ所有者、及びApple iTunes、Napster、WalMart、Hollywood Video、等のリテーラーを含む）が、図５に示すように、コンシューマのようなユーザと直接対話するのを許す。これは、コンテンツプロバイダーがそれら自身の独占的データを管理できるようにする。換言すれば、使用モデルは、ユーザがルーターと対話し、ルーターがユーザをメタデータ及びｅ−コマース機会のためにコンテンツプロバイダーへ再方向付けすることである。
【０１４９】
従って、システムは、メタデータに対する要求を、コンテンツ所有者及びリテーラーのようなコンテンツプロバイダーへルーティングする。換言すれば、ルーターは、ルーターではなく、コンテンツプロバイダーにより記憶されたメタデータ及びｅ−コマース機会へリンクするＣＩＤ及びＵＲＬを主として含むデータベースを備えている。
【０１５０】
システムは、図７に示すように、分散型アーキテクチャーを有する。このときは、中央ルーターの複製（ミラールーターと表示された）のみが指定される。これらルーターは、個別の登録及び解明ルーターを有することができる。おそらく、より多くの解明要求が生じるであろうから、より多くの解明ルーターが存在することになる。将来、キャッシュ型ルーターがミラー解明ルーターと対話し、効率的な応答のために最近の解明要求だけをセーブする。キャッシュ型ルーターは、登録要求には適用できない。というのは、これらの要求は、頻繁に発生することも繰り返し発生することもなく、中央ルーターへ直ちに転送されるからである。この実施例では、リーダーが、登録及び解明のために利用すべきルーターのアドレスを周期的に要求することを必要とし、従って、システムは、コンフィギュレーションを動的に変化させることができる。中央ルーター及びミラールーターがアドレスを要求する必要はない。というのは、それらは、全て、登録当局により動作され、従って、互いのアドレスを知っているからである。
【０１５１】
ルーターは、ハンドラー及びデータベースより成る。ハンドラーは、登録及び解明要求を受け入れ、要求された情報を素早く得、そして登録及び解明応答を送信する。これは、例えば、ローカルの低クオリティの実施の場合、データベースと同じマシン上で実行される単一のソフトウェアスレッドでもよいし、或いは図６に示すように、複数のＣＰＵを横切ってローカル要求データベースにリンクされた種々の要求ハンドラーへ要求コード又はＩＤプロバイダーにより（両フィールドがＸＭＬメッセージヘッダにあるので）要求を迅速にハンドオフしてもよい。
【０１５２】
［ワークフロー実施例］
コンテンツ所有者及びリテーラーが連絡先情報及びコンテンツを登録し、そしてコンシューマがメタデータにリンクしてコンテンツを購入するところを示す例示的ワークフローが表１に示されている。この実施例は、ＩＤプロバイダー及び２人のコンテンツプロバイダー、コンテンツ所有者及びリテーラーが、登録当局からそれらの各識別及びパスワードを受信したと仮定している。また、ＩＤプロバイダーが連絡先情報を登録し（UpdateIDProvider要求コードを経て）、また、エンベッダー及びリーダーソフトウェアを配布したと仮定する。要求コードは、ルーターへ送られるメッセージのための矢印間にイタリック体で示される。
【表２−１】
0005555271.tif 000005
【表２−２】
0005555271.tif 000006
【表２−３】
0005555271.tif 000007
【０１５３】
［アーキテクチャーの例］
アーキテクチャーは、拡張可能なメッセージングインターフェイス及びルーター設計を仕様書で定義するので融通性がある。
【０１５４】
コンテンツ所有者及びリテーラーの両方がシステムを使用できるようにする例示的アーキテクチャーが図８に示されている。多数の他のアーキテクチャー又はこのアーキテクチャーの拡張が考えられるが、このアーキテクチャーは、最も使用されるアーキテクチャーであることが期待される。このアーキテクチャーは、先の章で述べたワークフロー及び他の多数のワークフローを可能にする。このアーキテクチャーは、次のものを含む。
●識別をコンテンツに埋め込む（又はその指紋を記憶する）登録インターフェイスを有する埋め込み／計算ソフトウェアを伴うコンテンツ所有者環境
●識別をコンテンツに埋め込むか又は追加する（又はその指紋を記憶する）登録インターフェイスを有する埋め込み／計算ソフトウェアを伴うリテーラー環境
●中央ハンドラー、中央データベース、ミラーハンドラー及びミラーデータベースより成るルーター
●サイバースペースにおける保護及び識別されたコンテンツ
●ユーザをより多くの情報にリンクするための解明インターフェイスと、ユーザが二次パーソナル情報の送信に加入する場合にはユーザを登録するための登録インターフェイスとを有するリーダーソフトウェアを伴うユーザ環境
【０１５５】
［使用シナリオの例］
これらの使用シナリオは、仕様の融通性及び能力を立証する上で助けとなる。また、それらは、背景において技術的に何が生じるかも述べる（カッコ内の要求コード及び他のＸＭＬタグと共に）−それらは技術的な詳細であるから全て下線で示す。
【０１５６】
［メタデータ及びｅ−コマースにリンクされたコンシューマ］
この使用シナリオは、ＩＤプロバイダー、例えば、コンテンツ所有者及びリテーラーのようなコンテンツプロバイダー、及びユーザ、並びに、例えば、メタデータ及びｅ−コマースにリンクするコンシューマのようなユーザに対する登録のほとんどの観点を含む。これは、システムの多数の重要な観点を立証し、表１のワークフロー例に最も類似している。
【０１５７】
［ＩＤプロバイダーの登録］
第１のステップは、少なくとも１つのＩＤプロバイダーを登録することである。ＩＤプロバイダーは、メールレター又は電話コール並びに会社及び担当者セキュリティチェックのような安全プロセスを経て登録当局からＩＤ及びパスワードを受け取る。次いで、ＩＤプロバイダーは、登録当局のソフトウェア（UpdateIDProvider）を通して又は双方向安全ウェブページを通してそれらの連絡先情報を登録当局に安全に登録する。ＩＤプロバイダーは、成功又はエラーが通知される。
【０１５８】
背景において、ＩＤプロバイダーの埋め込み及び検出ソフトウェアは、ＩＤプロバイダーＩＤを含み、それを、埋め込み又は検出アルゴリズムのＩＤバージョンと共に、各要求で提出する。
【０１５９】
［コンテンツ所有者がコンテンツプロバイダーとして登録する］
第２のステップは、コンテンツ所有者の登録である。コンテンツ所有者は、メールレター又は電話コール並びに会社及び担当者セキュリティチェックのような安全プロセスを経て登録当局からコンテンツプロバイダーの名前及びパスワードを受け取る。次いで、コンテンツ所有者は、ＩＤプロバイダーから受け取ったそれらの埋め込み又は関連ソフトウェアを使用して、連絡先情報を安全に登録する（UpdateContentProviderを経て）。埋め込みソフトウェアは、応答を検証し、コンテンツ所有者に成功又はエラーを通知する。
【０１６０】
或いはまた、コンテンツプロバイダーは、登録当局の安全ウェブサイトを使用して、それらの連絡先情報を双方向に登録することができる。
【０１６１】
［コンテンツ所有者が新たなコンテンツを登録する］
コンテンツ所有者が登録を済ますと、それらのコンテンツを安全に登録する。第１に、彼らは、埋め込み又は関連ソフトウェアを使用して、一意コンテンツＩＤを得る(CreatedCIDを経て)。その後、コンテンツプロバイダーは、ＰＣに対して１つ及び移動装置に対して１つの、２つの一次ＵＲＬを登録し（フル又はＷＡＰデータエントリーを伴うURLType XMLタグを経て）、且つＰＣに対して２つ及び移動に対して２つの、４つの付加的なＵＲＬを登録する（RegURL要求コードを伴う６つのコールを経て）。例えば、ＰＣ及び移動装置の両方に対して、一次ＵＲＬは、ディズニーからの映画ファンタジアに関する静的な情報を与え、１つの付加的なＵＲＬは、ファンタジアの中の歌に関する情報を与え、そして他の付加的なＵＲＬは、ＣＩＤに基づくサーチ用語を含むＵＲＬを経て動的ウェブページを使用して、Amazon.comからのファンタジアに関する販売のためのアイテムを与える。ソフトウェアアプリケーションは、成功のための応答を検証し、コンテンツ所有者に成功（又はエラー）について知らせる。
【０１６２】
１つの別の態様において、コンテンツ所有者は、フル機能又はＷＡＰのためのチェックボックスでソフトウェアのＧＵＩに複数のＵＲＬを入力することができる。このコンフィギュレーションの背景において、ソフトウェアは、要求グループ分け方法を使用してＣＩＤを得(CreatedCIDを経て)、一次ＵＲＬ（RegURLを伴う２つのコールを経て）及び付加的なＵＲＬ（RegURLを伴う２つのコールを経て）を登録する。ルーターは、ＣＩＤがＵＲＬの前に登録されるようにタイミングを取り扱う。
【０１６３】
更に別の態様において、コンテンツ所有者は、登録当局の安全ウェブサイトを使用して、ＵＲＬを１つづつ双方向に登録することができる。
【０１６４】
［リテーラーがコンテンツプロバイダーとして登録し且つコンテンツを登録する］
リテーラーは、コンテンツ所有者と権利について考えをめぐらせていると仮定すれば、コンテンツプロバイダーとして登録当局に安全に登録し、コンテンツプロバイダーの名前及びパスワードを得、そして連絡先情報を登録することができる（UpdateContentProviderを経て）。例えば、リテーラーは、AppleiTunes店である。次いで、リテーラーは、コンテンツを販売する準備をするときに、ＣＩＤを要求し（CreateCIDを経て）、そして同じアーチストによる歌を販売するための１つの一次ＵＲＬ（RegURLを経て）と、同様の歌を販売するための１つの付加的なＵＲＬ（RegURLを経て）の、２つのＵＲＬを追加する。
【０１６５】
［匿名ユーザのリンク］
ユーザは、登録されたＣＩＤと共にコンテンツのコピーを受け取ると、そのマルチメディアプレーヤからより多くの情報を要求して受け取ることができる。好ましくは、マルチメディアプレーヤは、ＣＩＤに対して常にスキャンし、このＣＩＤに対してＵＲＬが登録されていることをチェックし、そして記号又は“more info by <company name>”アイコンを表示して、コンテンツが向上されたことをユーザに知らせるリーダープラグインを備えている。また、このスキャニングプロセスは、ＣＩＤ検出が既に行われているので、応答時間を即座なものにする。
【０１６６】
ユーザは、より多くの情報を受け取ることを選択すると、５つのウェブリンクを短い記述と共に受け取る。コンテンツ所有者からは３つのリンクがあり、それは、映画の歴史をもつものと、関連する歌情報をもつものと、Amazon.comからのファンタジアに関する販売のためのアイテムをもつものである。映画を販売するリテーラーからは２つのリンクがあり、それは、同じアーチストの歌を買うことができるものと、同様のコンテンツを購入できるものである。ユーザは、リンクをクリックして、表示されたウェブサイトを訪れることができる。
【０１６７】
背景において、リーダーソフトウェアは、コンテンツ所有者のＣＩＤについて１つと、リテーラーのＣＩＤについて１つの、２つの要求を含むグループでＵＲＬを要求する（ResURLを経て）。最後のステップとして、リーダーソフトウェアは、返送されたＵＲＬをパーズし、それらをユーザに表示する。
【０１６８】
ＣＩＤが２つの異なるＩＤプロバイダー技術により埋め込まれた場合には、ユーザは、２つの異なる“more info”ボタンを見、例えば、その一方は、“more info fromDisney”であり、もう一方は、“more info from Apple iTunes Store”であり、そしてユーザの選択に基づいて、対応する要求が送信され、応答が表示される。
【０１６９】
［移動ユーザ］
セルラー電話ユーザは、コンテンツを識別すると、登録されたＵＲＬのＷＡＰ又はＷＭＩバージョンにリンクする。但し、コンテンツプロバイダーがそのようなＵＲＬの形式を登録したと仮定する（登録又は解明中にＷＡＰ又はＷＭＩデータを伴うＸＭＬタグＵＲＬＴｙｐｅを経て）。小さなスクリーンに対してフォーマットされた情報が表示される。更に、好ましくは、ユーザは、一次リンクのみの表示を選択し（コンテンツ所有者又はリテーラーに対して）、より多くの情報を受け取るように選択した直後にコンテンツプロバイダーの情報を表示することができる（ＵＲＬや記述が進行していることがあるのでそれらのリストからユーザが再び選択することを必要とせずに）。
【０１７０】
例えば、セルラー電話ユーザは、好きな歌をラジオで聴くときには、その歌を識別して（ＤＷＭ又は指紋を経て）、より多くの情報にリンクすることができる。同様に移動ユーザは、それらのＰＤＡ電話で聞いている歌を識別して、より多くの情報へリンクすることができる。
【０１７１】
［ユーザ登録］
別のユーザは、新たなハイブリッドカーに勝つチャンスを得るためにパーソナル情報を登録するよう判断する。彼らは、マルチメディアプレーヤに対してリーダープラグインから登録する（RegUserを経て）。ソフトウェアアプリケーションは、成功に対する応答を検証し、ユーザに成功（又はエラー）について知らせる。ユーザは、それらの情報をいつでも更新できるし（UpdateUserを経て）、或いは１つの特定のリンク又は全ての将来のリンクについて脱退するよう判断することもできる。
【０１７２】
［登録されたユーザのリンク］
この登録されたユーザがリーダープラグインソフトウェアからのビデオに関してより多くの情報を要求するときには（ResURLを経て）、匿名のユーザに対して表示されるものと同じ５つのリンクが表示されると共に、ファンタジア又は同様の映画を上映しているユーザの郵便番号内の付加的な映画館、及び関連する商品を売っているユーザの郵便番号内の店へのリンクが表示される。更に、コンテンツプロバイダー（例えば、コンテンツ所有者又はリテーラー）が各ユーザ名情報を維持する場合には、ユーザの以前の購入に基づいて他のアイテムを示唆することもできるし、或いはそれが過去に多数のものを購入している好ましい顧客である場合には「インスタントチャット」アイコンを発生することができる（きちんと着飾った買い物客又は頻繁に来る買い物客のカード保有者が自然界の店でも良いサービスが得られるのと同等に）。いつか、このユーザは、全ての店が同じ安全なユーザ情報を共有するときには、リストされたアイテムのいずれかを購入することから１クリックで遠ざかると信じる。
【０１７３】
［コンテンツプロバイダー及びＩＤプロバイダーレポート及び勘定］
月末に（又は他の時期に）、コンテンツプロバイダー（例えば、コンテンツ所有者又はリテーラー）は、登録当局のウェブページにログオンし、登録されたＣＩＤの各々について使用データを安全に検討する。彼らの新しい映画は、米国の東北部及びカナダで、特に８歳ないし１０歳により、ほぼ７ＰＭ  ＥＳＴで人気があることが分かる。また、彼らは、その使用が下降し始めており、この年齢グループに対する現在解明使用の２０％を表し、このターゲット聴衆で新たな映画を封切する時期であることを示していることも分かる。最終的に、彼らは、固定金額又は月々の勘定で自動的に手を引くというコスト及び勘定オプションを調べることができる。
【０１７４】
また、ＩＤプロバイダーは、同じウェブサイトにログオンし、彼らの技術を使用して登録された全てのＣＩＤに対する総計使用データを検討することもできる。しかしながら、彼らは、個々のＣＩＤにより統計学的情報を検討することはできない。というのは、それがコンテンツプロバイダーにより所有されたものだからである。
【０１７５】
背景において、各ルーターは、ヒットごとにログファイルをセーブし、そして好ましくは、ログファイルを毎日処理して、使用データを総計し、これら統計学的情報とのリアルタイム対話を与えると共に、コンテンツプロバイダー及びＩＤプロバイダーへｅ−メールレポートする自動的な能力も与える。
【０１７６】
［指紋／健全なハッシュがコンテンツをＵＲＬにリンクする］
指紋を使用してコンテンツを識別するときには、コンテンツから指紋が計算されてデータベースへ入力される。次いで、コンテンツの識別を試みるときに、指紋が計算され、そしてある確実性スレッシュホールド内にも入るデータベースの最も近い指紋との一致が取られる。指紋は、通常、特に、コンテンツがストリーミングであるときには、サブ指紋の集合である。従って、指紋は、一意コンテンツＩＤではなく、指紋データベースは、指紋（即ち、サブ指紋の集合）を独特なコンテンツＩＤにリンクする。
【０１７７】
［コンテンツプロバイダーの登録］
コンテンツプロバイダーは、（ｉ）指紋プロバイダーの独占的コンテンツＩＤシステムを使用して、既存のＣＩＤをルーターに登録し（RegCIDを経て）、又は（ii）一意ＣＩＤを要求し（CreateCIDを経て）、それを指紋データベースに使用する。次いで、コンテンツプロバイダーは、ＣＩＤへリンクするためにＵＲＬを登録することができる（RegURL及びRegURLsを経て）。
【０１７８】
ケース（ｉ）では、ＣＩＤの独特さが保証される。というのは、指紋データベースは、ＣＩＤがそのデータベースにおいて独特であることを保証し、そしてＣＩＤとＩＤプロバイダーＩＤ及びＩＤバージョンとの組合せがグローバルな独特さを保証するからである。ケース（ii）では、ＣＩＤが中央ルーターにより独特であることが保証され、そして同じ組み合わせがグローバルに独特である。ＩＤバージョンは、各ＩＤプロバイダーに対する各指紋アルゴリズム及び関連データベースについて独特に定義される。
【０１７９】
［ユーザを指紋でメタデータにリンク］
ユーザは、ＣＩＤと共により多くの情報を受信すると共に、ＵＲＬ及び短い記述を受信することを選択する（ResURLsを経て）。次いで、ユーザは、受信を希望する情報をもつＵＲＬをクリックする。
【０１８０】
背景において、ユーザが、指紋で識別されたコンテンツに対してより多くの情報を受信することを要求するときに、指紋リーダーは、指紋を計算し、それを指紋サーバー（指紋プロバイダーのサーバー又は中央ルーターで実行される）へ送信し、指紋サーバーは、指紋データベースからＣＩＤを決定し、ＣＩＤをリーダーへ返送し、そしてリーダーは、ＣＩＤを使用して、ルーターからＵＲＬを要求する（ResURLsを経て）。解明要求メッセージにおいてＩＤプロバイダーＩＤ、ＩＤバージョン、及びＣＩＤデータにアクセスできるルーターは、このグルーバル一意組合せを使用して、正しいＵＲＬをルックアップする。適切なＩＤバージョンは、リーダーによって知られている。というのは、リーダーは、アルゴリズムのそのバージョンを使用して、ＣＩＤを決定するからである。
【０１８１】
［ＥＰＣのような他のＩＤシステムを経てのリンク］
あるケースでは、異なる登録当局には、おそらく他の目的で一意アイデンティティが以前に与えられており、この一意コンテンツＩＤをこのシステムに使用できるのが最適である。例えば、エレクトロニックプロダクトコード（ＥＰＣ）は、高周波識別子（ＲＦＩＤ）を伴う一意ＩＤを与える。同様に、ＩＦＰＩのＧＲｉｄは、一意コンテンツＩＤを与える。或いは、４Ｃは、ＶｅｒａｎｃｅのＤＷＭをもつ一意ＩＤを与える。更に、ＩＤプロバイダーは、例えば、ＩＤ３タグからの“album:artist:song”組合せを使用して、それ自身の一意ＩＤを発生することができる。
【０１８２】
一般的識別子（ＧＩＤ−９６）としても知られている例えば９６ビットＥＰＣフォーマットは、次の通りである。
●ヘッダ：８ビット
●製造者：２８ビット又は２億６千８百万の独特なＩＤ
●製品（ＳＫＵ）：２４ビット即ち千６百万の独特なＩＤ
●シリアルナンバー：３６ビット即ち６８０億の独特なＩＤ
【０１８３】
ＣＭＤＳの目標は、コンテンツ所有者により管理され且つ複数のＩＤ技術プロバイダーにより識別される情報にユーザをリンクすることであるが、ＥＰＣＮｅｔの目標は、各参加者に対し配布プロセスを通してアイテムを追跡することを含むので、バックエンド構造が異なることになる。従って、これら２つのネットワークは、ＥＰＣＮｅｔ  ＩＳがＣＭＤＳルーターへのインターフェイスを有する状態で相乗作用的に機能することができる。ＥＰＣ  ＧＩＤ−９６フォーマットでＲＦＩＤを含む映画のポスター広告のようなＥＰＣを使用する実施例を以下に説明する。
【０１８４】
［既存のＣＩＤに対するＵＲＬの登録］
第１ステップは、コンテンツプロバイダーが既存のＣＩＤを登録することである（RegCIDを経て）。次いで、コンテンツプロバイダーは、一次のフルＵＲＬを登録し（RegURLを経て）、そしてもし希望があれば、付加的なＵＲＬを登録し（RegURL又はRegURLsを経て）又は移動フォーマットに対するＵＲＬを登録することができる。
【０１８５】
この仕様を使用してＣＩＤを生成するときには、ＣＩＤネームスペースが、各ＩＤプロバイダー及びそれらの現在ＩＤバージョン（例えば、アルゴリズムバージョン）に対して独特であるよう保証され、そしてＣＩＤフォーマットは、１０進である。しかしながら、予め識別されたコンテンツは、そのＣＩＤが、このシステムの同じＩＤプロバイダーにより使用される他のＣＩＤに重畳することがあるので、ＩＤバージョンを使用して（IDVersion XMLタグを経て）、適切なＣＩＤネームスペースを決定する。例えば、ＧＩＤ−９６ＥＰＣコードを表すＣＩＤは、ＨＨ．ＭＭＭＭＭＭＭ．ＰＰＰＰＰＰ．ＳＳＳＳＳＳＳＳＳの１６進フォーマットを有し、ここで、Ｈは、ヘッダ（８ビット）、Ｍは、製造者（２８ビット即ち２億６千８百万の独特なＩＤ）、Ｐは、製品ＳＫＵ（２４ビット即ち千６百万の独特なＩＤ）、そしてＳは、シリアルナンバー（３６ビット即ち６８０億の独特なＩＤ）である。従って、ＩＤプロバイダーは、ＥＰＣ  ＧＩＤ−９６フォーマットに対してＩＤバージョンを、そして他のＥＰＣフォーマット又は他のＣＩＤフォーマット（例えば、ＤＷＭ）に対して異なるＩＤバージョンを有する。エンベッダーがＥＰＣ  ＧＩＤ−９６フォーマットＩＤを登録するときには、それに対応するＩＤバージョンを送信する。
【０１８６】
［既存のＣＩＤでＵＲＬにリンク］
リーダーソフトウェアは、既存のＣＩＤを検出し、それをルーターへ送信し（ResURLを経て）、ＵＲＬを受信し、そしてそれをユーザへ表示する。
【０１８７】
背景において、ＩＤプロバイダーＩＤ、ＩＤバージョン、及びＣＩＤデータにアクセスできるルーターは、このグルーバル一意組合せを使用して、正しいＵＲＬをルックアップする。適切なＩＤバージョンは、リーダーによって知られている。というのは、リーダーは、アルゴリズムのそのバージョンを使用して、ＣＩＤを決定する必要があるからである。
【０１８８】
［複数のＩＤプロバイダーからの相互運用可能なＩＤ技術］
ある会社が埋め込み及び検出技術（即ち、ＯＥＭ）を複数のＩＤプロバイダーに認可するときには、あるＩＤプロバイダーのリーダーが、別のＩＤプロバイダーのエンベッダーで埋め込まれたＣＩＤを利用できるというユーザに望まれる解決策が生じる。しかしながら、ＩＤプロバイダーは、埋め込みプロセスのための「クレジット」を希望し、従って、このコンテンツルーティングシステムは、埋め込みＩＤプロバイダーを追跡する。
【０１８９】
［コンテンツに埋め込まれたＩＤプロバイダーＩＤ］
各ＩＤプロバイダーのエンベッダーは、それらのＩＤプロバイダーＩＤを、コンテンツプロバイダーにより要求されて埋め込まれた（CreateCIDを経て）ＣＩＤと共に埋め込む。
【０１９０】
［ＵＲＬ要求と共に含まれる埋め込みＩＤプロバイダーＩＤ］
リーダーソフトウェアは、ＣＩＤを読み取ると、埋め込みＩＰプロバイダーＩＤも読み取る。埋め込みＩＰプロバイダーＩＤが、リーダーに記憶されたものと異なる場合には、それがＵＲＬ解明要求メッセージに含まれる（EmbIDProviderID XMLフィールドを経て）。ルーターは、埋め込みプロセスに対して適切に補償する等の更なる行動のために、埋め込みＩＰプロバイダーＩＤをログする。
【０１９１】
［ＣＭＤＳ章の結論］
結論として、コンパニオン仕様は、コンシューマに貴重な情報を提供すると共に、コンテンツプロバイダーがそれらの独占的データ及びコンシューマとの対話を管理するような分散ルーティングアーキテクチャーを可能にする。コンテンツプロバイダーは、レコードラベル、ムービースタジオ、ストックフォトエージェンシー、等のコンテンツ所有者と、アップルｉＴｕｎｅ、ウオルマート（クリック・アンド・モルタル）、カタログ会社、広告主、ネットフリックス、等のリテーラーとを含むことができる。
【０１９２】
更に、この仕様は、コンテンツプロバイダーがアイデンティティプロバイダー技術を使用してユーザを適切な情報にリンクできるようにする。更に、複数のＩＤプロバイダーが、コンテンツ識別ＯＥＭアルゴリズムを共有するときには、各ルーターは、適切な支払いに対する使用をシームレスに相互運用し追跡することができる。重要なことに、システムは、複数のＣＩＤをコンテンツに存在できるようにし、完全な価値チェーン（例えば、コンテンツ所有者及びリテーラー）が参加するか、又は参加のためのビジネスルールを生成できるようにする。
【０１９３】
更に、この仕様は、デジタル透かし（ＤＷＭ）、指紋（ａ．ｋ．ａ．健全ハッシュ）、エレクトロニックプロダクトコード（ＥＰＣ）、ＩＦＰＩのＧｒｉｄ及びＵＲＩを含む全ての識別技術及び既存のシステムに対して最適化される。最終的に、この仕様は、セキュリティトレースについてだけでなく、ＩＤプロバイダーがルーターの需要を理解し且つコンテンツプロバイダーがコンテンツの使用を理解するのを助ける使用レポートについてもロギングすることを含む。この仕様は、複数のＩＤシステムをシードし且つ非合法的コンテンツに対する「今買う(buy now)」機能を与えることに関する使用ケースを取り扱うように容易に拡張することができる。
【０１９４】
最後に、この仕様は、コンテンツ使用の知識を広げると共に、コンシューマがコンテンツ及び関連アイテムを購入するのを容易にすることにより、コンテンツ所有者及びリテーラー（ひいては、配布者）が売り上げを増加する（↑ＲＯＩ）上で助けとならねばならない。
【０１９５】
以下の実施例は、工業規格ＸＭＬベースのウェブサービスを使用して、ルーターへのオープンインターフェイスを与える。
【０１９６】
［ＣＭＤＳ実施例の概略］
このＣＭＤＳ実施例の仕様のメインコンポーネントは、次のものを含む。
●登録インターフェイス
○登録要求メッセージ
○登録応答メッセージ
●解明インターフェイス
○解明要求メッセージ
○解明応答メッセージ
●ルーター要求
【０１９７】
登録及び解明要求メッセージは、ＸＭＬを使用し、次のものを含む。
●ヘッダ
●本体
○一次情報
○二次情報
【０１９８】
応答メッセージは、簡単である。登録応答メッセージは、簡単で、ヘッダも、本体サブセクションも必要とせず、そして解明応答メッセージは、一次及び二次の情報サブセクションのみを含む。
【０１９９】
［ＩＤプロバイダー、コンテンツプロバイダー及びユーザ］
この実施例を理解するためには、ＩＤプロバイダーと、コンテンツプロバイダーと、ユーザとの間の関係を理解することが有用である。
【０２００】
ＩＤプロバイダー：コンテンツを識別し、ルーターとインターフェイスするための技術を提供する会社である。
【０２０１】
コンテンツプロバイダー：コンテンツのプロバイダーであって、例えば、コンテンツ所有者及びリテーラー、又はコンテンツ及び／又はコンテンツメタデータを配布する権利をもつ会社である。例えば、コンテンツ所有者は、レコードラベル、ムービースタジオ及びストックフォトエージェンシーを含むことができる。リテーラーは、アップルｉＴｕｎｅ、ウオルマート（クリック・アンド・モルタル）、広告主、カタログ会社、及びナプステアを含むことができる。
【０２０２】
ユーザ：システムのエンドユーザである。例えば、ＰＣマルチメディアジュークボックスを経てより多くの情報にリンクするコンシューマでもよいし、又は閉じたプライベートシステムを経て現在マーケッティング資料にリンクする映画評論家でもよい。
【０２０３】
［ＣＩＤ、ＩＤバージョン、ＩＤプロバイダーＩＤ、及びグローバルな独特さ］
更に、この実施形態は、ＣＩＤと表示される一意コンテンツ識別子に基づく。ＣＩＤは、各ＩＤプロバイダーＩＤ及びＩＤバージョンにとって独特であることが重要である。ＣＩＤは、異なるＩＤプロバイダーＩＤ又は異なるＩＤバージョンに対して重畳することができる。ＩＤプロバイダーＩＤは、ＩＤプロバイダーごとに異なり、そしてＩＤプロバイダーは、登録当局によって必要であると決定された場合には、複数のＩＤプロバイダーＩＤを登録することができる。
【０２０４】
ＩＤバージョンは、ＣＩＤを埋め込みそして読み取る技術／アルゴリズムのバージョンである。ＩＤバージョンは、エンベッダー及びリーダーによって常に知られている。というのは、それらが、どのアルゴリズムがＣＩＤを埋め込み又は読み取るか決定するからである。ＩＤプロバイダーは、それらが異なるＩＤバージョンをもつときに重畳するＣＩＤを有することができ、且つＣＩＤが重畳できるときに異なるＩＤバージョンを使用することができる。
【０２０５】
例えば、ビデオは、歌と同じＣＩＤを有してもよく、又はＩＤプロバイダー１によって埋め込まれた１つの歌は、ＩＤプロバイダー２（又は新たなＩＤバージョンを使用するＩＤプロバイダー１）により埋め込まれた異なる歌と同じＣＩＤを有してもよい。
【０２０６】
従って、ＣＩＤは、これらの他の変数と組み合わされない限りグローバルに独特ではない。従って、ＩＤＰｒｏｖｉｄｅｒＩＤ、ＩＤＶｅｒｓｉｏｎ及びＣＩＤを一緒に付加する（例えば、＜ＩＤＰｒｏｖｉｄｅｒＩＤ＞＜ＩＤＶｅｒｓｉｏｎ＞＜ＣＩＤ＞を付加する）ことにより生成される組み合せは、グルーバル一意ＩＤ、通常は、番号である。
【０２０７】
或いはまた、グルーバル一意組合せは、“ＣＭＤＳ：／／＜ＩＤＰｒｏｖｉｄｅｒＩＤ＞．＜ＩＤＶｅｒｓｉｏｎ＞．＜ＣＩＤ＞”としてフォーマットされたＵＲＩとして表すことができる。
【０２０８】
このフォーマットにおいてネームスペースを分割する効果は、２つある。（１）ＣＩＤを表すのに少数のビットしか必要としない。というのは、ＣＩＤを新たなコンテンツ又は新たなアルゴリズムバージョンに再使用できるからである。（２）システムは、ＥＰＣ、指紋、及び４Ｃ／Ｖｅｒａｎｃｅ  ＤＷＭのような既存のアイデンティティシステムと一体化し易い。というのは、ＣＩＤは、これらシステム間に重畳できるが、ＩＤバージョンとは区別されるからである。
【０２０９】
最終的に、多数の識別技術に対して、ＣＩＤは、整数であり、搬送及びバックエンド／ルーター処理にとって整数フィールドを使用することは最も効率的である。しかしながら、他の識別技術では、テキストフィールドが要求され、ルーターは、テキストを一意コンテンツ識別子へ処理することができる。従って、ＣＩＤフォーマットは、ＩＤバージョンデータにより決定され、ルーターにより適切に取り扱われる。それとは別に、これらの要求に対し、整数ＣＩＤについて１つと、テキストＣＩＤについて１つの、２つのＸＭＬ機構が存在する。もし可能であれば、整数フォーマットを使用するのが最適である。これらの方針に沿って、データベースは、全部で３つの識別子（ＩＤＰｒｏｖｉｄｅｒＩＤ、ＩＤＶｅｒｓｉｏｎ及びＣＩＤ）によりインデックスすることができる。というのは、ＣＩＤが整数フォーマットであるときには、個別変数又はデータベース或いは１つのデータベースがこのトリプレットＩＤをグルーバル一意インデックスとして使用できるからである。
【０２１０】
［登録インターフェイスの仕様］
登録プロセスは、コンテンツプロバイダーが一意ＣＩＤを得て、そのＣＩＤをＵＲＬにリンクできるようにする。また、ＩＤプロバイダー、コンテンツプロバイダー及びユーザが連絡先情報を登録できるようにもする。
【０２１１】
登録は、（ｉ）人間が読み取れる双方向のウェブインターフェイスと、（ii）売り主又はユーザのコンピュータで実行されるＣＩＤエンベッダー（又はユーザ登録のためのマルチメディアプラグイン）のような登録ソフトウェアと直接対話するウェブサービスインターフェイスと、の両方から行われる。
【０２１２】
［安全な認証されたチャンネル］
クライアントウェブ及びソフトウェアインターフェイスは、ルーターと共に安全な認証されたチャンネルを使用する。適切な売り主以外の誰もが登録データを変更できないように、このような保護が要求される。
【０２１３】
［コンテンツプロバイダー、ＩＤプロバイダー及びユーザの登録］
コンテンツプロバイダー及びＩＤプロバイダーは、これらのプロバイダー及び担当者が信頼性のあるプロバイダーであることを検証するプロセスを経て登録当局に最初に登録を行う。このプロセス中に、コンテンツプロバイダーには、一意売り主の名前及びパスワードが指定され、ＩＤプロバイダーには、一意番号ＩＤ及びパスワードが指定される。
【０２１４】
ＩＤプロバイダーには、次の理由で名前ではなく一意番号が指定される。ルーターが番号をルックアップするのは迅速であり、ＩＤプロバイダーのソフトウェアは、番号を覚え（従って、一意識別を思い出すために人間が読み取れることは重要ではなく）、また、ＩＤＰｒｏｖｉｄｅｒＩＤ、ＩＤＶｅｒｓｉｏｎ及びＣＩＤのグルーバル一意組合せは、番号である。
【０２１５】
コンテンツプロバイダー及びＩＤプロバイダーは、それらの売り主情報及びパスワードを受け取ると、それらのエンベッダーソフトウェアを経て、又は登録当局の双方向ウェブサイトと直接的に、それらの連絡先情報を更新することができる。
【０２１６】
ユーザは、ユーザ名及びパスワードを登録するリーダーソフトウェアを経て登録を行い、更に、将来の使用のためにパスワードを記憶するオプションをユーザに与えねばならない。リーダーソフトウェアは、ユーザ名を保持し、それを各解明要求と共に提出し、また、ユーザ名の送信を阻止するオプションをユーザに与える（１つの要求又は将来の全ての要求に対して）。換言すれば、この特定のシステムは、脱退(out-out)する能力を伴う加入(opt-in)システムである。
【０２１７】
［登録要求メッセージ］
登録要求メッセージは、データ登録のためにルーターへ送られるメッセージを定義するインターフェイスである。登録要求メッセージインターフェイスは、ＸＭＬヘッダ及び本体を含む。その実施例を以下に示すと共に、そのフォーマットについて以下に説明する。
【０２１８】
［登録要求ルートエレメント、サブエレメント及びグループ分け］
登録要求メッセージは、多数のオプションから１つのルートエレメントを選択し、次のものを含む。
CreateCID及びRegCID要求コードに対して<RegistrationCIDRequest>；
RegURL、DelURL、RegURLs、及びDelURLs要求コードに対して<RegistrationURLRequest>；及び
UpdateContentProvider、UpdateIDProvider、RegUser、及びUpdateUser要求コードに対して<RegistrationContactinfoRequest>
（整数及びテキストＣＩＤの取り扱いが終了したときには、より多くのルートエレメントが追加されてもよく、例えば、RegistrationIntCIDRequest及びRegistrationTextCIDRequest）サブエレメントもあり、次のものを含む。
メッセージヘッダに対して<Header>；
メッセージ本体に対して<Body>；及び
必要なときには<PrimaryInfo>及び<SecondaryInfo>
登録要求のグループ分けが許される（そして送信方法、例えば、ＳＯＡＰが終了したときには、以下に述べるように、それが指定されることが期待される）。
【０２１９】
［登録要求メッセージＸＭＬヘッダ］
ＸＭＬヘッダは、次の通りである。
【表３】
0005555271.tif 000008
【０２２０】
登録のための許容要求コードは、次のものを含む。
【表４】
0005555271.tif 000009
●このヘッダデータは、取り扱われるべき詳細なアクションに対してルーターが種々の要求ハンドラーへメッセージを迅速に配布する上で助けとなることができる。
●要求コードＲｅｇＵＲＬｓ及びＤｅｌＵＲＬｓは、１つのメッセージにおいて複数のＵＲＬを登録又は削除し、これは、登録ソフトウェアからの対話をあまり必要としないが、ルーターによるパージングを必要とする。
●多数の相互運用可能なリーダーがあるので、ＩＤプロバイダーがそれらのＩＤをコンテンツ内に埋め込むときにのケースのように、ＩＤプロバイダーＩＤ０−５１１が予約される。
【０２２１】
［登録要求メッセージＸＭＬ本体］
各要求コードに対して、解明メッセージＸＭＬ本体は、次の情報を含む。
【０２２２】
要求コード：CreateCID及びRegCID
ＸＭＬ本体は、登録要求に対してＣＩＤ関連変数を含む一次情報と、ＣＩＤに対して任意の記述データを含む二次情報とを有する。
【０２２３】
一次要求情報は、次の通りである。
【表５】
0005555271.tif 000010
●CIDExpirationフィールドは、コンテンツが長時間存在することがあるので、多大な注意を払って使用しなければならない。これは、新聞やカタログのように一時的なコンテンツに最も関連している。
【０２２４】
二次要求情報は、次の通りである。
【表６】
0005555271.tif 000011
【０２２５】
要求コード：RegURL、DelURL、RegURLs及びDelURLs
ＸＭＬ本体情報は、次の通りである。
【表７】
0005555271.tif 000012
【０２２６】
許容ＵＲＬ形式（このフィールドを含むすべての要求コードに対する）：
【表８】
0005555271.tif 000013
●ＵＲＬ変数は、ＵＲＬがデータベースに深くリンクできるようにする。
●RegURLsについては、Primary、URLType、URLVariable、URLActivation、URLExpiration、及びDescデータエレメントのリストが、セミコロン‘；’によって分離される。
○このフィールドは、ＵＲＬごとにエントリーを有するか（データなしのスペースがＯＫである）、又は全く使用されない。
●DelURL及びDelURLsについては、URLVariable、URLActivation、URLExpiration、及びDescのデータエレメントが任意であり、もし含まれれば、無視される。
●DelURLsについては、Primary、URLType、及びURLデータエレメントのリストがセミコロン‘；’により分離される。
○IDVersion及びCIDを含む他のフィールドは、一定のままである。
【０２２７】
ＵＲＬは、一次及び付加的なＵＲＬに分類され、ここで、ＵＲＬの形式ごとに１つの一次ＵＲＬがあると共に、望ましい数の付加的なＵＲＬがある。この分類は、ユーザに対する即座の再方向付けと、ユーザに対する全関連ＵＲＬ(即ち、付加的なアクション)の選択とを許す。換言すれば、一次ＵＲＬは、システムがユーザに対して一次ウェブサイトを自動的に表示できるようにし、従って、より多くの情報を受け取ることを選択した後にユーザが希望のＵＲＬをクリックする必要はない。必要なクリックの数を減少する間に、一次ＵＲＬも選択及び小売の機会を減少するので、バランスが取れる。
【０２２８】
要求コード：UpdateContentProvider、UpdateIDProvider、RegUser、及びUpdateUser
ＸＭＬ本体情報は、次の通りである。
【表９−１】
0005555271.tif 000014
【表９−２】
0005555271.tif 000015
●コントロールパネルにおけるウインドウズＸＰ“Region and LanguageOptions”からの国のリスト
●コントロールパネルにおけるウインドウズＸＰ“Region and LanguageOptions”からの言語のリスト
【０２２９】
［登録応答メッセージ］
登録応答メッセージは、データ登録に応答してルーターから送信されるメッセージを定義するインターフェイスである。この登録応答インターフェイスは、成功コード、ＵＲＬ及びＵＲＬの簡単な説明、又はエラーコード及び関連ＵＲＬ及び説明、並びにプライベートデータを含む。その例を以下に示し、そのフォーマットを以下に説明する。
【０２３０】
［登録応答ルートエレメント及びグループ分け］
全ての登録応答メッセージは、１つのルートエレメント<RegistrationResponse>（及び</RegistrationResponse>）を有し、サブエレメントはもたない。登録応用のグループ分けが許される（そして送信方法、例えば、ＳＯＡＰが終了したときに、それが指定されることが期待される）。
【０２３１】
［登録応答ＸＭＬメッセージ］
全ての要求に対する登録応答メッセージＸＭＬフォーマットは、次の通りである。
【表１０】
0005555271.tif 000016
●ＲｔｎＣｏｄｅの場合、“２”のようなエラーコードを将来定義して、システムがエラーを自動的に取り扱いできるようにしてもよい。このバージョンの場合、売り主又はユーザにエラーテキストを与えることで充分であり、従って、“１”が唯一のエラーコードである。
【０２３２】
［登録応答メッセージデータ］
一意ＩＤに対する要求（CreateCID）の場合に、メッセージは、RtnCodeフィールドにおける成功及びDescフィールドにおけるＣＩＤについて“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２３３】
他のシステムＩＤからＣＩＤを登録する要求（RegCID）の場合に、メッセージは、RtnCodeフィールドにおける成功について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２３４】
ＵＲＬを登録又は削除する要求（RegURL、DelURL、RegURLs、及びDelURLs）の場合に、メッセージは、RtnCodeフィールドにおける成功について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２３５】
コンテンツプロバイダー、ＩＤプロバイダー又はユーザ登録の要求（UpdateContentProvider、UpdateIDProvider、RegUser、及びUpsateUser）の場合に、メッセージは、RtnCodeフィールドにおける成功、及び任意の検証のためのDescフィールドにおけるRegName（例えば、ContentProviderName、IDProviderID、又はUserName）について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２３６】
［コンテンツプロバイダー表示］
コンテンツプロバイダーには、成功又はエラーが通知される。エラーの場合には、エラーテキスト及びＵＲＬを表示しなければならない。
【０２３７】
［解明インターフェイスの仕様］
解明アーキテクチャーは、リーダーをルーターに接続し、コンテンツ識別を使用して、ユーザに、関心のある関連データ及び購入機会を与えることができるようにする。
【０２３８】
解明インターフェイスは、ウェブサービスインターフェイスを使用する。
【０２３９】
［要求アドレスのための安全な認証されたチャンネル］
ウェブサービスインターフェイスは、ResRegAddress及びResResAddressに対し安全な認証されたチャンネルをルーターと共に使用する。この保護は、ルーターのスプーフィングを排除するために要求される。
【０２４０】
［解明要求メッセージ］
解明要求メッセージは、データルックアップのためにルーターへ送信されるメッセージを定義するインターフェイスである。この解明要求メッセージインターフェイスは、ＸＭＬヘッダ及び本体を含む。その例が示され、そのフォーマットが以下に説明される。
【０２４１】
［解明要求ルートエレメント、サブエレメント及びグループ分け］
解明要求メッセージは、２つのルートエレメント、即ちResURL及びResURLs要求コードに対する<ResolutionURLRequest>、並びにResRegAddress及びResResAddress要求コードに対する<ResolutionAddressRequest>、の１つを選択する。（整数及びテキストＣＩＤのハンドリングが終了したときには、より多くのルートエレメントが追加されてもよい。例えば、ResolutionURLintRequest及びResolutionURLtextRequest。）メッセージヘッダに対して<Header>、メッセージ本体に対して<Body>、及び必要な時には、<PrimaryInfo>及び<SecondaryInfo>を含むサブエレメントがある。登録要求のグループ分けが許される（そして、送信方法、例えば、ＳＯＡＰが終了したときには、それが指定されることが期待される）。グループ分けは、ＩＤプロバイダーリーダーが、コンテンツに埋め込まれた複数のＣＩＤ（例えば、コンテンツ所有者からの１つのＣＩＤ及びリテーラーからの１つのＣＩＤ）を読み取ることができるときに有用である。
【０２４２】
［解明要求メッセージＸＭＬヘッダ］
ＸＭＬヘッダは、登録要求の場合と同じである。このヘッダデータは、取り扱いされるべき詳細なアクションに対してルーターが種々の要求ハンドラーへメッセージを迅速に配布する上で助けとなる。
【０２４３】
解明に対する許容要求コードは、次のものを含む。
【表１１】
0005555271.tif 000017
【０２４４】
［解明要求メッセージＸＭＬ本体］
各要求コードに対して、解明メッセージＸＭＬ本体は、次の情報を含む。
【０２４５】
要求コード：ResURL、ResURLs、及びRes2ndInfo
これらの要求コードに対して、メッセージは、一次及び二次情報を含む。一次情報部分は、要求に適切に応じるのに必要なデータを含む。二次情報は、ユーザ特有のデータを含み、そしてユーザ特有のリンク並びに総計使用監視及び報告に意図される。
【０２４６】
二次情報を送信するときにはプライバシーの問題を考慮しなければならない。ユーザが二次情報を送信できるのが好ましい。
【０２４７】
一次要求情報は、次のものを含む。
【表１２】
0005555271.tif 000018
●プライベートデータは、例えば、イメージ又はオーディオの一部分を含むことができ、従って、サーバーは、埋め込まれたＣＩＤを検出することができる。バイナリーデータフォーマットは、ＩＤプロバイダーハンドラーによって知られ、好ましくは、バイナリーデータのヘッダに含まれねばならない。
【０２４８】
第２の要求情報は、次のものを含む。
【表１３】
0005555271.tif 000019
●リーダーＩＤは、ウェブサービス要求の無国籍性を排除し、有用な使用追跡を可能にする。これは、プライバシーの問題のため任意であり、ユーザによりターンオフできねばならない。
○これは、リーダーマシンから計算できるか、又は購入／アクチベーションコードを経て予め指定することができ、後者は、ＧＵＩＤを発生できない移動装置の場合に好ましいものである。
●トランザクションＩＤは、リーダーＩＤに基づく更なる追跡を与えると共に、ユーザによりターンオフすることもできる。
○これは、１でスタートして、そのリーダーにより各トランザクションをカウントする程度に簡単である。
●変数の前の“ｓ”は、それが二次情報であることを意味し、ユーザ登録なしに匿名のデータ総計を許すことに注意されたい。
○ユーザ名が含まれる場合には、これら“ｓ”変数のいずれも必要とされない。というのは、それらがユーザによって登録され、ルーターに記憶されるからである。
○sLanguageは、コントロールパネルにおけるウインドウズＸＰ「領域及び言語オプション」からの言語のリストを使用する。
○sCountryは、コントロールパネルにおけるウインドウズＸＰ「領域及び言語オプション」からの国のリストを使用する。
【０２４９】
従って、次のアクションが可能となる。
●総計使用の監視及び報告
●詳細な使用監視及びユーザ特有の解明応答に対して使用されるべきユーザに関する二次データ
【０２５０】
要求コード：ResRegAddress及びResResAddress
この要求コードの場合、メッセージは、次のものを含む。
【表１４】
0005555271.tif 000020
[解明応答メッセージ]
解明応答メッセージは、データルックアップに応答してルーターからのメッセージを定義するインターフェイスである。この解明応答インターフェイスは、成功コード、ＵＲＬ及びＵＲＬの簡単な説明、或いはエラーコード及び関連テキストを含む一次情報を有すると共に、コンテンツ特有のメタデータを与える二次情報を有する。その例は以下に示し、そのフォーマットは以下に説明する。
【０２５１】
［解明応答ルートエレメント、サブエレメント及びグループ分け］
全ての解明応答メッセージは、１つのルートエレメント<ResolutionResponse>（及び</ResolutionResponse>）と、サブエレメント<PrimaryInfo>及び<SecondaryInfo>とを有する。解明要求のグループ分けが許される（そして送信方法、例えば、ＳＯＡＰが終了したときに、それが指定されることが期待される）。グループ分けは、ＩＤプロバイダーリーダーが、コンテンツに埋め込まれた複数のＣＩＤ（例えば、コンテンツ所有者からの１つのＣＩＤ及びリテーラーからの１つのＣＩＤ）を読み取ることができるときに有用である。
【０２５２】
［解明応答ＸＭＬメッセージ］
全ての要求に対するＸＭＬ一次応答情報は、次の通りである。
【表１５】
0005555271.tif 000021
●ＲｔｎＣｏｄｅの場合、“２”のようなエラーコードを将来定義して、システムがエラーを自動的に取り扱いできるようにしてもよい。このバージョンの場合、売り主又はユーザにエラーテキストを与えることで充分であり、従って、“１”が唯一のエラーコードである（そして“０”及び“１”が唯一の有効なＲｔｎＣｏｄeである）。
●ＵＲＬ変数は、疑問符“？”の後に、ＸＭＬデータ（即ち、ＸＭＬタグ間の）として、或いはＸＭＬタグ＝データのようにフォーマットされたテキストとして、ＵＲＬに追加され、両方とも、ＸＭＬタグ間にコロン“；”をもつ。
○ＸＭＬデータの例＝<IDVersion>1</IDVersion>:CID=999<CID>999</CID>
○テキストの例＝IDVersion=1:CID=999
○従って、返送されるＵＲＬは、データベース内の深部を指すことができる。
●BizLogoURL及びBizTemplateURLは、それらがコンテンツプロバイダーにより登録された場合に要求され、要求コードは、ResURL、 ResURLs又はRes2ndInfoである。
○それらが登録されない場合には、それらは任意である。
【０２５３】
全ての要求に対するＸＭＬ二次応答情報は、Res2ndInfo要求コードに対して要求されるか、又はResponse2ndInfoフラグがセットされたときに要求される。
【表１６】
0005555271.tif 000022
【０２５４】
この二次情報は、ＣＩＤを登録するとき及びコンテンツプロバイダーを登録するときに含まれるデータの組合せから得られる。Res2ndInfoのためのフィールドが要求されるが、又はResponse2ndInfoフラグがセットされたときに、それらフィールドの多くは、登録時に任意であり、従って、要求されたときでも返送されない（又はブランクが返送される）ことがある。二次情報は、在庫代理店からの写真に対して望まれるような基本的アーチスト情報、及びおそらく全てのコンテンツに対して望まれるコンテンツプロバイダー情報をユーザが見られるようにする。
【０２５５】
［解明応答メッセージデータ］
ＵＲＬに対する要求（ResURL）の場合に、メッセージは、RtnCodeフィールドにおける成功、ＵＲＬフィールドにおける一次ＵＲＬ、DescフィールドにおけるＵＲＬの簡単な記述、及び要求された場合の二次情報について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。一次ＵＲＬは、一次フラグがセットされた状態で登録され、そして要求されたＩＤプロバイダーＩＤ、ＩＤバージョン、ＣＩＤ及びＵＲＬ形式に一致する。
【０２５６】
全てのＵＲＬに対する要求（ResURLs）の場合に、メッセージは、RtnCodeフィールドにおける成功、最初にリストされた一次ＵＲＬがＵＲＬフィールド内でセミコロン“；”により分離された全ＵＲＬのリスト、Descフィールド内でセミコロン“；”により分離されたＵＲＬの短い記述のリスト、及び要求された場合の二次情報について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。ＵＲＬは、全て、要求されたＩＤプロバイダーＩＤ、ＩＤバージョン、ＣＩＤ及びＵＲＬ形式に一致する。各ＵＲＬ形式に対して、一次ＵＲＬは１つしかなく、最初にリストされる。二次情報は、ＣＩＤにリンクされ、ＵＲＬにはリンクされないので、各フィールドに複数のアイテムをもつことはない。換言すれば、二次情報は、ＵＲＬと共に変化せず、ＣＩＤのみで変化する。
【０２５７】
二次情報の要求（Res2ndInfo）に場合に、メッセージは、RtnCodeフィールドにおける成功、及び対応するフィールドにおける二次情報について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２５８】
ルーターアドレスの要求（ResRegAddress及びResResAddress）の場合に、メッセージは、RtnCodeフィールドにおける成功、ＵＲＬフィールドにおけるローカルルーターのウェブまたはＩＰアドレスについて“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０２５９】
［ユーザディスプレイ］
一次ＵＲＬしか存在しない場合には、リーダーソフトウェアがウェブブラウザを一次ＵＲＬで起動し、一次ウェブページがユーザに対して「直ちに」表示されるようにする。これは、常に、ResURLで生じ、ResURLsで生じることもある。
【０２６０】
複数のＵＲＬを要求するときには、リーダーソフトウェアは、BizLogoURL及びBizTempleteURLフィールドがコンテンツプロバイダーにより登録された場合に、リンク及び記述をコンテンツプロバイダーのロゴ及びテンプレートと共に表示する。もしそうでなければ、リーダーは、その独占的なテンプレートを使用することができる。テンプレートは、どの二次ＣＩＤ情報（例えば、タイトル、版権、アダルトフラグコンテンツ形式、アーチスト情報、及びコンテンツプロバイダー会社情報）が表示されるかを定義する。テンプレートは、二次データに対する対応ＸＭＬタグ（＜＞間にある）を、このデータを表示するための変数として使用する。
【０２６１】
リーダーが常に接続される場合には、ＣＩＤを読み取り、二次情報（潜在的なキャッシングＵＲＬ）を要求し、次いで、<BizName>からより多くの情報が得られることをユーザに表示しなければならない。この解決策は、ユーザのより多くの情報の選択に対して即座に応答を生じさせて、ユーザがより多くの情報を選択し且つＵＲＬが登録されない機会を取り除く。更に、コンテンツが、複数のＣＩＤ、例えば、コンテンツ所有者からのＣＩＤ及びリテーラーからのＣＩＤを含む場合には、ユーザが情報ソースを区別できるようにもする。
【０２６２】
［ルーター要件］
次の要件は、ルーターシステムが適切に機能し、売り主及びユーザに価値を与えることができるようにする。
【０２６３】
［ＣＩＤ＆ＵＲＬ要件］
ルーターは、要求又は登録されたＣＩＤが所与のＩＤプロバイダーＩＤ及びＩＤバージョンに対して独特であることを保証する。要求されたＣＩＤの場合、発生アルゴリズムが一意ＩＤを保証しなければならない。登録されたＣＩＤの場合、システムは、データベースをチェックして、ＣＩＤがそのＩＤプロバイダーによってそのＩＤバージョンにまだ登録されていないことを確かめる。それが登録されている場合には、システムは、適当なエラーを返送しなければならない。
【０２６４】
ＵＲＬを登録するときには、システムは、要求側コンテンツプロバイダー名、ＩＤプロバイダーＩＤ及びＩＤバージョンによりＣＩＤが登録されたことをチェックする。もしそうでなければ、システムは、適当なエラーを返送しなければならない。
【０２６５】
ルーターは、ＩＤプロバイダーＩＤ、ＩＤバージョン及びＣＩＤが与えられると、ＵＲＬ形式ごとに１つの一次ＵＲＬしか登録されないことを保証する。
【０２６６】
データベースは、次のものを含む。
【０２６７】
●ＣＩＤが登録されたデータ(CIDRegData)及び最後に変更されたデータ(CIDModDate)
●ＵＲＬが登録されたデータ(URLRegData)及び最後に変更されたデータ(URLModDate)
【０２６８】
［ログファイル及び使用レポート］
ログファイルは、各要求に対して、プライベートデータを除いて、要求時間、応答遅延（ミリ秒）、要求ＩＰアドレス、及び登録又は解明ＸＭＬをセーブする。ログファイルは、少なくとも、先の６カ月に及ぶ。
【０２６９】
総計使用データは、ダウンロード又は自動ｅ−メールのために卓越した又は境界定めされた（タグ又はコンマ）テキストファイルへエクスポートする能力を伴う双方向の安全なウェブサイトを経て、登録されたＩＤプロバイダー及びコンテンツプロバイダーに見えねばならない。即座に見るか又はエクスポートするために、毎日、毎週及び毎月のレポートを自動的に発生しなければならない。毎月の使用レポートは、システムの寿命の間、保持しなければならず、また、毎日又は毎週のレポートは、２年間、保持しなければならない。
【０２７０】
レポートは、次のものを含む。
１．各コンテンツプロバイダーにより登録された各ＣＩＤに対し、並びに各ＩＤプロバイダー及び各コンテンツプロバイダーにより登録された全ＣＩＤに対し、要求された日付範囲について、
１．１．全ユーザ及び二次情報を送信するユーザに対し（登録されたユーザ及び匿名の二次情報を送信するユーザを含む）、
１．１．１．全成功リンク
１．１．２．日付（日付範囲における）当たりの総計リンク
１．１．３．２４時間周期で時間当りの総計リンク
１．１．４．週の日当たりの総計リンク
１．１．５．ＩＰアドレス当たりの総計リンク
１．１．６．平均応答時間
１．１．７．エラーコードでグループ分けされた全不成功リンク
１．２．二次情報を送信するユーザに対し、
１．２．１．リーダーＩＤ当たりの総計リンク（匿名ユーザをランク付けできる）
１．２．２．ユーザ名当たりの総計リンク（登録されたユーザをランク付けできる）
１．２．３．国当たりの総計リンク
１．２．４．郵便番号当たりの総計リンク
１．２．５．性別当たりの総計リンク
１．２．６．年齢当たりの総計リンク
１．２．７．グループ当たりの総計リンク
１．２．８．言語当たりの総計リンク
【０２７１】
レポートは、コンテンツプロバイダーがＣＩＤ特有の使用統計情報へアクセスできるようにする。
【０２７２】
年齢グループは、次のように定義される。
【表１７】
0005555271.tif 000023
【０２７３】
また、登録された売り主は、最近２年間の開始及び終了データを伴う慣習的なレポートも生成できねばならない。これら慣習的なレポートは、毎日のレポートを分析しなければならないので、計算に若干の時間を要する。システムは、慣習的なレポートが最近６カ月について以下のレポートリストに含まれないフィールドをもつのを許してもよい。これらのレポートは、ログファイルの分析を必要とするので、計算にある程度の時間を要する。
【０２７４】
［分散型アーキテクチャー］
ルーターの分散型アーキテクチャーが適切に機能し且つ将来拡張できるようにするために、次のことが行われる。
【０２７５】
リーダーは、登録及び／又は解明ルーターのウェブ又はＩＰアドレスを要求し、これらは、常に、毎週、適用できる。従って、システムアーキテクチャーは、毎週、動的に変更することができる。
【０２７６】
ミラールーターの数は、登録当局によりセットされる。ミラールーターは、全ての登録要求を中央ルーターへ直ちに転送し、そして情報が正しい（又はＣＩＤが独特である）というその応答を待機する。また、それらは、総計使用ファイルを中央ルーターへ送信し、中央データベースと毎日同期する。毎日の時間は送信されず、中央ルーターに全部が同時にヒットするのではない。最終的に、それらは、そのデータベースに存在しないＣＩＤに対する解明要求を転送し、そしてユーザに応答する前に応答を待機し、その最近の１日の間にそれらが登録されなかったことを確かめる。
【０２７７】
［ＸＭＬスキーマ］
ＸＭＬスキーマは、ほとんどの場合に、次のようにグループ分けされて（例えば、ＷＳＤＬ内で）、指定される。
●CreateCID及びRegCID要求コードに対する登録ＣＩＤ要求メッセージスキーマ
○整数について１つ及びテキストＣＩＤについて１つ
●RegURL、DelURL、RegURLs及びDelURLs要求コードに対する登録ＵＲＬ要求メッセージスキーマ
○整数について１つ及びテキストＣＩＤについて１つ
●UpdateContentProvider、UpdateIDProvider、RegUser及びUpdateUser要求コードに対する登録連絡先情報要求メッセージスキーマ
●全ての登録要求により使用される登録応答メッセージスキーマ
●ResURL、ResURLs及びRes２ndInfo要求コードに対する解明要求メッセージスキーマ
○整数について１つ及びテキストＣＩＤについて１つ
●ResRegAddress及びResResAddressを経ての要求ルーターアドレスについての解明要求メッセージスキーマ
●全ての解明要求により使用される解明応答メッセージスキーマ
【０２７８】
［パッキング及び送信方法］
ＸＭＬパッキング及び送信方法を指定する必要があり、これは、ｈｔｔｐ、ｈｔｔｐｓ、ＷＳＤＬ、ＳＯＡＰ、及び安全なウェブサービス、例えば、ＳＡＭＬ、ＷＳ−ライセンス又はＷＳ−セキュリティを含む。ＸＫＭＳ、Ｘ−ＫＲＳＳ及びＸ−ＫＩＳＳに述べられたようなパブリックキーアーキテクチャーは、おそらく必要とされない。というのは、この実施例は、コンテンツプロバイダー名及びパスワードを標準ＸＭＬメッセージインターフェイスの一部分として有し、そしてコンテンツデータがミッションクリティカルでないからである。
【０２７９】
重要なことに、ｈｔｔｐ又はｈｔｔｐｓリンクは、要求から応答まで維持され、応答が受け取られた後にのみ遮断されねばならず、従って、効率を高めると共に、ファイアウオールが応答と干渉するリスクを減少する（そしてクライアントエンベッダー又はリーダーソフトウェアがサーバーとして働くことを要求しない）。
【０２８０】
［データベースエレメント］
データベースエレメント及びおそらくその構成を説明することは、要求がどのように取り扱われるかの概略を与えるので、読者がインターフェイス及びルーターを理解する上で助けとなる。
【０２８１】
［データベースの管理］
データベースの管理が望まれ、次のものを含む。
●ＵＲＬを少なくとも月に一度はチェックする
○ＣＩＤを要求し且つ関連ＵＲＬを登録したコンテンツプロバイダーへデッドＵＲＬを報告する（担当者のｅ−メールを使用して）
・ＣＩＤ所有者情報を使用する
○一次ＵＲＬをもたず付加的なＵＲＬをもつＣＩＤをコンテンツプロバイダーへ報告する
・これは、ＵＲＬを全くもたないＣＩＤがまだ配布されていないか又はそのＵＲＬ形式に対して使用されていないと仮定する。
【０２８２】
［データベース情報］
一次データベースは、次の情報を含む。その構造は、表により示唆される必要はない。しかしながら、表は、分かり易い概略を与え、メッセージインターフェイスをどのように使用するか概念的に理解する上で助けとなる。
【０２８３】
［ＣＩＤ所有者情報］
【表１８】
0005555271.tif 000024
●この情報は、ＣＩＤを要求するとき（CreateCID）又は別のＩＤ規格から既存のＣＩＤを登録するとき（RegCID）、入力される。
○RegCIDに対するＣＩＤは、ＩＤプロバイダーＩＤ及びＩＤバージョンが与えられると、独特さについてチェックされる。
【０２８４】
［ＣＩＤリンク情報］
【表１９】
0005555271.tif 000025
●この情報は、ＵＲＬが登録又は削除されるとき（RegURL及びRegURLs、又はDelURL及びDelURLs）、各々、入力又は除去される。
○一次ＵＲＬをRegURLで登録するときには、各ＵＲＬ形式に対して１つの一次ＵＲＬしか登録されないことをチェックする（仕様書に述べられたように）。
●１つのデータベースがあってもよいし、多数のデータベースがあってもよい。
○各ＩＤプロバイダーＩＤ、又はＩＤプロバイダーＩＤ及びＩＤバージョンに対して異なるデータベースがあってもよい。
○データベースは、ＩＤプロバイダーＩＤ、ＩＤバージョン及びＣＩＤを１つのインデックスに結合できる。
・数字の組み合わせについて１つ（ＣＩＤが整数の場合）と、テキストの組合せについて１つ（ＣＩＤがテキストベースの場合）又はテキストインデックスを伴う１つのデータベース、の２つのデータベースが存在し得る。登録又は解明スキーマを使用して、どのデータベースを使用すべきか決定できる。効率のためには整数の組合せが最適である。
●フィールドが組み合わされてもよい。
○例えば、ＵＲＬ形式、ＵＲＬ及び説明を有するのではなく、FullURL、FullDesc、WAPURL、WAPDesc、WMIURL、WMIDesc、又はその組み合わせがあってもよい。
●データベースは、ＵＲＬ形式テキストを速度に対する整数に変換することができる。
○ＵＲＬ形式：Full＝１、WAP＝２、及びWMI＝３
【０２８５】
二次データベースは、次の情報を含む。
［コンテンツプロバイダー、ＩＤプロバイダー及びユーザ情報］
【表２０】
0005555271.tif 000026
●<RegName>は、ContentProviderName、IDProviderID、又はUserNameである。
●<type>は、各々、テキスト、整数、或いはコンテンツプロバイダー、ＩＤプロバイダー又はユーザデータベースのためのテキストである。
●ブールは、真＝１及び偽＝０で記憶することができる。
●性別は、女性＝真＝１及び男性＝偽＝０でブールとして記憶することができる。
【０２８６】
［登録メッセージの例］
［コンテンツＩＤを生成］
［要求メッセージ(CreateCID)］
<RegistrationCIDRequest>
<Header>
<Version>1</Version>
<IDProviderID>123</IDProviderID>
<RequestCode>CreateCID</RequestCode>
</Header>
<Body>
<PrimaryInfo>
<ContentProviderName>Disney</ContentProviderName>
<Password>walt4pres</Password>
<IDVersion>1</IDVersion>
</PrimaryInfo>
<SecondaryInfo>
<Title>Fantasia</Title>
<Copyright>1960</Copyright>
<AdultFlag>0</AdultFlag>
<ContentType>video-videotrack</ContentType>
<ArtistEmail>fantasia@disney.com</ArtistEmail>
</SecondaryInfo>
</Body>
</RegistrationCIDRequest>
［応答メッセージ(CreateCID)］
<RegistrationResponse>
<Version>1</Version>
<RtnCode>0</RtnCode>
<Desc>999</Desc>
</RegistrationResponse>
［既存のコンテンツＩＤを登録］
［要求メッセージ(RegCID)］
<RegistrationCIDRequest>
<Header>
<Version>1</Version>
<IDProviderID>321</IDProviderID>
<RequestCode>RegCID</RequestCode>
</Header>
<Body>
<PrimaryInfo>
<ContentProviderName>Apple</ContentProviderName>
<Password>1984year</Password>
<IDVersion>2</IDVersion>
<CID>111</CID>
</PrimaryInfo>
<SecondaryInfo>
<Title>Fantasia</Title>
<Copyright>1960</Copyright>
<AdultFlag>0</AdultFlag>
<ContentType>video-audiotrack</ContentType>
</SecondaryInfo>
</Body>
</RegistrationCIDRequest>
［応答エラーメッセージ(RegCID)］
<RegistrationResponse>
<Version>1</Version>
<RtnCode>1</RtnCode>
<URL>http://www.cmds.com/error/error8.html</URL>
<Desc> 
CID is already registered. Please verify the CID and ID 
Versionand try again.
</Desc>
</RegistrationResponse>
【０２８７】
［複数のＵＲＬを登録］
１つのＵＲＬをRegURLで登録することは、非常に良く似ているが、Primary、URLType、 URL、 URLVariables、 URLActivation、 URLExpiration及びDescフィールドには、１つのデータエレメントしかない。或いはまた、複数のRegURLコールを送信においてグループ分けすることにより複数のＵＲＬを登録することもできる。１つ以上のＵＲＬをDelURL又はDelURLsで削除することは、非常に良く似ているが、URLVariables、 URLActivation、 URLExpiration及びDescは、任意であり、もし含まれる場合には、無視される。RegURLに関しては、DelURLにおいて、ＵＲＬ  ＸＭＬフィールドには１つのＵＲＬしか含まれない。
【０２８８】
［要求メッセージ(RegURLs)］
<RegistrationURLRequest>
<Header>
<Version>1</Version>
<IDProviderID>123</IDProviderID>
<RequestCode>RegURLs</RequestCode>
</Header>
<Body>
<ContentProviderName>Disney</ContentProviderName>
<Password>walt4pres</Password>
<IDVersion>1</IDVersion>
<CID>999</CID>
<Primary>1;1;0;0;0;0</Primary>
<URLType>Full;WAP;Full;WAP;Full;WAP</URLType>
<URL>
www.disney.com/fantasia; 
wap.disney.com/fantasia; 
www.disney.com/fantasia/music; 
wap.disney.com/fantasia/music;
www.amazon.com/search?fantasia;
wap.amazon.com/search?fantasia;
</URL>
<URLVariables>
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
IDProviderID:IDVersion:CID:ReaderID:OS:Username;
</URLVariables>
<Desc>
Fantasia movie info from Disney.com;
Fantasia movie info from Disney.com (WAP Format);
Fantasia music info from Disney.com;
Fantasia music info from Disney.com (WAP Format);
Fantasia memorabilia from Amazon.com;
Fantasia memorabilia from Amazon.com (WAP format);
</Desc>
</Body>
</RegistrationURLRequest>
［応答メッセージ(RegURLs)］
<RegistrationResponse>
<Version>1</Version>
<RtnCode>0</RtnCode>
</RegistrationResponse>
【０２８９】
［ユーザを登録］
コンテンツプロバイダー、ＩＤプロバイダー又はユーザの更新は、ユーザの登録に非常に良く似ているが、名前及びパスワードは、独特さについてチェックされるのではなく、既に指定されている。更に、ユーザは、ビジネス情報を入力する必要がない。
【０２９０】
［要求メッセージ(RegUser)］
<RegistrationContactInfoRequest>
<Header>
<Version>1</Version>
<IDProviderID>123</IDProviderID>
<RequestCode>RegUser</RequestCode>
</Header>
<Body>
<RegName>klevy</RegName>
<Password>ken1sgreat</Password>
<BizName>AIPL</BizName>
<BizEmail>levy@aipl.com</BizEmail>
<BizAddress1>110NE Cedar Street</BizAddress1>
<BizCity>Stevenson</BizCity>
<BizState>WA</BizState>
<BizZip>98648</BizZip>
<BizCountry>USA</BizCountry>
<BizPhone>509-427-5374</BizPhone>
<BizURL>www.AIPL.com</BizURL>
<NameFirst>Ken</NameFirst>
<NameLast>Levy</NameLast>
<Email>levy@aipl.com</Email>
<Address1>110 NECedar Street</Address1>
<City>Stevenson</City>
<State>WA</State>
<Zip>98648</Zip>
<Country>USA</Country>
<Cell>509-427-5374</Cell>
<Language>English</Language>
<Sex>M</Sex>
<Age>40</Age>
</Body>
</RegistrationContactInfoRequest>
【０２９１】
［応答メッセージ(RegUser)］
最初に、ユーザは、ユーザ名“klevy”が存在するので、エラーを受け取る。
<RegistrationResponse>
<Version>1</Version>
<RtnCode>1</RtnCode>
<URL>http://www.cmds.com/error/error6.html</URL>
<Desc> 
ユーザ名は、予め登録される。
異なるユーザ名もトライしてみる。
</Desc>
</RegistrationResponse>
【０２９２】
次いで、ユーザ名"kenlevy"で再トライし、成功となる。
<RegistrationResponse>
<Version>1</Version>
<RtnCode>0</RtnCode>
<Desc>kenlevy</Desc>
</RegistrationResponse>
【０２９３】
［解明メッセージの例］
［ＵＲＬを解明］
１つのＵＲＬを解明することは、非常に良く似ており、唯一の変化は、１つのＵＲＬが応答メッセージにおいて返送されることである。
【０２９４】
［要求メッセージ(ResURLs)］
<ResolutionURLRequest>
<Header>
<Version>1</Version>
<IDProviderID>123</IDProviderID>
<RequestCode>ResURLs</RequestCode>
</Header>
<Body>
<PrimaryInfo>
<Timestamp>2005-04-14T13:20:00Z</Timestamp>
<IDVersion>1</IDVersion>
<CID>999</CID>
<URLType>Full</URLType>
<Response2ndInfo>TRUE</Response2ndInfo>
</PrimaryInfo>
<SecondaryInfo>
<ReaderID>789</ReaderID>
<TransactionID>235</TransactionID>
<OS>Windows</OS>
<Username>kenlevy</Username>
</SecondaryInfo>
</Body>
</ResolutionURLRequest>
［応答メッセージ(ResURLs)］
<ResolutionResponse>
<PrimaryInfo>
<Version>1</Version>
<RtnCode>0</RtnCode>
<URL>
www.disney.com/fantasia?
IDProviderID=123:IDVersion=1:CID=999:
ReaderID=789:ReaderID=789:OS=Windows:
Username=kenlevy; 
www.disney.com/fantasia/music?
IDProviderID=123:IDVersion=1:CID=999:
ReaderID=789:ReaderID=789:OS=Windows:
Username=kenlevy; 
www.amazon.com/search?fantasia?
IDProviderID=123:IDVersion=1:CID=999:
ReaderID=789:ReaderID=789:OS=Windows:
Username=kenlevy; 
</URL>
<Desc>
Fantasia movie info from Disney.com;
Fantasia music info from Disney.com;
Fantasia memorabilia from Amazon.com;
</Desc>
<BizLogoURL>disney.com/CMDS/logo.jpg</BizLogoURL>
<BizTemplateURL>disney.com/CMDS/template</BizTemplateURL>
</PrimaryInfo>
<SecondaryInfo>
<Title>Fantasia</Title>
<Copyright>1960</Copyright>
<AdultFlag>0</AdultFlag>
<ContentType>video-videotrack</ContentType> 
<ArtistEmail>fantasia@disney.com</ArtistEmail>
<BizName>Disney</BizName>
<BizURL>www.disney.com</BizURL>
</SecondaryInfo>
</ResolutionResponse>
【０２９５】
［ルーターアドレスを解明］
登録ルーターアドレスの要求は、非常に類似しており、要求コードしか変化しない。
【０２９６】
［要求メッセージ(ResResAddress)］
<ResolutionAddressRequest>
<Header>
<Version>1</Version>
<IDProviderID>123</IDProviderID>
<RequestCode>ResResAddress</RequestCode>
</Header>
<Body>
<Timestamp>2005-04-14T13:20:00Z</Timestamp>
<ReaderIP>206.58.236.61</ReaderIP>
</Body>
</ResolutionAddressRequest>
［応答メッセージ(ResResAddress)］
<ResolutionResponse>
<PrimaryInfo>
<Version>1</Version>
<RtnCode>0</RtnCode>
<URL>198.70.207.6/CMDS/cgi_bin</URL>
</PrimaryInfo>
</ResolutionResponse>
【０２９７】
［エラーテキストの例］
幾つかのエラーテキストの例は、次のものを含む。
１．“コンテンツはデータベースに登録されるが、ＵＲＬは登録されない。<BizEmail>において<ContentProviderName>に連絡されたい。”
２．“コンテンツは登録されるが、ＵＲＬはインアクティブとしてマークされる。<ContentProviderName>に連絡されたい。”
３．“コンテンツに一致するレコードがデータベースにない。<BizEmail>において<ContentProviderName>に連絡されたい。”
４．“要求フォーマットエラー−不完全なデータ。ソフトウェアプロバイダーに連絡されたい。”
５．“一次ＵＲＬは既に登録された。再びトライして、特に、Primary及びIDVersionについて設定を照合されたい。”
６．“Usernameは既に登録された。異なるusernameにトライされたい。”
７．“パスワードが有効なフォーマットでない。ある番号を伴う少なくとも６個のキャラクタであることが必要である。再びトライされたい。”
８．“ＣＩＤは既に登録された。ＣＩＤ及びＩＤバージョンを検証し、そして再びトライされたい。”
９．“ＣＩＤは、登録されない。コンテンツプロバイダー名、ＩＤバージョン及びＣＩＤを検証されたい。”
１０．“コンテンツが古いので、ＣＩＤは満了となる。”
【０２９８】
このシステムは、非常に融通性があり、複数の将来の可能性を考えることができる。その改善は、（１）複数のＩＤシステムをシードし、合体し、（２）非合法的コンテンツに対する「今買う(buy now)」リンクを可能にすることを含む。別の改善は、複数のＩＤプロバイダー技術又はキャッシュ型ルーターを一体化することを含む。
【０２９９】
［複数のＩＤシステムのシード及び合体］
メッセージの将来のバージョン（例えば、バージョンＸＭＬヘッダタグに数字“２”を伴う）において、次のステップは、このシステムが複数のＩＤシステムをシードし合体できるようにする。
１．登録要求コードを追加して、ＣＩＤにリンクされた他のＩＤを登録する
２．解明要求コードを追加して、他のコードを返送する
３．解明要求コードを追加して、他のＩＤが与えられると、ＣＩＤを返送する
【０３００】
他のＩＤが返送されたときでも、受信側ソフトウェアは、ソフトウェアの１つの断片から複数のシステムをシードできるようにするために他のＩＤを各独占的システムにどのように登録するか知る必要がある。
【０３０１】
［登録要求メッセージ］
特に、次の要求コードは、登録メッセージのバージョン２に追加することができる。
【０３０２】
要求コード：RegOtherIDs
【表２１−１】
0005555271.tif 000027
【表２１−２】
0005555271.tif 000028
【０３０３】
［登録応答メッセージ］
他のシステムＩＤを登録する要求(RegOtherIDs)の場合に、メッセージは、RtnCodeフィールドにおける成功について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０３０４】
［解明要求メッセージ］
次の解明要求コードを、それに対応する応答データと共に追加することができる。
【０３０５】
要求コード：ResCIDGivenOtherID
この要求は、ResURLで使用したものと同じフォーマットを使用するが、ＣＩＤ  ＸＭＬフィールドは、他のＩＤデータを含む（ＣＩＤは返送される）。
【０３０６】
要求コード：ResOtherIDs
この要求は、一次情報を含み、RegOtherIDsの場合と同じデータを使用するが、コンテンツプロバイダーＩＤ及びパスワードＸＭＬタグは、任意である。更に、上述したResURL要求コードからのタイムスタンプＸＭＬタグは、要求されたフィールドとして含まれる。
【０３０７】
［解明応答メッセージ］
別の一意ＩＤが与えられてＣＩＤを要求する場合（ResCIDGivenOtherID）、メッセージは、RtnCodeフィールドにおける成功、DescフィールドにおけるＣＩＤ、及び二次情報について“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０３０８】
他の一意ＩＤを要求する場合（ResOtherIDs）、メッセージは、RtnCodeフィールドにおける成功、及びセミコロン“；”で分離された各エントリーをもつ登録された他のＩＤのリストであって、フォーマットの各エントリーが、Descフィールド内でコロン“：”により分離されたRegOtherIDs要求コード及び関連ＩＤについて定義された他のシステムＸＭＬタグと、要求された場合の対応フィールドにおける二次情報とで構成されるようなリストについて“０”を返送するか、又はRtnCodeにおけるエラー、ＵＲＬフィールドにおけるエラーＵＲＬ、及びDescフィールドにおけるエラーテキストについて“１”を返送する。
【０３０９】
［データベースエレメント］
対応するデータベースエレメントは、次の通りである。
【０３１０】
［一意ＩＤシステムデータベース］
【表２２】
0005555271.tif 000029
【０３１１】
［非合法的コンテンツに対する「今買う(Buy Now)」］
マルチメディアプレーヤが生のコンテンツ（即ち、暗号化もされず、デジタルサインも入れられていない）を演奏又は転送しようとするときは、ＣＩＤをチェックすると共に、コンテンツがコピー保護されるかどうかチェックするために、リーダープラグインをコールする。この生のコンテンツがコピー保護され、ＣＩＤを含む場合には、説明及び「今買う」リンクをユーザに与えることができる。
【０３１２】
ＣＩＤの存在は、コンテンツを演奏できないことを必ずしも意味しないことに注意されたい。というのは、コンシューマが、購入したＣＤを圧縮されたオーディオに変換するか又は非暗号化コンテンツを買うことがあるからである。コンテンツは、コピー保護識別子、例えば、ＤＷＭペイロードのようなコンテンツＩＤにおけるコピーコントロール情報（ＣＣＩ）を有することも必要である。プレーヤは、この事象をログすることができ、従って、生のコンテンツを一度チェックするだけでよい。
【０３１３】
ＵＲＬにリンクされた権利のフラグを含ませることにより、既存の登録要求を使用して１つの一次権利ＵＲＬを登録できると共に、権利ＵＲＬをリーダーへ返送して、合法的コンテンツを購入するための「今買う」リンクを与えることができる。より詳細には、権利フラグは、登録及び解明メッセージにおける付加的なＸＭＬフィールドであり、そしてＵＲＬと共にデータベースエレメントに含まれる。
【０３１４】
［ユニバーサルリーダーインターフェイス］
コンテンツ所有者及びリテーラーが両方ともコンテンツプロバイダーとして行動し、従って、両方がコンテンツをそれら自身のＣＩＤでマークするときには、ユーザは、コンテンツ所有者から１つ及びリテーラーから１つ、の２つの異なる「より多くの情報」ボタンを見る。ＩＳＰのようなディストリビュータから付加的な「より多くの情報」ボタンがあってもよい。
【０３１５】
登録当局は、将来、異なるＩＤプロバイダー検出器からのＣＩＤ及びＵＲＬを一体化するユニバーサルリーダーインターフェイスを与えるプラグインを提供する。この実施例は、一般的なリーダープラグインとＩＤプロバイダー検出器との間のインターフェイスである標準的なリーダーアプリケーションインターフェイスを含むように拡張することができる。従って、インストールされた全てのＩＤ技術検出器は、一般的リーダープラグインをコールすることができ（又はそこからコールされ）、そして全てのＣＩＤがその一般的リーダープラグインからルーターへ送信される。
【０３１６】
この一般的リーダープラグインに対してインターフェイスを指定するだけでなく、登録当局は、全てのマルチメディアプレーヤに対して配布するためにプラグインを与えねばならない。一般的プラグインは、ＩＤプロバイダープラグインがそれらの解明要求ＸＭＬメッセージでそれをコールさせ、次いで、１つの「より多くの情報」ボタンをユーザに対して表示し、そして最終的に、検出された全てのＣＩＤに対する要求をルーターへ送信させることができる。この解決策は、ＩＤプロバイダープラグインがそれらのコールをＩＰアドレスから内部ＤＬＬへ変更し、それらのユーザ表示を除去することしか要求しない。
【０３１７】
［キャッシュ型ルーター］
このアーキテクチャーは、ミラールーターが解明要求に対してキャッシュ型ルーターへリンクできるようにする。キャッシュ型ルーターは、登録要求には適用できない。というのは、これらの要求は、頻繁に発生することも繰り返し発生することもなく、中央ルーターへ即座に転送されるからである。これらのキャッシュ型ルーターは、最近の解明要求に対してそれらのキャッシュ型データベースを一時的に維持する。データは、登録当局によりセットされた時間限界を有することが期待される。また、キャッシュ型ルーターは、それらのリンクされたミラールーターへ使用情報を毎日送信する。このアーキテクチャーは、真に分散型で効率の良いものとなる。
【０３１８】
［付加的な発明の組合せ］
付加的な発明の組合せは、次の通りである。
【０３１９】
Ａ１．コンテンツオブジェクトをメタデータに関連付ける方法において、
コンテンツ識別子のセットの中からコンテンツオブジェクトのためのコンテンツ識別子を受け取るステップと、
前記コンテンツ識別子のセットに対して一意境界識別子を与えるステップと、
前記コンテンツ識別子及び前記一意境界識別子の組合せを使用して、前記コンテンツオブジェクトに対するグルーバル一意識別子を形成するステップと、
前記グルーバル一意識別子をメタデータソースに関連付け、前記グルーバル一意識別子を前記メタデータソースへ供給するエンティティのルーティングを可能にするステップと、
を備える方法。
【０３２０】
Ａ２．グルーバル一意識別子をメタデータソースに関連付ける前記ステップは、別のネットワーク位置に位置するメタデータソースを識別するメタデータソース識別子を記憶することを含む、請求項Ａ１に記載の方法。
【０３２１】
Ａ３．前記メタデータソース識別子は、メタデータソースのＵＲＬを含む、請求項Ａ２に記載の方法。
【０３２２】
Ａ４．前記コンテンツ識別子のセットは、ＩＤプロバイダーにより予め指定され、そして前記一意境界識別子を前記コンテンツ識別子のセットに与えることによりディレクトリに登録される、請求項Ａ１に記載の方法。
【０３２３】
Ａ５．ディレクトリは、前記コンテンツオブジェクトに対するコンテンツ識別子と、前記ＩＤプロバイダーに対する一意境界識別子との両方を指定し、そして前記コンテンツ識別子をＩＤプロバイダーに与えて前記コンテンツ識別子を前記コンテンツオブジェクトに挿入するようにする、請求項Ａ１に記載の方法。
【０３２４】
Ａ６．前記ディレクトリは、前記一意境界識別子を使用して、前記コンテンツ識別子を決定する、請求項Ａ５に記載の方法。
【０３２５】
Ａ７．コンテンツ識別子の第１セットは、第１のＩＤプロバイダーにより予め指定され、そして第１の一意境界識別子を前記コンテンツ識別子の第１セットに与えることによりディレクトリに登録され、更に、前記ディレクトリは、第２のＩＤプロバイダーに対するコンテンツ識別子の第２セットを指定し、次いで、この第２のＩＤプロバイダーが前記コンテンツ識別子の第２セットをそれに対応するコンテンツオブジェクトに挿入する、請求項Ａ１に記載の方法。
【０３２６】
Ａ８．前記一意境界識別子は、ＩＤプロバイダー識別子を含む、請求項Ａ１に記載の方法。
【０３２７】
Ａ９．前記一意境界識別子は、ＩＤバージョンを更に含む、請求項８に記載の方法。
【０３２８】
Ａ１０．前記コンテンツ識別子及び一意境界識別子の組合せがユーザによりディレクトリに与えられ、次いで、このディレクトリは、前記コンテンツオブジェクトに対する前記グルーバル一意識別子に関連したメタデータソースへユーザをルーティングする、請求項Ａ１に記載の方法。
【０３２９】
Ａ１１．前記メタデータソースは、前記コンテンツオブジェクトのコンテンツプロバイダーにより与えられ、そして前記コンテンツプロバイダーのメタデータへの少なくとも第１リンク、及び別の参加者のメタデータへの少なくとも第２リンクとして表される、請求項Ａ１に記載の方法。
【０３３０】
Ａ１２．前記別の参加者のメタデータは、前記コンテンツオブジェクトに関係したオンライン商取引トランザクション機会へのリンクを含む、請求項Ａ１１に記載の方法。
【０３３１】
Ａ１３．前記コンテンツプロバイダーは、コンテンツオブジェクトのコンテンツ所有者である、請求項Ａ１１に記載の方法。
【０３３２】
Ａ１４．前記コンテンツオブジェクトは、第２の、異なるメタデータソースに関連付けられ、前記方法は、
コンテンツ識別子の第２セットの中から前記コンテンツオブジェクトのための第２コンテンツ識別子を受け取るステップと、
前記コンテンツ識別子の第２セットに対して第２の一意境界識別子を与えるステップと、
前記第２コンテンツ識別子及び前記第２の一意境界識別子の第２の組合せを使用して、前記コンテンツオブジェクトに対する第２のグルーバル一意識別子を形成するステップと、
前記第２のグルーバル一意識別子をメタデータソースに関連付け、前記グルーバル一意識別子を前記メタデータソースへ供給するエンティティのルーティングを可能にするステップと、
を備える、請求項Ａ１に記載の方法。
【０３３３】
Ａ１５．請求項Ａ１に記載の方法を遂行するためのインストラクションが記憶されたコンピュータ読み取り可能なメディア。
【０３３４】
Ａ１６．コンテンツオブジェクトをメタデータに関連付けるためのシステムにおいて、
コンテンツ識別子のセットの中からコンテンツオブジェクトに対するコンテンツ識別子を受け取り、前記コンテンツ識別子のセットに対する一意境界識別子を与える登録インターフェイスと、
前記コンテンツ識別子及び前記一意境界識別子の組合せを使用して、前記コンテンツオブジェクトに対するグルーバル一意識別子を形成し、更に、前記グルーバル一意識別子をメタデータソースに関連付けて、前記グルーバル一意識別子を前記メタデータソースへ供給するエンティティのルーティングを可能にするように動作できるデータベースと、
を備えるシステム。
【０３３５】
Ａ１７．コンテンツ識別子を受け取り、それに応答して、そのコンテンツ識別子に組み合わせて境界識別子を使用して、データベースにおける対応メタデータソースをルックアップするように動作できるルーターを更に備える、請求項Ａ１６に記載のシステム。
【０３３６】
Ａ１８．前記ルーターは、メタデータソース識別子を要求側エンティティに与え、次いで、このエンティティは、前記メタデータソース識別子を使用して、メタデータソースとの接続を確立すると共に、コンテンツオブジェクトに関連したメタデータを得る、請求項Ａ１７に記載のシステム。
【０３３７】
Ｂ１．コンテンツオブジェクトを２つ以上の異なるメタデータソースに関連付ける方法において、
コンテンツオブジェクトに対するグルーバル一意異なる識別子を登録するステップであって、これらグルーバル一意異なる識別子の各々は、コンテンツオブジェクトと共に与えられるコンテンツ識別子と、コンテンツ識別子がメンバーであるところのコンテンツ識別子のセットを識別する境界識別子とを含むものであるステップと、
前記グルーバル一意識別子の各々に対して、メタデータソースに関する情報を維持するステップと、
前記コンテンツオブジェクトに対して第１のコンテンツ識別子を受け取るステップと、
前記第１のコンテンツ識別子のセットに関連した境界識別子を使用して、前記第１のコンテンツ識別子に対する前記グルーバル一意識別子を決定するステップと、
ユーザを、前記グルーバル一意識別子に関連したメタデータソースへルーティングするステップと、
を備える方法。
【０３３８】
Ｂ２．前記コンテンツ識別子は、異なるリーダーを使用して前記コンテンツオブジェクトから導出される、請求項Ｂ１に記載の方法。
【０３３９】
Ｂ３．前記異なるリーダーは、異なるコンテンツ識別方法を使用してコンテンツ識別子を導出する、請求項Ｂ２に記載の方法。
【０３４０】
Ｂ４．前記異なるリーダーは、コンテンツオブジェクトの異なる属性を使用してコンテンツ識別子を導出する、請求項Ｂ２に記載の方法。
【０３４１】
Ｂ５．前記異なる属性は、異なる形式の埋め込まれた補助データを含む、請求項Ｂ４に記載の方法。
【０３４２】
Ｂ６．前記埋め込まれた補助データの形式の１つは、デジタル透かしを含む、請求項Ｂ５に記載の方法。
【０３４３】
Ｂ７．前記異なる属性は、第１のデジタル透かしに対応する第１属性と、第２のデジタル透かしに対応する第２の属性とを含む、請求項Ｂ４に記載の方法。
【０３４４】
Ｂ８．前記異なる属性は、異なるデジタル透かし又は健全なハッシュが導出されるところの属性を含む、請求項Ｂ４に記載の方法。
【０３４５】
Ｂ９．前記異なる属性は、コンテンツオブジェクトのインバンド及びアウトオブバンド属性を含み、インバンドは、人間が知覚するようにレンダリングされるコンテンツを指し、そしてアウトオブバンドは、コンテンツオブジェクトにおいて搬送されるが、人間が知覚するようにレンダリングされるコンテンツの部分を形成しない補助データを指す、請求項Ｂ４に記載の方法。
【０３４６】
Ｂ１０．前記第１コンテンツ識別子のセットは、前記第１コンテンツ識別子を与えるのに使用されるリーダーにより決定され、前記コンテンツオブジェクトは、異なるリーダーによって各々読み取りできる２つ以上のコンテンツ識別子を有する、請求項Ｂ１に記載の方法。
【０３４７】
Ｂ１１．前記コンテンツ識別子は、コンテンツオブジェクトの異なる部分を使用してコンテンツオブジェクトから導出される、請求項Ｂ１に記載の方法。
【０３４８】
Ｂ１２．前記部分は、コンテンツオブジェクトにおける知覚コンテンツの異なるインバンド部分である、請求項Ｂ１１に記載の方法。
【０３４９】
Ｂ１３．ある部分は、コンテンツオブジェクトにおけるインバンドであり、そして別の部分は、アウトオブバンドである、請求項Ｂ１１に記載の方法。
【０３５０】
Ｂ１４．前記第１のコンテンツ識別子及び前記メタデータソースは、コンテンツプロバイダーにより与えられ、そしてコンテンツプロバイダーのメタデータへのリンクを備え、更に、第２のコンテンツ識別子及び第２のメタデータソースもあって、これらは、第２の参加者のメタデータへリンクする第２の参加者によって与えられる、請求項Ｂ１に記載の方法。
【０３５１】
Ｂ１５．前記第２の参加者はリテーラーであり、前記第２の参加者のメタデータは、オンライン商取引機会を含む、請求項１４に記載の方法。
【０３５２】
Ｂ１６．前記コンテンツプロバイダーは、コンテンツ所有者である、請求項Ｂ１４に記載の方法。
【０３５３】
Ｂ１７．請求項Ｂ１に記載の方法を遂行するためのインストラクションが記憶されたコンピュータ読み取り可能なメディア。
【０３５４】
Ｂ１８．コンテンツオブジェクトを２つ以上の異なるメタデータソースに関連付けるシステムにおいて、
コンテンツオブジェクトに対するグルーバル一意異なる識別子を登録するディレクトリであって、これらグルーバル一意異なる識別子の各々は、コンテンツオブジェクトと共に与えられるコンテンツ識別子と、コンテンツ識別子がメンバーであるところのコンテンツ識別子のセットを識別する境界識別子とを含むものであるディレクトリと、
前記グルーバル一意識別子の各々に対して、メタデータソースに関する情報を維持するデータベースと、
前記コンテンツオブジェクトに対して第１のコンテンツ識別子を受け取るルーターであって、前記第１のコンテンツ識別子のセットに関連した境界識別子を使用して、前記第１のコンテンツ識別子に対する前記グルーバル一意識別子を決定すると共に、ユーザを、前記グルーバル一意識別子に関連したメタデータソースへ方向付けするように動作するルーターと、
を備えるシステム。
【０３５５】
Ｂ１９．異なるエンティティが異なるメタデータソースをコンテンツオブジェクトに関連付けできるようにするメタデータディレクトリ方法において、
異なるＩＤプロバイダー識別子を異なるＩＤプロバイダーに指定し、そして異なるＩＤプロバイダーがコンテンツ識別子の対応セットをコンテンツオブジェクトに指定できるようにして、コンテンツ識別子のセットが潜在的に競合するコンテンツ識別子を含むようにすることにより、異なるコンテンツＩＤプロバイダーを登録するステップと、
コンテンツ識別子を登録するステップであって、コンテンツ識別子を対応するメタデータソースに関連付けることを含むステップと、
を備える方法。
【０３５６】
Ｂ２０．第１のコンテンツオブジェクトに関連した第１のコンテンツ識別子を受け取るステップと、
第１のコンテンツ識別子に関連したＩＤプロバイダー識別子を決定するステップと、
前記第１のコンテンツ識別子及びＩＤプロバイダーを使用して、対応する第１のメタデータソースを決定するステップと、
前記第１のメタデータソースを設け、前記第１のコンテンツオブジェクトを有する要求側エンティティと、前記第１のメタデータソースとの間を接続できるようにするステップと、
を更に備える請求項Ｂ１９に記載の方法。
【０３５７】
Ｂ２１．メタデータソースプロバイダーを登録するステップを更に備え、その各々のプロバイダーは、対応する１つ以上のメタデータソースを設けると共に、コンテンツオブジェクトをメタデータソースプロバイダーのメタデータソースに関連付ける権利を有する、請求項Ｂ１９に記載の方法。
【０３５８】
Ｂ２２．前記異なるコンテンツＩＤプロバイダーは、異なるコンテンツ識別方法を使用する、請求項Ｂ１９に記載の方法。
【０３５９】
Ｂ２３．請求項Ｂ１９に記載の方法を遂行するためのインストラクションが記憶されたコンピュータ読み取り可能なメディア。
【０３６０】
Ｂ２４．異なるエンティティが異なるメタデータソースをコンテンツオブジェクトに関連付けできるようにするメタデータディレクトリシステムにおいて、
異なるＩＤプロバイダー識別子を異なるＩＤプロバイダーに指定し、そして異なるＩＤプロバイダーがコンテンツ識別子の対応セットをコンテンツオブジェクトに指定できるようにして、コンテンツ識別子のセットが潜在的に競合するコンテンツ識別子を含むようにすることにより、異なるコンテンツＩＤプロバイダーを登録するように動作できる登録インターフェイスを備え、
前記登録インターフェイスは、コンテンツ識別子を登録するようにも動作でき、これは、コンテンツ識別子を対応するメタデータソースに関連付けることを含む、システム。
【０３６１】
Ｂ２５．第１コンテンツオブジェクトに関連した第１コンテンツ識別子を受け取り、その第１コンテンツ識別子に関連したＩＤプロバイダー識別子を決定し、前記第１コンテンツ識別子及びＩＤプロバイダーを使用して、それに対応する第１メタデータソースを決定すると共に、その第１メタデータソースを設けて、前記第１コンテンツオブジェクトを有する要求側エンティティと前記第１メタデータソースとの間を接続できるように動作するルーターを備えた、請求項Ｂ２４に記載のシステム。
【０３６２】
［結びの言葉］
以上、特定の実施形態を参照して、技術の原理を説明したが、この技術は、多数の他の異なる形態で実施できることが明らかであろう。明細書を不当に長くせずに包括的な開示を与えるために、上述した特許及び特許出願を参考として援用した。
【０３６３】
上述した方法、プロセス及びシステムは、ハードウェアでも、ソフトウェアでも、又はハードウェア及びソフトウェアの組み合わせでも、実施することができる。例えば、補助的データエンコードプロセスは、プログラム可能なコンピュータ又は特殊目的のデジタル回路において実施されてもよい。同様に、補助的データデコーディングは、ソフトウェア、ファームウェア、ハードウェア、又はそれらソフトウェア、ファームウェア、ハードウェアの組合せで実施されてもよい。上述した方法及びプロセスは、システムのメモリ（電子、光学又は磁気記憶装置のようなコンピュータ読み取り可能なメディア）から実行されるプログラムで実施されてもよい。
【０３６４】
前記で詳細に述べた実施形態における要素及び特徴の特定の組合せは、例示に過ぎず、これらの技術と、本出願及び参考として援用された特許／特許出願における他の技術との交換及び置き換えも意図される。本発明は、特許請求の範囲に規定された方法、並びにそれらの方法を実施するシステム及びコンピュータ読み取り可能なメディアを包含する。また、本明細書に述べる実施形態も発明であり、本出願人は、種々の実施形態及びその組み合わせを発明として請求する権利を保有する。
【符号の説明】
【０３６５】
２００、２０２・・・ＩＤプロバイダーＡシステム、２０４・・・ディレクトリシステム、２０６・・・登録インターフェイス、２０８・・・データベース、２１０・・・ＧＵＩ、２１２・・・メタデータソースＩＤ、２１４・・・コンテンツオブジェクト、２１６・・・リーダーＡ、２１８・・・リーダーＢ、２２０・・・セットＡのＣＩＤ  １、２２２・・・セットＢのＣＩＤ  １、２２４・・・解明インターフェイス、２３０、２３２・・・メタデータソースプロバイダーシステム、９００・・・コンシューマドメイン、９０２・・・ルーターシステム、９０４・・・コンテンツ配布参加者、９０６・・・コンテンツ所有者、９０８・・・コンテンツ配布者、９１０・・・メディアオブジェクト、９１２・・・コンシューマ、９１４…登録コンポーネント、９１６・・・ＩＤレジストリ、９１８・・・リンクルールデータベース、９２０・・・ＩＤリゾルバー、９２２・・・ルールプロセッサ、９２４・・・トラフィックモニタ、９２６・・・応答アグレゲーター
【図１】
0005555271.tif 000030
【図２】
0005555271.tif 000031
【図３】
0005555271.tif 000032
【図４】
0005555271.tif 000033
【図５】
0005555271.tif 000034
【図６】
0005555271.tif 000035
【図７】
0005555271.tif 000036
【図８】
0005555271.tif 000037
【図９】
0005555271.tif 000038