(57)【要約】      （修正有）【課題】ラウザを搭載したＡＴＭにおいて、リクエスト競合が発生した場合、ブラウザは後発のオペレーションを優先して展開するが、ＡＴＭとしては、先発のオペレーションを優先して展開する必要がある。また、ブラウザは、リクエストに対するレスポンスが、必ずしも予想された順番通りに展開されないという非同期性を持っており、複数のリクエストがＷｅｂサーバに送信されると、処理の順序性が崩れる可能性がある。【解決手段】複数のリクエストが発生した際は、ブラウザ１０２で後発のオペレーションのリクエストを読み捨てる制御を行い、リクエスト実行中の間は、別のリクエストがＷｅｂサーバ１０３に送信されないようにし、先発のオペレーションの優先を実現する。【選択図】  図１
2006127175.tif 000002
【特許請求の範囲】
【請求項１】
利用者の操作に基づいて種々の取引を行う自動取引装置において、
利用者が操作する操作部と、カードの取扱等を行う複数のユニットと、ブラウザを有し当該ブラウザを制御する制御部とを有し、
前記制御部は、前記操作部又は前記複数のユニットより発生したイベントが複数競合したと判断したとき、当該複数のイベントのうち先に発生した先発イベントを優先して処理することを特徴とする自動取引装置。
【請求項２】
請求項１記載の自動取引装置において、
前記制御部は、前記複数のイベントのうち後に発生した後発イベントを読み捨て処理することを特徴とする自動取引装置。
【請求項３】
請求項２記載の自動取引装置において、
前記制御部は、前記先発イベントに基づくリクエストを前記自動取引装置に接続されたサーバに送信し、前記後発イベントに基づくリクエストを送信しない制御を行うことを特徴とする自動取引装置。
【請求項４】
請求項１記載の自動取引装置において、
前記ユニットはカードの読取制御を行うカード取扱機構を含み、
前記カード取扱機構のシャッタが開いた状態で前記操作部にて選択された操作イベントと、前記カード取扱機構へのカード挿入イベントが競合したとき、
前記制御部は、前記操作イベントに基づくリクエストを前記自動取引装置に接続されたサーバに送信すると共に、前記カード挿入イベントに基づいてカードの情報を読み取り、当該カード挿入イベントに基づくリクエストを読み捨て処理することを特徴とする自動取引装置。
【請求項５】
請求項１記載の自動取引装置において、
前記ユニットはカードの読取制御を行うカード取扱機構を含み、
前記制御部は前記各ユニットを制御するデバイス制御部を含み、
前記カード取扱機構のシャッタが開いた状態で前記操作部にて選択された操作イベントが発生したとき、前記デバイス制御部は前記シャッタの閉処理を行うと共に前記カード取扱機構のカード有無を確認し、
前記制御部は、前記操作部に表示するカード挿入画面の表示と、前記シャッタの開処理とを同期制御することを特徴とする自動取引装置。
【請求項６】
請求項５記載の自動取引装置において、
前記自動取引装置に接続されたサーバからのレスポンスを保留する保留キューを有し、
前記制御部は、前記同期制御を行うとき、前記カードの挿入画面表示又は前記シャッタの開処理の何れか一方の処理を前記保留キューに保留することを特徴とする自動取引装置。
【請求項７】
請求項１記載の自動取引装置において、
前記ブラウザはスクリプトを有し、
前記スクリプトは、前記操作部又は前記ユニットより発生するイベントに関して当該イベントが発生したことを示すフラグを設定し、当該設定されたフラグの有無を判定して前記ブラウザに通知することを特徴とする自動取引装置。
【請求項８】
ブラウザを搭載した自動取引装置と、前記自動取引装置での取引を実行するための業務プログラムを格納するサーバとを有する自動取引システムにおいて、
前記自動取引装置は、取引に必要な複数のユニットと、前記ユニットを制御し且つ前記ブラウザを制御する制御部とを有し、
前記制御部は、前記ユニットから発生するイベントが複数競合したことに基づき、当該複数のイベントのうち先に発生した先発イベントを前記サーバにリクエストして前記サーバからの前記業務プログラムを処理し、前記複数のイベントのうち後に発生した後発イベントを読み捨て制御することを特徴とする自動取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブラウザを搭載した現金自動取引装置（以下、ＡＴＭ）等において、ブラウザからＷｅｂサーバへ送信するリクエストを制御するブラウザ制御方法、自動取引装置、自動取引システムに関するものである。
【背景技術】
【０００２】
ブラウザを搭載したＡＴＭと、画面コンテンツ（ＡＴＭの画面生成に必要な画像ファイル等）を格納したＷｅｂサーバとを回線で接続し、ＡＴＭからのリクエストに応じてＷｅｂサーバで画面生成を行い、生成した画面をＡＴＭがダウンロードしてブラウザに表示することで取引を行う、という自動取引システムが特許文献１に記載されている。
【０００３】
また現在では、Ｗｅｂサーバには、画面コンテンツだけでなく、業務プログラム（ＡＴＭで取引を実行するためのアプリケーションプログラム）を格納した自動取引システムが考えられている。顧客がＡＴＭで操作したオペレーションは、ＡＴＭのブラウザからＷｅｂサーバへリクエストされ、Ｗｅｂサーバの業務プログラムでリクエストに応じた処理を行い、処理結果に対応した画面をブラウザに返すことで取引を実現する。
【０００４】
このように、業務プログラムをＡＴＭから分離し、Ｗｅｂサーバに格納することで、エンハンスや保守、ユーザカスタマイズ等、システム稼動後のほとんどのタスクをＷｅｂサーバのみで行うことが可能となり、保守作業やエンハンス時の省力化が期待できる。
【０００５】
また、ＡＴＭにブラウザを搭載することにより、インターネット上の情報を表示することができるとともに、インターネットと連携した新しいサービスの提供も期待できる。
【０００６】
【特許文献１】特開２００１−７６２１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ブラウザを搭載したＡＴＭと、取引を実行するための業務プログラムを格納したＷｅｂサーバとを回線で接続した自動取引システムにおいて、ＡＴＭにブラウザを搭載することにより生じる問題を、図７と図８を用いて説明する。
【０００８】
図７は、リクエストが競合した場合の一般的なブラウザの動作を示した図である。ブラウザ１０２において、イベント７０１のリクエスト実行中に別のイベント７０２が発生した場合、ブラウザ１０２は、そのままＷｅｂサーバに対してイベント７０２のリクエストを送信する。Ｗｅｂサーバ１０３は、複数（イベント７０１とイベント７０２）のリクエストを受け付け、それらを独立したリクエストとして並列処理する。但し、ブラウザ１０２は、後発リクエスト（イベント７０２のリクエスト）に対するレスポンスを優先して展開してしまうため（画面Ｂ７０４の表示）、先発リクエスト（イベント７０１のリクエスト）に対するレスポンスは、Ｗｅｂサーバから受け取っても展開処理を行わず、処理結果を読み捨ててしまう。そのため先行のイベント７０１の処理が行われないとの問題が発生してしまう。
【０００９】
本発明の目的は、ＡＴＭにおけるイベント複数発生した場合、つまり操作が競合した場合、先行の操作を優先することにある。そのため、先発リクエストに対するレスポンスは、読み捨ててしまうのではなく、優先して展開する。つまり、ＡＴＭに搭載したブラウザにおいて、先発のオペレーションを優先する制御を実現することにある。
【００１０】
また、ブラウザは、リクエストに対するレスポンスが、必ずしも予想された順番通りに展開されないという非同期性を持っている。図８は、ブラウザに表示するＷｅｂページ８０３を示しており、Ｗｅｂページ８０３は、フレームで分割された２つのページ（ページＡ８０１とページＢ８０２）から構成されている。
【００１１】
Ｗｅｂページ８０３をブラウザに表示した場合、ページＡ８０１およびページＢ８０２がロードされる順番は不定であり、ページＡ８０１が先にロードされる場合もあれば、ページＢ８０２が先にロードされる場合もある。ブラウザは、２つのページを非同期的にロードし、どちらのページが先にロードされるかは、ページのサイズや内容によって決まる。したがって、ページＡ８０１にページＢ８０２に依存するような処理を記述するようなことはできない。
【００１２】
このように、複数のリクエストをＷｅｂサーバに送信した場合、それらのレスポンスがブラウザに展開される順番を保証することはできないため、順次制御を基本とするＡＴＭにおいては、処理順序の面で問題が生じる。本発明の他の目的は、ＡＴＭにおいて順次制御を保証するために、Ｗｅｂサーバに送信するリクエストに対して制限をかけることにある。
【課題を解決するための手段】
【００１３】
複数のイベントによるリクエストが発生したとき、ブラウザで後発オペレーションのリクエストを読み捨てる制御を行い、リクエスト実行中の間は、別のリクエストがＷｅｂサーバに送信されないようにする。
【発明の効果】
【００１４】
リクエスト競合が発生した際は、後発オペレーションのリクエストを読み捨てるため、自動取引システムにブラウザを利用した場合でも先発オペレーションの優先を実現することができる。また、Ｗｅｂサーバの業務プログラムは、常に一つのリクエストを処理すればよいので、業務プログラムの処理フローを単純化することができるとともに、順次制御を基本とするＡＴＭにおいて、処理の順序性を保証することができる。
【発明を実施するための最良の形態】
【００１５】
以下、図１と図２を用いて具体的に説明する。
図１は、ブラウザがリクエストをＷｅｂサーバ（単にサーバとも言う）に送信する際の処理を示した図である。ＡＴＭに搭載されるブラウザ１０２には、リクエストの送信可否を判定するスクリプト１０１が備えられている。スクリプト１０１は、ブラウザ１０２がリクエストをＷｅｂサーバ１０３に送信する際に実行され、リクエスト競合が発生している場合には、後発イベントのリクエストに対して送信不可と判定する機能（手段）を有している。一方、Ｗｅｂサーバ１０３には、ＡＴＭで実行される業務プログラム１０４が格納されている。
【００１６】
イベント１０５、イベント１０６、イベント１０７はＡＴＭで発生するイベントである。イベントとは、顧客がＡＴＭで操作した一連のオペレーションであり、ブラウザ１０２を通してＷｅｂサーバ１０３にリクエストされる。例えば、顧客がＡＴＭの顧客操作画面で「支払」キーを押した際は、「支払」キー押下イベントがＷｅｂサーバ１０３にリクエストされ、業務プログラム１０４は「支払」処理を開始する。また、通帳やカードなどの媒体を挿入したり抜き取ったりした際にも、この事象イベントがブラウザ１０２を介してＷｅｂサーバ１０３にリクエストされる。顧客がＡＴＭで取扱不可の銀行カードを挿入した際は、カード挿入イベントがブラウザ１０２を介してＷｅｂサーバ１０３にリクエストされ、業務プログラム１０４はＡＴＭに「カードキャンセル」のレスポンスを返す。ＡＴＭは、カードキャンセルのレスポンスを受信すると、カード挿入口のシャッタを閉じる。
【００１７】
以下に、ＡＴＭのブラウザにイベント１０５、イベント１０６、イベント１０７が発生したときのブラウザ１０２の動きを、それぞれ説明する。
イベント１０５が発生した際は、リクエスト競合は発生していないため、スクリプト１０１はイベント１０５のリクエストに対して送信可と判定し、ブラウザ１０２はイベント１０５のリクエストをＷｅｂサーバ１０３に送信する（Ｓ１０８）。ここでＷｅｂサーバ１０３からのレスポンスを受信する前に、イベント１０６が発生した際は、イベント１０５のリクエストは未だ実行中であるため、スクリプト１０１はイベント１０６のリクエストに対して送信不可と判定し、ブラウザ１０２はイベント１０６のリクエストをＷｅｂサーバ１０３に送信しないで読み捨てる処理を行う（Ｓ１０９）。つまりイベント１０６のリクエストを制限する。
【００１８】
イベント１０７は、イベント１０５のリクエストに対するレスポンスを、ブラウザ１０２が受け取った後に発生したイベントである。イベント１０７が発生した際には、イベント１０５のリクエストは実行終了しており、リクエスト競合は発生していないため、スクリプト１０１はイベント１０７のリクエストに対して送信可と判定し、ブラウザ１０２は、イベント１０７のリクエストを送信する（Ｓ１１０）。そしてＷｅｂサーバ１０４より受信するレスポンスに応じてＡＴＭのブラウザによってイベント１０７に対応する処理が実行される。
【００１９】
図２は、図１で示したスクリプト１０１の処理内容を示したフロー図である。ブラウザ１０２は、Ｗｅｂサーバ１０３にリクエストを送信するにあたり、スクリプト１０１を実行する。そしてこのスクリプト１０１は、「submit中フラグ」と呼ばれるフラグを内部変数として保持している。言い換えると、イベントが発生したことを示す旨を設定する設定部を有している。スクリプト１０１は、Ｗｅｂサーバ１０３にリクエストを送信する際にsubmit中フラグを「ON」に設定し、送信したリクエストに対するレスポンスをＷｅｂサーバ１０３より受け取った際に、submit中フラグを「OFF」に設定する。
【００２０】
イベント２０９を例に、スクリプト１０１の処理内容について説明する。最初に、リクエスト競合が発生していない場合について説明する。以下、イベント２０９は、リクエスト競合が発生していないときのイベントである。イベント２０９が発生すると、ブラウザ１０２はスクリプト１０１を実行する。このときsubmit中フラグは「OFF」になっているので（Ｓ２０１）、スクリプト１０１は、submit中フラグを「ON」にし（Ｓ２０２）、戻り値として「TRUE」をブラウザ１０２に返す又は通知する（Ｓ２０４）。ブラウザ１０２は、スクリプト１０１の実行後、スクリプト１０１の戻り値を判定する（Ｓ２０５）。戻り値が「TRUE」の場合、ブラウザ１０２はＷｅｂサーバ１０３にリクエストを送信する（Ｓ２０７）。その後、業務プログラム１０４でリクエストに対する処理を行い、処理結果を受け取った際に、submit中フラグを「OFF」に設定する（Ｓ２０８）。
【００２１】
次に、リクエスト競合が発生している場合について説明する。以下、イベント２０９は、リクエスト競合が発生しているときの後発イベントであるとして説明する。イベント２０９が発生すると、ブラウザ１０２はスクリプト１０１を実行する。このときsubmit中フラグは「ON」になっているので（Ｓ２０１）、スクリプト１０１は戻り値として「FALSE」をブラウザ１０２に返す（Ｓ２０３）。言い換えるとイベント発生の有無を判定している。ブラウザ１０２は、スクリプト１０１の実行後、スクリプト１０１の戻り値を判定する（Ｓ２０５）。戻り値が「FALSE」の場合、ブラウザ１０２はＷｅｂサーバ１０３にリクエストを送信しない（Ｓ２０６）。このように、リクエスト競合が発生した際は、ブラウザで後発オペレーションのリクエストを送信しないで読み捨てる制御を行う。
【００２２】
以下、ブラウザを搭載するＡＴＭ、ＡＴＭを含めたシステムについて図３と図４を用いて説明する。
【００２３】
図３は、本発明の一実施例であるＡＴＭの構成図である。
ＡＴＭ３０１は、金融機関やコンビニ等に設置され、顧客又は利用者の操作に応じて、現金の入出金や振込などの取引を自動で行う装置である。ＡＴＭ３０１には、通帳取扱機構３０２、紙幣入出金口３０３、顧客操作画面３０４、カード取扱機構３０５、明細票排出機構３０６など、取引に必要な種々のハード的なユニットが備えられている。通帳取扱機構３０２は、通帳の磁気ストライプに記録された情報を読み取り、通帳に入出金の記録を印字する。紙幣取扱機構３０３は、その入出金口より顧客との紙幣の授受を行い、入金時には、顧客が挿入した紙幣を鑑別し、金種ごとに分類して図示しない収納ボックスに保管する。出金時には、顧客の指示した金額分の紙幣を収納ボックスより繰り出し、入出金口から顧客に受け渡す。顧客操作画面（単に操作部、操作手段とも言う）３０４は、取引のための情報表示や顧客の操作入力を行うためのインタフェースであり、顧客が選択する項目を検知する。カード取扱機構３０５は、金融機関で使用される種々の磁気ストライプカードに記録された情報を読み取る。磁気ストライプカードには、金融機関番号、科目、顧客の口座番号などが所定のフォーマットで記録されており、この情報は、取引対象となる口座の特定や顧客の認証などに用いられる。明細票取扱機構３０６は、取引結果を印字した明細書を発行する。
【００２４】
これらの各ユニット（各部、各機構）の動作は、ＣＰＵ、メモリ等のハード構成を具備する制御ユニット３０７によって制御される。ＡＴＭ３０１は、通信回線３０８を介してＷｅｂサーバ１０３と接続されている。制御ユニット３０７は、Ｗｅｂサーバ１０３と通信を行いながら、取引を実現する。制御ユニット３０７は、デバイス制御部３０９と通信制御部３１５を備え、主制御部３１６がこれらを制御する。各種デバイスを制御するデバイス制御部３０９は、顧客操作画面制御部３１０、紙幣取扱機構制御部３１１、明細票排出機構制御部３１２、通帳取扱機構制御部３１３、カード取扱機構制御部３１４から構成される。なお、上述した各機構、ユニットは狭義の意味でデバイスとも表現されることから、デバイス制御部として説明したがユニット制御部とも言い、制御ユニット３０７を含めて単に制御部、制御手段とも言う。
【００２５】
顧客操作画面制御部３１０は、顧客操作画面３０４を制御する。顧客が操作するための画面を表示するとともに、顧客が操作した情報を取得する。紙幣入出金口制御部３１１は、紙幣取扱機構３０３の入出金口のシャッタ開閉や、出金時又は入金時に紙幣の枚数を制御する。明細票取扱機構制御部３１２は、明細票取扱機構３０６の排出制御、明細票の印字制御を行う。通帳取扱機構制御部３１３は、通帳取扱機構３０２を制御して、通帳から情報の取得、通帳への印字を行う。カード取扱機構制御部３１４は、カード取扱機構３０５を制御して、磁気ストライプから情報を取得する。
【００２６】
図４は、図３におけるＡＴＭの制御系のブロック図である。
ＡＴＭ３０１に搭載したブラウザ１０２は、操作部３０４からの操作に応じてＷｅｂサーバ１０３にリクエストを送信し、Ｗｅｂサーバ１０３で生成された画面を表示する。通信制御部３１５は、主に業務アプリケーション１０４との通信を制御する。
【００２７】
通信制御部３１５には、保留キュー４０４が備えられている。通信回線で接続したＷｅｂサーバにて画面を生成する本システムでは、回線速度の物理的制限により、ＡＴＭ３０１において画面の表示に時間がかかる場合があり、画面表示と各種デバイスの動きとで同期を取る必要がある。例えば、顧客が明細票を受け取る場合、明細票の受け取りを促す画面（以下、明細票受取画面）の表示と、明細票取扱機構３０６における明細票の排出処理は、同期を取って行う必要がある。つまり、明細票受取画面の表示と、明細票の排出に、タイムラグが生じないようにする。この場合、明細票排出処理は、一旦、保留キュー４０４に登録しておいて、明細票受取画面の表示が完了してから、明細票排出処理をデバイス制御部３０９に通知し、明細票取扱機構３０６より明細票の排出を実行する。以上のように、保留キュー４０４を用いて、デバイスと画面表示の同期をとり、デバイスの動きに対応した画面をタイムラグ無く表示させる。
【００２８】
一方、Ｗｅｂサーバ１０３は、ＡＴＭのブラウザ１０２からのリクエストに応じて画面を生成する、ＡＴＭで実行される各種の業務、制御プログラムを送信する。例えば、顧客操作画面生成部４０３は、業務プログラム１０４の実行結果から、画面コンテンツ４０２の画像ファイル等を利用し、顧客操作画面３０４に表示する画面の生成を行い、上述の通信制御部３１５にデータを送信する。また、ホストコンピュータ４０１は、顧客の口座番号やその暗証番号、口座残高等の顧客情報を管理しており、Ｗｅｂサーバ１０３は、ホストコンピュータ４０１と交信することによりＡＴＭで実行される取引を行う。
【００２９】
以上説明したように、ＡＴＭ３０１のブラウザ１０２を中心に、ＡＴＭ内のハード的な各ユニット制御されるが、このブラウザ１０２自身は制御ユニット３０７に記憶されている。従って、ＣＰＵ,メモリ等から構成される制御ユニット（単に制御部）によって上述の制御、処理が行われるとも言え、勿論、ブラウザ１０２が各種機能を備えているとも言える。
【実施例１】
【００３０】
以下、先に述べた自動取引システムにおいて、顧客とＡＴＭとのインタフェースと、ハード的な各ユニットを制御するデバイス制御部と、特に顧客が操作するために用いられる操作部を制御するブラウザと、ＡＴＭと接続するＷｅｂサーバとのそれぞれの関係を基に、図５と図６を用いて具体的に説明する。
【００３１】
図５および図６は、顧客が支払処理を行った際の処理フローの一部分を示している。特に、顧客５０１が顧客操作画面３０４で「支払」キーを押してから、顧客操作画面３０４に暗証番号入力画面５２０が表示されるまでの間の処理フローである。上述のように、ＡＴＭ３０１を操作する顧客５０１、デバイス（この場合、カード取扱機構３０５）を制御するデバイス制御部３０９、Ｗｅｂサーバ１０３にリクエストを送信し、Ｗｅｂサーバ１０３で生成された画面を表示するブラウザ１０２、業務プログラム１０４を格納したＷｅｂサーバ１０３、それぞれの状態を示している。なお、図５は、「支払」キー押下後、顧客操作画面３０４の指示に従ってカードを挿入した場合（正常に操作した場合）の処理フローであり、図１のイベント１０５とイベント１０７の処理に相当する。図６は、「支払」キー押下とカード挿入をほぼ同時に行い、ブラウザで２つのイベントのリクエストが競合した場合の処理フローで、図１のイベント１０５とイベント１０６に相当する。
【００３２】
最初に、図５について説明する。ブラウザ１０２は操作部３０４に初期画面としていらっしゃい画面５０６を表示しており、この初期画面には「預入」「支払」「振込」等のＡＴＭで取引可能な複数の種目のキーが表示されている。顧客５０１がそれら項目の中から「支払」を選択する（Ｓ５０７）と、それを契機にＡＴＭ内の処理が開始される。なお、いらっしゃい画面５０６を表示している際は、カード取扱機構３０５のカード挿入口のシャッタは開いており（Ｓ５０２）、カード挿入が可能である。
【００３３】
ブラウザ１０２は、「支払」キー押下イベントを受け取り、「支払」イベントをＷｅｂサーバ１０３にリクエストする（Ｓ５０８）。なお、図２で示すブラウザ１０２のスクリプト１０１の機能、処理等については既に説明したので省略する。
Ｗｅｂサーバ１０３の業務プログラム１０４は、「支払」処理を開始し、「カードキャンセル」をデバイス制御部３０９に通知する（Ｓ５０９）。「カードキャンセル」の通知を受け取ったデバイス制御部３０９は、カード取扱機構３０５を制御して、カード挿入口のシャッタを閉じるとともに（Ｓ５０３）、カードが挿入されているかどうかチェックを行う（Ｓ５１０）。この場合、まだカードは挿入されていないので、Ｗｅｂサーバ１０３に「カードなし」と通知する（Ｓ５１１）。Ｗｅｂサーバ１０３の業務プログラム１０４は、「カード受付」処理を開始し（Ｓ５１２）、デバイス制御部３０９にカード挿入口のシャッタを開く処理を通知するとともに（Ｓ５０４）、カード挿入を促す画面（以下、カード挿入画面５１４）の表示をブラウザ１０２に通知する。なお、カード挿入画面５１４の表示処理と、カード挿入口のシャッタを開く処理は、図４にて説明した保留キュー４０４により、同期を取って実行される（Ｓ５１３）。
【００３４】
カード挿入画面５１４の指示に従い、顧客５０１は、カード取扱機構３０５にカードを挿入する（Ｓ５１５）。「カード挿入」イベントは、ブラウザ１０２を介してＷｅｂサーバ１０３にリクエストされ、業務プログラム１０４は、「カードキャンセル」をデバイス制御部３０９に通知する（Ｓ５１６）。「カードキャンセル」の通知を受け取ったデバイス制御部３０９は、カード取扱機構３０５を制御して、カード挿入口のシャッタを閉じるとともに（Ｓ５０５）、カードが挿入されているかどうかチェックを行う（Ｓ５１７）。この場合、カードは挿入されているので（Ｓ５１８）、カード挿入時に読み取ったカード情報を、Ｗｅｂサーバ１０３に通知する（Ｓ５１９）。続いて、業務プログラム１０４は、暗証番号入力処理を開始し、顧客５０１に対して暗証番号の入力を促す暗証番号入力画面５２０を、ブラウザ１０２に表示させる（Ｓ５２０）。
【００３５】
次に、図６を用いてイベント競合処理について説明する。図５において、顧客５０１が、いらっしゃい画面５０６で「支払」キーを押下すると、Ｗｅｂサーバ１０３の業務プログラム１０４は、「カードキャンセル」をデバイス制御部３０９に通知し（Ｓ５０９）、カード挿入口のシャッタが閉じる（Ｓ５０３）ことを説明した。
【００３６】
しかし、実際には、顧客５０１がＡＴＭ３０１で「支払」キーを押下してから、カード挿入口のシャッタが閉じるまでの間には、回線速度の物理的制限によるタイムラグが発生するため、この間（「支払」キーを押下してから、カード挿入口のシャッタが閉じるまでの間）にカード挿入は可能であり、この間にカードを挿入すると、「支払」キー押下と「カード挿入」の２つのイベントがブラウザからリクエストされることになる。図６は、このように「支払」キー押下と「カード挿入」の２つのイベントが競合した場合の処理フローを示している。
【００３７】
いらっしゃい画面５０６において、顧客５０１が「支払」キーを押下したとする（Ｓ６０１）。ブラウザ１０２は、「支払」キー押下イベントを受け取り、「支払」イベントをＷｅｂサーバ１０３にリクエストする（Ｓ６０２）。
【００３８】
一方、いらっしゃい画面５０６を表示している際は、カード挿入口のシャッタは開いており（Ｓ６１０）、カード挿入が可能である。顧客５０１が、「支払」キーを選択（Ｓ６０１）してからカード挿入口のシャッタが閉じる（Ｓ６１１）までの間にカードを挿入すると（Ｓ６０３）、「支払」キー押下イベントに続いて、「カード挿入」イベントも発生する。
【００３９】
しかし、図１と図２で述べたように、ブラウザ１０２では、リクエスト競合時に後発イベントのリクエストを読み捨てる制御を行うため、後発イベントである「カード挿入」のリクエストは読み捨て処理し（Ｓ６０５）、先発イベントである「支払」キー押下のリクエストのみがＷｅｂサーバ１０３に送信される。
【００４０】
Ｗｅｂサーバ１０３の業務プログラム１０４は、「支払」処理を開始し、「カードキャンセル」をデバイス制御部３０９に通知する（Ｓ６０６）。「カードキャンセル」の通知を受け取ったデバイス制御部３０９は、カード取扱機構３０５を制御して、カード挿入口のシャッタを閉じるとともに（Ｓ６１１）、カードが挿入されているかどうかチェックを行う（Ｓ６０７）。この場合、カードは挿入されているので（Ｓ６０８）、カード挿入時に読み取ったカード情報を、Ｗｅｂサーバ１０３に通知する（Ｓ６０９）。続いて、業務プログラム１０４は、暗証番号入力処理を開始し、顧客５０１に対して暗証番号の入力を促す暗証番号入力画面５２０を、ブラウザ１０２に表示させる。
【００４１】
先発イベントである「カード挿入」のリクエスト（Ｓ６０３）は読み捨てられてしまうが、カード挿入時に読み取ったカード情報（Ｓ６０４）は、先発イベントである支払処理の延長で読み取るため（Ｓ６０９）、その後のカード情報を使った処理（磁気ストライプの読取、エンボス（凹凸による取引情報）の読取等）に問題は無い。
【００４２】
以上説明したように、ブラウザを有する自動取引装置に対して異なる２種類以上のイベントが発生した場合、先に発生した先発イベントを優先して処理する構成を採用することで、種々の問題が解決できる。またそのとき、後に発生した後発イベントを自動取引装置に接続されたＷｅｂサーバにリクエストしないように読み捨て処理する。これらの処理、制御はＣＰＵ,メモリのハード構成を有する制御ユニット（制御部）３０７によって行われるが、制御部には上述のブラウザ、デバイス制御部、各ユニットの制御部の制御プログラムが記憶されていることは言うまでもない。
【００４３】
また上述の例では自動取引装置としてＡＴＭを例に説明したが、鉄道会社等に設置された切符を販売する自動取引装置に応用しても良い。
【図面の簡単な説明】
【００４４】
【図１】ブラウザがリクエストをＷｅｂサーバに送信する際の処理を示した図である。
【図２】ブラウザでリクエスト競合が発生した際に、後発リクエストを読み捨てる処理を示した図である。
【図３】本発明の一実施例であるＡＴＭの構成図である。
【図４】ＡＴＭの制御系のブロック図である。
【図５】自動取引システムにおいて、顧客が顧客操作画面で「支払」キーを押してから、顧客操作画面に暗証番号入力画面が表示されるまでの間の処理フローである。
【図６】顧客が顧客操作画面で「支払」キーを押してから、顧客操作画面に暗証番号入力画面が表示されるまでの間の処理フローで、「支払」キー押下と「カード挿入」の２つのイベントが競合している例である。
【図７】リクエストが競合した場合のブラウザの動作を示した図である。
【図８】フレームで分割された２つのページから成るＷｅｂページである。
【符号の説明】
【００４５】
１０１…リクエスト競合の有無を判定するスクリプト、１０２…ブラウザ、１０３…Ｗｅｂサーバ、１０４…業務プログラム、１０５、１０６、１０７…イベント、２０９…イベント、３０１…現金自動取引装置、３０２…通帳取扱機構、３０３…紙幣入出金口、３０４…顧客操作画面、３０５…カード取扱機構、３０６…明細票排出機構、３０７…制御ユニット、３０８…通信回線、３０９…デバイス制御部、３１０…顧客操作画面制御部、３１１…紙幣取扱機構制御部、３１２…明細票取扱機構制御部、３１３…通帳取扱機構制御部、３１４…カード取扱機構制御部、３１５…通信制御部、３１６…主制御部、４０１…ホストコンピュータ、４０２…画面コンテンツ、４０３…顧客操作画面生成部、４０４…保留キュー、５０１…顧客、５０６…いらっしゃい画面、５１４…カード挿入画面、５２０…暗証番号入力画面、７０１、７０２…イベント、７０３…画面Ａ、７０４…画面Ｂ、８０１…ページＡ、８０２…ページＢ、８０３…Ｗｅｂページ
【図１】
2006127175.tif 000003
【図２】
2006127175.tif 000004
【図３】
2006127175.tif 000005
【図４】
2006127175.tif 000006
【図５】
2006127175.tif 000007
【図６】
2006127175.tif 000008
【図７】
2006127175.tif 000009
【図８】
2006127175.tif 000010