(57)【要約】      （修正有）【課題】サーバ上のデータを、クライアントのキャッシュを利用して容易にバックアップし、また、バックアップしたデータをサーバにアップロードする方法を提案する。【解決手段】リソース・データをクライアントに送信するステップと、前記リソース・データの回復が必要か否か判断するステップと、前記リソース・データの回復が必要と判断したことに応答して、前記リソース・データに更新が無いことのメッセージと共に、前記リソース・データの回復が必要であるメッセージを伴ったＨＴＴＰ応答をクライアントに送信するステップと、前記クライアントから、前記リソース・データのバックアップを受信して回復するステップとを含む方法である。【選択図】図２
2008165363.tif 000002
【特許請求の範囲】
【請求項１】
サーバにおいて、サーバの一部のリソース・データを、ＨＴＴＰプロトコルを用いてクライアントにバックアップさせる方法であって、
前記リソース・データを前記クライアントに送信するステップと、
前記リソース・データの回復が必要か否か判断するステップと、
前記リソース・データの回復が必要と判断したことに応答して、前記リソース・データに更新が無いことのメッセージと共に、前記リソース・データの回復が必要であるメッセージを伴ったＨＴＴＰ応答をクライアントに送信するステップと、
前記クライアントから、前記リソース・データのバックアップを受信して回復するステップと
を含む方法。
【請求項２】
前記方法は、さらに、
クライアントに、ＨＴＴＰプロトコルにより要求されたデータを送信する場合に、前記リソース・データをバックアップするためのプログラムを送信するステップを含む、請求項１に記載の方法。
【請求項３】
前記プログラムは、ＪａｖａＳｃｒｉｐｔで記述されている請求項２に記載の方法。
【請求項４】
前記プログラムは、前記クライアントのウェブブラウザのキャッシュに前記リソース・データをバックアップさせるプログラムである請求項２に記載の方法。
【請求項５】
前記判断するステップは、クライアントから送られてきたＵＲＬとタイムスタンプで判断する請求項１に記載の方法。
【請求項６】
前記サーバは、ルータであり、
前記リソース・データは、前記ルータの設定情報である請求項１に記載の方法。
【請求項７】
前記サーバは、ショッピングサイトであり、
前記リソース・データは、前記ショッピングサイトを利用するユーザの個人情報であり、
前記方法は、さらに、
前記個人情報を秘密鍵を使って暗号化するステップと、
前記送信するステップの後、前記個人情報を前記サーバから削除するステップと
前記回復するステップの後、前記暗号化された前記個人情報を複合するステップと
を含む請求項１に記載の方法。
【請求項８】
前記サーバは、ショッピングサイトであり、
前記リソース・データは、前記サーバ上で保持される前記クライアントの買い物カゴ状態のデータであり、
前記方法は、さらに、
前記クライアントが、前記サーバとのセッションを買い物が完了する前に落とした場合に、前記買い物かご状態データを削除するステップと、
を含む請求項１に記載の方法。
【請求項９】
前記サーバは、Ｗｉｋｉサーバであり、
前記サーバは、重要なデータを管理する重要領域と、非重要なデータを管理する簡易領域を有し、
前記リソース・データは、前記簡易領域で管理されるデータである請求項１に記載の方法。
【請求項１０】
請求項１乃至１０のいずれか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
【請求項１１】
サーバにおいて、サーバの一部のリソース・データをＨＴＴＰプロトコルを用いてクライアントにバックアップさせる装置であって、
前記リソース・データを前記クライアントに送信する手段と、
前記リソース・データに更新があった場合に前記リソース・データを受取る前記クライアントからのＨＴＴＰのＧＥＴ要求に対して、前記リソース・データの回復が必要と判断した場合に、前記リソース・データに更新が無いことのメッセージと共に、前記リソース・データの回復が必要であるメッセージを伴ったＨＴＴＰ応答をクライアントに送信する回復判断部と、
前記クライアントから、前記リソース・データのバックアップを受信して回復する手段と
を有する装置。
【請求項１２】
前記装置は、さらに、
クライアントに前記リソース・データをブラウザのキャッシュにバックアップするためのプログラムを送信する手段を含む、請求項１１に記載の装置。
【請求項１３】
前記判断は、クライアントから送られてきたＵＲＬとタイムスタンプを使って判断する請求項１１に記載の装置。
【請求項１４】
前記サーバは、ルータであり、
前記リソース・データは、前記ルータの設定情報である請求項１１に記載の装置。
【請求項１５】
前記サーバは、ショッピングサイトであり、
前記リソース・データは、前記ショッピングサイトを利用するユーザの個人情報であり、
前記装置は、
秘密鍵と、
前記個人情報を秘密鍵を使って暗号化する手段と、
前記クライアントから、前記リソース・データを受信した後に、前記個人情報を前記サーバから削除する手段と、
を有し、
前記回復する手段は、前記暗号化された前記個人情報を複合する手段を含む
請求項１１に記載の装置。
【請求項１６】
前記サーバは、ショッピングサイトであり、
前記リソース・データは、前記サーバ上で保持される前記クライアントの買い物カゴ状態のデータであり、
前記装置は、さらに、
前記クライアントが、前記サーバとのセッションを買い物が完了する前に落とした場合に、前記買い物かご状態データを削除する手段と、
を含む請求項１１に記載の装置。
【請求項１７】
前記サーバは、Ｗｉｋｉサーバであり、
前記サーバは、重要なデータを管理する重要領域と、非重要なデータを管理する簡易領域を有し、
前記リソース・データは、前記簡易領域で管理されるデータである請求項１１に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ上のデータを、クライアントのウェブブラウザのキャッシュを利用してバックアップすることに関する。
【背景技術】
【０００２】
近年、ウェブサーバ上に蓄積されるデータ（ウェブデータ）は、その重要性を増しており、不慮の損失に備えてバックアップしておくことが必要となっている。これらのデータの総量は増加傾向にあり、ユーザ数の増加も加わり、ユーザ毎に履歴データを保持するなどデータのバックアップも多種にわたり、その結果、バックアップの作業が複雑かつ膨大になりつつある。これらのデータのバックアップをサーバ側で行なうには、サーバ提供に必要な資源コストおよび管理コストが大きくなる。現状のデータのバックアップと、バックアップデータを用いた回復作業は、サーバにおいては、テープドライブなどを利用して行われる。
【０００３】
これとは別にクライアント側で行うようなバックアップと回復作業については両方とも人手で行なうウェブアプリケーションを構築する方法が採られている。特に、小規模のウェブアプリケーションで、家庭用のネットワークルーターなどでよく見られる。これらの小規模のウェブアプリケーションでは、ＨＴＴＰ経由（ＧＥＴメソッドまたはＰＯＳＴメソッドを実行するためのコマンド入力）で、クライアントとサーバの間でバックアップデータを送受信して保存させる。また、バックアップデータからウェブデータを復元する必要が生じた場合は、ｔｙｐｅ属性がｆｉｌｅであるようなＨＴＭＬのＩＮＰＵＴ  ＦＯＲＭを用いてバックアップデータの入ったファイルを指定し、ＨＴＴＰ経由（ＰＯＳＴメソッドを実行するためのコマンド入力）でクライアントからサーバに送って回復させる。すなわち、現状ではバックアップ時と回復時にウェブブラウザの操作者が手動で行っている。
【０００４】
また、特許文献１では、クライアントがウェブサーバのコンテンツを一時的に保存するキャッシュ機能を備え、分散型のコンテンツ配信システムとしているが、ウェブサーバのコンテンツが破壊等した場合に、クライアントが保持するコンテンツを、バックアップデータとしてどのようにアップロードするかは明確に開示されていない。
【０００５】
【特許文献１】特開２００４−１８５２６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
サーバ上のデータを、クライアントのキャッシュを利用して容易にバックアップし、また、バックアップしたデータをサーバにアップロードする方法および装置を提供する。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明においては、サーバにおいて、サーバの一部のリソース・データを、ＨＴＴＰプロトコルを用いてクライアントにバックアップさせる方法を提案する。前記リソース・データを前記クライアントに送信するステップと、前記リソース・データの回復が必要か否か判断するステップと、前記リソース・データの回復が必要と判断したことに応答して、前記リソース・データに更新が無いことのメッセージと共に、前記リソース・データの回復が必要であるメッセージを伴ったＨＴＴＰ応答をクライアントに送信するステップと、前記クライアントから、前記リソース・データのバックアップを受信して回復するステップとを含む方法である。本発明の方法により、サーバのリソース・データをクライアントにバックアックし、サーバのリソース・データが損失した場合に回復する処理が容易になる。
【０００８】
以上、本発明の概要を、方法として説明したが、本発明は、装置、プログラム、またはプログラム製品として把握することもできる。プログラム製品は、例えば、前述のプログラムを格納した記憶媒体を含め、あるいはプログラムを伝送する媒体を含めることができる。
【０００９】
上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの構成要素のコンビネーションまたはサブコンビネーションもまた、発明となり得ることに留意すべきである。
【発明を実施するための最良の形態】
【００１０】
図１は、本発明の、サーバ上のデータをクライアントのキャッシュを利用して容易にバックアップし、また、バックアップしたデータをサーバにアップロードするバックアップ・システム１００の高水準の概要図である。クライアント１１０ａ−ｃ・・・は、サーバ１３０ａおよび１３０ｂとネットワーク１０１を介して接続する。サーバ１３０ａおよび１３０ｂは、ここでは例としてウェブサーバとし、複数台あるが、１台でも良い。またクライアント端末も、複数台あるが、１台でも本発明のシステムは実現可能である。
【００１１】
クライアント１１０ａ−ｃ・・・は、ネットワーク１０１を介して、ウェブサーバ１３０ａおよび１３０ｂと対話して、バックアップデータをダウンロードする。また、ウェブサーバ１３０ａまたは１３０ｂのいずれかのデータが破損した場合に、クライアント１１０ａ−ｃ・・・のいずれかの破損したバックアップデータを、ウェブサーバ１３０ａまたは１３０ｂにアップロードする。
【００１２】
図２は、本発明のバックアップ・システムの機能ブロックを概念的に示した概略図２００である。クライアント２１０ａ−ｃ・・・は、ネットワーク２０１を介してウェブサーバ２５０に接続される。２９０は、Ｒｅｓｏｕｒｃｅ  Ｐｕｂｌｉｓｈｅｒであり、ウェブサーバ２５０に保存されるリソース２６３の供給元である。このリソース２６３は、通常はウェブデータであるが、その他のバックアップが必要なデータでも構わない。ウェブサーバ２５０のリソースが原本である場合は、Ｒｅｓｏｕｒｃｅ  Ｐｕｂｌｉｓｈｅｒ２９０は本発明のバックアップ・システムでは、特に存在しなくても良い。
【００１３】
クライアント２１０ａは、ウェブブラウザ２１１を備え、Ｃｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔ２１３をダウンロードして、ウェブブラウザ２１１により、リソースのダウンロードする機能２１５、リソースのリカバリの必要性を判断する機能２１７、およびリソースをポストする機能２１９を実行する。リソースをダウンロードする機能２１５は、ウェブサーバ２５０からバックアップすべきリソース・データをダウンロードする機能である。リソースのリカバリの必要性を判断する機能２１７は、ウェブサーバ２５０で、リソース・データの回復が必要になったか否かを判断する機能である。リソースをポストする機能２１９は、ウェブサーバ２５０にリソース・データを送信する機能である。なお、２１３はＪａｖａＳｃｒｉｐｔ言語を利用しているが、他の言語や、ハード・ウェア、ソフトウェアなどを用いて構成しても良い。
【００１４】
これらの機能がいつ動作するかは、後に出てくるシーケンス図で説明する。クライアント２１０ａは、記憶装置２３１を持ち、バックアップしたソース・データ２３３を記憶する。このリソース・データ２３３は、ウェブサーバ２５０のリソース・データ２６３の一部または全部の複製である。ただし、リソース・データ２３３とリソース・データ２６３は、データフォーマットなどは異なってもよい。クライアント２１０ｂ、２１０ｃ・・もクライアント２１０ａと類似する機能を有する。
【００１５】
ウェブサーバ２５０は、Ｃｏｌｂａｃｋ  Ｓｅｒｖｌｅｔ２５１で、リソースを受信する機能２５３、リソースの回復を判断する機能２５５、およびリソースを送信する機能２５７を実行する。リソースを受信する機能２５３は、クライアント２１０から、回復すべきリソース・データ２６３を受信する。また、２５３は、Ｒｅｓｏｕｒｃｅ Ｐｕｂｌｉｓｈｅｒ２９０から、最初にバックアップの対象となるリソース・データを受信してもよいが、他の方法で受信しても良い。リソースの回復を判断する機能２５５は、リソース・データ２６３の回復が必要か否かを判断する。２５５は、リソース・データ２６３を部分毎、例えばファイル単位に回復が必要か否か判断しても良い。リソースを送信する機能２５７は、リソース・データ２６３を、クライアントにバックアップしてもらうために送信する。Ｃｏｌｂａｃｋ  Ｓｅｒｖｌｅｔ２５１は、Ｊａｖａ（登録商標）の技術を使用しているが、これＪａｖａ以外の技術で、同様の機能を実現しても良い。
【００１６】
ウェブサーバ２５０は、記憶装置２５９を有し、Ｃｏｌｂａｃｋ ＪａｖａＳｃｒｉｐｔ２６１とリソース・データ２６３を有する。Ｃｏｌｂａｃｋ ＪａｖａＳｃｒｉｐｔ２６１は、クライアント２１０が、ウェブサーバ２５０にアクセスしたときに、クライアント２１０にダウンロードされるもので、２１３のＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔ２１３と同じものである。なお、ウェブサーバは複数あっても良い。
【００１７】
図３は、ウェブサーバのリソース・データをクライアントにバックアップするシーケンスを例示したものである。以下ａ）−ｄ）の処理が行われる。
【００１８】
ａ）Ｒｅｓｏｕｒｃｅ Ｐｕｂｌｉｓｈｅｒがリソース・データをＣｏｌｂａｃｋ  Ｓｅｒｖｌｅｔに提供する（ステップ１、２）。
ここではＣｏｌｂａｃｋ  Ｓｅｒｖｌｅｔに直接提供しているが、他の方法で、例えばｆｔｐプロトコルを用いてウェブサーバにデータを提供しても良い。提供されたリソース・データは特定のURL（/.../res1）に関連付けられる。
【００１９】
ｂ）ウェブブラウザにリソース・データの複製をキャッシュする。
ウェブブラウザは、ウェブページにアクセスする（ステップ３）。ここでは、ウェブブラウザは、/…/index.htmlで表されるＵＲＬにアクセスして、要求データをＨＴＴＰのＧＥＴメソッドで取得する。その際、サーバはＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔをクライアントに送信する（ステップ４）。ウェブブラウザは、ダウンロードしたＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔを解釈して実行する（ステップ５）。Ｃｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔは、バックアップすべきリソース・データを、URL（/.../res1）を元にＣｏｌｂａｃｋ  Ｓｅｒｖｌｅｔ（ウェブサーバの記憶装置）にアクセスして（ステップ５．１）、ダウンロードする（ステップ５．２）。ウェブブラウザは、リソース・データを受取り（ステップ６）、キャッシュ処理を行う（ステップ７、８）。
【００２０】
ｃ）Ｒｅｓｏｕｒｃｅ  Ｐｕｂｌｉｓｈｅｒによりウェブサーバ上のリソース・データが更新されたとする（ステップ９、１０）。
【００２１】
ｄ）ウェブブラウザは、ウェブブラウザ上にキャッシュされたリソース・データの複製を更新する。
ウェブブラウザは、ウェブサーバ（Ｃｏｌｂａｃｋ  Ｓｅｒｖｌｅｔ）に再アクセスする（ステップ１１、１２）。図３のステップ１２では、/…/index.htmlのデータでＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔなどに変更が無い場合を例示している。/…/index.htmlのデータに変更がある場合は、ステップ１２はステップ３と同様の処理となる。ウェブブラウザがＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔを実行する（ステップ１３）。実行されたＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔはＣｏｌｂａｃｋ  ｓｅｒｖｌｅｔに対するHTTP GET要求をURL（/.../res1）とIf-Modified-Sinceをヘッダに含めて出す（１３．１）。If-Modified-Since は、要求するデータに更新があればダウンロードするという意味である。
【００２２】
HTTP GET要求を受け取ったＣｏｌｂａｃｋ  ｓｅｒｖｌｅｔはリソース・データの更新または回復の必要性をチェックする（ステップ１３．１．１、１３．１．２）。現時点ではまだリソース・データは失われていないので、Ｃｏｌｂａｃｋ  ｓｅｒｖｌｅｔはウェブブラウザから送られてきたURL（/.../res1）とヘッダから抽出したタイムスタンプ（timestamp）からウェブブラウザがキャッシュしているリソース・データの複製を更新する必要があるかどうかを確認する。リソース・データの複製を更新する必要があるので、ウェブブラウザ（Ｃｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔ）に200 OKのHTTP応答とともに更新されたリソース・データの複製を返す（１３．２）。仮にリソース・データの複製を更新する必要がなければ、303 Not ModifiedのHTTP応答を返す。200 OKを受け取ったウェブブラウザは複製で以前にキャッシュされたリソース・データの複製を受け取った新たなリソース・データによって更新する（ステップ１５、１６）。
【００２３】
図４は、クライアントにバックアップしたソース・データで、ウェブサーバのリソース・データを回復するシーケンスを例示したものである。以下ｅ）−ｆ）の処理が行われる。
【００２４】
ｅ）ウェブサーバに保持しているリソース・データが、何らかの原因でクラッシュして失われたとする。（ステップ１７、１８） 
【００２５】
ｆ）リソース・データを回復する。
ウェブブラウザは、ウェブサーバ（Ｃｏｌｂａｃｋ  Ｓｅｒｖｌｅｔ）にアクセスする（ステップ１９、２０）。ステップ２０では、/…/index.htmlのデータでＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔなどに変更が無い場合を例示している。ウェブブラウザがＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔを実行する（ステップ２１）。実行されたＣｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔはＣｏｌｂａｃｋ  ｓｅｒｖｌｅｔに対するHTTP GET要求をURL（/.../res1）とIf-Modified-Sinceをヘッダに含めて出す（２１．１）。If-Modified-Since は、要求するデータに更新があればダウンロードするという意味である。HTTP GET要求を受け取ったＣｏｌｂａｃｋ  ｓｅｒｖｌｅｔはリソース・データの更新または回復の必要性をチェックする（ステップ２１．１．１、２１．１．２）。
【００２６】
ここではリソース・データが失われた直後なので、Ｃｏｌｂａｃｋ  ｓｅｒｖｌｅｔはウェブブラウザから送られてきたURL（/.../res1）とタイムスタンプ（timestamp）から、ウェブブラウザがキャッシュしているリソース・データの複製から失われたデータが回復できることを確認する。確認の結果回復できると判断し、ウェブブラウザに304 Not ModifiedのHTTP応答を回復処理の要求を示す特別なヘッダ（Cache-Control: ColBack=DoRecovery）付きで返す（ステップ２１．２）。この従来からある304 Not ModifiedのHTTP応答を利用することにより、ウェブブラウザは、新たに要求データ（ここでは…/index.html）をダウンロードすること次の処理を続けられる。
【００２７】
仮にリソース・データの複製が古すぎるなどの理由により回復できないと判断した場合は、データが見つからないことを示すために404 Not FoundのHTTP応答を返すか、リソース・データの回復まではサービスが利用できないことを示すために503 Service UnavailableのHTTP応答を返す。そして、ウェブブラウザは、Cache-Control: ColBack=DoRecovery付き304 Not ModifiedのHTTP応答を受け取ったキャッシュからリソース・データの複製をメモリ上に取り出し（ステップ２１．３）、それをＣｏｌｂａｃｋ  Ｓｅｒｖｌｅｔに送信する（ステップ２１．５）。資源の複製を受け取ったＣｏｌｂａｃｋ  Ｓｅｒｖｌｅｔはそれをリソース・データの保管場所に格納することにより失われた資源を回復する（ステップ２１．５．１）。Ｃｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔとウェブブラウザは回復処理が成功した旨を受け取る（ステップ２１．６、２２）。
【００２８】
Ｃｏｌｂａｃｋ  ＪａｖａＳｃｒｉｐｔのうち、Ｃｏｌｂａｃｋ  Ｓｅｒｖｌｅｔに対してIf-Modified-Sinceを含むヘッダ付きのHTTP要求を出し、その応答からキャッシュの更新、または資源の回復を行うプログラムコードを以下に例示する。
【００２９】
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>ColBack JavaScript</title>
<script type="text/javascript">
//<![CDATA[
var lastModified = "Thu, 01 Jun 1970 00:00:00 GMT";
function isRecoveryNeeded(req) {
var cacheControl = req.getResponseHeader("Cache-Control");
return cacheControl && cacheControl.match(/\s*ColBack\s*=\s*\"DoRecovery\"\s*/);
}
function checkStatus() {
var req = new XMLHttpRequest();
req.open("GET", "resource", false);
req.setRequestHeader("If-Modified-Since", lastModified);
req.send("");
if(req.getAllResponseHeaders().match("Last-Modified")) {
lastModified = req.getResponseHeader("Last-Modified");
}
if (req.status == 200 || req.status == 304) { // OK or Not Modified
if (isRecoveryNeeded(req)) {
var responseText = req.responseText
// send req.responseText to the ColBack servlet for recovery
req.open("POST", "recovery ", false);
req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
req.send('value=' + responseText);
} else {
// cache may be updated
}
}
}
//]]>
</script>
</head>
<body>
<button onclick="checkStatus()">Check Status</button>
<div id="content"></div>
</body>
</html>
【００３０】
本発明では、HTTP 1.1を基準にして例示したものである。HTTP 1.1にはCache Control Extensionsの機能があり、304 Not ModifiedのHTTP応答で許されたCache-Controlヘッダの値として、「名前=値」の形式で任意の文字列を指定できる。そこで、本発明では、資源の回復が必要であることを示すために、304 Not ModifiedのHTTP応答で、Cache-Control:ColBack=DoRecovery、を使用するものとした。
【００３１】
もしCache-Control: ColBack=DoRecoveryを利用しない場合は、図３および４における、ステップ５．１、１３．１、２１．１のHTTP要求を出す前、または出すと同時に（別スレッドを使用）、別のHTTP要求によって明示的に回復の必要性を確認することも可能である。すなわち、当業者にとっては、ブラウザの種類に依存する条件などにより、上記シーケンスを変更した方法で、本発明の目的を達成できることは自明である。
【００３２】
（応用例１）
図５は、本発明を利用した、ポータルサイトなどでポートレットの管理するデータの自動バックアップ・回復の実施例を示したものである。ポートレット５３１では、ポートレット設定５３３、ポートレットデータ５３５、およびポートレットセッション５３７という３種類の利用者個人データをクライアント５２０ａで管理する。ポートレットはクライアント５２０ａの持つ５３１とポータルサイトの５１３ａが対応し、クライアント５２０ａの持つ５３１ｂとポータルサイトの５１３が対応する。従来はデータ５１３ａ、５１３ｂ・・のバックアップはポータルサイトが行う必要があり、コストが大きかったが、本発明により、ポータルサイトのポートレットは削除しても回復が可能になる。本発明の機構はポートレットのデータを自動的にバックアップし、回復することを容易にする。図５の場合では、ポートレットコンテナもしくはポートレットにＣｏｌｂａｃｋ  ｓｅｒｖｌｅｔの機能を追加することで実現できる。
【００３３】
（応用例２）
図６は、本発明を利用した、ルータの設定情報の自動バックアップ・回復の実施例を示したものである。従来、ルータは管理者用の設定管理インタフェイスとしてウェブサーバの機能６４０を内包しているものもあり、管理者のコンピュータからウェブブラウザである特定のURLにアクセスすることにより設定を管理できるようになっている。管理者は保存コマンドの実行（保存ボタンを押すなど）によりルータからブラウザにダウンロードされたファイル（設定情報）をコンピュータのハードディスクに保存し、設定情報のバックアップを行う。また、保存したファイルの場所を指定し、復元コマンドを実行する（復元ボタンを押すなど）ことにより、保存したファイルから設定情報を回復することができる。
【００３４】
このように、従来は管理者が明示的に設定をファイルとして保存し、必要に応じて手動で復元を行う必要があった。本発明の機構を用い、ブラウザのキャッシュにルータの設定情報を保存することによって、設定情報のバックアップと回復を管理者の手を煩わせることなく自動的に行うことができる。
バックアップは以下のステップで行う。
１）管理者がルータの設定情報を更新するため、ブラウザ上の「設定更新」ボタンを押す
２）ルータが更新後の設定情報６１３を保存する
３）ルータがブラウザに返答を返すことによりブラウザのキャッシュにルータの設定情報６３１を保存する（図３ステップ３−１１を実行）
【００３５】
回復は以下のステップで行う。
１）管理者が設定を確認するためブラウザで設定画面を開くことにより図４の１９を開始し、キャッシュ上のルータの設定情報６３１から元のルータの設定情報６３１を回復する
２）この方法は、ルータに限らず、ネットワークに接続されウェブブラウザによるインタフェイスを持った他の情報機器（ハードディスクレコーダーなど）にも適用できる。
【００３６】
（応用例３）
図７は、本発明を利用した、ショッピングサイトなどでの個人情報の恒久的な保存を回避するための実施例を示したものである。ショッピングサイトなどでは、最初の利用の際に個人情報を登録しておくと、次回の利用からサーバに保存した個人情報を自動的にフォームへの入力をしてくれるサイトがある。しかし、一方で昨今の個人情報保護に対する関心の高まりとともに、サイトの運営者はできる限り個人情報を保有したくないと考えるようになってきている。ここで言う個人情報には、氏名・住所・クレジットカード番号だけでなく、利用者が過去にした買い物の履歴なども含まれ、これらを含む情報は、ある程度大きいことが想定される。
【００３７】
以下の手順での個人情報の安全性を高めたやり取りをサーバとクライアント間で行う。
（ａ）ユーザがサイトを最初に利用する
１）ユーザが個人情報を入力しサーバに送信する
２）サーバは、サーバの秘密鍵７１５ａで「買い物履歴」を含む個人情報７１３ａを署名・暗号化し、ブラウザに送り返して７３１ａを個人情報の複製としてキャッシュさせておく（同時に図３ステップ５−８を実行）
３）サーバは個人情報を使ってアプリケーションの帳票の処理を完了させる
４）サーバは個人情報をディスク上から削除する
【００３８】
（ｂ）ユーザがサイトを再度利用する
１）本発明を適用してウェブブラウザのキャッシュ上の個人情報をサーバに送り、サーバは署名を確認、復号化し、個人情報をフォームに自動入力する（図４ステップ１９−２２を実行）
２）「買い物履歴」を元にお薦め商品を表示する
３）サーバは個人情報を使ってアプリケーションの帳票の処理を完了させる
４）サーバは個人情報をディスク上から削除する
【００３９】
これにより、サーバの秘密鍵と暗号化されたデータが、サーバとクライアントという異なる場所に保存される。仮に（ａ）の後でサーバの秘密鍵が盗まれたとしても、暗号化されたデータはクライアントのディスク上にあるため、双方がサーバ上に存在する場合に比べてより安全である。また、サイトの運営者が、個人情報の自動入力という利便性を損なうことなく、個人情報の扱いに関して「帳票が処理されたら即座に削除している」と利用者に対して明言でき、サービスの付加価値とすることができる。
【００４０】
（応用例４）
図８は、匿名のショッピングサイトでの買い物の実施例を示したものである。以下の手順で買い物カゴ情報のバックアップを実行する。
１）ユーザは、匿名（ログインなし）でショッピングサイトを利用
２）ユーザは、買い物カゴに、さまざまな買い物（Tシャツなど）を様々なオプション（プリントするイメージなど）を指定して品物を買い物カゴ８１３ａに追加し、クライアント側にも８３１ａを保存（図３ステップ１３−１６を実行）
３）ユーザは、ブラウザ・アプリケーションをなんらかの理由で一旦落とす
４）ユーザは、ブラウザ・アプリケーションを再び起動して、ショッピングサイトへ
５）ショッピングサイトは、前回の買い物カゴ８３１ａのデータを復帰（図４ステップ１９−２２を実行）
６）ユーザは、追加の買い物をするなどした後、ログイン情報やカード情報を入力して購入
【００４１】
現状では、ショッピングサイトサーバ側で、買い物カゴ状態を保管、保管ＩＤをCookieとしてクライアントに保管させる方法が取られている。しかし、多くののユーザがいる状態では買い物カゴの数が膨大になりサーバ側の管理コストが大きくなっていた。一方、本発明を用いると、買い物カゴ状態を、サーバ側にテンポラリに保管するとともに、そのバックアップのデータをクライアント側に保管することができる。そして、サーバ側が、時間や要領制限などで、買い物カゴ状態をパージしてしまっても復帰可能になる。
【００４２】
（応用例５）
図９は、社内のWikiサーバのバックアップの実施例を示したものである。以下の手順でWikiサーバのバックアップを実行する。
１）管理者は、厳重なバックアップ（高コスト）の必要な重要領域９１５と、そうでない簡易領域９１３を用意
２）利用者は、業務上重要な情報は厳重な重要領域９１５へ、そうでもないもの（クラブ活動など）は簡易領域９１３へ書き込み、非重要情報９１３ａをクライアントで９３１ａとして保存する（図３ステップ３−８を実行）
３）サーバのディスク故障や、操作上のアクシデントにより、簡易領域のデータが失われる
４）サーバは、本発明を利用して簡易領域のデータを（部分的にでも）復帰（図４ステップ１９−２２を実行）
【００４３】
現状、バックアップは高コストであるか、まったくバックアップがないかのどちらかであるが、業務上重要でないが、簡易でもバックアップがあると便利である場合が多くある。
【００４４】
図１０は、本発明の実施の形態によるクライアント２１０およびウェブサーバ２５０を実現するのに好適な情報処理装置のハードウェア構成の一例を示した図である。
【００４５】
情報処理装置は、バス１００２に接続されたＣＰＵ（中央処理装置）１００１とメインメモリ１００４を含んでいる。ハードディスク装置１０１３、１０３０、およびＣＤ−ＲＯＭ装置１０２６、１０２９、フレキシブル・ディスク装置１０２０、ＭＯ装置１０２８、ＤＶＤ装置１０３１のようなリムーバブル・ストレージ（記憶メディアを交換可能な外部記憶システム）がフロッピーディスクコントローラ１０１９、ＩＤＥコントローラ１０２５、ＳＣＳＩコントローラ１０２７などを経由してバス１００２へ接続されている。
【００４６】
フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭのような記憶メディアが、リムーバブル・ストレージに挿入される。これらの記憶メディアやハードディスク装置１０１３、１０３０、ＲＯＭ１０１４には、オペレーティング・システムと協働してＣＰＵ等に命令を与え、本発明を実施するためのコンピュータ・プログラムのコードを記憶することができる。メインメモリ１００４にロードされることによってコンピュータ・プログラムは実行される。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記憶することもできる。
【００４７】
情報処理装置は、キーボード／マウス・コントローラ１００５を経由して、キーボード１００６やマウス１００７のような入力デバイスからの入力を受ける。情報処理装置は、視覚データをユーザに提示するための表示装置１０１１にＤＡＣ／ＬＣＤＣ１０１０を経由して接続される。
【００４８】
情報処理装置は、ネットワーク・アダプタ１０１８（イーサネット（Ｒ）・カードやトークンリング・カード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。図示はされていないが、パラレルポートを介してプリンタと接続することや、シリアルポートを介してモデムを接続することも可能である。
【００４９】
以上の説明により、本発明の実施の形態によるシステムを実現するのに好適な情報処理装置は、通常のパーソナルコンピュータ、ワークステーション、メインフレームなどの情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。
【００５０】
本発明の実施の形態において使用される情報処理装置の各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得ることは勿論である。それらの変更は、当然に本発明の思想に包含される概念である。
【００５１】
本発明の実施形態によるシステムは、マイクロソフト・コーポレーションが提供するＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システム、アップル・コンピュータ・インコーポレイテッド提供するＭａｃＯＳ（Ｒ）、Ｘ  Ｗｉｎｄｏｗ  Ｓｙｓｔｅｍを備えるＵＮＩＸ（Ｒ）系システム（例えば、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＡＩＸ（Ｒ）など）のような、ＧＵＩ（グラフィカル・ユーザー・インターフェース）マルチウインドウ環境をサポートするオペレーティング・システムを採用することができる。
【００５２】
以上から、本発明の実施の形態において使用されるシステムは、特定のオペレーティング・システム環境に限定されるものではないことを理解することができる。すなわち、オペレーティング・システムは、アプリケーション・ソフトウェアなどがデータ処理システムの資源を利用できるようにする資源管理機能を提供することができるものであれば、いかなるものをも採用することができる。なお、資源管理機能には、ハードウェア資源管理機能、ファイルハンドル機能、スプール機能、ジョブ管理機能、記憶保護機能、仮想記憶管理機能などが含まれ得るが、これらの機能については、当業者によく知られたものであるので詳細な説明は省略する。
【００５３】
また、本発明は、ハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実行において、所定のプログラムを有するデータ処理システムにおける実行が典型的な例として挙げられる。かかる場合、該所定プログラムが該データ処理システムにロードされ実行されることにより、該プログラムは、データ処理システムを制御し、本発明にかかる処理を実行させる。このプログラムは、任意の言語・コード・表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接、または１．他の言語・コード・表記への変換、２．他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。
【００５４】
もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記憶した媒体もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ読み取り可能な記憶媒体に格納することができる。かかるプログラムは、記憶媒体への格納のために、通信回線で接続する他のデータ処理システムからダウンロードしたり、他の記憶媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記憶媒体に格納することもできる。また、様々な形態で、本発明を実施するプログラム製品を提供することも勿論可能であることにも留意されたい。
【００５５】
以上、本発明の実施形態によれば、ウェブサーバのリソース・データをクライアントにバックアップし、また、ウェブサーバのリソース・データが破損した場合に、クライアントがバックアップしたリソース・データから回復できるシステムを容易に構築することができることが理解される。
【００５６】
上記の実施の形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれることに留意されたい。
【図面の簡単な説明】
【００５７】
【図１】本発明の、サーバ上のデータをクライアントのキャッシュを利用して容易にバックアップし、また、バックアップしたデータをサーバにアップロードするバックアップ・システム１００の高水準の概要図である。
【図２】本発明のバックアップ・システムの機能ブロックを概念的に示した概略図２００である。
【図３】ウェブサーバのリソース・データをクライアントにバックアップするシーケンスを例示したものである。
【図４】クライアントにバックアップしたソース・データで、ウェブサーバのリソース・データを回復するシーケンスを例示したものである。
【図５】本発明を利用した、ポータルサイトなどでポートレットの管理するデータの自動バックアップ・回復の実施例を示したものである。
【図６】本発明を利用した、ルータの設定情報の自動バックアップ・回復の実施例を示したものである。
【図７】図７は、本発明を利用した、ショッピングサイトなどでの個人情報の恒久的な保存を回避するための実施例を示したものである。
【図８】匿名のショッピングサイトでの買い物の実施例を示したものである。
【図９】社内のWikiサーバのバックアップの実施例を示したものである。
【図１０】本発明の実施の形態によるクライアント２１０およびウェブサーバ２５０を実現するのに好適な情報処理装置のハードウェア構成の一例を示した図である。
【図１】
2008165363.tif 000003
【図２】
2008165363.tif 000004
【図３】
2008165363.tif 000005
【図４】
2008165363.tif 000006
【図５】
2008165363.tif 000007
【図６】
2008165363.tif 000008
【図７】
2008165363.tif 000009
【図８】
2008165363.tif 000010
【図９】
2008165363.tif 000011
【図１０】
2008165363.tif 000012