図面 (/)

技術 発呼元についての付加情報

出願人 グルロジックマイクロシステムズオーワイ
発明者 カルッカイネン、トゥオマスカレヴォ、オッシ
出願日 2015年4月15日 (6年10ヶ月経過) 出願番号 2016-562758
公開日 2017年7月13日 (4年7ヶ月経過) 公開番号 2017-519389
状態 特許登録済
技術分野 電話機の機能 電話通信サービス
主要キーワード 汎用レベル 識別測定 アクセス制限付き 再使用不可 コンピュータ素子 独立言語 プログラマブル論理素子 音声生成器
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年7月13日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (13)

課題・解決手段

被呼者発呼元の情報を提供するために、発呼元に関するリアルタイムもしくは準リアルタイム情報、またはリアルタイムもしくは準リアルタイム情報を用いて導出した情報を含むリソース、あるいはリアルタイムもしくは準リアルタイム情報、またはリアルタイムもしくは準リアルタイム情報を用いて導出した情報への参照情報接続確立要求と共に送信し、リソースにおける情報または受信した情報は、要求された接続が確立される前に被呼者に対して表示し、被呼者が呼に応答するか否かを判定できるようにする。

概要

背景

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

概要

被呼者に発呼元の情報を提供するために、発呼元に関するリアルタイムもしくは準リアルタイム情報、またはリアルタイムもしくは準リアルタイム情報を用いて導出した情報を含むリソース、あるいはリアルタイムもしくは準リアルタイム情報、またはリアルタイムもしくは準リアルタイム情報を用いて導出した情報への参照情報接続確立要求と共に送信し、リソースにおける情報または受信した情報は、要求された接続が確立される前に被呼者に対して表示し、被呼者が呼に応答するか否かを判定できるようにする。

目的

一般に、ユーザが他のユーザとの接続を介して通信すること、例えば、会話の伝達が可能な電話機または同様のユーザ装置は、ユーザが接続確立を受諾するか否かを決める前に、通常、発呼者と称される接続確立開始者の情報をそのユーザに提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

第1のユーザ装置において第2のユーザ装置からの接続確立要求を指示するメッセージおよびコンテンツの両方を受信し、該コンテンツは少なくとも、第2のユーザ装置から発生するリアルタイムもしくは準リアルタイム情報または該第2のユーザ装置から発生するリアルタイムもしくは準リアルタイム情報を用いて導出された情報を含み、前記コンテンツを出力し、前記接続確立要求をユーザに指示し、接続確立受諾を指示するユーザ入力を受けると、前記接続を確立することを含むことを特徴とする第1のユーザ装置における方法。

請求項2

請求項1に記載の方法において、該方法は更に、前記メッセージを受信しても第1のユーザ装置にコンテンツがない場合、第1のユーザ装置から前記コンテンツを求める要求を送信し、該要求は第2のユーザ装置を対象とすることを含むことを特徴とする方法。

請求項3

第1のユーザ装置において、第2のユーザ装置への接続を確立する要求を指示するユーザ入力を検出し、第2のユーザ装置を対象とした接続確立要求を送信し、前記接続確立要求とは別に、コンテンツを送信し、該コンテンツは少なくとも、第1のユーザ装置のユーザに関するリアルタイムもしくは準リアルタイム情報、または該リアルタイムもしくは準リアルタイム情報を用いて導出された情報を含み、前記コンテンツは第2のユーザ装置を対象とし、前記要求された接続が確立される前に送信されることを特徴とする方法。

請求項4

請求項3に記載の方法において、該方法は更に、前記情報を求める何らかの特定の要求なしで前記接続確立要求および前記コンテンツを連続的に送信し、または特定の要求に応答して前記情報を送信することを含むことを特徴とする方法。

請求項5

第1のユーザ装置において、少なくともリアルタイムもしくは準リアルタイム情報または該リアルタイムもしくは準リアルタイム情報を用いて導出された情報をコンテンツとして含むリソースへの参照情報を含む接続確立要求を第2のユーザ装置から受信し、前記参照情報を用いて前記リソースへの接続を確立し、該リソースから索出されたコンテンツを出力し、接続確立受諾を指示するユーザ入力を受信すると、第2のユーザ装置への接続を確立することを含むことを特徴とする第1のユーザ装置における方法。

請求項6

請求項5に記載の方法において、該方法は更に、リソースへの参照情報なしで接続確立要求を第2のユーザ装置から受信し、コンテンツを含むリソースへの参照情報を含む更新された接続確立要求を要求し、前記接続確立要求を未確定に維持し、前記更新された接続確立要求を受信した後だけ、該接続確立要求を第1のユーザ装置のユーザに通知することを含むことを特徴とする方法。

請求項7

請求項5または6に記載の方法において、該方法は更に、第2のユーザ装置への接続が確立すると、または前記コンテンツを索出すると、前記リソースへの接続を解放することを含むことを特徴とする方法。

請求項8

請求項5、6または7に記載の方法において、該方法は更に、リソースへの参照情報がない場合、または第2のユーザ装置を用いる第2のユーザが第1のユーザのブロックされた発呼元リストにあってリソースへの参照情報を受信していない場合、または第2のユーザが第1のユーザの連絡先リストになくてリソースへの参照情報を受信していない場合は、前記接続確立要求を拒否することを含むことを特徴とする方法。

請求項9

請求項8に記載の方法において、前記接続確立要求の拒否は婉曲な拒否であり、該接続確立拒否は第2のユーザ装置へ転送されないが、前記接続確立要求は未確定として第2のユーザ装置へ指示されることを特徴とする方法。

請求項10

第1のユーザ装置において、第2のユーザ装置への接続を確立する要求を指示するユーザ入力を検出し、コンテンツを含むリソースへの参照情報を接続確立要求に付加し、前記コンテンツは少なくとも、第1のユーザ装置のユーザに関するリアルタイムもしくは準リアルタイム情報、または該リアルタイムもしくは準リアルタイム情報を用いて導出された情報を含み、前記接続確立要求を送信することを含むことを特徴とする第1のユーザ装置における方法。

請求項11

請求項10に記載の方法において、該方法は更に、前記リソースへの前記参照情報なしで接続確立要求を送信し、リソースへの参照情報を求める要求を受信し、該要求に応答して前記付加を実行し、前記リソースへの前記参照情報なしで前記接続確立要求を送信することを含むことを特徴とする方法。

請求項12

請求項10または11に記載の方法において、該方法は更に、前記コンテンツを仲介するリソースを提供するネットワークノードへの更なる接続を確立し、割り当てられたリソースへの参照情報を受信し、該受信した参照情報を前記接続確立要求に付加し、前記ユーザに関する情報を前記更なる接続を用いて前記リソースへ送信することを含むことを特徴とする方法。

請求項13

前記請求項の何れかに記載の方法において、前記リアルタイムまたは準リアルタイム情報は、取込み後のある期間内で用いられる情報であることを特徴とする方法。

請求項14

前記請求項に記載の方法において、前記ユーザに関するリアルタイムまたは準リアルタイム情報は、該ユーザによって、または前記接続確立要求を送信したユーザ装置を含む該ユーザのユーザ装置のうちの1つによって、生成されることを特徴とする方法。

請求項15

前記請求項に記載の方法において、前記リアルタイムまたは準リアルタイム情報は個人情報を含み、該情報を用いることによって、前記接続確立要求を送信したユーザ装置を用いるユーザを識別可能であることを特徴とする方法。

請求項16

請求項15に記載の方法において、前記リアルタイムまたは準リアルタイム情報はビデオストリームおよび/またはオーディオストリームを含むことを特徴とする方法。

請求項17

装置において実行されると、請求項1ないし16の何れかに記載の方法を実行するように構成されたコンピュータプログラムコードを含むことを特徴とするコンピュータプログラム製品

請求項18

請求項1ないし16の何れかに記載の方法を実現するための手段を含むことを特徴とする装置。

請求項19

請求項18に記載の装置において、該装置は、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む1つのメモリとを含み、前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサによって、請求項1ないし16の何れかに記載の方法を実現する手段を提供するように構成されていることを特徴とする装置。

請求項20

ネットワークと、請求項1ないし4の何れか、および請求項1ないし4の何れかと組み合わせた請求項13ないし16の何れかに記載された方法を実現するための手段を含む2以上のユーザ装置とを含み、前記リアルタイムまたは準リアルタイム情報は、接続確立の目的のために取り込まれ、接続確立を開始したユーザに関する情報を含み、ならびに/または請求項5ないし12の何れか、および請求項5ないし12の何れかと組み合わせた請求項13ないし16の何れかに記載された方法を実現するための手段を含む2以上のユーザ装置を含み、前記参照情報は通信ステムにおけるリソースを指示し、該リソースは、接続確立を開始したユーザに関する前記リアルタイムもしくは準リアルタイム情報、または該リアルタイムもしくは準リアルタイム情報によって前記コンテンツを導出するのに使用される情報もしくは導出されたコンテンツを含み、前記リソースは、前記接続確立を開始したユーザのユーザ装置によって、および/もしくは前記ネットワークにおけるリソースによって提供されることを特徴とする通信システム。

請求項21

請求項20に記載の通信システムにおいて、前記ネットワークはサーバを含み、該サーバは、前記リソースを提供し、および/または前記コンテンツを転送し、および/または該コンテンツを導出するように構成されていることを特徴とする通信システム。

請求項22

請求項21に記載の通信システムにおいて、該システムは、前記サーバを経由して2以上の装置間のシグナリングトラフィックおよびユーザトラフィックを通すように構成され、前記サーバは更に、未確定の接続確立要求についてリソースへの参照情報を求める要求に応答して、前記サーバが既に該リソースを割り当てたか否かを判定し、該リソースが割り当てられていると、該リソースへの参照情報を送信することによって前記要求に応答し、該リソースが割り当てられていないと、前記要求を転送するように構成されていることを特徴とする通信システム。

請求項23

請求項20、21または22に記載の通信システムにおいて、前記リアルタイムまたは準リアルタイム情報は個人情報を含み、該情報を用いることによって、接続確立を開始したユーザを識別可能であることを特徴とする通信システム。

分野

0001

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

背景技術

0002

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

概要

0003

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

0004

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

図面の簡単な説明

0005

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

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

図1では、ユーザ装置110、110'のいくつかのユニットのみが例示されている。ユーザ装置110、110'は、通信のエンドポイントとして作用可能であって1以上のネットワークを通る通信をサポートするどのような種類の演算装置でもよく、ユーザ端末またはユーザ機器またはユーザデバイスと称される。そのようなユーザ装置の例には、ハードウェアまたはソフトウェアとして加入者識別モジュール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には、1つのUCIとして発呼元情報が含まれることがあるが、UCIは、再使用不可リアルタイム情報として、再使用される発呼元情報とは同じにできないことを理解すべきである。発呼者情報ユニット112、112'は、プル方式の原理のみを実現するように構成してもよい。また、ユーザ装置110、110'は、様々なメディアタイプを送信および受信する1以上のアンテナなどの1以上の様々な通信用インタフェースユニット111、111'と、1以上のスクリーンリモートまたは一体型)、1以上のスピーカ(リモートまたは一体型)、1以上のカメラ(リモートまたは一体型)、タッチスクリーン、スイッチ、キーボードバーチャルキーボードマウスジョイスティックセレクタローラチョイスホイーラ、セレクタスイッチドローイングパッドタッチパッドなどの1以上の様々なユーザインタフェースユニットも有している。しかし、それらは、ここでは詳細に例示しない。また、ユーザ装置110、110'は、例えば、連絡先情報を記憶するのに用い得る1以上のメモリ113、113'も有している。また、メモリは、発呼者ユニットの実現例の詳細に応じて、発呼者情報ユニット用の連絡先情報に対応付けられた設定情報および/またはルールおよび/またはプロファイルおよび/または付加情報も有している。例えば、付加情報は、リストにない番号を有するか、もしくはプリペイドアカウントを有するユーザの名前でよく、または付加情報は、「私はテレマーケティング会社xyzの社員です。あなたに雑誌xxxの非常に魅力的な提案をしたくて電話しました」などの発呼した団体および/もしくは理由を記述したテキスト、または地域、気温風速気圧心電図、呼気中アルコール量などの測定データでもよい。設定情報、ルール、プロファイル(プロファイルは1組の設定情報)の様々な例、および付加情報の更なる例を以下に説明するが、それらの例に限られるものではない。

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

図4および図5の例から分かるように、発呼側ユーザ装置が、被呼者側ユーザ装置からの何らかの特定の要求を用いることなく呼確立要求に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を送信する。

0059

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

0060

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

0061

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で受信される。

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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が発呼元情報に対して要求した後のみ送信されるようにしている。

0077

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

0078

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

0079

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

0080

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

0081

メッセージ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にて送信してもよい。そのような場合、サーバが指紋を記憶する必要はない。

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

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

0092

メッセージ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と同じよい。

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ