JP2001333131A - コンテンツ取得装置 - Google Patents

Abstract

(57)【要約】 【課題】 データ受信に先立って適切な接続方法を選択
するコンテンツ取得装置１a を提供することである。 【解決手段】 コンテンツ取得装置１a において、ブラ
ウザ部Ｐbwは、今回取得すべきサブコンテンツデータＤ
scの取得要求Ｄcreqを生成する。プロトコル制御部Ｐpc
は、ブラウザ部Ｐbwにより特定されたサブコンテンツデ
ータＤscの受信前に、第１の通信路４pkt を使うか、第
２の通信路４tel を使うかを決定する。第１の通信制御
部Ｐcc1 は、プロトコル制御部Ｐpcが第１の通信路４pk
t を使うと決定した場合に、ブラウザ部Ｐbwが指定した
サブコンテンツデータＤscをコンテンツサーバ３から受
信する。第２の通信制御部Ｐcc2 は、プロトコル制御部
Ｐpcが第２の通信路４tel を使うと決定した場合に、ブ
ラウザ部Ｐbwが指定したサブコンテンツデータＤscをコ
ンテンツサーバ３から受信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンテンツ取得装
置に関し、より特定的には、複数の接続方法を使用可能
に構成されており、最適な接続方法で通信網を介してサ
ーバからコンテンツデータを取得するコンテンツ取得装
置に関する。

【０００２】近年、インターネットを利用して、ホーム
ページ（Ｗｅｂページ）の閲覧または電子メールの交換
が盛んに行われている。インターネット利用時、ユーザ
は、携帯電話に代表されるコンテンツ取得装置を操作す
る。コンテンツ取得装置は、インターネットにアクセス
するために、まず、ユーザが加入するネットワーク（例
えば、移動体通信網）とのコネクションを確立する。そ
の後、コンテンツ取得装置は、ユーザの操作に従って、
インターネット上のサーバにアクセスし、ホームページ
または電子メールに代表されるコンテンツデータをネッ
トワークを介して取得する。

【０００３】従来、ネットワークの通信速度が低かった
こともあり、サーバは、テキストファイルおよび静止画
ファイルに代表される小容量のコンテンツデータを中心
に扱っていた。しかしながら、近年の技術進歩により、
コンテンツ取得装置が高性能になり、さらには、ネット
ワークの通信速度が飛躍的に向上したことから、サーバ
は、動画ファイルおよび音楽ファイルに代表される大容
量のコンテンツデータを扱えるようになってきた。

【０００４】また、コンテンツ取得装置は、回線交換接
続およびパケット交換接続のいずれか一方の接続方法
で、ネットワークを利用していた。回線交換接続では、
１つの発呼側および１つの着呼側の間で、物理的な１つ
の通信路が形成される。呼の発生から終了まで、発呼側
および着呼側が当該通信路を占有するので、回線交換接
続では、発呼側および着呼側のデータ通信が、他のデー
タ通信の影響を受けない。つまり、通信遅延（送信元か
ら受信先へとデータが届く時間）が実質的に一定にで
き、回線交換接続は通信速度を保証しやすい。そのた
め、テレビ電話や動画配信等のように、大容量のコンテ
ンツデータを同じ受信先へと送信したい場合に好適であ
る。

【０００５】一方、パケット交換接続では、回線交換接
続とは逆に、通信路は１つの呼で占有されず、他の呼と
共用される。通信路が共用されるので、データは、パケ
ットに分割され、他の呼で交換されるパケットと混在し
ながら伝送される。そのため、パケット交換接続では、
通信路のリソースを有効利用でき、通信コストを抑える
ことができるが、回線交換接続とは異なり、パケットの
紛失やパケットの到着順序の逆転が発生することから、
通信遅延を一定にすることができない。つまり、パケッ
ト交換接続は、通信速度を保証しにくい。さらに、各パ
ケットは、他の呼で交換されるものと区別する必要が生
じるので、伝送されるデータだけでなく、その送信元お
よび受信先の識別子を含んでいる。それゆえ、パケット
交換接続の実効通信速度は、回線交換接続のそれよりも
低くなる。ここで、実効通信速度とは、識別子その他の
制御情報を除く、データのみの通信速度を意味する。以
上のことから、パケット交換接続は、電子メールの送受
のように、通信遅延の揺らぎがさほど問題にならない場
合や、データ通信を呼の期間中常時行わない場合には好
適である。

【０００６】従来、コンテンツ取得装置は、回線交換接
続およびパケット交換接続のいずれか一方を使ってい
た。しかしながら、第２６２５３８８号特許公報に開示
されているＬＡＮ間接続装置のように、回線交換接続お
よびパケット交換接続のいずれかを選択的に使用するコ
ンテンツ取得装置が開発されている。ＬＡＮ間接続装置
は、ＩＳＤＮ(Integrated Service Digital Network)を
介してデータ通信を行うシステムに適用される。ＬＡＮ
間接続装置は、通信路上のデータ転送量を監視して、一
回の業務（トランザクション）におけるデータ転送量お
よび通信トラフィック量（通信路上をデータが占める通
信密度）に基づいて、回線交換接続およびパケット交換
接続のいずれかを選択する。

【０００７】

【発明が解決しようとする課題】しかしながら、ＬＡＮ
間接続装置は、実際に行われたデータ通信を監視し
て、、当該データ通信の状況に基づいて、回線交換接続
およびパケット交換接続のいずれかを選択する。そのた
め、ＬＡＮ間接続装置では、これから行うデータ通信に
適切な接続方法を選択することが難しい。また、ＬＡＮ
間接続装置では、データ通信の状況に応じて、接続方法
の切り替えが行われる場合があるので、途切れのないデ
ータ通信が必要な時、例えば、動画ファイルの伝送時に
は、一方の接続方法から他方への切り替えが完了するま
でに、通信遅延が発生してしまう。以上のことから、Ｌ
ＡＮ間接続装置は、通信遅延やデータ通信の中断が致命
的になる性質を有するデータには向かないという問題点
があった。

【０００８】かかる問題点に対して、ＬＡＮ間接続装置
は、業務毎に交換されるデータの属性を業務情報として
設定する業務情報設定部を備えており、当該業務情報設
定部を参照して、これから交換されるデータを予測し
て、適切な接続方法を選択する。しかしながら、インタ
ーネット上では、テキストファイル、動画ファイルおよ
び音楽ファイル等、様々なデータを取得できるので、Ｌ
ＡＮ間接続装置がこれから交換されるデータを正確に予
測することは難しい。

【０００９】それ故に、本発明の目的は、データ受信に
先立って適切な接続方法を選択するコンテンツ取得装置
を提供することである。

【００１０】

【課題を解決するための手段および発明の効果】第１の
発明は、マルチコール機能により複数の接続方法を使用
可能に構成されており、最適な接続方法で通信網を介し
てサーバからコンテンツデータを取得するコンテンツ取
得装置であって、今回取得すべきサブコンテンツデータ
の位置情報を特定する取得要求を生成するブラウザ部
と、ブラウザ部により特定されたコンテンツデータの受
信前に、その接続方法を決定するプロトコル制御部と、
プロトコル制御部が決定した接続方法で、ブラウザ部が
指定したコンテンツデータをサーバから受信する通信制
御部とを備える。

【００１１】第２の発明は第１の発明に従属しており、
コンテンツデータは、自身にリンクされる各サブコンテ
ンツデータの位置情報と、当該各サブコンテンツデータ
に好適な接続方法を示す接続方法情報とを含んでおり、
ブラウザ部は、受信コンテンツデータを解析して、各サ
ブコンテンツデータの位置情報および接続方法情報を取
得した後、今回取得すべきサブコンテンツデータの位置
情報を特定する取得要求を生成し、プロトコル制御部
は、ブラウザ部が取得した接続方法情報に基づいて、当
該ブラウザ部により指定されたサブコンテンツデータを
受信する際の最適な接続方法を決定する。

【００１２】第３の発明は第１の発明に従属しており、
コンテンツデータは、自身にリンクされる各サブコンテ
ンツデータの位置情報およびファイル属性とを含んでお
り、コンテンツ取得装置は、コンテンツデータのファイ
ル属性毎に最適な接続方法が記述された接続情報テーブ
ルを管理する接続情報管理部をさらに備え、ブラウザ部
は、受信コンテンツデータを解析して、各サブコンテン
ツデータの位置情報およびファイル属性の組みを取得し
て内部情報として保持した後に、今回取得すべきサブコ
ンテンツデータの位置情報を特定する取得要求を生成
し、プロトコル制御部は、ブラウザ部で生成された取得
要求を受け取ると、当該取得要求が含む位置情報と同じ
組みを構成するファイル属性を当該ブラウザ部から受け
取り、さらに、ブラウザ部から受け取ったファイル属性
と同じ組みを構成する最適な接続方法を、接続情報管理
部から取得することにより決定する。

【００１３】第４の発明は第１の発明に従属しており、
コンテンツデータには、サーバにおける格納位置を示す
位置情報が割り当てられており、当該位置情報の一部が
当該コンテンツデータの特徴を示しており、コンテンツ
取得装置は、コンテンツデータの特徴毎に最適な接続方
法が記述された接続情報テーブルを管理する接続情報管
理部をさらに備え、プロトコル制御部は、ブラウザ部で
生成された取得要求を受け取ると、当該取得要求が含む
位置情報の一部と同じ組みを構成する最適な接続方法
を、接続情報管理部から受け取ることにより決定する。

【００１４】第５の発明は第１の発明に従属しており、
サーバは、コンテンツデータの他に、当該コンテンツデ
ータのファイル属性を含むコンテンツヘッダを送信可能
に構成されており、コンテンツ取得装置は、コンテンツ
データのファイル属性毎に最適な接続方法が記述された
接続情報テーブルを管理する接続情報管理部をさらに備
え、ブラウザ部は、今回取得すべきコンテンツデータの
位置情報を特定する第１の取得要求を生成し、プロトコ
ル制御部は、ブラウザ部で生成された第１の取得要求を
受け取ると、当該取得要求で特定されるコンテンツデー
タのコンテンツヘッダを取得するための第２の取得要求
を生成し、通信制御部は、プロトコル制御部で生成され
た第２の取得要求で特定されるコンテンツヘッダをサー
バから受信し、プロトコル制御部は、通信制御部により
受信されたコンテンツヘッダが含むファイル属性と同じ
組みを構成する最適な接続方法を、接続情報管理部から
取得することにより決定する。

【００１５】以上の第１〜第５の発明によれば、コンテ
ンツ取得装置は、コンテンツデータの受信前に最適な接
続方法を決定する。その結果、通信遅延やデータ通信の
中断が致命的なコンテンツデータを、コンテンツ取得装
置は、好適な接続方法で受信できる。

【００１６】第６の発明は、マルチコール機能により、
複数の接続方法の内、最適な接続方法で通信網を介して
サーバからコンテンツデータを取得するコンテンツ取得
方法であって、今回取得すべきコンテンツデータの位置
情報を特定するコンテンツ取得要求を生成するコンテン
ツ要求生成ステップと、当該コンテンツ要求生成ステッ
プにより特定されたサブコンテンツデータの受信前に、
最適な接続方法を決定する接続方法決定ステップと、接
続方法決定ステップで決定された接続方法で、コンテン
ツ要求生成ステップで特定されたコンテンツデータをサ
ーバから受信するコンテンツ受信ステップとを備える。

【００１７】第７の発明は第６の発明に従属しており、
コンテンツデータは、自身にリンクされる各サブコンテ
ンツデータの位置情報と、当該各サブコンテンツデータ
に好適な接続方法を示す接続方法情報とを含んでおり、
コンテンツ要求生成ステップは、受信コンテンツデータ
を解析して、各サブコンテンツデータの位置情報および
接続方法情報を取得した後、今回取得すべきサブコンテ
ンツデータの位置情報を特定するコンテンツ取得要求を
生成し、接続方法決定ステップは、コンテンツ要求生成
ステップで取得された接続方法情報に基づいて、最適な
接続方法を決定する。

【００１８】第８の発明は第６の発明に従属しており、
コンテンツデータは、自身にリンクされる各サブコンテ
ンツデータの位置情報およびファイル属性とを含んでお
り、コンテンツデータのファイル属性毎に最適な接続方
法が記述された接続情報テーブルが予め管理されてお
り、コンテンツ要求生成ステップは、受信コンテンツデ
ータを解析して、各サブコンテンツデータの位置情報お
よびファイル属性の組みを取得して内部情報として保持
した後に、今回取得すべきサブコンテンツデータの位置
情報を特定するコンテンツ取得要求を生成し、接続方法
決定ステップは、コンテンツ要求生成ステップで生成さ
れたコンテンツ取得要求を受け取ると、当該コンテンツ
取得要求が含む位置情報と同じ組みを構成するファイル
属性を当該コンテンツ要求生成ステップから受け取り、
さらに、コンテンツ要求生成ステップから受け取ったフ
ァイル属性と同じ組みを構成する最適な接続方法を、接
続情報テーブルから取得することにより決定する。

【００１９】第９の発明は第６の発明に従属しており、
コンテンツデータには、サーバにおける格納位置を示す
位置情報が割り当てられており、当該位置情報の一部が
当該コンテンツデータの特徴を示しており、コンテンツ
データの特徴毎に最適な接続方法が記述された接続情報
テーブルが予め管理されており、接続方法決定ステップ
は、コンテンツ要求生成ステップで生成されたコンテン
ツ取得要求を受け取ると、当該コンテンツ取得要求が含
む位置情報の一部と同じ組みを構成する最適な接続方法
を、接続情報テーブルから取得することにより決定す
る。

【００２０】第１０の発明は第６の発明に従属してお
り、サーバは、コンテンツデータの他に、当該コンテン
ツデータのファイル属性を含むコンテンツヘッダを送信
可能に構成されており、コンテンツデータのファイル属
性毎に最適な接続方法が記述された接続情報テーブルが
予め管理されており、コンテンツ要求生成ステップで生
成されたコンテンツ取得要求を受け取って、当該取得要
求で特定されるコンテンツデータのコンテンツヘッダを
取得するためのヘッダ取得要求を生成するヘッダ要求生
成部と、ヘッダ要求生成ステップで生成されたヘッダ取
得要求で特定されるコンテンツヘッダをサーバから受信
するヘッダ受信ステップとをさらに備え、接続方法決定
ステップは、ヘッダ受信ステップで受信されたコンテン
ツヘッダが含むファイル属性と同じ組みを構成する最適
な接続方法を、接続情報テーブルから取得することによ
り決定する。

【００２１】第１１の発明は、マルチコール機能によ
り、複数の接続方法の内、最適な接続方法で通信網を介
してサーバからコンテンツデータを取得するためのプロ
グラムを記録した記録媒体であって、今回取得すべきコ
ンテンツデータの位置情報を特定するコンテンツ取得要
求を生成するコンテンツ要求生成ステップと、当該コン
テンツ要求生成ステップにより特定されたサブコンテン
ツデータの受信前に、最適な接続方法を決定する接続方
法決定ステップと、接続方法決定ステップで決定された
接続方法で、コンテンツ要求生成ステップで特定された
コンテンツデータをサーバから受信するコンテンツ受信
ステップとを備える。

【００２２】第１２の発明は第１１の発明に従属してお
り、コンテンツデータは、自身にリンクされる各サブコ
ンテンツデータの位置情報と、当該各サブコンテンツデ
ータに好適な接続方法を示す接続方法情報とを含んでお
り、コンテンツ要求生成ステップは、受信コンテンツデ
ータを解析して、各サブコンテンツデータの位置情報お
よび接続方法情報を取得した後、今回取得すべきサブコ
ンテンツデータの位置情報を特定するコンテンツ取得要
求を生成し、接続方法決定ステップは、コンテンツ要求
生成ステップで取得された接続方法情報に基づいて、最
適な接続方法を決定する。

【００２３】第１３の発明は第１１の発明に従属してお
り、コンテンツデータは、自身にリンクされる各サブコ
ンテンツデータの位置情報およびファイル属性とを含ん
でおり、コンテンツデータのファイル属性毎に最適な接
続方法が記述された接続情報テーブルが予め管理されて
おり、コンテンツ要求生成ステップは、受信コンテンツ
データを解析して、各サブコンテンツデータの位置情報
およびファイル属性の組みを取得して内部情報として保
持した後に、今回取得すべきサブコンテンツデータの位
置情報を特定するコンテンツ取得要求を生成し、接続方
法決定ステップは、コンテンツ要求生成ステップで生成
されたコンテンツ取得要求を受け取ると、当該コンテン
ツ取得要求が含む位置情報と同じ組みを構成するファイ
ル属性を当該コンテンツ要求生成ステップから受け取
り、さらに、コンテンツ要求生成ステップから受け取っ
たファイル属性と同じ組みを構成する最適な接続方法
を、接続情報テーブルから取得することにより決定す
る。

【００２４】第１４の発明は第１１の発明に従属してお
り、コンテンツデータには、サーバにおける格納位置を
示す位置情報が割り当てられており、当該位置情報の一
部が当該コンテンツデータの特徴を示しており、コンテ
ンツデータの特徴毎に最適な接続方法が記述された接続
情報テーブルが予め管理されており、接続方法決定ステ
ップは、コンテンツ要求生成ステップで生成されたコン
テンツ取得要求を受け取ると、当該コンテンツ取得要求
が含む位置情報の一部と同じ組みを構成する最適な接続
方法を、接続情報テーブルから取得することにより決定
する。

【００２５】第１５の発明は第１１の発明に従属してお
り、サーバは、コンテンツデータの他に、当該コンテン
ツデータのファイル属性を含むコンテンツヘッダを送信
可能に構成されており、コンテンツデータのファイル属
性毎に最適な接続方法が記述された接続情報テーブルが
予め管理されており、コンテンツ要求生成ステップで生
成されたコンテンツ取得要求を受け取って、当該取得要
求で特定されるコンテンツデータのコンテンツヘッダを
取得するためのヘッダ取得要求を生成するヘッダ要求生
成部と、ヘッダ要求生成ステップで生成されたヘッダ取
得要求で特定されるコンテンツヘッダをサーバから受信
するヘッダ受信ステップとをさらに備え、接続方法決定
ステップは、ヘッダ受信ステップで受信されたコンテン
ツヘッダが含むファイル属性と同じ組みを構成する最適
な接続方法を、接続情報テーブルから取得することによ
り決定する。

【００２６】第１６の発明は、マルチコール機能によ
り、複数の接続方法の内、最適な接続方法で通信網を介
してサーバからコンテンツデータを取得するためのプロ
グラムであって、今回取得すべきコンテンツデータの位
置情報を特定するコンテンツ取得要求を生成するコンテ
ンツ要求生成ステップと、当該コンテンツ要求生成ステ
ップにより特定されたサブコンテンツデータの受信前
に、最適な接続方法を決定する接続方法決定ステップ
と、接続方法決定ステップで決定された接続方法で、コ
ンテンツ要求生成ステップで特定されたコンテンツデー
タをサーバから受信するコンテンツ受信ステップとを備
える。

【００２７】第１７の発明は第１６の発明に従属してお
り、コンテンツデータは、自身にリンクされる各サブコ
ンテンツデータの位置情報と、当該各サブコンテンツデ
ータに好適な接続方法を示す接続方法情報とを含んでお
り、コンテンツ要求生成ステップは、受信コンテンツデ
ータを解析して、各サブコンテンツデータの位置情報お
よび接続方法情報を取得した後、今回取得すべきサブコ
ンテンツデータの位置情報を特定するコンテンツ取得要
求を生成し、接続方法決定ステップは、コンテンツ要求
生成ステップで取得された接続方法情報に基づいて、最
適な接続方法を決定する。

【００２８】第１８の発明は第１６の発明に従属してお
り、コンテンツデータは、自身にリンクされる各サブコ
ンテンツデータの位置情報およびファイル属性とを含ん
でおり、コンテンツデータのファイル属性毎に最適な接
続方法が記述された接続情報テーブルが予め管理されて
おり、コンテンツ要求生成ステップは、受信コンテンツ
データを解析して、各サブコンテンツデータの位置情報
およびファイル属性の組みを取得して内部情報として保
持した後に、今回取得すべきサブコンテンツデータの位
置情報を特定するコンテンツ取得要求を生成し、接続方
法決定ステップは、コンテンツ要求生成ステップで生成
されたコンテンツ取得要求を受け取ると、当該コンテン
ツ取得要求が含む位置情報と同じ組みを構成するファイ
ル属性を当該コンテンツ要求生成ステップから受け取
り、さらに、コンテンツ要求生成ステップから受け取っ
たファイル属性と同じ組みを構成する最適な接続方法
を、接続情報テーブルから取得することにより決定す
る。

【００２９】第１９の発明は第１６の発明に従属してお
り、コンテンツデータには、サーバにおける格納位置を
示す位置情報が割り当てられており、当該位置情報の一
部が当該コンテンツデータの特徴を示しており、コンテ
ンツデータの特徴毎に最適な接続方法が記述された接続
情報テーブルが予め管理されており、接続方法決定ステ
ップは、コンテンツ要求生成ステップで生成されたコン
テンツ取得要求を受け取ると、当該コンテンツ取得要求
が含む位置情報の一部と同じ組みを構成する最適な接続
方法を、接続情報テーブルから取得することにより決定
する。

【００３０】第２０の発明は第１６の発明に従属してお
り、サーバは、コンテンツデータの他に、当該コンテン
ツデータのファイル属性を含むコンテンツヘッダを送信
可能に構成されており、コンテンツデータのファイル属
性毎に最適な接続方法が記述された接続情報テーブルが
予め管理されており、コンテンツ要求生成ステップで生
成されたコンテンツ取得要求を受け取って、当該取得要
求で特定されるコンテンツデータのコンテンツヘッダを
取得するためのヘッダ取得要求を生成するヘッダ要求生
成部と、ヘッダ要求生成ステップで生成されたヘッダ取
得要求で特定されるコンテンツヘッダをサーバから受信
するヘッダ受信ステップとをさらに備え、接続方法決定
ステップは、ヘッダ受信ステップで受信されたコンテン
ツヘッダが含むファイル属性と同じ組みを構成する最適
な接続方法を、接続情報テーブルから取得することによ
り決定する。

【００３１】以上の第６〜第２０の発明によれば、コン
テンツデータの受信前に最適な接続方法が決定される。
その結果、通信遅延やデータ通信の中断が致命的なコン
テンツデータを好適な接続方法で受信できる。

【００３２】

【発明の実施の形態】図１は、本発明の第１の実施形態
に係るコンテンツ取得装置１a の機能ブロック図であ
る。さらに、図１には、コンテンツ取得装置１a に付随
して、通信網２と、コンテンツサーバ３とが示されてい
る。コンテンツ取得装置１a は、マルチコール機能を有
しており、これによって、パケット交換接続および回線
交換接続のいずれかの接続方法で、コンテンツサーバ３
からコンテンツデータＤc を、通信網２を介して取得す
る。ここで、コンテンツ取得装置１a は、パケット交換
接続時には、第１の通信路４pkt を使ってコンテンツサ
ーバ３にアクセスし、回線交換接続時には、第２の通信
路４tel を使う。以上のデータ通信を実現するために、
コンテンツ取得装置１a は、ブラウザ部Ｐbwと、プロト
コル制御部Ｐpcと、第１の通信制御部Ｐcc1 と、第２の
通信制御部Ｐcc2 とを備える。

【００３３】コンテンツサーバ３は、いくつかのコンテ
ンツデータＤc を格納している。各コンテンツデータＤ
c は、典型的には、ＨＴＭＬ(Hyper Text Markup Langu
age)に代表されるマークアップ言語で作成されるテキス
トファイル、音楽ファイル、静止画ファイルまたは動画
ファイルである。ＨＴＭＬでは、あるコンテンツデータ
Ｄc から、他のコンテンツデータＤc へとリンクを張る
ことができる（いわゆる、ハイパーリンク）。本実施形
態では、リンク元となるコンテンツデータＤcをメイン
コンテンツデータＤmcと称する。また、リンク先のコン
テンツデータＤc をサブコンテンツデータＤscと称す
る。

【００３４】ハイパーリンクのために、メインコンテン
ツデータＤmcには、サブコンテンツデータＤscの格納位
置を示す位置情報Ｉurl （つまり、ＵＲＬ(Uniform Res
ource Locator)。図示はｕｒｌ1 およびｕｒｌ2 ）を特
定するアンカータグＴanc （図示はアンカータグＴanc1
およびＴanc2）が記述される。また、本実施形態では、
アンカータグＴanc の属性値として接続方法情報Ｉconn
1 （接続方法情報Ｉconn11またはＩconn12）が追加され
る。接続方法情報Ｉconn1 は、サブコンテンツデータＤ
scをコンテンツ取得装置１a が取得するのに好適な接続
方法を示す。本実施形態では、接続方法情報Ｉconn1 は
２種類準備されており、一方の接続方法情報Ｉconn11
は、好適な接続方法がパケット交換接続であることを示
しており、ｃｃ＝ｐａｃｋｅｔと記される。他方の接続
方法情報Ｉconn12は、好適な接続方法が回線交換接続で
あることを示し、ｃｃ＝ｔｅｌと記される。

【００３５】図１には、例示的に、１つのメインコンテ
ンツデータＤmcと、サブコンテンツデータＤscとして、
２つのサブコンテンツデータＤsc1 およびＤsc2 とが示
されている。メインコンテンツデータＤmcには、その格
納位置を特定するための位置情報Ｉurl としてｕｒｌ0
が割り当てられている。なお、ｕｒｌ0 はhttp://www.x
xx.co.jp/main.htmlのような形式を持つ。サブコンテン
ツデータＤsc1 は、通信遅延やデータ通信の中断が致命
的ではないテキストファイルまたは静止画ファイル、つ
まり、パケット交換接続で取得されることが好適である
と仮定する。逆に、サブコンテンツデータＤsc2 は、通
信遅延等が致命的な音楽ファイルまたは動画ファイル、
つまり、回線交換接続で取得されることが好適であると
仮定する。また、サブコンテンツデータＤsc1 の位置情
報Ｉurl はｕｒｌ1 であり、サブコンテンツデータＤsc
2 のそれはｕｒｌ2 であると仮定する。以上の仮定下で
は、メインコンテンツデータＤmcには、２つのアンカー
タグＴanc1およびＴanc2が記述される。アンカータグＴ
anc1には、“ｈｒｅｆ＝ｕｒｌ1 ”と共に、“ｃｃ＝ｐ
ａｃｋｅｔ”が記される。また、アンカータグＴanc2に
は、“ｈｒｅｆ＝ｕｒｌ2 ”と共に、“ｃｃ＝ｔｅｌ”
が記される。

【００３６】次に、コンテンツ取得装置１a の動作につ
いて説明する。プロトコル制御部Ｐpcには、コンテンツ
の取得要求Ｄcreqがブラウザ部Ｐbwから送られてくる。
今回の取得要求Ｄcreqは、コンテンツ取得装置１a のユ
ーザの入力に応答して生成され、メインコンテンツデー
タＤmcの位置情報Ｉurl （つまり、ｕｒｌ0 ）を含むと
仮定する。プロトコル制御部Ｐpcは、受信取得要求Ｄcr
eqを第１の通信制御部Ｐcc1 に渡して、メインコンテン
ツデータＤmcの取得を指示する。この指示に応答して、
第１の通信制御部Ｐcc1 は、コネクションが未確立であ
れば、パケット交換接続の規定に従って、コンテンツサ
ーバ３との間で第１の通信路４pkt を確立した後、コン
テンツサーバ３に取得要求Ｄcreqを送信する。

【００３７】上記のように、メインコンテンツデータＤ
mcの取得時には第１の通信路４pkt が使用される。なぜ
なら、メインコンテンツデータＤmcはリンク元であるた
め、本実施形態では、その取得に好適な接続方法がアン
カータグＴanc により示されないからである。さらに、
一般的に、パケット交換接続に関しては、多くのユーザ
が第１の通信路４pkt を共用するので、その通信コスト
が回線交換接続の場合と比較して安いからである。

【００３８】コンテンツサーバ３は、受信取得要求Ｄcr
eq内の位置情報Ｉurl に基づいて、コンテンツデータＤ
c を読み出す。さらに、コンテンツサーバ３は、応答ヘ
ッダＨc および応答データＤrep を作成する。今回読み
出されるコンテンツデータＤc はメインコンテンツデー
タＤmcである。今回作成される応答ヘッダＨc は、メイ
ンコンテンツデータＤmc用の応答ヘッダＨmcであり、図
２（ａ）に示すように、プロトコル識別子ＩＤprt と、
応答結果コードＣrep と、コンテンツタイプＩctypと、
コンテンツデータ長Ｉclg とを含む。プロトコル識別子
ＩＤprt は、今回のデータ通信のためのプロトコルを特
定する。応答結果コードＣrep は、今回の取得要求Ｄcr
eqに対する応答結果を特定する。コンテンツタイプＩct
ypは、今回読み出したコンテンツデータＤmcの種類を示
す。今回のコンテンツタイプＩctypは、その種類とし
て、コンテンツデータＤmcがＨＴＭＬで記述されている
ことを示すと仮定する。コンテンツデータ長Ｉclg は、
今回読み出したコンテンツデータＤmcのデータサイズを
示す。また、今回作成される応答データＤrep は、メイ
ンコンテンツデータＤmc用の応答データＤrep1である。
応答データＤrep1は、以上の応答ヘッダＨmcがメインコ
ンテンツデータＤmcに付加されたものであり、第１の通
信路４pkt を介して、コンテンツ取得装置１a に送信さ
れる。

【００３９】コンテンツ取得装置１a において、第１の
通信制御部Ｐcc1 は、第１の通信路４pkt を介して、応
答データＤrep1を受信し、そのままプロトコル制御部Ｐ
pcに渡す。プロトコル制御部Ｐpcは、受信応答データＤ
rep1のコンテンツタイプＩctypから、その後に続くコン
テンツデータＤc の種類を特定する。コンテンツタイプ
ＩctypがＨＴＭＬを示している場合、プロトコル制御部
Ｐpcは、受信応答データＤrep1をブラウザ部Ｐbwの言語
解析部（図示せず）に渡して、それに含まれるメインコ
ンテンツデータＤmcの解析を指示する。

【００４０】上記指示に応答して、ブラウザ部Ｐbwは、
コンテンツデータＤmcにより表されるテキストの構造お
よび配置を解析した後、当該テキストの表示処理を行
う。さらに、ブラウザ部Ｐbwは、今回の受信コンテンツ
データＤmcの各アンカータグＴanc1およびＴanc2から、
位置情報Ｉurl および接続方法情報Ｉconn1 の組みを内
部情報として取り出した後、予め内部に保持する内部情
報テーブルＴconn1 に記述する。図２（ｂ）に示すよう
に、内部情報テーブルＴconn1 には、位置情報Ｉurl お
よび接続方法情報Ｉconn1 の組みが記述可能に構成され
る。これによって、各サブコンテンツデータＤscの取得
時に、パケット交換接続および回線交換接続のいずれが
好適であるかが示される。本実施形態では、図１に示す
ように、アンカータグＴanc1には、“ｈｒｅｆ＝ｕｒｌ
1 ”および接続方法情報Ｉconn11としての“ｃｃ＝ｐａ
ｃｋｅｔ”の組みが記され、アンカータグＴanc2には、
“ｈｒｅｆ＝ｕｒｌ2 ”および接続方法情報Ｉconn12と
しての“ｃｃ＝ｔｅｌ”が記される。したがって、内部
情報テーブルＴconn1 には、図２（ｂ）に示すように、
ｕｒｌ1 およびｐａｃｋｅｔの組みと、ｕｒｌ2 および
ｔｅｌの組みとが記述される。これによって、サブコン
テンツデータＤsc1 の取得時にはパケット交換接続が、
また、サブコンテンツデータＤsc2 の取得時には回線交
換接続が好適であることが示される。

【００４１】サブコンテンツデータＤsc1 の取得時、プ
ロトコル制御部Ｐpcには、その位置情報Ｉurl を含む取
得要求Ｄcreqがブラウザ部Ｐbwから送られてくる。今回
の取得要求Ｄcreqは、ブラウザ部Ｐbwにより自動的に生
成される。このように取得要求Ｄcreqが自動的に生成さ
れるのは、サブコンテンツデータＤsc1 がメインコンテ
ンツデータＤmcに埋め込まれている場合である。かかる
埋め込みの例として、図３（ａ）には、メインコンテン
ツデータＤmcが表すテキスト上に、サブコンテンツデー
タＤsc1 により表される静止画が貼り付けられる場合が
示されている。プロトコル制御部Ｐpcは、受信取得要求
Ｄcreqから位置情報Ｉurl を取り出した後、当該位置情
報Ｉurl と同じ組みの接続方法情報Ｉconn1 （今回の場
合、接続方法情報Ｉconn11）を、内部情報テーブルＴco
nn1 （図２（ｂ）参照）から取得する。プロトコル制御
部Ｐpcは、取得した接続方法情報Ｉconn1 に従って、今
回のサブコンテンツデータＤscを、パケット交換接続で
取得するか、回線交換接続で取得するかを決定する。今
回の場合、接続方法情報Ｉconn11が取得されるので、パ
ケット交換接続が好適であると決定される。

【００４２】以上の決定に従って、プロトコル制御部Ｐ
pcは、受信取得要求Ｄcreqを第１の通信制御部Ｐcc1 に
渡して、サブコンテンツデータＤsc1 の取得を指示す
る。この指示に応答して、第１の通信制御部Ｐcc1 は、
第１の通信路４pkt を確立した状態であればそのまま、
当該第１の通信路４pkt を介して、コンテンツサーバ３
に今回の取得要求Ｄcreqを送信する。一方、未確立であ
れば、第１の通信制御部Ｐcc1 は、コンテンツサーバ３
との間で第１の通信路４pkt を確立した後、今回の取得
要求Ｄcreqを当該コンテンツサーバ３に送信する。

【００４３】コンテンツサーバ３は、受信取得要求Ｄcr
eq内の位置情報Ｉurl に基づいて、コンテンツデータＤ
c を読み出す。さらに、コンテンツサーバ３は、応答ヘ
ッダＨc および応答データＤrep を作成する。今回読み
出されるコンテンツデータＤc はメインコンテンツデー
タＤsc1 である。さらに、コンテンツサーバ３は、サブ
コンテンツデータＤsc1 用の応答ヘッダＨsc1 を作成す
る。応答ヘッダＨsc1 は、図２（ａ）に示す通りのフォ
ーマットを有する。ここで、応答ヘッダＨsc1のコンテ
ンツタイプＩctypおよびコンテンツデータ長Ｉclg は、
今回読み出したコンテンツデータＤsc1 の種類およびデ
ータサイズを示す。本実施形態では、図３（ａ）に示す
ように、コンテンツデータＤsc1 の種類は静止画である
から、コンテンツタイプＩctypは、静止画という種類を
特定する。コンテンツサーバ３は、今回の応答データＤ
rep として、メインコンテンツデータＤsc1 に応答ヘッ
ダＨsc1 が付加された応答データＤrep2を作成し、第１
の通信路４pkt に送出する。

【００４４】コンテンツ取得装置１a の第１の通信制御
部Ｐcc1 は、第１の通信路４pkt から応答データＤrep2
を受信し、そのままプロトコル制御部Ｐpcに渡す。プロ
トコル制御部Ｐpcは、受信応答データＤrep2のコンテン
ツタイプＩctypから、後に続くコンテンツデータＤsc1
の種類を特定する。コンテンツタイプＩctypが静止画を
示していると判断した場合、プロトコル制御部Ｐpcは、
受信応答データＤrep2をブラウザ部Ｐbwの静止画の表示
処理部（図示せず）に渡して、当該応答データＤrep2に
含まれるサブコンテンツデータＤsc1 に対する表示処理
を指示する。この指示に応答して、ブラウザ部Ｐbwは、
サブコンテンツデータＤsc1 に対して静止画の表示処理
を行う。その結果、ブラウザ部Ｐbwは、サブコンテンツ
データＤsc1 が表す静止画を、メインコンテンツデータ
Ｄmcが表すテキスト上に貼り付ける。

【００４５】次に、サブコンテンツデータＤsc2 を取得
する場合について説明する。ここで、サブコンテンツデ
ータＤsc2 は、音楽ファイルであって、メインコンテン
ツデータＤmcに埋め込まれていると仮定する。より具体
的には、図３（ａ）に示すように、メインコンテンツデ
ータＤmcが表すテキストの表示中、サブコンテンツデー
タＤsc2 により表される音楽が流れる。サブコンテンツ
データＤsc2 の取得時、プロトコル制御部Ｐpcには、そ
の位置情報Ｉurl （つまり、ｕｒｌ2 ）を含む取得要求
Ｄcreqがブラウザ部Ｐbwから送られてくる。プロトコル
制御部Ｐpcは、受信取得要求Ｄcreqに含まれる位置情報
Ｉurl を取り出した後、当該位置情報Ｉurl と組みを構
成する接続方法情報Ｉconn1 （今回の場合、接続方法情
報Ｉconn12）を、内部情報テーブルＴconn1 から取得す
る。プロトコル制御部Ｐpcは、取得した接続方法情報Ｉ
conn1 に従って、今回使用する方法（今回は回線交換接
続）を決定する。

【００４６】以上の決定に従って、プロトコル制御部Ｐ
pcは、受信取得要求Ｄcreqを第２の通信制御部Ｐcc2 に
渡して、サブコンテンツデータＤsc2 の取得を指示す
る。この指示に応答して、第２の通信制御部Ｐcc2 は、
第２の通信路４tel を確立した状態であればそのまま、
当該第２の通信路４tel を介して、コンテンツサーバ３
に今回の取得要求Ｄcreqを送信する。一方、未確立であ
れば、第２の通信制御部Ｐcc2 は、コンテンツサーバ３
との第２の通信路４tel を確立した後、コンテンツサー
バ３に今回の取得要求Ｄcreqを送信する。

【００４７】コンテンツサーバ３は、受信取得要求Ｄcr
eqで指定された位置情報Ｉurl に基づいて、サブコンテ
ンツデータＤsc2 を読み出し、さらに、当該サブコンテ
ンツデータＤsc2 用の応答ヘッダＨsc2 （図２（ａ）参
照）を作成する。コンテンツサーバ３は、メインコンテ
ンツデータＤsc2 に応答ヘッダＨsc2 が付加された応答
データＤrep3を作成し、第１の通信路４tel に送出す
る。

【００４８】コンテンツ取得装置１a の第２の通信制御
部Ｐcc2 は、第２の通信路４tel から応答データＤrep3
を受信し、そのままプロトコル制御部Ｐpcに渡す。プロ
トコル制御部Ｐpcは、受信応答データＤrep3のコンテン
ツタイプＩctypから、当該コンテンツデータＤsc2 の種
類を特定する。コンテンツタイプＩctypが音楽ファイル
を示していると判断した場合、プロトコル制御部Ｐpc
は、受信応答データＤrep3をブラウザ部Ｐbwの音楽の再
生処理部（図示せず）に渡して、サブコンテンツデータ
Ｄsc2 が表す音楽の再生を指示する。ブラウザ部Ｐbw
は、プロトコル制御部Ｐpcの指示通りに再生処理を行
い、その結果、出力部（図示せず）からは、図３（ａ）
に示すような画面が表示され、音楽が出力される。

【００４９】以上説明したように、メインコンテンツデ
ータＤmcには、サブコンテンツデータＤsc1 およびＤsc
2 の取得に好適な接続方法情報Ｉconn11およびＩconn12
が記述される。以上のメインコンテンツデータＤmcを解
析することにより、コンテンツ取得装置１a は、サブコ
ンテンツデータＤsc1 およびＤsc2 の取得前に、それぞ
れを取得するのに好適な接続方法を知ることができる。
つまり、コンテンツ取得装置１a は、コンテンツデータ
Ｄsc2 の取得前に回線交換接続を選択することができ、
音楽ファイルおよび動画ファイルを、通信遅延またはデ
ータ通信の中断なく取得できる。また、コンテンツ取得
装置１a は、コンテンツデータＤsc1 の取得前にパケッ
ト交換接続を選択できるので、電子メールのような通信
遅延等を考慮しなくてもよいものを、相対的に安価な通
信コストで取得できる。

【００５０】なお、第１の実施形態では、好適な接続方
法はアンカータグＴanc 内の属性値により指定されてい
たが、通常のアンカータグＴanc とは異なる新しいアン
カータグを好適な接続方法の指定用に定義してもよい。

【００５１】また、上述では、サブコンテンツデータＤ
sc1 およびＤsc2 はメインコンテンツデータＤmcに埋め
込まれていた（図３（ａ）参照）。しかし、サブコンテ
ンツデータＤsc1 およびＤsc2 は、メインコンテンツデ
ータＤmcとリンクされているが、当該メインコンテンツ
データＤmcとは独立した内容を表していてもよい。より
具体的には、図３（ｂ）に示すように、まず、メインコ
ンテンツデータＤmcにより表される内容が出力される。
かかる出力内容において、ユーザが、アンカータグＴan
c1またはＴanc2を指定すると、コンテンツ取得装置１a
は、サブコンテンツデータＤsc1 またはＤsc2 を取得す
る。その結果、出力内容は、メインコンテンツデータＤ
mcが表すものから、サブコンテンツデータＤsc1 または
Ｄsc2 が表すものに切り替わる。

【００５２】次に、上記コンテンツ取得装置１a の実装
例について説明する。図４は、コンテンツ取得装置１a
を組み込んだ移動体通信装置Ｕcomm1 の構成を示すブロ
ック図である。図４において、移動体通信装置Ｕcomm1
は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、第１
の通信制御部Ｐcc1 と、第２の通信制御部Ｐcc2 と、入
力装置１４と、出力装置１５と、多重／分離部１６と、
送受信部１７とを備えている。ＣＰＵ１１は、ＲＯＭ１
２に予め格納されているプログラムを実行するする。プ
ログラム実行時、ＣＰＵ１１は、ＲＡＭ１３を作業領域
として使用する。以上のＣＰＵ１１は、ＲＯＭ１２およ
びＲＡＭ１３と共に、上述のブラウザ部Ｐbwおよびプロ
トコル制御部Ｐpc（図１参照）を構成する。第１の通信
制御部Ｐcc1 は、ＣＰＵ１１の制御下で、パケット交換
接続でデータ通信を行う。第２の通信制御部Ｐcc2 は、
ＣＰＵ１１の制御下で、回線交換接続でデータ通信を行
う。以上のＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、第１
の通信制御部Ｐcc1 および第２の通信制御部Ｐcc2 がコ
ンテンツ取得装置１a を構成する。

【００５３】入力装置１４は、典型的にはキー、ボタン
およびジョグダイヤルからなり、ユーザにより操作され
る。出力装置１５は、液晶ディスプレイおよびスピーカ
からなり、ＣＰＵ１１が作成した出力データＤout に対
して出力処理を行って、それが表す内容をユーザに提供
する。多重／分離部１６は、予め定められた多元接続方
式に従って、第１の通信制御部Ｐcc1 および第２の通信
制御部Ｐcc2 から受け取った取得要求Ｄcreqを多重す
る。また、多重／分離部１６は、送受信部１７から受け
取ったコンテンツデータＤc を分離する。より具体的に
は、送受信部１７からは、他の移動体通信装置Ｕcomm1
に向けられたコンテンツデータＤc も送られてくるの
で、多重／分離部１６は、自身向けのコンテンツデータ
Ｄc を、他者向けのコンテンツデータＤc から分離す
る。送受信部１７は、多重／分離部１６により多重化さ
れた取得要求Ｄcreqを通信網２に送出する。さらに、送
受信部１７は、通信網２上を伝送されてくるコンテンツ
データＤc を受信して、多重／分離部１６に渡す。

【００５４】次に、移動体通信装置Ｕcomm1 の動作につ
いて、図５のフローチャートを参照して説明する。ＣＰ
Ｕ１１は、ＲＯＭ１２に格納されたプログラムを実行す
る。ユーザは、入力装置１４を操作して、今回取得した
いコンテンツデータＤc の位置情報Ｉurl を入力する。
今回入力されたのは、メインコンテンツデータＤmcの位
置情報Ｉurl （つまり、ｕｒｌ0 ）であると仮定する。
ＣＰＵ１１は、まず、ブラウザ部Ｐbwとして動作し、取
得要求生成処理を行う（ステップＳ１０１）。より具体
的には、ＣＰＵ１１は、ステップＳ１０１において、入
力装置１４からの位置情報Ｉurl を含む取得要求Ｄcreq
を生成する。

【００５５】次に、ＣＰＵ１１は、プロトコル制御部Ｐ
pcとして動作し、コネクションが確立済みか否かを判断
する（ステップＳ１０２）。より具体的には、ステップ
Ｓ１０２において、ＣＰＵ１１は、パケット交換接続お
よび回線交換接続のいずれかで、サーバ３（図１参照）
にアクセス可能な状態であるか否かを判断する。コネク
ションが未確立の場合、ＣＰＵ１１は、今回の取得要求
Ｄcreqを第１の通信制御部Ｐcc1 に渡して、メインコン
テンツデータＤmcの取得を指示する（ステップＳ１０
３）。以上のステップＳ１０３までの処理が、プロトコ
ル制御部Ｐpcの処理である。

【００５６】第１の通信制御部Ｐcc1 は、ＣＰＵ１１の
指示に応答して、コンテンツサーバ３との間で第１の通
信路４pkt を確立する（ステップＳ１０４）。第１の通
信路４pkt を確立した状態で、第１の通信制御部Ｐcc1
は多重／分離部１６に取得要求Ｄcreqを渡す。多重／分
離部１６は、受信取得要求Ｄcreqを多重して、送受信部
１７に渡す。送受信部１７は、多重化された取得要求Ｄ
creqを、第１の通信路４pkt に送出する。以上のように
して、今回生成された取得要求Ｄcreqは第１の通信路４
pkt 上に送出される（ステップＳ１０５）。以上の取得
要求Ｄcreqはサーバ３により受信される。サーバ３は、
受信取得要求Ｄcreqに応答して、応答データＤrep1（図
２（ａ）参照）を生成する。応答データＤrep1は、第１
の通信路４pkt に送出される。

【００５７】移動体通信装置Ｕcomm1 において、送受信
部１７は、第１の通信路４pkt からの応答データＤrep1
を受信し、多重／分離部１６に渡す。多重／分離部１６
は、自身向けの応答データＤrep1を分離して、第１の通
信制御部Ｐcc1 に渡す。第１の通信制御部Ｐcc1 は、受
信応答データＤrep1をそのままＲＡＭ１３に格納する。
以上のようにして、応答データＤrep1は移動体通信装置
Ｕcomm1 により受信される（ステップＳ１０６）。ＣＰ
Ｕ１１は、ＲＡＭ１３に応答データＤrep1が格納される
と、プロトコル制御部Ｐpcとして動作する。そして、Ｃ
ＰＵ１１は、受信応答データＤrep1のコンテンツタイプ
Ｉctypから、後に続くコンテンツデータＤmcの種類を判
断する（ステップＳ１０７）。より具体的には、ＣＰＵ
１１は、コンテンツデータＤmcがＨＴＭＬで記述されて
いるか否かを判断する。今回の場合、応答データＤrep1
のコンテンツタイプＩctypはＨＴＭＬを示すので、ＣＰ
Ｕ１１は、ステップＳ１０８に進む。

【００５８】次に、ＣＰＵ１１は、ブラウザ部Ｐbwとし
て動作し、メインコンテンツデータＤmcの解析処理を行
って、各アンカータグＴanc1およびＴanc2の双方から、
位置情報Ｉurl および接続方法情報Ｉconn1 の組みを内
部情報として取り出す。さらに、ＣＰＵ１１は、取り出
した位置情報Ｉurl および接続方法情報Ｉconn1 の組み
を、図２（ｂ）に示す内部情報テーブルＴconn1 に記述
する。これによって、内部情報テーブルＴconn1 が作成
される（ステップＳ１０８）。さらに、ＣＰＵ１１は、
コンテンツデータＤmcが表すテキストの構造および配置
を解析して、出力データＤout をＲＡＭ１３上で生成す
る（ステップＳ１０９）。以上の出力データＤout は、
出力装置１５に転送され、当該出力装置１５は、出力デ
ータＤout に従って表示処理を行う。

【００５９】サブコンテンツデータＤsc1 またはＤsc2
を移動体通信装置Ｕcomm1 が取得する場合、ＣＰＵ１１
は、コンテンツの取得要求Ｄcreqを生成する（ステップ
Ｓ１０１）。今回の取得要求ＤcreqはＣＰＵ１１により
自動的に生成され、位置情報Ｉurl （つまり、ｕｒｌ1
またはｕｒｌ2 ）を含む。次に、ＣＰＵ１１は、コネク
ションが確立されているか否かを判断する（ステップＳ
１０２）。今回、第１の通信路４pkt を使ってデータ通
信が可能な状態であるから、ＣＰＵ１１はコネクション
が確立されていると判断する。この場合、ＣＰＵ１１
は、今回取得するコンテンツデータＤc がサブコンテン
ツデータＤscか否かを判断する（ステップＳ１０９）。
より具体的には、ＣＰＵ１１は、今回作成した取得要求
Ｄcreq内の位置情報Ｉurl と組みを構成する接続方法情
報Ｉconn1 が、ステップＳ１０８で作成した内部情報テ
ーブルＴconn1 （図２（ｂ）参照）にあるか否かを判断
する。

【００６０】接続方法情報Ｉconn1 がなければ、今回取
得するコンテンツデータＤc はメインコンテンツデータ
Ｄmcとみなすことができるので、ＣＰＵ１１は、ステッ
プＳ１０５に進み、以降の処理を続ける。一方、ステッ
プＳ１０９において、接続方法情報Ｉconn1 が見つかれ
ば、今回取得するコンテンツデータＤc はサブコンテン
ツデータＤscとみなされる。この場合、ＣＰＵ１１は、
位置情報Ｉurl と同じ組みの接続方法情報Ｉconn1 （接
続方法情報Ｉconn11またはＩconn12）を、内部情報テー
ブルＴconn1 から取得する（ステップＳ１０１１）。次
に、ＣＰＵ１１は、取得した接続方法情報Ｉconn1 が、
第２の通信路４tel を示しているか否かを判断する（ス
テップＳ１０１２）。

【００６１】ここで、今回の取得要求Ｄcreqに位置情報
Ｉurl としてｕｒｌ1 が設定される場合、ステップＳ１
０１１では、接続方法情報Ｉconn11が取得される。この
場合、ＣＰＵ１１は、取得した接続方法情報Ｉconn1 が
第２の通信路４tel を示していないと判断する。つま
り、ＣＰＵ１１は、サブコンテンツデータＤsc1 を、メ
インコンテンツデータＤmcと同様に、第１の通信路４pk
t を使って取得すると決定する。

【００６２】一方、ステップＳ１０１０において、今回
の取得要求Ｄcreqに位置情報Ｉurl としてｕｒｌ2 が設
定される場合、ステップＳ１０１１では、接続方法情報
Ｉconn12が取得される。この場合、ＣＰＵ１１は、取得
した接続方法情報Ｉconn1 が、第２の通信路４tel を示
していると判断する。つまり、コンテンツデータＤsc2
は回線交換接続で取得されると、ＣＰＵ１１により決定
される。この場合、ＣＰＵ１１は、ステップＳ１０１２
に進み、まず、第１の通信制御部Ｐcc1 に対してコネク
ション（第１の通信路４pkt ）の切断を指示する。さら
に、ＣＰＵ１１は、今回生成した取得要求Ｄcreqを第２
の通信制御部Ｐcc2 に渡して、サブコンテンツデータＤ
sc2 の取得を指示する（ステップＳ１０１３）。以上の
ステップＳ１０１０〜Ｓ１０１３までも、プロトコル制
御部Ｐpcの処理に属する。

【００６３】第１の通信制御部Ｐcc1 は、ＣＰＵ１１の
指示に応答して、コンテンツサーバ３との間で確立され
ていた第１の通信路４pkt を切断する。また、第２の通
信制御部Ｐcc2 は、ＣＰＵ１１の指示に応答して、回線
交換接続の規定に従って、コンテンツサーバ３との間で
第２の通信路４tel を確立する（ステップＳ１０１
４）。第２の通信路４tel を確立した状態で、第２の通
信制御部Ｐcc2 は、多重／分離部１６に取得要求Ｄcreq
を渡す。多重／分離部１６は、受信取得要求Ｄcreqを多
重して、送受信部１７に渡す。送受信部１７は、多重化
された取得要求Ｄcreqを、第２の通信路４tel に送出す
る。以上のようにして、今回生成された取得要求Ｄcreq
は第２の通信路４tel 上に送出される（ステップＳ１０
５）。その結果、サブコンテンツデータＤsc2 は、メイ
ンコンテンツデータＤmcとは異なり、第２の通信路４te
l を使って取得される。

【００６４】ところで、図３（ａ）を参照して説明した
ように、サブコンテンツデータＤsc1 およびＤsc2 は静
止画および音楽を表しており、厳密にはＨＴＭＬで作成
されたものではない。そのため、ＣＰＵ１１は、原則的
に、ステップＳ１０７においてＮｏと判断する。この場
合、ＣＰＵ１１は、サブコンテンツデータＤsc1 および
Ｄsc2 から内部情報を取得することなく、当該サブコン
テンツデータＤsc1 およびＤsc2 を基礎にして出力デー
タＤout を作成して出力装置１５に転送する（ステップ
Ｓ１０９）。出力装置１５は、受信サブコンテンツデー
タＤsc1 およびＤsc2 に従って、静止画の表示処理およ
び音楽の再生処理を行う。

【００６５】図６は、本発明の第２の実施形態に係るコ
ンテンツ取得装置１b の機能ブロック図である。さら
に、図６には、コンテンツ取得装置１b に付随して、通
信網２と、コンテンツサーバ３とが示されている。コン
テンツ取得装置１b は、コンテンツ取得装置１a と同様
に、マルチコール機能により、パケット交換接続時に
は、第１の通信路４pkt を使ってコンテンツサーバ３に
アクセスし、回線交換接続時には、第２の通信路４tel
にアクセスする。以上のデータ通信を実現するために、
コンテンツ取得装置１b は、コンテンツ取得装置１a と
比較して、接続情報管理部Ｐconn1 をさらに備える点で
相違する。両者の間に、それ以外に構成面での相違点は
無いので、図６において、図１の構成に相当するものに
は同一の参照符号を付す。

【００６６】接続情報管理部Ｐconn1 は、図７（ａ）に
示すような接続情報テーブルＴconn2 を予め保持し、管
理している。接続情報テーブルＴconn2 には、コンテン
ツタイプＩctypおよび、第１の実施形態と同様の接続方
法情報Ｉconn1 の組みが予め記述されている。コンテン
ツタイプＩctypは、各コンテンツデータＤc の種類を示
す情報である。これによって、各コンテンツデータＤc
のコンテンツタイプＩctyp毎に、パケット交換接続およ
び回線交換接続のいずれが好適であるかが示される。本
実施形態では、ＨＴＭＬファイルには、ｔｅｘｔ／ｈｔ
ｍｌというコンテンツタイプＩctypが割り当てられ、動
画ファイルには、ｖｉｄｅｏ／ｍｐｅｇというコンテン
ツタイプＩctypが割り当てられる。また、ＨＴＭＬファ
イルに関しては通信遅延およびデータ通信の中断が致命
的ではないことから、ｔｅｘｔ／ｈｔｍｌと組みをなす
のは、接続方法情報Ｉconn11（パケット交換接続）であ
ることが好ましい。一方、動画ファイルに関しては通信
遅延等が致命的である点から、ｖｉｄｅｏ／ｍｐｅｇと
組みをなすのは、接続方法情報Ｉconn12（回線交換接
続）であることが好ましい。

【００６７】また、コンテンツサーバ３は、第１の実施
形態と同様に、いくつかのコンテンツデータＤc を格納
している。ただし、第１の実施形態では、アンカータグ
Ｔanc の属性値として、好適な接続方法そのもの（接続
方法情報Ｉconn1 ）がメインコンテンツデータＤmcに記
述されていた。それに対し、第２の実施形態では、アン
カータグＴanc の属性値として、サブコンテンツデータ
Ｄscの種類を示すコンテンツタイプＩctypが追加され
る。本実施形態では、コンテンツタイプＩctypは２種類
準備されており、一方のコンテンツタイプＩctyp1 は、
アンカータグＴanc により指定されるサブコンテンツデ
ータＤscがＨＴＭＬファイルであることを示しており、
ｔｙｐｅ＝ｔｅｘｔ／ｈｔｍｌと記される。他方のコン
テンツタイプＩctyp2 は、アンカータグＴanc により指
定されるサブコンテンツデータＤscが動画ファイルであ
ることを示しており、ｔｙｐｅ＝ｖｉｄｅｏ／ｍｐｅｇ
と記される。

【００６８】図６には、例示的に、１つのメインコンテ
ンツデータＤmcと、サブコンテンツデータＤscとして、
２つのサブコンテンツデータＤsc1 およびＤsc1 とが示
される。メインコンテンツデータＤmcの位置情報Ｉurl
はｕｒｌ0 とする。サブコンテンツデータＤsc1 は、前
述したように、通信遅延およびデータ通信の中断が致命
的ではないＨＴＭＬファイルであり、サブコンテンツデ
ータＤsc2 は、通信遅延等が致命的な動画ファイルであ
ると仮定する。また、サブコンテンツデータＤsc1 およ
びＤsc2 の位置情報Ｉurl はｕｒｌ1 でおよびｕｒｌ2
であると仮定する。以上の仮定下では、メインコンテン
ツデータＤmcには、アンカータグＴancとして、２つの
アンカータグＴanc1およびＴanc2が記述される。アンカ
ータグＴanc1には、“ｈｒｅｆ＝ｕｒｌ1 ”と共に、
“ｔｙｐｅ＝ｔｅｘｔ／ｈｔｍｌ”が記される。また、
アンカータグＴanc2には、“ｈｒｅｆ＝ｕｒｌ2 ”と共
に、“ｔｙｐｅ＝ｖｉｄｅｏ／ｍｐｅｇ”が記される。

【００６９】上記構成のコンテンツ取得装置１b の動作
について、次に説明する。コンテンツ取得装置１b は、
第１の実施形態においてコンテンツ取得装置１a と同様
の手法で、メインコンテンツデータＤmcをコンテンツサ
ーバ３から取得する。つまり、メインコンテンツデータ
Ｄmcは、プロトコル制御部Ｐpcから、解析指示と共にブ
ラウザＰbwに渡される。この指示に応答して、ブラウザ
部Ｐbwは、コンテンツデータＤmcにより表されるテキス
トの構造および配置を解析して、当該テキストを表す出
力データＤout を作成する。さらに、ブラウザ部Ｐbw
は、今回の受信コンテンツデータＤmcの各アンカータグ
Ｔanc1およびＴanc2から、位置情報Ｉurl およびコンテ
ンツタイプＩctypの組みを内部情報として取り出して、
当該内部情報を内部情報テーブルＴctypに記述し保持す
る。図７（ｂ）に示すように、内部情報テーブルＴctyp
は、位置情報Ｉurl およびコンテンツタイプＩctypの組
みが記述されるように予め構成されており、これによっ
て、各サブコンテンツデータＤscのコンテンツタイプＩ
ctypが分かるようになっている。本実施形態の説明で
は、図６に示すように、アンカータグＴanc1には、“ｈ
ｒｅｆ＝ｕｒｌ1 ”および“ｔｙｐｅ＝ｔｅｘｔ／ｈｔ
ｍｌ”の組みが記され、アンカータグＴanc2には、“ｈ
ｒｅｆ＝ｕｒｌ2 ”および“ｔｙｐｅ＝ｖｉｄｅｏ／ｍ
ｐｅｇ”が記されるので、内部情報テーブルＴctypに
は、図７（ｂ）に示すように、ｕｒｌ1 およびｔｅｘｔ
／ｈｔｍｌの組みと、ｕｒｌ2 およびｖｉｄｅｏ／ｍｐ
ｅｇの組みとが記述される。

【００７０】サブコンテンツデータＤsc1 を取得する場
合、プロトコル制御部Ｐpcには、位置情報Ｉurl として
のｕｒｌ1 を含む取得要求Ｄcreqがブラウザ部Ｐbwから
送られてくる。プロトコル制御部Ｐpcは、受信取得要求
Ｄcreqに含まれる位置情報Ｉurl を取り出した後、それ
と同じ組みのコンテンツタイプＩctyp（今回の場合、ｔ
ｅｘｔ／ｈｔｍｌ）を、ブラウザ部Ｐbwの内部情報テー
ブルＴctyp（図７（ｂ）参照）から取得する。次に、プ
ロトコル制御部Ｐpcは、今回取得するサブコンテンツデ
ータＤscを、パケット交換接続で取得するか、回線交換
接続で取得するかを決定する。そのために、プロトコル
制御部Ｐpcは、内部情報テーブルＴctypから取得したコ
ンテンツタイプＩctypと一致するものが接続情報テーブ
ルＴconn2 にあるかどうかを、接続情報管理部Ｐconn1
に問い合わせる。接続情報管理部Ｐconn1 は、問い合わ
されたコンテンツタイプＩctypと一致するものが接続情
報テーブルＴconn2 に記述されていれば、当該コンテン
ツタイプＩctypと同じ組みの接続方法情報Ｉconn1 （今
回の場合、接続方法情報Ｉconn11（つまり、ｐａｃｋｅ
ｔ））をプロトコル制御部Ｐpcに返す。プロトコル制御
部Ｐpcは、接続情報管理部Ｐconn1 から取得した接続方
法情報Ｉconn1 に従って、今回取得するサブコンテンツ
データＤsc1 を、パケット交換接続で取得するか、回線
交換接続で取得するかを決定する。今回の場合、接続方
法情報Ｉconn11が取得されるので、パケット交換接続が
好適であると決定される。以降の動作については、第１
の実施形態と同様であるため、その説明を省略する。

【００７１】また、サブコンテンツデータＤsc2 を取得
する場合、プロトコル制御部Ｐpcには、位置情報Ｉurl
としてのｕｒｌ2 を含む取得要求Ｄcreqが送られてく
る。プロトコル制御部Ｐpcは、受信取得要求Ｄcreqから
位置情報Ｉurl と同じ組みのコンテンツタイプＩctyp
（今回の場合、ｖｉｄｅｏ／ｍｐｅｇ）を、ブラウザ部
Ｐbwの内部情報テーブルＴctypから取得する。次に、プ
ロトコル制御部Ｐpcは、内部情報テーブルＴctypから取
得したコンテンツタイプＩctypと一致するものが接続情
報テーブルＴconn2 にあるかどうかを、接続情報管理部
Ｐconn1 に問い合わせる。接続情報管理部Ｐconn1 は、
接続情報テーブルＴconn2 に記述されていれば、コンテ
ンツタイプＩctypと同じ組みの接続方法情報Ｉconn1
（今回の場合、接続方法情報Ｉconn12（ｔｅｌ））を
プロトコル制御部Ｐpcに返す。プロトコル制御部Ｐpc
は、接続情報管理部Ｐconn1 から取得した接続方法情報
Ｉconn1 に従って、今回取得するサブコンテンツデータ
Ｄsc2 を、パケット交換接続で取得するか、回線交換接
続で取得するかを決定する。今回の場合、接続方法情報
Ｉconn12が取得されるので、パケット交換接続が好適で
あると決定される。以降の動作については、第１の実施
形態と同様であるため、その説明を省略する。

【００７２】以上説明したように、メインコンテンツデ
ータＤmcには、各サブコンテンツデータＤscのコンテン
ツタイプＩctypが記述される。さらに、コンテンツ取得
装置１b は、コンテンツタイプＩctypおよび接続方法情
報Ｉconn1 の組みが予め記述される接続情報テーブルＴ
conn2 を保持している。コンテンツ取得装置１b は、メ
インコンテンツデータＤmcを解析して、位置情報Ｉurl
およびコンテンツタイプＩctypの組みを内部情報テーブ
ルＴctypに記述する。コンテンツ取得装置１b は、内部
情報テーブルＴctypおよび接続情報テーブルＴconn2 を
参照することにより、サブコンテンツデータＤscの取得
前に、そのための好適な接続方法を知ることができる。

【００７３】なお、第２の実施形態では、コンテンツデ
ータＤc 内にコンテンツタイプＩctypが記述されてお
り、接続情報管理部Ｐconn1 は、コンテンツタイプＩct
yp毎に接続方法情報Ｉconn1 を管理していた。しかし、
これだけに限らず、コンテンツデータＤc 内に当該コン
テンツデータＤc の属性が記述されている場合には、当
該コンテンツデータＤc の属性毎に接続方法情報Ｉconn
1 を管理しても良い。コンテンツデータＤc の属性を示
すものの例としては、ファイル名、ファイルの拡張子、
およびコンテンツ長Ｉclg がある。特に、コンテンツデ
ータＤc 内にコンテンツ長Ｉclg が記述されており、接
続情報管理部Ｐconn1 は、コンテンツ長Ｉclg 毎に接続
方法情報Ｉconn1 を管理する場合、取得すべきコンテン
ツデータＤc の長さＩclg を、接続情報管理部Ｐconn1
が管理するコンテンツ長Ｉclg と比較して、取得する接
続方法情報Ｉconn1 を決定する。

【００７４】また、第２の実施形態では、コンテンツデ
ータＤc 内にコンテンツタイプＩctypが記述されていた
が、これに限らず、コンテンツ取得装置１b は、サブコ
ンテンツデータＤscの一部分を先に取得して、それを解
析して、当該コンテンツデータＤscのデータフォーマッ
ト（つまり、コンテンツタイプＩctyp）を特定するよう
にしてもよい。この場合、コンテンツ取得装置１b は、
特定したコンテンツタイプＩctypに基づいて、接続方法
情報Ｉconn1 を取得する。

【００７５】次に、上記コンテンツ取得装置１b を組み
込んだ移動体通信装置Ｕcomm2 について説明する。移動
体通信装置Ｕcomm2 は、移動体通信装置Ｕcomm1 と同様
の構成を有するので、以下の説明では、図４を援用す
る。次に、以上のような構成の移動体通信装置Ｕcomm2
の動作について、図８のフローチャートを参照して説明
する。図８は、図５と比較すると、ステップＳ１０８、
Ｓ１０１０およびＳ１０１１がステップＳ２０１、Ｓ２
０２およびＳ２０３に代わる点で相違する。それ以外に
両者には相違点は無いので、図８において、図５のステ
ップに相当するものには、同一の番号を付し、その説明
を省略する。

【００７６】移動体通信装置Ｕcomm2 がコンテンツデー
タＤc の取得を行う場合、最初に、ＣＰＵ１１は、ＲＯ
Ｍ１２からプログラムをＲＡＭ１３に読み出す。本実施
形態におけるプログラムには、図７（ａ）に示す接続情
報テーブルＴconn2 が予め記述されている。接続情報テ
ーブルＴconn2 は、プログラムの読み出しと共に、ＲＡ
Ｍ１３に読み出される。さて、移動体通信装置Ｕcomm2
は、メインコンテンツデータＤmcを取得するために、ス
テップＳ１０１〜Ｓ１０７を実行する。ＣＰＵ１１は、
応答データＤrep1（図２（ａ）参照）のコンテンツタイ
プＩctypがＨＴＭＬを示すことから、ステップＳ１０７
の後、ステップＳ２０１を実行する。そこで、ＣＰＵ１
１は、メインコンテンツデータＤmcの解析処理を行っ
て、各アンカータグＴanc1およびＴanc2の双方から、位
置情報Ｉurl およびコンテンツタイプＩctypの組みを内
部情報として取り出す。さらに、ＣＰＵ１１は、取り出
した内部情報をＲＡＭ１３に格納し、図７（ｂ）に示す
内部情報テーブルＴctypを作成する（ステップＳ２０
１）。その後、ＣＰＵ１１は、ステップＳ１０９を行
う。

【００７７】サブコンテンツデータＤsc1 またはＤsc2
を移動体通信装置Ｕcomm2 が取得する場合、ＣＰＵ１１
は、ステップＳ１０１およびＳ１０２を実行した後に、
ステップＳ２０２を実行する。そこで、ＣＰＵ１１は、
今回取得するコンテンツデータＤc がサブコンテンツデ
ータＤscか否かを判断する（ステップＳ２０２）。より
具体的には、ＣＰＵ１１は、今回作成した取得要求Ｄcr
eqに含まれる位置情報Ｉurl と同じものがステップＳ２
０１で作成した内部情報テーブルＴctyp（図７（ｂ）参
照）にあるか否かを判断する。

【００７８】同じ位置情報Ｉurl がなければ、今回取得
するのはメインコンテンツデータＤmcとみなせるので、
ＣＰＵ１１は、ステップＳ１０５に進む。一方、ステッ
プＳ２０２において、同じ位置情報Ｉurl が見つかれ
ば、今回取得するのは、サブコンテンツデータＤscであ
るとみなすことができる。この場合、ＣＰＵ１１は、ス
テップＳ２０３に進み、まず、取得した位置情報Ｉurl
と同じ組みのコンテンツタイプＩctyp（ｔｅｘｔ／ｈｔ
ｍｌおよびｖｉｄｅｏ／ｍｐｅｇのいずれか）を、内部
情報テーブルＴctypから取得する。次に、ＣＰＵ１１
は、プログラムと共にＲＡＭ１３上に読み出されている
接続情報テーブルＴconn2 （図７（ａ）参照）にアクセ
スして、取得したコンテンツタイプＩctypと同じ組みの
接続方法情報Ｉconn1 （ｐａｃｋｅｔまたはｔｅｌ）を
取得する。次に、ＣＰＵ１１は、ステップＳ１０１２に
進むが、これ以降の処理については、第１の実施形態と
同様であるため、その説明を省略する。

【００７９】図９は、本発明の第３の実施形態に係るコ
ンテンツ取得装置１c の機能ブロック図である。さら
に、図９には、コンテンツ取得装置１c に付随して、通
信網２と、コンテンツサーバ３とが示されている。コン
テンツ取得装置１c は、コンテンツ取得装置１a と同様
に、マルチコール機能により、パケット交換接続時に
は、第１の通信路４pkt を使ってコンテンツサーバ３に
アクセスし、回線交換接続時には、第２の通信路４tel
にアクセスする。以上のデータ通信を実現するために、
コンテンツ取得装置１c は、コンテンツ取得装置１a と
比較して、接続情報管理部Ｐconn2 をさらに備える点で
相違する。両者の間に、それ以外に構成面での相違点は
無いので、図９において、図１の構成に相当するものに
は同一の参照符号を付す。

【００８０】接続情報管理部Ｐconn2 は、図１０に示す
接続情報テーブルＴconn3 を予め管理している。接続情
報テーブルＴconn3 には、位置情報Ｉurl の特徴（また
は位置情報Ｉurl の一部分）および、第１の実施形態と
同様の接続方法情報Ｉconn1 の組みが予め記述されてい
る。位置情報Ｉurl （つまり、ｕｒｌ）は、コンテンツ
データＤc に一意に割り当てられており、当該コンテン
ツデータＤc の格納位置を示す。さらに、位置情報Ｉur
l の一部分は、コンテンツデータＤc の特徴を示す。よ
り具体的には、位置情報Ｉurl の一部分である末尾に
は、コンテンツデータＤc の特徴を表す拡張子が付加さ
れている。位置情報Ｉurl の特徴および接続方法情報Ｉ
conn1 の組みによって、位置情報Ｉurl の特徴毎に、パ
ケット交換接続および回線交換接続のいずれが好適であ
るかが示される。通常、ＨＴＭＬファイルには、http:/
/www.xxx.co.jp/yyy.htmlのような形式の位置情報Ｉurl
が割り当てられ、その拡張子は．ｈｔｍｌである。ま
た、ＨＴＭＬファイルに関しては通信遅延およびデータ
通信の中断が致命的ではないことから、．ｈｔｍｌと組
みをなすのは、接続方法情報Ｉconn11（パケット交換接
続）であることが好ましい。また、動画ファイルには、
それがＭＰＥＧ(Motion Picture Experts Group)に従っ
て作成されている場合には、http://www.xxx.co.jp/zz
z.mpgのような形式の位置情報Ｉurl が割り当てられ、
その拡張子は．ｍｐｇである。動画ファイルに関しては
通信遅延等が致命的である点から、．ｍｐｇと組みをな
すのは、接続方法情報Ｉconn12（回線交換接続）である
ことが好ましい。

【００８１】また、コンテンツサーバ３は、第１の実施
形態と同様に、いくつかのコンテンツデータＤc （図示
は３つ）を格納している。また、各コンテンツデータＤ
c には、上述の位置情報Ｉurl が割り当てられる。な
お、第１の実施形態では、アンカータグＴanc の属性値
として、好適な接続方法そのものがメインコンテンツデ
ータＤmcに記述されていた。それに対し、第３の実施形
態では、アンカータグは、コンテンツ取得装置１c の本
質と無関係であるから、図示されていない。

【００８２】上記構成のコンテンツ取得装置１c の動作
について、次に説明する。プロトコル制御部Ｐpcには、
コンテンツデータＤc の位置情報Ｉurl を含むコンテン
ツの取得要求Ｄcreqが送られてくる。プロトコル制御部
Ｐpcは、受信取得要求Ｄcreqに応答して、今回のコンテ
ンツデータＤc の取得に好適な接続方法を決定する。ま
ず、プロトコル制御部Ｐpcは、受信取得要求Ｄcreqか
ら、位置情報Ｉurl の特徴、つまり、拡張子を取り出
す。プロトコル制御部Ｐpcは、取り出した位置情報Ｉur
l の特徴と一致するものが接続情報テーブルＴconn3
（図１０参照）にあるかどうかを、接続情報管理部Ｐc
onn2 に問い合わせる。接続情報管理部Ｐconn2 は、問い
合わせされた位置情報Ｉurl の特徴と一致するものが接
続情報テーブルＴconn3 に記述されていれば、当該位置
情報Ｉurl の特徴と同じ組みの接続方法情報Ｉconn1 を
プロトコル制御部Ｐpcに返す。プロトコル制御部Ｐpc
は、受信接続方法情報Ｉconn1 に従って、今回取得する
コンテンツデータＤc を、パケット交換接続で取得する
か、回線交換接続で取得するかを決定する。これ以降の
動作については、第１の実施形態と同様であるため、そ
の説明を省略する。

【００８３】以上説明したように、各コンテンツデータ
Ｄc には、その特徴を表す位置情報Ｉurl が割り当てら
れる。コンテンツ取得装置１c は、位置情報Ｉurl の特
徴毎に接続方法情報Ｉconn1 が記述された接続情報テー
ブルＴconn3 を予め保持する。コンテンツ取得装置１c
は、取得要求Ｄcreqから、位置情報Ｉurl の特徴を取り
出す。取り出した位置情報Ｉurl の特徴および接続情報
テーブルＴconn3 を使うことにより、コンテンツ取得装
置１c は、各コンテンツデータＤc を取得する前に、両
者を取得するのに好適な接続方法を知ることができる。

【００８４】なお、第３の実施形態では、接続情報テー
ブルＴconn3 には、拡張子毎に接続方法情報Ｉconn1 が
記述されており、プロトコル制御部Ｐpcは、取得するコ
ンテンツデータＤc の位置情報Ｉurl の拡張子に基づい
て、接続方法情報Ｉconn1 を取得していた。しかし、拡
張子だけに限らず、位置情報Ｉurl の一部、つまり、ホ
スト名、パスの一部または全部、スキームまたはポート
番号を接続情報テーブルＴconn3 に記述してもよい。こ
の場合、プロトコル制御部Ｐpcは、取得するコンテンツ
データＤc の位置情報Ｉurl から、接続情報テーブルＴ
conn3 に記述された情報（ホスト名、パスの一部または
全部、スキームまたはポート番号）に相当するものを取
得する。

【００８５】次に、上記コンテンツ取得装置１c が実装
される移動体通信装置Ｕcomm3 について説明する。移動
体通信装置Ｕcomm3 は、移動体通信装置Ｕcomm1 のそれ
と同様の構成を有するので、以下の説明では図４を援用
する。次に、移動体通信装置Ｕcomm3 の動作について、
図１１のフローチャートを参照して説明する。

【００８６】移動体通信装置Ｕcomm3 がコンテンツデー
タＤc の取得を行う場合、最初に、ＣＰＵ１１は、ＲＯ
Ｍ１２からプログラムをＲＡＭ１３に読み出す。本実施
形態におけるプログラムには、図１０に示す接続情報テ
ーブルＴconn3 が予め記述されている。接続情報テーブ
ルＴconn3 は、プログラムの読み出しと共に、ＲＡＭ１
３に読み出される。さて、移動体通信装置Ｕcomm3 がコ
ンテンツデータＤc を取得する時、ＣＰＵ１１は、ま
ず、ブラウザ部Ｐbwとして動作し、取得要求作成処理を
行う（ステップＳ３０１）。より具体的には、ＣＰＵ１
１は、ステップＳ３０１において、入力装置１４から得
られる位置情報Ｉurl を含む取得要求Ｄcreqを生成す
る。

【００８７】次に、ＣＰＵ１１は、プロトコル制御部Ｐ
pcとして動作し、今回得た位置情報Ｉurl から、今回取
得するコンテンツデータＤc の特徴を示す拡張子を取得
する（ステップＳ３０２）。次に、ＣＰＵ１１は、今回
取得した位置情報Ｉurl の特徴と同じ組みを構成する接
続情報Ｉconn1 を、ＲＡＭ１３上の接続情報テーブルＴ
conn3 から取得する（ステップＳ３０３）。ＣＰＵ１１
は、取得した接続方法情報Ｉconn1 に従って、今回のコ
ンテンツデータＤc を、パケット交換接続で取得する
か、回線交換接続で取得するかを決定する（ステップＳ
３０４）。取得したものが接続方法情報Ｉconn11の場
合、今回のコンテンツデータＤ_c の取得には、パケット
交換接続が好適であると決定する。接続方法情報Ｉconn
12の場合には、回線交換接続が好適であると決定され
る。

【００８８】次に、ＣＰＵ１１は、コンテンツサーバ３
とのコネクションが既に確立されているか否かを判断す
る（ステップＳ３０５）。より具体的には、ＣＰＵ１１
は、パケット交換接続および回線交換接続のいずれかを
使って、サーバ３（図９参照）にアクセス可能な状態で
あるか否かを判断する。コネクションが未確立の場合、
ＣＰＵ１１は、今回生成した取得要求Ｄcreqを、第１の
通信制御部Ｐcc1 および第２の通信制御部Ｐcc2 のいず
れかに渡して、コンテンツデータＤc の取得を指示する
（ステップＳ３０６）。ここで、ステップＳ３０４にお
いてパケット交換接続が好適であると決定された場合、
ＣＰＵ１１は、今回生成した取得要求Ｄcreqを、第１の
通信制御部Ｐcc1 に渡す。ＣＰＵ１１は、逆に、回線交
換接続が好適であると決定した場合、第２の通信制御部
Ｐcc2 に渡す。以上のステップＳ３０６までの処理が、
プロトコル制御部Ｐpcの処理である。

【００８９】第１の通信制御部Ｐcc1 または第２の通信
制御部Ｐcc2 は、ＣＰＵ１１からの指示があった場合に
限り、コンテンツサーバ３との間で第１の通信路４pkt
または第２の通信路４tel を確立する（ステップＳ３０
７）。第１の通信路４pkt または第２の通信路４tel を
確立した状態で、第１の通信制御部Ｐcc1 または第２の
通信制御部Ｐcc2 は、多重／分離部１６および送受信部
１７の双方を介して、取得要求Ｄcreqを、第１の通信路
４pkt または第２の通信路４tel に送出する。以上のよ
うにして、取得要求Ｄcreqは第１の通信路４pkt または
第２の通信路４tel 上に送出される（ステップＳ３０
８）。その結果、コンテンツサーバ３は、受信取得要求
Ｄcreqに応答して、図２（ａ）に示すような応答データ
Ｄrep を生成して、現在移動体通信装置Ｕcomm3 との間
で確立されている第１の通信路４pkt または第２の通信
路４tel 上に送出する。

【００９０】移動体通信装置Ｕcomm3 において、第１の
通信制御部Ｐcc1 は、第１の通信路４pkt または第２の
通信路４tel 、送受信部１７および多重／分離部１６を
介して、自身向けの応答データＤrep を受け取る。第１
の通信制御部Ｐcc1 は、受信応答データＤrep をそのま
まＲＡＭ１３に格納する。これによって、ＣＰＵ１１
は、応答データＤrep を受信する。これ以降、ＣＰＵ１
１は、プロトコル制御部Ｐpcとして動作し、ＲＡＭ１３
上の応答データＤrep を解析する（ステップＳ３０
９）。その後、ＣＰＵ１１は、ブラウザ部Ｐbwとして動
作し、コンテンツデータＤc に従って出力データＤout
をＲＡＭ１３上で生成する（ステップＳ３１０）。以上
の出力データＤout は、出力装置１５に転送され、出力
処理される。

【００９１】ところで、コンテンツ取得装置１c は、コ
ネクションの確立後、さらに、コンテンツ取得要求Ｄcr
eqを生成することがあるので、ＣＰＵ１１は、ステップ
Ｓ３０５で、コネクションが確立済みであると判断する
場合がある。かかる場合、ＣＰＵ１１は、コネクション
の切り替えが必要か否かを判断する（ステップＳ３１
１）。より具体的には、ＣＰＵ１１は、コンテンツサー
バ３とのデータ通信に現在使用している通信路４（第１
の通信路４pkt または第２の通信路４tel ）が、ステッ
プＳ３０４で決定した通信路４と一致するか否かを判断
する。両者が一致する場合、新たにコネクションを確立
する必要がないので、ＣＰＵ１１は、ステップＳ３０７
に進む。逆に、ステップＳ３０４で決定した通信路４
が、現在使用中のものと異なる場合、ＣＰＵ１１は、ス
テップＳ３１２に進む。ＣＰＵ１１は、まず、第１の通
信制御部Ｐcc1 および第２の通信制御部Ｐcc2 の内、現
在データ通信を行っている側に対してコネクション（第
１の通信路４pkt または第２の通信路４tel ）の切断を
指示する。さらに、ＣＰＵ１１は、今回生成した取得要
求Ｄcreqを、第１の通信制御部Ｐcc1 および第２の通信
制御部Ｐcc2 の内、ステップＳ３０４で決定した側に渡
すと共に、コンテンツデータＤc の取得を指示する（ス
テップＳ３１２）。その後、コンテンツ取得装置１c で
はステップＳ３０８が実行される。

【００９２】図１２は、本発明の第４の実施形態に係る
コンテンツ取得装置１d の機能ブロック図である。さら
に、図１２には、コンテンツ取得装置１d に付随して、
通信網２と、コンテンツサーバ３とが示されている。コ
ンテンツ取得装置１d は、コンテンツ取得装置１b と同
様の構成を有するので、その説明を省略する。また、コ
ンテンツサーバ３は、第３の実施形態と同様に、いくつ
かのコンテンツデータＤc （図示は３つ）を格納してい
る。

【００９３】上記構成のコンテンツ取得装置１d の動作
について、次に説明する。プロトコル制御部Ｐpcには、
ブラウザ部Ｐbwにより生成されたコンテンツの取得要求
Ｄcreqが送られてくる。前述と同様に、取得要求Ｄcreq
には、今回取得すべきコンテンツデータＤc の位置情報
Ｉurl が含まれる。プロトコル制御部Ｐpcは、取得要求
Ｄcreqの受信に応答して、ヘッダの取得要求Ｄhreqを生
成する。ヘッダの取得要求Ｄhreqは、今回取得されるコ
ンテンツデータＤc 用の応答ヘッダＨc のみ（図２
（ａ）および第１の実施形態参照）を送信するようコン
テンツサーバ３に要求するためのデータである。また、
取得要求Ｄhreqには、コンテンツデータＤcを特定する
ための位置情報Ｉurl が設定される。プロトコル制御部
Ｐpcは、既にコンテンツサーバ３とのデータ通信が行わ
れている場合には、第１の通信制御部Ｐcc1 および第２
の通信制御部Ｐcc2 の内、現在データ通信を行っている
側に、生成した取得要求Ｄhreqを渡して、応答ヘッダＨ
c の取得を指示する。第１の通信制御部Ｐcc1 または第
２の通信制御部Ｐcc2 は、プロトコル制御部Ｐpcからの
指示があった場合に限り、第１の通信路４pkt または第
２の通信路４tel を介して、コンテンツサーバ３に取得
要求Ｄhreqを送信する。

【００９４】一方、プロトコル制御部Ｐpcは、取得要求
Ｄhreqの生成終了後、コンテンツサーバ３とのデータ通
信が行われていない場合には、好ましくは、第１の通信
制御部Ｐcc1 に、生成した取得要求Ｄhreqを渡して、応
答ヘッダＨc の取得を指示する。第１の通信制御部Ｐcc
1 に渡されるのは、第１の通信路４pkt の方が通信コス
トが安いからである。第１の通信制御部Ｐcc1 は、プロ
トコル制御部Ｐpcからの指示に応答して、第１の通信路
４pkt を介して、コンテンツサーバ３に取得要求Ｄhreq
を送信する。

【００９５】コンテンツサーバ３は、受信取得要求Ｄhr
eqで指定された位置情報Ｉurl に基づいて、コンテンツ
データＤc 用の応答ヘッダＨc を作成する。応答ヘッダ
Ｈcのフォーマットは、図２（ａ）に示す通りである。
以上の応答ヘッダＨc は、コンテンツサーバ３により、
第１の通信路４pkt または第２の通信路４tel を介し
て、コンテンツ取得装置１d に送信される。

【００９６】コンテンツ取得装置１d において、第１の
通信制御部Ｐcc1 または第２の通信制御部Ｐcc2 は、第
１の通信路４pkt または第２の通信路４tel を介して、
応答ヘッダＨc を受信し、そのままプロトコル制御部Ｐ
pcに渡す。プロトコル制御部Ｐpcは、受信応答ヘッダＨ
c からコンテンツタイプＩctypを取り出した後、取り出
したコンテンツタイプＩctypと同じ組みを構成する接続
方法情報Ｉconn1 を、接続情報管理部Ｐconn1 の接続情
報テーブルＴconn2 （図７（ａ）参照）から取得する。
プロトコル制御部Ｐpcは、取得した接続方法情報Ｉconn
1 に従って、今回のコンテンツデータＤc を、パケット
交換接続で取得するか、回線交換接続で取得するかを決
定する。接続方法情報Ｉconn11が取得されると仮定する
と、パケット交換接続が好適であると決定される。逆
に、接続方法情報Ｉconn12が取得されると仮定すると、
回線交換接続が好適であると決定される。

【００９７】取得された接続方法情報Ｉconn1 により特
定される通信路４（第１の通信路４pkt または第２の通
信路４tel ）が、ヘッダの取得要求Ｄhreqの送信時に使
用されたものと同じ場合、プロトコル制御部Ｐpcは、第
１の通信制御部Ｐcc1 および第２の通信制御部Ｐcc2 の
内、現在データ通信を行っている側に、先にブラウザ部
Ｐbwから受け取った取得要求Ｄcreqを渡して、コンテン
ツデータＤc の取得を指示する。第１の通信制御部Ｐcc
1 または第２の通信制御部Ｐcc2 は、プロトコル制御部
Ｐpcからの指示があった場合に限り、第１の通信路４pk
t または第２の通信路４tel を介して、コンテンツサー
バ３に取得要求Ｄcreqを送信する。

【００９８】逆に、取得された接続方法情報Ｉconn1 に
より特定される通信路４が、ヘッダの取得要求Ｄhreqの
送信に使用された通信路４と異なる場合、プロトコル制
御部Ｐpcは、第１の通信制御部Ｐcc1 および第２の通信
制御部Ｐcc2 の内、現在データ通信を行っている側に、
コネクションの切断を指示する。さらに、プロトコル制
御部Ｐpcは、第１の通信制御部Ｐcc1 および第２の通信
制御部Ｐcc2 の内、現在データ通信を行っていない側
に、先にブラウザ部Ｐbwから受け取った取得要求Ｄcreq
を渡して、コンテンツデータＤc の取得を指示する。第
１の通信制御部Ｐcc1 および第２の通信制御部Ｐcc2 の
いずれか一方は、プロトコル制御部Ｐpcから切断指示が
あった場合に限り、コンテンツサーバ３との間で現在確
立されている第１の通信路４pkt または第２の通信路４
tel を切断する。第１の通信制御部Ｐcc1 および第２の
通信制御部Ｐcc2 のいずれか他方は、プロトコル制御部
ＰpcからコンテンツデータＤc の取得指示があった場合
に限り、コンテンツサーバ３との間で第１の通信路４pk
t または第２の通信路４tel を確立して、コンテンツサ
ーバ３に取得要求Ｄcreqを送信する。

【００９９】また、ヘッダの取得要求Ｄhreqの送信に使
用された通信路４が切断されている場合、プロトコル制
御部Ｐpcは、第１の通信制御部Ｐcc1 および第２の通信
制御部Ｐcc2 の内、取得した接続方法情報Ｉconn1 によ
り特定される側に、先にブラウザ部Ｐbwから受け取った
取得要求Ｄcreqを渡して、コンテンツデータＤc の取得
を指示する。第１の通信制御部Ｐcc1 または第２の通信
制御部Ｐcc2 は、プロトコル制御部Ｐpcの指示があった
場合に限り、コンテンツサーバ３との間で第１の通信路
４pkt または第２の通信路４tel を確立して、コンテン
ツサーバ３に取得要求Ｄcreqを送信する。コンテンツサ
ーバ３は、受信取得要求Ｄcreqで指定された位置情報Ｉ
url に基づいて、コンテンツデータＤc を読み出して、
現在データ通信に使用している第１の通信路４pkt また
は第２の通信路４tel を介して、コンテンツ取得装置１
d に送信する。

【０１００】以上説明したように、コンテンツ取得装置
１d は、コンテンツデータＤc の取得前に、その応答ヘ
ッダＨc を取得する。そして、取得した応答ヘッダＨc
に含まれるコンテンツタイプＩctypおよび接続情報テー
ブルＴconn2 を参照することにより、今回取得するコン
テンツデータＤc の取得に好適な好適な接続方法を知る
ことができる。

【０１０１】なお、第４の実施形態では、応答ヘッダＨ
c からコンテンツタイプＩctypが取得され、接続情報管
理部Ｐconn1 は、コンテンツタイプＩctyp毎に接続方法
情報Ｉconn1 を管理していた。しかし、これだけに限ら
ず、応答ヘッダＨc に記述されているコンテンツデータ
Ｄc の属性（例えば、コンテンツ長Ｉclg ）が取得さ
れ、さらに、接続情報管理部Ｐconn1 は、コンテンツデ
ータＤc の属性毎に接続方法情報Ｉconn1 を管理しても
良い。特に、コンテンツデータＤc の属性がコンテンツ
長Ｉclg の場合、コンテンツ取得装置１d は、今回取得
するコンテンツデータＤc の長さＩclg を、接続情報管
理部Ｐconn1 が管理するコンテンツ長Ｉclg と比較し
て、取得する接続方法情報Ｉconn1 を決定する。

【０１０２】次に、上記コンテンツ取得装置１d が実装
される移動体通信装置Ｕcomm4 について説明する。移動
体通信装置Ｕcomm4 は、移動体通信装置Ｕcomm1 と同様
の構成を有するので、以下の説明では図４を援用する。
次に、移動体通信装置Ｕcomm4 の動作について、図１３
のフローチャートを参照して説明する。図１３は、図１
１と比較すると、ステップＳ３０２〜Ｓ３０４がステッ
プＳ４０１〜Ｓ４０５に代わる点で相違する。それ以外
に両者の間には相違点はないので、図１２において、図
１１のステップに相当するものには、同じ番号を付し、
その説明を省略する。

【０１０３】移動体通信装置Ｕcomm4 がコンテンツデー
タＤc の取得を行う場合、最初に、ＣＰＵ１１は、ＲＯ
Ｍ１２からプログラムをＲＡＭ１３に読み出す。本実施
形態におけるプログラムには、図７（ａ）に示す接続情
報テーブルＴ_conn2 が予め記述されている。接続情報テ
ーブルＴconn2 は、プログラムの読み出しと共に、ＲＡ
Ｍ１３に読み出される。その後、ＣＰＵ１１は、取得要
求生成処理を行う（ステップＳ３０１）。次に、ＣＰＵ
１１は、プロトコル制御部Ｐpcとして動作し、上述のヘ
ッダの取得要求Ｄhreqを生成する（ステップＳ４０
２）。

【０１０４】次に、ＣＰＵ１１は、生成した取得要求Ｄ
hreqを、第１の通信制御部Ｐcc1 および第２の通信制御
部Ｐcc2 のいずれかに渡す。ここで、既にコンテンツサ
ーバ３とデータ通信中であれば、現在データ通信を行っ
ている方に、ＣＰＵ１１は、生成した取得要求Ｄhreqを
渡して、応答ヘッダＨc の取得を指示する。第１の通信
制御部Ｐcc1 または第２の通信制御部Ｐcc2 は、ＣＰＵ
１１からの指示に応答して、多重／分離部１６、送受信
部１７および第１の通信路４pkt または第２の通信路４
tel を介して、コンテンツサーバ３に取得要求Ｄhreqを
送信する。一方、ＣＰＵ１１は、取得要求Ｄhreqの生成
終了後、データ通信中ではない場合、第１の通信制御部
Ｐcc1 に、生成した取得要求Ｄhreqを渡す。これに応答
して、第１の通信制御部Ｐcc1 は、多重／分離部１６、
送受信部１７および第１の通信路４pkt を介して、コン
テンツサーバ３に取得要求Ｄhreqを送信する。以上のよ
うにして、ヘッダの取得要求Ｄhreqはコンテンツサーバ
３に送信される（ステップＳ４０２）。

【０１０５】コンテンツサーバ３は、第１の通信路４pk
t および第２の通信路４tel のいずれかを使って、応答
ヘッダＨc を作成して移動体通信装置Ｕcomm4 に返す。
移動体通信装置Ｕcomm4 において、第１の通信制御部Ｐ
cc1 または第２の通信制御部Ｐcc2 は、第１の通信路４
pkt または第２の通信路４tel 、送受信部１７および多
重／分離部１６を介して、応答ヘッダＨc を受信し、そ
のままＲＡＭ１３に格納する。これによって、ＣＰＵ１
１は、応答ヘッダＨc を受信する（ステップＳ４０
３）。ＣＰＵ１１は、受信応答ヘッダＨc 内のコンテン
ツタイプＩctypと同じ組みを構成する接続方法情報Ｉco
nn1 を、ＲＡＭ１３上の接続情報テーブルＴconn2 （図
７（ａ）参照）から取得する。ＣＰＵ１１は、取得した
接続方法情報Ｉconn1 に従って、今回のコンテンツデー
タＤc を、パケット交換接続で取得するか、回線交換接
続で取得するかを決定する（ステップＳ４０５）。以
降、移動体通信装置Ｕcomm4 では、図１１と同様のステ
ップＳ３０５〜Ｓ３１２が行われる。ただし、コンテン
ツサーバ３は、コンテンツ取得要求Ｄcreqに応答して、
コンテンツデータＤc だけを移動体通信装置Ｕcomm4 に
送信すれば良く、応答ヘッダＨc は特に送信される必要
はない。

【０１０６】なお、以上の第１〜第４の実施形態では、
マークアップ言語としてＨＴＭＬを例に採りあげたが、
コンテンツ取得装置１a 〜１d は、ＸＭＬ(eXtension M
arkup Language) で記述されたコンテンツデータＤc に
対しても上述と同様の処理を行うことができる。

【図面の簡単な説明】

【図１】コンテンツ取得装置１a の機能ブロック図であ
る。

【図２】図１のコンテンツサーバ３が生成する応答デー
タＤrep のデータ構造を示す図である。

【図３】メインコンテンツデータＤmcおよびサブコンテ
ンツデータＤscの関係を示す図である。

【図４】移動体通信装置Ｕcomm1 〜Ｕcomm4 の構成を示
すブロック図である。

【図５】移動体通信装置Ｕcomm1 の動作を示すフローチ
ャートである。

【図６】コンテンツ取得装置１b の機能ブロック図であ
る。

【図７】接続情報テーブルＴconn2 および内部情報テー
ブルＴctypを示す図である。

【図８】移動体通信装置Ｕcomm2 の動作を示すフローチ
ャートである。

【図９】コンテンツ取得装置１c の機能ブロック図であ
る。

【図１０】接続情報テーブルＴconn3 を示す図である。

【図１１】移動体通信装置Ｕcomm3 の動作を示すフロー
チャートである。

【図１２】コンテンツ取得装置１d の機能ブロック図で
ある。

【図１３】移動体通信装置Ｕcomm4 の動作を示すフロー
チャートである。

【符号の説明】

１a 〜１d …コンテンツ取得装置 Ｐbw…ブラウザ部 Ｐpc…プロトコル制御部 Ｐcc1 …第１の通信制御部 Ｐcc2 …第２の通信制御部 Ｐconn1 ，Ｐconn2 …接続情報管理部

Claims (20)

【特許請求の範囲】
1. 【請求項１】 マルチコール機能により複数の接続方法
   を使用可能に構成されており、最適な接続方法で通信網
   を介してサーバからコンテンツデータを取得するコンテ
   ンツ取得装置であって、 今回取得すべきコンテンツデータの位置情報を特定する
   取得要求を生成するブラウザ部と、 前記ブラウザ部により特定されたコンテンツデータの受
   信前に、その接続方法を決定するプロトコル制御部と、 前記プロトコル制御部が決定した接続方法で、前記ブラ
   ウザ部が指定したコンテンツデータを前記サーバから受
   信する通信制御部とを備える、コンテンツ取得装置。
2. 【請求項２】 コンテンツデータは、自身にリンクされ
   る各サブコンテンツデータの位置情報と、当該各サブコ
   ンテンツデータに好適な接続方法を示す接続方法情報と
   を含んでおり、 前記ブラウザ部は、受信コンテンツデータを解析して、
   各サブコンテンツデータの位置情報および接続方法情報
   を取得した後、今回取得すべきサブコンテンツデータの
   位置情報を特定する取得要求を生成し、 前記プロトコル制御部は、前記ブラウザ部が取得した接
   続方法情報に基づいて、当該ブラウザ部により指定され
   たサブコンテンツデータを受信する際の最適な接続方法
   を決定する、請求項１に記載のコンテンツ取得装置。
3. 【請求項３】 コンテンツデータは、自身にリンクされ
   る各サブコンテンツデータの位置情報およびファイル属
   性とを含んでおり、 コンテンツデータのファイル属性毎に最適な接続方法が
   記述された接続情報テーブルを管理する接続情報管理部
   をさらに備え、 前記ブラウザ部は、受信コンテンツデータを解析して、
   各サブコンテンツデータの位置情報およびファイル属性
   の組みを取得して内部情報として保持した後に、今回取
   得すべきサブコンテンツデータの位置情報を特定する取
   得要求を生成し、 前記プロトコル制御部は、前記ブラウザ部で生成された
   取得要求を受け取ると、当該取得要求が含む位置情報と
   同じ組みを構成するファイル属性を当該ブラウザ部から
   受け取り、さらに、前記ブラウザ部から受け取ったファ
   イル属性と同じ組みを構成する最適な接続方法を、前記
   接続情報管理部から取得することにより決定する、請求
   項１に記載のコンテンツ取得装置。
4. 【請求項４】 コンテンツデータには、前記サーバにお
   ける格納位置を示す位置情報が割り当てられており、当
   該位置情報の一部が当該コンテンツデータの特徴を示し
   ており、 コンテンツデータの特徴毎に最適な接続方法が記述され
   た接続情報テーブルを管理する接続情報管理部をさらに
   備え、 前記プロトコル制御部は、前記ブラウザ部で生成された
   取得要求を受け取ると、当該取得要求が含む位置情報の
   一部と同じ組みを構成する最適な接続方法を、前記接続
   情報管理部から受け取ることにより決定する、請求項１
   に記載のコンテンツ取得装置。
5. 【請求項５】 前記サーバは、コンテンツデータの他
   に、当該コンテンツデータのファイル属性を含むコンテ
   ンツヘッダを送信可能に構成されており、 コンテンツデータのファイル属性毎に最適な接続方法が
   記述された接続情報テーブルを管理する接続情報管理部
   をさらに備え、 前記ブラウザ部は、今回取得すべきコンテンツデータの
   位置情報を特定する第１の取得要求を生成し、 前記プロトコル制御部は、前記ブラウザ部で生成された
   第１の取得要求を受け取ると、当該取得要求で特定され
   るコンテンツデータのコンテンツヘッダを取得するため
   の第２の取得要求を生成し、 前記通信制御部は、前記プロトコル制御部で生成された
   第２の取得要求で特定されるコンテンツヘッダを前記サ
   ーバから受信し、 前記プロトコル制御部は、前記通信制御部により受信さ
   れたコンテンツヘッダが含むファイル属性と同じ組みを
   構成する最適な接続方法を、前記接続情報管理部から取
   得することにより決定する、請求項１に記載のコンテン
   ツ取得装置。
6. 【請求項６】 マルチコール機能により、複数の接続方
   法の内、最適な接続方法で通信網を介してサーバからコ
   ンテンツデータを取得するコンテンツ取得方法であっ
   て、 今回取得すべきコンテンツデータの位置情報を特定する
   コンテンツ取得要求を生成するコンテンツ要求生成ステ
   ップと、 前記コンテンツ要求生成ステップにより特定されたサブ
   コンテンツデータの受信前に、最適な接続方法を決定す
   る接続方法決定ステップと、 前記接続方法決定ステップで決定された接続方法で、前
   記コンテンツ要求生成ステップで特定されたコンテンツ
   データを前記サーバから受信するコンテンツ受信ステッ
   プとを備える、コンテンツ取得方法。
7. 【請求項７】 コンテンツデータは、自身にリンクされ
   る各サブコンテンツデータの位置情報と、当該各サブコ
   ンテンツデータに好適な接続方法を示す接続方法情報と
   を含んでおり、 前記コンテンツ要求生成ステップは、受信コンテンツデ
   ータを解析して、各サブコンテンツデータの位置情報お
   よび接続方法情報を取得した後、今回取得すべきサブコ
   ンテンツデータの位置情報を特定するコンテンツ取得要
   求を生成し、 前記接続方法決定ステップは、前記コンテンツ要求生成
   ステップで取得された接続方法情報に基づいて、最適な
   接続方法を決定する、請求項６に記載のコンテンツ取得
   方法。
8. 【請求項８】 コンテンツデータは、自身にリンクされ
   る各サブコンテンツデータの位置情報およびファイル属
   性とを含んでおり、 コンテンツデータのファイル属性毎に最適な接続方法が
   記述された接続情報テーブルが予め管理されており、 前記コンテンツ要求生成ステップは、受信コンテンツデ
   ータを解析して、各サブコンテンツデータの位置情報お
   よびファイル属性の組みを取得して内部情報として保持
   した後に、今回取得すべきサブコンテンツデータの位置
   情報を特定するコンテンツ取得要求を生成し、 前記接続方法決定ステップは、 前記コンテンツ要求生成ステップで生成されたコンテン
   ツ取得要求を受け取ると、当該コンテンツ取得要求が含
   む位置情報と同じ組みを構成するファイル属性を当該コ
   ンテンツ要求生成ステップから受け取り、さらに、 前記コンテンツ要求生成ステップから受け取ったファイ
   ル属性と同じ組みを構成する最適な接続方法を、前記接
   続情報テーブルから取得することにより決定する、請求
   項６に記載のコンテンツ取得方法。
9. 【請求項９】 コンテンツデータには、前記サーバにお
   ける格納位置を示す位置情報が割り当てられており、当
   該位置情報の一部が当該コンテンツデータの特徴を示し
   ており、 コンテンツデータの特徴毎に最適な接続方法が記述され
   た接続情報テーブルが予め管理されており、 前記接続方法決定ステップは、前記コンテンツ要求生成
   ステップで生成されたコンテンツ取得要求を受け取る
   と、当該コンテンツ取得要求が含む位置情報の一部と同
   じ組みを構成する最適な接続方法を、前記接続情報テー
   ブルから取得することにより決定する、請求項６に記載
   のコンテンツ取得方法。
10. 【請求項１０】 前記サーバは、コンテンツデータの他
    に、当該コンテンツデータのファイル属性を含むコンテ
    ンツヘッダを送信可能に構成されており、 コンテンツデータのファイル属性毎に最適な接続方法が
    記述された接続情報テーブルが予め管理されており、 前記コンテンツ要求生成ステップで生成されたコンテン
    ツ取得要求を受け取って、当該取得要求で特定されるコ
    ンテンツデータのコンテンツヘッダを取得するためのヘ
    ッダ取得要求を生成するヘッダ要求生成ステップと、 前記ヘッダ要求生成ステップで生成されたヘッダ取得要
    求で特定されるコンテンツヘッダを前記サーバから受信
    するヘッダ受信ステップとをさらに備え、 前記接続方法決定ステップは、前記ヘッダ受信ステップ
    で受信されたコンテンツヘッダが含むファイル属性と同
    じ組みを構成する最適な接続方法を、前記接続情報テー
    ブルから取得することにより決定する、請求項６に記載
    のコンテンツ取得方法。
11. 【請求項１１】 マルチコール機能により、複数の接続
    方法の内、最適な接続方法で通信網を介してサーバから
    コンテンツデータを取得するためのプログラムを記録し
    た記録媒体であって、 今回取得すべきコンテンツデータの位置情報を特定する
    コンテンツ取得要求を生成するコンテンツ要求生成ステ
    ップと、 当該コンテンツ要求生成ステップにより特定されたサブ
    コンテンツデータの受信前に、最適な接続方法を決定す
    る接続方法決定ステップと、 前記接続方法決定ステップで決定された接続方法で、前
    記コンテンツ要求生成ステップで特定されたコンテンツ
    データを前記サーバから受信するコンテンツ受信ステッ
    プとを備える、プログラムを記録した記録媒体。
12. 【請求項１２】 コンテンツデータは、自身にリンクさ
    れる各サブコンテンツデータの位置情報と、当該各サブ
    コンテンツデータに好適な接続方法を示す接続方法情報
    とを含んでおり、 前記コンテンツ要求生成ステップは、受信コンテンツデ
    ータを解析して、各サブコンテンツデータの位置情報お
    よび接続方法情報を取得した後、今回取得すべきサブコ
    ンテンツデータの位置情報を特定するコンテンツ取得要
    求を生成し、 前記接続方法決定ステップは、前記コンテンツ要求生成
    ステップで取得された接続方法情報に基づいて、最適な
    接続方法を決定する、請求項１１に記載のプログラムを
    記録した記録媒体。
13. 【請求項１３】 コンテンツデータは、自身にリンクさ
    れる各サブコンテンツデータの位置情報およびファイル
    属性とを含んでおり、 コンテンツデータのファイル属性毎に最適な接続方法が
    記述された接続情報テーブルが予め管理されており、 前記コンテンツ要求生成ステップは、受信コンテンツデ
    ータを解析して、各サブコンテンツデータの位置情報お
    よびファイル属性の組みを取得して内部情報として保持
    した後に、今回取得すべきサブコンテンツデータの位置
    情報を特定するコンテンツ取得要求を生成し、 前記接続方法決定ステップは、 前記コンテンツ要求生成ステップで生成されたコンテン
    ツ取得要求を受け取ると、当該コンテンツ取得要求が含
    む位置情報と同じ組みを構成するファイル属性を当該コ
    ンテンツ要求生成ステップから受け取り、さらに、 前記コンテンツ要求生成ステップから受け取ったファイ
    ル属性と同じ組みを構成する最適な接続方法を、前記接
    続情報テーブルから取得することにより決定する、請求
    項１１に記載のプログラムを記録した記録媒体。
14. 【請求項１４】 コンテンツデータには、前記サーバに
    おける格納位置を示す位置情報が割り当てられており、
    当該位置情報の一部が当該コンテンツデータの特徴を示
    しており、 コンテンツデータの特徴毎に最適な接続方法が記述され
    た接続情報テーブルが予め管理されており、 前記接続方法決定ステップは、前記コンテンツ要求生成
    ステップで生成されたコンテンツ取得要求を受け取る
    と、当該コンテンツ取得要求が含む位置情報の一部と同
    じ組みを構成する最適な接続方法を、前記接続情報テー
    ブルから取得することにより決定する、請求項１１に記
    載のプログラムを記録した記録媒体。
15. 【請求項１５】 前記サーバは、コンテンツデータの他
    に、当該コンテンツデータのファイル属性を含むコンテ
    ンツヘッダを送信可能に構成されており、 コンテンツデータのファイル属性毎に最適な接続方法が
    記述された接続情報テーブルが予め管理されており、 前記コンテンツ要求生成ステップで生成されたコンテン
    ツ取得要求を受け取って、当該取得要求で特定されるコ
    ンテンツデータのコンテンツヘッダを取得するためのヘ
    ッダ取得要求を生成するヘッダ要求生成ステップと、 前記ヘッダ要求生成ステップで生成されたヘッダ取得要
    求で特定されるコンテンツヘッダを前記サーバから受信
    する前記ヘッダ受信ステップとをさらに備え、 前記接続方法決定ステップは、前記ヘッダ受信ステップ
    で受信されたコンテンツヘッダが含むファイル属性と同
    じ組みを構成する最適な接続方法を、前記接続情報テー
    ブルから取得することにより決定する、請求項１１に記
    載のプログラムを記録した記録媒体。
16. 【請求項１６】 マルチコール機能により、複数の接続
    方法の内、最適な接続方法で通信網を介してサーバから
    コンテンツデータを取得するためのプログラムであっ
    て、 今回取得すべきコンテンツデータの位置情報を特定する
    コンテンツ取得要求を生成するコンテンツ要求生成ステ
    ップと、 当該コンテンツ要求生成ステップにより特定されたサブ
    コンテンツデータの受信前に、最適な接続方法を決定す
    る接続方法決定ステップと、 前記接続方法決定ステップで決定された接続方法で、前
    記コンテンツ要求生成ステップで特定されたコンテンツ
    データを前記サーバから受信するコンテンツ受信ステッ
    プとを備える、プログラム。
17. 【請求項１７】 コンテンツデータは、自身にリンクさ
    れる各サブコンテンツデータの位置情報と、当該各サブ
    コンテンツデータに好適な接続方法を示す接続方法情報
    とを含んでおり、 前記コンテンツ要求生成ステップは、受信コンテンツデ
    ータを解析して、各サブコンテンツデータの位置情報お
    よび接続方法情報を取得した後、今回取得すべきサブコ
    ンテンツデータの位置情報を特定するコンテンツ取得要
    求を生成し、 前記接続方法決定ステップは、前記コンテンツ要求生成
    ステップで取得された接続方法情報に基づいて、最適な
    接続方法を決定する、請求項１６に記載のプログラム。
18. 【請求項１８】 コンテンツデータは、自身にリンクさ
    れる各サブコンテンツデータの位置情報およびファイル
    属性とを含んでおり、 コンテンツデータのファイル属性毎に最適な接続方法が
    記述された接続情報テーブルが予め管理されており、 前記コンテンツ要求生成ステップは、受信コンテンツデ
    ータを解析して、各サブコンテンツデータの位置情報お
    よびファイル属性の組みを取得して内部情報として保持
    した後に、今回取得すべきサブコンテンツデータの位置
    情報を特定するコンテンツ取得要求を生成し、 前記接続方法決定ステップは、 前記コンテンツ要求生成ステップで生成されたコンテン
    ツ取得要求を受け取ると、当該コンテンツ取得要求が含
    む位置情報と同じ組みを構成するファイル属性を当該コ
    ンテンツ要求生成ステップから受け取り、さらに、 前記コンテンツ要求生成ステップから受け取ったファイ
    ル属性と同じ組みを構成する最適な接続方法を、前記接
    続情報テーブルから取得することにより決定する、請求
    項１６に記載のプログラム。
19. 【請求項１９】 コンテンツデータには、前記サーバに
    おける格納位置を示す位置情報が割り当てられており、
    当該位置情報の一部が当該コンテンツデータの特徴を示
    しており、 コンテンツデータの特徴毎に最適な接続方法が記述され
    た前記接続情報テーブルが予め管理されており、 前記接続方法決定ステップは、前記コンテンツ要求生成
    ステップで生成されたコンテンツ取得要求を受け取る
    と、当該コンテンツ取得要求が含む位置情報の一部と同
    じ組みを構成する最適な接続方法を、前記接続情報テー
    ブルから取得することにより決定する、請求項１６に記
    載のプログラム。
20. 【請求項２０】 前記サーバは、コンテンツデータの他
    に、当該コンテンツデータのファイル属性を含むコンテ
    ンツヘッダを送信可能に構成されており、 コンテンツデータのファイル属性毎に最適な接続方法が
    記述された前記接続情報テーブルが予め管理されてお
    り、 前記コンテンツ要求生成ステップで生成されたコンテン
    ツ取得要求を受け取って、当該取得要求で特定されるコ
    ンテンツデータのコンテンツヘッダを取得するためのヘ
    ッダ取得要求を生成するヘッダ要求生成ステップと、 前記ヘッダ要求生成ステップで生成されたヘッダ取得要
    求で特定されるコンテンツヘッダを前記サーバから受信
    する前記ヘッダ受信ステップとをさらに備え、 前記接続方法決定ステップは、前記ヘッダ受信ステップ
    で受信されたコンテンツヘッダが含むファイル属性と同
    じ組みを構成する最適な接続方法を、前記接続情報テー
    ブルから取得することにより決定する、請求項１６に記
    載のプログラム。