Notice: Undefined variable: fterm_desc_sub in /mnt/www/biblio_conv.php on line 353
相対的な条件評価を実現する方法、システム、サーバ、およびクライアント
説明

相対的な条件評価を実現する方法、システム、サーバ、およびクライアント

相対的な条件評価を実現する方法、システム、サーバ、およびクライアントが提供される。この方法は次のステップを含む。評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。従って、基準対象に関する情報が評価のための基礎として使用され、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、基準対象の状態に従って評価が実行される。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信の分野に関し、より詳しくは相対的な条件評価を実現する方法、システム、サーバ、およびクライアントに関する。
【0002】
本願は、2008年7月7日に出願され、発明の名称を「相対的な条件評価を実現する方法、システム、サーバ、およびクライアント」とする中国特許出願第200810130557.1号の優先権を主張し、その全体を引用してここに組み込む。
【背景技術】
【0003】
サービスを開始する前に、現在のサービスの受け手がそのサービスに参加するために適切であるか否かを知るために、ユーザまたはあるアプリケーションはサービスの受け手の現在の状態(status)を評価することができ、それによって、サービス開始の効率性を向上させ、通信リソースの浪費を防止する。条件を基にしたユニフォームリソース識別選択(Condition Based Uniform resource identification Selection(CBUS))サービスは、評価機能を提供することを目的とし、評価要求者の要望に従って相対的な評価条件を満たす対象を提供することができる。
【0004】
グループセッションを確立するサービスを一例にすると、グループセッションを確立する方法は次のステップを含む。サービスサーバは、グループセッション要求を受信し、そのグループセッション要求における情報に従ってグループメンバーのリストおよびセッション確立条件を取得する。サービスサーバは、グループメンバーのセッション確立条件に関する情報を取得し、取得した情報がセッション確立条件を満たすか否かを判定する。サービスサーバは、セッション確立条件を満たすグループメンバーのクライアントにグループセッション確立要求を発信し、グループセッションを確立する。先行技術における相対的な評価条件は次に表わされている通りである。
【0005】
< condition-set > “この要素は以下は評価条件であることを表わす”
< profile-condition > “この要素はユーザ基本情報に基づく評価条件を表わす”
< gender > female < / gender > “性別が女性であることを表わす”
< hobbies > football < / hobbies > “趣味がフットボールであることを表わす”
< / profile -condition >
< dynamiclnfo-condition > “以下は動的な情報に基づく評価条件であることを表わす”
< presence > “プレゼンス情報に基づく評価条件を表わす”
< mood > happy < / mood > “気分が満足であることを表わす”

< / presence >
< location > “位置情報に基づく評価条件を表わす”
< geography-location > shenzhen < / geography-location >
“地理的な位置がシンセンであることを表わす”
< /location >
< / condition-set >
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明の実現において、発明者らは、先行技術が少なくとも次の問題を有することを発見した。先行技術において、評価対象の情報のみが評価される、すなわち、評価要求者は評価対象のある状態が固定値を満たすことを指示することが必要である。評価要求者が固定値を指示しなかった場合、または、ある基準対象の状態に従って評価を実行することを意図する場合、または、相対的な評価条件が動的に変更される場合、先行技術においては評価が実現できない。
【課題を解決するための手段】
【0007】
本発明は、相対的な条件評価を実現する方法、システム、サーバ、およびクライアントを提供し、それによって、評価要求者が、評価対象のある状態が固定値を満たすことを指示しないとき、基準対象の状態に従って評価が実行されることが可能である。
【0008】
一実施形態において、本発明は、次のステップを含む相対的な条件評価を実現する方法を提供する。
評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【0009】
一実施形態において、本発明は、クライアントおよびサーバを含む相対的な条件評価を実現するシステムを提供する。
クライアントは、評価要求メッセージを送信し、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
サーバは、受信された評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果をクライアントに送信するように構成される。
【0010】
一実施形態において、本発明は、第2送信モジュールおよび第2受信モジュールを含むクライアントを提供する。
第2送信モジュールは評価要求メッセージをサーバに送信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
第2受信モジュールは、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。
【0011】
一実施形態において、本発明は、第1受信モジュール、条件取得モジュール、情報取得モジュール、および処理/送信モジュールを含むサーバを提供する。
第1受信モジュールは、評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。
条件取得モジュールは、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
情報取得モジュールは、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。
処理/送信モジュールは、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【0012】
本発明の実施形態において、相対的な評価条件が取得され、相対的な評価条件は基準対象を指示し、それによって、基準対象に関する情報が評価のための基礎として使用され、基準対象の状態に従って評価が実行される。
【図面の簡単な説明】
【0013】
【図1】本発明の第1実施形態による相対的な条件評価を実現する方法のフローチャートである。
【図2】本発明の第2実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図3】本発明の第3実施形態による相対的な条件評価を実現する方法の第1の場合のシグナリングフローチャートである。
【図4】本発明の第4実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図5】本発明の第5実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図6】本発明の第6実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図7】本発明の第7実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図8】本発明の第8実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図9】本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。
【図10】本発明の一実施形態によるクライアントの構成図である。
【図11】本発明の一実施形態によるサーバの構成図である。
【発明を実施するための形態】
【0014】
図1は、本発明の第1実施形態による相対的な条件評価を実現する方法のフローチャートである。図1を参照すると、本実施形態の方法は具体的には次のステップを含む。
ステップ101において、評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
ステップ102において、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
ステップ103において、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
ステップ104において、相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【0015】
さらに、ステップ101における相対的な条件評価に関する情報は相対的な評価条件とすることが可能であり、すなわち、相対的な評価条件は評価要求メッセージ内にカプセル化され、従って、ステップ102において、具体的には、評価要求メッセージが解析され、相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。
【0016】
ステップ101における相対的な条件評価に関する情報は参照パス情報とすることも可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ101の前に、相対的な評価条件が記憶位置において記憶される。ステップ102において、具体的には、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。具体的には、相対的な評価条件が予め定義されることが可能である。ユーザまたはアプリケーションは、特定の記憶位置、例えば、共有の拡張マークアップ言語データ管理サーバ(XDMS)またはCBUSサーバ内の記憶空間において予め定義された相対的な評価条件を記憶させる。このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは、相対的な評価条件の参照パスを指示する必要がある。
【0017】
本実施形態において、相対的な評価条件が取得され、相対的な評価条件は相対的な条件評価の基準対象を指示し、それによって、基準対象に関する情報が評価の基礎として使用され、基準対象の状態に従って相対的な条件評価が実行される。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶することが可能であり、相対的な評価条件は評価要求メッセージにおいて伝送することが可能であり、それによって、評価の効率性を向上させる。
【0018】
図2は、本発明の第2実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、CBUSサービスが例とされ、これに伴う装置は、CBUSクライアント、CBUSサーバ、および関係するサービスエンジンを含む。図2に表わされているように、本実施形態の方法は具体的には次のステップを含む。
【0019】
ステップ201において、CBUSクライアントは、評価要求メッセージをCBUSサーバに送信する。評価要求メッセージは、相対的な評価条件および相対的な評価条件において指示された基準対象を含み、さらに、評価対象および/または評価設定を含み、評価対象および評価設定はオプションの情報とすることが可能である。
【0020】
相対的な評価条件は、次の2つの例とすることが可能である。一例において、相対的な評価条件は相対的な条件のみを含み、他の例において、相対的な評価条件は相対的な条件と評価対象の条件の組み合わせを含む。さらに、CBUSサーバは、主に、位置情報、プレゼンス情報、および評価対象の共有XDMS内の情報に従って評価を実行し、それによって、相対的な評価条件は、3種類の情報のうち1つまたは複数に対応する部分によって表わすことが可能である。さらに、相対的な評価条件は、CBUSサーバが評価対象の情報を基準対象の情報と比較すべきであることを示し、従って、相対的な評価条件は基準対象を指示する。すなわち、基準対象は相対的な評価条件に含まれる。
【0021】
基準対象は、評価要求の発信者または評価要求の発信者によって指示された他のものとすることが可能である。基準対象の数は1つまたは複数とすることが可能である。評価手順の間、基準対象は固定され、または、変更されることが可能であり、例えば、CBUSサーバはCBUSクライアントの事前設定に従って異なる条件のもとで異なる基準対象を動的に選択する。
【0022】
評価対象は1人のユーザ、複数のユーザ(例えば、あるグループ)とし、または、単位としてグループ(すなわち、複数のグループ)を使用することが可能である。CBUSサービスはグループ選択機能をサポートし、評価要求者によって指示された複数のグループを評価し、相対的な評価条件を満たすグループを選択する
【0023】
評価設定は、主に、1回の評価、リアルタイムな評価、終了の評価(評価された対象が相対的な評価条件を満たすとき評価が終了する)、および他の形態を含む。さらに、CBUSは、CBUSクライアントが、自身の要求に従ってCBUSサーバによって返信された評価結果の数の上限および下限を設定することをサポートし、例えば、相対的な評価条件を満たす現在の評価対象の数が下限に到達していないならば、CBUSサーバは、その数が下限に到達するまで評価を実行し続け、評価結果を返信し、CBUSサーバによって返信される結果の数は上限を超えない。
【0024】
このステップにおいて、CBUSクライアントは、ポリシーの評価、実施、および管理(policy evaluation, enforcement and management(PEEM))の呼び出し可能インタフェース(以下、PEM−1と呼ぶ)によって評価要求メッセージをCBUSサーバに送信することが可能である。さらに、本実施形態において、CBUSクライアントとCBUSサーバの間の交信は、PEM−1インタフェースによって実現することが可能である。具体的には、PEEMは、運営者によって設定され、サービスプロバイダおよびアプリケーション開発者によって指示された、端末ユーザのプリファレンス設定におけるポリシーを評価、実施、および管理することによってリソースの保護および管理を実現するフレームワークであり、インタフェースPEM−1はポリシー評価のために定義される。PEM−1インタフェースによってPEEMからポリシー処理リソースが要求されるとき、各種リソースの差異のために該当するポリシーは異なり、それによって、PEM−1入力情報および出力情報は異なり、入力パラメータおよび出力パラメータも異なる。PEM−1は汎用インタフェースであり、異なるポリシーのために異なる独立のインタフェースを設定することは不可能であり、それによって、PEM−1テンプレートによって問題を解決することができ、すなわち、構造を要求および応答することが指定される。PEM−1テンプレートにおいて、ポリシーを処理するように構成されたどの入力PEM−1パラメータが評価要求者によって提供されるか、ポリシーが処理された後、どの出力PEM−1パラメータが評価要求者のために生成されるかが定義され、すなわち、基本入力および出力パラメータが定義され、具体的な要求に従ってパラメータが拡張されることがサポートされる。オプションで、本実施形態において、インタフェースは再利用することができ、CBUSクライアントとCBUSサーバの間の交信は、PEM−1インタフェースの入力および出力テンプレートパラメータを拡張することによって実現される。
【0025】
ステップ202において、CUBSサーバは、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得し、さらに、評価対象および評価設定を取得する。
【0026】
オプションで、ステップ201における評価要求メッセージは、参照パス情報を含むことが可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ201の前に、記憶位置において相対的な評価条件が記憶される。ステップ202において、具体的には、相対的な評価条件および相対的な評価条件において指示された基準対象が参照パス情報に対応する記憶位置から取得され、オプションで、評価対象および評価設定も取得することが可能である。具体的には、相対的な評価条件、評価対象、および/または、評価設定は予め定義することが可能であり、ユーザまたはアプリケーションは予め定義された相対的な評価条件、評価対象、および/または、評価設定を特定の記憶位置、例えば、共有XDMS、または、CBUSサーバ内の記憶空間に記憶させ、このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは参照パスのみ指示する必要がある。
【0027】
ステップ203において、CBUSサーバは評価対象に関する情報および基準対象に関する情報を取得し、これは具体的には次のステップを含む。
【0028】
ステップ2031において、CBUSサーバは、評価対象および基準対象に関する情報を取得する要求メッセージを(本実施形態において具体的にはサービスエンジンである)情報源に送信し、要求メッセージは評価要求の発信者の識別情報を伝送することが可能である。
【0029】
本発明の実施形態において、サービスエンジンは、限定しないが、位置エンジン、プレゼンスエンジン、および共有XDMSエンジンを含む。
【0030】
さらに、CBUSサーバは、相対的な評価条件に従って同一の情報源から評価対象および基準対象に関する情報を取得することが可能であり、または、異なる情報源から評価対象および基準対象に関する情報を取得することが可能である。
【0031】
ステップ2032において、サービスエンジンは、評価対象および基準対象に関する情報をCBUSサーバに返信する。
【0032】
ステップ2031とステップ2032の間に、サービスエンジンは、評価要求の発信者の識別情報に従って評価要求の発信者について識別情報の確認を実行する。具体的には、CBUSサーバによって送信された評価対象および基準対象に関する情報を取得する要求メッセージを受信するとき、サービスエンジン(例えば、プレゼンスエンジンまたは位置エンジン)は、(本実施形態においてCBUSクライアントである)評価要求の発信者を認証することが可能である。CBUSサーバがSIPプロトコルによってサービスエンジンとの交信を実現する、例えば、SIP subscribe/notifyメソッドによってプレゼンス情報を取得するならば、評価要求の発信者の識別情報を表わすIdentityおよびIdentity-Infoである2つのヘッダフィールドはサービスエンジンに送信される要求メッセージ内で伝送され、それによって評価要求の発信者の識別情報を示し、Identityフィールドは識別情報の確認の署名のために適合し、Identity-Infoは署名者の証明書の参照である。CBUSサーバが他のプロトコルによってサービスエンジンと交信を実現する、例えば、HTTPプロトコルによって位置エンジンと交信して位置情報を取得するならば、SIPプロトコルにおけるIdentityおよびIdentity-Infoと同じ機能を有するフィールドがそのプロトコルにおいて拡張され、それによって評価要求の発信者の識別情報を伝送する。評価要求の発信者の識別情報に従って、サービスエンジンは評価要求の発信者について識別情報の確認を実行する。
【0033】
ステップ204において、CBUSサーバは、相対的な評価条件および評価設定に従って評価対象に関する情報を基準対象に関する情報と比較し、それによって評価結果を取得する。
【0034】
ステップ205において、CBUSサーバは、評価結果をCBUSクライアントに返信する。
【0035】
本実施形態において、相対的な評価条件は相対的な条件を含む。相対的な評価条件が相対的な条件と評価対象の条件の組み合わせを含むならば、言い換えると、相対的な評価条件が第1の評価条件と第2の評価条件を含み、第1の評価条件は相対的な条件であり、第2の評価条件は評価対象の条件であり、評価対象の条件において、評価対象のある状態が固定値を満たすならばステップ204およびステップ205が具体的には次のステップを含むことが指示される。
【0036】
CBUSサーバは、相対的な条件に従って評価対象に関する情報を基準対象に関する情報と比較し、相対的な条件を満たす第1の評価対象を取得する。
【0037】
CBUSサーバは、(本実施形態において具体的にはサービスエンジンである)関係する情報源から第1の評価対象に関する情報を取得し、例えば、プレゼンスサーバから第1の評価対象のプレゼンス情報を取得する。
【0038】
CBUSサーバは第1の評価対象に関する情報を評価対象についての条件、すなわち、第2の評価条件と比較し、さらに、評価対象についての条件を満たす第2の評価対象を選択する。
【0039】
CBUSサーバは、第2の評価対象を評価結果としてCBUSクライアントに返信する。
【0040】
本実施形態において、評価対象についての条件、すなわち、第2の評価条件を満たす評価対象がまず選択されることが可能であり、そして、相対的な条件、すなわち、第1の評価条件を満たす評価対象がさらに選択される。言い換えると、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において2つの評価条件を評価するための順序は限定されない。
【0041】
本実施形態において、評価要求メッセージは、基準対象および相対的な評価条件を指示し、さらに、評価設定および評価対象を含む。サービスエンジンから取得された基準対象に関する情報は評価のための基礎として使用される。相対的な評価条件が相対的な条件であるとき、評価の要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、2つの条件を満たす評価対象は順に選択され、それによって、相対的な条件評価はより柔軟である。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶させることが可能であり、相対的な評価条件は評価要求メッセージ内で伝送されることが可能であり、それによって、評価の効率性を向上させる。
【0042】
ステップ201においてCBUSサーバによって受信される評価要求メッセージは評価対象を含まないという点で、本発明の第3実施形態による相対的な条件評価を実現する方法は第2実施形態と異なる。本実施形態の方法は次の例とすることが可能である。
【0043】
第1の例において、相対的な評価条件は相対的な条件のみを含み、基準対象に関する情報および検索される評価対象(すなわち、検索対象)に関する情報は、同一の情報源から取得される。具体的には、図3は、本発明の第3実施形態による相対的な条件評価を実現する方法の第1の場合のシグナリングフローチャートである。図3を参照すると、ステップ201はステップ201Aによって置き換えることが可能であり、CBUSクライアントは、相対的な評価条件を伝送する評価要求メッセージをCBUSサーバに送信し、ステップ203およびステップ204は次のステップによって置き換えることが可能である。
【0044】
ステップ203Aにおいて、CBUSサーバは、相対的な評価条件および基準対象を伝送する検索要求メッセージを(具体的にはサービスエンジンである)情報源に送信する。ステップ203Bにおいて、サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および相対的な評価条件に従って相対的な評価条件を満たす評価対象を検索する。ステップ203Cにおいて、相対的な評価条件を満たす評価対象がCBUSサーバに返信される。ステップ203Dにおいて、CBUSサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【0045】
第2の例において、相対的な評価条件が相対的な条件のみを含み、基準対象に関する情報および検索対象に関する情報が異なる情報源から取得されるならば、ステップ203およびステップ204は次のステップによって置き換えることが可能である。
【0046】
CBUSサーバは、基準対象に関する情報を第1の情報源から取得する。CBUSサーバは、相対的な評価条件および基準対象に関する情報を伝送する検索要求メッセージを第2の情報源に送信する。第2の情報源は、相対的な評価条件および基準対象に関する情報に従って相対的な評価条件を満たす評価対象を検索し、評価対象をCBUSサーバに返信する。CBUSサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【0047】
第3の例において、相対的な評価条件が相対的な条件(第1の評価条件)と評価対象の条件(第2の評価条件)の組み合わせであるならば、第2の評価条件において評価対象の条件が固定値を満たすことが指示され、基準対象に関する情報および検索対象に関する情報が同一の情報源から取得される。本実施形態において、相対的な条件を満たす評価対象はサービスエンジンから検索され、そして、サーバは、さらに、検索対象の条件を満たす評価結果を選択する。具体的には、ステップ203およびステップ204は次のステップによって置き換えることが可能である。
【0048】
CBUSサーバは、第1の評価条件および基準対象を伝送する検索要求メッセージを(具体的にはサービスエンジンである)情報源に送信する。サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および第1の評価条件に従って第1の評価条件を満たす第1の評価対象を検索する。CBUSサーバは、サービスエンジンによって返信された第1の評価条件を満たす第1の評価対象を受信する。CBUSサーバは、第1の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。CBUSサーバは、第1の評価対象に関する情報を第2の評価条件において指示された固定値と比較し、第2の評価条件を満たす第2の評価対象を評価結果として取得する。
【0049】
第3の例において、CBUSサーバは、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することも可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において2つの条件を評価するための順序は限定されない。
【0050】
第4の例において、相対的な評価条件が相対的な条件(第1の評価条件)と評価対象の条件(第2の評価条件)の組み合わせであり、基準対象に関する情報および評価対象に関する情報が異なる情報源から取得されるならば、ステップ203およびステップ204は次のステップによって置き換えることが可能である。
【0051】
CBUSサーバは、基準対象に関する情報を第1の情報源から取得する。CBUSサーバは、第1の評価条件および基準対象に関する情報を伝送する検索要求メッセージを第2の情報源に送信する。第2に情報源は、第1の評価条件および基準対象に関する情報に従って第1の評価条件を満たす第1の評価対象を検索し、第1の評価対象をCBUSサーバに返信する。CBUSサーバは、第1の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。CBUSサーバは、第1の評価対象に関する情報を第2の評価条件において指示された固定値と比較し、第2の評価条件を満たす第2の評価対象を評価結果として取得する。
【0052】
第4の例において、CBUSサーバは、まず、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することが可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において2つの条件を評価するための順序は限定されない。
【0053】
本実施形態において、評価要求メッセージは基準対象、相対的な評価条件、および評価設定を指示する。基準対象に関する情報は評価のための基礎として使用され、相対的な評価条件を満たす評価対象が取得される。相対的な評価条件が相対的な条件であるとき、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、2つの条件を満たす評価対象が順に選択され、それによって、相対的な条件評価はより柔軟である。
【0054】
以下、具体的なシナリオを例として本発明の実施形態の技術的解決手段をさらに説明する。
【0055】
図4は、本発明の第4実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態においてユーザAはCBUSサービスの加入者である。ユーザAは、他の都市の顧客を訪問した後、CBUSサービスによって何人かの友人の中で最も近い友人を探して会うことを意図し、ユーザAのSIP URIはsip:a@example.comであり、評価される友人のSIP URIはそれぞれsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであると仮定する。図4を参照すると、本実施形態の方法は具体的には次のステップを含む。
【0056】
ステップ301において、ユーザAは端末上のCBUSクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置がユーザAに最も近いことであり、評価対象はユーザAの3人の友人であり、評価設定は1回の評価、すなわち、CBUSサーバは条件を満たす1人の友人のURIのみ返信する必要がある。CBUSクライアントは、ユーザAの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをCBUSサーバに送信し、相対的な評価条件は(ユーザA、すなわち、本実施形態における評価要求の発信者である)基準対象を指示する。
【0057】
この実施形態において、評価要求メッセージはHTTP GETの実現方式を採用することが可能であり、それは次に表わされている通りである。
GET cbusgroup@example.com HTTP/1.1
“第1行のコードは要求の行であり、GETは要求がHTTPにおけるGETメソッドを使用することを表わし、cbusgroup@example.comは要求が識別情報に対応する対象を評価することであることを表わし、識別情報は本実施形態においてグループURIであり、HTTP/1.1はプロトコルバージョンを表わす”
Host: cbus.example.com “要求されたリソースがCBUSサーバであることを表わす”
User-Agent: CBUS-client/OMA1.0
“評価要求を発信するユーザエージェントがCBUSクライアントであることを表わす”
Date: Thu, 10 Aug 2007 10:50:33 GMT
“要求が発信された特定の日時を表わす”
X-3GPP-Intended-Identity: "sip:a@example.com"
“要求発信者の識別情報を表わす”
"representing an identity of the request initiator"

<?xml version="1.0"?> "xmlの宣言"
<policyInputData xmlns="http://www.openmobilealliance.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation= "http://www.openmobilealliance.org"
otherEnablerInputTemplate.xsd">
“以下はポリシーに関する入力情報であることを表わす”

<policyInputTemplate xsi:type="PEEMInputTemplateType"
templateID = "PEEMTemplateID_1"
templateVersion = "V1.0.0">
</policyInputTemplate> “基本入力テンプレート情報を表わす”

<policyInputTemplate xsi:type="OtherEnablerInputType""
templateID = "otherEnablerInputTemplateID_2"
templateVersion = "V1.0.0">
“自己定義の入力テンプレート情報を表わす”
<extPolicyVAL> “外部ポリシー”
<focus>a@example.com</focus><filter>nearest</filter>
“ユーザAが基準対象として使用され、ユーザAに最も近いことを表わす”
</extPolicyVAL>
<eva_type>once</eva_type> “1回の評価を表わす”
</policyInputTemplate>
</policyInputData>
【0058】
本実施形態において、CBUSクライアントとCBUSサーバの間の情報交信はPEEMにおけるPEM−1インタフェースを再使用することによって、すなわち、PEM−1インタフェースにおいて定義された入力および出力テンプレートパラメータを拡張することによって実現される。具体的には、相対的な評価条件は、インタフェースの定義における既存の<extPolicyVAL>要素を採用することによって伝送され、<focus>要素は基準対象、すなわち、ユーザAのSIP URIを表わし、<filter>要素は規則を表わし、これはnearest(最も近い)またはfarthest(最も遠い)である値を有する列挙型であり、本実施形態において列挙型の値はnearestである。さらに、標準入力テンプレートに基づいて、文字列型であるパラメータ<eva_type>は評価設定を表わすように拡張され、この要素は、1回の評価(once)、リアルタイムな評価(realtime)、または終了の評価(until_cond_match)の値を有する列挙型であり、本実施形態においてこの要素の値はonceである。
【0059】
ステップ302において、CBUSサーバは、評価要求メッセージを受信し、その評価要求メッセージを解析し、評価対象、すなわち、その評価要求メッセージ内の要求URI(sip:cbus-group@example.com)に従ってSIP URIによって表わされるグループメンバー(f1、f2、およびf3)を取得し、相対的な評価条件は地理的な位置がユーザAに最も近いこと、評価設定は1回の評価であることを取得する。
【0060】
ステップ303において、CBUSサーバは、基準対象のユーザAおよび評価対象のf1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信する。
【0061】
本実施形態において、要求メッセージはHTTP POSTの実現方式を採用し、それは次に表わされている通りである。
POST http://location-server.example.com:9210/LocationQueryService/HTTP/1.1
“HTTP POSTメソッドが採用され、パスは要求が位置サーバに発信されたことを表わす”
Host: location-server.example.com[:9210]
“要求されたリソースは位置サーバであることを表わす”
User-Agent:LCS Client /OMA3.3
“評価要求を発信するユーザエージェントは位置クライアントであることを表わす”
Date: Thu, 10 Aug 2007 10:50:33 GMT
“要求が発信された特定の日時を表わす”
X-3GPP-Intended-Identity: "sip:a@example.com"
“要求発信者の識別情報を表わす”
Content-type: application/slir-info + xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”

<?xml version='1.0' encoding='UTF-8'?> “xmlの宣言”
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_330.DTD">
“参照ドキュメントタイプ定義(DTD)を表わす”
<svc_init ver="3.3.0">
<hdr ver='3.3.0'> “ヘッダを表わす”
<client> “要求者のクライアントに関する情報を表わす”
<id>testlst</id> “要求発信者の名前を表わす”
<pwd>password</pwd> “パスワードを表わす”
</client>
</hdr>
<slir ver='3.3.0' res_type='SYNC'> “要求を表わす”
<msids> “位置決めされるものの識別情報を表わす”
<msid type=' SIP_URI '>a@example.com </msid>
“ユーザAの識別情報”
<msid type=' SIP_URI '>f1@example.com </msid> “友人1の識別情報”
<msid type=' SIP_URI '>f2@example.com </msid> “友人2の識別情報”
<msid type=' SIP_URI '>f3@example.com </msid> “友人3の識別情報”
</msids>
<loc_type type='CURRENT'/>
“位置決めされるものの現在の位置情報が要求されることを表わす”
</slir>
</svc_init>
【0062】
ステップ304において、位置サーバはユーザAおよび3人の友人の位置情報をCBUSサーバに返信する。返信されるメッセージはステップ303に対応する200 OKメッセージであり、それは次に表わされている通りである。
HTTP/1.1 200 OK “要求成功の応答であることを表わす”
Server: LS-serv/OMA2.0 “要求を処理するためにサーバによって使用されるソフトウェアを表わす”
Date: Thu, 10 Aug 200710:50:39 GMT
“要求が発信された特定の日時を表わす”
Content-Type: application/slia-info+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”

<xml version="1.0" encoding='UTF-8'?> “xmlの宣言”
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_320.DTD">
“参照DTDを表わす”
<svc_result ver="3.3.0">
<slia ver="3.3.0"> “応答を表わす”
<pos> “位置決めされるものの位置を表わす”
<msid type=" SIP_URI " enc="ASC"> a@example.com </msid> “位置決めされるものAの識別情報を表わす”
<pd>
<time utc_off="+0100">20030704221700</time>
“位置決めの日時を表わす”
<shape> “位置領域の形状を現す”
<CircularArea> “楕円の領域を表わす”
<coord> “楕円の中心座標を表わす”
<X>45 07 24.123N</X>
<Y>100 06 22.111E</Y>
<Z>5280</Z>
</coord>
<radius>300</radius> “範囲を表わす”
</CircularArea>
</shape>
<alt>5280.0</alt> “高さを表わす”
<alt_acc>300</alt_acc> “高さの正確さを表わす”
<speed>42.42640687119285</speed> “位置決めされるものの速度を表わす”
<direction>45.0</direction> “位置決めされるものの移動方向を表わす”
<lev_conf>0.90</lev_conf>
“範囲内で位置決めされるものの確率を表わす”
</pd>
</pos>
<pos>
<msid type=" SIP_URI " enc="ASC"> f1@example.com </msid> “位置決めされるものf1の識別情報を表わす”
<pd>
<time utc_off="+0100">20030704221700</time>
“位置決めの時刻を表わす”
<shape> “位置領域の形状を表わす”
<CircularArea> “楕円の範囲を表わす”
<coord> “楕円の中心座標を表わす”
<X>56 09 58.183N</X> “範囲を表わす”
<Y>107 09 52.532E</Y>
<Z>3361</Z>
</coord>
<radius>300</radius> “範囲を表わす”
</CircularArea>
</shape>
<alt>5280.0</alt> “高さを表わす”
<alt_acc>300</alt_acc> “高さの正確さを表わす”
<speed>42.42640687119285</speed> “位置決めされるものの速度を表わす”
<direction>45.0</direction> “位置決めされるものの移動方向を表わす”
<lev_conf>0.90</lev_conf>
“範囲内で位置決めされるものの確率を表わす”
</pd>
</pos>

</slia>
</svc_result>
【0063】
ステップ305において、CBUSサーバは、受信された位置情報に従ってユーザAと3人の友人の間の距離を計算し、比較によってユーザAに現在最も近い友人はsip:f2@example.comであることを取得する。
【0064】
ステップ306において、CBUSサーバは、評価結果(すなわち、ユーザAに現在最も近い友人のSIP URI:sip:f2@example.com)をCBUSクライアントに返信する。返信されるメッセージはステップ301に対応する200 OKメッセージであり、それは次に表わされている通りである。
HTTP/1.1 200 OK “要求成功の応答を表わす”
Etag: "et53" “エンティティタグの現在の値を表わす”


<?xml version="1.0"?> “xmlの宣言”
<policyOutputData xmlns="http://www.openmobilealliance.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation= "http://www.openmobilealliance.org"
otherEnablerOutputTemplate.xsd">
“以下はポリシーに関する出力情報であることを表わす”

<policyOutputTemplate xsi:type="PEEMOutputTemplateType"
templateID = "PEEMTemplateID_1"
templateVersion = "V1.0.0">
“基本出力テンプレート情報を表わす
<StatusCode>2101</StatusCode >
“ポリシー処理の結果の状態はサーバがその処理を行うことであることを表わす”
<StatusText>ALLOW</StatusText >
“StatusCodeの付加情報を表わす”
</policyOutputTemplate>

<policyOutputTemplate xsi:type="OtherEnablerOutputType"
templateID = "otherEnablerOutputTemplateID_2"
templateVersion = "V1.0.0"> “自己定義の出力テンプレート情報を表わす”
<StatusCode>2101</StatusCode >
“ポリシー処理の結果の状態はサーバがその処理を行うことであることを表わす”
<StatusText>ALLOW</StatusText >
“StatusCodeの付加情報を表わす”
<urilist>f2@example.com</urilist>
“評価結果は友人2であることを表わす”
</policyOutputTemplate>
</ policyOutputData >
【0065】
このステップは、ステップ301に対応して、PEM−1インタフェースによって定義される標準出力テンプレートパラメータを拡張すること、すなわち、CBUSサーバによって返信された評価結果(URIリスト)を表わす配列型の新たなパラメータ<urilist>によって実現される。
【0066】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、相対的な評価条件に従って該当するサービスエンジン、すなわち、本実施形態の位置サーバから基準対象の位置情報が取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者によって指示された評価対象に従って相対的な条件が評価され、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【0067】
図5は、本発明の第5実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザAは、CBUSサービスによって、友人f1、f2、およびf3が友人Bの自宅住所に近いか否かを判断することを意図する。本実施形態は、基準対象が評価要求の発信者によって指示された他者であり、基準対象に関する情報および評価対象に関する情報は異なる情報源からのものである点で第4実施形態と異なる。ユーザAのSIP URIはsip:a@example.comであり、友人BのSIP URIはsip:b@example.comであると仮定する。図5を参照すると、本実施形態の方法は具体的には次のステップを含む。
【0068】
ステップ401において、ユーザAは端末上のCBUSクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置が友人Bから500mの範囲内で離れていることであり、評価対象はユーザAの3人の友人であり、評価設定は終了の評価である。CBUSクライアントは、ユーザAの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをCBUSサーバに送信し、相対的な評価条件は(本実施形態において友人Bである)基準対象を指示する。
【0069】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用し、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“評価結果はSIP SUBSCRIBEによってCBUSサーバから配信されることを表わす”
Via: SIP/2.0/TCP terminal.example.com; branch=z9hG4bKwYb6QREiCL “要求メッセージが現在まで通過した通路を表わす”
Max-Forwards: 70 “要求を転送する最大回数を表わす”
To: <sip:cbus-server@example.com> “要求の論理的な受信者を表わす”
From: <sip:a@example.com>;tag=ie4hbb8t
“要求発信者の論理的な識別情報を表わす”
Call-ID: cdB34qLToC@terminal.example.com
“1つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける1つの要求および応答を識別する順序番号”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “CBUSイベントパケットを表わす”
Expires: 0 “有効回数を表わし、ここでは1回で取得されることを表わすために0が設定される”
Accept: application/resource-lists+xml “受信されることが可能なメディアタイプを表わす”
Content-Type: application/cbusformat+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”

<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<cbus_req xmlns="urn:oma:xml:cbus"
xmlns:l="urn:ietf:params:xml:ns:resource-lists">
“以下は評価要求に関する情報であることを表わす”
<eva_condition> “評価要求を表わす”
<rel_condition> “相対的な条件を表わす”
<location> “位置情報に基づく条件を表わす”
<focus>b@example.com</focus> “基準対象を表わす”
<radius>500m</ radius > “範囲が500mであることを表わす”
</location>
</rel_condition>
<eva_condition>
<eva_setting> “評価設定を表わす”
<eva_type>until_cond_matched</eva_type> “終了の評価を表わす”
</eva_setting>
<eva_object> “評価対象を表わす”
<l:list> “以下はリストであることを表わす”
<l:entry uri="sip:f1@example.com" />
“評価対象1の識別情報を表わす”
<l:entry uri="sip:f2@example.com" />
“評価対象2の識別情報を表わす”
<l:entry uri="sip:f3@example.com" />
“評価対象3の識別情報を表わす”
</l:list>
</eva_object>
</cbus_req>
【0070】
メッセージ本体の<cbus_req>要素は評価要求メッセージ内の情報を表わすように構成され、<cbus_req>要素は<eva_condition>および<eva_setting>である2つの部分要素を含み、それぞれ、相対的な評価条件および評価設定を表わすように構成される。<eva_condition>は、さらに、相対的な条件を表わすように構成された<rel_condition>部分要素を含み、<rel_condition>は位置情報に基づいて相対的な評価条件を表わすように構成された<location>部分要素を含み、CBUSサーバは位置サーバから関係する情報を取得する。<focus>要素は相対的な条件の基準対象(友人B)を表わすように構成され、その値は友人BのSIP URIである。<radius>要素は範囲を表わすように構成され、すなわち、500mの範囲内を表わし、2つの要素の値はユーザによってランダムに指示することが可能である。本実施形態において、評価方法を表わすように構成された<eva_type>部分要素がさらに定義され、この要素はonce、realtime、またはuntil_cond_matchedの値を有する列挙型であり、それぞれ、1回の評価、リアルタイムな評価、および終了の評価を表わすように構成され、本実施形態において<eva_type>の値はuntil_cond_matchedである。本実施形態において、評価要求メッセージによって具体的な評価対象のリストが伝送され、それによって、メッセージ本体の<eva_object>拡張要素は評価対象を表わすように構成され、評価対象のリストを表わす<list>部分要素を含み、リスト内の各々の評価対象は<entry>部分要素によって表わされる。
【0071】
ステップ402において、CBUSサーバは評価要求メッセージを受信し、200 OK応答メッセージをCBUSクライアントに返信する。
【0072】
ステップ403において、CBUSサーバは評価要求メッセージを解析し、評価対象がsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであること、相対的な評価条件が友人Bから500mの範囲内で離れていること、評価設定が終了の評価であることを取得する。
【0073】
ステップ404において、CBUSサーバは、ユーザBの自宅住所を取得する要求メッセージを共有プロファイルXDMSに送信し、このメッセージはHTTP POSTの実現方式を採用することが可能である。
【0074】
ステップ405において、共有プロファイルXDMSはユーザBの自宅住所をCBUSサーバに返信し、このメッセージは200 OK応答メッセージとすることが可能である。
【0075】
ステップ406において、CBUSサーバは、評価対象sip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信し、このステップにおける要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【0076】
ステップ407において、位置サーバは、f1、f2、およびf3の位置情報をCBUSサーバに返信する。返信されるメッセージはステップ406に対応する200 OKメッセージであり、このメッセージの実現方式は第3実施形態において返信されるメッセージと同じである。
【0077】
本実施形態は、ステップ404からステップ407の実行順序に限定されず、ステップ404の後でステップ405が実行され、ステップ406の後でステップ407が実行される技術的解決手段もまた本発明の本実施形態の保護範囲内にある。
【0078】
ステップ408において、CBUSサーバは、受信されたユーザBの自宅住所およびf1、f2、およびf3の位置情報に従って、各々の評価対象とユーザBの自宅住所の間の距離を計算し、比較によって相対的な評価条件を満たす評価対象を取得する。現在、相対的な評価条件を満たす評価対象が存在しないならば、ステップ409が実行され、そうでなければ、ステップ412が実行される。
【0079】
ステップ409において、CBUSサーバは評価結果なしで一時的な通知メッセージをCBUSクライアントに送信する。一時的な通知メッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザAに返信されることを表わす”
Via: SIP/2.0/TCP cbus-server.example.com;branch=z9hG4bK4EPlfSFQK1 “要求メッセージが現在まで通過した経路を表わす”
Max-Forwards: 70 “要求を転送する最大回数を表わす”
From: <sip:cbus-server.example.com>;tag=zpNctbZq
“要求発信者の論理的な識別情報を表わす”
To: <sip:a@example.com>;tag=ie4hbb8t “要求の論理的な受信者を表わす”
Call-ID: cdB34qLToC@terminal.example.com
“1つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける1つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “CBUSイベントパケットを表わす”
Subscription-State: active;expires=0
“有効回数を表わし、ここでは1回で取得されることを表わすために0が設定される”
Content-Type: text/plain “メッセージ本体のメディアタイプを表わす”
Content-Length: …“メッセージ本体の長さを表わす”
There is no rule matcher at this moment, please wait for a moment, once someone matches the condition, you will be notified!(現時点では規則に合致するものはありません。しばらくお待ち下さい。誰かが条件に合致したときに、あなたに通知されます。)
【0080】
ステップ410において、CBUSクライアントはステップ409に対応する200 OK応答メッセージをCBUSサーバに返信する。
【0081】
ステップ411において、ある条件が引き起こされると(例えば、計時デバイス)、CBUSサーバは、評価対象およびユーザBの位置情報を再び位置サーバから取得することを要求する。
【0082】
CBUSサーバによって位置情報を定期的に取得する時間間隔はユーザAまたはCBUSサーバによって設定することが可能である。
【0083】
ステップ412において、位置サーバは評価対象およびユーザBの位置情報をCBUSサーバに返信し、さらに、CBUSサーバはsubscribe/notifyメソッドにおいて評価対象の位置情報を追跡する。
【0084】
ステップ413において、CBUSサーバは受信された位置情報に従ってユーザBと3人の友人の間の距離を計算し、比較によって、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象を取得する。
【0085】
ステップ414において、CBUSサーバは評価結果(すなわち、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象)をCBUSクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザAに返信されることを表わす”
Via: SIP/2.0/TCP cbus-server.example.com;branch=z9hG4bK4EPlfSFQK1 “要求メッセージが現在まで通過した経路を表わす”
Max-Forwards: 70 “要求を転送する最大回数を表わす”
From: <sip:cbus-server@example.com>;tag=zpNctbZq
“要求発信者の論理的な識別情報を表わす”
To: <sip:a@example.com>;tag=ie4hbb8t “要求の論理的な受信者を表わす”
Call-ID: cdB34qLToC@terminal.example.com
“1つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける1つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “CBUSイベントパケットを表わす”
Subscription-State: active;expires=0
“有効回数を表わし、ここでは1回で取得されることを表わすために0が設定される”
Content-Type: application/resource-lists+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: …“メッセージ本体の長さを表わす”

<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
“続くリソースのリストが評価結果であることを表わす”
<list>
<entry uri="sip:bill@example.com"/> “評価結果1”
<entry uri="sip:joe@example.com"/> “評価結果2”
</list>
</resource-lists>
【0086】
ステップ415において、CBUSクライアントはステップ414に対応する200 OK応答メッセージをCBUSサーバに返信する。
【0087】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、基準対象の位置情報および評価対象の位置情報は、相対的な評価条件に従ってそれぞれ共有プロファイルXDMSおよび位置サーバから取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【0088】
図6は、本発明の第6実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、広告(advertisement)移動局の位置は動的に変更され、リアルタイムな評価方法でCBUSサーバによって広告移動局から1000mの範囲内で離れている現在の地理的な位置を有するIM(instant messaging)接続中の音楽愛好者を検索することを意図する。図6を参照すると、本実施形態の方法は具体的には次のステップを含む。
【0089】
ステップ501において、広告移動局は、位置決めされるCBUSクライアントによって評価要求メッセージをCBUSサーバに送信し、評価要求メッセージは相対的な評価条件および評価設定を含み、相対的な評価条件は広告移動局から1000mの範囲内で離れている現在の地理的な位置を有するIM接続中の音楽愛好者であり、相対的な評価条件は基準対象が広告移動局であることを指示し、評価設定はリアルタイムな評価である。
【0090】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能であり、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“SIP SUBSCRIBEによってCBUSサーバから評価結果が配信されることを表わす”
Via: SIP/2.0/TCP terminal.example.com;
branch=z9hG4bKwYb6QREiCL
“要求メッセージが現在まで通過した経路を表わす”
Max-Forwards: 70 “要求を転送する最大回数を表わす”
To: <sip:cbus-server@example.com> “要求の論理的な受信者を表わす”
From: <sip:advertiser@example.com>;tag=ie4hbb8t
“要求発信者の論理的な識別情報を表わす”
Call-ID: cdB34qLToC@terminal.example.com
“1つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける1つの要求および応答を識別する順序番号を表わす”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “CBUSイベントパケットを表わす”
Expires: 0 “有効回数を表わし、ここでは1回で取得されることを表わすために0が設定される”
Accept: application/resource-lists+xml “受信されることが可能なメディアタイプを表わす”
Content-Type: application/cbusformat+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”

<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<cbus_req xmlns="urn:oma:xml:cbus"
xmlns :pdm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns :l= "urn :oma :xml :loc:user "> “以下は評価要求に関する情報であることを表わす”
<eva_condition> “評価条件を表わす”
<rel_condition> “相対的な条件を表わす”
<location> “位置情報に基づく条件を表わす”
<focus>advertiser@example.com</focus>
“基準対象を表わす”
<radius>1000m</ radius > “範囲が1000mであることを表わす”
</location>
</rel_condition>
<fix_condition> “検索対象の条件を表わす”
<presence> “プレゼンス情報に基づく条件を表わす”
<rule>//pdm:tuple[*/op:service-id="org.openmobilealliance:IM-pager-mode" /pdm:status[basic="open"]</rule> “IM接続中を表わす”
</presence>
<shared_xdms>
“検索対象によって個々にXDMSに記憶されている情報に基づく条件を表わす”
<rule>//l:hobbies/l:hobby/l:music]</rule>
“趣味が音楽であることを表わす”
</shared_xdms>
</fix_condition>
<eva_condition>
<eva_setting> “評価設定を表わす”
<eva_type>realtime</eva_type> “リアルタイムな評価を表わす”
<eva_duration>12h</eva_duration>
“評価期間は12時間であることを表わす”
<eva_interval>5min</eva_interval> “評価間隔は5分であることを表わす”
<result_min>50</result_min> “返信される評価結果の数の下限を表わす”
<result_max>200</result_max> “返信される評価結果の数の上限を表わす”
</eva_setting>
</cbus_req>
【0091】
<rel_condition>要素およびその部分要素の定義は第4実施形態と同じである。本実施形態において相対的な評価条件は相対的な条件と評価対象の条件の組み合わせであり、それによって、評価対象の条件を表わすように構成された新たな<fix_condition>要素が定義され、その<presence>および<shared_xdms>部分要素は、それぞれ、条件がプレゼンス情報および共有XDMS内の情報に基づくことを表わすように構成され、ここで、2つの部分要素における<rule>要素はともに特定の規則内容を表わすように構成される。本実施形態はリアルタイムな評価方法を採用するので、評価期間を表わすように構成された新たな<eva_duration>部分要素、リアルタイムな評価の時間間隔を表わすように構成された<eva_interval>、および、評価要求の発信者によって要求され、CBUSサーバによって返信される評価結果の数の下限および上限を表わすように構成された<result_min>および<result_max>が定義される。
【0092】
ステップ502において、CBUSサーバは評価要求メッセージを受信し、200 OK応答メッセージをCBUSクライアントに返信する。
【0093】
ステップ503において、CBUSサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、および基準対象を取得する。
【0094】
ステップ504において、本実施形態の相対的な評価条件は、第1の評価条件(相対的な条件)および第2の評価条件(評価対象の条件)を含み、ここで、第1の評価条件は、広告移動局から1000mの範囲内で離れている現在の地理的な位置を有する音楽愛好者であり、第2の評価条件はIM接続中であり、CBUSサーバは第1の評価条件および基準対象を伝送する検索要求メッセージを(本実施形態において具体的には位置サーバである)情報源に送信し、それによって、広告移動局から1000mの範囲内で離れている現在の地理的な位置を有する音楽愛好者を検索することを要求する。
【0095】
本実施形態における検索要求メッセージはHTTP POSTの実現方式を採用することが可能であり、それは次に表わされている通りである。
POST http://location-server.example.com:9210/LocationQueryService/HTTP/1.1
“HTTP POSTメソッドが採用され、パスは要求が位置サーバに発信されることを表わす”
Host: location-server.example.com[:9210]
“要求されたリソースが位置サーバであることを表わす”
User-Agent:LCS Client /OMA3.3
“評価要求を発信するユーザエージェントが位置クライアントであることを表わす”
Date: Thu, 10 Aug 2007 10:50:33 GMT “要求が発信された特定の日時を表わす”
X-3GPP-Intended-Identity: "sip:advertiser@example.com"
“要求発信者の識別情報を表わす”
Content-type: application/slir-info + xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_330.DTD">
<svc_init ver="3.3.0" search="TRUE">
<hdr ver='3.3.0'> “ヘッダを表わす”
<client> “要求者のクライアントに関する情報を表わす”
<id>testlst</id> “要求発信者の名前を表わす”
<pwd>password</pwd> “パスワードを表わす”
</client>
</hdr>
<slir ver='3.3.0' res_type='SYNC'> “要求部分を表わす”
<change_area type=" MS_WITHIN_AREA">
“位置決めを引き起こすときは検索対象が領域に入ったときであることを表わす”
<target_area> “目標領域を表わす”
<focus>advertiser@example.com</focus>
“基準対象は広告移動局であることを表わす”
<radius>1000m</radius> “範囲は1000mであることを表わす”
</target_area>
</change_area>
<userinfo>
<hobby>music</hobby> “趣味は音楽を含むことを表わす”
</userinfo>
<loc_type type='CURRENT_OR_LAST'/>
“位置決めされるものの現在または以前の位置情報が要求されることを表わす”
</slir>
</svc_init>
【0096】
検索機能を満たすために、本実施形態において、移動位置プロトコル(Mobile Location Protocol(MLP))が拡張される。具体的には、svc_init要素について新たな属性検索が定義され、位置サーバに送信された要求メッセージが検索要求メッセージであるか否かを表わすように構成される。属性の値が真(true)であるならば、それは要求メッセージが検索要求メッセージであることを示し、属性の値が偽(false)であるならば、それは要求メッセージが位置情報の要求メッセージであることを示す。
【0097】
ステップ505において、位置サーバは条件検索を実行し、基準対象に関する情報を問い合わせ、基準対象および第1の評価条件に関する情報に従って第1の評価条件を満たす評価対象を検索する。
【0098】
具体的には、広告移動局の位置がまず決定され、広告移動局の位置に従って広告移動局から1000mの範囲内で離れている人が決定され、位置サーバ内のユーザ情報データベース内の情報に従って広告移動局から1000mの範囲内で離れている人がさらに選択され、音楽を含む趣味を有する人が選択される。
【0099】
さらに、位置サーバは、ユーザが位置情報を公開するか否か選択する機能も提供する。ユーザが位置情報を公開することを選択するならば、位置情報を公開する対象をさらに指示することが可能であり、例えば、評価を受信し、広告を受信し、ユーザが位置情報を公開することを選択したときのみ位置サーバはそのユーザを検索要求メッセージの検索対象に挙げることができる。位置サーバによって検索要求メッセージを処理する時間を減少させるために、位置情報を公開することを望むユーザについて、位置サーバはユーザの位置情報を特定の地図領域にマッピングし、従って、検索要求メッセージを受信した後、位置サーバは誰がある領域の範囲内に存在するかを迅速に決定することができる。さらに、位置サーバは、ユーザの共通に使用される基本情報を記憶するように構成されたユーザ情報記憶データベースを提供し、それによって、位置の相対的な評価条件を満たす人がさらに選択され、そして、CBUSサーバが、ユーザ情報を記憶する他のデータベース(例えば、共有プロファイルXDMS)から関係する情報を取得することを防止し、それによって、CBUSサーバとサービスエンジンの間で過度のトラフィックの交信を防止するが、ユーザ情報は位置サーバにおいてのみ使用され、個人情報である。ユーザ情報を記憶するデータベースがXDMSによって実現されるならば、各ユーザの共通に使用される基本情報は1つのxmlドキュメントによって表わすことができ、それは次に表わされている通りである。

<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<loc-userinfo xmlns = "urn :oma :xml :loc:user"> “以下は位置サービスのユーザの基本情報であることを表わす”
<uri>user1@example.com</uri> “ユーザのURIを表わす”
<gender>female</gender> “性別を表わす”
<age>25</age > “年齢を表わす”
<job>engineer</job> “職業を表わす”
<company>Huawei Technology</company> “会社を表わす”
<hobbies> “趣味を表わす”
<hobby>music</hobby> “趣味が音楽を含むことを表わす”
<hobby>game</hobby> “趣味がゲームを含むことを表わす”
</hobbies>

<open-willingness> “位置情報の設定が公開されることを表わす”
<basic>open</basic> “公開の意思を表わす”
<purpose>evaluation</purpose>
“評価サービスのために位置情報が公開されることを表わす”
<purpose>advertisement</purpose>
“広告サービスのために位置情報が公開されることを表わす”
</open-willingness>
</loc-userinfo>
【0100】
ステップ506において、CBUSサーバは、位置サーバによって返信された第1の評価条件を満たす評価対象を受信し、このステップにおいて返信されるメッセージはステップ504に対応する200 OK応答メッセージとすることが可能であり、それは次に表わされている通りである。
HTTP/1.1 200 OK “要求成功の応答を表わす”
Server: LS-serv/OMA2.0 “要求を処理するためにサーバによって使用されるソフトウェアを表わす”
Date: Thu, 10 Aug 200710:50:39 GMT “要求が発信された特定の日時を表わす”
Content-Type: application/slia-info+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”

<xml version="1.0" encoding='UTF-8'?> “xmlの宣言”
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_320.DTD">
“参照DTDを表わす”
<svc_result ver="3.3.0">
<slia ver="3.3.0"> “応答を表わす”
<msids> “条件を満たす検索対象の識別情報を表わす”
<msid type=' SIP_URI '>user1@example.com </msid>
“条件を満たすユーザ1”
<msid type=' SIP_URI '>user2@example.com </msid>
“条件を満たすユーザ2”
<msid type=' SIP_URI '>user3@example.com </msid>
“条件を満たすユーザ3”

<msid type=' SIP_URI '>user278@example.com </msid>
“条件を満たすユーザ278”
</msids>
</slia>
</svc_result>
【0101】
ステップ506が実行された後、CBUSサーバは、第2の評価条件および評価設定に従って関係するサービスエンジンから第1の評価条件を満たす評価対象に関する情報を取得し、それによって、評価結果を取得する。本実施形態において、第2の評価条件はIMサービス接続中であり、評価結果は次のステップによって取得される。
【0102】
ステップ507において、CBUSサーバは、プレゼンス情報を取得する、具体的には、ステップ505において選択された人がIMサービス接続中であるか否かを表わすプレゼンス情報を取得する要求メッセージをプレゼンスサーバに送信し、その要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【0103】
ステップ508において、プレゼンスサーバはプレゼンス情報をCBUSサーバに返信し、返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【0104】
ステップ509において、CBUSサーバは受信されたプレゼンス情報を判定し、IM接続中である人、すなわち、第2の評価条件を満たす評価対象を選択し、それによって、評価結果を取得する。
【0105】
ステップ510において、CBUSサーバは評価結果を広告移動局に送信する。送信されるメッセージはSIP NOTIFYの実現方式を採用することができ、それは次に表わされている通りである。
NOTIFY sip:advertiser@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザAに返信されることを表わす”
Via: SIP/2.0/TCP cbus-server.example.com;branch=z9hG4bK4EPlfSFQK1 “要求メッセージが現在まで通過した経路を表わす”
Max-Forwards: 70 “要求を転送する最大回数を表わす”
From: <sip:cbus-server@example.com>;tag=zpNctbZq
“要求発信者の論理的な識別情報を表わす”
To: <sip:advertiser@example.com>;tag=ie4hbb8t
“要求の論理的な受信者を表わす”
Call-ID: cdB34qLToC@terminal.example.com
“1つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける1つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “CBUSイベントパケットを表わす”
Subscription-State: active;expires=0
“有効回数を表わし、ここでは1回で取得されることを表わすために0が設定される”
Content-Type: application/resource-lists+xml “メッセージ本体のメディアタイプを表わす”
Content-Length: … “メッセージ本体の長さを表わす”
<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
“続くリソースのリストが評価結果であることを表わす”
<list>
<entry uri="sip:user1@example.com" /> “評価結果1”
<entry uri="sip:user5@example.com" /> “評価結果2”
<entry uri="sip:user11@example.com" /> “評価結果3”

<entry uri="sip:user128@example.com" /> “評価結果45”
</list>
</resource-lists>
【0106】
さらに、ステップ501における評価要求メッセージは<result_min>要素および<result_max>要素、すなわち、相対的な評価条件において設定された評価結果の数の上限(200)および下限(50)を含み、CBUSサーバは、評価結果を返信する前に、評価結果をカウントする。評価結果の数が50より小さいならば、CBUSサーバは、評価結果の数が50に到達するまで、広告移動局によって設定された評価間隔(<eva_interval>要素)に従ってリアルタイムな評価を実行し、そして、評価結果を広告移動局に通知し、一方、今回の評価結果の数が200より大きいならば、CBUSサーバは、複数回、評価結果を広告移動局に通知し、毎回返信される評価結果の数は多くても200である。
【0107】
ステップ511において、広告移動局はステップ510に対応する200 OK応答メッセージをCBUSサーバに返信する。
【0108】
本実施形態はリアルタイムな評価方法を採用し、それによって、CBUSサーバは、評価期間<eva_duration>が到達されるまで、評価間隔<eva_interval>に従って周期的な評価を実行する。
【0109】
さらに、本実施形態はステップ504からステップ509の実行順序に限定されず、評価対象のプレゼンス情報をまず取得することが可能であり、IM接続中である人が選択され、そして、相対的な評価条件を満たす評価対象がさらに検索される。
【0110】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、および評価設定を指示し、広告移動局の位置情報は位置サーバから取得され、相対的な評価条件を部分的に満たす評価対象が検索され、プレゼンスサーバから取得されたプレゼンス情報に従って相対的な評価条件を完全に満たす評価対象がさらに検索され、それによって、評価結果を取得する。本実施形態において、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、広告移動局の位置は動的に変更され、CBUSサーバは広告移動局の変更された位置情報を自動的に取得し、それによって、相対的な評価条件が手動で変更された後の不都合な結果を防止する。
【0111】
図7は、本発明の第7実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、CBUSサービスは単位としてグループを使用する評価機能をサポートする。ユーザAはCBUSサービスによって3つの生成されたグループを評価することを意図し、それによって、相対的な評価条件を満たす最大の人数を有するグループについて3つのグループを検索する。3つのグループのSIP URIはそれぞれsip:group1@example.com、sip:group2@example.com、およびsip:group3@example.comであり、相対的な評価条件は、地理的な位置がユーザAから500mの範囲内で離れていることであり、活動状態は買物中である。図7を参照すると、本実施形態の方法は具体的には次のステップを含む。
【0112】
ステップ601において、ユーザAは端末上のCBUSクライアントによって評価要求メッセージをCBUSサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含む。相対的な評価条件は、地理的な位置がユーザAから500mの範囲内で離れていることであり、活動状態は買物中であり、評価対象は3つのグループであり、評価設定は1回の評価であり、ここで、相対的な評価条件は基準対象がユーザAであることを指示する。
【0113】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<cbusreq xmlns=" xmlns="urn:oma:xml:cbus"
xmlns:ls="urn:oma:xml:poc:list-service"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:pdm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid">
“以下は評価要求に関する情報であることを表わす”

<ls:list-service>
<rl:list> “評価対象を表わす”
<rl:entry uri="sip:group1@example.com"/> “評価対象1”
<rl:entry uri="sip:group2@example.com"/> “評価対象2”
<rl:entry uri="sip:group3@example.com"/> “評価対象3”
</rl:list>

<cr:ruleset> “評価条件および評価設定を表わす”
<cr:rule>
<cr:conditions> “評価条件を表わす”
<is-list-member/> “評価対象のメンバーであるべきであることを表わす”
<location> “位置情報に基づく条件を表わす”
<focus>a@example.com</focus> “基準対象を表わす”
<radius>500m</radius> “範囲を表わす”
</location>
<presence> “プレゼンス情報に基づく条件を表わす”
<filter>//pdm:person/rpid:activities/rpid:shopping</filter>
“活動状態が買物中であることを表わす”
</presence>
</cr:conditions>
<cr:actions> “評価設定を表わす”
<result_urilist>most</result_urilist>
“評価条件を満たす最大の人数を有するグループのURIが返信されることを表わす”
<eva_type>once</eva_type> “1回の評価を表わす”
</cr:actions>
</cr:rule>
</cr:ruleset>
</ls:list-service>
</cbusreq>
【0114】
メッセージ本体の<location>要素および<presence>要素は、それぞれ、位置情報に基づく相対的な評価条件およびプレゼンス情報に基づく相対的な評価条件を表わすように構成される。<result_urilist>の値は、相対的な評価条件を満たす最大の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたmost(最大)とすることが可能であり、また、この要素の値は、相対的な評価条件を満たす最小の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたleast(最小)とすることが可能である。
【0115】
ステップ602において、CBUSサーバは評価要求メッセージを受信し、200 OK応答メッセージをCBUSクライアントに返信する。
【0116】
ステップ603において、CBUSサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【0117】
このステップにおいて、CBUSサーバは、3つのグループのグループ識別情報に従って関係する情報源(例えば、共有グループXDMS)からグループメンバーのリスト情報を取得する。
【0118】
ステップ604において、CBUSサーバはグループメンバーの活動状態の情報を取得する要求メッセージをプレゼンスサーバに送信し、それによって、3つのグループにおける全てのメンバーの活動状態の情報を取得することを要求する。この要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【0119】
ステップ605において、プレゼンスサーバはグループメンバーの活動状態の情報をCBUSサーバに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【0120】
ステップ606において、CBUSサーバは買物中である活動状態の情報を有するグループメンバーを選択する。
【0121】
ステップ607において、CBUSサーバは評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザAおよびステップ506において選択されたグループメンバーの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【0122】
ステップ608において、位置サーバは位置情報をCBUSサーバに返信する。
【0123】
ステップ609において、CBUSサーバは、受信された位置情報に従ってユーザAとステップ606において選択されたグループメンバーの間の距離を計算し、ユーザAから500mの範囲内で離れているグループメンバーを取得し、3つのグループにおいて条件を満たす人数をそれぞれカウントし、条件を満たす最大の人数を有するグループがsip:group2@example.comであることを取得する。
【0124】
ステップ610において、CBUSサーバは評価結果をCBUSクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【0125】
ステップ611において、CBUSクライアントはステップ510に対応する200 OK応答メッセージをCBUSサーバに返信する。
【0126】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示する。まず、グループメンバーの活動状態の情報がプレゼンスサーバから取得され、買物中である活動状態を有するグループメンバーが選択され、そして、ユーザAおよび買物中である活動状態を有するグループメンバーの位置情報が位置サーバから取得され、ユーザAからの距離が計算され、各グループにおいて条件を満たす人数がカウントされ、それによって、評価結果を取得する。本実施形態において、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、本実施形態において、CBUSサーバはグループ選択機能をサポートし、従って、評価方法の応用範囲が拡張される。
【0127】
図8は、本発明の第8実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザAは、CBUSサービスによって顧客Bおよび顧客Cから500mの範囲内で離れている地理的な位置を有する同僚を見つけることを意図する。顧客Bおよび顧客CのSIP URIは、それぞれ、sip:b@example.comおよびsip:c@example.comであり、相対的な評価条件は、地理的な位置が顧客Bおよび顧客Cから500mの範囲内で離れていることであり、評価設定は1回の評価であり、評価対象はユーザAの同僚であり、ここで、ユーザAの同僚のSIP URIは、それぞれ、sip:f1@example.com、sip:f2@example.com、…、およびsip:fn@example.comであると仮定する。図8を参照すると、本実施形態の方法は次のステップを含む。
【0128】
ステップ701において、ユーザAは端末上のCBUSクライアントによって評価要求メッセージをCBUSサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含み、相対的な評価条件は、基準対象が顧客Bおよび顧客Cであることを指示する。
【0129】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?xml version="1.0" encoding="UTF-8"?> “xmlの宣言を表わす”
<cbus_req xmlns="urn:oma:xml:cbus"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
“以下は評価要求に関する情報であることを表わす”
<cr:rule id="ck81">
<cr:conditions> “評価条件を表わす”
<cr:identity> “評価対象を表わす”
<cr:one id="sip:f1@example.com"/> “評価対象1”
<cr:one id="sip:f2@example.com"/> “評価対象2”

<cr:one id="sip:fn@example.com"/> “評価対象n”
</cr:identity>
<focus> “基準対象を表わす”
<cr:one id="sip:b@example.com"/> “基準対象1”
<cr:one id="sip:c@example.com"/> “基準対象2”
</focus>
<radius>500m</radius> “範囲が500mであることを表わす”
</cr:conditions>
<cr:actions> “評価設定を表わす”
<eva_type>once</eva_type> “1回の評価を表わす”
</cr:actions>
<cr:transformations> “評価結果の設定を表わす”
<provide-urilist>true</provide- urilist>
“URIリストを返信することをサーバが要求されていることを表わす”
</cr:transformations>
</cr:rule>
</cbus_req>
【0130】
メッセージ本体の<identity>要素は評価対象を表わすように構成され、<focus>要素は基準対象を表わすように構成され、<provide-urilist>要素の値は真(true)であり、これはURIリストの形式で評価結果を返信することをCBUSサーバが要求されていることを表わすように構成される。
【0131】
ステップ702において、CBUSサーバは評価要求メッセージを受信し、200 OK 応答メッセージをCBUSクライアントに返信する。
【0132】
ステップ703において、CBUSサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【0133】
ステップ704において、CBUSサーバは、評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザAの同僚、顧客B、および顧客Cの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【0134】
ステップ705において、位置サーバは位置情報をCBUSサーバに返信する。
【0135】
ステップ706において、CBUSサーバは、受信された位置情報に従って各々の評価対象(ユーザAの同僚)と顧客Bの間の距離、および各々の評価対象と顧客Cの間の距離をそれぞれ計算し、相対的な評価条件を満たす評価対象がsip:f2@example.comであることを取得する。
【0136】
ステップ707において、CBUSサーバは評価結果をCBUSクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【0137】
ステップ708において、CBUSクライアントはステップ510に対応する200 OK応答メッセージをCBUSサーバに返信する。
【0138】
本実施形態において、評価要求メッセージは、複数の基準対象、相対的な評価条件、評価設定、および評価対象を指示し、ユーザAの同僚、顧客B、および顧客Cの位置情報は位置サーバから取得され、相対的な評価条件を満たす評価対象が取得され、それによって、評価結果を取得する。本実施形態において、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。さらに、本実施形態におけるCBUSサーバは複数の基準対象を有する評価方法をサポートし、ユーザまたはアプリケーションの設定に従って異なる基準対象を動的に選択することが可能であり、それによって、相対的な評価条件の設定がより柔軟になる。
【0139】
図9は、本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。図9を参照すると、本実施形態のシステムは、サーバ1およびクライアント2を含み、さらに、情報源3を含むことが可能である。
【0140】
クライアント2は評価要求メッセージをサーバ1に発信する。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。相対的な条件評価に関する情報が評価対象を含むならば、サーバ1は、評価要求メッセージに従って情報源3から相対的な評価条件において指示された基準対象に関する情報および評価対象に関する情報(この2つに関する情報は相対的な条件評価のために要求される情報である)を取得し、この2つに関する情報を比較し、評価結果を取得し、この評価結果をクライアント2に送信する。相対的な条件評価に関する情報が評価対象を含まないならば、サーバ1は、基準対象および/または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源3に送信し、情報源3は、基準対象に関する情報に従って相対的な評価条件(すなわち、相対的な条件評価のために要求される情報)を満たす評価対象を検索し、この評価対象をサーバ1に送信し、サーバ1は、相対的な評価条件を満たす評価対象に従って評価結果を取得し、この評価結果をクライアント2に送信する。
【0141】
さらに、図9に表わされているように、本実施形態のクライアント2は、以下の本発明の実施形態のクライアントにおける任意のクライアントとすることが可能であり、サーバ1は、以下の本発明の実施形態のサーバにおける任意のサーバとすることが可能である。
【0142】
図10は、本発明の一実施形態によるクライアントの構成図である。図10を参照すると、本実施形態のクライアントは、第2送信モジュール21および第2送信モジュール22を含む。第2送信モジュール21は評価要求メッセージを送信するように構成される。第2受信モジュール22は評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は、相対的な評価条件および/または評価対象および/または評価設定を含み、または、参照パス情報を含み、参照パス情報は相対的な評価条件および/または評価対象および/または評価設定の記憶位置を指示する。
【0143】
図11は、本発明の一実施形態によるサーバの構成図である。図11を参照すると、本実施形態のサーバは、第1受信モジュール11、条件取得モジュール12、情報取得モジュール13、および処理/送信モジュール14を含む。第1受信モジュール11は評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。条件取得モジュール12は評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。情報取得モジュール13は評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。処理/送信モジュール14は相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【0144】
相対的な条件評価に関する情報が相対的な評価条件を含むならば、条件取得モジュール12は、さらに、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得するように構成される。
【0145】
相対的な条件評価に関する情報が参照パス情報であるならば、条件取得モジュール12は、さらに、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
【0146】
評価要求メッセージが解析され、または、相対的な評価条件が取得されるとき、評価対象がさらに取得される。情報取得モジュール13は、さらに、第3送信モジュール15および第3受信モジュール16を含む。第3送信モジュール15は評価対象に関する情報および基準対象に関する情報を取得する要求メッセージを情報源3に送信するように構成される。第3受信モジュール16は情報源3によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成される。第3送信モジュール15および第3受信モジュール16は通信によって接続され、正確には、情報源3を介して通信によって接続されることも可能である。
【0147】
処理/送信モジュール14は相対的な評価条件に従って評価対象に関する情報を基準対象に関する情報と比較し、評価結果を取得し、その評価結果をクライアントに送信するように構成されることが可能である。
【0148】
さらに、情報取得モジュール13は第4送信モジュール17および第4受信モジュール18を含むことも可能である。第4送信モジュール17は、取得された相対的な評価条件および相対的な評価条件において指示された基準対象に従って基準対象および/または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源3に送信するように構成される。第4受信モジュール18は情報源3によって返信された相対的な評価条件を満たす評価対象を受信するように構成され、相対的な評価条件を満たす評価対象は相対的な条件評価のために要求される情報であり、また、評価結果である。第4送信モジュール17は通信によって第4受信モジュール18に接続され、正確には、情報源3を介して通信によって接続されることも可能である。
【0149】
本発明の実施形態による相対的な条件評価を実現するシステム、クライアント、およびサーバにおいて、相対的な評価条件が取得され、基準対象は相対的な評価条件において指示され、それによって、基準対象に関する情報は評価のための基礎として使用され、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、基準対象の状態に従って評価が実行される。
【0150】
この技術分野の当業者は、本発明の実施形態による方法のステップの全部または一部がプログラム命令関連ハードウェアによって実現されることが可能であることを理解すべきである。プログラムはコンピュータ読み取り可能な記憶媒体に記憶されることが可能である。プログラムが実行されるとき、本発明の実施形態による方法のステップが実行される。記憶媒体は、ROM、RAM、磁気ディスク、または光ディスクのようなプログラムコードを記憶することが可能な任意の媒体とすることが可能である。
【0151】
最後に、上記の実施形態は本発明の技術的解決手段を説明するために提供されたにすぎず、本発明を限定することを意図していないことに留意すべきである。上記実施形態に関して本発明が詳細に説明されたが、修正または置換が該当する技術的解決手段の要旨を本発明の思想および範囲から逸脱させない限り、上記実施形態に記載された技術的解決手段に修正を行うことができ、または、技術的解決手段におけるいくつかの技術的特徴に等価な置換を行うことができることをこの技術分野の当業者は理解すべきである。
【符号の説明】
【0152】
1 サーバ
2 クライアント
3 情報源
11 第1受信モジュール
12 条件取得モジュール
13 情報取得モジュール
14 処理/送信モジュール
15 第3送信モジュール
16 第3受信モジュール
17 第4送信モジュール
18 第4受信モジュール
21 第2送信モジュール
22 第2受信モジュール

【特許請求の範囲】
【請求項1】
評価要求メッセージを受信するステップを有し、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するステップと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップと、
を有する相対的な条件評価を実現する方法。
【請求項2】
前記相対的な条件評価に関する情報は前記相対的な評価条件を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記評価要求メッセージを解析し、前記相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップを有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項3】
前記相対的な条件評価に関する情報は参照パス情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記参照パス情報に対応する記憶位置から前記相対的な評価条件および前記相対的な評価条件において指示された基準対象を取得するステップを有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項4】
前記相対的な条件評価に関する情報は評価対象をさらに含み、かつ、前記評価要求メッセージを解析するステップは前記評価対象を取得するステップを有するか、または、
前記参照パス情報から評価対象を取得するステップを有する請求項2または3に記載の相対的な条件評価を実現する方法。
【請求項5】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップと、
前記関係する情報源によって返信された評価対象および基準対象に関する情報を取得するステップと、
を有する請求項4に記載の相対的な条件評価を実現する方法。
【請求項6】
前記関係する情報源に送信される前記評価対象および前記基準対象に関する情報を取得する要求メッセージは、評価要求の発信者の識別情報を伝送し、
前記方法は、前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップの後に、前記関係する情報源によって前記評価要求の発信者の識別情報に従って前記評価要求の発信者の識別情報の確認を実行するステップをさらに有する請求項5に記載の相対的な条件評価を実現する方法。
【請求項7】
前記相対的な条件評価のために要求される情報は同一の情報源から取得されるか、または、
前記相対的な条件評価のために要求される情報は異なる情報源から取得される請求項1に記載の相対的な条件評価を実現する方法。
【請求項8】
前記相対的な条件評価のために要求される情報は前記評価対象に関する情報および前記基準対象に関する情報を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信するステップを有する請求項4に記載の相対的な条件評価を実現する方法。
【請求項9】
前記相対的な評価条件は第1の評価条件および第2の評価条件を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記第1の評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、前記第1の評価条件を満たす第1の評価対象を取得するステップと、
前記関係する情報源から前記第1の評価対象に関する情報を取得するステップと、
前記第1の評価対象に関する情報を前記第2の評価条件において指示された固定値と比較し、前記第2の評価条件を満たす第2の評価対象を取得するステップと、
前記第2の評価対象を評価結果として送信するステップと、
を有する請求項8に記載の相対的な条件評価を実現する方法。
【請求項10】
前記評価対象がグループであるならば、
前記評価対象に関する情報はグループメンバーに関する情報であり、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記相対的な評価条件に従って前記グループメンバーに関する情報を前記基準対象に関する情報と比較し、前記グループ内で前記相対的な評価条件を満たすグループメンバーをカウントし、評価対象を取得および送信するステップを有する請求項4に記載の相対的な条件評価を実現する方法。
【請求項11】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記相対的な評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項12】
前記関係する情報源は第1の情報源および第2の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第1の情報源から前記基準対象に関する情報を取得するステップと、
前記相対的な評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第2の情報源に送信し、それによって前記第2の情報源が前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記第2の情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項13】
前記相対的な評価条件は第1の評価条件および第2の評価条件を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第1の評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記第1の評価条件および前記基準対象に関する情報に従って前記第1の評価条件を満たす第1の評価対象を検索するステップと、
前記第1の評価対象を受信するステップと、
を有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項14】
前記関係する情報源は第1の情報源および第2の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第1の情報源から前記基準対象に関する情報を取得するステップと、
第1の評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第2の情報源に送信し、それによって前記第2の情報源が前記第1の評価条件および前記基準対象に関する情報に従って前記第1の評価条件を満たす第1の評価対象を検索するステップと、
前記第2の情報源によって返信された前記第1の評価条件を満たす第1の評価対象を受信するステップと、
を有する請求項13に記載の相対的な条件評価を実現する方法。
【請求項15】
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記第1の評価対象に関する情報を前記第2の評価条件において指示された固定値と比較し、前記第2の評価条件を満たす第2の評価対象を取得するステップと、
前記第2の評価対象を評価結果として送信するステップと、
を有する請求項13または14に記載の相対的な条件評価を実現する方法。
【請求項16】
前記相対的な評価条件は評価結果の数の上限および下限を含み、
前記評価結果を取得するステップは、
サーバによって、前記評価結果の数が前記下限より少ないとき、前記評価結果の数が前記下限に到達するまで、評価を実行し続け、評価結果を返信するステップと、
前記サーバによって、前記評価結果の数が前記上限より多いとき、複数回、評価結果を返信するステップと、をさらに有し、毎回返信される評価結果の数は前記上限より多くない請求項1から3のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項17】
前記基準対象は評価要求の発信者または前記評価要求の発信者によって指示されたユーザであるか、または、
前記基準対象の数は1つまたは複数であるか、または、
前記評価の手順の間、前記基準対象は固定されるか、または、前記評価の手順の間、事前設定に従って異なる基準対象が動的に選択される請求項1から3のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項18】
前記相対的な条件評価に関する情報は評価設定をさらに含み、
前記評価設定は、1回の評価、リアルタイムな評価、または、終了の評価を含む請求項2または3に記載の相対的な条件評価を実現する方法。
【請求項19】
前記評価要求メッセージは、ポリシーの評価、実施、および管理(PEEM)の呼び出し可能インタフェース(PEM−1)によって受信され、前記評価結果はPEM−1インタフェースによって送信される請求項1から3のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項20】
前記相対的な評価条件が取得されるとき評価対象が取得され、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、前記関係する情報源から前記評価対象に関する情報および前記基準対象に関する情報を取得するステップを有し、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および返信するステップは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および返信するステップを有する請求項1に記載の相対的な条件評価を実現する方法。
【請求項21】
評価要求メッセージを送信し、前記評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成されたクライアントを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
受信された評価要求メッセージに従って前記相対的な評価条件および前記相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を前記クライアントに送信するように構成されたサーバをさらに備える相対的な条件評価を実現するシステム。
【請求項22】
前記相対的な評価条件において指示された評価対象に関する情報および基準対象に関する情報を提供し、前記相対的な評価条件を満たす評価対象を検索するように構成された情報源をさらに備える請求項21に記載の相対的な条件評価を実現するシステム。
【請求項23】
評価要求メッセージをサーバに送信するように構成された第2送信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
前記評価要求メッセージに従って前記サーバによって返信された評価結果を受信するように構成された第2受信モジュールをさらに備えるクライアント。
【請求項24】
評価要求メッセージを受信するように構成された第1受信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するように構成された条件取得モジュールと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成された情報取得モジュールと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するように構成された処理/送信モジュールと、
をさらに備えるサーバ。
【請求項25】
前記情報取得モジュールは、
評価対象に関する情報および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するように構成された第3送信モジュールと、
前記関係する情報源によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成された第3受信モジュールと、
をさらに備え、
前記処理/送信モジュールは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信する請求項24に記載のサーバ。
【請求項26】
前記情報取得モジュールは、
取得された相対的な評価条件および前記相対的な評価条件において指示された基準対象に従って、前記基準対象および/または前記基準対象に関する情報、および、前記相対的な評価条件を伝送する検索要求メッセージを前記関係する情報源に送信するように構成された第4送信モジュールと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するように構成された第4受信モジュールと、をさらに備え、前記相対的な評価条件を満たす評価対象は前記相対的な条件評価のために要求される情報である請求項24に記載のサーバ。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate


【公表番号】特表2011−521572(P2011−521572A)
【公表日】平成23年7月21日(2011.7.21)
【国際特許分類】
【出願番号】特願2011−509847(P2011−509847)
【出願日】平成21年6月24日(2009.6.24)
【国際出願番号】PCT/CN2009/072425
【国際公開番号】WO2010/003341
【国際公開日】平成22年1月14日(2010.1.14)
【出願人】(504277388)▲ホア▼▲ウェイ▼技術有限公司 (220)
【Fターム(参考)】