(57)【要約】  輸送サービスに自動コンピュータ検証を提供するためのコンピュータ実装システム及び方法が開示される。システムは、通信ネットワークと接続する１つ以上のサーバに常駐する１つ以上のデータベース、ベンダモジュール、サービスプロバイダモジュール、運転者モジュール、及び１つ以上のプロセッサに、サービス要求を受け取り、請求書作成要求を生成し、サービス要求を請求書作成要求と比較するように命令するための命令を記憶できる非一過性コンピュータ可読媒体を含む。また、プロセッサは、サービス要求と関連付けられた運転者又は乗客が、請求書作成要求生成時に受入可能範囲内にいるかどうかを識別して、サービス要求の完了を検証する又は請求書作成要求を条件付きで拒絶するかのどちらかを行うように構成される。受入可能範囲は、収集されたデータに基づいて動的に更新されてよい。【選択図】図１Ａ
2020502634.tif 000002
【特許請求の範囲】
【請求項１】
輸送サービスに自動コンピュータ検証を提供するためのコンピュータ実装システムであって、
通信ネットワークと接続する１つ以上のサーバ上に常駐する１つ以上のデータベースを備えるコンピューティングシステムと、
乗客にサービスを提供するためのサービス要求を送信するように構成されたベンダモジュールであって、前記サービス要求が、ピックアップ時間、ピックアップ場所、降車時間、又は降車場所のうちの少なくとも１つを含む、ベンダモジュールと、
前記ベンダモジュールから前記サービス要求を受け取り、前記サービス要求を運転者に割り当て、前記サービス要求を前記運転者に送信するように構成されたサービスプロバイダモジュールと、
前記サービス要求を受け取り、請求書作成要求を生成し、前記請求書作成要求を前記サービスプロバイダモジュールに送信するように構成された運転者モジュールと、
１つ以上のプロセッサに、
前記サービスプロバイダモジュールによって、複数のコンピューティングデバイスのうちの１つを通して前記ベンダモジュールから前記サービス要求を受け取り、
前記サービスプロバイダモジュールによって、前記サービス要求を前記運転者モジュールに送信し、
前記運転者モジュールによって、前記請求書作成要求を生成し、
前記サービス要求を前記請求書作成要求と比較し、
前記請求書作成要求生成時に、前記運転者又は前記乗客が受入可能範囲内にいるのかを識別し、前記受入可能範囲が（ｉ）前記ピックアップ場所からの所定の距離、（ｉｉ）前記降車場所からの所定の距離、（ｉｉｉ）前記ピックアップ時間に対する所定の時間、又は（ｉｖ）前記降車時間に対する所定の時間のうちの少なくとも１つによって特徴付けられる１つ以上の所定の規則に基づき、
前記受入可能範囲内にいるとして識別される前記運転者又は前記乗客を条件として前記サービス要求の完了を確認する
ように命令するための命令を記憶できる非一過性コンピュータ可読記憶媒体と
を備える、前記システム。
【請求項２】
前記１つ以上のプロセッサが、
（ａ）実際のピックアップジオロケーション、（ｂ）実際の降車ジオロケーション、（ｃ）実際のピックアップ時間、又は（ｄ）実際の降車時間のうちの少なくとも１つを、前記請求書作成要求を生成する前に決定し、
前記請求書作成要求に、（ｅ）前記実際のピックアップジオロケーション、（ｆ）前記実際の降車ジオロケーション、（ｇ）前記実際のピックアップ時間、又は（ｈ）前記実際の降車時間のうちの少なくとも１つを含める
ように構成される、請求項１に記載のシステム。
【請求項３】
前記受入可能範囲が、時間及びジオロケーション又は場所のうちの１つに関係する、請求項１に記載のシステム。
【請求項４】
前記請求書作成要求が、少なくとも１つ以上のピックアップ場所、ピックアップ時間、降車場所、又は降車時間を含む、請求項１に記載のシステム。
【請求項５】
前記システムが、
前記運転者による前記サービス要求の完了を確認する前記乗客からの情報を少なくとも送信するように構成された乗客モジュール、
をさらに備え、
前記情報が、署名、ＰＩＮ、パスコード、指紋、他の生体情報、又は前記乗客からの前記請求書作成要求を確認するための任意の他の手段のうちの少なくとも１つを含む
請求項１に記載のシステム。
【請求項６】
前記情報が、少なくとも１つのタイムスタンプ又は場所データを含み、前記サービスの開始、前記サービスの終了、又は前記サービスに関連性がある任意の他のときのうちの１つに提供される、請求項５に記載のシステム。
【請求項７】
比較するための前記命令が、前記運転者が前記受入可能範囲内にいるかどうかを判断するために、（ａ）前記ピックアップ場所及び実際のピックアップ場所、（ｂ）前記降車場所及び実際の降車場所、（ｃ）前記ピックアップ時間及び実際のピックアップ時間、又は（ｄ）前記降車時間及び実際の降車時間のうちの１つ以上の比較を含む、請求項１に記載のシステム。
【請求項８】
前記１つ以上のプロセッサが、
前記乗客のための前記運転者のピックアップの意思又は前記乗客のための前記運転者の降車の意思を識別し、
前記ピックアップの意思又は前記降車の意思を確認するように前記運転者に促し、
前記運転者又は前記乗客が前記受入可能範囲内にいるかどうかを識別し、
前記運転者又は前記乗客が前記受入可能範囲内にいるかどうかに関して前記運転者に警告する
ように構成され、
前記ピックアップの意思又は前記降車の意思が、前記ピックアップ場所又は前記降車場所の所定距離範囲内にいる間の前記運転者の所定の速度に基づく
請求項１に記載のシステム。
【請求項９】
前記ピックアップの意思又は前記降車の意思の確認時に、前記１つ以上のプロセッサが、前記受入可能範囲内にいることができないことを前記運転者に警告するように構成される、請求項８に記載のシステム。
【請求項１０】
前記１つ以上のプロセッサが、
前記サービス要求の完了の確認時に前記サービス要求に一致するように前記請求書作成要求を調整する、又は
前記運転者が前記受入可能範囲内にいることができないことに基づいて、前記請求書作成要求の条件付き拒絶を発行する
ように構成される、請求項８に記載のシステム。
【請求項１１】
前記１つ以上のプロセッサが、
前記受入可能範囲内にいることができないとき、前記複数のコンピューティングデバイスのうちの少なくとも１つを通して前記請求書作成関連データを提出するように前記運転者に促し、
タイムスタンプ又はジオロケーションのために前記請求書作成関連データを取り出し、
前記請求書作成関連データで前記１つ以上のデータベースを動的に更新する
ように構成され、
前記請求書作成関連データが、前記サービス要求を完了しようとするが、前記受入可能範囲内にいることができない１つ以上の理由を含み、前記１つ以上の理由が、テキストデータ、音声データ、画像データ、又はビデオデータのうちの少なくとも１つを含む
請求項１に記載のシステム。
【請求項１２】
前記１つ以上のプロセッサが、
前記複数のコンピューティングデバイスのうちの少なくとも１つを通して、前記請求書作成関連データでの直接の経験を有する１人以上の追加のユーザから前記請求書作成関連データの１つ以上の検証を受け取る
ように構成され、
前記直接の経験が、前記１人以上の追加のユーザが、前記請求書作成関連データに基づいて前記請求書作成関連データに関する前記１つ以上の実際のジオロケーションまでの所定の距離範囲内に物理的にいる又はいたと判断されるとして識別される
請求項１１に記載のシステム。
【請求項１３】
前記１つ以上のプロセッサが、
前記請求書作成関連データが所定の期間内に所定数の肯定的な評価に達することに応えて前記サービス要求に一致するように前記請求書作成要求を調整し、
前記受入可能範囲を動的に更新する
ように構成される、請求項１１に記載のシステム。
【請求項１４】
前記１つ以上のプロセッサが、
前記請求書作成関連データが、所定の時間内に所定数の肯定的な評価を受け取ることができないことに応えて、前記請求書作成要求を拒絶する
ように構成される、請求項１に記載のシステム。
【請求項１５】
前記１つ以上のプロセッサが、
前記複数のコンピューティングデバイスのうちの１つ以上を通して前記請求書作成関連データでの直接の経験を有する１人以上の追加のユーザからクラウドソースによる請求書作成関連データを収集する
ように構成される、請求項１に記載のシステム。
【請求項１６】
前記１つ以上のプロセッサが、
前記請求書作成関連データ及び前記クラウドソースによる請求書作成関連データに基づいて、前記１つ以上のデータベースを動的に更新する
ように構成される、請求項１５に記載のシステム。
【請求項１７】
前記受入可能範囲が、予備受入可能範囲、恒久受入可能範囲、又は仮受入可能範囲のうちの少なくとも１つとして特徴付けられ、
前記予備受入可能範囲、前記恒久受入可能範囲、又は前記仮受入可能範囲のうちの１つだけしか一度にアクティブではない
請求項１に記載のシステム。
【請求項１８】
前記１つ以上のプロセッサが、
１つ以上の所定のデフォルトパラメータに基づいて前記サービス要求のための前記予備受入可能範囲として前記受入可能範囲を特徴付ける
ように構成される、請求項１７に記載のシステム。
【請求項１９】
前記１つ以上のプロセッサが、
前記１つ以上のユーザ関与パネルを通して前記請求書作成関連データを収集し、
前記請求書作成関連データに従って前記所定の規則に基づいて前記恒久受入可能範囲として前記予備受入可能範囲を再び特徴付けする
ように構成され、
前記恒久受入可能範囲が完全にアクティブとして特徴付けられ、
前記予備受入可能範囲及び前記仮受入可能範囲がアクティブではないとして特徴付けられる、
請求項１７に記載のシステム。
【請求項２０】
前記１つ以上のプロセッサが、
所定数の運転者が、前記場所のための前記恒久受入可能範囲外でサービスを完了したことに基づいて、前記仮受入可能範囲として前記受入可能範囲を特徴付け、
前記所定数の運転者が、前記仮受入可能範囲内で前記サービスを完了したことに基づいて、新しい恒久受入可能範囲として前記仮受入可能範囲を再び特徴付けする
ように構成される、請求項１７に記載のシステム。
【請求項２１】
前記１つ以上のプロセッサが、
所定数の運転者が前記場所のための前記恒久受入可能範囲外でサービスを完了したことに基づいて、セミアクティブとして前記恒久受入可能範囲を特徴付ける
ように構成され、
前記恒久受入可能範囲が、（ａ）前記仮受入可能範囲が前記新しい恒久受入可能範囲に変化する、又は（ｂ）少なくとも１人の前記運転者が前記セミアクティブ受入可能範囲内で前記サービスを完了するときまでセミアクティブなままである
請求項１７に記載のシステム。
【請求項２２】
前記１つ以上のプロセッサが、
（ｄ）前記ピックアップ場所又は前記降車場所までの所定の距離範囲内で複数の遠隔コンピューティングデバイスから受け取られる集まった請求書作成関連データ、（ｅ）前記恒久受入可能範囲外でサービス要求を完了した所定の第１の数の運転者、又は（ｆ）前記仮受入可能範囲内でサービス要求を完了した所定の第２の数の運転者のうちの１つに従って、（ａ）前記予備受入可能範囲から前記恒久受入可能範囲、（ｂ）前記恒久受入可能範囲から前記仮受入可能範囲、又は（ｃ）前記仮受入可能範囲から前記恒久受入可能範囲に、前記受入可能範囲の特徴付けを動的に修正する
ように構成される、請求項１７に記載のシステム。
【請求項２３】
前記１つ以上のプロセッサが、
前記乗客が所定の期間内に前記サービス要求を確認できないとき、前記ピックアップ場所からの前記乗客の不在を識別する
ように構成される
請求項１に記載のシステム。
【請求項２４】
前記１つ以上のプロセッサが、
前記運転者が前記ピックアップ場所で前記乗客を待機する時間の長さを追跡し、
前記乗客に連絡しようとする試行の証拠を前記運転者から受け取り、
前記乗客の前記不在を検証する前記請求書作成要求の少なくとも一部分とともに前記証拠を前記サービスプロバイダモジュールに送信する
ように構成される、請求項２３に記載のシステム。
【請求項２５】
前記１つ以上のプロセッサが、
前記指定されたピックアップ場所から前記所定の距離又は前記指定された降車場所から前記所定の距離の範囲内に位置する前記複数のコンピューティングデバイスから受け取られる請求書作成関連データを統合し、
前記統合された請求書作成関連データを前記１つ以上のデータベースに記憶し、
前記統合された請求書作成関連データに従って前記所定の規則を動的に更新する
ように構成される、請求項１に記載のシステム。
【請求項２６】
前記統合された請求書作成関連データが、（ａ）１つ以上のジオロケーションに対応する複数のＧＰＳデータ、又は（ｂ）前記統合された請求書作成関連データの送信の１つ以上の時間又は日に相当する複数の時間データのうちの少なくとも１つを含む、請求項２５に記載のシステム。
【請求項２７】
前記１つ以上のプロセッサが、
前記複数のコンピューティングデバイスのそれぞれが、前記ピックアップ場所からの前記所定の距離又は前記降車場所からの前記所定の距離の範囲内にあるかどうかを連続的に識別するために前記複数のＧＰＳデータを活用する
ように構成され、
前記統合された請求書作成関連データが連続的に実行される
請求項２６に記載のシステム。
【請求項２８】
前記統合された請求書作成関連データが、交通密度、人口密度、建設障害物、道路封鎖、車線封鎖、天候状態、駐車制限、道路規則、建設現場、一時的な道路阻絶、特別な警備事象、パレード、大決起集会、又は抗議行動のうちの少なくとも１つに関係する情報を含む、請求項２７に記載のシステム。
【請求項２９】
前記システムが、
前記運転者が、前記受入可能範囲内にいることができない理由を示す請求書作成関連データとして前記システムへの提出のためにデータを取り込むことができるように構成された地理認識カメラ
をさらに備え、
前記複数のコンピューティングデバイスが、１人以上のユーザが、肯定的な評価又は否定的な評価で前記請求書作成関連データを評価できるように構成される
請求項１に記載のシステム。
【請求項３０】
輸送サービスに自動コンピュータ検証を提供するための方法であって、
サービスプロバイダモジュールによって、複数のコンピューティングデバイスのうちの１つを通してベンダモジュールからサービス要求を受け取るステップと、
運転者に前記サービス要求を割り当てるステップと、
前記サービスプロバイダモジュールによって、前記サービス要求を運転者モジュールに送信するステップと、
前記運転者モジュールによって、請求書作成要求を生成するステップと、
前記サービス要求を前記請求書作成要求と比較するステップと、
前記運転者又は乗客が、前記請求書作成要求生成時に受入可能範囲内にいるかどうかを識別するステップであって、前記受入可能範囲が、（ｉ）ピックアップ場所からの所定の距離、（ｉｉ）降車場所からの所定の距離、（ｉｉｉ）ピックアップ時間に対する所定の時間、又は（ｉｖ）降車に対する所定の時間のうちの少なくとも１つによって特徴付けられる１つ以上の所定の規則に基づく、識別するステップと、
前記受入可能範囲内にいるとして識別される前記運転者又は前記乗客を条件として前記サービス要求の完了を確認するステップと
を含む、前記方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、２０１６年１１月１１日に出願され、Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｅｌｅｃｔｒｏｎｉｃ  Ｂｉｌｌｉｎｇと題する米国仮特許出願第６２／４２１、０８６号、及び２０１７年３月３０日に出願され、Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｇｅｏ−Ａｗａｒｅ  Ｔｒａｎｓｐｏｒｔａｔｉｏｎ  Ｂｉｌｌｉｎｇ  Ｖｅｒｉｆｉｃａｔｉｏｎと題する米国非仮特許出願第１５／４７４，６８５号に基づきその優先権を主張し、参照によりその全体が本明細書に援用される。
【０００２】
本開示は輸送に関し、より詳細には、輸送サービスの提供に関係する、輸送追跡及び電子請求書作成検証のためのジオロケーション認識機能を備えた検証システム及び方法に関する。
【背景技術】
【０００３】
グローバルポジショニングシステム（ＧＰＳ）は、携帯機器が、ＧＰＳ衛星配置から信号を取得し、それから携帯機器の位置を三角測量する、衛星をベースにしたジオロケーションシステムである。ＧＰＳ技術の幅広い可用性が広範囲の用途につながり、輸送を革命的に変化させてきた。
【０００４】
例えばＧＰＳ場所識別等の技術の進展は、ライドヘイリングサービスにおける種々の革新につながってきた。しかしながら、非緊急医療輸送（ｎｏｎ−ｅｍｅｒｇｅｎｃｙ  ｍｅｄｉｃａｌ  ｔｒａｎｓｐｏｒｔａｔｉｏｎ）（ＮＥＭＴ）請求書作成を含むが、これに限定されるものではない輸送請求書作成検証は、これらの同じ開発物、例えば場所検証のための自動化されたＧＰＳ追跡機能を組み込む追跡及び請求書作成システムを受け入れてこなかった。非緊急医療輸送は、概して医療に関係するが、緊急事態ではない輸送サービスに関する。他の医療上必要なサービスと同様に、非緊急医療輸送は、概して例えば医療保険企業、政府ヘルスケア部門若しくは機関、又は保険会社若しくは政府機関の代わりに働いている機関等のサードパーティに支払い請求可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
電子輸送請求書作成検証と関連付けられる１つの技術的な問題は、概して、コンピュータプログラムが多くの場合、指定された時間又は指定された場所に一致しない入力を拒絶する点である。これらの拒絶は、多くの場合任意の拒絶である。有効であるために、入力は柔軟性を欠いた構文を使用して提供されなければならず、システムは多くの場合、受入れ可能な構文が何であるのかにおいて厳しすぎる。これが、１つ以上の関係者により手作業で対応される必要がある場合がある、多大な時間を必要とする拒絶の請求書作成議論につながる場合がある。
【０００６】
第２の技術的な問題は、特定のプログラミングがコンピューティングシステムを、それが受け入れる可能性がある構文において大まか又は寛容にしすぎる場合があり、実際の時間又は実際の場所が、指定された時間又は指定された場所から不合理に逸脱する場合がある点である。この構文は、場所入力情報、時間入力情報、又はたいていの場合、それら２つの組合せに関する場合がある。受入れ可能な構文において寛容すぎるコンピューティングシステムは、コンピュータ実装検証の元の目標の観点では逆効果であり、詐欺防止のタスクは、その検証において寛容すぎるシステムのため、遂行できない。
【０００７】
第３の技術的な問題は、電子請求書作成検証システムが、なにが受入れ可能な入力であってよいのかに関して自己更新（ｓｅｌｆ−ｕｐｄａｔｅ）できず、受入れ可能な構文に対して、厳しすぎるのと大まかすぎるのとの間のバランスが変わる点である。受入れ可能な入力を定義するパラメータは、明確にプログラムされなければならない。本質的には、既存のシステムは、多くの場合入力値を拒絶し、自動化された方法で自己修正するすべをもっていない。代わりに、既存のシステムは、更新が必要であるたびに再プログラムされなければならない。再プログラミングは、多大な時間を必要とし、サービスの変化及び現実世界の状況に動的に対応しない可能性がある。例えば、指定された場所に患者を輸送するとき、例えば建設現場等の障害物又は他の妨害物が、患者が、患者が医療上必要なケアを受ける正確な場所に届けられるのを妨げる場合がある。結果として、降車場所は、運転者が到達できる考えられる最近傍の場所である場合があるが、既存の電子請求書作成検証システムは、実際の目的地住所が医療の目的地住所とは異なるときに支払いに対する、それ以外の場合合法的な請求を拒絶する場合がある。
【０００８】
既存の電子請求書作成検証システムは、厳しすぎるか、大まかすぎるか、又は輸送サービス請求受入れを可能にするほど十分に頻繁に更新されないかのどちらかである。輸送請求書作成は、おもに電子請求書作成検証に移り変わってきたが、該分野は、依然として電子請求書作成検証へのその移り変わりにおいて固有の障害に遭遇しており、技術の進展は、それに関連付けられた問題を大部分は無視してきた。本明細書に開示されるような技術に基づいた検証特長は、「受入可能範囲」を規定することによって、サービス要求が実際に提供されたこと、又は請求書作成要求の時間若しくは場所の偏差が、妥当な又は筋が通った原因に起因していたことを検証するための技術的な解決策を提供する。受入可能範囲は、厳しすぎるシステムと寛容すぎるシステムのバランスを提供する。
【課題を解決するための手段】
【０００９】
発明の概要は、本質的な特長を識別若しくは指す、又は本明細書で特許請求される主題の範囲を限定することを意図していない。以下の説明は、請求書作成要求を検証する際に受入可能範囲を規定し、更新するためのコンピュータ実装システム及び方法を含む。システムは、ドライバモジュールに接続するネットワーク内に配置される、少なくとも１つ以上のサーバ、１つ以上の地理情報システム（ＧＩＳ）、及び１つ以上のデータベースを実装してよく、それは、現在の時間及び日付を識別するために、少なくとも１つのジオロケーション識別子、地理認識（ｇｅｏ‐ａｗａｒｅ）カメラ、及びクロック機構を含んでよい。システムは、タスクをプログラムで実行するために命令を記憶する非一過性コンピュータ可読記憶媒体を含む。請求書作成要求及びその関係データを受け取ることを含んだそれらのタスクは、１つ以上のサーバによって展開できる。
【００１０】
受入可能範囲は、輸送サービス検証のためにシステムによって確立され、所定の規則が受入可能範囲のパラメータを管理する。関連する点では、運転者が、受入可能範囲の範囲内にいる、又は範囲内にいないことが判断されてよい。この判断は、運転者が、請求書作成要求で提供されるサービスに対する支払いの対象であるかどうかを判断するプロセスを開始するために使用されてよい。運転者が受入可能範囲の範囲内にいる場合、生成された請求書作成要求は、それがシステムにより受け入れられ得るように、受け取られた指定された情報に一致するように自動的に調整されてよい。運転者が受入可能範囲の範囲内にいない場合、運転者は、１つ以上の理由、及び／又はジオロケーション及び時間メタデータで補強された写真を提出するように促されてよい。この情報は、受入可能範囲の範囲内に到着できないことに対する筋が通った理由の証拠に使用されてよく、ユーザ関与パネルで提出されてよい。ユーザ関与パネルは、運転者が提出する情報の検証に参加する１人以上の追加のユーザから１つ以上の評価を収集するためのプラットフォームとして使用されてよい、ユーザインタフェース要素である。直接の経験を有するユーザは、運転者により提供される１つ以上の理由を含んだ情報に目を通し、運転者の理由が筋が通っていたことを確認又は拒否することを決定できるであろう。これが、運転者の提出物を評価するプロセスである。
【００１１】
一定数の肯定的な評価を受け取るユーザ関与パネル上で提供される情報は、データベースを動的に更新、補正、及び補足するために使用される。さらに、受入可能範囲を管理する所定の規則は、部分的には、収集されたデータが係る所定の規則を動的に更新するために使用されるユーザ関与パネルに関係する。
【００１２】
特定の実施形態では、輸送サービスに自動コンピュータ検証を提供するためのコンピュータ実装システムは、通信ネットワークと接続する１つ以上のサーバ上に常駐する１つ以上のデータベース、及び乗客にサービスを提供するためのサービス要求を送信するように構成されたベンダモジュールを含んだコンピューティングシステムを含む。サービス要求は、ピックアップ時間、ピックアップ場所、降車時間、又は降車場所のうちの少なくとも１つを含む。システムは、ベンダモジュールからサービス要求を受け取り、サービス要求を運転者に割り当て、サービス要求を運転者に送信するように構成されたサービスプロバイダモジュールをさらに含む。また、システムは、１つ以上のプロセッサに命令するための命令を記憶できる非一過性コンピュータ可読記憶媒体だけではなく、サービス要求を受け取り、請求書作成要求を生成し、サービスプロバイダモジュールに請求書作成要求を送信するように構成された運転者モジュールも含む。プロセッサは、サービスプロバイダモジュールによって、複数のコンピューティングデバイスのうちの１つを通して、ベンダモジュールからサービス要求を受け取り、サービスプロバイダモジュールによって運転者モジュールにサービス要求を送信し、運転者モジュールによって請求書作成要求を生成し、サービス要求を請求書作成要求に比較するように構成される。また、プロセッサは、請求書作成要求生成時に、運転者又は乗客が受入可能範囲の範囲内にいるのかを識別し、受入可能範囲の範囲内にいるとして識別される運転者又は乗客を条件として、サービス要求の完了を確認するように構成される。受入可能範囲は、（ｉ）ピックアップ場所からの所定の距離、（ｉｉ）降車場所からの所定の距離、（ｉｉｉ）ピックアップ時間に対する所定の時間、又は（ｖｉ）降車時間に対する所定の時間のうちの少なくとも１つにより特徴付けられる１つ以上の所定の規則に基づく。
【００１３】
特定の実施形態では、輸送サービスに自動コンピュータ検証を提供する方法は、サービスプロバイダモジュールによって、複数のコンピューティングデバイスのうちの１つを通してベンダモジュールからサービス要求を受け取ることと、サービス要求を運転者に割り当てることと、サービスプロバイダモジュールによって、サービス要求を運転者モジュールに送信することと、運転者モジュールによって、請求書作成要求を生成することと、サービス要求を請求書作成要求と比較することと、請求書作成要求生成時に、運転者又は乗客が受入可能範囲の範囲内にいるのかを識別することを含む。受入可能範囲は、（ｉ）ピックアップ場所からの所定の距離、（ｉｉ）降車場所からの所定の距離、（ｉｉｉ）ピックアップ時間に対する所定の時間、又は（ｉｖ）降車時間に対する所定の時間のうちの少なくとも１つによって特徴付けられる１つ以上の所定の規則に基づく。また、方法は、受入可能範囲の範囲内にあるとして識別される運転者又は乗客を条件として、サービス要求の完了を確認することも含む。
【００１４】
本発明の追加の理解は、添付図面に説明される好ましい実施形態及び例示的な実施形態に対する参照により得ることができる。図面は、添付される又はその後補正される特許請求の範囲の特殊性とともに説明される、本発明の範囲を限定することを意図するのではなく、むしろ単に本発明を明確にし、例証する。本発明のより完全な見解、及びその添付態様の多くは、同が、添付の図面に関連して検討されるとき、以下の発明を実施するための形態に対する参照によってよりよく理解されるようになると、容易に得られる。
【図面の簡単な説明】
【００１５】
【図１Ａ】電子請求書作成検証及び運転者追跡のために１つ以上のサーバと通信するシステム構成要素を示す概略図である。
【図１Ｂ】電子請求書作成検証及び運転者追跡のためのシステム構成要素をさらに示す概略図である。
【図２Ａ】サービスの提供において請求書作成要求調整を行うための例示的なワークフローを示すフローチャートである。
【図２Ｂ】ジオロケーションに関して請求書作成要求を調整するための手法を示すフローチャートである。
【図２Ｃ】時間に関して請求書作成要求を調整するための手法を示すフローチャートである。
【図３Ａ】受入可能範囲を規定し、更新するための手法を示すフローチャートである。
【図３Ｂ】特定の状況で仮受入可能範囲を規定するための手法を示すフローチャートである。
【図３Ｃ】仮受入可能範囲を更新するための手法を示すフローチャートである。
【図４Ａ】距離に基づいた受入可能範囲の適用を示す図である。
【図４Ｂ】距離に基づいた受入可能範囲の適用を示す図である。
【図５】バッファによって規定された受入可能範囲及びその中のジオロケーション座標を示す図である。
【図６】運転者が、距離に基づいた受入可能範囲の範囲内にいなくても、運転者が請求書作成要求の提出を試みる場合、運転者が運転者のコンピューティングデバイスで受け取る場合がある潜在的なメッセージを示す図である。
【図７】運転者が、１つ以上の受入可能範囲の中に到達できなかった１つ以上の理由についてユーザ関与パネル上で運転者が作成するであろう考えられる提出物のプレビューを示す図である。
【図８】時間に基づいた受入可能範囲の範囲内にいることができないことについて運転者が運転者のコンピューティングデバイス上で受け取る場合がある潜在的なメッセージを示す図である。
【図９】時間に基づいた受入可能範囲の範囲内にいることができないことの１つ以上の理由を入力するための運転者のコンピューティングデバイス上の潜在的なインタフェースを示す図である。
【図１０】ユーザ関与パネルの潜在的な表示を示す図である。
【図１１】距離に基づいた受入可能範囲に関係するデータベーステーブルを示し、データが、請求書作成検証システムの中でどのようにして収集され、ユーザ関与パネル又はサービスプロバイダモジュールのどこか他の箇所でサービスプロバイダに表示され得るのかを示す図である。
【図１２】サービスプロバイダモジュールでアクセスされてよい請求書作成要求について包括的な情報を示すユーザ関与パネルのインタフェースをさらに示す図である。
【図１３】時間に基づいた受入可能範囲に関係するデータベーステーブルを示す図である。
【図１４】データベースに記憶されるデータ、及びデータの編成がどのようにして実行されてよいのかを示す図である。
【図１５】地理情報システムによって実行される潜在的なジオプロセシングを示す概略図である。
【発明を実施するための形態】
【００１６】
図面に示される本発明の例示的な実施形態を説明する際に、分かりやすくするために特定の専門用語が利用される。しかしながら、本開示は、このようにして選択された特定の専門用語に限定されることを意図されず、特定の要素又は要素の組合せが同様に動作するすべての技術的な同等物を含むことが理解されるべきである。
【００１７】
加えて本明細書の例示的な実施形態が、タイムスタンプが押され、ジオロケーションスタンプが押された支払い要求を自動的に送信及び／又は提出するための車両ベースの請求書作成検証コンピューティングデバイスをサポートすることが当業者によって理解され得る。係るコンピューティングデバイスは、車両のジオロケーションを取得するためのジオロケーション識別子ユニット、現在のローカル時間及び日付情報を取得するためのクロック機構、又は指定されたピックアップ及び降車の時間及びジオロケーションを含んでよいサービス要求を受け取るための入力装置を含んでよい。処理ユニットは、車両の取得された実際のジオロケーション、実際の日付及び時間の情報、及びサービス要求についての潜在的な情報を含んだ支払いに対する請求書作成要求を自動的に生成してよい。移動無線又は他の通信手段は、生成された請求書作成要求を自動的に送信できる。
【００１８】
非緊急医療輸送（ＮＥＭＴ）領域を含むが、これに制限されるものではない、輸送領域では、少なくとも４つの関係者が関与している。概して、輸送サービス自体の提供に関与する関係者は、つまり本明細書で名前を付けられるように、「運転者」及び「乗客」である。概して輸送サービスのロジスティクスを調整することに関与する他の関係者がいる。本明細書では、それらの追加の関係者は、「ベンダ」及び「サービスプロバイダ」と呼ばれる場合がある。乗客は輸送サービスを要求するためにベンダと調整してよく、ベンダ又はベンダの代理人は、それを提供するためにサービスプロバイダと契約してよい。サービスプロバイダは、同様に、運転者と通信して、運転者に輸送サービスを割り当てる。基本的には、乗客は、指定場所情報（例えば、起点又はピックアップ、及び目的地又は降車）及び指定時間情報（例えば、指定ピックアップ時間及び指定降車時間）を提供することによって要求を行い、運転者を発送することができる。乗客が要求しているトリップが許可される場合、ベンダは、その情報でサービスプロバイダと連絡する。
【００１９】
ユーザは、特定の機能にアクセスできる前に、最初にシステムに登録してよい。ユーザが登録情報のために提出してよいことは、そのユーザの種類に依存する場合がある。例えば、乗客であるユーザは、名前、住所、ｅメール、ヘルスケア提供者情報、又は任意の他の関連情報等の連絡情報を提供してよい。運転者であるユーザは、例えば運転者の免許又は業務許可、保険情報等の関連性のある免許下付情報又は他の資格情報、及び業務履歴及び経験、車両の種類、話される言語等を含む場合があるプロファイル情報を提出する場合がある。関連する免許下付情報は、サービスプロバイダの営業所に応じて異なる場合がある。サービスプロバイダであるユーザは、他の登録情報とともに提供されてよい、発送免許又は他の関連する規制証明を有する場合がある。ベンダ又はその代理人であるユーザは、ベンダ又はその代理人が、ベンダの営業所についてだけではなくサービスについての支払いも支出できることを規定する登録情報、及びベンダが乗客の潜在的な保護医療情報を取り扱うだけではなく、このようにすることで法的に準拠している旨の検証を提出してよい。「登録情報」又は「登録データ」が、システムを使用する及び／又はそれが適用する法律に準拠するやり方でサービスを提供するユーザの正当性又は能力を規定する種々のユーザについての任意のありとあらゆる情報を合理的に包含してよいことが当業者によって理解され得る。
【００２０】
請求書作成要求は、サービスプロバイダに送られてよい。サービスプロバイダは、ベンダ又はその代理人に送信するために請求書作成要求のグループを収集してよい。ただし、いくつかの状況では、請求書作成要求がベンダに間接的に又は直接的に送られてもよいことが意図される場合がある。「間接的に」は、サービスプロバイダが最初に、請求書作成要求を検討し、受け入れ、次いでそれをベンダに提出することを意味する場合がある。「直接的に」は、請求書作成要求が直接的にベンダに提出されることを意味する場合がある。運転者がどのようにサービスプロバイダ又はベンダと連絡するのかは、請負契約又は作業合意書等において２つの関係者間で事前にかわされる合意に依存する場合がある。関係者間の特定の通信フレームワークが確立されなければならないことは、本発明の説明では意図されていない。
【００２１】
当業者は、これらの関係者が、本発明の例示的な実施形態での異なる用語が多数の状況を包含することを意図しているので、それらを使用することに参照される場合があることを理解し得る。例えば、用語「乗客」は、内科患者を指す場合がある。一方、それは法人口座を有する企業の従業員又は請負業者等に適用してもよい。用語「運転者」は、より広義に、例えばパイロット等、モータ付きの又はそれ以外の車両のオペレータを指す場合がある。「ベンダ」は、政府機関及び非政府機関、例えば私的機関、保険代理店、法人、非営利団体、株式非公開企業等の事業所、又は他の構造の事業所を包含する場合がある。用語「ベンダ」は、本明細書では、サービスの支払人であり、必ずしもサービスを受ける人ではないと理解される場合がある。ＮＭＥＴでは、ベンダはブローカー又は他のサードパーティである場合がある。用語「ベンダ」は、正確な検証された請求書作成に関心のある関係者を必然的に伴うべきである。請求書作成検証は、多数の他の業界で、特に、他の輸送サービス又はサービス認証に関係する業界で適用されてよい。例えば、正確な電子請求書作成検証は、企業又はプロバイダが、自分たちがサービスに対して支払う金が適切に使用されていることを確認する事に関心がある場合があり、彼らがかかるサービスに関する検証可能な情報を追求する場合がある、法人口座で、カーサービス、補助的交通機関、交通機関、又はブローカー、タクシー等で、役立つ場合がある。電子請求書作成検証システムが役に立つ業界が存在する場合があり、これは、ジオロケーションの使用及び時間調整、又は受入可能範囲が他のパラメータに関係する他の実施形態を少なくとも必要とする場合がある。
【００２２】
さらに、本明細書の「サービスプロバイダ」は、ベンダとインタフェースをとりながら、１人以上の運転者のサービスを調整することによってサービスを提供するエンティティを指す場合がある。それらのサービスプロバイダは、例えばＮＥＭＴサービスを提供することを専門に行うカーサービス企業等のカーサービス企業であってよい。サービスプロバイダは、運転者からの請求書作成要求を監視し、支払いのためにベンダに請求書を送るために請求書作成部門又は個別の請求書作成者を有してよい。最後に、「ユーザ」は、本明細書では、運転者、乗客、サービスプロバイダ若しくはサービスプロバイダと提携している人物、又はベンダ若しくはベンダと提携している人物に関してよい。「ユーザ」は、本明細書では、システムを使用する可能性がある関係者を指すことが意図される。
【００２３】
受入可能範囲に関係する場合がある異なる変数があり得ることが理解されるべきである。これらの変数は、類似性に基づいて異なるカテゴリにグループ化されてよい。１つのカテゴリは、サービス要求におけるピックアップのための１つ以上の受入可能範囲に当てはまる場合がある。これは、ピックアップ時間又はピックアップ場所、又は両方を含む場合がある。別のカテゴリは降車に当てはまる場合があり、降車カテゴリは、降車時間又は降車場所、又は両方を含む。変数は、さらに他の主題に関係し、第３のカテゴリ又は第４のカテゴリに関係するカテゴリがある場合があり、サービス要求に対する追加のレグ（ｌｅｇｓ）がある場合がある。係る場合、マルチレグ（ｍｕｌｔｉｌｅｇ）サービス要求は、ピックアップ時間、ピックアップ場所、降車時間、又は降車場所を含んだ変数の第３のカテゴリを含む場合がある。
【００２４】
受入可能範囲は、サービス要求で提供される少なくとも１つの場所に適用してよい。例えば、乗客の特に指定されたピックアップ場所のための１つの受入可能範囲がある場合がある。しかしながら、代わりに、受入可能範囲は、１つ以上の場所、又は１つ以上の一定の場所に適用する場合がある。異なる状況に基づいて、運転者がサービスに対して支払われる特定の場所に到達することを必要とされる場合がある特定の場所に適用する受入可能範囲がある場合がある。しかしながら、受入可能範囲は、例えば警察活動又は道路封鎖等のリアルタイム要因に基づいて、運転者がサービスを実行するためにそれらの一定の場所の中に又はそれらの一定の場所のひとつに到達することによって支払われてよい、１つ以上の一定の場所にさらに適用する場合がある。本質的に、受入可能範囲は、受入れ可能な場所である１つ以上の場所を含んでよい。さらに、これは、特定の時間、時間枠、又は請求書作成要求の承認のために受け入れることができる一定の回数がある場合がある、時間に基づいた受入可能範囲に適用してよい。
【００２５】
システムは、本明細書に使用される「場所」が、場所を説明するために緯度及び経度の座標を使用する場所フォーマットを説明する可能性があるジオロケーションに適用してよいことを認識するように構成されてよい。さらに、「場所」は、本明細書では、例えば実際の住所等の人間可読フォーマットを包含してもよい。ジオコーディングプロセスは、それが関連性があるこれらのフォーマットを変換するために使用されてよい。本説明は、受入可能範囲が、いつ又はどこで係るサービスに対するサービス要求又は請求書作成要求に関連性があるのかを限定することを意図していない。受入可能範囲が特定の状況で適用するかどうかは、所定の規則に基づいてよい。
【００２６】
１つ以上のサービスは、モバイル機器のジオロケーション識別子及びクロックからジオロケーションデータ及び時間データを引き出すことを通じて、車両活動、したがって運転者活動についての情報を追跡する１つ以上のモジュールと通信するように構成されてよい。例えばＧＰＳ受信機等のジオロケーション識別子は、運転者によって操作される車両内に配置されてよく、１つ以上のサーバを有する無線ネットワークを通してジオロケーション追跡処理のための手段と通信してよい。結果として、１つ以上のサーバは、実際のジオロケーション及び実際の時間―サービス要求が、どこで及びいつ開始し、終了したのか―のための入力を受け取ってよい。ジオロケーション及び時間データが送信されると、１つ以上のサーバが、指定された時間を実際の時間にだけではなく、「指定された」ジオロケーションを「実際の」ジオロケーションに比較することもでき、これが、運転者が１つ以上の受入可能範囲の中にいるかどうかを規定する。本明細書では、「指定された」は、サービス要求で受け取られる入力（例えば、トリップの意図された目的地として入力された場所）を指す場合がある。対照的に、「実際の」は、モジュール又は他の有効にされた装置を通して追跡される入力（例えば、降車が行われたとして示される場合がある場所）を示す場合がある。１つ以上のサーバは、運転者モジュールから受け取られた実際のデータを、指定された情報に比較してよく、実際のジオロケーション又は実際の時間は、それらが食い違いを特色とするが、請求書作成要求プロセスの間、依然として受入可能範囲内に含まれる場合に自動的に調整される。その情報及び比較は、次いで提供されると仮定された輸送サービスが実際に提供されたのかどうかを、運転者と確認するために使用されてよく、これにより運転者は相応して支払われることができる（又は、したがって、請求を拒絶するかどうかが判断できる）。運転者は、次いで確認されたトリップに基づいて支払われてよい。
【００２７】
運転者が、受入可能範囲の範囲内にいるかどうか、したがって運転者がユーザ関与パネルで１つ以上の理由を提出するように促されるかどうかの判断は、運転者、車両、又は運転者モジュールから取り出される情報だけに基づくわけではない場合がある。実際には、この判断は、乗客又は乗客モジュールから収集されるデータからであってもよく、乗客のジオロケーション及び署名又は指紋等の検証情報が追跡される。関連性のある検証情報は、実際のジオロケーション又は実際の時間とともに検討されてよく、実際のジオロケーション又は実際の時間は、次いで関連性のある指定されたジオロケーション及び関連性のある指定された時間に比較されてよい。他の例示的な実施形態では、運転者が受入可能範囲の範囲内にいるという判断は、運転者からの追跡情報、乗客からの追跡情報、又は両方からの追跡情報に基づく場合がある。
【００２８】
請求書作成要求情報に基づいて、言及されたように、自動調整が発行される場合がある。１つ以上のサーバは、請求書作成関連データが受け取られると、又は請求書作成要求が有効であると判断されると、請求書作成関連データをフォーマットしてよい。
【００２９】
本発明の例示的な実施形態は、運転者のジオロケーションを追跡し、ピックアップ又は降車の時間にタイムスタンプを入手して、係るピックアップ及び降車の場所及びタイミングが受入可能範囲の範囲内にあることを確認することによって、時間枠（複数可）及び／又は距離（複数可）及び／又は場所（複数可）についての所定の規則に基づいて、これらの受入可能範囲に基づいた調整の誠実な性質を確認するための種々のシステム及び方法を提供する。受入可能範囲は、次いでさらに、連続的なデータ収集に基づいて所定の規則に適用される場合がある、所定の規則に対する動的な更新によってより正確にされる。
【００３０】
１つ以上のサーバは、ピックアップ及び／又は降車に関係するジオロケーション及び／又は時間に対する調整を行ってよい。異なる状況に基づいて行われる異なる種類の調整がある場合がある。「調整」は、複数の入力が記録される場合に、システムが特定の入力を選択し、別の入力の代わりにそれを表示するようにプログラムされ得ることを意味する場合がある。例えば、特定の所定の規則が（例えば受入可能範囲に関して）満たされる場合、システムは、指定されたジオロケーション入力を選択し、実際のジオロケーション入力の代わりにそれを表示するであろう。また、調整は、ある入力を別入力で置き換えることを意味する場合もある。自動的に行われる場合がある種類の調整がある場合がある。本明細書では、「自動調整」は、運転者が受入可能範囲の中にいることに応えて、請求書作成要求が１つ以上のサーバによって受け取られると調整が行われるときに参照される場合がある。これは、運転者が、ユーザ関与パネル上で情報を提出する必要がないときに起こる調整である。調整は距離及び時間に関する場合があり、受入可能範囲に適用される規則は、任意の妥当な距離又は時間を反映するようにあらかじめ決められてよい。さらに、請求書作成要求に行われる「調整」が、請求書作成要求を後に再調整できないことを必ずしも意味しないことが、本明細書で理解されるべきである。調整されるジオロケーションは、調整された形で記憶されるだけではなく、その当初の形でもデータベースの中に記録され、記憶されてよい。同じことは時間にも当てはまる。適格の時間が調整されてよいが、元の入力も記録されてよい。
【００３１】
さらに、受入可能範囲は、場所対場所に基づいて異なるパラメータを有してよい。より高い建物に起因する信号途絶又は他の技術的な制限がある場合があるため、例えば、受入可能範囲のパラメータは、より小さい都市においてよりも、例えばマンハッタン等の人口密度が高い都会の環境のより大きい区域を必要とする場合がある。局所的且つ近傍のＷｉ−Ｆｉ接続は、特にＧＰＳ信号が不十分又は十分に正確ではない可能性がある場合に、ジオロケーションを識別するのを助けるために活用されてよい。さらに、交通状態がより小さい都市よりもはるかにより予測不可能である場合があるので、例えばロサンジェルス等の交通渋滞で知られている都市は、時間のためのより大きい受入可能範囲を規定させる場合がある。
【００３２】
用語「システム」は、本明細書で、１つ以上のモジュール上で又はコンピューティングデバイス上で動作するハードウェア及びソフトウェアの組合せを通した電子請求書作成検証システムの実施態様を指す場合があり、１つ以上のサーバ上に配備されてよい。システムは、通信フレームワーク又はネットワークの中の１つ以上のサーバ、データベース、モバイルエンドアプリケーション、ウェブポータル、ネットワーク設定等を含むが、これに限定されるものではない構成要素と結合され、統合された種々の事前にプログラムされた特長を含んでよい。これらの構成要素のサポートにより、例えばウェブサイト又はモバイルアプリケーション等の、特定のモジュールでアクセスできるアプリケーションインタフェースを通したサービスが実現できる。モジュールは、サービスプロバイダモジュール、運転者モバイル、ベンダモジュール、及び乗客モジュールを含んでよい。システムは、概して無線広域ネットワーク（ＷＡＮ）（例えば、インターネット）に対する１つ以上の接続を有する、携帯コンピューティングデバイス及びコンピュータ等のコンピューティングデバイスで動作する、ハードウェア及びソフトウェアの組合せを通して実装されてよい。システムは、通信手段を通してサービスを調整するネットワークサービスと通信するように構成されてよい。
【００３３】
概して、本明細書に説明されるプロセス及び方法は、１つ以上のコンピューティングデバイスを使用し、それらのコンピューティングデバイスは、ソフトウェア又は他の命令手段を通して命令を与えられてよい。それらのコンピューティングデバイスは、種々の例に関して以下の図の説明から説明されてよい。ただし、当業者は、他の例示的な実施形態で潜在的に使用される異なるコンピューティングデバイスを理解してもよい。
【００３４】
本発明の例示的な実施形態のハードウェアにより実行される処置は、コンピュータ実行可能命令を通してプログラムで行われてよい。命令は、１つ以上のサーバ上に、他のハードウェア又はシステム器具に、又は他の箇所に記憶されてよい。処置は、コンピューティングデバイス上で実行される前に満たされる特定の条件を検出する場合があるルーチン又は命令であってよく、それらは自動である可能性もあれば、自動ではない可能性もある。また、それらのルーチンは、係るルーチンの目標によって必要とされるサブルーチンを含んでもよく、それらは、ハードウェアデバイス、ソフトウェア構成要素、又は両方で実行されてよい。
【００３５】
本発明の例示的な実施形態に係るソフトウェアのアーキテクチャは、最適化の管理容易性及び保守、性能、データのセキュリティ等を提供しつつも、ユーザビリティ及び機能性の観点から技術要件及び操作要件のすべてを満たすためにソフトウェア構造を定義する。したがって、アーキテクチャは、例えばデータストレージ及びアクセスだけではなく、運転者、乗客、ベンダ、及びサービスプロバイダ向けのユーザインタフェース（ＵＩ）等の特定の態様に機能性も提供するという目標を追跡するように構成される。それらの構造及びその設計は、多岐にわたる要因に応じて変わり、システムアプリケーションの質、性能、保全性、及び全体的なユーザビリティに影響を与える場合がある。
【００３６】
構造上の要素は、各モジュールと関連付けられたアプリケーションインタフェース、及び別々のアプリケーション及び他の構成要素の間の協調によって定義されてよい。これらの構造上の要素は、それぞれの機能に基づいて全体的なシステムのサブシステムにグループ化されてよく、例示的な本実施形態に係るソフトウェア及びソフトウェアアーキテクチャは、異なる状況に従って対応してよい。各ユーザは、そのユーザの役割及びそのユーザのニーズに応じて、システムの異なる機能性を提供されてよい。
【００３７】
当業者は、クライアントフェイシングのシステム又はサブシステムが、運転者、ベンダ、サービスプロバイダ、又は乗客がそれによってサービス要求を提供又は調整するために必要な機能性にアクセスし得るモジュールを含んでよいことを理解するであろう。これらのインタフェースは、異なる特長に重点をおいてプログラムされ得るので、これらのインタフェースは、組織において互いと異なる場合がある。当業者は、異なるアプリケーションインタフェース特長及び／又はモジュール機能性を根本的に要求する場合がある、サービスプロバイダ又はベンダによって満たされる役割に比較した、運転者によって満たされる役割の相違を理解するであろう。要求される機能性は、例えばスマートホン、スマートウォッチ、又は他のモバイル機器及びその関連特長等のハードウェアで実行されるソフトウェアを通してプログラムで提供されてよい。
【００３８】
いくつかの例示的な実施形態では、コンピュータは、複数のプログラム又はスレッドを含んだコンピュータプログラム命令の実行を可能にする。複数のプログラム又はスレッドは、１つ以上のサーバの活用を強化し、実質的に同時の機能を容易にするために実質的に同時に処理されてよい。実施態様として、本明細書に説明されるありとあらゆる方法、プログラムコード、プログラム命令等は、１つ以上のスレッドで実装されてよい。１つ以上のスレッドは、それら自体がそれらと関連付けられた割り当てられた優先順位を有する他のスレッドをスポーンしてよい。コンピュータは、優先順位に基づいて、又はプログラムコードで提供される命令に基づいた任意の他の順序でこれらのスレッドを処理できる。コンピュータプログラム命令が、コンピュータ実行可能コードを含んでよいことは当業者によって理解されるべきである。Ｃ、Ｃ＋＋、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｐｙｔｈｏｎ、アセンブリ言語、Ｌｉｓｐ等を含むが、これに限定されるものではない、コンピュータプログラム命令を表すためのいろいろな言語が考えられる。
【００３９】
特定の論理関数は、解決されなければならない技術的な課題にきわめて特有の、適合したサービスを提供するために実装されてよく、例えばブール論理関数等の特定のｉｆ−ｔｈｅｎ状況を実行するためにはなはだしく複雑である場合がある。例えば、受入可能範囲のための特定のパラメータを識別する論理規則が実行されるために規定されてよい。多くの複雑な条件は説明され得るのは、このようにしてである。複雑な条件に対応する種々の言語特長は、例えばＪａｖａ等のプログラミング言語を通してプログラムされ、実装される場合がある。係る言語は、アセンブリ言語、ハードウェア記述言語、データベースプログラミング言語、関数型プログラミング言語、命令型プログラミング言語等を含んでよい。いくつかの例示的な実施形態では、コンピュータプログラム命令は、コンピュータ、プログラム可能データプロセッサ、又はプロセッサ若しくはプロセッサアーキテクチャの異種組合せ等で実行するために記憶、コンパイル、又は解釈される場合がある。
【００４０】
本明細書に説明される本発明の例示的な実施形態は、従来のコンピュータプログラムを伴うアプリケーション、又はそれらを実行するプログラム可能装置に限定されない。それは、例えば量子コンピュータ、アナログコンピュータ等の他の種類のコンピューティングデバイスのために意図される。
【００４１】
フローチャート図の各要素は、コンピュータ実装方法のステップ又はステップのグループを示してよい。さらに、各ステップは、１つ以上のサブステップを含んでよい。図示のために、（識別され、説明されたありとあらゆる他のステップだけではなく）これらのステップも順序正しく提示される。例示的な実施形態が、本明細書に開示される技術の特定の応用例に適応されたステップの代替順序を含んでよいことが理解され得る。すべての係る変形形態及び変更形態は、本開示の範囲内に入ることが意図される。任意の特定の順序でのステップの図示及び説明は、特定の応用例によって必要とされない、明記されない、又はそれ以外の場合文脈から明らかではない限り、異なる順序でステップを有する例示的な実施形態を除外することを意図されていない。
【００４２】
図全体で示される要素は、要素間の論理的な境界を暗示する。しかしながら、ソフトウェア又はハードウェアの設計慣行によれば、示される要素及びその機能は、スタンドアロンソフトウェアモジュールとして、又は外部ルーチン、コード、サービス等若しくはこれらの組合せを利用するモジュールとして、モノリシックソフトウェア構造の部分として実装されてよい。すべての係る実装は、本開示の範囲内にある。
【００４３】
本発明のハードウェアが、その指定された部分に限定されないことが、当業者によって理解されるべきである。いくつかの例示的な実施形態では、追加の機能性が他の種類のハードウェアによって提供される場合もあれば、追加の機能性がまだ利用可能ではないハードウェアを通して将来より効率的に提供される場合もある。有形のハードウェア構成要素は、特殊化した配置で提供される。係る構成要素の配置が、例示的な実施形態に依存する場合があることが、当業者によって理解されるべきである。本明細書でのこれらの構成要素の説明は、システムの構成要素部分を１つの且つ唯一の配置に限定することを意図されていないことが当業者により理解されるべきである。
【００４４】
上記を鑑みて、ここで、ブロック図及びフローチャート図の要素が、ステップが自動的に実行されるか否かに関わりなく、指定された機能を実行するための手段の組合せ、指定された機能を実行するためのステップの組合せ、指定された機能を実行するためのプログラム命令手段等をサポートすることが理解される。
【００４５】
図１Ａは、本発明の例示的な実施形態に係る電子請求書作成検証及び運転者追跡のために１つ以上のサーバ１００と通信するシステム構成要素を示す概略図である。サーバ１００は、システムが団結して機能できるように、システムのそれぞれの別個の部分及び機能性とインタフェースをとってよい。サーバ１００は、ユーザが、ユーザにアクセスを、又は多数のユーザに同時システムアクセスを許可するために複雑な通信ネットワークを管理し、使用できるようにする。システムは、世界中のどこかに位置してよいデータセンタからのサポートを有する分散構造内にあってよい複数のサーバを有してよい。これらの実施態様は、通信でリンクされ、相互に運用してよく（ｃｒｏｓｓ  ｐｌａｔｆｏｒｍ）、これによりコンピューティングデバイスのドライバは、例えば電子地図表示、移動時間、ルート、価格設定情報、プロファイル、及び設定情報、ベンダ、乗客、サービスプロバイダ等の他の情報を表示するインジケータ等のサービス要求に関連性がある情報を提供されてよい。システムの特長は、方法ステップが、１つ以上のサーバ１００によって処理され、出力されるのを可能にするコンピューティングデバイスを通して実装できる。サーバ側アーキテクチャは、モジュールと、ストレージ及びいくつかの計算特長だけではなく、データ処理及び画像処理を提示することも可能にするバックエンドシステムとの間の通信を調整するように構成されたソフトウェアプログラムを通して実装されてよい。
【００４６】
サーバ１００は、地理情報システム（ＧＩＳ）１０２、さらに１つ以上の非一過性コンピュータ可読記憶媒体としてインスタンス化され得る非一過性コンピュータ可読記憶媒体１０１、及びデータベース１０３を配備してよい。データベース１０３及びそのシステム機能は、１つ以上のデータベースを通してさらにインスタンス化されてよい。サーバ１００は、システム機能性を提供するために、ＧＩＳ１０２及び非一過性コンピュータ可読記憶媒体１０１に接続してよい。データベース１０３は、データが、すべてのサービス要求及び請求書作成要求にとって有用な情報を得るために記憶、編成、及び解析されてよい、非一過性コンピュータ可読記憶媒体１０１の一部として実装されてよい。また、当業者は、サーバ１００が、例えば１つ以上、つまり中央演算処理装置（ＣＰＵ）、デジタルシグナルプロセッサ、特定用途向け集積回路等の一種の論理処理ユニットである場合がある、処理ユニット１２３を含んでよいことも理解してよい。これらは、システム機能性を実装するために、メモリコントローラ、周辺バス、及びローカルバスを有するメモリを含んだ、任意の既知のシステムバス構造を通して接続されてよい。
【００４７】
非一過性コンピュータ可読記憶媒体１０１は、コンピュータによって実行されている、例えばプログラムモジュール等のコンピュータ実行可能命令をさらに記憶してよい。ドライブ及び関連付けられたコンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、及びコンピュータシステムのための他のデータの不揮発性且つ非一過性のストレージを提供してよい。プログラムモジュールは、特定のタスクを実行する、又は特定のデータ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含んでよい。コンピュータプログラム及びデータは、任意の形式（例えば、ソースコード形式、コンピュータ実行可能形式、又は中間形式）で、恒久的に又は一時的にのどちらかで、例えば半導体記憶装置（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、若しくはフラッシュプログラマブルＲＡＭ）、磁気記憶装置（例えば、ディスケット若しくは固定ハードディスク）、光記憶装置（例えば、ＣＤ−ＲＯＭ若しくはＤＶＤ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、又は他の記憶装置等の有形記憶媒体で固定されてよい。
【００４８】
コンピュータプログラム及びデータは、アナログ技術、デジタル技術、光技術、無線技術、ネットワーキング技術、及びインターネットワーキング技術を含むが、まったくこれに限定されるものではない、種々の通信技術のいずれかを使用し、コンピュータに送信可能である信号で任意の形式で固定されてよい。コンピュータプログラム及びデータは、取外し可能な記憶媒体磁気テープ）のような任意の形式で分散され、（例えば、システムＲＯＭ又は固定ディスク上で）コンピュータシステムをプリインストールされ、又は通信システムを介してサーバ若しくは電子掲示板から分散されてよい。ソフトウェア構成要素のいずれかが、所望される場合、ＲＯＭ（読出し専用）形式で実装され得ることが理解される。ソフトウェア構成要素は、概してハードウェアで実装されてよい。
【００４９】
サーバ１００は、サービスプロバイダモジュール１０４、運転者モジュール１０５（例えば、モバイル機器で実装されるアプリケーション及び特長）、並びにベンダモジュール１０６に接続してよく、その追加の詳細は図１Ｂに示される。接続は、例えばコンピュータネットワーク１１６を通るリンク等の通信手段を通じてよく、情報は、モジュールと関連付けられた１つ以上のコンピューティングデバイスのディスプレイに出力されてよい。システムの通信手段は、１つ以上のネットワークを介して、又はシステムに接続された１つ以上の周辺装置にデータを通信するための任意の手段であってよい。適切な通信手段は、無線接続、有線接続、セルラー接続、データポート接続、ブルートゥース接続、又はその任意の組合せを提供するための回路網及び制御接続を含んでよいが、これに限定されるものではない。本発明の例示的な実施形態と活用されてよい多数の通信手段がある場合がある。
【００５０】
ユーザモジュールは、異なるように構成されてよく、各ユーザモジュールは、特定の機能を実行するために異なるコンピューティングデバイス構成部分に頼る場合がある。現代では多くの異なる形式で―タブレット、スマートホン、例えばスマートウォッチ等のウェアラブル技術、ラップトップ、ＰＣ、又はサーバでもある場合があるコンピューティングデバイスの中の異なる構成要素は、情報を共有するために、相互作用し、通信する。システムを使用するユーザは、アプリケーションを通して部分的にそのコンピューティングデバイス上で潜在的に実行される、モジュールを通してシステムと相互作用してよい。システムは、クロスプラットフォームであってよく、それは、必要な場合、同時に、例えばウェブポータル及び／又はモバイルアプリケーション等の異なる手段を通じてアクセスされてよい。例えば、スマートホン、ジオロケーション識別子１１１、及びカメラ１１２等の少なくとも運転者コンピューティングデバイス１１０を使用してよい、運転者モジュール１０５。システムの管理は、運転者、ベンダ、サービスプロバイダ、及び乗客によって使用されるモジュールとは異なる別のモジュールを通じて種々の管理機能にアクセスしてよい。システム管理者が、当業者にとって明らかであってよい重要な管理機能を提供又は実行してよく、そうするためにモジュールを必要とする場合があることが意図される。
【００５１】
図１Ｂは、本発明の例示的な実施形態に係る電子請求書作成検証及び運転者追跡のためのシステム構成要素をさらに示す概略図である。サービスプロバイダモジュール１０４は、例えばデスクトップコンピュータ等のサービスプロバイダコンピューティングデバイス１０８上で実行中のソフトウェアであってよいサービスプロバイダアプリケーション１０７を含んでよい。サービスプロバイダ（例えば、サービスプロバイダに雇用される、又はサービスプロバイダと提携している請求書作成者等の人間のユーザ）は、サービスプロバイダモジュール１０４を通してシステムにコマンド及び情報を入力することができ、サービスプロバイダコンピューティングデバイス１０８は、デスクトップコンピュータ若しくはタッチスクリーンデバイスである可能性もあれば、キーボード及び／又はマウス若しくは他の入力装置を含む可能性もある。他の入力装置は、マイク、タブレット、スマートホン、又は他のモバイル機器を含む場合がある。追加の機能性は、スキャナ等を通して提供されてよい。これらの及び他の入力装置は、インタフェースを通して１つ以上のサーバに接続される。サービスプロバイダアプリケーション１０７は、例えばデスクトップアプリ、Ａｎｄｒｏｉｄアプリ、ｉＯＳアプリ、Ｗｉｎｄｏｗｓ  Ｐｈｏｎｅアプリ等の異なるアプリの形をとってよく、例えばモバイル機器等のコンピューティングデバイスで実行してよい。また、アプリケーションは、関係するモニタツール及び／又は管理ツールで保守専門家によって保守されてもよく、関係する経験及び技能を有するエンジニアによって更新されてよい。また、サーバは、セキュリティ追加のためにサービスプロバイダモジュール１０４上でのバックアップを可能にしてもよい。サービスプロバイダモジュール１０４は、部分的に、サービスプロバイダが、サービスプロバイダウェブポータル１０９に接続できるようにし、該サービスプロバイダウェブポータル１０９では、例えば未決の請求書作成要求、サービス要求等の特定の請求書作成関係の情報が利用できるようにされてよい。サービスプロバイダは、自らのジョブ機能にとって一意である特長を与えられてよい。サービスプロバイダは、サービスに関して包括的な情報を有するために運転者よりもはるかに多くの情報を提供されてよい。例えば、サービス要求のために提供される情報は、行われる任意の認証のために、利用可能な車両情報、運転者及び車両の現在の及び将来の計画場所、それらの車両の方向等を含んでよい。
【００５２】
運転者モジュール１０５は、運転者コンピューティングデバイス１１０上で実行されてよい運転者アプリケーション１１７を含んでよい。運転者モジュール１０５は、例えばジオロケーション識別子１１１（例えば、ＧＰＳ受信機）等の追跡構成要素が、運転者のジオロケーションを識別することを可能にし、ジオロケーション識別子１１１は、モバイル機器の中に内蔵される場合もあれば、ジオロケーション識別子１１１は、特別にプログラムされた請求書作成検証装置の一部である場合もある。他の例示的な実施形態では、ジオロケーション識別子１１１は、運転者によって操作される車両に取り付けられてもよく、ジオロケーションの追跡及び／又は処理のための手段を有するサーバ１００と、ネットワーク１１６を通して通信してよい。また、運転者モジュール１０５は、写真を撮影するためにカメラ１１２、及びタイムスタンプを得るためにクロック機構１１３を使用してもよい。これらは、例えばスマートホンに内蔵される等、運転者コンピューティングデバイス１１０の部分である場合もあれば、それらは入力装置又は追加の特別にプログラムされた請求書作成検証装置により提供される潜在的な機能性である場合もある。カメラ１１２は、運転者が特定の場所（例えば、降車場所）の写真を撮影できるようにし、その写真は、既知の場所画像と相互参照するために画像認識技術を使用し、画像処理されてよい。例えば、約束のために医師の事務所に到着する患者／乗客は、システムによって認識され得る医師の事務所の中への入口の写真を撮影できる場合がある。システムは、同じ建物入口の記憶画像又はビデオ録画を有する場合があり、その提供された写真は、認証を提供するためにさらに調べることができる。それらの画像又はビデオ録画は、そのコンテンツについて問い合わせを行われる場合があるデータベース１０３の中に記憶されてよい。さらに、それらの画像は、認証のために取り出されてもよい正しい住所に対応する街路画像を特徴付ける、例えばＧｏｏｇｌｅ、つまりＡｌｐｈａｂｅｔ  Ｉｎｃ．の子会社により提供されるマッピング及びターンバイターン指示アプリケーションであるＧＯＯＧＬＥ  ＭＡＰＳのＡＰＩ等のＡＰＩを通して提供されてよい。この機能性は、運転者モジュール１０５が、サーバ１００との通信問題又はそれ以外の場合安定した接続を維持する問題を有する場合に役立つ場合がある。係る場合、これは、接続ネットワークにおける特定の技術的な欠陥を補償するための方法を提供してよい。
【００５３】
運転者アプリケーション１１７は、さらに運転者のウェブポータルあるいはデータ入力及び／又はシステムアクセスの他の手段へのアクセスを可能にしてよい。これは、運転者が、請求書作成要求を提出するためであってよく、該請求書作成要求はサービスプロバイダに移動する場合もあれば、間接的に又は直接的にベンダに移動する場合もある。間接的には、サービスプロバイダが最初に請求書作成要求を検討し、受け入れ、次いで請求書作成要求をベンダに提出することを意味する場合がある。直接的には、請求書作成要求が直接的にベンダに提出されることを意味する場合がある。さらに、運転者は、運転者モジュール１０５を通して潜在的なジョブを提供されてもよく、問い合わせは、トリップの出発のために一時的に表示される場合がある。また、運転者アプリケーション１１７は、モジュールの中の他の独立した装置、又は外部でサーバ１００との特定の通信機能性を可能にしてもよい。サーバ１００又はユーザ関与パネル１１５を通して、運転者はウェブポータル又はサービスプロバイダと相互作用してよく、運転者が、事例の検討、要請、又は他の状況の場合にサービスプロバイダに連絡をできることが重要である。
【００５４】
さらに、乗客がトリップのために署名できない場合、システムは、運転者が、例えば指紋、音声確認、又は運転者モジュール１０５上での乗客からの検証情報等、サービス要求を確認又は検証するための情報を収集するのに頼る場合がある。これは、例えば乗客が自分のモジュールを忘れた、モジュールを家に置いてきた、技術的な困難等の場合であってよい。これは、運転者モジュール１０５が含む場合がある異なる機能性の包括的なリストではなく、それはこのようなものとなることも意図されていない。
【００５５】
ベンダ（例えば、支払い関係者）は、システムにアクセスするためにサーバ１００と通信するベンダモジュール１０６を使用してよい。ベンダモジュール１０６は、ベンダアプリケーション１１８を含んでよい。また、ベンダモジュール１０６は、ベンダアプリケーション１１８を実装するためにベンダコンピューティングデバイス１１４を統合してもよい。ただし、当業者は、ベンダアプリケーション１１８が、サービスプロバイダアプリケーション１０７又は運転者アプリケーション１１７とは異なるようにプログラムされる場合があることを認識してよい。さらに、企業である場合があるベンダは、内部コンピューティングネットワークを使用する場合があり、ベンダアプリケーション１１８は、係るネットワーク上及び１つ以上のベンダコンピューティングデバイス１１４で実行するように設計されてよい。また、ベンダコンピューティングデバイス１１４は、ベンダウェブポータル１１９を通してベンダモジュール１０６へのベンダアクセスを与えてもよい。ベンダモジュール１０６は、サーバ１００又は処理ユニット１２３で受け取られるサービス要求を送信するように構成されてよい。このサービス要求は、次いでサービスプロバイダモジュール１０４又は運転者モジュール１０５に送信されてよい。
【００５６】
乗客は、特定のシステム機能性にアクセスするために乗客モジュール１２０を使用してよい。乗客コンピューティングデバイス１２２で実行される乗客アプリケーション１２１がある場合がある。また、乗客モジュール１２０は、とりわけジオロケーション識別子１１１、カメラ１１２、及びクロック機構１１３を含んでもよい。いくつかの機能性は、乗客によって私たちのために乗客モジュールを提供することによって達成されてよく、乗客が関連性のあるベンダ又は他の関係者と連絡できるようにしつつ、１つ以上のサーバと通信してよい。乗客モジュールは、乗客が、例えばスマートホン、スマートウォッチ、タブレット、又は例えばラップトップ若しくはＰＣ等の他のコンピューティングデバイス等のモバイル機器の機能性を使用できるようにするためのクロスプラットフォームであってよいアプリケーションを含んでよい。また、アプリケーションは、乗客モジュール１２０にアクセスするための手段を乗客に提供してもよく、乗客は、以前のルート情報、プロファイル情報、医療情報等にアクセスしてよい。
【００５７】
サービスプロバイダモジュール１０４、運転者モジュール１０５、ベンダモジュール１０６、及び乗客モジュール１２０は、（例えば、特定のアプリケーション又はジオロケーション識別子１１１、カメラ１１２、クロック機構１１３等の要素等の）類似した要素を含んでよいが、これらの要素が各モジュールの中で完全に同じように実装される必要はないことが理解されるべきである。ジオロケーション識別子１１１及びクロック機構１１３は、それぞれ、サービスプロバイダモジュール１０４、ベンダモジュール１０６、乗客モジュール１２０、又は運転者モジュール１０５上でのそのシステム活動についてタイムスタンプを得ることに加えて、システム活動の場所を確かめるために使用され得る。これは、いくつかの場合に、特にモバイルコンピューティングデバイスで使用されている場合に、潜在的な監査において又はセキュリティ手段として役立つ場合がある。
【００５８】
また、サーバ１００は、ネットワーク１１６を通してユーザ関与パネル１１５に接続する１つ以上のモジュールを通してユーザによってアクセスされてよい、ユーザ関与パネル１１５にアクセスを提供してもよい。ユーザ関与パネル１１５は、ユーザインタフェース（ＵＩ）要素であってよい。サーバ１００は、データベース１０３又は１つ以上のデータベースにアクセスし、ユーザ関与パネル１１５上にデータベースの中で関連性のあるデータを表示してよい。サーバ１００は、特定のサービス要求又は請求書作成要求に関してすべての情報にアクセスし、それを表示してよい。ユーザ関与パネル１１５は、オンラインフォーラム、メッセージボード、又は関連性のあるトピックのオンラインディスカッションを可能にする他の種類のウェブサイト等の手段を通して提供されてよい。ユーザ関与パネル１１５は、ウェブブラウザ上でアクセスされる場合もあれば、ユーザのアプリケーションの一部として又は１つ以上のコンピューティングデバイスで実行できる専用のアプリケーションとして提供される場合もある。ユーザ関与パネル１１５上のデータは、誰がそれを見ている場合があるのかに応じて、個人情報のために潜在的に編集される場合があるが、ユーザ関与パネル１１５上のデータは通常アクセスされてよい。他の例では、ユーザ関与パネル１１５上のデータは、例えば情報が関係するユーザ等の特定のユーザに全体で提示されてよい。
【００５９】
運転者は、運転者モジュール１０５を通してユーザ関与パネル１１５にアクセスしてよく、運転者は写真をアップロードし、自分が受入可能範囲の中にいなかった理由等を提出してよい。ユーザ関与パネル１１５では、運転者がアップロードした写真は表示されてよく、それらの写真は、ジオタグ情報を有するメタデータ、又は写真が撮影された時刻と関連付けられたタイムスタンプを含んでよい。
【００６０】
また、ユーザ関与パネル１１５は、サービスプロバイダモジュール１０４及びベンダモジュール１０６を通してアクセスされる場合もあり、ユーザは、検証のために情報にアクセスしてよい。ユーザ関与パネル１１５から、サービスプロバイダ又はベンダであってよい承認された請求書作成者が、事例の事実及び他の情報を検討してよく、請求書作成要求を検証するために、１人以上の運転者に連絡できる場合がある。
【００６１】
運転者は、関連性のあるユーザ関与パネル１１５上で請求書関連データを含んだ提出物を作成するように通知される場合がある。１人以上の運転者からのユーザ関与パネル１１５の提出物を通じて収集されるデータは、データベース１０３を動的に更新、補正、及び補足するために使用できる。請求書作成関連データが１つ以上のユーザ関与パネル１１５上で提出され、所定数の肯定的な評価を受ける、又は他の所定の規則に従って検証されるとき、請求書作成関連データは、データベース１０３を更新するためにリアルタイムで使用されてよい。同様に、データベース１０３に対する更新は、該当する場合、１つ以上の受入可能範囲に対する更新を生じさせる場合がある。このようにして、受入可能範囲も動的に更新され、相応してデータベース１０３に組み込まれる。図３Ｂ及び図３Ｃにさらに定義されるように、１つ以上のユーザ関与パネル提出物に基づいて、受入可能範囲が正確であるかどうか、及びそれがアクティブに保たれるべきかどうか、無効にされるべきかどうか、それともセミアクティブな受入可能範囲として組み込まれるべきであるかどうかが部分的に判断されてよい。請求書作成関連情報、ジオロケーション、又は時間の直接の経験を有する任意のユーザは、それがサービスプロバイダであるのか、運転者であるのか、ベンダであるのか、乗客であるのか、又はシステムの中に登録された別の個人であるのかに関わりなく、ユーザ関与パネル１１５のデータに貢献してよい。直接の経験は、少なくともジオロケーション追跡データによって判断されてよく、直接の経験は、関連性のある場所に物理的に近接するとして示されている又は示されていたユーザによって判断される。いくつかの例の関連性のある場所は、請求書作成要求中の疑問視される実際のジオロケーションである場合がある。近接は、一例では、場所から５０フィート未満として定義される場合もあれば、近接は、例えば３０フィート又は４０フィート等の所定の規則に基づいた異なる定義である場合もある。ユーザがジオロケーションデータに基づいた半径の範囲内にいる場合、ユーザは、直接の経験を有すると示され、したがってユーザ関与パネル上の情報を少なくとも評価する資格がある。近接判断は、半径に基づかない可能性がある。近接判断は、同じ街区又は通りにいることに基づく場合もあれば、地理上のフェンスに基づく場合もある。これらは、任意のときに前もって決められる又は規定される場合がある。クラウドソースによるデータ又は情報は、システムの他のユーザに概して利用可能にされる場合もあれば、されない場合もある。任意のクラウドソースによるデータ又は情報が、他のユーザに知らせることを通じて又は所定数の肯定的な評価を受け取ることによってのどちらかで役立つと識別される場合、次いでそれを提出したユーザに報酬が与えられる場合がある。これは、ユーザに、ユーザ関与パネル１１５を使用し、ユーザ関与パネル１１５で提出物を作成する動機を与える場合がある。システム特長が、図示されない他の道具に配置されてよい、又はこの概略図若しくは他の概略図によって定義されてよいことが当業者によって理解されるべきである。
【００６２】
ユーザ関与パネル１１５は、１つ以上の異なる方法で編成されてよい。１つ以上のユーザ関与パネルがある場合があり、あらゆる受入可能範囲が独自の対応するユーザ関与パネル１１５を有する。さらに、１つのユーザ関与パネル１１５は独自のデータストレージ手段を有してよく、１つ以上のデータベースが、１つ以上のサービス要求に関係する１つ以上の場所のすべての関連性のあるデータの対応する情報を記憶してよい。さらに、単一の受入可能範囲又は複数の受入可能範囲に一度に適用する１つ以上の小区分を有する中心ユーザ関与パネルがあってよい。
【００６３】
図２Ａは、サービスの提供において請求書作成要求の調整を行うための例示的なワークフローを示すフローチャートである。プロセスの第１のステップは、サービス要求に関係する指定された場所及び指定された時間を含む場合があるサービス要求情報を受け取ること（ステップ２００）である。また、これは、例えば個々のベンダが有する場合がある特定の受入可能範囲規定等のベンダ情報を含んでもよい。ＧＩＳ１０２又はサーバ１００は、住所としての場所入力を、例えば経度及び緯度の座標を含んだジオロケーションにジオコーディングすることを含んだジオプロセシングを実施してよい（ステップ２０１）。これは、例えばＧＯＯＧＬＥ  ＭＡＰＳ等のサードパーティのジオコーディングＡＰＩを使用し、達成されてよい。サービス要求で提出される情報に部分的に基づいて、サーバ１００は、次いでサービス要求で入力された値を使用し、動的に調整された所定の規則に基づく場合がある受入可能範囲を規定できる。ジオコーディングは、場所をジオロケーションに変換することによって、ジオロケーションのための受入可能範囲が規定される（ステップ２０２）のを部分的に可能にする。さらに、時間のための受入可能範囲は、部分的にはサービス要求入力に基づいて規定できる（ステップ２０３）。一方又は両方又は任意の他の関連性のある受入可能範囲が規定され、サービス要求が進行中になると、システムは、経時的に運転者の場所を追跡してよく、請求書作成関連データを受け取ってよく（ステップ２０４）、運転者モジュール１０５は、例えばＧＰＳ受信機等の機能性を通して運転者モジュール１０５の場所についてサーバ１００に請求書作成要求情報を送信する。請求書作成関連データは、事象（例えば、車両が一定の時間量停止すること、又は指定された場所の一定の距離範囲内に停止すること）の発生時、又は情報要求（例えば、サービスプロバイダ、ベンダ、又は車両に対するステータス更新を手動で要求する他のシステムモニタ）時に周期的に送信又はそれ以外の場合受信されてよい。
【００６４】
実際のピックアップジオロケーション及び時間、実際の降車ジオロケーション及び時間、及び例えば価格設定情報及びマイレージ情報等の他の関連性のある情報を含んだ、サービス要求情報及び請求書作成関連データに基づいて、次いで、運転者が、請求書作成要求の提出のために受入可能範囲の範囲内にいるかどうかが判断される（決定２０５）。これは、運転者モジュールが、請求書作成要求情報をサーバ１００に自動的に中継した後に発生する場合がある。追跡される情報が受入可能範囲の範囲内にある、又はサービス要求情報に一致する場合、次いで自動調整が行われてよい。つまり、請求書作成要求が承認される（ステップ２０６）。例えばどの値が変更されたのか及びそれらの変更がいつ行われたのか等の調整についての情報は、システムに記録されてよい。記録は、サービス要求及び請求書作成要求のためにこの情報及び他の類似する情報の完全な会計処理を含んでよい。運転者が受入可能範囲の範囲内にいない場合、次いでそれが発生した理由を調査しなければならない場合があり、その場合、サーバ１００は運転者に、運転者モジュール１０５を介して１つ以上のメッセージを通じて、運転者が受入可能範囲の外にいる場合があることを警告してよい。上述されたように、判断は、乗客から収集される情報に基づく場合があり、乗客から収集される情報は、運転者モジュール情報とともに使用されてよい、又は独自に使用されてよい。運転者が１つ以上の受入可能範囲の範囲内にない状況では、最終的には、一時的な又は恒久的な支払の取り消しにつながる場合がある条件付き拒絶又は最終的拒絶。この状況で、サービス要求が実行されたかどうかが、検証されてよい。このようにするために、サーバ１００は、条件付き拒絶と見なされる場合がある受入可能範囲の中に到達できないことが発生するとき、運転者にメッセージを送信してよい。このメッセージは、運転者に、受入可能範囲の中にいることができないことに対する１つ以上の理由及び写真（複数可）を提供するように促す場合がある（ステップ２０７）。これは、何が運転者を指定された時間に又は指定された場所に到達させなかったのかの説明、又は証拠として時間及びジオロケーションデータで補強された写真であってよい。
【００６５】
運転者は、次いでこの請求書作成関連データを、ユーザ関与パネル１１５を通して提出する（ステップ２０８）。検討のために、ユーザは、運転者によって提供される１つ以上の理由を含んだ請求書作成関連データを一読し、運転者の理由の筋が通っていたかを確認又は否定することを決定するであろう。これは、運転者の提出物を評価するプロセスの例であってよい。これらの理由は、１つ以上の他の運転者を含んだユーザによって調査されてよく、これによりどのような問題が発生したのか、及び、その問題が筋が通っていたのか、問題がうっかりミスである場合もあれば、潜在的に不正である場合もある、を判断することができる、又は判断することができない。さらに、いくつかの状況では、運転者は、署名又は例えば指紋等の他の確認を、サービス要求が試行され、指定された通りに完了できなかった乗客から収集してよく、運転者は写真を撮影し、状況の書面による説明（例えば、「パレードルートがあり、５番街がアクセスから封鎖され、６番街で乗客を降ろした」）とともに写真をアップロードしてよい。乗客の検証は、サービスの始めに、サービス中に、又はサービスの最後に行われてよい。これは、運転者モジュール１０５で、特殊目的装置で、又は乗客のために特に提供されるモジュールでも収集されてよい。
【００６６】
請求書作成関連データがユーザ関与パネル１１５で提出されるとき、直接の経験を有する１人以上の追加のユーザがそれを評価してよい。請求書作成関連データが、所定時間内に所定数の評価を受ける場合（決定２０９）、次いで調整（例えば、支払い）があってよく、評価がそれが正確であると証明したため、請求書作成要求は承認されてよい（ステップ２０６）。それらの評価は、肯定的な評価又は確認の評価、又は１つ以上の理由が筋が通った理由である旨の情報を伝達する任意の他の評価種類であってよい。評価はまた、否定的な評価であってもよい。情報が所定の時間内に所定数の評価に達しない場合（決定２０９）、最終的な拒絶（ステップ２１０）が発行されてよい。運転者が、請求が筋が通っていると考えない、又は所定の時間内に異論を唱えない（決定２１１）場合、最終的な拒絶が保持されてよい（ステップ２１２）。運転者が、自分の請求は筋が通っていると考え、所定の時間内にそれを示す場合（ステップ２１１）、次いでサービスプロバイダは事例検討を公開してよい。事例検討では、サービスプロバイダは、運転者が提出した理由、写真、又は他の情報を監視してよい。サービスプロバイダは、同じ情報、又はユーザ関与パネル１１５で提出されたものよりも多い詳細な情報を提供されてよい。サービスプロバイダ、又は本発明の特定の例示的な実施形態では、ベンダが、運転者の請求が筋が通っていると考えず、請求書作成要求を認める場合（決定２１３）、次いでサービスプロバイダは拒絶を最終に保持してよい（ステップ２１２）。運転者が正しい場所に到達できない多くの筋の通った理由がある場合があるので、サービスプロバイダが請求書作成要求を承認すると決定する場合（決定２１３）、請求書作成要求が承認されたため、次いで調整が行われる（ステップ２０６）。要因は、駐車制限、道路規則、建設現場、及び一時的な道路阻絶を含む場合がある。いくつかの場合、乗客が車両を降りることは単に安全ではない場合があり、運転者は、すぐ近くの場所に停止する方がより安全な場合があると評価する。また、特別な警備事象、パレード、大決起集会、又は抗議行動のための道路封鎖も正しい場所に到着することを実現困難又は不可能にする場合がある。これらすべては、運転者が、場所又は時間の食い違いを検証される場合がある潜在的な理由であってよい。
【００６７】
図２Ｂは、ジオロケーションに関して請求書作成要求を調整するステップが示される、本発明の例示的な実施形態に係る例示的なワークフローを示すフローチャートである。サーバ１００は、指定されたピックアップ場所及び降車場所（ステップ２１４）を含む場合がある場所入力、又はいくつかの例示的な実施形態では複数のピックアップ場所及び降車場所を受け取る。それらの場所は、次いでジオコード化され、入力場所はジオロケーションに変換される（ステップ２１５）。ジオロケーションは、データベース１０３からそのジオロケーションと関連付けられた所定の規則を取り出すために使用されてよい（ステップ２１６）（例えば、受入可能範囲のための所定の規則が取り出され、受入可能範囲が、指定されたジオロケーションから１２０フィート範囲内の区域に基づかなければならないと判断される）。
【００６８】
これらの所定の規則は、空間解析ソフトウェアを提供する、Ｅｒｓｉによって提供されるマッピングプラットフォームである、例えばＡｒｃＧＩＳ等のＧＩＳ１０２及び／又はサーバ１００が、受入可能範囲を作成できるようにする「バッファパラメータ」の次元を作成する。バッファは、所定の規則に基づいて受入れ可能として資格を得るすべての点を含む領域を規定することによって受入可能範囲を規定してよい。空間解析ソフトウェアを用いて、特定の属性を有する特定の座標が、バッファの中でともにグループ化されてよい。バッファは、ジオプロセシング中に入力されたサービス要求アドレスから変換された座標の中心的な集合に基づいてよい。バッファは、次いで、そのパラメータとして中心点から一定の距離範囲内にあるすべての座標を含むように構成される。ジオロケーションと関連付けられた座標は、すべて一定の基準を満たし、したがってその類似性に基づいてグループ化されてよい。
【００６９】
いったん受入可能範囲が規定されると、運転者モジュール１０５によって生成される請求書作成要求から入力される実際のジオロケーションは、サーバ１００によって受け取られてよい（ステップ２１８）。入力に基づいて、実際のジオロケーションが、受入可能範囲の範囲内にあり、したがって「資格要件を満たしたジオロケーション」であるかどうかを判断することができる（決定２１９）。そうである場合、ジオロケーションの自動調整が発行され（ステップ２２０）、指定された場所入力が、請求書作成要求を処理するために選択される。例えば、受入可能範囲の中心座標が、４０°４５’２３．２”Ｎ、７３°５８’３５．８”Ｗの指定されたジオロケーションに基づく、２００フィートのサイズを要求する所定の規則に基づいて規定された受入可能範囲。運転者が、指定された降車場所から１０５フィート離れている４０°４５’２３．６”Ｎ、７３°５８’３５．０”Ｗで乗客を降ろすならば、サーバ１００は、降車のための実際の入力よりもむしろ、４０°４５’２３．２”Ｎ、７３°５８’３５．８”Ｗである降車ジオロケーションのための指定された入力を自動的に選択してよい。他の例示的な実施形態では、受入可能範囲は、例えばＧＩＳ１０２等のプログラムされた「スナップ公差」に基づいてよく、場所は地図上のグループの中に「はめ込まれて」よい。ジオロケーションが受入可能範囲の範囲内にあるかどうかの判断は、座標ベースの解析に加えて、例えばフィート、メートル、又は他の測定等の２つの入力点間の距離を決定することによって行われてもよい。いくつかの例示的な実施形態では、ジオロケーションは、人間可読住所にジオコーディングで戻される場合がある（ステップ２２９）。
【００７０】
実際のジオロケーションが受入可能範囲内にない場合、ジオロケーションのための自動的な調整は発行されない（ステップ２２１）。ただし、システムは依然としてデータベース１０３に実際のジオロケーション入力を記録し、記憶してよい。ジオロケーション入力は、人間可読住所にジオプロセシングで戻されてよい（ステップ２２９）。したがって、実際のジオロケーションは、実際の場所にジオプロセシングで戻されてよい。
【００７１】
図２Ｃは、本発明の例示的な実施形態に係る例示的なワークフローを示すフローチャートであり、時間に関して請求書作成要求を調整するステップが示される。サービス要求がベンダ又は他の関連性のある関係者によって提出されると、指定されたピックアップ時間及び降車時間の入力が、サーバ１００によって受け取られる（ステップ２２２）。サービス要求に基づいて、データベース１０３から係る情報を取り出すことによって、時間に基づいた受入可能範囲のための所定の規則があるかどうかが判断されてよい（ステップ２２３）。これは、一意のＩＤ番号を参照することによって、又は関連性のある情報についてデータベース１０３に問い合わせを行うために使用できる別のサービス要求識別子によって実行されてよい。いったん指定されたピックアップ時間及び降車時間、並びにサービス要求のための時間に基づいた受入可能範囲に関する所定の規則が取り出されると、それらの所定の規則に基づいた受入可能範囲が規定されてよい（ステップ２２４）。
【００７２】
時間に基づいた受入可能範囲は、属性別に時間をグループ化させてよく、その場合、定義される属性は、所定の時間又は他の時間的束縛に基づく場合がある。次に、サービス要求を実行することができ、請求書作成要求の中の実際の時間入力は、運転者モジュール１０５から受け取ることができる（ステップ２２５）。受け取られた実際の時間に基づいて、運転者が時間のための受入可能範囲内にいるかどうかを判断できる（決定２２６）。指定された時間は、実際の時間に対する比較の点として使用される既知の時間値となり、規則は、時間ウィンドウの外部の任意の時間は資格要件を満たした時間とはならず、したがって拒絶されると決定してよい。規則は、例えば指定された時間から１０分以内である任意の時間入力等、何が資格要件を満たした時間であるのかを決定してよい。例えば、指定された時間は午前９時１５分であり、規則は、１０分以内の時間だけが資格要件を満たした時間であると決定し、次いでサーバ１００又は処理のための他の手段は、午前９時５分と午前９時２５分との間の任意の時間入力を受け入れてよい。他の例示的な実施形態では、時間のための受入可能範囲は、１０分後である受入可能範囲を同時に作成しつつ、資格要件を満たした時間を指定された時間の５分前にする規則によって作成されてよい。これは、この例示的な実施形態での資格要件を満たした時間が、午前９時１５分の指定時間の場合、午前９時１０分と午前９時２５分との間であってよいことを意味する場合がある。比較は、コンピューティングデバイスによって実行されるプログラミング言語を通して提供され、作成されてよい時間枠を作成する論理関数に基づいて行われてよい。時間入力が受入可能範囲内にある場合、時間入力のための自動調整が発行されてよく（ステップ２２７）、指定されたジオロケーション入力が、請求書作成要求を処理するために選択される。時間に関して請求書作成要求を調整することは、規則に従ってプログラムで行われる場合もあれば、それはサービスプロバイダによる検討の後にプログラムで又は手動で調整される場合もある。時間が資格要件を満たした時間ではない場合、時間のための自動調整は発行されない（ステップ２２８）。ただし、実際の時間入力は依然としてデータベース１０３に記録されてよい。
【００７３】
図２Ｂ及び図２Ｃが、それにより１つ以上の受入可能範囲が規定されてよいプロセスだけを規定する図よりもむしろ、図２Ａに言及される受入可能範囲を規定することに関してより具体的なステップを記述することが意図されるサブルーチンとしてインスタンス化されてよいことが理解されるべきである。受入可能範囲を定める所定の規則は、変化を受ける場合がある。受入可能範囲は、運転者が一定の速度に達すること、一定の速度を平均化すること、一定の総距離を移動すること、一定のルートに沿って移動すること、交通規則に従うこと、安全な車間距離を維持すること等に関してよい。また、所定の規則は、いくつかの例示的な実施形態では、人工知能（ＡＩ）によって解析されてよい、収集されたデータに基づいて変更される可能性もある。ＡＩは、受入可能範囲を特定の状態で変更させる場合があるパターンを決定してよい。例えば、天候状態は、運転者がいくつかの場所に到着する能力に影響を及ぼす場合もあれば、交通渋滞を増加させる場合もある。係る状況及びそれが関連性がある場合、ＡＩは、所定の規則に基づいて受入可能範囲を変更する場合がある。データ収集に基づいて受入可能範囲を変更する手法が、天候状態に限定されない多数の他の要因に適用され得ることが当業者によって理解されるべきである。さらに、距離に基づいた受入可能範囲は、一定の半径に基づく必要はない。別の例示的な実施形態では、距離に基づいた受入可能範囲は、変化する長さ、高さ、又は任意の他の寸法若しくはパラメータの複数の側面を有する地理上のフェンスで囲まれた（ｇｅｏ‐ｆｅｎｃｅｄ）領域であってよい。いくつかの例示的な実施形態では、これも受入可能範囲を更新することを通じて達成され得ることが当業者によって理解されるべきである。
【００７４】
しかしながら、請求書作成要求で支払われるために資格を得るために、運転者はすべての又は一定数の変数を満たす。例えば、支払いの資格を得るために、運転者は、要求される通りにサービスを提供する、又はそれ以外の場合、−自動調整を通じてであるのか、ユーザ関与パネルを通してであるのか、又は議論に対して行われる調整を通してであるのかに関わりなく−請求書作成要求の変数を調整してもらう。しかしながら、運転者がまだサービス要求を提供していても、１つ以上の変数に対して調整が行われない場合がある場合もある。例えば、運転者が指定ピックアップ場所とは異なる場所で乗客をピックアップした筋が通った理由がなかったが、正しい時間に正しい目的地に乗客を連れて行った場合。この場合、運転者が正しい場所でピックアップを行わなかったことの１つ以上の理由は、収集され、解析され得るが、サービス要求が依然として提供され、請求書作成要求が提出されているので、運転者は支払われる場合がある。サービスプロバイダ、１人以上の追加ユーザ、ベンダ、又はシステムの裁量で最善に実行され得る支払いを決定する上で多数の状況があるので、この支払いは、全額である、部分的である、又はまったくない場合がある。他の例示的な実施形態では、いくつかの状況で請求書作成要求に対する正しい額を運転者に支払うことは、裁量による判断に基づかない可能性がある。
【００７５】
運転者又は乗客が予想される通りに関与しなかった、又は一方の関係者が、例えば不在（例えば、姿を見せない）等、他方の場所を見つけることができない状況が発生する場合がある。運転者が現れない場合、次いでサービスは提供されず、生成される請求書作成要求がない可能性がある。乗客が現れない場合、乗客からの検証がない場合がある。また、運転者又は乗客が、サービス前に又はサービス中にサービス要求を取り消す状況もある場合がある。特定の検証要因が満たされると検証され得る係る状況に対するプログラムされた次善策がある場合がある。１つの係る検証要因は、ジオロケーション追跡及び時間情報、運転者が受入可能範囲内にいるかどうかの判断を含む場合があり、係る場合の受入可能範囲は、時間、ジオロケーション、又は時間及びジオロケーションに関する場合がある。例えば、検証要因要件を満たすことは、運転者が一定のジオロケーションに到達し、例えば１０分又は１５分等、一定の期間そこにとどまることを伴う場合がある。運転者が、駐車規則のためにその時間中に駐車スペースを見つけることができない場合、運転者はブロックを周回する又は別の近傍の場所で待機する場合があり、これは、適切な場合待機時間と見なされる場合がある。別の検証要因は、他方の関係者に連絡する努力に関する場合がある。乗客にとって、それは、関連性がある場合、ベンダ、サービスプロバイダ、又は運転者に連絡しようと１回以上試みることである場合がある。運転者にとって、それは関連性がある場合、乗客、ベンダ、又はサービスプロバイダに連絡しようと１回以上試みることである場合がある。運転者又は乗客が、他方の関係者が現れないことに関する情報を登録するために、モバイル機器に設けられるテキスト入力フィールドがある場合があり、これはユーザ関与パネル１１５を通じて提出される場合もあれば、請求書作成要求に含まれる場合もある。乗客が現れるが、遅れている場合、運転者が乗客を待機するために費やした追加時間に対する運転者への追加料金の支払いが検討され得るが、運転者がどこで及びどれほど長く待機したのかに基づく場合があり、運転者が、電話記録等に基づいて乗客に連絡しようと試みた場合、これは、関連性のあるユーザモジュール又は通信手段を使用し、システムの中に統合されてよい。
【００７６】
姿を表さない状況又は類似した種類の状況は、受入可能範囲に関係する可能性もあれば、関係しない可能性もある。しかしながら、乗客モジュール１２０、運転者モジュール１０５、サービスプロバイダモジュール１０４、又はベンダモジュール１０６は、例えばサービスプロバイダが一定の明確化する情報等を入力する等、発生する可能性がある多数の状況を説明するための機能を実装する場合がある。乗客が現れない場合も、運転者は手動で又は自動的に（運転者が乗客をピックアップする表示時に終了する可能性もあれば、終了しない可能性もある、例えば、到着時に開始するようにプログラムされたタイマの期限切れ時に）請求書作成要求を提出できる。運転者は、運転者が受入可能範囲内に到着しない場合、ユーザ関与パネル１１５を通して請求書作成要求を調整させてもよい。１つ以上の理由は、いくつかの状況では、乗客の検証がなくても検証され得る。乗客の検証情報を提供せず入力される請求書作成要求を処理するための手段が提供されてよく、それが承認されるのか、それとも拒絶されるのかは、所定の規則に基づく場合がある。
【００７７】
図３Ａは、受入可能範囲を規定し、更新するための手法を示すフローチャートである。受入可能範囲を規定する権限を有する関係者は、提供されたサービスに対する支払いを行う責任をもつ関係者であることに留意することが重要である。したがって、受入可能範囲は、本発明の例示的な実施形態では、一般的な規則として運転者又は乗客により規定されない可能性がある。サービスプロバイダもその権限を持たない可能性はあるが、いくつかの状況には、特にサービスの提供に適用するいくつかの特別な規則がある場合、サービスプロバイダが、ベンダ又は代理人と受入可能範囲の交渉に関与する場合がある。
【００７８】
受入可能範囲を規定する方法は、受入可能範囲がそのパラメータで異なる、さまざまな段階を含んでよい。少なくとも３つの「種類」の受入可能範囲があってよい。受入可能範囲は、最初に、ベンダの又は代理人の裁量又は常識に基づいて、つまり任意に、又はそれ以外の場合、入手できる場合履歴データに基づいて「予備」受入可能範囲として規定される場合がある。予備受入可能範囲は、デフォルトパラメータに基づいて規定されてよく（ステップ３００）、それらは、ベンダ、ベンダの代理人、又は別の関連性のある関係者によって事前に規定されてよい。デフォルトパラメータは、その性質により任意であってよく、輸送サービスがどのように提供されているのかに応じて更新されてよい。所定数のサービス要求（一定数の降車、ピックアップ、又はそれらの組合せ等）が記録されてよい、データ収集（ステップ３０１）があってよい。この段階では、ユーザ関与パネルは、予備受入可能範囲をより正確な恒久受入可能範囲に最終的に変換する上で役立つ可能性がある情報又はデータを収集するために使用されてよい。データ収集は、より正確な恒久受入可能範囲を規定するのに役立つ場合があり、収集プロセスは、必要に応じて任意の時間、起こる場合がある。収集されたデータは、データベース１０３に記憶されてよい。しかしながら、本明細書での「恒久」は、それが受入可能範囲に適用し得るとき、恒久受入可能範囲が変更できない、又は変更されないことを示さない。むしろ、本明細書では、用語「恒久」は、恒久受入可能範囲が、長期にわたって適用可能となる場合がある受入可能範囲と見なされ得ることを反映するために使用される。恒久受入可能範囲が、収集されたデータに基づいて変更される、又は例えば恒久的な通りの封鎖若しくは駐車規則若しくは規制の変化等、リセットされる状況があり得る。
【００７９】
実際のピックアップ場所及び降車場所を含むが、これに限定されるものではない請求書作成関連データは、連続的に収集されてよい。同じ種類の筋の通った理由により裏付けられる調整された請求書作成要求の数が所定数に達する場合、予備受入可能範囲が無効にされ、恒久受入可能範囲に変換される。概して、データ収集が、運転者が予備受入可能範囲外に繰り返し達することを示す場合、予備受入可能範囲は無効にされ、収集された関連性のあるデータに基づいて、より大きい恒久受入可能範囲に変換される。他方、データ収集が、運転者が、予備受入可能範囲により規定される最大値よりも、指定場所により近く繰り返し到達することを示す場合、予備受入可能範囲は、変換され、無効にされ、より小さい恒久受入可能範囲に変換される。データ収集中に集められたデータに基づいて、恒久受入可能範囲は、データ収集段階で収集されたデータに基づき規定され（ステップ３０２）、実際のサービスの提供において運転者がいつ又はどこで降車又はピックアップを行っている場合があるのかのより正確な反映となる。しかし、現実の状況はそれらのサービスの提供に影響を及ぼすので、受入可能範囲は更新される必要がある。
【００８０】
請求書作成要求は受け取られ（ステップ３０３）、請求書作成要求に基づいて、運転者が恒久受入可能範囲内にいるかどうかが判断される（決定３０４）。運転者が恒久受入可能範囲内にいない場合、条件付き拒絶が発行されてよく、運転者は、予備受入可能範囲内に到着することができないことについて、ユーザ関与パネルを通して１つ以上の理由の形で請求書作成関連性データを提出するように促される場合がある（ステップ３０５）。図２Ａに開示されるように、運転者の請求書作成要求は、状況に応じて完全な拒絶又は条件付き拒絶の対象となる場合がある。ユーザ関与パネルを通して提出されると、運転者によって提出された請求書作成関連データは、評価の対象となる。評価が、所定の時間内に所定数に達する場合、運転者の請求書作成要求に対して行われる調整がある場合がある。達しない場合、運転者の請求書作成要求は拒絶される。ただし、運転者は依然として所定の時間内に異議を唱える機会を有している。
【００８１】
運転者が、恒久受入可能範囲内にいる場合、実際の入力及び指定された入力に基づいて運転者の請求書作成要求に対して行われる調整がある場合がある（ステップ３０６）。請求書作成要求データは収集され、運転者が、恒久受入可能範囲内にどこに到着するのかに応じて、恒久受入可能範囲が必要であるよりも広い場合には、恒久受入可能範囲はサイズが変更される場合がある。他方、恒久受入可能範囲が厳格すぎる場合、次いでそれを規定する規則も更新される場合があり、恒久受入可能範囲はより大きくなる場合がある。所定の規則に基づいて、収集されたデータが、恒久受入可能範囲に対する更新を正当化するかどうかが判断されてよい（決定３０７）。これは、実際の入力（例えば、実際のジオロケーション又は実際の時間の場合）が、最大許容入力よりも正確であるかどうかを評価することによって判断されてよい。ジオロケーションの例では、指定されたジオロケーションがあり、受入可能範囲が１００フィートの範囲内での入力を受け入れる場合、１００フィートが「最大許容入力」となる。降車が、指定場所に１００フィートよりも近い、指定場所から２５フィートで起こる場合、これは、受入可能範囲が寛大すぎる証拠となる場合がある。実際の入力が実質的に異なる場合、収集されるデータは、恒久受入可能範囲に対する更新を正当化しない（ステップ３０８）。収集されたデータが恒久受入可能範囲に対する更新を正当化する場合、これは、所定の規則に基づいて恒久受入可能範囲に対する更新を生じさせる場合がある（ステップ３０９）。更新は、請求書作成関連データに基づいて関連性のあるサイズに受入可能範囲を調整してよい（例えば、受入可能範囲は、より小さくされてよい、又はより寛大になるために拡大されてよい）。
【００８２】
本発明の例示的な実施形態に従って、１つの受入可能範囲だけしか所与のときに完全にアクティブではない可能性があることが考えられることが当業者によって理解されるべきである。また、本発明の例示的な実施形態は、運転者に受入可能範囲内にいることを知らせるために運転者に対して警告を発行することを提供し、したがってピックアップ／降車を実行できる。運転者が、運転者に受入可能範囲の外にいることを通知する警告を受け取り、指定場所により近く進む必要がある場合、運転者は、自分の請求書作成要求に対する自動調整を受け取るためにこうする場合がある。
【００８３】
図３Ｂは、一定の状況における仮受入可能範囲を規定する手法を示すフローチャートである。「仮」受入可能範囲と呼ばれることがある第３の種類の受入可能範囲がある場合がある。仮受入可能範囲は、それを要求する場合に規定されてよく、それは部分的にはユーザ関与パネル１１５を通して規定されてよい。運転者が、恒久受入可能範囲の外にいるとき、運転者は、ユーザ関与パネル上で請求書作成関連データを提出するように促される（ステップ３０５）。仮受入可能範囲は、例えば、建設現場又は警察活動の現場等、運転者が指定場所に又は恒久受入可能範囲の中に到着できない状況で規定されてよい。仮受入可能範囲が規定されるかどうかは、所定の規則に基づいてよく、所定の規則の１つは、ユーザ関与パネル１１５での提出後に請求書作成要求に調整が発行されたかどうかを判断することである（決定３１５）。調整が発行されなかった場合、提出物、関連性のある請求書作成要求、及び他のデータは、データベース１０３に記録されてよい（ステップ３１１）。発行される調整がある場合、次に、（例えば、場所に基づいて、理由に基づいて）実質的に類似する所定数の調整が行われたかどうかが判断されてよい（決定３１２）。所定数に達していない場合、提出物、関連性のある請求書作成要求、及び他のデータは、データベース１０３に記録されてよい（ステップ３１１）。所定数の調整が行われている場合、調整の理由が解析されてよく、仮受入可能範囲の規定は、調整が長期の理由であることの理由に依存する場合がある（決定３１３）。いくつかの理由又は写真は、例えば、駐車場ではつねに立っていてはならない（ｎｏ  ｓｔａｎｄｉｎｇ  ａｎｙ  ｔｉｍｅ  ｐａｒｋｉｎｇ）規則等の駐車規則の変化等、受入可能範囲に影響を及ぼす場合がある長期の状態を反映し、他は一時的にすぎない場合もあるが、該規則は、規則が有効である場合運転者が乗客を乗せる又は降ろすことを許可しないであろう。理由が長期的であると判断される場合、恒久受入可能範囲は所定の規則に基づいて更新されてよい（ステップ３１３）。理由が長期的ではない場合、仮受入可能範囲が所定の規則に基づいて規定されてよく（ステップ３１４）、規則は、前のステップ又はそうではないもので収集されたデータに基づいて作られてよい、受入可能範囲のサイズを決定してよい。仮受入可能範囲は、ユーザ関与パネル１１５で提供される理由又は写真に従って規定されてよく、それは一定の時間数、日数、週数等、定位置に留まるために規定されてよい。
【００８４】
所与の場所のための以前の恒久受入可能範囲のパラメータは、仮受入可能範囲の中に存在する場合がある。以前の恒久的なパラメータは、「セミアクティブ」な恒久受入可能範囲と呼ばれてよい。仮受入可能範囲は実際に一時的である場合があるので、いくつかの場合、恒久受入可能範囲への逆戻りが適切な場合があり、したがって「セミアクティブ」な恒久受入可能範囲を規定することによって恒久受入可能範囲のパラメータを維持することが有益である場合がある（ステップ３１５）。
【００８５】
特定の受入可能範囲は、例えば、アクティブ、イナクティブ、又はセミアクティブ等の活動の状態にあってよい。ユーザ関与パネル１１５への提出物は、概して受入可能範囲の適用可能性に関するため、運転者が受入可能範囲内にいなかった場合の検証された請求書作成要求も、請求書作成関連データをさらに検証するために、手動又は自動でユーザ関与パネルへのアクセスにつながる。受入可能範囲の活動の状態は、ユーザ関与パネル１１５での１つ以上の提出物から部分的に下される判断であってよく、所定の規則が、ユーザ関与パネル１１５で提出されたどのデータが正確であるのかを規定する。これは動的に起こる場合がある。本明細書で「アクティブな」受入可能範囲は、現在適用可能である受入可能範囲を指すことを意図され、それは請求書作成要求内で時間に適用することもあれば、場所に適用することもある。「イナクティブな」受入可能範囲は、それが現時点で不正確であると見なされる可能性があるため、無効にされている受入可能範囲を指す場合がある。最後に、「セミアクティブな」は、仮受入可能範囲とともに組み込まれてよい恒久受入可能範囲を指す場合があり、セミアクティブ恒久受入可能範囲は、仮受入可能範囲が、所定の規則に従って無効にされるとき、恒久受入可能範囲に完全に有効にされ、特定の条件が、図３Ｃに開示されるようにセミアクティブ恒久受入可能範囲の完全な有効化をトリガしてよい。さらに、係る条件が満たされない場合、セミアクティブ恒久受入可能範囲はセミアクティブなままとなる可能性がある。アクティブであるのか、イナクティブであるのか、それともセミアクティブであるのかに関わりなく、すべての受入可能範囲に関する情報はデータベース１０３に記憶されてよく、それは１つ以上の他の受入可能範囲をより正確にするための履歴データとして使用されてよい。
【００８６】
図３Ｃは、仮受入可能範囲を更新するための手法を示すフローチャートである。仮受入可能範囲が実施されているとき、図３Ｂのステップ３１４及び３１５によって開示されるように、運転者は、規定された仮受入可能範囲に関連性のある請求書作成要求を提出してよい（ステップ３１６）。これは、仮受入可能範囲が規定された、又は関連性がある後の任意のときである可能性がある。運転者が仮受入可能範囲内にいるかどうかが判断されてよい（ステップ３１７）。運転者が、仮受入可能範囲内にいない場合、運転者は、調整が発行されるためにユーザ関与パネル１１５で請求書作成関連データを提出するように促される場合がある（ステップ３０５）。運転者が仮受入可能範囲内にいる場合、実際の入力及び指定された入力に基づいて運転者の請求書作成要求に対して行われる調整があってよい（ステップ３０６）。しかしながら、いったん規定されると、仮受入可能範囲を無効にさせる場合がある一連の条件がある。運転者が、仮受入可能範囲内にいることが検出され、調整が行われるとき（ステップ３０６）、運転者が、セミアクティブ恒久受入可能範囲の中にいるかどうかがさらに検出されてよい（ステップ３１８）。運転者がセミアクティブ恒久受入可能範囲内にいる場合、これは、仮受入可能範囲がもはや適用しないことの表示である場合がある。係る状況は、仮受入可能範囲の無効化及びセミアクティブ恒久受入可能範囲の完全な有効化をトリガしてよい（ステップ３１９）。例えば、仮受入可能範囲は、一週間の間続いた建設現場のために規定され、建設現場が取り除かれた後、運転者は再び、建設現場がかつてあった場所に到着する場合があり、これは、セミアクティブ恒久受入可能範囲内である場合がある。運転者がセミアクティブ恒久受入可能範囲内にいないが、依然として仮受入可能範囲内にいる場合、仮受入可能範囲は依然として次の関連性がある請求書作成要求に適用する場合がある。
【００８７】
図４Ａは、距離に基づいた受入可能範囲の適用を示す図である。（運転者モジュール１０５を含む場合がある）車両４００は、サービス要求を提供する運転者によって運転されてよく、指定された降車場所４０１は角のあたりに位置する。しかしながら、この図では、運転者は、道４０２を塞いでいる建設障害物のため、乗客を指定降車場所４０１で降ろすことはできない。運転者は、障害物のため指定降車場所４０１で乗客を降ろすことができないので、運転者は、乗客を安全な又は合法的な場所に降ろすために通りの路肩に寄せなければならない場合があり、実際の降車場所４０３は異なるであろう。しかしながら、運転者は、距離４０４に基づいた受入可能範囲内で到着できないので、運転者は、自分が指定降車場所４０１に到達できなかったことを証明するためにユーザ関与パネル１１５で請求書作成関連データを提出するように促される場合がある。運転者が指定場所に到着できない多くの他の筋が通った理由がある場合がある。要因は、駐車制限、道路規則又は駐車規則、及び他の一時的な道路封鎖を含む場合がある。いくつかの場合では、単に乗客が車両を降りるには安全ではない場合があり、運転者は、近傍の場所に寄せることがより安全である場合があることを評価する。また、特別な警備事象、パレード、大決起集会、又は抗議行動のための道路封鎖は、指定場所が降車場所であるのか、それともピックアップ場所であるのかに関わらず、指定場所に到達することを実現困難又は不可能にする場合がある。これらのすべては、運転者が、検証された場所又は時間の食い違いを有する場合がある潜在的な理由である場合がある。
【００８８】
図４Ｂは、距離に基づいた受入可能範囲の適用を示す図である。（運転者モジュール１０５を含む場合がある）車両４００は、サービス要求を提供する運転者によって運転されてよく、指定降車場所４０１は、通りの右路肩上にある。しかしながら、この図では、運転者は、道４０５を封鎖している継続中の建設のため、乗客を指定降車場所に降ろすために通りの側に寄せることができない。運転者は、障害物のため指定降車場所４０１で乗客を降ろすことができないので、運転者は乗客を安全な又は合法的な場所に降ろすために角を回って運転しなければならない場合があり、実際の降車場所４０３は指定降車場所４０１から外れるであろう。この図に示される距離に基づいた受入可能範囲４０４は、実際の降車場所４０３が、指定降車場所４０１の一定の距離範囲内にある場合、実際の降車場所に対する自動調整が行われ得る区域を提供する。
【００８９】
しかしながら、運転者は、降車を行うために異なる住所まで運転する特別な通知を出す必要がない可能性がある。この図に示される距離に基づいた受入可能範囲４０４は、指定降車場所４０１が、実際の降車場所４０３の一定の距離範囲内にある場合、実際の降車場所に対する自動調整がその中で行われてよい区域を提供する。図４Ａ及び図４Ｂでは、距離に基づいた受入可能範囲４０４は、２次元楕円として示される。しかしながら、この図を通して、距離に基づいた受入可能範囲４０４をこの次元の制約に限定することは意図されていない。ＧＰＳ及びジオロケーション技術（及び他のジオロケーション技術）は、３次元マッピングを可能にするので、それらの特長も受入可能範囲の中に組み込まれてよい。例えば、目的地が空港の出発玄関である場合、到着玄関が出発玄関の真下であるが、同一の座標に位置するとしても、出発玄関は到着玄関とは異なる場合がある。
【００９０】
図５は、バッファ及びその中のジオロケーション座標によって規定される受入可能範囲を示す図である。指定された場所５００、及びその関連座標が示される。この図では、距離に基づいた受入可能範囲４０４は、指定場所５００から１５０フィートの距離５０１のための所定規則に基づく。この図に示されるのは、資格要件を満たしたジオロケーション５０２及び５０３の２つの例であり、運転者が乗客を降ろす又はピックアップするならば、ジオロケーションは自動的に調整されてよい。これらの場所は受入可能範囲内にあるため、これらの場所は資格要件を満たしたジオロケーションである。別のジオロケーション５０４は、それが指定場所５００から１５０フィートの範囲内にないため距離に基づいた受入可能範囲内４０４にないので資格要件を満たしたジオロケーションではない。この場合、係るジオロケーションは、運転者がこの場所で降車を行わないならば、指定場所５００に一致するように自動的に調整されない可能性がある。
【００９１】
車両４００の座標情報が、ジオロケーション識別子１１１によって自動的に取り込まれ、自動的に生成され、送信される請求書／送り状／保険提出物の一部として、コンピュータネットワーク１１６を介してサーバ１００に送信されてよいことが理解されるべきである。本発明の例示的な一実施形態によれば、運転者モジュール１０５は、電子的な請求書作成検証提出物が、タクシー様式のメーターによって直接的に取得されるＧＰＳデータ及びタイムスタンプデータにより、改ざんを受け得ないようにタクシー様式のメーターの中に組み込まれてよい。
【００９２】
図６は、運転者が距離に基づいた受入可能範囲４０４内にいない場合にも運転者が請求書作成要求を提出しようと試みる場合、運転者コンピューティングデバイス１１０で運転者が受け取る場合がある潜在的なメッセージを示す図である。係る状況では、運転者は、運転者が指定されたジオロケーション及び／又は自動調整のための指定場所に十分に近くないことを運転者に通知するメッセージ６００を受け取る場合がある。これは、運転者が移動できる場合、運転者に指定されたジオロケーションのより近くに車両を移動させてよい。運転者が車両をより近くに移動できない場合、運転者が指定されたジオロケーションに到達できない理由の有効性が、請求書作成要求の検討プロセスを加速するために証明されてよい。したがって、運転者は、通りの写真を撮影６０１し、ユーザ関与パネル１１５を通して１つ以上の理由を提出するように促される場合があり、それは、運転者の提出物及びその正確さを検証するための直接の経験を有する１人以上の他のユーザによって検討されてよい。また、運転者が拒絶に異議を唱える場合、サービスプロバイダ又はベンダと関連付けられた人間の請求書作成者が、請求書作成関連データ（例えば、請求書作成要求、及び／又はタイムスタンプ及びジオタグ情報若しくは住所情報を含んだメタデータ付きの１枚以上の写真）を検討してもよく、サービスプロバイダは、運転者のジオロケーションを少なくとも確認することによって運転者の提出物の有効性を判断できる。
【００９３】
乗客をピックアップする又は降ろす運転者の意思は、自動的に識別、又は運転者の裁量で手動で提出されてよい。運転者の意思が自動的に識別される場合、運転者の意思は、ジオロケーション識別子１１１を通して判断されてよい指定場所への運転者の所定の近接に相互に関連付けられた運転者モジュール１０５に接続されてよい、少なくとも加速度計及び／又は速度計１２４を通して車両の速度及び速度の変化を解析して、識別されてよい。所定の近接は、指定場所への所定距離であってよく、運転者は所定距離を事前に設定することができる、又は所定距離はシステムによって規定されたデフォルトに基づいてよい。速度計は、車両の瞬間速度を測定してよく、加速度計は、車両の速度変化を測定してよく、速度及び速度の変化は部分的に意思を識別するために使用されてよい−例えば、運転者が減速していることが加速度計を通して記録され、これは、運転者が１時間に２マイル移動していることを示す速度計に相互に関連付けられ、これは、システムに、運転者が降車を行う意思があることを合図する場合がある。近接解析は、さらに、クロック機構１１３によって識別される時間と連携して使用されてよい。電子若しくはデジタルマップ又はサードパーティマップＡＰＩがシステムに統合されてよいので、車両が交通又は他の理由で道路の真中で減速又は停止し、車両が指定されたジオロケーションから遠すぎる又は指定された時間まで長すぎる場合、システムは、意図されたピックアップ又は降車の場所としてＧＰＳ座標及び速度データを通して係るジオロケーションを無視してよい。係る意思が自動的に識別されていても運転者が実際に乗客をピックアップ又は降ろす意思を有することを確かめるために、運転者は、自分のピックアップ又は降車の意思を確認するために通知で促される場合がある。
【００９４】
運転者の意思が手動入力を通じて判断される場合、運転者は、例えばモバイル機器等の、特にシステムに乗客をピックアップ又は降ろす意思を通知するようにプログラムされた運転者コンピューティングデバイス１１０でボタンを押してよい、又はシステムは、１つ以上のマイクを通じて運転者の意思を識別するための音声認識機能を統合されてよい。例えば、運転者は、「ピックアップする意思を受け入れてください」と命令する場合がある。また、運転者は、システムに、例えば６０フィートの距離等、指定場所までの所定の近接範囲内で乗客をピックアップ又は降ろす自分の意思を通知するためにセットアップしてもよい。
【００９５】
意思（例えば、ピックアップの意思又は降車の意思）が自動的に又は手動でのどちらかで識別されるとき、次いで運転者が受入可能範囲内にいるかどうかが判断されてよい。運転者が受入可能範囲内にいると判断される場合、請求書作成要求は自動的に生成され、調整されてよい。識別されたピックアップ又は降車の意思を有する運転者が受入可能範囲外にいると判断される場合、運転者に警報が発行されて、運転者に指定されたジオロケーションのより近くに移動するように促す場合がある。運転者が、警報によって促されたとき、指定されたジオロケーションのより近くに移動できない場合、運転者は、次いで条件付きの拒絶を発行され、ユーザ関与パネル１１５を通して請求書作成関連データを提出するように促されてよい。しかしながら、運転者が、警報によって促されたとき指定されたジオロケーションのより近くに移動し、いま、受入可能範囲内にいると判断される場合、自動調整が発行されてよい。したがって、この種の警報は、運転者が、条件付き拒絶を受け取り、ユーザ関与パネル１１５を通して請求書作成関連データを提出するのを回避する助けとなる場合があり、これは、請求書作成要求を処理する時間及び資源を節約し得る。
【００９６】
運転者に受入可能範囲内にいる又はそれ以外の場合、受入可能範囲外にいることを警告することは、少なくともユーザの好みに基づいてよいことが当業者により理解されるべきである。運転者は、例えば、係る警告を受け取ることを断ってよい。また、ベンダはこの機能性を使用する又は使用しないことを選んでよい。
【００９７】
運転者のジオロケーションを確認することは、例えば乗客の署名、乗客の指紋、乗客のパスワード入力等、乗客の検証情報を統合することによる使用のために意図される。さらに、乗客が障害又は別の状況のためにトリップに対して署名できないことに由来する場合がある検証のための例外がある場合がある。係る状況では、トリップは、例えば乗客の在宅医療助手又は家族の一員等の誰かによって検証されてよい。記載されるように、乗客の検証は、サービスの始まりに、サービス中に、又はサービスの終わりに行われてよい。乗客の検証は、運転者モジュール１０５、乗客モジュール１２０で、特殊目的装置上で、又は特に乗客に提供されるモジュールでも収集されてよい。さらに、これらの概念は、運転者が、自分が別の乗客ではなく特定の乗客を降ろすつもりであることを、又は追加の乗客をピックアップするつもりであることを知らせる場合がある、マルチレグトリップ又は複数乗客（ｍｕｌｔｉ−ｐａｓｓｅｎｇｅｒ）トリップでの使用に意図される。同じ場所で１人以上の乗客（例えば、家族の複数のメンバー、同じ病院に行く複数の乗客等）がピックアップ又は降ろされる状況では、メッセージは、一度に１つ以上のサービス要求からの情報を含んで、運転者がそれらのサービス要求を区別し、適切に実行できるようにする。複数乗客トリップでは、サービスプロバイダは、１つ以上の個別化されたサービス要求に対する受入可能範囲情報を提供しなくてはならない場合がある。一方、１つ以上のサービス要求は、同時に進行中である。運転者が受け取る場合があるメッセージは、順序正しく送信されてよい又はその関連性に従って編成されてよい。例えば、車内に、乗客１及び乗客２の２人の乗客がいる。乗客１は現在降ろされているところで、乗客２は５マイルの距離で降ろされる。運転者が乗客１のサービス要求のためのジオロケーションの受入可能範囲内にいない―が、依然として乗客１を降ろそうと試みる場合―運転者が受け取るメッセージは、乗客１に対するその特定のサービス要求だけに関し、乗客２に関していない場合がある。
【００９８】
図７は、運転者が１つ以上の受入可能範囲内に到達できないことを証明するために運転者によって提出される請求書作成関連データのために、運転者がユーザ関与パネル１１５を通して行うであろう考えられる提出物のプレビューを示す図である。この図では、運転者コンピューティングデバイス１１０は、ユーザ関与パネル１１５上に提出物プレビュー７００を表示するとして示される。運転者は、１つ以上の受入可能範囲７０１の中に到達しないことに対する１つ以上の理由を入力してよい。この例では運転者は、建設現場の写真７０２の事情を提供するために西５０番通りで建設があったことを入力した。運転者は、次いで「提出」ボタン７０３をクリックして、直接の経験を有する追加のユーザによる追加の検証のために、ユーザ関与パネル１１５を通してこの情報を提出してよい。
【００９９】
図８は、時間に基づいた受入可能範囲内にいることができないことについて、運転者が運転者コンピューティングデバイス１１０で受け取る場合がある潜在的なメッセージを示す図である。このメッセージは、運転者が遅れていると見なされるとき、又は運転者がピックアップ若しくは降車を行う意思を知らせているが、時間通りではなく、したがって時間に基づいた受入可能範囲内にいないときに表示される場合がある。携帯機器のディスプレイ上にあるのは、運転者に、指定された住所でのピックアップ時間に遅れていることを通知するメッセージ８００である。このメッセージは、運転者が時間のための受入可能範囲内にいない旨の表示である場合がある。メッセージは、運転者に、ここでは対話型タッチスクリーンディスプレイ上に示される「次へ」ボタン８０１をクリックするように促してよく、「次へ」ボタン８０１は、運転者を、運転者が遅延の理由に関して詳細に入力し得るユーザ関与パネル１１５のインタフェースに連れて行く場合がある。
【０１００】
図９は、時間に基づいた受入可能範囲内にいることができないことについての１つ以上の理由を入力するための、運転者コンピューティングデバイス１１０上の潜在的なインタフェースを示す図である。運転者は、理由をテキストフィールド９０２に打ち込むことによって理由を入力するように促される場合がある。この例では、テキスト９０１の題名が、運転者に、自分の遅延に対する理由を提供するように合図する。運転者は、次いでテキストフィールド９０２に理由を入力する又は口述してよく、「提出」ボタン９０３をクリックすることによってそれらの理由を提出してよい。受入可能範囲を満たすことができない各請求書作成要求に運転者の理由が添付される場合、それが検討プロセスを容易にするので、運転者は請求書作成要求が最終決定されるために理由を入力しなければならない場合がある。
【０１０１】
図１０は、ユーザ関与パネル１１５の潜在的なインタフェースを示す図である。ユーザ関与パネル１１５は、ユーザコンピューティングデバイス１０００を通してアクセスされてよく、ユーザは運転者であってよい。ユーザ関与パネル１１５を通して運転者によって提出された請求書作成要求に関する情報は、ユーザの現在位置若しくはユーザが最近いた場所１００１に、又はシステムによって促されるとき運転者によって提供される写真及び１つ以上の理由１００２に基づいてよい。ユーザ関与パネル１１５を通して、ユーザは、ユーザの直接の経験からのユーザの判断に基づいて、提供された理由が正確であったかどうかに関して投票するために、はい１００３をクリックすることによって確認する、又はいいえ１００４をクリックすることによって拒否することができる。投票の議論がある場合（例えば、確認が所定数の肯定的な評価に達するが、所定数の否定的な評価もあるとき）、事例はさらに公開され、例えばサービスプロバイダと関連付けられた請求書作成者又はベンダ若しくはその代理人と関連付けられた請求書作成者等の関連性のある関係者によって見直される場合がある。事例の検討は、例えば１つ以上のジオタグが付けられた写真等の追加情報又は乗客の検証情報を与える、提供された任意の情報を使用してよい。また、ユーザは、評価１００５に対する１つ以上の理由を提供してもよい。ユーザが１つ以上の理由を確認又は拒否できない場合、ユーザは、「飛ばして進む」ボタン１００６をクリックすることによって飛ばして進むことができる。サービス要求、ジオロケーション、又は時間の直接の経験を有する任意のユーザは、それがサービスプロバイダであるのか、運転者であるのか、ベンダであるのか、又は情報を有する誰か他の人であるのかに関係なく、ユーザ関与パネル１１５を通してデータを貢献してよい。他のユーザに知らせること又はそれが所定数の肯定的な評価を受け取ることのどちらかにより、任意のクラウドソースによるデータ又は情報が役立つと識別される場合、次いでそれを提出したユーザに報酬が与えられてよい。報酬は、金銭的である場合もあれば、例えばギフト若しくは昇格のタイプ等、金銭的ではない場合もある。報酬を与えることは、ユーザがユーザ関与パネル１１５を使用し、ユーザ関与パネル１１５で提出を行うための動機を提供し得る。
【０１０２】
図１１は、距離に基づいた受入可能範囲４０４に関係するデータベーステーブル１１００を示す図であり、請求書作成検証システムの中でデータがどのようにして収集され、ユーザ関与パネル１１５を通して、又はサービスプロバイダモジュール１０４上のどこか他の場所でサービスプロバイダに表示され得るのかを示す。例えば、テーブル１１００は、請求書作成要求に関するジオロケーションデータを含み、降車のための情報を明確に示す。一番左の欄は、トリップＩＤ情報１１０１を示す。また、示されているのは、入力された住所のそれぞれから取り出され、ジオロケーション座標にジオコーディングされた可能性がある指定降車場所のそれぞれの座標１１０２である。また、示されているのは、実際の降車場所の座標１１０３である。一番右の欄は、座標間の差１１０４を示し、実際の降車場所が受入可能範囲内にあったかどうかを表すであろう。この図では、これらの差のうちの２つが、請求書作成システムの中で警報がない受入可能範囲内に該当するジオロケーションを示す。しかしながら、降車場所の差が大きすぎるため、１つの請求書作成要求記録が、その隣に警報インジケータ１１０５を有する。これは、サービスプロバイダが、いくつかの状況でこの情報に関して検討を公開するための視覚的な合図としての機能を果たしてよい。サービスプロバイダは、請求書作成要求についてのより包括的な情報１１０６を示すユーザ関与パネル１１５の別のインタフェースを提示する場合がある警報インジケータ１１０５をクリックすることによってこの差の理由を調査できる場合がある。また、この図に示されるのは、運転者の写真識別、運転者の氏名、及び運転者ＩＤだけではなく、運転者に関する情報でもある。また、示されるのは、トリップＩＤ、乗客ＩＤ、並びに指定降車ジオロケーション及び実際の降車ジオロケーションが人間可読住所１１０８に変換される詳細な運転者情報１１０７である。また、詳細な情報の中に含まれるのは、別の場所で乗客を降ろしたことについて運転者によって提供された根拠１１０９である。この図では、運転者が、西５０番通りで工事があり、したがって運転者が乗客を降ろすために他の場所に行かなければならなかったことに言及していることが示される。運転者は、この証拠として建設現場を含んだ都市の街並みを示す写真１１１０をアップロードし、写真は、運転者の理由が筋が通っていることの証拠を提供するために、ジオタグ情報及びタイミング情報で補強される場合がある。
【０１０３】
図１２は、サービスプロバイダモジュール１０４上でアクセスされてよい、請求書作成要求についての包括的な情報１１０６を示すユーザ関与パネル１１５の潜在的なインタフェースをさらに示す図である。請求書作成要求が、検討又は議論のためにフラグを付けられているとき、それは、コンピューティング手段によって又はサービスプロバイダによって検討され、認証されてよい。検討プロセスでは、「さらに参照」ボタン１２０２がクリックされる場合、詳細な情報が別ディスプレイ１２０１上で利用されてよい。そのディスプレイ上には、乗客の署名、並びに署名のためのジオタグ及びタイムスタンプを含んでよいそれについての情報１２０３があってよい。乗客検証情報は、指紋、虹彩スキャン、又は実装され得る他の種類の物理的な検証を含む場合がある。さらに、検証情報は、２要素認証等のためにｅメール又はＳＭＳコードによる場合がある。このディスプレイ上には、写真のジオロケーション座標及び写真の著者だけではなく、時間、人間可読近似場所も含むであろう、写真１２０４から取り出されるデータ及び情報もある場合がある。また、乗客確認のジオロケーション又は時間は、乗客のモバイル機器を通して得られるであろう、受入可能範囲が乗客の場所に基づく受入可能範囲解析の根拠であってもよい。指定されたジオロケーションと写真と関連付けられたジオロケーションとの間の差１２０５の表示がある場合があり、これはシステム又はサービスプロバイダが、運転者の、１つ以上の距離に基づいた受入可能範囲４０４の中に到達できない理由の有効性を決定するのに役立つ場合がある。
【０１０４】
図１３は、時間に基づいた受入可能範囲に関係するデータベーステーブルを示す図である。これは、ユーザ関与パネル１１５を通してサービスプロバイダが利用できるようにされてよい。図中に示されるのは、一意のトリップＩＤフィールド１３００に対応するデータを示すテーブルである。各トリップＩＤに関連付けられているのは、各トリップＩＤに関係する異なる欄に表示される情報であり、指定ピックアップ住所１３０１、指定ピックアップ時間１３０２、実際のピックアップ時間１３０３、指定ピックアップ時間と実際のピックアップ時間との間の時間差に基づく差の値１３０４である。トリップＩＤ欄の最初の４つのトリップのそれぞれは、５２秒と２分２１秒との間の小さい差を示す。最後のトリップＩＤは、５５分を超える差を示す。サーバ１００は、大きい時間の食い違い―大きすぎて、受入可能範囲に該当しない―のために自動調整がないであろうため、運転者に、ユーザ関与パネル１１５を通して１つ以上の理由を提供するように促す場合がある。その請求書作成要求は、サービスプロバイダ又は他の関連性のある関係者に、何かが関心に値する場合があることを通知する警報インジケータ１３０５によってフラグを付けられてよい。これは、１つ以上の理由がユーザ関与パネル１１５を通して所定の時間内に所定数の評価を受け取る前又は後であってよい。サービスプロバイダ又は他の関連性がある関係者が、この請求書作成要求の詳細を検査する場合、そのユーザは、インジケータ１３０５をクリックすることによって検査するであろう。インジケータ１３０５をクリックすると、詳細な運転者情報１１０６及び請求書作成要求についての追加の詳細１３０６、さらに、遅れた到着について運転者によって提供される理由１３０７−この例では、運転者は、ピックアップ場所までのルートに沿った激しい交通渋滞とともに、前のトリップがタイミングを遅らせたことを示した−が提示され得る。
【０１０５】
図１４は、データベース１０３に記憶されるデータ、及びデータの編成がどのようにして実行され得るのかを示す図である。特定のデータの編成及び取出しのためにデータベース及びデータ記憶媒体を提供する多数の方法があり、本発明の例示的な実施形態は、適切なデータベース（複数可）又は記憶手段との使用に意図される。いくつかの実施態様では、データベース１０３は、遠隔で場所を突き止め、アクセスできる。さらに、データベースとして参照されながら、構造化なのか、それとも非構造化なのか、リレーショナルなのか、それともそれ以外なのかに関わりなく、データベース１０３がデータ記憶媒体を含んでよいが、これに限定されるものではないことが理解されてよい。データベース１０３は、サービスが予約され、完了されるにつれ、動的に更新されてよい。データベース１０３は、必要に応じてどんなときでも参照のために取り出すことができる乗客及び運転者の登録番号又はユーザ識別を含んだ、要求され、完了されている各サービス要求のインデックスを記憶してよい。また、データベース１０３は、将来の参照のために、それぞれの特定の運転者、乗客、ベンダ、又はサービスプロバイダについて編成されたサービス要求又は請求書作成要求の詳細を記憶してもよい。データベース１０３は、例えば、いつ及びどこからサービス要求が行われたのか、誰がサービス要求を行ったのか、誰がサービス要求を提供したのか、乗客が訪れた医師の名前は何であったのか等、サービス要求データ１４００を含んでよい。さらに、ユーザ関与パネル１１５（ユーザ関与パネルデータ１４０１）を通して提供されたいずれのデータも、独自のカテゴリで記憶されてよく、そのサブカテゴリがあってよい。
【０１０６】
サービス要求データ１４００のすべて又は一部分は、例えばコンピューティングデバイス上の重要なフィールドに入力される等手動で、又は自動的に、以前に提供された若しくはどこか他の箇所で提供された乗客と関連付けられたデータがアップロード若しくはインポートされて提供されてよい。サーバ１００は、トリップ識別子（「トリップＩＤ」）を生成し、その識別子をサービス要求に割り当てるようにプログラムされてよい。これは、データベース１０３内でデータを編成し、それらのサービス要求を編成するために行われる。このサービス要求データ１４００の編成及び各サービス要求に対するトリップＩＤの割当ては、例えば運転者が拒絶された請求書作成要求に異議を唱える等、潜在的な議論又は監査の場合に役立つ。トリップＩＤは、アルファベット、数値、英数字であってよく、無作為に又は暗号鍵若しくは非暗号化鍵に従って生成されてよい。例えば、特定の日に点Ａから点Ｂに移動する運転者は、重要なサービス要求データに従ってカタログに掲載される場合がある。例えば、サービス要求詳細は、トリップ識別子自体の中に含まれてよく、それをその基本データに変換するアルゴリズムがある場合がある。トリップ識別子は、関連性のあるデータをデータベース１０３の中で直接的に待ち行列に入れるために使用されてよい。
【０１０７】
さらに、サービス要求データ１４００は、運転者の氏名、ＩＤ、及び住所だけではなく、乗客の氏名、ＩＤ、及び誕生日、並びに乗客が輸送されている医師又は機関の名称、関連付けられたＩＤ及び住所も含んでよい。さらに、標準的な詳細は、要求又は事前に許可されている医療又は医療活動のコード、並びに承認又は承認要求が提出及び／又は発行された日付を含んでもよい。この情報の一部は、一定の関係者だけにしか可視ではない場合がある。例えば、特定の保護医療情報（ＰＨＩ）又は他の認証情報は、運転者が利用できない可能性がある。いくつかの状況では、許可は指定された時間の後には無効であり、有効日後にサービスを提供した運転者は支払われない可能性があるため、許可の日付が、潜在的に議論される事例で関連性がある場合がある。サービス要求の事前許可は、ＮＥＭＴに適切な場合がある。例えば、多くのベンダは、毎回輸送サービスに対する同じ必要性に基づいて予定される再発する約束である、特定の乗客に対する継続発注を有する。当業者にとって、継続発注及びその関連付けられた詳細は、概して事前に既知であり、予定されているサービス要求は、（例えば、乗客が自分の家からピックアップされ、同じ診療所に輸送される、週に２回、同じ場所で起こる約束のための）以前の入力に関する同じ又は類似した情報を使用できる。さらに、ベンダは、サービス要求がどのように実行されるのかに関する規定を有してよく、係る規定を入力するための手段が提供される場合がある。これは、受入可能範囲のサイズを定義する規定を含んでよい。
【０１０８】
サーバ１００は、検証システム、及びいくつかの実施形態では、そのデータがデータベース１０３に記憶されてよい電子データ交換（ＥＤＩ）を通して、例えばブローカー又は保険会社等のベンダからデータを受け取るように構成された１つ以上のインタフェースを含んでよい。特定の例示的な実施形態では、検証システムは、指定されたジオロケーション及び指定された時間を含むスケジューリング情報に接続する。
【０１０９】
データベース１０３は、例えばバッファパラメータ、及び／又は各ジオロケーションの受入可能範囲だけではなく、指定されたジオロケーション及び実際のジオロケーション等のジオロケーション調整データ１４０２を記憶してもよい。さらに、データベース１０３は、各時間調整に関連性があるバッファパラメータ及び／又は受入可能範囲にも関する、時間調整データ１４０３を記憶してよい。また、データベース１０３は、サービスプロバイダデータ１４０４、ベンダデータ１４０５、運転者データ１４０６、及び乗客データ１４０７を記憶してもよい。これらのデータは、プロファイル、サービス要求履歴、請求書作成要求履歴等を含んでよい、各ユーザが生成してよいありとあらゆる記録を反映してよい。また、データベース１０３は、請求書要求データ１４０８を記憶してよい。データベース１０３は、受入可能範囲を定義する所定の規則１４０９を分類するように構成されてよく、それらの規則は、特定のサービス要求、１つ以上の場所又は時間、１つ以上のベンダ、１人以上の乗客等と関連付けられてよい。このようにして、サーバ１００は、必要時、データベース１０３から適用可能な所定の規則を取り出すことができる。さらに、データベース１０３は、すべてのユーザの登録データ１４１０を記憶してよい。さらに、データベース１０３は、ＧＩＳ１０２マップ層として使用するために又は他の関連する目的のために問い合わされる場合がある、地図構成要素データ１４１１を記憶してよい。地図構成要素データ１４１１は、例えばＧＯＯＧＬＥ  ＭＡＰＳ等のサードパーティジオコーディングＡＰＩから取り出されるデータを含んでよい。さらに、データベース１０３は、電子請求書作成検証に関連性がある任意の他のデータ１４１３だけではなく、管理データ１４１２のシステム管理に関係するデータも記憶するように構成されてよい。
【０１１０】
それがリレーショナルデータベースである場合、次いでデータベーステーブルは、例えば、他のデータベーステーブル（複数可）との１対多の関係性、多対多の関係性、及び１対１の関係性等の１種類の関係性を有してよい。システムがベンダ又は運転者から入力又は要求を得るたびに、サーバ１００は、最初にデータベース１０３又は関連データベースセンタとの安全なアクセスチャネルを開き、次いでシステムは、アクセルチャネルを通してデータベース管理モジュールにクエリー文を送出する。以下に説明されるデータベーステーブル間の関係性に基づいて、データベース管理モジュール（複数可）は、正確にクエリー文に従い、２つ以上のデータベースを互いに結合することで又は結合せずに、ＩＤ（複数可）、テーブル名、及びテーブルの欄名を使用することによって特定のデータベーステーブル（複数可）を見つける。それが管理モジュールである場合、それは正確にクエリー文に従い、クエリー文が提供するキーを使用することによって特定のデータを見つける。それがリレーショナルデータベースであるのか、それとも非リレーショナルデータベースであるのかに関わりなく、サーバ１００が、データベース管理モジュールを通して又は他の手段によって行われてよいターゲットとされたデータを取り出した後、次いでそれは検索結果を保護されたアクセスチャネルを通してサーバ１００に送り返す。次いで、保護されたチャネルは、それが開かれる次回まで閉じられる。
【０１１１】
データベース１０３が、データが変更又は更新されるたびに動的に更新し、同期してよいことが当業者によって理解されるべきである。サーバ１００は、例えば受入可能範囲、乗客の住所、ベンダの情報、（例えば、ユーザからクラウドソースされる）ユーザ関与パネルから提出される新しいデータ又は情報等のための所定の規則の変更等の最新の変更を反映するためにデータを動的に更新してよい。さらに、特定のデータ又はデータ更新が偽であることが証明される場合にデータをそれがあった可能性があるものに戻す方法があってよい。データは、効果的な並べ替え及び取出しを可能にする方法で変性又は構造化されてよい。別の例示的な実施形態では、データは、非リレーショナル又は非構造化で記憶されてよい。当業者は、データベース又は他のデータ記憶媒体にデータを提供する、記憶する、及び編成するための多数の方法があることを理解し、本発明の例示的な実施形態は、任意の適切なデータベース又はデータ記憶媒体との使用のために意図される。さらに、一次データベースでデータ損失がある場合、一次データベースをバックアップし得る少なくとも１つのバックアップデータベースがあってよい。また、データベース１０３に関係するバックアップデータベースの任意のデータは、データベース内での変更に従って変化する場合がある。
【０１１２】
図１５は、ＧＩＳ１０２によって実行される潜在的なジオプロセシング機能を示す概略図である。ＧＩＳ１０２は、運転者モジュール１０５又はベンダモジュール１０６によって提供されるジオロケーション座標であってよい、入力データ１５００を受け取る。他の例では、入力は、サービス要求で提供される住所であってよい。ＧＩＳ１０２は、データを取り込み、表示し、それ以外の場合解析し、例えばスマートホン、ウェブポータル等のコンピューティングデバイスで見られる（例えばＧＯＯＧＬＥ  ＭＡＰＳ等の）層として電子地図又はデジタル地図を統合してよい。この統合により、車道は、少なくとも地図データに基づいて表示されてよい。ＧＩＳ１０２は、類似する属性を有するデータ点が分離され、層として出力される、異なる層を統合してよい。その出力層は、類似した属性を有するそれらのデータ点のすべての例を示すであろう。ＧＩＳ１０２は、サーバ１００に配備される場合もあれば、例えば有線接続又は無線接続等の通信リンクを１つ以上のサーバと共用して、別々に機能する場合もある。リンクを通じて、例えば請求書作成要求又はサービス要求等の情報が送信されてよい。ＧＩＳ１０２は、バッファツール１５０１及び／又は近接解析を使用し、受入可能範囲を規定し、サードパーティジオコーディングＡＰＩ１５０３（例えば、ＧＯＯＧＬＥ  ＭＡＰＳ又はＯＰＥＮ  ＡＤＤＲＥＳＳＥＳ、グローバルアドレス収集ＡＰＩ）に接続して、住所を座標に、及び座標を住所に変換してよい。処理ユニット１２３は、ＧＩＳ１０２の機能を用いて、又はなしで受入可能範囲を規定してよい。入力データ及び出力必要性に基づいて、ＧＩＳ１０２は、サーバ１００又は他の関連性のあるシステム構成要素と通信で共有されてよい、出力１５０４を生じさせてよい。
【０１１３】
ＧＩＳ１０２は、地理情報を取り込む、表示する、記憶する、操作する、及び解析するために、サーバ１００、非一過性コンピュータ可読記憶媒体１０１、及びデータベース１０３と協力して使用されてよい。一定のクエリー動作を遂行するために、ＧＩＳ１０２は、データベース１０３からデータを抽出し、解析することができる、又はデータベースの中に記憶されるデータは、データベース管理システム（ＤＢＭＳ）によって管理される。ＧＩＳ１０２はデータを視覚化するために使用されてよく、それはデータを有効に並べ替え、アクセスし、見る方法を提供する。ＧＩＳ１０２は、その根本的な機能を適切に実行するためにいくつかの重要な構成要素から成り、それは、中央コンピュータ又は中央コンピュータに取り付けられ、ＧＩＳ１０２が機能することを可能にする任意の二次装置を伴うハードウェア、ソフトウェア、地理データ及び地理情報を記憶し、解析し、表示するために実行可能なプログラミング言語を使用し、作成されるアルゴリズム、並びにデータ、例えばピックアップ場所及び降車場所、ルート等の解析される任意の情報を幅広く含んでよい。ＧＩＳ１０２は、正確な維持手順の知識を有する技術者又は他の資格のある人員によって保守されてよい。また、ＧＩＳ１０２の異なるクラス又はモデルは、異なるアプリケーションに使用されてもよい。例えば、フィールドモデル等のＧＩＳは、連続的な領域で切り替わるデータを解析するために必要である場合がある。別々のモデルは、２次元空間内での点に関するデータを分析するために使用されてよい。最後に、ネットワークモデルは、例えば幹線道路又は道路に沿った点等の一連の点によって接続される２つの点を解析するために使用されてよい。
【０１１４】
上述されたように、車両４００は、例えば耐タンパー性のある請求書作成検証装置の一部としてその中にインストールされた運転者モジュール１０５を含んでよい。この請求書作成検証装置が、乗客の医療保険情報を含む場合がある車両の運転者からの入力を受け取る場合もあれば、乗客が、（装置と通信中である）車両４００の後部座席領域の中に設置された端末へアクセスできる場合もあり、乗客はこの端末を使用して、健康保険（又は他の支払者情報）を提供し、降車住所及び時間を確認してよい。到着時、請求書作成検証装置は、トリップ、タイムスタンプ、及びジオロケーションの記録を最終決定し、例えば請求書作成検証装置の中に統合されたセル無線を使用し、指定された保険会社又は他の支払者に記録を自動的に送信してよい。サーバ１００は、正式な提出物として記録を保険会社／支払者の所望される構文に再フォーマットし、次いで正式な提出物を適切な保険会社／支払者に電子的に送信してよい、保険会社／支払者又は仲介エンティティによって保守されてよい。ＧＰＳ座標／タイムスタンプデータは、正式な提出物の一部であってよく、例えば上述された手法に従って提出物を受け入れるのか、それとも拒絶するのかを判断する際に使用されてよい。１つ以上のサーバから保険会社／支払者への提出物の送信だけではなく記録の１つ以上のサーバへの送信も、患者の医療約束の場所及び時間を含む場合がある極秘医療データが、部外秘に保たれ、１９９６年の医療保険の相互運用性と説明責任に関する法律（ＨＩＰＡＡ）及び他の類似した法律要件との準拠に適した方法で処理され得るように、１つ以上の暗号化技法を使用し、実行されてよい。
【０１１５】
このようにして、本発明の例示的な実施形態は、保険会社又は他の支払者に対する支払いのための電子提出物を自動的に送信できるＮＥＭＴ用の医療輸送車両を提供してよい。
【０１１６】
本明細書に説明される例示的な実施形態は例示的であり、多くの変形形態が、本開示の精神から、又は添付の特許請求の範囲の範囲から逸脱することなく導入できる。例えば、異なる例示的な実施形態の要素及び／又は特長は、結合されてよい、及び／又は本開示の範囲内で互いと置換されてよい。したがって、結合を説明することの不在は、係る結合に対する権利を有することを不可能にするべきではない。例は、本明細書で添付図面を参照して詳細に説明されるが、概念がそれらの正確な例に限定されないことが理解されるべきである。したがって、概念の範囲は、以下の特許請求の範囲及びその同等物により定義されることが意図される。
【図１Ａ】
2020502634.tif 000003
【図１Ｂ】
2020502634.tif 000004
【図２Ａ】
2020502634.tif 000005
【図２Ｂ】
2020502634.tif 000006
【図２Ｃ】
2020502634.tif 000007
【図３Ａ】
2020502634.tif 000008
【図３Ｂ】
2020502634.tif 000009
【図３Ｃ】
2020502634.tif 000010
【図４Ａ】
2020502634.tif 000011
【図４Ｂ】
2020502634.tif 000012
【図５】
2020502634.tif 000013
【図６】
2020502634.tif 000014
【図７】
2020502634.tif 000015
【図８】
2020502634.tif 000016
【図９】
2020502634.tif 000017
【図１０】
2020502634.tif 000018
【図１１】
2020502634.tif 000019
【図１２】
2020502634.tif 000020
【図１３】
2020502634.tif 000021
【図１４】
2020502634.tif 000022
【図１５】
2020502634.tif 000023
【国際調査報告】
2020502634.tif 000024