JP2014518464A - パッシブ通信サービスのためのシステムおよび方法 - Google Patents

Abstract

通話サービスなどのサービスの第１のユーザに関する受動的プレゼンス情報が、ユーザの操作ログを分析することにより取得される。これは、第２のユーザからの要求時に行われる。従って、従来のインターネット・プロトコル・マルチメディア・サービス（ＩＭＳ）環境に求められた大きなオーバヘッドを必要とせずに、プレゼンス情報を少ないオーバヘッドで取得しうる。このようなオーバヘッドの少ないプレゼンス機能は、ユーザが通話オブジェクトを更新するのを可能にする通話サービスを含む、他のサービスを可能にできる。ユーザは、特定の通話オブジェクトの更新情報をリッスンすることができる。従って、模擬のリアルタイムプッシュ経験を提供する。

Description

本発明は、一般に、通信ネットワーク上のユーザ間のパッシブ（受動的）なプレゼンス兼通話サービスを提供するシステムおよび方法に関する。

公衆インターネットと通信ネットワークの両方において、プレゼンスおよび通話は、２つの重要な通信サービスである。既存のプレゼンスサービスおよび通話サービスの大部分は、ＩＰマルチメディアサブシステム（ＩＭＳ）、セッション開始プロトコル（ＳＩＰ）、または他のセッションベースのプロトコルを使用して、ネットワーク内に大きなトラヒックフローを作り出している。このオーバヘッドとなるネットワークトラヒックを処理するためには、余分のシステム能力が必要であり、このため、事業者ネットワークにおいてＩＭＳベースのプレゼンスサービスまたは通話サービスを展開する総費用が増加している。

ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）は、クライアントがサーバにリクエスト（要求）を開始し、サーバが要求を処理して、適切なレスポンス（応答）を返すことを含むソフトウェアアーキテクチャのスタイルである。要求および応答は、リソースのリプレゼンテーション（表現）の転送を中心に構築される。リソースの表現は、通常、リソースの現在の状態をキャプチャーしたメッセージまたはドキュメントである。任意の特定の時間において、クライアントは、現在進行中の要求に対するリプライ（返答）を待っていてもよいし、またはレスト（休止）していてもよい。休止状態のクライアントは、そのユーザと情報をやり取りできるが、負荷を発生せず、サーバまたはネットワーク上のクライアントごとの記憶容量を消費しない。要求と要求との間には、セッション状態もクライアントコンテキストも格納されない。ＲＥＳＴの制約に適合するアーキテクチャは、ＲＥＳＴｆｕｌであると呼ばれる。

現時点では、通信ネットワーク分野のオープンスタンダード機関によって支持されている、ステートレスの軽いプレゼンス兼通話サービスを提供するメカニズムはない。

従って、受動的なやり方を使用することによって、プレゼンス兼通話サービスによって生成されるネットワークのトラヒックフローと、利用されるネットワークリソースとを削減する解決手段が有ると有利であろうことが容易に理解されるはずである。

本発明の１つの目的は、従来技術の少なくとも１つの欠点を除去または軽減することである。

本明細書に開示するのは、最小限のネットワークトラヒックおよびリソースを必要とするＲＥＳＴｆｕｌアプローチを用いて構築される、プレゼンス兼通話サービスである。

本発明の第１の態様においては、通信ネットワークにおいてユーザ間の通話サービスをイニシャライズ（初期設定）する方法を提供する。この方法は、第１のユーザデバイスから第２のユーザデバイスとの通話を開始したいという要求を受信する工程と、受信した要求に関連する通話オブジェクトを識別する工程と、通話オブジェクトに関連する識別情報を含むインビテーション（招待）メッセージを第２のユーザデバイスに送信する工程と、第１のユーザデバイスから通話オブジェクトの更新通知のリッスン要求を受信する工程とを有する。通話オブジェクトを識別する工程は、第１のユーザと第２のユーザの両方に関連する通話オブジェクトが存在するかどうかを判定する工程を有していてもよい。通話オブジェクトが存在しないことを受けて、第１のユーザと第２のユーザの両方に関連する通話オブジェクトを作成してもよい。通話オブジェクトに関連する識別情報を、第１のユーザデバイスに送信してもよい。招待メッセージは、ＳＭＳ−０メッセージであってもよい。本方法は、第１のユーザデバイスまたは第２のユーザデバイスの少なくとも一方に、通話オブジェクトに関連する通話履歴を送信する工程をさらに有していてもよい。方法は、第２のユーザデバイスからの通話アップデート（通話更新情報）の受信を受けて、第１のユーザデバイスに受信したリッスン要求に対する返答を送信する工程をさらに有していてもよい。

本発明の第２の態様においては、通信ネットワークのユーザ間の通話を更新する方法を提供する。本方法は、第１のユーザから通話オブジェクトの更新通知のリッスン要求を受信する工程と、第２のユーザから通話オブジェクトに関連するメッセージを受信する工程と、受信したメッセージに応じて通話オブジェクトを更新する工程と、通話オブジェクトの更新を受けて、第１のユーザに受信したリッスン要求に対する返答を送信する工程とを有する。受信したリッスン要求に対する返答には、第２のユーザから受信したメッセージを含めてもよい。方法は、第２のユーザデバイスから通話オブジェクトの更新通知のリッスン要求を受信する工程をさらに有していてもよい。第２のユーザデバイスから受信したリッスン要求に対して、受信したメッセージに従って通話オブジェクトを更新したことを知らせる返答を送信してもよい。通話オブジェクトを更新する工程は、通話オブジェクトに関連する通話履歴の中に、受信したメッセージを格納する工程を有していてもよい。方法は、返答の送信に応えて、第１のユーザデバイスから通話オブジェクトの更新通知に対する新しいリッスン要求を受信する工程をさらに有していてもよい。受信するリッスン要求は、ロングポーリング要求メッセージであってもよい。

本発明の別の態様においては、通話システムを提供する。この通話システムは、第１のユーザと第２のユーザの両方に関連する通話オブジェクトを格納するメモリと、第１のユーザから第２のユーザとの通話を開始したいという要求を受信するとともに、第１のユーザから通話オブジェクトの更新通知のリッスン要求を受信する通信インタフェースと、受信した要求に関連する通話オブジェクトを識別し、識別した通話オブジェクトを示す招待メッセージを第２のユーザに送信するように通信インタフェースに指示し、かつ第２のユーザからの通話更新情報の受信を受けて、受信したリッスン要求に対する返答を送信するプロセッサとを備えている。このプロセッサは、通話オブジェクトが第１のユーザと第２のユーザの両方に関連するメモリに格納されているかどうかを判定してもよい。プロセッサは、通話オブジェクトが存在しないことを受けて、第１のユーザと第２のユーザの両方に関連するメモリの中に通話オブジェクトを作成してもよい。通信インタフェースは、第２のユーザからメッセージを受信してもよい。メッセージの受信を受けて、プロセッサは、通話オブジェクトを更新してもよい。受信したリッスン要求に対する返答には、通話更新情報を含んでもよい。受信するリッスン要求は、ロングポーリング要求メッセージであってもよい。

本発明の他の態様および特徴については、添付の図とともに、本発明の特定の実施形態についての以下の説明を精査することにより、当業者には明らかになるであろう。

以下、本発明の実施形態について、説明のためだけに、添付の図を参照して述べる。

ＲＥＳＴベースのプレゼンス兼通話サービスを示すアーキテクチャの図である。 プレゼンスサービスの一例を示す呼フローの図である。 移動デバイスに表示されたプレゼンス状態の一例の図である。 通話サービスの一例を示す呼フローの図である。 通話サービスを初期設定する方法を示すフロー図である。 通話サービスを更新する方法を示すフロー図である。 本発明のノードの一例を示すブロック図である。

ここで図１を参照する。提案のサービスは、ユニバーサルウェブサービス機能（ＵＷＦ）１０２、プレゼンス機能（ＰＦ）１０４、および通話機能（ＣＦ）１０６の３つの主要な機能を有する。ＵＷＦ１０２、ＰＦ１０４、およびＣＦ１０６は、通信ネットワーク１００のＲＥＳＴベースのプレゼンス兼通話サービス（ＲＰＣＳ）１０８などの単一ノードに存在していてもよいし、またネットワーク内の複数のノードに分散されていてもよい。各機能は、ハードウェアによって実行される１つ以上のソフトウェアモジュールまたはアプリケーションコードから成る構成であってもよい。

ＵＷＦ１０２は、サービス登録、プロファイル管理等の下位通信機能と結びつくＡＰＩコンテナである。ＵＷＦ１０２は、ウェブポータル１１０およびクライアントアプリケーション１１２にＲＥＳＴ ＡＰＩを提供する。また、ＵＷＦ１０２は、認証許可アプリケーションサーバ（ＡＵＴＨ ＡＳ）１１４にアクセスしてサービスを要求するクライアントに、認証および許可を与えてもよい。

ＰＦ１０４は、クライアントアプリケーション１１２が行った動作を、加入者ごとに、ファイルシステム（ＦＳ）１１６に記録および更新するプロキシの役割を果たす。また、クライアントが過去の動作の履歴を取り出せるようにもしてもよい。ＰＦ１０４は、ユーザの操作履歴と、事業者またはクライアントが設定したルールまたはポリシのセットとに基づいて、ユーザのプレゼンス状態を判定するロジックを有する。

ＣＦ１０６は、参加しているユーザに対して通話に関連する情報を提供する。ＣＦ１０６は、通話に係わる参加者／ユーザ／ユーザデバイスの全ての間で情報を交換する。また、通話中に交わされたメッセージにインデックスを付け、ファイルシステム１１６に格納してもよい。ＣＦ１０６は、ユーザが通話履歴を取り出して見ることができるようにする手段を提供する。

ＲＥＳＴベースのプレゼンス兼通話サービスは、３ＰＰ認証アプリケーションサーバを通して、認証および許可を行えるメカニズムを提供する。ショートメッセージサービスセンタ（ＳＭＳ−Ｃ）１１８は、通話にインバイト（招待）するＳＭＳ通知を送信するために使用されてもよい。ＦＳ１１６は、ネットワークに加入している各ユーザの通話およびプレゼンスに関する情報を格納するために使用される、ネットワーク用の中央データ記憶装置であってもよい。

明瞭にするため、および読みやすくするために、本開示においてはユーザと参加者を交換可能に使用していることが、当業者には分かるであろう。メッセージは、ユーザに関係するユーザデバイスによって、送信および受信されることが分かるであろう。

図２に、本発明のプレゼンスサービスの呼フローの例示的実施形態を示す。この例がＲＰＣＳ１０８のＵＷＦ１０２およびＰＦ１０４に係わるものの、ＵＷＦ１０２とＰＦ１０４との通信およびやり取りに関する具体的な詳細については、簡潔にするために省略されていることが、当業者には分かるであろう。ユーザＡ２０２は、ネットワーク上の自分の移動デバイス上で、ＵＷＦ１０２を通して操作２２０（例えば、ログイン、メッセージのポスト、リッスン等）を行う。ユーザＡからの要求２２０の受信後、ＵＷＦ１０２は、操作の種類を識別し、この操作情報を加入者ユーザＡに関して記録するようにＰＦ１０４に指示する。ＰＦ１０４は、指示２２２を送信して、／ＭＳＩＳＤＮ＿Ａ／Ｐｒｅｓｅｎｃｅ／Ａｃｔｉｖｉｔｙ＿Ｌｏｇなどのパスに従って、ＦＳ１１６に格納されているユーザＡに関するログファイル２０８の操作情報を更新する。ログファイルには、関連する日付、時間、および他の任意の適切なデータフィールドを有する操作種類のリストを含んでいてもよい。ネットワーク上の各加入者は、自分に関連する操作ログファイルを有していてもよい。事業者は、そのログファイルにどの種類の操作を記録および格納するかを設定してもよい。ステップ２２３において、ＦＳ１１６は、ユーザＡの操作ログ２０８に更新情報を格納する。ＦＳ１１６は、ＲＰＣＳ１０８に肯定応答メッセージＡＣＫ２２４で答え、次いでＲＰＣＳ１０８は、ユーザＡにＡＣＫ２２６を送信する。ＡＣＫ２２６は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）２００ＯＫメッセージ、またはＳＩＰメッセージ、または適切なプロトコルの他の任意の肯定応答メッセージであってもよい。例示のためだけに、ＨＴＴＰメッセージを使用する。当業者は、肯定応答メッセージ２２４および２２６が、具体的な実装およびプロトコルの詳細に応じて、任意でありうることが分かるであろう。

同様に、ユーザＢ２０４も、自分の移動デバイス上で、ＵＷＦ１０２を通して操作２２８（例えば、ログイン、メッセージのポスト、リッスン等）を行う。ユーザＢからの要求の受信後、ＵＷＦ１０２は、操作の種類を識別し、この操作情報を加入者ユーザＢに関して記録するようにＰＦ１０４に指示する。ＰＦ１０４は、指示２３０を送信して、例示のパス／ＭＳＩＳＤＮ＿Ｂ／Ｐｒｅｓｅｎｃｅ／Ａｃｔｉｖｉｔｙ＿Ｌｏｇに従って、ＦＳ１１６に格納されているユーザＢに関するログファイル２１０の操作情報を更新する。ステップ２３１において、更新情報が格納され、任意的な肯定応答メッセージ２３２および２３４が、上記のメッセージ２２４および２２６と同様に返されてもよい。

ユーザＢは、ネットワーク内のユーザＡのプレゼンス情報を尋ねたいかまたは見守りたいと思ってもよい。ユーザＡは、ユーザＢの電話帳の中の連絡先であってもよい。ユーザＢの移動デバイスのクライアントアプリケーションは、ユーザＡのプレゼンス状態を取り出すために、ＵＷＦ１０２に要求２３６を送信してもよい。ＵＷＦ１０２は、ユーザＡの操作ログファイルを取り出すために、ＰＦ１０４にその要求を転送する。ＰＦ１０４は、ＦＳ１１６にユーザＡの操作情報２３８を要求し、その情報は、メッセージ２４０で返される。ユーザＡの操作ログファイルの取り出し後、ＰＦ１０４は、事業者および／またはエンドユーザが定めた基準に基づいて、ユーザＡのプレゼンス状態を導き出す。ＰＦ１０４は、操作種類、操作時間、または他の任意の基準を使用して、操作ログファイルに格納された情報からプレゼンス状態を判定してもよい。ネットワークにおけるユーザのプレゼンス状態は、オンライン、オフライン、通話中、対応可能などの中の１つ、または事業者もしくは加入者が定めた任意の他の状態であってもよい。プレゼンス状態は、記録された最新の操作情報だけの解釈、または記録された任意数の操作情報の解釈に基づいて、判定されてもよい。例えば、ＰＦ１０４は、ユーザＡの操作ログを読み、ユーザＡが最近の所定の時間内に活動していたと判定し、ユーザＡは、推定状態として「オンライン」であると想定してもよい。

次いで、ＰＦ１０４は、ユーザＡのプレゼンス状態をＵＷＦ１０２に返す。次いで、ＵＷＦ１０２は、ユーザＡのプレゼンス情報２４２をユーザＢのデバイスに送信する。このデバイスは、図３に示すように、この情報をユーザＢに視覚的に表示２４４してもよい。

当業者は、記述するＲＥＳＴｆｕｌプレゼンスサービスが、ユーザに対して受動的なステートレスのプレゼンス状態を提供することが、分かるであろう。ユーザの状態は、別のユーザが情報を要求したときに判定されるだけである。この方法は、セッションの確立、維持、および最終的な切断に関してネットワークのオーバヘッドを必要としないし、ユーザのプレゼンス状態を能動的に維持するために必要な、継続的なネットワークトラヒックも必要としない。

図３は、ユーザの移動デバイス３００が図２で判定されたプレゼンス状態を表示する表示の一例を示す。ユーザに関する種々のプレゼンス状態の例は、「オンライン」３０２、「通話中」３０４、または「オフライン」３０６である。

図４は、本発明の通話サービスの呼フローの一例示的実施形態を示す。この例がＲＰＣＳ１０８のＵＷＦ１０２およびＣＦ１０６に係わるものの、ＵＷＦ１０２とＣＦ１０６との通信およびやり取りに関する具体的な詳細については、簡潔にするために省略されていることが、当業者には分かるであろう。ユーザＡ４０２は、自分の移動デバイス上の連絡先リストからユーザＢ４０４を選択し、ＵＷＦ１０２を通してユーザＢに通話への招待メッセージ４０６を送信してもよい。招待メッセージ４０６は、ＨＴＴＰ ＰＯＳＴまたは他の任意の適切なメッセージであってもよい。ユーザＡからの招待メッセージ４０６の受信後、ＵＷＦ１０２は、通話オブジェクト（またはリソース）を識別するようにＣＦ１０６に指示する。

通話オブジェクトは、ＦＳ１１６またはネットワークの中央データ記憶装置に格納されるデータオブジェクトまたはエントリであってもよい。各通話オブジェクトは、一意の識別情報（ＩＤ）、通話の参加者リスト（すなわち、ユーザＡおよびユーザＢ）、および通話履歴４０５を有していてもよい。参加者は、名前、ＭＳＩＳＤＮ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ Ｎｕｍｂｅｒ）、または加入者に一意の他の任意のパブリックアイデンティティであってもよい。通話履歴４０５は、通話オブジェクトに関係している参加者間で交わされた以前の全てのメッセージを格納するファイルであってもよい。通話オブジェクトは、通話履歴を含んでいてもよいし、またネットワークのほかのどこかに格納されている通話履歴へのポインタであってもよい。

ステップ４０８において、ＣＦ１０６は、通話オブジェクトおよび通話ＩＤが参加者間の以前の通話のために既に存在しているかどうかを判定する。通話オブジェクトが存在しない場合、ＣＦ１０６は、新しい通話オブジェクトおよび関連する通話ＩＤを作成する。

ＵＷＦ１０２は、生成されたかまたは既存の通話オブジェクトに関する通話ＩＤを受信する。次いで、ＵＷＦ１０２は、その通話ＩＤをメッセージ４１０に入れてユーザＡのデバイスに転送する。メッセージ４１０には、ユーザＡのデバイスのチャット・クライアント・アプリケーションを起動するための、アプリケーション識別情報を含んでいてもよい。この場合、チャットクライアントは、メッセージ４１２をＲＰＣＳ１０８に送信することによって、ロングポーリングメカニズムを使用して、通話オブジェクトのリスニングチャネルを作成してもよい。

ロングポーリングは、サーバからクライアントへの情報プッシュを模倣できるようにするポーリング技術である。ロングポーリングを使用して、クライアントは、通常のポーリングと同様にサーバに情報を要求する。しかし、サーバは、クライアントに提供可能な情報を少しも持っていない場合、中身のない応答を送信する代わりに、要求を保持し、情報が提供可能になるのを待つ。情報が提供可能になると直ぐに（または適切な小休止の後）、完全な応答をクライアントに送信する。この場合、クライアントは、通常、直ぐにサーバに情報を再要求して、サーバが、イベントを受けて更新したデータを配信するために使用できる利用可能な待機中の要求を、ほとんど常に有するようにする。

また、ＵＷＦ１０２は、ショートメッセージサービスセンタ（ＳＭＳ−Ｃ）１１８を介してユーザＢのデバイスに、通話ＩＤを含むＳＭＳ−０メッセージを送信する指示４１４も送信する。ＳＭＳ−Ｃ１１８は、ユーザＢにＳＭＳ−０ ４１６を送信して、ＳＭＳ−Ｃ１１８に肯定応答４１８が返されると、肯定応答４２０をＵＷＦ１０２に返して、ＵＷＦ１０２にＳＭＳ−０ ４１６の配信が完了したことを通知する。このＳＭＳ−０ ４１６は、チャット・クライアント・アプリケーション開始のトリガと、リッスンすべき通話オブジェクトへのポインタの両方に使用される。ＳＭＳ−０メッセージの使用は、ユーザＢのデバイスに通知する一方法例であることが分かるであろう。他の可能な方法には、マルチメディアメッセージングサービス（ＭＭＳ）メッセージ、Ｅメール、またはＳＩＰメッセージの使用を含む。この場合、ユーザＢのデバイスのチャット・クライアント・アプリケーションは、要求４２２をＵＷＦ１０２およびＣＦ１０６に送信して、受信した通話ＩＤによって識別される通話オブジェクトを取り出す。ＲＰＣＳ１０８は、要求４２４および返答４２６を使用して、通話オブジェクトに関して存在しうるいかなる通話履歴もＦＳ１１６から取り出すことができる。ＲＰＣＳ１０８は、通話履歴をユーザＢに転送４２８してもよい。ＵＷＦ１０２は、ユーザＢが通話に参加したことを、リスニングチャネルで送信する応答４３０によってユーザＡに示すことができる。ユーザＡのデバイスは、ロングポーリングまたは他の適切なメカニズムで、リスニングチャネルを更新４３２する。

ユーザＢは、ＵＷＦ１０２を通してユーザＡに新しいメッセージ４３４をポストする。ＵＷＦ１０２は、そのメッセージをＦＳ１１６の通話オブジェクトの中に格納するために、メッセージをＣＦ１０６に渡す。ＣＦ１０６は、更新情報４３６をＦＳ１１６に送信して、リターンとして更新情報に対するＡＣＫ４３８を受信する。ＵＷＦ１０２は、ユーザＢがポストしたメッセージに対する肯定応答メッセージについて、分岐動作４４０をする。ユーザＡは、通話オブジェクトに対して継続するロングポーリングのリターン４４２として、ユーザＢがポストしたメッセージ（すなわち、通話オブジェクトへの更新情報）を受信する。ユーザＢは、メッセージ４３４のポストに対する肯定応答４４４を受信する。

２人を超える参加者がいるグループ通話の場合は、分岐動作４４０は、ユーザＢがポストしたメッセージを全ての他のグループメンバに送信するように行われてもよい。例えば、ユーザＣ（図示せず）は、通話オブジェクトの継続するロングポーリングに対する応答として、リターン４４２と同様に、ユーザＢがポストしたメッセージを受信することができる。

メッセージ４４２および４４４の受信後、ユーザＡとユーザＢの両方とも、ロングリスニングチャネルを更新する必要がある。メッセージ４４２を受信すると、ユーザＡのデバイスのチャット・クライアント・アプリケーションが起動され、ロングポーリング４４６によってリスニングチャネルを更新する。メッセージ４４４を受信すると、ユーザＢのデバイスのチャット・クライアント・アプリケーションが起動され、ロングポーリング４４８によってリスニングチャネルを更新する。

ユーザＡおよびユーザＢのデバイスは、それぞれのチャット・クライアント・アプリケーションが動作し続ける限り、通話オブジェクトのロングポーリングを続けてもよい。通話オブジェクトに新しい情報が追加されると直ぐに、その情報はユーザに返される。ユーザがチャット・クライアント・アプリケーションを終了すると、そのクライアントのデバイスが、通話オブジェクトのリッスンを停止するだけである。他の参加者は、あるユーザが通話から去った（すなわち、リッスンを停止した）という更新情報を受信することができる。

図５は、本発明の一実施形態による通話サービスを初期設定する方法を示すフロー図である。この方法は、図１のＲＰＣＳ１０８のような通信ネットワークの１つのノードによって実施されてもよいし、またネットワークの複数のノードまたはモジュールによって実施されてもよい。ステップ５０２において、第１のユーザデバイスからチャット要求を受信する。チャット要求は、第１のユーザとのチャット／通話への参加を要請された第２のユーザまたは複数のユーザを識別してもよい。ステップ５０４において、受信したチャット要求に一致する通話オブジェクトが識別される。通話オブジェクトは、第１のユーザおよびチャット要求の中で要請された参加者のアイデンティティによって識別されてもよい。ステップ５０４は、チャット要求に関する通話オブジェクトが既に存在するかどうかの判定を有していてもよい。通話オブジェクトが存在しない場合、新しいオブジェクトが作成されてもよい。ステップ５０６において、通話オブジェクト識別情報が通話の参加者に送信される。通話オブジェクト識別情報は、第１のユーザデバイスに送信された、チャット要求に対する返答の中に含まれていてもよい。通話オブジェクト識別情報は、要請された参加者に送信されたチャット招待メッセージの中に含まれていてもよい。招待兼通話オブジェクト識別情報は、ＳＭＳ−０メッセージまたは他の手段によって送信されてもよい。ステップ５０８において、通話履歴は、履歴が存在する場合、オプションで各ユーザデバイスに送信されてもよい。通話履歴には、参加者間で以前交わされたあらゆるメッセージ、および必要に応じて各参加者のプレゼンス状態を含んでいてもよい。ステップ５１０において、更新情報を聞くために通話オブジェクトをリッスンしたいというリッスン要求が、通話中の各ユーザデバイスから受信される。このリッスン要求は、ロングポーリング要求メッセージであってもよい。リッスン要求は、通話オブジェクトの更新通知を受信したいという要求であってもよい。

図６は、本発明の一実施形態による通話サービスを更新する方法を示すフロー図である。ステップ６０２において、通話オブジェクトの少なくとも１人の参加者のデバイスから、通話オブジェクトの更新情報を聞くためにリスニングチャネルを作成したいというリッスン要求が受信される。リッスン要求は、ロングポーリング要求メッセージであってもよい。ステップ６０４において、第１の参加デバイスから通話オブジェクトを更新するメッセージが受信される。ステップ６０６において、受信したメッセージに従って、通話オブジェクトが更新される。通話更新情報の更新は、通話履歴の中に受信したメッセージを保存または格納してもよい。ステップ６０８において、ステップ６０２で受信したリッスン要求に対する返答として、および通話オブジェクトの更新６０６に応えて、通話更新通知が各参加者に送信される。通話更新通知は、第１の参加者のメッセージ６０４が通話オブジェクトにポストされたことに対する、第１の参加者への肯定応答であってもよい。通話更新通知は、第１の参加者から受信したメッセージの他の全ての参加者への転送であってもよい。通話更新通知は、参加者の以前の更新以降に通話オブジェクトにポストされたどのコンテンツも取り出せるリンクであってもよい。ステップ６１０において、オプションで、新しいリッスン要求が、通話に参加のデバイスの一部または全部から受信されてもよい。

図７は、本開示の種々の実施形態のいずれも実施することができる一例のノード７００を示すブロック図である。ノード７００は、プロセッサ７０２、通信インタフェース７０４、およびメモリ７０６を有する。メモリ７０６は、命令を格納することができ、この命令は、プロセッサ７０２で実行されると、ノード７００が図１のＲＰＣＳ１０８のユニバーサルウェブサービス機能１０２、プレゼンス機能１０４、および通話機能１０６を含む機能を実行できるようにする。また、メモリ７０６は、少なくとも２人の参加者間の通話に関連する通話オブジェクトも格納することができる。通信インタフェース７０４は、第１のユーザデバイスから第２のユーザデバイスとの通話を開始したいという要求を受信する。また、通信インタフェース７０４は、第１のユーザデバイスから更新情報を聞くために通話オブジェクトをリッスンしたい、および更新時に通知を受信したいというリッスン要求も受信する。

プロセッサ７０２は、受信した要求に関連する通話オブジェクトを識別する。通話オブジェクトの識別には、第１と第２のユーザの両方に関連する通話オブジェクトが、メモリ７０６に格納されて既に存在しているかどうかの判定を含んでもよい。そのような通話オブジェクトが存在しない場合、プロセッサ７０２は、メモリ７０６内に新しい通話オブジェクトを作成する。プロセッサ７０２は、第２のユーザに通話への招待メッセージを送信するように通信インタフェース７０４に指示する。この招待メッセージは、識別した通話オブジェクトを示す。招待メッセージには、通話ＩＤを含んでいてもよい。プロセッサ７０２は、必要に応じて通信インタフェース７０４に指示して、通話オブジェクトに関連する通話履歴をユーザの一方または両方に送信させてもよい。通話履歴は、メモリ７０６にアクセスして取り出されてもよいし、あるいは通信ネットワークのほかのどこかにあるデータ記憶装置に格納されていてもよい。

通信インタフェース７０４は、第２のユーザデバイスから新しいメッセージを受信する。プロセッサ７０２は、新しいメッセージの受信を受けて通話オブジェクトを更新し、第２のユーザデバイスからの通話更新情報の受信を受けて、第１のユーザデバイスから受信したリッスン要求に対する返答を送信するように通信インタフェース７０４に指示する。第１のユーザデバイスに送信される、受信したリッスン要求に対する返答は、第２のユーザデバイスから受信した新しいメッセージを含んでいてもよい。また、通信インタフェース７０４は、第２のユーザデバイスに肯定応答を送信して、第２のユーザデバイスのメッセージを受信し、通話オブジェクトを更新したことを通知してもよい。通信インタフェースは、第１のユーザデバイスから、通話オブジェクトの更新通知を求める新しいリッスン要求を受信してもよい。

本開示のＲＥＳＴベースのプレゼンス兼通話サービスは、重いインストラクチャにも、重いセットアップにも、重いネットワークオーバヘッドにも依存しない。通話またはプレゼンス情報に登録または加入するようにユーザに要求しない。本開示は、疑問の余地のない状態ではなく、記録された操作に基づく受動的または想定のプレゼンス状態を使用する。この解決手段は、ＳＩＰスタックの使用もＩＭＳインフラストラクチャの使用も必要としないで、ＨＴＴＰベースのＡＰＩを実施するＲＥＳＴベースのクライアントしか必要としない。解決手段は、いったん通話が終了すると動作中のセッションがないのでステートレスである。本開示においては、ユーザデバイスのチャット・クライアント・アプリケーションが通話を担当し、招待は、例えばＳＭＳによって制御される。動作中のセッションの終了とは対照的に、クライアントは、通話オブジェクトのリッスンを停止するだけでよい。

これまで述べたことから、本開示が有利な解決手段を提供することは、今や当業者には明白なはずである。本開示のシステムおよび方法について、ある種のメッセージおよびノードを特に参照して述べているが、本明細書の参照時に、本明細書に含まれる本発明の教示が必ずしもそれらに限定されず、種々のやり方で有利に実施されうることが認識されるはずである。本発明の運用および構築は、これまでの説明から明白だと思う。

本発明の実施形態は、永久的マシン可読媒体（コンピュータで読み取り可能な媒体、プロセッサで読み取り可能な媒体、コンピュータで読み取り可能なプログラムコードを中に組み込んでいるコンピュータ使用可能媒体とも呼ばれる）の中に格納されたソフトウェアプロダクトとして表現されてもよい。マシン可読媒体は、ディスク、コンパクトディスク・リードオンリメモリ（ＣＤ−ＲＯＭ）、ＤＶＤ−ＲＯＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、メモリデバイス（揮発性または不揮発性）、または類似のストレージ機構を含む磁気、光または電気的ストレージ媒体を含む、任意の適切な有形の媒体であってもよい。マシン可読媒体は、実行されると、プロセッサに本発明の一実施形態による方法のステップを行わせる命令の種々のセット、コードシーケンス、設定情報、または他のデータを含んでいてもよい。当業者は、記述した本発明を実施するために必要な他の命令および動作もまたマシン可読媒体に格納されてもよいことが分かるであろう。マシン可読媒体から実行されるソフトウェアは、記述のタスクを実行するために、電気回路と連動してもよい。

本発明の上述の実施形態は、例にすぎない。本明細書に添付される特許請求の範囲によって規定される本発明の範囲から逸脱することなく、当業者が、特定の実施形態に対して、変更、修正および変形を行いうる。

Claims (20)

1. 通信ネットワークにおいてユーザ間の通話サービスを初期設定する方法であって、
   第１ユーザデバイスから第２ユーザデバイスとの通話を開始することを要求するリクエストを受信するステップと、
   前記受信したリクエストに関連付けられている通話オブジェクトを識別するステップと、
   前記通話オブジェクトに関連付けられている識別情報を含むインビテーションを前記第２ユーザデバイスに送信するステップと、
   前記通話オブジェクトの更新を通知するリッスンリクエストを前記第１ユーザデバイスから受信するステップと
   を有することを特徴とする方法。
2. 前記通話オブジェクトを識別するステップは、前記第１ユーザデバイスおよび前記第２ユーザデバイスに関連付けられている通話オブジェクトが存在するかどうかを判定するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記通話オブジェクトが存在しないことを受けて、前記第１ユーザデバイスおよび前記第２ユーザデバイスに関連付けた通話オブジェクトを生成するステップをさらに有することを特徴とする請求項２に記載の方法。
4. 前記第１ユーザデバイスに関連付けられている通話オブジェクトの識別情報を送信するステップをさらに有することを特徴とする請求項１に記載の方法。
5. 前記インビテーションは、ＳＭＳ−０メッセージであることを特徴とする請求項１に記載の方法。
6. 前記第１ユーザデバイスと前記第２ユーザデバイスとの少なくとも一方への前記通話オブジェクトに関連付けられている通話履歴を送信するステップをさらに有することを特徴とする請求項１に記載の方法。
7. 前記第２ユーザデバイスから通話更新情報を受信したことを受けて前記受信したリッスンリクエストに対するリプライを送信するステップをさらに有することを特徴とする請求項１に記載の方法。
8. 通信ネットワークにおいてユーザ間での通話を更新する方法であって、
   第１ユーザデバイスから通話オブジェクトの更新を通知するリッスンリクエスト受信するステップと、
   前記通話オブジェクトに関連付けられているメッセージを前記第２ユーザデバイスから受信するステップと、
   前記受信したメッセージに応じて前記通話オブジェクトを更新するステップと、
   前記通話オブジェクトを更新したことを受けて前記受信したリッスンリクエストに対するリプライを前記第１ユーザデバイスに送信するステップと
   を有することを特徴とする方法。
9. 前記受信したリッスンリクエストに対するリプライは、前記第２ユーザデバイスから受信した前記メッセージを含んでいることを特徴とする請求項８に記載の方法。
10. 前記通話オブジェクトの更新を通知するリッスンリクエストを前記第２ユーザデバイスから受信するステップをさらに有することを特徴とする請求項８に記載の方法。
11. 前記受信したメッセージに応じて、前記通話オブジェクトを更新することを知らせる前記第２ユーザデバイスから受信したリッスンリクエストに対するリプライを送信するステップをさらに有することを特徴とする請求項１０に記載の方法。
12. 前記通話オブジェクトを更新するステップは、前記通話オブジェクトに関連付けられている通話履歴に前記受信したメッセージを格納するステップをさらに有することを特徴とする請求項８に記載の方法。
13. 前記リプライを送信したことを受けて、前記通話オブジェクトを更新することを通知する更新されたリッスンリクエストを前記第１ユーザデバイスから受信するステップをさらに有することを特徴とする請求項８に記載の方法。
14. 前記受信したリッスンリクエストは、ロングポーリングリクエストメッセージであることを特徴とする請求項８に記載の方法。
15. 通話システムであって、
    第１ユーザデバイスおよび第２ユーザデバイスに関連付けられている通話オブジェクトを記憶するメモリと、
    前記第１ユーザデバイスから前記第２ユーザデバイスとの通話を開始することを要求するリクエストを受信するとともに、前記通話オブジェクトの更新を通知するリッスンリクエストを受信する通信インタフェースと、
    前記受信したリクエストに関連付けられている前記通話オブジェクトを識別し、前記識別された通話オブジェクトを示すインビテーションを前記第２ユーザデバイスに送信するよう前記通信インタフェースに指示し、前記第２ユーザデバイスから通話更新情報を受信したことを受けて前記受信したリッスンリクエストに対するリプライを送信するプロセッサと
    を有することを特徴とする通信システム。
16. 前記プロセッサは、前記第１ユーザデバイスおよび前記第２ユーザデバイスに関連付けられている通話オブジェクトが前記メモリに記憶されているかどうかを判定することを特徴とする請求項１５に記載の通話システム。
17. 前記プロセッサは、前記通話オブジェクトが存在しないことを受けて、前記第１ユーザデバイスおよび前記第２ユーザデバイスに関連付けた通話オブジェクトを前記メモリ内に生成することを特徴とする請求項１６に記載の通話システム。
18. 前記通信インタフェースは、前記第２ユーザデバイスからメッセージを受信し、
    前記メッセージが受信されたことを受けて、前記プロセッサは、前記通話オブジェクトを更新することを特徴とする請求項１５に記載の通話システム。
19. 前記受信したリッスンリクエストに対する前記リプライは前記通話更新情報を含むことを特徴とする請求項１５に記載の通話システム。
20. 前記受信したリッスンリクエストは、ロングポーリングリクエストメッセージであることを特徴とする請求項１５に記載の通話システム。

Images