JP2006171918A - クライアントへのデータ送信および更新データの実行制御方法 - Google Patents

Abstract

【課題】 サーバから複数のクライアントへ送信されるアプリケーション・プログラムの送信を円滑にし、システム内の全てのクライアントが、更新されたアプリケーション・プログラムを、ある指定日時以降に、一斉に使用可能とすることができる方法を提供する。
【解決手段】 サーバと複数のクライアントとに接続される通信ネットワークとを備えるネットワークシステムに適用される方法であり、このクライアントにおいて実行可能なファイルを、通信ネットワークを介してサーバがクライアントへ送信する第一送信ステップと、サーバが、この実行可能なファイルの実行日時を示す実行日時データを、通信ネットワークを介してクライアントへ送信する第二送信ステップと、クライアントが現在時刻と当該実行日時データとに基づいてこの実行可能なファイルを実行するか否かを判断する実行判断ステップと、を有する方法。
【選択図】 図２

Description

本発明は、サーバと、このサーバに通信回線を介して接続される複数のクライアントと、通信ネットワークと、を備えたネットワークシステムを用いて、各クライアントのデータを更新させ、この更新したデータの実行を制限する方法に関する。

従来より、クライアントにて動作するアプリケーション・プログラムが、サーバから、ネットワークに接続する全てのクライアントへ配信され、このアプリケーション・プログラムのアップデートプログラム（更新データ）も、サーバから配信されることが行われている。

例えば、運送管理システムでは、全国の支店に備えられたクライアントが数十台から数百台あり、これに対してサーバは数台といったようなシステム構成であり、少数のサーバから多数のクライアントへアプリケーション・プログラムの更新データの送信が行われる。

このようなクライアントは、アプリケーション・プログラム（以下、適宜、「静的データ」）と、アプリケーション・プログラムにて使用するデータ（以下、「動的データ」）とを分離し、通常は、一のクライアントのみが、この動的データをサーバと通信する。このようなデータは、ファイルサイズが比較的小さく、かつ、送信元となるクライアントは１台程度なので、データ流量が通信回線を圧迫することはない。

しかしながら、アプリケーション・プログラムの更新を行う場合には、ファイルサイズが大きいこともあり、かつ、このアプリケーション・プログラムの更新が多数のクライアント分だけ発生するため、更新に伴うデータ流量が通信回線を圧迫することがある。

一方、システム内の複数のクライアントのアプリケーション・プログラムが更新されて、実行される際には、このシステム内の全てのクライアントが、同時に、新しいアプリケーション・プログラムの実行を開始できることが望まれる。例えば、クライアントが入力を行う項目の追加に関するアプリケーション・プログラムの変更がある場合には、この入力項目の追加に伴うサーバ側のデータベースにも、変更が発生する。この場合に、あるクライアントは、以前のデータ・フォーマット（新しい入力項目がないフォーマット）でサーバに動的データを送信し、他のクライアントは新しいデータ・フォーマット（新しい入力項目が含まれたフォーマット）でサーバに動的データを送信する。これにより、サーバは、以前のデータ・フォーマットと新しいデータ・フォーマットとの両方のデータを処理する必要が生じてしまう。

このように、両方のデータを処理することは、サーバの負荷が増加するという点から、回避できることが望ましい。したがって、システム内の全てのクライアントが、所定の時間に一斉に、更新されたアプリケーション・プログラムを使用できるように、時間的な制限を設けた更新データの使用を可能にする方法がシステムにとって、望ましい。

アプリケーション・プログラムを複数のクライアントが、サーバから取得して、利用する方法として、サーバが、クライアントからのアクセスを時間的に制限したコンテンツを提供し、そのコンテンツをクライアントが、所定の時間にのみ取得して利用する方法が知られている（特許文献１参照）。

この特許文献１に記載の方法によれば、配送スケジューリング装置とこの配送スケジューリング装置に通信回線を介して接続されるクライアントとを有するシステムにおいて、配送スケジューリング装置は、提供するコンテンツを公開開始時刻及び公開終了時刻で制御し、クライアントがコンテンツにアクセスできる時間を制限する。この時間的な制限により、クライアントは、略同一時刻にサーバからコンテンツを取得し、そのコンテンツを利用することが可能である。
特開平２００２−１０８７１８号公報

しかしながら、上述したコンテンツの提供では、複数のクライアントが略同一時刻において、サーバに提供されたコンテンツを一斉に取得しようとする。そのため、クライアントがコンテンツを取得しようとすると、通信回線への負荷が高まり、コンテンツを取得できない状況が発生し、提供されたコンテンツを一斉に利用できないおそれがあった。

例えば、図７に示すように、クライアントは、静的データの取得・利用を以下のように行う。はじめに、クライアント６０が所定のタイミングで、静的データの取得をサーバ５０に対して要求する（Ｓ３０）。この際に、クライアント６０の静的データのバージョンや更新日時に関する情報をサーバ５０に送信する。サーバ５０が、これに応答して、対応した静的データをクライアント６０に送信する（Ｓ３１）。この際に、サーバ５０は、更新した時間（Ｔ１）をクライアント６０に、ＨＴＴＰ（HyperText Transfer Protocol）要求ヘッダのフィールド（Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ Ｔ１）を用いて、送信する。

次に、クライアント６０が更新された静的データの取得のために、「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」（条件付ＧＥＴ）を発行する（Ｓ３２）。ここで、「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」とは、ＨＴＴＰ（HyperText Transfer Protocol）要求ヘッダのフィールドのひとつである。すなわち、サーバ５０は、この条件付ＧＥＴを受信すると、「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」フィールドの後に示される時刻（ここではＴ１）よりも新しい静的データが記憶されているかを確認する。

「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」フィールドの後に示される時刻（ここではＴ１）よりも新しい静的データがサーバ５０に記憶されている場合には、サーバ５０に記憶された静的データをクライアント６０に送信する。「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」フィールドの後に示される時刻（ここではＴ１）よりも新しい静的データが記憶されていない場合には、静的データの送信を行わない（Ｓ３３）。

そして、クライアント６０が更新された静的データをサーバ５０から受信するとすぐに、現在使用している静的データをサーバ５０から取得した新しい静的データに更新する。したがって、複数のクライアントが静的データの更新処理を一斉に行うと、通信回線の負荷が高くなる状況が発生し、サーバは新しい静的データを円滑に送信することができない。そのため、結果的に、システム内の全てのクライアントで、同時に新しい静的データを実行開始とさせることができなくなる。

そこで、本発明は、複数のクライアントが、アプリケーション・プログラムをサーバから取得して、実行する際に、サーバからの新しいアプリケーション・プログラムの送信を円滑にし、システム内の全てのクライアントが、更新されたアプリケーション・プログラムを、ある指定日時以降に、一斉に実行可能とすることができる方法およびシステムを提供することを目的とする。

本発明によれば、サーバと、複数のクライアントと、当該サーバと複数の当該クライアントとに接続される通信ネットワークとを備えるネットワークシステムに適用される方法であり、当該クライアントにおいて実行可能なファイルを、当該通信ネットワークを介して当該サーバが当該クライアントへ送信する第一送信ステップと、当該サーバが、当該ファイルの実行開始日時を示す実行開始日時データを当該通信ネットワークを介して当該クライアントへ送信する第二送信ステップと、当該クライアントが現在日時と当該実行開始日時データとに基づいて当該ファイルを実行するか否かを判断する実行判断ステップと、を有する方法を提供する。

したがって、クライアントにおいて実行可能なファイルを、通信ネットワークを介して、サーバがクライアントへ送信し、サーバが、このファイルの実行開始日時を示す実行開始日時データを当該通信ネットワークを介してクライアントへ送信し、このクライアントが現在日時と実行開始日時データとに基づいて、このファイルを実行するか否かを判断する。

本発明によれば、システム内の全てのクライアントは、新しいアプリケーション・プログラムを実行開始日時データに基づいて、実行開始日時以降に使用可能とすることができる。

以下、本発明の一実施形態を図面に基づいて説明する。

[ネットワークシステムの構成]図１は、本発明の一実施形態に係るサーバとクライアントの概略構成を示すシステムの構成図である。本実施の形態が適用されるネットワークシステム１は、企業内の通信ネットワーク２と、サーバ１０と、ユーザが業務などで操作するクライアント２０とを備える。これらのサーバ１０とクライアント２０は、通信ネットワーク２を介してデータを送受信する。

ネットワークシステム１は、複数のサーバ１０と、複数のクライアント２０とから構成されていてよい。ネットワークシステム１を構成する通信ネットワーク２は、サーバ１０とクライアント２０とを接続する専用線であってもよいし、インターネット等の公衆通信回線であってもよい。

サーバ１０は、１以上のクライアント２０に対して、アプリケーション・プログラムを送信する装置である。更新されたアプリケーション・プログラムは、サーバ１０に記憶され、ネットワークシステム１に接続された全てのクライアント２０に送信される。サーバ１０は、制御装置１１、主記憶装置１３、通信装置１４、補助記憶装置１５、入力装置１６、出力装置１７、送信ファイル管理部１２を備える。

制御装置１１は、例えばＣＰＵ（中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））であり、コンピュータの中心となる部分で、演算(計算)を行い、プログラムとデータの流れを制御する。主記憶装置１３はプログラムやデータを記憶し、ＣＰＵから返された処理結果を記憶する。すなわち、コンピュータの働きの中心となるメモリであってよい。通信装置１４は、サーバ１０とクライアント２０との間でのデータやパラメータの受け渡し、結果の受け取りを行う。

補助記憶装置１５は、制御装置１１からのアクセスが少ないデータや、入力装置１６を介して入力されたデータなどを記憶する。補助記憶装置１５には、例えば、フロッピー（登録商標）ディスクやハードディスク、ＤＶＤ−ＲＯＭ、ＣＤ-ＲＯＭなどがある。

入力装置１６は、サーバ１０に接続され、ユーザがコンピュータを操作する際に使用し、コンピュータの外部からさまざまな情報をコンピュータに与える。入力装置１６には、例えば、キーボード、マウス、スキャナなどがある。出力装置１７は、コンピュータの処理状況や処理結果を表示、印刷、音声のデータとして再生したりする。出力装置１７には、例えば、ディスプレイ、プリンタ、スピーカなどがある。

送信ファイル管理部１２は、クライアント２０で使用するクライアントソフトウェア（後で説明するリッチクライアント等）のアプリケーション・プログラム（静的データ）のファイル管理を行うプログラムを備え、リッチクライアントの静的データの更新に必要な複数の静的データと、当該静的データの実行を開始できる実行開始日時データを管理する。すなわち、送信ファイル管理部１２は、現時点で実行可能な静的データを判断し、この判断に基づいてクライアント２０に静的データを送信する。したがって、送信ファイル管理部１２は、このような送信判断手段を備える。また、送信ファイル管理部１２は、送信する静的データと共に実行開始日時データを付加したヘッダを生成する。

送信ファイル管理部１２は、クライアントに送信すべき新しい静的データが、サーバ１０に記憶されていないと判断した場合に、サーバ１０の現在の時刻に関する現在日時の情報を、クライアント２０に送信してもよい。

送信ファイル管理部１２は、更新する静的データを実行開始日時ごとに、補助記憶装置１５のディレクトリを分けて記憶されてもよい。また、現時点で使用されている静的データが記憶されていてもよい。

送信ファイル管理部１２は、ハードウェア的に独立した装置でなくてもよく、制御装置１１と、主記憶装置１３と、補助記憶装置１５とから実現されてもよい。

クライアント２０は、サーバから送信されたアプリケーション・プログラムを動作するコンピュータであり、アプリケーション・プログラムの更新データを受信して、この更新されたプログラムを実行する。クライアント２０は、制御装置２１、主記憶装置２３、通信装置２２、補助記憶装置２５、入力装置２７、出力装置２８、キャッシュ管理部２４を備える。

制御装置２１、主記憶装置２３、通信装置２２、入力装置２７、および出力装置２８は、前述したサーバが備える制御装置１１、主記憶装置１３、通信装置１４、入力装置１６、および出力装置１７と同様の機能を有する。ここで、制御装置２１は、アプリケーション・プログラムを実行する実行手段を含む。

補助記憶装置２５は、キャッシュ記憶部２６を有する。そして、補助記憶装置２５は、制御装置２１からのアクセスが少ないデータや、入力装置２７を介して入力されたデータなどを記憶する。補助記憶装置２５には、例えば、フロッピー（登録商標）ディスクやハードディスク、ＤＶＤ−ＲＯＭ、ＣＤ-ＲＯＭなどがある。

キャッシュ記憶部２６は、静的データを識別するための名前、静的データが更新されたことに関する情報（静的データ更新情報）、静的データの実行開始日時の情報などを記憶する。静的データ更新情報は、後述するように、例えば、静的データの過去の更新した日時（以下「更新日時」）であってもよいし、静的データに関するファイルの管理番号（バージョン番号）である「ファイルの番号」であってもよい。静的データの実行開始日時の情報は、静的データの格納場所（格納場所のディレクトリ、パス等）、静的データの実行開始日時（実行開始日時データ）などを含んでもよい。

キャッシュ記憶部２６は、ハードディスク等の補助記憶装置２５ではなく、主メモリである主記憶装置２３に備えられていてもよい。

キャッシュ管理部２４は、補助記憶装置２５に記憶されたキャッシュ記憶部２６を制御する。キャッシュ管理部２４は、サーバ１０に送信する要求ヘッダに、本発明の独自のヘッダを付加する。また、サーバ１０の送信ファイル管理部１２が付加した要求ヘッダと、クライアント２０が記憶する静的データ更新情報、静的データの実行開始日時データを比較して、クライアント２０で使用するべき静的データを選択し、選択した静的データをユーザに実行させるか判断する実行判断手段を含む。

[ネットワークシステムの作用] 図２を用いて、ネットワークシステム１の具体的な動作を説明する。ここでは一例として、静的データ更新情報が、「更新日時」である場合の説明を行う。

まず、クライアント２０は、ユーザがクライアント２０のリッチクライアントの使用を開始したタイミング等の、所定のタイミングで、更新されたアプリケーション・プログラム（クライアントにて実行可能なプログラム・ファイルである静的データ）が存在するかどうかをサーバ１０に問合せる（ステップＳ１）。ここでは、サーバ１０には、Ｔ１の時間に新しい静的データが記憶されていたため、サーバ１０は、クライアント２０からの問合せの受信に応答して、新しい更新日時Ｔ１の静的データＡ（Ｔ１）をクライアント２０に送信する（ステップＳ２）。

そして、クライアント２０は、所定のタイミングで再度、サーバ１０に問合せを行う（ステップＳ３）。このとき、クライアント２０のキャッシュ管理部２４は、Ｘ−Ｕｓｅ−Ｆｒｏｍを要求ヘッダに付して、静的データＡ（Ｔ１）が、現在の日時においても、最新かどうかをサーバ１０に問合せる（ステップＳ３）。

サーバ１０には、日時Ｔ２に更新された静的データＡ（Ｔ２）が存在しており、かつ、システムに設定された所定の条件を満たしているならば、サーバ１０は、クライアント２０からの問合せに応答して、静的データＡ（Ｔ２）と静的データＡ（Ｔ２）の実行開始日時を記憶した要求ヘッダをクライアント２０に送信する（ステップＳ４：第１送信ステップ）。このときに、サーバ１０の送信ファイル管理部１２は、「Ｘ−Ｕｓｅ−Ｆｒｏｍ Ｔ３」としたヘッダを要求ヘッダ（例えば、ＨＴＴＰヘッダ）に付加して、クライアント２０にこの要求ヘッダを送信する（第２送信ステップ）。すなわち、この付加したヘッダとは、実行開始日時Ｔ３から、送信したアプリケーション・プログラム（静的データ）は実行可能であるという実行開始日時データである。

ここで、第１送信ステップと第２送信ステップとの順番が逆であってもよい。すなわち、これから送信する静的データの実行時刻データを送信しておき、その後に、実際の静的データを送信してもよい。

本例では、第１送信ステップと第２送信ステップは、同時に、サーバ１０により行われる（ステップＳ４）が、個別のパケットがサーバからクライアント２０へ送信されてもよい。

再度、所定のタイミングで、クライアント２０が、静的データＡ（Ｔ２）が最新かどうかをサーバ１０に問合せる（ステップＳ５）。サーバ１０には、新しい静的データが記憶されていないとすると、サーバ１０は、静的データＡ（Ｔ２）が最新の静的データであると判断する。この場合には、サーバ１０は、送信する静的データがない情報（３０４）をクライアントに送信し、現在のサーバの日時Ｔ４（Ｄａｔｅ）を記憶したヘッダをクライアント２０に送信する（ステップＳ６）。

クライアント２０は、サーバ１０の現在日時Ｔ４を記憶したヘッダを受信して、現在日時Ｔ４と実行開始日時データの実行開始日時Ｔ３とを比較して、現在の日時が実行開始日時を経過しているならば、クライアント２０で使用する静的データを今まで使用していた静的データＡ（Ｔ１）から静的データＡ（Ｔ２）に切替え、実行可能とする（実行判断ステップ）。そして、ユーザからの要求があった場合には、クライアント２０が、この新しい静的データ（ファイル）の実行を行う（実行ステップ）。現在日時が実行開始日時を経過していないならば、クライアント２０で使用する静的データを今まで使用していた静的データＡ（Ｔ１）を継続して使用する。

例えば、クライアント２０とサーバー１０の日時の一致が保証される環境下では、クライアント２０は、クライアント２０が受信したサーバ１０の現在日時ではなく、クライアント２０の現在日時を実行開始日時と比較してもよい。

このように、１台のクライアント２０が、静的データを更新して、実行開始日時から新しい静的データを実行できる。サーバ１０は、ネットワークシステム１に接続された全てのクライアントに対して、このような更新作業を行う。したがって、サーバ１０は、実行可能なファイルの送信（第１送信ステップ）を各クライアント２０に対して、複数回、実行してもよい。

サーバ１０が、各クライアント２０に対して第１送信ステップを複数回行う場合には、サーバ２０が、最後のクライアントに静的データを送信する時間が、実行開始日時より前である場合には、全てのクライアントに静的データの準備が完了した状態で、実行開始日時を待ち、実行開始日時後に、実行可能なファイルである静的データを実行する。

次に、静的データ更新情報が、静的データの「ファイル番号」である場合の説明を行う。ファイル番号とは、静的データのバージョン番号であってもよいし、静的データのシリアル番号であってもよい。

まず、クライアント２０は、ユーザがクライアント２０のアプリケーション・プログラムの使用を開始したタイミング等の、所定のタイミングで、更新された静的データが存在するかどうかをサーバ１０に問合せる（ステップＳ１）。ここでは、サーバ１０には、ファイル番号Ｖ１の新しい静的データが記憶されていたため、サーバ１０は、クライアント２０からの問合せの受信に応答して、新しいファイル番号Ｖ１の静的データＡ（Ｖ１）をクライアント２０に送信する（ステップＳ２）。

そして、クライアント２０は、所定のタイミングで再度、サーバ１０に問合せを行う（ステップＳ３）。このとき、クライアント２０のキャッシュ管理部２４は、Ｘ−Ｕｓｅ−Ｆｒｏｍを要求ヘッダに付して、静的データＡ（Ｖ１）が、新しい静的データかどうかをサーバ１０に問合せる（ステップＳ３）。

サーバ１０には、更新された静的データＡ（Ｖ２）が存在しており、かつ、システムに設定された所定の条件を満たしているならば、サーバ１０は、クライアント２０からの問合せに応答して、静的データＡ（Ｖ２）と、静的データＡ（Ｖ２）の実行開始日時とを記憶した要求ヘッダをクライアント２０に送信する（ステップＳ４：第１送信ステップ）。このときに、サーバ１０の送信ファイル管理部１２は、「Ｘ−Ｕｓｅ−Ｆｒｏｍ Ｔ３」としたヘッダを要求ヘッダ（例えば、ＨＴＴＰヘッダ）に付加して、クライアント２０にこの要求ヘッダを送信する（第２送信ステップ）。すなわち、この付加したヘッダとは、実行開始日時Ｔ３から、送信した静的データは、使用可能であるという情報である。

再度、所定のタイミングで、クライアント２０が、静的データＡ（Ｖ２）が最新かどうかをサーバ１０に問合せる（ステップＳ５）。サーバ１０には、新しい静的データが記憶されていないとすれば、サーバ１０は、静的データＡ（Ｖ２）が最新の静的データであると判断する。この場合には、サーバ１０は、クライアント２０からの問合せに応答して、現在のサーバ１０の日時Ｔ４（Ｄａｔｅ）を記憶したヘッダをクライアント２０に送信する（ステップＳ６）。

クライアント２０は、サーバ１０からの現在日時Ｔ４を記憶したヘッダを受信して、現在日時Ｔ４と実行開始日時データのＴ３とを比較して、現在の日時が実行開始日時を経過しているならば、クライアント２０で使用する静的データを今まで使用していた静的データＡ（Ｖ１）から静的データＡ（Ｖ２）に切替える。現在日時が実行開始日時を経過していないならば、クライアント２０で使用する静的データを今まで使用していた静的データＡ（Ｖ１）を継続して使用する。

サーバ１０から、クライアント２０に送信するアプリケーション・プログラムとしては、クライアントで使用するユーザインターフェースに関するプログラムであってよい。このようなユーザインターフェースを実現するプログラムとして、リッチクライアントがある。リッチクライアントとは、クライアント２０に備えられるサーバの情報を閲覧、変更、記録させるための機能であり、サーバから送信されたアプリケーション・プログラムにより動作するプログラムである。

[リッチクライアント] 図３、図４は、クライアント２０の出力装置２８に出力されたリッチクライアントの画面表示である。このリッチクライアントでは、「搬送作業依頼」に関するサービスを提供する。つまり、クライアント２０から搬送作業の依頼を、このリッチクライアントから行うことで、通信ネットワーク２を介して、この依頼に関するデータ（動的データ）がサーバ１０へ送信される。このように、リッチクライアントは、画面のレイアウトなどを定義する静的データと、画面上に表示されるデータを処理する動的データとを備える。

このようなリッチクライアントのファイルであるアプリケーションプログラムファイルを、サーバ１０からクライアント２０へ送信する際に、本発明が適用されてもよい。

図３に示すような搬送作業依頼のウィンドウに、「電話番号」の項目を増やして、さらに、全体のレイアウトを変更して、図４のウィンドウのようにする場合を想定する。この場合には、例えば、更新前の静的データが図３に示すウィンドウを表示するアプリケーション・プログラムであり、更新後の静的データが図４に示すウィンドウを表示するアプリケーション・プログラムである。したがって、上述の静的データＡ（Ｔ１）またはＡ（Ｖ１）が図３に示すウィンドウを表示するアプリケーション・プログラムであり、静的データＡ（Ｔ２）またはＡ（Ｖ２）が図４に示すウィンドウを表示するアプリケーション・プログラムである。

他の実施例としては、クライアントがウェブブラウザを備え、このウェブブラウザに新たな機能を追加するためのアプリケーション・プログラム（静的データ）が、サーバ１０からクライアント２０へ送信される際に、本発明が適用されてもよい。例えば、サーバ１０はウェブサーバであり、クライアントはウェブブラウザを備え、サーバとクライアントがＨＴＴＰにより通信を行う際に、第１送信ステップで、ＨＴＴＰのキャッシュ管理ヘッダを用いて、静的データのファイルを、サーバのキャッシュからウェブブラウザのキャッシュへ送信してもよい。

[サーバの作用] 図５を用いて、サーバ１０の具体的な動作を説明する。まず、サーバ１０が、クライアント２０のキャッシュ管理部２４から、所定のタイミングで、静的データを要求される（ステップＳ１０）。この要求に応答して、サーバ１０は、この要求を受信する。ステップＳ１０での静的データの要求は、新しい静的データの要求のみではなく、静的データがクライアントのキャッシュ記憶部２６に一つも記憶されていない場合に、静的データを要求する場合を含んでもよい。

次に、サーバ１０の送信ファイル管理部１２は、その要求ヘッダに「条件付ＧＥＴ」（Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ）が含まれているかを確認する（ステップＳ１１）。この判別がＮＯのときは、従来技術と同様に、所定の静的データＡをクライアント２０に送信する（ステップ１６）。判別がＹＥＳのときは、送信ファイル管理部１２は、条件付ＧＥＴの時間（条件付ＧＥＴのファイル番号）と、静的データＡが更新された時間（静的データＡのファイル番号）とを比較して、新しい静的データＡがサーバ１０に記憶されているか判別する（ステップＳ１２）。

ステップＳ１２の判別がＹＥＳのときは、送信ファイル管理部１２は、静的データＡより新しい実行開始日時の指定されている静的データＢが存在するかを判別する（ステップＳ１３）。この判別がＮＯならば、静的データを更新する必要がないので、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を送信することに加えて、サーバ１０の時間情報である「Ｄａｔｅ」をクライアント２０に送信する（ステップＳ１７）。

ステップＳ１３の判別がＹＥＳならば、サーバ１０や通信ネットワーク２が「所定の条件」を満たすか判別する。

「所定の条件」とは、サーバ１０が静的データを送信するための条件であるため、通信ネットワーク２の処理負荷を条件としてもよいし、サーバ１０の処理負荷が高いかを条件としてもよい。さらに、予めユーザが定めた時間（期間）であるかを所定の条件としてもよい。すなわち、システム内のネットワークの負荷が下がる時間を予め指定しておき、この時間（もしくは所定の期間）であるかを所定の条件とすることができる。

ここで、通信ネットワーク２の利用率が高いかを判断する条件は、その通信回線の通信速度に対して、送信するファイル量によって判断される。例えば、１０メガbit/sの通信速度であるＬＡＮにおいて、３メガByte＝２４メガbitのファイルを送信した場合には、このファイル送信のみで、ＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection）方式では、ＬＡＮ全体が２秒強、占有されてしまう。このように、通信ネットワーク２が所定の時間（例えば１秒間）占有されてしまう場合には、ネットワークの通信負荷が高いと判断してもよい。

また、サーバ１０の処理負荷が高いかを判断する条件は、サーバ１０の制御装置１１（ＣＰＵ等）の使用率（５０％以上等）により判断してもよいし、サーバ１０の主記憶装置１３（メインメモリ等）の使用率（５０％以上等）により判断してもよい。

加えて、「所定の条件」として、要求のあったクライアント２０の静的データの更新した回数をサーバ１０が記憶しておき、その回数が所定の回数であるかどうかを、「所定の条件」としてもよい。また、要求のあったクライアント２０にて現在、動作する静的データのバージョンと、サーバ１０が送信しようとする静的データとを比較して、両バージョンが異なる場合には、「所定の条件」を満たすとしてもよい。

ステップＳ１４がＹＥＳならば、クライアント２０に静的データＢ、静的データ（Ｂの）実行開始日時、（Ｂの）更新日時の送信をする。ここで、静的データの実行開始日時は、「Ｘ−Ｕｓｅ−Ｆｒｏｍ」に設定されて、クライアント２０に送信される（ステップＳ１５）。クライアント２０では、この新しい静的データ、静的データ更新情報、更新日時を、受信して、キャッシュ記憶部２６に記憶されていたこれらの情報を更新する。ステップＳ１４がＮＯならば、ステップＳ１７へ移る。

[クライアントの作用] 図６を用いて、クライアント２０の具体的な動作を説明する。クライアント２０が、所定のタイミングで静的データをサーバ１０に要求する（ステップＳ２０）。この時点で、静的データがキャッシュ管理部２４に存在するかを判断する（ステップＳ２１）。ここでの判断は、静的データが古いバージョンを含めて、一つでもキャッシュ管理部２４に記憶されているかを判断する。静的データがキャッシュ管理部２４に存在しないならば、「条件無しＧＥＴ」によりサーバ１０から静的データＡを取得する（ステップＳ２５）。

「条件無しＧＥＴ」とは、「Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅ」のヘッダを要求ヘッダに負荷しないで、静的データを要求するＨＴＴＰの要求である。静的データが全くキャッシュ管理部２４に記憶されていない場合には、とりあえず、条件等がない状態で、クライアント２０は、静的データを要求して取得する。

静的データＡを取得した後に、クライアント２０の静的データを静的データＡに更新（利用可能）する（ステップＳ２６）。すなわち、この場合には、実行開始日時の指定がないため、静的データの取得後に、すぐに使用可能となる。

ステップＳ２１がＹＥＳならば、静的データＡの更新日時で、「条件付きＧＥＴ」をサーバ１０へ送信する（ステップＳ２２）。これに対する応答として、サーバ１０から「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」と「Ｄａｔｅ」とを受信した場合には、サーバから受信した日時情報（Ｄａｔｅ）により、クライアント２０で使用する静的データを決定する（ステップＳ２４）。すなわち、日時情報が、静的データの実行開始日時を経過しているならば、クライアント２０は、新しく取得した静的データを使用開始とし、経過していないならば、現在使用している静的データを維持する。

ステップＳ２３がＮＯならば、サーバ１０から「２００ Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」を受信して、サーバから静的データを取得する（ステップＳ２７）。この場合には、受信した要求ヘッダに「Ｘ−Ｕｓｅ−Ｆｒｏｍ」が付されているかの判断が行われる（ステップＳ２８）。ステップＳ２８がＮＯ（付されてない）ならば、クライアント２０の静的データを静的データＡに更新（利用可能）とする（ステップＳ２６）。すなわち、この場合には、実行開始日時の指定がないため、静的データの取得後に、すぐに使用可能となる。

ステップＳ２８が、ＹＥＳ（「Ｘ−Ｕｓｅ−Ｆｒｏｍ」が付されている）ならば、静的データ更新情報の更新日時と静的データ実行開始日時とを、更新した時間の情報と「Ｘ−Ｕｓｅ−Ｆｒｏｍ」の時間と、から更新する（ステップＳ２９）。その後、サーバ１０から得た更新日時と、静的データ実行開始時間とを比較して、更新日時が静的データ実行開始時間を経過していると判断した場合には、クライアント２０は、新しく取得した静的データを使用開始とし、経過していないならば、現在使用している静的データを維持する（ステップＳ２４）。

例えば、図５、図６における実施形態では、更新日時を、静的データ更新情報としていたが、静的データ更新情報を、ファイル番号の情報とすることもできる。すなわち、ステップＳ１２が、「条件付ＧＥＴのファイル番号よりも新しい静的データＡ」として、図６のステップＳ２２が、「静的データＡのファイル番号で条件付ＧＥＴを送信する」、ステップＳ２９が「キャッシュ管理部内のファイル番号情報、静的データ、実行開始日時を更新する」として、ファイル番号により静的データを更新するべきかを判断してもよい。

このような実施形態を実現するシステム、方法を、コンピュータ、クライアント、サーバにて実行するためのプログラムにより実現することができる。このプログラムのための記憶媒体としては、光学記憶媒体、テープ媒体、半導体メモリ等が挙げられる。また、専用通信ネットワークやインターネットに接続されたサーバに設けられたハードディスク又はＲＡＭ等の記憶装置を記憶媒体として使用し、ネットワークを介してプログラムを提供してもよい。

なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。例えば、本発明は、ＪＡＶＡ（登録商標）サーブレットにより機能が拡張されるウェブサーバや、クライアントのウェブブラウザに対して適用されてもよい。

以上、本発明の実施形態を説明したが、具体例を例示したに過ぎない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載された効果に限定されない。

本発明の実施例であるネットワークシステムの構成を示す図である。 本発明の実施例であるネットワークシステムのフローチャート図である。 本発明に用いられるクライアントの画面イメージの一例を示す図である。 本発明に用いられるクライアントの画面イメージの一例を示す図である。 本発明の実施例であるサーバのフローチャート図である。 本発明に用いられるクライアントのフローチャート図である。 従来のクライアントのデータ更新を行うシステムのフローチャート図である。

符号の説明

１ ネットワークシステム
２ 通信ネットワーク
１０ サーバ
１１ 制御装置
１２ 送信ファイル管理部
１３ 主記憶装置
１４ 通信装置
１５ 補助記憶装置
１６ 入力装置
１７ 出力装置
２０ クライアント
２１ 制御装置
２２ 通信装置
２３ 主記憶装置
２４ キャッシュ管理部
２５ 補助記憶装置
２６ キャッシュ記憶部
２７ 入力装置
２８ 出力装置

Claims (28)

1. サーバと、複数のクライアントと、当該サーバと複数の当該クライアントとに接続される通信ネットワークとを備えるネットワークシステムに適用される方法であり、
   当該クライアントにおいて実行可能なファイルを、当該通信ネットワークを介して当該サーバが当該クライアントへ送信する第一送信ステップと、
   当該サーバが、当該ファイルの実行開始日時を示す実行開始日時データを、当該通信ネットワークを介して当該クライアントへ送信する第二送信ステップと、
   当該クライアントが現在時刻と当該実行開始日時データとに基づいて当該ファイルを実行するか否かを判断する実行判断ステップと、
   を有する方法。
2. 前記サーバが、前記第一送信ステップと前記第二送信ステップとを同時に行う請求項１に記載の方法。
3. 前記サーバと前記クライアントとはＨＴＴＰにより前記通信ネットワークを介して通信を行い、
   前記第二送信ステップでは、当該ＨＴＴＰのＨＴＴＰヘッダに前記実行開始日時データを含め、当該実行開始日時データを前記サーバから前記クライアントへ送信する請求項１に記載の方法。
4. 前記サーバと前記クライアントとはＨＴＴＰにより前記通信ネットワークを介して通信を行い、
   前記実行判断ステップでは、前記現在時刻を当該サーバから送信されるＨＴＴＰヘッダから得る請求項１に記載の方法。
5. 前記実行判断ステップでは、前記現在時刻が前記実行開始日時以降の場合に前記ファイルを実行すると判断する請求項１に記載の方法。
6. 前記実行判断ステップにおいて前記ファイルを実行すると判断した場合には、前記クライアントにおいて当該ファイルを実行する実行ステップを有する請求項１に記載の方法。
7. 前記ファイルはユーザインタフェイスファイルを含み、前記実行判断ステップでは、前記クライアントにおいて、そのユーザインタフェイスを更新するか否かを判断する請求項１に記載の方法。
8. 前記ファイルは、アプリケーションプログラムファイルを含み、前記実行判断ステップでは、前記クライアントにおいて、そのアプリケーションプログラムを更新するか否かを判断する請求項１に記載の方法。
9. 前記クライアントは、ウェブブラウザを備え、前記アプリケーションプログラムファイルは、当該ウェブブラウザへ機能追加をするアプリケーションプログラムファイルである請求項８に記載の方法。
10. 前記第一送信ステップを前記実行開始日時前に行う請求項１に記載の方法。
11. 前記複数のクライアントへ送信するための複数の第一送信ステップを複数回に分けて行う請求項１に記載の方法。
12. 前記複数のクライアントに対応する複数の第一送信ステップを複数回に分けて行い、最終回に対応する第一送信ステップを前記実行開始日時前に行う請求項１に記載の方法。
13. 前記第一送信ステップの前に、所定条件に基づいて当該第一送信ステップを行うか否かを判断する送信判断ステップを有する請求項１に記載の方法
14. 前記所定条件は、前記サーバが記憶するファイルのバージョンと前記クライアントが記憶するファイルのバージョンとの相違を含み、
    前記送信判断ステップでは、両バージョンが相違する場合に前記第一送信ステップを行うと判断する請求項１３に記載の方法。
15. 前記サーバと前記クライアントとはＨＴＴＰにより前記通信ネットワークを介して通信を行い、
    前記両バージョンの相違は、当該ＨＴＴＰの「If-Modified-Sinceヘッダ」を用いて判断する請求項１４に記載の方法。
16. 前記所定条件は、前記サーバの処理負荷を含み、
    前記送信判断ステップでは、当該処理負荷が所定値以下の場合に前記第一送信ステップを行うと判断する請求項１３に記載の方法。
17. 前記所定条件は、前記通信ネットワークの通信負荷を含み、
    前記送信判断ステップでは、当該通信負荷が所定値以下の場合に前記第一送信ステップを行うと判断する請求項１３に記載の方法。
18. 前記所定条件は、現在時刻が所定の送信時刻に達したか否かを含み、
    前記送信判断ステップでは、当該現在時刻が当該送信時刻に達した場合に前記第一送信ステップを行うと判断する請求項１３に記載の方法。
19. サーバと、複数のクライアントと、当該サーバと当該クライアントとに接続される通信ネットワークとを備えるネットワークシステムであり、
    当該サーバは、当該クライアントにおいて実行可能なファイルと当該ファイルの実行開始日時を示す実行開始日時データとを当該通信ネットワークを介して当該サーバから当該クライアントへ送信する送信手段を有し、
    当該各クライアントは、現在時刻と当該実行開始日時データとに基づいて当該ファイルを実行するか否かを判断する実行判断手段を有するシステム。
20. 前記各クライアントは、前記実行判断手段の判断に基づいて当該ファイルを実行する実行手段を有する請求項１９に記載の方法。
21. 前記送信手段は、前記ファイルを複数回に分けて前記複数のクライアントに送信する請求項１９に記載のシステム。
22. 前記サーバは、所定条件に基づいて前記ファイルを送信するかを判断する送信判断手段を有する請求項１９に記載のシステム。
23. 互いに通信ネットワークで接続されるサーバと、複数のクライアントとを備えるネットワークシステムに使用するためのコンピュータプログラムであり、
    当該サーバとしてのコンピュータに、当該クライアントにおいて実行可能なファイルの実行開始日時を示す実行開始日時データを当該クライアントへ送信する機能を実現させ、
    クライアントとしてのコンピュータに、現在時刻と当該実行開始日時データとに基づいて当該サーバから送信されたファイルを実行するか否かを判断する実行判断機能を実現させるコンピュータプログラム。
24. サーバと、複数のクライアントと、当該サーバと当該クライアントとに接続される通信ネットワークとを備え、サーバは当該通信ネットワークを介してクライアントにファイルを含む情報を送信し、各クライアントは当該ファイルを実行するネットワークシステムに提供されるサービスの方法であり、
    当該情報として当該ファイルの実行開始日時を示す実行開始日時データを含めるように当該サーバの機能を拡張する第一ステップと、
    現在時刻と当該実行開始日時データとに基づいて当該ファイルを実行するか否かを判断するようにクライアントの機能を拡張する第二ステップと
    を備える方法。
25. 前記サーバと前記クライアントとはＨＴＴＰにより前記通信ネットワークを介して情報をやり取りし、
    前記第一ステップは、ＨＴＴＰヘッダに実行開始日時データを含めるようにサーバの機能を拡張し、
    前記第二ステップは、当該ＨＴＴＰヘッダ中の当該実行開始日時データに基づいて当該ファイルを実行するか否かを判断するようにクライアントの機能を拡張する請求項２４に記載の方法。
26. 前記ファイルを複数回に分けて前記複数のクライアントに送信するようにサーバの機能を拡張する第三ステップを有する請求項２４に記載の方法。
27. 所定条件に基づいて前記ファイルを送信するか否かを判断するようにサーバの機能を拡張する第四ステップを有する請求項２３に記載の方法。
28. 前記サーバの機能は、サーブレットにより拡張される請求項２３に記載の方法。

Images