IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

7114462ローカル取引認可のためのネットワークブリッジ
<図1>
  • -ローカル取引認可のためのネットワークブリッジ 図1
  • -ローカル取引認可のためのネットワークブリッジ 図2
  • -ローカル取引認可のためのネットワークブリッジ 図3
  • -ローカル取引認可のためのネットワークブリッジ 図4
  • -ローカル取引認可のためのネットワークブリッジ 図5
  • -ローカル取引認可のためのネットワークブリッジ 図6
  • -ローカル取引認可のためのネットワークブリッジ 図7
  • -ローカル取引認可のためのネットワークブリッジ 図8
  • -ローカル取引認可のためのネットワークブリッジ 図9
  • -ローカル取引認可のためのネットワークブリッジ 図10
  • -ローカル取引認可のためのネットワークブリッジ 図11
  • -ローカル取引認可のためのネットワークブリッジ 図12
  • -ローカル取引認可のためのネットワークブリッジ 図13
  • -ローカル取引認可のためのネットワークブリッジ 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-07-29
(45)【発行日】2022-08-08
(54)【発明の名称】ローカル取引認可のためのネットワークブリッジ
(51)【国際特許分類】
   G06Q 20/20 20120101AFI20220801BHJP
   G07G 1/14 20060101ALI20220801BHJP
   H04L 67/00 20220101ALI20220801BHJP
【FI】
G06Q20/20
G07G1/14
H04L67/00
【請求項の数】 7
(21)【出願番号】P 2018526193
(86)(22)【出願日】2016-11-14
(65)【公表番号】
(43)【公表日】2018-12-20
(86)【国際出願番号】 US2016061930
(87)【国際公開番号】W WO2017087335
(87)【国際公開日】2017-05-26
【審査請求日】2018-07-18
【審判番号】
【審判請求日】2020-06-25
(31)【優先権主張番号】14/944,319
(32)【優先日】2015-11-18
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】505161378
【氏名又は名称】イー2インタラクティブ,インコーポレーテッド・ディー/ビー/エー・イー2インタラクティブ,インコーポレーテッド
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100103034
【弁理士】
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100179062
【弁理士】
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100199565
【弁理士】
【氏名又は名称】飯野 茂
(74)【代理人】
【識別番号】100153051
【弁理士】
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100162570
【弁理士】
【氏名又は名称】金子 早苗
(72)【発明者】
【氏名】オロック、アンドリュー
(72)【発明者】
【氏名】ビエレー、デイビッド
【合議体】
【審判長】渡邊 聡
【審判官】高瀬 勤
【審判官】中野 浩昌
(56)【参考文献】
【文献】特開2014-116712(JP,A)
【文献】特表2002-517957(JP,A)
【文献】特開2006-330891(JP,A)
【文献】特開2010-026811(JP,A)
【文献】特開2008-065408(JP,A)
【文献】特開昭63-039099(JP,A)
【文献】国際公開第2000/046659(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q10/00-99/00
H04L67/00-67/75
G07G1/00-1/14
(57)【特許請求の範囲】
【請求項1】
記憶値カード取引をローカルに処理する装置において、
前記装置は、小売ポイントオブセール(POS)またはホストに近接し、
前記装置は、前記POSまたはホストおよび記憶値カードプロセッサと選択的に通信し、
前記装置は、
前記POSまたはホストとの選択的な通信を可能にするPOSまたはホストインターフェースと、
前記記憶値カードプロセッサとの選択的な通信を可能にする記憶値カードプロセッサインターフェースと、
憶値カードのアクティブ化要求に対する選択的な承認を可能にする処理モジュールとを具備し、
前記POSまたはホストと前記記憶値カードプロセッサとの通信がタイムアウトしない場合には、前記処理モジュールは、憶値カードのアクティブ化要求に対する承認を行わずに、このような要求を前記記憶値カードプロセッサに通過させ、
前記POSまたはホストと前記記憶値カードプロセッサとの通信がタイムアウトした場合には、前記処理モジュールは、憶値カードのアクティブ化要求に対する承認をローカルに行装置。
【請求項2】
前記処理モジュールと前記記憶値カードプロセッサとの間の通信がいったん再確立されると、前記処理モジュールは、前記装置によってローカルに行われたアクティブ化要求の承認により、前記記憶値カードプロセッサに関係付けられているメモリ中に記憶されているデータを更新する請求項1記載の装置。
【請求項3】
前記POSまたはホストと前記記憶値カードプロセッサとの通信がタイムアウトしない場合には、前記処理モジュールは、前記記憶値カードプロセッサから受信した応答に基づいて、前記記憶値カードプロセッサの承認をローカルに上書きする請求項1記載の装置。
【請求項4】
記憶値カードタイプまたは額面金額、取引タイプ、ならびに/あるいは、取引額が、上書きに対して適格であるとして記憶される場合、前記記憶値カードプロセッサは、前記記憶値カードプロセッサの承認をローカルに上書きするだけである請求項3記載の装置。
【請求項5】
いったん前記処理モジュールと前記記憶値カードプロセッサとの間の通信が再確立されると、前記装置によってローカルに行われたアクティブ化要求の承認により、前記記憶値カードプロセッサに関係付けられているメモリ中に記憶されているデータを更新する記憶および転送モジュールをさらに具備する請求項1記載の装置。
【請求項6】
冗長記憶を提供するために、コンテンツ複製アプリケーションと通信する少なくとも2つのデータベースをさらに具備する請求項1記載の装置。
【請求項7】
前記装置は、1つ以上のロードバランサまたはマルチプレクサを通して、前記POSまたはホストと通信する請求項1記載の装置。
【発明の詳細な説明】
【背景】
【0001】
[001]
アクティブ化、非アクティブ化、兌換、リロード、および、リフレッシュに限定されないが、これらのような記憶値カード取引は、取引に対する認可を取得するために、および/または、取引を行うために、遠隔プロセッサまたはサーバと通信するための、小売ポイントオブセール(POS)端末、システム、または、ホストを典型的に必要とする。しかしながら、ある状況では、遠隔プロセッサとの通信は、(例えば、停電またはネットワーク停止の間)可能でないかもしれない、または、(例えば、ピーク時間またはネットワーク過負荷の間)タイムリーでないかもしれない。
【0002】
[002]
したがって、記憶値カード取引をローカルに認可するおよび/または行う、システムおよび方法を提供することが望ましい。可能なときに、遠隔プロセッサと通信して、新たな取引情報により、プロセッサと任意の関係付けられているデータストアとを更新できる、このようなシステムおよび方法を提供することがさらに望ましい。このようなシステムおよび方法は、取引および取引要求のより速い処理を可能にするかもしれない。
【0003】
[003]
さまざまな記憶値カードシステムは、非常に特定の状況で利用されるかもしれない、ある程度のローカル認可を提示するかもしれない。しかしながら、このようなシステムは、(i)タイムアウトの際に、ある取引タイプを取り消しすることを継続する一方で、指定された取引タイプに対する代理承認機構も追加し、(ii)報告されるときに、ある「ソフト拒否」に対する代理能力を提供し、(iii)記憶および転送(SAF)取引から出るアウトバウンド要求上に一意的なシステムトレースオーディットナンバー(STAN)を提供することのような、特定の要件を実現し、および/または、(iv)動作および管理レベルの見落しに対するSAFコンテンツへの可視性を取得する、能力を提供しない。一般的に、「ソフト拒否」は、記憶値カードプロセッサは取引を拒否するかもしれないが、発行者またはプロセッサ(すなわち、製品および/または取引に対する実際の認可者)が取引を拒否していないかもしれないことであることに留意すべきである。
【0004】
[004]
したがって、本発明のいくつかの実施形態にしたがう、システムおよび方法のこのような目的が望ましい。
【発明の概要】
【0005】
[005]
本発明のいくつかの実施形態にしたがうと、態様は、記憶値カード取引をローカルに処理する装置を含んでいてもよく、装置は、小売ポイントオブセール(POS)またはホストに近接し、装置は、POSまたはホストおよび記憶値カードプロセッサと選択的に通信し、装置は、POSまたはホストとの選択的な通信を可能にするPOSまたはホストインターフェースと、記憶値カードプロセッサとの選択的な通信を可能にする記憶値カードプロセッサインターフェースと、ある記憶値カード取引要求に対する選択的な決定を可能にする処理モジュールとを具備する。
【0006】
[006]
本発明のいくつかの実施形態にしたがうと、他の態様は、記憶値カード取引をローカルに認可する方法を含んでいてもよく、方法は、小売ポイントオブセール(POS)またはホスト、ブリッジプロセッサ、および、記憶値カードプロセッサ間で行われ、ブリッジプロセッサは、POSまたはホストとともにローカルに配置され、方法は、ブリッジプロセッサにおいて、取引要求を受信することと、ブリッジプロセッサによって、取引要求を、記憶値カードプロセッサに通過させるべきであるか否か、または、ローカルに決定させるべきであるか否かを決定することと、取引要求を記憶値カードプロセッサに通過させるべきであると決定すると、このような要求をブリッジから記憶値カードプロセッサに通信することと、記憶値カードプロセッサから、または、記憶値カードプロセッサとの試行した通信から、ある応答を受信すると、ブリッジプロセッサによって、記憶値カードプロセッサの応答をローカルに上書きするか、または、取引要求をローカルに決定することと、取引要求を記憶値カードプロセッサに通過させるべきでないと決定すると、ブリッジプロセッサによって、取引要求をローカルに決定することと、ブリッジプロセッサによって、取引要求応答をPOSまたはホストへと返通信することとを含む。
【0007】
[007]
本発明のいくつかの実施形態にしたがう他の態様は、記憶値カード取引をローカルに処理する装置を含んでいてもよく、装置は、小売ポイントオブセール(POS)またはホストに近接し、装置は、POSまたはホストおよび記憶値カードプロセッサと選択的に通信し、装置は、取引要求を受信し、取引要求を記憶値カードプロセッサに通過させるべきであるか否か、または、ローカルに決定させるべきであるか否かを決定し、取引要求を記憶値カードプロセッサに通過させるべきであると決定すると、このような要求を記憶値カードプロセッサに通信し、記憶値カードプロセッサから、または、記憶値カードプロセッサとの試行した通信から、ある応答を受信すると、記憶値カードプロセッサの応答をローカルに上書きするか、または、取引要求をローカルに決定し、取引要求を記憶値カードプロセッサに通過させるべきでないと決定すると、ブリッジプロセッサによって、取引要求をローカルに決定し、ブリッジプロセッサによって、取引要求応答をPOSまたはホストへと返通信する。
【0008】
[008]
本発明の新規概念の範囲から逸脱することなく、バリエーションおよび修正がもたらされるかもしれないが、以下の図とともに本発明の以下の記述から、これらおよび他の態様が明らかになるだろう。
【図面の簡単な説明】
【0009】
[009]
本発明は、添付の図とともに以下の詳細な説明を読むことにより、さらに完全に理解することができ、図面において、同様の参照インジケータは、同様の要素を表すように使用している。添付の図は、ある例示的な実施形態を描写し、以下の詳細な説明を理解することを助けるかもしれない。本発明の任意の実施形態を詳細に説明する前に、本発明は、以下の記述で述べるまたは図において図示する、構成の詳細およびコンポーネントのアレンジメントにそのアプリケーションが限定されないと理解すべきである。描写した実施形態は、例示として理解すべきであり、本発明の全体的な範囲を決して限定しない。ここで使用する表現および専門用語は記述の目的のためであり、限定として考えるべきではないとも理解すべきである。詳細な説明では、以下の図を参照するだろう。
図1】[0010] 図1は、本発明のいくつかの実施形態にしたがった、限定された処理機能性を有する例示的な記憶および転送(SAF)モデルを図示している。
図2】[0011] 図2は、本発明のいくつかの実施形態にしたがった、完全な処理機能性を有する例示的なSAFモデルを図示している。
図3】[0012] 図3は、本発明のいくつかの実施形態にしたがった、ポール通過動作に対する例示的なフローダイヤグラムを図示している。
図4】[0013] 図4は、本発明のいくつかの実施形態にしたがった、代理承認による、SAF影響のない、ソフト拒否を取り扱うための例示的なプロセスを明記している。
図5】[0014] 図5は、本発明のいくつかの実施形態にしたがった、代理承認によるソフト拒否とSAFハード拒否とを取り扱うための例示的なプロセスを図示している。
図6】[0015] 図6は、本発明のいくつかの実施形態にしたがった、取引がリトライの最大数に達するとき、代理承認によるソフト拒否を取り扱うための例示的なプロセスを図示している。
図7】[0016] 図7は、本発明のいくつかの実施形態にしたがった、代理承認によるホストタイムアウトに対する例示的なプロセスを描いている。
図8】[0017] 図8は、本発明のいくつかの実施形態にしたがった、代理承認によるホストタイムアウトに対する例示的なプロセスを図示している。
図9】[0018] 図9は、本発明のいくつかの実施形態にしたがった、中止モードに対する例示的なプロセスを描いている。
図10】[0019] 図10は、本発明のいくつかの実施形態にしたがった、発起者ベースの無効および取消に対する例示的な処理を図示している。
図11】[0020] 図11は、本発明のいくつかの実施形態にしたがった、ペンディングSAF取引に対する例示的な処理を図示している。
図12】[0021] 図12は、本発明のいくつかの実施形態にしたがった、SAF中の補充アイテムに対する例示的なプロセスを図示している。
図13】[0022] 図13は、本発明のいくつかの実施形態にしたがった、予期される範囲内にない、万国製品コード(UPC)を有する製品を取り扱うための例示的なプロセスを図示している。
図14】[0023] 図14は、本発明のいくつかの実施形態にしたがった、SAFシステムに対してアクティブではない、万国製品コードを有する製品を取り扱うための例示的なプロセスを図示している。
【詳細な説明】
【0010】
[0024]
本発明の任意の実施形態を詳細に説明する前に、本発明は、以下の記述で述べるまたは図において図示する、構成の詳細およびコンポーネントのアレンジメントにそのアプリケーションが限定されないと理解すべきである。本発明は、他の実施形態が可能であり、さまざまな方法で実施または実行することが可能である。ここで使用する表現および専門用語は記述の目的のためであり、限定として考えるべきではないとも理解すべきである。
【0011】
[0025]
この記述において例示する事項は、添付の図を参照して開示されるさまざまな例示的な実施形態の包括的な理解を支援するために提供されている。したがって、特許請求の範囲に記載されている発明の精神および範囲から逸脱することなく、ここで記述した例示的な実施形態のさまざまな変更および改良ができると、当業者であれば認識するだろう。明瞭さおよび簡潔さのために、既知の機能および構成の記述は省略した。さらに、ここで使用しているように、単数形は複数形で解釈してもよく、代わりに、複数形の任意の用語は単数形で解釈してもよい。
【0012】
[0026]
図1を参照すると、現在の方法論の下では、-例えば、記憶値カードプロセッサから応答を待っている間-小売のホストで金銭的な取引がタイムアウトする場合、タイムアウト取消(TOR)が発生され、SAFシステムに提供されるかもしれない。別の方法では、他の取引に対して、ホストは、記憶値カードプロセッサと直接通信する。継続して図1とプロセス10を参照すると、小売110は、記憶値カードプロセッサ120と直接通信するかもしれず、次に、記憶値カードプロセッサ120は、サービスプロバイダ130と通信するかもしれない。
【0013】
[0027]
サービスプロバイダ130は、記憶値カードを実際に発行するまたは兌換する当事者であってもよい。記憶値カードプロセッサ120は、複数の記憶値カードに関連するサービスを提供してもよい、中間者であってもよい。小売110は、ポイントオブセールロケーションを有する、典型的な小売または加盟店であってもよい。例えば、小売110は、複数の記憶値カードの販売を提供できる、Walgreensであってもよい。記憶値カードプロセッサ120は、Walgreensによって提供される複数の記憶値カードに関連する、アクティブ化、および、他のサービスを提供できる、Interactive Communications International, Inc.、すなわち、InCommであってもよい。サービスプロバイダ130は、Bed Bath & Beyondギフトカードに対するカード取引を取り扱うことができる、Stored Value Solutionsのような、カードの発行者に対してカード取引を取り扱うエンティティであってもよい。
【0014】
[0028]
たいていの取引の間、ホストは、取引要求141を記憶値カードプロセッサ120に伝え、記憶値カードプロセッサ120から応答142を受信するかもしれない、単なるパススルーとして動作するかもしれない。しかしながら、ある状況の間には、ホスト110と記憶値カードプロセッサ120との間で試行した通信において、タイムアウト143があるかもしれない。このような状況において、ホスト110は、タイムアウト取消144を発生させるかもしれず、これは、SAFキュー145に提供されるかもしれない。後の時間に、SAFシステムは、記憶値カードプロセッサ120と通信して、不適切または不完全に行われているかもしれない任意の取引を取り消しするかもしれない。このようなSAFシステムが非常に限られた能力を有していることが、図1から分かる。
【0015】
[0029]
本発明のいくつかのうちの実施形態にしたがうと、数ある中で、(i)(ポイントオブセールにおいてよりもむしろ、または、ポイントオブセールにおいてに加えて、)ホストレベルで代理承認を実現することと、(ii)特に識別された取引タイプのみを可能にすること(例えば、代理アクティブ化のみを許可すること)と、(iii)特に識別された製品または製品取引タイプの組み合わせを可能にすることと、(iv)「ソフト拒否」および/またはタイムアウトの間、ブリッジがSAFシステムと通信することを自動的に可能にすることと、(v)例えば、領収書上に印刷された、または、POSディスプレイ上で表示された、ブリッジ/SAFアクティビティの結果を店員または技術者に提供することと、のうちの1つ以上を提供してもよい、ブリッジが提供されてもよい。
【0016】
[0030]
ある取引は、ローカルに決定されてもよい一方で、他は、記憶値カードプロセッサからの応答を必要するかもしれないことから、このような機能性は、より速い、より効率的な処理を提供できる。さらに、非通信またはエラーの時間の間、このようなシステムおよび方法は、取引が、非効率なプロセッサに積み上がること、非効率なプロセッサに過負荷をかけることを防いでもよく、これにより、全体的により効率的に、迅速に、システムが実行できるようになる。
【0017】
[0031]
一般的に、本発明は、POSシステム/ホストと記憶値カードプロセッサとの間に配置されているブリッジに向けられている。ブリッジは1つ以上の機能を提供してもよい。例えば、記憶値カードプロセッサとの通信が効率的でタイムリーな場合、ブリッジは、記憶値カードプロセッサと通信するようにパススルーであってもよく、取引要求のルーティングを支援してもよい。記憶値カードプロセッサとの通信が可能でない、効率的でない、または、タイムリーでない場合、ブリッジは、代理プロセッサとして機能してもよく、ある取引を行ってもよい。いったん、記憶値カードプロセッサとの適切な通信が再開されると、ブリッジが代理として認可した、または、行った取引に関係付けられている更新された情報で、ブリッジは、記憶値カードプロセッサと任意の関係付けられているデータストアとを更新してもよい。
【0018】
[0032]
本発明のいくつかの実施形態にしたがうと、ブリッジは、POS/ホストと記憶値カードプロセッサとの中間にポジショニングしてもよい。例えば、ブリッジは、パススルー取引を受信して、ルーティングすることができる一方で、必要な代理取引に対する接続性も有して、POS/ホストロケーションに物理的に位置付けてもよい。
【0019】
[0033]
POS/ホストロケーションにブリッジをポジショニングすることは、追加の利益を提供する。ブリッジの目的は、ある記憶値カード取引に対して継続的なサービスを提供することであることから、POS/ホストのロケーションにブリッジをポジショニングすることは、確実にブリッジがPOS/ホストと同じ環境になるようにする。言い換えると、ブリッジがPOS/ホストから遠隔に位置付けられる場合、POS/ホストロケーションが通常通り実行しているかもしれない間に、ブリッジロケーションが停電またはネットワーク問題の対象であるかもしれないことが予見可能である。ブリッジの目的のうちの1つは、POS/ホストに対する継続的なサポートを提供することであることから、POS/ホストとともにブリッジを位置付けることは、確実に、環境要因が同じまたは類似するようになり、代理認可または取引を処理するためには、限られたネットワーク通信が要求されるに過ぎない。
【0020】
[0034]
本発明のいくつかにしたがうシステムおよび方法は、1つ以上のソリッドステートドライブを利用してもよい。ソリッドステートドライブは、例えば、Intel Xeon E5-2609プロセッサを利用しているかもしれない、例えばHP ProLiant DL380P G8 2Uを備えていてもよい。ソリッドステートドライブは、1つ以上のロードバランサを介して、および/または、マルチプレクサを介して、POS/ホストと直接通信してもよい。
【0021】
[0035]
一般的に、ブリッジは、記憶および転送(SAF)機能性を実現して、小売ロケーションにおける代理およびパススルー取引の両方を行ってもよい。本発明のいくつかの実施形態にしたがうと、ブリッジは、(i)タイムアウトの際に、ある取引タイプを取り消しすることを継続する一方で、指定された取引タイプに対して代理承認機構も追加し、(ii)報告されるときに、ある「ソフト拒否」に対する代理能力を提供し、(iii)記憶および転送(SAF)取引から出るアウトバウンド要求上に一意的なSTANを提供することのような、特定の要件を実現し、および/または、(iv)動作および管理レベルの見落しに対するSAFコンテンツへの可視性を取得する、能力を提供してもよい。
【0022】
[0036]
小売システムへの修正は、完全な機能性を提供するために、ブリッジに対して望まれ、推薦され、または必要とされるかもしれない。例えば、小売は、直接、記憶値カードプロセッサによりもむしろブリッジに、記憶値カード取引をルーティングするように、取引ルートの設定を修正するように要求されるかもしれない。同様に、小売は、代理承認および代理拒否に関係付けられている新たな応答コードをサポートするように、そのシステムを修正してもよい。このような応答コードは、SAFイベントを追跡および相関させ、ブリッジ決定する際に有用であるかもしれない。また、小売は、ある状況において、追加のポイントオブセールガイダンスを顧客に提供してもよい。例えば、購入した製品が代理承認を受信する場合、顧客には、製品が24時間でアクティブになるだろうと通知されてもよい。この情報は、(販売員から顧客に)口頭で行われてもよく、または、領収書上に印刷されてもよい。
【0023】
[0037]
図2を参照すると、本発明のいくつかの実施形態にしたがったブリッジを利用する、改善されたSAFモデル20が描かれている。一般的に、モデル20は、POS211および/またはホスト212を備えていてもよい顧客210の間で行われるような、さまざまな取引を図示している。(ここにおける「顧客」の使用は、記憶値カードプロセッサの顧客である加盟店または小売を指すように意図されていることに留意されたい。例えば、販売のために1つ以上の記憶値カードまたはギフトカードを提供する小売は、「顧客」であってもよい。)ホスト212を通した通信が一般的であるかもしれないが、ブリッジ220と直接通信するPOS211により、類似する取引が行われてもよいことが企図されている。顧客210は、通信をブリッジ220に送ってもよく、ブリッジ220は、次に、いくつかの取引を行うか、または、取引要求を記憶値カードプロセッサ230に通過させるかのいずれかをしてもよい。記憶値カードプロセッサ230は、サービスプロバイダ240と通信して、ある取引を可能にするか、行ってもよい。
【0024】
[0038]
図2は、顧客210、ブリッジ220、記憶値カードプロセッサ230、および、サービスプロバイダ240を通したフローを図示するために、いくつかの例示的な取引タイプを説明している。250において、POSにおいて取引が起き、ホスト212を通過し、ブリッジ220を通過し、記憶値カードプロセッサ230において受信される、パススルー取引が図示されている。記憶値カードプロセッサは、サービスプロバイダ240と通信してもよいが、記憶値カードプロセッサ230はまた、サービスプロバイダでもあってもよく、または、追加の通信なく取引を行うように認可されていてもよいことも企図されている。取引応答は、その後、ブリッジ220とホスト212を通して、POS211にルーティングバックされる。
【0025】
[0039]
251において、ホストがタイムアウトする(すなわち、記憶値カードプロセッサ230との通信が効率的にまたはタイムリーにできない)が、特定の製品タイプ(すなわち、ある記憶値カード)が「リトライ」リスト上にない状況に対する取引フローが示されている。この状況において、取引は、POS211において起き、ホスト212を通過しているかもしれないが、記憶値カードプロセッサ230には到着していないかもしれない。製品は、ブリッジ220によって取引されるように許容されないことから、タイムアウト取消(TOR)が252において発行され、これは、後の時間の記憶値カードプロセッサ230との通信のために、SAFキュー260に記憶されてもよい。
【0026】
[0040]
253において、ホストがタイムアウトするが、特定の製品タイプが「リトライ」リスト上にある状況に対する取引フローが示されている。ここで、取引は、POS211において起き、ホスト212を通って流れるが、記憶値カードプロセッサ230に到着していないかもしれない。しかしながら、製品タイプが「リトライ」リスト上にあることから、ブリッジ220は、254において、取引の代理承認を実行してもよい。この代理承認はまた、記憶値カードプロセッサ230との後の通信のために、SAFキュー260中に記憶されてもよい。
【0027】
[0041]
255において、「リトライ」リスト上にある製品タイプに対するソフト拒否に対する取引フローが示されている。再度説明すると、取引は、POS211において起き、ホスト212を通過する。ブリッジ220は、取引のために代理承認256を提供してもよく、SAFキュー260を再度更新してもよい。
【0028】
[0042]
257において、ローカルブリッジアクションを使用して行われることが認可されている取引に対する取引フローが示されている。ここで、取引は、POS211において起き、ホスト212を通って流れ、そして、ブリッジ220によって、認可され、承認され、または行われてもよい。再度説明すると、ブリッジ220は、更新を記憶値カードプロセッサ230に提供するために、任意の代理承認または拒否に関する情報をSAFキュー260に提供してもよい。
【0029】
[0043]
最終的に、上記に示したように、259において、SAFシステムは、ブリッジ220によって行われたまたは拒否された取引のリストまたはキューを提供することによって、記憶値カードプロセッサ230を更新してもよい。
【0030】
[0044]
顧客210が、ブリッジとともにこのようなSAFシステムを適切に利用するために、顧客は、そのシステムを修正するように知らされてもよい。このような修正は、(i)決定する際に現在のSAFキューコンテンツの有効性確認する、(ii)「ハード」拒否から「ソフト」拒否を見分ける、および/または、(iii)各SAF要求試行に関するフィールドを修正する、能力を提供することを含むがこれらに限定されない。
【0031】
[0045]
より具体的には、決定する際に現在のSAFキューコンテンツの有効性確認をするために、SAF決定は、SAFキューの特定の現在のコンテンツによってガイドされてもよい。例えば、同じ記憶値カードに対するアクティブ化要求が既にSAFキュー中に存在しているのに、アクティブ化要求が受信される(または、同様に、リロード要求が受信される)場合、引き続いてのまたは後続する取引はローカルに拒否されるべきである。
【0032】
[0046]
「ハード」拒否から「ソフト」拒否を見分けることに関して、「ソフト」拒否は、ブリッジによって行われる潜在的な代理取引に対する候補であってもよい一方で、「ハード」拒否は、そうではないかもしれない。各SAF要求試行に関するフィールドは、同じシステムトレースオーディットナンバー(STAN)の繰り返しのまたは重複の使用を防ぐために修正してもよい。同じSTANを使用することは、記憶値カードプロセッサが以前と同じ応答を自動的に繰り返すことをトリガするかもしれない。したがって、各取引要求に対するSTANを修正することが-特にソフト拒否のケースにおいて-望ましいかもしれない。
【0033】
ホスト統合
[0047]
ブリッジ自体が必要でなくてもよいように、ブリッジの取引能力がホストに統合されてもよいことが企図される。しかしながら、このような統合を妨げるまたは遅延させる要因があることが多いことから、ブリッジの使用は、顧客のホストへのコストおよび時間がかかる修正なく、ローカル代理取引能力を取得するための便利な方法を提供できる。
【0034】
コンフィギュレーション
[0048]
ブリッジと通信するためのホストを構成するために、いくつかのコンフィギュレーションファイルが有用または必要であるかもしれない。例えば、「QueryHost」取引参加者は、どのようにブリッジが認可者に接続するか、どのようにブリッジが応答または応答の欠如を取り扱うべきかを規定し、制御してもよい。「QueryHost」参加者は、(リアルタイム要求を取り扱うことができる)メイン取引マネージャーと、(コンフィギュレーション決定の結果としてSAFキュー中に入るアイテムの後続するアンロードを取り扱うことができる)SAF取引マネージャーの両方によって呼び出されてもよい。
【0035】
[0049]
以下の例において、ならびに、ここで提示するすべての例示的なコーディングおよびファイルにおいて、特定の構成、アルゴリズム、および/または、情報の提示は、単なる例であることに留意すべきである。同じ、実質的に同じ、または、類似した結果を達成するために、多数のアプローチまたは方法を利用してもよい。さらに、例示的なコーディングは、InCommを記憶値カードプロセッサとして説明していることに留意すべきである。提示されるコーディングは、「incomm」への参照を他の当事者への参照に置換することを含む、任意の数の方法で修正してもよいことが企図されている。
【0036】
[0050]
参加者「QueryHost」は、以下のように規定されていてもよい(以下で説明する値は、例示的な開始値であり、最終的な、生産設定の保証を意図してはいないことに留意すべきである)。
<participant class="com.ols.incomm.QueryHost" logger="Q2" realm="QueryHost">
<property name="mux" value="incomm-mux-pool" />
<property name="saf" value="incomm-svc-saf" />
<property name="threshold" value="3500" />
<property name="timeout" value="19000" />
<property name='retry-response-codes' value="91,92,96" />
<property name='retry-transaction-codes' value="189090" />
<property name="suspend-manager" value="suspend-manager" />
<property name="saf-on-disconnect" value="false" />
<property name="checkpoint" value="query-host" />
</participant>
【0037】
[0051]
以下の表1は、QueryInCommHost中で特定される特性のそれぞれを説明している。
【表1-1】
【表1-2】
【表1-3】
【0038】
SAFマネージャー定義
[0052]
ブリッジに搭載されているエンドポイントは、規定されたまたは展開されたSAFマネージャーコンポーネントを必要とするかもしれない。このようなSAFマネージャーは、(i)SAFキューをアンロードすること、(ii)SAF複製をリトライすること、および、(iii)SAFを同期させる役割を担ってもよい。より具体的には、SAFマネージャーは、指定されたエンドポイントに送り出される必要が依然としてあるかもしれないSAFエントリを識別してもよい。送るためにアイテムが利用可能である場合、SAF取引マネージャーによって取り扱うために、SAFマネージャーは、キュー(SAF.TXN)中にトップ関連エントリを置いてもよい。
【0039】
[0053]
SAF複製は、アンロードプロセスの一部として、ピアノードに実行されてもよい。複製が失敗する(例えば、ピアへの要求がタイムアウトする)場合、リトライ取引マネージャーによって取り扱うために、SAFマネージャーは、キュー(RETRY.TXN)中のこのリスト上にトップ関連エントリを置いてもよい。
【0040】
[0054]
そのピアがダウンしているとノードが通知する場合、ノードは、両方のノードにSAFエントリを送り出す役割を果たす「SOLO」モードで動作することを開始してもよい。その後、そのピアがバックアップであるとノードが認識するとき、ノードは、その代わりにそれが引き受けたすべてのアクションでピアに同期しなければならない。同期が生じた場合、SAFマネージャーは、同期取引マネージャーによって取り扱うために、キュー(SYNC.TXN)中のこのリスト上にトップ関連エントリを置いてもよい。
【0041】
[0055]
例えば、エンドポイントをブリッジアプローチに統合するために、SAFマネージャー定義は、以下であってもよい。
<saf name='bridge-saf' logger='q2' realm='saf' class='org.jpos.saf.SAFManager'>
<property name="endpoint" value="INCOMM" />
<property name="echo-mgr" value="incomm-echo-mgr" />
<property name="initial-delay' value='10000' />
<property name='penalty-box-time' value='300000' />
<property name='polling-delay' value='500' />
<property name='max-saf-space-queue-size' value='6' />
<property name='max-retry-space-queue-size' value='6' />
<property name='max-sync-space-queue-size' value='20'/>
<property name='max-retransmissions' value='12' />
<property name='expire-after' value='43200'> in seconds </property>
<property name="node" value="1" />
<property name="peer-node" value="2" /<
</saf>
【0042】
[0056]
以下の表2は、SAFマネージャー中で特定される特性のそれぞれを説明している。
【表2-1】
【表2-2】
【0043】
エコーマネージャー
[0057]
本発明のいくつかの実施形態にしたがうシステムおよび方法は、エコーマネージャーも備えていてもよく、これは、ブリッジと外部認可者(例えば、記憶値カードプロセッサ)との間でネットワークレベルメッセージ(例えば、08xxシリーズメッセージ)を送ることおよび受け取ることを制御してもよい。エコーメッセージは、少なくとも2つの目的で機能してもよい:(i)これは、量の少ないときに恒久的に接続されているチャネルを通じたままにする(非アクティブの期間の後、多くの遠隔ホストが接続を強制遮断させるかもしれない)、および/または、(ii)これは、外部認可者を証明し、エコー要求への有効な応答を受信すると、中止モードからブリッジを出すように機能できる。エコーマネージャー参加者は以下のように規定されていてもよい:
<incomm-echo-manager class="com.ols.incomm.EchoManager" logger="Q2" >
<property name="persist-space" value="je:incomm-echo:space/incomm-echo" />
<property name="suspend-space" value="je:suspend:space/suspend" />
<property name="mux" value="incomm-mux" />
<property name="echo-mgr" value="incomm-echo-mgr" />
<property name="channel-ready" value="incomm.ready" />
<property name="timeout" value="19000" />
<property name="echo-interval" value="120000" />
<property name="max-timeouts" value="20" />
<property name="node" value="1" />
</incomm-echo-mgr>
【0044】
[0058]
以下の表3は、エコーマネージャー中で特定される特性のそれぞれを説明している。
【表3】
【0045】
ブリッジ発生応答コード
[0059]
ブリッジが取引において中に入り、何らかのアクションをする場合、それは、応答において、応答コード(「RC」-フィールド39)を顧客のアプリケーションに返送するかもしれない。これらの「RCスレート」は、ブリッジ決定に関する洞察を提供し、とられるかもしれない任意の次のステップに関して顧客のホストへのガイダンスを与えるように設計されている。
【0046】
[0060]
ブリッジの承認スレートは、「Bx」の形態であってもよい。顧客のアプリケーションは、RC=「Bx」(例えば、B1、B1等)である任意の応答を、承認された取引として取り扱うかもしれない。表4は、以下のBスレート承認コードのうちのいくつかを図示している。
【0047】
【表4】
【0048】
[0061]
コードB0、B1、B2、B3、およびB6に対して、顧客のアプリケーションは、POSシステムに、(口頭のまたは領収書上に印刷されたのいずれかで)製品は24時間以内に使用に対して利用可能になるだろうと顧客に知らせるように命令すべきであることに留意すべきである。
【0049】
[0062]
ブリッジの拒否スレートは、「Dx」の形態であってもよい。顧客のアプリケーションは、RC=「Dx」である任意の応答を、拒否された取引として取り扱うかもしれない。表5は、以下のDスレート拒否コードのうちのいくつかを図示している。
【0050】
【表5】
【0051】
[0063]
ある拒否テキストが、POSディスプレイに提供されてもよいことに留意すべきである。例えば、拒否コードD1が発行される場合、ディスプレイは、「オリジナル要求が受け入れられたこと」を示してもよい。D2、D3、D4、D5、D8、D9、またはDAが発行される場合、ディスプレイは、「即座に再度トライ」を示してもよい。D6またはD7が発行される場合、ディスプレイは、「製品に対して量が不適当」を示してもよい。
【0052】
データベーステーブル定義
[0064]
ブリッジは、結果とメトリック情報を取引ログ(「tranlog」)tranlogテーブルに記録してもよい。ブリッジは、SAFを呼び出そうとなかろうと、これが見るすべての取引に対してtranlog記録を書き込む「heavier」を、または、SAFを呼び出す取引のみに対してtranlog記録を書き込む「lighter」を実行するように構成されていてもよい。選択は、メイン取引マネージャーのCreateTranLog参加者中の「log-safed-only」特性を介して伝えられる:
<participant class="com.ols.jpos.CreateTranLog" logger="Q2" realm="CreateTranLog>
<property name="queue" value="MAIN.TXN" />
<property name="space" value=tspace:default" />
<property name="server" value="@server@" />
<property name="log-safed-only" value="true" />
<property name="checkpoint" value-"create-tranlog" />
</participant>
【0053】
[0065]
ブリッジとその特性とのコンフィギュレーションの間、取引期間ずっとブリッジの影響の記録された証拠を顧客が望む場合、heavierコンフィギュレーションが選ばれてもよい(ここで、値=「偽」である)。逆に、取引タッチおよび対応するデータベース管理の両方において、顧客がブリッジのフットプリントを最小化したい場合、顧客は、lighterコンフィギュレーションを選んでもよい(ここで、値=「真」である)。一般的に、および、本発明のいくつかの実施形態にしたがうと、「tranlog」テーブルは、以下のように規定されていてもよい:
CREATE TABLE [dbo].[tranlog](
[id] [numeric](19, 0) IDENTITY(1,1) NOT NULL,
[date] [datetime] NULL,
[irc] [varchar](4) NULL,
[rrc] [varchar](4) NULL,
[rc] [varchar](4) NULL,
[duration] [numeric](19, 0) NULL,
[extDuration] [numeric](19, 0) NULL,
[outstanding] [int] NULL,
[node] [varchar](1) NULL,
[pc] varchar'(6) NULL,
[extrc] [varchar](255) NULL,
[peerDuration] [numeric](19, 0) NULL,
PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_ KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
【0054】
[0066]
以下の表6は、tranlog中で特定される特性のそれぞれを説明している。
【表6】
【0055】
[0067]
本発明のいくつかの実施形態にしたがうと、(例えば、SAFから出るアウトバウンド要求上のSTANを変更すること、直接の特定な処理への関連するエントリに対するSAFキューをチェックすることのような)の特定の要件を満たすために、ブリッジのリアルタイム処理エンジンは、「SAF可能」アイテムを、2つの相互に関係するデータベーステーブル、safMetaテーブル、および、safDataテーブルに、行として書き込んで(その後に更新)してもよい。次にそれぞれを以下で説明する。
【0056】
[0068]
safMetaテーブルは、SAFエントリ(例えば、「エンドポイント」)についての「meta」データとともに、エントリに関連する動的データ、すなわち、各SAF試行の後にブリッジが更新するかもしれない値(例えば、「lastSent」、「lastStan」)を含んでいてもよい。さらに、SAFベースのデータベースクエリの一部としてブリッジが使用する任意のフィールドは、この「Meta」テーブル中に位置付けられる必要がある。
【0057】
[0069]
同様に、safDataテーブルは、SAF要求の安全な表現とともに、エントリに関連する静的データ(例えば、「reversal」、「inboundStan」)を含んでいてもよい。
【0058】
[0070]
これらのテーブルの行に書き込むことは、以下の状況のうちの1つ以上において生じてもよい:(a)取引応答が認可者から受信され、取引応答には、遠隔応答コード(RRC)が、ブリッジのretry-response-codesのうちの1つとしてリストアップされ、取引の対応する取引コードが、「retry-transaction-codes」中にリストアップされ、(b)取引応答が認可者から受信されず(すなわち、タイムアウトが生じている)、取引の対応する取引が「retry-transaction-codes」中にリストアップされ、(c)取引要求を準備するとき、認可者へのすべてのラインが切断され(マルチプレクサ切断シナリオ)、ブリッジ顧客が「saf-on-disconnect」を「真」にするとしてシステムを構成することが観測され、(d)顧客から要求が受信され、SAFテーブル中の同じカードに対する補充的な、未送付要求があったことが決定され、(e)取引応答が認可者から受信されなかった(すなわち、タイムアウトが生じ、取引の対応する取引コードが「retry-transaction- codes」中にリストアップされていない、(または、リストアップされているが、ブリッジは、Swipe Reloadとして要求を識別した)、あるいは、(f)端末ベースのタイムアウト取消または顧客無効/キャンセルがポイントオブセールから受信された。(a)-(e)は、「ホストベースのタイムアウト取消」として呼ばれることがあり、したがって、TORとして呼ばれることがあることに留意すべきである。
【0059】
[0071]
上記の状況(a)-(d)において、オリジナル取引は、テーブルに書き込まれるアイテムであってもよい一方で、行における取消列は「偽」に設定されてもよい。状況(e)において、オリジナル取引の取消は、テーブルに書き込まれるアイテムであってもよく、行における取消列は、「真」に設定されてもよい。状況(f)において、オリジナル取引の取消は、POSから直接受信されてもよく、アイテムは、テーブルに書き込まれてもよい一方で、行における取消列は、「真」に設定されてもよい。状況のそれぞれにおいて、リアルタイム処理エンジンによって初めてテーブルに書き込まれるときのアイテムのステータスは、「リトライ」に設定されてもよい。
【0060】
[0072]
その後および非同期的に、ブリッジのSAFマネージャーは、このテーブルを読み取って、どの行が送り出しに対して依然として存続可能な候補を含んでいるかを決定してもよい。存続可能な候補は、アイテムが、(i)満了していない、(ii)リトライ試行の最大数に達していない、(iii)以前に送り出すことに成功しなかった、および/または、(iv)以前の送る試行の間に処理例外をもたらさなかった、ものであってもよい。したがって、「リトライ」ステータスのままであるアイテムは、送り出すことに対して存続可能な候補であるかもしれない。
【0061】
[0073]
本発明のいくつかの実施形態にしたがうと、「safMeta」テーブルは、以下のように規定されていてもよい:
CREATE TABLE [dbo].[safMeta](
[id] [mumeric](19, 0) IDENTITY(1,1) NOT NULL,
[tranId] [numeric] (19, 0) NOT NULL,
[node] [varchar] (1) NOT NULL,
[endpoint] [varchar] (20) NOT NULL,
[hash] [varchar] (255) NOT NULL,
[status] [varchar] (5) NOT NULL,
[created] [datetime] NOT NULL,
[pc] [varchar] (6) NOT NULL,
[lastSent] [datetime] NULL,
[lastRRC] [varchar] (2) NULL,
[lastStan] [varchar] (12) NULL,
[lastNode] [varchar] (1) NULL,
[LastAuthId] [varchar] (20) NULL,
[attempts] [int] NULL,
[repStatus] [varchar] (5) NULL,
[repRetryReason] [varchar] (4) NULL,
[repPhase] [varchar] (1) NULL,
[repTime] [datetime] NULL,
[archiveId] [numeric] (19, 0) NOT NULL DEFAULT 0,
[extractId] [numeric] (19, 0) NOT NULL DEFAULT 0,
PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY
GO
CREATE NONCLUSTERED INDEX [pending] ON [dbo].[safMeta]
(
[hash] ASC,
[status] ASC,
[endpoint] ASC
) WITH (PAD_INDEX = OFF STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [toSend] ON [dbo].[safMeta]
(
[created] ASC,
[status] ASC,
[endpoint] ASC,
[node] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [toRetry] ON [dbo].[safMeta]
(
[created] ASC,
[status] ASC,
[endpoint] ASC,
[node] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [toUpdate] ON [dbo].[safMeta]
(
[tranId] ASC,
[node] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
【0062】
[0074]
表7は、safMetaテーブル中で特定される特性のそれぞれを説明している。
【表7-1】
【表7-2】
【表7-3】
【0063】
[0075]
上記で議論したように、safDataテーブルも規定されていてもよい。
CREATE TABLE [dbo].[safData](
[id] [numeric] (19, 0) NOT NULL,
[secureData] [varbinary] (8000) NULL,
[keyId] [varchar] (7) NULL,
[reversal] [tinyint] NULL,
[inboundStan] [varchar] (12) NULL,
[rrn] [varchar] (12) NULL,
[amount] [numeric] (14, 2) NULL,
PRIMARY KEY CLUSTERED
(
[id] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
【0064】
[0076]
以下の表8は、safMetaテーブル中で特定される特性のそれぞれを説明している。
【表8】
【0065】
[0077]
図3を参照すると、ブリッジ30の例示的および非限定的な、役割および動作が図示されている。図3は、さまざまな取引フローを描き、他の取引関係者に関連するブリッジのアクションを説明している。取引は、顧客310において起きてもよく、顧客310は、POS311および/またはホスト312を備えていてもよい。POS311は、取引を起こしてもよく、取引は、ホスト312を通してブリッジ320に流れるかもしれない。取引は、ブリッジ320を通して流れ、記憶値カードプロセッサ330に送り出されるように継続されるかもしれない。記憶値カードプロセッサ330は、その後、(例えば、サービスプロバイダ340との通信を通して)取引を処理するかもしれず、ブリッジ320を通して、ホスト312を通して、POS311に、取引応答を戻すかもしれない。フローのそれぞれにおいて、ブリッジ320は、忠実に、要求と関連する応答とを関連付けること以外に、取引に値を追加しないかもしれない。
【0066】
[0078]
より具体的には、350において、承認取引フローを見ることができ、ここで、取引は、記憶値カードプロセッサまたは最終のサービスプロバイダにより承認される。この取引フローは、POS311において起き、ホスト312とブリッジ320を通して記憶値カードプロセッサ330に流れるかもしれない。記憶値カードプロセッサ330は、00の応答コード(RC)を提供するかもしれない。ブリッジ320は、その後、このRCを、ホスト312を介して、POS311に伝えるかもしれない。
【0067】
[0079]
360において、ハード拒否取引が図示されている。再度説明すると、この取引フローは、POS311において起き、ホスト312とブリッジ320を通して記憶値カードプロセッサ330に流れるかもしれない。記憶値カードプロセッサ330は、14の応答コード(RC)を提供するかもしれない。ブリッジ320は、その後、このRCを、ホスト312を介してPOS311に伝えるかもしれない。
【0068】
[0080]
370において、「リトライリスト」取引上にない処理コードを有するソフト拒否が図示されている。さらに、この取引フローは、POS311において起き、ホスト312とブリッジ320を通して記憶値カードプロセッサ330に流れるかもしれない。記憶値カードプロセッサ330は、96の応答コード(RC)を提供するかもしれない。ブリッジ320は、その後、このRCを、ホスト312を介して、POS311に伝えるかもしれない。
【0069】
[0081]
図4を参照すると、代理承認(SAF=00)によるソフト拒否の例示的な取引フロー40が図示されている。一般的に、取引は、記憶値カードプロセッサにより「ソフト拒否」されるかもしれず、取引は、「retry-transaction-code」リスト上に構成されている。したがって、ブリッジは、アイテムをそのSAFキューに置いてもよく、メッセージ「B0」-拒否に関する代理承認を反映するように、顧客へのRCを変更する。その後、取引と非同期的に、ブリッジは、アイテムのSAFされた要求を記憶値カードプロセッサに送るかもしれない。第1のトライは、96のRCにより拒否されるかもしれない。しかしながら、SAF取引マネージャーは、メイン(リアルタイム)取引マネージャーと同じコンフィギュレーションルールにしたがうかもしれないことから、各「ソフト拒否」応答は、結果として、少なくとも、構成された最大試行数または割り当てられた時間まで-別の試行であってもよい。取引が成功する(すなわち、認可者または記憶値カードプロセッサによって取引が承認される)とき、アイテムは、「行われた」と印が付けられてもよく、将来のSAFアンロードアクションに対する考慮から取り除かれるかもしれない。
【0070】
[0082]
継続して図4を参照すると、上記の例が図表を用いて図示されている。顧客410において、取引が起きてもよい。顧客POS411は、そのホスト412を通してブリッジ420に取引要求450を送るかもしれない。以前のように、ブリッジ420は、取引を記憶値カードプロセッサ430に送ろうとするかもしれない。ブリッジ420が、参照番号451において図示されている、ソフト拒否-96のRCを受信する場合、ブリッジ420は、アイテムのステータスを「リトライ」に設定し、459においてRCをB0に設定し、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と示すように、POS411を促すかもしれない。
【0071】
[0083]
取引は、その後、ブリッジ420中のSAFキュー470にルーティングされてもよい。453において、取引は、再度試行されるかもしれないが、追加のソフト拒否を示している96のRCコードが454で図示されている。455において、取引は、「リトライ」として示されるかもしれない。456において、取引は、再度試行されるかもしれず、457において、96のRCコードを再度受信するかもしれない。さらに、458において、取引は、「リトライ」として示されるかもしれない。459において、取引は、再度試行されるかもしれず、成功して行われるかもしれない。00のRCコードが460で戻されるかもしれず、その後、取引は、「行われた」とフラグが立てられ、SAFキューから取り除かれるかもしれない。
【0072】
[0084]
図5を参照すると、代理承認によるソフト拒否とSAF=ハード拒否の例示的なシナリオ50が図示されている。一般的に、取引は、記憶値カードプロセッサまたは最終サービスプロバイダによりソフト拒否されるかもしれず、取引は、「retry-transaction-code」リスト上に再度構成されるかもしれない。したがって、ブリッジは、拒否に関して代理承認を提供するかもしれず、そのアイテムをSAFキューに置くかもしれず、B0のRCコードをPOSに報告するかもしれない。その後、場合によっては非同期的に、ブリッジは、アイテムのSAFされた要求を記憶値カードプロセッサに送るかもしれない。アイテムを認可するための2つの試行は、追加のソフト拒否を受信するかもしれない。第3の試行は、記憶値カードプロセッサからのハード拒否を受信するかもしれない。このアイテムは、その後、SAFキューから取り除かれ、例外ファイル中に含められるべきである。
【0073】
[0085]
継続して図5を参照すると、上記の例が図表で図示されている。顧客510において、取引が起きてもよい。顧客POS511は、そのホスト512を通してブリッジ520に取引要求550を送るかもしれない。以前のように、ブリッジ520は、取引を記憶値カードプロセッサ530に送ろうとするかもしれない。ブリッジ520が、参照番号551において図示されている、ソフト拒否-96のRCを受信する場合、ブリッジ520は、アイテムのステータスを「リトライ」に設定し、553においてRCをB0に設定し、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と示すように、POS411を促すかもしれない。
【0074】
[0086]
取引は、その後、ブリッジ520中のSAFキュー570にルーティングされるかもしれない。554において、取引は、再度試行されるかもしれないが、追加のソフト拒否を示している96のRCコードが555で図示されている。556において、取引は、「リトライ」として示されるかもしれない。557において、取引は、再度試行されるかもしれず、558において、96のRCコードを再度受信するかもしれない。再度説明すると、559において、取引は、「リトライ」として示されるかもしれない。560において、取引は、再度試行されるかもしれず、参照番号561で図示されている14のハード拒否RCコードを受信するかもしれない。562において、アイテムは、「行われた」とフラグが立てられ、SAFキュー570から取り除かれるかもしれない。記憶値カードプロセッサ530からのハード拒否により、アイテムは、例外ファイル中に含められるべきである。
【0075】
[0087]
図6を参照すると、SAFがリトライの最大数に達する、ブリッジ代理承認によるソフト拒否の例示的なシナリオ60が図示されている。一般的に、取引は、記憶値カードプロセッサまたは最終サービスプロバイダにより「ソフト拒否」されるかもしれないが、取引は、「retry-transaction-code」リスト上に構成されるかもしれない。ブリッジは、その後、そのアイテムをSAFキューに置くかもしれず、代理承認を提供するかもしれず、それにより、RCを「B0」に変更するかもしれない。その後、場合によっては非同期的に、ブリッジは、アイテムのSAFされた要求を記憶値カードプロセッサに送るかもしれない。この例では、ブリッジは、承認またはハード拒否を取得するのに成功しないかもしれないが、代わりに、試行の最大数に達するかもしれない。最終的に、SAFマネージャーは、「最大送信」しきい値が満たされていることを認識するかもしれない。何らかの成功した試行の前に、SAFマネージャーは、アイテムを「MAX」と印付けて、それを将来のSAFアンロードアクションに対する考慮から取り除くかもしれない。このアイテムも、例外ファイル中に含められるかもしれない。
【0076】
[0088]
継続して図6を参照すると、上記の例が図表で図示されている。顧客610において、取引が起きてもよい。顧客POS611は、そのホスト612を通してブリッジ620に取引要求650を送るかもしれない。以前のように、ブリッジ620は、取引を記憶値カードプロセッサ630に送ろうとするかもしれない。ブリッジ620が、参照番号651において図示されている、ソフト拒否-96のRCを受信する場合、ブリッジ620は、652において、アイテムのステータスを「リトライ」に設定し、653においてRCをB0に設定し、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と示すように、POS611を促すかもしれない。
【0077】
[0089]
取引は、その後、ブリッジ620中のSAFキュー670にルーティングされるかもしれない。654において、取引は、再度試行されるかもしれないが、追加のソフト拒否を示している96のRCコードが655で図示されている。656において、取引は、「リトライ」として示されるかもしれない。657において、取引は、再度試行されるかもしれず、658において、96のRCコードを再度受信するかもしれない。再度説明すると、659において、取引は、「リトライ」として示されるかもしれない。660において、取引は、許容可能な試行の最大数に達するかもしれず、661において、「MAX」とフラグが立てられるかもしれない。この点において、SAFマネージャーは、アイテムをキューから取り除くかもしれない。記憶値カードプロセッサ630からの最終承認または拒否なく、試行の最大数に達したことにより、アイテムは、例外ファイル中に含められるべきである。
【0078】
[0090]
図7を参照すると、代理承認によるホストタイムアウトの例示的なシナリオ70が図示されている。一般的に、ブリッジによってアクションがとられるときを図示するために、2つのタイムアウト状況が示されている。第1のケースでは、処理コードが「リトライ」リスト上になく、第2のケースでは、処理コードが「リトライ」リスト上にある。第1のケースでは、D2のRCコードを有する拒否(クエリ遠隔ホストタイムアウトに関する拒否)が受信されるかもしれない。記憶値カードプロセッサに送られることになる取消要求が生成されて、SAFに送られるかもしれない。第2のケースでは、ブリッジは、要求をタイムアウトするかもしれないが、RCコードが「B1」である代理承認を記録するかもしれない。SAFされた要求が、記憶値カードプロセッサによって受け入れられて承認されるまで、SAFされた要求は、記憶値カードプロセッサに送られるかもしれず、-記憶値カードプロセッサによって受け入れられて、承認される点で、アイテムは、「行われた」とフラグが立てられるかもしれず、将来のSAFアンロードアクションに対する考慮から取り除かれるかもしれない。
【0079】
[0091]
継続して図7を参照すると、上記の例が図表で図示されている。顧客710において、取引が起きてもよい。顧客POS711は、そのホスト712を通してブリッジ720に取引要求750を送るかもしれない。以前のように、ブリッジ720は、取引を記憶値カードプロセッサ730に送ろうとするかもしれない。ブリッジ720が、751においてタイムアウトする場合、752において、ステータスは「リトライ」に設定されるかもしれず、取消は「真」に設定されるかもしれない。ブリッジは、その後、753において、「D2」のRCを伝え、POS711に「即座に再度トライ」と通知するかもしれない。
【0080】
[0092]
しかしながら、754において、ホストタイムアウトは、異なる結果を受信するかもしれない。ここで、タイムアウト755が生じるかもしれず、756において、ステータスは、再度「リトライ」に設定されるかもしれないが、取消は「偽」に設定されるかもしれない。757において、B1のRCがPOSシステムに送られ、「この製品は24時間で使用に対して利用可能になるでしょう」と購入者に通知するかもしれない。758において、SAFキュー770は、再度取引を行おうとするかもしれず、759において再度タイムアウトするかもしれない。760において、アイテムは、再度「リトライ」とフラグが立てられるかもしれない。761において、ブリッジは、再度取引を行おうとするかもしれず、762において、今回は、記憶値カードプロセッサから、96のRCコードを有するソフト拒否を受信するかもしれない。再度説明すると、アイテムは、763において、「リトライ」とフラグが立てられるかもしれない。最後に、764において、取引が行われるかもしれず、取引が成功したと示す、00のRCコードが戻されるかもしれない。766において、SAFキュー770からそれを取り除くために、アイテムは、「行われた」とフラグが立てられるかもしれない。
【0081】
[0093]
図8を参照すると、試行の最大数に達した、ブリッジによる代理承認を有するホストタイムアウトの例示的なシナリオが図示されている。一般的に、取引要求は、POSからのブリッジに送られるかもしれず、要求はタイムアウトするかもしれない。ブリッジは、その後、アイテムをそのSAFキューに置き、代理承認を提供し、POSに「B1」のRCコードを返報告するかもしれない。ブリッジは、その後、アイテムのSAFされた要求を記憶値カードプロセッサに送るかもしれない。第1の試行もタイムアウトするかもしれず、第2の試行は、ソフト拒否を受信するかもしれない。すべての後続する試行は、タイムアウトする、または、ソフト拒否を受信するのいずれかであるかもしれない。最終的に、SAFマネージャーは、SAFエントリの生成(「safMeta.created」)間の時間期間は、現在「expired-after」中で特定されている時間量を超えていると認識するかもしれない。マネージャーは、その後、アイテムを「EXP」と印付け、将来のSAFアンロードアクションに対する考慮からそれを取り除くかもしれない。アイテムは例外ファイル中に含められるべきである。
【0082】
[0094]
継続して図8を参照すると、上記の例が図表で図示されている。顧客810において、取引が起きてもよい。顧客POS811は、そのホスト812を通してブリッジ820に取引要求850を送るかもしれない。以前のように、ブリッジ820は、取引を記憶値カードプロセッサ830に送ろうとするかもしれない。ブリッジ820が、参照番号851において図示されているようにタイムアウトする場合、852において、ブリッジ820は、アイテムのステータスを「リトライ」、取消=「偽」に設定し、853において、RCをB1に設定し、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と示すように、POS811を促すかもしれない。
【0083】
[0095]
取引は、その後、ブリッジ820中のSAFキュー870にルーティングされるかもしれない。854において、取引は、再度試行されるかもしれないが、855において、再度タイムアウトするかもしれない。856において、アイテムは、「リトライ」とフラグが立てられるかもしれない。857において、取引は、再度試行されるかもしれず、858において、96のRCコードを受信するかもしれない。再度説明すると、859において、取引は、「リトライ」として示されるかもしれない。860において、取引は、861で再度タイムアウトするかもしれない。862において、取引は、再度「リトライ」とフラグが立てられるかもしれない。しかしながら、エントリのための時間は、「expire-after」量を超えていることが認識されるかもしれず、863において、アイテムは「EXP」のステータスに設定されるかもしれない。この点で、SAFマネージャーは、アイテムをキューから取り除くかもしれない。記憶値カードプロセッサ830からの最終承認または拒否なく、最大時間量に達していることにより、アイテムは、例外ファイル中に含められるべきである。
【0084】
[0096]
図9を参照すると、中止モード90の例示的なシナリオが図示されている。一般的に、図9は、処理コードが「リトライ」リスト上にあるときとないときの中止モードを図示している。処理コードが「リトライ」リスト上にないとき、ブリッジは、要求をタイムアウトして、アイテムをSAFキュー上に置き、代理承認を提供し、顧客に報告されるRCを「B1」に変更するかもしれない。ブリッジは、エコーマネージャー中で特定される「max-timeouts」値を超える回数、タイムアウトするかもしれず、これは、ブリッジを「中止」モードに置く。
【0085】
[0097]
中止モードの間、ブリッジは、何らかの外部認可者に問い合わせることなく、ローカルに取引を決定するかもしれない。「retry-transaction-code」上で特定されている場合、ブリッジは、アイテムをSAFキュー中に置き、取引をPOSに戻す前に応答コードを変更するかもしれない。応答コードは、「B3」(ブリッジ中止に関する代理承認)または「D3」(ブリッジ中止に関する拒否)に変更されるかもしれない。中止モードが変更されるまで、ブリッジは、SAFエントリをアンロードするように試行しないであろうことに留意すべきである。記憶値カードプロセッサが「エコー」要求に応答する場合、ブリッジは、中止モードを出て、取引要求のために記憶値カードプロセッサに問い合わせることを再開し、SAFマネージャーを介してSAFキューをアンロードするだろう。
【0086】
[0098]
継続して図9を参照すると、上記の例が図表で図示されている。顧客910において、取引が起きてもよい。顧客POS911は、そのホスト912を通してブリッジ920に取引要求950を送るかもしれない。以前のように、ブリッジ920は、取引を記憶値カードプロセッサ930に送ろうとするかもしれない。ブリッジ920が、参照番号951において図示されているようにタイムアウトする場合、952において、ブリッジ920は、アイテムのステータスを「リトライ」、取消=「偽」に設定し、953において、RCをB1に設定し、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と示すように、POS911を促すかもしれない。取引は、955において、タイムアウトの最大数に達するまでリトライするだろう、そして、ブリッジは、中止モードに入る。
【0087】
[0099]
中止モードの間、ブリッジ920は、POS911から取引要求954を受信するかもしれない。ブリッジ920は、取引をローカルに認可し、956において、ステータスを「リトライ」に設定し、957において、「B3」の応答コードを戻すかもしれない。さらに、ブリッジ920は、エコー要求958を記憶値カードプロセッサ930に継続して送るだろうが、959において、エコーはタイムアウトするかもしれない。
【0088】
[00100]
処理コードが「リトライ」リスト上にない場合、取引960は、ブリッジによって拒否されるかもしれず、「D3」のRCコード(ブリッジ中止に関する拒否)が発行されるかもしれない。いくつかの時点において、エコー962は、記憶値カードプロセッサによって戻されるかもしれない。ブリッジ920は、中止モードからそれ自体を取り除くだろう、そして、963のような、後続する取引を、記憶値カードプロセッサ930に通過させ、964において、「B1」のRCを有する成功メッセージを受信するかもしれず、965において、ブリッジ920は、これをPOS911に渡すかもしれない。その後、SAFキュー970は、966でアンロードされ、967において、「00」のRCコードを受信し、968において、アイテムに「行われた」とフラグを立ててもよく、それにより、SAFキューからアイテムを取り除くかもしれない。
【0089】
[00101]
図10を参照すると、発起者ベースの無効および取消を伴うシナリオ1000が図示されている。一般的に、ブリッジは、顧客ホストから取消-クラス(MTI0400)メッセージを受信するかもしれない。この取引要求は、(i)POSにおけるキャンセル/無効に、(ii)POSにおけるシステムタイムアウトに、または、(iii)ホストにおけるシステムタイムアウトに基づいているかもしれない。ブリッジは、このような要求をローカルに受け入れ、アイテムをSAFキューに置き、「B4」のRC(強制承認/取消受け入れ)で応答するかもしれない。その後、場合によっては非同期的に、ブリッジは、SAFされた要求を記憶値カードプロセッサに送るかもしれない。このリトライが成功した場合、アイテムは、「行われた」と印付けられ、将来のSAFアンロードアクションに対する考慮から取り除かれるかもしれない。
【0090】
[00102]
継続して図10を参照すると、上記の例が図表で図示されている。顧客1010において、取引が起きてもよい。顧客POS1011は、そのホスト1012を通してブリッジ1020に取引要求1050を送るかもしれない。以前とは異なり、ブリッジ1020は、取引を記憶値カードプロセッサ1030に送ろうとしないかもしれないが、1051においてアイテムに「リトライ」とのフラグが立て、1052において「B4」のRCを戻すかもしれない。1053において、POS1011は、この応答を受信するかもしれない。アイテムはその後、SAFキュー1060に提供され、1054において、記憶値カードプロセッサ1030に提供されるだろう。記憶値カードプロセッサ1030によって受け入れられる場合、RCは、1055において「00」に設定されるかもしれず、アイテムは、1056において、「行われた」とフラグが立てられるかもしれず、これにより、SAFキューからそれを取り除く。
【0091】
[00103]
SAFテーブルの現在のコンテンツがブリッジの取引処理挙動に影響を与えるかもしれないシナリオがあってもよいことに留意すべきである。例えば、ブリッジが、SAFキュー中にカードアクティブ化を以前に置いたが、アイテムを送り出すことにまだ成功しておらずに、同じカードに対する非アクティブ化要求を現在受信している場合、適切な時系列の順序で、新たなアイテム(非アクティブ化)をSAFキュー中に直接置くことが適切であるかもしれない。以下の表は、SAFテーブル中のペンディングアイテムコンテンツに基づいて、特定の考慮をブリッジがどのようにするかを図示しており、ここで、「A」はアクティブ化、「AR」は、アクティブ化取消、「D」は非アクティブ化、「DR」は非アクティブ化取消である。
【0092】
【表9】
【0093】
[00104]
いくつかのケースにおいて、上記に描いたトップSAFエントリは、カードに対する以前のアイテムがSAFされていることもを意味しているかもしれない。例えば、上記のケース3において、非アクティブ化がSAFキュー中で終わる唯一の方法は、それに先行するアクティブ化もSAF中に置かれた場合である。したがって、ケース3に対する完全なシーケンスは、少なくとも「A-D-A」であるべきである。実際には、カード購入者が製品の直ちの使用を望むことから、「24時間内にカードはアクティブになるでしょう」ということを表している領収書に直面したカード購入者が、カードをリトライすることを求めるときに、この進行が生じることが多い。これは、製品を非アクティブ化および再アクティブ化するために必要なポジションに、POSにおける販売員を置くかもしれない。しかしながら、SAFアイテムがアンロードされるまで、購入者に提示される結果は、同じままであるかもしれない。
【0094】
[00105]
図11を参照して、例示的なペンディングSAF状況1100を説明する。一般的に、取引が記憶値カードプロセッサによってソフト拒否され、取引が「retry-transaction-code」リスト上に構成されるとき、この状況が生じるかもしれない。ブリッジは、アイテムをSAFキューに置き、RCコードをB0(拒否に関する代理承認)に変更するかもしれない。ブリッジは、購入者に「この製品は24時間以内に使用のために利用可能になるでしょう」と通知するように、POS911に通知するかもしれない。しかしながら、ブリッジは、その後、同じ製品に対する第2の取引を受信するかもしれない。ブリッジは、SAFキューをチェックして、SAFキュー中にペンディングアイテムがあることを決定するかもしれない。したがって、ブリッジは、拒否を「D1」と記録し、それを返報告してもよい。その後、非同期的に、ブリッジは、アイテムのSAFされた要求を記憶値カードプロセッサに送るかもしれない。
【0095】
[00106]
継続して図11参照すると、上記の例が図表で図示されている。顧客1110において、取引が起きてもよい。顧客POS1111は、そのホスト1112を通してブリッジ1120に取引要求1150を送るかもしれない。以前のように、ブリッジ1120は、取引を記憶値カードプロセッサ1130に送ろうとするかもしれない。1151において、ブリッジ1120がソフト拒否を受信する場合、1152において、アイテムに「リトライ」とフラグを立てて、1153において、B0のようなRCコードをPOSに戻すかもしれない。1154において、ブリッジは、後の処理のために、アイテムをSAFキュー1170に送るかもしれない。1155において、その後、ブリッジが同じカードに対する第2の取引を受信する場合、ブリッジは、この取引を記憶値カードプロセッサ1130に渡さないかもしれないが、1156において、「D1」のRCコード-すなわち、拒否-を発行するかもしれない。これは、1157において、POS1111に提供されるかもしれず、「オリジナルの要求が受け入れられた」ことが通知されるかもしれない。その後、1158において、SAFキュー1170は、取引要求1158を記憶値カードプロセッサ1130に送り、1159において、取引が受け入れられたことを示す、「00」のRCコードを受信するかもしれない。1160において、アイテムは、「行われた」とフラグが立てられ、SAFキュー1170から取り除かれるかもしれない。
【0096】
[00107]
図12を参照して、SAF中の補充的なアイテムの、いくつかの例示的なシナリオ1200を説明する。一般的に、取引が記憶値カードプロセッサに送られるかもしれず、ソフト拒否されるかもしれず、取引は、「retry-transaction-code」リスト上に構成されるかもしれない。ブリッジは、アイテムをSAFキューに置き、顧客に返報告されるRCを「B0」(拒否に関する代理承認)に変更するかもしれない。その後、ブリッジは、同じカードに対する第2の取引要求、今回は非アクティブ化、を受信するかもしれない。ブリッジは、SAFキューをチェックして、ペンディングアクティブ化があることを認識するかもしれない。ブリッジは、アイテムをSAFキューに置き、「B2」のRCコードの(SAF中のペンディング補充アイテムに関する代理承認)を顧客に返報告するかもしれない。ブリッジは、その後、別の非アクティブ化を受信するかもしれない。再度説明すると、ブリッジは、SAFキューをチェックして、キュー中にペンディング非アクティブ化があることを決定するかもしれない。したがって、ブリッジは、「B5」のRCコード(重複承認)を返報告するかもしれない。その後に、非同期的に、ブリッジは、2つのアイテム(アクティブ化と第1の非アクティブ化)のSAFされた要求を記憶値カードプロセッサに送るかもしれない。
【0097】
[00108]
継続して図12を参照すると、上記の例が図表で図示されている。顧客1210において、取引が起きてもよい。顧客POS1211は、そのホスト1212を通してブリッジ1220に取引要求1250を送るかもしれない。以前のように、ブリッジ1220は、取引を記憶値カードプロセッサ1230に送ろうとするかもしれない。1251において、ブリッジ1220がソフト拒否を受信する場合、1252において、「リトライ」とアイテムにフラグを立てて、1253において、B0のようなRCコードをPOSに戻すかもしれない。1254において、ブリッジは、後の処理のために、アイテムをSAFキュー1270に送るかもしれない。
【0098】
[00109]
1255において、その後、ブリッジが同じカードに対する第2の取引を受信する場合、ブリッジは、この取引を記憶値カードプロセッサ1230に渡さないかもしれないが、1256において、アイテムに「リトライ」とフラグを立てて、1257において、「B2」のRCコードを発行するかもしれない。ブリッジ1220は、その後、1258において、同じカードに対する第3の取引要求を受信するかもしれない。ブリッジ1220は、再度、この要求が記憶値カードプロセッサ1230に送られることを妨げてもよく、代わりに、1259において、RCコード「B5」を戻すかもしれない。その後、1260において、SAFキューは、第1のアイテムを記憶値カードプロセッサ1230に送り、1261において、「00」のRCコードを受信するかもしれず、1262において、第1の取引アイテムに「行われた」とフラグを立てるかもしれない。1263において、SAFキューは、第2の取引アイテムを記憶値カードプロセッサ1230に送るかもしれず、記憶値カードプロセッサ1230は、取引を再度受け入れ、1264において、「00」のRCコードを戻すかもしれない。1265において、第2のアイテムも、「行われた」とフラグが立てられるかもしれない。両方のアイテムは、SAFキューから取り除かれるかもしれない。
【0099】
[00110]
図13を参照すると、受け入れられる最小-最大範囲外のUPCの、例示的なシナリオ1300が図示されている。一般的に、最小許容量を下回るまたは最大許容量を上回るのいずれかである量でリロードされるように、製品は試行されるかもしれない。取引は、ソフト拒否を発行するかもしれない記憶値カードプロセッサに送られるであろう。ブリッジは、その後、アイテムファイル上のUPCに対して構成されている最小/最大範囲をチェックして、量が制限よりも少ないか多いか否かを決定するかもしれない。量が制限よりも少ない場合、ブリッジは、RCコード「D6」(規定された最小量よりも少ないUPCを拒否)を戻すかもしれない一方で、量が最大量より多い場合、ブリッジはコード「D7」(規定された最大量より多いUPCを拒否)を戻すかもしれない。
【0100】
[00111]
継続して図13を参照すると、上記の例が図表で図示されている。顧客1310において、取引が起きてもよい。顧客POS1311は、そのホスト1312を通してブリッジ1320に取引要求1350を送るかもしれない。ブリッジ1320は、取引を記憶値カードプロセッサ1330に送ろうとするかもしれない。1351において、ブリッジ1320がソフト拒否を受信する場合、1352において、UPC最大/最小テーブル1354をレビューし、1353において、「D6」または「D7」のRCコードを戻すかもしれない。
【0101】
[00112]
図14を参照すると、SAFに対してアクティブではないUPCの、例示的なシナリオ1400が図示されている。一般的に、取引は、記憶値カードプロセッサによってソフト拒否されるかもしれず、取引は、「retry-transaction-code」リスト上に構成されるかもしれない。ブリッジは、UPCに関するアイテムファイルに対して構成されている最小/最大範囲をチェックして、要求されている値が範囲内にあるか否かを決定するかもしれない。ブリッジは、UPCに対するアイテムファイル上のアクティブフラグもチェックして、それが「N」に設定されていることを決定するかもしれない。したがって、ブリッジは、「D8」のRC(アイテムがSAFに対してアクティブでない;ソフト拒否に関する代理承認が行われない)を戻すかもしれない。
【0102】
[00113]
継続して図14を参照すると、上記の例が図表で図示されている。顧客1410において、取引が起きてもよい。顧客POS1411は、そのホスト1412を通してブリッジ1420に取引要求1450を送るかもしれない。ブリッジ1420は、取引を記憶値カードプロセッサ1430に送ろうとするかもしれない。1451において、ブリッジ1420がソフト拒否を受信する場合、UPC最大/最小テーブル1552をレビューし、「D8」のRCコードを戻すかもしれない。
【0103】
ログ記録
[00114]
すべてのブリッジアクションは、非公式に「Q2」ログと呼ばれているログファイル中に記録してもよい。トラブルシューティングとイベント解析は、典型的に、これらのファイルを調べることにより、開始してもよい。このようなファイルはまた、ブリッジがどのように動作するかを理解する際に、リーダを支援する。ログは、各ログが管理可能なサイズ(例えば、100MBを超えないくらいの大きさ)に保たれるログローテータサービスによって管理してもよい。
【0104】
[00115]
ログ中のエントリは、(スタートアップの間)展開する、および、(シャットダウンの間)展開しない、すべてのアプリケーションコンポーネントのリストを示していてもよい。ログは、「クリーン」スタートアップの有効性確認するために通常の実務の一部として調べてもよい。これは、新たな特徴と機能をアプリケーションに追加するプロセスのときに、適切かもしれない。
【0105】
[00116]
「通常の」取引に対して、ログ記録は、結果として4つのエントリ:(i)(顧客のホストからの)インバウンド要求;(ii)(外部認可者への)アウトバウンド要求;(iii)(外部認可者からの)インバウンド応答;および/または、(iv)(顧客のホストへ戻す)アウトバウンド応答であってもよい。いくつかの実施形態にしたがうと、空間をセーブし、処理オーバーヘッドをセーブするために、ある関係するISO8583要求と応答フィールド(例えば、PC/3、STAN/11、RRN/37、RC/39)のみをログ中に表示してもよい。
【0106】
[00117]
取引がSAFされる場合、または、SAFコンテンツが更新される何らかの後続するアクションが起こる場合、このような情報は、ピアノードに中継されるので、両方のノードのSAFコンテンツは、同期したままである。「通常の」複製試行において、このログ記録は、結果として2つのエントリ:(ピアノードへの)アウトバウンド要求と、(ピアノードからの)インバウンド応答であってもよい。エントリは、オリジナルの複製要求、すなわち、要求を処理したノード上のSAFに、アイテムが最初にコミットされるときを表してもよい。
【0107】
[00118]
さらに、外部認可者にSAFするように試行することもログ記録してもよい。これは、結果として2つのエントリ:(外部認可者への)アウトバウンド要求と;(外部認可者からの)インバウンド応答であってもよい。いくつかの実施形態にしたがうと、オリジナルSTANは、一意的なSTANと置き換えてもよい。さらに、チャネルレベルのSAFされた要求は、POS条件コード中の表示「01」を介して、(リアルタイム要求に対して)見分けてもよい。
【0108】
[00119]
ノードが、SAF要求をアンロードするその試行を完了する度に、対応するピアノードに通知されてもよい。例示的なコーディングにおけるさまざまな複製要求フィールドは:(i)39-(ピアのsafMeta.lastRRC列中に記録される)SAF応答において認可者によって戻されるような、応答コード(フィールド39);(ii)105-(ピアのsafMeta. lastAuthid列中に記録される)認可者によって戻されるような、AuthID(フィールド38);(iii)121-(safMeta中で記録を位置付けるために-フィールド123(以下参照)中のノード値とともに-ピアによって使用され、任意のノードペア上で、ノード+tranld はsafMeta内の一意的な識別子である)要求のTranlog ID;(iv)122-(ピアのsafMeta.status列中に記録される)要求のステータス;(v)123-(検索の役割のために上記121を参照する)要求のノード;(vi)125-ピアのsafMeta.attempt列中に記録される)要求に関連する更新された試行カウント;(vii)126-(ピアのsafMeta.lastSent列に記録される)試行の時間;および/または、(viii)127-(ピアのsafMeta.lastStan列に記録される)試行の最後のSTAN、のようなアイテムを含んでいてもよい。
【0109】
[00120]
メイン取引マネージャー(「TM」)の要約も維持してもよい。例えば、リアルタイム取引情報の要約を記録してもよい。このような取引情報は:(i)(外部認可者への)アウトバウンド要求;(ii)(顧客のホストに戻す)アウトバウンド応答;(iii)プロファイラ(各取引参加者において費やされる時間);(iv)外部認可者から受信した遠隔応答コード(「RRC」);(v)SAFチェックに関連するイベント;および/または、(vi)SAF処理が呼び出される場合に、ピアにポストされる複製要求、を含んでいてもよいが、これらに限定されない。
【0110】
[00121]
要約のSAF試行は、(外部認可者への)アウトバウンド要求、(外部認可者からの)インバウンド応答、(各取引参加者において費やされる時間)プロファイラ、(ピアノードへの/からの)複製要求/応答、複製ステータスを含み、記録されてもよく、パッケージングされてもよい。
【0111】
[00122]
ピアノード上では、発起ノード上で発生されるすべてのSAFアクティビティの記録もログ記録されてもよい。これは、「複製要求」によって達成されてもよい。複製TMは、(i)メインTM-SAFにおいて終わるアイテムに対するリアルタイム取引処理の間に(ピアへの)「オリジナル」要求を生成させるかもしれない、(ii)SAF TM-後続するSAFアンロードの間に、ピアへの「更新」要求を発生させるかもしれない、(iii)同期TM-(ピアの停止またはピアからの通信の欠如の後、)発起ノードがピアノードと同期するとき、「オリジナル」または「更新」ピア要求を発生させるかもしれない、ならびに/あるいは、(iv)リトライTM-メインTMからの最初の要求が失敗した場合、「オリジナル」ピア要求を発生させるかもしれない、または、SAF TMもしくは同期TM「更新」ピア要求が失敗した場合、「更新」ピア要求を発生させるかもしれないこと、を含むが、これらに限定されず、発起ノード上の可能性ある生成点から出る複製要求を取り扱ってもよい。
【0112】
[00123]
要求は、「オリジナル」(すなわち、完全SAFエントリ)または「更新」(すなわち、ピアノードは既に記録したことを発起ノードは知っているとの、エントリに関する他の情報またはステータスにおける変更)であってもよい。複製論理は、ISOフィールド3を介して、「更新」から「オリジナル」を見分けてもよい。存在する場合、要求は、「オリジナル」として処理してもよく、存在しない場合、要求は「更新」として処理してもよい。
【0113】
[00124]
高い利用可能性の目的のために、状態制御装置を使用して、2つのノードが同期したままであることを助け、どの他のそれぞれの役割が、動作の何らかの所定点において、必要とされるかを理解する。状態制御装置ログ中で、状態における変化を記録する。
【0114】
[00125]
さらに、ログを通して、フィルタリングを適用してもよい。SAF決定に関連するイベント、SAFイベント、およびHA状態制御を要約するために、「##」タグまたはマーカの存在により、リーダがフィルタをログに適用することを可能にしてもよい。
【0115】
サポート機能
[00126]
ブリッジ顧客は、代理承認ルールを修正するように機能してもよい「アイテムファイル」をインポートすることを選んでもよい。ファイルは、以下のようにカンマ区切り値(「CSV」)フォーマットで構築してもよい(アイテム毎に1つの記録)。
【0116】
【表10】
【0117】
[00127]
ブリッジ顧客は、完全ファイルをFTPすることにより、アイテムファイルインポート処理を開始してもよい。例えば、ファイルは、(「要求」サブディレクトリとしても知られている)Bridge/spool/item_file/requestに提供されてもよい。ファイルの命名規則はイニシエータに残されるが、一般的に、接尾部「.csv」または「.txt」を有していなければならない。これらの接尾部のうちの1つを有していない任意のファイルは無視してもよい。周期的に、-例えば、60秒毎に-ブリッジアプリケーションは、ディレクトリポーリング(「DirPoll」)機構を使用して、新たなインポートファイルの存在をチェックしてもよい。適切に名付けられたファイルが見つかるとき、ブリッジは、処理するために、「要求」サブディレクトリから「実行」サブディレクトリにファイルを動かしてもよい。インポート処理の間、ブリッジは、アイテムファイル入力を使用して、ブリッジ取引処理エンジンによる後続の使用のために同等なデータベーステーブルを構築してもよい。
【0118】
[00128]
インポートの完了に成功すると、ブリッジは、そのアクションを要約するレポートを生成させてもよい。これらのレポートは、「応答」サブ=ディレクトリに置かれてもよい。何らかの不正な形式の入力ファイルを受信する際に、または、処理を通常の完了に満たないように実行させる何らかのイベントの際に、ブリッジは、入力ファイルのコピーを「悪い」サブ-ディレクトリに動かしてもよい。そうでなければ、ブリッジは、適切な完了を実行するファイルを「アーカイブ」サブディレクトリに動かしてもよい。
【0119】
[00129]
ブリッジのオンライン取引処理(「OLTP」)エンジンは、以下の方法で、結果的に得られるアイテムファイルコンテンツを使用してもよい。最初に、以下の条件、(i)ノードが現在「中止モード」である、(ii)同じカードに対して、SAF中に、1つ以上の送り出されない補充アイテムがある、(iii)要求がタイムアウトし、PCがリトライリスト上にある、または、(iv)(「リトライrc」リストにより)要求がソフト拒否を受信し、PCが「リトライpc」リスト上にある、のうちの1つが真であることから、代理承認に対して取引がSAF可能であるか否かを、ブリッジは決定してもよい。
【0120】
[00130]
その後、(a)において特定された条件のうちの1つが真である場合、ブリッジは、取引のUPC(ISO8583フィールド54)がアイテムテーブル上にあるか否かをチェックしてもよく、そうである場合、いずれにせよ、SAT可能アイテムとして指定される。アイテムファイルに基づいて、ブリッジは、以下のように、SAFへの以前の決定を上書きしてもよい。
【0121】
【表11】
【0122】
例外ファイル処理
[00131]
ブリッジは、記憶値カードプロセッサに送るために、例外ファイルコンテンツを生成させてもよい。これらのファイルは、一日あたり複数回生成され、送り出されるようにスケジューリングされてもよい。以下の条件、(i)アイテムが満了した(safMeta.status - 「EXP」)、(ii)アイテムがその最大試行数に達した(safMeta.status - 「MAZ」)、または、(iii)認可者によってアイテムがハード拒否された(safMeta.status - 'TAKEN' and lastRRC <> '00')、のうちの1つが、SATファイル上のアイテムに当てはまる場合、ブリッジは、例外ファイル上にアイテムを置いてもよい。例外ファイルは、パイプ制限フォーマットで構築してもよく、いくつかの実施形態したがうと、ヘッダとトレーラが必要とされる。空のファイルは、詳細な記録を有さないヘッダとトレーラによって表してもよい。しかしながら、空のファイルは、依然として記憶値カードプロセッサに送られてもよいことが企図されていることに留意すべきである。
【0123】
【表12】
【0124】
詳細な記録
【表13】
【0125】
トレーラ記録
【表14】
【0126】
[00132]
ブリッジが例外ファイルを生成させる場合、ファイル名は、ファイル生成の開始における、システムからのタイムスタンプを含んでいてもよく、ファイルが生成された例外ジョブ実行のIDも反映してもよいことに留意すべきである。
【0127】
[00133]
ブリッジは、周期的に動作させてもよい安全なFTP機構を使用して、ファイルを送り出してもよい。ブリッジは、SAFエントリが例外ファイル上に含まれたか否か、そうである場合、どれにかに関して、(抽出された列中の)saf.Metaテーブル上に記録してもよい。以下のテーブルは、例示的なテーブルエントリと意味を図示している。
【0128】
【表15】
【0129】
[00134]
ここで示し、説明した本発明の特定の実施形態は、単なる例であることを理解すべきである。本発明の精神および範囲から逸脱することなく、多数のバリエーション、変更、置換、および、均等物を、当業者は思い付くだろう。したがって、ここで説明し、添付の図面で示したすべての主題事項は、単なる実例とみなされ、意味を限定するものとしてみなされないように意図されている。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[1] 記憶値カード取引をローカルに処理する装置において、
前記装置は、小売ポイントオブセール(POS)またはホストに近接し、
前記装置は、前記POSまたはホストおよび記憶値カードプロセッサと選択的に通信し、
前記装置は、
前記POSまたはホストとの選択的な通信を可能にするPOSまたはホストインターフェースと、
前記記憶値カードプロセッサとの選択的な通信を可能にする記憶値カードプロセッサインターフェースと、
ある記憶値カード取引要求に対する選択的な決定を可能にする処理モジュールとを具備する装置。
[2] 前記記憶値カードプロセッサとの通信の時間の間には、前記処理モジュールは、ある記憶値カード取引要求に対して決定をせずに、このような要求を、前記記憶値カードプロセッサに通過させる[1]記載の装置。
[3] 前記記憶値カードプロセッサとの非通信の時間の間には、前記処理モジュールは、ある記憶値カード取引要求に対してローカルに決定する[1]記載の装置。
[4] 前記処理モジュールと前記記憶値カードプロセッサとの間の通信がいったん再確立されると、前記処理モジュールは、ローカルに行われた取引により前記記憶値カードプロセッサを更新する[3]記載の装置。
[5] 前記記憶値カードプロセッサとの通信の時間の間には、前記処理モジュールは、前記記憶値カードプロセッサから受信した応答に基づいて、前記記憶値カードプロセッサのある決定をローカルに上書きする[1]記載の装置。
[6] 記憶値カードタイプまたは額面金額、取引タイプ、ならびに/あるいは、取引額が、上書きに対して適格であるとして記憶される場合、前記記憶値カードプロセッサは、前記記憶値カードプロセッサのある決定をローカルに上書きするだけである[5]記載の装置。
[7] 前記処理モジュールにより上書きされたある決定は、ソフト拒否である[6]記載の装置。
[8] 前記決定は、アクティブ化、非アクティブ化、リロード、および/または、リフレッシュ取引を含む[1]記載の装置。
[9] いったん前記処理モジュールと前記記憶値カードプロセッサとの間の通信が再確立されると、ローカルに行われた取引により前記記憶値カードプロセッサを更新する記憶および転送モジュールをさらに具備する[1]記載の装置。
[10] 冗長記憶を提供するために、コンテンツ複製アプリケーションと通信する少なくとも2つのデータベースをさらに具備する[1]記載の装置。
[11] 前記装置は、1つ以上のロードバランサまたはマルチプレクサを通して、前記POSまたはホストと通信する[1]記載の装置。
[12] 記憶値カード取引をローカルに認可する方法において、
前記方法は、小売ポイントオブセール(POS)またはホスト、ブリッジプロセッサ、および、記憶値カードプロセッサ間で行われ、
前記ブリッジプロセッサは、前記POSまたはホストとともにローカルに配置され、
前記方法は、
前記ブリッジプロセッサにおいて、取引要求を受信することと、
前記ブリッジプロセッサによって、前記取引要求を、前記記憶値カードプロセッサに通過させるべきであるか否か、または、ローカルに決定させるべきであるか否かを決定することと、
前記取引要求を前記記憶値カードプロセッサに通過させるべきであると決定すると、
このような要求を前記ブリッジから前記記憶値カードプロセッサに通信することと、
前記記憶値カードプロセッサから、または、前記記憶値カードプロセッサとの試行した通信から、ある応答を受信すると、前記ブリッジプロセッサによって、前記記憶値カードプロセッサの応答をローカルに上書きするか、または、前記取引要求をローカルに決定することと、
前記取引要求を前記記憶値カードプロセッサに通過させるべきでないと決定すると、
前記ブリッジプロセッサによって、前記取引要求をローカルに決定することと、
前記ブリッジによって、取引要求応答を前記POSまたはホストへと返通信することとを含む方法。
[13] 前記記憶値カードプロセッサからのある応答は、ソフト拒否またはホストタイムアウトである[12]記載の方法。
[14] 前記ブリッジプロセッサによって、前記取引要求を前記記憶値カードプロセッサに通過させるべきであるか否か、または、ローカルに決定させるべきであるか否かを決定することは、
前記POSまたはホストから要求された取引のタイプを決定することと、
前記取引のタイプにおよび/または記憶値カードに関係付けられている処理コードが、ローカル処理に対して適格であるとしてフラグが立てられているか否かを決定することと、ならびに/あるいは、
前記ブリッジが前記記憶値カードプロセッサと通信しているか否かを決定することとを含む[12]記載の方法。
[15] 前記取引のタイプにおよび/または前記記憶値カードに関係付けられている処理コードが、ローカル処理に対して適格であるとしてフラグが立てられていない場合、前記ブリッジは、パススルーとして機能し、前記取引要求を前記記憶値カードプロセッサに渡し、前記取引要求に対する応答を前記POSまたはホストに戻す[14]記載の方法。
[16] 前記ブリッジが前記記憶値カードプロセッサと通信していない場合、前記記憶値カードプロセッサとの通信が再確立されるまで、前記ブリッジにおいて、少なくともいくつかの取引をローカルに行う[13]記載の方法。
[17] 前記記憶値カードプロセッサから受信したタイムアウトに続いて、前記ブリッジは、前記取引要求をローカルに処理する[12]記載の方法。
[18] 前記ブリッジプロセッサによってローカルに上書きされた、前記記憶値カードプロセッサから受信したある応答は、ソフト拒否である[12]記載の方法。
[19] 記憶値カード取引をローカルに処理する装置において、
前記装置は、小売ポイントオブセール(POS)またはホストに近接し、
前記装置は、前記POSまたはホストおよび記憶値カードプロセッサと選択的に通信し、
前記装置は、
取引要求を受信し、
前記取引要求を前記記憶値カードプロセッサに通過させるべきであるか否か、または、ローカルに決定させるべきであるか否かを決定し、
前記取引要求を前記記憶値カードプロセッサに通過させるべきであると決定すると、
このような要求を前記記憶値カードプロセッサに通信し、
前記記憶値カードプロセッサから、または、前記記憶値カードプロセッサとの試行した通信から、ある応答を受信すると、前記記憶値カードプロセッサの応答をローカルに上書きするか、または、前記取引要求をローカルに決定し、
前記取引要求を前記記憶値カードプロセッサに通過させるべきでないと決定すると、
前記取引要求をローカルに決定し、
取引要求応答を前記POSまたはホストへと返通信し、
ローカルな上書きまたはローカルな決定に続き、前記上書きまたは決定に関する情報を記憶し、いったん通信が再確立されると、このような情報を、前記記憶値カードプロセッサに転送するように構成されている装置。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14