(57)【要約】  複数のレポジトリー(714,716,718)の中のレポジトリーに１つ以上のコンテンツサービスを提供するためのシステム及び方法において、前記システムは、１つ以上のコンテンツサービス(708,710)を含むバーチャルコンテンツレポジトリー(700)と、前記バーチャルコンテンツレポジトリーへと一体化された前記複数のレポジトリーと、前記複数のレポジトリーを取り巻くことのできる論理的ネームスペース(400)とを備えている。
2007520785.tif 000002
【特許請求の範囲】
【請求項１】
複数のレポジトリーの中のレポジトリーに１つ以上のコンテンツサービスを提供するための方法において、
前記複数のレポジトリーをバーチャルコンテンツレポジトリー（ＶＣＲ）へと一体化するステップと、
前記複数のレポジトリーを取り巻く論理的ネームスペースを維持するステップと、
前記レポジトリーへ前記１つ以上のコンテンツサービスを提供するステップと、
を備え、前記１つ以上のコンテンツサービスは、バージョニング能力及びライフサイクル能力の少なくとも１つを含み、
前記レポジトリーは、コンテンツ情報及びスキーマ情報の少なくとも１つを記憶し、そして
前記コンテンツ及びスキーマ情報は、前記複数のレポジトリーを取り巻く論理的ネームスペースを通してアクセスできるようにした方法。
【請求項２】
前記コンテンツ情報及びスキーマ情報の少なくとも１つに対する変更を追跡するために前記レポジトリーのバージョン経歴を維持するステップを更に備えた、請求項１に記載の方法。
【請求項３】
前記バージョン経歴はロールバックすることができる、請求項２に記載の方法。
【請求項４】
ライフサイクル定義に基づき状態のセットを通して前記コンテンツ情報を移行させるステップを更に備えた、請求項１に記載の方法。
【請求項５】
前記一体化するステップは、前記ＶＣＲに適合するサービスプロバイダーインターフェイスを実施することを含む、請求項１に記載の方法。
【請求項６】
前記ネームスペースはハイアラーキーである、請求項１に記載の方法。
【請求項７】
複数のレポジトリーの中のレポジトリーに１つ以上のコンテンツサービスを提供するためのシステムにおいて、
１つ以上のコンテンツサービスを含むバーチャルコンテンツレポジトリー(ＶＣＲ)と、
前記ＶＣＲへと一体化された前記複数のレポジトリーと、
前記複数のレポジトリーを取り巻くことのできる論理的ネームスペースと、
を備え、前記１つ以上のコンテンツサービスを前記レポジトリーへ提供することができ、
前記１つ以上のコンテンツサービスは、バージョニング能力及びライフサイクル能力の少なくとも１つを含み、
前記レポジトリーは、コンテンツ情報及びスキーマ情報の少なくとも１つを記憶し、そして
前記コンテンツ及びスキーマ情報は、前記複数のレポジトリーを取り巻く論理的ネームスペースを通してアクセスできるようにしたシステム。
【請求項８】
前記コンテンツ情報及びスキーマ情報の少なくとも１つに対する変更を追跡することのできる前記レポジトリーのバージョン経歴を更に備えた、請求項７に記載のシステム。
【請求項９】
前記バージョン経歴はロールバックすることができる、請求項８に記載のシステム。
【請求項１０】
状態のセットを通して前記コンテンツ情報を移行させることのできるライフサイクル定義を更に備えた、請求項７に記載のシステム。
【請求項１１】
前記一体化は、前記ＶＣＲに適合するサービスプロバイダーインターフェイスを実施することを含む、請求項７に記載のシステム。
【請求項１２】
前記ネームスペースはハイアラーキーである、請求項７に記載のシステム。
【請求項１３】
複数のコンテンツレポジトリーを表わすバーチャルコンテンツレポジトリー（ＶＣＲ）で動作する方法において、
ノードを生成するステップであって、前記ノードは、前記ＶＣＲにおける前記ノードの位置を指示する識別子を有するようなステップと、
前記ノードを、１）プロパティ、及び２）スキーマ、の少なくとも１つに関連付けるステップと、
前記ＶＣＲに前記ノードを記憶するステップと、
を備え、前記ＶＣＲに前記ノードを記憶すると、少なくとも１つのプロパティ及び／又はスキーマが前記複数のコンテンツレポジトリーの１つに記憶されるようにした方法。
【請求項１４】
前記プロパティは、ネームと少なくとも１つの値との関連性である、請求項１３に記載の方法。
【請求項１５】
前記少なくとも１つの値は、テキストストリング、番号、イメージ、オーディオ／ビジュアルプレゼンテーション、又はバイナリーデータである、請求項１４に記載の方法。
【請求項１６】
前記複数のコンテンツレポジトリーの各１つは、ＶＣＲへのその一体化を可能にするように第１セットのサービスを露出させる、請求項１３に記載の方法。
【請求項１７】
スキーマは、少なくとも１つのプロパティ定義を含む、請求項１３に記載の方法。
【請求項１８】
前記ノードは、ＶＣＲ内の他のノードにハイアラーキー式に関連付けできる、請求項１３に記載の方法。
【請求項１９】
バーチャルコンテンツレポジトリー（ＶＣＲ）で動作する方法であって、前記ＶＣＲがノードを有し、そして前記ノードが情報に関連付けされる方法において、
前記ノードを得るステップであって、前記ノードが、前記ＶＣＲにおける独特の位置を指示する識別子を有するようなステップと、
前記ノードで動作を実行するステップであって、前記動作は、１）前記ノードを削除し、２）ＶＣＲにおける前記ノードの位置を変更し、３）前記情報を読み取り、そして４）前記情報を更新する、の１つであるようなステップと、
を備え、
前記ＶＣＲは、複数のコンテンツレポジトリーを表わし、そして
前記情報は、１）プロパティ、及び２）スキーマ、の少なくとも１つを含むようにした方法。
【請求項２０】
前記プロパティは、ネームと少なくとも１つの値との関連性である、請求項１９に記載の方法。
【請求項２１】
前記複数のコンテンツレポジトリーの各１つは、ＶＣＲへのその一体化を可能にするように第１セットのサービスを露出させる、請求項１９に記載の方法。
【請求項２２】
複数のコンテンツレポジトリーをバーチャルコンテンツレポジトリー（ＶＣＲ）へ一体化する方法において、
前記複数のコンテンツレポジトリーの各１つに証明書情報を与えるステップと、
前記複数のコンテンツレポジトリーの各１つから許可情報を受け取るステップであって、この許可情報が、許可手順が成功したかどうか指示するようなステップと、
許可情報が許可成功を指示する前記複数のコンテンツレポジトリーの各１つを前記ＶＣＲに一体化するステップと、
を備え、前記複数のコンテンツレポジトリーの各１つが、ＶＣＲへのその一体化を可能にするように第１セットのサービスを露出させるようにした方法。
【請求項２３】
前記第１セットのサービスは前記証明書情報を受け容れる、請求項２２に記載の方法。
【請求項２４】
前記第１セットのサービスは前記許可情報を与える、請求項２２に記載の方法。
【請求項２５】
前記複数のコンテンツレポジトリーの各１つは、そのコンテンツレポジトリーにおける情報のモデルを実施することに関連した第２セットのサービスを露出させ、そして
前記モデルは、ＶＣＲコンテンツモデルに適合し得るものである、請求項２２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツのマネージメントに係り、より詳細には、コンテンツをバージョニングしそして定義可能なコンテンツライフサイクルを与えることに係る。
【０００２】
優先権の請求：本出願は、参考としてここにその全体を援用する次の特許出願から優先権を請求する。
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR VIRTUAL CONTENT REPOSITORY DEPLOYMENT」と題する米国プロビジョナル特許出願第６０／５６１，８１９号（代理人ドケットNo. BEAS-01550US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR VIRTUAL CONTENT REPOSITORY DEPLOYMENT」と題する米国特許出願第１０／９１５，１９４号（代理人ドケットNo. BEAS-01550US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT VERSIONING」と題する米国プロビジョナル特許出願第６０／５６１，７８０号（代理人ドケットNo. BEAS-01533US0）；
２００４年１１月１日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT VERSIONING」と題する米国特許出願第１０／９１０，２３３号（代理人ドケットNo. BEAS-01533US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT LIFECYCLES」と題する米国プロビジョナル特許出願第６０／５６１，７９６号（代理人ドケットNo. BEAS-01534US0）；
２００４年８月４日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT LIFECYCLES」と題する米国特許出願第１０／９１１，０９９号（代理人ドケットNo. BEAS-01534US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT AND SCHEMA VERSIONING」と題する米国プロビジョナル特許出願第６０／５６１，７８３号（代理人ドケットNo. BEAS-01535US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT AND SCHEMA VERSIONING」と題する米国特許出願第１０／９１５，０３３号（代理人ドケットNo. BEAS-01535US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT AND SCHEMA LIFECYCLES」と題する米国プロビジョナル特許出願第６０／５６１，７８５号（代理人ドケットNo. BEAS-01536US0）；
２００４年１１月１日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT AND SCHEMA LIFECYCLES」と題する米国特許出願第１０／９１１，２８７号（代理人ドケットNo. BEAS-01536US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR VIRTUAL CONTENT REPOSITORY ENTITLEMENTS」と題する米国プロビジョナル特許出願第６０／５６１，７７８号（代理人ドケットNo. BEAS-01551US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR VIRTUAL CONTENT REPOSITORY ENTITLEMENTS」と題する米国特許出願第１０／９１５，００８号（代理人ドケットNo. BEAS-01551US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT TYPE MANAGEMENT」と題する米国プロビジョナル特許出願第６０／５６１，６４８号（代理人ドケットNo. BEAS-01552US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT TYPE MANAGEMENT」と題する米国特許出願第１０／９１５，０１３号（代理人ドケットNo. BEAS-01552US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CUSTOM CONTENT LIFECYCLES」と題する米国プロビジョナル特許出願第６０／５６１，７８２号（代理人ドケットNo. BEAS-01553US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CUSTOM CONTENT LIFECYCLES」と題する米国特許出願第１０／９１５，５０５号（代理人ドケットNo. BEAS-01553US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT TYPE VERSIONS」と題する米国プロビジョナル特許出願第６０／５６１，７５９号（代理人ドケットNo. BEAS-01554US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR CONTENT TYPE VERSIONS」と題する米国特許出願第１０／９１５，０５７号（代理人ドケットNo. BEAS-01554US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR INFORMATION LIFECYCLE WORKFLOW INTEGRATION」と題する米国プロビジョナル特許出願第６０／５６１，６４６号（代理人ドケットNo. BEAS-01555US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR INFORMATION LIFECYCLE WORKFLOW INTEGRATION」と題する米国特許出願第１０／９１５，５０６号（代理人ドケットNo. BEAS-01555US1）；
２００４年４月１３日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR SEARCHING A VIRTUAL CONTENT REPOSITORY」と題する米国プロビジョナル特許出願第６０／５６１，８１８号（代理人ドケットNo. BEAS-01565US0）；
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR SEARCHING A VIRTUAL CONTENT REPOSITORY」と題する米国特許出願第１０／９１５，５０４号（代理人ドケットNo. BEAS-01565US1）；及び
２００４年８月１０日に出願されたロドニー・マッカーレイ氏等の「SYSTEM AND METHOD FOR PROVIDING CONTENT SERVICES TO A REPOSITORY」と題する米国特許出願第１０／９１５，５２１号（代理人ドケットNo. BEAS-01729US0）。
【背景技術】
【０００３】
コンテンツレポジトリーは、新聞のアーカイブス、広告、在庫、映像収集等の大型データ記憶装置をマネージしそしてそこへのアクセスを与える。コンテンツレポジトリーは、ユーザの対話に応答して異なる形式のコンテンツに迅速にサービスしなければならないポータルのようなウェブアプリケーションの重要なコンポーネントである。しかしながら、２人以上の売主のコンテンツレポジトリーを一体化しようと試みるときに問題が生じ得る。その各々は、それ自身の独占的アプリケーションプログラムインターフェイス及びコンテンツサービス（例えば、コンテンツ、バージョニング、ライフサイクル、及びデータフォーマットをサーチしそして操作するための規定）をもつことができる。更に、レポジトリーがアプリケーションに追加されるたびに、それらの相違を受け容れるためにアプリケーションソフトウェアを変更しなければならない。そこで、異種のレポジトリーにインターフェイスし、そしてコンテンツサービスの均一なセットを、これらサービスを欠くものも含む全てのレポジトリーにわたって提供するためのコヒレントなシステム及び方法が要望される。
【発明を実施するための最良の形態】
【０００４】
同様の要素が同じ参照番号で示された添付図面を参照して本発明の態様を一例として説明するが、本発明は、これに限定されない。この開示において、「ある」、「１つの」及び「種々の」実施形態という言い方は、必ずしも同じ実施形態ではなく、少なくとも１つを意味することに注意されたい。以下の説明では、本発明を完全に説明するために、多数の特定の細部を説明する。しかしながら、これらの特定の細部を伴わずに本発明を実施できることが当業者に明らかであろう。他の例では、本発明を不明瞭にしないために、良く知られた特徴は、詳細に述べないことにする。
【０００５】
図１は、本発明の種々の実施形態における機能的システムレイヤーを例示する図である。この図は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアへと任意に結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【０００６】
コンテンツレポジトリー１１２は、サーチ可能なデータ記憶装置を表わす。このようなシステムは、構造化コンテンツ及び非構造化コンテンツ（例えば、デジタルで走査されるペーパードキュメント、拡張可能なマークアップ言語、ポータブルドキュメントフォーマット、ハイパーテキストマークアップ言語、電子メール、イメージ、ビデオ及びオーディオストリーム、生のバイナリーデータ等）をサーチ可能なコーパスに関連付けることができる。コンテンツレポジトリーは、コンテンツマネージメントシステムに結合し又はそれと一体化することができる。コンテンツマネージメントシステムは、コンテンツライフサイクルマネージメント、バージョニング、コンテンツ再検討及び承認、自動コンテンツ分類、事象駆動のコンテンツ処理、プロセス追跡、及び他のシステムへのコンテンツ配送を行うことができる。説明上、ユーザがウェブポータルにおいてローンの申込書に書き込みをする場合に、ポータルは、その申込書をコンテンツレポジトリーへ転送し、該コンテンツレポジトリーは、次いで、銀行システムにコンタクトし、ローン承認の通知を受け取り、レポジトリーにおけるローンの申込書を更新し、そしてウェブポータルに適したフォーマットで承認情報を差し出すことでユーザに通知することができる。
【０００７】
バーチャル又はフェデレート化(federated)コンテンツレポジトリー（以下、「ＶＣＲ」と称する）は、アプリケーションレイヤー１２０の観点から単一のコンテンツレポジトリーとして現われて振舞うような１つ以上の個々のコンテンツレポジトリーの論理的表示である。又、ＶＣＲは、コンテンツサービスを、本来それらを欠くレポジトリーに追加することもできる。種々の実施形態では、説明上、これは、ＡＰＩ（アプリケーションプログラムインターフェイス）１００及びＳＰＩ（サービスプロバイダーインターフェイス）１０２の使用により一部分達成することができる。ＡＰＩは、アプリケーションレイヤーのエンティティが、あるプログラムロジック又は機能にどのようにインターフェイスできるか記述する。アプリケーションレイヤーは、ＡＰＩを利用するアプリケーション（及びその区画）、例えば、プロセス、スレッド、サーブレット、ポトレット、オブジェクト、ライブラリー、及び他の適当なアプリケーションコンポーネントを含むことができる。ＳＰＩは、サービスプロバイダー（例えば、コンテンツレポジトリー、コンテンツマネージメントシステム）をある種のシステムにどのように一体化できるか記述する。ＳＰＩは、ＡＰＩからのレポジトリーとの直接的な対話を分離する。種々の実施形態では、これは、ランタイムに、ＡＰＩライブラリーがＳＰＩライブラリーに動的にリンクし又はロードするようにして実行できる。別の実施形態では、ＳＰＩは、ＡＰＩとＳＰＩがネットワークを経て通信できるようにサーバープロセスの一部分でよい。ＳＰＩは、共有メモリ、リモート手順コール、及び／又は１つ以上の中間サーバープロセスを含む（それらに限定されないが）多数の手段を使用してレポジトリーと通信することができる。
【０００８】
ＡＰＩ及びＳＰＩは、ＶＣＲサービス（１つ又は複数）にアクセスしそしてそれを利用できるようにするプログラム手段をなすように一緒に作用するクラス／インターフェイス、データ構造及び／又は方法／機能の集合として指定することができる。説明上、ＡＰＩ及びＳＰＩは、ＪａｖａTM（カリフォルニア州マウンテンビューのサン・マイクロシステムズ・インクから入手できる）及びＣ＃（ワシントン州レドモンドのマイクロソフト・コープから入手できる）のようなオブジェクト指向のプログラミング言語で指定することができる。ＡＰＩ及びＳＰＩは、静的ライブラリー、動的リンクライブラリー、分散型オブジェクト、サーバー、クラス／インターフェイスインスタンス、及び他の適当な手段を含む（それらに限定されないが）多数の仕方で露出させることができる。
【０００９】
種々の実施形態において、ＡＰＩは、全てのレポジトリーの統合したビューをアプリケーションレイヤーに与えて、アプリケーションレイヤーから開始されたナビゲーション、ＣＲＵＤオペレーション（生成、読み取り、更新、削除）、バージョニング、ライフサイクル、及びサーチオペレーションが、レポジトリーに対し、それらが１つであるかのごとく、働くようにする。ＳＰＩを実施するレポジトリーは、ＶＣＲに「プラグイン」することができる。ＳＰＩは、ＡＰＩの機能をレポジトリーレベルでサポートするインターフェイス及びサービスのセットを含む。ＡＰＩ及びＳＰＩは、全てのレポジトリーの結合されたコンテンツをノードのハイアラーキーネームスペースとして表わすコンテンツモデルを共有する。ノードＮが与えられると、ハイアラーキー的にＮより下位のノードは、Ｎの子供と称され、一方、ハイアラーキー的にＮより上位のノードは、Ｎの親と称される。ハイアラーキーの最上位レベルは、フェデレート化ルート(federated root)と称される。ハイアラーキーの深さに限度はない。種々の実施形態において、レポジトリーは、フェデレート化ルートの子供である。各レポジトリーそれ自体が子供をもつことができる。
【００１０】
説明上、コンテンツマイニングファシリティ１０４、プロセス／スレッド１０６、タグライブラリー１０８、一体化開発環境（ＩＤＥ）１１０、及び他のライブラリー１１８は、全て、ＡＰＩを利用して、ＶＣＲと対話することができる。ＩＤＥは、ユーザがライフサイクル及び／又はコンテンツビューをインタラクティブに構築する能力を与えることができる。コンテンツマイニングファシリティは、パラメータに基づいてＶＣＲからコンテンツを自動的に抽出するためのサービスを含むことができる。Ｊａｖａ  ＳｅｒｖｅｒＰａｇｅTMタグライブラリーは、ポータルがＶＣＲと対話して、ウェブページ上のそのコンテンツを表面化できるようにする。（Ｊａｖａ  ＳｅｒｖｅｒＰａｇｅTMは、サン・マイクロシステムズ・インクから入手できる。）更に、当業者であれば、他の多数の形式のアプリケーション及びソフトウェアコンポーネントもＡＰＩを利用し、従って、それらも、この開示の範囲及び精神の中に完全に包含されることが明らかであろう。
【００１１】
種々の実施形態において、ＡＰＩは、ＶＣＲとの対話の実行を改善するための最適化を含むことができる。１つ以上のキャッシュ１１６を使用して、サーチ結果及び／又は最近アクセスしたノードをバッファすることができる。種々の実施形態において、キャッシュは、ノードキャッシュ及び／又はバイナリーキャッシュを含むことができる。ノードキャッシュは、最近アクセスしたノードへ高速アクセスを与えるのに使用でき、一方、バイナリーキャッシュは、ノードキャッシュ内の各ノードに関連したコンテンツ／データへ高速アクセスを与えるのに使用できる。又、ＡＰＩは、アプリケーション、ツール及びライブラリーがキャッシュ及びＶＣＲを構成できるようにするためのコンフィギュレーションファシリティ１１４も与えることができる。種々の実施形態において、このファシリティは、Ｊａｖａマネージメントエクステンション（サン・マイクロシステムズ・インクから入手できる）として実施することができる。
【００１２】
種々の実施形態において、ハイアラーキー情報、コンテンツ及びデータ形式を表わすためのモデルがＡＰＩとＳＰＩとの間に共有される。このモデルでは、ノードは、ハイアラーキー情報、コンテンツ又はスキーマ情報を表わすことができる。ハイアラーキーノードは、ハイアラーキーファイルシステムのファイルサブディレクトリーと同様にネームスペース内の他のノードに対するコンテナとして働くことができる。スキーマノードは、予め定められたデータ形式を表わす。コンテンツノードは、コンテンツ／データを表わす。ノードは、それらのプロパティにより定められた形状をもつことができる。プロパティは、ネーム、データ形式、及びその形式に適した任意の値を関連させる。これら実施形態の幾つかにおいて、コンテンツノードのプロパティは、値を含む。説明上、形式は、テーブル１に示す形式のいずれかでよい。当業者であれば、この開示の精神及び範囲内で更に多数の形式が考えられることが明らかであろう。
【００１３】
テーブル１：種々の実施形態におけるプロパティ形式の例
2007520785.tif 000003
【００１４】
種々の実施形態において、プロパティは、それが要求されるかどうか、それがリードオンリであるかどうか、それがデフォールト値を与えるかどうか、そしてそれがプロパティ選択を指定するかどうかも指示することができる。プロパティ選択は、プロパティが単一の非制限値であるか、単一の制限値であるか、多数の非制限値であるか、又は多数の制限値であるかを指示する。単一であるプロパティは、１つの値しかもたず、一方、多数であるプロパティは、２つ以上の値をもつことができる。プロパティが制限される場合には、値の限定セットから値（１つ又は複数）が選択される。しかし、プロパティが非制限である場合には、それに対していかなる値（１つ又は複数）を与えることもできる。又、プロパティは、一次プロパティとして設計することもできる。説明上、ノードの一次プロパティは、そのデフォールトコンテンツと考えることができる。例えば、ノードがイメージを保持するためにバイナリープロパティを含む場合には、イメージのサムネールビューを表わすための二次バイナリープロパティも含むことができる。サムネールビューが一次プロパティであった場合には、ブラウザのようなソフトウェアアプリケーションがデフォールトによりそれを表示することができる。
【００１５】
１つ以上のプロパティ形式の命名された集合が、スキーマ(schema)である。スキーマノードは、スキーマのプレースホルダーである。種々の実施形態において、スキーマは、ノードのプロパティを指定するのに使用できる。説明上、３つのプロパティ（名前、住所及び誕生日(Name, Address and DateofBirth)）をもつパーソン(Person)スキーマを、以下の説明の目的で記述することができる。
Schema Person = {
<Name=Name, Type=Text>,
<Name=Address, Type=Address>,
<Name=DateofBirth, Type=Date>}
【００１６】
種々の実施形態では、スキーマに基づきノードを定義できる。説明上、コンテンツノードＪｏｈｎは、スキーマＰｅｒｓｏｎと同じプロパティを与えることができる。
Content Node John is a person
【００１７】
この場合に、ノードＪｏｈｎは、次の特性をもつ：Ｎａｍｅ、Ａｄｄｒｅｓｓ及びＤａｔｅｏｆＢｉｒｔｈ。或いは又、ノードは、１つ以上のスキーマを使用して、個々のプロパティを定義することができる。これは、時々、ネスト型形式とも称される。以下の説明において、Ｊｏｈｎは、プロパティＮａｍｅ、Ａｄｄｒｅｓｓ及びＤａｔｅｏｆＢｉｒｔｈをそれ自身含むＩｎｆｏプロパティを有するように定義される。更に、Ｊｏｈｎは、ＣｕｓｔｏｍｅｒＩＤプロパティも有する。
Content Node John = {
<Name=Info, Type=Person>,
<Name=CustomerId, Type=Number> }
【００１８】
スキーマは、ＶＣＲにおいて及び／又はＶＣＲを形成する個々のレポジトリーにおいて論理的に定義することができる。ある実施形態では、スキーマは、少なくとも１つの他のスキーマからプロパティを継承する。スキーマの継承は、その深さが無制限である。即ち、スキーマＡは、スキーマＢから継承することができ、そしてスキーマＢ自体は、スキーマＣから継承することができ、等々となる。多数のスキーマが繰り返しプロパティを含む場合には、「ベース」スキーマを構成し、そこから、他のスキーマを継承することができる。例えば、プロパティＮａｍｅ、Ａｄｄｒｅｓｓ及びＤａｔｅｏｆＢｉｒｔｈを含むＰｅｒｓｏｎスキーマは、Ｅｍｐｌｏｙｅｅ（従業員）スキーマにより継承することができ、これは、それ自身のプロパティ（即ち、従業員ＩＤ、雇用日及び給与(EmployeeID, Date of Hire and Salary)を追加する。
Schema Employee inherits from Person = {
<Name=EmployeeID, Type= Number>,
<Name=DateofHire, Type=Date>,
<Name=Salary, Type= Number> }
【００１９】
従って、上記で定義したように、Ｅｍｐｌｏｙｅｅスキーマは、次のプロパティを有する：Ｎａｍｅ、Ａｄｄｒｅｓｓ、ＤａｔｅｏｆＢｉｒｔｈ、ＥｍｐｌｏｙｅｅＩＤ、ＤａｔｅｏｆＨｉｒｅ、及びＳａｌａｒｙ。Ｐｅｒｓｏｎスキーマが、別のスキーマからそれ自身継承したプロパティを有する場合には、これらのプロパティもＥｍｐｌｏｙｅｅに属する。
【００２０】
種々の実施形態において、ノードは、名前／識別子を有し、そしてＶＣＲネームスペースにおけるノードの位置を指定する経路を使用してプログラム式に指定又はアドレスすることができる。説明上、経路は、フェデレート化ルート（‘／’）から当該ノード（‘ｃ’）までの経路を指定することができる。
／ａ／ｂ／ｃ
【００２１】
この例では、オープニング‘／’は、フェデレート化ルートを表わし、‘ａ’は、フェデレート化ルートの下のレポジトリーを表わし、‘ｂ’は、‘ａ’ レポジトリー内のハイアラーキーノードであり、そして‘ｃ’は、当該ノードである。又、経路は、ノードにおけるプロパティ（‘ｐｒｏｐｅｒｔｙ１’）も識別できる。
／ａ／ｂ／ｃ．ｐｒｏｐｅｒｔｙ１
【００２２】
これら実施形態の態様において、ノードの名前の前に生じる経路コンポーネントは、システムがコンテクスト情報に基づいてノードの位置を推測できる場合には、省略することができる。
【００２３】
種々の実施形態において、１つのレポジトリー又はＶＣＲに定義されたスキーマは、同じレポジトリー、異なるレポジトリー又はＶＣＲに定義された１つ以上のスキーマから継承することができる。これら実施形態のある態様において、継承されたスキーマにより示唆されるレポジトリーの１つ以上が継承をサポートしない場合には、継承するスキーマをＡＰＩによりＶＣＲにおいて自動的に定義することができる。一実施形態では、継承するスキーマは、デフォールトによりＶＣＲにおいて定義される。
【００２４】
説明上、Ａｖｉｔｅｃｈレポジトリーに位置されたＥｍｐｌｏｙｅｅスキーマは、ＢＥＡレポジトリーにおいてスキーマハイアラーキーノードの下に位置するＰｅｒｓｏｎスキーマから継承する。
Schema /Avitech/Employee inherits from /BEA/Schemas/Person = {
<Name=EmployeeID, Type= Number>,
<Name=DateofHire, Type=Date>,
<Name=Salary, Type= Number> }
【００２５】
種々の実施形態において、リンクプロパティ形式（テーブル１を参照）は、コンテンツの再使用を許すと共に、ＶＣＲの制御のもとにないコンテンツを含ませることを許す。説明上、リンクプロパティに関連した値は、次のいずれかを参照し／指すことができる：ＶＣＲ内のコンテンツノード、ＶＣＲ内のコンテンツノードの個々のプロパティ、ファイルシステムのファイル、ＵＲＬ（ユニホームリソースロケータ）で識別されたオブジェクト、又は他の適当な識別子。種々の実施形態において、リンクプロパティ形式を有するコンテンツノードを編集するときには、ユーザは、リンク行先を指定することができる（例えば、ブラウザ形式のユーザインターフェイスを使用して）。これら実施形態のある態様において、リンクがコンテンツノードを指すか、又は移動されたコンテンツノードプロパティを指す場合には、新たな位置を反映するようにリンクをシステムにより自動的に分析することができる。
【００２６】
種々の実施形態において、形式をルックアップする値（テーブル１を参照）は、ＶＣＲをサーチするために評価できる表現を、その表現を満足するコンテンツノード（１つ又は複数）のインスタンスに対して保持することができる。その表現を満足するノード（もしあれば）は、その後の処理に使用することができる。種々の実施形態において、ルックアップ表現は、次のものからの表現変数に置き換わり得る１つ以上の表現を含むことができる：ルックアッププロパティを含むコンテンツノード、ユーザプロフィール、要求又はセッションの範囲内の何か。種々の実施形態において、表現は、数学的、論理的及びブールの演算子、機能／方法の呼び出し、マクロ、ＳＱＬ（構造化問合せ言語）、及び他の適当な問合せ言語を含むことができる。種々の実施形態において、表現は、変数の置き換え、定数のフォールディング及び／又はマクロ拡張を実行するために１回以上前処理することができる。当業者であれば、この開示の精神及び範囲内で多数の他の表現が考えられることが明らかであろう。
【００２７】
種々の実施形態において、ルックアッププロパティ形式を有するコンテンツノードを編集するときには、ユーザは、ユーザが表現を直接入力することにより及び／又はその構成部分を選択することにより表現を構築するのを許すユーザインターフェイスを通して、表現を編集することができる。更に、このユーザインターフェイスは、ユーザが表現の評価結果をプレビューできるようにする。
【００２８】
データベースマップドのプロパティ形式（テーブル１を参照）は、１つ以上のデータベーステーブル（又は他のデータベースオブジェクト）から情報を抜粋（即ちマップ）させ、そしてノードプロパティを通して操作するのを許す。説明上、ある会社は、１つ以上のＲＤＢＭＳ（関連データベースマネージメントシステム）テーブルに行として記憶されたニュース記事のような「コンテンツ」を有する。この会社は、それらのポータル実施を介してこの「コンテンツ」の使用を希望する。更に、このテーブルの情報を、それがＶＣＲに存在するかのようにマネージすることを希望する。データベースマップド形式のコンテンツノードプロパティは、インスタンス生成されると、そのコンテンツが（データベーステーブルではなく）ＶＣＲにあるかのように振舞う。一実施形態では、プロパティに対する全てのＡＰＩオペレーションは、同一に振舞うが、最終的には、データベースの情報に対して動作する。
【００２９】
種々の実施形態において、所与のデータベースマップドのプロパティ形式は、評価されたときに、１つ以上のネットワークを経てシステムによりアクセスできるデータベーステーブル内の行及び列に分解する（又は任意の種類のデータベースオブジェクトに分解する）表現（例えば、ＳＱＬ）をもつことができる。データベースマップドのプロパティは、ネーティブなデータベーステーブル／オブジェクト、又はこれらテーブル／オブジェクトにおけるデータベースビューのいずれかを使用することができる。当業者であれば、この開示が特定の形式のデータベース又は表現分解に限定されないことが明らかであろう。
【００３０】
ある実施形態の態様において、データベーステーブル内の任意の行へとマップするスキーマを自動的に生成することができる。システムは、テーブルのデータ構造を検査し、そしてテーブルからの列に対応するデータベースマップドのプロパティをもつスキーマを予めポピュレートすることができる。テーブルの列のネームをデフォールトプロパティのネームとして使用することができ、同様に、各列のデータ形式が、各対応するプロパティのデータ形式を決定する。又、システムは、スキーマにおいて、どのプロパティが一次キー列に対応するか指示することもできる。テーブルからのある列が新たなスキーマにおいて使用されない場合には、それらを、ユーザ又はプロセスによりアンマップ（即ちデセレクト）することができる。コンテンツノードは、このようなスキーマをベースとし、そしてインスタンス生成されたときに、データベーステーブル内の行（又は他のデータベースオブジェクト）へ自動的に結び付けることができる。種々の実施形態において、ユーザは、データベーステーブルをブラウズすることによりデータベースオブジェクトを対話式に指定することができる。
【００３１】
種々の実施形態において、ディスプレイテンプレート（又は「テンプレート」）を使用して、スキーマに基づくコンテンツを表示することができる。テンプレートは、種々の「ビュー」を実施することができる。説明上、ビューは、「フル」、「サムネール」及び「リスト」であるが、付加的な「ビュー」をエンドユーザにより定義することもできる。フルビューは、コンテンツの最も大きな即ち全ページビューである。サムネールビューは、非常に小さなビューであり、そしてリストビューは、多数のコンテンツノードをページ（例えば、製品カタログサーチ結果ページ）に「リスト」として表示するときに使用できる。種々の実施形態において、スキーマとテンプレートとの間の関連性は、１対多である。テンプレートは、スキーマに対してデフォールトテンプレートとして設計することができる。これら実施形態の幾つかにおいて、テンプレートは、一体化開発環境（ＩＤＥ）の助けで設計することができる。
【００３２】
種々の実施形態において、説明上、ディスプレイテンプレートは、ＨＴＭＬ（ハイパーテキストマークアップ言語）及びＪＳＰ（Ｊａｖａ（登録商標）サーバーページ）を使用して実施することができる。更に説明上、このようなディスプレイテンプレートは、コンテンツノードの識別子をアーギュメントとして受け入れることのできるＪＳＰタグを介してウェブページからアクセスすることができる。コンテンツノードが与えられると、ノードのスキーマ及びそれに関連したデフォールトディスプレイテンプレートを導出してレンダリングすることができる。或いは又、ＪＳＰタグは、デフォールト以外のビューを指定するために付加的なアーギュメントを得ることができる。別の実施形態では、ディスプレイテンプレートは、コンテンツノードのスキーマに基づいて自動的に発生することができる（例えば、前もって又はランタイムに動的に）。他の実施形態では、ビュー（例えば、フル、サムネール、リスト）は、ＨＴＴＰ要求のコンテンツに基づいて自動的に決定することができる。
【００３３】
種々の実施形態において、ロール(role)は、ユーザの動的セットである。説明上、ロールは、そのメンバーにより分担された機能的責務に基づくことができる。これら実施形態の態様において、ロールは、１つ以上のメンバーシップ基準(Membership Criteria)により定義することができる。ロールのマッピングは、ユーザが所与のロールに対してメンバーシップ基準を満足するかどうか決定するプロセスである。説明上、ロールは、次のように記述することができる。
Role = PMembers + [Membership Criteria]
但し、ＰＭｅｍｂｅｒｓは、もしあれば、メンバーシップ基準を受けるこのロールの潜在的メンバーのプールを形成するユーザ（１人又は複数）、グループ（１つ又は複数）及び／又は他のロール（１つ又は複数）のセットである。ロールに入れられるべきユーザ又はプロセスについては、それらが、ＰＭｅｍｂｅｒｓに属し、そしてメンバーシップ基準を満足しなければならない。メンバーシップ基準は、１つ以上の条件を含むことができる。説明上、このような条件は、１つ以上の（考えられるネスト型及び混合型）ブール、数学的、機能的、関連性、及び／又は論理的表現を含むが、これらに限定されない。説明上、次のアドミニストレータのロールについて考える。
Administrator = Joe, Mary, SuperUser + CurrentTime > 5:00pm
【００３４】
このロールは、２人のユーザ（Ｊｏｅ及びＭａｒｙ）と、ＳｕｐｅｒＵｓｅｒという名前のユーザグループに属するユーザとをその潜在的メンバーとして有する。メンバーシップ基準は、現在時間が５：００ｐｍ以降であることを要求する条件を含む。従って、ユーザがＪｏｅ、Ｍａｒｙ、であるか、ＳｕｐｅｒＵｓｅｒグループに属し、そして現在時間が５：００ｐｍ以降である場合には、ユーザがアドミニストレータロールのメンバーである。
【００３５】
種々の実施形態において、ロールにリソース（１つ又は複数）を組み合せることができる。説明上、リソースは、任意のシステム及び／又はアプリケーションアセット（例えば、ＶＣＲノード及びノードプロパティ、ＶＣＲスキーマ及びスキーマプロパティ、オペレーティングシステムリソース、バーチャルマシンリソース、Ｊ２ＥＥアプリケーションリソース、及びある種のソフトウェア／ファームウェアにより使用できるか又はその一部分である他のエンティティ）である。通常、リソースは、親／子関係が確立されるように１つ以上のハイアラーキーで構成することができる（例えば、ＶＣＲハイアラーキーネームスペース及びスキーマ継承ハイアラーキー）。これらの実施形態の幾つかにおいて、ロールに対する収容モデルは、子のリソースがそれらの親に関連したロールを継承できるものが続く。更に、子のリソースは、それらの親のロールを、それら自身のロールでオーバーライドすることができる。
【００３６】
種々の実施形態において、メンバーシップ基準は、ノードのプロパティに少なくとも一部分基づくことができる。これは、ユーザ／プロセスに関する情報を、例えば、ＶＣＲのコンテンツと比較できるロールを許す。種々の実施形態において、ノードのプロパティは、ドット表示、即ちＡｒｔｉｃｌｅ．Ｃｒｅａｔｏｒは、Ａｒｔｉｃｌｅ（記事）ノードのＣｒｅａｔｏｒ（生成者）プロパティである、を使用してプログラムでアクセスすることができる。説明上、ニュース記事を表わしそして２つのプロパティＣｒｅａｔｏｒ及びＳｔａｔｅ（状態）を含むＡｒｔｉｃｌｅノードを仮定する。システムは、Ｃｒｅａｔｏｒプロパティを、その記事を生成したユーザの名前に自動的にセットすることができる。Ｓｔａｔｅプロパティは、パブリケーションのライフサイクルの観点（例えば、記事が草案であるか又はパブリケーションとして承認されたものであるか）から記事の現在状態を指示する。この例では、２つのロールが定義される（テーブル２を参照）。
【００３７】
テーブル２：一実施形態におけるロールの一例
2007520785.tif 000004
【００３８】
Ｓｕｂｍｉｔｔｅｒ（提出者）及びＡｐｐｒｏｖｅｒ（承認者）のロールは、Ａｒｔｉｃｌｅ（記事）ノードに関連している。このスキーマからインスタンス生成されるコンテンツノードは、これらのロールを継承する。記事にアクセスしようと試みるユーザが記事の生成者であり、そして記事の状態が草案である場合には、ユーザは、Ｓｕｂｍｉｔｔｅｒのロールにある。同様に、ユーザがＥｄｉｔｏｒ（編集者）グループに属しそして記事の状態が提出又は承認である場合には、ユーザは、Ａｐｐｒｏｖｅｒのロールに属することができる。
【００３９】
種々の実施形態において、ポリシー(policy)を使用して、所与のリソース(resource)に対してどんな能力又は特権(privilege)がポリシーの主題(Subject)（例えば、ユーザ（１人又は複数）、グループ（１つ又は複数）及び／又はロール（１つ又は複数））に得られるか決定することができる。説明上、ポリシーは、次のように記述することができる。
Policy = Resource + Privilege (s) + Subjects + [Policy Criteria]
【００４０】
ポリシーマッピングは、もしあれば、ポリシー基準を評価して、どんな主題がリソースに対する１つ以上の特権へのアクセスを許可されるか決定するプロセスである。ポリシー基準(Policy Criteria)は、１つ以上の条件を含むことができる。説明上、このような条件は、１つ以上の（考えられるネスト型及び混合型）ブール、数学的、機能的、関連性、及び／又は論理的表現を含むが、これらに限定されない。幾つかの実施形態の態様は、リソースに対してアクセス判断が行われる直前にポリシーマッピングを許す。
【００４１】
ロールと同様に、これら実施形態の幾つかにおいて、ポリシーに対する収容モデルは、子のリソースがそれらの親に関連したポリシーを継承できるものが続く。更に、子のリソースは、それらの親のポリシーを、それら自身のポリシーでオーバーライドできる。
【００４２】
種々の実施形態において、ノードのポリシーは、ノードに関連した特権へのアクセスを制御することができる。説明上、次のポリシーが与えられると、
Policy1 = Printer504 + Read/View + Marketing
Policy2 = Printer504 + All + Engineering
マーケッティング(Marketing)のロールは、Ｐｒｉｎｔｅｒ５０４リソースを読み取り／見て、ブラウズし、一方、エンジニアリング(Engineering)ロールは、それに完全にアクセスできる（‘All’）。これらの特権がテーブル３に要約されている。Ｐｏｌｉｃｙ１は、マーケッティングロールのユーザがＰｒｉｎｔｅｒ５０４のプロパティを単に見るのを許し、一方、Ｐｏｌｉｃｙ２は、エンジニアリングロールのユーザがそのプロパティを見て変更し、Ｐｒｉｎｔｅｒ５０４に基づいてコンテンツノードを生成し（それがスキーマであると仮定して）、そしてリソースを削除するのを許す。
【００４３】
テーブル３：種々の実施形態における「Ｐｒｉｎｔｅｒ５０４」ノードの特権の例
2007520785.tif 000005
【００４４】
これら実施形態の幾つかの態様は、親の特権がポリシーにより許可された場合に親の特権の子の特権（１つ又は複数）が自動的に許可されるような、特権に対する暗示的ハイアラーキーを含む。説明上、「ブラウズ」特権は、Ｐｒｉｎｔｅｒ５０４ノードに対して優位性が最も低い特権であると考えられる。他の特権の追加は、「ブラウズ」を暗示的に含む。例えば、次の設定が「読み取り／見る」能力である場合は、「読み取り／見る」の選択は、「ブラウズ」特権を暗示的に含む。
【００４５】
種々の実施形態において、ポリシー及びロールの収容モデルは、ノードのプロパティが、ノードに生じるポリシー及びロールを継承するのを許すように拡張される。又、プロパティにおけるロール／ポリシーは、継承されたロール／ポリシーをオーバーライドすることができる。説明上、Ｐｒｉｎｔｅｒ５０４の電力(Power)プロパティについて次のポリシーを仮定する。
Policy3 = Printer504.Power + Update + Marketing
【００４６】
ポリシー３では、マーケッティングのロールは、プリンターリソースＰｒｉｎｔｅｒ５０４に対する電力プロパティを更新する権利（例えば、プリンタをオンにするかオフにするかを制御する）が許可される。デフォールトにより、暗示された特権ハイアラーキーに基づいて「読み取り／見る」プロパティも許可される。（このプロパティについては、「ブラウズ」特権はない。）テーブル４を参照されたい。或いは又、暗示された特権ハイアラーキーが存在しない場合には、電力プロパティは、マーケッティングロールに対する「読み取り／見る」特権をその親であるＰｒｉｎｔｅｒ５０４から継承する。電力プロパティ及びエンジニアリングロールについてはポリシーが指定されないが、エンジニアリングロールに基づく特権は、親ノードから継承することができる。これらの特権を、テーブル４に要約する。
【００４７】
テーブル４：「Ｐｒｉｎｔｅｒ５０４」ノードの「電力」プロパティに対する特権の例
2007520785.tif 000006
【００４８】
種々の実施形態において、スキーマに基づいてノードをインスタンス生成する能力を特権とすることができる。これを使用して、ユーザ又はプロセスによりどの形式のコンテンツを生成できるか制御できる。説明上、次のポリシーを仮定する。
Policy4 = Press_Release + Instantiate + Marketing, Manager
【００４９】
ポリシー４は、スキーマＰｒｅｓｓ＿Ｒｅｌｅａｓｅに基づいて生成されたノードは、マーケッティング及び／又はマネージャーロールのメンバーであるユーザ／プロセッサでなければインスタンス生成できないことを指定する。これら実施形態の幾つかの態様において、ユーザインターフェイスは、これらポリシーの知識を使用して、得られるユーザ選択を制限することができる（例えば、ユーザは、「インスタンス生成」特権を有するところのスキーマを見て選択することができればよい。）
【００５０】
種々の実施形態において、ポリシーは、スキーマに配置することができる。スキーマのインスタンス（例えば、コンテンツノード）は、よりローカルなポリシーによりオーバーライドされない限り、これらのポリシーを継承することができる。説明上、次のポリシーを仮定する。
Policy5 = Press_Release + Read/View + Everyone
Policy6 = Press_Release + All + Public_Relations
【００５１】
テーブル５：「プレス・リリース(Press Release)」スキーマに対する特権の例
2007520785.tif 000007
【００５２】
テーブル５を参照すれば、説明上、「プレス・リリース」スキーマに基づいてコンテクストノードインスタンスが生成されたと仮定する。デフォールトにより、これは、「プレス・リリース」スキーマと同じロール／ポリシーを有する。ロール「編集者」にノードを更新する特権を与えるポリシーがノードに追加された場合には、その結果が加算的となる。即ち、Ｅｖｅｒｙｏｎｅ（誰か）及びＰｕｂｌｉｃ  Ｒｅｌａｔｉｏｎ（広報）は、それらのオリジナル特権を維持する。
【００５３】
種々の実施形態において、ポリシーは、プロパティ選択を含むスキーマ内のプロパティに配することができる。（プロパティ選択は、所与のプロパティに対する許容値の所定のセットである。例えば、「カラー」プロパティは、プロパティ選択「赤」、「緑」及び「青」をもつことができる。）スキーマのインスタンス（例えば、コンテンツノードにおける）は、よりローカルなポリシーによりオーバーライドされない限り、これらのプロパティポリシーを継承する。
【００５４】
種々の実施形態において、コンテンツ及びスキーマノードは、ライフサイクルをたどることができる。これら実施形態の幾つかの態様において、ライフサイクルは、ノードが通ることのできる状態のセット、状態移行の一部分として生じるか又はその結果得られるアクション、及びライフサイクルに参加できるアクターを規定することができる。説明上、ライフサイクルを使用して、組織のコンテンツ承認プロセスをモデリングすることができる。種々の実施形態において、ライフサイクルは、ライフサイクル内にネスト状にすることができる。これは、操作及び開発が容易なように複雑なライフサイクルを区画化するのを許す。種々の実施形態は、ライフサイクルの定義、拡張可能なライフサイクルシステム、ライフサイクル定義を発生及び／又は変更するための対話型ライフサイクル設計ツール、及び他のシステムと対話するためのライフサイクルの手段とを備えている。コンテンツレポジトリーがライフサイクルをネーティブにサポートしない場合には、ＶＣＲによりサポートを与えることができる。
【００５５】
種々の実施形態において、ライフサイクルは、ノードに関連付けてもよいし、又はノードのプロパティでもよい。これら実施形態の態様において、ライフサイクルがハイアラーキーノードに関連付けられる場合には、ハイアラーキーノードの子も、ライフサイクルに関連付けられる。同様に、ライフサイクルがスキーマに関連付けられる場合には、スキーマに基づいてインスタンス生成されるノードもライフサイクルに関連付けられる。又、ライフサイクルをコンテンツノードに直接関連付けることもできる。
【００５６】
種々の実施形態において、説明上、ノードは、現在状態から新たな状態へ移行することができる。移行の前、移行中、又は以降の後に、１つ以上のアクションをとることができる。これらアクションは、ノードに任意に作用し及び／又はノードを利用することができる。これらアクションは、ライフサイクル中に呼び出すことのできる任意の形式の処理を含むことができる。例えば、これらアクションは、機能／方法コール、リモート手順コール、プロセス間通信、プロセス内通信、ハードウェア装置とのインターフェイス、バージョン制御への／からのノードのチェック、ユーザ、グループ又はロールへのノードの指定、ノードに対するある種の処理の実行（ノードにおいて定義できるポリシーに基づく）、ユーザ、グループ及び／又はロールへの通知の付与、並びに他の適当な処理を含むことができる。又、これらアクションは、要求された処理を識別するように解釈し又はマップすることのできるコマンド（１つ又は複数）、ディレクティブ（１つ又は複数）、表現（１つ又は複数）、或いは他の構成として指定することもできる。例えば、「パブリッシュ」のような高レベルアクションディレクティブは、コンテンツノードをパブリッシュさせると共に、ｅメール又は他のメッセージをある当事者へ送信させることができる。当業者であれば、いかなるアクションも本開示の精神及び範囲内にあることが明らかであろう。
【００５７】
ニュース記事を表わすコンテンツノードに対するライフサイクルの例が、テーブル６及び図２に示されている。状態は、図２に、ドキュメントアイコン（２０４、２０８、２１２、２１６）として示され、そして状態と状態との間の判断ポイントは、円（２０６、２１０、２１４）として示されている。状態と状態との間の移行は、状態の順序を示すように方向付けされた線として示されている。これら実施形態の幾つかの態様において、状態と状態との間の移行は、１つ以上の判断ポイントを通過できる。判断ポイントは、移行をユーザ（１つ又は複数）、グループ（１つ又は複数）及びロール（１つ又は複数）に制約すると共に、もしあれば、状態の変化を付随し得るアクション（１つ又は複数）を指定するための視覚プレースホルダー（例えば、ＩＤＥグラフィックエディタ）である。判断ポイントは、状態を少なくとも１つの他の状態に接続することができる。あるクラスのユーザ／プロセス特権を異なる状態において許すために、ノードに関連され且つライフサイクル状態（例えば、状態はノードのプロパティである）からキーオフされたポリシー及び／又はロールによりアクションを制御することができる。
【００５８】
テーブル６：種々の実施形態におけるライフサイクルの例
2007520785.tif 000008
【００５９】
図２のライフサイクルの例は、「開始」状態２０２で始まり、これは、ライフサイクルの次の状態、即ち「草案」状態２０４へ非制限移行する。移行は、非制限であるか、又はユーザ（１人又は複数）、グループ（１つ又は複数）及び／又はロール（１つ又は複数）のセットに制限することができる。これら実施形態の幾つかにおいて、ロールは、デレゲートされたアドミニストレーションを経てユーザへデレゲートすることができる。説明上、承認能力は、デレゲートされたアドミニストレーションモデルの能力をベースとすることができる。一実施形態においては、制限により、ある許可されたユーザ／プロセスしか次の状態へ移行できないようにされる。種々の実施形態において、ツールを通してノードと対話するユーザにより、及び／又はＶＣＲ  ＡＰＩを通してノードと対話するプロセスにより、状態変更を開始することができる。これら実施形態のある態様において、ノードの現在状態は、ノードのプロパティである。例えば、状態プロパティを変更すると（例えば、ユーザ／プロセスが許可を受けたと仮定して、「開始」から「草案」へ変更すると）、それに付随するライフサイクル処理を行わせ、例えば、その移行において定義されたアクションを実行することができる。
【００６０】
ニュース記事は、「草案」状態にある間にユーザ（１人又は複数）及び／又はプロセス（１つ又は複数）により変更し、次いで、承認のために提出することができる。例えば、ユーザは、ニュース記事をチェックアウトし（それがバージョン制御のもとにあると仮定して）、それを変更し、次いで、変更と共に記事をチェックインすることができる。記事をチェックインする前に、ユーザは、状態プロパティを「草案」から「承認準備」へ変更し、「承認のための準備２０８」状態への移行を生じさせることができる。更なる説明上、ユーザインターフェイスは、ユーザが記事の編集を終了したときに生成者が選択できるボタン又はメニューオプションを与えることができる。選択されると、記事は、ライフサイクルへ自動的に提出することができ、そこで、次の状態へと進行することができる。この説明において、判断ポイントＤ１（２０６）を経て「承認準備」状態へ至る移行は、「生成者」ロールのユーザに制限される。従って、記事を生成したユーザ／プロセスでなければ、記事を「承認準備」状態へ移行させることができない。
【００６１】
「草案」から「承認準備」への移行は、付随のアクション「提出」も有する。例えば、このアクションは、承認のために記事を再検討することに関心のある者へ通知を送信させることができる。それとは別に、又はそれに加えて、ニュース記事をユーザ／グループ／ロールに指定することができる。このように、指定のユーザ／グループ／ロールの中のユーザ／プロセスは、「承認準備」状態にある間にそれを再検討することができる。「承認準備」状態から、判断ポイントＤ２（２１０）を経て移行がなされる。このＤ２判断ポイントは、承認者ロールにおけるユーザ／プロセスが「草案」状態２０４又は「パブリッシュ済」状態２１２への移行を生じさせることを指定する。「草案」状態への移行の場合には、その移行に関連したアクションが、記事を「拒絶」することである。拒絶された記事は、「草案」から「承認準備」へのライフサイクル経路を繰り返す。しかしながら、「パブリッシュ済」状態への移行である場合には、アクションが記事を「受け容れる」ことである。記事が「パブリッシュ済」状態になると、編集者又は生成者のロールにおけるユーザ／プロセスが「リタイヤ済」状態２１６への移行を生じさせることができる。生成者のロールにおけるユーザは、「草案」状態への移行を生じさせることができる。「パブリッシュ済」状態から「草案」状態への移行は、「更新」アクションを生じさせ、一方、「パブリッシュ済」状態から「リタイヤ済」状態への移行は、「リタイヤ」アクションを生じさせる。
【００６２】
これら実施形態の態様において、上位のロールが、下位のロールに必要な状態移行をスキップできるように、ロールをロールハイアラーキーに編成できる。説明上、「承認者」ロールが「生成者」ロールより上位にあると想定する。記事の現在ライフサイクル状態が「草案」である場合には、「承認者」のロールにおけるユーザが、「承認準備」状態をスキップし、そして記事を「パブリッシュ済」状態へと完全に移行させることができる。一実施形態では、「承認準備」状態をスキップしても、判断ポイントＤ１及びＤ２に関連したアクションを自動的に呼び出すことができる。
【００６３】
種々の実施形態において、説明上、ライフサイクルは、テキストエディタ及び／又はＩＤＥを使用して定義することができる。テキストエディタから、ユーザは、完全なライフサイクル定義をある言語（例えば、ＸＭＬ）で生成することができる。グラフィック環境において、ユーザは、異なる状態を生成し、次いで、それらを一緒に接続して、移行を表わすことができる。一実施形態では、ライフサイクルのグラフィック表示が図２のように現われる。状態及び判断ノードのグラフィック表示は、ＩＤＥキャンバスに配置して、移行を形成するように接続することができる。グラフィックオブジェクトに関連したプロパティシートは、ユーザが、状態及び移行に関連したロール及びアクションを対話式に指定するのを許すことができる。これら実施形態の態様において、ユーザは、ライフサイクルのグラフィック表示とテキスト表示との間を容易に切り換えることができる。というのは、両方の表示が同等だからである。
【００６４】
種々の実施形態において、第三者ライフサイクルエンジンを呼び出すことができる。これは、付加的な機能をライフサイクルモデルにシームレスに組み込むことを許す。一実施形態では、これは、ライフサイクル内からライフサイクルアクションを通して実行することができる。別の実施形態では、コールバックメカニズムを介して第三者ライフサイクルを呼び出すことができる。説明上、ＶＣＲ  ＡＰＩは、例えば、コンテンツノード／筋書きが変更され及び／又はその状態プロパティが切り換えられたときに、ある事象に応答して第三者ライフサイクルを呼び出すことができる。この説明においては、第三者ライフサイクルを実施するプロセスは、これら事象が生じたときにコールバックを受け取るように登録することができる。又、コールバック通知は、ＶＣＲノード識別子及び任意のコンテクスト情報、例えば、その事象を生じさせたユーザ／プロセスに関する情報も含むことができる。
【００６５】
種々の実施形態において、ライフサイクルは、他のプロセスから利用することができる。ＶＣＲ  ＡＰＩは、ノードのライフサイクル定義へのアクセスを許すライフサイクルインターフェイスを備えている。更に、ライフサイクルインターフェイスは、ノードの現在状態を確かめ、その現在状態から得られる移行選択に基づいて新たな状態にノードを入れ、そして状態移行に関連したアクションを呼び出すための能力のような機能を与えることにより、ライフサイクルを通してノードを駆動するプロセスを許す。
【００６６】
図３は、種々の実施形態においてライフサイクルを呼び出す外部筋書きを例示する図である。ＩＤＥから、ユーザは、図３に示すような筋書きの視覚表示を生成することができる。この説明において、筋書きは、出発点３０２アイコンと、それに続いて、クライアント要求を受け取るためのプロセスを表わすクライアント要求制御アイコン３０４とを備えている。要求が受け取られた後に、筋書きは、「ｗｈｉｌｅ」ループ３０６に入る。このループ内で、ＶＣＲライフサイクルを表わすライフサイクル制御アイコン３０８が、それに関連したライフサイクルを呼び出すようにさせる。ライフサイクル制御は、ライフサイクルと、そのライフサイクルを通して推進するノードとを識別する関連プロパティをもつことができる。これら実施形態の態様において、制御は、ＪａｖａTM制御である。ライフサイクル制御は、ＶＣＲ  ＡＰＩのライフサイクルインターフェイスを使用してライフサイクルを通してノードを推進することができる。ライフサイクルが完了した後に、この筋書きは、ライフサイクル完了の通知を種々のユーザ／プロセスへ送信させることのできる通知制御３１０を呼び出す。
【００６７】
このシステムの種々の実施形態は、ノードのライフタイムにわたって状態の経歴が維持されるようにノードに使用可能なバージョン制御能力を含む。種々の実施形態では、ノードの１つのバージョンは、パブリッシュ済バージョンであると考えられる。これら実施形態の幾つかの態様において、バージョンは、名前（又は他の適当な識別子）が与えられ、そして特定のノードに関連したバージョンリストを経てこれを記憶し又はこれにアクセスすることができる。これら実施形態の態様において、ＶＣＲは、ノードが存続するレポジトリーがない場合にバージョニングのサポートを与えることができる。
【００６８】
種々の実施形態において、ノードのバージョンは、バージョンを最後に変更したユーザ／プロセスの識別、及び記述又はコメントも含むことができる。バージョン制御のもとにあるノードは、ＶＣＲ内で移動され又はコピーされ得る。種々の実施形態において、バージョン経歴は、移動又はコピー中にノードと共に進行する。ユーザ又はプロセスがコンテンツノードを移動するときに、そのノードの経歴もそれと共に移動する。ロールバックの場合には、ロールバックの親バージョンを経歴において指示することができる。種々の実施形態において、ノードのバージョンは、以前のバージョンへ「ロールバック」（即ち、復帰）することができる。これら実施形態の態様において、ロールバックの際に、復帰すべく選択されたコンテンツノードバージョンが、コンテンツノードの最後のバージョンとなる。これら実施形態の幾つかにおいて、ロールバックされたバージョンには、新たなバージョン識別子（例えば、古いバージョン番号+１）が自動的に与えられる。
【００６９】
各ノードは、ロック（例えば、ノードへのアクセスを制御するためのセマフォ又は他の適当な手段）をもつことができる。このロックは、同時に２つ以上のユーザ／プロセスによりノードが変更されるのを防止する。ノードがバージョン制御をチェックアウトすると、ユーザは、ロックを取得する。ロックの取得は、他のものが、ノードがチェックインされるまでノードに関連したバージョンをチェックアウトするのを防止する。ロックは、ノードレベル又はバージョンレベルで使用することができる。バージョンレベルのロックが使用される場合には、ノードの２つ以上のバージョンを同時にチェックアウトすることが可能である。所与のノード、レポジトリー及び／又はＶＣＲに対してバージョン制御をターンオン／オフすることができる。一実施形態において、バージョン制御を使用しないノードは、そのバージョンリストに単一のバージョンしかもたない。
【００７０】
バージョニングは、ユーザ又はプロセスがノードのバージョンを編集のためにチェックアウトする能力を含む。説明上、ユーザは、ＶＣＲのツリーブラウザビュー内のあるアイテムをクリックすることができる（図４及び付随のテキストを参照）。これら実施形態の態様において、ユーザ又はプロセスは、ユーザ又はプロセスは、ノードのどのバージョンをチェックアウトすべきか選択することができる。ツリーブラウザは、各バージョンに対して次の情報を表示することができる（例えば、ポップアップメニュー又はツールチップを経て）：バージョン番号／識別子、最後にセーブされた日付バージョン、最後のセーブを実行したユーザ／プロセス、及び任意のコメント（１つ又は複数）。種々の実施形態において、ユーザは、ツリーブラウザのようなユーザインターフェイスの助けで特定ノードのバージョン経歴を対話式にブラウズすることによりチェックアウトすべきバージョンを選択することができる。一実施形態において、バージョンが指定されない場合には、ノードの最も最近のバージョンがデフォールトによりチェックアウトされる。
【００７１】
一実施形態では、ユーザインターフェイスは、ノードのプロパティのレンダリングを与えることができる。例えば、ユーザは、「編集コンテンツ」ボタンを選択して、ノードのプロパティを編集することができる。このアクションは、ノードがまだチェックアウトされていない場合にそれをチェックアウトするように試みることができる。種々の実施形態において、所与のユーザのチェックアウトされたノードがユーザのワークスペースに現われる（図４を参照）。ユーザは、それらのワークをチェックインの時間までセーブすることができる。種々の実施形態において、「セーブ」されたノードは、バージョンを変更することもないし、バージョンの増加を与えることもない。他のユーザのパースペクティブから、ノードは依然としてチェックアウトされる。ユーザが編集を終了すると、変化を破棄することができ又はＶＣＲへチェックインすることができる。
【００７２】
チェックインの際に、ノードの新たなバージョンがシステムに得られる。種々の実施形態において、ノードをチェックインすると、ノードはＶＣＲに現われるが、ユーザのワークスペースには現われない。ユーザ／プロセスは、チェックイン時間中にノードに対してなされた変化の記述を入力することができる。この記述は、バージョンと共にセーブすることができる。又、ノードをワークスペースにチェックインすると、それに関連したロックが解除され（従って、他のものが編集を行える）、そしてバージョニングがターンオンされた場合には、ノードの新たなバージョンを生成する。しかしながら、ユーザが、それらのワークを、チェックインするのではなく、単にセーブする場合には、ノードがワークスペースに留まり、新たなバージョンは発生されない。これら実施形態の態様において、ライフサイクルがノードに関連付けされる場合には、ノードをチェックインすると、ノードをライフサイクルに提出することができる。
【００７３】
説明上、図２を参照すれば、「生成者」のロールにおけるユーザは、ニュース記事の状態を「承認準備」へ変更し、次いで、それをチェックインすることにより、新たな記事を承認のために提出することができる。一実施形態では、状態プロパティを指定できるところの状態のドロップダウンリストがユーザに利用できるようにされる。このドロップダウンリストは、ユーザのロール及び／又はライフサイクルの段階に基づいてフィルタされ得る。チェックインの後に、「承認者」のロールにおけるユーザのワークスペースが、ユーザに指定されたアイテムとしてニュース記事を示すように更新を行う。又、種々の実施形態において、「承認者」は、ニュース記事を得て再検討できることを示すための警告（例えば、ｅメール、インスタントメッセージ、ページ等）も受け取ることができる。承認者は、ニュース記事を編集することを選択すると、それをチェックアウトすることができる。承認者がロックを取得すると、このアイテムは、「承認者」ロールにおける誰かのワークスペースの「指定アイテム」部分から消える。
【００７４】
種々の実施形態において、ユーザ／プロセスは、あるノードへナビゲートし、そして削除アクションを実行することができる。一実施形態において、ノードを削除すると、その状態が変化する（例えば、リタイヤ済又は削除済へ）。ユーザは、削除された全てのノードを後で見て、それらを永久的に削除するか又は非削除するように選択することができる。別の実施形態では、ノードを削除すると、それがＶＣＲから永久的に除去される。一実施形態では、ノードは、そのライフサイクルの状態に関わらず削除することができる。一実施形態では、ノードは、それがチェックアウトされない場合には、削除できない。又、一実施形態では、ノードを削除すると、ノードの子供全員が削除される。又、一実施形態では、ノードのチェックインされた子供だけが削除される。更に別の実施形態では、削除されたノード（及び任意であるが、その子供）を非削除とすることができる。
【００７５】
図４は、本発明の種々の実施形態におけるユーザインターフェイスを例示するものである。例えば、ユーザインターフェイスは、次の１つ以上を含むことができる。１）グラフィックユーザインターフェイス（ＧＵＩ）（例えば、ハイパーテキストマークアップ言語でレンダリングされる）；２）サウンド及び／又はボイスコマンドに応答する能力；３）リモートコントロール装置（例えば、セルラー電話、ＰＤＡ、又は他の適当なリモートコントロール）からの入力に応答する能力；４）ジェスチャー（例えば、顔面等）に応答する能力；５）同じ又は別のコンピューティング装置のプロセスからのコマンドに応答する能力；６）コンピュータマウス及び／又はキーボードからの入力に応答する能力。この開示は、特定のユーザインターフェイスに限定されない。当業者であれば、本開示の精神及び範囲内で多数の他のユーザインターフェイス実施形態も考えられることが明らかであろう。
【００７６】
種々の実施形態に基づくユーザインターフェイスは、説明上、ユーザがＶＣＲ及びそれらのワークスペースと対話し且つ探求するのを許すためにこの分野で良く知られたインタラクティブグラフィックツリーブラウザを含むことができる。ツリーブラウザは、ノード及びスキーマのハイアラーキービューを与える。ノードのインデントレベルは、親／子関係を示す。種々の実施形態において、ツリーブラウザは、ＶＣＲの１つ以上のビューを与えることができる。これらのビューは、パブリッシュされたノード、非パブリッシュノード、リタイヤされたノード、削除されたノード、指定されたノード、ロックされたノード、及び承認を待機しているノードを含むことができる（これらに限定されない）。これら実施形態の態様において、ユーザは、これらビューの１つ以上を含むようにツリーブラウザをカスタマイズすることができる。これらビューは、個別のツリーとして与えることもできるし、合併したツリーとして与えることもできる。種々の実施形態において、これらビューは、特定のユーザ（１人又は複数）に対して自動的にカスタマイズすることができる。例えば、ノードを装飾するロール及び／又はポリシーは、ビューをフィルタリングするのに使用できる。説明上、指定されたアイテムのビュー及び承認を待機しているビューは、所与のユーザに適用できるノードしか示さない。一実施形態では、これは、ライフサイクル移行においてロールを検査し、そして所与のユーザが対話できないライフサイクルに対してノードをフィルタ除去することにより達成できる。
【００７７】
説明上、ツリーブラウザは、ＶＣＲ４００、即ちフェデレート化ルートを露出させることができる。これは、２つのレポジトリー（ネプチュン(Neptune)４０２及びプルト(Pluto)４１２）と、パブリックハイアラーキーノード４２６とを含む。種々の実施形態において、ノードは、それらの目的を示すためにフォルダー又は関連視覚記号でデコレーションすることができる。これら幾つかの実施形態の態様において、フォルダーアイコン又はハイアラーキーノードネームを選択すると、ノードのコンテンツをツリーにおいてその下に拡張させる。これら実施形態の更に別の態様において、任意の形式のノードを選択すると、ユーザがそのノードのプロパティを編集するのを許すことができる。一実施形態では、フェデレート化ルート（図示せず）の真下を含むＶＣＲのどこかでスキーマを定義することができる。レポジトリーで定義されないスキーマ（例えば、４２８、４３０及び４３４）は、種々の実施形態においてバーチャルと考えられる。ネプチュンレポジトリー４０２は、２つのレポジトリーノード、即ちプレス・リリース(Press Releases)４０４及びオールド・スキーマ(Old Schemas)４０８を含む。プレス・リリースは、ジャパン・アカウント(Japan Account)４０６という名前のコンテンツノードを含み、これは、その名前の次のパッドロックアイコンで指示されたように、現在ロック（例えば、チェックアウト）されている。ノードをチェックアウトしたユーザだけがそれを編集できる。他のものは、ロール及び／又は特権に基づいてそれを任意に見ることができる。オールド・スキーマのハイアラーキーノードは、アカウント・スキーマ(Account Schema)４１０という名前のスキーマを含み、これは、現在アンロックである。これら実施形態の態様において、ノードのプロパティは、ツリーブラウザにおいてノードを選択することにより見ることができる。選択されたノードがロックされない場合には、システムは、ユーザに代わってロックを得るように自動的に試みることができる。
【００７８】
プルトレポジトリーは、スキーマ４１４及び２つのトップレベルハイアラーキーノード（４１６、４１８）を備えている。ハイアラーキーノードの一方、２００３メモ(Memos)４１６は、ソリッドカラーであるフォルダー記号を有し、そしてその他方は、フォルダー記号４１８の輪郭を有する。一実施形態において、特殊な視覚記号（例えば、ソリッドフォルダーアイコン）は、ハイアラーキーノードがスキーマ及び／又はそれに関連したライフサイクルを有することをユーザに指示できる。種々の実施形態において、スキーマ及び／又はライフサイクルをハイアラーキーノードに関連付けると、スキーマ及び／又はライフサイクルがハイアラーキーノードの子供に課せられるか又はそれにより継承されることになる。２００４メモのハイアラーキーノードは、別のハイアラーキーノード４２０、アンロックのコンテンツノード４２２、及びロックされたコンテンツノード４２４を含む。
【００７９】
種々の実施形態において、ユーザインターフェイスは、ユーザの新たな、チェックアウトされた及び指定されたアイテムへの迅速なアクセスを与える論理的なワークスペース(Workspace)フォルダー４３６を与えることができる。指定されたアイテムとは、ライフサイクル又は他の適当な手段に基づいて１つ以上のユーザ、グループ及び／又はロールに指定されるものである。この説明において、ジャパン・アカウント(Japan Account)４４４及びインターナル・メモ・スキーマ(Internal Memo Schema)４４６の２つのノードがユーザに指定される。ユーザは、チェックアウトされたジャパン・アカウントノードを有する。というのは、これが、現在チェックアウトされないインターナル・メモ・スキーマとは異なり、パッドロックをそばに伴ってＶＣＲツリーに現われるからである。ユーザは、スタッフ・チェンジ(Staff Change)スキーマ４３４をチェックアウトしない。というのは、それらがワークスペースに現われない（即ち、別のユーザ又はプロセスがそれをチェックアウトする）からである。種々の実施形態において、スタッフ・チェンジスキーマ４３４を選択することにより、ユーザは、誰がロックを保持するかそしていつそれを得たか発見することができる。
【００８０】
種々の実施形態において、更なる説明上、新たなノードを生成することができる。新たに生成されたノードは、それらがＶＣＲにおいてパブリッシュされるまで、それらを生成したユーザのワークスペースに現われることができる。幾つかのこれら実施形態の態様は、新たなノードがＶＣＲ、レポジトリー又はハイアラーキーノードのどれに存在するかユーザが選択できるようにするユーザインターフェイスを経てユーザが新たなノードを生成するのを許す。ユーザは、新たなノードに対してバージョン経歴を維持すべきかどうか指示できると共に、プロパティをそれに追加するか又はスキーマにおけるそのプロパティをベースとすることができる。新たなノードに対するライフサイクルも指定できる。ツリーブラウザは、新たなノードの追加を反映するように更新することができる。
【００８１】
図５は、本発明の種々の実施形態においてレポジトリーをＶＣＲに接続するのに使用できるオブジェクト／インターフェイスを例示する図である。この図は、コンポーネントを論理的に個別に示すが、このような描写は、例示的なものに過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアへと任意に結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【００８２】
ＲｅｐｏｓｉｔｏｒｙＭａｎａｇｅｒ（レポジトリーマネージャー）５０２は、アプリケーションプログラム５００の観点からＶＣＲの表示として働くことができる。これら実施形態の態様において、ＲｅｐｏｓｉｔｏｒｙＭａｎａｇｅｒは、使用可能な全てのレポジトリーをＶＣＲ（例えば、５１２−５１６）に、任意であるがユーザ又はプロセス証明書に、接続するよう試みる。種々の実施形態において、これは、ＪａｖａTM認証及び許可サービス（サン・マイクロシステムズ・インクから入手できる）をベースとすることができる。当業者であれば、本開示の精神及び範囲から逸脱せずに、多数の許可機構が考えられることが明らかであろう。各々の使用可能なコンテンツレポジトリーは、ＳＰＩレポジトリーオブジェクト５０６−５１０により表わされる。ＲｅｐｏｓｉｔｏｒｙＭａｎａｇｅｒは、レポジトリーオブジェクトのセットにおけるｃｏｎｎｅｃｔ（）メソッドを呼び出すことができる。種々の実施形態において、ＲｅｐｏｓｉｔｏｒｙＭａｎａｇｅｒは、接続が試みられたレポジトリーごとに一度、アプリケーションプログラムへレポジトリーセッションオブジェクトのリストを返送する。接続手順におけるエラーは、セッションオブジェクトの状態により記述することができる。別の実施形態では、ＲｅｐｏｓｉｔｏｒｙＭａｎａｇｅｒは、レポジトリーの名前が与えられた特定のレポジトリーに接続することができる。種々の実施形態において、レポジトリーの名前は、ＵＲＩ（ユニフォームリソース識別子）である。
【００８３】
図６は、本発明の種々の実施形態においてサービスモデルとして使用できるオブジェクト／インターフェイスを例示する図である。この図は、コンポーネントを論理的に個別に示すが、このような描写は、例示的なものに過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアへと任意に結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【００８４】
図６を参照すれば、破線矢印は、矢印が出てくるところのオブジェクト／インターフェイスが、ランタイムに、矢印が指すオブジェクトインターフェイスを形成できることを指示する。チケット６０２は、ＶＣＲサービスオブジェクト／インターフェイス：ＮｏｄｅＯｐｓ６０４、ＷｏｒｋｓｐａｃｅＯｐｓ６０６及びＳｅａｒｃｈＯｐｓ６０８へのアクセスを与えるＡＰＩレベルオブジェクト／インターフェイスである。ＶＣＲに接続された各レポジトリーは、これらオブジェクト／インターフェイスのあるものをＳＰＩの一部分として実施する。チケット６０２のオブジェクト／インターフェイスは、軽量であることが意図される。従って、ＶＣＲにアクセスする各アプリケーション／プロセスに対して１つ以上が生成されそしておそらくキャッシュされる。チケットは、ユーザ又はプロセスの証明書を使用して、サービスを許可することができる。種々の実施形態において、チケットは、ＮｏｄｅＯｐｓ６０４、ＷｏｒｋｓｐａｃｅＯｐｓ６０６及びＳｅａｒｃｈＯｐｓ６０８のアクセスポイントである。
【００８５】
説明上、レポジトリー６２２は、ＮｏｄｅＯｐｓ６１０、ＷｏｒｋｓｐａｃｅＯｐｓ６１２及びＳｅａｒｃｈＯｐｓ６１４を与える。レポジトリー６２４は、ＮｏｄｅＯｐｓ６１６、ＷｏｒｋｓｐａｃｅＯｐｓ６１８及びＳｅａｒｃｈＯｐｓ６２０を与える。ＡＰＩレベルオブジェクト／インターフェイスは、それに対応するＳＰＩレベルオブジェクト／インターフェイスと通信する。このように、ＡＰＩレベルオブジェクトにおけるオペレーションを各レポジトリーに分散させて、各レポジトリーが、要求されたオペレーションを実行するように並列に機能できるようにする。従って、ＶＣＲにおけるレポジトリーの数をＮとすれば、全てのレポジトリーにおいて順次に実行するのに平均時間Ｍ＊Ｎを要するオペレーションは、理論的に、時間Ｍしか必要としない。
【００８６】
ＮｏｄｅＯｐｓ６０４は、ノードに対する生成、読み取り、更新、削除メソッドと、ＶＣＲにおけるノードプロパティとを与える。これら実施形態の態様において、ノード及びプロパティは、識別子、ＶＣＲにおける経路に基づき、或いは他の適当な相対的又は絶対的基準を介して、動作することができる。ＡＰＩ  ＮｏｄｅＯｐｓ６０４は、アクションを実行するための要求を受け取ると、その要求を１つ以上のＳＰＩ  ＮｏｄｅＯｐｓ（６１０、６１６）へマップすることができ、これらは、次いで、その関連レポジトリーを使用して要求を満足する。このように、ＡＰＩを利用するアプリケーション及びライブラリーは、個々のコンテンツレポジトリーではなく、単一のＶＣＲを見る。ＡＰＩに露出されたＮｏｄｅＯｐｓの機能は、次の物を含むことができる。
−所与のノードのプロパティ及びプロパティ定義を更新する
−所与のノードをその全ての子孫と共に所与のハイアラーキーの新たな位置へコピーする
−新たなコンテンツノードを所与の親の下に生成する
−新たなハイアラーキーノードを所与の親の下に生成する
−所与のノードにおいて全カスケード削除を実行する
−それ自身を含む所与のノードの経路において全てのノードを検索する
−所与の親ノードに対する子供のコンテンツノードを検索する
−所与の親ノードに対する子供のハイアラーキーノードを検索する
−ノードをそのＩＤに基づいて検索する
−ノードをその経路に基づいて検索する
−所与のハイアラーキーノードに対する子供のノードを検索する
−所与のハイアラーキーノードに対する親のノードを検索する
−全てのノードを所与の名前で検索する
−所与のノード及びプロパティｉｄに対してバイナリーデータを検索する
−ノードをその全ての子孫と共にハイアラーキー内の新たな位置に移動する
−所与のノードを命名し直すと共に、その全ての子孫経路を暗示的に命名し直す
−ハイアラーキーにわたり繰り返すのに使用できる繰り返しオブジェクトを得る
【００８７】
種々の実施形態において、ＷｏｒｋｓｐａｃｅＯｐｓ６０６は、チェックイン／チェックアウトノードに対するサービス、ノード／プロパティロッキング、アクセスノードバージョン経歴、ライフサイクル操作、ラベリング、及びジョブを含む、バージョニングのためのサービスを露出する。ＡＰＩ  ＷｏｒｋｓｐａｃｅＯｐｓ６０６は、アクションを実行するための要求を受け取ると、１つ以上のＳＰＩ  ＷｏｒｋｓｐａｃｅＯｐｓ（６１２、６１８）へ要求をマップすることができ、これは、次いで、それに関連したレポジトリーを使用して要求を満足させる。ＡＰＩに露出されるＷｏｒｋｓｐａｃｅＯｐｓ機能は、次のものを含む。
−チェックイン：ノードをアンロックし、そしてノードをそのワークバージョンと共にセーブする
−チェックアウト：ノードをロックし、それをロックしたユーザ／プロセスのみがそれをセーブするか又はチェックインして、新たなワークバージョンを生成できるようにする
−コピー：パブリッシュされたソースノードを行先へ繰り返しコピーする
−生成：新たなノード及びそれに対するワークバージョンを、それがノードにアタッチされる場合に、生成する
−削除：ノードバージョンを所与のバージョンと共に削除する
−ゲット：所与の経路においてノードをゲットする。
−ゲットバージョン：所与のバーチャルノードに対して全てのバージョンを返送する
−セーブ：ノード、及びノードの現在バージョンであるノードのワークバージョン（それがノードのアタッチされる場合）をセーブする
−提出：ノードをそのライフサイクルに提出する
【００８８】
種々の実施形態において、ＳｅａｒｃｈＯｐｓ６０８は、１つ以上のサーチ表現に基づいてＶＣＲ全体にわたりノード、プロパティ、及び／又はプロパティ値を検索するためのＡＰＩサーチサービスを提供する。ＡＰＩ  ＳｅａｒｃｈＯｐｓ６０８は、アクションを実行するための要求を受け取ると、その要求を１つ以上のＳＰＩ  ＳｅａｒｃｈＯｐｓ（６１４、６２０）へマップすることができ、これは、次いで、それに関連したレポジトリーを使用して要求を満足させる。ＡＰＩ  ＳｅａｒｃｈＯｐｓ６０８は、各ＳＰＩ  ＳｅａｒｃｈＯｐｓからのサーチ結果を結果セットへと合成する。種々の実施形態において、結果セットは、その結果セットにおけるアイテムに対して更に別のサーチを実行することで精錬することができる。
【００８９】
サーチ表現は、１つ以上の論理的表現、ブール演算子、ネスト状表現、変数、識別子、ノードの名前、機能／方法の呼び出し、リモート手順コール、数学的関数、数学的演算子、ストリング演算子、イメージ演算子、及び構造化問合せ言語（ＳＱＬ）を含むことができる（が、これらに限定されない）。又、サーチ表現は、自然言語問合せ、キーワードサーチ、ファジーロジック、近接表現、ワイルドカード表現、及びレンジングサーチ形式に対するサポートも含むことができる。種々の実施形態において、サーチ表現を満足するアイテムにおける実際のロール／ポリシーに基づいて結果セットを調整することができる。ユーザ／プロセスが見ることを許されないアイテムは、サーチ中、又は結果が収集された後に、フィルタリングすることができる。
【００９０】
これら実施形態の態様において、サーチ結果は、ランキングアルゴリズム及び基準に基づいてランク付けすることができる。一実施形態では、ランキングアルゴリズムは、結果セットにおけるアイテムがサーチ表現をどの程度満足するかに基づいて結果セットをランク付けすることができる。本発明の精神及び範囲内で他の多数のランキングアルゴリズムが考えられることが当業者に明らかであろう。種々の実施形態において、多数のランキングアルゴリズムを結果セットに適用できる。一実施形態では、所与のランキングアルゴリズムに対するランキング基準をユーザ／プロセスにより調整することができる。
【００９１】
種々の実施形態において、ジョブは、ノードのセットに対してＶＣＲオペレーションを実行する能力を与える。説明上、ジョブは、ノードのセットをグループとしてチェックイン及びチェックアウトするか、又はノードのグループを、ライフサイクルを通して一緒に送信するのに使用できる。これら実施形態の態様において、ジョブ識別子及び又はラベルをノードに関連付けて、特定のジョブ及び／又はラベルセットにそれが含まれたことを指示できる。一実施形態では、ジョブが承認の準備ができた場合に、ジョブ内の全てのノードがこの状態に到達する。種々の実施形態において、ラベルを使用して、ノードのレポジトリー又はグループにタグ付けすることができる。説明上、これは、異なるバージョンでノードのセットを参照する仕方を与える。更に説明上、ラベルを使用して表現をサーチすることができる。
【００９２】
種々の実施形態において、ＶＣＲの情報を外部フォーマットでエクスポートすることができる。これら実施形態の態様において、外部フォーマットは、情報のハイアラーキー構造を維持することのできるＸＭＬ又は他の適当な言語／表示（例えば、ＨＴＭＬ、自然言語、バイナリーファイル）である。ＶＣＲノードの全部又は幾つかをエクスポートすることは、ＶＣＲをバックアップし、ＶＣＲの情報を別のレポジトリーへ搬送し、そして後日にノードを再ロードするために、ＶＣＲの「スナップショット」を許す。種々の実施形態において、あるノード及びその全ての子供は、エクスポートプロセスによりエクスポートされる。一例として、フェデレート化ルートがエクスポートされるべく選択された場合には、ＶＣＲ全体がエクスポートされる。更に別の例として、エクスポートプロセスは、ＶＣＲを繰り返し横断し（例えば、深さ第１又はブレッド第１の横断）、訪問先の各ノード（例えば、コンテンツ、ハイアラーキー及びスキーマノード）に関連した情報をシリアライズすることができる。これら実施形態の態様は、どんな情報（例えば、ノード、ライフサイクル、ロール、ポリシー）がエクスポートされるか報告される「プレビュー」モードを有する。
【００９３】
種々の実施形態において、エクスポートプロセスは、各ノード（及び他の情報）をデシリアライズしそしてそれをＶＣＲネームスペース内の適当な場所に追加することにより、エクスポートプロセスのワークを逆に行うことができる。別の実施形態では、インポートプロセスが、ノードを、それらのオリジナルの位置ではなく、選択されたノードの下にインストールすることができる。エクスポートプロセスと同様に、これら実施形態の態様は、どんな情報（例えば、ノード、ライフサイクル、ロール、ポリシー）がＶＣＲにインポートされるか報告される「プレビュー」モードを有する。ノードプロパティに加えて、種々の実施形態は、コンテンツ及びスキーマノードに関連したバージョン経歴、ロール及び／又はポリシーのエクスポート及びインポートを許す。
【００９４】
図７は、本発明の種々の実施形態に基づきＶＣＲコンテンツサービスがディスエイブルされる間のコンテンツ生成を例示する図である。この図は、コンポーネントを論理的に別々のものとして示すが、これは単なる例示に過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントへと結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【００９５】
図７は、２つの一体化されたレポジトリー（７１４、７１６）及び一体化された第三者コンテンツマネージメントシステム７１８をもつＶＣＲ７００を示す。図示されていないが、サブシステム（７１４−７１８）の各々は、ＶＣＲへの一体化を許すＳＰＩを実施することができる。又、ユーザワークスペースマネージメント７０６、コンテンツバージョニング７０８、及びライフサイクルマネージメント７１０を含むＶＣＲにより提供されるコンテンツサービスも図示されている。フェデレーションに加えて、ＶＣＲは、そのコンテンツサービスの１つ以上を、それらを欠くサブシステムへ提供することができる。説明上、レポジトリー「Ｐｅｐｏ１」がバージョニングをネーティブにサポートしない場合には、ＶＣＲが、そのレポジトリーにおけるノードに対してこのサービスを自動的に提供できる。
【００９６】
ボックス７０２は、ＶＣＲにおいて情報を生成、変更及び削除するために使用できる１つ以上のコンテンツアドミニストレーションツールを表わす。これらのツールは、ＶＣＲのコンテンツサービスの利点を取り入れることができる。ボックス７０４は、コンテンツサービスの必要なく、レポジトリーにおいて動作できる１つ以上のツールを表わす。例えば、これらは、バルクコンテンツローダー、コンテンツサーチツール、及びコンテンツタグを含むことができる。コンテンツマネージャーＡＰＩコンポーネント７１２は、ＶＣＲとその一体化されたサブシステムとの間の対話をマネージするのに使用できる。
【００９７】
図７は、ＶＣＲのコンテンツサービスがイネーブルされないコンテンツノードの生成を示している。ボックス７２０は、ＶＣＲにおいて／Ｒｅｐｏ１／ＦｉｓｃａｌＰｌａｎに位置されてレポジトリーＲｅｐｏ１に記憶されたＦｉｓｃａｌＰｌａｎと命名されたコンテンツノードを表わしている。又、このノードは、デフォールトシステムプロパティ、例えば、「生成者(Created By)」、「生成日付(Created Date)」、ノード状態(Node Status)」、及び「ノード形式(Node Type)」を有する。ノード形式は、プロパティ「会計年度(Fiscal Year)」及び「カテゴリー(Category)」を有するＦｉｓｃａｌＰｌａｎＴｙｐｅと称されるスキーマである。このインスタンスにおいて、これらのプロパティは、２００３及び「財務(Finance)」に各々セットされている。又、ノード状態が「パブリッシュ済(Published)」であることにも注意されたい。
【００９８】
図８は、本発明の種々の実施形態に基づきＶＣＲコンテンツサービスがイネーブルされる間のコンテンツ生成を例示する図である。この例は、図７と同様であるが、コンテンツサービスがＶＣＲにおいてイネーブルされる。同じコンテンツノード／Ｒｅｐｏ１／ＦｉｓｃａｌＰｌａｎが生成されるが、コンテンツアドミニストレーションツール（これはコンテンツサービスを利用する）を使用して生成される。システムは、最初、上述したように、システムプロパティを含むＲｅｐｏ１においてコンテンツアイテムを生成する。しかしながら、スキーマ定義プロパティは、Ｒｅｐｏ１がバージョニング能力をもたないので、Ｒｅｐｏ１ではなく、ＶＣＲに、ノードの第１バージョンとして記憶される。これで、ノードは、バージョン番号に加えて、ノードがどのライフサイクル状態にあるか指示するためのライフサイクル状態も含む。この例では、ノードのライフサイクル状態は、「草案(Draft)」である。又、システムは、バージョン１を、それを生成したユーザに対してロックし、そしてそのユーザのワークスペースを通してノードへのアクセスを与えることができる。ユーザがノードをチェックインすると、そのライフサイクル（もしあれば）へ提出される。
【００９９】
図９は、本発明の種々の実施形態によりコンテンツサービスがイネーブルされる間にＶＣＲ内のノードを変更するところを例示する図である。この図は、前記図８から続くものである。この図において、ノード／Ｒｅｐｏ１／ＦｉｓｃａｌＰｌａｎがユーザによりチェックアウトされ、これは、ＶＣＲに新たなバージョン（バージョン２）を生成し、その新たなバージョンをロックし、そしてそれをユーザに指定するという作用を有する。ここで、ユーザは、ライフサイクル状態を「承認準備(ReadyForApproval)」に変更する。ノードがチェックインされると、そのスキーマ定義プロパティがバージョン２にセーブされる。更に、システムは、ロックを解除し、そしてノードをそのライフサイクルに提出する。説明上、これは、ユーザのワークスペースに所与のロール（例えば、パブリッシャーのロール）でノードを配するという作用を有してもよい。
【０１００】
図１０は、本発明の種々の実施形態によりコンテンツサービスがイネーブルされる間にＶＣＲにおいてノードをパブリッシュするところを例示する図である。この図は、前記図９から続くものである。この場合も、ノード／Ｒｅｐｏ１／ＦｉｓｃａｌＰｌａｎがユーザによりチェックアウトされ、これは、ＶＣＲに新たなバージョン（バージョン３）を生成し、その新たなバージョンをロックし、そしてそれをユーザに指定するという作用を有する。ここで、ユーザは、ライフサイクル状態を「パブリッシュ済(Published)」に変更する。ノードがチェックインされると、そのスキーマ定義プロパティがバージョン３にセーブされる。更に、システムは、ノードをアンロックし、そしてそのスキーマ定義プロパティ及びノード形式をバージョン３からＲｅｐｏ１へパブリッシュする。
【０１０１】
図１１は、本発明の種々の実施形態によりコンテンツサービスがイネーブルされる間にＶＣＲにおいてノードをリタイヤするところを例示する図である。図１０から続いて、ここでも、ノード／Ｒｅｐｏ１／ＦｉｓｃａｌＰｌａｎがユーザによりチェックアウトされ、これは、ノードをデパブリッシュし、ＶＣＲに新たなバージョン（バージョン４）を生成し、その新たなバージョンをロックし、そしてそれをユーザに指定するという作用を有する。ここで、ユーザは、ライフサイクル状態を「リタイヤ済(Retired)」に変更する。ノードが再びチェックインされると、そのスキーマ定義プロパティがＶＣＲにおいてバージョン４にセーブされ、そしてノードは、アンロックされる。更に、システムは、ノードのスキーマ定義プロパティと、Ｒｅｐｏ１で見つかったそのノード形式とを除去（即ち、デパブリッシュ）する。
【０１０２】
種々の実施形態は、コンピュータ分野の当業者に明らかなように、本開示の教示に基づいてプログラムされた従来の汎用又は特殊なデジタルコンピュータを使用して実施することができる。ソフトウェア分野の当業者に明らかなように、熟練したプログラマーであれば、本開示の教示に基づいて適切なソフトウェアコードを容易に準備することができよう。又、本発明は、当業者に容易に明らかなように、集積回路を準備するか、又は従来のコンポーネント回路の適切なネットワークを相互接続することにより、実施することもできる。
【０１０３】
種々の実施形態は、命令が記憶された記憶媒体（メディア）であるか、ここに示す特徴のいずれかを実行するようにコンピューティング装置をプログラムするのに使用できるコンピュータプログラム製品を包含する。プログラム媒体は、フロッピー（登録商標）ディスク、光学的ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気−光学ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気又は光学カード、ナノシステム（分子メモリ、ＩＣを含む）を含む任意の形式の物理的メディア、或いは命令及び／又はデータを記憶するための任意の形式のメディア又はデバイスを包含し得るが、これらに限定されない。種々の実施形態は、１つ以上のパブリック及び／又はプライベートネットワークを経て送信できるコンピュータプログラム製品を包含し、この送信は、ここに示す特徴のいずれかを実行するようにコンピューティング装置をプログラムするのに使用できる命令を含む。
【０１０４】
コンピュータ読み取り可能な媒体（メディア）のいずれか１つに記憶されるが、本発明は、汎用／特殊なコンピュータ又はマイクロプロセッサのハードウェアを制御すると共に、コンピュータ又はマイクロプロセッサが本発明の結果を利用して人間のユーザ又は他のメカニズムと対話できるようにするためのソフトウェアも包含する。このようなソフトウェアは、装置ドライバ、オペレーティングシステム、実行環境／コンテナ、及びアプリケーションを含むが、これらに限定されない。
【０１０５】
以上、本発明の好ましい実施形態を詳細に説明したが、これは、単なる例示に過ぎない。これは、本発明を余すところなく示すものでもないし、又、ここに開示した正確な形態に制限するものでもない。当業者であれば、多数の変更や修正が明らかであろう。これら実施形態は、本発明の原理及びその実際の応用を説明するために選ばれたものであり、従って、当業者であれば、本発明、種々の実施形態、並びに意図された特定の用途に適する種々の変更を理解することができよう。従って、本発明の範囲は、特許請求の範囲によって限定されるものとする。
【図面の簡単な説明】
【０１０６】
【図１】本発明の種々の実施形態における機能的システムレイヤーを例示する図である。
【図２】本発明の種々の実施形態におけるライフサイクルを例示する図である。
【図３】種々の実施形態においてライフサイクルを呼び出す外部筋書きを例示する図である。
【図４】本発明の種々の実施形態におけるユーザインターフェイスを例示する図である。
【図５】本発明の種々の実施形態においてＶＣＲにレポジトリーを接続するのに使用できるオブジェクト／インターフェイスを例示する図である。
【図６】本発明の種々の実施形態においてサービスモデルとして使用できるオブジェクト／インターフェイスを例示する図である。
【図７】本発明の種々の実施形態に基づきＶＣＲコンテンツサービスがディスエイブルされる間のコンテンツ生成を例示する図である。
【図８】本発明の種々の実施形態に基づきＶＣＲコンテンツサービスがイネーブルされる間のコンテンツ生成を例示する図である。
【図９】本発明の種々の実施形態に基づきコンテンツサービスがイネーブルされる間にＶＣＲのノードを変更するところを例示する図である。
【図１０】本発明の種々の実施形態に基づきコンテンツサービスがイネーブルされる間にＶＣＲのノードをパブリッシュするところを例示する図である。
【図１１】本発明の種々の実施形態に基づきコンテンツサービスがイネーブルされる間にＶＣＲのノードをリタイヤするところを例示する図である。
【図１】
2007520785.tif 000009
【図２】
2007520785.tif 000010
【図３】
2007520785.tif 000011
【図４】
2007520785.tif 000012
【図５】
2007520785.tif 000013
【図６】
2007520785.tif 000014
【図７】
2007520785.tif 000015
【図８】
2007520785.tif 000016
【図９】
2007520785.tif 000017
【図１０】
2007520785.tif 000018
【図１１】
2007520785.tif 000019