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

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

▶ アクシオム エルエルシーの特許一覧

<>
  • 特許-販売時点管理消費者解決システム 図1
  • 特許-販売時点管理消費者解決システム 図2
  • 特許-販売時点管理消費者解決システム 図3
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-27
(45)【発行日】2024-01-11
(54)【発明の名称】販売時点管理消費者解決システム
(51)【国際特許分類】
   G06Q 20/20 20120101AFI20231228BHJP
   G06Q 20/40 20120101ALI20231228BHJP
【FI】
G06Q20/20
G06Q20/40
【請求項の数】 36
(21)【出願番号】P 2021548659
(86)(22)【出願日】2019-08-22
(65)【公表番号】
(43)【公表日】2022-04-21
(86)【国際出願番号】 US2019047666
(87)【国際公開番号】W WO2020185251
(87)【国際公開日】2020-09-17
【審査請求日】2022-05-26
(31)【優先権主張番号】62/815,686
(32)【優先日】2019-03-08
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520407460
【氏名又は名称】アクシオム エルエルシー
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】ターナー、ジョイス
(72)【発明者】
【氏名】ギレラン、ショーン
(72)【発明者】
【氏名】ペイトン、サンディー
(72)【発明者】
【氏名】プティ、ジョエル
【審査官】牧 裕子
(56)【参考文献】
【文献】米国特許出願公開第2006/0065716(US,A1)
【文献】米国特許出願公開第2006/0074637(US,A1)
【文献】特開2000-259721(JP,A)
【文献】特開2002-251513(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
販売時点管理で消費者識別を解決するためのネットワーク接続されたシステムであって、
消費者データ入力サブシステムと、消費者データ出力ルーチンと、支払い承認サブシステムとを備えた小売業者販売時点管理システムと、
前記小売業者販売時点管理システムと電子通信している拡張型トレード・エリア・アペンド・プロセッサであって、前記小売業者販売時点管理システムから消費者データを受信する消費者データ入力ルーチンと、前記消費者データ入力ルーチンを通じて前記小売業者販売時点管理システムから受信された消費者レコードが、定義されたトレード・エリア内に見つかる1つ以上の消費者名と一致するかどうかを判定するトレード・エリア・アペンド・ルーチンとを備える、拡張型トレード・エリア・アペンド・プロセッサと、
前記拡張型トレード・エリア・アペンド・プロセッサと電子通信している小売業者データベースであって、前記小売業者データベースが複数の消費者レコードを含み、各消費者レコードが、小売業者にとって既知の消費者に対する消費者名及び一致する消費者住所を含む、小売業者データベースと、
前記拡張型トレード・エリア・アペンド・プロセッサと電子通信しているコンソーシアム・プロセッサであって、前記拡張型トレード・エリア・プロセッサから受信された消費者レコードに対して一致又は一致なしの結果のみを返すリアルタイム・コンソーシアム・チェック・ルーチンを備え、前記リアルタイム・コンソーシアム・チェック・ルーチンを実行するために、前記小売業者販売時点管理システムによってアクセスできないコンソーシアム・データベースを用いる、コンソーシアム・プロセッサと、
を備える、システム。
【請求項2】
前記コンソーシアム・プロセッサが金融サービス・コンソーシアムによって維持される、請求項1に記載のシステム。
【請求項3】
前記コンソーシアム・プロセッサが少なくとも1つの支払いプロセッサによって維持される、請求項1に記載のシステム。
【請求項4】
前記コンソーシアム・プロセッサと電子通信しており、前記拡張型トレード・エリア・プロセッサから受信された前記消費者レコードを提携先プロセッサ・データベース内の複数の提携先消費者レコードと比較する少なくとも1つの提携先プロセッサをさらに備える、請求項1に記載のシステム。
【請求項5】
前記拡張型トレード・エリア・アペンド・プロセッサと電子通信している小売業者プロセッサをさらに備える、請求項4に記載のシステム。
【請求項6】
前記拡張型トレード・エリア・アペンド・プロセッサが、前記小売業者販売時点管理システムでの販売時点管理取引中に前記小売業者プロセッサにリアルタイム結果を提供するリアルタイム出力ルーチンをさらに備える、請求項5に記載のシステム。
【請求項7】
前記小売業者データベースと通信しており、複数のバッチ提携先更新ファイルのセットを含み、前記複数のバッチ提携先更新ファイルのセットからのバッチ照合データを前記小売業者データベースへ送信するように構成されたステージング・サーバをさらに備える、請求項6に記載のシステム。
【請求項8】
前記小売業者データベースが小売業者販売時点管理プロセッサと電子通信しており、前記小売業者データベースが、バッチ照合データを前記小売業者販売時点管理プロセッサへ送信する小売業者データベース出力ルーチンを備える、請求項7に記載のシステム。
【請求項9】
前記拡張型トレード・エリア・アペンド・プロセッサと電子通信している包括的消費者データベースをさらに備える、請求項8に記載のシステム。
【請求項10】
前記拡張型トレード・エリア・アペンド・プロセッサが、前記定義されたトレード・エリア内の住所を含む前記包括的消費者データベースからの消費者レコードを識別する検索ルーチンをさらに備える、請求項9に記載のシステム。
【請求項11】
販売時点管理で消費者識別を解決する方法であって、
拡張型トレード・エリア・アペンド・プロセッサが、識別子を含む電子販売時点管理メッセージを小売業者販売時点管理システムから受信するステップと、
前記拡張型トレード・エリア・アペンド・プロセッサが、一致する消費者レコードを求めて、前記拡張型トレード・エリア・アペンド・プロセッサと通信する小売業者データベースを検索するステップと、
前記小売業者データベースの検索で一致する消費者レコードが見つかった場合、前記一致する消費者レコードを、前記拡張型トレード・エリア・アペンド・プロセッサに返すステップと、
前記小売業者データベースの検索で一致する消費者レコードが見つからない場合、前記拡張型トレード・エリア・アペンド・プロセッサが、前記電子販売時点管理メッセージからの前記識別子及び定義されたトレード・エリア内の住所の両方を含む少なくとも1つの完全な消費者レコードを識別するトレード・エリア・アペンドを実行するステップと、
識別された各完全な消費者レコードについて、コンソーシアム・プロセッサが、コンソーシアム照合結果を要求するステップであって、前記コンソーシアム照合結果は肯定的又は否定的のいずれかのみであり得え、前記コンソーシアム・プロセッサが、前記小売業者販売時点管理システムによって直接アクセスできないコンソーシアム・データベースと通信して、前記コンソーシアム照合結果を生成する、要求するステップと、
コンソーシアム照合結果が肯定的である識別された各完全な消費者レコードについて、少なくとも消費者名フィールド及び消費者住所フィールドを含む新しい消費者レコードを書き込み、前記新しい消費者レコードを前記小売業者データベースに追加するステップと、
を含む、販売時点管理で消費者識別を解決する方法。
【請求項12】
前記識別子が名前を含む、請求項11に記載の方法。
【請求項13】
前記識別子が、暗号化されたパケットを含む、請求項11に記載の方法。
【請求項14】
前記コンソーシアム・プロセッサが、コンソーシアム照合結果を要求するときにタイマを開始するステップをさらに含む、請求項11に記載の方法。
【請求項15】
コンソーシアム照合結果を受信すること又は前記タイマが満了時刻に到達することのいずれかが最初に起こるまで、前記コンソーシアム・プロセッサが、前記コンソーシアム照合結果を要求するステップを定期的に反復するステップをさらに含む、請求項14に記載の方法。
【請求項16】
前記小売業者データベースの検索で一致する消費者レコードが見つかった場合、ログを更新するステップをさらに含む、請求項11に記載の方法。
【請求項17】
前記コンソーシアム照合結果が受信される前に前記タイマが前記満了時刻に到達した場合、前記コンソーシアム・プロセッサが、ログを更新するステップをさらに含む、請求項15に記載の方法。
【請求項18】
前記小売業者データベースの検索で一致する消費者レコードが見つかった場合、前記一致する消費者レコードを小売業者プロセッサに書き込む、請求項11に記載の方法。
【請求項19】
前記電子販売時点管理メッセージを生成するために電子リーダを使用して前記小売業者販売時点管理システム電子支払い情報を読み取るステップをさらに含む、請求項18に記載の方法。
【請求項20】
前記小売業者販売時点管理システムが前記電子リーダで電子支払い情報を読み取るステップが、前記電子リーダを有する複数の電子支払いカード・プロバイダからの電子支払いカードを読み取るステップを含む、請求項19に記載の方法。
【請求項21】
コンソーシアム照合結果が肯定的である識別された各完全な消費者レコードについて、前記コンソーシアム・プロセッサが、小売業者プロセッサへコンソーシアム照合結果メッセージを送信するステップをさらに含む、請求項11に記載の方法。
【請求項22】
前記コンソーシアム照合結果メッセージが、一致する消費者名フィールド及び一致する消費者住所フィールドを含む、請求項21に記載の方法。
【請求項23】
前記コンソーシアム・プロセッサが前記小売業者プロセッサへ前記コンソーシアム照合結果メッセージを送信するステップがリアルタイムで実行される、請求項22に記載の方法。
【請求項24】
前記コンソーシアム・プロセッサが前記コンソーシアム照合結果メッセージを送信するステップが、前記小売業者販売時点管理システムでの取引が完了する前に実行される、請求項23に記載の方法。
【請求項25】
前記小売業者データベースから小売業者プロセッサへバッチ・ファイルを定期的に送信するステップをさらに含み、前記バッチ・ファイルが、最後の定期的に送信されたバッチ・ファイルの後に前記小売業者データベースに追加されたそれぞれの新しい小売業者データベース・レコードを含む、請求項18に記載の方法。
【請求項26】
前記小売業者データベースから前記小売業者プロセッサへバッチ・ファイルを送信するステップの周期が日次である、請求項25に記載の方法。
【請求項27】
複数の消費者レコードを含む少なくとも1つのコンソーシアム提携先バッチ・ファイルを、前記コンソーシアム・プロセッサから受信するステップをさらに含む、請求項25に記載の方法。
【請求項28】
前記少なくとも1つのコンソーシアム提携先バッチ・ファイルステージング・サーバ受信る、請求項27に記載の方法。
【請求項29】
前記コンソーシアム・プロセッサからの前記少なくとも1つのコンソーシアム提携先バッチ・ファイル内に列挙された各消費者名について、前記ステージング・サーバが、ステージング・サーバ消費者レコードを作成するステップをさらに含む、請求項28に記載の方法。
【請求項30】
前記ステージング・サーバから前記小売業者データベースへ少なくとも1つのステージング・サーバ消費者レコードを通信するステップをさらに含む、請求項29に記載の方法。
【請求項31】
前記小売業者データベースを検索するステップが、複数の小売業者データベースを検索するステップを含む、請求項11に記載の方法。
【請求項32】
前記コンソーシアム照合結果コンソーシアム・チェック・プロセッサ受信る、請求項20に記載の方法。
【請求項33】
前記コンソーシアム・チェック・プロセッサコンソーシアム照合結果を受信するステップに応答して、前記コンソーシアム・チェック・プロセッサ複数のコンソーシアム提携先プロセッサのそれぞれへ要求を送信するステップをさらに含む、請求項32に記載の方法。
【請求項34】
前記複数のコンソーシアム提携先プロセッサのそれぞれが、コンソーシアム提携先応答を送信するステップをさらに含み、前記コンソーシアム提携先応答のそれぞれは肯定的又は否定的のいずれかであり得る、請求項33に記載の方法。
【請求項35】
前記コンソーシアム提携先応答のいずれかが肯定的である場合、前記コンソーシアム照合結果を肯定に設定する、請求項34に記載の方法。
【請求項36】
前記コンソーシアム提携先プロセッサのそれぞれが単一の電子支払いカード・プロバイダに対応する、請求項35に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、販売時点管理での自動化されたデータ収集に関連する、ネットワーク接続されたハードウェア、データ構造、及び自動化された方法の分野に関し、より詳細には、自動化された販売時点管理(POS:point-of-sale)システムと対話する消費者の識別を解決するそのようなデータ構造及び方法に関する。
【背景技術】
【0002】
この背景技術のセクションで言及されている参照事項は本発明に関する従来技術であることを認めるものではない。
【0003】
実店舗を経営している小売業者は、特定の販売時点管理(POS)で購買をする消費者を識別すれば有利であることを長らく認識している。この情報を用いれば、小売業者はその最も価値の高い消費者たちを認識して彼らに特別なインセンティブを提供することができ、その小売業者での消費者の購買履歴に基づいて消費者にその営業努力をより正確に向けることもできる可能性がある。消費者がデビット・カード、クレジット・カード、電子財布、又は電子小切手などの電子対応決済タイプを利用する場合、小売業者は、この取引を通じて消費者の名前を知り得る。この情報は、電子POSシステムを使用して決済方法から引き出される。しかし、名前は一意的ではないから、名前だけでは小売業者は消費者を一意的に識別することができないため、小売業者は、その名前を共有する任意数の消費者のうちのいずれが実際にその購買をしたかを知る方法がない。
【0004】
この問題を克服する1つの試みは、ポイント・カード又は類似の電子デバイスを消費者に発行することである。この手法では、小売業者は、各ポイント・カード上のコードをカードが発行された特定の消費者に関連付けるデータベースを維持する。このデータベースは小売業者のPOSシステムにリンクされる。購買がなされると、消費者は割引、ポイントなどを受け取るためにPOSでカードを提示するように誘われる。小売業者は、この方法を使用してPOSで消費者を明瞭に識別することができるが、この方法は各購買においてポイント・カードを提示することを消費者に要求する。多くの消費者はポイント・カードを使用することを好まないか、又は自分のカードを紛失し若しくは忘れている可能性があり、その場合には顧客及び顧客の購買に関するデータがPOSで捕捉されないことがある。
【0005】
この問題を克服するもう1つの試みは、トレード・エリア・アペンドとして知られている。この手法は、特定の管轄内の消費者に関する一致した名前、住所、及びさまざまな他のデータを含む広域的な消費者データベースを利用する。例えば、1つのこのようなデータベースはAcxiom LLCによって維持されているInfoBaseデータベースであり、これは米国内の消費者に関する広範囲の人口統計学的及び他のデータを追跡している。トレード・エリア・アペンド手法は、POSで受信された決済データから導出される消費者名を取得し、小売業者POSの物理的地点の周りの定義されたトレード・エリア内にある一致する名前及び居住住所の両方で消費者データベース内のレコードを探索する。一致が見つかった場合、実店舗小売業者で買い物をする消費者は小売業者地点の近くのエリアに居住している可能性が高いため、この消費者が購買者であると推定される。
【0006】
このトレード・エリア・アペンド手法はいくつかの欠点を有する。第1に、定義されたトレード・エリア内で重複する消費者名が見つかることがある。この場合、システムがトレード・エリア内で同じ名前を有する相異なる消費者間の「結び付き」を断つことが可能な追加的データがないため、購買取引に関わったのがこれらの消費者のうちのいずれであるかを判定することは不可能である。トレード・エリアのサイズを縮小すると、重複する消費者名が返されるリスクは低下するが、消費者を完全に見失うかもしれないリスクも増大する。第2に、消費者はトレード・エリアの外部に居住していて、それにもかかわらず特定の小売業者で買い物をしている可能性がある。これは、例えば、消費者が旅行しているとき、又は消費者が特に望ましいと考えている小売業者で買い物をするために、予想されるよりも遠くまで移動するのをいとわないだけの可能性があるときに生じ得る。この場合、トレード・エリア・アペンド手法はヒットを返さない可能性がある。第3に、たとえ単一の名前がトレード・エリア・アペンドによって返されても、取引に関わった消費者がトレード・エリアの外部に居住し、トレード・エリア内に実際に居住している単一の消費者と同じ名前を偶然に有しているだけの可能性がある。この場合、トレード・エリア・アペンド手法は単一の結果を返すが、その結果は正しくない。
【0007】
小売業者POSでの決済データに基づいて消費者識別を解決する既存のシステムの限界により、この機能を実行するための改善されたデータベース構造及び電子システムであって、トレード・エリア・アペンドよりも正確に消費者の識別を明瞭に解決することが可能で、しかもポイント・カードを必要としないものがあれば非常に望ましい。
【発明の概要】
【課題を解決するための手段】
【0008】
本発明は、仮想財布データベース及びコンソーシアム・プロセッサをネットワークに組み込む、小売業者POSで消費者を識別する改善されたシステム及び方法に関する。仮想財布データベースは、消費者の名前、住所、カード・データ、及び他の識別子を含む。コンソーシアム・プロセッサは、小売業者によって直接アクセス可能でないデータベース(単数又は複数)を利用し、消費者によって利用される電子決済方法のプロバイダに既知の情報を維持する。消費者のプライバシーを保護するために、多くの管轄で適用可能な規制によって、このようなプロバイダがそれらのデータベースに維持されているデータ全体を小売業者に供給することが防止される。コンソーシアム・プロセッサは、クレジット・カードを発行するさまざまな主体を含むがそれらに限定されない金融サービス・プロバイダのコンソーシアムによって維持されてもよく、又はそのコンソーシアムによって提供されるデータを利用してもよい。代替的に、又は金融サービス・プロバイダに加えて、コンソーシアムは、支払いプロセッサを含んでもよい。支払いプロセッサは、銀行に対する取引を扱うために商人によって任命される企業である。TSYSは支払いプロセッサの一実例である。
【0009】
いくつかの実施態様では、システムはまず、仮想財布データベースで小売業者POSからの決済データをチェックする。一致が見つかった場合、消費者識別が確認される。仮想財布データベースからの一致がない場合、小売業者POSのトレード・エリア内で一致する消費者を見つけるためにトレード・エリア・アペンドのルーチンが使用される。一致が見つからない場合、レコードは未識別とフラグが立てられる。トレード・エリア・アペンドを使用して一致が見つかった場合、該当する住所がPOSで捕捉された消費者データに添付され、このレコードはコンソーシアムへ送信される。コンソーシアムは、このデータを自己のレコードと比較し、単純な一致又は不一致(すなわち、「はい」又は「いいえ」)の結果を返す。そして、仮想財布データベースは、新たに識別された消費者で更新されるか、又は該当する場合には、データベース内の消費者に対する既存のレコードに新たな決済タイプが追加される。可能性のある一致が複数ある場合、プロセスは、コンソーシアムでの一致要求まで複数回実行されてもよい。
【0010】
本発明のこれら及び他の特徴、目的及び利点は、以下で説明する図面とともに以下の詳細な説明を考慮することからより良く理解されるであろう。
【図面の簡単な説明】
【0011】
図1】本発明の実施態様によるシステムの構成要素を示す図である。
図2】本発明の実施態様によるリアルタイム方法のステップを示すフロー・チャートである。
図3】本発明の実施態様によるバッチ方法のステップを示すフロー・チャートである。
【発明を実施するための形態】
【0012】
本発明をさらに詳細に説明する前に、理解されるべきであるが、本発明は本明細書に記載される特定の実施態様に限定されず、特定の実施態様を説明する際に使用される用語はそれらの特定の実施態様を説明する目的のみのものであって、限定的であることを意図してない。本発明の範囲は特許請求の範囲によってのみ限定される。
【0013】
図1を参照して、一実施態様に従って本発明を実施するために使用されるシステムの主要な構成要素について説明することができる。小売業者販売時点管理(POS)システム10は、小売業者地点に物理的に位置する電子システム及びネットワーク構成要素を指し、そこで消費者が購買を行い、消費者に提供される商品又はサービスに対する支払いを処理する間に決済情報(カード番号及び発行者情報など)が取り込まれる。小売業者POSシステムは、例えば、小売業者販売時点管理のレジスタにネットワーク接続されたカード・リーダであってもよいが、他の実施例では、小売業者が取引のために電子支払い情報を受領する任意の方法からなることが可能である。このデータは電子ネットワークを介して「拡張型(enhanced)」トレード・エリア・アペンド(TAA:trade area append)プロセッサ40に渡される。これはコンピュータ・サーバ(単数又は複数)上で実行されるソフトウェアとして実施されてもよい。TAAプロセッサ40は、消費者解決サービスのプロバイダによって維持され、その機能は以下で図2を参照してより詳細に説明される。
【0014】
TAAプロセッサ40は、1つ以上のコンソーシアム・プロセッサ・データベース44で見込み識別子(例えば、消費者の名前/住所又は、組込みチップ付きのカードの場合、暗号化パケット)の一致を調べ、見込み識別子の一致が実際に正しいかどうかを判定するために、コンソーシアム・チェック・プロセッサ46と通信する。この処理は、電子支払いデータが、TAAプロセッサ40と通信している1つ以上の仮想財布データベース42におけるレコードにまだ見つからないデータを有する消費者との取引で受領された場合にのみ生じる。注意されるであろうが、2個の仮想財布データベースが図1に示されているが、システムは、仮想財布データベース42の機能を実施するために、任意個数の物理的に分離したデータベースを含むことができる。仮想財布データベース42は、過去の取引を通じて入手された消費者に対する一致した名前、住所、カード・データ、及び他の情報を追跡し、新たな一致がなされた後にTAAプロセッサ40からの更新にも備えている。
【0015】
図2を参照して以下でより詳細に説明するように、TAAプロセッサ40は、いくつかの実施態様では、第三者データ・サービス・プロバイダから利用可能とされ得るような包括的コンピュータ・データベース(単数又は複数)と通信していてもよい。包括的コンピュータ・データベースは、1つ以上の仮想データベース42内に消費者に対応するレコードがない場合に、その消費者に対する住所データを提供する。この情報はリアルタイム・コンソーシアム・チェック・プロセッサ46に渡される。代替的に、小売業者が、データ・プロバイダの包括的コンピュータ・データベースと同じ目的を果たす自己のデータベースを維持してもよい。この小売業者データベース内の情報は、データ・サービス・プロバイダからのデータが入力されてもよいし、任意の代替的な方法で収集されてもよい。
【0016】
リアルタイム・コンソーシアム・チェック・プロセッサ46は、1つ以上のコンソーシアム提携先プロセッサ44へのフロント・エンドとして作用する。リアルタイム・コンソーシアム・チェック・プロセッサ46は、特定の消費者に対する候補識別子(例えば、名前/住所)の一致が、小売業者POSシステム10に電子的に提示された特定の決済データを有する消費者に実際には対応していないかどうかをチェックするために、TAAプロセッサ40からメッセージを受信する。コンソーシアム提携先プロセッサのそれぞれは決済データを受信し、それを自己の内部データベースと比較する。これらのデータベースは、例えば、クレジット・カード発行者によって維持される消費者データベースであってもよい。この種のデータは、消費者カード所持者のプライバシーを保護するために、小売業者システムにとって直接入手可能とすることはできない。カード発行者は、適用可能な規制によってこの情報を保護することが要求される。したがって、リアルタイム・コンソーシアム・チェック・プロセッサ46は、コンソーシアム提携先と小売業者との間で情報の任意の可能な開示に対する保護を行う仲介者として作用する。
【0017】
TAAプロセッサ40は、コンソーシアム・チェック・プロセッサ46でリアルタイム・チェックが成功した後に入手された情報を小売業者に提供するために、消費者リアルタイム受注プロセス50で小売業者システム48にメッセージを送信することができる。システムはまた、仮想財布データベース42からバッチ受注プロセス52を通じて小売業者システム48へのバッチ更新に備える。本発明のこの実施態様では、コンソーシアム提携先バッチ・データベース54からのバッチ情報を通信するためにステージング・サーバ56が使用されてもよい。これにより本発明は、リアルタイム・モードで動作することが可能であり、その期間中は取引が処理されている間に見込み識別子一致の正しさに関してチェックが行われるだけでなく、バッチ・モードで後の時刻にさまざまな更新が行われ、結果が配信されることも可能となる。バッチ・モード更新は、日次などの定期的に予定された間隔で配信されてもよい。
【0018】
次に図2に移り、図1を参照して説明したシステムを使用したリアルタイムの自動化されたプロセスにおけるステップについて説明することができる。処理はPOSシステム10で開始され、ステップ12で、識別子及び決済データが何らかの形態の電子支払いを通じて受信される。判断ブロック14で、拡張型TAAプロセッサは、POSシステム10で入力された情報が仮想財布データベース42内に既に存在するレコードと一致するかどうかを判定する。そうである場合、ステップ16で、その消費者の識別に対する信頼度スコアが割り当てられ、ステップ18でシステム・ログが更新され、ステップ20で処理はクライアント(すなわち、小売業者コンピュータ・システム)に戻る。この場合、この消費者は、システムが使用されていた間に取引を明らかに既に実行しており、それによりその消費者のデータは仮想財布データベース42に過去に追加されていたので、他の照合は要求されない。
【0019】
POSシステム10で入力された情報が仮想財布データベース42内に既に存在するレコードと一致しない場合、ステップ22で、トレード・エリア・アペンド・プロセスが実行される。このステップでは、識別子が消費者名であると仮定して、消費者の名前が、消費者の名前及び住所を含む包括的消費者データベースと照合される。見つかった一致する名前を有する各消費者レコードについて、システムは、その消費者が小売業者の定義されたトレード・エリア内に居住しているかどうかを判定するためのコードを実行する。トレード・エリアは、小売業者からの定義された絶対距離、小売業者からの定義された道のり距離、又は小売業者が位置している大都市統計エリアなどのいくつかの方法のいずれかで定義されてもよい。これらの実例は限定的でなく、任意の数の他のトレード・エリア定義が使用可能である。このステップの結果は、消費者の名前とその消費者の住所との間の見込み一致である。
【0020】
ステップ23で、判断ブロック23からのトレード・エリア・アペンドの結果として消費者名が見つかるかどうかが判定される。見つからない場合、ステップ25で一致なしの結果が返され、処理はブロック18に進みログを更新してから、ステップ20で前のようにクライアントに結果を返す。判断ブロック23での問いで、トレード・エリア・ステップ22において消費者名が見つかった場合、処理は判断ブロック・ステップ24に進み、そこで見込み消費者の名前及び住所がコンソーシアム・チェック・プロセッサ46へ送信され、返されるデータは、これが正しい一致か否かを示す。この返されるデータは、「はい」及び「いいえ」の選択肢若しくは「Y」及び「N」の選択肢などの一致を示す文字列を含んでもよく、又は「1」若しくは「0」の選択肢で一致があったかどうかを示す単一ビットであってもよい。この情報を通信する任意の数の他の手段が他の実施態様で使用可能である。
【0021】
コンソーシアム・チェック・プロセッサ46によって一致が返された場合、ブロック26で、仮想財布データベース42が消費者決済データで更新され、上記のようにステップ16で処理が継続する。この場合、個人消費者が仮想財布データベース42内に存在しなかったにもかかわらず、システムはその個人消費者を正しく識別している。しかし、仮想財布データベース42はステップ26で更新されるため、特定の決済データを使用したこの消費者に関する後続の処理は判断ブロック14で「はい」の結果を返すことになり、それにより、トレード・エリア・アペンド及びコンソーシアム・チェック・プロセッサ46との電子通信の必要性が回避される。
【0022】
判断ブロック24で、コンソーシアム・チェック・プロセッサ46からの応答に基づく一致又は一致なしの結果として見込み消費者の名前及び住所がまだ確認されない場合、処理はステップ28に移動し、そこで見込みデータが未確認一致に対する待ち行列に保持される。判断ブロック30で、待ち行列に保持されているデータに対する時間が、設定されたタイム・リミットを超過しているかどうかをチェックするポーリングが行われる。超過していない場合、処理はステップ22に戻り、トレード・エリア・アペンドが再び実行される。なお、このプロセスは、タイマ設定に基づいて任意回数繰り返すことができることに注意されたい。また、このプロセスは複数の見込み一致に対して繰り返すことができることにも注意すべきである。例えば、ステップ22でのトレード・エリア・アペンド処理が2個以上の潜在的な消費者の名前及び住所の一致を返した場合、それらのそれぞれが、コンソーシアム・チェック・プロセッサ46との通信によってステップ24でチェックされてもよい。
【0023】
判断ブロック30でタイマが超過した後、処理はブロック16に移動して信頼度コードを割り当ててから、ステップ26に移動して、一致した消費者情報で仮想財布データベースを更新する。さらに、ステップ18でログが更新され、ブロック20で処理はクライアントに戻る。信頼度コードは、一致の品質に基づいて割り当てられる。一実例では、以下のコードが割り当てられる。
400:仮想財布に見つかった
300:名前/住所/コンソーシアムが一致
220:名前/住所が一致
200:名前/コンソーシアムが一致
150:住所/コンソーシアムが一致
ログはJSONフォーマットで記憶され、タイミング、一意取引ID、日付、ステータス・コード、一致信頼度、コンソーシアム・メンバID、及びサービス・プロバイダへ送信された情報を保持する。サービス・プロバイダに返される情報は、追跡、報告、及びインボイス作成のために使用される。
【0024】
次に図3の流れ図を参照して、本発明のいくつかの実施態様に関してバッチ・モード動作について説明することができる。ブロック36に示すように、各コンソーシアム・メンバは、リフレッシュ・ファイル内で、更新されたデータを送信することができる。プロセスの最初のステップは、ステップ38で、レコード上の名前、住所、又は他の情報からの情報に基づいて一意キーを割り当てようと試みることである。このレコードは、ステップ40で、仮想財布内のコンソーシアム・データベース・テーブルを更新する。新しいレコードが追加された後、ステップ44で、すべての既存の未確認レコード23が、新しい追加されたレコード21とマージされる。その目的は、新しい一致を見つけることである。新しいレコードが到着したときに一致が見つからない場合、ステップ56で、それらは未確認レコードのままにとどまり、ステップ58で、データが契約満了時刻に到達したかどうかがチェックされる。レコードが契約されたアーカイブ期間内に依然としてある場合、これ以上の処理はなく、プロセスはステップ62で終了する。レコードが契約されたアーカイブ期間に到達した場合、ステップ60で、レコードは仮想財布データベースにおける削除のためにマークされ、次の保守ウィンドウにおいて削除される。
【0025】
ステップ46で一致が見つかった場合、ステップ48で仮想財布が更新され、ステップ50で正しい信頼度コードが割り当てられ、ステップ52でそれぞれのこのようなレコードのステータスが確認済みに変更される。そしてステップ54で処理はクライアントに戻る。
【0026】
別段の断りがない限り、本明細書で使用されるすべての技術用語及び科学用語は、本発明が属する分野の当業者によって一般的に理解されるのと同じ意味を有する。本明細書に記載されるものと類似又は同等の任意の方法及び材料もまた本発明の実施又は試験において使用可能であるが、限定された数の例示的方法及び材料が本明細書には記載される。当業者には認識されるように、本明細書における発明の概念から逸脱することなくさらに多くの変更が可能である。
【0027】
本明細書で使用されるすべての用語は、文脈と整合する可能な限り最広義に解釈されるべきである。群にまとめたものが本明細書に記載される場合、群のすべての個別メンバ並びに群のすべての可能な組合せ及び下位組合せが本開示に個別に含まれることが意図されている。範囲が本明細書に記載される場合、その範囲内のすべての部分範囲及び個別の点が本開示に別個に含まれることが意図されている。本明細書で引用されるすべての参考文献は、本明細書の開示との矛盾がない限り参照により本明細書に組み込まれる。
【0028】
本発明について、例示的であることのみが意図され本発明の完全な範囲にとって限定的でない特定の好適な及び代替的な実施態様を参照して説明した。本発明の完全な範囲は添付の特許請求の範囲においてのみ記載される。
図1
図2
図3