JP3613247B2 - プロキシサーバ、サーバ用プログラム及びメモリ管理方法 - Google Patents
プロキシサーバ、サーバ用プログラム及びメモリ管理方法 Download PDFInfo
- Publication number
- JP3613247B2 JP3613247B2 JP2002034713A JP2002034713A JP3613247B2 JP 3613247 B2 JP3613247 B2 JP 3613247B2 JP 2002034713 A JP2002034713 A JP 2002034713A JP 2002034713 A JP2002034713 A JP 2002034713A JP 3613247 B2 JP3613247 B2 JP 3613247B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- acquisition request
- acquisition
- specific
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
- Memory System (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一のネットワークリソースと他のネットワークリソースとの間でデータの取得を仲介する装置、サーバおよびプログラム、並びに方法に係り、特に、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法に関する。
【０００２】
【従来の技術】
Ｗｅｂベースの技術の浸透に伴い、ユーザインターフェースとしてＷｅｂブラウザを用い、アプリケーション本体はＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバで稼働させるような、いわゆるシンクライアント型のシステムが利用されるようになってきている。このとき、ＷＷＷサーバからクライアントに送られる情報は、フォームを含むＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データであり、クライアントの端末では、Ｗｅｂブラウザさえ動けば、実行に先立って特にアプリケーションの配布・インストール等の作業を行うことなく、アプリケーションを実行させることができるようになる。また、一般的には、クライアント側でアプリケーションを実行するのに比して、クライアント側はより処理能力の低いハードウエアで運用することができる。
【０００３】
従来、このようなクライアント端末には、ローエンドのＰＣが用いられてきた。しかし、最近では、店舗等に設置して顧客に気軽に使用してもらうことを目的としたものとして、液晶ディスプレイ上にタッチパネルを設け、タッチパネル上の操作だけで利用することができるブラウザ端末も開発され、そのようなブラウザ端末上でもＷｅｂブラウザが動作するようになってきている。
【０００４】
【発明が解決しようとする課題】
このようなブラウザ端末は、ローエンドのＰＣと異なり、省電力化、低コスト化および省スペース化等を図るために、ＣＰＵの処理能力が低く、メモリリソースも少なく設計されているのが通常である。そのため、ブラウザ端末に組み込むＷｅｂブラウザでは、ＪＡＶＡ（登録商標）アプレット（以下、単にアプレットという。）を実行するにあたり、アプレットに割り当てるメモリ領域を管理する方法として、ＣＰＵ負荷が少なくかつメモリ効率に優れたスタティックメモリ管理方式が採用されている。
【０００５】
スタティックメモリ管理方式は、１つのＷｅｂページをテーブルにより管理し、テーブルがリセットされるまでは、Ｗｅｂページに付属するアプレットを読み込むたびに未使用のメモリ領域を順次割り当てていく方式である。テーブルのリセットタイミングは、そのＷｅｂページをリロードすべき更新命令が与えられたときである。
【０００６】
しかしながら、スタティックメモリ管理方式にあっては、複数のフレームにより構成されたＷｅｂページを表示する場合は、ユーザの操作によっては更新命令が与えられないまま、そのＷｅｂページに付属するアプレットが次々と読み込まれ、メモリリソースが不足し操作不能な状態に陥る可能性があった。例えば、メニュー項目の一覧を表示するメニューフレームと、メニューフレームのメニュー項目に対応する内容を表示するコンテンツフレームにより構成されたＷｅｂページを、ユーザが各メニュー項目を選択しながら一つ一つのメニュー内容を表示する場合、メニュー項目を選択するごとにコンテンツフレームのＷｅｂページは更新されるが、コンテンツフレームの更新だけでは全体のＷｅｂページについて更新命令が与えられないため、メニュー項目を選択するごとにそのＷｅｂページに付属するアプレットがメモリに読み込まれ蓄積される。ローエンドのＰＣのように個人ユーザ向けに使用される端末では、同一のＷｅｂページを何度も表示することはないので、アプレットの過剰読込によりメモリリソース不足が生じる可能性は少ない。しかし、これに対し、店舗等に設置するブラウザ端末では、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供することがあるため、複数の顧客により同一のＷｅｂページを繰り返し表示されると、アプレットの過剰読込によりメモリリソース不足が生じる可能性が大きい。
【０００７】
ところで、ローエンドのＰＣ上で動作するＷｅｂブラウザには、「戻る」というコントロールボタンが設けられており、ユーザは、戻るボタンをクリックするだけで、１つまたはいくつか前に閲覧したＷｅｂページを、再アクセスを行うことなく閲覧することができる。これに対して、ブラウザ端末上で動作するＷｅｂブラウザには、戻るボタンが設けられていない場合が多い。これは、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供する場合、ブラウザ端末においてアプレットの実行中に戻るボタンがクリックされてしまうと、Ｗｅｂページによるサービスを確実に提供できなくなってしまうからである。例えば、プリントの実行が完了する前に戻るボタンをクリックされてしまうと、プリントが完全に行われず印刷ミスとなる可能性がある。すなわち、店舗にとっては、戻るボタンが利用できない不便よりも、サービス提供の確実性が低下してしまう方が不都合であるため、ブラウザ端末には、あえて戻るボタンが設けられていないのである。
【０００８】
しかしながら、ブラウザ端末上で動作するＷｅｂブラウザにあっては、戻るボタンが設けられていないことから、ＷＷＷサーバの更新の不手際等何らかの原因により、サービス提供に必要なアプレットがＷＷＷサーバ上に存在しない場合、ブラウザ端末が特定の画面を表示したまま停止してしまい、操作不能な状態に陥ることがあった。従業員がこの状態を直ちに見つけて対処できればよいが、多くの場合困難であるし、またできても大変な手間がかかる。この場合、戻るボタンを設ければ、戻るボタンの操作により操作不能な状態に陥ることをとりあえず回避することはできるが、戻るボタンを設けては、上記要因によりサービス提供の確実性が低下してしまう。
【０００９】
そこで、本発明は、このような従来の技術の有する未解決の課題に着目してなされたものであって、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第１の目的としている。さらに、サービス提供の確実性を低下させることなく、アプレットの取得待ち等により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第２の目的としている。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明に記載のプロキシサーバは、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバであって、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段と、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段と、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段と、前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段とを備えることを特徴とする。
【００１５】
このような構成であれば、ブラウザ端末では、ネットワークリソースにアクセスする場合、端末側データ取得手段により、プロキシサーバに取得要求が送信される。
プロキシサーバでは、取得要求を受信すると、サーバ側データ取得手段により、取得要求に応じてネットワークリソースからデータが取得され、データ送信手段により、取得されたデータがブラウザ端末に送信される。
【００１６】
ブラウザ端末では、データを受信すると、メモリ領域割当手段により、受信したデータのうち特定形式データにスタティックメモリ管理方式によりメモリ領域が割り当てられる。
一方、プロキシサーバでは、回数計数手段により、サーバ側データ取得手段で取得されたデータに基づいてブラウザ端末への特定形式データの送信回数が計数され、更新命令送信手段により、その計数結果に基づいてブラウザ端末に更新命令が送信される。
【００１７】
ブラウザ端末では、更新命令を受信すると、メモリ解放手段により、更新命令に応じて特定形式データに割り当てられたメモリ領域が解放される。
また、特定形式のデータとしては、実行型のプログラムデータ（例えば、ＪＡＶＡ（登録商標）アプレット）のほか、例えば、画像データ、音声データその他のマルチメディアデータ、またはテキストデータその他の文書データが含まれる。以下、本発明に記載のプロキシサーバ、サーバ用プログラム、並びにメモリ管理方法において同じである。
また、回数計数手段は、データ取得手段で取得した特定形式データの取得回数を計数するようになっていればどのような構成であってもよく、より具体的には、特定形式データの取得回数を推定または実測により計数することができる。以下、本発明に記載のメモリ管理プログラムにおいて同じである。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、前記特定形式データは、実行型のプログラムデータであることを特徴とする。
【００１８】
このような構成であれば、ブラウザ端末では、データを受信すると、メモリ領域割当手段により、受信したデータのうちプログラムデータにスタティックメモリ管理方式によりメモリ領域が割り当てられる。
一方、プロキシサーバでは、回数計数手段により、サーバ側データ取得手段で取得されたデータに基づいてブラウザ端末へのプログラムデータの送信回数が計数され、更新命令送信手段により、その計数結果に基づいてブラウザ端末に更新命令が送信される。
【００１９】
ブラウザ端末では、更新命令を受信すると、メモリ解放手段により、更新命令に応じてプログラムデータに割り当てられたメモリ領域が解放される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記更新命令送信手段は、前記回数計数手段で計数した送信回数が所定値以上となったときは、前記ブラウザ端末に前記更新命令を送信するようになっていることを特徴とする。
【００２０】
このような構成であれば、プロキシサーバでは、回数計数手段で計数された送信回数が所定値以上となると、更新命令送信手段により、ブラウザ端末に更新命令が送信される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記サーバ側データ取得手段で取得したデータに前記特定形式データの取得要求である特定取得要求が含まれていることを検出する特定取得要求検出手段を備え、
前記回数計数手段は、前記特定取得要求検出手段で検出した特定取得要求の個数を計数することにより前記ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とする。
【００２１】
このような構成であれば、プロキシサーバでは、サーバ側データ取得手段で取得されたデータに特定取得要求が含まれていると、特定取得要求検出手段により、特定取得要求が含まれていることが検出され、回数計数手段により、検出された特定取得要求の個数が計数され、これによりブラウザ端末への特定形式データの送信回数が計数される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記特定取得要求を含むデータには、前記特定取得要求であることを示す要求識別情報をあらかじめ付加しておき、
前記特定取得要求検出手段は、前記サーバ側データ取得手段で取得したデータから前記要求識別情報を検出することにより当該データに前記特定取得要求が含まれていることを検出するようになっていることを特徴とする。
【００２２】
このような構成であれば、プロキシサーバでは、取得されたデータに要求識別情報が含まれていると、特定取得要求検出手段により、取得されたデータに特定取得要求が含まれていることが検出される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により前記ブラウザ端末を識別するようになっていることを特徴とする。
【００２３】
このような構成であれば、プロキシサーバでは、ネットワークリソース識別情報を含む取得要求を受信すると、受信した取得要求からネットワークリソース識別情報が取得される。そして、取得されたネットワークリソース識別情報によりブラウザ端末が識別される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソース識別情報は、ＩＰアドレスであることを特徴とする。
【００２４】
このような構成であれば、プロキシサーバでは、ＩＰアドレスを含む取得要求を受信すると、受信した取得要求からＩＰアドレスが取得される。そして、取得されたＩＰアドレスによりブラウザ端末が識別される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
複数の前記ブラウザ端末と通信可能に接続し、
前記回数計数手段は、前記各ブラウザ端末ごとに、当該ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とする。
【００２５】
このような構成であれば、プロキシサーバでは、回数計数手段により、各ブラウザ端末ごとに、そのブラウザ端末への特定形式データの送信回数が計数される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記回数計数手段は、前記更新命令送信手段で前記更新命令を前記ブラウザ端末に送信したときは、当該ブラウザ端末への前記特定形式データの送信回数を初期化するようになっていることを特徴とする。
【００２６】
このような構成であれば、プロキシサーバでは、更新命令送信手段で更新命令がブラウザ端末に送信されると、そのブラウザ端末への特定形式データの送信回数が初期化される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記特定取得要求検出手段の検出結果に基づいて前記特定取得要求に係る特定形式データが取得先のネットワークリソースに存在するか否かを判定するデータ存在判定手段を備え、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、前記特定形式データが存在しない旨の通知を行うようになっていることを特徴とする。
【００２７】
このような構成であれば、プロキシサーバでは、データ存在判定手段により、特定取得要求検出手段の検出結果に基づいて特定取得要求に係る特定形式データが取得先のネットワークリソースに存在するか否かが判定される。その結果、特定形式データが存在しないと判定されると、データ送信手段により、特定形式データが存在しない旨の通知が行われる。
【００２８】
ここで、特定形式データが存在しない旨の通知は、ブラウザ端末に対して行うに限らず、ブラウザ端末を管理する管理端末に対して行うようにしてもよい。この場合、特定形式データが存在しない旨は、イベントログとして通知するようにしてもよい。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、当該データに代えて、前記特定形式データが存在しない旨の通知データを前記ブラウザ端末に送信するようになっていることを特徴とする。
【００２９】
このような構成であれば、プロキシサーバでは、特定形式データが存在しないと判定されると、データ送信手段により、そのデータに代えて、特定形式データが存在しない旨の通知データがブラウザ端末に送信される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記データ存在判定手段は、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定したときは、当該特定形式データを識別するためのデータ識別情報および当該特定形式データの取得先アドレスを対応付けて記憶手段に登録し、
前記特定取得要求検出手段で前記特定取得要求が含まれていることを検出したときは、当該特定取得要求が含まれているデータから前記データ識別情報および前記取得先アドレスを取得し、取得したデータ識別情報および取得先アドレスが前記記憶手段に登録されていないときは、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定するようになっていることを特徴とする。
【００３０】
このような構成であれば、プロキシサーバでは、データ存在判定手段により、取得先のネットワークリソースにアクセスして特定取得要求に係る特定形式データが存在するか否かが判定されると、その特定形式データについてデータ識別情報および取得先アドレスが対応付けられて記憶手段に登録される。
一方、特定取得要求が含まれていることが検出されると、データ存在判定手段により、その特定取得要求が含まれているデータからデータ識別情報および取得先アドレスが取得される。そして、取得されたデータ識別情報および取得先アドレスが記憶手段に登録されていないと、取得先のネットワークリソースにアクセスして特定取得要求に係る特定形式データが存在するか否かが判定される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記記憶手段には、前記ブラウザ端末がアクセスすることのある特定形式データごとに前記取得先アドレスを登録したアクセス登録テーブルを記憶させておき、
前記データ存在判定手段は、前記ブラウザ端末からの取得要求を受信する前に、前記アクセス登録テーブルの取得先アドレスをもとに前記ネットワークリソースにアクセスして該当の特定形式データが存在するか否かを判定し、当該特定形式データを識別するためのデータ識別情報および当該特定形式データの取得先アドレスを対応付けて前記記憶手段に登録するようになっていることを特徴とする。
【００３１】
このような構成であれば、プロキシサーバでは、ブラウザ端末からの取得要求を受信する前に、データ存在判定手段により、アクセス登録テーブルの取得先アドレスをもとにネットワークリソースにアクセスされて該当の特定形式データが存在するか否かが判定され、その特定形式データを識別するためのデータ識別情報およびその特定形式データの取得先アドレスが対応付けて記憶手段に登録される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により特定されるネットワークリソースが前記ブラウザ端末であると判定したときは、前記特定取得要求検出手段による検出および前記データ存在判定手段による判定を行うようになっていることを特徴とする。
【００３２】
このような構成であれば、プロキシサーバでは、ネットワークリソース識別情報を含む取得要求を受信すると、受信した取得要求からネットワークリソース識別情報が取得される。そして、取得されたネットワークリソース識別情報により特定されるネットワークリソースがブラウザ端末であると判定されると、特定取得要求検出手段による検出およびデータ存在判定手段による判定が行われる。
【００３３】
一方、上記目的を達成するために、本発明に記載のサーバ用プログラムは、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバとして用いるコンピュータに、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段、および前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段として実現される処理を実行させるためのプログラムであることを特徴とする。
【００３４】
このような構成であれば、コンピュータによってプログラムが読み取られ、読み取られたプログラムに従ってコンピュータが処理を実行すると、本発明に記載のプロキシサーバと同等の作用が得られる。
【００３５】
さらに、本発明に記載のサーバのメモリ管理方法は、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバのメモリ管理方法であって、
前記取得要求に応じてＣＰＵが前記ネットワークリソースからデータを取得するサーバ側データ取得ステップと、前記ＣＰＵが前記サーバ側データ取得ステップで取得したデータを前記ブラウザ端末に送信するデータ送信ステップと、前記サーバ側データ取得ステップで取得したデータに基づいて前記ＣＰＵが前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数ステップと、前記回数計数ステップの計数結果に基づいて前記ＣＰＵが前記ブラウザ端末に前記更新命令を送信する更新命令送信ステップとを含むことを特徴とする。
【００３６】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しながら説明する。図１ないし図９は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法の実施の形態を示す図である。
本実施の形態は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したものである。
【００３７】
まず、本発明を適用するネットワークシステムの構成を図１を参照しながら説明する。図１は、本発明を適用するネットワークシステムの構成を示すブロック図である。
図１において、インターネット１９８には、ＨＴＭＬデータにより構成したＷｅｂページを蓄積する複数のＷＷＷサーバ１００が接続されており、プライベートネットワーク１９９には、特殊用途に特化した複数のブラウザ端末３００と、特殊用途以外の用途にも用いられる複数の通常端末３１０とが接続されている。また、インターネット１９８およびプライベートネットワーク１９９には、ブラウザ端末３００および通常端末３１０とＷＷＷサーバ１００との間でＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）その他のプロトコルによりデータ取得を仲介するプロキシサーバ２００が接続されている。
【００３８】
ブラウザ端末３００は、図示しないが、液晶ディスプレイ上にタッチパネルを設けて構成されており、Ｗｅｂブラウザを起動し、タッチパネル上の操作だけでＷｅｂブラウザを利用可能となっている。なお、ブラウザ端末３００上で動作するＷｅｂブラウザは、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行う。また、同Ｗｅｂブラウザには、Ｗｅｂページによるサービスを確実に提供するために、戻るボタンが設けられていない。
【００３９】
ブラウザ端末３００は、組み込まれているＷｅｂブラウザによって「ＮＤ−２０００」および「ＮＤ−３０００」の２種類に分類される。「ＮＤ−２０００」のブラウザ端末３００は、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をすべて１つのタグとして記述した形式（以下、ＮＤ−２０００形式という。）のＨＴＭＬデータが与えられたときは、そのタグを解読して適切に処理するが、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をそれぞれ１つのタグとして記述した形式（以下、ＮＤ−３０００形式という。）のＨＴＭＬデータが与えられたときは、それらタグを無視するようになっている。「ＮＤ−３０００」のブラウザ端末３００は、ＮＤ−３０００形式のＨＴＭＬデータが与えられたときは、それらタグを解読して適切に処理するが、ＮＤ−２０００形式のＨＴＭＬデータが与えられたときは、そのタグを無視するようになっている。
【００４０】
次に、プロキシサーバ２００の構成を図２を参照しながら詳細に説明する。図２は、プロキシサーバ２００の構成を示すブロック図である。
プロキシサーバ２００は、図２に示すように、制御プログラムに基づいて演算およびシステム全体を制御するＣＰＵ３０と、所定領域にあらかじめＣＰＵ３０の制御プログラム等を格納しているＲＯＭ３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互にかつデータ授受可能に接続されている。
【００４１】
Ｉ／Ｆ３８には、外部装置として、ヒューマンインターフェースとしてデータの入力が可能なキーボードやマウス等からなる入力装置４０と、データやテーブル等をファイルとして格納する記憶装置４２と、画像信号に基づいて画面を表示する表示装置４４と、インターネット１９８に接続するための信号線と、プライベートネットワーク１９９に接続するための信号線とが接続されている。
【００４２】
記憶装置４２には、図３に示すように、プライベートネットワーク１９９に接続する各端末がアクセスすることのあるＷｅｂページのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）を登録したアクセス登録テーブル４００が格納されている。図３は、アクセス登録テーブル４００のデータ構造を示す図である。
アクセス登録テーブル４００には、図３に示すように、各ＵＲＬごとに１つのレコードが登録されている。各レコードは、ＵＲＬを登録したフィールド４０２を含んで構成されている。アクセス登録テーブル４００は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、プロキシサーバ２００が参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録するために使用される。これにより、プライベートネットワーク１９９に接続する端末に対する応答速度を向上することができる。
【００４３】
また、記憶装置４２には、図４に示すように、プライベートネットワーク１９９に接続する各端末についてＩＰアドレス、端末識別情報およびアプレットの送信回数を対応付けて登録した端末管理テーブル４２０が格納されている。図４は、端末管理テーブル４２０のデータ構造を示す図である。
端末管理テーブル４２０には、図４に示すように、プライベートネットワーク１９９に接続する各端末ごとに１つのレコードが登録されている。各レコードは、端末に設定されたＩＰアドレスを登録したフィールド４２２と、端末を識別するための端末識別情報を登録したフィールド４２４と、アプレットを端末に送信した回数を登録したフィールド４２６とを含んで構成されている。
【００４４】
図４の例では、第１段目のレコードには、ＩＰアドレスとして「１９２．１６８．１００．１０」が、端末識別情報として「通常端末」が、送信回数として「０」がそれぞれ登録されており、これは、ＩＰアドレス「１９２．１６８．１００．１０」が設定された端末が通常端末３１０であることを意味し、また、その通常端末３１０に対するアプレットの送信回数が「０」回であることを意味している。また、第４段目のレコードには、ＩＰアドレスとして「１９２．１６８．１０１．１０」が、端末識別情報として「ブラウザ端末」がそれぞれ登録されており、これは、ＩＰアドレス「１９２．１６８．１０１．１０」が設定された端末がブラウザ端末３００であることを意味し、また、そのブラウザ端末３００に対するアプレットの送信回数が「０」回であることを意味している。
【００４５】
また、記憶装置４２には、図５に示すように、Ｗｅｂページのアプレットを管理するアプレット管理テーブル４４０が格納されている。図５は、アプレット管理テーブル４４０のデータ構造を示す図である。
アプレット管理テーブル４４０は、図５に示すように、取得要求に応じてプロキシサーバ２００がＷｅｂページを取得するごとに、１つのレコードが作成されるものである。各レコードは、ＷｅｂページのＵＲＬを登録したフィールド４４２と、そのＷｅｂページが利用するアプレットの個数を登録したフィールド４４４，４５０と、そのＷｅｂページが利用するすべてのアプレットの存在の有無を登録したフィールド４４６，４５２と、そのＷｅｂページが利用する各アプレットについてアプレットが存在するか否かを管理するアプレット存在管理テーブルへのポインタを登録したフィールド４４８，４５４とを含んで構成されている。なお、フィールド４４４〜４４８は、Ｗｅｂページを構成するＨＴＭＬデータの形式がＮＤ−２０００形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドであり、フィールド４５０〜４５４は、Ｗｅｂページを構成するＨＴＭＬデータの形式がＮＤ−３０００形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドである。
【００４６】
図５の例では、第１段目のレコードには、ＵＲＬとして「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍ」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちＮＤ−２０００形式に係るものとして、「３」、「０」および「テーブルＡ１」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちＮＤ−３０００形式に係るものとして、「４」、「０」および「テーブルＡ２」がそれぞれ登録されている。これは、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍ」により特定されるＷｅｂページに、アプレットを取得する要求である特定取得要求が７つ含まれており、アプレットが存在するか否かを、ＮＤ−２０００形式に係るものについてはテーブルＡ１により、ＮＤ−３０００形式に係るものについてはテーブルＡ２により管理することを意味している。さらに、ＮＤ−２０００形式に係るアプレットの一部または全部が存在せず、ＮＤ−３０００形式に係るアプレットの一部または全部が存在しないことを意味している。なお、各Ｗｅｂページには、特定取得要求を確実に検出するため、特定取得要求とともにアプレット識別符号があらかじめ付加されている。
【００４７】
アプレット存在管理テーブル４６０は、図６に示すように、各アプレットごとに１つのレコードが登録されている。各レコードは、アプレット名を登録したフィールド４６２と、アプレットの存在の有無を登録したフィールド４６４とを含んで構成されている。図６は、アプレット存在管理テーブル４６０のデータ構造を示す図である。
【００４８】
図６の例では、第１段目のレコードには、アプレット名として「ｅｘｅ＿００１」が、アプレット存在の有無として「１」がそれぞれ登録されており、これは、アプレット名「ｅｘｅ＿００１」により特定されるアプレットが規定のＷＷＷサーバ１００に存在することを意味している。また、第３段目のレコードには、アプレット名として「ｅｘｅ＿００３」が、アプレット存在の有無として「０」がそれぞれ登録されており、これは、アプレット名「ｅｘｅ＿００３」により特定されるアプレットが規定のＷＷＷサーバ１００に存在しないことを意味している。
【００４９】
ＣＰＵ３０は、マイクロプロセッシングユニットＭＰＵ等からなり、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図７および図８のフローチャートに示すアプレット存在登録処理およびデータ取得仲介処理を実行するようになっている。
初めに、アプレット存在登録処理を図７を参照しながら詳細に説明する。図７は、アプレット存在登録処理を示すフローチャートである。
【００５０】
アプレット存在登録処理は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、アクセス登録テーブル４００を参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録する処理であって、ＣＰＵ３０において実行されると、図７に示すように、まず、ステップＳ１００に移行するようになっている。
【００５１】
ステップＳ１００では、アクセス登録テーブル４００の先頭レコードからＵＲＬを読み出し、ステップＳ１０２に移行して、読み出したＵＲＬをもとにＷＷＷサーバ１００にアクセスし、ステップＳ１０４に移行して、アクセスしたＷＷＷサーバ１００からＷｅｂページを取得し、ステップＳ１０６に移行する。
ステップＳ１０６では、取得したＷｅｂページを解析し、ステップＳ１０８に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき（Ｙｅｓ）は、ステップＳ１１０に移行する。
【００５２】
ステップＳ１１０では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ１１２に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき（Ｙｅｓ）は、ステップＳ１１４に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録する。なお、この登録は、取得したＷｅｂページを構成するＨＴＭＬデータの形式に応じてそれぞれ行う。以下、ステップＳ１２０，Ｓ２２０，Ｓ２３２において同じである。
【００５３】
次いで、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００５４】
一方、ステップＳ１１２で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき（Ｎｏ）は、ステップＳ１２０に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００５５】
一方、ステップＳ１０８で、アプレット識別符号を検出しないと判定したとき（Ｎｏ）は、ステップＳ１１６に移行して、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了したか否かを判定し、すべてのＵＲＬについて処理が終了したと判定したとき（Ｙｅｓ）は、一連の処理を終了して元の処理に復帰させる。
【００５６】
一方、ステップＳ１１６で、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了しないと判定したとき（Ｎｏ）は、ステップＳ１１８に移行して、アクセス登録テーブル４００の次のレコードからＵＲＬを読み出し、ステップＳ１０２に移行する。
次に、データ取得仲介処理を図８を参照しながら詳細に説明する。図８は、データ仲介処理を示すフローチャートである。
【００５７】
データ取得仲介処理は、ＣＰＵ３０において実行されると、図８に示すように、まず、ステップＳ２００に移行するようになっている。
ステップＳ２００では、ＨＴＴＰによりページの取得要求を受信したか否かを判定し、取得要求を受信したと判定したとき（Ｙｅｓ）は、ステップＳ２０１に移行するが、そうでないと判定したとき（Ｎｏ）は、取得要求を受信するまでステップＳ２００で待機する。
【００５８】
ステップＳ２０１では、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているか否かを判定し、端末管理テーブル４００に登録されていないと判定したとき（Ｎｏ）は、ステップＳ２０２に移行して、取得要求のＨＴＴＰヘッダを解析し、ステップＳ２０４に移行して、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき（Ｙｅｓ）は、ステップＳ２０５に移行する。
【００５９】
ステップＳ２０５では、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２０６に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２０８に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２１０に移行する。
【００６０】
ステップＳ２１０では、取得したＷｅｂページを解析し、ステップＳ２１２に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき（Ｙｅｓ）は、ステップＳ２１４に移行して、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されているか否かを判定し、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていないと判定したとき（Ｎｏ）は、ステップＳ２１６に移行する。
【００６１】
ステップＳ２１６では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２１８に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき（Ｙｅｓ）は、ステップＳ２２０に移行する。
ステップＳ２２０では、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２２２に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を加算し、ステップＳ２２４に移行する。
【００６２】
ステップＳ２２４では、アプレットの送信回数が所定値（例えば、１００回）以上であるか否かを判定し、送信回数が所定値以上であると判定したとき（Ｙｅｓ）は、全画面更新命令を要求元のブラウザ端末３００に送信し、ステップＳ２２８に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を「０」に設定し、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００６３】
一方、ステップＳ２２４で、アプレットの送信回数が所定値未満であると判定したとき（Ｎｏ）は、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００６４】
一方、ステップＳ２１８で、特定要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき（Ｎｏ）は、ステップＳ２３２に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２３４に移行して、アプレットが存在しないことを通知するための差換ページを、取得したＷｅｂページに代えて要求元のブラウザ端末３００に送信し、一連の処理を終了して元の処理に復帰させる。
【００６５】
一方、ステップＳ２１４で、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていると判定したとき（Ｙｅｓ）は、ステップＳ２３６に移行して、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在しないと判定したとき（Ｎｏ）は、ステップＳ２３４に移行する。
【００６６】
一方、ステップＳ２３６で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在すると判定したとき（Ｙｅｓ）は、ステップＳ２２２に移行する。
一方、ステップＳ２１２で、取得したＷｅｂページからアプレット識別符号を検出しないと判定したとき（Ｎｏ）は、ステップＳ２３０に移行して、取得したＷｅｂページを要求元の端末に送信し、一連の処理を終了して元の処理に復帰させる。
【００６７】
一方、ステップＳ２０４で、要求元の端末がブラウザ端末３００でないと判定したとき（Ｎｏ）は、ステップＳ２３８に移行して、取得要求に含まれるＩＰアドレスおよび通常端末３１０であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２４０に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２４２に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２３０に移行する。
【００６８】
一方、ステップＳ２０１で、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていると判定したとき（Ｙｅｓ）は、ステップＳ２４４に移行して、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき（Ｙｅｓ）は、ステップＳ２０６に移行する。
【００６９】
一方、ステップＳ２４４で、要求元の端末がブラウザ端末３００でないと判定したとき（Ｎｏ）は、ステップＳ２４０に移行する。
次に、本実施の形態の動作を図９を参照しながら説明する。図９は、ブラウザ端末３００の表示画面である。
まず、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットが存在するか否かを登録する場合を説明する。
【００７０】
プロキシサーバ２００では、電源が投入されると、アプレット存在登録処理が実行される。アプレット存在登録処理が実行されると、ステップＳ１００〜Ｓ１０４を経て、アクセス登録テーブル４００の先頭レコードからＵＲＬが読み出され、読み出されたＵＲＬをもとにＷＷＷサーバ１００にアクセスされ、そのＷＷＷサーバ１００から該当のＷｅｂページが取得される。
【００７１】
次いで、ステップＳ１０６〜Ｓ１０８を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出され、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ１１４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。これに対し、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ１２０を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。
【００７２】
そして、このような処理がアクセス登録テーブル４００に登録されているすべてのＵＲＬについて行われることにより、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットの存在の有無がプロキシサーバ２００に登録される。
次に、プロキシサーバ２００がデータ取得の仲介を行う場合を説明する。
【００７３】
ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。この取得要求は、ＨＴＴＰパケットとして送信される。
プロキシサーバ２００では、取得要求を受信すると、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていない場合は、ステップＳ２０１〜Ｓ２０４を経て、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、ステップＳ２０５〜Ｓ２０８を経て、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報が端末管理テーブル４００に登録され、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。
【００７４】
そして、ステップＳ２１０，Ｓ２１２を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、取得要求がアプレット管理テーブル４４０に登録されていないと、ステップＳ２１６を経て、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ２２０，Ｓ２２２を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、要求元のブラウザ端末３００についてアプレットの送信回数が加算される。この加算により、アプレットの送信回数が所定値以上となると、ステップＳ２２６，Ｓ２２８，Ｓ２１２，Ｓ２３０を経て、全画面更新命令が要求元のブラウザ端末３００に送信され、アプレットの送信回数が「０」に設定され、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。
【００７５】
ブラウザ端末３００では、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放が行われているので、全画面更新命令を受信すると、アプレットに割り当てたメモリ領域がすべて解放される。したがって、複数のフレームにより構成されたＷｅｂページを表示していても、アプレットに割り当てられていたメモリ領域が一旦解放されるので、メモリリソースが不足し操作不能な状態に陥る可能性を低減することができる。
【００７６】
なお、上記加算の結果により、アプレットの送信回数が所定値以上とならなければ、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。この点については、従来のプロキシサーバと同様の動作である。
一方、上記判定の結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ２３２，Ｓ２３４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。
【００７７】
ブラウザ端末３００では、差換ページを受信すると、図９（ａ）または同図（ｂ）に示すような差換ページが表示される。例えば、ブラウザ端末３００が店舗等に設置して顧客の利用に供するものであれば、顧客は、その表示を見たときに不具合が発生したことが分かるので、従業員を呼ぶ等して適切な対処を行うことができる。したがって、アプレットの実行前に対処することができるので、操作不能な状態に陥る可能性を低減することができる。
【００７８】
次に、他のブラウザ端末３００において上記と同一のＷｅｂページを閲覧する場合、ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。
プロキシサーバ２００では、取得要求を受信すると、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。
【００７９】
そして、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、アプレット存在管理テーブル４６０には、検出されたアプレット識別符号に対応するアプレットが上記処理において登録されているので、ステップＳ２３６，Ｓ２３４を経て、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。
【００８０】
なお、ＨＴＴＰヘッダの解析の結果、要求元の端末が通常端末３１０であると判定された場合、または取得したＷｅｂページにアプレット識別符号が含まれていない場合はいずれも、取得されたＷｅｂページがそのまま要求元の端末に送信される。
このようにして、本実施の形態では、プロキシサーバ２００は、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行うブラウザ端末３００と、複数のＷＷＷサーバ１００とに通信可能に接続し、ブラウザ端末３００からの取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページを要求元のブラウザ端末３００に送信する一方、取得したＷｅｂページに基づいてブラウザ端末３００へのアプレットの送信回数を計数し、その計数結果に基づいて要求元のブラウザ端末３００に全画面更新命令を送信するようになっている。
【００８１】
これにより、アプレットの送信回数に応じてメモリ領域が解放されるので、スタティックメモリ管理方式を採用したブラウザ端末３００において、従来に比して、メモリリソースの不足により操作不能な状態に陥る可能性を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページに特定取得要求が含まれているときは、そのＷｅｂページから特定取得要求を検出し、検出した特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、取得したＷｅｂページについて、そのＷｅｂページに含まれる特定取得要求に係るアプレットが存在しないと判定したときは、そのＷｅｂページに代えて、アプレットが存在しない旨の差換ページを要求元の端末に送信するようになっている。
【００８２】
これにより、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しない場合は、要求元の端末が特定取得要求を送信する前に、アプレットが存在しないことを要求元の端末に通知することができるので、ブラウザ端末３００において、従来に比して、操作不能な状態に陥る可能性を低減することができる。また、これを戻るボタンを設けずに実現することができるので、サービス提供の確実性を低下させることもさほどない。
【００８３】
さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページからアプレット識別符号を検出することによりそのＷｅｂページに特定取得要求が含まれていることを検出するようになっている。
これにより、特定取得要求が含まれていることを比較的確実に検出することができる。
【００８４】
さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページに特定取得要求が含まれていることを検出したときは、その特定取得要求が含まれているＷｅｂページを解析し、解析結果に基づいてアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０にアプレットが登録されていないと判定した場合に限り、ＷＷＷサーバ１００にアクセスして特定取得要求に係るアプレットが存在するか否かを判定するようになっている。
【００８５】
これにより、存在するか否かを一度も判定したことのないアプレットについてのみ、ＷＷＷサーバ１００に対してアクセスが行われるので、ＷＷＷサーバ１００にアクセスする回数を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、受信した取得要求の解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、ブラウザ端末３００であると判定したときは、特定取得要求の検出およびアプレットの存在確認を行うようになっている。
【００８６】
これにより、ブラウザ端末３００に送信すべきＷｅｂページについてのみ、特定取得要求の検出およびアプレットの存在確認が行われるので、処理負荷を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、ブラウザ端末３００からの取得要求を受信する前に、アクセス登録テーブル４００のＵＲＬをもとにＷＷＷサーバ１００にアクセスして該当のアプレットが存在するか否かを判定し、該当のアプレットの存在確認結果を、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録するようになっている。
【００８７】
これにより、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０への登録が取得要求の受信前に行われるので、ブラウザ端末３００に対する応答速度を向上することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、取得要求のＨＴＴＰヘッダを解析し、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、判定結果に基づいて端末管理テーブル４００への登録を行う一方、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているときは、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定するようになっている。
【００８８】
これにより、端末管理テーブル４００に一旦登録されると、要求元の端末についてＨＴＴＰヘッダの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。
上記実施の形態において、インターネット１９８およびプライベートネットワーク１９９は、ネットワークに対応し、ＷＷＷサーバ１００、ブラウザ端末３００および通常端末３１０は、ネットワークリソースに対応している。また、記憶装置４２は、記憶手段に対応し、ステップＳ２０６，Ｓ２０８は、サーバ側データ取得手段、またはサーバ側データ取得ステップに対応し、ステップＳ２１０，Ｓ２１２は、特定取得要求検出手段に対応している。
【００８９】
また、上記実施の形態において、ステップＳ２１６，Ｓ２１８は、データ存在判定手段に対応し、ステップＳ２２２は、回数計数手段、または回数計数ステップに対応している。また、ステップＳ２２６は、更新命令出力手段、更新命令送信手段、更新命令出力ステップ、または更新命令送信ステップに対応し、ステップＳ２３０，Ｓ２３４は、データ送信手段、またはデータ送信ステップに対応している。
【００９０】
また、上記実施の形態において、差換ページは、通知データに対応し、全画面更新命令は、更新命令に対応し、アプレットは、特定形式データ、または実行型のプログラムデータに対応している。また、アプレット識別符号は、要求識別情報に対応し、ＵＲＬは、データ識別情報、または取得先アドレスに対応し、ＩＰアドレスは、ネットワークリソース識別情報に対応している。
【００９１】
なお、上記実施の形態において、プロキシサーバ２００は、ステップＳ１０６，Ｓ２１０で、取得したＷｅｂページを常に解析するように構成したが、これに限らず、取得したＷｅｂページのＵＲＬがアプレット管理テーブル４４０に登録されているか否かを判定し、アプレット管理テーブル４４０に登録されていると判定したときは、Ｗｅｂページの解析を省略するように構成してもよい。
【００９２】
これにより、アプレット管理テーブル４４０に一旦登録されると、Ｗｅｂページの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。
また、上記実施の形態においては、図６に示すアプレット存在管理テーブル４６０をＷｅｂページごと複数設けて構成したが、これに限らず、それら複数のアプレット存在管理テーブル４６０を一つのテーブルとして構成してもよい。これにより、検索の高速化を図ることができる。
【００９３】
また、上記実施の形態においては、取得要求に含まれるＩＰアドレスにより要求元の端末を識別するように構成したが、これに限らず、クッキー（Ｃｏｏｋｉｅ）によって送受信されるユーザ情報等により要求元の端末を識別するように構成することもできる。
また、上記実施の形態において、図７および図８のフローチャートに示す処理を実行するにあたってはいずれも、ＲＯＭ３２にあらかじめ格納されている制御プログラムを実行する場合について説明したが、これに限らず、これらの手順を示したプログラムが記憶された記憶媒体から、そのプログラムをＲＡＭ３４に読み込んで実行するようにしてもよい。
【００９４】
ここで、記憶媒体とは、ＲＡＭ、ＲＯＭ等の半導体記憶媒体、ＦＤ、ＨＤ等の磁気記憶型記憶媒体、ＣＤ、ＣＤＶ、ＬＤ、ＤＶＤ等の光学的読取方式記憶媒体、ＭＯ等の磁気記憶型／光学的読取方式記憶媒体であって、電子的、磁気的、光学的等の読み取り方法のいかんにかかわらず、コンピュータで読み取り可能な記憶媒体であれば、あらゆる記憶媒体を含むものである。
【００９５】
また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、インターネット１９８からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９８と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９８と同一方式により通信を行うネットワークに限らず、通常のネットワークに適用することもできる。
【００９６】
また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したが、これに限らず、本発明の主旨を逸脱しない範囲で他の場合にも適用可能である。例えば、プロキシサーバ２００が実現する処理をブラウザ端末３００に組み込むソフトウェアとして構成することもできる。
【図面の簡単な説明】
【図１】本発明を適用するネットワークシステムの構成を示すブロック図である。
【図２】プロキシサーバ２００の構成を示すブロック図である。
【図３】アクセス登録テーブル４００のデータ構造を示す図である。
【図４】端末管理テーブル４２０のデータ構造を示す図である。
【図５】アプレット管理テーブル４４０のデータ構造を示す図である。
【図６】アプレット存在管理テーブル４６０のデータ構造を示す図である。
【図７】アプレット存在登録処理を示すフローチャートである。
【図８】データ仲介処理を示すフローチャートである。
【図９】ブラウザ端末３００の表示画面である。
【符号の説明】
１００ ＷＷＷサーバ
１９８ インターネット
３００ ブラウザ端末
３１０ 通常端末
１９９ プライベートネットワーク
２００ プロキシサーバ
３０ ＣＰＵ
３２ ＲＯＭ
３４ ＲＡＭ
３８ Ｉ／Ｆ
４０ 入力装置
４２ 記憶装置
４４ 表示装置
４００ アクセス登録テーブル
４２０ 端末管理テーブル
４４０ アプレット管理テーブル
４６０ アプレット存在管理テーブル
【発明の属する技術分野】
本発明は、一のネットワークリソースと他のネットワークリソースとの間でデータの取得を仲介する装置、サーバおよびプログラム、並びに方法に係り、特に、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法に関する。
【０００２】
【従来の技術】
Ｗｅｂベースの技術の浸透に伴い、ユーザインターフェースとしてＷｅｂブラウザを用い、アプリケーション本体はＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバで稼働させるような、いわゆるシンクライアント型のシステムが利用されるようになってきている。このとき、ＷＷＷサーバからクライアントに送られる情報は、フォームを含むＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データであり、クライアントの端末では、Ｗｅｂブラウザさえ動けば、実行に先立って特にアプリケーションの配布・インストール等の作業を行うことなく、アプリケーションを実行させることができるようになる。また、一般的には、クライアント側でアプリケーションを実行するのに比して、クライアント側はより処理能力の低いハードウエアで運用することができる。
【０００３】
従来、このようなクライアント端末には、ローエンドのＰＣが用いられてきた。しかし、最近では、店舗等に設置して顧客に気軽に使用してもらうことを目的としたものとして、液晶ディスプレイ上にタッチパネルを設け、タッチパネル上の操作だけで利用することができるブラウザ端末も開発され、そのようなブラウザ端末上でもＷｅｂブラウザが動作するようになってきている。
【０００４】
【発明が解決しようとする課題】
このようなブラウザ端末は、ローエンドのＰＣと異なり、省電力化、低コスト化および省スペース化等を図るために、ＣＰＵの処理能力が低く、メモリリソースも少なく設計されているのが通常である。そのため、ブラウザ端末に組み込むＷｅｂブラウザでは、ＪＡＶＡ（登録商標）アプレット（以下、単にアプレットという。）を実行するにあたり、アプレットに割り当てるメモリ領域を管理する方法として、ＣＰＵ負荷が少なくかつメモリ効率に優れたスタティックメモリ管理方式が採用されている。
【０００５】
スタティックメモリ管理方式は、１つのＷｅｂページをテーブルにより管理し、テーブルがリセットされるまでは、Ｗｅｂページに付属するアプレットを読み込むたびに未使用のメモリ領域を順次割り当てていく方式である。テーブルのリセットタイミングは、そのＷｅｂページをリロードすべき更新命令が与えられたときである。
【０００６】
しかしながら、スタティックメモリ管理方式にあっては、複数のフレームにより構成されたＷｅｂページを表示する場合は、ユーザの操作によっては更新命令が与えられないまま、そのＷｅｂページに付属するアプレットが次々と読み込まれ、メモリリソースが不足し操作不能な状態に陥る可能性があった。例えば、メニュー項目の一覧を表示するメニューフレームと、メニューフレームのメニュー項目に対応する内容を表示するコンテンツフレームにより構成されたＷｅｂページを、ユーザが各メニュー項目を選択しながら一つ一つのメニュー内容を表示する場合、メニュー項目を選択するごとにコンテンツフレームのＷｅｂページは更新されるが、コンテンツフレームの更新だけでは全体のＷｅｂページについて更新命令が与えられないため、メニュー項目を選択するごとにそのＷｅｂページに付属するアプレットがメモリに読み込まれ蓄積される。ローエンドのＰＣのように個人ユーザ向けに使用される端末では、同一のＷｅｂページを何度も表示することはないので、アプレットの過剰読込によりメモリリソース不足が生じる可能性は少ない。しかし、これに対し、店舗等に設置するブラウザ端末では、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供することがあるため、複数の顧客により同一のＷｅｂページを繰り返し表示されると、アプレットの過剰読込によりメモリリソース不足が生じる可能性が大きい。
【０００７】
ところで、ローエンドのＰＣ上で動作するＷｅｂブラウザには、「戻る」というコントロールボタンが設けられており、ユーザは、戻るボタンをクリックするだけで、１つまたはいくつか前に閲覧したＷｅｂページを、再アクセスを行うことなく閲覧することができる。これに対して、ブラウザ端末上で動作するＷｅｂブラウザには、戻るボタンが設けられていない場合が多い。これは、アプレットを利用してＷｅｂページを構成し、そのＷｅｂページによりプリントサービス等の店舗専用のサービスを提供する場合、ブラウザ端末においてアプレットの実行中に戻るボタンがクリックされてしまうと、Ｗｅｂページによるサービスを確実に提供できなくなってしまうからである。例えば、プリントの実行が完了する前に戻るボタンをクリックされてしまうと、プリントが完全に行われず印刷ミスとなる可能性がある。すなわち、店舗にとっては、戻るボタンが利用できない不便よりも、サービス提供の確実性が低下してしまう方が不都合であるため、ブラウザ端末には、あえて戻るボタンが設けられていないのである。
【０００８】
しかしながら、ブラウザ端末上で動作するＷｅｂブラウザにあっては、戻るボタンが設けられていないことから、ＷＷＷサーバの更新の不手際等何らかの原因により、サービス提供に必要なアプレットがＷＷＷサーバ上に存在しない場合、ブラウザ端末が特定の画面を表示したまま停止してしまい、操作不能な状態に陥ることがあった。従業員がこの状態を直ちに見つけて対処できればよいが、多くの場合困難であるし、またできても大変な手間がかかる。この場合、戻るボタンを設ければ、戻るボタンの操作により操作不能な状態に陥ることをとりあえず回避することはできるが、戻るボタンを設けては、上記要因によりサービス提供の確実性が低下してしまう。
【０００９】
そこで、本発明は、このような従来の技術の有する未解決の課題に着目してなされたものであって、スタティックメモリ管理方式を採用したブラウザ端末において、メモリリソースの不足により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第１の目的としている。さらに、サービス提供の確実性を低下させることなく、アプレットの取得待ち等により操作不能な状態に陥るという不具合を解決するのに好適なメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を提供することを第２の目的としている。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明に記載のプロキシサーバは、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバであって、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段と、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段と、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段と、前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段とを備えることを特徴とする。
【００１５】
このような構成であれば、ブラウザ端末では、ネットワークリソースにアクセスする場合、端末側データ取得手段により、プロキシサーバに取得要求が送信される。
プロキシサーバでは、取得要求を受信すると、サーバ側データ取得手段により、取得要求に応じてネットワークリソースからデータが取得され、データ送信手段により、取得されたデータがブラウザ端末に送信される。
【００１６】
ブラウザ端末では、データを受信すると、メモリ領域割当手段により、受信したデータのうち特定形式データにスタティックメモリ管理方式によりメモリ領域が割り当てられる。
一方、プロキシサーバでは、回数計数手段により、サーバ側データ取得手段で取得されたデータに基づいてブラウザ端末への特定形式データの送信回数が計数され、更新命令送信手段により、その計数結果に基づいてブラウザ端末に更新命令が送信される。
【００１７】
ブラウザ端末では、更新命令を受信すると、メモリ解放手段により、更新命令に応じて特定形式データに割り当てられたメモリ領域が解放される。
また、特定形式のデータとしては、実行型のプログラムデータ（例えば、ＪＡＶＡ（登録商標）アプレット）のほか、例えば、画像データ、音声データその他のマルチメディアデータ、またはテキストデータその他の文書データが含まれる。以下、本発明に記載のプロキシサーバ、サーバ用プログラム、並びにメモリ管理方法において同じである。
また、回数計数手段は、データ取得手段で取得した特定形式データの取得回数を計数するようになっていればどのような構成であってもよく、より具体的には、特定形式データの取得回数を推定または実測により計数することができる。以下、本発明に記載のメモリ管理プログラムにおいて同じである。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、前記特定形式データは、実行型のプログラムデータであることを特徴とする。
【００１８】
このような構成であれば、ブラウザ端末では、データを受信すると、メモリ領域割当手段により、受信したデータのうちプログラムデータにスタティックメモリ管理方式によりメモリ領域が割り当てられる。
一方、プロキシサーバでは、回数計数手段により、サーバ側データ取得手段で取得されたデータに基づいてブラウザ端末へのプログラムデータの送信回数が計数され、更新命令送信手段により、その計数結果に基づいてブラウザ端末に更新命令が送信される。
【００１９】
ブラウザ端末では、更新命令を受信すると、メモリ解放手段により、更新命令に応じてプログラムデータに割り当てられたメモリ領域が解放される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記更新命令送信手段は、前記回数計数手段で計数した送信回数が所定値以上となったときは、前記ブラウザ端末に前記更新命令を送信するようになっていることを特徴とする。
【００２０】
このような構成であれば、プロキシサーバでは、回数計数手段で計数された送信回数が所定値以上となると、更新命令送信手段により、ブラウザ端末に更新命令が送信される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記サーバ側データ取得手段で取得したデータに前記特定形式データの取得要求である特定取得要求が含まれていることを検出する特定取得要求検出手段を備え、
前記回数計数手段は、前記特定取得要求検出手段で検出した特定取得要求の個数を計数することにより前記ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とする。
【００２１】
このような構成であれば、プロキシサーバでは、サーバ側データ取得手段で取得されたデータに特定取得要求が含まれていると、特定取得要求検出手段により、特定取得要求が含まれていることが検出され、回数計数手段により、検出された特定取得要求の個数が計数され、これによりブラウザ端末への特定形式データの送信回数が計数される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記特定取得要求を含むデータには、前記特定取得要求であることを示す要求識別情報をあらかじめ付加しておき、
前記特定取得要求検出手段は、前記サーバ側データ取得手段で取得したデータから前記要求識別情報を検出することにより当該データに前記特定取得要求が含まれていることを検出するようになっていることを特徴とする。
【００２２】
このような構成であれば、プロキシサーバでは、取得されたデータに要求識別情報が含まれていると、特定取得要求検出手段により、取得されたデータに特定取得要求が含まれていることが検出される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により前記ブラウザ端末を識別するようになっていることを特徴とする。
【００２３】
このような構成であれば、プロキシサーバでは、ネットワークリソース識別情報を含む取得要求を受信すると、受信した取得要求からネットワークリソース識別情報が取得される。そして、取得されたネットワークリソース識別情報によりブラウザ端末が識別される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソース識別情報は、ＩＰアドレスであることを特徴とする。
【００２４】
このような構成であれば、プロキシサーバでは、ＩＰアドレスを含む取得要求を受信すると、受信した取得要求からＩＰアドレスが取得される。そして、取得されたＩＰアドレスによりブラウザ端末が識別される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
複数の前記ブラウザ端末と通信可能に接続し、
前記回数計数手段は、前記各ブラウザ端末ごとに、当該ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とする。
【００２５】
このような構成であれば、プロキシサーバでは、回数計数手段により、各ブラウザ端末ごとに、そのブラウザ端末への特定形式データの送信回数が計数される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記回数計数手段は、前記更新命令送信手段で前記更新命令を前記ブラウザ端末に送信したときは、当該ブラウザ端末への前記特定形式データの送信回数を初期化するようになっていることを特徴とする。
【００２６】
このような構成であれば、プロキシサーバでは、更新命令送信手段で更新命令がブラウザ端末に送信されると、そのブラウザ端末への特定形式データの送信回数が初期化される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記特定取得要求検出手段の検出結果に基づいて前記特定取得要求に係る特定形式データが取得先のネットワークリソースに存在するか否かを判定するデータ存在判定手段を備え、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、前記特定形式データが存在しない旨の通知を行うようになっていることを特徴とする。
【００２７】
このような構成であれば、プロキシサーバでは、データ存在判定手段により、特定取得要求検出手段の検出結果に基づいて特定取得要求に係る特定形式データが取得先のネットワークリソースに存在するか否かが判定される。その結果、特定形式データが存在しないと判定されると、データ送信手段により、特定形式データが存在しない旨の通知が行われる。
【００２８】
ここで、特定形式データが存在しない旨の通知は、ブラウザ端末に対して行うに限らず、ブラウザ端末を管理する管理端末に対して行うようにしてもよい。この場合、特定形式データが存在しない旨は、イベントログとして通知するようにしてもよい。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、当該データに代えて、前記特定形式データが存在しない旨の通知データを前記ブラウザ端末に送信するようになっていることを特徴とする。
【００２９】
このような構成であれば、プロキシサーバでは、特定形式データが存在しないと判定されると、データ送信手段により、そのデータに代えて、特定形式データが存在しない旨の通知データがブラウザ端末に送信される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記データ存在判定手段は、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定したときは、当該特定形式データを識別するためのデータ識別情報および当該特定形式データの取得先アドレスを対応付けて記憶手段に登録し、
前記特定取得要求検出手段で前記特定取得要求が含まれていることを検出したときは、当該特定取得要求が含まれているデータから前記データ識別情報および前記取得先アドレスを取得し、取得したデータ識別情報および取得先アドレスが前記記憶手段に登録されていないときは、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定するようになっていることを特徴とする。
【００３０】
このような構成であれば、プロキシサーバでは、データ存在判定手段により、取得先のネットワークリソースにアクセスして特定取得要求に係る特定形式データが存在するか否かが判定されると、その特定形式データについてデータ識別情報および取得先アドレスが対応付けられて記憶手段に登録される。
一方、特定取得要求が含まれていることが検出されると、データ存在判定手段により、その特定取得要求が含まれているデータからデータ識別情報および取得先アドレスが取得される。そして、取得されたデータ識別情報および取得先アドレスが記憶手段に登録されていないと、取得先のネットワークリソースにアクセスして特定取得要求に係る特定形式データが存在するか否かが判定される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記記憶手段には、前記ブラウザ端末がアクセスすることのある特定形式データごとに前記取得先アドレスを登録したアクセス登録テーブルを記憶させておき、
前記データ存在判定手段は、前記ブラウザ端末からの取得要求を受信する前に、前記アクセス登録テーブルの取得先アドレスをもとに前記ネットワークリソースにアクセスして該当の特定形式データが存在するか否かを判定し、当該特定形式データを識別するためのデータ識別情報および当該特定形式データの取得先アドレスを対応付けて前記記憶手段に登録するようになっていることを特徴とする。
【００３１】
このような構成であれば、プロキシサーバでは、ブラウザ端末からの取得要求を受信する前に、データ存在判定手段により、アクセス登録テーブルの取得先アドレスをもとにネットワークリソースにアクセスされて該当の特定形式データが存在するか否かが判定され、その特定形式データを識別するためのデータ識別情報およびその特定形式データの取得先アドレスが対応付けて記憶手段に登録される。
さらに、本発明に記載のプロキシサーバは、上記のプロキシサーバにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により特定されるネットワークリソースが前記ブラウザ端末であると判定したときは、前記特定取得要求検出手段による検出および前記データ存在判定手段による判定を行うようになっていることを特徴とする。
【００３２】
このような構成であれば、プロキシサーバでは、ネットワークリソース識別情報を含む取得要求を受信すると、受信した取得要求からネットワークリソース識別情報が取得される。そして、取得されたネットワークリソース識別情報により特定されるネットワークリソースがブラウザ端末であると判定されると、特定取得要求検出手段による検出およびデータ存在判定手段による判定が行われる。
【００３３】
一方、上記目的を達成するために、本発明に記載のサーバ用プログラムは、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバとして用いるコンピュータに、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段、および前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段として実現される処理を実行させるためのプログラムであることを特徴とする。
【００３４】
このような構成であれば、コンピュータによってプログラムが読み取られ、読み取られたプログラムに従ってコンピュータが処理を実行すると、本発明に記載のプロキシサーバと同等の作用が得られる。
【００３５】
さらに、本発明に記載のサーバのメモリ管理方法は、
ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバのメモリ管理方法であって、
前記取得要求に応じてＣＰＵが前記ネットワークリソースからデータを取得するサーバ側データ取得ステップと、前記ＣＰＵが前記サーバ側データ取得ステップで取得したデータを前記ブラウザ端末に送信するデータ送信ステップと、前記サーバ側データ取得ステップで取得したデータに基づいて前記ＣＰＵが前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数ステップと、前記回数計数ステップの計数結果に基づいて前記ＣＰＵが前記ブラウザ端末に前記更新命令を送信する更新命令送信ステップとを含むことを特徴とする。
【００３６】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しながら説明する。図１ないし図９は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法の実施の形態を示す図である。
本実施の形態は、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したものである。
【００３７】
まず、本発明を適用するネットワークシステムの構成を図１を参照しながら説明する。図１は、本発明を適用するネットワークシステムの構成を示すブロック図である。
図１において、インターネット１９８には、ＨＴＭＬデータにより構成したＷｅｂページを蓄積する複数のＷＷＷサーバ１００が接続されており、プライベートネットワーク１９９には、特殊用途に特化した複数のブラウザ端末３００と、特殊用途以外の用途にも用いられる複数の通常端末３１０とが接続されている。また、インターネット１９８およびプライベートネットワーク１９９には、ブラウザ端末３００および通常端末３１０とＷＷＷサーバ１００との間でＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）その他のプロトコルによりデータ取得を仲介するプロキシサーバ２００が接続されている。
【００３８】
ブラウザ端末３００は、図示しないが、液晶ディスプレイ上にタッチパネルを設けて構成されており、Ｗｅｂブラウザを起動し、タッチパネル上の操作だけでＷｅｂブラウザを利用可能となっている。なお、ブラウザ端末３００上で動作するＷｅｂブラウザは、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行う。また、同Ｗｅｂブラウザには、Ｗｅｂページによるサービスを確実に提供するために、戻るボタンが設けられていない。
【００３９】
ブラウザ端末３００は、組み込まれているＷｅｂブラウザによって「ＮＤ−２０００」および「ＮＤ−３０００」の２種類に分類される。「ＮＤ−２０００」のブラウザ端末３００は、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をすべて１つのタグとして記述した形式（以下、ＮＤ−２０００形式という。）のＨＴＭＬデータが与えられたときは、そのタグを解読して適切に処理するが、アプレット識別符号、アプレットのバージョン、アプレット名およびアプレットに与えるパラメータ等をそれぞれ１つのタグとして記述した形式（以下、ＮＤ−３０００形式という。）のＨＴＭＬデータが与えられたときは、それらタグを無視するようになっている。「ＮＤ−３０００」のブラウザ端末３００は、ＮＤ−３０００形式のＨＴＭＬデータが与えられたときは、それらタグを解読して適切に処理するが、ＮＤ−２０００形式のＨＴＭＬデータが与えられたときは、そのタグを無視するようになっている。
【００４０】
次に、プロキシサーバ２００の構成を図２を参照しながら詳細に説明する。図２は、プロキシサーバ２００の構成を示すブロック図である。
プロキシサーバ２００は、図２に示すように、制御プログラムに基づいて演算およびシステム全体を制御するＣＰＵ３０と、所定領域にあらかじめＣＰＵ３０の制御プログラム等を格納しているＲＯＭ３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互にかつデータ授受可能に接続されている。
【００４１】
Ｉ／Ｆ３８には、外部装置として、ヒューマンインターフェースとしてデータの入力が可能なキーボードやマウス等からなる入力装置４０と、データやテーブル等をファイルとして格納する記憶装置４２と、画像信号に基づいて画面を表示する表示装置４４と、インターネット１９８に接続するための信号線と、プライベートネットワーク１９９に接続するための信号線とが接続されている。
【００４２】
記憶装置４２には、図３に示すように、プライベートネットワーク１９９に接続する各端末がアクセスすることのあるＷｅｂページのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ）を登録したアクセス登録テーブル４００が格納されている。図３は、アクセス登録テーブル４００のデータ構造を示す図である。
アクセス登録テーブル４００には、図３に示すように、各ＵＲＬごとに１つのレコードが登録されている。各レコードは、ＵＲＬを登録したフィールド４０２を含んで構成されている。アクセス登録テーブル４００は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、プロキシサーバ２００が参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録するために使用される。これにより、プライベートネットワーク１９９に接続する端末に対する応答速度を向上することができる。
【００４３】
また、記憶装置４２には、図４に示すように、プライベートネットワーク１９９に接続する各端末についてＩＰアドレス、端末識別情報およびアプレットの送信回数を対応付けて登録した端末管理テーブル４２０が格納されている。図４は、端末管理テーブル４２０のデータ構造を示す図である。
端末管理テーブル４２０には、図４に示すように、プライベートネットワーク１９９に接続する各端末ごとに１つのレコードが登録されている。各レコードは、端末に設定されたＩＰアドレスを登録したフィールド４２２と、端末を識別するための端末識別情報を登録したフィールド４２４と、アプレットを端末に送信した回数を登録したフィールド４２６とを含んで構成されている。
【００４４】
図４の例では、第１段目のレコードには、ＩＰアドレスとして「１９２．１６８．１００．１０」が、端末識別情報として「通常端末」が、送信回数として「０」がそれぞれ登録されており、これは、ＩＰアドレス「１９２．１６８．１００．１０」が設定された端末が通常端末３１０であることを意味し、また、その通常端末３１０に対するアプレットの送信回数が「０」回であることを意味している。また、第４段目のレコードには、ＩＰアドレスとして「１９２．１６８．１０１．１０」が、端末識別情報として「ブラウザ端末」がそれぞれ登録されており、これは、ＩＰアドレス「１９２．１６８．１０１．１０」が設定された端末がブラウザ端末３００であることを意味し、また、そのブラウザ端末３００に対するアプレットの送信回数が「０」回であることを意味している。
【００４５】
また、記憶装置４２には、図５に示すように、Ｗｅｂページのアプレットを管理するアプレット管理テーブル４４０が格納されている。図５は、アプレット管理テーブル４４０のデータ構造を示す図である。
アプレット管理テーブル４４０は、図５に示すように、取得要求に応じてプロキシサーバ２００がＷｅｂページを取得するごとに、１つのレコードが作成されるものである。各レコードは、ＷｅｂページのＵＲＬを登録したフィールド４４２と、そのＷｅｂページが利用するアプレットの個数を登録したフィールド４４４，４５０と、そのＷｅｂページが利用するすべてのアプレットの存在の有無を登録したフィールド４４６，４５２と、そのＷｅｂページが利用する各アプレットについてアプレットが存在するか否かを管理するアプレット存在管理テーブルへのポインタを登録したフィールド４４８，４５４とを含んで構成されている。なお、フィールド４４４〜４４８は、Ｗｅｂページを構成するＨＴＭＬデータの形式がＮＤ−２０００形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドであり、フィールド４５０〜４５４は、Ｗｅｂページを構成するＨＴＭＬデータの形式がＮＤ−３０００形式の場合に、アプレット数、アプレットの存在の有無およびテーブル名を登録するフィールドである。
【００４６】
図５の例では、第１段目のレコードには、ＵＲＬとして「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍ」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちＮＤ−２０００形式に係るものとして、「３」、「０」および「テーブルＡ１」が、アプレット数、アプレット存在の有無およびアプレット存在管理テーブルへのポインタのうちＮＤ−３０００形式に係るものとして、「４」、「０」および「テーブルＡ２」がそれぞれ登録されている。これは、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍ」により特定されるＷｅｂページに、アプレットを取得する要求である特定取得要求が７つ含まれており、アプレットが存在するか否かを、ＮＤ−２０００形式に係るものについてはテーブルＡ１により、ＮＤ−３０００形式に係るものについてはテーブルＡ２により管理することを意味している。さらに、ＮＤ−２０００形式に係るアプレットの一部または全部が存在せず、ＮＤ−３０００形式に係るアプレットの一部または全部が存在しないことを意味している。なお、各Ｗｅｂページには、特定取得要求を確実に検出するため、特定取得要求とともにアプレット識別符号があらかじめ付加されている。
【００４７】
アプレット存在管理テーブル４６０は、図６に示すように、各アプレットごとに１つのレコードが登録されている。各レコードは、アプレット名を登録したフィールド４６２と、アプレットの存在の有無を登録したフィールド４６４とを含んで構成されている。図６は、アプレット存在管理テーブル４６０のデータ構造を示す図である。
【００４８】
図６の例では、第１段目のレコードには、アプレット名として「ｅｘｅ＿００１」が、アプレット存在の有無として「１」がそれぞれ登録されており、これは、アプレット名「ｅｘｅ＿００１」により特定されるアプレットが規定のＷＷＷサーバ１００に存在することを意味している。また、第３段目のレコードには、アプレット名として「ｅｘｅ＿００３」が、アプレット存在の有無として「０」がそれぞれ登録されており、これは、アプレット名「ｅｘｅ＿００３」により特定されるアプレットが規定のＷＷＷサーバ１００に存在しないことを意味している。
【００４９】
ＣＰＵ３０は、マイクロプロセッシングユニットＭＰＵ等からなり、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図７および図８のフローチャートに示すアプレット存在登録処理およびデータ取得仲介処理を実行するようになっている。
初めに、アプレット存在登録処理を図７を参照しながら詳細に説明する。図７は、アプレット存在登録処理を示すフローチャートである。
【００５０】
アプレット存在登録処理は、プライベートネットワーク１９９に接続する端末からの取得要求を受信する前に、アクセス登録テーブル４００を参照して登録ＵＲＬのＷｅｂページを取得し、取得したＷｅｂページが利用するアプレットの存在の有無を登録する処理であって、ＣＰＵ３０において実行されると、図７に示すように、まず、ステップＳ１００に移行するようになっている。
【００５１】
ステップＳ１００では、アクセス登録テーブル４００の先頭レコードからＵＲＬを読み出し、ステップＳ１０２に移行して、読み出したＵＲＬをもとにＷＷＷサーバ１００にアクセスし、ステップＳ１０４に移行して、アクセスしたＷＷＷサーバ１００からＷｅｂページを取得し、ステップＳ１０６に移行する。
ステップＳ１０６では、取得したＷｅｂページを解析し、ステップＳ１０８に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき（Ｙｅｓ）は、ステップＳ１１０に移行する。
【００５２】
ステップＳ１１０では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ１１２に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき（Ｙｅｓ）は、ステップＳ１１４に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録する。なお、この登録は、取得したＷｅｂページを構成するＨＴＭＬデータの形式に応じてそれぞれ行う。以下、ステップＳ１２０，Ｓ２２０，Ｓ２３２において同じである。
【００５３】
次いで、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００５４】
一方、ステップＳ１１２で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき（Ｎｏ）は、ステップＳ１２０に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ１０８に移行する。なお、ステップＳ１０８に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ１０８の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００５５】
一方、ステップＳ１０８で、アプレット識別符号を検出しないと判定したとき（Ｎｏ）は、ステップＳ１１６に移行して、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了したか否かを判定し、すべてのＵＲＬについて処理が終了したと判定したとき（Ｙｅｓ）は、一連の処理を終了して元の処理に復帰させる。
【００５６】
一方、ステップＳ１１６で、アクセス登録テーブル４００に登録されているすべてのＵＲＬについてステップＳ１０２〜Ｓ１１４，Ｓ１２０の処理が終了しないと判定したとき（Ｎｏ）は、ステップＳ１１８に移行して、アクセス登録テーブル４００の次のレコードからＵＲＬを読み出し、ステップＳ１０２に移行する。
次に、データ取得仲介処理を図８を参照しながら詳細に説明する。図８は、データ仲介処理を示すフローチャートである。
【００５７】
データ取得仲介処理は、ＣＰＵ３０において実行されると、図８に示すように、まず、ステップＳ２００に移行するようになっている。
ステップＳ２００では、ＨＴＴＰによりページの取得要求を受信したか否かを判定し、取得要求を受信したと判定したとき（Ｙｅｓ）は、ステップＳ２０１に移行するが、そうでないと判定したとき（Ｎｏ）は、取得要求を受信するまでステップＳ２００で待機する。
【００５８】
ステップＳ２０１では、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているか否かを判定し、端末管理テーブル４００に登録されていないと判定したとき（Ｎｏ）は、ステップＳ２０２に移行して、取得要求のＨＴＴＰヘッダを解析し、ステップＳ２０４に移行して、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき（Ｙｅｓ）は、ステップＳ２０５に移行する。
【００５９】
ステップＳ２０５では、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２０６に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２０８に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２１０に移行する。
【００６０】
ステップＳ２１０では、取得したＷｅｂページを解析し、ステップＳ２１２に移行して、解析結果に基づいて、取得したＷｅｂページからアプレット識別符号を検出したか否かを判定し、アプレット識別符号を検出したと判定したとき（Ｙｅｓ）は、ステップＳ２１４に移行して、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されているか否かを判定し、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていないと判定したとき（Ｎｏ）は、ステップＳ２１６に移行する。
【００６１】
ステップＳ２１６では、検出したアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２１８に移行して、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在すると判定したとき（Ｙｅｓ）は、ステップＳ２２０に移行する。
ステップＳ２２０では、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２２２に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を加算し、ステップＳ２２４に移行する。
【００６２】
ステップＳ２２４では、アプレットの送信回数が所定値（例えば、１００回）以上であるか否かを判定し、送信回数が所定値以上であると判定したとき（Ｙｅｓ）は、全画面更新命令を要求元のブラウザ端末３００に送信し、ステップＳ２２８に移行して、要求元のブラウザ端末３００についてアプレットの送信回数を「０」に設定し、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００６３】
一方、ステップＳ２２４で、アプレットの送信回数が所定値未満であると判定したとき（Ｎｏ）は、ステップＳ２１２に移行する。なお、ステップＳ２１２に移行した際には、解析結果に基づいて、取得したＷｅｂページから次のアプレット識別符号を検出したか否かを判定する。ステップＳ２１２の２回目以降の実行は、一つのＷｅｂページに複数のアプレット識別符号が含まれている場合に対応するためである。
【００６４】
一方、ステップＳ２１８で、特定要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定したとき（Ｎｏ）は、ステップＳ２３２に移行して、検出したアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことをアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録し、ステップＳ２３４に移行して、アプレットが存在しないことを通知するための差換ページを、取得したＷｅｂページに代えて要求元のブラウザ端末３００に送信し、一連の処理を終了して元の処理に復帰させる。
【００６５】
一方、ステップＳ２１４で、検出したアプレット識別符号に対応するアプレットがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録されていると判定したとき（Ｙｅｓ）は、ステップＳ２３６に移行して、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、アプレットが存在しないと判定したとき（Ｎｏ）は、ステップＳ２３４に移行する。
【００６６】
一方、ステップＳ２３６で、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在すると判定したとき（Ｙｅｓ）は、ステップＳ２２２に移行する。
一方、ステップＳ２１２で、取得したＷｅｂページからアプレット識別符号を検出しないと判定したとき（Ｎｏ）は、ステップＳ２３０に移行して、取得したＷｅｂページを要求元の端末に送信し、一連の処理を終了して元の処理に復帰させる。
【００６７】
一方、ステップＳ２０４で、要求元の端末がブラウザ端末３００でないと判定したとき（Ｎｏ）は、ステップＳ２３８に移行して、取得要求に含まれるＩＰアドレスおよび通常端末３１０であることを示す端末識別情報を端末管理テーブル４００に登録し、ステップＳ２４０に移行して、取得要求に係るＷＷＷサーバ１００にアクセスし、ステップＳ２４２に移行して、取得要求に係るＷｅｂページをそのＷＷＷサーバ１００から取得し、ステップＳ２３０に移行する。
【００６８】
一方、ステップＳ２０１で、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていると判定したとき（Ｙｅｓ）は、ステップＳ２４４に移行して、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定し、要求元の端末がブラウザ端末３００であると判定したとき（Ｙｅｓ）は、ステップＳ２０６に移行する。
【００６９】
一方、ステップＳ２４４で、要求元の端末がブラウザ端末３００でないと判定したとき（Ｎｏ）は、ステップＳ２４０に移行する。
次に、本実施の形態の動作を図９を参照しながら説明する。図９は、ブラウザ端末３００の表示画面である。
まず、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットが存在するか否かを登録する場合を説明する。
【００７０】
プロキシサーバ２００では、電源が投入されると、アプレット存在登録処理が実行される。アプレット存在登録処理が実行されると、ステップＳ１００〜Ｓ１０４を経て、アクセス登録テーブル４００の先頭レコードからＵＲＬが読み出され、読み出されたＵＲＬをもとにＷＷＷサーバ１００にアクセスされ、そのＷＷＷサーバ１００から該当のＷｅｂページが取得される。
【００７１】
次いで、ステップＳ１０６〜Ｓ１０８を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出され、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ１１４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。これに対し、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ１２０を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録される。
【００７２】
そして、このような処理がアクセス登録テーブル４００に登録されているすべてのＵＲＬについて行われることにより、プライベートネットワーク１９９に接続する端末がアクセスすることのあるＷｅｂページが利用するアプレットの存在の有無がプロキシサーバ２００に登録される。
次に、プロキシサーバ２００がデータ取得の仲介を行う場合を説明する。
【００７３】
ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。この取得要求は、ＨＴＴＰパケットとして送信される。
プロキシサーバ２００では、取得要求を受信すると、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されていない場合は、ステップＳ２０１〜Ｓ２０４を経て、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、ステップＳ２０５〜Ｓ２０８を経て、取得要求に含まれるＩＰアドレスおよびブラウザ端末３００であることを示す端末識別情報が端末管理テーブル４００に登録され、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。
【００７４】
そして、ステップＳ２１０，Ｓ２１２を経て、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、取得要求がアプレット管理テーブル４４０に登録されていないと、ステップＳ２１６を経て、検出されたアプレット識別符号に対応する特定取得要求に係るＷＷＷサーバ１００にアクセスされる。その結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在する場合は、ステップＳ２２０，Ｓ２２２を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在することがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、要求元のブラウザ端末３００についてアプレットの送信回数が加算される。この加算により、アプレットの送信回数が所定値以上となると、ステップＳ２２６，Ｓ２２８，Ｓ２１２，Ｓ２３０を経て、全画面更新命令が要求元のブラウザ端末３００に送信され、アプレットの送信回数が「０」に設定され、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。
【００７５】
ブラウザ端末３００では、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放が行われているので、全画面更新命令を受信すると、アプレットに割り当てたメモリ領域がすべて解放される。したがって、複数のフレームにより構成されたＷｅｂページを表示していても、アプレットに割り当てられていたメモリ領域が一旦解放されるので、メモリリソースが不足し操作不能な状態に陥る可能性を低減することができる。
【００７６】
なお、上記加算の結果により、アプレットの送信回数が所定値以上とならなければ、取得されたＷｅｂページが要求元のブラウザ端末３００に送信される。この点については、従来のプロキシサーバと同様の動作である。
一方、上記判定の結果、特定取得要求に係るアプレットがそのＷＷＷサーバ１００に存在しない場合は、ステップＳ２３２，Ｓ２３４を経て、検出されたアプレット識別符号に対応するアプレットがＷＷＷサーバ１００に存在しないことがアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。
【００７７】
ブラウザ端末３００では、差換ページを受信すると、図９（ａ）または同図（ｂ）に示すような差換ページが表示される。例えば、ブラウザ端末３００が店舗等に設置して顧客の利用に供するものであれば、顧客は、その表示を見たときに不具合が発生したことが分かるので、従業員を呼ぶ等して適切な対処を行うことができる。したがって、アプレットの実行前に対処することができるので、操作不能な状態に陥る可能性を低減することができる。
【００７８】
次に、他のブラウザ端末３００において上記と同一のＷｅｂページを閲覧する場合、ブラウザ端末３００では、ユーザがＷｅｂブラウザを操作すると、閲覧の目的となるＷｅｂページの取得要求がプロキシサーバ２００に送信される。
プロキシサーバ２００では、取得要求を受信すると、取得要求のＨＴＴＰヘッダが解析され、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かが判定される。ここで、要求元の端末がブラウザ端末３００であると判定されると、取得要求に係るＷＷＷサーバ１００にアクセスされ、取得要求に係るＷｅｂページがそのＷＷＷサーバ１００から取得される。
【００７９】
そして、取得されたＷｅｂページが解析され、そのＷｅｂページにアプレット識別符号が含まれていると、取得されたＷｅｂページからアプレット識別符号が検出される。ここで、アプレット存在管理テーブル４６０には、検出されたアプレット識別符号に対応するアプレットが上記処理において登録されているので、ステップＳ２３６，Ｓ２３４を経て、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０を参照して特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しないと判定され、アプレットが存在しないことを通知するための差換ページが、取得されたＷｅｂページに代えて要求元のブラウザ端末３００に送信される。
【００８０】
なお、ＨＴＴＰヘッダの解析の結果、要求元の端末が通常端末３１０であると判定された場合、または取得したＷｅｂページにアプレット識別符号が含まれていない場合はいずれも、取得されたＷｅｂページがそのまま要求元の端末に送信される。
このようにして、本実施の形態では、プロキシサーバ２００は、スタティックメモリ管理方式によりアプレットに対してメモリ領域の割当および解放を行うブラウザ端末３００と、複数のＷＷＷサーバ１００とに通信可能に接続し、ブラウザ端末３００からの取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページを要求元のブラウザ端末３００に送信する一方、取得したＷｅｂページに基づいてブラウザ端末３００へのアプレットの送信回数を計数し、その計数結果に基づいて要求元のブラウザ端末３００に全画面更新命令を送信するようになっている。
【００８１】
これにより、アプレットの送信回数に応じてメモリ領域が解放されるので、スタティックメモリ管理方式を採用したブラウザ端末３００において、従来に比して、メモリリソースの不足により操作不能な状態に陥る可能性を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求に応じてＷＷＷサーバ１００からＷｅｂページを取得し、取得したＷｅｂページに特定取得要求が含まれているときは、そのＷｅｂページから特定取得要求を検出し、検出した特定取得要求に係るアプレットがＷＷＷサーバ１００に存在するか否かを判定し、取得したＷｅｂページについて、そのＷｅｂページに含まれる特定取得要求に係るアプレットが存在しないと判定したときは、そのＷｅｂページに代えて、アプレットが存在しない旨の差換ページを要求元の端末に送信するようになっている。
【００８２】
これにより、特定取得要求に係るアプレットがＷＷＷサーバ１００に存在しない場合は、要求元の端末が特定取得要求を送信する前に、アプレットが存在しないことを要求元の端末に通知することができるので、ブラウザ端末３００において、従来に比して、操作不能な状態に陥る可能性を低減することができる。また、これを戻るボタンを設けずに実現することができるので、サービス提供の確実性を低下させることもさほどない。
【００８３】
さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページからアプレット識別符号を検出することによりそのＷｅｂページに特定取得要求が含まれていることを検出するようになっている。
これにより、特定取得要求が含まれていることを比較的確実に検出することができる。
【００８４】
さらに、本実施の形態では、プロキシサーバ２００は、取得したＷｅｂページに特定取得要求が含まれていることを検出したときは、その特定取得要求が含まれているＷｅｂページを解析し、解析結果に基づいてアプレット管理テーブル４４０およびアプレット存在管理テーブル４６０にアプレットが登録されていないと判定した場合に限り、ＷＷＷサーバ１００にアクセスして特定取得要求に係るアプレットが存在するか否かを判定するようになっている。
【００８５】
これにより、存在するか否かを一度も判定したことのないアプレットについてのみ、ＷＷＷサーバ１００に対してアクセスが行われるので、ＷＷＷサーバ１００にアクセスする回数を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、受信した取得要求の解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、ブラウザ端末３００であると判定したときは、特定取得要求の検出およびアプレットの存在確認を行うようになっている。
【００８６】
これにより、ブラウザ端末３００に送信すべきＷｅｂページについてのみ、特定取得要求の検出およびアプレットの存在確認が行われるので、処理負荷を低減することができる。
さらに、本実施の形態では、プロキシサーバ２００は、ブラウザ端末３００からの取得要求を受信する前に、アクセス登録テーブル４００のＵＲＬをもとにＷＷＷサーバ１００にアクセスして該当のアプレットが存在するか否かを判定し、該当のアプレットの存在確認結果を、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０に登録するようになっている。
【００８７】
これにより、アプレット管理テーブル４４０およびアプレット存在管理テーブル４６０への登録が取得要求の受信前に行われるので、ブラウザ端末３００に対する応答速度を向上することができる。
さらに、本実施の形態では、プロキシサーバ２００は、取得要求を受信したときは、取得要求のＨＴＴＰヘッダを解析し、解析結果に基づいて要求元の端末がブラウザ端末３００であるか否かを判定し、判定結果に基づいて端末管理テーブル４００への登録を行う一方、取得要求に含まれるＩＰアドレスが端末管理テーブル４００に登録されているときは、端末管理テーブル４００を参照して要求元の端末がブラウザ端末３００であるか否かを判定するようになっている。
【００８８】
これにより、端末管理テーブル４００に一旦登録されると、要求元の端末についてＨＴＴＰヘッダの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。
上記実施の形態において、インターネット１９８およびプライベートネットワーク１９９は、ネットワークに対応し、ＷＷＷサーバ１００、ブラウザ端末３００および通常端末３１０は、ネットワークリソースに対応している。また、記憶装置４２は、記憶手段に対応し、ステップＳ２０６，Ｓ２０８は、サーバ側データ取得手段、またはサーバ側データ取得ステップに対応し、ステップＳ２１０，Ｓ２１２は、特定取得要求検出手段に対応している。
【００８９】
また、上記実施の形態において、ステップＳ２１６，Ｓ２１８は、データ存在判定手段に対応し、ステップＳ２２２は、回数計数手段、または回数計数ステップに対応している。また、ステップＳ２２６は、更新命令出力手段、更新命令送信手段、更新命令出力ステップ、または更新命令送信ステップに対応し、ステップＳ２３０，Ｓ２３４は、データ送信手段、またはデータ送信ステップに対応している。
【００９０】
また、上記実施の形態において、差換ページは、通知データに対応し、全画面更新命令は、更新命令に対応し、アプレットは、特定形式データ、または実行型のプログラムデータに対応している。また、アプレット識別符号は、要求識別情報に対応し、ＵＲＬは、データ識別情報、または取得先アドレスに対応し、ＩＰアドレスは、ネットワークリソース識別情報に対応している。
【００９１】
なお、上記実施の形態において、プロキシサーバ２００は、ステップＳ１０６，Ｓ２１０で、取得したＷｅｂページを常に解析するように構成したが、これに限らず、取得したＷｅｂページのＵＲＬがアプレット管理テーブル４４０に登録されているか否かを判定し、アプレット管理テーブル４４０に登録されていると判定したときは、Ｗｅｂページの解析を省略するように構成してもよい。
【００９２】
これにより、アプレット管理テーブル４４０に一旦登録されると、Ｗｅｂページの解析を行わなくてすむので、プロキシサーバ２００の処理負荷を低減するとともに要求元の端末に対する応答速度を向上することができる。
また、上記実施の形態においては、図６に示すアプレット存在管理テーブル４６０をＷｅｂページごと複数設けて構成したが、これに限らず、それら複数のアプレット存在管理テーブル４６０を一つのテーブルとして構成してもよい。これにより、検索の高速化を図ることができる。
【００９３】
また、上記実施の形態においては、取得要求に含まれるＩＰアドレスにより要求元の端末を識別するように構成したが、これに限らず、クッキー（Ｃｏｏｋｉｅ）によって送受信されるユーザ情報等により要求元の端末を識別するように構成することもできる。
また、上記実施の形態において、図７および図８のフローチャートに示す処理を実行するにあたってはいずれも、ＲＯＭ３２にあらかじめ格納されている制御プログラムを実行する場合について説明したが、これに限らず、これらの手順を示したプログラムが記憶された記憶媒体から、そのプログラムをＲＡＭ３４に読み込んで実行するようにしてもよい。
【００９４】
ここで、記憶媒体とは、ＲＡＭ、ＲＯＭ等の半導体記憶媒体、ＦＤ、ＨＤ等の磁気記憶型記憶媒体、ＣＤ、ＣＤＶ、ＬＤ、ＤＶＤ等の光学的読取方式記憶媒体、ＭＯ等の磁気記憶型／光学的読取方式記憶媒体であって、電子的、磁気的、光学的等の読み取り方法のいかんにかかわらず、コンピュータで読み取り可能な記憶媒体であれば、あらゆる記憶媒体を含むものである。
【００９５】
また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、インターネット１９８からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９８と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９８と同一方式により通信を行うネットワークに限らず、通常のネットワークに適用することもできる。
【００９６】
また、上記実施の形態においては、本発明に記載のメモリ管理装置、プロキシサーバ、メモリ管理プログラムおよびサーバ用プログラム、並びにメモリ管理方法を、図１に示すように、インターネット１９８とプライベートネットワーク１９９との間に設けられたプロキシサーバ２００に適用したが、これに限らず、本発明の主旨を逸脱しない範囲で他の場合にも適用可能である。例えば、プロキシサーバ２００が実現する処理をブラウザ端末３００に組み込むソフトウェアとして構成することもできる。
【図面の簡単な説明】
【図１】本発明を適用するネットワークシステムの構成を示すブロック図である。
【図２】プロキシサーバ２００の構成を示すブロック図である。
【図３】アクセス登録テーブル４００のデータ構造を示す図である。
【図４】端末管理テーブル４２０のデータ構造を示す図である。
【図５】アプレット管理テーブル４４０のデータ構造を示す図である。
【図６】アプレット存在管理テーブル４６０のデータ構造を示す図である。
【図７】アプレット存在登録処理を示すフローチャートである。
【図８】データ仲介処理を示すフローチャートである。
【図９】ブラウザ端末３００の表示画面である。
【符号の説明】
１００ ＷＷＷサーバ
１９８ インターネット
３００ ブラウザ端末
３１０ 通常端末
１９９ プライベートネットワーク
２００ プロキシサーバ
３０ ＣＰＵ
３２ ＲＯＭ
３４ ＲＡＭ
３８ Ｉ／Ｆ
４０ 入力装置
４２ 記憶装置
４４ 表示装置
４００ アクセス登録テーブル
４２０ 端末管理テーブル
４４０ アプレット管理テーブル
４６０ アプレット存在管理テーブル
Claims (16)
- ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバであって、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段と、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段と、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段と、前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段とを備えることを特徴とするプロキシサーバ。 - 請求項１において、
前記特定形式データは、実行型のプログラムデータであることを特徴とするプロキシサーバ。 - 請求項１及び２のいずれかにおいて、
前記更新命令送信手段は、前記回数計数手段で計数した送信回数が所定値以上となったときは、前記ブラウザ端末に前記更新命令を送信するようになっていることを特徴とするプロキシサーバ。 - 請求項１乃至３のいずれかにおいて、
前記サーバ側データ取得手段で取得したデータに前記特定形式データの取得要求である特定取得要求が含まれていることを検出する特定取得要求検出手段を備え、
前記回数計数手段は、前記特定取得要求検出手段で検出した特定取得要求の個数を計数することにより前記ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とするプロキシサーバ。 - 請求項４において、
前記特定取得要求を含むデータには、前記特定取得要求であることを示す要求識別情報を予め付加しておき、
前記特定取得要求検出手段は、前記サーバ側データ取得手段で取得したデータから前記要求識別情報を検出することにより当該データに前記特定取得要求が含まれていることを検出するようになっていることを特徴とするプロキシサーバ。 - 請求項４及び５のいずれかにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により前記ブラウザ端末を識別するようになっていることを特徴とするプロキシサーバ。 - 請求項６において、
前記ネットワークリソース識別情報は、ＩＰアドレスであることを特徴とするプロキシサーバ。 - 請求項４乃至７のいずれかにおいて、
複数の前記ブラウザ端末と通信可能に接続し、
前記回数計数手段は、前記各ブラウザ端末ごとに、当該ブラウザ端末への前記特定形式データの送信回数を計数するようになっていることを特徴とするプロキシサーバ。 - 請求項４乃至８のいずれかにおいて、
前記回数計数手段は、前記更新命令送信手段で前記更新命令を前記ブラウザ端末に送信したときは、当該ブラウザ端末への前記特定形式データの送信回数を初期化するようになっていることを特徴とするプロキシサーバ。 - 請求項４乃至９のいずれかにおいて、
前記特定取得要求検出手段の検出結果に基づいて前記特定取得要求に係る特定形式データが取得先のネットワークリソースに存在するか否かを判定するデータ存在判定手段を備え、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、前記特定形式データが存在しない旨の通知を行うようになっていることを特徴とするプロキシサーバ。 - 請求項１０において、
前記データ送信手段は、前記サーバ側データ取得手段で取得したデータについて、当該データに含まれる前記特定取得要求に係る特定形式データが存在しないと前記データ存在判定手段で判定したときは、当該データに代えて、前記特定形式データが存在しない旨の通知データを前記ブラウザ端末に送信するようになっていることを特徴とするプロキシサーバ。 - 請求項１０及び１１のいずれかにおいて、
前記データ存在判定手段は、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定したときは、当該特定形式データを識別するためのデータ識別情報及び当該特定形式データの取得先アドレスを対応付けて記憶手段に登録し、
前記特定取得要求検出手段で前記特定取得要求が含まれていることを検出したときは、当該特定取得要求が含まれているデータから前記データ識別情報及び前記取得先アドレスを取得し、取得したデータ識別情報及び取得先アドレスが前記記憶手段に登録されていないときは、取得先のネットワークリソースにアクセスして前記特定取得要求に係る特定形式データが存在するか否かを判定するようになっていることを特徴とするプロキシサーバ。 - 請求項１２において、
前記記憶手段には、前記ブラウザ端末がアクセスすることのある特定形式データごとに前記取得先アドレスを登録したアクセス登録テーブルを記憶させておき、
前記データ存在判定手段は、前記ブラウザ端末からの取得要求を受信する前に、前記アクセス登録テーブルの取得先アドレスをもとに前記ネットワークリソースにアクセスして該当の特定形式データが存在するか否かを判定し、当該特定形式データを識別するためのデータ識別情報及び当該特定形式データの取得先アドレスを対応付けて前記記憶手段に登録するようになっていることを特徴とするプロキシサーバ。 - 請求項１０乃至１３のいずれかにおいて、
前記ネットワークリソースを識別するためのネットワークリソース識別情報を含む取得要求を受信したときは、受信した取得要求から前記ネットワークリソース識別情報を取得し、取得したネットワークリソース識別情報により特定されるネットワークリソースが前記ブラウザ端末であると判定したときは、前記特定取得要求検出手段による検出及び前記データ存在判定手段による判定を行うようになっていることを特徴とするプロキシサーバ。 - ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバとして用いるコンピュータに、
前記取得要求に応じて前記ネットワークリソースからデータを取得するサーバ側データ取得手段、前記サーバ側データ取得手段で取得したデータを前記ブラウザ端末に送信するデータ送信手段、前記サーバ側データ取得手段で取得したデータに基づいて前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数手段、及び前記回数計数手段の計数結果に基づいて前記ブラウザ端末に前記更新命令を送信する更新命令送信手段として実現される処理を実行させるためのプログラムであることを特徴とするサーバ用プログラム。 - ネットワークリソースからデータを取得する端末側データ取得手段と、前記端末側データ取得手段で取得したデータのうち特定形式のものにスタティックメモリ管理方式によりメモリ領域を割り当てるメモリ領域割当手段と、更新命令に応じて前記特定形式データに割り当てたメモリ領域を解放するメモリ領域解放手段とを有するブラウザ端末と、前記ブラウザ端末とは異なる他のネットワークリソースとにネットワークを介して通信可能に接続し、前記ブラウザ端末からデータの取得要求を受信したときは、受信した取得要求に係るデータを取得先のネットワークリソースから取得し、取得したデータを前記ブラウザ端末に送信するサーバのメモリ管理方法であって、
前記取得要求に応じてＣＰＵが前記ネットワークリソースからデータを取得するサーバ側データ取得ステップと、前記ＣＰＵが前記サーバ側データ取得ステップで取得したデータを前記ブラウザ端末に送信するデータ送信ステップと、前記サーバ側データ取得ステップで取得したデータに基づいて前記ＣＰＵが前記ブラウザ端末への前記特定形式データの送信回数を計数する回数計数ステップと、前記回数計数ステップの計数結果に基づいて前記ＣＰＵが前記ブラウザ端末に前記更新命令を送信する更新命令送信ステップとを含むことを特徴とするサーバのメモリ管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002034713A JP3613247B2 (ja) | 2002-02-12 | 2002-02-12 | プロキシサーバ、サーバ用プログラム及びメモリ管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002034713A JP3613247B2 (ja) | 2002-02-12 | 2002-02-12 | プロキシサーバ、サーバ用プログラム及びメモリ管理方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004235121A Division JP4093215B2 (ja) | 2004-08-12 | 2004-08-12 | メモリ管理システムおよびネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003233531A JP2003233531A (ja) | 2003-08-22 |
| JP3613247B2 true JP3613247B2 (ja) | 2005-01-26 |
Family
ID=27777102
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002034713A Expired - Fee Related JP3613247B2 (ja) | 2002-02-12 | 2002-02-12 | プロキシサーバ、サーバ用プログラム及びメモリ管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3613247B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4925436B2 (ja) * | 2004-09-29 | 2012-04-25 | 株式会社Ａｃｃｅｓｓ | メモリ領域管理方法、ブラウザプログラムおよびマークアップ言語文書処理装置 |
| CN113485822A (zh) * | 2020-06-19 | 2021-10-08 | 中兴通讯股份有限公司 | 内存管理方法、系统、客户端、服务器及存储介质 |
-
2002
- 2002-02-12 JP JP2002034713A patent/JP3613247B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003233531A (ja) | 2003-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100359366B1 (ko) | 자각-개시 푸시를 제공하기 위한 방법 및 장치 | |
| US9634915B2 (en) | Methods and computer program products for generating a model of network application health | |
| US6490617B1 (en) | Active self discovery of devices that participate in a network | |
| US7277914B2 (en) | Proxy server apparatus and method for providing service using the same | |
| CA2391783C (en) | Communication between client and server computers via http, method, computer program product and system | |
| US7290262B2 (en) | Method and apparatus for dynamically determining information for deploying a web service | |
| US6167448A (en) | Management event notification system using event notification messages written using a markup language | |
| US20140026082A1 (en) | Method and system for predictive browsing | |
| EP1895401B1 (en) | Communication system and communication apparatus and control method thereof | |
| US7165222B1 (en) | Information providing method and information distribution apparatus | |
| US8589537B2 (en) | Methods and computer program products for aggregating network application performance metrics by process pool | |
| US20120290718A1 (en) | Methods and Computer Program Products for Collecting Storage Resource Performance Data Using File System Hooks | |
| US10637910B1 (en) | Method for dynamically generating information objects based on a restful subscription request | |
| CN100550015C (zh) | 改进的用户界面 | |
| JP2006260343A (ja) | リンク切れチェックプログラム | |
| KR20050045797A (ko) | 정보단말, 로그관리시스템 및 로그관리방법 | |
| US9400547B2 (en) | Processing device and method thereof | |
| JP2004192346A (ja) | メモリ管理装置、プロキシサーバ、ブラウザ端末、メモリ管理プログラム、サーバ用プログラム、端末用プログラム及び監視プログラム、並びにメモリ管理方法 | |
| JP3613247B2 (ja) | プロキシサーバ、サーバ用プログラム及びメモリ管理方法 | |
| US8326977B2 (en) | Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method | |
| US8489679B2 (en) | Method and apparatus for monitoring network traffic and determining the timing associated with an application | |
| JP4093215B2 (ja) | メモリ管理システムおよびネットワークシステム | |
| JP4102570B2 (ja) | データ取得仲介装置、プロキシサーバ及びデータ取得仲介プログラム、データ取得仲介方法、記憶媒体、並びにデータ取得仲介システム | |
| JP2006107524A (ja) | Ｗｗｗサーバー、及び、該ｗｗｗサーバーと通信回線を介して接続された利用者端末、を有するシステム | |
| JP5441167B2 (ja) | ルータ装置、転送制御方法および転送制御プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040615 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040812 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041005 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041018 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081105 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091105 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091105 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101105 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101105 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111105 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111105 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121105 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121105 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131105 Year of fee payment: 9 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |