JP2001223732A

JP2001223732A - 情報配信方法ならびに情報配信装置および情報受信装置

Info

Publication number: JP2001223732A
Application number: JP2000034750A
Authority: JP
Inventors: Shin Mikuni; 伸三国
Original assignee: Casio Computer Co Ltd
Current assignee: Casio Computer Co Ltd
Priority date: 2000-02-14
Filing date: 2000-02-14
Publication date: 2001-08-17

Abstract

(57)【要約】【課題】送信側と受信側の配信情報の加工を不要にし
て送信側および受信側の処理負担を軽減しつつ異なる端
末への同一情報配信時のトラフィック抑制を図る。【解決手段】配信装置１は、端末３_iから要求された
情報を当該端末３_i宛てに配信する際に、前記要求が単
一の端末３_iからのものであるときは当該要求された情
報をユニキャスト方式で配信する一方、前記要求が複数
の端末３_iからのものであるときは当該要求された情報
をマルチキャスト方式で配信する。情報要求の端末数を
ｎとすると、ネットワーク上のパケット数を１／ｎに減
少でき、それだけネットワークトラフィックを抑制でき
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報配信方法なら
びに情報配信装置および情報受信装置に関し、詳しく
は、異なる端末への同一情報配信時のトラフィック（通
信路に対する負荷）抑制を意図した情報配信方法ならび
に情報配信装置および情報受信装置に関する。

【０００２】

【従来の技術】近時、インターネット等のネットワーク
利用者はますます増加の一途をたどり、それに伴ってネ
ットワークを流れるデータ量も一段と増える傾向にある
ことから、伝送容量の拡大等、ネットワークインフラの
整備が急務となっている。

【０００３】ネットワーク媒体の代表はＩＳＤＮ（Inte
grated Services Digital Network）やアナログ回線等
の公衆回線網であるが、この他にも衛星通信や無線通信
あるいはケーブルテレビなどの媒体も使用されている。
これらの媒体のうち、光ファイバーを用いるケーブルテ
レビや搬送周波数の高い衛星通信などの媒体は公衆回線
網に比べて伝送容量が大きく、高速通信に適している
が、これらの媒体はもっぱら配信先を指定しない一対多
の情報配信（いわゆる同報通信や一斉通信または放送通
信と呼ばれる通信形態）を行なうものであるため、イン
ターネット等のように配信先を指定する一対一の情報配
信に適用する場合には工夫が必要である。

【０００４】一般に一対多の情報配信のことを「マルチ
キャスト方式」と呼ぶことがあり、同様に一対一の情報
配信のことを「ユニキャスト方式」と呼ぶことがある。
以下、この呼び方に倣うことにすると、特開平１１−２
９８４９６号公報には、マルチキャスト方式とユニキャ
スト方式を併用することによってトラフィックを抑制し
た「情報配信方法および装置」の技術が記載されてい
る。この技術の要旨は、「複数の利用者に対して異なる
情報を配信する情報配信において、送信側は、送出情報
から全利用者に共通な共通情報と、個々の利用者に個別
な付加情報とを分離抽出するとともに、共通情報をマル
チキャスト方式を用いて同報送信し、付加情報をユニキ
ャスト方式を用いて個別送信し、受信側は、それぞれの
受信情報（共通情報と個別情報）を統合して出力、表示
する。」というものである。

【０００５】この技術におけるマルチキャスト方式によ
る同報送信は、通信パケットの送信先アドレスに共通の
グループアドレスをセットして送信するというもので、
同一グループ内の複数のユーザ（ホスト）に対して同一
の情報を一斉配信するというものである。一方、同技術
におけるユニキャスト方式による個別送信は、通信パケ
ットの送信先アドレスに個別のユーザアドレスをセット
して送信するというものである。上記技術によれば、配
信情報中に含まれる個々の利用者ごとの相違部分がユニ
キャスト方式によって個別送信され、共通部分がマルチ
キャスト方式で一斉送信されるため、共通部分が多いほ
ど、通信路に対するトラフィックの抑制効果が得られる
という利点がある。

【０００６】

【発明が解決しようとする課題】しかしながら、上記従
来の技術にあっては、送信側と受信側で配信情報の加工
が必要であり、以下の問題点があった。（Ａ）送信側で配信情報中の共通部分と相違部分を弁別
しなければならず、送信側の処理負担が大きい。（Ｂ）受信側で受信情報（共通情報と個別情報）を統合
しなければならず、受信側の処理負担も大きい。

【０００７】したがって、本発明が解決しようとする課
題は、送信側と受信側の配信情報の加工を不要にして送
信側および受信側の処理負担を軽減しつつ、異なる端末
への同一情報配信時のトラフィック抑制を図ることにあ
る。

【０００８】

【課題を解決するための手段】請求項１記載の発明に係
る情報配信方法は、端末から要求された情報を当該端末
宛てに配信する情報配信方法において、前記要求が単一
の端末からのものであるときは当該要求された情報をユ
ニキャスト方式で配信する一方、前記要求が複数の端末
からのものであるときは当該要求された情報をマルチキ
ャスト方式で配信するようにしたことを特徴とする。請
求項２記載の発明に係る情報配信方法は、請求項１記載
の情報配信方法において、前記ユニキャスト方式による
情報配信は送信先アドレスを前記単一の端末に固有のア
ドレスとする一方、前記マルチキャスト方式による情報
配信は前記複数の端末に共通のアドレスとすることを特
徴とする。請求項３記載の発明に係る情報配信装置は、
単一の端末からの情報要求であるか複数の端末からの同
一情報の要求であるかを判定する判定手段と、前記判定
手段によって単一の端末からの情報要求であることが判
定された場合に当該端末宛てにユニキャスト方式で要求
情報を配信する一方、前記判定手段によって複数の端末
からの同一情報の要求であることが判定された場合に当
該複数の端末宛てにマルチキャスト方式で要求情報を配
信する配信手段と、を備えたことを特徴とする。請求項
４記載の発明に係る情報配信装置は、過去の配信情報の
履歴を記憶する記憶手段と、端末から情報要求があった
ときに前記配信履歴を調べてユニキャスト方式で配信す
るかマルチキャスト方式で配信するかを決定する決定手
段と、前記決定手段の決定結果で示された方式を用いて
要求情報を配信する配信手段と、を備えたことを特徴と
する。請求項５記載の発明に係る情報配信装置は、請求
項３または請求項４記載の情報配信装置において、前記
ユニキャスト方式による情報配信は送信先アドレスを前
記単一の端末に固有のアドレスとする一方、前記マルチ
キャスト方式による情報配信は前記複数の端末に共通の
アドレスとすることを特徴とする。請求項６記載の発明
に係る情報受信装置は、配信装置に対して所要の情報要
求を出力するためのユーザインターフェースを提供する
提供手段と、前記配信装置からユニキャスト方式で伝送
される前記情報およびマルチキャスト方式で伝送される
前記情報を受信する受信手段と、を備え、前記ユーザイ
ンターフェースは前記配信装置から伝送される情報の伝
送方式を事前に識別表示することを特徴とする。請求項
７記載の発明に係る情報受信装置は、請求項６記載の情
報受信装置において、前記ユーザインターフェースは前
記配信装置から伝送される情報の伝送方式が所定の伝送
方式である場合に伝送を拒否するオブジェクトを有する
ことを特徴とする。

【０００９】

【発明の実施形態】以下、図面を参照して本発明の実施
形態を詳細に説明する。（１）実施形態図１は本発明の実施形態における情報配信システムの概
念構成図である。この図において、配信装置１（発明の
要旨に記載の情報配信装置に相当）は、ネットワーク２
を介して複数の端末３₁〜３_nに接続されており、この配
信装置１は、任意の端末３_i（ｉは１〜ｎ；以下同様）
からの情報要求に応答して、要求された情報を要求元の
端末３_iに返送する機能を有するものである。このよう
な機能の代表は、例えば、ＷＷＷ（world wide web）サ
ーバサービスやＦＴＰ（File Transfer Protocol）サー
バサービスなどである。

【００１０】周知のとおり、これらのサービスはＨＴＭ
Ｌ（Hyper Text Markup Language）文書や画像ファイル
またはデータファイル等のコンテンツ情報を公開フォル
ダに格納し、ネットワーク上のパーソナルコンピュータ
等に搭載された閲覧ツール（一般にブラウザソフト）か
らの情報要求を受付け、当該要求で指定されたコンテン
ツ情報を当該閲覧ツールに返送するものである。

【００１１】上記サービスの転送プロトコルはインター
ネットの標準プロトコルであるＴＣＰ／ＩＰ（Transmis
sion Control Protocol／Internet Protocol）であり、
ＴＣＰ／ＩＰはＩＰ（Internet Protocol）を中心とし
たパケット通信方式のプロトコル群の総称のことである
から、図示の配信装置１と端末３_iの間のデータ転送
は、配信情報を所定のサイズ（パケットまたはフレーム
という）に小分けして各小分け単位に送信元アドレスと
送信先アドレスを付して送信するパケット通信方式で行
なわれる。

【００１２】図２は配信装置１と各端末３_iの間のパケ
ット通信概念図である。図において、端末３_iから配信
装置１へのパケット４ｕを便宜的に“アップロードパケ
ット”ということにすると、このアップロードパケット
４ｕの送信元アドレスには端末３_iのアドレスがセット
され、また、送信先アドレスには配信装置１のアドレス
がセットされる。同様に、配信装置１から端末３_iへの
パケット４ｄを便宜的に“ダウンロードパケット”とい
うことにすると、このダウンロードパケット４ｄの送信
元アドレスには配信装置１のアドレスがセットされ、送
信先アドレスには端末３_iのアドレスがセットされる。

【００１３】このように、パケット内に送信元と送信先
のアドレスをセットしてホスト間でアップロードパケッ
ト４ｕやダウンロードパケット４ｄをやり取りすること
をパケット通信といい、特に通信先アドレスをユニーク
（ネットワーク上の一つの端末の固有アドレス）とする
方式をユニキャスト方式によるパケット通信という。ユ
ニキャスト方式では一対一のホスト間でパケット通信を
行なうことができる。一方、通信先アドレスをブロード
（ネットワーク上のすべてまたは複数の端末に共通のア
ドレスであり、この共通のアドレスとしては、一時的な
共通アドレスと予め決めてある共通アドレスとが考えら
れる。）とする方式をマルチキャスト方式によるパケッ
ト通信といい、この方式では一対多のホスト間でパケッ
ト通信を行なうことができ、例えば、一斉通信や同報通
信あるいは放送通信等を行なうことができる。

【００１４】ところで、パケット通信方式によるデータ
転送においては、ネットワークに一つのパケットが流れ
ている間（コリジョンが発生している間ともいう）、他
のパケットを流し込むことはできない。コリジョンの発
生期間はネットワークの伝送容量に依存し、高速になる
ほどネットワークの帯域幅が拡大して短くなるからであ
る。

【００１５】伝送容量の点で上記二つの方式（ユニキャ
スト方式とマルチキャスト方式）を比較した場合、後者
の方式（マルチキャスト方式）が優れている。マルチキ
ャスト方式は複数の端末宛てに共通のパケットを伝送で
きるため、ネットワークの利用効率が高く少ない帯域幅
で所要の伝送容量を確保できるからである。しかし、マ
ルチキャスト方式は一対多の通信方式であるため、特定
の端末宛ての情報伝送に利用できないという欠点があ
り、インターネット等のネットワークインフラを利用し
た情報伝送（例えば、ＷＷＷ、ＦＴＰ、メールなど）に
適用することはできない。

【００１６】したがって、インターネット等のネットワ
ークインフラを利用した情報伝送には一対一の伝送方
式、すなわち、ユニキャスト方式によるパケット通信を
採用せざるを得ないが、ネットワーク利用者の増大に伴
って、この方式の欠点（伝送路のトラフィックが増え
る）が問題視されるようになってきた。

【００１７】そこで、本実施形態では、以下に詳述する
ように、端末からの情報要求の形態に応じてユニキャス
ト方式とマルチキャスト方式のパケット通信を使い分け
ることにより、伝送路のトラフィックを抑制しつつ、イ
ンターネット等のネットワークインフラを利用した一対
一の情報伝送も支障なく行なうことのできる情報配信技
術を提供する。

【００１８】図３は本実施形態における情報配信の概念
図である。図において、（ａ）はユニキャスト方式によ
るもの、（ｂ）はマルチキャスト方式によるものであ
り、本実施形態ではこれら二つの方式を端末３_iからの
情報要求の形態によって適宜に使い分ける。すなわち、
本実施形態における配信装置１は、単一の端末３_iから
の情報要求の場合に（ａ）のユニキャスト方式を用い
て、要求された情報を端末３_iに配信し、複数の端末３_i
からの同一情報の要求の場合に（ｂ）のマルチキャスト
方式を用いて、要求された情報を端末３_iに配信する。

【００１９】ここで、（ａ）のユニキャスト方式による
情報配信は、実質的に図２に示したものと同じである
が、（ｂ）のマルチキャスト方式による情報配信は、既
述のとおり、複数の端末３_iからの同一情報の要求があ
ったとき、例えば、ｎ個（ｎは２以上の整数）の端末３
_iから同一情報の要求があったときに、通信パケットの
送信先アドレスにグループアドレス（当該ｎ個の端末３
_iに共通のアドレス）をセットして送信する点に特徴が
ある。

【００２０】したがって、この実施形態によれば、配信
装置１は、単一の端末３_iからの要求があった場合には
ユニキャスト方式を使用し、当該一つの端末３_iに対し
て一対一の情報配信を行なう一方、ｎ個の端末３_iから
の要求があった場合にはマルチキャスト方式を使用し、
当該ｎ個の端末３_iに対して一対多の情報配信を行なう
ため、インターネット等のネットワークインフラを利用
した一対一の情報伝送を支障なく行なうことができると
ともに、同一情報の要求端末数（ｎ）に応じてパケット
数を１／ｎに削減でき、それだけトラフィックを抑制す
ることができるという格別な効果が得られる。

【００２１】なお、マルチキャスト方式におけるグルー
プアドレスは、あらかじめユーザ登録されたアドレス
（特定の端末グループに恣意的に割り当てられたアドレ
ス）であってもよいし、ＴＣＰ／ＩＰなどのブロードキ
ャストアドレス（プロトコルでで定められた制御用アド
レス）であってもよい。例えば、図４はインターネット
プロトコルにおけるＩＰアドレスの概念図であり、特に
限定しないが、クラスＣのサブネットマスク構造図であ
る。図において、ＩＰアドレスは１６ビットのネットワ
ーク部と、各々８ビットのサブネット部およびホスト部
からなり、特定のサブネット内で０〜２５５のホストを
表すことができ、例えば、１０進表記で１９２．１６
８．１．０〜１９２．１６８．１．２５５のホストアド
レスを表すことができる。ホスト部の「０」と「２５
５」はそれぞれネットワークアドレスとブロードキャス
トアドレスにシステム予約されており、表現可能なホス
ト数は２５６−２個の最大２５４個である。なお、上述
の「１９２」および「１６８」は説明上の便宜値であ
る。

【００２２】一般にブロードキャストアドレスは経路制
御等の制御アドレスに用いられているが、このブロード
キャストアドレスは同一サブネット内のすべてのホスト
で受信されるため、前記グループアドレスに利用可能で
ある。したがって、図３（ｂ）において、マルチキャス
ト方式を行なう際に、その通信パケットの送信先アドレ
ス（グループアドレス）にＴＣＰ／ＩＰのブロードキャ
ストアドレスを利用することができる。

【００２３】図５は配信装置１と二つの端末３_i（便宜
的に端末Ａ、端末Ｂ）との間のデータ配信を示すタイム
ランである。（ａ）一般に一つの端末（図では端末Ａ）
から任意の情報要求（図ではデータａの要求）が行なわ
れた場合、配信装置１はその要求をＷＷＷサーバサービ
ス等のデータ配信サービスに伝え、当該サービスは要求
された情報（データａ）を自サーバや上位サーバまたは
インターネット等に接続された他サーバから取得すると
ともに、その取得情報（データａ）をユニキャスト方式
で要求元の端末（端末Ａ）に転送し、要求元の端末Ａは
転送された情報（データａ）を取り込み、例えば、表示
プロセスに渡して画面表示等を実行するが、（ｂ）本実
施形態においては、一つの端末（図では端末Ａ）からの
情報要求の直後に、他の端末（図では端末Ｂ）からも同
一情報（データａ）の要求があった場合、配信装置１は
要求された情報をマルチキャスト方式で転送する点で相
違する。すなわち、本実施形態の配信装置１は、一つの
端末（端末Ａ）からの情報要求をデータ配信サービスに
伝えた後、当該情報の他の端末からの重複要求を判定
し、重複要求がなければ（ａ）と同様にユニキャスト方
式で要求情報（データａ）を送信する一方、重複要求が
あった場合はマルチキャスト方式で要求情報（データ
ａ）を送信する点で相違する。

【００２４】したがって、本実施形態においては、複数
の端末（図では端末Ａ、Ｂ）から同一の情報要求があっ
た場合、ネットワーク上にマルチキャスト方式の通信パ
ケットが流れるため、ユニキャスト方式に比べてパケッ
ト数を１／ｎ（ｎは同一情報の要求端末数）に減少する
ことができ、ネットワーク負荷（トラフィック）を軽減
することができる。

【００２５】以下、上記実施形態の技術思想を適用した
好ましい実施例について説明する。（２）第１実施例図６は本発明の第１実施例を示す概念構成図であり、ネ
ットワーク２を公衆回線網２ａと放送波２ｂの二つの伝
送媒体で構成した例である。図において、配信装置１
は、放送波２ｂを送出する放送部５、公衆回線網２ａと
のインターフェースをとるネットワークインターフェー
ス部６、経路切替え制御部７およびサーバ主制御部８
（発明の要旨に記載の判定手段、配信手段、決定手段に
相当）などを備え、サーバ主制御部８は、端末３_iから
の情報要求に応じて当該要求情報を、例えば、インター
ネット９に接続された情報蓄積サーバ１０から取得し、
その取得情報を要求元の端末３_iに転送する機能を有す
る。また、代表してその一つを示す端末３_iは、放送波
２ｂを受信する受信部１１、公衆回線網２ａとのインタ
ーフェースをとるネットワークインターフェース部１
２、データ送受信制御装置（発明の要旨に記載の受信手
段に相当）１３およびパーソナルコンピュータ等のデー
タ利用装置（発明の要旨に記載の提供手段に相当）１４
などを備え、データ利用装置１４にインストールされた
ブラウザ等の閲覧ソフトを操作することにより、ネット
ワークインターフェース部１２を介して配信装置１へ所
望の情報要求を出力し、配信装置１からの応答情報を、
ネットワークインターフェース部１２または受信部１１
を介して取り込み、データ利用装置１４の、例えば、デ
ィスプレイ上に表示出力する機能を有する。

【００２６】ここに、放送波２ｂと公衆回線網２ａはい
ずれもパケット通信方式の伝送媒体であるが、前者は一
対多のマルチキャスト方式に適した媒体であるのに対し
て、後者は一対一のユニキャスト方式に適した媒体であ
る点で相違する。サーバ主制御部８は端末３_iからの情
報要求形態、すなわち、一つの端末３_iからの情報要求
であるか複数の端末３_iからの同一情報の重複要求であ
るかを判定し、一つの端末３_iからの情報要求である場
合にはネットワークインターフェース部６を選択する一
方、複数の端末３_iからの同一情報の重複要求である場
合には放送部５を選択する。これにより、一つの端末３
_iからの情報要求である場合にはユニキャスト方式の通
信を行い、複数の端末３_iからの同一情報の重複要求で
ある場合にはマルチキャスト方式の通信を行なって要求
元の端末３_iへの情報転送を実現することができる。

【００２７】図７はデータ送受信制御装置１３の要部ブ
ロック図であり、データ送受信制御装置１３は受信部１
１との間の信号インターフェースをとる高周波インター
フェース（図ではＩ／Ｆと略す）１３ａ、ネットワーク
インターフェース１２との間の信号インターフェースを
とるモデムインターフェース（図ではＩ／Ｆ）１３ｂ、
所定の手順（プログラム）に従ってデータ送受信制御装
置１３の各部を制御するＣＰＵ（Central Processor Un
it）１３ｃ、データ送受信制御装置１３の各部間のデー
タ転送を調停するシステムバス調停部１３ｄ、データ利
用装置１４との間の信号インターフェースをとるＰＣイ
ンターフェース（図ではＩ／Ｆ）１３ｅおよびメモリ１
３ｆなどを備える。

【００２８】メモリ１３ｆにはＣＰＵ１３ｃの動作手
順、例えば、有線・無線パケット合成手順１３ｇや有効
受信パケット選別手順１３ｈなどが格納されており、有
線・無線パケット合成手順１３ｇは放送波２ｂによる伝
送パケット（マルチキャスト方式による伝送パケット）
と公衆回線網２ａによる伝送パケット（ユニキャスト方
式による伝送パケット）の各々の合成手順を規定し、有
効受信パケット選別手順は伝送パケット中の送信先アド
レスに基づいて自端末宛てのパケットであるか否かを判
定する手順を規定する。

【００２９】図８は配信装置１と二つの端末３_i（便宜
的に端末Ａ、端末Ｂ）との間のデータ配信を示すタイム
ランであり、このタイムランは配信装置１に対して端末
Ｂから情報（データａとする）要求があった直後に端末
Ａからも同一の情報要求があった場合を表している。配
信装置１は端末Ｂからの情報要求を受け取ると、まず、
当該情報の取得手続きを行なう。この取得手続きは、例
えば、当該情報がインターネット９に接続された情報蓄
積サーバ１０に保存されている場合、その情報蓄積サー
バ１０に対してデータａの送信を要求するというもので
ある。

【００３０】次に、配信装置１は、情報蓄積サーバ１０
に要求した情報（データａ）と同一の情報要求が他の端
末（端末Ａ）からも入るかどうかをモニタする。このモ
ニタ期間は、例えば、情報蓄積サーバ１０からの情報返
送までの待ち時間程度とすることができる。もし、この
モニタ期間中に他の端末（端末Ａ）から同一の情報要求
が入った場合、その端末Ａに対して、要求された情報
（データａ）をマルチキャスト方式で送信する旨を事前
に通知する情報（図では便宜的に「伝送方式変更通
知」）を送信し、端末Ａは当該通知に応答してマルチキ
ャスト方式のパケット受信態勢を整えた旨を通知する情
報（図では便宜的に「通知了解」）を返送し、しかる
後、配信装置１は情報蓄積サーバ１０からの情報（デー
タａ）を受け取ると、その情報を端末Ａおよび端末Ｂに
対してマルチキャスト方式で送信する。

【００３１】ここで、図８において、配信装置１と端末
Ａ（または端末Ｂ）の間に引かれた矢印付きの横線は、
配信装置１と端末Ａ（または端末Ｂ）の間でやり取りさ
れるアップロードパケットまたはダウンロードパケット
の転送動作を表しており、各々の横線に併記した記号
（ＵＣ、ＭＣ）はそれぞれの情報転送方式（ＵＣ：ユニ
キャスト方式、ＭＣ：マルチキャスト方式）を示してい
る。

【００３２】今、公衆回線網２ａをユニキャスト方式の
伝送媒体とし、放送波２ｂをマルチキャスト方式の伝送
媒体として使い分けることにすると、端末Ａ（または端
末Ｂ）から配信装置１へのアップロードパケット（情報
要求、通知了解）は公衆回線網２ａを用いたユニキャス
ト方式で伝送され、また、配信装置１から端末Ａへのダ
ウンロードパケット（伝送方式変更通知）も公衆回線網
２ａを用いたユニキャスト方式で伝送されるが、配信装
置から端末Ａ、Ｂへのダウンロードパケット（情報転
送）だけは放送波２ｂを用いたマルチキャスト方式で伝
送されることになる。なお、配信装置から端末Ａ、Ｂへ
のダウンロードパケット（情報転送）に放送波２ｂを用
いる理由は、この放送波２ｂが一対多のマルチキャスト
方式に適しているからであり、ダウンロードの情報量に
よっては公衆回線網２ａを用いても構わない。

【００３３】図９および図１０は配信装置１の動作フロ
ーチャートであり、図９は端末からのアップロードパケ
ット受信時に実行される動作フロー、図１０は端末への
ダウンロードパケット送信時に実行される動作フローで
ある。図９において、配信装置１は、まず、ステップＳ
１１で端末３_iからのアップロードパケットを取り込
み、次いで、そのアップロードパケットの内容に応じて
以下の三つの処理を択一的に実行する。ステップＳ１２
およびステップＳ１３はアップロードパケットの内容を
判定する部分であり、具体的には、ステップＳ１２はそ
のアップロードパケットが端末からの「通知了解」であ
るか否かを判定する部分、ステップＳ１３はそのアップ
ロードパケットが端末からの「情報送信要求」であるか
否かを判定する部分である。

【００３４】今、一つの端末（便宜的に端末Ｂとする）
からある情報（便宜的にデータａとする）を要求するア
ップロードパケットを受信した場合を考えると、この場
合、ステップＳ１２の判定結果は“ＮＯ”でステップＳ
１３の判定結果は“ＹＥＳ”となり、ステップＳ１４に
進む。このステップＳ１４は端末からの要求情報の取得
手続がすでに完了しているか否かを判定する部分であ
り、完了していなければ、ステップＳ１５に進み、例え
ば、インターネット上の情報蓄積サーバ（図６の情報蓄
積サーバ１０参照）に当該要求を伝達して端末Ｂからの
要求情報の取得手続を実行した後、フローを終了する。
なお、ステップＳ１３の判定結果が“ＮＯ”の場合は、
アップロードパケットはその他の処理を指定する制御情
報であるから、ステップＳ１３ａで当該処理を実行した
後、フローを終了する。

【００３５】一方、端末Ｂからのアップロードパケット
の受信直後に、他の端末（便宜的に端末Ａとする）から
同一情報（データａ）要求のアップロードパケットを受
信した場合は、この情報（データａ）の取得手続きはす
でに完了しているため、ステップＳ１４の判定結果は
“ＹＥＳ”となり、この場合、ステップＳ１６に進み、
端末Ｂに対して要求された情報（データａ）をマルチキ
ャスト方式で送信する旨を事前に通知する情報（伝送方
式変更通知）を送信し、ステップＳ１７で当該通知を送
信したことを示す所定のフラグ（便宜的に「変更中フラ
グ」とする）をセットした後、フローを終了する。

【００３６】ここで、伝送方式変更通知を受信した端末
Ｂは、後で詳述するように、当該通知に応答してマルチ
キャスト方式のパケット受信態勢を整えるとともに、そ
の態勢完了を示す旨の通知情報（「通知了解」）のアッ
プロードパケットを配信装置１に返送するため、このア
ップロードパケットによって、上記ステップＳ１２の判
定結果が“ＹＥＳ”となる。この場合、ステップＳ１８
に進み、端末Ａにおいて伝送方式の変更が行なわれてい
ることを示す所定のフラグ（便宜的に「伝送方式変更フ
ラグ」とする）をセットし、ステップＳ１９で上記変更
中フラグをリセットした後、フローを終了する。

【００３７】図１０において、配信装置１は、ステップ
Ｓ２１で、例えば、インターネット上の情報蓄積サーバ
（図６の情報蓄積サーバ１０参照）から要求情報（デー
タａ）を受け取ると、次に、ステップＳ２２で変更中フ
ラグがセットされているか否かを判定し、セットされて
いる場合、すなわち、同一情報を要求した端末から「伝
送方式変更通知」の「通知了解」を内容とするアップロ
ードパケットを受信するまでの間、ステップＳ２２をル
ープして待機する一方、セットされていない場合は、ル
ープを抜けてステップＳ２３に進み、上記ステップＳ２
１で受け取った情報（データａ）を、例えば、放送波２
ｂを用いて送信する。

【００３８】そして、ステップＳ２４で伝送方式変更フ
ラグがセットされているか否かを判定し、セットされて
いない場合はそのままフローを終了し、セットされてい
る場合、すなわち、複数の端末からの同一情報の要求の
場合は、ステップＳ２５に進み、当該情報のすべての送
信完了を判定し、その判定結果が“ＹＥＳ”の場合に、
ステップＳ２６で当該複数の端末のうち初回の要求を除
く２回目以降の要求を行なった端末（図８の例では端末
Ａ）に対して、伝送方式の終了を通知し、ステップＳ２
７で伝送方式変更フラグをリセットした後、フローを終
了する。

【００３９】ここで、ステップＳ２３におけるデータ送
信の方式は、伝送方式変更フラグがセットされていない
場合とセットされている場合で異なる方式を採用する。
すなわち、伝送方式変更フラグがセットされていない場
合は、単一の端末に対するデータ転送であるから、当該
端末を宛先とするユニキャスト方式のデータ送信を行な
い、一方、伝送方式変更フラグがセットされている場合
は、複数の端末に対する同一データの転送であるから、
当該複数の端末を宛先とするマルチキャスト方式のデー
タ送信を行なう。なお、ステップＳ２３においては伝送
方式（ユニキャスト方式／マルチキャスト方式）に関わ
らず共に放送波２ｂを伝送媒体としているが、各方式に
適した伝送媒体を使い分ける（例えば、マルチキャスト
方式には放送波２ｂを適用し、ユニキャスト方式には公
衆回線網２ａを適用する。）ことが好ましい。

【００４０】図１１は端末３_i（例えば、前述の端末
Ａ、Ｂ）におけるダウンロードパケットの受信動作を示
すフローチャートである。この図において、まず、ステ
ップＳ３１で配信装置１からのダウンロードパケットを
受信すると、当該パケット中の送信先アドレスを取り出
し、そのアドレス値を“判定値”（後述）と比較して自
分宛てのパケットであるか否かを判定する。ここで、判
定値は二つの値をとり得る。その一つは自端末固有のア
ドレス（以下「固有アドレス」という）であり、他の一
つは自端末を含むグループアドレスである。いずれの値
が判定値に採用されるかは、後述のステップＳ３７の判
定結果に依存する。但し、初期値は固有アドレスであ
る。

【００４１】配信装置１から端末３_iに対しては、伝送
方式変更通知や伝送方式変更終了通知などの各種通知情
報を含むダウンロードパケットまたは要求情報（上記例
示ではデータａ）を含むダウンロードパケットが送信さ
れる。これらの情報のうち、各種通知情報はもっぱらユ
ニキャスト方式で送信されるが、要求情報（上記例示で
はデータａ）については、単一の端末からの要求の場合
にユニキャスト方式、複数の端末からの要求の場合にマ
ルチキャスト方式で送信される。

【００４２】今、ステップＳ３１で受信したダウンロー
ドパケットが自端末宛ての伝送方式変更通知である場合
を考える。ステップＳ３３は当該パケットから取り出さ
れた送信先アドレスと判定値とを比較する部分であり、
自端末宛ての伝送方式変更通知の場合、このステップＳ
３３の判定結果は“ＹＥＳ”となるから、ステップＳ３
４に進み、このステップＳ３４で伝送方式変更通知であ
るか否かを判定する。この場合、ステップＳ３４の判定
結果は“ＹＥＳ”となるので、ステップＳ３５で上記ス
テップＳ３３の判定値にグループアドレスをセットし、
ステップＳ３６で配信装置1に対して了解通知を送信し
た後、フローを終了する。

【００４３】一方、ステップＳ３１で受信したダウンロ
ードパケットが要求情報（データａ）である場合、その
ダウンロードパケットの伝送方式は、事前に伝送方式変
更通知が行われていればマルチキャスト方式、行われて
いなければユニキャスト方式である。そして、ステップ
Ｓ３３における判定値は、事前に伝送方式変更通知が行
われていればグループアドレスであり、行われていなけ
れば固有アドレスである。

【００４４】したがって、ステップＳ３３の判定結果が
“ＹＥＳ”となるときは、「ユニキャスト方式で且つ自
端末宛ての場合」か「マルチキャスト方式の場合」の二
つのケースである。伝送方式変更通知を受信した後のこ
れら二つのケースにおいては、ステップＳ３７に進み、
ダウンロードパケットが伝送方式変更終了通知であるか
否かを判定する。そして、伝送方式変更終了通知でない
場合は、ステップＳ３８でダウンロードパケットが要求
情報（データａ）であるか否かを判定し、要求情報であ
れば、ステップＳ３９で当該ダウンロードパケットを受
信した後、フローを終了する。なお、ステップＳ３８の
判定結果が“ＮＯ”の場合は、ダウンロードパケットは
その他の処理を指定する制御情報であるから、ステップ
Ｓ３８ａで当該処理を実行した後、フローを終了する。

【００４５】他方、ステップＳ３１で受信したダウンロ
ードパケットが伝送方式変更終了通知である場合、ステ
ップＳ３７の判定結果が“ＹＥＳ”となり、この場合、
ステップＳ４０で前述の判定値を初期値（固有アドレ
ス）に戻し、ステップＳ４１で配信装置１に対して、伝
送方式変更終了通知を了解した旨の通知了解を送信した
後、フローを終了する。

【００４６】以上の第１実施例によれば、図９〜図１１
の動作フローで説明したように、単一の端末から情報要
求があった場合と、複数の端末から同一の情報要求があ
った場合で、当該情報を配信する際の伝送方式（ユニキ
ャスト方式／マルチキャスト方式）を使い分けることが
できる。すなわち、単一の端末から情報要求があった場
合にはユニキャスト方式で配信することができ、さら
に、複数の端末から同一の情報要求があった場合にはマ
ルチキャスト方式で配信することができる。したがっ
て、一対多の情報配信により、同一情報の要求端末数
（ｎ）に応じてネットワーク上を流れるダウンロードパ
ケットを１／ｎに削減でき、それだけネットワークトラ
フィックを抑制することができる。

【００４７】（３）第２実施例次に、本発明の第２実施例について説明する。図１２は
第２実施例を示す概念構成図であり、第１実施例との大
きな違いは配信装置１に送信履歴記憶部（発明の要旨に
記載の記憶手段に相当）２０を備えた点にある。この送
信履歴記憶部２０は、図１３にその概念構成を示すよう
に、端末宛ての送信済み情報の名前（図ではデータ
名）、その送信回数、送信周期およびデータ本体などを
記憶する。なお、送信周期は送信回数が２回以上の場合
に有意値（数値として有効な値）となり、例えば、２回
とすると、その有意値は１回目の送信から２回目の送信
までの時間値に相当する値になるが、３回ないしそれ以
上の送信回数の場合は各回の送信周期の平均値を有意値
としてもよい。送信履歴記憶部２０における新規データ
の履歴記録位置は図１３中の白抜き矢印で示されてい
る。この位置は、新規に記録されるデータの重複要求の
可能性を考慮して、データテーブルのできるだけ先頭に
近い行（送信回数を１回とするデータの先頭行）とする
ものである。

【００４８】送信履歴記憶部２０の記憶情報は、以下の
ようにして利用する。図１４は配信装置１と二つの端末
３_i（便宜的に端末Ａ、端末Ｂ）との間のデータ配信を
示すタイムランである。この図において、端末（図では
端末Ｂ）から情報（図ではデータａ）の要求があった場
合、配信装置１は、送信履歴記憶部２０の記憶情報（図
１３参照）に基づいて保留時間Ｔａを設定し、データａ
の端末への送信を当該保留時間Ｔａだけ保留する。そし
て、保留時間Ｔａの間に他の端末（図では端末Ａ）から
同一情報（データａ）の要求があった場合は、端末Ａに
対してマルチキャスト方式で送信する旨の事前通知（伝
送方式変更通知）を行なうとともに、その通知了解を端
末Ａから受け取り、しかる後、当該保留時間Ｔａを経過
すると、要求情報（データａ）をマルチキャスト方式で
送信し、各端末（図では端末Ａ、Ｂ）はマルチキャスト
方式で伝送された情報（データａ）を一斉受信する。

【００４９】図１５は本実施例における配信装置１の動
作フローチャートである。図において、本実施例の配信
装置１は、端末からの情報要求（便宜的にデータａの要
求とする）があると、まず、ステップＳ５１で送信履歴
記憶部２０の記憶情報を参照して要求情報（データａ）
の記録が残っているかどうかを調べる。今、送信履歴記
憶部２０の記憶情報を図１３のとおりとすると、データ
ａの記録は１行目に残っており、その送信回数は１０
回、送信周期は５１（単位は例えばミリ秒）である。

【００５０】配信装置１は、次に、ステップＳ５２で当
該記憶情報中の送信周期が所定の要求間隔値以下の有意
値であるか否かを判定する。そして、その判定結果が
“ＮＯ”の場合には、ステップＳ６１に進んで、例え
ば、インターネットなどに接続された情報蓄積サーバ等
に要求を転送し、ステップＳ６２で当該サーバからの情
報を受信すると、ステップＳ６３で公衆回線網２ａを介
して要求端末へ情報（データａ）を転送した後、フロー
を終了する。なお、ステップＳ６３で公衆回線網２ａを
使用する理由は、当該情報（データａ）の要求周期が所
定の要求間隔値を超える程度に長く、要するに、単一の
端末から利用される要求頻度の低い情報であることか
ら、もっぱらユニキャスト方式のパケット通信を適用す
る情報であるため、ことさら放送波２ａを利用するまで
もないからである。

【００５１】一方、ステップＳ５２の判定結果が“ＹＥ
Ｓ”の場合、すなわち、当該情報（データａ）の要求周
期が所定の要求間隔値以下であって、要するに、複数の
端末から利用される要求頻度の高い情報である場合は、
ステップＳ５３で保留時間Ｔａ（当該情報の要求周期：
５１ミリ秒を若干超える程度の時間または５００ミリ程
度の固定時間）だけ待機する。そして、その保留時間Ｔ
ａの間に他の端末から同一情報の要求を受信（ステップ
Ｓ６０参照）すると、前述したとおり、他の端末に対し
て伝送形式変更通知を送信し、ステップＳ５４で当該他
の端末から了解通知を受け取るまで待機する。

【００５２】当該他の端末から了解通知を受け取ると、
ステップＳ５５で送信履歴記憶部２０から要求情報（デ
ータａ）を取り出して送信し、ステップＳ５６で伝送方
式変更フラグがセットされているか否かを判定し、セッ
トされていない場合はそのままフローを終了し、セット
されている場合、すなわち、複数の端末からの同一情報
の要求の場合は、ステップＳ５７に進み、当該情報のす
べての送信完了を判定し、その判定結果が“ＹＥＳ”の
場合に、ステップＳ５８で当該複数の端末のうち初回の
要求を除く２回目以降の要求を行なった端末に対して、
伝送方式の終了を通知し、ステップＳ５９で伝送方式変
更フラグをリセットした後、フローを終了する。

【００５３】ここで、ステップＳ５５におけるデータ送
信の方式は、伝送方式変更フラグがセットされていない
場合とセットされている場合で異なる方式を採用する。
すなわち、伝送方式変更フラグがセットされていない場
合は、単一の端末に対するデータ転送であるから、当該
端末を宛先とするユニキャスト方式のデータ送信を行な
い、一方、伝送方式変更フラグがセットされている場合
は、複数の端末に対する同一データの転送であるから、
当該複数の端末を宛先とするマルチキャスト方式のデー
タ送信を行なう。なお、ステップＳ５５においては伝送
方式（ユニキャスト方式／マルチキャスト方式）に関わ
らず共に放送波２ｂを伝送媒体としているが、各方式に
適した伝送媒体を使い分ける（例えば、マルチキャスト
方式には放送波２ｂを適用し、ユニキャスト方式には公
衆回線網２ａを適用する。）ことが好ましい。

【００５４】このように、第２実施例においては、配信
装置１に送信履歴記憶部２０を設け、端末からの情報要
求時に送信履歴記憶部２０を調べて当該要求情報の履歴
が残っていて、且つ、その履歴中の送信周期の値が所定
の要求間隔値以下の場合に、送信履歴記憶部２０から要
求情報（データ本体）を取り出して送信するので、当該
要求情報をインターネットなどに接続された情報蓄積サ
ーバ等から取り込む必要がなく、情報蓄積サーバ等との
間での無用なパケット伝送を回避できるという特有の効
果が得られる。

【００５５】なお、本第２実施例において、図１６に示
すように、単一の端末（図では端末Ｂ）から情報要求
（例えば、データｇの要求）があった場合は、そのデー
タｇをユニキャスト方式で端末Ｂに送信することになる
ため、ことさら放送波２ｂを用いる必要はなく、図示の
とおり、公衆回線網２ｂを用いて伝送してもよい。

【００５６】また、電話回線網２ｂを用いて伝送する場
合は、専用線でない限り、当然ながら通信費（電話代）
が発生するため、端末側で電話回線網２ｂによる転送を
拒否できる仕組みを作っておくことが望ましい。図１７
はその仕組みを加味した、前述の図１５の変形例であ
り、図１５との相違部分は破線で囲んだステップＳ６４
である。すなわち、この変形例では、ステップＳ５２の
判定結果が“ＮＯ”となって電話回線網２ｂを用いたデ
ータ伝送を行なう可能性が生じたときに、ステップＳ６
４ａで、端末に対して電話回線網２ｂによる伝送を実行
してよいかどうかの問い合わせを行ない、ステップＳ６
４ｂでその問い合わせに対する端末からの回答（了解／
拒否）を判定し、転送を拒否する場合にそのままフロー
を終了する一方、転送を希望（了解）する場合にステッ
プＳ６１以降を実行して、端末に対して電話回線網２ｂ
による伝送を行なうというものである。

【００５７】図１８（ａ）は端末における画面表示例で
ある。この図に示す文字列のうちアンダーライン付きの
ものは各々リンクが張られた文字列である。任意の文字
列をオンクリック、例えば、マウス等のポィンティング
デバイスを用いてカーソル（図では白抜き矢印形のカー
ソル）をその文字列の上に移動させてクリックすること
により、当該文字列のリンク先に保存されているコンテ
ンツ情報を取り込むことができる。

【００５８】ここで、上記文字列のうち“今朝のニュー
ス”や“関東地方の天気予報”などは利用頻度の高い情
報であるが、占いコーナの各月の情報（“１月”、“２
月”、……、“１２月”）などは比較的利用頻度の低い
情報である。したがって、これらの利用頻度の低い情報
の履歴は、配信装置１の送信履歴記憶部２０に残ってお
らず、または、残っていたとしてもその送信周期は所定
の要求間隔値を超える可能性が高い。このため、占いコ
ーナの各月の情報（“１月”、“２月”、……、“１２
月”）をクリックした場合は、図１７の動作フローのス
テップＳ５２の判定結果が高い蓋然性で“ＮＯ”にな
り、同フローのステップＳ６４ａで端末に対する転送問
い合わせが行われることとなる。

【００５９】図１８（ｂ）は端末における問い合わせ画
面表示を示す図であり、同画面上には電話料金が発生す
る旨とその予想金額のメッセージＭが表示されるととも
に、転送を了解するコマンドオブジェクト（“はいボタ
ン”Ｂ１）と、転送を拒否するコマンドオブジェクト
（“いいえボタン”Ｂ２；発明の要旨に記載のオブジェ
クトに相当）が表示されている。ユーザは電話料金を確
認して、転送を了解する場合は“はいボタン”Ｂ１をク
リックし、拒否する場合は“いいえボタン”Ｂ２をクリ
ックする。

【００６０】これによれば、利用頻度の低い情報を要求
した際に、所要の問い合わせメッセージＭを表示するこ
とができ、ユーザの了解をとった場合だけに電話回線網
２ｂを用いた情報転送を行なうことができる。

【００６１】なお、図１８（ａ）の画面表示例におい
て、利用頻度の高いリンク文字列と、利用頻度の低いリ
ンク文字列の各々の文字属性（文字色や文字フォントま
たは文字の太さもしくは大きさ等）を異ならせてもよ
い。このようにすると、画面表示を一瞥しただけで利用
頻度の高低を判別でき、電話回線網２ａによる伝送を直
感的に事前予測できるからである。

【００６２】（４）第３実施例次に、本発明の第３実施例について説明する。図１９は
第３実施例を示す概念構成図であり、第２実施例との大
きな違いは端末１に先行データ記憶部２１を備えた点に
ある。この先行データ記憶部２１は、要求情報に関連す
る“先行データ”（詳細は後述）を取り込み、この先行
データを必要とされる時期まで保持するものである。

【００６３】ここで、先行データについて説明する。図
２０（ａ）は端末の画面上に表示されたＨＴＭＬ文書の
例であり、このＨＴＭＬ文書は複数のリンク付き文字列
（アンダーラインを付した文字列）とともに、イメージ
オブジェクト２２を有している。図２０（ａ）は当該Ｈ
ＴＭＬ文書のリストであり、１行目にタイトル（“便利
ページ”）が記述され、２行目にイメージオブジェクト
２２のリンク先（“ｃｎｅｔ＿ｌｏｇｏ．ｊｐｇ”）が
記述されている。なお、“＜”、“＞”、“Ｈ２”、
“／Ｈ２”、“ＢＲ”、“ＩＭＧＳＲＣ＝”、“Ａ
ＨＲＥＦ＝”などは公知のＨＴＭＬタグである。

【００６４】今、このＨＴＭＬ文書のデータ名（文書
名）を便宜的にデータｘとし、当該データｘをダウンロ
ードすることを考えると、ＴＣＰ／ＩＰではデータごと
に要求と応答を繰り返すため、データｘの要求後、その
データｘに含まれるサブデータ（上記例示ではイメージ
オブジェクト２２のデータ；以下データｙとする）の要
求が付随的に発生することとなり、結局、データｘの要
求とデータｙの要求は密接不可分の関係になる。

【００６５】したがって、複数の端末からデータｘの要
求があった場合、データｘに続けてデータｙの要求も発
生するから、先行要求側の端末に対して配信装置１から
送信されたデータｙ（上記先行データに相当）を後要求
側の端末に先行して取り込んでおき、データｘの受信後
にそのデータｙを画面表示することにより、後要求側の
端末から配信装置１へのデータｙの要求を不要にするこ
とができる。その結果、データｙの要求パケットがネッ
トワークに流れ込まないため、トラフィックを抑制でき
るという効果が得られる。

【００６６】図２１は先行データの事前取り込みを行な
うようにした本第３実施例のタイムランである。この図
は、端末Ｂから配信装置１に対してデータｙの要求が行
われた後、端末Ａから配信装置１に対してデータｘの要
求が行われた場合を示している。配信装置１は送信履歴
記憶部２０を調べてデータｘの履歴を調査する。上記の
とおり、データｙとデータｘの要求は密接不可分の関係
にあるから、端末Ｂからのデータｙの要求の前に（図で
は略しているが）当該端末Ｂから配信装置１に対してデ
ータｘの要求が発生していたはずである。したがって、
上記調査の結果は「データｘの履歴あり」となり、配信
装置１は端末Ａに対して先行データ（データｙ）の取り
込みと先行データ記憶部２１への保存を指示するための
通知（図では「先行受信要求通知」）を送信する。端末
Ａは当該通知を受け取って所要の準備を整えた後、通知
了解を配信装置１に送信する。

【００６７】配信装置１は伝送方式変更通知を端末Ａに
送信し、端末Ａはその了解通知を配信装置１に送信す
る。そして、配信装置１はデータｙをマルチキャスト方
式で送信し、端末Ａ、Ｂはそのデータｙを一斉受信する
が、データｙは上述の先行データであるから、端末Ａは
受信したデータｙを先行データ記憶部２１に書込む。次
に、配信装置１は端末Ａに対して先行解除要求を通知
し、端末Ａは了解通知を配信装置１に送信する。次に、
配信装置１は端末Ａに対して伝送方式解除通知を送信
し、端末Ａは了解通知を配信装置１に送信する。最後
に、配信装置１は、データｘを要求元の端末Ａに対して
送信し、端末Ａはデータｘを受信して、そのデータｘと
先行データ記憶部２１の記憶データ（データｙ）とを画
面に表示する。

【００６８】図２２は本第３実施例における端末の動作
フローチャートである。この図において、まず、ステッ
プＳ７１で行変数ｉを初期化（１をセット）し、ステッ
プＳ７２でＨＴＭＬ文書（データｘ）のｉ行目を調べ、
ステップＳ７３でｉ行目にサブデータ（前記のデータ
ｙ）の情報が記載されているか否かを判定する。そし
て、データｙの情報が記載されていなければ、ステップ
Ｓ７９に進んでデータｘを画面表示し、データｙの情報
が記載されていれば、ステップＳ７４で先行データ記憶
部２１の記憶内容を調べ、ステップＳ７５で先行データ
（データｙ）が格納済みであるか否かを判定する。

【００６９】そして、格納済みであれば、ステップＳ７
８でその先行データ（データｙ）を読み出した後、ステ
ップＳ７９に進んでデータｘとデータｙを画面に表示す
る一方、格納済みでなければ、ステップＳ７６およびス
テップＳ７７でサーバ等からデータｙを取得した後、ス
テップＳ７９に進んでデータｘとデータｙを画面に表示
する。そして、ステップＳ８０で行変数ｉを＋１し、ス
テップＳ８１で全行終了を判定（例えば、データｘのＥ
ＯＦ：End Of Fileコードを検出）するまで、ステップ
Ｓ７２以降を繰り返し実行し、全行終了を判定するとフ
ローを終了する。

【００７０】以上のとおり、本第３実施例によれば、あ
るデータ（上記例示ではデータｘ）と密接不可分にある
他のデータ（上記例示ではデータｙ）を事前に受信して
先行データ記憶部２１に保存できるとともに、データｘ
の受信後にこの保存データ（先行データ；データｙ）を
取り出して、データｘとともに画面表示することができ
る。したがって、先行データ（上記例示ではデータｙ）
の要求パケットをネットワークに流し込むことがないか
ら、それだけトラフィックを抑制できるという特有の効
果が得られる。

【００７１】

【発明の効果】請求項１記載の発明によれば、複数の端
末からの同一情報の要求の場合に当該複数の端末宛てに
マルチキャスト方式で情報を配信するので、例えば、情
報要求の端末数をｎとすると、ネットワーク上のパケッ
ト数を１／ｎに減少することができ、それだけネットワ
ークトラフィックを抑制できる。請求項２記載の発明に
よれば、情報配信パケットの送信先アドレスを、単一の
端末に固有のアドレスから複数の端末に共通のアドレス
へ、またはその逆に変更するだけで、配信情報の伝送方
式を自在に切り換えることができ、既存のネットワーク
インフラを利用して請求項１記載の発明を実現できる。
請求項３記載の発明によれば、複数の端末からの同一情
報の要求の場合に当該複数の端末宛てにマルチキャスト
方式で情報を配信するので、例えば、情報要求の端末数
をｎとすると、ネットワーク上のパケット数を１／ｎに
減少することができ、それだけネットワークトラフィッ
クを抑制できる。請求項４記載の発明によれば、複数の
端末からの要求頻度の高低に応じてユニキャスト方式と
マルチキャスト方式を使い分けることができる。請求項
５記載の発明によれば、情報配信パケットの送信先アド
レスを、単一の端末に固有のアドレスから複数の端末に
共通のアドレスへ、またはその逆に変更するだけで、配
信情報の伝送方式を自在に切り換えることができ、既存
のネットワークインフラを利用して請求項４記載の発明
を実現できる。請求項６記載の発明によれば、配信装置
からの伝送方式を端末側で事前に把握することができ
る。請求項７記載の発明によれば、配信装置からの伝送
方式が所定の伝送方式である場合に当該伝送を端末側で
拒否することができ、例えば、所定の伝送方式を電話回
線網を用いたユニキャスト方式とした場合に当該方式
（通信費が発生する伝送方式である）を事前に承知また
は拒否することができる。

【図面の簡単な説明】

【図１】実施形態における情報配信システムの概念構成
図である。

【図２】実施形態における配信装置１と各端末３_iの間
のパケット通信概念図である。

【図３】実施形態における情報配信の概念図である。

【図４】インターネットプロトコルにおけるＩＰアドレ
スの概念図である。

【図５】実施形態における配信装置１と二つの端末３_i
（便宜的に端末Ａ、端末Ｂ）との間のデータ配信を示す
タイムランである。

【図６】第１実施例を示す概念構成図である。

【図７】第１実施例におけるデータ送受信制御装置１３
の要部ブロック図である。

【図８】第１実施例における配信装置１と二つの端末３
_i（便宜的に端末Ａ、端末Ｂ）との間のデータ配信を示
すタイムランである。

【図９】第１実施例における端末３_iからのアップロー
ドパケット受信時に実行される動作フローチャートであ
る。

【図１０】第１実施例における端末３_iへのダウンロー
ドパケット送信時に実行される動作フローチャートであ
る。

【図１１】第１実施例における端末３_i（例えば、前述
の端末Ａ、Ｂ）におけるダウンロードパケットの受信動
作を示すフローチャートである。

【図１２】第２実施例を示す概念構成図である。

【図１３】第２実施例における送信履歴記憶部２０の概
念構成図である。

【図１４】第２実施例における配信装置１と二つの端末
３_i（便宜的に端末Ａ、端末Ｂ）との間のデータ配信を
示すタイムランである。

【図１５】第２実施例における配信装置１の動作フロー
チャートである。

【図１６】第２実施例における他の動作例を示すタイム
ランである。

【図１７】端末側で電話回線網２ｂによる転送を拒否で
きる仕組みを加味した第２実施例の変形例を示す図であ
る。

【図１８】第２実施例の変形例における端末３_iの画面
表示例である。

【図１９】第３実施例を示す概念構成図である。

【図２０】第３実施例における端末３_iの画面上に表示
されたＨＴＭＬ文書の例およびそのリスト図である。

【図２１】第３実施例におけるタイムランである。

【図２２】第３実施例における端末３_iの動作フローチ
ャートである。

【符号の説明】

Ｂ２いいえボタン（オブジェクト）１配信装置（情報配信装置）３_i 端末８サーバー主制御部（判定手段、配信手段、決定手
段）１３データ送受信制御装置（受信手段）１４データ利用装置（提供手段）２０送信履歴記憶部（記憶手段）

Claims

【特許請求の範囲】

【請求項１】端末から要求された情報を当該端末宛て
に配信する情報配信方法において、前記要求が単一の端末からのものであるときは当該要求
された情報をユニキャスト方式で配信する一方、前記要
求が複数の端末からのものであるときは当該要求された
情報をマルチキャスト方式で配信するようにしたことを
特徴とする情報配信方法。
【請求項２】前記ユニキャスト方式による情報配信は
送信先アドレスを前記単一の端末に固有のアドレスとす
る一方、前記マルチキャスト方式による情報配信は前記
複数の端末に共通のアドレスとすることを特徴とする請
求項１記載の情報配信方法。
【請求項３】単一の端末からの情報要求であるか複数
の端末からの同一情報の要求であるかを判定する判定手
段と、前記判定手段によって単一の端末からの情報要求である
ことが判定された場合に当該端末宛てにユニキャスト方
式で要求情報を配信する一方、前記判定手段によって複
数の端末からの同一情報の要求であることが判定された
場合に当該複数の端末宛てにマルチキャスト方式で要求
情報を配信する配信手段と、を備えたことを特徴とする情報配信装置。
【請求項４】過去の配信情報の履歴を記憶する記憶手
段と、端末から情報要求があったときに前記配信履歴を調べて
ユニキャスト方式で配信するかマルチキャスト方式で配
信するかを決定する決定手段と、前記決定手段の決定結果で示された方式を用いて要求情
報を配信する配信手段と、を備えたことを特徴とする情報配信装置。
【請求項５】前記ユニキャスト方式による情報配信は
送信先アドレスを前記単一の端末に固有のアドレスとす
る一方、前記マルチキャスト方式による情報配信は前記
複数の端末に共通のアドレスとすることを特徴とする請
求項３または請求項４記載の情報配信装置。
【請求項６】配信装置に対して所要の情報要求を出力
するためのユーザインターフェースを提供する提供手段
と、前記配信装置からユニキャスト方式で伝送される前記情
報およびマルチキャスト方式で伝送される前記情報を受
信する受信手段と、を備え、前記ユーザインターフェースは前記配信装置から伝送さ
れる情報の伝送方式を事前に識別表示することを特徴と
する情報受信装置。
【請求項７】前記ユーザインターフェースは前記配信
装置から伝送される情報の伝送方式が所定の伝送方式で
ある場合に伝送を拒否するオブジェクトを有することを
特徴とする請求項６記載の情報受信装置。