JP2010508686A - 通信システムにおける配信レポート - Google Patents

Abstract

配信レポートについて更新が受信される可能性のある不完全なレポートであるのかまたは更新が受信されない完全なレポートであるのかを該配信レポートの受信者へ示す機構を、配信レポートの機能を拡張してそのレポートが完全なレポートであるか不完全なレポートであるかを示す識別情報を含めることによって、提供する。
【選択図】図４

Description

発明の分野

本発明は、通信システムにおける配信レポートに関し、特に、集約型レポート（aggregated report）とすることのできる配信レポートに関する。

背景技術に関する以下の記載は、本発明に先立つ関連技術では知られていない、本発明によって提供される知見、発見、認識または開示、あるいは開示に伴う関連事項を含みうる。本発明のかかる提案の一部については以下に具体的に示されるが、一方それ以外の、本発明の上述のような提案については、文脈から明らかになるであろう。

通信技術、とりわけＩＰベースの通信技術の発達、ならびにエンドユーザ端末の発達により、汎用性のある通信の実現および様々なサービスの導入が可能になってきた。頻繁に、ＳＩＰ（Session Initiation Protocol：セッション開始プロトコル）によって提供されるプリミティブを用いて諸サービスが実施されている。ＳＩＰは、通信システムに垂直に統合されるものではなく、マルチメディア・アーキテクチャを構築するツールである。より正確には、ＳＩＰは、ＩＥＴＦにより定義された、１者以上の参加者のあるセッションを作成、変更および終了させるためのアプリケーション層コントロール（シグナリング）プロトコルである。上述のセッションとしては、例えば、インターネット通話、マルチメディア配信、マルチメディア会議、インスタント・メッセージングなどがある。

ＳＩＰセッションを利用すると特に便利な機能の１つは、グループ通信である。本明細書で用いられる用語「グループ」は、同一のグループ通信へ参加しようとする二者以上のユーザすなわちグループ・メンバーから成る任意の論理グループを指し、グループ通信は、二者以上の参加者間のセッションを対象として扱う。インスタント・メッセージによるグループ通信では、通常、以下で発信者と称するインスタント・メッセージの送信者が、そのグループをホストするサーバへインスタント・メッセージを送信し、このメッセージが、該サーバによって、他のグループ・メンバーすなわち対象の受信者へ送信される。インスタント・メッセージングに関する特徴として、発信者が、メッセージの配信レポートを要求することができるということがある。そのようなレポートが要求される場合、各受信者から受信した応答を集約して配信レポートを集約型レポートの形で発信者へ送信するように、サーバが構成されているとよい。

グループ通信における上記の構成に関連する問題の１つは、サーバが、対象の参加者全員が応答してから１つだけレポートを送信する代わりに、複数のレ￥ポートを送信するかもしれないのに（つまり、対象の参加者全員の応答が済む前に少なくとも１つの集約型レポートを送信し、対象の参加者全員が応答した後で少なくとも１つのレポートを送信するかもしれないのに）、サーバには、そのレポートが更なるレポートによって更新が送られて来る可能性のある不完全なレポートであるのか、更新が送られて来ないレポートであるのかを発信者に対して示す機構や手段が、備えられていないということである。

概要

従って本発明の目的は、上記の問題を克服するための方法や、該方法を実施する装置を提供することである。本発明の目的は、独立請求項における記載によって特徴付けられる方法、装置、モジュール、シグナリング・メッセージ、およびコンピュータ・プログラムによって達成される。本発明の好適な実施形態は、従属請求項に開示される。

本発明は、問題を認識した上で、配信レポートの機能を拡張して該レポートが完全なレポートであるのか不完全なレポートであるのかを示す識別情報を含めることで問題を解決することに、基づいている。

本発明の利点は、レポートの受信者、すなわち発信者が、或るメッセージに関して、更新されたレポートなどの追加的レポートを受信する可能性があるか否かを知ることができるようになる機構を提供することにある。発信者は、この情報を用いて、例えば、レポートとメッセージとの相互関連付けに使用されるメッセージ識別子を不要な情報としてメモリから削除するか、あるいはさらなるレポートとメッセージとの相互関連付けができるように該メッセージ識別子を保持しておくかどうかなどについて、判断を下すことができる。

以下、添付の図面を参照しつつ、さらに詳しく実施形態を説明する。

グループ通信サービスを提供する通信システムの全体的なアーキテクチャの一例を示す図である。 本発明の実施形態による装置の簡略的なブロック図である。 本発明の実施形態による装置の簡略的なブロック図である。 本発明の一実施形態による配信レポートの一例を示す図である。 本発明の一実施形態によるシグナリングを示すシグナリング図である。 本発明の実施形態による装置の機能を示すフロー図である。 本発明の実施形態による装置の機能を示すフロー図である。

いくつかの実施形態の詳細な説明

以下の実施形態は例示的なものである。本明細書ではいくつかの箇所で「或る」、「１つの」または「いくつかの」実施形態（単数または複数）に言及し得るが、このことは必ずしも、そのような言及の各々が同じ実施形態（単数または複数）を指すこと、あるいはその特徴が単独の実施形態のみに当てはまることを意味するものではない。各種実施形態の単独の特徴を組み合わせて、別の実施形態を提供することもできる。

本発明は、通信の集約型のレポーティングをサポートする任意のユーザ端末、サーバ、対応する任意のコンポーネント、および／または任意の通信システムもしくは様々な通信システムの任意の組み合わせに対して、適用可能である。該通信システムは、固定式通信システムもしくはワイヤレス通信システム、または固定式ネットワークとワイヤレス・ネットワークとの双方を利用した通信システムとすればよい。使用されるプロトコル、通信システムの規格、サーバおよびユーザ端末は、特にワイヤレス通信において、急速に発展する。こうした発展によって、実施形態に対する余分な変更が必要となることもある。従って、全ての語句および表現は、広く解釈されるべきものであり、実施形態を限定することではなく説明することを目的とするものである。

以下、通信の一例としてインスタント・メッセージを使ったグループ通信を用い、さらに、本発明を適用可能なシステム・アーキテクチャの一例としてＳＩＰに基づいたアーキテクチャを用いて本発明を説明するが、通信は、そのようなグループ通信およびそのようなアーキテクチャに限定されるものではない。

グループ通信を提供する通信システムの全体的なアーキテクチャを図１に示す。図１は、簡略化されたシステム・アーキテクチャであって、一部の要素および機能エンティティのみが示されている。これら一部の要素および機能エンティティは全て論理ユニットであり、その実装は図に示すものと異なる可能性がある。図１に示す接続は論理的な接続であり、実際の物理的な接続はこれと異なる可能性がある。当業者には明らかなことであるが、システムにはさらに他の機能および構造が含まれる。なお、グループ通信において、またグループ通信のために使用される機能、構造、要素およびプロトコルは、実際の本発明にとって重要ではないことに留意されたい。従って、ここでさらに詳細に述べる必要はないだろう。

図１の通信システム１００は、ユーザ端末３００、３００'、３００''、３００'''を含み、上記ユーザ端末は各々、オペレータ・ネットワークを介して、各自のネットワーク・オペレータのサーバ２００、２００'と接続可能である。各オペレータ・ネットワークは、アクセス・ネットワークとコア・ネットワークとを含んでいることが好ましく、場合によっては、インターネットなどのルーティング・ネットワーク（図１には図示せず）を介して別のオペレータ・ネットワークと接続されている。

ユーザ端末３００、３００'、３００''、３００'''は、ユーザ端末およびそのユーザをサブスクリプションに関連付けるまたは関連付けるように構成されている機器またはデバイスであって、ユーザによる通信システムとのやり取りを可能にしている。ユーザ端末は、ユーザへ情報を提示し、ユーザが情報を入力できるようにしている。言い換えれば、ユーザ端末は、ネットワークからの情報の受信および／またはネットワークへの情報の送信が可能であり、ワイヤレスにまたは固定式接続を介してネットワークに接続可能な任意の端末とすればよい。ユーザ端末の例としては、パーソナル・コンピュータ、ゲーム・コンソール、ラップトップ（ノートブック）、パーソナル・デジタル・アシスタント、移動局（移動電話）、有線電話などが挙げられる。

サーバ２００、２００'は、グループ通信サーバへのアクセスを提供するサーバ、またはグループ通信サーバとすればよく、あるいは双方のサーバとして機能するサーバとしてもよい。グループ通信サーバへのアクセスを提供するサーバは、そのオペレータのサブスクリプションを利用している各ユーザのオペレータ・ネットワークを介してアクセス可能なサーバである。グループ通信サーバは、１つ以上のセッションに関してグループ通信サービスを提供する。グループ通信サービスとしては、例えば、グループ通信の他の参加者へインスタント・メッセージを配信すること、グループ通信において参加者各々に対するＳＩＰシグナリング関係を維持すること、グループ通信を構成する媒体を参加者各々が確実に受信するようにつかさどること、グループ通信ポリシを実施することなどが挙げられる。例えば、オペレータＡのサーバＡ２００が、ユーザ端末３００、３００'、３００''および３００'''のグループ通信サーバであって、各自オペレータＡのサブスクリプションを利用しているユーザ端末３００、３００'、３００''に対してグループ通信サービスへのアクセスを提供し、同時に、オペレータＢのサーバＢ２００'が、オペレータＢのサブスクリプションを利用しているユーザ端末３００'''に対してグループ通信サービスへのアクセスを提供するとよい。グループ通信サーバは、ここではさらに、フォーカス、そのセッションをホストしているサーバ、チャット・ルーム・サーバ、および／または制御サーバをも対象として含む。グループ通信へのアクセスを提供するサーバは、参加型サーバと称してもよい。

グループ通信へのアクセスを提供するサーバ、および／またはグループ通信サーバであるサーバ２００、２００'は、アプリケーションに従ってグループ通信サービスを提供する。サーバは、いくつかのアプリケーションを含む場合もあるが、グループ通信またはチャットまたはセッションに関しては、１つのアプリケーションに従ってサブスクライバへグループ通信サービスを提供する。ただし、同じサブスクライバの別のグループ通信に関して、または同じグループ通信に関するが別のサブスクライバに対しては、別のアプリケーションを使用してもよい。グループ通信サービスを提供するアプリケーションは、グループ通信を提供するものであればいかなるアプリケーションであってもよい。ＳＩＰに基づいており、少なくともインスタント・メッセージング・サービスをグループに提供するアプリケーションの例としては、ＰｏＣ（push-to-talk over cellular：プッシュ・トゥ・トーク・オーバー・セルラ、ＯＭＡ：Open Mobile Alliance：オープン・モバイル・アライアンスにより定義されている）や、IETF SIMPLE（すなわちＩＥＴＦにより定義されたSIP for instant messaging and presence leveraging extensions：インスタント・メッセージングおよびプレゼンス活用を拡張するためのＳＩＰ）、ＯＭＡインスタント・メッセージング・サービス（すなわち、SIP/SIMPLEのプロトコルに基づいておりＯＭＡにより定義されているインスタント・メッセージング・イネーブラ）などが挙げられる。ＯＭＡ規格に関するさらに詳細な情報は、http://www.openmobilealliance.orgで見ることができ、ＩＥＴＦ規格およびインターネット・ドラフトに関するさらに詳細な情報はhttp://www.ietf.orgで見ることができる。従って、サーバ２００や２００'は、例えばＰｏＣサーバ、またはＯＭＡインスタント・メッセージング・サーバ、あるいはIETF SIMPLEインスタント・メッセージング・サーバとしてもよい。

図２は、本発明の一実施形態による装置のブロック図である。装置２００は、該装置が配信に参加した通信について集約型配信レポートを作成することが可能なサーバ、任意の中間ノード、あるいはホストとなるように、構成されている。この装置を１つのエンティティとして図示したが、１つ以上の物理的または論理的エンティティに様々なモジュールおよびメモリを実装することもできる。集約型の配信レポートを作成するために、この装置は、通信およびその配信に関する情報を少なくとも一時的に保存するデータ・ストレージ２０と、集約型レポートを提供するレポート・プロバイダ・ユニット２１と、各種の入力、情報およびメッセージを受信する受信機ユニット２２と、各種の出力、情報およびメッセージを送信する送信機ユニット２３とを含む。レポート・プロバイダ・ユニット２１は、データ・ストレージ２０への情報の保存を制御し、送信機ユニット２３を制御し、受信機ユニット２２に応答するように構成されているとよい。

レポート・プロバイダ・ユニット２１の機能、およびデータ・ストレージ２０に保存される情報については、以下で図４乃至６を用いてさらに詳細に説明する。当然のことながら、本装置には、通信においてまたは通信のために使用される他のユニットを含めることもできるが、それらは実際の本発明にとって重要ではないため、ここでさらに詳細に述べる必要はない。

図３は、本発明の一実施形態による装置３００のブロック図である。この装置は１つのエンティティとして図示されているが、１つ以上の物理的または論理的エンティティに様々なモジュールおよびメモリを実装することもできる。装置３００は、配信レポートが要求される対象である通信の発信者として機能可能なユーザ端末、または対応するデバイスとなるように構成されている。この目的のために、本装置には、少なくとも、応答と通信との相互関連付けに必要なメッセージＩＤなどの通信識別子または対応する情報を、少なくとも一時的に保存し、かつ、一方は不完全なレポートに関しもう一方は完全なレポートに関する少なくとも２つのルールを保存する、データ・ストレージ３０と、アプリケーションに従って通信を提供し、レポートを処理するクライアント・ユニット３１と、レポートなど各種の入力、情報およびメッセージを受信する受信機ユニット３２と、各種の出力、情報およびメッセージを送信する送信機ユニット３３と、を含む。クライアント・ユニット３１は、データ・ストレージ３０への情報の保存を制御し、受信機ユニット３２に応答するように構成されているとよい。さらに、本装置が、ユーザへ情報を配信可能なユーザ端末となるように構成されている場合、本ユーザ端末は、ユーザへ情報を提示しユーザによる情報の入力を可能にするユーザ・インターフェース・ユニット３４を含むことが好ましい。ただし、ユーザ・インターフェース・ユニットは、装置に必須のユニットではない。クライアント・ユニット３１が、ユーザ・インターフェース・ユニット３４を介したユーザに対する情報の提示を制御するように、構成されているとよい。

クライアント・ユニット３１の機能は、以下で図４および７を用いてさらに詳細に説明する。当然のことながら、本装置には、通信においてまたは通信のために使用される他のユニットを含めることもできるが、それらは実際の本発明にとって重要ではないため、ここでさらに詳細に述べる必要はない。

実施形態をもって説明される、サーバもしくは対応するサーバ・コンポーネント、ユーザ端末、および／または対応する装置の機能を実現しているその他の対応するデバイスまたは装置などといった各装置は、従来技術の手段のみでなく、実施形態をもって説明される、対応する装置の機能を実現する手段をも含み、さらに各装置が別個の機能各々のための別個の手段を含んでいてもよいし、あるいは２つ以上の機能を果たすように手段が構成されていてもよい。検討中の各装置は、実施形態にて利用可能なプロセッサおよびメモリを含む。例えば、レポート・プロバイダ・ユニット２１またはクライアント・ユニット３１は、ソフトウェア・アプリケーション、またはモジュール、あるいは、演算プロセッサによって実行される算術演算としてまたはプログラムとして構成されたユニットとしてもよい。実施形態の機能を実現するのに必要な変更および構成は全て、ルーチンとして実施されてもよく、これらは、追加のまたは更新されたソフトウェア・ルーチン、アプリケーション回路（ＡＳＩＣ）、および／またはプログラム可能な回路として実装されるとよい。アプレットおよびマクロなど、プログラムとも称されるソフトウェア・ルーチンは、装置が読み取り可能な任意のデータ・ストレージ媒体に保存することができ、特定のタスクを実行させるプログラム命令を含む。ソフトウェア・ルーチンは、装置の中へダウンロードされてもよい。サーバもしくは対応するサーバ・コンポーネント、またはユーザ端末などといった装置は、コンピュータ、または単一チップのコンピュータ素子などのマイクロプロセッサとして構成されてもよく、少なくとも、算術演算に用いられるストレージ領域を提供するメモリと、該算出演算を実行する演算プロセッサとを含む。演算プロセッサの一例として、中央処理装置が挙げられる。メモリは、装置に取り外し可能に接続されている着脱可能なメモリとしてもよい。

図４は、一実施形態による配信レポートを開示している。本配信レポートは、異なるトランスポート・プロトコルを使うシステム間の相互運用を可能とする、アプリケーション・レベルのシグナリング・メッセージであることが好ましい。このようなメッセージの例としては、共通のプレゼンスおよびインスタント・メッセージング（ＣＰＩＭ：Common Presence and Instant Messaging）メッセージに対するインスタント・メッセージ配信通知（ＩＭＤＮ：Instant Message Delivery Notification）、ならびにＰｏＣ配信レポートが挙げられる。ただし、メッセージは、任意の適切なメッセージとすればよく、分かりやすくするために、図では、ｘｍｌ（extensible mark up language：拡張可能マークアップ言語）文書にてあり得るヘッダ・フィールド、パラメータ、またはコンテンツを全て含むとは限らない簡略化したメッセージとして示す。

図４に示す実施形態では、配信レポートが、該配信レポートと元のメッセージとを相互に関連付けるためのメッセージ識別子４−２と、集約型配信レポート４−３と、新しいパラメータ４−１として配信レポート内のｘｍｌ文書に対する拡張属性を含み、この新しいパラメータ４−１によって、該配信レポートが不完全なものであるか完全なものであるかを示している。完全な配信レポートは、受信された配信情報は全てレポート済みであって更新は予想されないことを示し、これに対し不完全な配信レポートは、更新が予想されることを示す。通常、完全な配信レポートは、配信情報が全て受信済みであることを示すのであるが、一部の配信情報がまだ受信されていないにもかかわらず配信情報のレポートが終わることを示すものであってもよい。実装によっては、完全な配信レポートは、全ての配信情報を集約したメッセージであってもよく、または前の集約型メッセージで送信済みの情報は含まずに、前の集約型メッセージへ情報を集約した後に受信された情報の集約のみを含んだ配信メッセージであってもよく、あるいは、情報は含まず、これ以上レポートは送信されないということを示すのみの配信メッセージであってもよい。図に示す例では、パラメータ４−１は、完全な配信レポートを示す値「full」を有する。図に示す実施形態では、配信レポートが不完全な配信レポートである場合、そのことはパラメータ値「partial」によって示される。

当然のことながら、実際の値名、すなわち例として挙げた「full」または「partial」は、本実施形態にとって何ら重要性を有するものではなく、任意の値名、例えば「full」の代わりに「last」または「final」を、「partial」の代わりに「more」を使用して、配信レポートが不完全なレポートであるか完全なレポートであるかを示すことができる。同様のことが、新しいパラメータ名、あるいは対応するインジケータにも当てはまる。

別の実施形態では、ｘｍｌ文書の拡張の代わりに、特定のヘッダが使用される。

図５は、一実施形態によるシグナリングを図示したシグナリング図である。図５の例では、ＵＴ−Ａのユーザが、サーバＡによってホストされておりかつＵＴ−Ａ、ＵＴ−Ｂ、ＵＴ−ＣおよびＵＴ−Ｄをグループ・メンバーとして有するグループＸに対してインスタント・メッセージを送信したがっており、さらにこのユーザは、このインスタント・メッセージの配信について情報を得たがっている。ここで、サーバＡは、完全なレポートが送信されるまで、不完全なレポートを或る特定の時間間隔で送信するように構成されていると仮定する。さらに、グループＸのグループ通信へのアクセスは、ＵＴ−Ａ、ＵＴ−ＣおよびＵＴ−Ｄに対してはサーバＡによって、ＵＴ−Ｂに対してはサーバＢによって、提供されると仮定する。

図５を参照すると、ＵＴ−Ａが、メッセージ識別子と配信レポートを求める要求とを含んだメッセージ５−１を送信する。メッセージ５−１の受信に応じて、サーバＡが、このインスタント・メッセージをメッセージ５−２で他のグループ・メンバーへ配信する。ＵＴ−Ｂへのメッセージ５−２は、サーバＢを介して送信される。

図５の例では、サーバＡは、各応答を様々な遅延時間で受信する。遅延時間が異なる理由の１つの例は、ＵＴ−ＣとサーバＡの間のリンクおよびＵＴ−ＤとサーバＡの間のリンクが、ＵＴ−ＢとサーバＡの間のリンクよりも速いことである。従って、メッセージ５−２に対するＵＴ−Ｃからの応答５−３およびＵＴ−Ｄからの応答５−４は、極めて迅速に受信される。何らかの理由で、ＵＴ−Ｂから何も応答が受信されないうちに、レポートを送信する時間間隔が終了するとしよう。すると、サーバＡは、ポイント５−５にて、受信済みの応答を集約し、不完全なレポートであることを示すようにレポート内のパラメータ値を設定して、レポート５−６を送信する。

レポート５−６の受信に応じて、ＵＴ−Ａは、ポイント５−７にて、レポートが不完全なレポートであることを検知し、該レポートを第１セットのルールに従って処理する。第１セットのルールの一例は、ユーザへ不完全なレポートを提示することと、これは完全なレポートではなく追加のレポートが来る予定であることをユーザに示すことと、を含む。第１セットのルールの別の例は、ユーザへレポートを提示しないことを含む。すなわちこの場合、ルールは１つのみである。

サーバＡは、ＵＴ−Ｂから応答５−８を受信する一方で、ポイント５−９にて、今度は全ての受信者が応答済みであることを検知し、ポイント５−９にて、受信済みの応答を集約し、完全なレポートであることを示すようにレポート内のパラメータ値を設定して、レポート５−１０を送信する。

レポート５−１０の受信に応じて、ＵＴ−Ａは、ポイント５−１１にて、レポートが完全なレポートであることを検知し、該レポートを第２セットのルールに従って処理する。第２セットのルールの一例は、ユーザへ完全なレポートを提示することと、メッセージ識別子を、もはや相互関連付けに不要であるという理由でメモリから削除することと、が含まれる。メモリからメッセージ識別子を削除することの利点には、空きメモリの量が増加すること、および該メッセージ識別子が再利用可能になることが含まれる。

実装によっては、レポート５−１０には、受信された応答全てを集約してもよいし、または前回のレポートより後、すなわちレポート５−６の作成および送信の後に受信された応答を集約してもよい。後者の実装では、ユーザ端末が、不完全なレポート群を一時的に保存し、ユーザへ提示する前に該不完全なレポート群を１つのレポートへ集約するように、構成されているとよい。あるいは、ユーザ端末は、ユーザへ不完全なレポート群を提示し、最後の不完全なレポートをもってそれ以上のレポートは来ないことを示すように、構成されていてもよい。

図６は、配信レポートを提供するサーバ機能、または対応する中間ノード機能、あるいはより正確には、本発明の一実施形態によるレポート・プロバイダ・ユニットを示すフロー図である。ただし、以下においては用語「サーバ」を使用する。本実施形態では、受信者各々からの応答が受信済みでないこと、および／または応答各々がフルの状態すなわち完全な応答であることを示していないことが、不完全なレポートによって示され、サーバは、引き続き応答を収集して更新されたレポートを送信する。

なお、何によって配信レポートの提供が引き起こされるのかということは、本発明に何ら重要性を持たないことに留意されたい。例えば、配信レポートの提供が要求されてもよいし、あるいは、具体的な要求がなくても配信レポートを送信するようにサーバが構成されていてもよい。

図６を参照すると、ステップ６０１にて、サーバが、受信していたインスタント・メッセージを各受信者へ向けて配信し、レポート機能が開始する（ステップ６０３）までは、ステップ６０２にて、受信者からの応答を受信する。レポート機能は、一定の時間が終了したこと、および／または一定量の応答が受信されたこと、および／または受信者各々がメッセージに対する応答を送信したことを理由に、開始されるとよい。例えば、直近の１０秒以内に新しい応答が少なくとも１つ受信されていれば１０秒おきにレポートを送信するように、サーバが構成されていてもよい。

レポート機能が開始する（ステップ６０３）と、ステップ６０４にて、サーバが、全ての応答を受信済みであるかどうか、言い換えれば受信者各々が応答済みであるかどうかを確認する。全ての応答を受信済みである場合、サーバは、応答が最終的な状態を示しているか否かを各応答について確認するように構成されている（ステップ６０５）。例えば、他のサーバからの応答が、受信者への配信を試みたが応答が受信されていないことを示していたり、メッセージは配信されたがまだ読み取られていないことを示していたりするなど、状態は最終的なものでないことを表している場合がある。さらなる例として、メッセージが受信者の「ストアアンドフォワード」ボックスへ配信されたことを応答が示していれば、状態が最終的なものであると解釈するように、サーバが構成されている場合もある。状態が各々最終的なものであれば、ステップ６０６にて、サーバは、集約型レポートをそれが完全なレポートであることを示すように設定し、ステップ６０７にて、該集約型レポートをインスタント・メッセージの送信者へ送信する。

応答のうちの１つが最終的な状態にない場合（ステップ６０５）、ステップ６０８にて、サーバは、集約型レポートをそれが不完全なレポートであることを示すように設定し、ステップ６０９にて、該集約型レポートをインスタント・メッセージの送信者へ送信し、再びレポート機能が開始されるまで、応答を受信してステップ６０２以降を続行する。

或る受信者から応答が受信されなかった場合（ステップ６０４）、ステップ６０８にて、サーバは、集約型レポートをそれが不完全なレポートであることを示すように設定し、ステップ６０９にて、該集約型レポートをインスタント・メッセージの送信者へ送信し、さらに、レポートがトリガされるまで、応答を受信してステップ６０２以降を続行する。

本発明の一実施形態では、サーバが、一定の時間応答を待つように構成されており、その時間の終了に当たり１つ以上の応答が受信されていない場合、サーバは、応答の収集を中止し、該レポートが完全なものであることを示す集約型レポートを送信するように構成されている。このレポートは、集約情報（aggregate information）の一部として、いくつかの応答が欠けているという識別情報を含んでいることが好ましい。一方、該レポートは、このレポートが完全なレポートであるという識別情報のみを含んでいてもよい。当然のことながら、応答の収集を中止させるのに、制限時間以外の他の何らかの理由、言い換えれば条件を使ってもよい。

一実施形態では、サーバが、受信される応答の所定の量に応じて配信レポートを送信するように構成されており、該所定の量は、１つ、２つなどの任意の数としてもよく、あるいはグループ・メンバーの総量に対する率として定められてもよい。上記所定の量は、さらに、以前に送信済みのレポートがいくつであるかによって決まってもよい。

図７は、本発明の一実施形態による、ユーザ端末または対応する装置における、配信レポートを処理するクライアント機能を示すフロー図である。ただし、以下においては、用語「ユーザ端末（User Terminal）」を使用する。図に示す実施形態では、ルールのセットは、完全なレポートが予め設定された最大時間内に受信された場合には完全なレポートのみをユーザへ提示することを含むと想定されている。すなわち以下で明らかになるように、実質的には異なるルールのセットが３つある。実装によっては、ユーザが、メッセージを送信するときに、完全なレポートのみを提示するかどうか、および／または完全なレポートを待つ最大時間をどれほどにするかを選択することもできる。あるいは、ルールのうちの１つ以上が、ユーザ端末設定の一部として構成されていてもよい。ここでのさらなる想定は、ユーザ端末がレポートを集約するのではなく、完全なレポートが、全ての応答の集約であるということである。

図７を参照すると、ステップ７０１にて、ユーザ端末が、メッセージの配信レポートを受信し、ステップ７０２にて、該レポートが不完全なレポートであるか完全なレポートであるかを確認する。該レポートが完全なレポートである場合、ステップ７０３にて、ユーザ端末は、該レポートまたはそのコンテンツを、ユーザ・インターフェースを介してユーザへ提示する。次いでステップ７０４にて、ユーザ端末は、メッセージ識別子を、この識別子はもはや必要ないという理由で、ユーザ端末のメモリから削除する。

レポートが不完全なレポートである場合（ステップ７０２）、ユーザ端末は、さらなるレポートが受信されるか、またはタイマーすなわち最大待ち時間が終了する（ステップ７０６）まで、ステップ７０５にて、さらなるレポートを待つ。最大待ち時間内にさらなるレポートが受信されたら（ステップ７０１）、プロセスは、レポートが不完全なレポートであるか完全なレポートであるかを確認するステップ７０２以降を続行する。タイマーが終了したら（ステップ７０６）、最後に受信された不完全なレポートまたはそのコンテンツが、ステップ７０７にて、ユーザ・インターフェースを介してユーザへ提示される。ユーザ端末が、レポートが不完全なレポートであることをも示すことが好ましい。その後ステップ７０４にて、ユーザ端末は、メッセージ識別子を、この識別子はもはや必要ないという理由で、自分のメモリから削除する。削除後に該メッセージに対するレポートが到着した場合、対応するメッセージ識別子がメモリ内にもはや存在しないので、このレポートはユーザ端末によって廃棄される。

当然のことながら、不完全なレポートまたは完全なレポートを処理する方法に関する上記のルールは例示的なものに過ぎず、別の実施形態では別のルールを使用してもよい。本発明は、決してルールを限定するものではなく、不完全なレポートおよび完全なレポートを処理する方法に実装の柔軟性を与えるものである。

図５乃至７で上述したステップ／ポイント、シグナリング・メッセージおよび関連機能は、絶対的な時系列におかれたものではなく、一部のステップ／ポイントを同時に、あるいは提示した順序とは異なる順序で実施してもよい。さらに、ステップ／ポイントの間またはステップ／ポイントの内部で別の機能を実行することもできるし、図示したメッセージの間で別のシグナリング・メッセージを送信することもできる。例えば、ユーザへレポートを提示する前に、ユーザ端末が、一般の人に向けてより適した／読みやすい形態になるようにコンテンツを編成してもよい。さらに、ステップ／ポイントのいくつか、もしくはステップ／ポイントの部分を省略すること、または対応するステップ／ポイントもしくはステップ／ポイントの対応する部分で置き換えることもできる。例えば、応答の状態を確認することすなわち図６におけるステップ６０５を、省いてもよい。サーバおよびユーザ端末の動作は、１つ以上の物理的または論理的エンティティにて実施可能なプロシージャを示している。シグナリング・メッセージは単なる例示に過ぎず、同じ情報を送信するのに、複数の別個のメッセージを含めることもできる。その上、メッセージには、別の情報を含めてもよい。

上述の実施形態は、例としてグループ通信を用いて上記に説明してきたが、該実施形態は、一対一通信に対して実装されることもでき、特に、配信確認および開封確認など、メッセージを元にしていくつかの応答が要求されている場合に適している。

当業者には言うまでもないことであるが、技術の進歩に伴い、本発明のコンセプトを様々なやり方で実現することが可能になる。本発明およびその実施形態は、上述した例に限定されるものではなく、請求項の範囲内で変わり得るものである。

Claims (28)

1. 通信の配信レポート中に、該レポートが不完全なレポートであるか完全なレポートであるかを示すことを含む、方法。
2. 前記不完全なレポートは、更新が予想されることを示し、前記完全なレポートは、更新が予想されないことを示す、請求項１に記載の方法。
3. 前記配信レポートを受信することと、
   不完全なレポートを第１セットのルールに従って処理することと、
   完全なレポートを第２セットのルールに従って処理することと、
   をさらに含む、請求項１または２に記載の方法。
4. 予め設定された期間、完全なレポートを待つことと、
   前記予め設定された期間内に前記完全なレポートが受信されなかった場合、受信済みの不完全なレポートを第３セットのルールに従って処理することと、
   をさらに含む、請求項１、２または３に記載の方法。
5. 予め設定された条件が満たされれば、レポートを完全なレポートとして示すことをさらに含む、請求項１、２、３または４に記載の方法。
6. 前記予め設定された条件は、前記通信の受信者各々から応答が受信されたことである、請求項５に記載の方法。
7. コンピュータ上またはプロセッサ上で実行されると、請求項１乃至６に記載のステップ群のいずれかを実行するように構成されるプログラム・コード手段を含む、コンピュータ・プログラム。
8. 通信に対する応答を含む信号を受信するように構成される受信機ユニットと、
   受信された応答に基づく配信レポートを含みかつ前記配信レポートが不完全なレポートであるか完全なレポートであるかを示す信号を生成するように構成されるプロセッサと、
   前記信号を送信するように構成される送信機ユニットと、
   を含む、装置。
9. 通信に対する応答を受信する受信手段と、
   受信された応答に基づく配信レポートを作成すると共に前記配信レポートが不完全なレポートであるか完全なレポートであるかを示す報告手段と、
   前記配信レポートを送信する送信手段と、
   を含む、装置。
10. 前記報告手段は、前記通信の受信者各々からの応答が受信された場合に、前記配信レポートを完全なレポートとして示すように構成される、請求項９に記載の装置。
11. 前記報告手段は、予め設定された条件が満たされたことに応じて、配信レポートを完全なレポートとして送信し、応答の受信を中止するよう前記受信手段に指示するように構成される、請求項９または１０に記載の装置。
12. グループ通信を提供するサーバ・コンポーネントである、請求項９、１０または１１に記載の装置。
13. 配信レポートと、前記配信レポートが不完全なレポートであるか完全なレポートであるかの識別情報とを含んだ信号を受信するように構成される受信機ユニットと、
    前記受信機ユニットに応答するように構成され、メッセージをどのように処理するかを決めるために前記識別情報を使用するように構成されるプロセッサと、
    を含む、装置。
14. 自身が不完全なレポートであるか完全なレポートであるかの識別情報を含む配信レポートを受信する受信手段と、
    前記受信手段に応答して、第１セットのルールに従って不完全なレポートを処理し、第２セットのルールに従って完全なレポートを処理する処理手段と、
    を含む、装置。
15. 前記処理手段が、予め設定された期間の終了に応じて、受信済みの不完全なレポートを第３セットのルールに従って処理するように構成される、請求項１４に記載の装置。
16. 前記装置が、ユーザ端末である、請求項１４または１５に記載の装置。
17. 通信システムにおいて通信の配信に関する集約情報を伝達するシグナリング・メッセージであって、前記メッセージは、前記集約情報が不完全であるか完全であるかを示す識別情報を含む、前記シグナリング・メッセージ。
18. 前記シグナリング・メッセージは、前記識別情報のためのパラメータを含んだｘｍｌ文書を含み、前記パラメータの値は、前記集約情報が不完全であるか完全であるかを示す、請求項１７に記載のシグナリング・メッセージ。
19. 前記シグナリング・メッセージが、前記識別情報のための特定のヘッダを含む、請求項１７に記載のシグナリング・メッセージ。
20. 前記シグナリング・メッセージが、アプリケーション・レベルのメッセージである、請求項１７、１８または１９に記載のシグナリング・メッセージ。
21. 前記シグナリング・メッセージが、プッシュ・トゥ・トーク・オーバー・セルラ配信レポート、または共通のプレゼンスおよびインスタント・メッセージングのメッセージに対するインスタント・メッセージ配信通知である、請求項２０に記載のシグナリング・メッセージ。
22. 請求項１７乃至２１のいずれかに記載のシグナリング・メッセージを生成するように構成される、モジュール。
23. 前記モジュールが、プロセッサまたはマイクロプロセッサである、請求項２２に記載のモジュール。
24. 請求項１７乃至２１のいずれかに記載のシグナリング・メッセージを受信および処理するように構成される、モジュール。
25. 前記集約情報が不完全であることを示しているシグナリング・メッセージを第１セットのルールに従って処理し、前記集約情報が完全であることを示しているシグナリング・メッセージを第２セットのルールに従って処理するように構成される、請求項２４に記載のモジュール。
26. 前記シグナリング・メッセージを処理するように構成されるプロセッサまたはマイクロプロセッサを含む、請求項２４または２５に記載のモジュール。
27. 請求項８乃至１６のいずれかに記載の装置を１つ以上含む、システム。
28. インスタント・メッセージング・グループ通信を提供するように構成される、請求項２７に記載のシステム。

Images