JP2004193984A - 通信システム、通信方法、サーバ、通信端末、プログラム、並びに、記録媒体 - Google Patents

Abstract

【課題】ＩＰネットワーク上の通信端末と公衆網上の通信端末との間で通信を行う通信システムにおいて、公衆網上の通信端末からＩＰネットワーク上の通信端末の指定方法の問題点を解決する。
【解決手段】ＩＰネットワーク上の通信端末Ａと、公衆網上の通信端末Ｂと、前記ＩＰネットワークと前記公衆網との間に配置され、前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、両側発信サーバとを備え、前記両側発信サーバは、前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付ける第１の手段と、前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信する第２の手段と、前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送する第３手段とを有する。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
本発明は、通信システム、通信方法、サーバ、通信端末、プログラム、並びに、記録媒体に係わり、特に、帯域保証型および帯域非保証型のネットワークに接続された、ＰＣ（Personal Computer）端末と映像付携帯端末の間で行われる、リアルタイム双方向通信サービスの提供方法に関する。
【０００２】
【従来の技術】
従来の技術として、ＩＰネットワーク上での映像、音声などの双方向通信系サービスでの相手のＩＰアドレスを直接指定して通信を行っていた。
ＩＰアドレスは、固定ＩＰアドレスとして使用することは少なく、ほとんどの場合、ＤＨＣＰ（Dynamic Host Configuration Protocol）などでサービスを使用する度ごとに毎回異なったＩＰアドレスとなる。
ＤＨＣＰは、各クライアントの起動時に動的にＩＰアドレスを割り当て、終了時にＩＰアドレスを回収するプロトコルである。
このため、ＤＨＣＰを利用した場合、各ＰＣ端末にはサービスを利用する度ごとに毎回異なったＩＰアドレスが割り当てられることになる。
このような場合、ＩＰネットワーク上のＰＣ端末は、例えば、プレゼンスサーバと呼ばれるサーバにログインし、このサーバに対してＩＰアドレスを通知する。携帯端末側は、このプレゼンスサーバから、ＰＣ端末のＩＰアドレスを含むプレゼンス情報を得ることにより、ログイン中のＰＣ端末に対して発信（発呼）を行うことが可能となる。
【０００３】
同じ相手と通信するのに、毎回異なるアドレスを指定するのは、使いづらいため、ユーザ一人にユニークな名前をつけ、その名前と、ＩＰアドレスを管理するサーバを用意し、接続する際に、そのサーバに間い合わせることで、接続相手先のアドレスを解決する。
例えば、ITU-T H.323では、ゲートキーパにアドレス解決機能を持たせ、ユーザは、相手のアカウントを指定することで、接続を可能としている。
また、このサーバヘの登録時に認証機能を持たせることで、特定のユーザだけのサービス提供が可能となる。
ＩＰネットワーク以外の公衆網、他の通信網との接続については、プロトコル変換用のゲートウェイが必要となる。
ITU-T H.323と電話網とをつなぐゲートウェイは市販されており、また、マイクロソフト社のWindowsMessengerサービス等で行っていたが、ＩＰネットワークから電話網への一方向の接続サービスである。
市販のゲートウェイは、電話網等の公衆網からＩＰネットワークヘの接続の機能を持っているにもかかわらず、一般ユーザ向けにサービスが提供されない理由として、いくつか考えられる。
【０００４】
第一の理由として、ゲートウェイを経由したＩＰネットワーク端末の選択方法が挙げられる。
公衆網等に接続されている端末が、ゲートウェイを経由で、ＩＰアドレスを指定する方法としてＤＴＭＦ（Dual Tone Multi Frequency）信号、着番号（ダイヤルイン）、着サブアドレスなどがある。
ＤＴＭＦ信号を利用した方法では、ゲートウェイが接続されている電話番号に接続し、ゲートウェイが一旦応答した後、ＩＰネットワーク内の端末を指定する番号をＤＴＭＦ信号で送信し、それを受信したゲートウェイが、ＩＰネットワーク内の端末に接続する。
着番号（ダイヤルイン）を利用した方法では、ＩＰネットワーク内の端末と着番号（ダイヤルイン）が１対１に対応しており、ゲートウェイは、着信時に取得する着番号（ダイヤルイン）を元に、対応するＩＰネットワーク内の端末に接続する。着サブアドレスは、着番号（ダイヤルイン）と同様である。
ＤＴＭＦ信号は、端末によっては、送信機能がないものがある。着番号（ダイヤルイン）は、ＩＰネットワーク上の端末数分だけ、必要となり、費用的な問題がある。着サブアドレスについては、端末およびネットワークで指定できない場合がある。
【０００５】
第二の理由として、利用ユーザの特定の問題がある。
ゲートウェイで発信元を識別する情報として、発信者番号があるが、ゲートウェイの容量の問題があり、番号の数がある程度限定される。
また、発信者番号を利用した場合、発信者番号が通知されることが必須条件となり、発信者番号を通知しない場合利用できない。
課金サービスを考えた場合、認証として、利用者を特定できない場合もあり、発信者番号だけでは十分ではない。
一方、従来、インターネット上のサーバを利用することにより携帯電話において相手のプレゼンス情報を表示する技術やサーバが特定の端末に対して発信（発呼）を行い多地点間でテレビ会議を行う技術はあったが、不特定多数のユーザの中から特定ユーザにサービスを提供でき、かつ、不正利用を防止できる、携帯電話側からＰＣ端末に対して発信（発呼）可能なシステムの具体的構成については開示されていなかった（非特許文献１、非特許文献２参照）。
【０００６】
なお、本願発明に関連する先行技術文献情報としては以下のものがある。
【非特許文献１】
株式会杜 富士通研究所、“携帯電話における思いやりコミュニケーションを可能とするサービスを開発 〜携帯電話向けインスタントメッセージサービスの開発〜”、[ｏｎｌｉｎｅ]、平成１２年１１月３０日、
株式会杜富士通研究所、
ＵＲＬ：http://www.1abs.fujitsu.com/News/2000/Nov/30.html
【非特許文献２】
株式会社 エヌ・ティ・ティエムイー、“ＩＰネットワーク用(H.323)多地点テレビ会議制御システム Encounter3000シリーズ”、
［ｏｎｌｉｎｅ］、株式会社 エヌ・ティ・ティエムイー、
ＵＲＬ：http://nttiivs.ntt-me.co.jp/mmcs/tvmt/e3k1.htm
【０００７】
【発明が解決しようとする課題】
本発明では、ＩＰネットワーク上の通信端未と他の通信網の通信端未、特に、携帯電話端末とＩＰネットワーク上にある通信端末（ＰＣ端末）との通信を既存のゲートウェイを用いてシステム構築し、双方向サービスを提供する。
前述したとおり、ゲートウェイを経由したＩＰネットワーク端末の選択方法に課題があり、特に、現在市販されている3GPP 324M規格の携帯電話端末では、映像、音声通話中のＤＴＭＦ信号の送信ができず、また、着サブアドレスを指定することもできない。
ゲートウェイは、不特定の通信端末（ＰＣ端末、携帯端末等）から発信要求され、不正利用されることが考えられる。
課金においては、一般的には、ＩＰネットワークは従量課金をしていない場合が多く、回線交換網の多くは従量課金を行っている。そのため、携帯電話から発信し、ＩＰネットワーク上のＰＣ端末が応答しない場合や、サービスが成り立たない状況でも通信料が発生するという問題がある。
【０００８】
これを解決するために、ＩＰネットワーク上にある端末および他の通信網の端末から発信する際のどちらにおいても、ゲートウェイから他の通信網への発信の接続形態をとることを考え、接続要求を受け付ける機能、接続要求から、ＩＰネットワーク上の端末とゲートウェイの両方へ発信する機能を持つサーバとゲートウェイを用いる。
両方へ発信する機能を持つサーバを用いた場合、端末において、通常の通信と異なるため、端末間の通信確立が認識できない問題がある。
また、発信要求であるにもかかわらず、実際の接続形態がサーバからの着信という動作になるため、通常の通信とユーザインタフェースが異なる。
また、着信で接続されるため、端末での応答処理も必要となり実際の接続より時間がかかるという問題がある。
【０００９】
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、ＩＰネットワーク上の通信端末と公衆網上の通信端末との間で通信を行う通信システムおよび通信方法において、公衆網上の通信端末からＩＰネットワーク上の通信端末の指定方法の問題点を解決することが可能となる技術を提供することにある。
また、本発明の他の目的は、ＩＰネットワーク上の通信端末と公衆網上の通信端末との間で通信を行う通信システムおよび通信方法において、通信端末間での通信が確立しない場合の通信料の発生を抑えることが可能となる技術を提供することにある。
また、本発明の他の目的は、ＩＰネットワーク上の通信端末と公衆網上の通信端末との間で通信を行う通信システムおよび通信方法において、ユーザに対して、通信相手の通信端末との間で通信が確立したことを通知することが可能となる技術を提供することにある。
また、本発明の他の目的は、前述の通信システムに適用されるサーバ、通信端末を提供することにある。
また、本発明の他の目的は、前述の通信方法をコンピュータに実行させるためのプログラム、および当該プログラムが記録された記録媒体を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【００１０】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
前述の目的を達成するため、本発明では、ＩＰネットワーク上の通信端末Ａと、公衆網上の通信端末Ｂと、前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、発信受付処理サーバと、両側発信サーバとで通信システムを構成する。
本発明では、通信端末Ａ、あるいは、通信端末Ｂのどちらの発信要求に対しても、必ず両側発信サーバからそれぞれの通信端末に発信する。
よって、ゲートウェイは、ＩＰネットワークから公衆網への一方向の発信となり、公衆網からＩＰネットワーク上の端末の指定方法の問題は回避できる。
また、ゲートウェイは、サーバ以外の接続はなく、両側発信サーバからの通信要求に対してのみ応答すればよいので、ゲートウェイが不正利用されることを防止することができる。
なお、本発明において、発信受付処理サーバと両側発信サーバとは、１台のサーバで構成することも可能である。
【００１１】
また、本発明では、両側発信サーバにおいて、同時に通信端末Ａおよび通信端末Ｂの両側に同時に発信するのではなく、片方ずつ通信可能性を確認しながら、接続する。
これにより、通信端末間で通信が確立しない場合に、公衆網接続による通信料の発生を抑えることができる。
本発明において、通信端末から発信要求をした場合、通信端末と両側発信サーバ間の通信が確立してからにおいても、通信相手端末との通信が確立していない状況であり、ユーザがどの時点で相手端末と通信が確立したのかを認識する必要がある。
このため、本発明では、通信端末に、通信端末間において通信が確立したことを確認する確認手段を持たせ、ユーザに対して、通信相手の通信端末と通信が確立したことを通知する。
【００１２】
また、通信端末から発信要求をした場合でも、通信処理的には、両側発信サーバから着信するため、通信端末のユーザに着信を意識させると、自分が発信した着信か、それ以外からの着信か混乱が生じることが予想される。
そのため、本発明では、通信端末に、通信端末から発信要求をした場合、通信相手の通信端末との通信が確立するまで、ユーザにあたかも発信しているように表示する手段を持たせる。
即ち、通信端末は、発信受付処理サーバ（あるいは、両側発信サーバ）に、発信要求を出したタイミングで、例えば、通信端末のディスプレイ上に、「接続中」のメッセージを表示する。
また、この「接続中」のメッセージを消すタイミングとして、前述の手段を用いる。
【００１３】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
なお、実施の形態を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
また、以下の実施の形態では、ＩＰネットワーク上の通信端末をＰＣ端末、公衆網側の端末を3GPP規格の3G-324Mの映像、音声通信用端末とし、その相互間の通信について説明する。
ＰＣ端末には、サーバとの通信機能および映像、音声用通信機能を持つソフトウェアが備えられているものとする。
本発明のサービス概要を図１に示す。
図１に示すサービスは、ＰＣ端末１と、携帯端末（3G-324M方式対応携帯端末）２との間で、映像・音声の１対１双方向リアルタイム通信を提供するテレビ電話サービスである。
3G-324M方式対応携帯端末２と、ＰＣ端末１は、帯域保障型であるＩＳＤＮ網（回線交換網）と、帯域非保障型のＩＰネットワークを、ゲートウェイ（以下、ＧＷという）５を介して接続される。
【００１４】
［実施の形態１］
図２は、本発明の実施の形態１の通信システムの概略構成を示すブロック図である。
同図に示すように、本実施の形態の通信システムは、ＰＣ端末１と、携帯端末２と、ＰＣ端末１、または携帯端末２からの接続要求を受付、両側発信サーバに発信指示を行う発信受付処理サーバ４と、発信受付処理サーバ４からの発信指示に基づきＰＣ端末１と携帯端末２に発信し、端末間の通信を確立する両側発信サーバ３と、回線交換網（帯域保証型の通信網）からのデータとＩＰネットワーク（帯域非保証型の通信網）からのデータを相互に変換するＧＷ５とから構成される。ここで、発信受付処理サーバ４、および両側発信サーバ３は、ＩＰネットワーク上に配置される。
なお、以下の説明では、発信受付処理サーバ４、両側発信サーバ３は２台のサーバで本サービスを提供するが、それぞれの機能を１台のサーバに集約することもできる。
【００１５】
以下、本発明の通信方法について説明する。
初めに、ＰＣ端末１から携帯端末２への通信を行う際の手順について説明する。
ＰＣ端末１から、発信受付処理サーバ４ヘ、携帯端末２への接続を要求する（図２に示す矢印（１））。
発信受付処理サーバ４は、ＰＣ端末１からの要求を元に、両側発信サーバ３に対し、ＰＣ端末１と携帯端末２への接続を行うように指示する（図２に示す矢印（２））。
両側発信サーバ３は、発信受付処理サーバ４の指示により、ＰＣ端末１と携帯端末２に接続を行う（図２に示す矢印（３））。
その際、携帯端末２へは直接接続できないため、ＧＷ５に対して、携帯端末２の接続要求を行い、ＧＷ５は、両側発信サーバ３の指示により、携帯端末２へ接続する。
両側発信サーバ３は、ＰＣ端末１から送信された映像、音声のデータをＧＷ５を経由して携帯端末２へ、あるいは、ＧＷ５を経由して携帯端末２から送信された映像、音声データをＰＣ端末１へ、それぞれ転送することで、ＰＣ端末１と携帯端末２間の映像、音声通信を実現する。
【００１６】
次に、携帯端末２からＰＣ端末１への通信を行う際の手順について説明する。
ここでは、携帯端末２にインターネット接続機能があるとして説明する。
携帯端末２のインターネット接続機能を用いて、発信受付処理サーバ４ヘ接続し、ＰＣ端末１への接続を要求する（図２に示す矢印（４））。
発信受付処理サーバ４は、携帯端末２からの要求を元に、両側発信サーバ３に対して、ＰＣ端末１と携帯端末２への接続を行うように指示する（図２に示す矢印（２））。
以下、ＰＣ端末１からの携帯端末２への接続と同様にして、両側発信サーバ３が、ＰＣ端末１から送信された映像、音声のデータをＧＷ５を経由して携帯端末２へ、あるいは、ＧＷ５を経由して携帯端末２から送信された映像、音声データをＰＣ端末１へ、それぞれ転送することで、ＰＣ端末１と携帯端末２間の映像、音声通信を実現する。
なお、前述の説明では、携帯端末２にインターネット接続機能があることとして説明したが、発信受付処理サーバ４ヘの接続方法は、通常の電話接続をして、接続要求の情報をＤＴＭＦ信号等で送信しても構わない。
前述したように、接続要求情報を発信受付処理サーバ４に伝えることができれば手段は問わない。
【００１７】
ＰＣ端末１のＩＰアドレス、携帯端末２の電話番号については、各端末からの接続要求時にサーバに指示することが可能であるが、事前に発信受付処理サーバ４に登録してあって構わない。
また、最近インターネット上でのコミュニケーション用サーバとして利用されているプレゼンスサーバと連携してアドレス解決を行うことも可能である。
プレゼンスサーバとは、各ユーザの状態を管理するサーバで、例えば、各ユーザのオンライン（このサーバにログインしている）／オフライン（ログインしていない）状態や、コミュニケーション手段の状態等の付加情報を管理している。
このサーバに各ユーザのコミュニケーション用のＩＰアドレスを管理させれば、コミュニケーション手段のアドレス解決手段として利用できる。
このサーバにアクセスしているユーザは、他のユーザの状態を知ることが可能である。
ＰＣ端末１が、プレゼンスサーバにログインする際に、コミュニケーション用ＩＰアドレスを通知することで、プレゼンスサーバをアドレス解決用サーバとして利用することが可能となる。携帯端末２からの接続時に、このプレゼンス情報が利用できる。
プレゼンスサーバは一例であり、アドレス解決するためのデータベースを持つものとの連携が可能であれば良い。他に、ＬＤＡＰ（Lightweight Directory Access Protocol）サーバ、ITU-TH 323でのゲートキーパであってもよい。
【００１８】
図３は、図１に示す発信受付処理サーバ４の内部概略構成を示すブロック図である。
同図に示すように、発信受付処理サーバ４は、認証機能４１と、発信要求受付機能４２と、発信要求機能４３とを備える。
認証機能４１は、ＰＣ端末１あるいは携帯端末２を使用するユーザを認証する機能である。
例えば、発信受付処理サーバ４にアクセスする際に、ＩＤとパスワード入力を求めて、ユーザを認証する。
また、携帯端末２に関しては、発信者番号通知やＤＴＭＦ信号等の利用して、認証を行うことが可能である。
発信要求受付機能４２は、ＰＣ端末１から携帯端末２への接続要求、あるいは、携帯端末２からＰＣ端末１への接続要求を受け付ける機能である。
発信要求機能４３は、ＰＣ端末１から携帯端末２への接続要求、あるいは、携帯端末２からＰＣ端末１への接続要求に基づき、両側発信サーバ３に対し、ＰＣ端末１と携帯端末２への接続を行うように指示する機能である。
【００１９】
図４は、図１に示す両側発信サーバ３の内部概略構成を示すブロック図である。
同図に示すように、両側発信サーバ３は、発信要求受付機能３１と、ＰＣ側発信機能３２と、携帯端末側発信機能３３と、データ転送機能３４とを備える。
発信要求受付機能３１は、発信受付処理サーバ４からの接続指示を受け付ける機能である。
ＰＣ側発信機能３２は、ＰＣ端末１に接続を行う機能であり、携帯端末側発信機能３３は、ＧＷ５を介して携帯端末に接続する機能である。
データ転送機能３４は、ＰＣ端末１から送信された映像、音声のデータをＧＷ５を経由して携帯端末２へ、あるいは、ＧＷ５を経由して携帯端末２から送信された映像、音声データをＰＣ端末１へ、それぞれ転送する機能である。
【００２０】
図５は、図１に示すＰＣ端末１、あるいは、携帯端末２の内部概略構成を示すブロック図である。
なお、この図５は、本発明に直に関係する部分のみを図示し、それ以外の部分の図示は省略している。
図５に示すように、図１に示すＰＣ端末１、あるいは、携帯端末２は、発信受付処理サーバ接続モジュール１１、通信制御モジュール１２、通信アプリケーションモジュール１３、並びに、ＧＵＩ（Graphical User Interface）処理部１４を備える。
発信受付処理サーバ接続モジュール１１は、発信受付処理サーバ４との通信を行い、発信受付処理サーバ４に接続要求を行う。
通信制御モジュール１２は、音声、映像の通信を実現するための呼制御および映像、音声処理を行う。
通信アプリケーションモジュール１３は、ＧＵＩ処理部１４からのユーザの指示により、発信受付処理サーバ接続モジュール１１、通信制御モジュール１２を制御し、また、ユーザヘ着信、相手応答・通信開始等の情報についてＧＵＩ処理部１４を通して、ユーザに通知する。
ＧＵＩ処理部１４は、ユーザインタフェースを処理するモジュールである。
【００２１】
〈通信を実現するまでの一連の処理〉
ＧＵＩ処理部１４は、ユーザからの接続要求に基づき、通信アプリケーションモジュール１３ヘ通信相手先を通知する。
通信アプリケーションモジュール１３は、ＧＵＩ処理部１４からの情報を元に、発信受付処理サーバ接続モジュール１１に対し、通信相手先、通信要求元（自分）の情報を渡し、発信するように指示する。
発信受付処理サーバ接続モジュール１１は、通信アプリケーションモジュール１３からの指示に従い、発信受付処理サーバ４に対して、通信相手先、通信要求元（自分）の情報を渡し、発信要求を行う。
前述したように、発信受付処理サーバ４は、発信要求の情報を元に、両側発信サーバ３に対して、発信指示を行い、両側発信サーバ３は、指定された情報を元に、両側に発信を行う。
通信制御モジュール１２は、両側発信サーバ３からの着信を受信し、着信した情報を通信アプリケーションモジュール１３に通知する。
通信アプリケーションモジュール１３は、着信したことをユーザに通知し、通信制御モジュール１２に応答することを指示する（必ずしも自動的に応答する必要はなく、ＧＵＩ処理部１４を経由しユーザに通知し、ユーザ操作により応答してもよい。）。
【００２２】
以上説明したように、本実施の形態によれば、携帯端末２からの発信に関しても、ＩＰネットワークから、公衆網への接続方向になるため、公衆網側からのＧＷ５への接続指示を行う問題を回避できる。
また、ＧＷ５は、両側発信サーバ３のみからアクセスするので、ＧＷ５のＩＰアドレスは、ユーザは知ることができないため、ＧＷ５に直接アクセスし、不正利用される危険性は少ない。
また、公衆網側からのアクセスについては、ＧＷ５の機能により、ＩＰネツトワーク側への接続を禁止したり、回線契約を発信専用にする等の手段で防ぐことが可能である。
ＰＣ端末１、携帯端末２からのユーザに関する利用制限については、発信受付処理サーバ４に認証機能４１を持たせることで、利用に関する制限を行うことが可能である。
【００２３】
公衆網接続については、ほとんどの場合、時間と距離に関する課金方式である。
そのため、課金情報としては、誰が、いつ、どこに、どのくらい接続したという情報が必要である。
その情報に関しては、両側発信サーバ３でこれら全ての情報をログとして残すことが可能であるが、それぞれのログを残す場所として、発信受付処理サーバ４、ＧＷ５に分散させてもたせることも可能である。
また、実際の公衆網での通話料に関しては、電話会社からの請求とログから誰に課金するか判断することができる。
また、本実施の形態では、公衆網側の端末として、3G-324Mを例に挙げて説明したが、一般のアナログ電話網、ＩＳＤＮ電話網などの公衆網に接続される端末であっても構わない。
インターネット接続手段を持たない端末は、別の手段（端末等）を用いて、インターネット接続を行い、発信受付処理サーバ４に接続要求を行うことで、サービスを提供することが可能である。また、インターネット接続手段と音声や映像の通信と同時に使用できない場合は、最初にインターネット接続手段で、発信受付処理サーバ４に接続要求を行い、一旦、インターネット接続手段を終了して、ＧＷ５を経由した両側発信サーバ３からの着信を待つことで、サービスを利用することも可能である。
【００２４】
［実施の形態２］
前述実施の形態１では、ＰＣ端末１およびＧＷ５を経由して携帯端末２へ発信は、同時に行うことを想定している。この方法でもサービスは可能であるが、ＧＷ経由の接続は、公衆網との接続のため、通信料が発生する。
そのため、例えば、ＰＣ端末１との接続ができない場合に、携帯端末２との接続が確立した場合、ＰＣ端末１と携帯端末２との通話が確立しないまま、通話料だけ発生することになる。
そのため、接続順番を考慮することが必要となる。
以下の説明では、両側発信サーバ３の接続順序に関してＰＣ端末１から接続し、その後、ＧＷ５を経由し携帯端末２に接続する方法について説明する。
図６、図７は、本実施の形態の通信方法を説明するための図であり、図６は、ＰＣ端末１から発信した場合のＰＣ端末１と携帯端末２との間の接続手順、図７は、携帯端末２から発信した場合のＰＣ端末１と携帯端末２との間の接続手順を説明するための図である。
【００２５】
ＰＣ端末１および携帯端末２からの発信要求（図６、図７に示す矢印（１）の接続先選択）に関する処理に関しては、前述の実施の形態１で説明したことと同じなので、ここでは、割愛し、両側発信サーバ３に関する動作部分についてのみ説明する。
発信受付処理サーバ４からの指示（図６、図７に示す矢印（２）の発信要求）により、両側発信サーバ３は、ＰＣ端末１に対して、発信を行う（図６、図７に示す矢印（３−１）の発信）。
次に、ＰＣ端末１の通信可能性を確認したのち、ＧＷ５を経由して携帯端末２への発信を行う（図６、図７に示す矢印（３−２）の発信）。
そして、携帯端末２の通信可能性を確認したのち、映像、音声のデータの転送処理を行う。
ＰＣ端末１および携帯端末２の通信可能性が確認できない場合は、その時点で、通信が成り立たないと判断し、切断処理を行う。
上記の説明は、公衆網側が従量課金、ＩＰネットワーク側が固定料金の場合として、先にＩＰネットワーク側の端末に接続することとして説明を行ったが、公衆網側が固定料金で、ＩＰネットワーク側が従量課金である場合も考えられるため、接続順番においては、その逆であっても構わない。
【００２６】
両側発信サーバ３における通信可能性の確認方法としては、「着信の確認」、「応答の確認」、「通信メディアの確認」の３種類が考えられる。
「着信の確認」とは、発信し、呼び出された端末が着信状態になったことを確認することを意味する。
「応答の確認」とは、発信し、呼び出された端末が、着信し、応答したことを確認することを意味する。
「通信メディアの確認」とは、発信し、呼び出された端末が着信し、応答して且つ、通信サービスを行う通信メディアの通信能力を確認したことを意味する。ここでの通信メディアとは、映像、音声を意味し、この通信サービスで最低限必要な通信メディアを指す。
例えば、映像、音声のコミュニケーションサービスの場合、最低限必要な通信メディアを音声とした場合、映像の能力が確認できない場合でも音声の能力が確認できればよい。
最低限必要な通信メディアは、このコミュニケーションサービスの提供者が決定する。
【００２７】
通信可能性確認の方法の一例として、ITU-T H.323のプロトコルを用いて説明する。
「着信の確認」については、両側発信サーバ３から、SETUPメッセージを送信後、ＰＣ端末１およびＧＷ５からのALERTメッセージの受信で行う。
ALERTメッセージは、オプションのメッセージであるため、代わりとして、CALLPROCメッセージの受信でも着信の確認は可能である。
また、H.323のメッセージは、ＴＣＰで転送されるため、ＴＣＰのリンク確立の確認で代用も可能である。
「応答の確認」については、両側発信サーバ３から、SETUPメッセージを送信後、ＰＣ端末１およびＧＷ５からのCONNECTメッセージの受信で行う。
「通信メディアの確認」については、両側発信サーバ３からSETUPメッセージを送信し、ＰＣ端末１およびＧＷ５からのCONNECTメッセージ受信後、端末およびＧＷ５からの能力交換メッセージであるTerminalCapabilitySetメッセージを受信し、そのメッセージ内に含まれる通信メディアの能力の確認によって行う。より確実に行うために、チャネル開設メッセージであるOpenLogicalChannelメッセージの受信との組み合わせで行っても良い。
ここでは、H.323のプロトコルで説明したが、他のプロトコルに関しても対応付けが可能である。
【００２８】
［実施の形態３］
本実施の形態では、ＰＣ端末１、あるいは携帯端末２における通信開始タイミングのユーザヘの通知方法について説明する。
前述の実施の形態２において、両側発信サーバ３から接続されたＰＣ端末１、あるいは携帯端末２は、両側発信サーバ３からの着信に対し、応答しても、両側発信サーバ３と接続しているだけで、本来通信したい端末（ＰＣ端末１、あるいは携帯端末２）との通信を確立したわけではない。
もう一方の端末との通信が両側発信サーバ３との間で確立し、映像、音声のデータ転送が開始された時点で、実際の通信が確立する。
映像、音声のデータ転送が開始されたことを、ＰＣ端末１、あるいは携帯端末２で検出し、ユーザに通知する方法について説明する。
ＰＣ端末１および携帯端末２からの発信要求に関する処理に関しては、前述の実施の形態１で説明したことと同じなので、ここでは、割愛し、ＰＣ端末１での両側発信サーバ３からの着信、または、携帯端末２でのＧＷ５経由の両側発信サーバ３からの着信に対する応答後の、両端末間での通信確立の確認方法についてのみ説明する。
【００２９】
ＰＣ端末１、あるいは携帯端末２における、両端末間での通信確立の確認方法として、「受信メディアの確立の確認」、「メディアデータの受信の確認」の２種類が考えられる。
「受信メディアの確立の確認」とは、通信プロトコル上で、その意味を表すメッセージとして受信する場合のことである。
「メディアデータの受信の確認」とは、通信相手端末からの映像や音声のデータを受信することである。
両端末間での通信確立の確認方法の例として、ITU-T H.245のプロトコルを用いて説明する。
「受信メディアの確立の確認」については、受信メディアを確立するためのチャネル開設を意味するOpenLogicalChannelメッセージの受信により確認することができる。
また、H.245での非標準メッセージを用いた独自メッセージを用い、通信が確立した意味のメッセージを定義し、そのメッセージの受信により実現可能である。
「メディアデータの受信の確認」については、実際、音声または映像のデータを受信したことで、両端末間での通信が確立することを認識することができる。
ここでは、H.245のプロトコルで説明したが、他のプロトコルに関しても対応付けが可能である。
【００３０】
図８は、本実施の形態のＰＣ端末１、あるいは、携帯端末２の内部概略構成を示すブロック図である。
図８に示すＰＣ端末１、あるいは、携帯端末２は、図５に示す構成に通信開始検出モジュール１５を追加したものである。
通信開始検出モジュール１５は、本来通信したい相手と接続したことの判定を行う。
以下、図８に示すＰＣ端末１、あるいは、携帯端末２における動作を説明する。 途中までの動作は図５の場合と同じであり、両側発信サーバ３から着信するところから説明する。
通信制御モジュール１２は、両側発信サーバ３からの着信を受信し、着信した情報を通信アプリケーションモジュール１３に通知する。
通信アプリケーションモジュール１３は、通信制御モジュール１２に応答することを指示する。通信制御モジュール１２は、両側発信サーバ３からの着信に対して、応答し、両側発信サーバ３との通信を確立する。
その後、通信制御モジュール１２から通知される、受信メディアの確立の確認」、「メディアデータの受信の確認」を通信開始検出モジュール１５が検出し、ＧＵＩ処理部１４に対し、ユーザに本来通信したい相手と通信が確立したことを通知する。
【００３１】
［実施の形態４］
本実施の形態では、ＰＣ端末１、あるいは携帯端末２におけるユーザインタフェースについて説明する。
前述の実施の形態１において、発信要求を行ったＰＣ端末１、あるいは携帯端末２は、両側発信サーバ３での発信による接続のため、実際には、着信のシーケンスで通信が確立するため、通常の通信とユーザインタフェースが異なる。
また、着信で接続されるため、端末での応答処理も必要となり実際の接続より時間がかかる。
発信要求を行った端末において、通常の通信で発信をしているようにユーザに見せる手段について説明する。
ＰＣ端末１から携帯端末２に接続する場合について説明する。
ＰＣ端末１において、発信受付処理サーバ４に対し、携帯端末２への接続を要求する。同時に、ＰＣ端末１のユーザに対し、ＰＣ端末１のディスプレイに「接続中」のメッセージを表示する。
発信要求を受けた発信受付処理サーバ４は、両側発信サーバ３に対し、ＰＣ端末１と携帯端末２への接続を指示する。
【００３２】
両側発信サーバ３は、ＰＣ端末１に発信する際の接続メッセージに、ＰＣ端末１からの発信要求である情報を付加して、送信する。
ＰＣ端末１は、受信した接続メッセージ内の付加情報をチェックし、自分が要求した呼であるかを判断し、自分の要求した呼であれば、自動応答する。このとき、ユーザには、「接続中」のメッセージを表示したままである。
次に、両側発信サーバ３が、携帯端末２と接続したことをＰＣ端末１が前述実施の形態３で説明した方法で検出し、ユーザに表示している接続中のメッセージを解除し、通信中になったことをユーザに通知する。
付加情報を付与して実現する例として、ITU-T H.323のプロトコルを用いて説明する。
ＰＣ端末１において、発信受付処理サーバ４ヘ接続要求する際に、接続先である携帯端末２の電話番号をＰＣ端末１で保持しておく。
両側発信サーバ３において、ＰＣ端末１に対して、発信する際に、SETUPメッセージの表示情報要素に、携帯端末２の電話番号を付加情報としてコーディングし、送信する。
ＰＣ端末１は、SETUPメッセージ内の表示情報要素をチェックし、発信要求した電話番号と比較し、一致した場合、接続要求した呼と判断する。この例では、表示情報要素を用いたが、別の情報要素であっても構わない。
【００３３】
図９は、本実施の形態のＰＣ端末１、あるいは、携帯端末２の内部概略構成を示すブロック図である。
図９に示すＰＣ端末１、あるいは、携帯端末２は、図８に示す構成に接続判定モジュール１６を追加したものである。
接続判定モジュール１６は、通信制御モジュール１２からの着信通知に対し、発信受付処理サーバ４ヘ要求した呼であるかを判定するモジュールである。
以下、図９に示すＰＣ端末１、あるいは、携帯端末２における動作を説明する。
ＧＵＩ処理部１４は、ユーザからの接続要求を元に通信アプリケーションモジュール１３ヘ通信相手先を通知する。
通信アプリケーションモジュール１３は、ＧＵＩ処理部１４からの情報を元に、接続判定モジュール１６ヘ、通信相手先の情報を渡し、また、発信受付処理サーバ接続モジュール１１に対し、通信相手先、通信要求元（自分）の情報を渡し、発信するように指示する。
発信受付処理サーバ接続モジュール１１は、通信アプリケーションモジュール１３からの指示に従い、発信受付処理サーバ４に対し、通信相手先、通信要求元（自分）の情報を渡し、発信要求を行う。
【００３４】
通信制御モジュール１２は、両側発信サーバ３からの着信を受信し、着信時に着信メッセージに含まれる前述した情報（接続メッセージ内の付加情報）を通信アプリケーションモジュール１３に通知する。
通信アプリケーションモジュール１３は、接続判定モジュール１６に着信メッセージに含まれる情報を渡す。
接続判定モジュール１６は、発信要求の情報と着信メッセージに含まれる情報を比較し、発信要求した呼と判定した場合には、応答指示を通信制御モジュール１２に指示し、発信要求した呼ではないと判定した場合には、切断指示を通信制御モジュール１２に対し指示する。応答後の動作は、前述の実施の形態３と同じである。
なお、本発明の各装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
以上、本発明者によってなされた発明を、前記実施の形態に基づき具体的に説明したが、本発明は、前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【００３５】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
（１）本発明によれば、ゲートウェイを経由することにより、ＩＰネットワーク上の通信端末（例えば、ＰＣ端末）と、他の公衆網上の通信端末（例えば、携帯端末）との間の双方向の音声および映像通信が可能となるとともに、不特定の端末からゲートウェイを不正利用されることを防止することが可能となる。
（２）本発明によれば、両側発信サーバおよびゲートウェイにおいては、保有回線数だけの端末情報を（一時的に）持つことができればよく、全ての端末情報を記録した大きなデータベースを持つ必要がない。
（３）本発明によれば、従量課金の通信網において、サービスが成立しない状況で通信料が発生するのを防止することが可能となる。
【図面の簡単な説明】
【図１】本発明のサービス概要を示すブロック図である。
【図２】本発明の実施の形態１の通信システムの概略構成を示すブロック図である。
【図３】図１に示す発信受付処理サーバの内部概略構成を示すブロック図である。
【図４】図１に示す両側発信サーバの内部概略構成を示すブロック図である。
【図５】図１に示すＰＣ端末、あるいは、携帯端末の内部概略構成を示すブロック図である。
【図６】本発明の実施の形態２の通信方法を説明するための図である。
【図７】本発明の実施の形態２の通信方法を説明するための図である。
【図８】本発明の実施の形態３のＰＣ端末、あるいは、携帯端末の内部概略構成を示すブロック図である。
【図９】本発明の実施の形態４のＰＣ端末、あるいは、携帯端末の内部概略構成を示すブロック図である。
【符号の説明】
１…ＰＣ端末、２…携帯端末、３…両側発信サーバ、４…発信受付処理サーバ、５…ゲートウェイ（ＧＷ）、１１…発信受付処理サーバ接続モジュール、１２…通信制御モジュール、１３…通信アプリケーションモジュール、１４…ＧＵＩ（Graphical User Interface）処理部、１５…通信開始検出モジュール、１６…接続判定モジュール、３１…発信要求受付機能、３２…ＰＣ側発信機能、３３…携帯端末側発信機能、３４…データ転送機能、４１…認証機能、４２…発信要求受付機能、４３…発信要求機能。

Claims (18)

1. ＩＰネットワーク上の通信端末Ａと、
   公衆網上の通信端末Ｂと、
   前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
   両側発信サーバとを備える通信システムであって、
   前記通信端末Ａおよび前記通信端末Ｂは、前記両側発信サーバに対して発信要求を行う第１の手段を有し、
   前記両側発信サーバは、前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付ける第１の手段と、
   前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信する第２の手段と、
   前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送する第３手段とを有することを特徴とする通信システム。
2. ＩＰネットワーク上の通信端末Ａと、
   公衆網上の通信端末Ｂと、
   前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
   発信受付処理サーバと、
   両側発信サーバとを備える通信システムであって、
   前記通信端末Ａおよび前記通信端末Ｂは、前記発信受付処理サーバに対して発信要求を行う第１の手段を有し、
   発信受付処理サーバは、前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付ける第１の手段と、
   前記両側発信サーバに対して前記通信端末Ａと前記通信端末Ｂとの接続を指示する第２の手段とを有し、
   前記両側発信サーバは、前記発信受付処理サーバからの発信要求を受け付ける第１の手段と、
   前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信する第２の手段と、
   前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送する第３手段とを有することを特徴とする通信システム。
3. 前記両側発信サーバの第２の手段は、前記通信端末Ａ、あるいは通信端末Ｂの一方の通信端末に発信し、一方の通信端末の通信可能性を確認した後に、他方の通信端末に発信し、
   前記両側発信サーバの第３の手段は、両通信端末の通信可能性が確認できた後に、それぞれの通信端末から送信されるデータをお互いに転送することを特微とする請求項１または請求項２に記載の通信システム。
4. 前記通信端末Ａおよび前記通信端末Ｂは、両通信端末間の通信が前記両側発信サーバ経由で確立したことを検出する第２の手段を有することを特徴とする請求項１ないし請求項３のいずれか１項に記載の通信システム。
5. 前記通信端末Ａおよび通信端末Ｂは、発信要求を行った後に、通信相手の通信端末との通信が確立するまで、通信相手の通信端末と接続中であることをユーザに通知する第３の手段を有することを特徴とする請求項１ないし請求項４のいずれか１項に記載の通信システム。
6. ＩＰネットワーク上の通信端末Ａと、
   公衆網上の通信端末Ｂと、
   前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
   両側発信サーバとを備える通信システムにおける通信方法であって、
   前記通信端末Ａ、あるいは前記通信端末Ｂが、前記両側発信サーバに対して発信要求を行うステップ１１と、
   前記両側発信サーバが、前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付けるステップ３１と、
   前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信するステップ３２と、
   前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送するステップ３３とを有することを特徴とする通信方法。
7. ＩＰネットワーク上の通信端末Ａと、
   公衆網上の通信端末Ｂと、
   前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
   発信受付処理サーバと、
   両側発信サーバとを備える通信システムにおける通信方法であって、
   前記通信端末Ａ、あるいは前記通信端末Ｂが、前記発信受付処理サーバに対して発信要求を行うステップ１１と、
   発信受付処理サーバが、前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付けるステップ２１と、
   前記両側発信サーバに対して前記通信端末Ａと前記通信端末Ｂとの接続を指示するステップ２２と、
   前記両側発信サーバが、前記発信受付処理サーバからの発信要求を受け付けるステップ３１と、
   前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信するステップ３２と、
   前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送するステップ３３とを有することを特徴とする通信方法。
8. 前記両側発信サーバのステップ３２において、前記通信端末Ａ、あるいは通信端末Ｂの一方の通信端末に発信し、一方の通信端末の通信可能性を確認した後に、他方の通信端末に発信し、
   前記両側発信サーバのステップ３３において、両通信端末の通信可能性が確認できた後に、それぞれの通信端末から送信されるデータをお互いに転送することを特微とする請求項６または請求項７に記載の通信方法。
9. 前記両側発信サーバのステップ３３の後に、前記通信端末Ａあるいは通信端末Ｂが、両通信端末間の通信が前記両側発信サーバ経由で確立したことを検出するステップ１２を有することを特徴とする請求項６ないし請求項８のいずれか１項に記載の通信方法。
10. 前記通信端末Ａあるいは通信端末Ｂが、前記ステップ１１の後に、通信相手の通信端末との通信が確立するまで、通信相手の通信端末と接続中であることをユーザに通知するステップ１３を有することを特徴とする請求項６ないし請求項９のいずれか１項に記載の通信方法。
11. ＩＰネットワーク上の通信端末Ａと、
    公衆網上の通信端末Ｂと、
    前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
    両側発信サーバとを備える通信システムにおける両側発信サーバであって、
    前記通信端末Ａ、あるいは前記通信端末Ｂからの発信要求を受け付ける第１の手段と、
    前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信する第２の手段と、
    前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送する第３手段とを有することを特徴とする両側発信サーバ。
12. ＩＰネットワーク上の通信端末Ａと、
    公衆網上の通信端末Ｂと、
    前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
    発信受付処理サーバと、
    両側発信サーバとを備える通信システムにおける両側発信サーバであって、
    前記発信受付処理サーバからの発信要求を受け付ける第１の手段と、
    前記通信端末Ａ、および前記ゲートウェイを介して前記通信端末Ｂに発信する第２の手段と、
    前記通信端末Ａと通信端末Ｂとを接続した後に、それぞれの端末から送信されるデータをお互いに転送する第３手段とを有することを特徴とする両側発信サーバ。
13. 前記第２の手段は、前記通信端末Ａ、あるいは通信端末Ｂの一方の通信端末に発信し、一方の通信端末の通信可能性を確認した後に、他方の通信端末に発信し、
    前記第３の手段は、両通信端末の通信可能性が確認できた後に、それぞれの通信端末から送信されるデータをお互いに転送することを特微とする請求項１１または請求項１２に記載の両側発信サーバ。
14. ＩＰネットワーク上の通信端末と、
    公衆網上の通信端末と、
    前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
    両側発信サーバとを備える通信システムにおけるＩＰネットワーク上、あるいは公衆網上の通信端末であって、
    前記両側発信サーバに対して発信要求を行う第１の手段と、
    両通信端末間の通信が前記両側発信サーバ経由で確立したことを検出する第２の手段を有することを特徴とする通信端末。
15. ＩＰネットワーク上の通信端末と、
    公衆網上の通信端末と、
    前記ＩＰネットワークと前記公衆網との間に配置され、前記ＩＰネットワークと前記公衆網との間の通信を実現するゲートウェイと、
    発信受付処理サーバと、
    両側発信サーバとを備える通信システムにおけるＩＰネットワーク上、あるいは公衆網上の通信端末であって、
    前記発信受付処理サーバに対して発信要求を行う第１の手段と、
    両通信端末間の通信が前記両側発信サーバ経由で確立したことを検出する第２の手段を有することを特徴とする通信端末。
16. 発信要求を行った後に、通信相手の通信端末との通信が確立するまで、通信相手の通信端末と接続中であることをユーザに通知する第３の手段を有することを特徴とする請求項１４または請求項１５に記載の通信端末。
17. 請求項６ないし請求項１０のいずれか１項に記載の通信方法における、両側発信サーバ、通信端末Ａ、あるいは通信端末Ｂのステップをコンピュータに実行させるためのプログラム。
18. 請求項１７に記載のプログラムが記録されたコンピュータで読み取り可能な記録媒体。

Images