(57)【要約】  拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）及び拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）を含む拡張可能マークアップ言語文書管理（ＸＤＭ）システムにおいて、ＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）文書の位置を示すユニフォームリソース識別子（ＵＲＩ）を使用して拡張可能マークアップ言語（ＸＭＬ）文書をＸＤＭＳに間接的に生成する方法を提供する。この方法は、ＸＤＭＣが生成されるＸＭＬ文書のＸＣＡＰ ＵＲＩ及び格納位置を含むＸＣＡＰ ＰＵＴ要請メッセージを対応するＸＤＭＳに送信するステップと、ＸＤＭＳがＸＣＡＰ ＰＵＴ要請メッセージを受信し、ＸＣＡＰ ＰＵＴ要請メッセージに含まれているＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、ＸＭＬ文書を対応する格納位置に格納するステップと、を含む。
2010500685.tif 000002
【特許請求の範囲】
【請求項１】
拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現するＸＭＬ文書管理（ＸＤＭ）システムであって、
生成されるＸＭＬ文書のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）及び格納位置を含むＸＣＡＰ ＰＵＴ要請メッセージを対応するＸＤＭサーバ（ＸＤＭＳ）に送信するＸＤＭクライアント（ＸＤＭＣ）と、
前記ＸＣＡＰ ＰＵＴ要請メッセージを受信し、前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、前記ＸＭＬ文書を対応する格納位置に格納するＸＤＭＳと、
を具備することを特徴とするＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項２】
前記ＸＤＭＳが、前記ＸＭＬ文書を取り出し、前記ＸＭＬ文書を前記対応する格納位置に格納した後に、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書の生成が成功したことを前記ＸＤＭＣに通知することを特徴とする請求項１に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項３】
前記ＸＣＡＰ ＰＵＴ要請メッセージは、前記ＸＤＭＣのディレクトリ、ユーザー識別子（ＩＤ）、コンテンツタイプ、アクセスタイプ、生成されるＸＭＬ文書のＸＣＡＰ ＵＲＩ、及びサイズから成るグループから選択された少なくとも１つの情報を含むことを特徴とする請求項１に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項４】
前記ＸＤＭＳは、前記ＸＣＡＰ ＰＵＴ要請メッセージがＸＭＬ生成のための要請メッセージであることを認識し、前記ＸＤＭＣがＸＭＬ文書をディレクトリに生成する権限があるか否かを確認した後に、前記ＸＤＭＣが前記ＸＭＬ文書を前記ディレクトリに生成する権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を格納するか否かを検査し、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を格納している場合には、前記ＸＤＭＣが前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出す権限があるか否かを確認した後に、前記ＸＤＭＣが前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出す権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、前記ＸＭＬ文書を前記対応する格納位置に格納することを特徴とする請求項１に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項５】
前記ＸＤＭＳは、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を格納していない場合には、ＸＣＡＰ ＧＥＴ要請メッセージを前記ＸＭＬ文書を格納している他のＸＤＭＳに送信し、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を受信することを特徴とする請求項４に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項６】
前記ＸＤＭＳは、前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているコンテンツタイプが外部ボディーである場合には、前記ＸＣＡＰ ＰＵＴ要請メッセージがＸＭＬ生成のための要請メッセージであることを認識することを特徴とする請求項４に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項７】
前記ＸＤＭＳは、ユーザーが前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているユーザーＩＤを用いて前記ディレクトリにＸＭＬ文書を生成する権限があるか否かを確認することを特徴とする請求項４に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項８】
前記ＸＤＭＳは、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が格納されているか否かを検査し、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が格納されている場合には、前記ＸＤＭＣが前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているユーザーＩＤを用いて対応するＸＭＬ文書を取り出す権限があるか否かを検査した後に、前記ＸＤＭＣが前記対応するＸＭＬ文書を取り出す権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出すことを特徴とする請求項４に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項９】
前記ＸＤＭＣは、生成される少なくとも１つのＸＭＬ文書のＸＣＡＰ ＵＲＩ及び格納位置を含むＸＣＡＰ ＰＵＴ要請メッセージを対応するＸＤＭＳに送信し、
前記ＸＤＭＳが前記ＸＣＡＰ ＰＵＴ要請メッセージを受信し、前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれている各ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、前記ＸＭＬ文書を前記対応する格納位置に格納することを特徴とする請求項１に記載のＸＭＬ文書管理機能を実現するＸＤＭシステム。
【請求項１０】
拡張可能マークアップ言語文書管理クライアント（ＸＤＭＣ）及び拡張可能マークアップ言語文書管理サーバ（ＸＤＭＳ）を含む拡張可能マークアップ言語文書管理（ＸＤＭ）システムにおける拡張可能マークアップ言語（ＸＭＬ）文書管理機能を実現する方法であって、
（ａ）前記ＸＤＭＣが生成されるＸＭＬ文書のＸＭＬコンフィギュレーションアクセスプロトコル（ＸＣＡＰ）ユニフォームリソース識別子（ＵＲＩ）及び格納位置を含むＸＣＡＰ ＰＵＴ要請メッセージを対応するＸＤＭＳに送信するステップと、
（ｂ）前記ＸＤＭＳが前記ＸＣＡＰ ＰＵＴ要請メッセージを受信し、前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれている前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、前記ＸＭＬ文書を対応する格納位置に格納するステップと、
を有することを特徴とするＸＭＬ文書管理機能を実現する方法。
【請求項１１】
前記ＸＤＭＳが、前記ＸＭＬ文書を取り出し、前記ＸＭＬ文書を前記対応する格納位置に格納した後に、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書の生成に成功したことを前記ＸＤＭＣに通知するステップをさらに含むことを特徴とする請求項１０に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１２】
前記ＸＣＡＰ ＰＵＴ要請メッセージは、前記ＸＤＭＣのディレクトリ、ユーザー識別子（ＩＤ）、コンテンツタイプ、アクセスタイプ、生成されるＸＭＬ文書のＸＣＡＰ ＵＲＩ、及びサイズから成るグループから選択された少なくとも１つの情報を含むことを特徴とする請求項１０に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１３】
前記ステップ（ｂ）は、
前記ＸＤＭＳが前記ＸＣＡＰ ＰＵＴ要請メッセージを受信する場合には、前記ＸＣＡＰ ＰＵＴ要請メッセージがＸＭＬ生成のための要請メッセージであることを認識するステップと、
前記ＸＤＭＣがＸＭＬ文書をディレクトリに生成する権限があるか否かを確認するステップと、
前記ＸＤＭＣが前記ＸＭＬ文書を前記ディレクトリに生成する権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が格納されているか否かを検査するステップと、
前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が格納されている場合には、前記ＸＤＭＣが対応するＸＭＬ文書を取り出す権限があるか否かを確認するステップと、
前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が格納されており、前記ＸＤＭＣが前記対応するＸＭＬ文書を取り出す権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出し、前記ＸＭＬ文書を対応する格納位置に格納するステップと、を有することを特徴とする請求項１０に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１４】
前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が前記ＸＤＭＳに格納されていない場合には、ＸＣＡＰ ＧＥＴ要請メッセージを前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を格納している他のＸＤＭＳに送信し、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を受信するステップをさらに含むことを特徴とする請求項１３に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１５】
前記ＸＣＡＰ ＰＵＴ要請メッセージがＸＭＬ生成のための要請メッセージであることを認識するステップは、
前記ＸＤＭＳが前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているコンテンツタイプを検査した後に、前記コンテンツタイプが外部ボディーである場合には、前記ＸＣＡＰ ＰＵＴ要請メッセージがＸＭＬ生成のための要請メッセージであることを認識することを特徴とする請求項１３に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１６】
前記ＸＤＭＣがＸＭＬ文書をディレクトリに生成する権限があるか否かを確認するステップは、ユーザーが前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているユーザーＩＤを用いてＸＭＬ文書を前記ディレクトリに生成する権限があるか否かを確認するステップであることを特徴とする請求項１３に記載のＸＭＬ文書管理機能を実現する方法。
【請求項１７】
前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書が前記ＸＤＭＳに格納されている場合には、前記ＸＤＭＣが前記ＸＣＡＰ ＰＵＴ要請メッセージに含まれているユーザーＩＤを用いて対応するＸＭＬ文書を取り出す権限があるか否かを検査するステップと、
前記ＸＤＭＣが前記対応するＸＭＬ文書を取り出す権限がある場合には、前記ＸＣＡＰ ＵＲＩに対応するＸＭＬ文書を取り出すステップと、をさらに含むことを特徴とする請求項１３に記載のＸＭＬ文書管理機能を実現する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オープンモバイルアライアンス（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"の生成を要請することができる。
【０００３】
【表１】
2010500685.tif 000003
【０００４】
上述した＜表１＞に示すＸＣＡＰ ＰＵＴ要請メッセージを受信すると、ＸＤＭＳは、対応するＸＭＬ文書を生成し、生成に成功したことを知らせるために、図１のＸＣＡＰ２０１生成メッセージ１２をＸＤＭＣに送信する。この際、図１のＸＣＡＰ２０１生成メッセージ１２は、下記の＜表２＞に示すように構成される。
【０００５】
【表２】
2010500685.tif 000004
【０００６】
上述したように、ＸＭＬ文書は、ＸＤＭｖ１．０サービスイネーブラのＸＤＭを用いてＸＤＭＳに生成されることができる。さらに、ＸＤＭｖ２．０サービスイネーブラは、ＸＤＭコピー及びＸＤＭフォワード（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'ＭＩＭＥタイプに基づいて、ＸＭＬ文書のＸＣＡＰ ＵＲＩだけを含むＸＣＡＰ ＰＵＴ要請メッセージは、下記の＜表３＞に示すように得られる。
【００１７】
【表３】
2010500685.tif 000005
【００１８】
＜表３＞を参照すると、"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）ＭＩＭＥタイプを用いて表現されることができる。下記の＜表４＞は、２つのＰｏＣグループＸＭＬ文書をこれらのＸＣＡＰ ＵＲＩのみを用いて記述することにより、ＸＣＡＰ要請内に間接的に表現した例を示す。
【００１９】
【表４】
2010500685.tif 000006
【００２０】
本発明の他の１つの観点は、上述した方法の代替案を提供する。特に、新たなＸＭＬアプリケーションＭＩＭＥタイプを定義することにより、対応するＸＭＬ文書をＸＭＬに間接的に表現する方法を提案する。説明の便宜上、ＸＭＬ文書は、この新たなＭＩＭＥタイプの名称として"application/vnd.oma.external-body+xml"を使用する。このＸＭＬ情報は、上述した方法と同様に、対応する外部オブジェクト、すなわち、ＸＭＬ文書のＸＣＡＰ ＵＲＩを含み、サイズ及びコンテンツタイプなとの情報は、選択的に記述される。下記の＜表５＞及び＜表６＞は、上述した＜表３＞及び＜表４＞の例をＸＭＬタイプで各々変形した後に表現したのである。
【００２１】
【表５】
2010500685.tif 000007
【００２２】
ＸＭＬ文書のＸＣＡＰ ＵＲＩを記述するようによりＸＭＬ文書をＸＤＭＳに間接的に生成する方法について説明する。
本発明は、ＸＣＡＰ ＰＵＴ要請メッセージにその文書自体を含ませず、対応するＸＭＬ文書のＸＣＡＰ ＵＲＩを記述することにより、このＸＭＬ文書をＸＤＭＳに生成する手続きを提供する。この手続きについては、２通りの場合を参照して説明する。１番目の場合において、ＸＣＡＰ ＵＲＩを用いて記述されたＸＭＬ文書が格納されているＸＤＭＳは、対応するＸＭＬ文書が新たに生成されるＸＤＭＳと同一のドメイン（すなわち、シングルドメイン（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）点を除いては、図３と同一である。この場合については、図４を参照して説明する。
まず、ユーザー又はＸＤＭＣは、図４のステップ４０で、生成されるＸＭＬ文書のＸＣＡＰ ＵＲＩを含むＸＣＡＰ ＰＵＴ要請メッセージを対応するＸＤＭＳに送信する。ドメインＡ内のＸＤＭＳは、ＸＣＡＰ ＰＵＴ要請メッセージに含まれているＸＣＡＰ ＵＲＩに基づいて、対応するＸＭＬ文書が他のＸＤＭＳ、すなわち、ドメインＢ内のＸＤＭＳに格納されていることを確認し、図４のステップ４２で、このＸＭＬ文書に関するＸＣＡＰ ＧＥＴ要請メッセージを送信する。この場合に、両方のＸＤＭＳは、同一のアプリケーションＩＤを有する。
【００２６】
ＸＣＡＰ ＧＥＴ要請メッセージを受信すると、ドメインＢ内のＸＤＭＳは、ステップ４４で、要請されたＸＭＬ文書をＸＣＡＰ ＧＥＴ要請に応じてドメインＡ内のＸＤＭＳに送信する。ドメインＡ内のＸＤＭＳは、ＸＣＡＰ ＰＵＴ要請メッセージに基づいて送信されたこのＸＭＬ文書を格納する位置を確認した後に、このＸＭＬ文書を生成し、要請された位置に格納する。ドメインＡ内のＸＤＭＳは、ステップ４８で、対応するＸＭＬ文書の生成に成功したことを通知するための２０１生成メッセージをＸＤＭＣに送信する。
下記の＜表７＞、＜表８＞、及び＜表９＞は、図４のステップ４０で送信されたＸＣＡＰ ＰＵＴ要請メッセージ、図４のステップ４２で送信されたＸＣＡＰ ＧＥＴ要請メッセージ、図４のステップ４４で送信されたＸＣＡＰ ＧＥＴ応答メッセージの例をそれぞれ示す。
【００２７】
【表６】
2010500685.tif 000008
【００２８】
上述した＜表７＞を参照すると、"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"が外部オブジェクトに対応すると、ＸＤＭＳは、ステップ５０４に進み、そうでなければ、ステップ５０３に進み、受信されたＸＣＡＰ ＰＵＴ要請メッセージについて対応する処理を実行する。
【００３２】
ステップ５０２からステップ５０４に進んだ後に、ＸＤＭＳは、この要請者が要請ラインに記述されたユーザーディレクトリにＸＭＬ文書を生成する権限があるか否かを検査する。この際に、この権限の検査は、ＸＣＡＰ ＰＵＴ要請メッセージのヘッダーに含まれている要請者のＩＤに基づく。この検査の結果、ステップ５０４で、要請者が対応する権限がある場合には、ステップ５０６に進み、ＸＣＡＰ ＵＲＩを参照して記述されたＸＭＬ文書が格納されているか否かを検査する。
ＸＣＡＰ ＵＲＩを参照して記述されたＸＭＬ文書が格納されている場合には、ＸＤＭＳは、ステップ５０８に進み、そうでなければ、ステップ５１８に進み、記述されたＸＣＡＰ ＵＲＩを含む要請ライン及び要請者のＩＤを含むＸＣＡＰ ＧＥＴ要請メッセージを対応するドメインのＸＤＭＳに送信する。この後に、ＸＤＭＳは、ステップ５２０に進み、ＸＣＡＰ ＧＥＴ要請メッセージに対する応答メッセージ、すなわち、対応するＸＭＬ文書を含んでいる応答メッセージを受信すると、ステップ５１２に進む。
【００３３】
一方、この検査の結果、ステップ５０６で、ＸＣＡＰ ＵＲＩを参照して記述されたＸＭＬ文書が格納されている場合には、ＸＤＭＳは、ステップ５０８に進み、この要請者が対応するＸＭＬ文書を取り出す権限があるか否かを検査する。この際に、この権限の検査は、ステップ５０４のように、ＸＣＡＰ ＰＵＴ要請メッセージのヘッダーに含まれている要請者のＩＤに基づく。この要請者が対応するＸＭＬ文書を取り出す権限がある場合には、ＸＤＭＳは、ステップ５１０に進み、対応するＸＭＬ文書を取り出す。その後に、ＸＤＭＳは、ステップ５１２で、対応するＸＭＬ文書を要請ラインにより指定された位置に生成し、格納する。ＸＤＭＳは、ステップ５１４に進み、ＸＣＡＰ ＵＲＩを参照して記述された他のＸＭＬがあるか否かを検査する。この検査の結果、ステップ５１４で、ＸＣＡＰ ＵＲＩを参照して記述された他のＸＭＬがある場合には、ＸＤＭＳは、ステップ５０６に進み、ＸＭＬ文書に関する要請された機能を実行する。他方、ステップ５１４で、ＸＣＡＰ ＵＲＩを参照して記述されたＸＭＬ文書がこれ以上ない場合には、ＸＤＭＳは、ステップ５１６に進み、ＸＤＭＣ（すなわち、要請者）に実行の結果を送信する。
【００３４】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【図１】
2010500685.tif 000009
【図２】
2010500685.tif 000010
【図３】
2010500685.tif 000011
【図４】
2010500685.tif 000012
【図５】
2010500685.tif 000013
【国際調査報告】
2010500685.tif 000014
2010500685.tif 000015