(57)【要約】  [ＸＤＭ２_ＲＤ]及び[ＸＤＭ２_ＡＤ]に記録されたＸＤＭフォワード機能を実現するためのシステム及び方法を提供する。ＸＤＭフォワード要求者がＸＭＬ文書をＸＤＭフォワード受信者にフォワードするためのフォワード要求メッセージをＸＤＭＳに伝送し、ＸＤＭＳはフォワード要求メッセージを受信すると、要求されたＸＭＬ文書に対してフォワード権限があるか否かを確認し、あればＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングし、ＸＤＭＳはフォワードされたＸＭＬ文書を受信すると、ＸＤＭフォワード受信者がＸＭＬ文書を収容するかに対して受信者権限を確認した後に、収容を希望すると、ＸＭＬ文書をＸＤＭＳ内のＸＤＭフォワード受信者のユーザーディレクトリに格納し、ＸＤＭフォワード受信者はＸＤＭＳから受信者権限を確認するための要求があると、ユーザーの応答によってＸＭＬ文書の収容に対する応答をＸＤＭＳに伝送する。
2010500686.tif 000002
【特許請求の範囲】
【請求項１】
ＸＤＭ(XML  Document Management)フォワード機能を遂行するためのＸＤＭシステムであって、
フォワードしようとするＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングするためのフォワード要求メッセージを伝送するＸＤＭフォワード要求者と、
前記フォワード要求メッセージを受信し、前記ＸＤＭフォワード要求者がフォワードを要求するターゲットＸＭＬ文書をフォワーディングする権限があるか否かを判定し、前記ＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更してフォワードしようとする場合に、前記ＸＤＭフォワード要求者がターゲットＸＭＬ文書を調整する権限があるか否かを判定した後、前記ＸＤＭフォワード要求者が前記ターゲットＸＭＬ文書に対してフォワード権限と変更権限を有すると、要求されるＸＭＬ文書又は前記ＸＭＬ文書のフィルタリング及び変更によって調整された部分を前記ＸＤＭフォワード受信者にフォワーディングし、前記ＸＤＭフォワード受信者が前記フォワーディングされたＸＭＬ文書又は調整された前記ＸＭＬ文書の内容を収容するか否かを判定する受信者権限の確認を遂行した後に、前記受信者権限の確認が成功的に遂行された場合に、前記ＸＤＭフォワード受信者は前記フォワーディングされたＸＭＬ文書又は調整された前記ＸＭＬ文書の内容を所有して前記ＸＤＭフォワード受信者のユーザーディレクトリに格納するＸＤＭＳ(XDM  Sever)と、
前記ＸＤＭＳが受信者権限の確認を要求する場合には、ユーザーの応答によって前記ＸＭＬ文書収容に対する応答を前記ＸＤＭＳに伝送する前記ＸＤＭフォワード受信者と、
を含んでなることを特徴とするシステム。
【請求項２】
前記ＸＤＭフォワード要求者は、前記フォワード要求メッセージに該当ＸＭＬ文書を調整してフォワーディングするための情報を含めて伝送し、
前記ＸＤＭＳは、前記ＸＭＬ文書を調整してフォワーディングするための情報を含むフォワード要求メッセージを受信した場合に、前記ＸＤＭフォワード要求者が該当ＸＭＬ文書に対して調整する権限があるか否かを判定し、前記ＸＤＭフォワード要求者が調整権限があると、該当ＸＭＬ文書に前記調整情報を適用させたＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングすることを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＸＭＬ文書を調整してフォワーディングするための情報は、
フォワード要求のための原本ＸＭＬ文書を変化せずに、フィルタリングされた部分のみをＸＭＬ文書のみに対してＸＤＭフォワーディングするために使用されるフィルタ規則であることを特徴とする請求項２に記載のシステム。
【請求項４】
前記ＸＤＭＳは、
受信されたフォワード要求メッセージがフィルタ規則を含む場合、前記フォワード権限を通じて要求されたＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングする際に前記フィルタ規則を適用させ、前記適用されたＸＭＬ文書をフォワーディングすることを特徴とする請求項３に記載のシステム。
【請求項５】
前記ＸＤＭＳは、
前記フォワーディングされたＸＭＬ文書を前記ＸＤＭフォワード受信者のユーザーディレクトリに格納した後に、フォワード遂行結果を前記ＸＤＭフォワード要求者に伝送することをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項６】
前記ＸＤＭＳは、
前記ＸＤＭフォワード受信者が同じドメイン内に存在しない場合に、前記ＸＤＭフォワード受信者に前記要求されたＸＭＬ文書をフォワーディングする際に、前記該当ＸＤＭフォワード受信者が含まれているドメインの同一のＡＵＩＤ(Application  Unique  ID)のＸＤＭＳに前記要求されたＸＭＬ文書をフォワーディングすることを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＸＤＭＳは、
フォワーディングされる前記ＸＭＬ文書が前記ＸＤＭフォワード受信者を含んでいるドメインのＸＤＭＳに伝達される場合に、前記ＸＤＭフォワード受信者が前記ＸＭＬ文書を収容するか否かを判定する受信者権限の確認を遂行し、前記受信者権限の確認が成功的に遂行されると、前記ＸＤＭフォワード受信者が前記フォワーディングされたＸＭＬ文書を所有して前記ＸＤＭフォワード受信者のユーザーディレクトリに格納することを特徴とする請求項１に記載のシステム。
【請求項８】
前記フォワード要求メッセージは、
フォワーディングするためのＸＭＬ文書に対応するＸＣＡＰ  ＵＲＩを含むことを特徴とする請求項１に記載のシステム。
【請求項９】
ＸＤＭフォワード要求者、ＸＤＭＳ、及びＸＤＭフォワード受信者を含んで構成されるＸＤＭシステムにおけるＸＤＭフォワード機能を実現する方法であって、
前記ＸＤＭフォワード要求者がフォワードしようとするＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングするためのフォワード要求メッセージを前記ＸＤＭＳに伝送するステップと、
前記ＸＤＭＳが前記フォワード要求メッセージを受信した場合に、前記ＸＤＭフォワード要求者がフォワードを要求したターゲットＸＭＬ文書に対してフォワード権限があるか否か、そして前記ＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更してフォワードしようとする場合に、前記ＸＤＭフォワード要求者がターゲットＸＭＬ文書を変更する権限があるか否かを確認し、前記ターゲットＸＭＬ文書に対してフォワード権限と変更権限があると、要求されたＸＭＬ文書又はその内容のフィルタリングと変更が適用されて調整された内容をＸＤＭフォワード受信者にフォワーディングし、前記ＸＤＭフォワード受信者が前記フォワードされたＸＭＬ文書又はその調整された内容を収容する否かに対して受信者権限を確認するステップと、
前記ＸＤＭフォワード受信者が前記ＸＤＭＳから受信者権限を確認するための要求がある場合に、ユーザーの応答によって前記ＸＭＬ文書の収容に対する応答をＸＤＭＳに伝送するステップと、
前記ＸＤＭＳが前記受信者権限確認を成功的に遂行した場合に、前記ＸＤＭフォワード受信者が前記フォワーディングされたＸＭＬ文書を所有してユーザーディレクトリに格納するステップと、
を有することを特徴とする方法。
【請求項１０】
前記ＸＤＭフォワード要求者が、前記フォワード要求メッセージに該当ＸＭＬ文書を調整してフォワーディングするための情報を含めて伝送することを特徴とする請求項９に記載の方法。
【請求項１１】
前記ＸＤＭＳは、前記ＸＭＬ文書を調整してフォワーディングするための情報が含まれたフォワード要求メッセージを受信した場合に、前記ＸＤＭフォワード要求者が該当ＸＭＬ文書に対して調整権限があるか否かを判定するステップと、
前記ＸＤＭフォワード要求者が調整権限があると、該当ＸＭＬ文書に前記調整情報を適用させたＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングするステップと、
をさらに有することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ＸＭＬ文書を調整してフォワードする情報は、
フォワードを要求するための原本ＸＭＬ文書を変更せずに、フィルタリングされた部分のみをＸＤＭフォワーディングするためのフィルタ規則であることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ＸＤＭＳは、受信されたフォワード要求メッセージにフィルタ規則が含まれている場合に、前記フォワード権限があって要求されたＸＭＬ文書をＸＤＭフォワード受信者にフォワーディングする際に、前記フィルタ規則を適用させてＸＭＬ文書をフォワーディングするステップをさらに有することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ＸＤＭＳは、前記フォワーディングされたＸＭＬ文書を前記ＸＤＭフォワード受信者のユーザーディレクトリに格納した後に、フォワード遂行結果を前記ＸＤＭフォワード要求者に伝送するステップをさらに有することを特徴とする請求項９に記載の方法。
【請求項１５】
前記ＸＤＭＳは、前記ＸＤＭフォワード受信者が同一のドメインに存在しない場合に、前記ＸＤＭフォワード受信者へのフォワーディングの際に、前記該当ＸＤＭフォワード受信者が含まれているドメインの同一のＡＵＩＤ(Application  Unique  ID）のＸＤＭＳに前記要求されたＸＭＬ文書をフォワーディングするステップをさらに有することを特徴とする請求項９に記載の方法。
【請求項１６】
前記ＸＤＭＳは、前記ＸＤＭフォワード受信者が前記フォワードされるＸＭＬ文書を含んでいるドメインのＸＤＭＳに伝達された場合に、前記ＸＤＭフォワード受信者が前記ＸＭＬ文書を収容するか否かに対して受信者権限を確認し、前記受信者権限確認が成功的に遂行されると、前記ＸＤＭフォワード受信者が前記フォワーディングされたＸＭＬ文書を所有して前記ＸＤＭフォワード受信者のユーザーディレクトリに格納するステップをさらに有することを特徴とする請求項９に記載の方法。
【請求項１７】
前記フォワード要求メッセージは、フォワーディングするためのＸＭＬ文書に対応するＸＣＡＰ  ＵＲＩを含むことを特徴とする請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＤＭ  ｖ２.０イネーブラ(enabler)の文書管理機能(document management function)のうち一つであるＸＤＭ(XML Document Management)フォワード機能(forward function)を実現するためのシステム及び方法に関するものである。
【背景技術】
【０００２】
ＸＤＭフォワード機能(forward  function)は、ＸＤＭ  ｖ２.０イネーブラの文書管理機能の一つであって、ＸＤＭ  ｖ２.０  ｒｅｑｕｉｒｅｍｅｎｔ[ＸＤＭ２_ＲＤ](参考文献：“OMA  XML  Document  Management  Requirements”,  Version 2.0，Open  Mobile  AllianceTM,  OMA-RD-XDM-V2_0、URL:http://www．openmobilealliance.org/)と、ＸＤＭ  ｖ２.０  ａｒｃｈｉｔｅｃｔｕｒｅ[ＸＤＭ２_ＡＤ](参考文献：“OMA  XML  Document  Management  Architecture”,  Version 2.0,  Open  Mobile  AllianceTM,  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  AllianceTM,  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”のＸＣＡＰ  ＵＲＩとして記録される。
【００４３】
【表１】
2010500686.tif 000003
【００４４】
まず、ＸＤＭフォワード機能の実現方法の中でＨＴＴＰ  ＰＯＳＴ要求を用いる方法について説明する。
【００４５】
本発明では、ＸＤＭフォワード機能がＨＴＴＰ  ＰＯＳＴ要求を用いて次のように実現され、ＸＤＭシステムは次のような４つの条件に従って処理することが提案される。
【００４６】
１．ＸＤＭフォワード要求の実現
本発明は、ＨＴＴＰ  ＰＯＳＴ要求に基づいてＸＤＭフォワード要求を次のように実現することを提案する。下記の＜表２＞は、ＸＤＭフォワード要求の実現に関する例を示す。
【００４７】
【表２】
2010500686.tif 000004
【００４８】
(１)要求ライン(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  AllianceTM，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)を指定する。下記の＜表３＞は、＜表２＞のＸＤＭフォワード要求に上記したフィルタ規則を追加させた例を示す。
【００６０】
【表３】
2010500686.tif 000005
【００６１】
上記＜表３＞のＸＤＭフォワード要求のコンテンツは、このＸＤＭフォワード要求のターゲットである
“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’フィルタ規則が共に適用される場合を示す。
【００６２】
ここで、これらフィルタ規則は、原本ＸＭＬ文書には全く影響せずに、ＸＤＭフォワードされる場合のみに適用されることに留意する。
【００６３】
【表４】
2010500686.tif 000006
【００６４】
【表５】
2010500686.tif 000007
【００６５】
２．実現されたＸＤＭフォワード要求の処理
実現されたＸＤＭフォワード要求は、図１及び図２の手順に従って処理される。すなわち、＜表３＞に示したように実現されたＸＤＭフォワード要求の場合は、次のように処理される。
【００６６】
(１）“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ドメインのＰｏＣ  ＸＤＭＳに＜表４＞の内容を伝達することは、ＨＴＴＰ  ＰＵＴ要求またはＸＤＭフォワード要求によって実現されることができる。次の＜表６＞及び＜表７＞は、それぞれＨＴＴＰ  ＰＵＴ要求またはＸＤＭフォワード要求によって伝達される方法の例を示す。＜表６＞は、ＨＴＴＰ  ＰＵＴ要求を用いて、ターゲットＸＭＬ文書又はフィルタリングされた部分をドメインの間で伝達する方法を示す。また、＜表７＞は、ＸＤＭフォワード要求を用いて、ターゲットＸＭＬ文書又はフィルタリングされた部分をドメインの間で伝達する方法を示す。
【００７９】
【表６】
2010500686.tif 000008
【００８０】
【表７】
2010500686.tif 000009
【００８１】
＜表６＞に示すＨＴＴＰ  ＰＵＴ要求を用いる方法において、ＰｏＣグループ文書の該当フィルタリングされた内容は、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  AllianceTM，OMA-TS-XDM_CORE-V2_0，URL:http://www.openmobilealliance.org/)によって記録されてＸＤＭＳに格納される。ＸＤＭフォワードが実際に発生する場合に、ＸＤＭＳは、ＸＤＭフォワード受信者に直接確認する代わりに、ＸＤＭフォワード受信者が予め記録されたアクセス許可規則によってＸＭＬ文書を収容するか否かを判定する。このとき、選択的に、ＸＤＭＳは、このプロアクティブ権限確認の結果をＸＤＭフォワード受信者に伝送し、それによって該当受信者にＸＤＭＳの内容が新たにＸＤＭフォワーディングされたことを知らせる。
【００８８】
以下、ＸＤＭフォワード機能を実現するための方法のうち、第２の方法であるＸＣＡＰ  ＧＥＴ要求を用いる方法について説明する。
本発明は、ＸＤＭフォワード要求を次のように実現し処理するために、ＸＣＡＰ  ＧＥＴ要求を用いるＸＤＭシステムを提案する。
ＸＣＡＰ  ＧＥＴ要求を用いて記録される内容は、上記のＸＤＭフォワード機能を実現する方法のうち第１の方法である“１.ＸＤＭフォワード要求の実現”に述べられたＨＴＴＰ  ＰＯＳＴ要求を用いて記録される場合と同一であり、記述方法において若干の差がある。
【００８９】
下記の＜表８＞は、＜表３＞に示したようにＨＴＴＰ  ＰＯＳＴ要求を用いてＸＤＭフォワード要求を実現した例をＸＣＡＰ  ＧＥＴ要求によって変更した例を示す。
【００９０】
【表８】
2010500686.tif 000010
【００９１】
上記の＜表８＞からわかるように、上記した“１．ＸＤＭフォワード要求の実現”でのＨＴＴＰ  ＰＯＳＴ要求を用いる方法と異なって、ＸＣＡＰ  ＧＥＴ要求を用いる方法は、ＸＤＭフォワードのターゲットＸＭＬ文書のＸＣＡＰ  ＵＲＩと、これが伝達されたＸＤＭフォワード受信者がコンテンツボディーにＸＭＬで記録されず、ＸＤＭフォワーディングされたターゲットＸＭＬ文書のＸＣＡＰ  ＵＲＩがＨＴＴＰ  ＧＥＴ要求の要求ラインに記録され、ＸＤＭフォワードが伝達されるユーザーは新たなＨＴＴＰヘッダー(本発明では、便宜上“X-XCAP-Forward-to”と称する)に記録される。しかしながら、ＸＤＭフォワード要求者のＩＤ及びＸＤＭフォワードフィルタは、“１．ＸＤＭフォワード要求の実現”に述べられたＨＴＴＰ  ＰＯＳＴ要求を用いる方法と同一の方法で記録される。すなわち、ＸＤＭフォワード要求者のＩＤは、“X-XCAP-Assserted-Identity”又は対応するＨＴＴＰヘッダーに記録され、ＸＤＭフォワードフィルタは、＜forward-filter-set＞をルート要素として有するＸＭＬを通じてコンテンツボディーに記録される。
【００９２】
ＸＣＡＰ  ＧＥＴ要求によって実現されたＸＤＭフォワード要求が受信されたＸＤＭＳは、X-XCAP-Foward-toヘッダーの存在を通じて、上記要求が一般のＸＣＡＰ  ＧＥＴ要求でなく、ＸＤＭフォワード要求であることを確認することができる。その後、ＨＴＴＰ  ＰＯＳＴ要求を用いて、ＸＤＭＳは、ＸＤＭフォワードを実現する方法(“２．実現されたＸＤＭフォワード要求の処理”、“３．ドメイン間でターゲットＸＭＬ文書又はフィルタリングされた内容を伝達する方法”、“４．受信者権限確認の実現”)と同一の処理を遂行する。
【００９３】
これから、ＸＤＭフォワード機能を実現する方法のうち、第３の方法であるＸＤＭフォワードのターゲットを直接含むＸＣＡＰ  ＰＵＴ要求を用いる方法について説明する。
本発明は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書又はその内容をＸＣＡＰ  ＰＵＴ要求に直接含めてＸＤＭフォワード機能を実現する方法を提案する。
この第３の方法において、ＸＤＭフォワード機能を実現する方法のうち、上記した第１及び第２の方法とは異なって、ターゲットＸＭＬ文書のＸＣＡＰ  ＵＲＩの代わりにターゲットＸＭＬ文書又はその変更された内容が、ＸＣＡＰ  ＰＵＴ要求内に直接に含まれる。したがって、ＸＤＭフォワード要求者がターゲットＸＭＬ文書を既に有していない場合には、該当ＸＭＬ文書をＸＣＡＰ  ＧＥＴ要求を通じて直接取り出さなければならない。その後、ＸＤＭフォワードする該当ＸＭＬ文書またはその内容は、ＸＣＡＰ  ＰＵＴ要求内に直接記録される。
【００９４】
この第３の実現方法では、ＸＤＭフォワード要求者によってＸＤＭフォワードされる内容が直接ＸＣＡＰ  ＰＵＴ要求に含まれるため、上記のＸＤＭフォワード機能の実現方法のうち第１及び第２の実現方法とは異なって、ＸＤＭフォワードフィルタを必要としない。
【００９５】
下記の＜表９＞は、ＸＤＭフォワード要求者が＜表１＞に示したＰｏＣグループ文書を取り出した後に、伝達される上記文書の希望する内容だけをＸＣＡＰ  ＰＵＴ要求に含めてＸＤＭフォワード機能を遂行する例を示す。ここで、伝送しようとする上記ＰｏＣグループ文書の内容は、＜表３＞の‘xyz’ＸＤＭフォワードフィルタを適用した内容と同一である。
【００９６】
【表９】
2010500686.tif 000011
【００９７】
上記の＜表９＞からわかるように、この実現方法では、伝達された内容が格納されるＸＤＭフォワード受信者のＸＤＭＳ内のユーザーディレクトリとそのファイル名を、ＸＣＡＰ  ＰＵＴ要求の要求ラインに直接指定する。このとき、どんなファイル名も使用可能である。ここで、ファイル名は、原本ＸＭＬ文書のファイル名にＸＤＭフォワード要求者のＩＤを加えて表現した。図１１に示すように、ＸＤＭフォワード機能を実現する方法のうち第１及び第２の実現方法とは異なって、ＸＣＡＰ  ＰＵＴを用いるＸＤＭフォワード要求は、ターゲットＸＭＬ文書またはその内容が格納されるＸＤＭＳに直接ルーティングされる。
【００９８】
また、ＸＣＡＰ  ＰＵＴ要求において、特定のＸＤＭフォワード受信者のユーザーディレクトリはＸＣＡＰ  ＰＵＴ要求の要求ラインに記録されなければならないため、ＸＤＭフォワード機能の実現方法のうち第１及び第２の方法と異なり、複数のユーザー又はグループにＸＤＭフォワードを遂行することが不可能である。
【００９９】
このように実現されたＸＤＭフォワード要求の一般的な処理は、図１１に示すようである。すなわち、ドメインＡのＸＤＭフォワード要求者１０は、ＸＤＭフォワードするＸＭＬ文書を有していない場合に、該当ＸＭＬ文書をドメインＡのＸＤＭＳ１２から取り出し、この文書に基づいてフォワードしようとする内容をＸＣＡＰ  ＰＵＴ要求のボディーに直接含め、フォワードされるドメインＢのＸＤＭＳ２０に直接伝達する。ドメインＢのＸＤＭＳ２０は、ＸＤＭフォワード受信者２２がフォワードされた内容を収容するか否かを判定し、そのフォワーディングされた内容をＸＤＭＳ２０に格納する。
【０１００】
第３の実現方法において、ＸＤＭフォワード要求者がＸＤＭＳを通じて該当内容を直接に取り出してＸＣＡＰ  ＰＵＴ要求に含めるため、上記第１及び第２の実現方法とは違い、このユーザーに対する要求者権限の確認が難しい。これは、ＸＤＭフォワード要求者が、ＸＣＡＰ  ＧＥＴ要求を通じて該当ＸＭＬ文書を取り出す場合には、ユーザーがこのようなＸＭＬ文書を取り出すための権限のみを有しているか否かを確認するためである。したがって、このユーザーが該当ＸＭＬ文書を取り出した後にＸＤＭフォワードを遂行しても、これに対する管理、すなわちユーザーが該当ＸＭＬ文書をＸＤＭフォワードできるか否かを判定するための要求者権限確認を遂行することが不可能である。
【０１０１】
上述したように、このようなＸＣＡＰ  ＰＵＴ要求を用いるＸＤＭフォワード要求は、ターゲットが格納されるＸＤＭＳに直接伝達される。この要求は、コンテンツボディー内の内容を生成することを直接要求するため、ＸＤＭＳは、この要求を一般的なＸＣＡＰ  ＰＵＴ要求と同一に扱って処理する。したがって、この実現方法において、ＸＤＭフォワード要求に対する受信者権限の確認は、一般的なＸＣＡＰ  ＰＵＴ要求に対する受信者権限の確認と同様に適用される。
【０１０２】
最後に、ＸＤＭフォワード機能を実現する方法のうち第４の方法である、ＸＤＭフォワードのターゲットのＸＣＡＰ  ＵＲＩを含むＸＣＡＰ  ＰＵＴ要求を用いてＸＤＭフォワード要求を実現する方法について説明する。
【０１０３】
本発明は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ  ＵＲＩをＸＣＡＰ  ＰＵＴ要求に含めてＸＤＭフォワード機能を実現する方法を提案する。
このような第４の実現方法は、ＸＣＡＰ  ＰＵＴ要求を利用する点において、上記したＸＤＭフォワード機能を実現する方法のうち第３の方法と同一である。しかしながら、第４の実現方法は、ターゲットＸＭＬ文書の内容をＸＣＡＰ  ＰＵＴ要求に直接記録する代わりに、第１及び第２の実現方法と同様に、ＸＣＡＰ  ＵＲＩのみを記録して間接的にターゲットＸＭＬ文書を記録することに差がある。
【０１０４】
上記した第４の実現方法において、このＸＭＬ文書はＸＣＡＰ  ＵＲＩを用いて間接的に記録される。したがって、第４の実現方法においても、ＸＤＭフォワードフィルタは、第1及び第２の実現方法と同様にＸＤＭフォワードフィルタが記録されることができる。
【０１０５】
＜表１０＞、＜表１１＞、＜表１２＞は、上記のように実現されるＸＤＭフォワード要求の例を示す。
【０１０６】
【表１０】
2010500686.tif 000012
【０１０７】
【表１１】
2010500686.tif 000013
【０１０８】
【表１２】
2010500686.tif 000014
【０１０９】
＜表１０＞は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ  ＵＲＩを含むＸＣＡＰ  ＰＵＴ要求を用いてＸＤＭフォワード要求を実現した例を示す。＜表１１＞は、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ  ＵＲＩとこれに対するＸＤＭフォワードフィルタを含むＸＣＡＰ  ＰＵＴ要求を用いてＸＤＭフォワード要求を実現する例を示す。また、＜表１２＞は、ＸＤＭフォワード要求が、ＸＤＭフォワードのターゲットとなるＸＭＬ文書のＸＣＡＰ  ＵＲＩとこれに対するＸＤＭフォワードフィルタを含むＸＣＡＰ  ＰＵＴ要求を用いて実現される例と、新たなＨＴＴＰヘッダーを通じてＸＣＡＰ  ＵＲＩを記録する他の例とを示す。
【０１１０】
上記の＜表１０＞及び＜表１１＞において、[ＲＦＣ２０１７](参考文献：“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
１４      ＸＤＭフォワード受信者
【図１】
2010500686.tif 000015
【図２】
2010500686.tif 000016
【図３】
2010500686.tif 000017
【図４】
2010500686.tif 000018
【図５】
2010500686.tif 000019
【図６】
2010500686.tif 000020
【図７】
2010500686.tif 000021
【図８】
2010500686.tif 000022
【図９】
2010500686.tif 000023
【図１０】
2010500686.tif 000024
【図１１】
2010500686.tif 000025
【図１２】
2010500686.tif 000026
【国際調査報告】
2010500686.tif 000027
2010500686.tif 000028