(57)【特許請求の範囲】
【請求項１】
売り物として商品又はサービスを提供する複数の小売商が支出額制限付きカードプログラムに参加するシステムであって、
前記システムは、ポイントオブセールサーバを含む、小売商のインフラストラクチャと選択的に通信し、
前記システムは、
商品又はサービスの製品表を備えるデータ記憶装置と、
前記小売商のインフラストラクチャと選択的に通信する判定プロセッサと、
前記判定プロセッサ及び前記データ記憶装置と選択的に通信するカタログ管理プロセッサと、
を具備し、
前記カタログ管理プロセッサは、前記商品又はサービスの前記製品表から、前記複数の小売商の各々に対する、統一商品コード（ＵＰＣ）の１つ以上のカタログを作成するように構成されており、
前記１つ以上のカタログは、
前記小売商により売り物として提供された前記商品又はサービスのサブセットから作られ、
ナショナルブランド製品に関連付けられたデータを備えるナショナルブランド製品カタログと、
プライベートラベル製品に関連付けられたデータを備えるプライベートラベル製品カタログと、
を具備し、
前記カタログ管理プロセッサは、
購入を要求された製品を識別する情報を受信し、
前記購入を要求された製品のうちの何れが、前記１つ以上のカタログに掲載された製品と一致するかどうかを決定する、
ように構成され、
ここで、前記カタログ管理プロセッサは、前記小売商のインフラストラクチャから受信されたＵＰＣを、前記ナショナルブランド製品カタログ及び前記プライベートラベル製品カタログの両方と比較すること、及び、１つまたは両方のカタログからの一致の検出をするとマーケットバスケットサーバに肯定応答を返送することによって、前記購入を要求された製品のうちの何れが、前記１つ以上のカタログに掲載された製品と一致するかどうかを決定し、
ここで、前記カタログ管理プロセッサによってサーチされた前記プライベートラベル製品カタログは、判定を要求する前記小売商のインフラストラクチャの同一性に基づいて選択される、システム。
【請求項２】
前記１つ以上のカタログの各々は、前記カタログ管理プロセッサと金融取引カードとを使用して、前記支出額制限付きカードプログラムにおいて購入できるものの定義を反映している、請求項１のシステム。
【請求項３】
前記１つ以上のカタログの各々の少なくとも一部分は、健康保険制度に関係付けられているコードに従う、請求項１のシステム。
【請求項４】
前記１つ以上のカタログの各々の少なくとも一部分は、スポンサのガイドラインに従う、請求項１のシステム。
【請求項５】
前記ナショナルブランド製品のカタログは、定期的に更新され、
前記プライベートラベル製品のカタログは、付随する更新により定期的に更新される、請求項１のシステム。
【請求項６】
前記カタログ管理プロセッサは、任意の承認機関の条件に従って、承認されたナショナルブランド製品カタログを生成する、請求項１のシステム。
【請求項７】
前記カタログ管理プロセッサは、健康保険制度と承認機関とに対する代理としての役割を果たす、請求項１のシステム。
【請求項８】
前記カタログ管理プロセッサは、前記複数の小売商のうちの何れかによって提供されたプライベートラベル品目が適格品目のガイダンスの範囲内にあることを保証する、請求項１のシステム。
【請求項９】
前記複数の小売商のうちの各々は、前記ナショナルブランド製品カタログの範囲内にあるプライベートラベル品目のリストを定義し維持する、請求項１のシステム。
【請求項１０】
前記カタログ管理プロセッサは、規制ガイダンスの範囲内に従ったカタログを作成する、請求項１のシステム。
【請求項１１】
前記ナショナルブランド製品カタログと、前記プライベートラベル製品カタログは、作成及び承認の異なる経路を進む、請求項１のシステム。
【請求項１２】
前記カタログ管理プロセッサは、前記ナショナルブランド製品カタログを制御し、
前記複数の小売商のうちの各小売商は、小売商自身のプライベートラベル製品カタログを制御する、請求項１のシステム。
【請求項１３】
前記カタログ管理プロセッサは、前記プライベートラベル製品カタログにおける品目を検査して承認する、請求項１のシステム。
【請求項１４】
前記カタログ管理プロセッサは、特定の製品群についての、ナショナルブランド製品に関連付けられたＵＰＣのリストにアクセスするように構成されている、請求項１のシステム。
【請求項１５】
前記カタログ管理プロセッサは、前記リストを絞り込み、スポンサのガイドラインに合うＵＰＣを含むＵＰＣリストを作成する、請求項１４のシステム。
【請求項１６】
前記カタログ管理プロセッサと小売商との間における通信は、データファイルの形式をとる、請求項１のシステム。
【請求項１７】
連邦政府及び／又は州政府の代わりにヘルスケアプログラムを管理する健康保険制度から購入者に発行される金融取引カード、を更に具備する、請求項１のシステム。
【請求項１８】
対話型音声認識（ＩＶＲ）技術を介してアクティブにされる、購入者が所有している金融取引カード、を更に具備する、請求項１のシステム。
【請求項１９】
前記判定プロセッサは、
スイッチと、
マーケットバスケットの中の品目の妥当性を確認するマーケットバスケット分析サーバと、
プロセス制御サーバと、
を含み、
前記マーケットバスケット分析サーバは、１つ以上の製品カタログに結合され、前記マーケットバスケットの中の適格品目の妥当性を確認するように構成されており、
前記プロセス制御サーバは、前記マーケットバスケットの中の品目の特徴を、前記マーケットバスケット分析サーバと前記スイッチとの間で通信するように構成されている、請求項１のシステム。
【請求項２０】
前記スイッチと、マーケットバスケット分析サーバと、カタログ管理サーバと、プロセス制御サーバは、前記マーケットバスケットの中の品目に対して金融取引の認可を与えるように構成されている、請求項１９のシステム。
【請求項２１】
前記判定プロセッサに結合された金融プロセッサ、を更に具備する、請求項１９のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、２０１０年１２月１３日に出願された米国のシリアルナンバ第６１／４２２，４７１号と、２０１１年５月２６日に出願された米国のシリアルナンバ第１３／１１７，００３号と、２０１１年５月２６日に出願された米国のシリアルナンバ第１３／１１７，０１０号と、の利益に権利を主張しており、これらの全ては、参照によって全体的にここに組込まれている。
【０００２】
本発明は、全体的に、品目リスト、より具体的には、品目毎に一意の識別コードを有する品目リスト、の作成及び管理を容易にするシステムであって、品目リストをスポンサの支払い金融取引カードプログラムに関連付けて、指定された金融取引カードプログラムに関連付けられている支払い金融取引カードを使用して、購入するために提示された品目に支払うことができるかどうかを決定することを含む、システムに関する。
【背景技術】
【０００３】
多くの管理医療提供者（managed healthcare provider）は、処方薬に対する割引をメンバに提供している。しかしながら、一般用医薬品(Over-The-counter drug, OTC drug)に対する割引もメンバに提供している管理医療提供者は、ほんの少数だけである。従って、軽い病気、例えば鼻水及び咳で、メンバが緊急処置室（emergency room）に行くことはよくある。これらの診察を受けに行くことと、多くの場合に、診察を受けに行った際に処方される薬は、一般に非常に費用がかかり、多くの場合に管理医療提供者によって賄われている。
【０００４】
メンバが、ＯＴＣ製品、例えば、ＯＴＣの咳止めシロップ、抗ヒスタミン剤、アスピリン、等に費やす月毎の一定額を与えられると、これらの診察を受けに行くことと、診察を受けに行くことに関連するコストとの多くを無くすことができる。従来は、ＯＴＣの給付金（benefit）をメンバに提供する幾つか管理医療提供者は、メンバに与えられ且つ小売店（retail store）で引き換えられる紙の商品券（voucher）又はフォーム（form）を使用して、これを達成することを試みていた。これらの従来の方法は、手違いを伴うことが多く、これらの方法に関連する報告能力を提供することができなかった。
【０００５】
顧客に対する給付金の引き換え（redemption）を容易にする１つのシステムと方法では、給付金の金融取引カード（financial transaction card）を与える。これは顧客に識別コードを関連付けることを含む。識別コードは、給付金の金融取引カードに記憶されている。識別コードに関連付けられている口座記録にアクセスし、顧客によって購入するために提示された品目（item）が、給付金割引（benefit discount）に適格（eligible）であるかどうかを確認することを決定する。品目が給付金割引に適格であると決定されると、品目に対する適切な割引が計算される。
【０００６】
現在の方法は、小売商に関する複数のエンティティと、管理医療提供者に関係する複数のエンティティとを扱っているが、適格品目のリスト（複数）を作成し、関連付け、管理する、多対多のシナリオ（many-to-many scenario）に特有の複雑さに備えていない。単一の管理医療組織（managed care organization）と、１つの品目リスト及び単一の小売商ブランド(retailer brand)は、かなり簡単である。しかしながら、複数の組織が、複数の小売商で受け入れられた２つ以上の品目リストを有すると、より複雑なシナリオになる。現在の方法を用いると、リスト自体は識別される。しかしながら、提示した支払い又はＩＤ機構に基づいて、ポイントオブパーチェイス（又は購入点、point of purchase）で品目を照合するために、リストの結果として得られる出力（resulting output）が必要であっても、現在の方法は、リストを作成し、関連付け、管理していない。
【０００７】
殆どの米国の健康保険制度（health plan）は、小売店におけるヘルスケア関連品目に対する給付金の補償範囲を設けている。例えば、アレルギー治療薬、感冒薬、鎮痛剤、ビタミン、等を含むが、これらに限られない。
【０００８】
連邦政府は、保健社会福祉省（Department of Health and Human Services）と、より具体的に、メディケアメディケイドセンタ（Centers for Medicare and Medicaid）とを通じて、１つの小売商ブランドに割り当てられる給付資金（benefit fund）の使用を制限している。同時に、品目が全承認リストのサブセットであり、且つそれらが全てのメンバに提供される限り、彼らは、健康保険制度が適格品目の同じリストを提供することを要求していない。
【０００９】
継続的に、どのように適格品目のリスト（複数）を作成し、金融取引カードプログラムに関連付け、管理するかについて、現在の方法は対処していない。現在の方法は、顧客によって購入するために提示された品目が、適格であるか又は不適格であるかを、リストに基づいて決定することに対処しているだけである。リストは、フレックス給付金融取引カード（flex benefit financial transaction card）の例では、管理カード提供者又は雇用者によって与えられる。
【００１０】
メディケア及びメディケイドの給付金は、年間支出の機会（annual spend opportunity）において数十億に相当する。多くの場合に、参加している購入者は、現在のプロセスに関連する複雑さと不便とが原因で、これらの資金を利用していない。店頭での電子的処理の便利さは、より多くの参加している購入者を参加している小売店に動かし、適格製品の販売により小売商の収入を増やす。金融取引カードの所有者は、店のＰＯＳで金融取引カードを使って正規の小売価格を支払う。店は、例えば、薬局のカウンタを含むが、これに限られない。
【００１１】
幾人か（several）の小売商がどの品目を販売しているかを自ら公表し、自身のプライベートラベル品目を適格品目のリストに加えるシステムと方法が必要とされている。更に、幾つかの健康保険制度（又はスポンサ）が、(ｉ)承認されたマスタリストの形式の開始点を有し、（ｉｉ）複数の参加している小売商から品目の照合を閲覧することができ、(ｉｉｉ)そのリストからサブセットを作成することができ、(ｉｉｉ)顧客リストを作成することができ、(ｉｖ)スポンサによって出資された特定の支払い機構と、そのリストを関連付けることが必要とされている。
【発明の概要】
【００１２】
従って、本発明の目的は、提示された品目が、提示された支払い機構(例えば、磁気の金融取引カードを読み取り機に通すこと)によって購入するのに適格であるかどうかを決定する際に、ポイントオブセール（又は販売時点情報管理、point-of-sale）デバイスからの購入時に行われる、品目リストの作成と、関連付けとを自動化するシステムを提供することである。
【００１３】
本発明の別の目的は、特定の品目リスト内におけるどの品目を小売商が販売しているかを知らせることと、小売商自身のプライベートラベル製品をこれらのリストに加えることとを、小売商ができるようにすることである。
【００１４】
本発明の更に別の目的は、スポンサが品目リストを作成し、決済のために品目リストを支払いプログラムに関連付けて、小売商が適格品目をスポンサのメンバに販売することを可能にするシステムを提供することである。
【００１５】
本発明の更に別の目的は、各リストのスポンサが公表の設定を決定できるようにするシステムを提供することである。
【００１６】
本発明のこれらの及び他の目的は、複数の小売商が支払額制限付きカードプログラムに参加するシステムにおいて達成される。小売商のインフラストラクチャは、店の集信装置（store concentrator）と、製品表／価格帳とに結合されたポイントオブセールを含んでいる。判定プロセッサは、小売商に結合されている。カタログ管理プロセッサは、判定プロセッサに結合されたサーバを含んでいる。カタログ管理プロセッサは、参加小売商毎にＵＰＣのカタログを作成する。各カタログは、第１と第２のセットのＵＰＣデータを含む。第１のセットは、ナショナルブランド製品に関し、第２のリストは、小売商のプライベートラベル製品に関する。
【図面の簡単な説明】
【００１７】
【図１−１】小売商のネットワークインフラストラクチャの外部の本発明の１つの実施形態の全体的なシステムのアーキテクチャである。
【図１−２】小売商のネットワークインフラストラクチャの外部の本発明の１つの実施形態の全体的なシステムのアーキテクチャである。
【図２−１】小売商のネットワークインフラストラクチャの内部の本発明の１つの実施形態の全体的なシステムのアーキテクチャである。
【図２−２】小売商のネットワークインフラストラクチャの内部の本発明の１つの実施形態の全体的なシステムのアーキテクチャである。
【図３】本発明の１つの実施形態において使用されているマーケットバスケット分析サーバの動作を示すフローチャートである。
【図４】本発明の１つの実施形態におけるマーケットバスケットの判定を示すフローチャートである。
【図５】本発明の１つの実施形態における判定プロセッサのスイッチの動作を示すフローチャートである。
【図６】カタログを公表するプロセスの流れの実施形態を示している。
【発明を実施するための形態】
【００１８】
複数の小売商が、ポイントオブパーチェイスで提示された品目を、購入者が選択した金融取引の金融取引カードと照合して、提示された金融取引の金融取引カードによって、提示された品目を購入できるかどうかを決定するプロセスを自動化することを容易にするシステムと方法を提供する。より具体的には、本発明では、スポンサに関連付けられている支払い／決済プログラム（sponsor associated payment/settlement program）についての複数の品目リストと、複数の品目との照合を行う。
【００１９】
本発明を用いて、購入者を有する金融取引カードプログラムを実施するシステムと方法を提供する。購入者は、選択した品目を選択した小売商から購入するように制限されている。小売商は、ネットワークコンピュータへ及びネットワークコンピュータからメッセージを通信する能力を有する、ホスト対ホストのプライベートネットワークの一部である。各購入者は、一意の識別コードを有する。一意の識別コードは、選択された品目のリストと、選択された小売商のリストとで対応している。
【００２０】
本発明を用いて、マーケットバスケット（又は買物かご、market basket）を製品カタログと共に利用することを可能にする判定プロセスを実施するシステムと方法を提供する。各カタログは、統一商品コード(universal product code, UPC)のリストを含み、各々は、金融取引カードによって購入できる品目を識別する。財布は、金融取引カードに関連付けられている金融口座に対する識別子である。非制限な例として、金融口座は、銀行口座、クレジット金融取引カード、デビット金融取引カード、プリペイド金融取引カード、第三者の資金源、等であり得る。非制限的な例として、金融取引カードは、クレジット金融取引カードと、デビット金融取引カードと、ギフト金融取引カードと、送金金融取引カードと、他のタイプの支払いを認証（authenticating）するものであって送金できるもの、等のうちの少なくとも１つから選択される、金融取引カードであり得る。１つの実施形態では、金融取引カードは、デビット又はクレジット金融取引カードを含むが、これに限られず、複数の金融取引機関又は財布を有する。更に、金融取引カードは、１つのみの支出用の財布を有することができる。マーケットバスケットの中の品目は、１つ以上の関連するカタログに照らして判定される。
【００２１】
図１に示されているように、判定プロセッサ１０は、マーケットバスケット分析サーバ１２と、プロセス制御サーバ１４と、スイッチ１６と、製品カタログ１８と、購入者の口座データ２０とを含む。
【００２２】
より全体的に、図１において、２２として示されている小売商のインフラストラクチャは、小売商：ＰＯＳインレーン（POS In Lane）２４（以下、小売商２４)を含んでいる。小売商２４は、バーコードスキャナ２８を有するポイントオブセールサーバ(ＰＯＳ)２６を含んでいる。ＰＯＳ２６は、店の集信装置３０と製品表／価格帳３２とに結合されている。小売商の製品チーム（retailer product team）３４は、製品表／価格帳３２と通信し、カタログ管理サーバ３６へ通信する。小売商の製品チーム３４は、小売商：ＰＯＳ  Ｏｐｓ３８の一部である。
【００２３】
カタログ管理サーバ３６は、カタログ管理プロセッサ４０に含まれている。小売商のインフラストラクチャ２２は、小売商のスイッチ４４を有する小売商のネットワーク４２を更に含んでいる。
【００２４】
小売商のスイッチ４４は、判定プロセッサ１０に結合されている。後述でより十分に記載するように、マーケットバスケット分析サーバ１２は、製品カタログ１８に結合され、マーケットバスケットの中の適格品目の妥当性を確認する。マーケットバスケットの内容は、ＵＰＣ、価格、量、等を含むが、これらに限られない。マーケットバスケットの内容は、小売商のスイッチ４４から、マーケットバスケット分析サーバ１２とスイッチ１６との間で通信される。カタログ管理サーバ３６は、マーケットバスケット分析サーバ１２と製品カタログ１８の形式で通信する。
【００２５】
金融取引の金融取引カード発行者(以下、金融プロセッサ４６)は、判定プロセッサ１０に結合されており、金融取引カード番号４８と、発行者プロセッサ(取引)５０とを含んでいる。
【００２６】
給付金プロセッサ５２は、スイッチ１６に結合された支払請求プロセッサ（アキュムレータ)５４を含んでいる。給付金プロセッサ５２は、スイッチ１６と通信する。マーケットバスケット分析サーバ１２は、スイッチ１６を介して給付金プロセッサ５２とリアルタイムで接し（contact）、支払請求の認可（claim authorization）を受け取ることができる。給付金プロセッサ５２は、標準の規定言語と、ＮＣＰＤＰ５．１と、ＮＣＰＤＰｄ．０とを介して通信することができる。
【００２７】
口座情報５６は、購入者の口座データ２０を含んでいる。購入者の口座データ２０は、マーケットバスケット分析サーバ１２に与えられる。購入者の口座データ２０は、金融プロセッサ４６に属する金融取引の金融取引カード番号４８に関係している。金融プロセッサ４６は、発行者プロセッサ５０（取引）を含んでいる。金融承認取引（financial approval transaction）が要求されると、発行者プロセッサ５０は、スイッチ５８と、更にスイッチ１６と通信する。
【００２８】
既に記載したように、本発明は、複数の小売商が、購入者が選択した支払機構を使って購入するためにＰＯＳ２６において提示された品目を照合し、提示された支払い機構によって、提示された品目を購入できるかどうか決定するプロセスを自動化することを容易にする。より具体的には、本発明は、スポンサに関連付けられている支払い／決済プログラムのための複数の品目リストと、品目とを照合する。
【００２９】
図２の実施形態では、判定プロセッサ１０は、小売商のインフラストラクチャ２２に含まれている。図２の実施形態における全体的なシステムのアーキテクチャは、小売商のプロセスと通信するスイッチ５８を含み、これが小売商のファイアウォールを支えている。
【００３０】
判定プロセスは、判定プロセッサ１０におけるコンポーネントを利用する。スイッチ１６と、マーケットバスケット分析サーバ１２と、カタログ管理サーバ３６と、プロセス制御サーバ１４は、協力して、判定を行う。更に、１つの実施形態では、判定プロセスは、金融取引を認可することができる。
【００３１】
小売商のインレーン購入動作によってトリガされる金融取引は、一般に、小売商のスイッチ４４からスイッチ１６にＩＳＯ８５８３の形式で通信される。スイッチ１６は、ＩＳＯ８５８３のメッセージを、次の処理コンポーネント、例えばマーケットバスケット分析サーバ１２、による処理に適したメッセージに分解する。
【００３２】
１つの実施形態では、スイッチ１６は、マーケットバスケットの内容のデータと取引識別情報とを、スイッチ１６によって解析（parse）されフォーマットされたデータ形式で、マーケットバスケット分析サーバ１２に通信する。
【００３３】
マーケットバスケット分析サーバ１２は、マーケットバスケットの内容と、製品カタログ（複数）１８とを比較する。製品カタログ（複数）１８は、カタログ管理サーバ３６から、マーケットバスケット分析サーバ１２に、予めロードされている。製品カタログ１８は、承認された製品の品目リストを含んでいる。承認された製品は、ＵＰＣと短い記述（short description）とによって識別される。マーケットバスケットのライン品目の内容のデータは、マーケットバスケットサーバ１２によって繰り返し処理される。
【００３４】
本発明を用いて、複数のカタログ１８に対する判定を処理することができる。本発明を用いて、カタログ１８を口座の財布に直接に関係付ける。品目リストを判定するために使用されるカタログ１８に基づいて、この財布を制限付きの支出額に関連付けることができる。例えば、金融取引の金融取引カードは、食品の品目カタログと、更に一般用医薬品の品目カタログとに対する支出をサポートし得る。１つ以上の支出用の財布は、単一の金融取引の金融取引カードに対して識別され得る。支出用の財布の各々は、特定の発行者からの特定の支出残高（spending balance）を有する。
【００３５】
本発明を用いて、小売商２４は、マーケットバスケットを集め、購入者の金融取引の金融取引カードを読取り機に通す又はスキャンすると、マーケットバスケットをパッケージ化し、それを判定プロセッサ１０に送り、(ｉ)小売商が購入要求を処理するか、又は(ｉｉ) 判定プロセッサが購入要求を処理する。小売商２４と判定プロセッサ１０との間における入ってくる及び出ていく通信は、ＩＳＯ８５８３のメッセージフォーマット、ＸＭＬウェブサービスフォーマット、等を介して、リアルタイムのやり取りとして全て可能である。非制限的な例として、モバイルデバイスに結合されたカード読取り機のスロット、モバイルデバイスのスロットに金融取引の金融取引カードを通すことと、ワイヤレス通信を通じてスキャンすることと、金融取引の金融取引カードをモバイルデバイスにタッチすることと、モバイルデバイスにおいて情報をタイプ入力することと、写真を撮ることと、モバイルデバイス上のアプリケーション及びオンラインエンティティから金融取引の金融取引カードを選択することと、のうちの少なくとも１つによって入力することができる。
【００３６】
図１と２に示されているように、小売商は、小売商のスイッチ４４と通信する。小売商のスイッチ４４は、取引データを判定プロセッサ５０に送り込む。スイッチ１６は、取引を受信し、それを最後まで処理する。スイッチ１６は、全てのタイプの取引に対するゲートウエイである。取引（又はトランザクション）は、多くのタイプのうちの１つであり得る。本発明の１つの実施形態では、取引は、判定要求、認可要求、又はＰＯＳ結果取引であり得る。スイッチ１６は、取引要求５６の性質を決定し、データをフォーマットし、要求のタイプによって決定される次のプロセスを通して、要求をルーティングする。
【００３７】
図３は、マーケットバスケットサーバ１２の動作を、ステップ６０−８０を使って説明するフローチャートである。マーケットバスケット分析サーバは、マーケットバスケットの取引データをスイッチ１６から受信し、マーケットバスケットの取引が有効であるかどうかを決定する。それが有効でない場合は、処理要求は拒絶される。それが有効である場合は、マーケットバスケットサーバ１２は、処理制御データから取引の信用証明書（credential）を検索する。信用証明書が有効でない場合は、処理要求は拒絶される。信用証明書が有効である場合は、マーケットバスケットに適切な品目があるかどうかを確かめることを決定する。ない場合は、処理を要求することなく返送する。ある場合は、認可を要求し、次に、要求される処理と共に返送する。
【００３８】
判定取引（adjunction transaction）は、取引の識別と、マーケットバスケット情報をフォーマットしてマーケットバスケットサーバプロセスに送ることを含む。認可取引(authorization transaction)は、取引の識別を含み、特定の金融支払い口座(財布)に対して金融上の認可（financial authorization）を要求する。結果の取引は、取引識別情報と、処理されたマーケットバスケット判定取引(特定の財布とカタログとに対してマーケットバスケット品目にフラグを立てる)と、金融認可情報とを含んでいる。
【００３９】
マーケットバスケットサーバ１２は、スイッチ１６から判定取引を受信する。マーケットバスケットサーバ１２は、全ての金融取引の金融取引カードを可能な範囲まで処理し、要求に応じて、更なる処理のために取引結果をスイッチに返送する。スイッチ１６は、判定取引を受信し、更なる処理が必要であるかどうかを決定する。判定取引は、スイッチ１６が１以上の発行者から金融取引の認可を取得することを要求し得る。ルーティングと、発行者による処理のために、スイッチ１６は取引情報をフォーマットする６０。
【００４０】
認可要求（複数）が発行者（複数）によって処理されて返送されるまで、スイッチ１６は、小売商２４に対する取引を完了するのを待つ。認可情報は、フォーマットされ、小売商２４に返送される。その取引は、スイッチ１６を通った全ての取引の永久データログに加えられる。スイッチ１６は、ＰＯＳ結果取引をフォーマットし、小売商２４に返送する。その取引は、スイッチ１６を通った全ての取引の永久データログに加えられる。
【００４１】
ステップ８２乃至１１２を有する図４のマーケットバスケットの判定フローチャートを参照すると、マーケットバスケット分析サーバ１２とスイッチ１６とを使用して、マーケットバスケットの品目リストが受信される。マーケットバスケットが使い尽くされる（exhaust）と、品目を合計し、マーケットバスケットを閉じ、注釈を付けられた（annotated）マーケットバスケットを作成する。それが使い尽くされていない場合は、マーケットバスケットからの品目と、インデックスの付いたカタログの品目とを比較する。カタログの品目と一致しない場合は、カタログ１８が使い尽くされていて、インデックスがインクリメントされる。さらにまた、カタログ１８が使い尽くされていないと、マーケットバスケットのリストのインデックスがインクリメントされ、品目にフラグが立てられる。
【００４２】
スイッチ１６の動作が、図５においてステップ１１４乃至１３４に示されている。スイッチ１６は、取引から得た取引データを受信し、変換する。スイッチ１６によって、取引のタイプについて決定する。取引が判定である場合に、マーケットバスケットはフォーマットされる。ＰＯＳ以外（POS-OUT）の取引の場合は、それはＰＯＳのためにフォーマットされる。次に、スイッチ１６は、認可を行ない、金融プロセッサ４６のために取引をフォーマットし、次に、認可のために５０８を発行者にルーティングする。認可メッセージ５０９は、金融プロセッサ４６から受信される。スイッチ１６は、これをフォーマットし、小売商のスイッチ４４を介して小売商２４に返送する。次に、取引が取引ログにログインされる。
【００４３】
複数の財布に対して、複数の認可がある。複数の認可がある場合に、スイッチ１６は複数の金融プロセッサ４０に結合するように構成されている。スイッチ１６は、複数の金融処理システムに結合し、複数の発行者プロセッサに結び付けられた複数の財布に照らして、制限付きの支出を処理することができる。プロセス制御サーバ１４によって提供されるルールに基づいて、スイッチは、金融取引を複数の金融の金融取引カード発行者に分けて、複数の金融プロセッサから認可を受ける。
【００４４】
本発明を用いて、マーケットバスケット分析サーバ１２は、ＨＩＰＡＡとＰＣＩ−ＤＳＳの規制遵守（regulatory compliance）に対する依存から、購入者の金融口座情報を切り離す。
【００４５】
小売商２４は、複数の財布、複数の金融取引の金融取引カード発行者のメンバの人口統計、等の詳細から切り離される。取引のＰＡＮは、適用可能なプロセス制御ルールを定めている口座構造に結び付いている。プロセス制御ルールは、プロセス制御サーバ１４からスイッチ１６に与えられ、金融認可の経路を確立する。マーケットバスケット分析サーバ１２が、財布と共にカタログを使用するために、金融取引の金融取引カード番号４８と、関連するカタログ１８とが、その金融取引の金融取引カードと共に与えられる。
【００４６】
判定プロセッサ１０は、小売商のメンバの人口統計を送らない。マーケットバスケット分析サーバ１２が、ＰＡＮに関係付けられているカタログと、金融取引の金融取引カード発行者と、財布とを使用するために、金融取引の金融取引カード番号４８と、その金融取引の金融取引カードに関連するカタログ１８が与えられる。
【００４７】
本発明を用いて、次のステップが行なわれる。
【００４８】
品目データを集めたもの、例えばマーケットバスケットを受信する。マーケットバスケットの中の各品目は、品目を一意に識別する統一商品コード(ＵＰＣ)を有し、小売商の価格リストによって決定される追加税と、正味価格と、品質とを有する。
【００４９】
マーケットバスケットの中の各品目は、評価され、製品／計画製品カタログ１８に関係付けられている特定の財布に対して承認された品目とＵＰＣによって比較される。マーケットバスケットの中の各品目は、特定の製品／計画に対して適格又は不適格としてマークを付される。適格品目は、製品／計画に従ってグループ化され、グループ毎に、全ての品目の合計コストから、適切な割引（discount）と値引（allowance）とを除く計算をする。小売商２４、給付金プロセッサ５２、等によって更に処理するために、品目と、グループの合計と、マーケットバスケット識別情報とを、ＸＭＬデータ構造、ＩＳＯ８５８３、ＮＣＰＤＰ５．１、又はＮＣＰＤＰｄ．０にフォーマットする。
【００５０】
判定は、小売商２４でホストされ、小売商の内部であってもよく、又は判定は、小売商の外部でホストされ、幾つかの小売商をそれに接続してもよい。
【００５１】
ＸＭＬデータ構造をスイッチ１６に送り込む。スイッチ１６を利用し、小売商のネットワーク内でホストされているシステムのための小売商別フォーマットのデータを、発行者プロセッサ５０又は支払請求プロセッサ５４によって処理するために、ＩＳＯ８５８３、ＸＭＬ、ＮＣＰＤＰ５．１、又はＮＣＰＤＰｄ．０のフォーマットに変換する。金融プロセッサが内部の小売商のネットワークに統合されていない場合と、小売商が本発明によって開始される取引を要求する場合に、ＸＭＬベースの金融認可要求又はＩＳＯ８５８３ベースの金融認可要求が開始される。この場合に、本発明のプロセス制御サーバ１４のシステムと方法は、グループの合計に照らして認可要求の内容を決定し、スイッチ１６は、ＸＭＬベースの認可要求を構築し、金融プロセッサ４６に伝送する。スイッチ１４は、ＸＭＬベースの認可要求を、対応する発行者プロセッサによって要求されるフォーマットでフォーマットする。
【００５２】
購入者によって選択され且つマーケットバスケットに入れられた品目は、購入するために、参加している小売商２４の清算プロセス（check out process）に提示される。プロセスの中でもとりわけこのプロセスは、小売店内の物理的なレーン（physical lane）、カタログから選択され且つ精算時に購入者によって識別されるマーケットバスケットの品目の収集、或いは小売店、オンライン、又は電話に基づく薬局のカウンタにおける処方箋の提示であり得る。
【００５３】
小売商の物理的な清算レーン又は小売商の物理的な薬局カウンタを使用するプロセスでは、そのマーケットバスケットの品目を、小売商の店のＰＯＳ２６に手入力するか又はスキャンすることが必要である。カタログ１８、オンライン、又は電話による買い物を使用するプロセスでは、品目を買物の方法によって選択して識別し、マーケットバスケットの中の品目として入力することが必要である。
【００５４】
買物の方法に関わらず、全てのマーケットバスケットの品目のデータ、例えば、価格、量、税金、ポイントオブパーチェイスで行なわれる割引を、１つの取引にパッケージ化し、店のポイントオブセールシステムのメッセージの詳細に従ってフォーマットする。更に、１つの取引は、小売商の識別情報と、購入者の識別情報とを更に含まなければならない。これは、最低でも、以下を含み得る。
【００５５】
１．小売商のＩＤ
２．店のＩＤ
３．端末のＩＤ
４．主要口座番号（Primary Account Number, PAN）
５．タイムスタンプ
６．システム追跡記録監査番号（System Trace Audit Number, STAN）
７．ライン品目の詳細＜一意のマーケットバスケット品目毎＞
ａ．ＵＰＣ
ｂ．正味価格
ｃ．税金
ｄ．量
ｅ．品目の簡単な説明
この取引は、ＰＯＳ２６から、店の集信装置３０、小売商のスイッチ４４、次にスイッチ１６に届く。取引データは、品目データ、顧客識別子(金融取引の金融取引カード番号)データ、等を含むことができる。小売商２４を介して、店の集信装置３０、小売商のスイッチ４４に通信される。小売商２４の全てがネットワークに接続され、データは、小売商のスイッチ４４から、小売商２４、次に、小売商の内部の別のスイッチに進む。スイッチ１６は、小売商のスイッチ４４、又は様々な方法で小売商２４に通信する内部の小売商のスイッチを利用する。様々な方法は、例えば、ＩＳＯ８５８３又はＸＭＬデータ構造を含むが、これに限られない。
【００５６】
取引データは、送信元の小売商２４から受信される。マーケットバスケットの取引は、マーケットバスケットサーバ１２からスイッチ１６に送られる。スイッチ１６は、受信したどんな小売商構造からのデータも、ＸＭＬデータ構造にデータをフォーマットし、変換されたＸＭＬ構造をマーケットバスケット分析サーバ１２に伝送する。
【００５７】
マーケットバスケット分析サーバ１２は、ＰＡＮを利用し、購入者の口座に対する財布とカタログ１８とを決定する。判定又は金融取引の処理中におけるどの時点においても、購入者の個人情報は検索されない。購入者のＰＡＮは、１つ以上の特定の製品カタログを、マーケットバスケットの取引に関係付ける。
【００５８】
購入者の識別子、例えば、金融取引の金融取引カードの口座番号(ＰＡＮ)が、スイッチ１６によって認識されない場合は、エラーが発生し、拒絶される。ＰＡＮにエラーがある場合は、取引が断わられたというメッセージを、スイッチ１６が送信元の小売商２４に返送する。
【００５９】
スイッチ１６は、マーケットバスケットの取引で受信した品目データを、一度に１品目ずつ照合する。スイッチ１６は、２つのインジケータを、マーケットバスケットの各ライン品目に付加する。品目が適格であるか又は不適格であるかを通信するフラグを生成し、更に、品目が属するグループ(カタログ)１８のインジケータを決定する。
【００６０】
処理の完了時に、マーケットバスケットの中の各品目と、各グループによる合計とを使用して、マーケットバスケットの取引をパッケージ化し、処理のために小売商２４に返送する。別の実施形態では、処理されたマーケットバスケットの取引をスイッチ１６に返送する。
【００６１】
処理されたマーケットバスケットの取引を受け取ると、マーケットバスケット分析サーバ１２は、購入者の識別子に関連付けられている金融取引の金融取引カード発行者に対して、購入者の識別子を照合する。
【００６２】
スイッチ１６は、ＸＭＬベースの支払い認可要求メッセージを作成する。ＸＭＬベースの支払い認可要求メッセージは、金融プロセッサ４６の識別と、小売商の取引の識別の情報を含んでいる。次に、この支払い認可は、金融プロセッサ４６に送られる。様々な実施形態では、ＩＳＯ８５８３と、ＸＭＬと、ＮＣＰＤＰｄ．０のデータ構造を、スイッチ１６と金融プロセッサ４６との間における認可要求メッセージに使用する。
【００６３】
様々な実施形態において、スイッチ１６は、(ｉ)金融プロセッサ４６又は支払請求プロセッサ５４から返送された認可メッセージを受信し、(ｉｉ)取引識別番号に基づいて認可された取引のデータログを作成し、（ｉｉｉ）認可メッセージを適切なフォーマットで作成し、そのメッセージを小売商２４に送る。
【００６４】
本発明の別の実施形態では、カタログ管理プロセッサ４０は、参加している小売商２４毎にＵＰＣのカタログ１８を作成する。各カタログ１８は、第１と第２のセットのＵＰＣデータを含んでいる。第１のセットは、ナショナルブランド製品に関し、第２のセットは、小売商２４のプライベートラベル製品に関する。
【００６５】
本発明のシステムと方法は、インコム（inComm）の小売商２４が、スポンサが扱っている製品に対して、ポイントオブセールにおける金融取引カードに基づく支払い方法を受け入れることを可能にする。製品は、薬品と医療用品とを含むが、これらに限られない。スポンサは、メディケア及び／又はメディケイドを含むが、これらに限られない。本発明は、小売商２４のＰＯＳ１８と相互に動作しない、人手による（manual）支払請求又はオフラインシステムを従来含んでいた引き換え方法に代わることができるシステムと方法を提供する。
【００６６】
幾つかの場合において、金融取引カードの受理／引き換え機構（acceptance/redemption mechanism）は、取引の処理のための既存のＰＯＳからインコムへのメッセージングインターフェイスを強化する（leverage）。
【００６７】
様々な実施形態では、本発明は、あるスポンサが彼らの組織に特有のリストを作成し、従って、小売商２４へのリストの公表を制限することを可能にする、システムと方法とを提供する。他のスポンサは、彼らのリストを公表し、カタログ管理サーバ内で利用可能にすることを選ぶことができる。これは、他のスポンサが、既に作成されたリストを選択することを可能にする。非制限的な例として、ある州のメディケイドプログラムが、予防カード（preventive card）に焦点を当てたリストであって、ビタミンと低用量のアスピリンで埋められたリストを作成し、他の州が予防カードに最も有効な品目を識別する労力を利用できるようにすることを選ぶことができる。
【００６８】
１つの実施形態では、金融取引カードは、小売商のＰＯＳ取引を通じてアクティブにされることも、購入されることもない。金融取引カードは、連邦政府と州政府との代わりに、メディケアとメディケイドとを管理する健康保険制度（health insurance plan）によって購入者に発行される。１つの実施形態では、購入者は、電話及び対話型音声認識技術（Interactive Voice Recognition technology）を介して金融取引カードをアクティブにする。スポンサによって定められている適格小売品目又はサービスに支払うために、参加している小売商２４において金融取引カードを使用することができる。これらの適格小売品目は、例えば、一般用医薬品（over the counter medicine）と医療用品とを含むが、これらに限られない。
【００６９】
１つの実施形態では、ＵＰＣのカタログ１８は、参加している小売商２４毎に作成され維持される。カタログ１８は、２セットのＵＰＣデータから構成されている。一方のセットは、ナショナルブランド製品に関し、他方のセットは、小売商２４のプライベートラベル製品に関する。カタログ１８は、カタログ管理プロセッサ４０／インコム金融取引カードを使用して購入できるものの定義を反映している。カタログ１８は、スポンサからの公表されたガイドラインに従わなければならない。スポンサは、メディケアメディケイドサービスセンタ(Centers for Medicare and Medicaid Service, CMS)を含むが、これに限られない。
【００７０】
カタログ１８は、ナショナルブランドのカタログ１８と、プライベートラベルのカタログ１８への小売商２４による付随する（concomitant）更新とへ定期的に更新される。カタログ管理プロセッサ４０は、承認機関の条件に合う、承認されたナショナルブランドのカタログ１８を生成する。カタログ管理プロセッサ４０は、健康保健制度と承認機関の代理として、小売商２４によって提示されたプライベートラベル品目が適格品目のガイダンス（guidance）の範囲内にあることを保証することに責任を負う。小売商２４は、ナショナルブランドのカタログ１８の範囲内にある、その小売商２４のプライベートラベル品目のリストを定義し維持することに責任を負う。カタログ管理プロセッサ４０は、健康保健制度において、小売商２４によって提示された全てのプライベートラベル品目がガイダンスの範囲内で承認されていることを保証することに責任を負う。１つのプロセスの流れを使用して、最初のカタログ１８を公表し、次に、それを進め続ける。
【００７１】
カタログ管理プロセッサ４０によるカタログ１８の最初の構築は、所定の製品群についてのナショナルブランドのＵＰＣの完全なリストから始める。カタログ管理プロセッサ４０は、このリストを絞り込む。１つの実施形態では、これは、カタログ管理プロセッサ４０によって単独で行われる。別の実施形態では、これは、プロセッサ４０と、承認しているスポンサ又は代理業者（agency）、例えば、ＣＭＳのガイダンスに合うＵＰＣのみを含むものと、の両者で達成される。
【００７２】
ナショナルブランドのカタログ１８と、プライベートラベルのカタログ１８は、異なる経路に従って承認される。カタログ管理プロセッサ４０は、ナショナルブランドのカタログ１８を制御するが、小売商２４は、彼らのプライベートカタログ１８を制御する。カタログ管理プロセッサ４０は、健康保健制度又は承認機関に対する代理として、プライベートラベルのカタログ１８の中の品目を検査（review）して承認する。
【００７３】
小売商２４とカタログ管理プロセッサ４０との対話は、データファイルの形式をとることができ、データファイルは、提案と、承認と、公表との様々な段階で交換される。図６は、カタログ１８を公表するプロセスの流れを示している。
【００７４】
カタログ１８の最初の公開に続いて、定期的に、例えば四半期毎に、メンテナンスが公開される。メンテナンスを公開する目的は、追加の製品を入れるか、古い製品を取り除くか、又は特定のＵＰＣに関係する情報を変更するために、ナショナルブランドのカタログ１８を調整することである。ナショナルブランドのカタログ１８の内容が変化すると、それはプライベートラベルのカタログ１８の内容に影響を及ぼし得る。従って、ナショナルレベルにおける変化が、プライベートラベルのレベルにおける変化として反映されることを保証するために、検査プロセスが必要である。
【００７５】
小売商２４は、現在から、最後のカタログ１８の公開の選択された期間、例えば９０日以内まで、更新を順番に処理する。非制限的な例として、各四半期の最初の日以前に小売商２４によって処理して統合するために、四半期毎に、即ち、四半期（１月、４月、７月、１０月）の４５日前に、カタログ１８が公開される。小売商２４が途中で加加わった場合は、更新の最初のサイクルに対して例外が許される。最初の更新サイクルのときのみ、小売商２４は、初期設定を更新する前に、１サイクルの間待つことを選んでもよい。例えば、小売商２４は、５月１日に加わり、４月に始まる四半期に対して、２月１５日からカタログ１８を取り入れる。次のカタログ１８の更新は、５月１５日に公開されるが、小売商２４は、一回限りのこと（one-time event）として、このサイクルをスキップしてもよい。しかしながら、将来のカタログ１８の公開は、９０日前に取り入れる。
【００７６】
プライベートラベル品目に関して、例１は、四半期プロセスの１つの実施形態である。
【表１】
0005872584.tif 000002
【００７７】
カタログ管理のプロセスにおける各ステップ中に、カタログ管理プロセッサ４０と小売商２４は相互に通信する。１つの実施形態では、ファイル転送プロセスは、ＳＦＴＰ(ＳＳＨを通じてのＦＴＰ)による。小売商２４は、転送されるデータファイルを配置し検索するために、カタログ管理プロセッサ４０のＳＦＴＰサーバにおけるＳＦＴＰアドレスと一意のディレクトリとを与えられる。ファイルは、小売商２４によってＳＦＴＰサイトに送り込まれ、ＳＦＴＰサイトから引き出される。
【００７８】
カタログ管理プロセッサ４０は、小売商２４のＳＦＴＰディレクトリに配置されたファイルを、定期的に、非制限的な例として２時間毎等に、自動的にスキャンし処理することができる。
【００７９】
例２は、カタログ管理プロセッサ２４のフォルダ構造の例である。他のフォルダ構造が利用され得ることが分かるであろう。
【００８０】
例２
カタログ管理プロセッサのフォルダ構造
（サービスの最初にカタログ管理プロセッサ４０によって小売商に提供される）／Ｐｒｏｄｕｃｔｉｏｎ
（小売商から送られるファイルに対して）／ｉｎ
（小売商に送るファイルに対して）/ｏｕｔ
本発明は、様々なファイルネーミング規定を用いることができる。例３は、特定の実施形態であり、他を用いてもよい。
【００８１】
例３
ファイルネーミング規定
ファイルネーミング規定
現在使用されている一般的なフォーマットは、次の形式をとる。
【００８２】
「＜ＭＲＩＤ＞＜ｆｉｌｅ ｔｙｐｅ＞ ＜ｆｉｌｅ ｓｔａｔｅ＞ ＜ｆｉｌｅ ｎｕｍｂｅｒ＞ ＹＹＹＹＭＭＤＤＨＨＭＭＳＳ．ｔｙｔ」
ここで、「ＭＲＩＤ」は、小売商２４に対してカタログ管理プロセッサ４０によって割り当てられた３文字の指示子（designator）である。
【００８３】
「ｆｉｌｅ ｔｙｐｅ」は、ファイルのタイプを表わす３文字以下の指示子である。
【００８４】
「ｆｉｌｅ ｓｔａｔｅ」は、１文字の指示子である。ここで、「Ｓ」は、ファイルを小売商２４からＭＧへの送信（submission）として定義し、「Ｒ」は、ファイルをカタログ管理プロセッサ４０から小売商２４への返送（return）として定義する。
【００８５】
「ｆｉｌｅ ｎｕｍｂｅｒ」は、ファイルの内容の範囲を識別するために使用される一意の５文字の指示子である。
【００８６】
「ＹＹＹＹ」は、４ケタの年を表わす。
【００８７】
「ＭＭ」は、年の中の月を表わす。
【００８８】
「ＤＤ」は、月の中の日を表わす。
【００８９】
「ＨＨＭＭＳＳ」は、日の中の時間と、分と、秒とを表す。
【表２】
0005872584.tif 000003
【００９０】
ファイル及びデータフォーマットの規定−カタログ管理プロセッサ４０と小売商２４との間で転送されるデータファイルは、様々な規定に従うことができる。様々な規定は、以下に記載された規定を含むが、これらに限られない。
【００９１】
ファイル及びデータフォーマットは、ＡＳＣＩであり得る。ファイル内のフィールドは、パイプ「｜」の符号によって区切られる。
【００９２】
・ファイル構造−ファイルは３つのレコードタイプを有し得る。
【００９３】
・品目ヘッダレコード（Item Header Record）:タイプ「ＨＤＲＤ」。
【００９４】
・品目レコード（Item Record）:ファイルのタイプ毎に指定される。
【００９５】
・チェックサムレコード(Check Sum Record):タイプ「ＣＨＫＳ」。チェックサムレコードは、ファイルの最後のレコードである。ほとんどの場合に、チェックサムは、単にレコードの総数である。
【００９６】
・ＣＱＵの場合に、レコードタイプ「ＦＩＬＥ」を有するファイルのヘッダレコード。
【００９７】
復帰（carriage return）と改行（line feed）−ファイル内の全てのレコードは、復帰と改行で終わることができる。
【００９８】
フィールドタイプ−「Ｍ」＝金額（Money）、「Ｄ」＝日付(Date）、「Ｎ」＝数値（Numeric）、「Ａ」＝英数字（Alphanumeric）
金額フィールド−数値フィールドは、実際の小数点を含み、２桁の小数部を有することができる。即ち、「９９９９９．９９」である。これらは、符号の付いた数であり得る。即ち、正の数は符号を有しておらず、負の数はマイナス符号を有している。
【００９９】
日付フィールド−日付フィールドは、次のフォーマットで送ることができる。即ち、ＭＭ／ＤＤ／ＹＹＹＹである。
【０１００】
数値フィールド−数値フィールドは、左揃えであり得る。即ち、９９９９９．９９である。
【０１０１】
英数字フィールド−英数字フィールドは、左揃えであり、先頭のブランクを取り除くことができる。
【０１０２】
最大長(Maximum length, Max Len)−これらは、フィールド長に対して許される最大文字数を指定する。
【０１０３】
必須（Required, Req’d）−「Ｙ」は、必須に等しく、データが含まれていない場合は、レコードが無効であると見なすことができる。「Ｎ」＝不要（not required）。
【０１０４】
ファイル名−以下は、使用できる３つのファイルの名前である。
【０１０５】
１．ファイルタイプ名:ＣＱＵ−カタログ管理プロセッサ４０は、マスタカタログ１８を公表する。マスタカタログ１８は、定期的な、例えば四半期毎の、全てのアクティブなナショナルブランドの品目を含んでいる(「カタログ１８」)。ＣＱＵは、所定の１組の健康保健制度の条件に合ったナショナルブランドのＵＰＣコードの全てを含んでいる。
【０１０６】
２.ファイルタイプ名:ＣＱＲ−小売商２４は、マスタカタログ１８(ＣＱＵ)を検査し、カタログ管理プロセッサ４０によって検査される小売商２４自身のプライベートラベル製品のＣＱＲカタログを作成する。カタログ管理プロセッサ４０は、承認又は否認で応答する。
【０１０７】
３．ファイルタイプ名:ＣＱＰ−小売商２４は、最終的なプライベートラベルとナショナルブランドの品目を、１つのデータファイルに統合し、カタログ管理プロセッサ４０による承認を得るために、このファイルを送信する。カタログ管理プロセッサ４０は、承認又は否認で応答する。
【０１０８】
特定のＣＱＵのファイルヘッダは、ファイルによってサポートされている全ての健康保健制度及び健康保険プログラムを表す。
【０１０９】
ファイルヘッダレコードが使用される。適切なものは、例４にある。
【表３】
0005872584.tif 000004
【表４】
0005872584.tif 000005
【表５】
0005872584.tif 000006
【表６】
0005872584.tif 000007
【表７】
0005872584.tif 000008
【０１１０】
小売商２４は、(健康保健制度及び承認機関に対する代理としての)カタログ管理プロセッサ４０によって承認を得るために送信されるプライベートラベル品目のファイルを生成しなければならない。このファイルのためのフォーマットを以下に記載する。検査のときに、制度に含むことを許されないファイル中の品目に、アクティビティコードにおける「Ｎ」でマークを付し、全ての適格品目に、「Ｅ」でマークを付す。ファイルは、送信から５営業日内に小売商２４に返送される。ファイル名の送信と返送の識別に関して、セクション４におけるファイルネーミング規定を参照。
【表８】
0005872584.tif 000009
【表９】
0005872584.tif 000010
【表１０】
0005872584.tif 000011
【０１１１】
小売商２４は、展開に先立ってカタログ管理プロセッサ４０によって承認を得るために、承認されたプライベートラベル品目と、適用可能なナショナルブランド品目との両者を含むファイルを生成する。このファイルのためのフォーマットを以下に記載する。検査のときに、制度に含むことを許されないファイル中の品目に、アクティビティコードにおける「Ｎ」でマークを付し、全ての適格品目に、「Ｅ」でマークを付す。ファイルは、送信から５営業日内に小売商２４に返送される。ファイル名の送信と返送の識別に関して、セクション４におけるファイルネーミング規定を参照。
【表１１】
0005872584.tif 000012
【表１２】
0005872584.tif 000013
【表１３】
0005872584.tif 000014
【０１１２】
ここに開示されている本発明の明細書と実施とを検討することにより、本発明の他の実施形態が当業者に明らかになるであろう。明細書と例を単なる例示と見なすことが意図されており、本発明の真の範囲と真意は、請求項によって示されている。
以下に、本願出願時の特許請求の範囲に記載された発明を付記する。
[１]複数の小売商が複数の支出額制限付きカードプログラムに参加するシステムであって、
前記システムは、
店の集信装置と製品表／価格帳とに結合されたポイントオブセールサーバを含む、小売商のインフラストラクチャと、
前記小売商に結合された、判定プロセッサと、
カタログ管理プロセッサと、
を具備し、
前記カタログ管理プロセッサは、前記判定プロセッサに結合されたサーバを含み、
前記カタログ管理プロセッサは、参加している小売商の各々に対するＵＰＣのカタログを作成し、
カタログの各々は、第１と第２のセットのＵＰＣデータを含み、
前記第１のセットは、ナショナルブランドの複数の製品に関し、
前記第２のセットは、小売商のプライベートラベルの複数の製品に関する、システム。
[２]カタログの各々は、前記カタログ管理サーバシステムと金融取引カードとを使用して、購入できるものの定義を反映している、前記[１]のシステム。
[３]複数の前記カタログの少なくとも一部分は、メディケアメディケイドサービスセンタ（ＣＭＳ）からの公表された複数のガイドラインに従う、前記[１]のシステム。
[４]複数の前記カタログの少なくとも一部分は、健康保険制度に関係付けられているコードに従う、前記[１]のシステム。
[５]複数の前記カタログの少なくとも一部分は、スポンサの複数のガイドラインに従う、前記[１]のシステム。
[６]カタログの各々は、ナショナルブランドのカタログを、プライベートラベルのカタログへの小売商による複数の付随する更新と共に定期的に更新される、前記[１]のシステム。
[７]前記カタログ管理プロセッサは、承認機関の複数の条件に合う、承認されたナショナルブランドのカタログを生成する、前記[１]のシステム。
[８]前記カタログ管理プロセッサは、健康保険制度と承認機関とに対する代理としての役割を果たす、前記[１]のシステム。
[９]前記カタログ管理プロセッサは、小売商によって提供された複数のプライベートラベル品目が適格品目のガイダンスの範囲内にあることを保証する、前記[１]のシステム。
[１０]複数の小売商は、前記ナショナルブランドのカタログの範囲内にある複数のプライベートラベル品目のリストを定義し維持する、前記[１]のシステム。
[１１]前記カタログ管理プロセッサは、規制ガイダンスの範囲に従った複数のカタログを作成する、前記[１]のシステム。
[１２]前記ナショナルブランドのカタログと、前記プライベートラベルのカタログは、作成及び承認の異なる経路を進む、前記[１]のシステム。
[１３]前記異なる経路は、様々な形式で展開される１つのカタログに集まる、前記[１２]のシステム。
[１４]前記カタログ管理プロセッサは、前記ナショナルブランドのカタログを制御し、
小売商は、プライベートカタログを制御する、前記[１]のシステム。
[１５]前記カタログ管理プロセッサは、前記プライベートラベルのカタログにおける複数の品目を検査して承認する、前記[１]のシステム。
[１６]前記カタログ管理プロセッサは、所定の製品群についての、ナショナルブランドの複数のＵＰＣからなる完全なリストにアクセスするように構成されている、前記[１]のシステム。
[１７]前記カタログ管理プロセッサは、前記完全なリストを絞り込み、スポンサのガイダンスに合う複数のＵＰＣのみを含むＵＰＣリストを作成する、前記[１６]のシステム。
[１８]前記カタログ管理プロセッサと小売商との間における通信は、複数のデータファイルの形式をとる、前記[１]のシステム。
[１９]連邦政府と州政府とに代わりに、メディケアとメディケイドとを管理する複数の健康保険制度によって、複数の金融取引カードが購入者に発行される、前記[１]のシステム。
[２０]購入者は、ＩＶＲを介してアクティブにされた金融取引カードを有する、前記[１]のシステム。
[２１]前記判定プロセッサは、スイッチと、マーケットバスケットの中の複数の品目の妥当性を確認するマーケットバスケット分析サーバと、プロセス制御サーバと、を含み、
前記マーケットバスケット分析サーバは、複数の製品カタログに結合され、前記マーケットバスケットの中の適格な複数の品目の妥当性を確認し、
前記マーケットバスケットにおける複数の内容属性は、前記マーケットバスケット分析サーバと前記スイッチとの間で通信される、前記[１]のシステム。
[２２]前記スイッチと、マーケットバスケット分析サーバと、カタログ管理サーバと、プロセス制御サーバは、前記マーケットバスケットの中の複数の品目に対して金融取引の認可を与えるように構成されている、前記[２１]のシステム。
[２３]複数のカタログと金融口座構造情報は、複数の入力であり、前記マーケットバスケットの中の複数の品目と照合され、
次に、前記マーケットバスケットの中の複数の品目は、購入者の財布から支払われ、
前記財布は、購入者の金融取引資金へのリンクである、前記[２１]のシステム。
[２４]前記マーケットバスケット分析器は、マーケットバスケットの複数の品目を、カタログと繰り返し比較するように構成されている、前記[２１]のシステム。
[２５]前記判定プロセッサに結合された金融プロセッサ、を更に具備する、前記[２１]のシステム。
【図１−１】
0005872584.tif 000015
【図１−２】
0005872584.tif 000016
【図２−１】
0005872584.tif 000017
【図２−２】
0005872584.tif 000018
【図３】
0005872584.tif 000019
【図４】
0005872584.tif 000020
【図５】
0005872584.tif 000021
【図６】
0005872584.tif 000022