JP3809420B2 - 通信端末、通信端末の制御方法、および通信端末の制御プログラム - Google Patents
通信端末、通信端末の制御方法、および通信端末の制御プログラム Download PDFInfo
- Publication number
- JP3809420B2 JP3809420B2 JP2003016948A JP2003016948A JP3809420B2 JP 3809420 B2 JP3809420 B2 JP 3809420B2 JP 2003016948 A JP2003016948 A JP 2003016948A JP 2003016948 A JP2003016948 A JP 2003016948A JP 3809420 B2 JP3809420 B2 JP 3809420B2
- Authority
- JP
- Japan
- Prior art keywords
- communication terminal
- terminal
- internet resource
- call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、その制御プログラムに関するものである。
【０００２】
【従来の技術】
近年、インターネットの普及が世界的に急速に拡大しており、通信料金の著しい低減を図ることができる利点から、インターネット電話（以下ＩＰ電話）が注目を浴びている。インターネット電話で特に現在有力な規格はＶｏＩＰ（下記の非特許文献１：ＩＴＵ−Ｔ勧告Ｈ．３２３など）であり、このような規格によるインターネット電話対応の機器が様々な形で提案されている。
【０００３】
ＩＰ電話の１つの利用形態として、インターネットサービスプロバイダを経由して、常時接続する状態でＬＡＮを経由して相互に直接接続する形態が考えられる。ＩＰ電話では、通信しようとするユーザが相互にＩＰ接続する必要があるため、インターネット上にランデブーサーバが用意される。ランデブーサーバに電話番号と最寄のインターネットサービスプロバイダとの対応テーブルを設け、着呼側ユーザに公衆回線経由で通話要求と発呼側ユーザのＩＰアドレスとを通知し、双方のユーザがランデブーサーバを介して同時接続することにより、通話を実現する。このランデブーサーバを用いる規格の１つとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｅ Ｐｒｏｔｏｃｏｌ：下記の非特許文献２：ＲＦＣ２５４３）が知られている。
【０００４】
【非特許文献１】
ＩＴＵ−Ｔ勧告 Ｈ．３２３
【非特許文献２】
ＲＦＣ２５４３（http://www.faqs.org/rfcs/rfc2543.html）
【０００５】
【発明が解決しようとする課題】
ところが、従来のＩＰ電話の技術は、ＩＰコネクションの上で音声通信を行なうだけのものが多い。
【０００６】
たとえば、ＩＰ電話で通話中の場合、相互のＩＰアドレスが判明しているにもかかわらず、ユーザはこのＩＰアドレスを用いて利用できるインターネットリソースに全くアクセスすることができず、ユーザに充分なサービスを提供しているとはいえない。
【０００７】
たとえば、従来では、あるＷＥＢページやＦＴＰサーバ、その他のインターネットリソースの所在を通話相手に伝えたくても、ＩＰ電話の通話上の音声で伝え合うしか方法がない。インターネットリソースのアドレスは通常ＵＲＬ、ＵＲＩのような形式で表現されるが、多くの場合これらの文字数は電話番号ほどには短かくなく、誤りなくこのような形式のデータを音声で伝達するのは困難であり、また非常にわずらわしい。
【０００８】
さらに、現在では、ＷＥＢブラウザなどインターネットリソースを利用する機構を有する電話機が存在しているが、ユーザはこのような端末を用いていたとしても、一旦上記のようにして音声で伝達したインターネットリソースのアドレスをＷＥＢブラウザなどに再度入力しなければならない。
【０００９】
また、ユーザの端末がＩＰ電話と、ＷＥＢページ閲覧のようなインターネットリソースの利用を異なる接続方式でしかサポートしていない場合もあり、そのような場合はユーザはＩＰ電話を切断してから再度ＩＰ接続を行なわなければならない。どうしても通話とインターネットリソースの利用を両立させたければ、ＩＰ電話用の端末の他にさらにＰＣなどの別の機器を用い、別の呼接続の上でインターネットリソースを利用しなければならない。
【００１０】
本発明の課題は、上記の問題を解決し、他の機器を用いることなく通話端末のみによりＩＰ電話で通話中の相手とインターネットリソースを簡単安価に、また面倒な操作を必要とせず確実に共有できるようにすることにある。
【００１１】
【課題を解決するための手段】
上記の課題を解決するため、本発明によれば、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、およびその制御プログラムにおいて、通話中の相手通信端末と、同一のインターネットリソースを共有利用するためのインターネットリソース共有手段ないし制御過程を含む構成を採用した。
【００１２】
相手通信端末との同一のインターネットリソースの共有利用は、通話中の相手通信端末と目的のインターネットリソースのＵＲＬ情報を送受信することにより行なうことができる。
【００１３】
特に、前記ＵＲＬ情報は前記ＵＲＬ情報を受信した後の利用処理に関する利用制御情報を含む特定の形式で記述でき、前記ＵＲＬ情報を受信した場合、前記利用制御情報にしたがって前記ＵＲＬ情報に対応するインターネットリソースを利用（表示、インストールなど任意の処理）することができる。
【００１４】
また、前記ＵＲＬ情報の伝送は自機または相手通信端末の一方が他方にＦＴＰログインし、前記ＵＲＬ情報をＦＴＰ手順を用いて相手通信端末と送受信することにより行なうことができる。
【００１５】
また、相手通信端末に対してＦＴＰログインする際には、その認証情報としてメモリのアドレス帳領域に記憶された相手通信端末に関する情報を用いることができる。
【００１６】
また、前記ＵＲＬ情報の伝送は、前記ＵＲＬ情報を電子メールプロトコルを用いて相手通信端末と送受信することにより行なうことができる。
【００１７】
また、前記ＵＲＬ情報を記述した電子メールを受信するため、ＩＰ電話による通話中は、ＰＯＰサーバから電子メールを受信する電子メール時間間隔を通常よりも短縮することができる。
【００１８】
また、前記電子メール時間間隔の短縮は、前記ＵＲＬ情報を記述した最初の電子メールを受信した後から行なうことができる。
【００１９】
また、ＵＲＬ情報を伝送するだけではなく、自機または相手通信端末の一方がＨＴＴＰプロキシサーバとして、他方がＨＴＴＰクライアントとして動作し、相手通信端末との間でＨＴＴＰプロキシ手順を用いて目的のインターネットリソース自体を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用することもできる。
【００２０】
前記インターネットリソースは、ＨＴＴＰサーバにより提供されるＷＥＢデータやＦＴＰファイル、ＦＴＰディレクトリ情報、その他、ＩＰを介して利用可能な任意のデータであってよく、上記インターネットリソース共有のために必要な相手通信端末のＩＰアドレスは、ＩＰ電話の接続の時に取得したものを用いればよい。
【００２１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
【００２２】
なお、本明細書（特許請求の範囲も含む）では、用語として「インターネット」および「インターネットリソース」を用いるが、前者はＩＰ網を、後者はＩＰ網上でＩＰを介してアクセス可能なデータ（ファイルやディレクトリリストなどを含む）その他の資源を指す。すなわち、本明細書において用語「インターネット」は、単にＩＰ網と同義であり、広域的かつ公共的に利用されるいわゆる”Ｉｎｔｅｒｎｅｔ”の他、企業その他の組織内で閉じたいわゆるイントラネットのようなＩＰ網も含み、用語「インターネットリソース」はこれらのネットワーク上でＩＰを介してアクセス可能なデータを指すものとする。これは「ＩＰ網リソース」のような適当な上位概念の用語が現在のところ一般的ではないための止むを得ない措置である。
【００２３】
図１は本発明を採用したＩＰ電話機能およびＷＥＢブラウザ機能を有する通信端末の構成を示している。図１において、符号１００は、通信端末２００が接続されるＩＰ網（いわゆるインターネットの他に、イントラネットのように閉じた網も考えられるが、以下では特に区別する必要がある場合を除きインターネット網という）で、有線回線１０１を介して接続される。本実施形態では、有線回線１０１としてはＡＤＳＬであるものとし、図１の通信端末の回線はスプリッタ１０２によりＰＳＴＮ網用の帯域１０４と、ＡＤＳＬ網用の帯域１０３が分割され、通信端末２００は、ＰＳＴＮ接続による音声通信（たとえば通話およびファクシミリ）が可能であるとともに、インターネット接続（ＰＰＰｏＥなどのＡＤＳＬ接続方式が用いられる）、およびインターネット上の資源の利用（本実施形態の場合、少なくともＩＰ電話の他にＷＥＢページ閲覧、Ｅメール送受信など）が可能である。
【００２４】
なお、ＩＰ網１００への接続は、ＡＤＳＬである必要はなく光ファイバー回線や、ＣＡＴＶ回線、無線回線など任意の回線メディアを用いることができる。
【００２５】
図１の通信端末２００は液晶表示器などを用いた表示部２１４およびテンキーや各種ファンクションキーを含む操作部２１５、および音声通話用入出力のためのハンドセット２０８を有する。表示部２１４および操作部２１５は通話制御のために用いられる他、ＷＥＢブラウザ機能を実現するためにも用いられる。
【００２６】
本実施形態では、特に操作部２１５にリソース転送ボタン２１５ａおよびリロードボタン２１５ｂが設けられている。リソース転送ボタン２１５ａは、本端末どうしでＩＰ電話中にインターネットリソースを共有利用する場合に押下する。リロードボタン２１５ｂは、メールの強制受信操作（あるいはＷＥＢページのリロード操作など）に用いられる。
【００２７】
図２に図１の通信端末２００の制御系の構成を示す。図示の制御系は、通信端末２００でＩＰ電話機能および、ＷＥＢブラウザ機能の他、ファクシミリ機能（図１では不図示）を実現するものである。
【００２８】
図２においてＣＰＵ２０１は、データバス２１９を介して各部との信号の入力を行い、この入力した信号に応じてデータバス２１９に接続された各構成要素を制御する。すなわち、ＣＰＵ２０１はＲＯＭ２０２に格納されたプログラムにしたがって全体を制御し、網への接続や、各種プロトコルを制御し処理を実行する。もちろん操作、表示、読み取り、記録に使用する制御も含まれる。
【００２９】
さらに、ブロードバンド接続をつかさどる制御や、ＩＰ電話を実現するための制御、ＷＥＢアクセスを行なうための制御、ＷＥＢページを表示するためのブラウザ制御、また、ＩＰアドレスの検知、抽出制御、そして、ＵＲＬ等のデータを送信するためのファイル作成や、送受信制御を実行する。
【００３０】
また、ＲＯＭ２０２は、プログラムを格納したメモリであり、マスクＲＯＭやフラッシュＲＯＭなどで構成される。また、データの書込み、消去が必要なデータ用にフラッシュＲＯＭや、ＥＥＰＲＯＭも構成されることも考えられる。ＲＯＭ２０２には、ＣＰＵ２０１で行なう制御全般のプログラムが格納されている。
【００３１】
ＲＡＭ２０３はＣＰＵ２０１が処理を行なう場合のワークエリアとして、呼処理を含むＷＥＢ閲覧やＥメール送受信の各処理を実行するにあたって使用したり、読取、記録時、または音声ＣＯＤＥＣデータを処理するエリアでもある。ここは、ＲＯＭ２０２と異なり、一時的なデータが記憶される。
【００３２】
さらに、ＲＡＭ２０３は電池等でバックアップされる部分もあり、時間データ等、各種サービス機能の設定内容やアドレス帳（あるいは電話帳）に登録した内容を記憶する。図２ではこのような領域のうち、特にアドレス帳２０３ａの領域を図示してある。
【００３３】
このアドレス帳２０３ａには、通常回線の通話の際の番号通知などで得た電話番号、ＩＰ電話通信の際に得たＩＰアドレス、さらに、これらの選択情報に対応するユーザ名やメールアドレスの他、自機のユーザのユーザ名およびメールアドレスなどを所定の設定操作に基づき記憶させておく。
【００３４】
また、このアドレス帳に類した管理情報の記憶領域は、不揮発性のメモリとしてのＥＥＰＲＯＭ等で構成することもできる。
【００３５】
また、ＲＡＭ２０３は、ＩＰ電話接続手順にて検出したＩＰアドレスの一時保管や、ファイル送受信を行なうためのバッファや、ＷＥＢページ表示のための受信バッファとしても利用する。
【００３６】
通信制御部２０４は、アナログ（ＰＳＴＮ）公衆回線１０４を収容するためのインタフェイスであり、アナログ回線の場合、局交換機の電話回線（以後、加入者線と称す）に接続され、ダイオードによる全波整流回路により構成され、回線電圧の極性を一致させるための極性一致回路、回路局交換機の加入者線に接続され、局交換機からの呼出信号を検出するリンガー検出回路、オフフック操作が行われると回線ループを形成するとともに、局に対してダイヤルパルスを送出するパルス送出回路、２線−４線変換を行なうためのトランス回路で構成されている。また、外部に接続されるアナログ端末用のインターフェイス２５０も設け通常のアナログ端末も接続できるように構成されている。
【００３７】
２０５はＭＯＤＥＭ部であり、ＤＳＰとＡＦＥ（アナログフロントエンド）で構成され、機能的には、Ｇ３ＦＡＸによるファクシミリの送受信を行なうファクシミリモデムの機能を、ＣＰＵ２０１の制御により実現する。さらにモデムデータ（ナンバーディスプレイデータ）の解析を行なうナンバディスプレイ機能と、エコーキャンセラ機能を有し、スピーカフォン機能をも実現することができる。
【００３８】
音源部２０６は、保留音や着信メロディーの音源であり内部に音源データ生成機能をもち、ＲＯＭ２０２や、ＲＡＭ２０３に記憶してあるデータに基づきＣＰＵ２０１の制御により音源部２０６でアナログ信号として再生することができる。また擬似ＤＴ、ＢＴ、ＲＢＴ等のコールプログレストーンを出力するための音源も兼ねる。
【００３９】
符号２０７は音声処理部で、ＣＰＵ２０１の制御によりＭＯＤＥＭ部２０５からの信号や音源部２０６、後述するハンドセット２０８、スピーカ２０９、本体マイク２１０、通信制御部２０４等の入出力信号をこの音声処理部２０７の音声パス制御により処理する。
【００４０】
ハンドセット２０８（図１）は通常回線上の通話およびＩＰ電話における音声の入出力に用いられる。ハンドセット２０８のフックのＯＮ／ＯＦＦはフック検出部２１６により検出され、このフックの状態に応じて回線のＯＮ／ＯＦＦが制御される。
【００４１】
スピーカ２０９は着信音や記憶した音声データの出力およびスピーカフォン通話時のモニタに用いられる。本体マイク２１０はスピーカホン機能を実現する際の音声入力に使用する。
【００４２】
記録部２１１は、感熱型、熱転写型プリンタ、あるいはレーザービームプリンタ、インクジェットプリンタ等の周知の記録手段から構成され、ファクシミリ記録の場合ＭＨ、ＭＲ、ＭＭＲ符号化されたデジタルデータを復号化し、この復号化したデータを記録する。また、ＷＥＢブラウザからデータをプリントする場合は、ＲＡＭ２０３を受信バッファとして使用し、そこに格納されているマークアップ言語（通常ＨＴＭＬ）で記述されたウェブ１ページ分のデータを表示用データに変換し、表示部２１４の一画面に表示可能な量のデータをＲＡＭ２０３内の表示バッファに格納する。ＷＥＢブラウザは表示バッファへの格納を終了すると記録部２１１へ記録開始通知を行なう。
【００４３】
記録部２１１は格納終了通知を受けると表示バッファからデータを読み出し、１ラインごとにプリント用データに変換して記録部２１１へ転送する。転送が終わると転送終了通知をブラウザに通知する。転送終了通知を受けたブラウザは次の表示用データがあれば表示バッファに格納して記録部２１１に通知し、ウェブページ分のデータが終わり、次の表示用データがない時にはページ終了を通知する。以上の処理を繰り返して１ページ分のデータを記録部２１１に転送し、ウェブプリントを行なう。
【００４４】
読取部２１２はＣＣＤあるいは密着型センサアレイ等の周知の原稿読取手段を備えており、読取手段で読み取ったアナログデータをデジタルデータに変換するとともに、この変換されたデジタルデータをファクシミリ通信においては、ＭＨ、ＭＲ、ＭＭＲ符号化等の周知の符号化方法により符号化し出力する。
【００４５】
符号２１３はセンサ部であり、読取部２１２上の送信原稿の有無やサイズを検出しその結果をＣＰＵ２０１に通知する。また、記録部２１１上の記録紙の有無やサイズを検出しその結果をＣＰＵ２０１に通知する。
【００４６】
表示部２１４（図１）は、カラーＬＣＤや、モノクロＬＣＤ等の液晶部品などにより構成され、種々の情報表示を行なうために用いられる。表示部２１４の表示処理にはインターネット上のサーバより受信したＨＴＭＬの情報の表示、時刻の表示や通信中の回線状態およびエラー等の状態の表示、その他動作状態のモニタ表示、操作部２１５でキー入力された文字メッセージや受信した文字メッセージの表示、電話機の各種サービス機能の設定内容などの表示などが含まれる。
【００４７】
操作部２１５（図１）はキーボード（あるいはさらにマウスなどのポインティングデバイス）などから成り、表示部２１４とともにユーザーインターフェースを構成する。ＷＥＢブラウズ操作、プリント、発呼／着呼／登録などに関するあらゆるユーザ操作を受け付け、その内容を制御部２０１に通知する。
【００４８】
操作部２１５のキーには、前述のリソース転送ボタン２１５ａの他、公知のキーとして次のようなものが含まれる。すなわち、ダイヤル番号やＵＲＬ等を０−９および＊、＃および前記キーを利用しアルファベットや記号等を入力するためのダイヤルキー、ファクシミリの送受信を制御する送信、受信キー、回線のＯＮ／ＯＦＦを制御するオフフックキー、その他には保留キー、機能設定を行なうためのセレクトキー等のキーなどである。
【００４９】
ネットワーク制御部２４０は、インターネット通信にかかわる各種プロトコルを制御する。ネットワーク制御部２４０は便宜上回路ブロックとして示してあるが、実際にはその基本制御はＣＰＵ２０１のソフトウェアにより行なわれる。
【００５０】
ネットワーク制御部２４０は、ＭＩＩインタフェイスを用いたドライバ部２４１（通常ＰＨＹと呼ばれる）を介してＮＩＣ（ネットワークインターフェースカード）２４２（図示のように複数設けることも可）の入出力を制御するとともに、ＡＤＳＬモデム部２３０の入出力を制御する。
【００５１】
ＮＩＣ２４２はＣＳＭＡ／ＣＤ（イーサネット：商標名）などのインターフェース方式（あるいは他の）に基づくものを用いることができる。ＡＤＳＬモデム部２３０は上記のＡＤＳＬによる通信に用いられる。ＮＩＣ２４２はＬＡＮに接続された他の機器と通信するために用いられるが、後述の制御には必ずしも必須ではない。
【００５２】
ネットワーク通信において、ネットワーク制御部２４０を中心とした図２の回路ブロック間の入出力は次のように行なわれる。
【００５３】
ＩＰ電話の通信はたとえばＩＴＵ−Ｔ勧告Ｈ．３２３に記載されるＶｏＩＰにより行なう。ＶｏＩＰでは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎ）、ＲＳＶＰ（Ｒｅｓｏｕｓｅ ＲｅｓｅｒｖａｔｉｏｎＰｒｏｔｏｃｏｌ）などの各種プロトコルが利用される。
【００５４】
ＩＰ電話の場合、ハンドセット２０８から入力される音声信号は、音声処理部２０７を介して処理され、ＣＯＤＥＣ部２４３により、音声処理のためのコーデック処理を実行し、ＩＴＵ−Ｔ勧告Ｇ．７１１やＧ．７２９等の符号フォーマットに基づく符号化／復号化を介して音声信号がデジタルデータとして送受信される。また、通話相手のＩＰアドレスを特定するためには、ＳＩＰ、ＩＴＵ−Ｔ勧告Ｈ．３２３、あるいはＭＣＧＰ等のプロトコルが利用される。
【００５５】
本実施形態では、インターネットと通信し、またＮＩＣ２４２を介してＬＡＮとも通信する、つまり異なるネットワークセグメント間でパケットをフォワードする。したがって、ネットワーク制御部２４０には、異なるネットワークセグメント間でパケットを転送するルータ機能、およびアドレス／ポート番号の変換を行なうＮＡＴ機能が設けられていることが望ましい。
【００５６】
ＮＡＴ機能は、プライベートＩＰアドレスと、Ｉｎｔｅｒｎｅｔアクセスに利用できる本来のグローバルＩＰアドレスを相互に変換し、ローカルなＩＰアドレスしか割り当てられていないノードから、透過的にＩｎｔｅｒｎｅｔをアクセスできるようにするものである。
【００５７】
また、ＬＡＮに接続される機器のため、起動時に動的にＩＰアドレスを割り当て、終了時にＩＰアドレスを回収するため、ＤＨＣＰも設けられる。
【００５８】
ＡＤＳＬモデム部２３０がＡＤＳＬ網と接続する際には、ＰＰＰｏＥなどのプロトコルが用いられる。ＡＤＳＬ網と接続する際の認証ではＰＡＰ／ＣＨＡＰなどのプロトコルが用いられるので、ネットワーク制御部２４０には、これらの認証プロトコルも実装しておく必要がある。
【００５９】
ネットワーク制御部２４０とＡＤＳＬモデム部２３０はＵＴＯＰＩＡなどのインターフェースを介して接続される。
【００６０】
ＡＤＳＬモデム部２３０は、インターネット接続に使用するための通信制御部で、ここに、スプリッタで分離した公衆回線を接続する。そして、ＡＤＳＬモデム部２３０は、ＡＦＥ部２３１とＢＢ−通信部２３２で構成される。ＡＤＳＬモデム部２３０にはＡＤＳＬモデムのプログラム格納用のＲＯＭ２３３とデータワークエリアのＲＡＭ２３４が接続されている。
【００６１】
図３はＩＰネットワークの構成を概念的に示している。図３に示すように本実施形態の通信端末２００は、公衆回線１０１によってＩＰ網１００に接続され、相手の通信端末２２０と通信する。
【００６２】
図３は、通信端末（Ａ）２００と通信端末（Ｂ）２２０が同一のインターネットサービスプロバイダ（ＩＳＰ）に接続された状態を想定している。
【００６３】
ＩＰ網１００上には、ＩＰ電話での呼接続に用いられるＳＩＰサーバ１１０、電話番号／ＩＰアドレスの対応テーブルを管理するロケーションサーバ１１１、ＩＰアドレスとドメイン／ホスト名の対応テーブルを管理するためのＤＮＳサーバ１１２、ＷＥＢサーバ１１３が設けられている。
【００６４】
また、図４は図３と同等の構成であるが、ＩＰ網１００が異なるインターネットサービスプロバイダ（ＩＳＰ：１５１、１５３）を介して接続されている状態を示している。インターネット接続の形態としては、通信相手によっては図３、図４いずれの接続形態もあり得る。図４では、ＩＳＰ（Ａ）１５１を介して通信端末（Ａ）２００が接続され、ＩＳＰ（Ｂ）１５３を介して通信端末（Ｂ）２２０が接続されている。
【００６５】
図４の場合は、異なるサービスプロバイダを結ぶためのＩＳＰ−ＧＷ１５２が異なるＩＳＰ間のゲートウエイ的役目を行なうことにより、通信端末２００、２２０間の通信が可能となる。なお、ＩＳＰ−ＧＷ１５２は必ずしも単一の機器により構成されるものではなく、複数のゲートウェイ機器により構成されている場合もある。
【００６６】
本実施形態のＩＰ電話通信では、ＳＩＰ方式を用いる。ここで発呼側が通信端末２００、着呼側が通信端末２２０であるものとすると、ＳＩＰでは、まず発呼側の通信端末２００がＳＩＰサーバ１１０に発呼メッセージを送り、相手端末２２０との接続を要求する。ＳＩＰサーバ１１０は、ロケーションサーバ１１１に相手端末２２０のＩＰアドレスを問い合わせ、判明したＩＰアドレスを用いて通信端末２００と２２０の間のＩＰコネクションが形成される。
【００６７】
次に上記構成において、ＩＰ電話により通話中の通信端末間で、インターネットリソースを共有するための通信制御につき、異なる実施形態を説明する。
【００６８】
＜実施形態１＞
図５〜図９は本実施形態１のＩＰ電話通信のシーケンスを示している。図５〜図９のＩＰ電話通信では、図１および図２のように構成された通信端末Ａから通信端末Ｂへ呼接続し、通話を行なう。また、本実施形態では、端末ＡでＷＥＢブラウジングを行なうとともに、ＩＰ電話通信中に通信端末Ａから通信端末ＢにそのＵＲＬデータを転送し、通信端末（以下単に「端末」とも記す）ＡおよびＢとの間で同一のＷＥＢ情報を共有できるようにする。
【００６９】
なお、図５〜図９のＳＩＰサーバ１１０、ロケーションサーバ１１１、ＤＮＳサーバ１１２、およびＷＥＢサーバ１１３は、図３または図４に示したものと同じである。
【００７０】
図５〜図９の通信シーケンスは、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはたとえばＲＯＭ２０２に格納される（後述の他の実施形態においても同様）。図５〜図９の通信シーケンスの各ステップは符号Ｓ５０１以降により示されている。なお、図５〜図９の通信では、既にＡＤＳＬコネクションが成立し、端末ＡおよびＢがＩＰ網と接続されているものとする。
【００７１】
まず、端末Ａにおいて、ユーザが操作部２１５でダイヤル操作を行なう（図５のＳ５０１）。これにより、ＩＮＶＩＴＥメッセージにより、ＳＩＰサーバ１１０に接続される（Ｓ５０２）。
【００７２】
ＳＩＰサーバ１１０はロケーションサーバ１１１に対してＩＰアドレスを要求し（Ｓ５０３）、ロケーションサーバ１１１は指定された電話番号に対応したＩＰアドレスを検索し、ＳＩＰサーバ１１０に得られたＩＰアドレスを送信する（Ｓ５０４）。
【００７３】
ここで、ＳＩＰサーバは、受信した相手端末ＩＰアドレスを元に、ＩＮＶＩＴＥ要求を端末Ｂへ送出し、接続要求する（Ｓ５０６）。この時、端末Ｂが発信側端末ＡのＩＰアドレスを入手することになる。
【００７４】
端末Ｂは、ＳＩＰサーバからのＩＮＶＩＴＥ要求により着信動作に入る（Ｓ５０７）。そして、呼出中を示すＲｉｎｇｉｎｇをＳＩＰサーバに返し（Ｓ５０８）、ＳＩＰサーバは端末Ａに対してＲｉｎｇｉｎｇ信号を送信する（Ｓ５０９）。
【００７５】
端末Ｂが応答すると（Ｓ５１０）、接続完了を示すＯＫ情報がＳＩＰサーバ１１０に送信され（Ｓ５１１）、ＳＩＰサーバ１１０は、端末Ａに向けてＯＫ情報を送信し、端末Ａも相手端末ＢのＩＰアドレスを入手する（Ｓ５１２）。
【００７６】
その後、端末Ａ〜端末Ｂ間に生成されたＩＰコネクションを用いて音声パケットの送受信が可能となり（Ｓ５１３）、端末Ａおよび端末Ｂは通話状態となる（Ｓ５１４）。
【００７７】
通常、ＶｏＩＰによる通信は、リアルタイム性を重視し、メッセージを含めてＵＤＰベースで行なわれるが、ＴＣＰベースの接続を選択することもできる。
【００７８】
端末Ａは、ＩＰ網と接続されているため、ＷＥＢページやメール送受信など、インターネット上の資源を利用することができる。
【００７９】
端末Ａ、Ｂ間の通話の進行に応じ、両者の間で特定のＷＥＢページのようなインターネットリソースが話題にのぼることは充分考えられる。前述のように従来では、ＷＥＢページのＵＲＬはＩＰ電話中は音声でやりとりしていたが、本実施形態では端末ＡからＢにあるＷＥＢページのＵＲＬを伝送し、端末Ｂで閲覧できるようにする例を示す。
【００８０】
端末Ａで、ＷＥＢブラウザを起動し（Ｓ５１５）、操作部２１５からＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせる（Ｓ５１６）。問合せを受けたＤＮＳサーバ１１２は、ＵＲＬからＷＥＢサーバ１１３のアドレスを検索し（Ｓ５１７）、検索結果を端末Ａに返す（Ｓ５１８）。
【００８１】
端末ＡはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスする。端末ＡからＳＹＮパケットを出し（Ｓ５１９）、ＷＥＢサーバ１１３からＳＹＮ・ＡＣＫパケットを受信し（Ｓ５２０）、相手のＳＹＮに対してＡＣＫパケットを送信する（Ｓ５２１）。
【００８２】
このようにして同期が取れると、端末ＡはＷＥＢサーバ１１３にＷＥＢページのリクエストを行い（図６のＳ５２２）、ＷＥＢサーバ１１３からＷＥＢページのデータを得る（Ｓ５２３）。ＷＥＢページのデータを受信した端末ＡはブラウザにＷＥＢページを表示させる（Ｓ５２４）。
【００８３】
端末Ａは表示させたＷＥＢページを通話相手の端末Ｂにも表示させるため、ＵＲＬの転送を行なう。このＷＥＢページの内容を端末Ｂのユーザにも見てもらいたい場合には、端末Ａのユーザは操作部２１５のリソース転送ボタン２１５ａを押下する。
【００８４】
リソース共有利用を起動する操作として、上記のリソース転送ボタン２１５ａの操作の他、たとえば、表示部２１４のツールバーや、ＷＥＢブラウザのウィンドウの１つとして用意したコンソール上の「ＵＲＬ転送」など適当な名前のボタンの操作（ポインティングデバイスなどによる操作も含む）などが考えられ、これらの所定操作のいずれか、あるいはいずれも許容するような仕様も考えられる。
【００８５】
本実施形態では、端末Ａから端末ＢにＵＲＬ情報をＦＴＰ（ファイル転送プロトコル）で転送するため、ＵＲＬを記述したファイルを作成する（Ｓ５２５）。このＵＲＬを含むファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ：ＲＦＣ３２８８）で記述する。
【００８６】
ＦＴＰでは、制御用のコネクションと、データ（ファイル）転送用の２つのコネクションを用いる。
【００８７】
まず、端末Ａはロケーションサーバから得た端末ＢのＩＰアドレスに基き端末Ｂとの間で制御用ポートの同期を取る。端末ＡからＳＹＮパケットを送信し（Ｓ５２６）、端末ＢからＳＹＮ・ＡＣＫパケットを受信し（Ｓ５２７）、相手のＳＹＮに対してＡＣＫパケットを送信する（Ｓ５２８）。端末Ｂは端末ＡにＦＴＰ通信が開始できることを示すｒｅａｄｙを送信する（Ｓ５２９）。
【００８８】
端末Ａは端末Ｂにログインをかけ（Ｓ５３０）、端末Ｂは端末Ａのログインを許可する（Ｓ５３１）。
【００８９】
このＦＴＰログインの認証方式に関しては、既にＩＰコネクションが成立しているので、ユーザ名にａｎｏｎｙｍｏｕｓ、パスワードにメールアドレスを用いるいわゆる匿名ＦＴＰ方式を用いることで多くの場合充分であると考えられる。たとえば、匿名ＦＴＰ方式であっても、さらにＩＰ電話で現在通話中の相手からのＦＴＰログインのみしか受け付けないようにすればかなりのセキュリティを確保できる。
【００９０】
しかし、認証シーケンスにおいては、さらに相互の端末に固有の情報を交換してセキュリティを向上することも考えられる。たとえば、図２の構成によれば、アドレス帳２０３ａが設けられているので、端末Ａからはメールアドレスを送信し、端末Ｂでは端末Ａから送信されたメールアドレスが自機のアドレス帳２０３ａに格納されているか否かを判定し、格納されていれば端末ＡのＦＴＰログインを許可するようにすればよい。このようなＦＴＰログインシーケンスはユーザ入力を行なうことなく自動で実行することができ、しかも、上記のようにアドレス帳の情報を用いた認証を行なうようにすれば、面倒な操作を必要とせず、不特定多数の相手のＦＴＰログインを禁止でき、セキュリティを確保することができる。
【００９１】
続いて端末Ａは制御用のポートの他にＵＲＬデータ転送用のポートを用意（Ｓ５３２）し、データ転送用のポートを使用して端末ＢにＵＲＬデータを転送する（図７のＳ５３５）。まず端末Ａは端末Ｂとの間でデータ転送用のポートの同期を取る（Ｓ５３３、Ｓ５３４）。端末ＡはＵＲＬを記述したファイルをデータ転送用のポートを介して端末Ｂに送信する（Ｓ５３６）。ファイルを受信した端末Ｂは端末Ａのデータ転送用ポートにＡＣＫを返し、端末Ａの制御用ポートに受信完了を通知する（Ｓ５３７）。
【００９２】
ＵＲＬデータの転送が完了すると、端末ＡはＵＲＬデータ転送用のポートを開放する（Ｓ５３８）。端末Ａはデータ転送用のポートから端末Ｂにポート解放要求を送信し（Ｓ５３９）、端末Ｂは端末Ａのデータ転送用ポートにＡＣＫを返す（Ｓ５４０）。これを受けて端末ＡはＵＲＬデータ転送用のポートを開放完了し、ＵＲＬデータの転送を終了する（Ｓ５４１）。端末Ａは端末ＢにＦＴＰの終了を通知し（Ｓ５４２）、端末ＢからＡＣＫを受信する（Ｓ５４３）。
【００９３】
ＳＯＡＰで記述されたファイルを受信した端末Ｂは（Ｓ５４４）、受信したＵＲＬデータのファイルを解析する（Ｓ５４５）。ここで、図３１にＳＯＡＰで記述したＵＲＬデータの一例を示す。ＳＯＡＰはＸＭＬベースの情報伝達のためのプロトコルであるＳＯＡＰであり、ＳＯＡＰメッセージではエンベロープ、ヘッダ、ボディの構文構造になっており、図３１の下線部分、つまりＳＯＡＰメッセージのボディの部分に本実施形態の特徴がある。図３１の他の部分の構文構造は従来と同じである。図３１の特徴部分（アンダーライン部）は次のようになっている。
【００９４】
<BrowsURL>http://www.canon.co.jp/ezumi.html</BrowsURL>
このデータ型<BrowsURL>は、装置がブラウザを起動し、指定されたＷＷＷサーバのアドレスを閲覧すべきことを意味している。このように、ＳＯＡＰサービスで使用する各種データ型はあらかじめ端末がダウンロード したアプレット内でパーサー定義がなされており、アプレットはＳＯＡＰメッセージを受信した際にメッセージのヘッダ部分の識別子によりメッセージがサービスの情報パケ ットであることを認識することができる。
【００９５】
このようにして、ＳＯＡＰ記述により、受信したＵＲＬデータファイルの取り扱い方法を指定できるので、端末ＢはＳＯＡＰの指示通りブラウザを起動し（図８のＳ５４６）、ブラウザに端末Ａから受信したＵＲＬを入力する。端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせる（Ｓ５４７）。問合せを受けたＤＮＳサーバ１１２は、ＵＲＬからＷＥＢサーバ１１３のアドレスを検索し（Ｓ５４８）、検索結果を端末Ｂに返す（Ｓ５４９）。
【００９６】
端末ＢはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスする。まず端末ＢはＳＹＮパケットをＷＥＢサーバ１１３に送信し（Ｓ５５０）、ＷＥＢサーバ１１３からＳＹＮ・ＡＣＫパケットを受信し（Ｓ５５１）、相手のＳＹＮ・ＡＣＫに対してＡＣＫパケットを送信する（Ｓ５５２）。同期が取れると、端末ＢはＷＥＢサーバ１１３にＷＥＢページのリクエストを行い（Ｓ５５３）、ＷＥＢサーバ１１３からＷＥＢページのデータを得る（Ｓ５５４）。ＷＥＢページのデータを受信した端末ＢはブラウザにＷＥＢページを表示させる（Ｓ５５５）。
【００９７】
ＷＥＢブラウザによる閲覧を終えた端末Ａはブラウザを終了させ（図９のＳ５５６）、ＷＥＢサーバ１１３に切断を送信し（Ｓ５５７）、ブラウザを終了する（Ｓ５５８）。端末Ｂもブラウザを閲覧し終えるとブラウザを終了させる（Ｓ５５９）。ＷＥＢサーバ１１３に切断を送信し（Ｓ５６０）、ブラウザを終了する（Ｓ５６１）。
【００９８】
通話の終了（Ｓ５６２）は、図９の場合、端末Ａ側から行なっている。ＶｏＩＰおよびＳＩＰ手順に基づき、ＳＩＰサーバ１１０を介してＢＹＥおよびＯＫメッセージの交換（Ｓ５６３、Ｓ５６４、Ｓ５６６、Ｓ５６７）が行なわれ、端末Ｂ側ではこれに基づきＲＯＴ鳴動（Ｓ５６５）、オンフック（Ｓ５６８）が行なわれ、ＩＰ電話の通話シーケンスが終了する（Ｓ５６９）。
【００９９】
なお、上述のＵＲＬデータの送信操作は、通話中に何度でも行なえる。このとき、たとえば、端末Ａでインターネットリソースが変る（たとえば表示中のＷＥＢページの再表示や、他のＷＥＢページへのジャンプ）ごとにリソース共有ボタン２１５ａを操作する方式でもよいし、また、通話が終了するまで（あるいは他の明示的な操作を行なうまで）端末Ａでインターネットリソースが変る（たとえば表示中のＷＥＢページの再表示や、他のＷＥＢページへのジャンプ）ごとに自動的に端末Ａから端末ＢにＵＲＬデータを送信するようにしてもよい。
【０１００】
上記のＩＰ電話通信の概略を図１０〜図１２にフローチャートとして示す。図１０〜図１２の手順は上記の図５〜図９の通信シーケンスに対応するもので、上記同様、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはＲＯＭ２０２に格納される。図１０〜図１２の各ステップは符号Ｓ６０１以降により示されている。
【０１０１】
まず、端末ＡがＩＰ電話の発呼操作を行なう。端末Ａのダイヤル操作（図１０のＳ６０１）によりＳＩＰサーバ１１０を用いてＩＰ電話の呼接続処理が行なわれる。上述の通り、ＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、端末Ａに相手先端末の電話番号に対応するＩＰアドレスを返す（Ｓ６０２）。端末Ａは呼び出し中状態になり、相手先端末が応答するのを待つ（Ｓ６０３）。相手先端末が応答すると通話状態になる（Ｓ６０４）。
【０１０２】
端末ＡはＷＥＢページを表示させるためにブラウザを起動する（Ｓ６０５）。端末ＡのブラウザにＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ６０６）。端末ＡはＤＮＳサーバ１１２から得たＩＰアドレスに基づきＷＥＢサーバ１１３にアクセスしてＷＥＢページのデータを受信し（Ｓ６０７）、ブラウザにＷＥＢページを表示させる（Ｓ６０８）。
【０１０３】
端末Ａは表示させたＷＥＢページを相手先端末にも表示させるため、ＵＲＬの転送を行なう。端末ＡはＵＲＬをＦＴＰで転送するため、ＵＲＬを記述したファイルを作成する（Ｓ６０９）。ファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰで記述する。
【０１０４】
端末Ａはロケーションサーバから得た相手先端末のＩＰアドレスを元に相手先端末との間で制御用ポートの同期を取る（Ｓ６１０）。相手先端末との同期が取れると、続いて相手先端末にログインを行なう（Ｓ６１１）。
【０１０５】
端末Ａは制御用のポートの他にＵＲＬデータ転送用のポートを用意し、相手先端末との間でデータ転送用のポートの同期を取る（図１１のＳ６１４）。端末ＡはＵＲＬを記述したファイルをデータ転送用のポートを使用して相手先端末に送信する（Ｓ６１５）。ＵＲＬデータの転送が完了すると、端末ＡはＵＲＬデータ転送用のポートを解放する（Ｓ６１６）。端末Ａは相手先端末にＦＴＰの終了を通知し転送終了処理を行なう（Ｓ６１７）。
【０１０６】
ＷＥＢブラウザによる閲覧を終えた端末Ａはブラウザを終了させる（Ｓ６１８）。相手先端末との通話が終了すると通話を切断する（図１２のＳ６２６）。
【０１０７】
一方、端末Ｂ側の処理は次のように行なわれる。
【０１０８】
端末Ｂはスタンバイ状態において、着信があるかどうか監視をしている（図１０のＳ６１２）。着信を検出すると端末Ｂは着信に応答し（Ｓ６１３）、通話状態になる（Ｓ６０４）。
【０１０９】
相手先端末から同期を要求されると、端末Ｂはそれにしたがって同期を取る（Ｓ６１０）。相手先端末から（ＦＴＰ）ログインを要求されると、（ＦＴＰ）ログインを許可しデータ転送待ち状態になる（Ｓ６１１）。端末Ｂは相手先端末との間でデータ転送用のポートの同期を取り（図１１のＳ６１４）、相手先端末のデータ転送用のポートからＵＲＬを記述したファイルを受信する（Ｓ６１５）。
【０１１０】
ＵＲＬデータの転送が完了すると、相手先端末のデータ転送用のポートを解放し（Ｓ６１６）、相手先端末からＦＴＰの終了を受信し転送終了処理を行なう（Ｓ６１７）。
【０１１１】
ファイルを受信した端末Ｂは、受信したファイルの解析を行なう（Ｓ６１９）。ファイルがＳＯＡＰで記述されていて、ＵＲＬが指定されブラウザを起動させる指示があるなら（Ｓ６２０）、ＷＥＢページを表示させるためにブラウザを起動する（Ｓ６２１）。ブラウザに相手先端末から受信したＵＲＬを入力すると、端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ６２２）。端末ＢはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスしてＷＥＢページのデータを受信し（Ｓ６２３）、ブラウザにＷＥＢページを表示させる（Ｓ６２４）。
【０１１２】
ブラウザを閲覧し終えた端末Ｂはブラウザを終了させる（Ｓ６２５）。また、端末Ｂは相手先との通信状態を監視し（図１２のＳ６２７）、相手先に切断されたことを検出すると通話を終了する（Ｓ６２８）。
【０１１３】
以上では、発呼した端末Ａ側から端末Ｂ側にＵＲＬデータを送信する例を示したが、ＵＲＬの送信はいずれが発呼側かに関係するものではなく、当然ながら上記と同様にして端末Ｂから端末ＡにＵＲＬデータを送信し、端末Ａ側で閲覧させることができる。また、以上では、端末Ａ側から端末Ｂ側にＵＲＬデータを送信する場合、端末Ａ側が端末Ｂ側にＦＴＰログインする、つまり端末Ｂ側をＦＴＰサーバとして機能させ、端末ＡがＵＲＬデータを送信（図７のＳ５３６：この際ＳＴＯＲ、ないしＳＴＯＵなどのＦＴＰコマンドが用いられる）する例を示した。しかしながら、ＵＲＬデータ送信の際のＦＴＰのログイン方向、送受信方向（送信コマンドであるＳＴＯＲ、ないしＳＴＯＵを用いるか、受信コマンドであるＲＥＴＲを用いるか、など）は任意であり、適宜変更してよい。
【０１１４】
この一例を図１３〜図１５に示す。図１３〜図１５は、端末Ｂから端末ＡにＵＲＬデータを送信し、端末Ａ側で閲覧させる場合であるが、ただしこの場合、上記同様に端末ＡがＦＴＰサーバとしての端末Ｂにログインしているものとし、ＵＲＬデータ送信は、ＦＴＰの受信コマンドであるＲＥＴＲを用いる。
【０１１５】
図１３〜図１５では、端末ＡのＦＴＰ制御ポートおよびデータポートを符号２００により、端末ＢのＦＴＰ制御ポートおよびデータポートを符号２２０により示してある。図１３〜図１５では、図５に示したものと同様のＩＰ電話発呼シーケンスにより既に通話状態が形成されているものとする。また、既に図６に示したものと同様のＦＴＰログイン認証は終了しているものとする。
【０１１６】
図１３は端末ＢがＷＥＢページの閲覧を行なう時の様子である。すなわち、端末ＢがＷＥＢサーバ１１３から通常のＨＴＴＰプロトコル（Ｓ１１４７〜Ｓ１１５１）によりＷＥＢデータを取得し、そのページをレンダリングし、表示部２１４に表示させる（Ｓ１１５２）。その後、上述同様にしてＳＯＡＰフォーマットで記述したＵＲＬデータファイルを作成する（Ｓ１１７２）。このようにＵＲＬデータファイルは、リソース共有を行なうか否かにかかわらず、ＷＥＢページをダウンロードしたら無条件で作成してもよい。通常はＵＲＬデータファイルは１、２行の文字列に過ぎないので、このようにしてもシステムに大きな負荷はかからない。
【０１１７】
その後、端末Ａのユーザが通話の進行に応じ、端末Ｂのユーザと同一のＷＥＢページを閲覧したいと考え、転送のための所定操作（上述のリソース転送ボタン２１５ａないし他の同等操作）を操作部２１５により行なう。これにより、上記のようにして作成されたＵＲＬデータファイルが図１４に示すようにしてＦＴＰ転送される（Ｓ１１５３〜Ｓ１１６３）。この場合図示のように、ＦＴＰサーバとしての端末Ｂからファイルを取得するのでＦＴＰコマンドＲＥＴＲが用いられる（Ｓ１１５３）。
【０１１８】
その後、端末Ａで図１５に示すようにしてＵＲＬデータファイルが解析（Ｓ１１６４）される。さらに端末ＡはＳＯＡＰに基づき、ＷＥＢサーバ１１３からＷＥＢデータをダウンロード（Ｓ１１６５〜Ｓ１１６９）し、表示部２１４で表示（Ｓ１１７０）する。
【０１１９】
以上のようにして、実施形態１によれば、ＩＰ電話通信中に通信している端末どうしでインターネットリソースを共有する手段を提供することができる。実施形態１の場合、インターネットリソースはＷＥＢページ（のＵＲＬ）であり、第１の端末（Ａ）から第２の端末（Ｂ）に対してＦＴＰプロトコルによりＷＥＢページのＵＲＬを記述したデータファイル（ＵＲＬファイル）を送信することにより、第２の端末（Ｂ）でも第１の端末（Ａ）で閲覧しているものと同じＷＥＢページをブラウズすることができる。
【０１２０】
これによって、ＩＰ電話通信中に通信している端末どうしで同じインターネットリソースを利用（上記実施形態の場合表示であるが、下記のファームウエアの更新の場合のように共有するインターネットリソースの利用方法は表示に限定されるものではない）させることができ、従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースの情報が伝わり、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１２１】
また、ＵＲＬデータの受信側では、ＳＯＡＰを利用し、自動的にそのＵＲＬで示されるインターネットリソースを閲覧するブラウザを起動することができ、面倒な操作を一切必要としない。
【０１２２】
以上では、ＩＰ電話通信中の第１および第２の端末で共有するインターネットリソースとしてＷＥＢページを考えたが、ＵＲＬ（あるいはＵＲＩ）ないしこれと同等のインターネットリソースの所在を示す情報形式（ＦＴＰで送信できさえすればよい）で表現できるインターネットリソースであればどのようなものでも第１および第２の端末で共有することができる。ＵＲＬ形式だけで考えてみても、本発明により共有できるインターネットリソースは、ＦＴＰディレクトリやそのディレクトリ中のファイル、Ｇｏｐｈｅｒページ、音声やビデオ（静止画／動画）ストリームを提供する各種のサービスなど、数限りない。
【０１２３】
本発明のインターネットリソース共有技術は、ビジネスや娯楽のための情報共有に広く用いることができる。特に本発明の通信端末の製品展開などに有用と考えられるのは、本発明の通信端末のファームウエアのアップデートなどに利用することである。たとえば、本発明の通信端末のユーザがトラブルに遭遇し、ＩＰ電話でメーカーのサポート窓口に電話し、相談した結果、通信端末のファームウエアの更新が必要、という結論に達した場合、メーカーのサポート要員が直接そのユーザの通信端末にファームウエア（たとえばＨＴＴＰやＦＴＰで取得可能なファイルで、通常メーカーが運営するＨＴＴＰサーバ／ＦＴＰサーバから提供される）のＵＲＬを送信し、ファームウエアのアップデートを行なうことができる。ＳＯＡＰないし同等の取り決めを利用すれば、この（上述のようなＷＥＢ表示とは異なる）ファームウエアのアップデートのような受信側のファイルの取り扱いは任意に指定できるので、ユーザ操作を一切必要とせず通信端末のファームウエアのアップデートを行なうことができる。
【０１２４】
＜実施形態２＞
以上では、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有するためにＦＴＰプロトコルを用いてＵＲＬ情報を送受信する構成を示したが、ＵＲＬ情報の送受信にはＥメールプロトコル（ＳＭＴＰ）を用いることもできる。
【０１２５】
本実施形態でも、通信端末の構成は図１および図２に示したものと同様であるものとし、以下のシーケンス図およびフローチャートにおいても上記実施形態１と同様に通信端末Ａ（２００）および通信端末Ｂ（２２０）の間の通信につき説明する（後続の各実施形態においても同様）。
【０１２６】
本実施形態では、メール送受信を行なうため、図１６に示すようにＩＰ網１００にはメールサーバ１１４およびＰＯＰサーバ１１５が必要である。メールサーバ１１４およびＰＯＰサーバ１１５のサービスは通常、ＩＳＰにより提供されるものであり、本実施形態の実施のために特別に設置する必要はない。図１６ではメールサーバ１１４およびＰＯＰサーバ１１５を１つづつしか示していないが、通信端末Ａ、Ｂ（２００、２２０）のＩＳＰが異なる、などの理由でそれぞれ別のメールサーバ１１４およびＰＯＰサーバ１１５を用いることもある。
【０１２７】
メールサーバ１１４はＳＭＴＰプロトコルによりユーザからのメール送信を受けつけるとともにサーバ間のメールの配送を行ない、ＰＯＰサーバ１１５は（主としてダイアルアップ接続のユーザのため）着信したメールを最終ユーザに配送するために用いられる。ＰＯＰサーバ１１５が実行する対ユーザ配送にはＰＯＰの他にＡＰＯＰやＩＭＡＰなどを用いることもできる。メールサーバ１１４でもＳＭＴＰに代るＥメールプロトコルを用いることが考えられるが、現在ではＳＭＴＰが最もメジャーなＥメールプロトコルである。
【０１２８】
図１７〜図２１に本実施形態の通信シーケンスを、図２２および図２３に対応するフローチャート図を示す。
【０１２９】
図１７〜図１８において、端末ＡでＷＥＢサーバ１１３からＷＥＢページを取得し、表示するまでのシーケンス（Ｓ２５０１〜Ｓ２５２４）は、図５〜図６のシーケンス（Ｓ５０１〜Ｓ５２４）と全く同様である。
【０１３０】
端末ＡはブラウザにＷＥＢページを表示（Ｓ２５２４）させた後、このＷＥＢページの内容を端末Ｂのユーザにも見てもらいたい場合には、端末Ａのユーザは操作部２１５のリソース転送ボタン２１５ａを押下する。
【０１３１】
これにより、端末Ａは利用中のインターネットリソース、すなわち表示中のＷＥＢページの所在を示すＵＲＬデータを転送するためのＥメールテキストを作成する（Ｓ２５２５）。このＥメールテキストでは、受信側で容易に解析し、その後のインターネットリソースの利用処理を制御できるような特別な記述形式を用いると都合がよい。本実施形態では、“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”という記述形式を用いる。この記述形式の場合、受信側では、”ＵＲＬｔｏ”を検索してその後に続く＜＞で囲まれたＷＥＢページ（あるいは他のインターネットリソース）のＵＲＬを容易に抽出できる。
【０１３２】
すなわち、上記のようなＵＲＬ情報の記述形式は、実施形態１におけるＳＯＡＰによるものと同様、ＵＲＬ情報を受信した後の利用処理に関する利用制御情報を含むものといえ、このようなタグ付きのＵＲＬ情報を受信した側では、この利用制御情報にしたがってＵＲＬ情報に対応するインターネットリソースを利用することができる。
【０１３３】
さらに、端末Ａにおいて、端末ＢのＩＰアドレス（Ｓ２５１２で取得済み）から、端末ＡのＲＡＭ２０３内のＩＰアドレス−メールアドレスのテーブルを用いて、端末Ｂのメールアドレスを検出し、このアドレスに対してＳ２５２５で作成したメールを送信する（Ｓ２５２６）。
【０１３４】
メールの送信は通常のメールで一般的に使用されているＳＭＴＰプロトコルによって行われる。もちろん、このとき、ＩＰ電話データの通信で使用しているポート番号とは別の、ＳＭＴＰ用のＷｅｌｌ−Ｋｎｏｗｎポート番号であるポート番号２５を用いてＴＣＰパケットのやり取りを行なうので、メールの送信と音声パケットとは混ざりあうことなく通信でき、音声通話をしながらメール送信ができる。
【０１３５】
まず、端末Ａは自機が送信に使用できるメールサーバ１１４にコネクションを開始する（図１８のＳ２５２７）。詳細のコマンドのやりとりは省略しているが、ＳＭＴＰの規約に基づき自分のドメイン名や送信元である自分のメールアドレス、送信先相手のメールアドレスなどがメールサーバ１１４に伝えられる。メールサーバ１１４でメール送信が問題なく行なえることを確認されると、サーバからＯＫコマンドが返ってくる（Ｓ２５２８）。
【０１３６】
続いて、Ｓ２５２５で作成したメールをメールサーバ１１４に送信し（Ｓ２５２９）、メールが正常にメールサーバ１１４に届いたらＯＫコマンドが返ってくる（Ｓ２５３０）。そして、端末Ａが通信を終了させるための終了要求コマンドをメールサーバ１１４に送信し（Ｓ２５３１）、メールサーバ１１４は終了コマンドを返してメール送信が完了する（Ｓ２５３２）。
【０１３７】
メールを受け取ったメールサーバ１１４は、宛先の端末Ｂのユーザ配送を行なうＰＯＰサーバ１１５にメールを転送する（Ｓ２５３３）。
【０１３８】
端末Ｂでは公知のＰＯＰ３のプロトコルでメールの受信を行なう（図１９のＳ２５３４）。このとき、音声のデータの通信で使用しているポート番号とは別の、ＰＯＰ３用のＷｅｌｌ−Ｋｎｏｗｎポート番号であるポート番号１１０を用いてＴＣＰパケットのやり取りを行なうので、メールの受信と音声パケットとは混ざりあうことなく通信でき、音声通話をしながらメール受信ができる。
【０１３９】
通常、端末ＢがメールをＰＯＰサーバ１１５に取りにいく時間間隔はユーザ設定されている。あるいは、リロードボタン２１５ｂ（あるいはマウスなどによるメニュー操作など他の操作でもよい）の入力によって、強制的にメールを受信することもできる。端末Ｂの製品仕様や設定状態によっては、端末Ａでインターネットリソース共有操作を行なった時、端末Ｂでリロードボタン２１５ｂなどによるメール受信操作を行なう必要がある場合も考えられるが、上記のメールのポーリング間隔をごく短かく設定する、特に後述のようにＩＰ電話の通話中は自動的にメールのポーリング間隔を短かい時間（数秒程度）に設定する、などの対策をとれば、実用上大きなタイムラグは生じない。
【０１４０】
なお、端末Ｂが固定ＩＰアドレスを有していたり、携帯電話のようにＰＯＰやＩＭＡＰを用いずに直接メールを着信できる装置の場合は、端末Ａが送信したメールはＰＯＰ／ＩＭＡＰサーバを経ずに端末Ｂに着信する。具体的には、端末ＡがＳＭＴＰサーバ機能を有し、かつ端末Ｂが電子メールをＳＭＴＰで受信する機能を有していれば、端末ＡはＳ２５２５で作成したメールを、サーバを介さずに直接端末ＢにＳＭＴＰプロトコルで送信できる。また、この際の認証方式は、必要であれば実施形態１で説明したものと同様のものを用いることができる。
【０１４１】
ＰＯＰのメール受信シーケンスの場合は次のように進む。端末Ｂはまず自分のユーザ名やパスワードなどをＰＯＰサーバ１１５に送信し、ＰＯＰサーバ１１５とコネクションを開始する（Ｓ２５３５）。ユーザ名、パスワードなどを認証するとＰＯＰサーバ１１５はＯＫコマンドを返す（Ｓ２５３６）。
【０１４２】
続いて端末Ｂは自分宛てのメールが届いているかを確認するコマンドをサーバに送信する（Ｓ２５３７）。本シーケンスでは、端末Ａから送信されたＵＲＬ通知メールがＰＯＰサーバ１１５に届いているので、ＰＯＰサーバ１１５は受信メールがあることを端末Ｂに通知する（Ｓ２５３８）。端末Ｂはメールの受信を要求するコマンドをサーバに送信して（Ｓ２５３９）、ＰＯＰサーバ１１５はＵＲＬ通知メールを端末Ｂに送る（Ｓ２５４０）。メール受信が完了すると端末Ｂは終了要求をＰＯＰサーバ１１５に送信し（Ｓ２５４１）、それに対してＰＯＰサーバ１１５は終了コマンドを端末Ｂに返して、メールの受信は終了する（Ｓ２５４２）。
【０１４３】
また、本実施形態では、後述のフローチャートで詳細に説明するように、ＩＰ電話通話中は初期設定されているメール受信間隔より短い間隔でメールを取りに行くことができる。これはいちいちリロードボタン２１５ｂを押さなくても、端末ＡでＷＥＢページが更新されるごとに（端末Ａにおける自動制御あるいは明示的な手動操作に基づき）送られるＵＲＬ通知メールを、大きな遅延なしに受信してページの更新に追従することができる。
【０１４４】
ＵＲＬ通知メールを受信（Ｓ２５４３）した端末Ｂは、受信したメールテキストを解析し、メール中のＵＲＬを抽出する（Ｓ２５４４）。
【０１４５】
その後、図２０〜図２１において、端末Ｂで行なわれるＷＥＢページの表示シーケンス（Ｓ２５４６〜Ｓ２５６９）は、図８〜図９のシーケンス（Ｓ５４６〜Ｓ５６９）と同様である。
【０１４６】
図２２は端末Ａ側の、図２３は端末Ｂ側の制御手順を示している。
【０１４７】
図２２において、ダイヤル操作を行ない、ＩＮＶＩＴＥメッセージを送信してＳＩＰサーバ１１０に接続すると（Ｓ２６０１）、ＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、ｒｉｎｇｉｎｇを送信端末に返すので、相手先端末が応答するのを待つ（Ｓ２６０２）。相手先端末が応答すると、ＯＫメッセージと相手先端末の電話番号に対応するＩＰアドレスを送信端末に返すので、送信端末は相手先のＩＰアドレスを取得してＲＡＭ２０３に一時格納し（Ｓ２６０３）、その後、ＩＰ電話の通話状態に入る（Ｓ２６０４）。
【０１４８】
端末ＡにおいてＷＥＢページを表示させるためにブラウザを起動し（Ｓ２６０５）、ブラウザにＵＲＬを入力すると、ＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ２６０６）。そしてＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスして目的のＷＥＢページのデータを受信し（Ｓ２６０７）、ブラウザにＷＥＢページを表示させる（Ｓ２６０８）。
【０１４９】
本実施形態では、前述のように、ＵＲＬデータをメールにより送信する。ＵＲＬをメールで転送するため、ＵＲＬを記述したメールを作成する（Ｓ２６０９）。本実施形態では“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”というテキストデータをメール本文中に書き込んだメールを作成している。ただし、ＵＲＬの記載方法は送信側と受信側とで同じ規格で行われていれば、特にこれに限ったものでなくてもよく、表題（Ｓｕｂｊｅｃｔ：ヘッダ）にＵＲＬを書いても構わないし、“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”のような形式でなくても構わない。つづいて、ＲＡＭ２０３内にあるＩＰアドレスとメールアドレス対応表を用いて、ステップＳ２６０３で取得した相手先ＩＰアドレスをもとに、相手先のメールアドレスを検索する（Ｓ２６１０）。検索した結果メールアドレスが見つかればステップＳ２６１２以降のメール送信を行い、見つからなければメールは送信できないので、通話を続けながら、最終的にはステップＳ２６１５に進み、ブラウザを終了させる（Ｓ２６１１）。
【０１５０】
ステップＳ２６１１でメールアドレスが見つかったら、ステップＳ２６１２で見つかったメールアドレスを宛先として作成したＵＲＬ通知メールを送信する要求をメールサーバ１１４に送信する（Ｓ２６１２）。メールサーバ１１４では、送信元である送信端末のドメイン、送信先のメールアドレスなどをチェックして、メール送信を許可するかどうかを判断する。送信端末ではメールサーバ１１４からＯＫメッセージがくるか否かを待つ（Ｓ２６１３）。ステップＳ２６１３でＯＫメッセージを受信すれば、メールを送信し（Ｓ２６１４）、通話を続け、受信しなければメールを送信しないで通話を続け、最終的にはステップＳ２６１５に進み、ブラウザを終了させる。もちろん他のＷＥＢページにアクセスして、もう一度ステップＳ２６０６からの処理を行なうことが可能であることはいうまでもない。
【０１５１】
通話を終了するときは、オンフックにすることによって送信端末はＳＩＰサーバ１１０にＢＹＥコマンドを送信して通話を終了する（Ｓ２６１６）。もちろん相手先に切断されたことをＢＹＥコマンドの受信によって検出すると通話を終了することは言うまでもない。
【０１５２】
一方、端末Ｂ側では、スタンバイ状態では着信があるかどうか監視をしている（図２３のＳ２７０１）。ＩＮＶＩＴＥコマンドの受信によって着信を検出すると、着信に応答しＯＫコマンドを返し（Ｓ２７０２）、通話状態に入る（Ｓ２７０３）。
【０１５３】
この通話中、設定されている受信メール取得時間になったか（Ｓ２７０４）、およびリロードボタン２１５ｂによる受信メール取得操作があるか（Ｓ２７０５）をチェックする。この種の機器では、デフォルトのメール受信間隔は１５分程度とするが、ユーザの設定によってこの時間は変更可能である。
【０１５４】
なお、後述の通り、本実施形態ではＵＲＬデータの転送後、メール受信間隔をより短い時間に短縮するが、ＩＰ電話の通話開始直後から（たとえばＳ２７０３において）このメール受信間隔の短縮を行なってもよい。
【０１５５】
受信メール取得時間でもなく（Ｓ２７０４）、リロードボタン入力もなければ（Ｓ２７０５）、通話が切断されたかをＢＹＥコマンドを受信するか否かでチェックし（Ｓ２７１７）、通話が切断していなければ、通話状態を保持する。
【０１５６】
受信メール取得時間であるか（ステップＳ２７０４）、リロードボタン入力（Ｓ２７０５）があると、ＰＯＰサーバ１１５に接続して受信メール確認コマンドを送出する（Ｓ２７０６）。ＰＯＰサーバ１１５からの返信コマンドによって、受信メールがあるか否かをチェックして（Ｓ２７０７）、受信メールがなければ通話が切断されたか否かをチェック（Ｓ２７１７）する。
【０１５７】
ＰＯＰサーバ１１５に受信メールがあれば、受信メール取得コマンドをＰＯＰサーバ１１５に送出して、ＰＯＰサーバ１１５から受信メールを転送させる（Ｓ２７０８）。
【０１５８】
そして、ＰＯＰサーバ１１５から受信したメールの中（当然複数のメールを受信することもある）にＵＲＬを通知するメールがあるかを判定（Ｓ２７０９）する。この判定は、メール本文中に前述の“ＵＲＬｔｏ：＜ＵＲＬ＞”の記述があるか否かチェックすることにより行なう。上記のようにして端末Ａから送られたＵＲＬ通知メールがあれば、そのメールの“ＵＲＬｔｏ：”タグからＵＲＬ文字列を抽出する（Ｓ２７１０）。
【０１５９】
ＵＲＬ通知のメールを受信すると、この通話中に、たとえば送信側でＷＥＢページの更新があって、新たなＵＲＬが通知されてくることが頻繁に起こることが想定される。この場合に設定値（デフォルトはたとえば１５分）のままだと、端末Ａ側でＷＥＢページが更新されるたびに、端末Ａ側の通話音声にしたがって通話中の音声によってページが更新されたことを聞いた上で、リロードボタン２１５ｂを操作しなければ新しいＵＲＬを受信できないので、本実施形態では、受信メール取得時間を１分（あるいはより短い時間でもよい）に変更する（Ｓ２７１１）。もちろん、先に触れたように、ＩＰ通話開始直後（たとえばＳ２７０３）からこの受信メール取得時間短縮を行なっている場合にはこの処理は必要ない。
【０１６０】
続いてＷＥＢページを表示させるためにブラウザを起動し、（Ｓ２７１２）ＵＲＬ通知メールの“ＵＲＬｔｏ：”タグから抽出したＵＲＬ文字列をＷＥＢブラウザに入力する。端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ２７１３）。続いてＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスし、ＷＥＢページのデータを受信し（Ｓ２７１４）、ブラウザにＷＥＢページを表示させる（Ｓ２７１５）。その後、ブラウザの閲覧が必要なくなったらブラウザを終了させる（Ｓ２７１６）。
【０１６１】
通話の終了はＢＹＥコマンドを受信するか否かでチェックする（Ｓ２７１７）。相手先に通話を切断されたことを検出するとＯＫコマンドを返して通話を終了し、オンフック状態に復帰する（Ｓ２７１８）。その後、ステップＳ２７１１で変更した受信メール取得間隔を設定値に戻し（Ｓ２７１９）、処理を終了する。
【０１６２】
なお、ここではＵＲＬの送信側で“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”というテキストデータをメール本文中に書き込んだメールを作成し、受信側で受信したメールの中（当然複数のメールを受信することもある）に前述の“ＵＲＬｔｏ：＜ＵＲＬ＞”の記述があるか否かチェックすることで同一のインターネットリソースの共有利用を実施した。しかしこれに限らず、送信側で図３１に示されるＳＯＡＰメッセージをもつ実行ファイルを添付したメールを作成して送信し、受信側でＳＯＡＰメッセージをもつ実行ファイルを受信したかどうかをチェックすることでＳＯＡＰを用いるようにすることも可能である。
【０１６３】
以上のようにして、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有することができ、実施形態１と同様に従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースの情報が伝わり、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１６４】
本実施形態２によれば、ＵＲＬデータの転送にＥメールを用いている。メール送受信の機能はこの種の装置に設けられることが多いため、ハードウェア／ソフトウェア構成を大きく変更せずに実施することができる。また、上記のようにメール受信間隔を短縮する（ＩＰ通話開始直後から、あるいは最初のＵＲＬ通知メールを受信した後）ことにより、大きなタイムラグを生じることなくインターネットリソースを共有利用することができる。
【０１６５】
なお、実施形態１で述べた種々の変形例は、実施形態１とのＵＲＬデータの転送方式の差異に関係するものでなければいずれも同様に本実施形態２においても通用するのはいうまでもない。
【０１６６】
＜実施形態３＞
以上では、ＵＲＬデータの転送方式にＦＴＰ、あるいはＥメールプロトコル（ＳＭＴＰ）を用いる例を示した。本実施形態では、ＨＴＴＰプロキシ技術を用いてＵＲＬデータを転送する。
【０１６７】
ＨＴＴＰプロキシサーバに関しては、ＨＴＴＰ−１．１に関してはＲＦＣ２６１６に記載されている。ＨＴＴＰプロキシサーバは、ＨＴＴＰクライアントに代ってＨＴＴＰサーバにアクセスし、目的のＨＴＴＰデータを取得し、ＨＴＴＰクライアントに転送するもので、ＨＴＴＰデータをキャッシュすることもでき、これによりＨＴＴＰトラフィックを軽減したり、あるいはＨＴＴＰクライアントの情報（ＩＰアドレスその他のブラウザが提供可能な情報）をＨＴＴＰサーバから隠すなどの目的で広く利用されている。
【０１６８】
本実施形態では、ＩＰ電話の通話中の相手とインターネットリソースを共有利用したい場合、一方の端末がＨＴＴＰプロキシサーバとして機能することにより相手にインターネットリソースデータそのものを送信する。したがって、本実施形態では、インターネットリソースの所在を示すＵＲＬデータを転送するのではなく、既に取得済みのインターネットリソース自体を通話相手に転送する。
【０１６９】
本実施形態でも、通信端末およびネットワークの構成は図１〜図４に示したものと同様であるものとし、以下のシーケンス図およびフローチャートにおいても上記実施形態１と同様に通信端末Ａ（２００）および通信端末Ｂ（２２０）の間の通信につき説明する。
【０１７０】
図２４および図２５は、端末Ａと端末ＢがＩＰ電話により通話中、端末ＡがＷＥＢページを取得し、端末ＡがＨＴＴＰプロキシサーバ、端末ＢがＨＴＴＰクライアントとなりＷＥＢページを共有利用する様子を示している。
【０１７１】
図２４のＳ３７０１〜Ｓ３７０４はＩＰ電話による通話を開始するまでの処理である。まず、端末Ａが端末Ｂを発呼する（もちろん、この発呼方向は逆であっても構わない）。
【０１７２】
端末Ａはダイヤル操作を行いＳＩＰサーバ１１０に接続する（Ｓ３７０１）。前述同様にＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、端末Ａに相手先の端末Ｂの電話番号に対応するＩＰアドレスを返す（Ｓ３７０２）。端末Ａは呼び出し中状態になり、端末Ｂが応答するのを待つ（Ｓ３７０３）。端末Ｂが応答すると通話状態になる（Ｓ３７０４）。
【０１７３】
一方、端末Ｂはスタンバイ状態では着信があるかどうか監視をしている（Ｓ３７１１）。着信を検出すると端末Ｂは着信に応答し（Ｓ３７１２）、通話状態になる（Ｓ３７０４）。
【０１７４】
本実施形態では、端末ＢにおいてあるＷＥＢページを閲覧する需要が発生し、そのＷＥＢページを端末Ａで共有利用（閲覧）させたい場合の処理を説明する。この場合、端末Ｂでブラウザを起動し（Ｓ３７１３）、目的のＷＥＢページのＵＲＬを入力して、（普通の閲覧操作ではなく）リソース共有ボタン２１５ａを操作する。
【０１７５】
これにより、端末Ｂは端末ＡをＨＴＴＰプロキシサーバ、自端末をクライアントとして、端末Ａにアクセスする。すなわち、端末Ａと同期を取り、表示したいＷＥＢページをプロキシサーバに要求する（Ｓ３７１４）。このＨＴＴＰプロキシ手順については、後でより詳細に説明する。
【０１７６】
端末Ａは、ＨＴＴＰクライアントとしての端末Ｂからのアクセスを監視（Ｓ３７０５）しており、端末Ｂからアクセスが行われると、端末Ｂと同期を取りＷＥＢページ要求を受け取り、端末Ｂが表示したいＵＲＬ情報を取得する（Ｓ３７０６）。
【０１７７】
端末Ａは、取得したＵＲＬ情報を用いてＷＥＢサーバ１１３にアクセスし（Ｓ３７０７）、端末Ｂが要求したＷＥＢデータを取得する（Ｓ３７０８）。取得したＷＥＢデータは端末Ａのキャッシュに保存されるとともに、ＨＴＴＰクライアントとしての端末ＢにもＷＥＢページ要求に対する応答として転送する（Ｓ３７０９）。
【０１７８】
また、端末Ａはブラウザを起動させ、端末Ｂから要求されたＷＥＢページを表示させる（Ｓ３７１０）。ただし、端末Ａにおける表示は必ずしも必須のものではない。一方、端末Ｂはプロキシサーバとしての端末Ａからの応答を待ち（Ｓ３７１５）、プロキシサーバからＷＥＢデータを取得し（Ｓ３７１６）、取得したＷＥＢページを表示させる（Ｓ３７１７）。閲覧が終ったら、端末ＡないしＢはブラウザを終了させる（図２５のＳ３７１８、Ｓ３７２０）。
【０１７９】
本実施形態では、端末Ｂとの通話が終了すると端末Ａから通話を切断している（Ｓ３７１９）。端末Ｂでは、端末からの切断を検出（Ｓ３７２１）するとオンフック処理を行ない通話を切断する（Ｓ３７２２）。この切断シーケンスにおいて、端末ＡおよびＢの動作は図示と逆であってもよい。
【０１８０】
また、以上では、端末ＡがＨＴＴＰプロキシサーバとして、端末ＢがＨＴＴＰクライアントとして動作し、端末ＢからＷＥＢページを要求しているが、これらの役割は逆であってもかまわない。
【０１８１】
図２６は、端末Ａから端末Ｂへ呼接続するときのシーケンス図である。発呼側の端末ＡはＩＳＰサーバ１１０に接続可能で、被呼側の端末ＢもＩＳＰサーバ１１０に接続可能である。ＩＳＰサーバ１１０はＳＩＰサーバ、ロケーションサーバ、ＤＮＳサーバなどから構成され、お互いにインターネットで接続されている。
【０１８２】
まず端末Ａにおいて操作部２１５からダイヤル操作を行なう。前述の各実施形態同様、これにより端末ＡからＳＩＰサーバ１１０を介してＩＮＶＩＴＥメッセージが送信され、端末Ｂとの通話状態が形成される（Ｓ４００５〜Ｓ４０１２）。端末ＡおよびＢは相互のＩＰアドレスを認識する。
【０１８３】
図２７は、通話開始後、上記のようにして端末ＡがＨＴＴＰプロキシサーバとして、端末ＢがＨＴＴＰクライアントとして動作し、端末ＢからＷＥＢページを要求する際のＨＴＴＰパケットのやり取りを示している。また、図２８〜図３０は各ＨＴＴＰパケットの構成を示している。
【０１８４】
図２７のシーケンスには４０００番台のステップ（シーケンス）番号が用いられ、図２８〜図３０では５０００番台の参照符号が用いられている。以下の説明では「（Ｓ４ｘｘｘ・５ｘｘｘ）」の形式で、各図のステップおよびパケット（ないしその内部構成）との対応を示す。
【０１８５】
まず、図２８によりＨＴＴＰパケットの構成を説明する。図２９および図３０のパケットは図２８の構造を有する。図２８はＴＣＰ／ＩＰで用いられるパケットの一般的な構成を示しており、図示のように、ＴＣＰ／ＩＰパケットはＩＰヘッダ部５００１とＩＰデータ部５００２から成る。ＩＰヘッダ部５００１には送信元のＩＰアドレス５００８、送信先のＩＰアドレス５００９などが記述される。
【０１８６】
ＩＰデータ部５００２は、さらにＴＣＰヘッダ部５００３とＴＣＰデータ部５００４から成り、ＴＣＰヘッダ部５００３には送信元ポート番号５００５、送信先ポート番号５００６、ＴＣＰパケットのタイプなどを示すコントロールフラグ５００７などが記述される。
【０１８７】
以下、図２７、図２９、および図３０を参照して、端末Ａがプロキシサーバ、端末Ｂがクライアントとなり、同一のＷＥＢページを共有利用する際の動作を説明する。
【０１８８】
プロキシサーバとして機能する端末Ａは、ＷＥＢサーバ１１３、およびＨＴＴＰクライアントとして動作する端末Ｂとの間でそれぞれＨＴＴＰデータを送受信するために、データ送受信用の２つのポートを用いる。図２７では、端末Ａを端末Ａ−１、および端末Ａ−２として示しているが、この２つの表示は上記のデータ送受信用の２つのポートに対応するものである。ＴＣＰ／ＩＰでは、ポート番号は相手と同期を取ってから役割を終えるまでの一連の流れが終ると、次には違うポート番号が使用される。ＨＴＴＰクライアントとして動作する端末Ｂも複数のポートを用いることができるが、本実施形態のＨＴＴＰ通信では１つのみ用いる。
【０１８９】
まず、端末ＢはＷＥＢページを表示させるため、プロキシサーバとしての端末Ａと同期を取る。すなわち、端末Ａのポート番号１３０３はＨＴＴＰポートである８０番を使用し、端末ＢからＳＹＮパケットを送信すると（Ｓ４３０５・５３０５）、端末ＡはＳＹＮ・ＡＣＫパケットを返し（Ｓ４３０６・５３０６）、これに応じて端末ＢからＡＣＫパケットが送信される（Ｓ４３０７・５３０７）。この後、端末Ｂと端末ＡはＨＴＴＰ通信を行なうことができる。この後の端末Ｂと端末Ａとの間のＴＣＰパケットのやりとりでは、端末ＢはＴＣＰデータ部５００４にＨＴＴＰコマンドを記述し、端末ＡはＴＣＰデータ部５００４にそれに対する応答を記述することになる。
【０１９０】
端末Ｂは端末ＡにＨＴＴＰでＷＥＢデータの要求を行なう（Ｓ４３０８・５３０８）。このＴＣＰパケット５３０８により端末Ｂから端末ＡにＵＲＬ情報が伝達される。
【０１９１】
プロキシサーバとして機能する端末Ａは、端末Ｂに変わってＷＥＢサーバ１１３にＷＥＢページのデータを要求する。端末Ａは端末Ｂとの通信で使っているポートとは異なるポート１３０２を用意しＷＥＢサーバと同期を取る。すなわち、端末ＡからＳＹＮパケットを送信（Ｓ４３０９・５３０９）すると、ＷＥＢサーバ１１３はＳＹＮ・ＡＣＫパケットを返し（Ｓ４３１０・５３１０）、端末ＡはＡＣＫパケットを返す（Ｓ４３１１・５３１１）。この後、端末ＡとＷＥＢサーバ１１３はＨＴＴＰ通信を行なうことができる。上記同様に、ＷＥＢサーバ１１３端末Ａとの間のＴＣＰパケットのやりとりでは、端末ＡはＴＣＰデータ部５００４にＨＴＴＰコマンドを記述し、ＷＥＢサーバはＴＣＰデータ部５００４にそれに対する応答を記述する。
【０１９２】
その後、端末ＡはＷＥＢサーバにＨＴＴＰでＷＥＢデータの要求を行い（Ｓ４３１２・５３１２）、目的のＷＥＢデータを受信する（Ｓ４３１３・５３１３）。端末Ａはこれに対してＡＣＫを返す（Ｓ４３１４・５３１４）。端末ＡはＷＥＢデータをメモリに記憶するとともに、端末ＢにＷＥＢデータ要求の応答として転送する（Ｓ４３１５・５３１５）。端末Ｂはこれに対してＡＣＫを返す（Ｓ４３１６・５３１６）。
【０１９３】
端末ＡはＷＥＢサーバから受信したＷＥＢページを表示し（Ｓ４３１７）、端末Ｂは端末Ａから受けたＷＥＢページを表示する（Ｓ４３１８）。
【０１９４】
以上のようにして、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有することができる。従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースそのものの情報が伝達され、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１９５】
なお、実施形態１で述べた種々の変形例は、実施形態１とのＵＲＬデータの転送方式の差異に関係するものでなければいずれも同様に本実施形態３においても通用するのはいうまでもない。
【０１９６】
本発明を実現するソフトウェアは、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう任意の形式の通信端末に適用でき、その通信端末のＣＰＵのプログラムとしてＲＯＭやその他の記憶媒体などに格納してあらかじめ格納しておく他、外部記憶媒体（ＣＤ−ＲＯＭやフレキシブルディスク、ＭＯなど）を介して供給する、あるいは、ネットワーク経由で供給することができる。特に、ネットワーク経由で供給する場合には、前述のようにインターネットリソースとしてＦＴＰサーバやＨＴＴＰサーバに通信端末のファームウエア（あるいは付加的なソフトウェア）として配置し、本発明の通信方法を介して通信端末にダウンロードし、さらにＳＯＡＰ手順などを介してその通信端末にインストールすることができる。
【０１９７】
【発明の効果】
以上の説明から明らかなように、本発明によれば、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、およびその制御プログラムにおいて、通話中の相手通信端末と、目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するためのインターネットリソース共有手段ないし制御過程を含み、ＵＲＬ情報を受信した場合はそのＵＲＬ情報が示すインターネットリソースに自動的にアクセスする構成を採用しているので、従来の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソース（ないしその所在情報）を伝達でき、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるという優れた効果がある。すなわち、本発明によれば、他の機器を用いることなく通話端末のみによりＩＰ電話で通話中の相手とインターネットリソースを簡単安価に、また面倒な操作を必要とせず確実に共有できる、という優れた効果が得られる。
【図面の簡単な説明】
【図１】本発明を採用した通信端末の構成を示した説明図である。
【図２】図１の装置の制御系の構成を示したブロック図である。
【図３】図１の装置が通信するＩＰ網により構成された通信環境を示した説明図である。
【図４】図１の装置が通信する通信環境の異なる構成を示した説明図である。
【図５】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図６】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図７】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図８】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図９】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図１０】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１１】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１２】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１３】図１の装置による異なるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１４】図１の装置によるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１５】図１の装置によるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１６】図１の装置が通信する通信環境の異なる構成（実施形態２）を示した説明図である。
【図１７】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図１８】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図１９】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２０】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２１】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２２】図１の装置によるＩＰ電話通信の通信制御手順（実施形態２）を示したフローチャート図である。
【図２３】図１の装置によるＩＰ電話通信の通信制御手順（実施形態２）を示したフローチャート図である。
【図２４】図１の装置によるＩＰ電話通信の通信制御手順（実施形態３）を示したフローチャート図である。
【図２５】図１の装置によるＩＰ電話通信の通信制御手順（実施形態３）を示したフローチャート図である。
【図２６】図１の装置によるＩＰ電話通信の様子（実施形態３）を示した説明図である。
【図２７】図１の装置によるＩＰ電話通信の様子（実施形態３）を示した説明図である。
【図２８】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図２９】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図３０】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図３１】実施形態１で用いられるＳＯＡＰメッセージの構成を示した説明図である。
【符号の説明】
１００ ＩＰ網
１０１ 有線回線
１０２ スプリッタ
１０４ 公衆回線
１１０ ＳＩＰサーバ
１１１ ロケーションサーバ
１１２ ＤＮＳサーバ
１１３ ＷＥＢサーバ
１１４ メールサーバ
１１５ ＰＯＰサーバ
２００ 通信端末
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 通信制御部
２０５ ＭＯＤＥＭ部
２０６ 音源部
２０７ 音声処理部
２０８ ハンドセット
２０９ スピーカ
２１０ 本体マイク
２１１ 記録部
２１２ 読取部
２１４ 表示部
２１５ 操作部
２１６ フック検出部
２１９ データバス
２３０ ＡＤＳＬモデム部
２３１ ＡＦＥ部
２３２ ＢＢ−通信部
２３３ ＲＯＭ
２３４ ＲＡＭ
２４０ ネットワーク制御部
２４１ ドライバ部
５００１ ＩＰヘッダ部
５００２ ＩＰデータ部
５００３ ＴＣＰヘッダ部
５００４ ＴＣＰデータ部
５００５ 送信元ポート番号
５００６ 送信先ポート番号
５００７ コントロールフラグ
５００８、５００９ ＩＰアドレス
【発明の属する技術分野】
本発明は、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、その制御プログラムに関するものである。
【０００２】
【従来の技術】
近年、インターネットの普及が世界的に急速に拡大しており、通信料金の著しい低減を図ることができる利点から、インターネット電話（以下ＩＰ電話）が注目を浴びている。インターネット電話で特に現在有力な規格はＶｏＩＰ（下記の非特許文献１：ＩＴＵ−Ｔ勧告Ｈ．３２３など）であり、このような規格によるインターネット電話対応の機器が様々な形で提案されている。
【０００３】
ＩＰ電話の１つの利用形態として、インターネットサービスプロバイダを経由して、常時接続する状態でＬＡＮを経由して相互に直接接続する形態が考えられる。ＩＰ電話では、通信しようとするユーザが相互にＩＰ接続する必要があるため、インターネット上にランデブーサーバが用意される。ランデブーサーバに電話番号と最寄のインターネットサービスプロバイダとの対応テーブルを設け、着呼側ユーザに公衆回線経由で通話要求と発呼側ユーザのＩＰアドレスとを通知し、双方のユーザがランデブーサーバを介して同時接続することにより、通話を実現する。このランデブーサーバを用いる規格の１つとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｅ Ｐｒｏｔｏｃｏｌ：下記の非特許文献２：ＲＦＣ２５４３）が知られている。
【０００４】
【非特許文献１】
ＩＴＵ−Ｔ勧告 Ｈ．３２３
【非特許文献２】
ＲＦＣ２５４３（http://www.faqs.org/rfcs/rfc2543.html）
【０００５】
【発明が解決しようとする課題】
ところが、従来のＩＰ電話の技術は、ＩＰコネクションの上で音声通信を行なうだけのものが多い。
【０００６】
たとえば、ＩＰ電話で通話中の場合、相互のＩＰアドレスが判明しているにもかかわらず、ユーザはこのＩＰアドレスを用いて利用できるインターネットリソースに全くアクセスすることができず、ユーザに充分なサービスを提供しているとはいえない。
【０００７】
たとえば、従来では、あるＷＥＢページやＦＴＰサーバ、その他のインターネットリソースの所在を通話相手に伝えたくても、ＩＰ電話の通話上の音声で伝え合うしか方法がない。インターネットリソースのアドレスは通常ＵＲＬ、ＵＲＩのような形式で表現されるが、多くの場合これらの文字数は電話番号ほどには短かくなく、誤りなくこのような形式のデータを音声で伝達するのは困難であり、また非常にわずらわしい。
【０００８】
さらに、現在では、ＷＥＢブラウザなどインターネットリソースを利用する機構を有する電話機が存在しているが、ユーザはこのような端末を用いていたとしても、一旦上記のようにして音声で伝達したインターネットリソースのアドレスをＷＥＢブラウザなどに再度入力しなければならない。
【０００９】
また、ユーザの端末がＩＰ電話と、ＷＥＢページ閲覧のようなインターネットリソースの利用を異なる接続方式でしかサポートしていない場合もあり、そのような場合はユーザはＩＰ電話を切断してから再度ＩＰ接続を行なわなければならない。どうしても通話とインターネットリソースの利用を両立させたければ、ＩＰ電話用の端末の他にさらにＰＣなどの別の機器を用い、別の呼接続の上でインターネットリソースを利用しなければならない。
【００１０】
本発明の課題は、上記の問題を解決し、他の機器を用いることなく通話端末のみによりＩＰ電話で通話中の相手とインターネットリソースを簡単安価に、また面倒な操作を必要とせず確実に共有できるようにすることにある。
【００１１】
【課題を解決するための手段】
上記の課題を解決するため、本発明によれば、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、およびその制御プログラムにおいて、通話中の相手通信端末と、同一のインターネットリソースを共有利用するためのインターネットリソース共有手段ないし制御過程を含む構成を採用した。
【００１２】
相手通信端末との同一のインターネットリソースの共有利用は、通話中の相手通信端末と目的のインターネットリソースのＵＲＬ情報を送受信することにより行なうことができる。
【００１３】
特に、前記ＵＲＬ情報は前記ＵＲＬ情報を受信した後の利用処理に関する利用制御情報を含む特定の形式で記述でき、前記ＵＲＬ情報を受信した場合、前記利用制御情報にしたがって前記ＵＲＬ情報に対応するインターネットリソースを利用（表示、インストールなど任意の処理）することができる。
【００１４】
また、前記ＵＲＬ情報の伝送は自機または相手通信端末の一方が他方にＦＴＰログインし、前記ＵＲＬ情報をＦＴＰ手順を用いて相手通信端末と送受信することにより行なうことができる。
【００１５】
また、相手通信端末に対してＦＴＰログインする際には、その認証情報としてメモリのアドレス帳領域に記憶された相手通信端末に関する情報を用いることができる。
【００１６】
また、前記ＵＲＬ情報の伝送は、前記ＵＲＬ情報を電子メールプロトコルを用いて相手通信端末と送受信することにより行なうことができる。
【００１７】
また、前記ＵＲＬ情報を記述した電子メールを受信するため、ＩＰ電話による通話中は、ＰＯＰサーバから電子メールを受信する電子メール時間間隔を通常よりも短縮することができる。
【００１８】
また、前記電子メール時間間隔の短縮は、前記ＵＲＬ情報を記述した最初の電子メールを受信した後から行なうことができる。
【００１９】
また、ＵＲＬ情報を伝送するだけではなく、自機または相手通信端末の一方がＨＴＴＰプロキシサーバとして、他方がＨＴＴＰクライアントとして動作し、相手通信端末との間でＨＴＴＰプロキシ手順を用いて目的のインターネットリソース自体を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用することもできる。
【００２０】
前記インターネットリソースは、ＨＴＴＰサーバにより提供されるＷＥＢデータやＦＴＰファイル、ＦＴＰディレクトリ情報、その他、ＩＰを介して利用可能な任意のデータであってよく、上記インターネットリソース共有のために必要な相手通信端末のＩＰアドレスは、ＩＰ電話の接続の時に取得したものを用いればよい。
【００２１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
【００２２】
なお、本明細書（特許請求の範囲も含む）では、用語として「インターネット」および「インターネットリソース」を用いるが、前者はＩＰ網を、後者はＩＰ網上でＩＰを介してアクセス可能なデータ（ファイルやディレクトリリストなどを含む）その他の資源を指す。すなわち、本明細書において用語「インターネット」は、単にＩＰ網と同義であり、広域的かつ公共的に利用されるいわゆる”Ｉｎｔｅｒｎｅｔ”の他、企業その他の組織内で閉じたいわゆるイントラネットのようなＩＰ網も含み、用語「インターネットリソース」はこれらのネットワーク上でＩＰを介してアクセス可能なデータを指すものとする。これは「ＩＰ網リソース」のような適当な上位概念の用語が現在のところ一般的ではないための止むを得ない措置である。
【００２３】
図１は本発明を採用したＩＰ電話機能およびＷＥＢブラウザ機能を有する通信端末の構成を示している。図１において、符号１００は、通信端末２００が接続されるＩＰ網（いわゆるインターネットの他に、イントラネットのように閉じた網も考えられるが、以下では特に区別する必要がある場合を除きインターネット網という）で、有線回線１０１を介して接続される。本実施形態では、有線回線１０１としてはＡＤＳＬであるものとし、図１の通信端末の回線はスプリッタ１０２によりＰＳＴＮ網用の帯域１０４と、ＡＤＳＬ網用の帯域１０３が分割され、通信端末２００は、ＰＳＴＮ接続による音声通信（たとえば通話およびファクシミリ）が可能であるとともに、インターネット接続（ＰＰＰｏＥなどのＡＤＳＬ接続方式が用いられる）、およびインターネット上の資源の利用（本実施形態の場合、少なくともＩＰ電話の他にＷＥＢページ閲覧、Ｅメール送受信など）が可能である。
【００２４】
なお、ＩＰ網１００への接続は、ＡＤＳＬである必要はなく光ファイバー回線や、ＣＡＴＶ回線、無線回線など任意の回線メディアを用いることができる。
【００２５】
図１の通信端末２００は液晶表示器などを用いた表示部２１４およびテンキーや各種ファンクションキーを含む操作部２１５、および音声通話用入出力のためのハンドセット２０８を有する。表示部２１４および操作部２１５は通話制御のために用いられる他、ＷＥＢブラウザ機能を実現するためにも用いられる。
【００２６】
本実施形態では、特に操作部２１５にリソース転送ボタン２１５ａおよびリロードボタン２１５ｂが設けられている。リソース転送ボタン２１５ａは、本端末どうしでＩＰ電話中にインターネットリソースを共有利用する場合に押下する。リロードボタン２１５ｂは、メールの強制受信操作（あるいはＷＥＢページのリロード操作など）に用いられる。
【００２７】
図２に図１の通信端末２００の制御系の構成を示す。図示の制御系は、通信端末２００でＩＰ電話機能および、ＷＥＢブラウザ機能の他、ファクシミリ機能（図１では不図示）を実現するものである。
【００２８】
図２においてＣＰＵ２０１は、データバス２１９を介して各部との信号の入力を行い、この入力した信号に応じてデータバス２１９に接続された各構成要素を制御する。すなわち、ＣＰＵ２０１はＲＯＭ２０２に格納されたプログラムにしたがって全体を制御し、網への接続や、各種プロトコルを制御し処理を実行する。もちろん操作、表示、読み取り、記録に使用する制御も含まれる。
【００２９】
さらに、ブロードバンド接続をつかさどる制御や、ＩＰ電話を実現するための制御、ＷＥＢアクセスを行なうための制御、ＷＥＢページを表示するためのブラウザ制御、また、ＩＰアドレスの検知、抽出制御、そして、ＵＲＬ等のデータを送信するためのファイル作成や、送受信制御を実行する。
【００３０】
また、ＲＯＭ２０２は、プログラムを格納したメモリであり、マスクＲＯＭやフラッシュＲＯＭなどで構成される。また、データの書込み、消去が必要なデータ用にフラッシュＲＯＭや、ＥＥＰＲＯＭも構成されることも考えられる。ＲＯＭ２０２には、ＣＰＵ２０１で行なう制御全般のプログラムが格納されている。
【００３１】
ＲＡＭ２０３はＣＰＵ２０１が処理を行なう場合のワークエリアとして、呼処理を含むＷＥＢ閲覧やＥメール送受信の各処理を実行するにあたって使用したり、読取、記録時、または音声ＣＯＤＥＣデータを処理するエリアでもある。ここは、ＲＯＭ２０２と異なり、一時的なデータが記憶される。
【００３２】
さらに、ＲＡＭ２０３は電池等でバックアップされる部分もあり、時間データ等、各種サービス機能の設定内容やアドレス帳（あるいは電話帳）に登録した内容を記憶する。図２ではこのような領域のうち、特にアドレス帳２０３ａの領域を図示してある。
【００３３】
このアドレス帳２０３ａには、通常回線の通話の際の番号通知などで得た電話番号、ＩＰ電話通信の際に得たＩＰアドレス、さらに、これらの選択情報に対応するユーザ名やメールアドレスの他、自機のユーザのユーザ名およびメールアドレスなどを所定の設定操作に基づき記憶させておく。
【００３４】
また、このアドレス帳に類した管理情報の記憶領域は、不揮発性のメモリとしてのＥＥＰＲＯＭ等で構成することもできる。
【００３５】
また、ＲＡＭ２０３は、ＩＰ電話接続手順にて検出したＩＰアドレスの一時保管や、ファイル送受信を行なうためのバッファや、ＷＥＢページ表示のための受信バッファとしても利用する。
【００３６】
通信制御部２０４は、アナログ（ＰＳＴＮ）公衆回線１０４を収容するためのインタフェイスであり、アナログ回線の場合、局交換機の電話回線（以後、加入者線と称す）に接続され、ダイオードによる全波整流回路により構成され、回線電圧の極性を一致させるための極性一致回路、回路局交換機の加入者線に接続され、局交換機からの呼出信号を検出するリンガー検出回路、オフフック操作が行われると回線ループを形成するとともに、局に対してダイヤルパルスを送出するパルス送出回路、２線−４線変換を行なうためのトランス回路で構成されている。また、外部に接続されるアナログ端末用のインターフェイス２５０も設け通常のアナログ端末も接続できるように構成されている。
【００３７】
２０５はＭＯＤＥＭ部であり、ＤＳＰとＡＦＥ（アナログフロントエンド）で構成され、機能的には、Ｇ３ＦＡＸによるファクシミリの送受信を行なうファクシミリモデムの機能を、ＣＰＵ２０１の制御により実現する。さらにモデムデータ（ナンバーディスプレイデータ）の解析を行なうナンバディスプレイ機能と、エコーキャンセラ機能を有し、スピーカフォン機能をも実現することができる。
【００３８】
音源部２０６は、保留音や着信メロディーの音源であり内部に音源データ生成機能をもち、ＲＯＭ２０２や、ＲＡＭ２０３に記憶してあるデータに基づきＣＰＵ２０１の制御により音源部２０６でアナログ信号として再生することができる。また擬似ＤＴ、ＢＴ、ＲＢＴ等のコールプログレストーンを出力するための音源も兼ねる。
【００３９】
符号２０７は音声処理部で、ＣＰＵ２０１の制御によりＭＯＤＥＭ部２０５からの信号や音源部２０６、後述するハンドセット２０８、スピーカ２０９、本体マイク２１０、通信制御部２０４等の入出力信号をこの音声処理部２０７の音声パス制御により処理する。
【００４０】
ハンドセット２０８（図１）は通常回線上の通話およびＩＰ電話における音声の入出力に用いられる。ハンドセット２０８のフックのＯＮ／ＯＦＦはフック検出部２１６により検出され、このフックの状態に応じて回線のＯＮ／ＯＦＦが制御される。
【００４１】
スピーカ２０９は着信音や記憶した音声データの出力およびスピーカフォン通話時のモニタに用いられる。本体マイク２１０はスピーカホン機能を実現する際の音声入力に使用する。
【００４２】
記録部２１１は、感熱型、熱転写型プリンタ、あるいはレーザービームプリンタ、インクジェットプリンタ等の周知の記録手段から構成され、ファクシミリ記録の場合ＭＨ、ＭＲ、ＭＭＲ符号化されたデジタルデータを復号化し、この復号化したデータを記録する。また、ＷＥＢブラウザからデータをプリントする場合は、ＲＡＭ２０３を受信バッファとして使用し、そこに格納されているマークアップ言語（通常ＨＴＭＬ）で記述されたウェブ１ページ分のデータを表示用データに変換し、表示部２１４の一画面に表示可能な量のデータをＲＡＭ２０３内の表示バッファに格納する。ＷＥＢブラウザは表示バッファへの格納を終了すると記録部２１１へ記録開始通知を行なう。
【００４３】
記録部２１１は格納終了通知を受けると表示バッファからデータを読み出し、１ラインごとにプリント用データに変換して記録部２１１へ転送する。転送が終わると転送終了通知をブラウザに通知する。転送終了通知を受けたブラウザは次の表示用データがあれば表示バッファに格納して記録部２１１に通知し、ウェブページ分のデータが終わり、次の表示用データがない時にはページ終了を通知する。以上の処理を繰り返して１ページ分のデータを記録部２１１に転送し、ウェブプリントを行なう。
【００４４】
読取部２１２はＣＣＤあるいは密着型センサアレイ等の周知の原稿読取手段を備えており、読取手段で読み取ったアナログデータをデジタルデータに変換するとともに、この変換されたデジタルデータをファクシミリ通信においては、ＭＨ、ＭＲ、ＭＭＲ符号化等の周知の符号化方法により符号化し出力する。
【００４５】
符号２１３はセンサ部であり、読取部２１２上の送信原稿の有無やサイズを検出しその結果をＣＰＵ２０１に通知する。また、記録部２１１上の記録紙の有無やサイズを検出しその結果をＣＰＵ２０１に通知する。
【００４６】
表示部２１４（図１）は、カラーＬＣＤや、モノクロＬＣＤ等の液晶部品などにより構成され、種々の情報表示を行なうために用いられる。表示部２１４の表示処理にはインターネット上のサーバより受信したＨＴＭＬの情報の表示、時刻の表示や通信中の回線状態およびエラー等の状態の表示、その他動作状態のモニタ表示、操作部２１５でキー入力された文字メッセージや受信した文字メッセージの表示、電話機の各種サービス機能の設定内容などの表示などが含まれる。
【００４７】
操作部２１５（図１）はキーボード（あるいはさらにマウスなどのポインティングデバイス）などから成り、表示部２１４とともにユーザーインターフェースを構成する。ＷＥＢブラウズ操作、プリント、発呼／着呼／登録などに関するあらゆるユーザ操作を受け付け、その内容を制御部２０１に通知する。
【００４８】
操作部２１５のキーには、前述のリソース転送ボタン２１５ａの他、公知のキーとして次のようなものが含まれる。すなわち、ダイヤル番号やＵＲＬ等を０−９および＊、＃および前記キーを利用しアルファベットや記号等を入力するためのダイヤルキー、ファクシミリの送受信を制御する送信、受信キー、回線のＯＮ／ＯＦＦを制御するオフフックキー、その他には保留キー、機能設定を行なうためのセレクトキー等のキーなどである。
【００４９】
ネットワーク制御部２４０は、インターネット通信にかかわる各種プロトコルを制御する。ネットワーク制御部２４０は便宜上回路ブロックとして示してあるが、実際にはその基本制御はＣＰＵ２０１のソフトウェアにより行なわれる。
【００５０】
ネットワーク制御部２４０は、ＭＩＩインタフェイスを用いたドライバ部２４１（通常ＰＨＹと呼ばれる）を介してＮＩＣ（ネットワークインターフェースカード）２４２（図示のように複数設けることも可）の入出力を制御するとともに、ＡＤＳＬモデム部２３０の入出力を制御する。
【００５１】
ＮＩＣ２４２はＣＳＭＡ／ＣＤ（イーサネット：商標名）などのインターフェース方式（あるいは他の）に基づくものを用いることができる。ＡＤＳＬモデム部２３０は上記のＡＤＳＬによる通信に用いられる。ＮＩＣ２４２はＬＡＮに接続された他の機器と通信するために用いられるが、後述の制御には必ずしも必須ではない。
【００５２】
ネットワーク通信において、ネットワーク制御部２４０を中心とした図２の回路ブロック間の入出力は次のように行なわれる。
【００５３】
ＩＰ電話の通信はたとえばＩＴＵ−Ｔ勧告Ｈ．３２３に記載されるＶｏＩＰにより行なう。ＶｏＩＰでは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎ）、ＲＳＶＰ（Ｒｅｓｏｕｓｅ ＲｅｓｅｒｖａｔｉｏｎＰｒｏｔｏｃｏｌ）などの各種プロトコルが利用される。
【００５４】
ＩＰ電話の場合、ハンドセット２０８から入力される音声信号は、音声処理部２０７を介して処理され、ＣＯＤＥＣ部２４３により、音声処理のためのコーデック処理を実行し、ＩＴＵ−Ｔ勧告Ｇ．７１１やＧ．７２９等の符号フォーマットに基づく符号化／復号化を介して音声信号がデジタルデータとして送受信される。また、通話相手のＩＰアドレスを特定するためには、ＳＩＰ、ＩＴＵ−Ｔ勧告Ｈ．３２３、あるいはＭＣＧＰ等のプロトコルが利用される。
【００５５】
本実施形態では、インターネットと通信し、またＮＩＣ２４２を介してＬＡＮとも通信する、つまり異なるネットワークセグメント間でパケットをフォワードする。したがって、ネットワーク制御部２４０には、異なるネットワークセグメント間でパケットを転送するルータ機能、およびアドレス／ポート番号の変換を行なうＮＡＴ機能が設けられていることが望ましい。
【００５６】
ＮＡＴ機能は、プライベートＩＰアドレスと、Ｉｎｔｅｒｎｅｔアクセスに利用できる本来のグローバルＩＰアドレスを相互に変換し、ローカルなＩＰアドレスしか割り当てられていないノードから、透過的にＩｎｔｅｒｎｅｔをアクセスできるようにするものである。
【００５７】
また、ＬＡＮに接続される機器のため、起動時に動的にＩＰアドレスを割り当て、終了時にＩＰアドレスを回収するため、ＤＨＣＰも設けられる。
【００５８】
ＡＤＳＬモデム部２３０がＡＤＳＬ網と接続する際には、ＰＰＰｏＥなどのプロトコルが用いられる。ＡＤＳＬ網と接続する際の認証ではＰＡＰ／ＣＨＡＰなどのプロトコルが用いられるので、ネットワーク制御部２４０には、これらの認証プロトコルも実装しておく必要がある。
【００５９】
ネットワーク制御部２４０とＡＤＳＬモデム部２３０はＵＴＯＰＩＡなどのインターフェースを介して接続される。
【００６０】
ＡＤＳＬモデム部２３０は、インターネット接続に使用するための通信制御部で、ここに、スプリッタで分離した公衆回線を接続する。そして、ＡＤＳＬモデム部２３０は、ＡＦＥ部２３１とＢＢ−通信部２３２で構成される。ＡＤＳＬモデム部２３０にはＡＤＳＬモデムのプログラム格納用のＲＯＭ２３３とデータワークエリアのＲＡＭ２３４が接続されている。
【００６１】
図３はＩＰネットワークの構成を概念的に示している。図３に示すように本実施形態の通信端末２００は、公衆回線１０１によってＩＰ網１００に接続され、相手の通信端末２２０と通信する。
【００６２】
図３は、通信端末（Ａ）２００と通信端末（Ｂ）２２０が同一のインターネットサービスプロバイダ（ＩＳＰ）に接続された状態を想定している。
【００６３】
ＩＰ網１００上には、ＩＰ電話での呼接続に用いられるＳＩＰサーバ１１０、電話番号／ＩＰアドレスの対応テーブルを管理するロケーションサーバ１１１、ＩＰアドレスとドメイン／ホスト名の対応テーブルを管理するためのＤＮＳサーバ１１２、ＷＥＢサーバ１１３が設けられている。
【００６４】
また、図４は図３と同等の構成であるが、ＩＰ網１００が異なるインターネットサービスプロバイダ（ＩＳＰ：１５１、１５３）を介して接続されている状態を示している。インターネット接続の形態としては、通信相手によっては図３、図４いずれの接続形態もあり得る。図４では、ＩＳＰ（Ａ）１５１を介して通信端末（Ａ）２００が接続され、ＩＳＰ（Ｂ）１５３を介して通信端末（Ｂ）２２０が接続されている。
【００６５】
図４の場合は、異なるサービスプロバイダを結ぶためのＩＳＰ−ＧＷ１５２が異なるＩＳＰ間のゲートウエイ的役目を行なうことにより、通信端末２００、２２０間の通信が可能となる。なお、ＩＳＰ−ＧＷ１５２は必ずしも単一の機器により構成されるものではなく、複数のゲートウェイ機器により構成されている場合もある。
【００６６】
本実施形態のＩＰ電話通信では、ＳＩＰ方式を用いる。ここで発呼側が通信端末２００、着呼側が通信端末２２０であるものとすると、ＳＩＰでは、まず発呼側の通信端末２００がＳＩＰサーバ１１０に発呼メッセージを送り、相手端末２２０との接続を要求する。ＳＩＰサーバ１１０は、ロケーションサーバ１１１に相手端末２２０のＩＰアドレスを問い合わせ、判明したＩＰアドレスを用いて通信端末２００と２２０の間のＩＰコネクションが形成される。
【００６７】
次に上記構成において、ＩＰ電話により通話中の通信端末間で、インターネットリソースを共有するための通信制御につき、異なる実施形態を説明する。
【００６８】
＜実施形態１＞
図５〜図９は本実施形態１のＩＰ電話通信のシーケンスを示している。図５〜図９のＩＰ電話通信では、図１および図２のように構成された通信端末Ａから通信端末Ｂへ呼接続し、通話を行なう。また、本実施形態では、端末ＡでＷＥＢブラウジングを行なうとともに、ＩＰ電話通信中に通信端末Ａから通信端末ＢにそのＵＲＬデータを転送し、通信端末（以下単に「端末」とも記す）ＡおよびＢとの間で同一のＷＥＢ情報を共有できるようにする。
【００６９】
なお、図５〜図９のＳＩＰサーバ１１０、ロケーションサーバ１１１、ＤＮＳサーバ１１２、およびＷＥＢサーバ１１３は、図３または図４に示したものと同じである。
【００７０】
図５〜図９の通信シーケンスは、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはたとえばＲＯＭ２０２に格納される（後述の他の実施形態においても同様）。図５〜図９の通信シーケンスの各ステップは符号Ｓ５０１以降により示されている。なお、図５〜図９の通信では、既にＡＤＳＬコネクションが成立し、端末ＡおよびＢがＩＰ網と接続されているものとする。
【００７１】
まず、端末Ａにおいて、ユーザが操作部２１５でダイヤル操作を行なう（図５のＳ５０１）。これにより、ＩＮＶＩＴＥメッセージにより、ＳＩＰサーバ１１０に接続される（Ｓ５０２）。
【００７２】
ＳＩＰサーバ１１０はロケーションサーバ１１１に対してＩＰアドレスを要求し（Ｓ５０３）、ロケーションサーバ１１１は指定された電話番号に対応したＩＰアドレスを検索し、ＳＩＰサーバ１１０に得られたＩＰアドレスを送信する（Ｓ５０４）。
【００７３】
ここで、ＳＩＰサーバは、受信した相手端末ＩＰアドレスを元に、ＩＮＶＩＴＥ要求を端末Ｂへ送出し、接続要求する（Ｓ５０６）。この時、端末Ｂが発信側端末ＡのＩＰアドレスを入手することになる。
【００７４】
端末Ｂは、ＳＩＰサーバからのＩＮＶＩＴＥ要求により着信動作に入る（Ｓ５０７）。そして、呼出中を示すＲｉｎｇｉｎｇをＳＩＰサーバに返し（Ｓ５０８）、ＳＩＰサーバは端末Ａに対してＲｉｎｇｉｎｇ信号を送信する（Ｓ５０９）。
【００７５】
端末Ｂが応答すると（Ｓ５１０）、接続完了を示すＯＫ情報がＳＩＰサーバ１１０に送信され（Ｓ５１１）、ＳＩＰサーバ１１０は、端末Ａに向けてＯＫ情報を送信し、端末Ａも相手端末ＢのＩＰアドレスを入手する（Ｓ５１２）。
【００７６】
その後、端末Ａ〜端末Ｂ間に生成されたＩＰコネクションを用いて音声パケットの送受信が可能となり（Ｓ５１３）、端末Ａおよび端末Ｂは通話状態となる（Ｓ５１４）。
【００７７】
通常、ＶｏＩＰによる通信は、リアルタイム性を重視し、メッセージを含めてＵＤＰベースで行なわれるが、ＴＣＰベースの接続を選択することもできる。
【００７８】
端末Ａは、ＩＰ網と接続されているため、ＷＥＢページやメール送受信など、インターネット上の資源を利用することができる。
【００７９】
端末Ａ、Ｂ間の通話の進行に応じ、両者の間で特定のＷＥＢページのようなインターネットリソースが話題にのぼることは充分考えられる。前述のように従来では、ＷＥＢページのＵＲＬはＩＰ電話中は音声でやりとりしていたが、本実施形態では端末ＡからＢにあるＷＥＢページのＵＲＬを伝送し、端末Ｂで閲覧できるようにする例を示す。
【００８０】
端末Ａで、ＷＥＢブラウザを起動し（Ｓ５１５）、操作部２１５からＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせる（Ｓ５１６）。問合せを受けたＤＮＳサーバ１１２は、ＵＲＬからＷＥＢサーバ１１３のアドレスを検索し（Ｓ５１７）、検索結果を端末Ａに返す（Ｓ５１８）。
【００８１】
端末ＡはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスする。端末ＡからＳＹＮパケットを出し（Ｓ５１９）、ＷＥＢサーバ１１３からＳＹＮ・ＡＣＫパケットを受信し（Ｓ５２０）、相手のＳＹＮに対してＡＣＫパケットを送信する（Ｓ５２１）。
【００８２】
このようにして同期が取れると、端末ＡはＷＥＢサーバ１１３にＷＥＢページのリクエストを行い（図６のＳ５２２）、ＷＥＢサーバ１１３からＷＥＢページのデータを得る（Ｓ５２３）。ＷＥＢページのデータを受信した端末ＡはブラウザにＷＥＢページを表示させる（Ｓ５２４）。
【００８３】
端末Ａは表示させたＷＥＢページを通話相手の端末Ｂにも表示させるため、ＵＲＬの転送を行なう。このＷＥＢページの内容を端末Ｂのユーザにも見てもらいたい場合には、端末Ａのユーザは操作部２１５のリソース転送ボタン２１５ａを押下する。
【００８４】
リソース共有利用を起動する操作として、上記のリソース転送ボタン２１５ａの操作の他、たとえば、表示部２１４のツールバーや、ＷＥＢブラウザのウィンドウの１つとして用意したコンソール上の「ＵＲＬ転送」など適当な名前のボタンの操作（ポインティングデバイスなどによる操作も含む）などが考えられ、これらの所定操作のいずれか、あるいはいずれも許容するような仕様も考えられる。
【００８５】
本実施形態では、端末Ａから端末ＢにＵＲＬ情報をＦＴＰ（ファイル転送プロトコル）で転送するため、ＵＲＬを記述したファイルを作成する（Ｓ５２５）。このＵＲＬを含むファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ：ＲＦＣ３２８８）で記述する。
【００８６】
ＦＴＰでは、制御用のコネクションと、データ（ファイル）転送用の２つのコネクションを用いる。
【００８７】
まず、端末Ａはロケーションサーバから得た端末ＢのＩＰアドレスに基き端末Ｂとの間で制御用ポートの同期を取る。端末ＡからＳＹＮパケットを送信し（Ｓ５２６）、端末ＢからＳＹＮ・ＡＣＫパケットを受信し（Ｓ５２７）、相手のＳＹＮに対してＡＣＫパケットを送信する（Ｓ５２８）。端末Ｂは端末ＡにＦＴＰ通信が開始できることを示すｒｅａｄｙを送信する（Ｓ５２９）。
【００８８】
端末Ａは端末Ｂにログインをかけ（Ｓ５３０）、端末Ｂは端末Ａのログインを許可する（Ｓ５３１）。
【００８９】
このＦＴＰログインの認証方式に関しては、既にＩＰコネクションが成立しているので、ユーザ名にａｎｏｎｙｍｏｕｓ、パスワードにメールアドレスを用いるいわゆる匿名ＦＴＰ方式を用いることで多くの場合充分であると考えられる。たとえば、匿名ＦＴＰ方式であっても、さらにＩＰ電話で現在通話中の相手からのＦＴＰログインのみしか受け付けないようにすればかなりのセキュリティを確保できる。
【００９０】
しかし、認証シーケンスにおいては、さらに相互の端末に固有の情報を交換してセキュリティを向上することも考えられる。たとえば、図２の構成によれば、アドレス帳２０３ａが設けられているので、端末Ａからはメールアドレスを送信し、端末Ｂでは端末Ａから送信されたメールアドレスが自機のアドレス帳２０３ａに格納されているか否かを判定し、格納されていれば端末ＡのＦＴＰログインを許可するようにすればよい。このようなＦＴＰログインシーケンスはユーザ入力を行なうことなく自動で実行することができ、しかも、上記のようにアドレス帳の情報を用いた認証を行なうようにすれば、面倒な操作を必要とせず、不特定多数の相手のＦＴＰログインを禁止でき、セキュリティを確保することができる。
【００９１】
続いて端末Ａは制御用のポートの他にＵＲＬデータ転送用のポートを用意（Ｓ５３２）し、データ転送用のポートを使用して端末ＢにＵＲＬデータを転送する（図７のＳ５３５）。まず端末Ａは端末Ｂとの間でデータ転送用のポートの同期を取る（Ｓ５３３、Ｓ５３４）。端末ＡはＵＲＬを記述したファイルをデータ転送用のポートを介して端末Ｂに送信する（Ｓ５３６）。ファイルを受信した端末Ｂは端末Ａのデータ転送用ポートにＡＣＫを返し、端末Ａの制御用ポートに受信完了を通知する（Ｓ５３７）。
【００９２】
ＵＲＬデータの転送が完了すると、端末ＡはＵＲＬデータ転送用のポートを開放する（Ｓ５３８）。端末Ａはデータ転送用のポートから端末Ｂにポート解放要求を送信し（Ｓ５３９）、端末Ｂは端末Ａのデータ転送用ポートにＡＣＫを返す（Ｓ５４０）。これを受けて端末ＡはＵＲＬデータ転送用のポートを開放完了し、ＵＲＬデータの転送を終了する（Ｓ５４１）。端末Ａは端末ＢにＦＴＰの終了を通知し（Ｓ５４２）、端末ＢからＡＣＫを受信する（Ｓ５４３）。
【００９３】
ＳＯＡＰで記述されたファイルを受信した端末Ｂは（Ｓ５４４）、受信したＵＲＬデータのファイルを解析する（Ｓ５４５）。ここで、図３１にＳＯＡＰで記述したＵＲＬデータの一例を示す。ＳＯＡＰはＸＭＬベースの情報伝達のためのプロトコルであるＳＯＡＰであり、ＳＯＡＰメッセージではエンベロープ、ヘッダ、ボディの構文構造になっており、図３１の下線部分、つまりＳＯＡＰメッセージのボディの部分に本実施形態の特徴がある。図３１の他の部分の構文構造は従来と同じである。図３１の特徴部分（アンダーライン部）は次のようになっている。
【００９４】
<BrowsURL>http://www.canon.co.jp/ezumi.html</BrowsURL>
このデータ型<BrowsURL>は、装置がブラウザを起動し、指定されたＷＷＷサーバのアドレスを閲覧すべきことを意味している。このように、ＳＯＡＰサービスで使用する各種データ型はあらかじめ端末がダウンロード したアプレット内でパーサー定義がなされており、アプレットはＳＯＡＰメッセージを受信した際にメッセージのヘッダ部分の識別子によりメッセージがサービスの情報パケ ットであることを認識することができる。
【００９５】
このようにして、ＳＯＡＰ記述により、受信したＵＲＬデータファイルの取り扱い方法を指定できるので、端末ＢはＳＯＡＰの指示通りブラウザを起動し（図８のＳ５４６）、ブラウザに端末Ａから受信したＵＲＬを入力する。端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせる（Ｓ５４７）。問合せを受けたＤＮＳサーバ１１２は、ＵＲＬからＷＥＢサーバ１１３のアドレスを検索し（Ｓ５４８）、検索結果を端末Ｂに返す（Ｓ５４９）。
【００９６】
端末ＢはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスする。まず端末ＢはＳＹＮパケットをＷＥＢサーバ１１３に送信し（Ｓ５５０）、ＷＥＢサーバ１１３からＳＹＮ・ＡＣＫパケットを受信し（Ｓ５５１）、相手のＳＹＮ・ＡＣＫに対してＡＣＫパケットを送信する（Ｓ５５２）。同期が取れると、端末ＢはＷＥＢサーバ１１３にＷＥＢページのリクエストを行い（Ｓ５５３）、ＷＥＢサーバ１１３からＷＥＢページのデータを得る（Ｓ５５４）。ＷＥＢページのデータを受信した端末ＢはブラウザにＷＥＢページを表示させる（Ｓ５５５）。
【００９７】
ＷＥＢブラウザによる閲覧を終えた端末Ａはブラウザを終了させ（図９のＳ５５６）、ＷＥＢサーバ１１３に切断を送信し（Ｓ５５７）、ブラウザを終了する（Ｓ５５８）。端末Ｂもブラウザを閲覧し終えるとブラウザを終了させる（Ｓ５５９）。ＷＥＢサーバ１１３に切断を送信し（Ｓ５６０）、ブラウザを終了する（Ｓ５６１）。
【００９８】
通話の終了（Ｓ５６２）は、図９の場合、端末Ａ側から行なっている。ＶｏＩＰおよびＳＩＰ手順に基づき、ＳＩＰサーバ１１０を介してＢＹＥおよびＯＫメッセージの交換（Ｓ５６３、Ｓ５６４、Ｓ５６６、Ｓ５６７）が行なわれ、端末Ｂ側ではこれに基づきＲＯＴ鳴動（Ｓ５６５）、オンフック（Ｓ５６８）が行なわれ、ＩＰ電話の通話シーケンスが終了する（Ｓ５６９）。
【００９９】
なお、上述のＵＲＬデータの送信操作は、通話中に何度でも行なえる。このとき、たとえば、端末Ａでインターネットリソースが変る（たとえば表示中のＷＥＢページの再表示や、他のＷＥＢページへのジャンプ）ごとにリソース共有ボタン２１５ａを操作する方式でもよいし、また、通話が終了するまで（あるいは他の明示的な操作を行なうまで）端末Ａでインターネットリソースが変る（たとえば表示中のＷＥＢページの再表示や、他のＷＥＢページへのジャンプ）ごとに自動的に端末Ａから端末ＢにＵＲＬデータを送信するようにしてもよい。
【０１００】
上記のＩＰ電話通信の概略を図１０〜図１２にフローチャートとして示す。図１０〜図１２の手順は上記の図５〜図９の通信シーケンスに対応するもので、上記同様、図１のＣＰＵ２０１が通信制御プログラムを実行することにより実現される。このＣＰＵ２０１の通信制御プログラムはＲＯＭ２０２に格納される。図１０〜図１２の各ステップは符号Ｓ６０１以降により示されている。
【０１０１】
まず、端末ＡがＩＰ電話の発呼操作を行なう。端末Ａのダイヤル操作（図１０のＳ６０１）によりＳＩＰサーバ１１０を用いてＩＰ電話の呼接続処理が行なわれる。上述の通り、ＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、端末Ａに相手先端末の電話番号に対応するＩＰアドレスを返す（Ｓ６０２）。端末Ａは呼び出し中状態になり、相手先端末が応答するのを待つ（Ｓ６０３）。相手先端末が応答すると通話状態になる（Ｓ６０４）。
【０１０２】
端末ＡはＷＥＢページを表示させるためにブラウザを起動する（Ｓ６０５）。端末ＡのブラウザにＵＲＬを入力すると、端末ＡはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ６０６）。端末ＡはＤＮＳサーバ１１２から得たＩＰアドレスに基づきＷＥＢサーバ１１３にアクセスしてＷＥＢページのデータを受信し（Ｓ６０７）、ブラウザにＷＥＢページを表示させる（Ｓ６０８）。
【０１０３】
端末Ａは表示させたＷＥＢページを相手先端末にも表示させるため、ＵＲＬの転送を行なう。端末ＡはＵＲＬをＦＴＰで転送するため、ＵＲＬを記述したファイルを作成する（Ｓ６０９）。ファイルは受信側でブラウザを立ち上げられるようにＦＴＰの上位プロトコルであるＳＯＡＰで記述する。
【０１０４】
端末Ａはロケーションサーバから得た相手先端末のＩＰアドレスを元に相手先端末との間で制御用ポートの同期を取る（Ｓ６１０）。相手先端末との同期が取れると、続いて相手先端末にログインを行なう（Ｓ６１１）。
【０１０５】
端末Ａは制御用のポートの他にＵＲＬデータ転送用のポートを用意し、相手先端末との間でデータ転送用のポートの同期を取る（図１１のＳ６１４）。端末ＡはＵＲＬを記述したファイルをデータ転送用のポートを使用して相手先端末に送信する（Ｓ６１５）。ＵＲＬデータの転送が完了すると、端末ＡはＵＲＬデータ転送用のポートを解放する（Ｓ６１６）。端末Ａは相手先端末にＦＴＰの終了を通知し転送終了処理を行なう（Ｓ６１７）。
【０１０６】
ＷＥＢブラウザによる閲覧を終えた端末Ａはブラウザを終了させる（Ｓ６１８）。相手先端末との通話が終了すると通話を切断する（図１２のＳ６２６）。
【０１０７】
一方、端末Ｂ側の処理は次のように行なわれる。
【０１０８】
端末Ｂはスタンバイ状態において、着信があるかどうか監視をしている（図１０のＳ６１２）。着信を検出すると端末Ｂは着信に応答し（Ｓ６１３）、通話状態になる（Ｓ６０４）。
【０１０９】
相手先端末から同期を要求されると、端末Ｂはそれにしたがって同期を取る（Ｓ６１０）。相手先端末から（ＦＴＰ）ログインを要求されると、（ＦＴＰ）ログインを許可しデータ転送待ち状態になる（Ｓ６１１）。端末Ｂは相手先端末との間でデータ転送用のポートの同期を取り（図１１のＳ６１４）、相手先端末のデータ転送用のポートからＵＲＬを記述したファイルを受信する（Ｓ６１５）。
【０１１０】
ＵＲＬデータの転送が完了すると、相手先端末のデータ転送用のポートを解放し（Ｓ６１６）、相手先端末からＦＴＰの終了を受信し転送終了処理を行なう（Ｓ６１７）。
【０１１１】
ファイルを受信した端末Ｂは、受信したファイルの解析を行なう（Ｓ６１９）。ファイルがＳＯＡＰで記述されていて、ＵＲＬが指定されブラウザを起動させる指示があるなら（Ｓ６２０）、ＷＥＢページを表示させるためにブラウザを起動する（Ｓ６２１）。ブラウザに相手先端末から受信したＵＲＬを入力すると、端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ６２２）。端末ＢはＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスしてＷＥＢページのデータを受信し（Ｓ６２３）、ブラウザにＷＥＢページを表示させる（Ｓ６２４）。
【０１１２】
ブラウザを閲覧し終えた端末Ｂはブラウザを終了させる（Ｓ６２５）。また、端末Ｂは相手先との通信状態を監視し（図１２のＳ６２７）、相手先に切断されたことを検出すると通話を終了する（Ｓ６２８）。
【０１１３】
以上では、発呼した端末Ａ側から端末Ｂ側にＵＲＬデータを送信する例を示したが、ＵＲＬの送信はいずれが発呼側かに関係するものではなく、当然ながら上記と同様にして端末Ｂから端末ＡにＵＲＬデータを送信し、端末Ａ側で閲覧させることができる。また、以上では、端末Ａ側から端末Ｂ側にＵＲＬデータを送信する場合、端末Ａ側が端末Ｂ側にＦＴＰログインする、つまり端末Ｂ側をＦＴＰサーバとして機能させ、端末ＡがＵＲＬデータを送信（図７のＳ５３６：この際ＳＴＯＲ、ないしＳＴＯＵなどのＦＴＰコマンドが用いられる）する例を示した。しかしながら、ＵＲＬデータ送信の際のＦＴＰのログイン方向、送受信方向（送信コマンドであるＳＴＯＲ、ないしＳＴＯＵを用いるか、受信コマンドであるＲＥＴＲを用いるか、など）は任意であり、適宜変更してよい。
【０１１４】
この一例を図１３〜図１５に示す。図１３〜図１５は、端末Ｂから端末ＡにＵＲＬデータを送信し、端末Ａ側で閲覧させる場合であるが、ただしこの場合、上記同様に端末ＡがＦＴＰサーバとしての端末Ｂにログインしているものとし、ＵＲＬデータ送信は、ＦＴＰの受信コマンドであるＲＥＴＲを用いる。
【０１１５】
図１３〜図１５では、端末ＡのＦＴＰ制御ポートおよびデータポートを符号２００により、端末ＢのＦＴＰ制御ポートおよびデータポートを符号２２０により示してある。図１３〜図１５では、図５に示したものと同様のＩＰ電話発呼シーケンスにより既に通話状態が形成されているものとする。また、既に図６に示したものと同様のＦＴＰログイン認証は終了しているものとする。
【０１１６】
図１３は端末ＢがＷＥＢページの閲覧を行なう時の様子である。すなわち、端末ＢがＷＥＢサーバ１１３から通常のＨＴＴＰプロトコル（Ｓ１１４７〜Ｓ１１５１）によりＷＥＢデータを取得し、そのページをレンダリングし、表示部２１４に表示させる（Ｓ１１５２）。その後、上述同様にしてＳＯＡＰフォーマットで記述したＵＲＬデータファイルを作成する（Ｓ１１７２）。このようにＵＲＬデータファイルは、リソース共有を行なうか否かにかかわらず、ＷＥＢページをダウンロードしたら無条件で作成してもよい。通常はＵＲＬデータファイルは１、２行の文字列に過ぎないので、このようにしてもシステムに大きな負荷はかからない。
【０１１７】
その後、端末Ａのユーザが通話の進行に応じ、端末Ｂのユーザと同一のＷＥＢページを閲覧したいと考え、転送のための所定操作（上述のリソース転送ボタン２１５ａないし他の同等操作）を操作部２１５により行なう。これにより、上記のようにして作成されたＵＲＬデータファイルが図１４に示すようにしてＦＴＰ転送される（Ｓ１１５３〜Ｓ１１６３）。この場合図示のように、ＦＴＰサーバとしての端末Ｂからファイルを取得するのでＦＴＰコマンドＲＥＴＲが用いられる（Ｓ１１５３）。
【０１１８】
その後、端末Ａで図１５に示すようにしてＵＲＬデータファイルが解析（Ｓ１１６４）される。さらに端末ＡはＳＯＡＰに基づき、ＷＥＢサーバ１１３からＷＥＢデータをダウンロード（Ｓ１１６５〜Ｓ１１６９）し、表示部２１４で表示（Ｓ１１７０）する。
【０１１９】
以上のようにして、実施形態１によれば、ＩＰ電話通信中に通信している端末どうしでインターネットリソースを共有する手段を提供することができる。実施形態１の場合、インターネットリソースはＷＥＢページ（のＵＲＬ）であり、第１の端末（Ａ）から第２の端末（Ｂ）に対してＦＴＰプロトコルによりＷＥＢページのＵＲＬを記述したデータファイル（ＵＲＬファイル）を送信することにより、第２の端末（Ｂ）でも第１の端末（Ａ）で閲覧しているものと同じＷＥＢページをブラウズすることができる。
【０１２０】
これによって、ＩＰ電話通信中に通信している端末どうしで同じインターネットリソースを利用（上記実施形態の場合表示であるが、下記のファームウエアの更新の場合のように共有するインターネットリソースの利用方法は表示に限定されるものではない）させることができ、従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースの情報が伝わり、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１２１】
また、ＵＲＬデータの受信側では、ＳＯＡＰを利用し、自動的にそのＵＲＬで示されるインターネットリソースを閲覧するブラウザを起動することができ、面倒な操作を一切必要としない。
【０１２２】
以上では、ＩＰ電話通信中の第１および第２の端末で共有するインターネットリソースとしてＷＥＢページを考えたが、ＵＲＬ（あるいはＵＲＩ）ないしこれと同等のインターネットリソースの所在を示す情報形式（ＦＴＰで送信できさえすればよい）で表現できるインターネットリソースであればどのようなものでも第１および第２の端末で共有することができる。ＵＲＬ形式だけで考えてみても、本発明により共有できるインターネットリソースは、ＦＴＰディレクトリやそのディレクトリ中のファイル、Ｇｏｐｈｅｒページ、音声やビデオ（静止画／動画）ストリームを提供する各種のサービスなど、数限りない。
【０１２３】
本発明のインターネットリソース共有技術は、ビジネスや娯楽のための情報共有に広く用いることができる。特に本発明の通信端末の製品展開などに有用と考えられるのは、本発明の通信端末のファームウエアのアップデートなどに利用することである。たとえば、本発明の通信端末のユーザがトラブルに遭遇し、ＩＰ電話でメーカーのサポート窓口に電話し、相談した結果、通信端末のファームウエアの更新が必要、という結論に達した場合、メーカーのサポート要員が直接そのユーザの通信端末にファームウエア（たとえばＨＴＴＰやＦＴＰで取得可能なファイルで、通常メーカーが運営するＨＴＴＰサーバ／ＦＴＰサーバから提供される）のＵＲＬを送信し、ファームウエアのアップデートを行なうことができる。ＳＯＡＰないし同等の取り決めを利用すれば、この（上述のようなＷＥＢ表示とは異なる）ファームウエアのアップデートのような受信側のファイルの取り扱いは任意に指定できるので、ユーザ操作を一切必要とせず通信端末のファームウエアのアップデートを行なうことができる。
【０１２４】
＜実施形態２＞
以上では、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有するためにＦＴＰプロトコルを用いてＵＲＬ情報を送受信する構成を示したが、ＵＲＬ情報の送受信にはＥメールプロトコル（ＳＭＴＰ）を用いることもできる。
【０１２５】
本実施形態でも、通信端末の構成は図１および図２に示したものと同様であるものとし、以下のシーケンス図およびフローチャートにおいても上記実施形態１と同様に通信端末Ａ（２００）および通信端末Ｂ（２２０）の間の通信につき説明する（後続の各実施形態においても同様）。
【０１２６】
本実施形態では、メール送受信を行なうため、図１６に示すようにＩＰ網１００にはメールサーバ１１４およびＰＯＰサーバ１１５が必要である。メールサーバ１１４およびＰＯＰサーバ１１５のサービスは通常、ＩＳＰにより提供されるものであり、本実施形態の実施のために特別に設置する必要はない。図１６ではメールサーバ１１４およびＰＯＰサーバ１１５を１つづつしか示していないが、通信端末Ａ、Ｂ（２００、２２０）のＩＳＰが異なる、などの理由でそれぞれ別のメールサーバ１１４およびＰＯＰサーバ１１５を用いることもある。
【０１２７】
メールサーバ１１４はＳＭＴＰプロトコルによりユーザからのメール送信を受けつけるとともにサーバ間のメールの配送を行ない、ＰＯＰサーバ１１５は（主としてダイアルアップ接続のユーザのため）着信したメールを最終ユーザに配送するために用いられる。ＰＯＰサーバ１１５が実行する対ユーザ配送にはＰＯＰの他にＡＰＯＰやＩＭＡＰなどを用いることもできる。メールサーバ１１４でもＳＭＴＰに代るＥメールプロトコルを用いることが考えられるが、現在ではＳＭＴＰが最もメジャーなＥメールプロトコルである。
【０１２８】
図１７〜図２１に本実施形態の通信シーケンスを、図２２および図２３に対応するフローチャート図を示す。
【０１２９】
図１７〜図１８において、端末ＡでＷＥＢサーバ１１３からＷＥＢページを取得し、表示するまでのシーケンス（Ｓ２５０１〜Ｓ２５２４）は、図５〜図６のシーケンス（Ｓ５０１〜Ｓ５２４）と全く同様である。
【０１３０】
端末ＡはブラウザにＷＥＢページを表示（Ｓ２５２４）させた後、このＷＥＢページの内容を端末Ｂのユーザにも見てもらいたい場合には、端末Ａのユーザは操作部２１５のリソース転送ボタン２１５ａを押下する。
【０１３１】
これにより、端末Ａは利用中のインターネットリソース、すなわち表示中のＷＥＢページの所在を示すＵＲＬデータを転送するためのＥメールテキストを作成する（Ｓ２５２５）。このＥメールテキストでは、受信側で容易に解析し、その後のインターネットリソースの利用処理を制御できるような特別な記述形式を用いると都合がよい。本実施形態では、“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”という記述形式を用いる。この記述形式の場合、受信側では、”ＵＲＬｔｏ”を検索してその後に続く＜＞で囲まれたＷＥＢページ（あるいは他のインターネットリソース）のＵＲＬを容易に抽出できる。
【０１３２】
すなわち、上記のようなＵＲＬ情報の記述形式は、実施形態１におけるＳＯＡＰによるものと同様、ＵＲＬ情報を受信した後の利用処理に関する利用制御情報を含むものといえ、このようなタグ付きのＵＲＬ情報を受信した側では、この利用制御情報にしたがってＵＲＬ情報に対応するインターネットリソースを利用することができる。
【０１３３】
さらに、端末Ａにおいて、端末ＢのＩＰアドレス（Ｓ２５１２で取得済み）から、端末ＡのＲＡＭ２０３内のＩＰアドレス−メールアドレスのテーブルを用いて、端末Ｂのメールアドレスを検出し、このアドレスに対してＳ２５２５で作成したメールを送信する（Ｓ２５２６）。
【０１３４】
メールの送信は通常のメールで一般的に使用されているＳＭＴＰプロトコルによって行われる。もちろん、このとき、ＩＰ電話データの通信で使用しているポート番号とは別の、ＳＭＴＰ用のＷｅｌｌ−Ｋｎｏｗｎポート番号であるポート番号２５を用いてＴＣＰパケットのやり取りを行なうので、メールの送信と音声パケットとは混ざりあうことなく通信でき、音声通話をしながらメール送信ができる。
【０１３５】
まず、端末Ａは自機が送信に使用できるメールサーバ１１４にコネクションを開始する（図１８のＳ２５２７）。詳細のコマンドのやりとりは省略しているが、ＳＭＴＰの規約に基づき自分のドメイン名や送信元である自分のメールアドレス、送信先相手のメールアドレスなどがメールサーバ１１４に伝えられる。メールサーバ１１４でメール送信が問題なく行なえることを確認されると、サーバからＯＫコマンドが返ってくる（Ｓ２５２８）。
【０１３６】
続いて、Ｓ２５２５で作成したメールをメールサーバ１１４に送信し（Ｓ２５２９）、メールが正常にメールサーバ１１４に届いたらＯＫコマンドが返ってくる（Ｓ２５３０）。そして、端末Ａが通信を終了させるための終了要求コマンドをメールサーバ１１４に送信し（Ｓ２５３１）、メールサーバ１１４は終了コマンドを返してメール送信が完了する（Ｓ２５３２）。
【０１３７】
メールを受け取ったメールサーバ１１４は、宛先の端末Ｂのユーザ配送を行なうＰＯＰサーバ１１５にメールを転送する（Ｓ２５３３）。
【０１３８】
端末Ｂでは公知のＰＯＰ３のプロトコルでメールの受信を行なう（図１９のＳ２５３４）。このとき、音声のデータの通信で使用しているポート番号とは別の、ＰＯＰ３用のＷｅｌｌ−Ｋｎｏｗｎポート番号であるポート番号１１０を用いてＴＣＰパケットのやり取りを行なうので、メールの受信と音声パケットとは混ざりあうことなく通信でき、音声通話をしながらメール受信ができる。
【０１３９】
通常、端末ＢがメールをＰＯＰサーバ１１５に取りにいく時間間隔はユーザ設定されている。あるいは、リロードボタン２１５ｂ（あるいはマウスなどによるメニュー操作など他の操作でもよい）の入力によって、強制的にメールを受信することもできる。端末Ｂの製品仕様や設定状態によっては、端末Ａでインターネットリソース共有操作を行なった時、端末Ｂでリロードボタン２１５ｂなどによるメール受信操作を行なう必要がある場合も考えられるが、上記のメールのポーリング間隔をごく短かく設定する、特に後述のようにＩＰ電話の通話中は自動的にメールのポーリング間隔を短かい時間（数秒程度）に設定する、などの対策をとれば、実用上大きなタイムラグは生じない。
【０１４０】
なお、端末Ｂが固定ＩＰアドレスを有していたり、携帯電話のようにＰＯＰやＩＭＡＰを用いずに直接メールを着信できる装置の場合は、端末Ａが送信したメールはＰＯＰ／ＩＭＡＰサーバを経ずに端末Ｂに着信する。具体的には、端末ＡがＳＭＴＰサーバ機能を有し、かつ端末Ｂが電子メールをＳＭＴＰで受信する機能を有していれば、端末ＡはＳ２５２５で作成したメールを、サーバを介さずに直接端末ＢにＳＭＴＰプロトコルで送信できる。また、この際の認証方式は、必要であれば実施形態１で説明したものと同様のものを用いることができる。
【０１４１】
ＰＯＰのメール受信シーケンスの場合は次のように進む。端末Ｂはまず自分のユーザ名やパスワードなどをＰＯＰサーバ１１５に送信し、ＰＯＰサーバ１１５とコネクションを開始する（Ｓ２５３５）。ユーザ名、パスワードなどを認証するとＰＯＰサーバ１１５はＯＫコマンドを返す（Ｓ２５３６）。
【０１４２】
続いて端末Ｂは自分宛てのメールが届いているかを確認するコマンドをサーバに送信する（Ｓ２５３７）。本シーケンスでは、端末Ａから送信されたＵＲＬ通知メールがＰＯＰサーバ１１５に届いているので、ＰＯＰサーバ１１５は受信メールがあることを端末Ｂに通知する（Ｓ２５３８）。端末Ｂはメールの受信を要求するコマンドをサーバに送信して（Ｓ２５３９）、ＰＯＰサーバ１１５はＵＲＬ通知メールを端末Ｂに送る（Ｓ２５４０）。メール受信が完了すると端末Ｂは終了要求をＰＯＰサーバ１１５に送信し（Ｓ２５４１）、それに対してＰＯＰサーバ１１５は終了コマンドを端末Ｂに返して、メールの受信は終了する（Ｓ２５４２）。
【０１４３】
また、本実施形態では、後述のフローチャートで詳細に説明するように、ＩＰ電話通話中は初期設定されているメール受信間隔より短い間隔でメールを取りに行くことができる。これはいちいちリロードボタン２１５ｂを押さなくても、端末ＡでＷＥＢページが更新されるごとに（端末Ａにおける自動制御あるいは明示的な手動操作に基づき）送られるＵＲＬ通知メールを、大きな遅延なしに受信してページの更新に追従することができる。
【０１４４】
ＵＲＬ通知メールを受信（Ｓ２５４３）した端末Ｂは、受信したメールテキストを解析し、メール中のＵＲＬを抽出する（Ｓ２５４４）。
【０１４５】
その後、図２０〜図２１において、端末Ｂで行なわれるＷＥＢページの表示シーケンス（Ｓ２５４６〜Ｓ２５６９）は、図８〜図９のシーケンス（Ｓ５４６〜Ｓ５６９）と同様である。
【０１４６】
図２２は端末Ａ側の、図２３は端末Ｂ側の制御手順を示している。
【０１４７】
図２２において、ダイヤル操作を行ない、ＩＮＶＩＴＥメッセージを送信してＳＩＰサーバ１１０に接続すると（Ｓ２６０１）、ＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、ｒｉｎｇｉｎｇを送信端末に返すので、相手先端末が応答するのを待つ（Ｓ２６０２）。相手先端末が応答すると、ＯＫメッセージと相手先端末の電話番号に対応するＩＰアドレスを送信端末に返すので、送信端末は相手先のＩＰアドレスを取得してＲＡＭ２０３に一時格納し（Ｓ２６０３）、その後、ＩＰ電話の通話状態に入る（Ｓ２６０４）。
【０１４８】
端末ＡにおいてＷＥＢページを表示させるためにブラウザを起動し（Ｓ２６０５）、ブラウザにＵＲＬを入力すると、ＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ２６０６）。そしてＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスして目的のＷＥＢページのデータを受信し（Ｓ２６０７）、ブラウザにＷＥＢページを表示させる（Ｓ２６０８）。
【０１４９】
本実施形態では、前述のように、ＵＲＬデータをメールにより送信する。ＵＲＬをメールで転送するため、ＵＲＬを記述したメールを作成する（Ｓ２６０９）。本実施形態では“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”というテキストデータをメール本文中に書き込んだメールを作成している。ただし、ＵＲＬの記載方法は送信側と受信側とで同じ規格で行われていれば、特にこれに限ったものでなくてもよく、表題（Ｓｕｂｊｅｃｔ：ヘッダ）にＵＲＬを書いても構わないし、“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”のような形式でなくても構わない。つづいて、ＲＡＭ２０３内にあるＩＰアドレスとメールアドレス対応表を用いて、ステップＳ２６０３で取得した相手先ＩＰアドレスをもとに、相手先のメールアドレスを検索する（Ｓ２６１０）。検索した結果メールアドレスが見つかればステップＳ２６１２以降のメール送信を行い、見つからなければメールは送信できないので、通話を続けながら、最終的にはステップＳ２６１５に進み、ブラウザを終了させる（Ｓ２６１１）。
【０１５０】
ステップＳ２６１１でメールアドレスが見つかったら、ステップＳ２６１２で見つかったメールアドレスを宛先として作成したＵＲＬ通知メールを送信する要求をメールサーバ１１４に送信する（Ｓ２６１２）。メールサーバ１１４では、送信元である送信端末のドメイン、送信先のメールアドレスなどをチェックして、メール送信を許可するかどうかを判断する。送信端末ではメールサーバ１１４からＯＫメッセージがくるか否かを待つ（Ｓ２６１３）。ステップＳ２６１３でＯＫメッセージを受信すれば、メールを送信し（Ｓ２６１４）、通話を続け、受信しなければメールを送信しないで通話を続け、最終的にはステップＳ２６１５に進み、ブラウザを終了させる。もちろん他のＷＥＢページにアクセスして、もう一度ステップＳ２６０６からの処理を行なうことが可能であることはいうまでもない。
【０１５１】
通話を終了するときは、オンフックにすることによって送信端末はＳＩＰサーバ１１０にＢＹＥコマンドを送信して通話を終了する（Ｓ２６１６）。もちろん相手先に切断されたことをＢＹＥコマンドの受信によって検出すると通話を終了することは言うまでもない。
【０１５２】
一方、端末Ｂ側では、スタンバイ状態では着信があるかどうか監視をしている（図２３のＳ２７０１）。ＩＮＶＩＴＥコマンドの受信によって着信を検出すると、着信に応答しＯＫコマンドを返し（Ｓ２７０２）、通話状態に入る（Ｓ２７０３）。
【０１５３】
この通話中、設定されている受信メール取得時間になったか（Ｓ２７０４）、およびリロードボタン２１５ｂによる受信メール取得操作があるか（Ｓ２７０５）をチェックする。この種の機器では、デフォルトのメール受信間隔は１５分程度とするが、ユーザの設定によってこの時間は変更可能である。
【０１５４】
なお、後述の通り、本実施形態ではＵＲＬデータの転送後、メール受信間隔をより短い時間に短縮するが、ＩＰ電話の通話開始直後から（たとえばＳ２７０３において）このメール受信間隔の短縮を行なってもよい。
【０１５５】
受信メール取得時間でもなく（Ｓ２７０４）、リロードボタン入力もなければ（Ｓ２７０５）、通話が切断されたかをＢＹＥコマンドを受信するか否かでチェックし（Ｓ２７１７）、通話が切断していなければ、通話状態を保持する。
【０１５６】
受信メール取得時間であるか（ステップＳ２７０４）、リロードボタン入力（Ｓ２７０５）があると、ＰＯＰサーバ１１５に接続して受信メール確認コマンドを送出する（Ｓ２７０６）。ＰＯＰサーバ１１５からの返信コマンドによって、受信メールがあるか否かをチェックして（Ｓ２７０７）、受信メールがなければ通話が切断されたか否かをチェック（Ｓ２７１７）する。
【０１５７】
ＰＯＰサーバ１１５に受信メールがあれば、受信メール取得コマンドをＰＯＰサーバ１１５に送出して、ＰＯＰサーバ１１５から受信メールを転送させる（Ｓ２７０８）。
【０１５８】
そして、ＰＯＰサーバ１１５から受信したメールの中（当然複数のメールを受信することもある）にＵＲＬを通知するメールがあるかを判定（Ｓ２７０９）する。この判定は、メール本文中に前述の“ＵＲＬｔｏ：＜ＵＲＬ＞”の記述があるか否かチェックすることにより行なう。上記のようにして端末Ａから送られたＵＲＬ通知メールがあれば、そのメールの“ＵＲＬｔｏ：”タグからＵＲＬ文字列を抽出する（Ｓ２７１０）。
【０１５９】
ＵＲＬ通知のメールを受信すると、この通話中に、たとえば送信側でＷＥＢページの更新があって、新たなＵＲＬが通知されてくることが頻繁に起こることが想定される。この場合に設定値（デフォルトはたとえば１５分）のままだと、端末Ａ側でＷＥＢページが更新されるたびに、端末Ａ側の通話音声にしたがって通話中の音声によってページが更新されたことを聞いた上で、リロードボタン２１５ｂを操作しなければ新しいＵＲＬを受信できないので、本実施形態では、受信メール取得時間を１分（あるいはより短い時間でもよい）に変更する（Ｓ２７１１）。もちろん、先に触れたように、ＩＰ通話開始直後（たとえばＳ２７０３）からこの受信メール取得時間短縮を行なっている場合にはこの処理は必要ない。
【０１６０】
続いてＷＥＢページを表示させるためにブラウザを起動し、（Ｓ２７１２）ＵＲＬ通知メールの“ＵＲＬｔｏ：”タグから抽出したＵＲＬ文字列をＷＥＢブラウザに入力する。端末ＢはＵＲＬで指定されたＷＥＢサーバ１１３のアドレスをＤＮＳサーバ１１２に問い合わせ、検索結果を受信する（Ｓ２７１３）。続いてＤＮＳサーバ１１２から得たＩＰアドレスを元にＷＥＢサーバ１１３にアクセスし、ＷＥＢページのデータを受信し（Ｓ２７１４）、ブラウザにＷＥＢページを表示させる（Ｓ２７１５）。その後、ブラウザの閲覧が必要なくなったらブラウザを終了させる（Ｓ２７１６）。
【０１６１】
通話の終了はＢＹＥコマンドを受信するか否かでチェックする（Ｓ２７１７）。相手先に通話を切断されたことを検出するとＯＫコマンドを返して通話を終了し、オンフック状態に復帰する（Ｓ２７１８）。その後、ステップＳ２７１１で変更した受信メール取得間隔を設定値に戻し（Ｓ２７１９）、処理を終了する。
【０１６２】
なお、ここではＵＲＬの送信側で“ＵＲＬｔｏ：＜ＷＥＢページのＵＲＬ＞”というテキストデータをメール本文中に書き込んだメールを作成し、受信側で受信したメールの中（当然複数のメールを受信することもある）に前述の“ＵＲＬｔｏ：＜ＵＲＬ＞”の記述があるか否かチェックすることで同一のインターネットリソースの共有利用を実施した。しかしこれに限らず、送信側で図３１に示されるＳＯＡＰメッセージをもつ実行ファイルを添付したメールを作成して送信し、受信側でＳＯＡＰメッセージをもつ実行ファイルを受信したかどうかをチェックすることでＳＯＡＰを用いるようにすることも可能である。
【０１６３】
以上のようにして、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有することができ、実施形態１と同様に従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースの情報が伝わり、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１６４】
本実施形態２によれば、ＵＲＬデータの転送にＥメールを用いている。メール送受信の機能はこの種の装置に設けられることが多いため、ハードウェア／ソフトウェア構成を大きく変更せずに実施することができる。また、上記のようにメール受信間隔を短縮する（ＩＰ通話開始直後から、あるいは最初のＵＲＬ通知メールを受信した後）ことにより、大きなタイムラグを生じることなくインターネットリソースを共有利用することができる。
【０１６５】
なお、実施形態１で述べた種々の変形例は、実施形態１とのＵＲＬデータの転送方式の差異に関係するものでなければいずれも同様に本実施形態２においても通用するのはいうまでもない。
【０１６６】
＜実施形態３＞
以上では、ＵＲＬデータの転送方式にＦＴＰ、あるいはＥメールプロトコル（ＳＭＴＰ）を用いる例を示した。本実施形態では、ＨＴＴＰプロキシ技術を用いてＵＲＬデータを転送する。
【０１６７】
ＨＴＴＰプロキシサーバに関しては、ＨＴＴＰ−１．１に関してはＲＦＣ２６１６に記載されている。ＨＴＴＰプロキシサーバは、ＨＴＴＰクライアントに代ってＨＴＴＰサーバにアクセスし、目的のＨＴＴＰデータを取得し、ＨＴＴＰクライアントに転送するもので、ＨＴＴＰデータをキャッシュすることもでき、これによりＨＴＴＰトラフィックを軽減したり、あるいはＨＴＴＰクライアントの情報（ＩＰアドレスその他のブラウザが提供可能な情報）をＨＴＴＰサーバから隠すなどの目的で広く利用されている。
【０１６８】
本実施形態では、ＩＰ電話の通話中の相手とインターネットリソースを共有利用したい場合、一方の端末がＨＴＴＰプロキシサーバとして機能することにより相手にインターネットリソースデータそのものを送信する。したがって、本実施形態では、インターネットリソースの所在を示すＵＲＬデータを転送するのではなく、既に取得済みのインターネットリソース自体を通話相手に転送する。
【０１６９】
本実施形態でも、通信端末およびネットワークの構成は図１〜図４に示したものと同様であるものとし、以下のシーケンス図およびフローチャートにおいても上記実施形態１と同様に通信端末Ａ（２００）および通信端末Ｂ（２２０）の間の通信につき説明する。
【０１７０】
図２４および図２５は、端末Ａと端末ＢがＩＰ電話により通話中、端末ＡがＷＥＢページを取得し、端末ＡがＨＴＴＰプロキシサーバ、端末ＢがＨＴＴＰクライアントとなりＷＥＢページを共有利用する様子を示している。
【０１７１】
図２４のＳ３７０１〜Ｓ３７０４はＩＰ電話による通話を開始するまでの処理である。まず、端末Ａが端末Ｂを発呼する（もちろん、この発呼方向は逆であっても構わない）。
【０１７２】
端末Ａはダイヤル操作を行いＳＩＰサーバ１１０に接続する（Ｓ３７０１）。前述同様にＳＩＰサーバ１１０は相手先端末の呼び出しを行なうとともに、端末Ａに相手先の端末Ｂの電話番号に対応するＩＰアドレスを返す（Ｓ３７０２）。端末Ａは呼び出し中状態になり、端末Ｂが応答するのを待つ（Ｓ３７０３）。端末Ｂが応答すると通話状態になる（Ｓ３７０４）。
【０１７３】
一方、端末Ｂはスタンバイ状態では着信があるかどうか監視をしている（Ｓ３７１１）。着信を検出すると端末Ｂは着信に応答し（Ｓ３７１２）、通話状態になる（Ｓ３７０４）。
【０１７４】
本実施形態では、端末ＢにおいてあるＷＥＢページを閲覧する需要が発生し、そのＷＥＢページを端末Ａで共有利用（閲覧）させたい場合の処理を説明する。この場合、端末Ｂでブラウザを起動し（Ｓ３７１３）、目的のＷＥＢページのＵＲＬを入力して、（普通の閲覧操作ではなく）リソース共有ボタン２１５ａを操作する。
【０１７５】
これにより、端末Ｂは端末ＡをＨＴＴＰプロキシサーバ、自端末をクライアントとして、端末Ａにアクセスする。すなわち、端末Ａと同期を取り、表示したいＷＥＢページをプロキシサーバに要求する（Ｓ３７１４）。このＨＴＴＰプロキシ手順については、後でより詳細に説明する。
【０１７６】
端末Ａは、ＨＴＴＰクライアントとしての端末Ｂからのアクセスを監視（Ｓ３７０５）しており、端末Ｂからアクセスが行われると、端末Ｂと同期を取りＷＥＢページ要求を受け取り、端末Ｂが表示したいＵＲＬ情報を取得する（Ｓ３７０６）。
【０１７７】
端末Ａは、取得したＵＲＬ情報を用いてＷＥＢサーバ１１３にアクセスし（Ｓ３７０７）、端末Ｂが要求したＷＥＢデータを取得する（Ｓ３７０８）。取得したＷＥＢデータは端末Ａのキャッシュに保存されるとともに、ＨＴＴＰクライアントとしての端末ＢにもＷＥＢページ要求に対する応答として転送する（Ｓ３７０９）。
【０１７８】
また、端末Ａはブラウザを起動させ、端末Ｂから要求されたＷＥＢページを表示させる（Ｓ３７１０）。ただし、端末Ａにおける表示は必ずしも必須のものではない。一方、端末Ｂはプロキシサーバとしての端末Ａからの応答を待ち（Ｓ３７１５）、プロキシサーバからＷＥＢデータを取得し（Ｓ３７１６）、取得したＷＥＢページを表示させる（Ｓ３７１７）。閲覧が終ったら、端末ＡないしＢはブラウザを終了させる（図２５のＳ３７１８、Ｓ３７２０）。
【０１７９】
本実施形態では、端末Ｂとの通話が終了すると端末Ａから通話を切断している（Ｓ３７１９）。端末Ｂでは、端末からの切断を検出（Ｓ３７２１）するとオンフック処理を行ない通話を切断する（Ｓ３７２２）。この切断シーケンスにおいて、端末ＡおよびＢの動作は図示と逆であってもよい。
【０１８０】
また、以上では、端末ＡがＨＴＴＰプロキシサーバとして、端末ＢがＨＴＴＰクライアントとして動作し、端末ＢからＷＥＢページを要求しているが、これらの役割は逆であってもかまわない。
【０１８１】
図２６は、端末Ａから端末Ｂへ呼接続するときのシーケンス図である。発呼側の端末ＡはＩＳＰサーバ１１０に接続可能で、被呼側の端末ＢもＩＳＰサーバ１１０に接続可能である。ＩＳＰサーバ１１０はＳＩＰサーバ、ロケーションサーバ、ＤＮＳサーバなどから構成され、お互いにインターネットで接続されている。
【０１８２】
まず端末Ａにおいて操作部２１５からダイヤル操作を行なう。前述の各実施形態同様、これにより端末ＡからＳＩＰサーバ１１０を介してＩＮＶＩＴＥメッセージが送信され、端末Ｂとの通話状態が形成される（Ｓ４００５〜Ｓ４０１２）。端末ＡおよびＢは相互のＩＰアドレスを認識する。
【０１８３】
図２７は、通話開始後、上記のようにして端末ＡがＨＴＴＰプロキシサーバとして、端末ＢがＨＴＴＰクライアントとして動作し、端末ＢからＷＥＢページを要求する際のＨＴＴＰパケットのやり取りを示している。また、図２８〜図３０は各ＨＴＴＰパケットの構成を示している。
【０１８４】
図２７のシーケンスには４０００番台のステップ（シーケンス）番号が用いられ、図２８〜図３０では５０００番台の参照符号が用いられている。以下の説明では「（Ｓ４ｘｘｘ・５ｘｘｘ）」の形式で、各図のステップおよびパケット（ないしその内部構成）との対応を示す。
【０１８５】
まず、図２８によりＨＴＴＰパケットの構成を説明する。図２９および図３０のパケットは図２８の構造を有する。図２８はＴＣＰ／ＩＰで用いられるパケットの一般的な構成を示しており、図示のように、ＴＣＰ／ＩＰパケットはＩＰヘッダ部５００１とＩＰデータ部５００２から成る。ＩＰヘッダ部５００１には送信元のＩＰアドレス５００８、送信先のＩＰアドレス５００９などが記述される。
【０１８６】
ＩＰデータ部５００２は、さらにＴＣＰヘッダ部５００３とＴＣＰデータ部５００４から成り、ＴＣＰヘッダ部５００３には送信元ポート番号５００５、送信先ポート番号５００６、ＴＣＰパケットのタイプなどを示すコントロールフラグ５００７などが記述される。
【０１８７】
以下、図２７、図２９、および図３０を参照して、端末Ａがプロキシサーバ、端末Ｂがクライアントとなり、同一のＷＥＢページを共有利用する際の動作を説明する。
【０１８８】
プロキシサーバとして機能する端末Ａは、ＷＥＢサーバ１１３、およびＨＴＴＰクライアントとして動作する端末Ｂとの間でそれぞれＨＴＴＰデータを送受信するために、データ送受信用の２つのポートを用いる。図２７では、端末Ａを端末Ａ−１、および端末Ａ−２として示しているが、この２つの表示は上記のデータ送受信用の２つのポートに対応するものである。ＴＣＰ／ＩＰでは、ポート番号は相手と同期を取ってから役割を終えるまでの一連の流れが終ると、次には違うポート番号が使用される。ＨＴＴＰクライアントとして動作する端末Ｂも複数のポートを用いることができるが、本実施形態のＨＴＴＰ通信では１つのみ用いる。
【０１８９】
まず、端末ＢはＷＥＢページを表示させるため、プロキシサーバとしての端末Ａと同期を取る。すなわち、端末Ａのポート番号１３０３はＨＴＴＰポートである８０番を使用し、端末ＢからＳＹＮパケットを送信すると（Ｓ４３０５・５３０５）、端末ＡはＳＹＮ・ＡＣＫパケットを返し（Ｓ４３０６・５３０６）、これに応じて端末ＢからＡＣＫパケットが送信される（Ｓ４３０７・５３０７）。この後、端末Ｂと端末ＡはＨＴＴＰ通信を行なうことができる。この後の端末Ｂと端末Ａとの間のＴＣＰパケットのやりとりでは、端末ＢはＴＣＰデータ部５００４にＨＴＴＰコマンドを記述し、端末ＡはＴＣＰデータ部５００４にそれに対する応答を記述することになる。
【０１９０】
端末Ｂは端末ＡにＨＴＴＰでＷＥＢデータの要求を行なう（Ｓ４３０８・５３０８）。このＴＣＰパケット５３０８により端末Ｂから端末ＡにＵＲＬ情報が伝達される。
【０１９１】
プロキシサーバとして機能する端末Ａは、端末Ｂに変わってＷＥＢサーバ１１３にＷＥＢページのデータを要求する。端末Ａは端末Ｂとの通信で使っているポートとは異なるポート１３０２を用意しＷＥＢサーバと同期を取る。すなわち、端末ＡからＳＹＮパケットを送信（Ｓ４３０９・５３０９）すると、ＷＥＢサーバ１１３はＳＹＮ・ＡＣＫパケットを返し（Ｓ４３１０・５３１０）、端末ＡはＡＣＫパケットを返す（Ｓ４３１１・５３１１）。この後、端末ＡとＷＥＢサーバ１１３はＨＴＴＰ通信を行なうことができる。上記同様に、ＷＥＢサーバ１１３端末Ａとの間のＴＣＰパケットのやりとりでは、端末ＡはＴＣＰデータ部５００４にＨＴＴＰコマンドを記述し、ＷＥＢサーバはＴＣＰデータ部５００４にそれに対する応答を記述する。
【０１９２】
その後、端末ＡはＷＥＢサーバにＨＴＴＰでＷＥＢデータの要求を行い（Ｓ４３１２・５３１２）、目的のＷＥＢデータを受信する（Ｓ４３１３・５３１３）。端末Ａはこれに対してＡＣＫを返す（Ｓ４３１４・５３１４）。端末ＡはＷＥＢデータをメモリに記憶するとともに、端末ＢにＷＥＢデータ要求の応答として転送する（Ｓ４３１５・５３１５）。端末Ｂはこれに対してＡＣＫを返す（Ｓ４３１６・５３１６）。
【０１９３】
端末ＡはＷＥＢサーバから受信したＷＥＢページを表示し（Ｓ４３１７）、端末Ｂは端末Ａから受けたＷＥＢページを表示する（Ｓ４３１８）。
【０１９４】
以上のようにして、ＩＰ電話で通話中の端末どうしでインターネットリソースを共有することができる。従来のＩＰ電話通信中の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソースそのものの情報が伝達され、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるため、操作性を向上できる。
【０１９５】
なお、実施形態１で述べた種々の変形例は、実施形態１とのＵＲＬデータの転送方式の差異に関係するものでなければいずれも同様に本実施形態３においても通用するのはいうまでもない。
【０１９６】
本発明を実現するソフトウェアは、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう任意の形式の通信端末に適用でき、その通信端末のＣＰＵのプログラムとしてＲＯＭやその他の記憶媒体などに格納してあらかじめ格納しておく他、外部記憶媒体（ＣＤ−ＲＯＭやフレキシブルディスク、ＭＯなど）を介して供給する、あるいは、ネットワーク経由で供給することができる。特に、ネットワーク経由で供給する場合には、前述のようにインターネットリソースとしてＦＴＰサーバやＨＴＴＰサーバに通信端末のファームウエア（あるいは付加的なソフトウェア）として配置し、本発明の通信方法を介して通信端末にダウンロードし、さらにＳＯＡＰ手順などを介してその通信端末にインストールすることができる。
【０１９７】
【発明の効果】
以上の説明から明らかなように、本発明によれば、ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末、その制御方法、およびその制御プログラムにおいて、通話中の相手通信端末と、目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するためのインターネットリソース共有手段ないし制御過程を含み、ＵＲＬ情報を受信した場合はそのＵＲＬ情報が示すインターネットリソースに自動的にアクセスする構成を採用しているので、従来の音声によるインターネットリソースの伝達と異なり、相互に正しくインターネットリソース（ないしその所在情報）を伝達でき、確実に同じインターネットリソースを利用でき、また、ＵＲＬなどのデータ再入力などの操作を省略できるという優れた効果がある。すなわち、本発明によれば、他の機器を用いることなく通話端末のみによりＩＰ電話で通話中の相手とインターネットリソースを簡単安価に、また面倒な操作を必要とせず確実に共有できる、という優れた効果が得られる。
【図面の簡単な説明】
【図１】本発明を採用した通信端末の構成を示した説明図である。
【図２】図１の装置の制御系の構成を示したブロック図である。
【図３】図１の装置が通信するＩＰ網により構成された通信環境を示した説明図である。
【図４】図１の装置が通信する通信環境の異なる構成を示した説明図である。
【図５】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図６】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図７】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図８】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図９】図１の装置によるＩＰ電話通信の様子（実施形態１）を示した説明図である。
【図１０】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１１】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１２】図１の装置によるＩＰ電話通信の通信制御手順（実施形態１）を示したフローチャート図である。
【図１３】図１の装置による異なるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１４】図１の装置によるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１５】図１の装置によるＦＴＰ通信の様子（実施形態１）を示した説明図である。
【図１６】図１の装置が通信する通信環境の異なる構成（実施形態２）を示した説明図である。
【図１７】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図１８】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図１９】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２０】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２１】図１の装置によるＩＰ電話通信の様子（実施形態２）を示した説明図である。
【図２２】図１の装置によるＩＰ電話通信の通信制御手順（実施形態２）を示したフローチャート図である。
【図２３】図１の装置によるＩＰ電話通信の通信制御手順（実施形態２）を示したフローチャート図である。
【図２４】図１の装置によるＩＰ電話通信の通信制御手順（実施形態３）を示したフローチャート図である。
【図２５】図１の装置によるＩＰ電話通信の通信制御手順（実施形態３）を示したフローチャート図である。
【図２６】図１の装置によるＩＰ電話通信の様子（実施形態３）を示した説明図である。
【図２７】図１の装置によるＩＰ電話通信の様子（実施形態３）を示した説明図である。
【図２８】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図２９】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図３０】実施形態３で用いられるＴＣＰパケットの構成を示した説明図である。
【図３１】実施形態１で用いられるＳＯＡＰメッセージの構成を示した説明図である。
【符号の説明】
１００ ＩＰ網
１０１ 有線回線
１０２ スプリッタ
１０４ 公衆回線
１１０ ＳＩＰサーバ
１１１ ロケーションサーバ
１１２ ＤＮＳサーバ
１１３ ＷＥＢサーバ
１１４ メールサーバ
１１５ ＰＯＰサーバ
２００ 通信端末
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 通信制御部
２０５ ＭＯＤＥＭ部
２０６ 音源部
２０７ 音声処理部
２０８ ハンドセット
２０９ スピーカ
２１０ 本体マイク
２１１ 記録部
２１２ 読取部
２１４ 表示部
２１５ 操作部
２１６ フック検出部
２１９ データバス
２３０ ＡＤＳＬモデム部
２３１ ＡＦＥ部
２３２ ＢＢ−通信部
２３３ ＲＯＭ
２３４ ＲＡＭ
２４０ ネットワーク制御部
２４１ ドライバ部
５００１ ＩＰヘッダ部
５００２ ＩＰデータ部
５００３ ＴＣＰヘッダ部
５００４ ＴＣＰデータ部
５００５ 送信元ポート番号
５００６ 送信先ポート番号
５００７ コントロールフラグ
５００８、５００９ ＩＰアドレス
Claims (18)
- ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末において、
通話中の相手通信端末と、目的のインターネットリソースの利用処理に関する利用制御情報を含む特定の形式で記述された該インターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有手段を有し、
前記インターネットリソース共有手段は前記ＵＲＬ情報を受信すると、前記利用制御情報にしたがって前記ＵＲＬ情報に対応するインターネットリソースに自動的にアクセスすることを特徴とする通信端末。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末において、
通話中の相手通信端末との間で、自機または相手通信端末の一方が他方にＦＴＰログインし、ＦＴＰ手順を用いて目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有手段を有し、
前記インターネットリソース共有手段はＦＴＰ手順により前記ＵＲＬ情報を受信すると、該ＵＲＬ情報が示すインターネットリソースに自動的にアクセスするとともに、
前記ＦＴＰログインの際には、認証情報としてメモリのアドレス帳領域に記憶された相手通信端末に関する情報を用いることを特徴とする通信端末。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末において、通話中の相手通信端末と、目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有手段を有し、
ＩＰ電話による通話中、前記ＵＲＬ情報を記述した電子メールを受信するため、ＰＯＰサーバから電子メールを受信する電子メール受信時間間隔を通常よりも短縮することを特徴とする通信端末。 - 前記ＵＲＬ情報を記述した最初の電子メールを受信した後、前記電子メール受信時間間隔の短縮を行なうことを特徴とする請求項３に記載の通信端末。
- 前記所定のＩＰ電話方式により取得した前記相手通信端末のＩＰアドレスに基づいて、前記ＵＲＬ情報を前記相手通信端末に送信することを特徴とする請求項１〜３のいずれか１項に記載の通信端末。
- 前記インターネットリソースがＨＴＴＰサーバにより提供されるＷＥＢデータであることを特徴とする請求項１〜３のいずれか１項に記載の通信端末。
- ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御方法において、
通話中の相手通信端末と、目的のインターネットリソースの利用処理に関する利用制御情報を含む特定の形式で記述された該インターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、
前記インターネットリソース共有過程は前記ＵＲＬ情報を受信すると、前記利用制御情報にしたがって前記ＵＲＬ情報に対応するインターネットリソースに自動的にアクセスすることを特徴とする通信端末の制御方法。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御方法において、
通話中の相手通信端末との間で、自機または相手通信端末の一方が他方にＦＴＰログインし、ＦＴＰ手順を用いて目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、
前記インターネットリソース共有制御過程はＦＴＰ手順により前記ＵＲＬ情報を受信すると、該ＵＲＬ情報が示すインターネットリソースに自動的にアクセスするとともに、
前記ＦＴＰログインの際には、認証情報としてメモリのアドレス帳領域に記憶された相手通信端末に関する情報を用いることを特徴とする通信端末の制御方法。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御方法において、
通話中の相手通信端末と、目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、
ＩＰ電話による通話中、前記ＵＲＬ情報を記述した電子メールを受信するため、ＰＯＰサーバから電子メールを受信する電子メール受信時間間隔を通常よりも短縮することを特徴とする通信端末の制御方法。 - 前記ＵＲＬ情報を記述した最初の電子メールを受信した後、前記電子メール受信時間間隔の短縮を行なうことを特徴とする請求項９に記載の通信端末の制御方法。
- 前記所定のＩＰ電話方式により取得した前記相手通信端末のＩＰアドレスに基づいて、前記ＵＲＬ情報を前記相手通信端末に送信することを特徴とする請求項７〜９のいずれか１項に記載の通信端末の制御方法。
- 前記インターネットリソースがＨＴＴＰサーバにより提供されるＷＥＢデータであることを特徴とする請求項７〜９のいずれか１項に記載の通信端末の制御方法。
- ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御プログラムにおいて、
通話中の相手通信端末と、目的のインターネットリソースの利用処理に関する利用制御情報を含む特定の形式で記述された該インターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、
前記インターネットリソース共有過程は前記ＵＲＬ情報を受信すると、前記利用制御情報にしたがって前記ＵＲＬ情報に対応するインターネットリソースに自動的にアクセスすることを特徴とする通信端末の制御プログラム。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御プログラムにおいて、
通話中の相手通信端末との間で、自機または相手通信端末の一方が他方にＦＴＰログインし、ＦＴＰ手順を用いて目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、
前記インターネットリソース共有制御過程はＦＴＰ手順により前記ＵＲＬ情報を受信すると、該ＵＲＬ情報が示すインターネットリソースに自動的にアクセスするとともに、
前記ＦＴＰログインの際には、認証情報としてメモリのアドレス帳領域に記憶された相手通信端末に関する情報を用いることを特徴とする通信端末の制御プログラム。 - ＩＰ網に接続し、所定のＩＰ電話方式により通話を行なう通信端末の制御プログラムにおいて、通話中の相手通信端末と、目的のインターネットリソースのＵＲＬ情報を送受信することにより、相手通信端末と同一のインターネットリソースを共有利用するインターネットリソース共有制御過程を含み、ＩＰ電話による通話中、前記ＵＲＬ情報を記述した電子メールを受信するため、ＰＯＰサーバから電子メールを受信する電子メール受信時間間隔を通常よりも短縮するための制御過程を含むことを特徴とする通信端末の制御プログラム。
- 前記ＵＲＬ情報を記述した最初の電子メールを受信した後、前記電子メール受信時間間隔の短縮を行なうための制御過程を含むことを特徴とする請求項１５に記載の通信端末の制御プログラム。
- 前記所定のＩＰ電話方式により取得した前記相手通信端末のＩＰアドレスに基づいて、前記ＵＲＬ情報を前記相手通信端末に送信することを特徴とする請求項１３〜１５のいずれか１項に記載の通信端末の制御プログラム。
- 前記インターネットリソースがＨＴＴＰサーバにより提供されるＷＥＢデータであることを特徴とする請求項１３〜１５のいずれか１項に記載の通信端末の制御プログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003016948A JP3809420B2 (ja) | 2003-01-27 | 2003-01-27 | 通信端末、通信端末の制御方法、および通信端末の制御プログラム |
| US10/543,544 US8306196B2 (en) | 2003-01-27 | 2004-01-26 | Communication terminal, control method for communication terminal and control program for communication terminal |
| PCT/JP2004/000664 WO2004073289A1 (ja) | 2003-01-27 | 2004-01-26 | 通信端末、通信端末の制御方法、および通信端末の制御プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003016948A JP3809420B2 (ja) | 2003-01-27 | 2003-01-27 | 通信端末、通信端末の制御方法、および通信端末の制御プログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004266325A JP2004266325A (ja) | 2004-09-24 |
| JP2004266325A5 JP2004266325A5 (ja) | 2005-07-21 |
| JP3809420B2 true JP3809420B2 (ja) | 2006-08-16 |
Family
ID=33111955
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003016948A Expired - Fee Related JP3809420B2 (ja) | 2003-01-27 | 2003-01-27 | 通信端末、通信端末の制御方法、および通信端末の制御プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3809420B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006311418A (ja) * | 2005-05-02 | 2006-11-09 | Ricoh Co Ltd | 電気機器 |
| JP2007013614A (ja) * | 2005-06-30 | 2007-01-18 | Docomo Technology Inc | 通信制御装置及び通信制御方法 |
| JP4641496B2 (ja) | 2005-12-09 | 2011-03-02 | 富士通株式会社 | ファイル共有システム、ファイル共有方法およびファイル共有プログラム |
| JP2008042739A (ja) * | 2006-08-09 | 2008-02-21 | Nec Access Technica Ltd | Ｓｉｐによるｉｐアドレス取得方法、ネットワーク・システム、及びｓｉｐ端末 |
| JP5351837B2 (ja) * | 2010-06-01 | 2013-11-27 | 日本電信電話株式会社 | 呼制御方法及び呼制御装置 |
| JP5920829B2 (ja) * | 2012-07-10 | 2016-05-18 | レノボ・シンガポール・プライベート・リミテッド | アプリケーション・ウィンドウの表示を共有する方法、情報端末装置およびコンピュータ・プログラム |
-
2003
- 2003-01-27 JP JP2003016948A patent/JP3809420B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004266325A (ja) | 2004-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3840202B2 (ja) | 通信端末、通信端末の制御方法、および通信端末の制御プログラム | |
| JP2005020647A (ja) | 通信端末、通信端末の制御方法、通信端末の制御プログラム | |
| KR100675304B1 (ko) | Ｉｐ 전화 시스템 및 발호 방법 | |
| JP4343626B2 (ja) | 画像通信制御方法、画像通信制御プログラム、および画像通信装置 | |
| KR100629002B1 (ko) | Ｉｐ 전화 시스템, ｉｐ 전화 장치 및 통신 방법 | |
| KR100598730B1 (ko) | Ｉｐ 전화기 및 ｉｐ 전화 통화 방법 | |
| KR100671534B1 (ko) | Ｉｐ 전화 시스템, ｉｐ 전화 장치 및 착신 유저 식별 방법 | |
| KR100671532B1 (ko) | Ｉｐ 전화 시스템, ｉｐ 전화 장치 및 착신 유저 식별 방법 | |
| KR100598729B1 (ko) | 호 에이전트 장치, ｉｐ 전화 장치 및 ｉｐ 전화 시스템 | |
| WO2004073289A1 (ja) | 通信端末、通信端末の制御方法、および通信端末の制御プログラム | |
| JP4283740B2 (ja) | Ｉｐ電話システム、ｉｐ電話装置及び通話方法 | |
| KR100721837B1 (ko) | Ｉｐ 통신 방법, ｉｐ 단말 장치, ｅｎｕｍ 서버 및 ｉｐ통신 시스템 | |
| JP3809420B2 (ja) | 通信端末、通信端末の制御方法、および通信端末の制御プログラム | |
| JP4995416B2 (ja) | Ｉｐ通信装置およびｉｐ通信方法 | |
| JP4426922B2 (ja) | Ｉｐ電話システム、ｉｐ電話装置及び伝言メッセージ録音方法 | |
| JP4012082B2 (ja) | 通信端末、その制御方法、及びその制御プログラム | |
| US7436819B2 (en) | Communication apparatus and control method thereof | |
| JP2005101745A (ja) | Ｉｐ電話システム及び通信端末 | |
| JP2006041915A (ja) | 情報通信装置およびその制御方法 | |
| JP4898603B2 (ja) | 通信装置および通信方法 | |
| JP2006033588A (ja) | Ｉｐ電話システム、ｉｐ電話装置及び通話方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041126 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051011 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051212 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060131 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060403 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060516 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060522 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3809420 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100526 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100526 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110526 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130526 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140526 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |