WO2004073289A1 - 通信端末、通信端末の制御方法、および通信端末の制御プログラム - Google Patents

Description

明 細 書 通信端末、 通信端末の制御方法、 および通信端末の制御プログラム 技術分野

本発明は、 I P網に接続し、所定の I P電話方式により通話を行なう通信 端末、 その制御方法、 その制御プログラムに関するものである。

'背景技術

近年、インターネットの普及が世界的に急速に拡大しており、通信料金の 著しい低減を図ることができる利点から、インターネット電話（以下 I P電 話）が注目を浴びている。インターネット電話で特に現在有力な規格は V o I P (下記の非特許文献 1 ： I TU— T勧告 H. 323など） であり、 この ような規格によるインターネット電話対応の機器が様々な形で提案されて いる。

ΓΡ電話の 1つの利用形態として、インターネットサービスプロバイダを 経由して、常時接続する状態で LANを経由して相互に直接接続する形態が 考えられる。 I P電話では、通信しようとするユーザが相互に I P接続する 必要があるため、インターネット上にランデブーサーバが用意される。 ラン デブ一サーバに電話番号と最寄のインターネットサービスプロバイダとの 対応テーブルを設け、着呼側ユーザに公衆回線経由で通話要求と発呼側ユー ザの I Pァドレスとを通知し、双方のユーザがランデブーサーバを介して同 時接続することにより、通話を実現する。 このランデプーサーパを用いる規 格の 1つとして、 S I P (S e s s i o n I n i t i a t e P r o t o c o l :下記の非特許文献 2 ： RFC 2543) が知られている。

非特許文献 1 I TU— T勧告 H. 323 非特許文献 2

R F C 2 5 4 3 (htt ： //www. faqs. org/rf cs/rf c2543. html)

ところが、従来の I P電話の技術は、 I Pコネクションの上で音声通信を 行なうだけのものが多い。

たとえば、 I P電話で通話中の場合、相互の I Pァドレスが判明している にもかかわらず、ユーザはこの I pァドレスを用いて利用できるィンターネ ットリソースに全くアクセスすることができず、ユーザに充分なサービスを 提供しているとはいえない。

たとえば、従来では、 ある WE Bページや F T Pサーバ、 その他のインタ ーネットリソースの所在を通話中の相手先に伝えたくても、 I P電話の通話 上の音声で伝え合うしか方法がない。インターネッ トリ ソースのァドレスは 通常 U R L、 U R Iのような形式で表現されるが、多くの場合これらの文字 数は電話番号ほどには短かくなく、誤りなくこのような形式のデータを音声 で伝達するのは困難であり、 また非常にわずらわしい。

さらに、現在では、 WE Bブラゥザなどィンターネットリソースを利用す る機構を有する電話機が存在している力 ユーザはこのような端末を用いて いたとしても、一且上記のようにして音声で伝達したインターネットリソー スのアドレスを W E Bブラウザなどに再度入力しなければならない。

また、ユーザの端末が I P電話と、 WE Bページ閲覧のようなインターネ ットリソースの利用を異なる^続方式でしかサポートしていない場合もあ り、そのような場合はユーザは I P電話を切断してから再度 I P接続を行な わなければならない。どうしても通話とインターネットリソースの利用を両 立させたければ、 I P電話用の端末の他にさらに P Cなどの別の機器を用レ、、 別の呼接続の上でインターネットリソースを利用しなければならない。 発明の開示 本発明の目的は、上記の問題を解決し、他の機器を用いることなく通話端 末のみにより I P電話で通話中の相手とインターネットリソースを簡単安 価に、また面倒な操作を必要とせず確実に共有できるようにすることにある。 図面の簡単な説明

図 1は本発明を採用した通信端末の構成を示した説明図である。

図 2は図 1の装置の制御系の構成を示したブロック図である。

図 3は図 1の装置が通信する I P網により構成された通信環境を示した 説明図である。

図 4は図 1の装置が通信する通信環境の異なる構成を示した説明図であ る。

図 5は図 1の装置による I P電話通信の様子（実施形態 1 ) を示した説明 図である。

図 6は図 1の装置による I P電話通信の様子（実施形態 1 ) を示した説図 である。

図 7は図 1の装置による I P電話 ¾信の様子（実施形態 1 ) を示した説明 図である。

図 8は図 1の装置による I P電話通信の様子（実施形態 1 ) を示した説明 図である。

図 9は図 1の装置による I P電話通信の様子（実施形態 1 ) を示した説明 図である。

図 1 0は図 1の装置による I P電話通信の通信制御手順（実施形態 1 ) を 示したフローチヤ一ト図である。

図 1 1は図 1の装置による I P電話通信の通信制御手順（実施形態 1 ) を 示したフローチャート図である。

図 1 2は図 1の装置による I P電話通信の通信制御手順（実施形態 1 ) を 示したフローチャート図である。

図 13は図 1の装置による異なる FTP通信の様子 ' (実施形態 1) を示し た説明図である。

図 14は図 1の装置による FTP通信の様子（実施形態 1) を示した説明 図である。

図 15は図 1の装置による FTP通信の様子（実施形態 1) を示した説明 図である。

図 16は図 1の装置が通信する通信環境の異なる構成（実施形態 2) を示 した説明図である。

図 17は図 1の装置による I P電話通信の様子（実施形態 2) を示した説 明図である。

図 18は図 1の装置による I P電話通信の様子（実施形態 2) を示した説 明図である。

図 1 9は図 1の装置による I P電話通信の様子（実施形態 2) を示した説 明図である。

図 20は図 1の装置による I P電話通信の様子（実施形態 2) を示した説 明図である。

図 21は図 1の装置による I P電話通信の様子（実施形態 2) を示した説 明図である。

図 22は図 1の装置による I P電話通信の通信制御手順（実施形態 2 ) を 示したフローチヤ一ト図である。

図 23は図 1の装置による I P電話通信の通信制御手順（実施形態 2) を 示したフローチャート図である。

図 24は図 1の装置による I P電話通信の通信制御手順（実施形態 3) を 示したフローチャート図である。

図 25は図 1の装置による I P電話通信の通信制御手順（実施形態 3 ) を 示したフローチヤ一ト図である。

図 26は図 1の装置による I P電話通信の様子（実施形態 3) を示した説 明図である。

図 27は図 1の装置による I P電話通信の様子（実施形態 3) を示した説 明図である。

図 28は実施形態 3で用いられる TCPパケットの構成を示した説明図 である。

図 29は実施形態 3で用いられる TCPバケツトの構成を示した説明図 である。

図 30は実施形態 3で用いられる TCPバケツトの構成を示した説明図 である。

図 31は実施形態 1で用いられる SOAPメッセージの構成を示した説 明図である。

図 32は図 1の装置による I P電話通信の通信制御手順（実施形態 4) を 示したフローチャート図である。

図 33は図 1の装置による I P電話通信の通信制御手順（実施形態 4) を 示したフローチャート図である。

図 34は図 1の装置による I P電話通信の様子（実施形態 4) を示した説 明図で'ある。

図 35は図 1の装置による I P電話通信の様子（実施形態 4) を示した説 明図である。

図 36は実施形態 4で用いられる TCPバケツトの構成を示した説明図 である。

図 37は実施形態 4で用いられる TCPバケツトの構成を示した説明図 である。

図 38は実施形態 4で用いられる TCPパケットの構成を示した説明図 である。 発明を実施するための最良の形態

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

なお、 本明細書 （特許請求の範囲も含む） では、 用語として 「インターネ ット」 および 「インターネットリソース」 を用いるが、 前者は I P網を、 後 者は I P網上で I Pを介してアクセス可能なデータ（ファイルやディレクト リリストなどを含む） その他の資源を指す。 すなわち、本明細書において用 語 「インターネット」 は、 単に I P網と同義であり、 広域的かつ公共的に利 用されるいわゆる" I n t e r n e t "の他、企業その他の組織内で閉じた いわゆるイントラネットのような I P網も含み、用語「インターネットリソ ース」はこれらのネットワーク上で I Pを介してアクセス可能なデータを指 すものとする。 これは「I P網リソース」 のような適当な上位概念の用語が 現在のところ一般的ではないための止むを得ない措置である。

図 1は本発明を採用した I P電話機能および WE Bブラゥザ機能を有す る通信端末の構成を示している。 図 1において、符号 1 0 0は、通信端末 2 0 0が接続される I P網（いわゆるインターネットの他に、イントラネット のように閉じた網も考えられる力 S、以下では特に区別する必要がある場合を 除きインターネット網という） で、 有線回線 1 0 1を介して接続される。 本 実施形態では、有線回線 1 0 1としては A D S Lであるものとし、図 1の通 信端末の回線はスプリッタ 1 0 2により P S T N網用の帯域 1 0 4と、 A D S L網用の帯域 1 0 3が分割され、通信端末 2 0 0は、 P S T N接続による '音声通信 （たとえば通話およびファクシミリ） が可能であるとともに、 イン ターネット接続（P .P P 0 Eなどの A D S L接続方式が用いられる） 、 およ ぴインターネット上の資源の利用 （本実施形態の場合、少なくとも I P電話 の他に WE Bページ閲覧、 Eメール送受信など） が可能である。 なお、 I P網 1 0 0への接続は、 A D S Lである必要はなく光ファイバ一 回線や、 C A T V回線、無線回線など任意の回線メディアを用いることがで きる。

図 1の通信端末 2 0 0は液晶表示器などを用いた表示部 2 1 4およびテ ンキーや各種ファンクションキーを含む操作部 2 1 5、および音声通話用入 出力のためのハンドセット 2 0 8を有する。表示部 2 1 4および操作部 2 1 5は通話制御のために用いられる他、 WE Bブラゥザ機能を実現するために も用いられる。

操作部 2 1 5には、リソース転送ボタン 2 1 5 aおよびリロードポタン 2 1 5 bが設けられている。 リソース転送ボタン 2 1 5 aは、本端末どうしで I P電話中にインターネットリソースを共有利用することを指定するため ユーザが押下する。 リロードボタン 2 1 5 bは、 メールの強制受信操作（あ るいは W E Bページのリロード操作など） に用いられる。

図 2に図 1の通信端末 2 0 0の制御系の構成を示す。図示の制御系は、通 信端末 2 0 0で I P電話機能おょぴ、 W E Bブラウザ機能の他、 ファクシミ リ機能 （図 1では不図示） も実現するものである。

図 2において C P U 2 0 1は、データパス 2 1 9を介して各部との信号の 入力を行い、この入力した信号に応じてデータパス 2 1 9に接続された各構 '成要素を制御する。すなわち、 C P U 2 0 1は R OM 2 0 2に格納されたプ ログラムにしたがって全体を制御し、網への接続や、各種プロトコルを制御 し処理を実行する。 もちろん操作、 表示、 読み取り、 記録に使用する制御も 含まれる。

さらに、プロ一ドパンド接続をつかさどる制御や、 I P電話を実現するた めの制御、 W E Bアクセスを行なうための制御、 WE Bページを表示するた めのブラウザ制御、 また、 I Pアドレスの検知、 抽出制御、 そして、 U R L 等のデータを送信するためのファイル作成や、 送受信制御を実行する。 また、 ROM 202は、 プログラムを格納したメモリであり、 マスグ RO Mやフラッシュ ROMなどで構成される。 また、 データの書込み、 消去が必 要なデータ用にフラッシュ ROMや、 EE PROMでも構成されることも考 えられる。 ROM 202には、 C PU 201で行なう制御全般のプログラム が格納されている。

RAM 203は CPU201が処理を行なう場合のワークエリアとして、 呼処理を含む WE B閲覧や Eメール送受信の各処理を実行するにあたって 使用したり、読取、記録時、 または音声 COD ECデータを処理するエリア でもある。 ここは、 ROM202と異なり、 一時的なデータが記憶される。 さらに、 RAM 203は電池等でパックアップされる部分もあり、時間デ ータ等、各種サービス機能の設定内容やアドレス帳 （あるいは電話帳） に登 録した内容を記憶する。図 2ではこのような領域のうち、特にアドレス帳 2 03 aの領域を図示してある。

このァドレス帳 203 aには、通常回線の通話の際の番号通知などで得た 電話番号、 I P電話通信の際に得た I Pアドレス、 さらに、 これらの選択情 報に対応するユーザ名やメールァドレスの他、自機のユーザのユーザ名およ びメールァドレスなどを所定の設定操作に基づき記憶させておく。

また、 このァドレス帳に類した管理情報の記憶領域は、不揮発性のメモリ としての EEPROM等で構成することもできる。

また、 RAM203は、 I P電話接続手順にて検出した I Pアドレスの一 時保管や、 ファイル送受信を行なうためのバッファや、 WE Bページ表示の ための受信バッファとしても利用する。

通信制御部 204は、 アナログ （P S TN) 公衆回線 104を収容するた めのィ-ンタフヱイスであり、 アナログ回線の場合、 局交換機の電話回線（以 後、加入者線と称す） に接続され、 ダイオードによる全波整流回路により構 成され、回線電圧の極性を一致させるための極性一致回路、回路局交換機の 加入者線に接続され、局交換機からの呼出信号を検出するリンガー検出回路、 オフフック操作が行われると回線ループを形成するとともに、局に対してダ ィャルパルスを送出するパルス送出回路、 2線一 4線変換を行なうためのト ランス回路で構成されている。また、外部に接続されるアナログ端末用のィ ンターフェイス 250も設け通常のアナログ端末も接続できるように構成 されている。

205は MOD EM部であり、 DSPと AFE (アナログフロントェンド） で構成され、機能的には、 G 3 FAXによるファクシミリの送受信を行なう フ 7クシミリモデムの機能を、 CPU201の制御により実現する。 さらに モデムデータ （ナンパ一ディスプレイデータ）の解析を行なうナンバデイス プレイ機能と、エコーキャンセラ機能を有し、スピーカフォン機能をも実現 することができる。

音源部 206は、保留音や着信メロディーの音源であり内部に音源データ 生成機能をもち、 ROM202や、 RAM203に記憶してあるデータに基 づき CPU 201の制御により音源部 206でアナログ信号として再生す ることができる。 また擬似 DT、 BT、 RBT等のコールプログレストーン を出力するための音源も兼ねる。

符号 207は音声処理部で、 C PU 201の制御により MODEM部 20 5からの信号や音源部 206、後述するハンドセット 208、 スピーカ 20 9、本体マイク 210、通信制御部 204等の入出力信号をこの音声処理部 207.の音声パス制御により処理する。

ハンドセット 208 (図 1)は通常回線上の通話おょぴ I P電話における 音声の入出力に用いられる。ハンドセッ ト 208のフックの ONZOFFは フック検出部 216により検出され、このフックの状態に応じて回線の ON ZOFFが制御される。

スピーカ 209は着信音や記憶した音声データの出力およびスピーカフ オン通話時のモニタに用いられる。本体マイク 2 1 0はズピー力ホン機能を 実現する際の音声入力に使用する。

記録部 2 1 1は、感熱型、 熱転写型プリンタ、 あるいはレーザービームプ リンタ、インクジヱットプリンタ等の周知の記録手段から構成される記録部 であり、 ファタシミリ記録の場合、 MH、 MR、 MMR符号化されたデジタ ルデータを複号化し、 この複号化したデータを記録する。 また、 WE Bブラ ゥザからデータをプリントする場合は、 R AM 2 0 3を受信バッファとして 使用し、 そこに格納されているマークアップ言語（通常 H TM L ) で記述さ れたウェブ 1ページ分のデータを表示用データに変換し、表示部 2 1 4の一 画面に表示可能な量のデータを R AM 2 0 3内の表示バッファに格納する。 WE Bブラウザは表示バッファへの格納を終了すると記録部 2 1 1へ記録 開始通知を行なう。

記録部 2 1 1は格納終了通知を受け取ると表示バッファからデータを読 み出し、 1ラインごとにプリント用データに変換して記録部 2 1 1へ転送す る。転送が終わると転送終了通知をブラゥザに通知する。転送終了通知を受 けたブラゥザは次の表示用データがあれば表示パッファに格納して記録部 2 1 1に通知し、 ウェブページ分のデータが終わり、次の表示用データがな い時にはページ終了を通知する。以上の処理を繰り返して 1ページ分のデー タを記録部 2 1 1に転送し、 ウェブプリントを行なう。

読取部 2 1 2は C C Dあるいは密着型センサアレイ等の周知の原稿読取 手段を備えており、読取手段で読み取つたアナ口グデータをデジタルデータ に変換するとともに、この変換されたデジタルデータをファクシミリ通信に おいては、 MH、 MR、 MMR符号化等の周知の符号化方法により符号化し 出力する。

符号 2 1 3はセンサ部で'あり、読取部 2 1 2上の送信原稿の有無やサイズ を検出しその結果を C P U 2 0 1に通知する。 また、記録部 2 1 1上の記録 紙の有無やサイズを検出しその結果を C P U 2 0 1に通知する。

表示部 2 1 4 (図 1 ) は、 カラー L C Dや、 モノクロ L C D等の液晶部品 などにより構成され、種々の情報表示を行なうために用いられる。表示部 2 1 4の表示処理にはインターネット上のサーバより受信した H TM Lの情 報の表示、時刻の表示や通信中の回線状態おょぴエラー等の状態の表示、そ の他動作状態のモニタ表示、操作部 2 1 5でキー入力された文字メッセージ や受信した文字メッセージの表示、電話機の各種サービス機能の設定内容な どの表示などが含まれる。

操作部 2 1 5 (図 1 ) はテンキー、 ファンクションキーなどを含むキーボ 一ド（あるいはさらにマウスなどのポィンティングデバイス）などから成り、 表示器 2 1 4とともにユーザ一^ f ンターフェースを構成する。 WE Bブラウ ズ操作、プリント、発呼/着呼/登録などに関するあらゆるユーザ操作を受 け付け、 その内容を制御部 2 0 1に通知する。

操作部 2 1 5のキーには、前述のリソース転送ボタン 2 1 5 aの他、公知 のキーとして次のようなものが含まれる。すなわち、ダイヤル番号や U R L 等を 0— 9および *、 #および前記キーを利用しアルファべットゃ記号等を 入力するためのダイヤルキー、 ファタシミ リの送受信を制御する送信、受信 キー、回線の O N/O F Fを制御するオフフックキー、その他には保留キー、 機能設定を行なうためのセレクトキ一等のキーなどである。

ネットワーク制御部 2 4 0は、インターネット通信にかかわる各種プロト コルを制御する。ネットワーク制御部 2 4 0は便宜上回路ブロックとして示 してある力、実際にはその基本制御は C P U 2 0 1のソフトウエアに'より行 なわれる。

ネットワーク制御部 2 4 0は、 M I Iインタフェイスを用いたドライバ部 2 4 1 (通常 P HYと呼ばれる） を介して N I C (ネットワークインターフ エースカード） 2 4 2 (図示のように複数設けることも可） の入出力を制御 するとともに、 AD S Lモデム部 230の入出力を制御する。

N I C 242は CSMAZCD (イーサネット ：商標名） などのインター フェース方式 （あるいは他の） に基づくものを用いることができる。 ADS Lモデム部 230は上記の AD S Lによる通信に用いられる。 N I C 242 は L A Nに接続された他の機器と通信するために用いられるが、後述の制御 には必ずしも必須ではない。

ネットワーク通信において、ネットワーク制御部 240を中心とした図 2 の回路プロック間の入出力は次のように行なわれる。

I P電話の通信はたとえば I TU— T勧告 H. 323に記載される V o I Pにより行なう。 Vo I Pでは、 I P (I n t e r n e t P r o t o c o 1 ) , UD Ρ (U s e r D a t a g r am P r o t o c o l ) 、 RTP (T r a n s p o r t P r o t o c o l F o r R e a l— T i me A p p 1 i c a t i o n) 、 RSVP (R e s o u s e R e s e r v a t i o n P r o t o c o l) などの各種プロ トコルが利用される。

I P電話の場合、ハンドセット 208から入力される音声信号は、音声処 理部 207を介して処理され、 CODEC部 243により、音声処理のため のコーデック処理を実行し、 I TU— T勧告 G. 71 1 G. 729等の符 号フォーマツ トに基づく符号化/複号化を介して音声信号がデジタルデー タとして送受信される。また、通話相手の I Pァドレスを特定するためには、 S I P、 I TU— T勧告 H. 323、 あるいは MCGP等のプロ トコルが利 用される。

本実施形態では、インターネットと通信し、 また N I C 242を介して L ANとも通信する、つまり異なるネッ トワークセグメント間でバケツトをフ ォヮードする。 したがって、 ネットワーク制御部 240には、 異なるネット ワークセグメント間でバケツトを転送するルータ機能、およぴァドレス/ポ 一ト番号の変換を行なう NAT機能が設けられていることが望ましい。 NAT機能は、 プライべ一ト I Pアドレスと、 I n t e r n e tアクセス に利用できる本来のグローバル I Pァドレスを相互に変換し、ローカルな I Pアドレスしか割り当てられていないノードから、透過的に I n t e r n e tをアクセスできるようにするものである。

また、 LANに接続される機器のため、起動時に動的に I Pアドレスを割 り当て、 終了時に I Pアドレスを回収するため、 DHCPも設けられる。

ADSLモデム部 230が ADS L網と接続する際には、 PPP o Eなど のプロトコルが用いられる。 ADS L網と接続する際の認証では PAPZC HAPなどのプロトコルが用いられるので、ネットワーク制御部 240には、 これらの認証プロトコルも実装しておく必要がある。

ネットワーク制御部 240と ADS Lモデム部 230は UTOP I Aな どのィンターフェースを介して接続される。

AD S Lモデム部 230は、インターネット接続に使用するための通信制 御^で、 ここに、 スプリツタで分離した公衆回線を接続する。 そして、 AD S Lモデム部 230は、 A F E部 231と B B—通信部 232で構成される。 AD S Lモデム部 230には AD S Lモデムのプログラム格納用の ROM 233とデータワークエリアの RAM 234が接続されている。

図 3は I Pネットワークの構成を概念的に示している。図 3に示すように 本実施形態の通信端末 200は、公衆回線 101によって I P網 100に接 続され、 相手の通信端末 220と通信する。

図 3は、 通信端末 （A) 200と通信端末 （B) 220が同一インターネ ットサービスプロバイダ （I SP) に接続された状態を想定している。

I P網 100上には、 I P電話での呼接続に用いられる S I Pサーバ 1 1 0、電話番号/ I Pァドレスの対応テーブルを管理するロケーションサーバ 11 1、 I Pアドレスとドメイン/ホスト名の対応テーブルを管理するため の DNSサーバ 1 12、 WEBサーバ 113が設けられている。 また、図 4は図 3と同等の構成であるが、 I P網 100が異なるィンター ネットサービスプロバイダ （I S P : 1 5 1、 1 53) を介して接続されて いる状態を示している。インターネット接続の形態としては、通信相手によ つては図 3、 図 4いずれの接続形態もあり得る。 図 4では、 I S P (A) 1 5 1を介して通信端末 （A) 200が接続され、 I S P (B) 1 53を介し て通信端末 （B) 220が接続されている。

図 4の場合は、異なるサービスプロパイダを結ぶための I S P— GW1 5 2が異なる I S P間のゲートウェイ的役目を行なうことにより、通信端末 2

00、 220間の通信が可能となる。 なお、 I S P— GW1 52は必ずしも 単一の機器により構成されるものではなく、複数のゲートウェイ機器により 構成されている場合もある。

本実施形態の I P電話通信では、 S I P方式を用いる。 ここで発呼側が通 信端末 200、 着呼側が通信端末 220であるものとすると、 S I Pでは、 まず発呼側の通信端末 200が S I Pサーバ 1 1 0に発呼メッセージを送 り、相手端末 220との接続を要求する。 S I Pサーバ 1 10は、 ロケーシ ョンサーバ 1 1 1に相手端末 220の I Pァドレスを問い合わせ、判明した

1 Pァドレスを用いて通信端末 200と 220の間の I Pコネクションが 形成される。

次に上記構成において、 I P電話により通話中の通信端末間で、インター ネットリソースを共有するための通信制御につき説明する。

実施形態 1

図 5〜図 9は本実施形態 1の I P電話通信のシーケンス'を示している。図 5〜図 9の I P電話通信では、図 1および図 2のように構成された通信端末 Aから通信端末 Bへ呼接続し、 通話を行なう。 また、 本実施形態では、 端末 Aで WE Bブラウジングを行なうとともに、 I P電話通信中に通信端末 Aか ら通信端末 Bにその URLデータを転送し、 通信端末 （以下単に 「端末」 と も記す） Aおよび Bとの間で同一の WEB情報を共有できるようにする。 なお、 図 5〜図 9の S I Pサーバ 1 1 0、 ロケーションサーバ 1 1 1、 D NSサーバ 1 1 2、および WE Bサーバ 1 1 3は、図 3または図 4に示した ものと同じである。

図 5〜図 9の通信シーケンスは、図 1の CPU 20 1が通信制御プロダラ ムを実行することにより実現される。この CPU 201の通信制御プロダラ ムはたとえば ROM 202に格納される（後述の他の実施形態においても同 様）。図 5〜図 9の通信シーケンスの各ステップは符号 S 50 1以降により 示されている。 なお、 図 5〜図 9の通信では、既に AD S Lコネクションが 成立し、 端末 Aおよび Bが I P網と接続されているものとする。

まず、端末 Aにおいて、ユーザが操作部 21 5でダイヤル操作を行なう（図 5の S 501 ) 。 これにより、 I NV I TEメッセージにより、 S I Pサー ノ 1 10に接続される （S 502) 。

S I Pサーバ 1 10はロケーションサーバ 1 1 1に対して I Pアドレス を要求し （S 503) 、 ロケーションサーバ 1 1 1は指定された電話番号に 対応した I Pァドレスを検索し、 S I Pサーバ 1 10に得られた I Pァドレ スを送信する （S 504) 。

ここで、 S I Pサーバは、受信した相手端末 I Pアドレスを元に、 I NV I TE要求を端末 Bへ送出し、 接続要求する （S 506) 。 この時、 端末 B が発信側端末 Aの I Pアドレスを入手することになる。

端末 Bは、 S I Pサーバからの I NV I TE要求により着信動作に入る (S 507)。 そして、 呼出中を示す R i n g i n gを S I Pサーバに返し (S 508)、 S I Pサーバは端末 Aに対して R i n g i n g信号を送信す る （S 509) 。

端末 Bが応答すると （S 5 10) 、接続完了を示す OK情報が S I Pサ" バ 1 1 0に送信され （S 5 1 1) 、 S I Pサーバ 1 1 0は、 端末 Aに向けて OK情報を送信し、端末 Aも相手端末 Bの I Pァドレスを入手する （S 5 1 2) 。

その後、端末 A〜端末 B間に生成された I Pコネクションを用いて音声パ ケットの送受信が可能となり （S 5 1 3) 、端末 Aおよび端末 Bは通話状態 となる （S 5 1 4) 。

通常、 Vo I Pによる通信は、 リアルタイム性を重視し、 メッセージを含 めて UD Pベースで行なわれる力 TC Pベースの接続を選択することもで さる。

端末 Aは、 I P網と接続されているため、 WEBページやメール送受信な ど、 インターネット上の資源を利用することができる。

端末 A、 B間の通話の進行に応じ、両者の間で特定の WEBページのよう なインターネットリソースが話題にのぼることは充分考えられる。前述のよ うに従来では、 WE Bページの URLは I P電話中は音声でやりとりしてい た力 S、本実施形態では端末 Aから Bへ、ある WE Bページの URLを伝送し、 端末 Bで閲覧できるようにする例を示す。

端末 Aで、 WE Bブラウザを起動し （S 5 1 5) 、操作部 2 1 5から UR Lを入力すると、端末 Aは URLで指定された WE Bサーバ 1 1 3のァドレ スを DNSサーバ 1 1 2に問い合わせる （S 5 1 6)。 問合せを受けた DN Sサーバ 1 1 2は、 UR Lから WE Bサーバ 1 1 3のァドレスを検索し（S 51 7) 、 検索結果を端末 Aに返す （S 518) 。

端末 Aは DNSサーバ 1 1 2力 ら得た I Pァドレスを元に WE Bサーバ 1 1 3にアクセスする。 端末 Aから SYNバケツトを出し （S 5 1 9) 、 W EBサーバ 1 1 3から SYN · ACKパケットを受信し （S 5 2 0) 、 相手 の S YNに対して ACKパケットを送信する （S 521) 。

このようにして同期が取れると、端末 Aは WE Bサーバ 1 1 3に WE Bぺ ージのリクエストを行い （図 6の S 5 2 2) 、 WE Bサーバ 1 1 3から WE Bページのデータを得る （S 523) 。 WEBページのデータを受信した端 末 Aはブラウザに WE Bページを表示させる （S 524) 。

端末 Aは表示させた WE Bページを通話相手の端末 Bにも表示させるた め、 URLの転送を行なう。 この WE Bページの内容を端末 Bのユーザにも 見てもらいたい場合には、端末 Aのユーザは操作部 2 1 5のリソース転送ボ タン 21 5 aを押下する。

リソース共有利用を起動する操作として、上記のリソース転送ボタン 21 5 aの操作の他、 たとえば、表示部 214のツールバーや、 WE Bブラウザ のウィンドウの 1つとして用意したコンソール上の「URL転送」など適当 な名前のボタンの操作（ポインティングデバイスなどによる操作も含む） な どが考えられ、 これらの所定操作のいずれか、 あるいはいずれも許容するよ うな仕様も考えられる。

本実施形態では、端末 Aから端末 Bに URL情報を FTP (ファイル転送 プロトコル） で転送するため、 URLを記述したファイルを作成する （S 5 25) 。 この URLを含むファイルは受信側でブラウザを立ち上げられるよ うに FTPの上位プロトコルである SOAP (S i mp l e Ob j e c t Ac c e s s P r o t o c o l ： RFC 3288) で記述する。

FTPでは、 制御用のコネクションと、 データ （ファイル） 転送用の 2つ のコネクションを用いる。

まず、端末 Aはロケーションサーバから得た端末 Bの I Pァドレスに基き 端末 Bとの間で制御用ポートの同期を取る。端末 Aから S Yパケットを送信 し（S 5 26)、端末 Bから NS ΥΝ· ACKバケツトを受信し（S 527)、 相手の SYNに対して AC Κバケツトを送信する （S 528) 。端末 Bは端 末 Aに FTP通信が開始できることを示す r e a d yを送信する （S 5 2 9) o

端末 Aは端末 Bにログインをかけ （S 530) 、 端末 Bは端末 Aの口グイ ンを許可する （S 53 1) 。

この FTPログインの認証方式に関しては、既に I Pコネクションが成立 しているので、ユーザ名に a n o n ymo u s、パスヮードにメールァドレ スを用いるいわゆる匿名 FTP方式を用いることで多くの場合充分である と考えられる。 たとえば、 匿名 FTP方式であっても、 さらに I P電話で現 在通話中の相手からの FTP口グインのみしか受け付けないようにすれば かなりのセキュリティを確保できる。

しかし、認証シーケンスにおいては、 さらに相互の端末に固有の情報を交 換してセキュリティを向上することも考えられる。たとえば、図 2の構成に よれば、了ドレス帳 203 aが設けられているので、端末 Aからはメールァ ドレスを送信し、端末 Bでは端末 Aから送信されたメールアドレスが自機の ァドレス帳 203 aに格納されているか否かを判定し、格納されていれば端 末 Aの F T P口グインを許可するようにすればよい。このような FTPログ インシーケンスはユーザ入力を行なうことなく自動で実行することができ、 しかも、上記のようにァドレス帳の情報を用いた認証を行なうようにすれば、 面倒な操作を必要とせず、 不特定多数の相手の FTP口グインを禁止でき、 セキュリティを確保することができる。

続いて端末 Aは制御用のポートの他に URLデータ転送用のポートを用 意 （S 532) し、データ転送用のポートを使用して端末 Bに URLデータ を転送する （図 7の S 535 )。 まず端末 Aは端末 Bとの間でデータ転送用 のポートの同期を取る （S 533、 S 534) 端末 Aは URLを記述した ファイルをデータ転送用のポートを介して端末 Bに送信する （S 536) 。 ファイルを受信した端末 Bは端末 Aのデータ転送用ポートに AC Kを返し、 端末 Aの制御用ポートに受信完了を通知する （S 53 7) 。

U; Lデータの転送が完了すると、端末 Aは URLデータ転送用のポート を開放する （S 538)。 端末 Aはデータ転送用のポートから端末 Bにポー ト解放要求を送信し （S 5 39) 、端末 Bは端末 Aのデータ転送用ポートに ACKを返す （S 540) 。 これを受けて端末 Aは URLデータ転送用のポ ートを開放完了し、 URLデータの転送を終了する （S 541) 。 端末 Aは 端末 Bに FTPの終了を通知し （S 542) 、端末 Bから ACKを受信する (S 543) 。

SOAPで記述されたファイルを受信した端末 Bは （S 544) 、受信し た URLデータのファイルを解析する （S 545) 。 ここで、 図 31に SO APで記述した UR Lデータの一例を示す。 S OAPは XMLベースの情報 伝達のためのプロトコルである S OAPであり、 S OAPメッセージではェ ンべロープ、 ヘッダ、 ボディの構文構造になっており、 図 3 1の下線部分、 つまり SOAPメッセージのボディの部分に本実施形態の特徴がある。図 3 1の他の部分の構文構造は従来と同じである。図 3 1の特徴部分（アンダー ライン部） は次のようになっている。

<BrowsURL>http： //www. canon, co. jp/ezumi. htmlく/ BrowsURL>

このデータ型く BrowsURL〉は、装置がブラゥザを起動し、指定された WWW サーバのアドレスを閲覧すべきことを意味している。 このように、 SOAP サービスで使用する各種データ型はあらかじめ端末がダウンロード したァ プレツト内でパーサー定義がなされており、ァプレツトは SOAPメッセー ジを受信した際にメッセージのヘッダ部分の識別子によりメッセージがサ 一ビスの情報パケットであることを認識することができる。

このようにして、 S OAP記述により、受信した URLデータファイルの 取り扱い方法を指定できるので、端末 Bは S O A Pの指示通りブラウザを起 動し（図 8の S 546)、ブラウザに端末 Aから受信した URLを入力する。 端末 Bは URLで指定された WEBサーバ 1 1 3のァ ドレスを DNSサー ノ 1 1 2に問い合わせる （S 547) 。 問合せを受けた D N Sサーバ 1 1 2 は、 URLから WEBサーバ 1 1 3のァドレスを検索し （S 548) 、 検索 結果を端末 Bに返す （S 549) 。

端末 Bは DNSサーバ 1 1 2から得た I Pァドレスを元に WE Bサーバ 1 1 3にアクセスする。まず端末 Bは SYNバケツトを WEBサーバ 1 1 3 に送信し （S 550) 、 WE Bサーバ 1 1 3から SYN ' ACKバケツトを 受信し （S 55 1) 、 相手の S YN · A CKに対して AC Kバケツトを送信 する （S 552) 。 同期が取れると、 端末 Bは WE Bサーバ 1 1 3に WEB ページのリクエストを行い （S 553) 、 WEBサーバ 1 1 3から WE Bぺ ージのデータを得る （S 554) 。 WE Bページのデータを受信した端末 B はブラウザに WE Bページを表示させる （S 555) 。

WE Bブラウザによる閲覧を終えた端末 Aはブラウザを終了させ（図 9の

S 556) 、 WEBサーバ 1 1 3に切断を送信し （S 557) 、 ブラウザを 終了する （S 558)。端末 Bもブラウザを閲覧し終えるとブラウザを終了 させる （S 559) 。 WEBサーバ 1 1 3に切断を送信し （S 560) 、 プ ラウザを終了する （S 56 1) 。

通話の終了 （S 562) は、 図 9の場合、 端末 A側から行なっている。 V o I Pおよび S I P手順に基づき、 S I Pサーバ 1 10を介して BYEおよ び OKメッセージの交換 （S 563、 S 564、 S 566、 S 567) が行 なわれ、端末 B側ではこれに基づき ROT鳴動（S 565)、オンフック （S 568) が行なわれ、 I P電話の通話シーケンスが終了する （S 569) 。 なお、 上述の URLデータの送信操作は、通話中に何度でも行なえる。 こ のとき、 たとえば、 端末 Aでインターネットリソースが変わる （たとえば表 示中の WE Bページの再表示や、他の WE Bページへのジャンプ） ごとにリ ソース共有ポタン 215 aを操作する方式でもよいし、また、通話が終了す るまで（あるいは他の明示的な操作を行なうまで）端末 Aでインターネット リソースが変わる （たとえば表示中の WE Bページの再表示や、他の WE B ページへのジャンプ）ごとに自動的に端末 Aから端末 Bに U R Lデータを送 信するようにしてもよレ、。

上記の I P電話通信の概略を図 1 0〜図 1 2にフローチヤ一トとして示 す。図 1 0〜図 1 2の手順は上記の図 5〜図 9の通信シーケンスに対応する もので、上記同様、図 1の CPU20 1が通信制御プログラムを実行するこ とにより実現される。この CPU20 1の通信制御プログラムは ROM20 2に格納される。図 1 0〜図 1 2の各ステップは符号 S 60 1以降により示 されている。

まず、端末 Aが I P電話の発呼操作を行なう。 端末 Aのダイヤル操作 （図 1 0の S 601)により S I Pサーバ 1 1 0を用いて I P電話の呼接続処理 が行なわれる。上述の通り、 S I Pサーバ 1 10は相手先端末の呼び出しを 行なうとともに、端末 Aに相手先端末の電話番号に対応する I Pァドレスを 返す （S 602) 。 端末 Aは呼び出し中状態になり、 相手先端末が応答する のを待つ（S 603)。相手先端末が応答すると通話状態になる（S 604)。 端末 Aは WE Bページを表示させるためにブラゥザを起動する （S 60 5) 。 端末 Aのブラウザに URLを入力すると、端末 Aは URLで指定され た WE Bサーバ 1 1 3のァドレスを DNSサーバ 1 12に問い合わせ、検索 結果を受信する （S 606)。 端末 Aは DNSサーバ 1 1 2から得た I Pァ ドレスに基づき WE Bサーバ 1 1 3にアクセスして WE Bページのデータ を受信し（S 607)、ブラウザに WE Bページを表示させる（S 608)。 端末 Aは表示させた WE Bページを相手先端末にも表示させるため、 UR

Lの転送を行なう。端末 Aは URLを FTPで転送するため、 URLを記述 したファイルを作成する （S 609) 。 ファイルは受信側でブラウザを立ち 上げられるように FTPの上位プロ トコルである SOAPで記述する。 端末 Aはロケーションサーバから得た相手先端末の I Pァドレスを元に 相手先端末との間で制御用ポートの同期を取る （S 6 10)。 相手先端末と の同期が取れると、 続いて相手先端末にログインを行なう （S 6 1 1) 。 端末 Aは制御用のポートの他に URLデータ転送用のポートを用意し、相 手先端末との間でデータ転送用のポートの同期を取る（図 1 1の S 6 14)。 端末 Aは URLを記述したファイルをデータ転送用のポートを使用して相 手先端末に送信する （S 61 5) 。 URLデータの転送が完了すると、 端末 Aは URLデータ転送用のポートを解放する （S 6 1 6)。 端末 Aは相手先 端末に FTPの終了を通知し転送終了処理を行なう （S 6 1 7) 。

WE Bブラウザによる閲覧を終えた端末 Aはブラウザを終了させる（S 6 1 8)。 相手先端末との通話が終了すると通話を切断する （図 12の S 62 6) 。

一方、 端末 B側の処理は次のように行なわれる。

端末 Bはスタンパイ状態において、 着信があるかどうか監視をしている (図 10の S 6 1 2)。着信を検出すると端末 Bは着信に応答し（S 6 1 3)、 通話状態になる （S 604) 。

相手先端末から同期を要求されると、端末 Bはそれにしたがって同期を取 る （S 6 1 0) 。 相手先端末から （FTP) ログインを要求されると、 （F TP) ログインを許可しデータ転送待ち状態になる （S 6 1 1) 。 端末 Bは 相手先端末との間でデータ転送用のポートの同期を取り （図 1 1の S 6 1 4)、相手先端末のデータ転送用のポートから URLを記述したファイルを 受信する （S 6 15) 。

URLデータの転送が完了すると、相手先端末のデータ転送用のポートを 解放し （S 6 1 6) 、相手先端末から FTPの終了を受信し転送終了処理を 行なう （S 6 1 7) 。

ファイルを受信した端末 Bは、受信したファイルの解析を行なう （S 6 1 9) 。 ファイルが SOAPで記述されていて、 URLが指定されブラウザを 起動させる指示があるなら （S 620) 、 WE Bページを表示させるために ブラウザを起動する （S 621)。 ブラウザに相手先端末から受信した UR Lを入力すると、端末 Bは URLで指定された WEBサーバ 1 13のァドレ スを DNSサーバ 1 1 2に問い合わせ、 検索結果を受信する （S 622) 。 端末 Bは DNSサーバ 1 1 2から得た I Pァドレスを元に WE Bサーバ 1 13にアクセスして WEBページのデータを受信し （S 623) 、 ブラゥザ に WEBページを表示させる （S 624) 。

ブラウザを閲覧し終えた端末 Bはブラウザを終了させる （S 625) 。 ま た、 端末 Bは相手先との通信状態を監視し （図 12の S 627) 、 相手先に 切断されたことを検出すると通話を終了する （S 628) 。

以上では、発呼した端末 A側から端末 B側に U R Lデータを送信する例を 示したが、 URLの送信はいずれが発呼側かに関係するものではなく、当然 ながら上記と同様にして端末 Bから端末 Aに URLデータを送信し、端末 A 側で閲覧させることができる。 また、以上では、端末 A側から端末 B側に U RLデータを送信する場合、端末 A側が端末 B側に FTPログインする、つ まり端末 B側を FTPサーバとして機能させ、端末 Aが URLデータを送信 (図 7の S 536 ：この際 STOR、ないし S T O Uなどの F T Pコマンド が用いられる） する例を示した。 しかしながら、 URLデータ送信の際の F TPのログイン方向、 送受信方向 （送信コマンドである STOR、 ないし S TOUを用いる力 \受信コマンドである RETRを用いる力、 など） は任意 であり、 適宜変更してよい。

この一例を図 1 3〜図 15に示す。図 1 3〜図 15は、端末 Bから端末 A に URLデータを送信し、端末 A側で閲覧させる場合であるが、ただしこの 場合、上記同様に端末 Aが FTPサーバとしての端末 Bにログインしている ものとし、 URLデータ送信は、 FTPの受信コマンドである RETRを用 いる。

図 13〜図 15では、端末 Aの FTP制御ポートおよびデータポートを符 号 200により、端末 Bの FTP制御ポートおよびデータポートを符号 22 0により示してある。 図 1 3〜図 1 5では、図 5に示したものと同様の I P 電話発呼シーケンスにより既に通話状態が形成されているものとする。また、 既に図 6に示したものと同様の FTP口グイン認証は終了しているものと する。

図 1 3は端末 Bが WE Bページの閲覧を行なう時の様子である。すなわち、 端末 Bが WEBサーバ 1 1 3から通常の HTTPプロトコル（S 1 147〜 S 1 15 1 ) により WE Bデータを取得し、 そのページをレンダリングし、 表示部 214に表示させる （S 1 152) 。 その後、 上述同様にして SOA Pフォーマツトで記述した URLデータファイルを作成する（S 1 1 72)。 このように URLデータファイルは、リソース共有を行なうか否かにかかわ らず、 WE Bページをダウンロードし'たら無条件で作成してもよい。通常は URLデータファイルは 1、 2行の文字列に過ぎないので、 このようにして もシステムに大きな負荷はかからない。

その後、端末 Aのユーザが通話の進行に応じ、端末 Bのユーザと同一の W EBページを閲覧したいと考え、転送のための所定操作（上述のリソース転 送ボタン 21 5 aないし他の同等操作） を操作部 21 5により行なう。 これ により、上記のようにして作成された URLデータファイルが図 14に示す ようにして FTP転送される （S 1 153〜S 1 1 63)。 この場合図示の ように、 FTPサーバとしての端末 Bからファイルを取得するので FTPコ マンド RETRが用いられる （S 1 1 53) 。

その後、 端末 Aで図 1 5に示すようにして URLデータファイルが解析 (S 1 1 64) される。 さらに端末 Aは SOAPに基づき、 WEBサーバ 1 1 3から WE Bデータをダウンロード（S 1 1 65〜S 1 1 69) し、表示 部 214で表示 （S 1 1 70) する。

以上のようにして、実施形態 1によれば、 I P電話通信中に通信している 端末どうしでインターネットリソースを共有する手段を提供すること'がで きる。 実施形態 1の場合、 インターネッ トリソースは WE Bページ （の UR L) であり、 第 1の端末 （A) から第 2の端末 （B) に対して FTPプロ ト コルにより WE Bページの URLを記述したデータファイル（URLフアイ ル） を送信することにより、 第 2の端末 （B) でも第 1の端末 （A) で閲覧 しているものと同じ WE Bページをブラウズすることができる。

これによつて、 I P電話通信中に通信している端末どうしで同じインター ネットリソースを利用 （上記実施形態の場合表示であるが、下記のファーム ウェアの更新の場合のように共有するインターネットリソースの利用方法 は表示に限定されるものではない） させることができ、従来の I P電話通信 中の音声によるインターネットリソースの伝達と異なり、相互に正しくイン ターネットリソースの情報が伝わり、確実に同じィンターネットリソースを 利用でき、 また、 URLなどのデータ再入力などの操作を省略できるため、 操作性を向上できる。

また、 URLデータの受信側では、 SOAPを利用し、 自動的にその UR Lで示されるインターネットリソースを閲覧するブラウザを起動すること ができ、 面倒な操作を一切必要としない。

以上では、 I P電話通信中の第 1および第 2の端末で共有するインターネ ットリソースとして WE Bページを考えたが、 URL (あるいは UR I ) な いしこれと同等のインターネットリソースの所在を示す情報形式（FTPで 送信できさえすればよい）で表現できるインターネットリソースであればど のようなものでも第 1および第 2の端末で共有することができる。 L形 式だけで考えてみても、本発明により共有できるインターネットリソースは、 FTPディレクトリやそのディレクトリ中のファイル、 Go p h e rページ、 音声やビデオ （静止画 z動画） ストリームを提供する各種のサービスなど、 数限りない。

本発明のィンターネットリソース共有技術は、ビジネスや娯楽のための情 報共有に広く用いることができる。特に本発明の通信端末の製品展開などに 有用と考えられるのは、本発明の通信端末のファームウェアのアップデート などに利用することである。たとえば、本発明の通信端末のユーザがトラブ ルに遭遇し、 I P電話でメーカーのサポート窓口に電話し、 相談した結果、 通信端末のファームウェアの更新が必要、 という結論に達した場合、 メーカ 一のサポート要員が直接そのユーザの通信端末にファームウェア（たとえば HTTPや FT Pで取得可能なファイルで、通常メーカーが運営する HTT Pサーバ/ FTPサーバから提供される）の URLを送信し、 ファームゥェ ァのアップデートを行なうことができる。 SOAPないし同等の取り決めを 利用すれば、 この （上述のような WE B表示とは異なる） ファームウェアの アップデートのような受信側のファイルの取り扱いは任意に指定できるの で、ユーザ操作を一切必要とせず通信端末のファームウェアのアツプデート を行なうことができる。

実施形態 2

以上では、 I P電話で通話中の端末どうしでィンターネットリソースを共 有するために F T Pプロトコルを用いて UR L情報を送受信する構成を示 したが、 URL情報の送受信には Eメールプロトコル（SMTP) を用いる こともできる。

本実施形態でも、通信端末の構成は図 1および図 2に示したものと同様で あるものとし、以下のシーケンス図およびフローチヤ一トにおいても上記実 施形態 1と同様に通信端末 A (200) および通信端末 B (220) の間の 通信につき説明する （後続の各実施形態においても同様） 。

本実施形態では、メール送受信を行なうため、図 16に示すように I P網 100にはメールサーバ 1 14および P O Pサーバ 1 15が必要である。メ —ルサーバ 114および PQPサーバ 1 15のサービスは通常、 I S Pによ り提供されるものであり、本実施形態の実施のために特別に設置する必要は ない。図 1 6ではメールサーバ 1 14および POPサーバ 1 1 5を 1つづつ しか示していない力 S、通信端末 A、 B (200、 220)の I S Pが異なる、 などの理由でそれぞれ別のメールサーバ 1 14および POPサーバ 1 1 5 を用いることもある。

メールサーバ 1 14は SMT Pプロトコルによりユーザからのメール送 信を受けつけるとともにサーバ間のメールの配送を行ない、 P O Pサーバ 1 1 5は（主としてダイアルアップ接続のユーザのため）着信したメールを最 終ユーザに配送するために用いられる。 POPサーバ 1 1 5が実行する対ュ 一ザ配送には POPの他に APOPや I MAPなどを用いることもできる。 メールサーバ 1 14でも SMT Pに代る Eメールプロトコルを用いること が考えられる力 S、現在では SMTPが最もメジャーな Eメールプロトコルで める。

図 1 7〜図 21に本実施形態の通信シーケンスを、図 22およぴ図 23に 対応するフローチャート図を示す。

図 1 7〜図 1 8において、端末 Aで WE Bサーバ 1 1 3から WE Bページ を取得し、 表示するまでのシーケンス （S 2501〜S 2524) は、 図 5 〜図 6のシーケンス （S 501'〜S 524) と全く同様である。

端末 Aはブラウザに WE Bページを表示 （S 2524) させた後、 この W E Bページの内容を端末 Bのユーザにも見てもらいたい場合には、端末 Aの ユーザは操作部 21 5のリソース転送ボタン 21 5 aを押下する。

これにより、端末 Aは利用中のインターネットリソース、すなわち表示中 の WE Bページの所在を示す UR Lデータを転送するための Eメールテキ ストを作成する （S 2525) 。 この Eメールテキストでは、 受信側で容易 に解析し、その後のインターネットリソースの利用処理を制御できるような 特別な記述形式を用いると都合がよい。本実施形態では、 "URL t o ： < WEBページの URL〉" という記述形式を用いる。 この記述形式の場合、 受信側では、 " URL t o" を検索してその後に続く <>で囲まれた WEB ページ（あるいは他のィンターネットリソース） の URLを容易に抽出でき る。

すなわち、上記のような UR L情報の記述形式は、実施形態 1における S OAPによるものと同様、 UR L情報を受信した後の利用処理に関する利用 制御情報を含むものといえ、このようなタグ付きの U R L情報を受信した側 では、この利用制御情報にしたがって URL情報に対応するィンターネット リソースを利用することができる。

さらに、端末 Aにおいて、端末 Bの I Pアドレス （S 251 2で取得済み） から、端末 Aの RAM 203内の I Pァドレス一メールァドレスのテーブル を用いて、端末 Bのメールァドレスを検出し、 このァドレスに対して S 25 25で作成したメールを送信する (S 2526) 。

メールの送信は通常のメールで一般的に使用されている SMTPプロト コルによって行われる。 もちろん、 このとき、 I P電話データの通信で使用 しているポート番号とは別の、 SMTP用の We 1 1一 Kn ownポート番 号であるポート番号 25を用いて TC Pバケツトのやり取りを行なうので、 メールの送信と音声パケットとは混ざりあうことなく通信でき、音声通話を しながらメール送信ができる。

まず、端末 Aは自機が送信に使用できるメールサーバ 1 14にコネクショ ンを開始する （図 1 8の S 2527) 。 詳細のコマンドのやりとりは省略し ているが、 SMTPの規約に基づき自分のドメイン名や送信元である自分の メールァドレス、送信先相手のメールァドレスなどがメールサーバ 1 14に 伝えられる。メールサーバ 1 14でメール送信が問題なく行なえることを確 認されると、 サーバから OKコマンドが返ってくる （S 2528) 。

続いて、 S 25 25で作成したメールをメールサーバ 1 14に送信し（S

2529)、メールが正常にメールサーバ 1 14に届いたら OKコマンドが 返ってくる （S 2530) 。 そして、端末 Aが通信を終了させるための終了 要求コマンドをメールサーバ 1 14に送信し （S 2531) 、 メールサーバ 1 14は終了コマンドを返してメール送信が完了する （S 2532) 。 メールを受け取ったメールサーバ 1 14は、宛先の端末 Bのユーザ配送を 行なう？0 サーパ1 15にメールを転送する （S 2533) 。

端末 Bでは公知の POP 3のプロトコルでメールの受信を行なう（図 1 9 の S 2534)。 このとき、 音声のデータの通信で使用しているポート番号 とは別の、 POP 3用の We 1 1 -Kn o w ηポート番号であるポート番号 1 10を用いて TCPバケツトのやり取りを行なうので、メールの受信と音 声パケットとは混ざりあうことなく通信でき、音声通話をしながらメール受 信ができる。

通常、端末 Bがメールを POPサーバ 1 15に取りにいく時間間隔はユー ザ設定されている。 あるいは、 リロードポタン 215 b (あるいはマウスな どによるメニュー操作など他の操作でもよい）の入力によって、強制的にメ ールを受信することもできる。端末 Bの製品仕様や設定状態によっては、端 末 Aでインターネットリソース共有操作を行なった時、端末 Bでリロードボ タン 21 5 bなどによるメール受信操作を行なう必要がある場合も考えら れるが、上記のメールのポーリング間隔をごく短く設定する、特に後述のよ うに I P電話の通話中は自動的にメールのポーリング間隔を短い時間（数秒 程度） に設定する、 などの対策をとれば、 実用上大きなタイムラグは生じな い。

なお、端末 Bが.固定 I Pァドレスを有していたり、携帯電話のように PO Pや I MA Pを用いずに直接メールを着信できる装置の場合は、端末 Aが送 信したメールは POP/ I MAPサーバを経ずに端末 Bに着信する。具体的 には、端末 Aが SMTPサーバ機能を有し、かつ端末 Bが電子メールを SM TPで受信する機能を有していれば、端末 Aは S 2525で作成したメール を、サーバを介さずに直接端末 Bに SMTPプロトコルで送信できる。また、 この際の認証方式は、必要であれば実施形態 1で説明したものと同様のもの を用いることができる。

POPのメール受信シーケンスの場合は次のように進む。端末 Bはまず自 分のユーザ名やパスワードなどを POPサーバ 1 1 5に送信し、 POPサー パ 1 1 5とコネクションを開始する （S 2535) 。 ユーザ名、 パスヮード などを認証すると POPサーバ 1 1 5は OKコマンドを返す（S 2536)。 続いて端末 Bは自分宛てのメールが届いているかを確認するコマンドを サーバに送信する （S 2537) 。 本シーケンスでは、 端末 Aから送信され た URL通知メールが POPサーバ 1 1 5に届いているので、 POPサーバ 1 1 5は受信メールがあることを端末 Bに通知する （S 2538) 。 端末 B はメールの受信を要求するコマンドをサーバに送信して （S 2539) 、 P OPサーバ 1 15は URL通知メールを端末 Bに送る （S 2540)。 メー ル受信が完了すると端末 Bは終了要 ^^を POPサーバ 1 1 5に送信し（S 2 541)、それに対して POPサーバ 1 1 5は終了コマンドを端末 Bに返し て、 メールの受信は終了する （S 2542) 。

また、 本実施形態では、 後述のフローチャートで詳細に説明するように、 I P電話通話中は初期設定されているメール受信間隔より短い間隔でメー ルを取りに行くことができる。これはいちいちリロードボタン 21 5 bを押 さなくても、端末 Aで WEBページが更新されるごとに（端末 Aにおける自 動制御あるいは明示的な手動操作に基づき） 送られる URL通知メールを、 大きな遅延なしに受信してページの更新に追従することができる。

URL通知メールを受信 （S 2543) した端末 Bは、受信したメールテ キストを解析し、 メール中の URLを抽出する （S 2544) 。

その後、図 20〜図 21において、端末 Bで行なわれる WE Bページの表 示シーケンス （S 2546〜S 256 9) は、 図 8〜図 9のシーケンス （S 546〜S 569) と同様である。

図 22は端末 A側の、 図 23は端末 B側の制御手順を示している。

図 22において、ダイヤル操作を行ない、 I NV I TEメッセージを送信 して S I Pサーバ 1 10に接続すると （S 260 1) 、 S I Pサーバ 1 1 0 は相手先端末の呼び出しを行なうとともに、 r i n g i n gを送信端末に返 すので、 相手先端末が応答するのを待つ （S 2602) 。 相手先端末が応答 すると、 OKメッセージと相手先端末の電話番号に対応する I Pアドレスを 送信端末に返すので、送信端末は相手先の I Pァドレスを取得して RAM 2 03に一時格納し （S 2603) 、 その後、 I P電話の通話状態に入る （S 2604) 。

端末 Aにおいて WEBページを表示させるためにブラゥザを起動し（S 2

605) 、 ブラウザに URLを入力すると、 UR Lで指定された WE Bサー パ 1 1 3のアドレスを DNSサーバ 1 1 2に問い合わせ、検索結果を受信す る （S 2606) 。 そして DNSサーバ 1 1 2から得た I Pァドレスを元に WEBサーバ 1 1 3にアクセスして目的の WEBページのデータを受信し (S 2607) 、 ブラウザに WEBページを表示させる （S 2608) 。 本実施形態では、 前述のように、 URLデータをメールにより送信する。 URLをメールで転送するため、 URLを記述レたメールを作成する （S 2 609) 。 本実施形態では "URL t o ：く WEBページの URL〉" とレヽ うテキストデータをメール本文中に書き込んだメールを作成している。ただ し、 URLの記載方法は送信側と受信側とで同じ規格で行われていれば、特 にこれに限ったものでなくてもよく、 表題 （S u b j e c t ：ヘッダ） に U R Lを書いても構わないし、 "URL t 0 ：く WE Bページの URL "の ような形式でなくても構わない。つづいて、 RAM203内にある I Pアド レスとメールァドレス対応表を用いて、ステップ S 2603で取得した相手 先 I Pァドレスをもとに、相手先のメールアドレスを検索する（S 26 10)。 検索した結果メールァドレスが見つかればステップ S 26 1 2以降のメー ル送信を行い、見つからなければメールは送信できないので、通話を続けな .がら、 最終的にはステップ S 26 15に進み、 ブラウザを終了させる （S 2 6 1 1) 。

ステップ S 26 1 1でメールァドレスが見つかったら、ステップ S 26 1

2で見つかったメールァドレスを宛先として作成した UR L通知メールを 送信する要求をメールサーバ 1 14に送信する （S 26 1 2)。 メールサー パ 1 14では、送信元である送信端末のドメイン、送信先のメールア ドレス などをチェックして、 メール送信を許可するかどうかを判断する。送信端末 ではメールサーバ 1 14から OKメッセージがくるか否かを待つ（S 26 1 3) 。 ステップ S 26 1 3で OKメッセージを受信すれば、 メールを送信し (S 26 14) 、通話を続け、受信しなければメールを送信しないで通話を 続け、晕終的にはステップ S 26 15に進み、 ブラウザを終了させる。 もち ろん他の WEBページにアクセスして、もう一度ステップ S 2606からの 処理を行なうことが可能であることはいうまでもない。

通話を終了するときは、オンフックにすることによって送信端末は S I P サーバ 1 1 0に BYEコマンドを送信して通話を終了する （S 261 6) 。 もちろん相手先に切断されたことを BYEコマンドの受信によって検出す ると通話を終了することは言うまでもない。

一方、端末 B側では、スタンパイ状態では着信があるかどうか監視をして いる （図 23の S 2701) 。 I NV I T Eコマンドの受信によって着信を 検出すると、 着信に応答し OKコマンドを返し （S 2702) 、 通話状態に 入る （S 2703) 。

この通話中、設定されている受信メール取得時間になったか（S 2704)、 ， およぴリロードボタン 21 5 bによる受信メール取得操作がある力 （S 27 05) をチェックする。 この種の機器では、 デフォルトのメール受信間隔は 1 5分程度とするが、 ユーザの設定によってこの時間は変更可能である。 なお、後述の通り、 本実施形態では URLデータの転送後、 メール受信間 隔をより短い時間に短縮するが、 I P電話の通話開始直後から （たとえば S 2703において） このメール受信間隔の短縮を行なってもよい。

受信メール取得時間でもなく （ S 2704 ) 、 リロードボタン入力もなけ れば（S 2705) 、 通話が切断されたかを BYEコマンドを受信するか否 かでチェックし （S 271 7) 、 通話が切断していなければ、 通話状態を保 持する。

受信メール取得時間であるか（ステップ S 2704) 、 リロードポタン入 力 （S 2705) があると、 POPサーバ 1 1 5に接続して受信メール確認 コマンドを送出する （S 2706)。 卩0?サーバ1 1 5からの返信コマン ドによって、 受信メールがあるか否かをチェックして （S 2707) 、 受信 メールがなければ通話が切断されたか否かをチ πック （S 271 7) する。

?0?サーバ1 1 5に受信メールがあれば、受信メール取得コマンドを P OPサーバ 1 1 5に送出して、 POPサーバ 1 1 5から受信メールを転送さ せる （S 2708) 。

そして、 0?サーパ1 1 5かち受信したメールの中（当然複数のメール を受信することもある） に URLを通知するメールがあるかを判定（S 27 09)する。 この判定は、 メール本文中に前述の "URL t o ： <URL>" の記述があるか否かチェックすることにより行なう。上記のようにして端末 Aから送られた URL通知メールがあれば、 そのメールの "URL t o ： " タグから URL文字列を抽出する （S 271 0) 。

URL通知のメールを受信すると、 この通話中に、たとえば送信側で WE Bページの更新があって、新たな URLが通知されてくることが頻繁に起こ ることが想定される。 この場合に設定値（デフォルトはたとえば 1 5分） の ままだと、端末 A側で WEBページが更新されるたぴに、端末 A側の通話音 声にしたがって通話中の音声によってページが更新されたことを聞いた上 で、リロードボタン 2 1 5 bを操作しなければ新しい URLを受信できない ので、本実施形態では、 受信メール取得時間を 1分（あるいはより短い時間 でもよい） に変更する （S 27 1 1) 。 もちろん、 先に触れたように、 I P 通話開始直後（たとえば S 2703) からこの受信メール取得時間短縮を行 なっている場合にはこの処理は必要ない。

続いて WEBページを表示させるためにブラゥザを起動し、 （S 27 1 2) URL通知メールの "URL t o : " タグから抽出した URL文字列を WE Bブラゥザに入力する。端末 Bは UR Lで指定された WE Bサーバ 1 1 3のアドレスを DNSサーバ 1 1 2に問い合わせ、検索結果を受信する （S 27 1 3)。続いて DNSサーバ 1 1 2から得た I Pァドレスを元に WE B サーバ 1 1 3にアクセスし、 WE Bページのデータを受信し（ S 27 14)、 ブラゥザに WE Bページを表示させる (S 27 1 5) 。 その後、 ブラゥザの 閲覧が必要なくなったらブラウザを終了させる （S 27 1 6) 。

通話の終了は BYEコマンドを受信するか否かでチェックする（S 27 1

7)。相手先に通話を切断されたことを検出すると OKコマンドを返して通 話を終了し、 オンフック状態に復帰する （S 271 8) 。 その後、 ステップ S 271 1で変更し 受信メール取得間隔を設定値に戻し （S 27 1 9) 、 処理を終了する。

なお、 ここでは URLの送信側で "URL t o ：く WEBページの URL

〉，' というテキストデータをメール本文中に書き込んだメールを作成し、 ' 受信側で受信したメールの中 （当然複数のメールを受信することもある） に 前述の "URL t o ： <URL>"の記述があるか否かチェックすることで 同一のインターネットリソースの共有利用を実施した。しかしこれに限らず、 送信側で図 3 1に示される S OAPメッセージをもつ実行ファイルを添付 したメールを作成して送信し、受信側で S O A Pメッセージをもつ実行ファ ィルを受信したかどうかをチェックすることで S OAPを用いるようにす ることも可能である。

以上のようにして、 I P電話で通話中の端末どうしでインターネットリソ ースを共有することができ、実施形態 1と同様に従来の I P電話通信中の音 声によるインターネットリソースの伝達と異なり、相互に正しくインターネ ットリソースの情報が伝わり、確実に同じインターネットリソースを利用で き、 また、 URLなどのデータ再入力などの操作を省略できるため、 操作性 を向上できる。

本実施形態 2によれば、 URLデータの転送に Eメールを用いている。 メ ール送受信の機能はこの種の装置に設けられることが多いため、ハードゥエ ァ Zソフトウェア構成を大きく変更せずに実施することができる。 また、上 記のようにメール受信間隔を短縮する （I P通話開始直後から、 あるいは最 初の URL通知メールを受信した後) ことにより、大きなタイムラグを生じ ることなくインターネットリソースを共有利用することができる。

なお、実施形態 1で述べた種々の変形例は、実施形態 1との URLデータ の転送方式の差異に関係するものでなければいずれも同様に本実施形態 2 においても通用するのはいうまでもない。

実施形態 3

以上では、 URLデータの転送方式に FTP、 あるいは Eメールプロ トコ ル （SMTP) を用いる例を示した。 本実施形態では、 HTTPプロキシ技 術を用いて URLデータを転送する。

HTTPプロキシサーバに関しては、 HTTP— l . 1に関しては RFC 2616に記載されている。 HTTPプロキシサーバは、 HTTPクライア ントに代って HTT Pサーバにアクセスし、目的の HTT Pデータを取得し、 HTTPクライアントに転送するもので、 HTTPデータをキヤッシュする こともでき、 これにより HTTPトラフィックを軽減したり、 あるいは HT TPクライアントの情報 （I Pァドレスその他のブラウザが提供可能な情 報） を H T T Pサーバから隠すなどの目的で広く利用されている。

本実施形態では、 I P電話の通話中の相手とインターネットリソースを共 有利用したい場合、一方の端末が HTTPプロキシサーバとして機能するこ とにより相手にィンターネットリソースデータそのものを送信する。したが つて、本実施形態では、インターネットリソースの所在を示す URLデータ を転送するのではなく、既に取得済みのインターネットリソース自体を通話 相手に転送する。

本実施形態でも、通信端末およびネットワークの構成は図 1〜図 4に示し たものと同様であるものとし、以下のシーケンス図おょぴフローチャートに おいても上記実施形態 1と同様に通信端末 A(200)および通信端末 B (2 20) の間の通信につき説明する。

図 24およぴ図 25は、端末 Aと端末 Bが I P電話により通話中、端末 A が WEBページを取得し、端末 Aが HTTPプロキシサーバ、端末 Bが HT TPクライアントとなり WEBページを共有利用する様子を示している。 図 24の S 3 70 1〜S 3704は I P電話による通話を開始するまで の処理である。 まず、 端末 Aが端末 Bを発呼する （もちろん、 この発呼方向 は逆であっても構わない） 。

端末 Aはダイヤル操作を行い S I Pサーバ 1 1 0に接続する （S 3 70 1)。前述同様に S I Pサーバ 1 10は相手先端末の呼び出しを行なうとと もに、 端末 Aに相手先の端末 Bの電話番号に対応する I Pァドレスを返す (S 3702) 。 端末 Aは呼び出し中状態になり、端末 Bが応答するのを待 つ （S 3.703) 。 端末 Bが応答すると通話状態になる （S 3704) 。 一方、 端末 Bはスタンパイ状態では着信があるかどうか監視をしている (S 371 1) 。 着信を検出すると端末 Bは着信に応答し （S 3 7 1 2) 、 通話状態になる （S 3704) 。 本実施形態では、端末 Bにおいて ^ある WE Bページを閲覧する需要が発 生し、 その WE Bページを端末 Aで共有利用 （閲覧） させたい場合の処理を 説明する。.この場合、 端末 Bでブラウザを起動し （S 3713) 、 目的の W EBページの URLを入力して、 （普通の閲覧操作ではなく） リソース共有 ボタン 215 aを操作する。

これにより、端末 Bは端末 Aを HTTPプロキシサーバ、 自端末をクライ アントとして、 端末 Aにアクセスする。 すなわち、 端末 Aと同期を取り、 表 示したい WE Bページをプロキシサーバに要求する （S 3714)。 この H TTPプロキシ手順については、 後でより詳細に説明する。 ， 端末 Aは、 HTTPクライアントとしての端末 Bからのアクセスを監視

(S 3705) しており、端末 Bからアクセスが行われると、端末 Bと同期 を取り WE Bページ要求を受け取り、端末 Bが表示したい URL情報を取得 する （S 3706) 。

端末 Aは、取得した URL情報を用いて WE Bサーバ 1 13にアクセスし (S 3707)、端末 Bが要求した WE Bデータを取得する（S 3708)。 取得した WE Bデータは端末 Aのキャッシュに保存されるとともに、 HTT Pクライアントとしての端末 Bにも WE Bページ要求に対する応答として 転送する （S 3709) 。

また、端末 Aはブラゥザを起動させ、端末 Bから要求された WE Bページ を表示させる （S 3710) 。 ただし、 端末 Aにおける表示は必ずしも必須 のものではない。一方、端末 Bはプロキシサーバとしての端末 Aからの応答 を待ち （S 3715) 、 プロキシサーバから WE Bデータを取得し （S 37 16) 、 取得した WE Bページを表示させる （S 3717) 。 閲覧が終った ら、端末 Aないし Bはブラウザを終了させる （図 25の S 3718、 S 37 20) ₀

本実施形態では、端末 Bとの通話が終了すると端末 Aから通話を切断して いる （S 37 1 9) 。 端末 Bでは、 端末からの切断を検出 （S 3721) す るとオンフック処理を行ない通話を切断する （S 3722) 。 この切断シー ケンスにおいて、 端末 Aおよび Bの動作は図示と逆であってもよい。

また、 以上では、端末 Aが HTTPプロキシサーバとして、 端末 Bが HT TPクライアントとして動作し、端末 Bから WEBページを要求している力 これらの役割は逆であってもかまわない。

図 26は、端末 Aから端末 Bへ呼接続するときのシーケンス図である。発 呼側の端末 Aは I S Pサーバ 1 10に接続可能で、被呼側の端末 Bも I S P サーバ 1 10に接続可能である。 I S Pサーバ 1 10は S I Pサーバ、 ロケ ーシヨンサーバ、 DN Sサーバなどから構成され、お互いにインターネット で接続されている。

まず端末 Aにおいて操作部 21 5からダイヤル操作を行なう。前述の各実 施形態同様、これにより端末 Aから S I Pサーバ 1 10を介して I NV I T Eメッセージが送信され、端末 Bとの通話状態が形成される （S 4005〜 S 40 1 2) 。 端末 Aおよび Bは相互の I Pァドレスを認識する。

図 27は、通話開始後、上記のようにして端末 Aが HTTPプロキシサー パとして、端末 Bが HTTPクライアントとして動作し、端末 Bから WE B ページを要求する際の HTTPバケツトのやり取りを示している。また、図 28〜図 30は各 HTT Pバケツトの構成を示している。

図 27のシーケンスには 4000番台のステップ（シーケンス）番号が用 いられ、図 28〜図 30では 5000番台の参照符号が用いられている。以 下の説明では 「 （S 4 X X X ·· 5 X X X) 」 の形式で、 各図のステップおよ ぴパケット （ないしその内部構成） との対応を示す。

まず、図 28により HTTPパケットの構成を説明する。 図 29およぴ図 30のパケットは図 28の構造を有する。図 28は TCP/ I Pで用いられ るバケツトの一般的な構成を示しており、図示のように、 TCP/I Pパケ ットは I Pヘッダ部 5 0 0 1と I Pデータ部 5 0 0 2力、ら成る。 I Pヘッダ 部 5 00 1には送信元の I Pアドレス 5 0 0 8、送信先の I Pアドレス 5 0 0 9などが記述される。

I Pデータ部 5 0 0 2は、さらに TCPヘッダ部 5 0 0 3と TCPデータ 部 5 004から成り、 TC Pヘッダ部 5 0 0 3には送信元ポート番号 5 0 0 5、送信先ポート番号 5 0 0 6、 TCPバケツトのタイプなどを示すコント ロールフラグ 5 00 7などが記述される。 '

以下、 図 2 7、 図 2 9、 およぴ図 3 0を参照して、 端末 Aがプロキシサー パ、端末 Bがクライアントとなり、同一の WE Bページを共有利用する際の 動作を説明する。

プロキシサーバとして機能する端末 Aは、 WEBサーバ 1 1 3、および H TTPクライアントとして動作する端末 Bとの間でそれぞれ HTTPデー タを送受信するために、データ送受信用の 2つのポートを用いる。 図 2 7で は、 端末 Aを端末 A— 1、 および端末 A— 2として示しているが、 この 2つ の表示は上記のデータ送受信用の 2つのポートに対応するものである。 TC P/ 1 Pでは、ポート番号は相手と同期を取ってから役割を終えるまでの一 連の流れが終ると、次には違うポート番号が使用される。 HTTPクライア ントとして動作する端末 Bも複数のポートを用いることができるが、本実施 形態の H TTP通信では 1つのみ用いる。

まず、端末 Bは WE Bページを表示させるため、 プロキシサーバとしての 端末 Aと同期を取る。すなわち、端末 Aのポート番号 1 3 0 3は HTTPポ ートである 80番を使用し、端末 Bから SYNバケツトを送信すると （S 4· 3 0 5 . 5 3 0 5)、端末 Aは S YN · ACKパケットを返し （S 4 3 0 6 · 5 3 0 6) 、 これに応じて端末 Bから AC Kバケツトが送信される （S 4 3 0 7 · '5 3 0 7) 。 この後、 端末 Bと端末 Aは HTTP通信を行なうことが できる。 この後の端末 Bと端末 Aとの間の TCPパケットのやりとりでは、 端末 Bは TCPデータ部 5004に HTTPコマンドを記述し、端末 Aは T CPデータ部 5004にそれに対する応答を記述することになる。

端末 Bは端末 Aに HTTPで WEBデータの要求を行なう （S 4308 · 5308)。 この TCPパケット 5308により端末 Bから端末 Aに U R L 情報が伝達される。

プロキシサーバとして機能する端末 Aは、端末 Bに変わって WE Bサーバ 1 1 3に WE Bページのデータを要求する。端末 Aは端末 Bとの通信で使つ ているポートとは異なるポート 1 302を用意し WEBサーバと同期を取 る。 すなわち、 端末 Aから S YNバケツトを送信 （S 4309 · 5309) すると、 WE Bサーバ 1 1 3は SYN'ACKバケツトを返し（S 43 10 · 53 1 0) 、 端末 Aは AC Kパケットを返す （S 43 1 1 ' 53 1 1) 。 こ の後、 端末 Aと WE Bサーバ 1 1 3は HTTP通信を行なうことができる。 上記同様に、 WE Bサーバ 1 1 3端末 Aとの間の TC Pバケツトのやりとり では、端末 Aは TCPデータ部 5004に HTTPコマンドを記述し、 WE Bサーバは TCPデータ部 5004にそれに対する応答を記述する。

その後、 端末 Aは WE Bサーバに HTT Pで WE Bデータの要求を行い (S 43 1 2 - 53 1 2) , 目的の WE Bデータを受信する （S 43 1 3 · 53 1 3)。端末 Aはこれに対して AC Kを返す（S 43 14 * 53 14)。 端末 Aは WE Bデータをメモリに記憶するとともに、端末 Bに WE Bデータ 要求の応答として転送する （S 43 1 5 * 53 15) 。 端末 Bはこれに対し て AC Kを返す （S 43 1 6 · 53 1 6) 。

端末 Aは WE Bサーバから受信した WE Bページを表示し（S 431 7)、 端末 Bは端末 Aから受けた WE Bページを表示する （S 43 1 8) 。

以上のようにして、 I P電話で通話中の端末どうしでィンターネットリソ ースを共有することができる。従来の I P電話通信中の音声によるインター ネットリソースの伝達と異なり、相互に正しくイ ターネットリソースその ものの情報が伝達され、確実に同じインターネットリソースを利用でき、ま た、 U R Lなどのデータ再入力などの操作を省略できるため、操作性を向上 できる。

なお、実施形態 1で述べた種々の変形例は、実施形態 1 との U R Lデータ の転送方式の差異に関係するものでなければいずれも同様に本実施形態 3 においても通用するのはいうまでもない。

本発明を実現するソフトウ アは、 I P網に接続し、所定の I P電話方式 により通話を行なう任意の形式の通信端末に適用でき、その通信端末の C P Uのプログラムとして R OMやその他の記憶媒体などに格納してあらかじ め格納しておく他、 外部記憶媒体 （C D— R OMやフレキシブルディスク、 MOなど） を介して供給する、 あるいは、 ネットワーク経由で供給すること ができる。 特に、ネットワーク経由で供給する場合には、前述のようにイン ターネットリソースとして F T Pサーバや H T T Pサーバに通信端末のフ アームウェア （あるいは付加的なソフトウェア） として配置し、本発明の通 信方法を介して通信端末にダゥンロードし、さらに S O A P手順などを介し てその通信端末にインストールすることができる。

以上の説明から明らかなように、実施形態 1〜3によれば、 I P網に接続 し、所定の I P電話方式により通話を行なう通信端末、 その制御方法、 およ ぴその制御プログラムにおいて、通話中の相手通信端末と、同一のインター ネットリソースを共有利用するためのィンターネットリソース共有手段な いし制御過程を含む構成を採用しているので、従来の音声によるインターネ ットリソースの伝達と異なり、相互に正しくインタ ネットリソース （ない しその所在情報） を伝達でき、確実に同じインターネットリソースを利用で き、また、 U R Lなどのデータ再入力などの操作を省略できるという優れた 効果がある。 すなわち、本発明によれば、他の機器を用いることなく通話端 末のみにより I P電話で通話中の相手とインターネットリソースを簡単安 価に、また面倒な操作を必要とせず確実に共有できる、 という優れた効果が 得られる。

実施形態 4

図 5およぴ図 6は本実施形態における I P電話通信の様子を示している。 本実施形態の I P電話通信では、図 1および図 2のように構成された通信端 末 A (200)から通信端末 B (220)へ呼接続し、通話を行なう。また、 本実施形態では、端末 Aで WE Bブラウジングを行なうとともに、 I P電話 通信中に通信端末 Aから通信端末 Bにその URLデータを転送し、通信端末 (以下単に 「端末」 とも記す） Aおよび Bとの間で同一の WE B情報を共有 できるようにする。図示の通信手順は図 1の CPU 20 1が通信制御プログ ラムを実行することにより実現される。この CPU 20 1の通信制御プログ ラムは ROM202 (あるいは他の記憶媒体） に格納される。 本実施形態で も、通信端末およぴネットワークの構成は図 1〜図 4に示したものと同様で あるものとし、以下のシーケンス図およびフローチャートにおいても上記実 施形態 1と同様に通信端末 A (200) および通信端末 B (220) の間の 通信につき説明する。

なお、 以下の説明において、 端末間の発呼方向は Aから Bとし、 また、 W ' EBデータの転送方向も Aから Bであるものとする力 これらの発呼方向お よぴ W E Bデータの転送方向は一例にすぎず、 任意である。

まず、端末 Aが I P電話の発呼操作を行なう。 端末 Aのダイヤル操作 （図 5の S 801)により S I Pサーバ 1 1 0を用いて I P電話の呼接続処理が 行なわれる。上述の通り、 S I Pサーバ 1 1 0は相手先端末の呼び出しを行 なうとともに、端耒 Aに相手先端末の電話番号に対応する I Pアドレスを返 す （S 802) 。 端末 Aは呼び出し中状態になり.、 相手先端末が応答するの を待つ（S 803)。相手先端末が応答すると通話状態になる（S 804)。 端末 Aは WE Bページを表示させるためにブラウザを起動する （S 80 5)。 端末 Aのブラウザに URLを入力すると、端末 Aは URLで指定され た WE Bサーバ 1 1 3のァドレスを DNSサーバ 1 12に問い合わせ、検索 結果を受信する （S 806) 。 端末 Aは DNSサーバ 1 12から得た I Pァ ドレスに基づき WE Bサーバ 1 1 3にアクセスして WE Bページのデータ を受信し（S 807)、ブラウザに WE Bページを表示させる（S 808)。 本実施形態では、端末 Aは相手先端末に自分が表示させた WE Bページを 送信するために、後述のように HTTPアクセスの際に送信する TCPパケ ットの送信元 I Pア ドレスに S I Pサーバ 1 10から得た相手先端末の I Pアドレスを使用することにより、データ要求は端末 Aから行なうが、 WE Bデータは相手の端末 Bに送信されるよう制御する。

すなわち、端末 Aは相手先端末に自分が表示させた WE Bページを送信す るために、 再度 WE Bサ バ 113にアクセスを行なう （S 809) 。 この とき WE Bサーバに WE Bデータの要求を行なう際の送信元 I Pアドレス には S I Pサーバから得た相手先端末の I Pァドレスを使用することによ り WEBサーバ 1 1 3の応答は端末 Bに送信される。

ブラウザを閲覧し終えた端末 Aはブラウザを終了させ（図 6の S 815)、 相手端末との通話が終了すると通話を切断する （S 816) 。 あるいは、 相 手端末からの切断を検出すると通話を終了する。

一方、 端末 B側の処理は次のように行なわれる。

端末 Bはスタンパイ状態において、 着信があるかどうか監視をしている

(図 5の S 810)。着信を検出すると端末 Bは着信に応答し（S 81 1)、 ' 通話状館になる （S 804) 。

通話中、 端末 Bは WE Bサーバからの受信を監視する （S 812) 。 上記 のようにして端末 Aが WE Bサーバ 1 13にアクセスする（S 809)ので、 端末 Aが要求した WE Bデータは WE Bサーバ 1 1 3から端末 Bに送信さ れる。 WEBサーバからデータを受信すると、端末 Bは受信データを解析す る。受信したデータが WEBデータであった場合、ブラウザが起動されてい ない場合はブラゥザを起動し （S 813) 、 WE Bページを表示する （S 8 14) 。

ブラウザを閲覧し終えると端末 Bはブラウザを終了させる（図 6の S 81 7) 。 また相手先との通信状態を監視していて （S 818) 、 相手先に切断 されたことを検出すると通話を終了する （S 819) 。 あるいは自端末から 通話を切断する。

図 7およぴ図 8は、 上記の I P電話通信シーケンスの概略を示している。 図 7およぴ図 8のシーケンスは図 5〜図 6の通信制御に対応するもので、上 記同様、図 1の CPU201が通信制御プログラムを実行することにより実 現される。また、図 9〜図 1 1は図 7および図 8のシーケンスで用いられる 各 HTTPバケツトの構成を示している。

図 7〜図 8の各シーケンスには符号 S 1000番台と S 1200番台の ステップ（シーケンス）番号が用いられ、 図 9〜図 11では 2000番台の 参照符号が用いられている。 以下の説明では r (S 12 x x - 2 x x ) j の形式で、各図のステップおよび TC Pパケット （ないしその内部構成） と の対応を示す。

また、 図 7およぴ図 8では、簡略化のため、端末 Aおよび Bのそれぞれの I S Pにより提供される上述の S I Pサーバ、 ロケーションサーバ、 DN S サーバなどの各サーバを I S Pサーバ 1002、 1003として示している。 図 7およぴ図 8のシーケンスを説明する前に、図 9により TCPバケツト の構成を説明する。 図 10および図 1 1のパケットは図 9の構造を有する。 図 9は TCP/ I Pで用いられるパケットの一般的な構成を示しており、図 示のように、 TCP/ I Pバケツトは I Pヘッダ部 2001と I Pデータ部 2002力 ら成る。 I Pヘッダ部 2001には送信元の I Pァドレス 200 8、 送信先の I Pアドレス 2009などが記述される。 I Pデータ部 2002は、さらに TC Pヘッダ部 2003と TCPデータ 部 2004から成り、 TCPヘッダ部 2003には送信元ポート番号 200 5、送信先ポート番号 2006、 TC Pパケットのタイプなどを示すコント ロールフラグ 2007などが記述される。

以下、 図 7および図 8のシーケンスを説明する。

まず端末 Aにおいて操作部 21 5か.らダイヤル操作を行なう。これにより 端末 A (200) は端末 Aの I S Pサーバ 1 002に接続される （図 7の S 1 005)。端末 Aの I S Pサーバ 1002 (実際には上述のように S I P、 DNSサーバなどが動作する） は通話相手である端末 B (200) の I Pァ ドレスを検索し （S 1006) 、検索結果の I Pァドレスに対して発呼パケ ットを送信する （S 1007) 。

この発呼バケツトを受信すると、端末 Bの I S Pサーバ 1 003 (実際に は上述のように S I P、 DNSサーバなどが動作する） は端末 B (220) を呼び出す （S 1008) 。 端末 Bが応答すると （S 1009) 、 端末 Bの I S Pサーバ 1 003は端末 Aの I S Pサーバ 1 002に接続バケツトを 返す （ S 1010 ) 。 端末 Aの I S Pサーバ 1002が端末 A 100 1に応 答を返すと呼接続が完了し、このとき端末 Aに端末 Bの I Pアドレスが通知 される （S 101 1) 。 その後、 端末 Aおよび端末 Bは通話状態になり、 音 声パケットのやり取りが行われる （S 101 2) 。 この I P電話通信は、 リ アルタイム性を重視して通常、メッセージを含めて UD Pベースで行なわれ る。ただし、 TC Pベースの H 323等の呼接続方法も利用することができ、 I P電話通信の方式は任意である。

次に、図 8を参照して端末 Aが WE Bサーバ 1 1 3から得た WE Bデータ を端末 Bと共有する際のシーケンスを説明する。図 8では、端末 Aを端末 A — 1、および端末 A— 2として示しているが、 この 2つの表示はデータ送受 信用の 2つのポートに対応するものである。 TCP/I Pでは、ポート番号 は相手と同期を取ってから役割を終えるまでの一連の流れが終ると、次には 違うポート番号が使用される。 HTTPクライアントとして動作する端末 B も複数のポートを用いることができる力 S、本実施形態の HTT P通信では 1 つのみ用いる。

端末 Aは自端末に WE Bページを表示させるために、データ用のポート 1

20 1と WEBサーバと同期を取る。端末 Aから WEBサーバに S YNパケ ットを送信し （S 1 205 ' 2205) 、 WEBサーバから SYN · ACK バケツトを受信する （S 1 206 ' 2206) 。 端末 Aはこれに対して AC Kバケツトを返す （S 1 207 ' 2207) 。 これにより端末 Aのポート 1 201と WE Bサーバは HTTP通信を行なうことができる。

端末 Aは WE Bサーバに WE Bページの要求を行い（S 1 208 . 220 8) 、 WE Bデータを受信する （S 1 209 * 2209) 。 端末 Aはこれに 対して AC Kバケツトを返し （S 1 2 10 * 2210) 、 受信した WEBぺ ージを表示する (S 1 21 1) 。

端末 Aは端末 Bにも WE Bページを表示させるために、再度 WE Bァクセ スを行なう。 これ以降の動作は、端末 Aで操作部 21 5のリソース転送ボタ ン 21 5 aを操作することにより開始される。リソース転送ボタン 21 5 a は、通話中の相手に同じ WEBページを表示させたい時にその都度押下する 構成の他、 リソース転送ボタン 21 5 aの押下により、 それ以後、後述のィ ンターネットリソース共有動作を常に行なうインターネットリソース共有 モードに入るようにしてもよい。 また、 I P電話の通話開始後は、 自動的に このようなインターネットリソース共有モードに入るようにしてもよい。 以下のインターネットリソース共有（本実施形態では同一 WE Bページの ブラウジング） は、端末 Aで新しい WE Bページを読み込むごとに自動的に 実行することができる。

まず、端末 Aはデータ用のポート 1 202と WE Bサーバとの同期を取る。 このとき使用するポート番号は、端末 Bで使用可能なものを使用する。端末 Aから WE Bサーバに SYNバケツトを送信し （S 1 2 1 2、 22 1 2) 、 WEBサーバから SYN · ACKパケットを受信する （S 1 21 3 . 22 1 3)。端末 Aはこれに対して ACKバケツトを返す（S 1 2 14 * 2214)。 これにより端末 Aのポート 1 202と WE Bサーバは HTT P通信を行な うことができる。

さらに端末 Aは WE Bサーバに WE Bページの要求を行なう。このとき I Pヘッダの送信元ァドレスに端末 Bの I Pァドレスを入れる （S 1 21 5 · 221 5)。 WEBサーバはこの要求に対して WEBページのデータを要求 元の I Pァドレスに送信することになる （S 1 21 6 * 2216) 。 WEB データを受信した端末 Bは WEBサーバに ACKパケットを返し（S 1 2 1 7 - 221 7) 、 端末 Bは WEBページを表示させる （S 1 21 8) 。 なお、本実施形態では、バケツトの送信元ァドレスの書き変えによって送 信されてくる WE Bページを受信する端末 Bのブラウザ（あるいはさらにそ のブラゥザが動作しているオペレーティングシステムの TC P / I Pスタ ック） は、 自己が要求していない WE Bデータを受信し、 さらに表示 （ある いは他の形 での出力）できる必要がある。このために、 I P電話通信中は、 端末 B (あるいは A： WE Bデータの受信側） のオペレーティングシステム は、 自機宛に送信された WE Bデータが自機のブラウザ（必要であればその 起動も行なう） に送り込まれるように制御する必要がある。

以上のようにして、 I P電話で通話中の端末どうしでィンターネットリソ ースを共有することができる。従来の I P電話通信中の音声によるインター ネットリソースの伝達と異なり、相互に正しくインターネットリソースその ものの情報が伝達され、確実に同じインターネ.ットリソースを利用でき、ま た、 URLなどのデータ再入力などの操作を省略できるため、操作性を向上 できる。 これによつて、 I P電話通信中に通信している端末どうしで同じインター ネットリソースを利用 （上記実施形態の場合表示であるが、下記のファーム ウェアの更新の場合のように共有するインターネットリソースの利用方法 は表示に限定されるものではない） させることができ、従来の I P電話通信 中の音声によるインターネットリソースの伝達と異なり、相互に正しくイン ターネットリソースの情報が伝わり、確実に同じインターネットリソースを 利用でき、 また、 U R Lなどのデータ再入力などの操作を省略できるため、 操作性を向上できる。

また、上記実施形態では、相手端末と共有する WE Bページのアクセスの 時、 送信元 I Pアドレスを書き変え、 WE Bサーバから直接、 目的の WE B ページが相手端末に送信されるように制御しているため、目的の WE Bぺー ジデータそのもの、あるいはその U R Lデータなどを相手端末に送信するよ うな通信制御に比してシーケンスのステップ数が極めて少なくて済み、高速 かつ効率的な通信を行なうことができる。特に、 WE Bデータの受信側では、 特別な操作を必要とせず、自動的にその U R Lで示されるインターネットリ ソースをプラウズすることができる。

以上では、 I P電話通信中の第 1および第 2の端末で共有するインターネ ットリソースとして WE Bページを考えたが、 U R L (あるいは U R I ) な いしこれと同等のィンターネットリソースの所在を示す情報形式（F T Pで 送信できさえすればよい）で表現できるインターネットリソースであればど のようなものでも第 1および第 2の端末で共有することができる。本発明に より共有できるインターネットリソースは、 ブラゥザベースで利用できる - (あるいは U R L形式で表現可能な）ものであれば F T Pディレクトリやそ のディレクトリ中のファイル、 G o p h e rページ、音声やビデオ（静止画 /動画） ス トリームを提供する各種のサービスなど、 数限りない。

本発明のィンターネットリソース共有技術は、ビジネスや娯楽のための情 報共有に広く用いることができる。特に本発明の通信機器の製品展開などに 有用と考えられるのは、本発明の通信端末のファームウェアのアップデート などに利用することである。 たとえば、本発明の通信端末のユーザがトラプ ルに遭遇し、 I P電話でメーカーのサポート窓口に電話し、 相談した結果、 通信端末のファームウェアの更新が必要、 という結論に達した場合、 メーカ 一のサポート要員が直接そのユーザの通信端末にファームウェア（たとえば H T T Pや F T Pで取得可能なファイルで、通常メーカーが運営する H T T Pサーバ/ F T Pサーバから提供される） の U R Lを送信し、 ファームゥェ ァのアップデートを行なうことができる。多くのブラウザに実装されている ソフトウヱアインストール機能などを利用すれば、ファームウェアのアップ デートのような受信側のファイルの取り扱いは任意に指定できるので、ユー ザ操作を一切必要とせず通信端末のファームウェアのアツプデートを行な うことができる。

本発明を実現するソフトウエアは、 I P網に接続し、所定の I P電話方式 により通話を行なう任意の形式の通信端末に適用でき、その通信端末の C P Uのプログラムとして R O Mやその他の記憶媒体などに格納してあらかじ め格納しておく他、 外部記憶媒体 （C D— R OMやフレキシブルディスク、 MOなど） を介して供給する、 あるいは、 ネットワーク経由で供給すること ができる。 特に、 ネットワーク経由で供給する場合には、 上記のようにイン ターネットリソースとして F T Pサーバや H T T Pサーバに通信端末のフ アームウェア （あるいは付加的なソフトウェア） として配置し、 本発明の通 信方法を介して通信端末にダウンロードし、さらに多くの WE Bブラウザに 実装されているソフトウエアインストール機能などを利用してその通信端 末に自動的にインス トールすることができる。

, 以上では、 送信元 I Pアドレスを書き変え、 WE Bサーバから直接、 目的 の W Bページが相手端末に送信されるように制御することにより、通話中 の端末どうしで同一のィンターネットリソースを共有利用する構成を示し たが、インターネットリソースを共有利用するための構成はこのようなもの に限らず、 F T Pや H T T Pプロトコルで目的のインターネットリソースの U R L情報を相手端末に転送したり、あるいはダウンロードしたインターネ ットリソースデータそのものを転送することによつても、このような共有利 用が可能であるのはいうまでもない。これらの情報を通話相手の端末に転送 するには、 I P電話手順により相手の I Pァドレスが判明しているため、上 述のリソース転送ボタンの操作や、インターネットリソース共有モードの設 定により相手の I Pァドレスとの間に F T Pや H T T Pコネクションを成 立させることができるから、このようなコネクションを介してインターネッ トリソースの U R L情報やそのデータそのものを容易に転送することがで さる。

また、インターネットリソースの共有動作は、 リソース転送ボタンめ操作 により極めて容易に実行でき、あるいはインターネットリソース共有モード を設定可能とする（リソース転送ボタンの明示的な操作により当該モードに 入る、 あるいは I P電話の通話開始後、 自動的に当該モードに入る） ことに より面倒な操作をさらに省略でき、ユーザを選ぶことなく容易にインターネ ットリソース共有動作を行なうができる。

インターネットリソース共有動作に必要な相手の I Pァドレスは、特別な ハードウエアゃソフトウエアを必要とせず I P電話手順により取得するこ とができる。

以上の説明から明らかなように、 実施形態 4によれば、 I P網に接続し、 所定の I P電話方式により通話を行なう通信端末において、目的のインター ネットリソースを提供するサーバにアクセスし、その際送信するバケツトの 送信元ァドレスを通話相手の通信端末の I Pアドレスに変更することによ り当該サーバの応答バケツトが通話相手の通信端末に送信されるように.制 御することにより、通話相手の通信端末と同一のインターネットリソースを 共有利用する構成を採用しているので、従来の音声によるインターネットリ ソースの伝達と異なり、 相互に正しくインターネットリソースを伝達でき、 確実に同じインターネットリソースを利用でき、また、 U R Lなどのデータ 再入力などの操作を省略できるという優れた効果がある。すなわち、本発明 によれば、他の機器を用いることなく通信端末のみにより I P電話で通話中 の相手とインターネットリソースを簡単安価に、また面倒な操作を必要とせ ず確実に共有できる、 という優れた効果が得られる。

Claims

請 求 の 範 囲

1. I P網に接続し、所定の I P電話方式により通話を行なう通信端末 において、通話中の相手通信端末と、 目的のィンターネットリソースの UR L情報を送受信することにより、相手通信端末と同一のインターネットリソ ースを共有利用するインターネットリソース共有手段を有することを特徴 とする通信端末。

2. 前記 URL情報が前記 URL情報を受信した後の利用処理に関する 利用制御情報を含む特定の形式で記述され、前記 URL情報を受信した場合、 前記利用制御情報にしたがって前記 URL情報に対応するインターネット リソースを利用することを特徴とする請求項 1に記載の通信端末。

3. 自機または相手通信端末の一方が他方に F T Pログインし、前記 U R L情報を F T P手順を用いて相手通信端末と送受信することを特徴とす る請求項 1に記載の通信端末。

4. 相手通信端末に対して F T P口グインする際の認証情報としてメモ リのァドレス帳領域に記憶された相手通信端末に関する情報を用いること を特徴とする請求項 3に記載の通信端末。

5. 前記 URL情報を電子メールプロトコルを用いて相手通信端末と送 受信することを特徴とする請求項 1に記載の通信端末。

6. I P電話による通話中、 前記 URL情報を記述した電子メールを受 信するため、 P O Pサーバから電子メールを受信する電子メール時間間隔を 通常よりも短縮することを特徴とする請求項 5に記載の通信端末。

7. 前記 URL情報を記述した最初の電子メールを受信した後、 前記電 子メール時間間隔の短縮を行なう.ことを特徴とする請求項 6に記載の通信 端末。

8. 前記所定の I P電話方式により取得した前記相手通信端末の I Pァ ドレスに基づいて、前記 U R L情報を前記相手通信端末に送信することを特 徴とする請求項 1〜 4のいずれか 1項に記載の通信端末。

9. I P網に接続し、 所定の I P電話方式により通話を行なう通信端末 において、自機または相手通信端末の一方が HTTPプロキシサーバとして、 他方が HTTPクライアントとして動作し、相手通信端末との間で H T T P プロキシ手 を用いて目的のインターネットリソース自体を送受信するこ とにより、相手通信端末と同一のインターネットリソースを共有利用するィ ンターネットリソース共有手段を有することを特徴とする通信端末。

10. 前記所定の I P電話方式により取得した前記相手通信端末の I P ァドレスに基づいて、前記相手通信端末との間で HTTP手順を用いて目的 のインターネットリソースの送受信を行なうことを特徴する請求項 9に記 載の通信端末。

1 1. 前記インターネットリソースが HTTPサーバにより提供される WE Bデータであることを特徴とする請求項 1〜1 1のいずれか 1項に記 載の通信端末。

12. I P網に接続し、所定の I P電話方式により通話を行なう通信端 末の制御方法において、通話中の相手通信端末と、 目的のインターネットリ ソースの UR L情報を送受信することにより、相手通信端末と同一のィンタ ーネットリソースを共有利用するインターネットリソース共有制御過程を 含むことを特徴とする通信端末の制御方法。

13. 前記 URL情報が前記 URL情報を受信した後の利用処理に関す る利用制御情報を含む特定の形式で記述され、前記 U R L情報を受信した場 合、前記利用制御情報にしたがって前記 U R L情報に対応するインターネッ トリソースを利用することを特徴とする請求項 1 2に記載の通信端末の制 御方法。

14. 自機または相手通信端末の一方が他方に FTPログインし、前記 URL情報を FTP手順を用いて相手通信端末と送受信することを特徴と する請求項 12に記載の通信端末の制御方法。

15. 相手通信端末に対して FTPログインする際の認証情報としてメ モリのァドレス帳領域に記憶された相手通信端末に関する情報を用いるこ とを特徴とする請求項 14に記載の通信端末の制御方法。

16. 前記 URL情報を電子メールプロトコルを用いて相手通信端末と 送受信することを特徴とする請求項 12に記載の通信端末の制御方法。

17. I P電話による通話中、 前記 URL情報を記述した電子メールを 受信するため、 P O Pサーバから電子メールを受信する電子メール時間間隔 を通常よりも短縮することを特徴とする請求項 1 6に記載の通信端末の制 御方法。

18. 前記 URL情報を記述した最初の電子メールを受信した後、 前記 電子メール時間間隔の短縮を行なうことを特徴とする請求項 17に記載の 通信端末の制御方法。

19. 前記所定の I P電話方式により取得した前記相手通信端末の I P ァドレスに基づいて、前記 URL情報を前記相手通信端末に送信することを 特徴とする請求項 12〜15のいずれか 1項に記載の通信端末の制御方法。

20. I P網に接続し、 所定の I P電話方式により通話を行なう通信端 末の制御方法において、自機または相手通信端末の一方が HTTPプロキシ サーバとして、他方が HTTPクライアントとして動作し、相手通信端末と の間で HTTPプロキシ手順を用いて目的のインターネットリソース自体 を送受信することにより、相手通信端末と同一のインターネットリソースを 共有利用するインターネットリソース共有制御過程を含むことを特徴とす る通信端末の制御方法。

21. 前記所定の I P電話方式により取得した前記相手通信端末の I P アドレスに ¾づいて、前記相手通信端末との間で H T T P手順を用いて目的 のィンターネットリソースの送受信を行なうことを特徴する請求項 20に 記載の通信端末の制御方法。

22. 前記インターネットリソースが HTTPサーバにより提供される WEBデータであることを特徴とする請求項 12〜 21のいずれか 1項に 記載の通信端末の制御方法。

23. I P網に接続し、 所定の I P電話方式により通話を行なう通信端 末の制御プログラムにおいて、通話中の相手通信端末と、 目的のインターネ ットリソースの URL情報を送受信することにより、相手通信端末と同一の ィンターネットリソースを共有利用するインターネットリソース共有制御 過程含むことを特徴とする通信端末の制御プログラム。

24. 前記 URL情報が前記 URL情報を受信した後の利用処理に関す る利用制御情報を含む特定の形式で記述され、前記 U R L情報を受信した場 合、前記利用制御情報にしたがって前記 URL情報に対応するインターネッ トリソースを利用するための制御過程を含むことを特徴とする請求項 23 に記載の通信端末の制御プログラム。

25. 自機または相手通信端末の一方が他方に FTPログインレ、 前記 URL情報を FTP手順を用いて相手通信端末と送受信するための制御過 程を含むことを特徴とする請求項 23に記載の通信端末の制御プログラム。

26. 相手通信端末に対して FTPログインする際の認証情報としてメ モリのァドレス帳領域に記憶された相手通信端末に関する情報を用いるた めの制御過程を含むことを特徴とする請求項 25に記載の通信端末の制御 プログラム。

27. 前記 URL情報を電子メールプロトコルを用いて相手通信端末と 送受信するための制御過程を含むことを特徴とする請求項 24に記載の通 信端末の制御プログラム。

28. I P電話による通話中、 前記 URL情報を記述した電子メールを 受信するため、 P O Pサーバから電子メールを受信する電子メール時間間隔 を通常よりも短縮するための制御過程を含むことを特徴とする請求項 2 7 に記載の通信端末の制御プログラム。

29. 前記 URL情報を記述した最初の電子メールを受信した後、 前記 電子メール時間間隔の短縮を行なうための制御過程を含むことを特徴とす る請求項 28に記載の通信端末の制御プログラム。

30. 前記所定の I P電話方式により取得した前記相手通信端末の I P ァドレスに基づいて、前記 URL情報を前記相手通信端末に送信することを 特徴とする請求項 24〜26のいずれか 1項に記載の通信端末の制御プロ グラム。

31. I P網に接続し、 所定の I P電話方式により通話を行なう通信端 末の制御プログラムにおいて、自機または相手通信端末の一方が H T T Pプ ロキシサーバとして、他方が HTTPクライアントとして動作し、相手通信 端末との間で HTTPプロキシ手順を用いて目的のィンターネットリソー ス自体を送受信することにより、相手通信端末と同一のインターネットリソ ースを共有利用するインターネットリソース共有制御過程を含むことを特 徴とする通信端末の制御プログラム。

32. 前記所定の I P電話方式により取得した前記相手通信端末の I P アドレスに基づいて、前記相手通信端末との間で H T T P手順を用いて目的 のインターネットリソースの送受信を行なう.ことを特徴する請求項 3 1に 記載の通信端末の制御プログラム。 ' ■

33. 前記インターネットリソースが HTTPサーバにより提供される W E Bデータであることを特徴とする請求項 2 2〜3 2のいずれか 1項に 記載の通信端末の制御プログラム。 '

3 4 . I P網に接続し、 所定の I P電話方式により通話を行なう通信端 末において、目的のインターネットリソースを提供するサーバにアクセスし、 その際送信するバケツトの送信元ァドレスを通話中の相手の通信端末の I Pアドレスに変更することにより当該サーバの応答パケットが通話中の相 手の通信端末に送信されるように制御することにより、通話中の相手の通信 端末と同一のインターネッ トリ ソースを共有利用するインターネッ トリ ソ ース共有手段を有することを特徴とする通信端末。

3 5 . 前記インターネッ トリソースが WE Bデータであり、 前記サーバ が WE Bデータを提供する H T T Pサーバであることを特徴とする請求項 3 4に記載の通信端末。

3 6 . 前記通話中の相手の通信端末の I Pアドレスが I P電話の呼接続 手順により取得されることを特徴とする請求項 3 4に記載の通信端末。

3 7 . 前記インターネットリソースの共有利用を指定する操作手段が設 けられることを特徴とする請求項 3 4に記載の通信端末。

3 8 . 前記操作手段の操作の都度、 前記インターネットリソース共有動 作が行なわれることを特徴とする請求項 3 4に記載の通信端末。 ' 3 9 . I P電話の通話中、 自機で利用中のインターネットリソースが変 更される度にそのインターネットリソースの通話中の相手の通信端末との 共有動作を行なうインターネットリソース共有モードが設定されることを 特徴とする請求項 3 4に記載の通信端末。

4 Q . I P網に接続し、 所定の I P電話方式により通話を行なう通信端 末の制御方法において、

目的のインターネットリソースを提供するサーバにアクセスし、その際送信 するパケットの送信元ァドレスを通話中の相手の通信端末の I Pア ドレス に変更することにより当該サーバの応答パケットが通話中の相手の通信端 末に送信されるように制御することにより、通話中の相手の通信端末と同一 のインターネットリソースを共有利用することを特徴とする通信端末の制 御方法。

4 1 . 前記インターネットリソースが W E Bデータであり、 前記サーバ が W E Bデータを提供する H T T Pサーバであることを特徴とする請求項 4 0に記載の通信端末の制御方法。

4 2 . 前記通話中の相手の通信端末の I Pアドレスが I P電話の呼接続 手順により取得されることを特徴とする請求項 4 0に記載の通信端末の制 御方法。

4 3 . 所定の操作手段のユーザ操作により前記インターネットリソース の共有利用が指定されることを特徴とする請求項 4 0に記載の通信端末の 制御方法。 4 4 . 前記操作竽段の操作の都度、 前記インターネットリソース共有動 作が行なわれることを特徴とする請求項 4 0に記載の通信端末の制御方法。

4 5 . I P電話の通話中、 自機で利用中のインターネットリソースが変 更される度にそのィンターネットリソースの通話中の相手の通信端末との 共有動作を行なうインターネットリソース共有モードが設定されることを 特徴とする請求項 4 0に記載の通信端末の制御方法。

4 6 . I P網に接続し、 所定め I P電話方式により通話を行なう通信端 末の制御プログラムにおいて、目的のインターネットリソースを提供するサ ーバにアクセスし、その際送信するバケツトの送信元ァドレスを通話中の相 手の通信端末の I Pアドレスに変更することにより当該サーバの応答パケ ットが通話中の相手の通信端末に送信されるよ.うに制御することにより、通 話中の相手の通信端末と同一のィンターネットリソースを共有利用するた めの制御過程を含むことを特徴とする通信端末の制御プログラム。

4 7 . 前記インターネットリ ソースが W E Bデータであり、 前記サーバ が W E Bデータを提供する H T T Pサーバであることを特徴とする請求項 4 6に記載の通信端末の制御プログラム。

4 8 . 前記通話中の相手の通信端末の I Pアドレスを I P電話の呼接続 手順により取得するための制御過程を含むことを特徴とする請求項 4 6に 記載の通信端末の制御プログラム。

4 9 . 所定の操作手段のユーザ操作に応じて前記インターネットリソー スの共有利用動作を行なうための制御過程を含むことを特徴とする請求項 4 6に記載の通信端末の制御プログラム。

5 0 . 前記操作手段の操作の都度、 前記インターネットリソース共有動 作を行なうための制御過程を含むことを特徴とする請求項 4 6に記載の通 信端末の制御プログラム。

5 1 . I P電話の通話中、 自機で利用中のインターネットリ ソースが変 更される度にそのィンターネットリソースの通話中の相手の通信端末との 共有動作を行なうインターネットリソース共有モードを設定するための制 御過程を含むことを特徴とする請求項 4 6に記載の通信端末の制御プログ ラム。