JP2004005632A - インターネットを利用したリモートインストールシステムおよびその方法 - Google Patents

Abstract

【課題】インターネット上でリモートインストールシステムを利用して、安全かつ適切な会員制サービスを実現することが課題である。
【解決手段】ＷＷＷブラウザ１１４により起動されたリモートインストールサービス（ＲＩＳ）クライアント１１５は、ホームページ上でクリックされたアイコンに対応するソフトウェア番号を、ＲＩＳサーバ１１２に通知する。ＲＩＳサーバ１１２は、その情報を元にして、ソフトウェア配送、オンラインショッピング、通信サービス、トランザクションサービス等の各種サービスを提供する。インターネット１１７上で、パスワードやコンテンツは暗号化されてやり取りされる。
【選択図】　　　図２

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネット等の通信ネットワークを利用したリモートインストールシステムおよびその方法に関する。
【０００２】
【従来の技術】
近年のパーソナルコンピュータの普及に伴い、ユーザは通信回線を介して様々なサービスを受けられるようになりつつある。例えば、通信回線を介してソフトウェアの配送を自動的に行う従来の技術として、「リモートインストールシステムおよび方法」（特願平７−１７９７、特開平８−１９０４７２）がある。
【０００３】
従来のリモートインストールサービスシステム（ＲＩＳシステム）は、ソフトウェアの配送センターにあるホスト計算機、ユーザ端末、およびこれらを結ぶ通信回線から成る。ホスト計算機は、配送可能な複数のソフトウェアを含むソフトウェア群と、そのソフトウェア群から特定のソフトウェアを選択するときに用いるキーワードのリストを保持する第１キーテーブルおよび第２キーテーブルを格納している。
【０００４】
ユーザが端末からホスト計算機にキーワードのリストを要求すると、ホスト計算機は第１キーテーブル、第２キーテーブルを順次送信して、それらに含まれるキーワードを端末の表示装置の画面に表示させる。ユーザは表示されたキーワードから希望するソフトウェアに対応するものを選び、ホスト計算機に通知する。
【０００５】
ホスト計算機は通知されたキーワードに該当するいくつかのソフトウェアの名称を含むメニューを表示装置の画面に表示させ、ユーザはその中から希望するソフトウェアを選んで、ホスト計算機に通知する。そして、ホスト計算機はソフトウェア群からユーザの選んだソフトウェアのコンテンツ（ファイル）を取り出し、端末のハードディスクに設定された配送用のディレクトリに格納する。
【０００６】
このとき、宅配されたソフトウェアを起動するためのアイコンが自動的に登録され、表示装置の画面上でディレクトリに対応して設けられた倉庫ウィンドウ内に表示される。例えば端末がＷＩＮＤＯＷＳ（登録商標）を搭載している場合は、宅配されたソフトウェアはＷＩＮＤＯＷＳのプログラムマネージャに登録される。以後、ユーザはそのアイコンをマウス等の入力装置を用いてクリックするだけで、宅配されたソフトウェアを使用することができる。
【０００７】
ここで、図４４から図４６までを参照しながら、従来のリモートインストールシステムによるソフトウェアの宅配の動作フローを説明する。
図４４において、ユーザＡの端末は通信用の端末ソフトのインストール時に動作環境の情報を取得し、取得した情報を設定した環境ファイル１を作成する（ステップＳ１）。このとき、ユーザの端末の機種や宅配に使用する格納場所（ディレクトリ）ＳＯＵＫＯ等の、取得に時間のかかる情報、あるいは、場合によってユーザに問い合わせなければならない情報を取得する。
【０００８】
格納場所ＳＯＵＫＯの決定にあたっては、端末はそのハードディスクに所定の容量以上の空き領域があるかどうかを調べ、空き領域があればそのルートに宅配用のディレクトリを作成する。このときディレクトリ名等は端末が自動的に生成し、ユーザＡはそれを確認する作業のみを行う。したがって、ユーザＡはディレクトリ名等を入力する必要がない。
【０００９】
ここでは、ユーザＡの機種はＴＯＷＮＳであり、ＳＯＵＫＯのディレクトリはＤ：￥ＳＯＵＫＯ（ドライブＤのディレクトリＳＯＵＫＯ）であることが環境ファイル１に書き込まれる。ユーザＡは、必要があればＤ：￥ＳＯＵＫＯを他のディレクトリに変更することもできる。
【００１０】
既に設定されているパーティションに所定の容量の空き領域がなければ、別のパーティションの空き領域が一番大きい場所を探して、そこに宅配用のディレクトリを作成する。具体的には、ディレクトリＤ：￥ＳＯＵＫＯが一杯になったとすると、端末が”Ｄ：￥ＳＯＵＫＯが一杯です。倉庫をＦ：￥ＳＯＵＫＯに変更します。よろしいですか。”等のメッセージを表示装置の画面に表示する。
【００１１】
ユーザＡがこれを承認すると、Ｆ：￥ＳＯＵＫＯが新たにＳＯＵＫＯのディレクトリとなる。所定の容量の空き領域がどのハードディスクにもなかったときは、”残念ながらディスク容量が足りません。ディスクを増設してください。”等のメッセージが表示される。
【００１２】
次に、端末ソフトの起動時（ホスト計算機へのアクセス時）に、ハードディスクやメモリの状況等のインストール後に変化した可能性のある情報を取得する（ステップＳ２）。ここでは、ユーザＡのハードディスクがドライブＤにあり、空き容量が３００Ｍバイトであることが環境ファイル１に書き込まれる。こうして作成された環境ファイル１の内容は、ユーザＡがホスト計算機にアクセス（接続）したときに、コマンドＲＩＳ　ＳＥＮＤＥＮＶによりホスト計算機に送信される（ステップＳ３）。
【００１３】
ホスト計算機は受信した情報をユーザＡ環境ファイル２として保持する。ユーザＡ環境ファイル２には、機種、ハードディスク情報ＨＤ、格納場所ＳＯＵＫＯのほかに、使用しているＯＳ（オペレーティングシステム）とその格納場所が記述されている。ここでは、ユーザＡの端末のＯＳはＷＩＮＤＯＷＳであり、その格納場所ＷＩＮＤＩＲはＤ：￥ＷＩＮＤＯＷＳであることがわかる。
【００１４】
ホスト計算機からコマンドＲＩＳ　ＳＥＮＤＥＮＶに対するレスポンスとしてＲＩＳ　ＳＥＮＤＥＮＶ＊ＲＥＳＰ　ＯＫを受け取ると、端末はコマンドＲＩＳＫＥＹＬＩＳＴにより第１キーリストを要求する（ステップＳ４）。これに応じて、ホスト計算機２１は第１キーテーブル３の内容をＲＩＳ　ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第１キーテーブル３には、キー番号１、２、３、・・・に対応するキーワードとして、ＯＳ／基本ソフト、開発支援、ゲーム、・・・が格納されている。
【００１５】
これらのキーワードが第１キーリストとして表示装置の画面に表示されると（ステップＳ５）、ユーザＡはそれらの中から第１キーワードを選び端末に入力する（ステップＳ６）。すると、端末はユーザＡの選んだ第１キーワードのキー番号とともに、第２キーリストを要求するコマンドＲＩＳ　ＫＥＹＬＩＳＴをホスト計算機に送る（ステップＳ７）。ここでは、ユーザＡは第１キーワードとしてゲームを選択し、それに対応するキー番号３がホスト計算機に送られる。
【００１６】
第２キーリストを要求されたホスト計算機は、受け取ったキー番号に対応して第１キーテーブル３内に格納されているポインタを用いて、対応する第２キーテーブル４を求め、その内容をＲＩＳ　ＫＥＹＬＩＳＴ＊ＲＥＳＰとともに送り返す。ここでは、第２キーテーブル４には、キー番号５１、５２、５３、・・・に対応するキーワードとして、ＲＰＧ、アクション、パズル／クイズ、・・・が格納されている。
【００１７】
第２キーテーブル４は第１キーテーブル３内のキーワードに対応して一般に複数設けられており、その数は第１キーテーブル３内のキーワードの数と同じか、またはそれより少ない。後者の場合には、第１キーテーブル３内の２つ以上のキーワードが同じ１つの第２キーテーブル４を指すことになる。
【００１８】
第２キーテーブル４内のキーワードが第２キーリストとして表示装置の画面に表示されると（ステップＳ８）、ユーザＡはそれらの中から第２キーワードを選び端末に入力する（図４５、ステップＳ９）。すると、端末はユーザＡの選んだ第１および第２キーワードのキー番号とともに、第１および第２キーワードの両方に該当するソフトウェアのリストを要求するコマンドＲＩＳ　ＬＩＳＴをホスト計算機に送る（ステップＳ１０）。ここでは、ユーザＡは第２キーワードとしてアクションを選択し、それに対応するキー番号５２がホスト計算機に送られる。
【００１９】
ソフトウェアのリストを要求されたホスト計算機は、第１および第２キーワードの２つのキー番号を持つソフトウェアをソフトウェア群の中から検索する。このとき、検索条件として第１キーワードと第２キーワードとを区別せずに、フラットに検索を行う。また、機種やＯＳの種別はデフォルトのキーとして扱い、これらも加味した上で検索する。これにより、例えばＴＯＷＮＳ以外の機種専用のソフトウェアが検索されてくることが防止される。
【００２０】
そして、該当するソフトウェアの名称と番号のリストをＲＩＳ　ＬＩＳＴ＊ＲＥＳＰとともに端末に送る。ここでは、キー番号３と５２を持つテトリス、パチンコ等のソフトウェアが該当するので、それらの名称がそれぞれのソフトウェア番号５、３０等とともに端末に送られる。
【００２１】
ソフトウェアのリストが表示装置の画面に表示されると（ステップＳ１１）、ユーザＡはそれらの中から希望するソフトウェアを選び、端末に入力する（ステップＳ１２）。すると、端末はユーザＡの選んだソフトウェアの番号とともに、ユーザＡの環境がそのソフトウェアの動作に適するかどうかのチェックを要求するコマンドＲＩＳ　ＣＨＫＥＮＶをホスト計算機に送る（ステップＳ１３）。ここでは、ユーザＡはテトリスを選択し、それに対応するソフトウェア番号５がホスト計算機に送られる。
【００２２】
ユーザＡが選択したソフトウェアの番号を受け取ったホスト計算機は、その番号に対応するソフトウェアの動作環境とユーザＡの端末の環境との整合性を調べるためのチェックスクリプト５を用意し、環境チェックを行う。
【００２３】
このチェックはチェックスクリプト５の実行プログラムと端末の端末ソフトとの間のやりとりにより自動的に行われるので、ユーザＡは環境チェックが行われていることを必ずしも意識する必要はない（ステップＳ１４）。ユーザＡに何らかの問い合わせを行う必要が生じたときにのみ、ホスト計算機がその問い合わせを行う。
【００２４】
ここでは、ユーザＡが選択したテトリスの動作環境として、ＯＳがＷＩＮＤＯＷＳ、機種がＴＯＷＮＳ、ＰＣ９８等、推奨ディレクトリ（ＤＩＲ）名がＴＥＴであることが記述されている。これに対して、ユーザＡ環境ファイル２には、機種がＴＯＷＮＳ、ＯＳがＷＩＮＤＯＷＳと記述されており、両者を比較することによって機種とＯＳが適合していることがわかる。
【００２５】
次に、テトリスのチェックスクリプト５を見るとユーザＡ側の格納場所ＷＩＮＤＩＲにＶＢＲＪＰ２００．ＤＬＬというファイルがあるかどうか調査するためのコマンド”ＳＴ４　＠ＷＩＮＤＩＲ＠ＶＢＲＪＰ２００．ＤＬＬ”があるので（ＭＱ１）、ホスト計算機はこれをＲＩＳ　ＣＨＫＥＮＶ＊ＲＥＳＰとともに端末に送る。このとき、ホスト計算機はユーザＡ環境ファイル２を参照して、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて送る。また、ファイルＶＢＲＪＰ２００．ＤＬＬはテトリスの動作に必要なファイルの１つである。
【００２６】
このコマンドを受け取った端末は、ドライブＤのディレクトリＷＩＮＤＯＷＳにファイルＶＢＲＪＰ２００．ＤＬＬがあるかどうか調べ、その結果をＡＮＳとしてホスト計算機に送り返す。ここでは、該当するファイルがなかったのでＡＮＳ＝ＯＦＦが送り返される。
【００２７】
端末にファイルＶＢＲＪＰ２００．ＤＬＬがないことを知ったホスト計算機は、チェックスクリプト５に従って（ＭＱ２）、”ＶＢＲＪＰ２００をコピーしてよいか？”という問い合わせを端末に送り、この問い合わせが表示装置の画面に表示される。ユーザＡは表示された問い合わせに対する回答を入力し、端末がその回答をホスト計算機に送り返す。ここでは、ＡＮＳ＝はい　が送り返され、ホスト計算機はチェックスクリプト５に従って、リモートインストールを承諾し（ＲＩＳ＝ＯＫ）、ＶＢＲＪＰ２００．ＤＬＬのコピーを指示するフラグＦ２をＯＮにする（ＭＡ２）。
【００２８】
もし、ファイルＶＢＲＪＰ２００．ＤＬＬが端末の指定されたディレクトリにあった場合はＡＮＳ＝ＯＮが送り返されるので、その時点でＲＩＳ＝ＯＫとなる（ＭＡ１）。
【００２９】
このように環境チェックを自動的に行うことにより、ユーザＡの環境に適合しないソフトウェアが配送されるのを防ぐことができる。例えば、あるパッケージソフトウェアを通信回線を介して購入した後に、特定のドライバがないとそれが動作しないことを知るといったような事故が未然に防止される。
【００３０】
ＲＩＳ＝ＯＫとなるとホスト計算機は環境チェックを終了し、判定結果（ＪＵＤＧＥ＝ＯＫ）とともに、配送先のディレクトリＳＯＵＫＯＤＩＲを端末に送る。このＳＯＵＫＯＤＩＲは、ユーザＡ環境ファイルに格納されているＳＯＵＫＯのディレクトリであるＤ：￥ＳＯＵＫＯの下に、テトリスの推奨ディレクトリであるＴＥＴをサブディレクトリとして付加した形式で指定される。
【００３１】
このとき同時に、インストールの可否（ＲＩＳ）、インストールプログラム（インストーラ）のアイコン登録の有無（ＩＣＯＮ）、およびダウンロードの可否（ＤＬＯＡＤ）が端末に送られる。これらのフラグＲＩＳ、ＩＣＯＮ、ＤＬＯＡＤにより、ホスト計算機はインストール、インストーラのアイコン登録、ダウンロードのうちのどれが可能かを端末に通知する。
【００３２】
インストールとはユーザＡの選んだソフトウェアを端末のシステム、例えばＷＩＮＤＯＷＳに登録して、端末上で使用可能にすることを意味する。したがって、この場合はそのソフトウェアの実行ファイルをＷＩＮＤＯＷＳ上でアイコン登録する作業までを含む。これに対して、インストーラのアイコン登録とはインストールを実行するプログラムを端末上でアイコン登録することを意味する。
【００３３】
ここでは、インストールとダウンロードが許諾され（ＲＩＳ＝ＯＫ、ＤＬＯＡＤ＝ＯＫ）、インストーラのアイコン登録は行わない（ＩＣＯＮ＝ＮＧ）という条件が提示される。複雑なインストールプログラムを持つソフトウェアの場合には、インストールが許諾される代わりにインストーラのアイコン登録が必要である旨が提示される。また、ＷＩＮＤＯＷＳを搭載している端末からＴＯＳ（ＴＯＷＮＳのＯＳ）用のアプリケーションを要求されたような場合には、ダウンロードのみが許諾される。
【００３４】
次に、端末の端末ソフトはインストール、インストーラのアイコン登録、ダウンロードの順に優先順位をつけて、より優先順位の高いものをデフォルトとして設定し、表示装置の画面に表示する。ここでは、ホスト計算機により許諾されたインストールとダウンロードのうち優先順位のより高いインストールがデフォルトとして設定され、インストール方法選択ウィンドウに表示される。
【００３５】
ユーザＡは表示されたインストール方法を確認して、確認した旨を入力する（ステップＳ１５）。また、ユーザＡはここで表示された設定を変更することもできる。例えば、インストーラのアイコン登録を行いたいときは、インストール方法選択ウィンドウ内の「インストーラのアイコン登録」を選択して入力する。
【００３６】
基本的には、ユーザＡは手間をかけずにできあいのインストールを行いたい場合は「システム登録」を選択し、細かいインストール設定を自分で行いたい場合は「インストーラのアイコン登録」を選択し、格納場所を後で変更したい（別の機種の端末にインストールしたい）場合は「ダウンロード」を選択する。「ダウンロード」を選択すれば、端末の機種とは異なる機種用のソフトウェアを入手して動作するかどうか試してみることも可能になる。
【００３７】
次に、端末はホスト計算機から指示された宅配用のサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴを、ハードディスク内に自動的に生成する（ステップＳ１６）。ここでもし、端末にサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴが既に存在している場合は、例えばＤ：￥ＳＯＵＫＯ￥ＴＥＴ　００１というサブディレクトリをつくり、これも既に存在している場合はＤ：￥ＳＯＵＫＯ￥ＴＥＴ　００２というサブディレクトリをつくる。
【００３８】
テトリスのファイル本体６はファイルＴＥＴ１．ＬＺＨ（Ｆ１）とＶＢＲＪＰ２００．ＤＬＬ（Ｆ２）とから成り、ＴＥＴ１．ＬＺＨは４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣを圧縮（凍結）してできている。ＴＥＴ１．ＬＺＨを圧縮前の状態に伸長（解凍）するとこれらの４つのファイルに分かれるが、ＴＥＴ１．ＬＺＨの解凍はホスト計算機から端末に配送された後に行われる。
【００３９】
宅配用のサブディレクトリを生成した端末は、リモートインストールの開始を依頼するコマンドＲＩＳ　ＩＮＳＴＡＬＬを選択したソフトウェアの番号とともにホスト計算機に送る（図４６、ステップＳ１７）。これを受けて、ホスト計算機は送られた番号に対応するソフトウェアのリモートインストールを開始する。リモートインストールは、ホスト計算機が作成したテトリスのインストールスクリプト７に従って、ホスト計算機と端末の間のやりとりにより自動的に行われる（ステップＳ１８）。
【００４０】
インストールスクリプト７には、まずファイルＴＥＴ１．ＬＺＨをユーザＡ側の格納場所＠ＳＯＵＫＯ＠にダウンロードすることを指示する記述がある。そこで、ホスト計算機は＠ＳＯＵＫＯ＠をＳＯＵＫＯＤＩＲ＝Ｄ：￥ＳＯＵＫＯ￥ＴＥＴに置き換えて、ハードディスクのサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴにＴＥＴ１．ＬＺＨをダウンロードする。
【００４１】
端末からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機は、＠ＷＩＮＤＩＲ＠をＤ：￥ＷＩＮＤＯＷＳに置き換えて、ハードディスクのディレクトリＤ：￥ＷＩＮＤＯＷＳにＶＢＲＪＰ２００．ＤＬＬをダウンロードする。
【００４２】
端末からダウンロードの完了（ＯＫ）を通知されると、次にホスト計算機は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）にダウンロードしたＴＥＴ１．ＬＺＨを解凍する指示、ＬＨＡ　Ｘ　Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＥＴ１．ＬＺＨを送る。これを受けて、端末はＴＥＴ１．ＬＺＨを前述した４つのファイルＴＥＴＲＩＳ．ＥＸＥ、ＴＯＷＮＳ．ＤＲＶ、ＰＣ９８．ＤＲＶ、およびＭＡＣ．ＤＲＣに解凍する。これらの４つのファイルはＴＥＴ１．ＬＺＨと同じサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴに保持される。
【００４３】
端末から解凍の完了（ＯＫ）を通知されると、次にホスト計算機は、格納場所＠ＳＯＵＫＯ＠（Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ）の機種＠．ＤＲＶというファイルを格納場所＠ＷＩＮＤＩＲ＠（Ｄ：￥ＷＩＮＤＯＷＳ）に移動させてファイル名をＦＯＮＴ．ＤＲＶに変更する指示、ＭＯＶＥ　Ｄ：￥ＳＯＵＫＯ￥ＴＥＴ￥ＴＯＷＮＳ．ＤＲＶ　Ｄ：￥ＷＩＮＤＯＷＳ￥ＦＯＮＴ．ＤＲＶを送る。
【００４４】
このとき、ホスト計算機はユーザＡ環境ファイル２を参照して、機種＠をＴＯＷＮＳに置き換えて送る。これを受けて、端末はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＯＷＮＳ．ＤＲＶをディレクトリＤ：￥ＷＩＮＤＯＷＳに移動し（ファイル移動）、ＦＯＮＴ．ＤＲＶというファイル名に変更する（リネーム）。
【００４５】
端末からファイル移動およびリネームの完了（ＯＫ）を通知されると、次にホスト計算機は、ファイルＴＥＴＲＩＳ．ＥＸＥのアイコン登録を行う指示、ＩＣＯＮ　ＴＥＴＲＩＳ．ＥＸＥを送る。これを受けて、端末はサブディレクトリＤ：￥ＳＯＵＫＯ￥ＴＥＴのファイルＴＥＴＲＩＳ．ＥＸＥをアイコン化して端末内に登録する。
【００４６】
これにより、表示装置の画面に表示された倉庫ウィンドウ内に、例えばＴＥＴＲＩＳ．ＥＸＥを起動するアイコンが表示され、アイコンをクリックすればテトリスが動作を開始する。
【００４７】
端末からアイコン登録の完了（ＯＫ）を通知されると、ホスト計算機はＲＥＴＵＲＮを送り返してリモートインストールの終了を端末に通知し、一連のインストール作業を終了する。リモートインストールの終了を通知された端末は、ユーザＡの指示に従って次のソフトウェアの選択とそのリモートインストールを行うか、あるいは処理を終了する（ステップＳ１９）。
【００４８】
このようなリモートインストールシステムを利用して、ユーザにソフトウェアを販売する場合、流通するソフトウェアを管理する従来の技術として、「ソフトウェア流通システムにおける識別子管理装置および方法」（特願平７−１７９８、特開平８−１９０５２９）がある。
【００４９】
このシステムでは、ホスト計算機はそれぞれのユーザ端末に端末識別子（マシンＩＤ：ＭＩＤ）を発行し、端末のユーザにはマシンＩＤとは別のユーザ識別子（ユーザＩＤ：ＵＩＤ）を発行する。また、各マシンＩＤに対応して端末のパスワード（マシンパスワード：ＭＰＳＷ）を設け、各ユーザＩＤに対応してユーザパスワードを設ける。
【００５０】
ホスト計算機はこれらのマシンＩＤ、マシンパスワード、ユーザＩＤ、およびユーザパスワードを用いて、ソフトウェアの販売先である端末とユーザの情報を管理する。
【００５１】
ユーザに販売したソフトウェアが何らかの原因により破壊され使用不可能となった場合には、ホスト計算機は販売記録を参照して、そのソフトウェアの復旧サービスを行う。また、販売したソフトウェアのバージョンアップのサービスも行う。さらに、ホスト計算機は端末に与えるマシンパスワードを動的に変更して、アクセスが行われるたびにそれをチェックすることにより、インストールしたソフトウェアが他の端末にコピーされたかどうかを監視する。
【００５２】
あるユーザから他のユーザに端末の譲渡があった場合には、その端末にインストールされたソフトウェアは、そのバージョンアップや復旧等のサービスを受ける権利も含めて譲り渡すことが可能となる。このような譲渡を行えば、不正コピーの防止にも繋がるし、権利の譲渡もスムーズに行われるため、ユーザとベンダーの双方に有益に働く。
【００５３】
ここで、図４７から図５０までを参照しながら、従来のソフトウェア流通システムにおける処理のフローを説明する。
図４７は、ユーザＩＤの登録処理のフローチャートである。処理が開始されると、まずユーザは端末を流通センターのホスト計算機に接続して（ステップＳ２１）、名前、キャッシュカードの番号、住所等の個人情報を入力する（ステップＳ２２）。これを受けて、ホスト計算機は仮のユーザＩＤと仮のユーザパスワードを発行して、ユーザの仮登録を行う（ステップＳ２３）。ここで、ユーザは一旦ホスト計算機との接続を断ち、キャッシュカードが認証されるのを待つ（ステップＳ４）。
【００５４】
キャッシュカードが認証され、流通センターから正式のユーザＩＤと正式のユーザパスワードとが郵送されてくると（ステップＳ２５）、ユーザは再び端末をホスト計算機に接続して（ステップＳ２６）、受け取った正式のユーザＩＤと正式のユーザパスワードとを入力する（ステップＳ２７）。
【００５５】
これにより、ホスト計算機は正式のユーザＩＤとユーザパスワードを記載した郵便がユーザ本人に届いたことを確認し、そのユーザを正式に登録（本登録）して処理を終了する。このとき、郵送されたユーザパスワードと共に、別のパスワードをユーザが入力して登録することもできる。
【００５６】
図４８は、端末ＩＤの登録処理のフローチャートである。処理が開始されると、まずユーザは端末を流通センターのホスト計算機に接続して（ステップＳ３１）、登録されているユーザＩＤとユーザパスワードを入力する（ステップＳ３２）。その後、端末がその機種や使用ＯＳ等のマシン情報を自動的にホスト計算機に送る（ステップＳ３３）。ホスト計算機は送られたマシン情報に端末ＩＤと端末パスワードを付加して所定の形式で記憶し、それらの端末ＩＤと端末パスワードを端末に送る（ステップＳ３４）。こうして、発行された端末ＩＤと端末パスワードは端末内にも保持される。
【００５７】
図４９は、流通センターに登録されたユーザにネットワークを介してソフトウェアを販売する処理のフローチャートである。図４９において、ユーザのリクエスト等により処理が開始されると、まずユーザの端末がネットワークに接続される（ステップＳ４１）。次に、ホスト計算機はユーザが入力したユーザＩＤとユーザパスワードをチェックし（ステップＳ４２）、それらが正しくなければ（ＮＧ）、処理を終了する。
【００５８】
ユーザＩＤとユーザパスワードが正しければ（ＯＫ）、次にホスト計算機は端末内に保持された端末ＩＤと端末パスワードとを自動的に読み取り、これらをチェックする（ステップＳ４３）。端末ＩＤと端末パスワードが正しくなければ（ＮＧ）、不正コピーが行われた可能性があるので不正に対応する処理（不正処理）を行う（ステップＳ４４）。
【００５９】
端末ＩＤと端末パスワードが正しければ（ＯＫ）、商品であるソフトウェアのリストを端末の画面に表示させ、ユーザに購入する商品の選択を行わせる（ステップＳ４５）。ユーザは表示されたリストから商品を選択し、復旧サービスの要請の場合はその旨を入力する。
【００６０】
次に、ホスト計算機はユーザからの要求が新規商品の購入か既に販売した商品の復旧要請かを判断し（ステップＳ４６）、復旧要請の場合はそのユーザの購入情報を参照して、該当する商品を過去に購入しているかどうかを調べる（ステップＳ４７）。ユーザが購入していない商品の復旧を要請している場合は（ステップＳ４７、ＮＯ）、復旧サービスの対象とならないので再びステップＳ４５の処理に戻る。
【００６１】
ユーザが過去に購入した商品の復旧を要請している場合は（ステップＳ４７、ＹＥＳ）、ホスト計算機はネットワークを介してその商品を端末に宅配し、再インストールする（ステップＳ４９）。そして、使用契約等に基づいてユーザに課金して（ステップＳ５０）、処理を終了する。ただし、無償で復旧サービスを行う契約が結ばれている場合は課金は行わない。
【００６２】
ステップＳ４６でユーザが新規商品の購入を要求している場合は、選択された商品の販売を決定し（ステップＳ４８）、ネットワークを介してその商品を端末に宅配してインストールする（ステップＳ４９）。そして、商品の代金をユーザに課金して（ステップＳ５０）、処理を終了する。
【００６３】
ステップＳ５０においては、入力されたユーザＩＤを持つユーザに対して代金が課されるが、ユーザＩＤの管理はユーザに委ねられる。各ユーザはそのユーザパスワードを指定してユーザＩＤを管理する。
【００６４】
商品の販売契約がユーザを対象とせずに、インストールする端末に対して販売することになっている場合は、ステップＳ５０において端末に対して代金が課金される。この場合は、ステップＳ４７においてその端末が該当する商品を過去に購入しているかどうかを調べ、購入していたときにのみ復旧サービスを行う。
【００６５】
また、端末ＩＤについては、ホスト計算機が端末パスワードを付加し、端末が１回接続される毎にその端末の端末パスワードを自動的に書き換えて管理する。不正コピーが行われると、書き換え前の端末パスワードと共にアクセスが行われるため、その事実を認識することが可能になる。端末ＩＤおよび端末パスワードについては、ホスト計算機がバックトレースを行うことができる。
【００６６】
図５０は、ステップＳ４３における端末パスワードのチェックと書換え、およびステップＳ４４の不正処理のフローチャートである。図５０において処理が開始されると、ホスト計算機は接続された端末の端末パスワードを、その端末の前回接続時に付与した端末パスワードと比較する（ステップＳ５１）。
【００６７】
それらが一致すれば、新しい端末パスワードを生成してその端末内に書き込み、ホスト計算機内にも保持しておく（ステップＳ５２）。このとき、ホスト計算機は例えば乱数のように予想できないものを用いて、次の端末パスワードを決定する。また、書き換えられた古い端末パスワードは後で参照するために保存しておき（ステップＳ５３）、処理を終了する。
【００６８】
ステップＳ５１で２つの端末パスワードが一致しないときは、ホスト計算機は不正コピーが行われたと判断し、接続された端末に新しい端末ＩＤを付与して新規に管理する（ステップＳ５４）。そして、接続時における端末パスワードを保存されている古い端末パスワードと順次比較して、その端末パスワードによるアクセスがあった日時を求める（ステップＳ５５）。これにより、不正コピーが行われたタイミングを特定して処理を終了する。
【００６９】
また、リモートインストールシステムにユーザが作成したソフトウェアを登録する先願の技術としては、「ソフトウェア登録システムおよび方法」（特願平７−２５８５０６）がある。
【００７０】
図５１は、このシステム内での場の構成を示している。図５１のシステムにおいては、ホスト計算機の中に仮想的につくられた、クラブと呼ばれるユーザのグループが最小単位となり、ソフトウェア情報の交換の場を形成する。クラブの構成員は会員とも呼ばれる。クラブ１２、１３、１４は同じ階層に属し、それぞれが会議室機能とリモートインストールシステム（ＲＩＳ）の機能とを持っている。
【００７１】
これらのクラブ１２、１３、１４の上位階層には上位クラブ１１がある。この例ではクラブの階層は２階層であるが、一般的には何階層でもよい。宅配されるコンテンツとなるソフトウェアは、必ず、いずれかのクラブにアップロードされ、そこに登録される。例えば、ソフトウェア１５がクラブ１２にアップロードされると、クラブ１２に最初に登録され、クラブ１２はソフトウェア１５のオリジナルクラブとなる。オリジナルクラブに登録されたソフトウェアを他のクラブに持って行くには、転載という方法と移管という方法とがある。
【００７２】
転載とは、ソフトウェアを他のクラブからも見えるようにすることを意味し、移管とは、オリジナルクラブの機能そのものを他のクラブに移すことを意味する。ソフトウェア１５を希望する会員は、オリジナルクラブ１２または転載先クラブ１１、１３のいずれかから、それをダウンロードすることができる。
【００７３】
基本的には、オリジナルクラブを選ぶ権利はソフトウェア１５を作成した会員が持っている。しかし、作者がソフトウェア１５をアップロードして、一旦公開を許可したら、それを他のクラブに転載または移管する権利はオリジナルクラブの管理者に移る。現実の運用に当たっては、アップロードした作者や各クラブの管理者の間でこれらの権利について交渉する必要があるが、コンピュータ内の仕組みとしては、それぞれの権利をあらかじめ次のように決めておく。また、作者や各管理者の義務は、契約によって例えば次のように決められる。
（１）一般作者の権利と義務
コンテンツ（ソフトウェア）をアップロードする権利
自分のアップロードしたソフトウェアを無償でテスト宅配する権利（テスト時のＲＩＳの料金が無償になる）
ソフトウェアの公開を許可する権利
自分のアップロードしたソフトウェアをサポートする義務（ソフトウェアの利用者からの質問に答えたり、エラーが発生した時の修正を行ったりする）
（２）オリジナルクラブ管理者の権利と義務
クラブ内のソフトウェアを無償でテストする権利（テスト時のソフトウェア使用料が無償になる）
ソフトウェアを公開する権利
転載先クラブに転載の許可を出す権利
クラブ内のソフトウェアをサポートする義務
上位クラブには、特別な理由が無い限り、転載の許可を出す義務。
（３）転載先クラブ管理者の権利と義務
転載が許可されたソフトウェアを公開する権利
クラブ内のソフトウェアをサポートする義務
（４）上位クラブ管理者の権利
転載が許可されたソフトウェアを公開する権利
上位クラブは、基本的に下位クラブのソフトウェアを転載することができるので、最上位のクラブの会員はすべてのソフトウェアを閲覧することができるようになる。また、転載先クラブの管理者がソフトウェアの使用方法等を確実にサポートしてくれる事を条件に転載するので、ソフトウェアが閲覧可能なクラブ内で、そのサポートが必ず受けられる。
【００７４】
ここで、図５２から図５４までを参照しながら、ソフトウェア登録システムにおける作者や管理者の作業の手順について説明する。
図５２は、作者の作業のフローチャートである。作業が開始されると、作者は、まずソフトウェアを作成し、アップロードに必要なファイル群を用意する（ステップＳ６１）。次に、アップロードするクラブを選択し、コマンドＵＰＬＯＡＤによりソフトウェアをアップロードして（ステップＳ６２）、アップロード先での自動チェックの結果を受け取る（ステップＳ６３）。
【００７５】
ここでは、誤動作チェック、ウィルスチェック、著作権や商標権のチェック等が自動的に行われる。チェックの結果（ステップＳ６４）、エラーが発生すればエラー部分を修正し、修正部分のみ再びアップロードして（ステップＳ６５）、ステップＳ６３以降の作業を繰り返す。
【００７６】
そして、自動チェックが通ったら、次にＲＩＳによりテスト宅配を行う（ステップＳ６６）。テスト宅配では、アップロードされたソフトウェアがリモートインストール時に問題を起こさないかどうかがチェックされる（ステップＳ６７）。テスト宅配でエラーが発生すればエラー部分を修正し、その部分のみ再びアップロードして（ステップＳ６８）、ステップ６６以降の作業を繰り返す。テスト宅配で合格したら、ＰＵＳＨによりソフトウェアの公開を許可し（ステップＳ６９）、作業を終了する。
【００７７】
図５３は、オリジナルクラブの管理者の作業のフローチャートである。作業が開始されると、管理者は、まず作者により公開を許可されているソフトウェアをテスト宅配し（ステップＳ７１）、問題が無いかチェックする（ステップＳ７２）。テスト宅配で問題がなければ、コマンドＰＵＢＬＩＳＨによりソフトウェアをオリジナルクラブの会員に公開し（ステップＳ７３）、問題があればそれを作者に連絡して（ステップＳ７４）、作業を終了する。
【００７８】
図５４は、転載先クラブの管理者の作業のフローチャートである。作業が開始されると、管理者は、希望するソフトウェアがあったら、その転載許可をオリジナルクラブに依頼する（ステップＳ８１）。依頼に対する応答を受け取り（ステップＳ８２）、転載が許可されなければそのまま作業を終了する。コマンドＰＥＲＭＩＴにより転載が許可されれば、コマンドＬＩＮＫによりそのソフトウェアを自分のクラブに転載する（ステップＳ８３）。この時、自分のクラブで検索しやすいようにキーワードを変更しておく。
【００７９】
次に、転載したソフトウェアをテスト宅配し（ステップＳ８４）、問題が無いかチェックする（ステップＳ８５）。テスト宅配で問題がなければ、コマンドＰＵＢＬＩＳＨによりソフトウェアをクラブの会員に公開し（ステップＳ８６）、問題があればそれをオリジナルクラブに連絡して（ステップＳ８７）、作業を終了する。
【００８０】
ところで、パソコン通信で流通しているソフトウェアには、様々な種類のものがある。例えば、フリーウェアと呼ばれるものは基本的に無料で配布され、シェアウェアと呼ばれるものは機能制限付きで一旦無料で送付された後、所定の代金が送金されれば機能制限が解除されることになっている。また、商品として販売されているものは、基本的に代金と引き換えに送付される。
【００８１】
配送センターがリモートインストールの機能を利用して、ソフトウェアをユーザに販売するサービスを行う場合、このような多様な販売形態に対応して、代金を確実に受け取ることを保証する機構が必要になる。このような代金の決裁に関する先願としては、「ソフトウェア代金決裁システムおよび方法」（特願平７−２５８５０７）がある。
【００８２】
図５５は、このシステムで用いられるファイル群のアップロード処理の例を示している。シェアウェアの作者は、まず本体登録ファイルとして、ＣＦＧファイル２１（ＡＡＡ．ＣＦＧ）、説明ファイル２２（ＡＡＡ．ＴＸＴ）、インストール関連ファイル２３（ここではアイコンファイルＩＣＯＮ．ＤＥＦ）、および本体ファイル２４（ＡＡＡ．ＬＺＨ）を自分の端末からアップロードする。
【００８３】
ホスト計算機は、これらのアップロード情報をコンテンツデータベース２８に登録する。ここでは、アップロードされたソフトウェア「ＡＡＡスケジューラ」のソフトコード、名称、タイプ（ＴＹＰＥ）、本体ファイル名、説明ファイル名、アイコンファイル名等が管理情報として登録されている。タイプの欄のＳＨＡＲＥはソフトウェアの種類がシェアウェアであることを表す。コンテンツデータベース２８は、例えば、ホスト計算機内または外部のディスク装置内に設けられる。
【００８４】
次に、作者は送金手続きファイルとして、定義ファイル２５（ＡＡＡＳ．ＣＦＧ）、ＣＨＫファイル２６（ＡＡＡＳ．ＣＨＫ）、および書換えファイル２７（ＩＮＩ．ＤＥＦ）をアップロードする。これにより、送金手続きファイルＡＡＡＳのソフトコード、名称、タイプ、ＣＨＫファイル名、後処理用のファイル名等がコンテンツデータベース２８に登録される。
【００８５】
後処理用のファイルとして、ここでは、書換えファイル２７のファイル名ＩＮＩ．ＤＥＦが記されている。また、タイプの欄のＳＯＫＩＮ＃ＲＩＳは、ソフトウェアの種類がシェアウェアの送金手続きファイルであることを表し、ＡＡＡＳ．ＣＦＧの［ｉｎｓｔｙｐｅ］セクションに記述された情報に対応している。
【００８６】
次に、図５６、５７、５８、５９を参照しながら、アップロードされたファイル群を用いたシェアウェアの送金手続きについて説明する。シェアウェア手続きにおいては、上述のリモートインストールの手続きに加えて、プロトコル上に送金フラグを設ける。そして、端末からこのフラグを立ててソフトウェアの検索を要求することにより、シェアウェア手続きを選択できるようにする。また、端末の画面に送金フラグをＯＮ／ＯＦＦするメニューを表示させる。
【００８７】
この例において、シェアウェア「ＡＡＡスケジューラ」は、送金手続きの前に、機能制限付きでユーザシステムにインストールされているものとする。ユーザがこのソフトウェアを購入しようとした時は、ホスト計算機と端末の間で次のようなコマンド／レスポンスのやりとりを行う。
【００８８】
端末は、まずユーザ環境をホスト計算機に送信し（図５６、ステップＳ９１）、ホスト計算機はこれを受信すると応答を返す（ステップＳ９２）。次に、ユーザがソフトウェア検索用のキーワードリストを要求すると（ステップＳ９３）、ホスト計算機はキーワードリストを返送する（ステップＳ９４）。
【００８９】
このとき、図５７に示すように、端末の画面上にはオプション手続きのメニュー２９が表示され、ユーザはその中から「送金」を指定し、キーワードリストの中からキーワードを選択する。これにより、送金フラグＳＯＫＩＮが立てられ（オンになり）、シェアウェアの検索を開始する指示がホスト計算機に送られる（図５７、ステップＳ９５）。
【００９０】
ホスト計算機は、指定されたキーワードでコンテンツデータベース２８を検索し、タイプがＳＯＫＩＮで始まるソフトウェアの名称とその送金手続きファイル（送金ソフト）のソフトコードとを返す（ステップＳ９６）。ここでは、「ＡＡＡスケジューラ」、「ＢＢＢスケジューラ」等の名称および送金ソフトのソフトコード４０００、４００１等が返送されている。
【００９１】
端末は送金ソフトのみリスティングし、ユーザはリスティングされた中の特定の送金ソフトを指定する（ステップＳ９７）。ここでは、ソフトコード４０００が指定されている。ホスト計算機は、ソフトコード４０００の送金ソフトの条件により端末側とネゴシエーションを行う（ステップＳ９８）。ここでは、まず、コマンドＳＴ４を用いて、ユーザシステム内に格納された初期設定ファイルＡＡＡ．ＩＮＩの位置を調べるように端末に指示する。
【００９２】
これを受けて、端末はＡＡＡ．ＩＮＩの場所を調べ、その場所はＥ：￥ＡＡＡということをホスト計算機に通知する（ステップＳ９９）。ＳＴ４というコマンドは、あらかじめ端末側に具備されているものとする。
【００９３】
次に、ホスト計算機はダイアログＢＯＸ３０を端末の画面に表示させ、ＡＡＡ．ＩＮＩの位置はＥ：￥ＡＡＡでよいかどうかをユーザに確認する（図５８、ステップＳ１００）。ダイアログＢＯＸ３０に表示されたディレクトリが正しければ、ユーザはそのディレクトリをそのまま返送し（ステップＳ１０１）、ホスト計算機は、ユーザシステムの書き換えるべきファイルのディレクトリパスはＥ：￥ＡＡＡ￥ＡＡＡ．ＩＮＩと確定する。
【００９４】
もし、表示されたディレクトリが正しくなければ、ユーザは正しいディレクトリ名を入力する。例えばＧ：￥ＧＧＧと入力すると、端末はディレクトリパスＧ：￥ＧＧＧ￥ＡＡＡ．ＩＮＩをホスト計算機に返す。ＡＡＡ．ＩＮＩの格納場所が確定したので、ホスト計算機は、シェアウェア送金が可能であることを端末に通知する（ステップＳ１０２）。
【００９５】
次に、ユーザは機能制限の解除を要求する（図５９、ステップＳ１０３）。これを受けて、ホスト計算機は、定義ファイル２５の［ｉｎｓｔｙｐｅ］セクションを参照し、代金をそのユーザの口座等から引き落とした後に、ＡＡＡ．ＩＮＩの書換え手順が記述されている書換えファイルＩＮＩ．ＤＥＦを送付する。さらに、定義ファイルの［ｌａｓｔ］セクションを参照して後処理のコマンドＣＨＧＩＮＩを送り、ＩＮＩ．ＤＥＦの手順に従って書換えを行うことを端末に指示する。
【００９６】
これを受けて、端末はダウンロードされたＩＮＩ．ＤＥＦを参照し、ＡＡＡ．ＩＮＩを書換える。これにより、シェアウェア「ＡＡＡスケジューラ」の機能制限が解除され、ユーザシステム上で完全に動作するようになる。その後、ホスト計算機はＩＮＩ．ＤＥＦを端末から削除して、処理を終了する。
【００９７】
この例では、定義ファイル２５の［ｉｎｓｔｙｐｅ］のセクションにその場で制限解除を行うという情報が記されていたので、代金の引き落としと同時にシェアウェアの機能制限を解除した。しかし、一般のパソコン通信センターと同様に、ホスト計算機が代金引き落としとシェアウェア登録者への電子メールの発行だけを行う構成とすることもできる。
【００９８】
図６０、６１、６２は、このようなソフトウェア「ＢＢＢスケジューラ」の代金引き落とし手続きを示している。ただし、この手続きの前に、シェアウェア「ＢＢＢスケジューラ」は機能制限付きでユーザシステムにインストールされているものとする。ユーザがこのソフトウェアを購入しようとした時は、ホスト計算機と端末の間で次のようなコマンド／レスポンスのやりとりを行う。
【００９９】
端末は、まずユーザ環境をホスト計算機に送信し（図６０、ステップＳ１１１）、ホスト計算機はこれを受信すると応答を返す（ステップＳ１１２）。次に、ユーザがソフトウェア検索用のキーワードリストを要求すると（ステップＳ１１３）、ホスト計算機はキーワードリストを返送する（ステップＳ１１４）。
【０１００】
このとき、図６１に示すように、端末の画面上にはオプション手続きのメニュー２９が表示され、ユーザはその中から「送金」を指定し、キーワードリストの中からキーワードを選択する。これにより、送金フラグＳＯＫＩＮが立てられ、シェアウェアの検索を開始する指示がホスト計算機に送られる（図６１、ステップＳ１１５）。
【０１０１】
ホスト計算機は、指定されたキーワードでコンテンツデータベース２８を検索し、タイプがＳＯＫＩＮで始まるソフトウェアの名称とその送金ソフトのソフトコードとを返す（ステップＳ１１６）。端末は送金ソフトのみリスティングし、ユーザはリスティングされた中からソフトコード４００１の送金ソフトを指定する（ステップＳ１１７）。
【０１０２】
次に、ホスト計算機はメッセージ３１を端末の画面に表示させ、課金してよいかどうかをユーザに確認する（図６２、ステップＳ１１８）。このとき、ホスト計算機は、定義ファイルの［ｉｎｓｔｙｐｅ］セクションを参照し、フラグＳＯＫＩＮの値をメール発行のみを表す「０ｘ０８」に変更して、端末に返送する。
【０１０３】
ユーザは、課金されてもよければＯＫを、購入しない場合はＮＧを選択する。ここでは、ＯＫが選択され、登録者に対するメールの発行の依頼が端末からホスト計算機に送られる（ステップＳ１１９）。
【０１０４】
これを受けて、ホスト計算機は代金をそのユーザの口座等から引き落とし、「ＢＢＢスケジューラ」の登録者に代金引き落としを知らせる電子メールを送る。メールの送付先としては、定義ファイルの［ｔｙｐｅ］セクションに記述された送金先ＦＪＯＫＩを用いる。
【０１０５】
ホスト計算機から電子メールを受け取った登録者は、電子メール等の手段により、ソフトウェアの購入者に機能制限解除の方法を連絡する。これにより、購入者は「ＢＢＢスケジューラ」のすべての機能を使用することができるようになる。
【０１０６】
【発明が解決しようとする課題】
しかしながら、上述のような従来のリモートインストールシステムには、次のような問題がある。
【０１０７】
販売されるソフトウェアは秘密の情報であるため、セキュリティの確保された回線を介して宅配する必要がある。したがって、あらかじめセキュリティの確保が保証されないインターネット上に適用するためには、ハッキング防止のための対策を施す必要がある。
【０１０８】
また、インターネット上の情報探索用ソフトウェアツールであるＷＷＷブラウザ（ｗｏｒｌｄ　ｗｉｄｅ　ｗｅｂ　ｂｒｏｗｓｅｒ）と、リモートインストールシステムとの連携方法としては、様々な機構が考えられ、提供するサービスに応じて適した機構を構築する必要がある。
【０１０９】
また、従来のリモートインストールシステムにおける端末のマシンＩＤは、ホスト計算機がただ一つしか存在しないことを前提として作成／管理されている。このため、複数のホスト計算機をＲＩＳサーバとしてサービスを行うと、同じマシンＩＤを各ホスト計算機がそれぞれ異なる端末に付与する可能性がある。この場合、ホスト計算機が端末を誤って識別するという問題が生じる。
【０１１０】
さらに、インターネット上では識別情報等も盗用される恐れがあるため、通信相手を正確に識別することが困難である。このため、第３者が不正に入手した識別情報を利用して、ＲＩＳのホスト計算機になりすますことができる。このような場合、ユーザがそれを見破ることができる必要がある。
【０１１１】
本発明の課題は、インターネット上でリモートインストールシステムを利用して、安全かつ適切な会員制サービスを実現するシステムおよびその方法を提供することである。
【０１１２】
【課題を解決するための手段】
図１は、本発明のサービスシステムの原理図である。図１のサービスシステムは、本発明の第１、第２、第３、第４、第５、第６、第７、第８、第９、第１０、および第１１の原理を含む。
【０１１３】
第１の原理において、サービスシステムは、登録手段８０、キー情報付与手段８１、および暗号化手段８２を備え、ソフトウェア配送サービスを提供する。登録手段８０は、セキュリティの確保された通信路を介して、クライアントのサインアップを行い、キー情報付与手段８１は、上記サインアップの過程で、上記クライアントのマシン識別子に対応したキー情報を付与する。そして、暗号化手段８２は、上記キー情報を用いて、インターネット上でのパスワードとソフトウェアコンテンツのうち少なくとも一方の暗号化を行う。
【０１１４】
暗号化に用いられるキー情報は、セキュリティの確保された通信路を介してやり取りされるので、盗用されることがない。こうして付与された秘密のキー情報を用いてパスワードを暗号化することで、インターネット上において、リモートインストールシステムへのログインシーケンスのセキュリティを高めることができる。また、このキー情報を用いてコンテンツを暗号化することで、インターネット上において、リモートインストールのシーケンスのセキュリティを高めることができる。
【０１１５】
第２の原理において、サービスシステムは、リモートインストール手段８３とブラウザ手段８８を備え、ソフトウェア配送サービスを提供する。リモートインストール手段８３は、ホームページ上のアンカーファイルにより指定されるソフトウェアを、自動的にサーバからクライアントに配送し、ブラウザ手段８８は、上記アンカーファイルがアクセスされたとき、自動的にリモートインストール手段８３を起動する。
【０１１６】
ブラウザ手段８８がリモートインストール手段８３を起動することで、ユーザが指定したソフトウェアが自動的に配送される。したがって、ユーザはリモートインストール手段８３を意識することなく、インターネットのホームページ上でリモートインストールサービスを利用することができる。
【０１１７】
第３の原理において、サービスシステムは、課金手段８４とブラウザ手段８８を備え、オンラインショッピングサービスを提供する。課金手段８４は、自動的にクライアントからサーバへ接続して、ホームページ上のアンカーファイルにより指定される商品またはサービスの課金処理を行い、ブラウザ手段８８は、上記アンカーファイルがアクセスされたとき、自動的に課金手段８４を起動する。
【０１１８】
課金手段８４としては、例えばリモートインストールシステムが用いられ、ブラウザ手段８８が課金手段８４を起動することで、ユーザが指定した商品またはサービスの課金が自動的に行われる。したがって、インターネット上でリモートインストールシステムを利用したオンラインショッピングサービスが実現される。
【０１１９】
第４の原理において、サービスシステムは、処理手段８５とブラウザ手段８８を備え、通信サービスを提供する。処理手段８５は、ホームページ上のアンカーファイルにより指定される通信サービスの課金処理を行い、その通信サービスを利用するために必要な情報を、自動的にサーバからクライアントへ送る。また、ブラウザ手段８８は、上記アンカーファイルがアクセスされたとき、自動的に処理手段８５を起動する。
【０１２０】
処理手段８５としては、例えばリモートインストールシステムが用いられ、ブラウザ手段８８が処理手段８５を起動することで、ユーザが指定した通信サービスの課金と、そのサービスを利用するために必要な情報の提供が自動的に行われる。したがって、インターネット上でリモートインストールシステムを利用した通信サービスが実現される。
【０１２１】
第５の原理において、サービスシステムは、ヘルパ手段８６、処理手段８７、およびブラウザ手段８８を備え、トランザクションサービスを提供する。ブラウザ手段８８は、インターネットにアクセスし、ヘルパ手段８６は、ブラウザ手段８８により起動され、トランザクションサービスの一部の処理を行う。また、処理手段８７は、ブラウザ手段８８により起動され、ヘルパ手段８６と連携して、トランザクションの使用権の付与および課金に関する処理を行う。
【０１２２】
処理手段８７としては、例えばリモートインストールシステムが用いられ、ブラウザ手段８８がヘルパ手段８６と処理手段８７を起動し、ヘルパ手段８６と処理手段８７が連携することで、ユーザに対するトランザクション処理の使用権の付与と課金とが自動的に行われる。したがって、インターネット上でリモートインストールシステムを利用したトランザクションサービスが実現される。
【０１２３】
第６の原理において、サービスシステムは、処理手段８９とトランザクション手段９１を備え、トランザクションサービスを提供する。トランザクション手段９１は、トランザクションサービスの処理を行い、処理手段８９は、トランザクション手段９１により起動され、トランザクション手段９１と連携して、トランザクションの使用権の付与および課金に関する処理を行う。
【０１２４】
処理手段８９としては、例えばリモートインストールシステムが用いられ、トランザクション手段９１が処理手段８９を起動し、それと連携することで、ユーザに対するトランザクション処理の使用権の付与と課金とが自動的に行われる。したがって、ブラウザを介することなく、リモートインストールシステムを利用したトランザクションサービスが実現される。
【０１２５】
第７の原理において、サービスシステムは、処理手段９０とトランザクション手段９１を備え、トランザクションサービスを提供する。トランザクション手段９１は、トランザクションサービスの処理を行い、処理手段９０は、トランザクション手段９１により起動され、自動的にクライアントからサーバへ接続して、上記トランザクションサービスに必要なデータを取得する。
【０１２６】
処理手段９０としては、例えばリモートインストールシステムが用いられ、トランザクション手段９１が処理手段９０を起動する。処理手段９０はサーバからデータを取得してトランザクション手段９１に渡し、トランザクション手段９１は、そのデータを用いてトランザクションサービスの処理を行う。したがって、ブラウザを介することなく、リモートインストールシステムを利用したトランザクションサービスが実現される。
【０１２７】
第８の原理において、サービスシステムは、受信手段９２と判定手段９３を備える。受信手段９２は、クライアントから、サーバ識別子とクライアント識別子を合成して生成されたマシン識別子を受け取る。そして、判定手段９３は、上記マシン識別子をサーバ部とクライアント部に分解し、そのサーバ部に記述されたサーバ識別子をチェックして、上記クライアントとの接続が正しいかどうかを判定する。
【０１２８】
クライアントがマシン識別子にサーバ識別子を混ぜて送ることで、判定手段９３は、その接続要求がどのサーバに対するものかを特定することができる。そして、サーバ識別子に対応するサーバが、クライアントの正しい接続先と判定される。したがって、複数のサーバがサービスを提供する環境において、同じクライアント識別子が２つ以上のクライアントに付与された場合でも、サーバがクライアントを確実に識別することが可能になる。
【０１２９】
第９の原理において、サービスシステムは、生成手段９４、格納手段９５、および接続手段９６を備える。生成手段９４は、サーバ識別子とクライアント識別子を合成して、クライアントのマシン識別子を生成し、格納手段９５は、そのマシン識別子を格納する。そして、接続手段９６は、そのマシン識別子を用いてサーバに接続する。
【０１３０】
生成手段９４がサーバ識別子を含むマシン識別子を生成し、接続手段９６がそのマシン識別子を用いてサーバに接続することで、サーバは、その接続要求がどのサーバに対するものかを特定することができる。したがって、第８の原理と同様に、サーバがクライアントを確実に識別することが可能になる。
【０１３１】
第１０の原理において、サービスシステムは、通信手段９７と認証手段９８を備える。通信手段９７は、サーバへのログイン時に、そのサーバの認証鍵に基づく電子署名機能を用いて暗号化された指定情報を送受信し、認証手段９８は、その指定情報を介してサーバの認証を行う。
【０１３２】
サーバは、例えばリモートインストールサービスを提供し、ログインシーケンスにおいて、クライアントから指定された情報を秘密鍵で暗号化して送り返す。認証手段９８は、その指定情報を対応する公開鍵で復号化し、その結果に基づいてサーバが正しいかどうかを判断する。復号化された情報が元の指定情報と一致すれば、サーバは正しいと判定される。
【０１３３】
正しいサーバのみが正しい暗号化を行うことができるので、インターネット上において、クライアントがサーバを確実に識別することが可能になる。また、クライアントが公開鍵で暗号化した指定情報をサーバに送り、サーバがそれを秘密鍵で復号化して送り返しても、同様の効果が得られる。
【０１３４】
第１１の原理において、サービスシステムは、格納手段９９と接続手段１００を備え、リモートインストールサービスを提供する。格納手段９９は、クライアント側に設けられ、インターネット上におけるサーバのアドレス情報を格納し、接続手段１００は、上記アドレス情報を用いて、自動的に上記クライアントから上記サーバに接続する。
【０１３５】
リモートインストールシステムのサーバのアドレス情報（ドメイン名やポート番号）が、ホームページ上ではなく、ユーザ端末内の格納手段９９に格納されているので、他のユーザに知られることがない。このアドレス情報を、ＲＩＳ会員になったユーザの端末にのみ格納することで、インターネット上において、会員制のリモートインストールサービスが実現される。
【０１３６】
このように、図１のサービスシステムによれば、インターネット上でリモートインストールシステムを利用した様々な会員制サービスを、安全かつ適切に提供することが可能になる。
【０１３７】
図１の登録手段８０、キー情報付与手段８１、暗号化手段８２、リモートインストール手段８３、ブラウザ手段８８、課金手段８４、処理手段８５、ヘルパ手段８６、処理手段８７、処理手段８９、処理手段９０、トランザクション手段９１、受信手段９２、判定手段９３、生成手段９４、接続手段９６、格納手段９５、通信手段９７、認証手段９８、格納手段９９、および接続手段１００は、例えば、後述する図２におけるホスト計算機１１１およびユーザ端末１１３の持つ機能に対応する。
【０１３８】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を詳細に説明する。
図２は、実施形態のサービスシステムの構成図である。図２のサービスシステムは、インターネット１１７に接続されたホスト計算機１１１およびユーザ端末１１３を備える。ホスト計算機１１１とユーザ端末１１３は、インターネット１１７以外にも、セキュリティの確保された通信路（パイプ）であるＦＥＮＩＣＳ回線１１６を介して互いに接続されている。
【０１３９】
ホスト計算機１１１は、リモートインストールサービスを提供するソフトウェアとして、ＲＩＳサーバ１１２を搭載し、ユーザ端末１１３は、ＷＷＷブラウザ１１４の他に、リモートインストールサービスを利用するソフトウェアとして、ＲＩＳクライアント１１５を搭載する。
【０１４０】
図３は、図２のホスト計算機１１１およびユーザ端末１１３に対応する情報処理装置（コンピュータ）の構成図である。図３の情報処理装置は、ＣＰＵ（中央処理装置）１２１、メモリ１２２、入力装置１２３、出力装置１２４、外部記憶装置１２５、媒体駆動装置１２６、ネットワーク接続装置１２７を備え、それらの各装置はバス１２８により互いに結合されている。
【０１４１】
ＣＰＵ１２１は、メモリ１２２を利用してプログラムを実行し、サービスに必要な処理を実現する。メモリ１２２には、サービスに必要なプログラムとデータが格納され、メモリ１１２としては、例えばＲＯＭ（ｒｅａｄ　ｏｎｌｙ　ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ　ａｃｃｅｓｓ　ｍｅｍｏｒｙ）等が用いられる。
【０１４２】
入力装置１２２は、例えばキーボード、ポインティングデバイス等に相当し、ユーザからの要求や指示の入力に用いられる。また、出力装置１２４は、表示装置やプリンタ等に相当し、サービス画面等の出力に用いられる。
【０１４３】
外部記憶装置１２５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置等である。この外部記憶装置１２５に、上述のプログラムとデータを格納しておき、必要に応じて、メモリ１２２にロードして使用することもできる。また、外部記憶装置１２５はデータベースとしても使用される。
【０１４４】
媒体駆動装置１２６は、可搬記録媒体１２９を駆動し、その記憶内容にアクセスする。可搬記録媒体１２９としては、メモリカード、フレキシブルディスク、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ　ｄｉｓｋ　ｒｅａｄ　ｏｎｌｙ　ｍｅｍｏｒｙ　）、光ディスク、光磁気ディスク等、任意のコンピュータ読み取り可能な記録媒体を使用することができる。この可搬記録媒体１２９に、上述のプログラムとデータを格納しておき、必要に応じて、メモリ１２２にロードして使用することもできる。
【０１４５】
ネットワーク接続装置１２７は、ＦＥＮＩＣＳ回線１１６やインターネット１１７への接続に用いられ、通信に伴うデータ変換等を行って、他の情報処理装置（ホスト計算機１１１またはユーザ端末１１３）との間でプログラムやデータの送受信を行う。また、情報処理装置は、外部の情報提供者のデータベース１３０等からネットワークを介して、上述のプログラムとデータを受け取り、必要に応じて、メモリ１２２にロードして使用することもできる。
【０１４６】
本実施形態では、システムへの登録手続き（サインアップ）は、必ずセキュリティの確保されたパイプで行う。そして、サインアップの過程で、ＲＩＳサーバ１１２は、ユーザＩＤ／パスワードおよびマシンＩＤ／パスワードとともに、マシンＩＤに対応したインターネット用の暗号キーをＲＩＳクライアント１１５に付与する。この暗号キーを用いて、インターネット上でのパスワードおよびコンテンツの暗号化／復号化が行われる。
【０１４７】
このようなサービスを実現するため、図４７、４８のサインアップのシーケンスに図４に示すようなシーケンスを追加し、ＲＩＳサーバ１１２が、端末（マシン）１１３にユニークに対応した秘密キー（例えばＤＥＳキー）を、端末１１３に付与する。
【０１４８】
図４において、ＲＩＳクライアント１１５が、マシンＩＤ（ＭＩＤ）なしでコマンドＲＥＳ　ＳＥＮＤＥＮＶをＲＩＳサーバ１１２に送ると、ＲＩＳサーバ１１２は、秘密キーデータベース１３１を参照してレスポンスを返す。秘密キーデータベース１３１には、あらかじめＭＩＤと秘密キーの対応表が格納されている。
【０１４９】
ここでは、レスポンスとして、ＭＩＤ＝１２３４、ＭＰＳＷＤ＝ＡＳＤＦ、ＫＥＹ＝９８７６がＲＩＳクライアント１１５に返される。このうち、ＫＥＹが秘密キーに対応する。ＲＩＳクライアント１１５は、受け取ったこれらの情報を初期設定ファイル１３２（ＲＩＳ．ＩＮＩ）に書き込んで保存する。
【０１５０】
さらに、この初期設定ファイル１３２には、図５に示すように、インターネット１１７を介してＲＩＳサーバ１１２に接続するためのアドレス（ドメイン名）およびＴＣＰ／ＩＰ（ｔｒａｎｓｍｉｓｓｉｏｎ　ｃｏｎｔｒｏｌ　ｐｒｏｔｏｃｏｌ／ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ　）のポート番号が記述されている。
【０１５１】
これらのアドレスとポート番号は、ユーザがＲＩＳ会員になって、ＲＩＳクライアント１１５が端末１１３にインストールされた時に、端末１１３の初期設定ファイル１３２に書き込まれる。アドレス情報が、インターネット上ではなく、ＲＩＳクライアント１１５側に保持されているので、会員以外の他のユーザにハッキングされることはない。したがって、ＲＩＳ会員のみがＲＩＳサーバ１１２にアクセスすることができる。
【０１５２】
このアドレス情報を用いたインターネット１１７でのログインは、図６に示すようなシーケンスにて行われる。ＲＩＳサーバ１１２からユーザＩＤ（ＵＩＤ）の入力指示を受け取ると、ＲＩＳクライアント１１５は、まず、ＵＩＤとともにＭＩＤを送出する。
【０１５３】
ＲＩＳサーバ１１２は、Ｃｈａｌｌｅｎｇｅ発生関数１３３を用いて、毎回異なる乱数Ｃｈａｌｌｅｎｇｅを生成し、ＲＩＳクライアント１１５に送る。この乱数はＲＩＳサーバ１１２の識別情報として送られるが、毎回異なるため、他人がハッキングして使用することができない。したがって、他のサーバがＲＩＳサーバ１１２になりすますことを防止できる。
【０１５４】
ＲＩＳクライアント１１５は、合成関数１３４を用いて、ＲＩＳサーバ１１２から送られたＣｈａｌｌｅｎｇｅとサインアップ時に取得したＫＥＹとを合成し、暗号化キーを生成する。合成関数１３４としては、例えばＥＯＲ（ｅｘｃｌｕｓｉｖｅｏｒ）が用いられる。そして、その暗号化キーをＤＥＳ（Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）アルゴリズムの秘密キー（ＤＥＳキー）として用いて、ユーザパスワードを暗号化プログラム１３５により暗号化し、ＲＩＳサーバ１１２に送出する。
【０１５５】
ＲＩＳサーバ１１２は、ＲＩＳクライアント１１５に送ったＣｈａｌｌｅｎｇｅおよびＫＥＹから同様にしてＤＥＳキーを合成する。そして、復号化プログラム１３６により、暗号化されたユーザパスワードを復号化し、ユーザパスワードの確認を行う。ユーザパスワードが暗号化されてやり取りされるため、インターネット１１７上でのログイン時において、ユーザパスワードの盗用が防止される。
【０１５６】
また、インターネット１１７上のコンテンツの配送においては、図４４、４５、４６の従来のリモートインストール方法を図７に示すように拡張する。まず、ＲＩＳクライアント１１５が、インターネット１１７を介して、セキュリティを要求されるコンテンツのデストリビューションを要求すると、ＲＩＳサーバ１１２は、代金の与信を行う。
【０１５７】
次に、ＲＩＳサーバ１１２は、圧縮されたコンテンツファイルＡＢＣ．ＬＺＨを、ＭＩＤに対応する秘密キーを用いて暗号化プログラム１３５により暗号化し、ＲＩＳクライアント１１５にダウンロードする。そして、暗号化されたコンテンツファイルＡＢＣ．ＤＥＳを復号化するコマンドを送る。
【０１５８】
ＲＩＳクライアント１１５は、コンテンツファイルＡＢＣ．ＤＥＳを、保持しているＫＥＹを用いて復号化プログラム１３６により復号化し、ファイルＡＢＣ．ＬＺＨを取り出す。次に、ＲＩＳサーバ１１２からのコマンドに従って、ファイルＡＢＣ．ＬＺＨを解凍し、実行用ファイルＡＢＣ．ＥＸＥを生成する。その後、ＡＢＣ．ＤＥＳとＡＢＣ．ＬＺＨは自動的に消去される。
【０１５９】
このように、あらかじめセキュリティの確保された通信路を介して秘密キーを送ることで、ＤＥＳアルゴリズムのように堅牢な暗号化アルゴリズムを採用することが可能になる。また、暗号化アルゴリズムとしては、秘密キーを用いる他の任意のアルゴリズムを用いることができる。
【０１６０】
次に、ブラウザのヘルパ・アプリケーションを起動することにより、指定されたソフトウェアを配送するリモートインストールシステムについて述べる。このシステムでは、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４にヘルパ・アプリケーションとしてあらかじめ登録しておく。ここで、ヘルパ・アプリケーションとは、ＷＷＷブラウザ１１４からキックされて起動し、それに組み込まれた機能以外の形式のファイルを表示することのできるプログラムを意味する。
【０１６１】
そして、ホームページ上にヘルパ起動のためのアンカーファイルを置き、そのアンカーファイルをユーザがポインティング・デバイスでクリックすると、ＲＩＳクライアント１１５が自動的にＲＩＳサーバ１１２に接続し、指定のソフトウェアが配送されるようにする。
【０１６２】
図８は、このようなインターネット１１７上のソフトウェア配送システムを示している。ソフトウェアのベンダであるソフト工房１４１は、インターネット１１７上にホームページ１４２を開き、自社の開発したソフトウェアの宣伝を行う（処理Ｐ１）。それとともに、自社の開発したソフトウェアを、図５１、５２に示した先願の方法でＲＩＳサーバ１１２に登録する（処理Ｐ１）。
【０１６３】
このホームページ１４２を構成するＨＴＭＬ（ｈｙｐｅｒｔｅｘｔ　ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ　）ファイルは、図９のように記述される。これにより、“競馬ソフト”、“パチンコソフト”等のソフトウェア名とそれらの配送を受けるための選択ボタン（Ｒｉｓアイコン）が表示される。これらのＲｉｓボタンには、それぞれヘルパ起動のためのアンカーファイルがリファレンスとして設定されている。
【０１６４】
例えば、“競馬ソフト”のＲｉｓアイコン１４３には、図１０に示すようなアンカーファイル１４４（ＫＥＩＢＡ．ＲＩＳ）がリンクされている。このＫＥＩＢＡ．ＲＩＳの［ＲＩＳ］セクションには、ソフトウェア名とソフトウェア番号（Ｓｏｆｔ）とが記述される。
【０１６５】
また、アンカーファイル１４４におけるＷＷＷサーバのＭＩＭＥ（ｍｕｌｔｉｐｕｒｐｏｓｅ　ｉｎｔｅｒｎｅｔ　ｍａｉｌ　ｅｘｔｅｎｓｉｏｎｓ　）設定として、ファイルタイプ“．ＲＩＳ”がＭＩＭＥタイプ“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｒｉｓ”に対応付けられる。ＭＩＭＥとは、ＷＷＷにおいて様々なファイル形式を扱うための方法である。これにより、ＷＷＷブラウザ１１４がこのリファレンスを参照してきたとき、対応するＷＷＷサーバが、ＭＩＭＥタイプとして“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｒｉｓ”を返すようになる。
【０１６６】
ユーザ側は、図４７、４８、４の方法にて、ＲＩＳ会員として既にユーザＩＤ／パスワードおよびマシンＩＤ／パスワードが付与されているものとする。また、ＷＷＷブラウザ１１４に、ＲＩＳクライアント１１５をヘルパ・アプリケーションとして登録しておく。
【０１６７】
例えば、ＷＷＷブラウザ１１４としてＮｅｔｓｃａｐｅを用いた場合は、Ｆｉｌｅ−Ｔｙｐｅとして“．ＲＩＳ”を登録し、ＭＩＭＥ−ＴＹＰＥとして“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｒｉｓ”を登録する。また、ＲＩＳクライアント１１５を起動するＬａｕｎｃｈアプリケーションとして、“Ｃ：￥ＲＩＳＷ４１０￥ＲＩＳＷＩＮ３２￥ＲＩＳＡＮＣ３２．ＥＸＥ”と登録する。
【０１６８】
この状態で、ユーザがソフト工房ホームページ１４２にアクセスし（処理Ｐ２）、“競馬ソフト”の横のＲｉｓアイコン１４３を、ポインティング・デバイスでクリックしたとする（処理Ｐ３）。このとき、ＷＷＷブラウザ１１４は、自動的にＲＩＳクライアント１１５を起動し、ＲＩＳクライアント１１５にファイルＫＥＩＢＡ．ＲＩＳの内容を渡す（処理Ｐ４）。
【０１６９】
起動されたＲＩＳクライアント１１５は、図６に示した方法でＲＩＳサーバ１１２に接続する（処理Ｐ５）。そして、ログイン後は、図１１に示すように、図４４、４５、４６と同様のシーケンスで、ＲＩＳサーバ１１２がソフトウェアのデストリビューションを行う。このとき、ファイルＫＥＩＢＡ．ＲＩＳから抽出されたソフトウェア番号が、ＲＩＳクライアント１１５からＲＩＳサーバ１１２に送られ、それに対応するソフトウェアが自動的に端末１１３に配送される。
【０１７０】
以上の操作が行われると、ＲＩＳサーバ１１２上のデータベースには、図１２の購入テーブルおよび図１３の支払いテーブルに記述されたような購入履歴が残る。そこで、ＲＩＳサーバ１１２は、この購入テーブルを元に、クレジット会社経由で購入者から代金を徴収し、支払いテーブルを元に、ベンダに払いもどしを行う（処理Ｐ６）。
【０１７１】
このように、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４から起動されるヘルパ・アプリケーションとして登録しておくことで、インターネット１１７上でのソフトウェア配送システムが実現される。また、ＲＩＳクライアント１１５をヘルパとして組み込む代わりに、それをＷＷＷブラウザ１１４のプラグイン（ブラウザウィンドウ内のアプリケーション）として登録しておいてもよい。
【０１７２】
次に、ブラウザのヘルパ・アプリケーションを起動することにより、物品の購入を簡便に行うことのできるオンラインショッピングシステムについて述べる。このシステムでは、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４にヘルパとして登録するとともに、ホームページ上にヘルパ起動のためのアンカーファイルを置く。
【０１７３】
そして、このアンカーファイルをユーザがクリックすると、自動的にＲＩＳクライアント１１５がＲＩＳサーバ１１２に接続し、ＲＩＳサーバ１１２は自動的に指定の商品の課金処理を行って、ベンダに購入報告を行う。ベンダは、これを受けて商品をユーザに発送する。
【０１７４】
図１４は、このようなオンラインショッピングシステムを示している。ベンダであるα商店１５１は、インターネット１１７上にホームページ１５２を開き、自社の扱う“タオルセット”や“ハンカチーフ”等の商品の宣伝を行う（処理Ｐ１１）。それとともに、商品の購入処理のソフトウェアを、図５１、５２に示した先願の方法でＲＩＳサーバ１１２に登録する（処理Ｐ１２）。
【０１７５】
ホームページ１５２のＨＴＭＬファイルは、図９と同様の形式で記述され、商品の選択／購入に必要なＲｉｓアイコンをホームページ１５２上に表示させる（処理Ｐ１３）。それぞれのＲｉｓアイコンにリンクしたアンカーファイルおよびユーザ側のＭＩＭＥ等の設定は、上述のソフトウェア配送システムと同様である。例えば、Ｒｉｓアイコン１５３には、アンカーファイル１５４（ＴＯＷＥＬ．ＲＩＳ）がリンクされている。
【０１７６】
この状態で、ユーザがα商店ホームページ１５２にアクセスし（処理Ｐ１４）、“タオルセット”の横のＲｉｓアイコン１５３をクリックしたとする（処理Ｐ１５）。このとき、ＷＷＷブラウザ１１４は、ヘルパとして登録されたＲＩＳクライアント１１５を起動し、ＲＩＳクライアント１１５にファイルＴＯＷＥＬ．ＲＩＳの内容を渡す（処理Ｐ１６）。
【０１７７】
起動されたＲＩＳクライアント１１５は、ＲＩＳサーバ１１２に接続し、暗号化されたパスワードでログインして、登録されたリモートインストール処理（ＲＩＳ　ＩＮＳＴＡＬＬ）を開始する（処理Ｐ１７）。ログイン時の設定内容や手順も、上述のソフトウェア配送システムと同様である。
【０１７８】
開始されたリモートインストール処理では、ソフトウェアの宅配の場合とは異なる動作を行うように、そのスクリプトを記述しておく。この場合、具体的には、ユーザへ受付票を送付する処理とベンダへ購入通知を送付する処理とが、ソフトウェア配送処理の代わりに記述される。また、必要であれば、商品の発送先をユーザが指定できるようにしておく。
【０１７９】
受付票は、ソフトウェアをダウンロードする場合と同様の方法でユーザへ送付される（処理Ｐ１８）。また、購入通知は、電子メールや専用回線を介した規定フォーマットの通知票としてベンダへ送付される（処理Ｐ１８）。購入通知の送付処理は、ベンダ側から見ると商品の受注処理となる。この購入通知送付処理も、リモートインストール処理中に即時に実行される。
【０１８０】
図１５は、これらの送付処理のシーケンスを示している。まず、ＲＩＳクライアント１１５は、ファイルＴＯＷＥＬ．ＲＩＳから抽出したソフトウェア番号を、注文する商品の番号としてＲＩＳサーバ１１２に送る。このとき、コマンドＲＩＳ　ＣＨＫＥＮＶを利用する。
【０１８１】
次に、ＲＩＳサーバ１１２が、レスポンスとして商品の発送先を問い合わせてくると、ユーザは希望する住所／宛て名を入力する。入力された発送先は、コマンドＲＩＳ　ＣＨＫＥＮＶを利用してＲＩＳサーバ１１２に送られる。そして、ＲＩＳサーバ１１２から“ＯＫ”が返されると、ＲＩＳクライアント１１５がコマンドＲＩＳ　ＩＮＳＴＡＬＬを送る。
【０１８２】
このとき、ＲＩＳサーバ１１２は、受付票をダウンロードし、購入通知をベンダに送付する。そして、購入通知を受け取ったベンダは、所定の方法でユーザに商品を発送する（処理Ｐ１９）。図１５の処理が終了すると、図１２、１３と同様の購入テーブル、支払テーブルが作成されるので、ＲＩＳサーバ１１２は、これらを元にユーザから代金を徴収し、ベンダへの支払いを行う（処理Ｐ２０）。
【０１８３】
このように、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４から起動されるヘルパ・アプリケーションとして登録しておくことで、インターネット１１７上でのオンラインショッピングシステムが実現される。また、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４のプラグインとして登録しておくことも可能である。
【０１８４】
このようなシステムによれば、ＲＩＳ会員としてのユーザ情報があらかじめ登録されているので、ユーザは商品の購入に際し、気に入った商品のボタンを押すだけでよい。このため、非常に簡便なオンラインショッピングが可能となる。また、登録時の連絡先と異なる発送先を指定することもでき、例えば、商品を第３者への贈答品として配送させることもできる。
【０１８５】
また、ＲＩＳのセンターは、販売に関わる一部の業務をアウトソーシングの形で請け負うことが可能である。したがって、ＲＩＳ会員のみに商品を販売する場合は、ベンダにとって、個々のカード会社との契約等の煩わしい手間が省けるというメリットがある。
【０１８６】
次に、ブラウザのヘルパ・アプリケーションを起動することにより、特定のパスワードを通知するオンライン通信サービスシステムについて述べる。このシステムでは、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４にヘルパとして登録するとともに、ホームページ上にヘルパ起動のアンカーファイルを置く。
【０１８７】
そして、ユーザがこのアンカーファイルをクリックすると、ＲＩＳクライアント１１５が自動的にＲＩＳサーバ１１２に接続する。ＲＩＳサーバ１１２は、指定された通信サービスの課金処理を行い、ベンダに購入報告を行うとともに、ユーザにサービス利用のためのパスワードを通告する。ユーザは、このパスワードをＷＷＷブラウザ１１４の画面に入力することで、そのサービスが受けられるようになる。
【０１８８】
図１６は、このようなオンライン通信サービスシステムを示している。通信サービスのベンダである占いの舘１６１は、インターネット１１７上にホームページ１６２を開き、これを自社の占いサービスの受付画面とする（処理Ｐ２１）。また、占いサービスの利用権を表す占いチケットとなるパスワード情報を、図５１、５２に示した方法で、ユーザへの通告としてＲＩＳサーバ１１２に登録する（処理Ｐ２１）。
【０１８９】
ホームページ１６２のＨＴＭＬファイルは、図１７のように記述される。これにより、占いチケットに対応するＲｉｓアイコン１６３と、パスワードの入力欄１６４が表示される。Ｒｉｓアイコン１６３には、ヘルパ起動のためのアンカーファイル１６５（ＦＴＥＬＬ．ＲＩＳ）がリファレンスとして設定されている。
【０１９０】
このファイルＦＴＥＬＬ．ＲＩＳの［ＲＩＳ］セクションには、図１８に示すように、占いサービスのサービス名とソフトウェア番号（Ｓｏｆｔ）とが記述される。このソフトウェア番号は、サービスの識別番号として用いられる。
【０１９１】
また、アンカーファイル１６５におけるＷＷＷサーバのＭＩＭＥ設定は、上述のソフトウェア配送システムと同様にしておく。これにより、ＷＷＷブラウザ１１４がこのリファレンスを参照してきたとき、対応するＷＷＷサーバはＭＩＭＥタイプとしてａｐｐｌｉｃａｔｉｏｎ／ｘ−ｒｉｓを返すようになる。
【０１９２】
ユーザ側は、上述のソフトウェア配送システムと同様に、ＲＩＳ会員として既にユーザＩＤ／パスワードおよびマシンＩＤ／パスワードが付与されているものとする。さらに、ＷＷＷブラウザ１１４に、ＲＩＳクライアント１１５をヘルパ・アプリケーションとして登録しておく。
【０１９３】
この状態で、ユーザが占いの舘ホームページ１６２にアクセスし（処理Ｐ２２）、占いチケットの横のＲｉｓアイコン１６３をクリックしたとする（処理Ｐ２３）。このとき、ＷＷＷブラウザ１１４は、ＲＩＳクライアント１１５を起動し、ＲＩＳクライアント１１５にファイルＦＴＥＬＬ．ＲＩＳの内容を渡す（処理Ｐ２４）。
【０１９４】
起動されたＲＩＳクライアント１１５は、ＲＩＳサーバ１１２に接続し、暗号化されたパスワードでログインする。インターネット１１７上でのログインのシーケンスやＲＩＳクライアント１１５を使用するための設定は、図４、５、６に示した方法と同様である。
【０１９５】
ログインの後、ＲＩＳクライアント１１５は、ファイルＦＴＥＬＬ．ＲＩＳに記述されたソフトウェア番号をＲＩＳサーバ１１２に送り（処理Ｐ２５）、ＲＩＳサーバ１１２は、その番号により指定されるサービスの購入代金の課金処理を行い、その後、サービス購入者を識別するためのパスワードをユーザへ通告する（処理Ｐ２６）。
【０１９６】
パスワードの通告は、ＲＩＳセンターからユーザへの連絡であり、例えば図１９に示すような画面を、メッセージボックスの形式で端末１１３上に表示することで行われる。
【０１９７】
ユーザは、受け取ったパスワードをホームページ１６２上に表示された入力欄１６４に入力することで、対応するＷＷＷサーバを通じて占いサービスを受けることができるようになる（処理Ｐ２７）。このために、占いサービスを提供するＷＷＷサーバ側では、パスワード欄の値を得て、サービスの利用権を確認する機能を持っている。
【０１９８】
この機能の実現方法としては、図１７のＨＴＭＬファイルに記述されているＣＧＩ（ｃｏｍｍｏｎ　ｇａｔｅｗａｙ　ｉｎｔｅｒｆａｃｅ）のスクリプトファイルｕｒａ．ｃｇｉを利用する。ファイルｕｒａ．ｃｇｉには、図２０に示すようなサービス利用権の確認処理のロジックが記述される。
【０１９９】
確認処理が開始されると、ＷＷＷサーバ上のＣＧＩプロセスは、まず入力されたパスワードの値を取得し（ステップＳ２０１）、それをＲＩＳサーバ１１２に登録したパスワードと比較して、正しいパスワードかどうかを確認する（ステップＳ２０２）。
【０２００】
パスワードが正しければ、そのユーザは課金されているものとみなし、有料の占いサービス提供画面を表示して（ステップＳ２０３）、処理を終了する。パスワードが正しくなければ、その誤りを指摘するメッセージをホームページ１６２上に表示して（ステップＳ２０４）、処理を終了する。
【０２０１】
このような通信サービスにおけるパスワードの運用形態としては、すべてのユーザに共通のパスワードを与えて運用し続ける方法が考えられる。また、ユーザ間でのパスワードの漏洩またはパスワード推測による不正使用の防止するため、およびサービスの提供期間を限定するために、一定期間（数分、数時間、数日等）毎にパスワードを変更する方法やユーザ毎に異なるパスワードを発行する方法などもある。また、これらのパスワード保護方法を併せて用いることもできる。
【０２０２】
さらに、ＲＩＳサーバ１１２への登録時に、パスワードを固定した情報とするのではなく、特定の計算アルゴリズムを用いて、パスワードを動的に生成することも可能である。
【０２０３】
以上の操作が行われると、ＲＩＳサーバ１１２のデータベースには、図１２、１３と同様のサービス購入履歴が残る。そのサービス購入履歴を元に、上述のソフトウェア配送システムと同様の手順で、購入代金が決裁される（処理Ｐ２８）。
【０２０４】
このように、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４から起動されるヘルパ・アプリケーションとして登録しておくことで、インターネット１１７上でのオンライン通信サービスシステムが実現される。また、ＲＩＳクライアント１１５をＷＷＷブラウザ１１４のプラグインとして登録しておくことも可能である。
【０２０５】
図１６のシステムでは、ユーザにパスワードを知らせることで通信サービスの利用権を与えているが、その代わりに、サービスを受けるためのＵＲＬ（ｕｎｉｆｏｒｍ　ｒｅｓｏｕｒｃｅ　ｌｏｃａｔｏｒ）を通知することも考えられる。ＵＲＬとは、ネットワーク上の資源を統一的に表現する識別情報である。
【０２０６】
この場合、ＲＩＳサーバ１１２は、課金処理後に、通信サービスのＵＲＬをユーザに通知する。そして、このＵＲＬは、課金を受けたものだけが知り得るように運用しておく。例えばＵＲＬを頻繁に変更すれば、ユーザは最新のＵＲＬを知るためにチケットを購入しなければならなくなる。
【０２０７】
図２１は、このような通信サービスシステムを示している。このシステムの動作は、基本的に図１６のシステムと同様である。まず、占いの舘１６１は、インターネット１１７上にホームページ１６６を開き、これを自社の占いサービスの受付画面とする（処理Ｐ３１）。また、占いチケットとなるＵＲＬ情報を、図５１、５２に示した方法で、ＲＩＳサーバ１１２に登録する（処理Ｐ３１）。
【０２０８】
ホームページ１６６上には、占いチケットに対応するＲｉｓアイコン１６７と、“チケット購入で占いの部屋へのＵＲＬが表示されます”というメッセージが表示される。Ｒｉｓアイコン１６７には、ヘルパ起動のためのアンカーファイル１６５（図１８のＦＴＥＬＬ．ＲＩＳ）がリファレンスとして設定されている。
【０２０９】
ユーザが占いの舘ホームページ１６６にアクセスし（処理Ｐ３２）、占いチケットの横のＲｉｓアイコン１６７をクリックしたとする（処理Ｐ３３）。このとき、ＷＷＷブラウザ１１４は、ＲＩＳクライアント１１５を起動し、ＲＩＳクライアント１１５にファイルＦＴＥＬＬ．ＲＩＳの内容を渡す（処理Ｐ３４）。
【０２１０】
起動されたＲＩＳクライアント１１５は、ＲＩＳサーバ１１２に接続し、暗号化されたパスワードでログインし、ファイルＦＴＥＬＬ．ＲＩＳに記述されたソフトウェア番号をＲＩＳサーバ１１２に送る（処理Ｐ３５）。ＲＩＳサーバ１１２は、その番号により指定されるサービスの購入代金の課金処理を行い、その後、占いサービスページ１６８のＵＲＬをユーザへ通告する（処理Ｐ３６）。ＵＲＬの通告は、例えば図１９と同様のメッセージボックスを用いて行われる。
【０２１１】
ユーザは、通告によって知り得た占いサービスへのＵＲＬをＷＷＷブラウザ１１４上で指定することで、そのサービスページ１６８にアクセスして、占いサービスを受けることができるようになる（処理Ｐ３７）。
【０２１２】
また、図２１のシステムにおいて、ＵＲＬをユーザに通知する代わりに、そのＵＲＬを参照するブラウザを自動的に起動することも可能である。この場合、ＲＩＳセンターからのＵＲＬ通知をトリガとして、ソフトウェアによりブラウザを起動することで、ユーザがＵＲＬを直接扱うことなく、ＵＲＬに対応したサービス画面へのアクセスが可能になる。
【０２１３】
ＷＷＷブラウザ１１４の実装形態により、すでに起動されているＷＷＷブラウザ１１４が、外部からのイベントによりＵＲＬ指定を自動取得可能な場合は、ＲＩＳクライアント１１５は、ＷＷＷブラウザ１１４が読み込み可能な形式でＵＲＬをそれに通知する。このような方法としては、例えば、ＷＷＷブラウザ１１４の所定のファイルにＵＲＬを書き込んだ後、動作しているＷＷＷブラウザ１１４にソフトウェアシグナルを送付する方法がある。
【０２１４】
ＷＩＮ９５（Ｗｉｎｄｏｗｓ９５）の場合は、例えば図２２に示すようなファイルＷＯＲＫ．ＵＲＬを作成する。このファイルＷＯＲＫ．ＵＲＬには、モザイク、ＮＥＴＳＣＡＰＥ等のブラウザのタイプに応じて、ＲＩＳサーバ１１２から通知されたＵＲＬが書き込まれる。
【０２１５】
そして、ＲＩＳクライアント１１５は、ＷＩＮ９５のＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ　ｐｒｏｇｒａｍｍｉｎｇ　ｉｎｔｅｒｆａｃｅ　）を使用して、ＷＷＷブラウザ１１４を立ち上げる。ＡＰＩとは、オペレーティングシステムが提供するプログミング・インタフェースである。
【０２１６】
この場合のＡＰＩは、例えば“ＳｈｅｌｌＥｘｅｃｕｔｅ（〜，”ＷＯＲＫ．ＵＲＬ”，〜）”のように記述される。これにより、ＷＷＷブラウザ１１４は、ファイルＷＯＲＫ．ＵＲＬから自動的にＵＲＬを取得して、対応するサービス画面にアクセスする。
【０２１７】
また、ＷＷＷブラウザ１１４が、上述の方法で、ソフトウェア的にＵＲＬ指定を自動取得可能でない場合は、所定のＵＲＬを初期ＵＲＬ引数として与えて、ＲＩＳクライアント１１５から別途ＷＷＷブラウザ１１４を起動する。複数のＷＷＷブラウザ１１４が同時に並行して動作すると不都合がある場合は、以前から動作していたＷＷＷブラウザ１１４を一旦終了させ、その後で改めてＷＷＷブラウザ１１４を起動すればよい。
【０２１８】
次に、トランザクション用ヘルパとＲＩＳシステムとで構成するトランザクション処理システムについて述べる。このシステムでは、トランザクション用ヘルパを用意し、トランザクションの使用権をＲＩＳシステムに登録しておく。そして、ヘルパとして起動されたＲＩＳシステムが、トランザクション用の別のヘルパと連携することにより、トランザクション処理の使用権のデストリビューションと課金処理とを行う。
【０２１９】
図２３は、このようなトランザクション処理システムを示している。ベンダであるＶＯＩＣＥ工房のＷＷＷサーバ１７１は、例えば入力されたユーザの音声を元に占いを実行する音声占いのトランザクションサービスを提供する。まず、ＷＷＷサーバ１７１は、音声占いのホームページ１７２をインターネット１１７上に開き、そのトランザクションサービスの使用権を表す音声占い券を、ソフトウェアとしてＲＩＳサーバ１１２に登録する（処理Ｐ４１）。
【０２２０】
また、ユーザ端末１１３上では、ＷＷＷブラウザ１１４のヘルパとして、ＲＩＳクライアント１１５とＶｏｉｃｅ処理プログラム１７８が登録される。Ｖｏｉｃｅ処理プログラム１７８は、ユーザから音声の入力を受けて、各種フィルタリング処理の後、音声ファイルを作成する専用のソフトウェアであり、ＶＯＩＣＥ工房により作成／配布される。
【０２２１】
ユーザは、まず、ＷＷＷブラウザ１１４からＶＯＩＣＥ工房ホームページ１７２にアクセスし（処理Ｐ４２）、音声占い券販売のアイコン１７３をクリックする（処理Ｐ４３）。
【０２２２】
このアイコン１７３には、ＲＩＳクライアント１１５を起動するためのアンカーファイル１７６（ＵＲＡＮＡ．ＲＩＳ）がリファレンスとして設定されており、ＷＷＷブラウザ１１４は、ＲＩＳクライアント１１５を起動して、ファイルＵＲＡＮＡ．ＲＩＳの内容を渡す（処理Ｐ４４）。ファイルＵＲＡＮＡ．ＲＩＳにおけるＭＩＭＥ設定は、図８のシステムと同様である。
【０２２３】
起動されたＲＩＳクライアント１１５は、インターネット１１７を介してＲＩＳサーバ１１２に接続し（処理Ｐ４５）、ダイレクトに音声占い券のデストリビューションを行う。
【０２２４】
ここでは、デストリビューション処理として、ＲＩＳクライアント１１５がＶｏｉｃｅ処理プログラム１７８の初期設定ファイル１７９（Ｖｏｉｃｅ．ｉｎｉ）の情報を書き換える（処理Ｐ４６）。例えば、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションに“ＹＥＳ”を書き込むことで、音声占い券のデストリビューションが行われ、ユーザにサービスの利用権が与えられる。
【０２２５】
次に、ユーザがホームページ１７２の音声入力開始のアイコン１７４をクリックする（処理Ｐ４７）。このアイコン１７４には、Ｖｏｉｃｅ処理プログラム１７８を起動するためのアンカーファイル１７７（ＫＵＢＯ．ＶＯＣ）がリファレンスとして設定されており、ＷＷＷブラウザ１１４は、Ｖｏｉｃｅ処理プログラム１７８を起動する（処理Ｐ４８）。アンカーファイル１７７におけるＭＩＭＥ設定として、ファイルタイプ“．ＶＯＣ”がＭＩＭＥタイプ“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｖｏｉｃｅ”に対応付けられている。
【０２２６】
起動されたＶｏｉｃｅ処理プログラム１７８は、図２４に示すような処理を行う。Ｖｏｉｃｅ処理プログラム１７８は、まず、初期設定ファイル１７９の［Ｐｅｒｍｉｓｓｉｏｎ］セクションに“ＹＥＳ”と記述されているかどうかを調べる（ステップＳ２１１）。ここに“ＹＥＳ”と記述されていなければ、“占い券未購入”というメッセージを表示して（ステップＳ２１６）、処理を終了する。
【０２２７】
ここに“ＹＥＳ”と記述されていれば、音声入力動作を開始し（ステップＳ２１２）、入力音声のフィルタリング等の各種ローカル処理を行って（ステップＳ２１３）、音声ファイル（不図示）を生成／出力する（ステップＳ２１４）。そして、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションの“ＹＥＳ”を消去し（ステップＳ２１５）、処理を終了する。
【０２２８】
こうして、音声ファイルが出力されると、ユーザは、次に占い開始のアイコン１７５をクリックし、占いサービスを実行する（処理Ｐ４９）。占い開始のページは、例えば図２５に示すように構成される。図２５においては、音声ファイル名入力欄１８１、Ｂｒｏｗｓｅアイコン１８２、ＡＤＤアイコン１８３、および実行アイコン１８４が表示されている。
【０２２９】
Ｂｒｏｗｓｅアイコン１８２がクリックされると、ファイルセレクタ１８５が開き、ここで選択された音声ファイル名が自動的に入力欄１８１に入力される。ＡＤＤアイコン１８３は、入力する音声ファイルを追加する際に用いられる。ＨＴＭＬファイル１８６は、この占い開始ページの記述方法を表す。
【０２３０】
ユーザにより音声ファイル名が入力され、実行アイコン１８４がクリックされると、指定された音声ファイルが占いサービスを行うＷＷＷサーバ１７１にアップロードされる。音声ファイルのアップロードは、既知のＨＴＭＬファイルアップロード機能を用いて行われる。ＷＷＷサーバ１７１は、アップロードされた音声ファイルを処理して、占い結果１８０をＷＷＷブラウザ１１４に返す（処理Ｐ５０）。
【０２３１】
音声占いの使用料金は、ＲＩＳクライアント１１５がＲＩＳサーバ１１２に接続した時点で課金処理され、その後、ＲＩＳサーバ１１２からＶＯＩＣＥ工房に払い戻される（処理Ｐ５１）。
【０２３２】
ところで、上述の初期設定ファイル１７９を利用して、ローカルなトランザクション処理プログラムから直接ＲＩＳクライアント１１５を起動し、図２３と同様の方法でトランザクション処理の使用権のデストリビューションと課金処理とを行うこともできる。
【０２３３】
この場合、トランザクション処理プログラムを、図２６のフローチャートに示すように構成する。トランザクション処理プログラムは、まず、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションに、サービス使用権の購入処理中であることを示す情報“ＢＵＹＩＮＧ”が書き込まれているかどうかを調べる（ステップＳ２２１）。
【０２３４】
ここに“ＢＵＹＩＮＧ”が書かれていれば、それが消去されるまで同じ判定を繰り返し、“ＢＵＹＩＮＧ”が書かれていなければ、次に、その［Ｐｅｒｍｉｓｓｉｏｎ］セクションに、購入済を表す情報“ＹＥＳ”が書き込まれているかどうかを調べる（ステップＳ２２２）。
【０２３５】
ここに“ＹＥＳ”が書かれていなければ、サービス使用権（占い券）を購入中でも購入済でもないことがわかる。そこで、トランザクション処理プログラムは、占い券を購入するかどうかをユーザに問い合せる（ステップＳ２２８）。ここで、ユーザが占い券の購入を選択しなければそのまま処理を終了する。
【０２３６】
ユーザが占い券の購入を選択すると、トランザクション処理プログラムは、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションに“ＢＵＹＩＮＧ”を書き込んで（ステップＳ２２９）、ＲＩＳクライアント１１５を起動し（ステップＳ２３０）、ステップＳ２２８以降の処理を繰り返す。
【０２３７】
起動されたＲＩＳクライアント１１５は、図２３のシステムと同様の方法でＲＩＳサーバ１１２に接続して、占い券を購入する。占い券の購入が終わると、ＲＩＳクライアント１１５は、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションの“ＢＵＹＩＮＧ”を消去して、代わりに“ＹＥＳ”を書き込む。
【０２３８】
このとき、ステップＳ２２１の判定結果がＮＯとなり、ステップＳ２２２の判定結果がＹＥＳとなる。そこで、トランザクション処理プログラムは、音声入力動作を開始し（ステップＳ２２３）、入力音声のフィルタリング等の処理を行って（ステップＳ２２４）、占いを実行する（ステップＳ２２５）。
【０２３９】
そして、占い結果を表示し（ステップＳ２２６）、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションの“ＹＥＳ”を消去して（ステップＳ２２７）、処理を終了する。［Ｐｅｒｍｉｓｓｉｏｎ］セクションの“ＹＥＳ”を消去することで、トランザクション処理は初期状態を回復する。
【０２４０】
このように、ＲＩＳシステムと連携するトランザクション処理プログラムをユーザ端末１１３上に備えることで、ＷＷＷブラウザ１１４の介在なしにＲＩＳシステムを利用することが可能になる。
【０２４１】
また、図２３のトランザクションサービスシステムにおいて、複数回のサービス利用権を販売することもできる。この場合は、ＲＩＳサーバ１１２には複数回の使用権を登録しておき、Ｖｏｉｃｅ処理プログラム１７８側では、トランザクション処理毎に、初期設定ファイルのカウント数を１だけデクリメントする構成を用いる。
【０２４２】
図２７は、このようなトランザクションサービスシステムを示している。図２７のシステムにおいては、ＲＩＳサーバ１１２には、１回、５回、１０回の３種類の占い券が、それぞれ、ソフトウェア番号１６０、１６１、１６２に対応して登録されている。そして、ベンダのＶＯＩＣＥ工房ホームページ１９１には、音声占い券販売のアイコンとして、１回券、５回券、１０回券のアイコン１９２、１９３、１９４が表示される。
【０２４３】
これらのアイコン１９２、１９３、１９４には、それぞれ、アンカーファイル１９５（ＵＲＡＮＡ．ＲＩＳ）、１９６（ＵＲＡＮＡ２．ＲＩＳ）、１９７（ＵＲＡＮＡ３．ＲＩＳ）がリファレンスとして設定されている。そして、ファイルＵＲＡＮＡ．ＲＩＳにはソフトウェア番号１６０が記述され、ファイルＵＲＡＮＡ２．ＲＩＳにはソフトウェア番号１６１が記述され、ファイルＵＲＡＮＡ３．ＲＩＳにはソフトウェア番号１６２が記述されている。
【０２４４】
ユーザがいずれかの占い券を選択して、対応するアイコンをクリックすると、ＲＩＳクライアント１１５は、そのアイコンにリンクしているアンカーファイルのソフトウェア番号をＲＩＳサーバ１１２に送り、初期設定ファイル１７９の［Ｐｅｒｍｉｓｓｉｏｎ］セクションに、対応するカウント数（Ｃｏｕｎｔ）を書き込む。例えば、１０回券が購入された場合は、Ｃｏｕｎｔ＝１０となる。これにより、複数回のサービス利用権がユーザ端末１１３に設定される。
【０２４５】
図２８は、このシステムにおけるＶｏｉｃｅ処理プログラム１７８の処理のフローチャートである。Ｖｏｉｃｅ処理プログラム１７８は、まず、初期設定ファイル１７９の［Ｐｅｒｍｉｓｓｉｏｎ］セクションのＣｏｕｎｔの値が０かどうかを調べる（ステップＳ２３１）。Ｃｏｕｎｔが０であれば、“占い券未購入”というメッセージを表示して（ステップＳ２３６）、処理を終了する。
【０２４６】
Ｃｏｕｎｔが０より大きければ、音声入力動作を開始し（ステップＳ２３２）、入力音声のフィルタリング等の各種ローカル処理を行って（ステップＳ２３３）、音声ファイルを生成／出力する（ステップＳ２３４）。そして、ファイルＶｏｉｃｅ．ｉｎｉの［Ｐｅｒｍｉｓｓｉｏｎ］セクションのＣｏｕｎｔの値を、１だけデクリメントして（ステップＳ２３５）、処理を終了する。
【０２４７】
このようなＶｏｉｃｅ処理プログラム１７８を用いれば、ユーザは、購入したサービス利用権の利用回数だけ、サービスを受けることができる。図２７のシステムにおけるその他の設定および動作は、図２３のシステムと同様である。
【０２４８】
次に、ローカルなトランザクション処理プログラムとＲＩＳシステムの連携処理により、データの取得および課金を行うシステムについて述べる。このシステムでは、トランザクション処理プログラムから直接ＲＩＳクライアント１１５を起動し、図２３と同様の方法でトランザクション処理用のデータを入手する。
【０２４９】
例えば、トランザクション処理プログラムが競馬予想ソフトウェアである場合、その処理のフローチャートは、図２９に示すようになる。競馬予想ソフトウェアは、起動時に、まず新しいデータを取得するかどうかをユーザに問い合せる（ステップＳ２４１）。
【０２５０】
そして、ユーザが新しいデータを取得しない意思決定を行った場合は、既存の競馬データを用いて予想を実行し（ステップＳ２４３）、処理を終了する。また、ユーザが新しいデータを取得する意思決定を行った場合は、ＲＩＳクライアント１１５を起動する（ステップＳ２４２）。
【０２５１】
ＲＩＳクライアント１１５は、ソフトウェア番号を元にしてＲＩＳサーバ１１２にアクセスする。ＲＩＳサーバ１１２には、図３０に示すように、競馬データがあらかじめ登録されており、図８と同様な方法で、ダイレクトに競馬データのデストリビューションを行う。そして、競馬予想ソフトウェアは、配送された競馬データを用いて予想を実行し（ステップＳ２４３）、処理を終了する。
【０２５２】
図３１は、ＲＩＳクライアント１１５とＲＩＳサーバ１１２による競馬データのデストリビューション処理を示している。この処理は、図４４、４５、４６に示した方法を利用して実行される。まず、ＲＩＳクライアント１１５が、競馬予想ソフトウェアに付随する競馬データファイルＫＥＩＢＡ．ＤＡＴの日付を調べ、ＲＩＳサーバ１１２に送る（ステップＳ２５１）。ファイルＫＥＩＢＡ．ＤＡＴには、例えば図３２に示すように、競走馬等のデータＡ、Ｂ、Ｃが格納されている。
【０２５３】
ＲＩＳサーバ１１２は、図３３に示すような日付・ファイル名対応表を参照して、送られた日付に対応するファイル名を検索し、それに対応するファイルを、追加データファイルとしてＲＩＳクライアント１１５に送付する（ステップＳ２５２）。そして、その内容をファイルＫＥＩＢＡ．ＤＡＴに追加して、ファイルＫＥＩＢＡ．ＤＡＴを更新し（ステップＳ２５３）、処理を終了する。
【０２５４】
図３３の日付・ファイル名対応表は、あらかじめＲＩＳサーバ１１２に登録されており、必要に応じて更新される。日付・ファイル名対応表に記載されたファイルＦＩＬＥ１．ＬＺＨ、ＦＩＬＥ２．ＬＺＨ、ＦＩＬＥ３．ＬＺＨには、図２４に示すようなデータの組み合わせが含まれる。
【０２５５】
例えば、ファイルＦＩＬＥ１．ＬＺＨにはデータＤ、Ｅ、Ｆ、Ｇが含まれ、ファイルＦＩＬＥ２．ＬＺＨにはデータＥ、Ｆ、Ｇが含まれ、ファイルＦＩＬＥ３．ＬＺＨにはデータＦ、Ｇが含まれている。このように、ファイル毎にデータの組み合わせを変えておくことで、日付の古いファイルＫＥＩＢＡ．ＤＡＴほど、多くの追加データが与えられるようにすることができる。
【０２５６】
図２９のようなトランザクション処理プログラムによれば、ＷＷＷブラウザ１１４の介在なしに、ＲＩＳシステムを利用してサービスに必要なデータを配送することが可能になる。
【０２５７】
また、トランザクション処理プログラムが、起動時にデータファイルの日付を見て、前回のデータ更新時から一定時間経過している場合のみ、ＲＩＳサーバ１１２に接続し、データ取得を行う構成にすることもできる。この場合、トランザクション処理プログラムは、現在の日付がデータファイルの日付より所定日数以上経過していれば、ＲＩＳサーバ１１２に接続して、最新のデータによりデータファイルを更新する。
【０２５８】
図３５は、このような競馬予想ソフトウェアのフローチャートである。競馬予想ソフトウェアは、起動時に、現在の日付とデータファイルＫＥＩＢＡ．ＤＡＴの日付の差を計算し、それが２ヵ月を越えているかどうかを判定する（ステップＳ２６１）。
【０２５９】
その差が２ヵ月を越えていなければ、既存の競馬データを用いて予想を実行し（ステップＳ２６３）、処理を終了する。また、その差が２ヵ月を越えていれば、ＲＩＳクライアント１１５を起動し、新しい競馬データをＲＩＳサーバ１１２から取得する（ステップＳ２６２）。そして、配送された競馬データにより更新されたファイルＫＥＩＢＡ．ＤＡＴを用いて、予想を実行し（ステップＳ２６３）、処理を終了する。
【０２６０】
次に、複数のＲＩＳサーバが存在するネットワーク環境において、ユーザ端末（クライアントマシン）のマシンＩＤ（ＭＩＤ）にサーバ識別子を混ぜることで、サーバによるユーザ端末の誤認識を防ぐＲＩＳシステムについて述べる。
【０２６１】
このシステムでは、サーバ識別子とクライアントマシンの識別子を合成して、そのクライアントマシンを識別するＭＩＤを生成する。そして、サーバはクライアントから送られたＭＩＤをサーバ部とクライアント部に分解し、サーバ部がそのサーバの識別子と異なっていたら、クライアントとの接続を切断する。
【０２６２】
従来のＲＩＳシステムによるクライアント識別の方法は、サーバがただ１つしか存在しないことを前提としていた。これに対して、本実施形態の方法を用いれば、複数のサーバがサービスを行い、１つのクライアントが各サーバに接続する場合でも、サーバによるクライアントの誤認識を防ぐことができる。
【０２６３】
このシステムでは、それぞれ異なる複数のサーバは、それ自身を表す固有の識別子を有し、クライアントのＭＩＤは、常にアクセス先のサーバ識別子を用いて作成することにする。したがって、同じマシンでも、そのアクセス先によってＭＩＤが異なってくる。
【０２６４】
図３６は、サーバＡ、Ｂとクライアントマシンα、βを含むシステムを示している。このシステムにおいて、サーバＡは、クライアント番号１に対してマシンαの情報（ディレクトリ情報やメモリ量等）を保持し、クライアント番号２に対してマシンβの情報を保持する。また、他のサーバＢは、クライアント番号２に対してマシンαの情報を保持し、クライアント番号１に対してマシンβの情報を保持している。
【０２６５】
図４８に示した従来の方法では、クライアント番号自体がＭＩＤとして使われていた。この方法をそのまま図３６のシステムに適用すると、マシンαがクライアント番号１をＭＩＤとしてサーバＢに接続した場合、サーバはそれをマシンβのＭＩＤとみなして、マシンαから送られる情報をマシンβの情報に上書きしてしまう事故が発生し得た。
【０２６６】
しかし、クライアント識別子にサーバ識別子を混ぜてＭＩＤを生成することで、クライアントが誤った識別子を用いてサーバに接続した場合に、サーバ側でこれをチェックして、誤りを検出することが可能になる。これにより、サーバは、マシン情報を誤って上書きしてしまうことを避けるとともに、クライアントに対して、誤りを通知することができる。
【０２６７】
例えば、マシンαがサーバＡ、Ｂにアクセスする際のＭＩＤを、それぞれ“Ａ１”、“Ｂ２”とし、マシンβがサーバＡ、Ｂにアクセスする際のＭＩＤを、それぞれ“Ａ２”、“Ｂ１”とする。
【０２６８】
このとき、マシンαが、誤って“Ｂ２”をＭＩＤとしてサーバＡにアクセスした場合、サーバＡは、まず、そのＭＩＤをサーバ部“Ｂ”とクライアント部“２”とに分解して、サーバ部の識別子を調べる。この場合、サーバ部“Ｂ”が自身の識別子と異なるので、このアクセスは誤りと判断し、マシンαとの接続を切断する。
【０２６９】
また、マシンαが、誤って“Ａ１”をＭＩＤとしてサーバＢにアクセスした場合も、同様にして誤りが検出され、マシンαとの接続が切断される。ここでは、アクセスの誤りを接続の切断という方法でクライアントに通知しているが、代わりにエラーメッセージ等を用いてもよい。
【０２７０】
このシステムのサーバ識別子としては、ドメイン名ｒｉｓ．ｇｍｓｎｅｔ．ｏｒ．ｊｐのように、世界で唯一であることが保証されているものを用いることが望ましい。そうすれば、サーバ識別子の重複という事故を避けることができるので、クライアントの識別を完璧に行うことができる。したがって、１つのクライアントで複数のサーバを使い分ける場合でも、クライアントのマシン情報が混乱することが避けられる。
【０２７１】
また、このような複数のサーバの取扱いにおいて、各サーバに対応する初期設定ファイルをクライアント側に持つことも考えられる。この場合、基本となるサーバの初期設定ファイルに、他のサーバの初期設定ファイルがあるかどうかを、拡張情報として記述しておく。
【０２７２】
例えば、図３７に示すファイルＲＩＳ．ＩＮＩを基本の初期設定ファイルとし、図３８に示すファイルＲＩＳ２．ＩＮＩを別のサーバの初期設定ファイルとする。このように、サーバ毎に異なる初期設定ファイルを用意すれば、矢印で示されるように、それぞれまったく異なるユーザＩＤ／パスワードおよびＭＩＤを扱うことができる。
【０２７３】
また、図３７のファイルＲＩＳ．ＩＮＩの中には［ＥＸＴＥＮＳＩＯＮ］セクションが設けられ、ここに他の初期設定ファイルをアクティブにするかどうかを記述できる。ここでは、ファイルＲＩＳ．ＩＮＩとＲＩＳ２．ＩＮＩがアクティブ（ＯＮ）になっており、動作時には、他のファイルＲＩＳ２．ＩＮＩも自動的に参照される。
【０２７４】
図３６に示した方法を用いれば、サーバ側は正しくクライアントマシンの情報をハンドリングすることができる。次に問題となるのは、クライアント側にとって、正しいサーバに接続できたかどうかを確認することにある。というのは、複数のサーバが存在する場合、間違って悪意のあるサーバに接続するかもしれないという危険性があるからである。
【０２７５】
そこで、次に、正しいサーバを識別するＲＩＳシステムについて述べる。このシステムでは、ＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ　）暗号による電子署名の機能を用いたログインセッションを設ける。ＲＳＡ暗号は、非対称な暗号システムであり、暗号化と復号化にはそれぞれ異なる鍵情報が用いられる。
【０２７６】
このログインセッションにおいて、サーバは、決められた情報を秘密鍵で暗号化してクライアントに送り、クライアントは、それを公開鍵で復号化することにより、サーバの認証を行う。これにより、クライアントは、ログイン先が正しいサーバかどうかを判定することができる。
【０２７７】
図３９は、このようなサーバ識別システムを示している。図３９において、各サーバは、ＲＳＡの秘密鍵を保持し、対応する公開鍵をホームページ２０１に登録しておく。サーバのリストを表示するホームページ２０１が信用できるかどうかは、ユーザが判断するものとする。あるいは、信用できるホームページ２０１のＵＲＬをあらかじめクライアントに埋め込んでおいてもよい。
【０２７８】
サーバは、クライアントから接続時に任意の情報を平文で渡してもらい、それを秘密鍵で暗号化して返すと、クライアントは、サーバの公開鍵で元の平文を正しく復元することができる。正しく復元できたということは、サーバがその公開鍵と対を成す秘密鍵を保持していることになるので、正しいサーバであると判断できる。
【０２７９】
図３９において、マシンαは、サーバＡへの接続に先立ち、その識別子“Ａ”、公開鍵“公Ａ”等のサーバ情報をホームページ２０１から取得し、ＭＩＤ“Ａ１”を作成する。このとき、必要であれば、他のサーバの情報も取得しておく。
【０２８０】
この状態で、マシンαがサーバＡを識別するログインシーケンスは、図４０に示すようになる。マシンαがサーバＡに接続すると、サーバＡはサーバ識別のための情報（Ｗｏｒｄ）を問い合せてくる。そこで、マシンαが情報“ａｐｐｌｅ”を平文で送ると、サーバＡはそれを秘密鍵“秘Ａ”で暗号化し、暗（ａｐｐｌｅ，秘Ａ）として送り返す。
【０２８１】
マシンαは、暗（ａｐｐｌｅ，秘Ａ）を公開鍵“公Ａ”で復号化し、情報“ａｐｐｌｅ”を取り出す。この情報は、先に送った情報と一致するので、接続先は正しいサーバＡであると判断する。そこで、ユーザがＵＩＤを入力し、マシンαは通常のログインシーケンスに移行する。
【０２８２】
これに対して、サーバＡになりすましたサーバＡ′に対するログインシーケンスは、図４１に示すようになる。マシンαがサーバＡ′に接続して、サーバＡ′に情報“ａｐｐｌｅ”を送るところまでは、図４０と同様である。サーバＡは、受け取った情報を、適当に設定した秘密鍵“秘Ａ′”で暗号化し、暗（ａｐｐｌｅ，秘Ａ′）として送り返す。
【０２８３】
ところが、マシンαが暗（ａｐｐｌｅ，秘Ａ′）を公開鍵“公Ａ”で復号化すると、平文“ｂｑｑｍｆ”が取り出される。この情報は、先に送った情報と異なるので、接続先は正しいサーバＡではないと判断し、接続を切断する。こうして、偽のサーバＡ′を識別することができる。
【０２８４】
また、図４０、４１のシーケンスとは異なり、クライアントがサーバの公開鍵で暗号化した情報をサーバに送り、サーバがそれを秘密鍵で復号化して、クライアントに平文として送り返しても、同様の効果が得られる。この場合、クライアントは、サーバから送り返された平文が正しければ、そのサーバを正しいサーバと認識する。
【０２８５】
図３９のサーバ識別システムにおいて、サーバ認証鍵となる公開鍵および秘密鍵を固定したまま運用を続けると、いつか暗号を破られる可能性がある。そこで、これらのを定期的に更新することにより、暗号の安全性を高める必要がある。しかし、公開鍵が変更される度に、クライアント側のサーバ情報を設定し直すのは不便なので、この過程を自動化し、クライアントがサーバにログインするときに、毎回サーバ情報を取得するようにする。
【０２８６】
そして、図８に示した方法を利用して、ホームページからＲＩＳクライアント１１５を起動する。この場合、Ｒｉｓアイコンにリンクしたアンカーファイルは、図４２に示すように拡張され、その［ＳＥＲＶＥＲ］セクションにサーバ識別子が記述され、［ＯＫＥＹ］セクションに公開鍵が記述される。
【０２８７】
ＷＷＷブラウザ１１４から起動されたＲＩＳクライアント１１５は、ＲＩＳサーバに接続する前に、図４３に示すような処理を行う。ＲＩＳクライアント１１５は、まず、図４２のアンカーファイルＲＩＳ２．ＲＩＳの［ＳＥＲＶＥＲ］セクションを見て、ＲＩＳサーバ“０００２”へのアクセス権があるかどうかを調べる（ステップＳ２７１）。
【０２８８】
ここに、サーバ識別子“０００２”が記述されていればアクセス権があると判断し、次に、［ＯＫＥＹ］セクションを見て、新たな公開鍵“１２３４”を取り込む（ステップＳ２７２）。そして、［ＲＩＳ］セクションを見て、ソフトウェア番号ではなく、“Ｓｔａｒｔ＝ｍｅｎｕ”と記述されていることを知る。そこで、ソフトウェアを要求するのではなく、初期メニューからＲＩＳサーバ“０００２”にアクセスすることを認識し（ステップＳ２７３）、処理を終了する。
【０２８９】
ステップＳ２７１において、サーバ“０００２”へのアクセス権がないことがわかると、エラー表示等の処理を行って（ステップＳ２７４）、処理を終了する。こうして、ファイルＲＩＳ２．ＲＩＳの読み取りが終了すると、ＲＩＳクライアント１１５は、図４０に示したようなログインセッションを開始する。
【０２９０】
以上説明した実施形態において、暗号アルゴリズムはＤＥＳとＲＳＡに限られず、他の任意のものを用いることができる。また、図１４のオンラインショッピングシステムでは、タオルセット、ハンカチーフ以外の任意の商品、サービスを販売することができ、図１６、２１の通信サービスシステムでは、占いサービス以外の任意の通信サービスを提供することができる。また、図２３、２７のトランザクションサービスシステムでは、音声占いサービス以外の任意のトランザクションサービスを提供することができる。
【０２９１】
【発明の効果】
本発明によれば、インターネット上でリモートインストールシステムを利用して、ソフトウェア配送サービス、オンラインショッピング、通信サービス、トランザクションサービス等の様々な会員制サービスを提供することが可能になる。また、インターネット上での接続先の認証や、パスワード、コンテンツ等の暗号化も行われ、サービスの安全性が保証される。
【図面の簡単な説明】
【図１】本発明のサービスシステムの原理図である。
【図２】実施形態のシステム構成図である。
【図３】情報処理装置の構成図である。
【図４】サインアップシーケンスを示す図である。
【図５】第１の初期設定ファイルを示す図である。
【図６】第１のログインシーケンスを示す図である。
【図７】暗号化されたコンテンツの配送を示す図である。
【図８】インターネット上のソフトウェア配送システムを示す図である。
【図９】ソフト工房ホームページのＨＴＭＬファイルを示す図である。
【図１０】第１のアンカーファイルを示す図である。
【図１１】ソフトウェアの配送を示す図である。
【図１２】購入テーブルを示す図である。
【図１３】支払いテーブルを示す図である。
【図１４】オンラインショッピングシステムを示す図である。
【図１５】受付票／購入通知送付処理を示す図である。
【図１６】オンライン通信サービスシステムを示す図である。
【図１７】占いの舘ホームページのＨＴＭＬファイルを示す図である。
【図１８】第２のアンカーファイルを示す図である。
【図１９】パスワードの表示画面を示す図である。
【図２０】サービス利用権の確認処理のフローチャートである。
【図２１】ＵＲＬを通知する通信サービスシステムを示す図である。
【図２２】ＵＲＬ格納ファイルを示す図である。
【図２３】第１のトランザクションサービスシステムを示す図である。
【図２４】第１のＶｏｉｃｅ処理プログラムのフローチャートである。
【図２５】占い開始画面を示す図である。
【図２６】トランザクション処理プログラムのフローチャートである。
【図２７】第２のトランザクションサービスシステムを示す図である。
【図２８】第２のＶｏｉｃｅ処理プログラムのフローチャートである。
【図２９】第１の競馬予想処理のフローチャートである。
【図３０】ＲＩＳサーバの情報を示す図である。
【図３１】データのデストリビューション処理のフローチャートである。
【図３２】競馬データファイルを示す図である。
【図３３】日付・ファイル名対応表を示す図である。
【図３４】各ファイルに含まれるデータを示す図である。
【図３５】第２の競馬予想処理のフローチャートである。
【図３６】複数のサーバが存在するシステムを示す図である。
【図３７】第２の初期設定ファイルを示す図である。
【図３８】第３の初期設定ファイルを示す図である。
【図３９】サーバ識別システムを示す図である。
【図４０】第２のログインシーケンスを示す図である。
【図４１】第３のログインシーケンスを示す図である。
【図４２】第３のアンカーファイルを示す図である。
【図４３】クライアントの処理のフローチャートである。
【図４４】リモートインストールのフローチャート（その１）である。
【図４５】リモートインストールのフローチャート（その２）である。
【図４６】リモートインストールのフローチャート（その３）である。
【図４７】ユーザＩＤ登録のフローチャートである。
【図４８】端末ＩＤ登録のフローチャートである。
【図４９】販売のフローチャートである。
【図５０】端末パスワードチェックのフローチャートである。
【図５１】場の構成を示す図である。
【図５２】作者の作業のフローチャートである。
【図５３】オリジナルクラブ管理者の作業のフローチャートである。
【図５４】転載先クラブ管理者の作業のフローチャートである。
【図５５】アップロードを示す図である。
【図５６】シェアウェア手続きを示す図（その１）である。
【図５７】シェアウェア手続きを示す図（その２）である。
【図５８】シェアウェア手続きを示す図（その３）である。
【図５９】シェアウェア手続きを示す図（その４）である。
【図６０】代金引き落とし手続きを示す図（その１）である。
【図６１】代金引き落とし手続きを示す図（その２）である。
【図６２】代金引き落とし手続きを示す図（その３）である。
【符号の説明】
１、２　環境ファイル
３、４　キーテーブル
５　チェックスクリプト
６　ファイル本体
７　インストールスクリプト
１１、１２、１３、１４　クラブ
１５　ソフトウェア
２１　ＣＦＧファイル
２２　説明ファイル
２３　インストール関連ファイル
２４　本体ファイル
２５　定義ファイル
２６　ＣＨＫファイル
２７　書換えファイル
２８　コンテンツデータベース
２９　メニュー
３０　ダイアログボックス
３１　メッセージ
８０　登録手段
８１　キー情報付与手段
８２　暗号化手段
８３　リモートインストール手段
８４　課金手段
８５、８７、８９、９０　処理手段
８６　ヘルパ手段
８８　ブラウザ手段
９１　トランザクション手段
９２　受信手段
９３　判定手段
９４　生成手段９４
９５、９９　格納手段
９６、１００　接続手段
９７　通信手段
９８　認証手段
１１１　ホスト計算機
１１２　ＲＩＳサーバ
１１３　ユーザ端末
１１４　ＷＷＷブラウザ
１１５　ＲＩＳクライアント
１１６　ＦＥＮＩＣＳ回線
１１７　インターネット
１２１　ＣＰＵ
１２２　メモリ
１２３　入力装置
１２４　出力装置
１２５　外部記憶装置
１２６　媒体駆動装置
１２７　ネットワーク接続装置
１２８　バス
１２９　可搬記録媒体
１３０　データベース
１３１　秘密キーデータベース
１３２、１７９　初期設定ファイル
１３３　Ｃｈａｌｌｅｎｇｅ発生関数
１３４　合成関数
１３５　暗号化プログラム
１３６　復号化プログラム
１４１　ソフト工房
１４２　ソフト工房ホームページ
１４３、１５３、１６３、１６７、１９２、１９３、１９４　Ｒｉｓアイコン
１４４、１５４、１６５、１７６、１７７、１９５、１９６、１９７　アンカーファイル
１５１　α商店
１５２　α商店ホームページ
１６１　占いの舘
１６２、１６６　占いの舘ホームページ
１６４　パスワード入力欄
１６８　占いサービスページ
１７１　ＶＯＩＣＥ工房サーバ
１７２、１９１　ＶＯＩＣＥ工房ホームページ
１７３、１７４、１７５、１８２、１８３、１８４　アイコン
１７８　Ｖｏｉｃｅ処理プログラム
１８０　占い結果
１８１　音声ファイル名入力欄
１８５　ファイルセレクタ
１８６　ＨＴＭＬファイル
２０１　信用できるホームページ

Claims (3)

1. サーバへのログイン時に、該サーバの認証鍵に基づく電子署名機能を用いて暗号化された指定情報を送受信する通信手段と、
   該指定情報を介してサーバの認証を行う認証手段と
   を備えることを特徴とするリモートインストールシステム。
2. サーバへのログイン時に、該サーバの認証鍵に基づく電子署名機能を用いて暗号化された指定情報を送受し、
   該指定情報を介してサーバの認証を行う
   ことを特徴とするリモートインストール方法。
3. コンピュータのためのプログラムを記録した記録媒体であって、
   サーバへのログイン時に、該サーバの認証鍵に基づく電子署名機能を用いて暗号化された指定情報を送受信する機能と、
   該指定情報を介してサーバの認証を行う機能と
   を前記コンピュータに実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images