JP4093215B2 - メモリ管理システムおよびネットワークシステム - Google Patents

Description

本発明は、一のネットワークリソースと他のネットワークリソースとの間でデータの取得を仲介する装置、サーバおよびプログラム、並びに方法に係り、特に、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法に関する。

Ｗｅｂベースの技術の浸透に伴い、ユーザインターフェースとしてＷｅｂブラウザを用い、アプリケーション本体はＷＷＷ（World Wide Web）サーバで稼働させるような、いわゆるシンクライアント型のシステムが利用されるようになってきている。このとき、ＷＷＷサーバからクライアントに送られる情報は、フォームを含むＨＴＭＬ（HyperText Markup Language）データであり、クライアントの端末では、Ｗｅｂブラウザさえ動けば、実行に先立って特にアプリケーションの配布・インストール等の作業を行うことなく、アプリケーションを実行させることができるようになる。また、一般的には、クライアント側でアプリケーションを実行するのに比して、クライアント側はより処理能力の低いハードウエアで運用することができる。

従来、このようなクライアント端末には、ローエンドのＰＣが用いられてきた。しかし、最近では、店舗等に設置して顧客に気軽に使用してもらうことを目的としたものとして、液晶ディスプレイ上にタッチパネルを設け、タッチパネル上の操作だけで利用することができるブラウザ端末も開発され、そのようなブラウザ端末上でもＷｅｂブラウザが動作するようになってきている。

このようなブラウザ端末は、ローエンドのＰＣと異なり、省電力化、低コスト化および省スペース化等を図るために、ＣＰＵの処理能力が低く、メモリリソースも少なく設計されているのが通常である。そのため、ブラウザ端末に組み込むＷｅｂブラウザでは、ＪＡＶＡ（登録商標）アプレット（以下、単にアプレットという。）を実行するにあたり、アプレットに割り当てるメモリ領域を管理する方法として、ＣＰＵ負荷が少なくかつメモリ効率に優れたスタティックメモリ管理方式が採用されている。

スタティックメモリ管理方式は、１つのＷｅｂページをテーブルにより管理し、テーブルがリセットされるまでは、Ｗｅｂページに付属するアプレットを読み込むたびに未使用のメモリ領域を順次割り当てていく方式である。テーブルのリセットタイミングは、そのＷｅｂページをリロードすべき更新命令が与えられたときである。

しかしながら、スタティックメモリ管理方式にあっては、複数のフレームにより構成されたＷｅｂページを表示する場合は、ユーザの操作によっては更新命令が与えられないまま、そのＷｅｂページに付属するアプレットが次々と読み込まれ、メモリリソースが不足し操作不能な状態に陥る可能性があった。例えば、メニュー項目の一覧を表示するメニューフレームと、メニューフレームのメニュー項目に対応する内容を表示するコンテンツフレームにより構成されたＷｅｂページを、ユーザが各メニュー項目を選択しながら一つ一つのメニュー内容を表示する場合、メニュー項目を選択するごとにコンテンツフレームのＷｅｂページは更新されるが、コンテンツフレームの更新だけでは全体のＷｅｂページについて更新命令が与えられないため、メニュー項目を選択するごとにそのＷｅｂページに付属するアプレットがメモリに読み込まれ蓄積される。ローエンドのＰＣのように個人ユーザ向けに使用される端末では、同一のＷｅｂページを何度も表示することはないので、アプレットの過剰読込によりメモリリソース不足が生じる可能性は少ない。しかし、これに対し、店舗等に設置するブラウザ端末では、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供することがあるため、複数の顧客により同一のＷｅｂページを繰り返し表示されると、アプレットの過剰読込によりメモリリソース不足が生じる可能性が大きい。

ところで、ローエンドのＰＣ上で動作するＷｅｂブラウザには、「戻る」というコントロールボタンが設けられており、ユーザは、戻るボタンをクリックするだけで、１つまたはいくつか前に閲覧したＷｅｂページを、再アクセスを行うことなく閲覧することができる。これに対して、ブラウザ端末上で動作するＷｅｂブラウザには、戻るボタンが設けられていない場合が多い。これは、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供する場合、ブラウザ端末においてアプレットの実行中に戻るボタンがクリックされてしまうと、Ｗｅｂページによるサービスを確実に提供できなくなってしまうからである。例えば、プリントの実行が完了する前に戻るボタンをクリックされてしまうと、プリントが完全に行われず印刷ミスとなる可能性がある。すなわち、店舗にとっては、戻るボタンが利用できない不便よりも、サービス提供の確実性が低下してしまう方が不都合であるため、ブラウザ端末には、あえて戻るボタンが設けられていないのである。

しかしながら、ブラウザ端末上で動作するＷｅｂブラウザにあっては、戻るボタンが設けられていないことから、ＷＷＷサーバの更新の不手際等何らかの原因により、サービス提供に必要なアプレットがＷＷＷサーバ上に存在しない場合、ブラウザ端末が特定の画面を表示したまま停止してしまい、操作不能な状態に陥ることがあった。従業員がこの状態を直ちに見つけて対処できればよいが、多くの場合困難であるし、またできても大変な手間がかかる。この場合、戻るボタンを設ければ、戻るボタンの操作により操作不能な状態に陥ることをとりあえず回避することはできるが、戻るボタンを設けては、上記要因によりサービス提供の確実性が低下してしまう。

そこで、本発明は、このような従来の技術の有する未解決の課題に着目してなされたものであって、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第１の目的としている。さらに、サービス提供の確実性を低下させることなく、アプレットの取得待ち等により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第２の目的としている。

上記目的を達成するために、本発明に記載のメモリ管理装置は、
データを取得するデータ取得手段と、前記データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するメモリ管理システムに適用する装置であって、
前記データ取得手段で取得した特定形式データの取得回数を計数する回数計数手段と、前記回数計数手段の計数結果に基づいて前記メモリ管理システムに前記更新命令を出力する更新命令出力手段とを備えることを特徴とする。

このような構成であれば、メモリ管理システムでは、データ取得手段によりデータが取得されると、メモリ領域割当手段により、取得されたデータのうち特定形式データにスタティックメモリ管理方式によりメモリ領域が割り当てられる。

一方、本発明に記載のメモリ管理装置では、回数計数手段により、データ取得手段で取得された特定形式データの取得回数が計数され、更新命令出力手段により、その計数結果に基づいてメモリ管理システムに更新命令が出力される。

メモリ管理システムでは、更新命令が入力されると、メモリ解放手段により、更新命令に応じて特定形式データに割り当てられたメモリ領域が解放される。

ここで、本発明に記載のメモリ管理装置は、メモリ管理システムと一体に構成されていてもよいし、メモリ管理システムとは別体に構成されていてもよい。前者の場合、例えば、メモリ管理システムに組み込まれるソフトウェアとして構成することができ、後者の場合、例えば、メモリ管理システムが組み込まれたコンピュータがネットワークアクセスに利用するプロキシサーバとして構成することができる。

また、特定形式のデータとしては、実行型のプログラムデータ（例えば、ＪＡＶＡ（登録商標）アプレット）のほか、例えば、画像データ、音声データその他のマルチメディアデータ、またはテキストデータその他の文書データが含まれる。以下、本発明に記載のプロキシサーバ、メモリ管理プログラム、サーバ用プログラム、並びにメモリ管理方法において同じである。

また、回数計数手段は、データ取得手段で取得した特定形式データの取得回数を計数するようになっていればどのような構成であってもよく、より具体的には、特定形式データの取得回数を推定または実測により計数することができる。例えば、メモリ管理システムと一体に構成する場合は、実測により計数すればよいし、メモリ管理システムと別体に構成する場合は、実測が困難なので推定により計数すればよい。以下、本発明に記載のメモリ管理プログラムにおいて同じである。

さらに、本発明に記載のメモリ管理装置は、上記のメモリ管理装置において、
前記特定形式データは、実行型のプログラムデータであることを特徴とする。

このような構成であれば、メモリ管理システムでは、データを受信すると、メモリ領域割当手段により、受信したデータのうちプログラムデータにスタティックメモリ管理方式によりメモリ領域が割り当てられる。

一方、メモリ管理装置では、回数計数手段により、データ取得手段で取得されたデータに基づいてメモリ管理システムへのプログラムデータの送信回数が計数され、更新命令出力手段により、その計数結果に基づいてメモリ管理システムに更新命令が出力される。

メモリ管理システムでは、更新命令を受信すると、メモリ解放手段により、更新命令に応じてプログラムデータに割り当てられたメモリ領域が解放される。

さらに、本発明に記載のメモリ管理装置は、上記のメモリ管理装置において、
前記更新命令出力手段は、前記回数計数手段で計数した送信回数が所定値以上となったときは、前記メモリ管理システムに前記更新命令を出力するようになっていることを特徴とする。

このような構成であれば、メモリ管理装置では、回数計数手段で計数された送信回数が所定値以上となると、更新命令出力手段により、メモリ管理システムに更新命令が出力される。

さらに、本発明に記載のメモリ管理装置は、上記のメモリ管理装置において、
前記データ取得手段で取得したデータに前記特定形式データの取得要求である特定取得要求が含まれていることを検出する特定取得要求検出手段を備え、
前記回数計数手段は、前記特定取得要求検出手段で検出した特定取得要求の個数を計数することにより前記メモリ管理システムへの前記特定形式データの送信回数を計数するようになっていることを特徴とする。

このような構成であれば、メモリ管理装置では、データ取得手段で取得されたデータに特定取得要求が含まれていると、特定取得要求検出手段により、特定取得要求が含まれていることが検出され、回数計数手段により、検出された特定取得要求の個数が計数され、これによりメモリ管理システムへの特定形式データの送信回数が計数される。

さらに、本発明に記載のメモリ管理装置は、上記のメモリ管理装置において、
前記特定取得要求を含むデータには、前記特定取得要求であることを示す要求識別情報をあらかじめ付加しておき、
前記特定取得要求検出手段は、前記データ取得手段で取得したデータから前記要求識別情報を検出することにより当該データに前記特定取得要求が含まれていることを検出するようになっていることを特徴とする。

このような構成であれば、メモリ管理装置では、取得されたデータに要求識別情報が含まれていると、特定取得要求検出手段により、取得されたデータに特定取得要求が含まれていることが検出される。

一方、上記目的を達成するために、本発明に記載のメモリ管理プログラムは、
データを取得するデータ取得手段と、前記データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するコンピュータに実行させるためのプログラムであって、
前記データ取得手段で取得した特定形式データの取得回数を計数する回数計数手段、および前記回数計数手段の計数結果に基づいて前記更新命令を出力する更新命令出力手段として実現される処理を実行させるためのプログラムであることを特徴とする。

このような構成であれば、コンピュータによってプログラムが読み取られ、読み取られたプログラムに従ってコンピュータが処理を実行すると、本発明に記載のメモリ管理装置と同等の作用が得られる。
さらに、本発明に記載のメモリ管理プログラムは、上記のメモリ管理プログラムにおいて、
前記特定形式データは、実行型のプログラムデータであることを特徴とする。
さらに、本発明に記載のメモリ管理プログラムは、上記のメモリ管理プログラムにおいて、
前記更新命令出力手段は、前記回数計数手段で計数した送信回数が所定値以上となったときは、前記更新命令を出力するようになっていることを特徴とする。

一方、上記目的を達成するために、本発明に記載のメモリ管理方法は、
データを取得するデータ取得手段と、前記データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するメモリ管理システムに適用する方法であって、
前記データ取得手段で取得した特定形式データの取得回数を計数する回数計数ステップと、前記回数計数ステップの計数結果に基づいて前記メモリ管理システムに前記更新命令を出力する更新命令出力ステップとを含むことを特徴とする。

ここで、回数計数ステップは、データ取得手段で取得した特定形式データの取得回数を計数できればどのような方法であってもよく、より具体的には、特定形式データの取得回数を推定または実測により計数することができる。例えば、メモリ管理システムと一体に構成する場合は、実測により計数すればよいし、メモリ管理システムと別体に構成する場合は、実測が困難なので推定により計数すればよい。
さらに、本発明に記載のメモリ管理方法は、上記のメモリ管理方法において、
前記特定形式データは、実行型のプログラムデータであることを特徴とする。
さらに、本発明に記載のメモリ管理方法は、上記のメモリ管理方法において、
前記更新命令出力ステップは、前記回数計数ステップで計数した送信回数が所定値以上となったときは、前記メモリ管理システムに前記更新命令を出力するようになっていることを特徴とする。

以下、本発明の実施の形態を図面を参照しながら説明する。図１ないし図９は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法の実施の形態を示す図である。

本実施の形態は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したものである。

まず、本発明を適用するネットワークシステムの構成を図１を参照しながら説明する。図１は、本発明を適用するネットワークシステムの構成を示すブロック図である。

図１において、インターネット１９８には、ＨＴＭＬデータにより構成したＷｅｂページを蓄積する複数のＷＷＷサーバ１００が接続されており、プライベートネットワーク１９９には、特殊用途に特化した複数のブラウザ端末３００と、特殊用途以外の用途にも用いられる複数の通常端末３１０とが接続されている。また、インターネット１９８およびプライベートネットワーク１９９には、ブラウザ端末３００および通常端末３１０とＷＷＷサーバ１００との間でＨＴＴＰ（HyperText Transfer Protocol）その他のプロトコルによりデータ取得を仲介するプロキシサーバ２００が接続されている。

ブラウザ端末３００は、図示しないが、液晶ディスプレイ上にタッチパネルを設けて構成されており、Ｗｅｂブラウザを起動し、タッチパネル上の操作だけでＷｅｂブラウザを利用可能となっている。なお、ブラウザ端末３００上で動作するＷｅｂブラウザは、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行う。また、同Ｗｅｂブラウザには、Ｗｅｂページによるサービスを確実に提供するために、戻るボタンが設けられていない。

ブラウザ端末３００は、組み込まれているＷｅｂブラウザによって「ND-2000」および「ND-3000」の２種類に分類される。「ND-2000」のブラウザ端末３００は、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をすべて１つのタグとして記述した形式（以下、ND-2000形式という。）のＨＴＭＬデータが与えられたときは、そのタグを解読して適切に処理するが、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をそれぞれ１つのタグとして記述した形式（以下、ND-3000形式という。）のＨＴＭＬデータが与えられたときは、それらタグを無視するようになっている。「ND-3000」のブラウザ端末３００は、ND-3000形式のＨＴＭＬデータが与えられたときは、それらタグを解読して適切に処理するが、ND-2000形式のＨＴＭＬデータが与えられたときは、そのタグを無視するようになっている。

次に、プロキシサーバ２００の構成を図２を参照しながら詳細に説明する。図２は、プロキシサーバ２００の構成を示すブロック図である。

プロキシサーバ２００は、図２に示すように、制御プログラムに基づいて演算およびシステム全体を制御するＣＰＵ３０と、所定領域にあらかじめＣＰＵ３０の制御プログラム等を格納しているＲＯＭ３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互にかつデータ授受可能に接続されている。

Ｉ／Ｆ３８には、外部装置として、ヒューマンインターフェースとしてデータの入力が可能なキーボードやマウス等からなる入力装置４０と、データやテーブル等をファイルとして格納する記憶装置４２と、画像信号に基づいて画面を表示する表示装置４４と、インターネット１９８に接続するための信号線と、プライベートネットワーク１９９に接続するための信号線とが接続されている。

記憶装置４２には、図３に示すように、プライベートネットワーク１９９に接続する各端末がアクセスすることのあるＷｅｂページのＵＲＬ（Universal Resource Locater）を登録したアクセス登録テーブル４００が格納されている。図３は、アクセス登録テーブル４００のデータ構造を示す図である。

アクセス登録テーブル４００には、図３に示すように、各ＵＲＬごとに１つのレコードが登録されている。各レコードは、ＵＲＬを登録したフィールド４０２を含んで構成されている。アクセス登録テーブル４００は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、プロキシサーバ２００が参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録するために使用される。これにより、プライベートネットワーク１９９に接続する端末に対する応答速度を向上することができる。

また、記憶装置４２には、図４に示すように、プライベートネットワーク１９９に接続する各端末についてＩＰアドレス、端末識別情報およびアプレットの送信回数を対応付けて登録した端末管理テーブル４２０が格納されている。図４は、端末管理テーブル４２０のデータ構造を示す図である。

端末管理テーブル４２０には、図４に示すように、プライベートネットワーク１９９に接続する各端末ごとに１つのレコードが登録されている。各レコードは、端末に設定されたＩＰアドレスを登録したフィールド４２２と、端末を識別するための端末識別情報を登録したフィールド４２４と、アプレットを端末に送信した回数を登録したフィールド４２６とを含んで構成されている。

図４の例では、第１段目のレコードには、ＩＰアドレスとして「192.168.100.10」が、端末識別情報として「通常端末」が、送信回数として「０」がそれぞれ登録されており、これは、ＩＰアドレス「192.168.100.10」が設定された端末が通常端末３１０であることを意味し、また、その通常端末３１０に対するアプレットの送信回数が「０」回であることを意味している。また、第４段目のレコードには、ＩＰアドレスとして「192.168.101.10」が、端末識別情報として「ブラウザ端末」がそれぞれ登録されており、これは、ＩＰアドレス「192.168.101.10」が設定された端末がブラウザ端末３００であることを意味し、また、そのブラウザ端末３００に対するアプレットの送信回数が「０」回であることを意味している。

また、記憶装置４２には、図５に示すように、Ｗｅｂページのアプレットを管理するアプレット管理テーブル４４０が格納されている。図５は、アプレット管理テーブル４４０のデータ構造を示す図である。

アプレット管理テーブル４４０は、図５に示すように、取得要求に応じてプロキシサーバ２００がＷｅｂページを取得するごとに、１つのレコードが作成されるものである。各レコードは、ＷｅｂページのＵＲＬを登録したフィールド４４２と、そのＷｅｂページが利用するアプレットの個数を登録したフィールド４４４，４５０と、そのＷｅｂページが利用するすべてのアプレットの存在の有無を登録したフィールド４４６，４５２と、そのＷｅｂページが利用する各アプレットについてアプレットが存在するか否かを管理するアプレット存在管理テーブルへのポインタを登録したフィールド４４８，４５４とを含んで構成されている。なお、フィールド４４４〜４４８は、Ｗｅｂページを構成するＨＴＭＬデータの形式がND-2000形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドであり、フィールド４５０〜４５４は、Ｗｅｂページを構成するＨＴＭＬデータの形式がND-3000形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドである。

図５の例では、第１段目のレコードには、ＵＲＬとして「http://www.aaa.com/index.htm」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちND-2000形式に係るものとして、「３」、「０」および「テーブルＡ１」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちND-3000形式に係るものとして、「４」、「０」および「テーブルＡ２」がそれぞれ登録されている。これは、ＵＲＬ「http://www.aaa.com/index.htm」により特定されるＷｅｂページに、アプレットを取得する要求である特定取得要求が７つ含まれており、アプレットが存在するか否かを、ND-2000形式に係るものについてはテーブルＡ１により、ND-3000形式に係るものについてはテーブルＡ２により管理することを意味している。さらに、ND-2000形式に係るアプレットの一部または全部が存在せず、ND-3000形式に係るアプレットの一部または全部が存在しないことを意味している。なお、各Ｗｅｂページには、特定取得要求を確実に検出するため、特定取得要求とともにアプレット識別符号があらかじめ付加されている。

アプレット存在管理テーブル４６０は、図６に示すように、各アプレットごとに１つのレコードが登録されている。各レコードは、アプレット名を登録したフィールド４６２と、アプレットの存在の有無を登録したフィールド４６４とを含んで構成されている。図６は、アプレット存在管理テーブル４６０のデータ構造を示す図である。

図６の例では、第１段目のレコードには、アプレット名として「exe_001」が、アプレット存在の有無として「１」がそれぞれ登録されており、これは、アプレット名「exe_001」により特定されるアプレットが規定のＷＷＷサーバ１００に存在することを意味している。また、第３段目のレコードには、アプレット名として「exe_003」が、アプレット存在の有無として「０」がそれぞれ登録されており、これは、アプレット名「exe_003」により特定されるアプレットが規定のＷＷＷサーバ１００に存在しないことを意味している。

ＣＰＵ３０は、マイクロプロセッシングユニットＭＰＵ等からなり、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図７および図８のフローチャートに示すアプレット存在登録処理およびデータ取得仲介処理を実行するようになっている。

初めに、アプレット存在登録処理を図７を参照しながら詳細に説明する。図７は、アプレット存在登録処理を示すフローチャートである。

アプレット存在登録処理は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、アクセス登録テーブル４００を参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録する処理であって、ＣＰＵ３０において実行されると、図７に示すように、まず、ステップＳ１００に移行するようになっている。

ステップＳ１００では、アクセス登録テーブル４００の先頭レコードからＵＲＬを読み出し、ステップＳ１０２に移行して、読み出したＵＲＬをもとにＷＷＷサーバ１００にアクセスし、ステップＳ１０４に移行して、アクセスしたＷＷＷサーバ１００からＷｅｂページを取得し、ステップＳ１０６に移行する。

ステップＳ１０６では、取得したＷｅｂページを解析し、ステップＳ１０８に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき(Yes)は、ステップＳ１１０に移行する。

ステップＳ１１０では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ１１２に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき(Yes)は、ステップＳ１１４に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録する。なお、この登録は、取得したＷｅｂページを構成するＨＴＭＬデータの形式に応じてそれぞれ行う。以下、ステップＳ１２０，Ｓ２２０，Ｓ２３２において同じである。

次いで、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。

一方、ステップＳ１１２で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき(No)は、ステップＳ１２０に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。

一方、ステップＳ１０８で、アプレット識別符号を検出しないと判定したとき(No)は、ステップＳ１１６に移行して、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了したか否かを判定し、すべてのＵＲＬについて処理が終了したと判定したとき(Yes)は、一連の処理を終了して元の処理に復帰させる。

一方、ステップＳ１１６で、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了しないと判定したとき(No)は、ステップＳ１１８に移行して、アクセス登録テーブル４００の次のレコードからＵＲＬを読み出し、ステップＳ１０２に移行する。

次に、データ取得仲介処理を図８を参照しながら詳細に説明する。図８は、データ仲介処理を示すフローチャートである。

データ取得仲介処理は、ＣＰＵ３０において実行されると、図８に示すように、まず、ステップＳ２００に移行するようになっている。

ステップＳ２００では、ＨＴＴＰによりページの取得要求を受信したか否かを判定し、取得要求を受信したと判定したとき(Yes)は、ステップＳ２０１に移行するが、そうでないと判定したとき(No)は、取得要求を受信するまでステップＳ２００で待機する。

ステップＳ２０１では、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているか否かを判定し、端末管理テーブル４００に登録されていないと判定したとき(No)は、ステップＳ２０２に移行して、取得要求のＨＴＴＰヘッダを解析し、ステップＳ２０４に移行して、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき(Yes)は、ステップＳ２０５に移行する。

ステップＳ２０５では、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２０６に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２０８に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２１０に移行する。

ステップＳ２１０では、取得したＷｅｂページを解析し、ステップＳ２１２に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき(Yes)は、ステップＳ２１４に移行して、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されているか否かを判定し、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていないと判定したとき(No)は、ステップＳ２１６に移行する。

ステップＳ２１６では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２１８に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき(Yes)は、ステップＳ２２０に移行する。

ステップＳ２２０では、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２２２に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を加算し、ステップＳ２２４に移行する。

ステップＳ２２４では、アプレットの送信回数が所定値（例えば、１００回）以上であるか否かを判定し、送信回数が所定値以上であると判定したとき(Yes)は、全画面更新命令を要求元のブラウザ端末３００に送信し、ステップＳ２２８に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を「０」に設定し、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。

一方、ステップＳ２２４で、アプレットの送信回数が所定値未満であると判定したとき(No)は、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。

一方、ステップＳ２１８で、特定要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき(No)は、ステップＳ２３２に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２３４に移行して、アプレットが存在しないことを通知するための差換ページを、取得したＷｅｂページに代えて要求元のブラウザ端末３００に送信し、一連の処理を終了して元の処理に復帰させる。

一方、ステップＳ２１４で、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていると判定したとき(Yes)は、ステップＳ２３６に移行して、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在しないと判定したとき(No)は、ステップＳ２３４に移行する。

一方、ステップＳ２３６で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在すると判定したとき(Yes)は、ステップＳ２２２に移行する。

一方、ステップＳ２１２で、取得したＷｅｂページからアプレット識別符号を検出しないと判定したとき(No)は、ステップＳ２３０に移行して、取得したＷｅｂページを要求元の端末に送信し、一連の処理を終了して元の処理に復帰させる。

一方、ステップＳ２０４で、要求元の端末がブラウザ端末３００でないと判定したとき(No)は、ステップＳ２３８に移行して、取得要求に含まれるＩＰアドレスおよび通常端末３１０であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２４０に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２４２に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２３０に移行する。

一方、ステップＳ２０１で、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていると判定したとき(Yes)は、ステップＳ２４４に移行して、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき(Yes)は、ステップＳ２０６に移行する。

一方、ステップＳ２４４で、要求元の端末がブラウザ端末３００でないと判定したとき(No)は、ステップＳ２４０に移行する。

次に、本実施の形態の動作を図９を参照しながら説明する。図９は、ブラウザ端末３００の表示画面である。

まず、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットが存在するか否かを登録する場合を説明する。

プロキシサーバ２００では、電源が投入されると、アプレット存在登録処理が実行される。アプレット存在登録処理が実行されると、ステップＳ１００〜Ｓ１０４を経て、アクセス登録テーブル４００の先頭レコードからＵＲＬが読み出され、読み出されたＵＲＬをもとにＷＷＷサーバ１００にアクセスされ、そのＷＷＷサーバ１００から該当のＷｅｂページが取得される。

次いで、ステップＳ１０６〜Ｓ１０８を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出され、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ１１４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。これに対し、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ１２０を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。

そして、このような処理がアクセス登録テーブル４００に登録されているすべてのＵＲＬについて行われることにより、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットの存在の有無がプロキシサーバ２００に登録される。

次に、プロキシサーバ２００がデータ取得の仲介を行う場合を説明する。

ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。この取得要求は、ＨＴＴＰパケットとして送信される。

プロキシサーバ２００では、取得要求を受信すると、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていない場合は、ステップＳ２０１〜Ｓ２０４を経て、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、ステップＳ２０５〜Ｓ２０８を経て、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報が端末管理テーブル４００に登録され、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。

そして、ステップＳ２１０，Ｓ２１２を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、取得要求がアプレット管理テーブル４４０に登録されていないと、ステップＳ２１６を経て、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ２２０，Ｓ２２２を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、要求元のブラウザ端末３００についてアプレットの送信回数が加算される。この加算により、アプレットの送信回数が所定値以上となると、ステップＳ２２６，Ｓ２２８，Ｓ２１２，Ｓ２３０を経て、全画面更新命令が要求元のブラウザ端末３００に送信され、アプレットの送信回数が「０」に設定され、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。

ブラウザ端末３００では、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放が行われているので、全画面更新命令を受信すると、アプレットに割り当てたメモリ領域がすべて解放される。したがって、複数のフレームにより構成されたＷｅｂページを表示していても、アプレットに割り当てられていたメモリ領域が一旦解放されるので、メモリリソースが不足し操作不能な状態に陥る可能性を低減することができる。

なお、上記加算の結果により、アプレットの送信回数が所定値以上とならなければ、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。この点については、従来のプロキシサーバと同様の動作である。

一方、上記判定の結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ２３２，Ｓ２３４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。

ブラウザ端末３００では、差換ページを受信すると、図９（ａ）または同図（ｂ）に示すような差換ページが表示される。例えば、ブラウザ端末３００が店舗等に設置して顧客の利用に供するものであれば、顧客は、その表示を見たときに不具合が発生したことが分かるので、従業員を呼ぶ等して適切な対処を行うことができる。したがって、アプレットの実行前に対処することができるので、操作不能な状態に陥る可能性を低減することができる。

次に、他のブラウザ端末３００において上記と同一のＷｅｂページを閲覧する場合、ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。

プロキシサーバ２００では、取得要求を受信すると、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。

そして、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、アプレット存在管理テーブル４６０には、検出されたアプレット識別符号に対応するアプレットが上記処理において登録されているので、ステップＳ２３６，Ｓ２３４を経て、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。

なお、ＨＴＴＰヘッダの解析の結果、要求元の端末が通常端末３１０であると判定された場合、または取得したＷｅｂページにアプレット識別符号が含まれていない場合はいずれも、取得されたＷｅｂページがそのまま要求元の端末に送信される。

このようにして、本実施の形態では、プロキシサーバ２００は、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行うブラウザ端末３００と、複数のＷＷＷサーバ１００とに通信可能に接続し、ブラウザ端末３００からの取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページを要求元のブラウザ端末３００に送信する一方、取得したＷｅｂページに基づいてブラウザ端末３００へのアプレットの送信回数を計数し、その計数結果に基づいて要求元のブラウザ端末３００に全画面更新命令を送信するようになっている。

これにより、アプレットの送信回数に応じてメモリ領域が解放されるので、スタティックメモリ管理方式を採用したブラウザ端末３００において、従来に比して、メモリリソースの不足により操作不能な状態に陥る可能性を低減することができる。

さらに、本実施の形態では、プロキシサーバ２００は、取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページに特定取得要求が含まれているときは、そのＷｅｂページから特定取得要求を検出し、検出した特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、取得したＷｅｂページについて、そのＷｅｂページに含まれる特定取得要求に係るアプレットが存在しないと判定したときは、そのＷｅｂページに代えて、アプレットが存在しない旨の差換ページを要求元の端末に送信するようになっている。

これにより、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しない場合は、要求元の端末が特定取得要求を送信する前に、アプレットが存在しないことを要求元の端末に通知することができるので、ブラウザ端末３００において、従来に比して、操作不能な状態に陥る可能性を低減することができる。また、これを戻るボタンを設けずに実現することができるので、サービス提供の確実性を低下させることもさほどない。

さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページからアプレット識別符号を検出することによりそのＷｅｂページに特定取得要求が含まれていることを検出するようになっている。

これにより、特定取得要求が含まれていることを比較的確実に検出することができる。

さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページに特定取得要求が含まれていることを検出したときは、その特定取得要求が含まれているＷｅｂページを解析し、解析結果に基づいてアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０にアプレットが登録されていないと判定した場合に限り、ＷＷＷサーバ１００にアクセスして特定取得要求に係るアプレットが存在するか否かを判定するようになっている。

これにより、存在するか否かを一度も判定したことのないアプレットについてのみ、ＷＷＷサーバ１００に対してアクセスが行われるので、ＷＷＷサーバ１００にアクセスする回数を低減することができる。

さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、受信した取得要求の解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、ブラウザ端末３００であると判定したときは、特定取得要求の検出およびアプレットの存在確認を行うようになっている。

これにより、ブラウザ端末３００に送信すべきＷｅｂページについてのみ、特定取得要求の検出およびアプレットの存在確認が行われるので、処理負荷を低減することができる。

さらに、本実施の形態では、プロキシサーバ２００は、ブラウザ端末３００からの取得要求を受信する前に、アクセス登録テーブル４００のＵＲＬをもとにＷＷＷサーバ１００にアクセスして該当のアプレットが存在するか否かを判定し、該当のアプレットの存在確認結果を、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録するようになっている。

これにより、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０への登録が取得要求の受信前に行われるので、ブラウザ端末３００に対する応答速度を向上することができる。

さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、取得要求のＨＴＴＰヘッダを解析し、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、判定結果に基づいて端末管理テーブル４００への登録を行う一方、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているときは、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定するようになっている。

これにより、端末管理テーブル４００に一旦登録されると、要求元の端末についてＨＴＴＰヘッダの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。

上記実施の形態において、インターネット１９８およびプライベートネットワーク１９９は、ネットワークに対応し、ＷＷＷサーバ１００、ブラウザ端末３００および通常端末３１０は、ネットワークリソースに対応している。また、記憶装置４２は、記憶手段に対応し、ステップＳ２０６，Ｓ２０８は、サーバ側データ取得手段、またはサーバ側データ取得ステップに対応し、ステップＳ２１０，Ｓ２１２は、特定取得要求検出手段に対応している。

また、上記実施の形態において、ステップＳ２１６，Ｓ２１８は、データ存在判定手段に対応し、ステップＳ２２２は、回数計数手段、または回数計数ステップに対応している。また、ステップＳ２２６は、更新命令出力手段、更新命令送信手段、更新命令出力ステップ、または更新命令送信ステップに対応し、ステップＳ２３０，Ｓ２３４は、データ送信手段、またはデータ送信ステップに対応している。

また、上記実施の形態において、差換ページは、通知データに対応し、全画面更新命令は、更新命令に対応し、アプレットは、特定形式データ、または実行型のプログラムデータに対応している。また、アプレット識別符号は、要求識別情報に対応し、ＵＲＬは、データ識別情報、または取得先アドレスに対応し、ＩＰアドレスは、ネットワークリソース識別情報に対応している。

なお、上記実施の形態において、プロキシサーバ２００は、ステップＳ１０６，Ｓ２１０で、取得したＷｅｂページを常に解析するように構成したが、これに限らず、取得したＷｅｂページのＵＲＬがアプレット管理テーブル４４０に登録されているか否かを判定し、アプレット管理テーブル４４０に登録されていると判定したときは、Ｗｅｂページの解析を省略するように構成してもよい。

これにより、アプレット管理テーブル４４０に一旦登録されると、Ｗｅｂページの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。

また、上記実施の形態においては、図６に示すアプレット存在管理テーブル４６０をＷｅｂページごと複数設けて構成したが、これに限らず、それら複数のアプレット存在管理テーブル４６０を一つのテーブルとして構成してもよい。これにより、検索の高速化を図ることができる。

また、上記実施の形態においては、取得要求に含まれるＩＰアドレスにより要求元の端末を識別するように構成したが、これに限らず、クッキー（Cookie）によって送受信されるユーザ情報等により要求元の端末を識別するように構成することもできる。

また、上記実施の形態において、図７および図８のフローチャートに示す処理を実行するにあたってはいずれも、ＲＯＭ３２にあらかじめ格納されている制御プログラムを実行する場合について説明したが、これに限らず、これらの手順を示したプログラムが記憶された記憶媒体から、そのプログラムをＲＡＭ３４に読み込んで実行するようにしてもよい。

ここで、記憶媒体とは、ＲＡＭ、ＲＯＭ等の半導体記憶媒体、ＦＤ、ＨＤ等の磁気記憶型記憶媒体、ＣＤ、ＣＤＶ、ＬＤ、ＤＶＤ等の光学的読取方式記憶媒体、ＭＯ等の磁気記憶型／光学的読取方式記憶媒体であって、電子的、磁気的、光学的等の読み取り方法のいかんにかかわらず、コンピュータで読み取り可能な記憶媒体であれば、あらゆる記憶媒体を含むものである。

また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、インターネット１９８からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９８と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９８と同一方式により通信を行うネットワークに限らず、通常のネットワークに適用することもできる。

また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したが、これに限らず、本発明の主旨を逸脱しない範囲で他の場合にも適用可能である。例えば、プロキシサーバ２００が実現する処理をブラウザ端末３００に組み込むソフトウェアとして構成することもできる。

本発明を適用するネットワークシステムの構成を示すブロック図である。 プロキシサーバ２００の構成を示すブロック図である。 アクセス登録テーブル４００のデータ構造を示す図である。 端末管理テーブル４２０のデータ構造を示す図である。 アプレット管理テーブル４４０のデータ構造を示す図である。 アプレット存在管理テーブル４６０のデータ構造を示す図である。 アプレット存在登録処理を示すフローチャートである。 データ仲介処理を示すフローチャートである。 ブラウザ端末３００の表示画面である。

符号の説明

１００ ＷＷＷサーバ
１９８ インターネット
３００ ブラウザ端末
３１０ 通常端末
１９９ プライベートネットワーク
２００ プロキシサーバ
３０ ＣＰＵ
３２ ＲＯＭ
３４ ＲＡＭ
３８ Ｉ／Ｆ
４０ 入力装置
４２ 記憶装置
４４ 表示装置
４００ アクセス登録テーブル
４２０ 端末管理テーブル
４４０ アプレット管理テーブル
４６０ アプレット存在管理テーブル

Claims (3)

1. データを取得するデータ取得手段と、
   前記データ取得手段で取得したデータのうち特定形式のデータにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、
   更新命令に応じて前記特定形式のデータに割り当てたメモリ領域を解放するメモリ領域解放手段と、
   前記データ取得手段で取得した特定形式のデータの取得回数を計数する回数計数手段と、
   前記回数計数手段の計数結果に基づいて前記更新命令を出力する更新命令出力手段と、を有し、
   前記データ取得手段と、前記メモリ領域割当手段と、前記メモリ領域開放手段と、前記回数係数手段と、前記更新命令出力手段とが、一体に構成されていることを特徴とするメモリ管理システム。
2. ネットワークを介して接続される端末とサーバとを有するネットワークシステムであって、
   前記ネットワークを介してデータを取得するデータ取得手段と、
   前記データ取得手段で取得したデータのうち特定形式のデータにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、
   前記ネットワークを介して受信する更新命令に応じて前記特定形式のデータに割り当てたメモリ領域を解放するメモリ領域解放手段と、
   を有する端末と、
   前記データ取得手段で取得した特定形式のデータの取得回数を計数する回数計数手段と、
   前記回数計数手段の計数結果に基づいて前記ネットワークを介して前記端末に前記更新命令を出力する更新命令出力手段と、
   を有するサーバと、
   を有することを特徴とするネットワークシステム。
3. ブラウザ端末とプロキシサーバとを有するネットワークシステムであって、
   前記プロキシサーバからデータを取得する端末側データ取得手段と、
   前記端末側データ取得手段で取得したデータのうち特定形式のデータにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、
   更新命令に応じて前記特定形式のデータに割り当てたメモリ領域を解放するメモリ領域解放手段と、
   前記データの取得要求を前記プロキシサーバに送信する送信手段と、
   を有するブラウザ端末と、
   前記取得要求に応じて前記ブラウザ端末とは異なる他のネットワークリソースから前記データを取得するサーバ側データ取得手段と、
   前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段と、
   前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式のデータの送信回数を計数する回数計数手段と、
   前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段と、
   を有するプロキシサーバと、
   を有することを特徴とするネットワークシステム。

Images