(57)【要約】【課題】本発明は、ＯＭＡ（Open Mobile Alliance）サービス情報の管理効率を向上するためのＸＤＭ（ＸＭＬ  Document Management）サービス情報管理システム及び方法に関する。【解決手段】本発明の装置は、サービス情報として参照される共有サービス情報のために新しく生成されたレファレンスハンドルとして利用される静的（static）値として制御部によって生成された値を利用して共有されたＵＲＩ（User Resource Identifier）を生成する制御部を含む。前記新しく生成された値は、変化されない値（対応エレメントが消滅するまで静的（static）に維持する）に設定することによって、共有サービス情報の変更によるシグナリングオーバーヘッド、互換性阻害及びリソースの無駄使いを防止する。【選択図】図５
2009505555.tif 000002
【特許請求の範囲】
【請求項１】
ＯＭＡ（Open Mobile Alliance）システムのＸＤＭ（ＸＭＬ  Document Management）クライアントにおいてＸＤＭサービス情報を管理する装置であって、
ｓｈａｒｅｄ  ＵＲＩ（User Resource Identifier）ｌｉｓｔの作成が要請される場合、自分が生成した値をレファレンスハンドルとするｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記要請に対応して作成する制御部を含むＸＤＭサービス情報管理装置。
【請求項２】
前記生成されたレファレンスハンドル値は、前記レファレンスハンドルを示すエレメントが消滅するまで固定されて変更されないことを特徴とする請求項１に記載のＸＤＭサービス情報管理装置。
【請求項３】
前記生成されたレファレンスハンドル値は、ランダム値であることを特徴とする請求項１に記載のＸＤＭサービス情報管理装置。
【請求項４】
前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、ＸＣＡＰ（ＸＭＬ  Configuration Access Protocol）プロトコルを使用して作成されることを特徴とする請求項１に記載のＸＤＭサービス情報管理装置。
【請求項５】
ＯＭＡ（Open Mobile Alliance）システムにおいてＸＤＭ（ＸＭＬ  Document Management）サービス情報を管理するシステムであって、
複数のＯＭＡサービスで共通に使用されるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを格納するｓｈａｒｅｄ  ＸＤＭＳと、
レファレンスハンドル値を含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを作成して前記ｓｈａｒｅｄ  ＸＤＭＳに伝送し、前記レファレンスハンドル値を使用して前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するＸＤＭＳサービス情報を作成してＸＤＭＳサービス情報を格納する前記ＸＤＭＳに伝送するＸＤＭクライアントと、
を含むＸＤＭサービス情報管理システム。
【請求項６】
ＰｏＣ（Push to talk over Cellular）グループサービス提供のために使用されるＰｏＣサービス情報を格納するＰｏＣ  ＸＤＭＳをさらに含み、
前記ＸＤＭクライアントは、前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの前記レファレンスハンドル値を使用して前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するＰｏＣグループサービス情報を作成して前記ＰｏＣ  ＸＤＭＳに伝送することを特徴とする請求項５に記載のＸＤＭサービス情報管理システム。
【請求項７】
ＲＬＳ（Resource List Server）サービス情報を格納するＲＬＳ  ＸＤＭＳをさらに含み、
前記ＸＤＭクライアントは、前記ｓｈａｒｅｄ  ＵＲＩリストのレファレンスハンドル値を使用して前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するＲＬＳサービス情報を作成して前記ＲＬＳ  ＸＤＭＳに伝送することを特徴とする請求項５に記載のＸＤＭサービス情報管理システム。
【請求項８】
前記ＸＤＭクライアントは、前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの変更が要請される場合、変更内容を前記ｓｈａｒｅｄ  ＸＤＭＳに伝送することを特徴とする請求項５に記載のＸＤＭサービス情報管理システム。
【請求項９】
前記ＸＤＭクライアントによって生成されたレファレンスハンドル値は、対応するｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ情報が存在する間は固定されて変更されないことを特徴とする請求項５に記載のＸＤＭサービス情報管理システム。
【請求項１０】
前記ＸＤＭクライアントによって生成されるレファレンスハンドル値は、ランダムに生成されることを特徴とする請求項５に記載のＸＤＭサービス情報管理システム。
【請求項１１】
ＯＭＡ（Open Mobile Alliance）システムのＸＤＭクライアントにおいてＸＤＭサービス情報を管理する方法であって、
ｓｈａｒｅｄ  ＸＤＭサーバーに格納されるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの作成を要請される過程と、
レファレンスハンドル値を生成する過程と、
前記生成したレファレンスハンドル値を含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記要請に応答して作成する過程と、
を含むＸＤＭサービス情報管理方法。
【請求項１２】
前記生成されたレファレンスハンドル値は、対応するエレメントが生成された後、前記エレメントが消滅するまで変更されないことを特徴とする請求項１０に記載のＸＤＭサービス情報管理方法。
【請求項１３】
前記生成されたレファレンスハンドル値は、ランダム値であることを特徴とする請求項１０に記載のＸＤＭサービス情報管理方法。
【請求項１４】
前記作成されたｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記ｓｈａｒｅｄ  ＸＤＭＳに伝送する過程をさらに含むことを特徴とする請求項１０に記載のＸＤＭサービス情報管理方法。
【請求項１５】
前記生成されたレファレンスハンドル値を使用して、前記サービス情報を参照するＸＤＭサービス情報、ＲＬＳサービス情報及びＰｏＣサービス情報の少なくとも１つを生成する過程をさらに含むことを特徴とする請求項１０に記載のＸＤＭサービス情報管理方法。
【請求項１６】
前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの変更が要請される場合、変更内容を前記ｓｈａｒｅｄ  ＸＤＭＳに伝送する過程をさらに含むことを特徴とする請求項１０に記載のＸＤＭサービス情報管理方法。
【請求項１７】
ＯＭＡ（Open Mobile Alliance）システムのＸＤＭクライアントにおいてＸＤＭサービス情報を管理する方法であって、
ｓｈａｒｅｄ  ＸＤＭサーバーに格納されるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの作成を要請される過程と、
リスト名称を含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを生成する過程と、
前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのリスト名称を固定する過程と、
前記固定されたリスト名称を含む前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記ｓｈａｒｅｄ  ＸＤＭサーバーに伝送する過程と、
を含むＸＤＭサービス情報管理方法。
【請求項１８】
ＯＭＡ（Open Mobile Alliance）システムのＸＤＭクライアントにおいてＸＤＭサービス情報を管理する方法において、
ｓｈａｒｅｄ  ＸＤＭサーバーに格納されるエントリーエレメントを含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの作成を要請される過程と、
固有識別子を有するエントリーエレメントを含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを生成する過程と、
前記エントリーエレメントの固有識別子を固定する過程と、
前記エントリーエレメントの固定された固有識別子を含む前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記ｓｈａｒｅｄ  ＸＤＭサーバーに伝送する過程と、
を含むＸＤＭサービス情報管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＭＡ（Open Mobile Alliance）サービスの提供のために使用されるＸＤＭサービス情報を管理するためのシステム及び方法に関する。
【背景技術】
【０００２】
移動通信技術は画期的に発展しており、通信網も拡大されている。また、移動通信サービスに対するユーザの要求も多様になっている。ＰｏＣ（Push to talk over Cellular）、インスタントメッセージング（Instant Messaging；ＩＭ）などのＯＭＡ（Open Mobile Alliance）サービスが、ユーザの要求を満たすために提案されている。
【０００３】
多様なＯＭＡサービスを提供するためにサービス情報が要求される。サービス情報は、すべてのＯＭＡサービスのうち共有される情報と特定のＯＭＡサービスだけで使用される情報とに分類されることができる。様々なＯＭＡサービスのうち共有されるサービス情報は、ＯＭＡ  ｓｈａｒｅｄ  ＸＤＭＳ（ＸＭＬ  Document Management System）（以下、“ｓｈａｒｅｄ  ＸＤＭＳ”という）に格納される。
【０００４】
図１は、ＯＭＡサービス情報の管理のためのグループ管理及びプレゼンスアーキテクチャーを示すブロックダイヤグラムである。図１を参照すれば、グループ管理及びプレゼンスアーキテクチャーは、ＸＤＭクライアント（ＸＤＭ  client）１００、アグリゲイションプロキシ(aggregation proxy)１１０、ｓｈａｒｅｄ  ＸＤＭＳ１２０、ＲＬＳ（Resource List Server）ＸＤＭＳ１３０、ＲＬＳ（Resource List Server）１３２、ＰｏＣ  ＸＤＭＳ１４０、ＰｏＣサーバー（ＰｏＣ  server）１４２、プレゼンスＸＤＭＳ１５０、プレゼンスサーバー（presence server）１５２、ＳＩＰ／ＩＰコア（ＳＩＰ／ＩＰ  core）１６０などを含むこともできる。
【０００５】
ＸＤＭクライアント１００は、グループ情報の利用のためのものである。ＸＤＭクライアント１００は、ユーザ端末に内蔵されるサービス要請者であり、ＨＴＴＰを利用するアグリゲイションプロキシ１１０を通じて、またはＳＩＰ（session Initiation Protocol）及びＩＰ（Internet Protocol）マルチメディアサポートコア網であるＳＩＰ／ＩＰコア（core）１６０を通じてＸＤＭサーバーに連結される。ＸＤＭクライアント１００は、グループ通話サービスのためにグループリスト情報を獲得、処理することができる。ＸＤＭクライアントは、ＯＭＡ規格に定義されている。
【０００６】
ＸＤＭＳ（ＸＤＭ  server）１２０、１３０、１４０、１５０は、グループリストサービスのために使用される。これらのサーバーもＯＭＡ規格に定義されている。ＸＤＭＳ１２０、１３０、１４０、１５０は、特定のＯＭＡサービスを提供するためにＲＬＳ  ＸＤＭＳ１３０、ＰｏＣ  ＸＤＭＳ１４０、プレゼンスＸＤＭＳ１５０、他のサービスイネイブラー（service enabler）にも共通的に使用されることができる共用（shared）ＸＤＭＳ１２０に区分されることができる。
【０００７】
ユーザは、ＸＤＭクライアント１００を利用してＸＤＭＳ１２０、１３０、１４０、１５０にグループ及びグループメンバーに関する情報を入力することができる。ここで、以下別途の言及がない限り、ユーザという用語は、ＸＤＭクライアントと同一の意味として見なされる。
【０００８】
アグリゲイションプロキシサーバー（aggregation proxy）１１０は、ユーザからグループリスト関連要請が受信されると、これを適切な規則に従って各ＸＤＭＳ１２０、１３０、１４０、１５０にルーティングする。
【０００９】
ＲＬＳ１３２は、グループメンバーのプレゼンス情報（presence information）を記述するためにＲＬＳ  ＸＤＭＳ１３０に保持されるプレゼンス情報グループを利用する。ＰｏＣサーバー１４２は、ＰｏＣセッションを運営するためにＰｏＳ  ＸＤＭＳ１４０で保持されるＰｏＣグループ情報を利用する。プレゼンスサーバー１５２は、ユーザの現在状態またはプレゼンス情報を管理する。
【００１０】
ＳＩＰ／ＩＰコア１６０は、ＯＭＡサービスを提供するためにＸＤＭＳ１２０、１３０、１４０、１５０、ＰｏＣサーバー６０、ＲＬＳ１３２に連結される。
【００１１】
前述したように、ＲＬＳ  ＸＭＤＳ１３０及びＰｏＣ  ＸＤＭＳ１４０は、各々ＲＬＳサービス情報及びＰｏＣサービス情報を格納する。ｓｈａｒｅｄ  ＸＤＭＳ１２０は、様々なＯＭＡサービスのために使用される共有サービス情報を格納する。一般的に、ＰｏＣサービス情報及びＲＬＳサービス情報は、ｓｈａｒｅｄ  ＸＤＭＳに格納された共有サービス情報を参照するように作成される。また、ｓｈａｒｅｄ  ＸＤＭＳ１２０は、ＸＤＭＳのみをために使用されるサービス情報を格納することができる。このサービス情報も共有サービス情報を参照するように作成される。
【００１２】
サービス情報の代表的な例には、ＵＲＩ（Uniform Resource Identifier）ｌｉｓｔが含まれる。ｓｈａｒｅｄ  ＸＤＭＳに格納され、複数のＯＭＡサービスのために使用されるＵＲＩ  ｌｉｓｔは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔと称される。
【００１３】
Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、［ＸＣＡＰ（ＸＭＬ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）＿Ｌｉｓｔ］に符合するｒｅｓｏｕｒｃｅ−ｌｉｓｔ形式を有する。
【００１４】
下記表１及び表２は、“ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）フォーマット”（Ｊ．Ｒｏｓｅｎｂｅｒｇ、Ｆｅｂｒｕａｒｙ  ７、２００５）に明示されたｒｅｓｏｕｒｃｅ  ｌｉｓｔのためのＸＭＬスキーマを示し、以下、このリストを［ＸＣＡＰリスト］と言う。
【００１５】
表１は、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ（パート１［ＸＣＡＰリスト］）のためのＸＭＬスキーマである。
【００１６】
【表１】
2009505555.tif 000003
【００１７】
表２は、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ（パート２［ＸＣＡＰリスト］）のＸＭＬスキーマである。
【００１８】
【表２】
2009505555.tif 000004
【００１９】
表１及び表２のスキーマによって作成されたｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、Ｓｈａｒｅｄ  ＸＤＭＳ１２０内にＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを所有しているユーザのユーザディレクトリ（user directory）中にｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔ形態で格納される。
【００２０】
表３は、ｆｒｉｅｎｄｓ．ｘｍｌという名前を有するｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの一例を示す。表３は、ｆｒｉｅｎｄｓ．ｘｍｌという名前を有する共有ＸＤＭＳのｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの例である。
【００２１】
【表３】
2009505555.tif 000005
【００２２】
Ｓｈａｒｅｄ  ＸＤＭＳ１２０に格納されたｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの位置は、［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］／［ＡＵＩＤ］／ｕｓｅｒｓ／［ＸＵＩ］／［ＸＭＬ  ｄｏｃｕｍｅｎｔ  ｎａｍｅ］形式のＸＣＡＰ  ＵＲＩで表現され、これに関する詳細な内容は、“ＸＤＭ（ＸＭＬ  Ｄｏｃｕｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ）仕様”（Ｖｅｒｓｉｏｎ  １．０、Ｏｐｅｎ  Ｍｏｂｉｌｅ  ＡｌｌｉａｎｃｅＴＭ、ＯＭＡ−ＴＳ−ＸＤＭ  ＣＯＲＥ−Ｖ１  ０（以下、［ＸＤＭ＿Ｃｏｒｅ］という）に記述されている。このような形式は、ＸＭＬ文書の位置を指定するという理由によりｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒと呼ばれる。ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）は、すべてのＸＤＭＳの最上位組職を意味し、ＡＵＩＤ（Ａｐｐｌｉｃａｔｉｏｎ  ＩＤ）は、該当サービスを示し、ＸＵＩ（ＸＣＡＰ  Ｕｓｅｒ  Ｉｄｅｎｔｉｔｙ）は、文書の所有者を示す。［Ｓｈａｒｅｄ＿ＸＤＭ］に定義されたｒｅｓｏｕｒｃｅ−ｌｉｓｔのためのＡＵＩＤは、‘ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ’である。したがって、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔのｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒは、［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／［ＸＵＩ］／［ＸＭＬ  ｄｏｃｕｍｅｎｔ  ｎａｍｅ］になる。
【００２３】
例えば、Ｓｈａｒｅｄ  ＸＤＭＳが属する［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］がｈｔｔｐ：／／ｘｃａｐ． ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅｓであり、表３のｆｒｉｅｎｄｓ．ｘｍｌというｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ  ｄｏｃｕｍｅｎｔの所有者は、ゼイ（Ｊａｙ）であり、ゼイのＸＵＩは、ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍと仮定する。この場合、ｆｒｉｅｎｄｓ．ｘｍｌ文書のｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒは、ｈｔｔｐ：／／ｘｃａｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅｓ／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍ／ｆｒｉｅｎｄｓ． ｘｍｌであり、このｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒは、この文書の位置を指定するＸＣＡＰ  ＵＲＩとして使用される。
【００２４】
Ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔに格納されている各エレメント（ｅｌｅｍｅｎｔ）の位置は、ｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒ及びｎｏｄｅ  ｓｅｌｅｃｔｏｒの組合せを利用して表現される。その位置表現形式は、［ｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒ］／〜〜／［ｎｏｄｅ  ｓｅｌｅｃｔｏｒ］である。ｎｏｄｅ  ｓｅｌｅｃｔｏｒは、所定の方法を利用して記述された条件に符合するエレメントの位置を表現する。
【００２５】
表４は、“ＸＭＬ（Extensible Markup Language）ＸＣＡＰ（Configuration Access Protocol）”（Ｊ．Ｒｏｓｅｎｂｅｒｇ、Ｊｕｎｅ  １１、２００５）（以下、［ＸＣＡＰ］という）に明示されたｎｏｄｅ  ｓｅｌｅｃｔｏｒを定義するために利用されるコードを示す。表４は、ｎｏｄｅ  ｓｅｌｅｃｔｏｒ［ＸＣＡＰ］の進歩したＢＮＦ定義である。
【００２６】
【表４】
2009505555.tif 000006
【００２７】
例えば、表３のｆｒｉｅｎｄｓ．ｘｍｌ文書で、ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ  ｒｏｏｔ  ｅｌｅｍｅｎｔのｃｈｉｌｄ  ｅｌｅｍｅｎｔである＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの中に、ｍｙ＿ｆｒｉｅｎｄｓという名前の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの位置を指定しようとすれば、ｈｔｔｐ：／／ｘｃａｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅｓ／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍ／ｆｒｉｅｎｄｓ．ｘｍｌ／〜〜／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｌｉｓｔ［＠ｎａｍｅ＝ｍｙ＿ｆｒｉｅｎｄｓ］であり、これは、‘ｎａｍｅ’属性の値が“ｍｙ  ｆｒｉｅｎｄｓ”である＜ｌｉｓｔ＞のＸＣＡＰ  ＵＲＩになる。
【００２８】
Ｓｈａｒｅｄ  ＸＤＭＳ１２０に格納されるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの所有者は、該当ｌｉｓｔを作成したユーザである。したがって、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの修正、削除、利用は、該当ｌｉｓｔを所有したユーザの固有権限である。例えば、ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍによって識別（identify）されるユーザが表３のｆｒｉｅｎｄｓ． ｘｍｌ文書を生成し、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔであるｆｒｉｅｎｄｓ．ｘｍｌの所有者になる。このように、文書の内容を修正し、文書を利用し、文書を削除することができる唯一のユーザは、ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍである。
【００２９】
一方、前述したように、ｓｈａｒｅｄ  ＸＤＭＳ１２０に格納されたｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、様々なＯＭＡサービスで参照されることができる。ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの生成及びＯＭＡサービスでの参照を用いた利用手続を添付の図面を参照して説明する。
【００３０】
図２は、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの生成及び利用手続の一例を示す。
【００３１】
図２に示されたように、ユーザ、すなわちＸＤＭクライアント１００は、自分のＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを表３に示すようにｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの形態で生成し、これをＸＣＡＰプロトコル（protocol）のＨＴＴＰ  ＰＵＴメッセージを利用してＳｈａｒｅｄ  ＸＤＭＳ１２０内の指定された位置またはユーザのユーザディレクトリに格納する。ＨＴＴＰ  ＰＵＴメッセージの要請ＵＲＩは、ｈｔｔｐ：／／ｘｃａｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅｓ／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍ／ｆｒｉｅｎｄｓ．ｘｍｌであるＸＣＡＰ  ＵＲＩのｄｏｃｕｍｅｎｔ  ｓｅｌｅｃｔｏｒである。ＨＴＴＰ  ＰＵＴメッセージは、アグリゲイションプロキシ１１０に先に送られる（２０１）。アグリゲイションプロキシ１１０は、前記ＸＣＡＰ  ＵＲＩ内に明示された“ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ”のａｐｐｌｉｃａｔｉｏｎ  ＩＤを利用してｓｈａｒｅｄ  ＸＤＭＳ１２０にメッセージをルーティングする（２０３）。次に、ＨＴＴＰ  ＰＵＴメッセージは、名前がｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍのＸＵＩであるユーザディレクトリの下にｆｒｉｅｎｄｓ．ｘｍｌ文書を生成することをｓｈａｒｅｄ  ＸＤＭＳ１２０に要請するのに使用される。また、ユーザは、ｆｒｉｅｎｄｓ．ｘｍｌを参照するｆｒｉｅｎｄｓ２．ｘｍｌ文書を生成してｆｒｉｅｎｄｓ２．ｘｍｌ文書をｓｈａｒｅｄ  ＸＤＭＳ１２０に提供し（２０９、２１１）、ｆｒｉｅｎｄｓ． ｘｍｌ文書を参照するｒｌｓ．ｘｍｌ文書を生成してｒｌｓ．ｘｍｌ文書をＲＬＳ  ＸＤＭＳ１３０に提供し（２１７、２１９）、ｆｒｉｅｎｄｓ．ｘｍｌを参照するｐｏｃ＿ｇｒｏｕｐ．ｘｍｌ文書を生成してｐｏｃ＿ｇｒｏｕｐ．ｘｍｌ文書をＰｏＣ  ＸＤＭＳ１４０に提供する（２２５、２２７）。これらのｆｒｉｅｎｄｓ２．ｘｍｌ、ｒｌｓ．ｘｍｌ及びｐｏｃ＿ｇｒｏｕｐ．ｘｍｌ文書の生成もアグリゲイションプロキシ１１０を通じて行う。ＨＴＴＰ２０１生成応答メッセージ２０５、２０７、２１３、２１５、２２１、２２３、２２９、２３１は、各文書の成功的な生成を通知するためにユーザに送信される。
【００３２】
Ｓｈａｒｅｄ  ＸＤＭＳ１２０に生成されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔ、＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞  ｅｌｅｍｅｎｔ、または＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔによって参照されることができる。＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔは、共有メンバーグループを示すｓｈａｒｅｄ  ＵＲＩリスト内の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照するのに使用される。ｅｘｔｅｒｎａｌ  ｅｌｅｍｅｎｔと同様に、＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔは、Ｓｈａｒｅｄ  Ｇｒｏｕｐを示す＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照するのに使用されるが、ＲＬＳ  Ｓｅｒｖｉｃｅ［ＲＬＳ＿ＸＤＭ］でのみ使用されることができる。Ｓｈａｒｅｄ  Ｍｅｍｂｅｒを示すｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔを参照するためには、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔを使用する。このような参照要素を通じてｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、Ｓｈａｒｅｄ  ＸＤＭＳ１２０自体を含むＯＭＡサービスで参照または利用される。また、これらの参照要素は、Ｓｈａｒｅｄ  ＸＤＭＳ１３０に存在するＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔへの一種のｐｏｉｎｔｅｒの役目をする。このようなｐｏｉｎｔｅｒによって参照されるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔと＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔに対するｒｅｓｏｌｕｔｉｏｎは、該当サービスを実際に使用する各々の主体（例えば、ＰｏＣ  ＳｅｒｖｅｒやＲＬＳ  Ｓｅｒｖｅｒ）によってなされるようになる。
【００３３】
表５乃至表７は、上記で説明した参照メカニズムの例を示す。表５は、名前がｆｒｉｅｎｄｓ２．ｘｍｌであるＳｈａｒｅｄ  ＸＤＭＳのｒｅｓｏｕｒｃｅ−ｌｉｓｔ文書の例を示す。
【００３４】
【表５】
2009505555.tif 000007
【００３５】
表６は、名前がｒｌｓ．ｘｍｌであるＲＬＳ  ＸＤＭＳのｒｌｓ文書の例を示す。
【００３６】
【表６】
2009505555.tif 000008
【００３７】
表７は、名前がｐｏｃ＿ｇｒｏｕｐ．ｘｍｌであるＰｏＣ  ＸＤＭＳのＰｏＣグループ文書の例を示す。
【００３８】
【表７】
2009505555.tif 000009
【００３９】
表５は、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔ及び＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔを利用してｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔと＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照するｓｈａｒｅｄ  ＸＤＭＳ１２０内のｆｒｉｅｎｄｓ２．ｘｍｌ文書を示す。さらに詳細に、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、各々＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔと＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔを利用して、‘ｏｔｈｅｒ＿ｆｒｉｅｎｄｓ’という名前を有する＜ｌｉｓｔ＞ｅｌｅｍｅｎｔ及びｆｒｉｅｎｄｓ．ｘｍｌという名前を有するｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の‘ｓｉｐ：ｂｒｉａｎ＠ｅｘａｍｐｌｅ．ｃｏｍ’のＵＲＩを有する＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔを参照する。
【００４０】
表６は、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔと＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔを利用してｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔと＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを各々参照するＲＬＳ  ＸＤＭＳ１３０のｒｌｓ．ｘｍｌ文書を示す。さらに詳細には、ｓｉｐ：ｒｌｓ−ｓｅｒｖｉｃｅ１＠ｅｘａｍｐｌｅ．ｃｏｍというｓｅｒｖｉｃｅ  ＵＲＩの＜ｓｅｒｖｉｃｅ＞ｅｌｅｍｅｎｔは＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔを使用して、Ｓｈａｒｅｄ  ＸＤＭＳ１２０内のｆｒｉｅｎｄｓ．ｘｍｌ  ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔに格納されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｏｔｈｅｒ＿ｆｒｉｅｎｄｓというｌｉｓｔ  ｎａｍｅを有する＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照する。同様に、ｓｉｐ：ｍａｒｋｅｔｉｎｇ＠ｅｘａｍｐｌｅ．ｃｏｍというｓｅｒｖｉｃｅ  ＵＲＩを有する＜ｓｅｒｖｉｃｅ＞ｅｌｅｍｅｎｔは、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔを使用してｆｒｉｅｎｄｓ．ｘｍｌ  ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔに格納されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｏｔｈｅｒ＿ｆｒｉｅｎｄｓというｌｉｓｔ  ｎａｍｅを有する＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照し、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔを利用してｆｒｉｅｎｄｓ．ｘｍｌ  ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔに格納されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｓｉｐ：ｂｒｉａｎ＠ｅｘａｍｐｌｅ．ｃｏｍというＵＲＩを有する＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔを参照する。
【００４１】
表７は、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔ及び＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔを使用してｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内の＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔ及び＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを各々参照するＰｏＣ  ＸＤＭＳ１４０のｐｏｃ＿ｇｒｏｕｐ．ｘｍｌ  ｄｏｃｕｍｅｎｔを示す。特に、ＰｏＣ  Ｇｒｏｕｐ  Ｍｅｍｂｅｒ  Ｌｉｓｔｉｎｇは、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔを利用して、ｓｈａｒｅｄ  ＸＤＭＳ１２０のｆｒｉｅｎｄｓ．ｘｍｌ  ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔに格納されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｏｔｈｅｒ＿ｆｒｉｅｎｄｓというｌｉｓｔ  ｎａｍｅを有する＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照する。
【００４２】
以下、上記例を参照してレファレンスハンドル（reference handle）について説明する。
【００４３】
＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔと＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔに対するＸＭＬスキーマ定義は、表１に示されている。＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔは、参照される＜ｌｉｓｔ＞ｅｌｅｍｅｎｔへの全体経路である＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのａｂｓｏｌｕｔｅ  ＸＣＡＰ  ＵＲＩを指定することによって、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照する。例えば、表５で＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔによって参照されるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの＜ｌｉｓｔ＞ｅｌｅｍｅｎｔは、ｈｔｔｐ：／／ｘｃａｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅｓ／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍ／ｆｒｉｅｎｄｓ．ｘｍｌ／〜〜／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｌｉｓｔ［＠ｎａｍｅ＝ｏｔｈｅｒ＿ｆｒｉｅｎｄｓ］というａｂｓｏｌｕｔｅ  ＸＣＡＰ  ＵＲＩに位置指定される。この例で、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの他の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのうち参照される＜ｌｉｓｔ＞ｅｌｅｍｅｎｔは、“ｎａｍｅ”属性値または‘ｏｔｈｅｒ＿ｆｒｉｅｎｄｓ’という＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの名前によって識別される。参照される要素の正確な位置を識別するこの部分をレファレンスハンドルと言う。従って、この場合、‘ｏｔｈｅｒ＿ｆｒｉｅｎｄｓ’という＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔのＸＣＡＰ  ＵＲＩのｎａｍｅ属性値が、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔのレファレンスハンドルになる。表６のＲＬＳサービス文書の＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔの場合も同様である。
【００４４】
＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔは、参照される＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのｒｅｌａｔｉｖｅ  ＸＣＡＰ  ＵＲＩを指定することによって、＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔを参照する。ｒｅｌａｔｉｖｅ  ＸＣＡＰ  ＵＲＩは、全体経路を示すａｂｓｏｌｕｔｅ  ＸＣＡＰ  ＵＲＩから＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔへの［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］を除いた経路である。このため、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔを利用した参照は、参照する＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔの［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］が参照される＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔと同一の場合にだけ行われることができる。
【００４５】
例えば、表６のｒｌｓ．ｘｍｌ  ＲＬＳ  Ｓｅｒｖｉｃｅ  ｄｏｃｕｍｅｎｔを格納するＲＬＳ  ＸＤＭＳ１３０は、表３のｆｒｉｅｎｄｓ．ｘｍｌ  ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ文書を格納するＳｈａｒｅｄ  ＸＤＭＳ１２０と同一のｈｔｔｐ：／／ｘｃａｐ．ｅｘａｍｐｌｅ． ｃｏｍ／ｓｅｒｖｉｃｅｓという［ＸＣＡＰ  Ｒｏｏｔ  ＵＲＬ］を有する。この例で、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔは、ｓｉｐ：ｂｒｉａｎ＠ｅｘａｍｐｌｅ．ｃｏｍというＵＲＩを有する参照する＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのｒｅｌａｔｉｖｅ  ＸＣＡＰ  ＵＲＩを含み、前記ＵＲＩは、ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｕｓｅｒｓ／ｓｉｐ：ｊａｙ＠ｅｘａｍｐｌｅ．ｃｏｍ／ｆｒｉｅｎｄｓ．ｘｍｌ／〜〜／ｒｅｓｏｕｒｃｅ−ｌｉｓｔｓ／ｌｉｓｔ［＠ｎａｍｅ＝ｍｙ＿ｆｒｉｅｎｄｓ］／ｅｎｔｒｙ［＠ｕｒｉ＝ｓｉｐ：ｂｒｉａｎ＠ｅｘａｍｐｌｅ．ｃｏｍ］である。この例で、‘ｓｉｐ：ｂｒｉａｎ＠ｅｘａｍｐｌｅ．ｃｏｍ’である＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔのｒｅｌａｔｉｖｅ  ＸＣＡＰ  ＵＲＩの‘ｕｒｉ’属性の値は、参照される＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの正確な位置を識別するので、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔのレファレンスハンドルになる。
【００４６】
前述したように、Ｓｈａｒｅｄ  ＸＤＭＳ１２０に格納されたＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔは、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔ、＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔ、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔなどを利用した位置指定を通じて参照される方法により、ＯＭＡサービスによって利用される。この時、位置指定のためのレファレンスハンドルは、＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔと＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔの場合には、参照される＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのｌｉｓｔ  ｎａｍｅであり、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔの場合には、参照される＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのＵＲＩになる。
【００４７】
リスト名称とＵＲＩ値のこれらのレファレンスハンドルは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔとＯＭＡサービス間の参照関係を形成するキーであるが、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを所有するユーザの意志によって変わることがある。これは、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを所有しているユーザは、所望する毎にＨＴＴＰ  ＰＵＴを利用したｒｅｐｌａｃｅ動作を利用して該当Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの内容を修正することができるからである。
【００４８】
しかし、ユーザが＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの‘ｎａｍｅ’属性の値や＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの‘ｕｒｉ’属性の値を修正する場合には、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔと＜ｌｉｓｔ＞ｅｌｅｍｅｎｔまたは＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔに対して行われた他のＯＭＡサービス間のすべての参照関係も、ｎａｍｅ属性またはｕｒｉ属性の値がレファレンスハンドルとして機能するように、対応してアップデートされなければならない。さもなければ、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔとこれを利用する他のＯＭＡサービスのオブジェクトとの間の参照関係が破れ、オブジェクトがＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを利用することができなくなる。
【００４９】
すなわち、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔに対するＳｈａｒｅｄ  ＸＤＭＳ１２０、ＲＬＳ  ＸＤＭＳ１３０、及びＰｏＣ  ＸＤＭＳ１４０との参照関係が維持されるためには、レファレンスハンドルである‘ｎａｍｅ’属性と‘ｕｒｉ’属性の値が変わる場合、すべての参照オブジェクトであるＳｈａｒｅｄ  ＸＤＭＳ１２０、ＲＬＳ  ＸＤＭＳ１３０、及びＰｏＣ  ＸＤＭＳ１４０に対して各々対応する＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔ、＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔ、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔのレファレンスハンドル値が一緒にアップデートされなければならない。したがって、参照されるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのレファレンスハンドルに対する修正は、これを参照するＳｈａｒｅｄ  ＸＤＭＳ１２０、ＲＬＳ  ＸＤＭＳ１３０、及びＰｏＣ  ＸＤＭＳ１４０のアップデートのための別個のシグナリングを必要とする。
【００５０】
図３は、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのレファレンスハンドルが変わる場合のｓｈａｒｅｄ  ＸＤＭＳ、ＲＬＳ  ＸＤＭＳ及びＰｏＣ  ＸＤＭＳのレファレンスアップデート（reference update）のためのシグナリングを示す。レファレンスアップデートも、対応ＸＤＭＳに対するルーティングアップデート要請のためにアグリゲイションプロキシ１１０を通じて行われる。ユーザは、ｓｈａｒｅｄ  ＸＤＭＳ１２０に格納されたｆｒｉｅｎｄｓ．ｘｍｌを変更した後（３０１、３０３）、ｆｒｉｅｎｄｓ２．ｘｍｌを変更し（３０９、３１１）、ｒｌｓ．ｘｍｌを変更し（３１７、３１９）、ｐｏｃ＿ｇｒｏｕｐ．ｘｍｌを変更する（３２５、３２７）。ＨＴＴＰ  ２００  ＯＫ  ３０５、３０７、３１３、３１５、３２１、３２３、３２９、３３１は、応答メッセージである。
【００５１】
しかし、従来技術は、前述したように可変レファレンスハンドルを使用するので、多くの問題点を有する。
【００５２】
例えば、Ｓｈａｒｅｄ  ＸＤＭＳにあるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔが参照される利用度に比例して、これを参照するすべてのオブジェクトのレファレンスをアップデートするために追加的なシグナリングを必要とし、これは、ＸＤＭＳの関係を複雑にし、追加的なシグナリングのためのシステムリソースを浪費する結果をもたらす。
【００５３】
また、レファレンスハンドルの変化に応じた参照するオブジェクトに対するレファレンスアップデートシグナリングの一部が、ある理由で失敗した場合、これを失敗した参照オブジェクトは、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照することができなくなる。このため、互換性問題が生じる。
【００５４】
また、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの変化に応じた適切なレファレンスアップデートのためには、該当Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照しているオブジェクトに関する情報を維持していなければならない。その結果、システムリソースを浪費してしまう。。
【発明の開示】
【発明が解決しようとする課題】
【００５５】
したがって、本発明の目的は、ＯＭＡサービスシステムにおいてレファレンスハンドルの変化に起因して発生するシグナリングオーバーヘッド、互換性阻害、及び、リソースの無駄使いを防止することができるＸＤＭサービス情報管理システム及び方法を提供することにある。
【課題を解決するための手段】
【００５６】
本発明によるＯＭＡ（Open Mobile Alliance）システムのＸＤＭクライアントにおいてＸＤＭサービス情報を管理するための装置は、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの作成が要請される場合、自分が生成した値をレファレンスハンドルとするｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記要請に対応して作成する制御部を含む。
【００５７】
本発明によるＯＭＡシステムにおけるＸＤＭサービス情報管理システムは、複数のＯＭＡサービスのうち共有されるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを格納するｓｈａｒｅｄ  ＸＤＭＳと、自分が生成した値をレファレンスハンドルとするｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを作成して前記ｓｈａｒｅｄ  ＸＤＭＳに伝送し、前記レファレンスハンドルを使用して前記ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するＸＤＭＳサービス情報を作成して前記ｓｈａｒｅｄ  ＸＤＭＳに伝送するＸＤＭクライアントと、を含む。
【００５８】
本発明によるＯＭＡ（Open Mobile Alliance）システムのＸＤＭクライアントにおけるＸＤＭサービス情報管理方法は、ｓｈａｒｅｄ  ＸＤＭサーバーに格納されるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの作成を要請される過程と、レファレンスハンドルとして使用するための値を生成する過程と、前記生成した値をレファレンスハンドルとするｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを前記要請に対応して作成する過程と、を含む。
【発明を実施するための最良の形態】
【００５９】
前述したように、本発明は、変更されないレファレンスハンドルを使用することを特徴とする。すなわち、本発明によって、Ｓｈａｒｅｄ  ＸＤＭＳに格納されるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの利用のためにＯＭＡサービスが使うレファレンスハンドルの値は、参照されるエレメントの生成から消滅まで変わらない静的（static）値を使用する。
【００６０】
静的（static）レファレンスハンドルを使用する場合、参照されるオブジェクト、すなわち＜ｌｉｓｔ＞ｅｌｅｍｅｎｔと＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの変化とこれを参照するオブジェクト、すなわち＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔ、＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔ、＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔの関係は独立的になる。したがって、参照されるオブジェクトの内部変化は、これを参照するオブジェクトとの参照関係に影響を与えない。
【００６１】
本発明で使用されるレファレンスハンドルは、さまざまな方法で生成されることができる。以下記述する本発明では、レファレンスハンドル生成方法の代表的な例として、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを管理するシステムがユーザの要求に応じて自動で生成するランダム値（random value）を使用する。
【００６２】
本発明は、図１に示されたようなＯＭＡプレゼンスアーキテクチャー上で具現されることができる。
【００６３】
表８及び表９は、本発明による表１及び表２のｒｅｓｏｕｒｃｅ−ｌｉｓｔの改善されたＸＭＬスキーマ定義を示す。具体的に、表８及び表９は、ランダム値をレファレンスハンドルとして使用するためのＸＭＬスキーマ定義を示す。表８は、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ（パート１）の改善されたＸＭＬスキーマである。
【００６４】
【表８】
2009505555.tif 000010
【００６５】
表９は、ｒｅｓｏｕｒｃｅ−ｌｉｓｔ（パート１）の改善されたＸＭＬスキーマである。
【００６６】
【表９】
2009505555.tif 000011
【００６７】
表８及び表９に示されたように、本発明による改善されたＸＭＬスキーマは、表１の、従来のスキーマで定義された＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのｌｉｓｔ  ｎａｍｅである‘ｎａｍｅ’属性を＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのｃｈｉｌｄ  ｅｌｅｍｅｎｔとして定義し、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔには、新たに‘ｉｄ’というｓｔｒｉｎｇ  ｔｙｐｅの属性を追加的に定義する。この‘ｉｄ’属性は、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの生成時にシステムが自動で該当＜ｌｉｓｔ＞ｅｌｅｍｅｎｔに割り当てるランダム値を含む。この‘ｉｄ’属性は、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの同じｐａｒｅｎｔ  ｅｌｅｍｅｎｔに属する他の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのなかで固有の値でなければならないし、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの消滅時まで変わらない値でなければならない。すなわち、この‘ｉｄ’属性は、該当＜ｌｉｓｔ＞ｅｌｅｍｅｎｔをｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔ内で固有（unique）に識別されるようにすることができる。本発明は、この‘ｉｄ’属性を該当＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの参照時に使用される＜ｅｘｔｅｒｎａｌ＞ｅｌｅｍｅｎｔと＜ｒｅｓｏｕｒｃｅ−ｌｉｓｔ＞ｅｌｅｍｅｎｔのレファレンスハンドルとして使用する。
【００６８】
前述したように、レファレンスハンドルを使用する場合、後にユーザがＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｌｉｓｔ  ｎａｍｅを変更しても、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの＜ｎａｍｅ＞ｃｈｉｌｄ  ｅｌｅｍｅｎｔだけが変わり、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのレファレンスハンドルとして使用される‘ｉｄ’属性は、そのまま維持される。したがって、“ｉｄ”属性をレファレンスハンドルとして利用して＜ｌｉｓｔ＞ｅｌｅｍｅｎｔを参照するオブジェクトも、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのｌｉｓｔ  ｎａｍｅ変更による追加的なレファレンスアップデートを必要としない。
【００６９】
また、表１の、従来のＸＭＬスキーマで定義された＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのＵＲＩ値を示す‘ｕｒｉ’属性は、表８及び表９の改善されたＸＭＬスキーマでは＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのｃｈｉｌｄ  ｅｌｅｍｅｎｔとして定義され、＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔには、新たに‘ｉｄ’というｓｔｒｉｎｇ  ｔｙｐｅの属性が追加的に定義される。この‘ｉｄ’属性は、前述した＜ｌｉｓｔ＞ｅｌｅｍｅｎｔのように、＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの生成時にシステムで自動で該当＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔに割り当てられるランダム値である。この‘ｉｄ’属性は、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの同じｐａｒｅｎｔ  ｅｌｅｍｅｎｔの下の他の＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの間で固有の値でなければならないし、該当＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの消滅時まで変わらない値でなければならない。上記で示したように、この‘ｉｄ’属性は、該当＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔをｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔ内で固有（unique）に識別されるようにすることができ、該当＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの参照時に使用される＜ｅｎｔｒｙ−ｒｅｆ＞ｅｌｅｍｅｎｔでレファレンスハンドルとして使用される。したがって、後にユーザが該当Ｓｈａｒｅｄ  ＭｅｍｂｅｒのＵＲＩを変更しても、＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの＜ｕｒｉ＞ｃｈｉｌｄ  ｅｌｅｍｅｎｔだけが変わることができ、＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔのレファレンスハンドルである‘ｉｄ’属性はそのまま維持されなければならない。したがって、“ｉｄ”属性をレファレンスハンドルとして使用して＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔを参照するオブジェクトは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのＭｅｍｂｅｒのＵＲＩ変更による追加的なレファレンスアップデートを必要としない。
【００７０】
表１０は、表８及び表９の、改善されたＸＭＬスキーマによって作成された、従来の表２のｆｒｉｅｎｄｓ．ｘｍｌ  ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔを改善した例である。表１０は、ｆｒｉｅｎｄｓ．ｘｍｌという名前のＳｈａｒｅｄ  ＸＤＭＳの改善されたｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの例を示す。
【００７１】
【表１０】
2009505555.tif 000012
【００７２】
表１０は、ｆｒｉｅｎｄｓ． ｘｍｌ文書のリスト及びエントリーがｓｐ９３、ｅ２ｌｗ、ｖｎ１２ｗ、ｗ２ｆｂ７という、ランダムに生成された“ｉｄ”属性値をレファレンスハンドルとして使用する本発明による例を示す。したがって、表１０のｆｒｉｅｎｄｓ．ｘｍｌは、ｎａｍｅまたはｕｒｉ属性値をレファレンスハンドルとして使用しない。これは、ｆｒｉｅｎｄｓ．ｘｍｌを所有するユーザの意図によって変更されるからである。このように、本発明によって導入されたｆｒｉｅｎｄｓ．ｘｍｌのレファレンスハンドルは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔサービス情報がユーザによって変更される時にも変更されない。
【００７３】
前述したように、本発明では、レファレンスハンドルの変更が発生しないので、レファレンスハンドルの変化による、該当ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するオブジェクトの追加的なレファレンスアップデートを必要としない。したがって、本発明では、レファレンスアップデートによるシグナリングオーバーヘッドが発生しない。また、本発明は、レファレンスアップデートを必要としないので、システムを単純にして性能を向上させることができる。また、本発明では、従来技術でレファレンスアップデートの失敗に起因して発生した互換性阻害が発生しない。また、本発明では、後に発生しうるレファレンスアップデートのために該当Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの参照関係情報を維持していなければならない負担がなくなり、したがってこのために使用されたリソースの節約が可能である。
【００７４】
表１１乃至表１３は、本発明によるｓｈａｒｅｄ  ＸＤＭＳの改善されたｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔ、ＲＬＳ  Ｓｅｒｖｉｃｅの改善したｒｌｓ−ｓｅｒｖｉｃｅｓ  ｄｏｃｕｍｅｎｔ、ＰｏＣ  Ｓｅｒｖｉｃｅの改善されたＰｏＣ  Ｇｒｏｕｐ  ｄｏｃｕｍｅｎｔの例を各々示している。表１１乃至表１３で、これらの文書のすべての参照関係は、表９の改善されたＸＭＬスキーマによって作成された表１０のｆｒｉｅｎｄｓ．ｘｍｌの改善されたＳｈａｒｅｄ  ＵＲＩリストを参照することによって改善される。
【００７５】
表１１は、名前がｆｒｉｅｎｄｓ２． ｘｍｌであるｓｈａｒｅｄ  ＸＤＭＳの改善されたｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔの例を示す。
【００７６】
【表１１】
2009505555.tif 000013
【００７７】
表１２は、名前がｒｌｓ． ｘｍｌであるＲＬＳ  ＸＤＭＳの改善されたｒｌｓ  ｄｏｃｕｍｅｎｔの例を示す。
【００７８】
【表１２】
2009505555.tif 000014
【００７９】
表１３は、名前がｐｏｃ  ｇｒｏｕｐ．ｘｍｌであるＰｏＣ  ＸＤＭＳの改善されたＰｏＣグループ文書の例を示す。
【００８０】
【表１３】
2009505555.tif 000015
【００８１】
表１１乃至表１３の例は、表５乃至表７に示す例において‘ｎａｍｅ’属性、‘ｕｒｉ’属性、及びレファレンスハンドルを改善したものである。
【００８２】
代案として、本発明で使用されるレファレンスの概念は、＜ｌｉｓｔ＞ｅｌｅｍｅｎｔの‘ｎａｍｅ’属性と＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの‘ｕｒｉ’属性の既存のレファレンスハンドルを向上させることによって得られることができる。ただし、上記で言及したように、‘ｎａｍｅ’属性または‘ｕｒｉ’属性は、他の＜ｌｉｓｔ＞ｅｌｅｍｅｎｔまたは＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの属性のなかで固有であるべきであり、これにより、対応する＜ｌｉｓｔ＞または＜ｅｎｔｒｙ＞ｅｌｅｍｅｎｔの固有識別が可能となる。上記で示したように、これらの値が変更される従来技術の問題点及び‘ｎａｍｅ’属性の存在は、表１のスキーマ定義によって選択的である。従って、‘ｎａｍｅ’属性または‘ｕｒｉ’属性の値が固定され、且つ、‘ｎａｍｅ’属性の存在が必須なら、すなわち＜ｌｉｓｔ＞ｅｌｅｍｅｎｔが常に‘ｎａｍｅ’属性を含むのであれば、本発明によって提供される静的レファレンスメカニズムは、既存のレファレンスハンドルを修正することによって得られることができる。
【００８３】
本発明によるＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ生成及び参照のためのシグナリングフローは、図２に示されたシグナリングフローと同一である。すなわち作成されたｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔがｓｈａｒｅｄ  ＸＭＬＳに格納され、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するＸＤＭサービス情報（ｒｅｓｏｕｒｃｅ−ｌｉｓｔ  ｄｏｃｕｍｅｎｔ）、ＲＬＳサービス情報（ＲＬＳ  ｓｅｒｖｉｃｅ  ｄｏｃｕｍｅｎｔ）及びＰｏＣサービス情報（ＰｏＣ  ｓｅｒｖｉｃｅ  ｄｏｃｕｍｅｎｔ）が各々ｓｈａｒｅｄ  ＸＤＭＳ、ＲＬＳ  ＸＤＭＳ及びＰｏＣ  ＸＤＭＳに格納される。ｓｈａｒｅｄ  ＸＤＭＳ、ＲＬＳ  ＸＤＭＳ及びＰｏＣ  ＸＤＭＳに格納される各々のサービス情報は、本発明による改善されたＸＭＬスキーマによって作成される。すなわち、ｓｈａｒｅｄ  ＸＤＭＳ、ＲＬＳ  ＸＤＭＳ及びＰｏＣ  ＸＤＭＳに格納される各々のサービス情報は、ランダムに生成されたレファレンスハンドルを使用してｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照する。
【００８４】
一方、本発明では、Ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内に変化がある時にも、レファレンスハンドルがそのまま維持されるので、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ内に変更がある時にも、該当ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するオブジェクトのレファレンスアップデートを必要としない。
【００８５】
図４は、本発明によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの変更時のシグナリング過程を示している。
【００８６】
図４に示されたように、本発明では、ユーザ、すなわちＸＤＭクライアント１００によってｓｈａｒｅｄ  ＸＤＭＳ１２０のｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔが変更（４０１、４０３）される場合にも、他のＸＤＭＳ１２０、１３０、１４０、１５０に対するレファレンスアップデートは行われない。図４のＨＴＴＰ  ２００  ＯＫ（４０５または４０７）は、応答メッセージである。
【００８７】
一方、前述したレファレンスハンドル生成過程は、一般的にＸＤＭクライアントで行われる。これは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔがＸＤＭクライアントで作成され、ｓｈａｒｅｄ  ＸＤＭＳに伝送されるからである。ＸＤＭ端末での、本発明によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ作成過程を添付の図面を参照して説明すれば、次の通りである。
図５は、ＸＤＭクライアントでの、本発明によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ作成過程を示すフローチャートである。
【００８８】
図５に示されたように、ＸＤＭクライアントは、ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ作成が要請されれば（５００）、該当ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔに含まれるレファレンスハンドルを生成する（５０２）。一般的に、ランダム値がレファレンスハンドルとして使用される。ＸＤＭクライアントは、生成されたレファレンスハンドルを含むｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを作成する（５０４）。ＸＤＭクライアントは、作成したｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔをｓｈａｒｅｄ  ＸＤＭＳに伝送する（５０６）。ＸＤＭクライアントは、作成したｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔを参照するサービス情報を作成し、各々該当するサービスのＸＤＭＳに伝送する（５０８）。
【００８９】
本発明では、ＯＭＡサービスによる参照を利用したＳｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの利用時に、レファレンスハンドルの値は、ユーザに無意味であり、ユーザに知らされない。したがって、ユーザが参照関係を要求する時、実質的な参照のための動作は、システム、すなわちＸＤＭクライアント、ｓｈａｒｅｄ  ＸＤＭＳ、ＰｏＣ  ＸＤＭＳ、ＲＬＳ  ＸＤＭＳなどにより自動的に形成され維持される。
【産業上の利用可能性】
【００９０】
本発明は、共有サービス情報が削除されるまで変わらない値を生成して該当共有サービス情報のレファレンスハンドルとして使用することによって、ＯＭＡサービスが安定的に共有サービス情報を参照することができるようにする。このため、本発明は、シグナリングオーバーヘッド、互換性阻害、リソースの無駄使いを防止し、システムの性能を向上させることができる。
【図面の簡単な説明】
【００９１】
【図１】ＯＭＡサービス情報管理のためのプレゼンスアーキテクチャーを示す図。
【図２】ｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの生成及び利用手続の一例を示す図。
【図３】従来技術によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔのレファレンスハンドル変更時のシグナリング過程を示す図。
【図４】本発明によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔの変更時のシグナリング過程を示す図。
【図５】ＸＤＭクライアントにおける、本発明によるｓｈａｒｅｄ  ＵＲＩ  ｌｉｓｔ作成過程を示すフローチャート。
【図１】
2009505555.tif 000016
【図２】
2009505555.tif 000017
【図３】
2009505555.tif 000018
【図４】
2009505555.tif 000019
【図５】
2009505555.tif 000020
【国際調査報告】
2009505555.tif 000021