相対的な条件評価を実現する方法、システム、サーバ、およびクライアント
相対的な条件評価を実現する方法、システム、サーバ、およびクライアントが提供される。この方法は次のステップを含む。評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。従って、基準対象に関する情報が評価のための基礎として使用され、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、基準対象の状態に従って評価が実行される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信の分野に関し、より詳しくは相対的な条件評価を実現する方法、システム、サーバ、およびクライアントに関する。
【０００２】
本願は、２００８年７月７日に出願され、発明の名称を「相対的な条件評価を実現する方法、システム、サーバ、およびクライアント」とする中国特許出願第２００８１０１３０５５７．１号の優先権を主張し、その全体を引用してここに組み込む。
【背景技術】
【０００３】
サービスを開始する前に、現在のサービスの受け手がそのサービスに参加するために適切であるか否かを知るために、ユーザまたはあるアプリケーションはサービスの受け手の現在の状態（status）を評価することができ、それによって、サービス開始の効率性を向上させ、通信リソースの浪費を防止する。条件を基にしたユニフォームリソース識別選択（Condition Based Uniform resource identification Selection（ＣＢＵＳ））サービスは、評価機能を提供することを目的とし、評価要求者の要望に従って相対的な評価条件を満たす対象を提供することができる。
【０００４】
グループセッションを確立するサービスを一例にすると、グループセッションを確立する方法は次のステップを含む。サービスサーバは、グループセッション要求を受信し、そのグループセッション要求における情報に従ってグループメンバーのリストおよびセッション確立条件を取得する。サービスサーバは、グループメンバーのセッション確立条件に関する情報を取得し、取得した情報がセッション確立条件を満たすか否かを判定する。サービスサーバは、セッション確立条件を満たすグループメンバーのクライアントにグループセッション確立要求を発信し、グループセッションを確立する。先行技術における相対的な評価条件は次に表わされている通りである。
【０００５】
< 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 >
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実現において、発明者らは、先行技術が少なくとも次の問題を有することを発見した。先行技術において、評価対象の情報のみが評価される、すなわち、評価要求者は評価対象のある状態が固定値を満たすことを指示することが必要である。評価要求者が固定値を指示しなかった場合、または、ある基準対象の状態に従って評価を実行することを意図する場合、または、相対的な評価条件が動的に変更される場合、先行技術においては評価が実現できない。
【課題を解決するための手段】
【０００７】
本発明は、相対的な条件評価を実現する方法、システム、サーバ、およびクライアントを提供し、それによって、評価要求者が、評価対象のある状態が固定値を満たすことを指示しないとき、基準対象の状態に従って評価が実行されることが可能である。
【０００８】
一実施形態において、本発明は、次のステップを含む相対的な条件評価を実現する方法を提供する。
評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【０００９】
一実施形態において、本発明は、クライアントおよびサーバを含む相対的な条件評価を実現するシステムを提供する。
クライアントは、評価要求メッセージを送信し、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
サーバは、受信された評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果をクライアントに送信するように構成される。
【００１０】
一実施形態において、本発明は、第２送信モジュールおよび第２受信モジュールを含むクライアントを提供する。
第２送信モジュールは評価要求メッセージをサーバに送信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
第２受信モジュールは、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。
【００１１】
一実施形態において、本発明は、第１受信モジュール、条件取得モジュール、情報取得モジュール、および処理／送信モジュールを含むサーバを提供する。
第１受信モジュールは、評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。
条件取得モジュールは、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
情報取得モジュールは、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。
処理／送信モジュールは、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【００１２】
本発明の実施形態において、相対的な評価条件が取得され、相対的な評価条件は基準対象を指示し、それによって、基準対象に関する情報が評価のための基礎として使用され、基準対象の状態に従って評価が実行される。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１実施形態による相対的な条件評価を実現する方法のフローチャートである。
【図２】本発明の第２実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図３】本発明の第３実施形態による相対的な条件評価を実現する方法の第１の場合のシグナリングフローチャートである。
【図４】本発明の第４実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図５】本発明の第５実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図６】本発明の第６実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図７】本発明の第７実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図８】本発明の第８実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図９】本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。
【図１０】本発明の一実施形態によるクライアントの構成図である。
【図１１】本発明の一実施形態によるサーバの構成図である。
【発明を実施するための形態】
【００１４】
図１は、本発明の第１実施形態による相対的な条件評価を実現する方法のフローチャートである。図１を参照すると、本実施形態の方法は具体的には次のステップを含む。
ステップ１０１において、評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
ステップ１０２において、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
ステップ１０３において、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
ステップ１０４において、相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【００１５】
さらに、ステップ１０１における相対的な条件評価に関する情報は相対的な評価条件とすることが可能であり、すなわち、相対的な評価条件は評価要求メッセージ内にカプセル化され、従って、ステップ１０２において、具体的には、評価要求メッセージが解析され、相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。
【００１６】
ステップ１０１における相対的な条件評価に関する情報は参照パス情報とすることも可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ１０１の前に、相対的な評価条件が記憶位置において記憶される。ステップ１０２において、具体的には、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。具体的には、相対的な評価条件が予め定義されることが可能である。ユーザまたはアプリケーションは、特定の記憶位置、例えば、共有の拡張マークアップ言語データ管理サーバ（ＸＤＭＳ）またはＣＢＵＳサーバ内の記憶空間において予め定義された相対的な評価条件を記憶させる。このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは、相対的な評価条件の参照パスを指示する必要がある。
【００１７】
本実施形態において、相対的な評価条件が取得され、相対的な評価条件は相対的な条件評価の基準対象を指示し、それによって、基準対象に関する情報が評価の基礎として使用され、基準対象の状態に従って相対的な条件評価が実行される。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶することが可能であり、相対的な評価条件は評価要求メッセージにおいて伝送することが可能であり、それによって、評価の効率性を向上させる。
【００１８】
図２は、本発明の第２実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ＣＢＵＳサービスが例とされ、これに伴う装置は、ＣＢＵＳクライアント、ＣＢＵＳサーバ、および関係するサービスエンジンを含む。図２に表わされているように、本実施形態の方法は具体的には次のステップを含む。
【００１９】
ステップ２０１において、ＣＢＵＳクライアントは、評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは、相対的な評価条件および相対的な評価条件において指示された基準対象を含み、さらに、評価対象および／または評価設定を含み、評価対象および評価設定はオプションの情報とすることが可能である。
【００２０】
相対的な評価条件は、次の２つの例とすることが可能である。一例において、相対的な評価条件は相対的な条件のみを含み、他の例において、相対的な評価条件は相対的な条件と評価対象の条件の組み合わせを含む。さらに、ＣＢＵＳサーバは、主に、位置情報、プレゼンス情報、および評価対象の共有ＸＤＭＳ内の情報に従って評価を実行し、それによって、相対的な評価条件は、３種類の情報のうち１つまたは複数に対応する部分によって表わすことが可能である。さらに、相対的な評価条件は、ＣＢＵＳサーバが評価対象の情報を基準対象の情報と比較すべきであることを示し、従って、相対的な評価条件は基準対象を指示する。すなわち、基準対象は相対的な評価条件に含まれる。
【００２１】
基準対象は、評価要求の発信者または評価要求の発信者によって指示された他のものとすることが可能である。基準対象の数は１つまたは複数とすることが可能である。評価手順の間、基準対象は固定され、または、変更されることが可能であり、例えば、ＣＢＵＳサーバはＣＢＵＳクライアントの事前設定に従って異なる条件のもとで異なる基準対象を動的に選択する。
【００２２】
評価対象は１人のユーザ、複数のユーザ（例えば、あるグループ）とし、または、単位としてグループ（すなわち、複数のグループ）を使用することが可能である。ＣＢＵＳサービスはグループ選択機能をサポートし、評価要求者によって指示された複数のグループを評価し、相対的な評価条件を満たすグループを選択する
【００２３】
評価設定は、主に、１回の評価、リアルタイムな評価、終了の評価（評価された対象が相対的な評価条件を満たすとき評価が終了する）、および他の形態を含む。さらに、ＣＢＵＳは、ＣＢＵＳクライアントが、自身の要求に従ってＣＢＵＳサーバによって返信された評価結果の数の上限および下限を設定することをサポートし、例えば、相対的な評価条件を満たす現在の評価対象の数が下限に到達していないならば、ＣＢＵＳサーバは、その数が下限に到達するまで評価を実行し続け、評価結果を返信し、ＣＢＵＳサーバによって返信される結果の数は上限を超えない。
【００２４】
このステップにおいて、ＣＢＵＳクライアントは、ポリシーの評価、実施、および管理（policy evaluation, enforcement and management（ＰＥＥＭ））の呼び出し可能インタフェース（以下、ＰＥＭ−１と呼ぶ）によって評価要求メッセージをＣＢＵＳサーバに送信することが可能である。さらに、本実施形態において、ＣＢＵＳクライアントとＣＢＵＳサーバの間の交信は、ＰＥＭ−１インタフェースによって実現することが可能である。具体的には、ＰＥＥＭは、運営者によって設定され、サービスプロバイダおよびアプリケーション開発者によって指示された、端末ユーザのプリファレンス設定におけるポリシーを評価、実施、および管理することによってリソースの保護および管理を実現するフレームワークであり、インタフェースＰＥＭ−１はポリシー評価のために定義される。ＰＥＭ−１インタフェースによってＰＥＥＭからポリシー処理リソースが要求されるとき、各種リソースの差異のために該当するポリシーは異なり、それによって、ＰＥＭ−１入力情報および出力情報は異なり、入力パラメータおよび出力パラメータも異なる。ＰＥＭ−１は汎用インタフェースであり、異なるポリシーのために異なる独立のインタフェースを設定することは不可能であり、それによって、ＰＥＭ−１テンプレートによって問題を解決することができ、すなわち、構造を要求および応答することが指定される。ＰＥＭ−１テンプレートにおいて、ポリシーを処理するように構成されたどの入力ＰＥＭ−１パラメータが評価要求者によって提供されるか、ポリシーが処理された後、どの出力ＰＥＭ−１パラメータが評価要求者のために生成されるかが定義され、すなわち、基本入力および出力パラメータが定義され、具体的な要求に従ってパラメータが拡張されることがサポートされる。オプションで、本実施形態において、インタフェースは再利用することができ、ＣＢＵＳクライアントとＣＢＵＳサーバの間の交信は、ＰＥＭ−１インタフェースの入力および出力テンプレートパラメータを拡張することによって実現される。
【００２５】
ステップ２０２において、ＣＵＢＳサーバは、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得し、さらに、評価対象および評価設定を取得する。
【００２６】
オプションで、ステップ２０１における評価要求メッセージは、参照パス情報を含むことが可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ２０１の前に、記憶位置において相対的な評価条件が記憶される。ステップ２０２において、具体的には、相対的な評価条件および相対的な評価条件において指示された基準対象が参照パス情報に対応する記憶位置から取得され、オプションで、評価対象および評価設定も取得することが可能である。具体的には、相対的な評価条件、評価対象、および／または、評価設定は予め定義することが可能であり、ユーザまたはアプリケーションは予め定義された相対的な評価条件、評価対象、および／または、評価設定を特定の記憶位置、例えば、共有ＸＤＭＳ、または、ＣＢＵＳサーバ内の記憶空間に記憶させ、このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは参照パスのみ指示する必要がある。
【００２７】
ステップ２０３において、ＣＢＵＳサーバは評価対象に関する情報および基準対象に関する情報を取得し、これは具体的には次のステップを含む。
【００２８】
ステップ２０３１において、ＣＢＵＳサーバは、評価対象および基準対象に関する情報を取得する要求メッセージを（本実施形態において具体的にはサービスエンジンである）情報源に送信し、要求メッセージは評価要求の発信者の識別情報を伝送することが可能である。
【００２９】
本発明の実施形態において、サービスエンジンは、限定しないが、位置エンジン、プレゼンスエンジン、および共有ＸＤＭＳエンジンを含む。
【００３０】
さらに、ＣＢＵＳサーバは、相対的な評価条件に従って同一の情報源から評価対象および基準対象に関する情報を取得することが可能であり、または、異なる情報源から評価対象および基準対象に関する情報を取得することが可能である。
【００３１】
ステップ２０３２において、サービスエンジンは、評価対象および基準対象に関する情報をＣＢＵＳサーバに返信する。
【００３２】
ステップ２０３１とステップ２０３２の間に、サービスエンジンは、評価要求の発信者の識別情報に従って評価要求の発信者について識別情報の確認を実行する。具体的には、ＣＢＵＳサーバによって送信された評価対象および基準対象に関する情報を取得する要求メッセージを受信するとき、サービスエンジン（例えば、プレゼンスエンジンまたは位置エンジン）は、（本実施形態においてＣＢＵＳクライアントである）評価要求の発信者を認証することが可能である。ＣＢＵＳサーバがＳＩＰプロトコルによってサービスエンジンとの交信を実現する、例えば、SIP subscribe/notifyメソッドによってプレゼンス情報を取得するならば、評価要求の発信者の識別情報を表わすIdentityおよびIdentity-Infoである２つのヘッダフィールドはサービスエンジンに送信される要求メッセージ内で伝送され、それによって評価要求の発信者の識別情報を示し、Identityフィールドは識別情報の確認の署名のために適合し、Identity-Infoは署名者の証明書の参照である。ＣＢＵＳサーバが他のプロトコルによってサービスエンジンと交信を実現する、例えば、ＨＴＴＰプロトコルによって位置エンジンと交信して位置情報を取得するならば、ＳＩＰプロトコルにおけるIdentityおよびIdentity-Infoと同じ機能を有するフィールドがそのプロトコルにおいて拡張され、それによって評価要求の発信者の識別情報を伝送する。評価要求の発信者の識別情報に従って、サービスエンジンは評価要求の発信者について識別情報の確認を実行する。
【００３３】
ステップ２０４において、ＣＢＵＳサーバは、相対的な評価条件および評価設定に従って評価対象に関する情報を基準対象に関する情報と比較し、それによって評価結果を取得する。
【００３４】
ステップ２０５において、ＣＢＵＳサーバは、評価結果をＣＢＵＳクライアントに返信する。
【００３５】
本実施形態において、相対的な評価条件は相対的な条件を含む。相対的な評価条件が相対的な条件と評価対象の条件の組み合わせを含むならば、言い換えると、相対的な評価条件が第１の評価条件と第２の評価条件を含み、第１の評価条件は相対的な条件であり、第２の評価条件は評価対象の条件であり、評価対象の条件において、評価対象のある状態が固定値を満たすならばステップ２０４およびステップ２０５が具体的には次のステップを含むことが指示される。
【００３６】
ＣＢＵＳサーバは、相対的な条件に従って評価対象に関する情報を基準対象に関する情報と比較し、相対的な条件を満たす第１の評価対象を取得する。
【００３７】
ＣＢＵＳサーバは、（本実施形態において具体的にはサービスエンジンである）関係する情報源から第１の評価対象に関する情報を取得し、例えば、プレゼンスサーバから第１の評価対象のプレゼンス情報を取得する。
【００３８】
ＣＢＵＳサーバは第１の評価対象に関する情報を評価対象についての条件、すなわち、第２の評価条件と比較し、さらに、評価対象についての条件を満たす第２の評価対象を選択する。
【００３９】
ＣＢＵＳサーバは、第２の評価対象を評価結果としてＣＢＵＳクライアントに返信する。
【００４０】
本実施形態において、評価対象についての条件、すなわち、第２の評価条件を満たす評価対象がまず選択されることが可能であり、そして、相対的な条件、すなわち、第１の評価条件を満たす評価対象がさらに選択される。言い換えると、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの評価条件を評価するための順序は限定されない。
【００４１】
本実施形態において、評価要求メッセージは、基準対象および相対的な評価条件を指示し、さらに、評価設定および評価対象を含む。サービスエンジンから取得された基準対象に関する情報は評価のための基礎として使用される。相対的な評価条件が相対的な条件であるとき、評価の要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、２つの条件を満たす評価対象は順に選択され、それによって、相対的な条件評価はより柔軟である。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶させることが可能であり、相対的な評価条件は評価要求メッセージ内で伝送されることが可能であり、それによって、評価の効率性を向上させる。
【００４２】
ステップ２０１においてＣＢＵＳサーバによって受信される評価要求メッセージは評価対象を含まないという点で、本発明の第３実施形態による相対的な条件評価を実現する方法は第２実施形態と異なる。本実施形態の方法は次の例とすることが可能である。
【００４３】
第１の例において、相対的な評価条件は相対的な条件のみを含み、基準対象に関する情報および検索される評価対象（すなわち、検索対象）に関する情報は、同一の情報源から取得される。具体的には、図３は、本発明の第３実施形態による相対的な条件評価を実現する方法の第１の場合のシグナリングフローチャートである。図３を参照すると、ステップ２０１はステップ２０１Ａによって置き換えることが可能であり、ＣＢＵＳクライアントは、相対的な評価条件を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４４】
ステップ２０３Ａにおいて、ＣＢＵＳサーバは、相対的な評価条件および基準対象を伝送する検索要求メッセージを（具体的にはサービスエンジンである）情報源に送信する。ステップ２０３Ｂにおいて、サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および相対的な評価条件に従って相対的な評価条件を満たす評価対象を検索する。ステップ２０３Ｃにおいて、相対的な評価条件を満たす評価対象がＣＢＵＳサーバに返信される。ステップ２０３Ｄにおいて、ＣＢＵＳサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【００４５】
第２の例において、相対的な評価条件が相対的な条件のみを含み、基準対象に関する情報および検索対象に関する情報が異なる情報源から取得されるならば、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４６】
ＣＢＵＳサーバは、基準対象に関する情報を第１の情報源から取得する。ＣＢＵＳサーバは、相対的な評価条件および基準対象に関する情報を伝送する検索要求メッセージを第２の情報源に送信する。第２の情報源は、相対的な評価条件および基準対象に関する情報に従って相対的な評価条件を満たす評価対象を検索し、評価対象をＣＢＵＳサーバに返信する。ＣＢＵＳサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【００４７】
第３の例において、相対的な評価条件が相対的な条件（第１の評価条件）と評価対象の条件（第２の評価条件）の組み合わせであるならば、第２の評価条件において評価対象の条件が固定値を満たすことが指示され、基準対象に関する情報および検索対象に関する情報が同一の情報源から取得される。本実施形態において、相対的な条件を満たす評価対象はサービスエンジンから検索され、そして、サーバは、さらに、検索対象の条件を満たす評価結果を選択する。具体的には、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４８】
ＣＢＵＳサーバは、第１の評価条件および基準対象を伝送する検索要求メッセージを（具体的にはサービスエンジンである）情報源に送信する。サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および第１の評価条件に従って第１の評価条件を満たす第１の評価対象を検索する。ＣＢＵＳサーバは、サービスエンジンによって返信された第１の評価条件を満たす第１の評価対象を受信する。ＣＢＵＳサーバは、第１の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。ＣＢＵＳサーバは、第１の評価対象に関する情報を第２の評価条件において指示された固定値と比較し、第２の評価条件を満たす第２の評価対象を評価結果として取得する。
【００４９】
第３の例において、ＣＢＵＳサーバは、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することも可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの条件を評価するための順序は限定されない。
【００５０】
第４の例において、相対的な評価条件が相対的な条件（第１の評価条件）と評価対象の条件（第２の評価条件）の組み合わせであり、基準対象に関する情報および評価対象に関する情報が異なる情報源から取得されるならば、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００５１】
ＣＢＵＳサーバは、基準対象に関する情報を第１の情報源から取得する。ＣＢＵＳサーバは、第１の評価条件および基準対象に関する情報を伝送する検索要求メッセージを第２の情報源に送信する。第２に情報源は、第１の評価条件および基準対象に関する情報に従って第１の評価条件を満たす第１の評価対象を検索し、第１の評価対象をＣＢＵＳサーバに返信する。ＣＢＵＳサーバは、第１の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。ＣＢＵＳサーバは、第１の評価対象に関する情報を第２の評価条件において指示された固定値と比較し、第２の評価条件を満たす第２の評価対象を評価結果として取得する。
【００５２】
第４の例において、ＣＢＵＳサーバは、まず、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することが可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの条件を評価するための順序は限定されない。
【００５３】
本実施形態において、評価要求メッセージは基準対象、相対的な評価条件、および評価設定を指示する。基準対象に関する情報は評価のための基礎として使用され、相対的な評価条件を満たす評価対象が取得される。相対的な評価条件が相対的な条件であるとき、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、２つの条件を満たす評価対象が順に選択され、それによって、相対的な条件評価はより柔軟である。
【００５４】
以下、具体的なシナリオを例として本発明の実施形態の技術的解決手段をさらに説明する。
【００５５】
図４は、本発明の第４実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態においてユーザＡはＣＢＵＳサービスの加入者である。ユーザＡは、他の都市の顧客を訪問した後、ＣＢＵＳサービスによって何人かの友人の中で最も近い友人を探して会うことを意図し、ユーザＡのSIP URIはsip:a@example.comであり、評価される友人のSIP URIはそれぞれsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであると仮定する。図４を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００５６】
ステップ３０１において、ユーザＡは端末上のＣＢＵＳクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置がユーザＡに最も近いことであり、評価対象はユーザＡの３人の友人であり、評価設定は１回の評価、すなわち、ＣＢＵＳサーバは条件を満たす１人の友人のURIのみ返信する必要がある。ＣＢＵＳクライアントは、ユーザＡの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、相対的な評価条件は（ユーザＡ、すなわち、本実施形態における評価要求の発信者である）基準対象を指示する。
【００５７】
この実施形態において、評価要求メッセージはHTTP GETの実現方式を採用することが可能であり、それは次に表わされている通りである。
GET cbusgroup@example.com HTTP/1.1
“第１行のコードは要求の行であり、GETは要求がHTTPにおけるGETメソッドを使用することを表わし、cbusgroup@example.comは要求が識別情報に対応する対象を評価することであることを表わし、識別情報は本実施形態においてグループURIであり、HTTP/1.1はプロトコルバージョンを表わす”
Host: cbus.example.com “要求されたリソースがＣＢＵＳサーバであることを表わす”
User-Agent: CBUS-client/OMA1.0
“評価要求を発信するユーザエージェントがＣＢＵＳクライアントであることを表わす”
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>
“ユーザＡが基準対象として使用され、ユーザＡに最も近いことを表わす”
</extPolicyVAL>
<eva_type>once</eva_type> “１回の評価を表わす”
</policyInputTemplate>
</policyInputData>
【００５８】
本実施形態において、ＣＢＵＳクライアントとＣＢＵＳサーバの間の情報交信はＰＥＥＭにおけるＰＥＭ−１インタフェースを再使用することによって、すなわち、ＰＥＭ−１インタフェースにおいて定義された入力および出力テンプレートパラメータを拡張することによって実現される。具体的には、相対的な評価条件は、インタフェースの定義における既存の<extPolicyVAL>要素を採用することによって伝送され、<focus>要素は基準対象、すなわち、ユーザＡのSIP URIを表わし、<filter>要素は規則を表わし、これはnearest（最も近い）またはfarthest（最も遠い）である値を有する列挙型であり、本実施形態において列挙型の値はnearestである。さらに、標準入力テンプレートに基づいて、文字列型であるパラメータ<eva_type>は評価設定を表わすように拡張され、この要素は、１回の評価（once）、リアルタイムな評価（realtime）、または終了の評価（until_cond_match）の値を有する列挙型であり、本実施形態においてこの要素の値はonceである。
【００５９】
ステップ３０２において、ＣＢＵＳサーバは、評価要求メッセージを受信し、その評価要求メッセージを解析し、評価対象、すなわち、その評価要求メッセージ内の要求URI（sip:cbus-group@example.com）に従ってSIP URIによって表わされるグループメンバー（f1、f2、およびf3）を取得し、相対的な評価条件は地理的な位置がユーザＡに最も近いこと、評価設定は１回の評価であることを取得する。
【００６０】
ステップ３０３において、ＣＢＵＳサーバは、基準対象のユーザＡおよび評価対象のf1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信する。
【００６１】
本実施形態において、要求メッセージは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>
“ユーザＡの識別情報”
<msid type=' SIP_URI '>f1@example.com </msid> “友人１の識別情報”
<msid type=' SIP_URI '>f2@example.com </msid> “友人２の識別情報”
<msid type=' SIP_URI '>f3@example.com </msid> “友人３の識別情報”
</msids>
<loc_type type='CURRENT'/>
“位置決めされるものの現在の位置情報が要求されることを表わす”
</slir>
</svc_init>
【００６２】
ステップ３０４において、位置サーバはユーザＡおよび３人の友人の位置情報をＣＢＵＳサーバに返信する。返信されるメッセージはステップ３０３に対応する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> “位置決めされるものＡの識別情報を表わす”
<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> “位置決めされるものｆ１の識別情報を表わす”
<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>
【００６３】
ステップ３０５において、ＣＢＵＳサーバは、受信された位置情報に従ってユーザＡと３人の友人の間の距離を計算し、比較によってユーザＡに現在最も近い友人はsip:f2@example.comであることを取得する。
【００６４】
ステップ３０６において、ＣＢＵＳサーバは、評価結果（すなわち、ユーザＡに現在最も近い友人のSIP URI:sip:f2@example.com）をＣＢＵＳクライアントに返信する。返信されるメッセージはステップ３０１に対応する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>
“評価結果は友人２であることを表わす”
</policyOutputTemplate>
</ policyOutputData >
【００６５】
このステップは、ステップ３０１に対応して、ＰＥＭ−１インタフェースによって定義される標準出力テンプレートパラメータを拡張すること、すなわち、ＣＢＵＳサーバによって返信された評価結果（URIリスト）を表わす配列型の新たなパラメータ<urilist>によって実現される。
【００６６】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、相対的な評価条件に従って該当するサービスエンジン、すなわち、本実施形態の位置サーバから基準対象の位置情報が取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者によって指示された評価対象に従って相対的な条件が評価され、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【００６７】
図５は、本発明の第５実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザＡは、ＣＢＵＳサービスによって、友人ｆ１、ｆ２、およびｆ３が友人Ｂの自宅住所に近いか否かを判断することを意図する。本実施形態は、基準対象が評価要求の発信者によって指示された他者であり、基準対象に関する情報および評価対象に関する情報は異なる情報源からのものである点で第４実施形態と異なる。ユーザＡのSIP URIはsip:a@example.comであり、友人ＢのSIP URIはsip:b@example.comであると仮定する。図５を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００６８】
ステップ４０１において、ユーザＡは端末上のＣＢＵＳクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置が友人Ｂから５００ｍの範囲内で離れていることであり、評価対象はユーザＡの３人の友人であり、評価設定は終了の評価である。ＣＢＵＳクライアントは、ユーザＡの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、相対的な評価条件は（本実施形態において友人Ｂである）基準対象を指示する。
【００６９】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用し、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“評価結果はSIP SUBSCRIBEによってＣＢＵＳサーバから配信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける１つの要求および応答を識別する順序番号”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Expires: 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 > “範囲が５００ｍであることを表わす”
</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" />
“評価対象１の識別情報を表わす”
<l:entry uri="sip:f2@example.com" />
“評価対象２の識別情報を表わす”
<l:entry uri="sip:f3@example.com" />
“評価対象３の識別情報を表わす”
</l:list>
</eva_object>
</cbus_req>
【００７０】
メッセージ本体の<cbus_req>要素は評価要求メッセージ内の情報を表わすように構成され、<cbus_req>要素は<eva_condition>および<eva_setting>である２つの部分要素を含み、それぞれ、相対的な評価条件および評価設定を表わすように構成される。<eva_condition>は、さらに、相対的な条件を表わすように構成された<rel_condition>部分要素を含み、<rel_condition>は位置情報に基づいて相対的な評価条件を表わすように構成された<location>部分要素を含み、ＣＢＵＳサーバは位置サーバから関係する情報を取得する。<focus>要素は相対的な条件の基準対象（友人Ｂ）を表わすように構成され、その値は友人ＢのSIP URIである。<radius>要素は範囲を表わすように構成され、すなわち、５００ｍの範囲内を表わし、２つの要素の値はユーザによってランダムに指示することが可能である。本実施形態において、評価方法を表わすように構成された<eva_type>部分要素がさらに定義され、この要素はonce、realtime、またはuntil_cond_matchedの値を有する列挙型であり、それぞれ、１回の評価、リアルタイムな評価、および終了の評価を表わすように構成され、本実施形態において<eva_type>の値はuntil_cond_matchedである。本実施形態において、評価要求メッセージによって具体的な評価対象のリストが伝送され、それによって、メッセージ本体の<eva_object>拡張要素は評価対象を表わすように構成され、評価対象のリストを表わす<list>部分要素を含み、リスト内の各々の評価対象は<entry>部分要素によって表わされる。
【００７１】
ステップ４０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【００７２】
ステップ４０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、評価対象がsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであること、相対的な評価条件が友人Ｂから５００ｍの範囲内で離れていること、評価設定が終了の評価であることを取得する。
【００７３】
ステップ４０４において、ＣＢＵＳサーバは、ユーザＢの自宅住所を取得する要求メッセージを共有プロファイルＸＤＭＳに送信し、このメッセージはHTTP POSTの実現方式を採用することが可能である。
【００７４】
ステップ４０５において、共有プロファイルＸＤＭＳはユーザＢの自宅住所をＣＢＵＳサーバに返信し、このメッセージは200 OK応答メッセージとすることが可能である。
【００７５】
ステップ４０６において、ＣＢＵＳサーバは、評価対象sip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信し、このステップにおける要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【００７６】
ステップ４０７において、位置サーバは、ｆ１、ｆ２、およびｆ３の位置情報をＣＢＵＳサーバに返信する。返信されるメッセージはステップ４０６に対応する200 OKメッセージであり、このメッセージの実現方式は第３実施形態において返信されるメッセージと同じである。
【００７７】
本実施形態は、ステップ４０４からステップ４０７の実行順序に限定されず、ステップ４０４の後でステップ４０５が実行され、ステップ４０６の後でステップ４０７が実行される技術的解決手段もまた本発明の本実施形態の保護範囲内にある。
【００７８】
ステップ４０８において、ＣＢＵＳサーバは、受信されたユーザＢの自宅住所およびｆ１、ｆ２、およびｆ３の位置情報に従って、各々の評価対象とユーザＢの自宅住所の間の距離を計算し、比較によって相対的な評価条件を満たす評価対象を取得する。現在、相対的な評価条件を満たす評価対象が存在しないならば、ステップ４０９が実行され、そうでなければ、ステップ４１２が実行される。
【００７９】
ステップ４０９において、ＣＢＵＳサーバは評価結果なしで一時的な通知メッセージをＣＢＵＳクライアントに送信する。一時的な通知メッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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!（現時点では規則に合致するものはありません。しばらくお待ち下さい。誰かが条件に合致したときに、あなたに通知されます。）
【００８０】
ステップ４１０において、ＣＢＵＳクライアントはステップ４０９に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【００８１】
ステップ４１１において、ある条件が引き起こされると（例えば、計時デバイス）、ＣＢＵＳサーバは、評価対象およびユーザＢの位置情報を再び位置サーバから取得することを要求する。
【００８２】
ＣＢＵＳサーバによって位置情報を定期的に取得する時間間隔はユーザＡまたはＣＢＵＳサーバによって設定することが可能である。
【００８３】
ステップ４１２において、位置サーバは評価対象およびユーザＢの位置情報をＣＢＵＳサーバに返信し、さらに、ＣＢＵＳサーバはsubscribe/notifyメソッドにおいて評価対象の位置情報を追跡する。
【００８４】
ステップ４１３において、ＣＢＵＳサーバは受信された位置情報に従ってユーザＢと３人の友人の間の距離を計算し、比較によって、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象を取得する。
【００８５】
ステップ４１４において、ＣＢＵＳサーバは評価結果（すなわち、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象）をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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"/> “評価結果１”
<entry uri="sip:joe@example.com"/> “評価結果２”
</list>
</resource-lists>
【００８６】
ステップ４１５において、ＣＢＵＳクライアントはステップ４１４に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【００８７】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、基準対象の位置情報および評価対象の位置情報は、相対的な評価条件に従ってそれぞれ共有プロファイルＸＤＭＳおよび位置サーバから取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【００８８】
図６は、本発明の第６実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、広告（advertisement）移動局の位置は動的に変更され、リアルタイムな評価方法でＣＢＵＳサーバによって広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有するＩＭ（instant messaging）接続中の音楽愛好者を検索することを意図する。図６を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００８９】
ステップ５０１において、広告移動局は、位置決めされるＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信し、評価要求メッセージは相対的な評価条件および評価設定を含み、相対的な評価条件は広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有するＩＭ接続中の音楽愛好者であり、相対的な評価条件は基準対象が広告移動局であることを指示し、評価設定はリアルタイムな評価である。
【００９０】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能であり、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“SIP SUBSCRIBEによってＣＢＵＳサーバから評価結果が配信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Expires: 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 > “範囲が１０００ｍであることを表わす”
</location>
</rel_condition>
<fix_condition> “検索対象の条件を表わす”
<presence> “プレゼンス情報に基づく条件を表わす”
<rule>//pdm:tuple[*/op:service-id="org.openmobilealliance:IM-pager-mode" /pdm:status[basic="open"]</rule> “ＩＭ接続中を表わす”
</presence>
<shared_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>
“評価期間は１２時間であることを表わす”
<eva_interval>5min</eva_interval> “評価間隔は５分であることを表わす”
<result_min>50</result_min> “返信される評価結果の数の下限を表わす”
<result_max>200</result_max> “返信される評価結果の数の上限を表わす”
</eva_setting>
</cbus_req>
【００９１】
<rel_condition>要素およびその部分要素の定義は第４実施形態と同じである。本実施形態において相対的な評価条件は相対的な条件と評価対象の条件の組み合わせであり、それによって、評価対象の条件を表わすように構成された新たな<fix_condition>要素が定義され、その<presence>および<shared_xdms>部分要素は、それぞれ、条件がプレゼンス情報および共有ＸＤＭＳ内の情報に基づくことを表わすように構成され、ここで、２つの部分要素における<rule>要素はともに特定の規則内容を表わすように構成される。本実施形態はリアルタイムな評価方法を採用するので、評価期間を表わすように構成された新たな<eva_duration>部分要素、リアルタイムな評価の時間間隔を表わすように構成された<eva_interval>、および、評価要求の発信者によって要求され、ＣＢＵＳサーバによって返信される評価結果の数の下限および上限を表わすように構成された<result_min>および<result_max>が定義される。
【００９２】
ステップ５０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【００９３】
ステップ５０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、および基準対象を取得する。
【００９４】
ステップ５０４において、本実施形態の相対的な評価条件は、第１の評価条件（相対的な条件）および第２の評価条件（評価対象の条件）を含み、ここで、第１の評価条件は、広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有する音楽愛好者であり、第２の評価条件はＩＭ接続中であり、ＣＢＵＳサーバは第１の評価条件および基準対象を伝送する検索要求メッセージを（本実施形態において具体的には位置サーバである）情報源に送信し、それによって、広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有する音楽愛好者を検索することを要求する。
【００９５】
本実施形態における検索要求メッセージは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> “範囲は１０００ｍであることを表わす”
</target_area>
</change_area>
<userinfo>
<hobby>music</hobby> “趣味は音楽を含むことを表わす”
</userinfo>
<loc_type type='CURRENT_OR_LAST'/>
“位置決めされるものの現在または以前の位置情報が要求されることを表わす”
</slir>
</svc_init>
【００９６】
検索機能を満たすために、本実施形態において、移動位置プロトコル（Mobile Location Protocol（ＭＬＰ））が拡張される。具体的には、svc_init要素について新たな属性検索が定義され、位置サーバに送信された要求メッセージが検索要求メッセージであるか否かを表わすように構成される。属性の値が真（true）であるならば、それは要求メッセージが検索要求メッセージであることを示し、属性の値が偽（false）であるならば、それは要求メッセージが位置情報の要求メッセージであることを示す。
【００９７】
ステップ５０５において、位置サーバは条件検索を実行し、基準対象に関する情報を問い合わせ、基準対象および第１の評価条件に関する情報に従って第１の評価条件を満たす評価対象を検索する。
【００９８】
具体的には、広告移動局の位置がまず決定され、広告移動局の位置に従って広告移動局から１０００ｍの範囲内で離れている人が決定され、位置サーバ内のユーザ情報データベース内の情報に従って広告移動局から１０００ｍの範囲内で離れている人がさらに選択され、音楽を含む趣味を有する人が選択される。
【００９９】
さらに、位置サーバは、ユーザが位置情報を公開するか否か選択する機能も提供する。ユーザが位置情報を公開することを選択するならば、位置情報を公開する対象をさらに指示することが可能であり、例えば、評価を受信し、広告を受信し、ユーザが位置情報を公開することを選択したときのみ位置サーバはそのユーザを検索要求メッセージの検索対象に挙げることができる。位置サーバによって検索要求メッセージを処理する時間を減少させるために、位置情報を公開することを望むユーザについて、位置サーバはユーザの位置情報を特定の地図領域にマッピングし、従って、検索要求メッセージを受信した後、位置サーバは誰がある領域の範囲内に存在するかを迅速に決定することができる。さらに、位置サーバは、ユーザの共通に使用される基本情報を記憶するように構成されたユーザ情報記憶データベースを提供し、それによって、位置の相対的な評価条件を満たす人がさらに選択され、そして、ＣＢＵＳサーバが、ユーザ情報を記憶する他のデータベース（例えば、共有プロファイルＸＤＭＳ）から関係する情報を取得することを防止し、それによって、ＣＢＵＳサーバとサービスエンジンの間で過度のトラフィックの交信を防止するが、ユーザ情報は位置サーバにおいてのみ使用され、個人情報である。ユーザ情報を記憶するデータベースがＸＤＭＳによって実現されるならば、各ユーザの共通に使用される基本情報は１つのｘｍｌドキュメントによって表わすことができ、それは次に表わされている通りである。
<?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>
【０１００】
ステップ５０６において、ＣＢＵＳサーバは、位置サーバによって返信された第１の評価条件を満たす評価対象を受信し、このステップにおいて返信されるメッセージはステップ５０４に対応する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>
“条件を満たすユーザ１”
<msid type=' SIP_URI '>user2@example.com </msid>
“条件を満たすユーザ２”
<msid type=' SIP_URI '>user3@example.com </msid>
“条件を満たすユーザ３”
…
<msid type=' SIP_URI '>user278@example.com </msid>
“条件を満たすユーザ２７８”
</msids>
</slia>
</svc_result>
【０１０１】
ステップ５０６が実行された後、ＣＢＵＳサーバは、第２の評価条件および評価設定に従って関係するサービスエンジンから第１の評価条件を満たす評価対象に関する情報を取得し、それによって、評価結果を取得する。本実施形態において、第２の評価条件はＩＭサービス接続中であり、評価結果は次のステップによって取得される。
【０１０２】
ステップ５０７において、ＣＢＵＳサーバは、プレゼンス情報を取得する、具体的には、ステップ５０５において選択された人がＩＭサービス接続中であるか否かを表わすプレゼンス情報を取得する要求メッセージをプレゼンスサーバに送信し、その要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【０１０３】
ステップ５０８において、プレゼンスサーバはプレゼンス情報をＣＢＵＳサーバに返信し、返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１０４】
ステップ５０９において、ＣＢＵＳサーバは受信されたプレゼンス情報を判定し、ＩＭ接続中である人、すなわち、第２の評価条件を満たす評価対象を選択し、それによって、評価結果を取得する。
【０１０５】
ステップ５１０において、ＣＢＵＳサーバは評価結果を広告移動局に送信する。送信されるメッセージはSIP NOTIFYの実現方式を採用することができ、それは次に表わされている通りである。
NOTIFY sip:advertiser@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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" /> “評価結果１”
<entry uri="sip:user5@example.com" /> “評価結果２”
<entry uri="sip:user11@example.com" /> “評価結果３”
…
<entry uri="sip:user128@example.com" /> “評価結果４５”
</list>
</resource-lists>
【０１０６】
さらに、ステップ５０１における評価要求メッセージは<result_min>要素および<result_max>要素、すなわち、相対的な評価条件において設定された評価結果の数の上限（200）および下限（50）を含み、ＣＢＵＳサーバは、評価結果を返信する前に、評価結果をカウントする。評価結果の数が５０より小さいならば、ＣＢＵＳサーバは、評価結果の数が５０に到達するまで、広告移動局によって設定された評価間隔（<eva_interval>要素）に従ってリアルタイムな評価を実行し、そして、評価結果を広告移動局に通知し、一方、今回の評価結果の数が２００より大きいならば、ＣＢＵＳサーバは、複数回、評価結果を広告移動局に通知し、毎回返信される評価結果の数は多くても２００である。
【０１０７】
ステップ５１１において、広告移動局はステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１０８】
本実施形態はリアルタイムな評価方法を採用し、それによって、ＣＢＵＳサーバは、評価期間<eva_duration>が到達されるまで、評価間隔<eva_interval>に従って周期的な評価を実行する。
【０１０９】
さらに、本実施形態はステップ５０４からステップ５０９の実行順序に限定されず、評価対象のプレゼンス情報をまず取得することが可能であり、ＩＭ接続中である人が選択され、そして、相対的な評価条件を満たす評価対象がさらに検索される。
【０１１０】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、および評価設定を指示し、広告移動局の位置情報は位置サーバから取得され、相対的な評価条件を部分的に満たす評価対象が検索され、プレゼンスサーバから取得されたプレゼンス情報に従って相対的な評価条件を完全に満たす評価対象がさらに検索され、それによって、評価結果を取得する。本実施形態において、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、広告移動局の位置は動的に変更され、ＣＢＵＳサーバは広告移動局の変更された位置情報を自動的に取得し、それによって、相対的な評価条件が手動で変更された後の不都合な結果を防止する。
【０１１１】
図７は、本発明の第７実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ＣＢＵＳサービスは単位としてグループを使用する評価機能をサポートする。ユーザＡはＣＢＵＳサービスによって３つの生成されたグループを評価することを意図し、それによって、相対的な評価条件を満たす最大の人数を有するグループについて３つのグループを検索する。３つのグループのSIP URIはそれぞれsip:group1@example.com、sip:group2@example.com、およびsip:group3@example.comであり、相対的な評価条件は、地理的な位置がユーザＡから５００ｍの範囲内で離れていることであり、活動状態は買物中である。図７を参照すると、本実施形態の方法は具体的には次のステップを含む。
【０１１２】
ステップ６０１において、ユーザＡは端末上のＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含む。相対的な評価条件は、地理的な位置がユーザＡから５００ｍの範囲内で離れていることであり、活動状態は買物中であり、評価対象は３つのグループであり、評価設定は１回の評価であり、ここで、相対的な評価条件は基準対象がユーザＡであることを指示する。
【０１１３】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?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"/> “評価対象１”
<rl:entry uri="sip:group2@example.com"/> “評価対象２”
<rl:entry uri="sip:group3@example.com"/> “評価対象３”
</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> “１回の評価を表わす”
</cr:actions>
</cr:rule>
</cr:ruleset>
</ls:list-service>
</cbusreq>
【０１１４】
メッセージ本体の<location>要素および<presence>要素は、それぞれ、位置情報に基づく相対的な評価条件およびプレゼンス情報に基づく相対的な評価条件を表わすように構成される。<result_urilist>の値は、相対的な評価条件を満たす最大の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたmost（最大）とすることが可能であり、また、この要素の値は、相対的な評価条件を満たす最小の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたleast（最小）とすることが可能である。
【０１１５】
ステップ６０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【０１１６】
ステップ６０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【０１１７】
このステップにおいて、ＣＢＵＳサーバは、３つのグループのグループ識別情報に従って関係する情報源（例えば、共有グループＸＤＭＳ）からグループメンバーのリスト情報を取得する。
【０１１８】
ステップ６０４において、ＣＢＵＳサーバはグループメンバーの活動状態の情報を取得する要求メッセージをプレゼンスサーバに送信し、それによって、３つのグループにおける全てのメンバーの活動状態の情報を取得することを要求する。この要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【０１１９】
ステップ６０５において、プレゼンスサーバはグループメンバーの活動状態の情報をＣＢＵＳサーバに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１２０】
ステップ６０６において、ＣＢＵＳサーバは買物中である活動状態の情報を有するグループメンバーを選択する。
【０１２１】
ステップ６０７において、ＣＢＵＳサーバは評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザＡおよびステップ５０６において選択されたグループメンバーの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【０１２２】
ステップ６０８において、位置サーバは位置情報をＣＢＵＳサーバに返信する。
【０１２３】
ステップ６０９において、ＣＢＵＳサーバは、受信された位置情報に従ってユーザＡとステップ６０６において選択されたグループメンバーの間の距離を計算し、ユーザＡから５００ｍの範囲内で離れているグループメンバーを取得し、３つのグループにおいて条件を満たす人数をそれぞれカウントし、条件を満たす最大の人数を有するグループがsip:group2@example.comであることを取得する。
【０１２４】
ステップ６１０において、ＣＢＵＳサーバは評価結果をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１２５】
ステップ６１１において、ＣＢＵＳクライアントはステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１２６】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示する。まず、グループメンバーの活動状態の情報がプレゼンスサーバから取得され、買物中である活動状態を有するグループメンバーが選択され、そして、ユーザＡおよび買物中である活動状態を有するグループメンバーの位置情報が位置サーバから取得され、ユーザＡからの距離が計算され、各グループにおいて条件を満たす人数がカウントされ、それによって、評価結果を取得する。本実施形態において、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、本実施形態において、ＣＢＵＳサーバはグループ選択機能をサポートし、従って、評価方法の応用範囲が拡張される。
【０１２７】
図８は、本発明の第８実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザＡは、ＣＢＵＳサービスによって顧客Ｂおよび顧客Ｃから５００ｍの範囲内で離れている地理的な位置を有する同僚を見つけることを意図する。顧客Ｂおよび顧客ＣのSIP URIは、それぞれ、sip:b@example.comおよびsip:c@example.comであり、相対的な評価条件は、地理的な位置が顧客Ｂおよび顧客Ｃから５００ｍの範囲内で離れていることであり、評価設定は１回の評価であり、評価対象はユーザＡの同僚であり、ここで、ユーザＡの同僚のSIP URIは、それぞれ、sip:f1@example.com、sip:f2@example.com、…、およびsip:fn@example.comであると仮定する。図８を参照すると、本実施形態の方法は次のステップを含む。
【０１２８】
ステップ７０１において、ユーザＡは端末上のＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含み、相対的な評価条件は、基準対象が顧客Ｂおよび顧客Ｃであることを指示する。
【０１２９】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?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"/> “評価対象１”
<cr:one id="sip:f2@example.com"/> “評価対象２”
…
<cr:one id="sip:fn@example.com"/> “評価対象ｎ”
</cr:identity>
<focus> “基準対象を表わす”
<cr:one id="sip:b@example.com"/> “基準対象１”
<cr:one id="sip:c@example.com"/> “基準対象２”
</focus>
<radius>500m</radius> “範囲が５００ｍであることを表わす”
</cr:conditions>
<cr:actions> “評価設定を表わす”
<eva_type>once</eva_type> “１回の評価を表わす”
</cr:actions>
<cr:transformations> “評価結果の設定を表わす”
<provide-urilist>true</provide- urilist>
“URIリストを返信することをサーバが要求されていることを表わす”
</cr:transformations>
</cr:rule>
</cbus_req>
【０１３０】
メッセージ本体の<identity>要素は評価対象を表わすように構成され、<focus>要素は基準対象を表わすように構成され、<provide-urilist>要素の値は真（true）であり、これはURIリストの形式で評価結果を返信することをＣＢＵＳサーバが要求されていることを表わすように構成される。
【０１３１】
ステップ７０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK 応答メッセージをＣＢＵＳクライアントに返信する。
【０１３２】
ステップ７０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【０１３３】
ステップ７０４において、ＣＢＵＳサーバは、評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザＡの同僚、顧客Ｂ、および顧客Ｃの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【０１３４】
ステップ７０５において、位置サーバは位置情報をＣＢＵＳサーバに返信する。
【０１３５】
ステップ７０６において、ＣＢＵＳサーバは、受信された位置情報に従って各々の評価対象（ユーザＡの同僚）と顧客Ｂの間の距離、および各々の評価対象と顧客Ｃの間の距離をそれぞれ計算し、相対的な評価条件を満たす評価対象がsip:f2@example.comであることを取得する。
【０１３６】
ステップ７０７において、ＣＢＵＳサーバは評価結果をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１３７】
ステップ７０８において、ＣＢＵＳクライアントはステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１３８】
本実施形態において、評価要求メッセージは、複数の基準対象、相対的な評価条件、評価設定、および評価対象を指示し、ユーザＡの同僚、顧客Ｂ、および顧客Ｃの位置情報は位置サーバから取得され、相対的な評価条件を満たす評価対象が取得され、それによって、評価結果を取得する。本実施形態において、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。さらに、本実施形態におけるＣＢＵＳサーバは複数の基準対象を有する評価方法をサポートし、ユーザまたはアプリケーションの設定に従って異なる基準対象を動的に選択することが可能であり、それによって、相対的な評価条件の設定がより柔軟になる。
【０１３９】
図９は、本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。図９を参照すると、本実施形態のシステムは、サーバ１およびクライアント２を含み、さらに、情報源３を含むことが可能である。
【０１４０】
クライアント２は評価要求メッセージをサーバ１に発信する。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。相対的な条件評価に関する情報が評価対象を含むならば、サーバ１は、評価要求メッセージに従って情報源３から相対的な評価条件において指示された基準対象に関する情報および評価対象に関する情報（この２つに関する情報は相対的な条件評価のために要求される情報である）を取得し、この２つに関する情報を比較し、評価結果を取得し、この評価結果をクライアント２に送信する。相対的な条件評価に関する情報が評価対象を含まないならば、サーバ１は、基準対象および／または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源３に送信し、情報源３は、基準対象に関する情報に従って相対的な評価条件（すなわち、相対的な条件評価のために要求される情報）を満たす評価対象を検索し、この評価対象をサーバ１に送信し、サーバ１は、相対的な評価条件を満たす評価対象に従って評価結果を取得し、この評価結果をクライアント２に送信する。
【０１４１】
さらに、図９に表わされているように、本実施形態のクライアント２は、以下の本発明の実施形態のクライアントにおける任意のクライアントとすることが可能であり、サーバ１は、以下の本発明の実施形態のサーバにおける任意のサーバとすることが可能である。
【０１４２】
図１０は、本発明の一実施形態によるクライアントの構成図である。図１０を参照すると、本実施形態のクライアントは、第２送信モジュール２１および第２送信モジュール２２を含む。第２送信モジュール２１は評価要求メッセージを送信するように構成される。第２受信モジュール２２は評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は、相対的な評価条件および／または評価対象および／または評価設定を含み、または、参照パス情報を含み、参照パス情報は相対的な評価条件および／または評価対象および／または評価設定の記憶位置を指示する。
【０１４３】
図１１は、本発明の一実施形態によるサーバの構成図である。図１１を参照すると、本実施形態のサーバは、第１受信モジュール１１、条件取得モジュール１２、情報取得モジュール１３、および処理／送信モジュール１４を含む。第１受信モジュール１１は評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。条件取得モジュール１２は評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。情報取得モジュール１３は評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。処理／送信モジュール１４は相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【０１４４】
相対的な条件評価に関する情報が相対的な評価条件を含むならば、条件取得モジュール１２は、さらに、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得するように構成される。
【０１４５】
相対的な条件評価に関する情報が参照パス情報であるならば、条件取得モジュール１２は、さらに、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
【０１４６】
評価要求メッセージが解析され、または、相対的な評価条件が取得されるとき、評価対象がさらに取得される。情報取得モジュール１３は、さらに、第３送信モジュール１５および第３受信モジュール１６を含む。第３送信モジュール１５は評価対象に関する情報および基準対象に関する情報を取得する要求メッセージを情報源３に送信するように構成される。第３受信モジュール１６は情報源３によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成される。第３送信モジュール１５および第３受信モジュール１６は通信によって接続され、正確には、情報源３を介して通信によって接続されることも可能である。
【０１４７】
処理／送信モジュール１４は相対的な評価条件に従って評価対象に関する情報を基準対象に関する情報と比較し、評価結果を取得し、その評価結果をクライアントに送信するように構成されることが可能である。
【０１４８】
さらに、情報取得モジュール１３は第４送信モジュール１７および第４受信モジュール１８を含むことも可能である。第４送信モジュール１７は、取得された相対的な評価条件および相対的な評価条件において指示された基準対象に従って基準対象および／または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源３に送信するように構成される。第４受信モジュール１８は情報源３によって返信された相対的な評価条件を満たす評価対象を受信するように構成され、相対的な評価条件を満たす評価対象は相対的な条件評価のために要求される情報であり、また、評価結果である。第４送信モジュール１７は通信によって第４受信モジュール１８に接続され、正確には、情報源３を介して通信によって接続されることも可能である。
【０１４９】
本発明の実施形態による相対的な条件評価を実現するシステム、クライアント、およびサーバにおいて、相対的な評価条件が取得され、基準対象は相対的な評価条件において指示され、それによって、基準対象に関する情報は評価のための基礎として使用され、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、基準対象の状態に従って評価が実行される。
【０１５０】
この技術分野の当業者は、本発明の実施形態による方法のステップの全部または一部がプログラム命令関連ハードウェアによって実現されることが可能であることを理解すべきである。プログラムはコンピュータ読み取り可能な記憶媒体に記憶されることが可能である。プログラムが実行されるとき、本発明の実施形態による方法のステップが実行される。記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、または光ディスクのようなプログラムコードを記憶することが可能な任意の媒体とすることが可能である。
【０１５１】
最後に、上記の実施形態は本発明の技術的解決手段を説明するために提供されたにすぎず、本発明を限定することを意図していないことに留意すべきである。上記実施形態に関して本発明が詳細に説明されたが、修正または置換が該当する技術的解決手段の要旨を本発明の思想および範囲から逸脱させない限り、上記実施形態に記載された技術的解決手段に修正を行うことができ、または、技術的解決手段におけるいくつかの技術的特徴に等価な置換を行うことができることをこの技術分野の当業者は理解すべきである。
【符号の説明】
【０１５２】
１ サーバ
２ クライアント
３ 情報源
１１ 第１受信モジュール
１２ 条件取得モジュール
１３ 情報取得モジュール
１４ 処理／送信モジュール
１５ 第３送信モジュール
１６ 第３受信モジュール
１７ 第４送信モジュール
１８ 第４受信モジュール
２１ 第２送信モジュール
２２ 第２受信モジュール
【技術分野】
【０００１】
本発明は通信の分野に関し、より詳しくは相対的な条件評価を実現する方法、システム、サーバ、およびクライアントに関する。
【０００２】
本願は、２００８年７月７日に出願され、発明の名称を「相対的な条件評価を実現する方法、システム、サーバ、およびクライアント」とする中国特許出願第２００８１０１３０５５７．１号の優先権を主張し、その全体を引用してここに組み込む。
【背景技術】
【０００３】
サービスを開始する前に、現在のサービスの受け手がそのサービスに参加するために適切であるか否かを知るために、ユーザまたはあるアプリケーションはサービスの受け手の現在の状態（status）を評価することができ、それによって、サービス開始の効率性を向上させ、通信リソースの浪費を防止する。条件を基にしたユニフォームリソース識別選択（Condition Based Uniform resource identification Selection（ＣＢＵＳ））サービスは、評価機能を提供することを目的とし、評価要求者の要望に従って相対的な評価条件を満たす対象を提供することができる。
【０００４】
グループセッションを確立するサービスを一例にすると、グループセッションを確立する方法は次のステップを含む。サービスサーバは、グループセッション要求を受信し、そのグループセッション要求における情報に従ってグループメンバーのリストおよびセッション確立条件を取得する。サービスサーバは、グループメンバーのセッション確立条件に関する情報を取得し、取得した情報がセッション確立条件を満たすか否かを判定する。サービスサーバは、セッション確立条件を満たすグループメンバーのクライアントにグループセッション確立要求を発信し、グループセッションを確立する。先行技術における相対的な評価条件は次に表わされている通りである。
【０００５】
< 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 >
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実現において、発明者らは、先行技術が少なくとも次の問題を有することを発見した。先行技術において、評価対象の情報のみが評価される、すなわち、評価要求者は評価対象のある状態が固定値を満たすことを指示することが必要である。評価要求者が固定値を指示しなかった場合、または、ある基準対象の状態に従って評価を実行することを意図する場合、または、相対的な評価条件が動的に変更される場合、先行技術においては評価が実現できない。
【課題を解決するための手段】
【０００７】
本発明は、相対的な条件評価を実現する方法、システム、サーバ、およびクライアントを提供し、それによって、評価要求者が、評価対象のある状態が固定値を満たすことを指示しないとき、基準対象の状態に従って評価が実行されることが可能である。
【０００８】
一実施形態において、本発明は、次のステップを含む相対的な条件評価を実現する方法を提供する。
評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【０００９】
一実施形態において、本発明は、クライアントおよびサーバを含む相対的な条件評価を実現するシステムを提供する。
クライアントは、評価要求メッセージを送信し、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
サーバは、受信された評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果をクライアントに送信するように構成される。
【００１０】
一実施形態において、本発明は、第２送信モジュールおよび第２受信モジュールを含むクライアントを提供する。
第２送信モジュールは評価要求メッセージをサーバに送信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。
第２受信モジュールは、評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。
【００１１】
一実施形態において、本発明は、第１受信モジュール、条件取得モジュール、情報取得モジュール、および処理／送信モジュールを含むサーバを提供する。
第１受信モジュールは、評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。
条件取得モジュールは、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
情報取得モジュールは、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。
処理／送信モジュールは、相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【００１２】
本発明の実施形態において、相対的な評価条件が取得され、相対的な評価条件は基準対象を指示し、それによって、基準対象に関する情報が評価のための基礎として使用され、基準対象の状態に従って評価が実行される。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１実施形態による相対的な条件評価を実現する方法のフローチャートである。
【図２】本発明の第２実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図３】本発明の第３実施形態による相対的な条件評価を実現する方法の第１の場合のシグナリングフローチャートである。
【図４】本発明の第４実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図５】本発明の第５実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図６】本発明の第６実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図７】本発明の第７実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図８】本発明の第８実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。
【図９】本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。
【図１０】本発明の一実施形態によるクライアントの構成図である。
【図１１】本発明の一実施形態によるサーバの構成図である。
【発明を実施するための形態】
【００１４】
図１は、本発明の第１実施形態による相対的な条件評価を実現する方法のフローチャートである。図１を参照すると、本実施形態の方法は具体的には次のステップを含む。
ステップ１０１において、評価要求メッセージが受信され、評価要求メッセージは相対的な条件評価に関する情報を含む。
ステップ１０２において、評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象が取得される。
ステップ１０３において、評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報が取得される。
ステップ１０４において、相対的な条件評価のために要求される情報に従って評価結果が取得および送信される。
【００１５】
さらに、ステップ１０１における相対的な条件評価に関する情報は相対的な評価条件とすることが可能であり、すなわち、相対的な評価条件は評価要求メッセージ内にカプセル化され、従って、ステップ１０２において、具体的には、評価要求メッセージが解析され、相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。
【００１６】
ステップ１０１における相対的な条件評価に関する情報は参照パス情報とすることも可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ１０１の前に、相対的な評価条件が記憶位置において記憶される。ステップ１０２において、具体的には、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件において指示された基準対象が取得される。具体的には、相対的な評価条件が予め定義されることが可能である。ユーザまたはアプリケーションは、特定の記憶位置、例えば、共有の拡張マークアップ言語データ管理サーバ（ＸＤＭＳ）またはＣＢＵＳサーバ内の記憶空間において予め定義された相対的な評価条件を記憶させる。このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは、相対的な評価条件の参照パスを指示する必要がある。
【００１７】
本実施形態において、相対的な評価条件が取得され、相対的な評価条件は相対的な条件評価の基準対象を指示し、それによって、基準対象に関する情報が評価の基礎として使用され、基準対象の状態に従って相対的な条件評価が実行される。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶することが可能であり、相対的な評価条件は評価要求メッセージにおいて伝送することが可能であり、それによって、評価の効率性を向上させる。
【００１８】
図２は、本発明の第２実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ＣＢＵＳサービスが例とされ、これに伴う装置は、ＣＢＵＳクライアント、ＣＢＵＳサーバ、および関係するサービスエンジンを含む。図２に表わされているように、本実施形態の方法は具体的には次のステップを含む。
【００１９】
ステップ２０１において、ＣＢＵＳクライアントは、評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは、相対的な評価条件および相対的な評価条件において指示された基準対象を含み、さらに、評価対象および／または評価設定を含み、評価対象および評価設定はオプションの情報とすることが可能である。
【００２０】
相対的な評価条件は、次の２つの例とすることが可能である。一例において、相対的な評価条件は相対的な条件のみを含み、他の例において、相対的な評価条件は相対的な条件と評価対象の条件の組み合わせを含む。さらに、ＣＢＵＳサーバは、主に、位置情報、プレゼンス情報、および評価対象の共有ＸＤＭＳ内の情報に従って評価を実行し、それによって、相対的な評価条件は、３種類の情報のうち１つまたは複数に対応する部分によって表わすことが可能である。さらに、相対的な評価条件は、ＣＢＵＳサーバが評価対象の情報を基準対象の情報と比較すべきであることを示し、従って、相対的な評価条件は基準対象を指示する。すなわち、基準対象は相対的な評価条件に含まれる。
【００２１】
基準対象は、評価要求の発信者または評価要求の発信者によって指示された他のものとすることが可能である。基準対象の数は１つまたは複数とすることが可能である。評価手順の間、基準対象は固定され、または、変更されることが可能であり、例えば、ＣＢＵＳサーバはＣＢＵＳクライアントの事前設定に従って異なる条件のもとで異なる基準対象を動的に選択する。
【００２２】
評価対象は１人のユーザ、複数のユーザ（例えば、あるグループ）とし、または、単位としてグループ（すなわち、複数のグループ）を使用することが可能である。ＣＢＵＳサービスはグループ選択機能をサポートし、評価要求者によって指示された複数のグループを評価し、相対的な評価条件を満たすグループを選択する
【００２３】
評価設定は、主に、１回の評価、リアルタイムな評価、終了の評価（評価された対象が相対的な評価条件を満たすとき評価が終了する）、および他の形態を含む。さらに、ＣＢＵＳは、ＣＢＵＳクライアントが、自身の要求に従ってＣＢＵＳサーバによって返信された評価結果の数の上限および下限を設定することをサポートし、例えば、相対的な評価条件を満たす現在の評価対象の数が下限に到達していないならば、ＣＢＵＳサーバは、その数が下限に到達するまで評価を実行し続け、評価結果を返信し、ＣＢＵＳサーバによって返信される結果の数は上限を超えない。
【００２４】
このステップにおいて、ＣＢＵＳクライアントは、ポリシーの評価、実施、および管理（policy evaluation, enforcement and management（ＰＥＥＭ））の呼び出し可能インタフェース（以下、ＰＥＭ−１と呼ぶ）によって評価要求メッセージをＣＢＵＳサーバに送信することが可能である。さらに、本実施形態において、ＣＢＵＳクライアントとＣＢＵＳサーバの間の交信は、ＰＥＭ−１インタフェースによって実現することが可能である。具体的には、ＰＥＥＭは、運営者によって設定され、サービスプロバイダおよびアプリケーション開発者によって指示された、端末ユーザのプリファレンス設定におけるポリシーを評価、実施、および管理することによってリソースの保護および管理を実現するフレームワークであり、インタフェースＰＥＭ−１はポリシー評価のために定義される。ＰＥＭ−１インタフェースによってＰＥＥＭからポリシー処理リソースが要求されるとき、各種リソースの差異のために該当するポリシーは異なり、それによって、ＰＥＭ−１入力情報および出力情報は異なり、入力パラメータおよび出力パラメータも異なる。ＰＥＭ−１は汎用インタフェースであり、異なるポリシーのために異なる独立のインタフェースを設定することは不可能であり、それによって、ＰＥＭ−１テンプレートによって問題を解決することができ、すなわち、構造を要求および応答することが指定される。ＰＥＭ−１テンプレートにおいて、ポリシーを処理するように構成されたどの入力ＰＥＭ−１パラメータが評価要求者によって提供されるか、ポリシーが処理された後、どの出力ＰＥＭ−１パラメータが評価要求者のために生成されるかが定義され、すなわち、基本入力および出力パラメータが定義され、具体的な要求に従ってパラメータが拡張されることがサポートされる。オプションで、本実施形態において、インタフェースは再利用することができ、ＣＢＵＳクライアントとＣＢＵＳサーバの間の交信は、ＰＥＭ−１インタフェースの入力および出力テンプレートパラメータを拡張することによって実現される。
【００２５】
ステップ２０２において、ＣＵＢＳサーバは、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得し、さらに、評価対象および評価設定を取得する。
【００２６】
オプションで、ステップ２０１における評価要求メッセージは、参照パス情報を含むことが可能であり、これは相対的な評価条件の記憶位置を示し、従って、ステップ２０１の前に、記憶位置において相対的な評価条件が記憶される。ステップ２０２において、具体的には、相対的な評価条件および相対的な評価条件において指示された基準対象が参照パス情報に対応する記憶位置から取得され、オプションで、評価対象および評価設定も取得することが可能である。具体的には、相対的な評価条件、評価対象、および／または、評価設定は予め定義することが可能であり、ユーザまたはアプリケーションは予め定義された相対的な評価条件、評価対象、および／または、評価設定を特定の記憶位置、例えば、共有ＸＤＭＳ、または、ＣＢＵＳサーバ内の記憶空間に記憶させ、このようにして、評価要求を発信するとき、ユーザまたはアプリケーションは参照パスのみ指示する必要がある。
【００２７】
ステップ２０３において、ＣＢＵＳサーバは評価対象に関する情報および基準対象に関する情報を取得し、これは具体的には次のステップを含む。
【００２８】
ステップ２０３１において、ＣＢＵＳサーバは、評価対象および基準対象に関する情報を取得する要求メッセージを（本実施形態において具体的にはサービスエンジンである）情報源に送信し、要求メッセージは評価要求の発信者の識別情報を伝送することが可能である。
【００２９】
本発明の実施形態において、サービスエンジンは、限定しないが、位置エンジン、プレゼンスエンジン、および共有ＸＤＭＳエンジンを含む。
【００３０】
さらに、ＣＢＵＳサーバは、相対的な評価条件に従って同一の情報源から評価対象および基準対象に関する情報を取得することが可能であり、または、異なる情報源から評価対象および基準対象に関する情報を取得することが可能である。
【００３１】
ステップ２０３２において、サービスエンジンは、評価対象および基準対象に関する情報をＣＢＵＳサーバに返信する。
【００３２】
ステップ２０３１とステップ２０３２の間に、サービスエンジンは、評価要求の発信者の識別情報に従って評価要求の発信者について識別情報の確認を実行する。具体的には、ＣＢＵＳサーバによって送信された評価対象および基準対象に関する情報を取得する要求メッセージを受信するとき、サービスエンジン（例えば、プレゼンスエンジンまたは位置エンジン）は、（本実施形態においてＣＢＵＳクライアントである）評価要求の発信者を認証することが可能である。ＣＢＵＳサーバがＳＩＰプロトコルによってサービスエンジンとの交信を実現する、例えば、SIP subscribe/notifyメソッドによってプレゼンス情報を取得するならば、評価要求の発信者の識別情報を表わすIdentityおよびIdentity-Infoである２つのヘッダフィールドはサービスエンジンに送信される要求メッセージ内で伝送され、それによって評価要求の発信者の識別情報を示し、Identityフィールドは識別情報の確認の署名のために適合し、Identity-Infoは署名者の証明書の参照である。ＣＢＵＳサーバが他のプロトコルによってサービスエンジンと交信を実現する、例えば、ＨＴＴＰプロトコルによって位置エンジンと交信して位置情報を取得するならば、ＳＩＰプロトコルにおけるIdentityおよびIdentity-Infoと同じ機能を有するフィールドがそのプロトコルにおいて拡張され、それによって評価要求の発信者の識別情報を伝送する。評価要求の発信者の識別情報に従って、サービスエンジンは評価要求の発信者について識別情報の確認を実行する。
【００３３】
ステップ２０４において、ＣＢＵＳサーバは、相対的な評価条件および評価設定に従って評価対象に関する情報を基準対象に関する情報と比較し、それによって評価結果を取得する。
【００３４】
ステップ２０５において、ＣＢＵＳサーバは、評価結果をＣＢＵＳクライアントに返信する。
【００３５】
本実施形態において、相対的な評価条件は相対的な条件を含む。相対的な評価条件が相対的な条件と評価対象の条件の組み合わせを含むならば、言い換えると、相対的な評価条件が第１の評価条件と第２の評価条件を含み、第１の評価条件は相対的な条件であり、第２の評価条件は評価対象の条件であり、評価対象の条件において、評価対象のある状態が固定値を満たすならばステップ２０４およびステップ２０５が具体的には次のステップを含むことが指示される。
【００３６】
ＣＢＵＳサーバは、相対的な条件に従って評価対象に関する情報を基準対象に関する情報と比較し、相対的な条件を満たす第１の評価対象を取得する。
【００３７】
ＣＢＵＳサーバは、（本実施形態において具体的にはサービスエンジンである）関係する情報源から第１の評価対象に関する情報を取得し、例えば、プレゼンスサーバから第１の評価対象のプレゼンス情報を取得する。
【００３８】
ＣＢＵＳサーバは第１の評価対象に関する情報を評価対象についての条件、すなわち、第２の評価条件と比較し、さらに、評価対象についての条件を満たす第２の評価対象を選択する。
【００３９】
ＣＢＵＳサーバは、第２の評価対象を評価結果としてＣＢＵＳクライアントに返信する。
【００４０】
本実施形態において、評価対象についての条件、すなわち、第２の評価条件を満たす評価対象がまず選択されることが可能であり、そして、相対的な条件、すなわち、第１の評価条件を満たす評価対象がさらに選択される。言い換えると、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの評価条件を評価するための順序は限定されない。
【００４１】
本実施形態において、評価要求メッセージは、基準対象および相対的な評価条件を指示し、さらに、評価設定および評価対象を含む。サービスエンジンから取得された基準対象に関する情報は評価のための基礎として使用される。相対的な評価条件が相対的な条件であるとき、評価の要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、２つの条件を満たす評価対象は順に選択され、それによって、相対的な条件評価はより柔軟である。さらに、本実施形態において、予め定義された相対的な評価条件は特定の記憶位置において記憶させることが可能であり、相対的な評価条件は評価要求メッセージ内で伝送されることが可能であり、それによって、評価の効率性を向上させる。
【００４２】
ステップ２０１においてＣＢＵＳサーバによって受信される評価要求メッセージは評価対象を含まないという点で、本発明の第３実施形態による相対的な条件評価を実現する方法は第２実施形態と異なる。本実施形態の方法は次の例とすることが可能である。
【００４３】
第１の例において、相対的な評価条件は相対的な条件のみを含み、基準対象に関する情報および検索される評価対象（すなわち、検索対象）に関する情報は、同一の情報源から取得される。具体的には、図３は、本発明の第３実施形態による相対的な条件評価を実現する方法の第１の場合のシグナリングフローチャートである。図３を参照すると、ステップ２０１はステップ２０１Ａによって置き換えることが可能であり、ＣＢＵＳクライアントは、相対的な評価条件を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４４】
ステップ２０３Ａにおいて、ＣＢＵＳサーバは、相対的な評価条件および基準対象を伝送する検索要求メッセージを（具体的にはサービスエンジンである）情報源に送信する。ステップ２０３Ｂにおいて、サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および相対的な評価条件に従って相対的な評価条件を満たす評価対象を検索する。ステップ２０３Ｃにおいて、相対的な評価条件を満たす評価対象がＣＢＵＳサーバに返信される。ステップ２０３Ｄにおいて、ＣＢＵＳサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【００４５】
第２の例において、相対的な評価条件が相対的な条件のみを含み、基準対象に関する情報および検索対象に関する情報が異なる情報源から取得されるならば、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４６】
ＣＢＵＳサーバは、基準対象に関する情報を第１の情報源から取得する。ＣＢＵＳサーバは、相対的な評価条件および基準対象に関する情報を伝送する検索要求メッセージを第２の情報源に送信する。第２の情報源は、相対的な評価条件および基準対象に関する情報に従って相対的な評価条件を満たす評価対象を検索し、評価対象をＣＢＵＳサーバに返信する。ＣＢＵＳサーバは、相対的な評価条件を満たす返信された評価対象を評価結果として受信する。
【００４７】
第３の例において、相対的な評価条件が相対的な条件（第１の評価条件）と評価対象の条件（第２の評価条件）の組み合わせであるならば、第２の評価条件において評価対象の条件が固定値を満たすことが指示され、基準対象に関する情報および検索対象に関する情報が同一の情報源から取得される。本実施形態において、相対的な条件を満たす評価対象はサービスエンジンから検索され、そして、サーバは、さらに、検索対象の条件を満たす評価結果を選択する。具体的には、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００４８】
ＣＢＵＳサーバは、第１の評価条件および基準対象を伝送する検索要求メッセージを（具体的にはサービスエンジンである）情報源に送信する。サービスエンジンは、基準対象に関する情報を問い合わせ、基準対象に関する情報および第１の評価条件に従って第１の評価条件を満たす第１の評価対象を検索する。ＣＢＵＳサーバは、サービスエンジンによって返信された第１の評価条件を満たす第１の評価対象を受信する。ＣＢＵＳサーバは、第１の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。ＣＢＵＳサーバは、第１の評価対象に関する情報を第２の評価条件において指示された固定値と比較し、第２の評価条件を満たす第２の評価対象を評価結果として取得する。
【００４９】
第３の例において、ＣＢＵＳサーバは、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することも可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの条件を評価するための順序は限定されない。
【００５０】
第４の例において、相対的な評価条件が相対的な条件（第１の評価条件）と評価対象の条件（第２の評価条件）の組み合わせであり、基準対象に関する情報および評価対象に関する情報が異なる情報源から取得されるならば、ステップ２０３およびステップ２０４は次のステップによって置き換えることが可能である。
【００５１】
ＣＢＵＳサーバは、基準対象に関する情報を第１の情報源から取得する。ＣＢＵＳサーバは、第１の評価条件および基準対象に関する情報を伝送する検索要求メッセージを第２の情報源に送信する。第２に情報源は、第１の評価条件および基準対象に関する情報に従って第１の評価条件を満たす第１の評価対象を検索し、第１の評価対象をＣＢＵＳサーバに返信する。ＣＢＵＳサーバは、第１の評価対象に関する情報、例えば、プレゼンス情報を他のサービスエンジンから取得する。ＣＢＵＳサーバは、第１の評価対象に関する情報を第２の評価条件において指示された固定値と比較し、第２の評価条件を満たす第２の評価対象を評価結果として取得する。
【００５２】
第４の例において、ＣＢＵＳサーバは、まず、評価対象に関する情報を他のサービスエンジンから取得し、評価対象の条件を満たす評価対象を選択し、そして、さらに、相対的な条件を満たす評価対象を検索することが可能である。すなわち、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせである場合、本実施形態において２つの条件を評価するための順序は限定されない。
【００５３】
本実施形態において、評価要求メッセージは基準対象、相対的な評価条件、および評価設定を指示する。基準対象に関する情報は評価のための基礎として使用され、相対的な評価条件を満たす評価対象が取得される。相対的な評価条件が相対的な条件であるとき、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な評価条件が相対的な条件と評価対象の条件の組み合わせであるとき、２つの条件を満たす評価対象が順に選択され、それによって、相対的な条件評価はより柔軟である。
【００５４】
以下、具体的なシナリオを例として本発明の実施形態の技術的解決手段をさらに説明する。
【００５５】
図４は、本発明の第４実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態においてユーザＡはＣＢＵＳサービスの加入者である。ユーザＡは、他の都市の顧客を訪問した後、ＣＢＵＳサービスによって何人かの友人の中で最も近い友人を探して会うことを意図し、ユーザＡのSIP URIはsip:a@example.comであり、評価される友人のSIP URIはそれぞれsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであると仮定する。図４を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００５６】
ステップ３０１において、ユーザＡは端末上のＣＢＵＳクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置がユーザＡに最も近いことであり、評価対象はユーザＡの３人の友人であり、評価設定は１回の評価、すなわち、ＣＢＵＳサーバは条件を満たす１人の友人のURIのみ返信する必要がある。ＣＢＵＳクライアントは、ユーザＡの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、相対的な評価条件は（ユーザＡ、すなわち、本実施形態における評価要求の発信者である）基準対象を指示する。
【００５７】
この実施形態において、評価要求メッセージはHTTP GETの実現方式を採用することが可能であり、それは次に表わされている通りである。
GET cbusgroup@example.com HTTP/1.1
“第１行のコードは要求の行であり、GETは要求がHTTPにおけるGETメソッドを使用することを表わし、cbusgroup@example.comは要求が識別情報に対応する対象を評価することであることを表わし、識別情報は本実施形態においてグループURIであり、HTTP/1.1はプロトコルバージョンを表わす”
Host: cbus.example.com “要求されたリソースがＣＢＵＳサーバであることを表わす”
User-Agent: CBUS-client/OMA1.0
“評価要求を発信するユーザエージェントがＣＢＵＳクライアントであることを表わす”
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>
“ユーザＡが基準対象として使用され、ユーザＡに最も近いことを表わす”
</extPolicyVAL>
<eva_type>once</eva_type> “１回の評価を表わす”
</policyInputTemplate>
</policyInputData>
【００５８】
本実施形態において、ＣＢＵＳクライアントとＣＢＵＳサーバの間の情報交信はＰＥＥＭにおけるＰＥＭ−１インタフェースを再使用することによって、すなわち、ＰＥＭ−１インタフェースにおいて定義された入力および出力テンプレートパラメータを拡張することによって実現される。具体的には、相対的な評価条件は、インタフェースの定義における既存の<extPolicyVAL>要素を採用することによって伝送され、<focus>要素は基準対象、すなわち、ユーザＡのSIP URIを表わし、<filter>要素は規則を表わし、これはnearest（最も近い）またはfarthest（最も遠い）である値を有する列挙型であり、本実施形態において列挙型の値はnearestである。さらに、標準入力テンプレートに基づいて、文字列型であるパラメータ<eva_type>は評価設定を表わすように拡張され、この要素は、１回の評価（once）、リアルタイムな評価（realtime）、または終了の評価（until_cond_match）の値を有する列挙型であり、本実施形態においてこの要素の値はonceである。
【００５９】
ステップ３０２において、ＣＢＵＳサーバは、評価要求メッセージを受信し、その評価要求メッセージを解析し、評価対象、すなわち、その評価要求メッセージ内の要求URI（sip:cbus-group@example.com）に従ってSIP URIによって表わされるグループメンバー（f1、f2、およびf3）を取得し、相対的な評価条件は地理的な位置がユーザＡに最も近いこと、評価設定は１回の評価であることを取得する。
【００６０】
ステップ３０３において、ＣＢＵＳサーバは、基準対象のユーザＡおよび評価対象のf1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信する。
【００６１】
本実施形態において、要求メッセージは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>
“ユーザＡの識別情報”
<msid type=' SIP_URI '>f1@example.com </msid> “友人１の識別情報”
<msid type=' SIP_URI '>f2@example.com </msid> “友人２の識別情報”
<msid type=' SIP_URI '>f3@example.com </msid> “友人３の識別情報”
</msids>
<loc_type type='CURRENT'/>
“位置決めされるものの現在の位置情報が要求されることを表わす”
</slir>
</svc_init>
【００６２】
ステップ３０４において、位置サーバはユーザＡおよび３人の友人の位置情報をＣＢＵＳサーバに返信する。返信されるメッセージはステップ３０３に対応する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> “位置決めされるものＡの識別情報を表わす”
<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> “位置決めされるものｆ１の識別情報を表わす”
<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>
【００６３】
ステップ３０５において、ＣＢＵＳサーバは、受信された位置情報に従ってユーザＡと３人の友人の間の距離を計算し、比較によってユーザＡに現在最も近い友人はsip:f2@example.comであることを取得する。
【００６４】
ステップ３０６において、ＣＢＵＳサーバは、評価結果（すなわち、ユーザＡに現在最も近い友人のSIP URI:sip:f2@example.com）をＣＢＵＳクライアントに返信する。返信されるメッセージはステップ３０１に対応する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>
“評価結果は友人２であることを表わす”
</policyOutputTemplate>
</ policyOutputData >
【００６５】
このステップは、ステップ３０１に対応して、ＰＥＭ−１インタフェースによって定義される標準出力テンプレートパラメータを拡張すること、すなわち、ＣＢＵＳサーバによって返信された評価結果（URIリスト）を表わす配列型の新たなパラメータ<urilist>によって実現される。
【００６６】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、相対的な評価条件に従って該当するサービスエンジン、すなわち、本実施形態の位置サーバから基準対象の位置情報が取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者によって指示された評価対象に従って相対的な条件が評価され、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【００６７】
図５は、本発明の第５実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザＡは、ＣＢＵＳサービスによって、友人ｆ１、ｆ２、およびｆ３が友人Ｂの自宅住所に近いか否かを判断することを意図する。本実施形態は、基準対象が評価要求の発信者によって指示された他者であり、基準対象に関する情報および評価対象に関する情報は異なる情報源からのものである点で第４実施形態と異なる。ユーザＡのSIP URIはsip:a@example.comであり、友人ＢのSIP URIはsip:b@example.comであると仮定する。図５を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００６８】
ステップ４０１において、ユーザＡは端末上のＣＢＵＳクライアントによって相対的な評価条件、評価対象、および評価設定を設定し、相対的な評価条件は地理的な位置が友人Ｂから５００ｍの範囲内で離れていることであり、評価対象はユーザＡの３人の友人であり、評価設定は終了の評価である。ＣＢＵＳクライアントは、ユーザＡの設定に従って相対的な評価条件、評価設定、および評価対象を伝送する評価要求メッセージをＣＢＵＳサーバに送信し、相対的な評価条件は（本実施形態において友人Ｂである）基準対象を指示する。
【００６９】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用し、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“評価結果はSIP SUBSCRIBEによってＣＢＵＳサーバから配信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける１つの要求および応答を識別する順序番号”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Expires: 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 > “範囲が５００ｍであることを表わす”
</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" />
“評価対象１の識別情報を表わす”
<l:entry uri="sip:f2@example.com" />
“評価対象２の識別情報を表わす”
<l:entry uri="sip:f3@example.com" />
“評価対象３の識別情報を表わす”
</l:list>
</eva_object>
</cbus_req>
【００７０】
メッセージ本体の<cbus_req>要素は評価要求メッセージ内の情報を表わすように構成され、<cbus_req>要素は<eva_condition>および<eva_setting>である２つの部分要素を含み、それぞれ、相対的な評価条件および評価設定を表わすように構成される。<eva_condition>は、さらに、相対的な条件を表わすように構成された<rel_condition>部分要素を含み、<rel_condition>は位置情報に基づいて相対的な評価条件を表わすように構成された<location>部分要素を含み、ＣＢＵＳサーバは位置サーバから関係する情報を取得する。<focus>要素は相対的な条件の基準対象（友人Ｂ）を表わすように構成され、その値は友人ＢのSIP URIである。<radius>要素は範囲を表わすように構成され、すなわち、５００ｍの範囲内を表わし、２つの要素の値はユーザによってランダムに指示することが可能である。本実施形態において、評価方法を表わすように構成された<eva_type>部分要素がさらに定義され、この要素はonce、realtime、またはuntil_cond_matchedの値を有する列挙型であり、それぞれ、１回の評価、リアルタイムな評価、および終了の評価を表わすように構成され、本実施形態において<eva_type>の値はuntil_cond_matchedである。本実施形態において、評価要求メッセージによって具体的な評価対象のリストが伝送され、それによって、メッセージ本体の<eva_object>拡張要素は評価対象を表わすように構成され、評価対象のリストを表わす<list>部分要素を含み、リスト内の各々の評価対象は<entry>部分要素によって表わされる。
【００７１】
ステップ４０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【００７２】
ステップ４０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、評価対象がsip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comであること、相対的な評価条件が友人Ｂから５００ｍの範囲内で離れていること、評価設定が終了の評価であることを取得する。
【００７３】
ステップ４０４において、ＣＢＵＳサーバは、ユーザＢの自宅住所を取得する要求メッセージを共有プロファイルＸＤＭＳに送信し、このメッセージはHTTP POSTの実現方式を採用することが可能である。
【００７４】
ステップ４０５において、共有プロファイルＸＤＭＳはユーザＢの自宅住所をＣＢＵＳサーバに返信し、このメッセージは200 OK応答メッセージとすることが可能である。
【００７５】
ステップ４０６において、ＣＢＵＳサーバは、評価対象sip:f1@example.com、sip:f2@example.com、およびsip:f3@example.comの位置情報を取得する要求メッセージを位置サーバに送信し、このステップにおける要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【００７６】
ステップ４０７において、位置サーバは、ｆ１、ｆ２、およびｆ３の位置情報をＣＢＵＳサーバに返信する。返信されるメッセージはステップ４０６に対応する200 OKメッセージであり、このメッセージの実現方式は第３実施形態において返信されるメッセージと同じである。
【００７７】
本実施形態は、ステップ４０４からステップ４０７の実行順序に限定されず、ステップ４０４の後でステップ４０５が実行され、ステップ４０６の後でステップ４０７が実行される技術的解決手段もまた本発明の本実施形態の保護範囲内にある。
【００７８】
ステップ４０８において、ＣＢＵＳサーバは、受信されたユーザＢの自宅住所およびｆ１、ｆ２、およびｆ３の位置情報に従って、各々の評価対象とユーザＢの自宅住所の間の距離を計算し、比較によって相対的な評価条件を満たす評価対象を取得する。現在、相対的な評価条件を満たす評価対象が存在しないならば、ステップ４０９が実行され、そうでなければ、ステップ４１２が実行される。
【００７９】
ステップ４０９において、ＣＢＵＳサーバは評価結果なしで一時的な通知メッセージをＣＢＵＳクライアントに送信する。一時的な通知メッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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!（現時点では規則に合致するものはありません。しばらくお待ち下さい。誰かが条件に合致したときに、あなたに通知されます。）
【００８０】
ステップ４１０において、ＣＢＵＳクライアントはステップ４０９に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【００８１】
ステップ４１１において、ある条件が引き起こされると（例えば、計時デバイス）、ＣＢＵＳサーバは、評価対象およびユーザＢの位置情報を再び位置サーバから取得することを要求する。
【００８２】
ＣＢＵＳサーバによって位置情報を定期的に取得する時間間隔はユーザＡまたはＣＢＵＳサーバによって設定することが可能である。
【００８３】
ステップ４１２において、位置サーバは評価対象およびユーザＢの位置情報をＣＢＵＳサーバに返信し、さらに、ＣＢＵＳサーバはsubscribe/notifyメソッドにおいて評価対象の位置情報を追跡する。
【００８４】
ステップ４１３において、ＣＢＵＳサーバは受信された位置情報に従ってユーザＢと３人の友人の間の距離を計算し、比較によって、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象を取得する。
【００８５】
ステップ４１４において、ＣＢＵＳサーバは評価結果（すなわち、f1@example.comおよびf2@example.comである、相対的な評価条件を満たす評価対象）をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能であり、それは次に表わされている通りである。
NOTIFY sip:a@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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"/> “評価結果１”
<entry uri="sip:joe@example.com"/> “評価結果２”
</list>
</resource-lists>
【００８６】
ステップ４１５において、ＣＢＵＳクライアントはステップ４１４に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【００８７】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示し、基準対象の位置情報および評価対象の位置情報は、相対的な評価条件に従ってそれぞれ共有プロファイルＸＤＭＳおよび位置サーバから取得され、評価のための基礎として使用され、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。
【００８８】
図６は、本発明の第６実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、広告（advertisement）移動局の位置は動的に変更され、リアルタイムな評価方法でＣＢＵＳサーバによって広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有するＩＭ（instant messaging）接続中の音楽愛好者を検索することを意図する。図６を参照すると、本実施形態の方法は具体的には次のステップを含む。
【００８９】
ステップ５０１において、広告移動局は、位置決めされるＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信し、評価要求メッセージは相対的な評価条件および評価設定を含み、相対的な評価条件は広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有するＩＭ接続中の音楽愛好者であり、相対的な評価条件は基準対象が広告移動局であることを指示し、評価設定はリアルタイムな評価である。
【００９０】
本実施形態において、評価要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能であり、それは次に表わされている通りである。
SUBSCRIBE sip:cbus-server@example.com SIP/2.0
“SIP SUBSCRIBEによってＣＢＵＳサーバから評価結果が配信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 322723822 SUBSCRIBE
“同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:terminal.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Expires: 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 > “範囲が１０００ｍであることを表わす”
</location>
</rel_condition>
<fix_condition> “検索対象の条件を表わす”
<presence> “プレゼンス情報に基づく条件を表わす”
<rule>//pdm:tuple[*/op:service-id="org.openmobilealliance:IM-pager-mode" /pdm:status[basic="open"]</rule> “ＩＭ接続中を表わす”
</presence>
<shared_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>
“評価期間は１２時間であることを表わす”
<eva_interval>5min</eva_interval> “評価間隔は５分であることを表わす”
<result_min>50</result_min> “返信される評価結果の数の下限を表わす”
<result_max>200</result_max> “返信される評価結果の数の上限を表わす”
</eva_setting>
</cbus_req>
【００９１】
<rel_condition>要素およびその部分要素の定義は第４実施形態と同じである。本実施形態において相対的な評価条件は相対的な条件と評価対象の条件の組み合わせであり、それによって、評価対象の条件を表わすように構成された新たな<fix_condition>要素が定義され、その<presence>および<shared_xdms>部分要素は、それぞれ、条件がプレゼンス情報および共有ＸＤＭＳ内の情報に基づくことを表わすように構成され、ここで、２つの部分要素における<rule>要素はともに特定の規則内容を表わすように構成される。本実施形態はリアルタイムな評価方法を採用するので、評価期間を表わすように構成された新たな<eva_duration>部分要素、リアルタイムな評価の時間間隔を表わすように構成された<eva_interval>、および、評価要求の発信者によって要求され、ＣＢＵＳサーバによって返信される評価結果の数の下限および上限を表わすように構成された<result_min>および<result_max>が定義される。
【００９２】
ステップ５０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【００９３】
ステップ５０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、および基準対象を取得する。
【００９４】
ステップ５０４において、本実施形態の相対的な評価条件は、第１の評価条件（相対的な条件）および第２の評価条件（評価対象の条件）を含み、ここで、第１の評価条件は、広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有する音楽愛好者であり、第２の評価条件はＩＭ接続中であり、ＣＢＵＳサーバは第１の評価条件および基準対象を伝送する検索要求メッセージを（本実施形態において具体的には位置サーバである）情報源に送信し、それによって、広告移動局から１０００ｍの範囲内で離れている現在の地理的な位置を有する音楽愛好者を検索することを要求する。
【００９５】
本実施形態における検索要求メッセージは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> “範囲は１０００ｍであることを表わす”
</target_area>
</change_area>
<userinfo>
<hobby>music</hobby> “趣味は音楽を含むことを表わす”
</userinfo>
<loc_type type='CURRENT_OR_LAST'/>
“位置決めされるものの現在または以前の位置情報が要求されることを表わす”
</slir>
</svc_init>
【００９６】
検索機能を満たすために、本実施形態において、移動位置プロトコル（Mobile Location Protocol（ＭＬＰ））が拡張される。具体的には、svc_init要素について新たな属性検索が定義され、位置サーバに送信された要求メッセージが検索要求メッセージであるか否かを表わすように構成される。属性の値が真（true）であるならば、それは要求メッセージが検索要求メッセージであることを示し、属性の値が偽（false）であるならば、それは要求メッセージが位置情報の要求メッセージであることを示す。
【００９７】
ステップ５０５において、位置サーバは条件検索を実行し、基準対象に関する情報を問い合わせ、基準対象および第１の評価条件に関する情報に従って第１の評価条件を満たす評価対象を検索する。
【００９８】
具体的には、広告移動局の位置がまず決定され、広告移動局の位置に従って広告移動局から１０００ｍの範囲内で離れている人が決定され、位置サーバ内のユーザ情報データベース内の情報に従って広告移動局から１０００ｍの範囲内で離れている人がさらに選択され、音楽を含む趣味を有する人が選択される。
【００９９】
さらに、位置サーバは、ユーザが位置情報を公開するか否か選択する機能も提供する。ユーザが位置情報を公開することを選択するならば、位置情報を公開する対象をさらに指示することが可能であり、例えば、評価を受信し、広告を受信し、ユーザが位置情報を公開することを選択したときのみ位置サーバはそのユーザを検索要求メッセージの検索対象に挙げることができる。位置サーバによって検索要求メッセージを処理する時間を減少させるために、位置情報を公開することを望むユーザについて、位置サーバはユーザの位置情報を特定の地図領域にマッピングし、従って、検索要求メッセージを受信した後、位置サーバは誰がある領域の範囲内に存在するかを迅速に決定することができる。さらに、位置サーバは、ユーザの共通に使用される基本情報を記憶するように構成されたユーザ情報記憶データベースを提供し、それによって、位置の相対的な評価条件を満たす人がさらに選択され、そして、ＣＢＵＳサーバが、ユーザ情報を記憶する他のデータベース（例えば、共有プロファイルＸＤＭＳ）から関係する情報を取得することを防止し、それによって、ＣＢＵＳサーバとサービスエンジンの間で過度のトラフィックの交信を防止するが、ユーザ情報は位置サーバにおいてのみ使用され、個人情報である。ユーザ情報を記憶するデータベースがＸＤＭＳによって実現されるならば、各ユーザの共通に使用される基本情報は１つのｘｍｌドキュメントによって表わすことができ、それは次に表わされている通りである。
<?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>
【０１００】
ステップ５０６において、ＣＢＵＳサーバは、位置サーバによって返信された第１の評価条件を満たす評価対象を受信し、このステップにおいて返信されるメッセージはステップ５０４に対応する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>
“条件を満たすユーザ１”
<msid type=' SIP_URI '>user2@example.com </msid>
“条件を満たすユーザ２”
<msid type=' SIP_URI '>user3@example.com </msid>
“条件を満たすユーザ３”
…
<msid type=' SIP_URI '>user278@example.com </msid>
“条件を満たすユーザ２７８”
</msids>
</slia>
</svc_result>
【０１０１】
ステップ５０６が実行された後、ＣＢＵＳサーバは、第２の評価条件および評価設定に従って関係するサービスエンジンから第１の評価条件を満たす評価対象に関する情報を取得し、それによって、評価結果を取得する。本実施形態において、第２の評価条件はＩＭサービス接続中であり、評価結果は次のステップによって取得される。
【０１０２】
ステップ５０７において、ＣＢＵＳサーバは、プレゼンス情報を取得する、具体的には、ステップ５０５において選択された人がＩＭサービス接続中であるか否かを表わすプレゼンス情報を取得する要求メッセージをプレゼンスサーバに送信し、その要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【０１０３】
ステップ５０８において、プレゼンスサーバはプレゼンス情報をＣＢＵＳサーバに返信し、返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１０４】
ステップ５０９において、ＣＢＵＳサーバは受信されたプレゼンス情報を判定し、ＩＭ接続中である人、すなわち、第２の評価条件を満たす評価対象を選択し、それによって、評価結果を取得する。
【０１０５】
ステップ５１０において、ＣＢＵＳサーバは評価結果を広告移動局に送信する。送信されるメッセージはSIP NOTIFYの実現方式を採用することができ、それは次に表わされている通りである。
NOTIFY sip:advertiser@example.com SIP/2.0
“SIP NOTIFYメソッドで評価結果がユーザＡに返信されることを表わす”
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
“１つのセッションにおける全てのメッセージを関係付けるユニークな識別情報を表わす”
CSeq: 997935769 NOTIFY “同じセッションにおける１つの要求および応答を識別する順序番号を表わす”
Contact: <sip:cbus-server.example.com>
“SIP URIによって続く要求が要求者と連絡をとることを表わす”
Event: cbus “ＣＢＵＳイベントパケットを表わす”
Subscription-State: active;expires=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" /> “評価結果１”
<entry uri="sip:user5@example.com" /> “評価結果２”
<entry uri="sip:user11@example.com" /> “評価結果３”
…
<entry uri="sip:user128@example.com" /> “評価結果４５”
</list>
</resource-lists>
【０１０６】
さらに、ステップ５０１における評価要求メッセージは<result_min>要素および<result_max>要素、すなわち、相対的な評価条件において設定された評価結果の数の上限（200）および下限（50）を含み、ＣＢＵＳサーバは、評価結果を返信する前に、評価結果をカウントする。評価結果の数が５０より小さいならば、ＣＢＵＳサーバは、評価結果の数が５０に到達するまで、広告移動局によって設定された評価間隔（<eva_interval>要素）に従ってリアルタイムな評価を実行し、そして、評価結果を広告移動局に通知し、一方、今回の評価結果の数が２００より大きいならば、ＣＢＵＳサーバは、複数回、評価結果を広告移動局に通知し、毎回返信される評価結果の数は多くても２００である。
【０１０７】
ステップ５１１において、広告移動局はステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１０８】
本実施形態はリアルタイムな評価方法を採用し、それによって、ＣＢＵＳサーバは、評価期間<eva_duration>が到達されるまで、評価間隔<eva_interval>に従って周期的な評価を実行する。
【０１０９】
さらに、本実施形態はステップ５０４からステップ５０９の実行順序に限定されず、評価対象のプレゼンス情報をまず取得することが可能であり、ＩＭ接続中である人が選択され、そして、相対的な評価条件を満たす評価対象がさらに検索される。
【０１１０】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、および評価設定を指示し、広告移動局の位置情報は位置サーバから取得され、相対的な評価条件を部分的に満たす評価対象が検索され、プレゼンスサーバから取得されたプレゼンス情報に従って相対的な評価条件を完全に満たす評価対象がさらに検索され、それによって、評価結果を取得する。本実施形態において、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、広告移動局の位置は動的に変更され、ＣＢＵＳサーバは広告移動局の変更された位置情報を自動的に取得し、それによって、相対的な評価条件が手動で変更された後の不都合な結果を防止する。
【０１１１】
図７は、本発明の第７実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ＣＢＵＳサービスは単位としてグループを使用する評価機能をサポートする。ユーザＡはＣＢＵＳサービスによって３つの生成されたグループを評価することを意図し、それによって、相対的な評価条件を満たす最大の人数を有するグループについて３つのグループを検索する。３つのグループのSIP URIはそれぞれsip:group1@example.com、sip:group2@example.com、およびsip:group3@example.comであり、相対的な評価条件は、地理的な位置がユーザＡから５００ｍの範囲内で離れていることであり、活動状態は買物中である。図７を参照すると、本実施形態の方法は具体的には次のステップを含む。
【０１１２】
ステップ６０１において、ユーザＡは端末上のＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含む。相対的な評価条件は、地理的な位置がユーザＡから５００ｍの範囲内で離れていることであり、活動状態は買物中であり、評価対象は３つのグループであり、評価設定は１回の評価であり、ここで、相対的な評価条件は基準対象がユーザＡであることを指示する。
【０１１３】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?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"/> “評価対象１”
<rl:entry uri="sip:group2@example.com"/> “評価対象２”
<rl:entry uri="sip:group3@example.com"/> “評価対象３”
</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> “１回の評価を表わす”
</cr:actions>
</cr:rule>
</cr:ruleset>
</ls:list-service>
</cbusreq>
【０１１４】
メッセージ本体の<location>要素および<presence>要素は、それぞれ、位置情報に基づく相対的な評価条件およびプレゼンス情報に基づく相対的な評価条件を表わすように構成される。<result_urilist>の値は、相対的な評価条件を満たす最大の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたmost（最大）とすることが可能であり、また、この要素の値は、相対的な評価条件を満たす最小の人数を有するグループのURIを返信するようにサーバが要求されることを表わすように構成されたleast（最小）とすることが可能である。
【０１１５】
ステップ６０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK応答メッセージをＣＢＵＳクライアントに返信する。
【０１１６】
ステップ６０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【０１１７】
このステップにおいて、ＣＢＵＳサーバは、３つのグループのグループ識別情報に従って関係する情報源（例えば、共有グループＸＤＭＳ）からグループメンバーのリスト情報を取得する。
【０１１８】
ステップ６０４において、ＣＢＵＳサーバはグループメンバーの活動状態の情報を取得する要求メッセージをプレゼンスサーバに送信し、それによって、３つのグループにおける全てのメンバーの活動状態の情報を取得することを要求する。この要求メッセージはSIP SUBSCRIBEの実現方式を採用することが可能である。
【０１１９】
ステップ６０５において、プレゼンスサーバはグループメンバーの活動状態の情報をＣＢＵＳサーバに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１２０】
ステップ６０６において、ＣＢＵＳサーバは買物中である活動状態の情報を有するグループメンバーを選択する。
【０１２１】
ステップ６０７において、ＣＢＵＳサーバは評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザＡおよびステップ５０６において選択されたグループメンバーの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【０１２２】
ステップ６０８において、位置サーバは位置情報をＣＢＵＳサーバに返信する。
【０１２３】
ステップ６０９において、ＣＢＵＳサーバは、受信された位置情報に従ってユーザＡとステップ６０６において選択されたグループメンバーの間の距離を計算し、ユーザＡから５００ｍの範囲内で離れているグループメンバーを取得し、３つのグループにおいて条件を満たす人数をそれぞれカウントし、条件を満たす最大の人数を有するグループがsip:group2@example.comであることを取得する。
【０１２４】
ステップ６１０において、ＣＢＵＳサーバは評価結果をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１２５】
ステップ６１１において、ＣＢＵＳクライアントはステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１２６】
本実施形態において、評価要求メッセージは、基準対象、相対的な評価条件、評価設定、および評価対象を指示する。まず、グループメンバーの活動状態の情報がプレゼンスサーバから取得され、買物中である活動状態を有するグループメンバーが選択され、そして、ユーザＡおよび買物中である活動状態を有するグループメンバーの位置情報が位置サーバから取得され、ユーザＡからの距離が計算され、各グループにおいて条件を満たす人数がカウントされ、それによって、評価結果を取得する。本実施形態において、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、評価はより柔軟である。さらに、本実施形態において、ＣＢＵＳサーバはグループ選択機能をサポートし、従って、評価方法の応用範囲が拡張される。
【０１２７】
図８は、本発明の第８実施形態による相対的な条件評価を実現する方法のシグナリングフローチャートである。本実施形態において、ユーザＡは、ＣＢＵＳサービスによって顧客Ｂおよび顧客Ｃから５００ｍの範囲内で離れている地理的な位置を有する同僚を見つけることを意図する。顧客Ｂおよび顧客ＣのSIP URIは、それぞれ、sip:b@example.comおよびsip:c@example.comであり、相対的な評価条件は、地理的な位置が顧客Ｂおよび顧客Ｃから５００ｍの範囲内で離れていることであり、評価設定は１回の評価であり、評価対象はユーザＡの同僚であり、ここで、ユーザＡの同僚のSIP URIは、それぞれ、sip:f1@example.com、sip:f2@example.com、…、およびsip:fn@example.comであると仮定する。図８を参照すると、本実施形態の方法は次のステップを含む。
【０１２８】
ステップ７０１において、ユーザＡは端末上のＣＢＵＳクライアントによって評価要求メッセージをＣＢＵＳサーバに送信する。評価要求メッセージは相対的な評価条件、評価設定、および評価対象を含み、相対的な評価条件は、基準対象が顧客Ｂおよび顧客Ｃであることを指示する。
【０１２９】
評価要求メッセージのメッセージ本体は次に表わされている通りである。
<?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"/> “評価対象１”
<cr:one id="sip:f2@example.com"/> “評価対象２”
…
<cr:one id="sip:fn@example.com"/> “評価対象ｎ”
</cr:identity>
<focus> “基準対象を表わす”
<cr:one id="sip:b@example.com"/> “基準対象１”
<cr:one id="sip:c@example.com"/> “基準対象２”
</focus>
<radius>500m</radius> “範囲が５００ｍであることを表わす”
</cr:conditions>
<cr:actions> “評価設定を表わす”
<eva_type>once</eva_type> “１回の評価を表わす”
</cr:actions>
<cr:transformations> “評価結果の設定を表わす”
<provide-urilist>true</provide- urilist>
“URIリストを返信することをサーバが要求されていることを表わす”
</cr:transformations>
</cr:rule>
</cbus_req>
【０１３０】
メッセージ本体の<identity>要素は評価対象を表わすように構成され、<focus>要素は基準対象を表わすように構成され、<provide-urilist>要素の値は真（true）であり、これはURIリストの形式で評価結果を返信することをＣＢＵＳサーバが要求されていることを表わすように構成される。
【０１３１】
ステップ７０２において、ＣＢＵＳサーバは評価要求メッセージを受信し、200 OK 応答メッセージをＣＢＵＳクライアントに返信する。
【０１３２】
ステップ７０３において、ＣＢＵＳサーバは評価要求メッセージを解析し、相対的な評価条件、評価設定、評価対象、および基準対象を取得する。
【０１３３】
ステップ７０４において、ＣＢＵＳサーバは、評価対象および基準対象の位置情報を取得する要求メッセージを位置サーバに送信し、それによって、ユーザＡの同僚、顧客Ｂ、および顧客Ｃの位置情報を取得することを要求する。この要求メッセージはHTTP POSTの実現方式を採用することが可能である。
【０１３４】
ステップ７０５において、位置サーバは位置情報をＣＢＵＳサーバに返信する。
【０１３５】
ステップ７０６において、ＣＢＵＳサーバは、受信された位置情報に従って各々の評価対象（ユーザＡの同僚）と顧客Ｂの間の距離、および各々の評価対象と顧客Ｃの間の距離をそれぞれ計算し、相対的な評価条件を満たす評価対象がsip:f2@example.comであることを取得する。
【０１３６】
ステップ７０７において、ＣＢＵＳサーバは評価結果をＣＢＵＳクライアントに返信する。返信されるメッセージはSIP NOTIFYの実現方式を採用することが可能である。
【０１３７】
ステップ７０８において、ＣＢＵＳクライアントはステップ５１０に対応する200 OK応答メッセージをＣＢＵＳサーバに返信する。
【０１３８】
本実施形態において、評価要求メッセージは、複数の基準対象、相対的な評価条件、評価設定、および評価対象を指示し、ユーザＡの同僚、顧客Ｂ、および顧客Ｃの位置情報は位置サーバから取得され、相対的な評価条件を満たす評価対象が取得され、それによって、評価結果を取得する。本実施形態において、相対的な評価条件は相対的な条件であり、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、それによって、基準対象の状態に従って評価が実行され、相対的な条件評価はより柔軟である。さらに、本実施形態におけるＣＢＵＳサーバは複数の基準対象を有する評価方法をサポートし、ユーザまたはアプリケーションの設定に従って異なる基準対象を動的に選択することが可能であり、それによって、相対的な評価条件の設定がより柔軟になる。
【０１３９】
図９は、本発明の一実施形態による相対的な条件評価を実現するシステムの構成図である。図９を参照すると、本実施形態のシステムは、サーバ１およびクライアント２を含み、さらに、情報源３を含むことが可能である。
【０１４０】
クライアント２は評価要求メッセージをサーバ１に発信する。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含む。相対的な条件評価に関する情報が評価対象を含むならば、サーバ１は、評価要求メッセージに従って情報源３から相対的な評価条件において指示された基準対象に関する情報および評価対象に関する情報（この２つに関する情報は相対的な条件評価のために要求される情報である）を取得し、この２つに関する情報を比較し、評価結果を取得し、この評価結果をクライアント２に送信する。相対的な条件評価に関する情報が評価対象を含まないならば、サーバ１は、基準対象および／または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源３に送信し、情報源３は、基準対象に関する情報に従って相対的な評価条件（すなわち、相対的な条件評価のために要求される情報）を満たす評価対象を検索し、この評価対象をサーバ１に送信し、サーバ１は、相対的な評価条件を満たす評価対象に従って評価結果を取得し、この評価結果をクライアント２に送信する。
【０１４１】
さらに、図９に表わされているように、本実施形態のクライアント２は、以下の本発明の実施形態のクライアントにおける任意のクライアントとすることが可能であり、サーバ１は、以下の本発明の実施形態のサーバにおける任意のサーバとすることが可能である。
【０１４２】
図１０は、本発明の一実施形態によるクライアントの構成図である。図１０を参照すると、本実施形態のクライアントは、第２送信モジュール２１および第２送信モジュール２２を含む。第２送信モジュール２１は評価要求メッセージを送信するように構成される。第２受信モジュール２２は評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成される。評価要求メッセージは相対的な条件評価に関する情報を含み、相対的な条件評価に関する情報は、相対的な評価条件および／または評価対象および／または評価設定を含み、または、参照パス情報を含み、参照パス情報は相対的な評価条件および／または評価対象および／または評価設定の記憶位置を指示する。
【０１４３】
図１１は、本発明の一実施形態によるサーバの構成図である。図１１を参照すると、本実施形態のサーバは、第１受信モジュール１１、条件取得モジュール１２、情報取得モジュール１３、および処理／送信モジュール１４を含む。第１受信モジュール１１は評価要求メッセージを受信するように構成され、評価要求メッセージは相対的な条件評価に関する情報を含む。条件取得モジュール１２は評価要求メッセージに従って相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。情報取得モジュール１３は評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成される。処理／送信モジュール１４は相対的な条件評価のために要求される情報に従って評価結果を取得し、評価結果を送信するように構成される。
【０１４４】
相対的な条件評価に関する情報が相対的な評価条件を含むならば、条件取得モジュール１２は、さらに、評価要求メッセージを解析し、相対的な評価条件および相対的な評価条件において指示された基準対象を取得するように構成される。
【０１４５】
相対的な条件評価に関する情報が参照パス情報であるならば、条件取得モジュール１２は、さらに、参照パス情報に対応する記憶位置から相対的な評価条件および相対的な評価条件における基準対象を取得するように構成される。
【０１４６】
評価要求メッセージが解析され、または、相対的な評価条件が取得されるとき、評価対象がさらに取得される。情報取得モジュール１３は、さらに、第３送信モジュール１５および第３受信モジュール１６を含む。第３送信モジュール１５は評価対象に関する情報および基準対象に関する情報を取得する要求メッセージを情報源３に送信するように構成される。第３受信モジュール１６は情報源３によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成される。第３送信モジュール１５および第３受信モジュール１６は通信によって接続され、正確には、情報源３を介して通信によって接続されることも可能である。
【０１４７】
処理／送信モジュール１４は相対的な評価条件に従って評価対象に関する情報を基準対象に関する情報と比較し、評価結果を取得し、その評価結果をクライアントに送信するように構成されることが可能である。
【０１４８】
さらに、情報取得モジュール１３は第４送信モジュール１７および第４受信モジュール１８を含むことも可能である。第４送信モジュール１７は、取得された相対的な評価条件および相対的な評価条件において指示された基準対象に従って基準対象および／または基準対象に関する情報、および、相対的な評価条件を伝送する検索要求メッセージを情報源３に送信するように構成される。第４受信モジュール１８は情報源３によって返信された相対的な評価条件を満たす評価対象を受信するように構成され、相対的な評価条件を満たす評価対象は相対的な条件評価のために要求される情報であり、また、評価結果である。第４送信モジュール１７は通信によって第４受信モジュール１８に接続され、正確には、情報源３を介して通信によって接続されることも可能である。
【０１４９】
本発明の実施形態による相対的な条件評価を実現するシステム、クライアント、およびサーバにおいて、相対的な評価条件が取得され、基準対象は相対的な評価条件において指示され、それによって、基準対象に関する情報は評価のための基礎として使用され、評価要求者は評価対象のある状態が固定値を満たすことを指示する必要がなく、基準対象の状態に従って評価が実行される。
【０１５０】
この技術分野の当業者は、本発明の実施形態による方法のステップの全部または一部がプログラム命令関連ハードウェアによって実現されることが可能であることを理解すべきである。プログラムはコンピュータ読み取り可能な記憶媒体に記憶されることが可能である。プログラムが実行されるとき、本発明の実施形態による方法のステップが実行される。記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、または光ディスクのようなプログラムコードを記憶することが可能な任意の媒体とすることが可能である。
【０１５１】
最後に、上記の実施形態は本発明の技術的解決手段を説明するために提供されたにすぎず、本発明を限定することを意図していないことに留意すべきである。上記実施形態に関して本発明が詳細に説明されたが、修正または置換が該当する技術的解決手段の要旨を本発明の思想および範囲から逸脱させない限り、上記実施形態に記載された技術的解決手段に修正を行うことができ、または、技術的解決手段におけるいくつかの技術的特徴に等価な置換を行うことができることをこの技術分野の当業者は理解すべきである。
【符号の説明】
【０１５２】
１ サーバ
２ クライアント
３ 情報源
１１ 第１受信モジュール
１２ 条件取得モジュール
１３ 情報取得モジュール
１４ 処理／送信モジュール
１５ 第３送信モジュール
１６ 第３受信モジュール
１７ 第４送信モジュール
１８ 第４受信モジュール
２１ 第２送信モジュール
２２ 第２受信モジュール
【特許請求の範囲】
【請求項１】
評価要求メッセージを受信するステップを有し、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するステップと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップと、
を有する相対的な条件評価を実現する方法。
【請求項２】
前記相対的な条件評価に関する情報は前記相対的な評価条件を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記評価要求メッセージを解析し、前記相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項３】
前記相対的な条件評価に関する情報は参照パス情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記参照パス情報に対応する記憶位置から前記相対的な評価条件および前記相対的な評価条件において指示された基準対象を取得するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項４】
前記相対的な条件評価に関する情報は評価対象をさらに含み、かつ、前記評価要求メッセージを解析するステップは前記評価対象を取得するステップを有するか、または、
前記参照パス情報から評価対象を取得するステップを有する請求項２または３に記載の相対的な条件評価を実現する方法。
【請求項５】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップと、
前記関係する情報源によって返信された評価対象および基準対象に関する情報を取得するステップと、
を有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項６】
前記関係する情報源に送信される前記評価対象および前記基準対象に関する情報を取得する要求メッセージは、評価要求の発信者の識別情報を伝送し、
前記方法は、前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップの後に、前記関係する情報源によって前記評価要求の発信者の識別情報に従って前記評価要求の発信者の識別情報の確認を実行するステップをさらに有する請求項５に記載の相対的な条件評価を実現する方法。
【請求項７】
前記相対的な条件評価のために要求される情報は同一の情報源から取得されるか、または、
前記相対的な条件評価のために要求される情報は異なる情報源から取得される請求項１に記載の相対的な条件評価を実現する方法。
【請求項８】
前記相対的な条件評価のために要求される情報は前記評価対象に関する情報および前記基準対象に関する情報を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信するステップを有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項９】
前記相対的な評価条件は第１の評価条件および第２の評価条件を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記第１の評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、前記第１の評価条件を満たす第１の評価対象を取得するステップと、
前記関係する情報源から前記第１の評価対象に関する情報を取得するステップと、
前記第１の評価対象に関する情報を前記第２の評価条件において指示された固定値と比較し、前記第２の評価条件を満たす第２の評価対象を取得するステップと、
前記第２の評価対象を評価結果として送信するステップと、
を有する請求項８に記載の相対的な条件評価を実現する方法。
【請求項１０】
前記評価対象がグループであるならば、
前記評価対象に関する情報はグループメンバーに関する情報であり、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記相対的な評価条件に従って前記グループメンバーに関する情報を前記基準対象に関する情報と比較し、前記グループ内で前記相対的な評価条件を満たすグループメンバーをカウントし、評価対象を取得および送信するステップを有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項１１】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記相対的な評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１２】
前記関係する情報源は第１の情報源および第２の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の情報源から前記基準対象に関する情報を取得するステップと、
前記相対的な評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第２の情報源に送信し、それによって前記第２の情報源が前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記第２の情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１３】
前記相対的な評価条件は第１の評価条件および第２の評価条件を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記第１の評価条件および前記基準対象に関する情報に従って前記第１の評価条件を満たす第１の評価対象を検索するステップと、
前記第１の評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１４】
前記関係する情報源は第１の情報源および第２の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の情報源から前記基準対象に関する情報を取得するステップと、
第１の評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第２の情報源に送信し、それによって前記第２の情報源が前記第１の評価条件および前記基準対象に関する情報に従って前記第１の評価条件を満たす第１の評価対象を検索するステップと、
前記第２の情報源によって返信された前記第１の評価条件を満たす第１の評価対象を受信するステップと、
を有する請求項１３に記載の相対的な条件評価を実現する方法。
【請求項１５】
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記第１の評価対象に関する情報を前記第２の評価条件において指示された固定値と比較し、前記第２の評価条件を満たす第２の評価対象を取得するステップと、
前記第２の評価対象を評価結果として送信するステップと、
を有する請求項１３または１４に記載の相対的な条件評価を実現する方法。
【請求項１６】
前記相対的な評価条件は評価結果の数の上限および下限を含み、
前記評価結果を取得するステップは、
サーバによって、前記評価結果の数が前記下限より少ないとき、前記評価結果の数が前記下限に到達するまで、評価を実行し続け、評価結果を返信するステップと、
前記サーバによって、前記評価結果の数が前記上限より多いとき、複数回、評価結果を返信するステップと、をさらに有し、毎回返信される評価結果の数は前記上限より多くない請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項１７】
前記基準対象は評価要求の発信者または前記評価要求の発信者によって指示されたユーザであるか、または、
前記基準対象の数は１つまたは複数であるか、または、
前記評価の手順の間、前記基準対象は固定されるか、または、前記評価の手順の間、事前設定に従って異なる基準対象が動的に選択される請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項１８】
前記相対的な条件評価に関する情報は評価設定をさらに含み、
前記評価設定は、１回の評価、リアルタイムな評価、または、終了の評価を含む請求項２または３に記載の相対的な条件評価を実現する方法。
【請求項１９】
前記評価要求メッセージは、ポリシーの評価、実施、および管理（ＰＥＥＭ）の呼び出し可能インタフェース（ＰＥＭ−１）によって受信され、前記評価結果はＰＥＭ−１インタフェースによって送信される請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項２０】
前記相対的な評価条件が取得されるとき評価対象が取得され、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、前記関係する情報源から前記評価対象に関する情報および前記基準対象に関する情報を取得するステップを有し、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および返信するステップは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および返信するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項２１】
評価要求メッセージを送信し、前記評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成されたクライアントを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
受信された評価要求メッセージに従って前記相対的な評価条件および前記相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を前記クライアントに送信するように構成されたサーバをさらに備える相対的な条件評価を実現するシステム。
【請求項２２】
前記相対的な評価条件において指示された評価対象に関する情報および基準対象に関する情報を提供し、前記相対的な評価条件を満たす評価対象を検索するように構成された情報源をさらに備える請求項２１に記載の相対的な条件評価を実現するシステム。
【請求項２３】
評価要求メッセージをサーバに送信するように構成された第２送信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
前記評価要求メッセージに従って前記サーバによって返信された評価結果を受信するように構成された第２受信モジュールをさらに備えるクライアント。
【請求項２４】
評価要求メッセージを受信するように構成された第１受信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するように構成された条件取得モジュールと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成された情報取得モジュールと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するように構成された処理／送信モジュールと、
をさらに備えるサーバ。
【請求項２５】
前記情報取得モジュールは、
評価対象に関する情報および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するように構成された第３送信モジュールと、
前記関係する情報源によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成された第３受信モジュールと、
をさらに備え、
前記処理／送信モジュールは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信する請求項２４に記載のサーバ。
【請求項２６】
前記情報取得モジュールは、
取得された相対的な評価条件および前記相対的な評価条件において指示された基準対象に従って、前記基準対象および／または前記基準対象に関する情報、および、前記相対的な評価条件を伝送する検索要求メッセージを前記関係する情報源に送信するように構成された第４送信モジュールと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するように構成された第４受信モジュールと、をさらに備え、前記相対的な評価条件を満たす評価対象は前記相対的な条件評価のために要求される情報である請求項２４に記載のサーバ。
【請求項１】
評価要求メッセージを受信するステップを有し、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するステップと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップと、
を有する相対的な条件評価を実現する方法。
【請求項２】
前記相対的な条件評価に関する情報は前記相対的な評価条件を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記評価要求メッセージを解析し、前記相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項３】
前記相対的な条件評価に関する情報は参照パス情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するステップは、
前記参照パス情報に対応する記憶位置から前記相対的な評価条件および前記相対的な評価条件において指示された基準対象を取得するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項４】
前記相対的な条件評価に関する情報は評価対象をさらに含み、かつ、前記評価要求メッセージを解析するステップは前記評価対象を取得するステップを有するか、または、
前記参照パス情報から評価対象を取得するステップを有する請求項２または３に記載の相対的な条件評価を実現する方法。
【請求項５】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップと、
前記関係する情報源によって返信された評価対象および基準対象に関する情報を取得するステップと、
を有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項６】
前記関係する情報源に送信される前記評価対象および前記基準対象に関する情報を取得する要求メッセージは、評価要求の発信者の識別情報を伝送し、
前記方法は、前記評価対象および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するステップの後に、前記関係する情報源によって前記評価要求の発信者の識別情報に従って前記評価要求の発信者の識別情報の確認を実行するステップをさらに有する請求項５に記載の相対的な条件評価を実現する方法。
【請求項７】
前記相対的な条件評価のために要求される情報は同一の情報源から取得されるか、または、
前記相対的な条件評価のために要求される情報は異なる情報源から取得される請求項１に記載の相対的な条件評価を実現する方法。
【請求項８】
前記相対的な条件評価のために要求される情報は前記評価対象に関する情報および前記基準対象に関する情報を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信するステップを有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項９】
前記相対的な評価条件は第１の評価条件および第２の評価条件を含み、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および送信するステップは、
前記第１の評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、前記第１の評価条件を満たす第１の評価対象を取得するステップと、
前記関係する情報源から前記第１の評価対象に関する情報を取得するステップと、
前記第１の評価対象に関する情報を前記第２の評価条件において指示された固定値と比較し、前記第２の評価条件を満たす第２の評価対象を取得するステップと、
前記第２の評価対象を評価結果として送信するステップと、
を有する請求項８に記載の相対的な条件評価を実現する方法。
【請求項１０】
前記評価対象がグループであるならば、
前記評価対象に関する情報はグループメンバーに関する情報であり、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記相対的な評価条件に従って前記グループメンバーに関する情報を前記基準対象に関する情報と比較し、前記グループ内で前記相対的な評価条件を満たすグループメンバーをカウントし、評価対象を取得および送信するステップを有する請求項４に記載の相対的な条件評価を実現する方法。
【請求項１１】
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記相対的な評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１２】
前記関係する情報源は第１の情報源および第２の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の情報源から前記基準対象に関する情報を取得するステップと、
前記相対的な評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第２の情報源に送信し、それによって前記第２の情報源が前記相対的な評価条件および前記基準対象に関する情報に従って前記相対的な評価条件を満たす評価対象を検索するステップと、
前記第２の情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１３】
前記相対的な評価条件は第１の評価条件および第２の評価条件を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の評価条件および前記基準対象を伝送する検索要求メッセージを前記関係する情報源に送信し、それによって前記関係する情報源が前記検索要求に従って前記基準対象に関する情報を問い合わせ、前記第１の評価条件および前記基準対象に関する情報に従って前記第１の評価条件を満たす第１の評価対象を検索するステップと、
前記第１の評価対象を受信するステップと、
を有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項１４】
前記関係する情報源は第１の情報源および第２の情報源を含み、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、
前記第１の情報源から前記基準対象に関する情報を取得するステップと、
第１の評価条件および前記基準対象に関する情報を伝送する検索要求メッセージを前記第２の情報源に送信し、それによって前記第２の情報源が前記第１の評価条件および前記基準対象に関する情報に従って前記第１の評価条件を満たす第１の評価対象を検索するステップと、
前記第２の情報源によって返信された前記第１の評価条件を満たす第１の評価対象を受信するステップと、
を有する請求項１３に記載の相対的な条件評価を実現する方法。
【請求項１５】
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するステップは、
前記第１の評価対象に関する情報を前記第２の評価条件において指示された固定値と比較し、前記第２の評価条件を満たす第２の評価対象を取得するステップと、
前記第２の評価対象を評価結果として送信するステップと、
を有する請求項１３または１４に記載の相対的な条件評価を実現する方法。
【請求項１６】
前記相対的な評価条件は評価結果の数の上限および下限を含み、
前記評価結果を取得するステップは、
サーバによって、前記評価結果の数が前記下限より少ないとき、前記評価結果の数が前記下限に到達するまで、評価を実行し続け、評価結果を返信するステップと、
前記サーバによって、前記評価結果の数が前記上限より多いとき、複数回、評価結果を返信するステップと、をさらに有し、毎回返信される評価結果の数は前記上限より多くない請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項１７】
前記基準対象は評価要求の発信者または前記評価要求の発信者によって指示されたユーザであるか、または、
前記基準対象の数は１つまたは複数であるか、または、
前記評価の手順の間、前記基準対象は固定されるか、または、前記評価の手順の間、事前設定に従って異なる基準対象が動的に選択される請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項１８】
前記相対的な条件評価に関する情報は評価設定をさらに含み、
前記評価設定は、１回の評価、リアルタイムな評価、または、終了の評価を含む請求項２または３に記載の相対的な条件評価を実現する方法。
【請求項１９】
前記評価要求メッセージは、ポリシーの評価、実施、および管理（ＰＥＥＭ）の呼び出し可能インタフェース（ＰＥＭ−１）によって受信され、前記評価結果はＰＥＭ−１インタフェースによって送信される請求項１から３のいずれか一項に記載の相対的な条件評価を実現する方法。
【請求項２０】
前記相対的な評価条件が取得されるとき評価対象が取得され、
前記関係する情報源から相対的な条件評価のために要求される情報を取得するステップは、前記関係する情報源から前記評価対象に関する情報および前記基準対象に関する情報を取得するステップを有し、
前記相対的な条件評価のために要求される情報に従って評価結果を取得および返信するステップは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および返信するステップを有する請求項１に記載の相対的な条件評価を実現する方法。
【請求項２１】
評価要求メッセージを送信し、前記評価要求メッセージに従ってサーバによって返信された評価結果を受信するように構成されたクライアントを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
受信された評価要求メッセージに従って前記相対的な評価条件および前記相対的な評価条件における基準対象を取得し、関係する情報源から相対的な条件評価のために要求される情報を取得し、前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を前記クライアントに送信するように構成されたサーバをさらに備える相対的な条件評価を実現するシステム。
【請求項２２】
前記相対的な評価条件において指示された評価対象に関する情報および基準対象に関する情報を提供し、前記相対的な評価条件を満たす評価対象を検索するように構成された情報源をさらに備える請求項２１に記載の相対的な条件評価を実現するシステム。
【請求項２３】
評価要求メッセージをサーバに送信するように構成された第２送信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、前記相対的な条件評価に関する情報は相対的な評価条件または参照パス情報を含み、
前記評価要求メッセージに従って前記サーバによって返信された評価結果を受信するように構成された第２受信モジュールをさらに備えるクライアント。
【請求項２４】
評価要求メッセージを受信するように構成された第１受信モジュールを備え、前記評価要求メッセージは相対的な条件評価に関する情報を含み、
前記評価要求メッセージに従って相対的な評価条件および前記相対的な評価条件における基準対象を取得するように構成された条件取得モジュールと、
前記評価要求メッセージに従って関係する情報源から相対的な条件評価のために要求される情報を取得するように構成された情報取得モジュールと、
前記相対的な条件評価のために要求される情報に従って評価結果を取得し、前記評価結果を送信するように構成された処理／送信モジュールと、
をさらに備えるサーバ。
【請求項２５】
前記情報取得モジュールは、
評価対象に関する情報および前記基準対象に関する情報を取得する要求メッセージを前記関係する情報源に送信するように構成された第３送信モジュールと、
前記関係する情報源によって返信された評価対象に関する情報および基準対象に関する情報を受信するように構成された第３受信モジュールと、
をさらに備え、
前記処理／送信モジュールは、前記相対的な評価条件に従って前記評価対象に関する情報を前記基準対象に関する情報と比較し、評価結果を取得および送信する請求項２４に記載のサーバ。
【請求項２６】
前記情報取得モジュールは、
取得された相対的な評価条件および前記相対的な評価条件において指示された基準対象に従って、前記基準対象および／または前記基準対象に関する情報、および、前記相対的な評価条件を伝送する検索要求メッセージを前記関係する情報源に送信するように構成された第４送信モジュールと、
前記関係する情報源によって返信された前記相対的な評価条件を満たす評価対象を受信するように構成された第４受信モジュールと、をさらに備え、前記相対的な評価条件を満たす評価対象は前記相対的な条件評価のために要求される情報である請求項２４に記載のサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１１−５２１５７２（Ｐ２０１１−５２１５７２Ａ）
【公表日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願番号】特願２０１１−５０９８４７（Ｐ２０１１−５０９８４７）
【出願日】平成２１年６月２４日（２００９．６．２４）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０７２４２５
【国際公開番号】ＷＯ２０１０／００３３４１
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
【公表日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願日】平成２１年６月２４日（２００９．６．２４）
【国際出願番号】ＰＣＴ／ＣＮ２００９／０７２４２５
【国際公開番号】ＷＯ２０１０／００３３４１
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
[ Back to top ]