JP2004341967A - ソフトウェアリソース管理方法 - Google Patents

Abstract

【課題】ソフトウェア配信システムにおいて配信するソフトウェアリソースの増大に伴い管理が煩わしくなってきている。
【解決手段】ソフトウェア配信システムのソフトウェアリソースを決められたルールに基いて自動的に削除する機能と必要に応じて自動的に回復する機能を提供する。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
本発明は複数台のコンピュータとネットワークにより構成するソフトウェア配信管理システムにおいて、配信するソフトウェアリソースを管理するための方法に関する。
【０００２】
【従来の技術】
従来より、複数のコンピュータをネットワークで接続し、一方のコンピュータからネットワークを経由してもう一方のコンピュータにソフトウェアやデータなどのソフトウェアリソースを配信する機能をもつソフトウェア配信管理システムが発案され、さまざまなベンダーより製品および実用化がなされている。
【０００３】
ソフトウェア配信管理システムの概要の一例を図１を用いて簡単に説明する。ソフトウェアリソース１０３（以下リソースと略す）の登録システムから、リソースを配信管理サーバ１０１に登録する。リソースは媒体１０２に格納される。配信管理サーバから、中継サーバ１０５やクライアント１０６〜１１０に対してリソースの配信をネットワーク１０４を経由して行うものである。中継サーバ１０５を設置し、中継サーバにリソースをキャッシングし、中継サーバからクライアント１０８〜１１０に対してリソースを配信することにより、分散的で効率良いリソース配信が可能である。各クライアントは、配信結果の情報を配信管理サーバに送付することにより、配信管理サーバでは、どのクライアントに対してどのリソ−スを配信したかどうかを一元的に管理できるようになる。
【０００４】
配信管理サーバに保持するリソースについて従来では手動により削除を行っていた（例えば、特許文献１参照。）。例えば、特許文献１においては配信する情報としてルールベースというデータを扱っているが、ＧＵＩ上の削除ボタンによって手動により削除を行っている。
【０００５】
【特許文献１】
特開２００２−３５１６６４号公報
【０００６】
【発明が解決しようとする課題】
パーソナルコンピュータやワークステーションが普及浸透すると共に、配信管理サーバにおいて配信する必要のあるリソースが多種多様化してきていること、過去に配信したリソ−スのバージョンアップが繰り返し行われることにより、管理しなければならないリソースの数も増え、配信不要な例えば古いソフトウェアなどを削除する必要が生じてきている。
【０００７】
特に、近年では、コンピュータウィルスの流行により、ウィルスを検知および駆除するためのソフトウェアやパターンファイルのバージョンアップが日々行われており、管理するリソースの数は日増しに急増傾向になってきている。ただし、リソースは、もともと重要なデータであったりソフトウェア資産価値を含んでいる事情もあり、その性質上手動により確認しながら削除する必要があるが、誤操作により必要なソフトウェアリソースを削除してしまうことがある。また、一旦削除してしまったソフトウェアリソースは再度登録システムから登録しなおす必要があり手間がかかっていた。本発明では、これらの課題を解決することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、ソフトウエアリソース管理方法において、リソースをあらかじめ設定したルールに基き、自動的に削除できるようにすることで解決できる。さらに、配信管理サーバにおいては、配信処理の関係でリソースが必要となったり、登録したリソースが重要な情報であったり資産価値をもつ側面も持つことから、一気に削除してしまうのではなく、必要に応じて一時的に保管管理、バックアップや元の状態に回復できるようにする。
【０００９】
【発明の実施の形態】
以下、本発明の実施例を図面に基づいて詳細に説明する。図２は、本発明における実施例である配信管理システムの構成を示す図である。配信管理サーバとして計算機２００上に配信管理サーバのプログラム２０２、２０６、２０７、２１０、２１１を動作させる。計算機２１３上にはリソースの登録システムとして、リソース登録処理のプログラム２１４を動作させる。なお、登録システムは独立した計算機上に配置する必要はなく、配信管理サーバ２００上でも動作させることができる。コンピュータアーキテクチャの違いにより扱うリソースをシステム毎に分ける必要がある場合に登録システムを個別に存在させる必要がある。計算機２１７上には中継サーバとして、中継処理を行うためのプログラム２１８、２１９を動作させる。
【００１０】
なお、本説明では省略しているが中継サーバはシステム構成上の上位システムである配信管理サーバからの配信指示を受信する処理が存在する点を除けば基本的に配信管理サーバとほぼ同様のシステム構成となる。計算機２１５上にはクライアントとして、リソースを受信するためのプログラム２１６を動作させる。
【００１１】
リソースを登録し配信するまでの基本的な動作を説明する。なお実施の形態における流れ図には特に記載はしないがリソースを扱う部分には排他制御が施されており、リソースの登録処理やリソースの配信処理において競合が発生しても不正な状態にならないものとする。
【００１２】
最初にリソースの登録処理について図５を用いて説明する。サーバ側はリソース登録システムからの登録要求を待っている状態（５０６）で、リソース登録システムからリソースの登録要求（５０１）を受信したら、サーバ側が持つリソースの一覧をリソースが持つ属性と共にすべての情報を引き渡す（５０７、５０２）。
【００１３】
リソース登録システム上で登録するリソースの名称、バージョン、リビジョンを設定し（５０３）、受け取った一覧情報を検索して既に同一のリソースが登録されていないかどうかを確認する（５０４）。リソース名称やバージョン、リビジョンの設定は、リソースの管理や配信するリソースの見分けを容易につけるために設定する。リビジョンとはマイナーバージョンの意味である。リソース名称、バージョン、リビジョンを組み合わせた名称で同一名称の既に登録済みのリソースがある場合は再度設定し直す（５０４、５０３）。
【００１４】
予め、重複するリソースを参照できるようにするため、サーバから受け取ったリソース情報の一覧を基にリソースの一覧をコンソールなどに表示し参照できるようにすることもできる。なお、サイズ、登録日はユーザが設定しても良いが、ＯＳのＡＰＩなどを使用して求め、属性値を設定する。また、リソースについては、複数のファイルにより構成する場合は管理しやすいようにするため一つのファイルにアーカイブして登録する。アーカイブしたファイルは、例えばネットワークが公衆回線であった場合はセキュリティ維持のために暗号化したり、例えばネットワークが低速回線であった場合は転送量を減らすため圧縮化することも可能であり、配信後にクライアント側で圧縮、暗号を解除する。
【００１５】
既に登録済みのリソースが存在しない場合は、アーカイブしたファイルを新たなリソースとしてリソースの属性情報と共にサーバ側に送信する（５０５）。サーバ側はリソースとそのリソースの属性情報を受信し、リソースはディスクに格納し、属性情報はリソース管理テーブルに設定する（５０８）。
【００１６】
図３にリソース管理テーブルを示す。それぞれの情報は、登録システム側で設定した属性情報が入る。ファイルパス３０７には格納先ディスクのパスが設定される。リソース名称、バージョン、リビジョンの組み合わせにより、ユニーク性を持つ。例えば、図３に示すようにリソース名称が同一でもバージョン、リビジョンが異なれば、別のリソースとして存在するものとする（３０８、３０９、３１０）。リソースが正しく格納できたら、登録を完了し再び登録要求の待ち状態となる（５０６）。登録システム側は登録処理を終了する。
【００１７】
次に、リソースの配信処理について図６を用いて説明する。配信処理はサーバからどのクライアントにどのリソースを配信するかを決定し配信指示情報を作成する（６０１）。配信指示は詳細に説明しないが、配信するあて先と配信するリソース（リソース名称、バージョン、リビジョン）により構成される情報である。作成の際にはリソース管理テーブルから配信するリソースを選択する。そして、配信指示情報を基に配信するクライアントに対して配信指示を渡す（６０２）。
【００１８】
クライアント側では、サーバ側からの配信指示を待っている状態となっており（６０６）、配信指示を受けたらサーバからリソースを受信する（６０３、６０７）。配信が何らかの理由により失敗した場合は何回かリトライを試み配信が成功するまで繰り返す（６０４、６０３）。クライアント側では、リソースの受信が完了したら、例えばリソースがアプリケーションの場合はインストールプログラムを起動しインストールを実施し、例えばユーザデータであれば所定の位置にファイルをコピーするなど、リソースに合わせたインストール処理を行う。インストールが完了したら、サーバ側にインストール結果情報を送信する（６０８）。
【００１９】
サーバ側はインストール結果情報を受信したら図４に示す配信結果テーブルのインストール回数（４０２）を加算し、最終アクセス日（４０４）を実行した日に設定して更新する（６０５）。配信が終了したら、クライアント側は再びサーバからの配信指示の待ち状態となる（６０８、６０６）。サーバ側も再び配信指示作成待ちとなる（６０５、６０１）。なお、サーバ側の配信処理はマルチスレッドを用いることにより、並行して複数のクライアントあての配信処理ができるものとする。
【００２０】
リソースの配信結果についての配信結果テーブルを図４に示す。通番４０１は、図３のリソース管理テーブルの通番３０１とリンクしており、何のリソースが配信されたかどうかを把握できる。クライアントへのインストールの場合は、インストール回数４０２がクライアントにインストールした分更新され、どれぐらいのクライアントに配信が行われたかを把握できる。通番１を例にすると、‘Ａ’という名称のリソースは、２０台のクライアントに配信されたことが分かる。
【００２１】
図６では、サーバ側でクライアントに対し配信するリソースを選択するサーバ側が主導して配信を行う方法であるが、図７にはクライアント側が欲しいリソースを選択して配信するクライアント側が主導する配信の方法について説明する。まず最初に、サーバ側で登録されているリソース管理テーブルを参照し接続している全クライアント宛に配信指示情報を作成しておき（７０１）、クライアントからの配信要求の待ち状態となる（７０２）。クライアント側では、サーバに接続し配信可能なリソースの一覧情報を受け取る。さらに、そのリソース情報の中から受信したいリソースをユーザが選択して配信要求を行う（７０７）。クライアントが配信要求したリソースについて、サーバからクライアントに対して配信を行う（７０３、７０８、７０４）。リソースを配信後、クライアントでインストールを行い、インストール結果をサーバ側に送信する（７０９、７０５）。サーバ側では、リソースの追加や削除、接続するクライアントに変更が生じたら配信指示を変更し、クライアント側からの配信要求の待ち状態となる（７０６、７０２）。
【００２２】
次に、図８には中継サーバを経由して配信する際の方法について説明する。中継サーバを経由して配信したいクライアントとリソース管理テーブル内の配信したいリソースから配信指示情報を作成し（８０１）、中継サーバに対して配信指示を渡す（８０２）。中継サーバ側では、サーバ側からの配信指示を待っている状態となっており（８０６）、配信指示を受けたらリソースを受信する（８０３、８０７）。
【００２３】
リソースの受信が完了したら、中継サーバが持つリソース管理テーブルとディスクに格納する（８０８）。そして、下位システムであるクライアントに対して配信指示情報を転送し、サーバ側に、ダウンロード結果情報を送信する（８０９）。そして、下位クライアントからの配信指示があれば、サーバ側に渡す（８１０）。サーバ側は図４に示す配信結果テーブルのダウンロード回数（４０３）を加算し、下位クライアントからの配信結果の通知があればインストール回数（４０２）を加算し、最終アクセス日（４０４）を実行した日に設定して更新する（８０５）。転送が終了したら、中継サーバ側は再びサーバからの配信指示の待ち状態となる（８０９、８０６）。サーバ側も再び配信指示作成待ちとなる（８０５、８０１）。
【００２４】
これにより、中継サーバの下位のクライアントは中継サーバからリソースを配信できる。中継サーバ上のリソースはキャッシュの役割を果たし、これにより分散的に効率よく配信できる。中継サーバへ何回ダウンロードしたかどうかを確認するには、配信結果テーブルのダウンロード回数４０３を参照することにより把握できる。通番１を例にすると、「Ａ」という名称のリソースは、１０台の中継サーバに対してダウンロードしたことが分かる。また、インストール回数の情報も含めて、当該リソースへの最終アクセスがいつ行われたのかを把握できる。以上が基本的なリソースの登録から配信するまでの説明である。
【００２５】
次に、本発明である配信管理システムにおけるリソースの管理方法について説明する。まず、リソースをどのように扱うかを図２３を使用して説明する。登録されたリソースは、通常状態で配信に使用される（２３０１）。リソースに対してルールを設け、新たにリソースを登録した時などのイベントが生じたときにルールに従い完全に削除（２３０４）、削除への猶予期間を設けた一時保管状態（２３０２）、削除禁止（２３０３）にする。
【００２６】
削除および一時保管状態になるには、例えばディスク容量の制限やリソースの個数の上限などを設定したルールに抵触した場合である。削除禁止になるには、登録した日からある一定の年月を経過しても削除処理されなかった場合である。削除禁止は古いリソースにもかかわらず配信には使用されるが、リソースの元となるファイルが古い故に製造中止などにより回復が困難であるため削除されないようにすることを想定している。一時保管状態になったリソースについては、完全に削除するまでの猶予期間を設けたもので、その間に使用された場合に、まだニーズがあるものとして猶予期間を延長したり再び通常状態にするために再登録し、使用されない場合は削除する。一時保管は一旦削除扱いとした後も配信に使用される場合に対処できるようにすることを想定している。
【００２７】
図９には、本発明のためのリソース管理テーブルの内容を示す。図３と比較すると、リソースの配信可能な期限を設定する使用期限日９０７、一時保管状態にしたリソースをいつまで保管するかを設定する保管期限日９０８、全リソースにおける当該リソースのプライオリティであることを示す重要度９０９、当該リソースの削除の状態を示すステータス９１０、当該リソースの削除方法９１２、当該リソースの回復方法９１３の情報が追加されている。図９には回復方法に設定するパラメータの例９１４を示す。通番の‘２’のリソースについても例９１４と同様に何らかの値が設定されているが説明は省略する。
【００２８】
図１０には、図９のリソース管理テーブルに設定される定義を示す。定義１００１は、図９のステータス９１０に設定される定義の一覧である。‘１’から‘５’の定義を持つ。‘１’は通常のステータスであるリソースであることを示す。‘２’は新たに配信対象にはできないが、下位システムからの配信要求に備えてリソースの実体であるファイルを一時的に保管しておくリソースであることを示す。‘３’は‘２’と同じであるが、リソースの実体を圧縮した状態で保管しておくリソースであることを示す。‘４’は新たに配信対象にできるが、リソースの実体であるファイルを削除した状態で保管しておくリソースであることを示す。‘５’は絶対に削除されずに保管しておくリソースであることを示す。なお、ステータスを図２３に当てはめると‘１’は通常状態、‘２’、‘３’、‘４’は一時保管状態、‘５’は削除禁止状態である。
【００２９】
定義１００２は、図９のリソースの削除方法９１２に設定される定義の一覧である。‘１’から‘４’の定義を持つ。‘１’はリソースの実体であるファイルは残す一時保管状態ステータスにするリソースであることを示す。‘２’は‘１’と同じであるがリソースの実体であるファイルを圧縮する一時保管状態ステータスにするリソースであることを示す。‘３’はリソースの実体であるファイルを削除する一時保管状態ステータスにするリソースであることを示す。‘４’はリソースの実体であるファイルを削除すると共にリソース管理テーブルからも削除するリソースであることを示す。‘１’および‘２’のリソースについては配信処理において新たに配信指示することができないものとし、配信指示が中継サーバおよびクライアントに渡ったあとのタイミングでリソースが削除されてしまったケースに対処するためのものである。また、‘３’のリソースについては、定義１００３のリソースの回復方法で示す回復方法で回復し、主としてディスク容量の増大化を防ぐことを意識したものである。設定時は当該リソースの利用頻度をある程度予想し回復方法を適切な方法に設定する必要がある。
【００３０】
定義１００３は、図９のリソースの回復方法９１２に設定される定義の一覧である。‘１’から‘６’の定義を持つ。‘１’はインターネットを経由してリソースであるファイルをダウンロードして回復する方法をとるリソースであることを示す。‘２’はリソースの作成者宛てもしくは作成した企業宛てに向けてメールを送りリソースであるファイルを入手して回復する方法をとるリソースであることを示す。‘３’はＣＤ−ＲＯＭなどのインストールメディアからリソースであるファイルを戻して回復する方法をとるリソースであることを示す。‘４’はリソースの登録の際にあらかじめ別のディスクに取得しておいたバックアップからリソースを取得して回復する方法をとるリソースであることを示す。‘５’は中継システム上のキャッシュとして保持しているリソースを吸い上げて回復する方法をとるリソースであることを示す。‘６’は、当該リソースを回復せず、当該リソースの最も上位のリビジョンのリソースを代わりに配信する方法をとるリソースであることを示す。この回復方法は、コンピュータウィルスの対策ソフトウェアなどのように日々リソースが更新され、常に最新のリソースを適用した方がシステムの運用上効果的なリソースについて指定する。なお、本発明においては、リビジョンのみを適用しているが、バージョンを適用することもできる。
【００３１】
図１１は削除ルール管理テーブルの内容を示す。テーブルは、リソースがどのような状況になった場合に削除するのかを示すルールの内容１１０１、ルールを適用するか否かを示す適用１１０２、リソースが削除に到るまでにどのタイミングで警告を出すかを示す警告１１０３、ルール適用時にどの範囲でリソースを削除するかの削除対象１１０４の列で構成されている。削除のルールは９個のルール１１０５〜１１１３により構成されている。なお、ルールの内容の一部に‘ｎ’で示す箇所があるが、その部分には整数値が入り値を自由に設定できることを示している。ルール１１０５で例えると、‘最大登録数ｎ個を超えたときに削除する。’について、‘ｎ’が１００であれば１００個の以上登録できないようにする意味である。これはルールの設定時に‘ｎ’の部分に‘１００’を設定することで可能となる。
【００３２】
ルール１１０５では、ｎ個のリソースが登録されたらリソースを削除することを示している。ルール１１０６では、登録したリソースの合計のサイズがｎＭＢを超えたらリソースを削除することを示している。ルール１１０７では、新しいバージョンのリソースを登録したら、古いバージョンおよびリビジョンのリソースを削除することを示している。ルール１１０８では、新しいリビジョンのリソースを登録したら、古いリビジョンのリソースを削除することを示している。ルール１１０９では、一時保管状態であるリソース管理テーブルの使用期限日に到達したリソースを削除することを示している。ルール１１１０では、中継サーバにリソースをｎ回ダウンロードしたらリソースを削除することを示している。ルール１１１１では、クライアントからインストール完了の報告をｎ回受けたらリソースを削除することを示している。ルール１１１２では、中継システムへのダウンロードおよびクライアントからのインストール報告の最終更新がｎ日間無かったときにリソースを削除することを示している。ルール１１１３では、クライアント管理テーブルの登録日からｎ年が経過したリソースについて削除できないようにすることを示している。
【００３３】
図１２には、図１１の削除ルール管理テーブルに設定される定義を示す。定義１２０１は、削除ルール管理テーブルの１１０２に設定される削除ルール適用の定義の一覧である。‘Ｙ’または‘Ｎ’の定義を持つ。‘Ｙ’はルールの適用を意味し、‘Ｎ’はルールを適用しない意味をもつ。定義１２０２は、削除ルール管理テーブルの１１０３に設定されるリソースが削除されるまでの警告のタイミングの閾値の定義の一覧である。‘１’から‘６’の定義を持つ。
【００３４】
定義１２０３は、削除ルール管理テーブルに設定されるリソースの削除対象１１０４の定義の一覧である。‘１’から‘８’の定義を持つ。‘１’はリソース管理テーブルの登録日を参照し古いリソースから削除することを示す。‘２’はリソース管理テーブルのサイズを参照し大きいサイズのリソースから削除することを示す。‘３’はリソース管理テーブルのサイズを参照し小さいサイズのリソースから削除することを示す。‘４’はリソース管理テーブルの重要度を参照し重要度の値の大きいリソースから削除することを示す。重要度の値の設定方法については、図１５に示す登録処理で説明する。‘５’は登録したリソースの名称と同一のリソースをリソース管理テーブルから検索し古いバージョンおよびリビジョンであるリソースをすべて削除することを示す。‘６’は登録したリソースの名称と同一のリソースをリソース管理テーブルから検索し古いリビジョンであるリソースをすべて削除することを示す。‘７’は登録したリソースの名称と同一のリソースをリソース管理テーブルから検索し古いバージョンおよびリビジョンのうち最新のバージョン以外のリソースをすべて削除することを示す。‘８’は登録したリソースの名称と同一のリソースをリソース管理テーブルから検索し古いリビジョンのうち最新のリビジョン以外のリソースをすべて削除することを示す。
【００３５】
図１１の範囲１１１４と１１１５に示す枠内は図１２に示す定義の値の設定可能な組合せの一覧を示しており、斜線の部分は設定ができないことを示す（設定が不要である）。例えば、ルール１１０５では、適用１１０２に‘Ｙ’と‘Ｎ’のいずれかの定義を設定でき、警告１１０３に‘１’と‘２’のいずれかの定義を設定でき、削除対象１１０４に‘１’と‘４’のいずれかの定義を設定することができる。また、ルール１１１３では、適用１１０２に‘Ｙ’と‘Ｎ’のいずれかの定義を設定でき、警告１１０３に‘５’と‘６’のいずれかの定義を設定でき、削除対象１１０４には定義を設定できない。
【００３６】
図１３は、ルールを設定するセットアップ処理を示す。本処理は、配信管理システムが動作する際に必ず設定される処理である。本説明においてはセットアップが行わずにサーバ機能を動作させることはできないものとする。セットアップ処理を開始した場合、まずサーバの全機能を一旦停止する（１３０１）。ここでは、セットアップ処理を実行する際にリソースの登録処理や配信処理などが動作中の可能性があることからサーバの機能が停止した後に処理を開始するものとし、サーバの全機能が停止したらセットアップ処理を行う。最初にリソースの削除ルールの設定を行う。削除ルール管理テーブルのルール１１０５〜１１１３の適用の判断、および各ルールを適用する場合の警告機能の選択、削除対象リソースの組み合わせを決定し、必要に応じてルールの内容１１０１に含まれる‘ｎ’に値を設定する（１３０３）。
【００３７】
図１４にコンソール上に表示する設定インタフェースの例を示す。画面１４０１では、削除ルール管理テーブルのルール１１０６についての削除方法についてＧＵＩを用いて設定を行っている。削除ルールを適用するか否かのチェックボックス、最大個数を入力するためのエディットボックスなどから構成され、ユーザに設定してもらう。
【００３８】
入力後の状態の例として図２４に示すテーブルを用いて説明すると、ルール２４０１は、最大個数が１００個を越えたときに重要度の低いリソースを削除し、２５個、５０個、７５個、９０個のそれぞれのリソースが登録された場合に警告メッセージを出すことを示す（ルールの内容のｎには１００を設定したものとする。）。ルール２４０３は、リソースの登録の際に同一名称のリソースの古いバージョンとリビジョンのリソースをすべて削除することを示す。ルール２４０４は、リソースの登録の際に同一名称のリソースの古いリビジョンのリソースのうち最新のリビジョンを１つだけ残してすべて削除することを示す。ルール２４０７は、１００台のクラアントからインストール報告があった場合に当該リソースを削除し、２５台、５０台、７５台、９０台のそれぞれのインストール報告があった場合に警告メッセージを出すことを示す（ルールの内容のｎには１００を設定したものとする。）。ルール２４０８は、６０日の間にクラアントまたは中継サーバからインストール報告やダウンロード報告が無かった場合に当該リソースを削除し、１０日、２０日、３０日のそれぞれの日数が経過した場合に警告メッセージを出すことを示す（ルールの内容のｎには６０を設定したものとする。）。ルール２４０９は、登録日から５年経過した場合に当該リソースを削除できないようにし、６ヶ月、１年、３年のそれぞれの日数が経過した場合に警告メッセージを出すことを示す（ルールの内容のｎには５を設定したものとする。）。以上のようにすることで削除ルールと削除対象を組み合わせた削除ルールを作成できる。
【００３９】
次に、登録済みのリソースのリソース管理テーブルの情報について変更できるようにする（１３０５）。変更できる情報は、リソース管理テーブルの削除ルールに関係する使用期限日９０７、重要度９０９、削除方法９１２、回復方法９１３の情報についてである。これにより、リソースの削除のタイミングを短縮したり延長するなどリソースの登録以降に再調整できる。さらに、ここでは定義１００３の回復方法のうち‘４’のバックアップから回復する方法において使用するバックアップ先のパス名を設定する。パス名には比較的大容量の固定ディスクなどのパスを設定する。セットアップ処理では、いずれかの処理１３０３および１３０５のみを選択することができる（１３０２、１３０４）。図１３には特に記載していないが、この処理ではサーバ処理の基本的な動作の設定も行うことができるが省略する。
【００４０】
次に、リソースの削除機能について説明する。図１５はリソースの登録処理を示す。図５に示すリソースの登録と異なる点は、リソースを登録する際に削除ルールに関連する使用期限、重要度、削除方法、回復方法の属性の設定と、リソースを登録する際に設定された削除ルールに抵触するリソースがあった場合にリソースの削除を行う点で、他は同様である。リソース登録処理１５０１〜１５０２、サーバ側リソース受信処理１５０８〜１５０９については、図５に示したリソース登録処理と同様であるため説明は省略する。
【００４１】
リソース登録システム上で登録するリソースの属性の設定部分から説明する（１５０３）。ここではリソース名称、バージョン、リビジョン、登録日時の設定の他、使用期限日、重要度、削除方法、回復方法の設定を行う。使用期限日には当該リソースを配信できる使用可能な日付を設定する。この属性値は削除ルール管理テーブルのルール１１０９で参照され、期限を過ぎると当該リソースが削除の対象となる。重要度には、１からｎ（通常状態のステータスであるリソースの全体個数）の重複しない値がリソース毎に設定されている。値が小さいほど重要度が高く、値が大きいほど重要度が低く、最大値が設定されているリソースが削除対象の最優先となる。登録時は１からｎ＋１の間の値を１つ選択する。サーバ側では、当該リソースの重要度を基にリナンバリングする（設定した重要度以降の値を持つリソースの重要度を＋１する）。削除方法は定義１００２に示す定義から１つ選択する。削除方法にて‘３’を選択した場合は回復方法を定義１００３に示す定義から１つ選択する。さらに、回復方法に応じて、パラメータを設定する。回復方法が‘１’の場合は、ＵＲＬ名を設定する。‘２’の場合はメールアドレスを設定する。‘４’の場合は、何も設定しない。これはサーバ側で設定してあるバックアップのパス名を設定するためである。‘５’の場合は、接続された中継サーバの名称を設定する。削除方法にて‘４’および‘６’を選択した場合は、回復方法を設定する必要は無い。‘６’については、頻繁にリビジョンアップされるリソースであることを前提とした上で設定する必要がある。これは、当該リソースより上位のリビジョンが存在しない場合に回復が正しく行われないためである。なお、この処理１５０３において、重複するリソースや重要度の関係を参照できるようにするためサーバから受け取ったリソース情報の一覧を基にリソースの一覧を作成しコンソールなどに表示し参照できるようにすることも可能である。ユーザが設定しない属性のうち、ステータスは‘１’を設定し、保管期限日はすべて０を設定する。
【００４２】
次に、受け取った一覧情報内を検索して既に同一のリソースが登録されていないかどうかを確認する（１５０４）。このとき、登録済みのリソースが存在しても、その登録済みのリソースが一時保管状態であれば、リソースの再登録を行うため属性の設定（１５０４から１５０３）は行わずに、リソースの登録処理へ移行する。一時保管状態かどうかは、リソース管理テーブルのステータスの値が‘２’、‘３’、‘４’の場合である。既に登録済みかどうかは、ステータスの値が‘１’および‘５’の場合で判断できる。リソース名称、バージョン、リビジョンを組み合わせた名称で同一名称の既に登録済みのリソースがある場合は再度設定し直す（１５０４、１５０３）。
【００４３】
既に登録済みのリソースが存在しない場合は、アーカイブしたファイルを新たなリソースとしてリソースの属性情報と共にサーバ側に送信する（１５０５）。サーバ側はリソースとそのリソースの属性情報を受信し、リソースが既に登録されたもので一時保管状態かどうかを確認する（１５１０）。リソースが存在しない場合は、本リソースの登録結果による削除ルールに抵触するリソースの削除を行う。この処理については、後述する図１８で詳細に説明する。なお、ここで削除対象となるのは、削除ルール管理テーブルのうちリソースの登録に関連するルール１１０５、１１０６、１１０７および１１０８が適用される。削除したリソースがあれば、リソース登録処理側にそのリソース情報を渡す（１５１１）。
【００４４】
処理１５１０で、リソースが存在する場合は、処理１５１１を行わない。リソース登録処理より登録要求のあったリソースとそのリソースの属性情報について、リソースはディスクに格納し、属性情報はリソース管理テーブルに設定する（１５１２）。このとき、当該リソースの削除方法が‘１’で回復方法が‘４’であれば予め定義済みのバックアップのパスにバックアップのリソースを作成する。そして、回復方法にファイルパス名をパラメータとして設定する。このバックアップのパス名は、本リソースが削除状態のステータスになった状態で回復が必要となった場合に参照する。
【００４５】
以上の処理が終了したら登録を完了し再び登録要求の待ち状態となる（１５０８）。リソース登録システム側は、サーバ側で削除されたリソースがあればそれを表示し（１５０６、１５０７）、登録処理を終了する。
【００４６】
図１６にはリソースの配信処理を示す。図６、図７、図８で示すリソースの配信処理と異なる点は、リソースを配信する際に一時保管状態のステータスのリソースは新たに配信の対象にできないこと、リソースの配信を実行し中継システムからダウンロードが成功した報告があった場合、またはクライアントからインストールが完了した報告があった場合に、設定された削除ルールに抵触するリソースがあった場合にリソースの削除を行う点で、他は同様である。図１６のステップ１６０１はリソースの配信指示を作成する部分であるが、配信する際に削除中のリソースは新たに配信の対象としないようにする。ここはリソースの配信処理である図６のステップ６０１、図７のステップ７０１、図８のステップ８０１にそれぞれ置き換えることができる。配信の対象かどうかは、リソース管理テーブルのステータスの値が‘２’と‘３’である場合に、そのリソースを配信対象としないようにすることで可能である（‘４’は対象とする）。
【００４７】
図１６のステップ１６０２は、図６のステップ６０５、図７のステップ７０５、図８のステップ８０５における配信結果情報の更新処理後に、配信結果による削除ルールに抵触するリソースの削除を行う。この処理については、後述する図１８で詳細に説明する。なお、ここで削除対象となるのは、削除ルール管理テーブルに示されるルールのうち配信に関連するルール１１１０および１１１１が適用される。以上、図１６は図６、図７、図８の配信処理にいずれにも共通的に置き換えることができ、説明を省略している部分は同様の処理となる。
【００４８】
図１７にはスケジュール処理を示す。まず、削除ルールに抵触するリソースの削除を行う（１７０１）。この処理については、後述する図１８で詳細に説明する。なお、ここで削除対象となるのは、削除ルール管理テーブルに示されるルールのうち日時の超過に関連するルール１１０９および１１１２が適用される。次に、一時保管状態の確認を行う。具体的には、リソース管理テーブルの保管期限がスケジュール処理を実行した日時より過ぎているリソースの検索とそのリソースの削除を行う。リソースの実体の削除とリソース管理テーブルの当該リソースの情報を合わせて削除する。この際に残ったリソースのリソース管理テーブルの通番、および重要度をリナンバリングする。また、配信結果テーブルからも当該リソースの情報を削除する。さらに、リソース管理テーブルの削除方法が‘１’で回復方法が‘４’であればバックアップ用に作成したバックアップのリソースも削除する（１７０２）。この処理で削除したリソースについては図２２のメッセージ出力処理を利用しメッセージを出力する。
【００４９】
次に、削除ルール管理テーブルのルール１１１３である登録日から一定の期間に達したリソースかつ通常状態のステータスであるリソースについて検索を行い、リソース管理テーブルのステータスの値を‘１’から‘５’とし、削除できないようにする。さらに使用期限に０を設定する（１７０３）。この処理で削除禁止にしたリソースについては図２２のメッセージ出力処理を利用しメッセージを出力する。
【００５０】
次に、削除ルールの警告の値に従い、警告の閾値に達したリソースが存在したら、警告メッセージの処理を行う（１７０４）。警告メッセージの処理は、図２２で詳細に説明する。
【００５１】
以上の処理が終わったらウェイト状態となる。ウェイト間隔は２４時間とし、図１３には記載していないが、本スケジュール処理の開始時間はセットアップ処理で設定できるものとする。例えば、リソースの削除処理と配信処理の競合を防ぐことを目的とし、夜間に配信を実行する運用をとった場合は昼にスケジュール処理を動作するように設定できる（１７０５から１７０１）。
【００５２】
図１８には削除ルール管理テーブルに基づいたリソースの削除処理を示す。まず、削除するリソースが存在するか削除ルール管理テーブルを参照し削除ルールに沿って、リソース管理テーブルの各属性値を参照し、ルールに抵触するリソースを検索する（１８０１）。
【００５３】
削除ルール管理テーブルのルール１１０５では、リソース管理テーブルに登録されるステータスが‘１’の状態であるリソース数が、ｎ個に達しているときにリソースの削除を行う。削除するリソースは、削除対象の定義に従い選択される。例えば、‘１’の場合は、ステータスが’１‘で登録日の一番古いリソースが削除の対象として選択される。さらに、‘４’の場合は、ステータスが‘１’で重要度の値が一番大きいリソースが削除の対象として選択される。
【００５４】
削除ルール管理テーブルのルール１１０６では、リソース管理テーブルに登録されたリソースのサイズの合計が、ｎＭＢに達しているときにリソースの削除を行う。削除するリソースは、削除対象の定義に従い選択される。例えば、‘２’の場合は、リソース管理テーブルの中の、ステータスが‘１’でサイズの一番大きいリソースが削除の対象として選択される。さらに、‘３’の場合は、ステータスが‘１’でサイズの一番小さいリソースが削除の対象として選択される。
【００５５】
削除ルール管理テーブルのルール１１０７では、リソース登録システムにより登録されたリソースのバージョンを基にリソースの削除を行う。削除するリソースは、削除対象の定義に示される定義に従い選択される。例えば、‘５’場合は、ステータスが‘１’でリソース名称の同じリソースが削除の対象として選択される。さらに、‘６’の場合は、ステータスが‘１’でリソース名称の同じかつ１つ下のバージョン以外のリソースが削除の対象として選択される。（１つ下のバージョンとは、例えば登録したリソースのバージョンが７の場合必ず６のバージョンというわけではなく、７未満のうちの一番高いバージョンの意味である。）
削除ルール管理テーブルのルール１１０８についてもルール１１０７と同様であり、対象がリソース管理テーブルのリビジョンを対象として削除するリソースを選択する。削除ルール管理テーブルのルール１１０９では、リソース管理テーブルの使用期限日が過ぎているリソースについて削除を行う。このルールは削除対象の定義がなく、ステータスが‘１’でかつ使用期限日が過ぎているリソースが削除の対象として選択される。
【００５６】
削除ルール管理テーブルのルール１１１０では、配信結果テーブルのダウンロード回数を参照し、ｎ回以上のダウンロードを行っているリソースについて削除を行う。このルールも削除対象の定義がなく、ステータスが’１‘でかつｎ回以上のダウンロードが行われているリソースが削除の対象として選択される。
【００５７】
削除ルール管理テーブルのルール１１１１も同様であり、これは配信結果テーブルのインストール回数を参照し、リソースを選択する。削除ルール管理テーブルのルール１１１２では、配信結果テーブルの最終アクセス日から現在の日付からｎ日（ｎヶ月、ｎ年）経過しているリソースについて削除を行う。このルールは削除対象の定義がなく、ステータスが‘１’でかつ最終アクセス日からｎ日が過ぎているリソースが削除の対象として選択される。
【００５８】
リソース登録処理から削除処理が実行された場合は、処理の関連性からルール１１０５、１１０６、１１０７、１１０８を適用する。リソースの配信処理から削除処理が実行された場合は、ルール１１１０、１１１１を適用する。スケジュール処理から削除処理が実行された場合は、ルール１１０９、１１１２を適用する。
【００５９】
削除するリソースがなければ、そのまま終了するが、削除するリソースが存在すれば、そのリソースのリソース管理テーブル上の削除方法を参照する。削除方法が‘１’であれば（１８０２）、リソース管理テーブルのステータスを‘１’から‘２’に更新する（１８０６）。削除方法が‘２’であれば（１８０３）、リソース管理テーブルのファイルパスに示すファイルを圧縮処理し、ステータスを‘１’から‘３’に更新する（１８０７）。削除方法が‘３’であれば（１８０４）、リソース管理テーブルのファイルパスに示すファイルを削除し、ステータスを‘１’から‘４’に更新する（１８０７）。削除方法が‘１’、‘２’、‘３’の値で、値に応じて削除処理を行った場合は、保管期間の設定を行う（１８０９）。
【００６０】
保管期間には削除した日の１ヶ月後の日時を設定する。図１３には記載していないが、１ヶ月の期間はセットアップ処理で別の期間に自由に設定できるものとする。長い期間を設定すれば、万が一配信要求があっても回復する可能性があるがある程度の容量を必要とする。短い期間を設定すれば、万が一配信要求があっても回復できなくなる。システムの性質や扱うリソースの性質により適度な値を設定すればよい。重要度には０を設定する。この処理で削除処理したリソースについては図２２のメッセージ出力処理を利用しメッセージを出力する。
【００６１】
削除方法が‘４’であれば、リソース管理テーブルおよび実体のファイルを即時に削除する（１８０５）。この際に残ったリソースのリソース管理テーブルの通番、および重要度をリナンバリングする。リソース管理テーブルの削除方法が‘１’で回復方法が‘４’であればバックアップ用に作成したバックアップのリソースも削除する。また、配信結果テーブルからも削除するリソースの情報を削除する。この処理で削除したリソースについては図２２のメッセージ出力処理を利用しメッセージを出力する。リソースの削除処理（１８０５、１８０９）について終了したら再度１８０１に戻り、削除するリソースがあるかどうかを検索する。削除するリソースが無くなるまで、繰り返し処理する。
【００６２】
次に、リソースの回復機能について説明する。図１９に、リソースの回復について示す。リソースの回復処理はリソースの配信処理である図６のステップ６０３、図７のステップ７０３、図８のステップ８０３の部分に回復のための処理を追加することで実現可能である。まず、下位システム（中継サーバ、クライアント）からリソース配信の要求があったときに、リソース管理テーブルを参照し、リソースが一時保管状態かどうかを判断する（１９０１）。一時保管状態かどうかは、リソース管理テーブルのステータスの値が‘１’または‘５’以外の状態になっていることで判断できる。当該リソースが一時保管状態でない場合は、そのままリソースの配信を実行する（１９０７）。
【００６３】
当該リソースが一時保管状態の場合は、図２０に示すリソースの回復処理を実行する（１９０２）。リソースの回復処理が正しく完了したかどうかを判定し（１９０３）、回復が行われたら、リソースの配信を行う（１９０７）。リソースの回復処理の詳細は図２０と図２１で説明する。
【００６４】
回復が行われなかった場合は、下位システム（中継サーバ、クライアント）に配信処理の保留通知を行う（１９０４）。下位システムはこれにより、サーバからの指示があるまでは、下位システムからはアクションを行わない。そして、ステップ１９０２で行ったリソースの回復処理の続きを行う。回復方法によっては一回の回復処理で回復しないケースがあるため、ここで回復するまで回復処理を継続して行う（１９０５）。回復処理が正しく行われたら、下位システムに対して保留解除の再開通知を行う（１９０６）。その後、リソースの配信を行う（１９０７）。
【００６５】
リソースの配信以降の処理は、リソースの配信処理である図６、図７、図８と同様であるため省略する。図１９では省略しているが、回復中に他の中継サーバやクライアントから配信要求が来た場合を考慮し、ステップ１９０１から１９０７の処理については、リソース名称、バージョンおよびリビジョンの組み合わせた名称による排他制御を施すことにより、他の中継サーバやクライアントから配信要求はウェイト状態となるようにする。
【００６６】
図２０および図２１には詳細な回復処理の説明を示す。回復対象となるリソースのリソース管理テーブルのステータスの値が‘２’であれば（２００１）、保管期限をさらに１ヶ月延長して（２００５）、回復完了状態で元の処理に戻る。本ケースは、リソース管理テーブルのファイルパスで示されるファイルがそのまま残っているため、そのファイルをそのまま使用して配信処理を行う。回復対象となるリソースのリソース管理テーブルのステータスの値が‘３’であれば（２００２）、リソース管理テーブルのファイルパスで示されるファイルの圧縮を解凍し元のファイルの状態に戻す（２００３）。そして、リソース管理テーブルのステータスを‘２’のステータスに変更し（２００４）、保管期限をさらに１ヶ月延長して（２００５）、回復完了状態で元の処理に戻る。
【００６７】
本ケースは、リソース管理テーブルのファイルパスで示されるファイルが圧縮解凍されるため元の配信可能な状態に戻り、その復元したファイルを使用して配信処理を行う。配信処理の要求が今後もあることが考えられるため、以降は圧縮状態のステータスには戻さず保管期限まで一時保管する。ステップ２００５で示す１ヶ月の期限については、図１８での説明と同様にセットアップ処理で変更できるものとする。回復対象となるリソースのステータスの値が‘２’と‘３’以外でれば‘４’であると見なし、リソース管理テーブルの回復方法を参照する。回復方法が‘６’であれば（２００６）、当該リソースの最上位のリビジョンのリソースをリソース管理テーブルから検索し、そのリソースを配信リソースとするため配信指示情報のリソース名称を最上位のリビジョンのリソースに変更する（２００７）。
【００６８】
そして、ステップ２００５の処理へ移行し当該リソースの保管期限を一ヶ月間延長する。リソースの配信が正しく行われたあとに、最上位のリビジョンのリソース情報で配信結果テーブルを更新する。回復方法が‘３’であれば（図２１の２１０１）、リソースを作成したインストールメディアからファイルを回復するため、設定したドライブのマウント先にアクセスを行いファイルが存在するか確認する（２１０６）。なお、設定したパラメタのドライブにあらかじめメディアをマウントしておけば、スムーズに回復を行うことができる。
【００６９】
回復方法が‘２’であれば（２１０２）、リソースの作者宛てもしくは企業宛てにリソースを送信してもらう旨の内容でメールを作成し設定したメールアドレスにメールを送信する（２１０７）。返信メールにはリソースを添付してもらい自動的にリソースファイルにコピーするようにメールソフトを設定する。
【００７０】
回復方法が‘５’であれば（２１０３）、リソースが配信される過程で保管される中継サーバのキャッシュからファイルを吸い上げてリソースを回復するため、設定した中継サーバのアドレスに対して接続しリソースを吸い上げる（２１０８）。設定する中継サーバのアドレスは、キャッシュがされている可能性が高い中継サーバのアドレスを設定しておくことで回復する可能性が高くなる。また、設定した中継サーバにリソースが存在しなかった場合は、設定しなかった中継サーバにも接続し回復を行う。
【００７１】
回復方法が‘１’であれば（２１０４）、設定したＵＲＬに向けてインターネット経由でリソースをダウンロードし回復するため、設定したＵＲＬに接続を行いリソースをダウンロードする（２１０９）。
【００７２】
回復方法が‘１’、‘２’、‘３’、‘５’において、回復できたかどうかを判断し（２１１０）、回復できたら、リソース管理テーブルのファイルパスの示すパスにファイルコピーする（２１１１）。インストールメディアから回復する場合などのように必要であれば、リソースの登録処理のようにアーカイブを行い１つのファイルにしたうえでファイルコピーをする。メールの送信のように、即回復ができなかった場合は、回復未完状態で元の処理に戻る。
【００７３】
回復方法が‘１’、‘２’、‘３’、‘５’、‘６’以外であれば、‘４’とみなし、バックアップのパス名に示すパスよりファイルコピーを行う（２１０５）。ファイルコピーが完了したら、リソース管理テーブルのステータスを‘１’の通常状態にする。さらに、使用期限日を回復を実行した時点の日付に１ヶ月足した値とする。また、保管期限日はすべて０の値にする。重要度は最下位の値とする。その他の属性については、リソースの登録時点の値とする（２１１２）。そのあと、回復完了状態で元の処理に戻る。
【００７４】
図２２には、メッセージ出力の方法を示す。まず、メッセージ出力要求が、警告処理から行われたものか、削除処理から行われたものかを判定する（２２０１）。警告処理から行われた場合は、削除ルール管理テーブルのルールと警告で指定された警告の閾値に該当するリソースをリソース管理テーブルを基に検索する（２２０３）。該当するリソースがあれば、リソースおよび警告内容を、メッセージ出力バッファに追記形式で格納し（２２０４）、他に警告対象となるリソースが無いか検索する（２２０３に戻る）。すべてのリソースについての検索が終わったら、検索処理を終えループを抜ける。削除処理から行われた場合は、削除処理で削除したリソース名称、バージョン、リビジョンをメッセージ出力バッファに格納する（２２０２）。
【００７５】
メッセージ出力バッファにメッセージが格納されているかどうかを確認する（２２０５）。何もメッセージがなければそのまま終了する。何らかのメッセージが格納されているならば、メッセージ出力先を選択する。メッセージ出力であれば（２２０６）、コンソール装置にメッセージ出力バッファに格納された内容を出力する（２２０７）。ログ出力であれば（２２０８）、メッセージ出力バッファに格納された内容をログ出力専用のファイルに出力する（２２０９）。メール送信であれば（２２１０）、メッセージ出力バッファに格納された内容をメールに書きサーバのユーザ充てに送信する（２２１１）。なお、メッセージの出力先の定義について本説明では省略するが、セットアップ処理であらかじめ定義できているとする。以上、説明した機能がそれぞれ動作することによりリソースの削除と回復が行われるようになる。
【００７６】
本発明では、ステータスが一時保管状態のリソースについて再登録した場合や回復処理を施した場合に通常状態のステータスにしているが、このとき削除ルールを適用していない。ここは、再登録や回復処理の後に図１８の削除処理を実行することで、削除ルールを適用できる。また、本発明では、図２０のステップ２００５で一時保管状態を示すリソース管理テーブルのステータスの‘２’と‘３’については保管期限を延長する処理としたが、‘４’のステータスのように再度登録し通常のリソースの状態にすることで再登録の手間を省くことができる。図２０のステップ２００５の部分を図２１のステップ２１１２のように再登録する処理にすることで可能である。属性の再設定値についても‘４’のケースと同様である。ただし、回復方法を‘６’の最上位のリビジョンを適用する方法については、その性質上再登録処理の対象外とする。
【００７７】
また、本発明では、図９のリソースの回復方法９１３を１つ設定するようにした。ここに２つ以上の回復の方法と回復方法の優先順位を設定することで、より回復を効果的に行うことができるようになる。図２０と図２１に示す回復処理で処理２００６〜２１１０を、設定された回復方法９１３の設定数だけ優先順位に従いループ処理することで可能である。
【００７８】
また、本発明では、削除ルール管理テーブルのルールのうち新たなバージョンやリビジョンのリソースを登録した場合（図１１のルール１１０７や１１０８）やインストール結果の情報の更新の場合（図１１の１１１１）が発生したときに削除するルールについて共通ルール的な扱いとしたが、バージョンアップの頻度が高いリソースなどの特質をもつリソースや全クライアントではなく一部のクライアントにだけ配信するリソースなどの特質を考えた場合にリソース毎にルールの設定を行いたい場合もある。そこで、使用期限日などの属性と同様にリソース管理テーブル側にローカル的な位置付けで削除のルールの情報を保持するようにし、リソースの登録処理で削除ルールを設定できるようにする（図１５のステップ１５０３に追加）。リソースの削除処理にリソース毎のルールに抵触するかを判断する処理を追加することで可能である（図１８のステップ１８０１に追加）。
【００７９】
【発明の効果】
本発明によるリソースの自動削除方法を採用することにより、誤ってリソースを削除してしまう可能性が大幅に低下するとともに、ルールに従って自動的に削除することにより不必要にディスク容量を圧迫することを防ぎ安定した運用を行うことが可能となった。また、リソースの個数を自動的に制限できるようにすることで管理の手間もかからないようになった。また、配信結果によりリソースを削除できるようにすることで、ライセンス数のコントロールも可能となった。その一方で、ただ単に削除するだけではなく回復の手段も各種用意することでルールの設定ミスなどにより誤って削除した場合も容易に回復でき、さらに希少価値の高いリソースを削除できないようにする手段も用意することで再登録の必要が無くなったことにより、操作性および運用性が向上する。
【図面の簡単な説明】
【図１】本発明のシステムの構成を示す図である。
【図２】本発明のプログラムモジュールの構成を示す図である。
【図３】リソース管理テーブルの一例を示す図である。
【図４】本発明で利用する配信結果テーブルの一例を示す図である。
【図５】リソースの登録処理を示すフローチャートである。
【図６】サーバ側主導によるリソースの配信処理を示すフローチャートである。
【図７】クライアント側主導によるリソースの配信処理を示すフローチャートである。
【図８】中継サーバへのリソースの配信処理を示すフローチャートである。
【図９】本発明で利用するリソース管理テーブルの一例を示す図である。
【図１０】リソース管理テーブルで使用する定義一覧を示す図である。
【図１１】本発明で利用する削除ルール管理テーブルの一例を示す図である。
【図１２】削除ルール管理テーブルで使用する定義一覧を示す図である。
【図１３】セットアップ処理を示すフローチャートである。
【図１４】設定画面の例を示す図である。
【図１５】リソースの自動削除処理を含めたリソースの登録処理を示すフローチャートである。
【図１６】リソースの自動削除処理を含めたリソースの配信処理を示すフローチャートである。
【図１７】スケジュール処理を示すフローチャートである。
【図１８】リソースの削除処理を示すフローチャートである。
【図１９】リソースの自動回復処理を含めたリソースの配信処理を示すフローチャートである。
【図２０】リソースの回復処理を示すフローチャートである。
【図２１】リソースの回復処理を示すフローチャートである。
【図２２】警告メッセージ出力処理を示すフローチャートである。
【図２３】本発明によるリソースの扱いを説明する図である。
【図２４】本発明で利用する削除ルール管理テーブルの一例を示す図である。
【符号の説明】
１０１：配信管理サーバ、１０２：ソフトウェアリソース、１０３：リソース登録システム、１０４：ネットワーク、１０５：中継サーバ、１０６：クライアント、１０７：クライアント、１０８：クライアント、１０９：クライアント、１１０：クライアント、２００：配信管理サーバ、２０１：コンソール装置、
２０２：表示制御部、２０３：削除ルール管理テーブル、２０４：リソース管理テーブル、２０５：ソフトウェアリソース、２０６：スケジュール処理部、
２０７：セットアップ処理部、２０８：配信指示テーブル、２０９：バックアップ、２１０：リソース受信処理部、２１１：リソース配信処理部、２１２：配信結果テーブル、２１３：リソース登録システム、２１４：リソース登録処理部、２１５：クライアント、２１６：リソース受信処理部、２１７：中継サーバ、２１８：リソース受信処理部、２１９：リソース配信処理部、２２０：リソース（キャッシュ）

Claims (3)

1. ソフトウェアリソース、ソフトウェアリソースのリソース管理テーブル、ソフトウェアリソースの削除ルール管理テーブル、ソフトウェアリソースの配信結果テーブルを持ち、リソース管理テーブル、削除ルールテーブル、配信結果テーブルを基にソフトウェアリソースの削除および回復を行うことを特徴とするソフトウェアリソース管理方法。
2. 請求項１に記載のソフトウェアリソース管理方法において、リソース管理テーブル、削除ルールテーブルを基にソフトウェアリソースの削除をできないようにすることを特徴とするソフトウェアリソース管理方法。
3. 請求項１に記載のソフトウェアリソース管理方法において、リソース管理テーブルを基に削除したソフトウェアリソースを上位のバージョンまたはリビジョンのソフトウェアリソースを適用し回復することを特徴とするソフトウェアリソース管理方法。

Images