(57)【要約】【課題】効率的な呼処理のためのシステムおよび方法を提供する。【解決手段】コンピュータによって実現されるサーバのシステムは、コンピュータで読み取り可能な命令を格納するメモリ、および前記命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、発信電子機器の発信リクエストに対応する着信電子機器にプッシュ通知を提供することをプッシュサーバにリクエストするように前記サーバを制御するプッシュリクエスト制御部、および前記プッシュ通知に基づいて前記着信電子機器から送信されたインバイト（ＩＮＶＩＴＥ）リクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成するように前記サーバを制御する通話管理制御部を備えてもよい。【選択図】図１
2020198636.tif 000002
【特許請求の範囲】
【請求項１】
ＶｏＩＰサーバを、
発信電子機器が生成した発信リクエストを受信する手段と、
前記発信リクエストに応じて、着信電子機器にプッシュサーバを介してプッシュ通知を送信する手段と、
前記プッシュ通知を受信した着信電子機器から受信するインバイトリクエストに基づいた情報を前記発信電子機器に送信する手段と、
前記発信電子機器と前記着信電子機器との間の通話セッションを生成する手段と、
して機能させるコンピュータプログラム。
【請求項２】
発信電子機器を、
発信リクエストを生成してＶｏＩＰサーバに送信する手段と、
着信電子機器から送信されたインバイトリクエストであって、前記発信リクエストを受信した前記ＶｏＩＰサーバからプッシュサーバを介して前記着信電子機器に提供されるプッシュ通知に基づいて、前記着信電子機器から前記ＶｏＩＰサーバに送信されるリクエストを、前記ＶｏＩＰサーバを介して受信する手段と、
前記ＶｏＩＰサーバが前記発信電子機器と前記着信電子機器との間に生成した通話セッションを介して前記着信電子機器と通信する手段と、
して機能させるコンピュータプログラム。
【請求項３】
着信電子機器を、
プッシュサーバからのプッシュ通知であって、発信電子機器からの発信リクエストに応じたＶｏＩＰサーバの前記プッシュサーバへのリクエストに応じて、前記プッシュサーバから前記着信電子機器に提供されるプッシュ通知を受信する手段と、
受信した前記プッシュ通知に基づいて、前記ＶｏＩＰサーバにインバイトリクエストを送信する手段と、
前記ＶｏＩＰサーバが前記インバイトリクエストに基づいて前記発信電子機器と前記着信電子機器との間に生成した通話セッションを介して、前記発信電子機器と通信する手段と、
して機能させるコンピュータプログラム。
【請求項４】
請求項１乃至３のいずれか一項に記載のコンピュータプログラムであって、
前記発信リクエストには、前記インバイトリクエストが含まれていないことを特徴とするコンピュータプログラム。
【請求項５】
請求項１乃至３のいずれか一項に記載のコンピュータプログラムであって、
前記ＶｏＩＰサーバは、
前記着信電子機器から前記インバイトリクエストを受信することによってＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を作成して管理するように実装されることを特徴とするコンピュータプログラム。
【請求項６】
請求項１乃至３のいずれか一項に記載のコンピュータプログラムであって、
前記ＶｏＩＰサーバは、
前記着信電子機器から前記インバイトリクエストを受信する以前に、前記発信電子機器から発信取消リクエストを受信、または、前記着信電子機器から着信拒絶リクエストを受信した場合、前記発信リクエストに対応するＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を生成せずに発信を取り消すように実装されていることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
下記の説明は、効率的な呼処理のためのシステムおよび方法に関する。
【背景技術】
【０００２】
ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）環境において通信装置間の連動のために利用されるプロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）では、クライアントが呼び出しを開始すると、サーバ（一例として、ＶｏＩＰサーバまたはＳＩＰサーバ）がその呼び出しに応答をするクライアント／サーバ構造に基盤を置いている。
【０００３】
このようなＳＩＰにおいて、発信を希望するすべての発信電子機器それぞれは、サーバにインバイト（ＩＮＶＩＴＥ）をリクエストし、サーバはインバイトリクエストに応じてＳＩＰダイアログ（ｄｉａｌｏｇ）を生成して管理する。このようなＳＩＰダイアログは、一定時間内に存在する２つのＳＩＰユーザエージェント（ＳＩＰ  ｕｓｅｒ−ａｇｅｎｔ、発信クライアント、着信クライアント）との関係を示すものであって、発信電子機器と着信電子機器との間のＳＩＰメッセージシーケンス（ＳＩＰ  ｍｅｓｓａｇｅ  ｓｅｑｕｅｎｃｅ）情報、ＳＩＰリクエストルーティング（ＳＩＰ  ｒｅｑｕｅｓｔ  ｒｏｕｔｉｎｇ）情報などを管理する。ここで、ＳＩＰユーザエージェントとは、ＳＩＰ処理が可能な装置であって、発信クライアント、着信クライアント、およびＳＩＰサーバがＳＩＰユーザエージェントに該当する。
【０００４】
このようなＳＩＰダイアログは、ＳＩＰメッセージを翻訳するためのコンテクスト（ｃｏｎｔｅｘｔ）を含み、それぞれのＳＩＰユーザエージェントは、ダイアログ識別子（ｄｉａｌｏｇ  ＩＤ）を利用してＳＩＰダイアログを管理する。ＳＩＰダイアログは、１つ以上のＳＩＰトランザクション（ＳＩＰ  ｔｒａｎｓａｃｔｉｏｎ（ＳＩＰｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ））を含む。このようなＳＩＰダイアログを生成するＳＩＰメソッド（ＳＩＰ  ｍｅｔｈｏｄ）にはインバイト（ＩＮＶＩＴＥ）とサブスクライブ（ＳＵＢＳＣＲＩＢＥ）があり、インバイトメソッドは通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）の生成のために利用される。
【０００５】
言い換えれば、ＳＩＰ呼処理を行う装置（発信クライアント、着信クライアント、およびＳＩＰサーバ）は、インバイトリクエストに応じてＳＩＰダイアログを生成して管理し、ＳＩＰダイアログは、終了リクエスト（ＢＹＥ  ｒｅｑｕｅｓｔ）またはインバイトエラー応答（ＩＮＶＩＴＥ  ｅｒｒｏｒ  ｒｅｓｐｏｎｓｅ）のような呼終了メッセージと共に終わる。このとき、それぞれのＳＩＰユーザエージェントは、ＳＩＰダイアログのライフサイクル（ｌｉｆｅ−ｃｙｃｌｅ）中に発生したサブシーケンスＳＩＰリクエストを処理するためにＳＩＰダイアログを管理しなければならない。
【０００６】
ＳＩＰにおいて、インバイトリクエストは、ＳＩＰ呼を生成するＳＩＰメソッドであって、従来技術では発信電子機器が発信リクエストのためにインバイトリクエストをＳＩＰサーバに送信し、ＳＩＰサーバが受信したインバイトリクエストを着信電子機器に伝達して呼受信を知らせる。このようなインバイトメッセージは、各ＳＩＰユーザエージェントがＳＩＰダイアログを生成するようにするため、ＳＩＰサーバは呼処理数に比例するＳＩＰダイアログを生成および管理しなければならない。例えば、１秒間に１万回のインバイトリクエストが発生した場合、ＳＩＰサーバは、１秒間に１万個のＳＩＰダイアログを生成および管理しなければならない。したがって、ＳＩＰサーバでは、ＳＩＰダイアログの効率的な管理が性能および容量に大きな影響を及ぼすようになる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】ＰＣＴ／ＫＲ／２０１４／０１０１６７
【特許文献２】ＵＳ２０１４／００１９５４０Ａ１
【特許文献３】ＵＳ２０１３／０３３２５４３Ａ１
【特許文献４】ＵＳ２０１３／０２６０８９３
【発明の概要】
【発明が解決しようとする課題】
【０００８】
着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することで、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができるシステムおよび方法を提供する。
【課題を解決するための手段】
【０００９】
コンピュータによって実現されるサーバのシステムであって、コンピュータで読み取り可能な命令を格納するメモリ、および前記命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、発信電子機器の発信リクエストに対応する着信電子機器にプッシュ通知を提供することをプッシュサーバにリクエストするように前記サーバを制御するプッシュリクエスト制御部、および前記プッシュ通知に基づいて前記着信電子機器から送信されたインバイト（ＩＮＶＩＴＥ）リクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成するように前記サーバを制御する通話管理制御部を備えることを特徴とする、システムを提供する。
【００１０】
コンピュータによって実現されるサーバのシステムであって、コンピュータで読み取り可能な命令を格納するメモリ、および前記命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、ＶｏＩＰサーバから、前記ＶｏＩＰサーバで発信電子機器からの発信リクエストに応じて前記発信リクエストに対応する着信電子機器に対して生成されるプッシュ通知リクエストを受信するように前記サーバを制御するリクエスト受信制御部、および前記プッシュ通知リクエストに応答して前記着信電子機器にプッシュ通知を送信するように前記サーバを制御するプッシュ通知送信制御部を備え、前記着信電子機器で前記プッシュ通知に基づいてインバイトリクエストを前記ＶｏＩＰサーバに送信し、前記ＶｏＩＰサーバで前記インバイトリクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成することを特徴とする、システムを提供する。
【００１１】
呼処理方法であって、ＶｏＩＰサーバで発信電子機器から発信リクエストを受信するステップ、前記ＶｏＩＰサーバで前記発信リクエストに対応する着信電子機器にプッシュ通知を提供することをプッシュサーバにリクエストするステップ、前記ＶｏＩＰサーバで前記着信電子機器から前記プッシュ通知に基づいて送信されたインバイト（ＩＮＶＩＴＥ）リクエストを受信するステップ、および前記ＶｏＩＰサーバで前記インバイトリクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成するステップを含むことを特徴とする、呼処理方法を提供する。
【発明の効果】
【００１２】
着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することにより、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図２】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。
【図３】本発明の一実施形態における、ＶｏＩＰサーバのプロセッサが含むことのできる構成要素の例を示した図である。
【図４】本発明の一実施形態における、ＶｏＩＰサーバが実行することのできる呼処理方法の例を示したフローチャートである。
【図５】本発明の一実施形態における、プッシュサーバのプロセッサが含むことのできる構成要素の例を示した図である。
【図６】本発明の一実施形態における、プッシュサーバが実行することのできる呼処理方法の例を示したフローチャートである。
【図７】本発明の一実施形態における、全体システムにおける呼処理工程の例を示した図である。
【図８】本発明の一実施形態における、全体システムにおける発信終了工程の例を示した図である。
【図９】本発明の一実施形態における、全体システムにおける発信取り消し工程の例を示した図である。
【図１０】本発明の一実施形態における、全体システムにおける着信拒絶工程の例を示した図である。
【発明を実施するための形態】
【００１４】
以下、実施形態について、添付の図面を参照しながら詳しく説明する。
【００１５】
図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。
【００１６】
複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定型端末や移動型端末であってもよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン（ｓｍａｒｔ  ｐｈｏｎｅ）、携帯電話、ナビゲーション、コンピュータ、ノート型パソコン、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｐｌａｙｅｒ）、タブレットＰＣなどがある。一例として、電子機器１（１１０）は、無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信してもよい。
【００１７】
通信方式が制限されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ  ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでもよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これに制限されることはない。
【００１８】
サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供するコンピュータ装置または複数のコンピュータ装置によって実現されてもよい。
【００１９】
一例として、サーバ１６０は、ネットワーク１７０を介して接続した電子機器１（１１０）にアプリケーションのインストールのためのファイルを提供してもよい。この場合、電子機器１（１１０）は、サーバ１６０から提供されたファイルを利用してアプリケーションをインストールしてもよい。また、電子機器１（１１０）が含むオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ：ＯＳ）および少なくとも１つのプログラム（一例として、ブラウザや前記インストールされたアプリケーション）の制御にしたがってサーバ１５０に接続し、サーバ１５０が提供するサービスやコンテンツの提供を受けてもよい。例えば、電子機器１（１１０）がアプリケーションの制御にしたがってネットワーク１７０を介してサービスリクエストメッセージをサーバ１５０に送信すると、サーバ１５０はサービスリクエストメッセージに対応するコードを電子機器１（１１０）に送信してもよく、電子機器１（１１０）はアプリケーションの制御にしたがってコードに基づいた画面を構成して表示することにより、ユーザにコンテンツを提供してもよい。他の例として、サーバ１５０は、メッセージングサービスのための通信セッションを設定し、設定された通信セッションを通じて複数の電子機器１１０、１２０、１３０、１４０間のメッセージ送受信をルーティングしてもよい。
【００２０】
特に、本発明の実施形態において、サーバ１５０は、発信電子機器としての電子機器１（１１０）と着信電子機器としての電子機器２（１２０）との間の呼処理を実行するＶｏＩＰサーバ（またはＳＩＰサーバ）であってもよく、サーバ１６０は、発信リクエストに対応する着信電子機器である電子機器２（１２０）にプッシュ通知を伝達するプッシュサーバであってもよい。
【００２１】
図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、１つの電子機器に対する例として電子機器１（１１０）を、１つのサーバに対する例としてサーバ１５０の内部構成を説明する。他の電子機器１２０、１３０、１４０やサーバ１６０も、同一または類似の内部構成を備えてもよい。
【００２２】
電子機器１（１１０）とサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでもよい。メモリ２１１、２２１は、コンピュータで読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、およびディスクドライブのような永久大容量記憶装置（ｐｅｒｍａｎｅｎｔ  ｍａｓｓ  ｓｔｏｒａｇｅ  ｄｅｖｉｃｅ）を含んでよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電気機器１（１１０）にインストールされ駆動するブラウザや上述したアプリケーションなどのためのコード）が格納されてよい。このようなソフトウェア構成要素は、ドライブメカニズム（ｄｒｉｖｅ  ｍｅｃｈａｎｉｓｍ）を利用してメモリ２１１、２２１とは別のコンピュータで読み取り可能な記録媒体からロードされてもよい。このような別のコンピュータで読み取り可能な記録媒体は、フロッピーディスク、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭ、メモリカードなどのコンピュータで読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータで読み取り可能な記録媒体ではない通信モジュール２１３、２２３を利用してメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてもよい。
【００２３】
プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に格納されたプログラムコードにしたがって受信される命令を実行するように構成されてもよい。
【００２４】
通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に格納されたプログラムコードにしたがって生成したリクエスト（一例として、コンテンツに対するストリーミングサービスリクエスト）が、通信モジュール２１３の制御にしたがってネットワーク１７０を介してサーバ１５０に伝達されてもよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御にしたがって提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてもよい。例えば、通信モジュール２１３を通じて受信されたサーバ１５０の制御信号や命令などはプロセッサ２１２やメモリ２１１に伝達されてもよく、コンテンツやファイルなどは電子機器１（１１０）がさらに含むことのできる格納媒体に格納されてもよい。
【００２５】
入力／出力インタフェース２１４、２２４は、入力／出力装置２１５とのインタフェースのための手段であってもよい。例えば、入力装置は、マイクロフォン、キーボード、またはマウスなどの装置を、また出力装置はアプリケーションの通信セッションを表示するためのディスプレイやスピーカのような装置を含んでもよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２は、メモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが、入力／出力インタフェース２１４を通じてディスプレイに表示されてもよい。
【００２６】
また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりもさらに多くの構成要素を含んでもよい。しかし、大部分の従来技術の構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ（ｔｒａｎｓｃｅｉｖｅｒ）、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。
【００２７】
図３は、本発明の一実施形態における、ＶｏＩＰサーバのプロセッサが含むことのできる構成要素の例を示した図であり、図４は、本発明の一実施形態における、ＶｏＩＰサーバが実行することのできる呼処理方法の例を示したフローチャートである。
【００２８】
本実施形態において、サーバ１５０は、ＶｏＩＰサーバ（またはＳＩＰサーバ）に対応してもよく、サーバ１５０のプロセッサ２２２は、送受信制御部３１０、プッシュリクエスト制御部３２０、および通話管理制御部３３０を備えてもよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図４の呼処理方法が含むステップ４１０〜ステップ４５０を実行するようにサーバ１５０を制御してもよい。例えば、プロセッサ２２２およびプロセッサ２２２の構成要素は、サーバ１５０のメモリ２２１が含むオペレーティングシステムのコードと少なくとも１つのプログラムコードによる命令を実行するように実現されてもよい。
【００２９】
ステップ４１０で、プロセッサ２２２は、呼処理方法のためのプログラムファイルに格納されたプログラムコードをメモリ２２１にロードしてもよい。例えば、サーバ１５０には、プログラムファイルにしたがってプログラムがインストール（ｉｎｓｔａｌｌ）されてもよい。このとき、サーバ１５０にインストールされたプログラムが実行される場合、プロセッサ２２２は、プログラムコードをメモリ２２１にロードしてもよい。ここで、プロセッサ２２２が備える送受信制御部３１０、プッシュリクエスト制御部３２０、および通話管理制御部３３０それぞれは、メモリ２２１にロードされたプログラムコードのうち対応するコードによる命令を実行して以後のステップ４２０〜ステップ４５０を実行するように実現されてもよい。
【００３０】
以下で、プロセッサ２２２の構成要素がサーバ１５０を制御することは、プロセッサ２２２がサーバ１５０の他の構成要素を制御するものと理解されてもよい。例えば、プロセッサ２２２は、サーバ１５０が含む通信モジュール２２３を制御してサーバ１５０が電子機器（一例として、電子機器１（１１０））や他のサーバ（一例として、サーバ１６０）と通信するようにサーバ１５０を制御してもよい。
【００３１】
ステップ４２０で、送受信制御部３１０は、発信電子機器から発信リクエストを受信するようにサーバ１５０を制御してもよい。従来技術に係るＳＩＰでは、発信をリクエストする工程で、ＳＩＰダイアログの生成と通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）の生成のためにインバイトリクエストをＶｏＩＰサーバ（または、ＳＩＰサーバ）に送信していたが、本発明の実施形態では、このようなインバイトリクエストのための工程は省略されてもよい。
【００３２】
ステップ４３０で、プッシュリクエスト制御部３２０は、発信リクエストに対応する着信電子機器にプッシュ通知を提供することをプッシュサーバにリクエストするようにサーバ１５０を制御してもよい。例えば、発信リクエストは、着信電子機器を識別するための情報を含んでもよく、サーバ１５０は、このような情報に基づいてプッシュサーバに着信電子機器へのプッシュ通知の提供をリクエストしてもよい。プッシュサーバは、このようなリクエストに応じてプッシュ通知を着信電子機器に提供してもよい。例えば、着信電子機器には、プッシュサーバと関連するアプリケーションがインストールされていてもよい。このとき、プッシュサーバは、リクエストにしたがい、プッシュ通知を着信電子機器にインストールされたアプリケーションを通じて着信電子機器にプッシュしてもよい。着信電子機器にインストールされたアプリケーションは、発信電子機器にも同じようにインストールされてもよく、発信電子機器と着信電子機器はこのようなアプリケーションを通じて通話を処理してもよい。
【００３３】
ステップ４４０で、通話管理制御部３３０は、発信取消リクエストの受信の可否を確認してもよい。例えば、通話管理制御部３３０は、インバイトリクエストを受信する以前に発信電子機器から発信取消リクエストが受信されたか否かを確認してもよい。発信取消リクエストが受信された場合にはステップ４５０が実行されてもよく、発信取消リクエストが受信されていない場合にはステップ４６０が実行されてもよい。
【００３４】
ステップ４５０で、通話管理制御部３３０は、インバイトリクエストを受信する以前に発信電子機器から発信取消リクエストが受信された場合、発信リクエストに対応するＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を生成せずに発信を取り消してもよい。発信が取り消された場合、図４の呼処理方法は終了されてもよい。
【００３５】
ステップ４６０で、通話管理制御部３３０は、着信拒絶リクエストの受信の可否を確認してもよい。例えば、通話管理制御部３３０は、インバイトリクエストを受信する以前に着信電子機器から着信拒絶リクエストが受信されたか否かを確認してもよい。着信拒絶リクエストが受信された場合にはステップ４７０が実行されてもよく、着信拒絶リクエストが受信されていない場合にはステップ４８０が実行されてもよい。
【００３６】
ステップ４７０で、通話管理制御部３３０は、インバイトリクエストを受信する以前に着信電子機器から着信拒絶リクエストが受信された場合、発信リクエストに対応するＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を生成せずに発信を取り消してもよい。発信が終了された場合、図４の呼処理方法は終了されてもよい。
【００３７】
言い換えれば、ステップ４４０およびステップ４５０は、発信電子機器から発信取消リクエストが受信された場合に実行されてもよく、ステップ４６０およびステップ４７０は、着信電子機器から着信拒絶リクエストが受信された場合に実行されてもよい。したがって、発信取消リクエストや着信拒絶リクエストが受信されなかった場合、ステップ４３０以後にはステップ４８０が実行されてもよい。
【００３８】
ステップ４８０で、送受信制御部３１０は、着信電子機器からプッシュ通知に基づいて送信されたインバイト（ＩＮＶＩＴＥ）リクエストを受信するようにサーバ１５０を制御してもよい。このようなインバイトリクエストは、着信電子機器が着信に応答する場合に着信電子機器で生成されてサーバ１５０に送信されてもよい。
【００３９】
ステップ４９０で、通話管理制御部３３０は、インバイトリクエストに応じて前記発信電子機器と前記着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成してもよい。また、通話管理制御部３３０は、着信電子機器からインバイトリクエストを受信することによって発信電子機器にインバイトリクエストを送信するようにサーバ１５０を制御してもよい。このとき、発信電子機器がサーバ１５０からのインバイトリクエストに基づいて通話セッションに連結されてもよい。さらに、通話管理制御部３３０は、着信電子機器からインバイトリクエストを受信することによってＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を生成して管理してもよい。
【００４０】
また、図４の呼処理方法は、インバイトリクエストの受信にしたがってＳＩＰダイアログ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｉａｌｏｇ）を生成して管理するステップ（図示せず）を、ステップ４９０以後またはステップ４９０以前にさらに含んでもよい。このような図に示されていないステップは、通話管理制御部３３０によって実行されてもよい。
【００４１】
このように、本発明の実施形態では、着信電子機器が着信に応答した場合にだけインバイトリクエストを生成することができる。したがって、サーバ１５０は、すべての発信リクエストに対してインバイトリクエストを生成する必要がないため、サーバ１５０が生成しなければならないＳＩＰダイアログの数を画期的に減少させることができる。例えば、発信リクエストに対して着信応答が発生する割合が５０％であれば、サーバ１５０が生成しなければならないＳＩＰダイアログの数は半減するようになり、これによってサーバ１５０の性能と容量を大きく向上させることができる。
【００４２】
発信電子機器がインバイトリクエストをサーバ１５０に伝達しなくとも、サーバ１５０は、プッシュサーバからのプッシュ通知の送信によって呼リクエストを着信電子機器に伝達することができる。
【００４３】
図５は、本発明の一実施形態における、プッシュサーバのプロセッサが含むことのできる構成要素の例を示した図であり、図６は、本発明の一実施形態における、プッシュサーバが実行することのできる呼処理方法の例を示したフローチャートである。
【００４４】
本実施形態において、サーバ１６０は、プッシュサーバに対応してもよく、サーバ１６０のプロセッサ５１０は、リクエスト受信制御部５１１およびプッシュ通知送信制御部５１２を備えてもよい。このようなプロセッサ５１０およびプロセッサ５１０の構成要素は、図６の呼処理方法が含むステップ６１０〜ステップ６３０を実行するようにサーバ１６０を制御してもよい。例えば、プロセッサ５１０およびプロセッサ５１０の構成要素は、サーバ１６０のメモリ（図示せず）が含むオペレーティングシステムのコードと少なくとも１つのプログラムコードによる命令を実行するように実現されてもよい。
【００４５】
ステップ６１０で、プロセッサ５１０は、呼処理方法のためのプログラムファイルに格納されたプログラムコードをサーバ１６０のメモリにロードしてもよい。例えば、サーバ１６０には、プログラムファイルにしたがってプログラムがインストール（ｉｎｓｔａｌｌ）されてもよい。ここで、サーバ１６０にインストールされたプログラムが実行される場合、プロセッサ５１０は、プログラムコードをメモリにロードしてもよい。このとき、プロセッサ５１０が備えるリクエスト受信制御部５１１およびプッシュ通知送信制御部５１２それぞれは、メモリにロードされたプログラムコードのうち対応するコードによる命令を実行して以後のステップ６２０およびステップ６３０を実行するように実現されてもよい。
【００４６】
ステップ６２０で、リクエスト受信制御部５１１は、ＶｏＩＰサーバからプッシュ通知リクエストを受信するようにサーバ１６０を制御してもよい。このとき、プッシュ通知リクエストは、ＶｏＩＰサーバで発信電子機器からの発信リクエストに応じて発信リクエストに対応する着信電子機器に対して生成されてもよい。
【００４７】
ステップ６３０で、プッシュ通知送信制御部５１２は、プッシュ通知リクエストに応答して着信電子機器にプッシュ通知を送信するようにサーバ１６０を制御してもよい。このとき、着信電子機器でプッシュ通知に基づいてインバイトリクエストをＶｏＩＰサーバに送信してもよく、ＶｏＩＰサーバでインバイトリクエストに応じて発信電子機器と着信電子機器との間の通話セッション（ｃａｌｌ  ｓｅｓｓｉｏｎ）を生成してもよい。
【００４８】
上述したように、サーバ１６０と関連するアプリケーションが着信電子機器にインストールされてもよく、プッシュ通知は、このようなアプリケーションを通じて着信電子機器にプッシュされてもよい。
【００４９】
以下では、より具体的な実施例を参照しながら、本発明の実施形態に係る呼処理工程について説明する。
【００５０】
図７は、本発明の一実施形態における、全体システムにおける呼処理工程の例を示した図である。ここで、図７は、発信電子機器７１０、ＶｏＩＰサーバ７２０、プッシュサーバ７３０、および着信電子機器７４０間のメッセージ送受信工程の例を示している。
【００５１】
１．ｓｅｔｕｐ工程は、発信電子機器７１０上で発信リクエスト７５０が発生されることにより、発信電子機器７１０がＶｏＩＰサーバ７２０に発信リクエストを送信する工程であってもよい。
【００５２】
２．ｒｅｑ．ＰＵＳＨ工程は、ＶｏＩＰサーバ７２０が受信した発信リクエストに対応する着信電子機器７４０にプッシュ通知を送信するようにプッシュサーバ７３０にリクエストする工程であってもよい。
【００５３】
３．ＰＵＳＨ通知工程は、プッシュサーバ７３０がＶｏＩＰサーバ７２０のリクエストに応じて着信電子機器７４０にプッシュ通知を提供する工程であってもよい。
【００５４】
４．ｒｓｐ．ＰＵＳＨ工程は、プッシュサーバ７３０がＶｏＩＰサーバ７２０のリクエストを処理したことをＶｏＩＰサーバ７２０に知らせるための応答工程であってもよい。
【００５５】
５．２００  ＯＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０のリクエストを処理したことを発信電子機器７１０に知らせるための応答工程であってもよい。ここで、「２００  ＯＫ」とは、ＳＩＰで定義された応答メッセージであり、既に広く知られている。
【００５６】
このとき、着信電子機器７４０がプッシュ通知にしたがって着信登録７６０を処理しようとする場合、６．ｒｅｇ工程が実行されてもよい。
【００５７】
６．ｒｅｇ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に自身を登録する工程であってもよい。このような登録は、着信電子機器７４０がＶｏＩＰサーバ７２０に自身の存在を知らせるものに過ぎず、ＶｏＩＰサーバ７２０は、ＳＩＰダイアログがまだ生成されていないため、発信電子機器７１０と着信電子機器７４０との関係を知ることはできない。
【００５８】
７．２００  ＯＫ工程は、ＶｏＩＰサーバ７２０が着信電子機器７４０の登録が処理されたことを着信電子機器７４０に知らせるための応答工程であってもよい。
【００５９】
このとき、着信電子機器７４０が着信応答７７０を処理しようとする場合、８．ＩＮＶＩＴＥ工程が実行されてもよい。
【００６０】
８．ＩＮＶＩＴＥ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０にインバイトリクエストを送信する工程であってもよい。このとき、ＶｏＩＰサーバ７２０は、インバイトリクエストに基づいてＳＩＰダイアログを生成および管理してもよい。
【００６１】
９．ＩＮＶＩＴＥ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０にインバイトリクエストを送信する工程であってもよい。一例として、ＶｏＩＰサーバ７２０は、着信電子機器７４０が送信したインバイトリクエストを発信電子機器７１０に伝達してもよい。
【００６２】
１０．２００  ＯＫ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０にインバイトリクエストに対する応答を送信する応答工程であってもよい。
【００６３】
１１．２００  ＯＫ工程は、ＶｏＩＰサーバ７２０が着信電子機器７４０にインバイトリクエストに対する応答を送信する応答工程であってもよい。
【００６４】
１２．ＡＣＫ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に応答を送信する応答工程であってもよい。
【００６５】
１３．ＡＣＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に応答を送信する応答工程であってもよい。
【００６６】
このような工程により、発信電子機器７１０と着信電子機器７４０は、ＶｏＩＰサーバ７２０がインバイトリクエストに基づいて生成した通話セッションに連結されてもよく、互いに通話を行うことができるようになる。
【００６７】
着信応答７７０にしたがって着信電子機器７４０からインバイトリクエストが受信されなければ、ＳＩＰダイアログが生成されないため、多数の発信リクエストを考慮したとき、ＶｏＩＰサーバ７２０の性能を大きく向上させることができる。
【００６８】
図８は、本発明の一実施形態における、全体システムにおける発信終了工程の例を示した図である。図８は、図７において発信電子機器７１０と着信電子機器７４０との間の通話が行われる工程以後に、発信電子機器７１０から通話終了８１０がリクエストされた場合の工程について説明する。
【００６９】
１４．ＢＹＥ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０に発信終了メッセージを送信する工程であってもよい。「ＢＹＥ」とは、ＳＩＰで定義された終了メッセージであり、既に広く知られている。
【００７０】
１５．ＢＹＥ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０から受信した終了メッセージを着信電子機器７４０に伝達する工程であってもよい。
【００７１】
１６．２００  ＯＫ工程は、着信電子機器７４０が終了メッセージの受信による応答をＶｏＩＰサーバ７２０に送信する応答工程であってもよい。
【００７２】
１７．２００  ＯＫ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に応答を送信する応答工程であってもよい。
【００７３】
このような工程の後、発信電子機器７１０と着信電子機器７４０との間の通話が終了されてもよい。着信電子機器７４０上から先に通話終了がリクエストされると、着信電子機器７４０は、ＶｏＩＰサーバ７２０に終了メッセージを送信してもよく、ＶｏＩＰサーバ７２０を通じて終了メッセージが発信電子機器７１０に送信されて通話が終了されてもよい。
【００７４】
図９は、本発明の一実施形態における、全体システムにおける発信取消工程の例を示した図である。図９は、図７において、着信登録７６０によって７．２００  ＯＫ工程まで進んだ後に、発信電子機器７１０上で発信取消９１０がリクエストされた場合の実施形態について説明する。
【００７５】
８．ｃａｎｃｅｌ工程は、発信電子機器７１０がＶｏＩＰサーバ７２０に発信取消メッセージを送信する工程であってもよい。
【００７６】
９．ｃａｎｃｅｌ工程は、ＶｏＩＰサーバ７２０がプッシュサーバ７３０に発信取消メッセージを伝達する工程であってもよい。
【００７７】
１０．ｃａｎｃｅｌ工程は、プッシュサーバ７３０が着信電子機器７４０に発信取消メッセージを伝達する工程であってもよい。
【００７８】
言い換えれば、ＶｏＩＰサーバ７２０は、インバイトリクエストを受信しておらず、ＳＩＰダイアログを生成していなかった。このような場合に発信が取り消されたため、ＶｏＩＰサーバ７２０は、プッシュサーバ７３０を通じて発信取消メッセージを着信電子機器７４０に送信することができる。
【００７９】
１１．２００  ＯＫ工程、１２．２００  ＯＫ工程、および１３．２００  ＯＫ工程は、着信電子機器７４０の応答をプッシュサーバ７３０およびＶｏＩＰサーバ７２０を通じて発信電子機器７１０に伝達する工程であってもよい。
【００８０】
このように、発信が取り消された場合にはインバイトリクエストが発生せず、これによってＳＩＰダイアログも生成されないことが分かる。
【００８１】
図１０は、本発明の一実施形態における、全体システムにおける着信拒絶工程の例を示した図である。図１０は、図７において、着信登録７６０によって７．２００  ＯＫ工程まで進んだ後に、着信電子機器７４０上で着信拒絶１０１０リクエストが発生した場合の例を示している。
【００８２】
８．ｒｅｊｅｃｔ工程は、着信電子機器７４０がＶｏＩＰサーバ７２０に着信拒絶メッセージを送信する工程であってもよい。
【００８３】
９．ｒｅｊｅｃｔ工程は、ＶｏＩＰサーバ７２０が発信電子機器７１０に着信拒絶メッセージを伝達する工程であってもよい。
【００８４】
１０．２００  ＯＫ工程および１１．２００  ＯＫ工程は、発信電子機器７１０の応答がＶｏＩＰサーバ７２０を通じて着信電子機器７４０に伝達される工程であってもよい。
【００８５】
このように、着信が拒絶された場合にもインバイトリクエストが発生せず、これによってＳＩＰダイアログも生成されないことが分かる。
【００８６】
このように、本発明の実施形態によると、着信電子機器が通話を受諾する場合にだけインバイトリクエストが発生するように処理することにより、ＳＩＰダイアログの生成回数自体を減らし、ＳＩＰサーバ（ＶｏＩＰサーバ）の性能および容量を画期的に向上させることができる。
【００８７】
上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてもよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ  ｌｏｇｉｃ  ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてもよい。処理装置は、オペレーティングシステム（ＯＳ）および前記ＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してもよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してもよい。便宜的な理解のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素（ｐｒｏｃｅｓｓｉｎｇ  ｅｌｅｍｅｎｔ）および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ  ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。
【００８８】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供するために、いかなる種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ  ｅｑｕｉｐｍｅｎｔ）、コンピュータ格納媒体または装置、または送信される信号波（ｓｉｇｎａｌ  ｗａｖｅ）に永久的または一時的に具現化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された方法によって格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。
【００８９】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでもよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェアは当業者に公知な使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の例としては、ハードディスク、フロッピーディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ  ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして動作するように構成されてもよく、その逆も同じである。
【００９０】
以上のように、実施形態を限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能である。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、および／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【００９１】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【００９２】
１１０、１２０、１３０、１４０：電子機器
１５０、１６０：サーバ
１７０：ネットワーク
【図１】
2020198636.tif 000003
【図２】
2020198636.tif 000004
【図３】
2020198636.tif 000005
【図４】
2020198636.tif 000006
【図５】
2020198636.tif 000007
【図６】
2020198636.tif 000008
【図７】
2020198636.tif 000009
【図８】
2020198636.tif 000010
【図９】
2020198636.tif 000011
【図１０】
2020198636.tif 000012