イベントシーケンスに基づいてプレゼンスを通知するための方法
クライアントエンティティは、プレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを生成し、サブスクリプションはイベントシーケンスの時間パラメータをさらに指標する。サブスクリプションを受け取ると（３０２）、プレゼンスサーバは指標された時間パラメータに基づいてプレゼンス情報を受け取りモニタして（３０４）イベントシーケンスの発生を検出し、プレゼンス情報がトリガを満たす場合はクライアントエンティティに通知を送る（３０６）。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概してプレゼンスサービスに関し、より具体的には、イベントシーケンスに基づいてプレゼンスを通知するための方法に関する。
【背景技術】
【０００２】
技術の進歩に伴い、通信システムはより優れたサービスをユーザに提供することができるようになっている。プレゼンスサービスを利用する一部の応用例では、通信装置が、その通信装置（「プレゼンティティ」）のユーザの状態情報すなわちプレゼンス情報を中央ネットワークエンティティ（「プレゼンスサーバ」）に報告（「発行」）する。プレゼンスサーバは、通信システム内の他のユーザ（「ウォッチャ」）にそのプレゼンス情報を配信（「通知」）する。一般にプレゼンス情報には、通信装置の状態、装置のユーザの連絡可能性、通信装置の位置、装置によって実行されている現在の操作、ユーザの優先通信手段などの情報が含まれる。
【０００３】
標準的なプレゼンス機能は、ウォッチャ（ユーザ、装置、またはアプリケーション）がプレゼンスサーバにサブスクライブして、１つまたは複数のプレゼンティティに関係するプレゼンス情報を受け取ることを可能にする。サブスクリプションは、１つまたは複数のプレゼンティティごとにそれぞれ行うことができるか、または複数のプレゼンティティを含むプレゼンスリソースリストを使用して行うことができる。１つまたは複数の指定したプレゼンティティにサブスクライブすると、その指定したプレゼンティティに関するプレゼンス情報がウォッチャに通知される。
【０００４】
インターネット技術標準化委員会（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のコメント要求（ＲＦＣ）４４６０および４４６１では、ＳＩＰ／ＳＩＭＰＬＥウォッチャがサブスクリプションの一部として通知フィルタ基準を供給できるようにする拡張マークアップ言語（ＸＭＬ）ベースの方法が論じられている。プレゼンスサーバはその基準を評価して、サブスクライブしているウォッチャに通知するかどうか、および通知するときを決定する。しかしＲＦＣ４４６０および４４６１は、ウォッチャが、同時に発生する無順序の複数の同期現行プレゼンス値しか（供給される通知基準内で）参照することを認めない。例えば基準は、プレゼンス情報要素Ａが「ａ１」の値を有し、プレゼンス情報要素Ｂが「ｂ１」の値を同時に有する場合にウォッチャに通知することからなることができる。この単純なサブスクリプション・通知メカニズムは、消費者ユーザにとっては一般に十分である。しかし、このメカニズムは、例えばプレゼンス情報要素の履歴値および将来値、順序付きもしくは無順序のイベントシーケンス、および／またはプレゼンス情報の変化に対応するイベントの時間パラメータに基づいて通知トリガを指定する能力であって、既知のサブスクリプション／通知メカニズムでは利用できない、指定する能力を含むより洗練された技法の恩恵を受ける、公共の安全に関するユーザなどの他の特定のユーザの需要を満たすには不十分である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、イベントシーケンスに基づいてプレゼンスを通知するための方法が求められている。
以下の詳細な説明とともに、別々の図面を通して同様の参照番号が同一の要素または機能的に同様の要素を指す添付図面は本明細書に組み込まれ、本明細書の一部を形成し、特許請求の範囲に記載の本発明を含む概念の諸実施形態をさらに例示し、それらの実施形態の様々な原理および利点を説明する機能を果たす。
【０００６】
図面の中の要素は簡単かつ明瞭にするために示しており、必ずしも縮尺通りに描いているとは限らないことを当業者なら理解されよう。例えば、本発明の諸実施形態を理解する一助となるように、図中の一部の要素の寸法を他の要素に比べて拡大することがある。
【０００７】
図面の中で機器および方法のコンポーネントを従来の記号により必要に応じて示し、本明細書の説明の利益を有する当業者にとってすぐに分かる詳細によって本開示を不明瞭にしないために、本発明の諸実施形態の理解に関連がある特定の詳細だけを図示した。
【図面の簡単な説明】
【０００８】
【図１】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知するための通信システムのブロック図を示す。
【図２】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知できるようにするための、クライアントエンティティにおける方法の流れ図を示す。
【図３】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知できるようにするための、プレゼンスサーバにおける方法の流れ図を示す。
【図４】一部の実施形態による、モニタするプレゼンス情報が通知を送るためのトリガを満たすことを、プレゼンスサーバが様々な条件下で検出することを示す流れ図を示す。
【図５】一部の実施形態による、プレゼンスサーバがプレゼンス情報をモニタし、イベントシーケンスに基づいて通知を行うことを例示する絵図を示す。
【発明を実施するための形態】
【０００９】
概して言えば、様々な実施形態に従いクライアントエンティティは、プレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを生成し、サブスクリプションはイベントシーケンスの時間パラメータをさらに指標する。サブスクリプションを受け取ると、プレゼンスサーバは、プレゼンス情報を受け取り、指標された時間パラメータに基づいてプレゼンス情報をモニタしてイベントシーケンスが少なくとも１回発生したことを検出し、プレゼンス情報がトリガを満たす場合はクライアントエンティティに通知を送る。
【００１０】
トリガ基準の一部としてイベントシーケンスをサブスクリプション内に含めることで、ウォッチャははるかに複雑な「シナリオベースの」通知トリガを設定することができる。さらに、トリガ基準の一部として時間パラメータをサブスクリプション内で指標しまたは特定することにより、ウォッチャは、今度は過去のおよび将来のプレゼンス情報を参照することができる。さらに、ウォッチャは特定のプレゼンス状態がトリガを満たすために遷移しなければならない順序を明確に示すことができ、高度なブール論理を使用していつ通知を行うべきかを設定し、多くの実装形態、とりわけ公共の安全との関連で有用なトリガメカニズムのさらなる柔軟性をもたらすことができる。上記に認められる利点および本明細書に記載する他の利点は例示に過ぎず、様々な実施形態の利点の全てを完全に表すつもりではないことを当業者なら理解されよう。
【００１１】
次に図面、とりわけ図１を参照して、通信システムを例示するブロック図を図示し１００で示し、このシステムは、本開示の実施形態に従いクライアントエンティティに通知を提供する。この詳細な説明の中の例の詳細は一部の実施形態の例示に過ぎず、本明細書に記載の教示は様々な代替的設定において適用できることを当業者なら認識し、理解されよう。例えば記載する実施形態では、通信システム１００内に実装するプレゼンス機能は、独自のプロトコル（図２から図５を参照することにより説明する本開示の諸実施形態を実施するプロトコルなど）、およびＳＩＰ（ＲＦＣ３２６１内に記載のセッション開始プロトコル）を利用するＳＩＰ／ＳＩＭＰＬＥベースのプレゼンスサービス用のアプリケーションレベルの仕様を定める、オープンモバイルアライアンス（ＯＭＡ）によって発行されたＰｒｅｓｅｎｃｅ ＳＩＭＰＬＥ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（２００９年２月３日付け最新ドラフト）や、ＳＩＰを用いたインスタントメッセージングおよびプレゼンスについて記載する、インターネット技術標準化委員会（ＩＥＴＦ）によって発行されたＳＩＭＰＬＥ ｍａｄｅ ｓｉｍｐｌｅ（２００９年３月９日付け最新ドラフト）などの標準プロトコルを使用して実行し、本明細書では標準プレゼンスプロトコルを一括してＳＩＰ／ＳＩＭＰＬＥと呼ぶ。ただし、記載する教示はこのシステム実装形態に限定されることは決してない。さらに本システムは、図１に示すよりも多くのウォッチャ、プレゼンティティ、プレゼンスサーバ、通信装置、および他のエンティティを含むことができる。
【００１２】
通信システム１００は、プレゼンスサーバ１２０、通信装置１１２を使用するユーザ１１０、および通信装置１３２を使用するユーザ１３０を含み、通信装置１１２および１３２ならびにプレゼンスサーバ１２０は、本明細書の教示に従いプレゼンス情報をサブスクライブし、対応するプレゼンス情報を通知するためにネットワーク（図示せず）を介して全て通信可能に結合される。ネットワークは有線ネットワーク、無線ネットワーク、または有線通信および無線通信の両方を可能にするネットワークとすることができ、通常、ブリッジ、スイッチ、ゾーンコントローラ、基地局コントローラ、中継器、無線基地局、基地局、ベーストランシーバ基地局、アクセスポイント、ルータ、または無線環境もしくは有線環境内の任意のエンティティとインターフェイスする他の任意の種類のインフラ機器を含むがこれだけに限定されない、いくつかのネットワークインフラ装置を含む。
【００１３】
通信装置１１２および１３２（本明細書では「クライアントエンティティ」と呼ぶ）は、当技術分野ではアクセス装置、アクセス端末、ユーザ機器、移動局、移動加入者ユニット、モバイル機器等とも呼ばれ、無線機、携帯電話、携帯情報端末（ＰＤＡ）、ラップトップ、送受信兼用無線機、セルフォン、および有線環境または無線環境内で動作することができる他の任意の装置など、任意の標準的な通信装置とすることができる。各通信装置は、（図示せずだが）動作可能に結合されるメモリ、１つまたは複数のネットワークインターフェイス、および処理装置を含む。
【００１４】
ネットワークインターフェイスは、プレゼンティティのプレゼンス情報をプレゼンスサーバ１２０に発行すること、プレゼンティティのプレゼンス情報をサブスクライブし、サブスクライブすることの結果として、本明細書の教示に従いプレゼンスサーバ１２０から通知を受け取ること、および本教示による方法を実施できるようにするためのプレゼンスサーバ１２０との他の通信のうちの１つまたは複数のために使用することができる。ネットワークインターフェイスの実装形態は、通信装置が接続するネットワークの特定の種類、すなわち有線および／または無線によって決まる。例えばネットワークが有線通信をサポートする場合、インターフェイスには（例えばＲＳ−２３２標準に準拠する）シリアルポートインターフェイス、パラレルポートインターフェイス、イーサネット（登録商標）インターフェイス、ＵＳＢインターフェイス、および／またはファイヤワイヤインターフェイス等が含まれ得る。ネットワークが無線通信をサポートする場合、インターフェイスには、１つまたは複数の任意の標準無線インターフェイスまたは独自の無線インターフェイスに従って動作可能な処理要素、変調要素、およびトランシーバ要素を含む要素が含まれ、その処理要素、変調要素、およびトランシーバ要素の機能の一部は、通信装置のメモリ装置上に記憶されるソフトウェアアプリケーションやファームウェアなどのプログラムドロジックにより、通信装置の処理装置内で実行されてもよい。
【００１５】
プログラムドロジックまたはコードによって実施される上述の機能に加えて、各通信装置の処理装置は、図２を参照することにより以下に記載する方法３００などの方法を実施するためのロジックまたはコードでさらにプログラムされ、かつ／または処理装置は状態機械もしくはＡＳＩＣとして実装することができる。通信装置内のメモリは、通信装置が機能するために必要な様々なデータ、例えばプレゼンス情報、構成情報等の短期記憶域および／または長期記憶域を含むことができる。メモリは、処理装置の機能を実行するために必要なロジックまたはコードで処理装置をプログラムするためのソフトウェアまたはファームウェアをさらに記憶することができる。
【００１６】
次にプレゼンスサーバ１２０を参照して、プレゼンスサーバ１２０は、メモリ１２２、１つまたは複数のネットワークインターフェイス１２４、およびプレゼンスサーバ１２０の機能を実行するために動作可能に結合される処理装置１２６を含む。ネットワークインターフェイス１２４は、プレゼンスサーバ１２０が接続する特定のネットワークに応じて有線、無線、またはその両方の組合せ（例は上述した）とすることができる。処理装置１２６は、自らの機能を実行するためのロジックまたはコードでプログラムすることができ、ロジックはソフトウェアおよび／またはファームウェアとしてメモリ１２２内に記憶され（例は上述した）、かつ／または処理装置１２６は状態機械もしくはＡＳＩＣとして実装することができる。
【００１７】
動作面では、プレゼンスサーバ１２０は、クライアントエンティティからのいくつかの発行メッセージ（例えばＳＩＰ／ＳＩＭＰＬＥ ＰＵＢＬＩＳＨメッセージとすることができる装置１３２からのメッセージ１３５など）のそれぞれの中で、プレゼンティティに関連するプレゼンス情報要素の値を受け取る。特定のプレゼンティティに関連するプレゼンス情報は１つまたは複数のプレゼンス情報要素を含み、プレゼンティティは概して、異なるまたは同じプレゼンス情報要素についてある期間にわたり多くの発行メッセージを送る。プレゼンスサーバ１２０は、現在値を（メモリ１２２内に）保持し、一部の実施形態では、１つまたは複数のプレゼンティティの少なくとも１つのプレゼンス情報要素に関する１組の（１つまたは複数の）以前のまたは過去の値をさらに保持する。
【００１８】
プレゼンスサーバ１２０は、ウォッチャからの１つまたは複数のサブスクライブメッセージ（例えばＳＩＰ／ＳＩＭＰＬＥ ＳＵＢＳＣＲＩＢＥメッセージとすることができるサブスクライブメッセージ１１５など）の中で、１つまたは複数のプレゼンティティのイベントシーケンスに関して通知されるための要求をさらに受け取り、イベントシーケンスはプレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義し、サブスクライブ要求はイベントシーケンスの時間パラメータをさらに指標する。サブスクライブ要求に応答して、プレゼンスサーバ１２０は、指標された時間パラメータに基づいてプレゼンス情報を受け取りモニタしてイベントシーケンスの発生を検出し、モニタしたプレゼンス情報がトリガを満たす場合はウォッチャに（例えば１つまたは複数のＳＩＰ／ＳＩＭＰＬＥ ＮＯＴＩＦＹメッセージの中で）通知を提供する（１２５）。
【００１９】
本明細書で使用する用語の一部についての定義は、開示する教示を理解するのに役立つ。例えば、プレゼンスサーバは、プレゼンス情報またはプレゼンス情報に関連する他のデータを受け付け、記憶し、配信する機能エンティティとして定義される。プレゼンス情報は、通信するためのプレゼンティティの状態、到達可能性、意思、および／または能力を示す、プレゼンティティに関連する１組の動的情報として定義される。プレゼンス情報には、例えばユーザの連絡可能性、位置、ネットワークの可用性、ユーザの気分、移動方向、速度、目的地、目的地に到達する推定時間、目的地からの距離、インシデント局面、完了した割合、段階、またはインシデント中の指定されたタスクの局面などの状態情報が含まれるがこれだけに限定されない。プレゼンス情報は１つまたは複数のプレゼンス情報要素からなり、プレゼンス情報要素はプレゼンス情報の基本単位として定義される。プレゼンス情報要素は、現在の英数字値（本明細書では単に値とも呼ぶ）および／または１組の（すなわち１つまたは複数の）過去の値に関連することができる。プレゼンス情報要素の値は、所与の時点におけるそのプレゼンス情報要素についてのプレゼンスに関係する状態として定義される。例えばプレゼンス情報要素の値は、「不在」、「職場にいない」などのユーザの状態を定義することができる。さらに、特定の時点におけるプレゼンティティに関するいくつかのプレゼンス情報要素の１組の現在値は、その特定の時点におけるプレゼンティティのプレゼンス状態を表す。
【００２０】
ウォッチャは、１つまたは複数のプレゼンティティに関する特定のプレゼンス情報をサブスクライブする、装置内の一意に識別することができる論理エンティティとして定義される。プレゼンティティは、プレゼンス情報によって述べられる論理エンティティとして定義される。プレゼンティティは、装置および／または人に相当することができ、サーバ、ビル、車両、アプリケーション、または他の論理エンティティおよび物理エンティティが含まれる他の種類のエンティティに相当することもできるがこれだけに限定されない。さらに、複数のプレゼンティティをプレゼンスリソースリスト（ＰＲＬ）によって識別することができ、プレゼンスリソースリストは、ウォッチャによる単一の操作（ｓｉｎｇｌｅ ｏｐｅｒａｔｉｏｎ）において従来よりサブスクライブされている、プレゼンティティの定義済みリスト（例えば「バディリスト」）として定義される。
【００２１】
サブスクリプション（本明細書ではサブスクライブ要求とも呼ぶ）は、サブスクリプション内で定義される１つまたは複数のトリガが満たされているときに後続の通知を得るための、クライアントエンティティからプレゼンスサーバへの要求として定義される。したがって通知は、関連する通知内で定義されるトリガの１つまたは複数が、プレゼンスサーバにおいて受け取られるプレゼンス情報によって満たされているときにプレゼンスサーバがクライアントエンティティに送る応答として定義される。イベントシーケンスは１組の複数のイベントとして定義され、シーケンスの中のイベントの少なくとも２つはある期間にわたり連続して、または異なる時間に（すなわち非同期的に）発生しなければならない。イベントは、１つまたは複数のプレゼンス情報要素に関するある値から別の値への状態遷移として定義され、複数のプレゼンス情報要素によって定義されるイベントでは、全ての要素についての状態遷移は同期的でも非同期的でもよい。したがって、イベントはそれ自体が、自らの順序付きまたは無順序のイベントのシーケンスによって定義される「サブシーケンス」を含むことができる。
【００２２】
次に図２から図４を参照する。図２では、イベントシーケンスに基づいてプレゼンス通知を受け取るためにサブスクライブするための方法を例示する流れ図を図示し、２００で示す。この方法２００のステップの少なくとも一部を、図１に示すクライアントエンティティ１１２などのクライアントエンティティが実行する。図３は、イベントシーケンスに基づいてプレゼンスを通知するための対をなす方法３００の流れ図を例示し、図４は、モニタするプレゼンス情報が通知を送るためのトリガを満たす様々な条件を示す流れ図４００を例示する。一実施形態では、図３および図４に示す機能をプレゼンスサーバ１２０などのプレゼンスサーバによって実施するが、記載する機能の一部をプレゼンスサーバ１２０の外部にある１つまたは複数の補助ハードウェアユニットにおいて実行してもよい。さらに、本明細書の記載に関して、図２から図５の流れ図を参照することにより例示し説明する機能は、例えば自らの機能を実行するようにロジックまたはコードでプログラムされる処理装置（例は以下に示す）であって、そのロジックはソフトウェアおよび／またはファームウェアとして適切なメモリ装置の中に記憶される、処理装置を用いてかつ／または状態機械もしくはＡＳＩＣとして実装される処理装置を用いて実行することができる。
【００２３】
まず図２に示す方法２００を参照して、２０２で、クライアントエンティティ１１２がプレゼンティティへのサブスクリプションを生成する。サブスクリプションは、プレゼンスサーバがクライアントエンティティ１１２に通知を送る時を管理するトリガを定義する（順序付きまたは無順序の）イベントシーケンスを含み、そのイベントシーケンスの時間パラメータをさらに特定しまたは他の方法で指標する。トリガメカニズムをイベントシーケンスおよび時間パラメータに基づかせることは、トリガを定義する際のさらなる柔軟性をもたらす。
【００２４】
イベントシーケンスに基づいて多くのトリガを定義することができる。そうしたトリガ定義の例には、イベントシーケンスの中の全てのイベントが発生したことを検出するとき、またはイベントシーケンスの中の全てのイベントが発生したが、１つもしくは複数の介在イベントの発生と共に発生したことを検出するとき、またはイベントシーケンスの中のイベントの１つもしくは複数が発生しないことを検出するとき、またはイベントシーケンスの中に含まれていないさらなるイベントの発生を検出するとき、またはイベントシーケンスの中の全てのイベントが発生したが、時間パラメータを満たさないことを検出するとき、（イベントシーケンスが順序付けされているか、それとも無順序か、すなわち指定された順序を有さないかに関係なく）トリガが満たされているものとして定義することが含まれるが、これだけに限定されない。さらに、イベントシーケンスが順序付けられている場合、実例として、イベントシーケンスの中の全てのイベントが発生したが、指定された順序で発生していないことを検出するとき、トリガが満たされているものとして定義することができ、「順序」とは、イベント自体の間の順序や、（イベントがサブシーケンスを含む場合）イベント自体の間の順序ではなくサブシーケンス内の順序など、これだけに限定されないが、シーケンスの中の１つまたは複数のイベントについて指定される任意の順序である。そのようなトリガが満たされていることを検出するプレゼンスサーバについてのさらなる説明および特定の例を、例えば図４に付随する説明を参照することにより以下に示す。
【００２５】
イベントシーケンスの時間パラメータに関して、「時間パラメータ」は、シーケンスの中の１つまたは複数のイベントについて設けられる任意の時間的制約または時間制限を含めるために定義し、本開示のサブスクリプションおよび通知メカニズムにおいて大幅な柔軟性ももたらす。さらに、既知の通知メカニズムとの相違点として、本教示は（以下に示す例を用いてさらに説明するように）サブスクリプション内で提供される時間パラメータに基づいて、またはそうした時間パラメータの指針の下で、イベントシーケンス内の状態遷移のタイミングを考慮する。ところが既知の技術では、全ての遷移が同期的に生じるので状態遷移のタイミングは考慮されない。一例では時間パラメータが明確に指定されず、サブスクリプション内に時間パラメータを明確に含めないことは、トリガが１回または複数回満たされることをプレゼンスサーバが検出するまで（無限の時間にわたって）継続する暗黙のデフォルト時間パラメータを暗に示す。
【００２６】
あるいはイベントシーケンスの時間パラメータは、いくつもの方法を用いてサブスクリプション内で明確に指定し、または指標することができる。以下の時間パラメータの例では、本開示の諸実施形態の理解を助けるためにイベントシーケンスを、イベントＡ、Ｂ、およびＣを含むものとして定義し、各イベントは１つまたは複数のプレゼンス情報要素に関する状態遷移を含み、これらのイベントのうちの少なくとも２つは非同期的に（すなわち異なる時間に）発生する。例えば、イベントＡは「ａ」の値が割り当てられるプレゼンス情報要素Ａであり、イベントＢは「ｂ」の値が割り当てられるプレゼンス情報要素Ｂであり、イベントＣは「ｃ」の値が割り当てられるプレゼンス情報要素Ｃである。
【００２７】
一例示的実装形態では、時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間である。例えばその時間パラメータは、イベントＡ、Ｂ、およびＣが発生しないかどうか、午後１時から午後３時までに受け取るプレゼンス情報をモニタし、その時間枠内でイベントシーケンスが発生する場合は通知を送るようにプレゼンスサーバに指標する。これは絶対的時間制限、この場合はイベントの全段階の発生についての総時間制限の一例でもある。さらに、シーケンスの中のイベントの１つまたは複数が、その独自の個々の絶対的時間制限に関連することができる。例えば、イベントＡは午後１：３０までに発生しなければならず、イベントＢは午後２時までに発生しなければならない。
【００２８】
あるいは時間パラメータは、両方ではないが開始時間または終了時間だけの制限がある場合がある。さらに、開始時間を含めることにより、サブスクリプションは、過去のイベントの発生をモニタするようにプレゼンスサーバに明確に指図することができる。より具体的には、一実装形態ではサブスクリプション内で指定される開始時間は、そのサブスクリプションをクライアントエンティティが送り、プレゼンスサーバが受け取る前に発生したプレゼンス情報のモニタ開始時間を指定する。したがってプレゼンスサーバは、プレゼンスサーバがアクセス可能な位置に記憶された過去のプレゼンス情報をモニタすることになる。
【００２９】
さらに別の例示的実装形態では、時間パラメータが、イベントの発生に関する２つ以上のイベント間の相対的時間制限を含む。例えば、イベントシーケンスの中のイベント間のそれぞれの「遷移」は、その遷移に関連する時間制限または時間枠を有することができ、例えばイベントＡの発生後、イベントＢは１５分以内に発生しなければならず、イベントＢの発生後、イベントＣは３０分以内に発生しなければならない。
【００３０】
この相対的時間制限の実装形態ではさらに、サブスクリプションは、通知を送ることができる時間枠を制限するサブスクリプションの時間パラメータをさらに含むことができる。したがって、これらの２つの時間枠の間で何らかの相互関係があり得る。例えばｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅが、シーケンスが発生するための時間制限であり、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎが、そのシーケンスが発生するときに通知がなされる時間制限である場合（例えばｓｕｂｓｃｒｉｐｔｉｏｎＴｉｍｅＦｒａｍｅの値は、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージのヘッダ内で提供される）、ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅ（例えばこのイベントシーケンスは互いに３０分以内に起こらなければならない）が、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎ（イベントシーケンスが今後１週間の間に完了するときはいつも通知してください）未満の場合、イベントの完了を追跡する状態機械は自己リセットしなければならない。
【００３１】
言い換えれば、トリガが全て互いに３０分の範囲（ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅ）内でＡ→Ｂ→Ｃとして定義されると仮定する。Ａ→Ｂ→Ｃが３０分以内に発生する場合クライアントエンティティは通知され、状態機械は再びリセットされてＡ→Ｂ→Ｃを待ち、必要に応じて再度（最長１週間、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎまで）通知を行う。同様にＡ→Ｂだが、Ｃが３０分以内にない場合、Ａの３０分後に状態機械はクリアされ、プレゼンスサーバは再度Ａ→Ｂ→Ｃがないかどうかモニタする。ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅは、無順序のイベントについて「循環」させることもでき、したがって互いに３０分以内にＡ＝真、Ｂ＝真、およびＣ＝真であることを要求し、かつＴ＝０分においてＡ＝真、Ｔ＝１５分においてＢ＝真、Ｔ＝３５分においてＣ＝真である場合、Ａ、Ｂ、Ｃのシーケンスは３０分以内に完了しないが、ここでＡ＝真がＴ＝４５分において再び発生する場合、（無順序イベントの基準を満たす）Ｂ、Ｃ、Ａは、Ｔ＝１５分において開始してＴ＝４５分において完了し、３０分以内に発生する。そのため３０分のクロックは、Ｔ＝１５分におけるＢ＝真で「リセット」された。
【００３２】
さらに別の例示的実装形態では、過去のイベント発生および将来のイベント発生を参照するためのトリガの設定ならびに時間パラメータの指標を、一例示的実装形態では高度なブール論理によって達成する。当然ながら上記の実装形態は全て実装形態の例に過ぎず、本明細書の教示の範囲を限定することを意図するものでは決してない。
【００３３】
上記に述べたように、サブスクリプションは、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ形式とすることができる。拡張ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの２つの例を以下に示す。最初の例では、プレゼンスウォッチャ（ＣｏｍｍａｎｄｅｒＸ＠ａｇｅｎｃｙ．ｇｏｖ）は、１日にわたってＩｎｃｉｄｅｎｔ１２３４にあらかじめ割り当てられたグループｏｆｆｉｃｅｒｓ＠ａｇｅｎｃｙ．ｇｏｖ内の任意のユーザが連絡可能になるたびに（それまでにこれらの職員に他のどんなインシデントが割り当てられている可能性があるかに関係なく）通知されることを望む。
【００３４】
【数１】
行（１）はＳＩＰ／ＳＩＭＰＬＥの拡張であり、本明細書の教示を実施するための新たなＸＭＬネームスペースを含み、行（２）は、イベントシーケンスに基づくトリガを定義する。
【００３５】
別の例では、プレゼンスウォッチャ（ＳｕｐｅｒｖｉｓｏｒＹ＠ａｉｒｐｏｒｔ．ｇｏｖ）は、この１２時間のうちにリストｅｍｐｌｏｙｅｅｓ＠ａｉｒｐｏｒｔ．ｇｏｖ内の任意のユーザがドア３、５、６を（この順序で）成功裏に横切るたびに通知されることを望む。
【００３６】
【数２】
行（３）はＸＭＬネームスペースであり、行（４）から（６）はイベントシーケンスに基づくトリガを特定する。図２に戻り、クライアントエンティティがサブスクリプションをプレゼンスサーバに送り（２０４）、モニタされるプレゼンス情報がトリガを満たす場合はプレゼンスサーバから通知を受け取る（２０６）。一実施形態では、トリガを満たした複数のイベントを通知が明らかにする。
【００３７】
次に図３を参照して、３０２でプレゼンスサーバは、イベントシーケンスによりトリガが定義された状態のサブスクリプションであって、時間パラメータをさらに指標する、サブスクリプションを受け取る。サブスクリプションを受け取ると、プレゼンスサーバは、イベントシーケンスの発生を検出するために、自らが受け取るプレゼンス情報を指標された時間パラメータに基づいてモニタする（３０４）。上記に述べたように、そのようなモニタリングには、記憶された過去のプレゼンス情報をモニタすることが含まれ得る。モニタされるプレゼンス情報がサブスクリプション内で定義されるトリガを満たすとき、プレゼンスサーバはクライアントエンティティに通知を送る（３０６）。
【００３８】
図４は、プレゼンスサーバがプレゼンス情報をモニタすること、およびモニタするプレゼンス情報がトリガを満たすと検出すること（４０２）を示す。代替的な検出シナリオ４０４から４１４を例示する。４０４で、モニタされるプレゼンス情報は、シーケンスの中の全てのイベントが、介在イベントなしの「厳密な」シーケンスで、または１つもしくは複数の介在イベントを伴う「無規律な」シーケンス（４０６）で発生したことをプレゼンスサーバが検出するときにトリガを満たす。例えば厳密な無順序のシーケンスでは、イベントＡおよびＢおよびＣは全て任意の順序で発生するが、他のイベントは発生しない（例えばＢ→Ａ→Ｃや、さらにはＡ→Ｂ→Ａ→Ｃ）。無規律な無順序のシーケンスでは、全てのイベントが、それらのイベントの間に他の可能な非列挙イベントを伴って任意の順序で発生する（例えばＣ→Ｂ→Ｘ→Ａ）。厳密な順序付きのシーケンスでは、Ａの後にＢ、その後にＣと、それらの間に何も介在しない。さらに、無規律な順序のシーケンスでは、Ａの後にＢかつＢの後にＣだが、それらの間に他の何らかのイベントが発生し得る（例えばＡ→Ｘ→Ｂ→Ｙ、Ｚ→Ｃ）。
【００３９】
４０８で、シーケンスの中の１つまたは複数のイベントが発生しないことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。このシナリオは、無順序のイベントシーケンスおよび順序付きのイベントシーケンスの両方に適用することができる。
【００４０】
４１０で、シーケンスの中に含まれていなかった追加のイベントが発生したことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。図５を参照することによる第３のＳＩＰ ＳＵＢＳＣＲＩＢＥの例および付随する説明が、このトリガシナリオを例示する。さらなる例において、厳密な無順序のシーケンスの不履行では、全てのイベントが発生するが、列挙したイベントのいずれかの間に非列挙イベントが発生する（例えばＡ→Ｂ→Ｘ→Ｃや、Ｃ→Ｂ→Ｘ→Ａ）。厳密な順序付きのシーケンスの不履行では、全てのイベントが指定された順序で発生するが、厳密な順序付きのイベントのいずれかの間に非列挙イベントが発生する（例えばＡ→Ｂ→Ｘ→Ｃ）。
【００４１】
４１２で、シーケンスの中の全てのイベントが発生したが、時間パラメータを満たさなかったことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。この例示的実装形態に対応するものとして上記に例を示した。さらに、検出シナリオ４１２は、順序付きのイベントシーケンスおよび無順序のイベントシーケンスの両方に適用することができる。
【００４２】
４１４で、シーケンスの中の全てのイベントが発生したが、（順序付きのイベントシーケンスについての）指定された順序で発生していないことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。例えば順序付きのシーケンスの不履行では、全てのイベントが発生するが、指定された順序から外れている（例えばＢ→Ａ→Ｃ）。これらの例示的シナリオのいずれかについてトリガが満たされていると判定すると、プレゼンスサーバは、サブスクリプション内で提供される指図に応じてまたはトリガを満たしたイベントを明らかにするデータを供給することに関するデフォルトに応じて、トリガを満たしたイベントを明らかにした状態で、または明らかにすることなしにクライアントエンティティに通知を送る（４１６）。
【００４３】
図５は、サブスクリプションを受け取ることに応答してプレゼンスサーバがプレゼンス情報をモニタし、順序付きのシーケンスが不履行に終わる場合にクライアントエンティティに通知を行う絵図を示す。この例示的実装形態ではクライアントエンティティが以下のＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを送り、プレゼンスウォッチャ（ｓｅｃｕｒｉｔｙ＠ｂａｎｋ．ｃｏｍ）はウォッチャユーザ（ａｒｍｏｒｅｄｃａｒ＠ｂａｎｋ．ｃｏｍ）が明日、１組の特定の状態遷移に従わない場合かつその場合に限り通知されることを望む。
【００４４】
【数３】
行（７）はＸＭＬネームスペースであり、行（８）から（１２）はトリガを定義し、そのトリガは、介在イベントなしに装甲車の進路に沿って指定された時間に発生することが予想される順序付きのイベントシーケンスを基本的に定義する。指定されていない介在イベントが発生することおよび／または時間基準を満たさないことが原因でこのシーケンスが不履行に終わることは、クライアントエンティティに通知が送られることを引き起こす。
【００４５】
図５は、サブスクリプションに対応するものとして、モニタされる例示的プレゼンス情報を示す。８：１０に（プレゼンティティａｒｍｏｒｅｄｃａｒ＠ｂａｎｋとして特定する）装甲トラック（５０４）がその現在地（５０２）を出発して進路を開始し、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（８）に定める）８：００〜８：１５の間に出発するというシーケンスの中の第１のイベントを満たす（５０６）。９：１５に装甲トラックは最初の停止のために銀行５０８に到着し、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（９）に定める）９：００〜９：３０の間に銀行に到着するというシーケンスの中の第２のイベントを満たす（５１０）。１２：１５に、装甲トラックは昼食のために停止し（５１２）、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（１０）に定める）１２：００〜１３：００の間の昼食時間というシーケンスの中の第３のイベントを満たす（５１４）。
【００４６】
しかし３：１５に強奪（５１６）が発生し、この強奪は、（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（１１）に定める）１３：３０〜１４：００の間に装甲トラックがその最終目的地（５１８）に到着するのを妨げ、それによりシーケンスを不履行に終わらせ、ｓｅｃｕｒｉｔｙ＠ｂａｎｋ．ｃｏｍにおけるセキュリティサービスへの通知（５２０）をトリガする。とりわけこの例は、諸実施形態を将来のイベントに適用できることを強調する。さらにこの例は、高度なブール論理（否定論理積）の使用を示す。最後にこの例は、混在する順序付き／無順序の基準の使用を示す。ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ内の最後の要素（行１２）は、明日のある時点でａｒｍｏｒｅｄｃａｒ＠ｂａｎｋが自らの積荷の配送状態を「配送済み」に設定することを単純に要求し、これは銀行１または銀行２に訪れた後に発生することができるが、この場合は強奪により発生しなかった。
【００４７】
上記の明細書で特定の実施形態について説明してきた。ただし、添付の特許請求の範囲に記載する本発明の範囲から逸脱することなしに、様々な修正および変更を加えてもよいことを当業者なら理解されよう。したがって、本明細書および図面は限定的な意味ではなく例示的な意味としてみなすべきであり、そのようなあらゆる修正は本教示の範囲に含まれることを目的とする。
【００４８】
これらの利益、利点、問題に対する解決策、および何らかの利益、利点、もしくは解決策を発生させることができ、またはより顕著にすることができる任意の要素は、いずれかのまたは全ての請求項の重大な、所要の、または不可欠の特徴もしくは要素として解釈すべきでない。本発明は、本願の係属中に加えられる任意の補正を含む添付の特許請求の範囲、および発行されるそれらの請求項のあらゆる等価物によってのみ定められる。
【００４９】
さらにこの文書では、第１のと第２の、上部と下部などの関係語は、あるエンティティまたは行為を別のエンティティまたは行為と単に区別するために、そのようなエンティティまたは行為間のそのようないかなる実際の関係または順序も必ずしも必要とすることなしに、もしくは暗に示すことなしに使用することができる。用語「備える（ｃｏｍｐｒｉｓｅｓ）」、「備えている（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｓ）」、「有している（ｈａｖｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「含有する（ｃｏｎｔａｉｎｓ）」、「含有している（ｃｏｎｔａｉｎｉｎｇ）」、またはそれらの他の任意の改変形態は、非排他的な包含をカバーすることを目的とし、それにより、列挙の要素を備え、有し、含み、含有するプロセス、方法、物品、または機器はそれらの要素だけを含むのではなく、明確に列挙していない他の要素またはそのようなプロセス、方法、物品、もしくは機器に固有でない他の要素を含んでもよい。「〜を備える（ｃｏｍｐｒｉｓｅｓ．．．ａ）」、「〜を有する（ｈａｓ．．．ａ）」、「〜を含む（ｉｎｃｌｕｄｅｓ．．．ａ）」、「〜を含有する（ｃｏｎｔａｉｎｓ．．．ａ）」が前に来る要素は、より多くの制約を受けることなく、その要素を備え、有し、含み、含有するプロセス、方法、物品、または機器において、同一の要素がさらに存在することを排除するものではない。用語「ａ」および「ａｎ」は、本明細書で明示的に別段の定めをした場合を除き１つまたは複数として定義する。用語「ほぼ（ｓｕｂｓｔａｎｔｉａｌｌｙ）」、「事実上（ｅｓｓｅｎｔｉａｌｌｙ）」、「おおよそ（ａｐｐｒｏｘｉｍａｔｅｌｙ）」、「約（ａｂｏｕｔ）」、またはそれらの他の任意のバージョンは、当業者によって理解されるものに近いものとして定義され、非限定的な一実施形態では、この用語は１０％以内、別の実施形態では５％以内、別の実施形態では１％以内、別の実施形態では０．５％以内であると定義される。本明細書で使用するとき、用語「結合される（ｃｏｕｐｌｅｄ）」は、必ずしも直接的にではなく、かつ必ずしも機械的にではないが接続されているものとして定義する。特定の方法で「構成される（ｃｏｎｆｉｇｕｒｅｄ）」装置または構造は、少なくともその方法で構成されるが、列挙されていない方法で構成することもできる。
【００５０】
一部の実施形態が、マイクロプロセッサ、デジタル信号プロセッサ、特注プロセッサ、書替え可能ゲートアレイ（ＦＰＧＡ）などの、１個または複数の汎用プロセッサもしくは専用プロセッサ（または「処理装置」）、ならびに本明細書に記載の方法および／または機器の機能の一部、大部分、もしくは全てを特定の非プロセッサ回路とともに実施するためにその１個または複数のプロセッサを制御する、記憶された固有のプログラム命令（ソフトウェアおよびファームウェアの両方を含む）からなり得ることが理解されよう。あるいは一部の機能または全ての機能を、記憶されたプログラム命令を有さない状態機械により、または１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）内に実装することができ、各機能または機能のいくつかの一部の組合せはカスタムロジックとして実装される。当然ながら、この２つの手法の組合せを使用することもできる。
【００５１】
さらに、実施形態は、本明細書に記載し権利を主張する方法を実行するように（例えばプロセッサを含む）コンピュータをプログラムするためのコンピュータ可読コードが記憶された、コンピュータ可読記憶媒体として実施することができる。そのようなコンピュータ可読記憶媒体の例には、これだけに限定されないが、ハードディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶装置、ＲＯＭ（読取専用メモリ）、ＰＲＯＭ（プログラム可能読取専用メモリ）、ＥＰＲＯＭ（消去可能プログラム可能読取専用メモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラム可能読取専用メモリ）、およびフラッシュメモリが含まれる。さらに、例えば可用時間、最新の技術、および経済的配慮によって動機付けられる、場合によってはかなりの労力および多くの設計上の選択があったとしても、本明細書に開示した概念および原理によって導かれるとき、当業者はそうしたソフトウェア命令およびプログラムならびにＩＣを最小限の実験で容易に作り出せることが予想される。
【００５２】
本開示の要約は、技術的開示の性質を読者がすぐに確認できるようにするために提供する。要約は、特許請求の範囲またはその意味を解釈するために使用されることも限定するために使用されることもないという理解の下で提出する。さらに上記の詳細な説明では、本開示を簡素化するために様々な実施形態において様々な機能をまとめていることが見て取れる。この開示方法は、権利を主張する実施形態が、それぞれの請求項の中で明確に列挙するよりも多くの特徴を必要とするという意図を反映するものだと解釈すべきでない。むしろ、添付の特許請求の範囲が反映するように、本発明の主題は開示した単一の実施形態の全ての特徴よりも少ない特徴にある。このため、添付の特許請求の範囲は詳細な説明に組み込まれ、各請求項は別々に権利を主張する主題として独立している。
【技術分野】
【０００１】
本開示は、概してプレゼンスサービスに関し、より具体的には、イベントシーケンスに基づいてプレゼンスを通知するための方法に関する。
【背景技術】
【０００２】
技術の進歩に伴い、通信システムはより優れたサービスをユーザに提供することができるようになっている。プレゼンスサービスを利用する一部の応用例では、通信装置が、その通信装置（「プレゼンティティ」）のユーザの状態情報すなわちプレゼンス情報を中央ネットワークエンティティ（「プレゼンスサーバ」）に報告（「発行」）する。プレゼンスサーバは、通信システム内の他のユーザ（「ウォッチャ」）にそのプレゼンス情報を配信（「通知」）する。一般にプレゼンス情報には、通信装置の状態、装置のユーザの連絡可能性、通信装置の位置、装置によって実行されている現在の操作、ユーザの優先通信手段などの情報が含まれる。
【０００３】
標準的なプレゼンス機能は、ウォッチャ（ユーザ、装置、またはアプリケーション）がプレゼンスサーバにサブスクライブして、１つまたは複数のプレゼンティティに関係するプレゼンス情報を受け取ることを可能にする。サブスクリプションは、１つまたは複数のプレゼンティティごとにそれぞれ行うことができるか、または複数のプレゼンティティを含むプレゼンスリソースリストを使用して行うことができる。１つまたは複数の指定したプレゼンティティにサブスクライブすると、その指定したプレゼンティティに関するプレゼンス情報がウォッチャに通知される。
【０００４】
インターネット技術標準化委員会（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のコメント要求（ＲＦＣ）４４６０および４４６１では、ＳＩＰ／ＳＩＭＰＬＥウォッチャがサブスクリプションの一部として通知フィルタ基準を供給できるようにする拡張マークアップ言語（ＸＭＬ）ベースの方法が論じられている。プレゼンスサーバはその基準を評価して、サブスクライブしているウォッチャに通知するかどうか、および通知するときを決定する。しかしＲＦＣ４４６０および４４６１は、ウォッチャが、同時に発生する無順序の複数の同期現行プレゼンス値しか（供給される通知基準内で）参照することを認めない。例えば基準は、プレゼンス情報要素Ａが「ａ１」の値を有し、プレゼンス情報要素Ｂが「ｂ１」の値を同時に有する場合にウォッチャに通知することからなることができる。この単純なサブスクリプション・通知メカニズムは、消費者ユーザにとっては一般に十分である。しかし、このメカニズムは、例えばプレゼンス情報要素の履歴値および将来値、順序付きもしくは無順序のイベントシーケンス、および／またはプレゼンス情報の変化に対応するイベントの時間パラメータに基づいて通知トリガを指定する能力であって、既知のサブスクリプション／通知メカニズムでは利用できない、指定する能力を含むより洗練された技法の恩恵を受ける、公共の安全に関するユーザなどの他の特定のユーザの需要を満たすには不十分である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、イベントシーケンスに基づいてプレゼンスを通知するための方法が求められている。
以下の詳細な説明とともに、別々の図面を通して同様の参照番号が同一の要素または機能的に同様の要素を指す添付図面は本明細書に組み込まれ、本明細書の一部を形成し、特許請求の範囲に記載の本発明を含む概念の諸実施形態をさらに例示し、それらの実施形態の様々な原理および利点を説明する機能を果たす。
【０００６】
図面の中の要素は簡単かつ明瞭にするために示しており、必ずしも縮尺通りに描いているとは限らないことを当業者なら理解されよう。例えば、本発明の諸実施形態を理解する一助となるように、図中の一部の要素の寸法を他の要素に比べて拡大することがある。
【０００７】
図面の中で機器および方法のコンポーネントを従来の記号により必要に応じて示し、本明細書の説明の利益を有する当業者にとってすぐに分かる詳細によって本開示を不明瞭にしないために、本発明の諸実施形態の理解に関連がある特定の詳細だけを図示した。
【図面の簡単な説明】
【０００８】
【図１】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知するための通信システムのブロック図を示す。
【図２】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知できるようにするための、クライアントエンティティにおける方法の流れ図を示す。
【図３】一部の実施形態による、イベントシーケンスに基づいてプレゼンスを通知できるようにするための、プレゼンスサーバにおける方法の流れ図を示す。
【図４】一部の実施形態による、モニタするプレゼンス情報が通知を送るためのトリガを満たすことを、プレゼンスサーバが様々な条件下で検出することを示す流れ図を示す。
【図５】一部の実施形態による、プレゼンスサーバがプレゼンス情報をモニタし、イベントシーケンスに基づいて通知を行うことを例示する絵図を示す。
【発明を実施するための形態】
【０００９】
概して言えば、様々な実施形態に従いクライアントエンティティは、プレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを生成し、サブスクリプションはイベントシーケンスの時間パラメータをさらに指標する。サブスクリプションを受け取ると、プレゼンスサーバは、プレゼンス情報を受け取り、指標された時間パラメータに基づいてプレゼンス情報をモニタしてイベントシーケンスが少なくとも１回発生したことを検出し、プレゼンス情報がトリガを満たす場合はクライアントエンティティに通知を送る。
【００１０】
トリガ基準の一部としてイベントシーケンスをサブスクリプション内に含めることで、ウォッチャははるかに複雑な「シナリオベースの」通知トリガを設定することができる。さらに、トリガ基準の一部として時間パラメータをサブスクリプション内で指標しまたは特定することにより、ウォッチャは、今度は過去のおよび将来のプレゼンス情報を参照することができる。さらに、ウォッチャは特定のプレゼンス状態がトリガを満たすために遷移しなければならない順序を明確に示すことができ、高度なブール論理を使用していつ通知を行うべきかを設定し、多くの実装形態、とりわけ公共の安全との関連で有用なトリガメカニズムのさらなる柔軟性をもたらすことができる。上記に認められる利点および本明細書に記載する他の利点は例示に過ぎず、様々な実施形態の利点の全てを完全に表すつもりではないことを当業者なら理解されよう。
【００１１】
次に図面、とりわけ図１を参照して、通信システムを例示するブロック図を図示し１００で示し、このシステムは、本開示の実施形態に従いクライアントエンティティに通知を提供する。この詳細な説明の中の例の詳細は一部の実施形態の例示に過ぎず、本明細書に記載の教示は様々な代替的設定において適用できることを当業者なら認識し、理解されよう。例えば記載する実施形態では、通信システム１００内に実装するプレゼンス機能は、独自のプロトコル（図２から図５を参照することにより説明する本開示の諸実施形態を実施するプロトコルなど）、およびＳＩＰ（ＲＦＣ３２６１内に記載のセッション開始プロトコル）を利用するＳＩＰ／ＳＩＭＰＬＥベースのプレゼンスサービス用のアプリケーションレベルの仕様を定める、オープンモバイルアライアンス（ＯＭＡ）によって発行されたＰｒｅｓｅｎｃｅ ＳＩＭＰＬＥ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（２００９年２月３日付け最新ドラフト）や、ＳＩＰを用いたインスタントメッセージングおよびプレゼンスについて記載する、インターネット技術標準化委員会（ＩＥＴＦ）によって発行されたＳＩＭＰＬＥ ｍａｄｅ ｓｉｍｐｌｅ（２００９年３月９日付け最新ドラフト）などの標準プロトコルを使用して実行し、本明細書では標準プレゼンスプロトコルを一括してＳＩＰ／ＳＩＭＰＬＥと呼ぶ。ただし、記載する教示はこのシステム実装形態に限定されることは決してない。さらに本システムは、図１に示すよりも多くのウォッチャ、プレゼンティティ、プレゼンスサーバ、通信装置、および他のエンティティを含むことができる。
【００１２】
通信システム１００は、プレゼンスサーバ１２０、通信装置１１２を使用するユーザ１１０、および通信装置１３２を使用するユーザ１３０を含み、通信装置１１２および１３２ならびにプレゼンスサーバ１２０は、本明細書の教示に従いプレゼンス情報をサブスクライブし、対応するプレゼンス情報を通知するためにネットワーク（図示せず）を介して全て通信可能に結合される。ネットワークは有線ネットワーク、無線ネットワーク、または有線通信および無線通信の両方を可能にするネットワークとすることができ、通常、ブリッジ、スイッチ、ゾーンコントローラ、基地局コントローラ、中継器、無線基地局、基地局、ベーストランシーバ基地局、アクセスポイント、ルータ、または無線環境もしくは有線環境内の任意のエンティティとインターフェイスする他の任意の種類のインフラ機器を含むがこれだけに限定されない、いくつかのネットワークインフラ装置を含む。
【００１３】
通信装置１１２および１３２（本明細書では「クライアントエンティティ」と呼ぶ）は、当技術分野ではアクセス装置、アクセス端末、ユーザ機器、移動局、移動加入者ユニット、モバイル機器等とも呼ばれ、無線機、携帯電話、携帯情報端末（ＰＤＡ）、ラップトップ、送受信兼用無線機、セルフォン、および有線環境または無線環境内で動作することができる他の任意の装置など、任意の標準的な通信装置とすることができる。各通信装置は、（図示せずだが）動作可能に結合されるメモリ、１つまたは複数のネットワークインターフェイス、および処理装置を含む。
【００１４】
ネットワークインターフェイスは、プレゼンティティのプレゼンス情報をプレゼンスサーバ１２０に発行すること、プレゼンティティのプレゼンス情報をサブスクライブし、サブスクライブすることの結果として、本明細書の教示に従いプレゼンスサーバ１２０から通知を受け取ること、および本教示による方法を実施できるようにするためのプレゼンスサーバ１２０との他の通信のうちの１つまたは複数のために使用することができる。ネットワークインターフェイスの実装形態は、通信装置が接続するネットワークの特定の種類、すなわち有線および／または無線によって決まる。例えばネットワークが有線通信をサポートする場合、インターフェイスには（例えばＲＳ−２３２標準に準拠する）シリアルポートインターフェイス、パラレルポートインターフェイス、イーサネット（登録商標）インターフェイス、ＵＳＢインターフェイス、および／またはファイヤワイヤインターフェイス等が含まれ得る。ネットワークが無線通信をサポートする場合、インターフェイスには、１つまたは複数の任意の標準無線インターフェイスまたは独自の無線インターフェイスに従って動作可能な処理要素、変調要素、およびトランシーバ要素を含む要素が含まれ、その処理要素、変調要素、およびトランシーバ要素の機能の一部は、通信装置のメモリ装置上に記憶されるソフトウェアアプリケーションやファームウェアなどのプログラムドロジックにより、通信装置の処理装置内で実行されてもよい。
【００１５】
プログラムドロジックまたはコードによって実施される上述の機能に加えて、各通信装置の処理装置は、図２を参照することにより以下に記載する方法３００などの方法を実施するためのロジックまたはコードでさらにプログラムされ、かつ／または処理装置は状態機械もしくはＡＳＩＣとして実装することができる。通信装置内のメモリは、通信装置が機能するために必要な様々なデータ、例えばプレゼンス情報、構成情報等の短期記憶域および／または長期記憶域を含むことができる。メモリは、処理装置の機能を実行するために必要なロジックまたはコードで処理装置をプログラムするためのソフトウェアまたはファームウェアをさらに記憶することができる。
【００１６】
次にプレゼンスサーバ１２０を参照して、プレゼンスサーバ１２０は、メモリ１２２、１つまたは複数のネットワークインターフェイス１２４、およびプレゼンスサーバ１２０の機能を実行するために動作可能に結合される処理装置１２６を含む。ネットワークインターフェイス１２４は、プレゼンスサーバ１２０が接続する特定のネットワークに応じて有線、無線、またはその両方の組合せ（例は上述した）とすることができる。処理装置１２６は、自らの機能を実行するためのロジックまたはコードでプログラムすることができ、ロジックはソフトウェアおよび／またはファームウェアとしてメモリ１２２内に記憶され（例は上述した）、かつ／または処理装置１２６は状態機械もしくはＡＳＩＣとして実装することができる。
【００１７】
動作面では、プレゼンスサーバ１２０は、クライアントエンティティからのいくつかの発行メッセージ（例えばＳＩＰ／ＳＩＭＰＬＥ ＰＵＢＬＩＳＨメッセージとすることができる装置１３２からのメッセージ１３５など）のそれぞれの中で、プレゼンティティに関連するプレゼンス情報要素の値を受け取る。特定のプレゼンティティに関連するプレゼンス情報は１つまたは複数のプレゼンス情報要素を含み、プレゼンティティは概して、異なるまたは同じプレゼンス情報要素についてある期間にわたり多くの発行メッセージを送る。プレゼンスサーバ１２０は、現在値を（メモリ１２２内に）保持し、一部の実施形態では、１つまたは複数のプレゼンティティの少なくとも１つのプレゼンス情報要素に関する１組の（１つまたは複数の）以前のまたは過去の値をさらに保持する。
【００１８】
プレゼンスサーバ１２０は、ウォッチャからの１つまたは複数のサブスクライブメッセージ（例えばＳＩＰ／ＳＩＭＰＬＥ ＳＵＢＳＣＲＩＢＥメッセージとすることができるサブスクライブメッセージ１１５など）の中で、１つまたは複数のプレゼンティティのイベントシーケンスに関して通知されるための要求をさらに受け取り、イベントシーケンスはプレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義し、サブスクライブ要求はイベントシーケンスの時間パラメータをさらに指標する。サブスクライブ要求に応答して、プレゼンスサーバ１２０は、指標された時間パラメータに基づいてプレゼンス情報を受け取りモニタしてイベントシーケンスの発生を検出し、モニタしたプレゼンス情報がトリガを満たす場合はウォッチャに（例えば１つまたは複数のＳＩＰ／ＳＩＭＰＬＥ ＮＯＴＩＦＹメッセージの中で）通知を提供する（１２５）。
【００１９】
本明細書で使用する用語の一部についての定義は、開示する教示を理解するのに役立つ。例えば、プレゼンスサーバは、プレゼンス情報またはプレゼンス情報に関連する他のデータを受け付け、記憶し、配信する機能エンティティとして定義される。プレゼンス情報は、通信するためのプレゼンティティの状態、到達可能性、意思、および／または能力を示す、プレゼンティティに関連する１組の動的情報として定義される。プレゼンス情報には、例えばユーザの連絡可能性、位置、ネットワークの可用性、ユーザの気分、移動方向、速度、目的地、目的地に到達する推定時間、目的地からの距離、インシデント局面、完了した割合、段階、またはインシデント中の指定されたタスクの局面などの状態情報が含まれるがこれだけに限定されない。プレゼンス情報は１つまたは複数のプレゼンス情報要素からなり、プレゼンス情報要素はプレゼンス情報の基本単位として定義される。プレゼンス情報要素は、現在の英数字値（本明細書では単に値とも呼ぶ）および／または１組の（すなわち１つまたは複数の）過去の値に関連することができる。プレゼンス情報要素の値は、所与の時点におけるそのプレゼンス情報要素についてのプレゼンスに関係する状態として定義される。例えばプレゼンス情報要素の値は、「不在」、「職場にいない」などのユーザの状態を定義することができる。さらに、特定の時点におけるプレゼンティティに関するいくつかのプレゼンス情報要素の１組の現在値は、その特定の時点におけるプレゼンティティのプレゼンス状態を表す。
【００２０】
ウォッチャは、１つまたは複数のプレゼンティティに関する特定のプレゼンス情報をサブスクライブする、装置内の一意に識別することができる論理エンティティとして定義される。プレゼンティティは、プレゼンス情報によって述べられる論理エンティティとして定義される。プレゼンティティは、装置および／または人に相当することができ、サーバ、ビル、車両、アプリケーション、または他の論理エンティティおよび物理エンティティが含まれる他の種類のエンティティに相当することもできるがこれだけに限定されない。さらに、複数のプレゼンティティをプレゼンスリソースリスト（ＰＲＬ）によって識別することができ、プレゼンスリソースリストは、ウォッチャによる単一の操作（ｓｉｎｇｌｅ ｏｐｅｒａｔｉｏｎ）において従来よりサブスクライブされている、プレゼンティティの定義済みリスト（例えば「バディリスト」）として定義される。
【００２１】
サブスクリプション（本明細書ではサブスクライブ要求とも呼ぶ）は、サブスクリプション内で定義される１つまたは複数のトリガが満たされているときに後続の通知を得るための、クライアントエンティティからプレゼンスサーバへの要求として定義される。したがって通知は、関連する通知内で定義されるトリガの１つまたは複数が、プレゼンスサーバにおいて受け取られるプレゼンス情報によって満たされているときにプレゼンスサーバがクライアントエンティティに送る応答として定義される。イベントシーケンスは１組の複数のイベントとして定義され、シーケンスの中のイベントの少なくとも２つはある期間にわたり連続して、または異なる時間に（すなわち非同期的に）発生しなければならない。イベントは、１つまたは複数のプレゼンス情報要素に関するある値から別の値への状態遷移として定義され、複数のプレゼンス情報要素によって定義されるイベントでは、全ての要素についての状態遷移は同期的でも非同期的でもよい。したがって、イベントはそれ自体が、自らの順序付きまたは無順序のイベントのシーケンスによって定義される「サブシーケンス」を含むことができる。
【００２２】
次に図２から図４を参照する。図２では、イベントシーケンスに基づいてプレゼンス通知を受け取るためにサブスクライブするための方法を例示する流れ図を図示し、２００で示す。この方法２００のステップの少なくとも一部を、図１に示すクライアントエンティティ１１２などのクライアントエンティティが実行する。図３は、イベントシーケンスに基づいてプレゼンスを通知するための対をなす方法３００の流れ図を例示し、図４は、モニタするプレゼンス情報が通知を送るためのトリガを満たす様々な条件を示す流れ図４００を例示する。一実施形態では、図３および図４に示す機能をプレゼンスサーバ１２０などのプレゼンスサーバによって実施するが、記載する機能の一部をプレゼンスサーバ１２０の外部にある１つまたは複数の補助ハードウェアユニットにおいて実行してもよい。さらに、本明細書の記載に関して、図２から図５の流れ図を参照することにより例示し説明する機能は、例えば自らの機能を実行するようにロジックまたはコードでプログラムされる処理装置（例は以下に示す）であって、そのロジックはソフトウェアおよび／またはファームウェアとして適切なメモリ装置の中に記憶される、処理装置を用いてかつ／または状態機械もしくはＡＳＩＣとして実装される処理装置を用いて実行することができる。
【００２３】
まず図２に示す方法２００を参照して、２０２で、クライアントエンティティ１１２がプレゼンティティへのサブスクリプションを生成する。サブスクリプションは、プレゼンスサーバがクライアントエンティティ１１２に通知を送る時を管理するトリガを定義する（順序付きまたは無順序の）イベントシーケンスを含み、そのイベントシーケンスの時間パラメータをさらに特定しまたは他の方法で指標する。トリガメカニズムをイベントシーケンスおよび時間パラメータに基づかせることは、トリガを定義する際のさらなる柔軟性をもたらす。
【００２４】
イベントシーケンスに基づいて多くのトリガを定義することができる。そうしたトリガ定義の例には、イベントシーケンスの中の全てのイベントが発生したことを検出するとき、またはイベントシーケンスの中の全てのイベントが発生したが、１つもしくは複数の介在イベントの発生と共に発生したことを検出するとき、またはイベントシーケンスの中のイベントの１つもしくは複数が発生しないことを検出するとき、またはイベントシーケンスの中に含まれていないさらなるイベントの発生を検出するとき、またはイベントシーケンスの中の全てのイベントが発生したが、時間パラメータを満たさないことを検出するとき、（イベントシーケンスが順序付けされているか、それとも無順序か、すなわち指定された順序を有さないかに関係なく）トリガが満たされているものとして定義することが含まれるが、これだけに限定されない。さらに、イベントシーケンスが順序付けられている場合、実例として、イベントシーケンスの中の全てのイベントが発生したが、指定された順序で発生していないことを検出するとき、トリガが満たされているものとして定義することができ、「順序」とは、イベント自体の間の順序や、（イベントがサブシーケンスを含む場合）イベント自体の間の順序ではなくサブシーケンス内の順序など、これだけに限定されないが、シーケンスの中の１つまたは複数のイベントについて指定される任意の順序である。そのようなトリガが満たされていることを検出するプレゼンスサーバについてのさらなる説明および特定の例を、例えば図４に付随する説明を参照することにより以下に示す。
【００２５】
イベントシーケンスの時間パラメータに関して、「時間パラメータ」は、シーケンスの中の１つまたは複数のイベントについて設けられる任意の時間的制約または時間制限を含めるために定義し、本開示のサブスクリプションおよび通知メカニズムにおいて大幅な柔軟性ももたらす。さらに、既知の通知メカニズムとの相違点として、本教示は（以下に示す例を用いてさらに説明するように）サブスクリプション内で提供される時間パラメータに基づいて、またはそうした時間パラメータの指針の下で、イベントシーケンス内の状態遷移のタイミングを考慮する。ところが既知の技術では、全ての遷移が同期的に生じるので状態遷移のタイミングは考慮されない。一例では時間パラメータが明確に指定されず、サブスクリプション内に時間パラメータを明確に含めないことは、トリガが１回または複数回満たされることをプレゼンスサーバが検出するまで（無限の時間にわたって）継続する暗黙のデフォルト時間パラメータを暗に示す。
【００２６】
あるいはイベントシーケンスの時間パラメータは、いくつもの方法を用いてサブスクリプション内で明確に指定し、または指標することができる。以下の時間パラメータの例では、本開示の諸実施形態の理解を助けるためにイベントシーケンスを、イベントＡ、Ｂ、およびＣを含むものとして定義し、各イベントは１つまたは複数のプレゼンス情報要素に関する状態遷移を含み、これらのイベントのうちの少なくとも２つは非同期的に（すなわち異なる時間に）発生する。例えば、イベントＡは「ａ」の値が割り当てられるプレゼンス情報要素Ａであり、イベントＢは「ｂ」の値が割り当てられるプレゼンス情報要素Ｂであり、イベントＣは「ｃ」の値が割り当てられるプレゼンス情報要素Ｃである。
【００２７】
一例示的実装形態では、時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間である。例えばその時間パラメータは、イベントＡ、Ｂ、およびＣが発生しないかどうか、午後１時から午後３時までに受け取るプレゼンス情報をモニタし、その時間枠内でイベントシーケンスが発生する場合は通知を送るようにプレゼンスサーバに指標する。これは絶対的時間制限、この場合はイベントの全段階の発生についての総時間制限の一例でもある。さらに、シーケンスの中のイベントの１つまたは複数が、その独自の個々の絶対的時間制限に関連することができる。例えば、イベントＡは午後１：３０までに発生しなければならず、イベントＢは午後２時までに発生しなければならない。
【００２８】
あるいは時間パラメータは、両方ではないが開始時間または終了時間だけの制限がある場合がある。さらに、開始時間を含めることにより、サブスクリプションは、過去のイベントの発生をモニタするようにプレゼンスサーバに明確に指図することができる。より具体的には、一実装形態ではサブスクリプション内で指定される開始時間は、そのサブスクリプションをクライアントエンティティが送り、プレゼンスサーバが受け取る前に発生したプレゼンス情報のモニタ開始時間を指定する。したがってプレゼンスサーバは、プレゼンスサーバがアクセス可能な位置に記憶された過去のプレゼンス情報をモニタすることになる。
【００２９】
さらに別の例示的実装形態では、時間パラメータが、イベントの発生に関する２つ以上のイベント間の相対的時間制限を含む。例えば、イベントシーケンスの中のイベント間のそれぞれの「遷移」は、その遷移に関連する時間制限または時間枠を有することができ、例えばイベントＡの発生後、イベントＢは１５分以内に発生しなければならず、イベントＢの発生後、イベントＣは３０分以内に発生しなければならない。
【００３０】
この相対的時間制限の実装形態ではさらに、サブスクリプションは、通知を送ることができる時間枠を制限するサブスクリプションの時間パラメータをさらに含むことができる。したがって、これらの２つの時間枠の間で何らかの相互関係があり得る。例えばｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅが、シーケンスが発生するための時間制限であり、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎが、そのシーケンスが発生するときに通知がなされる時間制限である場合（例えばｓｕｂｓｃｒｉｐｔｉｏｎＴｉｍｅＦｒａｍｅの値は、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージのヘッダ内で提供される）、ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅ（例えばこのイベントシーケンスは互いに３０分以内に起こらなければならない）が、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎ（イベントシーケンスが今後１週間の間に完了するときはいつも通知してください）未満の場合、イベントの完了を追跡する状態機械は自己リセットしなければならない。
【００３１】
言い換えれば、トリガが全て互いに３０分の範囲（ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅ）内でＡ→Ｂ→Ｃとして定義されると仮定する。Ａ→Ｂ→Ｃが３０分以内に発生する場合クライアントエンティティは通知され、状態機械は再びリセットされてＡ→Ｂ→Ｃを待ち、必要に応じて再度（最長１週間、ｓｕｂｓｃｒｉｐｔｉｏｎＥｘｐｉｒａｔｉｏｎまで）通知を行う。同様にＡ→Ｂだが、Ｃが３０分以内にない場合、Ａの３０分後に状態機械はクリアされ、プレゼンスサーバは再度Ａ→Ｂ→Ｃがないかどうかモニタする。ｓｅｑｕｅｎｃｅＴｉｍｅＦｒａｍｅは、無順序のイベントについて「循環」させることもでき、したがって互いに３０分以内にＡ＝真、Ｂ＝真、およびＣ＝真であることを要求し、かつＴ＝０分においてＡ＝真、Ｔ＝１５分においてＢ＝真、Ｔ＝３５分においてＣ＝真である場合、Ａ、Ｂ、Ｃのシーケンスは３０分以内に完了しないが、ここでＡ＝真がＴ＝４５分において再び発生する場合、（無順序イベントの基準を満たす）Ｂ、Ｃ、Ａは、Ｔ＝１５分において開始してＴ＝４５分において完了し、３０分以内に発生する。そのため３０分のクロックは、Ｔ＝１５分におけるＢ＝真で「リセット」された。
【００３２】
さらに別の例示的実装形態では、過去のイベント発生および将来のイベント発生を参照するためのトリガの設定ならびに時間パラメータの指標を、一例示的実装形態では高度なブール論理によって達成する。当然ながら上記の実装形態は全て実装形態の例に過ぎず、本明細書の教示の範囲を限定することを意図するものでは決してない。
【００３３】
上記に述べたように、サブスクリプションは、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ形式とすることができる。拡張ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの２つの例を以下に示す。最初の例では、プレゼンスウォッチャ（ＣｏｍｍａｎｄｅｒＸ＠ａｇｅｎｃｙ．ｇｏｖ）は、１日にわたってＩｎｃｉｄｅｎｔ１２３４にあらかじめ割り当てられたグループｏｆｆｉｃｅｒｓ＠ａｇｅｎｃｙ．ｇｏｖ内の任意のユーザが連絡可能になるたびに（それまでにこれらの職員に他のどんなインシデントが割り当てられている可能性があるかに関係なく）通知されることを望む。
【００３４】
【数１】
行（１）はＳＩＰ／ＳＩＭＰＬＥの拡張であり、本明細書の教示を実施するための新たなＸＭＬネームスペースを含み、行（２）は、イベントシーケンスに基づくトリガを定義する。
【００３５】
別の例では、プレゼンスウォッチャ（ＳｕｐｅｒｖｉｓｏｒＹ＠ａｉｒｐｏｒｔ．ｇｏｖ）は、この１２時間のうちにリストｅｍｐｌｏｙｅｅｓ＠ａｉｒｐｏｒｔ．ｇｏｖ内の任意のユーザがドア３、５、６を（この順序で）成功裏に横切るたびに通知されることを望む。
【００３６】
【数２】
行（３）はＸＭＬネームスペースであり、行（４）から（６）はイベントシーケンスに基づくトリガを特定する。図２に戻り、クライアントエンティティがサブスクリプションをプレゼンスサーバに送り（２０４）、モニタされるプレゼンス情報がトリガを満たす場合はプレゼンスサーバから通知を受け取る（２０６）。一実施形態では、トリガを満たした複数のイベントを通知が明らかにする。
【００３７】
次に図３を参照して、３０２でプレゼンスサーバは、イベントシーケンスによりトリガが定義された状態のサブスクリプションであって、時間パラメータをさらに指標する、サブスクリプションを受け取る。サブスクリプションを受け取ると、プレゼンスサーバは、イベントシーケンスの発生を検出するために、自らが受け取るプレゼンス情報を指標された時間パラメータに基づいてモニタする（３０４）。上記に述べたように、そのようなモニタリングには、記憶された過去のプレゼンス情報をモニタすることが含まれ得る。モニタされるプレゼンス情報がサブスクリプション内で定義されるトリガを満たすとき、プレゼンスサーバはクライアントエンティティに通知を送る（３０６）。
【００３８】
図４は、プレゼンスサーバがプレゼンス情報をモニタすること、およびモニタするプレゼンス情報がトリガを満たすと検出すること（４０２）を示す。代替的な検出シナリオ４０４から４１４を例示する。４０４で、モニタされるプレゼンス情報は、シーケンスの中の全てのイベントが、介在イベントなしの「厳密な」シーケンスで、または１つもしくは複数の介在イベントを伴う「無規律な」シーケンス（４０６）で発生したことをプレゼンスサーバが検出するときにトリガを満たす。例えば厳密な無順序のシーケンスでは、イベントＡおよびＢおよびＣは全て任意の順序で発生するが、他のイベントは発生しない（例えばＢ→Ａ→Ｃや、さらにはＡ→Ｂ→Ａ→Ｃ）。無規律な無順序のシーケンスでは、全てのイベントが、それらのイベントの間に他の可能な非列挙イベントを伴って任意の順序で発生する（例えばＣ→Ｂ→Ｘ→Ａ）。厳密な順序付きのシーケンスでは、Ａの後にＢ、その後にＣと、それらの間に何も介在しない。さらに、無規律な順序のシーケンスでは、Ａの後にＢかつＢの後にＣだが、それらの間に他の何らかのイベントが発生し得る（例えばＡ→Ｘ→Ｂ→Ｙ、Ｚ→Ｃ）。
【００３９】
４０８で、シーケンスの中の１つまたは複数のイベントが発生しないことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。このシナリオは、無順序のイベントシーケンスおよび順序付きのイベントシーケンスの両方に適用することができる。
【００４０】
４１０で、シーケンスの中に含まれていなかった追加のイベントが発生したことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。図５を参照することによる第３のＳＩＰ ＳＵＢＳＣＲＩＢＥの例および付随する説明が、このトリガシナリオを例示する。さらなる例において、厳密な無順序のシーケンスの不履行では、全てのイベントが発生するが、列挙したイベントのいずれかの間に非列挙イベントが発生する（例えばＡ→Ｂ→Ｘ→Ｃや、Ｃ→Ｂ→Ｘ→Ａ）。厳密な順序付きのシーケンスの不履行では、全てのイベントが指定された順序で発生するが、厳密な順序付きのイベントのいずれかの間に非列挙イベントが発生する（例えばＡ→Ｂ→Ｘ→Ｃ）。
【００４１】
４１２で、シーケンスの中の全てのイベントが発生したが、時間パラメータを満たさなかったことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。この例示的実装形態に対応するものとして上記に例を示した。さらに、検出シナリオ４１２は、順序付きのイベントシーケンスおよび無順序のイベントシーケンスの両方に適用することができる。
【００４２】
４１４で、シーケンスの中の全てのイベントが発生したが、（順序付きのイベントシーケンスについての）指定された順序で発生していないことをプレゼンスサーバが検出するとき、モニタされるプレゼンス情報はトリガ、例えばシーケンスの不履行を満たす。例えば順序付きのシーケンスの不履行では、全てのイベントが発生するが、指定された順序から外れている（例えばＢ→Ａ→Ｃ）。これらの例示的シナリオのいずれかについてトリガが満たされていると判定すると、プレゼンスサーバは、サブスクリプション内で提供される指図に応じてまたはトリガを満たしたイベントを明らかにするデータを供給することに関するデフォルトに応じて、トリガを満たしたイベントを明らかにした状態で、または明らかにすることなしにクライアントエンティティに通知を送る（４１６）。
【００４３】
図５は、サブスクリプションを受け取ることに応答してプレゼンスサーバがプレゼンス情報をモニタし、順序付きのシーケンスが不履行に終わる場合にクライアントエンティティに通知を行う絵図を示す。この例示的実装形態ではクライアントエンティティが以下のＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを送り、プレゼンスウォッチャ（ｓｅｃｕｒｉｔｙ＠ｂａｎｋ．ｃｏｍ）はウォッチャユーザ（ａｒｍｏｒｅｄｃａｒ＠ｂａｎｋ．ｃｏｍ）が明日、１組の特定の状態遷移に従わない場合かつその場合に限り通知されることを望む。
【００４４】
【数３】
行（７）はＸＭＬネームスペースであり、行（８）から（１２）はトリガを定義し、そのトリガは、介在イベントなしに装甲車の進路に沿って指定された時間に発生することが予想される順序付きのイベントシーケンスを基本的に定義する。指定されていない介在イベントが発生することおよび／または時間基準を満たさないことが原因でこのシーケンスが不履行に終わることは、クライアントエンティティに通知が送られることを引き起こす。
【００４５】
図５は、サブスクリプションに対応するものとして、モニタされる例示的プレゼンス情報を示す。８：１０に（プレゼンティティａｒｍｏｒｅｄｃａｒ＠ｂａｎｋとして特定する）装甲トラック（５０４）がその現在地（５０２）を出発して進路を開始し、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（８）に定める）８：００〜８：１５の間に出発するというシーケンスの中の第１のイベントを満たす（５０６）。９：１５に装甲トラックは最初の停止のために銀行５０８に到着し、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（９）に定める）９：００〜９：３０の間に銀行に到着するというシーケンスの中の第２のイベントを満たす（５１０）。１２：１５に、装甲トラックは昼食のために停止し（５１２）、それにより（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（１０）に定める）１２：００〜１３：００の間の昼食時間というシーケンスの中の第３のイベントを満たす（５１４）。
【００４６】
しかし３：１５に強奪（５１６）が発生し、この強奪は、（ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの行（１１）に定める）１３：３０〜１４：００の間に装甲トラックがその最終目的地（５１８）に到着するのを妨げ、それによりシーケンスを不履行に終わらせ、ｓｅｃｕｒｉｔｙ＠ｂａｎｋ．ｃｏｍにおけるセキュリティサービスへの通知（５２０）をトリガする。とりわけこの例は、諸実施形態を将来のイベントに適用できることを強調する。さらにこの例は、高度なブール論理（否定論理積）の使用を示す。最後にこの例は、混在する順序付き／無順序の基準の使用を示す。ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ内の最後の要素（行１２）は、明日のある時点でａｒｍｏｒｅｄｃａｒ＠ｂａｎｋが自らの積荷の配送状態を「配送済み」に設定することを単純に要求し、これは銀行１または銀行２に訪れた後に発生することができるが、この場合は強奪により発生しなかった。
【００４７】
上記の明細書で特定の実施形態について説明してきた。ただし、添付の特許請求の範囲に記載する本発明の範囲から逸脱することなしに、様々な修正および変更を加えてもよいことを当業者なら理解されよう。したがって、本明細書および図面は限定的な意味ではなく例示的な意味としてみなすべきであり、そのようなあらゆる修正は本教示の範囲に含まれることを目的とする。
【００４８】
これらの利益、利点、問題に対する解決策、および何らかの利益、利点、もしくは解決策を発生させることができ、またはより顕著にすることができる任意の要素は、いずれかのまたは全ての請求項の重大な、所要の、または不可欠の特徴もしくは要素として解釈すべきでない。本発明は、本願の係属中に加えられる任意の補正を含む添付の特許請求の範囲、および発行されるそれらの請求項のあらゆる等価物によってのみ定められる。
【００４９】
さらにこの文書では、第１のと第２の、上部と下部などの関係語は、あるエンティティまたは行為を別のエンティティまたは行為と単に区別するために、そのようなエンティティまたは行為間のそのようないかなる実際の関係または順序も必ずしも必要とすることなしに、もしくは暗に示すことなしに使用することができる。用語「備える（ｃｏｍｐｒｉｓｅｓ）」、「備えている（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｓ）」、「有している（ｈａｖｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「含有する（ｃｏｎｔａｉｎｓ）」、「含有している（ｃｏｎｔａｉｎｉｎｇ）」、またはそれらの他の任意の改変形態は、非排他的な包含をカバーすることを目的とし、それにより、列挙の要素を備え、有し、含み、含有するプロセス、方法、物品、または機器はそれらの要素だけを含むのではなく、明確に列挙していない他の要素またはそのようなプロセス、方法、物品、もしくは機器に固有でない他の要素を含んでもよい。「〜を備える（ｃｏｍｐｒｉｓｅｓ．．．ａ）」、「〜を有する（ｈａｓ．．．ａ）」、「〜を含む（ｉｎｃｌｕｄｅｓ．．．ａ）」、「〜を含有する（ｃｏｎｔａｉｎｓ．．．ａ）」が前に来る要素は、より多くの制約を受けることなく、その要素を備え、有し、含み、含有するプロセス、方法、物品、または機器において、同一の要素がさらに存在することを排除するものではない。用語「ａ」および「ａｎ」は、本明細書で明示的に別段の定めをした場合を除き１つまたは複数として定義する。用語「ほぼ（ｓｕｂｓｔａｎｔｉａｌｌｙ）」、「事実上（ｅｓｓｅｎｔｉａｌｌｙ）」、「おおよそ（ａｐｐｒｏｘｉｍａｔｅｌｙ）」、「約（ａｂｏｕｔ）」、またはそれらの他の任意のバージョンは、当業者によって理解されるものに近いものとして定義され、非限定的な一実施形態では、この用語は１０％以内、別の実施形態では５％以内、別の実施形態では１％以内、別の実施形態では０．５％以内であると定義される。本明細書で使用するとき、用語「結合される（ｃｏｕｐｌｅｄ）」は、必ずしも直接的にではなく、かつ必ずしも機械的にではないが接続されているものとして定義する。特定の方法で「構成される（ｃｏｎｆｉｇｕｒｅｄ）」装置または構造は、少なくともその方法で構成されるが、列挙されていない方法で構成することもできる。
【００５０】
一部の実施形態が、マイクロプロセッサ、デジタル信号プロセッサ、特注プロセッサ、書替え可能ゲートアレイ（ＦＰＧＡ）などの、１個または複数の汎用プロセッサもしくは専用プロセッサ（または「処理装置」）、ならびに本明細書に記載の方法および／または機器の機能の一部、大部分、もしくは全てを特定の非プロセッサ回路とともに実施するためにその１個または複数のプロセッサを制御する、記憶された固有のプログラム命令（ソフトウェアおよびファームウェアの両方を含む）からなり得ることが理解されよう。あるいは一部の機能または全ての機能を、記憶されたプログラム命令を有さない状態機械により、または１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）内に実装することができ、各機能または機能のいくつかの一部の組合せはカスタムロジックとして実装される。当然ながら、この２つの手法の組合せを使用することもできる。
【００５１】
さらに、実施形態は、本明細書に記載し権利を主張する方法を実行するように（例えばプロセッサを含む）コンピュータをプログラムするためのコンピュータ可読コードが記憶された、コンピュータ可読記憶媒体として実施することができる。そのようなコンピュータ可読記憶媒体の例には、これだけに限定されないが、ハードディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶装置、ＲＯＭ（読取専用メモリ）、ＰＲＯＭ（プログラム可能読取専用メモリ）、ＥＰＲＯＭ（消去可能プログラム可能読取専用メモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラム可能読取専用メモリ）、およびフラッシュメモリが含まれる。さらに、例えば可用時間、最新の技術、および経済的配慮によって動機付けられる、場合によってはかなりの労力および多くの設計上の選択があったとしても、本明細書に開示した概念および原理によって導かれるとき、当業者はそうしたソフトウェア命令およびプログラムならびにＩＣを最小限の実験で容易に作り出せることが予想される。
【００５２】
本開示の要約は、技術的開示の性質を読者がすぐに確認できるようにするために提供する。要約は、特許請求の範囲またはその意味を解釈するために使用されることも限定するために使用されることもないという理解の下で提出する。さらに上記の詳細な説明では、本開示を簡素化するために様々な実施形態において様々な機能をまとめていることが見て取れる。この開示方法は、権利を主張する実施形態が、それぞれの請求項の中で明確に列挙するよりも多くの特徴を必要とするという意図を反映するものだと解釈すべきでない。むしろ、添付の特許請求の範囲が反映するように、本発明の主題は開示した単一の実施形態の全ての特徴よりも少ない特徴にある。このため、添付の特許請求の範囲は詳細な説明に組み込まれ、各請求項は別々に権利を主張する主題として独立している。
【特許請求の範囲】
【請求項１】
イベントシーケンスに基づいてプレゼンスを通知するための方法であって、
プレゼンスサーバにおいて、
前記プレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを前記クライアントエンティティから受け取るステップであって、前記サブスクリプションは、前記イベントシーケンスの中の前記イベントの少なくとも１つの発生に関する時間制限を定める時間パラメータをさらに指標する、受け取るステップと、
プレゼンス情報を受け取り、前記指標された時間パラメータに基づいて前記プレゼンス情報をモニタして、前記イベントシーケンスの発生を検出するステップと、
前記モニタされるプレゼンス情報が前記トリガを満たすとき、前記クライアントエンティティに前記通知を送るステップと
を含む、方法。
【請求項２】
前記イベントシーケンスの中の全ての前記イベントが発生したことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、少なくとも１つの介在イベントの発生と共に発生したことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の前記イベントの少なくとも１つが発生しないことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中に含まれていないさらなるイベントの発生を前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記時間パラメータを満たさないことを前記プレゼンスサーバが検出するとき
前記モニタされるプレゼンス情報が前記トリガを満たす、請求項１に記載の方法。
【請求項３】
前記イベントシーケンスが、指定された順序を有するイベントシーケンスを含み、
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記指定された順序で発生していないことを前記プレゼンスサーバが検出するとき、前記モニタされるプレゼンス情報が前記トリガを満たす
請求項１に記載の方法。
【請求項４】
前記プレゼンス情報をモニタするステップが、記憶されたプレゼンス情報をモニタすることを含む、請求項１に記載の方法。
【請求項５】
前記時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間を含む、請求項１に記載の方法。
【請求項６】
前記開始時間は、前記プレゼンスサーバが前記サブスクリプションを受け取る前に生じる、請求項５に記載の方法。
【請求項７】
前記シーケンスの中の少なくとも１つのイベントがサブシーケンスを含む、請求項１に記載の方法。
【請求項８】
イベントシーケンスに基づいてプレゼンスを通知するための方法であって、
クライアントエンティティにおいて、
プレゼンスサーバが前記クライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを生成するステップであって、前記サブスクリプションは、前記イベントシーケンスの中の前記イベントの少なくとも１つの発生に関する時間制限を定める時間パラメータをさらに指標し、前記イベントシーケンスを検出するために、前記プレゼンスサーバにおいて受け取られるプレゼンス情報が前記時間パラメータに基づいてモニタされる、ステップと、
前記サブスクリプションを前記プレゼンスサーバに送るステップと、
前記モニタされるプレゼンス情報が前記トリガを満たすとき、前記プレゼンスサーバから前記通知を受け取るステップと
を含む、方法。
【請求項９】
前記イベントシーケンスの中の全ての前記イベントが発生したことを検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、少なくとも１つの介在イベントの発生と共に発生したことを検出するとき、または
前記イベントシーケンスの中の前記イベントの少なくとも１つが発生しないことを検出するとき、または
前記イベントシーケンスの中に含まれていないさらなるイベントの発生を検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記時間パラメータを満たさないことを検出するとき
前記トリガが満たされているものとして前記サブスクリプション内で定義される、請求項８に記載の方法。
【請求項１０】
前記イベントシーケンスが、
指定された順序を有するイベントシーケンス、または
指定された順序を有さないイベントシーケンス
を含む、請求項２または９に記載の方法。
【請求項１１】
前記イベントシーケンスが、指定された順序を有するイベントシーケンスを含み、
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記指定された順序で発生していないことを検出するとき、前記トリガが満たされているものとして前記サブスクリプション内で定義される
請求項８に記載の方法。
【請求項１２】
前記通知が、前記トリガを満たした複数のイベントを特定する、請求項１または８に記載の方法。
【請求項１３】
前記時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間を含む、請求項８に記載の方法。
【請求項１４】
前記サブスクリプションが前記開始時間の後に前記プレゼンスサーバに送られる、請求項１３に記載の方法。
【請求項１５】
前記少なくとも１つの時間制限が、
前記イベントシーケンスの中の前記イベントの１つまたは複数の前記発生に関する絶対的時間制限、
前記イベントシーケンスの中の全てのイベントの前記発生に関する総時間制限、
前記イベントシーケンスの中の２つ以上の前記イベント間の発生の相対的時間制限、
前記イベントシーケンスの中の全ての前記イベントの前記発生に関する循環的時間制限
のうちの少なくとも１つを含み、前記イベントシーケンスは無順序のイベントシーケンスを含む、請求項１または８に記載の方法。
【請求項１】
イベントシーケンスに基づいてプレゼンスを通知するための方法であって、
プレゼンスサーバにおいて、
前記プレゼンスサーバがクライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを前記クライアントエンティティから受け取るステップであって、前記サブスクリプションは、前記イベントシーケンスの中の前記イベントの少なくとも１つの発生に関する時間制限を定める時間パラメータをさらに指標する、受け取るステップと、
プレゼンス情報を受け取り、前記指標された時間パラメータに基づいて前記プレゼンス情報をモニタして、前記イベントシーケンスの発生を検出するステップと、
前記モニタされるプレゼンス情報が前記トリガを満たすとき、前記クライアントエンティティに前記通知を送るステップと
を含む、方法。
【請求項２】
前記イベントシーケンスの中の全ての前記イベントが発生したことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、少なくとも１つの介在イベントの発生と共に発生したことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の前記イベントの少なくとも１つが発生しないことを前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中に含まれていないさらなるイベントの発生を前記プレゼンスサーバが検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記時間パラメータを満たさないことを前記プレゼンスサーバが検出するとき
前記モニタされるプレゼンス情報が前記トリガを満たす、請求項１に記載の方法。
【請求項３】
前記イベントシーケンスが、指定された順序を有するイベントシーケンスを含み、
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記指定された順序で発生していないことを前記プレゼンスサーバが検出するとき、前記モニタされるプレゼンス情報が前記トリガを満たす
請求項１に記載の方法。
【請求項４】
前記プレゼンス情報をモニタするステップが、記憶されたプレゼンス情報をモニタすることを含む、請求項１に記載の方法。
【請求項５】
前記時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間を含む、請求項１に記載の方法。
【請求項６】
前記開始時間は、前記プレゼンスサーバが前記サブスクリプションを受け取る前に生じる、請求項５に記載の方法。
【請求項７】
前記シーケンスの中の少なくとも１つのイベントがサブシーケンスを含む、請求項１に記載の方法。
【請求項８】
イベントシーケンスに基づいてプレゼンスを通知するための方法であって、
クライアントエンティティにおいて、
プレゼンスサーバが前記クライアントエンティティに通知を送る時を管理するトリガを定義するイベントシーケンスを含む、プレゼンティティへのサブスクリプションを生成するステップであって、前記サブスクリプションは、前記イベントシーケンスの中の前記イベントの少なくとも１つの発生に関する時間制限を定める時間パラメータをさらに指標し、前記イベントシーケンスを検出するために、前記プレゼンスサーバにおいて受け取られるプレゼンス情報が前記時間パラメータに基づいてモニタされる、ステップと、
前記サブスクリプションを前記プレゼンスサーバに送るステップと、
前記モニタされるプレゼンス情報が前記トリガを満たすとき、前記プレゼンスサーバから前記通知を受け取るステップと
を含む、方法。
【請求項９】
前記イベントシーケンスの中の全ての前記イベントが発生したことを検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、少なくとも１つの介在イベントの発生と共に発生したことを検出するとき、または
前記イベントシーケンスの中の前記イベントの少なくとも１つが発生しないことを検出するとき、または
前記イベントシーケンスの中に含まれていないさらなるイベントの発生を検出するとき、または
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記時間パラメータを満たさないことを検出するとき
前記トリガが満たされているものとして前記サブスクリプション内で定義される、請求項８に記載の方法。
【請求項１０】
前記イベントシーケンスが、
指定された順序を有するイベントシーケンス、または
指定された順序を有さないイベントシーケンス
を含む、請求項２または９に記載の方法。
【請求項１１】
前記イベントシーケンスが、指定された順序を有するイベントシーケンスを含み、
前記イベントシーケンスの中の全ての前記イベントが発生したが、前記指定された順序で発生していないことを検出するとき、前記トリガが満たされているものとして前記サブスクリプション内で定義される
請求項８に記載の方法。
【請求項１２】
前記通知が、前記トリガを満たした複数のイベントを特定する、請求項１または８に記載の方法。
【請求項１３】
前記時間パラメータが、開始時間およびそれに続く終了時間を有する有界時間を含む、請求項８に記載の方法。
【請求項１４】
前記サブスクリプションが前記開始時間の後に前記プレゼンスサーバに送られる、請求項１３に記載の方法。
【請求項１５】
前記少なくとも１つの時間制限が、
前記イベントシーケンスの中の前記イベントの１つまたは複数の前記発生に関する絶対的時間制限、
前記イベントシーケンスの中の全てのイベントの前記発生に関する総時間制限、
前記イベントシーケンスの中の２つ以上の前記イベント間の発生の相対的時間制限、
前記イベントシーケンスの中の全ての前記イベントの前記発生に関する循環的時間制限
のうちの少なくとも１つを含み、前記イベントシーケンスは無順序のイベントシーケンスを含む、請求項１または８に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１３−５１６０１９（Ｐ２０１３−５１６０１９Ａ）
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１２−５４７０９１（Ｐ２０１２−５４７０９１）
【出願日】平成２２年１２月６日（２０１０．１２．６）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５９０６８
【国際公開番号】ＷＯ２０１１／０９０５６４
【国際公開日】平成２３年７月２８日（２０１１．７．２８）
【出願人】（３９０００９５９７）モトローラ ソリューションズ インコーポレイテッド (649)
【氏名又は名称原語表記】Ｍｏｔｏｒｏｌａ Ｓｏｌｕｔｉｏｎｓ， Ｉｎｃ．
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２２年１２月６日（２０１０．１２．６）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５９０６８
【国際公開番号】ＷＯ２０１１／０９０５６４
【国際公開日】平成２３年７月２８日（２０１１．７．２８）
【出願人】（３９０００９５９７）モトローラ ソリューションズ インコーポレイテッド (649)
【氏名又は名称原語表記】Ｍｏｔｏｒｏｌａ Ｓｏｌｕｔｉｏｎｓ， Ｉｎｃ．
[ Back to top ]