JP2022512074A - 購入管理システムおよび方法 - Google Patents

Abstract

本明細書で説明される１または複数の実施形態に係る購入管理システム１００が提供される。システム１００は、中央データベース構成１１０と、前記中央データベース構成１１０へのクライアントインタフェース１２０と、銀行５００内のトランザクション認証モジュール５２０と通信するように構成された銀行固有データベースモジュール１３０と、を備える。前記中央データベース構成１１０は、前記クライアントインタフェース１２０を通じて、購入機関２００から購入グループ３００に適用される購入ルールを受信するように構成され、中央処理手段１１５を有し、前記中央処理手段は、選択された購入グループ３００を、前記中央データベース構成１１０における第１トランザクションＩＤに関連付けられたメタデータとして加え、前記購入グループ３００に適用される前記購入ルールを、前記中央データベース構成１１０における前記第１トランザクションＩＤに関連付けられたメタデータとして加え、前記銀行固有データベースモジュール１３０に前記第１トランザクションＩＤに関連付けられたメタデータを転送するように構成される。前記銀行固有データベースモジュール１３０は、前記トランザクション認証モジュール５２０から購入承認要求を受信するように構成され、前記購入承認要求は、前記第１トランザクションＩＤに関連付けられた購入金額を少なくとも含むトランザクション情報を含む。前記銀行固有データベースモジュール１３０は、銀行処理手段１３５を有し、前記銀行処理手段は、前記銀行固有データベースモジュール１３０における前記第１トランザクションＩＤに関連付けられた前記購入ルールを、要求された前記購入が満たすかに基づいて、承認または却下することで、前記購入承認要求について判断し、前記購入承認要求の承認または却下により、前記トランザクション認証モジュール５２０に応答し、前記トランザクション認証モジュール５２０から受信した前記トランザクション情報を、前記銀行固有データベースモジュール１３０における前記第１トランザクションＩＤに関連付けられたメタデータとして加え、前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を、前記中央データベース構成１１０に転送するように構成される。前記中央データベース構成１１０の前記中央処理手段１１５はさらに、前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を、前記購入機関２００に転送するように構成され、これにより、前記購入についての情報が前記購入機関２００の少なくとも１つの管理システムに自動的に入力され得る。

Description

本開示は、概して購入管理システムおよび方法に関する。

米国特許第７３１９９８６号に記載の動的支払いカード管理システムでは、カード制御設定が動的に修正可能であり、構成可能な企業の購入ポリシーおよびルールの適用を通して、承認パラメータが動的に管理できる。

米国特許第７３１９９８６号に記載のシステムは、購入要求の使用に基づく。特定の購入要求がなければ購入は行われない。ただし、当該購入要求はシステムで合成される場合もあり得る。購入要求を使用することで、企業内での承認プロセスが簡略化される。

米国特許第７３１９９８６号に記載のシステムにおいて、クライアントはトランザクションが生じたことを通知され得るが、システムが購入要求の使用に基づくため、購入時に購入の詳細を企業の経理システムに転送することはできない。したがって、企業はサプライヤから請求書を受信するまで、購入の詳細を受信しない。

さらに、米国特許第７３１９９８６号に記載のシステムは、既存の支払いインフラに取って代わることを意図した、包括的カード処理システムである。したがって、改善した購入管理システムが望まれている。

購入要求の使用に基づく購入管理システムは、企業内での承認プロセスを簡略化する。しかし、企業内で購入要求が内部管理されることで、外部団体がそれに、例えば完了した購入についての詳細などの情報を加えることができない。

本発明によると、これの代わりに、システムに対する任意の団体が、購入に関する情報を格納するためにアクセス可能なデータベースが使用される。データベース構成は、好ましくは、システムに対する異なる団体により用いられるデータフォーマットを、単一のデータフォーマットに「移行する」機能を有する。これにより、異なる団体が、購入に関する情報を加えやすくなる。

本開示は、購入機関が、サプライヤ／加盟店から物品およびサービスを購入し得る、購入管理システムおよび購入管理方法に関する。従来技術のシステムは、そのような購入からのトランザクション情報を購入機関の経理システムおよびその他管理システムに自動入力可能としない。本発明は、従来技術のシステムではできなかった方法で、システムに対する各種団体から情報を収集することでこれを実現する。

特許請求された購入管理システムは、中央データベース構成と、上記中央データベース構成へのクライアントインタフェースと、銀行内のトランザクション認証モジュールと通信するように構成された銀行固有データベースモジュールと、を備え得る。上記中央データベース構成は、上記クライアントインタフェースを通じて、購入機関から購入グループに適用される購入ルールを受信するように構成され得る。上記中央データベース構成は、中央処理手段を有し得、上記中央処理手段は、選択された購入グループを、上記中央データベース構成における第１トランザクションＩＤに関連付けられたメタデータとして加え、上記購入グループに適用される上記購入ルールを、上記中央データベース構成における上記第１トランザクションＩＤに関連付けられたメタデータとして加え、上記銀行固有データベースモジュールに上記第１トランザクションＩＤに関連付けられたメタデータを転送するように構成される。上記銀行固有データベースモジュールは、上記トランザクション認証モジュールから購入承認要求を受信するように構成され得、上記購入承認要求は、上記第１トランザクションＩＤに関連付けられた購入金額を少なくとも含むトランザクション情報を含む。上記銀行固有データベースモジュールは、銀行処理手段を有し得、上記銀行処理手段は、上記銀行固有データベースモジュールにおける上記第１トランザクションＩＤに関連付けられた上記購入ルールを、要求された上記購入が満たすかに基づいて、承認または却下することで、上記購入承認要求について判断し、上記購入承認要求の承認または却下により、上記トランザクション認証モジュールに応答し、上記トランザクション認証モジュールから受信した上記トランザクション情報を、上記銀行固有データベースモジュールにおける上記第１トランザクションＩＤに関連付けられたメタデータとして加え、上記第１トランザクションＩＤに関連付けられた上記トランザクション情報を、上記中央データベース構成に転送するように構成される。上記中央データベース構成の上記中央処理手段はさらに、上記第１トランザクションＩＤに関連付けられた上記トランザクション情報を、上記購入機関に転送するように構成され得、これにより、上記購入についての情報が上記購入機関の少なくとも１つの管理システムに自動的に入力され得る。これにより、購入からトランザクション情報を簡易に収集し、このトランザクション情報を購入機関によって使用されるデータフォーマットに変換することが可能になり、これにより、トランザクション情報は購入機関の経理システムおよびその他管理システムに自動的に入力され得る。

特許請求された購入管理方法は、購入グループに適用される購入ルールを、クライアントインタフェースを通じて中央データベース構成に入力する段階と、上記中央データベース構成における第１トランザクションＩＤに関連付けられたメタデータとして、選択された購入グループを加える段階と、上記中央データベース構成における上記第１トランザクションＩＤに関連付けられたメタデータとして、上記購入グループに適用する上記購入ルールを加える段階と、上記第１トランザクションＩＤに関連付けられたメタデータを、上記中央データベース構成から銀行固有データベースモジュールに転送する段階と、銀行内に配置されたトランザクション認証モジュールにおいて、上記第１トランザクションＩＤに関連付けられ、トランザクション認証情報を含む第１トランザクション認証要求を受信する段階と、上記トランザクション認証モジュールから上記銀行固有データベースモジュールに、少なくとも購入金額を含むトランザクション情報を含む購入承認要求を通信する段階と、要求された上記購入が、上記銀行固有データベースモジュールにおける上記第１トランザクションＩＤに関連付けられた上記購入ルールを満たすかに基づいて、承認または却下することで、上記購入承認要求について判断する段階と、上記購入承認要求に対する承認または却下を、上記トランザクション認証モジュールに応答する段階と、上記トランザクション認証モジュールから、上記第１トランザクションＩＤに関連付けられた上記第１トランザクション認証要求に応答する段階と、上記トランザクション認証モジュールから受信した上記トランザクション情報を、上記銀行固有データベースモジュールにおける上記第１トランザクションＩＤに関連付けられたメタデータとして加える段階と、上記第１トランザクションＩＤに関連付けられた上記トランザクション情報を上記中央データベース構成に転送する段階と、上記第１トランザクションＩＤに関連付けられた上記トランザクション情報を、上記購入機関に転送し、これにより、上記購入についての情報が上記購入機関の少なくとも１つの管理システムに自動入力され得る段階と、を備え得る。これにより、購入からトランザクション情報を簡易に収集し、このトランザクション情報を購入機関によって使用されるデータフォーマットに変換することが可能になり、これにより、トランザクション情報は購入機関の経理システムおよびその他管理システムに自動的に入力され得る。

実施形態において、銀行固有データベースモジュールは、銀行内に配置される。「銀行内」という定義は、銀行内のモジュールが、銀行のシステム内で、銀行のファイアウォールの奥に存在することを意味する。これにより、モジュール間で転送される情報が、決して銀行のファイアウォールの外に送信されることはない。これにより、購入承認要求に対する短時間での応答が可能となる。さらに、規制上の理由で銀行のファイアウォールの外部に送信が許可されないタイプのトランザクション情報を、銀行固有データベースモジュールにおける第１トランザクションＩＤに関連付けられたメタデータとして加えることを可能とする。銀行の外部から受信、および／または外部へ送信可能なトランザクション情報に関しては厳しい規制要件が存在する。しかし、銀行内に銀行固有データベースモジュールを配置することで、銀行の外部から受信、および／または外部へ送信許可されないトランザクション情報も、銀行固有データベースモジュールに入力され得る。

実施形態において、上記購入グループは、少なくとも１の購入個人を含む。これにより、１または複数の特定の購入個人、または１または複数の購入個人を含む購入機関のサブセクションに対して、購入ルールが定義および適応可能となる。

実施形態において、購入グループは、上記購入機関全体を含む。これにより、購入機関が、機関全体に対して一般購入ルールを定義可能となる。

実施形態において、上記購入ルールは、上記購入機関のサブセクションに対する一般購入ルールであり、上記購入グループに適用される上記購入ルールを、上記中央データベース構成における上記第１トランザクションＩＤに関連付けられたメタデータとして加える段階は、上記購入グループがどのサブセクションに属するかを決定する段階を含む。

実施形態において、上記トランザクション情報は、例えば加盟店の名前、または加盟店を識別するためのコードである加盟店情報を含む。承認または却下することで、上記購入承認要求について判断する段階は、さらに上記加盟店情報に基づく。これにより、購入機関は、選択されたサプライヤ／加盟店からの購入をブロックする、および／または選択されたサプライヤ／加盟店からの購入のみを可能とすることが可能となる。

実施形態において、上記購入ルールは、購入実行前に、所定のメタデータが、上記中央データベース構成における上記トランザクションＩＤに加えられ、関連付けられている必要があると指定する。上記購入承認要求について判断する段階は、当該メタデータが存在せず、上記銀行固有データベースモジュールにおける上記トランザクションＩＤに関連付けられていなければ、上記購入承認要求を却下する段階を含む。

実施形態において、直接または上記銀行内の支払いカード管理モジュールを介して、上記中央データベース構成から支払いカード発行機関に情報が転送され、これにより、上記支払いカード発行機関は支払いカードを上記購入機関に発行し得る。

実施形態において、上記中央データベース構成および上記銀行固有データベースモジュールは、互いを反映した形態となるように同期される。ただし、反映は、必ずしもデータベース内のすべての情報を含むものではなく、一部のメタデータフィールドは反映から除外され得る。

実施形態において、上記中央データベース構成は、多数の異なる団体と通信するように構成され、これらの異なる団体のそれぞれで用いられるデータフォーマットを、好ましくは上記購入機関により定義されたデータフォーマットである、単一のデータフォーマットに変換するアダプタを備える。

本発明は、支払いカードの使用に限定されることはなく、他の手段を利用したトランザクションも網羅する。同手段は、スマートフォン、または例えばＱＲ、ＥＡＮ、ＰＩＮコードのような他の装置である。

本出願における「銀行」という用語は、支払いカード支払い、または同様のタイプのトランザクションを承認し、実行する権限を持つ任意の支払いサービスまたは金融機関である。したがって、正式に銀行として定義され、認証された支払いサービスまたは金融機関のみではない。地域によっては、支払いサービスまたは金融機関は、例えば預金保険システムにより網羅されるためには、所定の規制要件を満たす必要がある。そのような地域では、「銀行」という用語は、そのような規制要件を満たす支払いサービスまたは金融機関に用いられるものであり得る。本出願における「銀行」という用語は、これに限定されることはなく、支払いカード支払い、または同様のタイプのトランザクションを承認し、実行する権限を持つ任意の支払いサービスまたは金融機関を網羅する。したがって、本出願における「銀行」という用語は、トランザクションを承認し、実行する、例えばマスターカードまたはビザなどのクレジットカードネットワークも網羅し得る。本出願における「銀行」という用語は、例えばマスターカードまたはビザなどのクレジットカードネットワーク間、および支払いカード支払い、または同様のタイプのトランザクションを承認し、実行する権限を持つ支払いサービスまたは金融機関の協働も網羅する。

中央データベース構成の中央処理手段は、単一の中央処理構成、または互いに信号を送信する複数の中央処理構成であり得る。いくつかの処理は、例えば１つの中央処理構成において実施され得、その後信号が１または複数の他の中央処理構成に送信されて、さらに処理され得る。

銀行固有データベースモジュールの銀行処理手段は、銀行システム内の任意の１または複数の処理構成であり得る。したがって、必ずしも銀行固有データベースモジュール専用の処理手段ではない。

銀行内のモジュールは、互いに情報を送信する物理的に別個のモジュールであり得るが、同一のサーバ上に実装される仮想モジュールでもあり得、または単にソフトウェアモジュールであり得る。

本発明の範囲は、参照によって本章に組み込まれる特許請求の範囲によって定義される。当業者であれば、１または複数の実施形態の以下の詳細な説明を考慮することによって、本発明の複数の実施形態をより完全に理解し、それらの追加の利点を認識するであろう。最初に簡潔に説明される添付の図面のページを参照されたい。

本明細書で説明される１または複数の実施形態に係る購入管理システムを概略的に示す。 本明細書で説明される１または複数の実施形態に係る購入管理システムを概略的に示す。 本明細書で説明される１または複数の実施形態に係る購入管理システムを概略的に示す。 本明細書で説明される１または複数の実施形態に係る、購入管理方法の例示的な流れ図である。 本明細書で説明される１または複数の実施形態に係る、購入管理システムの一部を概略的に示す。 トランザクション認証情報の例である。 本明細書に記載の１または複数の実施形態に係る、購入管理方法を概略的に示す。

本開示の実施形態およびその利点は、以下の詳細な説明を参照することによってもっとも良く理解される。参照番号は、１または複数の図において示される同様の要素を識別するために使用されることを理解すべきである。

多数の異なるタイプの支払いカード処理モデルが存在する。加盟店が支払いカードを発行し、カード保有者と直接関係するような最も単純なモデルは、２コーナーモデルと定義され得る。２コーナーモデルでは、カード保有者は、支払いカードを、それを発行した加盟店でのみ使用できる。

加盟店が支払いカードの発行および処理を望まない場合、３コーナーモデルが用いられ得る。これは、サードパーティーが、カード保有者と加盟店との間の仲介者として機能するものである。３コーナーモデルにおいても、カード保有者は、支払いカードを指定の加盟店でのみ使用可能である。

カード保有者により柔軟性を提供するべく、支払いカードに関して、代わりに４コーナーモデルが通常用いられている。そのようなモデルにおいて、カード保有者は支払いカードを、当該カードを受け付けるあらゆる加盟店での支払いに用いてよい。トランザクションは、例えばマスターカードまたはビザなどの支払いカードネットワークを介して、加盟店銀行とカード保有者銀行との間で処理される。

支払いカードが支払いに用いられる際、加盟店銀行がトランザクション認証要求を、支払いカードネットワークを介してカード保有者銀行に送信することで、トランザクション認証が実現する。そのようなトランザクション認証要求は、例えば、図６に示される、トランザクション認証情報を含み得る。次にカード保有者銀行は、例えば、カードデータ、勘定残高、制限、および挙動に関する複数のチェックを実行し、トランザクションを承認または却下する。

本発明によれば、一般的なトランザクション認証に加え、トランザクション認証プロセスに、購入承認要求がさらに加えられる。購入承認は、カード保有者銀行において、一般的なトランザクション認証が実行されるのと同時に実施される。一般的なトランザクション認証に加えて購入承認が行われることに、加盟店銀行は関与する必要がなく、それについて知らされる必要もない。購入が承認されなければ、加盟店銀行はトランザクションが認証されなかったという情報を受信する。ただし、それが例えばカードデータ、勘定残高、制限、および挙動に関するチェックに起因するものか、あるいは要求された購入が購入ルールを満たさないことに起因するかは必ずしも知らされない。

したがって本発明によれば、購入が行われる前に、購入管理システムにおいてサプライヤ／加盟店を設定する必要がなく、さらにサプライヤ／加盟店はいかなる購入管理システムにも、一切関連付けられる必要がない。本発明は、サプライヤ／加盟店はいかなる購入管理システムに一切関連付けられてなくても、購入についての情報を、購入機関に転送可能とする。これはどの従来技術のシステムでも実現不能である。

本開示は、購入管理システムおよび購入管理方法に関する。開示のソリューションの複数の実施形態を、図に関連してより詳細に提示する。

図１は、本明細書で説明される１または複数の実施形態に係る購入管理システム１００を概略的に示す。購入管理システム１００は、中央データベース構成１１０と、中央データベース構成１１０へのクライアントインタフェース１２０と、カード保有者銀行５００内のトランザクション認証モジュール５２０と通信するように構成された銀行固有データベースモジュール１３０と、を備え得る。中央データベース構成１１０は、例えばクラウドサービスであり得る。銀行固有データベースモジュール１３０は、カード保有者銀行５００内に配置され、購入承認要求に対する短時間での応答を可能とし得る。さらに、規制上の理由で銀行のファイアウォールの外部に送信が許可されないタイプのトランザクション情報を、銀行固有データベースモジュール１３０における第１トランザクションＩＤに関連付けられたメタデータとして加えることを可能とする。銀行の外部から受信、および／または外部へ送信可能なトランザクション情報に関しては厳しい規制要件が存在する。しかし、銀行内に銀行固有データベース１３０モジュールを配置することで、銀行の外部から受信、および／または外部へ送信許可されないトランザクション情報も、銀行固有データベースモジュール１３０に入力され得る。

中央データベース構成１１０は、クライアントインタフェース１２０を通じて、購入機関２００から購入ルールを受信するように構成され得る。購入ルールは、購入機関２００全体用の一般購入ルールであり得るが、購入機関２００の所定のサブセクションに特有の、あるいはさらには購入個人に特有の購入ルールであってもよい。クライアントインタフェース１２０は、例えばウェブインターフェースまたはモバイルアプリケーションであり得る。

中央データベース構成１１０の中央処理手段１１５は、トランザクションに用いられるトランザクションＩＤを生成し得る。これらトランザクションＩＤは、１つずつ生成されてよく、またはまとめて生成されてよく、さらに、予め定義されたルールに基づいて、または購入機関２００からの要求に応じて、生成され得る。トランザクションＩＤは、いかなる購入ルールが定義される前に生成されてもよい。トランザクションＩＤは、使用前に、アクティベーションが必要となり得る。

各トランザクションＩＤについて、該当購入機関に関する情報が、メタデータとして加えられ得る。該当購入機関は、例えば、購入グループ３００内の任意の購入個人として定義され得る。定義購入グループ３００は、１または複数の特定の購入個人を含み得るが、例えば購入機関２００のサブセクション、または購入機関２００全体として定義されてもよい。購入グループ３００内の全購入個人が、購入機関２００の雇用者である必要はない。即ち、購入グループ３００は、例えば購入機関２００に対するコンサルタント、または下請け業者を含み得る。

購入グループ３００に関するメタデータに基づいて、中央データベース構成１１０の中央処理手段１１５は、この特定のトランザクションＩＤにどの購入ルールが適用されるか識別し、これら購入ルールをトランザクションＩＤに関連付けられたメタデータとして加え得る。購入ルールは、購入グループ３００内の全購入個人に対して常に同じである。しかし、購入グループ３００は、購入グループ内の異なる購入個人に対する異なる購入ルールについて必要が生じれば、動的に修正され得る。そのような場合、新たな購入グループ３００は、単に異なる購入ルールを要する購入個人に対して形成される。

トランザクションに関連した他のタイプの情報も、中央データベース構成１１０におけるトランザクションＩＤに関連付けられたメタデータとして加えられ得る。購入機関２００と異なる機関も、中央データベース構成１１０にアクセス可能であり得、トランザクションＩＤに関連付けられたメタデータを加えることが可能であり得る。好ましくは特定のサードパーティーインタフェース１６０を用いるサードパーティー機関１５０により、中央データベース構成１１０にメタデータを加えることを、図２に示す。サードパーティーインタフェース１６０は、例えば、ウェブインターフェースまたはモバイルアプリケーションであり得る。

そのようなサードパーティー機関１５０は、例えば、購入機関２００のクライアントであり得る。購入機関２００は、そのクライアントのために購入を行い、さらなる請求を行う。そのような場合、メタデータは例えば、購入コストを支払うことに対する承認であり得る。その後、トランザクションＩＤに関連付けられたメタデータとして、クライアントに請求を行うのに必要な全ての情報を加えれば有利である。これにより、クライアントへの請求が簡略化され得、あるいはさらには自動化され得る。

そのようなサードパーティー機関１５０の別の例として、ブラックリストに登録されたサプライヤまたは所定の規制要件を満たさないサプライヤについての情報を提供する組織が挙げられ得る。そのような組織がこの情報をメタデータとして全トランザクションＩＤに加えると、購入ルールは、このメタデータで定義されたサプライヤ／加盟店からの購入が可能になることはないことを定義し得る。

そのようなサードパーティー機関１５０のさらなる例は、加盟店／サプライヤ４００である。加盟店／サプライヤ４００が中央データベース構成１１０にアクセス可能であり、トランザクションＩＤに関連付けられたメタデータを加えることが可能であれば、加盟店／サプライヤ４００は、例えば電子レシートをトランザクションＩＤに関連付けられたメタデータとして加え得る。加盟店／サプライヤ４００は、サードパーティーインタフェース１６０または加盟店／サプライヤ４００に対する特定のインタフェースを使用し得る。そのようなインタフェースは、例えばウェブインターフェースまたはモバイルアプリケーションであり得る。ただし、加盟店／サプライヤ４００が中央データベース構成１１０にアクセス不能であれば、電子レシートは、例えば購入グループ３００内の購入個人などの、別の団体により加えられてもよい。

購入グループ３００内の購入個人は、情報を取得、および／またはメタデータを加えるべく、中央データベース構成１１０と通信可能であってもよい。例えば、購入機関２００が企業支払いカードを、個人購入に使用可能にすることを望む場合、購入個人は、購入を個人用としてタグ付けし、例えばコストを自動的に次の給与から差し引かれるようにする選択肢があり得る。購入グループ３００内の購入個人は、サードパーティーインタフェース１６０、または購入グループ３００用の特定のインタフェースを使用し得る。そのようなインタフェースは、例えばウェブインターフェースまたはモバイルアプリケーションであり得る。

例えば購入ルールは、購入機関２００内の管理を簡略化すべく、購入の前または後に、購入個人に、所定のメタデータをトランザクションＩＤに加えることを求め得る。購入個人は、例えば、アカウント、コストセンター、プロジェクト、または目的をトランザクションＩＤに関連付けられたメタデータとして加えることが求められ得る。その後、購入個人により加えられたメタデータに基づいて、さらなる要件が、特定のタイプの購入に加えられ得る。例えば購入がクライアントとの会食などの説明に関する場合、購入個人は、参加者の名前をトランザクションＩＤに関連付けられたメタデータとして加えることを求められ得る。購入が出張に関する場合、購入個人は、出張先および／またはその目的を指定することが求められ得る。これにより、購入機関２００内の請求書の自動経理処理が可能となる。購入ルールは、このメタデータが、承認される購入に加えられていることを要し得る。購入ルールにより、このメタデータが加えられることが求められれば、購入個人が購入をしようとする前であっても、購入個人は、このメタデータが加えられなければ購入が却下されるという警告が出され得る。この場合、そのような警告は好ましくは、例えばＳＭＳ、ｅメール、またはモバイルアプリケーションを介して購入個人に通信される。

ただし、情報の所定の項目は、購入承認前には加えることができない。例えば、購入個人は、トランザクションＩＤに関連付けられたメタデータとしてレシートを加えることが求められ得る。これは例えば、レシートの写真を、モバイルアプリケーション使用して撮影することで行われる。そのような状況では、購入は既に行われており、却下はできない。しかし、この購入個人による将来的な購入は、必要なメタデータがこれまでの全トランザクションに加えられるまで、ブロックされ得る。このブロックは、購入機関２００により手動で行われ得る。あるいは、購入ルールにより、例えば、所定の時間後、またはこれが行われなかった所定回数の購入後に、全てのさらなる購入が自動的にブロックされるように指定され得る。

購入ルールは、所定のサプライヤ／加盟店に対して、購入がどのようにされ得るかも指定し得る。それらは、例えばコスト面の理由から、所定のサプライヤからは、ウェブでの購入のみが可能であると指定し得る。この場合、実店舗で購入しようとしても却下される。この場合、却下の理由についての情報は、好ましくは、例えばＳＭＳ、ｅメール、またはモバイルアプリケーションを介して購入個人に通信される。

トランザクションＩＤに関連付けられたメタデータは、銀行固有データベースモジュール１３０に転送され得る。購入ルールと、それらに適用された全メタデータが転送されれば、必ずしも全メタデータを銀行固有データベースモジュール１３０に転送する必要はない。しかし、一実施形態においては、中央データベース構成１１０内の全情報が、銀行固有データベースモジュール１３０に反映される。

銀行固有データベースモジュール１３０がトランザクションＩＤに関連付けられたメタデータを受信すると、購入承認要求がカード保有者銀行５００内のトランザクション認証モジュール５２０から送信され得る。購入承認要求はトランザクション情報を含む。これは、支払いカードが支払いに用いられると、加盟店銀行からカード保有者銀行５００に支払いカードネットワークを介して送信され、トランザクション認証モジュール５２０により受信されるトランザクション認証情報と同じであり得る。そのようなトランザクション認証情報の例を、図６に示す。購入承認要求内のトランザクション情報は、金額と、それを所望のトランザクションＩＤに対応付けるのに十分な情報が含まれていれば、必ずしも全てのトランザクション認証情報を有さなくてもよい。購入承認要求がトランザクションＩＤを含まなければ、銀行固有データベースモジュール１３０が購入をトランザクションＩＤに対応付けることを可能とする、トランザクション情報の何らかの他の項目を含む必要がある。当該項目は、例えば、購入グループ３００を識別するトランザクション情報などである。購入グループ３００が１または複数の特定の支払いカードに割り当てられている場合、このトランザクション情報は、例えば支払いカード番号、または支払いカード番号のトークンであり得る。その後、銀行固有データベースモジュール１３０の銀行処理手段１３５は単純に、この購入グループ３００に対して次の利用可能なトランザクションＩＤに、購入を割り当て得る。

その後、銀行固有データベースモジュール１３０の銀行処理手段１３５は、要求された購入が、トランザクションＩＤに関連付けられた購入ルール、即ち購入グループ３００に適用される購入ルールを満たすかを確認する。上述の例に加えて、購入ルールは例えば、各購入についての最高額、最高総額、予算内であるか、または購入がどこでいつ行われ得るかについての制限（例えば、海外からの購入、または週末の購入はブロックされ得る）に関し得る。購入承認要求が、例えば加盟店の名前、または加盟店を識別するコードなどの加盟店情報を含む場合、購入ルールは、購入グループ３００に対して許可される、またはブロックされる特定の加盟店にも関し得る。これにより、購入機関２００は、選択されたサプライヤ／加盟店からの購入をブロックする、および／または選択されたサプライヤ／加盟店からの購入のみを可能とすることが可能となる。例えば、購入機関２００は、この機能を使用して、Ｓｙｓｔｅｍｂｏｌａｇｅｔなどの酒類販売店からの購入をブロックし得、またはＩＣＡおよび／またはＣｏｏｐなどの特定の食品チェーン、または食料品店などの特定のタイプの加盟店からのみ購入を可能とし得る。

したがって銀行固有データベースモジュール１３０の銀行処理手段１３５は、要求された購入が銀行固有データベースモジュール１３０におけるトランザクションＩＤに関連付けられた購入ルールを満たすかに基づいて、購入承認要求を承認または却下する。銀行固有データベースモジュール１３０の銀行処理手段１３５は、トランザクション認証モジュール５２０から受信したトランザクション情報も、銀行固有データベースモジュール１３０におけるトランザクションＩＤに関連付けられたメタデータとして加え、このトランザクション情報を、トランザクションＩＤに関連付けられたメタデータとしてさらに加えられるように、中央データベース構成１１０に転送する。これは、トランザクション認証モジュール５２０に承認／却下が送信される前または後のいずれに実施されてよい。

トランザクション情報は好ましくは、中央データベース構成１１０における機能により、好ましくは購入機関２００により定義されたデータフォーマットである、別のデータフォーマットに「移行」または変換される。これは、図５を参照してさらに説明される。

銀行固有データベースモジュール１３０の銀行処理手段１３５から、例えばカードデータ、勘定残高、制限、および挙動をチェックすることで実行される一般的なトランザクション認証と共に受信した承認／却下に基づき、トランザクション認証モジュール５２０はトランザクションを承認または却下する。銀行固有データベースモジュール１３０の銀行処理手段１３５がトランザクションを却下すると、トランザクション認証モジュール５２０は、一般的なトランザクション認証チェックにより許容されると示されたトランザクションであっても却下する。同様に、一般的なトランザクション認証チェックにより、トランザクションが許容されないことが示されると、たとえ銀行固有データベースモジュール１３０の銀行処理手段１３５が購入を承認したとしても、トランザクション認証モジュール５２０はトランザクションを却下する。そのような状況では、トランザクションはいずれにせよ却下されるため、トランザクション認証モジュール５２０は、購入承認要求を銀行固有データベースモジュール１３０に送信しなくてもよい。

購入承認要求が銀行固有データベースモジュール１３０に送信される前に、一般的なトランザクション認証がトランザクション認証モジュール５２０において実行された場合に、銀行固有データベースモジュール１３０の銀行処理手段１３５が購入承認要求を承認または却下するかを判断すると、銀行固有データベースモジュール１３０の銀行処理手段１３５はトランザクション認証モジュール５２０がトランザクションを承認または却下するかを判定することができる。あるいは、トランザクション認証モジュール５２０は、この情報を銀行固有データベースモジュール１３０に転送し得る。トランザクション認証モジュール５２０によりトランザクションが承認されたか却下されたかに関する情報は、銀行固有データベースモジュール１３０におけるトランザクションＩＤに関連付けられたメタデータとして加えられ得る。

他のタイプの情報も、銀行固有データベースモジュール１３０におけるトランザクションＩＤに関連付けられたメタデータとして加えられ得る。銀行５００は例えば、詐欺の疑い、トランザクションステータスについての情報、またはその他同様のタイプの情報を、銀行固有データベースモジュール１３０に提供し得る。これにより、この情報は中央データベース構成１１０に転送され得る。

中央データベース構成１１０がトランザクション情報を、トランザクションＩＤに関連付けられたメタデータとして受信すると、中央データベース構成１１０の中央処理手段１１５は、トランザクション情報を、好ましくは購入機関２００により定義されたデータフォーマットで、購入機関２００に転送し得る。これにより、トランザクション情報は購入機関２００の経理システムおよび／またはその他管理システムに自動的に入力可能になる。このようにして、購入機関はサプライヤ／加盟店からいかなる請求書を受信するかなり前から、全トランザクションを把握し得る。これにより、購入機関２００は、常にその予算を確認可能で、それに従って購入ルールを適応可能である。

購入ルールは様々な理由で適応され得る。購入機関２００の所定のサブセクションが１つの購入グループ３００としてみなされるが、例えば、所定の購入個人には追加の制限を課す（またはあらゆる購入までブロックする）ために、このサブセクション内の所定の購入個人に対して購入ルールを適応させることが望ましい場合、この購入個人に対して、サブセクションの他の者よりもより制限された購入ルールで、新たな購入グループ３００が生成され得る。したがって、購入グループ３００と、購入ルールとのいずれもが、購入機関２００により動的に更新され得る。

購入機関２００は、システム内で、必ずしも実際の購入グループを定義しない。むしろ、購入機関２００は、例えば複数の階層について購入ルールを定義し得る。ルールの一部は組織全体について一般的な物であり得、その他のルールは一部の個人または個人のグループに特有であり得る。この用途の文脈では、購入グループ３００は、同じ購入ルールが適用される１または複数の購入個人のグループである。

中央データベース構成１１０において、メタデータをトランザクションＩＤに関連付けられることを可能にするフィールドも、購入機関２００により動的に設定され得る。これにより、購入機関２００は、所望のメタデータと、このメタデータに対するデータフォーマットを定義し得る。これにより、例えば、コストセンター、アカウント、およびその他の請求情報に関するメタデータを、中央データベース構成１１０におけるトランザクションＩＤに関連付けることが可能となる。これにより、購入機関２００は、受信を希望するメタデータと、その受信に望ましいフォーマットとを、電子インボイス内に定義可能となる。したがって、このメタデータは、中央データベース構成１１０から取得され、電子インボイスに加えることが可能となる。そのような電子インボイスは、銀行５００から、中央データベース構成１１０から、またはサードパーティーから送信され得る。システム１００を使用して行われたトランザクションに対する請求書が、購入機関２００により特定されたメタデータを含む電子インボイスであれば、購入機関２００による請求書の処理の自動化が可能となり、管理に伴う作業負荷が大幅に削減可能となる。

本発明は、例えば支払いの実行に支払いカードを使用し得る。この場合、購入個人についての情報は、図３に示すように、中央データベース構成１１０から支払いカード発行機関６００に転送され得る。この転送は、中央データベース構成１１０と、支払いカード発行機関６００との間で直接実施され得、あるいは銀行５００内の支払いカード管理モジュール５１０を介して実行され得る。支払いカード発行機関６００は、銀行５００に関連付けられ得るが、別個の支払いカード発行機関６００でもあり得る。

支払いカードで行った支払いを、購入を行う購入個人に結び付けるため、好ましくは支払いカードについての情報が、支払いカード発行機関６００から直接または銀行５００内の支払いカード管理モジュール５１０を介して、中央データベース構成１１０に転送される。好ましくは、この情報は、実際のクレジットカード番号ではない。これを中央データベース構成１１０におけるトランザクションＩＤに関連付けられたメタデータとして格納することが許可されているかについて制限があり得るためである。その代わりに情報は、例えばクレジットカード番号のトークンであり得る。

図４は、本明細書で説明される１または複数の実施形態に係る、購入管理方法の例示的な流れ図である。流れは以下のとおりである。

段階４１０：購入機関２００が、中央データベース構成１１０においてその購入ルールを設定する（これは段階４６０前の任意の時点で実施され得、メタデータが流れの任意の時点で購入機関２００によって加えられ得る）。

段階４１５：中央データベース構成１１０が、カード保有者銀行５００から、購入機関２００に対するカードアカウントを注文する。段階４２０：カード保有者銀行５００は、支払いカード発行機関６００から、支払いカードを注文する。

段階４２５：カードのカスタマイズまたはロゴなどの追加情報が、中央データベース構成１１０から支払いカード発行機関６００に提供され得る。支払いカードは、支払いカード発行機関６００により、中央データベース構成１１０から直接注文されてもよい。

段階４３０：支払いカードが、支払いカード発行機関６００から、購入個人３００に送られる（購入機関２００が配布に関与し得る）。

段階４３５（任意）：購入個人３００が、購入に関連したメタデータを、中央データベース構成１１０にユーザインタフェースを介して加える（これは、流れの任意の時点で実施され得る）。

段階４４０：トランザクションＩＤと、購入ルールなどのそれらに関連付けられたメタデータが、中央データベース構成１１０から銀行固有データベースモジュール１３０に転送される。段階４４５：購入個人が、加盟店／サプライヤ４００から購入を行う。

段階４５０：加盟店銀行５５０が、購入についての情報を、加盟店／サプライヤ４００から受信する。

段階４５５：加盟店銀行５５０が、カード保有者銀行５００に、例えばビザまたはマスターカードなどの支払いカードネットワークを介して、トランザクションを認証することを要求する。

段階４６０：カード保有者銀行５００が、銀行固有データベースモジュール１３０から、購入承認を要求する。

段階４６５：銀行固有データベースモジュール１３０が、カード保有者銀行５００に購入承認を送信する。段階４７０：カード保有者銀行５００が、トランザクション認証を加盟店銀行５５０に送信する。段階４７５：加盟店銀行５５０が、トランザクション許可を、加盟店／サプライヤ４００に送信する。

段階４８０：銀行固有データベースモジュール１３０が、承認された購入に関するトランザクション情報を中央データベース構成１１０に転送する（これは、段階４６０後の任意の時点で実施され得る）。

段階４８５：中央データベース構成１１０が、トランザクション情報を購入機関２００に転送する。

段階４９０（任意）：サードパーティーが、メタデータをトランザクションに加える（これは流れにおける任意の時点で実施され得る）。

図５は、本明細書で説明される１または複数の実施形態に係る、購入管理システム１００の一部を概略的に示す。中央データベース構成１１０は、好ましくは、メタデータをトランザクションＩＤに関連付け可能とする「メタデータキャリア」の動的設定を用いる。これにより、購入機関２００は、所望のメタデータと、このメタデータ用のフォーマットを定義し得る。図１から図３に関して上述したように、中央データベース構成１１０は、例えば、購入機関２００、購入個人、あるいは購入グループ３００、加盟店／サプライヤ４００、カード保有者銀行５００、支払いカード発行機関６００、およびその他の各種サードパーティー機関１５０などの多数の異なる団体と相互作用および通信し得る。中央データベース構成１１０が、これらの団体からデータを収集可能で、これらの団体に対してデータを送受信可能となるように、中央データベース構成１１０は、これらの異なる団体のそれぞれにより用いられるデータフォーマットを、単一のデータフォーマット、好ましくは購入機関２００により定義されたデータフォーマットに「移行」または変換する、例えば「アダプタ」の形式の、機能を有する必要がある。中央データベース構成１１０は、団体２００、３００、４００、５００、６００、１５０それぞれに対して、特定のアダプタ２０５、３０５、４０５、５０５、６０５、１５５を有する必要がある。これは、異なる団体は、概して異なるデータフォーマットを使用するためである（いくつかの異なるサードパーティー１５０がある場合、概していくつかの異なるアダプタ１５５が必要となる）。これにより、購入機関２００は、異なる団体から受信を希望するメタデータと、このメタデータのデータフォーマットを定義可能となる。ユースケース

本発明をさらに説明するため、以下のユースケースを提供する。購入機関であるＡ社は、サービス部門、開発部門、販売部門、および管理部門というサブセクションを擁する。Ａ社は、その購入ポリシーおよびルールを、クライアントインタフェース１２０を通じて中央データベース構成１１０に定義し、その銀行である、Ｃａｒｄｂａｎｋから、その全購入個人用に、支払いカードを注文する。一部の購入個人は個人支払いカードを有し、その他は共用支払いカードを有する。

Ａ社は、そのサブセクションであるサービス部門を、サービスという購入グループとして定義し、同グループの全スタッフに同じ購入ルールが適用される。サービス部門のスタッフは、故障した設備に対して迅速なサービスを提供するため、長距離かつ急に出張することが可能でなければならない。したがって、サービスという購入グループ内の全購入個人は個人支払いカードを有し、サービスという購入グループに対する購入ルールには、制限が非常に少ない。一方で、Ａ社は、サービス部門の予算に対して、常に全購入を確認する必要があり、予算的制限のために、経時的に購入ルールを適応し得る。

Ａ社は、そのサブセクションである開発部門を、追加の制限をかなり多くして、開発という購入グループとして定義する。開発部門のスタッフは、Ａ社の従業員と、コンサルタントの両方を含む。開発部門のスタッフは、開発部門の責任者により事前に承認されていない購入を行うことは一切許可されない。開発部門のスタッフの一部は、個人支払いカードを有するが、共用支払いカードも多数、開発という購入グループで使用される。

Ａ社は、そのサブセクションである販売部門を、国内販売と、海外販売との２つの購入グループとして定義する。国内販売という購入グループは、通常、海外出張をしないため、購入ルールは、国内での購入に限定できる。一方で、海外販売という購入グループは、長距離出張するため、購入ルールにおける制限がかなり少なくなり得る。ただし、購入ルールは、例えばＡ社が割引を受けられるホテルおよびホテルチェーンのリストにないホテルが選択された場合に、事前承認が必要とするものと規定し得る。販売部門の全スタッフは、個人支払いカードを有する。

Ａ社は、そのサブセクションである、管理部門を管理という購入グループとして定義する。管理部門のスタッフは、事務用や昼食など、少額の購入を行うことが可能である必要がある。したがって、購入ルールは、例えば金額およびサプライヤに限定され得る。管理部門という購入グループは、共用支払いカードを有する。

サービス部門の従業員が、支払いカードにより購入を行おうとすると、加盟店銀行は、トランザクション認証要求を、例えば図６に示されるトランザクション認証情報を含む、支払いカードネットワークを介してＣａｒｄｂａｎｋに送信する。Ｃａｒｄｂａｎｋのトランザクション認証モジュール５２０は、トランザクション認証要求を受信し、例えばカードデータ、勘定残高、制限、および挙動に関する、複数のチェックを実行する。Ｃａｒｄｂａｎｋのトランザクション認証モジュール５２０は、これらチェックに基づいて、トランザクションを承認すると判断した場合、購入承認要求を、Ｃａｒｄｂａｎｋ内の銀行固有データベース１３０に送信する。そこで、トランザクションＩＤは、それらに関連付けられるメタデータとともに格納される。

サービス部門の従業員は全員同じ購入ルールが適用されるため、銀行固有データベース１３０は、サービスという購入グループにタグ付けされた、データベースにおける次の利用可能なトランザクションＩＤに購入を割り当て得る。この場合、サービスという購入グループに購入が関するかは、例えば支払いカード番号を使用して判定され得る。しかしながら、一方で特定のトランザクションＩＤが、既にこのトランザクションＩＤに関連付けられたメタデータを加え得たサービス部門の従業員により既に選択されている可能性がある。サービス部門のスタッフに対する購入ルールは、トランザクションＩＤに関連付けられたメタデータとして格納されているため、銀行固有データベース１３０は、要求された購入がサービス部門の購入ルールを満たすかに基づいて、承認または却下することで、購入承認要求について判断する。

サービス部門の購入ルールに対しては、制限は非常に少ないため、多く場合、購入は許可される。銀行固有データベース１３０は、トランザクションＩＤに関連付けられたメタデータとして、トランザクション情報を格納し、このメタデータを中央データベース構成１１０に転送する。次に、中央データベース構成１１０は、トランザクション情報をＡ社に転送する。これにより、購入についての情報が、Ａ社における経理およびその他管理システムに自動的に入力され得る。

開発部門のスタッフが購入を行う際、同様の流れが辿られる。しかしながら、開発部門のスタッフは、開発部門の責任者により事前に承認されていない購入は一切許可されないため、購入について事前承認が必要である。購入を行いたい開発部門のスタッフは、購入グループ３００について指定されたインタフェース（例えば、ウェブインターフェースまたはモバイルアプリケーション）を使用して、トランザクションＩＤを取得し、この購入に関連した必要なメタデータを、インタフェースを通じて中央データベース構成１１０に入力する。次に、開発部門の責任者がこの購入を事前承認するための動作が設定される。これは、単にシステムで定義された動作であり得るが、責任者に、例えばＳＭＳまたはｅメールを介して、自動的にリマインダーが送信されてもよい。開発部門の責任者が購入を承認すると、購入ルールによりそれが可能になる。

販売部門のスタッフが購入を行う際、同様の流れが辿られる。サービス部門のスタッフに関して、海外販売という購入グループに課せられる制限は非常に少ない。しかしながら、例えば経費を少々使い過ぎであることが判明すれば、海外販売内の個人または個人のグループについて、購入ルールを変更することが望ましく成り得る。次に、例えば経費に関して追加の制限が課された新たな購入グループが定義され得る。これにより、海外販売という購入グループであったものが、例えば海外販売標準、海外販売制限の２つのグループになる。

管理部門のスタッフが購入を行う際も、同様の流れが辿られる。しかしながら、管理部門のスタッフには、より厳しい購入ルールが課される。例えば、許容サプライヤ／加盟店に関する制限が課される。Ｃａｒｄｂａｎｋのトランザクション認証モジュール５２０から送信されたトランザクション情報は、例えば加盟店の名前または加盟店を識別するためのコードのような加盟店情報も含む。したがって、銀行固有データベース１３０は、加盟店情報を、購入ルールに応じた許容加盟店と比較し得る。管理部門のスタッフは、例えばＩＣＡおよび／またはＣｏｏｐなどの所定のサプライヤ／加盟店、または例えば食料品店などの所定のタイプの加盟店に限定され得る。ＶＩＳＡの加盟店カテゴリ分類は、例えばＭＣＣコード５４９９を、「食料雑貨、コンビニエンスストア、専門店」に使用する。このコードは、トランザクション認証情報における加盟店識別コードに含まれる。管理部門のスタッフが食料品店で食品を購入する場合、異なる種類の物品に、多くの異なるＶＡＴレベルが適用され得る。購入における異なる項目に対する異なるＶＡＴレベルはその後、トランザクションＩＤに関連付けられたメタデータとして自動で格納され得る。これにより、購入機関２００内の管理が簡略化される。方法実施形態

図７は、本明細書に記載の１または複数の実施形態に係る、購入管理方法７００を概略的に示す。方法７００は、以下を備え得る。

段階７１０：購入グループ３００に適用される購入ルールを、クライアントインタフェース１２０を通じて中央データベース構成１１０に入力する。

段階７２０：中央データベース構成１１０における第１トランザクションＩＤに関連付けられたメタデータとして、選択された購入グループ３００を加える。

段階７２５：中央データベース構成１１０における第１トランザクションＩＤに関連付けられたメタデータとして、購入グループ３００に適用する購入ルールを加える。

段階７３０：第１トランザクションＩＤに関連付けられたメタデータを、中央データベース構成１１０から銀行固有データベースモジュール１３０に転送する。

段階７４０：銀行５００内に配置されたトランザクション認証モジュール５２０において、第１トランザクションＩＤに関連付けられ、トランザクション認証情報を含む第１トランザクション認証要求を受信する。

段階７５０：トランザクション認証モジュール５２０から銀行固有データベースモジュール１３０に、少なくとも購入金額を含むトランザクション情報を含む購入承認要求を通信する。

段階７６０：要求された購入が、銀行固有データベースモジュール１３０における第１トランザクションＩＤに関連付けられた購入ルールを満たすかに基づいて、承認または却下することで、購入承認要求について判断する。

段階７６５：購入承認要求に対する承認または却下を、トランザクション認証モジュール５２０に応答する。

段階７７０：トランザクション認証モジュール５２０から、第１トランザクションＩＤに関連付けられた第１トランザクション認証要求に応答する。

段階７８０：トランザクション認証モジュール５２０から受信したトランザクション情報を、銀行固有データベースモジュール１３０における第１トランザクションＩＤに関連付けられたメタデータとして加える。

段階７８５：第１トランザクションＩＤに関連付けられたトランザクション情報を中央データベース構成１１０に転送する。

段階７９０：第１トランザクションＩＤに関連付けられたトランザクション情報を、購入機関２００に転送する。これにより、購入についての情報が購入機関２００の管理システムの少なくとも１つに自動入力され得る。

実施形態において、上記銀行固有データベースモジュール１３０は、上記銀行５００内に配置される。これにより、購入承認要求に対する短時間での応答が可能となる。さらに、規制上の理由で銀行のファイアウォールの外部に送信が許可されないタイプのトランザクション情報を、銀行固有データベースモジュール１３０における第１トランザクションＩＤに関連付けられたメタデータとして加えることを可能とする。銀行の外部から受信、および／または外部へ送信可能なトランザクション情報に関しては厳しい規制要件が存在する。しかし、銀行内に銀行固有データベース１３０モジュールを配置することで、銀行の外部から受信、および／または外部へ送信許可されないトランザクション情報も、銀行固有データベースモジュール１３０に入力され得る。

実施形態において、購入グループ３００は、少なくとも１の購入個人を含む。これにより、１または複数の特定の購入個人、または１または複数の購入個人を含む購入機関のサブセクションに対して、購入ルールが定義および適応可能となる。

実施形態において、購入グループ３００は、購入機関２００全体を含む。これにより、購入機関が、機関全体に対して一般購入ルールを定義可能となる。

実施形態において、購入ルールは、購入機関２００のサブセクションに対する一般購入ルールであり、購入グループ３００に適用される購入ルールを、中央データベース構成１１０における第１トランザクションＩＤに関連付けられたメタデータとして加える段階７２５は、購入グループ３００がどのサブセクションに属するかを決定する段階を含む。

実施形態において、トランザクション情報は、例えば加盟店の名前、または加盟店を識別するためのコードなどの加盟店情報を含む。承認または却下することで、購入承認要求について判断する段階７６０は、さらに加盟店情報に基づく。

実施形態において、購入ルールは、購入実行前に、所定のメタデータが、中央データベース構成１１０におけるトランザクションＩＤに加えられ、関連付けられている必要があると指定する。購入承認要求について判断する段階７６０は、当該メタデータが存在せず、銀行固有データベースモジュール１３０におけるトランザクションＩＤに関連付けられていなければ、購入承認要求を却下する段階を含む。

実施形態において、第１トランザクションＩＤに関連付けられたメタデータを、中央データベース構成１１０から銀行固有データベースモジュール１３０に転送する段階７３０、および第１トランザクションＩＤに関連付けられたトランザクション情報を中央データベース構成１１０に転送する段階７８５は、中央データベース構成１１０および銀行固有データベースモジュール１３０を、互いに反映された形態となるように同期する段階を含む。

実施形態において、中央データベース構成１１０は、多数の異なる団体２００、３００、４００、５００、６００、１５０と通信するように構成され、これらの異なる団体のそれぞれで用いられるデータフォーマットを、好ましくは購入機関２００により定義されたデータフォーマットである、単一のデータフォーマットに変換するアダプタ２０５、３０５、４０５、５０５、６０５、１５５を備える。方法７００は、さらに以下を備え得る。

段階７０５：直接または銀行５００内の支払いカード管理モジュール５１０を介して、中央データベース構成１１０から支払いカード発行機関６００に情報を転送する。これにより、支払いカード発行機関６００は、支払いカードを購入機関２００に発行し得る。

上記の開示は、開示されている厳密な形式、または、特定の使用分野に本発明を限定することを意図するものではない。

本明細書において明示的に説明されるか、または、示唆されるかに関わらず、本開示を考慮して、様々な代替的な実施形態および／または本発明への修正が可能であると考えられる。

本開示において、支払いカードを使用する発明の実施形態を説明した。しかしながら、本発明は、支払いカードを使用した実施形態に限定されず、例えば、スマートフォン、または例えばＱＲ、ＥＡＮ、ＰＩＮコードといった他のデバイスを使用した支払いなどの他の支払い方法も網羅する。したがって、本発明の範囲は、特許請求の範囲によってのみによって定義される。

さらに、特許請求の範囲の段階の全てが、記載の順序で実行される必要はない。例えば、購入ルールは、トランザクションＩＤ生成前に中央データベース構成１１０に入力される必要はない。さらに、購入機関２００が購入ルールを変更して、新しい購入ルールを中央データベース構成１１０に入力すると、中央データベース構成１１０におけるトランザクションＩＤに関連付けられた購入ルールに関するメタデータが更新され、トランザクションＩＤに対して購入承認要求が承認されるか却下されるまで、銀行固有データベースモジュール１３０に転送され得る。別の例では、トランザクション情報が、購入承認要求の承認／却下の前または後に、トランザクションＩＤに関連付けられたメタデータとして加えられ得る。全ての技術的に意味のある段階の順序を、特許請求の範囲により網羅する。

Claims (20)

1. 中央データベース構成と、前記中央データベース構成へのクライアントインタフェースと、銀行内のトランザクション認証モジュールと通信するように構成された銀行固有データベースモジュールと、を備え、
   前記中央データベース構成は、前記クライアントインタフェースを通じて、購入機関から購入グループに適用される購入ルールを受信するように構成され、中央処理手段を有し、前記中央処理手段は、
   選択された購入グループを、前記中央データベース構成における第１トランザクションＩＤに関連付けられたメタデータとして加え、
   前記購入グループに適用される前記購入ルールを、前記中央データベース構成における前記第１トランザクションＩＤに関連付けられたメタデータとして加え、
   前記銀行固有データベースモジュールに前記第１トランザクションＩＤに関連付けられたメタデータを転送するように構成され、
   前記銀行固有データベースモジュールは、前記トランザクション認証モジュールから購入承認要求を受信するように構成され、前記購入承認要求は、前記第１トランザクションＩＤに関連付けられた購入金額を少なくとも含むトランザクション情報を含み、前記銀行固有データベースモジュールは、銀行処理手段を有し、前記銀行処理手段は、
   前記銀行固有データベースモジュールにおける前記第１トランザクションＩＤに関連付けられた前記購入ルールを、要求された購入が満たすかに基づいて、承認または却下することで、前記購入承認要求について判断し、
   前記購入承認要求の承認または却下により、前記トランザクション認証モジュールに応答し、
   前記トランザクション認証モジュールから受信した前記トランザクション情報を、前記銀行固有データベースモジュールにおける前記第１トランザクションＩＤに関連付けられたメタデータとして加え、
   前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を、前記中央データベース構成に転送するように構成され、
   前記中央データベース構成の前記中央処理手段はさらに、前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を、前記購入機関に転送するように構成され、これにより、前記購入についての情報が前記購入機関の少なくとも１つの管理システムに自動的に入力され得る、購入管理システム。
2. 前記銀行固有データベースモジュールは、前記銀行内に配置される、請求項１に記載の購入管理システム。
3. 前記購入ルールは、少なくとも１の購入個人を含む購入グループに適用される購入ルールである、請求項１または２に記載の購入管理システム。
4. 前記購入ルールは、前記購入機関全体を含む購入グループに適用される購入ルールである、請求項１から３のいずれか一項に記載の購入管理システム。
5. 前記購入ルールは、前記購入機関のサブセクションに対する一般購入ルールであり、前記中央データベース構成の前記中央処理手段は、前記購入グループがどのサブセクションに属するかの決定に基づいて、前記購入グループに適用される前記購入ルールを、前記中央データベース構成における前記第１トランザクションＩＤに関連付けられたメタデータとして加えるように構成される、請求項１から４のいずれか一項に記載の購入管理システム。
6. 前記トランザクション情報は、加盟店情報を含み、前記銀行固有データベースモジュールの前記銀行処理手段は、さらに前記加盟店情報に基づいて、承認または却下することで、前記購入承認要求について判断するように構成される、請求項１から５のいずれか一項に記載の購入管理システム。
7. 前記購入ルールは、購入実行前に、所定のメタデータが、前記中央データベース構成における前記トランザクションＩＤに加えられ、関連付けられている必要があると指定し、前記銀行固有データベースモジュールの前記銀行処理手段は、当該メタデータが存在せず、前記銀行固有データベースモジュールにおける前記トランザクションＩＤに関連付けられていなければ、前記購入承認要求を却下するように構成される、請求項１から６のいずれか一項に記載の購入管理システム。
8. 前記中央データベース構成の前記中央処理手段は、直接または前記銀行内の支払いカード管理モジュールを介して、支払いカードを前記購入機関に発行する支払いカード発行機関に情報を転送するようにさらに構成される、請求項１から７のいずれか一項に記載の購入管理システム。
9. 前記購入管理システムは、前記中央データベース構成および前記銀行固有データベースモジュールが互いを反映した形態となるように同期されるように構成される、請求項１から８のいずれか一項に記載の購入管理システム。
10. 前記中央データベース構成は、多数の異なる団体と通信するように構成され、これらの異なる団体のそれぞれで用いられるデータフォーマットを、好ましくは前記購入機関により定義されたデータフォーマットである、単一のデータフォーマットに変換するアダプタを備える、請求項１から９のいずれか一項に記載の購入管理システム。
11. 購入グループに適用される購入ルールを、クライアントインタフェースを通じて中央データベース構成に入力する段階と、
    前記中央データベース構成における第１トランザクションＩＤに関連付けられたメタデータとして、選択された購入グループを加える段階と、
    前記中央データベース構成における前記第１トランザクションＩＤに関連付けられたメタデータとして、前記購入グループに適用する前記購入ルールを加える段階と、
    前記第１トランザクションＩＤに関連付けられたメタデータを、前記中央データベース構成から銀行固有データベースモジュールに転送する段階と、
    銀行内に配置されたトランザクション認証モジュールにおいて、前記第１トランザクションＩＤに関連付けられ、トランザクション認証情報を含む第１トランザクション認証要求を受信する段階と、
    前記トランザクション認証モジュールから前記銀行固有データベースモジュールに、少なくとも購入金額を含むトランザクション情報を含む購入承認要求を通信する段階と、
    要求された購入が、前記銀行固有データベースモジュールにおける前記第１トランザクションＩＤに関連付けられた前記購入ルールを満たすかに基づいて、承認または却下することで、前記購入承認要求について判断する段階と、
    前記購入承認要求に対する承認または却下を、前記トランザクション認証モジュールに応答する段階と、
    前記トランザクション認証モジュールから、前記第１トランザクションＩＤに関連付けられた前記第１トランザクション認証要求に応答する段階と、
    前記トランザクション認証モジュールから受信した前記トランザクション情報を、前記銀行固有データベースモジュールにおける前記第１トランザクションＩＤに関連付けられたメタデータとして加える段階と、
    前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を前記中央データベース構成に転送する段階と、
    前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を、購入機関に転送し、これにより、前記購入についての情報が前記購入機関の少なくとも１つの管理システムに自動入力され得る段階と、を備える、購入管理方法。
12. 前記銀行固有データベースモジュールは、前記銀行内に配置される、請求項１１に記載の購入管理方法。
13. 前記購入グループは、少なくとも１の購入個人を含む、請求項１１または１２に記載の購入管理方法。
14. 前記購入グループは、前記購入機関全体を含む、請求項１１から１３のいずれか一項に記載の購入管理方法。
15. 前記購入ルールは、前記購入機関のサブセクションに対する一般購入ルールであり、前記購入グループに適用される前記購入ルールを、前記中央データベース構成における前記第１トランザクションＩＤに関連付けられたメタデータとして加える段階は、前記購入グループがどのサブセクションに属するかを決定する段階を含む、請求項１１から１４のいずれか一項に記載の購入管理方法。
16. 前記トランザクション情報は、加盟店情報を含み、承認または却下することで、前記購入承認要求について判断する段階は、さらに前記加盟店情報に基づく、請求項１１から１５のいずれか一項に記載の購入管理方法。
17. 前記購入ルールは、購入実行前に、所定のメタデータが、前記中央データベース構成における前記トランザクションＩＤに加えられ、関連付けられている必要があると指定し、前記購入承認要求について判断する段階は、当該メタデータが存在せず、前記銀行固有データベースモジュールにおける前記トランザクションＩＤに関連付けられていなければ、前記購入承認要求を却下する段階を含む、請求項１１から１６のいずれか一項に記載の購入管理方法。
18. 直接または前記銀行内の支払いカード管理モジュールを介して、前記中央データベース構成から支払いカード発行機関に情報を転送する段階をさらに備え、これにより、前記支払いカード発行機関は支払いカードを前記購入機関に発行し得る、請求項１１から１７のいずれか一項に記載の購入管理方法。
19. 前記第１トランザクションＩＤに関連付けられたメタデータを、前記中央データベース構成から前記銀行固有データベースモジュールに転送する段階、および前記第１トランザクションＩＤに関連付けられた前記トランザクション情報を前記中央データベース構成に転送する段階は、前記中央データベース構成および前記銀行固有データベースモジュールを、互いに反映された形態となるように同期する段階を含む、請求項１１から１８のいずれか一項に記載の購入管理方法。
20. 前記中央データベース構成は、多数の異なる団体と通信するように構成され、これらの異なる団体のそれぞれで用いられるデータフォーマットを、好ましくは前記購入機関により定義されたデータフォーマットである、単一のデータフォーマットに変換するアダプタを備える、請求項１１から１９のいずれか一項に記載の購入管理方法。

Images