(57)【特許請求の範囲】
【請求項１】
ユーザの端末装置から通信ネットワークを介して受け取ったソフトウェアの登録を行う情報処理システムにおいて、
データベース登録処理に必要な基礎情報と、前記ソフトウェアの概要を記した説明情報と、該ソフトウェアの実行に必要なファイルを圧縮して１つにまとめたファイルとからなるソフトウェア情報を前記端末装置から受け取って管理する管理手段と、
前記管理手段が受け取ったソフトウェア情報に関して、危険と見なされる文字列やコード列のデータと比較して登録商標チェックを行い、該ソフトウェア情報の正当性を自動的に判定する自動テスト手段と、
前記ソフトウェア情報を記憶する記憶手段と、
を備えることを特徴とするソフトウェア登録システム。
【請求項２】
前記記憶手段に記憶された前記ソフトウェア情報に基づいて、前記通信ネットワークを介して前記端末装置の格納領域に前記ソフトウェアを自動的にインストールするインストール手段をさらに備え、
前記管理手段は、インストール時に前記ソフトウェアの動作環境を調査するためのチェック情報と、実際に行われるインストール処理を記したインストール関連情報とをさらに含む前記ソフトウェア情報を受け取り、該ソフトウェア情報を前記記憶手段に格納することを特徴とする請求項１記載のソフトウェア登録システム。
【請求項３】
ユーザの端末装置から通信ネットワークを介して受け取ったソフトウェアを管理する方法において、
登録するソフトウェア情報を、データベース登録処理に必要な基礎情報と、前記ソフトウェアの概要を記した説明情報と、該ソフトウェアの本体を圧縮した本体情報とに分割し登録するソフトウェア情報について、危険と見なされる文字列やコード列のデータと比較して登録商標チェックを行い、
該基礎情報、説明情報、および本体情報を登録する、
ことを特徴とするソフトウェア登録方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ユーザの端末装置から通信回線を介して、ソフトウェアを自動的にデータベースに登録するソフトウェア登録システムとその方法に関する。
【０００２】
【従来の技術】
近年のパソコン通信等の発達に伴い、通信回線を介してソフトウェアを入手したいというユーザの希望が生じているが、このようなソフトウェアの配送を自動的に行う本格的なシステムは実現していない。ソフトウェアの自動配送を行うには、まずユーザが希望するソフトウェアを自宅の端末装置から配送センターに知らせ、ユーザから通知を受けた配送センターは通信回線を介して要求されたソフトウェアをユーザの端末装置に送信するという形式が考えられる。
【０００３】
このようなソフトウェアの自動配送を実現するために、先願の「リモートインストールシステムおよび方法」（特願平７−１７９７）が考案された。以下、図面を参照しながら先願の技術について説明する。
【０００４】
図２９は、先願のリモートインストールシステムの構成図である。図２９のリモートインストールシステムは、ソフトウェアの配送センターにあるホスト計算機２１、ユーザの端末２３、およびこれらを結ぶ通信回線２２から成る。端末２３は、例えば配送センターから遠く離れたユーザの自宅にあるパーソナルコンピュータであり、通信回線２２は例えばパソコン通信のネットワーク用の回線であるものとする。
【０００５】
ホスト計算機２１は、図示されない格納領域内に配送可能な複数のソフトウェアを含むソフトウェア群３５と、そのソフトウェア群３５から特定のソフトウェアを選択するときに用いるキーワードのリストを保持する第１キーテーブル３２および第２キーテーブル３３を格納している。
【０００６】
ユーザが端末２３からホスト計算機２１にキーワードのリストを要求すると、ホスト計算機２１は第１キーテーブル３２、第２キーテーブル３３を順次送信して、それらに含まれるキーワードを端末２３の表示装置２４の画面に表示させる。ユーザは表示されたキーワードから希望するソフトウェアに対応するものを選び、ホスト計算機２１に通知する。
【０００７】
ホスト計算機２１は通知されたキーワードに該当するいくつかのソフトウェアの名称を含むメニューを表示装置２４の画面に表示させ、ユーザはその中から希望するソフトウェアを選んで、ホスト計算機２１に通知する。そして、ホスト計算機２１はソフトウェア群３５からユーザの選んだソフトウェアのコンテンツ（ファイル）を取り出し、端末２３のハードディスク２５に設定された配送（宅配、またはディストリビューション）用のディレクトリＤ：￥ＳＯＵＫＯに格納する。
【０００８】
このとき、宅配されたソフトウェアを起動するためのアイコン３７が自動的に登録され、表示装置２４の画面上でディレクトリＤ：￥ＳＯＵＫＯに対応して設けられた倉庫ウィンドウ３６内に表示される。例えば端末２３がＷＩＮＤＯＷＳを搭載している場合は、宅配されたソフトウェアはＷＩＮＤＯＷＳのプログラムマネージャに登録される。以後、ユーザはアイコン３７をマウス等の入力装置を用いてクリックするだけで、宅配されたソフトウェアを使用することができる。
【０００９】
端末２３が装備するハードウェアやソフトウェアツール等の動作環境を記述した環境ファイル３１は端末２３内で生成され、ホスト計算機２１のアクセス時にホスト計算機２１に送られる。ホスト計算機２１は受け取った環境ファイル３１を各ユーザ毎に保持し、ユーザが選んだソフトウェアが動作可能かどうかのチェックに用いる。
【００１０】
また、ホスト計算機２１はユーザ毎に個別の設定ファイル３４を用意し、ユーザが選んだソフトウェアの動作に必要なファイル一式とその格納場所をこれに記述する。そして、それらのファイル一式とともに設定ファイル３４を端末２３に一括して送り、端末２３にソフトウェアの自動インストールを行わせることができる。
【００１１】
次に、図３０から図３２までを参照しながら、図２９のリモートインストールシステムによるソフトウェアの宅配の動作フローを説明する。
図３０において、ユーザＡの端末２３は通信用の端末ソフトのインストール時に動作環境の情報を取得し、取得した情報を設定した環境ファイル３８を作成する（ステップＳ１）。このとき、ユーザの端末の機種や宅配に使用する格納場所ＳＯＵＫＯ等の取得に時間のかかる情報、あるいは、場合によってユーザに問い合わせなければならない情報を取得する。
【００１２】
格納場所ＳＯＵＫＯの決定にあたっては、端末２３はハードディスク２５に所定の容量以上の空き領域があるかどうかを調べ、空き領域があればそのルートに宅配用のディレクトリを作成する。このときディレクトリ名等は端末２３が自動的に生成し、ユーザＡはそれを確認する作業のみを行う。したがって、ユーザＡはディレクトリ名等を入力する必要がない。
【００１３】
ここでは、ユーザＡの機種はＴＯＷＮＳであり、ＳＯＵＫＯのディレクトリはＤ：￥ＳＯＵＫＯ（ドライブＤのディレクトリＳＯＵＫＯ）であることが環境ファイル３８に書き込まれる。ユーザＡは、必要があればＤ：￥ＳＯＵＫＯを他のディレクトリに変更することもできる。
【００１４】
既に設定されているパーティションに所定の容量の空き領域がなければ、別のパーティションの空き領域が一番大きい場所を探して、そこに宅配用のディレクトリを作成する。具体的には、ディレクトリＤ：￥ＳＯＵＫＯが一杯になったとすると、端末２３が”Ｄ：￥ＳＯＵＫＯが一杯です。倉庫をＦ：￥ＳＯＵＫＯに変更します。よろしいですか。”等のメッセージを表示装置２４の画面に表示する。ユーザＡがこれを承認すると、Ｆ：￥ＳＯＵＫＯが新たにＳＯＵＫＯのディレクトリとなる。所定の容量の空き領域がどのハードディスクにもなかったときは、”残念ながらディスク容量が足りません。ディスクを増設してください。”等のメッセージが表示される。
【００１５】
次に、端末ソフトの起動時（ホスト計算機２１へのアクセス時）に、ハードディスクやメモリの状況等のインストール後に変化した可能性のある情報を取得する（ステップＳ２）。ここでは、ユーザＡのハードディスクがドライブＤにあり、空き容量が３００Ｍバイトであることが環境ファイル３８に書き込まれる。こうして作成された環境ファイル３８の内容は、ユーザＡがホスト計算機２１にアクセス（接続）したときに、コマンドＲＩＳ ＳＥＮＤＥＮＶによりホスト計算機２１に送信される（ステップＳ３）。
【００１６】
ホスト計算機２１は受信した情報をユーザＡ環境ファイル３９として保持する。ユーザＡ環境ファイル３９には、機種、ハードディスク情報ＨＤ、格納場所ＳＯＵＫＯのほかに、使用しているＯＳ（オペレーティングシステム）とその格納場所が記述されている。ここでは、ユーザＡの端末２３のＯＳはＷＩＮＤＯＷＳであり、その格納場所ＷＩＮＤＩＲはＤ：￥ＷＩＮＤＯＷＳであることがわかる。
【００１７】
ホスト計算機２１からコマンドＲＩＳ ＳＥＮＤＥＮＶに対するレスポンスとしてＲＩＳ ＳＥＮＤＥＮＶ＊ＲＥＳＰ  ＯＫを受け取ると、端末２３はコマンドＲＩＳ ＫＥＹＬＩＳＴにより第１キーリストを要求する（ステップＳ４）。これに応じて、ホスト計算機２１は第１キーテーブル３２の内容をＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第１キーテーブル３２には、キー番号１、２、３、・・・に対応するキーワードとして、ＯＳ／基本ソフト、開発支援、ゲーム、・・・が格納されている。
【００１８】
これらのキーワードが第１キーリストとして表示装置２４の画面に表示されると（ステップＳ５）、ユーザＡはそれらの中から第１キーワードを選び端末２３に入力する（ステップＳ６）。すると、端末２３はユーザＡの選んだ第１キーワードのキー番号とともに、第２キーリストを要求するコマンドＲＩＳ ＫＥＹＬＩＳＴをホスト計算機２１に送る（ステップＳ７）。ここでは、ユーザＡは第１キーワードとしてゲームを選択し、それに対応するキー番号３がホスト計算機２１に送られる。
【００１９】
第２キーリストを要求されたホスト計算機２１は、受け取ったキー番号に対応して第１キーテーブル３２内に格納されているポインタを用いて、対応する第２キーテーブル３３を求め、その内容をＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第２キーテーブル３３には、キー番号５１、５２、５３、・・・に対応するキーワードとして、ＲＰＧ、アクション、パズル／クイズ、・・・が格納されている。
【００２０】
第２キーテーブルは第１キーテーブル３２内のキーワードに対応して一般に複数設けられており、その数は第１キーテーブル３２内のキーワードの数と同じか、またはそれより少ない。後者の場合には、第１キーテーブル３２内の２つ以上のキーワードが同じ１つの第２キーテーブルを指すことになる。
【００２１】
第２キーテーブル内のキーワードが第２キーリストとして表示装置２４の画面に表示されると（ステップＳ８）、ユーザＡはそれらの中から第２キーワードを選び端末２３に入力する（図３１、ステップＳ９）。すると、端末２３はユーザＡの選んだ第１および第２キーワードのキー番号とともに、第１および第２キーワードの両方に該当するソフトウェアのリストを要求するコマンドＲＩＳ ＬＩＳＴをホスト計算機２１に送る（ステップＳ１０）。ここでは、ユーザＡは第２キーワードとしてアクションを選択し、それに対応するキー番号５２がホスト計算機２１に送られる。
【００２２】
ソフトウェアのリストを要求されたホスト計算機２１は、第１および第２キーワードの２つのキー番号を持つソフトウェアをソフトウェア群３５の中から検索する。このとき、検索条件として第１キーワードと第２キーワードとを区別せずに、フラットに検索を行う。また、機種やＯＳの種別はデフォルトのキーとして扱い、これらも加味した上で検索する。これにより、例えばＴＯＷＮＳ以外の機種専用のソフトウェアが検索されてくることが防止される。
【００２３】
そして、該当するソフトウェアの名称と番号のリストをＲＩＳ ＬＩＳＴ＊ＲＥＳＰとともに端末２３に送る。ここでは、キー番号３と５２を持つテトリス、パチンコ等のソフトウェアが該当するので、それらの名称がそれぞれのソフトウェア番号５、３０等とともに端末２３に送られる。
【００２４】
ソフトウェアのリストが表示装置２４の画面に表示されると（ステップＳ１１）、ユーザＡはそれらの中から希望するソフトウェアを選び、端末２３に入力する（ステップＳ１２）。すると、端末２３はユーザＡの選んだソフトウェアの番号とともに、ユーザＡの環境がそのソフトウェアの動作に適するかどうかのチェックを要求するコマンドＲＩＳ ＣＨＫＥＮＶをホスト計算機２１に送る（ステップＳ１３）。ここでは、ユーザＡはテトリスを選択し、それに対応するソフトウェア番号５がホスト計算機２１に送られる。
【００２５】
ユーザＡが選択したソフトウェアの番号を受け取ったホスト計算機２１は、その番号に対応するソフトウェアの動作環境とユーザＡの端末２３の環境との整合性を調べるためのチェックスクリプト４０を用意し、環境チェックを行う。このチェックはチェックスクリプト４０の実行プログラムと端末２３の端末ソフトとの間のやりとりにより自動的に行われるので、ユーザＡは環境チェックが行われていることを必ずしも意識する必要はない（ステップＳ１４）。ユーザＡに何らかの問い合わせを行う必要が生じたときにのみ、ホスト計算機２１がその問い合わせを行う。
【００２６】
ここでは、ユーザＡが選択したテトリスの動作環境として、ＯＳがＷＩＮＤＯＷＳ、機種がＴＯＷＮＳ、ＰＣ９８等、推奨ディレクトリ（ＤＩＲ）名がＴＥＴであることが記述されている。これに対して、ユーザＡ環境ファイル３９には、機種がＴＯＷＮＳ、ＯＳがＷＩＮＤＯＷＳと記述されており、両者を比較することによって機種とＯＳが適合していることがわかる。
【００２７】
次に、テトリスのチェックスクリプト４０を見るとユーザＡ側の格納場所ＷＩＮＤＩＲにＶＢＲＪＰ２００．ＤＬＬというファイルがあるかどうか調査するためのコマンド”ＳＴ４  ＠ＷＩＮＤＩＲ＠ＶＢＲＪＰ２００．ＤＬＬ”があるので（ＭＱ１）、ホスト計算機２１はこれをＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。このとき、ホスト計算機２１はユーザＡ環境ファイル３９を参照して、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて送る。ここで、＠はワイルドカードを表す。また、ファイルＶＢＲＪＰ２００．ＤＬＬはテトリスの動作に必要なファイルの１つである。
【００２８】
このコマンドを受け取った端末２３は、ドライブＤのディレクトリＷＩＮＤＯＷＳにファイルＶＢＲＪＰ２００．ＤＬＬがあるかどうか調べ、その結果をＡＮＳとしてホスト計算機２１に送り返す。ここでは、該当するファイルがなかったのでＡＮＳ＝ＯＦＦが送り返される。
【００２９】
端末２３にファイルＶＢＲＪＰ２００．ＤＬＬがないことを知ったホスト計算機２１は、チェックスクリプト４０に従って（ＭＱ２）、”ＶＢＲＪＰ２００をコピーしてよいか？”という問い合わせを端末２３に送り、この問い合わせが表示装置２４の画面に表示される。ユーザＡは表示された問い合わせに対する回答を入力し、端末２３がその回答をホスト計算機２１に送り返す。ここでは、ＡＮＳ＝はい  が送り返され、ホスト計算機２１はチェックスクリプト４０に従って、リモートインストールを承諾し（ＲＩＳ＝ＯＫ）、ＶＢＲＪＰ２００．ＤＬＬのコピーを指示するフラグＦ２をＯＮにする（ＭＡ２）。
【００３０】
もし、ファイルＶＢＲＪＰ２００．ＤＬＬが端末２３の指定されたディレクトリにあった場合はＡＮＳ＝ＯＮが送り返されるので、その時点でＲＩＳ＝ＯＫとなる（ＭＡ１）。
【００３１】
このように環境チェックを自動的に行うことにより、ユーザＡの環境に適合しないソフトウェアが配送されるのを防ぐことができる。例えば、あるパッケージソフトウェアを通信回線２２を介して購入した後に、特定のドライバがないとそれが動作しないことを知るといったような事故が未然に防止される。
【００３２】
ＲＩＳ＝ＯＫとなるとホスト計算機２１は環境チェックを終了し、判定結果（ＪＵＤＧＥ＝ＯＫ）とともに、配送先のディレクトリＳＯＵＫＯＤＩＲを端末２３に送る。このＳＯＵＫＯＤＩＲは、ユーザＡ環境ファイルに格納されているＳＯＵＫＯのディレクトリであるＤ：￥ＳＯＵＫＯの下にテトリスの推奨ディレクトリであるＴＥＴをサブディレクトリとして付加した形式で指定される。
【００３３】
このとき同時に、インストールの可否（ＲＩＳ）、インストールプログラム（インストーラ）のアイコン登録の有無（ＩＣＯＮ）、およびダウンロードの可否（ＤＬＯＡＤ）が端末２３に送られる。これらのフラグＲＩＳ、ＩＣＯＮ、ＤＬＯＡＤにより、ホスト計算機２１はインストール、インストーラのアイコン登録、ダウンロードのうちのどれが可能かを端末２３に通知する。
【００３４】
インストールとはユーザＡの選んだソフトウェアを端末２３のシステム、例えばＷＩＮＤＯＷＳに登録して、端末２３上で使用可能にすることを意味する。したがって、この場合はそのソフトウェアの実行ファイルをＷＩＮＤＯＷＳ上でアイコン登録する作業までを含む。これに対して、インストーラのアイコン登録とはインストールを実行するプログラムを端末２３上でアイコン登録することを意味する。
【００３５】
ここでは、インストールとダウンロードが許諾され（ＲＩＳ＝ＯＫ、ＤＬＯＡＤ＝ＯＫ）、インストーラのアイコン登録は行わない（ＩＣＯＮ＝ＮＧ）という条件が提示される。複雑なインストールプログラムを持つソフトウェアの場合には、インストールが許諾される代わりにインストーラのアイコン登録が必要である旨が提示される。また、ＷＩＮＤＯＷＳを搭載している端末からＴＯＳ（ＴＯＷＮＳのＯＳ）用のアプリケーションを要求されたような場合には、ダウンロードのみが許諾される。
【００３６】
次に、端末２３の端末ソフトはインストール、インストーラのアイコン登録、ダウンロードの順に優先順位をつけて、より優先順位の高いものをデフォルトとして設定し、表示装置２４の画面に表示する。ここでは、ホスト計算機２１により許諾されたインストールとダウンロードのうち優先順位のより高いインストールがデフォルトとして設定され、インストール方法選択ウィンドウに表示される。
【００３７】
図３３は、インストール方法選択ウィンドウの表示例を示している。図３３において、「システム登録」がインストールに相当し、これがデフォルトで選択されている。
【００３８】
ユーザＡは表示されたインストール方法を確認して、確認した旨を入力する（ステップＳ１５）。また、ユーザＡはここで表示された設定を変更することもできる。例えば、インストーラのアイコン登録を行いたいときは、図３３のインストール方法選択ウィンドウ内の「インストーラのアイコン登録」を選択して入力する。
【００３９】
基本的には、ユーザＡは手間をかけずにできあいのインストールを行いたい場合は「システム登録」を選択し、細かいインストール設定を自分で行いたい場合は「インストーラのアイコン登録」を選択し、格納場所を後で変更したい（別の機種の端末にインストールしたい）場合は「ダウンロード」を選択する。「ダウンロード」を選択すれば、端末２３の機種とは異なる機種用のソフトウェアを入手して動作するかどうか試してみることも可能になる。
【００４０】
次に、端末２３はホスト計算機２１から指示された宅配用のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴを、ハードディスク２５内に自動的に生成する（ステップＳ１６）。ここでもし、端末２３にサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴが既に存在している場合は、例えばＤ：￥ＳＯＵＫＯ￥ＴＥＴ  ００１というサブディレクトリをつくり、これも既に存在している場合はＤ：￥ＳＯＵＫＯ￥ＴＥＴ  ００２というサブディレクトリをつくる。
【００４１】
テトリスのファイル本体４１はファイルＴＥＴ１．ＬＺＨ（Ｆ１）とＶＢＲＪＰ２００．ＤＬＬ（Ｆ２）とから成り、ＴＥＴ１．ＬＺＨは４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣを圧縮してできている。ＴＥＴ１．ＬＺＨを圧縮前の状態に伸長（解凍）するとこれらの４つのファイルに分かれるが、ＴＥＴ１．ＬＺＨの解凍はホスト計算機２１から端末２３に配送された後に行われる。
【００４２】
宅配用のサブディレクトリを生成した端末２３は、リモートインストールの開始を依頼するコマンドＲＩＳ ＩＮＳＴＡＬＬを選択したソフトウェアの番号とともにホスト計算機２１に送る（図３２、ステップＳ１７）。これを受けて、ホスト計算機２１は送られた番号に対応するソフトウェアのリモートインストールを開始する。リモートインストールは、ホスト計算機２１が作成したテトリスのインストールスクリプト４２に従って、ホスト計算機２１と端末２３の間のやりとりにより自動的に行われる（ステップＳ１８）。
【００４３】
インストールスクリプト４２には、まずファイルＴＥＴ１．ＬＺＨをユーザＡ側の格納場所＠ＳＯＵＫＯ＠にダウンロードすることを指示する記述がある。そこで、ホスト計算機２１は＠ＳＯＵＫＯ＠をＳＯＵＫＯＤＩＲ＝Ｄ：￥ＳＯＵＫＯ￥ＴＥＴに置き換えて、ハードディスク２５のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴにＴＥＴ１．ＬＺＨをダウンロードする。
【００４４】
端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて、ハードディスク２５のディレクトリＤ：￥ＷＩＮＤＯＷＳにＶＢＲＪＰ２００．ＤＬＬをダウンロードする。
【００４５】
端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）にダウンロードしたＴＥＴ１．ＬＺＨを解凍する指示、ＬＨＡ  Ｘ  Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＥＴ１．ＬＺＨを送る。これを受けて、端末２３はＴＥＴ１．ＬＺＨを前述した４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣに解凍する。これらの４つのファイルはＴＥＴ１．ＬＺＨと同じサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴに保持される。
【００４６】
端末２３から解凍の完了（ＯＫ）を通知されると、次にホスト計算機２１は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）の機種＠．ＤＲＶというファイルを格納場所＠ＷＩＮＤＩＲ＠（Ｄ：￥ＷＩＮＤＯＷＳ）に移動させてファイル名をＦＯＮＴ．ＤＲＶに変更する指示、ＭＯＶＥ  Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＯＷＮＳ．ＤＲＶ  Ｄ：￥ＷＩＮＤＯＷＳ￥ＦＯＮＴ．ＤＲＶを送る。このとき、ホスト計算機２１はユーザＡ環境ファイル３９を参照して、機種＠をＴＯＷＮＳに置き換えて送る。これを受けて、端末２３はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＯＷＮＳ．ＤＲＶをディレクトリＤ：￥ＷＩＮＤＯＷＳに移動し（ファイル移動）、ＦＯＮＴ．ＤＲＶというファイル名に変更する（リネーム）。
【００４７】
端末２３からファイル移動およびリネームの完了（ＯＫ）を通知されると、次にホスト計算機２１は、ファイルＴＥＴＲＩＳ．ＥＸＥのアイコン登録を行う指示、ＩＣＯＮ  ＴＥＴＲＩＳ．ＥＸＥを送る。これを受けて、端末２３はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＥＴＲＩＳ．ＥＸＥをアイコン化して端末２３内に登録する。これにより、表示装置２４の画面に表示された倉庫ウィンドウ３６内に、例えばＴＥＴＲＩＳ．ＥＸＥを起動するアイコン３７が表示され、アイコン３７をクリックすればテトリスが動作を開始する。
【００４８】
端末２３からアイコン登録の完了（ＯＫ）を通知されると、ホスト計算機２１はＲＥＴＵＲＮを送り返してリモートインストールの終了を端末２３に通知し、一連のインストール作業を終了する。リモートインストールの終了を通知された端末２３は、ユーザＡの指示に従って次のソフトウェアの選択とそのリモートインストールを行うか、あるいは処理を終了する（ステップＳ１９）。
【００４９】
ステップＳ１８のインストール時に、インストールするソフトウエェアがそのダウンロード先の格納場所の空き容量に比べて大きければ、格納場所を変更してダウンロードする。
【００５０】
次に、図３４から図３９までを参照しながら、リモートインストールのプロトコルの例と第１および第２のキーワードの表示例について説明する。
図３４は、ステップＳ３の端末２３によるホスト計算機２１へのアクセス時に、端末２３が環境情報を送るプロトコルの一例を示している。図３４のプロトコルにおいて、リクエストＩＤ（ＲＩＤ）、端末を特定するマシンＩＤ（ＭＩＤ）、日時（ＴＩＭＥ）に続いて、端末２３に関するマシン情報（ＭＡＣＨＩＮＥ：）が記述されている。
【００５１】
ＭＡＣＨＩＮＥ：の中のドライブ情報（ＤＲＶ：）には、容量やドライブ名等のハードディスク２５に関する情報が記述されている。例えば、ＰＡＲＴＩＮＦ：の中のＣＡＰＡＣＩＴＹはそのパーティションの容量を表し、ＶＡＣＡＮＴはそのうちの空き容量を表し、ＤＲＶＮＡＭＥはそのパーティションに対応するドライブ名を表す。
【００５２】
ＤＲＶ：に続いて、宅配用の格納場所である倉庫ディレクトリＳＯＵＫＯＤＩＲと、ＯＳ（ＷＩＮＤＯＷＳ）の格納場所であるディレクトリＷＩＮＤＩＲが記述されている。ここでは、ＳＯＵＫＯＤＩＲ＝Ｄ：￥ＲＩＳ￥ＳＯＵＫＯであり、ＷＩＮＤＩＲ＝Ｄ：￥ＷＩＮＤＯＷＳである。その次には、メモリに関する情報（ＭＥＭ：）がある。このＳＯＵＫＯＤＩＲを指定することにより、端末２３はホスト計算機２１に宅配先を通知する。
【００５３】
そして、ＭＡＣＨＩＮＥ：に続いて、端末２３のマシンパスワード（ＭＰＳＷＤ）等が記述される。
図３５は、ステップＳ１４の環境チェックの終了時に、ホスト計算機２１がＳＯＵＫＯＤＩＲにサブディレクトリを付加して送り返すプロトコルの一例を示している。図３５のプロトコルにおいて、ＲＩＤ、環境チェックの判定結果（ＪＵＤＧＥ）に続いて、宅配先に関する情報（ＳＴＲＰＬＡＣＥ：）が記述されている。
【００５４】
ＳＴＲＰＬＡＣＥ：の中のＳＯＦＴはステップＳ１２でユーザが選択したソフトウェアの番号を表し、ＷＯＲＫＤＩＲは作業領域を表し、ＳＯＵＫＯＤＩＲはホスト計算機２１が指定した宅配先を表す。ここでは、ＷＯＲＫＤＩＲは図３４のＳＯＵＫＯＤＩＲと同じであり、ＳＯＵＫＯＤＩＲは図３４のＳＯＵＫＯＤＩＲにサブディレクトリ名ＦＭを付加した形になっている。
【００５５】
ＳＴＲＰＬＡＣＥ：に続いて、作業領域のサイズＷＯＲＫＳＩＺおよび宅配先のサイズＳＯＵＫＯＳＩＺが記述されている。
図３６は、ステップＳ４からＳ９において、ホスト計算機２１が第１および第２キーリストを端末２３に送り、ユーザＡの選択したキーワードのキー番号を端末２３が送り返すプロトコルの一例を示している。図３６のプロトコルにおいて、端末２３がコマンドＲＩＳ ＫＥＹＬＩＳＴにより第１キーリストを要求すると、ホスト計算機２１がレスポンスとしてＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに第１キーテーブルの内容ＫＥＹＬＩＳＴ：を送り返す。このＫＥＹＬＩＳＴ：内には、キー番号ＫＥＹ＝１、２、３、・・・に対応してキーワードＮＡＭＥ＝”ＯＳ／基本ソフト”、”開発支援”、”ゲーム”、・・・が記述されている。
【００５６】
次に、端末２３がコマンドＲＩＳ ＫＥＹＬＩＳＴとともに、ユーザＡの選
択した第１キーワード”ゲーム”のキー番号３を送ると、ホスト計算機２１がレスポンスとしてＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに、キー番号３に対応する第２キーテーブルの内容ＫＥＹＬＩＳＴ：を送り返す。このＫＥＹＬＩＳＴ：内には、キー番号ＫＥＹ＝５１、５２、５３、５４、５５、・・・に対応してキーワードＮＡＭＥ＝”ＲＰＧ”、”アクション”、”パズル／クイズ”、”シミュレート”、”冗談”、・・・が記述されている。
【００５７】
そして、端末２３はコマンドＲＩＳ ＬＩＳＴとともに、ユーザＡの選択した第２キーワード”アクション”および”冗談”のキー番号５２および５５をホスト計算機２１に送り、３つのキー番号３、５２、５５を持つソフトウェアのリストを要求する。ここでは、既におくった第１キーワードのキー番号３はホスト計算機２１が記憶しているので、第２キーワードのキー番号５２および５５のみが送られる。
【００５８】
図３７は、第１および第２キーワードの表示例を示している。図３７における第１および第２キーワードは図３６のそれらとは異なっている。ユーザＡが見ている表示装置２４の画面には、例えば画像、ゲーム等の第１キーワードが表示され、ユーザＡが第１キーワードを選択すると、次にツール、テキスト、ＤＯＳ、ＷＩＮ、画像、音声、ゲーム等の第２キーワードが表示される。第２キーワードの中には、画像、ゲームのように第１キーワードと重複するものも含まれる。
【００５９】
ユーザＡは、表示されたいずれのキーワードも選択することができる。例えば、第１キーワードとして画像を選び、第２キーワードとしてツール、ＤＯＳ、ゲーム等を選んだり、あるいは第１キーワードとしてゲームを選び、第２キーワードとしてＤＯＳ、ＷＩＮ、画像、音声等を選ぶ。また、ユーザＡは第２キーワードとして２つ以上のキーワードを同時に選択することもできる。
【００６０】
一般に、ソフトウェア群３５の中から希望するソフトウェアを選択するためのキーワードは多数あるので、これらを一度に全部表示すると見づらく、まったく必要のないものも表示される。そこで、これを単純なツリー構造のメニューにして表示すると、最初に選択するキーワードが重要な役割を果たし、そこで選択を誤ると欲しいソフトウェアは得られなくなってしまう。
【００６１】
そこで、図３７のように重複を許して２つの階層でキーワードを表示することにより、ユーザは多数のキーワードの中から必要なものをより柔軟に選びだすことが可能になる。尚、キーワードの階層は２階層に限らず、より多くの階層に分けて表示してもよい。
【００６２】
ソフトウェア群３５の各ソフトウェアのコンテンツは、あらかじめいくつかのキーワードと関係付けられて格納されている。例えば図３７において、ソフトＡはゲーム、画像、ＤＯＳの３つのキーワードを持ち、ソフトＢは画像、ツール、ＷＩＮ、ゲームの４つのキーワードを持つ。したがって、ユーザＡが画像とゲームの２つのキーワードを選択すると、これらの２つのソフトウェアを含むリストがホスト計算機２１から送られてきて画面に表示される。
【００６３】
図３８は、ステップＳ３のホストアクセス時において、端末２３からホスト計算機２１へ送られる環境情報の送信プロトコルの他の例を示している。図３８のプロトコルにおいて、マシン情報ＭＡＣＨＩＮＥ：の中のＭＯＤＥＬは、ステップＳ１において端末ソフトのインストール時に取得した情報で、端末２３の機種ＴＯＷＮＳを表す。また、ＰＡＲＴＩＮＦ：の中のＶＡＣＡＮＴは、ステップＳ３のホスト計算機２１へのアクセスの前（ステップＳ２）に取得した情報で、対応するパーティションの空き容量を表す。
【００６４】
図３９は、ステップＳ１４における環境チェックとその後のステップＳ１７におけるインストール開始のプロトコルの一例を示している。図３９のプロトコルにおいて、まず端末２３はコマンドＲＩＳ ＣＨＫＥＮＶとともにユーザＡの選んだソフトウェアの番号（ソフトコード）ＳＯＦＴ＝５をホスト計算機２１に送り、環境チェックを要求する。
【００６５】
ホスト計算機２１は、まずＶＢＲＪＰ２００．ＤＬＬというファイルが端末２３のシステムディレクトリにあるかどうか調査するための指示ＣＨＫＥＸＥ：を、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。ＣＨＫＥＸＥ：には、ＴＡＧ＝”ＶＢＲＪＰ２００．ＤＬＬ”、コマンドＣＭＤ＝”ＳＴ４  Ｄ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭ￥ＶＢＲＪＰ２００．ＤＬＬ”、作業用ディレクトリの指定ＷＯＲＫＤＩＲ＝”Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ”、宅配先のディレクトリの指定ＳＯＵＫＯＤＩＲ＝”Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ”等が記述されている。
【００６６】
端末２３は、ドライブＤのディレクトリＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭにファイルＶＢＲＪＰ２００．ＤＬＬがあるかどうか調べ、その結果をＲＥＳＵＬＴ：としてホスト計算機２１に送り返す。ＲＥＳＵＬＴ：には、対応するＴＡＧ＝”ＶＢＲＪＰ２００．ＤＬＬ”とともに調査結果ＶＡＬ＝”ＯＦＦ”が記述されている。これは、ファイルＶＢＲＪＰ２００．ＤＬＬがシステムディレクトリになかったことを意味する。
【００６７】
そこで、ホスト計算機２１は、選択されたソフトウェアをインストールしてよいかどうかをユーザに問い合わせる指示ＡＳＫＣＨＫ：を、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。ＡＳＫＣＨＫ：には、ＴＡＧ＝”Ｑ１”、表示すべき質問文ＱＵＥＲＹ＝”このソフトを実行するためには〜インストールしてもよろしいですか？”、および回答のフォーマットＡＮＳ：が記述されている。
【００６８】
端末２３は、ユーザＡが入力した回答をＲＥＳＵＬＴ：として、コマンドＲＩＳ ＣＨＫＥＮＶとともにホスト計算機２１に送り返す。ＲＥＳＵＬＴ：には、対応するＴＡＧ＝”Ｑ１”とともに回答結果ＶＡＬ＝”ＯＫ”が記述されている。これは、ソフトウェアをインストールしてもよいという意味である。
【００６９】
そこで、ホスト計算機２１は、他に動作環境上の障害がなければ、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに環境チェック結果ＪＵＤＧＥ＝”ＯＫ”を端末２３に送る。これは、ファイルＶＢＲＪＰ２００．ＤＬＬがないことを除いて、ソフトコード５番のソフトウェアの動作環境が整っており、インストールが可能であることを意味する。
【００７０】
環境チェックの結果が”ＯＫ”となったので、端末２３はコマンドＲＩＳ ＩＮＳＴＡＬＬとともに、インストール方法の種別ＴＹＰＥ＝”ＲＩＳ”、宅配先の指定ＳＴＲＰＬＡＣＥ：等をホスト計算機２１に送り、インストールを要求する。ＳＴＲＰＬＡＣＥ：には、インストールするソフトウェアのソフトコードＳＯＦＴとともに、作業用ディレクトリＷＯＲＫＤＩＲ、宅配先のディレクトリＳＯＵＫＯＤＩＲが記述されている。
【００７１】
以後、ホスト計算機２１は指定された方法でソフトウェアのインストールを行う。インストールの際には、例えば図３２のステップＳ１８で説明したようにホスト計算機２１から送られるコマンドにより、端末２３がファイルを解凍して、コピーして、システムに登録するという逐次作業を行う。これらの作業が完了したかどうかは、端末２３がレスポンスとして逐次送り返すので、ホスト計算機２１はインストール作業の進行状況を最後まで監視することができる。
【００７２】
しかしこの方法では、端末２３が頻繁にホスト計算機２１との通信を行わなければならないので、通信の効率が悪くなる。そこで、ホスト計算機２１がインストール作業のコマンドを記述した設定ファイルを用意し、これを端末２３に渡して自動インストールを行わせる方法が考えられる。
【００７３】
図４０は、設定ファイルを用いた自動インストールのフローチャートである。図４０のインストール作業は、図３１のステップＳ１６におけるサブディレクトリの生成の後に行われる。
【００７４】
端末２３は、まずコマンドＲＩＳ ＩＮＳＴＡＬＬをソフトウェアの番号とともにホスト計算機２１に送る（ステップＳ２１）。これを受けて、ホスト計算機２１は送られた番号に対応するソフトウェアのリモートインストールを開始する。リモートインストールは、ホスト計算機２１が作成したテトリスのインストールスクリプト４３に従って、ホスト計算機２１と端末２３の間のやりとりにより自動的に行われる（ステップＳ２２）。
【００７５】
ホスト計算機２１は、まず＠ＳＯＵＫＯ＠をＳＯＵＫＯＤＩＲ＝Ｄ：￥ＳＯＵＫＯ￥ＴＥＴに置き換えて、ハードディスク２５のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴにファイルＴＥＴ１．ＬＺＨをダウンロードする。
【００７６】
端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて、ハードディスク２５のディレクトリＤ：￥ＷＩＮＤＯＷＳにＶＢＲＪＰ２００．ＤＬＬをダウンロードする。
【００７７】
端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＳＯＵＫＯ＠をＳＯＵＫＯ＝Ｄ：￥ＳＯＵＫＯに置き換えて、端末２３が行うべき作業のコマンドを記述したユーザＡ用設定ファイル４４（ＳＥＴＵＰ．ＩＮＦ）を、ハードディスク２５のディレクトリＤ：￥ＳＯＵＫＯにダウンロードする。このとき、ホスト計算機２１はステップＳ１８と同様にユーザＡ環境ファイル３９を参照して、設定ファイルＳＥＴＵＰ．ＩＮＦに含まれる機種、ＳＯＵＫＯ、ＷＩＮＤＩＲ等の情報をユーザＡ用の情報に書き換えて送る。設定ファイルＳＥＴＵＰ．ＩＮＦには、ファイルＴＥＴ１．ＬＺＨを解凍し、ファイルＴＯＷＮＳ．ＤＲＶを移動してリネームし、ファイルＴＥＴＲＩＳ．ＥＸＥをシステムに登録する一連の作業が記述されている。
【００７８】
端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、設定ファイルＳＥＴＵＰ．ＩＮＦの記述に従って自動インストールを行う指示ＩＮＳＴＡＬＬ  Ｄ：￥ＳＯＵＫＯ￥ＳＥＴＵＰ．ＩＮＦを端末２３に送る。
【００７９】
これを受けて端末２３は、設定ファイルＳＥＴＵＰ．ＩＮＦの記述に従って自動インストールを行う。端末２３は、まずコマンドＬＯＧ  ＯＦＦによりホスト計算機２１との間の回線を遮断する。これ以降は、通信回線２２を使用しないので通信料金もかからない。次に、コマンドＬＨＡ  Ｘ  Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＥＴ１．ＬＺＨにより、ファイルＴＥＴ１．ＬＺＨを前述した４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣに解凍する。
【００８０】
次に、端末２３はコマンドＭＯＶＥ  Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＯＷＮＳ．ＤＲＶ  Ｄ：￥ＷＩＮＤＯＷＳ￥ＦＯＮＴ．ＤＲＶにより、ファイルＴＯＷＮＳ．ＤＲＶをディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴからＤ：￥ＷＩＮＤＯＷＳに移動させて、そのファイル名をＦＯＮＴ．ＤＲＶに変更する。次に、コマンドＩＣＯＮ  ＴＥＴＲＩＳ．ＥＸＥにより、ファイルＴＥＴＲＩＳ．ＥＸＥをアイコン化して端末２３内に登録する。そして、コマンドＰＯＦＦにより電源をオフにし、インストール作業を終了する。
【００８１】
設定ファイルを用いた自動インストールでは、ホスト計算機２１が作業終了の最終確認をすることはできないが、通信回数を削減することにより通信回線２２の使用効率を高めることができる。また、ソフトウェアの購入前に機種等のインストール条件を解決して、後は自動的にインストールが行われる。
【００８２】
図４１は、他の形式の設定ファイルの一例を示している。図４１の設定ファイルにおいて、〔ＤｓｔＤｉｒｓ〕はファイルの格納先のリストであり、〔Ｆｉｌｅｓ〕は格納すべきファイルのリストである。ここでは、ユーザが希望するソフトウェアの実行ファイルＳｏｆｔ２．ＥｘｅをディレクトリＤ：￥ＲＩＳ￥ＫＯＢＵＴＡに格納し、ＴＯＷＮＳ用のドライバであるＴＯＷＮＳ．ＤＲＶの名称をＦＯＮＴ．ＤＲＶに変更してディレクトリＤ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭに格納することが記述されている。
【００８３】
設定ファイルの生成時には、〔ＤｓｔＤｉｒｓ〕は１＝ＳＯＵＫＯＤＩＲ、２＝ＷＩＮＤＩＲと記述されるが、ホスト計算機２１が実際のＳＯＵＫＯＤＩＲ、ＷＩＮＤＩＲの情報を得た時点で、１＝Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ、２＝Ｄ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭと書き換えられる。このように、設定ファイルの中の設定条件は動的または選択的に変更することができる。
【００８４】
以上説明したように、先願によれば、配送センターから通信回線を介して、ユーザの希望するソフトウェアをその端末装置に自動的にインストールすることが可能になる。これを利用して、通信回線を介してソフトウェアをユーザに販売することも可能になる。
【００８５】
このとき、配送されたソフトウェアは専用のディレクトリに格納されるので保守性が良く、またユーザは配送先のディレクトリ等を指定する文字列を入力する必要がない。
【００８６】
ユーザは端末装置の画面上で希望するソフトウェアを効率よく選びだすことができ、そのインストールの方法も選択することができる。また、ユーザがソフトウェアの動作環境をチェックする必要がなく、自動的に環境チェックが行われる。
【００８７】
さらに、ソフトウェアのインストール時に通信回線の使用をできるだけ少なくすることができる。
【００８８】
【発明が解決しようとする課題】
しかしながら、上述のリモートインストールシステムには次のような問題がある。
【００８９】
配送センターのホスト計算機は、保持しているソフトウェアをユーザの端末装置に自動的にインストールすることができるが、逆に、ユーザが作成したソフトウェアを自動的に配送センターに登録するための機構が用意されていない。このため、新たにソフトウェアを登録するためには、配送センターのオペレータを介して必要なファイルのやり取りを行わなければならない。
【００９０】
また、配送センターに登録されたソフトウェアの管理形態が固定的であり、配送センターの単一の窓口を通してしかユーザに公開されない。一方、ユーザの希望するソフトウェアの分野は多様であるにもかかわらず、すべてのユーザがその窓口を通して登録ソフトウェアにアクセスする。したがって、配送センターの膨大なソフトウェアの中から希望するものを効率良く選び出すために、例えば複数のキーワードを入力する必要がある。
【００９１】
本発明は、ユーザの端末装置からソフトウェアを自動的にホスト計算機に登録し、それをフレキシブルに管理することのできるソフトウェア登録システムとその方法を提供することを目的とする。
【００９２】
【課題を解決するための手段】
図１は、本発明のソフトウェア登録システムの原理図である。図１のソフトウェア登録システムは、管理手段５１、記憶手段５２、およびインストール手段５３を備える。
【００９３】
管理手段５１は、登録されたソフトウェアを管理するための仮想的な場であって、ユーザ間で電子的に情報交換を行うための会議室機能を持つ１つ以上のクラブを、上記端末装置に提供する。
【００９４】
記憶手段５２は、上記クラブに対してアップロードされたソフトウェア情報を記憶する。
インストール手段５３は、記憶手段５２に記憶された上記ソフトウェア情報に基づいて、上記端末装置の格納領域にソフトウェアを自動的にインストールする。
【００９５】
管理手段５１が提供するクラブは、それに属するユーザの間で特定のテーマに関する情報を交換するための場であり、ユーザがあるクラブにアクセスすると、そのクラブで提供される会議室やリモートインストール等の機能がメニュー形式で端末装置の画面に表示される。ユーザは会議室機能を利用して、そのクラブに掲載されているソフトウェアに関する情報を、他のユーザやクラブの管理者から得ることができる。
【００９６】
また、ユーザは得られた情報を元にして、自分が作成したソフトウェア情報を特定のクラブにアップロードし、そこに登録することができる。ユーザはアップロード先のクラブを自由に選択することができ、管理手段５１はあるクラブにアップロードされたソフトウェア情報を他のクラブに転載することもできる。
【００９７】
ユーザからアップロードされたソフトウェア情報は、管理手段５１により記憶手段５２に自動的に格納され、アップロード者や他のユーザからの要求に基づいて、インストール手段５３により要求者の端末装置の適用なディレクトリに配送される。このとき、ユーザは希望するソフトウェアが掲載されている任意のクラブに対して、配送要求を出すことができる。
【００９８】
また、管理手段５１は、データベース登録処理に必要な基礎情報と、ソフトウェアの概要を記した説明情報と、ソフトウェアの本体を圧縮した本体情報とに分割され、標準化されたソフトウェア情報を端末装置から受け取り、そのソフトウェア情報を管理する。
【００９９】
記憶手段５２は、そのソフトウェア情報を記憶する。
端末装置からアップロードされるソフトウェア情報のフォーマットが標準化されているので、データベースへの自動登録が可能になり、アップロード情報のウィルスチェック等を自動的に行うこともできる。また、ソフトウェア情報を基礎情報と説明情報と本体情報とに分割して管理することにより、各情報毎に必要なチェックのみを行うことができ、エラー等が生じた場合でも、問題のある情報のみを修正してアップロードし直すことができる。したがって、ソフトウェアの登録処理が自動化されるとともに効率化される。
【０１００】
例えば、図１の管理手段５１およびインストール手段５３は、実施形態における図２のホスト計算機６３内のＣＰＵ（中央処理装置）に対応し、記憶手段５２はホスト計算機６３内のメモリまたはディスク装置に対応する。
【０１０１】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
図２は、実施形態のソフトウェア登録システムの構成図である。図２のソフトウェア登録システムにおいては、Ｎ個の端末６１−１、・・・、６１−Ｎが通信ネットワーク６２を介してホスト計算機６３と結合している。端末６１−１、・・・、６１−Ｎは、ソフトウェア登録システムの各ユーザの端末装置であり、ホスト計算機６３は配送センター側にある。ホスト計算機６３は、ネットワーク６２から見れば一台に見えるが、実際には、複数の計算機による分散処理も可能である。
【０１０２】
以下では、図２のソフトウェア登録システム内での情報交換の場の構成、構成員の権限、情報の形態、サービスの形態等について説明する。
図３は、ソフトウェア登録システム内での場の構成を示している。本実施形態においては、ホスト計算機６３の中に仮想的につくられた、クラブと呼ばれるユーザのグループが最小単位となり、ソフトウェア情報の交換の場を形成する。クラブの構成員は会員とも呼ばれる。図３において、クラブ７２、７３、７４は同じ階層に属し、それぞれが会議室機能と先願のリモートインストールシステム（ＲＩＳ）の機能とを持っている。
【０１０３】
これらのクラブ７２、７３、７４の上位階層には上位クラブ７１がある。この例ではクラブの階層は２階層であるが、一般的には何階層でもよい。宅配されるコンテンツとなるソフトウェアは、必ず、いずれかのクラブにアップロードされ、そこに登録される。例えば、ソフトウェア７５がクラブ７２にアップロードされると、クラブ７２に最初に登録され、クラブ７２はソフトウェア７５のオリジナルクラブとなる。オリジナルクラブに登録されたソフトウェアを他のクラブに持って行くには、転載という方法と移管という方法とがある。
【０１０４】
転載とは、ソフトウェアを他のクラブからも見えるようにすることを意味し、移管とは、オリジナルクラブの機能そのものを他のクラブに移すことを意味する。ソフトウェア７５を希望する会員は、オリジナルクラブ７２または転載先クラブ７１、７３のいずれかから、それをダウンロードすることができる。
【０１０５】
基本的には、オリジナルクラブを選ぶ権利はソフトウェア７５を作成した会員が持っている。しかし、作者がソフトウェア７５をアップロードして、一旦公開を許可したら、それを他のクラブに転載または移管する権利はオリジナルクラブの管理者に移る。現実の運用に当たっては、アップロードした作者や各クラブの管理者の間でこれらの権利について交渉する必要があるが、コンピュータ内の仕組みとしては、それぞれの権利をあらかじめ次のように決めておく。また、作者や各管理者の義務は、契約によって例えば次のように決められる。
（１）一般作者の権利と義務
コンテンツ（ソフトウェア）をアップロードする権利
自分のアップロードしたソフトウェアを無償でテスト宅配する権利（テスト時のＲＩＳの料金が無償になる）
ソフトウェアの公開を許可する権利
自分のアップロードしたソフトウェアをサポートする義務（ソフトウェアの利用者からの質問に答えたり、エラーが発生した時の修正を行ったりする）
（２）オリジナルクラブ管理者の権利と義務
クラブ内のソフトウェアを無償でテストする権利（テスト時のソフトウェア使用料が無償になる）
ソフトウェアを公開する権利
転載先クラブに転載の許可を出す権利
クラブ内のソフトウェアをサポートする義務
上位クラブには、特別な理由が無い限り、転載の許可を出す義務。
（３）転載先クラブ管理者の権利と義務
転載が許可されたソフトウェアを公開する権利
クラブ内のソフトウェアをサポートする義務
（４）上位クラブ管理者の権利
転載が許可されたソフトウェアを公開する権利
上位クラブは、基本的に下位クラブのソフトウェアを転載することができるので、最上位のクラブの会員はすべてのソフトウェアを閲覧することができるようになる。また、転載先クラブの管理者がソフトウェアの使用方法等を確実にサポートしてくれる事を条件に転載するので、ソフトウェアが閲覧可能なクラブ内で、そのサポートが必ず受けられる。
【０１０６】
図４は、ネットワーク６２との情報交換によりホスト計算機６３上で実現されるクラブの例を示している。ある端末からホスト計算機６３をアクセスすると、ホスト内には、ソフトウェアの専門店に対応するクラブＡ、Ｂ、Ｃと、あらゆるソフトウェアを販売するデパートＤＰが見える。
【０１０７】
ワープロクラブＡのＲＩＳには統合ＯＡ−Ａ１というソフトウェアが登録され、表計算クラブＢのＲＩＳには表計算−Ｂ１と統合ＯＡ−Ａ１が登録され、通信クラブＣのＲＩＳにはＯＬＤＴＥＲＭ−Ｃ１とＮＥＷＴＥＲＭ−Ｃ２が登録されている。デパートＤＰはこれらのクラブＡ、Ｂ、Ｃの上位クラブに相当し、ここには統合ＯＡ−Ａ１、表計算−Ｂ１、およびＮＥＷＴＥＲＭ−Ｃ２が登録されている。商品データベース８１には、システム内の各ソフトウェアの管理情報が格納される。
【０１０８】
図４において、（）で囲まれたソフトウェアは、管理者による作業が終了していないので、一般会員からは見えないようになっている。一般会員に見えているソフトウェアに関しては、所属クラブ内の何処かで会員が会議を開いて、情報交換することができる。
【０１０９】
尚、デパートＤＰは必ずしもクラブＡ、Ｂ、Ｃの上位クラブとして設ける必要はなく、クラブとは独立に商品を提供する機能を持たせてもよい。
ホスト計算機６３は、コンテンツを管理するために、商品データベース８１のようなコンテンツデータベースを用意し、次のような情報を格納する。
【０１１０】
ソフトウェアＩＤ：システムの中でソフトウェアコンテンツを一意に特定できる識別子
アップロード者ＩＤ：システム利用者を一意に特定できる識別子
オリジナルクラブＩＤ：システムの中でソフトウェアコンテンツを登録したクラブを一意に特定できる識別子
転載先クラブＩＤ：システムの中でソフトウェアコンテンツの転載先クラブを一意に特定できる識別子
キーワード：各クラブで使用するキーワード
最終アクセス日時：アップロードされたソフトウェアを書き換えた最後の日時、または、それを読み取った最後の日時
図５は、商品データベース８１の例を示している。図５の商品データベースにおいて、ソフトコード＝００１等はソフトウェアＩＤを表し、アップロード＝ＵＩＤ００１等はアップロード者ＩＤを表し、オリジナル＝Ａ等はオリジナルクラブＩＤを表し、転載先１＝Ｂ等は転載先クラブＩＤを表す。統合ＯＡ−Ａ１は他のクラブＢ、Ｃ、ＤＰに転載されており、ＯＬＤＴＥＲＭ−Ｃ１は転載されていない。また、新ワープロ−Ａ２は、アップロード後一時的に登録されたソフトウェアの例を表し、その領域には最終アクセス日時が記録されている。
【０１１１】
ここで、ソフトウェアの作者やクラブ等の管理者の権限を整理すると、例えば以下のようなコマンド群が有ればよいことが分かる。これらのコマンド群の機能の分割方法や実現方法には、文字ベース、コマンドベース、ＧＵＩ（graphical user interface）ベース等の方法があり、任意のものを用いることができる。
ＵＰＬＯＡＤ        ：ソフトウェアをシステムにアップロードする。
【０１１２】
ＲＩＳ              ：ソフトウェアをリモートインストールする。
ＰＵＳＨ            ：ソフトウェアの公開を許可する／取り消す。
ＰＵＢＬＩＳＨ      ：ソフトウェアを公開する／取り消す。
【０１１３】
ＰＥＲＭＩＴＩＯＮ  ：ソフトウェアの転載を許可する／取り消す。
ＬＩＮＫ            ：ソフトウェアの転載とキーワードの再割り付けを行う。
【０１１４】
ＭＯＶＥ            ：オリジナルクラブを移管する。
これらのコマンドのうち、ＰＵＳＨ、ＰＵＢＬＩＳＨ、ＰＥＲＭＩＴＩＯＮについては、適当なスイッチの記述を付加して取り消しの操作を表現する。
【０１１５】
図６は、作者および管理者のコマンドの使用権限を示している。ここでは、あるソフトウェアがオリジナルクラブにアップロードされた場合を想定している。図６において、○印は、そのソフトウェアをアップロードした作者、若しくは、それが自分のクラブ内にある管理者が使用することのできるコマンドを表している。
【０１１６】
上記コマンドのうちＰＥＲＭＩＴＩＯＮとＭＯＶＥは、オリジナルクラブの管理者のみが使用することができる。転載先クラブおよび上位クラブの管理者は、オリジナルクラブからＰＥＲＭＩＴＩＯＮにより転載を許可された場合に、ＬＩＮＫを使用してソフトウェアを転載することができる。ＬＩＮＫにより、転載先クラブまたは上位クラブからソフトウェアのファイルにリンクが張られ、それを参照することができるようになる。また、ＭＯＶＥにより、オリジナルクラブの権限が他のクラブに移管され、元のオリジナルクラブとファイルのリンクは切断される。
【０１１７】
次に、図７から図９までを参照しながら、作者や管理者の作業の手順について説明する。
図７は、作者の作業のフローチャートである。図７において作業が開始されると、作者は、まずソフトウェアを作成し、アップロードに必要なファイル群を用意する（ステップＳ３１）。次に、アップロードするクラブを選択し、ＵＰＬＯＡＤによりソフトウェアをアップロードして（ステップＳ３２）、アップロード先での自動チェックの結果を受け取る（ステップＳ３３）。ここでは、誤動作チェック、ウィルスチェック、著作権や商標権のチェック等が自動的に行われる。チェックの結果（ステップＳ３４）、エラーが発生すればエラー部分を修正し、修正部分のみ再びアップロードして（ステップＳ３５）、ステップＳ３３以降の作業を繰り返す。
【０１１８】
そして、自動チェックが通ったら、次にＲＩＳによりテスト宅配を行う（ステップＳ３６）。テスト宅配では、アップロードされたソフトウェアがリモートインストール時に問題を起こさないかどうかがチェックされる（ステップＳ３７）。テスト宅配でエラーが発生すればエラー部分を修正し、その部分のみ再びアップロードして（ステップＳ３８）、ステップＳ３６以降の作業を繰り返す。テスト宅配で合格したら、ＰＵＳＨによりソフトウェアの公開を許可し（ステップＳ３９）、作業を終了する。
【０１１９】
図８は、オリジナルクラブの管理者の作業のフローチャートである。図８において作業が開始されると、管理者は、まず作者により公開を許可されているソフトウェアをテスト宅配し（ステップＳ４１）、問題が無いかチェックする（ステップＳ４２）。テスト宅配で問題がなければ、ＰＵＢＬＩＳＨによりソフトウェアをオリジナルクラブの会員に公開し（ステップＳ４３）、問題があればそれを作者に連絡して（ステップＳ４４）、作業を終了する。
【０１２０】
図９は、転載先クラブの管理者の作業のフローチャートである。図９において作業が開始されると、管理者は、希望するソフトウェアがあったら、その転載許可をオリジナルクラブに依頼する（ステップＳ５１）。依頼に対する応答を受け取り（ステップＳ５２）、転載が許可されなければそのまま作業を終了する。ＰＥＲＭＩＴＩＯＮにより転載が許可されれば、ＬＩＮＫによりそのソフトウェアを自分のクラブに転載する（ステップＳ５３）。この時、自分のクラブで検索しやすいようにキーワードを変更しておく。
【０１２１】
次に、転載したソフトウェアをテスト宅配し（ステップＳ５４）、問題が無いかチェックする（ステップＳ５５）。テスト宅配で問題がなければ、ＰＵＢＬＩＳＨによりソフトウェアをクラブの会員に公開し（ステップＳ５６）、問題があればそれをオリジナルクラブに連絡して（ステップＳ５７）、作業を終了する。
【０１２２】
図７のステップＳ３２で、ネットワーク６２を介してホスト計算機６３にコンテンツを登録する場合に、アップロードする情報を標準化しておく。アップロードする具体的な方法としては、標準化され、いくつかに分類された情報に、その内容を示すＴＡＧを付けて送るようにする。情報を標準化することによって、登録作業やチェック作業の自動化が可能となる。また、情報を分割してアップロードすることにより、バグの発見時に必要な部分だけを再送し、再度のアップロードに要する時間を短縮することができる。アップロード情報は、大きく分類して次の５種類となる。
［１］ＣＦＧファイル（コンフィギュレーションファイル）：ソフトウェアをシステムに登録するための基礎情報（必須の情報）で、次のものを含む。
○データベースに登録するための情報
コンテンツ名称
コンテンツの前バージョン、現バージョン（必須ではない）
販売形態（フリーウェア／シェアウェア／市販品）
価格
動作可能なハードウェア
動作可能なＯＳ
検索キーワード
○インストールの本処理の情報
コンテンツ本体の圧縮方法
インストールの方法
○インストール時の前処理と後処理の情報
前処理の有無と方法
後処理の有無と方法
［２］説明ファイル：ソフトウェアの概要を書いた説明（必須の情報）
［３］本体ファイル：実行に必要なファイルを圧縮して１つにまとめたもの（必須の情報）
［４］ＣＨＫファイル（チェックファイル）：ソフトウェアが動作する環境条件を調査してリモートインストールを修飾するために、特別な言語で書かれたファイルで、環境依存性のあるソフトウェアのみ必要となる。よく使われるものはシステムで提供するが、特殊なものはオプションとしてユーザが作成する。ＣＨＫファイルには、例えば次のような情報が含まれる。
【０１２３】
ＣＨＫＥＸＥ：オプションで行われる環境チェックのための実行プログラムＶＥＲＳＩＯＮ：ＤＬＬ（dynamic link library）のバージョン情報のチェックをオプションで行う必要がある場合に作成される。
【０１２４】
図３１のチェックスクリプト４０のような情報をＣＨＫファイルに記述しておくこともできる。
［５］インストール関連ファイル：リモートインストールの実際の手順を書いたもので、次のような情報が含まれる。
【０１２５】
ＩＮＳＴＡＬＬ：実際のインストールの手順書（手順を標準化した場合は不要）
標準化したインストール処理は以下のようになり、大半のソフトウェアはこの範囲内でインストール可能である。
【０１２６】
１．指定されていれば、前処理を行う。
２．圧縮された本体を端末のワーク領域にダウンロードする。
３．本体を展開して、適当なディレクトリにファイルをコピーする。
【０１２７】
４．指定があれば、ファイル属性を変更する。
５．指定があれば、メニューやアイコン登録を行う。
６．指定があれば、後処理を行う。
ＩＣＯＮ：メニューとかマネージャといわれるものに、ソフトウェアを登録するための情報
ＦＩＲＳＴ：ＩＮＳＴＡＬＬを標準化した場合に、標準インストール処理の前に行う前処理で、例えば、バージョンアップ処理においては旧版のバックアップ処理等を指す。
【０１２８】
ＬＡＳＴ：ＩＮＳＴＡＬＬを標準化した場合に、標準インストールの後に行う後処理で、例えば、環境変数ファイルＣＯＮＦＩＧ．ＳＹＳの書換え処理等を指す。
図１０は、ステップＳ３１において、端末６１−ｉ（ｉ＝１，２，．．．，Ｎ）上で作成されるファイル群の例を示している。図１０においては、メモリ９１内で、ＣＦＧファイル９２、説明ファイル９３、本体ファイル９４、ＣＨＫファイル９５、およびインストール関連ファイル９６が作成され、これらがホスト計算機６３にアップロードされる。
【０１２９】
次に、図１１から図１８までを参照しながら、ファイルの具体例について説明する。図１１から図１４まではＣＦＧファイル９２の例を示しており、図１５、１６、１７、１８は、それぞれ説明ファイル９３、本体ファイル９４、ＣＨＫファイル９５、およびインストール関連ファイル９６の例を示している。
【０１３０】
図１１、１２、１３、１４のＣＦＧファイルにおいて、；で始まる行はコメント文であることを表す。図１１の［ｎａｍｅ］はソフト検索用名称を表し、［ｖｅｒｓｉｏｎ］はそのバージョンを表し、［ｏｌｄｖｅｒｓｉｏｎ］はその旧バージョンを表す。また、［ｔｙｐｅ］は販売形態を表し、［ｐｒｉｃｅ］は価格を表す。ここでは、［ｔｙｐｅ］はＳＨＡＲＥとなっており、シェアウェアであることを示している。［ｍａｃｈｉｎｅ］は動作可能なハードウェアを表し、ここではＴＯＷＮＳ、ＦＭＲ、ＰＣ９８、ＰＣ−ＡＴの４機種が挙げられている。
【０１３１】
図１２において、［ｏｓ］は動作可能なＯＳを表し、ここではＷＩＮ３１Ｊのみが挙げられている。［ｋｅｙ］は検索用のキーワードを表し、ここでは”中国語”がキーワードとして記されている。［ｃｏｍｐｒｅｓｓｉｏｎ］は本体の圧縮形式を表し、ここではＬＨＡ方式と記されている。また、［ｉｎｓｔｙｐｅ］は可能なリモートインストールの方法を表している。「ＲＩＳ      ｉｃｏｎ．ｄｅｆ」は、通常のリモートインストールを行ってアイコンファイルｉｃｏｎ．ｄｅｆに登録する方法を表し、「ＩＮＳＴＡＬＬＥＲ      ｉｃｏｎ２．ｄｅｆ」は、インストーラ（ＩＮＳＴＡＬＬ．ＥＸＥ）自体をアイコン登録する方法を表し、「ＤＬＯＡＤ」はダウンロードする方法を表す。ここでは、これらの方法のいずれもが可能となっている。
【０１３２】
図１３において、［ｓｏｕｋｏ］はインストール時にソフトウェアを格納する推奨ディレクトリを表し、ここではＰ１とＰ２の２つのディレクトリが記されている。
【０１３３】
［ｓｏｕｒｃｅ］は圧縮された本体ファイル（アーカイブファイル）の情報を表し、ここではＳ１とＳ２の２つのアーカイブファイルの情報が記されている。Ｓ１のファイル名はＮＥＷＷＰ．ＬＺＨで、展開後（解凍後）の格納ディレクトリは＠Ｐ１＠、展開時のモードはＭ、ファイル容量は８０００００バイト、展開後の最低必要容量は２００００００バイトである。また、Ｓ２のファイル名はＮＥＷＷＰＬＩＢ．ＬＺＨで、展開後の格納ディレクトリは＠Ｐ２＠、展開時のモードはＦ、ファイル容量は７０００バイト、展開後の最低必要容量は１３０００バイト、重複チェックの対象ファイル名はＧＳＷＤＬＬ．ＤＬＬである。
【０１３４】
ここで、モードＭが指定されていれば、端末側で展開先ディレクトリを変更することができ、モードＦが指定されていれば変更不可能である。また、ＧＳＷＤＬＬ．ＤＬＬは、アーカイブファイルＮＥＷＷＰＬＩＢ．ＬＺＨの中に圧縮格納されているファイルの１つで、端末上でファイル名の重複がないかどうかをチェックするために記されている。
【０１３５】
［ｄｅｓｔｉｎａｔｉｏｎ］は特殊な展開先ディレクトリを表し、ここではＤ１として＠ＷＩＮＳＹＳＴＥＭ＠が記されている。また、［ｃｏｐｙ］はインストール時に移動させるべきファイル等の情報を表し、ここでは、Ｃ１として、Ｓ２で指定したアーカイブファイルに含まれるファイルＧＳＷＤＬＬ．ＤＬＬを、Ｄ１で指定したディレクトリに同じファイル名で移動することが記されている。Ａｔｔｒの欄のＮは、移動後も属性が不変であることを表す。
【０１３６】
図１４において、［ｆｉｒｓｔ］は前処理の情報を表し、インストールの際にアーカイブファイルのダウンロード前に実行しておきたいコマンドが記される。［ｌａｓｔ］は後処理の情報を表し、インストールの際にアイコン登録コマンド実行後に実行したいコマンドが記される。
【０１３７】
図１５の説明ファイルは、図１１から図１４までのＣＦＧファイルに記述された新ワープロ−Ａ２というソフトウェアの概要をユーザに説明するための情報であり、図１６の本体ファイルは、そのアーカイブファイルを示している。アーカイブファイルＮＥＷＷＰ．ＬＺＨは、３つのファイルＷＰ．ＥＸＥ、ＮＥＷＷＰ．ＩＣＯ、ＲＥＡＤＭＥ．ＤＯＣを含んでおり、アーカイブファイルＮＥＷＷＰＬＩＢ．ＬＺＨは１つのファイルＧＳＷＤＬＬ．ＤＬＬのみを含んでいることが分かる。
【０１３８】
図１７のＣＨＫファイルは、インストール時の環境チェックのチェックスクリプトに対応する。ここでは、ＷＰ．ＥＸＥというファイルがユーザの端末にあるかどうかのチェックと、もしあれば、それが最新のバージョンかどうかのチェックと、それぞれのチェック結果に応じた処理とが記述されている。
【０１３９】
図１８は、インストール関連ファイル９６の一種であるＩＣＯＮファイルを示している。図１８のＩＣＯＮファイルには、新ワープロ−Ａ２の実行ファイル、カレント・ワーキング・ディレクトリ、アイコン登録用のファイル等の情報が記述されている。このＩＣＯＮファイルは、リモートインストール時のシステム登録の際に使用される。
【０１４０】
以上説明したような本実施形態のソフトウェア登録システムにより、以下のようなサービスが行われる。
（ａ）アップロード者が公開依頼を出す前のソフトコードと公開依頼後のソフトコードを別にしておき、宅配の要求にテストフラグを付けておく。アップロード者本人がテスト宅配する場合には公開前のソフトコードでテストして、エラーが起これば問題のある部分だけを再度アップロードすればよいようにする。そして、公開後のコンテンツは修正できないようにして、公開後の改変を禁止する。
【０１４１】
また、管理者かアップロード者が、テストフラグをＯＮにして宅配要求をした場合には、無償でリモートインストールができるように管理する。
（ｂ）商品データベース８１に記されたソフトコードとオリジナルクラブの対応関係を用いて、ソフトウェア名から、それをサポートしているクラブ（サポートクラブ）の一覧を取り、直接サポートクラブへ行けるようにする。これはＭＭＩ（man-machine interface ）の問題であるが、ソフトウェアのサポートを受けたい場合に、ソフトウェア名を選ぶことによって、直ちにサポートクラブが分かるので、１アクションでサポート場所への移動ができる。
（ｃ）ユーザにサポートクラブを提示する時に、オリジナルクラブが最初に見えるように表示して、それに優位性を持たせる。一般に、ソフトウェアの作者は、サポート能力の高い管理者がいるクラブにアップロードしようとする傾向がある。このため、そのようなクラブがオリジナルクラブになりやすく、オリジナルクラブをＭＭＩ上最初に表示することで、能力の高い管理者のクラブに人がアクセスしやすくなる。アクセスしてくる会員が多いクラブほど、その管理者に対する報酬も多くなり、管理者の努力が報われる結果となる。
（ｄ）クラブの中から希望するソフトウェアのリモートインストールができるようにする。会議室での会話の中から必要なソフトウェアが見つかった場合等を考慮して、図３、４に示したように、クラブ内にもＲＩＳ機能を設ける。この場合は、クラブ毎に検索用のキーワードが変更できるので、各クラブの特色を活かしたリモートインストールを実現できる。
（ｅ）アップロードから公開許可までの間に、ソフトウェアの正当性のチェックを行う。アップロードフォーマットが標準化されているので、文法チェック／ウィルスチェック／著作権チェック／登録商標チェック／ソフトウェア名の重複チェック等を自動化することができる。これらのテスト項目のうち文法チェック以外は、ホスト計算機６３内に危険と見なされる文字列やコード列のデータを持っておく。そして、アップロード情報をそれらと比較し、両者が一致した時にアラームを上げる。最終判断は人間が行ってもよい。
【０１４２】
文法チェックを行うべきアップロード情報には、ＣＦＧファイル９２、ＣＨＫファイル９５、ＩＮＳＴＡＬＬ、ＩＣＯＮ等があり、ウィルスチェックを行うべきアップロード情報には、本体ファイル９４、ＣＨＫＥＸＥ、ＦＩＲＳＴ、ＬＡＳＴ等がある。また、著作権／登録商標チェックを行うべきアップロード情報には、ＣＦＧファイル９２、本体ファイル９４等がある。
（ｆ）テスト途中のソフトウェアは、一定期間アクセスが無い場合には自動的に削除して、記憶領域の無駄遣いを避ける。テスト途中のソフトウェアは、デバックや修正の時に変更部分のみのアップロードができるように、一定期間はホスト計算機６３内のディスク装置に保存しておくが、その期間を過ぎたらディスクから自動的に削除する。
【０１４３】
例えば図５に示される新ワープロ−Ａ２のように、ＴＭＰ（テンポラリ）のソフトコード９０５は、９で始まる特別な形をしている。そこで、定期的に商品データベース８１をパトロールして、ＴＭＰのソフトコードの最終アクセス日時を調べ、一定期間を過ぎたものは消去することができる。
次に、図１９から図２８までを参照しながら、上述のようなサービスの具体例について説明する。
【０１４４】
図１９および図２０は、作成されたファイル群のアップロードの例を示している。図１９において、作者はＵＰＬＯＡＤを用いて、新ワープロ−Ａ２のファイル群１０１を種類毎に分割して、自分の端末からホスト計算機６３に送信する。まず、１分割目としてＣＦＧファイルを送信し（ステップＳ１０１）、ホスト計算機６３はディスク内のＴＭＰ領域にそれを受信する（ステップＳ２０１）。作者は１分割目の送信結果としてＯＫを受け取ると（ステップＳ１０２）、次に、２分割目として説明ファイルを送信する（ステップＳ１０３）。さらに、２分割目の送信結果としてＯＫを受け取ると（ステップＳ１０４）、２分割目のファイルを送信する。このようにして、最終分割の本体ファイルを送信すると（図２０、ステップＳ１０５）、ホスト計算機６３はアップロードされたファイル群の管理情報を商品データベース８１に追加する（ステップＳ２０２）。
【０１４５】
これにより、商品データベース８１には、新たにアップロードされたソフトウェアのソフトコードが９０５で、アップロード者ＩＤがＵＩＤ００３で、オリジナルクラブＩＤがＡで、キーワードが中国語である等の情報が登録される。ここで、９で始まる３桁のソフトコードは、そのソフトウェアがテスト中であることを表す。
【０１４６】
作者は、最終分割の送信結果としてＯＫを受け取ると（ステップＳ１０６）、作業を終了する。このとき、ＴＭＰのソフトコード（ＴＭＰコード）９０５がホスト計算機６３から通知される。一方、ホスト計算機６３は、アップロードされたファイルの正当性のチェックを自動的に行い（ステップＳ２０３）、エラー等があれば、それを作者の端末に通知する。
【０１４７】
図２１は、アップロードされたソフトウェアのテスト宅配の例を示している。先願のリモートインストールにおいてソフトウェアの検索を要求するプロトコル上にテストフラグ（ＴＦＬＧ）を設けて、テスト宅配の権限をチェックする。これにより、権限を持っている人にのみ、公開前のソフトウェアを見せるようにする。
【０１４８】
図２１において、作者または管理者が端末からキーワードの一覧を要求すると（ステップＳ１１１）、ホスト計算機６３はこれに無条件に応答し、キーワードリストを送り返す（ステップＳ２１１）。次に、端末から、ＴＦＬＧ＝１として、キーワード「中国語」による検索要求が送られると、ホスト計算機６３は権限チェックを行う（ステップＳ２１２）。
【０１４９】
権限チェックにおいてはテストフラグの値を調べ、ＴＦＬＧ＝０のときは公開済みのソフトウェアのみを検索する。ＴＦＬＧ＝１、かつ、要求者が一般会員の場合は、商品データベース８１のＴＭＰコードを持つソフトウェアを探し、そのうちアップロード者ＩＤが要求者のログインＩＤと一致するものの中から検索する。また、ＴＦＬＧ＝１、かつ、要求者が管理者の場合は、商品データベース８１のソフトウェアのステータスを調べ、公開許可済み、転載済み、または移管済みのものを検索する。ＴＦＬＧ＝０の場合は権限チェックの結果を不合格として、宅配料金を課金する。ＴＦＬＧ＝１の場合は、権限チェックの結果を合格として、無償扱いとする。
【０１５０】
ここでは、ＴＦＬＧ＝１なので宅配は無償となり、要求者は検索されたソフトウェアの中から目的とする新ワープロ−Ａ２を選択し、ＴＦＬＧ＝１として、その環境チェックを要求する（ステップＳ１１３）。ホスト計算機６３は、ステップＳ２１２と同様の権限チェックを行う（ステップＳ２１３）。それ以降の動作は、図３１のステップＳ１４以降と同様である。ただし、テスト宅配中に何らかの問題が起これば、要求者は図７、図８、または図９のいずれかのフローに従ってエラー処理を行う。
【０１５１】
図２２は、テスト宅配に合格したソフトウェアの公開依頼の例を示している。図２２において、作者がコマンドＰＵＳＨを用いて、テスト宅配に合格したソフトウェア９０５の公開を依頼（許可）すると（ステップＳ１２１）、ホスト計算機６３は権限チェックを行う（ステップＳ２２１）。このとき、商品データベース８１を参照し、ソフトウェア９０５のアップロード者ＩＤが依頼者のログインＩＤと一致し、かつ、オリジナルクラブＩＤが依頼とともに送られたクラブのＩＤと一致した時にのみ公開依頼を受け付け、それ以外の場合は拒否する。公開依頼を受け付けると、正式のソフトコード００５を新たに取って、商品データベース８１内でソフトウェア９０５の管理情報をすべてコピーする（ステップＳ２２２）。そして、そのソフトコード００５を端末に通知する。
【０１５２】
図２３は、公開許可済みのソフトウェアの公開の例を示している。図２３において、クラブの管理者がコマンドＰＵＢＬＩＳＨを用いて、ソフトウェア００５の公開を要求すると（ステップＳ１３１）、ホスト計算機６３は権限チェックを行う（ステップＳ２３１）。このとき、商品データベース８１を参照し、ソフトウェア００５のステータスが公開許可済み（ＰＵＳＨ済み）、転載済み（ＬＩＮＫ済み）、移管済み（ＭＯＶＥ済み）のいずれかで、かつ、要求者のログインＩＤが管理者のＩＤと一致した時にのみ公開要求を受け付け、それ以外の場合は拒否する。公開要求を受け付けると、商品データベース８１内のソフトウェア００５のステータスを公開済み（ＰＵＢＬＩＳＨ済み）に変更して、それを公開する（ステップＳ２３２）。
【０１５３】
図２４は、公開されたソフトウェアの転載を許可する例を示している。図２４において、オリジナルクラブの管理者がコマンドＰＥＲＭＩＴＩＯＮ用いて、ソフトウェア００５のクラブＢへの転載を許可すると（ステップＳ１４１）、ホスト計算機６３は権限チェックを行う（ステップＳ２４１）。このとき、商品データベース８１を参照し、ソフトウェア００５のステータスがＰＵＢＬＩＳＨ済みで、かつ、ログインＩＤが管理者のＩＤと一致した時にのみ転載許可を受け付け、それ以外の場合は拒否する。転載許可を受け付けると、商品データベース８１内のソフトウェア００５の管理情報に転載先情報（転載先クラブＢのＩＤ）を新たに追加し、ステータスを転載許可済み（ＰＥＲＭＩＴＩＯＮ済み）に変更する（ステップＳ２４２）、。
【０１５４】
図２５は、転載を許可されたソフトウェアの転載の例を示している。図２５において、転載先クラブＢの管理者がコマンドＬＩＮＫを用い、転載先のキーワードを指定して、ソフトウェア００５のクラブＢへの転載を要求すると（ステップＳ１５１）、ホスト計算機６３は権限チェックを行う（ステップＳ２５１）。このとき、商品データベース８１を参照し、ソフトウェア００５のステ
ータスがＰＥＲＭＩＴＩＯＮ済みで、かつ、要求者のログインＩＤが管理者のＩＤと一致した時にのみ転載要求を受け付け、それ以外の場合は拒否する。転載要求を受け付けると、商品データベース８１内のソフトウェア００５の管理情報に転載先のキーワードを追加し、ステータスを転載済み（ＬＩＮＫ済み）に変更する（ステップＳ２５２）。
【０１５５】
図２６は、公開されたソフトウェアの移管の例を示している。図２６において、オリジナルクラブの管理者がコマンドＭＯＶＥを用いて、ソフトウェア００５のクラブＢへの移管を要求すると（ステップＳ１６１）、ホスト計算機６３は権限チェックを行う（ステップＳ２６１）。このとき、商品データベース８１を参照し、ソフトウェア００５のステータスがＰＵＢＬＩＳＨ済みで、かつ、要求者のログインＩＤが管理者のＩＤと一致した時にのみ移管要求を受け付け、それ以外の場合は拒否する。移管要求を受け付けると、商品データベース８１内のソフトウェア００５のオリジナルクラブＩＤを移管先クラブＢのＩＤに書き換える（ステップＳ２６２）。このとき、移管先クラブが既に転載先クラブとして登録されている場合は、その転載先クラブＩＤを消去する。そして、ステータスを移管済み（ＭＯＶＥ済み）に変更する。
【０１５６】
図２７および図２８は、クラブの移動の例を示している。図２７において、ユーザが端末からキーワードの一覧を要求すると（ステップＳ１７１）、ホスト計算機６３はこれに無条件に応答し、キーワードリストを送り返す（ステップＳ２７１）。次に、ユーザがＴＦＬＧ＝０として、キーワード「日本語」による検索要求を送ると、ホスト計算機６３は図２１のステップＳ２１２と同様の権限チェックを行う（ステップＳ２７２）。ここでは、ＴＦＬＧ＝０なので通常通り課金され、ＰＵＢＬＩＳＨ済みのソフトウェアから検索される。
【０１５７】
次に、ユーザは、検索された統合ＯＡ−Ａ１をサポートしているクラブの検索を要求し（ステップＳ１７３）、ホスト計算機６３は、ステップＳ２７２と同様の権限チェックを行う（ステップＳ２７３）。そして、商品データベース８１を参照し、図２８に示すように、オリジナルクラブ、転載先クラブの順に、サポートクラブのクラブＩＤとメニューＩＤ（ルートＩＤ）を返送する。クラブＩＤとルートＩＤの対応関係は、あらかじめホスト計算機６３に記憶されているものとする。端末はこれらの情報を受け取ると、表示画面１０２に示すように、オリジナルクラブ、転載先クラブの順にサポートクラブのクラブ名を表示する。ここでは、統合ＯＡ−Ａ１のオリジナルクラブであるワープロクラブが、転載先の表計算クラブよりも上に表示されている。
【０１５８】
次に、ユーザが表示されたクラブの中から１つを選択すると、そのルートＩＤに従ってメニュー情報が返送される。ここでは、ワープロクラブが選択されて、表示画面１０３に示すようなメニューが表示される。このように、商品データベース８１にサポートクラブのＩＤがすべて格納されているので、ユーザはその情報を用いて、オリジナルクラブや転載先クラブに直ちに移動することができる。
【０１５９】
【発明の効果】
本発明によれば、ソフトウェアをユーザの端末から自動的にシステムに登録することができる。
【０１６０】
作者はアップロードのコマンドを用いて、ソフトウェアを任意のクラブに自由にアップロードすることができる。このとき、アップロードのフォーマットが標準化されており、アップロード情報の自動チェックが行われるので、登録に伴う管理者の負担が軽減される。
【０１６１】
また、ウィルスチェックや管理者によるチェック等に合格しないものは公開されないので、安全なソフトウェアの流通が実現できる。
また、最上位のクラブからはすべての登録ソフトが閲覧可能であり、クラブ毎に検索キーワードが付け変えられるので、リモートインストールを行う時に目的のソフトウェアを探す手間が省ける。
【０１６２】
また、ソフトウェアの重複チェックを行うので、同じソフトウェアが記憶領域の複数箇所に存在することがなく、ディスク資源が有効に利用される。
このように、アップロードされたソフトウェアをフレキシブルに管理することが可能になる。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】実施形態のシステム構成図である。
【図３】場の構成を示す図である。
【図４】ホスト計算機上のクラブを示す図である。
【図５】商品データベースを示す図である。
【図６】コマンドの使用権限を示す図である。
【図７】作者の作業のフローチャートである。
【図８】オリジナルクラブの管理者の作業のフローチャートである。
【図９】転載先クラブ管理者の作業のフローチャートである。
【図１０】端末上で作成されるファイル群を示す図である。
【図１１】ＣＦＧファイルを示す図（その１）である。
【図１２】ＣＦＧファイルを示す図（その２）である。
【図１３】ＣＦＧファイルを示す図（その３）である。
【図１４】ＣＦＧファイルを示す図（その４）である。
【図１５】説明ファイルを示す図である。
【図１６】本体ファイルを示す図である。
【図１７】ＣＨＫファイルを示す図である。
【図１８】ＩＣＯＮファイルを示す図である。
【図１９】アップロードの例を示す図（その１）である。
【図２０】アップロードの例を示す図（その２）である。
【図２１】テスト宅配の例を示す図である。
【図２２】公開依頼の例を示す図である。
【図２３】公開の例を示す図である。
【図２４】転載許可の例を示す図である。
【図２５】転載の例を示す図である。
【図２６】移管の例を示す図である。
【図２７】クラブの移動の例を示す図（その１）である。
【図２８】クラブの移動の例を示す図（その２）である。
【図２９】先願のリモートインストールシステムの構成図である。
【図３０】リモートインストールのフローチャート（その１）である。
【図３１】リモートインストールのフローチャート（その２）である。
【図３２】リモートインストールのフローチャート（その３）である。
【図３３】インストール方法選択ウィンドウの例を示す図である。
【図３４】リモートインストールプロトコルを示す図（その１）である。
【図３５】リモートインストールプロトコルを示す図（その２）である。
【図３６】キーワード選択のプロトコルを示す図である。
【図３７】キーワードの表示例を示す図である。
【図３８】環境情報の送信プロトコルを示す図である。
【図３９】環境チェックのプロトコルを示す図である。
【図４０】自動インストールのフローチャートである。
【図４１】設定ファイルの例を示す図である。
【符号の説明】
２１、６３  ホスト計算機
２２  通信回線
２３、６１−１、６１−Ｎ、６１−ｉ  端末
２４  表示装置
２５  ハードディスク
３１、３８、３９  環境ファイル
３２  第１キーテーブル
３３  第２キーテーブル
３４、４４  設定ファイル
３５  ソフトウェア群
３６  倉庫ウィンドウ
３７  アイコン
４０  チェックスクリプト
４１  ファイル本体
４２、４３  インストールスクリプト
５１  管理手段
５２  記憶手段
５３  インストール手段
６２  ネットワーク
７１  上位クラブ
７２、７３、７４  クラブ
７５  ソフトウェア
８１  商品データベース
９１  メモリ
９２  ＣＦＧファイル
９３  説明ファイル
９４  本体ファイル
９５  ＣＨＫファイル
９６  インストール関連ファイル
１０１  ファイル群
１０２、１０３  表示画面
【図１】
0003751664.tif 000002
【図２】
0003751664.tif 000003
【図３】
0003751664.tif 000004
【図４】
0003751664.tif 000005
【図５】
0003751664.tif 000006
【図６】
0003751664.tif 000007
【図７】
0003751664.tif 000008
【図８】
0003751664.tif 000009
【図９】
0003751664.tif 000010
【図１０】
0003751664.tif 000011
【図１１】
0003751664.tif 000012
【図１２】
0003751664.tif 000013
【図１３】
0003751664.tif 000014
【図１４】
0003751664.tif 000015
【図１５】
0003751664.tif 000016
【図１６】
0003751664.tif 000017
【図１７】
0003751664.tif 000018
【図１８】
0003751664.tif 000019
【図１９】
0003751664.tif 000020
【図２０】
0003751664.tif 000021
【図２１】
0003751664.tif 000022
【図２２】
0003751664.tif 000023
【図２３】
0003751664.tif 000024
【図２４】
0003751664.tif 000025
【図２５】
0003751664.tif 000026
【図２６】
0003751664.tif 000027
【図２７】
0003751664.tif 000028
【図２８】
0003751664.tif 000029
【図２９】
0003751664.tif 000030
【図３０】
0003751664.tif 000031
【図３１】
0003751664.tif 000032
【図３２】
0003751664.tif 000033
【図３３】
0003751664.tif 000034
【図３４】
0003751664.tif 000035
【図３５】
0003751664.tif 000036
【図３６】
0003751664.tif 000037
【図３７】
0003751664.tif 000038
【図３８】
0003751664.tif 000039
【図３９】
0003751664.tif 000040
【図４０】
0003751664.tif 000041
【図４１】
0003751664.tif 000042