JP4384529B2 - インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム - Google Patents

Description

本発明は、インターネットを介して通話するインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムに関する。

従来、この種のインターネット電話のネットワークは、以下のように構成されていた。

例えば、Ｈ．３２３プロトコルを用いたインターネット電話システムの場合、インターネット電話のネットワーク内にゲートキーパーという呼管理サーバを設ける。このゲートキーパーは通話したい宛先の電話番号を各電話機から一元的に受信して、前記電話番号を対応するＩＰアドレスに変換して、前記電話番号を発呼した電話機に返送する機能を有する。

一方、電話機では、オペレータが通話したい宛先の電話番号を入力すると、その電話番号を発呼する。電話機が前記電話番号に対応するＩＰアドレスをゲートキーパーから受信すると、オペレータの介在なく、前記ＩＰアドレスに基づいて通話したい宛先の電話機に対してゲートキーパーを介してアクセスし、あるいはゲートキーパーを介さず直接アクセスする。これにより、インターネットを介した電話機間の通話が可能になる（例えば、特許文献１参照）。

また、通常、ゲートキーパーと各電話機との間にはルータが介在する。前記ルータには複数のインターネット電話機が接続され、ネットワーク上のグループを形成する。同一グループ内の電話機には、ネットワークアドレスが共通なＩＰアドレスが割り当てられる。通常会社のオフィスでは、同一部署の電話機はネットワーク上の同一グループとして構成される。

図２８（ａ）は、一般的なインターネット電話システムのネットワークの構成を示す図である。同図に示すネットワークにおいては、呼管理サーバ（サーバ）２８０１にルータＡ２８０２とルータＢ２８０３が接続されている。ルータＡ２８０２にグループ（Ａ）を形成するＡ１〜Ａ４のインターネット電話機が接続され、ルータＢ２８０３にグループ（Ｂ）を形成するＢ１〜Ｂ４のインターネット電話機が接続されている。

図２８（ｂ）、（ｃ）は、このサーバ２８０１において管理される、各インターネット電話機に割り当てられた電話番号とその電話番号に対応するＩＰアドレスとが登録された管理表を示している。図２８（ｂ）は、グループ（Ａ）の管理表を示し、図２８（ｃ）は、グループ（Ｂ）の管理表を示している。ここで、電話番号としては会社内で用いられる内線番号を示している。

同図（ｂ）に示すように、インターネット電話機(端末)Ａ１〜Ａ４には、それぞれ電話番号として１００１〜１００４が割り当てられ、ＩＰアドレスとして１９２．１６８．１．１〜１９２．１６８．１．４が割り当てられている。すなわち、グループ（Ａ）の端末には、ネットワークアドレス（１９２．１６８．１）が共通なＩＰアドレスとして割り当てられている。

一方、同図（ｃ）に示すように、インターネット電話機(端末)Ｂ１〜Ｂ４には、それぞれ電話番号として２００１〜２００４が割り当てられ、ＩＰアドレスとして１９２．１６８．２．１〜１９２．１６８．２．４が割り当てられている。すなわち、グループ（Ｂ）の端末には、ネットワークアドレス（１９２．１６８．２）が共通なＩＰアドレスとして割り当てられている。
特開２００２−１０１１９８号公報（第４―５頁、第１図）

しかし、かかる従来の技術では、以下のような問題が生じていた。

即ち、ある部署の１つの電話機を宛先として電話した際、その電話機が話中の場合がある。この場合、通話者は一旦電話を切り、緊急の場合などは特に話中の電話機に隣接する電話機の番号を入力して、再度かけ直すという作業を行うことになる。このように、同一部署内の１つの電話機が話中の場合、再度改めて隣接する電話機にかけ直さなければならず、電話をする作業が大変煩雑なものになっていたという問題があった。

上述のネットワークの構成例を用いて説明する。例えば、端末Ａ１が端末Ｂ１を宛先として電話する場合について考える。図２９は、従来のインターネット電話システムにおける動作を示すシーケンス図である。

同図に示すように、端末Ａ１から端末Ｂ１に対して電話する場合、通話者は、まず、端末Ｂ１の電話番号（２００１）を入力する。この電話番号を受け付けると、端末Ａ１は、サーバ２８０１に端末Ｂ１のＩＰアドレスを問い合わせ、端末Ｂ１のＩＰアドレスの通知を受ける。そして、そのＩＰアドレスに基づいて端末Ｂ１に発呼する。

ここで、端末Ｂ１は話中であったものとする。端末Ｂ１が話中であるため、端末Ｂ１には接続することができず、端末Ａ１には話中音が鳴動する。この話中音を確認すると、通話者は一旦電話を切り、隣接する端末Ｂ２の電話番号（２００２）を入力する。端末Ｂ１の場合と同様に、サーバ２８０１から端末Ｂ２のＩＰアドレスの通知を受けると端末Ｂ２に発呼する。

ここで、端末Ｂ２も話中であったものとする。この場合、端末Ｂ２には接続することができず、端末Ａ１には話中音が鳴動する。この話中音を確認すると、通話者は一旦電話を切り、さらに隣接する端末Ｂ３の電話番号（２００３）を入力する。端末Ｂ１、Ｂ２の場合と同様に、サーバ２８０１から端末Ｂ３のＩＰアドレスの通知を受けると端末Ｂ３に発呼する。

ここで、端末Ｂ３は、話中でなかったものとする。この場合、端末Ｂ３が話中でないため、端末Ａ１は端末Ｂ３と接続する。そして、例えば、端末Ｂ１のオペレータへのメッセージ等を端末Ｂ３のオペレータに伝える。このように同一部署内の１つの端末が話中の場合、再度改めて隣接する端末にかけ直さなければならない事態が生じている。

本発明は、かかる問題点に鑑みて為されたものであり、通話したい宛先の電話機が応答しない場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができるインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムを提供することを目的とする。

本発明は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩを前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させる制御手段とを備えるものである。

本発明に係るインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムによれば、通話したい宛先の電話機が応答しない場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。

本発明の第１の態様に係るインターネット電話機は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩを前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させる制御手段と、を具備する構成を採る。

この構成によれば、サーバから受信した複数のＵＲＩのうち、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。特に、複数の電話機と連続して接続できないような場合、操作負担を軽減する効果は一層大きくなる。

本発明の第２の態様に係るインターネット電話機は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させる制御手段と、を具備する構成を採る。

この構成によれば、サーバから複数のＵＲＩを受信した場合であってＰｒｅｆｅｒｅｎｃｅフィールドの設定値が差異を有する場合、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値の大小関係に応じて発呼動作が行われる。これにより、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値に応じて発呼順序が決定されるので、発呼順序を指定することができる。

本発明の第３の態様は、第２の態様に係るインターネット電話機において、前記制御手段は、前記設定値が小さいＵＲＩに対応する宛先から優先して発呼させる構成を採る。

この構成によれば、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値が小さいＵＲＩに対応する宛先から優先して発呼されるので、発呼させたい順番に設定値を定めることで発呼順序を指定することができる。

本発明の第４の態様は、第２の態様に係るインターネット電話機において、前記制御手段は、前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに対応する宛先に一斉に発呼させる構成を採る。

この構成によれば、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値が同一の場合には全てのＵＲＩに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。

本発明の第５の態様は、第２の態様に係るインターネット電話機において、前記制御手段は、前記設定値を無視する指示を受け付けると前記設定値を無視して全てのＵＲＩに対応する宛先に一斉に発呼させる構成を採る。

この構成によれば、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値を無視する指示を受け付けると、この設定値を無視して全てのＵＲＩに対応する宛先に一斉に発呼する。これにより、設定値が差異を有する場合においても、この設定を無視する指示を受け付けた場合には全てのＵＲＩに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。

本発明の第６の態様に係るインターネット電話機は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させ、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行させる制御手段と、を具備する構成を採る。

この構成によれば、サーバから複数のＵＲＩを受信した場合であってＳｅｒｖｉｃｅフィールドに設定された通信種別（プロトコル）にｓｉｐ及びｓｉｐ以外の通信種別が存在する場合、通信種別にｓｉｐと設定されたＵＲＩに対応する宛先に発呼動作を行わせ、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

また、Ｓｅｒｖｉｃｅフィールドに設定された通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行する。これにより、ｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合においても、予めｓｉｐ以外の通信種別を用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。

本発明の第７の態様は、第６の態様に係るインターネット電話機において、前記受信手段は、前記ｓｉｐ以外の通信種別として電子メール又は電話でのＦＡＸを受信し、前記制御手段は、前記電子メール又は電話でのＦＡＸと設定されたＵＲＩが示す宛先に予め用意された定型文を送信する構成を採る。

この構成によれば、Ｓｅｒｖｉｃｅフィールドに設定された通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合に電子メール又は電話でのＦＡＸと設定されたＵＲＩが示す宛先に予め用意された定型文が送信される。これにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。

本発明の第８の態様は、第１の態様に係るインターネット電話機において、前記受信手段は前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行う構成を採る。

この構成によれば、サーバから複数のＵＲＩを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、オペレータから指定された発呼順序に従って発呼動作が行われる。これにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。

本発明の第９の態様は、第１から第６のいずれかの態様に係るインターネット電話機において、前記受信手段はＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行う構成を採る。

この構成によれば、ＵＲＩに含まれるポート番号とＵＲＩに応じたＩＰアドレスとで特定される宛先に対して発呼するので、例えば、インターネット電話機にプライベートＩＰアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。

本発明の第１０の態様は、第１から第９のいずれかの態様に係るインターネット電話機において、前記制御手段は、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼させる構成を採る。

この構成によれば、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、話中や所定時間継続して応答しない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

本発明の第１１の態様に係るネットワークサーバは、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶する記憶手段と、前記代表番号による問い合わせを受けると当該代表番号に対応する各インターネット電話機のＵＲＩを返送し、ＵＲＩによる問い合わせを受けると当該ＵＲＩに応じたＩＰアドレスを返送する制御手段と、を具備する構成を採る。

この構成によれば、特定の電話番号に対応するＵＲＩの問い合わせを受けると隣接して設置されたインターネット電話機の電話番号に対応する複数のＵＲＩを返送する。ＵＲＩを問い合わせたインターネット電話機において、受信した複数のＵＲＩのうち、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

本発明の第１２の態様は、第１１の態様に係るネットワークサーバにおいて、前記記憶手段が記憶するＮＡＰＴＲリソースレコードにはＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含み、前記制御手段は前記代表番号による問い合わせを受けると前記設定値も合わせて返送する構成を採る。

この構成によれば、特定の電話番号に対応するＵＲＩの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のＵＲＩ及び差異を有する設定値を返送する。ＵＲＩを問い合わせたインターネット電話機において、複数のＵＲＩを受信した場合であってＰｒｅｆｅｒｅｎｃｅフィールドの設定値が差異を有する場合、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、ＵＲＩを問い合わせたインターネット電話機において、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値の大小関係に応じて発呼動作を行うことにより、Ｐｒｅｆｅｒｅｎｃｅフィールドの設定値に応じて発呼順序が決定されるので、発呼順序を指定することができる。

本発明の第１３の態様は、第１１の態様に係るネットワークサーバにおいて、前記記憶手段が記憶するＮＡＰＴＲリソースレコードにはＳｅｒｖｉｃｅフィールドの通信種別を含み、前記制御手段は前記代表番号による問い合わせを受けると前記通信種別も合わせて返送する構成を採る。

この構成によれば、特定の電話番号に対応するＵＲＩの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のＵＲＩ及び当該複数のＵＲＩに応じたｓｉｐ及びｓｉｐ以外の通信種別を返送する。ＵＲＩを問い合わせたインターネット電話機において、複数のＵＲＩを受信した場合であってＳｅｒｖｉｃｅフィールドに設定された通信種別にｓｉｐ及びｓｉｐ以外の通信種別が存在する場合、通信種別にｓｉｐと設定されたＵＲＩに対応する宛先に発呼動作を行わせ、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

また、ＵＲＩを問い合わせたインターネット電話機において、Ｓｅｒｖｉｃｅフィールドに設定された通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行することにより、ｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合においても、予めｓｉｐ以外の通信種別を用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。

本発明の第１４の態様は、第１３の態様に係るネットワークサーバにおいて、前記通信種別としてｓｉｐ又は電子メール又は電話でのＦＡＸを登録する構成を採る。

この構成によれば、ＵＲＩを問い合わせたインターネット電話機において、Ｓｅｒｖｉｃｅフィールドに設定された通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合に電子メール又は電話でのＦＡＸと設定されたＵＲＩが示す宛先に予め用意された定型文を送信することにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。

本発明の第１５の態様は、第１１の態様に係るネットワークサーバにおいて、前記記憶手段は前記グループ内の各インターネット電話機のオペレータの識別情報も記憶し、前記制御手段は前記ＵＲＩによる問い合わせを受けると前記識別情報も合わせて返送する構成を採る。

この構成によれば、特定の電話番号に対応するＵＲＩの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のＵＲＩ及び当該複数のＵＲＩに応じた識別情報を返送する。ＵＲＩを問い合わせたインターネット電話機において、複数のＵＲＩを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、ＵＲＩを問い合わせたインターネット電話機において、オペレータから指定された発呼順序に従って発呼動作を行うことにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。

本発明の第１６の態様は、第１１の態様に係るネットワークサーバにおいて、前記ＮＡＰＴＲリソースレコード上のＵＲＩにポート番号を含む構成を採る。

この構成によれば、ＵＲＩを問い合わせたインターネット電話機において、ＵＲＩに含まれるポート番号とＵＲＩに応じたＩＰアドレスとで特定される宛先に対して発呼することにより、例えば、インターネット電話機にプライベートＩＰアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。

本発明の第１７の態様に係る通話方法は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩを返送し、前記返送された複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼するものである。

本発明の第１８の態様に係る通話方法は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記設定値並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記設定値を返送し、前記返送された複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼するものである。

本発明の第１９の態様は、第１８の態様に係る通話方法において、前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに応じたＩＰアドレスの宛先に一斉に発呼するものである。

本発明の第２０の態様に係る通話方法は、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記通信種別並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記通信種別を返送し、前記返送された複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼し、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行するものである。

本発明の第２１の態様は、第１７の態様に係る通話方法において、前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行うものである。

本発明の第２２の態様は、第１７から第２０のいずれかの態様に係る通話方法において、ＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行うものである。

本発明の第２３の態様に係るインターネット電話システムは、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩを返送し、前記返送された複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼するものである。

本発明の第２４の態様に係るインターネット電話システムは、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記設定値並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記設定値を返送し、前記返送された複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼するものである。

本発明の第２５の態様は、第２４の態様に係るインターネット電話システムにおいて、前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに応じたＩＰアドレスの宛先に一斉に発呼するものである。

本発明の第２６の態様に係るインターネット電話システムは、複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記通信種別並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記通信種別を返送し、前記返送された複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼し、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行するものである。

本発明の第２７の態様は、第２３の態様に係るインターネット電話システムにおいて、前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行うものである。

本発明の第２８の態様は、第２３から第２６のいずれかの態様に係るインターネット電話システムにおいて、ＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行うものである。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係るインターネット電話機が適用されるネットワークの構成を示す図である。同図に示すネットワークにおいては、呼管理サーバ（以下、「サーバ」という）１０１にルータＡ１０２とルータＢ１０３が接続されている。ルータＡ１０２にグループ（Ａ）を形成するＡ１〜Ａ４のインターネット電話機が接続され、ルータＢ１０３にグループ（Ｂ）を形成するＢ１〜Ｂ４のインターネット電話機が接続されている。それぞれのグループは、会社内の部署毎に設定され、部署におけるインターネット電話機の配置は、同図に示す配置と同一であるものとする。

なお、図１においては、各ルータにインターネット電話機が接続された場合について示しているが、このインターネット電話機は、通常の電話機（インターネット電話機の機能を有しないもの）をインターネット電話機の機能を実現させる制御装置（以下、「制御アダプタ」という）に接続して構成してもよい。以下の本実施の形態の説明では、かかる制御アダプタに通常の電話機を接続したものをインターネット電話機として説明する。

図２は、図１に示すネットワークに接続されたインターネット電話機に割り当てられた電話番号及びＩＰアドレスを示す図である。図２（ａ）はグループ（Ａ）を構成するインターネット電話機に割り当てられた電話番号及びＩＰアドレスを示し、図２（ｂ）はグループ（Ｂ）を構成するインターネット電話機に割り当てられた電話番号及びＩＰアドレスを示している。

同図（ａ）に示すように、インターネット電話機(端末)Ａ１〜Ａ４には、それぞれ電話番号として０３１０００００００〜０３１００００００３が割り当てられ、ＩＰアドレスとして１９２．１６８．１．１〜１９２．１６８．１．４が割り当てられている。また、同図（ｂ）に示すように、インターネット電話機(端末)Ｂ１〜Ｂ４には、それぞれ電話番号として０３１０００１０００〜０３１０００１００３が割り当てられ、ＩＰアドレスとして１９２．１６８．２．１〜１９２．１６８．２．４が割り当てられている。なお、グループ（Ａ）及びグループ（Ｂ）においてはそれぞれ端末Ａ１及び端末Ｂ１に割り当てられた電話番号が代表番号とされている。

図３は、実施の形態１に係るインターネット電話機の構成を示すブロック図である。

同図に示すように、本実施の形態に係るインターネット電話機は、制御アダプタ３０１に通常の電話機３０２を接続して構成される。なお、本実施の形態に係る制御アダプタ３０１は、２台の通常の電話機３０２を接続可能であり、各電話機をインターネット電話機として機能させることができる。なお、制御アダプタ３０１が接続可能な電話機を３台以上にすることも当然に可能である。

制御アダプタ３０１は、装置本体の全体を制御するＣＰＵ３０３を備えている。このＣＰＵ３０３に制御バス３０４を介してＲＯＭ３０５及びＲＡＭ３０６が接続されている。ＲＯＭ３０５には、ＣＰＵ３０３が読み込んで実行する本制御アダプタ３０１の制御プログラムが格納されている。ＲＡＭ３０６は、ＣＰＵ３０３が制御プログラムを実行する際のワークメモリとして機能する。なお、本制御アダプタ３０１においては、ＲＯＭ３０５としてフラッシュＲＯＭを用い、ＲＡＭ３０６としてＳＤＲＡＭを用いる。

また、ＣＰＵ３０３にポート３０７を介してクロスポイントミキサ３０８が接続されている。クロスポイントミキサ３０８は、後述するＮＣＵを介して接続された２台の電話機に提供する通話路の切換え機能及びミキシング機能を備える。

クロスポイントミキサ３０８にＮＣＵ（Network Control Unit）３０９が接続されている。ＮＣＵ３０９は、本制御アダプタ３０１に接続された電話回線を制御して通信相手との回線の接続又は切断を行う。

さらに、ＣＰＵ３０３に制御バス３０４を介してＡ／Ｄ・Ｄ／ＡＣＯＤＥＣ３１０及びＬＡＮコントローラ３１１が接続されている。Ａ／Ｄ・Ｄ／ＡＣＯＤＥＣ３１０は、電話機３０２から入力された音声データのアナログ／デジタル変換を行った後、圧縮処理を施す。一方、ＬＡＮコントローラ３１１を介して受け取った圧縮データを復元した後、デジタル／アナログ変換処理を施す。

ＬＡＮコントローラ３１１は、本制御アダプタ３０１が接続されたネットワークを構成するイーサネット（Ｒ）との間で信号の制御を行う。なお、ネットワーク上を送信されるパケットデータの組立て及び解析は、ＬＡＮコントローラ３１１によって行われる。

なお、以上の制御アダプタ３０１に通常の電話機を接続せずに、インターネット電話機でかかる構成を実現する場合には、本制御アダプタ３０１の機能を有する制御ボードをインターネット電話機に搭載することで実現可能である。

図４は、実施の形態１に係るサーバ１０１の概略構成を示すブロック図である。実施の形態１に係るサーバ１０１は、ホスト名の問い合わせに応じてＩＰアドレスを通知するＤＮＳ（Domain Name System）サーバとしての機能を有する。特に、本実施の形態では、ホスト名が電話番号で特定されるＥＮＵＭ（Telephone Number Mapping）技術を取り入れたサーバ（ＥＮＵＭサーバ）としての機能を有する。

同図に示すように、実施の形態１に係るサーバ１０１は、サーバ１０１全体の制御を行う制御手段としてのＣＰＵ４０１を備えている。このＣＰＵ４０１に制御バス４０２を介して記憶手段としてのメモリ４０３、ネットワークインターフェイス（Ｉ／Ｆ）４０４及び入出力装置４０５が接続されている。

メモリ４０３は、ＣＰＵ４０１が読み込んで実行する本サーバ１０１の制御プログラムを格納するＲＯＭ及びＣＰＵ４０１が制御プログラムを実行する際のワークメモリとして機能するＲＡＭの機能を有する。

メモリ４０３は、ネットワークを介して接続された各インターネット電話機に割り当てられた電話番号からＵＲＩ（Uniform Resource Identifier）への変換を行うためのデータベースを格納している。かかるデータベースにおいて、データはＮＡＰＴＲ（The Naming Authority Pointer）と呼ばれるリソースレコード（以下、「ＮＡＰＴＲリソースレコード」という）で記述されている。ＮＡＰＴＲリソースレコードは、単一又は複数のＮＡＰＴＲレコードから構成される。また、メモリ４０３は、電話番号から変換されたＵＲＩと対応付けられるＩＰアドレスを登録している。

ネットワークＩ／Ｆ４０４は、本サーバ１０１が接続されたネットワークを構成するイーサネット（Ｒ）との間で信号の制御を行う。入出力装置４０５は、キーボードやマウス等の入力手段と液晶モニタ等の出力手段で構成され、オペレータの入力を受け付ける一方、本サーバ１０１における動作状態を出力する。

図５は、実施の形態１に係るサーバ１０１のメモリ４０３に記述されたＮＡＰＴＲリソースレコードの一例を示す図である。図５（ａ）は、図１に示すグループ（Ａ）に対応したＮＡＰＴＲリソースレコードを示し、図５（ｂ）は、図１に示すグループ（Ｂ）に対応したＮＡＰＴＲリソースレコードを示している。

図５（ａ）に示すように、端末Ａ１の電話番号（代表番号）「０３１０００００００」から得られるドメイン名「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対して４つのＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」が対応付けられている。同様に、端末Ａ２、Ａ３及びＡ４の電話番号「０３１００００００１」、「０３１００００００２」及び「０３１００００００３」から得られるドメイン名「１．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」、「２．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」及び「３．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」にそれぞれＵＲＩ「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」が対応付けられている。このように端末Ａ１の電話番号から得られるドメイン名に対して、端末Ａ１に対応するＵＲＩのみならず、端末Ａ２〜Ａ４に対応するＵＲＩも対応付けられている。

また、図５（ｂ）に示すように、端末Ｂ１の電話番号（代表番号）「０３１００１００００」から得られるドメイン名「０．０．０．１．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に４つのＵＲＩ「８１３１０００１０００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１０００１００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１０００１００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００１０００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」が対応付けられている。同様に、端末Ｂ２、Ｂ３及びＢ４の電話番号「０３１０００１００１」、「０３１０００１００２」及び「０３１０００１００３」から得られるドメイン名「１．０．０．１．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」、「２．０．０．１．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」及び「３．０．０．１．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」にそれぞれＵＲＩ「８１３１０００１００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１０００１００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１０００１００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」が対応付けられている。図５（ａ）と同様に、端末Ｂ１の電話番号から得られるドメイン名に対して、端末Ｂ１に対応するＵＲＩのみならず、端末Ｂ２〜Ｂ４に対応するＵＲＩも対応付けられている。

図６は、実施の形態１に係るサーバ１０１のメモリ４０３に記憶されたＵＲＩ及びＩＰアドレスの対応関係の一例を示す図である。図６（ａ）は、図１に示すグループ（Ａ）に対応するＵＲＩ及びＩＰアドレスを示し、図６（ｂ）は、図１に示すグループ（Ｂ）に対応するＵＲＩ及びＩＰアドレスを示している。

図６（ａ）に示すように、ＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」にそれぞれＩＰアドレス「１９２．１６８．１．１」、「１９２．１６８．１．２」、「１９２．１６８．１．３」及び「１９２．１６８．１．４」が対応付けられている。

また、図６（ｂ）に示すように、ＵＲＩ「８１３１０００１０００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１０００１００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１０００１００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１０００１００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」にそれぞれＩＰアドレス「１９２．１６８．２．１」、「１９２．１６８．２．２」、「１９２．１６８．２．３」及び「１９２．１６８．２．４」が対応付けられている。

以下、上記構成を有するサーバ１０１に接続された本インターネット電話機間で発呼を行う場合の動作について図７を用いて説明する。ここでは、特に端末Ｂ１からグループ（Ａ）に含まれる端末に発呼する場合の動作について説明する。なお、サーバ１０１のメモリ４０３には、図５に示すＮＡＰＴＲリソースレコード及び図６に示す対応表が登録されているものとする。

グループ（Ａ）の端末に発呼する場合、端末Ｂ１は、端末Ａ１〜Ａ４のいずれかの電話番号の入力をオペレータから受け付ける（ＳＴ７０１）。例えば、端末Ａ１に対して発呼する場合には、「０３１０００００００」あるいは「０３」を省略した「１０００００００」の入力をオペレータから受け付ける。

電話番号を受け付けると、端末Ｂ１は、この電話番号に対応するＵＲＩをサーバ１０１に対して問い合わせる（ＳＴ７０２）。上述の例の場合、端末Ｂ１は、オペレータが入力した「０３１０００００００」を国番号付きのＥ．１６４番号である「＋８１−３−１０００００００」に変換し、先頭の＋と数字を残して「＋８１３１０００００００」としてから数字以外の文字を抹消して数字間にドットを挿入して「８．１．３．１．０．０．０．０．０．０．０」とし、次に数字を逆順にして最後に文字列．ｅ１６４．ａｒｐａを追加することにより、ドメイン名である「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」を得て、この文字列に対応するＵＲＩを問い合わせる。

ＵＲＩの問い合わせを受けると、サーバ１０１がメモリ４０３に格納されたＮＡＰＴＲリソースレコードに従ってＵＲＩを返してくるので、端末Ｂ１は、このＵＲＩを受信する（ＳＴ７０３）。上述の例の場合、サーバ１０１は、図５（ａ）に示したＮＡＰＴＲリソースレコードに従って、上記文字列に対応する４つのＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を返してくる。

ＵＲＩを受信したならば、端末Ｂ１は、ＵＲＩが複数存在するか判断する（ＳＴ７０４）。ここでＵＲＩが複数存在するか判断するのは、後述する通常発呼処理及びグループ発呼処理のいずれを行うべきか判断するためである。

ＵＲＩが複数存在しない場合、すなわち、単一のＵＲＩを受信した場合には処理をＳＴ７０５に移行し通常発呼処理を行う。一方、複数存在する場合、すなわち、複数のＵＲＩを受信した場合には処理をＳＴ７０６に移行しグループ発呼処理を行う。通常発呼処理においては単一の宛先に対して発呼処理が行われるのに対し、グループ発呼処理においては複数の宛先に対して発呼処理が行われる。上述の例の場合には、４つのＵＲＩが存在するのでグループ発呼処理が行われる。なお、通常発呼処理及びグループ発呼処理の詳細な処理については後述する。

通常発呼処理又はグループ発呼処理を行った後、端末Ｂ１は、いずれかの発呼処理の結果（以下、「発呼結果」という）の状態が「通話ＯＫ」であるか判断する（ＳＴ７０７）。発呼結果の状態には「通話ＯＫ」、「通話ＮＧ」及び「待機中」があり、いずれかの状態がＲＡＭ３０６上の所定領域に登録される。

発呼結果の状態が「通話ＯＫ」の場合には通話処理に移行する一方（ＳＴ７０８）、「通話ＯＫ」以外の場合には切断処理に移行する（ＳＴ７０９）。通話処理においては、端末Ｂ１のオペレータと発呼先のオペレータとの通話が終わり次第、端末Ｂ１による発呼処理が終了する。切断処理においては、移行すると同時に端末Ｂ１による発呼処理が終了する。

ここで、実施の形態１における通常発呼処理について図８を用いて説明する。図８は、実施の形態１における通常発呼処理について説明するためのフロー図である。

通常発呼処理に移行した場合、端末Ｂ１は、受信したＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる（ＳＴ８０１）。例えば、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」をＵＲＩとして受信した場合には、このＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる。

ＩＰアドレスの問い合わせを受けると、サーバ１０１がメモリ４０３に登録された対応表に従ってＩＰアドレスを返してくるので、端末Ｂ１は、このＩＰアドレスを受信する（ＳＴ８０２）。上述の例の場合、サーバ１０１は、図６（ａ）に示した対応表に従って、ＩＰアドレス「１９２．１６８．１．２」を返してくる。

ＩＰアドレスを受信したならば、端末Ｂ１は、発呼結果の状態を初期化する（ＳＴ８０３）。具体的には、発呼結果の状態を「待機中」に設定することにより発呼結果の状態を初期化する。

次に、端末Ｂ１は、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ８０４）。上述の例の場合、「１９２．１６８．１．２」に対して発呼処理を行う。すなわち、端末Ａ２に対して発呼処理が行われる。

発呼処理を行った後、端末Ｂ１は、当該宛先と接続できたかを判断する（ＳＴ８０５）。ここで、接続できたならば、端末Ｂ１は、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ８０６）、通常発呼処理を終了する。一方、接続できなかったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ８０７）、通常発呼処理を終了する。このように通常発呼処理においては単一の宛先に対して発呼処理を行い、その宛先に対する接続の可否に応じて発呼結果の状態が切り替えられる。

なお、宛先と接続できない場合としては、例えば、宛先が話中である場合や宛先のオペレータが不在で所定時間応答しない場合（無応答の場合）が該当する。無応答の場合には、タイマで所定時間をカウントし、所定時間継続して宛先からリングバックトーンを示す信号が出力された場合に接続できないと判断することが一般的である。

次に、実施の形態１におけるグループ発呼処理について図９を用いて説明する。図９は、実施の形態１におけるグループ発呼処理について説明するためのフロー図である。

グループ発呼処理に移行した場合、端末Ｂ１は、受信したＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる（ＳＴ９０１）。グループ発呼処理に移行した場合には複数のＵＲＩが受信されているため、端末Ｂ１は、いずれかのＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる。例えば、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」をＵＲＩとして受信した場合には、いずれかのＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる。

端末Ｂ１からこのＵＲＩによりＩＰアドレスの問い合わせを受けると、通常発呼処理における説明と同様に、サーバ１０１からＩＰアドレスが返されてくるので、端末Ｂ１は、これを受信する（ＳＴ９０２）。ＩＰアドレスを受信したならば、発呼結果の状態を初期化した後（ＳＴ９０３）、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ９０４）。そして、当該宛先と接続できたかを判断し（ＳＴ９０５）、接続できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ９０６）、グループ発呼処理を終了する。

これに対して、接続できなかった場合には、端末Ｂ１は、対応するＩＰアドレスを問い合わせしていないＵＲＩが存在するか判断する（ＳＴ９０７）。問い合わせしていないＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ９０１に戻し、問い合わせしていないＵＲＩが存在しなくなるまでＳＴ９０１〜ＳＴ９０７の処理を繰り返す。４つのＵＲＩを受信した場合には最高４回までＳＴ９０１〜ＳＴ９０７の処理が行われる。

ＳＴ９０１〜ＳＴ９０７の処理を繰り返すうちにＩＰアドレスを問い合わせしていないＵＲＩが存在しなくなったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ９０８）、グループ発呼処理を終了する。このようにグループ発呼処理においては複数の宛先に対して発呼処理を行い、全ての宛先に対して接続ができなかった場合に発呼結果の状態が「通話ＮＧ」に設定される。

なお、ここでは、対応するＩＰアドレスを問い合わせるＵＲＩを任意に選択可能とし、特にそのＵＲＩの優先順位は決めていない。問い合わせしていないＵＲＩが存在しなくなった時点でＳＴ９０８において発呼結果が「通話ＮＧ」と切り替えられることとなる。

以下、このグループ発呼処理を実行することで、端末Ｂ１とグループ（Ａ）に含まれる端末との間で行われるシーケンスについて図１０を用いて説明する。なお、図１０においては、端末Ｂ１から端末Ａ１に割り当てられた代表番号「０３１０００００００」を発呼した場合のシーケンスについて示している。

端末Ｂ１のオペレータから電話番号「０３１０００００００」の入力を受け付けると、端末Ｂ１は、かかる電話番号に対応するＵＲＩを問い合わせる（ＳＴ１００１）。これに応じてサーバ１０１から当該電話番号に対応するＵＲＩの通知を受ける（ＳＴ１００２）。このとき、端末Ｂ１は、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」の４つのＵＲＩの通知を受ける。

次に、端末Ｂ１は、いずれかのＵＲＩに対応するＩＰアドレスを問い合わせ（ＳＴ１００３）、サーバ１０１から当該ＵＲＩに対応するＩＰアドレスの通知を受ける（ＳＴ１００４）。ここでは、ＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスを問い合わせ、ＩＰアドレス「１９２．１６８．１．１」の通知を受けたものとする。ＩＰアドレスの通知を受けると、端末Ｂ１は、当該ＩＰアドレスに対して発呼する（ＳＴ１００５）。これにより、端末Ａ１に対する発呼処理が行われる。

ここで、端末Ａ１は、話中等で接続ができなかったものとする。この場合、端末Ｂ１は、先にＩＰアドレスを問い合わせしたＵＲＩ以外のいずれかのＵＲＩに対応するＩＰアドレスを問い合わせ（ＳＴ１００６）、サーバ１０１から当該ＵＲＩに対応するＩＰアドレスの通知を受ける（ＳＴ１００７）。ここでは、ＵＲＩ「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスを問い合わせ、ＩＰアドレス「１９２．１６８．１．２」の通知を受けたものとする。ＩＰアドレスの通知を受けると、端末Ｂ１は、当該ＩＰアドレスに対して発呼する（ＳＴ１００８）。これにより、端末Ａ２に対する発呼処理が行われる。

ここで、端末Ａ２も、話中等で接続ができなかったものとする。この場合、端末Ｂ１は、更に先にＩＰアドレスを問い合わせしたＵＲＩ以外のいずれかのＵＲＩに対応するＩＰアドレスを問い合わせ（ＳＴ１００９）、サーバ１０１から当該ＵＲＩに対応するＩＰアドレスの通知を受ける（ＳＴ１０１０）。ここでは、ＵＲＩ「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスを問い合わせ、ＩＰアドレス「１９２．１６８．１．３」の通知を受けたものとする。ＩＰアドレスの通知を受けると、端末Ｂ１は、当該ＩＰアドレスに対して発呼する（ＳＴ１０１１）。これにより、端末Ａ３に対する発呼処理が行われる。

ここで、端末Ａ３は、話中等で接続ができない事態にないものとする。したがって、端末Ｂ１は、端末Ａ３を利用するオペレータと通話することが可能となる。なお、ここでは、対応するＩＰアドレスを問い合わせるＵＲＩの順番として、端末Ａ１、端末Ａ２、端末Ａ３の順番に処理を行ったが、当該順番は一例に過ぎず、他のどのような順番で処理を行うようにしてもよい。

このように実施の形態１に係るインターネット電話機によれば、サーバ１０１から受信した複数のＵＲＩのうち、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。特に、複数の電話機と連続して接続できないような場合、操作負担を軽減する効果は一層大きくなる。

特に、実施の形態１に係るインターネット電話機においては、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、話中や所定時間継続して応答しない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。かかる効果は以下の実施の形態においても同様である。

（実施の形態２）
実施の形態１に係るインターネット電話機がサーバ１０１から複数のＵＲＩを受信した場合に任意のＵＲＩを選択してＩＰアドレスを問い合わせた後、当該ＩＰアドレスに対応する宛先に対して発呼するのに対し、実施の形態２に係るインターネット電話機は、ＵＲＩを選択する際に優先順位を設け、その優先順位に従ってＩＰアドレスを問い合わせた後、当該ＩＰアドレスに対応する宛先に対して発呼する点で相違する。

実施の形態２に係るインターネット電話機は、ＵＲＩを選択する際の優先順位を判断するパラメータとしてＮＡＰＴＲリソースレコードに記述されたＰｒｅｆｅｒｅｎｃｅフィールドの値（以下、「Ｐｒｅｆｅｒｅｎｃｅ値」という）を利用する。Ｐｒｅｆｅｒｅｎｃｅ値は、Ｏｒｄｅｒフィールドに同じ値を有するＮＡＰＴＲレコードが複数ある場合に処理順序を決めるものであるが、実施の形態２に係るインターネット電話機は、このＰｒｅｆｅｒｅｎｃｅ値を、ＵＲＩを選択する際の優先順位を判断するパラメータとして用いることで、複数存在する宛先に対して優先順位を付けて発呼する。

図１１は、実施の形態２に係るサーバ１０１のメモリ４０３に記述されたＮＡＰＴＲリソースレコードの一例を示す図である。図１１においては、図１に示すグループ（Ａ）に対応したＮＡＰＴＲリソースレコードを示している。

同図においては、そのＰｒｅｆｅｒｅｎｃｅ値を除き、図５（ａ）に示すＮＡＰＴＲリソースレコードと同一であるため、その詳細な説明は省略する。図１１に示すＮＡＰＴＲリソースレコードにおいては、異なるＰｒｅｆｅｒｅｎｃｅ値が設定されている点で図５（ａ）に示すＮＡＰＴＲリソースレコードと相違する。

図１１においては、端末Ａ１の電話番号（代表番号）「０３１０００００００」から得られるドメイン名「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対応付けられた４つのＵＲＩのうち、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「１０」が設定されている。また、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「２０」が設定され、同様に、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「３０」が設定され、「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「４０」が設定されている。

以下、上記構成を有するサーバ１０１に接続された本インターネット電話機間で発呼を行う場合の動作について図１２を用いて説明する。ここでは、特に端末Ｂ１からグループ（Ａ）に含まれる端末に発呼する場合の動作について説明する。なお、サーバ１０１のメモリ４０３には、図１１及び図６に示す内容が登録されているものとする。

グループ（Ａ）の端末に発呼する場合、端末Ｂ１は、端末Ａ１〜Ａ４のいずれかの電話番号の入力をオペレータから受け付ける（ＳＴ１２０１）。例えば、端末Ａ１に対して発呼する場合には、「０３１０００００００」あるいは「０３」を省略した「１０００００００」をオペレータから受け付ける。

電話番号を受け付けると、端末Ｂ１は、この電話番号に対応するＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値をサーバ１０１に対して問い合わせる（ＳＴ１２０２）。上述の例の場合、端末Ｂ１は、「０３１０００００００（１０００００００）」から文字列「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」を得て、この文字列に対応するＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値を問い合わせる。

ＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値の問い合わせを受けると、サーバ１０１がメモリ４０３に格納されたＮＡＰＴＲリソースレコードに従ってＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値を返してくるので、端末Ｂ１は、このＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値を受信する（ＳＴ１２０３）。上述の例の場合、サーバ１０１は、図１１に示したＮＡＰＴＲリソースレコードに従って、この文字列に対応する４つのＵＲＩ及びＰｒｅｆｅｒｅｎｃｅ値を返してくる。具体的には、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「１０」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「２０」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「３０」、並びに、「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「４０」を返してくる。

ＵＲＩ等を受信したならば、端末Ｂ１は、ＵＲＩが複数存在するか判断する（ＳＴ１２０４）。受信したＵＲＩが複数存在しない場合には処理をＳＴ１２０５に移行し通常発呼処理を行う。一方、複数存在する場合には処理をＳＴ１２０６に移行しグループ発呼処理を行う。なお、実施の形態２における通常発呼処理については図８に示す説明と同様のため、その説明を省略する。また、実施の形態２におけるグループ発呼処理については後述する。

通常発呼処理又はグループ発呼処理を行った後、端末Ｂ１は、発呼結果の状態が「通話ＯＫ」であるか判断する（ＳＴ１２０７）。発呼結果の状態が「通話ＯＫ」の場合には通話処理に移行する一方（ＳＴ１２０８）、「通話ＯＫ」以外の場合には切断処理に移行する（ＳＴ１２０９）。通話処理においては、端末Ｂ１のオペレータと発呼先のオペレータとの通話が終わり次第、端末Ｂ１の発呼処理が終了する。切断処理においては、移行すると同時に端末Ｂ１の発呼処理が終了する。

ここで、実施の形態２におけるグループ発呼処理について図１３を用いて説明する。図１３は、実施の形態２におけるグループ発呼処理について説明するためのフロー図である。

グループ発呼処理に移行した場合、端末Ｂ１は、受信したＰｒｅｆｅｒｅｎｃｅ値の大小関係を判断する（ＳＴ１３０１）。そして、最小のＰｒｅｆｅｒｅｎｃｅ値についてのＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる（ＳＴ１３０２）。

端末Ｂ１からこのＵＲＩによりＩＰアドレスの問い合わせを受けると、サーバ１０１からＩＰアドレスが返されてくるので、端末Ｂ１は、これを受信する（ＳＴ１３０３）。ＩＰアドレスを受信したならば、発呼結果の状態を初期化した後（ＳＴ１３０４）、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ１３０５）。そして、当該宛先と接続できたかを判断し（ＳＴ１３０６）、接続できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ１３０７）、グループ発呼処理を終了する。

これに対して、接続できなかった場合には、端末Ｂ１は、対応するＩＰアドレスを問い合わせしていないＵＲＩが存在するか判断する（ＳＴ１３０８）。問い合わせしていないＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ１３０２に戻す。そして、対応するＩＰアドレスを問い合わせしていないＵＲＩのうち、最小のＰｒｅｆｅｒｅｎｃｅ値を有するものに対して、再びＳＴ１３０２〜ＳＴ１３０８の処理を行う。４つのＵＲＩを受信した場合には最高４回までＳＴ１３０２〜ＳＴ１３０８の処理が行われる。

ＳＴ１３０２〜ＳＴ１３０８の処理を繰り返すうちにＩＰアドレスを問い合わせしていないＵＲＩが存在しなくなったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ１３０９）、グループ発呼処理を終了する。

このように実施の形態２に係るインターネット電話機によれば、サーバ１０１から複数のＵＲＩを受信した場合であってＰｒｅｆｅｒｅｎｃｅ値が差異を有する場合、いずれかのＵＲＩに対応する宛先と接続できない場合には他のＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

また、実施の形態２に係るインターネット電話機によれば、Ｐｒｅｆｅｒｅｎｃｅ値の大小関係に応じて発呼動作が行われる。これにより、Ｐｒｅｆｅｒｅｎｃｅ値に応じて発呼順序が決定されるので、発呼順序を指定することができる。特に、Ｐｒｅｆｅｒｅｎｃｅ値が小さいＵＲＩに対応する宛先から優先して発呼するので、発呼させたい順番に設定値を定めることで発呼順序を指定することができる。

なお、上述のように実施の形態２においては、ＮＡＰＴＲリソースレコードに記述されたＰｒｅｆｅｒｅｎｃｅ値をパラメータとして用いることで、複数存在する宛先に対して優先順位を付けて発呼する。しかし、Ｐｒｅｆｅｒｅｎｃｅ値をパラメータとして用いることで、複数存在する宛先に対して発呼する方法としては、常に優先順位を付けて発呼する場合に限られない。

例えば、Ｐｒｅｆｅｒｅｎｃｅ値を全て同一の値に設定しておき、そのＵＲＩに対応する全ての宛先に対して一斉に発呼することも可能である。図５（ａ）に示すＮＡＰＴＲリソースレコードを実施の形態２に係るインターネット電話機に利用したとする。図５（ａ）に示すＮＡＰＴＲリソースレコードのＰｒｅｆｅｒｅｎｃｅ値は全て「１０」に設定されている。このため、図１３に示すＳＴ１３０２においては全てのＵＲＩに対応するＩＰアドレスの問い合わせが行われ、ＳＴ１３０５においては全ての宛先端末（Ａ１〜Ａ４）に発呼されることとなる。

このように実施の形態２を応用したインターネット電話機によれば、Ｐｒｅｆｅｒｅｎｃｅ値が同一の場合には全てのＵＲＩに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。

なお、インターネット電話機においてＰｒｅｆｅｒｅｎｃｅ値を無視する指示を受けられるようにしておき、Ｐｒｅｆｅｒｅｎｃｅ値に差異を有する値を設定した場合において、Ｐｒｅｆｅｒｅｎｃｅ値を無視する指示を受け付けた場合にこの設定値を無視して全てのＵＲＩに対応する宛先に一斉に発呼することも可能である。この場合には、Ｐｒｅｆｅｒｅｎｃｅ値が差異を有する場合においても、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。

また、Ｐｒｅｆｅｒｅｎｃｅ値に同一の値を設定した組を複数用意しておき、その組単位で優先順位を付けて発呼することも可能である。図１４は、かかる場合にサーバ１０１のメモリ４０３に記述されたＮＡＰＴＲリソースレコードの一例を示す図である。同図においては、そのＰｒｅｆｅｒｅｎｃｅ値を除き、図１１に示すＮＡＰＴＲリソースレコードと同一であるため、その詳細な説明は省略する。図１４に示すＮＡＰＴＲリソースレコードにおいては、Ｐｒｅｆｅｒｅｎｃｅ値に同一の値を設定した組を有する点で図１１に示すＮＡＰＴＲリソースレコードと相違する。

図１４においては、端末Ａ１の電話番号（代表番号）「０３１０００００００」から得られるドメイン名「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対応付けられた４つのＵＲＩのうち、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「１０」が設定されている。また、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」を含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に「２０」が設定されている。このため、図１３に示す１回目のＳＴ１３０２において「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスの問い合わせが行われると共に、１回目のＳＴ１３０５において端末Ａ１及び端末Ａ２に対して一斉に発呼される。そして、２回目のＳＴ１３０２において「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスの問い合わせが行われると共に、２回目のＳＴ１３０５において端末Ａ３及び端末Ａ４に対して一斉に発呼される。

このように実施の形態２を応用したインターネット電話機によれば、Ｐｒｅｆｅｒｅｎｃｅ値が同一の値を設定した組を複数用意しておき、その組単位で優先順位を付けて発呼するので、発呼させたい順番に設定値の組を定めることで段階的に発呼順序を指定することができる。

更に、ここまではＰｒｅｆｅｒｅｎｃｅ値に異なる値を設定して複数存在する宛先に対して優先順位を付けて発呼する場合、並びに、Ｐｒｅｆｅｒｅｎｃｅ値を全て同一の値に設定して複数存在する宛先に対して一斉に発呼する場合について個別に説明してきたが、これらを並存させる実施の形態も可能である。かかる実施の形態は、例えば、上記電話番号（０３１０００００００〜０３１００００００３）に新たに電話番号を追加することで実現することが可能である。ここでは、例えば、電話番号０３１００００００４を追加し、この電話番号を一斉に発呼する際に用いる番号（以下、「一斉番号」という）に設定したものとする。

図１５は、かかる場合にサーバ１０１のメモリ４０３に記述されたＮＡＰＴＲリソースレコードの一例を示す図である。同図においては、最下段のＮＡＰＴＲレコードが追加されている点を除き、図１１に示すＮＡＰＴＲリソースレコードと同一であるため、その詳細な説明は省略する。

図１５においては、電話番号０３１００００００４から得られるドメイン名「４．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対して４つのＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」が対応付けられている。これらのＵＲＩを含むＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値に全て同一の値である「１０」が設定されている。このため、電話番号０３１００００００を受け付けた場合には異なるＰｒｅｆｅｒｅｎｃｅ値に従って複数存在する宛先に対して優先順位を付けて発呼が行われる。また、一斉番号０３１００００００４を受け付けた場合には同一であるＰｒｅｆｅｒｅｎｃｅ値に従って複数存在する宛先に対して一斉に発呼が行われる。

このように実施の形態２を応用したインターネット電話機によれば、サーバ１０１から複数のＵＲＩを受信した場合であってＰｒｅｆｅｒｅｎｃｅ値が差異を有する場合（上述の電話番号０３１０００００００が入力された場合）、優先順位の高いＵＲＩに対応する宛先と接続できない場合には次に優先順位の高いＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

一方、Ｐｒｅｆｅｒｅｎｃｅ値が同一の場合（上述の一斉番号が入力された場合）には全てのＵＲＩに対応する宛先に一斉に発呼する。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。

（実施の形態３）
実施の形態２に係るインターネット電話機がＮＡＰＴＲリソースレコードに記述されたＰｒｅｆｅｒｅｎｃｅ値に応じて複数存在する宛先に対して優先順位を付けて発呼する。その際に利用するサービスプロトコル（通信種別）としてｓｉｐ（Session Initiation Protocol）に限定しているのに対し、実施の形態３に係るインターネット電話機は、ｓｉｐのみならず他のサービスプロトコルを組み合わせて利用する点で相違する。

実施の形態３に係るインターネット電話機は、ｓｉｐと組み合わせるサービスプロトコルとして、例えば、電子メールや電話によるＦＡＸを利用する。以下の説明においては、特に電子メールや電話によるＦＡＸを組み合わせた実施の形態について説明するが、これに限定されず、Ｈ．３２３、Ｈ．３２３による電話、インターネットＦＡＸ、既存電話及びＷＥＢを利用するサービスプロトコルとして適用することができるのはいうまでもない。

図１６は、実施の形態３に係るサーバ１０１のメモリ４０３に記述されたＮＡＰＴＲリソースレコードの一例を示す図である。同図においては、最上段のＮＡＰＴＲレコードが変更されている点を除き、図１１に示すＮＡＰＴＲリソースレコードと同一であるため、その詳細な説明は省略する。

図１６においては、電話番号０３１０００００００から得られるドメイン名「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対して６つのＵＲＩが対応付けられている。上段４つのＵＲＩを含むＮＡＰＴＲレコードは図１１と同一のため、その説明を省略する。下段２つのＵＲＩを含むＮＡＰＴＲレコードのうち、上側のものはＳｅｒｖｉｃｅフィールドに「Ｅ２Ｕ＋ｍｅｓｓａｇｅ：ｍａｉｌｔｏ」と設定され、サービスプロトコル（通信種別）として電子メールを指定している。ＵＲＩには電子メールの宛先である「ｉｎｆｏ＠ｐａｎａｓｏｎｉｃ．ｃｏ．ｊｐ」が指定されている。一方、下側のものは「Ｅ２Ｕ＋ｔｅｌ」と設定され、サービスプロトコル（通信種別）として電話でのＦＡＸを指定している。ＵＲＩにはＦＡＸの宛先である「＋８１３１０００００１０；ｓｖｃ＝ｆａｘ」が指定されている。なお、下段２つのＵＲＩを含むＮＡＰＴＲレコードのうち、上側のものはＰｒｅｆｅｒｅｎｃｅ値に「５０」と設定され、下側のものは「６０」と設定されている。

以下、上記構成を有するサーバ１０１に接続された本インターネット電話機間で発呼を行う場合の動作について図１７を用いて説明する。ここでは、特に端末Ｂ１からグループ（Ａ）に含まれる端末に発呼する場合の動作について説明する。なお、サーバ１０１のメモリ４０３には、図１６及び図６に示す内容が登録されているものとする。

グループ（Ａ）の端末に発呼する場合、端末Ｂ１は、端末Ａ１〜Ａ４のいずれかの電話番号の入力をオペレータから受け付ける（ＳＴ１７０１）。例えば、端末Ａ１に対して発呼する場合には、「０３１０００００００」あるいは「０３」を省略した「１０００００００」をオペレータから受け付ける。

電話番号を受け付けると、端末Ｂ１は、この電話番号に対応するＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅをサーバ１０１に対して問い合わせる（ＳＴ１７０２）。上述の例の場合、端末Ｂ１は、「０３１０００００００（１０００００００）」から文字列「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」を得て、この文字列に対応するＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅを問い合わせる。

ＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅの問い合わせを受けると、サーバ１０１がメモリ４０３に格納されたＮＡＰＴＲリソースレコードに従ってＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅを返してくるので、端末Ｂ１は、このＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅを受信する（ＳＴ１７０３）。上述の例の場合、サーバ１０１は、図１６に示したＮＡＰＴＲリソースレコードに従って、この文字列に対応する６つのＵＲＩ、Ｐｒｅｆｅｒｅｎｃｅ値及びＳｅｒｖｉｃｅを返してくる。具体的には、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「１０」及び「Ｅ２Ｕ＋ｓｉｐ」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「２０」及び「Ｅ２Ｕ＋ｓｉｐ」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「３０」及び「Ｅ２Ｕ＋ｓｉｐ」、並びに、「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」、「４０」及び「Ｅ２Ｕ＋ｓｉｐ」、「ｉｎｆｏ＠ｐａｎａｓｏｎｉｃ．ｃｏ．ｊｐ」、「５０」及び「Ｅ２Ｕ＋ｍｅｓｓａｇｅ：ｍａｉｌｔｏ」、並びに、「＋８１３１０００００１０；ｓｖｃ＝ｆａｘ」、「６０」及び「Ｅ２Ｕ＋ｔｅｌ」を返してくる。

ＵＲＩ等を受信したならば、端末Ｂ１は、ＵＲＩが複数存在するか判断する（ＳＴ１７０４）。受信したＵＲＩが複数存在しない場合には処理をＳＴ１７０５に移行し通常発呼処理を行う。一方、複数存在する場合には処理をＳＴ１７０６に移行しグループ発呼処理を行う。なお、実施の形態３における通常発呼処理については図８に示す説明と同様のため、その説明を省略する。また、実施の形態３におけるグループ発呼処理については後述する。

通常発呼処理又はグループ発呼処理を行った後、端末Ｂ１は、発呼結果の状態が「通話ＯＫ」であるか判断する（ＳＴ１７０７）。発呼結果の状態が「通話ＯＫ」の場合には通話処理に移行する一方（ＳＴ１７０８）、「通話ＯＫ」以外の場合には切断処理に移行する（ＳＴ１７０９）。通話処理においては、端末Ｂ１のオペレータと発呼先のオペレータとの通話が終わり次第、端末Ｂ１の発呼処理が終了する。切断処理においては、移行すると同時に端末Ｂ１の発呼処理が終了する。

ここで、実施の形態３におけるグループ発呼処理について図１８を用いて説明する。図１８は、実施の形態３におけるグループ発呼処理について説明するためのフロー図である。なお、図１８において、図１３と同一の処理については同一の符号を付し、その詳細な説明を省略する。

グループ発呼処理に移行した場合、端末Ｂ１は、受信したＳｅｒｖｉｃｅの種別を判断する（ＳＴ１８０１）。そして、ｓｉｐ以外のＳｅｒｖｉｃｅを含むかどうか判断する（ＳＴ１８０２）。ｓｉｐ以外のＳｅｒｖｉｃｅを含まない場合には、図１３に示すＳＴ１３０１〜ＳＴ１３０６及びＳＴ１３０８を行うと共に、後述するＳＴ１８０９及びＳＴ１８１５において発呼結果の状態を「通話ＯＫ」か「通話ＮＧ」に切り替えてグループ発呼処理を終了する。

これに対してｓｉｐ以外のＳｅｒｖｉｃｅを含む場合には、端末Ｂ１は、まず、ＳｅｒｖｉｃｅがｓｉｐのＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値の大小関係を判断する（ＳＴ１８０３）。そして、最小のＰｒｅｆｅｒｅｎｃｅ値についてのＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる（ＳＴ１８０４）。

端末Ｂ１からこのＵＲＩによりＩＰアドレスの問い合わせを受けると、サーバ１０１からＩＰアドレスが返されてくるので、端末Ｂ１は、これを受信する（ＳＴ１８０５）。ＩＰアドレスを受信したならば、発呼結果の状態を初期化した後（ＳＴ１８０６）、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ１８０７）。そして、当該宛先と接続できたかを判断し（ＳＴ１８０８）、接続できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ１８０９）、グループ発呼処理を終了する。

これに対して、接続できなかった場合には、端末Ｂ１は、対応するＩＰアドレスを問い合わせしていないｓｉｐ対応のＵＲＩが存在するか判断する（ＳＴ１８１０）。問い合わせしていないｓｉｐ対応のＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ１８０４に戻す。そして、対応するＩＰアドレスを問い合わせしていないＵＲＩのうち、最小のＰｒｅｆｅｒｅｎｃｅ値を有するものに対して、再びＳＴ１８０４〜ＳＴ１８１０の処理を行う。４つのｓｉｐ対応のＵＲＩを受信した場合には最高４回までＳＴ１８０４〜ＳＴ１８１０の処理が行われる。

ＳＴ１８０４〜ＳＴ１８１０の処理を繰り返すうちにＩＰアドレスを問い合わせしていないｓｉｐ対応のＵＲＩが存在しなくなったならば、端末Ｂ１は、今度は、Ｓｅｒｖｉｃｅがｓｉｐ以外のＮＡＰＴＲレコードのＰｒｅｆｅｒｅｎｃｅ値の大小関係を判断する（ＳＴ１８１１）。そして、最小のＰｒｅｆｅｒｅｎｃｅ値を有するＮＡＰＴＲレコードのＵＲＩで指定された宛先に予め用意しておいた定型文を送信する（ＳＴ１８１２）。

図１６に示す例の場合には、電子メールアドレス「ｉｎｆｏ＠ｐａｎａｓｏｎｉｃ．ｃｏ．ｊｐ」に対して定型文が電子メールで送信される。定型文としては、例えば、「○○様宛てに電話を差し上げましたが、不在のようでしたので、折り返しご連絡下さい。」等の文章が想定される。しかし、定型文の内容としてはこれに限定されず、いかなる内容を設定しておいてもよい。

そして、電子メールを送信できたかを判断し（ＳＴ１８１３）、送信できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ１８０９）、グループ発呼処理を終了する。これに対して、送信できなかった場合には、端末Ｂ１は、未処理のＵＲＩが存在するか判断する（ＳＴ１８１４）。未処理のＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ１８１２に戻す。そして、未処理のＵＲＩのうち、最小のＰｒｅｆｅｒｅｎｃｅ値を有するものに対して、再びＳＴ１８１２の処理を行う。図１６に示す例の場合には、電話番号「＋８１３１０００００１０」に対して定型文がファクシミリ文書として送信される。定型文は、電子メールの場合と同様である。

ＳＴ１８１２〜ＳＴ１８１４の処理を繰り返すうちに未処理のＵＲＩが存在しなくなったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ１８１５）、グループ発呼処理を終了する。

このように実施の形態３に係るインターネット電話機によれば、サーバ１０１から複数のＵＲＩを受信した場合であってＳｅｒｖｉｃｅフィールドに設定されたプロトコル（通信種別）にｓｉｐ及びｓｉｐ以外のプロトコルが存在する場合、プロトコルにｓｉｐと設定されたＵＲＩに対応する宛先に発呼動作を行わせ、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

また、Ｓｅｒｖｉｃｅフィールドに設定されたプロトコルにｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外のプロトコルが設定されたＵＲＩに対して当該プロトコルに応じた処理を実行する。これにより、ｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合においても、予めｓｉｐ以外のプロトコルを用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。

特に、実施の形態３に係るインターネット電話機によれば、Ｓｅｒｖｉｃｅフィールドに設定されたプロトコルにｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合に電子メール又は電話でのＦＡＸと設定されたＵＲＩが示す宛先に予め用意された定型文が送信される。これにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。

（実施の形態４）
実施の形態２に係るインターネット電話機がＮＡＰＴＲリソースレコードに記述されたＰｒｅｆｅｒｅｎｃｅ値に応じて複数存在する宛先に対して優先順位を付けて発呼するのに対し、実施の形態４に係るインターネット電話機は、オペレータの指示に応じて複数存在する宛先に対して優先順位を付けて発呼する点で相違する。

実施の形態４に係るインターネット電話機は、予めサーバ１０１のメモリ４０３に宛先端末のオペレータの識別情報を予め登録しておき、発呼元のインターネット電話機のＵＲＩの問い合わせに応じてＵＲＩと共に識別情報を返す。発呼元のインターネット電話機のオペレータは、その識別情報を確認した上で発呼する際の優先順位をダイアルキー等により指定する。インターネット電話機は、オペレータからの指定に応じて発呼処理を行うものである。

なお、実施の形態４に係るサーバ１０１のメモリ４０３において、宛先端末のオペレータの識別情報を登録する際の形式は、どのような形式で登録しておいてもよい。しかし、発呼元のインターネット電話機からのＵＲＩの問い合わせに応じて識別情報を返すことを考慮した場合、ＵＲＩに対応させて登録しておくことが実施の形態として好ましい。

図１９は、実施の形態４に係るサーバ１０１のメモリ４０３に登録された識別情報の一例を示す図である。図１９（ａ）は、図１に示すグループ（Ａ）に対応するＵＲＩ及び識別情報を示し、図１９（ｂ）は、図１に示すグループ（Ｂ）に対応するＵＲＩ及び識別情報を示している。

以下、上記構成を有するサーバ１０１に接続された本インターネット電話機間で発呼を行う場合の動作について図２０を用いて説明する。ここでは、特に端末Ｂ１からグループ（Ａ）に含まれる端末に発呼する場合の動作について説明する。なお、サーバ１０１のメモリ４０３には、図５、図６及び図１９に示す内容が登録されているものとする。

グループ（Ａ）の端末に発呼する場合、端末Ｂ１は、端末Ａ１〜Ａ４のいずれかの電話番号の入力をオペレータから受け付ける（ＳＴ２００１）。例えば、端末Ａ１に対して発呼する場合には、「０３１０００００００」あるいは「０３」を省略した「１０００００００」をオペレータから受け付ける。

電話番号を受け付けると、端末Ｂ１は、この電話番号に対応するＵＲＩ及び識別情報をサーバ１０１に対して問い合わせる（ＳＴ２００２）。上述の例の場合、端末Ｂ１は、「０３１０００００００（１０００００００）」から文字列「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」を得て、この文字列に対応するＵＲＩ及び識別情報を問い合わせる。

ＵＲＩ及び識別情報の問い合わせを受けると、サーバ１０１がメモリ４０３に格納されたＮＡＰＴＲリソースレコードに従ってＵＲＩを返すと共に、当該ＵＲＩに対応して登録された識別情報を返してくるので、端末Ｂ１は、このＵＲＩ及び識別情報を受信する（ＳＴ２００３）。上述の例の場合、サーバ１０１は、図５に示したＮＡＰＴＲリソースレコードに従って、この文字列に対応する４つのＵＲＩと共に、図１９に示した対応表に従ってＵＲＩに対応する識別情報を返してくる。具体的には、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「松下太郎」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「松下二郎」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「松下三郎」、並びに、「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」及び「松下花子」を返してくる。

ＵＲＩ等を受信したならば、端末Ｂ１は、ＵＲＩが複数存在するか判断する（ＳＴ２００４）。受信したＵＲＩが複数存在しない場合には処理をＳＴ２００５に移行し通常発呼処理を行う。一方、複数存在する場合には処理をＳＴ２００６に移行しグループ発呼処理を行う。なお、実施の形態４における通常発呼処理については図８に示す説明と同様のため、その説明を省略する。また、実施の形態４におけるグループ発呼処理については後述する。

通常発呼処理又はグループ発呼処理を行った後、端末Ｂ１は、発呼結果の状態が「通話ＯＫ」であるか判断する（ＳＴ２００７）。発呼結果の状態が「通話ＯＫ」の場合には通話処理に移行する一方（ＳＴ２００８）、「通話ＯＫ」以外の場合には切断処理に移行する（ＳＴ２００９）。通話処理においては、端末Ｂ１のオペレータと発呼先のオペレータとの通話が終わり次第、端末Ｂ１の発呼処理が終了する。切断処理においては、移行すると同時に端末Ｂ１の発呼処理が終了する。

ここで、実施の形態４におけるグループ発呼処理について図２１を用いて説明する。図２１は、実施の形態４におけるグループ発呼処理について説明するためのフロー図である。

グループ発呼処理に移行した場合、端末Ｂ１は、オペレータから発呼する際の優先順位、すなわち、発呼順序を受け付ける（ＳＴ２１０１）。グループ発呼処理に移行すると、端末Ｂ１の表示部などに図２０に示すＳＴ２００３で受信した全ての識別情報が表示される。オペレータは、その識別情報において優先的に着信して欲しいオペレータの順序を指定してくるので、端末Ｂ１はこれを受け付ける。例えば、端末Ｂ１のオペレータにより図１９（ａ）に示す識別情報の上段から下段に向かって発呼順序が指定される。

発呼順序を受け付けたならば、端末Ｂ１は、指定された発呼順序を判断する（ＳＴ２１０２）。これにより、端末Ｂ１が本グループ発呼処理で発呼すべき順序が認識される。上述の例の場合、１番目に「松下太郎」、２番目に「松下二郎」、３番目に「松下三郎」、最後に「松下花子」に対して発呼すべき旨が認識される。

次に、端末Ｂ１は、最初に発呼すべき識別情報に応じたＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる（ＳＴ２１０３）。上述の例の場合、まず、「松下太郎」に応じた「８１３１００００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ」に対応するＩＰアドレスの問い合わせが行われる。

端末Ｂ１からこのＵＲＩによりＩＰアドレスの問い合わせを受けると、サーバ１０１からＩＰアドレスが返されてくるので、端末Ｂ１は、これを受信する（ＳＴ２１０４）。ＩＰアドレスを受信したならば、発呼結果の状態を初期化した後（ＳＴ２１０５）、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ２１０６）。そして、当該宛先と接続できたかを判断し（ＳＴ２１０７）、接続できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ２１０８）、グループ発呼処理を終了する。

これに対して、接続できなかった場合には、端末Ｂ１は、対応するＩＰアドレスを問い合わせしていないＵＲＩが存在するか判断する（ＳＴ２１０９）。問い合わせしていないＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ２１０３に戻す。そして、対応するＩＰアドレスを問い合わせしていないＵＲＩのうち、次の発呼順序のものに対して、再びＳＴ２１０３〜ＳＴ２１０９の処理を行う。４つのＵＲＩを受信した場合には最高４回までＳＴ２１０３〜ＳＴ２１０９の処理が行われる。

ＳＴ２１０３〜ＳＴ２１０９の処理を繰り返すうちにＩＰアドレスを問い合わせしていないＵＲＩが存在しなくなったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ２１１０）、グループ発呼処理を終了する。

このように実施の形態４に係るインターネット電話機によれば、サーバ１０１から複数のＵＲＩを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのＵＲＩに対応する宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、実施の形態４に係るインターネット電話機においては、オペレータから指定された発呼順序に従って発呼動作が行われる。これにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。

（実施の形態５）
上記実施の形態１〜４に係るインターネット電話機は、社内ＬＡＮなどのネットワークに設置された場合であって外部のネットワークから直接アクセスできないような場合には適用が制限される場合がある。例えば、社内ＬＡＮ上のインターネット電話機にプライベートＩＰアドレスを割り当て、外部ネットワークとの通信にはＮＡＴ（Network Address Translation）機能を有するルータ（以下、「ＮＡＴルータ」という）を介して行うような場合には適用が制限される。実施の形態５に係るインターネット電話機は、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができるようにするものである。

図２２は、本発明の実施の形態５に係るインターネット電話機が適用されるネットワークの構成を示す図である。

同図において、インターネット電話機(端末)Ａ１〜Ａ４は、社内ＬＡＮ上に設置され、端末Ｂ１は外部ネットワークに設置されている。端末Ａ１〜Ａ４には、図２（ａ）に示した例と同様に、電話番号として０３１０００００００〜０３１００００００３が同様に割り当てられる。しかし、図２（ａ）に示した例と異なり、ＩＰアドレスとしてプラーベートＩＰアドレス（ローカルＩＰアドレス）である１９２．１６８．１．１００〜１９２．１６８．１．１０３が割り当てられている。ＮＡＴルータ２２０１にはグローバルＩＰアドレスである２．２．２．２が割り当てられている。端末Ａ１〜Ａ４から外部ネットワークの端末（例えば、端末Ｂ１）にアクセスする場合には、ＮＡＴルータ２２０１においてプライベートＩＰアドレスからグローバルＩＰアドレスへの変換が行われ、モデム２２０２による通信制御の下、インターネット２２０３を介して通信が行われる。なお、図２２においては、端末Ｂ１を外部ネットワークに設置されたインターネット電話機として説明しているが、これに限定されず、端末Ａ１〜Ａ４のような社内ＬＡＮに接続された一台の端末であってもよい。

サーバ２２０４は、ネットワークＩ／Ｆ４０４がインターネットとの間で信号の制御を行う点を除き、図４における説明と同様の構成を有している。実施の形態５に係るサーバ２２０４のメモリ４０３は、端末Ａ１〜Ａ４に割り当てられた電話番号からＵＲＩへの変換を行うためのデータベース（ＮＡＰＴＲリソースレコード）を格納し、また、電話番号から変換されたＵＲＩと対応付けられるＩＰアドレスを登録している。しかし、実施の形態５においては、端末Ａ１〜Ａ４にプライベートＩＰアドレスが割り当てられているため、電話番号から変換されたＵＲＩには全てＮＡＴサーバ２２０１のグローバルＩＰアドレスが対応付けられている。

図２３は、実施の形態５に係るサーバ２２０４のメモリ４０３に格納されたＮＡＰＴＲリソースレコードの一例を示す図である。同図においては、端末Ａ１〜Ａ４に対応したＮＡＰＴＲリソースレコードを示している。

図２３に示すように、端末Ａ１の電話番号（代表番号）「０３１０００００００」から得られるドメイン名「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」に対して４つのＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：５０６０」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００１」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００２」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００３」が対応付けられている。同様に、端末Ａ２、Ａ３及びＡ４の電話番号「０３１００００００１」、「０３１００００００２」及び「０３１００００００３」から得られるドメイン名「１．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」、「２．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」及び「３．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」にそれぞれＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００１」、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００２」及び「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００３」が対応付けられている。

このように各ＵＲＩにそれぞれ「５０６０」、「６０００１」、「６０００２」及び「６０００３」が追加されている。これらは、通信に用いられるポート番号を示している。追加されている「５０６０」はｓｉｐのデフォルトのポート番号であり、「６０００１」〜「６０００３」は未定義ポートから利用したポート番号の一例を示している。これらのポート番号は、ＮＡＴルータ２２０１においてポートフォワーディングを行う際に用いられる。ＮＡＴルータ２２０１にはポートフォワーディングを行うため、特定のポート番号と端末Ａ１〜Ａ４のＩＰアドレスとを対応付ける設定が予め行われている。

図２４は、実施の形態５に係るＮＡＴルータ２２０１に設定された特定のポート番号とＩＰアドレスとの対応関係を示す図である。

同図に示すように、ポート番号「５０６０」に端末Ａ１のプライベートＩＰアドレス「１９２．１６８．１．１００」が設定され、ポート番号「６０００１」に端末Ａ２のプライベートＩＰアドレス「１９２．１６８．１．１０１」が設定され、ポート番号「６０００２」に端末Ａ３のプライベートＩＰアドレス「１９２．１６８．１．１０２」が設定され、ポート番号「６０００３」に端末Ａ４のプライベートＩＰアドレス「１９２．１６８．１．１０３」が設定されている。予めこのように設定しておくことで、外部ネットワークの端末からＮＡＴルータ２２０１のＩＰアドレス（２．２．２．２）にポート番号を指定してアクセスされると、指定されたポート番号に対応するＩＰアドレスの端末と通信が可能となる。

以下、実施の形態５に係るインターネット電話機に対して外部ネットワークに設置されたインターネット電話機から発呼を行う場合の動作について図２５を用いて説明する。ここでは、端末Ｂ１から端末Ａ１〜Ａ４のいずれかに発呼する場合の動作について説明する。なお、サーバ２２０４のメモリ４０３には図２３に示すＮＡＰＴＲリソースレコードが登録され、ＮＡＴルータ２２０１には図２４に示す設定が行われているものとする。

端末Ａ１〜Ａ４のいずれかに発呼する場合、端末Ｂ１は、端末Ａ１〜Ａ４のいずれかの電話番号の入力をオペレータから受け付ける（ＳＴ２５０１）。例えば、端末Ａ１に対して発呼する場合には、「０３１０００００００」あるいは「０３」を省略した「１０００００００」の入力をオペレータから受け付ける。

電話番号を受け付けると、端末Ｂ１は、この電話番号に対応するＵＲＩをサーバ２２０４に対して問い合わせる（ＳＴ２５０２）。実施の形態５においてはＵＲＩにポート番号が含まれているため、結果としてポート番号も問い合わせたこととなる。上述の例の場合、端末Ｂ１は、「０３１００００００（１０００００００）」から文字列「０．０．０．０．０．０．０．１．３．１．８．ｅ１６４．ａｒｐａ」を得て、この文字列に対応するＵＲＩを問い合わせる。

ＵＲＩの問い合わせを受けると、サーバ２２０４がメモリ４０３に格納されたＮＡＰＴＲリソースレコードに従ってＵＲＩを返してくるので、端末Ｂ１は、このＵＲＩを受信する（ＳＴ２５０３）。実施の形態５においてはＵＲＩにポート番号が含まれているため、結果としてポート番号も受信する。これにより、端末Ｂ１は、入力された電話番号に対応するＵＲＩとポート番号を把握する。上述の例の場合、サーバ１０１は、図２３に示したＮＡＰＴＲリソースレコードに従って、上記文字列に対応する４つのＵＲＩ「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：５０６０」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００１」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００２」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００３」を返してくる。

ＵＲＩ等を受信したならば、端末Ｂ１は、ＵＲＩが複数存在するか判断する（ＳＴ２５０４）。受信したＵＲＩが複数存在しない場合には処理をＳＴ２５０５に移行し通常発呼処理を行う。一方、複数存在する場合には処理をＳＴ２５０６に移行しグループ発呼処理を行う。なお、実施の形態５における通常発呼処理及びグループ発呼処理については後述する。

通常発呼処理又はグループ発呼処理を行った後、端末Ｂ１は、発呼結果の状態が「通話ＯＫ」であるか判断する（ＳＴ２５０７）。発呼結果の状態が「通話ＯＫ」の場合には通話処理に移行する一方（ＳＴ２５０８）、「通話ＯＫ」以外の場合には切断処理に移行する（ＳＴ２５０９）。通話処理においては、端末Ｂ１のオペレータと発呼先のオペレータとの通話が終わり次第、端末Ｂ１の発呼処理が終了する。切断処理においては、移行すると同時に端末Ｂ１の発呼処理が終了する。

ここで、実施の形態５における通常発呼処理について図２６を用いて説明する。図２６は、実施の形態５における通常発呼処理について説明するためのフロー図である。

通常発呼処理に移行した場合、端末Ｂ１は、受信したＵＲＩに対応するＩＰアドレスをサーバ２２０４に問い合わせる（ＳＴ２６０１）。例えば、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：５０６０」をＵＲＩとして受信した場合には、このＵＲＩに対応するＩＰアドレスをサーバ１０１に問い合わせる。

ＩＰアドレスの問い合わせを受けると、サーバ２２０４がメモリ４０３に登録された内容に従ってＩＰアドレスを返してくるので、端末Ｂ１は、このＩＰアドレスを受信する（ＳＴ２６０２）。上述のように、実施の形態５に係るサーバ２２０４は、ＮＡＴルータ２２０１のＩＰアドレスしか登録していないため、このＩＰアドレス（２．２．２．２）を返してくる。ＩＰアドレスを受信すると、端末Ｂ１は、図２５に示す処理（ＳＴ２５０３）で得たポート番号と合わせることで、結果としてＮＡＴルータ２２０１のＩＰアドレスと宛先端末のポート番号を把握する。

ＩＰアドレスを受信したならば、端末Ｂ１は、発呼結果の状態を初期化する（ＳＴ２６０３）。具体的には、発呼結果の状態を「待機中」に設定することにより発呼結果の状態を初期化する。

次に、端末Ｂ１は、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ２６０４）。実施の形態５においては、ＮＡＴルータ２２０１に対して把握した宛先のポート番号に向けた発呼処理が行われる。具体的には、ＳＩＰのＩＮＶＩＴＥメッセージ中に「ｓｉｐ：２．２．２．２：５０６０」を記述することでＮＡＴルータのＩＰアドレスと宛先端末のポート番号を指定する。

発呼処理を行った後、端末Ｂ１は、当該宛先と接続できたかを判断する（ＳＴ２６０５）。ここで、接続できたならば、端末Ｂ１は、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ２６０６）、通常発呼処理を終了する。一方、接続できなかったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ２６０７）、通常発呼処理を終了する。このように通常発呼処理においては単一の宛先に対して発呼処理を行い、その宛先に対する接続の可否に応じて発呼結果の状態が切り替えられる。

次に、実施の形態５におけるグループ発呼処理について図２７を用いて説明する。図２７は、実施の形態５におけるグループ発呼処理について説明するためのフロー図である。

グループ発呼処理に移行した場合、端末Ｂ１は、受信したＵＲＩに対応するＩＰアドレスをサーバ２２０４に問い合わせる（ＳＴ２７０１）。グループ発呼処理に移行した場合には複数のＵＲＩが受信されているため、端末Ｂ１は、いずれかのＵＲＩに対応するＩＰアドレスをサーバ２２０４に問い合わせる。例えば、「８１３１０００００００＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：５０６０」、「８１３１００００００１＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００１」、「８１３１００００００２＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００２」及び「８１３１００００００３＠ｔｏｋｙｏ．ｓｉｐ．ｊｐ：６０００３」をＵＲＩとして受信した場合には、いずれかのＵＲＩに対応するＩＰアドレスをサーバ２２０４に問い合わせる。

ＩＰアドレスの問い合わせを受けると、通常発呼処理における説明と同様に、サーバ２２０４からＮＡＴルータ２２０１のＩＰアドレスが返されてくるので、端末Ｂ１は、これを受信する（ＳＴ２７０２）。ＩＰアドレスを受信すると、通常発呼処理における説明と同様に、端末Ｂ１は、図２５に示す処理（ＳＴ２５０３）で得たポート番号と合わせることで、結果としてＮＡＴルータのＩＰアドレスと宛先端末のポート番号を把握する。

ＩＰアドレスを受信したならば、発呼結果の状態を初期化した後（ＳＴ２７０３）、受信したＩＰアドレスに対して発呼処理を行う（ＳＴ２７０４）。そして、当該宛先と接続できたかを判断し（ＳＴ２７０５）、接続できたならば、発呼結果の状態を「通話ＯＫ」に切り替えて（ＳＴ２７０６）、グループ発呼処理を終了する。

これに対して、接続できなかった場合には、端末Ｂ１は、対応するＩＰアドレスを問い合わせしていないＵＲＩが存在するか判断する（ＳＴ２７０７）。問い合わせしていないＵＲＩが存在するならば、端末Ｂ１は、処理をＳＴ２７０１に戻し、問い合わせしていないＵＲＩが存在しなくなるまでＳＴ２７０１〜ＳＴ２７０７の処理を繰り返す。４つのＵＲＩを受信した場合には最高４回までＳＴ２７０１〜ＳＴ２７０７の処理が行われる。

ＳＴ２７０１〜ＳＴ２７０７の処理を繰り返すうちにＩＰアドレスを問い合わせしていないＵＲＩが存在しなくなったならば、端末Ｂ１は、発呼結果の状態を「通話ＮＧ」に切り替えて（ＳＴ２７０８）、グループ発呼処理を終了する。このようにグループ発呼処理においては複数の宛先に対して発呼処理を行い、全ての宛先に対して接続ができなかった場合に発呼結果の状態が「通話ＮＧ」に設定される。

このように実施の形態５に係るインターネット電話機によれば、サーバ２２０４から複数のＵＲＩを受信した場合であって当該ＵＲＩにポート番号が含まれる場合、いずれかのＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるＵＲＩを変更して異なるＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。

特に、実施の形態５に係るインターネット電話機によれば、ＵＲＩに含まれるポート番号とＵＲＩに応じたＩＰアドレスとで特定される宛先に対して発呼するので、例えば、インターネット電話機にプライベートＩＰアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。

なお、上記説明におけるインターネット電話は、総務省が定義し通信事業者が運用するＩＰ電話や、ローカルなネットワーク又は自営網でのＴＣＰ／ＩＰ等のコンピュータ通信プロトコルによるネットワークで実現されるものも含むものとする。

本発明に係るインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムによれば、通話したい宛先の電話機が話中の場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができ、オペレータの利便性に優れたインターネット電話機等を提供できる点で有用である。

本発明の実施の形態１に係るインターネット電話機が適用されるネットワークの構成を示す図 図１に示すネットワークに接続されたインターネット電話機に割り当てられた電話番号及びＩＰアドレスを示す図 実施の形態１に係るインターネット電話機の構成を示すブロック図 実施の形態１に係るサーバの概略構成を示すブロック図 実施の形態１に係るサーバのメモリに記述されたＮＡＰＴＲリソースレコードの一例を示す図 実施の形態１に係るサーバのメモリに記憶されたＵＲＩ及びＩＰアドレスの対応関係の一例を示す図 実施の形態１に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作についてについて説明するためのフロー図 実施の形態１における通常発呼処理について説明するためのフロー図 実施の形態１におけるグループ発呼処理について説明するためのフロー図 実施の形態１におけるグループ発呼処理を実行することで、端末Ｂ１とグループ（Ａ）に含まれる端末との間で行われるシーケンスを説明するための図 本発明の実施の形態２に係るサーバのメモリに記述されたＮＡＰＴＲリソースレコードの一例を示す図 実施の形態２に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作について説明するためのフロー図 実施の形態２におけるグループ発呼処理について説明するためのフロー図 実施の形態２に係るサーバのメモリに記述されたＮＡＰＴＲリソースレコードの変形例を示す図 実施の形態２に係るサーバのメモリに記述されたＮＡＰＴＲリソースレコードの変形例を示す図 本発明の実施の形態３に係るサーバのメモリに記述されたＮＡＰＴＲリソースレコードの一例を示す図 実施の形態３に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作を説明するためのフロー図 実施の形態３におけるグループ発呼処理について説明するためのフロー図 本発明の実施の形態４に係るサーバのメモリに登録された識別情報の一例を示す図 実施の形態４に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作を説明するためのフロー図 実施の形態４におけるグループ発呼処理について説明するためのフロー図 本発明の実施の形態５に係るインターネット電話機が適用されるネットワークの構成を示す図 実施の形態５に係るサーバのメモリに格納されたＮＡＰＴＲリソースレコードの一例を示す図 実施の形態５に係るＮＡＴルータに設定された特定のポート番号とＩＰアドレスとの対応関係を示す図 実施の形態５に係るインターネット電話機に対して外部ネットワークに設置されたインターネット電話機から発呼を行う場合の動作を説明するためのフロー図 実施の形態５における通常発呼処理について説明するためのフロー図 実施の形態５におけるグループ発呼処理について説明するためのフロー図 （ａ）従来の一般的なインターネット電話システムのネットワークの構成を示す図 （ｂ）、（ｃ）従来のインターネット電話システムのサーバにおいて管理される、各インターネット電話機に割り当てられた電話番号とその電話番号に対応するＩＰアドレスとが登録された管理表を示す図 従来のインターネット電話システムにおける動作を示すシーケンス図

符号の説明

Ａ１〜Ａ４、Ｂ１〜Ｂ４ インターネット電話機（端末）
１０１ サーバ
１０２、１０３ ルータ
３０１ 制御アダプタ
３０２ 通常の電話機
３０３ ＣＰＵ
３０５ ＲＯＭ
３０６ ＲＡＭ
４０１ ＣＰＵ
４０３ メモリ
２２０１ ＮＡＴルータ
２２０２ モデム
２２０４ サーバ

Claims (28)

1. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩを前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
2. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
3. 前記制御手段は、前記設定値が小さいＵＲＩに対応する宛先から優先して発呼させることを特徴とする請求項２記載のインターネット電話機。
4. 前記制御手段は、前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに対応する宛先に一斉に発呼させることを特徴とする請求項２記載のインターネット電話機。
5. 前記制御手段は、前記設定値を無視する指示を受け付けると前記設定値を無視して全てのＵＲＩに対応する宛先に一斉に発呼させることを特徴とする請求項２記載のインターネット電話機。
6. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶して前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するネットワークサーバにネットワークを介して接続するインターネット電話機であって、入力された前記代表番号に対応するＮＡＰＴＲリソースレコード上の前記グループ内の複数のインターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を前記ネットワークサーバから受信する受信手段と、前記受信した複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信するアドレス受信手段と、前記受信したＩＰアドレスが割り当てられた宛先に発呼する発呼手段と、前記発呼した宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記ネットワークサーバから受信して当該ＩＰアドレスの宛先に再発呼させ、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行させる制御手段と、を具備することを特徴とするインターネット電話機。
7. 前記受信手段は、前記ｓｉｐ以外の通信種別として電子メール又は電話でのＦＡＸを受信し、前記制御手段は、前記電子メール又は電話でのＦＡＸと設定されたＵＲＩが示す宛先に予め用意された定型文を送信することを特徴とする請求項６記載のインターネット電話機。
8. 前記受信手段は前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行うことを特徴とする請求項１記載のインターネット電話機。
9. 前記受信手段はＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行うことを特徴とする請求項１から請求項６のいずれかに記載のインターネット電話機。
10. 前記制御手段は、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるＵＲＩを変更して異なるＵＲＩに対応する宛先に再発呼させることを特徴とする請求項１から請求項９のいずれかに記載のインターネット電話機。
11. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶する記憶手段と、前記代表番号による問い合わせを受けると当該代表番号に対応する各インターネット電話機のＵＲＩを返送し、ＵＲＩによる問い合わせを受けると当該ＵＲＩに応じたＩＰアドレスを返送する制御手段と、を具備することを特徴とするネットワークサーバ。
12. 前記記憶手段が記憶するＮＡＰＴＲリソースレコードにはＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含み、前記制御手段は前記代表番号による問い合わせを受けると前記設定値も合わせて返送することを特徴とする請求項１１記載のネットワークサーバ。
13. 前記記憶手段が記憶するＮＡＰＴＲリソースレコードにはＳｅｒｖｉｃｅフィールドの通信種別を含み、前記制御手段は前記代表番号による問い合わせを受けると前記通信種別も合わせて返送することを特徴とする請求項１１記載のネットワークサーバ。
14. 前記記憶手段は、前記通信種別としてｓｉｐ又は電子メール又は電話でのＦＡＸを登録することを特徴とする請求項１３記載のネットワークサーバ。
15. 前記記憶手段は前記グループ内の各インターネット電話機のオペレータの識別情報も記憶し、前記制御手段は前記ＵＲＩによる問い合わせを受けると前記識別情報も合わせて返送することを特徴とする請求項１１記載のネットワークサーバ。
16. 前記ＮＡＰＴＲリソースレコード上のＵＲＩにポート番号を含むことを特徴とする請求項１１記載のネットワークサーバ。
17. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩを返送し、前記返送された複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼することを特徴とする通話方法。
18. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記設定値並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記設定値を返送し、前記返送された複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼することを特徴とする通話方法。
19. 前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに応じたＩＰアドレスの宛先に一斉に発呼することを特徴とする請求項１８記載の通話方法。
20. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記通信種別並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記通信種別を返送し、前記返送された複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼し、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行することを特徴とする通話方法。
21. 前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行うことを特徴とする請求項１７記載の通話方法。
22. ＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行うことを特徴とする請求項１７から請求項２０のいずれかに記載の通話方法。
23. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩを含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩを返送し、前記返送された複数のＵＲＩのいずれかのＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼することを特徴とするインターネット電話システム。
24. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＰｒｅｆｅｒｅｎｃｅフィールドの設定値を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記設定値並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記設定値を返送し、前記返送された複数のＵＲＩのうち前記設定値の大小関係に応じて選択したＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記グループ内のいずれかのインターネット電話機と接続できるまで前記設定値の大小関係に応じて選択される他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼することを特徴とするインターネット電話システム。
25. 前記ＵＲＩを複数受信した場合であって前記設定値が同一の場合には全てのＵＲＩに応じたＩＰアドレスの宛先に一斉に発呼することを特徴とする請求項２４記載のインターネット電話システム。
26. 複数のインターネット電話機からなるグループの代表番号に対応して前記グループ内の各インターネット電話機のＵＲＩ及びＳｅｒｖｉｃｅフィールドに設定された通信種別を含むＮＡＰＴＲリソースレコード及び前記ＵＲＩに応じた前記各インターネット電話機のＩＰアドレスを記憶し、前記代表番号に対応する各インターネット電話機のＵＲＩ及び前記通信種別並びに当該ＵＲＩに応じたＩＰアドレスを返送するサーバと、入力された前記代表番号に応じてサーバから前記グループ内の複数のインターネット電話機のＵＲＩ及びＩＰアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から前記代表番号に対応するＵＲＩの問い合わせを受けるとサーバから当該代表番号に対応する前記グループ内のインターネット電話機の複数のＵＲＩ及び当該複数のＵＲＩに応じた前記通信種別を返送し、前記返送された複数のＵＲＩのうち前記通信種別にｓｉｐと設定されたＵＲＩに対応するＩＰアドレスを前記インターネット電話機から前記サーバに問い合わせ、前記サーバから返送されたＩＰアドレスが割り当てられた宛先に発呼し、当該宛先と接続できない場合には前記通信種別にｓｉｐと設定された他のインターネット電話機のＵＲＩに対応するＩＰアドレスを前記サーバに問い合わせて当該ＩＰアドレスの宛先に再発呼し、前記通信種別にｓｉｐと設定された全てのＵＲＩに対応する宛先と接続できなかった場合にはｓｉｐ以外の通信種別が設定されたＵＲＩに対して当該通信種別に応じた処理を実行することを特徴とするインターネット電話システム。
27. 前記ＵＲＩと共に前記グループ内の各インターネット電話機のオペレータの識別情報を受信し、インターネット電話機の表示部に表示された前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼並びに再発呼を行うことを特徴とする請求項２３記載のインターネット電話システム。
28. ＮＡＰＴＲリソースレコード上のポート番号を含むＵＲＩを受信し、前記受信したＵＲＩに応じたＩＰアドレスと当該ＵＲＩに含まれるポート番号で特定される宛先に対して発呼並びに再発呼を行うことを特徴とする請求項２３から請求項２６のいずれかに記載のインターネット電話システム。

Images