JP5253396B2

JP5253396B2 - Ｘｍｌ文書の位置記述を用いてｘｍｌ文書管理機能を実現するためのｘｄｍシステム及び方法

Info

Publication number: JP5253396B2
Application number: JP2009524557A
Authority: JP
Inventors: ジェ−クウォン・オウ; ウク・キム
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2006-08-16
Filing date: 2007-08-16
Publication date: 2013-07-31
Anticipated expiration: 2027-08-16
Also published as: KR20080015566A; JP2010500685A; CN102012943A; KR101281387B1; CN102012943B; CN101506800B; EP2052332B1; CN101506800A; US20080046482A1; EP2052332A1; WO2008020717A1; US8230003B2; EP2052332A4

Description

本発明は、オープンモバイルアライアンス（Open Mobile Alliance：以下、"ＯＭＡ"と称する）拡張可能マークアップ言語文書管理（eXtensible Markup Language (XML) Document Management：以下、"ＸＤＭ"と称する）サービスイネーブラ（service enabler）に関し、特に、本発明は、ＸＭＬ文書の位置記述を用いるＸＤＭシステム及び方法に関する。

一般的なＸＤＭｖ１．０サービスイネーブラの拡張可能マークアップ言語文書管理（eXtensible Markup Language (XML) Document Management：以下、"ＸＤＭ"と称する）において、拡張可能マークアップ言語（eXtensible markup language：以下、"ＸＭＬ"と称する）文書をＸＤＭサーバ（XDM Server：以下、"ＸＤＭＳ"と称する）に生成するＸＤＭオペレーション（operation）は、生成されるＸＭＬ文書をＸＭＬコンフィギュレーションアクセスプロトコル（XML Configuration Access Protocol：以下、"ＸＣＡＰ"と称する）ＰＵＴ要請メッセージに含ませてＸＤＭＳに送信することにより実現される。
ユニフォームリソース識別子（Uniform Resource Identifier：以下、"ＵＲＩ"と称する）リストのＸＭＬ文書を共有（Shared）ＸＤＭＳに生成するためのＸＤＭオペレーションの間のメッセージのフローについて、図１と下記の＜表１＞及び＜表２＞とを参照して説明する。
まず、ＸＤＭクライアント（XDM Client：以下、"ＸＤＭＣ"と称する）は、図１のステップ１０で生成されるＸＭＬ文書を含むＸＣＡＰＰＵＴ要請メッセージをＸＤＭＳに送信する。この際、ＸＣＡＰＰＵＴ要請メッセージが下記の＜表１＞に示すように構成される場合に、ＸＤＭＣは、ＸＣＡＰＰＵＴ要請メッセージを通じて"sip:jay@example.com"のユーザーディレクトリ（user directory）にコンテンツボディーに含まれているＵＲＩリストを含む"friends.xml document"の生成を要請することができる。

上述した＜表１＞に示すＸＣＡＰＰＵＴ要請メッセージを受信すると、ＸＤＭＳは、対応するＸＭＬ文書を生成し、生成に成功したことを知らせるために、図１のＸＣＡＰ２０１生成メッセージ１２をＸＤＭＣに送信する。この際、図１のＸＣＡＰ２０１生成メッセージ１２は、下記の＜表２＞に示すように構成される。

上述したように、ＸＭＬ文書は、ＸＤＭｖ１．０サービスイネーブラのＸＤＭを用いてＸＤＭＳに生成されることができる。さらに、ＸＤＭｖ２．０サービスイネーブラは、ＸＤＭコピー及びＸＤＭフォワード（Forward）を含む新たなＸＤＭ機能をサポートする。これら機能は、ＸＤＭＳにすでに存在しているＸＭＬ文書を取り出すか、又はこのＸＤＭＳ文書を他のユーザーに伝達するために使用される［ＸＤＭ２_ＲＤ］（参考文献:"OMA XML Document Management Requirements," Version 2.0, Open Mobile Alliance, OMA-RD-XDM-V2_0, URL: http://www.openmobilealliance.org/）。したがって、これらがＸＭＬ文書をＸＤＭＳに生成するための既存のＸＤＭ機能を使用して実現される場合には、図２のステップ２０及びステップ２２で、ＸＤＭＣは、対応するＸＭＬ文書をＸＤＭＳから取り出す（retrieve）ためにＸＣＡＰＧＥＴ要請を送信する。この後、ＸＤＭＣは、図２のステップ２４及びステップ２６で、ＸＤＭＳから取り出したＸＭＬ文書をＸＣＡＰＰＵＴ要請に含ませることにより、図２のステップ２４及びステップ２６で、この文書を所望のＸＤＭＳに生成し、格納する。

上述したような過程の根本的な理由は、このＸＤＭｖ１．０サービスイネーブラでＸＭＬ文書をＸＤＭＳに生成する技術について説明したように、新たなＸＭＬ文書をＸＤＭＳに生成するためには、対応するＸＭＬ文書は、ＸＣＡＰＰＵＴ要請に含まれる必要があるためである。
言い換えれば、ＸＤＭＣは、すでにＸＤＭＳに格納されているＸＭＬ文書を取り出し、このＸＭＬ文書をＸＤＭＳにさらに格納する。その結果、重複した情報をやり取りするシグナリングオーバーヘッドを引き起こす。また、ＸＤＭサービスイネーブラは、無線環境でのサービスを提供し、したがって、上述したようなシグナリングが無線チャンネルを介して発生することを考慮すれば、このようなシグナリングオーバーヘッドは、リソースの浪費及び処理時間の遅延を引き起こす。

Open Mobile Alliance, "OMA XML Document Management Requirements," Version 2.0, OMA-RD-XDM-V2_0, URL: http://www.openmobilealliance.org/ N. Freed, et al., "Definition of the URL MIME External-Body Access-Type," RFC 2017, October 1996, URL: http://www.ietf.org/rfc/rfc2017.txt E. Burger, Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP Messages)," RFC 4483, May 2006, URL: http://www.ietf.org/rfc/rfc4483.txt Open Mobile Alliance, "XML Document Management (XDM) Specification," Version 1.0, OMA-TS-XDM_CORE-V1_0, URL: http://www.openmobilealliance.org/

したがって、本発明は、上述した従来技術の問題点を解決するために提案されたものであり、その目的は、ＸＣＡＰ文書のＵＲＬを使用してＸＭＬ文書をＸＤＭＳに間接的に生成するためのシステム及び方法を提供することにある。
本発明の他の目的は、ＸＣＡＰ文書のＵＲＬを使用してＸＭＬ文書をＸＤＭＳに間接的に生成することにより、ＸＤＭｖ２．０サービスイネーブラのＸＤＭコピー機能を具体的に実現するためのシステム及び方法を提供することにある。

上記のような目的を達成するために、本発明の実施形態の一態様によれば、拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現するＸＭＬ文書管理（ＸＤＭ）システムを提案する。上記ＸＤＭシステムは、生成されるＸＭＬ文書のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）及び格納位置を含むＸＣＡＰＰＵＴ要請メッセージを対応するＸＤＭサーバ（ＸＤＭＳ）に送信するＸＤＭクライアント（ＸＤＭＣ）と、上記ＸＣＡＰＰＵＴ要請メッセージを受信し、上記ＸＣＡＰＰＵＴ要請メッセージに含まれているＸＣＡＰＵＲＩに対応するＸＭＬ文書を取り出し、上記ＸＭＬ文書を対応する格納位置に格納するＸＤＭＳと、を具備することを特徴とする。

本発明の実施形態の他の態様によれば、拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）及び拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）を含む拡張可能マークアップ言語文書管理（ＸＤＭ）システムにおける拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法を提案する。上記方法は、上記ＸＤＭＣが生成されるＸＭＬ文書のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）及び格納位置を含むＸＣＡＰＰＵＴ要請メッセージを対応するＸＤＭＳに送信するステップと、上記ＸＤＭＳが上記ＸＣＡＰＰＵＴ要請メッセージを受信し、上記ＸＣＡＰＰＵＴ要請メッセージに含まれている上記ＸＣＡＰＵＲＩに対応するＸＭＬ文書を取り出し、上記ＸＭＬ文書を対応する格納位置に格納するステップと、を有することを特徴とする。

本発明で提案された方法は、ＸＤＭｖ２．０サービスイネーブラのＸＤＭコピー及びＸＤＭフォワードのような新たな機能を実現するために使用されることができる。この方法は、ＸＤＭＣがＸＤＭＳにすでに格納されているＸＭＬ文書を取り出し、ＸＭＬ文書をＸＤＭＳにさらに格納する場合に（すなわち、重複した情報をやり取りする場合に）発生するシグナリングオーバーヘッド問題を解決することができる。したがって、無線チャンネル及びシステムリソースの性能を向上させ、要請処理時間を短縮させることができる。

従来技術によるＸＭＬ文書をＸＤＭＳに生成する過程を示すフローチャートである。従来技術によるフォワード／コピー機能を実現する過程を示すフローチャートである。本発明によるシングルドメインでＸＭＬ文書のＸＣＡＰＵＲＩを用いて間接的にＸＭＬ文書を生成する過程を示すフローチャートである。本発明によるマルチドメインでＸＭＬ文書のＸＣＡＰＵＲＩを用いて間接的にＸＭＬ文書を生成する過程を示すフローチャートである。本発明によるＸＤＭＳでＸＭＬ文書のＸＣＡＰＵＲＩを用いて間接的にＸＭＬ文書を生成する過程を示すフローチャートである。

以下、本発明の好適な実施形態について添付図面を参照して詳細に説明する。なお、図面中、同一の構成要素及び部分には、可能な限り同一の符号及び番号を共通使用するものとする。下記説明において、本発明の要旨のみを明瞭にするために、公知の機能又は構成についての詳細な説明は省略する。
添付の図面を参照して、本発明による拡張可能マークアップ言語コンフィギュレーションアクセスプロトコル（eXtensible Markup Language (XML) Configuration Access Protocol：以下、"ＸＣＡＰ"と称する）文書のユニフォームリソース識別子（Uniform Resource Identifier：以下、"ＵＲＩ"と称する）を使用して拡張可能マークアップ言語（eXtensible markup language：以下、"ＸＭＬ"と称する）文書をＸＭＬ文書管理サーバ（XML Document Management Server：以下、"ＸＤＭＳ"と称する）に間接的に生成するようにすることにより、ＸＭＬ文書管理（XML Document Management：以下、"ＸＤＭ"と称する）の生成及びコピー機能を実現する方法だけではなく、ＸＤＭｖ２．０サービスイネーブラのＸＤＭ機能を向上させる方法について説明する。

まず、ＸＭＬ文書のＵＲＬを用いてＸＣＡＰ要請に対応するＸＭＬ文書を間接的に記述する方法について説明する。
"Definition of the URL MIME External-Body Access-Type," N. Freed, et al., RFC (Request For Comment) 2017, October 1996, URL: http://www.ietf.org/rfc/rfc2017.txt [RFC2017] and "A Mechanism for Content Indirection in Session Initiation Protocol (SIP Messages)," E. Burger, Ed., RFC 4483, May 2006, URL: http://www.ietf.org/rfc/rfc4483.txt [RFC4483]の開示によれば、あるオブジェクト（object）をＨＴＴＰ又はＳＩＰ要請に直接記述する代わりに、このオブジェクトのＵＲＬだけをＨＴＴＰ又はＳＩＰ要請に含ませることにより、このオブジェクトを間接的に記述する（すなわち、'message/external-body'MIME (Multimedia Internet Message Extensions)）タイプ）。

本発明は、ＸＭＬ文書のＸＣＡＰＵＲＩだけをＸＣＡＰ要請に記述することによりＸＭＬ文書を間接的に表現するために、このような'message/external-body'ＭＩＭＥタイプを使用する。ここで、ＸＭＬ文書のＸＣＡＰＵＲＩは、ＸＤＭＳ内のＸＭＬ文書の格納位置を意味し、ＸＣＡＰルートＵＲＩをＸＣＡＰ文書セレクタ（document selector）に連結する（concatenate）ことにより得られる[XDM_Core]（参考文献："XML Document Management (XDM) Specification," Version 1.0, Open Mobile AllianceTM, OMA-TS-XDM_CORE-V1_0, URL: http://www.openmobilealliance.org/）。'message/external-body'ＭＩＭＥタイプに基づいて、ＸＭＬ文書のＸＣＡＰＵＲＩだけを含むＸＣＡＰＰＵＴ要請メッセージは、下記の＜表３＞に示すように得られる。

＜表３＞を参照すると、"message/external-body Content-Type"は、このＸＣＡＰ要請のコンテンツが外部オブジェクト（external object）であることを意味する。また、"ACCESS-TYPE"、"ＵＲＬ"、及び"size"は、"message/external-body Content-Type"の選択的な（optional）パラメータであり、対応する外部オブジェクトがＵＲＬに基づいてアクセスされ、このＵＲＬは、"http://xcap.example.com/org.openmobilealliance.poc/users/sip:copyee@example.com/source-poc-group.xml"のＸＣＡＰＵＲＩであり、この外部オブジェクトは、特定のサイズを有することをそれぞれ意味する。この外部オブジェクトのコンテンツタイプは、"Content-Type: message/external-body"の下にさらに記述され、"Content-Type: application/vnd.oma.poc.groups+xml"は、このＵＲＬに存在している外部オブジェクトのコンテンツタイプがプッシュツートークオーバーセルラー（Push to Talk Over Cellular：以下、"ＰｏＣ"と称する）グループＸＭＬ文書に対応することを意味する。
多くの外部オブジェクトは、マルチパート（Multipart）ＭＩＭＥタイプを用いて表現されることができる。下記の＜表４＞は、２つのＰｏＣグループＸＭＬ文書をこれらのＸＣＡＰＵＲＩのみを用いて記述することにより、ＸＣＡＰ要請内に間接的に表現した例を示す。

本発明の他の１つの観点は、上述した方法の代替案を提供する。特に、新たなＸＭＬアプリケーションＭＩＭＥタイプを定義することにより、対応するＸＭＬ文書をＸＭＬに間接的に表現する方法を提案する。説明の便宜上、ＸＭＬ文書は、この新たなＭＩＭＥタイプの名称として"application/vnd.oma.external-body+xml"を使用する。このＸＭＬ情報は、上述した方法と同様に、対応する外部オブジェクト、すなわち、ＸＭＬ文書のＸＣＡＰＵＲＩを含み、サイズ及びコンテンツタイプなとの情報は、選択的に記述される。下記の＜表５＞及び＜表６＞は、上述した＜表３＞及び＜表４＞の例をＸＭＬタイプで各々変形した後に表現したのである。

ＸＭＬ文書のＸＣＡＰＵＲＩを記述するようによりＸＭＬ文書をＸＤＭＳに間接的に生成する方法について説明する。
本発明は、ＸＣＡＰＰＵＴ要請メッセージにその文書自体を含ませず、対応するＸＭＬ文書のＸＣＡＰＵＲＩを記述することにより、このＸＭＬ文書をＸＤＭＳに生成する手続きを提供する。この手続きについては、２通りの場合を参照して説明する。１番目の場合において、ＸＣＡＰＵＲＩを用いて記述されたＸＭＬ文書が格納されているＸＤＭＳは、対応するＸＭＬ文書が新たに生成されるＸＤＭＳと同一のドメイン（すなわち、シングルドメイン（single domain））に存在し、２番目の場合において、ＸＣＡＰＵＲＩを用いて記述されたＸＭＬ文書が格納されているＸＤＭＳは、対応するＸＭＬ文書が新たに生成されるＸＤＭＳと異なるドメイン（すなわち、マルチドメイン（multiple domain））に存在する。

この１番目の場合（シングルドメイン）に基づいて、すなわち、ＸＣＡＰＵＲＩを用いて記述されたＸＭＬ文書が格納されているＸＤＭＳが、対応するＸＭＬ文書が新たに生成されるＸＤＭＳと同一のドメインに存在するとの見方に立った上で、図３を参照して説明する。
まず、ユーザー又はＸＤＭＣは、ステップ３０で、生成されるＸＭＬ文書のＸＣＡＰＵＲＩを含むＸＣＡＰＰＵＴ要請メッセージを対応するＸＤＭＳに送信する。ＸＤＭＳは、ＸＣＡＰＰＵＴ要請メッセージに含まれているＸＣＡＰＵＲＩに基づいて、図３のステップ３２で、対応するＸＭＬ文書がＸＤＭＳ内に格納されていることを確認する。その後に、ＸＤＭＳは、対応するＸＭＬ文書を取り出し、ＸＣＡＰＰＵＴ要請メッセージ内の格納位置を確認し、ＸＭＬ文書を生成した後に、このＸＭＬ文書を要請された位置に格納する。図３のステップ３４で、ＸＤＭＳは、対応するＸＭＬ文書の生成に成功したことを通知するための２０１生成（created）メッセージをＸＤＭＣに送信する。

上述した＜表３＞及び＜表５＞は、図３に示したＸＣＡＰＰＵＴ要請メッセージの例を示し、ＸＣＡＰＰＵＴ要請メッセージは、図３に示した過程に基づいて次の方法で処理される。
１．"sip:copyer@example.com"で表されるユーザーは、"http://xcap.example.com/org.openmobilealliance.poc"と記述されるＰｏＣＸＤＭＳ内の"/users/sip:copyer@example.com"と記述される自身のユーザーディレクトリ（user directory）に、"http://xcap.example.com/org. openmobilealliance.poc/users/sip:copyee@example.com/source-poc-group.xml"と記述されるＰｏＣグループＸＭＬ文書を"copyed-poc-group.xml"と名付けられるＰｏＣグループＸＭＬ文書として生成することを要請する。
２．対応するＰｏＣＸＤＭＳは、要請されたＰｏＣグループＸＭＬ文書が自身に格納されていることを確認し、"source-PoC-group.xml"ＰｏＣグループ文書を"sip:copyee@example.com"のユーザーディレクトリから取り出し、"sip:copyer@example.com"のユーザーディレクトリに"copyed-PoC-group.xml"と名付けられる文書を生成する。
３．対応するＰｏＣＸＤＭＳは、ＸＭＬ文書の生成に成功した結果を"sip:copyer@example.com"で表されるユーザーに通知する。

生成されるＸＭＬ文書が異なるドメインのＸＭＳにある２番目の場合（すなわち、マルチドメイン）について図４を参照して説明する。図４は、ドメインＡにあるＸＤＭＳ、すなわち、ＸＭＬ文書が生成されるＸＤＭＳがドメインＢのＸＤＭＳに格納されているＸＭＬ文書をＸＣＡＰＧＥＴ要請メッセージを使用して直接取り出す（retrieve）点を除いては、図３と同一である。この場合については、図４を参照して説明する。
まず、ユーザー又はＸＤＭＣは、図４のステップ４０で、生成されるＸＭＬ文書のＸＣＡＰＵＲＩを含むＸＣＡＰＰＵＴ要請メッセージを対応するＸＤＭＳに送信する。ドメインＡ内のＸＤＭＳは、ＸＣＡＰＰＵＴ要請メッセージに含まれているＸＣＡＰＵＲＩに基づいて、対応するＸＭＬ文書が他のＸＤＭＳ、すなわち、ドメインＢ内のＸＤＭＳに格納されていることを確認し、図４のステップ４２で、このＸＭＬ文書に関するＸＣＡＰＧＥＴ要請メッセージを送信する。この場合に、両方のＸＤＭＳは、同一のアプリケーションＩＤを有する。

ＸＣＡＰＧＥＴ要請メッセージを受信すると、ドメインＢ内のＸＤＭＳは、ステップ４４で、要請されたＸＭＬ文書をＸＣＡＰＧＥＴ要請に応じてドメインＡ内のＸＤＭＳに送信する。ドメインＡ内のＸＤＭＳは、ＸＣＡＰＰＵＴ要請メッセージに基づいて送信されたこのＸＭＬ文書を格納する位置を確認した後に、このＸＭＬ文書を生成し、要請された位置に格納する。ドメインＡ内のＸＤＭＳは、ステップ４８で、対応するＸＭＬ文書の生成に成功したことを通知するための２０１生成メッセージをＸＤＭＣに送信する。
下記の＜表７＞、＜表８＞、及び＜表９＞は、図４のステップ４０で送信されたＸＣＡＰＰＵＴ要請メッセージ、図４のステップ４２で送信されたＸＣＡＰＧＥＴ要請メッセージ、図４のステップ４４で送信されたＸＣＡＰＧＥＴ応答メッセージの例をそれぞれ示す。

上述した＜表７＞を参照すると、"xcap.example.com"ドメイン内のＰｏＣＸＤＭＳは、＜表７＞に示したＸＣＡＰＰＵＴ要請メッセージに含まれているＸＣＡＰＵＲＩに基づいて、要請されるＰｏＣグループＸＭＬ文書が"xcap.example2.com"ドメイン内のＰｏＣＸＤＭＳに格納されていることを確認する。この後に、"xcap.example.com"ドメイン内のＰｏＣＸＤＭＳは、＜表８＞に示したＸＣＡＰＧＥＴ要請メッセージを"xcap.example2.com"ドメイン内のＰｏＣＸＤＭＳに送信する。この際、＜表８＞に示したＸＣＡＰＧＥＴ要請メッセージの要請ラインは、＜表７＞に示したＸＣＡＰＰＵＴ要請メッセージを介して送信された対応するＰｏＣグループ文書のＸＣＡＰＵＲＩに対応し、"X-XCAP-Asserted-Identify"は、＜表７＞に示したＸＣＡＰＰＵＴ要請と同一の"sip:copyer@example.com"となる。
"xcap.example2.com"ドメイン内のＰｏＣＸＤＭＳは、対応するＰｏＣグループ文書を取り出し、ＰｏＣＸＤＭＳ文書を＜表９＞に示した応答メッセージに付加し、このＰｏＣＸＤＭＳ文書を"xcap.example.com"ドメイン内のＰｏＣＸＤＭＳに送信する。
このＰｏＣグループ文書を受信すると、"xcap.example.com"ドメイン内のＰｏＣＸＤＭＳは、＜表７＞に示したＸＣＡＰＰＵＴ要請の要請ラインに明示された通りに、"sip:copyer@example.com"のユーザーディレクトリに"copyed-poc-group.xml"のＸＭＬ文書を生成し、この送信されたＰｏＣグループ文書を格納する。

上記では、１つのＸＭＬ文書についてＸＣＡＰＵＲＩの記述を用いてＸＭＬ文書をＸＤＭＳに間接的に生成する方法について説明したが、複数のＸＭＬ文書についてＸＣＡＰＵＲＩの記述を用いてＸＭＬ文書をＸＤＭＳに間接的に生成することもできる。
複数のＸＭＬ文書のＸＣＡＰＵＲＩの記述を用いてＸＭＬ文書をＸＤＭＳに間接的に生成する方法について説明する。
上述した＜表４＞及び＜表６＞のように、複数のターゲットＸＭＬ文書がＸＣＡＰＰＵＴ要請メッセージに記述されたＸＣＡＰＵＲＩを含む場合にも、図３及び図４のような手続きと同一に処理される。この場合には、複数のＸＭＬ文書が生成されるため、ＸＣＡＰＰＵＴ要請の要請ラインは、生成されるＸＭＬ文書のＸＣＡＰＵＲＩの代わりに、生成されるユーザーディレクトリまで記述する点に留意すべきである。この場合には、生成されるＸＭＬ文書の名称は、このユーザーディレクトリで唯一の（unique）いずれのものも可能であり、一般的な場合には、ターゲットＸＭＬ文書と同一である。すなわち、＜表４＞及び＜表６＞において、"sip:copyee@example.com"のユーザーディレクトリから取り出された"source-PoC-group.xml"及び"source-PoC-group2.xml"は、"sip:copyer@example.com"のユーザーディレクトリに"source-PoC-group.xml"及び"source-PoC-group2.xml"としてそれぞれ生成され、格納されてもよい。

一方、図３及び図４の過程では、ＸＭＬ文書の生成を要請するユーザーの権限（authorization）の確認は、説明の便宜上省略した。しかしながら、実際の実現にあたり、ＸＭＬ文書の生成を要請するユーザーがこれを行う権限があるか否かがかならず確認されなければならない。このメッセージの例から明らかなように、要請者のＩＤは、"X-XCAP-Asserted-Identify"ヘッダー又は対応する他のタイプのヘッダーを介してＸＤＭＳに送信される。各ＸＤＭＳは、ある動作を行う前に、この要請者の権限の確認を実行する。特に、ＸＤＭＳは、この要請者がＸＣＡＰＰＵＴ要請メッセージの要求ラインに記述されたユーザーディレクトリにＸＭＬ文書を生成する権限があるか否かを確認する。また、ＸＤＭＳは、この要請者がＸＭＬ文書のＸＣＡＰＵＲＩを用いて記述されたＸＭＬ文書を取り出す権限があるか否かを確認する。ＸＣＡＰＧＥＴ要請メッセージをもって対応するＸＭＬ文書を他のドメイン内のＸＤＭＳから取り出す場合には、取出し権限は、ＸＣＡＰＧＥＴ要請を受信したＸＤＭＳ、例えば、図４に示したドメインＢ内のＸＤＭＳにより確認されてもよい。

図５を参照して、ＸＤＭＳがＸＤＭＣからＸＭＬ文書の生成を要請するために、ＸＭＬ文書に対応するＸＣＡＰＵＲＩを含むＸＣＡＰＰＵＴ要請メッセージを受信した後に、対応するＸＭＬ文書を指定された位置に生成し、格納する過程について説明する。
ステップ５００で、ＸＤＭＳは、ＸＣＡＰＰＵＴ要請メッセージを受信する。ＸＤＭＳは、ステップ５０２で、受信されたこのＸＣＡＰＰＵＴ要請メッセージの"message/external-body Content-Type"が外部オブジェクトに対応するか否かを検査する。この検査の結果、受信されたＸＣＡＰＰＵＴ要請メッセージの"message/external-body Content-Type"が外部オブジェクトに対応すると、ＸＤＭＳは、ステップ５０４に進み、そうでなければ、ステップ５０３に進み、受信されたＸＣＡＰＰＵＴ要請メッセージについて対応する処理を実行する。

ステップ５０２からステップ５０４に進んだ後に、ＸＤＭＳは、この要請者が要請ラインに記述されたユーザーディレクトリにＸＭＬ文書を生成する権限があるか否かを検査する。この際に、この権限の検査は、ＸＣＡＰＰＵＴ要請メッセージのヘッダーに含まれている要請者のＩＤに基づく。この検査の結果、ステップ５０４で、要請者が対応する権限がある場合には、ステップ５０６に進み、ＸＣＡＰＵＲＩを参照して記述されたＸＭＬ文書が格納されているか否かを検査する。
ＸＣＡＰＵＲＩを参照して記述されたＸＭＬ文書が格納されている場合には、ＸＤＭＳは、ステップ５０８に進み、そうでなければ、ステップ５１８に進み、記述されたＸＣＡＰＵＲＩを含む要請ライン及び要請者のＩＤを含むＸＣＡＰＧＥＴ要請メッセージを対応するドメインのＸＤＭＳに送信する。この後に、ＸＤＭＳは、ステップ５２０に進み、ＸＣＡＰＧＥＴ要請メッセージに対する応答メッセージ、すなわち、対応するＸＭＬ文書を含んでいる応答メッセージを受信すると、ステップ５１２に進む。

一方、この検査の結果、ステップ５０６で、ＸＣＡＰＵＲＩを参照して記述されたＸＭＬ文書が格納されている場合には、ＸＤＭＳは、ステップ５０８に進み、この要請者が対応するＸＭＬ文書を取り出す権限があるか否かを検査する。この際に、この権限の検査は、ステップ５０４のように、ＸＣＡＰＰＵＴ要請メッセージのヘッダーに含まれている要請者のＩＤに基づく。この要請者が対応するＸＭＬ文書を取り出す権限がある場合には、ＸＤＭＳは、ステップ５１０に進み、対応するＸＭＬ文書を取り出す。その後に、ＸＤＭＳは、ステップ５１２で、対応するＸＭＬ文書を要請ラインにより指定された位置に生成し、格納する。ＸＤＭＳは、ステップ５１４に進み、ＸＣＡＰＵＲＩを参照して記述された他のＸＭＬがあるか否かを検査する。この検査の結果、ステップ５１４で、ＸＣＡＰＵＲＩを参照して記述された他のＸＭＬがある場合には、ＸＤＭＳは、ステップ５０６に進み、ＸＭＬ文書に関する要請された機能を実行する。他方、ステップ５１４で、ＸＣＡＰＵＲＩを参照して記述されたＸＭＬ文書がこれ以上ない場合には、ＸＤＭＳは、ステップ５１６に進み、ＸＤＭＣ（すなわち、要請者）に実行の結果を送信する。

以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。

Claims

拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）及び拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）を含む拡張可能マークアップ言語文書管理（ＸＤＭ）システムにおいて、ＸＤＭＣが拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法であって、
複数の拡張可能マークアップ言語（ＸＭＬ）文書のそれぞれが格納された複数の第１の格納位置を示す複数のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）と、前記複数の拡張可能マークアップ言語（ＸＭＬ）文書が新しく格納される第２の格納位置とを含み、該当拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）により前記拡張可能マークアップ言語（ＸＭＬ）文書の検索のためのＸＣＡＰＰＵＴ要請メッセージを生成するステップと、
前記ＸＣＡＰＰＵＴ要請メッセージを前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）に送信するステップと、を含み、
前記ＸＣＡＰＰＵＴ要請メッセージには、前記拡張可能マークアップ言語（ＸＭＬ）文書は含まれなく、前記拡張可能マークアップ言語（ＸＭＬ）文書が外部オブジェクトであることを示す情報と、前記拡張可能マークアップ言語（ＸＭＬ）文書のコンテンツタイプを示す情報が含まれ、前記ＸＣＡＰＵＲＩは、ＸＣＡＰルートＵＲＩとＸＣＡＰ文書セレクタを連結することにより得られ、
前記第２の格納位置は、前記複数の拡張可能マークアップ言語（ＸＭＬ）文書が新しく格納されるユーザーディレクトリで記述され、前記複数の拡張可能マークアップ言語（ＸＭＬ）文書は前記ユーザーディレクトリの下位に唯一の（unique）名称で格納されることを特徴とする方法。
前記第１の格納位置のそれぞれの拡張可能マークアップ言語（ＸＭＬ）文書が前記ＸＣＡＰＰＵＴ要請メッセージにより指定された前記第２の格納位置に格納された後、該当文書の生成に成功したことを前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）から通報されるステップをさらに含むことを特徴とする請求項１に記載の方法。
前記ＸＣＡＰＰＵＴ要請メッセージは、前記ＸＤＭＣのディレクトリ、ユーザー識別子（ＩＤ）、コンテンツタイプ、アクセスタイプ、生成される拡張可能マークアップ言語（ＸＭＬ）文書のＸＣＡＰＵＲＩ、及びサイズから成るグループから選択された少なくとも１つの情報を含むことを特徴とする請求項１に記載の方法。
前記ＸＣＡＰＰＵＴ要請メッセージに含まれた前記拡張可能マークアップ言語（ＸＭＬ）文書の前記ＸＣＡＰＵＲＩのドメインが前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）のドメインと同一であることを特徴とする請求項１に記載の方法。
前記ＸＣＡＰＰＵＴ要請メッセージに含まれた前記拡張可能マークアップ言語（ＸＭＬ）文書の前記ＸＣＡＰＵＲＩのドメインが新しく拡張可能マークアップ言語（ＸＭＬ）文書が生成される拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）のドメインと相異であることを特徴とする請求項１に記載の方法。
前記ＸＣＡＰＰＵＴ要請メッセージは、前記拡張可能マークアップ言語（ＸＭＬ）文書のサイズと前記拡張可能マークアップ言語（ＸＭＬ）文書のコンテンツタイプのうち、少なくとも一つを含むことを特徴とする請求項１に記載の方法。
拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）及び拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）を含む拡張可能マークアップ言語文書管理（ＸＤＭ）システムにおいて、拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）が拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法であって、
（ａ）複数の拡張可能マークアップ言語（ＸＭＬ）文書のそれぞれが格納された複数の第１の格納位置を示す複数のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）を含み、前記拡張可能マークアップ言語（ＸＭＬ）文書の検索のためのＸＣＡＰＰＵＴ要請メッセージを前記拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）から受信するステップと、
（ｂ）前記ＸＣＡＰＰＵＴ要請メッセージに含まれている前記複数のＸＣＡＰＵＲＩに対応する前記複数の第１の格納位置で前記複数の拡張可能マークアップ言語（ＸＭＬ）文書を取り出すステップと、
（ｃ）前記複数の拡張可能マークアップ言語（ＸＭＬ）文書を前記ＸＣＡＰＰＵＴ要請メッセージに含まれた第２の格納位置に格納するステップと、を含み、
前記ＸＣＡＰＰＵＴ要請メッセージには、前記拡張可能マークアップ言語（ＸＭＬ）文書は含まれなく、前記拡張可能マークアップ言語（ＸＭＬ）文書が外部オブジェクトであることを示す情報と、前記拡張可能マークアップ言語（ＸＭＬ）文書のコンテンツタイプを示す情報が含まれ、前記ＸＣＡＰＵＲＩは、ＸＣＡＰルートＵＲＩとＸＣＡＰ文書セレクタを連結することにより得られ、前記第２の格納位置は、前記複数の拡張可能マークアップ言語（ＸＭＬ）文書が新しく格納されるユーザーディレクトリで記述され、前記複数の拡張可能マークアップ言語（ＸＭＬ）文書は前記ユーザーディレクトリの下位に唯一の（unique）名称で格納されることを特徴とする拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記拡張可能マークアップ言語（ＸＭＬ）文書を前記第２の格納位置に格納した後に、前記ＸＣＡＰＵＲＩに対応する拡張可能マークアップ言語（ＸＭＬ）文書の生成に成功したことを前記ＸＤＭＣに通知するステップをさらに含むことを特徴とする請求項７に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＣＡＰＰＵＴ要請メッセージは、前記ＸＤＭＣのディレクトリ、ユーザー識別子（ＩＤ）、コンテンツタイプ、アクセスタイプ、生成される拡張可能マークアップ言語（ＸＭＬ）文書のＸＣＡＰＵＲＩ、及びサイズから成るグループから選択された少なくとも１つの情報を含むことを特徴とする請求項７に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記第１の格納位置で前記拡張可能マークアップ言語（ＸＭＬ）文書を取り出すステップは、
前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）が前記ＸＣＡＰＰＵＴ要請メッセージを受信する場合には、前記ＸＣＡＰＰＵＴ要請メッセージが拡張可能マークアップ言語（ＸＭＬ）生成のための要請メッセージであることを認識するステップと、
前記ＸＤＭＣが拡張可能マークアップ言語（ＸＭＬ）文書をディレクトリに生成する権限があるか否かを確認するステップと、
前記ＸＤＭＣが前記拡張可能マークアップ言語（ＸＭＬ）文書を前記ディレクトリに生成する権限がある場合には、前記ＸＣＡＰＵＲＩに対応する拡張可能マークアップ言語（ＸＭＬ）文書が格納されているか否かを検査するステップと、
前記ＸＣＡＰＵＲＩに対応する前記拡張可能マークアップ言語（ＸＭＬ）文書が格納されている場合には、前記ＸＤＭＣが対応する拡張可能マークアップ言語（ＸＭＬ）文書を取り出す権限があるか否かを確認するステップと、
前記ＸＣＡＰＵＲＩに対応する前記拡張可能マークアップ言語（ＸＭＬ）文書が格納されており、前記ＸＤＭＣが前記対応する拡張可能マークアップ言語（ＸＭＬ）文書を取り出す権限がある場合には、前記ＸＣＡＰＵＲＩに対応する前記拡張可能マークアップ言語（ＸＭＬ）文書を取り出すステップと、を有することを特徴とする請求項７に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＣＡＰＵＲＩに対応する前記拡張可能マークアップ言語（ＸＭＬ）文書が前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）に格納されていない場合には、ＸＣＡＰＧＥＴ要請メッセージを前記ＸＣＡＰＵＲＩに対応する拡張可能マークアップ言語（ＸＭＬ）文書を格納している他の拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）に送信し、前記ＸＣＡＰＵＲＩに対応する拡張可能マークアップ言語（ＸＭＬ）文書を受信するステップをさらに含むことを特徴とする請求項１０に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＣＡＰＰＵＴ要請メッセージが拡張可能マークアップ言語（ＸＭＬ）生成のための要請メッセージであることを認識するステップは、
前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）が前記ＸＣＡＰＰＵＴ要請メッセージに含まれているコンテンツタイプを検査した後に、前記コンテンツタイプが外部ボディーである場合には、前記ＸＣＡＰＰＵＴ要請メッセージが拡張可能マークアップ言語（ＸＭＬ）生成のための要請メッセージであることを認識することを特徴とする請求項１０に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＤＭＣが拡張可能マークアップ言語（ＸＭＬ）文書をディレクトリに生成する権限があるか否かを確認するステップは、ユーザーが前記ＸＣＡＰＰＵＴ要請メッセージに含まれているユーザーＩＤを用いて拡張可能マークアップ言語（ＸＭＬ）文書を前記ディレクトリに生成する権限があるか否かを確認するステップであることを特徴とする請求項１０に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＣＡＰＵＲＩに対応する前記拡張可能マークアップ言語（ＸＭＬ）文書が前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）に格納されている場合には、前記ＸＤＭＣが前記ＸＣＡＰＰＵＴ要請メッセージに含まれているユーザーＩＤを用いて対応する拡張可能マークアップ言語（ＸＭＬ）文書を取り出す権限があるか否かを検査するステップと、
前記ＸＤＭＣが前記対応する拡張可能マークアップ言語（ＸＭＬ）文書を取り出す権限がある場合には、前記ＸＣＡＰＵＲＩに対応する拡張可能マークアップ言語（ＸＭＬ）文書を取り出すステップと、をさらに含むことを特徴とする請求項１０に記載の拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法。
前記ＸＣＡＰＰＵＴ要請メッセージに含まれた前記拡張可能マークアップ言語（ＸＭＬ）文書の前記ＸＣＡＰＵＲＩのドメインが前記拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）のドメインと同一であることを特徴とする請求項７に記載の方法。
前記ＸＣＡＰＰＵＴ要請メッセージに含まれた前記拡張可能マークアップ言語（ＸＭＬ）文書の前記ＸＣＡＰＵＲＩのドメインが新しく拡張可能マークアップ言語（ＸＭＬ）文書が生成される拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）のドメインと相異であることを特徴とする請求項７に記載の方法。