プッシュ識別子を含むデータ完成のためのシステム並びに方法
プッシュ取引を処理するためのシステム並びに方法を提供する。支払者は、支払先から入力無しで取引を開始することがある。システムは、支払者によって提供された一部の情報から支払先が誰であるかを決定してその取引を適切な相手先へ伝えることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本出願は暫定的なものではなく、米国特許出願第６１／０２１，２８９号、２００８年１月１５日出願の優先権を主張するものであり、この出願は此処に参照することにより全ての目的に対してそのまま組み込まれている。
【背景技術】
【０００２】
多数の支払い方法およびシステムが存在する。例えば、購入者が１枚のクレジット・カードを売買業者に提示し、彼はそのクレジット・カードを「読み取り機に通して（swipe）」、支払いをそのクレジット・カードに関係する銀行から受け取ることが出来る。この方法は多くの長所を有し、強化された詐欺検出およびセキュリティーを含む。しかしながら、クレジット・カード（またはカード番号およびセキュリティー・コード）が、取引処理が生じる前に販売者に対して最初に提示されなければならない。従って、その販売者および全ての販売者に関係する銀行は、その取引にたとえその取引が完結しない場合でも最初から関与していなければならない。更に、その購入者は支払いが販売者に何時振り替えられるかを、簡単に予定計画することが出来ない。
【０００３】
別の支払い方法、例えば小切手、自動清算処理装置（automated clearing house：ACH）システムの使用、電信送信等が存在する。これらの方法の長所は、売買業者がクレジット・カード支払いの様には、支払い処理に関与する必要が無いことである。しかしながら、支払い方法は制限されている。例えば、危険事前評価も強化されていないし、または購入者または売買業者に対する報償計画も提供していない。電信送金は実施するのは面倒であり、使用時間および送金可能額が制限されている。小切手は受取者によって現金化されるまでしばらく時間が掛かる。その時間の間、購入者はその小切手の状態、またはその資金が何時その購入者の口座から引き落とされるかを知ることが出来ない。更に、小切手の紛失または盗難といった本来的な危険が存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施例は上記の問題、およびその他の問題を、個別にまた全体的に解決する。
【課題を解決するための手段】
【０００５】
本発明の実施例はプッシュ取引を実施するためのシステム及び方法を含み、此処で支払者は支払先への支払いを、支払先からの干渉をほとんど知ること無しに開始できる。
【０００６】
１つの実施例は、取引を処理するためのコンピュータを用いた方法を指向している。この方法は、支払い指示メッセージをサーバ・コンピュータで受け取り、此処で支払い指示メッセージはその発行者に関係する口座を用いて、支払先への支払いを行うものであり、此処でその支払い指示メッセージは少なくとも支払先情報の一部を含み、また更に此処で支払い指示メッセージは支払先とは異なる事業体から発せられたものであり、その支払い指示メッセージを再審理し、実質的に完全な支払先情報を決定し、そして認証要求メッセージを支払い指示メッセージの再審査後に発行者に送ることを含み、此処で認証要求がプッシュ識別子を含む。
【０００７】
別の実施例は、支払いを行うコンピュータを用いた方法を指向している。この方法は少なくとも支払先情報の一部、取引額、および支払時期を含む支払い指示メッセージをサーバ・コンピュータへ送り、此処でその支払い指示メッセージがサーバ・コンピュータで実質的に完全な支払先情報を決定するために構文解釈され、認証ログが支払先に関連する集金者に送られ、そしてお金が支払先に送金されることで構成されている。
【０００８】
別の実施例は、プッシュ支払い取引を受けとるためのコンピュータを用いた方法を指向している。この方法は取引に関係する認証ログを受け取り、此処でその認証ログは報告システム・ファイルと清算ファイルを含み、その取引の資金の流れに関するメッセージを送信し、その取引に関係する資金を受け取り、その資金を支払先に送金し、そして取引情報を支払先に送ることで構成されている。
【０００９】
別の実施例は、プッシュ取引を実施するためのコンピュータ読み取り可能媒体を指向している。この媒体は発行者に関係する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコード、此処で、支払い指示は少なくとも支払先情報の一部を含み、そして更に此処で支払い指示メッセージは支払先とは異なる事業体から発せられたものであり、その支払い指示メッセージを再審査するためのコード、実質的に完全な支払先情報を決定するためのコード、および認証要求を発行者に送るためのコードを含み、此処で認証要求がプッシュ識別子を含む。
【００１０】
本発明の別の実施例は、取引における支払先を識別するためのコンピュータ読み取り可能媒体を指向している。この媒体は支払い指示メッセージを受け取るためのコード、支払い指示メッセージを再審査し、その支払い指示メッセージが支払先を決定するための情報を含んでいるか否か判定するためのコード、および支払い指示メッセージ内の情報を、その支払い指示に関連する支払先を実質的に識別するために、複数のデータ・ストアとファジー論理を用いて比較するためのコードを含み、此処で複数のデータ・ストアは少なくとも１人の販売者を識別するための複数の識別子を含み、此処で複数の識別子は名称の識別子、電話番号の識別子、および住所の識別子を含む。
本発明のこれらおよびその他の実施例は、添付図および詳細な説明を参照して更に詳細に説明されている。
【図面の簡単な説明】
【００１１】
【図１】図１は、本発明の１つの実施例に基づくシステムのブロック図。
【図２】図２は、本発明の１つの実施例に基づく方法を図示する流れ図。
【図３】図３は、本発明の１つの実施例に基づく方法を図示する流れ図。
【図４】図４は、携帯型消費者機器のブロック図を示し、（ａ）は電話機形式の携帯型消費者機器（ｂ）はカード形式の携帯型消費者機器を示す。
【図５】図５は、コンピュータ装置のブロック図を示す。
【発明を実施するための形態】
【００１２】
本発明の実施例は、支払いを行う側から開始される支払い処理のシステムおよび方法を指向している。言葉を変えれば、支払先から「プル（pull）」されるものではなく、支払者から「プッシュ（push）」される取引である。或るいくつかの実施例において、第１当事者（例えば、取引の購入者）は標準クレジット・カード処理システムを用いて、支払い資金を第２当事者（例えば販売者）に、第２当事者と何らの相互交渉を行うことなく送金することが可能である。第２当事者は第１当事者から支払いがなされ、関連する資金が第２当事者の口座へ入金されたことの通知を受け取ることが可能である。
【００１３】
本発明の実施例は他の事業体へ支払いを行う企業で使用することが出来る。例えば、購入者が供給者から物品を購入する。その様な１つの例において、レストラン企業がナプキンを大量にナプキン供給者から購入する。購入者はそれらの物品の請求書を受け取る。従来の処理では、購入者はその請求書に対して小切手を供給者に送ることで支払いを行う。しかしながら、小切手による支払いは、上述の様な制約を受ける。本発明の或る実施例において、購入者は代わりにその請求書を支払うためにプッシュ支払いを行うことが出来る。これらの実施例では支払い指示メッセージが購入者の銀行（「発行者（issuer）」）または支払い処理ネットワーク、例えばVisaNet（登録商標）,またはBanknet（登録商標）に電子的に送信されるものと考えている。
【００１４】
支払い指示メッセージはある種の情報、例えば供給者の名称、支払額、支払い時期など、を含むことが出来る。支払い処理ネットワークは、支払い指示メッセージ内の情報を用いて、その支払いを行う適切な事業体を決定することが出来る。例えば、支払い指示メッセージの中には支払先情報の或る一部分のみ、例えば供給者名または住所の一部のみしか含まないものもある。上記の例では、ナプキン供給者は「ナプキン株式会社（The Napkin Company）」であるかも知れない。しかしながら、レストラン会社ではそれを「ナプキン社（Napkin Co.）」とだけ呼んでいるかも知れない。従って、支払い処理ネットワークは、与えられた情報に基づいて、実質的に完全に支払先情報を決定することが出来る。これは、ファジー論理マッチング（fuzzy logic matching）により、部分情報を供給者一覧表のデータ・ベースと比較することで実施可能であり、また本発明の実施例に基づくその他の技術も同様に以下に更に詳細に説明される。この様にして、支払い処理ネットワークは適切な支払先は「ナプキン株式会社（The Napkin Company.）」と決定できる。
【００１５】
ひとたび、供給者の完全な支払先情報が決定されると、支払い処理ネットワークは発行者から支払いを要求するメッセージ（「認証要求メッセージ」（“authorization request message”））を作成できる。いくつかの実施例において、認証要求メッセージはどの様な特定標準メッセージ・システムにも適合することが出来る（すなわち、支払い処理システムは支払い処理メッセージを１つの工業標準フォーマットに翻訳する。）別の実施例では、認証要求メッセージはユニークなフォーマットと出来る。
【００１６】
ひとたび発行者が認証要求を受け取ると、その取引の承認または拒否が可能である。拒否される場合、拒否メッセージが購入者に送り返される。認証されると、支払い処理ネットワークは認証ログをその供給者に関連する銀行へ送られる。例として示す実施例において、この認証ログが、取引が購入者によって開始されたという、この銀行への第１通知である。発行者の取引を認証する処理は「認証（authorization）」と呼ばれる。この認証ステップは銀行と購入者に対して、取引が継続出来ることの注意を喚起する。支払いは一般的にこの認証ステップが実行された後に生じる。支払いは、発行者から供給者へ、または銀行または供給者の系列のその他の公共機関へ資金が引き落とされた時に発生する。
【００１７】
本発明の具体的な実施例を、図１−５を参照して説明する。
【００１８】
（１．例示システム）
図１は本発明の１つの実施例に基づくシステム２０を示す。本発明に基づくその他のシステムは、図１に具体的に示されたものよりも少ないかまたは多い部品を含む。
【００１９】
図１は購入者３０、接続機器３４、売り手２２、集金者２４、支払い処理ネットワーク２６、および発行者２８を互いに通信出来る状態で示している。集金者２４および発行者２８は支払い処理ネットワーク２６を通して通信可能である。先に記述したように、「発行者」は通常はビジネス事業体（例えば銀行）であって、購入者の金融口座を管理し、またしばしばクレジットまたは銀行カードの様な携帯型消費者機器を購入者に発行する。「売り手」は通常取引に関わる１つの関係者であって、例えば小売店（store）、納入業者（supplier）、売買業者（merchant）、個人またはサービス提供者である。接続機器３４は購入者３０によって使用され、システム内の他の事業体と通信し、コンピュータ、電話機またはその他の通信手段を含む。
【００２０】
１つの典型的な支払い取引において、購入者（すなわち「支払者」）３０は物品またはサービスを売り手２２に注文する。購入者３０は次にその購入に対する支払い指示を、接続機器３４を用いて送信する。接続機器３４はその支払い指示を発行者２８または直接支払い処理ネットワーク２６に伝送する。支払い処理ネットワーク２６は識別システム４９を用いてその支払い指示を解析し、適切な売り手の身元を判定できる。支払い処理ネットワークは次に購入者３０の支払い口座に関係する発行者２８に連絡を取り、その取引の許可または拒絶のいずれかを受け取る。その取引が承認された場合、集金者２４には通知がなされ、お金が適切な当事者間で転送される。
【００２１】
此処で使用されるように「集金者（acquirer）」は通常ビジネス事業体であり、例えばビジネス関係を特定の売買業者またはその他の関係者と有する商業銀行である。関係者によっては発行者と集金者機能の両方を実施することが出来る。本発明の実施例はその様な単一事業体の発行者−集金者を包含している。
【００２２】
購入者３０は個人であるか、または物品またはサービスを購入できる会社のような組織である。
【００２３】
支払い処理ネットワーク２６はサーバ・コンピュータ４４、同様にデータ・ベース４８を有する。サーバ・コンピュータ４４は通常強力なコンピュータまたは、コンピュータの一群のコンピュータ（cluster of computer）である。例えば、サーバ・コンピュータは巨大なメインフレーム、ミニコンピュータ・クラスタまたは単一ユニットとして機能するサーバのグループである。１つの例において、サーバ・コンピュータはウェブ・サーバに連結されたデータ・ベース・サーバである。サーバ・コンピュータは取引を処理するためのコードを含む、コンピュータ読み取り可能媒体を含み、以下に詳細に説明するようにこれは売買業者、集金者、発行者からメッセージを受け取るためのコード、ユニークな取引識別子を生成し、それらを特定の取引に関連づけるためのコード、メッセージを送信するためのコード、発行者を識別するためのコード、および取引および不渡り手形要求をほぼ実時間で解消して解決するためのコードを含む。
【００２４】
サーバ・コンピュータ４４はまた、発行者に関連する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコード、此処で支払い指示は支払先情報の少なくとも一部を含み、そして更に此処で支払い指示は支払先とは異なる関係者によって発せられ；実質的に完全な支払先情報を決定するためのコード；および認証要求を発行者に送信するためのコード、此処で認証要求がプッシュ識別子を含む、で構成されたコンピュータ読み取り可能媒体をも含む。
【００２５】
サーバ・コンピュータ４４はまた、支払い指示メッセージを受け取るためのコード、支払い指示メッセージを読み取りその支払い指示メッセージが支払先を決定するための情報を含んでいるかを判定するためのコード、およびファジー論理を用いて支払い指示メッセージ内の情報を複数のデータ・ストアと比較し、その支払い指示メッセージに関連する支払先をほぼ同定するためのコードを含み、此処で複数のデータ・ストアが少なくとも１つの売買業者用の複数の識別子を含み、此処でその複数の識別子が、１つの名称のための識別子、１つの電話番号のための識別子、および１つの住所のための識別子を含む。
【００２６】
支払い処理ネットワーク２６は例えばVisaNet（登録商標）またはBanknet（登録商標）の様な支払い処理ネットワークを含むか使用している。支払い処理ネットワーク２６およびその支払い処理ネットワーク２６と通信を行う全ての通信ネットワークは、インターネットを含む任意のその他の有線または無線ネットワークを使用できる。支払い処理ネットワーク２６は通常の銀行カードまたはクレジット・カードを、此処に検討されているプッシュ支払い取引と共に処理するように適合されている。
【００２７】
識別システム４９は１つの取引の支払先の身元を、以下に更に詳細に説明するように、たとえ不完全な取引情報のみが与えられた場合においても決定するために使用可能である。識別システム４９は１つまた複数のサーバ・コンピュータ、１つまたは複数のデータ・ベース、またはそれらの任意の好適な組み合わせを含むことができる。或るいくつかの実施例において、識別システム４９は支払い処理ネットワーク２６の一部であって、支払い処理ネットワーク２６の一部分が識別システム４９の機能のいくつかまたは全てを実行することが可能である。これに代わる実施例において、識別システム４９は、支払い処理ネットワーク２６と通信している別のネットワークまたはコンピュータ・システムである。或るいくつかの実行例において、識別システム４９は、互いに通信している種々の独立したコンピュータ・システム上に配置された複数のデータ・ベースを含むことが可能である。
【００２８】
支払い処理ネットワーク２６の実施例はまた、多重支払い方法（multiple method of payment “MMOP”）図示せず、を含むかまたはこれに対応することの出来るデータ・センター・ハブと個別に通信している。データ・センター・ハブはプロフィール管理（profile management）、ファイル管理、メッセージ翻訳を実施し、ビジネス規則を格納して実行し、そして種々のその他のネットワークとの相互接続を行う。データ・センター・ハブの事例は米国特許出願第１１／９２９，０３３号、名称「多重支払い方法を処理するためのシステム並びに方法（System and Method For Processing Multiple of Payment）」に記載されており、これはその全部を参照することで全ての目的に対してそのまま組み込まれている。或るいくつかの実施例において、識別システム４９はその様なデータ・センター・ハブを含むことが可能である。
【００２９】
支払い処理ネットワーク２６と識別システム４９は集金者２４と発行者２８との間で動作するように図示されているが、本発明の別の実施例ではそうである必要はない。いずれか一方またはその両方は、本出願に記載された処理を容易に行えるコンピュータ装置の好適な組み合わせを含んで構わない。
【００３０】
購入者３０は接続機器３４を用いて、発行者２８または支払い処理ネットワーク２６と通信することが出来る。本発明の実施例に基づく接続機器は、任意の好適な形態を取りうる。接続機器の例として、店舗販売時点情報管理（point of sales: POS）機器、携帯電話機、PDA、パーソナル・コンピュータ(PC)、タブレット型PC、手持ち式専用読み取り機（handheld specialized reader）、セットトップボックス（set-top box）、電子式金出納器（electronic cash register :ECR）、現金自動預け払い機（ATM）、仮想金銭出納器（virtual cash register :VCR）、キオスク、セキュリティー・システム、アクセス・システムなどが含まれる。接続機器は、インターネットを介して通信を行うコンピュータ上の例えばウェッブ・ブラウザの様な、使いやすいインタフェースを含む。或るいくつかの実施例において、購入者３０は、例えば発行者２８によって主催されている講座に関連する支払いカードの様な、携帯型消費者機器を所有している。１つの形態において、支払いカードは接続機器３４と相互に作用して、送信される支払い指示メッセージを生成することが出来る。別の形態において、支払いカードは関連する支払い口座情報を含むことが可能である。購入者は支払いカード上に含まれる関連する支払い口座情報を接続機器３４か、または直接、発行者２８支払い処理ネットワーク２６に提供することができる。
【００３１】
接続機器３４はプロセッサおよび計算機読み取り可能媒体を含み、此処で計算機読み取り可能媒体は、消費者に関連する口座番号を獲得するためのコード；口座番号および取引に関わる金額を含む、認証要求メッセージを支払い処理ネットワークに送信するためのコード；およびその取引用にユニークな取引識別子を含む認証応答メッセージを受信するためのコードを含む。
【００３２】
図を簡単にするために、１人の購入者３０、１人の売り手２２、１台の接続機器３４、１人の集金者２４および１つの発行者２８が図示されている。しかしながら、理解されるように本発明の実施例において、多数の消費者、複数の携帯型機器、売買業者達、複数の接続機器、集金者達、発行者達、同様に複数のサーバ・コンピュータ、複数のデータ・ベース、複数の口座などが可能である。
【００３３】
（２．事例処理過程）
図２は、図１のシステム２０で実施される、１つの取引処理１００例の流れ図を提供している。或るいくつかの実施例において、取引処理過程はその取引の性質および含まれる個別の当事者に依存して異なるはずである。
【００３４】
ステップ１０１において、購入者が取引を開始する。先に記述されるように、取引は購入者／支払者が物品またはサービスの対価を売買業者／支払先に支払う財務取引である。この支払いは、請求書に対応した請求書支払い（bill payment）、購入カード取引、またはその他の好適な取引である。いくつかの実施例において、特定売買業者に対する複数の支払いを集計して１つの取引として支払うことが可能である。取引を開始するために、購入者は支払い指示メッセージまたは支払いファイルを準備する。この支払い指示メッセージは、取引を処理するために必要最小限の情報を含む。事例の実施例において、支払い指示メッセージは少なくとも、誰に支払うか（支払先情報）とその取引に幾ら支払うか（取引金額（transaction amount））の情報を含む。別の実施例では、支払い指示メッセージがその他の情報、例えば支払い時期、関連する請求書番号、関連する注文番号、どの通貨で取引を実行するか、発行者の名称およびその取引で使用される発行者に関連する購入者の銀行口座の識別子を含むものも有る。
【００３５】
事例の実施例において、支払い指示メッセージは一部の支払先情報を含んでいる。支払い指示メッセージはその支払先を識別するために使用されるデータを含む。此処で使用されている事例の実施例では、「一部の支払先情報」とは、或る種の情報が欠落している支払先関連データと言えて、そのデータを見ただけでは支払先を１００％同定することは出来ない。一部の支払先情報は支払先の名称、電話番号、ｅメールまたはウェッブサイト情報、住所、およびその他の識別子（例えば政府発行の税金識別子、または銀行または支払い処理ネットワークから割り当てられた特定の識別子）のいずれかまたは全てを含む。しかしながら、一部の支払先情報は支払い情報が欠落する可能性がある。この情報は不完全な支払先名称、または旧いまたは不完全な住所を含む場合がある。一部の支払先情報はまたはっきりしない情報、例えば複数の他の組織と共有されている支払先の名称または住所を含む可能性がある。ひとたび支払い指示メッセージが受け取られると、図１のシステム２０はその支払い指示メッセージを分析して、実質的に完全な支払先情報を決定する、ステップ１０４−１０６に示す通り。事例の実施例において、「実質的に完全な支払先情報」は、正しい支払先に支払いを行うことを可能とする支払先に関する情報を含む。例えば、一部の支払先情報が不完全な支払先名称および間違った住所を含む場合、支払い処理システム２０の実施例は完全な支払先名称および正しい住所を決定する。或るいくつかの実施例において、実質的に完全な支払先情報は予め定められた閾値内の精度を含む。例えば、実質的に完全な支払先情報は９５％精度以内の支払先に関する情報を含む。他の実施例ではより高いかまたはより低い、予め定められた精度、例えば７０％，８５％，または９９％を考慮している。相対的に、その取引が支払先によって開始された場合（例えば、標準のクレジット・カード取引、此処ではクレジット・カードが支払先／売買業者により「読み取り（swipe）」される）、支払先情報は１００％の精度と言える。これは、支払先情報が標準取引の中で支払先自身により提供されるからである。従って、ひとつの形態において、実質的に完全な支払先情報は取引を完成させるために十分な精度の支払先に関する情報である。
【００３６】
購入者は取引をステップ１０１において、幾らでも十分多くの方法で開始できる。実施例は支払い指示メッセージが：固有のソフトウェアで生成され、任意の転送システム、例えばファイル転送プロトコル（FTP）または安全保証FTP（secure FTP）、ｅメールなどによって支払い処理ネットワークに提出されることで転送される；書き物または電話でなされる口頭指示、郵便または本人自身により；安全保証ウェッブサイトに接続されたウェッブ・ブラウザによって；売買業者直接交換（MDEX）システム；またはその他の任意の好適な方法により、生成され転送されると考慮している。事例の実施例は更に、支払い指示メッセージが要求される情報を、例えばMicrosoft Word またはExcel の様な一般的に利用可能なソフトウェア・プログラムで作成されたファイルの中に入力することにより、生成できることを考慮している。或るいくつかの実施例において、支払い指示メッセージは直接支払い処理ネットワークに転送される。別の実施例では購入者が支払い要求を購入者の銀行（発行者）に通信し、これが次に支払い指示メッセージを支払い処理ネットワークに転送する。
【００３７】
ひとたび支払い指示メッセージが支払い処理ネットワークに送られると、プッシュ識別子がステップ１０２で追加される。このプッシュ識別子はその取引がプッシュ取引であることのラベル付けを行う。事例の実施例において、プッシュ取引は既存の支払い取引インフラを利用する。このプッシュ識別子は標準取引とは対照的にプッシュ取引を、既存のシステムが適切に識別して処理することを可能とし、またそのシステムが必要に応じてその取引に対して特定のプッシュ処理を実施することを知らしめることが可能である。ステップ１０３ａおよび１０３ｂにおいて、支払い指示メッセージが分析され、その支払い指示が完全であるか決定する。特定の実施例において、全ての要求された支払いフィールド（例えば、一部の支払先名称、支払額など）が提供され、またその支払い指示メッセージに対するその他の要求が、支払い処理ネットワークで決定されるように合致した場合に、その支払い指示は完全である。支払い指示メッセージがステップ１０３ａまたは１０３ｂで決定されるように完全でない場合、更なる支払先識別情報を要求し完全な支払い指示メッセージを生成するように、警告メッセージが購入者に送られる。更なる支払先識別情報は、それ以前には支払い指示メッセージの中に具備されていなかった支払先に関する情報、例えば電話番号、住所または先に提供された情報に代わるスペルを含む。
【００３８】
支払い指示メッセージがステップ１０３ａおよび１０３ｂで完全であると決定されると、その支払い指示メッセージはステップ１０４−１０６で更に検証され処理される。ステップ１０４−１０６は図１の支払い処理ネットワーク２６で、一部のまたは全てが実行される。或るいくつかの実施例では、ステップ１０４−１０６の一部または全てが識別システム４９で実行される。ステップ１０４において、支払い指示メッセージは一部の支払先情報を抽出するために構文解析される。先に説明したように、一部の支払先情報は完全な支払先情報に翻訳される。完全な支払先情報が既に提供されている場合、次にその支払い指示メッセージはステップ１０５に移される。事例の実施例において、支払い指示メッセージは一部の支払先情報のみを含み、見たところでは適切な支払先と厳密な照合は取れない。これは例えば、支払先名称が正しく綴られていないか情報が欠落している（“payee corp.が、提示されているが“the payee corp.”が正式な名称）の時に起こりうる。また種々の略称が一部の支払先情報の中に提示されている場合があり、例えば“corporation”に対して“corp”または“co”または“road”に対して“rd”である。一部の情報はまた複数の支払先が同一名称を有する場合にも生じる。例えば、受託業者が供給品をHome Depot店から購入したとする。国内には数百のHome Depot店が存在し、支払い指示メッセージはどの特定店に支払われるべきか特定することは出来ないであろう。更に、支払先情報の別の部分、名称に関するもの以外が、支払い指示メッセージの中に提供されている一部の支払先情報の中で欠落しているかまたは不正確な情報を有する場合がある。例えば、支払先がアルバカーキ（Albuquerque）、ニューメキシコ（New Mexico）に居住していたとする。しかしながら“Albuquerque”が一部の支払先情報の中で間違って“Alberquerque”と綴られているか、またはそれがニュージャージー（New Jersey）州に居住していると間違って識別される場合がある。また、先に説明したように住所の中に略称が存在する場合もある。事例の中には提供された唯一の情報が支払先の電話番号のみの場合もある。購入者によって提供された支払い指示メッセージ内の全てのフィールドには、不整合、欠落または不正確情報が存在しうる。
【００３９】
ステップ１０４内の情報照合処理過程は本発明の実施例の価値のある部分である。識別システム４９の実施例は与えられた情報の全体性を調べることが出来る。従って、与えられた名称が電話番号と一致しない場合、両方が住所と比較される。いくつかの実施例では、これら３つのデータ項目の２つが互いに一致し、またその第３番目が予め定められた逸脱以内である場合、合致したと見なされ、実質的に完全な支払先情報が決定される。例えば、以下の情報が支払い指示メッセージのデータ・フィールド内に含まれる：
【００４０】
支払先名称：Payee Corp.
支払先電話番号:(800)-555-5555
支払先住所: 15 Lincoln Rd. Arlington, VA 22202
【００４１】
この情報は一部の支払先情報を含んでいる可能性がある。ステップ１０４において、システム、例えば図１に関連して説明されたコンピュータ・システムは、１つの支払い指示メッセージから一部の支払先情報を抽出し、それを分析することができる。そのデータ・フィールドは識別システム４９に格納されているかまたは接続可能な複数の関係者の種々のデータ・ベースと比較することができる。これらのデータ・ベースは支払先名称の一覧表を含むことが出来る。或るいくつかの実施例において、１つまたは複数のこれらのデータ・ベースは、支払い処理ネットワークを通して支払いを受け付けるように構成された支払先の一覧表を含むことができる。データ・ベースの中に集計された支払先情報は、種々の支払者からその支払先に関して行われた複数の取引から導出される。これらの複数の取引には、銀行カード取引、クレジット・カード取引、プリペイド方式取引（stored value transaction）等を含む。種々のデータ・ベースに対する比較の後、識別システムは“Payee Corp.”は与えられた住所は存在しないと決定する。“Payee Service International”と言う名称の１つの事業体が与えられた電話番号に載せられており、また与えられた電話番号を有している。更に、“Payee Corporation”は“Payee Services International”の完全子会社であると判定された。従って、実質的に完全な支払先情報は提供された電話番号および住所情報を具備した“Payee Corporation”で構成されることになるであろう。
【００４２】
いくつかの実施例では、一部のおよび捕捉的支払先情報を具備したデータ・ベースを構築することが可能なものも有り、これにより将来の支払いメッセージがより高い精度と速度で判定されるようにしている。また、種々のサードパーティー（third parties）に対して、その様な一部のおよび捕捉的支払先情報用のデータ・ベースを採掘させることが可能なようにして、実質的に完全な支払先情報を決定できるようにもできる。料金はそのデータを運用している関係者から、そのデータを要求する関係者に課金される。
【００４３】
別の事例において、印刷間違いまたはその他の正しくない情報が提供される可能性がある。住所が“13 Linkin Lane”と与えられる場合が有るであろうし、または電話番号が“(888)555-555”として提供される可能性もある。識別システム４９は一部の支払先情報を種々のデータ・ベースと先に説明したように比較することが出来る。事例の実施例において、識別システム４９はまた、実質的に完全な支払先情報を決定する際に、ファジー論理を使用することが出来る。識別システム４９は一部の支払先情報を、実質的に完全な支払先情報の一覧表を含む、単一または複数のデータ・ストアと比較して一致を採る際に、ファジー論理を使用することが出来る。ファジー論理は不確かさの下での推論を行う技術を含み、報告システムと同様に、近代産業および消費者製品制御システムで広く使用されてきている。ファジー論理は一般的にブール代数論理の上位集合と見なされており、この中でブール代数の真値が真値の中間値で置き換えられたものである。従って、ブール代数論理が真値としてゼロか１のみしか許さない一方で、ファジー論理は真値としてゼロから１の間の任意の実数を有することを許している。或る実現例において、識別システム４９は第３者データ・ベースおよび照合システム、例えばD&B MarketMatch を含むDun & Bradstreet 製品、と通信可能であるかまたはそうでなければそこにアクセスすることが可能である。識別システム４９はまた、隠れマルコフ・モデル（HMM）、動的プログラミング・モデル、ニューラル・ネットワーク、テンプレート照合（template matcher）等の様な好適な処理過程を含むことも可能である。これらのデータ・ベース、技術およびモデルは単独でまたは組み合わせて使用できる。
【００４４】
識別システム４９はファジー論理照合、またはその他の好適なシステムを使用することが出来る。上記の事例で、識別システムは支払い指示メッセージの中に提供された電話番号“(888)555-5555”を種々のデータ・ベースと比較するためにファジー論理を使用できる。識別システムは９５％の精度で、実質的に完全な支払先情報が電話番号“(800)555-5555”を含むものと、決定する。この精度は予め定められた精度閾値と比較できる。この閾値は支払い処理ネットワーク、支払者、発行者、集金者、または此処に開示されている実施例に基づくプッシュ取引に関係するその他の関係者によって設定可能である。識別システム４９は予め定められた９５％の精度閾値を有している。上記の事例で、実質的に完全な支払先情報は十分に正確であり、支払い処理はステップ１０５へ継続される。別の実施例において、識別システムが９９％の予め定められた閾値を有する場合がある。上記の事例では、実質的に完全な支払先情報は十分に正確とは言えない。より高い精度の照合が得られない場合、取引処理はステップ１０５で終了し、更なる支払先識別情報が無いとプッシュ支払いが出来ない旨の、１つのメッセージが購入者へ送られる。
【００４５】
一部の支払先情報内に提供された各々のデータ・フィールドは、先にステップ１０４に関連して説明したように、適切なデータ・ベースと比較され、ファジー論理照合で分析される。種々のデータ・フィールドには分析中に重みがかけられる。ひとたび全てのフィールドの処理が、個別並びに組み合わせでなされると、実質的に完全な支払先情報が、可能な最も高い精度で決定される。従って、ステップ１０５において、取引を実行するために必要な全ての更なる情報が決定され、支払い指示メッセージに添付される。これには、支払い経路情報、ネットワーク識別子などが含まれる。支払い処理システムはまた、当業分野で知られているように、その取引に対するリスク評価処理を適用できる。ステップ１０６において、実質的に完全な支払先情報の精度が予め定められた閾値より高い場合、支払い指示メッセージは翻訳されステップ１０７に基づいて処理される。或るいくつかの実施例において、予め定められた閾値以上である必要がある一方で、別の実施例ではその精度は予め定められた閾値より高くなければならない。
【００４６】
購入者が此処に開示されている実指令に基づくプッシュ支払いを第１回目に行う際には、一部の支払先情報と実質的に完全な支払先情報の照合は先に説明したように実施される必要がある。一度実質的に完全な支払先情報が決定されると、識別システム４９はその支払先にユニークな支払先識別子、または「売買業者識別子（merchant identifier）」を割り当て、将来のプッシュ支払いで使用できるようにする。識別システム４９はまた、購入者識別子をその購入者に割り当てることも出来る。この購入者識別子は、誰がプッシュ支払いを行っているか、またどの金融口座が使用されるのかを迅速に識別するために使用できる。売買業者識別子および購入者識別子はその購入者に送られる。従って購入者はそれらの支払い処理ネットワークが生成した識別子を将来のプッシュ支払いで使用して、精度の向上と取引の迅速化を図ることができる。
【００４７】
識別システム４９はまた、売買業者識別子と購入者識別子とが他の与えられた情報と相関を取るように、データ・ベースを生成したり修正変更したりすることが可能である。これは購入者がベンダーに対して、その逆もあり、内部的に割り当てた、識別子を含む場合がある。例えば、会社Ｘはコンピュータ供給品をベンダーＹからしばしば購入しているとする。会社ＸはベンダーＹに識別子“VY123”を割り当て、ベンダーＹは会社Ｘに識別子“CX-AB5”を割り当てる。これらの識別子が、取引を開始する支払い指示メッセージの中に与えられると（さもなければ識別システム４９に対して既知）、識別システム４９はその識別子を、データ・ベース４８の様なデータ・ベースの中に格納できる。そのデータ・ベースは、これらの識別子をその他の識別情報に写像（map）できる。例えば、識別子“VY123”および“CX-AB5”は各々、支払い処理ネットワークで割り当てられた１つのユニークな識別子、そしてまたそれぞれの会社の名称および住所に写像される。従って、会社ＸがベンダーＹに対する支払いを行うプッシュ支払いを識別子VY123を使用して開始する場合、実質的に完全な支払先情報の決定に際して１００％の精度が得られる。
【００４８】
ステップ１０７を参照すると、支払い指示メッセージ（これは先に決定された実質的に完全な支払先情報を含む）が認証要求の形式に翻訳される。この認証要求メッセージは従来のクレジット・カード処理メッセージで使用されている形式で構わない。或るいくつかの実行例において、支払い指示メッセージは当業分野でBase1認証要求メッセージとして知られているものに翻訳される。従来取引において、認証要求メッセージは支払先／販売者により生成される。しかしながら、或るいくつかの実施例では支払い処理ネットワークがステップ１０７の認証要求メッセージを、購入者から提供された情報を用いて生成しもそのネットワークで処理される。ステップ１０７で生成された、翻訳済み認証要求メッセージはその取引を継続するために要求される全ての情報を含み、実質的に完全な支払先情報、取引額、購入者が支払いを行うためにどの口座を使用するか、を含む。認証要求メッセージは従来のクレジット・カード処理で生成されるものとほとんど同じである。事例の実施例において、認証要求メッセージは、ステップ１０７で生成された認証要求メッセージがステップ１０２で生成されたプッシュ識別子を含むことを除き、従来のものと全く同一である。
【００４９】
認証要求メッセージは次にステップ１０８で支払い処理ネットワークにより、発行者に送られる。発行者は購入者に関連する銀行口座を管理する銀行である。或るいくつかの実施例において、購入者は発行者を通して取引を開始しており、これは従って支払い処理ネットワークに連絡を取っている。別の実施例において、購入者は支払い指示メッセージの中で発行者を特定することができる。ステップ１０９において、発行者はその取引が認証されているか（すなわち承認されているか）を判定する。発行者は当業分野で知られているように、ある種のリスク・システムおよびその他の認証処理過程を起動させる。発行者は購入者の口座に十分なクレジットおよび／または資金が存在する場合、その取引を認証するはずである。発行者は十分なクレジットおよび／または資金が存在しない場合、認証しないであろう。更に、発行者は或る特別な処理をプッシュ支払い要求に適用し（メッセージの中にプッシュ識別子が有るため）、これは例えば特別報償または値引きの提供である。
【００５０】
取引が断られると、その取引は終了し辞退メッセージが支払い処理ネットワークに送られ、これはそのメッセージを購入者に回送される。取引が認証された場合、発行者は支払い処理ネットワークに警告を発する。認証ログを含む認証応答メッセージがステップ１１０ａおよび１１０ｂで生成される。この認証ログは支払い処理ネットワーク、または発行者で生成されて支払い処理ネットワークへ回送される。認証ログは当業分野で知られているように、帳票処理システム・ファイルと清算ファイルの様な、帳票処理と清算データを含む。認証ログはまたプッシュ取引用の更なる情報、例えばプッシュ識別子を含むように、を増加させることが可能である。認証ログはまた基本的な取引に関わる情報、例えば関連する請求書番号、関連する購入注文書番号、および購入者の名称をも含むはずである。或るいくつかの実施例において、認証ログは特定集金者の要求に従うようにカスタマイズすることが可能である。認証応答メッセージ（認証ログを含む）は集金者によりステップ１１１で受け取られる。事例の実施例において、認証応答メッセージは集金者がその取引に関して受け取る最初の通知である。認証応答メッセージは、購入者から支払先に支払いが行われることの、集金者に対する警告として機能できる。従って、いくつかの実施例において集金者は取引が発行者によって認証された後にのみ連絡される（すなわち、認証要求メッセージが発行者に対して、集金者と何らかの通信を始める前に送られる）。これは、集金者が関与する取引上のステップが少なくなり、認証することなく最終的に終了される取引を処理することがないので、取引速度と効率を増加させる。
【００５１】
取引が承認された後、通常の清算および支払い処理が開始できる。集金者は、資金の流れに関する勘定調整（reconciliation）メッセージ（例えば、勘定調整報告）を支払い処理ネットワークに送り、これは続いてこのメッセージを発行者に回送する。この勘定調整メッセージは支払者情報（例えば購入者名称）、請求書番号、および購入注文書番号を含む。集金者はまたステップ１１３で勘定調整メッセージを売買業者に送る。ステップ１１２において、資金は発行者に関する購入者の財務口座から集金者に支払われる。或るいくつかの実施例において、発行者はその取引に関連する資金を支払い処理ネットワークに送金かることができる。支払い処理ネットワークは次にその資金を支払先またはその支払先に関係する口座（例えば集金者の口座）に送金することができる。或るいくつかの実施例において、勘定調整メッセージを資金が支払われるのと同時に支払先に送ることができる。集金者に関連する支払先の口座は実行される取引の支払いに使用される資金から、手数料を減算した分増大する。発行者に関連する購入者の口座は、その資金と同額に手数料を加算した分減少する。この方法によってお金が転送できる。この資金の流れは勘定調整メッセージ内の情報を参照することが可能であり、従って全ての関係者はお金の流れの目的および対応する取引情報を知ることができる。従って、先に記述した方法によって、購入者は支払いを売買業者に「プッシュ」することができる。これは購入者が支払い方法並びにスケジュールに関して、従来の支払い方法と比較して大きな制御権を持つことを許す。更に、クレジット・カード処理取引を処理するためのシステムを利用できる。これはクレジット・カード取引の全ての利点を、プッシュ・モデル、例えば購入注文書支払いに対して、提供することができる。利点には高い安全性および詐欺防止、処理中の実時間または準実時間で実行されるリスク評価、累積ポイント還付の様な報償プログラムへのアクセス能力など、が含まれる。更に、先に説明したシステムおよび方法の実施例はまた、集金者の関与が、支払いが認証された後のみである、強化された処理フローを用いることで既存のクレジット・カード取引をも改善する。実施例はこれらおよびその他の利点を、以下に更に詳細に説明するように含む。
【００５２】
図３はプッシュ取引の１つの実施例を、実質的に完全な支払先情報を決定するための照合処理過程を強調して示す。この実施例において、支払い指示メッセージは先に説明したように購入者によって準備され、図１に示すサーバ・コンピュータの様な支払い処理ネットワークで受け取られる。ステップ１において、支払い処理ネットワーク２６はその支払い指示メッセージを再審理（すなわち「検証」）して、全ての要求された情報が存在するか、例えば一部の支払先情報を判定する。支払い指示メッセージが重要情報を欠いている場合、この取引はステップ１ａに示されるように処理されないであろう。支払い指示メッセージが検証されると、これはその支払先を決定するために、識別システム４９に送られる。ステップ２において、識別システム４９は支払い指示メッセージを構文解析（すなわち、再審理）して、そのメッセージが購入者識別子を含んでいるか、および一部の支払先情報が売買業者識別子を含むかを判定する。これらの識別子の実施例は図２に関連して、先に説明されている。或るいくつかの実施例において、これらの識別子は識別システム４９のデータ・ベース内に格納されており、それらは特定の、ユニークな事業体に各々写像されることが確認されている。従って、売買業者識別子と購入者識別子が与えられると、識別システム４９はほぼ完全（１００％）な精度で実質的に完全な支払先情報を決定できる。支払い処理ネットワーク２６は次に、ステップ６で認証要求メッセージを生成するために必要な全ての情報を添付することが可能であり、次にその認証要求メッセージをステップ７で従来の手段によって処理する。（すなわち、認証、支払い清算および決済）。
【００５３】
支払い指示メッセージが少なくとも１つの売買業者識別子を含まない場合、識別システム（これはサーバ・コンピュータで構成できる）は、与えられている一部の支払先情報の分析を実施して、実質的に完全な支払先情報を決定する。この一部の支払先情報はステップ３で種々のデータ・ベースと比較され、予め定められた基準、識別システムに格納されている支払先記録に基づいてその情報が一致するか判定する。一致が存在しない場合、取引失敗メッセージがステップ２ａで購入者へ送られる。事例の実施例では、ファジー論理照合が使用できる。１つの一致が有る場合、一部の支払先情報はステップ４で分析され、複数の一致記録が存在するか判定される。或るいくつかの実施例において、唯１つの一致のみが必要とされ、もしステップ４で更に別の記録が見つからない場合、取引はステップ６に継続できる。別の事例の実施例において、一部の支払先情報は識別システム４９によってアクセスされたデータ・ベースに格納されている複数の記録と一致しなければならない。従って、これらの実施例のステップ４において、更に別の記録が一部の支払先情報と一致しない場合、取引失敗メッセージがステップ２ａで購入者に送られる。
【００５４】
複数の一致記録が発見されると、全ての一致記録が比較され最も精度の高い１つが決定される。１つの実行例において、識別システム４９は一致記録の種々のデータ・フィールドに重要性に基づいて階級を付けることが可能であり、最も高い階級付けをされた一致データ・フィールドを具備した一致記録が選択される。例えば、一致記録は売買業者の税金識別子、売買業者の名称、および住所並びに郵便番号を含む。識別システムは重要性に基づいてフィールドの階級付けを行う。従って、税金識別子フィールドは最も重要性が高く、名称が２番目、住所が３番目そして郵便番号が４番目である。
【００５５】
１つの事例において、識別システムは、少なくとも或る程度一致している、次の様に与えられた一部の支払先情報：FredCo, 15 Broadlawn Drive, OH, 11111、税金識別子は与えられていない、に対して一致する３つの記録を判定する。第１照合記録は郵便番号の完全な一致、街路住所は一致しているが街路番号は一致せず（例えば、12 Broadlawn Drive）、そして一部の支払先情報の中に提供されている売買業者名称は一致していない。第２照合記録では売買業者名称が一致するか、住所が予め定められた許容偏差内で（例えば、15 Broadlawn Dr., Ohio）一致し、そして郵便番号が一致しているかも知れない。第３照合記録は、名称も郵便番号も不一致であるが、住所が一致しているかも知れない。上記の与えられた事例では、第２照合記録が最も高い階級の一致データ・フィールドを有し、これが選択される照合記録となるであろう。
【００５６】
ステップ５において、選択された照合記録が分析されて精度が判定され、支払い清算データが決定できる。精度が予め定められた閾値未満の場合、ステップ２ａで取引失敗メッセージが購入者に送られる。精度が予め定められた閾値より上の場合、実質的に完全な支払先情報が決定される。支払い清算データは、その実質的に完全な支払先情報で識別された支払先に対して決定される。支払い清算データはその支払先に関係する集金者に対する連絡先情報の様な、情報を含むことができる。この支払い清算データは支払い要求メッセージ、実質的に完全な支払先情報およびプッシュ識別子と結合して、認証要求メッセージをステップ６で生成することができる。従って、上述の処理は取引を完了するために実施される。
【００５７】
（３．携帯型機器およびコンピュータ装置）
図４（ａ）−４（ｂ）は携帯型消費者機器および、本発明の実施例に基づくシステム内のコンピュータ装置の中に存在するであろうサブシステムのブロック図を示す。
【００５８】
本発明の実施例の中で使用される携帯型消費者機器は任意の好適な形状を取りうる。例えば、好適な携帯型消費者機器は手持ち式でコンパクトであり、消費者の財布および／またはポケットに収まるものである（例えば、ポケットサイズ）。それらには、スマートカード、例えば支払いカードの様な通常のクレジットまたは銀行カード（マイクロプロセッサ無しの磁気ストライプ方式）、キーホルダ機器（例えば、エクソン・モービル社から市販されているSpeedpass（登録商標））などが含まれる。携帯型消費者機器のその他の例として、携帯電話機、携帯端末、ポケットベル（pager）、支払いカード、セキュリティー・カード（security card）、アクセス・カード（access card）、スマート・メディア（smart media）、トランスポンダ（transponder）などが含まれる。携帯型消費者機器はまた、借り方機器（debit devices）（例えば銀行カード）、クレジット機器（例えば、クレジット・カード）またはプリペイド機器（stored value devices）（例えばプリペイド・カード）も考えられる。
【００５９】
電話機の形状の携帯型消費者機器３２’の例は、図４（ａ）に示すようにコンピュータ読み取り可能媒体と本体とで構成されている。（図４（ａ）は多数の構成部品を示しており、本発明の実施例に基づく携帯型消費者機器はその様な構成部品の任意の好適な組み合わせまたはそれらの一部分を含んで構成することも可能である。）コンピュータ読み取り可能媒体３２（ｂ）は、本体３２（ｈ）の内部に存在するかまたは、それと取り外し可能である。本体３２（ｈ）はプラスチック基材、格納ケース、またはその他の構造の形式が考えられる。コンピュータ読み取り可能媒体３２（ｂ）はデータを格納しているメモリであり、磁気ストライプ、メモリ・チップ、暗号化アルゴリズム、秘密または秘密鍵などを含む任意の形式で構わない。メモリはまた好適に財務情報、通行情報（例えば、地下鉄または電車の定期として）、アクセス情報（例えば、入室バッチとして）などの情報を格納する。財務情報には、銀行口座情報、銀行識別番号（BIN bank identification number）、クレジットまたは銀行カード番号情報、勘定残高情報、有効期日、名前、生年月日の様な消費者情報などが含まれる。
【００６０】
メモリ内の情報はまた、従来からクレジット・カードに関連している、データ・トラックの形式でも構わない。その様なトラックはTrack1とTrack2を含む。Track1（国際航空運送協会“International Air Transport Association”）はTrack2よりも多くの情報を格納し、カード所有者の名前と同様に口座番号およびその他の自由裁量データを含む。このトラックは、クレジット・カードで予約を確保する際に航空会社でしばしば使用される。Track2 （米国銀行協会“American Banking Association”）は現在最も一般的に使用されている。これはATMおよびクレジット・カード照合器で読み取られるトラックである。ABA（米国銀行協会“American Banking Association”）はこのトラックの仕様が全世界の銀行がそれに耐えうるように設計している。これはカード所有者の口座、暗証番号（PIN）それに加えて、自由裁量データを含む。
【００６１】
携帯型消費者機器３２’は更に、非接触要素３２（ｇ）を含み、これは典型的には、関連する無線伝送（例えば、データ転送）素子、例えばアンテナ、を具備した半導体チップ（またはその他のデータ格納素子）の形状で実現されている。非接触要素３２（ｇ）は携帯型消費者機器３２’と関連づけられており（例えば、その中に組み込まれている）、携帯電話ネットワーク経由で送信されるデータまたは制御指令は非接触要素３２（ｇ）に非接触要素インタフェース（図示せず）により、供給される。非接触要素インタフェースは、モバイル機器回路（従って、携帯電話ネットワーク）とオプションの非接触要素３２（ｇ）との間でデータおよび／または制御指令の交換ができるように機能する。
【００６２】
非接触要素３２（ｇ）は近距離通信（NFC near field communication）能力（または近距離通信媒体）を用いて、典型的には標準化されたプロトコルまたはデータ転送機構（例えば、ISO 14443/NFC）に基づき、データの送信および受信を行える。近距離通信能力は短距離通信能力、例えばRFID, Bluetooth（登録商標）,近赤外線、またはその他の携帯型消費者機器３２とインターロゲーション機器（interrogation device）との間でデータ交換に使用できるデータ転送能力である。従って、携帯型消費者機器３２は携帯電話ネットワークと近距離通信能力の両方を介してデータおよび／または制御指令を通信しかつ転送することが可能である。
【００６３】
携帯型消費者機器３２’はまた携帯型消費者機器３２’の機能を処理するためのプロセッサ３２（ｃ）（例えば、マイクロプロセッサ）および消費者が電話番号およびその他の情報およびメッセージを見ることをできるようにするための表示器３２（ｄ）を含む。携帯型消費者機器３２’は更に、消費者が機器に情報を入力できるようにする入力素子３２（ｅ）、消費者が音声通信、音楽などを聴けるようにするスピーカ３２（ｆ）および消費者が携帯型消費者機器３２’を通して、その音声を伝送できるようにするマイクロフォン３２（ｉ）を含む。携帯型消費者機器３２’はまた無線データ転送用（例えば、データ送信）のアンテナ３２（ａ）を含む。
【００６４】
携帯型消費者機器３２’は購入者がプッシュ支払いを開始するためにも使用できる。いくつかの実行例において、携帯型消費者機器３２’は購入者が支払い要求メッセージを生成することを可能とするインタフェースを含む。携帯型消費者機器３２’は従って、支払い要求メッセージを支払い処理ネットワークへ非接触要素３２（ｇ）または無線または有線通信を経由して送ることが可能である。
【００６５】
カード形式の携帯型消費者機器３２”の１例が図４（ｂ）に示されている。図４（ｂ）はプラスチック基板３２（ｍ）を示す。接続機器３４とインタフェースするための非接触要素３２（ｏ）がプラスチック基板３２（ｍ）上に存在するかまたはその中に組み込まれている。口座番号、有効期限、および消費者名の様な消費者情報３２（ｐ）がカード上に印刷されているかまたは刻印されている。また、磁気ストライプ３２（ｎ）もまた、プラスチック基板３２（ｍ）上にある。
【００６６】
図４（ｂ）に示すように、携帯型消費者機器３２”は磁気ストライプ３２（ｎ）と非接触要素３２（ｏ）の両方を含んでいる。別の実施例では磁気ストライプ３２（ｎ）と非接触要素３２（ｏ）の両方が携帯型消費者機器３２”の中に有る。別の実施例では、磁気ストライプ３２（ｎ）または非接触要素３２（ｏ）のいずれかが携帯型消費者機器３２”の中に存在する。いくつかの実現例において、携帯型消費者機器３２”は購入カードで構成することが可能である。購入カード３２”は購入者に関係する購入者識別子、その購入者によって管理され、支払いに使用される１つの口座に関する口座番号、またはその他の識別情報を含む。この識別情報は上記のように支払い指示メッセージを生成する際に購入者により使用できる。
【００６７】
図１に示す種々の関係者および要素は、此処に記述されている機能を容易にするために１つまたは複数のコンピュータ装置を運用または使用するはずである。図１の全ての要素（例えば、接続機器３４、売買業者２２、集金者２４など）は、此処に記述されている複数の機能を容易にするために任意の好適な数量のサブシステムを使用するはずである。その様なサブシステムまたは構成要素の例が図５に示されている。図５に示すサブシステムはシステム・バス７７５経由で相互接続されている。プリンタ７７４、キーボード７７８、固定ディスク７７９（または計算機読み取り可能媒体を含むその他のメモリ）、モニタ７７６、これは表示器アダプタ７８２に結合されている、およびその他が図示されている。Ｉ／Ｏ制御器７７１に接続する、周辺機器および入出力（Ｉ／Ｏ）装置は、例えばシリアル・ポート７７７の様な、当業分野で知られている任意の多くの手段でコンピュータ・システムに接続される。例えば、シリアル・ポート７７７または外部インタフェース７８１は、コンピュータ装置をインターネットの様な広域ネットワーク、マウス入力機器、またはスキャナと接続するために使用できる。システム・バスを介した相互接続は中央処理装置７７３が各々のサブシステムと通信し、システム・メモリ７７２または固定ディスク７７９からの命令の実行を制御し、また同様にサブシステム間での情報交換を行うことを可能とする。システム・メモリ７７２および／または固定ディスク７７９は計算機読み取り可能媒体を具現化している。
【００６８】
本発明の実施例は上述の実施例に限定されるものでは無い。例えば、発行者、支払い処理ネットワーク、および集金者に関して別々の機能ブロックとして示されているが、事業体によってはこれら機能の全てを実行し、発明の実施例に包含される。
【００６９】
上述の本発明は、モジュール型または統合方式の計算機ソフトウェアを用いた制御ロジックの形式で実現できることを理解されたい。此処に提示する開示および教えに基づき、通常の技量を有する当業者は、ハードウェアおよびハードウェアとソフトウェアの組み合わせを用いて、本発明を実現するためのやり方および／または方法を知り、かつ理解することが可能である。
【００７０】
本出願に記述されているソフトウェア構成要素または機能のいずれも、例えば従来方式またはオブジェクト指向技術を使用して、任意の好適な計算機言語、例えばJava（登録商標）, C++またはPerlで実行されるソフトウェア・コードとして実現される。ソフトウェア・コードは一連の命令（instruction）、または指令（command）として計算機読み取り可能媒体、例えば随意アクセス・メモリ（RAM）、読み取り専用メモリ（ROM）、ハードディスクまたはフロッピー（登録商標）ディスクの様な磁気媒体、またはCD-ROMの様な光学媒体の上に格納される。その様な計算機読み取り可能媒体のいずれも、単一計算装置上またはその内部に常駐するか、システムまたはネットワーク内の異なる計算装置の上または内部に存在している。
【００７１】
本発明の実施例は多くの長所を有する。或るいくつかの実行例において、支払い取引の受益者（すなわち、支払先）はいずれのシステムに登録したり選択したりする必要が無い。支払者は既に支払いを受けることが可能な全ての事業体に、クレジット・カードまたはその他の手段で支払いをプッシュすることができる。更に、支払者はその取引の金額および時機に対する制御を保持している。支払先および関連する事業体（例えば集金者）は、最終的に発行者に承認されない取引に悩まされる必要が無いので、これはシステム効率を向上させ無駄を防止する。取引の全ての関係者は、強化された詐欺およびリスク検知、また同様に報償およびその他の有益なプログラムを利用することができる。
【００７２】
以上の説明は実例として示すことが目的であって制限するものではない。当業者には開示を見直すことにより、本発明の多くの変形が明らかとなろう。従って、本発明の範囲は上述の説明を参照して決定されるのではなく、代わりに添付の特許請求項の全範囲またはその等価なものを参照して決定されるべきである。
【００７３】
いずれかの実施例の１つまたは複数の特徴は、他のいずれかの実施例の１つまたは複数の特徴と、本発明の範囲から逸脱することなく組み合わすことができる。
【００７４】
“a”（ひとつの）、“an”（ひとつの）または“the”（その）という言い回しは特にその反対の意味であると断りがない限り、“one or more”（ひとつまたは複数の）を意味することを意図している。“she”（彼女）という記述は中性を意味し、特に反対の意味であると断りが無い限り“he”or“she”（彼または彼女）と読まれるものである。
【００７５】
先に言及した全ての特許、特許出願、発行物、および記述は此処に参照することで、全ての目的に対してそっくりそのまま組み込まれている。いずれも従来技術と自認するものではない。
【技術分野】
【０００１】
（関連出願）
本出願は暫定的なものではなく、米国特許出願第６１／０２１，２８９号、２００８年１月１５日出願の優先権を主張するものであり、この出願は此処に参照することにより全ての目的に対してそのまま組み込まれている。
【背景技術】
【０００２】
多数の支払い方法およびシステムが存在する。例えば、購入者が１枚のクレジット・カードを売買業者に提示し、彼はそのクレジット・カードを「読み取り機に通して（swipe）」、支払いをそのクレジット・カードに関係する銀行から受け取ることが出来る。この方法は多くの長所を有し、強化された詐欺検出およびセキュリティーを含む。しかしながら、クレジット・カード（またはカード番号およびセキュリティー・コード）が、取引処理が生じる前に販売者に対して最初に提示されなければならない。従って、その販売者および全ての販売者に関係する銀行は、その取引にたとえその取引が完結しない場合でも最初から関与していなければならない。更に、その購入者は支払いが販売者に何時振り替えられるかを、簡単に予定計画することが出来ない。
【０００３】
別の支払い方法、例えば小切手、自動清算処理装置（automated clearing house：ACH）システムの使用、電信送信等が存在する。これらの方法の長所は、売買業者がクレジット・カード支払いの様には、支払い処理に関与する必要が無いことである。しかしながら、支払い方法は制限されている。例えば、危険事前評価も強化されていないし、または購入者または売買業者に対する報償計画も提供していない。電信送金は実施するのは面倒であり、使用時間および送金可能額が制限されている。小切手は受取者によって現金化されるまでしばらく時間が掛かる。その時間の間、購入者はその小切手の状態、またはその資金が何時その購入者の口座から引き落とされるかを知ることが出来ない。更に、小切手の紛失または盗難といった本来的な危険が存在する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施例は上記の問題、およびその他の問題を、個別にまた全体的に解決する。
【課題を解決するための手段】
【０００５】
本発明の実施例はプッシュ取引を実施するためのシステム及び方法を含み、此処で支払者は支払先への支払いを、支払先からの干渉をほとんど知ること無しに開始できる。
【０００６】
１つの実施例は、取引を処理するためのコンピュータを用いた方法を指向している。この方法は、支払い指示メッセージをサーバ・コンピュータで受け取り、此処で支払い指示メッセージはその発行者に関係する口座を用いて、支払先への支払いを行うものであり、此処でその支払い指示メッセージは少なくとも支払先情報の一部を含み、また更に此処で支払い指示メッセージは支払先とは異なる事業体から発せられたものであり、その支払い指示メッセージを再審理し、実質的に完全な支払先情報を決定し、そして認証要求メッセージを支払い指示メッセージの再審査後に発行者に送ることを含み、此処で認証要求がプッシュ識別子を含む。
【０００７】
別の実施例は、支払いを行うコンピュータを用いた方法を指向している。この方法は少なくとも支払先情報の一部、取引額、および支払時期を含む支払い指示メッセージをサーバ・コンピュータへ送り、此処でその支払い指示メッセージがサーバ・コンピュータで実質的に完全な支払先情報を決定するために構文解釈され、認証ログが支払先に関連する集金者に送られ、そしてお金が支払先に送金されることで構成されている。
【０００８】
別の実施例は、プッシュ支払い取引を受けとるためのコンピュータを用いた方法を指向している。この方法は取引に関係する認証ログを受け取り、此処でその認証ログは報告システム・ファイルと清算ファイルを含み、その取引の資金の流れに関するメッセージを送信し、その取引に関係する資金を受け取り、その資金を支払先に送金し、そして取引情報を支払先に送ることで構成されている。
【０００９】
別の実施例は、プッシュ取引を実施するためのコンピュータ読み取り可能媒体を指向している。この媒体は発行者に関係する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコード、此処で、支払い指示は少なくとも支払先情報の一部を含み、そして更に此処で支払い指示メッセージは支払先とは異なる事業体から発せられたものであり、その支払い指示メッセージを再審査するためのコード、実質的に完全な支払先情報を決定するためのコード、および認証要求を発行者に送るためのコードを含み、此処で認証要求がプッシュ識別子を含む。
【００１０】
本発明の別の実施例は、取引における支払先を識別するためのコンピュータ読み取り可能媒体を指向している。この媒体は支払い指示メッセージを受け取るためのコード、支払い指示メッセージを再審査し、その支払い指示メッセージが支払先を決定するための情報を含んでいるか否か判定するためのコード、および支払い指示メッセージ内の情報を、その支払い指示に関連する支払先を実質的に識別するために、複数のデータ・ストアとファジー論理を用いて比較するためのコードを含み、此処で複数のデータ・ストアは少なくとも１人の販売者を識別するための複数の識別子を含み、此処で複数の識別子は名称の識別子、電話番号の識別子、および住所の識別子を含む。
本発明のこれらおよびその他の実施例は、添付図および詳細な説明を参照して更に詳細に説明されている。
【図面の簡単な説明】
【００１１】
【図１】図１は、本発明の１つの実施例に基づくシステムのブロック図。
【図２】図２は、本発明の１つの実施例に基づく方法を図示する流れ図。
【図３】図３は、本発明の１つの実施例に基づく方法を図示する流れ図。
【図４】図４は、携帯型消費者機器のブロック図を示し、（ａ）は電話機形式の携帯型消費者機器（ｂ）はカード形式の携帯型消費者機器を示す。
【図５】図５は、コンピュータ装置のブロック図を示す。
【発明を実施するための形態】
【００１２】
本発明の実施例は、支払いを行う側から開始される支払い処理のシステムおよび方法を指向している。言葉を変えれば、支払先から「プル（pull）」されるものではなく、支払者から「プッシュ（push）」される取引である。或るいくつかの実施例において、第１当事者（例えば、取引の購入者）は標準クレジット・カード処理システムを用いて、支払い資金を第２当事者（例えば販売者）に、第２当事者と何らの相互交渉を行うことなく送金することが可能である。第２当事者は第１当事者から支払いがなされ、関連する資金が第２当事者の口座へ入金されたことの通知を受け取ることが可能である。
【００１３】
本発明の実施例は他の事業体へ支払いを行う企業で使用することが出来る。例えば、購入者が供給者から物品を購入する。その様な１つの例において、レストラン企業がナプキンを大量にナプキン供給者から購入する。購入者はそれらの物品の請求書を受け取る。従来の処理では、購入者はその請求書に対して小切手を供給者に送ることで支払いを行う。しかしながら、小切手による支払いは、上述の様な制約を受ける。本発明の或る実施例において、購入者は代わりにその請求書を支払うためにプッシュ支払いを行うことが出来る。これらの実施例では支払い指示メッセージが購入者の銀行（「発行者（issuer）」）または支払い処理ネットワーク、例えばVisaNet（登録商標）,またはBanknet（登録商標）に電子的に送信されるものと考えている。
【００１４】
支払い指示メッセージはある種の情報、例えば供給者の名称、支払額、支払い時期など、を含むことが出来る。支払い処理ネットワークは、支払い指示メッセージ内の情報を用いて、その支払いを行う適切な事業体を決定することが出来る。例えば、支払い指示メッセージの中には支払先情報の或る一部分のみ、例えば供給者名または住所の一部のみしか含まないものもある。上記の例では、ナプキン供給者は「ナプキン株式会社（The Napkin Company）」であるかも知れない。しかしながら、レストラン会社ではそれを「ナプキン社（Napkin Co.）」とだけ呼んでいるかも知れない。従って、支払い処理ネットワークは、与えられた情報に基づいて、実質的に完全に支払先情報を決定することが出来る。これは、ファジー論理マッチング（fuzzy logic matching）により、部分情報を供給者一覧表のデータ・ベースと比較することで実施可能であり、また本発明の実施例に基づくその他の技術も同様に以下に更に詳細に説明される。この様にして、支払い処理ネットワークは適切な支払先は「ナプキン株式会社（The Napkin Company.）」と決定できる。
【００１５】
ひとたび、供給者の完全な支払先情報が決定されると、支払い処理ネットワークは発行者から支払いを要求するメッセージ（「認証要求メッセージ」（“authorization request message”））を作成できる。いくつかの実施例において、認証要求メッセージはどの様な特定標準メッセージ・システムにも適合することが出来る（すなわち、支払い処理システムは支払い処理メッセージを１つの工業標準フォーマットに翻訳する。）別の実施例では、認証要求メッセージはユニークなフォーマットと出来る。
【００１６】
ひとたび発行者が認証要求を受け取ると、その取引の承認または拒否が可能である。拒否される場合、拒否メッセージが購入者に送り返される。認証されると、支払い処理ネットワークは認証ログをその供給者に関連する銀行へ送られる。例として示す実施例において、この認証ログが、取引が購入者によって開始されたという、この銀行への第１通知である。発行者の取引を認証する処理は「認証（authorization）」と呼ばれる。この認証ステップは銀行と購入者に対して、取引が継続出来ることの注意を喚起する。支払いは一般的にこの認証ステップが実行された後に生じる。支払いは、発行者から供給者へ、または銀行または供給者の系列のその他の公共機関へ資金が引き落とされた時に発生する。
【００１７】
本発明の具体的な実施例を、図１−５を参照して説明する。
【００１８】
（１．例示システム）
図１は本発明の１つの実施例に基づくシステム２０を示す。本発明に基づくその他のシステムは、図１に具体的に示されたものよりも少ないかまたは多い部品を含む。
【００１９】
図１は購入者３０、接続機器３４、売り手２２、集金者２４、支払い処理ネットワーク２６、および発行者２８を互いに通信出来る状態で示している。集金者２４および発行者２８は支払い処理ネットワーク２６を通して通信可能である。先に記述したように、「発行者」は通常はビジネス事業体（例えば銀行）であって、購入者の金融口座を管理し、またしばしばクレジットまたは銀行カードの様な携帯型消費者機器を購入者に発行する。「売り手」は通常取引に関わる１つの関係者であって、例えば小売店（store）、納入業者（supplier）、売買業者（merchant）、個人またはサービス提供者である。接続機器３４は購入者３０によって使用され、システム内の他の事業体と通信し、コンピュータ、電話機またはその他の通信手段を含む。
【００２０】
１つの典型的な支払い取引において、購入者（すなわち「支払者」）３０は物品またはサービスを売り手２２に注文する。購入者３０は次にその購入に対する支払い指示を、接続機器３４を用いて送信する。接続機器３４はその支払い指示を発行者２８または直接支払い処理ネットワーク２６に伝送する。支払い処理ネットワーク２６は識別システム４９を用いてその支払い指示を解析し、適切な売り手の身元を判定できる。支払い処理ネットワークは次に購入者３０の支払い口座に関係する発行者２８に連絡を取り、その取引の許可または拒絶のいずれかを受け取る。その取引が承認された場合、集金者２４には通知がなされ、お金が適切な当事者間で転送される。
【００２１】
此処で使用されるように「集金者（acquirer）」は通常ビジネス事業体であり、例えばビジネス関係を特定の売買業者またはその他の関係者と有する商業銀行である。関係者によっては発行者と集金者機能の両方を実施することが出来る。本発明の実施例はその様な単一事業体の発行者−集金者を包含している。
【００２２】
購入者３０は個人であるか、または物品またはサービスを購入できる会社のような組織である。
【００２３】
支払い処理ネットワーク２６はサーバ・コンピュータ４４、同様にデータ・ベース４８を有する。サーバ・コンピュータ４４は通常強力なコンピュータまたは、コンピュータの一群のコンピュータ（cluster of computer）である。例えば、サーバ・コンピュータは巨大なメインフレーム、ミニコンピュータ・クラスタまたは単一ユニットとして機能するサーバのグループである。１つの例において、サーバ・コンピュータはウェブ・サーバに連結されたデータ・ベース・サーバである。サーバ・コンピュータは取引を処理するためのコードを含む、コンピュータ読み取り可能媒体を含み、以下に詳細に説明するようにこれは売買業者、集金者、発行者からメッセージを受け取るためのコード、ユニークな取引識別子を生成し、それらを特定の取引に関連づけるためのコード、メッセージを送信するためのコード、発行者を識別するためのコード、および取引および不渡り手形要求をほぼ実時間で解消して解決するためのコードを含む。
【００２４】
サーバ・コンピュータ４４はまた、発行者に関連する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコード、此処で支払い指示は支払先情報の少なくとも一部を含み、そして更に此処で支払い指示は支払先とは異なる関係者によって発せられ；実質的に完全な支払先情報を決定するためのコード；および認証要求を発行者に送信するためのコード、此処で認証要求がプッシュ識別子を含む、で構成されたコンピュータ読み取り可能媒体をも含む。
【００２５】
サーバ・コンピュータ４４はまた、支払い指示メッセージを受け取るためのコード、支払い指示メッセージを読み取りその支払い指示メッセージが支払先を決定するための情報を含んでいるかを判定するためのコード、およびファジー論理を用いて支払い指示メッセージ内の情報を複数のデータ・ストアと比較し、その支払い指示メッセージに関連する支払先をほぼ同定するためのコードを含み、此処で複数のデータ・ストアが少なくとも１つの売買業者用の複数の識別子を含み、此処でその複数の識別子が、１つの名称のための識別子、１つの電話番号のための識別子、および１つの住所のための識別子を含む。
【００２６】
支払い処理ネットワーク２６は例えばVisaNet（登録商標）またはBanknet（登録商標）の様な支払い処理ネットワークを含むか使用している。支払い処理ネットワーク２６およびその支払い処理ネットワーク２６と通信を行う全ての通信ネットワークは、インターネットを含む任意のその他の有線または無線ネットワークを使用できる。支払い処理ネットワーク２６は通常の銀行カードまたはクレジット・カードを、此処に検討されているプッシュ支払い取引と共に処理するように適合されている。
【００２７】
識別システム４９は１つの取引の支払先の身元を、以下に更に詳細に説明するように、たとえ不完全な取引情報のみが与えられた場合においても決定するために使用可能である。識別システム４９は１つまた複数のサーバ・コンピュータ、１つまたは複数のデータ・ベース、またはそれらの任意の好適な組み合わせを含むことができる。或るいくつかの実施例において、識別システム４９は支払い処理ネットワーク２６の一部であって、支払い処理ネットワーク２６の一部分が識別システム４９の機能のいくつかまたは全てを実行することが可能である。これに代わる実施例において、識別システム４９は、支払い処理ネットワーク２６と通信している別のネットワークまたはコンピュータ・システムである。或るいくつかの実行例において、識別システム４９は、互いに通信している種々の独立したコンピュータ・システム上に配置された複数のデータ・ベースを含むことが可能である。
【００２８】
支払い処理ネットワーク２６の実施例はまた、多重支払い方法（multiple method of payment “MMOP”）図示せず、を含むかまたはこれに対応することの出来るデータ・センター・ハブと個別に通信している。データ・センター・ハブはプロフィール管理（profile management）、ファイル管理、メッセージ翻訳を実施し、ビジネス規則を格納して実行し、そして種々のその他のネットワークとの相互接続を行う。データ・センター・ハブの事例は米国特許出願第１１／９２９，０３３号、名称「多重支払い方法を処理するためのシステム並びに方法（System and Method For Processing Multiple of Payment）」に記載されており、これはその全部を参照することで全ての目的に対してそのまま組み込まれている。或るいくつかの実施例において、識別システム４９はその様なデータ・センター・ハブを含むことが可能である。
【００２９】
支払い処理ネットワーク２６と識別システム４９は集金者２４と発行者２８との間で動作するように図示されているが、本発明の別の実施例ではそうである必要はない。いずれか一方またはその両方は、本出願に記載された処理を容易に行えるコンピュータ装置の好適な組み合わせを含んで構わない。
【００３０】
購入者３０は接続機器３４を用いて、発行者２８または支払い処理ネットワーク２６と通信することが出来る。本発明の実施例に基づく接続機器は、任意の好適な形態を取りうる。接続機器の例として、店舗販売時点情報管理（point of sales: POS）機器、携帯電話機、PDA、パーソナル・コンピュータ(PC)、タブレット型PC、手持ち式専用読み取り機（handheld specialized reader）、セットトップボックス（set-top box）、電子式金出納器（electronic cash register :ECR）、現金自動預け払い機（ATM）、仮想金銭出納器（virtual cash register :VCR）、キオスク、セキュリティー・システム、アクセス・システムなどが含まれる。接続機器は、インターネットを介して通信を行うコンピュータ上の例えばウェッブ・ブラウザの様な、使いやすいインタフェースを含む。或るいくつかの実施例において、購入者３０は、例えば発行者２８によって主催されている講座に関連する支払いカードの様な、携帯型消費者機器を所有している。１つの形態において、支払いカードは接続機器３４と相互に作用して、送信される支払い指示メッセージを生成することが出来る。別の形態において、支払いカードは関連する支払い口座情報を含むことが可能である。購入者は支払いカード上に含まれる関連する支払い口座情報を接続機器３４か、または直接、発行者２８支払い処理ネットワーク２６に提供することができる。
【００３１】
接続機器３４はプロセッサおよび計算機読み取り可能媒体を含み、此処で計算機読み取り可能媒体は、消費者に関連する口座番号を獲得するためのコード；口座番号および取引に関わる金額を含む、認証要求メッセージを支払い処理ネットワークに送信するためのコード；およびその取引用にユニークな取引識別子を含む認証応答メッセージを受信するためのコードを含む。
【００３２】
図を簡単にするために、１人の購入者３０、１人の売り手２２、１台の接続機器３４、１人の集金者２４および１つの発行者２８が図示されている。しかしながら、理解されるように本発明の実施例において、多数の消費者、複数の携帯型機器、売買業者達、複数の接続機器、集金者達、発行者達、同様に複数のサーバ・コンピュータ、複数のデータ・ベース、複数の口座などが可能である。
【００３３】
（２．事例処理過程）
図２は、図１のシステム２０で実施される、１つの取引処理１００例の流れ図を提供している。或るいくつかの実施例において、取引処理過程はその取引の性質および含まれる個別の当事者に依存して異なるはずである。
【００３４】
ステップ１０１において、購入者が取引を開始する。先に記述されるように、取引は購入者／支払者が物品またはサービスの対価を売買業者／支払先に支払う財務取引である。この支払いは、請求書に対応した請求書支払い（bill payment）、購入カード取引、またはその他の好適な取引である。いくつかの実施例において、特定売買業者に対する複数の支払いを集計して１つの取引として支払うことが可能である。取引を開始するために、購入者は支払い指示メッセージまたは支払いファイルを準備する。この支払い指示メッセージは、取引を処理するために必要最小限の情報を含む。事例の実施例において、支払い指示メッセージは少なくとも、誰に支払うか（支払先情報）とその取引に幾ら支払うか（取引金額（transaction amount））の情報を含む。別の実施例では、支払い指示メッセージがその他の情報、例えば支払い時期、関連する請求書番号、関連する注文番号、どの通貨で取引を実行するか、発行者の名称およびその取引で使用される発行者に関連する購入者の銀行口座の識別子を含むものも有る。
【００３５】
事例の実施例において、支払い指示メッセージは一部の支払先情報を含んでいる。支払い指示メッセージはその支払先を識別するために使用されるデータを含む。此処で使用されている事例の実施例では、「一部の支払先情報」とは、或る種の情報が欠落している支払先関連データと言えて、そのデータを見ただけでは支払先を１００％同定することは出来ない。一部の支払先情報は支払先の名称、電話番号、ｅメールまたはウェッブサイト情報、住所、およびその他の識別子（例えば政府発行の税金識別子、または銀行または支払い処理ネットワークから割り当てられた特定の識別子）のいずれかまたは全てを含む。しかしながら、一部の支払先情報は支払い情報が欠落する可能性がある。この情報は不完全な支払先名称、または旧いまたは不完全な住所を含む場合がある。一部の支払先情報はまたはっきりしない情報、例えば複数の他の組織と共有されている支払先の名称または住所を含む可能性がある。ひとたび支払い指示メッセージが受け取られると、図１のシステム２０はその支払い指示メッセージを分析して、実質的に完全な支払先情報を決定する、ステップ１０４−１０６に示す通り。事例の実施例において、「実質的に完全な支払先情報」は、正しい支払先に支払いを行うことを可能とする支払先に関する情報を含む。例えば、一部の支払先情報が不完全な支払先名称および間違った住所を含む場合、支払い処理システム２０の実施例は完全な支払先名称および正しい住所を決定する。或るいくつかの実施例において、実質的に完全な支払先情報は予め定められた閾値内の精度を含む。例えば、実質的に完全な支払先情報は９５％精度以内の支払先に関する情報を含む。他の実施例ではより高いかまたはより低い、予め定められた精度、例えば７０％，８５％，または９９％を考慮している。相対的に、その取引が支払先によって開始された場合（例えば、標準のクレジット・カード取引、此処ではクレジット・カードが支払先／売買業者により「読み取り（swipe）」される）、支払先情報は１００％の精度と言える。これは、支払先情報が標準取引の中で支払先自身により提供されるからである。従って、ひとつの形態において、実質的に完全な支払先情報は取引を完成させるために十分な精度の支払先に関する情報である。
【００３６】
購入者は取引をステップ１０１において、幾らでも十分多くの方法で開始できる。実施例は支払い指示メッセージが：固有のソフトウェアで生成され、任意の転送システム、例えばファイル転送プロトコル（FTP）または安全保証FTP（secure FTP）、ｅメールなどによって支払い処理ネットワークに提出されることで転送される；書き物または電話でなされる口頭指示、郵便または本人自身により；安全保証ウェッブサイトに接続されたウェッブ・ブラウザによって；売買業者直接交換（MDEX）システム；またはその他の任意の好適な方法により、生成され転送されると考慮している。事例の実施例は更に、支払い指示メッセージが要求される情報を、例えばMicrosoft Word またはExcel の様な一般的に利用可能なソフトウェア・プログラムで作成されたファイルの中に入力することにより、生成できることを考慮している。或るいくつかの実施例において、支払い指示メッセージは直接支払い処理ネットワークに転送される。別の実施例では購入者が支払い要求を購入者の銀行（発行者）に通信し、これが次に支払い指示メッセージを支払い処理ネットワークに転送する。
【００３７】
ひとたび支払い指示メッセージが支払い処理ネットワークに送られると、プッシュ識別子がステップ１０２で追加される。このプッシュ識別子はその取引がプッシュ取引であることのラベル付けを行う。事例の実施例において、プッシュ取引は既存の支払い取引インフラを利用する。このプッシュ識別子は標準取引とは対照的にプッシュ取引を、既存のシステムが適切に識別して処理することを可能とし、またそのシステムが必要に応じてその取引に対して特定のプッシュ処理を実施することを知らしめることが可能である。ステップ１０３ａおよび１０３ｂにおいて、支払い指示メッセージが分析され、その支払い指示が完全であるか決定する。特定の実施例において、全ての要求された支払いフィールド（例えば、一部の支払先名称、支払額など）が提供され、またその支払い指示メッセージに対するその他の要求が、支払い処理ネットワークで決定されるように合致した場合に、その支払い指示は完全である。支払い指示メッセージがステップ１０３ａまたは１０３ｂで決定されるように完全でない場合、更なる支払先識別情報を要求し完全な支払い指示メッセージを生成するように、警告メッセージが購入者に送られる。更なる支払先識別情報は、それ以前には支払い指示メッセージの中に具備されていなかった支払先に関する情報、例えば電話番号、住所または先に提供された情報に代わるスペルを含む。
【００３８】
支払い指示メッセージがステップ１０３ａおよび１０３ｂで完全であると決定されると、その支払い指示メッセージはステップ１０４−１０６で更に検証され処理される。ステップ１０４−１０６は図１の支払い処理ネットワーク２６で、一部のまたは全てが実行される。或るいくつかの実施例では、ステップ１０４−１０６の一部または全てが識別システム４９で実行される。ステップ１０４において、支払い指示メッセージは一部の支払先情報を抽出するために構文解析される。先に説明したように、一部の支払先情報は完全な支払先情報に翻訳される。完全な支払先情報が既に提供されている場合、次にその支払い指示メッセージはステップ１０５に移される。事例の実施例において、支払い指示メッセージは一部の支払先情報のみを含み、見たところでは適切な支払先と厳密な照合は取れない。これは例えば、支払先名称が正しく綴られていないか情報が欠落している（“payee corp.が、提示されているが“the payee corp.”が正式な名称）の時に起こりうる。また種々の略称が一部の支払先情報の中に提示されている場合があり、例えば“corporation”に対して“corp”または“co”または“road”に対して“rd”である。一部の情報はまた複数の支払先が同一名称を有する場合にも生じる。例えば、受託業者が供給品をHome Depot店から購入したとする。国内には数百のHome Depot店が存在し、支払い指示メッセージはどの特定店に支払われるべきか特定することは出来ないであろう。更に、支払先情報の別の部分、名称に関するもの以外が、支払い指示メッセージの中に提供されている一部の支払先情報の中で欠落しているかまたは不正確な情報を有する場合がある。例えば、支払先がアルバカーキ（Albuquerque）、ニューメキシコ（New Mexico）に居住していたとする。しかしながら“Albuquerque”が一部の支払先情報の中で間違って“Alberquerque”と綴られているか、またはそれがニュージャージー（New Jersey）州に居住していると間違って識別される場合がある。また、先に説明したように住所の中に略称が存在する場合もある。事例の中には提供された唯一の情報が支払先の電話番号のみの場合もある。購入者によって提供された支払い指示メッセージ内の全てのフィールドには、不整合、欠落または不正確情報が存在しうる。
【００３９】
ステップ１０４内の情報照合処理過程は本発明の実施例の価値のある部分である。識別システム４９の実施例は与えられた情報の全体性を調べることが出来る。従って、与えられた名称が電話番号と一致しない場合、両方が住所と比較される。いくつかの実施例では、これら３つのデータ項目の２つが互いに一致し、またその第３番目が予め定められた逸脱以内である場合、合致したと見なされ、実質的に完全な支払先情報が決定される。例えば、以下の情報が支払い指示メッセージのデータ・フィールド内に含まれる：
【００４０】
支払先名称：Payee Corp.
支払先電話番号:(800)-555-5555
支払先住所: 15 Lincoln Rd. Arlington, VA 22202
【００４１】
この情報は一部の支払先情報を含んでいる可能性がある。ステップ１０４において、システム、例えば図１に関連して説明されたコンピュータ・システムは、１つの支払い指示メッセージから一部の支払先情報を抽出し、それを分析することができる。そのデータ・フィールドは識別システム４９に格納されているかまたは接続可能な複数の関係者の種々のデータ・ベースと比較することができる。これらのデータ・ベースは支払先名称の一覧表を含むことが出来る。或るいくつかの実施例において、１つまたは複数のこれらのデータ・ベースは、支払い処理ネットワークを通して支払いを受け付けるように構成された支払先の一覧表を含むことができる。データ・ベースの中に集計された支払先情報は、種々の支払者からその支払先に関して行われた複数の取引から導出される。これらの複数の取引には、銀行カード取引、クレジット・カード取引、プリペイド方式取引（stored value transaction）等を含む。種々のデータ・ベースに対する比較の後、識別システムは“Payee Corp.”は与えられた住所は存在しないと決定する。“Payee Service International”と言う名称の１つの事業体が与えられた電話番号に載せられており、また与えられた電話番号を有している。更に、“Payee Corporation”は“Payee Services International”の完全子会社であると判定された。従って、実質的に完全な支払先情報は提供された電話番号および住所情報を具備した“Payee Corporation”で構成されることになるであろう。
【００４２】
いくつかの実施例では、一部のおよび捕捉的支払先情報を具備したデータ・ベースを構築することが可能なものも有り、これにより将来の支払いメッセージがより高い精度と速度で判定されるようにしている。また、種々のサードパーティー（third parties）に対して、その様な一部のおよび捕捉的支払先情報用のデータ・ベースを採掘させることが可能なようにして、実質的に完全な支払先情報を決定できるようにもできる。料金はそのデータを運用している関係者から、そのデータを要求する関係者に課金される。
【００４３】
別の事例において、印刷間違いまたはその他の正しくない情報が提供される可能性がある。住所が“13 Linkin Lane”と与えられる場合が有るであろうし、または電話番号が“(888)555-555”として提供される可能性もある。識別システム４９は一部の支払先情報を種々のデータ・ベースと先に説明したように比較することが出来る。事例の実施例において、識別システム４９はまた、実質的に完全な支払先情報を決定する際に、ファジー論理を使用することが出来る。識別システム４９は一部の支払先情報を、実質的に完全な支払先情報の一覧表を含む、単一または複数のデータ・ストアと比較して一致を採る際に、ファジー論理を使用することが出来る。ファジー論理は不確かさの下での推論を行う技術を含み、報告システムと同様に、近代産業および消費者製品制御システムで広く使用されてきている。ファジー論理は一般的にブール代数論理の上位集合と見なされており、この中でブール代数の真値が真値の中間値で置き換えられたものである。従って、ブール代数論理が真値としてゼロか１のみしか許さない一方で、ファジー論理は真値としてゼロから１の間の任意の実数を有することを許している。或る実現例において、識別システム４９は第３者データ・ベースおよび照合システム、例えばD&B MarketMatch を含むDun & Bradstreet 製品、と通信可能であるかまたはそうでなければそこにアクセスすることが可能である。識別システム４９はまた、隠れマルコフ・モデル（HMM）、動的プログラミング・モデル、ニューラル・ネットワーク、テンプレート照合（template matcher）等の様な好適な処理過程を含むことも可能である。これらのデータ・ベース、技術およびモデルは単独でまたは組み合わせて使用できる。
【００４４】
識別システム４９はファジー論理照合、またはその他の好適なシステムを使用することが出来る。上記の事例で、識別システムは支払い指示メッセージの中に提供された電話番号“(888)555-5555”を種々のデータ・ベースと比較するためにファジー論理を使用できる。識別システムは９５％の精度で、実質的に完全な支払先情報が電話番号“(800)555-5555”を含むものと、決定する。この精度は予め定められた精度閾値と比較できる。この閾値は支払い処理ネットワーク、支払者、発行者、集金者、または此処に開示されている実施例に基づくプッシュ取引に関係するその他の関係者によって設定可能である。識別システム４９は予め定められた９５％の精度閾値を有している。上記の事例で、実質的に完全な支払先情報は十分に正確であり、支払い処理はステップ１０５へ継続される。別の実施例において、識別システムが９９％の予め定められた閾値を有する場合がある。上記の事例では、実質的に完全な支払先情報は十分に正確とは言えない。より高い精度の照合が得られない場合、取引処理はステップ１０５で終了し、更なる支払先識別情報が無いとプッシュ支払いが出来ない旨の、１つのメッセージが購入者へ送られる。
【００４５】
一部の支払先情報内に提供された各々のデータ・フィールドは、先にステップ１０４に関連して説明したように、適切なデータ・ベースと比較され、ファジー論理照合で分析される。種々のデータ・フィールドには分析中に重みがかけられる。ひとたび全てのフィールドの処理が、個別並びに組み合わせでなされると、実質的に完全な支払先情報が、可能な最も高い精度で決定される。従って、ステップ１０５において、取引を実行するために必要な全ての更なる情報が決定され、支払い指示メッセージに添付される。これには、支払い経路情報、ネットワーク識別子などが含まれる。支払い処理システムはまた、当業分野で知られているように、その取引に対するリスク評価処理を適用できる。ステップ１０６において、実質的に完全な支払先情報の精度が予め定められた閾値より高い場合、支払い指示メッセージは翻訳されステップ１０７に基づいて処理される。或るいくつかの実施例において、予め定められた閾値以上である必要がある一方で、別の実施例ではその精度は予め定められた閾値より高くなければならない。
【００４６】
購入者が此処に開示されている実指令に基づくプッシュ支払いを第１回目に行う際には、一部の支払先情報と実質的に完全な支払先情報の照合は先に説明したように実施される必要がある。一度実質的に完全な支払先情報が決定されると、識別システム４９はその支払先にユニークな支払先識別子、または「売買業者識別子（merchant identifier）」を割り当て、将来のプッシュ支払いで使用できるようにする。識別システム４９はまた、購入者識別子をその購入者に割り当てることも出来る。この購入者識別子は、誰がプッシュ支払いを行っているか、またどの金融口座が使用されるのかを迅速に識別するために使用できる。売買業者識別子および購入者識別子はその購入者に送られる。従って購入者はそれらの支払い処理ネットワークが生成した識別子を将来のプッシュ支払いで使用して、精度の向上と取引の迅速化を図ることができる。
【００４７】
識別システム４９はまた、売買業者識別子と購入者識別子とが他の与えられた情報と相関を取るように、データ・ベースを生成したり修正変更したりすることが可能である。これは購入者がベンダーに対して、その逆もあり、内部的に割り当てた、識別子を含む場合がある。例えば、会社Ｘはコンピュータ供給品をベンダーＹからしばしば購入しているとする。会社ＸはベンダーＹに識別子“VY123”を割り当て、ベンダーＹは会社Ｘに識別子“CX-AB5”を割り当てる。これらの識別子が、取引を開始する支払い指示メッセージの中に与えられると（さもなければ識別システム４９に対して既知）、識別システム４９はその識別子を、データ・ベース４８の様なデータ・ベースの中に格納できる。そのデータ・ベースは、これらの識別子をその他の識別情報に写像（map）できる。例えば、識別子“VY123”および“CX-AB5”は各々、支払い処理ネットワークで割り当てられた１つのユニークな識別子、そしてまたそれぞれの会社の名称および住所に写像される。従って、会社ＸがベンダーＹに対する支払いを行うプッシュ支払いを識別子VY123を使用して開始する場合、実質的に完全な支払先情報の決定に際して１００％の精度が得られる。
【００４８】
ステップ１０７を参照すると、支払い指示メッセージ（これは先に決定された実質的に完全な支払先情報を含む）が認証要求の形式に翻訳される。この認証要求メッセージは従来のクレジット・カード処理メッセージで使用されている形式で構わない。或るいくつかの実行例において、支払い指示メッセージは当業分野でBase1認証要求メッセージとして知られているものに翻訳される。従来取引において、認証要求メッセージは支払先／販売者により生成される。しかしながら、或るいくつかの実施例では支払い処理ネットワークがステップ１０７の認証要求メッセージを、購入者から提供された情報を用いて生成しもそのネットワークで処理される。ステップ１０７で生成された、翻訳済み認証要求メッセージはその取引を継続するために要求される全ての情報を含み、実質的に完全な支払先情報、取引額、購入者が支払いを行うためにどの口座を使用するか、を含む。認証要求メッセージは従来のクレジット・カード処理で生成されるものとほとんど同じである。事例の実施例において、認証要求メッセージは、ステップ１０７で生成された認証要求メッセージがステップ１０２で生成されたプッシュ識別子を含むことを除き、従来のものと全く同一である。
【００４９】
認証要求メッセージは次にステップ１０８で支払い処理ネットワークにより、発行者に送られる。発行者は購入者に関連する銀行口座を管理する銀行である。或るいくつかの実施例において、購入者は発行者を通して取引を開始しており、これは従って支払い処理ネットワークに連絡を取っている。別の実施例において、購入者は支払い指示メッセージの中で発行者を特定することができる。ステップ１０９において、発行者はその取引が認証されているか（すなわち承認されているか）を判定する。発行者は当業分野で知られているように、ある種のリスク・システムおよびその他の認証処理過程を起動させる。発行者は購入者の口座に十分なクレジットおよび／または資金が存在する場合、その取引を認証するはずである。発行者は十分なクレジットおよび／または資金が存在しない場合、認証しないであろう。更に、発行者は或る特別な処理をプッシュ支払い要求に適用し（メッセージの中にプッシュ識別子が有るため）、これは例えば特別報償または値引きの提供である。
【００５０】
取引が断られると、その取引は終了し辞退メッセージが支払い処理ネットワークに送られ、これはそのメッセージを購入者に回送される。取引が認証された場合、発行者は支払い処理ネットワークに警告を発する。認証ログを含む認証応答メッセージがステップ１１０ａおよび１１０ｂで生成される。この認証ログは支払い処理ネットワーク、または発行者で生成されて支払い処理ネットワークへ回送される。認証ログは当業分野で知られているように、帳票処理システム・ファイルと清算ファイルの様な、帳票処理と清算データを含む。認証ログはまたプッシュ取引用の更なる情報、例えばプッシュ識別子を含むように、を増加させることが可能である。認証ログはまた基本的な取引に関わる情報、例えば関連する請求書番号、関連する購入注文書番号、および購入者の名称をも含むはずである。或るいくつかの実施例において、認証ログは特定集金者の要求に従うようにカスタマイズすることが可能である。認証応答メッセージ（認証ログを含む）は集金者によりステップ１１１で受け取られる。事例の実施例において、認証応答メッセージは集金者がその取引に関して受け取る最初の通知である。認証応答メッセージは、購入者から支払先に支払いが行われることの、集金者に対する警告として機能できる。従って、いくつかの実施例において集金者は取引が発行者によって認証された後にのみ連絡される（すなわち、認証要求メッセージが発行者に対して、集金者と何らかの通信を始める前に送られる）。これは、集金者が関与する取引上のステップが少なくなり、認証することなく最終的に終了される取引を処理することがないので、取引速度と効率を増加させる。
【００５１】
取引が承認された後、通常の清算および支払い処理が開始できる。集金者は、資金の流れに関する勘定調整（reconciliation）メッセージ（例えば、勘定調整報告）を支払い処理ネットワークに送り、これは続いてこのメッセージを発行者に回送する。この勘定調整メッセージは支払者情報（例えば購入者名称）、請求書番号、および購入注文書番号を含む。集金者はまたステップ１１３で勘定調整メッセージを売買業者に送る。ステップ１１２において、資金は発行者に関する購入者の財務口座から集金者に支払われる。或るいくつかの実施例において、発行者はその取引に関連する資金を支払い処理ネットワークに送金かることができる。支払い処理ネットワークは次にその資金を支払先またはその支払先に関係する口座（例えば集金者の口座）に送金することができる。或るいくつかの実施例において、勘定調整メッセージを資金が支払われるのと同時に支払先に送ることができる。集金者に関連する支払先の口座は実行される取引の支払いに使用される資金から、手数料を減算した分増大する。発行者に関連する購入者の口座は、その資金と同額に手数料を加算した分減少する。この方法によってお金が転送できる。この資金の流れは勘定調整メッセージ内の情報を参照することが可能であり、従って全ての関係者はお金の流れの目的および対応する取引情報を知ることができる。従って、先に記述した方法によって、購入者は支払いを売買業者に「プッシュ」することができる。これは購入者が支払い方法並びにスケジュールに関して、従来の支払い方法と比較して大きな制御権を持つことを許す。更に、クレジット・カード処理取引を処理するためのシステムを利用できる。これはクレジット・カード取引の全ての利点を、プッシュ・モデル、例えば購入注文書支払いに対して、提供することができる。利点には高い安全性および詐欺防止、処理中の実時間または準実時間で実行されるリスク評価、累積ポイント還付の様な報償プログラムへのアクセス能力など、が含まれる。更に、先に説明したシステムおよび方法の実施例はまた、集金者の関与が、支払いが認証された後のみである、強化された処理フローを用いることで既存のクレジット・カード取引をも改善する。実施例はこれらおよびその他の利点を、以下に更に詳細に説明するように含む。
【００５２】
図３はプッシュ取引の１つの実施例を、実質的に完全な支払先情報を決定するための照合処理過程を強調して示す。この実施例において、支払い指示メッセージは先に説明したように購入者によって準備され、図１に示すサーバ・コンピュータの様な支払い処理ネットワークで受け取られる。ステップ１において、支払い処理ネットワーク２６はその支払い指示メッセージを再審理（すなわち「検証」）して、全ての要求された情報が存在するか、例えば一部の支払先情報を判定する。支払い指示メッセージが重要情報を欠いている場合、この取引はステップ１ａに示されるように処理されないであろう。支払い指示メッセージが検証されると、これはその支払先を決定するために、識別システム４９に送られる。ステップ２において、識別システム４９は支払い指示メッセージを構文解析（すなわち、再審理）して、そのメッセージが購入者識別子を含んでいるか、および一部の支払先情報が売買業者識別子を含むかを判定する。これらの識別子の実施例は図２に関連して、先に説明されている。或るいくつかの実施例において、これらの識別子は識別システム４９のデータ・ベース内に格納されており、それらは特定の、ユニークな事業体に各々写像されることが確認されている。従って、売買業者識別子と購入者識別子が与えられると、識別システム４９はほぼ完全（１００％）な精度で実質的に完全な支払先情報を決定できる。支払い処理ネットワーク２６は次に、ステップ６で認証要求メッセージを生成するために必要な全ての情報を添付することが可能であり、次にその認証要求メッセージをステップ７で従来の手段によって処理する。（すなわち、認証、支払い清算および決済）。
【００５３】
支払い指示メッセージが少なくとも１つの売買業者識別子を含まない場合、識別システム（これはサーバ・コンピュータで構成できる）は、与えられている一部の支払先情報の分析を実施して、実質的に完全な支払先情報を決定する。この一部の支払先情報はステップ３で種々のデータ・ベースと比較され、予め定められた基準、識別システムに格納されている支払先記録に基づいてその情報が一致するか判定する。一致が存在しない場合、取引失敗メッセージがステップ２ａで購入者へ送られる。事例の実施例では、ファジー論理照合が使用できる。１つの一致が有る場合、一部の支払先情報はステップ４で分析され、複数の一致記録が存在するか判定される。或るいくつかの実施例において、唯１つの一致のみが必要とされ、もしステップ４で更に別の記録が見つからない場合、取引はステップ６に継続できる。別の事例の実施例において、一部の支払先情報は識別システム４９によってアクセスされたデータ・ベースに格納されている複数の記録と一致しなければならない。従って、これらの実施例のステップ４において、更に別の記録が一部の支払先情報と一致しない場合、取引失敗メッセージがステップ２ａで購入者に送られる。
【００５４】
複数の一致記録が発見されると、全ての一致記録が比較され最も精度の高い１つが決定される。１つの実行例において、識別システム４９は一致記録の種々のデータ・フィールドに重要性に基づいて階級を付けることが可能であり、最も高い階級付けをされた一致データ・フィールドを具備した一致記録が選択される。例えば、一致記録は売買業者の税金識別子、売買業者の名称、および住所並びに郵便番号を含む。識別システムは重要性に基づいてフィールドの階級付けを行う。従って、税金識別子フィールドは最も重要性が高く、名称が２番目、住所が３番目そして郵便番号が４番目である。
【００５５】
１つの事例において、識別システムは、少なくとも或る程度一致している、次の様に与えられた一部の支払先情報：FredCo, 15 Broadlawn Drive, OH, 11111、税金識別子は与えられていない、に対して一致する３つの記録を判定する。第１照合記録は郵便番号の完全な一致、街路住所は一致しているが街路番号は一致せず（例えば、12 Broadlawn Drive）、そして一部の支払先情報の中に提供されている売買業者名称は一致していない。第２照合記録では売買業者名称が一致するか、住所が予め定められた許容偏差内で（例えば、15 Broadlawn Dr., Ohio）一致し、そして郵便番号が一致しているかも知れない。第３照合記録は、名称も郵便番号も不一致であるが、住所が一致しているかも知れない。上記の与えられた事例では、第２照合記録が最も高い階級の一致データ・フィールドを有し、これが選択される照合記録となるであろう。
【００５６】
ステップ５において、選択された照合記録が分析されて精度が判定され、支払い清算データが決定できる。精度が予め定められた閾値未満の場合、ステップ２ａで取引失敗メッセージが購入者に送られる。精度が予め定められた閾値より上の場合、実質的に完全な支払先情報が決定される。支払い清算データは、その実質的に完全な支払先情報で識別された支払先に対して決定される。支払い清算データはその支払先に関係する集金者に対する連絡先情報の様な、情報を含むことができる。この支払い清算データは支払い要求メッセージ、実質的に完全な支払先情報およびプッシュ識別子と結合して、認証要求メッセージをステップ６で生成することができる。従って、上述の処理は取引を完了するために実施される。
【００５７】
（３．携帯型機器およびコンピュータ装置）
図４（ａ）−４（ｂ）は携帯型消費者機器および、本発明の実施例に基づくシステム内のコンピュータ装置の中に存在するであろうサブシステムのブロック図を示す。
【００５８】
本発明の実施例の中で使用される携帯型消費者機器は任意の好適な形状を取りうる。例えば、好適な携帯型消費者機器は手持ち式でコンパクトであり、消費者の財布および／またはポケットに収まるものである（例えば、ポケットサイズ）。それらには、スマートカード、例えば支払いカードの様な通常のクレジットまたは銀行カード（マイクロプロセッサ無しの磁気ストライプ方式）、キーホルダ機器（例えば、エクソン・モービル社から市販されているSpeedpass（登録商標））などが含まれる。携帯型消費者機器のその他の例として、携帯電話機、携帯端末、ポケットベル（pager）、支払いカード、セキュリティー・カード（security card）、アクセス・カード（access card）、スマート・メディア（smart media）、トランスポンダ（transponder）などが含まれる。携帯型消費者機器はまた、借り方機器（debit devices）（例えば銀行カード）、クレジット機器（例えば、クレジット・カード）またはプリペイド機器（stored value devices）（例えばプリペイド・カード）も考えられる。
【００５９】
電話機の形状の携帯型消費者機器３２’の例は、図４（ａ）に示すようにコンピュータ読み取り可能媒体と本体とで構成されている。（図４（ａ）は多数の構成部品を示しており、本発明の実施例に基づく携帯型消費者機器はその様な構成部品の任意の好適な組み合わせまたはそれらの一部分を含んで構成することも可能である。）コンピュータ読み取り可能媒体３２（ｂ）は、本体３２（ｈ）の内部に存在するかまたは、それと取り外し可能である。本体３２（ｈ）はプラスチック基材、格納ケース、またはその他の構造の形式が考えられる。コンピュータ読み取り可能媒体３２（ｂ）はデータを格納しているメモリであり、磁気ストライプ、メモリ・チップ、暗号化アルゴリズム、秘密または秘密鍵などを含む任意の形式で構わない。メモリはまた好適に財務情報、通行情報（例えば、地下鉄または電車の定期として）、アクセス情報（例えば、入室バッチとして）などの情報を格納する。財務情報には、銀行口座情報、銀行識別番号（BIN bank identification number）、クレジットまたは銀行カード番号情報、勘定残高情報、有効期日、名前、生年月日の様な消費者情報などが含まれる。
【００６０】
メモリ内の情報はまた、従来からクレジット・カードに関連している、データ・トラックの形式でも構わない。その様なトラックはTrack1とTrack2を含む。Track1（国際航空運送協会“International Air Transport Association”）はTrack2よりも多くの情報を格納し、カード所有者の名前と同様に口座番号およびその他の自由裁量データを含む。このトラックは、クレジット・カードで予約を確保する際に航空会社でしばしば使用される。Track2 （米国銀行協会“American Banking Association”）は現在最も一般的に使用されている。これはATMおよびクレジット・カード照合器で読み取られるトラックである。ABA（米国銀行協会“American Banking Association”）はこのトラックの仕様が全世界の銀行がそれに耐えうるように設計している。これはカード所有者の口座、暗証番号（PIN）それに加えて、自由裁量データを含む。
【００６１】
携帯型消費者機器３２’は更に、非接触要素３２（ｇ）を含み、これは典型的には、関連する無線伝送（例えば、データ転送）素子、例えばアンテナ、を具備した半導体チップ（またはその他のデータ格納素子）の形状で実現されている。非接触要素３２（ｇ）は携帯型消費者機器３２’と関連づけられており（例えば、その中に組み込まれている）、携帯電話ネットワーク経由で送信されるデータまたは制御指令は非接触要素３２（ｇ）に非接触要素インタフェース（図示せず）により、供給される。非接触要素インタフェースは、モバイル機器回路（従って、携帯電話ネットワーク）とオプションの非接触要素３２（ｇ）との間でデータおよび／または制御指令の交換ができるように機能する。
【００６２】
非接触要素３２（ｇ）は近距離通信（NFC near field communication）能力（または近距離通信媒体）を用いて、典型的には標準化されたプロトコルまたはデータ転送機構（例えば、ISO 14443/NFC）に基づき、データの送信および受信を行える。近距離通信能力は短距離通信能力、例えばRFID, Bluetooth（登録商標）,近赤外線、またはその他の携帯型消費者機器３２とインターロゲーション機器（interrogation device）との間でデータ交換に使用できるデータ転送能力である。従って、携帯型消費者機器３２は携帯電話ネットワークと近距離通信能力の両方を介してデータおよび／または制御指令を通信しかつ転送することが可能である。
【００６３】
携帯型消費者機器３２’はまた携帯型消費者機器３２’の機能を処理するためのプロセッサ３２（ｃ）（例えば、マイクロプロセッサ）および消費者が電話番号およびその他の情報およびメッセージを見ることをできるようにするための表示器３２（ｄ）を含む。携帯型消費者機器３２’は更に、消費者が機器に情報を入力できるようにする入力素子３２（ｅ）、消費者が音声通信、音楽などを聴けるようにするスピーカ３２（ｆ）および消費者が携帯型消費者機器３２’を通して、その音声を伝送できるようにするマイクロフォン３２（ｉ）を含む。携帯型消費者機器３２’はまた無線データ転送用（例えば、データ送信）のアンテナ３２（ａ）を含む。
【００６４】
携帯型消費者機器３２’は購入者がプッシュ支払いを開始するためにも使用できる。いくつかの実行例において、携帯型消費者機器３２’は購入者が支払い要求メッセージを生成することを可能とするインタフェースを含む。携帯型消費者機器３２’は従って、支払い要求メッセージを支払い処理ネットワークへ非接触要素３２（ｇ）または無線または有線通信を経由して送ることが可能である。
【００６５】
カード形式の携帯型消費者機器３２”の１例が図４（ｂ）に示されている。図４（ｂ）はプラスチック基板３２（ｍ）を示す。接続機器３４とインタフェースするための非接触要素３２（ｏ）がプラスチック基板３２（ｍ）上に存在するかまたはその中に組み込まれている。口座番号、有効期限、および消費者名の様な消費者情報３２（ｐ）がカード上に印刷されているかまたは刻印されている。また、磁気ストライプ３２（ｎ）もまた、プラスチック基板３２（ｍ）上にある。
【００６６】
図４（ｂ）に示すように、携帯型消費者機器３２”は磁気ストライプ３２（ｎ）と非接触要素３２（ｏ）の両方を含んでいる。別の実施例では磁気ストライプ３２（ｎ）と非接触要素３２（ｏ）の両方が携帯型消費者機器３２”の中に有る。別の実施例では、磁気ストライプ３２（ｎ）または非接触要素３２（ｏ）のいずれかが携帯型消費者機器３２”の中に存在する。いくつかの実現例において、携帯型消費者機器３２”は購入カードで構成することが可能である。購入カード３２”は購入者に関係する購入者識別子、その購入者によって管理され、支払いに使用される１つの口座に関する口座番号、またはその他の識別情報を含む。この識別情報は上記のように支払い指示メッセージを生成する際に購入者により使用できる。
【００６７】
図１に示す種々の関係者および要素は、此処に記述されている機能を容易にするために１つまたは複数のコンピュータ装置を運用または使用するはずである。図１の全ての要素（例えば、接続機器３４、売買業者２２、集金者２４など）は、此処に記述されている複数の機能を容易にするために任意の好適な数量のサブシステムを使用するはずである。その様なサブシステムまたは構成要素の例が図５に示されている。図５に示すサブシステムはシステム・バス７７５経由で相互接続されている。プリンタ７７４、キーボード７７８、固定ディスク７７９（または計算機読み取り可能媒体を含むその他のメモリ）、モニタ７７６、これは表示器アダプタ７８２に結合されている、およびその他が図示されている。Ｉ／Ｏ制御器７７１に接続する、周辺機器および入出力（Ｉ／Ｏ）装置は、例えばシリアル・ポート７７７の様な、当業分野で知られている任意の多くの手段でコンピュータ・システムに接続される。例えば、シリアル・ポート７７７または外部インタフェース７８１は、コンピュータ装置をインターネットの様な広域ネットワーク、マウス入力機器、またはスキャナと接続するために使用できる。システム・バスを介した相互接続は中央処理装置７７３が各々のサブシステムと通信し、システム・メモリ７７２または固定ディスク７７９からの命令の実行を制御し、また同様にサブシステム間での情報交換を行うことを可能とする。システム・メモリ７７２および／または固定ディスク７７９は計算機読み取り可能媒体を具現化している。
【００６８】
本発明の実施例は上述の実施例に限定されるものでは無い。例えば、発行者、支払い処理ネットワーク、および集金者に関して別々の機能ブロックとして示されているが、事業体によってはこれら機能の全てを実行し、発明の実施例に包含される。
【００６９】
上述の本発明は、モジュール型または統合方式の計算機ソフトウェアを用いた制御ロジックの形式で実現できることを理解されたい。此処に提示する開示および教えに基づき、通常の技量を有する当業者は、ハードウェアおよびハードウェアとソフトウェアの組み合わせを用いて、本発明を実現するためのやり方および／または方法を知り、かつ理解することが可能である。
【００７０】
本出願に記述されているソフトウェア構成要素または機能のいずれも、例えば従来方式またはオブジェクト指向技術を使用して、任意の好適な計算機言語、例えばJava（登録商標）, C++またはPerlで実行されるソフトウェア・コードとして実現される。ソフトウェア・コードは一連の命令（instruction）、または指令（command）として計算機読み取り可能媒体、例えば随意アクセス・メモリ（RAM）、読み取り専用メモリ（ROM）、ハードディスクまたはフロッピー（登録商標）ディスクの様な磁気媒体、またはCD-ROMの様な光学媒体の上に格納される。その様な計算機読み取り可能媒体のいずれも、単一計算装置上またはその内部に常駐するか、システムまたはネットワーク内の異なる計算装置の上または内部に存在している。
【００７１】
本発明の実施例は多くの長所を有する。或るいくつかの実行例において、支払い取引の受益者（すなわち、支払先）はいずれのシステムに登録したり選択したりする必要が無い。支払者は既に支払いを受けることが可能な全ての事業体に、クレジット・カードまたはその他の手段で支払いをプッシュすることができる。更に、支払者はその取引の金額および時機に対する制御を保持している。支払先および関連する事業体（例えば集金者）は、最終的に発行者に承認されない取引に悩まされる必要が無いので、これはシステム効率を向上させ無駄を防止する。取引の全ての関係者は、強化された詐欺およびリスク検知、また同様に報償およびその他の有益なプログラムを利用することができる。
【００７２】
以上の説明は実例として示すことが目的であって制限するものではない。当業者には開示を見直すことにより、本発明の多くの変形が明らかとなろう。従って、本発明の範囲は上述の説明を参照して決定されるのではなく、代わりに添付の特許請求項の全範囲またはその等価なものを参照して決定されるべきである。
【００７３】
いずれかの実施例の１つまたは複数の特徴は、他のいずれかの実施例の１つまたは複数の特徴と、本発明の範囲から逸脱することなく組み合わすことができる。
【００７４】
“a”（ひとつの）、“an”（ひとつの）または“the”（その）という言い回しは特にその反対の意味であると断りがない限り、“one or more”（ひとつまたは複数の）を意味することを意図している。“she”（彼女）という記述は中性を意味し、特に反対の意味であると断りが無い限り“he”or“she”（彼または彼女）と読まれるものである。
【００７５】
先に言及した全ての特許、特許出願、発行物、および記述は此処に参照することで、全ての目的に対してそっくりそのまま組み込まれている。いずれも従来技術と自認するものではない。
【特許請求の範囲】
【請求項１】
取引を処理するためのコンピュータで実行される方法であって、
支払い指示メッセージをサーバ・コンピュータで受け取り、此処で支払い指示メッセージは発行者に関連する口座を用いて、支払先に支払いを行うためのものであり、支払い指示メッセージは少なくとも一部の支払先情報を含み、更に支払い指示メッセージは支払先とは異なる事業体から発せられるものであり、
支払い指示メッセージを再審理し、
実質的に完全な支払先情報を決定し、
支払い指示メッセージを再審理した後に、認証要求メッセージを発行者に送信し、認証要求メッセージがプッシュ識別子を含む、
以上を含む、前記コンピュータで実行される方法。
【請求項２】
請求項１記載のコンピュータで実行される方法において、支払い指示メッセージが支払者により発せられる、前記方法。
【請求項３】
請求項２記載のコンピュータで実行される方法において、更に、認証要求メッセージを送信する前に、更に別の支払先識別情報が無いとその取引が完了出来ないことを、支払者に通知することを含む、前記方法。
【請求項４】
請求項１記載のコンピュータで実行される方法において、更に、
前記取引に関わる認証応答メッセージを発行者から受け取り、
認証ログをその支払先に関連する集金者に送信することを含む、前記方法。
【請求項５】
請求項４記載のコンピュータで実行される方法において、認証要求メッセージが集金者と通信する前に発行者に送られる、前記方法。
【請求項６】
請求項１記載のコンピュータで実行される方法において、更に、
認証要求メッセージを送信する前に、プッシュ識別子を支払い指示メッセージに添付し、当該支払い指示をBase1 メッセージに翻訳し、認証要求メッセージがBase1 メッセージを含む、前記方法。
【請求項７】
請求項１記載のコンピュータで実行される方法において、前記実質的に完全な支払先情報を決定することが、支払先を少なくとも予め定められた閾値の精度で設定することを含む、前記方法。
【請求項８】
請求項７記載のコンピュータで実行される方法において、予め定められた閾値が８５％を含む、前記方法。
【請求項９】
請求項１記載のコンピュータで実行される方法において、前記実質的に完全な支払先情報を決定することが、支払い指示メッセージ内の情報と１つまたは複数のデータ・ベース内の支払先名称の１つまたは複数の一覧表と照合するためにファジー論理を使用することを含む、前記方法。
【請求項１０】
請求項９記載のコンピュータで実行される方法において、１つまたは複数のデータ・ベースが、支払い処理ネットワークを通して支払いを受諾するように構成された支払先一覧表のデータ・ベースを含む、前記方法。
【請求項１１】
支払いを行うためのコンピュータで実行される方法であって、
少なくとも一部の支払先情報、取引金額、支払時期を含む支払い指示メッセージをサーバ・コンピュータに送信し、支払い指示メッセージがサーバ・コンピュータで実質的に完全な支払先情報を決定するために構文解析され、認証ログがその支払先に関係する集金者に送られ、
資金を支払先に送金する、前記方法。
【請求項１２】
請求項１１記載のコンピュータで実行される方法において、一部の支払先情報が少なくとも支払先の１つの名称を含む、前記方法。
【請求項１３】
請求項１１記載のコンピュータで実行される方法において、一部の支払先情報が少なくとも支払先の１つの電話番号を含む、前記方法。
【請求項１４】
プッシュ支払い取引を受け取るためのコンピュータで実行される方法であって、
取引に関係する認証ログを受け取り、認証ログは帳票処理システム・ファイルと清算ファイルを含み、
前記取引の資金の流れに関するメッセージを送信し、
前記取引に関係する資金を受け取り、
前記資金を支払先に送金し、
取引情報を支払先に送信する、以上を含む前記方法。
【請求項１５】
請求項１４記載のコンピュータで実行される方法が更に、前記取引に対して認証ログにより通告されることを含む、前記方法。
【請求項１６】
請求項１４記載のコンピュータで実行される方法において、取引情報が請求書番号、購入注文番号、および支払者情報を含む勘定調整報告を含む、前記方法。
【請求項１７】
請求項１６記載のコンピュータで実行される方法において、勘定調整報告が資金の送金と同時に送信される、前記方法。
【請求項１８】
請求項１６記載のコンピュータで実行される方法において、支払者情報が支払者名を含む、前記方法。
【請求項１９】
プッシュ取引を処理するための計算機読み取り可能媒体であって、
発行者に関連する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコードであって、支払い指示は少なくとも一部の支払先情報を含み、更に支払い指示メッセージが支払先とは異なる事業体から発せられる前記受け取るためのコードと、
支払い指示メッセージを再審理するためのコードと、
実質的に完全な支払先情報を決定するためのコードと、
認証要求を発行者に送るためのコードであって、認証要求がプッシュ識別子を含む前記送るためのコードと、を含む前記計算機読み取り可能媒体。
【請求項２０】
請求項１９記載の計算機読み取り可能媒体において、前記実質的に完全な支払先情報を決定することが、支払先を少なくとも１つの予め定められた閾値の精度で決定することを含む、前記計算機読み取り可能媒体。
【請求項２１】
請求項２０記載の計算機読み取り可能媒体において、予め定められた閾値が８５％を含む、前記計算機読み取り可能媒体。
【請求項２２】
取引における支払先を識別するための計算機読み取り可能媒体であって、
支払い指示メッセージを受け取るためのコードと、
支払い指示メッセージを再審理し、当該支払い指示メッセージが支払先を決定するための情報を含んでいるかを判定するためのコードと、
支払い指示メッセージ内の情報を、当該支払い指示メッセージに関係する支払先を実質的に識別するための複数のデータ・ストアと比較するために、ファジー論理照合を使用するためのコードとを含み、
複数のデータ・ストアが少なくとも１つの売買業者に対して複数の識別子を含み、複数の識別子が名称用識別子、電話番号用識別子、および住所用識別子を含む、前記計算機読み取り可能媒体。
【請求項１】
取引を処理するためのコンピュータで実行される方法であって、
支払い指示メッセージをサーバ・コンピュータで受け取り、此処で支払い指示メッセージは発行者に関連する口座を用いて、支払先に支払いを行うためのものであり、支払い指示メッセージは少なくとも一部の支払先情報を含み、更に支払い指示メッセージは支払先とは異なる事業体から発せられるものであり、
支払い指示メッセージを再審理し、
実質的に完全な支払先情報を決定し、
支払い指示メッセージを再審理した後に、認証要求メッセージを発行者に送信し、認証要求メッセージがプッシュ識別子を含む、
以上を含む、前記コンピュータで実行される方法。
【請求項２】
請求項１記載のコンピュータで実行される方法において、支払い指示メッセージが支払者により発せられる、前記方法。
【請求項３】
請求項２記載のコンピュータで実行される方法において、更に、認証要求メッセージを送信する前に、更に別の支払先識別情報が無いとその取引が完了出来ないことを、支払者に通知することを含む、前記方法。
【請求項４】
請求項１記載のコンピュータで実行される方法において、更に、
前記取引に関わる認証応答メッセージを発行者から受け取り、
認証ログをその支払先に関連する集金者に送信することを含む、前記方法。
【請求項５】
請求項４記載のコンピュータで実行される方法において、認証要求メッセージが集金者と通信する前に発行者に送られる、前記方法。
【請求項６】
請求項１記載のコンピュータで実行される方法において、更に、
認証要求メッセージを送信する前に、プッシュ識別子を支払い指示メッセージに添付し、当該支払い指示をBase1 メッセージに翻訳し、認証要求メッセージがBase1 メッセージを含む、前記方法。
【請求項７】
請求項１記載のコンピュータで実行される方法において、前記実質的に完全な支払先情報を決定することが、支払先を少なくとも予め定められた閾値の精度で設定することを含む、前記方法。
【請求項８】
請求項７記載のコンピュータで実行される方法において、予め定められた閾値が８５％を含む、前記方法。
【請求項９】
請求項１記載のコンピュータで実行される方法において、前記実質的に完全な支払先情報を決定することが、支払い指示メッセージ内の情報と１つまたは複数のデータ・ベース内の支払先名称の１つまたは複数の一覧表と照合するためにファジー論理を使用することを含む、前記方法。
【請求項１０】
請求項９記載のコンピュータで実行される方法において、１つまたは複数のデータ・ベースが、支払い処理ネットワークを通して支払いを受諾するように構成された支払先一覧表のデータ・ベースを含む、前記方法。
【請求項１１】
支払いを行うためのコンピュータで実行される方法であって、
少なくとも一部の支払先情報、取引金額、支払時期を含む支払い指示メッセージをサーバ・コンピュータに送信し、支払い指示メッセージがサーバ・コンピュータで実質的に完全な支払先情報を決定するために構文解析され、認証ログがその支払先に関係する集金者に送られ、
資金を支払先に送金する、前記方法。
【請求項１２】
請求項１１記載のコンピュータで実行される方法において、一部の支払先情報が少なくとも支払先の１つの名称を含む、前記方法。
【請求項１３】
請求項１１記載のコンピュータで実行される方法において、一部の支払先情報が少なくとも支払先の１つの電話番号を含む、前記方法。
【請求項１４】
プッシュ支払い取引を受け取るためのコンピュータで実行される方法であって、
取引に関係する認証ログを受け取り、認証ログは帳票処理システム・ファイルと清算ファイルを含み、
前記取引の資金の流れに関するメッセージを送信し、
前記取引に関係する資金を受け取り、
前記資金を支払先に送金し、
取引情報を支払先に送信する、以上を含む前記方法。
【請求項１５】
請求項１４記載のコンピュータで実行される方法が更に、前記取引に対して認証ログにより通告されることを含む、前記方法。
【請求項１６】
請求項１４記載のコンピュータで実行される方法において、取引情報が請求書番号、購入注文番号、および支払者情報を含む勘定調整報告を含む、前記方法。
【請求項１７】
請求項１６記載のコンピュータで実行される方法において、勘定調整報告が資金の送金と同時に送信される、前記方法。
【請求項１８】
請求項１６記載のコンピュータで実行される方法において、支払者情報が支払者名を含む、前記方法。
【請求項１９】
プッシュ取引を処理するための計算機読み取り可能媒体であって、
発行者に関連する口座を用いて支払いを行うための支払い指示メッセージを受け取るためのコードであって、支払い指示は少なくとも一部の支払先情報を含み、更に支払い指示メッセージが支払先とは異なる事業体から発せられる前記受け取るためのコードと、
支払い指示メッセージを再審理するためのコードと、
実質的に完全な支払先情報を決定するためのコードと、
認証要求を発行者に送るためのコードであって、認証要求がプッシュ識別子を含む前記送るためのコードと、を含む前記計算機読み取り可能媒体。
【請求項２０】
請求項１９記載の計算機読み取り可能媒体において、前記実質的に完全な支払先情報を決定することが、支払先を少なくとも１つの予め定められた閾値の精度で決定することを含む、前記計算機読み取り可能媒体。
【請求項２１】
請求項２０記載の計算機読み取り可能媒体において、予め定められた閾値が８５％を含む、前記計算機読み取り可能媒体。
【請求項２２】
取引における支払先を識別するための計算機読み取り可能媒体であって、
支払い指示メッセージを受け取るためのコードと、
支払い指示メッセージを再審理し、当該支払い指示メッセージが支払先を決定するための情報を含んでいるかを判定するためのコードと、
支払い指示メッセージ内の情報を、当該支払い指示メッセージに関係する支払先を実質的に識別するための複数のデータ・ストアと比較するために、ファジー論理照合を使用するためのコードとを含み、
複数のデータ・ストアが少なくとも１つの売買業者に対して複数の識別子を含み、複数の識別子が名称用識別子、電話番号用識別子、および住所用識別子を含む、前記計算機読み取り可能媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１１−５１０３９９（Ｐ２０１１−５１０３９９Ａ）
【公表日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願番号】特願２０１０−５４３１８３（Ｐ２０１０−５４３１８３）
【出願日】平成２１年１月１３日（２００９．１．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３０８３０
【国際公開番号】ＷＯ２００９／０９１７２２
【国際公開日】平成２１年７月２３日（２００９．７．２３）
【出願人】（５０８１６８７９０）ビザ ユー．エス．エー．インコーポレイテッド (21)
【公表日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願日】平成２１年１月１３日（２００９．１．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０３０８３０
【国際公開番号】ＷＯ２００９／０９１７２２
【国際公開日】平成２１年７月２３日（２００９．７．２３）
【出願人】（５０８１６８７９０）ビザ ユー．エス．エー．インコーポレイテッド (21)
[ Back to top ]