JP2008521108A - コンテンツ管理システムの一意なネーミング・スキームの方法、システム、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】複数のステップを含む、コンテンツ管理システムの一意なネーミング方法、システム、およびコンピュータ・プログラムを提供する。
【解決手段】相対ＵＲＩと要求固有情報を含む第１要求を受け取る。相対ＵＲＩと要求固有情報を含む長いＵＲＩを含む第２要求を作成する。その第２要求を送る。
【選択図】図１

Description

本発明は、一般的にはリソースの識別に関し、より具体的にはコンテンツ管理システムの一意なネーミング・スキームの方法およびシステムに関する。

ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーション社（ＩＢＭ）は、ビジネス・コンピューティングにおいて常に新しい方法を開発してきた。この数十年の間にネットワーキングの重要性が増すにつれて、ユーザの利用できるリソースの数が増加し、利用に関する問題も増大するようになっている。ユーザがあるリソースを便利に利用できなければ、存在し、しかも理論的には有用であるはずであるということはユーザにとって実際にはまったく役に立たない。

その結果、リソースを便利に利用するという問題に対して、コンテンツ管理システムは様々なアプローチを利用している。識別スキームは便利なリソース識別に重要な２つの特徴、利便性と多義性の回避のバランスをとらなければならない。例えば、リソースに名前を付ける２つのアプローチは「一般名」と「抽象名」のネーミングである。一般名はユーザに馴染みやすいが、小さな名前空間でないと多義になりがちである。例えば、ある人をその人の名で識別すれば使いやすく、その名をもつ人が１人しか含まない名前空間内では多義にならないが、このアプローチはその名をもつ人を多数含むより大きな名前空間では、許容できないレベルの多義性がもたらされるために問題となることがある。

抽象名は典型的にはユーザに馴染みにくいが、多義にならないという利点がある。例えば、ある人をその人のフルネーム、生年月日と出生地、両親のフルネームで識別すれば、かなり多義にならずに識別できる。しかし、このようなアプローチはそれに従って作った識別子が扱いにくい性質のため使いにくい。

ユニフォーム・リソース識別子（ＵＲＩ）システムは抽象名のネーミングの１例である。ＵＲＩを利用してリソースを一意に識別するが、その２例がファイルとオブジェクトである。限られた名前空間内で、ユーザは「相対ＵＲＩ」を使ってリソースを識別するのはよくあるが、名前空間が長期間の間に変化するにつれて多義性がもたらされる可能性には目を瞑って利便性を改善できる。

明らかに、変化する名前空間内で使いやすくリソースを一意に識別できるコンテンツ管理システムのネーミング・スキームが必要である。

第１の側面によると、複数のステップを含むコンテンツ管理システムの一意なネーミング方法を提供する。相対ＵＲＩおよび要求固有情報を含む第１の要求を受け取る。相対ＵＲＩおよび要求固有情報を含む長いＵＲＩを含む第２の要求を作成する。好ましくは、第２の要求を送る。

複数のステップを含む相対識別子を含む要求に応答してリソースを多義にならずに識別し提供する方法も提供する。相対ユニフォーム・リソース識別子（ＵＲＩ）および要求固有情報を含む要求をサーバが受け取る。相対ＵＲＩおよび要求固有情報を含む長いＵＲＩをサーバが作成する。長いＵＲＩをサーバが複数のリソースと比較する。サーバが比較に基づいて、要求に応答して提供するために複数のリソースの１つを選択する。

相対識別子を含む要求に応答してリソースを多義にならずに識別して提供するコンテンツ管理システムも提供する。システムはサーバとコンピュータ読み取り可能命令を含む。サーバはコンピューティング・デバイスを含む。コンピュータ読み取り可能命令はコンピューティング・デバイス上で実行可能で、実行するとき、複数のステップを含むプロセスを実施する。相対ＵＲＩとメッセージ固有情報を含むメッセージを受け取る。相対ＵＲＩとメッセージ固有情報を含む長いＵＲＩを提供する。長いＵＲＩを複数のリソースと比較して、比較に基づいて複数のリソースの１つを選択する。好ましくは、システムはさらに複数のリソースを収容するデータベースを有し、データベースはコンピューティング・デバイスのプロセッサに作動的に連結される。

複数のステップを含む、初期リソースに基づいて多義にならずに識別した複数のリソースを作成および識別する方法も提供する。相対ＵＲＩを含む初期リソースをコンピューティング・デバイスが受け取る。初期リソースは、ＭＩＭＥタイプ、ユーザ・エージェント識別子、およびユーザ・ロケールの群の中の少なくとも１つを有する少なくとも１つの最終リソースに変換する。少なくとも相対ＵＲＩと、ＭＩＭＥタイプ、ユーザ・エージェント識別子、およびユーザ・ロケールの群の中の少なくとも１つとに基づいて、少なくとも１つの最終リソースの各々についてＵＲＩを作成する。

あるコンテンツ管理システムを特に参照して説明するが、請求の範囲に記載される主題は、使いやすい一意なネーミング・スキームが妥当なあらゆる情報技術（ＩＴ）システムに実装できる。コンピュータ技術の当業者には、開示される実施例が以下に説明するものに加えて多様なコンピューティング環境に関連性があることは認識されるであろう。さらに、開示する発明の方法は、ソフトウェア、ハードウェア、あるいはソフトウェアとハードウェアの組み合わせに実装できる。ハードウェア部分は専用のロジックを使用して実装できる。またソフトウェア部分はメモリーに格納して、マイクロプロセッサ、パーソナル・コンピュータ（ＰＣ）、またはメインフレームなどの適切な命令実行システムによって実行できる。

本書において、「メモリー」または「記録媒体」とは、命令実行システム、装置、もしくはデバイスによって、あるいは命令実行システム、装置、もしくはデバイスと一緒に使用するプログラムおよびデータもしくはプログラムまたはデータを包含、格納、通信、伝搬、あるいは移送するあらゆる手段である。メモリーおよび記録媒体とは、電子、磁気、光学、電磁、赤外線、または半導体システム、装置、もしくはデバイスでありうるが、それだけに限定されない。メモリーおよび記録媒体は、例えば、ポータブル・コンピュータ・フレキシブルディスク、ランダム・アクセス・メモリー（ＲＡＭ）、読取専用メモリー（ＲＯＭ）、消去及び再書き込み可能読み取り専用メモリー（ＥＰＲＯＭまたはフラッシュ・メモリー）、携帯コンパクト・ディスク読取専用メモリー、あるいはプログラムおよびデータもしくはプログラムまたはデータを格納できるその他適切な媒体も含むが、それだけに限定されない。

コンテンツ管理システムは、拡大し続けるネットワークのサイズと相互接続性を鑑みて、ネットワークで利用できるコンテンツを利用しやすくするように開発し実装されている。ネットワーキングは多様な概念的フレームワークを通じて理解でき、そのうちの１つが開放型システム間相互接続（ＯＳＩ）参照モデルである。ＯＳＩ参照モデルはネットワーキング技術をいかに機能的に調和させるかを記述するフレームワークを提供し、７つのレイヤを含み、その中にネットワーキング技術が割り当てられる。

１〜４のレイヤは「下位層」と呼べ、基本的にはネットワーク上でのデータのフォーマット化、エンコード、および伝送に向けられる、すなわち、ネットワーク内でデータを移動し、典型的にはハードウェアとソフトウェアの組み合わせで実施される。５〜７のレイヤは「上位層」と呼べ、基本的にはユーザとの対話と、ネットワーク上でランするアプリケーション、プロトコル、およびサービスの実施に向けられ、典型的にはソフトウェアで実施される。前述したように、また当業者には認識されるように、ソフトウェア実装の方が普通に使われる場合に特別な設計の配慮をしてハードウェア実装の使用を有利にでき、またその逆もできる。当該改良および変型は本書で提供される文字通りの記述から逸脱しているかもしれないが、添付の請求項の精神および範囲内にある。

レイヤは概念的フレームワークをサポートするように明確に区別されているが、実際にはレイヤは機能的に相互接続する。例えば、イーサーネットの仕様は１と２の両方のレイヤに関わり、ＴＣＰ／ＩＰプロトコル・スーツのＴＣＰとＩＰは３と４の両方のレイヤに関わる。

本発明の好適な実施例は上位層に向けられる。実際には、上位層の分離は下位層の分離ほど明確ではない。例えば、ＴＣＰ／ＩＰプロトコル・スーツのアーキテクチャはレイヤ５〜７を単一の「トップ・レイヤ」として扱う。この結果、トップ・レイヤはより高次のＯＳＩレイヤにサービスを提供するのではなく、ネットワークを利用したいプログラムとユーザに提供する。言い換えると、トップ・レイヤはネットワークのユーザが必要な機能を実施する。下位層のサービスはトップ・レイヤの機能をサポートする必要があるときに利用される。

例えば、パーソナル・コンピュータ上で動作するウエブ・ブラウザ・ソフトウェアを考えてみる。ウエブ・ブラウザ・ソフトウェアは従来ユーザからアプリケーションといわれるが、ＯＳＩのアプリケーション・レイヤには存在しない。そうではなく、ウエブ・ブラウザ・ソフトウェアは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）などのアプリケーション・レイヤが提供する機能を利用する。ある意味、ウエブ・ブラウザ・ソフトウェアは「８番目」のＯＳＩレイヤに存在するといえるかもしれない。

多くの目的のためにレイヤ５〜７は十分に分離せず、そのため概念的に不明瞭になる。従って、レイヤ５〜７は以下の表に示すような代替フレームワークを使って明確に区別されることがある。

本発明の好適な実施例は特に上の表に提示する第４機能領域、すなわちエンドユーザのアプリケーションとアプリケーション・プロトコルに関する。この機能領域の中で、好適な実施例は特にインターネット・リソースのアドレス割り当てにおいてＴＣＰ／ＩＰアプリケーションが使用するために確立する共通システム、すなわちユニフォーム・リソース識別子（ＵＲＩ）に関する。

ＵＲＩシステムは、インターネットが相互接続される膨大な数のサーバを含むために利用できる大量の情報のユーザビリティを改善するために作られた。各ＵＲＩはあるクライアントが特定のリソースが使えるようにそれを位置付けしてアクセスできる方法を一意に識別する。ＵＲＩは「アプリケーション・レイヤ・アドレッシング」と呼ばれているものを可能にする。これはレイヤ２のＭＡＣアドレッシング、レイヤ３のＩＰアドレッシング、レイヤ４のポート・アンド・ソケット・アドレッシング、ドメイン名システム（ＤＮＳ）アドレッシングとは異なる。特に、ＤＮＳ名はネットワークに接続される特定の実デバイスもしくは仮想デバイスを識別する。ＵＲＩはＤＮＳ名を頼りに、そのＤＮＳ名で識別されるデバイスに論理的に関係する特定のファイル、オブジェクト、またはその他のリソースを識別する。実際には、ＵＲＩはリソースを参照するのに必要な情報のすべてが単一のかなりコンパクトな文字列からなる。ＵＲＩはコンパクトな文字列であるため、ドキュメントに埋め込みやすく、そのためそのドキュメントから、少なくとも論理的には直接もしくは間接的に到達可能なその外部にあるあらゆるリソースまで、リンクの便利な埋め込みを可能にする。

どのＵＲＩもユニフォーム・リソース・ロケーター（ＵＲＬ）とユニフォーム・リソース名（ＵＲＮ）という２つのサブカテゴリーのうちの１つに分類される。ＵＲＬとは、ターゲット・リソースとターゲット・リソースの位置にアクセスするプロトコルまたはメカニズムを指定するＵＲＩである。ＵＲＬの一例がｈｔｔｐ：／／ｗｗｗ．ｉｂｍ．ｃｏｍ／ｕｓ／であり、これはインターナショナル・ビジネス・マシーンズ・インクが提供するウエブページを識別する。このＵＲＬはウエブページのプロトコルまたはアクセスのメカニズムをＨＴＴＰと指定し、ＤＮＳドメイン名「ｗｗｗ．ｉｂｍ．ｃｏｍ」とパス「ｕｓ／」でウエブページの位置を指定する。

対して、ＵＲＮとは、リソースのアクセス・メカニズムまたは位置を指定せずにリソースに固有名を提供するＵＲＩである。ＵＲＮの一例は、ＵＲＮ：ｉｓｂｎ：０４７１４１４６３８であり、これは２００３年４月４日にワイリー社（ジョン・ワイリー・アンド・サンズ・インク）がペーパーバックとして発行した、ケビン・メイニー著「Ｔｈｅ Ｍａｖｅｒｉｃｋ ａｎｄ Ｈｉｓ Ｍａｃｈｉｎｅ：Ｔｈｏｍａｓ Ｗａｔｓｏｎ，Ｓｒ． ａｎｄ ｔｈｅ Ｍａｋｉｎｇ ｏｆ ＩＢＭ（邦題：貫徹の志 トーマス・ワトソン・シニア ＩＢＭを発明した男）」と題する本を識別する。このように、ＵＲＩは本を一意に識別するが、それをアクセスできる場所または方法は識別しない。

ＵＲＬとＵＲＮは両方とも制限があるが、各々リソースを一意に識別する１種のＵＲＩを提供する。現在の実務では、ほとんどのＵＲＩは標準的なウエブのＵＲＬ構文規則に従うＨＴＴＰ ＵＲＬである。そのため、本書の大部分は本発明の好適な実施例を例証するためにウエブのＵＲＬ構文規則に適した例および用語を使用する。ただし、当業者には理解されるように、他のＵＲＩも添付の請求項の精神および範囲内にある。

ここで図面に移って、図１は本発明の一実施例に従い、相対ＵＲＩを長いＵＲＩに変換するプロセス１００を示すブロック図である。相対ＵＲＩ１０２はユーザ・インターフェース・レベル１０４で使用する。相対ＵＲＩ１０２はＵＲＩトランスレータ１０６に渡して、変換１０８を受ける。ＵＲＩトランスレータ１０６はターゲット・リソース１１１を識別する長いＵＲＩ１１０を出力するが、このターゲット・リソース１１１はおそらくユーザ・インターフェース・レベル１０４で相対ＵＲＩ１０２が識別することになっていたリソースであろう。長いＵＲＩ１１０は相対ＵＲＩ１０２および好ましくはユーザおよびターゲット・リソース１１１に関係するコンテキスト情報１１２に基づく。

長いＵＲＩ１１０の一部として含まれるコンテキスト情報１１２は多目的インターネットメール拡張（ＭＩＭＥ）タイプ、ユーザ・エージェント識別子（ユーザ・エージェントＩＤ）、およびユーザ・ロケールを含むのが好ましい。特に、ユーザ・ロケールはユーザ国とユーザ言語を含むのが好ましい。

図２は、本発明の一実施例に従い、相対ＵＲＩで識別されるリソースを求めるユーザ要求に応答して、複数のリソースのうちの１つを提供するプロセス１１４を示すブロック図である。相対ＵＲＩをもつユーザ要求をサーバが受け取る１１６。相対ＵＲＩはサーバによって、相対ＵＲＩと、ＭＩＭＥタイプ、ユーザ・エージェントＩＤおよびユーザ・ロケールを有するコンテキスト情報を含む長いＵＲＩに変換される１１８。サーバが長いＵＲＩを複数の利用できるリソースと比較する１２０。この比較に基づいて、ユーザ要求に応答して提供するために複数の利用できるリソースのうちの１つを選択する１２２。

本書を通し、「ユーザ・エージェントＩＤ」という用語は、該当するリソースへのアクセスに関連のあるユーザのコンピューティング環境を意味する。例えば、リソースがウエブページの場合、ユーザ・エージェントＩＤはユーザのウエブ・ブラウザ・ソフトウェアとコンピューディング・デバイス（例、携帯情報端末、パーソナル・コンピュータ、プリンター等）を含むであろう。これによって、ユーザは相対ＵＲＩを使ってリソースを要求することができ、相対ＵＲＩから長いＵＲＩへの裏での変換のおかげで、ユーザに合わせてカスタマイズしたリソースを提供できるであろう。

例えば、ユーザがサーバから相対ＵＲＩ ｈｔｔｐ：／／ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍを要求する。ユーザの要求にはユーザが米国に居住していることとＨＴＭＬを読むウエブ・ブラウザを使用していることを示すヘッダー情報が含まれる。従って、サーバは相対ＵＲＩを長いＵＲＩ ｈｔｔｐ：／／ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍ／ｔｅｘｔ／ｈｔｍｌ／ａ／ｕｓ／ｅｎ／ｈｏｍｅ．ｈｔｍｌに変換するので、ユーザにはＨＴＭＬを読むウエブ・ブラウザを使用する米国居住のユーザに特別に設計されたウエブページが提供される。長いＵＲＩは以下の表に示すように分解される。

長いＵＲＩの例の表では、トークン「ｔｅｘｔ／ｈｔｍｌ」は、リソースのフォーマットがＨＴＭＬを読むウエブ・ブラウザに適していることを示す。トークン「ａ」は設計上ウエブ・ブラウザがＤＨＴＭＬとモジラ４／ｘの機能性をハンドルできることを示す。トークン「ｕｓ」はユーザの国が米国であることを示す。トークン「ｅｎ」は、ユーザの言語が英語であることを示す。トークン「ｈｏｍｅ．ｈｔｍｌ」はＤＮＳドメイン名ｗｗｗ．ｓｏｍｅｓｅｒｖｅｒ．ｃｏｍに添えた記号「／」の要求に対してマップされたホームページである。

この例で例証するように、「ｈｏｍｅ」など、好まれる名前は、各リソースが特定のユーザ・コンテキストに合わせて作られ、コンテキストに依存した「長いＵＲＩ」によって裏で識別される場合には、多くのリソースで使用することができる。

図３は、本発明の一実施例に従い、バックエンドでユーザ・インターフェース・レベルの相対ＵＲＩと長いＵＲＩを使用できるコンテンツ管理システム１２６を含む相互接続されたネットワーク１２４を示すブロック図である。相対ＵＲＩをもつユーザ要求１２８はインターネット１３０を経由してコンテンツ管理システム１２６の一部であるサーバ１３２に送信される。サーバ１３２は相対ＵＲＩを長いＵＲＩに変換し１３４、長いＵＲＩを複数の利用できるリソース１３８と比較し１３６、その比較１３６に基づいてユーザ要求１２８に応答してユーザに提供するために複数の利用できるリソース１３８の中から１つを選択する１４０。

コンテンツ管理システム１２６は開示される一意なネーミング・スキームの詳細をユーザから効果的に隠すので、ユーザは相対ＵＲＩを使うことができ、長いＵＲＩよりも使いやすい。

図４は、本発明の一実施例に従い、少なくとも相対ＵＲＩをもつ初期リソースに基づきリソースを作成および識別するプロセス１４２を示すブロック図である。入力フェーズ１４６の初期リソース１４４は相対ＵＲＩ１４８を含む。初期リソース１４４は作成フェーズ１５２のためにリソース・クリエータ１５０に提供される。作成フェーズ１５２の後にターゲット・リソース・フェーズ１５４となり、そこでリソース・クリエータ１５０が、各々相対ＵＲＩおよび好ましくはターゲット・リソースおよびその意図するユーザに関連するコンテキスト情報１５８に基づく長いＵＲＩをもつ一または複数の最終リソース１５６を出力する。

この種のシステムは、初期リソースが基本コンテンツの記述に特によく適合したフォーマットである場合に特に便利である。このようなフォーマットの一例がＸＭＬである。例えば、初期リソース、ｓｏｍｅｃｏｎｔｅｎｔ．ｘｍｌが作成されているとする。初期リソースは、各々（１）英語を使う米国居住のユーザ向けにＤＨＴＭＬおよびモジラ４／ｘの機能性をハンドルできるウエブ・ブラウザ用ＨＴＭＬ、（２）日本語を使う日本居住のユーザ向けにＤＨＴＭＬおよびモジラ４／ｘの機能性をハンドルできるウエブ・ブラウザ用ＰＤＦ、（３）英語を使う米国居住のユーザ向けに上段および下段バナーとナビゲーション情報がないことを除きＤＨＴＭＬおよびモジラ４／ｘの機能性をハンドルできるウエブ・ブラウザ用ＨＴＭＬ、（４）英語を使用する米国居住のユーザ向けにＸＭＬの４つのフォーマットのうち別々のフォーマットをもつ４つの最終リソースとして格納されることが望ましい。図４に描くようなプロセスは、ｓｏｍｅｃｏｎｔｅｎｔ．ｘｍｌを以下の４つのリソースに変換する。
（１）／ｔｅｘｔ／ｈｔｍｌ／ａ／ｕｓ／ｅｎ／ｓｏｍｅｃｏｎｔｅｎｔ．ｈｔｍｌ
（２）／ａｐｐｌｉｃａｔｉｏｎ／ｐｄｆ／ａ／ｊｐ／ｊａ／ｓｏｍｅｃｏｎｔｅｎｔ．ｐｄｆ
（３）／ｔｅｘｔ／ｈｔｍｌ／ｆａｓｔ／ｕｓ／ｅｎ／ｓｏｍｅｃｏｎｔｅｎｔ．ｈｔｍｌ
（４）／ａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ／ａ／ｕｓ／ｅｎ／ｓｏｍｅｃｏｎｔｅｎｔ．ｈｔｍｌ

この例の結果は、４つの最終リソースの各々が多義にならずに識別されることである。また、最終リソースは、「ｓｏｍｅｃｏｎｔｅｎｔ」を求めるユーザ要求に応答して、ユーザ要求に伴うユーザ・コンテキスト情報に基づいて提供するために４つのリソースのうちの１つを選択できるように名前付けおよび位置付けされる。

本発明はその特定の実施例を参照して図示並びに説明してきたが、本発明の範囲を逸脱することなく、追加、省略、あるいは改良したエレメントおよび追加、省略、あるいは改良したブロック、もしくは追加、省略、あるいは改良したエレメントまたは追加、省略、あるいは改良したブロックを同じまたは異なる順番で行うことを含むが、それだけに限定されない、それに形態および細部に前述およびその他の変更を行えることは当業者には理解されるであろう。例えば、相対識別子はユーザのコンピューティング・デバイスでローカルに転換または変換して、完全な識別子を含む要求をアプリケーション・レイヤまたは同等のサービスに提出することができる。

本発明は開示する実施例の詳細な説明を以下の図面と考え合わせると、よりよい理解を得ることができる。

本発明の一実施例に従い、相対ユニフォーム・リソース識別子（ＵＲＩ）の長いＵＲＩへの変換を示すブロック図である。 本発明の一実施例に従い、相対ＵＲＩで識別したリソースを求めるユーザ要求に応答して複数のリソースの中の１つの提供を示すブロック図である。 本発明の一実施例に従い、バックエンドでユーザ・インターフェース・レベルの相対ＵＲＩと長いＵＲＩを使用できるコンテンツ管理システムを示すブロック図である。 本発明の一実施例に従い、少なくとも相対ＵＲＩをもつ初期リソースに基づくリソースの作成および識別を示すブロック図である。

Claims (15)

1. 相対ユニフォーム・リソース識別子（ＵＲＩ）および要求固有情報とを有する第１要求を受け取るステップと、
   前記相対ＵＲＩと前記要求固有情報とを有する長いＵＲＩを有する第２要求を作成するステップとを有する、コンテンツ管理システムの一意なネーミング方法。
2. 前記第２要求を送るステップをさらに有する、請求項１に記載の方法。
3. 前記第１要求が、
   前記相対ＵＲＩと、
   多目的インターネットメール拡張（ＭＩＭＥ）タイプ、ユーザ・エージェント識別子、およびユーザ・ロケールの群のうち少なくとも１つを有する前記要求固有情報とを有する、請求項１または請求項２に記載の方法。
4. 前記送るステップが、
   前記第２要求を処理するステップと、
   前記第１要求に応答して前記長いＵＲＩによって識別される前記リソースを有する応答を送るステップとを有する、請求項２または請求項３に記載の方法。
5. 前記長いＵＲＩを複数のリソースと比較するステップと、
   前記比較するステップに基づいて、前記要求に応答して提供するために前記複数のリソースのうちの１つを選択するステップとをさらに有する、請求項１〜４のいずれかに記載の方法。
6. 前記第１要求に応答して、前記複数のリソースのうちの前記１つを有する応答を送るステップをさらに有する、請求項５に記載の方法。
7. 前記受け取るステップが、前記相対ＵＲＩと前記要求固有情報とを有する前記要求を常時接続公衆ネットワークを介して受け取るステップを有し、
   前記送るステップが、前記要求に応答して、前記複数のリソースのうちの前記１つを有する応答を常時接続公衆ネットワークを介して送るステップを有する、請求項６に記載の方法。
8. プロセッサとプロセッサに作動的に連結されるメモリーとプロセッサに作動的に連結されるネットワーク・インターフェースとを有するコンピューティング・デバイスを有するサーバを有し、
   前記コンピューティング・デバイスがネットワーク・インターフェースを介して、相対ＵＲＩと要求固有情報とを有する第１要求を受け取るようになされ、かつ
   前記コンピューティング・デバイスが、前記相対ＵＲＩと前記要求固有情報とを有する長いＵＲＩを有する第２要求を作成するようになされた、一意なネーミング・コンテンツ管理システム。
9. 前記コンピューティング・デバイスが前記第２要求を送るようになされた、請求項８に記載のシステム。
10. 前記第１要求が、前記相対ＵＲＩと、ＭＩＭＥタイプ、ユーザ・エージェント識別子、およびユーザ・ロケールの群の中の少なくとも１つを有する前記要求固有情報を有する、請求項８または請求項９に記載のシステム。
11. 前記コンピューティング・デバイスが、
    前記第２要求を処理するようになされ、かつ
    前記第１要求に応答して、前記長いＵＲＩによって識別される前記リソースを有する応答を送るようになされた、請求項９または請求項１０に記載のシステム。
12. 前記コンピューティング・デバイスが、前記長いＵＲＩと前記複数のリソースを比較して、前記比較に基づいて前記複数のリソースのうちの１つを選択するようになされた、請求項８〜１１のいずれかに記載のシステム。
13. 前記コンピューティング・デバイスが、前記第１要求に応答して、前記複数のリソースのうちの前記１つを有する応答を前記ネットワーク・インターフェースを介して送るようになされた、請求項１２に記載のシステム。
14. 前記コンピューティング・デバイスがさらに、前記相対ＵＲＩと前記要求固有情報とを有する前記要求を常時接続公衆ネットワークを介して受け取るようになされ、
    前記送るステップが、前記要求に応答して、前記複数のリソースのうちの前記１つを有する応答を前記常時接続公衆ネットワークを介して送るステップを有する、請求項１３に記載のシステム。
15. プログラムをコンピュータでランするとき、請求項１から７のいずれかのステップのすべてを実行するようになされたプログラム・コード手段を有するコンピュータ・プログラム。

Images