JP6762489B2 - 発呼元についての付加情報 - Google Patents

Description

分野

本発明は、第一者から１以上の第二者への接続確立の開始に関するものであり、とくに１以上の第二者のうちの少なくとも１つへ第一者の情報を配信することに関する。

一般に、ユーザが他のユーザとの接続を介して通信すること、例えば、会話の伝達が可能な電話機または同様のユーザ装置は、ユーザが接続確立を受諾するか否かを決める前に、通常、発呼者と称される接続確立開始者の情報をそのユーザに提供するように構成されている。概して、この情報は、呼出信号の最中に、すなわち接続設定中であるがユーザが接続確立を受諾する前に、表示器を介してユーザに表示される。示される情報の最も単純なものは、発呼元の識別情報であり、発呼者番号か、または発呼者番号を用いてユーザ装置のメモリ内の電話帳もしくはネットワークのデータベースの何れかから索出された名前の何れかである。スマートフォンおよび同様の装置の躍進によって種々のアプリケーションの量が増加し、それらには、発呼者のより多くの情報を表示し得るアプリケーション（アプリ）も含まれている。例えば、オペレーティングシステムとしてAndroidを有する装置では、ユーザが発呼者に接続されると、名前および番号ならびに写真に加えて、フェイスブックおよびツイッタのプロファイルのようなソーシャルプロファイルへのリンクと、場合によっては発呼者の地域およびその地域の天気についての情報も出力するアプリケーションのダウンロードが利用可能である。公衆が利用可能な番号情報が利用可能であれば、ユーザが発呼者に接続されないときでも、それを用いて名前情報が索出される。したがって、アプリケーションでも、予め記憶された所定のデータを用いれば、発呼者番号情報に基づいて発呼者に関する情報を提供する。さらに、このような付加情報は、ユーザと発呼者同士の接続履歴があって両者がプロファイルアカウントを有していることも必要である。

概要

本発明の概括的な態様は、第一者についてのあるリアルタイムまたは準リアルタイム情報を、第一者が接続を確立しようとする１以上の第二者へ、そのリアルタイムまたは準リアルタイム情報を含むリソースへの参照情報を用いて配信することであり、参照情報は、発呼者によって、または接続の確立以前にリアルタイムまたは準リアルタイム情報を１以上の第二者へ送ることによって、与えられる。

本発明は、独立請求項に記載された事項を特徴とする方法、装置、コンピュータプログラム製品およびシステムとして定義される。本発明の好ましい実施例は、従属請求項に開示される。

以下、添付図面を参照して種々の実施例をより詳細に説明する。
は、システムの簡易化した構造および代表的な装置の概略図である。 および は、ネットワーク装置機能の例を示すフローチャートである。 ないし は様々な例によるシグナリングを示す図である。 は代表的な装置のブロック図である。

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

以下の実施例は代表的なものである。本明細書では、数箇所において「ある」実施例、「１つの」実施例、または「いくつかの」実施例を参照するが、これは必ずしも、それぞれのそのような参照が同じ実施例に関すること、またはその特徴事項が単一の実施例にだけ適用されることを意味するものではない。また、様々な実施例の個々の特徴事項を組み合わせて他の実施例を提供してよい。

本発明の実施例は、通信システムに用いられて発呼者側ユーザに対する情報表示をサポートするように構成された何れの装置にも適用可能である。本通信システムは、無線通信システム、または１以上の固定ネットワークおよび１以上の無線ネットワークの両方を利用する通信システムでよい。通信、とくに無線通信では、使用されるプロトコルおよび仕様が急速に発達する。そのような発達によれば、実施例の更なる変更が必要となることがある。したがって、すべての用語および表現は、広く解釈すべきであり、そのような実施例を限定することなく説明することを意図するものである。

代表的な実施例によるシステム100の概括的な構造を図１に示す。図１は、いくつかの要素および機能エンティティのみを示す非常に簡略化したシステム構造であり、それらすべてが論理的単位であり、その実現形態は示されるものと異なってよい。図１に示す接続は、論理的接続の例であり、実際の物理的接続は異なってよい。当業者にとって、本システムが他の機能、構成および装置も有することは明らかである。接続を確立してその接続を介して様々なメディアフォーマットを送信することに用いられ、またはその目的で用いられる機能、構成、要素およびプロトコル、ならびにその接続に必要な実際のチャネルの量は、実際の発明とは無関係であることを理解すべきである。したがって、それらは、ここで詳細に説明する必要がない。

図１に例示される代表的なシステム100は１以上のユーザ装置110、110'（図１では２つのみ示されている）を有し、各ユーザ装置は、１以上のサーバ装置140を有するコアネットワーク130（またはサーバシステム140）に対してアクセスネットワーク120、120'を介して接続され、サーバ装置（またはサーバシステム）は発呼元情報のリソースを含んでいる。

アクセスネットワーク120、120'の１以上、およびコアネットワーク130は、モバイルネットワーク、公衆電話交換網、ワイドエリアネットワークWAN、インターネット、すべてのユーザに対して、もしくはアクセス制限付きで開放されたローカルエリアネットワークLAN（例えば、企業内LANまたは社内LAN）、Wi-Fiのような無線LAN、プライベートネットワーク、専有ネットワーク、またはそれらの組合せでよい。

図１では、ユーザ装置110、110'のいくつかのユニットのみが例示されている。ユーザ装置110、110'は、通信のエンドポイントとして作用可能であって１以上のネットワークを通る通信をサポートするどのような種類の演算装置でもよく、ユーザ端末またはユーザ機器またはユーザデバイスと称される。そのようなユーザ装置の例には、ハードウェアまたはソフトウェアとして加入者識別モジュール（SIM）を有し、または有さないで動作する携帯型無線移動通信装置があり、以下のタイプの装置があるが、それらに限定されない。すなわち、携帯電話、スマートフォン、パーソナルデジタルアシスタント（PDA）、ハンドセット、ラップトップコンピュータ、電子書籍閲覧装置、タブレット、サービス専用の携帯装置である。更に、どのような種類のオペレーティングシステムを使用してよいことを理解すべきである。そのようなオペレーティングシステムの例には、Android、iOS、WindowsおよびOSXがある。また、オペレーションシステム独立言語を含む何れのプログラミング言語に基づく何れのアプリケーションも、例えばアプリケーションベースのJava、HTML（ハイパーテキストマークアップ言語）、HTML5、ActionSript（「フラッシュ」）およびQT（クロスプラットフォーム・アプリケーションフレームワーク）でサポートされるものでよい。図示した例では、ユーザ装置110、110'は発呼者情報ユニット112、112'を有し、これらは、以下で「リアルタイム発呼元情報」または単に「発呼元情報」と称されるユーザについてのリアルタイムまたは準リアルタイム情報を配信し、発呼者についてのリアルタイム発呼元情報を出力するものである。プル方式の原理を用いる場合、発呼者情報ユニット112、112'は、発呼元情報を含むリソースへの参照情報を配信し、参照情報を伴う接続確立をユーザが開始すると、発呼元情報をリソースへ配信する制御を行ない、参照情報を伴う接続確立の要求を受信すると、ユーザに表示すべき発呼者についての発呼元情報を取得／索出する。これについては以下に詳細に説明する。プッシュ方式の原理を用いる場合、発呼者情報ユニット112、112'は、接続確立要求と共にか、または接続確立要求の実質的に直後の何れかで、ユニフォーム発呼元情報UCIと称することのある発呼元情報を配信し、UCIが接続確立要求と共に送信されない場合には、UCIを伴う接続確立がユーザによって開始されると、発呼元情報を被呼者へ配信する制御を行ない、UCIを伴う、またはUCIが後続する接続確立要求を受信すると、ユーザに表示すべき発呼者についての発呼元情報を取得／索出する。これについては以下に詳細に説明する。UCIには、１つのUCIとして発呼元情報が含まれることがあるが、UCIは、再使用不可のリアルタイム情報として、再使用される発呼元情報とは同じにできないことを理解すべきである。発呼者情報ユニット112、112'は、プル方式の原理のみを実現するように構成してもよい。また、ユーザ装置110、110'は、様々なメディアタイプを送信および受信する１以上のアンテナなどの１以上の様々な通信用インタフェースユニット111、111'と、１以上のスクリーン（リモートまたは一体型）、１以上のスピーカ（リモートまたは一体型）、１以上のカメラ（リモートまたは一体型）、タッチスクリーン、スイッチ、キーボード、バーチャルキーボード、マウス、ジョイスティック、セレクタローラ、チョイスホイーラ、セレクタスイッチ、ドローイングパッド、タッチパッドなどの１以上の様々なユーザインタフェースユニットも有している。しかし、それらは、ここでは詳細に例示しない。また、ユーザ装置110、110'は、例えば、連絡先情報を記憶するのに用い得る１以上のメモリ113、113'も有している。また、メモリは、発呼者ユニットの実現例の詳細に応じて、発呼者情報ユニット用の連絡先情報に対応付けられた設定情報および／またはルールおよび／またはプロファイルおよび／または付加情報も有している。例えば、付加情報は、リストにない番号を有するか、もしくはプリペイドアカウントを有するユーザの名前でよく、または付加情報は、「私はテレマーケティング会社xyzの社員です。あなたに雑誌xxxの非常に魅力的な提案をしたくて電話しました」などの発呼した団体および／もしくは理由を記述したテキスト、または地域、気温、風速、気圧、心電図、呼気中アルコール量などの測定データでもよい。設定情報、ルール、プロファイル（プロファイルは１組の設定情報）の様々な例、および付加情報の更なる例を以下に説明するが、それらの例に限られるものではない。

図１では、１つのサーバ装置140のいくつかのユニットのみが例示されている。サーバ装置140は、適切なアクセス権を有するユーザ装置またはすべてのユーザ装置によってアクセスされ得るどのような種類の演算装置でもよく、予め記憶された発呼元情報、ならびに／またはリアルタイムおよび／もしくは準リアルタイム発呼元情報の配信を助けることができ、サーバまたはサーバシステムと称することがある。換言すれば、サーバ装置140は、１以上のクライアントと共有する専用のリソースを実行するようにプログラム可能な、またはさもなければ構成可能な汎用装置（デバイス）でよく、クライアントは、他の装置のリモートクライアントまたはサーバ装置の内部クライアントの何れかである。例えば、サーバ装置140は、発呼者の識別情報を確認するためのウェブサーバまたはメディアサーバまたは認証サーバまたは信頼された第三者サーバのような、コンピュータまたは他の演算要素でよい。図示した例では、サーバ装置140は１以上のインタフェース141、少なくとも１つの記憶ユニット142、および少なくとも１つのメモリ143を有し、以前に使用された発呼元情報および／もしくはリアルタイムもしくは準リアルタイム発呼元情報を一時的に記憶し、ならびに／またはサーバによって提供されるサービスに対する付加情報を記憶する。そのような付加情報の例には、ユーザを確認するのに必要な確認情報、またはユーザを認証するのに必要な認証情報がある。例えば、サーバは、受信した写真に基づいて顔認識を実行し、写真と共に名前、性別および／または年齢のような識別情報をリソースに記憶し、これによって発呼者の最終的な確認または認識のための情報を提供するように構成してよい。サーバ装置の配置場所は発明にとって重要でないことを理解すべきである。サーバ装置は、例えばアクセスネットワークに配置してよい。サーバ装置は、発呼元情報の仲介として使用する場合、ユーザ装置によってアクセス可能であれば十分である。ある実現例では、本システムは、一種の集中型システム、すなわち発呼元情報が常にサーバシステム（当該目的専用のシステムでよい）を介して配信されるシステムである。集中型システムに基づく実現例では、各ユーザ装置、またはより正確には各クライアントは、他のユーザ装置ではなく集中型サーバへの接続を確立し、サーバは、この接続をマッピングしてエンドユーザがその接続をエンドツーエンドのユーザ装置接続として記憶するようにする。他の実現例では、本システムは分散型システムであり、発呼元情報を配信する際に経由するサーバは自由に選択してよく、発呼元情報用のサーバとして発呼者側ユーザ装置を使用するオプションが含まれている。しかし、サーバ装置が発呼元情報の配信に関係しない実現例もある。

以前に記憶した発呼元情報は、前もって取り込まれ呼確立で一度使用される情報である。以前に記憶した発呼元情報を確実に一度だけ使用する何らかの手段を用いてもよい。以前に記憶した発呼元情報は、例えば、取得／索出したときに削除し、または使用済みとしてマーク／フラグを付してもよい。以前に記憶した発呼元情報には、ある存続期間を設けてもよく、存続期間が満了すれば、その情報は使用できなくなる。以前に記憶した発呼元情報は、ユーザの写真、ならびに／またはテキストメッセージおよび／もしくはボイスメッセージでよい。これらは単なる例であり、どのような種類の情報を使用してもよいことは、理解すべきである。

リアルタイム情報または準リアルタイム情報は、本来、ワンタイム情報である。リアルタイム情報または準リアルタイム情報は、発呼者側ユーザ装置からのイメージストリーム、ビデオストリームおよび／またはオーディオストリーム、ならびに／または発呼者側ユーザ装置と一体型の、もしくはそうでなければこれに接続された測定ユニット／デバイス／センサによって測定された識別／個人データ、ならびに／または発呼者側ユーザ装置と一体型の、もしくはそうでなければこれに接続されたカメラによって取り込んだ画像でよい。測定された識別データ、すなわち発呼者の識別を可能にする情報の例には、指紋、虹彩紋、顔画像および声があり、個人情報とも呼ばれ、それによって発呼者を識別可能である。上記の列挙は網羅的な列挙ではなく、他の情報をリアルタイム情報または準リアルタイム情報として用いてもよく、ユーザの制御の下で、ユーザ装置によって、または発呼者側ユーザ装置と一体型の、またはそうでなければこれに接続された他の装置／デバイス／手段によって情報を取り込めば十分であることを理解すべきである。「ユーザの制御の下」なる表現は、ここでは、どのような情報が送信されるかをユーザが知って、（それが呼の終了に必要なことがあっても）これによってその情報を送信しないと決定できることと、接続確立のために当該情報を取り込み、それが、好ましくはその情報を使用する接続確立要求のためにではあるが、必要ではないことを意味する。リアルタイム情報または準リアルタイム情報とは、ここでは、取り込んで取込み後ある期間内に使用される情報を意味する。例えば、その期間は15分に設定してよい。その期間は、使用される情報のタイプに応じて設定してよい。例えば、その期間は、ビデオに対して15秒に、オーディオに対して25秒に、写真に対して15分に、またその他の識別測定データに対しては２分に設定してよい。他の例としては、ビデオおよびオーディオに対して20秒、その他に対して15分がある。情報を使用しなければならない期間は自由に設定してよいが、情報のリアルタイム特性を保証するためには、その期間はあまり長くすべきではない。例えば、最上限として15分が合理的な限界である。

以下では、リアルタイム情報なる用語は、準リアルタイム情報にも及ぶ。

以下では、呼を接続確立の例として用い、プル方式の原理を用いて発呼元情報を配信するときに、リソースへの参照情報の例としてURI（ユニフォームリソースアイデンティファイア）を用いる。URIは、１以上のネットワークを通して利用可能なリソースへの明確な参照情報によって理論的または物理的なリソースを識別するコンパクトな文字列である。換言すれば、URIは、発呼元情報への指示子の例として用いられる。URIに代えて、接続確立要求に使用され発呼者への応答返信目的で発呼者を指示する他の識別子を用いてもよい。更に、フラッシュクライアントやm4yクライアントなどの被呼者以外の他のシステムまたはアプリケーションを発呼者が用いる場合には、異なる指示子をブリッジして被呼者側クライアントが発呼者側の発呼元情報を得ることができるようにする必要があるかもしれない。各接続が終端し各接続をマッピングする所でもある集中型サーバを実現する場合、リソースへの参照情報は、発呼元識別情報および発呼者識別の組合せでよい。しかし、その場合でさえ、URIを使用できることを理解すべきである。また、当業者にとっては、発呼元情報をプッシュ方式の原理を用いて配信するとき、参照情報は必要ないがUCIが接続確立要求と共にか、または接続確立要求の実質的に直後に配信されることは明らかである。

図２は、接続確立要求を受信したときの被呼者ユーザ装置の代表的な機能、またはより正確には発呼者識別ユニットの代表的な機能を例示するフローチャートである。図２の例では、ユーザは、URIなしの接続確立要求を受信し発呼者が連絡先リストにない場合、ユーザに通知しない旨、そうでなければユーザに呼出音を鳴らして通知する旨を定義してある。更に、発呼元情報は、発呼元情報を表示することによってユーザへ出力されると仮定する。コンテンツ（発呼元情報）を出力する他の手法も用いてよいことを理解すべきである。例えば、テキスト情報を音声生成器によって読み出してもよい。

呼確立要求をステップ200で受信すると、図示した例では、ステップ201で呼確立要求を受諾可能か否かを判定する。例えば、設定情報または構成は、発呼ユーザ装置から同じアプリケーションの使用などの、ある機能を必要とすることがある。しかし、ステップ201の判定は、他の実現例では省略してよい。

呼確立要求が受諾可能であると（ステップ201）、この要求は、ステップ202において未確定状態を指示する対応のメッセージを発呼者へ送ることによって、未確定として確認される。呼確立要求プロトコルが周期的な「未確定指示」を必要としない場合、ステップ202は省略されることを理解すべきである。発呼者側ユーザ装置がメッセージ（指示）を受信すると、発呼者は「通知音」または「呼出音」を聴取する。しかし、呼出音は、この例では被呼者側ユーザ装置で生成されない。そこでステップ203では、呼確立要請がURIを含むか否かを判定する。含む場合、URIがステップ204においてその要求から抽出され、ステップ204においてURIによって指示されたリソースに対して接続が確立され、リソース内のコンテンツが索出される。コンテンツは、例えば、発呼者側ユーザ装置から生成される最近の写真、付加テキスト付きの最近の写真、またはビデオストリームでよい。そこで、コンテンツは、ステップ205において被呼者に表示され、呼出音がステップ205で生成される。当然、ユーザ装置がサイレントモードであれば、呼出音は出力されない。コンテンツは、ユーザ装置の表示器に、別に取り付けられた装置に、または適切なインタフェースハードウェアを有する接続されたコンピュータによって処理され、またはテレビ画面に表示することができる。

次に、タイマがステップ206で設定されて、タイマが満了するか否か（ステップ207）、呼がユーザによって拒否されたか否か（ステップ208）または呼がユーザによって婉曲に拒否されたか否か（ステップ209）、または呼がユーザによって受諾されたか否か（ステップ210）が監視される。

タイマが満了し（ステップ207）、または呼が拒否されると（ステップ208）、表示と呼出音の生成がステップ211で停止し、呼接続要求に対する否定応答がステップ212で送信される。そのため、タイマの目的は、発呼者が寛容で呼を終了させず（図２に例示の例において仮定したように）、ユーザが通知音に答えもしない場合に、通知音がこれ以上続かないようにすることである。

呼が婉曲に拒否されると（ステップ209）、表示と呼出音の生成がステップ213において停止して、ユーザ装置は、呼確立を拒否するものとみなすが、これは発呼側ユーザ装置へ通知されない。したがって、ステップ214では、発呼者が放棄するまでこの呼確立要求を未確定のものとして確認するメッセージを送信し続ける。呼確立プロトコルが周期的な「未確定指示」を必要としない場合は、ステップ214を省略することを理解すべきである。換言すれば、図示した例において、婉曲な拒否とは、呼確立が拒否されることを意味し、そのため、被呼者のユーザ装置は新規の呼確立要求を受信および送信できるが、ステップ200で受信した呼確立要求に対して否定応答を発呼側ユーザ装置へ送信することはない。そのため、発呼者は、呼確立要求が依然として未確定であるとみなす。他の例では、婉曲な拒否で直ちに表示と呼出音の生成を停止させ（すなわち、ユーザ装置を一時的にサイレントモードに設定し）てもよいことを理解すべきである。

呼が受諾されると、表示と呼出音の生成はステップ215で停止され、ステップ216で呼確立動作を続ける。呼確立要求がビデオ呼を指示した場合、呼が受諾された時点で、ユーザの選択に基づいて、その呼をオーディオ呼またはビデオ呼として確立してもよい。しかし、本発明は実際の呼確立に対する変更を必要としないので、ここではこれ以上詳細に説明しない。

呼確立要請がURIを含まない場合（ステップ203）、ステップ217において、発呼者番号がユーザの連絡先リストに存在するか否かを判定する。存在すると、連絡先リストで取得可能な情報がステップ218においてユーザ装置のユーザに対して表示され、ステップ218において呼出音が生成される。当然、ユーザ装置がサイレントモードの場合、呼出音は出力されない。そこで、処理はステップ206へ進んでタイマを設定する。

発呼者番号が連絡先リストにない場合（ステップ217）、呼出音の生成は、ステップ219で消勢され、処理はステップ214へ進んで、発呼者が呼を終了させるまでこの確立要求を未確定のものと確認するメッセージを送信し続ける。通知音の設定情報で通知音生成を自動トリガとしていない場合、または通知音に対して実行すべき何かがある場合、ステップ219は省略してよいことを理解すべきである。

他の実現例では、ステップ215において、呼出音の生成のみを停止し、コンテンツの表示はユーザが表示停止指示を入力するまで継続される。この実現例では、呼がビデオ呼である場合、コンテンツは、ビデオ呼用画面以外の画面を用いて表示してもよい。

更なる実現例では、接続確立要求にURIがなく、連絡先リストに発呼者がない場合、処理はステップ219から（またはステップ219が省略されている場合にはステップ217から）直接的にステップ212へ進み、すなわち発呼者が呼を終了させるまで待機せず、あるいはタイマを設定してそれが満了すると処理がステップ212へ進むようにしてもよい。タイマの待ち時間は、ステップ207で監視したものと同じか、または他の時間でもよい。

また他の実現例では、婉曲な拒否にタイマを使用し、発呼者が非常に寛容で呼を終了させない場合に、その満了によって処理をステップ214からステップ212へ進めて否定応答を送信する。タイマの待ち時間は、上記のタイマの１つと同じか、または他の時間でもよい。本実現例では、接続確立要求にURIがなく、連絡先リストに発呼者がない場合、ここで説明した処理の何れを用いてもよい。

更に他の実現例では、婉曲な拒否が提供されない。このような実施例では、ステップ209および213が省略され、ステップ217から、すなわちURIが要求リストになく、発呼者も連絡先リストにない場合、処理はステップ212へ進んで、呼確立要求に対する否定応答を送信する。

発呼者番号が連絡先リストにない場合（ステップ217）、「ブロックされた発呼者」のリストにその発呼者番号があるか否かを判定することもできる。発呼者番号が「ブロックされた発呼者」のリストにある場合、呼出音の生成はステップ219で消勢され、処理はステップ214もしくはステップ212へ進み、またはステップ219が省略される場合には、処理は直接的にステップ214またはステップ212へ進む。しかし、発呼者番号が「ブロックされた発呼者」のリストにない場合、呼出音を生成して番号を表示し、処理はステップ206へ進んでタイマを始動させる。まず「ブロックされた発呼者」のリストをチェックし、そのリストにないと判定した場合に、次に連絡先リストをチェックすることもできる。更に別のやり方は、「ブロックされた発呼者」のリストのみをチェックすることである。これらの別のやり方の利点は、被呼者は、誰かから呼び出し中である旨の情報は受けるが、被呼者がブロックされた発呼者からの呼の通知を受けたり／そのような呼によって妨害されたりしないことである。

呼確立要求が受諾されない場合（ステップ201）、図示した例では、処理はステップ212へ進み、呼確立要求に対する否定応答を送信する。呼確立要求を取り扱う何らかの他の手法を用いてもよいことを理解すべきである。

上記から明らかなように、発呼者および被呼者が前もって互いに接続されること、または被呼者が発呼者の何らかの情報を有することは必要とせず、発呼側ユーザ装置が自動的に、またはユーザ入力への応答に際しての何れかで、接続確立要求にURIを付加すると、発呼元情報が利用可能となる。更に、他の利点は、被呼者に対して表示される発呼元情報を発呼者の連絡先情報に結び付けていないため、発呼者は自身の連絡先情報を秘密性を維持しながらも被呼者には識別可能とすることができることである。

図３は、発呼側ユーザ装置の代表的な機能、すなわちより正確には、接続確立要求開始時の発呼者識別ユニットの代表的な機能を例示するフローチャートである。図３の例では、ユーザ設定情報は、呼確立がトリガされる度に発呼元情報の様々な選択肢を選択し得るように設定される。発呼元情報は、常にビデオなどの１つのタイプに設定してよく、または連絡先情報の一部として被呼番号に対応付けてもよく、その場合には、デフォルトタイプを用いるか、または連絡先情報に含まれていない番号に代わって示されたものを用いてもよいことを理解すべきである。

呼確立を指示するすユーザ入力が検出されると（ステップ301）、ユーザは、ステップ302で発呼元情報として送信すべき情報を入力するプロンプトを示される。例えば、「最近記憶した情報の使用」、「ビデオの送信」「新規の取込み画像」「測定データ」および「識別認証」などの様々な選択肢をユーザに表示してよい。多くの選択肢が提供されてよく、上記の例は単なる例であって網羅的列挙でないことを理解すべきである。この例の各選択肢間の基本的な差異は以下の通りである。すなわち、図示したユーザ装置の例において、選択肢を前もって記憶しておくか、または選択肢が実際のリアルタイム情報であって当該情報を、またはその情報を導出し得る元となる情報を取得するように構成された対応する手段によって取得する必要のあるものであり、その場合、このような情報は、図示した例では、発呼元情報の仲介として機能するサーバへ配信する必要がある。使用するサーバは、発呼元情報として送る内容か、または使用する設定情報である内容に応じたものでよい。例えば、「サーバＸの使用」なる設定情報を含むプロファイルがユーザ装置における選択されたプロファイルでなければ、設定情報は、ビデオストリームに「サーバ１」を使用し、取り込んだ情報からの情報の導出には「サーバ２」を使用するとしてよい。また、あるプロファイルの場合、または設定情報にて他のサーバがプロファイル定義されていない場合、ユーザ装置自体をサーバとして使用するように定義することもできる。そのため、どのようなサーバを用いるか、およびどのようにサーバを選択するかに制限はない。

ユーザ選択を受信すると、ステップ303では、この選択がリアルタイム情報を指示しているか否かを判定する。ユーザがリアルタイム情報を配信することを選択した場合、選択された情報に関するデバイス／ユニット／インタフェース／センサをステップ304で起動し、当該情報をステップ305で取り込み、ステップ306でサーバへ送信して一時記憶し、および／または更に処理する。ユーザ装置自体がサーバである場合、サーバへの送信とは、ユーザ装置のメモリ内の記憶領域へ少なくとも一時的に蓄積することを意味すると理解すべきである。選択された情報に応じて、取込みおよび送信は、単独のステップであるか、またはバックグラウンドで連続していてもよい。例えば、ユーザの写真の取込みとその送信は単独のステップであるが、ビデオストリームの送信は連続したステップである。実現例に応じて、一連の取込みおよび送信は、呼が確立するか、もしくは呼が確立しないと判定されるまで、または確立した呼が終了し、もしくは取込みおよび送信の停止を指示するユーザ入力を受けるまで、連続する。これらのステップは、明確にするために、図３では図示しない。ステップ307では、URIをサーバから受信し、URIは、コンテンツ、すなわち取り込んだ情報、またはその取り込んだ情報に基づいて導出された情報が記憶されるリソースを指示するものである。

URIを受信すると、呼確立要求がステップ308で生成され、URIはステップ308で呼確立要求に付加されて、次にステップ309で、その呼確立要求が１以上の被呼者へ送信される。明確にするために、ここでは呼確立要求は一者のみへ送信されると仮定する。

次にステップ310では、タイマを始動して、呼確立要求を未確定の要求として指示するメッセージを受信したか（ステップ311）、タイマが満了したか否か（ステップ312）、ユーザが呼を終了させたか否か（ステップ313）、呼確立要求に対する拒否を受信したか否か（ステップ314）、または呼確立要求に対する受諾を受信したか否か（ステップ315）を監視する。

呼確立要求を未確定の要求として指示するメッセージを受信した場合（ステップ311）、呼出音をステップ316でユーザに対して出力し、その後も監視を継続する。

タイマが満了した場合（ステップ311）、またはユーザが呼を終了させた場合（ステップ312）、または拒否を受信した場合（ステップ313）、処理はステップ317で終了する。

受諾を受信した場合（ステップ315）、呼確立はステップ318で継続される。しかし、本発明は、実際の呼確立への変更を必要としないので、ここでは詳細に説明しない。

前もって記憶した情報の配信をユーザが選択した場合（ステップ303）、ユーザは、ステップ319において、送信すべき情報（コンテンツ）を指示するプロンプトを例えばブラウザによって示される。本実現例では、この目的のために前もって記憶された情報は有効期間を有し、満了後には使用可能（指示可能）でなくなると仮定している。ユーザ指示をステップ320で受信すると、指示された情報に対応したURIがステップ321で索出され、そこで、処理はステップ308へ続いて、URIを伴う要求を生成する。

他の実現例では、ステップ321の前に、ユーザに指示された情報が十分に新しいか否かを判定してよく、情報が古すぎる場合、ユーザは再度プロンプトを示される。

更に他の実現例では、提供されるすべての選択肢が実際のリアルタイム選択肢であり、したがってステップ303および319ないし321は省略される。

上記から明らかなように、発呼者もしくはビデオストリームから得たばかりの写真のようなリアルタイム情報を提供する機能によれば確実に、発呼者が誰か他人のユーザ装置を用いたときでも被呼者は発呼者を容易に識別することができ、または被呼者が多忙で邪魔されたくない場合でも、被呼者は緊急事態もしくは発呼者の急ぎの状態が明らかに分かる映像に気付くことができる。

他の実現例では、例えば、発呼元情報を選択肢の１つとして前もって設定すれば、ユーザはこの情報を提供するプロンプトを示され、これによって当該情報を送信することを暗黙に受諾し、または情報取込みを開始するプロンプトを示され、これによってユーザには、情報を送信されたことをユーザが受諾せず、もしくはユーザに全く通知されなくても、ユーザが呼確立を終了させる可能性を提供し、その場合、ユーザは、アプリケーションを伴う呼によって、もしくはユーザ装置の使用を開始することによって、および／もしくはその「発呼元情報配信を私に知らせるな」という設定情報を有するプロファイルを使用することによって、情報が送信されることを受諾してしまうことができる。

図４ないし図９は、他の例を図示するシグナリングチャートである。必要な情報の配信にいずれの適切なプロトコルも用いることができるため、シグナリングチャートは汎用レベルに変換した情報交換を例示するものである。適切なプロトコルの例には、HTTP（ハイパテキストトランスファプロトコル）、RTHTTP（2013年４月23日に提出された英国特許出願1307340.8に記載されたようなリアルタイムHTTP）、SIP（セッションイニシエーションプロトコル）、SDP（セッション記述プロトコル）RTP（リアルタイムトランスポートプロトコル）、RTCP（RTPコントロールプロトコル）、RTMP（RTPメッセージングプロトコル）、ファイアウォールを横断するHTTP要求内にカプセル化したRTMPTのようなRTMPのバリエーション、およびSkypeプロトコルがある。他のプロトコルも同様に用いてよく、これには、いまも規定作成中であるような新しいプロトコルおよび基準が含まれることを理解すべきである。更に、本明細書を読むことにより、当業者は、現存の、もしくは将来開発される何らかの適切なプロトコルおよび／または基準で本願記載の機能を実現することができる。更に、呼確立に用いるプロトコルは、発呼元情報配信に用いるプロトコルとは異なっても、または同じでもよいことを理解すべきである。

明確にするために、以下の例では、呼は二者間呼である。グループ呼または会議呼、すなわち参加者が３以上である呼に対して同じ原理を適用することは、当業者にとって複雑でない手法である。

図４および図５の例は、アリスのユーザ装置UA1から直接的に配信されるビデオストリームを発呼元情報とし、UA1がボブのアドレス、またはボブの使用するユーザ装置UA2のアドレスを有すると仮定している。

図４を参照して、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。したがって、UA1はUA2へメッセージ4-1を送信し、これは、発呼者アドレス、被呼者アドレス、当該呼に関する付加情報への指示子としてのURI、および、図示した例では、オーディオ呼およびビデオ呼についてのメディア定義、ならびに他の情報を含む呼確立メッセージである。メッセージ4-1の例はSIP INVITEであり、これはURIについて付加フィールド「ｕ」を含み、このフィールドは、SDPにおいてセッションに関する付加情報への指示子の送信に用いるために定義されたものである。他の例は、本体にURIを含むHTTP呼要求である。発呼元情報を指示するURIを使用する利点は、発呼元情報がオペレーションシステムに無関係に配信可能であり、発呼元情報が発呼者アドレス情報に依存することなく配信できることである。

UA2は、時点4-2においてメッセージ4-1がURIを含むことを検出する。したがって、UA2は、呼確立メッセージへ通常応答を送信するが、UA1へのメッセージ4-3では呼出音を未だ生成していない。しかし、他の実現例では、メッセージ4-3を送信しないことを理解すべきである。URIを検出すると、UA2は、URIによって指示されたリソースへの接続を確立し、情報を取得する。図示した例では、これは、ビデオを少なくとも一時的に記憶する記憶領域であるリソースへ接続確立メッセージ4-4を送ることによって行なわれる。URIがUA1を指示しているので、メッセージ4-4はUA1に宛てたメッセージであり、そのURIを含んでいる。

時点4-5においてUA1内でリソースへの接続確立要求を検出すると、UA1は、リソースへの接続を受諾するメッセージ4-6を送信し、コンテンツは、メッセージ4-7に含まれてUA1からUA2へ転送される（図４では最初のメッセージだけが示されている）。この例では、コンテンツがビデオストリームであると仮定する。メッセージ4-7は一種のユニキャストのビデオストリームを形成する。発呼元情報を受信すると、UA2は、時点4-8において呼出音を生成し、ボブに対してビデオストリームを表示する。時点4-9では、UA1はボブが呼に応答したことを検出する。図示した例では、UA2は、発呼元情報について確立された接続をメッセージ4-10の送信で終了するように構成されている。更に、UA2は、ボブがアリスの呼に応答したことを指示するメッセージ4-11を送信する。他の実現例では、メッセージ4-10は送信されないが、メッセージ4-11がその情報を指示すると解釈してよく、すなわち発呼元情報配信に対して確立された接続は、その呼についての接続が確立したときに解放され、または実際の呼が続いている限りメッセージ4-7を送信してもよい。

メッセージ4-10に応答して、UA1は、メッセージ4-13によってそれを承認して、発呼元情報配信に対して確立した接続を介したビデオストリームの配信を時点4-12において停止する。更に、当該呼を受諾したので（メッセージ4-11）、UA1は、メッセージ4-14を送信することによって呼受諾を承認し、双方向メディアストリーム4-15がアリスとボブとの間に確立される。メディアストリーム4-15は、オーディオストリームおよび／またはビデオストリームでよい。

メッセージ4-10の送信に代えて、UA2は、メッセージ4-7にて配信された一方向の発呼元情報に対して肯定応答の送信（図４では図示せず）を停止するように構成してもよい。更に、UA2は、ボブがアリスの呼を受諾したことを検出（時点4-9）すると直ちにビデオの表示を停止するように構成してよい。別のやり方は、メッセージ4-11を暗示的メッセージ4-10として解釈するようにUA1を構成するものであり、その場合、メッセージ4-10および4-13は送信されない。

図４の例を挙げると、双方向の接続確立が未確定である間は、発呼元から被呼者への一方向の接続が確立され（図４において斜体で示す）、一方向の接続は、遅くとも双方向の接続が確立されるときに解放される。他の実現例では、一方向のメディア接続は、双方向のメディア接続に昇格してもよいことを理解すべきである。

図５は、図４と同様の状況のシグナリングを例示している。アリスは、自分のユーザ装置UA1に対して、ボブへ発呼したい旨を入力したところである。したがって、UA1は、発呼者アドレス、被呼者アドレス、および、図示した例ではオーディオ呼およびビデオ呼のメディア定義、ならびに他の情報を含むメッセージ5-1をUA2へ送信する。しかし、図４におけるメッセージ4-1とは異なり、メッセージ5-1はURIを含んでいない。

UA2は、時点5-2でメッセージ5-1がURIを含んでいないことを検出する。しかし、ボブの設定情報は発呼元情報を必要とする。したがって、UA2は、呼確立メッセージに対する通常応答をメッセージ5-3にてUA1へ送信するが、メッセージ5-4において発呼元情報要求をUA1へ送信する。

UA1は、時点5-5で発呼元情報、またはより正確には発呼元情報を取得可能な情報が要求されていることを検出する。UA1は、アリスの設定情報から、発呼元情報配信をアリスが許可したか否かを判定する。図示した例では、アリスは、発呼元情報配信を受諾したと仮定している。したがって、UA1は、元のメッセージ5-1にURIを付加し、上記メッセージ5-1に対応するメッセージであるメッセージ5-1'をUA2へ送信する。これ以降、手順は図４で記載されたように続き、そのため、ここでは無用の繰返しを避ける。

図４および図５の例から分かるように、発呼側ユーザ装置が、被呼者側ユーザ装置からの何らかの特定の要求を用いることなく呼確立要求にURIを付加すると、呼確立は、時間をほとんどかけず、またネットワークリソースをほとんど用いない。そうすることによって、メッセージ5-3、5-4および5-1'、ならびに時点5-5は回避される。しかし、メッセージ5-4および5-1'、ならびに時点5-5によれば、発呼元情報は確実に、発呼側ユーザ装置またはサブスクリプションのサポートするフォーマットとなる。換言すれば、メッセージ5-1にURIが含まれていれば、UA2は、時点5-2で自身が発呼元情報のフォーマットをサポートしていないことを検出でき、このフォーマットはURIによって指示され、したがってUA2のサポートするフォーマットを指示するメッセージ5-4を送信する。

図６は、常にサーバS1を介して発呼元情報が配信される集中型システムのシグナリングを示し、サーバは、発呼元情報が確実にリアルタイムまたは準リアルタイムの基準を満たすように、ミリ秒などの非常に短い時間で発呼元情報を記憶するように構成されている。図６の例では、発呼元情報がビデオストリームであり、アリスのユーザ装置UA1は、ボブのアドレス、またはボブの使用するユーザ装置UA2のアドレスを有し、アリスのユーザ装置における設定情報は、アリスが誰かへの発呼を選択するときは常に発呼元情報を配信することを規定していると仮定している。

図６を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。発呼元情報はアリスの設定情報に応じて配信されるが、この発呼元情報を配信するためにUA1はメッセージ6-1をS1へ送信し、このメッセージは発呼元情報を配信するための接続を要求するメッセージである。S1はメッセージ6-2によって応答し、これは、発呼元情報に対する接続を受諾し発呼元情報の送り先であるアドレスを指示するメッセージである。このアドレスは、実際の呼に対しても使用可能なアドレスでよい。UA1は時点6-3でビデオの取込みを開始し、UA1は、アドレスの受信後、ビデオストリーム6-4においてこのビデオをS1へプッシュする。UA1は、アリスの発呼の意志を検出すると、もしくはアドレスを受信すると、または上記の時点の間の何れかの時点で直ちにビデオの取込みを開始してもよいことを理解すべきである。

URIの受信後、UA1はS1を介してメッセージ6-5をUA2へ送信し、このメッセージは、発呼者アドレス、被呼者アドレス、呼に関する付加情報への指示子としてメッセージ6-2に指示されたアドレス、および、図示した例では、オーディオ呼およびビデオ呼についてのメディア定義、ならびに他の情報を含む呼確立メッセージである。UA2は、S1を介してUA1へメッセージ6-6を送信することでメッセージ6-5に肯定応答する（そこでUA1は音声出力を開始して、ボブのユーザ装置に通知中／呼出信号送出中であることをアリスに知らせてもよい）。メッセージ6-5におけるURIに応答して、UA2はメッセージ6-7をS1へ送信し、これは、URIに隠れたコンテンツへのプル要求を指示するものであり、コンテンツはメッセージ6-8で受信される。

発呼元情報を受信すると、UA2は、時点6-9で呼出音を生成し、ボブに対してビデオストリームを表示する。時点6-10では、UA2は、ボブが呼に応答したことを検出し、したがって、UA2はS1を介してメッセージ6-11をUA1へ送信し、これは、ボブがアリスの呼に応答したことを指示するメッセージである。そこで、呼の実際のコンテンツは、メッセージ6-12によってS1を通して（図６で例示されるように）か、またはS1を通るメッセージ6-12を用いることないかのいずれかで、UA1とUA2との間で配信される。

図７および図８の例では、ビデオストリームを発呼元情報とし、アリスのユーザ装置UA1がボブのアドレス、またはボブの使用するユーザ装置UA2のアドレスを有し、ビデオストリーム、およびUA1とUA2の間の他のユーザトラフィックがサーバS1を通ると仮定している。

図７を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。したがって、UA1はS1を介してメッセージ7-1をUA2へ送信し、このメッセージは、被呼者アドレス、および、図示した例では、オーディオ呼についてのメディア定義を含む呼確立メッセージである。他の例では、メッセージ7-1は、オーディオ呼およびビデオ呼についての定義、またはビデオ呼だけについての定義を含むことを理解すべきである。

S1は、UA2へメッセージ7-1を転送し、それに対する肯定応答をメッセージ7-2にて送信する。メッセージ7-2に応答して、UA1は、呼出音の出力を開始し、アリスはボブのユーザ装置を呼出中であることを知る。

発呼元情報はアリスの設定情報に応じて配信されるが、この発呼元情報を配信するためにUA1はメッセージ7-3をS1へ送信し、このメッセージは発呼元情報を配信するための接続を要求するメッセージである。S1はメッセージ7-4によって応答し、これは、発呼元情報に対する接続を受諾し発呼元情報の送り先であるアドレスを指示するメッセージである。ここでUA1は、S1へのビデオストリームの配信を開始する。

その間に、UA2は、時点7-6においてメッセージ7-1がURIを含まないことを検出する。ボブの設定情報は発呼元情報を必要としているため、UA2はメッセージ7-8をS1へ送信し、これは、メッセージ7-1で受信した呼確立要求に関する発呼元情報を要求するメッセージである。

S1は、時点7-9において、S1が既に受信した発呼元情報をメッセージ7-8が要求していることを検出する。したがって、S1は、ビデオストリーム7-5、すなわち発呼元情報をUA2へ転送する。

発呼元情報を受信すると、UA2は、時点7-10において呼出音を生成し、ボブに対してビデオストリームを表示する。時点7-11では、UA2は、元の呼確立要求がオーディオ呼だけを指示していても、ボブがビデオ呼の選択によってその呼に応答したことを検出する。UA2はメッセージ7-12を送信するが、これは、ボブがアリスの呼に応答したうえでビデオ呼を希望していることを指示するメッセージである。

図示した例では、S1およびUA1は、メッセージ7-12も発呼元情報の転送を終了すると解釈するように構成されている。したがって、S1は、メッセージ7-12を転送し、時点7-13においてビデオストリーム7-5の転送も終了する。

メッセージ7-12を受信すると、UA1は、ビデオストリーム7-5の転送を停止し、本来要求されたような他のタイプの呼を7-12が含むことと、アリスのユーザ設定情報がオーディオ呼からビデオ呼へのタイプ変更に対する許可を必要とすることを検出し、したがって時点7-14において、アリスには、当該呼をビデオ呼として受諾するか、またはその呼をオーディオ呼として維持するかのいずれかをとるかについてプロンプトを示す。他の実現例では、オーディオ呼からビデオ呼への変更を受諾するプロンプトをアリスに示さないことを理解すべきである。図示した例では、アリスはビデオ呼を受諾する。UA1は、ビデオ呼がメッセージ7-15を送信することによって受諾の旨をUA2に通知する。そこで、双方向のビデオストリーム7-16がその呼に確立される。

他の実現例では、S1は、メッセージ7-1に代えて呼確立要求およびURIを含むメッセージを送信する。

図８は、図７と同様の状況のシグナリングを例示している。しかし、本例では、UA1から発呼元情報は配信されず、被呼者側ユーザ装置から明示的な要求が発生することはない。

図８を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。したがって、UA1は、メッセージ7-1に対応するメッセージ8-1をS1へ送信する。S1は、メッセージ8-1をUA2へ転送し、メッセージ8-2にてメッセージ8-1に対する肯定応答を送信する。メッセージ8-2に応答して、UA1は、呼出音の出力を開始し、アリスは、ボブのユーザ装置が呼出中であることを知る。

UA2は、時点8-3においてメッセージ8-1がURIを含まないことを検出する。ボブの設定情報が発呼元情報を必要としているため、UA2は、S1を介してUA1へメッセージ8-4を送信し、このメッセージは、メッセージ8-1で受信した呼確立要求の発生したユーザ装置の発呼元に関する発呼元情報を要求するものである。

S1は、時点8-5において、UA1から受信してない発呼元情報をメッセージ8-4が要求していることを検出する。S1はメッセージ8-6をUA1へ送信し、これは、発呼元情報を配信する接続を要求すると共に発呼元情報の送信先のアドレスを指示するメッセージである。メッセージ8-6はメッセージ8-4と同じでよい。UA1はメッセージ8-7によって応答し、これは、発呼元情報のための接続を受諾するメッセージである。更に、UA1は、時点8-8においてビデオの取込みを開始し、これは次に、UA1がビデオストリーム8-9でS1へ転送する。この時点で取込みを開始することによって確実に、UA2に対してプッシュまたはプルしてよい発呼元情報があるが、本例では、発呼元情報はUA2が発呼元情報に対して要求した後のみ送信されるようにしている。

S1は、UA1が発呼元情報配信（メッセージ8-7）を受諾したことを検出し、メッセージ8-10の送信によって発呼者情報配信についてのUA2への接続をトリガする。更にS1は、ビデオストリーム8-9をUA2へ転送する。これ以降、手順は、図７からの時点7-12以降のように続き、すなわちUA2は、呼出音を生成し、ボブに対してビデオストリームを表示する。そのため、ここでは無用な繰返しは避ける。

図４、図５、図６、図７および図８の例では、ユーザ装置UA1およびUA2は、アリスおよびボブから何らかの特定のユーザ入力がなくても発呼元情報を配信する。そのため、発呼および呼に対する応答は、発呼元情報なしの発呼および応答のように円滑である。

図９を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。したがって、UA1はメッセージ9-1をUA2へ送信し、これは、発呼者アドレス、被呼者アドレス、およびオーディオ呼および／またはビデオ呼についてのメディア定義、ならびに他の情報を含むSIP INVITEメッセージである。

UA2は、時点9-2において、メッセージ9-1がURIを含んでいないことを検出する。ボブのユーザ設定情報は、そのような場合、発呼元情報を要求するか否かのプロンプトをボブに示すと共に、それに応じて時点9-2でUA2がボブにプロンプトを示すことを要求するものである。ボブに対して、「発呼元情報なしでアリスから到来する呼が未確定である。発呼元情報要求を希望しますか」と簡易に表示することによってプロンプトを示してもよく、または、ボブに対して、ボブが得たい発呼元情報のタイプも選択するプロンプトを示してもよく、および／または、ボブに対して、呼要求を拒否もしくは婉曲に拒否する選択肢を与えてもよい。様々な選択肢の例には、上記ステップ301で記載されている。図示した例では、ボブは、典型的にはアリスが発呼元情報を伴った発呼をしているために、疑問を持つようになる。したがって、ボブは、発呼元情報として「指紋によるユーザ認証」を選択する。ボブのユーザ入力に応答して、UA2はURI欠落を指示するメッセージ9-3をUA1へ送信する。この機能の利点は、被呼者が応答するか否かを決める以前に、発呼者の更なる情報を要求するか否かを決めることができることである。様々な発呼元情報のタイプについて様々なメッセージ9-3があり、および／またはメッセージ9-3は、所望のタイプの発呼元情報を指示するフィールドを有している。

メッセージ9-3を受信すると、UA1は、時点9-4において、ボブへの呼確立を継続するのに指紋が必要であることのプロンプトをアリスに示す。図示した例では、アリスは、継続を望んでいるため、アリスは、時点9-4において、ユーザ入力として自分の指紋を入力する。指紋は、例えばスナップショットを撮ることによって入力してよい。アリスの設定情報には、アリスの指紋が予め記憶されたサーバS1へのアドレスがある。UA1およびS1は、メッセージ9-5および9-6によって接続を確立し、次に、UA1は、指紋を含むメッセージ9-7を指紋認証のために送信する。ユーザ装置UA1の使用が指紋認証を必要とする場合、時点9-4においてユーザにプロンプトを示す必要はないが、UA1を使用する許可を得るのに用いられる指紋をメッセージ9-7にて転送してよく、または使用の許可を判定したときに得られた指紋と許可に際しての比較で用いられたメモリ内の指紋の両方をメッセージ9-7にて送信してもよい。そのような場合、サーバが指紋を記憶する必要はない。

S1は、指紋がアリスの指紋であるかを認証し、時点9-8においてその結果を記憶領域に一時的に記憶し、メッセージ9-9にてその記憶領域を指示するURIを送信する。

URIの受信後、UA1は、時点9-10においてメッセージ9-1にURIを付加し、メッセージ9-1'にてURIを伴う要請をUA2へ送信する。

UA2は、メッセージ9-1'がメッセージ9-1の更新されたものであってURIを含むことを検出する。したがって、UA2は、メッセージ9-11をUA1へ送信し、メッセージ9-11は、未確定としてメッセージ9-1にて送られた要求を指示し、URIによって指示されたS1へ呼確立メッセージ9-12を送信する。他の例では、メッセージ9-11は、メッセージ9-1の受信直後に送信される。

メッセージ9-12に応答して、S1は、メッセージ9-13を送信することによって接続を受諾し、記憶領域からその結果を検索し、他の使用のために記憶領域を解放し、メッセージ9-7'にてその結果をUA2へ転送する。

UA2は、時点9-14において呼出音を生成し、ボブに対してその結果を表示する。時点9-14では、UA2は、図示の例ではオーディオ呼である呼にボブが応答したことを検出する。UA2は、ボブの応答を指示するメッセージ9-15（SIP 200 OK）を送信する。

メッセージ9-15に応答して、UA1は、メッセージ9-16（SIP ACK）によって肯定応答し、RTPを介して双方向オーディオ9-17がアリスとボブとの間に確立される。

図１０は、集中型システムにおけるシグナリングを例示し、発呼者と被呼者との間の接続が実際には２つの別の接続であり、１つは発呼者と集中型サーバとの間であり、１つは集中型サーバと被呼者との間である。そのような集中型サーバにおいて、ユーザ装置の呼クライアントは、少なくとも通信に係わっていないときに、定期的にサーバをポーリングして何らかの未確定の呼確立要求を検出し、呼クライアントからサーバへ通信が開始される。図示した例では、呼クライアントは、HHTP GETおよびRTMPを用いてREST（Representational State Transferスタイル）において通信するように構成されているが、本例はそのような方式に限定されない。更に、この例では、発呼元情報を含むリソースへの参照情報は、発呼者識別子と被呼者識別子の組合せである。更に、この例において、集中型サーバS1は、発呼者情報がリアルタイムまたは準リアルタイムの基準を確実に満たすようにするために、ミリ秒などの非常に短い時間だけで発呼元情報を記憶するように構成されているものとするが、本例はそのような方式に限定されまい。図１０の例では、発呼元情報がビデオストリームであり、アリスのユーザ装置UA1は、ボブのアドレス、またはボブの用いるユーザ装置UA2のアドレスを有し、アリスのユーザ装置における設定情報は、アリスが誰かへの発呼を選択するときは常に発呼元情報を配信することを指示すると仮定している。

図１０を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。接続を確立するため、およびアリスの設定情報に応じて配信すべき発呼元情報を配信するために、UA1はメッセージ10-1をS1へ送信し、これは、「Call request」（HTTP）などのボブのユーザ装置UA2への接続を要求すると共に発呼元情報、すなわち「NetStream Publish Audio/Video」（RTMP）などのビデオストリームメッセージ10-2を配信するメッセージである。

S1は、時点10-3において、当該呼のレコードを作成し、発呼元情報の一時的記憶用に何らかのメモリリソースを確保し、UA2へのイベントを作成することによってこの要求をマッピングする。このレコードは、UA1およびUA2が当該呼の参照に用いる発呼元識別子および被呼者識別子の両方を含み、そのため、これらを使ってレコードを索出し、これによって発呼元情報が索出される。

UA2が次に「Event Poll, periodical」（HTTP）などのメッセージ10-4によってS1をポーリングすると、S1は、メッセージ10-5とメッセージ10-6における発呼元情報とを送信することによって呼確立要求を通知する。メッセージ10-6はメッセージ10-2に対応している。

メッセージ10-5およびメッセージ10-6を受信すると、UA2は、時点10-7において、呼出音を生成すると共に発呼元情報、すなわちビデオを表示することによって、呼確立要求をボブに知らせる。時点10-8においてUA2が呼の受諾を検出すると、処理は従来のように続く。より正確には、UA2は「Call request」（HTTP）などのメッセージ10-9をS1へ送信し、そこでS1は、「Call Response」（HTTP）などのメッセージ10-10を送信することによってUA1にボブの応答を確認する。そこでメッセージ10-11（アリスからS1へ、S1からボブへ）およびメッセージ10-12（ボブからS1へ、S1からアリスへ）の交換によってビデオまたはオーディオ呼が進行する。メッセージ10-11および10-12はメッセージ10-2と同じよい。

図１１に示した例は、発呼元情報がボブによって具体的に要求された場合だけ送信される点で、図１０の例とは異なる。例えば、アリスの設定情報は、「要求されない限り発呼元情報を送信するな」であってよく、ボブの設定情報は、「発呼元情報を受信しない場合に通知し、要求する機会を与える」ものでよい。換言すれば、図１０では、発呼元情報を何ら具体的に要求しなくても接続確立要求および発呼元情報が続いて送信され、図１０では、すなわち発呼元情報の送信は具体的な要求に応答して行なわれる。

図１１を参照すると、アリスは、ボブへ発呼したい旨を自分のユーザ装置UA1に入力したところである。接続を確立するために、UA1は、ボブのユーザ装置UA2への接続を要求するメッセージであるメッセージ11-1をS1へ送信する。

S1は、時点11-2において、当該呼のレコードを作成し、発呼元情報の一時的記憶用に何らかのメモリリソースを暫定的に確保し、UA2へのイベントを作成することによってこの要求をマッピングする。他の方式では、発呼元情報の一時的な記憶用のメモリリソースを確保しないことを理解すべきである。

UA2が次にメッセージ11-3によってS1をポーリングすると、S1は、メッセージ11-4を送信することによって呼確立要求を通知する。

メッセージ11-4を受信すると、UA2は、時点11-5において、呼出音を生成すると共に発呼元情報を要求するための選択ツールを表示することによって、呼確立要求をボブに知らせる。図示した例において、ボブは発呼元情報の要求を選択しているが、UA2はこれを時点11-5で検出する。したがって、UA2は、発呼元から発呼元情報を要求する「Preview Request」（HTTP）などのメッセージ11-6を送信する。

S1は、当該要求を現存のレコードにマッピングすることができるので、S1は、「Preview Response」（HTTP）などのメッセージ11-7を送信することによってこの要求をUA1に知らせる。

本例では、アリスからの応答は必要ないと仮定している。したがって、メッセージ11-7に応答して、UA1はメッセージ11-8にて発呼元情報のS1への配信を開始し、S1は、発呼元情報を呼要求にマッピングすると共にUA2へ発呼元情報を送信する（メッセージ11-8）する。

ビデオと仮定した発呼元情報を受信すると、UA2は、時点11-9において、ボブに対して発呼元情報を表示する。そこで、ボブが呼を受諾した場合、時点10-8からは処理が上記のように続く。

上記の例から明らかなように、発呼者および／または発呼側ユーザ装置は、要求された接続が受諾される前に、正確な実時間性についての情報を出力してもよく、この情報はしばしば、受信者が応答するか否かを自身に決定させる必要性の基となる最も厳しい情報となろう。

上記では明確に触れていないが、発呼元情報を被呼者へ出力する際に経由するユーザ装置は、被呼者が呼（接続）の受諾の際に使用するユーザ装置とは別であってもよいことを理解すべきである。

図４ないし図９の上記例では、発呼元情報を受信すると仮定している。発呼元情報を受信しない場合、処理は図２を用いて上記したように続けてよいことを理解すべきである。

上記では明確に触れていないが、発呼元情報を受信する場合でも、被呼者は、更なる何らかの発呼元情報を要求するプロンプトを示され、またはそうでなくてもその機会を提供されてもよいことを理解すべきである。

図２ないし図１１において上記したステップ／時点、メッセージおよび関連の機能は、絶対的時間の順ではなく、これらのステップ／時点のうちのいくつかを行なってもよく、各メッセージを同時に、または記載した順序とは異なる順序で送信してもよい。例えば、プッシュ方式の原理を用いる場合、発呼者は被呼者に対して、被呼者が呼確立要求に対する応答前にUCIを受信したいか否かを問い合わせてもよく、被呼者がUCIを受信したい場合、発呼者は、呼確立要求が未確定のまま被呼者へUCIを送信することになる。また、各ステップ／時点の間、または各ステップ／時点の中で他の機能を実行し、および例示された各メッセージの間に他のメッセージを送信することもできる。例えば、ボブは、アリスに対して自分のウェブカメラを動かすようにアリスに指示するテキストメッセージを送信し、ボブが呼に応答する前にボブにアリスが見えるようにしてもよい。また、各ステップ／時点／メッセージのいくつか、もしくは各ステップ／時点／メッセージの一部分は、除外し、またはある相応のステップ／時点／メッセージ、もしくはそのようなステップ／時点／メッセージの一部分に置き換えてもよい。各メッセージは単なる例示であり、同じ情報をいくつかの別々のメッセージに分けて送信してもよい。

上記した機能を組み合わせることによって、様々なサービスまたはアプリケーションを作成してよい。例えば、サービスプロバイダは、「セキュア」、「簡易」および「プレミアム」のサービスを有することができる。すなわち、「セキュア」サービスは、発呼者が既知の者であり、そのユーザ装置はある機能／特徴を有し、被呼者が発呼元情報を希望している旨を指示したフォーマットで発呼元情報を被呼者に提供することを保証するものである。「簡易」サービスは、発呼元情報を提供することを保証するものである。また、「プレミアム」サービスは、セキュアサービス相当、簡易サービス相当のような様々なサービスモードの中からユーザが選択できるものである。

図１２は装置1200のいくつかのユニットを図示する簡易的なブロック図であり、本装置は、発呼情報ユニットもしくは対応する機能部、または図１０もしくは図１１を用いて上記した機能を実行する集中型サーバ、もしくは対応する機能部を含むユーザ装置に対して構成されたものである。図示した例では、本装置は、情報を受信および送信するための１以上のインタフェース（IF）1201と、本願記載の少なくとも発呼情報ユニットの機能を対応するアルゴリズム1203でユーザ装置として実現するように構成されたプロセッサ1202と、発呼情報ユニットおよび／または集中型サーバ構成に必要なプログラムコード、ならびにアルゴリズムを記憶するのに使用可能なメモリ1204とを含む。また、メモリ120４は、様々な設定情報またはルールまたはプロファイルのような他のあり得る情報を記憶するのにも使用可能である。

換言すれば、ユーザ装置、および／または集中型サーバ、および／または１以上の対応する機能を提供するように構成された何らかの同様の装置を提供するように構成された装置は演算装置であり、これは、実施例／例／実現例として上記した対応する装置機能の１以上を実行するように構成された何れの装置またはデバイスまたは機器でもよく、様々な実施例／例／実現例の機能を実行するように構成することができる。装置として記載された発呼者情報ユニットなどのユニットは別々ユニットでもよく、これらは、他の物理的装置に配置されてもよく、物理的装置は、機能を提供する１つの論理装置を形成するか、または同じ装置内の他のユニットに一体化してもよい。他の実施例では、装置内のユニット、またはそのユニットの機能の一部を他の物理的装置に配置してもよい。

より正確には、発呼者情報ユニットなどのユニットおよびエンティティは、ソフトウェアウェアコンポーネントおよび／またはソフトウェア−ハードウェアウェアコンポーネントおよび／またはファームウェアコンポーネント（読出し専用メモリなどの媒体に永久的に記録されるか、またはハードワイヤードコンピュータ回路として具現化されたもの）でよい。ここに記載された技術は様々な手段によって実現して、実施例／例／実現例として記載された対応する装置／エンティティの１以上の機能を実現する装置が従来の手段だけでなく実施例／例／実現例として記載された対応する装置の１以上の機能を実施する手段をも含むようにして、各機能ごとに別の手段を含んでもよく、または手段が２以上の機能を実行するように構成してもよい。例えば、これらの技術は、ハードウェア（１以上の装置）、ファームウェア（１以上の装置）、ソフトウェア（１以上のモジュール）、またはそれらの組合せで実現してよい。ファームウェアまたはソフトウェアについては、本願記載の機能を実行するモジュール（例えば、手順、機能など）によって実現することができる。ソフトウェアコードは、何らかの適切なプロセッサ／コンピュータ読出し可能データ記憶媒体もしくは記憶装置または製品に記憶して、１以上のプロセッサ／コンピュータによって実行することができる。

ユーザ装置および／または集中型サーバおよび／または１以上の相応の機能を提供するように構成された何らかの対応する装置を提供するように構成された装置は、一般に、装置のメモリおよび様々なインタフェースに接続されたプロセッサ、コントローラ、コントロールユニット、マイクロコンピュータなどを含んでよい。一般にプロセッサは中央処理装置であるが、付加的な演算処理装置でもよい。本願に記載された発呼者情報ユニットなどのユニット／エンティティの各々、またはいくつかもしくは１つは、コンピュータもしくはプロセッサ、または単一チップコンピュータ素子もしくはチップセットなどのマイクロプロセッサとして構成してよく、これらは、少なくとも算術演算用記憶領域を提供するメモリ、および算術演算実行用演算処理装置を含む。上記したユニット／エンティティの各々、またはいくつかもしくは１つは、１以上の演算処理装置、特定用途向け集積回路（ASIC）、デジタルシグナルプロセッサ（DSP）、デジタルシグナル処理装置（DSPD）、プログラマブル論理素子（PLD）、フィールドプログラマブルゲートアレイ（FPGA）および／または１以上の実施例の１以上の機能を実行するようにプログラムされた他のハードウェアコンポーネントを含んでよい。換言すれば、上記したユニット／エンティティの各々、またはいくつかもしくは１つは、１以上の算術論理ユニット、複数の特殊レジスタおよび制御回路を含む素子でよい。

更に、ユーザ装置および／または集中型サーバおよび／または１以上の相応の機能を提供するように構成された何らかの対応する装置を提供するように構成された装置は一般に、揮発性および／または不揮発性のメモリ、例えば、EEPROM、ROM、PROM、RAM、DRAM、SRAM、二重フローティングゲート電界効果トランジスタ、ファームウェア、プログラマブル論理回路等、および典型的には記憶コンテンツ、データなどを含む。メモリは、とくにメディアストリームコンテンツの蓄積を提供する場合、何れのタイプ（互いに異なる）でもよく、何らかのあり得る記憶構造を有し、必要であれば、何らかのデータベース／キャッシュ管理システムによって管理される。また、メモリは、ソフトウェアアプリケーション（例えば、１以上のユニット／エンティティのための）またはオペレーティングシステムなどのコンピュータプログラムコード、情報、データ、コンテンツなどを記憶して、プロセッサは、実施例による装置の動作に対応するステップを実行することができる。メモリまたはその一部分は、例えば、プロセッサ／装置の内部もしくはプロセッサ／装置の外部に実装されるランダムアクセスメモリ、ハードドライブもしくは他の固定データメモリもしくは記憶デバイスでよく、その場合、当業者に知られる様々な手段を介してプロセッサ／ネットワークに通信可能に接続することができる。外部メモリの例には、装置に着脱可能に接続されるリムーバブルメモリ、分散型データベースおよびクラウドサーバがある。

上記の各例では、発呼者の情報が被呼者に表示されるとしたが、そのような情報は、音声合成機器を用いて、もしくは触覚出力を用いて出力し、または様々な種類の振動を出力してもよく、例えば、各部の長さが変化する静止部および振動部を有するもの、および感知可能な出力を提供する他の手段を有するものでもよいことは、当業者であれば明らかである。

技術の進歩に伴って、本発明の概念を様々な手法で実現できることは当業者に明らかである。本発明およびその実施例は、上記した例に限定されず、特許請求の範囲内で変更可能である。

Claims (5)

1. 被呼側装置において、一方向接続で、双方向接続に関する発呼側装置からの接続確立要求を指示するメッセージおよび前記発呼側装置によって該発呼側装置のユーザから連続的に取り込まれるリアルタイムビデオを含むリアルタイムビデオストリームの両方を受信し、前記発呼側装置による前記リアルタイムビデオストリームでの連続的な送信は、前記接続確立要求が送信された時点または該時点の直前から開始され、少なくとも前記接続確立が未確定である間は継続して取込みおよび送信を行い、
   前記メッセージを受信しても前記被呼側装置にリアルタイムビデオストリームがない場合、前記被呼側装置から発呼元情報として前記リアルタイムビデオストリームを求める要求を前記発呼側装置に送信し、
   前記受信した一連のリアルタイムビデオストリームを出力し、前記接続確立要求をユーザに指示し、
   接続確立受諾を指示するユーザ入力を受けると、前記双方向接続を確立することを含むことを特徴とする被呼側装置における方法。
2. 請求項１に記載の方法において、該方法は更に、
   前記被呼側装置で前記接続確立要求の拒否を指示するユーザ入力を受けると、婉曲な拒否を行なうことを含み、前記接続確立要求の拒否は前記発呼側装置へ転送されないが、前記接続確立要求は未確定として前記発呼側装置へ指示されることを特徴とする方法。
3. 双方向接続に関する発呼側装置からの接続確立要求を指示するメッセージと、発呼側装置によって発呼側装置のユーザから連続的に取り込まれたリアルタイムビデオを含み前記発呼側装置によって前記接続確立要求が送信された時点または該時点の直前から連続的に送信されるリアルタイムビデオストリームとの両方を一方向接続で受信して、少なくとも前記接続確立要求が未確定の間は取込みおよび送信を継続する手段と、
   前記メッセージを受信してもユーザ装置にリアルタイムビデオストリームがない場合、該ユーザ装置から前記リアルタイムビデオストリームを求める要求を前記発呼側装置に送信する手段と、
   前記受信した一連のリアルタイムビデオストリームを出力し、前記接続確立要求をユーザに指示する手段と、
   接続確立受諾を指示するユーザ入力を受けると、前記双方向接続を確立する手段とを含むことを特徴とするユーザ装置。
4. 請求項３に記載のユーザ装置において、該装置は更に、前記接続確立要求の拒否を指示するユーザ入力を受けると、婉曲な拒否を行なう手段を含み、前記接続確立要求の拒否は前記発呼側装置へ転送されないが、前記接続確立要求は未確定として前記発呼側装置へ指示されることを特徴とするユーザ装置。
5. ユーザ装置において実行すると、該ユーザ装置は、
   双方向接続に関する発呼側装置からの接続確立要求を指示するメッセージおよび前記発呼側装置によって該発呼側装置のユーザから取り込まれたリアルタイムビデオを含むリアルタイムビデオストリームを一方向接続で連続的に受信し前記接続確立要求が送信された時点または該時点の直前から連続的に送信されると、前記リアルタイムビデオストリームを出力し、少なくとも前記接続確立要求が未確定である間は取込みおよび送信を継続し、
   前記メッセージを受信してもリアルタイムビデオストリームがない場合、発呼元情報として前記リアルタイムビデオストリームを求める要求を前記発呼側装置に送信し、
   前記接続確立要求をユーザに指示し、
   接続確立受諾を指示するユーザ入力を受けると、前記双方向接続を確立することを実行するように構成されたコンピュータプログラムコードを含むことを特徴とするコンピュータプログラム。

Images