JP4100217B2 - 取引処理システムおよび情報端末 - Google Patents
取引処理システムおよび情報端末 Download PDFInfo
- Publication number
- JP4100217B2 JP4100217B2 JP2003088440A JP2003088440A JP4100217B2 JP 4100217 B2 JP4100217 B2 JP 4100217B2 JP 2003088440 A JP2003088440 A JP 2003088440A JP 2003088440 A JP2003088440 A JP 2003088440A JP 4100217 B2 JP4100217 B2 JP 4100217B2
- Authority
- JP
- Japan
- Prior art keywords
- center
- information
- transaction
- abnormality
- terminal
- 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.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は取引処理システムに関するものである。
【０００２】
【従来の技術】
決済処理に使用される端末はネットワークを介してセンターとオンラインで接続され、取引の都度端末を操作してセンターへ情報を送信し、センターではその取引の許可／不許可を判断してその結果を端末に応答し、端末はその応答結果に応じて次の処理を行うものが知られている（例えば、特許文献１参照）。
【０００３】
図７に示すように一般的な取引システムは、店舗１４０に設置され決済を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００を接続する回線網１３０とから構成される。なお、センターコンピュータ１１０とデータベース１２０からセンター１５０が構成される。
【０００４】
操作者は、物品あるいはサービスの提供に応じて店舗に設置されている端末１００を操作して売上等の情報をセンター１５０へ送信し、センター１５０からの情報を受信して物品あるいはサービスを提供する。
【０００５】
【特許文献１】
特開２００２−１１７３５１号公報（第２−６頁、図１、図２）
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来の取引システムでは、センターコンピュータ１１０やデータベース１２０からなるセンター１５０に障害が発生した場合、センター１５０は端末１００からの取引要求を正常に処理することができず拒否報告を端末１００に返す。そのため、端末１００もその取引を正常に処理することができず、その結果として取引は異常終了する。ここで、端末１００の操作者は、取引が異常終了したため再度同じ処理操作を試みるか、センター１５０に問合せを行う等の非定常作業をする必要がでてくる。また、取引が異常終了したことにより、売上機会の損失や売上を処理するための手作業の事務手続きを行わなければならないという問題が生じる。
【０００７】
本発明は、上記従来の課題に鑑み、センター１５０に何らかの障害が発生した場合でも、取引を継続して処理できる取引システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記課題を解決するために本発明は、センターとの相互通信を行う通信部と、取引情報を格納する格納部と、日時を計測する計時部と、前記センターからの情報を処理する制御部と、取引件数を記録するカウンタと、以前の取引において前記センターから異常を生じている旨の異常情報を受け取った場合に異常発生中であることを示すフラグを記憶するためのセンター状況記憶部と、を備え、前記制御部は、今回の取引要求を送信するときに、前記フラグによってセンターにおいて異常発生中と認識した場合、前記異常が発生した以降の取引件数が規定値を越えるまでは前記センターへ取引要求を送信することなく上記取引情報を処理して前記格納部に格納し、さらに前記センターの異常が回復した後にこれをセンターに送信するとともに、前記取引件数が規定値を越えた場合及び前記制御部が前記計時部の計時結果に基づいて前記センターから前記異常情報を受け取った以降に日付が変わったと判断した場合、前記センターへ今回の取引要求を送信し、前記センターからの応答が前記異常情報以外の場合には前記フラグをクリアして正常処理を行い、該応答が前記異常情報であった場合は該フラグを異常発生中にし、上記取引情報を処理して前記格納部に格納し、前記センターの異常が回復した後に送信するように構成した。
【００１１】
【発明の実施の形態】
（前提の形態１）
以下、前提の形態１について、図１から図４を用いて説明する。
【００１２】
図１は、取引処理システムの概略構成を示すブロック図であり、この取引処理システムは、店舗１４０に設置されて取引処理を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００とを接続する回線網１３０から構成されている。なお、センターコンピュータ１１０とデータベース１２０とからセンター１５０が構成されている。
【００１３】
また、図２は、端末１００の概略構成を示すブロック図であり、端末１００は、センター１５０からの情報を処理する制御部１０１と、センター１５０との通信を行う通信部１０２と、金額等の情報を入力する入力部１０３と、取引情報を格納する取引情報格納部１０４と、取引の状況を表示する表示部１０５と、センター１５０が異常状態であるか否かの状況を意味する情報を記憶するセンター状況記憶部１０６と、日時を計測する計時部１０７と、前記センターが障害中であり前記センターへ取引要求を送信することなく取引情報を処理した回数をカウントするカウンタ１０８を備えている。
【００１４】
そして、図３は、前提の形態１における端末１００が行う取引処理の流れを示すフローチャートである。
【００１５】
物品の購買やサービスの提供の発生に伴い店員は端末１００を操作してこの取引の処理を行う。以下その流れについて図３を用いて説明する。
【００１６】
ステップＳ１０１において、店員は取引業務の内容を選択する。次に、ステップＳ１０２において、取引処理に必要なカード情報や金額等のデータを入力する。次に、端末１００はステップＳ１０３において、センター１５０に送信する取引電文を作成し、ステップＳ１０４においてセンター１５０へ送信する。
【００１７】
次に、この端末１００から送信されてきた情報の処理を行うセンター１５０の処理について図４を用いて説明する。図４はセンター１５０の処理の流れを示すフローチャートである。
【００１８】
センター１５０を構成するセンターコンピュータ１１０は、ステップＳ３０１において端末１００から送信された取引要求電文を受信する。次に、ステップＳ３０２においてセンター１５０の状態に異常が有るか否かを判断する。そしてその判断に基づいて次に行うステップが決まる。例えば、取引情報等を格納するデータベース１２０に障害が発生している場合にはセンター１５０に障害が発生しているとしてステップＳ３０４の処理に移行し、このステップＳ３０４において端末１００へ送る応答電文にセンター１５０が障害であることを示す特定のエラーコードをセットし、ステップＳ３０５においてエラーコードを含む応答電文を端末１００へ送信する。
【００１９】
ここで、図３に戻り、端末１００の処理について説明する。
【００２０】
端末１００はステップＳ１０５においてセンター１５０から送信された取引の応答電文を受信し、ステップＳ１０６においてこの応答電文に含まれる応答コードを確認し、この応答コードがセンター１５０が障害中であることを意味する特定の応答コードであった場合、ステップＳ１０７においてセンター１５０が障害中である旨の表示を表示部１０５に表示し、この取引を継続して処理するか否かの判断を端末操作者に要求する。端末操作者はこの取引を継続して処理するか中止するかを判断して端末１００に入力する。取引継続が指示されると端末１００はステップＳ１１０においてこの取引情報を端末１００内の取引情報格納部１１２に格納し、ステップＳ１１１においてこの取引を正常と判断して処理を終了する。
【００２１】
なお、端末１００は取引情報格納部１１２に格納されている情報をセンター１５０に一括して送信する取引情報一括送信機能を有しており、センター障害中に端末１００内に格納された取引情報は、センター１５０が障害から復旧した後に、取引情報一括送信機能を用いて端末１００からセンター１５０へ送信される。
【００２２】
また、取引を継続しないことが指示された場合はステップＳ１１２に移行し、異常処理であるとして異常である旨の伝票を出力部（図示せず）から出力して処理を終了する。
【００２３】
以上のように前提の形態１の取引処理システムは、センター１５０に何らかの障害が発生した場合、センター１５０を構成するセンターコンピュータ１１０は端末１００からの取引要求に対して特定のエラーコードを有した応答を返却する機能を備え、端末１００はセンター１５０からの応答が特定のエラーコードであればセンター１５０が障害中であると認識する機能を備え、この端末１００はセンター１５０が障害中の取引情報を取引情報格納部１１２に格納し、センター１５０の障害が復旧した後に取引情報格納部１１２に格納されている情報をセンター１５０に送信するようにしたことで、センター１５０の障害に起因する売上機会の損失や売上を処理するための手作業の事務手続きを削減することができる。
【００２４】
なお、センター１５０を構成するセンターコンピュータ１１０が異常を生じている場合は、センター１５０から端末１００に特定のエラーコードを送信することができないので、端末１００は取引情報を取引情報格納部１１２に格納することはせず、異常処理として終了する。すなわち、本実施の形態は、センターコンピュータ１１０は正常であり、このセンターコンピュータ１１０以外のセンター１５０の構成要素に異常が生じた場合を想定している。
【００２５】
（前提の形態２）
次に、取引システムの前提の形態２について、図１と図２と図５を用いて説明する。図５は、端末１００が行う取引処理の流れを示すフローチャートである。
【００２６】
前提の形態２において、前提の形態１と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。前提の形態１と異なる点は２点有り、以下にそれを示す。
【００２７】
１点目は、一つ前の取引処理の時にセンター１５０が障害中であったか否かを示すフラグを記憶するセンター状況記憶部１０６を端末１００内に設け、電文編集処理（Ｓ１０３）後に、このフラグが障害中であったことを示す「１」であるか、障害中でなかったことを示す「０」であるかを端末１００内の制御部１０１）で確認し（Ｓ２０１）、障害中であったことを示す「１」の場合はセンター１５０への取引電文送信（Ｓ１０４）のステップに移行せず、直ちにセンター障害中表示（Ｓ１０９）のステップに移行する。すなわち、センター１５０が障害中はセンター１５０への電文の送信を行わないようにしたものである。
【００２８】
２点目は、ステップＳ２０１でフラグが障害中でなかったことを示す「０」であった場合の処理で、ステップＳ１０５、ステップＳ１０６の処理を行い、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードであった場合、フラグをセンター１５０が障害中であることを示す「１」に変更するステップ（Ｓ２０２）を設けた点である。
【００２９】
以上のように、本前提の形態２では、端末１００内にセンター１５０が障害中であるか否かを判断するためのフラグを記憶するセンター状況記憶部１０６を設け、ステップＳ２０１においてセンター１５０の障害を確認するものとした。そして、センター１５０が障害中であることを示すフラグは、端末１００がセンター１５０が障害中であることを示す応答電文を受信した後に設定される（ステップＳ２０２）。
【００３０】
そして、ステップＳ２０１で示すように、センター１５０が障害中である旨のフラグが設定されている場合、端末１００はセンター１５０が障害中であると判断し、直ちにステップＳ１０７以降の処理に移行する。すなわち、センター１５０が障害中は、端末１００はセンター１５０へ電文送信することなく取引処理をすすめる。
【００３１】
（実施の形態１）
次に本発明の取引システムの実施の形態について、図１と図２と図６を用いて説明する。図６は本実施の形態における、端末１００が行う取引処理の流れを示すフローチャートである。
【００３２】
本実施の形態において、前提の形態２と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。前提の形態２と異なる点は３点有り、以下にそれを示す。
【００３３】
１点目は、ステップＳ２０１において、前回取引時にセンター１５０に障害が有りフラグが「１」である場合であっても、センター１５０の障害中に行われた取引の回数が規定の回数を超えた場合（Ｓ３０１）、あるいは障害発生時から日付が変わった場合（Ｓ３０２）には、端末１００からセンター１５０へ取引電文を送信（Ｓ１０４）するようにした点である。なお、日付が変わったか否かは、制御部１０１が計時部１０７の計時結果に基づいて判断する。
【００３４】
２点目は、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードでなかった場合、フラグをセンター１５０が障害中でないことを示す「０」に変更するステップ（Ｓ２０３）を設けた点である。
【００３５】
３点目は、端末１００にはセンター１５０の障害中に行われた取引の回数をカウントするカウンタ１０８が設けられており、このカウンタ１０８の数値を変更するステップとして、取引をオフラインで正常処理（Ｓ１１１）した後、カウンタ１０８の数値を１つ増やすステップ（Ｓ３０３）と、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定の応答コードでなかった場合、カウンタの数字を「０」にするステップ（Ｓ３０４）を設けている。
【００３６】
本実施の形態では前提の形態２と同様に、センター１５０が障害中であるか否かを示すフラグを用いて、センター１５０の障害中には端末１００は取引電文をセンター１５０へ送信せずに処理するが、リスク軽減のため、所定の条件を満たす場合はたとえ前回取引時にセンター１５０が障害中であったとしてもセンター１５０へ取引電文を送信する。すなわち、センター１５０の障害中に端末１００内に格納される取引件数が規定回数を超えた場合、または、前回の障害発生から今回取引を行う場合に日付が変わっていれば、端末１００からセンター１５０に取引電文を送るようにしている。
【００３７】
これにより、センター１５０へ送信されずに処理されて端末１００に格納される取引件数が無闇に増大することを防止することができる。
【００３８】
具体的には、ステップＳ２０１でセンター１５０が障害中であると判断した後に、ステップＳ３０１にてセンター１５０の障害中に処理した取引件数を示すカウンタの値を確認し、規定値を超えている場合にはステップＳ１０４の取引電文送信に移行して取引電文がセンター１５０に送信される。また、ステップＳ３０２では、端末装置１００はセンター１５０が障害中となった日から日付が変わったか否かを確認し、日付が変わっていればステップＳ１０４の取引電文送信へ移行して取引電文がセンター１５０に送信される。
【００３９】
また、ステップＳ２０３においては、センター１５０が障害中であることを示すフラグは、センター１５０からの応答コードが正常またはセンターが障害中であることを示す特定コード以外のコードであった場合にクリアされる。
【００４０】
また、ステップＳ３０３においては、センター１５０の障害中に取引を処理する毎にカウンタの数を増加させる処理を行う。
【００４１】
以上のように、たとえ前回取引時にセンター１５０が障害中であったとしても、一定取引回数毎または日付が変わった場合にセンター１５０へ取引電文を送信することでリスクを軽減することができる。
【００４２】
なお、日付が変わると障害が復旧されている可能性が高いので、日付が変わった場合にセンター１５０へ取引電文を送信するようにすることは有効である。
【００４３】
【発明の効果】
以上のように本発明によると、端末と回線網とセンターから構成される取引システムにおいて、センター側が障害等で取引を正常に処理できない場合に端末内に取引情報を格納してその取引を正常に処理し、センターが復旧した後に格納されている取引情報をセンターに送信することにより、売上機会の損失あるいは売上を処理するための手作業の事務手続き発生を削減する効果を奏する。
【図面の簡単な説明】
【図１】前提の形態１の取引処理システムの概略構成を示すブロック図
【図２】前提の形態１の情報端末の概略構成を示すブロック図
【図３】前提の形態１の端末の処理の流れを示すフローチャート
【図４】前提の形態１のセンターの処理の流れを示すフローチャート
【図５】前提の形態２の端末の処理の流れを示すフローチャート
【図６】本発明の実施の形態１の端末の処理の流れを示すフローチャート
【図７】従来の取引処理システムの概略構成を示すブロック図
【符号の説明】
１００ 端末
１０１ 制御部
１０２ 通信部
１０３ 入力部
１０４ 取引情報格納部
１０５ 表示部
１０６ センター状況記憶部
１０７ 計時部
１０８ 計数部
１１０ センターコンピュータ
１２０ データベース
１３０ 回線網
１４０ 店舗
１５０ センター
【発明の属する技術分野】
本発明は取引処理システムに関するものである。
【０００２】
【従来の技術】
決済処理に使用される端末はネットワークを介してセンターとオンラインで接続され、取引の都度端末を操作してセンターへ情報を送信し、センターではその取引の許可／不許可を判断してその結果を端末に応答し、端末はその応答結果に応じて次の処理を行うものが知られている（例えば、特許文献１参照）。
【０００３】
図７に示すように一般的な取引システムは、店舗１４０に設置され決済を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００を接続する回線網１３０とから構成される。なお、センターコンピュータ１１０とデータベース１２０からセンター１５０が構成される。
【０００４】
操作者は、物品あるいはサービスの提供に応じて店舗に設置されている端末１００を操作して売上等の情報をセンター１５０へ送信し、センター１５０からの情報を受信して物品あるいはサービスを提供する。
【０００５】
【特許文献１】
特開２００２−１１７３５１号公報（第２−６頁、図１、図２）
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来の取引システムでは、センターコンピュータ１１０やデータベース１２０からなるセンター１５０に障害が発生した場合、センター１５０は端末１００からの取引要求を正常に処理することができず拒否報告を端末１００に返す。そのため、端末１００もその取引を正常に処理することができず、その結果として取引は異常終了する。ここで、端末１００の操作者は、取引が異常終了したため再度同じ処理操作を試みるか、センター１５０に問合せを行う等の非定常作業をする必要がでてくる。また、取引が異常終了したことにより、売上機会の損失や売上を処理するための手作業の事務手続きを行わなければならないという問題が生じる。
【０００７】
本発明は、上記従来の課題に鑑み、センター１５０に何らかの障害が発生した場合でも、取引を継続して処理できる取引システムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記課題を解決するために本発明は、センターとの相互通信を行う通信部と、取引情報を格納する格納部と、日時を計測する計時部と、前記センターからの情報を処理する制御部と、取引件数を記録するカウンタと、以前の取引において前記センターから異常を生じている旨の異常情報を受け取った場合に異常発生中であることを示すフラグを記憶するためのセンター状況記憶部と、を備え、前記制御部は、今回の取引要求を送信するときに、前記フラグによってセンターにおいて異常発生中と認識した場合、前記異常が発生した以降の取引件数が規定値を越えるまでは前記センターへ取引要求を送信することなく上記取引情報を処理して前記格納部に格納し、さらに前記センターの異常が回復した後にこれをセンターに送信するとともに、前記取引件数が規定値を越えた場合及び前記制御部が前記計時部の計時結果に基づいて前記センターから前記異常情報を受け取った以降に日付が変わったと判断した場合、前記センターへ今回の取引要求を送信し、前記センターからの応答が前記異常情報以外の場合には前記フラグをクリアして正常処理を行い、該応答が前記異常情報であった場合は該フラグを異常発生中にし、上記取引情報を処理して前記格納部に格納し、前記センターの異常が回復した後に送信するように構成した。
【００１１】
【発明の実施の形態】
（前提の形態１）
以下、前提の形態１について、図１から図４を用いて説明する。
【００１２】
図１は、取引処理システムの概略構成を示すブロック図であり、この取引処理システムは、店舗１４０に設置されて取引処理を行う端末１００と、端末１００から送信されてくる取引情報を処理するセンターコンピュータ１１０と、センターコンピュータ１１０に接続され取引情報や顧客情報等を蓄えるデータベース１２０と、センターコンピュータ１１０と端末１００とを接続する回線網１３０から構成されている。なお、センターコンピュータ１１０とデータベース１２０とからセンター１５０が構成されている。
【００１３】
また、図２は、端末１００の概略構成を示すブロック図であり、端末１００は、センター１５０からの情報を処理する制御部１０１と、センター１５０との通信を行う通信部１０２と、金額等の情報を入力する入力部１０３と、取引情報を格納する取引情報格納部１０４と、取引の状況を表示する表示部１０５と、センター１５０が異常状態であるか否かの状況を意味する情報を記憶するセンター状況記憶部１０６と、日時を計測する計時部１０７と、前記センターが障害中であり前記センターへ取引要求を送信することなく取引情報を処理した回数をカウントするカウンタ１０８を備えている。
【００１４】
そして、図３は、前提の形態１における端末１００が行う取引処理の流れを示すフローチャートである。
【００１５】
物品の購買やサービスの提供の発生に伴い店員は端末１００を操作してこの取引の処理を行う。以下その流れについて図３を用いて説明する。
【００１６】
ステップＳ１０１において、店員は取引業務の内容を選択する。次に、ステップＳ１０２において、取引処理に必要なカード情報や金額等のデータを入力する。次に、端末１００はステップＳ１０３において、センター１５０に送信する取引電文を作成し、ステップＳ１０４においてセンター１５０へ送信する。
【００１７】
次に、この端末１００から送信されてきた情報の処理を行うセンター１５０の処理について図４を用いて説明する。図４はセンター１５０の処理の流れを示すフローチャートである。
【００１８】
センター１５０を構成するセンターコンピュータ１１０は、ステップＳ３０１において端末１００から送信された取引要求電文を受信する。次に、ステップＳ３０２においてセンター１５０の状態に異常が有るか否かを判断する。そしてその判断に基づいて次に行うステップが決まる。例えば、取引情報等を格納するデータベース１２０に障害が発生している場合にはセンター１５０に障害が発生しているとしてステップＳ３０４の処理に移行し、このステップＳ３０４において端末１００へ送る応答電文にセンター１５０が障害であることを示す特定のエラーコードをセットし、ステップＳ３０５においてエラーコードを含む応答電文を端末１００へ送信する。
【００１９】
ここで、図３に戻り、端末１００の処理について説明する。
【００２０】
端末１００はステップＳ１０５においてセンター１５０から送信された取引の応答電文を受信し、ステップＳ１０６においてこの応答電文に含まれる応答コードを確認し、この応答コードがセンター１５０が障害中であることを意味する特定の応答コードであった場合、ステップＳ１０７においてセンター１５０が障害中である旨の表示を表示部１０５に表示し、この取引を継続して処理するか否かの判断を端末操作者に要求する。端末操作者はこの取引を継続して処理するか中止するかを判断して端末１００に入力する。取引継続が指示されると端末１００はステップＳ１１０においてこの取引情報を端末１００内の取引情報格納部１１２に格納し、ステップＳ１１１においてこの取引を正常と判断して処理を終了する。
【００２１】
なお、端末１００は取引情報格納部１１２に格納されている情報をセンター１５０に一括して送信する取引情報一括送信機能を有しており、センター障害中に端末１００内に格納された取引情報は、センター１５０が障害から復旧した後に、取引情報一括送信機能を用いて端末１００からセンター１５０へ送信される。
【００２２】
また、取引を継続しないことが指示された場合はステップＳ１１２に移行し、異常処理であるとして異常である旨の伝票を出力部（図示せず）から出力して処理を終了する。
【００２３】
以上のように前提の形態１の取引処理システムは、センター１５０に何らかの障害が発生した場合、センター１５０を構成するセンターコンピュータ１１０は端末１００からの取引要求に対して特定のエラーコードを有した応答を返却する機能を備え、端末１００はセンター１５０からの応答が特定のエラーコードであればセンター１５０が障害中であると認識する機能を備え、この端末１００はセンター１５０が障害中の取引情報を取引情報格納部１１２に格納し、センター１５０の障害が復旧した後に取引情報格納部１１２に格納されている情報をセンター１５０に送信するようにしたことで、センター１５０の障害に起因する売上機会の損失や売上を処理するための手作業の事務手続きを削減することができる。
【００２４】
なお、センター１５０を構成するセンターコンピュータ１１０が異常を生じている場合は、センター１５０から端末１００に特定のエラーコードを送信することができないので、端末１００は取引情報を取引情報格納部１１２に格納することはせず、異常処理として終了する。すなわち、本実施の形態は、センターコンピュータ１１０は正常であり、このセンターコンピュータ１１０以外のセンター１５０の構成要素に異常が生じた場合を想定している。
【００２５】
（前提の形態２）
次に、取引システムの前提の形態２について、図１と図２と図５を用いて説明する。図５は、端末１００が行う取引処理の流れを示すフローチャートである。
【００２６】
前提の形態２において、前提の形態１と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。前提の形態１と異なる点は２点有り、以下にそれを示す。
【００２７】
１点目は、一つ前の取引処理の時にセンター１５０が障害中であったか否かを示すフラグを記憶するセンター状況記憶部１０６を端末１００内に設け、電文編集処理（Ｓ１０３）後に、このフラグが障害中であったことを示す「１」であるか、障害中でなかったことを示す「０」であるかを端末１００内の制御部１０１）で確認し（Ｓ２０１）、障害中であったことを示す「１」の場合はセンター１５０への取引電文送信（Ｓ１０４）のステップに移行せず、直ちにセンター障害中表示（Ｓ１０９）のステップに移行する。すなわち、センター１５０が障害中はセンター１５０への電文の送信を行わないようにしたものである。
【００２８】
２点目は、ステップＳ２０１でフラグが障害中でなかったことを示す「０」であった場合の処理で、ステップＳ１０５、ステップＳ１０６の処理を行い、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードであった場合、フラグをセンター１５０が障害中であることを示す「１」に変更するステップ（Ｓ２０２）を設けた点である。
【００２９】
以上のように、本前提の形態２では、端末１００内にセンター１５０が障害中であるか否かを判断するためのフラグを記憶するセンター状況記憶部１０６を設け、ステップＳ２０１においてセンター１５０の障害を確認するものとした。そして、センター１５０が障害中であることを示すフラグは、端末１００がセンター１５０が障害中であることを示す応答電文を受信した後に設定される（ステップＳ２０２）。
【００３０】
そして、ステップＳ２０１で示すように、センター１５０が障害中である旨のフラグが設定されている場合、端末１００はセンター１５０が障害中であると判断し、直ちにステップＳ１０７以降の処理に移行する。すなわち、センター１５０が障害中は、端末１００はセンター１５０へ電文送信することなく取引処理をすすめる。
【００３１】
（実施の形態１）
次に本発明の取引システムの実施の形態について、図１と図２と図６を用いて説明する。図６は本実施の形態における、端末１００が行う取引処理の流れを示すフローチャートである。
【００３２】
本実施の形態において、前提の形態２と同様の構成や同様の処理については同一の符号を付して詳細な説明を省略する。前提の形態２と異なる点は３点有り、以下にそれを示す。
【００３３】
１点目は、ステップＳ２０１において、前回取引時にセンター１５０に障害が有りフラグが「１」である場合であっても、センター１５０の障害中に行われた取引の回数が規定の回数を超えた場合（Ｓ３０１）、あるいは障害発生時から日付が変わった場合（Ｓ３０２）には、端末１００からセンター１５０へ取引電文を送信（Ｓ１０４）するようにした点である。なお、日付が変わったか否かは、制御部１０１が計時部１０７の計時結果に基づいて判断する。
【００３４】
２点目は、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定のエラーコードでなかった場合、フラグをセンター１５０が障害中でないことを示す「０」に変更するステップ（Ｓ２０３）を設けた点である。
【００３５】
３点目は、端末１００にはセンター１５０の障害中に行われた取引の回数をカウントするカウンタ１０８が設けられており、このカウンタ１０８の数値を変更するステップとして、取引をオフラインで正常処理（Ｓ１１１）した後、カウンタ１０８の数値を１つ増やすステップ（Ｓ３０３）と、ステップＳ１０６においてセンター１５０から受信した応答コードがセンター１５０が障害中であることを示す特定の応答コードでなかった場合、カウンタの数字を「０」にするステップ（Ｓ３０４）を設けている。
【００３６】
本実施の形態では前提の形態２と同様に、センター１５０が障害中であるか否かを示すフラグを用いて、センター１５０の障害中には端末１００は取引電文をセンター１５０へ送信せずに処理するが、リスク軽減のため、所定の条件を満たす場合はたとえ前回取引時にセンター１５０が障害中であったとしてもセンター１５０へ取引電文を送信する。すなわち、センター１５０の障害中に端末１００内に格納される取引件数が規定回数を超えた場合、または、前回の障害発生から今回取引を行う場合に日付が変わっていれば、端末１００からセンター１５０に取引電文を送るようにしている。
【００３７】
これにより、センター１５０へ送信されずに処理されて端末１００に格納される取引件数が無闇に増大することを防止することができる。
【００３８】
具体的には、ステップＳ２０１でセンター１５０が障害中であると判断した後に、ステップＳ３０１にてセンター１５０の障害中に処理した取引件数を示すカウンタの値を確認し、規定値を超えている場合にはステップＳ１０４の取引電文送信に移行して取引電文がセンター１５０に送信される。また、ステップＳ３０２では、端末装置１００はセンター１５０が障害中となった日から日付が変わったか否かを確認し、日付が変わっていればステップＳ１０４の取引電文送信へ移行して取引電文がセンター１５０に送信される。
【００３９】
また、ステップＳ２０３においては、センター１５０が障害中であることを示すフラグは、センター１５０からの応答コードが正常またはセンターが障害中であることを示す特定コード以外のコードであった場合にクリアされる。
【００４０】
また、ステップＳ３０３においては、センター１５０の障害中に取引を処理する毎にカウンタの数を増加させる処理を行う。
【００４１】
以上のように、たとえ前回取引時にセンター１５０が障害中であったとしても、一定取引回数毎または日付が変わった場合にセンター１５０へ取引電文を送信することでリスクを軽減することができる。
【００４２】
なお、日付が変わると障害が復旧されている可能性が高いので、日付が変わった場合にセンター１５０へ取引電文を送信するようにすることは有効である。
【００４３】
【発明の効果】
以上のように本発明によると、端末と回線網とセンターから構成される取引システムにおいて、センター側が障害等で取引を正常に処理できない場合に端末内に取引情報を格納してその取引を正常に処理し、センターが復旧した後に格納されている取引情報をセンターに送信することにより、売上機会の損失あるいは売上を処理するための手作業の事務手続き発生を削減する効果を奏する。
【図面の簡単な説明】
【図１】前提の形態１の取引処理システムの概略構成を示すブロック図
【図２】前提の形態１の情報端末の概略構成を示すブロック図
【図３】前提の形態１の端末の処理の流れを示すフローチャート
【図４】前提の形態１のセンターの処理の流れを示すフローチャート
【図５】前提の形態２の端末の処理の流れを示すフローチャート
【図６】本発明の実施の形態１の端末の処理の流れを示すフローチャート
【図７】従来の取引処理システムの概略構成を示すブロック図
【符号の説明】
１００ 端末
１０１ 制御部
１０２ 通信部
１０３ 入力部
１０４ 取引情報格納部
１０５ 表示部
１０６ センター状況記憶部
１０７ 計時部
１０８ 計数部
１１０ センターコンピュータ
１２０ データベース
１３０ 回線網
１４０ 店舗
１５０ センター
Claims (2)
- センターとの相互通信を行う通信部と、取引情報を格納する格納部と、日時を計測する計時部と、前記センターからの情報を処理する制御部と、取引件数を記録するカウンタと、以前の取引において前記センターから異常を生じている旨の異常情報を受け取った場合に異常発生中であることを示すフラグを記憶するためのセンター状況記憶部と、を備え、
前記制御部は、今回の取引要求を送信するときに、前記フラグによってセンターにおいて異常発生中と認識した場合、前記異常が発生した以降の取引件数が規定値を越えるまでは前記センターへ取引要求を送信することなく上記取引情報を処理して前記格納部に格納し、さらに前記センターの異常が回復した後にこれをセンターに送信するとともに、前記取引件数が規定値を越えた場合及び前記制御部が前記計時部の計時結果に基づいて前記センターから前記異常情報を受け取った以降に日付が変わったと判断した場合、前記センターへ今回の取引要求を送信し、前記センターからの応答が前記異常情報以外の場合には前記フラグをクリアして正常処理を行い、該応答が前記異常情報であった場合は該フラグを異常発生中にし、上記取引情報を処理して前記格納部に格納し、前記センターの異常が回復した後に送信することを特徴とする情報端末。 - 情報端末と、当該情報端末から送信されてきた情報を処理した後に当該情報を蓄積するデータベースを有しかつ前記情報端末と情報の送受信を行うセンターと、を備えた取引処理システムであって、
前記情報端末において、
前記センターとの相互通信を行う通信部と、取引情報を格納する格納部と、日時を計測する計時部と、前記センターからの情報を処理する制御部と、取引件数を記録するカウンタと、以前の取引において前記センターから異常を生じている旨の異常情報を受け取った場合に異常発生中であることを示すフラグを記憶するためのセンター状況記憶部と、を備え、
前記制御部は、今回の取引要求を送信するときに、前記フラグによってセンターにおいて異常発生中と認識した場合、前記異常が発生した以降の取引件数が規定値を越えるまでは前記センターへ取引要求を送信することなく上記取引情報を処理して前記格納部に格納し、さらに前記センターの異常が回復した後にこれをセンターに送信するとともに、前記取引件数が規定値を越えた場合及び前記制御部が前記計時部の計時結果に基づいて前記センターから前記異常情報を受け取った以降に日付が変わったと判断した場合、前記センターへ今回の取引要求を送信し、前記センターからの応答が前記異常情報以外の場合には前記フラグをクリアして正常処理を行い、該応答が前記異常情報であった場合は該フラグを異常発生中にし、上記取引情報を処理して前記格納部に格納し、前記センターの異常が回復した後に送信することを特徴とする取引処理システム。
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 JP2004295614A (ja) | 2004-10-21 |
| JP4100217B2 true 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 (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103268678A (zh) * | 2013-05-09 | 2013-08-28 | 雅酷时空科技开发（北京）有限公司 | 一种pos终端、服务器及处理发卡行识别码冲突的方法 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6023597B2 (ja) * | 2013-01-25 | 2016-11-09 | 日立オムロンターミナルソリューションズ株式会社 | 現金処理システム及び方法 |
| US11695853B1 (en) * | 2022-04-07 | 2023-07-04 | T-Mobile Usa, Inc. | Content management systems providing zero recovery point objective |
-
2003
- 2003-03-27 JP JP2003088440A patent/JP4100217B2/ja not_active Expired - Lifetime
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103268678A (zh) * | 2013-05-09 | 2013-08-28 | 雅酷时空科技开发（北京）有限公司 | 一种pos终端、服务器及处理发卡行识别码冲突的方法 |
| CN103268678B (zh) * | 2013-05-09 | 2016-02-24 | 雅酷时空科技开发（北京）有限公司 | 一种pos终端、服务器及处理发卡行识别码冲突的方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004295614A (ja) | 2004-10-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11514519B1 (en) | System and methods for credit dispute processing, resolution, and reporting | |
| KR101756594B1 (ko) | 대행 승인을 통한 금융 거래 승인 무중단 서비스 제공 방법 및 이를 수행하는 카드사 서버 | |
| US10282709B2 (en) | Processor issuer detection and user level stand-in authorization | |
| US20130317975A1 (en) | Systems and methods for interfacing merchants with third-party service providers | |
| CN108133425A (zh) | 理赔方法、装置及计算机可读存储介质 | |
| JP4100217B2 (ja) | 取引処理システムおよび情報端末 | |
| JPH0419586B2 (ja) | ||
| CN112990871A (zh) | 一种单据处理方法及相关设备 | |
| KR101165250B1 (ko) | 신용 결제 시스템에서 통신 장애를 알리는 방법 및 장치와 그 시스템 | |
| JP3976461B2 (ja) | 商品管理システムにおける携帯型無線端末の故障監視方法及び該方法の実施プログラムを記録した記憶媒体 | |
| JP5979719B2 (ja) | Ａｔｍシステム及び方法 | |
| JP2007122099A (ja) | 取引決済装置および取引管理システム | |
| JPS6367703B2 (ja) | ||
| JP4593310B2 (ja) | 注文データ管理システムおよびデータ制御装置 | |
| JPH04147397A (ja) | クレジット取引処理システムおよび端末装置 | |
| JPH06195571A (ja) | 商品販売データ処理装置 | |
| US20220084002A1 (en) | Sales data processing device, sales data processing method and recording medium | |
| US11526394B2 (en) | Method of controlling information processor, non-transitory controller-readable medium storing program, and communication system | |
| JPS5936300B2 (ja) | 商品販売デ−タ処理システム | |
| KR102599647B1 (ko) | 카드 결제 방법, 카드 결제 시스템 및 카드 결제 방법을 실행시키도록 기록매체에 저장된 컴퓨터 프로그램 | |
| JP7225911B2 (ja) | 電子レシート管理装置、電子レシート管理方法、およびプログラム | |
| JPH1196228A (ja) | 情報表示システム | |
| JP3628159B2 (ja) | 取引システムの取引データ処理方法及び取引システム | |
| JPS6249560A (ja) | デ−タ送信方式 | |
| JPH03219389A (ja) | 現金自動取引装置監視システム |
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 |