特許 6758139 効率的な呼処理のためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6758139

(24)【登録日】2020年9月3日

(45)【発行日】2020年9月23日

(54)【発明の名称】効率的な呼処理のためのシステムおよび方法

(51)【国際特許分類】

   H04M 3/00 20060101AFI20200910BHJP

   H04L 12/70 20130101ALI20200910BHJP

【ＦＩ】

   H04M3/00 B

   H04L12/70 A

【請求項の数】8

【全頁数】17

(21)【出願番号】特願2016-185562(P2016-185562)

(22)【出願日】2016年9月23日

(65)【公開番号】特開2017-63421(P2017-63421A)

(43)【公開日】2017年3月30日

【審査請求日】2019年9月13日

(31)【優先権主張番号】10-2015-0136898

(32)【優先日】2015年9月25日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】501333021

【氏名又は名称】ＬＩＮＥ株式会社

(74)【代理人】

【識別番号】110002516

【氏名又は名称】特許業務法人白坂

(74)【代理人】

【識別番号】100185971

【弁理士】

【氏名又は名称】高梨 玲子

(72)【発明者】

【氏名】カク ジョンナム

(72)【発明者】

【氏名】チェ ヒョングク

【審査官】 白川 瑞樹

(56)【参考文献】

【文献】 特開２０１５−１５４３６０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１６／０２４１６０７（ＵＳ，Ａ１）

【文献】 韓国公開特許第１０−２０１５−００４７９７０（ＫＲ，Ａ）

【文献】 特開２０１０−２１２８２５（ＪＰ，Ａ）

【文献】 特開２００８−０６７２２５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ７／２４−７／２６

Ｈ０４Ｌ１２／００−１２／２６

１２／５０−１２／９５５

Ｈ０４Ｍ３／００

３／１６−３／２０

３／３８−３／５８

７／００−７／１６

１１／００−１１／１０

Ｈ０４Ｗ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

発信電子機器で、発信リクエストを生成してＶｏＩＰサーバへ送信する送信手段と、
着信電子機器から発信されたインバイト（ＩＮＶＩＴＥ）リクエストを、前記ＶｏＩＰサーバを通じて前記発信電子機器が受信する受信手段と、
前記発信電子機器において、前記ＶｏＩＰサーバが前記発信電子機器と、前記着信電子機器との間に生成する通話セッションを通じて、前記着信電子機器と通信する通信手段と、を有し、
前記インバイトリクエストは、前記発信リクエストを受信した前記ＶｏＩＰサーバがプッシュサーバを通じて、前記着信電子機器に提供されるプッシュ通知に基づいて、前記着信電子機器から前記ＶｏＩＰサーバに配信されることを特徴とするシステム。

【請求項2】

前記ＶｏＩＰサーバは、前記着信電子機器から前記インバイトリクエストを受信する場合、前記発信電子機器と前記着信電子機器との関係を示すＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成することを特徴とする請求項１に記載のシステム。

【請求項3】

前記ＶｏＩＰサーバは、前記着信電子機器から前記インバイトリクエストを受信する以前に、前記発信電子機器から発信取消リクエストを受信した場合、前記発信リクエストに対応するＳＩＰダイアログを生成せずに、前記プッシュサーバを通じて発信取消メッセージを前記着信電子機器に送信して、前記発信電子機器による発信を取り消すことを特徴とする請求項１又は２に記載のシステム。

【請求項4】

前記ＶｏＩＰサーバは、前記着信電子機器から前記インバイトリクエストを受信する以前に、前記着信電子機器から着信拒絶リクエストを受信した場合、前記発信リクエストに対応するＳＩＰダイアログを生成せずに、前記着信拒絶リクエストを前記発信電子機器に送信して、前記発信電子機器による発信を取り消すことを特徴とする請求項１から３のいずれか１項に記載のシステム。

【請求項5】

発信電子機器が、発信リクエストを生成してＶｏＩＰサーバへ送信する送信ステップと、
前記発信電子機器が、着信電子機器から発信されたインバイト（ＩＮＶＩＴＥ）リクエストを、前記ＶｏＩＰサーバを通じて受信する受信ステップと、
前記発信電子機器が、前記ＶｏＩＰサーバが前記発信電子機器と、前記着信電子機器との間に生成する通話セッションを通じて、前記着信電子機器と通信する通信ステップと、を実行し、
前記インバイトリクエストは、前記発信リクエストを受信した前記ＶｏＩＰサーバがプッシュサーバを通じて、前記着信電子機器に提供されるプッシュ通知に基づいて、前記着信電子機器から前記ＶｏＩＰサーバに配信されることを特徴とする呼処理方法。

【請求項6】

前記ＶｏＩＰサーバが、前記着信電子機器から前記インバイトリクエストを受信する場合、前記発信電子機器と前記着信電子機器との関係を示すＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成する生成ステップを実行することを特徴とする請求項５に記載の呼処理方法。

【請求項7】

前記ＶｏＩＰサーバが、前記着信電子機器から前記インバイトリクエストを受信する以前に、前記発信電子機器から発信取消リクエストを受信した場合、前記発信リクエストに対応するＳＩＰダイアログを生成せずに、前記プッシュサーバを通じて発信取消メッセージを前記着信電子機器に送信して、前記発信電子機器による発信を取り消す取消ステップを実行することを特徴とする請求項５又は６に記載の呼処理方法。

【請求項8】

前記ＶｏＩＰサーバが、前記着信電子機器から前記インバイトリクエストを受信する以前に、前記着信電子機器から着信拒絶リクエストを受信した場合、前記発信リクエストに対応するＳＩＰダイアログを生成せずに、前記着信拒絶リクエストを前記発信電子機器に送信して、前記発信電子機器による発信を取り消す取消ステップを実行することを特徴とする請求項５から７のいずれか１項に記載の呼処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

下記の説明は、効率的な呼処理のためのシステムおよび方法に関する。

【背景技術】

【0002】

ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）環境において通信装置間の連動のために利用されるプロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）では、クライアントが呼び出しを開始すると、サーバ（一例として、ＶｏＩＰサーバまたはＳＩＰサーバ）がその呼び出しに応答をするクライアント／サーバ構造に基盤を置いている。

【0003】

このようなＳＩＰにおいて、発信を希望するすべての発信電子機器それぞれは、サーバにインバイト（ＩＮＶＩＴＥ）をリクエストし、サーバはインバイトリクエストに応じてＳＩＰダイアログ（ｄｉａｌｏｇ）を生成して管理する。このようなＳＩＰダイアログは、一定時間内に存在する２つのＳＩＰユーザエージェント（ＳＩＰ ｕｓｅｒ−ａｇｅｎｔ、発信クライアント、着信クライアント）との関係を示すものであって、発信電子機器と着信電子機器との間のＳＩＰメッセージシーケンス（ＳＩＰ ｍｅｓｓａｇｅ ｓｅｑｕｅｎｃｅ）情報、ＳＩＰリクエストルーティング（ＳＩＰ ｒｅｑｕｅｓｔ ｒｏｕｔｉｎｇ）情報などを管理する。ここで、ＳＩＰユーザエージェントとは、ＳＩＰ処理が可能な装置であって、発信クライアント、着信クライアント、およびＳＩＰサーバがＳＩＰユーザエージェントに該当する。

【0004】

このようなＳＩＰダイアログは、ＳＩＰメッセージを翻訳するためのコンテクスト（ｃｏｎｔｅｘｔ）を含み、それぞれのＳＩＰユーザエージェントは、ダイアログ識別子（ｄｉａｌｏｇ ＩＤ）を利用してＳＩＰダイアログを管理する。ＳＩＰダイアログは、１つ以上のＳＩＰトランザクション（ＳＩＰ ｔｒａｎｓａｃｔｉｏｎ（ＳＩＰｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ））を含む。このようなＳＩＰダイアログを生成するＳＩＰメソッド（ＳＩＰ ｍｅｔｈｏｄ）にはインバイト（ＩＮＶＩＴＥ）とサブスクライブ（ＳＵＢＳＣＲＩＢＥ）があり、インバイトメソッドは通話セッション（ｃａｌｌ ｓｅｓｓｉｏｎ）の生成のために利用される。

【0005】

言い換えれば、ＳＩＰ呼処理を行う装置（発信クライアント、着信クライアント、およびＳＩＰサーバ）は、インバイトリクエストに応じてＳＩＰダイアログを生成して管理し、ＳＩＰダイアログは、終了リクエスト（ＢＹＥ ｒｅｑｕｅｓｔ）またはインバイトエラー応答（ＩＮＶＩＴＥ ｅｒｒｏｒ ｒｅｓｐｏｎｓｅ）のような呼終了メッセージと共に終わる。このとき、それぞれのＳＩＰユーザエージェントは、ＳＩＰダイアログのライフサイクル（ｌｉｆｅ−ｃｙｃｌｅ）中に発生したサブシーケンスＳＩＰリクエストを処理するためにＳＩＰダイアログを管理しなければならない。

【0006】

ＳＩＰにおいて、インバイトリクエストは、ＳＩＰ呼を生成するＳＩＰメソッドであって、従来技術では発信電子機器が発信リクエストのためにインバイトリクエストをＳＩＰサーバに送信し、ＳＩＰサーバが受信したインバイトリクエストを着信電子機器に伝達して呼受信を知らせる。このようなインバイトメッセージは、各ＳＩＰユーザエージェントがＳＩＰダイアログを生成するようにするため、ＳＩＰサーバは呼処理数に比例するＳＩＰダイアログを生成および管理しなければならない。例えば、１秒間に１万回のインバイトリクエストが発生した場合、ＳＩＰサーバは、１秒間に１万個のＳＩＰダイアログを生成および管理しなければならない。したがって、ＳＩＰサーバでは、ＳＩＰダイアログの効率的な管理が性能および容量に大きな影響を及ぼすようになる。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】ＰＣＴ／ＫＲ／２０１４／０１０１６７

【特許文献2】ＵＳ２０１４／００１９５４０Ａ１

【特許文献3】ＵＳ２０１３／０３３２５４３Ａ１

【特許文献4】ＵＳ２０１３／０２６０８９３

【発明の概要】

【発明が解決しようとする課題】

【0008】

着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することで、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができるシステムおよび方法を提供する。

【課題を解決するための手段】

【0009】

発信電子機器で、発信リクエストを生成してＶｏＩＰサーバへ送信する送信手段と、着信電子機器から発信されたインバイト（ＩＮＶＩＴＥ）リクエストを、前記ＶｏＩＰサーバを通じて前記発信電子機器が受信する受信手段と、前記発信電子機器において、前記ＶｏＩＰサーバが前記発信電子機器と、前記着信電子機器との間に生成する通話セッションを通じて、前記着信電子機器と通信する通信手段と、を有し、前記インバイトリクエストは、前記発信リクエストを受信した前記ＶｏＩＰサーバがプッシュサーバを通じて、前記着信電子機器に提供されるプッシュ通知に基づいて、前記着信電子機器から前記ＶｏＩＰサーバに配信されることを特徴とするシステムを提供する。

【0010】

発信電子機器が、発信リクエストを生成してＶｏＩＰサーバへ送信する送信ステップと、前記発信電子機器が、着信電子機器から発信されたインバイト（ＩＮＶＩＴＥ）リクエストを、前記ＶｏＩＰサーバを通じて受信する受信ステップと、前記発信電子機器が、前記ＶｏＩＰサーバが前記発信電子機器と、前記着信電子機器との間に生成する通話セッションを通じて、前記着信電子機器と通信する通信ステップと、を実行し、前記インバイトリクエストは、前記発信リクエストを受信した前記ＶｏＩＰサーバがプッシュサーバを通じて、前記着信電子機器に提供されるプッシュ通知に基づいて、前記着信電子機器から前記ＶｏＩＰサーバに配信されることを特徴とする呼処理方法を提供する。

【発明の効果】

【0012】

着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することにより、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができる。

【図面の簡単な説明】

【0013】

【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。

【図2】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。

【図3】本発明の一実施形態における、ＶｏＩＰサーバのプロセッサが含むことのできる構成要素の例を示した図である。

【図4】本発明の一実施形態における、ＶｏＩＰサーバが実行することのできる呼処理方法の例を示したフローチャートである。

【図5】本発明の一実施形態における、プッシュサーバのプロセッサが含むことのできる構成要素の例を示した図である。

【図6】本発明の一実施形態における、プッシュサーバが実行することのできる呼処理方法の例を示したフローチャートである。

【図7】本発明の一実施形態における、全体システムにおける呼処理工程の例を示した図である。

【図8】本発明の一実施形態における、全体システムにおける発信終了工程の例を示した図である。

【図9】本発明の一実施形態における、全体システムにおける発信取り消し工程の例を示した図である。

【図10】本発明の一実施形態における、全体システムにおける着信拒絶工程の例を示した図である。

【発明を実施するための形態】

【0014】

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

【0015】

図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。

【0016】

複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定型端末や移動型端末であってもよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン（ｓｍａｒｔ ｐｈｏｎｅ）、携帯電話、ナビゲーション、コンピュータ、ノート型パソコン、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットＰＣなどがある。一例として、電子機器１（１１０）は、無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信してもよい。

【0017】

通信方式が制限されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでもよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これに制限されることはない。

【0018】

サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供するコンピュータ装置または複数のコンピュータ装置によって実現されてもよい。

【0019】

一例として、サーバ１６０は、ネットワーク１７０を介して接続した電子機器１（１１０）にアプリケーションのインストールのためのファイルを提供してもよい。この場合、電子機器１（１１０）は、サーバ１６０から提供されたファイルを利用してアプリケーションをインストールしてもよい。また、電子機器１（１１０）が含むオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＯＳ）および少なくとも１つのプログラム（一例として、ブラウザや前記インストールされたアプリケーション）の制御にしたがってサーバ１５０に接続し、サーバ１５０が提供するサービスやコンテンツの提供を受けてもよい。例えば、電子機器１（１１０）がアプリケーションの制御にしたがってネットワーク１７０を介してサービスリクエストメッセージをサーバ１５０に送信すると、サーバ１５０はサービスリクエストメッセージに対応するコードを電子機器１（１１０）に送信してもよく、電子機器１（１１０）はアプリケーションの制御にしたがってコードに基づいた画面を構成して表示することにより、ユーザにコンテンツを提供してもよい。他の例として、サーバ１５０は、メッセージングサービスのための通信セッションを設定し、設定された通信セッションを通じて複数の電子機器１１０、１２０、１３０、１４０間のメッセージ送受信をルーティングしてもよい。

【0020】

特に、本発明の実施形態において、サーバ１５０は、発信電子機器としての電子機器１（１１０）と着信電子機器としての電子機器２（１２０）との間の呼処理を実行するＶｏＩＰサーバ（またはＳＩＰサーバ）であってもよく、サーバ１６０は、発信リクエストに対応する着信電子機器である電子機器２（１２０）にプッシュ通知を伝達するプッシュサーバであってもよい。

【0021】

図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、１つの電子機器に対する例として電子機器１（１１０）を、１つのサーバに対する例としてサーバ１５０の内部構成を説明する。他の電子機器１２０、１３０、１４０やサーバ１６０も、同一または類似の内部構成を備えてもよい。

【0022】

電子機器１（１１０）とサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでもよい。メモリ２１１、２２１は、コンピュータで読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永久大容量記憶装置（ｐｅｒｍａｎｅｎｔ ｍａｓｓ ｓｔｏｒａｇｅ ｄｅｖｉｃｅ）を含んでよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電気機器１（１１０）にインストールされ駆動するブラウザや上述したアプリケーションなどのためのコード）が格納されてよい。このようなソフトウェア構成要素は、ドライブメカニズム（ｄｒｉｖｅ ｍｅｃｈａｎｉｓｍ）を利用してメモリ２１１、２２１とは別のコンピュータで読み取り可能な記録媒体からロードされてもよい。このような別のコンピュータで読み取り可能な記録媒体は、フロッピーディスク、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭ、メモリカードなどのコンピュータで読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータで読み取り可能な記録媒体ではない通信モジュール２１３、２２３を利用してメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてもよい。

【0023】

プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に格納されたプログラムコードにしたがって受信される命令を実行するように構成されてもよい。

【0024】

通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に格納されたプログラムコードにしたがって生成したリクエスト（一例として、コンテンツに対するストリーミングサービスリクエスト）が、通信モジュール２１３の制御にしたがってネットワーク１７０を介してサーバ１５０に伝達されてもよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御にしたがって提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてもよい。例えば、通信モジュール２１３を通じて受信されたサーバ１５０の制御信号や命令などはプロセッサ２１２やメモリ２１１に伝達されてもよく、コンテンツやファイルなどは電子機器１（１１０）がさらに含むことのできる格納媒体に格納されてもよい。

【0025】

入力／出力インタフェース２１４、２２４は、入力／出力装置２１５とのインタフェースのための手段であってもよい。例えば、入力装置は、マイクロフォン、キーボード、またはマウスなどの装置を、また出力装置はアプリケーションの通信セッションを表示するためのディスプレイやスピーカのような装置を含んでもよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２は、メモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが、入力／出力インタフェース２１４を通じてディスプレイに表示されてもよい。

【0026】

また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりもさらに多くの構成要素を含んでもよい。しかし、大部分の従来技術の構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ（ｔｒａｎｓｃｅｉｖｅｒ）、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。

【0027】

図３は、本発明の一実施形態における、ＶｏＩＰサーバのプロセッサが含むことのできる構成要素の例を示した図であり、図４は、本発明の一実施形態における、ＶｏＩＰサーバが実行することのできる呼処理方法の例を示したフローチャートである。

【0028】

本実施形態において、サーバ１５０は、ＶｏＩＰサーバ（またはＳＩＰサーバ）に対応してもよく、サーバ１５０のプロセッサ２２２は、送受信制御部３１０、プッシュリクエスト制御部３２０、および通話管理制御部３３０を備えてもよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図４の呼処理方法が含むステップ４１０〜ステップ４５０を実行するようにサーバ１５０を制御してもよい。例えば、プロセッサ２２２およびプロセッサ２２２の構成要素は、サーバ１５０のメモリ２２１が含むオペレーティングシステムのコードと少なくとも１つのプログラムコードによる命令を実行するように実現されてもよい。

【0029】

ステップ４１０で、プロセッサ２２２は、呼処理方法のためのプログラムファイルに格納されたプログラムコードをメモリ２２１にロードしてもよい。例えば、サーバ１５０には、プログラムファイルにしたがってプログラムがインストール（ｉｎｓｔａｌｌ）されてもよい。このとき、サーバ１５０にインストールされたプログラムが実行される場合、プロセッサ２２２は、プログラムコードをメモリ２２１にロードしてもよい。ここで、プロセッサ２２２が備える送受信制御部３１０、プッシュリクエスト制御部３２０、および通話管理制御部３３０それぞれは、メモリ２２１にロードされたプログラムコードのうち対応するコードによる命令を実行して以後のステップ４２０〜ステップ４５０を実行するように実現されてもよい。

【0030】

以下で、プロセッサ２２２の構成要素がサーバ１５０を制御することは、プロセッサ２２２がサーバ１５０の他の構成要素を制御するものと理解されてもよい。例えば、プロセッサ２２２は、サーバ１５０が含む通信モジュール２２３を制御してサーバ１５０が電子機器（一例として、電子機器１（１１０））や他のサーバ（一例として、サーバ１６０）と通信するようにサーバ１５０を制御してもよい。

【0031】

ステップ４２０で、送受信制御部３１０は、発信電子機器から発信リクエストを受信するようにサーバ１５０を制御してもよい。従来技術に係るＳＩＰでは、発信をリクエストする工程で、ＳＩＰダイアログの生成と通話セッション（ｃａｌｌ ｓｅｓｓｉｏｎ）の生成のためにインバイトリクエストをＶｏＩＰサーバ（または、ＳＩＰサーバ）に送信していたが、本発明の実施形態では、このようなインバイトリクエストのための工程は省略されてもよい。

【0032】

ステップ４３０で、プッシュリクエスト制御部３２０は、発信リクエストに対応する着信電子機器にプッシュ通知を提供することをプッシュサーバにリクエストするようにサーバ１５０を制御してもよい。例えば、発信リクエストは、着信電子機器を識別するための情報を含んでもよく、サーバ１５０は、このような情報に基づいてプッシュサーバに着信電子機器へのプッシュ通知の提供をリクエストしてもよい。プッシュサーバは、このようなリクエストに応じてプッシュ通知を着信電子機器に提供してもよい。例えば、着信電子機器には、プッシュサーバと関連するアプリケーションがインストールされていてもよい。このとき、プッシュサーバは、リクエストにしたがい、プッシュ通知を着信電子機器にインストールされたアプリケーションを通じて着信電子機器にプッシュしてもよい。着信電子機器にインストールされたアプリケーションは、発信電子機器にも同じようにインストールされてもよく、発信電子機器と着信電子機器はこのようなアプリケーションを通じて通話を処理してもよい。

【0033】

ステップ４４０で、通話管理制御部３３０は、発信取消リクエストの受信の可否を確認してもよい。例えば、通話管理制御部３３０は、インバイトリクエストを受信する以前に発信電子機器から発信取消リクエストが受信されたか否かを確認してもよい。発信取消リクエストが受信された場合にはステップ４５０が実行されてもよく、発信取消リクエストが受信されていない場合にはステップ４６０が実行されてもよい。

【0034】

ステップ４５０で、通話管理制御部３３０は、インバイトリクエストを受信する以前に発信電子機器から発信取消リクエストが受信された場合、発信リクエストに対応するＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成せずに発信を取り消してもよい。発信が取り消された場合、図４の呼処理方法は終了されてもよい。

【0035】

ステップ４６０で、通話管理制御部３３０は、着信拒絶リクエストの受信の可否を確認してもよい。例えば、通話管理制御部３３０は、インバイトリクエストを受信する以前に着信電子機器から着信拒絶リクエストが受信されたか否かを確認してもよい。着信拒絶リクエストが受信された場合にはステップ４７０が実行されてもよく、着信拒絶リクエストが受信されていない場合にはステップ４８０が実行されてもよい。

【0036】

ステップ４７０で、通話管理制御部３３０は、インバイトリクエストを受信する以前に着信電子機器から着信拒絶リクエストが受信された場合、発信リクエストに対応するＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成せずに発信を取り消してもよい。発信が終了された場合、図４の呼処理方法は終了されてもよい。

【0037】

言い換えれば、ステップ４４０およびステップ４５０は、発信電子機器から発信取消リクエストが受信された場合に実行されてもよく、ステップ４６０およびステップ４７０は、着信電子機器から着信拒絶リクエストが受信された場合に実行されてもよい。したがって、発信取消リクエストや着信拒絶リクエストが受信されなかった場合、ステップ４３０以後にはステップ４８０が実行されてもよい。

【0038】

ステップ４８０で、送受信制御部３１０は、着信電子機器からプッシュ通知に基づいて送信されたインバイト（ＩＮＶＩＴＥ）リクエストを受信するようにサーバ１５０を制御してもよい。このようなインバイトリクエストは、着信電子機器が着信に応答する場合に着信電子機器で生成されてサーバ１５０に送信されてもよい。

【0039】

ステップ４９０で、通話管理制御部３３０は、インバイトリクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ ｓｅｓｓｉｏｎ）を生成してもよい。また、通話管理制御部３３０は、着信電子機器からインバイトリクエストを受信することによって発信電子機器にインバイトリクエストを送信するようにサーバ１５０を制御してもよい。このとき、発信電子機器がサーバ１５０からのインバイトリクエストに基づいて通話セッションに連結されてもよい。さらに、通話管理制御部３３０は、着信電子機器からインバイトリクエストを受信することによってＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成して管理してもよい。

【0040】

また、図４の呼処理方法は、インバイトリクエストの受信にしたがってＳＩＰダイアログ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｉａｌｏｇ）を生成して管理するステップ（図示せず）を、ステップ４９０以後またはステップ４９０以前にさらに含んでもよい。このような図に示されていないステップは、通話管理制御部３３０によって実行されてもよい。

【0041】

このように、本発明の実施形態では、着信電子機器が着信に応答した場合にだけインバイトリクエストを生成することができる。したがって、サーバ１５０は、すべての発信リクエストに対してインバイトリクエストを生成する必要がないため、サーバ１５０が生成しなければならないＳＩＰダイアログの数を画期的に減少させることができる。例えば、発信リクエストに対して着信応答が発生する割合が５０％であれば、サーバ１５０が生成しなければならないＳＩＰダイアログの数は半減するようになり、これによってサーバ１５０の性能と容量を大きく向上させることができる。

【0042】

発信電子機器がインバイトリクエストをサーバ１５０に伝達しなくとも、サーバ１５０は、プッシュサーバからのプッシュ通知の送信によって呼リクエストを着信電子機器に伝達することができる。

【0043】

図５は、本発明の一実施形態における、プッシュサーバのプロセッサが含むことのできる構成要素の例を示した図であり、図６は、本発明の一実施形態における、プッシュサーバが実行することのできる呼処理方法の例を示したフローチャートである。

【0044】

本実施形態において、サーバ１６０は、プッシュサーバに対応してもよく、サーバ１６０のプロセッサ５１０は、リクエスト受信制御部５１１およびプッシュ通知送信制御部５１２を備えてもよい。このようなプロセッサ５１０およびプロセッサ５１０の構成要素は、図６の呼処理方法が含むステップ６１０〜ステップ６３０を実行するようにサーバ１６０を制御してもよい。例えば、プロセッサ５１０およびプロセッサ５１０の構成要素は、サーバ１６０のメモリ（図示せず）が含むオペレーティングシステムのコードと少なくとも１つのプログラムコードによる命令を実行するように実現されてもよい。

【0045】

ステップ６１０で、プロセッサ５１０は、呼処理方法のためのプログラムファイルに格納されたプログラムコードをサーバ１６０のメモリにロードしてもよい。例えば、サーバ１６０には、プログラムファイルにしたがってプログラムがインストール（ｉｎｓｔａｌｌ）されてもよい。ここで、サーバ１６０にインストールされたプログラムが実行される場合、プロセッサ５１０は、プログラムコードをメモリにロードしてもよい。このとき、プロセッサ５１０が備えるリクエスト受信制御部５１１およびプッシュ通知送信制御部５１２それぞれは、メモリにロードされたプログラムコードのうち対応するコードによる命令を実行して以後のステップ６２０およびステップ６３０を実行するように実現されてもよい。

【0046】

ステップ６２０で、リクエスト受信制御部５１１は、ＶｏＩＰサーバからプッシュ通知リクエストを受信するようにサーバ１６０を制御してもよい。このとき、プッシュ通知リクエストは、ＶｏＩＰサーバで発信電子機器からの発信リクエストに応じて発信リクエストに対応する着信電子機器に対して生成されてもよい。

【0047】

ステップ６３０で、プッシュ通知送信制御部５１２は、プッシュ通知リクエストに応答して着信電子機器にプッシュ通知を送信するようにサーバ１６０を制御してもよい。このとき、着信電子機器でプッシュ通知に基づいてインバイトリクエストをＶｏＩＰサーバに送信してもよく、ＶｏＩＰサーバでインバイトリクエストに応じて発信電子機器と着信電子機器との間の通話セッション（ｃａｌｌ ｓｅｓｓｉｏｎ）を生成してもよい。

【0048】

上述したように、サーバ１６０と関連するアプリケーションが着信電子機器にインストールされてもよく、プッシュ通知は、このようなアプリケーションを通じて着信電子機器にプッシュされてもよい。

【0049】

以下では、より具体的な実施例を参照しながら、本発明の実施形態に係る呼処理工程について説明する。

【0050】

図７は、本発明の一実施形態における、全体システムにおける呼処理工程の例を示した図である。ここで、図７は、発信電子機器７１０、ＶｏＩＰサーバ７２０、プッシュサーバ７３０、および着信電子機器７４０間のメッセージ送受信工程の例を示している。

【0051】

１．ｓｅｔｕｐ工程は、発信電子機器７１０上で発信リクエスト７５０が発生されることにより、発信電子機器７１０がＶｏＩＰサーバ７２０に発信リクエストを送信する工程であってもよい。

【0052】

２．ｒｅｑ．ＰＵＳＨ工程は、ＶｏＩＰサーバ７２０が受信した発信リクエストに対応する着信電子機器７４０にプッシュ通知を送信するようにプッシュサーバ７３０にリクエストする工程であってもよい。

【0053】

３．ＰＵＳＨ通知工程は、プッシュサーバ７３０がＶｏＩＰサーバ７２０のリクエストに応じて着信電子機器７４０にプッシュ通知を提供する工程であってもよい。

【0054】

４．ｒｓｐ．ＰＵＳＨ工程は、プッシュサーバ７３０がＶｏＩＰサーバ７２０のリクエストを処理したことをＶｏＩＰサーバ７２０に知らせるための応答工程であってもよい。

【0055】

５．２００ ＯＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０のリクエストを処理したことを発信電子機器７１０に知らせるための応答工程であってもよい。ここで、「２００ ＯＫ」とは、ＳＩＰで定義された応答メッセージであり、既に広く知られている。

【0056】

このとき、着信電子機器７４０がプッシュ通知にしたがって着信登録７６０を処理しようとする場合、６．ｒｅｇ工程が実行されてもよい。

【0057】

６．ｒｅｇ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に自身を登録する工程であってもよい。このような登録は、着信電子機器７４０がＶｏＩＰサーバ７２０に自身の存在を知らせるものに過ぎず、ＶｏＩＰサーバ７２０は、ＳＩＰダイアログがまだ生成されていないため、発信電子機器７１０と着信電子機器７４０との関係を知ることはできない。

【0058】

７．２００ ＯＫ工程は、ＶｏＩＰサーバ７２０が着信電子機器７４０の登録が処理されたことを着信電子機器７４０に知らせるための応答工程であってもよい。

【0059】

このとき、着信電子機器７４０が着信応答７７０を処理しようとする場合、８．ＩＮＶＩＴＥ工程が実行されてもよい。

【0060】

８．ＩＮＶＩＴＥ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０にインバイトリクエストを送信する工程であってもよい。このとき、ＶｏＩＰサーバ７２０は、インバイトリクエストに基づいてＳＩＰダイアログを生成および管理してもよい。

【0061】

９．ＩＮＶＩＴＥ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０にインバイトリクエストを送信する工程であってもよい。一例として、ＶｏＩＰサーバ７２０は、着信電子機器７４０が送信したインバイトリクエストを発信電子機器７１０に伝達してもよい。

【0062】

１０．２００ ＯＫ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０にインバイトリクエストに対する応答を送信する応答工程であってもよい。

【0063】

１１．２００ ＯＫ工程は、ＶｏＩＰサーバ７２０が着信電子機器７４０にインバイトリクエストに対する応答を送信する応答工程であってもよい。

【0064】

１２．ＡＣＫ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に応答を送信する応答工程であってもよい。

【0065】

１３．ＡＣＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に応答を送信する応答工程であってもよい。

【0066】

このような工程により、発信電子機器７１０と着信電子機器７４０は、ＶｏＩＰサーバ７２０がインバイトリクエストに基づいて生成した通話セッションに連結されてもよく、互いに通話を行うことができるようになる。

【0067】

着信応答７７０にしたがって着信電子機器７４０からインバイトリクエストが受信されなければ、ＳＩＰダイアログが生成されないため、多数の発信リクエストを考慮したとき、ＶｏＩＰサーバ７２０の性能を大きく向上させることができる。

【0068】

図８は、本発明の一実施形態における、全体システムにおける発信終了工程の例を示した図である。図８は、図７において発信電子機器７１０と着信電子機器７４０との間の通話が行われる工程以後に、発信電子機器７１０から通話終了８１０がリクエストされた場合の工程について説明する。

【0069】

１４．ＢＹＥ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０に発信終了メッセージを送信する工程であってもよい。「ＢＹＥ」とは、ＳＩＰで定義された終了メッセージであり、既に広く知られている。

【0070】

１５．ＢＹＥ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０から受信した終了メッセージを着信電子機器７４０に伝達する工程であってもよい。

【0071】

１６．２００ ＯＫ工程は、着信電子機器７４０が終了メッセージの受信による応答をＶｏＩＰサーバ７２０に送信する応答工程であってもよい。

【0072】

１７．２００ ＯＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に応答を送信する応答工程であってもよい。

【0073】

このような工程の後、発信電子機器７１０と着信電子機器７４０との間の通話が終了されてもよい。着信電子機器７４０上から先に通話終了がリクエストされると、着信電子機器７４０は、ＶｏＩＰサーバ７２０に終了メッセージを送信してもよく、ＶｏＩＰサーバ７２０を通じて終了メッセージが発信電子機器７１０に送信されて通話が終了されてもよい。

【0074】

図９は、本発明の一実施形態における、全体システムにおける発信取消工程の例を示した図である。図９は、図７において、着信登録７６０によって７．２００ ＯＫ工程まで進んだ後に、発信電子機器７１０上で発信取消９１０がリクエストされた場合の実施形態について説明する。

【0075】

８．ｃａｎｃｅｌ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０に発信取消メッセージを送信する工程であってもよい。

【0076】

９．ｃａｎｃｅｌ工程は、ＶｏＩＰサーバ７２０がプッシュサーバ７３０に発信取消メッセージを伝達する工程であってもよい。

【0077】

１０．ｃａｎｃｅｌ工程は、プッシュサーバ７３０が着信電子機器７４０に発信取消メッセージを伝達する工程であってもよい。

【0078】

言い換えれば、ＶｏＩＰサーバ７２０は、インバイトリクエストを受信しておらず、ＳＩＰダイアログを生成していなかった。このような場合に発信が取り消されたため、ＶｏＩＰサーバ７２０は、プッシュサーバ７３０を通じて発信取消メッセージを着信電子機器７４０に送信することができる。

【0079】

１１．２００ ＯＫ工程、１２．２００ ＯＫ工程、および１３．２００ ＯＫ工程は、着信電子機器７４０の応答をプッシュサーバ７３０およびＶｏＩＰサーバ７２０を通じて発信電子機器７１０に伝達する工程であってもよい。

【0080】

このように、発信が取り消された場合にはインバイトリクエストが発生せず、これによってＳＩＰダイアログも生成されないことが分かる。

【0081】

図１０は、本発明の一実施形態における、全体システムにおける着信拒絶工程の例を示した図である。図１０は、図７において、着信登録７６０によって７．２００ ＯＫ工程まで進んだ後に、着信電子機器７４０上で着信拒絶１０１０リクエストが発生した場合の例を示している。

【0082】

８．ｒｅｊｅｃｔ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に着信拒絶メッセージを送信する工程であってもよい。

【0083】

９．ｒｅｊｅｃｔ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に着信拒絶メッセージを伝達する工程であってもよい。

【0084】

１０．２００ ＯＫ工程および１１．２００ ＯＫ工程は、発信電子機器７１０の応答がＶｏＩＰサーバ７２０を通じて着信電子機器７４０に伝達される工程であってもよい。

【0085】

このように、着信が拒絶された場合にもインバイトリクエストが発生せず、これによってＳＩＰダイアログも生成されないことが分かる。

【0086】

このように、本発明の実施形態によると、着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することにより、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができる。

【0087】

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてもよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてもよい。処理装置は、オペレーティングシステム（ＯＳ）および前記ＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してもよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してもよい。便宜的な理解のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。

【0088】

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供するために、いかなる種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｎｔ）、コンピュータ格納媒体または装置、または送信される信号波（ｓｉｇｎａｌ ｗａｖｅ）に永久的または一時的に具現化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された方法によって格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。

【0089】

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでもよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の例としては、ハードディスク、フロッピーディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして動作するように構成されてもよく、その逆も同じである。

【0090】

以上のように、実施形態を限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能である。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、および／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

【0091】

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

【符号の説明】

【0092】

１１０、１２０、１３０、１４０：電子機器
１５０、１６０：サーバ
１７０：ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】