JP2015111828A - ネットワーク内でプレゼンス・イベントの数を減らすための方法およびシステム - Google Patents

Abstract

【課題】ネットワーク内のプレゼンス情報の流れをよりよく管理する、ネットワーク内でプレゼンス・イベントの数を減らすための方法及び装置を提供する。【解決手段】頻繁に通信する連絡先（親しい友人１０８又は最近使用した連絡先）をあまり頻繁に通信しない連絡先（アドレス帳内のあまり親しくない友人１１０又は最近使用していない連絡先）から分離する。【選択図】図１

Description

本発明は、ネットワーク内でプレゼンス・イベントの数を減らすための方法および装置に関する。これは、ネットワーク内のプレゼンス情報の流れをよりよく管理する目的で、頻繁に通信する連絡先（親しい友人／最近使用した連絡先）をあまり頻繁に通信しない連絡先（あまり親しくない友人／最近使用していない連絡先）から分離することによって達成される。

本発明は特に、ネットワークでプレゼンス情報を管理する技術を対象とし、したがって特にそれらを参照して説明されるが、本発明は他の分野および応用例において有用であってもよいということを理解されたい。

背景として、プレゼンティティとして知られる他のユーザに関連したプレゼンス情報について、ウォッチャーとして知られるユーザの通知を促進するための規格に準拠したメカニズムが存在する。知られているように、プレゼンス情報は様々な形態をとってもよいが、一般にはユーザ状態の指標である。この種の情報によって他者は、ユーザが応対できるか、応対できないか等を判定することができる。典型的には、上記の規格に準拠したメカニズムは、ウォッチャーがモバイル・ネットワーク内にある場合、過剰な量の無線ネットワーク資源を使用し、モバイル・デバイスのバッテリ寿命を減少させる。当然のことながら、ネットワーク資源の過剰な使用はモバイル・プロバイダにとって望ましいことではなく、バッテリ寿命が減少することはモバイル加入者によって望まれることではない。

さらに非モバイルの使用の際、プレゼンス状態の変化の通知を生成し、輸送することは、各ユーザが多数のプレゼンティティを観察している場合、（サーバ容量等の）資源の過度な要求につながり、これはプレゼンス・ネットワークのオペレータにとって望ましいことではない。

１つの状況では、プレゼンス情報は他のユーザ（１つの形態では、加入者のアドレス帳の中にあるユーザ）の状態が変化すると、自動的にモバイル加入者に対してプッシュされる。追跡されるプレゼンティティが１０個だけでも、ユーザに対する情報の各プッシュのためにネットワーク資源が必要とされるので、この手法はネットワークに多大な負荷をかける。

またネットワークにおけるプレゼンス情報の問題に対処するために、複数のその他の既存のメカニズムが利用可能である。例えば、（プッシュの代わりに）プレゼンス情報のプルが使用されることが可能である。しかしながら、この手法はユーザ体験を低下させる。プレゼンス情報に対する要求（例えばプル等）と配信との間の（多くの無線ネットワークに存在する）時間差は、多くのユーザにとって受け入れられない場合がある。

状態の数は減少し得るが、この手法はプレゼンス・サービスにとっての有用性の損失につながる。

プレゼンス通知は抑制されることが可能である。この手法の欠点には、短期間のイベントでの配信の遅れ、および情報の損失が含まれる。

またトリガ・フィルタも実装される場合がある。しかしながらこの手法では、フィルタの設定にユーザが大きく関与する必要がある。

他に手法がない場合、ネットワーク・プロバイダは単純に、プレゼンス機能を受信する加入者の数を減らし得る。これはサービスの加入者が減ることにつながり、場合によっては収益を減少させる。

ネットワーク内でプレゼンス・イベントの数を減らすための方法および装置が提供される。

本明細書に記載の実施形態の１つの態様では、本方法は、第２ユーザ（例えばプレゼンティティ）についてのプレゼンス状態の変化を（例えば第１ユーザなどのウォッチャーによって）検出することと、第２ユーザ（例えばプレゼンティティ）が第１リストにあるのか、または第２リストにあるのかを判定することと、第２ユーザ（例えばプレゼンティティ）が第１リストにある場合、プレゼンス状態の変化を即座に第１ユーザ（例えばウォッチャー）に通知することと、第２ユーザが第２リストにある場合、所定のイベントを検出した上でプレゼンス状態の変化を第１モバイル・ユーザに通知することとを含む。本明細書に記載の実施形態の他の態様では、第１リストは親しい友人のリスト／最近使用した連絡先である。

本明細書に記載の実施形態の他の態様では、第２リストは、あまり親しくない友人のリスト／最近使用していない連絡先の識別子を含む。

本明細書に記載の実施形態の他の態様では、所定のイベントは、アドレス帳または連絡先リストを開くことである。

本明細書に記載の実施形態の他の態様では、本方法は、第１および第２リストを変更することをさらに含む。

本明細書に記載の実施形態の他の態様では、第１ユーザはウォッチャーである。

本明細書に記載の実施形態の他の態様では、第２ユーザはプレゼンティティである。

本明細書に記載の実施形態の他の態様では、システムは第１ユーザ（例えばウォッチャー等）に対応する第１クライアントと、第１リストおよび第２リストを格納するＸＤＭＳサーバと、第２ユーザ（例えばプレゼンティティ）についてのプレゼンス状態の変化を検出し、第２ユーザ（例えばプレゼンティティ）が第１リストにあるのか、または第２リストにあるのかを判定し、第２ユーザ（例えばプレゼンティティ）が第１リストにある場合、プレゼンス状態の変化を第１モバイル・クライアント（例えばウォッチャー）に即座に通知し、第２ユーザ（例えばプレゼンティティ）が第２リストにある場合、所定のイベントを検出した上でプレゼンス状態の変化を第１クライアントに通知するように動作するプレゼンス・サーバとを備える。

本明細書に記載の実施形態の他の態様では、第１リストは親しい友人のリストである。

本明細書に記載の実施形態の他の態様では、第２リストは、あまり親しくない友人のリスト／最近使用していない連絡先のユーザの識別子を含む。

本明細書に記載の実施形態の他の態様では、所定のイベントはアドレス帳または連絡先リストを開くことである。

本明細書に記載の実施形態の他の態様では、プレゼンス・サーバおよび第１クライアント（例えばウォッチャー）のうちの少なくとも１つは、第１および第２リストを変更するようにさらに動作する。

本明細書に記載の実施形態の他の態様では、第１ユーザはウォッチャーである。

本明細書に記載の実施形態の他の態様では、第２ユーザはプレゼンティティである。

本発明のさらなる適用範囲は、以下に示される詳細な説明から明らかとなろう。しかしながら、この詳細な説明および特定の例は、本発明の好ましい実施形態を示しているが、本発明の精神および範囲内に入る様々な変更形態および修正形態が当業者には明らかであることから、単に例として示されていることを理解されたい。

本発明は、様々なデバイスの部分および方法のステップの構成、配置および組合せの中に存在し、それによって考えられる目的は、以下でより完全に言及され、特許請求の範囲の中で特に指摘され、添付の図面の中で示されるように達成される。

本明細書に記載の実施形態が実装されてもよいネットワークのブロック図である。 本明細書に記載の実施形態による方法の流れ図である。 本明細書に記載の実施形態が実装されてもよいネットワークのブロック図である。

本明細書に記載の実施形態の基本的概念は、無線ネットワーク資源の使用が最小化された良好なユーザ体験を達成するために、プッシュ・モデルおよびプル・モデルの有利な混合を提供することである。

これについて、１つの形態では、通話記録／最も頻繁な呼び出しまたは通信リストを通じてモバイル・クライアントで明らかになる通信パターンによって判定される、友人の小集団または最も頻繁に呼び出す相手のためにプレゼンス・プッシュ方法が使用される。本明細書に記載の実施形態の少なくとも１つの形態によって、このユーザの集団は常に自身の最新のプレゼンス状態を有する。

アドレス帳の残りの項目のために、プレゼンス・プル方法が使用される。本明細書に記載の実施形態の少なくとも１つの形態によって、このユーザの集団は、（例えばアドレス帳を開くこと等の所定のイベントを検出した上で）使用される可能性が高い場合に更新されるプレゼンスのみを有する。

通信パターンが変化すると、その友人の小集団の構成は変化されるので、ユーザが通信するエンティティの小集団は恒常的に最新に保たれる。エンティティのより大きな集団は、通信がめったに起こらない場合、アドレス帳が開かれるか、またはその集団が使用される可能性が高い他のイベント等の場合にだけ更新される。

この組合せは、加入者のアドレス帳の少数のエンティティだけに最新のプレゼンスを配信するためにネットワーク資源を減らす（例えば、ページング、トラフィック・チャネルの開通等を必要とする通知メッセージが使用されるのは、はるかに少ない）。

提案される解決法の少なくとも１つの形態では、ＩＥＴＦ、３ＧＰＰおよびＯＭＡによって標準化されたような標準的なＳＩＰ／ＳＩＭＰＬＥ（インスタント・メッセージングおよびプレゼンス・レバレッジング拡張子（Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ）のためのセッション開始プロトコル／ＳＩＰ）のプレゼンス・シグナリングが使用される。

少なくとも１つの形態では、モバイル・クライアント等のクライアントは、その親しい友人のリストを判定するために、その通信記録を分析する。モバイル・クライアント等のクライアントは、例えばＸＤＭＳ内にこのリストを設定し、例えばプレゼンス・サーバ／資源リスト・サーバ（ＲＬＳ）に対して、そのリストへの予約を行う。この形態では、プレゼンス・サーバ／ＲＬＳは、そのリスト中の誰かについて状態の変化がある場合、モバイル・クライアントに通知する。

さらに少なくとも１つの形態では、アドレス帳が開かれる場合に、クライアント（例えばモバイル・クライアント）は（ｅｘｐｉｒｅｓ＝０であるプル要求を使用して）親しくない友人のリストのために状態の更新を求める要求を行う。

少なくとも１つの形態では、（例えば）加入者の通信パターンの変化のために親しい友人のリストに変化が生じる場合、２つのリスト（例えば親しい友人のリストと親しくない友人のリスト）はその変化を反映するために変化される。

単に例示的な実施形態を示すことを目的として図示され、特許請求される主題を限定することを目的とはしない図面をここで参照すると、図１は、本明細書に記載の実施形態が組み込まれてもよいシステム図を示す。一般的に示すように、図１はネットワークの部分１００を示す。ネットワークのこの部分は、ネットワーク資源の使用が最小化されたプレゼンス検出技術を使用する際のユーザ体験を向上させるために、プッシュ・モデルとプル・モデルの混合が提供される本明細書に記載の実施形態に関連して、本明細書で説明されている技術を実装する。説明を簡単にするために、ネットワークの部分のみが図示されていることを理解されたい。当業者であれば、どのようにこの部分が他のネットワーク要素と一体化するかは理解されよう。

これについて、ネットワーク１００は例えば、プレゼンス・サーバ／資源リスト・サーバ１０４と通信している（モバイル・クライアント等の）クライアント１０２を含む。クライアント１０２は、例えばモバイル・クライアントとして図示されているが、携帯電話、パーソナル・コンピュータ等の様々な形態をとってもよい。さらに、クライアント１０２はモバイルであっても非モバイルであってもよく、例えばワークステーションまたはその他のコンピューティング・デバイスであってよい。さらに、クライアント１０２はウォッチャーである。

同様に、サーバ１０４はＸＭＬ文書管理サーバ（ＸＤＭＳ）１０６と通信している。ＸＤＭＳサーバ１０６は、少なくとも第１および第２リストを含む様々な情報の部分を格納している。とりわけ、親しい友人のリスト１０８および親しくない友人のリスト１１０が格納されている。少なくとも１つの形態では、親しい友人のリストにあるユーザは、親しくない友人のリストには存在しないことになる。これらのリストは、例えばクライアント１０２のユーザのためのアドレス帳を含んでもよく、また他のユーザに関連する識別子またはその他データを含んでもよい。適切な状況では、リスト上のこれらの他のユーザはプレゼンティティと呼ばれてもよい。また、他のユーザは（例えば携帯電話、コンピュータ等）様々な形態をとる、および／または様々なデバイスを使用することができ、モバイルまたは非モバイルであってよい。

動作中、プレゼンス・データは友人の小集団について状態の変化があるとクライアントにプッシュされる。この親しい友人の小集団は、親しい友人のリスト１０８によって図示されているように、クライアント１０２で通信された通話記録または最近使用された番号から判定される。この親しい友人の集団は、プッシュ・メカニズムを使用することによって、モバイル・クライアント１０２のために恒常的に最新の自身のプレゼンス状態を有する。通常は、恒常的に最新である友人の小集団だけを持つことが大部分のモバイル・ユーザに望まれるということが理解されよう。これについて、例えば携帯電話ユーザは通常、非常に小数の人々とだけ通信する。したがって大部分の人にとっては、恒常的に更新された親しい友人の小グループを有することだけで十分であろう。

少なくとも１つの実装形態では、親しい友人のリストは、ＸＤＭＳＡデータベースに対してＸＣＡＰ等の標準的なメカニズムを使用することによって、クライアント１０２（例えばモバイル・クライアント１０２）のために自動的に更新されることになる。このようにして、例であるモバイル・クライアント１０２、またはプレゼンス・サーバ１０４に対する加入者は、親しい友人のリストの任意の項目が変化した場合に通知を受ける。この機能は様々な様式で実装されてもよいということを理解されたい。例えば代替の実装形態は、クライアント（例えばモバイル・クライアント）が、親しい友人のうちのひとりひとりに対して個別に要求を出すか、または申し入れをすることである。

例として、図１をさらに参照すると、友人の小集団のために情報をプッシュするための過程は様々な形態をとってもよい。１つの形態の例では、クライアント１０２はその親しい友人のリストのために、プレゼンス情報を求める申し入れをする（参照線１）。次いで、プレゼンス・サーバ１０４は、ＸＤＭＳサーバ１０６から親しい友人のリストのメンバーを要求する（参照線２）。次いでＸＤＭＳサーバは、友人Ａ、Ｂ、ＣおよびＤのアイデンティティでプレゼンス・サーバ１０４に応答する（参照線３）。プレゼンス・サーバ１０４は友人Ａ、Ｂ、ＣおよびＤの状態をクライアント１０２に返送する（参照線４）。この時点で、親しい友人（またはプレゼンティティ）のうちのいずれかの状態が変化する場合、この変化はプレゼンス・サーバによって検出され、プレゼンス・サーバは自動的にクライアントに通知することになる。例えば、親しい友人Ａ（例えばプレゼンティティ）の状態が変化する場合、プレゼンス・サーバは通知を受ける（参照線５）。同様に、次いでプレゼンス・サーバは状態変化の通知をクライアント１０２に送信する（参照線６）。

上述のように、本明細書に記載の実施形態は、ネットワーク資源の使用を制限しながら、向上したユーザ体験を提供するために、プッシュ・モデルおよびプル・モデルの両方の混合を提供する。したがって、図１の中で親しくない友人１１０として識別されるアドレス帳項目のより大きな集合にはプル技術が使用される。これについて、プル・メカニズムは必要な場合にだけ、親しい友人のリストに含まれていないアドレス帳内の項目を更新するために使用される。１つの形態では、親しくない友人のリストは、ＸＤＭＳデータベースに対してＸＣＡＰ（ＸＭＬ構成アクセスプロトコル）等の標準的メカニズムを使用して更新される。親しくない友人のリストの各項目についてのプレゼンス情報は、そのリストのためにプレゼンス・プル・メカニズムを使用して更新される。当然のことながら、代替形態が存在してもよい。例えば１つの代替の実装形態では、アドレス帳の中で先に示される項目が最初にプルされ、続いて後の方の項目がプルされるように、多数のリストがリストの中の項目を用いて定義される。この実装形態の便益もまた、よりよいユーザ体験のためになるということである。他の代替形態では、アドレス帳の中の各項目についてのプレゼンス・プル要求が行われてもよい。

プッシュ技術と同じように、プル技術は様々な様式で実装されてよい。しかしながら１つの実装形態では、図１を参照すると、友人Ｅ（例えばプレゼンティティ）（モバイルであってよい）の状態が変化し、プレゼンス・サーバ１０４は状態の変化とともに更新される。この場合、例えばモバイル・クライアントに対する情報のプルが必要なので、モバイル・クライアントに通知が送信されることはない。次いで、例えば加入者がアドレス帳を開く場合、親しくない友人のリストを指定するプレゼンス・サーバにプル要求が送信される（参照線８）。次いで、プレゼンス・サーバは、ＸＤＭＳサーバ１０６から親しくない友人のリストのメンバーを要求する（参照線９）。ＸＤＭＳサーバ１０６は、友人Ｅのためのモバイルの状態を含む、全ての親しくない友人の現在のアイデンティティで応答する（参照線１０）。次いで、プレゼンス・サーバはこれらの親しくない友人の状態をクライアント１０２へ返送する（参照線１１）。したがって、状態の変化が第２リストのユーザ（プレゼンティティ）についてのものであれば、ウォッチャー（例えば第１ユーザまたはクライアント１０２）はプレゼンス状態の変化について通知を受けず、代わりにウォッチャーは、所定のイベントが生じる場合に、このプレゼンティティのステータスの変化について更新されるだけである。

本明細書に記載の実施形態の１つの特徴は、クライアント機能内の親しい友人のリストの恒常的な更新である。これについて、親しい友人のリストが恒常的に更新される場合、システムによってユーザ体験の向上が提供される。

ここで図２を参照すると、方法２００が図示されている。この方法では、加入者は他のエンティティと通信する（２０２において）。この例では、これが通信記録を変化させる（２０４において）。通信記録の変化に基づいて、親しい友人のリストは計算または再計算される（２０６において）。次いで、親しい友人のリストの新しい状態は、１つのリストから他のリストで変化があったかどうかを判定するために古い状態と比較される（２０８において）。変化があった場合、ＸＤＭＳサーバ１０６にある親しい友人のリストおよび親しくない友人のリストは更新される（２１０において）。次いで、システムは次の通信イベントを待つ（２１２において）。当然のことながら、ステップ２０８で友人リストに変化がない場合、システムは単に次の通信イベントを待つ（２１２において）。

ステップ２１０での親しい友人および親しくない友人のリストの更新は、様々な様式で達成されることが可能である。ここで図３を参照すると、１つの例示的な形態で、システム１００が図示されている。この例では、加入者またはモバイル・クライアント１０２はテキスト・メッセージを友人Ｅに送信する。この例では、ＥはＤに代わって、上位４人の友人のうちの１人になる（参照線１）。クライアントはＥを伴うＸＣＡＰ Ｐｕｔを親しい友人ＸＤＭＳリストに送信する（参照線２）。次いで、モバイル・クライアント１０２はＤを伴うＸＣＡＰ Ｐｕｔを親しくない友人のリストに送信する（参照線３）。次いで、モバイル・クライアントはＤを伴うＸＣＡＰ Ｄｅｌｅｔｅを親しい友人のリスト１０８に送信する（参照線４）。最後に、モバイル・クライアントはＥを伴うＸＣＡＰ Ｄｅｌｅｔｅを親しくない友人のリスト１１０に送信する（参照線５）。一旦全てのこれら行為が行われると、親しい友人のリスト１０８および親しくない友人のリスト１１０の最初の状態は各々、親しい友人のリスト１０８’および親しくない友人のリスト１１０’によって図示されているように、変形状態に変化される。

本明細書に記載の方法および技術は、様々なソフトウェア・ルーチン、ハードウェア構成および／または両方の組合せを使用して実装されてもよいことが理解されよう。例えば、図１、２および３とともに説明した技術は、クライアントまたはモバイル・クライアント、プレゼンス・サーバ、ＸＤＭＳサーバ、またはそれらの様々な組合せで動作するソフトウェア・ルーチンを使用して実装されてもよい。さらに、これらの要素は様々な形態をとってもよく、例えばそれらは他の要素に組み込まれてもよく、または独立したエンティティであってもよいことが理解されよう。

上の説明は、単に本発明の特定の実施形態の開示を示しており、本発明をこれらの実施形態に限定することを目的とはしていない。したがって、本発明は上で説明した実施形態だけに限定されることはない。むしろ、当業者であれば本発明の範囲内に入る代替実施形態を考えることができるということを認識されたい。

Claims (2)

1. 第１ユーザに他のユーザについてのプレゼンス状態の変化を通知するシステムであって、
   第２ユーザについてのプレゼンス状態の変化を検出し、前記第２ユーザが第１リストにあるのか、または第２リストにあるのかを判定し、前記第２ユーザが前記第１リストにある場合、プッシュ・メカニズムを使用することによって前記プレゼンス状態の変化を前記第１ユーザに即座に通知し、前記第２ユーザが前記第２リストにある場合、所定のイベントを検出した上でプル・メカニズムに応答して前記プレゼンス状態の変化を前記第１ユーザに通知するように動作するプレゼンス・サーバとを備え、
   前記第１リストが、親しい友人のリストであり、前記親しい友人のリストにはないモバイル・ユーザの識別子を含むシステム。
2. 前記第１ユーザは第１クライアントに対応し、
   前記第１リストおよび前記第２リストを格納する記憶手段をさらに含む請求項１に記載のシステム。

Images