JP2023545323A - コンテキストデータおよびメタデータに基づく支払い属性の動的で予測的な調整 - 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