JP2004295614A - 取引処理システムおよび情報端末 - Google Patents
取引処理システムおよび情報端末 Download PDFInfo
- Publication number
- JP2004295614A JP2004295614A JP2003088440A JP2003088440A JP2004295614A JP 2004295614 A JP2004295614 A JP 2004295614A JP 2003088440 A JP2003088440 A JP 2003088440A JP 2003088440 A JP2003088440 A JP 2003088440A JP 2004295614 A JP2004295614 A JP 2004295614A
- Authority
- JP
- Japan
- Prior art keywords
- information
- center
- transaction
- terminal
- storage unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Cash Registers Or Receiving Machines (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】取引処理システムにおいて、センター側の障害中にも取引を正常に処理できるようにする。
【解決手段】センター側に何らかの障害が発生した場合に、センターは端末からの取引要求に対して特定のエラーコードを有した応答を返却し、端末はセンターからの応答がセンター障害を示す特定のエラーコードであれば、センター障害中であると認識し、取引を端末内の取引情報ファイルに格納し、取引を正常処理し、後にセンター復旧後に取引情報ファイルに格納されているセンター障害中に処理した取引をセンターに送信する。
【選択図】 図３
【解決手段】センター側に何らかの障害が発生した場合に、センターは端末からの取引要求に対して特定のエラーコードを有した応答を返却し、端末はセンターからの応答がセンター障害を示す特定のエラーコードであれば、センター障害中であると認識し、取引を端末内の取引情報ファイルに格納し、取引を正常処理し、後にセンター復旧後に取引情報ファイルに格納されているセンター障害中に処理した取引をセンターに送信する。
【選択図】 図３
Description
【０００１】
【発明の属する技術分野】
本発明は取引処理システムに関するものである。
【０００２】
【従来の技術】
決済処理に使用される端末はネットワークを介してセンターとオンラインで接続され、取引の都度端末を操作してセンターへ情報を送信し、センターではその取引の許可／不許可を判断してその結果を端末に応答し、端末はその応答結果に応じて次の処理を行うものが知られている（例えば、特許文献１参照）。
【０００３】
図７に示すように一般的な取引システムは、店舗１４０に設置され決済を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００を接続する回線網１３０とから構成される。なお、センターコンピュータ１１０とデータベース１２０からセンター１５０が構成される。
【０００４】
操作者は、物品あるいはサービスの提供に応じて店舗に設置されている端末１００を操作して売上等の情報をセンター１５０へ送信し、センター１５０からの情報を受信して物品あるいはサービスを提供する。
【０００５】
【特許文献１】
特開２００２−１１７３５１号公報（第２−６頁、図１、図２）
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来の取引システムでは、センターコンピュータ１１０やデータベース１２０からなるセンター１５０に障害が発生した場合、センター１５０は端末１００からの取引要求を正常に処理することができず拒否報告を端末１００に返す。そのため、端末１００もその取引を正常に処理することができず、その結果として取引は異常終了する。ここで、端末１００の操作者は、取引が異常終了したため再度同じ処理操作を試みるか、センター１５０に問合せを行う等の非定常作業をする必要がでてくる。また、取引が異常終了したことにより、売上機会の損失や売上を処理するための手作業の事務手続きを行わなければならないという問題が生じる。
【０００７】
本発明は、上記従来の課題に鑑み、センター１５０に何らかの障害が発生した場合でも、取引を継続して処理できる取引システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明の取引システムは、取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合に取引情報を処理して前記格納部に格納するものである。
【０００９】
また、本発明の取引システムは、前記センター側の異常が回復した後に前記情報端末は前記格納部に格納した取引情報を前記センターに送信するものである。
【００１０】
また、本発明の情報端末は、センターからセンター側が異常を生じている旨の特定の異常情報を受け取った場合には取引情報を処理して前記格納部に取引情報を格納し、前記センター側の異常が回復した後に前記格納部に格納した取引情報を前記センターに送信するものである。
【００１１】
【発明の実施の形態】
（実施の形態１）
以下、本発明の実施の形態１について、図１から図４を用いて説明する。
【００１２】
図１は、取引処理システムの概略構成を示すブロック図であり、この取引処理システムは、店舗１４０に設置されて取引処理を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００とを接続する回線網１３０から構成されている。なお、センターコンピュータ１１０とデータベース１２０とからセンター１５０が構成されている。
【００１３】
また、図２は、端末１００の概略構成を示すブロック図であり、端末１００は、センター１５０からの情報を処理する制御部１０１と、センター１５０との通信を行う通信部１０２と、金額等の情報を入力する入力部１０３と、取引情報を格納する取引情報格納部１０４と、取引の状況を表示する表示部１０５と、センター１５０が異常状態であるか否かの状況を意味する情報を記憶するセンター状況記憶部１０６と、日時を計測する計時部１０７と、前記センターが障害中であり前記センターへ取引要求を送信することなく取引情報を処理した回数をカウントするカウンタ１０８を備えている。
【００１４】
そして、図３は、本実施の形態における端末１００が行う取引処理の流れを示すフローチャートである。
【００１５】
物品の購買やサービスの提供の発生に伴い店員は端末１００を操作してこの取引の処理を行う。以下その流れについて図３を用いて説明する。
【００１６】
ステップＳ１０１において、店員は取引業務の内容を選択する。次に、ステップＳ１０２において、取引処理に必要なカード情報や金額等のデータを入力する。次に、端末１００はステップＳ１０３において、センター１５０に送信する取引電文を作成し、ステップＳ１０４においてセンター１５０へ送信する。
【００１７】
次に、この端末１００から送信されてきた情報の処理を行うセンター１５０の処理について図４を用いて説明する。図４はセンター１５０の処理の流れを示すフローチャートである。
【００１８】
センター１５０を構成するセンターコンピュータ１１０は、ステップＳ３０１において端末１００から送信された取引要求電文を受信する。次に、ステップＳ３０２においてセンター１５０の状態に異常が有るか否かを判断する。そしてその判断に基づいて次に行うステップが決まる。例えば、取引情報等を格納するデータベース１２０に障害が発生している場合にはセンター１５０に障害が発生しているとしてステップＳ３０４の処理に移行し、このステップＳ３０４において端末１００へ送る応答電文にセンター１５０が障害であることを示す特定のエラーコードをセットし、ステップＳ３０５においてエラーコードを含む応答電文を端末１００へ送信する。
【００１９】
ここで、図３に戻り、端末１００の処理について説明する。
【００２０】
端末１００はステップＳ１０５においてセンター１５０から送信された取引の応答電文を受信し、ステップＳ１０６においてこの応答電文に含まれる応答コードを確認し、この応答コードがセンター１５０が障害中であることを意味する特定の応答コードであった場合、ステップＳ１０７においてセンター１５０が障害中である旨の表示を表示部１０５に表示し、この取引を継続して処理するか否かの判断を端末操作者に要求する。端末操作者はこの取引を継続して処理するか中止するかを判断して端末１００に入力する。取引継続が指示されると端末１００はステップＳ１１０においてこの取引情報を端末１００内の取引情報格納部１１２に格納し、ステップＳ１１１においてこの取引を正常と判断して処理を終了する。
【００２１】
なお、端末１００は取引情報格納部１１２に格納されている情報をセンター１５０に一括して送信する取引情報一括送信機能を有しており、センター障害中に端末１００内に格納された取引情報は、センター１５０が障害から復旧した後に、取引情報一括送信機能を用いて端末１００からセンター１５０へ送信される。
【００２２】
また、取引を継続しないことが指示された場合はステップＳ１１２に移行し、異常処理であるとして異常である旨の伝票を出力部（図示せず）から出力して処理を終了する。
【００２３】
以上のように本実施の形態の取引処理システムは、センター１５０に何らかの障害が発生した場合、センター１５０を構成するセンターコンピュータ１１０は端末１００からの取引要求に対して特定のエラーコードを有した応答を返却する機能を備え、端末１００はセンター１５０からの応答が特定のエラーコードであればセンター１５０が障害中であると認識する機能を備え、この端末１００はセンター１５０が障害中の取引情報を取引情報格納部１１２に格納し、センター１５０の障害が復旧した後に取引情報格納部１１２に格納されている情報をセンター１５０に送信するようにしたことで、センター１５０の障害に起因する売上機会の損失や売上を処理するための手作業の事務手続きを削減することができる。
【００２４】
なお、センター１５０を構成するセンターコンピュータ１１０が異常を生じている場合は、センター１５０から端末１００に特定のエラーコードを送信することができないので、端末１００は取引情報を取引情報格納部１１２に格納することはせず、異常処理として終了する。すなわち、本実施の形態は、センターコンピュータ１１０は正常であり、このセンターコンピュータ１１０以外のセンター１５０の構成要素に異常が生じた場合を想定している。
【００２５】
（実施の形態２）
次に、本発明の取引システムの他の実施の形態について、図１と図２と図５を用いて説明する。図５は、端末１００が行う取引処理の流れを示すフローチャートである。
【００２６】
本実施の形態において、実施の形態１と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。実施の形態１と異なる点は２点有り、以下にそれを示す。
【００２７】
１点目は、一つ前の取引処理の時にセンター１５０が障害中であったか否かを示すフラグを記憶するセンター状況記憶部１０６を端末１００内に設け、電文編集処理（Ｓ１０３）後に、このフラグが障害中であったことを示す「１」であるか、障害中でなかったことを示す「０」であるかを端末１００内の制御部１０１）で確認し（Ｓ２０１）、障害中であったことを示す「１」の場合はセンター１５０への取引電文送信（Ｓ１０４）のステップに移行せず、直ちにセンター障害中表示（Ｓ１０９）のステップに移行する。すなわち、センター１５０が障害中はセンター１５０への電文の送信を行わないようにしたものである。
【００２８】
２点目は、ステップＳ２０１でフラグが障害中でなかったことを示す「０」であった場合の処理で、ステップＳ１０５、ステップＳ１０６の処理を行い、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードであった場合、フラグをセンター１５０が障害中であることを示す「１」に変更するステップ（Ｓ２０２）を設けた点である。
【００２９】
以上のように、本実施の形態では、端末１００内にセンター１５０が障害中であるか否かを判断するためのフラグを記憶するセンター状況記憶部１０６を設け、ステップＳ２０１においてセンター１５０の障害を確認するものとした。そして、センター１５０が障害中であることを示すフラグは、端末１００がセンター１５０が障害中であることを示す応答電文を受信した後に設定される（ステップＳ２０２）。
【００３０】
そして、ステップＳ２０１で示すように、センター１５０が障害中である旨のフラグが設定されている場合、端末１００はセンター１５０が障害中であると判断し、直ちにステップＳ１０７以降の処理に移行する。すなわち、センター１５０が障害中は、端末１００はセンター１５０へ電文送信することなく取引処理をすすめる。
【００３１】
（実施の形態３）
次に本発明の取引システムの他の実施の形態について、図１と図２と図６を用いて説明する。図６は本実施の形態における、端末１００が行う取引処理の流れを示すフローチャートである。
【００３２】
本実施の形態において、実施の形態２と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。実施の形態２と異なる点は３点有り、以下にそれを示す。
【００３３】
１点目は、ステップＳ２０１において、前回取引時にセンター１５０に障害が有りフラグが「１」である場合であっても、センター１５０の障害中に行われた取引の回数が規定の回数を超えた場合（Ｓ３０１）、あるいは障害発生時から日付が変わった場合（Ｓ３０２）には、端末１００からセンター１５０へ取引電文を送信（Ｓ１０４）するようにした点である。なお、日付が変わったか否かは、制御部１０１が計時部１０７の計時結果に基づいて判断する。
【００３４】
２点目は、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードでなかった場合、フラグをセンター１５０が障害中でないことを示す「０」に変更するステップ（Ｓ２０３）を設けた点である。
【００３５】
３点目は、端末１００にはセンター１５０の障害中に行われた取引の回数をカウントするカウンタ１０８が設けられており、このカウンタ１０８の数値を変更するステップとして、取引をオフラインで正常処理（Ｓ１１１）した後、カウンタ１０８の数値を１つ増やすステップ（Ｓ３０３）と、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定の応答コードでなかった場合、カウンタの数字を「０」にするステップ（Ｓ３０４）を設けている。
【００３６】
本実施の形態では実施形態２と同様に、センター１５０が障害中であるか否かを示すフラグを用いて、センター１５０の障害中には端末１００は取引電文をセンター１５０へ送信せずに処理するが、リスク軽減のため、所定の条件を満たす場合はたとえ前回取引時にセンター１５０が障害中であったとしてもセンター１５０へ取引電文を送信する。すなわち、センター１５０の障害中に端末１００内に格納される取引件数が規定回数を超えた場合、または、前回の障害発生から今回取引を行う場合に日付が変わっていれば、端末１００からセンター１５０に取引電文を送るようにしている。
【００３７】
これにより、センター１５０へ送信されずに処理されて端末１００に格納される取引件数が無闇に増大することを防止することができる。
【００３８】
具体的には、ステップＳ２０１でセンター１５０が障害中であると判断した後に、ステップＳ３０１にてセンター１５０の障害中に処理した取引件数を示すカウンタの値を確認し、規定値を超えている場合にはステップＳ１０４の取引電文送信に移行して取引電文がセンター１５０に送信される。また、ステップＳ３０２では、端末装置１００はセンター１５０が障害中となった日から日付が変わったか否かを確認し、日付が変わっていればステップＳ１０４の取引電文送信へ移行して取引電文がセンター１５０に送信される。
【００３９】
また、ステップＳ２０３においては、センター１５０が障害中であることを示すフラグは、センター１５０からの応答コードが正常またはセンターが障害中であることを示す特定コード以外のコードであった場合にクリアされる。
【００４０】
また、ステップＳ３０３においては、センター１５０の障害中に取引を処理する毎にカウンタの数を増加させる処理を行う。
【００４１】
以上のように、たとえ前回取引時にセンター１５０が障害中であったとしても、一定取引回数毎または日付が変わった場合にセンター１５０へ取引電文を送信することでリスクを軽減することができる。
【００４２】
なお、日付が変わると障害が復旧されている可能性が高いので、日付が変わった場合にセンター１５０へ取引電文を送信するようにすることは有効である。
【００４３】
【発明の効果】
以上のように本発明によると、端末と回線網とセンターから構成される取引システムにおいて、センター側が障害等で取引を正常に処理できない場合に端末内に取引情報を格納してその取引を正常に処理し、センターが復旧した後に格納されている取引情報をセンターに送信することにより、売上機会の損失あるいは売上を処理するための手作業の事務手続き発生を削減する効果を奏する。
【図面の簡単な説明】
【図１】本発明の実施の形態１の取引処理システムの概略構成を示すブロック図
【図２】本発明の実施の形態１の情報端末の概略構成を示すブロック図
【図３】本発明の実施の形態１の端末の処理の流れを示すフローチャート
【図４】本発明の実施の形態１のセンターの処理の流れを示すフローチャート
【図５】本発明の実施の形態２の端末の処理の流れを示すフローチャート
【図６】本発明の実施の形態３の端末の処理の流れを示すフローチャート
【図７】従来の取引処理システムの概略構成を示すブロック図
【符号の説明】
１００ 端末
１０１ 制御部
１０２ 通信部
１０３ 入力部
１０４ 取引情報格納部
１０５ 表示部
１０６ センター状況記憶部
１０７ 計時部
１０８ 計数部
１１０ センターコンピュータ
１２０ データベース
１３０ 回線網
１４０ 店舗
１５０ センター
【発明の属する技術分野】
本発明は取引処理システムに関するものである。
【０００２】
【従来の技術】
決済処理に使用される端末はネットワークを介してセンターとオンラインで接続され、取引の都度端末を操作してセンターへ情報を送信し、センターではその取引の許可／不許可を判断してその結果を端末に応答し、端末はその応答結果に応じて次の処理を行うものが知られている（例えば、特許文献１参照）。
【０００３】
図７に示すように一般的な取引システムは、店舗１４０に設置され決済を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００を接続する回線網１３０とから構成される。なお、センターコンピュータ１１０とデータベース１２０からセンター１５０が構成される。
【０００４】
操作者は、物品あるいはサービスの提供に応じて店舗に設置されている端末１００を操作して売上等の情報をセンター１５０へ送信し、センター１５０からの情報を受信して物品あるいはサービスを提供する。
【０００５】
【特許文献１】
特開２００２−１１７３５１号公報（第２−６頁、図１、図２）
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来の取引システムでは、センターコンピュータ１１０やデータベース１２０からなるセンター１５０に障害が発生した場合、センター１５０は端末１００からの取引要求を正常に処理することができず拒否報告を端末１００に返す。そのため、端末１００もその取引を正常に処理することができず、その結果として取引は異常終了する。ここで、端末１００の操作者は、取引が異常終了したため再度同じ処理操作を試みるか、センター１５０に問合せを行う等の非定常作業をする必要がでてくる。また、取引が異常終了したことにより、売上機会の損失や売上を処理するための手作業の事務手続きを行わなければならないという問題が生じる。
【０００７】
本発明は、上記従来の課題に鑑み、センター１５０に何らかの障害が発生した場合でも、取引を継続して処理できる取引システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明の取引システムは、取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合に取引情報を処理して前記格納部に格納するものである。
【０００９】
また、本発明の取引システムは、前記センター側の異常が回復した後に前記情報端末は前記格納部に格納した取引情報を前記センターに送信するものである。
【００１０】
また、本発明の情報端末は、センターからセンター側が異常を生じている旨の特定の異常情報を受け取った場合には取引情報を処理して前記格納部に取引情報を格納し、前記センター側の異常が回復した後に前記格納部に格納した取引情報を前記センターに送信するものである。
【００１１】
【発明の実施の形態】
（実施の形態１）
以下、本発明の実施の形態１について、図１から図４を用いて説明する。
【００１２】
図１は、取引処理システムの概略構成を示すブロック図であり、この取引処理システムは、店舗１４０に設置されて取引処理を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００とを接続する回線網１３０から構成されている。なお、センターコンピュータ１１０とデータベース１２０とからセンター１５０が構成されている。
【００１３】
また、図２は、端末１００の概略構成を示すブロック図であり、端末１００は、センター１５０からの情報を処理する制御部１０１と、センター１５０との通信を行う通信部１０２と、金額等の情報を入力する入力部１０３と、取引情報を格納する取引情報格納部１０４と、取引の状況を表示する表示部１０５と、センター１５０が異常状態であるか否かの状況を意味する情報を記憶するセンター状況記憶部１０６と、日時を計測する計時部１０７と、前記センターが障害中であり前記センターへ取引要求を送信することなく取引情報を処理した回数をカウントするカウンタ１０８を備えている。
【００１４】
そして、図３は、本実施の形態における端末１００が行う取引処理の流れを示すフローチャートである。
【００１５】
物品の購買やサービスの提供の発生に伴い店員は端末１００を操作してこの取引の処理を行う。以下その流れについて図３を用いて説明する。
【００１６】
ステップＳ１０１において、店員は取引業務の内容を選択する。次に、ステップＳ１０２において、取引処理に必要なカード情報や金額等のデータを入力する。次に、端末１００はステップＳ１０３において、センター１５０に送信する取引電文を作成し、ステップＳ１０４においてセンター１５０へ送信する。
【００１７】
次に、この端末１００から送信されてきた情報の処理を行うセンター１５０の処理について図４を用いて説明する。図４はセンター１５０の処理の流れを示すフローチャートである。
【００１８】
センター１５０を構成するセンターコンピュータ１１０は、ステップＳ３０１において端末１００から送信された取引要求電文を受信する。次に、ステップＳ３０２においてセンター１５０の状態に異常が有るか否かを判断する。そしてその判断に基づいて次に行うステップが決まる。例えば、取引情報等を格納するデータベース１２０に障害が発生している場合にはセンター１５０に障害が発生しているとしてステップＳ３０４の処理に移行し、このステップＳ３０４において端末１００へ送る応答電文にセンター１５０が障害であることを示す特定のエラーコードをセットし、ステップＳ３０５においてエラーコードを含む応答電文を端末１００へ送信する。
【００１９】
ここで、図３に戻り、端末１００の処理について説明する。
【００２０】
端末１００はステップＳ１０５においてセンター１５０から送信された取引の応答電文を受信し、ステップＳ１０６においてこの応答電文に含まれる応答コードを確認し、この応答コードがセンター１５０が障害中であることを意味する特定の応答コードであった場合、ステップＳ１０７においてセンター１５０が障害中である旨の表示を表示部１０５に表示し、この取引を継続して処理するか否かの判断を端末操作者に要求する。端末操作者はこの取引を継続して処理するか中止するかを判断して端末１００に入力する。取引継続が指示されると端末１００はステップＳ１１０においてこの取引情報を端末１００内の取引情報格納部１１２に格納し、ステップＳ１１１においてこの取引を正常と判断して処理を終了する。
【００２１】
なお、端末１００は取引情報格納部１１２に格納されている情報をセンター１５０に一括して送信する取引情報一括送信機能を有しており、センター障害中に端末１００内に格納された取引情報は、センター１５０が障害から復旧した後に、取引情報一括送信機能を用いて端末１００からセンター１５０へ送信される。
【００２２】
また、取引を継続しないことが指示された場合はステップＳ１１２に移行し、異常処理であるとして異常である旨の伝票を出力部（図示せず）から出力して処理を終了する。
【００２３】
以上のように本実施の形態の取引処理システムは、センター１５０に何らかの障害が発生した場合、センター１５０を構成するセンターコンピュータ１１０は端末１００からの取引要求に対して特定のエラーコードを有した応答を返却する機能を備え、端末１００はセンター１５０からの応答が特定のエラーコードであればセンター１５０が障害中であると認識する機能を備え、この端末１００はセンター１５０が障害中の取引情報を取引情報格納部１１２に格納し、センター１５０の障害が復旧した後に取引情報格納部１１２に格納されている情報をセンター１５０に送信するようにしたことで、センター１５０の障害に起因する売上機会の損失や売上を処理するための手作業の事務手続きを削減することができる。
【００２４】
なお、センター１５０を構成するセンターコンピュータ１１０が異常を生じている場合は、センター１５０から端末１００に特定のエラーコードを送信することができないので、端末１００は取引情報を取引情報格納部１１２に格納することはせず、異常処理として終了する。すなわち、本実施の形態は、センターコンピュータ１１０は正常であり、このセンターコンピュータ１１０以外のセンター１５０の構成要素に異常が生じた場合を想定している。
【００２５】
（実施の形態２）
次に、本発明の取引システムの他の実施の形態について、図１と図２と図５を用いて説明する。図５は、端末１００が行う取引処理の流れを示すフローチャートである。
【００２６】
本実施の形態において、実施の形態１と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。実施の形態１と異なる点は２点有り、以下にそれを示す。
【００２７】
１点目は、一つ前の取引処理の時にセンター１５０が障害中であったか否かを示すフラグを記憶するセンター状況記憶部１０６を端末１００内に設け、電文編集処理（Ｓ１０３）後に、このフラグが障害中であったことを示す「１」であるか、障害中でなかったことを示す「０」であるかを端末１００内の制御部１０１）で確認し（Ｓ２０１）、障害中であったことを示す「１」の場合はセンター１５０への取引電文送信（Ｓ１０４）のステップに移行せず、直ちにセンター障害中表示（Ｓ１０９）のステップに移行する。すなわち、センター１５０が障害中はセンター１５０への電文の送信を行わないようにしたものである。
【００２８】
２点目は、ステップＳ２０１でフラグが障害中でなかったことを示す「０」であった場合の処理で、ステップＳ１０５、ステップＳ１０６の処理を行い、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードであった場合、フラグをセンター１５０が障害中であることを示す「１」に変更するステップ（Ｓ２０２）を設けた点である。
【００２９】
以上のように、本実施の形態では、端末１００内にセンター１５０が障害中であるか否かを判断するためのフラグを記憶するセンター状況記憶部１０６を設け、ステップＳ２０１においてセンター１５０の障害を確認するものとした。そして、センター１５０が障害中であることを示すフラグは、端末１００がセンター１５０が障害中であることを示す応答電文を受信した後に設定される（ステップＳ２０２）。
【００３０】
そして、ステップＳ２０１で示すように、センター１５０が障害中である旨のフラグが設定されている場合、端末１００はセンター１５０が障害中であると判断し、直ちにステップＳ１０７以降の処理に移行する。すなわち、センター１５０が障害中は、端末１００はセンター１５０へ電文送信することなく取引処理をすすめる。
【００３１】
（実施の形態３）
次に本発明の取引システムの他の実施の形態について、図１と図２と図６を用いて説明する。図６は本実施の形態における、端末１００が行う取引処理の流れを示すフローチャートである。
【００３２】
本実施の形態において、実施の形態２と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。実施の形態２と異なる点は３点有り、以下にそれを示す。
【００３３】
１点目は、ステップＳ２０１において、前回取引時にセンター１５０に障害が有りフラグが「１」である場合であっても、センター１５０の障害中に行われた取引の回数が規定の回数を超えた場合（Ｓ３０１）、あるいは障害発生時から日付が変わった場合（Ｓ３０２）には、端末１００からセンター１５０へ取引電文を送信（Ｓ１０４）するようにした点である。なお、日付が変わったか否かは、制御部１０１が計時部１０７の計時結果に基づいて判断する。
【００３４】
２点目は、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードでなかった場合、フラグをセンター１５０が障害中でないことを示す「０」に変更するステップ（Ｓ２０３）を設けた点である。
【００３５】
３点目は、端末１００にはセンター１５０の障害中に行われた取引の回数をカウントするカウンタ１０８が設けられており、このカウンタ１０８の数値を変更するステップとして、取引をオフラインで正常処理（Ｓ１１１）した後、カウンタ１０８の数値を１つ増やすステップ（Ｓ３０３）と、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定の応答コードでなかった場合、カウンタの数字を「０」にするステップ（Ｓ３０４）を設けている。
【００３６】
本実施の形態では実施形態２と同様に、センター１５０が障害中であるか否かを示すフラグを用いて、センター１５０の障害中には端末１００は取引電文をセンター１５０へ送信せずに処理するが、リスク軽減のため、所定の条件を満たす場合はたとえ前回取引時にセンター１５０が障害中であったとしてもセンター１５０へ取引電文を送信する。すなわち、センター１５０の障害中に端末１００内に格納される取引件数が規定回数を超えた場合、または、前回の障害発生から今回取引を行う場合に日付が変わっていれば、端末１００からセンター１５０に取引電文を送るようにしている。
【００３７】
これにより、センター１５０へ送信されずに処理されて端末１００に格納される取引件数が無闇に増大することを防止することができる。
【００３８】
具体的には、ステップＳ２０１でセンター１５０が障害中であると判断した後に、ステップＳ３０１にてセンター１５０の障害中に処理した取引件数を示すカウンタの値を確認し、規定値を超えている場合にはステップＳ１０４の取引電文送信に移行して取引電文がセンター１５０に送信される。また、ステップＳ３０２では、端末装置１００はセンター１５０が障害中となった日から日付が変わったか否かを確認し、日付が変わっていればステップＳ１０４の取引電文送信へ移行して取引電文がセンター１５０に送信される。
【００３９】
また、ステップＳ２０３においては、センター１５０が障害中であることを示すフラグは、センター１５０からの応答コードが正常またはセンターが障害中であることを示す特定コード以外のコードであった場合にクリアされる。
【００４０】
また、ステップＳ３０３においては、センター１５０の障害中に取引を処理する毎にカウンタの数を増加させる処理を行う。
【００４１】
以上のように、たとえ前回取引時にセンター１５０が障害中であったとしても、一定取引回数毎または日付が変わった場合にセンター１５０へ取引電文を送信することでリスクを軽減することができる。
【００４２】
なお、日付が変わると障害が復旧されている可能性が高いので、日付が変わった場合にセンター１５０へ取引電文を送信するようにすることは有効である。
【００４３】
【発明の効果】
以上のように本発明によると、端末と回線網とセンターから構成される取引システムにおいて、センター側が障害等で取引を正常に処理できない場合に端末内に取引情報を格納してその取引を正常に処理し、センターが復旧した後に格納されている取引情報をセンターに送信することにより、売上機会の損失あるいは売上を処理するための手作業の事務手続き発生を削減する効果を奏する。
【図面の簡単な説明】
【図１】本発明の実施の形態１の取引処理システムの概略構成を示すブロック図
【図２】本発明の実施の形態１の情報端末の概略構成を示すブロック図
【図３】本発明の実施の形態１の端末の処理の流れを示すフローチャート
【図４】本発明の実施の形態１のセンターの処理の流れを示すフローチャート
【図５】本発明の実施の形態２の端末の処理の流れを示すフローチャート
【図６】本発明の実施の形態３の端末の処理の流れを示すフローチャート
【図７】従来の取引処理システムの概略構成を示すブロック図
【符号の説明】
１００ 端末
１０１ 制御部
１０２ 通信部
１０３ 入力部
１０４ 取引情報格納部
１０５ 表示部
１０６ センター状況記憶部
１０７ 計時部
１０８ 計数部
１１０ センターコンピュータ
１２０ データベース
１３０ 回線網
１４０ 店舗
１５０ センター
Claims (9)
- 取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合に取引情報を処理して前記格納部に格納する取引処理システム。
- 取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合に取引情報を処理して前記格納部に格納し、前記センター側の異常が回復した後に前記情報端末は前記格納部に格納した取引情報を前記センターに送信する取引処理システム。
- 取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記回線網を介して前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合にセンター側の障害状態を端末内に記憶し、取引情報を処理して前記格納部に格納し、これ以後の取引についてはセンターへ取引要求を送信することなく取引情報を処理して前記格納部に格納し、前記センター側の異常が回復した後に前記情報端末は前記格納部に格納した取引情報を前記センターに送信する取引処理システム。
- 取引情報を格納する格納部を有する情報端末と、前記情報端末から送られてきた情報を処理した後にこの処理した情報を蓄積するデータベースを有しており前記情報端末との間で情報のやり取りを行うセンターとを備えた取引処理システムであって、前記情報端末は前記センターに取引要求を送り、前記センターはこの取引要求を受け取って取引処理を行い、前記センターはこの取引処理に基づいて前記情報端末に取引情報を送り、この取引情報を送る際にこのセンター側で異常を生じている場合にはこのセンターは前記情報端末に特定の異常情報を送り、前記情報端末はこの特定の異常情報を受け取った場合にセンター側の障害状態を端末内に記憶し、取引情報を処理して前記格納部に格納し、これ以後の取引についてはセンターへ取引要求を送信することなく取引情報を処理して前記格納部に格納し、センターへ取引要求を送信することなく取引情報を処理した取引が規定回数を超えた場合またはセンターから特定の異常情報を受け取った日から日付が変わった場合にセンターへ取引を送信することによってセンターの復旧を検知し、前記センター側の異常が回復した後に前記情報端末は前記格納部に格納した取引情報を前記センターに送信する取引処理システム。
- 特定の異常情報はセンター側が一時的に障害となっている旨の情報である請求項１から４のいずれかに記載の取引処理システム。
- センターとの通信を行う通信部と、取引情報を格納する格納部と、前記センターからの情報を処理する制御部とを備え、前記制御部が前記センターから受信した情報はセンター側が異常を生じている旨の特定の異常情報であると認識した場合、前記制御部は取引情報を処理して前記格納部に格納し、前記センター側の異常が回復した後に前記格納部に格納した取引情報を前記センターに送信する情報端末。
- センターとの通信を行う通信部と、取引情報を格納する格納部と、前記センターからの情報を処理する制御部と、前記センターの障害状態を記憶する記憶部とを備え、前記制御部が前記センターから受信した情報はセンター側が異常を生じている旨の特定の異常情報であると認識した場合、前記制御部は前記記憶部に前記センターが異常である旨を記憶し、これ以後の取引については前記センターへ取引要求を送信することなく取引情報を処理して前記格納部に格納し、前記センター側の異常が回復した後に前記格納部に格納した取引情報を前記センターに送信する情報端末。
- センターとの通信を行う通信部と、取引情報を格納する格納部と、前記センターからの情報を処理する制御部と、前記センターの障害状態を記憶する記憶部と、前記センターが障害中である場合に前記センターへ取引要求を送信することなく取引情報を処理した回数を数える計数部と、日時を計測する計時部とを備え、前記制御部が前記センターから受信した情報はセンター側が異常を生じている旨の特定の異常情報であると認識した場合、前記制御部は前記センターが異常である旨を前記記憶部に記憶し、これ以後の取引については前記センターへ取引要求を送信することなく取引情報を処理して前記格納部に格納し、前記計数部の回数が規定数を超えた場合または前記制御部が前記計時部の計時結果に基づいて前記センターから特定の異常情報を受け取った日から日付が変わったと判断した場合、前記センターへ取引を送信することによって前記センターの復旧を検知し、前記センターの異常が回復した後に前記格納部に格納した取引情報を前記センターに送信する情報端末。
- 特定の異常情報はセンター側が一時的に障害となっている旨の情報である請求項６から８のいずれかに記載の情報端末。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003088440A JP4100217B2 (ja) | 2003-03-27 | 2003-03-27 | 取引処理システムおよび情報端末 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003088440A JP4100217B2 (ja) | 2003-03-27 | 2003-03-27 | 取引処理システムおよび情報端末 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295614A true JP2004295614A (ja) | 2004-10-21 |
| JP4100217B2 JP4100217B2 (ja) | 2008-06-11 |
Family
ID=33402569
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003088440A Expired - Lifetime JP4100217B2 (ja) | 2003-03-27 | 2003-03-27 | 取引処理システムおよび情報端末 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4100217B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014115575A1 (ja) * | 2013-01-25 | 2014-07-31 | 日立オムロンターミナルソリューションズ株式会社 | 現金処理システム及び方法 |
| US11695853B1 (en) * | 2022-04-07 | 2023-07-04 | T-Mobile Usa, Inc. | Content management systems providing zero recovery point objective |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103268678B (zh) * | 2013-05-09 | 2016-02-24 | 雅酷时空科技开发（北京）有限公司 | 一种pos终端、服务器及处理发卡行识别码冲突的方法 |
-
2003
- 2003-03-27 JP JP2003088440A patent/JP4100217B2/ja not_active Expired - Lifetime
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014115575A1 (ja) * | 2013-01-25 | 2014-07-31 | 日立オムロンターミナルソリューションズ株式会社 | 現金処理システム及び方法 |
| JP2014142870A (ja) * | 2013-01-25 | 2014-08-07 | Hitachi Omron Terminal Solutions Corp | 現金処理システム及び方法 |
| US11695853B1 (en) * | 2022-04-07 | 2023-07-04 | T-Mobile Usa, Inc. | Content management systems providing zero recovery point objective |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4100217B2 (ja) | 2008-06-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101756594B1 (ko) | 대행 승인을 통한 금융 거래 승인 무중단 서비스 제공 방법 및 이를 수행하는 카드사 서버 | |
| JPS61156368A (ja) | テ−ブル内容変更制御方式 | |
| EP1672501A2 (en) | Fault tolerant duplex computer system and its control method | |
| CN110310170A (zh) | 订单处理方法、装置、电子设备及存储介质 | |
| EP0474886A1 (en) | Transaction processor | |
| US20160300232A1 (en) | Monitoring assistance device | |
| CN110599318A (zh) | 对账方法、装置以及存储介质 | |
| JP2004295614A (ja) | 取引処理システムおよび情報端末 | |
| CN112990871A (zh) | 一种单据处理方法及相关设备 | |
| JP3976461B2 (ja) | 商品管理システムにおける携帯型無線端末の故障監視方法及び該方法の実施プログラムを記録した記憶媒体 | |
| JP4536052B2 (ja) | キッチンディスプレイデータの送受信方法及びその方法を用いたシステム | |
| JPS6367703B2 (ja) | ||
| JP2004178480A (ja) | 取引伝票管理方法及び取引伝票管理プログラム | |
| JPH06195571A (ja) | 商品販売データ処理装置 | |
| JP4014259B2 (ja) | 約定情報表示システム | |
| JP2002189856A (ja) | 金融商品発注装置、金融商品発注方法及び金融商品発注用プログラムがコンピュータで読取可能に記録された情報記録媒体 | |
| JP4664847B2 (ja) | 過誤発注防止方法 | |
| JPH04107034A (ja) | リトライ回数学習装置 | |
| JPS5936300B2 (ja) | 商品販売デ−タ処理システム | |
| JPS6249560A (ja) | デ−タ送信方式 | |
| US20220005061A1 (en) | Electronic device for providing product sale managing information and method thereof | |
| JP3628159B2 (ja) | 取引システムの取引データ処理方法及び取引システム | |
| AU2020281182A1 (en) | Electronic apparatus for providing item sale managing information and method thereof | |
| JPH05216908A (ja) | オンラインシステムとその運用方法 | |
| CN116821192A (zh) | 资产数据查询方法、装置及计算机设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041220 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050708 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070627 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070703 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070827 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070925 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071101 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080226 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080310 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4100217 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140328 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |