JP2005310173A - リモートインストールシステムおよび方法 - Google Patents

Abstract

【課題】 ユーザが煩雑な作業を行うことなく通信回線を介してソフトウェアを入手し、自動的にインストールすることを可能とする。
【解決手段】 ホスト計算機２１は第１キーテーブル３２、第２キーテーブル３３を端末２３に送信し、表示装置２４はそれらに含まれるキーワードを表示する。ユーザは画面上で希望するソフトウェアに対応するキーワードを選び、ホスト計算機２１はそれに対応するソフトウェアのリストを端末２３に送る。ユーザはその中から希望するソフトウェアを選んで、ホスト計算機２１に通知する。ホスト計算機２１はソフトウェア群３５からユーザの選んだソフトウェアを取り出し、環境ファイル３１を用いて動作環境をチェックした後、通信回線２２を介して端末２３のハードディスク２５に格納する。配送されたソフトウェアは自動的にシステムに登録され、倉庫ウィンドウ３６内に起動用のアインコン３７が表示される。
【選択図】図２

Description

本発明は、通信回線を介してソフトウェアをユーザの端末装置に自動的にインストールするためのリモートインストールシステムとその方法に関する。

近年のパソコン通信等の発達に伴い、通信回線を介してソフトウェアを入手したいというユーザの希望が生じているが、このようなソフトウェアの配送を自動的に行う本格的なシステムは実現していない。ソフトウェアの自動配送を行うには、まずユーザが希望するソフトウェアを自宅の端末装置から配送センターに知らせ、ユーザから通知を受けた配送センターは通信回線を介して要求されたソフトウェアをユーザの端末装置に送信するという形式が考えられる。そして、ソフトウェアを受け取ったユーザは、自宅の端末装置上でディレクトリを指定してこれを格納し、必要に応じて対応するアイコンを設定する。

しかしながら上述のようなソフトウェアの配送を実現するには、次のような問題がある。
ユーザの端末装置において、ソフトウェアの配送を受ける窓口となるディレクトリが統一されていないと、後でユーザ自身がファイルをあるディレクトリから他のディレクトリに移動させたりして整理し直す必要があり、配送されたソフトウェアの保守性が悪くなる。また、ユーザにとってはサブディレクトリ等を指定する作業がわずらわしいという問題がある。

また、ユーザが自宅の端末装置上で、膨大な数のソフトウェアの中から希望するものを選択する方法が確立されておらず、的確にこれを選びだせるシステムが必要である。
また、ソフトウェアの動作環境として課される条件は一般に複数あり、ユーザにとってはこれらを１つ１つチェックする作業が煩雑に感じられる。さらに、動作環境のチェックを誤ると、せっかく入手したソフトウェアが自宅の環境では動作しない場合もあり得る。

また、配送されたソフトウェアのインストールの方法も一般には複数の方法が考えられ、ユーザの希望を考慮する必要がある。
さらに、ソフトウェアの配送およびインストールを通信回線を利用して行うので、通信回線の利用効率を低下させないことが望まれる。

本発明は、ユーザが煩雑な作業を行うことなく通信回線を介してソフトウェアを入手し、ユーザの端末装置に自動的にインストールすることが可能なリモートインストールシステムとその方法を提供することを目的とする。

本発明は、配送センターとユーザの端末装置とを通信回線で結び、該配送センターからソフトウェアを該端末装置に配送するリモートインストールシステムおよびその方法である。

図１は本発明のリモートインストールシステムの原理図である。
図１のリモートインストールシステムは、インストール手段１、サブディレクトリ指定手段２、キーワード格納手段３、環境チェック手段４、自動インストール手段１１、コンテンツ格納手段１２、アイコン表示手段１３、インストールメニュー表示手段１４、選択手段１５、キーワード表示手段１６、および環境情報通知手段１７を備える。

コンテンツ格納手段１２は、ユーザの端末装置内にあって、ソフトウェアの配送先となる専用の格納領域を持つ。
サブディレクトリ指定手段２は、配送すべき対象ソフトウェアが決まった後に、上記専用の格納領域内のサブディレクトリを対象ソフトウェアに対応して自動的に指定する。

インストール手段１は、上記専用の格納領域に自動的に生成された上記サブディレクトリに対象ソフトウェアを配送する。
アイコン表示手段１３は、上記専用の格納領域に対応する専用のウィンドウ内に、対象ソフトウェアに対応するアイコンを表示する。

キーワード格納手段３は、複数のキーワードを複数のソフトウェアと関係付けて保持する。
キーワード表示手段１６は、キーワード格納手段が保持する複数のキーワードを、重複を許して２つ以上の階層で表示する。

選択手段１５は、キーワード表示手段１６が表示した複数のキーワードから、対象ソフトウェアに対応する１つ以上のキーワードをユーザに選択させ、それらの１つ以上のキーワードをインストール手段１に通知する。インストール手段１は、上記１つ以上のキーワードを用いて、複数のソフトウェアから対象ソフトウェアを検索する。

環境情報通知手段１７は、上記端末装置におけるソフトウェアの動作環境に関する環境情報を取得して、上記配送センターに通知する。
環境チェック手段４は、環境情報通知手段１７から受け取った上記環境情報を対象ソフトウェアの動作環境と比較して、動作環境の適合性をチェックし、チェック結果をインストール手段１に通知する。インストール手段１は、上記チェック結果に応じて対象ソフトウェアを配送するかどうかまたは配送方法を決める。

インストールメニュー表示手段１４は、対象ソフトウェアの複数のインストール方法を表示する。
選択手段１５は、インストールメニュー表示手段１４が表示した複数のインストール方法から特定のインストール方法をユーザに選択させ、その特定のインストール方法をインストール手段１に通知する。インストール手段１は、上記特定のインストール方法により対象ソフトウェアをコンテンツ格納手段１２にインストールする。

自動インストール手段１１は、インストール手段１から受け取る設定ファイルに記述されたインストール手順に従って、対象ソフトウェアをコンテンツ格納手段１２に自動的にインストールする。インストール手段１は、上記設定ファイルをユーザ毎に個別に用意し、必要に応じてその設定ファイルの内容を書き換えて自動インストール手段１１に送る。

図１のインストール手段１、サブディレクトリ指定手段２、キーワード格納手段３、および環境チェック手段４は、図２の実施例の構成図におけるホスト計算機２１に相当する。また、図１の自動インストール手段１１、コンテンツ格納手段１２、アイコン表示手段１３、インストールメニュー表示手段１４、選択手段１５、キーワード表示手段１６、および環境情報通知手段１７は、端末ソフトを搭載した図２の端末２３に相当する。特に、コンテンツ格納手段１２はハードディスク２５に相当し、アイコン表示手段１３、インストールメニュー表示手段１４、およびキーワード表示手段１６は表示装置２４に相当する。

また、上記専用の格納領域は例えばハードディスク２５内の倉庫ディレクトリに対応し、上記専用のウィンドウは表示装置２４の画面に表示される倉庫ウィンドウ３６に対応する。

本発明のホスト計算機は、通信回線で結ばれたユーザの端末装置に対象ソフトウェアを送信するホスト計算機であって、端末装置の格納領域に関する情報および送信すべき対象ソフトウェアに関する情報に応じて対象ソフトウェアの動作環境をチェックするためのチェックスクリプトから、端末装置内でオペレーティングシステムが格納されている格納場所に対象ソフトウェアの動作に必要なファイルがあるかどうかを調査するコマンドを取り出す手段と、取り出したコマンドを端末装置に送信する手段と、オペレーティングシステムが格納されている格納場所に必要なファイルがなければそのファイルをダウンロードしてよいかをユーザに問い合わせた後に、端末装置の格納領域に関する情報および送信すべき対象ソフトウェアに関する情報に応じて、端末装置に対象ソフトウェアを格納するサブディレクトリをその端末装置の配送専用の格納領域内に生成させるためのサブディレクトリ指定情報を生成する手段と、生成したサブディレクトリ指定情報、対象ソフトウェア、および必要なファイルを端末装置に送信する手段とを備える。

対象ソフトウェアの配送時に、サブディレクトリ指定手段２がコンテンツ格納手段１２の有する専用の格納領域内のサブディレクトリを自動的に指定する。そして、上記サブディレクトリが上記専用の格納領域内に自動的に生成され、そこにインストール手段１が対象ソフトウェアを配送する。ソフトウェアの配送専用の格納領域が設けられるのでその後の保守性が良く、またサブディレクトリが自動的に指定・生成されるので、ユーザの作業が軽減される。

また、アイコン表示手段１３が上記専用の格納領域に対応する専用のウィンドウを表示し、対象ソフトウェアに対応するアイコンを自動的に表示する。これにより、ユーザは対象ソフトウェアが配送されたことを認識し、表示されたアイコンを用いて直ちに対象ソフトウェアを起動することができる。

また、キーワード表示手段１６は、キーワード格納手段が保持する複数のキーワードを、重複を許して２つ以上の階層で表示し、ユーザは選択手段１５を用いてそれらの複数のキーワードのうちのいくつかを選択する。選択されたキーワードはインストール手段１に通知され、対応する対象ソフトウェアが検索される。
キーワードの表示階層間で同一のキーワードが重複して表示されるため、ユーザにとって柔軟かつ効果的な選択が可能になる。

また、環境チェック手段４は、環境情報通知手段１７から受け取った上記端末装置におけるソフトウェアの動作環境と対象ソフトウェアの動作環境とを比較して、それらが適合するかどうかを調べる。例えば、それらが適合すればインストール手段１が対象ソフトウェアを配送し、適合しなければ配送するかどうかをユーザに問い合わせる。対象ソフトウェアの配送前にその動作環境のチェックが自動的に行われるので、ユーザのチェック作業が軽減される。

また、インストールメニュー表示手段１４が対象ソフトウェアの複数のインストール方法をメニュー形式で表示し、ユーザは希望する特定のインストール方法を選択することができる。インストール手段１は、選択されたインストール方法により対象ソフトウェアをコンテンツ格納手段１２の上記専用の格納領域にインストールする。これにより、ユーザはあらかじめ用意されたインストール方法内のバリエーションを試してみることが可能になる。

また、自動インストール手段１１は、インストール手段１がユーザ毎に用意した設定ファイルに記述されたインストール手順に従って、対象ソフトウェアをコンテンツ格納手段１２に自動的にインストールする。設定ファイルを受け取った後は上記配送センターと通信する必要がなく、通信回線の利用効率が良くなる。また、上記サブディレクトリの名称や環境情報を用いて設定ファイルの内容を書き換えることもできる。

本発明によれば、配送センターから通信回線を介して、ユーザの希望するソフトウェアをその端末装置に自動的にインストールすることが可能になる。これを利用して、通信回線を介してソフトウェアをユーザに販売することも可能になる。

このとき、配送されたソフトウェアは専用のディレクトリに格納されるので保守性が良く、またユーザは配送先のディレクトリ等を指定する文字列を入力する必要がない。
ユーザは端末装置の画面上で希望するソフトウェアを効率よく選びだすことができ、そのインストールの方法も選択することができる。また、ユーザがソフトウェアの動作環境をチェックする必要がなく、自動的に環境チェックが行われる。

さらに、ソフトウェアのインストール時に通信回線の使用をできるだけ少なくすることができる。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図２は、本発明の実施例のリモートインストールシステムの構成図である。図２のリモートインストールシステムは、ソフトウェアの配送センターにあるホスト計算機２１、ユーザの端末２３、およびこれらを結ぶ通信回線２２から成る。端末２３は、例えば配送センターから遠く離れたユーザの自宅にあるパーソナルコンピュータであり、通信回線２２は例えばパソコン通信のネットワーク用の回線であるものとする。

ホスト計算機２１は、図示されない格納領域内に配送可能な複数のソフトウェアを含むソフトウェア群３５と、そのソフトウェア群３５から特定のソフトウェアを選択するときに用いるキーワードのリストを保持する第１キーテーブル３２および第２キーテーブル３３を格納している。

ユーザが端末２３からホスト計算機２１にキーワードのリストを要求すると、ホスト計算機２１は第１キーテーブル３２、第２キーテーブル３３を順次送信して、それらに含まれるキーワードを端末２３の表示装置２４の画面に表示させる。ユーザは表示されたキーワードから希望するソフトウェアに対応するものを選び、ホスト計算機２１に通知する。

ホスト計算機２１は通知されたキーワードに該当するいくつかのソフトウェアの名称を含むメニューを表示装置２４の画面に表示させ、ユーザはその中から希望するソフトウェアを選んで、ホスト計算機２１に通知する。そして、ホスト計算機２１はソフトウェア群３５からユーザの選んだソフトウェアのコンテンツ（ファイル）を取り出し、端末２３のハードディスク２５に設定された配送（宅配、またはディストリビューション）用のディレクトリＤ：￥ＳＯＵＫＯに格納する。

このとき、宅配されたソフトウェアを起動するためのアイコン３７が自動的に登録され、表示装置２４の画面上でディレクトリＤ：￥ＳＯＵＫＯに対応して設けられた倉庫ウィンドウ３６内に表示される。例えば端末２３がＷＩＮＤＯＷＳを搭載している場合は、宅配されたソフトウェアはＷＩＮＤＯＷＳのプログラムマネージャに登録される。以後、ユーザはアイコン３７をマウス等の入力装置を用いてクリックするだけで、宅配されたソフトウェアを使用することができる。

端末２３が装備するハードウェアやソフトウェアツール等の動作環境を記述した環境ファイル３１は端末２３内で生成され、ホスト計算機２１のアクセス時にホスト計算機２１に送られる。ホスト計算機２１は受け取った環境ファイル３１を各ユーザ毎に保持し、ユーザが選んだソフトウェアが動作可能かどうかのチェックに用いる。

また、ホスト計算機２１はユーザ毎に個別の設定ファイル３４を用意し、ユーザが選んだソフトウェアの動作に必要なファイル一式とその格納場所をこれに記述する。そして、それらのファイル一式とともに設定ファイル３４を端末２３に一括して送り、端末２３にソフトウェアの自動インストールを行わせることができる。

次に、図３から図５までを参照しながら、図２のリモートインストールシステムによるソフトウェアの宅配の動作フローを説明する。
図３において、ユーザＡの端末２３は通信用の端末ソフトのインストール時に動作環境の情報を取得し、取得した情報を設定した環境ファイル３８を作成する（ステップＳ１）。このとき、ユーザの端末の機種や宅配に使用する格納場所ＳＯＵＫＯ等の取得に時間のかかる情報、あるいは、場合によってユーザに問い合わせなければならない情報を取得する。

格納場所ＳＯＵＫＯの決定にあたっては、端末２３はハードディスク２５に所定の容量以上の空き領域があるかどうかを調べ、空き領域があればそのルートに宅配用のディレクトリを作成する。このときディレクトリ名等は端末２３が自動的に生成し、ユーザＡはそれを確認する作業のみを行う。したがって、ユーザＡはディレクトリ名等を入力する必要がない。

ここでは、ユーザＡの機種はＴＯＷＮＳであり、ＳＯＵＫＯのディレクトリはＤ：￥ＳＯＵＫＯ（ドライブＤのディレクトリＳＯＵＫＯ）であることが環境ファイル３８に書き込まれる。ユーザＡは、必要があればＤ：￥ＳＯＵＫＯを他のディレクトリに変更することもできる。

既に設定されているパーティションに所定の容量の空き領域がなければ、別のパーティションの空き領域が一番大きい場所を探して、そこに宅配用のディレクトリを作成する。具体的には、ディレクトリＤ：￥ＳＯＵＫＯが一杯になったとすると、端末２３が”Ｄ：￥ＳＯＵＫＯが一杯です。倉庫をＦ：￥ＳＯＵＫＯに変更します。よろしいですか。”等のメッセージを表示装置２４の画面に表示する。ユーザＡがこれを承認すると、Ｆ：￥ＳＯＵＫＯが新たにＳＯＵＫＯのディレクトリとなる。所定の容量の空き領域がどのハードディスクにもなかったときは、”残念ながらディスク容量が足りません。ディスクを増設してください。”等のメッセージが表示される。

次に、端末ソフトの起動時（ホスト計算機２１へのアクセス時）に、ハードディスクやメモリの状況等のインストール後に変化した可能性のある情報を取得する（ステップＳ２）。ここでは、ユーザＡのハードディスクがドライブＤにあり、空き容量が３００Ｍバイトであることが環境ファイル３８に書き込まれる。こうして作成された環境ファイル３８の内容は、ユーザＡがホスト計算機２１にアクセス（接続）したときに、コマンドＲＩＳ ＳＥＮＤＥＮＶによりホスト計算機２１に送信される（ステップＳ３）。

ホスト計算機２１は受信した情報をユーザＡ環境ファイル３９として保持する。ユーザＡ環境ファイル３９には、機種、ハードディスク情報ＨＤ、格納場所ＳＯＵＫＯのほかに、使用しているＯＳ（オペレーティングシステム）とその格納場所が記述されている。ここでは、ユーザＡの端末２３のＯＳはＷＩＮＤＯＷＳであり、その格納場所ＷＩＮＤＩＲはＤ：￥ＷＩＮＤＯＷＳであることがわかる。

ホスト計算機２１からコマンドＲＩＳ ＳＥＮＤＥＮＶに対するレスポンスとしてＲＩＳ ＳＥＮＤＥＮＶ＊ＲＥＳＰ ＯＫを受け取ると、端末２３はコマンドＲＩＳ ＫＥＹＬＩＳＴにより第１キーリストを要求する（ステップＳ４）。これに応じて、ホスト計算機２１は第１キーテーブル３２の内容をＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第１キーテーブル３２には、キー番号１、２、３、・・・に対応するキーワードとして、ＯＳ／基本ソフト、開発支援、ゲーム、・・・が格納されている。

これらのキーワードが第１キーリストとして表示装置２４の画面に表示されると（ステップＳ５）、ユーザＡはそれらの中から第１キーワードを選び端末２３に入力する（ステップＳ６）。すると、端末２３はユーザＡの選んだ第１キーワードのキー番号とともに、第２キーリストを要求するコマンドＲＩＳ ＫＥＹＬＩＳＴをホスト計算機２１に送る（ステップＳ７）。ここでは、ユーザＡは第１キーワードとしてゲームを選択し、それに対応するキー番号３がホスト計算機２１に送られる。

第２キーリストを要求されたホスト計算機２１は、受け取ったキー番号に対応して第１キーテーブル３２内に格納されているポインタを用いて、対応する第２キーテーブル３３を求め、その内容をＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第２キーテーブル３３には、キー番号５１、５２、５３、・・・に対応するキーワードとして、ＲＰＧ、アクション、パズル／クイズ、・・・が格納されている。

第２キーテーブルは第１キーテーブル３２内のキーワードに対応して一般に複数設けられており、その数は第１キーテーブル３２内のキーワードの数と同じか、またはそれより少ない。後者の場合には、第１キーテーブル３２内の２つ以上のキーワードが同じ１つの第２キーテーブルを指すことになる。

第２キーテーブル内のキーワードが第２キーリストとして表示装置２４の画面に表示されると（ステップＳ８）、ユーザＡはそれらの中から第２キーワードを選び端末２３に入力する（図４、ステップＳ９）。すると、端末２３はユーザＡの選んだ第１および第２キーワードのキー番号とともに、第１および第２キーワードの両方に該当するソフトウェアのリストを要求するコマンドＲＩＳ ＬＩＳＴをホスト計算機２１に送る（ステップＳ１０）。ここでは、ユーザＡは第２キーワードとしてアクションを選択し、それに対応するキー番号５２がホスト計算機２１に送られる。

ソフトウェアのリストを要求されたホスト計算機２１は、第１および第２キーワードの２つのキー番号を持つソフトウェアをソフトウェア群３５の中から検索する。このとき、検索条件として第１キーワードと第２キーワードとを区別せずに、フラットに検索を行う。また、機種やＯＳの種別はデフォルトのキーとして扱い、これらも加味した上で検索する。これにより、例えばＴＯＷＮＳ以外の機種専用のソフトウェアが検索されてくることが防止される。

そして、該当するソフトウェアの名称と番号のリストをＲＩＳ ＬＩＳＴ＊ＲＥＳＰとともに端末２３に送る。ここでは、キー番号３と５２を持つテトリス、パチンコ等のソフトウェアが該当するので、それらの名称がそれぞれのソフトウェア番号５、３０等とともに端末２３に送られる。

ソフトウェアのリストが表示装置２４の画面に表示されると（ステップＳ１１）、ユーザＡはそれらの中から希望するソフトウェアを選び、端末２３に入力する（ステップＳ１２）。すると、端末２３はユーザＡの選んだソフトウェアの番号とともに、ユーザＡの環境がそのソフトウェアの動作に適するかどうかのチェックを要求するコマンドＲＩＳ ＣＨＫＥＮＶをホスト計算機２１に送る（ステップＳ１３）。ここでは、ユーザＡはテトリスを選択し、それに対応するソフトウェア番号５がホスト計算機２１に送られる。

ユーザＡが選択したソフトウェアの番号を受け取ったホスト計算機２１は、その番号に対応するソフトウェアの動作環境とユーザＡの端末２３の環境との整合性を調べるためのチェックスクリプト４０を用意し、環境チェックを行う。このチェックはチェックスクリプト４０の実行プログラムと端末２３の端末ソフトとの間のやりとりにより自動的に行われるので、ユーザＡは環境チェックが行われていることを必ずしも意識する必要はない（ステップＳ１４）。ユーザＡに何らかの問い合わせを行う必要が生じたときにのみ、ホスト計算機２１がその問い合わせを行う。

ここでは、ユーザＡが選択したテトリスの動作環境として、ＯＳがＷＩＮＤＯＷＳ、機種がＴＯＷＮＳ、ＰＣ９８等、推奨ディレクトリ（ＤＩＲ）名がＴＥＴであることが記述されている。これに対して、ユーザＡ環境ファイル３９には、機種がＴＯＷＮＳ、ＯＳがＷＩＮＤＯＷＳと記述されており、両者を比較することによって機種とＯＳが適合していることがわかる。

次に、テトリスのチェックスクリプト４０を見るとユーザＡ側の格納場所ＷＩＮＤＩＲにＶＢＲＪＰ２００．ＤＬＬというファイルがあるかどうか調査するためのコマンド”ＳＴ４ ＠ＷＩＮＤＩＲ＠ＶＢＲＪＰ２００．ＤＬＬ”があるので（ＭＱ１）、ホスト計算機２１はこれをＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。このとき、ホスト計算機２１はユーザＡ環境ファイル３９を参照して、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて送る。ここで、＠はワイルドカードを表す。また、ファイルＶＢＲＪＰ２００．ＤＬＬはテトリスの動作に必要なファイルの１つである。

このコマンドを受け取った端末２３は、ドライブＤのディレクトリＷＩＮＤＯＷＳにファイルＶＢＲＪＰ２００．ＤＬＬがあるかどうか調べ、その結果をＡＮＳとしてホスト計算機２１に送り返す。ここでは、該当するファイルがなかったのでＡＮＳ＝ＯＦＦが送り返される。

端末２３にファイルＶＢＲＪＰ２００．ＤＬＬがないことを知ったホスト計算機２１は、チェックスクリプト４０に従って（ＭＱ２）、”ＶＢＲＪＰ２００をコピーしてよいか？”という問い合わせを端末２３に送り、この問い合わせが表示装置２４の画面に表示される。ユーザＡは表示された問い合わせに対する回答を入力し、端末２３がその回答をホスト計算機２１に送り返す。ここでは、ＡＮＳ＝はい が送り返され、ホスト計算機２１はチェックスクリプト４０に従って、リモートインストールを承諾し（ＲＩＳ＝ＯＫ）、ＶＢＲＪＰ２００．ＤＬＬのコピーを指示するフラグＦ２をＯＮにする（ＭＡ２）。

もし、ファイルＶＢＲＪＰ２００．ＤＬＬが端末２３の指定されたディレクトリにあった場合はＡＮＳ＝ＯＮが送り返されるので、その時点でＲＩＳ＝ＯＫとなる（ＭＡ１）。
このように環境チェックを自動的に行うことにより、ユーザＡの環境に適合しないソフトウェアが配送されるのを防ぐことができる。例えば、あるパッケージソフトウェアを通信回線２２を介して購入した後に、特定のドライバがないとそれが動作しないことを知るといったような事故が未然に防止される。

ＲＩＳ＝ＯＫとなるとホスト計算機２１は環境チェックを終了し、判定結果（ＪＵＤＧＥ＝ＯＫ）とともに、配送先のディレクトリＳＯＵＫＯＤＩＲを端末２３に送る。このＳＯＵＫＯＤＩＲは、ユーザＡ環境ファイルに格納されているＳＯＵＫＯのディレクトリであるＤ：￥ＳＯＵＫＯの下にテトリスの推奨ディレクトリであるＴＥＴをサブディレクトリとして付加した形式で指定される。

このとき同時に、インストールの可否（ＲＩＳ）、インストールプログラム（インストーラ）のアイコン登録の有無（ＩＣＯＮ）、およびダウンロードの可否（ＤＬＯＡＤ）が端末２３に送られる。これらのフラグＲＩＳ、ＩＣＯＮ、ＤＬＯＡＤにより、ホスト計算機２１はインストール、インストーラのアイコン登録、ダウンロードのうちのどれが可能かを端末２３に通知する。

インストールとはユーザＡの選んだソフトウェアを端末２３のシステム、例えばＷＩＮＤＯＷＳに登録して、端末２３上で使用可能にすることを意味する。したがって、この場合はそのソフトウェアの実行ファイルをＷＩＮＤＯＷＳ上でアイコン登録する作業までを含む。これに対して、インストーラのアイコン登録とはインストールを実行するプログラムを端末２３上でアイコン登録することを意味する。

ここでは、インストールとダウンロードが許諾され（ＲＩＳ＝ＯＫ、ＤＬＯＡＤ＝ＯＫ）、インストーラのアイコン登録は行わない（ＩＣＯＮ＝ＮＧ）という条件が提示される。複雑なインストールプログラムを持つソフトウェアの場合には、インストールが許諾される代わりにインストーラのアイコン登録が必要である旨が提示される。また、ＷＩＮＤＯＷＳを搭載している端末からＴＯＳ（ＴＯＷＮＳのＯＳ）用のアプリケーションを要求されたような場合には、ダウンロードのみが許諾される。

次に、端末２３の端末ソフトはインストール、インストーラのアイコン登録、ダウンロードの順に優先順位をつけて、より優先順位の高いものをデフォルトとして設定し、表示装置２４の画面に表示する。ここでは、ホスト計算機２１により許諾されたインストールとダウンロードのうち優先順位のより高いインストールがデフォルトとして設定され、インストール方法選択ウィンドウに表示される。

図６は、インストール方法選択ウィンドウの表示例を示している。図６において、「システム登録」がインストールに相当し、これがデフォルトで選択されている。
ユーザＡは表示されたインストール方法を確認して、確認した旨を入力する（ステップＳ１５）。また、ユーザＡはここで表示された設定を変更することもできる。例えば、インストーラのアイコン登録を行いたいときは、図６のインストール方法選択ウィンドウ内の「インストーラのアイコン登録」を選択して入力する。

基本的には、ユーザＡは手間をかけずにできあいのインストールを行いたい場合は「システム登録」を選択し、細かいインストール設定を自分で行いたい場合は「インストーラのアイコン登録」を選択し、格納場所を後で変更したい（別の機種の端末にインストールしたい）場合は「ダウンロード」を選択する。「ダウンロード」を選択すれば、端末２３の機種とは異なる機種用のソフトウェアを入手して動作するかどうか試してみることも可能になる。

次に、端末２３はホスト計算機２１から指示された宅配用のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴを、ハードディスク２５内に自動的に生成する（ステップＳ１６）。ここでもし、端末２３にサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴが既に存在している場合は、例えばＤ：￥ＳＯＵＫＯ￥ＴＥＴ ００１というサブディレクトリをつくり、これも既に存在している場合はＤ：￥ＳＯＵＫＯ￥ＴＥＴ ００２というサブディレクトリをつくる。

テトリスのファイル本体４１はファイルＴＥＴ１．ＬＺＨ（Ｆ１）とＶＢＲＪＰ２００．ＤＬＬ（Ｆ２）とから成り、ＴＥＴ１．ＬＺＨは４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣを圧縮してできている。ＴＥＴ１．ＬＺＨを圧縮前の状態に伸長（解凍）するとこれらの４つのファイルに分かれるが、ＴＥＴ１．ＬＺＨの解凍はホスト計算機２１から端末２３に配送された後に行われる。

宅配用のサブディレクトリを生成した端末２３は、リモートインストールの開始を依頼するコマンドＲＩＳ ＩＮＳＴＡＬＬを選択したソフトウェアの番号とともにホスト計算機２１に送る（図５、ステップＳ１７）。これを受けて、ホスト計算機２１は送られた番号に対応するソフトウェアのリモートインストールを開始する。リモートインストールは、ホスト計算機２１が作成したテトリスのインストールスクリプト４２に従って、ホスト計算機２１と端末２３の間のやりとりにより自動的に行われる（ステップＳ１８）。

インストールスクリプト４２には、まずファイルＴＥＴ１．ＬＺＨをユーザＡ側の格納場所＠ＳＯＵＫＯ＠にダウンロードすることを指示する記述がある。そこで、ホスト計算機２１は＠ＳＯＵＫＯ＠をＳＯＵＫＯＤＩＲ＝Ｄ：￥ＳＯＵＫＯ￥ＴＥＴに置き換えて、ハードディスク２５のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴにＴＥＴ１．ＬＺＨをダウンロードする。

端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて、ハードディスク２５のディレクトリＤ：￥ＷＩＮＤＯＷＳにＶＢＲＪＰ２００．ＤＬＬをダウンロードする。

端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）にダウンロードしたＴＥＴ１．ＬＺＨを解凍する指示、ＬＨＡ Ｘ Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＥＴ１．ＬＺＨを送る。これを受けて、端末２３はＴＥＴ１．ＬＺＨを前述した４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣに解凍する。これらの４つのファイルはＴＥＴ１．ＬＺＨと同じサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴに保持される。

端末２３から解凍の完了（ＯＫ）を通知されると、次にホスト計算機２１は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）の機種＠．ＤＲＶというファイルを格納場所＠ＷＩＮＤＩＲ＠（Ｄ：￥ＷＩＮＤＯＷＳ）に移動させてファイル名をＦＯＮＴ．ＤＲＶに変更する指示、ＭＯＶＥ Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＯＷＮＳ．ＤＲＶ Ｄ：￥ＷＩＮＤＯＷＳ￥ＦＯＮＴ．ＤＲＶを送る。このとき、ホスト計算機２１はユーザＡ環境ファイル３９を参照して、機種＠をＴＯＷＮＳに置き換えて送る。これを受けて、端末２３はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＯＷＮＳ．ＤＲＶをディレクトリＤ：￥ＷＩＮＤＯＷＳに移動し（ファイル移動）、ＦＯＮＴ．ＤＲＶというファイル名に変更する（リネーム）。

端末２３からファイル移動およびリネームの完了（ＯＫ）を通知されると、次にホスト計算機２１は、ファイルＴＥＴＲＩＳ．ＥＸＥのアイコン登録を行う指示、ＩＣＯＮ ＴＥＴＲＩＳ．ＥＸＥを送る。これを受けて、端末２３はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＥＴＲＩＳ．ＥＸＥをアイコン化して端末２３内に登録する。これにより、表示装置２４の画面に表示された倉庫ウィンドウ３６内に、例えばＴＥＴＲＩＳ．ＥＸＥを起動するアイコン３７が表示され、アイコン３７をクリックすればテトリスが動作を開始する。

端末２３からアイコン登録の完了（ＯＫ）を通知されると、ホスト計算機２１はＲＥＴＵＲＮを送り返してリモートインストールの終了を端末２３に通知し、一連のインストール作業を終了する。リモートインストールの終了を通知された端末２３は、ユーザＡの指示に従って次のソフトウェアの選択とそのリモートインストールを行うか、あるいは処理を終了する（ステップＳ１９）。

ステップＳ１８のインストール時に、インストールするソフトウエェアがそのダウンロード先の格納場所の空き容量に比べて大きければ、格納場所を変更してダウンロードする。

次に、図７から図１２までを参照しながら、本実施例のリモートインストールのプロトコルの例と第１および第２のキーワードの表示例について説明する。
図７は、ステップＳ３の端末２３によるホスト計算機２１へのアクセス時に、端末２３が環境情報を送るプロトコルの一例を示している。図７のプロトコルにおいて、リクエストＩＤ（ＲＩＤ）、端末を特定するマシンＩＤ（ＭＩＤ）、日時（ＴＩＭＥ）に続いて、端末２３に関するマシン情報（ＭＡＣＨＩＮＥ：）が記述されている。

ＭＡＣＨＩＮＥ：の中のドライブ情報（ＤＲＶ：）には、容量やドライブ名等のハードディスク２５に関する情報が記述されている。例えば、ＰＡＲＴＩＮＦ：の中のＣＡＰＡＣＩＴＹはそのパーティションの容量を表し、ＶＡＣＡＮＴはそのうちの空き容量を表し、ＤＲＶＮＡＭＥはそのパーティションに対応するドライブ名を表す。

ＤＲＶ：に続いて、宅配用の格納場所である倉庫ディレクトリＳＯＵＫＯＤＩＲと、ＯＳ（ＷＩＮＤＯＷＳ）の格納場所であるディレクトリＷＩＮＤＩＲが記述されている。ここでは、ＳＯＵＫＯＤＩＲ＝Ｄ：￥ＲＩＳ￥ＳＯＵＫＯであり、ＷＩＮＤＩＲ＝Ｄ：￥ＷＩＮＤＯＷＳである。その次には、メモリに関する情報（ＭＥＭ：）がある。このＳＯＵＫＯＤＩＲを指定することにより、端末２３はホスト計算機２１に宅配先を通知する。

そして、ＭＡＣＨＩＮＥ：に続いて、端末２３のマシンパスワード（ＭＰＳＷＤ）等が記述される。
図８は、ステップＳ１４の環境チェックの終了時に、ホスト計算機２１がＳＯＵＫＯＤＩＲにサブディレクトリを付加して送り返すプロトコルの一例を示している。図８のプロトコルにおいて、ＲＩＤ、環境チェックの判定結果（ＪＵＤＧＥ）に続いて、宅配先に関する情報（ＳＴＲＰＬＡＣＥ：）が記述されている。

ＳＴＲＰＬＡＣＥ：の中のＳＯＦＴはステップＳ１２でユーザが選択したソフトウェアの番号を表し、ＷＯＲＫＤＩＲは作業領域を表し、ＳＯＵＫＯＤＩＲはホスト計算機２１が指定した宅配先を表す。ここでは、ＷＯＲＫＤＩＲは図７のＳＯＵＫＯＤＩＲと同じであり、ＳＯＵＫＯＤＩＲは図７のＳＯＵＫＯＤＩＲにサブディレクトリ名ＦＭを付加した形になっている。

ＳＴＲＰＬＡＣＥ：に続いて、作業領域のサイズＷＯＲＫＳＩＺおよび宅配先のサイズＳＯＵＫＯＳＩＺが記述されている。
図９は、ステップＳ４からＳ９において、ホスト計算機２１が第１および第２キーリストを端末２３に送り、ユーザＡの選択したキーワードのキー番号を端末２３が送り返すプロトコルの一例を示している。図９のプロトコルにおいて、端末２３がコマンドＲＩＳ ＫＥＹＬＩＳＴにより第１キーリストを要求すると、ホスト計算機２１がレスポンスとしてＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに第１キーテーブルの内容ＫＥＹＬＩＳＴ：を送り返す。このＫＥＹＬＩＳＴ：内には、キー番号ＫＥＹ＝１、２、３、・・・に対応してキーワードＮＡＭＥ＝”ＯＳ／基本ソフト”、”開発支援”、”ゲーム”、・・・が記述されている。

次に、端末２３がコマンドＲＩＳ ＫＥＹＬＩＳＴとともに、ユーザＡの選択した第１キーワード”ゲーム”のキー番号３を送ると、ホスト計算機２１がレスポンスとしてＲＩＳ ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに、キー番号３に対応する第２キーテーブルの内容ＫＥＹＬＩＳＴ：を送り返す。このＫＥＹＬＩＳＴ：内には、キー番号ＫＥＹ＝５１、５２、５３、５４、５５、・・・に対応してキーワードＮＡＭＥ＝”ＲＰＧ”、”アクション”、”パズル／クイズ”、”シミュレート”、”冗談”、・・・が記述されている。

そして、端末２３はコマンドＲＩＳ ＬＩＳＴとともに、ユーザＡの選択した第２キーワード”アクション”および”冗談”のキー番号５２および５５をホスト計算機２１に送り、３つのキー番号３、５２、５５を持つソフトウェアのリストを要求する。ここでは、既におくった第１キーワードのキー番号３はホスト計算機２１が記憶しているので、第２キーワードのキー番号５２および５５のみが送られる。

図１０は、第１および第２キーワードの表示例を示している。図１０における第１および第２キーワードは図９のそれらとは異なっている。ユーザＡが見ている表示装置２４の画面には、例えば画像、ゲーム等の第１キーワードが表示され、ユーザＡが第１キーワードを選択すると、次にツール、テキスト、ＤＯＳ、ＷＩＮ、画像、音声、ゲーム等の第２キーワードが表示される。第２キーワードの中には、画像、ゲームのように第１キーワードと重複するものも含まれる。

ユーザＡは、表示されたいずれのキーワードも選択することができる。例えば、第１キーワードとして画像を選び、第２キーワードとしてツール、ＤＯＳ、ゲーム等を選んだり、あるいは第１キーワードとしてゲームを選び、第２キーワードとしてＤＯＳ、ＷＩＮ、画像、音声等を選ぶ。また、ユーザＡは第２キーワードとして２つ以上のキーワードを同時に選択することもできる。

一般に、ソフトウェア群３５の中から希望するソフトウェアを選択するためのキーワードは多数あるので、これらを一度に全部表示すると見づらく、まったく必要のないものも表示される。そこで、これを単純なツリー構造のメニューにして表示すると、最初に選択するキーワードが重要な役割を果たし、そこで選択を誤ると欲しいソフトウェアは得られなくなってしまう。

そこで、図１０のように重複を許して２つの階層でキーワードを表示することにより、ユーザは多数のキーワードの中から必要なものをより柔軟に選びだすことが可能になる。尚、キーワードの階層は２階層に限らず、より多くの階層に分けて表示してもよい。

ソフトウェア群３５の各ソフトウェアのコンテンツは、あらかじめいくつかのキーワードと関係付けられて格納されている。例えば図１０において、ソフトＡはゲーム、画像、ＤＯＳの３つのキーワードを持ち、ソフトＢは画像、ツール、ＷＩＮ、ゲームの４つのキーワードを持つ。したがって、ユーザＡが画像とゲームの２つのキーワードを選択すると、これらの２つのソフトウェアを含むリストがホスト計算機２１から送られてきて画面に表示される。

図１１は、ステップＳ３のホストアクセス時において、端末２３からホスト計算機２１へ送られる環境情報の送信プロトコルの他の例を示している。図１１のプロトコルにおいて、マシン情報ＭＡＣＨＩＮＥ：の中のＭＯＤＥＬは、ステップＳ１において端末ソフトのインストール時に取得した情報で、端末２３の機種ＴＯＷＮＳを表す。また、ＰＡＲＴＩＮＦ：の中のＶＡＣＡＮＴは、ステップＳ３のホスト計算機２１へのアクセスの前（ステップＳ２）に取得した情報で、対応するパーティションの空き容量を表す。

図１２は、ステップＳ１４における環境チェックとその後のステップＳ１７におけるインストール開始のプロトコルの一例を示している。図１２のプロトコルにおいて、まず端末２３はコマンドＲＩＳ ＣＨＫＥＮＶとともにユーザＡの選んだソフトウェアの番号（ソフトコード）ＳＯＦＴ＝５をホスト計算機２１に送り、環境チェックを要求する。

ホスト計算機２１は、まずＶＢＲＪＰ２００．ＤＬＬというファイルが端末２３のシステムディレクトリにあるかどうか調査するための指示ＣＨＫＥＸＥ：を、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。ＣＨＫＥＸＥ：には、ＴＡＧ＝”ＶＢＲＪＰ２００．ＤＬＬ”、コマンドＣＭＤ＝”ＳＴ４ Ｄ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭ￥ＶＢＲＪＰ２００．ＤＬＬ”、作業用ディレクトリの指定ＷＯＲＫＤＩＲ＝”Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ”、宅配先のディレクトリの指定ＳＯＵＫＯＤＩＲ＝”Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ”等が記述されている。

端末２３は、ドライブＤのディレクトリＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭにファイルＶＢＲＪＰ２００．ＤＬＬがあるかどうか調べ、その結果をＲＥＳＵＬＴ：としてホスト計算機２１に送り返す。ＲＥＳＵＬＴ：には、対応するＴＡＧ＝”ＶＢＲＪＰ２００．ＤＬＬ”とともに調査結果ＶＡＬ＝”ＯＦＦ”が記述されている。これは、ファイルＶＢＲＪＰ２００．ＤＬＬがシステムディレクトリになかったことを意味する。

そこで、ホスト計算機２１は、選択されたソフトウェアをインストールしてよいかどうかをユーザに問い合わせる指示ＡＳＫＣＨＫ：を、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末２３に送る。ＡＳＫＣＨＫ：には、ＴＡＧ＝”Ｑ１”、表示すべき質問文ＱＵＥＲＹ＝”このソフトを実行するためには〜インストールしてもよろしいですか？”、および回答のフォーマットＡＮＳ：が記述されている。

端末２３は、ユーザＡが入力した回答をＲＥＳＵＬＴ：として、コマンドＲＩＳ ＣＨＫＥＮＶとともにホスト計算機２１に送り返す。ＲＥＳＵＬＴ：には、対応するＴＡＧ＝”Ｑ１”とともに回答結果ＶＡＬ＝”ＯＫ”が記述されている。これは、ソフトウェアをインストールしてもよいという意味である。

そこで、ホスト計算機２１は、他に動作環境上の障害がなければ、レスポンスＲＩＳ ＣＨＫＥＮＶ＊ＲＥＳＰとともに環境チェック結果ＪＵＤＧＥ＝”ＯＫ”を端末２３に送る。これは、ファイルＶＢＲＪＰ２００．ＤＬＬがないことを除いて、ソフトコード５番のソフトウェアの動作環境が整っており、インストールが可能であることを意味する。

環境チェックの結果が”ＯＫ”となったので、端末２３はコマンドＲＩＳ ＩＮＳＴＡＬＬとともに、インストール方法の種別ＴＹＰＥ＝”ＲＩＳ”、宅配先の指定ＳＴＲＰＬＡＣＥ：等をホスト計算機２１に送り、インストールを要求する。ＳＴＲＰＬＡＣＥ：には、インストールするソフトウェアのソフトコードＳＯＦＴとともに、作業用ディレクトリＷＯＲＫＤＩＲ、宅配先のディレクトリＳＯＵＫＯＤＩＲが記述されている。

以後、ホスト計算機２１は指定された方法でソフトウェアのインストールを行う。インストールの際には、例えば図５のステップＳ１８で説明したようにホスト計算機２１から送られるコマンドにより、端末２３がファイルを解凍して、コピーして、システムに登録するという逐次作業を行う。これらの作業が完了したかどうかは、端末２３がレスポンスとして逐次送り返すので、ホスト計算機２１はインストール作業の進行状況を最後まで監視することができる。

しかしこの方法では、端末２３が頻繁にホスト計算機２１との通信を行わなければならないので、通信の効率が悪くなる。そこで、ホスト計算機２１がインストール作業のコマンドを記述した設定ファイルを用意し、これを端末２３に渡して自動インストールを行わせる方法が考えられる。

図１３は、設定ファイルを用いた自動インストールのフローチャートである。図１３のインストール作業は、図４のステップＳ１６におけるサブディレクトリの生成の後に行われる。

端末２３は、まずコマンドＲＩＳ ＩＮＳＴＡＬＬをソフトウェアの番号とともにホスト計算機２１に送る（ステップＳ２１）。これを受けて、ホスト計算機２１は送られた番号に対応するソフトウェアのリモートインストールを開始する。リモートインストールは、ホスト計算機２１が作成したテトリスのインストールスクリプト４３に従って、ホスト計算機２１と端末２３の間のやりとりにより自動的に行われる（ステップＳ２２）。

ホスト計算機２１は、まず＠ＳＯＵＫＯ＠をＳＯＵＫＯＤＩＲ＝Ｄ：￥ＳＯＵＫＯ￥ＴＥＴに置き換えて、ハードディスク２５のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴにファイルＴＥＴ１．ＬＺＨをダウンロードする。

端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて、ハードディスク２５のディレクトリＤ：￥ＷＩＮＤＯＷＳにＶＢＲＪＰ２００．ＤＬＬをダウンロードする。

端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、＠ＳＯＵＫＯ＠をＳＯＵＫＯ＝Ｄ：￥ＳＯＵＫＯに置き換えて、端末２３が行うべき作業のコマンドを記述したユーザＡ用設定ファイル４４（ＳＥＴＵＰ．ＩＮＦ）を、ハードディスク２５のディレクトリＤ：￥ＳＯＵＫＯにダウンロードする。このとき、ホスト計算機２１はステップＳ１８と同様にユーザＡ環境ファイル３９を参照して、設定ファイルＳＥＴＵＰ．ＩＮＦに含まれる機種、ＳＯＵＫＯ、ＷＩＮＤＩＲ等の情報をユーザＡ用の情報に書き換えて送る。設定ファイルＳＥＴＵＰ．ＩＮＦには、ファイルＴＥＴ１．ＬＺＨを解凍し、ファイルＴＯＷＮＳ．ＤＲＶを移動してリネームし、ファイルＴＥＴＲＩＳ．ＥＸＥをシステムに登録する一連の作業が記述されている。

端末２３からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機２１は、設定ファイルＳＥＴＵＰ．ＩＮＦの記述に従って自動インストールを行う指示ＩＮＳＴＡＬＬ Ｄ：￥ＳＯＵＫＯ￥ＳＥＴＵＰ．ＩＮＦを端末２３に送る。

これを受けて端末２３は、設定ファイルＳＥＴＵＰ．ＩＮＦの記述に従って自動インストールを行う。端末２３は、まずコマンドＬＯＧ ＯＦＦによりホスト計算機２１との間の回線を遮断する。これ以降は、通信回線２２を使用しないので通信料金もかからない。次に、コマンドＬＨＡ Ｘ Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＥＴ１．ＬＺＨにより、ファイルＴＥＴ１．ＬＺＨを前述した４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣに解凍する。

次に、端末２３はコマンドＭＯＶＥ Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＯＷＮＳ．ＤＲＶ Ｄ：￥ＷＩＮＤＯＷＳ￥ＦＯＮＴ．ＤＲＶにより、ファイルＴＯＷＮＳ．ＤＲＶをディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴからＤ：￥ＷＩＮＤＯＷＳに移動させて、そのファイル名をＦＯＮＴ．ＤＲＶに変更する。次に、コマンドＩＣＯＮ ＴＥＴＲＩＳ．ＥＸＥにより、ファイルＴＥＴＲＩＳ．ＥＸＥをアイコン化して端末２３内に登録する。そして、コマンドＰＯＦＦにより電源をオフにし、インストール作業を終了する。

設定ファイルを用いた自動インストールでは、ホスト計算機２１が作業終了の最終確認をすることはできないが、通信回数を削減することにより通信回線２２の使用効率を高めることができる。また、ソフトウェアの購入前に機種等のインストール条件を解決して、後は自動的にインストールが行われる。

図１４は、他の形式の設定ファイルの一例を示している。図１４の設定ファイルにおいて、〔ＤｓｔＤｉｒｓ〕はファイルの格納先のリストであり、〔Ｆｉｌｅｓ〕は格納すべきファイルのリストである。ここでは、ユーザが希望するソフトウェアの実行ファイルＳｏｆｔ２．ＥｘｅをディレクトリＤ：￥ＲＩＳ￥ＫＯＢＵＴＡに格納し、ＴＯＷＮＳ用のドライバであるＴＯＷＮＳ．ＤＲＶの名称をＦＯＮＴ．ＤＲＶに変更してディレクトリＤ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭに格納することが記述されている。

設定ファイルの生成時には、〔ＤｓｔＤｉｒｓ〕は１＝ＳＯＵＫＯＤＩＲ、２＝ＷＩＮＤＩＲと記述されるが、ホスト計算機２１が実際のＳＯＵＫＯＤＩＲ、ＷＩＮＤＩＲの情報を得た時点で、１＝Ｄ：￥ＲＩＳ￥ＫＯＢＵＴＡ、２＝Ｄ：￥ＷＩＮＤＯＷＳ￥ＳＹＳＴＥＭと書き換えられる。このように、設定ファイルの中の設定条件は動的または選択的に変更することができる。

本発明の原理図である。 本発明の実施例の構成図である。 リモートインストールのフローチャート（その１）である。 リモートインストールのフローチャート（その２）である。 リモートインストールのフローチャート（その３）である。 インストール方法選択ウィンドウの例を示す図である。 リモートインストールプロトコルを示す図（その１）である。 リモートインストールプロトコルを示す図（その２）である。 キーワード選択のプロトコルを示す図である。 キーワードの表示例を示す図である。 環境情報の送信プロトコルを示す図である。 環境チェックのプロトコルを示す図である。 自動インストールのフローチャートである。 設定ファイルの例を示す図である。

符号の説明

１ インストール手段
２ サブディレクトリ指定手段
３ キーワード格納手段
４ 環境チェック手段
１１ 自動インストール手段
１２ コンテンツ格納手段
１３ アイコン表示手段
１４ インストールメニュー表示手段
１５ 選択手段
１６ キーワード表示手段
１７ 環境情報通知手段
２１ ホスト計算機
２２ 通信回線
２３ 端末
２４ 表示装置
２５ ハードディスク
３１、３８、３９ 環境ファイル
３２ 第１キーテーブル
３３ 第２キーテーブル
３４、４４ 設定ファイル
３５ ソフトウェア群
３６ 倉庫ウィンドウ
３７ アイコン
４０ チェックスクリプト
４１ ファイル本体
４２、４３ インストールスクリプト

Claims (2)

1. 通信回線で結ばれたユーザの端末装置に対象ソフトウェアを送信するホスト計算機であって、
   前記端末装置の格納領域に関する情報および送信すべき対象ソフトウェアに関する情報に応じて該対象ソフトウェアの動作環境をチェックするためのチェックスクリプトから、該端末装置内でオペレーティングシステムが格納されている格納場所に該対象ソフトウェアの動作に必要なファイルがあるかどうかを調査するコマンドを取り出す手段と、
   前記取り出したコマンドを前記端末装置に送信する手段と、
   前記オペレーティングシステムが格納されている格納場所に前記必要なファイルがなければ該必要なファイルをダウンロードしてよいかを前記ユーザに問い合わせた後に、前記端末装置の格納領域に関する情報および送信すべき対象ソフトウェアに関する情報に応じて、該端末装置に該対象ソフトウェアを格納するサブディレクトリを該端末装置の配送専用の格納領域内に生成させるためのサブディレクトリ指定情報を生成する手段と、
   前記生成したサブディレクトリ指定情報、前記対象ソフトウェア、および前記必要なファイルを前記端末装置に送信する手段と
   を備えることを特徴とするホスト計算機。
2. 前記端末装置の格納領域に関する情報および送信すべき対象ソフトウェアに関する情報に応じて、該端末装置に送信された対象ソフトウェアをインストールするために該端末装置が行う一連の作業として、前記ホスト計算機との通信回線を遮断し、該対象ソフトウェアを解凍し、解凍されたファイルの格納場所を移動してリネームし、該対象ソフトウェアのアイコンを登録する手順を記述した設定ファイルを生成する手段と、
   前記生成した設定ファイルを前記端末装置に送信する手段と
   をさらに備えることを特徴とする請求項１記載のホスト計算機。

Images