JP2004005688A - Server and server operation method for kiosk device connected to computer network - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a server and the server operation method for the kiosk device connected to the computer network are offered. <P>SOLUTION: The server system 195 is connected to a plurality of kiosks 100 by a network 150 such as the Internet, an intranet and an extranet of an enterprise or the government. A kiosk has one or a plurality of input/output devices 130 (for example a display, a keyboard, a paper printer, a telephone set, etc.) and the one or a plurality of driver programs 440 (local API) for each input/output device. A kiosk 160 has a browser 160 used in order that the kiosk receives material from the server. One or a plurality of files of the files in a configuration set comprise one or a plurality of built-in-control programs 620 for controlling the local API for the device on the kiosk. Thus, the device is controlled so that the kiosk performs the application. <P>COPYRIGHT: (C)2004,JPO

Description

このアプレットがブラウザによって実行されると、まず、ｋｉｏｓｋＡｐｐＩｎｔｅｒｆａｃｅというクラスをインスタンス化する。このファイルおよび関連するＤＬＬは、ブラウザ標準ライブラリに入れられる。次に、ｓｅｎｄ＿ＡＰＩｍｅｓｓａｇｅ（）というｋｉｏｓｋＡｐｐＩｎｔｅｒｆａｃｅクラス（６４０Ａ）のメソッドを使用して、ＡＰＩメッセージ”ｑｕｅｒｙ＿ｓｔａｔｕｓ”（６４０Ａ）を送る。このメソッドは、プロセス間通信機能６４０Ｉを呼び出して、ＡＰＩ機構６４０Ｂにメッセージを送る。次に、ＡＩＰ機構６４０Ｂは、関連するローカルＡＰＩ関数６８０を呼び出してシステム状況データを入手し、そのデータをプロセス間通信機能６４０Ｉを介して６４０Ａに送り返す。アプレットは、メソッドｇｅｔ＿ＡＰＩｍｅｓｓａｇｅ（）をコマンド”ｓｔａｔｕｓ”と共に使用して、６４０Ｂから送り返されたデータを入手し、そのデータをｓｙｓＳｔａｔｕｓというクラス内のデータ構造に格納する。
【００５１】
６４０Ａと６４０Ｂとの間のＡＰＩメッセージ受渡しには、ネーム・サーバ機能機構（以下の図７を参照）を使用することができる。一般に、６４０Ｂがメッセージを入手すると、（６４０Ｂ内の）ネーム・サーバ機能がそのメッセージを解析し、対応するローカル機能ＡＰＩ６８０を呼び出す。この例では、システム監視関数ＡＰＩを呼び出してシステム状況データを入手する。これは、以下のように例示することができる。

上述のように”ｓｙｓＳｔａｔｕｓ”クラス・データ構造で入手されたデータの例を以下に示す。
Ｎｕｍ．　ｏｆ　Ｄｅｖｉｃｅ　＝　５
ｌａｓｅｒ　ｐｒｉｎｔｅｒ　＝　ＯＫ
ｃａｒｄ　ｒｅａｄｅｒ　＝　ＯＫ
ｃａｒｄ　ｉｓｓｕｅｒ　＝　ｎｏ　ｃａｒｄ　ｓｕｐｐｌｙ
ｒｅｃｅｉｐｔ　ｐｒｉｎｔｅｒ　＝　ＯＫ
ｔｉｃｋｅｔ　ｐｒｉｎｔｅｒ　＝　ＯＫ
このメッセージは、キオスク上に５個の装置があり、カードを必要とするカード発行機以外はすべて動作していることを示している。
【００５２】
キオスクの現況に従って、アプリケーション・ファイル１７５は、レーザ・プリンタ、受領書プリンタ、およびカード読み取り機（装置サブセット４５１）を選択して使用することができると同時に、状況データが示すようにカード読み取り機のカード供給機構にカードが入っていないため、カード発行機の使用を回避する（このような状況では、カードは他の手段で作成し、キオスクのユーザに郵送される）。
【００５３】
ある種の好ましい実施形態では、このような技法を使用して、キオスクにどの装置が備えられているか、それらの装置が正常に機能しているかどうかを判断する。このようにして、サーバは、キオスクがどの装置を備えているかやどの装置が動作可能かに基づいて、キオスクを構成するための特定のアプリケーション・ファイル１７５を供給することができる。したがって、それぞれのアプリケーション構成のためにサーバでアプリケーション・ファイルを適切に選択することにより、任意の数の異なるキオスク設計や動作状況を構成することができる。たとえば、銀行業務アプリケーションでは、高品質の銀行取引明細書を印刷するためにレーザ・プリンタを備えたキオスクにはレーザ・プリンタ制御を含むアプリケーション・ファイルとして構成されるファイル５００が送られるのに対し、それと同じタスク（銀行取引明細書）のために（使用可能かつ動作可能な）受領書プリンタしか持っていないキオスクには、受領書プリンタ制御を含むアプリケーション・ファイルとして構成される他のファイル５００が送られる。このようにして、誤動作するレーザ・プリンタを備えたキオスクや、レーザ・プリンタのないより低コストのキオスクでも、銀行アプリケーション用に適切に構成することができる。
【００５４】
他の実施形態では、１つまたは複数のサーバがアプリケーション・ファイルで要求を送ることによって状況情報を要求することができる。この情報を使用して、サービスの提供を必要とするキオスクまたはそれらのキオスク上の装置あるいはその両方を判断することができる。たとえば、必要な場合にサービス技術員を派遣してカード発行機にカードを追加することができる。
【００５５】
他の実施形態では、キオスクまたは装置のサービス履歴で使用するために状況情報を要求することができる。さらに、他のマーケティング情報、たとえば、特定の設置場所でどのクラスの顧客によってどの構成が最も要求されるかという情報を入手することもできる。
【００５６】
好ましい一実施形態では、キオスクは、他のアプリケーションのバックグラウンドで実行されるブラウザ・ウィンドウ（システム監視アプリケーション・ウィンドウ）を有することができる。このシステム監視アプリケーション・ウィンドウは、１つまたは複数のサーバと通信する１つまたは複数のアプレットを含む１つまたは複数のＨＴＭＬファイルを含むことができる。（サーバとのＪａｖａ（登録商標）アプレット通信のための機構は周知である。）このシステム監視アプリケーション・ウィンドウは、キオスクに電源投入されると常に開始することができ、キオスクが動作中である限り稼働し続ける。このようにして、１つまたは複数のサーバが、アプレットとの通信を介して随時、キオスクのシステム状況情報を入手することができる。
【００５７】
本明細書に記載の手法によって得られる可能性の中には以下のものがある。
１）「軽量クライアント」キオスク。キオスクに事前インストールする必要があるアプリケーション固有ソフトウェアがないため、コスト効果の高いキオスクの構築と維持を行うことができる。したがって、サーバ上で１つのアプリケーション（アプリケーション・ファイル５００）を作成し、それをそのサーバに接続されているネットワーク上の多数の「軽量」キオスクが使用することができる。ネットワーク上の「軽量」キオスクのいずれのためにもアプリケーション固有のソフトウェアを作成する必要がない。実際には、ネットワークは、アプリケーション固有ソフトウェアをまったく持たない１つまたは複数の標準（したがってより安価な）「軽量」キオスクで構成することができる。（たとえば、キオスク製造業者は、どの用途にも使用され、どの用途からも独立した１つまたは複数の標準キオスクを製造することができる。）アプリケーション・ファイル５００をサーバで作成、更新、保守することができ、キオスク内のどのプログラミングにも変更を加えることなく、ネットワーク上の１つまたは複数のキオスクを再構成するために使用することができる。この「軽量クライアント」キオスクは、いつでもどこでも汎用公共アクセスを提供するためのキオスクの大量配備を可能にし、たとえばインターネットまたは電話網あるいはその両方を介して通信することができる「キオスク電話」を可能にする。
【００５８】
２）キオスクが再構成可能であるため、サーバで多数の多様なアプリケーションを開発することができ、そのキオスクを介して配布することができる。したがって、アプリケーション提供者はネットワーク上にあるどのキオスクでも共用することができる。これらのアプリケーションは、特定の時点や特定の状況、たとえばユーザ要求または所与の環境条件（雨が降り出した時に傘店が広告を出すなど）のために、キオスクに供給することができる。
【００５９】
３）キオスクはインターネットおよびウェブのオープン・スタンダード技術に基づくことができるため、情報や媒体が豊富で、技術に富むインターネットおよびワールド・ワイド・ウェブの利点を利用することができる。
【００６０】
ユーザがこのキオスク１００をどのように使用できるかを示すいくつかの非限定的な例を以下に示す。
１．遊休時におけるキオスクの画面によって、様々な画像、ビデオ・クリップ、音声、グラフィクス・パターンおよびテキストを動的に表示する。画面の内容はすべてＨＴＭＬファイルから制御され、これらのＨＴＭＬファイルはキオスクの要求またはサーバのプッシュに基づいて更新される。サーバ提供者は、この異なる種類の画面「スペース」およびその表示時間に対して異なる料金を支払うことができる。朝と夕方の通勤時間には、主にヘッドライン・ニュースと金融市場の変化を表示し、昼食時間には多くのレストランの宣伝を表示する。週末には、百貨店の特売広告を表示することもできる。この内容は、そばを通る人々を常に、画面にタッチするように誘う。
２．ユーザは画面を見て歩み寄り、画面にタッチする。画面はただちに次の画面に切り替わり、アプリケーションのカテゴリを示す多くの画像アイコンとテキストを表示する。
３．ユーザがピザ注文アイコンにタッチすると、ユーザがピザの種類を選択することができる画面が提示される。画面は、ユーザに対してピザの配達場所と時間の入力を促し、ユーザは画面上のタッチ・キーパッドを介して情報を入力することができる。ＨＴＭＬ内に組み込まれた制御プログラム６２０がこのデータを取り込む。次に、画面はユーザに対して自分のクレジット・カードを挿入して支払いを認めるように促す。制御プログラムは、カード読み取り機を開き、クレジット・カード情報を取り込む。次に、制御プログラムは関連するキオスクＡＰＩ関数を使用してキオスク上で通信機能を呼び出し、（たとえばモデムを介して）クレジット・カード会社と（たとえばファクス伝送を介して）ピザ店とにアクセスする。これらの機能が完了した後、画面は顧客に注文のための情報を確認する。その他の一般小売業トランザクションも同様にして行うことができる。
４．ユーザは、電話アイコンにタッチして電話を掛けることもできる。画面上に電話アプリケーションＨＴＭＬファイルが電話キーパッドと共に表示される。ユーザが番号を入力した後、組込み制御プログラムが関連ＡＰＩ関数６４０Ａを呼び出し、電話呼出しを開始する。これは、キオスクのネットワーク接続（１２２、１２３、１５０）、アプリケーション・ファイル５００、およびユーザ選択１０５Ａに応じて、公衆電話網（ＰＳＴＮ）、統合サービス・ディジタル網（ＩＳＤＮ）、またはインターネット電話を介した従来の電話呼出しとすることができる。電話が接続されると、ユーザはキオスクに備えられた送受話器またはスピーカフォンを使用することができる（欧州特許出願第７８９４７０号に対応する、１９９６年２月６日出願の「Ｍｕｌｔｉｐｏｉｎｔ　Ｓｉｍｕｌｔａｎｅｏｕｓ　Ｖｏｉｃｅ　ａｎｄ　Ｄａｔａ　Ｓｅｒｖｉｃｅｓ　Ｕｓｉｎｇ　ａ　Ｍｅｄｉａ　Ｓｐｌｉｔｔｅｒ　Ｇａｔｅｗａｙ　Ａｒｃｈｉｔｅｃｔｕｒｅ」という名称のホルテンシウス（Ｈｏｒｔｅｎｓｉｕｓ）等の米国特許出願第０８／５９５８９７号を参照されたい。これは、参照によりその全体が本明細書に組み込まれる）。
【００６１】
他の好ましい実施形態では、ユーザは相手方が同じ機能を備えていればアプリケーション共用機能を使用してテレビ電話呼出しまたはテレビ会議呼出しも選択することができる。その場合、ＨＴＭＬアプリケーションに組み込まれた制御プログラム６２０が関連ＡＰＩ関数６４０Ａを呼び出して、キオスクのテレビ会議機能を開始する。ユーザはキオスクに備えられたタッチ・スクリーンと電子ペンを使用して会話を容易にすることができる（前述のフィン等の「Ｉｎｔｅｒｎｅｔ　Ｗｅｂ　Ｐａｇｅ　Ｓｈａｒｉｎｇ」特許出願に記載されている）。
５．ユーザはファクス機能を選択することもできる。画面は、ユーザに対して指示を出して、ファクス番号を入力し、クレジット・カードを挿入してファクスする文書を適切な装置（文書スロットなど）に入れ、準備が整ったら画面上のＯＫボタンにタッチするように促す。ボタンにタッチすると、組込み制御プログラム６２０がキオスク上で関連装置制御ＡＰＩ関数６４０Ａを呼び出し、スキャナを動作させ、文書を走査して文書を返し、ネットワーク、たとえばＰＳＴＮやインターネットを介して文書を電子送信する。
６．ユーザは、電子メール機能を選択することもできる。画面は、電子メール用のＨＴＭＬアプリケーションを表示する。組込み制御プログラム６２０が関連ＡＰＩ関数６４０Ａを呼び出すか、またはブラウザを介してメール・サーバおよびディレクトリ・サーバと直接通信し、ユーザを識別し、既存の電子メール・メッセージの取出しまたは新規メッセージの送信を行う。
７．ユーザは、フロッピィ・ディスケットなどの媒体上の電子ファイルを転送する１０５Ａを選択することもできる。画面は、ユーザに対して特定のプロセスに従うように、たとえばフロッピィをスロットに挿入するように促す。組込み制御プログラム６２０が関連ＡＰＩ関数６４０Ａを呼び出し、ディスケットを読み取り、ユーザが選択したファイルの読み取りまたは書込みを行い、それを、たとえば誰かの電子メール・アドレスに送信するなど、ユーザの指示に従って転送する。
８．ユーザは、弁護士、医師、会計士、不動産業者、融資ブローカー、投資顧問業者、保険業者など、広範なサービス提供者（たとえばサーバ上のアプリケーション所有者）の中からサービスを選択することができる。画面は、ＨＴＭＬファイル内の対応するアプリケーションを表示し、要求されたサービスを供給する（ユーザ選択に基づき、このサービスは、英語、スペイン語、中国語、日本語、フランス語、イタリア語など、任意の自然言語で提示することができる。）
９．サービス提供者のアプリケーションによっては、映像、音声、共用画面、および遠隔装置制御機能を使用して、リアルタイム協同セッションも開始することができる（前述したフィン等の特許を参照）。組込み制御プログラムが関連ＡＰＩ関数６２０を呼び出し、映像、音声、およびデータ通信を処理する。
１０．ユーザは、情報の検索を選択することができる。画面がユーザにどのような情報が必要かを入力するように促し、組込制御プログラムがそのデータを取り込み、情報のタイプの応じて照会を送る。照会は、インタフェースを介して、周知の検索エンジン、アプリケーション・サーバ上のデータベース、および他のネットワーク・サーバ上のデータベースを使用して送ることができる。
１１．ユーザは、カスタマイズされたアプリケーション・サーバを選択することができる。たとえば、ユーザが（たとえば磁気カードまたはスマート・カード上でアクセスされた情報から）識別されると、アプリケーション・ファイルは、ユーザのためにカスタマイズされた情報やキオスク構成を提供する。
１２．ユーザは、キオスク１００によって最初に提供される構成ではないキオスク１００の構成を選択することができる。キオスクの第１の構成と対話することによって、他のアプリケーション・ファイル１７５の参照によってキオスクを第２の構成に再構成することができる。たとえば、第１の構成が、第２の構成のためのアプリケーション・ファイル１７５にアクセスするユーザ入力（アイコンまたはハイパーリンク）を備えることができる。
１３．ユーザは、サーバが「学習」アプリケーション・ファイル１７５を提供する、ネットワークに接続された１つまたは複数のキオスクにアクセスすることができる一人または複数の学生または受講者とすることができる。
１４．ユーザは、キオスクから「電子」製品を選択することができる。たとえば、音楽、ビデオ、コンピュータ・ソフトウェア、またはその他のマルチメディア情報あるいはそれらの組合せを有するコンパクト・ディスク（ＣＤ）を、適切なディスペンサから販売することができる。あるいは、適切なキオスク装置によって空の媒体（たとえばテープ、ディスケット、書込み可能ＣＤなど）に書き込み、ネットワークを介してユーザに伝送可能な「電子」情報を無形の形態で提供することもできる。たとえば、最新のオペラ録音を、工場で「カット」されたＣＤを送らずに、ＣＤで提供することができる。
【００６２】
キオスク装置との間で情報の入出力を行うために使用される、ある種のキオスク制御機構６４０の他の例を以下に示す。一般的入力状況で、アプリケーション・ファイル５００は、ＡＰＩ関数６４０「ｈａｒｄｋｅｙ＿ｉｎｐｕｔ」を呼び出すために使用されるＣｌｌＡＰＩ．ｃｌａｓｓというアプレットを有する。たとえば、以下の通りである。
【００６３】

【００６４】
このアプレットを以下のようにＨＴＭＬファイルに組み込む。
【００６５】

【００６６】
このアプレットは、ブラウザによって実行されると、まず、ｋｉｏｓｋＡｐｐＩｎｔｅｒｆａｃｅというクラスをインスタンス化する。このファイルおよび関連ＤＬＬは、ブラウザ標準ライブラリに入れられる。次に、ｓｅｎｄ＿ＡＰＩｍｅｓｓａｇｅ（）というｋｉｏｓｋＡｐｐＩｎｔｅｒｆａｃｅクラス（６４０Ａ）のメソッドを使用して、ＡＰＩメッセージ「ｈａｒｄｋｅｙ＿ｉｎｐｕｔ」（６４０Ａ）を送る。このメソッドは、プロセス間通信機能６４０Ｉを呼び出して、メッセージをＡＰＩ機構６４０Ｂに送る。次に、ＡＰＩ機構６４０Ｂが関連ローカルＡＰＩ関数６８０を呼び出し、キオスクに備えられたハードウェア・キーからのキー入力を取り込み、それをプロセス間通信機能６４０Ｉを介して６４０Ａに送り返す。このアプレットは、コマンド「ｉｎｐｕｔ」と共にｇｅｔ＿ＡＩＰｍｅｓｓａｇｅ（）を使用して、６４０Ｂから送られたデータを入手し、ＩｎｐｕｔＤａｔａというクラス内のデータ構造に格納する。
【００６７】

【００６８】
アプリケーション・ファイル５００が、「ソフト・キー」入力を呼び出す組込みアプレットを有する場合も、同様のＡＰＩメッセージが６４０Ａと６４０Ｂの間で受渡しされ、異なるＡＰＩ関数６８０を使用して画面上にソフトキー・パッド・ウィンドウを「ポップアップ」表示し、ユーザ入力を取り込むことに留意されたい。このようなソフト・キー入力のためのＡＰＩ関数６８０は周知である。
【００６９】
同様にして、アプリケーション・ファイル５００が、出力装置、たとえばレーザ・プリンタ上でのファイルのプリントを呼び出す場合、組込みアプレットを有する場合、上記のコードはローカルＡＰＩ関数６８０のＬａｓｅｒ＿ｐｒｉｎｔ（ＦｉｌｅＮａｍｅ）に指示して、レーザ・プリンタを制御し、ファイル「ＦｉｌｅＮａｍｅ」をプリントさせる。
【００７０】
図７に、ＩＣＰ６４０Ｉおよびネーム・サーバ機能６４０Ｂを使用するキオスク制御機構６４０の一実施形態を示す。この場合、アプリケーション・ファイル（１７５、５００）によって、（主としてメッセージ受渡しのための）汎用通信ＡＰＩ関数６４０Ａの小さな固定セットが使用される。これらの通信ＡＰＩ関数は、６４０Ａと６０Ｂとの間でメッセージの通信または受渡しを行う。メッセージの実行は、６４０Ｂ内のネーム・サーバ機能によって行われる。サーバ機能６４０Ｂは、ＩＰＣ６４０Ｉサーバとしての機能する。ネーム・サーバ機能は、様々な事前定義メッセージを認識する。たとえば、一実施形態では、通信ＡＰＩのセットは、ｓｅｎｄ＿ｍｅｓａｇｅ（ｍｅｓｓａｇｅ）とｇｅｔ＿ｍｅｓｓａｇｅ（ｍｅｓｓａｇｅ）の２つの関数を有する。しかし、複数の「ｍｅｓｓａｇｅ」がある。６４０Ｂ内のネーム・サーバ機能は、これらの各事前定義メッセージが入ったリストを融資、各事前定義メッセージは、それぞれの事前定義メッセージを実行するために適切なローカルＡＰＩ関数６８０を呼び出すことができる１組の論理に関連づけられている。
【００７１】
この実施形態では、新しい事前定義メッセージと、新しい機能を実行するのに必要な論理とを与えることによって、新しい装置やそれらの新しい装置によって実行される新しい機能を追加することができる。このようにして、アプリケーション・ファイル（１７５、５００）は、与えられた通信ＡＰＩ関数において新しいメッセージ識別子を使用するだけで、それらの新しい機能を実行することができる。これには、典型的には、アプリケーション・ファイル５００内で「ＡＳＣＩＩ」または「ｔｅｘｔ」メッセージ識別子を変更するだけでよい。新しい機能を使用するために、新しい組込みプログラムのコード化とコンパイルを行ったり、既存のプログラムを修正したりする必要はない。したがって、キオスク提供者が必要な論理をネーム・サーバ６４０Ｂにすでに組み込んでいるため、アプリケーション所有者（したがってサーバ上のアプリケーション・ファイル）が新しい機能を実行するためにしなければならないことはわずかしかない。
【００７２】
図８は、ブラウザ機構６４０Ａにおけるマッピング・ローカルＡＰＩのためのＩＰＣ６４０Ｉを使用するキオスク制御機構６４０の代替実施形態を示すブロック図である。この例では、多くのキオスク制御関数６２０またはすべてのキオスク制御関数６２０が、ブラウザ機構６４０Ａでアプリケーション・ファイル５００から対応するマッピング・ローカルＡＰＩを直接呼び出すことによって実行される。各マッピング・ローカルＡＰＩ６４０Ａは、ＩＰＣ６４０Ｉを介してＡＰＩ機構６４０Ｂと連絡し、ＡＰＩ機構６４０Ｂが適切なローカルＡＰＩ関数６８０を呼び出す。ここでは、マッピング・ローカルＡＰＩ６４０Ａは、Ｊａｖａ（登録商標）　ＡＰＩプログラムである。１つまたは複数のローカルＡＰＩ６８０のために特に作成された１つのＪａｖａ（登録商標）　ＡＰＩプログラムがある。ネーム・サーバの場合とは異なり、Ｊａｖａ（登録商標）　ＡＰＩプログラムのうちの少なくとも１つのＡＰＩプログラムが、ローカルＡＰＩ６８０のうちの１つまたは複数のローカルＡＰＩ６８０を制御する論理を持っていなければならない。これらのＪａｖａ（登録商標）　ＡＰＩプログラム６４０は事前定義され、アプリケーション・ファイル５００にとって既知である。
【００７３】
この実施形態では、ブラウザ機構６４０Ａ内に新しいマッピング・ローカルＡＰＩ（６４０Ａ）をそれらに対応するＡＰＩ機構６４０Ｂと共に設けることによって、新しい装置やそれらの装置によって実行される新規機能を追加することができる。この実施形態では、アプリケーション・ファイル５００は、これらの各新規機能を直接呼び出しで実行する必要がある。したがって、新規機能を実行するための論理の一部または全部を、アプリケーション・ファイル５００に定義する必要がある。たとえば、サーバでアプリケーション・ファイル５００を作成するアプリケーション・プログラマは、たとえば新しいＪａｖａ（登録商標）アプレットを作成することによってこの新しい論理をコード化する必要がある。
【００７４】
図９に、キオスク制御機構６４０の他の実施形態を示す。この実施形態では、ＩＰＣ６４０Ｉがなく、したがってＡＰＩ機構６４０Ｂはブラウザ機構６４０Ａにマージされる。しかし、ネーム・サーバ機能（やはりマージされる）は使用され、通信ＡＰＩのセットと組み合わされて、ブラウザ機構（６４０Ｂ、６４０）になる。この実施形態では、（アプレットを含む）アプリケーション・ファイル５００がブラウザ１６０によって「除去（ドロップ）」され、ローカル機能６８０が終了するため、持続性が失われる。この実施形態は、持続性が不要な場合、たとえば、ブラウザによって制御される画面以外に必要なキオスク装置がない場合に有用である。
【００７５】
図１０に、キオスク制御機構６４０の他の実施形態を示す。この実施形態には、ＩＰＣ６４０ＩとＡＰＩ機構６４０Ｂがまったくない。この場合は、アプレットがＡＰＩ関数（６４０、６４０Ａ）を直接呼び出し、ＡＰＩ関数がローカルＡＰＩ関数６８０を直接呼び出す。ここでは、ＡＰＩ関数６４０はＪａｖａ（登録商標）　ＡＰＩプログラムである。１つまたは複数の各ローカルＡＰＩ６８０のために特に作成された１つのＪａｖａ（登録商標）　ＡＰＩプログラムがある。ネーム・サーバの場合とは異なり、Ｊａｖａ（登録商標）　ＡＰＩプログラムのうちの少なくとも１つのＪａｖａ（登録商標）　ＡＰＩプログラムが、ローカルＡＰＩ６８０のうちの１つまたは複数のローカルＡＰＩプログラムを制御する論理を持っていなければならない。これらのＪａｖａ（登録商標）　ＡＰＩプログラム６４０は事前定義され、アプリケーション・ファイル５００にとって既知である。この実施形態でも持続性は失われる。
【００７６】
図１１は、キオスクによって行われる実行プロセス７００のフローチャートである。
【００７７】
まず、ブラウザ１６０がアプリケーション・ファイル１７５から（ＨＴＭＬ）ファイル５００を入手する７０５。次に、ブラウザ１６０は、アプリケーション・ファイル５００のタグと内容を解釈する７１０。ブラウザ１６０がローカルＡＰＩ呼び出しに遭遇しない場合７１５、ブラウザは関連する周知の処置を行って７２０、タグを実行する。ブラウザがローカルＡＰＩ呼び出しに遭遇した場合７１５、ブラウザは関連ＡＰＩ関数（６４０または６４０Ａ）を呼び出す７２５。
【００７８】
好ましい一実施形態では、ブラウザ機構６４０Ａはプロセス間通信機能６４０Ｉを介してＡＰＩ機構６４０Ｂにメッセージを伝える７３０。あるいは、前述のようにメッセージ・サーバが使用される。ＡＰＩ機構６４０Ｂはメッセージを受け取り、関連ローカル機能６８０を呼び出す７３５。ＡＰＩ機構６４０Ｂは、プロセス間通信機能６４０Ｉを介してブラウザ機構６４０Ａにローカル機能の実行結果についてのメッセージを伝える７４０。
【００７９】
ブラウザは、画面入力、組込み制御プログラム論理、または外部ブラウザ制御機能６６０を介して制御され、次のＨＴＭＬファイルを要求する。このようにして、ブラウザをローカル・キオスク装置として扱うことができる。したがって、ブラウザを制御して、ローカルＡＰＩ６６０を使用して周知のブラウザ・インタフェース（ＡＰＩ６８１）にアクセスすることによって、ネットワークを介して１つまたは複数のサーバから任意の特定のＨＴＭＬファイルをロードすることができる。ローカルＡＰＩ６６０は、組込み制御プログラム６２０がブラウザ・イン６８１にアクセスすることができるようにするように作成される（上記参照）。
【００８０】
図１２は、ネットワーク上の１つまたは複数のサーバで実行されるサーバ・プロセス８００のフローチャートである。サーバが、ネットワークを介して１つまたは複数のキオスクから要求を受け取る８１０。この要求では、アプリケーション・ファイル１７５のうちのどのアプリケーション・ファイル１７５がキオスクによって選択／アクセスされるかが識別される。この要求は、アプリケーション・ファイルの要求／アクセスを行っているキオスク１００の設置場所も含む。サーバは、要求を受け取ると、要求されたアプリケーション・ファイル１７５をキオスクに送る８２０。アプリケーション・ファイル１７５は、サーバ上の論理によって事前作成または動的に生成することができる。
【００８１】
他の実施形態では、キオスクはプロキシ・サーバ１９５Ａに要求を送る８１０。プロキシ・サーバ１９５Ａは、典型的にはサーバ１９５よりもキオスクの近くに配置される。あるいは、プロキシ・サーバ１９５Ａは、キオスク１００／２００ないのコンピュータ上に配置することもできる。たとえば、サーバ１９５は第１の都市、たとえば本社の所在地に配置され、プロキシ・サーバ１９５Ａは異なる都市にあるキオスクに接続されたＬＡＮ上に配置することができる。プロキシ・サーバ１９５Ａは、事前定義されたスケジュールに従ってキオスクが必要とする多くのアプリケーション・ファイル１７５またはすべてのアプリケーション・ファイル１７５を求める要求をネットワーク１５０を介してサーバに送ることができる。このようにして、キオスクは、アプリケーション・ファイルを必要とするとき、プロキシ・サーバ１９５Ａ上のアプリケーション・ファイル１７５に、より高速に、より高い信頼性をもってアクセスすることができる。さらに、プロキシ・サーバは、ネットワーク上の「オフ・ピーク」時間中にサーバ１９５に対してアプリケーション・ファイル１７５を要求することができる。
【００８２】
他の実施形態では、サーバ（１９５、１９５Ａ）を使用して、サーバ１９５によって識別された１つまたは複数のキオスクに情報を「プッシュ」することができる。たとえば、ステップ８１０で、サーバ１９５で要求が開始される。この開始８１０は、様々な理由で行われるようにすることができる。たとえば、アプリケーションを更新するには、新しいアプリケーション・ファイル１７５を使用して１つまたは複数のキオスクを再構成する必要がある。あるいは、毎日特定の時刻に新しい構成の提供、すなわち毎日午後５時に異なる情報源からのニュースの提供を必要とする場合がある。サーバは、キオスクの定期「点検」を「プッシュ」して、どのキオスクが保守を必要としているかを判断することもできる。
【００８３】
この実施形態の好ましい一実施態様は、キオスクで稼働する「サーバ・プッシュ機能」６８５を使用する。サーバ・プッシュ機能６８５は、ネットワーク１５０に接続され、サーバ１９５からメッセージを受け取ることができる。サーバ・プッシュ機能６８５は、ブラウザ・インタフェース６８１にもアクセスすることができる。サーバ１９５は、ブラウザにサーバ１９５に対して特定のアプリケーション・ファイル５００を要求させる要求を、サーバ・プッシュ機能６８５に送る。
【００８４】
図１３は、組込み制御プログラムがＪａｖａ（登録商標）の代わりにＡｃｔｉｖｅＸ技法を使用する場合の機構を示すブロック図である。ＡｃｔｉｖｅＸ制御オブジェクトは、Ｃ＋＋やＶｉｓｕａｌ　Ｂａｓｉｃ、Ｊａｖａ（登録商標）などの様々なプログラミング言語を使用して実現可能である。ＡｃｔｉｖｅＸオブジェクトは、ＨＴＭＬファイルに組み込むことができる。たとえば以下の通りである。
【００８５】

【００８６】
この場合、ブラウザはＡｃｔｉｖｅＸ使用可能でなければならない。すなわち、ＡｃｔｉｖｅＸ技法をサポートしていなければならない。一実施形態では、ブラウザはＭｉｃｒｏｓｏｆｔ　Ｉｎｔｅｒｎｅｔ　Ｅｘｐｌｏｒｅｒである。
【００８７】
アプリケーション・ファイル５００がブラウザ１６０に到着すると、ＨＴＭＬファイルがそのタグと内容に基づいて解釈される９１０。前述のＪａｖａ（登録商標）の場合と同様に、ブラウザは前述のように非ＡＰＩ制御関数を実行する９２０。ブラウザによって実行されたＡＰＩ制御関数９３０がＡＰＩ９４０を直接呼び出す。Ｊａｖａ（登録商標）の場合と同様に、ＡＰＩの最初の部分９４０Ａがプロセス間通信機能９４０Ｉを介してＡＰＩの第２の部分（たとえば６４０Ｂ）と連絡し９４０Ｂ、この第２の部分がローカルＡＰＩ６８０を呼び出す。
【００８８】
ＡｃｔｉｖｅＸと前述のＪａｖａ（登録商標）の場合との相違は、ＡｃｔｉｖｅＸは、Ｃ＋＋やＶｉｓｕａｌ　Ｂａｓｉｃなどの非ネットワーク言語で作成されたオブジェクトを含むことができることである。これらの言語のオブジェクトは、実行可能コードでブラウザにダウンロードされる。したがって、このようなオブジェクトは、同じ言語で作成されたプログラムが行えることはどのようなことでも行うことができるが、Ｊａｖａ（登録商標）アプレットが持っているようなセキュリティ上の制限を持たない。したがって、組込み制御プログラム６２０を、非Ｊａｖａ（登録商標）言語を使用してＡｃｔｉｖｅＸ制御プログラムとして作成した場合、ＡＰＩ関数９４０はキオスク内の任意のどこにでも入れることができる。ＡｃｔｉｖｅＸオブジェクトでＪａｖａ（登録商標）を使用する場合は、やはり前述の機構を使用しなければならない。
【００８９】
図１４から図１７で、前述の番号が付いたボックスは前述と同様の機能を有する。
【００９０】
図１４に、ＩＰＣおよびネーム・サーバ機能を使用するキオスク制御機構９４０の一実施形態を示す。ブラウザ機構９４０Ａは、ブラウザ・ディレクトリに入れる必要がなく、キオスクのメモリ内の任意の場所、たとえばキオスクのシステム・ディレクトリに入れることができるネイティブ言語ＡＰＩである。しかし、ブラウザ機構９４０Ａのパス（すなわち場所）は、アプリケーション・ファイル５００にわかっていなければならない。
【００９１】
図１５は、ＩＰＣ６４０Ｉをマッピング・ローカルＡＰＩと共に使用するキオスク制御機構９４０の他の実施形態を示すブロック図である。図８と同様、ローカルＡＰＩ６８０のうちの１つまたは複数のローカルＡＰＩ６８０のための少なくとも１つのブラウザ機構９４０がある。
【００９２】
図１６に、ＩＰＣ６４０Ｉのないキオスク制御機構９４０の他の実施形態を示す。この場合、ブラウザ機構９４０Ａは図１４で前述したように配置することができる。
【００９３】
図１７に、制御をＪａｖａ（登録商標）で実施しない場合にＡｃｔｉｖｅＸ制御を使用するキオスク制御機構の他の実施形態を示す。この実施形態では、そのような組込みＡｃｔｉｖｅＸ制御がローカルＡＰＩ６８０を直接呼び出すことができるため、９４０はまったく不要である。この場合、実行の持続性は失われる。
【００９４】
図１８に、いわゆるプラグイン技法を使用する他のキオスク制御機構を示す。この場合、好ましい実施形態はＮｅｔｓｃａｐｅ　Ｎａｖｉｇａｔｏｒ　ｖ３．０またはそれ以降のブラウザを使用する。
【００９５】
ここでは、制御機構１０４０は、ブラウザ機構（プラグイン・モジュールおよびそれに付随するＪａｖａ（登録商標）ラッパ）１０４０Ａを含み、このブラウザ機構にアプリケーション・ファイル／ファイル（１７５、５００）内のキオスク制御プログラム（６２０）がアクセスする。プラグイン・モジュール１０４０Ａは、アクセスされると、ブラウザ１６０の一部として実行される。実行プラグイン・モジュール１０４０Ａは、プロセス間通信機能１０４０Ｉを呼び出す。このプロセス間通信機能（ＩＰＣ）１０４０Ｉは、前述のＩＰＣ（６４０Ｉ、９４０Ｉ）と同じものとすることができる。ＩＰＣ１０４０Ｉは、ＡＰＩ機構１０４０Ｂと連絡してローカルＡＰＩ６８０を呼び出す。ＡＰＩ機構１０４０Ｂは、前述の機構（６４０Ｂ、９４０Ｂ）と同じものとすることができる。
【００９６】
この実施形態では、ブラウザ機構１０４０Ａはプラグイン技法（ザン・オリファント（Ｚａｎ　Ｏｌｉｐｈａｎｔ）の「Ｐｒｏｇｒａｍｍｉｎｇ　Ｎｅｔｓｃａｐｅ　Ｐｌｕｇ−ｉｎｓ」（Ｓａｍｓ．ｎｅｔ、１９９６年刊、ＩＳＢＮ１−５７５２１−０９８−３）を参照）によって実施される。プラグイン技法は、ネイティブ・コード・モジュールを使用する。すなわち、ＣまたはＣ＋＋あるいは同様のプログラミング言語を使用して実施され、さらに、より好ましい実施形態ではＪａｖａ（登録商標）ラッパでも実施される。プラグイン１０４０Ａは、ブラウザ１６０によって指定された特別なプラグイン・ディレクトリに入れられる。ＨＴＭＬインタプリタ６１０が、マルチパーパス・インターネット・メール・エクステンション（ＭＩＭＥ）タイプとも呼ばれる組込みファイル内の固有ファイル名拡張子によってそれぞれのプラグイン１０４０Ａを識別する組込みファイル（６２０）に遭遇すると、プラグイン１０４０Ａはブラウザ１６０に動的にロードされる。
【００９７】
組込みキオスク制御プログラム（６２０）は、１）Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ関数、２）Ｊａｖａ（登録商標）アプレット、または３）固有拡張子を持つＭＩＭＥファイルに含まれる事前定義された１組の制御スクリプトとすることができる。
【００９８】
ブラウザ１６０がプラグイン・モジュール１０４０Ａをロードすると、プラグイン１０４０ＡはＨＴＭＬ文書に使用可能になる。すなわち、プラグイン内の関数（プラグイン関数）が組込みプログラム（６２０）、たとえば呼び出すＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数またはＪａｖａ（登録商標）アプレット関数に使用可能になる。これを行う際、キオスクのローカルＡＰＩ６８０を１つまたは複数の対応するプラグイン１０４０Ａを介して所与の組込みプログラム６２０によって制御することができる。言い換えると、プラグイン・モジュール１０４０ＡはＩＰＣ関数１０４０Ｉを呼び出して、対応するＡＰＩ機構１０４０Ｂを介してキオスクのローカルＡＰＩ６８０を呼び出す。
【００９９】
非限定的な３つの例を以下に示す。
【０１００】
例１は、組込みキオスク制御プログラム１０３０としてＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数を、メッセージ受渡機能を備えるプラグイン・モジュール１０４０Ａと共に使用する。
【０１０１】
制御プログラム１０３０を有するアプリケーション・ファイル１７５は、以下の通りである。
【０１０２】

【０１０３】
Ｊａｖａ（登録商標）アプレット「ＭＹＡＰＰＬＥＴ．Ｊａｖａ」には以下のようなコードが含まれる。
【０１０４】

【０１０５】
Ｊａｖａ（登録商標）ラッパ・ファイルＰｌｕｇｉｎＷｒａｐｐｅｒ．ｊａｖａには、以下のコードが含まれる。
【０１０６】

【０１０７】
上記の組込み制御プログラム１０３０に関連づけられたプラグイン・モジュール１０４０Ａは、とえばＣ＋＋などのネイティブ言語コードで実施されたメソッドＳｅｎｄＭｓｇ（）を提供する。
【０１０８】
例２は、メッセージ受渡し機能を備えるプラグイン・モジュール１０４０Ａと共に、組込みキオスク制御プログラム１０３０としてＪａｖａ（登録商標）アプレットを直接使用する。
【０１０９】
制御プログラム１０３０を有するアプリケーション・ファイル１７５は以下の通りである。
【０１１０】

【０１１１】
Ｊａｖａ（登録商標）アプレット「ＭＹＡＰＰＬＥＴ．Ｊａｖａ」には以下のようなコードが含まれる。
【０１１２】

【０１１３】
Ｊａｖａ（登録商標）ラッパ・ファイルＰｌｕｇｉｎＷｒａｐｐｅｒ．ｊａｖａには以下のコードが含まれる。

【０１１４】
例１と同じように、上記のプラグイン組込み制御プログラム１０３０に関連づけられたプラグイン・モジュール１０４０Ａが、たとえばＣ＋＋などのネイティブ言語で実施されたメソッドＳｅｎｄＭｓｇ（）を提供する。
【０１１５】
例３は、１組の事前定義制御スクリプトと、キオスク・ローカルＡＰＩ６８０を制御する対応するプラグイン・モジュール１０４０Ａとを含み、それらのスクリプトを実行してキオスクのローカルＡＰＩ６８０を制御する組込みファイル１０３０を使用する。
【０１１６】
組込みファイル１０３０を有するアプリケーション・ファイル１７５は、以下のようになる。
【０１１７】

【０１１８】
プラグイン・モジュール１０４Ａは以下のコードから成ることができる。

上記の３つのプラグイン関数は、Ｎｅｔｓｃａｐｅブラウザ１６０が備える標準プラグインＡＰＩを実施する。ここでは、ブラウザ１６０が備える他のプラグインＡＰＩは使用されない。
【０１１９】
＜ｅｍｂｅｄ＞タグがＨＴＭＬインタプリタ６１０によって解釈されると、ＭＳＧＰＡＳＳ．ＭＥＴというファイル１０３０がローカル・ディスクにダウンロードされ、それに対応するプラグイン・モジュール１０４０Ａがまだブラウザ１６０にロードされていない場合、そのプラグイン・モジュール１０４０Ａがロードされる。ブラウザ１６０は、ＮＰＰ＿ＮｅｗというプラグインＡＰＩを自動的に呼び出してプラグイン・インスタンスを作成し、ダウンロードされたファイルの名前を持つプラグインＡＰＩであるＮＰＰＳｔｒｅａｍＡｓＦｉｌｅ（）を呼び出して、そのファイルを実行する。必要であれば、ブラウザ１６０はＮＰＰ＿Ｄｅｓｔｒｏｙ（）というプラグインＡＰＩを呼び出してプラグイン・インスタンスを破棄する。
【０１２０】
組込みファイル内の事前定義スクリプトを解釈して実行するためにクラスＫｉｏｓｋＩＰＣと関数ＩｎｔｅｒｐｒｅｔＦｉｌｅ（）を、Ｃ＋＋などのネイティブ言語を使用して実施することができる。この意味で、関数ＩｎｔｅｒｐｒｅｔＦｉｌｅ（）スクリプトが、妥当なパフォーマンスでスクリプトを解釈して必要な関数を実行することができるように実施されている限り、スクリプトをどのようなものにすることができるかについて制限がない。一例は以下の通りである。
【０１２１】
組込みファイル内では、スクリプトは以下のようになる。
【０１２２】

【０１２４】
プラグイン・モジュール１０４０Ａは、その機能の特定の対話式制御を実現するために、ブラウザ１６０ウィンドウ内にいくつかのボタンを作成することもできる。たとえば、「ＰｒｉｎｔＣｕｒｒｅｎｔＰａｇｅ」というメッセージを送るＳｅｎｄＭｓｇ（）関数を呼び出すために、「Ｐｒｉｎｔ（プリント）」というボタンを作成し、タッチまたはクリックされるのを待つことができる。＜ｅｍｂｅｄ＞タグは、プラグイン・モジュール１０４０Ａの実施態様に従ってプラグイン・モジュール１０４０Ａを制御するための１組の事前定義パラメータも含むことができる。＜ｅｍｂｅｄ＞タグの使用方法とプラグイン・モジュールの実施方法については、「ＨＴＭＬ　Ｐｕｂｌｉｓｈｉｎｇ　ｆｏｒ　Ｎｅｔｓｃａｐｅ」（スチュアート・ハリス（Ｓｔｕａｒｔ　Ｈａｒｒｉｓ）およびゲイル・キダー（Ｇａｙｌｅ　Ｋｉｄｄｅｒ）著、ＩＳＢＮ１−５６６０４−２８８−７）およびザン・オリファント（Ｚａｎ　Ｏｌｐｈａｎｔ）による上記の書物を参照されたい。
【０１２５】
以下に本発明をまとめて示す。
（１）　ブラウザ手段を含むエージェント・コンピュータを含んで構成される少なくとも１つのキオスク装置に接続され、アプリケーションを要求するための少なくとも１つの構成要求をネットワークを介して前記キオスク装置から受け取るサーバであって、前記サーバは、
アプリケーションに関連づけられ、組込み構成要素ファイルと組込み制御関数とを含んで構成されるＨＴＭＬファイルとして構成され、かつアプリケーション・ファイルとして参照される少なくとも１つの構成セットを格納する手段と、
前記構成要求により指定される前記構成セットを選択し、選択された前記構成セットをキオスク装置へと送信し、前記キオスク装置に対して入力／出力装置または周辺装置を制御するためのブラウザ機構を組み込ませ、前記キオスク装置の少なくとも１つの入力／出力装置または周辺装置を選択的に制御することにより前記キオスク装置が要求したアプリケーションを実行させる通信手段と、
を含むサーバ。
（２）　前記アプリケーション・ファイルが、Ｊａｖａ（登録商標）アプレットまたはＡｃｔｉｖｅＸ制御またはプラグイン制御による遠隔装置制御機能と、遠隔メッセージ表示機能と、ファイル転送機能と、エージェント／クライアント協同機能のうちのいずれか１つを提供する、（１）に記載のサーバ。
（３）　前記組込み制御関数の他、前記キオスク装置の動作状況を判断するシステム監視プログラムを含むＨＴＭＬファイルを格納する、（１）または（２）に記載のサーバ。
（４）　前記動作状況を使用して、前記入力／出力装置または周辺装置に必要な保守と、前記入力／出力装置または周辺装置の保守履歴と、前記構成要求のうちの１つまたは複数の構成要求に応答するために前記ネットワーク上で提供するアプリケーション・ファイルと、前記キオスク装置のユーザに関するマーケティング情報とのうちのいずれか１つまたは複数を判断する、（３）に記載のサーバ。
（５）　前記サーバは、前記動作状況を判断し、前記ネットワーク上で前記キオスク装置にどの構成セットを提供するかを決定する、（３）または（４）に記載のサーバ。
（６）　前記ＨＴＭＬファイルは、ゼロ個または１個以上のハイパーテキスト構成要素ファイルを含む、（１）ないし（５）のいずれか一項に記載のサーバ。
（７）　前記アプリケーションがキオスク装置におけるユーザに合わせてカスタマイズされたカスタマイズ・アプリケーションである、（１）ないし（６）のいずれか一項に記載のサーバ。
（８）　前記アプリケーション・ファイルが、前記少なくとも１つのアプリケーション・ファイルを受信することにより構成されたキオスク装置を介してインターネットへのアクセス機能を提供する、（１）ないし（７）のいずれか一項に記載のサーバ。
（９）　前記インターネットへの前記アクセスが、１つまたは複数の指定されたサーバを介して一人または複数のユーザ間に通信リンクを提供する、（８）に記載のサーバ。
（１０）　前記アプリケーション・ファイルが、電話呼出しと、電子メール送受信と、遠隔会議と、ファクス伝送と、トレーニング・セッションと、前記ネットワーク上の情報の検索と、ウェブ・ベースの協同とのうちのいずれか１つまたは複数の機能を提供する、（１）ないし（９）のいずれか一項に記載のサーバ。
（１１）　前記少なくとも１つのアプリケーション・ファイルを受信することによって構成されたキオスク装置におけるユーザに前記アプリケーション情報を提供する、（１）ないし（１０）のいずれか一項に記載のサーバ。
（１２）　前記少なくとも１つの組込み制御関数が、キオスク装置に対して前記アプリケーション・ファイルのうちの１つまたは複数のアプリケーション・ファイルを要求させるための機能を付与する、（１）ないし（１１）のいずれか一項に記載のサーバ。
（１３）　ネットワークを介して少なくとも１つのキオスク装置に接続されたサーバの動作方法であって、前記動作方法は前記サーバに対し、
前記ネットワークに接続されたキオスク装置に含まれ、ブラウザ手段を含むエージェント・コンピュータからの構成要求を受け取るステップと、
アプリケーションに関連づけられ、組込み構成要素ファイルと、キオスク装置におけるドライバ・プログラムから構成されるドライバ・サブセットを選択的に機能させる組込み制御関数とから構成され、かつＨＴＭＬファイルとして構成されるアプリケーション・ファイルである格納された構成セットを選択して、前記キオスク装置に送るステップと
を実行させ、
前記アプリケーション・ファイルは、Ｊａｖａ（登録商標）アプレットまたはＡｃｔｉｖｅＸ制御またはプラグイン制御を使用して前記キオスク装置にブラウザ機構を組込ませることにより前記キオスク装置の入力／出力装置または周辺装置に対応したドライバ・プログラムを選択的に制御させる
サーバ動作方法。
（１４）　エージェント・コンピュータを含んで構成される１つまたは複数のキオスク装置に接続され、少なくとも１つの構成要求をネットワークを介して前記キオスク装置のエージェント・コンピュータから受け取るサーバ動作方法であって、前記方法はサーバに対して、
前記ネットワークに接続された少なくとも１つのキオスク装置から構成要求を受け取るステップと、
アプリケーションに関連づけられ、組込み構成要素ファイルと組込み制御関数とを有し、かつ前記構成要求により指定され、ＨＴＭＬファイルとして構成されるアプリケーション・ファイルである構成セットを前記キオスク装置に送信するステップと
を実行させ、
前記アプリケーション・ファイルは、前記キオスク装置にブラウザ機構を組込むことにより前記キオスク装置のドライバ・プログラムを選択的に制御させ、前記ドライバ・プログラムにより入力／出力装置または周辺装置を駆動させることにより前記キオスク装置に前記アプリケーションを実行させる、方法。
（１５）　接続を介して少なくとも１つの構成要求を受信する、ネットワークへの１つまたは複数の接続を可能とする手段と、
アプリケーションに関連づけられ、組込み構成要素ファイルと組込み制御関数とを含んで構成されるＨＴＭＬファイルを含み、かつアプリケーション・ファイルとして参照される少なくとも１つの構成セットを格納する手段と、
キオスク装置へと前記構成要求により指定されるアプリケーションのための前記構成セットを通信する手段とを含み、
前記組込制御関数が前記キオスク装置に対してブラウザ機構を組込ませ、ブラウザ機構がドライバ・プログラムのうちの１つまたは複数のドライバ・プログラムから成るドライバ・サブセットを選択的に制御して前記ドライバ・プログラムにより前記入力／出力装置または周辺装置を駆動させ、前記キオスク装置をして前記アプリケーションを実行させるサーバ。
（１６）　前記構成要求が構成する前記キオスク装置のうちの１つまたは複数のキオスク装置から送られる、（１５）に記載のサーバ。
（１７）　前記構成要求がエージェント・コンピュータから送られる、（１６）に記載のサーバ。
（１８）　前記アプリケーション・ファイルが、Ｊａｖａ（登録商標）アプレットまたはＡｃｔｉｖｅＸ制御またはプラグイン制御による遠隔装置制御機能、遠隔メッセージ表示、ファイル転送、およびエージェント／クライアント協同のうちのいずれか１つを含む、（１６）に記載のサーバ。
（１９）　前記組込み制御関数の他、前記キオスク装置のローカル・キオスク機能のうちの少なくとも１つのローカル・キオスク機能の動作状況を判断するシステム監視プログラムを含む、（１５）に記載のサーバ。
（２０）　前記システム監視プログラムにより与えられる前記動作状況を使用して、前記周辺装置のうちの１つまたは複数の装置に必要な保守と、前記周辺装置のうちの少なくとも１つの装置の保守履歴と、前記要求のうちの少なくとも１つの構成要求に応答するために前記ネットワーク上で提供するアプリケーション・ファイルと、一人または複数のキオスク・ユーザに関するマーケティング情報とのうちのいずれか１つまたは複数を判断する、（１９）に記載のサーバ。
（２１）　前記システム監視プログラムにより与えられる前記動作状況によって、前記サーバが前記ネットワーク上でサービスを提供するアプリケーション・ファイルを決定する、（１９）に記載のサーバ。
（２２）　前記アプリケーション・ファイルが、１つまたは複数のＨＴＭＬファイルを含み、前記ＨＴＭＬファイルが、ゼロ個または１個以上のハイパーテキスト構成要素ファイルを含む、（１５）に記載のサーバ。
（２３）　前記アプリケーションが金融アプリケーションである、（１５）に記載のサーバ。
（２４）　前記金融アプリケーションが、ユーザへの金融情報提供、口座開設、現金支払い、勘定支払い、ローンの申込み、預金、モーゲージ支払い、金融に関する助言、固定資産取引、およびエージェントからの支援のうちのいずれか１つまたは複数の機能を含む、（２３）に記載のサーバ。
（２５）　前記アプリケーションがユーザに合わせてカスタマイズされたカスタマイズ・アプリケーションである、（１５）に記載のサーバ。
（２６）　前記アプリケーション・ファイルが、１つまたは複数のキオスク装置を介したインターネットへのアクセスを可能とする機能を提供する、（１５）に記載のサーバ。
（２７）　インターネットへの前記アクセスが、１つまたは複数の指定されたサーバを介して一人または複数の第２のユーザ間に通信リンクを提供する、（２６）に記載のサーバ。
（２８）　前記アプリケーションが通信アプリケーションである、（２７）に記載のサーバ。
（２９）　前記通信アプリケーション・ファイルが、電話呼出し、電子メール送受信、遠隔会議、ファクス伝送、トレーニング・セッション、前記ネットワーク上の情報検索、およびウェブ・ベースの協同のうちのいずれか１つまたは複数の機能を提供する、（２８）に記載のサーバ。
（３０）　前記アプリケーションがサービス・アプリケーションである、（１５）に記載のサーバ。
（３１）　前記サービス・アプリケーションが、広告、サービス、およびサービス料金のうちのいずれか１つまたは複数の機能の提供を含む、（３０）に記載のサーバ。
（３２）　前記アプリケーションが、前記アプリケーション・ファイルを受信することによって構成されたキオスク装置を使用してユーザに情報を提供する、（１５）に記載のサーバ。
（３３）　前記組込み制御関数のうちの少なくとも１つの組込み制御関数が、前記キオスク装置のうちの少なくとも１つのキオスク装置に前記アプリケーション・ファイルのうちの少なくとも１つのアプリケーション・ファイルを要求させる機能を付与する、（１５）に記載のサーバ。
【図面の簡単な説明】
【図１】キオスクの好ましい一実施形態を示すブロック図である。
【図２】キオスクの他の好ましい実施形態を示すブロック図である。
【図３】キオスクにおいて使用されるグラフィカル・ユーザ・インタフェースの例を示すブロック図である。
【図４】ユーザによって選択され、キオスクを構成するために実行される構成セット（アプリケーション・ファイル）を示すブロック図である。
【図５】少なくとも１つの組込み制御プログラムを含む、１つまたは複数のＨＴＭＬファイルおよび付随するハイパーテキスト構成要素ファイルを含む１組のアプリケーション・ファイル（構成セット）を示すブロック図である。
【図６】アプリケーション・ファイルおよびローカルＡＰＩプログラムと対話してキオスクを構成する制御プログラム／関数を実行するキオスクの好ましい一実施形態を示すブロック図である。
【図７】キオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図８】キオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図９】キオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１０】キオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１１】ＡＰＩ制御機能を備えた１つのアプリケーション・ファイルを実行する際に行われるステップを示すフローチャートである。
【図１２】典型的なサーバで行われるステップを示すフローチャートである。
【図１３】ＡｃｔｉｖｅＸを使用する好ましいキオスク・ソフトウェア・アーキテクチャを示すブロック図である。
【図１４】ＡｃｔｉｖｅＸを使用するキオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１５】ＡｃｔｉｖｅＸを使用するキオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１６】ＡｃｔｉｖｅＸを使用するキオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１７】ＡｃｔｉｖｅＸを使用するキオスク制御機構の様々な好ましい代替実施形態を示すブロック図である。
【図１８】プラグインを使用する代替キオスク制御実施形態を示すブロック図である。
【符号の説明】
１００…キオスク装置
１０３…タッチ・センシティブ端末
１０９…プリンタ
１０５…表示画面
１１０…コンピュータ
１１１、１１２、１３０…汎用情報読取装置（入力装置または周辺装置）
１１３、１３０…汎用情報書出装置（出力装置または周辺装置）
１２２…電話網
１２３…ＩＳＤＮ
１２５…制御プロセスおよびライブラリ
１５５…ネットワーク・インタフェース
５２０、６２０…組込み制御関数
６４０…キオスク固有制御機構
６４０Ａ…ブラウザ機構
６４０Ｉ…プロセス間通信手段
６４０Ｂ…ＡＰＩ機構
６８０…ローカル・アプリケーション・プログラム・インタフェース（ローカル・キオスクＡＰＩ）[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to the field of kiosk devices and servers that can be connected to a computer network and the server can form a kiosk device.
[0002]
[Prior art]
Generally, a kiosk is a machine that is located at a location for general access by a user or customer, for example, public access, thereby allowing a service provider to provide services to that user or customer. Generally, such services are "self-service" performed by the customer without the service provider having an agent to provide the customer with specific assistance. Thus, the service may be repetitive, such as 1) obtaining information, or 2) performing certain simple transactions (eg, buying tickets, obtaining cash, viewing department store floor maps, etc.). Tends to be a simple specific task.
[0003]
The tasks performed need to be pre-programmed and pre-determined and need to be self-service. Thus, the kiosk design is inflexible and does not provide customized assistance for a particular user.
[0004]
Generally, these transactions require the use of some device, for example, one or more monitors, card readers, ticket printers, laser printers, cash machines, and the like. These devices are generally dedicated to predefined tasks for inflexible designs in kiosks and therefore have no other use.
[0005]
The advantage of a kiosk is that it is convenient and reliable. The kiosk does not require a full-time human operator to perform the work, thus saving operating costs and increasing productivity.
[0006]
Some prior art kiosks, such as bank ATM machines and air ticket vending machines, are connected by a network. There are also stand-alone kiosks, just like information kiosks in shopping malls.
[0007]
The prior art includes kiosks with video conferencing capabilities for banking applications that attempt to set up a connection between a bank branch (agent) and a user / customer. This is done simply by adding a video conferencing system to a traditional type of kiosk.
[0008]
The prior art also has an integrated kiosk with the Internet. This kiosk has browser means for displaying an HTML page on the screen of the kiosk. The screen displayed on the kiosk is controlled by the hyperlink selected by the user. These kiosks are suitable for information access that customers / users can browse by selecting a "soft" button that invokes a hyperlink. These kiosks can also be used for certain personal communications, such as email. In this type of system, the screen is typically specially designed to present a user interface (e.g., having navigation buttons), and the kiosk further only accesses HTML pages (URLs) defined by the kiosk creator. Acts as a filter that limits the URLs that customers can visit, as possible.
[0009]
Most prior art kiosks are inflexible. Prior art kiosks are generally designed specifically for programming, created (usually in a high-level computer programming language such as C or C ++), and installed on a kiosk for a particular application, thus requiring modification or Reconfiguration cannot be easily and quickly performed at low cost. Any changes will require recoding, recompiling, reinstalling, and retesting the program at the kiosk. It is difficult to make changes to existing kiosks, especially if there are many kiosks in the area that need updating.
[0010]
Prior art kiosks cannot provide an effective "face-to-face" service based on an application, that is, a service that requires an agent to advise or guide a user or customer to perform a service or transaction. An effective “face-to-face” environment for customer service is not only video / audio, but also synchronized screen sharing (eg, user / customer viewing data while agent is entering data) and remote Device control is also required (eg, an agent can print a receipt for the kiosk user / customer). The prior art does not implement kiosk synchronization screen sharing or remote device control.
[0011]
While some prior art offers user assistance from agents over the phone, agents generally cannot directly view the screen of a kiosk. Thus, if there is a problem with the kiosk, the agent must rely on the user's description of the problem. Agents cannot access the problem by looking directly at the kiosk screen. In addition, agents cannot remotely change the kiosk's program / function to correct the kiosk problem. Note that some kiosks in banking applications allow banking agents to view the contents of the kiosk screen. However, this content is displayed by a separate application running on the agent's workstation, rather than the application displaying the screen content on the kiosk.
[0012]
[Problems to be solved by the invention]
Some conventional technologies include a video conference function as a kiosk function. However, while video conferencing provides customers with audio / video connections to other parties, this architecture is still a success in the marketplace because of the lack of consistent integration between audio / video communications and the content of the kiosk screen. Absent. When a customer has a problem with one of the items on the kiosk screen, the agent cannot have the same information on the agent screen as the customer has on the kiosk. For example, an ambiguous or incorrect value in a field on the screen of a kiosk may not be visible to agents during a video conference. Further, the agent cannot indicate the location on the customer's screen and cannot control the customer's screen. Further, the agent cannot provide general information to the customer via the kiosk that the kiosk has not yet been pre-programmed. Also, for example, if the customer needs information that is not available in the kiosk design, the agent can only provide the information by audio or camera video, and can be provided on the customer's kiosk screen or other Information cannot be provided via a kiosk device.
[0013]
Some prior art discloses a simple Internet / browser-based kiosk that can only perform limited specific applications, ie, limited information browsing. This type of kiosk cannot provide an effective customer service environment with flexible uses because of the lack of kiosk control and cooperation between the customer and the human agent.
[0014]
Accordingly, the present invention provides a kiosk and a server as defined in the claims.
[0015]
[Means for Solving the Problems]
The techniques described herein may be used for "face-to-face" agent-to-customer service and / or transactions and multiple communication networks such as the Internet (TCP / IP), Public Telephone Network (PSTN), Integrated Services Digital Network (ISDN). Configurable, directly accessible network located throughout the public, taking advantage of a flexible, reconfigurable, collaborative kiosk architecture for a variety of applications, including providing public access to・ Provide an interface. Thus, this network server system can be used to reconfigure remote kiosks or kiosk devices on a network in different ways for different applications, especially for different applications used in different ways for different applications. Numerous applications (possibly created, developed, and stored on one or more network servers) can be distributed to support output devices.
[0016]
Thus, in a preferred embodiment, the kiosk system may be connected to one or more networks, such as the Internet, a corporate or government intranet, or the like. The kiosk has one or more input / output devices (eg, display, keyboard, paper printer, phone, etc.) and one or more driver programs (local API) for each input / output device. . The display device is used to present one or more graphical user interfaces and video images to a kiosk user. Some of the interfaces are application specific. (An application is an application for which a kiosk is configured or reconfigured.) A kiosk is a browser that retrieves one or more application files (in a configuration set) from one or more servers on a network. Having. An application file (configuration set) contains a set of HTML files that are presented in sequence (determined by the application) by the kiosk browser. One or more of these HTML files includes a built-in (control) program used to control the local API of one or more of the devices on the kiosk. One or more of the files may be other HTML files, multimedia component files (such as images or sounds), or other HTML files, multimedia component files, embedded programs or other application programs. It can also include hyperlinks to files or a combination thereof. The first application file is selected from the server by a selection function at the kiosk (eg, voice, soft button, hyperlink, etc.). The application file (configuration set) associated with this selection item (selection function) configures the kiosk accordingly. Thus, the kiosk can be configured and reconfigured to execute various applications defined by the application files.
[0017]
In certain preferred embodiments, one or more of the application files has one or more predetermined selection links (eg, hyperlinks). As the browser renders or interprets the application files (e.g., one file at a time), predetermined selection links are presented to the user as additional selections on a graphical user interface. The user can select and call one or more other configuration sets, HTML files, etc., including zero or one or more other embedded control programs. Thus, using these additional selections, the sequence in which the content of the HTML file is presented by the browser, and in fact the files in the sequence, may be modified to reconstruct the kiosk in a different way and to provide It can obtain information and / or provide information to a user. Rendering the kiosk by rendering the contents of the HTML files in the sequence, thereby reconfiguring one or more screen sequences of interactive screens and, if necessary, the kiosk for a particular selected application. And a sequence of device actions (controlled by a built-in program). In these embodiments, the user (or kiosk or other function in the server) can reconfigure the kiosk for other applications by selecting different selection functions on the kiosk.
[0018]
In certain preferred embodiments, some of the applications include web page sharing features that allow agents and customers to collaborate on the network via kiosks and servers. One preferred embodiment implements a "lightweight" client architecture, that is, a client architecture without application specific software on the kiosk.
[0019]
Various preferred embodiments of the present invention are described in detail below, by way of example only, with reference to the following figures.
BEST MODE FOR CARRYING OUT THE INVENTION
Referring to FIG. 1, which is a block diagram of one preferred embodiment of the kiosk 100, the kiosk 100 includes a computer 110 (eg, an IBM personal computer such as a PC 350 or PC 750) having a suitable well-known network interface 155. Network 150 may be any known local area network (LAN) or wide area network (WAN). In the preferred embodiment, network 150 is the Internet. However, intranets, such as enterprise networks, government networks, education networks, extra business-to-business networks, and networks used by one or more retailers can be implemented by telephone networks, cable networks, ISDN networks, and the like. Other general purpose networks 150 are also contemplated, including. The computer 110 has one or more input and / or output devices (see below) 130 equipped as part of the kiosk 100. Typically, computer 110 includes one or more main memories, one or more storage devices 110M (such as a hard disk drive, a CDROM, etc.), as is well known, and one or more A central processing unit (CPU) 110C. In addition, the computer 110 has an optional hardware keyboard 135 and mouse 134 for maintenance. The user may access these various (peripheral 130) input and / or output devices (collectively numbered 130) to access other devices connected to network 150 via computer 110 and network 150. It transmits information to and / or from the client and / or server 195. Examples of these input / output devices 130 are a touch-sensitive terminal 103 with a screen 105, a printer 109, and any well-known general-purpose information reader 111 (e.g., reading a magnetic card, credit card, or smart card). Card reader 121), scanner (eg, laser scanner) 112, any well-known general-purpose information writer 113 (printer, ticket printer, media printer (eg, diskette drive), statement printer, or receipt printer) , (Eg, providing a sticker or a computer disk), or any other device 130 that provides the user with information contained in the tangible medium 113A. Other input / output devices 130 include a cash dispenser, scanner, deposer, pen input device 136, card issuer, ticketing machine, CRT, keyboard, touch-sensitive screen, program-controllable camera, one or more Human detector (eg, infrared), one or more lights, CD-ROM player, audio input / output device (eg, microphone 133, speaker 132, or telephone 107, and any one or more of memory 113B) The kiosk 100 may include well-known communication devices such as a telephone 107 and a video conferencing system 114, such as a PictureTel PCS-100 desktop ISDN videoconferencing system (PictureTel is a product of PictureTel, Inc.). The video conferencing system includes a camera 131, a speaker 132, a microphone 133, one or more ISDN connections or a separate network connection via a suitable network interface 155. Other networks 151, such as Connections can also be made to a conventional telephone system (POTS) telephone network 122 and / or an ISDN line 123 via a telephone 107, a speaker 132, and a microphone, using well-known interfaces to the network (150, 151). The other peripheral devices 130 can also be connected independently.
[0020]
Computer's CPU 110C executes a software program that includes control processes and libraries 125 and, in certain preferred embodiments, one or more cooperating processes. The control process 125 has two parts: one or more built-in control functions / programs 620 and one or more control mechanisms 640. (See FIGS. 5 and 6 to 10 below.) The embedded control program / function 620 is a content-specific process (eg, banking, car rental, product purchase, etc.). (Or a subset thereof) 130 using a non-content specific control mechanism 640 to control the local application program interface 680 (API). Thus, the input / output device 130 is controlled in a manner specific to the content of the application. In an alternative embodiment, the control mechanism can be loaded directly from the network 150 to the computer 110.
[0021]
The collaboration process 170 performs the function of establishing a collaboration session from the kiosk 100 with the API. This cooperative process is described in U.S. patent application Ser. No. 08 / 722,287, filed Sep. 27, 1996, entitled "Internet Web Page Sharing," which is hereby incorporated by reference in its entirety. (See European Patent Application No. 97307536.0, publication no. 833260). The computer also executes the necessary programs for interacting with network 150, including a web browser program 160, such as a Netscape Navigator browser. (Netscape Navigator is a trademark of Netscape Communications Corporation.)
[0022]
FIG. 2 is a block diagram illustrating an alternative embodiment of the present invention showing the kiosk 100 in an enclosed space or a partially enclosed space 200. The enclosed space 200 can be any type of space in which the kiosk 100 is placed with one or more users, for example, a room, small box, or any other private or quasi-private room. In this embodiment, computer 110 is connected to one or more well-known environmental peripherals 130 that computer 110 controls to create an environment for a user in space 200. For example, environmental peripherals include lighting 205 of the space, a display 210 in the space 200 that conveys additional information (eg, sales information) and / or environmental elements (eg, variable display of scenery and virtual world), entering and exiting space 200 Security access 215. Further, the (partially) enclosed space may also have other environmental peripherals 130 similar to the peripherals 130 described above, for example, audio, video conferencing, and the like. Examples of virtual worlds are well known.
[0023]
In a preferred embodiment of the systems 100 and 200, the user selects (using the select function) an application that configures the kiosk therefor, such as banking, and the browser 160 is configured to access one or more of the Internet (universal network) 150. Interact with multiple web servers 195 to retrieve one or more configuration sets 175. Optionally, data communication between the server 195 and the browser 160 in the kiosk (100, 200) starts. The application files 175 are then executed one file at a time by the browser 160 and 1) optionally, one or more of the input / output devices (e.g., touch-sensitive) of the input / output devices used with the respective application. Calls a driver program (local API 680) that controls the terminal 103 or display device 130; 2) optionally, a series of input / output device 130 actions, eg, a series of actions displayed on the terminal / display device 103; 3) Optionally, communicate user input from input device 130 to server 195; 4) Optionally, respond to user input to application file 175 for further execution by browser 160 Other applications • Select the file 175. In this way, the user can use the first selection function to select the first application (and its associated configuration set (application file) 175 on the server 195), which application can use the kiosk for the first time. The kiosk is reconfigured for the second application, etc. again by selecting a second application. The selection function for later configuration is The configuration is provided to the user.
[0024]
An application is any application for which a kiosk is configured. For example, applications include applications in the fields of finance, business, information (news, advertising), communications (email, web access, video conferencing), retail, marketing, and services (eg, government programs).
(Configuration) is included. An application owner is any individual, organization, or company that will configure a kiosk to implement the application. For example, a bank or mutual fund company configures a kiosk using one or more financial applications. Examples of such financial applications include providing financial information to a user, opening an account, paying cash, paying an account, applying for a loan, depositing, and receiving assistance from an agent. An example of a service owner is a rental car company that configures kiosks to do car rental / lease and the like.
[0025]
In another preferred embodiment, the kiosk (100, 200) is reconfigured by the server 195 rather than by the user. For example, a kiosk can be installed in a public space such as a shopping mall. The browser may retrieve the configuration set (application file) 175 from the one or more servers 195 or default or proxy server 195A located on the network 150 to the kiosk 100 first or periodically. (Or let the server "push"). Therefore, the system designer can control the configuration of the kiosk from a remote location of the server 195. For example, a kiosk in a mall may be configured to initially display a map of the mall, play background music, announce, or provide weather information or other general information such as news or stock quotes. it can. The application file 175 may include a selection function 105A, such as a touch screen, icons, hypertext links, soft buttons on a graphical user interface, a hard drive, on one or more of the input / output devices 130. Indicate to have or be to be a selection function 105A, such as a wired button, a remote sensor (such as a radio frequency identification tag), or a voice-activated message function for a video conferencing system. You can also. The selection function 105A is a function that allows the user to make a selection to reconfigure the kiosk according to the user's application. These selection functions 105A allow the user to reconfigure the kiosk 100/200 and access other information that the server 195 provides to the kiosk.
[0026]
The selection function 105A or other information displayed may also be a source of revenue for the kiosk owner / operator. For example, a kiosk may be a paid ad for notifications provided by the kiosk. Application providers (e.g., bank mutual funds, mortgage companies, money lenders, intermediaries (stocks, real estate), rental companies (automobiles, equipment), service providers, and retailers) can use the kiosk 100/200 on A user would pay for owning the selection function 105A, which the user selects to configure the kiosk for his application. The amount of the fee depends on the location of the kiosk, the location / location of the selected function / information on the kiosk (eg, graphical user interface), the size of the selected function 105A, the time and period during which the kiosk provides the selected function 105A / information. It can be determined based on such factors. The selection function 105A / information can be changed at different times or displayed periodically to target different classes of customers / clients. For example, a kiosk located at Grand Central Station may be reconfigured to display information for commuters during rush hour and to have a selection function 105A for restaurant reservation just before lunch time.
[0027]
The kiosk 100/200 can be reconfigured by the application provider via the server 195 to a user-specific configuration. For example, suppose the travel agency has a user profile for Mr. Smith. Mr. Smith selects the select function 105A on the kiosk 100/200 at a public place or office. Once the kiosk has been reconfigured for its travel agent application, the user can enter a personal identification code using one of the input / output devices 130 or by passing through a credit card, for example. Smith can be asked for personal information (following instructions from one of the files). Next, Mr. Smith's personal information is passed by kiosk 100/200 to server 195 to access his profile. Using the information in the profile, one or more of the application files 175 are sent by the server 195 and the kiosk is reconfigured specifically for Mr. Smith. For example, only a vacation package trip to Central America could be offered on a kiosk. In other embodiments, one or more of the application files 175 may allow a user to organize a GUI (300 below).
[0028]
In another preferred configuration of kiosk 100/200, a cooperative session is set up between one or more kiosk users and one or more agents of the application provider. The collaboration is set up by a collaboration process 170 that resides on the kiosk or is provided by server 195 as an application file 175 (see Fin et al., Patent application).
[0029]
In another preferred configuration of the kiosk (100, 200), the server 195 provides the kiosk with application files 175 used for monitoring or maintaining the kiosk. For example, in such an embodiment, one or more of the embedded control programs 620 may determine which input / output device is operating using a "deadman" timer status, error checking protocol, or the like. By making the determination, the operating status of one or more of the input / output devices 130 is monitored. This information is returned to server 195. Other application files 175 are used to query which input / output devices 130 are installed or operational at a given kiosk. In this way, the server 195 may enable the installed or operable input / output device 130 and not (unconfigure) any other application to enable the non-installed or faulty device. Determine whether to send file 175 to kiosk. Thus, a kiosk containing any general-purpose combination of input / output devices 130 can be located remote from the server, and the server provides suitable and operable applications that enable the kiosk for a given application. I do. The application file 175 may also be used to obtain information from one or more of the input / output devices to determine how to operate the device.
[0030]
FIG. 3 shows an example of a graphical user interface (GUI) 300 displayed on the screen display device 105 of the kiosk 100/200. GUI 300 provides the kiosk user with a primary access interface via selection function 105A. Examples of the selection function 105A include icon images 301 to 304 indicating applications for the bank 301, the insurance business 302, the general-purpose software button 303, and the pizza restaurant 304. The GUI 300 may also display a selection function 105A in the form of a menu 320 having one or more selection items (typically 325). Another example of a selection function 105A is a hyperlink 350, which can be part of the GUI 300 and / or the menu 320. Other area 340 of GUI 300 can be used to enter information or other data. Using these information fields 340, the GUI 300 can be presented as a form 370 such as a tax return, loan application, mortgage application, deposit slip, and the like. GUI 300 may be displayed as a web page by browser 160 using well-known techniques. This web page may have a multimedia (audio, video) aspect that is presented to the user via the input / output device 130.
[0031]
In FIG. 4, the user interacts via the user interface to select the selection function 105A, and the selection function 105A downloads an application file 175, which is a corresponding configuration set, from the server 195 to the client (kiosk 100, 200). A specific function is performed to control a specific subset 451 (for example, 107, 109, 111, 113, 114, etc.) of the peripheral device 130. Local API 440 is a software function interface that directly controls one or more peripheral devices 130. For example, the local API 440 of the card reader 130 includes processing for initializing, starting, reading data from the card, ejecting the card, and turning off the function.
[0032]
The selection (of the kiosk configuration) is made by the selection function 105A. The following are examples of the selection function 105A.
a) The user explicitly touches an image icon or other selection device such as a button on the screen.
b) The currently running program determines that the selection needs to be invoked based on the user's actions, for example, if the user makes the same mistake twice in a row, invokes the help program.
c) The logic in the currently executing program determines the next selection (kiosk configuration). For example, after a user creates a pre-qualification application for a mortgage and the bank approves it, the current application may ask the user if it requires real estate information. If the user responds positively, the configuration of the kiosk is changed to the configuration of the real estate agent application.
[0033]
In one embodiment, when the selection 105A is made, the browser 160 requests the server 195 via HTTP via the network interface 155 for the first application file 175 (comprising the file 500) corresponding to the selection function 105A. Send. (See also FIG. 5 for a description of file 500 in application file / configuration set 175.) Next, server 195 provides application file 175 to browser 160. After the file 500 constituting the application file arrives at the browser 160, the HTML content of the file 500 is executed line by line. If the file 500 of the next application file is associated (eg, hyperlinked) with the file 500 of the current application file that the browser is running, the file 500 of the next application file is also sent to the browser. Can be In this way, the browser 160 executes each file 500 one line at a time and one configuration set 175 at a time in the order defined by the HTML text instructions in the configuration set 175. By executing the file 500 in the application file / configuration set 175 in this manner, the local API 440 (associated with the device 130) or a subset 441 of the local API is invoked and the selected subset of the device is 451 to reconfigure the kiosk (100/200). The logic and / or user actions within each application file / file (175, 500) can change which application file / file (175, 500) is executed, Note that some application files may or may not be executed.
[0034]
By executing the application file 175, the browser 160 selects and controls one or more of the devices 130. The configuration of the kiosk is defined by the device 451 selected during execution of the application file (eg, a device subset 451) and how the device subset 451 is controlled. For example, in a banking configuration, the execution of the application file 175 invokes a subset of the API 441 and, for example, selects and controls the card reader 111 and the printer 109 (device subset 451) to read and read the bank card, respectively. The transaction record is printed. Executing one or more of the application files (or lines in the application file) 175 in the same banking configuration does not select or control device 130, but does Other actions are performed, including storing the data or returning the data or message to the server 195. In another arrangement for ordering a pizza, execution of the application file invokes a different subset of the API 441 to select and control the same device subset 451 (ie, card reader 111 and printer 109), respectively, for the credit card. A read and price request is made and a purchase receipt indicating the selected pizza topping is printed.
[0035]
Note that in some configurations, execution of application file 175 does not select one or more devices 130. In such a case, the default device is used. For example, a line in the file 500 for displaying a text line is sent to the display device 103 by default.
[0036]
It should also be noted that the browser 160 can access a special set of local executable modules that interact with the execution of the application file using other local programs and / or libraries (see FIG. 6). ).
[0037]
FIG. 5 is a block diagram illustrating a set of application files (configuration sets) 175 that provide at least one embedded control program 620, including one or more HTML files and their associated hypertext component files. . All web-based application files 175 are HTML-based files that provide at least one embedded control program 620. Application files 175 optionally also include other hypertext component files, whether HTML-based or not. Typically, the HTML file contains text 525, images or graphics 528, animations (implemented as images 528, applets 505, scripts 515, or other built-in control functions (programs) 620), (one built-in control function). It includes tags indicating standard HTML (such as HTML 3.0), which is an embedded component file such as audio (as 620), video (as one embedded control function 620), and other hyperlinks. These tags are well known. In one preferred embodiment, browser 160 is Netscape Navigator v3.0. The embedded program may be implemented using JavaScript or a Java applet, or any other embedded program that uses a plug-in, or a combination thereof. Sun Microsystems Inc.). As shown in FIG. 5, the HTML file 500 incorporates a Java ™ applet using a tag 505, incorporates a Java ™ Script function using a tag 515, and uses a tag 520 to implement a Javascript function. It incorporates any other program that calls the browser's plug-in function. Details of standard HTML tags are described in "Netscape HTML 3.0 Source Book", which is incorporated herein by reference in its entirety. Some of these built-in control functions 520 are read as built-in control functions / programs 620 when read into a computer.
[0038]
FIG. 5 is a block diagram illustrating components of a system that is called upon execution of embedded control program 620 of a typical application that configures kiosk 100.
[0039]
Within the browser 160, as a function, there is an interpreter 610 that interprets or recognizes HTML tags in HTML files. The interpreter 610 calls the HTML tag execution program 611 to execute a function for each HTML tag according to the type of the tag and the content of the tag. If the execution does not result in an API call 680 for the local kiosk program (including the local peripheral API 440), the browser executes each HTML tag 615 using a library of standard functions 617 if necessary. Examples of these non-API control functions 615 include text display, image display, and the like. These are well known and are included in prior art browsers.
[0040]
However, if the executable 611 encounters a built-in control function 620 that calls one of the local kiosk APIs 680, the executable 611 calls the security manager 625 inside the browser 160 to determine whether the API call is authorized. to decide. As will be described in greater detail below, the kiosk control mechanism 640, or a portion 640A of that mechanism, is located in a subdirectory of the directory containing the browser. In this way, when the execution program 611 encounters the built-in control function 620, the security manager 625 finds the control mechanism 640 (640A below) and the API control function 621 loads the control mechanism 640 / 640A into the browser process 160. I do. For example, these built-in control functions 620 may include an applet that calls one or more local API functions 680/440 (ie, a selected subset of API 441) to operate a given subset of devices 451. For example, if the device is a card reader, the built-in control function 620 uses the control mechanism 640 to call the appropriate API 440, open the card reader, read data from the card, eject the card, and close the card reader. .
[0041]
Note that the well-known browser 160 does not execute the built-in control functions 620 from the network 150 to execute the local API 680. In practice, these browsers specifically prevent the execution of these API control functions for well-known network security reasons. For example, if the application file 175 is modified while transiting the network, execution of the damaged control function in the application file will cause the client machine, ie, the kiosk (100, 200) to become unpredictable. Adverse consequences can occur.
[0042]
It is well known that Java is designed to overcome network security issues using various special measures, such as byte code transmission and verification, virtual machine error checking, and the like. Further, if Java is used as an applet in a web-based application, ie, embedded in an HTML file, the browser will typically include the Java applet in the browser. Strictly prevent access to any local Java (registered trademark) program on the client machine other than the Java (registered trademark) program in the standard Java (registered trademark) library. The reason for this is that the applet is sent from an unmanaged environment, that is, it can be sent from any server in the entire network, so the applet may simply damage the client machine. This is to prevent
[0043]
As described in the book "Java (Registered Trademark) Now" (by Kris Jamsa, James Press, 1996, ISBN 1-88133-30-4, p4), "addressing security issues" In order to do this, Java developers prevent programmers from creating computer viruses using the Java applet, and the applet stores information about the user's system (such as files on the user's system) on a server. For example, while browsing a competitor's web site, the competitor's Java applet reads his hard disk. If you don't like that security To provide, Java developers have decided to limit the operations that applets can perform, for example, Java applets cannot read or write files on the user's system. By doing so, the applet cannot store the virus on the user's disk or read information stored on the user's disk. " It is also described as follows. "Java allows a programmer to create a stand-alone program. A Java stand-alone program is similar to a program that a programmer can create using C ++. Such a stand-alone program can read and write files and execute operations that Java® restricts execution by an applet, whereas Java ™ applet can be used in a browser. Is only executed ... ". This means that the Java applet is designed not to operate functions outside the browser process 160.
[0044]
During operation of a standard browser, the browser security manager 625 monitors for violations of these security rules. If it finds an applet requesting access to a program that is not in the standard Java library, the browser simply reports a security breach error and stops running the applet.
[0045]
In one embodiment, a portion 640A of the kiosk-specific control 640 is added to the browser 160 to allow the application file 175 to configure the kiosk, and another portion 640B of the kiosk-specific control 640 is provided. Is added to the application programming interface (API) 680 (including 440). Therefore, the kiosk-specific control mechanism 640 is divided into two parts, a browser mechanism 640A and an API mechanism 640B. In this embodiment, the browser mechanism 640A and the API mechanism 640B communicate via an inter-process communication (IPC) 640I. The IPC 640I interface allows the browser mechanism 640A and the API mechanism 640B to communicate using message passing rather than direct indirect calls. (IPC is well known, one example is the use of Dynamic Data Exchange (DDE) in the Windows operating system. Windows is a trademark of Microsoft Corporation.)
[0046]
Browser mechanism 640A is placed in a browser subdirectory so that API control functions 620 in any application files 175 are recognized by interpreter 610 in browser 160. The API mechanism 640B receives a message from the browser mechanism 640A and independently controls various functions including 440 according to the message. In this way, an applet from a browser can control one or more devices and local functions, but only functions with a browser mechanism 640A. Thus, other functions in the kiosk remain secure from access by the application file 175 over the network. Thus, the kiosk is configurable but secure. Further, because the API mechanism 640B operates the device API 440 independently of the browser, the device control functions passed to the API mechanism 640B (a subset of the API control functions 620 used to control a given device) are: , Only if that application file is later removed or modified in browser 160, for that subset 451 of devices. This allows the device operation to be performed in a sustainable manner. That is, after the API function (640, 440) has been initiated, it can be completed regardless of whether the application file 175 is modified / removed by the browser 160. This execution persistence can make certain user interactions with the kiosk more efficient. For example, the application file 175 can instruct the card issuer to issue a new card. The user / browser can then move to another application file while the card issuer writes data to the magnetic stripe and launches a new card.
[0047]
The browser mechanism 640A is a name server that 1) resides in the browser's own standard directory / library and 2) the application file 175 passes messages (eg, function names and associated parameters) for one or more local API functions. One of the local APIs 680, either by passing messages using the mechanism (see FIGS. 7 and 9 and its description), or by directly invoking the local API function (see FIGS. 8 and 10 and its description). It has a structure that allows one or more local APIs 680 to be called.
[0048]
In a preferred embodiment, browser mechanism 640A includes a Java API (sometimes referred to as a "Java wrapper") known to application file 500 (e.g., inter-process communication or name It further includes functions programmed in a native language (eg, C ++) to communicate or call the local API 680 directly (using a server).
[0049]
The API mechanism 640B 1) directly accesses various local function modules (eg, a browser control module, a cooperative function module, a device control module, a system monitoring module, etc.), and 2) uses a name server mechanism or an associated function module. Has a structure that allows a set of one or more API functions 680 to be invoked by directly invoking, and 3) has an IPC that enables message-based communication with the API 640A. (Note that API function 680 is created to specifically control a given device or function within the kiosk, and may or may not be accessible by application file 175.)
[0050]
One application that uses this kiosk control mechanism is that the application queries the system setup and status before the application determines how to configure the kiosk. In the application file 175, the applet CallAPI. The class can be used to call the API function 640 "query_status". For example,

When this applet is executed by the browser, first, a class called kioskAppInterface is instantiated. This file and the associated DLL are placed in the browser standard library. Next, an API message "query_status" (640A) is sent using a method of the kioskAppInterface class (640A) called send_APImessage (). This method calls the inter-process communication function 640I and sends a message to the API mechanism 640B. Next, AIP mechanism 640B invokes the relevant local API function 680 to obtain system status data and sends that data back to 640A via inter-process communication function 640I. The applet uses the method get_APImessage () with the command "status" to obtain the data returned from the 640B and stores the data in a data structure in a class called sysStatus.
[0051]
The API message passing between 640A and 640B can use a name server facility (see FIG. 7 below). Generally, when 640B obtains a message, the name server function (within 640B) parses the message and calls the corresponding local function API 680. In this example, the system monitoring function API is called to obtain system status data. This can be illustrated as follows.

An example of data obtained in the "sysStatus" class data structure as described above is shown below.
Num. of Device = 5
laser printer = OK
card reader = OK
card issuer = no card supply
receive printer = OK
ticket printer = OK
This message indicates that there are five devices on the kiosk and all are working except the card issuer that needs the card.
[0052]
According to the current state of the kiosk, the application file 175 allows the selection and use of laser printers, receipt printers and card readers (device subset 451), while at the same time the card reader as indicated by the status data. Avoid using a card issuer because there is no card in the card supply (in such a situation, the card is created by other means and mailed to the kiosk user).
[0053]
In certain preferred embodiments, such techniques are used to determine what devices are included in the kiosk and whether those devices are functioning properly. In this way, the server can provide a particular application file 175 for configuring the kiosk based on which devices the kiosk has and which devices are operational. Thus, any number of different kiosk designs and operating situations can be configured by appropriately selecting the application files at the server for each application configuration. For example, in a banking application, a kiosk equipped with a laser printer for printing high quality bank statements is sent a file 500 configured as an application file containing laser printer controls, A kiosk that has only a receipt printer (available and operable) for the same task (bank statement) will receive another file 500 that is configured as an application file containing receipt printer controls. Can be In this way, a kiosk with a malfunctioning laser printer, or a lower cost kiosk without a laser printer, can be properly configured for banking applications.
[0054]
In other embodiments, one or more servers may request status information by sending a request in an application file. This information can be used to determine which kiosks and / or devices on those kiosks require service. For example, if necessary, a service technician can be dispatched to add a card to the card issuing machine.
[0055]
In other embodiments, status information may be requested for use in a kiosk or device service history. In addition, other marketing information may be obtained, for example, which configuration is most required by which class of customer at a particular installation location.
[0056]
In one preferred embodiment, the kiosk may have a browser window (system monitoring application window) running in the background of other applications. The system monitoring application window can include one or more HTML files that include one or more applets that communicate with one or more servers. (Mechanisms for Java applet communication with the server are well known.) This system monitoring application window can be started whenever the kiosk is powered on, as long as the kiosk is running. Keep running. In this way, one or more servers can obtain kiosk system status information at any time via communication with the applet.
[0057]
Among the possibilities provided by the approach described here are:
1) A "light client" kiosk. Because there is no application-specific software that needs to be pre-installed on the kiosk, a cost-effective kiosk can be built and maintained. Thus, one application (application file 500) can be created on a server and used by multiple "lightweight" kiosks on the network connected to that server. There is no need to create application-specific software for any of the "lightweight" kiosks on the network. In practice, the network can be made up of one or more standard (and thus cheaper) "lightweight" kiosks without any application-specific software. (For example, a kiosk manufacturer may manufacture one or more standard kiosks that are used for and independent of any application.) Creating, updating, and maintaining application files 500 on a server And can be used to reconfigure one or more kiosks on the network without changing any programming in the kiosk. This "light client" kiosk enables mass deployment of kiosks to provide universal public access anytime, anywhere, for example, "kiosk phones" that can communicate via the Internet and / or the telephone network .
[0058]
2) Since the kiosk is reconfigurable, many different applications can be developed on the server and distributed through the kiosk. Thus, the application provider can share any kiosk on the network. These applications can be provided to the kiosk for a particular point in time or for a particular situation, such as a user request or a given environmental condition (such as an umbrella advertising when it rains).
[0059]
3) The kiosks can be based on open standard technologies of the Internet and the Web, so that they can take advantage of the rich information and media, and the rich Internet and the World Wide Web.
[0060]
Some non-limiting examples showing how a user can use this kiosk 100 are provided below.
1. The idle kiosk screen dynamically displays various images, video clips, audio, graphics patterns and text. All screen content is controlled from HTML files, which are updated based on kiosk requests or server pushes. The server provider may pay different fees for this different type of screen "space" and its display time. In the morning and evening commutes, we mainly show headline news and changes in the financial markets, and at lunchtime we show advertisements for many restaurants. On weekends, you can also display special ads for department stores. This content always invites people passing by to touch the screen.
2. The user looks at the screen, walks up, and touches the screen. The screen switches immediately to the next screen, displaying a number of image icons and text indicating the category of the application.
3. When the user touches the pizza order icon, a screen on which the user can select the type of pizza is presented. The screen prompts the user for a pizza delivery location and time, and the user can enter information via the on-screen touch keypad. The control program 620 incorporated in the HTML captures this data. Next, the screen prompts the user to insert his credit card and authorize the payment. The control program opens the card reader and captures the credit card information. The control program then invokes the communication function on the kiosk using the relevant kiosk API function to access the credit card company (eg, via a modem) and the pizza store (eg, via a fax transmission). After these functions are completed, the screen confirms the customer with the information for ordering. Other general retail transactions can be performed in a similar manner.
4. The user can also place a call by touching the phone icon. The phone application HTML file is displayed on the screen along with the phone keypad. After the user enters the number, the embedded control program calls the associated API function 640A to initiate a telephone call. This can be via a public telephone network (PSTN), an integrated services digital network (ISDN), or an Internet telephone, depending on the kiosk's network connection (122, 123, 150), the application file 500, and the user selection 105A. It can be a conventional telephone call. Once the telephone is connected, the user can use the handset or speakerphone provided in the kiosk (“Multipoint Simultaneous Voice and Data” filed February 6, 1996, corresponding to European Patent Application No. 789470). See US Patent Application No. 08/595897 to Hortensius et al., Entitled "Services Using a Media Splitter Gateway Architecture," which is incorporated herein by reference in its entirety).
[0061]
In another preferred embodiment, the user can also select a videophone or videoconference call using the application sharing feature if the other party has the same functionality. In that case, the control program 620 embedded in the HTML application calls the relevant API function 640A to start the kiosk video conference function. Users can use the touch screen and electronic pen provided on the kiosk to facilitate conversations (as described in the aforementioned "Internet Web Page Sharing" patent application, such as Fins).
5. The user can also select the fax function. The screen prompts the user to enter a fax number, insert a credit card, insert the document to be faxed into an appropriate device (such as a document slot), and press the OK button on the screen when ready. Prompt to touch. Upon touching the button, the embedded control program 620 calls the associated device control API function 640A on the kiosk, activates the scanner, scans the document, returns the document, and electronically sends the document over a network, such as a PSTN or the Internet. .
6. The user can also select the e-mail function. The screen displays an HTML application for e-mail. The embedded control program 620 calls the associated API function 640A or communicates directly with the mail server and directory server via a browser to identify the user, retrieve an existing email message or send a new message. .
7. The user may also select 105A to transfer an electronic file on a medium such as a floppy diskette. The screen prompts the user to follow a particular process, for example, to insert a floppy into the slot. The embedded control program 620 calls the associated API function 640A, reads the diskette, reads or writes the file selected by the user, and forwards it according to the user's instructions, such as sending it to someone's email address.
8. The user can select a service from a wide range of service providers (eg, application owners on a server) such as lawyers, doctors, accountants, real estate agents, loan brokers, investment advisors, insurers, and the like. The screen displays the corresponding application in the HTML file and provides the requested service (based on user selection, this service can be any English, Spanish, Chinese, Japanese, French, Italian, etc. Can be presented in natural language.)
9. Depending on the service provider's application, real-time collaborative sessions may also be initiated using video, audio, shared screen, and remote device control functions (see Finn et al., Supra). The embedded control program calls the associated API function 620 to handle video, audio, and data communications.
10. The user can choose to search for information. The screen prompts the user to enter what information is needed, and the embedded control program captures the data and sends a query depending on the type of information. Queries can be sent through the interface using well-known search engines, databases on application servers, and databases on other network servers.
11. The user can select a customized application server. For example, once a user is identified (eg, from information accessed on a magnetic card or smart card), the application file provides customized information and kiosk configuration for the user.
12. The user can select a configuration for the kiosk 100 that is not the configuration initially provided by the kiosk 100. By interacting with the kiosk's first configuration, the kiosk can be reconfigured to a second configuration by reference to other application files 175. For example, a first configuration can include a user input (icon or hyperlink) accessing an application file 175 for a second configuration.
13. The user may be one or more students or students who have access to one or more kiosks connected to the network, where the server provides the "learning" application file 175.
14． The user can select an “electronic” product from the kiosk. For example, a compact disc (CD) containing music, video, computer software, or other multimedia information or a combination thereof can be sold from a suitable dispenser. Alternatively, a suitable kiosk device can write to a blank medium (eg, tape, diskette, writable CD, etc.) and provide the user with “electronic” information in intangible form that can be transmitted over a network. For example, an up-to-date opera recording may be provided on a CD without sending a "cut" CD at the factory.
[0062]
Other examples of certain kiosk control mechanisms 640 used to input and output information to and from a kiosk device are shown below. In a typical input situation, the application file 500 may include a CAPI API.xml file used to call the API function 640 "hardkey_input". It has an applet called class. For example:
[0063]

[0064]
Embed this applet in an HTML file as follows.
[0065]

[0066]
When this applet is executed by the browser, it first instantiates a class called kioskAppInterface. This file and the associated DLL are placed in the browser standard library. Next, an API message “hardkey_input” (640A) is sent using a method of the kioskAppInterface class (640A) called send_APImessage (). This method calls the inter-process communication function 640I and sends a message to the API mechanism 640B. Next, the API mechanism 640B calls the associated local API function 680, captures the key input from the hardware key provided on the kiosk, and sends it back to 640A via the inter-process communication function 640I. This applet uses get_AIPmessage () with the command “input” to get the data sent from 640B and stores it in a data structure in a class called InputData.
[0067]

[0068]
If the application file 500 has a built-in applet that invokes a "soft key" input, a similar API message is passed between 640A and 640B and the soft key pad is displayed on the screen using a different API function 680. Note that the window "pops up" and captures user input. API functions 680 for such soft key entry are well known.
[0069]
Similarly, if the application file 500 calls for printing a file on an output device, eg, a laser printer, or has a built-in applet, the above code directs the Local API function 680, Laser_print (FileName). , And controls the laser printer to print the file “FileName”.
[0070]
FIG. 7 illustrates one embodiment of a kiosk control mechanism 640 that uses the ICP 640I and the name server function 640B. In this case, the application file (175, 500) uses a small fixed set of general purpose communication API functions 640A (primarily for message passing). These communication API functions communicate or pass messages between 640A and 60B. Execution of the message is performed by the name server function in 640B. The server function 640B functions as an IPC 640I server. The name server function recognizes various predefined messages. For example, in one embodiment, the set of communication APIs has two functions: send_message (message) and get_message (message). However, there are multiple “messages”. The name server function in 640B finances a list containing each of these predefined messages, and each predefined message can call the appropriate local API function 680 to execute the respective predefined message1. Associated with a set of logic.
[0071]
In this embodiment, new devices and new functions performed by those new devices can be added by providing new predefined messages and the logic necessary to perform the new functions. In this way, the application files (175, 500) can perform their new functions simply by using the new message identifier in a given communication API function. This typically requires only changing the "ASCII" or "text" message identifier in the application file 500. You do not need to code and compile new embedded programs or modify existing programs to use the new features. Thus, since the kiosk provider has already incorporated the necessary logic into the name server 640B, there is little that the application owner (and thus the application files on the server) need to do to perform the new function.
[0072]
FIG. 8 is a block diagram illustrating an alternative embodiment of a kiosk control mechanism 640 that uses IPC 640I for a mapping local API in a browser mechanism 640A. In this example, many or all kiosk control functions 620 are executed by directly calling the corresponding mapping local API from application file 500 at browser mechanism 640A. Each mapping local API 640A communicates with the API mechanism 640B via the IPC 640I, which calls the appropriate local API function 680. Here, the mapping local API 640A is a Java (registered trademark) API program. There is one Java API program specifically created for one or more local APIs 680. Unlike the name server, at least one of the Java API programs must have logic to control one or more of the local APIs 680. These Java API programs 640 are predefined and known to the application file 500.
[0073]
In this embodiment, new devices and new functions performed by those devices can be added by providing new mapping local APIs (640A) in the browser mechanism 640A with their corresponding API mechanisms 640B. In this embodiment, the application file 500 needs to execute each of these new functions by direct invocation. Therefore, some or all of the logic for executing the new function needs to be defined in the application file 500. For example, an application programmer creating an application file 500 at the server will need to code this new logic, for example, by creating a new Java applet.
[0074]
FIG. 9 shows another embodiment of the kiosk control mechanism 640. In this embodiment, there is no IPC 640I, and thus the API mechanism 640B is merged into the browser mechanism 640A. However, the name server function (also merged) is used and combined with a set of communication APIs into a browser mechanism (640B, 640). In this embodiment, application files 500 (including applets) are "dropped" by browser 160 and local functions 680 are terminated, thus losing persistence. This embodiment is useful when persistence is not required, for example, when there is no required kiosk device other than the screen controlled by the browser.
[0075]
FIG. 10 shows another embodiment of the kiosk control mechanism 640. In this embodiment, there is no IPC 640I and no API mechanism 640B. In this case, the applet directly calls the API function (640, 640A), and the API function directly calls the local API function 680. Here, the API function 640 is a Java (registered trademark) API program. There is one Java API program specifically created for each one or more local APIs 680. Unlike the name server, at least one of the Java API programs has logic to control one or more of the local APIs 680. Must be. These Java API programs 640 are predefined and known to the application file 500. In this embodiment too, persistence is lost.
[0076]
FIG. 11 is a flowchart of an execution process 700 performed by a kiosk.
[0077]
First, the browser 160 obtains 705 the (HTML) file 500 from the application file 175. Next, browser 160 interprets 710 the tags and contents of application file 500. If the browser 160 does not encounter a local API call 715, the browser performs the relevant well-known actions 720, executing the tag. If the browser encounters a local API call 715, the browser calls 725 the associated API function (640 or 640A).
[0078]
In one preferred embodiment, browser mechanism 640A communicates 730 a message to API mechanism 640B via inter-process communication function 640I. Alternatively, a message server is used as described above. The API mechanism 640B receives the message and calls 735 the associated local function 680. The API mechanism 640B transmits 740 a message about the execution result of the local function to the browser mechanism 640A via the inter-process communication function 640I.
[0079]
The browser is controlled via screen input, embedded control program logic, or an external browser control function 660 to request the next HTML file. In this way, the browser can be treated as a local kiosk device. Thus, by controlling the browser and accessing the well-known browser interface (API 681) using the local API 660, it is possible to load any particular HTML file from one or more servers over the network. it can. Local API 660 is created to allow embedded control program 620 to access browser-in 681 (see above).
[0080]
FIG. 12 is a flowchart of a server process 800 executed on one or more servers on a network. The server receives 810 a request from one or more kiosks via a network. The request identifies which of the application files 175 is selected / accessed by the kiosk. The request also includes the location of the kiosk 100 that is requesting / accessing the application file. Upon receiving the request, the server sends 820 the requested application file 175 to the kiosk. The application file 175 can be pre-created or dynamically generated by logic on the server.
[0081]
In another embodiment, the kiosk sends 810 a request to proxy server 195A. Proxy server 195A is typically located closer to the kiosk than server 195. Alternatively, the proxy server 195A can be located on a computer without the kiosk 100/200. For example, server 195 may be located at a first city, for example, the location of a head office, and proxy server 195A may be located on a LAN connected to a kiosk in a different city. The proxy server 195A may send a request over the network 150 to the server for many or all application files 175 needed by the kiosk according to a predefined schedule. In this way, the kiosk can access the application file 175 on the proxy server 195A faster and more reliably when it needs the application file. Further, the proxy server may request the application file 175 from the server 195 during "off-peak" hours on the network.
[0082]
In other embodiments, the server (195, 195A) can be used to "push" information to one or more kiosks identified by the server 195. For example, at step 810, a request is initiated at server 195. This initiation 810 can be made for various reasons. For example, updating an application requires reconfiguring one or more kiosks using the new application file 175. Alternatively, it may be necessary to provide a new configuration at a specific time each day, i.e., provide news from a different source at 5 pm every day. The server can also "push" the periodic "checks" of the kiosk to determine which kiosk needs maintenance.
[0083]
One preferred implementation of this embodiment uses a "server push feature" 685 running on a kiosk. The server push function 685 is connected to the network 150 and can receive a message from the server 195. The server push function 685 can also access the browser interface 681. The server 195 sends a request to the server push function 685 to cause the browser to request the server 195 for a specific application file 500.
[0084]
FIG. 13 is a block diagram showing a mechanism in a case where the embedded control program uses the ActiveX technique instead of Java (registered trademark). The ActiveX control object can be realized using various programming languages such as C ++, Visual Basic, and Java (registered trademark). An ActiveX object can be embedded in an HTML file. For example:
[0085]

[0086]
In this case, the browser must be ActiveX-enabled. That is, it must support the ActiveX technique. In one embodiment, the browser is a Microsoft Internet Explorer.
[0087]
When the application file 500 arrives at the browser 160, the HTML file is interpreted 910 based on its tags and content. As with Java, described above, the browser executes 920 non-API control functions as described above. The API control function 930 executed by the browser directly calls the API 940. As in the case of Java, the first part 940A of the API communicates with the second part of the API (eg, 640B) 940B via the inter-process communication function 940I, and this second part connects the local API 680. call.
[0088]
The difference between ActiveX and the above-mentioned case of Java (registered trademark) is that ActiveX can include objects created in a non-network language such as C ++ or Visual Basic. Objects in these languages are downloaded to the browser in executable code. Thus, such an object can do whatever a program written in the same language can do, but does not have the security restrictions that Java ™ applets have. Thus, if the embedded control program 620 was created as an ActiveX control program using a non-Java language, the API function 940 could be placed anywhere within the kiosk. In the case of using Java (registered trademark) in an ActiveX object, the above-described mechanism must also be used.
[0089]
14 to 17, the boxes with the above numbers have the same functions as those described above.
[0090]
FIG. 14 illustrates one embodiment of a kiosk control mechanism 940 that uses the IPC and name server functions. Browser mechanism 940A is a native language API that does not need to be in the browser directory but can be located anywhere in the kiosk's memory, for example, in the kiosk's system directory. However, the path (ie, location) of the browser mechanism 940A must be known to the application file 500.
[0091]
FIG. 15 is a block diagram illustrating another embodiment of a kiosk control mechanism 940 that uses IPC 640I with a mapping local API. As in FIG. 8, there is at least one browser mechanism 940 for one or more of the local APIs 680.
[0092]
FIG. 16 shows another embodiment of the kiosk control mechanism 940 without the IPC 640I. In this case, the browser mechanism 940A can be arranged as described above with reference to FIG.
[0093]
FIG. 17 shows another embodiment of a kiosk control mechanism that uses ActiveX control when the control is not performed in Java (registered trademark). In this embodiment, 940 is not required at all since such a built-in ActiveX control can directly call the local API 680. In this case, the persistence of execution is lost.
[0094]
FIG. 18 illustrates another kiosk control mechanism using a so-called plug-in technique. In this case, the preferred embodiment uses a Netscape Navigator v3.0 or later browser.
[0095]
Here, the control mechanism 1040 includes a browser mechanism (plug-in module and its associated Java (registered trademark) wrapper) 1040A, and the kiosk control program (application file / file (175, 500)) in the browser mechanism includes 620) is accessed. When accessed, plug-in module 1040A executes as part of browser 160. The execution plug-in module 1040A calls the inter-process communication function 1040I. This inter-process communication function (IPC) 1040I can be the same as the above-mentioned IPC (640I, 940I). The IPC 1040I contacts the API mechanism 1040B and calls the local API 680. The API mechanism 1040B can be the same as the aforementioned mechanisms (640B, 940B).
[0096]
In this embodiment, the browser mechanism 1040A is implemented by a plug-in technique (see Zan Oliphant's "Programming Netscape Plug-ins" (Sams.net, 1996, ISBN1-57521-098-3)). You. Plug-in techniques use native code modules. That is, it is implemented using C or C ++ or a similar programming language, and in a more preferred embodiment is also implemented in a Java wrapper. Plug-in 1040A is placed in a special plug-in directory specified by browser 160. When the HTML interpreter 610 encounters an embedded file (620) that identifies each plug-in 1040A by a unique file name extension in the embedded file, also known as a multi-purpose Internet mail extension (MIME) type, the plug-in 1040A Dynamically loaded into browser 160.
[0097]
The built-in kiosk control program (620) is a set of predefined control scripts included in 1) a Java script function, 2) a Java applet, or 3) a MIME file with a unique extension. It can be.
[0098]
When browser 160 loads plug-in module 1040A, plug-in 1040A becomes available for HTML documents. That is, the function (plug-in function) in the plug-in can be used for the embedded program (620), for example, a Java (registered trademark) Script function or a Java (registered trademark) applet function to be called. In doing so, the kiosk's local API 680 may be controlled by a given embedded program 620 via one or more corresponding plug-ins 1040A. In other words, the plug-in module 1040A calls the IPC function 1040I and calls the kiosk's local API 680 via the corresponding API mechanism 1040B.
[0099]
Three non-limiting examples are shown below.
[0100]
Example 1 uses a JavaScript function as the embedded kiosk control program 1030 together with a plug-in module 1040A having a message passing function.
[0101]
The application file 175 having the control program 1030 is as follows.
[0102]

[0103]
The Java ™ applet “MYAPPLET.Java” includes the following codes.
[0104]

[0105]
Java® wrapper file PluginWrapper. Java includes the following codes.
[0106]

[0107]
The plug-in module 1040A associated with the embedded control program 1030 provides a method SendMsg () implemented in native language code such as C ++.
[0108]
Example 2 uses a Java applet directly as the embedded kiosk control program 1030 with a plug-in module 1040A having a message passing function.
[0109]
The application file 175 having the control program 1030 is as follows.
[0110]

[0111]
The Java ™ applet “MYAPPLET.Java” includes the following codes.
[0112]

[0113]
Java® wrapper file PluginWrapper. Java includes the following codes.

[0114]
As in Example 1, the plug-in module 1040A associated with the plug-in embedded control program 1030 above provides a method SendMsg () implemented in a native language such as C ++.
[0115]
Example 3 includes a set of predefined control scripts and a corresponding plug-in module 1040A that controls the kiosk local API 680, and uses an embedded file 1030 that executes those scripts to control the kiosk local API 680. I do.
[0116]
The application file 175 having the embedded file 1030 is as follows.
[0117]

[0118]
Plug-in module 104A may consist of the following code.

The above three plug-in functions implement the standard plug-in API provided in the Netscape browser 160. Here, other plug-in APIs provided in the browser 160 are not used.
[0119]
When the <embed> tag is interpreted by the HTML interpreter 610, the MSGPASS. If the file 1030 called MET is downloaded to the local disk and the corresponding plug-in module 1040A is not yet loaded in the browser 160, the plug-in module 1040A is loaded. The browser 160 automatically calls a plug-in API called NPP_New to create a plug-in instance, calls NPPStreamAsFile (), which is a plug-in API having the name of the downloaded file, and executes the file. If necessary, the browser 160 calls a plug-in API called NPP_Destroy () to destroy the plug-in instance.
[0120]
The class KioskIPC and the function InterpretFile () can be implemented using a native language such as C ++ to interpret and execute the predefined script in the embedded file. In this sense, as long as the function InterpretFile () script is implemented to be able to interpret the script with reasonable performance and execute the required functions, it is important to understand what the script can look like. There are no restrictions. An example is as follows.
[0121]
In the include file, the script looks like this:
[0122]

[0124]
The plug-in module 1040A may also create a number of buttons in the browser 160 window to provide specific interactive control of its functions. For example, to call the SendMsg () function that sends a message “PrintCurrentPage”, a button “Print” can be created and waited for a touch or click. The <embed> tag may also include a set of predefined parameters for controlling the plug-in module 1040A according to an embodiment of the plug-in module 1040A. For information on how to use the <embed> tag and how to implement a plug-in module, see "HTML Publishing for Netscape" (Stuart Harris and Gayle Kidder, ISBN1-5664-288-7). And Zan Olphant, supra.
[0125]
The present invention will be described below.
(1) A server connected to at least one kiosk device including an agent computer including browser means and receiving at least one configuration request for requesting an application from the kiosk device via a network, , The server comprises:
Means for storing at least one configuration set associated with the application, configured as an HTML file comprising an embedded component file and an embedded control function, and referred to as an application file;
A browser mechanism for selecting the configuration set specified by the configuration request, transmitting the selected configuration set to a kiosk device, and controlling an input / output device or a peripheral device with respect to the kiosk device. Communication means for selectively controlling at least one input / output device or peripheral device of the kiosk device to execute an application requested by the kiosk device;
Server containing.
(2) The application file is one of a remote device control function by Java (registered trademark) applet or ActiveX control or plug-in control, a remote message display function, a file transfer function, and an agent / client cooperation function. The server according to (1), which provides one.
(3) The server according to (1) or (2), which stores, in addition to the built-in control function, an HTML file including a system monitoring program for determining an operation state of the kiosk device.
And (4) using the operating status to perform one or more of a maintenance required for the input / output device or the peripheral device, a maintenance history of the input / output device or the peripheral device, and the configuration request. The server of (3), wherein the server determines one or more of an application file to be provided on the network to respond to the request and marketing information about a user of the kiosk device.
(5) The server according to (3) or (4), wherein the server determines the operation status and determines which configuration set is to be provided to the kiosk device on the network.
(6) The server according to any one of (1) to (5), wherein the HTML file includes zero or one or more hypertext component files.
(7) The server according to any one of (1) to (6), wherein the application is a customization application customized for a user of the kiosk device.
(8) The application file according to any one of (1) to (7), wherein the application file provides a function of accessing the Internet via a kiosk device configured by receiving the at least one application file. Server as described in.
(9) The server of (8), wherein the access to the Internet provides a communication link between one or more users via one or more designated servers.
(10) The application file is any one of a telephone call, an e-mail transmission / reception, a teleconference, a fax transmission, a training session, a search for information on the network, and a web-based collaboration. The server according to any one of (1) to (9), which provides one or more functions.
(11) The server according to any one of (1) to (10), which provides the application information to a user in a kiosk device configured by receiving the at least one application file.
(12) The method according to (1) to (11), wherein the at least one built-in control function provides a function for causing the kiosk device to request one or more of the application files. A server according to any one of the preceding claims.
(13) An operation method of a server connected to at least one kiosk device via a network, wherein the operation method includes:
Receiving a configuration request from an agent computer included in the kiosk device connected to the network and including browser means;
An application file associated with the application, comprising an embedded component file, and an embedded control function for selectively operating a driver subset composed of a driver program in the kiosk device, and configured as an HTML file. Selecting a stored configuration set and sending it to the kiosk device;
And execute
The application file is provided with a driver corresponding to an input / output device of the kiosk device or a peripheral device by incorporating a browser mechanism into the kiosk device using Java (registered trademark) applet or ActiveX control or plug-in control. Have the program selectively controlled
Server operation method.
(14) A server operation method connected to one or a plurality of kiosk devices including an agent computer and receiving at least one configuration request from an agent computer of the kiosk device via a network, The method is for the server,
Receiving a configuration request from at least one kiosk device connected to the network;
Transmitting to the kiosk device a configuration set associated with the application, the configuration set having an embedded component file and an embedded control function, and being an application file specified by the configuration request and configured as an HTML file;
And execute
The application file selectively controls a driver program of the kiosk device by incorporating a browser mechanism into the kiosk device, and drives the input / output device or a peripheral device by the driver program to thereby control the kiosk device. Causing the application to execute.
(15) means for enabling one or more connections to the network, receiving at least one configuration request via the connection;
Means for storing at least one configuration set, including an HTML file associated with the application and including an embedded component file and an embedded control function, and referred to as an application file;
Means for communicating the configuration set for an application specified by the configuration request to a kiosk device;
The built-in control function causes the kiosk device to incorporate a browser mechanism, the browser mechanism selectively controlling a driver subset of one or more of the driver programs to control the driver A server that drives the input / output device or peripheral device by a program and causes the kiosk device to execute the application.
(16) The server according to (15), wherein the configuration request is sent from one or more of the kiosk devices to be configured.
(17) The server according to (16), wherein the configuration request is sent from an agent computer.
(18) the application file includes any one of a Java ™ applet or a remote device control function by ActiveX control or plug-in control, a remote message display, a file transfer, and an agent / client cooperation. The server according to (16).
(19) The server according to (15), further including a system monitoring program that determines an operation status of at least one local kiosk function among the local kiosk functions of the kiosk device, in addition to the built-in control function.
(20) The maintenance status of one or more of the peripheral devices and the maintenance history of at least one of the peripheral devices are determined by using the operation status provided by the system monitoring program. Determining one or more of an application file provided on the network for responding to at least one of the requests for configuration and marketing information for one or more kiosk users. , (19).
(21) The server according to (19), wherein the server determines an application file that provides a service on the network based on the operation status provided by the system monitoring program.
(22) The server according to (15), wherein the application file includes one or more HTML files, and the HTML file includes zero or more hypertext component files.
(23) The server according to (15), wherein the application is a financial application.
(24) The financial application may provide any of financial information to a user, account opening, cash payment, account payment, loan application, deposit, mortgage payment, financial advice, fixed asset transaction, and assistance from an agent. The server according to (23), further comprising one or more functions.
(25) The server according to (15), wherein the application is a customization application customized for a user.
(26) The server according to (15), wherein the application file provides a function that enables access to the Internet via one or more kiosk devices.
(27) The server according to (26), wherein the access to the Internet provides a communication link between one or more second users via one or more designated servers.
(28) The server according to (27), wherein the application is a communication application.
(29) The communication application file is one or more of a telephone call, an e-mail transmission and reception, a teleconference, a fax transmission, a training session, a search for information on the network, and a web-based collaboration. The server according to (28), which provides a function.
(30) The server according to (15), wherein the application is a service application.
(31) The server according to (30), wherein the service application includes providing one or more functions of an advertisement, a service, and a service fee.
(32) The server according to (15), wherein the application provides information to a user using a kiosk device configured by receiving the application file.
(33) At least one of the built-in control functions provides a function of causing at least one of the kiosk devices to request at least one of the application files. , (15).
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating one preferred embodiment of a kiosk.
FIG. 2 is a block diagram illustrating another preferred embodiment of the kiosk.
FIG. 3 is a block diagram illustrating an example of a graphical user interface used in a kiosk.
FIG. 4 is a block diagram illustrating a configuration set (application files) selected by a user and executed to configure a kiosk.
FIG. 5 is a block diagram illustrating a set of application files (configuration sets) including one or more HTML files including at least one embedded control program and accompanying hypertext component files.
FIG. 6 is a block diagram illustrating one preferred embodiment of a kiosk that interacts with application files and local API programs to execute control programs / functions that make up the kiosk.
FIG. 7 is a block diagram illustrating various preferred alternative embodiments of the kiosk control mechanism.
FIG. 8 is a block diagram illustrating various preferred alternative embodiments of the kiosk control mechanism.
FIG. 9 is a block diagram illustrating various preferred alternative embodiments of the kiosk control mechanism.
FIG. 10 is a block diagram illustrating various preferred alternative embodiments of the kiosk control mechanism.
FIG. 11 is a flowchart showing steps performed when executing one application file having an API control function.
FIG. 12 is a flowchart illustrating steps performed by a typical server.
FIG. 13 is a block diagram illustrating a preferred kiosk software architecture using ActiveX.
FIG. 14 is a block diagram illustrating various preferred alternative embodiments of a kiosk control mechanism using ActiveX.
FIG. 15 is a block diagram illustrating various preferred alternative embodiments of a kiosk control mechanism using ActiveX.
FIG. 16 is a block diagram illustrating various preferred alternative embodiments of a kiosk control mechanism using ActiveX.
FIG. 17 is a block diagram illustrating various preferred alternative embodiments of a kiosk control mechanism using ActiveX.
FIG. 18 is a block diagram illustrating an alternative kiosk control embodiment using a plug-in.
[Explanation of symbols]
100 ... Kiosk device
103 ... Touch-sensitive terminal
109 ... Printer
105 ... Display screen
110 ... Computer
111, 112, 130: General-purpose information reading device (input device or peripheral device)
113, 130: General-purpose information writing device (output device or peripheral device)
122 ... Telephone network
123 ... ISDN
125 ... Control process and library
155 ... Network interface
520, 620 ... Built-in control function
640 ... Kiosk specific control mechanism
640A… Browser mechanism
640I ... Inter-process communication means
640B… API mechanism
680: Local application program interface (local kiosk API)

Claims (33)

A server connected to at least one kiosk device including an agent computer including browser means and receiving at least one configuration request for requesting an application from the kiosk device via a network, the server comprising: Is
Means for storing at least one configuration set associated with the application, configured as an HTML file comprising an embedded component file and an embedded control function, and referred to as an application file;
A browser mechanism for selecting the configuration set specified by the configuration request, transmitting the selected configuration set to a kiosk device, and controlling an input / output device or a peripheral device with respect to the kiosk device. Communication means for selectively controlling at least one input / output device or peripheral device of the kiosk device to execute an application requested by the kiosk device;
Server containing. The application file has one of a remote control function of Java (registered trademark) applet or ActiveX control or plug-in control, a remote message display function, a file transfer function, and an agent / client cooperation function. The server of claim 1 for providing. 3. The server according to claim 1, wherein an HTML file including a system monitoring program for determining an operation state of the kiosk device is stored in addition to the built-in control function. Responsive to one or more of the input / output devices or peripherals, a maintenance history of the input / output devices or peripherals, and one or more of the configuration requests using the operating conditions; The server of claim 3, wherein the server determines one or more of an application file provided on the network to do so and marketing information about a user of the kiosk device. 5. The server according to claim 3, wherein the server determines the operation status and determines which configuration set is provided to the kiosk device on the network. 6. The server according to any one of claims 1 to 5, wherein the HTML file includes zero or one or more hypertext component files. The server according to claim 1, wherein the application is a customization application customized for a user in a kiosk device. The server according to claim 1, wherein the application file provides a function of accessing the Internet via a kiosk device configured to receive the at least one application file. The server of claim 8, wherein the access to the Internet provides a communication link between one or more users via one or more designated servers. The application file may include any one of a telephone call, an e-mail transmission and reception, a teleconference, a fax transmission, a training session, a search for information on the network, and a web-based collaboration. 10. The server according to claim 1, which provides a plurality of functions. The server according to any of the preceding claims, wherein said server provides said application information to a user at a kiosk device configured by receiving said at least one application file. 12. The method of claim 1, wherein the at least one built-in control function provides a function for causing a kiosk device to request one or more of the application files. The server described. An operation method of a server connected to at least one kiosk device via a network, wherein the operation method includes:
Receiving a configuration request from an agent computer included in the kiosk device connected to the network and including browser means;
An application file associated with the application, comprising an embedded component file, and an embedded control function for selectively functioning a driver subset composed of a driver program in the kiosk device, and configured as an HTML file. Selecting a stored configuration set and sending it to the kiosk device.
The application file is loaded with a driver corresponding to an input / output device of the kiosk device or a peripheral device by incorporating a browser mechanism in the kiosk device using a Java (registered trademark) applet or ActiveX control or plug-in control. A server operation method for selectively controlling a program. A server operating method connected to one or more kiosk devices including an agent computer and receiving at least one configuration request from an agent computer of the kiosk device via a network, the method comprising a server Against
Receiving a configuration request from at least one kiosk device connected to the network;
Sending a configuration set to the kiosk device, the configuration set being an application file associated with the application, having an embedded component file and an embedded control function, and being specified by the configuration request and configured as an HTML file. Let
The application file selectively controls a driver program of the kiosk device by incorporating a browser mechanism into the kiosk device, and drives the input / output device or a peripheral device by the driver program to thereby control the kiosk device. Causing the application to execute. Means for enabling one or more connections to the network, receiving at least one configuration request over the connection;
Means for storing at least one configuration set, including an HTML file associated with the application and including an embedded component file and an embedded control function, and referred to as an application file;
Means for communicating the configuration set for an application specified by the configuration request to a kiosk device;
The built-in control function causes the kiosk device to incorporate a browser mechanism, the browser mechanism selectively controlling a driver subset of one or more of the driver programs to control the driver A server that drives the input / output device or peripheral device by a program and causes the kiosk device to execute the application. The server of claim 15, wherein the configuration request is sent from one or more of the kiosk devices to be configured. 17. The server of claim 16, wherein the configuration request is sent from an agent computer. 17. The application file, wherein the application file includes one of a Java applet or ActiveX or plug-in controlled remote device control function, remote message display, file transfer, and agent / client cooperation. Server. The server according to claim 15, further comprising a system monitoring program that determines an operation status of at least one local kiosk function of the kiosk devices of the kiosk device, in addition to the built-in control function. Using the operational status provided by the system monitoring program, maintenance required for one or more of the peripheral devices, maintenance history of at least one of the peripheral devices, Determining one or more of an application file to provide on the network to respond to a configuration request of at least one of: and marketing information for one or more kiosk users. 20. The server according to 19. 20. The server according to claim 19, wherein the server determines an application file that provides a service on the network according to the operation status provided by the system monitoring program. The server of claim 15, wherein the application file includes one or more HTML files, and wherein the HTML file includes zero or more hypertext component files. The server according to claim 15, wherein the application is a financial application. The financial application provides one of financial information to a user, account opening, cash payment, account payment, loan application, deposit, mortgage payment, financial advice, fixed asset transaction, and assistance from an agent. 24. The server of claim 23, comprising a plurality of functions. The server of claim 15, wherein the application is a customized application customized for a user. The server of claim 15, wherein the application file provides a function that allows access to the Internet via one or more kiosk devices. 27. The server of claim 26, wherein the access to the Internet provides a communication link between one or more second users via one or more designated servers. The server according to claim 27, wherein the application is a communication application. The communication application file provides one or more of the following functions: telephone calling, e-mail transmission and reception, teleconference, fax transmission, training session, information retrieval on the network, and web-based collaboration. 29. The server according to claim 28. The server according to claim 15, wherein the application is a service application. 31. The server of claim 30, wherein the service application includes providing one or more of an advertisement, a service, and a service fee. 16. The server of claim 15, wherein the application provides information to a user using a kiosk device configured by receiving the application file. The at least one built-in control function of the built-in control functions provides a function of causing at least one of the kiosk devices to request at least one of the application files. 16. The server according to 15.

Images