JP5545953B2 - Ｘｍｌ文書管理サーバヒストリーを管理するためのシステム及び方法 - Google Patents

Description

本発明は、一般的なモバイルアプリケーション（Mobile Application）に関し、これは、アプリケーション特定（Application Specific）拡張可能マークアップ言語（Extensible markup language：以下、“ＸＭＬ”と称する。）文書が格納される拡張可能マークアップ言語文書管理（Extensible Markup Language (XML) Document Management：以下、“ＸＤＭ”と称する。）サーバに適用することができる。また、本発明は、サーバでＸＭＬ文書の管理に使用されるＸＭＬ設定アクセスプロトコル（XML Configuration Access Protocol：以下、“ＸＣＡＰ”と称する。）に関する。特に、本発明は、ＸＤＭサーバヒストリー格納改善のためのシステム及び方法に関する。

認証ポリシー（Authorization Policy）、コンタクトリスト（Contact List）、及びグループリスト（Group List）に関する様々な文書の格納のためのプッシュツートークオーバーセルラー（Push to Talk Over Cellular：以下、“ＰｏＣ”と称する。）及びインスタントメッセージング（Instant Messaging：以下、“ＩＭ”と称する。）ＸＤＭサーバのような様々なセッション開始プロトコル（Session Initiation Protocol：以下、“ＳＩＰ”と称する。）に基づく通信アプリケーションがある。このような種類の情報は、アプリケーション-特定ＸＤＭサーバに格納されている。共有情報は、共有ＸＤＭサーバに格納される。オープンモバイルアライアンス（Open Mobile Alliance：以下、“ＯＭＡ”と称する。）フォーラム（Forum）は、様々なモバイルアプリケーション、例えば、認証規則、コンタクト、及びグループコンタクト情報を格納するためのＩＭ ＸＤＭサーバ、プレゼンス（Presence）ＸＤＭサーバに対する効率的なＸＭＬ文書管理のためのＸＤＭプロトコルを標準化している。ＸＤＭサーバ（XDM Server：以下、“ＸＤＭＳ”と称する。）プロトコルは、ＸＭＬ文書に関する追加、生成、削除、及び修正動作を可能にする。

ＳＩＰに基づく通信アプリケーションの基本アーキテクチャを、図１に示す。このアーキテクチャを参照すると、ＸＤＭクライアントデバイス１１０及びアプリケーションサーバ１２０、例えば、ＩＭサーバ、プレゼンスサーバなどがある。ＳＩＰ-ＩＰコア１３０は、アプリケーションサーバ１２０とＸＤＭクライアントデバイス１１０との間に滞在する。アプリケーション特定ＸＤＭサーバは、アプリケーション特定情報（固定）をＸＭＬフォーマットに格納するのに使用される。ＸＣＡＰプロトコルは、このようなＸＭＬフォーマット情報を管理するのに使用される。ＸＤＭクライアントデバイス１１０は、ＸＣＡＰプロトコルを用いてアグリゲーションプロキシ（Aggregation proxy）１５０を介してＸＭＬ文書にアクセスするためのＸＤＭサーバクライアントを有する。これは、ＯＭＡフォーラムで定義されたようなＳＰＩに基づくアプリケーションに対する基本アーキテクチャである。

図２は、ＸＤＭサーバ１４０に格納されているＸＭＬ文書のＸＣＡＰ動作を実行するために使用された既存の様々なＸＣＡＰ手続きを示す。図２に示すように、クライアントがＸＤＭクライアントデバイス１１０からＸＭＬリソースの取得を希望する場合に、ＸＤＭクライアントデバイス１１０は、ＸＣＡＰ ＧＥＴ要請を、アグリゲーションプロキシ１５０を介してＸＤＭサーバ１４０に送信する。アグリゲーションプロキシ１５０は、ＸＤＭクライアントデバイス１１０を認証する（Ｓ２１０）。

ユーザーが既存のＸＭＬ文書を生成するか又はアップデートすることを希望する場合に、ユーザーは、ＸＣＡＰ ＰＵＴ動作を送信し、ＸＭＬコンデンツをＸＤＭサーバ１４０に対する要請のボディーに含ませる（Ｓ２２０）。

ユーザーがＸＭＬ文書又はＸＭＬ文書の一部の削除を希望する場合に、ユーザーは、ＸＭＬ削除要請をＸＤＭサーバ１４０に送信する（Ｓ２３０）。

また、ＸＣＡＰは、検索関連動作のためのＸＣＡＰ ＰＯＳＴ方法をサポートする。ユーザーが検索を希望する度に、ユーザーは、ＸＣＡＰ ＰＯＳＴ方法をアグリゲーションプロキシ１５０に送信した後に、アグリゲーションプロキシ１５０は、同一の要請を検索プロキシ２００に送信する。その後に、インターン（Intern）検索プロキシは、ＰＯＳＴ要請をＸＤＭサーバ１４０に送信し、この情報をＸＤＭサーバ１４０から読み出す（Retrieve）。検索プロキシ２００は、結果を集め、その検索結果をＸＤＭクライアントデバイス１１０に送信する（Ｓ２４０）。

ＯＭＡフォーラムは、ユーザーにより特定のＸＭＬ文書又はリソースに実行された動作に関するヒストリー情報の格納のための要件を提示した。ヒストリー格納の主な使用ケースは、委任動作（ＸＭＬ文書にエントリーの追加、エントリーのアップデート及び削除のようなＸＣＡＰ動作）から由来する。ユーザーは、特定のＸＭＬ文書に対する修正又はアクセスを他のユーザーに委任することができる。したがって、他のユーザーにより実行された動作をヒストリー情報として格納することは重要である。ユーザーは、ヒストリーの使用を可能にしなければならない。従来の要求事項は、ヒストリー情報の格納である。従来では、ユーザーは、“ヒストリーに何を格納するか”及び“ヒストリー情報をいつ格納するか”を選択することができない。ユーザーがヒストリー情報を選択的に格納することが好ましい。従来技術の様々な制約が次のセクションで論議され、また、このことより新たな改善のための動機が論議される。

従来技術において、動作のヒストリー格納に関する要求事項がある。ヒストリー情報は、ＸＤＭサーバに格納される。このヒストリー情報は、要請される際にユーザーにより検索されることができる。従来技術の場合には、ヒストリー情報動作のイネーブリング又はディスエーブリングだけが許容される。本発明は、このヒストリー格納のためのフィルタリング規則を備えることを提案する。これは、ユーザーがヒストリーに何を格納するか、そして、ヒストリー情報をいつ格納するかを定義することをサポートする。このような種類の情報は、ユーザーの観点で非常に有益である。従来技術の幾つかの短所は、次のようである。

１．ユーザーにより実行された動作が多い可能性があり、したがって、すべての情報を格納することがサーバの問題となることがあり、後で、ユーザーは、ヒストリー情報を取得するための大量の情報全体を取ってくる（fetch）必要があり得る。

２．すべてのヒストリー情報の格納を必要としないことがある。したがって、従来技術は、不必要な情報をヒストリー情報に格納する。

３．イベントに基づくヒストリー格納は、従来技術では不可能であり、“イベントに基づく”というのは、特定のイベントが発生する場合のみにヒストリー文書に格納することを意味する。これは、ユーザーがイベントの全セットの追跡でない特定のイベントの追跡を希望する多くの場合に助けとなりうる。これは、追跡の後に特定のイベントヒストリーの検索が容易であるために、イベントの追跡の際にユーザーに柔軟性を提供しうる。

４．従来のＸＤＭヒストリーにおいて、ユーザーは、時間に基づく格納を設定することができず、これは、ある日の特定の時間に文書に関する動作を行う文書の管理者が存在しない場合にさらに重要である。したがって、その時間の間に、文書の管理者は、動作の追跡を希望する。これは、ユーザーに非常に役に立つ。

したがって、本発明は、上述した従来技術の問題点を解決するために提案されたものであり、その目的は、ユーザーが任意の文書のヒストリーを設定することができるようにするヒストリー格納管理のための方法を提供することにある。

本発明の他の目的は、ＸＤＭＳでヒストリー格納要件を強化させることを提供することにある。

本発明のさらに他の目的は、ヒストリーに格納されている情報及びこのヒストリー情報をいつ格納するかを選択するフィルターを定義し（イベントに基づくヒストリー格納）、これを達成するフィルター規則を使用する方法を提供することにある。

本発明のさらなる他の目的は、ＸＤＭ動作のためのヒストリーイネーブリングシステム及び方法を提供することにある。

本発明のさらにまた他の目的は、具体的に、ヒストリーフィルター規則を設定するシステム及び方法を提供することにある。

本発明のさらなるその他の目的は、時間に基づくヒストリー格納のためのシステム及び方法を提供することにある。

上記のような目的を達成するために、本発明の実施形態の一態様によれば、ＸＤＭサーバ（ＸＭＬ文書管理サーバ）ヒストリーを管理するためのシステムを提供する。上記システムは、ＸＭＬ文書（拡張可能マークアップ言語文書）及び上記ＸＭＬ文書のヒストリー情報のフィルタリング規則を送信する第１のＸＤＭクライアントデバイスと、上記ＸＭＬ文書及び上記フィルタリング規則の受信及び格納を行うＸＤＭサーバと、上記ＸＤＭサーバに格納されているＸＭＬ文書にアクセスする第２のＸＤＭクライアントデバイスと、を有し、上記第２のＸＤＭクライアントデバイスが上記ＸＭＬ文書にアクセスする場合に、上記ＸＤＭサーバが上記フィルタリング規則によるヒストリー情報を格納することを特徴とする。

本発明によれば、ヒストリー格納及び管理を改善させることができる。ユーザーは、このヒストリー管理が容易に実行されるようにするイベントヒストリー格納を設定することができる。特に、ユーザーは、どの情報がヒストリーに格納され、いつ格納されるかを選択することができ、したがって、不必要なヒストリー情報の格納を防止することができ、ヒストリー管理が容易に実行されるようにする。また、ユーザーは、ヒストリー情報の検索及び読出しを容易に実行することができる。

一方、ユーザーは、このヒストリー管理が容易に実行されるようにするタイムに基づくヒストリー格納を設定することができる。

ＳＩＰに基づく通信アプリケーションの基本アーキテクチャを示す図である。 従来技術のＸＣＡＰ動作を示す図である。 ＸＣＡＰ ＰＵＴ方法を使用するヒストリー管理に対する論理フローを示す図である。 論理スキーマ構成を示す図である。 ＸＣＡＰ ＰＯＳＴに基づくソリューションに対する論理フローを示す図である。 ＳＩＰ ＳＵＢＳＣＲＩＢＥ方法を使用するヒストリー処理に対する論理フローを示す図である。

以下、本発明の好適な一実施形態を、添付図面を参照しつつ詳細に説明する。下記の説明において、明瞭性と簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。

従来技術で説明した現在のＸＤＭヒストリーメカニズムの制約を解決するために、本発明は、次の新たな要件を提示する。

１．ユーザーは、ヒストリー情報機能をイネーブルさせるか、又はディスエーブルさせることができる。

２．ユーザーは、どんな情報／動作がヒストリー情報として格納されるかを選択することができる。１つの例は、ＸＣＡＰ ＰＵＴ動作だけがヒストリー情報として格納されるものであり、ユーザーの観点でＸＣＡＰ ＰＵＴがＸＣＡＰ ＧＥＴよりはるかに重要な動作である。したがって、動作の全リストを格納する代わりに特定の動作のみに関するヒストリー情報を格納することができる。

３．ユーザーは、どのイベントの際に動作がヒストリー情報として格納されるかを選択することができる。１つの例は、委任された動作だけがヒストリー情報として格納されるものである。

４．ユーザーは、上記動作でのどんな情報がヒストリー情報として格納されるかを選択することができる。１つの例は、ＸＣＡＰ方法、動作要請者、及び動作での時間だけがヒストリー情報として格納されるものである。

５．グループ文書の場合に、グループは、あるユーザーにより生成されることができ、このようなユーザーは、そのグループの管理者と呼ぶ。ある管理者が幾つかの動作をそのユーザーに委任することができるが、特定のユーザーの追加のような重要な動作をログ（log）することが希望することができ、これにより、管理者は、後の時点にこのグループに追加された人が認識することができる。

６．また、ユーザーは、特定の文書に行われた動作に関するインスタント情報を取得するためにヒストリーのヒストリー文書変更を購読することができる。ここで、ユーザーは、誰かによりＸＣＡＰ ＰＵＴ動作が行われる際に通知するもののような選択された動作の通知を受けることができない。しかしながら、ユーザーがヒストリー格納にフィルターを適用すると、選択的な通知を受けることができる。これは、ユーザーにさらなる柔軟性を提供し、また、ユーザーがヒストリーの文書変更を購読した場合に不必要なヒストリー情報及び通知を避けることができる。

本発明は、ヒストリー管理のためのシステム及び方法を提供する。また、本発明は、このような改善のためのシステム及び方法を提供する。さらに、本発明は、ＸＤＭサーバ及びＸＤＭクライアントデバイスの追加的な動作を提案する。本発明は、ヒストリー格納のための新たなフィルターを定義する。このようなフィルターは、時間に基づくヒストリー格納を定義するのに役立つ。また、これは、何がヒストリー情報として格納されるかを定義する。

また、本発明は、ヒストリー格納機能のイネーブリング及びディスエーブリングを行う方法を提供する。

本発明は、ユーザーがヒストリー選好度を設定することができるようにする詳細な方法を提供する。基本的な提案は、ヒストリー格納をフィルタリングするためにユーザーにより設定される新たなフィルタリング規則を定義するのである。本発明は、ユーザーがヒストリー格納に幾つかの選好度を設定することができるようにＸＣＡＰ要請に新たなフィルターボディーを定義する。この新たな構成は、下記で説明する。ここでは、ヒストリー及びこれに関連した対応するフィルターを設定する基本方法を説明する。本発明では、ＸＣＡＰ ＰＵＴ方法がヒストリー機能を設定し、これに関連したフィルターを設定するために使用される。ＸＤＭクライアントデバイスは、ＸＣＡＰ ＰＵＴ要請を使用してＸＣＡＰ ＰＵＴのボディーにヒストリー設定を言及する。したがって、ＸＤＭサーバは、このような要請を受信した後に、フィルターによりこのヒストリー選好度をヒストリー文書に格納し、このヒストリー設定を適用し、他のユーザーにより実行された動作を格納する。

図３は、このような機能のための基本的な論理フローを示す図である。ＸＤＭクライアントデバイス１１１及び１１２とＸＤＭサーバ１４０との動作について説明する。

以下、ＸＤＭクライアントデバイス１１１及び１１２側の動作について説明する（Ｓ３１０）。図３に示すように、クライアントは、特定のリソース（すなわち、ＸＤＭＳ内のＸＭＬ文書）で行われた動作のヒストリー情報の格納のための要請を送信する。また、ユーザーは、どんな種類の情報がこのヒストリーに格納される必要があるか、そして、このヒストリー情報を何時格納するかに関するフィルター情報を追加することができる。ＸＤＭクライアントデバイス１１１がヒストリー情報の使用を可能にし、また、これに関するフィルター情報を設定すると、ＸＤＭサーバ１４０は、要請により確認されたその特定のリソースで実行された動作に関するヒストリー情報を格納する。このフィルターは、ユーザーが、どの動作及びこの動作のどの部分がヒストリー情報として格納されるかを設定することができるようにし、このヒストリー格納に対する時間周期を設定することができるようにする。また、ユーザーは、選択された動作に対するヒストリー格納を設定することもできる。このような動作に使用されるこの方法は、ＸＣＡＰ ＰＵＴである。本発明は、ＸＣＡＰ ＰＵＴ要請のボディー内のヒストリー制御情報のための新たなコンデンツタイプを定義する。したがって、ＸＤＭクライアントデバイス１１１は、適切なボディーを有するＸＣＡＰ ＰＵＴ要請を送信する。このボディーは、ヒストリー機能が使用可能となるリソースを確認する。また、このフィルターボディーは、本発明で提案した様々な改善をサポートするための様々なフィルタリング規則を定義するようにする。ＸＤＭクライアントデバイス１１１は、この要請を適切に生成し、ヒストリー規則をＸＤＭサーバ１４０に設定する。このような規則に従って、ＸＤＭサーバ１４０は、このヒストリー情報を格納する。

一方、ＸＤＭサーバ１４０側の動作を説明すると、次のようである（Ｓ３２０）。

ＸＤＭサーバ１４０がそのボディー内のヒストリーフィルター規則とともにヒストリー要請をＸＤＭクライアントデバイス１１１から受信する。ＸＤＭサーバ１４０は、このヒストリーフィルター規則を格納し、この要請に明示された目標リソースに対するヒストリー機能を使用可能にする。その後に、ＸＤＭサーバ１４０は、フィルター設定によりリソースに実行された動作のヒストリー情報の格納を開始する。

ＸＤＭサーバ１４０の詳細な動作は、次のようである。

・ＸＤＭサーバ１４０がＸＣＡＰ ＰＵＴ要請を受信すると、ＸＤＭサーバ１４０は、ボディーの妥当性をチェックする。このような妥当性のチェックは、特定された目標リソース又はＸＭＬ文書がＸＤＭサーバ１４０に存在するか否かに関するチェックを含む。

・妥当性チェックが成功裡に実行されると、ＸＤＭサーバ１４０は、ＸＣＡＰ ＰＵＴ要請のボディー内のヒストリー規則を要請ラインに特定されたユニフォームリソース識別子（Uniform Resource Identifier：以下、“ＵＲＩ”と称する。）位置に格納する。

・成功裡に処理されると、ＸＤＭサーバ１４０は、ＸＤＭクライアントデバイス１１１に応答を送信し、ヒストリー規則に従ってヒストリー機能をイネーブルする。

次の＜表１Ａ＞および＜表１Ｂ＞は、ヒストリーフィルターボディーの一例である。

図４は、スキーマ構成図を示し、＜表１Ａ＞および＜表１Ｂ＞は、詳細なヒストリーフィルタースキーマを示す。このスキーマは、ＸＣＡＰ ＰＵＴボディーに使用される。このスキーマは、ユーザーがヒストリー格納のイネーブリング／ディスエーブリングを行うことができるようにし、このヒストリー格納に関連したフィルター規則を設定することができるようにする。このスキーマは、“History”４００と呼ばれる１つのルート要素を定義する。“History”４００要素は、ヒストリーがイネーブルされるか又はディスエーブルされるかを示す“State”４１０と呼ばれる２個の属性とヒストリー機能のイネーブリング／ディスエーブリングが行われる目標ＸＭＬ文書を確認するＵＲＩを含む“Resource”４２０とを有する。例えば、ユーザーがコンタクトリストに実行された動作のヒストリーを有することを希望する場合に、“Resource”４２０は、このコンタクトリストのＵＲＩであろう。ルート要素内に定義された２個の要素があり、その１つは、ヒストリーのためのフィルター規則を定義する“FilterCond”４３０であり、他の１つは、動作（情報）のどの部分がヒストリー情報として格納されるかを示す“WhatSrore”４４０である。

“FilterCond”４３０要素は、ヒストリー情報を格納するための条件を定義する。これは、“OppType”４３４、“User”４３５、及び“TimeAttrib”４３６である３個の子要素を有する。“OppType”４３４要素は、どの動作がヒストリー要素として格納されなければならないかを定義するのに使用される。これは、ＡＤＤ、ＲＥＭＯＶＥ、ＲＥＰＬＡＣＥ、及びＮＥＷのような様々な値を取ることができる。“OppType”４３４は、ＡＤＤとして設定される場合には、すべての追加的な動作がヒストリー情報として格納される。“User”４３５要素は、特定されたユーザーがこの動作を要請する際にこれを特定するのに使用され、その後に、この動作がヒストリー情報として格納されるものである。“TimeAttrib”４３６は、この動作がヒストリー情報として格納されなければならない時間周期を特定するのに使用される要素である。“FilterCond”４３０は、３つの属性を有する。“CondID”４３１は、フィルター規則を確認するのに使用され、“Resource”４２０は、どのリソースについてこのようなフィルター規則が適用されるかを示し、“State”４１０は、特定のフィルター規則のアクティブ状態を示す。

“WhatStore”４４０は、ヒストリー文書にキャプチャー（Capture）される必要がある様々な値を定義するのに使用される。これは、“Include”４４１と呼ばれる１つの要素を有する。ユーザーは、“Include”４４１要素を用いてヒストリーストレージに格納されなければならない情報を示す。

以下、ＸＤＭクライアントデバイス側の処理規則について説明する。ＸＤＭクライアントデバイス１１０は、ヒストリー格納のイネーブリング及びディスエーブリングを行うためにＸＣＡＰ ＰＵＴ方法を使用する。ここで、ＸＤＭクライアントデバイス１１０は、本発明で定義されたスキーマを用いて様々なフィルタリング規則を定義するためのボディーを含む。ＸＤＭクライアントデバイス１１０は、“FilterCond”４３０を用いて様々な種類の条件を定義することができる。また、ＸＤＭクライアントデバイス１１０は、１つ以上の“FilterCond”４３０要素を含むことができる。他の“FilterCond”４３０要素の下で定義された規則は、論理的にＯＲであろう。

また、ＸＤＭクライアントデバイス１１０は、１つ以上の“Include”４４１要素を含むことにより“WhatStore”要素を用いてどんな情報がヒストリー文書に含まれなければならないかを示すことができる。例えば、ユーザーがヒストリー文書にユーザーの名前だけを追加することを希望する場合に、ユーザーは、“Include”４４１要素を“WhatStore”４４０要素に追加し、値を“User”４３５に設定する。

次の＜表２＞は、ヒストリーのイネーブリングの一例である。

＜表２＞は、ＸＤＭクライアントデバイス１１０がグループアドレスリストに関するＸＤＭヒストリーのイネーブリングを希望する場合のボディーを示す。ここで、ＸＤＭクライアントデバイス１１０は、ルート要素を含み、“State”４１０属性は、“ＯＮ”に設定される。また、ＸＤＭクライアントデバイス１１０は、“Resource”４３２属性の値をアドレスブックのＵＲＩとして設定する。このように、ＸＤＭクライアントデバイス１１０は、特定のリソースに対するヒストリーをイネーブルさせることができる。

次の＜表３＞は、ヒストリーのイネーブリング及びフィルター規則の設定を例示している。

＜表３＞において、ＸＤＭクライアントデバイス１１０は、“ＡＤＤ”動作だけをヒストリー情報としてＸＤＭサーバ１４０に格納することを指示するフィルター規則を設定する。

以下、ＸＤＭサーバ１４０側の処理規則について説明する。

ＸＤＭクライアントデバイス１１０がＸＣＡＰ ＰＵＴ要請を送信する場合に、ＸＤＭサーバ１４０は、コンデンツタイプをチェックし、コンテンツタイプが“application/vnd.OMA.history+xml”である場合に、ＸＤＭサーバ１４０は、これがヒストリー要請であることをわかる。したがって、ＸＤＭサーバ１４０は、フィルター規則の存在をチェックし、フィルター規則がすでにそこにある場合には、これは、このフィルター規則の変更に対する要請である。このフィルター規則が存在しない場合には、ＸＤＭサーバ１４０は、ＸＣＡＰ ＰＵＴ要請の要請ラインに特定された通りこの要請されたフィルター規則をＵＲＩで生成し格納する。その後に、ＸＤＭサーバ１４０は、その結果を応答として格納する。

ＸＤＭサーバ１４０は、このフィルターボディーを格納し、この要請に応じてヒストリー格納のイネーブリング／ディスエーブリングを行う。ＸＤＭサーバ１４０は、ヒストリーボディーを抽出し、このフィルターボディーの妥当性をチェックする。ＸＤＭサーバ１４０は、ルート要素ヒストリーの“State”４１０属性をチェックし、“State”４１０要素がＯＮである場合に、これは、ヒストリーがターンオンされることを意味する。他方、“State”４１０要素がＯＮではない場合に、これは、ヒストリーがターンオフされることを意味する。したがって、“State”４１０属性がヒストリー情報のイネーブリング又はディスエーブリングを行うのに使用される。ＸＤＭクライアントデバイス１１０は、ヒストリー情報を何時格納するかに対する条件を設定するための１つ以上のフィルター条件を含むことができる。“OppType”４３４が“ＡＤＤ”として設定される場合に、追加要請だけがＸＤＭヒストリーに記録される。同様に、“User”４３５要素が特定の名前に設定される場合に、そのユーザーにより実行された動作は、このヒストリー情報に格納される。同様に、“TimeAttrib”４３６がユーザーにより設定される場合に、ＸＤＭサーバ１４０は、ヒストリー情報を記録するためにこのような時間周期を使用する。ＸＤＭクライアントデバイス１１０は、多重フィルター条件を含むことができ、ＸＤＭサーバ１４０は、これら条件の論理的なＯＲを行う。また、ＸＤＭサーバ１４０は、何がヒストリー文書に格納されるかを示す“WhatStore”４４０要素を抽出する。

以下、ＸＣＡＰ ＰＯＳＴ要請に基づくヒストリー制御のための代案的なソリューションについて説明する。

本発明では、ヒストリー及びフィルター規則を設定するためのＸＣＡＰ ＰＯＳＴ要請を提案する。ここで、ＸＤＭクライアントデバイス１１０は、上記で言及した提案と同一のボディーを有するＸＣＡＰ ＰＯＳＴ要請を使用する。図５は、ヒストリー格納を設定するための基本的なフローを示す。

次の＜表４＞は、目標リソースに対してヒストリー機能をイネーブルさせるＸＤＭクライアントデバイス１１０からの要請メッセージを例示している（次の例は、ＰｏＣ ＸＤＭＳ内のＰｏＣグループ文書に対してヒストリー機能をイネーブルさせる。）。

この要請ラインは、ＸＤＭサーバ１４０に対するルーティング可能なＵＲＩ（これは、“http://xcap.example.com/org.openmobilealliance.poc”である。）及びヒストリー機能制御のためのサービスディレクトリ（これは、“/history”である。）を含む。

このボディーは、目標リソース及びヒストリー機能制御（すなわち、ＯＮ／ＯＦＦ）を含む。このボディーは、このＩＤＦにより提案されたように、フィルターのようなヒストリー機能制御をさらに含んでもよい。

このヒストリー機能がイネーブルされると、目標リソースに対する予め定義されたヒストリー文書、例えば、“_poc-groups.history.xml_”がヒストリー情報を格納するのに使用される。これは、ヒストリー格納のためのシステム-発生ユーザー文書（system-generated user document）である。

以下、ＳＩＰ ＳＵＢＳＣＲＩＢＥを使用する代案的な方法について説明する。

この方法では、ヒストリーを設定し、他のユーザーにより実行された動作に関する通知を得るＳＩＰ ＳＵＢＳＣＲＩＢＥ方法を提案する。このメカニズムにおいて、ユーザーは、ＸＤＭ-ヒストリーのようなイベントパッケージを有するＳＵＢＳＣＲＩＢＥボディーを送信する。この方法は、このヒストリー機能のイネーブリング又はディスエーブリングのために使用されることができるＸＤＭ-ヒストリーと呼ばれる新たなイベントパッケージを提案する。

この方法において、ユーザーがヒストリー機能のイネーブリングを希望する場合に、ユーザーは、ＸＤＭ-ヒストリーのようなイベントパッケージを有するＳＩＰ ＳＵＢＳＣＲＩＢＥ方法をＸＤＭサーバ１４０に送信する。ＸＤＭサーバ１４０がＸＤＭ-ヒストリー機能のようなイベントを有するＳＩＰ ＳＵＢＳＣＲＩＢＥを受信すると、ＸＤＭサーバ１４０は、ユーザーがこのヒストリー機能を要請しているものと見なす。

同一の要請において、ユーザーは、実行された動作に関する通知を要請することができることに留意すべきである。これは、満了フィールドを有するＳＵＢＳＣＲＩＢＥ要請をノンゼロ（nonzero）値として送信することにより行われることができる。したがって、ＸＤＭサーバ１４０は、幾つの動作がユーザーにより行われる際に通知も送信することができ、ＸＤＭサーバ１４０は、ヒストリー機能の対応する動作を格納する。

ユーザーが上記で定義されたヒストリーフィルタースキーマに基づくヒストリー機能を格納するためのフィルタリング規則の設定を希望する場合に、ユーザーは、このフィルタリングボディーをＳＩＰ ＳＵＢＳＣＲＩＢＥ ＢＯＤＹに含む。同一のボディーフォーマットは、上記で定義されたように使用されることができる。図６は、この方法に対する基本的な論理フローを示す。

ユーザーがヒストリー機能のイネーブリングを希望する場合には、ユーザーは、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要請を発生し、ヒストリー選好度に対するフィルターボディーを含み、要請-ＵＲＩを“Resource”４３２に設定する。ユーザーがキー動作に関する通知の受信を希望する場合に、ユーザーは、満了フィールド値をノンゼロとして入力する。ユーザーがヒストリー機能のイネーブリング又はディスエーブリングのみを希望する場合に、ユーザーは、ゼロである満了フィールドを入力する。

次の＜表５＞は、ヒストリー設定のためのＳＵＢＳＣＲＩＢＥを例示している。

＜表５＞は、ヒストリー機能を設定するためのＳＩＰ ＳＵＢＳＣＲＩＢＥ要請フォーマットを示す。ヒストリー機能のイネーブリングを希望するユーザーは、ＸＤＭ-ヒストリーのようなイベントを有するＳＵＢＳＣＲＩＢＥ要請を送信し、ヒストリー選好度を設定するための“application/vnd.oma.history+xml”を含む。このように、ユーザーは、ヒストリーを設定し、特定のリソースで実行された動作に関するインスタント通知を取得するためにヒストリーの通知を設定するためにＳＩＰ ＳＵＢＳＣＲＩＢＥ要請を使用することができる。

以下では、ＸＣＡＰ-ｄｉｆｆを用いてＳＩＰ ＳＵＢＳＣＲＩＢＥを使用する代案的な方法について説明する。

本発明において、この部分は、特定の動作のインスタント通知に関するヒストリー文書を購読することができる接近を説明する。この方法は、ヒストリー文書変更を購読するためにＸＣＡＰ-ｄｉｆｆイベントパッケージを使用する。また、本発明は、ＳＵＢＳＣＲＩＢＥ要請とともにヒストリーフィルタリング規則を設定するための幾つのヒストリーフィルターを含むことを提案する。

次の＜表６＞は、ヒストリー文書変更を購読し、このヒストリーフィルタリング規則を設定するためのＸＣＡＰ-ｄｉｆｆイベントパッケージを使用するＳＵＢＳＣＲＩＢＥ要請の例を示す。

上述した＜表６＞に示すように、これは、特定のリソースに対するヒストリーを設定するためにＸＣＡＰ-ｄｉｆｆ動作を使用する。これは、イベントパッケージを有するＳＵＢＳＣＲＩＢＥ要請をＸＣＡＰ-ｄｉｆｆとして送信し、コンデンツタイプのヒストリー設定を有するボディーを“application/vnd.oma.history+xml”として含む。

ＸＤＭクライアントデバイス１１０がコンタクトリストに対するヒストリーの設定を希望する場合に、ＸＤＭクライアントデバイス１１０は、パッケージ名前を有するＳＵＢＳＣＲＩＢＥ要請をＸＣＡＰ-ｄｉｆｆとして送信し、ヒストリー関連設定を含む。＜表６＞に示すように、この設定において、ユーザーは、ヒストリーがアクティブされる必要があるリソースを特定する。

ヒストリー情報のイネーブリング／ディスエーブリングを行うためのメカニズムに対する代案的な他のメカニズムは、ＳＩＰ ＭＥＳＳＡＧＥを使用してもよく、例えば、このヒストリー情報は、時間周期及びフィルターを有するＳＩＰ ＭＥＳＳＡＧＥ要請を用いたイネーブリング及び制御が可能である。

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

１１０，１１１，１１２ ＸＤＭクライアントデバイス
１４０ ＸＤＭサーバ

Claims (12)

1. ＸＤＭサーバ（ＸＭＬ文書管理サーバ）においてクライアントからの要求に基づくＸＭＬ文書に対するヒストリーを管理するための方法であって、
   前記ＸＭＤサーバが、第１のＸＤＭクライアントデバイスからＸＭＬ文書（拡張可能マークアップ言語文書）及び前記ＸＭＬ文書のヒストリー情報のフィルタリング規則が定義された適切なボディを有するＸＣＡＰ ＰＵＴ要請、ＸＣＡＰ ＰＯＳＴ要請、またはＳＩＰ ＳＵＢＳＣＲＩＢＥを受信するステップと、
   前記ＸＤＭサーバは、前記受信したＸＣＡＰ ＰＵＴ要請、ＸＣＡＰ ＰＯＳＴ要請、またはＳＩＰ ＳＵＢＳＣＲＩＢＥの前記ボディの妥当性をチェックし、該チェックに問題がなかった場合には、前記ＸＭＬ文書及び前記フィルタリング規則を格納し、前記フィルタリング規則に応じてヒストリー格納のイネーブリングを行うステップと、
   第２のＸＤＭクライアントデバイスが前記ＸＤＭサーバに格納されているＸＭＬ文書にアクセスすると、前記ＸＤＭサーバが前記フィルタリング規則に基づいて、前記ＸＭＬ文書に対して遂行された動作のヒストリー情報を格納するステップと、
   を含み、
   前記フィルタリング規則は、前記ヒストリー情報に格納される情報の種類及び前記ヒストリー情報が格納される時点を含み、
   前記ヒストリー情報は、前記ＸＭＬ文書にエントリーを追加するか、前記ＸＭＬ文書内のエントリーをアップデート又は削除することを示すことを特徴とするＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
2. 前記フィルタリング規則がイネーブルメント又はディスエーブルメントとなるように設定されることができることを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
3. 前記ＸＭＬ文書に対して遂行された動作は、前記第２のＸＤＭクライアントデバイスが前記ＸＤＭサーバに格納されているＸＭＬ文書の生成、アップデート、変更、削除、検索、及び読出しの中のいずれか１つの動作を実行することであることを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
4. 前記フィルタリング規則は、ＸＣＡＰプロトコルによるイベント及び時間に基づくヒストリー選好度であることを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
5. 前記フィルタリング規則は、前記ＸＤＭサーバに格納されているヒストリー情報を格納する期間を含むことを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
6. 前記フィルタリング規則によるヒストリー情報は、ＸＭＬの形態でＸＭＬリソースとして格納されることを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
7. 前記ＸＣＡＰ ＰＵＴ要請は、ヒストリー要請かどうかを知らせるコンテンツタイプを含むことを特徴とする請求項１に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
8. 前記ＸＤＭサーバが前記ＸＭＬ文書及び前記フィルタリング規則の受信及び格納を行うステップは、前記コンテンツタイプが前記ヒストリー要請を示す場合、前記ＸＭＬ文書及び前記フィルタリング規則を格納することを特徴とする請求項７に記載のＸＤＭサーバにおいてＸＭＬ文書に対するヒストリーを管理するための方法。
9. 第１のＸＤＭクライアントデバイスにおいてＸＤＭサーバ(ＸＭＬ文書管理サーバ）のヒストリーを管理するための方法であって、
   ＸＭＬ文書(拡張可能マークアップ言語文書)及び前記ＸＭＬ文書のヒストリー情報のフィルタリング規則が定義された適切なボディを有するＸＣＡＰ ＰＵＴ要請、ＸＣＡＰ ＰＯＳＴ要請、またはＳＩＰ ＳＵＢＳＣＲＩＢＥを生成し、前記ＸＤＭサーバに送信するステップと、
   第２のＸＤＭクライアントデバイスが前記ＸＤＭサーバに格納されたＸＭＬ文書にアクセスすると、前記ＸＤＭサーバが前記フィルタリング規則に基づいて、前記ＸＭＬ文書に対して遂行された動作のヒストリー情報を格納するステップと、
   を含み、
   前記フィルタリング規則は、前記ヒストリー情報に格納される情報の種類及び前記ヒストリー情報が格納される時点を含み、
   前記ヒストリー情報は、前記ＸＭＬ文書にエントリーを追加するか、前記ＸＭＬ文書内のエントリーをアップデート又は削除することを示すことを特徴とするＸＤＭサーバのヒストリーを管理するための方法。
10. 前記フィルタリング規則がイネーブルメントまたはディスエーブルメントとなるように設定されることができることを特徴とする請求項９に記載のＸＤＭサーバのヒストリーを管理するための方法。
11. 前記ＸＭＬ文書に対して遂行された動作は、前記第２のＸＤＭクライアントデバイスが前記ＸＤＭサーバに格納されているＸＭＬ文書の生成、アップデート、変更、削除、検索、及び読出しの中のいずれか１つの動作を実行したことであることを特徴とする請求項９に記載のＸＤＭサーバのヒストリーを管理するための方法。
12. 前記フィルタリング規則は、ＸＣＡＰプロトコルによるイベント及び時間に基づくヒストリー選好度であることを特徴とする請求項９に記載のＸＤＭサーバのヒストリーを管理するための方法。

Images