JP2024065858A - Ｗｅｂ電話システム、ｗｅｂ電話用サーバ装置およびｗｅｂ電話用プログラム - Google Patents

Abstract

【課題】この開示は、ＷＥＢ経由での電話機能をユーザに提供する上で好適なＷＥＢ電話システムを提供することを目的とする。
【解決手段】ＩＰ電話を発信する発信端末１００と、ＩＰ電話を受信する着信端末１１０と、Ｗｅｂサーバ１４０と、シグナリングサーバ１５０と、通知サーバ１６０とを備える。発信端末１００は、ＩＰ電話で着信端末Ｂに発呼するためのＵＲＬ（Ｂ）の入力を受けて、当該ＵＲＬ（Ｂ）の情報を含むＡ→Ｂ呼び出し（１２）をＷｅｂサーバ１４０に送信する。Ｗｅｂサーバ１４０は、Ａ→Ｂ呼び出しを受けて、予め登録されている着信端末１１０のＩＰ電話登録情報をＵＲＬ（Ｂ）に基づいて読み出し、端末特定識別子およびＩＰ電話アプリを特定して、着信端末１１０の呼び出し要求（１３）を通知サーバ１６０に送信する。着信端末１１０は、呼び出し信号（１４）によりＩＰ電話アプリを起動（１５）して着信表示（１６）を生じさせる。
【選択図】図３

Description

この開示は、ＷＥＢ電話システム、ＷＥＢ電話用サーバ装置およびＷＥＢ電話用プログラムに係り、特に、ＷＥＢ経由での電話機能をユーザに提供する上で好適なＷＥＢ電話システム、ＷＥＢ電話用サーバ装置およびＷＥＢ電話用プログラムに関する。

特許文献１には、ＷＥＢページを介してデータネットワークテレフォニー（ＤＮＴ）通信を可能にするためのシステムが開示されている。ＷＥＢを経由するＩＰ電話では、発信側のデバイスと受信側のデバイスに、互換性のあるＩＰ電話用アプリケーション（以下、「ＩＰ電話アプリ」とする）のインストールを求めることが通常である。

ＩＰ電話アプリには様々な種類が存在し、一般的に異なる種類のＩＰ電話アプリ間では互換性が認められない。このため、様々なＩＰ電話に対応するためには、ＩＰ電話に用いるデバイスに、様々なＩＰ電話アプリをインストールしておくことが必要となる。

特許文献１では、このような不都合を解決するためのシステムが提案されている。具体的には、このシステムによれば、ＩＰ電話の発信者が特定のＷｅｂページのリンクにアクセスすることで必要なＩＰ電話アプリがダウンロードされ、事前に記憶されたいくつかの通話が終わった後に、そのＩＰ電話アプリがアンインストールされる。

特表２００２－５２４９７６号公報

特許文献１に記載の上記技術によれば、ユーザのデバイスに常にＩＰ電話アプリをインストールしておく必要が解消される。このため、ユーザは、デバイスの記憶容量が無駄に消費されないメリットを享受することができる。

しかしながら、ＩＰ電話を利用する度に、ＩＰ電話アプリのインストールとアンインストールが行われるとすれば、その処理に要する時間や手間に起因して、ユーザは煩らしさを感ずる。この点、特許文献１に記載の技術は、ＩＰ電話の利便性を高めるうえで、未だ改良の余地を残すものであった。

この開示は、上述のような課題を解決するためになされたもので、発信側のデバイスに特別なＩＰ電話アプリのインストールを求めることなくＩＰ電話による通話を可能とするＷＥＢ電話システムを提供することを第一の目的とする。
また、この開示は、発信側のデバイスに特別なＩＰ電話アプリのインストールを求めることなくＩＰ電話による通話を可能とするＷＥＢ電話用サーバ装置を提供することを第二の目的とする。
また、この開示は、発信側のデバイスに特別なＩＰ電話アプリのインストールを求めることなくＩＰ電話による通話を可能とするＷＥＢ電話用プログラムを提供することを第三の目的とする。

第１の態様は、上記の目的を達成するため、ＷＥＢ電話システムであって、
ＩＰ電話を発信する発信端末Ａと、
ＩＰ電話を受信する着信端末Ｂと、
前記発信端末Ａおよび前記着信端末Ｂとネットワークを介して通信可能なＷｅｂサーバ並びにシグナリングサーバと、
前記Ｗｅｂサーバからの呼び出し要求に応えて前記着信端末に呼び出し信号を送信する通知サーバと、を備え、
前記発信端末Ａは、
ＩＰ電話で前記着信端末Ｂに発呼するためのＵＲＬ（Ｂ）の入力を受け付ける処理と、
前記ＵＲＬ（Ｂ）の入力を受けて、当該ＵＲＬ（Ｂ）の情報を含むＡ→Ｂ呼び出しを前記Ｗｅｂサーバに送信する処理と、を実行するように構成され、
前記Ｗｅｂサーバは、
前記Ａ→Ｂ呼び出しを受けて、予め登録されている前記着信端末ＢのＩＰ電話登録情報を前記ＵＲＬ（Ｂ）に基づいて読み出す処理と、
前記ＩＰ電話登録情報に含まれる電話番号およびＩＰ電話アプリを特定して、前記着信端末Ｂの呼び出し要求を、前記通知サーバに送信する処理と、を実行するように構成され、
前記着信端末Ｂは、
前記通知サーバから、前記ＩＰ電話アプリを指定した呼び出し信号を受け付ける処理と、
前記呼び出し信号を受けて、前記ＩＰ電話アプリを起動すると共に着信表示を生じさせる処理と、
前記着信表示に対する通話受諾の操作を受け付ける処理と、
前記通話受諾の操作を受けて前記Ｗｅｂサーバに通話の受諾通知を送信する処理と、を実行するように構成され、
前記Ｗｅｂサーバは、前記着信端末Ｂからの前記受諾通知を受けて、前記発信端末Ａおよび前記着信端末Ｂの双方に、前記シグナリングサーバにおける両者の待ち合わせ領域を示すＡ－Ｂ待ち合わせ情報を送信する処理を更に実行するように構成され、
前記発信端末Ａおよび前記着信端末Ｂは、
両者間にＰ２Ｐ経路を開設するために必要なＳＤＰの情報を前記Ａ－Ｂ待ち合わせ情報が示す前記待ち合わせ領域を介して交換する処理と、
前記ＳＤＰに基づいて開設されたＰ２Ｐ経路を介して音声信号を互いに授受する処理と、を更に実行するように構成されていることが望ましい。

また、第２の態様は、発信端末Ａおよび着信端末Ｂとネットワークを介して通信可能なＷＥＢ電話用サーバ装置であって、
前記発信端末Ａからの送信信号を受け付ける処理と、
前記送信信号が、ＩＰ電話で前記着信端末Ｂに発呼するためのＵＲＬ（Ｂ）を含むＡ→Ｂ呼び出しであるかを判別する処理と、
前記送信信号が前記Ａ→Ｂ呼び出しであった場合に、予め登録されている前記着信端末ＢのＩＰ電話登録情報を前記ＵＲＬ（Ｂ）に基づいて読み出す処理と、
前記ＩＰ電話登録情報に含まれる電話番号およびＩＰ電話アプリを特定して前記着信端末Ｂの呼び出し要求を通知サーバに送信して、当該通知サーバに、前記ＩＰ電話アプリを指定した呼び出し信号を前記着信端末Ｂに送信させる処理と、
前記着信端末Ｂから、通話の受諾を意味する受諾通知を受け付ける処理と、
前記着信端末Ｂからの前記受諾通知を受けて、前記発信端末Ａおよび前記着信端末Ｂの双方に、シグナリングサーバにおける両者の待ち合わせ領域を示すＡ－Ｂ待ち合わせ情報を送信する処理と、
を実行するように構成されていることが望ましい。

また、第３の態様は、スマートフォンをＩＰ電話の着信端末Ｂとして機能させるためのＷＥＢ電話用プログラムであって、
前記着信端末ＢとしてＩＰ電話を着信するために必要なＩＰ電話登録情報を自身のＩＰ電話を発呼するためのＵＲＬ（Ｂ）と結び付けさせるためにＷｅｂサーバに送信する処理と、
通知サーバからの呼び出し信号が、ＩＰ電話アプリに関する呼び出しであるか否かを判別する処理と、
前記呼び出し信号が、前記ＩＰ電話アプリに関する呼び出しである場合に、当該ＩＰ電話アプリを起動して通話受諾の操作を待ち受ける処理と、
前記通話受諾の操作が行われた場合に、前記Ｗｅｂサーバに向けて受諾通知を送信して、前記呼び出しの発信元である発信端末Ａとシグナリングサーバで待ち合わせるためのＡ－Ｂ待ち合わせ情報を待ち受ける処理と、
前記Ｗｅｂサーバから前記Ａ－Ｂ待ち合わせ情報を受信したら、前記シグナリングサーバの前記Ａ－Ｂ待ち合わせ情報が示す待ち合わせ領域に入室して待機する処理と、
前記発信端末ＡのＳＤＰの情報を含むオファーを、前記待ち合わせ領域を介して前記発信端末Ａから受け取る処理と、
前記オファーに応えて、自身のＳＤＰの情報を含むアンサーを、前記待ち合わせ領域を介して前記発信端末Ａに送信する処理と、
前記ＳＤＰの交換後に、当該ＳＤＰに基づいて前記発信端末Ａとの間にＰ２Ｐ経路を開設するための処理と、
を前記スマートフォンに実行させるためのプログラムを含むことが望ましい。

第１乃至第３の態様によれば、発信側のデバイスに特別なＩＰ電話アプリをインストールする必要がないため、極めて利便性に優れたＩＰ電話を実現することができる。

本開示の実施の形態１のＷＥＢ電話システムの特徴的な機能を説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムで発信者が参照する二次元バーコードの一例を示す。 本開示の実施の形態１のＷＥＢ電話システムの構成と、発信から着信までの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、着信者が通話を許諾した後、発信者と着信者の待ち合わせが完了するまでの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と着信者が相互の接続情報を交換する様子を示す図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と着信者の間にＰ２Ｐ経路が開通した様子を示す図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と着信者の間にＰ２Ｐ経路が開通した状態で、発信者が着信者に電話の取り次ぎを依頼した後、引継ぎ者に着信が生ずるまでの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、引継ぎ者が通話を受諾した後、着信者と引継ぎ者の待ち合わせが完了するまでの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、着信者と引継ぎ者が相互の接続情報を交換する様子を示す図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と着信者の間に加えて、着信者と引継ぎ者との間にもＰ２Ｐ経路が開通した様子を示す図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、着信者が引き継ぎの依頼を発した後、発信者と引継ぎ者の待ち合わせに必要な情報が着信者に提供されるまでの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と引継ぎ者の待ち合わせに必要な情報が着信者に提供された後、発信者と引継ぎ者の待ち合わせが完了するまでの処理の流れを説明するための図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と引継ぎ者が相互の接続情報を交換する様子を示す図である。 本開示の実施の形態１のＷＥＢ電話システムにおいて、発信者と引継ぎ者との間にＰ２Ｐ経路が開通した様子を示す図である。

実施の形態１．
［実施の形態１の機能］
図１は、本開示の実施の形態１のＷＥＢ電話システムの機能を説明するための図である。本実施形態のＷＥＢ電話システムはスマートフォン１００を別のスマートフォン１１０もしくは１２０と接続するシステムである。スマートフォン１００は、ＩＰ電話の発信者Ａが所有するデバイスである。

図１に示す例には、更に二台のスマートフォン１１０、１２０が含まれている。スマートフォン１１０は、ＩＰ電話の着信者Ｂが所有するデバイスである。また、スマートフォン１２０は、着信者Ｂの取り次ぎを経て、発信者Ａからの電話を引き継ぐ引継ぎ者Ｃが所有するデバイスである。発信者Ａは、着信者Ｂと引継ぎ者Ｃが所属する同じ企業、同じチームの顧客であるとの想定である。

着信者Ｂのスマートフォン１１０と、引継ぎ者Ｃのスマートフォン１２０には、ＩＰ電話アプリ（図中に「THIS IS App」と例示）がインストールされている。一方、発信者Ａのスマートフォン１００には、一般的なアプリケーションであるＷＥＢブラウザと二次元バーコードスキャナはインストールされているが、本実施例専用のＩＰ電話アプリはインストールされていない。

図１に示す例では、先ず、発信者Ａから着信者Ｂと引継ぎ者Ｃが所属している企業に向けてＩＰ電話が発呼されている。着信者Ｂのスマートフォン１１０と引継ぎ者Ｃのスマートフォン１２０には、予め当該企業固有のＵＲＬ（チーム）が設定されている。本実施形態のＷＥＢ電話システムは、発信者Ａが、ＷＥＢブラウザ上でそのＵＲＬ（チーム）にアクセスするとスマートフォン１００からスマートフォン１１０及びスマートフォン１２０への発呼が生ずるように構成されている。ＵＲＬ（チーム）に外部からのアクセスがあると、ＵＲＬ（チーム）に紐づけられたスマートフォンの端末特定識別子が格納された端末特定識別子情報を読み出し、格納された端末特定識別子に合致するすべてのスマートフォンへの発呼が生じる。スマートフォン１１０とスマートフォン１２０のどちらも着信を受諾することができるが、この場合、着信者Ｂが先に着信の受諾操作をおこなったとすると、これに応じて、スマートフォン１００とスマートフォン１１０との間で接続情報が交換され、ＡとＢの両者間での通話が開始され、スマートフォン１２０への発呼は解除されるように構成されている。

図１に示す例では、発信者Ａが所望する電話の相手が、着信者Ｂではなく引継ぎ者Ｃであったため、着信者Ｂが引き継ぎ操作を行って通話相手を着信者Ｂから引き継ぎ者Ｃに受け渡している。引継ぎ者Ｃのスマートフォン１２０は、予め固有のＵＲＬ（Ｃ）が設定されている。本実施形態のＷＥＢ電話システムは、着信者Ｂが、発信者Ａとの通話中に引継ぎ者の固有ＵＲＬ（Ｃ）にアクセスすると、その通話を維持したままスマートフォン１１０からスマートフォン１２０への発呼が生ずるように構成されている。また、本実施形態のＷＥＢ電話システムは、引継ぎ者Ｃが引き継ぎを受諾すると、スマートフォン１００とスマートフォン１２０との間で接続情報が交換されて、発信者Ａと引継ぎ者Ｃとの通話が可能となるように構成されている。着信者Ｂのスマートフォン１１０は発信者Ａのスマートフォン１００と引継ぎ者Ｃのスマートフォン１２０の両方と同時に通話状態となり、着信者Ｂは、引継ぎ者Ｃとの通話が開始されたことを確認して、自己の通話を切断することができる。

図２は、本実施形態において、発信者Ａが参照する二次元バーコードの一例を示す。より具体的には、図２は、二次元バーコードとしてＱＲコード（登録商標）を印刷した名刺であるカード１３０を示している。この二次元バーコードには、ＵＲＬ（チーム）の情報が埋め込まれている。発信者Ａは、カード１３０を所持していれば、スマートフォン１００で二次元バーコードを読み取るだけで、着信者Ｂと引継ぎ者Ｃが所属するチームの登録された全員への発呼を同時に生じさせることができる。もちろん、名刺に記載するＱＲコードは、チームのものでも良いし、着信者Ｂに固有のＵＲＬ（Ｂ）でも良いし、それらの両方でも良い。ＵＲＬ（チーム）は、当該チームの電話番号でいうところの、代表番号に相当するものである。着信の転送先は、ＵＲＬ（チーム）に紐づけられていない、図示しない別のスマートフォンに紐づけられたＵＲＬ（Ｄ）でも良いし、別のチームのＵＲＬ（チーム２）でも良い。

以上説明した通り、本実施形態のＷＥＢ電話システムによれば、発信者Ａのスマートフォン１００は、特定のＵＲＬにブラウザからアクセスしているだけであって、スマートフォン１００に特別なＩＰ電話アプリをインストールする必要がない。また、着信者ＢのＵＲＬ（Ｂ）が埋め込まれたカード１３０を所持していれば、発信者Ａは、その二次元バーコードを読み取るだけで、簡単に着信者Ｂ個人、もしくは所属チーム全体への発呼を生じさせることができる。このため、自身のＵＲＬを埋め込んだ二次元バーコードを印刷した名刺を顧客である発信者Ａに配布しておけば、顧客が自身にＩＰ電話を発呼する際の手間を大幅に省くことができる。もちろん、このＵＲＬは通常のＵＲＬであるので、発信者Ａのスマートフォン１００にアクセル履歴として記憶されるし、お気に入り登録しておくことで、容易に再通話することもできる。また、ＵＲＬは通常のＵＲＬであるので、ＱＲコードからのアクセスでなくても、アドレスの手入力や、文字認識、会社Ｗｅｂサイトからのリンク等でも良い。

また、本実施形態のＷＥＢ電話システムによれば、「THIS IS App」をインストールしたスマートフォン１１０、１２０を所持する者同士であれば。着信した電話を、簡単に他者に受け渡すことができる。ビジネスのシーンでは、受け取った電話を関係者に取り次ぐ必要が頻繁に生ずる。本実施のＷＥＢ電話システムによれば、そのような要求にも応えることができる。以上の点より、本実施のＷＥＢ電話システムは、会社等の組織がビジネスのために用いるコミュニケーションツールとして高い有用性を備えている。また、本実施形態のＷＥＢ電話システムによれば、顧客に知らせるのは、自己のスマートフォンに紐づけられたＵＲＬだけであるので、例えば企業の社員であるＢとＣが個人的に保有するスマートフォンを紐づけておくこともできる。企業の従業員であるＢとＣは、個人的に保有するプライベートのスマートフォンをＵＲＬ（チーム）、ＵＲＬ（Ｂ）、ＵＲＬ（Ｃ）に登録したとしても、顧客に開示される情報は当該ＵＲＬだけであるので、個人的な電話番号のような固有アドレスが開示されることがない。社員にプライベートのスマートフォンに加えて社用のスマートフォンの両方を持たせておく必要がなくなる。企業から見ても、当該社員が退職、異動する等しても、ＵＲＬ（チーム）に紐づけるスマートフォンを引き継いだ社員のものに入れ替えるだけで、顧客に配布した名刺に記載されたＵＲＬ（チーム）は引き続き活用できるので、重要な顧客とのネットワークを従業員の退職や異動によって失う事がない。

［実施の形態１の構成］
図３には、本開示の実施の形態１のＷＥＢ電話システムの全体構成が示されている。図３に示すように、本実施のＷＥＢ電話システムは、上述した三台のスマートフォン１００、１１０および１２０に加えて、Ｗｅｂサーバ１４０、シグナリングサーバ１５０および通知サーバ１６０を備えている。

スマートフォン１００、１１０および１２０は、ＣＰＵ等のプロセッサ、ＲＯＭ、ＲＡＭ等を含むメモリ装置、ディスプレイ等の入出力インターフェースを備えている。同様に、Ｗｅｂサーバ１４０、シグナリングサーバ１５０および通知サーバ１６０も、プロセッサ、メモリ装置、入出力インターフェースなどの要素により構成されている。これらは何れも、メモリ装置に格納されているプログラムに沿ってプロセッサが必要な処理を実行することで、所望の機能を実現する。

［実施の形態１における処理の流れ］
以下、図３乃至図１４を参照して、本実施形態のＷＥＢ電話システムにおいて実行される処理の流れを説明する。尚、以下の説明では、スマートフォン１００、１１０および１２０の使用者による操作には（Ｓ１）、（Ｓ２）等の符号を付し、操作に起因して生ずる現象、信号等には（１１）、（１２）のようにＳを伴わない数値だけの符号を付することとする。

［ＩＰ電話による通話の開始］
図３には、上記の構成に加えて、発信から着信までの処理の流れが示されている。図３に示す例では、先ず、発信者Ａにより、着信者Ｂが配布した名刺に記載されたＵＲＬ（チーム）に向けた発信操作が行われる（Ｓ１）。発信操作は、例えば、発信者Ａが、スマートフォン１００により図２に示すカード１３０のＱＲコード（商標名）をスキャンすることにより行われる。

スマートフォン１００は、上記の発信操作が行われると、先ず、Ｗｅｂサーバ１４０に対するＷｅｂソケットを開設する（１１）。

続いて、スマートフォン１００は、ＵＲＬ（チーム）の情報を含むＡ→チーム全体呼び出しをＷｅｂサーバ１４０に送信する（１２）。

Ｗｅｂサーバ１４０には、ＩＰ電話アプリの利用者情報がＩＰ電話登録情報として登録されている。本実施例においてはＩＰ電話登録情報として、例えば、着信者Ｂについては、スマートフォン１１０の端末特定識別子（識別子は例えばＩＰアドレス、電話番号でも良く、これに限られない。）、ＩＰ電話アプリ「THIS IS App」で用いるＵＲＬ（Ｂ）の情報などがリストとして登録されている。

Ｗｅｂサーバ１４０は、Ａ→チーム全体の呼び出しを受けると、そこに含まれているＵＲＬ（チーム）により、その呼び出しが、ＵＲＬ（チーム）に紐づけられたスマートフォン１１０と１２０の両方に対するＩＰ電話の呼び出しであることを認識する。そして、スマートフォン１１０と１２０の端末特定識別子を読み出して、その番号に対する「THIS IS App」の呼び出し要求を通知サーバ１６０に送信する（１３）。

通知サーバ１６０は、スマートフォン１１０、１２０を管理する通信キャリア（端末特定識別子が電話番号ではなくＩＰアドレスである場合はデータ通信管理企業等）が運営するサーバである。通知サーバ１６０には、端末特定識別子とアプリケーションを指定した呼び出し要求を受けると、その端末特定識別子を持つデバイスに、そのアプリケーションに関わるプッシュ通知を生じさせるための呼び出し信号を発する機能が備わっている。このため、Ｗｅｂサーバ１４０からの呼び出し要求を受信すると、通知サーバ１６０は、ＵＲＬ（チーム）に紐づけられたすべてのスマートフォン、この場合は１１０と１２０の２台に向けて「THIS IS App」に関わる呼び出し信号を送信する（１４）。

スマートフォン１１０と１２０は、通知サーバ１６０から上記の呼び出し信号を受け取ると、ＩＰ電話アプリ「THIS IS App」を起動する（１５）。また、着信者Ｂと引継ぎ者Ｃに着信を知らせるための着信表示を生じさせる（１６）。

図４は、スマートフォン１１０に着信表示が生じた後の処理の流れを説明するための図である。図４に示す例では、着信表示を受けて、着信者Ｂが通話許諾の操作を実行している（Ｓ２）。

着信者Ｂが通話を許諾すると、スマートフォン１１０は、Ｗｅｂサーバ１４０に対して受諾通知を送信する（２１）。これに応じ、Ｗｅｂサーバ１４０は受諾通知を行ってきたスマートフォン１１０以外のＵＲＬ（チーム）に登録されたすべての他のスマーフォン、この場合はスマートフォン１２０に対し、発呼を停止する処理を行う。

Ｗｅｂサーバ１４０は、上記の受諾通知を受信すると、Ａ－Ｂ待ち合わせ情報をスマートフォン１１０に返信する（２２）。Ａ－Ｂ待ち合わせ情報は、シグナリングサーバ１５０において、発信者Ａのスマートフォン１００と着信者Ｂのスマートフォン１１０とが、通信の開設に必要な情報を交換するために必要な情報である。

Ａ－Ｂ待ち合わせ情報を受け取ると、スマートフォン１１０は、先ず、シグナリングサーバ１５０に対するＷｅｂソケットを開設する（２３）。次に、Ａ－Ｂ待ち合わせ情報が示す領域に「入室」する（２４）。尚、「入室」とは、その領域での情報授受が可能な状態で待機することを意味する。以下の説明においても「入室」はこの意味で用いられているものとする。

Ｗｅｂサーバ１４０は、スマートフォン１１０からの受諾通知を受け取った際に、発信者Ａのスマートフォン１００にも、Ａ－Ｂ待ち合わせ情報を送信する（２５）。この送信は、開設済みのＷｅｂソケット１１を用いて行われる（図３参照）。

Ａ－Ｂ待ち合わせ情報を受け取ったスマートフォン１００は、スマートフォン１１０と同様に、シグナリングサーバ１５０に対するＷｅｂソケットを開設して（２６）、待ち合わせ領域に入室する（２７）。

図５は、発信者Ａのスマートフォン１００と着信者Ｂのスマートフォン１１０が、共にシグナリングサーバ１５０の待ち合わせ領域に入室した後の処理の流れを説明するための図である。シグナリングサーバ１５０は、同じ待ち合わせ情報を持つ複数のスマートフォンが入室してきた場合に、遅れて入室してきたスマートフォンに、入室済みのスマートフォンが存在することを通知する。そして、その通知を受けたスマートフォンは、ブラウザの機能により、入室済みのスマートフォンに対して情報交換のオファーを投げかける。

図５に示す例では、着信者Ｂのスマートフォン１１０が先に入室し、発信者Ａのスマートフォン１００が遅れて入室することになる。この場合、発信者Ａのスマートフォン１００から着信者Ｂのスマートフォン１１０に向けて上記のオファーが送信される（２８）。このオファーには、スマートフォン１００のＩＰアドレス、ポート番号、通信帯域など、スマートフォン１００との通信を確立するために必要なＳＤＰ（Session Description Protocol）が含まれている。

着信者Ｂのスマートフォン１１０は、上記のオファーを受け取ると、自身との通信に必要なＳＤＰを含むアンサーを返信する（２９）。以上の処理により、二台のスマートフォン１００および１１０は、互いに相手方との通信に必要な情報を入手した状態となる。

図６は、上記の情報交換が終わった後の状態を示す。図６に示すように、スマートフォン１００および１１０は、お互いのＳＤＰに基づいて、両者間での通信を可能とするＰ２Ｐ経路を開設する（３０）。以後、両者は、このＰ２Ｐ経路を介して音声による通話を開始することができる。これに伴い、Ｗｅｂサーバ１４０は別の着信を待ち受ける状態に戻る。

［ＩＰ電話の引き継ぎ］
図７は、発信者Ａが、着信者Ｂに、Ｃさんへの電話の取り次ぎを依頼した（Ｓ３）場合の処理の流れを説明するための図である。発信者Ａと着信者Ｂは、音声による通話中であるから、取り次ぎの依頼は「Ｃさんへの取り次ぎをお願いします」のように音声により行うことができる。

発信者Ａからの取り次ぎ依頼を受けた着信者Ｂは、Ｃさんが電話の引き継ぎを承諾するか否かを確認するために、スマートフォン１１０においてＣさんへの発信操作、すなわちＣさんのスマートフォン１２０だけが紐づけられた固有のＵＲＬ（Ｃ）へのアクセスを行う（Ｓ４）。以後、着信者Ｂのスマートフォン１１０と、引継ぎ者Ｃのスマートフォン１２０との間で上述した処理が繰り返されて両者間にＰ２Ｐ経路が開設される。

具体的には、先ず、着信者Ｂのスマートフォン１１０によりＷｅｂサーバ１４０に対するＷｅｂソケットが開設される（４１）。

着信者Ｂと引継ぎ者Ｃは、共にＩＰ電話アプリの利用者であり、それぞれのＵＲＬ（Ｂ）およびＵＲＬ（Ｃ）は、事前に相互に交換されている。このため、スマートフォン１１０には、スマートフォン１２０のＵＲＬ（Ｃ）が登録されている。そして、スマートフォン１１０は、上記のＷｅｂソケットを開設したら、次に、ＵＲＬ（Ｃ）の情報を含むＢ→Ｃ呼び出しをＷｅｂサーバ１４０に送信する（４２）。

Ｗｅｂサーバ１４０には、Ｂ→Ｃ呼び出しに含まれているＵＲＬ（Ｃ）に基づいて、その呼び出しが、スマートフォン１２０に対する呼び出しであることを認識する。そして、スマートフォン１２０の呼び出し要求を通知サーバ１６０に送信する（４３）。

スマートフォン１２０は、通知サーバ１６０から呼び出し信号を受け取る（４４）と、ＩＰ電話アプリを起動する（４５）と共に着信表示を生じさせる（４６）。

図８は、スマートフォン１２０に着信表示が生じた後の処理の流れを示す。図８に示す例では、着信表示を受けて、引継ぎ者Ｃが通話許諾の操作を実行している（Ｓ５）。

引継ぎ者Ｃが通話を許諾すると、スマートフォン１２０は、Ｗｅｂサーバ１４０に対して受諾通知を送信する（５１）。

Ｗｅｂサーバ１４０は、上記の受諾通知を受信すると、Ｂ－Ｃ待ち合わせ情報をスマートフォン１２０に返信する（５２）。

Ｂ－Ｃ待ち合わせ情報を受け取ったスマートフォン１２０は、シグナリングサーバ１５０に対するＷｅｂソケットを開設して（５３）、待ち合わせの領域に入室する（５４）。

Ｗｅｂサーバ１４０は、引継ぎ者Ｃからの受諾通知を受け取った際に、着信者Ｂのスマートフォン１１０にもＢ－Ｃ待ち合わせ情報を送信する（５５）。この送信は、開設済みのＷｅｂソケット４１を用いて行われる（図７参照）。

Ｂ－Ｃ待ち合わせ情報を受け取ったスマートフォン１１０は、スマートフォン１２０と同様に、シグナリングサーバ１５０に対するＷｅｂソケットを開設して（５６）、待ち合わせ領域に入室する（５７）。

図９は、着信者Ｂのスマートフォン１１０と引継ぎ者Ｃのスマートフォン１２０が、待ち合わせ領域でお互いの情報を交換している様子を示す。図９に示すように、ここでは、着信者Ｂのスマートフォン１１０から引継ぎ者Ｃのスマートフォン１２０に向けて、着信者Ｂとの通信に必要なＳＤＰを含むオファーが送信される（５８）。

引継ぎ者Ｃのスマートフォン１２０は、上記のオファーを受けて、自身との通信に必要なＳＤＰを含むアンサーをスマートフォン１２０に返信する（５９）。以上の処理により、スマートフォン１１０および１２０は、それぞれ互いに相手方との通信に必要な情報を入手することができる。

図１０は、上記の情報交換が終わった後の状態を示す。図１０に示すように、スマートフォン１１０および１２０は、お互いのＳＤＰに基づいて、両者間での通信を可能とするＰ２Ｐ経路を開設する（６０）。これにより、着信者Ｂのスマートフォン１１０は、発信者Ａのスマートフォン１００に通じるＰ２Ｐ経路３０と、引継ぎ者Ｃのスマートフォン１２０に通じるＰ２Ｐ経路６０の双方を同時に有する状態となる。

図１１は、着信者Ｂが、「Ａさんから電話ですよ」といった引き継ぎ依頼を、Ｐ２Ｐ経路６０を介して引継ぎ者Ｃに音声で伝達し（６１）、引継ぎ者Ｃが「では引き継ぎます」のように引き継ぎ承諾の意思を返答（６２）した後の状態を示す。着信者Ｂは、この場合、スマートフォン１１０において、発信者Ａの通話相手を自身からＣさんに切り換える操作を行う（Ｓ７）。尚、着信者Ｂは、切り替え操作に先立って再びＡさんと会話することができる。このため、着信者Ｂは、通話相手をＣさんに切り替えることをＡさんに伝えてから切り替え操作を行ってもよい。

スマートフォン１１０は、上記の切り替え操作が実施されると、Ｗｅｂサーバ１４０に、Ａさんのスマートフォン１００の情報とＣさんのスマートフォン１２０の情報（以下、「ＡＣ情報」とする）を提供する（７１）。

Ｗｅｂサーバ１４０は、ＡＣ情報を受け取ると、その送信元であるスマートフォン１１０に向けて、Ａ－Ｃ待ち合わせ情報を返信する（７２）。つまり、Ｗｅｂサーバ１４０は、特定のスマートフォン（ここでは１１０）から、そのスマートフォンとは異なる他の二つのスマートフォンの情報（ここではＡＣ情報）を受け取ると、それらの待ち合わせに必要な情報を、情報の送信元であるスマートフォンに返信する。

図１２は、Ａ－Ｃ待ち合わせ情報を受信したスマートフォン１１０の動作を説明するための図である。スマートフォン１１０には、この時点で、二つのＰ２Ｐ経路３０、６０が開通している。このため、スマートフォン１１０は、それらのＰ２Ｐ経路３０、６０を介して、Ａ－Ｃ待ち合わせ情報を極めて簡単に双方のスマートフォン１００、１２０に受け渡すことができる。

具体的には、スマートフォン１１０は、Ｗｅｂサーバ１４０から受け取ったＡ－Ｃ待ち合わせ情報を、Ｐ２Ｐ経路３０を介して発信者Ａのスマートフォン１００に送信し（７３）、その後Ｐ２Ｐ経路３０を切断する（７４）。また、スマートフォン１１０は、Ｐ２Ｐ経路６０を介してＡ－Ｃ待ち合わせ情報を引継ぎ者Ｃのスマートフォン１２０に受け渡し（７５）、その後Ｐ２Ｐ経路６０を切断する（７６）。

このような引継ぎの手順によれば、Ｗｅｂサーバ１４０は、発信者Ａのスマートフォン１００との間、並びに引継ぎ者Ｃのスマートフォン１２０との間に、Ａ－Ｃ待ち合わせ情報を提供するための接続を新たに開設する必要がない。このため、本実施形態のＷＥＢ電話システムによれば、ＩＰ電話に引き渡しを、極めて短時間でスムーズに進めることができる。

発信者Ａのスマートフォン１００は、Ａ－Ｃ待ち合わせ情報を受け取ると、シグナリングサーバ１５０にＷｅｂソケットを開設して（７７）、待ち合わせ領域に入室する（７８）。同様に、引継ぎ者Ｃのスマートフォン１２０も、Ａ－Ｃ待ち合わせ情報を受け取ると、シグナリングサーバ１５０にＷｅｂソケットを開設して（７９）、待ち合わせ領域に入室する（８０）。

図１３は、発信者Ａのスマートフォン１００と引継ぎ者Ｃのスマートフォン１２０が、待ち合わせ領域でお互いの情報を交換している様子を示す。ここでは、引継ぎ者Ｃのスマートフォン１２０が先に待ち合わせ領域に入室し、次いで発信者Ａのスマートフォン１００がその領域に遅れて入室してきたものとする。この場合、シグナリングサーバ１５０は、スマートフォン１２０が入室済みであることをスマートフォン１００に通知する。そして、その通知を受けたスマートフォン１００が、引継ぎ者Ｃのスマートフォン１２０に向けてオファーを発する（８１）。

また、オファーを受けたスマートフォン１２０は、スマートフォン１００にアンサーを返信する（８２）。オファーとアンサーには、それぞれ送信元の通信情報を含むＳＤＰが含まれている。このため、以上の処理により、スマートフォン１００と１２０との間で、相手方との通信に必要な情報が相互に交換される。

図１４は、上記の情報交換に続いて、発信者Ａのスマートフォン１００と、引継ぎ者Ｃのスマートフォン１２０との間にＰ２Ｐ経路（８３）が開設された様子を示す。以後、両者は、Ｐ２Ｐ経路８３を介して音声による通話を行うことができる。

以上説明した通り、本実施形態のＷＥＢ電話システムによれば、発信者Ａは、自身のスマートフォン１００に特別なＩＰ電話アプリをインストールすることなく、特定の相手をＩＰ電話で発呼することができる。必然的に、ＩＰ電話アプリの利用者は、自身のＵＲＬを周知しておくだけで、特別なＩＰ電話アプリのインストールを相手方に求めることなく、受信電話をＩＰ電話で待ち受けることができる。

更に、ＩＰ電話アプリの利用者間では、着信したＩＰ電話を、極めて短時間でスムーズに他者に引き渡すことができる。ビジネスの場面では、電話の取り次ぎや引き継ぎが頻繁に求められる。本実施形態のＷＥＢ電話システムによれば、その機能を極めて安価に実現することができる。このため、このシステムは、組織的な導入を図ることにより、ビジネス用の電話として極めて有効に用いることができる。

また、本実施形態のＷＥＢ電話システムでは、Ｗｅｂサーバ１４０が、ＵＲＬ（Ｂ）に結び付けられた端末特定識別子に基づいて着信者Ｂのスマートフォン１１０を呼び出すための処理を行う。このため、スマートフォン１００のＳＩＭが交換されていても、また、有効なＳＩＭが挿入されていなくても、ＩＰ電話の呼び出しが確実に行われる。この点で、本実施形態のＷＥＢ電話システムは、機種交換や海外での利用に際して、極めた高い利便性をユーザに提供することができる。

［実施の形態１の変形例］
ところで、上述した実施の形態１では、発信者Ａは、二次元バーコードをスキャンして着信者のＵＲＬを読み取ることとしている。しかしながら、二次元バーコードを用いることは必須ではなく、着信者のＵＲＬはブラウザに直接入力してもよい。また、着信者のＵＲＬをブラウザに登録しておき、登録データを用いて着信者を呼び出すこととしてもよい。

また、上述した実施の形態１では、発信者Ａが着信者Ｂの個人ＩＤを特定するＵＲＬ（Ｂ）に対してＩＰ電話を発呼することとしているが、本開示はこれに限定されるものではない。例えば、発呼先を特定するＵＲＬは、個人ＩＤではなくグループＩＤであってもよい。そして、発呼されたＩＰ電話は、グループに属する複数の着信者の端末を鳴動させ、複数の着信者のだれもがＩＰ電話に応答できる構成であってもよい。このような態様によれば、本開示のＷＥＢ電話システムは、会社の代表電話、部署単位に割り当てられた部署代表電話、店舗ごとに割り当てられた店舗代表電話等として有効に使用することができる。

１００ 発信者Ａのスマートフォン
１１０ 着信者Ｂのスマートフォン
１２０ 引継ぎ者Ｃのスマートフォン
１３０ カード
１４０ Ｗｅｂサーバ
１５０ シグナリングサーバ
１６０ 通知サーバ

Claims (6)

1. ＩＰ電話を発信する発信端末Ａと、
   ＩＰ電話を受信する着信端末Ｂと、
   前記発信端末Ａおよび前記着信端末Ｂとネットワークを介して通信可能なＷｅｂサーバ並びにシグナリングサーバと、
   前記Ｗｅｂサーバからの呼び出し要求に応えて前記着信端末に呼び出し信号を送信する通知サーバと、を備え、
   前記発信端末Ａは、
   ＩＰ電話で前記着信端末Ｂに発呼するためのＵＲＬ（Ｂ）の入力を受け付ける処理と、
   前記ＵＲＬ（Ｂ）の入力を受けて、当該ＵＲＬ（Ｂ）の情報を含むＡ→Ｂ呼び出しを前記Ｗｅｂサーバに送信する処理と、を実行するように構成され、
   前記Ｗｅｂサーバは、
   前記Ａ→Ｂ呼び出しを受けて、予め登録されている前記着信端末ＢのＩＰ電話登録情報を前記ＵＲＬ（Ｂ）に基づいて読み出す処理と、
   前記ＩＰ電話登録情報に含まれる端末特定識別子およびＩＰ電話アプリを特定して、前記着信端末Ｂの呼び出し要求を、前記通知サーバに送信する処理と、を実行するように構成され、
   前記着信端末Ｂは、
   前記通知サーバから、前記ＩＰ電話アプリを指定した呼び出し信号を受け付ける処理と、
   前記呼び出し信号を受けて、前記ＩＰ電話アプリを起動すると共に着信表示を生じさせる処理と、
   前記着信表示に対する通話受諾の操作を受け付ける処理と、
   前記通話受諾の操作を受けて前記Ｗｅｂサーバに通話の受諾通知を送信する処理と、を実行するように構成され、
   前記Ｗｅｂサーバは、前記着信端末Ｂからの前記受諾通知を受けて、前記発信端末Ａおよび前記着信端末Ｂの双方に、前記シグナリングサーバにおける両者の待ち合わせ領域を示すＡ－Ｂ待ち合わせ情報を送信する処理を更に実行するように構成され、
   前記発信端末Ａおよび前記着信端末Ｂは、
   両者間にＰ２Ｐ経路を開設するために必要なＳＤＰの情報を前記Ａ－Ｂ待ち合わせ情報が示す前記待ち合わせ領域を介して交換する処理と、
   前記ＳＤＰに基づいて開設されたＰ２Ｐ経路を介して音声信号を互いに授受する処理と、を更に実行するように構成されたＷＥＢ電話システム。
2. 前記ＵＲＬ（Ｂ）の入力を受け付ける処理は、前記ＵＲＬ（Ｂ）の情報が埋め込まれた二次元バーコードを読み取る処理を含む請求項１に記載のＷＥＢ電話システム。
3. 前記ＳＤＰの情報を交換する処理は、
   前記発信端末Ａと前記着信端末Ｂのうち、前記待ち合わせ領域に遅れて入室した方が、自身のＳＤＰを含むオファーを他方に向けて送信する処理と、
   前記発信端末Ａと前記着信端末Ｂのうち、前記待ち合わせ領域に先に入室した方が、前記オファーに応えて、自身のＳＤＰを含むアンサーを他方に向けて送信する処理と、
   を含む請求項１または２に記載のＷＥＢ電話システム。
4. 発信端末Ａおよび着信端末Ｂとネットワークを介して通信可能なＷＥＢ電話用サーバ装置であって、
   前記発信端末Ａからの送信信号を受け付ける処理と、
   前記送信信号が、ＩＰ電話で前記着信端末Ｂに発呼するためのＵＲＬ（Ｂ）を含むＡ→Ｂ呼び出しであるかを判別する処理と、
   前記送信信号が前記Ａ→Ｂ呼び出しであった場合に、予め登録されている前記着信端末ＢのＩＰ電話登録情報を前記ＵＲＬ（Ｂ）に基づいて読み出す処理と、
   前記ＩＰ電話登録情報に含まれる端末特定識別子およびＩＰ電話アプリを特定して前記着信端末Ｂの呼び出し要求を通知サーバに送信して、当該通知サーバに、前記ＩＰ電話アプリを指定した呼び出し信号を前記着信端末Ｂに送信させる処理と、
   前記着信端末Ｂから、通話の受諾を意味する受諾通知を受け付ける処理と、
   前記着信端末Ｂからの前記受諾通知を受けて、前記発信端末Ａおよび前記着信端末Ｂの双方に、シグナリングサーバにおける両者の待ち合わせ領域を示すＡ－Ｂ待ち合わせ情報を送信する処理と、
   を実行するように構成されたＷＥＢ電話用サーバ装置。
5. スマートフォンをＩＰ電話の着信端末Ｂとして機能させるためのＷＥＢ電話用プログラムであって、
   前記着信端末ＢとしてＩＰ電話を着信するために必要なＩＰ電話登録情報を自身のＩＰ電話を発呼するためのＵＲＬ（Ｂ）と結び付けさせるためにＷｅｂサーバに送信する処理と、
   通知サーバからの呼び出し信号が、ＩＰ電話アプリに関する呼び出しであるか否かを判別する処理と、
   前記呼び出し信号が、前記ＩＰ電話アプリに関する呼び出しである場合に、当該ＩＰ電話アプリを起動して通話受諾の操作を待ち受ける処理と、
   前記通話受諾の操作が行われた場合に、前記Ｗｅｂサーバに向けて受諾通知を送信して、前記呼び出しの発信元である発信端末Ａとシグナリングサーバで待ち合わせるためのＡ－Ｂ待ち合わせ情報を待ち受ける処理と、
   前記Ｗｅｂサーバから前記Ａ－Ｂ待ち合わせ情報を受信したら、前記シグナリングサーバの前記Ａ－Ｂ待ち合わせ情報が示す待ち合わせ領域に入室して待機する処理と、
   前記発信端末ＡのＳＤＰの情報を含むオファーを、前記待ち合わせ領域を介して前記発信端末Ａから受け取る処理と、
   前記オファーに応えて、自身のＳＤＰの情報を含むアンサーを、前記待ち合わせ領域を介して前記発信端末Ａに送信する処理と、
   前記ＳＤＰの交換後に、当該ＳＤＰに基づいて前記発信端末Ａとの間にＰ２Ｐ経路を開設するための処理と、
   を前記スマートフォンに実行させるためのプログラムを含むＷＥＢ電話用プログラム。
6. ＩＰ電話を発信する発信端末と、ＩＰ電話を受信する少なくとも一つの着信端末とを通話可能に接続するＷＥＢ電話システムであって、
   前記発信端末および前記着信端末とネットワークを介して通信可能なＷｅｂサーバ並びにシグナリングサーバと、
   前記Ｗｅｂサーバからの呼び出し要求に応えて前記着信端末に呼び出し信号を送信する通知サーバと、を備え、
   前記Ｗｅｂサーバは、
   前記発信端末から、ＩＰ電話で前記着信端末に発呼するためのＵＲＬの入力を受け付ける処理と、
   前記ＵＲＬの入力を受けて、当該ＵＲＬに紐づけられた前記少なくとも一つの着信端末呼び出しを送信する処理と、を実行するように構成され、
   前記Ａ→Ｂ呼び出しを受けて、予め登録されている前記着信端末の端末特定識別子情報を前記ＵＲＬに基づいて読み出す処理と、
   前記端末特定識別子情報に含まれる端末特定識別子を特定して、前記着信端末Ｂの呼び出し要求を、前記通知サーバに送信する処理と、を実行するように構成され、
   前記通知サーバは、
   前記着信端末に、前記ＩＰ電話アプリを指定した呼び出し信号を発する処理と、
   前記Ｗｅｂサーバは、前記着信端末からの通話受諾を受信する処理と、を実行するように構成され、
   前記Ｗｅｂサーバは、前記着信端末からの前記受諾通知を受けて、前記発信端末および前記着信端末の双方に、前記シグナリングサーバにおける両者の待ち合わせ領域を示すＡ－Ｂ待ち合わせ情報を送信する処理を更に実行するように構成され、
   前記発信端末Ａおよび前記着信端末Ｂに対し、両者間にＰ２Ｐ経路を開設するために必要なＳＤＰの情報を発信するように構成されたＷＥＢ電話システム。

Images