JP2010507302A

JP2010507302A - 名刺の挿入による「プッシュ・ツー・トーク」タイプ通信セッションのシグナリングの向上

Info

Publication number: JP2010507302A
Application number: JP2009532746A
Authority: JP
Inventors: レグランド，パトリック; ダイグレモント，ジョアン
Original assignee: アルカテル−ルーセント
Priority date: 2006-10-18
Filing date: 2007-09-11
Publication date: 2010-03-04
Also published as: US7869821B2; US20080096599A1; FR2907621B1; WO2008046697A1; FR2907621A1; CN101166314A; EP1921835A1; KR20090068335A

Abstract

発呼側通信クライアント（Ａ）と１つまたは複数の被呼側通信クライアント（Ｂ、Ｃ）との間で「プッシュ・ツー・トーク」タイプ通信セッションを設定するように意図されており、発呼側通信クライアントの論理アドレスと前記被呼側通信クライアントのアドレスとを含む招待シグナリング・メッセージ（ＭＩ）、「ＩＮＶＩＴＥ」を含む、移動通信網（Ｎ）用のＳＩＰタイプのシグナリング・プロトコル。
このプロトコルは、招待シグナリング・メッセージ（ＭＩ）が、発呼側通信クライアント（Ａ）のユーザに関連する名刺をも含むことを特徴とする。

Description

本発明は、通信ネットワークに関する。より詳細には、それは、具体的には「ＰｏＣ」（「ＰｕｓｈｔｏｔａｌｋｏｖｅｒＣｅｌｌｕｌａｒ：プッシュ・ツー・トーク・オーバー・セルラー」）タイプの通信セッションを設定するために、通信クライアントによって１つまたは複数の他の通信クライアントを招待することに関する。

「プッシュ・ツー・トーク」（ＰＴＴ：ＰｕｓｈｔｏＴａｌｋ）サービスは、当事者が、同時にではないがインタラクティブに通信することを可能にする「半二重」タイプの通信サービスである。各クライアント用のコマンド（ボタン、キーなど）を使用して、クライアントを受信モードから送信モードに、またその逆に切り換える。

このサービスは、セルラー通信網向けに適応されており、したがって、頭字語ＰｏＣ（「ＰｕｓｈｔｏｔａｌｋｏｖｅｒＣｅｌｌｕｌａｒ」）が付けられている。

こうしたサービスは現在、ＯＭＡ（ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ：オープン・モバイル・アライアンス）によって推進されている。それは、たとえば、文献「ＰｕｓｈｔｏｔａｌｋｏｖｅｒＣｅｌｌｕｌａｒ（ＰｏＣ）−Ａｒｃｈｉｔｅｃｔｕｒｅ」（ＯＭＡ−ＡＤ＿ＰｏＣ−Ｖ１＿０−２００６０６０９−Ａ）および「ＯＭＡＰｏＣＣｏｎｔｒｏｌＰｌａｎｅ」（ＯＭＡ−ＴＳ−ＰｏＣ−ＣｏｎｔｒｏｌＰｌａｎｅ−Ｖ１＿０−２００６０６０９−Ａ）に記載され、明記されている。これらの２つの文献は、２００６年６月９日に発行されている。

これらの標準化仕様によれば、「ＰｏＣ」タイプの通信セッションを開始したいクライアントは、ＰｏＣ通信サーバに招待メッセージを送信する。

この招待メッセージは、ＳＩＰ「ＩＮＶＩＴＥ」要求である。このタイプの要求は主に、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ：インターネット・エンジニアリング・タスク・フォース）のＲＦＣ３２６１、表題「ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ」に明記されている。

招待メッセージは、招待を送信するクライアント、ならびに受信側クライアント（換言すると、送信者が「ＰｏＣ」通信セッションに招待したいクライアント）の、ＵＲＩ（「ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ：ユニフォーム・リソース識別子」）として知られている論理アドレスを含む。

ＰｏＣ通信サーバの役割のうちの１つは、送信側（すなわち発呼側）クライアントから受信された招待を、招待メッセージ内に含まれたアドレスを使用して、招待される（すなわち被呼側）クライアントに送信することである。

招待されるクライアントは通常、移動通信端末、具体的にはセルラー端末である。それは、招待に関する情報を表示することができる表示リソース、通常、画面を有する。この情報に基づいて、通信クライアントのユーザは、招待を受けるかどうか決定することができる。

ＯＭＡの仕様は、招待メッセージによって運ばれる情報をほとんど指定していない。ＳＩＰプロトコルは、１組のヘッダを指定する。これらのヘッダは、発呼側クライアントの論理アドレス（ＵＲＩ）を送信するために使用される。したがって、招待された通信クライアントは、その画面上にこの論理アドレスを表示することができる。この論理アドレスに対応するユーザが被呼側ユーザに知られている場合、それは、ディレクトリの一部を形成することができ、このディレクトリに含まれる情報が、論理アドレスに加えて、またはその代わりに表示され得る。

こうした可能性については、たとえば、米国特許出願公開第２００５／０２８７９９７号の特許要求に記載されている。ＯＭＡ標準化研究外では、これは、ユーザに追加の情報を表示するために、発呼者（「発呼者ＩＤ」）に関する情報がシグナリング・メッセージ内に挿入され、被呼側通信クライアントによってアドレス帳に関連付けられる解決策について記載している。

しかし、この最先端技術は、あまり満足のいくものではない。

第１のケースでは、論理アドレスは、ユーザが通信セッションへの招待を受けるかどうか適切な決定を行うのに十分でないことがある。実際、論理アドレスは、必ずしもあまり読みやすいものではない（それは、必ずしも発呼側クライアント・ユーザの名前に対応していない）。

クライアントによってメモリ内にローカルに格納された情報に論理アドレスが関連付けられる第２の状況に関して、これは、招待メッセージが既知の通信者から来ている場合にだけ実施することができる。それは、新しい通信者の場合には当てはまらず、またこの場合、被呼側ユーザが決定を行うのに役立つ情報を提供しない。

ＰｏＣアプリケーション内で追加の情報を送信することを可能にする解決策も開発されてきた。これらは、たとえば、「ＰｏＣ」セッション中に画像を通信する手段を提示する諸特許要求、米国特許出願公開第２００６／００４６７５５号、米国特許出願公開第２００６／０１２１９２７号および米国特許出願公開第２００６／００４０６８６号に記載されている。

しかし、これらの開発は、被呼側クライアントが通信セッションへの招待を受けるどうか決定できるようにする追加の情報の送信を可能にしていない。

実際、たとえば米国特許出願公開第２００６／００４０６８６号の要求では、通信セッションは依然として最先端技術に従って設定され、被呼側クライアントがサーバからの画像を受信することができるのは、このセッションが設定されたとき、また被呼側クライアントが呼を受け付けたときにすぎない。したがって、この画像は、着呼を受け付けるかどうか決定するために使用することができない。

このため、最先端技術を改良し、また被呼側クライアントが「ＰｏＣ」（「プッシュ・ツー・トーク・オーバー・セルラー」）タイプの通信セッションへの招待を受けるかどうか決定するのに必要な使用可能な情報を有することを可能にすることが求められている。

米国特許出願公開第２００５／０２８７９９７号米国特許出願公開第２００６／００４６７５５号米国特許出願公開第２００６／０１２１９２７号米国特許出願公開第２００６／００４０６８６号

「ＰｕｓｈｔｏｔａｌｋｏｖｅｒＣｅｌｌｕｌａｒ（ＰｏＣ）−Ａｒｃｈｉｔｅｃｔｕｒｅ」（ＯＭＡ−ＡＤ＿ＰｏＣ−Ｖ１＿０−２００６０６０９−Ａ）「ＯＭＡＰｏＣＣｏｎｔｒｏｌＰｌａｎｅ」（ＯＭＡ−ＴＳ−ＰｏＣ−ＣｏｎｔｒｏｌＰｌａｎｅ−Ｖ１＿０−２００６０６０９−Ａ）ＲＦＣ３２６１、「ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ」ＲＦＣ２４２５、「ＡＭＩＭＥＣｏｎｔｅｎｔ−ＴｙｐｅｆｏｒＤｉｒｅｃｔｏｒｙＩｎｆｏｒｍａｔｉｏｎ」ＲＦＣ２４２６、「ｖＣａｒｄＭＩＭＥＤｉｒｅｃｔｏｒｙＰｒｏｆｉｌｅ」

本発明の第１の目的は、
− ダウンストリーム通信チャネル上でデータが受信されたことを表す警告音を生成する音声生成回路と、アップストリーム通信チャネル上で送信されるように意図されたデータを生成するための音声取得回路と、
− シグナリング・チャネル上でシグナリング・メッセージを送信するのに適したシグナリング・インターフェースであって、これらのシグナリング・メッセージの一部が、１つまたは複数の他の通信クライアントとの通信セッションを設定するように意図される、シグナリング・インターフェースと、
− このシグナリング・インターフェースを制御する手段と、「プッシュ・ツー・トーク」タイプ通信セッションが設定されると、マイクロホンがアクティブである送信モードとマイクロホンがアクティブでない受信モードとの間で切り換える手段とを含むマンマシン・インターフェースと、
− 受信されたシグナリング・メッセージの一部に含まれたデータに基づいて情報を表示するように意図された表示手段とを有する通信クライアントである。

本発明による通信クライアントは、
− それが、通信クライアントのユーザに関連しており、１つまたは複数のシグナリング・メッセージによって他の通信クライアントに送信されるように意図された名刺を格納するように意図されたメモリをも有し、また
− 表示手段が、受信されたシグナリング・メッセージ内に含まれた名刺を完全にまたは部分的に表示するのに適しているという点で革新的である。

本発明の一実施形態によれば、シグナリング・インターフェースは、ＳＩＰプロトコルに準拠し、１つまたは複数の他の通信クライアントとの通信セッションを設定するように意図された「ＩＮＶＩＴＥ」シグナリング・メッセージ内で名刺を送信するように意図され得る。

名刺は、「ＩＮＶＩＴＥ」シグナリング・メッセージのＳＤＰ部分に挿入してもよい。

本発明の一実装形態によれば、名刺は、「ｖＣａｒｄ」フォーマットに準拠してもよい。

オプションとして、名刺を格納するように意図されたメモリは、それぞれがユーザおよびユーザ・プロファイルに関連している名刺のセットを格納するように意図されることもでき、通信クライアントは、シグナリング・メッセージ内でそれを送信する前にこのセットのうちから名刺を決定する手段を有する。

本発明の第２の目的は、発呼側通信クライアントと１つまたは複数の被呼側通信クライアントの間で「プッシュ・ツー・トーク」タイプ通信セッションを設定するように意図された招待シグナリング・メッセージを含む移動通信網用のシグナリング・プロトコルである。このシグナリング・メッセージは、発呼側通信クライアントの論理アドレスと、被呼側通信クライアントのアドレスとを含む。

本発明によれば、シグナリング・プロトコルは、招待シグナリング・メッセージが、発呼側通信クライアントのユーザに関連する名刺をも含むという点で革新的である。

本発明の一実施形態によれば、招待シグナリング・メッセージは、発呼側通信クライアントによって、それが含むアドレスに基づいて、被呼側通信クライアントにそれを送信するように意図された通信サーバに送信される。

本発明の一実装形態によれば、シグナリング・メッセージは、ＳＩＰ標準化に準拠したマルチパート「ＩＮＶＩＴＥ」メッセージとすることができ、このメッセージ内で、名刺は、ＳＤＰプロトコルに準拠した部分に含まれている。

オプションとして、この名刺は、ｖＣａｒｄフォーマットに準拠してもよい。

本発明は、本発明に従って通信プロトコルを実装するように意図されたコードを含むソフトウェア製品をも目的とする。こうしたコードは、必要であれば、通信クライアント上のアプリケーション・サーバからダウンロードしてもよい。

本発明およびその特徴は、実装形態についての以下の説明においてより明らかになる。

本発明を実装するために使用される通信ネットワークを示す図である。本発明によるシグナリング・メッセージを示す図である。

図１の例では、通信クライアントＡは、移動通信網Ｎと通信することができる。この移動通信網は通常、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡなどのタイプのセルラー網である。それは、移動サブネットワークと固定サブネットワークとを含んでおり、固定と移動の両方の通信クライアントが通信することを可能にする収束型ネットワークであってもよい。こうしたネットワークは、３ＧＰＰおよびＴＩＳＰＡＮによって標準化されたＩＭＳ（ＩｎｔｅｒｎｅｔＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ：インターネット・マルチメディア・サブシステム）アーキテクチュアに準拠してもよい。

この通信ネットワークＮを介して、通信クライアントＮは、１つまたは複数の通信クライアントＢ、Ｃと通信することができる。

それ自体知られているやり方で、通信端末は、通信クライアントのユーザから来るデータ（音声、ビデオなど）を通信ネットワークＮに送信することを可能にするアップストリーム・チャネル、ネットワークから（また一般に別の通信クライアントから間接的に）データを受信することを可能にするダウンストリーム・チャネル、および通信クライアントとネットワークＮとの間のシグナリング・メッセージの双方向伝送を可能にするシグナリング・チャネルを介して、通信ネットワークに接続されてもよい。

通信クライアントは通常、「音声」タイプの通信セッションの設定を可能にする音声生成回路と取得回路とを有する通信端末である。それは、マルチメディア通信セッション（ビデオなど）の設定を可能にする、画面、カメラなどのより高度なリソースを有することもできる。

音声生成回路は通常、ダウンストリーム通信チャネル上でデータが受信されたことを表す警告音を生成するために使用されるラウドスピーカまたはヘッドセットである。

音声取得回路は通常、アップストリーム通信チャネルを介して次いで通信網に送信されるデータを生成するように意図されたマイクロホンである。

通信クライアントＡ、Ｂ、Ｃは、通信ネットワークＮにそれらを接続するシグナリング・チャネル上でシグナリング・メッセージを送受信するためのシグナリング・インターフェースをも有する。

これらのシグナリング・インターフェースは、ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）のＲＦＣ３２６１に定義されたＳＩＰプロトコル、および必要であれば、ＩＥＴＦまたは標準化機関によって後に定義されたこのＳＩＰプロトコルの拡張物に準拠してもよい。

「ＰｏＣ」（「プッシュ・ツー・トーク・オーバー・セルラー」）タイプの通信セッションを設定するために、通信クライアントＡは、通信ネットワークＮに招待シグナリング・メッセージＭＩを送信する。

通信クライアントＡは、シグナリング・インターフェースを制御し、この招待シグナリング・メッセージＭＩの送信をトリガする手段を含むマンマシン・インターフェースを有する。このマンマシン・インターフェースは一般に、１組のキー、必要であればタッチ・スクリーンに加えて、ユーザによる通信クライアントへのコマンドおよび制御を可能にするスクロール・ホイールなどからなる。したがって、このマンマシン・インターフェースを使用して、ユーザは、「ＰｏＣ」タイプ通信セッションの開始をトリガしてもよい。

この同じマンマシン・インターフェースは、「プッシュ・ツー・トーク」通信セッションが設定されると受信モードと送信モードの間で切り換えるために使用される手段（キー、スクロール・ホイールなど）をも有する。受信モードでは、音声取得回路はアクティブでない。送信モードでは、音声生成回路は通常、アクティブでない。

招待シグナリング・メッセージＭＩは、通信ネットワーク内の通信サーバＳＣに送信されてもよい。この通信サーバは、招待シグナリング・メッセージＭＩの内容を理解することができ、この内容に基づいて、被呼側通信クライアントＢおよびＣにそれを送信する。

図２は、ＳＩＰプロトコル、および「ＰｏＣ」サービス用のＯＭＡの標準化仕様に準拠したこうした招待シグナリング・メッセージを図に示している。

次いで、この招待シグナリング・メッセージＭＩは、ＩＥＴＦのＲＦＣ３２６１によって定義された「ＩＮＶＩＴＥ」メッセージである。

それは、１組のＳＩＰヘッダによって形成された第１の部分のＥ_ＳＩＰを含む。これらのヘッダは、通信クライアントＡのユーザの少なくとも論理アドレスを含む。それらは、招待メッセージを通信サーバＳＣにルーティングすることを可能にする情報をも含む。

「ＩＮＶＩＴＥ」シグナリング・メッセージは、設定される通信セッションについて記述しており、それぞれ異なる部分によってこれらのパラメータを交渉することを可能にする情報を含む部分Ｐ１を含む。これらのパラメータは、たとえば、実装されるメディア・フローの符号化などに関し得る。

この部分は、それ自体周知のやり方で、ＳＤＰプロトコル（「セッション記述プロトコル」）に準拠する。

ＭＩシグナリング・メッセージは、上記の規格文献に指定されており、またＯＭＡから解釈されるように、ＳＤＰプロトコルにやはり準拠した部分Ｐ２をも含む。この部分Ｐ２は、招待された通信クライアントの論理アドレスを含む。

以下のコードは、ＳＩＰプロトコルおよびＯＭＡ仕様に準拠した招待シグナリング・メッセージの説明的な例である。第１の抜粋は、この招待メッセージのＥ_ＳＩＰヘッダを表している。太字の単語は、ＳＩＰプロトコル文法の主要な単語を表しており、読みやすさのためだけに書式設定されている。

招待メッセージＭＩがＳＤＰプロトコルに準拠した複数の部分（Ｐ１、Ｐ２、ならびに後述のＰ３）を含む「マルチパート」メッセージであることを意味するヘッダ「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ」に留意されたい。

ＳＤＰプロトコルに準拠した部分Ｐ１は、以下の形をとり得る。

やはりＳＤＰプロトコルに準拠した部分Ｐ２は、以下の形をとり得る。

上記に述べられたように、この部分Ｐ２は、被呼側通信クライアントＢ、Ｃのアドレス（「ｓｉｐ：ＰｏＣ−ＵｓｅｒＢ＠ｎｅｔｗｏｒｋＢ．ｃｏｍ」および「ｓｉｐ：ＰｏＣ−ＵｓｅｒＣ＠ｎｅｔｗｏｒｋＣ．ｃｏｍ」）を含む。

通信サーバＳＣは、このメッセージ内に含まれたアドレス（「ｓｉｐ：ＰｏＣ−ＵｓｅｒＢ＠ｎｅｔｗｏｒｋＢ．ｃｏｍ」および「ｓｉｐ：ＰｏＣ−ＵｓｅｒＣ＠ｎｅｔｗｏｒｋＣ．ｃｏｍ」）に基づいて、通信クライアントＢおよびＣにこの招待シグナリング・メッセージＭＩを送信するように意図される。したがって、図１の例では、メッセージＭＩは、通信クライアントＢに送信されるＭＩ_Ｂメッセージ、および通信クライアントＣに送信されるＭＩ_Ｃメッセージ内に複製される。

さらに、本発明によれば、部分Ｐ３もまた、呼出し側通信クライアントＡによって送信される招待シグナリング・メッセージＭＩに挿入される。

この部分Ｐ３は、ユーザの名刺を含む。それは、通信クライアント内のこの目的に意図されたメモリ内に予め格納してもよい。次いで、通信クライアントは、格納されたこの名刺を、送信される招待シグナリング・メッセージ内に自動的に挿入するように意図されてもよい。必要であれば、ユーザからの確認を要求してもよく、あるいは、自動的な挿入は、この通信クライアントのための構成オプションの対象であり得る。

単一の通信クライアントが複数の異なるユーザによって使用される可能性が高い場合、メモリは、複数の名刺を格納してもよい。こうした場合では、送信される名刺は、ユーザが通信クライアントに接続する（「ログインする」）にときに自動的に決定されてもよい。

必要であれば、単一のユーザについて複数の名刺が、それぞれ異なるプロファイル、たとえば仕事用の名刺、個人用の名刺などに対応して立案され格納されてもよい。

すべての場合において、通信クライアントは、シグナリング・メッセージＭＩで送信する前に、格納されたすべての名刺のうちから名刺を決定する手段を有する。

この名刺は、ｖＣａｒｄフォーマットに準拠してもよい。このｖＣａｒｄフォーマットは、電子メールで広く使用されているという利点を有し、したがって、招待メッセージと電子メール、ならびにアプリケーションと、それを使用するサービスの間の相互運用性を可能にする。

このｖＣａｒｄ（「Ｖｅｒｓｉｔｃａｒｄ」）フォーマットは、それぞれ「ＡＭＩＭＥＣｏｎｔｅｎｔ−ＴｙｐｅｆｏｒＤｉｒｅｃｔｏｒｙＩｎｆｏｒｍａｔｉｏｎ」および「ｖＣａｒｄＭＩＭＥＤｉｒｅｃｔｏｒｙＰｒｏｆｉｌｅ」という表題のＩＥＴＦのＲＦＣ２４２５および２４２６によってバージョン３．０で標準化されている。

もちろん、本発明の文脈の範囲内にある他の名刺仕様が可能である。

名刺は、通信クライアントのユーザに関する異なる情報、すなわちユーザの名前または名字、電子アドレス、住所、電話番号、役職および／または職務などを含んでもよい。

ＳＤＰプロトコルによれば、名刺を含むこの部分Ｐ３は、以下のとおりであり得る。

シグナリング・メッセージＭＩに含まれたこの部分Ｐ３は、通信サーバＳＣによってそれぞれ通信クライアントＢおよびＣに送信されるシグナリング・メッセージＭＩ_ＢおよびＭＩ_Ｃ内に維持される。

通信サーバＢおよびＣは、表示手段、具体的には画面を有する。次いで、名刺に含まれる情報は、部分的にまたは完全に画面上に表示することができる。したがって、それは、被呼側通信クライアントのユーザに、招待を受けるべきかどうか決定するために使用される追加情報を提供する。

特定の情報は自動的に表示されてもよく（発呼者名など）、他の情報は、ユーザによる特定の動作の後にだけ表示される（アドレスなど）。この分離は、表示画面のサイズに依存することがある。

したがって、通信クライアントＢまたはＣのユーザは、通信クライアントＡのユーザを知らない場合でも、このユーザの名前、会社、アドレスなどについて通知を受けることができ、この情報は、決定を行うことを可能にするのに十分であり得る。したがって、ユーザは、特定の着呼をフィルタリングし、必要であれば、要求されていない「スパミング」招待を拒否してもよい。

さらに、ユーザは、（フォルダ、文書などを取り出すことによって）精神的および物理的に着呼に備えてもよい。

通信クライアントによって受信されたこの名刺は、この目的に意図されたメモリに任意選択で格納し、「アドレス帳」タイプ・アプリケーションによって管理してもよい。メモリ内のこの格納、およびこのアプリケーションによって、ユーザは、これらの連絡先を管理し、通信者を追跡し続けることができる。

本発明の一実装形態によれば、名刺は、招待シグナリング・メッセージ以外のシグナリング・メッセージによって送信することもできる。

たとえば、シグナリング・メッセージは、被呼側通信クライアントＢによって、発呼側通信クライアントＡおよび／または他の被呼側通信クライアントＣに送信することができる。通信クライアントＢのユーザの名刺を含むこれらのシグナリング・メッセージによって、通信クライアントＡおよびＣは、この個人情報を見つけ出し、必要であれば、連絡先のうちからこの名刺を格納することができる。

Claims

− ダウンストリーム通信チャネル上でデータが受信されたことを表す警告音を生成する音声生成回路と、アップストリーム通信チャネル上で送信されるように意図されたデータを生成するための音声取得回路と、
− シグナリング・チャネル上でシグナリング・メッセージ（ＭＩ）を送信するのに適したシグナリング・インターフェースであって、招待メッセージである前記シグナリング・メッセージの一部が、１つまたは複数の他の通信クライアント（Ｂ、Ｃ）との通信セッションを設定するように意図される、シグナリング・インターフェースと、
− 前記シグナリング・インターフェースを制御する手段と、「プッシュ・ツー・トーク」タイプ通信セッションが設定されると、前記マイクロホンがアクティブである送信モードと前記マイクロホンがアクティブでない受信モードとの間で切り換えるために使用される手段とを含むマンマシン・インターフェースと、
− 受信された前記シグナリング・メッセージの一部に含まれたデータに基づいて情報を表示するように意図された表示手段とを有する通信クライアント（Ａ）であって、
それが、前記通信クライアントのユーザに関連しており、１つまたは複数の招待メッセージによって前記他の通信クライアントに送信されるように意図された名刺を格納するように意図されたメモリをも有し、また前記表示手段が、受信された前記シグナリング・メッセージ内に含まれた名刺を完全にまたは部分的に表示するのに適していることを特徴とする通信クライアント（Ａ）。
前記シグナリング・インターフェースが、ＳＩＰプロトコルに準拠し、１つまたは複数の他の通信クライアントとの前記通信セッションを設定するように意図された「ＩＮＶＩＴＥ」シグナリング・メッセージ内で前記名刺を送信するように意図される、請求項１に記載の通信クライアント。
前記名刺が前記「ＩＮＶＩＴＥ」シグナリング・メッセージのＳＤＰ部分に挿入される、請求項１または２に記載の通信クライアント。
前記名刺が「ｖＣａｒｄ」フォーマットに準拠する、請求項１乃至３のいずれか１項に記載の通信クライアント。
名刺を格納するように意図された前記メモリが、それぞれがユーザおよびユーザ・プロファイルに関連付けられている名刺のセットを格納するようにも意図され、さらに、シグナリング・メッセージ（ＭＩ）で送信する前に前記セットのうちから名刺を決定する手段を有する、請求項１乃至４のいずれか１項に記載の通信クライアント。
発呼側通信クライアント（Ａ）と１つまたは複数の被呼側通信クライアント（Ｂ、Ｃ）との間で「プッシュ・ツー・トーク」タイプ通信セッションを設定するように意図されており、前記発呼側通信クライアントの論理アドレスと、前記被呼側通信クライアントのアドレスとを含む招待シグナリング・メッセージ（ＭＩ）を含む移動通信網（Ｎ）用のシグナリング・プロトコルであって、前記招待シグナリング・メッセージ（ＭＩ）が、前記発呼側通信クライアント（Ａ）のユーザに関連する名刺をも含むことを特徴とするシグナリング・プロトコル。
前記招待シグナリング・メッセージ（ＭＩ）が、前記発呼側通信クライアント（Ａ）によって、前記アドレスに基づいて、前記被呼側通信クライアント（Ｂ、Ｃ）にそれを送信するように意図された通信サーバ（ＳＣ）に送信される、請求項６に記載のシグナリング・プロトコル。
前記シグナリング・メッセージが、ＳＩＰ標準化に準拠したマルチパート「ＩＮＶＩＴＥ」メッセージであり、前記名刺が、前記ＳＤＰプロトコルに準拠した部分に含まれる、請求項６または７に記載のシグナリング・プロトコル。
前記名刺がｖＣａｒｄフォーマットに準拠する、請求項６乃至８のいずれか１項に記載のシグナリング・プロトコル。
請求項６乃至９のいずれか１項に記載の通信プロトコルを実装するように意図されたコードを含むソフトウェア製品。
発呼側通信クライアント（Ａ）と１つまたは複数の被呼側通信クライアント（Ｂ、Ｃ）との間で通信セッションを設定するように意図されており、前記発呼側通信クライアントの論理アドレスと前記被呼側通信クライアントのアドレスとを含む招待シグナリング・メッセージ（ＭＩ）を含む移動通信網（Ｎ）用のシグナリング・プロトコルであって、前記招待シグナリング・メッセージ（ＭＩ）が、前記発呼側通信クライアント（Ａ）のユーザに関連する名刺をも含むことを特徴とするシグナリング・プロトコル。
前記名刺がｖＣａｒｄフォーマットに準拠する、請求項１１に記載のシグナリング・プロトコル。
前記招待シグナリング・メッセージが、ＳＩＰ標準化に準拠した「ＩＮＶＩＴＥ」メッセージである、請求項１２に記載のシグナリング・プロトコル。
前記名刺が、前記招待シグナリング・メッセージのＳＤＰプロトコルに準拠した部分に含まれる、請求項１３に記載のシグナリング・プロトコル。
請求項１乃至５のいずれか１項に記載の通信クライアントを実装する通信ネットワーク。