JP2001125821A

JP2001125821A - データ通信方法およびサーバ装置

Info

Publication number: JP2001125821A
Application number: JP30954399A
Authority: JP
Inventors: Mitsuhiro Wada; 光弘和田; Ko Nakayama; 香中山; Yasuaki Murakami; 恭朗村上; Daisuke Okabe; 大輔岡部
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-10-29
Filing date: 1999-10-29
Publication date: 2001-05-11

Abstract

(57)【要約】【課題】クライアント端末が情報発信サーバからハイ
パーテキストデータを効率的に先行取得できるデータ通
信方法とサーバ装置を提供する。【解決手段】クライアント装置がリクエストメッセー
ジを送信する時、先行取得情報の種類と階層範囲とをサ
ーバに指定しておき、情報発信サーバが、上記リクエス
トメッセージで要求されたハイパーテキスト形式のペー
ジ情報の他に、該ページ情報にリンクした関連情報のう
ち、上記先行取得情報種類と階層範囲に該当する情報ブ
ロックを追加検索し、順次にクライアント装置に送信す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネットに
代表される通信ネットワークにおけるデータ通信方法お
よびサーバ装置に関し、更に詳しくは、情報ブロック内
に関連する他の情報ブロックをアクセスするためのリン
ク情報を含んだハイパーテキスト形式のデータ通信方法
およびサーバ装置に関する。

【０００２】

【従来の技術】インターネット・プロトコル（ＩＰ）を
データ転送プロトコルの基本とするデータ通信ネットワ
ーク、所謂「インターネット」では、ファイル転送のた
めのプロトコルであるＦＴＰ(File Transfer Protocol)
を利用したＦＴＰサーバや、例えば、テキスト、画像
（グラフィックデータ）、動画、音声など複数種類のデ
ータが混在したマルチメディア情報を扱うハイパーテキ
スト転送プロトコル（ＨＴＴＰ：Hyper Text Transfer
Protocol)を利用したＷＷＷ(World Wide Web)サーバ
が、世界へ情報の発信源、情報の受信源として利用され
ている。最近では、一般ユーザ向けデジタル機器の普及
により、クライアント端末で容易に画像データや動画デ
ータを扱うことが可能になったため、ＷＷＷサーバから
発信されるコンテンツも、テキストベースの情報から、
同一ページに複数種類の情報（マルチメディア情報）を
含むハイパーテキスト形式の情報に変化してきている。

【０００３】情報通信システムを実用的なものとするた
めには、単純な情報取得以外に、例えば、情報の検索機
能や更新機能などにも優れた転送プロトコルが必要とな
る。ＨＴＴＰでは、リクエストの目的をメソッドで示す
ことによって、これらの複数の機能を実現している。ま
た、ＨＴＴＰでは、メソッドの適用対象となるリソーを
示す識別子：ＵＲＩ（Uniform Resource Identifier）
として、リソースの場所を示すＵＲＬ（Uniform Resour
ce Locator)や、リソースの名前を示すＵＲＮ（Uniform
Resource Name）を適用している。

【０００４】ＷＷＷサーバをアクセスする場合、クライ
アント端末は、メソッドと、リソース識別子ＵＲＩ（目
的情報名と存在場所）と、ＨＴＴＰプロトコルのバージ
ョンとを指定したリクエストメッセージを送信する。ク
ライアント端末は、ＷＷＷサーバから情報を取得する
時、メソッドとして、情報取得を意味する“ＧＥＴ”を
記述したリクエストメッセージを発行する。例えば、サ
ーバ「www.hitachi.co.jp」に蓄積された「index-j.htm
l」という情報を取得したい場合、クライアント端末
は、次のリクエストメッセージを送信する。 GET http://www.hitachi.co.jp/index-j.html HTTP/1.1 ＷＷＷサーバは、上記リクエストメッセージに応答して
情報を検索し、検索された情報ブロック（ページ情報）
を含むレスポンスメッセージをクライアント端末に返送
する。この場合、ページ情報は、ＨＴＭＬ(Hyper Text
Markup Language)によって記述され、ページ内の任意の
コンテンツがリンク情報で他の情報ブロックに関連付け
られたデータ構造となっている。本明細書では、ＨＴＭ
Ｌで記述されたコンテンツのうち、リンク情報によって
更に他の情報ブロックに関係付けられたデータ構造をも
つ情報ブロックを「ページ」と呼び、リンク情報を含ま
ない孤立した情報ブロックを「コンテンツ」と呼ぶこと
にする。

【０００５】

【発明が解決しようとする課題】サーバからレスポンス
メッセージに受信したクライアント端末は、取得したペ
ージ情報を画面に表示する。上記表示画面で、ユーザ
が、特定の情報領域を選択した場合、この情報領域に設
定されたリンク情報をＵＲＩとする新たなリクエストメ
ッセージが生成され、サーバに送信される。これによっ
て、サーバから、上記ＵＲＩと対応する新たな情報ブロ
ック（ページ情報またはコンテンツ情報）を含むレスポ
ンスメッセージが送信され、クライアント端末の表示画
面に関連情報として表示される。

【０００６】最新バージョンのＨＴＴＰ／１．１では、
クライアント端末とＷＷＷサーバとの間にＴＣＰコネク
ションを確立した状態で、クライアント側（ブラウザ）
から連続的にリクエストを発行し、サーバ側で、これら
の受信リクエストを順次にパイプライン処理することに
よって、連続的にレスポンスを発信できるようになって
いる。例えば、予めブラウザに関連情報の先取りを指示
しておくと、サーバから最初のページ情報を取得した時
点で、ブラウザが、受信ページ中のリンク情報を解析し
て、自動的に追加リクエストを発行する。これらの追加
リクエストに応答してサーバから送信されてきたサービ
ス情報をクライアント端末のディスクに蓄積しておくこ
とによって、ユーザが最初のページの表示画面で関連情
報の取得を指示した時、該当する情報を上記ディスクか
ら読み出すことによって、関連情報を瞬時に画面表示す
ることが可能となる。

【０００７】然るに、従来技術によれば、クライアント
端末からの関連情報のリクエストは、リンク情報毎にリ
クエストメッセージを発行する形式となっている。この
ため、ブラウザによる関連情報の先行取得機能を利用し
た場合、リンク情報と同数のリクエストメッセージが次
々と発行され、各リクエストに対応して、サーバから次
々とレスポンスが返送されるため、最初の取得ページに
多数のリンク情報が設定されていた場合、ネットワーク
上のトラフィックが急増するという問題がある。

【０００８】全世界のユーザが利用するインターネット
においては、特に人気のある情報発信サーバや、世界的
なイベントの情報を扱っているサーバに対して、国境を
超えた多数のユーザからのアクセスが集中する。従っ
て、これらの人気サーバでは、多数ユーザからのアクセ
スが集中することによって情報発信能力が低下するとい
う状況に加えて、上述した関連情報の先行取得機能によ
るクライアント端末からのバースト的なリクエストの発
生が、通信制御バッファの容量不足を招き、結果とし
て、受信リクエストの一部が廃棄されるという危険性が
ある。

【０００９】情報発信サーバ側の処理能力を高める方法
として、例えば、オリジナルサイトとして機能するサー
バとは別に、ミラーサイトとして機能するサーバを設置
することによって、サーバアクセスを分散させる方法
や、情報発信サーバへのアクセス経路上に、情報発信サ
ーバからユーザが引き出した情報を一時的に格納するた
めのキャッシング・サーバを配置し、他のユーザからの
リクエストを上記キャッシング・サーバで処理する等の
方法がある。しかしながら、サービス情報（コンテン
ツ）を一層充実化し、今後更に増加が予想される不特定
多数のクライアントに迅速な情報サービスを提供するた
めには、上述したサーバ側のデータ処理能力の向上だけ
では不充分であり、サーバとクライアントとの間のデー
タ通信方法の改善が必要となる。

【００１０】本発明の目的は、１つの情報発信サーバか
ら多数のクライアント装置に効率的にサービス情報を配
布できるデータ通信方法を提供することにある。本発明
の他の目的は、通信リソースを有効利用してクライアン
ト装置に効率的にハイパーテキストデータをサービスで
きるサーバ装置を提供することにある。

【００１１】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、１つの情報ブロック内に関連する他の情
報ブロックをアクセスするためのリンク情報を含むデー
タ形式でサービス情報を蓄積したサーバ装置と、通信回
線を介して上記サーバ装置に接続されたクライアント装
置との間のデータ通信方法において、（A）上記クライ
アント装置から上記サーバ装置に、情報識別子と先行取
得情報の属性とを指定した形でリクエストメッセージを
送信し、（B）上記サーバ装置が、上記リクエストメッ
セージで指定された情報識別子をもつ情報ブロックを検
索した後、該情報ブロックに含まれる上記指定された属
性に該当するリンク情報に基いて、関連情報ブロックを
追加検索し、上記各検索結果をレスポンスメッセージに
よって上記クライアント装置に送信することを特徴とす
る。

【００１２】上記リクエストメッセージで指定する先行
取得情報の属性は、例えば、先行取得すべき複数の情報
種類を一括して示しており、サーバ装置は、上記指定さ
れた情報識別子をもつ情報ブロックに含まれるリンク情
報のうち、上記属性で指定された特定種類のリンク情報
に基いて、関連情報を追加検索する。上記リクエストメ
ッセージで指定する先行取得情報の属性は、特定種類の
リンク情報に関する階層範囲を示すものであってもよ
い。この場合、サーバ装置は、特定種類の情報につい
て、上記指定された情報識別子をもつ情報ブロックを基
点として、上記階層範囲で指定された段階までリンク情
報を順次に辿って関連情報を追加検索する。具体的に言
うと、本発明において、サーバ装置が蓄積する各情報ブ
ロックは、例えば、ＨＴＭＬ（Hyper Text Markup Lang
uage）で記述されたハイパーテキスト形式のものであ
り、上述したリクエストメッセージとレスポンスメッセ
ージは、ＨＴＴＰ（Hyper Text TransferProtocol）に
従う。

【００１３】本発明によるサーバ装置は、１つの情報ブ
ロック内に関連する他の情報ブロックをアクセスするた
めのリンク情報を含むデータ形式でサービス情報を蓄積
し、通信回線を介して接続されたクライアント装置から
のリクエストに応答して情報サービスを行うためのもの
であり、上記クライアント装置から情報識別子と先行取
得情報の属性とを指定したリクエストメッセージを受信
した時、上記情報識別子をもつ情報ブロックを検索した
後、該情報ブロックに含まれる上記指定された属性に該
当するリンク情報に基いて、関連情報ブロックを追加検
索する検索手段と、上記検索された各情報ブロックをレ
スポンスメッセージによって上記クライアント装置に送
信するための手段とを有することを特徴とする。上記検
索手段は、関連情報ブロックの追加検索を容易にするた
めに、例えば、リンク情報を情報識別子とする追加検索
用のリクエストを内部的に生成するたの手段と、クライ
アント装置から受信したリクエストメッセージと上記内
部的に生成されたリクエストとに応じて情報検索するた
めの手段とからなる。

【００１４】

【発明の実施の形態】以下、本発明の実施形態を図面を
参照して説明する。図１は、本発明を適用する通信ネッ
トワークシステムを示す。通信ネットワークシステム
は、ＩＰ（インターネット・プロトコル）ネットワーク
３に接続された複数のクライアント端末１（１Ａ、１
Ｂ、…１Ｎ）と、複数の情報発信サーバ、例えば、ＷＷ
Ｗサーバ２（２Ａ〜２Ｍ）とからなる。実際のシステム
では、クライアント端末の一部は、例えば、公衆の電話
回線を通じてＩＰネットワークのアクセスポイント（ゲ
ートウエイ装置）に接続され、上記アクセスポイントを
介して各サーバ２と通信する。

【００１５】図２は、クライアント装置１の構成を示
す。クライアント装置１は、プロセッサ１０と、通信回
線に接続されたネットワーク・インタフェース１１と、
サーバ２から取得した情報（ページ情報またはコンテン
ツ情報）を一時的に蓄積するためのメモリ（例えば、デ
ィスク装置）１２と、プロセッサが利用するワークメモ
リ１３と、プロセッサが実行する各種のプログラムを記
憶するプログラムメモリ１４と、表示装置１５と、上記
表示装置の表示画面上でカーソルを移動し、アイコン、
メニューあるいはコンテンツ等の選択操作に使用される
位置情報入力装置（マウス）１６と、文字やコマンドの
入力キーを備えたキーボード１７と、これらの要素を接
続するバス１８とからなる。

【００１６】上記プログラムメモリ１４には、オペレー
ションシステム（ＯＳ）や通信制御ソフト１４１、ＷＷ
Ｗサーバと通信するためのブラウザ１４２、各種のアプ
リケーションプログラム１４５の他に、後述する要求処
理ルーチン１４３と応答処理ルーチン１４４が記憶され
ている。

【００１７】図３は、ＷＷＷサーバ２の構成を示す。Ｗ
ＷＷサーバ２は、プロセッサ２０と、クライアント端末
に提供する各種のサービス情報（ハイパーテキストデー
タ）を蓄積したファイル装置２１と、上記ファイル装置
２１から検索されたサービス情報を一時的に蓄積するた
めの検索結果蓄積ファイル２２と、プロセッサが実行す
る各種のプログラムを記憶するプログラムメモリ２３
と、後述するリクエストテーブル２００等の各種のテー
ブルが形成されるワークメモリ２４と、通信回線に接続
されたネットワーク・インタフェース２５と、これらの
要素を接続するバス２６とからなる。上記プログラムメ
モリ２３には、オペレーションシステム（ＯＳ）や通信
制御ソフト２３１と、要求受付処理ルーチン２３２と、
情報検索処理ルーチン２３３と、検索結果解析処理ルー
チン２３４と、情報送信処理ルーチン２３５とが記憶さ
れている。

【００１８】図４は、クライアント装置１の要求処理ル
ーチン１４３が利用する要求テーブル１００の構成を示
す。要求テーブル１００は、サーバアドレス１０１と、
上記サーバ内における要求ページのアドレス１０２と、
先行取得情報種類１０３と、検索階層範囲１０４とを定
義している。例えば、ユーザが、前述したサーバ「www.
hitachi.co.jp」に保持されているページ「index-j.htm
l」の取得を指示した場合、サーバアドレス１０１とし
て「www.hitachi.co.jp」が、また、要求ページアドレ
ス１０２として「index-j.html」が記憶される。

【００１９】本発明では、ブラウザ画面で要求ページを
指定する時点、あるいは要求ページの指定に先立って、
ユーザに、上記要求ページ中のリンク情報で関連付けら
れた情報（関連ページ情報または関連コンテンツ情報）
のうち、先行取得を希望する情報の種類１０３を指定さ
せる。また、関連情報のうち、特にテキスト情報につい
ては、上記要求ページを基点として何段階までリンクを
辿って関連情報を先行取得すべきかを示す検索階層範囲
１０４をユーザに指定させる。但し、サーバによる情報
検索処理を複雑化させないために、上記先行取得情報種
類と検索階層範囲の指定は、同一サーバ内に存在する関
連情報についてのみ有効とする。

【００２０】要求処理ルーチン１４３は、後述するよう
に、ユーザが指定した先行取得情報種類１０３と検索階
層範囲１０４を、サーバアドレス１０１および要求ペー
ジアドレス１０２と対応づけて、上記要求テーブル１０
０に記憶しておき、上記要求ページを取得するためのリ
クエストメッセージに付随して、サーバに、上記先行取
得情報種類１０３または検索階層範囲１０４で指定され
た範囲内での関連情報の取得を指示する。

【００２１】図５は、ＷＷＷサーバ２が備える要求管理
テーブル２００の構成を示す。要求管理テーブル２００
は、クライアントアドレス２０１と、要求ページ２０２
と、先行取得情報の種類２０３と、検索階層範囲２０４
との関係を定義している。ＷＷＷサーバ２では、クライ
アント端末１からリクエストメッセージを受信すると、
図６に示すように、要求受付処理ルーチン２３２によっ
て、リクエストメッセージをリクエストバッファに蓄積
する。また、上記要求管理テーブル２００に、リクエス
トの送信元となったクライアント端末のＩＰアドレス２
０１と対応して、要求ページ２０２、先行取得情報種類
２０３、検索階層範囲２０４を記憶する。

【００２２】情報検索処理ルーチン２３３は、リクエス
トバッファ２４０から順次にリクエストメッセージを取
り出し、サービス情報ファイル２１から上記リクエスト
に該当するページ（ＨＴＭＬ文書）を検索する。情報検
索処理ルーチン２３３は、検索結果をリクエストメセー
ジと共に検索結果蓄積ファイル２２に蓄積した後、検索
を終えたリクエストメッセージを検索結果処理ルーチン
２３４に通知する。

【００２３】検索結果処理ルーチン２３４は、上記リク
エストメッセージの要求ページアドレスに基いて要求管
理テーブル２００を参照し、検索結果蓄積ファイル２２
に新たに蓄積された検索結果について、追加検索の要否
を判定する。この時、要求管理テーブル２００から読み
出された上記リクエストメッセージと対応するレコード
が示すページアドレス２０２とクライアントアドレス２
０１との関係を送信アドレステーブル２１０に記憶して
おく。

【００２４】もし、検索されたページに関して、要求管
理テーブル２００の先行取得情報種類２０３が関連情報
の先行取得を指示していた場合は、上記ページに含まれ
るリンク情報を解析し、先行取得情報種類２０３で指定
された種類の情報リンクについて、追加検索のためのリ
クエストメッセージを生成し、リクエストバッファ２４
０に追加する。また、上記追加リクエストメッセージ毎
に、上記クライアントアドレス２０１と、各追加リクエ
ストで検索する新たな要求ページアドレスとの関係を示
す新たなレコードを要求管理テーブル２００に追加す
る。これらの追加レコードの先行取得情報種類２０３
は、指定なしを示す「０」にしておく。

【００２５】今回検索されたページに関して、上記先行
取得情報種類としてテキスト情報が指定されていた場
合、検索階層範囲２０４で階層指定がなされているか否
かを判定し、もし、階層指定がなされていた場合は、テ
キスト情報に関する各追加レコードの検索階層範囲２０
４には、現在の指定値から「１」を引いた値を設定して
おく。今回検索されたページに関して、先行取得情報の
種類としてテキスト情報の指定がなく、検索階層範囲２
０４で階層が指定されていた場合は、上記ページに含ま
れるテキスト情報リンクについて、追加検索のためのリ
クエストメッセージを生成し、リクエストバッファ２４
０に追加すると共に、追加リクエストメッセージ毎に、
上記クライアントアドレス２０１と、各追加リクエスト
で検索する新たな要求ページアドレスとの関係を示す新
たなレコードを要求管理テーブル２００に追加する。こ
れらの追加レコードも、先行取得情報種類２０３を
「０」とし、検索階層範囲２０４には、現在値より
「１」を引いた値を設定しておく。

【００２６】上述した要求管理テーブル２００への追加
検索レコードの追加によって、テキスト情報について
は、最初に検索されたページに含まれる各テキスト情報
リンクをルートとするツリー構造的に、関連情報の検索
が繰り返される。検索結果処理ルーチン２３４は、検索
結果のリンク情報解析を終えたリクエストに関して、要
求管理テーブル２００から該当レコードを消去した後、
リクエストメッセージを情報送信処理ルーチン２３５に
通知する。

【００２７】情報送信処理ルーチン２３５は、上記リク
エストメッセージと対応する検索結果をサービス情報フ
ァイル２１から読み出して、レスポンスメッセージを生
成する。上記レスポンスメッセージは、送信アドレステ
ーブル２１０が示すクライアントアドレスを宛先とした
ＩＰパケットに組み込まれ、ネットワークインタフェー
ス２５を介して、要求元のクライアント端末１に送信さ
れる。

【００２８】尚、上記実施例で、検索階層範囲１０４の
適用対象をテキスト情報に限定した理由は、先行取得す
る情報量を抑制し、通信リソースを有効に利用するため
である。すなわち、画像や音声のデータ量は、情報圧縮
した状態でも、テキストデータに比較して遥かに大であ
り、指定された階層範囲でこれらの情報の先行取得を許
容とすると、トラフィックが増加し、クライアント装置
側に大容量のバッファメモリを用意する必要があり、し
かも、先行取得された情報の全てがユーザに参照される
とは限らないからである。

【００２９】図７は、情報発信サーバ２が備えるサービ
ス情報ファイル２に蓄積されたハイパーテキストデータ
のデータ構造を模式的に示す。ここでは、前述したよう
に、ＨＴＭＬ等のハイパーテキスト形式により記述され
た情報ブロックのうち、関連情報への展開が可能なリン
ク構造をもつ情報ブロックを「ページ」と定義し、関連
情報への展開のない単独の情報ブロック、例えば、ｊｐ
ｅｇやｇｉｆ形式の画像データ、ｍｐｅｇやａｖｉ形式
の動画データ、ｊａｖａ言語に代表される実行型ファイ
ル等を「コンテンツ」と定義する。

【００３０】データブロック２１０に示すように、ペー
ジＡは、ページＡ１、Ａ２、Ａ３、α、βと、コンテン
ツＣ１、Ｃ２、γとからなっている。各ページの構成要
素となる情報ブロック、例えば、上記ページＡを構成し
ているページＡ１、Ａ２、Ａ３、α、βと、コンテンツ
Ｃ１、Ｃ２、γは、必ずしも同一サーバ内に存在すると
は限らない。ここでは、ページＡ１、Ａ２、Ａ３と、コ
ンテンツＣ１、Ｃ２が、情報発信サーバ２に存在し、ペ
ージα、βとコンテンツγは、他のサーバに存在してい
るものと仮定する。ページＡのデータブロック２１０
は、ページＡ１、Ａ２、Ａ３、α、βへのリンク情報を
含み、リンク先のページＡ１、Ａ２、Ａ３は、データブ
ロック２１１、２１２、２１３に示すように、それぞれ
更に下位のページＡ１１〜Ａ３１とコンテンツＣ１１〜
α１からなっている。

【００３１】尚、ページＡ、Ａ１〜Ａ３、Ａ１１〜Ａ３
１において、コンテンツＣ１〜Ｃ３１１の実体は、それ
ぞれが属するページ内に直接埋め込まれてもよいし、所
属ページとは別の記憶領域にコンテンツを蓄積し、これ
を所属ページにリンク情報で結合したデータ構造であっ
てもよい。コンテンツ情報がテキストの場合は、前者の
構造を適用できるが、画像、音声、動画等のコンテンツ
情報は、後者の構造が適している。ここで、ページＡの
構成要素であるページＡ１がテキスト情報、ページＡ２
とＡ３が画像情報、ページαとβが音声情報と仮定す
る。

【００３２】本発明において、ページＡの取得に際し
て、ユーザが、先行取得情報の種類１０３としてテキス
トと画像を指定した場合、目的ページＡを定義したデー
タブロック２１０の他に、目的ページＡの構成要素のう
ち、情報発信サーバ２内にあって上記先行取得情報種類
で指定された種類の情報ブロック、すなわち、ページＡ
１のデータブロック２１１と、画像情報を含むページＡ
２、Ａ３のデータブロック２１２、２１３が追加検索さ
れ、クライアント端末に送信される。また、ユーザが、
検索階層範囲１０４として、例えば、階層「２」を指定
した場合、目的ページＡの構成要素のうち、テキスト情
報を含む第１階層ページＡ１のデータブロック２１１
と、ページＡ１を構成する第２階層ページＡ１１、Ａ１
２のうちでテキスト情報を含むもの、例えば、ページＡ
１１のデータブロック２１６が追加検索され、レスポン
スメッセージによってクライアント端末に送信される。

【００３３】図８は、クライアント端末の表示装置１５
に出力されるページ画面１５０の１例を示す。上記ペー
ジは、例えば、「http//www.hitachi.co.jp/index-j.ht
ml」をアクセスすることによって得られるもので、タイ
トル「ＨＩＴＡＣＨＩ」１５１と、製品紹介欄１５３
と、トピックス欄１５５とからなっている。上記製品紹
介欄１５３には、新製品を示す複数の画像（イメージ
１、イメージ２、…）１５３Ａ、１５３Ｂ、…が表示さ
れ、トピックス欄１５５には、記事の見出し文字列（テ
キスト情報）が表示される。見出し文字列のうちの１つ
は、例えば、「新しい経営体制について」となってい
る。各見出し文字列は、その一部に下線が付され、この
部分に関連情報がリンクされていることを意味してい
る。ユーザが、マウス操作によって上記下線部を選択す
ると、選択された文字列に関連した情報が、新たなペー
ジ情報として画面上に表示される。

【００３４】図９は、図８に例示したページ内容と対応
するＨＴＭＬの文書構造を示す。ＨＴＭＬ文書は、記号
< >で示すタグを構成要素としており、１つのＨＴＭＬ
文書は、<HTML>で始まり、</HTML>で終わる。各ＨＴＭ
Ｌ文書は、<HEAD>と</HEAD>との間に記述されるエンテ
ィティ・ヘッダ部と、<BODY>と</BODY>との間に記述さ
れるエンティティ・ボディ部とからなり、前述したタイ
トル１５１は、エンティティヘッダ部において、<TITLE
>と</TITLE>の間に定義される。

【００３５】図９で、ステップ１０００に示した「IMG
SCR= "images/top/1_1.gif"」は、サーバ内のディレク
トリ「images/top/」に存在している画像「1_1.gif」
を、<TDから</TD>までの間で定義された図８のイメージ
領域１５３Ａに表示することを意味している。同様に、
ステップ１００１は、ディレクトリ「images/top/」に
存在している画像「1_2.gif」を、<TDから</TD>までの
間で定義された図８のイメージ領域１５３Ｂに表示する
ことを意味している。ステップ１００２は、図８のトピ
ックス見出し文字列「新しい経営体制について」に対応
したタグを示している。ここで、「<A HREF= "/topics/
9904/01a.html">経営体制</A>」は、文字列「経営体
制」に付随するリンク情報を示しており、表示画面で文
字列「経営体制」部分をユーザが選択すると、サーバ
「www.hitachi.co.jp」に存在しているアドレス「/topi
cs/9904/01a.html」をもつページ内容が画面に表示され
る。

【００３６】図１０は、クライアント端末１とサーバ２
との間で実行されるハイパーテキストデータの従来の通
信手順をＩＰレベルで示す。クライアント端末１は、サ
ーバ２へのページ情報の要求に先だって、先ず、クライ
アント端末とサーバとの間にＴＣＰコネクションのオー
プン（確立）手続きを実行する（ステップ３１０）。Ｈ
ＴＴＰバージョン「HTTP/1.1」以降では、一旦、ＴＣＰ
コネクションが確立されると、パイプライン通信を可能
にするために、クライアントまたはサーバの何れかが切
断を指示しない限り、ＴＣＰコネクションが維持され
た状態が続く。

【００３７】ＴＣＰコネクションがオープンされると、
クライアント端末からＨＴＴＰリクエストを送信する
（ステップ３２０）。ＨＴＴＰリクエストは、前述し
たように、メソッドとして情報取得要求を意味する“Ｇ
ＥＴ”を記述し、リソース識別子ＵＲＩ（目的情報名と
存在場所）でリクエストの適用対象、例えば、サーバ
「www.hitachi.co.jp」が保持する「index-j.html」を
指定し、ＨＴＴＰバージョンを特定したリクエストメッ
セージ（Request１）を送信する。サーバ２は、上記リ
クエストメッセージを受信すると、リソース識別子ＵＲ
Ｉで指定された要求ページ情報を検索した後、検索結果
を含むレスポンスメッセージ（Response 1）をクライア
ント端末に返送する（ステップ３４０）。

【００３８】上記レスポンスメッセージは、ステータス
ラインと、これに続くメッセージボディとからなる。ス
テータスラインは、ＨＴＴＰバージョンと、リクエスト
の処理結果を示す３桁数字のステータスコードと、該ス
テータスコードをテキストで記述した理由文とからり、
リクエストが正常に処理された場合、上記ステータスラ
インとして、例えば、「HTTP/1.1 200 OK」が返送され
る。レスポンスメッセージのメッセージボディは、リク
エストの処理日時、サーバ名、送信コンテンツのタイ
プ、長さ、符号化形式、およびコンテンツの最終更新日
を示したＨＴＴＰヘッダと、エンティティ・ボディとか
らなり、前述した「http//www.hitachi.co.jp」の「/in
dex-j.html」をリクエストした場合、レスポンスメッセ
ージのエンティティ・ボディとして、図９に示した内容
のＨＴＭＬ文書がクライアント端末に送信される。

【００３９】従来の通信手順では、ユーザが予め先行取
得情報の種類を指定しておくと、クライアント端末１
は、サーバからレスポンスメッセージを受信した時、Ｈ
ＴＭＬ文書を解析し、受信ＨＴＭＬ文書にリンク情報
で定義されている関連情報の中から指定種類のものを見
つけ、サーバに情報送信をリクエストする（ステップ３
３０）。上記リクエストは、リンク情報毎に別々のリク
エストメッセージ（Request 2、Request 3、…）を送信
する形で行われ、サーバ２は、上記各リクエストメッセ
ージに応じた検索処理を実行し、それぞれの検索結果を
レスポンスメッセージ（Response 2、Response 3、…）
によって返送する（ステップ３５０）。

【００４０】図１１は、ハイパーテキスト形式のページ
情報を取得するためにクライアント端末１とサーバ２と
の間で実行される本発明による通信手順を示す。本発明
では、クライアント端末１は、ＴＣＰコネクションをオ
ープン（ステップ３１０）した後、目的ページ情報をリ
クエストする際に、先行取得情報の種類１０３と検索階
層範囲１０４を指定し（ステップ３２１）、これらの付
加情報を最初のリクエストメッセージ（Request 1）で
サーバに伝える。

【００４１】上記先行取得情報種類１０３と検索階層範
囲１０４の指定は、例えば、図１２に示すように、先行
取得情報種類１０３の選択肢として、「text/html」１
０３Ａ、「image/jpeg」１０３Ｂ、「image/gif」１０
３Ｃ、「audio/midi」１０３Ｄを含み、検索階層範囲１
０４の選択肢として、「階層０」１０４Ａ、「階層１」
１０４Ｂ、「階層２」１０４Ｃを含む選択メニュー画面
を表示し、ユーザが指定した選択肢をサーバに通知すれ
ばよい。ここで、「jpeg」「gif」「midi」は、画像お
よび音声の符号化方式の種類を示している。

【００４２】ユーザが、先行取得情報として、「text/h
tml」、「image/jpeg」、「image/gif」を指定した場
合、複数メディアタイプの取得要求を意味する新たなス
テートメントとして、例えば、 Allget-mediatype = text/html, image/jpeg, image/gi
f をリクエストメッセージに加える。また、ユーザが、検
索階層範囲としてレベル「１」を指定した場合、テキス
ト情報（text/html）の検索階層範囲を示すステートメ
ントとして、例えば、 hierarchy = 1 をリクエストメッセージに加える。

【００４３】サーバ２は、上記先行取得情報の種類１０
３と検索階層範囲１０４の指定ステートメントを含むリ
クエストメッセージを受信すると、図６で説明したよう
に、該リクエストメッセージで指定されたページ情報を
検索（ステップ３４０）した後、該検索ページに含まれ
るリンク情報を分析し、上記リクエストメッセージで指
定された先行取得情報の種類１０３と検索階層範囲１０
４に該当する関連情報について追加検索（ステップ３４
１）を実行する。これらの検索結果は、検索結果蓄積フ
ァイル２２に蓄積された後、情報送信処理ルーチン２３
４によって、レスポンスメッセージに組み込まれ、要求
元のクライアント装置に送信される（ステップ３６
０）。この場合、例えば、検索されたページ情報（ＨＴ
ＭＬ文書）毎に、前述したステータスラインと、これに
続くメッセージボディとからなるレスポンスメッセージ
を生成し、各メッセージボディに１ページ分のＨＴＭＬ
文書を設定した形で、レスポンスメッセージの送信が繰
り返される（ステップ３６１）。但し、データ量が少な
ければ、複数のレスポンスメッセージを１つのＩＰパケ
ットにまとめて送信するようにしてもよい。

【００４４】尚、ＨＴＴＰでは、RFC 1341、1521、159
0などで、ＭＩＭＥ（MultipurposeInternet Mail Exten
sions）として、クライアント端末からサーバに受信す
るメディアのタイプを指定できるようになっている。例
えば、ＨＴＭＬで記述されたテキスト情報を取得したい
場合、「Accept:text/html」と指定することによって、
受信情報のフォーマットを限定できる。その他のタイプ
として、「multipart」「image」「application」「aud
io」「message」「video」を指定できる。しかしなが
ら、上記Acceptステートメントは、本発明のように、リ
クエストメッセージのＵＲＩで指定された要求ページ情
報にリンクされた関連情報のうち、追加検索によって先
行所得すべき特定の情報種類を指定するためのものでは
なく、上述したAllget-mediatypeとは機能的に明らかに
異なっている。

【００４５】上記図１２では、先行取得情報の種類１０
３を、情報種類と符号化方式と組み合わせた選択肢によ
って表示したが、アプリケーションが拡張子で指定でき
ることを考慮して、単に、「html」、「jpg,jpeg」、
「gif」、「mid」などの選択肢で指定するようにしても
よい。また、実施例では、情報検索処理ルーチン１３３
による検索結果（ＨＴＭＬ文書）を検索結果解析処理ル
ーチン２３４で解析することによって、追加検索すべき
リンク情報を特定したが、上記解析処理を容易にするた
めに、サーバ側で、サービス情報ファイル２２に登録さ
れた各ページ情報に対応して、構成要素となるリンク情
報（アドレスと情報種類）のリストを予め別ファイルに
記憶しておき、検索結果が得られたとき、上記別ファイ
ルを参照して、クライアントが指定した先行取得情報に
該当するリンク情報を特定するようにしてもよい。

【００４６】

【発明の効果】以上の実施例の説明から明らかなよう
に、本発明によれば、クライアント装置が要求情報を先
行取得する時、情報発信サーバに対する情報取得要求の
イベント数を削減できるため、情報発信サーバに多数の
ユーザからのアクセスが集中した場合でも、イベントの
競合によってリクエストメッセージが棄却される可能性
を低減できる。また、本発明では、クライアント装置か
ら受信した１つのリクエストメッセージに基いて、情報
発信サーバ側で自動的に追加検索を実行し、得られた検
索結果を順次にクライアント装置に返送するようにして
いるため、通信ネットワークのリソースを有効に利用し
て、クライアントに先行取得情報を配送できる。

【図面の簡単な説明】

【図１】本発明を適用する通信ネットワークシステムの
構成を示す図。

【図２】図１におけるクライアント装置１の構成を示す
ブロック図。

【図３】図１における情報発信サーバ２の構成を示すブ
ロック図。

【図４】クライアント装置１が利用する要求テーブル１
００の構成を示す図。

【図５】情報発信サーバ２が利用する要求管理テーブル
２００の構成を示す図。

【図６】情報発信サーバ２で実行される処理ルーチンの
動作を説明するための図。

【図７】情報発信サーバ２が備えるサービス情報ファイ
ル２１に蓄積されるデータ構造を説明するための図。

【図８】クライアント端末１に表示されるページ画面の
１例を示す図。

【図９】図８のページ画面と対応するＨＴＭＬの文書構
造の主要部を示す図。

【図１０】クライアント端末１とサーバ２との間で実行
されるハイパーテキストデータの従来の通信手順をＩＰ
レベルで示した図。

【図１１】クライアント端末１とサーバ２との間で実行
されるハイパーテキストデータの本発明による通信手順
をＩＰレベルで示した図。

【図１２】先行取得情報種類と検索階層範囲を指定する
ためのメニュー画面の１例を示す図。

【符号の説明】

１…クライアント装置、２…情報発信サーバ、３…ＩＰ
ネットワーク、１０…プロセッサ、１１…ネットワーク
インタフェース、１２…ディスク記憶装置、１３…ワー
クメモリ、１４…プログラムメモリ、１５…表示装置、
１００…要求テーブル、１４１…ＯＳ／通信制御ソフ
ト、１４２…ブラウザ、１４３…要求処理ルーチン、１
４４…応答処理ルーチン、１４５…アプリケーションプ
ログラム、２０…プロセッサ、２１…サービス情報ファ
イル、２２…検索結果蓄積ファイル、２３…プログラム
メモリ、２４…ワークメモリ、２５…ネットワークイン
タフェース、２００…要求管理テーブル、２１０…送信
アドレステーブル、２３１…ＯＳ／通信制御ソフト、２
３２…要求受付処理ルーチン、２３３…情報検索処理ル
ーチン、２３４…検索結果解析処理ルーチン、２３５…
情報送信処理ルーチン。

フロントページの続き (72)発明者村上恭朗神奈川県横浜市戸塚区戸塚町216番地株式会社日立製作所通信システム事業本部内 (72)発明者岡部大輔神奈川県横浜市戸塚区戸塚町216番地株式会社日立製作所通信システム事業本部内Ｆターム(参考） 5B075 ND36 PQ05 5B082 FA03 5B089 GA11 GA21 GB04 HA10 JA24 JB22 KA04 KB07 KC44 LB14

Claims

【特許請求の範囲】

【請求項１】１つの情報ブロック内に関連する他の情報
ブロックをアクセスするためのリンク情報を含むデータ
形式でサービス情報を蓄積したサーバ装置と、通信回線
を介して上記サーバ装置に接続されたクライアント装置
との間のデータ通信方法において、上記クライアント装置から上記サーバ装置に、情報識別
子と先行取得情報の属性とを指定した形でリクエストメ
ッセージを送信し、上記サーバ装置が、上記リクエストメッセージで指定さ
れた情報識別子をもつ情報ブロックを検索した後、該情
報ブロックに含まれる上記指定された属性に該当するリ
ンク情報に基いて、関連情報ブロックを追加検索し、上
記各検索結果をレスポンスメッセージによって上記クラ
イアント装置に送信することを特徴とするデータ通信方
法。
【請求項２】前記リクエストメッセージで指定する先行
取得情報の属性が、先行取得すべき複数の情報種類を示
し、前記サーバ装置が、前記指定された情報識別子をも
つ情報ブロックに含まれるリンク情報のうち、上記属性
で指定された特定種類のリンク情報に基いて、関連情報
を追加検索することを特徴とする請求項１に記載のデー
タ通信方法。
【請求項３】前記リクエストメッセージで指定する先行
取得情報の属性が、特定種類のリンク情報に関する階層
範囲を示し、前記サーバ装置が、特定種類の情報につい
て、前記指定された情報識別子をもつ情報ブロックを基
点として、上記階層範囲で指定された段階までリンク情
報を順次に辿って、関連情報を追加検索することを特徴
とする請求項１に記載のデータ通信方法。
【請求項４】前記各情報ブロックが、ＨＴＭＬ（Hyper
Text Markup Language）で記述されたハイパーテキスト
形式を有し、前記リクエストメッセージとレスポンスメ
ッセージが、ＨＴＴＰ（Hyper Text Transfer Protoco
l）に従うことを特徴とする請求項１〜請求項３の何れ
かに記載のデータ通信方法。
【請求項５】１つの情報ブロック内に関連する他の情報
ブロックをアクセスするためのリンク情報を含むデータ
形式でサービス情報を蓄積し、通信回線を介して接続さ
れたクライアント装置からのリクエストに応答して情報
サービスを行うサーバ装置において、上記クライアント装置から情報識別子と先行取得情報の
属性とを指定したリクエストメッセージを受信した時、
上記情報識別子をもつ情報ブロックを検索した後、該情
報ブロックに含まれる上記指定された属性に該当するリ
ンク情報に基いて、関連情報ブロックを追加検索する検
索手段と、上記検索された各情報ブロックをレスポンスメッセージ
によって上記クライアント装置に送信するための手段と
を有することを特徴とするサーバ装置。
【請求項６】前記検索手段が、前記リンク情報を情報識
別子とする追加検索用のリクエストを内部的に生成する
ための手段と、前記クライアント装置から受信したリク
エストメッセージと上記内部的に生成されたリクエスト
とに応じて情報検索するための手段とからなることを特
徴とする請求項５に記載のサーバ装置。