JP5213858B2 - 文書フォワーディングのためのｘｄｍシステム及び方法 - Google Patents

Description

本発明は、ＸＤＭ ｖ２.０イネーブラ(enabler)の文書管理機能(document management function)のうち一つであるＸＤＭ(XML Document Management)フォワード機能(forward function)を実現するためのシステム及び方法に関するものである。

ＸＤＭフォワード機能(forward function)は、ＸＤＭ ｖ２.０イネーブラの文書管理機能の一つであって、ＸＤＭ ｖ２.０ ｒｅｑｕｉｒｅｍｅｎｔ[ＸＤＭ２_ＲＤ](参考文献：“OMA XML Document Management Requirements”, Version 2.0，Open Mobile Alliance^TM, OMA-RD-XDM-V2_0、URL:http://www．openmobilealliance.org/)と、ＸＤＭ ｖ２.０ ａｒｃｈｉｔｅｃｔｕｒｅ[ＸＤＭ２_ＡＤ](参考文献：“OMA XML Document Management Architecture”, Version 2.0, Open Mobile Alliance^TM, OMA-AD-XDM-V2_0, URL:http://www.openmobilealliance.org/)とに記述されている。

ＸＤＭフォワード機能は、ユーザーがＸＤＭＳに格納されたＸＭＬ文書を他のユーザーにフォワードする文書管理機能(document management function)を意味する。このフォワーディングにおいて、ユーザーは、該当ＸＭＬ文書の全体をフォワードするか、あるいは該当ＸＭＬ文書の一部を選択的にフォワードし、またはその一部を変更(modify)してフォワードすることができる。このＸＭＬ文書を受信すると、ユーザーは、フォワードされたＸＭＬ文書を収容(acceptance)するか否かを決定する。ユーザーがこの文書を収容する場合に、フォワードされた文書は、このユーザーの所有となり、ＸＤＭＳ内の上記ユーザーのユーザーディレクトリ(user directory)に格納される。

一方、[ＸＤＭ２_ＲＤ]のＸＤＭフォワード機能に対する要求(requirement)要約技術には、上記したＸＤＭフォワード機能の要求に関して、次のように記録が含まれている。
１．適切な権限を有するユーザーは、他のユーザーにＸＭＬ文書をフォワードできる。
２．フォワーディング(forwarding）を要求するユーザーは、ターゲット(target)ＸＭＬ文書の原本に影響を与えないつつ、ターゲットＸＭＬ文書の内容を調整してフォワーディングできる。
３．フォワーディングされた文書を受信したユーザーは、このＸＭＬ文書を収容するか否かを決定できる。その結果、受信ユーザーがフォワーディングされたＸＭＬ文書を収容すると、該当部分は上記ユーザーの新たなＸＭＬ文書に生成されて格納される。

したがって、本発明は、[ＸＤＭ２_ＲＤ]及び[ＸＤＭ２_ＡＤ]に上述したように、ＸＤＭフォワード機能を実現するためのシステム及び方法を提供することをその目的とする。

上記の目的を達成するために、本発明の一態様によれば、ＸＤＭ(XML Document Management)フォワード機能を遂行するためのＸＤＭシステムであって、フォワードしようとするＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングするためのフォワード要求メッセージを伝送するＸＤＭフォワード要求者と、フォワード要求メッセージを受信し、ＸＤＭフォワード要求者がフォワードを要求するターゲットＸＭＬ文書をフォワーディングする権限があるか否かを判定し、ＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更してフォワードしようとする場合に、ＸＤＭフォワード要求者がターゲットＸＭＬ文書を調整する権限があるか否かを判定した後、ＸＤＭフォワード要求者がターゲットＸＭＬ文書に対してフォワード権限と変更権限を有すると、要求されるＸＭＬ文書又はＸＭＬ文書のフィルタリング及び変更によって調整された部分をＸＤＭフォワード受信者にフォワーディングし、ＸＤＭフォワード受信者がフォワーディングされたＸＭＬ文書又は調整されたＸＭＬ文書の内容を収容するか否かを判定する受信者権限の確認を遂行した後に、受信者権限の確認が成功的に遂行された場合に、ＸＤＭフォワード受信者はフォワーディングされたＸＭＬ文書又は調整されたＸＭＬ文書の内容を所有してＸＤＭフォワード受信者のユーザーディレクトリに格納するＸＤＭＳ(XDM Sever)と、ＸＤＭＳが受信者権限の確認を要求する場合には、ユーザーの応答によってＸＭＬ文書収容に対する応答をＸＤＭＳに伝送するＸＤＭフォワード受信者とを含んでなることを特徴とする。

本発明の他の態様によれば、ＸＤＭフォワード要求者、ＸＤＭＳ、及びＸＤＭフォワード受信者を含んで構成されるＸＤＭシステムにおけるＸＤＭフォワード機能を実現する方法であって、ＸＤＭフォワード要求者がフォワードしようとするＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングするためのフォワード要求メッセージをＸＤＭＳに伝送するステップと、ＸＤＭＳがフォワード要求メッセージを受信した場合に、ＸＤＭフォワード要求者がフォワードを要求したターゲットＸＭＬ文書に対してフォワード権限があるか否か、そしてＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更してフォワードしようとする場合に、ＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更する権限があるか否かを確認し、ターゲットＸＭＬ文書に対してフォワード権限と変更権限があると、要求されたＸＭＬ文書又はその内容のフィルタリングと変更が適用されて調整された内容をＸＤＭフォワード受信者にフォワーディングし、ＸＤＭフォワード受信者がフォワードされたＸＭＬ文書又はその調整された内容を収容する否かに対して受信者権限を確認するステップと、ＸＤＭフォワード受信者がＸＤＭＳから受信者権限を確認するための要求がある場合に、ユーザーの応答によってＸＭＬ文書の収容に対する応答をＸＤＭＳに伝送するステップと、ＸＤＭＳが受信者権限確認を成功的に遂行した場合に、ＸＤＭフォワード受信者がフォワーディングされたＸＭＬ文書を所有してユーザーディレクトリに格納するステップとを有することを特徴とする。

本発明で提案された方法によれば、ＸＤＭ Ｖ２.０サービスイネーブラ(service enabler）のＸＤＭフォワード機能を具体的に実現することができる。

本発明の実施形態により、単一ドメイン(single domain)でＸＤＭフォワード機能実現の構成及び各構成間のシグナリングフローを示す図である。 本発明の実施形態により、複数ドメイン(multiple domain)でＸＤＭフォワード機能実現の構成及び各構成間のシグナリングフローを示す図である。 本発明の実施形態により、ターゲットＸＭＬ文書がＸＤＭフォワード要求に直接挿入される場合のシグナリングフローを示す図である。 本発明の実施形態により、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩのみがＸＤＭフォワード要求に挿入されるこによって、間接的にターゲットＸＭＬ文書を記録する場合のシグナリングフローを示す図である。 本発明の実施形態により、フィルタ規則がＸＭＬ文書に適用される場合を示す概念図である。 本発明の実施形態により、ＸＤＭフォワード要求をルーティングする方法のうち、ＸＤＭフォワード要求がＸＤＭフォワード要求者のＸＤＭＳにまずルーティングされる方法を説明するための図である。 本発明の実施形態により、ＸＤＭフォワード要求をルーティングする方法のうち、 ＸＤＭフォワード要求がＸＤＭフォワード受信者のＸＤＭＳにまずルーティングされる方法を説明するための図である。 本発明の実施形態により、複数のユーザーに対するＸＤＭフォワードを説明するための図である。 本発明の実施形態により、グループに対するＸＤＭフォワードを説明するための図である。 ‘application/vnd.oma.foward+xml’のＸＭＬ構造の例を示す図である。 本発明の実施形態により、ＸＤＭフォワードターゲットを直接含むＸＣＡＰ ＰＵＴ要求を用いてＸＤＭフォワード機能を実現する場合の処理フローを示す図である。 本発明の実施形態により、ＸＤＭフォワードターゲットのＸＣＡＰ ＵＲＩを含むＸＣＡＰ ＰＵＴ要求を用いてＸＤＭフォワード機能を実現する場合の処理フローを示す図である。

以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
下記において、同一の構成要素に対しては異なる図面に表示されてもできるだけ同一の参照番号及び参照符号を付して説明する。また、本発明の説明において、関連した公知機能または構成に関する具体的な説明が本発明の要旨を不明にすると判断された場合に、その詳細な説明を省略する。

本発明では、[ＸＤＭ２_ＲＤ]及び[ＸＤＭ２_ＡＤ]に記録されたように、ＸＤＭフォワード機能を実現する方法がより具体的に提案される。このために、本発明は、ユーザーのＸＤＭフォワード機能を要求するＸＤＭＣ内のＸＤＭフォワード要求者(requestor)、要求されたＸＤＭフォワード機能を実行するＸＤＭＳ内のＸＤＭフォワード処理エンジン(forward processing engine)、及びユーザーが受信されたＸＭＬ文書を収容するか否かを決定するＸＤＭフォワード受信部(receiver)の機能(function)を定義し、これらの相互動作を説明する。

まず、本発明の実施形態によるＸＤＭフォワード機能実現の概要は、図１を参照して説明する。図１は、本発明によるＸＤＭフォワード機能実現の構成及び各構成間のシグナリング(signalling)フローを示す。このとき、図１は、該当ＸＭＬ文書を格納しているＸＤＭＳと該当ＸＭＬ文書が伝達されるＸＤＭフォワード受信者のＸＤＭＳが同一の単一ドメインに属する本発明の実施形態である。

まずは、ステップ１００で、ユーザー１０(機能的な構成(functional entity)から見れば、このユーザーによって要求されるＸＭＬ文書管理のために実際に使用されるＸＤＭＣ(XDM Client)であり、以下、便宜上“ＸＤＭフォワード要求者(XDM forward requesting user)”と称する)は、ＸＤＭＳ１２内の特定ＸＭＬ文書に対するフォワーディングを特定のユーザー１４(以下、便宜上“ＸＤＭフォワード受信者(forward receiving user)”と称する)に要求する。このとき、該当ＸＭＬ文書は、その全体、または一部、あるいは変更された部分がフォワーディングされることができる。このようなＸＤＭフォワード要求は、該当ＸＭＬ文書を格納しているＸＤＭＳ１２に伝達される。

ステップ１０２で、ＸＤＭフォワード要求(実際に、この要求は、ＸＤＭＳ内のＸＤＭフォワード処理エンジンで処理される)を受信したＸＤＭＳ１２は、ＸＤＭフォワード要求者１０が要求されたＸＭＬ文書に対してＸＤＭフォワード権限があるか否かを判定する。また、ＸＤＭフォワード要求者１０が該当ＸＭＬ文書を変更してＸＤＭフォワードしようとする場合に、ＸＤＭＳ１２は、ＸＤＭフォワード要求者１０が該当ＸＭＬ文書に対して変更権限があるか否かを判定する。本発明では、上記したような一連の権限確認過程は要求者権限確認(requestor authorization)と呼ばれる。このとき、ＸＤＭフォワード要求者は、該当ＸＭＬ文書の全体をフォワードする権限があれば、別途の要求者権限確認なしで、該当ＸＭＬ文書の一部のみをフォワードすること(以下、“フィルタ(filter)”と称する)ができる。これは、該当ＸＭＬ文書の内容全体をフォワードするか、あるいはその一部のみをフォワードするかの差異のみがあるためである。

その後、ＸＤＭＳ１２は、要求者権限の確認を成功的に遂行する。ステップ１０４で、上記要求が該当ＸＭＬ文書のフィルタまたは変更(modification）を含む場合に、ＸＤＭＳ１２は、これを該当ＸＭＬ文書に適用させてフォワードされる部分を調整(adjust)する。そうでないと、ＸＤＭＳ１２は、ステップ１０６に直ちに進行する。

ステップ１０６で、ＸＤＭＳ１２は、ＸＤＭフォワード受信者１４に該当ＸＭＬ文書をフォワードし、これは、該当ＸＭＬ文書をＸＤＭフォワード受信者のＸＤＭＳに伝達する過程である。該当ＸＭＬ文書のフィルタまたは変更が要求される場合、ＸＤＭＳは、これら要求によって調整されたＸＭＬ文書を伝送する。単一ドメインにおいて、単一ドメインで一つのＸＤＭＳが同一のＡＵＩＤ(Application Unique ID)を担当するため、単一ドメインの場合には、該当ＸＭＬ文書を格納しているＸＤＭＳは、該当ＸＭＬ文書が伝達されるＸＤＭフォワード受信者のＸＤＭＳと同一である。したがって、この過程は、同一ＸＤＭＳ内で該当ＸＭＬ文書をＸＤＭフォワード受信者のユーザーディレクトリに伝達するための過程である。しかしながら、ＸＤＭＳは機能的な構成であるため、一つのＸＤＭＳは、実際具現の際に、マルチプルインスタンス(multiple instance)によって実現されることもできる。この場合、フォワーディング過程は、同一のＡＵＩＤを担当する２つのＸＤＭＳインスタンス間の伝送過程もなり得る。

ステップ１０８で、該当ＸＭＬ文書が伝達されたＸＤＭＳ１２は、ＸＤＭフォワード受信者１４がこのＸＭＬ文書を受信できるか否かを判定する。本発明において、ＸＤＭフォワード受信者１４がこのＸＭＬ文書を受け入れるか否かを判定する過程は受信者権限確認(receiver authorization)と呼ばれる。このような受信者権限の確認を遂行する方法は、直接的な問い合わせなしにユーザーによってＸＤＭＳに定められているアクセス規則(access rule)に従ってＸＭＬ文書を収容するか否かを判定するためのプロアクティブ権限確認(proactive authorization)方法と、ＸＤＭフォワード受信者がＸＭＬ文書を収容するか否かをユーザーに直接問い合わせて確認するリアクティブ権限確認(reactive authorization）方法の２つの方法を含む。

ステップ１０８で受信者権限の確認が成功的に遂行すると、ＸＤＭＳ１２は、ステップ１１０で、フォワーディングされたＸＭＬ文書が該当ＸＤＭフォワード受信者の所有に属するので、このＸＭＬ文書をＸＤＭフォワード受信者のユーザーディレクトリに格納する。

ＸＤＭＳ１２は、ステップ１１２で、上記したＸＤＭフォワード要求に応じる実行結果をＸＤＭフォワード要求者に送る。

該当ＸＭＬ文書を格納しているＸＤＭＳと該当ＸＭＬ文書が伝達されるＸＤＭフォワード受信者１４のＸＤＭＳと同一でない複数ドメインである場合について、図２を参照して説明する。図２は、本発明で提案するＸＤＭフォワード機能実現の構成と各動作のシグナリングフローを示す。

まず、ＸＤＭフォワード要求者１０は、ステップ２００で、ＸＤＭＳ１２内に特定のＸＭＬ文書を特定のＸＤＭフォワード受信者２２にフォワーディングするように要求する。このとき、該当ＸＭＬ文書の全体、またはその一部、もしくは変更された部分がフォワードされることができる。このＸＤＭフォワード要求は、該当ＸＭＬ文書を格納するＸＤＭＳ１２に伝達される。

伝達されたＸＭＬ文書を有するＸＤＭＳ１２は、ステップ２０２で、 ＸＤＭフォワード要求者１０が要求されたＸＭＬ文書に対してＸＤＭフォワード権限を有しているか、そして該当ＸＭＬ文書を変更してフォワードしようとする場合にＸＤＭフォワード要求者１０が該当ＸＭＬ文書に対して変更権限を有しているかを確認するための要求者権限の確認を遂行する。これを成功的に確認した後に、ＸＤＭＳ１２は、ステップ２０４で、該当ＸＭＬ文書を該当ＸＭＬ文書のフィルタ又は変更によって調整する。その後、ステップ２０６で、要求されたＸＭＬ文書又はステップ２０４で調整されたＸＭＬ文書は、ドメインＢ(すなわち、他のドメイン)のＸＤＭＳ２０に伝送される。

ドメインＢのＸＤＭＳ２０は、ＸＭＬ文書が伝達された後に、ステップ２０８で、ＸＤＭフォワード受信者２２がフォワードされたＸＭＬ文書を収容できるか否かを判定するための受信者権限の確認を遂行する。受信者権限確認を成功的に遂行した後に、フォワーディングされたＸＭＬ文書は、ステップ２１０で、該当ＸＤＭフォワード受信者の所有とされ、ＸＤＭＳ２０はこのＸＭＬ文書を上記ユーザーのユーザーディレクトリに格納する。

ＸＤＭＳ２０は、ステップ２１２で、上記のようなＸＤＭフォワード要求に応じる実行結果をドメインＡのＸＤＭＳ１２を通じて、ＸＤＭフォワード要求者１０に送る。

また、複数ドメイン間のＸＤＭフォワード機能の基本的な手順は、図２で説明した単一ドメインインの場合と同様である。しかしながら、要求されたＸＭＬ文書が一つのドメインのＸＤＭＳから他のドメインのＸＤＭＳに伝達されることと、受信者権限の確認及びフォワードされたＸＭＬ文書の貯蔵は、ＸＤＭフォワード受信者が属するドメインのＸＤＭＳにより遂行されることとが異なる。

下記に、ＸＤＭフォワード機能を実現する場合に考慮すべき事項について説明する。まず、本発明で提案される実現は、上述した[ＸＤＭ２_ＲＤ]のＸＤＭフォワード機能に対する要求事項だけでなく、次のような４つの条件も満たすように考案された。

１．ＸＣＡＰ ＵＲＩを用いるターゲットＸＭＬ文書の表現
ＸＤＭフォワードのターゲットとなるＸＭＬ文書がＸＤＭフォワード要求に直接含まれる場合に、ＸＤＭフォワード要求者は、ＸＤＭフォワードを要求する前にＸＤＭＳからまず該当ＸＭＬ文書を取り出した(retrieve)後に、これをＸＤＭフォワード要求に含める。これについて、図３を参照して説明する。

ＸＤＭフォワード要求者１０は、ＸＤＭＳ１２にＸＣＡＰ ＧＥＴ要求メッセージを伝送することによってターゲットＸＭＬ文書を要求する。以後、ＸＤＭＳ１２は、２００ ＯＫメッセージを通じてターゲットＸＭＬ文書を伝送する。このターゲットＸＭＬ文書を受信した後に、ＸＤＭフォワード要求者１０は、ターゲットＸＭＬ文書を含むＸＤＭフォワード要求メッセージをＸＤＭＳ１２に伝送する。これを受信したＸＤＭＳ１２は、ＸＤＭフォワードの結果をＸＤＭフォワード要求者１０に伝送する。

図３からわかるように、このような過程は、ターゲットＸＭＬ文書がＸＤＭフォワード要求者１０とＸＤＭＳ１２との間で反復して交換されるシグナリングオーバーヘッド(signaling overhead)をもたらす。特に、ＸＤＭフォワード要求者のアクセスネットワークが無線である場合、このシグナリングオーバーヘッドは、アクセスチャンネルリソースの浪費と反応時間の遅延を招くことができる。このような問題を解決するために、本発明は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書がＸＤＭフォワード要求に直接に含まれずに、このＸＭＬ文書が格納されたＸＤＭＳの位置を記録するＸＣＡＰ ＵＲＩのみが含まれ、それによって該当ＸＭＬ文書がＸＤＭフォワード要求に間接的に記録できるＸＤＭフォワード機能を実現するための方法を提案する。このようにターゲットＸＭＬ文書がＸＤＭフォワード要求に直接含まれる代わりに、ターゲットＸＭＬ文書が格納されたＸＤＭＳの位置を記録するＸＣＡＰ ＵＲＩのみがＸＤＭフォワード要求に含まれ、それによって該当ＸＭＬ文書をＸＤＭフォワード要求に間接的に記録されることができる。ターゲットＸＭＬ文書の代わりにＸＣＡＰ ＵＲＩのみを含むＸＤＭフォワード要求メッセージを通じてフォワード機能を遂行する過程について、図４を参照して説明する。

まず、ＸＤＭフォワード要求者１０は、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩを含むＸＤＭフォワード要求メッセージをＸＤＭＳ１２に伝送する。このＸＤＭフォワード要求メッセージを受信した後に、ＸＤＭＳ１２は、ＸＣＡＰ ＵＲＩを通じてターゲットＸＭＬ文書を取り出してＸＤＭフォワード要求を遂行する。その後、ＸＤＭＳ１２は、ＸＤＭフォワード要求者１０にＸＤＭフォワードの結果を伝達する。

このターゲットＸＭＬ文書の間接技術は、ＸＤＭフォワード要求者とＸＤＭＳとの間のシグナリングオーバーヘッドを減少させる。したがって、図３と同様に、重複した情報の交換によるチャンネルリソースの浪費と反応時間の遅延を解決することができる。

２．ターゲットＸＭＬ文書にフィルタを適用
本発明では、ＸＤＭフォワード要求者がターゲットＸＭＬ文書の原本を変更させることなく、その一部だけをＸＤＭフォワードすることができる。このために、本発明は、フィルタを適用してＸＤＭフォワード要求者がターゲットＸＭＬ文書に対するフィルタ規則をＸＤＭフォワード要求に含めるようにする。このとき、ターゲットＸＭＬ文書の原本に影響を与えずにフォワードされるように、フィルタ規則によるターゲットＸＭＬ文書の一部のみにフィルタを適用することができる。図５は、ターゲットＸＭＬ文書に対するフィルタの適用を示す概念図である。図５を参照すると、原本ＸＭＬ文書５００は、フィルタ規則５０２を通じてフィルタリングされたＸＭＬ文書５０４に生成される。

３．ＸＤＭフォワード要求のルーティング(routing)方法
ＸＤＭフォワード要求をルーティングする方法は、ＸＤＭフォワード要求者のＸＤＭＳにＸＤＭフォワード要求をまずルーティングする方法と、ＸＤＭフォワード受信者のＸＤＭＳにＸＤＭフォワード要求をルーティングする方法との２つがある。これら２つの方法は、ＸＤＭフォワード要求者のドメインがＸＤＭフォワード受信者のドメインと相互に異なる場合に明らかな差を有し、これについては図６及び図７を参照して説明する。

第１に、ＸＤＭフォワード要求者のＸＤＭＳにＸＤＭフォワード要求をまずルーティングする方法について、図６を参照して説明する。
図６を参照すると、ドメインＡのＸＤＭフォワード要求者１０は、ＸＤＭフォワード要求メッセージを通じてＸＤＭフォワードを要求し、このＸＤＭフォワード要求は、上記ドメインＡと同一のドメインＡのＸＤＭＳ１２にまずルーティングされる。ＸＤＭＳ１２は、同一のドメインであるドメインＡのＸＤＭフォワード要求者の権利を確認した後に、ターゲットＸＭＬ文書又はフィルタ規則によって調整されたＸＭＬ文書の内容をＸＤＭフォワード受信者が存在するドメインＢのＸＤＭＳ２０に伝送する。ドメインＢのＸＤＭＳ２０は、同一のドメインであるドメインＢに存在するＸＤＭフォワード受信者２２を収容(acceptance)するか否かを判定してから受信された文書を格納する。

同一のドメイン内では情報の交換及び管理が容易である一方で、相互に異なるドメイン間の情報の交換及び管理は、ネットワーク間インターフェース(Network-to-Network Interface：ＮＮＩ)を通じてなされ、より複雑な手順を必要とする。この点を考慮すれば、図６に示す接近方法が効率的である。その理由は、図６の接近方法において、相互に異なるドメインで発生するオペレーション(operation）は、それらドメイン間のターゲットＸＭＬ文書またはそのフィルタリングされた内容を、権限確認(authorization)のような管理を必要とせずに、単純に交換だけをするためである。相互に異なるドメインの間で権限確認が必要ないことは、上記したように、要求者権限確認及び受信者権限確認がそれぞれの同一のドメイン内でユーザーとＸＤＭＳとの間でのみ遂行されるためである。

さらに、図６に示す接近方法において、ターゲットＸＭＬ文書が相互に異なるドメイン間で伝達される場合に、フィルタリングが適用されたＸＭＬ文書の内容のみが伝達されるため、ＸＤＭフォワード要求者によってフィルタリングされる内容は異なるドメインに伝達されることはない。したがって、図６に示す接近方法は、ＸＤＭフォワード要求者の情報に対するセキュリティ(security)維持の側面でも安全であるといえる。

第２に、ＸＤＭフォワード受信者のＸＤＭＳにＸＤＭフォワード要求をルーティングする方法について、図７を参照して説明する。
図７を参照すると、ドメインＡのＸＤＭフォワード要求者１０は、ＸＤＭフォワード要求メッセージを通じてＸＤＭフォワードを要求し、フォワーディングのターゲットが格納されるドメインＢのＸＤＭフォワード受信者２２のＸＤＭＳ２０にＸＤＭフォワード要求をルーティングする。ドメインＢのＸＤＭＳ２０は、該当ＸＭＬ文書が格納されているドメインＡのＸＤＭＳ１２に該当ＸＭＬ文書を要求する。その後、ドメインＡのＸＤＭＳ１２は、ＸＤＭフォワード要求者１０の権利が許可されたか否かを判定し、ドメインＢのＸＤＭＳ２０にターゲットＸＭＬ文書を伝送する。ＸＤＭフォワード要求がフィルタ規則を含む場合に、ドメインＢのＸＤＭＳ２０は、伝達されたＸＭＬ文書に上記フィルタ規則を適用させてその内容を調整し、ＸＤＭフォワード受信者が調整されたＸＭＬ文書を収容するか否かを判定した後にこれを格納する。

図７に示す方法は、ＸＤＭフォワード要求メッセージをＸＤＭＳに伝達する過程と、ターゲットＸＭＬ文書を取り出す過程とが、ＮＮＩインターフェースを通じて相互に異なるドメイン間で遂行されるので、図６に示した方法より効率が良くない。

また、図７に示す方法において、ＸＤＭフォワード要求と共にフィルタ規則が他のドメインに伝達され、そのドメインのＸＤＭＳ、すなわちドメインＢのＸＤＭＳが該当ＸＭＬ文書にフィルタ規則を直接適用する。したがって、ＸＤＭフォワード要求者によってフィルタリングされる希望する内容を含む該当ＸＭＬ文書の全体がドメインＢ、すなわち他のドメインに伝達されなければならないため、ＸＤＭフォワード要求者１０の情報に対するセキュリティ維持に問題となる可能性がある。
したがって、本発明は、図７の方法よりは図６の方法を優先してＸＤＭフォワード機能を実現することを提案する。

４．複数ユーザー又はグループへのＸＤＭフォワード
ＸＤＭフォワード機能は、図８及び図９に示すように、一つのＸＤＭフォワード要求を用いて複数のＸＤＭフォワード受信者又はグループのＸＤＭフォワード受信者に該当ＸＭＬ文書をＸＤＭフォワードできなければならない。図８を参照すると、ＸＤＭフォワード要求者１０は、複数のユーザーのためのＸＤＭフォワード要求メッセージをＸＤＭＳ１２に送る。このメッセージを受信したＸＤＭＳ１２は、該当するｎ人のＸＤＭフォワード受信者１４-１，１４-２，…，１４-ｎに対してＸＤＭフォワードを遂行する。また、図９に示すように、ＸＤＭフォワード要求者１０によってＸＤＭＳ１２にＸＭＬ文書のフォワードが要求される対象がグループである場合、すなわちグループに対するＸＤＭフォワード要求である場合に、ＸＤＭＳ１２は、グループＸＤＭＳ１３からこのグループの情報を取り出し、そのメンバー(member)に対するレゾリューション(resolution)を遂行し、それぞれのグループメンバー１５-１，１５-２，…，１５-ｎにＸＤＭフォワードを遂行する。

すると、本発明は、上記した[ＸＤＭ２_ＲＤ]のＸＤＭフォワード機能に対する要求と上記したＸＤＭフォワード機能の実現における４つの考慮事項に基づいて、ＸＤＭフォワード機能の具体的な実現方法を提案する。本発明では、４つのＸＤＭフォワード機能の具体的な実現方法を提案する。

まず、本発明で提案されるＸＤＭフォワード機能実現を説明するために、次の＜表１＞に示すＰｏＣグループ文書をＸＤＭフォワードの対象になるＸＭＬ文書の例として使用する。この例のようなＰｏＣグループ文書は、[ＰｏＣ_ＸＤＭ](参考文献:“PoC XDM Specification”，Version 1.0, Open Mobile Alliance^TM, OMA-TS-PoC_XDM-V1_0, URL:http://www.openmobilealliance.org/)に基づいて記述され、この文書の所有者は“sip:source_user＠example.com”であり、この文書のファイル名は“source-poc-group.xml”であると仮定する。また、このＰｏＣグループ文書は、現在“example.com”ドメインのＰｏＣ ＸＤＭＳ(そのＡＵＩＤは、org.openmobilealliance.pocである)内の“sip:source_user＠example.com”のユーザーディレクトリに格納されていると仮定する。したがって、このＰｏＣグループ文書のＸＤＭＳ内の位置は、
“http://xcap.example.com/org.openmobilealliance.poc/users/sip:source_user＠example.com/sorce-poc-group.xml”のＸＣＡＰ ＵＲＩとして記録される。

まず、ＸＤＭフォワード機能の実現方法の中でＨＴＴＰ ＰＯＳＴ要求を用いる方法について説明する。

本発明では、ＸＤＭフォワード機能がＨＴＴＰ ＰＯＳＴ要求を用いて次のように実現され、ＸＤＭシステムは次のような４つの条件に従って処理することが提案される。

１．ＸＤＭフォワード要求の実現
本発明は、ＨＴＴＰ ＰＯＳＴ要求に基づいてＸＤＭフォワード要求を次のように実現することを提案する。下記の＜表２＞は、ＸＤＭフォワード要求の実現に関する例を示す。

(１)要求ライン(Request line)
ＸＤＭフォワード要求を実現するＨＴＴＰ ＰＯＳＴ要求の要求ラインは、コンテンツボディー(content body)に記録されたＸＤＭフォワードを処理するＸＤＭＳと、そのＸＤＭＳ内にＸＤＭフォワード処理エンジン(processing engine）のＨＴＴＰ ＵＲＩを記録する。このとき、ＸＤＭフォワード要求がルーティングされるＸＤＭＳは、ＸＤＭフォワードのターゲットとなるＸＭＬ文書が格納されている所でなければならない。

＜表２＞の例において、要求ラインは
“http://xcap.example.com/org.openmobilealliance.poc/forward”である。これは、ＨＴＴＰ ＰＯＳＴ要求が、“example.com”ドメインの“org.openmobilealliance.poc”のＡＵＩＤを担当するＸＤＭＳ、すなわちＰｏＣ ＸＤＭＳにルーティングされ、上記ＰｏＣ ＸＤＭＳ内の“/forward”のＸＤＭフォワード処理エンジン(forward processing engine)で処理されることを意味する。コンテンツボディー(content body)に記録されたターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩは、
“http://xcap.example.com/org.openmobilealliance.poc/users/sip:
source_user＠example.com/source-poc-group.xml”であり、この文書が格納されたＸＤＭＳのアドレスは“http://xcap.example.com/org.openmobilealliance.poc”となる。したがって、この文書が格納されているＸＭＤＳのアドレスは、ＨＴＴＰ ＰＯＳＴ要求の要求ラインに記録されたＰｏＣ ＸＤＭＳのアドレスと同一であることがわかる。すなわち、このターゲットＸＭＬ文書は、ＰｏＣ ＸＤＭＳに格納されている。

（２)ＸＤＭフォワード要求者のＩＤ
このＸＤＭフォワードを要求するＸＤＭフォワード要求者は、“X-XCAP-Asserted-ID”[XDM_Core](参考文献：“XML Document Management(XDM) Specification”，Version 1.0，Open Mobile Alliance^TM，OMA-TS-XDM_CORE-V1_0，URL:http://www.openmobilealliance.org/)または対応するＨＴＴＰヘッダーに記録されることができる。＜表２＞の例では、ＸＤＭフォワード要求者が“sip:forwarder＠example.com”であることがわかる。

(３)ＸＤＭフォワードの内容
ＸＤＭフォワードの内容は、少なくとも次のような内容を記録しなければならない。
(a)ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ ＵＲＩ
(b)ＸＤＭフォワードされる内容が伝達されるＸＤＭフォワード受信者

このような内容は、ＸＭＬで表現されることができる。このとき、この表現のための新たなコンテンツタイプを定義することが必要である。本発明では、これを“application/vnd.oma.foward＋xml”であると仮定する。図１０は、ＸＤＭフォワードの内容が記録されるＸＭＬ構成の例を示す。

図１０を参照すると、ルート要素(root element)は、ＸＤＭフォワードのターゲットになるＸＭＬ文書のＸＣＡＰ ＵＲＩを記録する＜target＞、ＸＤＭフォワード受信者を記録する＜recipients＞、及びターゲットＸＭＬ文書に適用されるフィルタ規則(filter rule)を記録する＜forward-filter-set＞の子要素(child element)を含んでなる。ここで、＜target＞及び＜recipients＞は、基本的にＸＤＭフォワード内容を記録するため、必ず存在すべく、＜filter-rule-set＞は選択的に存在することができる。下記に、フィルタ規則についてより詳しく説明する。＜recipients＞において、それぞれのＸＤＭフォワード受信者は、子要素＜recipient＞によって記録される。したがって、複数個の＜recipient＞要素が存在できる。

＜表２＞は、‘application/vnd.oma.foward＋xml’コンテンツタイプのＸＤＭフォワード内容の例を示す。すなわち、＜target＞要素に記録されたターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩは、
“http://xcap.example.com/org.openmobilealliance.poc/users/sip:source_user＠example.com/source-poc-group.xml”である。このとき、＜target＞要素の‘auid’属性(attribute）は、そのＡＵＩＤを表し、ＸＭＬ文書の種類を提供する。また、＜recipients＞に記録されたＸＤＭフォワード受信者は、“sip:recipient_1＠example.com”、“sip:recipient_2＠example.com”、“sip:forward_group＠example.com”、及び“sip:user＠example2.com”である。

上記に考慮事項について説明したように、複数のＸＤＭフォワード受信者又はグループに対するＸＤＭフォワードが可能である。＜表２＞の例からわかるように、ターゲットＸＭＬ文書は、“example.com”ドメイン内の“sip:recipient_1＠example.com”、“sip:recipient_2＠example.com”のユーザーと“sip:forward_group＠example.com”のグループ、そして“example2.com”ドメイン内の“sip:user＠example2.com”にＸＤＭフォワードされる。

(４)ＸＤＭフォワードフィルタ
上述したように、ＸＤＭフォワード要求者は、フィルタを用いてターゲットＸＭＬ文書の内容のうち一部だけをＸＤＭフォワードすることができる。このために、フィルタ規則がＸＤＭフォワード要求に含まれることができる。このようなフィルタ規則は、少なくとも次のような内容を記録しなければならない。

(a)フィルタ規則が適用されるターゲットＸＭＬ文書
(b)フィルタ規則が適用される場合(例えば、ＸＭＬ文書が特定の受信者にＸＤＭフォワードされる場合のみにフィルタ規則を適用)
(c)フィルタされる内容の記録

このような内容は、ＸＭＬで表現され、ＸＤＭフォワード要求のコンテンツとして含まれることができる。図１０の例に示すように、“application/vnd.oma.foward＋xml”のコンテンツは、＜target＞に記録されたターゲットＸＭＬ文書に適用されたフィルタ規則を＜forward-filter-set＞に記録する。このような＜forward-filter-set＞は、複数の子要素＜forward-filter＞を有し、それぞれの子要素＜forward-filter＞は各フィルタ規則を記録する。＜forward-filter＞の‘id’属性は、フィルタ規則の識別(identification)を表し、‘recipient’属性は、記録されたフィルタ規則が適用される場合のＸＤＭフォワード受信者を表す。‘recipient’属性がない場合に、記録されたフィルタ規則は、すべてのＸＤＭフォワード受信者へのＸＤＭフォワードの際に適用される。

実際に、フィルタ規則を記録する方法は、２つの接近方法がある。その一つは、原本ＸＭＬ文書からフィルタアウト(filtered out)される部分のみを記録する方法であり、他の一つは、原本ＸＭＬ文書にフィルタリングされて含まれる部分のみを記録する方法である。これらは、＜forward-filter＞の子要素である＜exclude＞要素と＜include＞要素に記録される。この＜exclude＞要素には、ターゲットＸＭＬ文書からフィルタアウトされ、ＸＤＭフォワードの際に除外される部分の最上位要素のＸＰＡＴＨ Ｎｏｄｅ ＵＲＩ[ＸＣＡＰ](参考文献:“The Extensible Markup Language(XML) Configuration Access Protocol(XCAP)”，J.Rosenberg，May 5，2006，URL：http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt)が記録される。＜include＞要素には、ターゲットＸＭＬ文書にフィルタリングされてＸＤＭフォワードの際に含まれる部分のＸＰＡＴＨ Ｎｏｄｅ ＵＲＩを記録する。

＜ns-bindings＞要素は、ＸＰＡＴＨ ＵＲＩを記録する場合に使用される名前空間バインディング(namespace binding)を指定する。下記の＜表３＞は、＜表２＞のＸＤＭフォワード要求に上記したフィルタ規則を追加させた例を示す。

上記＜表３＞のＸＤＭフォワード要求のコンテンツは、このＸＤＭフォワード要求のターゲットである
“http://xcap.example.com/org.openmobilealliance.poc/users/sip:source_user＠example.com/source-poc-group.xml”のＸＣＡＰ ＵＲＩを有するＰｏＣグループ文書に適用される２つのフィルタ規則を示す。一つは、‘xyz’のidを有するフィルタ規則であり、他の一つは‘abc’のidを有するフィルタ規則である。‘xyz’フィルタ規則は、‘recipient’属性が存在しないため、ＸＤＭフォワードの際にすべてのＸＤＭフォワード受信者に適用され、それによってターゲットＰｏＣグループ文書から＜ruleset＞の内容をすべて除去する。‘abc’フィルタ規則は、“sip:recipient_2＠example.com”のユーザーにＸＤＭフォワードする際にのみ適用され、ＰｏＣグループリストから“sip:cherryblossom＠example.com”を記録する＜entry＞を除去できることを記録する。次の＜表４＞は、“sip:recipient_2＠example.com”の受信者を除いた残りの受信者に伝達されるターゲットＰｏＣグループ文書に‘xyz’フィルタ規則が適用される場合を示す。＜表５＞は、“sip:recipient_2＠example.com”の受信者に伝達されるターゲットＰｏＣグループ文書に‘xyz’フィルタ規則と‘abc’フィルタ規則が共に適用される場合を示す。

ここで、これらフィルタ規則は、原本ＸＭＬ文書には全く影響せずに、ＸＤＭフォワードされる場合のみに適用されることに留意する。

２．実現されたＸＤＭフォワード要求の処理
実現されたＸＤＭフォワード要求は、図１及び図２の手順に従って処理される。すなわち、＜表３＞に示したように実現されたＸＤＭフォワード要求の場合は、次のように処理される。

(１）“sip:forwarder＠example.com”のユーザーは、＜表３＞に示したＸＤＭフォワード要求を要求し、このＸＤＭフォワード要求はexample.comドメインのＰｏＣ ＸＤＭＳに伝達される。

(２）example.comドメインのＰｏＣ ＸＤＭＳは、“sip:forward＠example.com”のユーザーが“sip:source_user＠example.com”のユーザーの“source-poc-group.xml”をＸＤＭフォワードできる権限があるか否かを判定する。

(３）成功的な確認後、example.comドメインのＰｏＣ ＸＤＭＳは、“source-poc-group.xml”に‘xyz’フィルタ規則を適用させて＜表４＞の内容を生成する。また、ＰｏＣ ＸＤＭＳは、‘xyz’フィルタ規則及び‘abc’フィルタ規則を適用させて＜表５＞の内容を生成する。

(４）example.comドメインのＰｏＣ ＸＤＭＳは、“sip:forward_group＠example.com”が共有(shared)グループＵＲＩであることを認識し、example.comドメインの共有ＸＤＭＳからそのメンバーリストを取り出す。このとき、このグループのすべてのメンバーは、example.comドメインのユーザーであると仮定する。＜表４＞の内容は、メンバーリストのユーザーと“sip:recipient_1＠example.com”のユーザーのＰｏＣ ＸＤＭＳ内のユーザーディレクトリに伝達され、＜表５＞の内容は、“sip:recipient_2＠exmaple.com”のユーザーディレクトリに伝達される。

また、example.comドメインのＰｏＣ ＸＤＭＳは、“sip:user＠example2.com”のユーザーがexample2.comドメインに存在することを認知し、＜表４＞の内容をexample2.comドメインのＰｏＣ ＸＤＭＳに伝送する。example2.comドメインにおける処理は、下記のステップ(５-１)以後の処理に従う。

(５)example.comドメインのＰｏＣ ＸＤＭＳは、“sip:forward_group＠example.com”のメンバーユーザーと“sip:recipient_1＠example.com”のユーザーが＜表４＞の内容の受信を希望するか、そして“sip:recipient_2＠example.com”のユーザーは＜表５＞の内容の受信を希望するかを確認する。これは、ユーザーがexample.comドメインのＰｏＣ ＸＤＭＳに対して予め定められた規則によって確認するか、あるいは該当ユーザーに確認を直接要求することができる。

(６)成功的に確認を遂行した後に、example.comドメインのＰｏＣ ＸＤＭＳは、それぞれの受信された内容を各ユーザーのユーザーディレクトリに格納する。このとき、どんなファイル名(file name）でも使用可能である。ここでは、原本ＸＭＬ文書のファイル名にＸＤＭフォワード要求者のＩＤを加えてファイル名を表す。すなわち、ファイル名が、source-poc-group[forwarder＠example.com].xmlとして格納される。

(７)example.comドメインのＰｏＣ ＸＤＭＳは、ＸＤＭフォワード要求の遂行結果を“sip:forwarder＠example.com”に送る。

上記のステップ(４)に示した＜表４＞の内容が受信されたexample2.comドメインのＰｏＣ ＸＤＭＳは、次のサブステップに従って遂行される。

(５-１)example2.comドメインのＰｏＣ ＸＤＭＳは、“sip:user＠example2.com”のユーザーが＜表４＞の内容を受信しようとするか否かを確認する。

(６-１)成功的に確認した後に、example2.comドメインのＰｏＣ ＸＤＭＳは、＜表４＞の内容を“sip:user＠example2.com”のユーザーのユーザーディレクトリに格納する。

(７-１)example2.comドメインのＰｏＣ ＸＤＭＳは、ＸＤＭフォワード要求の遂行結果をexample.comドメインのＰｏＣ ＸＤＭＳに送る。

３．ドメイン間でターゲットＸＭＬ文書又はフィルタリングされた内容を伝達する方法
上記のステップ(４)で、example2.comドメインのＰｏＣ ＸＤＭＳに＜表４＞の内容を伝達することは、ＨＴＴＰ ＰＵＴ要求またはＸＤＭフォワード要求によって実現されることができる。次の＜表６＞及び＜表７＞は、それぞれＨＴＴＰ ＰＵＴ要求またはＸＤＭフォワード要求によって伝達される方法の例を示す。＜表６＞は、ＨＴＴＰ ＰＵＴ要求を用いて、ターゲットＸＭＬ文書又はフィルタリングされた部分をドメインの間で伝達する方法を示す。また、＜表７＞は、ＸＤＭフォワード要求を用いて、ターゲットＸＭＬ文書又はフィルタリングされた部分をドメインの間で伝達する方法を示す。

＜表６＞に示すＨＴＴＰ ＰＵＴ要求を用いる方法において、ＰｏＣグループ文書の該当フィルタリングされた内容は、example2.comドメインのＰｏＣ ＸＤＭＳ内の“sip:user＠example2.com”のユーザーのユーザーディレクトリに直接格納することが要求される。格納されるファイルは、どんなファイル名でも使用することができる。本発明においては、格納するファイル名と既存のファイル名との衝突を防止するために、原本ＸＭＬ文書のファイル名にＸＤＭフォワード要求者のＩＤを加えた、“source-poc-group[forward＠example.com]”を例として使用した。

＜表７＞に示すＸＤＭフォワード要求を用いる方法において、この要求が伝達されるexample2.comドメインのＰｏＣ ＸＤＭＳのＵＲＩ及びＸＤＭフォワード処理エンジンのＵＲＩは要求ラインに記録し、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩの代りにＸＭＬ文書のフィルタリングされた内容は＜target＞要素に直接記録される。したがって、＜forward-filter-set＞は、これ以上必要でない。この要求が伝達されるexmaple2.comドメインのＸＤＭフォワード受信者、すなわち“sip:user＠example2.com”のユーザーは、＜recipients＞に記録される。

このとき、２つの方法は、共にＸＤＭフォワード要求者の情報が“X-XCAP-Assserted-Identity”又はこれに対応するＨＴＴＰヘッダーを通じて必ず含まれることを要求する。これは、ＸＤＭフォワード要求者の要求は、他のドメインのＰｏＣ ＸＤＭＳの代わりにexample.comドメインのＰｏＣ ＸＤＭＳによって遂行され、このＸＤＭフォワード要求者の情報が受信者権限確認の根拠として使用するためである。

example2.comドメインのＰｏＣ ＸＤＭＳは、この要求を受信し、“sip:user＠example2.com”のユーザーが伝達されたＰｏＣグループ文書の内容に対して収容を希望するか否かを判定した後に、受信された内容を格納する。これは、既存の受信者権限確認の方法と同一である。

４．受信者権限確認の実現
上記ステップ(５)に説明したように、ＸＤＭフォワード受信者がＸＤＭフォワードされた内容を収容するか否かを確認する過程は、受信者権限確認と称する。この過程を遂行するために、プロアクティブ権限確認(proactive authorization）とリアクティブ権限確認(reactive authorization）との２つの方法を有する。

リアクティブ権限確認において、ＸＤＭＳは、ＸＤＭフォワードの発生時に該当内容を収容するか否かを判定するために、ＸＤＭフォワード受信者に直接確認する。

プロアクティブ権限確認において、ＸＤＭフォワード受信者がＸＤＭフォワードされた内容を収容するか否かに対するアクセス許可規則(access permission rule）は、[ＸＤＭ２_Ｃｏｒｅ](参考文献：“XML Document Management(XDM) Specification”，Version 2.0，Open Mobile Alliance^TM，OMA-TS-XDM_CORE-V2_0，URL:http://www.openmobilealliance.org/)によって記録されてＸＤＭＳに格納される。ＸＤＭフォワードが実際に発生する場合に、ＸＤＭＳは、ＸＤＭフォワード受信者に直接確認する代わりに、ＸＤＭフォワード受信者が予め記録されたアクセス許可規則によってＸＭＬ文書を収容するか否かを判定する。このとき、選択的に、ＸＤＭＳは、このプロアクティブ権限確認の結果をＸＤＭフォワード受信者に伝送し、それによって該当受信者にＸＤＭＳの内容が新たにＸＤＭフォワーディングされたことを知らせる。

以下、ＸＤＭフォワード機能を実現するための方法のうち、第２の方法であるＸＣＡＰ ＧＥＴ要求を用いる方法について説明する。
本発明は、ＸＤＭフォワード要求を次のように実現し処理するために、ＸＣＡＰ ＧＥＴ要求を用いるＸＤＭシステムを提案する。
ＸＣＡＰ ＧＥＴ要求を用いて記録される内容は、上記のＸＤＭフォワード機能を実現する方法のうち第１の方法である“１.ＸＤＭフォワード要求の実現”に述べられたＨＴＴＰ ＰＯＳＴ要求を用いて記録される場合と同一であり、記述方法において若干の差がある。

下記の＜表８＞は、＜表３＞に示したようにＨＴＴＰ ＰＯＳＴ要求を用いてＸＤＭフォワード要求を実現した例をＸＣＡＰ ＧＥＴ要求によって変更した例を示す。

上記の＜表８＞からわかるように、上記した“１．ＸＤＭフォワード要求の実現”でのＨＴＴＰ ＰＯＳＴ要求を用いる方法と異なって、ＸＣＡＰ ＧＥＴ要求を用いる方法は、ＸＤＭフォワードのターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩと、これが伝達されたＸＤＭフォワード受信者がコンテンツボディーにＸＭＬで記録されず、ＸＤＭフォワーディングされたターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩがＨＴＴＰ ＧＥＴ要求の要求ラインに記録され、ＸＤＭフォワードが伝達されるユーザーは新たなＨＴＴＰヘッダー(本発明では、便宜上“X-XCAP-Forward-to”と称する)に記録される。しかしながら、ＸＤＭフォワード要求者のＩＤ及びＸＤＭフォワードフィルタは、“１．ＸＤＭフォワード要求の実現”に述べられたＨＴＴＰ ＰＯＳＴ要求を用いる方法と同一の方法で記録される。すなわち、ＸＤＭフォワード要求者のＩＤは、“X-XCAP-Assserted-Identity”又は対応するＨＴＴＰヘッダーに記録され、ＸＤＭフォワードフィルタは、＜forward-filter-set＞をルート要素として有するＸＭＬを通じてコンテンツボディーに記録される。

ＸＣＡＰ ＧＥＴ要求によって実現されたＸＤＭフォワード要求が受信されたＸＤＭＳは、X-XCAP-Foward-toヘッダーの存在を通じて、上記要求が一般のＸＣＡＰ ＧＥＴ要求でなく、ＸＤＭフォワード要求であることを確認することができる。その後、ＨＴＴＰ ＰＯＳＴ要求を用いて、ＸＤＭＳは、ＸＤＭフォワードを実現する方法(“２．実現されたＸＤＭフォワード要求の処理”、“３．ドメイン間でターゲットＸＭＬ文書又はフィルタリングされた内容を伝達する方法”、“４．受信者権限確認の実現”)と同一の処理を遂行する。

これから、ＸＤＭフォワード機能を実現する方法のうち、第３の方法であるＸＤＭフォワードのターゲットを直接含むＸＣＡＰ ＰＵＴ要求を用いる方法について説明する。
本発明は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書又はその内容をＸＣＡＰ ＰＵＴ要求に直接含めてＸＤＭフォワード機能を実現する方法を提案する。
この第３の方法において、ＸＤＭフォワード機能を実現する方法のうち、上記した第１及び第２の方法とは異なって、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩの代わりにターゲットＸＭＬ文書又はその変更された内容が、ＸＣＡＰ ＰＵＴ要求内に直接に含まれる。したがって、ＸＤＭフォワード要求者がターゲットＸＭＬ文書を既に有していない場合には、該当ＸＭＬ文書をＸＣＡＰ ＧＥＴ要求を通じて直接取り出さなければならない。その後、ＸＤＭフォワードする該当ＸＭＬ文書またはその内容は、ＸＣＡＰ ＰＵＴ要求内に直接記録される。

この第３の実現方法では、ＸＤＭフォワード要求者によってＸＤＭフォワードされる内容が直接ＸＣＡＰ ＰＵＴ要求に含まれるため、上記のＸＤＭフォワード機能の実現方法のうち第１及び第２の実現方法とは異なって、ＸＤＭフォワードフィルタを必要としない。

下記の＜表９＞は、ＸＤＭフォワード要求者が＜表１＞に示したＰｏＣグループ文書を取り出した後に、伝達される上記文書の希望する内容だけをＸＣＡＰ ＰＵＴ要求に含めてＸＤＭフォワード機能を遂行する例を示す。ここで、伝送しようとする上記ＰｏＣグループ文書の内容は、＜表３＞の‘xyz’ＸＤＭフォワードフィルタを適用した内容と同一である。

上記の＜表９＞からわかるように、この実現方法では、伝達された内容が格納されるＸＤＭフォワード受信者のＸＤＭＳ内のユーザーディレクトリとそのファイル名を、ＸＣＡＰ ＰＵＴ要求の要求ラインに直接指定する。このとき、どんなファイル名も使用可能である。ここで、ファイル名は、原本ＸＭＬ文書のファイル名にＸＤＭフォワード要求者のＩＤを加えて表現した。図１１に示すように、ＸＤＭフォワード機能を実現する方法のうち第１及び第２の実現方法とは異なって、ＸＣＡＰ ＰＵＴを用いるＸＤＭフォワード要求は、ターゲットＸＭＬ文書またはその内容が格納されるＸＤＭＳに直接ルーティングされる。

また、ＸＣＡＰ ＰＵＴ要求において、特定のＸＤＭフォワード受信者のユーザーディレクトリはＸＣＡＰ ＰＵＴ要求の要求ラインに記録されなければならないため、ＸＤＭフォワード機能の実現方法のうち第１及び第２の方法と異なり、複数のユーザー又はグループにＸＤＭフォワードを遂行することが不可能である。

このように実現されたＸＤＭフォワード要求の一般的な処理は、図１１に示すようである。すなわち、ドメインＡのＸＤＭフォワード要求者１０は、ＸＤＭフォワードするＸＭＬ文書を有していない場合に、該当ＸＭＬ文書をドメインＡのＸＤＭＳ１２から取り出し、この文書に基づいてフォワードしようとする内容をＸＣＡＰ ＰＵＴ要求のボディーに直接含め、フォワードされるドメインＢのＸＤＭＳ２０に直接伝達する。ドメインＢのＸＤＭＳ２０は、ＸＤＭフォワード受信者２２がフォワードされた内容を収容するか否かを判定し、そのフォワーディングされた内容をＸＤＭＳ２０に格納する。

第３の実現方法において、ＸＤＭフォワード要求者がＸＤＭＳを通じて該当内容を直接に取り出してＸＣＡＰ ＰＵＴ要求に含めるため、上記第１及び第２の実現方法とは違い、このユーザーに対する要求者権限の確認が難しい。これは、ＸＤＭフォワード要求者が、ＸＣＡＰ ＧＥＴ要求を通じて該当ＸＭＬ文書を取り出す場合には、ユーザーがこのようなＸＭＬ文書を取り出すための権限のみを有しているか否かを確認するためである。したがって、このユーザーが該当ＸＭＬ文書を取り出した後にＸＤＭフォワードを遂行しても、これに対する管理、すなわちユーザーが該当ＸＭＬ文書をＸＤＭフォワードできるか否かを判定するための要求者権限確認を遂行することが不可能である。

上述したように、このようなＸＣＡＰ ＰＵＴ要求を用いるＸＤＭフォワード要求は、ターゲットが格納されるＸＤＭＳに直接伝達される。この要求は、コンテンツボディー内の内容を生成することを直接要求するため、ＸＤＭＳは、この要求を一般的なＸＣＡＰ ＰＵＴ要求と同一に扱って処理する。したがって、この実現方法において、ＸＤＭフォワード要求に対する受信者権限の確認は、一般的なＸＣＡＰ ＰＵＴ要求に対する受信者権限の確認と同様に適用される。

最後に、ＸＤＭフォワード機能を実現する方法のうち第４の方法である、ＸＤＭフォワードのターゲットのＸＣＡＰ ＵＲＩを含むＸＣＡＰ ＰＵＴ要求を用いてＸＤＭフォワード要求を実現する方法について説明する。

本発明は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ ＵＲＩをＸＣＡＰ ＰＵＴ要求に含めてＸＤＭフォワード機能を実現する方法を提案する。
このような第４の実現方法は、ＸＣＡＰ ＰＵＴ要求を利用する点において、上記したＸＤＭフォワード機能を実現する方法のうち第３の方法と同一である。しかしながら、第４の実現方法は、ターゲットＸＭＬ文書の内容をＸＣＡＰ ＰＵＴ要求に直接記録する代わりに、第１及び第２の実現方法と同様に、ＸＣＡＰ ＵＲＩのみを記録して間接的にターゲットＸＭＬ文書を記録することに差がある。

上記した第４の実現方法において、このＸＭＬ文書はＸＣＡＰ ＵＲＩを用いて間接的に記録される。したがって、第４の実現方法においても、ＸＤＭフォワードフィルタは、第1及び第２の実現方法と同様にＸＤＭフォワードフィルタが記録されることができる。

＜表１０＞、＜表１１＞、＜表１２＞は、上記のように実現されるＸＤＭフォワード要求の例を示す。

＜表１０＞は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ ＵＲＩを含むＸＣＡＰ ＰＵＴ要求を用いてＸＤＭフォワード要求を実現した例を示す。＜表１１＞は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ ＵＲＩとこれに対するＸＤＭフォワードフィルタを含むＸＣＡＰ ＰＵＴ要求を用いてＸＤＭフォワード要求を実現する例を示す。また、＜表１２＞は、ＸＤＭフォワード要求が、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ ＵＲＩとこれに対するＸＤＭフォワードフィルタを含むＸＣＡＰ ＰＵＴ要求を用いて実現される例と、新たなＨＴＴＰヘッダーを通じてＸＣＡＰ ＵＲＩを記録する他の例とを示す。

上記の＜表１０＞及び＜表１１＞において、[ＲＦＣ２０１７](参考文献：“Definition of the URL MIME External-Body Access-Type”，N.Freed，et.al.，RFC2017，October 1996，URL:http://www.ietf.org/rfc/rfc2017.txt）と[ＲＦＣ４４８３](参考文献:“A Mechanism for Content Indirection in Session Initiation Protocol(SIP Messages)”，E.Burger，Ed.，RFC4483，May 2006，URL:http://www.ietf.org/rfc/rfc4483.txt)とに定義された“message/external-body content type”を用いてＸＣＡＰ ＰＵＴ要求内にターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩを含む。そして、ターゲットＸＭＬ文書に対するＸＤＭフォワードフィルタは、＜表１１＞に示すように、“multipart/mixed”コンテンツタイプを用いて“message/external-body”コンテンツタイプと共に記録されることができる。

＜表１２＞に示すように、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩは、新たなＨＴＴＰヘッダー(本発明では、便宜上、“X-XCAP-Forward-Target”と称する)を用いて記録され、これに対するＸＤＭフォワードフィルタはＸＣＡＰ ＰＵＴ要求のボディーを用いて記録されることができる。

第４の実現方法において、上記したＸＤＭフォワード機能の実現方法のうち第３の実現方法と同一であり、ＸＣＡＰ ＰＵＴ要求の要求ラインには、伝達される内容が格納されるＸＤＭフォワード受信者のＸＤＭＳ内のユーザーディレクトリとそのファイル名を直接指定する。このとき、どんなファイル名も使用が可能である。ここで、ファイル名は、原本ＸＭＬ文書のファイル名にＸＤＭフォワード要求者のＩＤを加えて表現した。したがって、第３の実現方法と同様に、このＸＤＭフォワード要求は、ターゲットＸＭＬ文書またはその内容を格納するＸＤＭＳに直接ルーティングされる。

したがって、上記の第３の実現方法と同一に、ＸＣＡＰ ＰＵＴ要求は、特定のＸＤＭフォワード受信者のユーザーディレクトリをＸＣＡＰ ＰＵＴ要求の要求ラインに記録しなければならないため、第１及び第２の実現方法とは違い、複数のユーザーまたはグループへのＸＤＭフォワードは不可能である。

このように実現されたＸＤＭフォワード要求の一般的処理過程は、図１２のように示す。すなわち、ターゲットＸＭＬ文書のＸＣＡＰ ＵＲＩとＸＤＭフォワードフィルタを含むＸＣＡＰ ＰＵＴ要求によって実現されたＸＤＭフォワード要求は、ＸＤＭフォワードされる内容が格納されるＸＤＭＳであるドメインＢのＸＤＭＳ２０に直接伝達される。このＸＤＭＳ２０は、ＸＣＡＰ ＵＲＩを用いるＸＣＡＰ ＧＥＴ要求を通じてターゲットＸＭＬ文書をドメインＡのＸＤＭＳ１２から取り出し、ＸＤＭフォワードフィルタがある場合には、これを取り出されたＸＭＬ文書に適用させる。以後、ＸＤＭＳ２０は、ＸＤＭフォワード受信者２２がフィルタリングされたターゲットＸＭＬ文書の内容を収容するか否かを判定した後に、これをＸＤＭＳ２０に格納する。

このような実現方法は、図６及び図７を参照してＸＤＭフォワード要求のルーティング方法について説明したように、ＸＤＭフォワードフィルタ規則がＸＤＭフォワード受信者２２のＸＤＭＳ２０に直接伝送され、あるいはＸＤＭＳ２０がＸＤＭフォワード要求者のＸＤＭＳ１２からターゲットＸＭＬ文書を直接に取り出し、ＸＤＭフォワード要求者１０の情報セキュリティ維持の側面で問題となる可能性がある。

以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。

１０ ＸＤＭフォワード要求者
１２ XDMS
１４ ＸＤＭフォワード受信者

Claims (18)

1. 少なくとも一つのＸＭＬ（Extensible Markup Language）文書を管理するサーバーと
   、
   ＸＭＬ文書のフォワーディングを要求する少なくとも一つのクライアントと、を含んで
   構成されるＸＤＭ（ＸＭＬ Document Management）システムにおいて、前記サーバーが
   ＸＭＬ文書をフォワーディングする方法であって、
   第１クライアントから、特定のＸＭＬ文書に対するフォワーディングを要求するＸＤＭ
   フォワーディング要求メッセージを受信する過程と、
   前記ＸＤＭフォワーディング要求メッセージにより指示された前記特定のＸＭＬ文書の
   フォワードを受ける受信者クライアントが前記特定のＸＭＬ文書に対するフォワードを収
   容するか否かについて前記サーバーが確認する過程と、
   前記受信者クライアントが前記特定のＸＭＬ文書に対するフォワードを収容すると、前
   記特定のＸＭＬ文書を前記サーバー内の前記受信者クライアントの格納領域に格納して、
   前記特定のＸＭＬ文書をフォワーディングする過程と、を含み、
   前記ＸＤＭフォワーディング要求メッセージには、前記特定のＸＭＬ文書が格納された
   位置を記録するＵＲＩが含まれることを特徴とする方法。
2. 前記サーバーは、前記第１クライアントから前記ＸＤＭフォワーディング要求メッセー
   ジを受信すると、前記サーバーに予め登録された情報に従って、前記第１クライアントが
   前記特定のＸＭＬ文書に対するフォワード権限があるか否かを確認して、前記第１クライ
   アントが前記特定のＸＭＬ文書に対するフォワード権限があれば、前記特定のＸＭＬ文書
   を前記受信者クライアントにフォワーディングする
   ことを特徴とする請求項１に記載の方法。
3. 前記受信者クライアントが前記特定のＸＭＬ文書に対するフォワードを収容するか否か
   について前記サーバーが確認する過程は、前記受信者クライアントにより前記サーバーに
   予め記録されたアクセス許可規則を確認する過程である
   ことを特徴とする請求項１に記載の方法。
4. 前記ＸＤＭフォワード要求メッセージに前記特定のＸＭＬ文書のうちフォワーディング
   される一部部分を指定するフィルタ規則が含まれている場合、
   前記フィルタ規則に対応する前記特定のＸＭＬ文書の一部部分を前記受信者クライアン
   トの格納領域に格納する過程をさらに含む
   ことを特徴とする請求項１に記載の方法。
5. 前記ＸＤＭフォワーディング要求メッセージに前記特定のＸＭＬ文書に対する変更要求
   が含まれている場合、前記第１クライアントが前記特定のＸＭＬ文書に対する変更権限が
   あるか否かを確認する過程と、
   前記第１クライアントが前記特定のＸＭＬ文書に対する変更権限があれば、前記特定の
   ＸＭＬ文書を変更した後に前記受信者クライアントの格納領域に前記変更された特定のＸ
   ＭＬ文書を格納する過程と、をさらに含む
   ことを特徴とする請求項１に記載の方法。
6. 前記受信者クライアントが前記特定のＸＭＬ文書に対するフォワードを収容するか否か
   について前記サーバーが確認する過程は、
   前記受信者クライアントに前記特定のＸＭＬ文書に対するフォワードを収容するかを確
   認する段階と、
   前記受信者クライアントから前記特定のＸＭＬ文書に対するフォワードを収容するかに
   対する応答を受信する段階と、を含む
   ことを特徴とする請求項１に記載の方法。
7. 前記ＸＤＭフォワーディング要求メッセージに複数の受信者クライアントが指定されて
   いれば、該当受信者クライアントのそれぞれに前記特定のＸＭＬ文書をフォワーディング
   する
   ことを特徴とする請求項１に記載の方法。
8. 前記ＸＤＭフォワーディング要求メッセージは、前記特定のＸＭＬ文書の前記サーバー
   での格納位置を含んでいる
   ことを特徴とする請求項１に記載の方法。
9. 少なくとも一つのＸＭＬ（Extensible Markup Language）文書を管理するサーバーと
   、
   ＸＭＬ文書のフォワーディングを要求する少なくとも一つのクライアントと、を含んで構
   成されるＸＤＭ（ＸＭＬ Document Management）システムにおいて、前記クライアント
   がＸＤＭ文書をフォワーディングする方法であって、
   特定のＸＭＬ文書を少なくとも一つの受信者クライアントにフォワーディングすること
   を要求するＸＤＭフォワーディング要求メッセージを構成する過程と、
   前記フォワード要求メッセージを前記サーバーに伝送する過程と、を含み、
   前記ＸＤＭフォワーディング要求メッセージが伝送されることによって、前記クライア
   ントが前記特定のＸＭＬ文書に対するフォワード権限があり、前記受信者クライアントが
   前記特定の文書に対するフォワードを収容するか否かが前記サーバーにより確認されると
   、前記特定のＸＭＬ文書がサーバー内の前記受信者クライアントの格納領域に格納され、
   前記ＸＤＭフォワーディング要求メッセージには、前記特定のＸＭＬ文書が格納された
   位置を記録するＵＲＩが含まれることを特徴とする方法。
10. 前記ＸＤＭフォワーディング要求メッセージは、前記特定のＸＭＬ文書に対する変更要
    求を含む
    ことを特徴とする請求項９に記載の方法。
11. 前記ＸＤＭフォワーディング要求メッセージは、前記特定のＸＭＬ文書の前記ＸＤＭサ
    ーバーでの格納位置を含む
    ことを特徴とする請求項９に記載の方法。
12. 前記ＸＭＬフォワーディング要求メッセージは
    前記特定の原本ＸＭＬ文書を変更せずに、前記特定のＸＭＬ文書のうちフォワーディン
    グされる一部部分のみを指定するフィルタ規則を含む
    ことを特徴とする請求項９に記載の方法。
13. 前記特定のＸＭＬ文書が前記受信者クライアントの格納領域に格納された後、前記サー
    バーからフォワード遂行結果を受信する過程をさらに含む
    ことを特徴とする請求項９に記載の方法。
14. 少なくとも一つのＸＭＬ（Extensible Markup Language）文書を管理するサーバーと
    、ＸＭＬ文書のフォワーディングを要求する少なくとも一つのクライアントと、を含んで
    構成されるＸＤＭ（ＸＭＬ Document Management）システムにおいて、ＸＭＬ文書をフ
    ォワーディングするための前記サーバーであって、
    受信されたＸＭＬ文書を収容するか否かを決定するＸＤＭフォワード受信部と、
    第１クライアントから特定のＸＭＬ文書に対するフォワーディングを要求するＸＤＭフ
    ォワーディング要求メッセージを受信し、前記サーバーに予め登録された情報に従って、
    前記第１クライアントが前記特定のＸＭＬ文書に対するフォワード権限があるか否かを確
    認し、前記第１クライアントが前記特定のＸＭＬ文書に対するフォワード権限があれば、
    前記ＸＤＭフォワーディング要求メッセージにより指示された前記特定のＸＭＬ文書のフ
    ォワードを受ける受信者クライアントが前記特定のＸＭＬ文書に対するフォワードを収容
    するか否かについて確認し、前記受信者クライアントが前記特定のＸＭＬ文書に対するフ
    ォワードを収容すると、前記特定のＸＭＬ文書を前記サーバー内の前記受信者クライアン
    トの格納領域に格納して、前記特定のＸＭＬ文書をフォワーディングする処理エンジンと
    、を含み、
    前記ＸＤＭフォワーディング要求メッセージには、前記特定のＸＭＬ文書が格納された
    位置を記録するＵＲＩが含まれる
    ことを特徴とするサーバー。
15. 前記処理エンジンは、前記受信者クライアントが前記特定のＸＭＬ文書に対するフォワ
    ードを収容するか否かを確認するために、前記受信者クライアントにより予め記録された
    アクセス許可規則を確認する
    ことを特徴とする請求項１４に記載のサーバー。
16. 前記処理エンジンは、前記受信者クライアントが前記特定のＸＭＬ文書に対するフォワ
    ードを収容するかを確認するために、前記受信者クライアントに前記特定のＸＭＬ文書に
    対するフォワードを収容するか否かを確認し、前記受信者クライアントから前記特定のＸ
    ＭＬ文書に対するフォワードを収容するかに対する応答を受信する
    ことを特徴とする請求項１４に記載のサーバー。
17. 処理エンジンは、前記ＸＤＭフォワーディング要求メッセージに前記特定のＸＭＬ文書
    に対する変更要求が含まれていれば、前記第１クライアントが前記特定のＸＭＬ文書に対
    する変更権限があるか否かを確認し、前記第１クライアントが前記特定のＸＭＬ文書に対
    する変更権限があれば、前記特定のＸＭＬ文書を変更した後に前記受信者クライアントの
    格納領域に前記変更された特定のＸＭＬ文書を格納する
    ことを特徴とする請求項１４に記載のサーバー。
18. 前記処理エンジンは、前記ＸＤＭフォワーディング要求メッセージに前記特定のＸＭＬ
    文書中の一部をフォワーディングすることを要求するフィルタ規則が含まれていれば、前
    記フィルタ規則に対応する前記特定のＸＭＬ文書の一部を前記受信者クライアントの格納
    領域に格納する
    ことを特徴とする請求項１４に記載のサーバー。

Images