JPH11212882A

JPH11212882A - 情報受配信方法及び情報受配信システム

Info

Publication number: JPH11212882A
Application number: JP10019284A
Authority: JP
Inventors: Akira Kubota; 旭久保田; Toshikuni Hamano; 登志▲邦▼ 濱野; Shinya Abe; 信也阿部
Original assignee: PFU Ltd
Current assignee: PFU Ltd
Priority date: 1998-01-30
Filing date: 1998-01-30
Publication date: 1999-08-06

Abstract

(57)【要約】【課題】本発明は、情報受配信方法に関し、配信され
るデータの個数とデータ量を共に減らし伝送効率を向上
することを目的とする。【解決手段】サーバ１００は、クライアント２００に
対して配信すべき情報である複数の記事に共有の部分で
ある１又は２以上の共有データをまとめて、これをアー
カイブした１又は２以上の共有アーカイブを配信し、か
つ、複数の記事の各々に固有の部分である複数の固有デ
ータを、所定の条件に従って１又は２以上のグループに
まとめて、これを前記グループ毎にアーカイブした１又
は２以上の固有アーカイブを配信する。クライアント２
００の各々は、サーバ１００から配信される１又は２以
上の共有アーカイブ及び１又は２以上の固有アーカイブ
を受信し、これらから前記複数の記事を得る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報受配信方法及
び情報受配信システムに関し、特に、情報の内容に基づ
いて情報の受信及び配信を統一的に行う情報受配信シス
テムにおいて、一旦配信した情報のクライアントにおけ
る更新、削除等をサーバから管理する情報受配信方法及
び情報受配信システムに関する。

【０００２】

【従来の技術】最近のコンピュータネットワークの発達
に伴い、種々の公開された情報（コンテンツ）が企業や
個人というユーザの個々の壁を越えてこれらの間でコン
ピュータネットワークを介して受信、配信されている。
一方、例えば企業等においては、自社内の支店、営業
所、工場、研究所等をコンピュータネットワークで接続
する企業内ネットワーク（イントラネット）の構築が行
われている。

【０００３】このようなコンピュータネットワークを介
して情報の受信及び配信を行う情報受配信システムにお
いては、一般的に、端末数が多いこと等から、ツリー状
の接続形態が採られ、情報を配信するサーバと情報を受
信するクライアントとで構成される。サーバは多段で構
成され、上位サーバから下位サーバへ情報が伝播され、
更に各サーバに接続されているクライアントに情報が伝
播される。

【０００４】

【発明が解決しようとする課題】例えば、情報受配信シ
ステムの一例であるインターネット上のニュースシステ
ムによれば、新聞社（のホストコンピュータ、即ち、サ
ーバ）が配信する新聞記事を、個人（クライアントユー
ザ）がその情報端末（即ち、クライアント）から読むこ
とができる。この場合、クライアントユーザは自分が購
読したいニュースをグループ単位で自由に選択して、そ
のニュースグループのみを購読することができる。

【０００５】ところで、このような情報受配信システム
では、情報を配信するサーバから情報の提供を受けるク
ライアントへ随時情報が配信されるため、配信されるデ
ータの個数とデータ量が膨大なものになる。そこで、デ
ータの個数を減らして通信の回数を減らし、データ量を
圧縮して通信時間を短縮することが必要になる。

【０００６】このような観点から配信される情報を見る
と、配信される記事Ａで使用しているデータと記事Ｂで
使用しているデータとが同一であること、即ち、共有デ
ータである場合がある。図１８に共有データの例を示
す。

【０００７】コンテンツ＃１（記事Ａ）とコンテンツ＃
２（記事Ｂ）とは、共に４個のデータ（要素）から成立
しているが、文章部分のデータ（文書データ）が異なる
のみで、他の会社名のロゴイメージデータ、飾り罫線の
イメージデータ、ポスト印のアイコンのイメージデータ
の３個のデータが共有データとなっている。しかし、コ
ンテンツ＃１、又はコンテンツ＃２のいずれを配信する
場合でも４個のデータを送信する必要がある。従って、
コンテンツ＃１とコンテンツ＃２とを配信した場合、ロ
ゴデータ、飾り罫線データ、ポスト印のアイコンデータ
を二重に配信することになり、ネットワーク負荷を増加
させる要因となっている。実際にはｎ重に配信されてい
るため、システム全体では膨大な無駄となっている。

【０００８】そこで、このようなネットワーク負荷を軽
減するために、いくつかの方式が提案されている（詳細
は実施例において、本発明と比較して述べる）。第１
に、コンテンツ毎にアーカイブすることなく、例えば前
述の個々の要素毎に配信する方式がある（方式Ａとい
う）。この方式Ａによれば、共有データについては二重
に配信せずに済み、個々の要素毎にデータ圧縮すること
も可能である。しかし、アーカイブされていないので、
ネットワークに流れるデータの個数が多くなり、コネク
ション回数とパケット数が軽減されない。

【０００９】第２に、コンテンツ毎に必要なデータを揃
えこれらをアーカイブ（圧縮）して配信する方式がある
（方式Ｂという）。この方式Ｂによれば、アーカイブ
（及び圧縮）されているのでネットワーク負荷は軽減さ
れる。しかし、アーカイブされているので、個々の要素
は二重に配信されてしまう。

【００１０】第３に、コンテンツ毎にアーカイブするこ
となく、あるタイミングで（例えば、１日に１回）全て
のデータ（コンテンツ＃１及び＃２）をまとめてアーカ
イブして配信する方式がある（方式Ｃという）。この方
式Ｃによれば、共有データについては当該アーカイブに
１個づつでよいので、同一アーカイブ内のデータについ
て見ると二重に配信せずに済み、アーカイブ（及び圧
縮）されているのでネットワーク負荷は軽減される。し
かし、次のタイミングで（例えば、翌日）データを配信
する際に共有データについては再送する必要がある。こ
れは、前日のコンテンツがクライアントにおいて廃棄さ
れていると、翌日のコンテンツのデータの一部が不足し
エラーとなるためである。従って、共有データについて
は、結果として必ず二重配信になる。

【００１１】本発明は、配信されるデータの個数とデー
タ量を共に減らしてネットワーク負荷を軽減した情報受
配信方法を提供することを目的とする。また、本発明
は、伝送効率を向上した情報受配信方法を提供すること
を目的とする。

【００１２】また、本発明は、配信されるデータの個数
とデータ量を共に減らしてネットワーク負荷を軽減した
情報受配信システムを提供することを目的とする。ま
た、本発明は、伝送効率を向上した情報受配信システム
を提供することを目的とする。

【００１３】

【課題を解決するための手段】図１は本発明の原理構成
図であり、本発明による情報受配信方法を実行する情報
受配信システムの構成を示す。この情報受配信システム
は、情報を配信するサーバ１００とサーバ１００に接続
されサーバ１００から配信される情報を受信する複数の
クライアント２００とからなる。

【００１４】サーバ１００は、クライアント２００に対
して配信すべき情報である複数の記事に共有の部分であ
る１又は２以上の共有データをまとめて、これをアーカ
イブした１又は２以上の共有アーカイブを配信する。ま
た、サーバ１００は、複数の記事の各々に固有の部分で
ある複数の固有データを、所定の条件に従って１又は２
以上のグループにまとめて、これを当該グループ毎にア
ーカイブした１又は２以上の固有アーカイブを配信す
る。

【００１５】一方、クライアント２００の各々は、サー
バ１００から配信される１又は２以上の共有アーカイブ
を受信し、また、１又は２以上の固有アーカイブを受信
する。そして、クライアント２００の各々は、１又は２
以上の共有アーカイブと１又は２以上の固有アーカイブ
とから前記複数の記事を得る。

【００１６】サーバ１００は、例えば記事Ａ乃至Ｄの共
有データ「共有」を例えば１個にまとめてアーカイブ
（かつ圧縮）した１個の共有アーカイブ３００を配信
し、かつ、記事Ａ乃至Ｄの固有データ「固有Ａ」乃至
「固有Ｄ」を、例えば２個づつまとめてアーカイブ（か
つ圧縮）した２個の固有アーカイブ４０１及び４０２を
配信する。クライアント２００は、１個の共有アーカイ
ブ３００と２個の固有アーカイブ４０１及び４０２とを
受信し、これらを復元して記事Ａ乃至Ｄを得る。

【００１７】従って、本発明の情報受配信方法によれ
ば、複数の記事の複数の固有データは１又は２以上のグ
ループにまとめた上でアーカイブされているので、ネッ
トワークに流れるデータの個数（コネクション回数やパ
ケット数）を減らすことができる（なお、グループにま
とめた上で圧縮することができるので、データ量も減ら
すことができる）。これにより、ネットワーク負荷は軽
減される。

【００１８】一方、共有データについては、固有データ
とは別にアーカイブされるので、固有データの配信の都
度に配信せずに済む。また、共有データもアーカイブ
（かつ圧縮）されているので、データの個数（及びデー
タ量）も減らすことができ、これによってもネットワー
ク負荷は軽減される。更に、共有データを固有データと
は別にアーカイブすることにより、固有データの変更に
影響されることなく共有データ自体が変更されない限
り、共有データを再度配信する必要がない。

【００１９】これにより、従来二重（実際にはｎ重）に
配信されネットワーク負荷を増加させる要因となってい
た共有データについて、その重複した配信を必要な配信
のみに抑制することができ、サーバからクライアントへ
配信されるデータの個数（及びデータ量）が多くなって
も、データの個数（及びデータ量）を共に減らして通信
の回数と通信時間を短縮し、伝送効率を向上することが
できる。

【００２０】

【発明の実施の形態】図２は本発明が適用される情報受
配信システムの構成を示す。この情報受配信システムは
多段の構成を有する複数のサーバ１００と複数のクライ
アント２００とからなる。クライアント２００はいずれ
かのサーバ１００に接続される。サーバ１００相互の間
及びサーバ１００とクライアント２００の間は、専用回
線、公衆網、その他の接続線を介して接続される。

【００２１】以下の説明において、サーバ１００につい
て、その各々を区別する場合には、サーバ１００を表す
Ｓに、Ａ、Ｂ等の符号を付加して、サーバＳＡ、ＳＢ等
と表す。また、クライアント２００について、その各々
を区別する場合には、クライアント２００を表すＣに、
１、２等の符号を付加して、クライアントＣ１、Ｃ２等
と表す。

【００２２】サーバ１００は情報を作成又は受信して他
のサーバ１００又はクライアント２００に対して送信す
る。クライアント２００の接続されたサーバ１００を
（そのクライアント２００の）親サーバ１００と言う。
クライアント２００は、情報伝搬のルートの末端にあっ
て、情報を受信するのみである。

【００２３】この明細書において、サーバ１００の内で
情報を作成して他のサーバ１００又はクライアント２０
０に配信するものをコンテンツサーバ１００と言う。ま
た、あるサーバ１００又はクライアント２００から見
て、当該サーバ１００又はクライアント２００とコンテ
ンツサーバ１００とを結ぶルート（情報の伝播経路）上
にあって、よりコンテンツサーバ１００側にあるサーバ
１００を上位サーバ１００と言い、よりクライアント２
００側にあるサーバ１００を下位サーバ１００と言う。
更に、コンテンツサーバ１００とクライアント２００と
の間にあるサーバ１００を中間サーバ１００と言う。中
間サーバ１００はサーバであると同時に、より上位のサ
ーバ１００に対してはクライアント２００でもある。

【００２４】図２においては、サーバＳＡがコンテンツ
サーバ１００である。例えば、サーバＳＧはサーバＳＨ
の上位サーバであり、サーバＳＨはサーバＳＧの下位サ
ーバである。サーバＳＨ以外のサーバにも、同様に１又
は複数のクライアント２００が接続されている。

【００２５】コンテンツサーバ１００（サーバＳＡ）
は、例えば、１つの企業内におけるコンピュータネット
ワーク（イントラネット）の最も上位に位置するサー
バ、又はインターネットにおけるＷＷＷサーバである。
インターネットにイントラネットを接続した場合、イン
トラネットの最上位のサーバやＷＷＷサーバの双方がコ
ンテンツサーバ１００となる。ＷＷＷサーバから見て、
イントラネットの最上位のサーバは下位サーバである。

【００２６】情報（配信情報）は、コンテンツサーバ１
００から下位のサーバ１００に配信され、更に下位のサ
ーバ１００に配信され、更にクライアント２００に配信
される。これにより、情報はコンテンツサーバ１００か
ら末端のクライアント２００にまで伝播される。

【００２７】情報は「チャネル」と呼ぶカテゴリ単位に
分別されて配信される。チャネルは、複数の記事のまと
まったグループであり、情報の配信制御の単位である。
チャネルには、例えばスポーツチャネル、天気予報チャ
ネル、ニュースチャネル等がある。この情報と共に、当
該情報の配信等を制御するための各種の制御情報も同様
に配信される。

【００２８】図３及び図４は本発明が適用される情報受
配信システムにおける情報の配信を示す。本発明が適用
される情報受配信システムは擬似プッシュ型配信を行う
システムである。擬似プッシュ型配信システムは、下位
のサーバ１００又はクライアント２００がユーザによる
上位のサーバ１００に対する配信要求の指示入力なしで
自動的に情報の配信要求を行い、一方、上位のサーバ１
００が当該配信要求があった時に下位のサーバ１００又
はクライアント２００に対して情報を配信するシステム
である。

【００２９】なお、以下の図３及び図４についての説明
はサーバ１００とクライアント２００との間での情報の
受配信についてのものであるが、サーバ１００と更に下
位のサーバ１００との間でもほぼ同様の関係が成立す
る。即ち、この説明において、クライアント２００を下
位のサーバ１００と置き換えても良い。

【００３０】各々のサーバ１００又はクライアント２０
０の実行する処理は、実際には、当該サーバ１００又は
クライアント２００の制御プログラム（又はオペレーテ
ィングシステム）１０１及び２０１が実行する。即ち、
サーバ１００の制御プログラム１０１とクライアント２
００の制御プログラム２０１とが相互に通信をすること
によって、情報が受配信され、各々において所定の処理
が実行される。

【００３１】図３（Ａ）に示すように、あるクライアン
トＣ１があるサーバＳＡ及びＳＢに接続されている。サ
ーバＳＡ及びＳＢはクライアントＣ１の親サーバであ
り、コンテンツサーバ１００であっても中間サーバ１０
０であっても良い。サーバＳＢはサーバＳＡと関連する
他のサーバ１００であって情報の作成元及び／又は内容
によって、サーバＳＡと分離したり一体化することが可
能なものである。

【００３２】サーバＳＡはクライアントＣ１への配信を
行うために、ユーザリスト１０２、チャネル一覧情報１
０３、記事アーカイブ１０４を備える。ユーザリスト１
０２は当該サーバＳＡから情報の配信を受けるクライア
ント２００（及び下位のサーバ１００）を登録するため
のものである。チャネル一覧情報１０３は当該サーバＳ
Ａが現在公開しているチャネルを示す管理情報である。
なお、実際は、チャネル一覧情報１０３は、チャネルに
ついての情報やその他の制御情報を含む管理テーブルの
一部である。記事アーカイブ１０４は当該サーバＳＡが
現在公開しているチャネルにおける個々の情報、即ち、
記事（情報の中身を「記事」という）であり、所定の単
位でアーカイブされデータ圧縮されている。

【００３３】チャネル一覧情報１０３及び記事アーカイ
ブ１０４は共に当該サーバＳＡに接続されたクライアン
トＣ１に配信される。チャネル一覧情報１０３はこれが
配信されたクライアントＣ１においてローカルに記憶さ
れ、ローカルな（クライアントＣ１の）チャネル一覧情
報２０３とされる。チャネル一覧情報２０３はクライア
ントＣ１の管理テーブルである。一方、記事アーカイブ
１０４は、本発明に従って、特別の許可がない限り、こ
れが配信されたクライアントＣ１におけるチャネルから
のミラーリングは許されない。クライアントＣ１に代え
て下位のサーバ１００を考える時は、配信された記事ア
ーカイブ１０４は更に下位のサーバ１００に配信され
る。

【００３４】このような構成の擬似プッシュ型配信シス
テムにおけるサーバＳＡとクライアントＣ１との間での
情報の配信は図３（Ｂ）に示す手順で行われる。最初
に、クライアントＣ１がサーバＳＡにユーザ登録を依頼
する（手順）。このユーザ登録依頼は、クライアント
Ｃ１のクライアントユーザへのサーバ名登録（入力）に
応じて実行される。ユーザ登録依頼を受信したサーバＳ
Ａは、これに応じて、当該サーバＳＡが保持しているユ
ーザリスト１０２に当該クライアントＣ１をユーザとし
て登録する。これにより、クライアントＣ１から接続要
求があった時は、当該接続が行われる。

【００３５】次に、クライアントＣ１がサーバＳＡに接
続要求をする（手順の点線）。この接続要求は、クラ
イアントＣ１のユーザによる指示入力なしで、クライア
ントＣ１の制御プログラム２０１が、所定の時間間隔又
は所定のタイミング（例えば、クライアントＣ１である
情報端末でのユーザにおける所定の操作入力）で自動的
に行う。

【００３６】接続要求を受信したサーバＳＡは、これに
応じて、当該サーバＳＡが現在公開している情報のチャ
ネルの一覧（図４（Ａ）に示すチャネル一覧情報１０
３）を、当該接続要求の送信元であるクライアントＣ１
に送信（配信）する（手順の実線）。これにより、ク
ライアントＣ１はサーバＳＡから配信されたチャネル一
覧情報１０３を得て、これを自己の管理する記憶装置の
所定の位置に記憶して自己のチャネル一覧情報２０３
（図４（Ｂ）に示す）とする。

【００３７】この応答において、ユーザは、その端末で
あるクライアントＣ１を何も操作しておらず、接続要求
が行われたことを意識していない。なお、ユーザには接
続要求が見えないことを、手順において点線を用いて
表している。以下の手順においても同様である。これに
より、ユーザから見ると、外見上何もしないで、サーバ
ＳＡから自動的にチャネル一覧情報１０３が流れてきた
ように見える。

【００３８】サーバＳＡから配信されたチャネル一覧情
報１０３の一例を図４（Ａ）に示す。チャネル一覧情報
１０３は、チャネルＩＤ、チャネル名称、入手元、各種
の制御情報からなる。図４（Ａ）においては、制御情報
の一例として閲覧属性情報を示した（図では「閲覧」と
してある）。閲覧属性情報は、クライアントＣ１（及び
下位のサーバ１００）における上位サーバＳＡの配信し
た情報の受信を制御するための制御情報である。

【００３９】チャネルＩＤはチャネルを識別するための
ＩＤであり、当該システムにおいてユニークなものであ
る。チャネル名称は当該チャネルの名称であり、対応す
るチャネルＩＤを有するチャネルに含まれる情報のカテ
ゴリを示す。入手元は当該チャネルの情報を入手できる
（配信している）サーバ１００の名称（又はサーバＩ
Ｄ）である。

【００４０】チャネル一覧情報１０３が各チャネル毎の
閲覧属性情報等からなる各種の制御情報を含む。即ち、
チャネル一覧情報１０３には、各チャネル毎に閲覧属性
情報等からなる各種の制御情報が、配信元であるサーバ
ＳＡ（最初はコンテンツサーバ１００）によって付加さ
れる（書き込まれる）。サーバＳＡは、チャネル一覧情
報１０３に閲覧制御情報等を付加した後に、その状態の
チャネル一覧情報１０３をクライアントＣ１に配信す
る。これにより、配信元であるサーバＳＡ（最初はコン
テンツサーバ１００）からクライアントＣ１のチャネル
一覧情報２０３の内容を設定することができ、この結
果、クライアントＣ１における各種の処理をサーバＳＡ
（又はコンテンツサーバ１００）から制御できる。

【００４１】クライアントＣ１は、図４（Ｂ）に示すチ
ャネル一覧情報２０３を作成するために、配信されたチ
ャネル一覧情報１０３を参照して、その中の各種の制御
情報に基づいた処理を行う。

【００４２】クライアントＣ１は、既にあるチャネルに
ついてサーバＳＡにより閲覧が「必須」「不可」が設定
されている場合には、この属性をそのまま引き継ぐ。
「必須」「不可」はクライアントＣ１では変更できな
い。「自由」はクライアントＣ１が閲覧する／しないに
応じて選択できる。そして、クライアントＣ１は、この
状態のチャネル一覧情報１０３を表示してユーザに参照
させる。この表示を見たユーザは、チャネル一覧情報１
０３に付加された各種の制御情報を更新する。クライア
ントＣ１におけるこの更新は、サーバＳＡにより許され
る場合と許されない場合とが予め設定される。

【００４３】例えば、クライアントＣ１は、「自由」と
されているチャネル「ＸＸ新聞ニュース」について、実
際に閲覧が必要であるならそのまま「自由」とし、一
方、不要であるなら「不可」を入力する。これにより、
クライアントＣ１のクライアントユーザによる指示入力
が付加されたチャネル一覧情報２０３が作成される。チ
ャネル一覧情報２０３の一例を図４（Ｂ）に示す。この
チャネル一覧情報２０３に設定された制御情報は、本発
明に従って、そのまま更に下位のサーバ１００又はクラ
イアント２００にその属性として引き継がれる。

【００４４】なお、クライアントＣ１が既にチャネル一
覧情報２０３を備えている場合、クライアントＣ１が、
当該既存のチャネル一覧情報２０３の内容を、サーバＳ
Ａから配信された最新のチャネル一覧情報１０３の内容
に基づいて更新する（書き換える）。この処理もユーザ
には意識されない。

【００４５】次に、「必須」及び「自由」の記事の配信
を受けるために、クライアントＣ１が、チャネル一覧情
報２０３に基づいて、当該「必須」及び「自由」のチャ
ネルについてサーバＳＡに一覧要求をする（手順の点
線）。この一覧要求も、クライアントＣ１のユーザによ
る指示入力なしで、クライアントＣ１によって自動的に
行われる。

【００４６】この一覧要求を受信したサーバＳＡは、こ
れに応じて、当該サーバＳＡが現在公開している情報の
記事データ( アーカイブ) 一覧１０３’を、当該一覧要
求の送信元であるクライアントＣ１に送信（配信）する
（手順の実線）。この記事データ一覧１０３’も、実
際は、チャネル情報一覧（管理テーブル）１０３の一部
である。これにより、クライアントＣ１は閲覧したい旨
を指定した情報であってサーバＳＡから配信される情報
の記事データを得る。この応答においても、ユーザは、
その端末であるクライアントＣ１を何も操作しておら
ず、一覧要求が必要であることを意識することもない。

【００４７】記事データ一覧１０３’の一例を図４
（Ｃ）に示す。記事データ一覧１０３’は、当該チャネ
ルの個々の記事についての記事ＩＤとそのデータ名とか
らなる。記事ＩＤは当該記事の作成日時（正確には年月
日時分と他の数字との１３桁）からなる。従って、記事
ＩＤから当該記事の作成日時を知ることができる。デー
タ名は記事ＩＤに当該記事がアーカイブであることを示
す記号を付加したものである。

【００４８】例えば、「19980201a 」はその情報が１９
９８年２月１日のａ番目に作成された記事であることを
示す記事名である。そのデータ名は記事名にアーカイブ
ファイルであることを示す記号「arc 」を付加した「19
980201a.arc 」となる。

【００４９】次に、クライアントＣ１は、配信された最
新の記事データ一覧１０３’に基づいて、記事アーカイ
ブの入手要求（アーカイブ入手要求）をする（手順の
点線）。この入手要求も、クライアントＣ１のユーザに
よる指示入力なしで、クライアントＣ１によって自動的
に行われる。

【００５０】入手要求は、当該クライアントＣ１におい
て不足している記事、即ち、サーバＳＡにおいて新たに
記事として追加された記事について、行われる。このた
めに、クライアントＣ１は、図４（Ｃ）に示す最新の記
事データ一覧１０３’とその時点で自己が記憶している
記事データ一覧２０３’とを比較して、記事データ一覧
１０３’に存在して記事データ一覧２０３’には存在し
ない記事を求める。この求めた記事について、例えばデ
ータ名を用いた入手要求が行われる。

【００５１】入手要求を受信したサーバＳＡは、これに
応じて、当該サーバＳＡが現在公開している情報の記事
アーカイブ１０４の内指定されたものを、当該入手要求
の送信元であるクライアントＣ１に送信（配信）する
（手順の実線）。これにより、クライアントＣ１は閲
覧したい旨を指定した情報であってサーバＳＡから公開
される情報の記事アーカイブ１０４の配信を受ける。こ
の記事アーカイブ１０４がユーザに表示され、ユーザが
これを見ることになる。

【００５２】この応答においても、ユーザは、その情報
端末であるクライアントＣ１を何も操作しておらず、入
手要求が必要であることを意識することもない。これに
より、ユーザから見ると、外見上何もしないで、サーバ
ＳＡから自動的に記事が流れてきたように見える。従っ
て、ユーザは、最初の登録要求及び閲覧したい記事の選
択入力のみで、当該記事を閲覧することができる。

【００５３】また、クライアントＣ１は記事データ一覧
２０３’を更新する。即ち、クライアントＣ１は、予め
定められた有効期限の切れた古い記事の一覧情報を、記
事データ一覧２０３’から削除する。なお、このような
古い記事の一覧情報は、サーバＳＡにおける記事データ
一覧１０３’においても削除される。更に、クライアン
トＣ１は、前述のようにしてサーバＳＡから配信を受け
た記事アーカイブ１０４について、その記事データ一覧
情報を記事データ一覧２０３’に追加する。これによ
り、クライアントＣ１は自己の最新の記事データ一覧２
０３’を得る。

【００５４】図４（Ｄ）は、手順の実行以前にクライ
アントＣ１が持っていた記事データ一覧２０３’の一例
である。例えば、クライアントＣ１のユーザが１９９８
年２月１日以降全く当該情報端末を起動していなかった
とする。この時点でのクライアントＣ１の記事データ一
覧２０３’は、図４（Ｄ）に示すように、その日以前ま
でにサーバＳＡが公開した記事「19980128」及び「1998
0131」についてのみ、その記事データ一覧２０３’を持
っており、その日以降にサーバＳＡが公開した記事「19
980201a 」「19980201b 」及び「19980202」について
は、その記事データ一覧１０３’を持っていない。

【００５５】クライアントＣ１は、図４（Ｄ）に示す記
事データ一覧２０３’に、「19980201a 」「19980201b
」及び「19980202」についての記事データ一覧情報を
追加する。この結果、クライアントＣ１の記事データ一
覧２０３’は、図４（Ｃ）に示すようになる。

【００５６】なお、この手順は、図４（Ｃ）に示す記
事データ一覧１０３’に基づいて前述のように不足して
いるとされた記事について繰り返し実行される。例え
ば、前述の不足している記事「19980201a 」「19980201
b 」及び「19980202」について記事を入手し、既にもっ
ている「19980131」については記事を入手しないとす
る。この場合、まず、記事「19980201a 」を得るための
クライアントＣ１からの入手要求（手順の点線）と、
これに応じたサーバＳＡからの当該記事アーカイブ１０
４の配信（手順の実線）が行われ、次に、同様に、記
事「19980201b 」及び「19980202」を得るための入手要
求（手順の点線）と、これに応じた記事アーカイブ１
０４の配信（手順の実線）が繰り返される。

【００５７】また、手順乃至手順は、図４（Ｂ）に
示すチャネル一覧情報２０３においてクライアントＣ１
が閲覧を必要としたチャネルの各々について繰り返し実
行される。例えば、以上に述べた手順乃至手順がチ
ャネル一覧情報２０３のチャネル「社達（社内通達）」
について実行されたとする。この場合、次のチャネル
「ＸＸ新聞ニュース」について、同様に、手順乃至手
順が実行される。この場合も、手順は不足している
とされた記事について繰り返し実行される。更に、「天
気予報」以下の各チャネルについても同様に手順乃至
手順が繰り返し実行される。

【００５８】このように、外見上何もしないでサーバＳ
Ａから情報が配信されたように見えるが、一方、実際に
はクライアント２００からサーバ１００への配信要求等
が行われている。そこで、このような情報受配信システ
ムを疑似プッシュ型配信システムと言う。

【００５９】なお、本発明の情報受配信システムはプッ
シュ型配信を行うシステムであっても良い。プッシュ型
配信は、上位のサーバ１００が、下位のサーバ１００又
はクライアント２００からの情報の配信要求によって、
下位のサーバ１００又はクライアント２００に対して情
報を配信するシステムである。従って、プッシュ型配信
を行うシステムは、以上の疑似プッシュ型配信システム
において、図３（Ｂ）に示した手順乃至において、
点線で示したクライアント２００からのサーバ１００へ
の各種の要求を省略し、この要求なしでサーバ１００か
らクライアント２００への各種の情報の配信が実行され
るシステムである。

【００６０】このような疑似プッシュ型（又はプッシュ
型）の情報受配信システムにおいて、閲覧属性情報は、
図示はしないが、上述のように、「必須」「自由」又は
「不可」のいずれかとされる。「必須」は、当該情報の
受信（閲覧又は購読）を下位のサーバ１００又はクライ
アント２００に義務付ける。「自由」は、当該情報の受
信を下位のサーバ１００又はクライアント２００に委ね
る。「不可」は、当該情報の受信を下位のサーバ１００
又はクライアント２００に許さない。配信される各情報
毎に、「必須」「自由」又は「不可」のいずれかの配信
制御情報が、サーバ１００によって付加される。

【００６１】なお、閲覧属性情報は、図示はしないが、
閲覧属性情報の書き換えの可否を示す配信変更可否情報
と共に配信される。配信変更可否情報は、「変更可」又
は「変更不可」のいずれかである。「変更可」は、当該
閲覧属性情報の変更を下位のサーバ１００に許す。「変
更不可」は、当該閲覧属性情報の変更を下位のサーバ１
００に許さない。閲覧属性情報毎（従って、配信される
各情報毎）に配信変更可否情報がサーバ１００によって
付加される。

【００６２】閲覧属性情報及び配信変更可否情報は、基
本的には、各サーバ１００が自由に変更できるようにさ
れる。但し、配信変更可否情報が「変更可」の場合にの
み、閲覧属性情報は「必須」「自由」又は「不可」の間
で相互に変更を許される。配信変更可否情報の変更は、
当該情報が「変更不可」である場合には許されず、当該
情報が「変更可」である場合にのみ「変更不可」にのみ
変更することができる。クライアント２００は、末端に
位置するので、変更を認める意味がなく、従って、変更
の機能を持たない（許されない）。

【００６３】上位のサーバ１００は、そのチャネル情報
一覧１０３において各種の制御情報を設定してこれを下
位のサーバ１００又はクライアント２００に渡す。これ
により、上位のサーバ１００は、当該サーバ１００に接
続された下位のサーバ１００又はクライアント２００に
おける当該上位のサーバ１００の配信する情報について
の処理を、当該サーバ１００から制御する。即ち、上位
のサーバ１００は、当該上位のサーバ１００の配信する
情報の配信処理に関して、下位のサーバ１００又はクラ
イアント２００の制御プログラム１０１及び２０１を制
御する。

【００６４】上位のサーバ１００は、下位のサーバ１０
０又はクライアント２００に対して、閲覧属性情報及び
配信変更可否情報を配信する。この配信は、前述のよう
に、手順及び手順の実行による当該情報の書き込ま
れたチャネル一覧情報１０３の配信によって行われる。
下位のサーバ１００及びクライアント２００は、閲覧属
性情報に従って上位のサーバ１００の配信した情報の受
信を行う。例えば、上位のサーバ１００は、閲覧属性情
報を「必須」と設定することにより、下位のサーバ１０
０又はクライアント２００に対して、当該閲覧属性情報
を有する情報を必ず受信させることができる。

【００６５】このシステムは擬似プッシュ型（又はプッ
シュ型）であるから、実際には、前述のように、手順
、即ち、閲覧属性情報に従って下位のサーバ１００か
ら上位のサーバ１００への配信要求が必ず実行されるこ
とによって、当該情報である記事アーカイブ１０４が配
信される。

【００６６】一方、上位のサーバ１００とクライアント
２００との間の中間サーバ１００は、上位のサーバ１０
０により変更の許されている各種の制御情報を書き換
え、かつ、これをより下位のサーバ１００又はクライア
ント２００に配信する。これにより、当該中間サーバ１
００も、より下位のサーバ１００又はクライアント２０
０の各種のモードを設定し管理することが可能である。
このように、本発明の情報受配信システムでは、記事ア
ーカイブ１０４が多くのクライアント２００に配信され
るので、配信されるデータの個数とデータ量が膨大なも
のになる。従って、データの個数を減らして通信の回数
を減らし、データ量を圧縮して通信時間を短縮し、結果
として伝送効率を向上することが重要になる。

【００６７】そこで、以上のような擬似プッシュ型（又
はプッシュ型）配信システムにおいて、本発明に従っ
て、クライアント２００に配信する情報（記事）及びそ
の記事一覧１０３’の配信処理が行われる。

【００６８】図５は本発明が適用される情報受配信シス
テムの構成を示す。このシステムでは、サーバ１００が
クライアント２００に対して記事及びその記事一覧１０
３’のアーカイブの配信処理を行い、クライアント２０
０が当該配信されたアーカイブから記事を得る処理を行
う。

【００６９】なお、以下の説明はサーバ１００とクライ
アント２００との間での記事の更新処理及び削除処理に
ついてものであるが、サーバ１００と更に下位のサーバ
１００との間でもほぼ同様の関係が成立する。即ち、こ
の説明において、クライアント２００を下位のサーバ１
００と置き換えても良い。

【００７０】図５に示すように、サーバ１００は、記事
をサーバ保持部３に登録する記事登録部１、記事をクラ
イアント２００に配信する記事配信部２、記事登録部１
により登録された記事を保持するサーバ保持部３、記事
制御部５により作成された記事一覧１０３’を含む各種
の制御情報を保持する管理情報保持部４、記事一覧１０
３’を含む各種の制御情報を作成する記事制御部５を備
える。

【００７１】一方、クライアント２００は、各々、情報
を閲覧させるための情報閲覧部１１、クライアント２０
０において登録された記事を保持するクライアント保持
部１６、配信された記事一覧１０３’に従ってクライア
ント２００における記事の復元処理及び登録処理を行う
記事管理部１７を備える。

【００７２】記事登録部１は、クライアント２００に対
して配信すべき記事を登録する。記事配信者は、サーバ
１００の入力装置（図示せず）から、当該サーバ１００
の記事登録部１に対して、自己の提供したいと思ってい
る記事（例えば、記事Ａ及びＢ）を入力する。記事登録
部１は当該入力された記事をサーバ保持部３に登録す
る。即ち、記事登録部１は、登録された記事について、
図４に示すように、記事ＩＤを与え、当該記事の内容を
アーカイブしてアーカイブファイルを作成し、これにデ
ータ名を与える。

【００７３】この時、このアーカイブファイルが本発明
に従って作成される。即ち、記事登録部１は、複数の記
事Ａ及びＢを、共有アーカイブ３００と固有アーカイブ
４００とに分割して登録する。共有アーカイブ３００
は、記事Ａ及びＢの共有データ「共有」をまとめてアー
カイブし圧縮した１個（複数であっても良い）のアーカ
イブファイルである。固有アーカイブ４００は、記事Ａ
及びＢの固有データ「固有Ａ」及び「固有Ｂ」を、所定
の条件に従って、１つの（又は２以上の）グループにま
とめてアーカイブし圧縮した１つの（又は２以上の）ア
ーカイブファイルである。

【００７４】なお、共有アーカイブ３００及び固有アー
カイブ４００については、データ圧縮しても良くしなく
ても良い。データ圧縮することにより、更に送信すべき
データ量を減らすことができるので、データ圧縮するこ
とが望ましい。データ圧縮とアーカイブとを併用するこ
とが、更にデータ量を減らすために有効である。

【００７５】共有データ「共有」は、図１８に示すよう
に、双方の記事に共有のロゴマーク、ポスト印のアイコ
ン等であり、文字データ、イメージデータ、音声データ
のいずれであっても良い。共有アーカイブ３００にアー
カイブされる共有データは、１個でも複数でも良い。固
有データ「固有Ａ」及び「固有Ｂ」は、同様に図１８に
示すように、実際の記事の内容であり、共有データと同
様に、文字データ、イメージデータ、音声データのいず
れであっても良い。固有アーカイブ４００にアーカイブ
される固有データも、１個でも複数でも良い。

【００７６】共有アーカイブ３００は、通常、複数の固
有アーカイブ４００に対して１個である。固有アーカイ
ブ４００の数には、原則として制限がなく、１個でも２
個以上でも良い。共有アーカイブ３００の数を必要に応
じて複数としても良い。

【００７７】固有アーカイブ４００は、例えば、同時に
配信要求された複数の記事についての記事アーカイブ１
０４を１個のアーカイブファイルとする。又は、ある１
日に作成された複数の記事についての記事アーカイブ１
０４を１個のアーカイブファイルとする。従って、固有
データをグループにまとめる際の条件は、当該記事の作
成日時又は配信要求の日時とすることが望ましい。

【００７８】また、共有アーカイブ３００と固有アーカ
イブ４００についての記事一覧１０３’が本発明に従っ
て作成される。即ち、登録された情報（記事Ａ及びＢ）
について、記事制御部５が、当該記事の属するチャネル
のチャネル一覧情報１０３及び記事一覧１０３’に前述
の所定の事項を登録してこれらを作成し管理情報保持部
４に保持する。この記事一覧１０３’は、１個の共有ア
ーカイブ３００についての管理情報からなる共有データ
一覧と１つの（又は２以上の）固有アーカイブ４００に
ついての管理情報からなる記事データ一覧とからなる。

【００７９】記事配信部２は、クライアント２００に対
して、サーバ保持部３に登録された各種の記事（記事Ａ
及びＢ）及び管理情報保持部４に保持されたチャネル情
報一覧１０３と記事一覧１０３’を配信する。

【００８０】記事管理部１７は、記事一覧１０３’に基
づいて、サーバ１００に対して、必要な共有アーカイブ
３００及び固有アーカイブ４００の配信要求を行い、サ
ーバ１００から配信される共有アーカイブ３００及び固
有アーカイブ４００を受信し、これらから複数の記事
（記事Ａ及びＢ）を得る。

【００８１】記事配信部２は、登録された記事について
情報の配信を行うため、クライアント２００の記事管理
部１７との間で、図３（Ｂ）に示す手順乃至を実行
する。記事管理部１７は、サーバ１００から情報の配信
を受けるために、図３（Ｂ）に示す手順乃至におい
て点線で表される各種のサーバ１００に対する要求を実
行し、サーバ１００から配信された情報をユーザに閲覧
させる。記事配信部２は、当該各種の要求に応じて、手
順乃至において実線で表すように、クライアント２
００にチャネル情報一覧１０３、記事一覧１０３’及び
記事アーカイブ１０４等の情報を配信する。

【００８２】即ち、図３（Ａ）のユーザリスト１０１に
登録されたクライアント２００の記事管理部１７から接
続要求があると（図３（Ｂ）の手順の点線）、サーバ
１００の記事配信部２はチャネル一覧情報１０３を当該
記事管理部１７に配信する（手順の実線）。更に、記
事管理部１７から一覧要求があると（手順の点線）、
記事配信部２は記事一覧１０３’を当該記事管理部１７
に配信する（手順の実線）。この時、共有アーカイブ
３００と固有アーカイブ４００についての記事一覧１０
３’が配信される。更に、記事管理部１７から入手要求
があると（手順の点線）、記事配信部２は当該入手要
求があった記事アーカイブ１０４（共有アーカイブ３０
０及び／又は固有アーカイブ４００）を当該記事管理部
１７に配信する（手順の実線）。この時、当該要求さ
れた共有アーカイブ３００及び／又は固有アーカイブ４
００が配信される。記事管理部１７はこの記事アーカイ
ブ１０４から記事を受信し復元してクライアント保持部
１６に保持する。

【００８３】記事管理部１７は、サーバ１００から配信
された記事アーカイブ１０４について、記事一覧１０
３’（又は記事一覧２０３’）に基づいて、所定の処理
を行う。即ち、記事管理部１７は、配信された記事一覧
１０３’内に共有アーカイブ３００と固有アーカイブ４
００とがあるので、当該共有アーカイブ３００が固有ア
ーカイブ４００に共有のデータであることを知る。そこ
で、記事管理部１７は、共有アーカイブ３００から復元
した共有データ「共有」及び固有アーカイブ４００から
復元した複数の固有データ「固有Ａ」「固有Ｂ」の各々
を結合して、「共有」と「固有Ａ」とからなる記事Ａ及
び「共有」と「固有Ｂ」とからなる記事Ｂを作成し、ク
ライアント保持部１６に新たに登録する。なお、配信さ
れた記事一覧１０３’は、クライアント２００において
その管理情報である記事一覧２０３’として保持され
る。

【００８４】情報閲覧部１１は、ユーザによる閲覧指示
（表示指示）の入力があると、これに応じて、クライア
ント保持部１６に保持されている当該情報を表示する。
表示される情報は、クライアント保持部１６に保持され
ている情報である。従って、クライアント２００のユー
ザは、上述のような記事の配信処理については何ら意識
することがない。なお、前述のように、プッシュ型（及
び疑似プッシュ型）配信においては、新たな記事の登録
処理についてもユーザが意識する必要はない。

【００８５】以上の配信のあった後、記事配信者が自己
の提供した記事（例えば、記事Ａ及びＢ）を更新したい
と考える場合がある。この場合、記事配信者が更新され
た記事（例えば、記事Ａ）を入力すると、前述の場合と
同様に、アーカイブファイル等の作成が行われる。即
ち、この変更入力に応じて、記事登録部１によって記事
Ａの共有アーカイブ３００又は固有アーカイブ４００の
いずれかが変更される。変更すべき部分は、先の記事Ａ
と新たな記事Ａとの比較によって、記事登録部１が判断
する。

【００８６】記事制御部５は、共有アーカイブ３００又
は固有アーカイブ４００についての管理情報を、この変
更に基づいた新たな管理情報に変更した新たな記事一覧
１０３’を作成する。この新たな記事一覧１０３’は記
事配信部２によりクライアント２００に配信される。こ
れを受信したら、記事管理部１７が、先に保持していた
記事一覧２０３’と新たな記事一覧１０３’とを比較し
た結果に基づいて、サーバ１００に対して、変更された
共有アーカイブ３００又は固有アーカイブ４００の配信
要求を行う。

【００８７】次に、図６乃至図８に従って、クライアン
ト２００における記事の登録処理、更新処理及び削除処
理について説明する。まず、図４（Ｃ）及び（Ｄ）に示
したと同様の記事一覧１０３’及び２０３’であって、
この説明のための一例を、再度図６（Ａ）及び（Ｂ）に
示す。なお、この記事一覧１０３’及び２０３’は説明
のためのものであって、本発明に従って配信される記事
一覧１０３’及び２０３’とは異なる。

【００８８】「19980127.arc」は記事一覧２０３’には
存在するが、記事一覧１０３’には存在しない。従っ
て、アーカイブファイル「19980127.arc」に対応する記
事はクライアント２００には存在するが、当該アーカイ
ブファイル「19980127.arc」はサーバ１００には存在し
ない。これは、古い記事は有効期限が切れたものとし
て、サーバ１００において削除されるためである。この
場合、クライアント２００は対応する記事を削除する必
要がある。

【００８９】また、逆に、「19980201.arc」及び「1998
0202.arc」は記事一覧１０３’には存在するが、記事一
覧２０３’には存在しない。従って、アーカイブファイ
ル「19980201.arc」及び「19980202.arc」はサーバ１０
０には存在するが、クライアント２００には存在しな
い。これは、これらが新しく追加された記事であるため
である。この場合、クライアント２００は対応する記事
をサーバ１００から入力する必要がある。

【００９０】このような記事一覧１０３’の配信は前述
の手順の実線の処理において行われ、新しい記事のア
ーカイブファイル「19980201.arc」及び「19980202.ar
c」の配信は前述の手順の実線の処理において行われ
る。この手順及びの実線の処理が、本発明に従っ
て、以下のように行われる。

【００９１】前述のようにして、手順までを実行した
後、クライアント２００の記事管理部１７が、サーバ１
００の記事配信部２に対して、手順の記事一覧のため
の一覧要求を行う。

【００９２】これに応じて、サーバ１００の記事配信部
２が、１個の共有アーカイブ３００についての管理情報
からなる共有データ一覧と１（又は２以上）の固有アー
カイブ４００についての管理情報からなる記事データ一
覧とからなる記事一覧１０３’を配信する。この配信さ
れた記事一覧１０３’の一例を図７（Ａ）に示す。

【００９３】図７（Ａ）において、記事一覧１０３’の
共有データ一覧は、共有データのアーカイブファイル
「19980128cmn.arc 」がサーバ１００のサーバ保持部３
に存在することを示す。「cmn 」は当該ファイルが共有
データについてのものであることを示す。また、記事一
覧１０３’の固有データ一覧は、４個の固有データのア
ーカイブファイルがサーバ１００のサーバ保持部３に存
在することを示す。

【００９４】一方、クライアント２００は、先にサーバ
１００から配信された記事一覧１０３を自己の管理テー
ブルである記事一覧２０３’として保持している。この
保持された記事一覧２０３’の一例を図７（Ｂ）に示
す。

【００９５】図７（Ｂ）において、記事一覧２０３’の
共有データ一覧は、共有データのアーカイブファイル
「19980128cmn.arc 」がクライアント２００のクライア
ント保持部１６に存在することを示す。また、記事一覧
２０３’の固有データ一覧は、３個の固有データのアー
カイブファイルがクライアント２００のクライアント保
持部１６に存在することを示す。

【００９６】クライアント２００の記事管理部１７は、
記事一覧１０３’を受信して保持し、保持した記事一覧
１０３’に基づいて、サーバ１００に対して、必要な共
有アーカイブ３００及び固有アーカイブ４００の配信要
求を行う。

【００９７】即ち、記事管理部１７は、記事一覧１０
３’と記事一覧２０３’とを比較し、この比較結果に基
づいて、サーバ１００に対して、変更された固有アーカ
イブ４００の配信要求を行う。ここで、図７（Ａ）と図
７（Ｂ）とを対比すると判るように、「19980127.arc」
は記事一覧１０３’において削除され、「19980201.ar
c」及び「19980202.arc」は記事一覧１０３’において
追加されている。即ち、変更されている。一方、共有デ
ータのアーカイブファイル「19980128cmn.arc 」を含め
て、他のデータ「19980128.arc」及び「19980131.arc」
には変更がないことが判る。そこで、記事管理部１７
は、記事一覧１０３’において追加（即ち、変更）され
ている「19980201.arc」及び「19980202.arc」につい
て、その配信要求を行う。

【００９８】この配信要求に応じて、サーバ１００は、
クライアント２００に対して、複数の記事「19980201.a
rc」及び「19980202.arc」の固有データを１のグループ
にまとめてアーカイブし圧縮した固有アーカイブ４００
を配信する。従って、この場合、固有データをグループ
にまとめる条件は、同時に配信要求があったことであ
る。

【００９９】クライアント２００の記事管理部１７は、
サーバ１００から配信される共有アーカイブ３００又は
固有アーカイブ４００を受信し、これらから複数の記事
（「19980201.arc」及び「19980202.arc」を各々の固有
データとする２個の記事）を得る。即ち、クライアント
２００が保持していた共有データのアーカイブファイル
「19980128cmn.arc 」の復元データと「19980201.arc」
及び「19980202.arc」を各々の復元データを結合して、
前記２個の記事を得る。

【０１００】このように、サーバ１００の記事配信部１
は、固有アーカイブ４００のいずれかが変更された時
に、当該固有アーカイブ４００についての管理情報をこ
の変更に基づいた新たな管理情報に変更した新たな記事
一覧１０３’を、クライアント２００に配信する。そし
て、クライアント２００の記事管理部１７は、サーバ１
００から配信される固有アーカイブ４００を受信し、共
有アーカイブ３００とこの新たに配信された固有アーカ
イブ４００とから複数の記事を得る。

【０１０１】以上は、図８に示すように、共有アーカイ
ブ３００が変更された場合でも同様である。即ち、サー
バ１００の記事配信部１は、共有アーカイブ３００が変
更された時に、当該共有アーカイブ３００についての管
理情報をこの変更に基づいた新たな管理情報に変更した
新たな記事一覧１０３’を配信する。そして、クライア
ント２００の記事管理部１７は、サーバ１００から配信
された新たな共有アーカイブ３００又は固有アーカイブ
４００を受信し、共有アーカイブ３００と固有アーカイ
ブ４００とから前記複数の記事を得る。

【０１０２】図８（Ａ）において、記事一覧１０３’の
共有データ一覧は、共有データのアーカイブファイル
「19980202cmn.arc 」がサーバ１００のサーバ保持部３
に存在することを示す。一方、図８（Ｂ）において、記
事一覧２０３’の共有データ一覧は、共有データのアー
カイブファイル「19980128cmn.arc 」がクライアント２
００のクライアント保持部１６に存在することを示す。
なお、他の部分については、図７と同様である。従っ
て、「19980128cmn.arc 」は古い共有データのアーカイ
ブファイルであって、サーバ１００においては既に削除
されている。このため、クライアント２００は、これに
代えて「19980202cmn.arc 」なる新しい共有データのア
ーカイブファイルを入手する必要がある。

【０１０３】そこで、記事管理部１７は、サーバ１００
に対して、図７の場合の配信要求（固有アーカイブ４０
０の配信要求）に加えて、共有アーカイブ３００の配信
要求を行う。

【０１０４】即ち、記事管理部１７は、記事一覧１０
３’と記事一覧２０３’とを比較し、この比較結果に基
づいて、サーバ１００に対して、変更された固有アーカ
イブ４００の配信要求を行う。ここで、共有データのア
ーカイブファイル「19980128cmn.arc 」が変更されてい
るので、記事管理部１７は、その配信要求を行う。

【０１０５】この配信要求に応じて、サーバ１００は、
クライアント２００に対して、共有データのアーカイブ
ファイル「19980128cmn.arc 」である共有アーカイブ３
００を配信する。なお、共有データが複数であれば、複
数の共有データがまとめてアーカイブされる。従って、
この場合、共有データをグループにまとめる条件は同時
に配信要求があったことである。

【０１０６】クライアント２００の記事管理部１７は、
前述の場合とどうようにして、サーバ１００から配信さ
れる共有アーカイブ３００を受信し、共有アーカイブ３
００と固有アーカイブ４００とから複数の記事を得る。
なお、この場合、固有データについても変更されている
ので、得られる記事の内容は、共有データ及び固有デー
タの双方が新しいものとなる。

【０１０７】

【実施例】次に、実施例により、各種の方式で同一のデ
ータを送信する場合を比較して、本発明による情報受配
信システム及び情報受配信方法の有する効果について、
具体的に証明する。（データの要素の説明）図９乃至図１１は以下の説明に
用いる各日の文書を構成する要素の例を示す。図９乃至
図１１は各方式による情報の伝送効率の比較に用いるデ
ータの例を示し、これらで１つの図をなすものである。
図９乃至図１１に示す８個の文書Ａ乃至Ｈをサーバ１０
０からクライアント２００に対して配信するとする。こ
の場合における、従来知られていた前述の方式Ａ乃至方
式Ｃの各々による伝送効率と本発明の伝送効率との間で
の比較を行う。

【０１０８】８個の文書Ａ乃至Ｈは、共有データとして
ロゴデータ、飾り罫線データ及びアイコンデータを必要
とし、これらを含む。これらは全てイメージデータであ
り、そのデータ量が多い。文書Ａ乃至Ｈは、各々、この
共有データ以外に固有の文章である文章データを含む。
例えば、文書Ａの文章データを「Ａについて」と表すこ
とにする。更に、文書Ｆ及びＨは、共有データ及び文章
データ以外に、イメージデータである写真データを含
む。従って、写真データを含まない文書Ａ等は４個のデ
ータを包含し、写真データを含む文書Ｆ等は５個のデー
タを包含する。データ圧縮しない場合の各々のデータの
大きさを「元」として図示し、データ圧縮した場合の各
々のデータの大きさを「圧縮」として図示している。な
お、データの大きさの単位はＫＢ（キロバイト）であ
る。

【０１０９】例えば、文書Ａは２月１日に作成され、４
個のデータを包含し、３ＫＢに圧縮できる５ＫＢの文章
データ「Ａについて」、７ＫＢに圧縮できる１０ＫＢの
ロゴデータ、３ＫＢに圧縮できる５ＫＢの飾り罫線デー
タ及び１ＫＢに圧縮できる２ＫＢのアイコンデータを含
む。

【０１１０】以下の説明において、アーカイブすること
により、１ＫＢのアーカイブ情報がヘッダとして付加さ
れることとする。また、１個のデータをネットワークに
流すために、１ＫＢのパケットヘッダが必要であるとす
る。また、伝送効率の計算には、個々の要素を単純に積
算した時の圧縮後のデータ量が全体で５２ＫＢであるの
で、これを用いることとする。なお、同様に、個々の要
素を単純に積算した時の元のデータ量は全体で７３ＫＢ
である。（第１の比較例）第１の比較例は図９乃至図１１に示し
たデータを個々の要素毎に配信する例である。図１２は
第１の比較例説明図である。これは、前述の方式Ａであ
り、コンテンツ（文書）毎にアーカイブすることなく、
例えば前述の個々の要素毎に配信する方式である。従っ
て、この方式Ａによれば、共有データについては二重に
配信せずに済み、データの個数は１３個である。また、
個々の要素毎にデータ圧縮することも可能であり、全体
でのデータ量（バイト数）は５２ＫＢである。なお、ア
ーカイブされないので、アーカイブヘッダは存在しな
い。

【０１１１】しかし、アーカイブされていないので、ネ
ットワークに流れるデータの個数が多くなり、パケット
数が軽減されない。即ち、データの個数分のパケットを
必要とするので、前述の５２ＫＢの他に１３ＫＢのパケ
ットヘッダが送信され、全体で６５ＫＢとなる。この結
果、伝送効率はこの６５ＫＢを前述の圧縮後のデータ量
５２ＫＢで割って、６５ＫＢ／５２ＫＢ＝１．２５０と
なる。まとめると、受信パケット数１３個（１３ＫＢ）受信バイト数５２ＫＢ伝送効率１．２５０である。（第２の比較例）第２の比較例は、図９乃至図１１に示
したデータを各文書毎にアーカイブして配信する例であ
る。図１３乃至図１５は第２の比較例説明図であり、こ
れらで１つの図をなすものである。これは、前述の方式
Ｂであり、コンテンツ毎に必要なデータを揃えこれらを
アーカイブ（圧縮）して配信する方式である。この方式
Ｂによれば、アーカイブ（及び圧縮）されているのでネ
ットワーク負荷は軽減される。即ち、文書毎にアーカイ
ブするのでパケットの数は８個であり（８ＫＢのパケッ
トヘッダが送信され）、データも圧縮される。なお、文
書Ｆ及びＨについては、文章データと共に、当該文書で
使用する図、表、写真等もアーカイブされる。

【０１１２】しかし、アーカイブされているので、３個
の共有データの個々の要素はｎ重に配信されてしまう。
ここでは、データの数が８個であるので、ｎ＝８であり
（８重に配信され）、極めて無駄が多い。この結果、配
信されるデータ量は８個のアーカイブヘッダを加えて１
３６ＫＢであり、これにパケットヘッダの８ＫＢを加え
て１４４ＫＢとなる。この結果、伝送効率は１４４ＫＢ
／５２ＫＢ＝２．７６９となる。まとめると、受信パケット数８個（８ＫＢ）受信バイト数１３６ＫＢ伝送効率２．７６９である。（第３の比較例）第３の比較例は、図９乃至図１１に示
したデータを各日毎にアーカイブして配信する例であ
る。図１６は第３の比較例説明図である。これは、前述
の方式Ｃであり、コンテンツ毎にアーカイブすることな
く、あるタイミングで全てのデータをまとめてアーカイ
ブして配信する方式である。この方式Ｃによれば、共有
データについては当該アーカイブに１個づつでよいの
で、同一アーカイブ内のデータについて見ると二重に配
信せずに済み、アーカイブ（及び圧縮）されているので
ネットワーク負荷も軽減される。しかし、次のタイミン
グでデータを配信する際に共有データについては再送す
る必要がある。これは、先に送信されたコンテンツがク
ライアントにおいて廃棄されていると、次に送信された
コンテンツがエラーとなるためである。従って、共有デ
ータについては、結果として必ず二重配信になる。

【０１１３】例えば、文書Ａ乃至文書Ｅが２月１日に作
成され、文書Ｆ乃至文書Ｈが２月２日に作成されたとす
る。この場合、文書Ａ乃至文書Ｅが２月１日にまとめて
アーカイブされて送信され、文書Ｆ乃至文書Ｈが２月２
日にまとめてアーカイブされて送信される。なお、文書
Ｆ及びＨについては、文章データと共に、当該文書で使
用する図、表、写真等もアーカイブされる。従って、パ
ケットの数は２個であり、２ＫＢのパケットヘッダが送
信される。共有データについては二重配信になるので、
配信されるデータ量は２ＫＢのアーカイブヘッダを加え
て６５ＫＢであり、これにパケットヘッダの２ＫＢを加
えて６７ＫＢとなる。この結果、伝送効率は６７ＫＢ／
５２ＫＢ＝１．２８８となる。まとめると、受信パケット数２個（２ＫＢ）受信バイト数６５ＫＢ伝送効率１．２８８である。（本発明による例）本発明による例は、図９乃至図１１
に示したデータを各日毎にアーカイブした２個の固有ア
ーカイブ４００と１個の共有アーカイブ３００との３個
を配信する例である。図１７は本発明による例の説明図
である。第３の比較例（方式Ｃ）との比較のために、文
書Ａ乃至文書Ｅが２月１日に作成され、文書Ｆ乃至文書
Ｈが２月２日に作成されたとする。また、共有データは
２月１日と２月２日とで変更されていないものとする。

【０１１４】この場合、３個の共有データは、文章デー
タとは別に、２月１日にまとめてアーカイブされて送信
される。共有データは変更されないので、２月１日に１
回送信されるのみであり、２月２日には配信されない。
また、文書Ａ乃至文書Ｅの文章データのみが２月１日に
まとめてアーカイブされて送信され、文書Ｆ乃至文書Ｈ
の文章データのみが２月２日にまとめてアーカイブされ
て送信される。

【０１１５】この結果、パケットの数は３個であり、３
ＫＢのパケットヘッダが送信される。配信されるデータ
量は３ＫＢのアーカイブヘッダを加えて５５ＫＢであ
り、これにパケットヘッダの３ＫＢを加えて５８ＫＢと
なる。この結果、伝送効率は５８ＫＢ／５２ＫＢ＝１．
１１５となる。まとめると、受信パケット数３個（３ＫＢ）受信バイト数５５ＫＢ伝送効率１．１１５である。

【０１１６】以上の結果を比較すると、データの個数の
点では方式Ｃ（２個）と本発明（３個）とが他よりかな
り優れており、両者に大差はない。データの量の点で
は、方式Ａ（５２ＫＢ）と本発明（５５ＫＢ）とが他よ
りかなり優れており、両者に大差はない。伝送効率の点
では、本発明（１．１１５）が他（方式Ａが１．２５
０、方式Ｃが１．２８８）よりかなり優れている。

【０１１７】以上から、本発明の情報受配信システム
は、データの個数、データの量、伝送効率のいずれの点
でも優れていることが判る。本発明は、図９乃至図１１
に示したデータの数が多くなる程、有利である。即ち、
データの数が多くなる程、データの個数の点での方式Ｃ
と本発明との差は全体のデータの個数に比べて無視でき
る程に小さくなり、データの量の点での方式Ａと本発明
との差は全体のデータの量に比べて無視できる程に小さ
くなり、一方、伝送効率の点での本発明と他の方式との
差は小さくなるか同一である。

【０１１８】以上、本発明を情報受配信システムとして
説明したが、本発明は当該情報受配信システムを実現す
るプログラムがプログラム記憶媒体に記憶されたものを
も含むものである。即ち、当該プログラムがフレキシブ
ルディスクやＣＤ−ＲＯＭなどの記憶媒体に記述されて
いてもよく、またダウンロードによってハードディスク
などの記憶媒体にロードされてもよく、いずれも、本願
発明の技術的範囲に属するものと解すべきである。

【０１１９】

【発明の効果】以上説明したように、本発明によれば、
情報受配信システムにおいて、共有データをまとめてア
ーカイブし圧縮した共有アーカイブと複数の固有データ
をまとめてアーカイブし圧縮した固有アーカイブとを用
いて配信を行うことにより、共有データについてはこれ
を固有データの配信の都度に配信せずに済み、アーカイ
ブと圧縮によりデータの個数及びデータ量を減らすこと
ができ、また、固有データについてはアーカイブと圧縮
によりデータの個数及びデータ量を減らすことができる
ので、全体として、データの個数及びデータ量を減らし
て伝送効率を向上することができる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】情報受配信システム構成図である。

【図３】情報受配信システム説明図である。

【図４】情報受配信説明図である。

【図５】情報受配信システム構成図である。

【図６】情報受配信説明図である。

【図７】情報受配信説明図である。

【図８】情報受配信説明図である。

【図９】実施例説明図である。

【図１０】実施例説明図である。

【図１１】実施例説明図である。

【図１２】第１の比較例説明図である。

【図１３】第２の比較例説明図である。

【図１４】第２の比較例説明図である。

【図１５】第２の比較例説明図である。

【図１６】第３の比較例説明図である。

【図１７】本発明による例の説明図である。

【図１８】共有データ説明図である。

【符号の説明】

１記事登録部２記事配信部３サーバ保持部４登録制御情報５登録制御部１１情報閲覧部１６クライアント保持部１７記事管理部１００サーバ２００クライアント

Claims

【特許請求の範囲】

【請求項１】情報を配信するサーバと前記サーバに接
続され前記サーバから配信される情報を受信する複数の
クライアントとの間における情報の受配信方法におい
て、前記サーバが、前記クライアントに対して配信すべき情報である複数の
記事に共有の部分である１又は２以上の共有データをま
とめて、これをアーカイブした１又は２以上の共有アー
カイブを配信し、前記複数の記事の各々に固有の部分である複数の固有デ
ータを所定の条件に従って１又は２以上のグループにま
とめて、これらをグループ毎にアーカイブした１又は２
以上の固有アーカイブを配信し、前記クライアントの各々が、前記サーバから配信される前記１又は２以上の共有アー
カイブを受信し、前記サーバから配信される前記１又は２以上の固有アー
カイブを受信し、前記１又は２以上の共有アーカイブと前記１又は２以上
の固有アーカイブとから前記複数の記事を得ることを特
徴とする情報受配信方法。
【請求項２】前記サーバが、前記１又は２以上の共有
アーカイブについての管理情報からなる共有データ一覧
と前記１又は２以上の固有アーカイブについての管理情
報からなる記事データ一覧とからなる記事一覧を配信
し、前記クライアントの各々が、前記記事一覧受信して保持し、前記保持した記事一覧に基づいて、前記サーバに対し
て、必要な前記共有アーカイブ及び固有アーカイブの配
信要求を行うことを特徴とする請求項１に記載の情報受
配信方法。
【請求項３】前記サーバが、前記固有アーカイブのい
ずれかが変更された時に、当該固有アーカイブについて
の管理情報をこの変更に基づいた新たな管理情報に変更
した新たな記事一覧を配信し、前記クライアントの各々が、前記新たな記事一覧受信し、先に保持していた前記記事一覧と前記新たな記事一覧と
を比較し、この比較結果に基づいて、前記サーバに対して、前記変
更された固有アーカイブの配信要求を行うことを特徴と
する請求項２に記載の情報受配信方法。
【請求項４】前記サーバが、前記共有アーカイブが変
更された時に、当該共有アーカイブについての管理情報
をこの変更に基づいた新たな管理情報に変更した新たな
記事一覧を配信し、前記クライアントの各々が、前記新たな記事一覧受信し、先に保持していた前記記事一覧と前記新たな記事一覧と
を比較し、この比較結果に基づいて、前記サーバに対して、前記変
更された共有アーカイブの配信要求を行うことを特徴と
する請求項２に記載の情報受配信方法。
【請求項５】前記サーバは多段の構成を有する複数の
サーバからなり、前記クライアントは前記複数のサーバのいずれかに接続
され、前記クライアントは、前記上位のサーバから直接、又
は、前記上位のサーバに接続された前記複数のサーバの
内の下位のサーバを介して、前記複数のサーバの内の上
位のサーバから配信された情報を受信し、予め登録された前記下位のサーバ又はクライアントが、
前記上位のサーバに対して前記配信要求を実行するべき
旨の指示入力なしで、自動的に前記配信要求を行い、前記上位のサーバが、前記下位のサーバ又はクライアン
トに対して、これらからの前記配信要求があった時に、
情報を配信するプッシュ型配信を行うことを特徴とする
請求項２に記載の情報受配信方法。
【請求項６】前記サーバは多段の構成を有する複数の
サーバからなり、前記クライアントは前記複数のサーバのいずれかに接続
され、前記クライアントは、前記上位のサーバから直接、又
は、前記上位のサーバに接続された前記複数のサーバの
内の下位のサーバを介して、前記複数のサーバの内の上
位のサーバから配信された情報を受信し、前記上位のサーバが、予め登録された前記下位のサーバ
又はクライアントからの前記配信要求によって、これら
に対して情報を配信するプッシュ型配信を行うことを特
徴とする請求項１に記載の情報受配信方法。
【請求項７】サーバと前記サーバに接続された複数の
クライアントとからなり、前記サーバから配信される情
報を前記クライアントが受信する情報受配信システムに
おいて、前記サーバが、前記クライアントに対して配信すべき情報である複数の
記事を、当該複数の記事に共有の部分である１又は２以
上の共有データをまとめてアーカイブした１又は２以上
の共有アーカイブと、前記複数の記事の各々に固有の部
分である複数の固有データを所定の条件に従って１又は
２以上のグループにまとめてアーカイブした１又は２以
上の固有アーカイブとに分割して登録する記事登録部
と、前記クライアントに対して前記登録された記事を配信す
る記事配信部とを備え、前記クライアントの各々が、前記サーバから配信される前記１又は２以上の共有アー
カイブ及び１又は２以上の固有アーカイブを受信し、こ
れらから前記複数の記事を得る記事管理部を備えること
を特徴とする情報受配信システム。
【請求項８】前記サーバが、更に、前記１又は２以上
の共有アーカイブについての管理情報からなる共有デー
タ一覧と前記１又は２以上の固有アーカイブについての
管理情報からなる記事データ一覧とからなる記事一覧を
作成する記事制御部を備え、前記記事配信部が、前記クライアントに対して前記記事
一覧を配信し、前記記事管理部が、前記記事一覧に基づいて、前記サー
バに対して、必要な前記共有アーカイブ及び固有アーカ
イブの配信要求を行うことを特徴とする請求項７に記載
の情報受配信システム。
【請求項９】前記記事制御部が、前記固有アーカイブ
及び共有アーカイブのいずれかが変更された時に、当該
固有アーカイブ又は共有アーカイブについての管理情報
をこの変更に基づいた新たな管理情報に変更した新たな
記事一覧を作成し、前記記事配信部が、前記新たな記事一覧を配信し、前記記事管理部が、先に保持していた前記記事一覧と前
記新たな記事一覧とを比較した結果に基づいて、前記サ
ーバに対して、前記変更された固有アーカイブ又は共有
アーカイブの配信要求を行うことを特徴とする請求項８
に記載の情報受配信システム。
【請求項１０】当該情報受配信システムにおける前記
サーバは多段の構成を有する複数のサーバからなり、前記クライアントは前記複数のサーバのいずれかに接続
され、前記クライアントは、前記上位のサーバから直接、又
は、前記上位のサーバに接続された前記複数のサーバの
内の下位のサーバを介して、前記複数のサーバの内の上
位のサーバから配信された情報を受信し、予め登録された前記下位のサーバ又はクライアントが前
記上位のサーバに対して前記配信要求を実行するべき旨
の指示入力なしで自動的に前記配信要求を行い、前記下
位のサーバ又はクライアントからの前記配信要求があっ
た時に、前記上位のサーバが情報を配信するプッシュ型
配信を行うことを特徴とする請求項８に記載の情報受配
信システム。
【請求項１１】当該情報受配信システムにおける前記
サーバは多段の構成を有する複数のサーバからなり、前記クライアントは前記複数のサーバのいずれかに接続
され、前記クライアントは、前記上位のサーバから直接、又
は、前記上位のサーバに接続された前記複数のサーバの
内の下位のサーバを介して、前記複数のサーバの内の上
位のサーバから配信された情報を受信し、前記上位のサーバが、前記下位のサーバ又はクライアン
トからの前記配信要求によって、予め登録された前記下
位のサーバ又はクライアントに対して情報を配信するプ
ッシュ型配信を行うことを特徴とする請求項７に記載の
情報受配信システム。