JP2022520594A - 車両の行程を求めるためのシステム - Google Patents

Abstract

実施形態は、ロケーションイベントデータを取り込み、イベントデータから車両の行程を特定するためのシステムおよび方法に向けられている。行程を特定することは、特定の車両が行程の目的地に向かって運転するために移動しているか否かを特定することを含む。

Description

開示の背景
自動車産業はこれまでに見たことのない激変の最中にある。混乱がモビリティエコシステム全体に生じている。結果として、車両は、一層自動化、接続、電化、および共有されるようになった。そのため、自動車から発生するデータは爆発的に増加している。この豊富な新たなデータ資産はほとんどが未活用のままである。

ＧＰＳデータ等の車両ロケーションイベントデータは、極めて膨大なものであり、毎秒２００，０００～６００，０００のレコードを含み得る。実質的にリアルタイムのデータ分析を提供する従来のシステムにとって、とりわけ個々の車両についてロケーションイベントデータを処理することが課題となっている。さらに、個々の車両データについての課題は、個々の車両データを匿名化しつつ分析のためにこれらのスケールで特定することである。大量のデータを遅延を少なくして処理および保存しつつもこの大量のデータを分析および再処理のために利用できるようにするように構成された、システムプラットフォームならびにデータ処理アルゴリズムおよびプロセスが必要である。

車両を追跡するためのシステムは存在するが、必要なのは、大量の車両データからの、リアルタイムに近い正確な行程データである。車両の移動およびルートの分析から行程および行程の目的地を正確に特定するように構成されたシステムとアルゴリズムが必要である。

開示の概要
以下、本明細書に記載のイノベーションのいくつかの側面の基本的理解が得られるよう、実施形態を簡単に説明する。この簡単な説明は、広範囲にわたる概要を意図しているのではない。重要または不可欠な要素を特定することを意図している訳でも、範囲を明確にするかそうでなければ狭くすることを意図している訳でもない。その目的は、後に示すより詳細な説明の前置きとしていくつかの概念を簡単な形で示すことにすぎない。

簡単に説明すると、車両イベントデータを処理するためのシステム、方法、およびコンピュータプログラムプロダクトの各種実施形態が本明細書に開示される。

少なくとも１つの実施形態は、プログラム命令を含むメモリと、以下の方法のための上記命令を実行するように構成されたプロセッサとを備えるシステムであり、この方法は、ロケーションイベントデータを取り込むステップと、このイベントデータから車両の行程を特定するステップとを含み、上記行程を特定するステップは、特定の車両の移動が上記行程の行程セグメントであるか否かを特定することを含む。

ある実施形態において、上記イベントデータは、時間、位置（緯度／経度）、および興味のあるイベントを含み得る。興味のあるイベントは、急ブレーキ、急な減速、または急な加速を含み得る。急ブレーキまたは急な減速は、予め定められた時間内の減速であると定義されてもよい。急な加速は、別の予め定められた時間内の加速であると定義される。

ある実施形態において、プロセッサは、イベントデータにおけるロケーションデータを近接度に符号化することをさらに含む上記方法のための命令を実行するように構成されている。

ある実施形態において、上記イベントデータにおけるロケーションデータを近接度に符号化することはさらに、緯度および経度を、近接度を定める形状にジオハッシュすること、ジオハッシュを符号化して州を特定すること、ジオハッシュを符号化してジップコードを特定すること、およびジオハッシュを精度に符号化して車両を一意に特定すること、のうちの少なくとも１つを含み得る。

ある実施形態において、上記イベントデータにおけるロケーションデータを近接度に符号化することはさらに、ジオハッシュを５文字に符号化して州を特定すること、ジオハッシュを６文字に符号化してジップコードを特定すること、およびジオハッシュを９文字に符号化して車両を一意に特定すること、のうちの少なくとも１つを含み得る。ある実施形態において、イベントデータにおけるロケーションデータを近接度を定める形状に符号化することは、緯度および経度を、そのエッジがストリング内の文字に比例する矩形に、ジオハッシュすることを含む。

ある実施形態において、イベントデータにおけるロケーションデータを近接度に符号化することは、ジオハッシュを４～９文字に符号化することをさらに含む。

ある実施形態において、プロセッサは、ジオハッシュをマップデータベースにマッピングすることをさらに含む上記方法のための命令を実行するように構成されている。マッピングすることは、ジオハッシュを興味のあるポイントデータベースにマッピングすることをさらに含み得る。

ある実施形態において、上記行程を特定するステップは、車両のエンジンオンまたは最初の車両移動を特定することと、車両のエンジンオフまたは移動停止を特定することと、車両の滞留時間を特定することと、車両の最短走行距離を特定することと、最短走行継続時間を特定することとを含む。

ある実施形態において、プロセッサは最短走行継続時間基準で構成され、プロセッサは最短走行継続時間基準を用いて車両の最短走行継続時間を特定するための命令を実行するように構成されている。最短走行継続時間基準は、約６０～約９０秒であってもよい。ある実施形態において、最短走行継続時間基準は約６０秒である。

ある実施形態において、プロセッサは最長滞留時間基準で構成され、プロセッサは最長滞留時間基準を用いて車両の最長滞留時間を特定するための命令を実行するように構成されている。最長滞留時間基準は、約２０～約１２０秒であってもよい。ある実施形態において、最長滞留時間基準は約３０秒である。

ある実施形態において、プロセッサは最短走行距離基準で構成され、プロセッサは最短走行距離基準を用いて車両の最短走行距離を特定するための命令を実行するように構成されている。最短走行距離基準は約１００メートル～約３００メートルであってもよい。ある実施形態において、最短走行距離喫準は約２００メートルである。

ある実施形態において、上記行程を特定するステップは、行程セグメントがこの行程の一部を形成しないと判断することを含む。

ある実施形態において、上記システムは能動的車両検出を提供するように構成されている。能動的車両検出は、ある期間にわたる複数のイベントから車両経路を特定することを含み得る。ある実施形態において、能動的車両検出は、ある１日の上記期間にわたる複数のイベントから車両経路を特定することを含み、特定することは接続コンポーネントアルゴリズムを使用することを含み、接続コンポーネントアルゴリズムは、車両イベントの上記日を含む有向グラフ内で車両経路を特定することを含む。このグラフにおいて、ノードが車両であり、ノード間の接続が特定された車両経路である。

ある実施形態において、上記システムはデータウェアハウスを含み得る。このシステムは、イベントデータおよび行程決定データをデータウェアハウスに格納する。ある実施形態において、少なくとも１つのタイムカラムを格納されたデータに追加してもよい。このタイムカラムは日付（date）カラムおよび時間（hour）カラムを含み得る。

少なくとも１つの実施形態は、コンピュータによって実現される方法を説明し、このコンピュータは、プロセッサと、上記のおよびここに記載される方法を実行するための命令を含むプログラムメモリを含むメモリとを備える。

少なくとも１つの実施形態は、プロセッサによって実行されると上記のおよびここに記載される方法を実行するための命令を含むプログラムメモリを含む、コンピュータプログラムプロダクトを説明する。

本明細書で使用される行程は、ある目的地への任意のトリップ、走路、または走行を含み得る。

本明細書に記載のシステムおよび方法の、ある具体例としての利点は、本開示の時点で最大１２００万台の車両について毎秒最大６００，０００のレコードに対し車両イベントデータを取り込み処理することが可能な、最適化された低レイテンシである。

非限定的でありかつ非網羅的な実施形態について図面を参照しながら説明する。図面において、特に明記しない限り、各種図面の同様の参照番号は同様の部分を示す。

一層の理解のために、添付の図面と関連付けて読まれるべき以下の詳細な説明を参照する。

各種実施形態のうちの少なくとも１つを実現することができる環境のシステム図である。 本開示の各種実施形態のうちの少なくとも１つに従うイングレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに従うストリーム処理サーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに従うエグレスサーバシステムの論理アーキテクチャおよびフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに従う分析サーバシステムの論理アーキテクチャおよびプロセスのフローチャートを示す図である。 各種実施形態のうちの少なくとも１つに従うポータルサーバシステムの論理アーキテクチャおよびプロセスのフローチャートを示す図である。 システムのデータ処理チェックのデータ品質パイプラインを示すフローチャートの図である。 各種実施形態のうちの少なくとも１つに従うクラウドコンピューティングアーキテクチャを示す図である。 各種実施形態のうちの少なくとも１つに従うクラウドコンピューティングプラットフォームの論理アーキテクチャを示す図である。

実施形態の詳細な説明
以下、添付の図面を参照しながら各種実施形態についてより十分に説明するが、これらの図面は、実施形態の一部を形成し、説明のために、本明細書に記載のイノベーションを実施できる特定の実施形態を示す。しかしながら、実施形態は、多数の異なる形態で実施可能であり、本明細書に記載の実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本開示が詳細で完璧となるように、かつ、実施形態の範囲を当業者に十分に伝えるように、提供される。とりわけ、各種実施形態は、方法、システム、媒体、またはデバイスであってもよい。そのため、以下の詳細な説明は限定的な意味で解釈されてはならない。

本明細書および請求項を通して、以下の用語は、文脈が明らかにそれを否定しない限り、本明細書において明示的に関連付けられている意味を持つ。「本明細書において」という用語は、本願に関連付けられた明細書、請求項、および図面のことである。本明細書で使用される「一実施形態において」または「ある実施形態において」という表現は、同一の実施形態または単一の実施形態を指す可能性はあるが、必ずしも異なる実施形態を指す訳ではない。したがって、以下で説明するように、各種実施形態を、本発明の範囲または精神から逸脱することなく、容易に組み合わせることができる。

加えて、本明細書で使用される「または」という用語は、包含的な「または」であり、文脈が明らかにそれを否定しない限り、「および／または」という用語と等価である。「基づいて」という用語は排他的なものではなく、文脈が明らかにそれを否定しない限り、記載されていないその他の要素に基づくことを認める。加えて、本明細書を通して、「ａ」、「ａｎ」および「ｔｈｅ」の意味は、複数を含む。「中に／内（ｉｎ）」の意味は、「中に」および「上に（ｏｎ）」を含む。

説明のための論理システムアーキテクチャおよびシステムフロー
図１は、少なくとも１つの実施形態に係るジオロケーションイベント処理および分析のためのシステム１０の論理アーキテクチャである。各種実施形態のうちの少なくとも１つにおいて、イングレスサーバシステム１００は、ストリーム処理サーバシステム２００および分析サーバシステム５００と通信するように配置することができる。ストリーム処理サーバシステム２００は、エグレスサーバシステム４００および分析サーバシステム５００と通信するように配置することができる。

エグレスサーバシステム４００は、データ消費者と通信し、データ出力をデータ消費者に提供するように構成することができる。エグレスサーバシステム４００はまた、ストリーム処理サーバシステム２００と通信するように構成することができる。

分析サーバシステム５００は、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、およびエグレスサーバシステム４００と通信し、これらのシステムからのデータを受け入れるように構成される。分析サーバシステム５００は、ポータルサーバシステム６００と通信し、データをポータルサーバシステム６００に出力するように構成される。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００の各々は、１つ以上のコンピュータまたはサーバとすることができる。少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００のうちの１つ以上を、単一のコンピュータ上で、たとえばネットワークサーバコンピュータ上で、または、複数のコンピュータにまたがって動作するように構成することができる。たとえば、少なくとも１つの実施形態において、システム１０を、アマゾンウェブサービス（登録商標）（ＡＷＳ：Amazon Web Services）またはマイクロソフト（登録商標）アジュール（Microsoft Azure）等のウェブサービスプラットフォームホスト上で実行するように構成することができる。ある具体例としての実施形態において、このシステムは、本明細書に記載のデータ処理を実行するように構成することができるスパークストリーミングサーバを使用するＡＷＳプラットフォーム上に構成される。ある実施形態において、このシステムを、高スループットメッセージングサーバ、たとえばＡｐａｃｈｅ Ｋａｆｋａ（アパッチカフカ）を使用するように構成することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００を、サービスが提供するＡＰＩのまたは他の通信インターフェイスを使用して統合および／または通信するように構成することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００は、ホスティングサーバ上でホストすることができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、およびポータルサーバシステム６００を、ワイドアクセスネットワーク（ＷＡＮ：Wide Access Networks）またはローカルアクセスネットワーク（ＬＡＮ：Local Access Networks）を含む１つ以上の直接ネットワーク経路を用い、ネットワークを介して、クライアントコンピュータと直接的または間接的に通信するように構成することができる。

システム１０のアーキテクチャはある実施形態の少なくとも一部を例示する非限定的な例であることを、当業者は理解するであろう。そのため、より多くのまたは少ない構成要素を、本明細書に記載のイノベーションの範囲から逸脱することなく、異なる方法で採用および／または配置することができる。しかしながら、システム１０は、少なくとも本明細書でクレームされる発明を開示するのに十分である。

図２を参照すると、少なくとも１つの実施形態に従う、データおよびデータスループットを取り込むためのイングレスサーバシステム１００の論理アーキテクチャが示されている。少なくとも１つの実施形態において、１つ以上のイベントソースからのイベントを決定することができる。ある実施形態において、図１に示されるように、イベントソースは、車両センサデータソース１２、ＯＥＭ車両センサデータソース１４、アプリケーションデータソースｌ６、テレマティクスデータソース２０、ワイヤレスインフラストラクチャデータソース１７、および第三者データソース１５などを含み得る。少なくとも１つの実施形態において、決定したイベントは、ストリーム処理サーバシステム２００および分析サーバシステム５００等のシステムの下流コンポーネントが管理することができる、ロケーションデータ、車両センサデータ、さまざまなユーザとの対話、表示操作、印象などに対応し得る。少なくとも１つの実施形態において、イングレスサーバシステム１００は、図１～図２に示されるイベントソースよりも多いまたは少ないイベントソースからの受信が可能である。

少なくとも１つの実施形態において、１つ以上のイベントソースから受信および／または決定することができるイベントは、１つ以上のデータソースからの、たとえばＧＰＳデバイスからの車両イベントデータ、または、ＯＥＭ車両センサデータソース１４等の第三者データソース１５から提供されるロケーションデータテーブルを含む。車両イベントデータは、データベースフォーマットで、たとえばＪＳＯＮ、ＣＳＶ、およびＸＭＬで取り込むことができる。車両イベントデータは、サービスおよび／またはイングレスサーバシステム１００から提供されるＡＰＩまたは他の通信インターフェイスを介して取り込むことができる。たとえば、イングレスサーバシステム１００はイングレスサーバＡＰＩ１０６と統合されたＡＰＩゲートウェイ１０２インターフェイスを提供することができ、これは、車両イベントソース１４から提供されるデータベースに関連付けることができる各種イベントをイングレスサーバシステム１００が決定できるようにする。ある具体例としてのＡＰＩゲートウェイは、たとえばＡＷＳ ＡＰＩゲートウェイを含み得る。イングレスサーバシステム１００システムのための具体例としてのホスティングプラットフォームは、ＫｕｂｅｒｎｅｔｅｓおよびＤｏｃｋｅｒを含み得るが、他のプラットフォームおよびネットワークコンピュータ構成も同様に採用することができる。

少なくとも１つの実施形態において、イングレスサーバシステム１００は、生データを受け入れるように構成されたサーバ１０４、たとえば、セキュアファイル転送プロトコルサーバ（ＳＦＴＰ：Secure File Transfer Protocol Server）を含み、ＡＰＩまたは他のデータ入力を、車両イベントデータを受け入れるように構成することができる。イングレスサーバシステム１００を、たとえば分析サーバシステム５００によるさらなる分析のために生データをデータストア１０７に格納するように構成することができる。イベントデータは、イグニッションオン、タイムスタンプ（Ｔ１…ＴＮ）、イグニッションオフ、興味あるイベントデータ、緯度および経度、ならびに車両情報番号（ＶＩＮ：Vehicle Information Number）情報を含み得る。具体例としてのイベントデータは、当技術において周知のソースからの、たとえば車両自体からの（たとえばＧＰＳ、ＡＰＩを介した）、または、第三者データソース１５から提供されたロケーションデータのテーブルからの、車両移動データを含み得る。

ある実施形態において、イングレスサーバシステム１００は、イベントデータを処理して車両移動データを導き出す、たとえば、速度、継続時間、および加速度を導き出すように構成される。たとえば、ある実施形態において、ｘ秒（たとえば３秒）ごとにイベントデータベース上でスナップショットが撮影される。次に、緯度／経度データおよび時間データを処理し、車両の位置および時間を使用して、速度および加速度等の車両追跡データを導き出すことができる。

ある実施形態において、イングレスサーバシステム１００は、デバイスおよび第三者プラットフォームからのデータを受け入れるように構成される。イングレスサーバＡＰＩ１０６を、システム１０に対し、デバイスまたは第三者プラットフォームおよびプラットフォームホストを認証するように構成することができる。

したがって、ある実施形態において、イングレスサーバシステム１００は、生データを受信し、生データのデータ品質チェックおよびスキーマ評価を実行するように構成される。生データを取り込んで検証することは、図７のブロック７０１に示される、システムの品質チェックのデータ品質パイプラインのスタートである。表１は、システムが受信できる生データの一例を示す。

別の実施形態において、イングレスソースからの車両イベントデータに含まれる情報は、より少なくてもよい。たとえば、表２に示されるように、生の車両イベントデータは、限られた数の属性を、たとえばロケーションデータ（経度および緯度）と時間データ（タイムスタンプ）とを含み得る。

本開示の実施形態の具体例としてのある利点は、存在しない情報を、本明細書に記載の革新的なアルゴリズムから導き出すことができる点である。たとえば、車両イベントデータは、行程の特定を含まない場合がある、または不正確な行程の特定を有する場合がある。したがって、システムを、最初に受信したデータが限定された属性を有する場合は追加の車両イベント属性データを導き出すように構成することができる。たとえば、システムを、受信した車両イベントデータについて特定の車両を識別して車両ＩＤを追加するように構成することができる。そうすることで、システムは、たとえば、車両ＩＤに関連付けられたロケーションおよびタイムスタンプデータのみを使用し、発進と停止、速度、進行方向、加速度、および他の属性を含めて、車両の移動を追跡することができる。

ある実施形態では、ブロック７０２において、受信したデータは、外部から定義されたスキーマ、たとえばＡｖｒｏまたはＪＳＯＮに準拠していてもよい。このデータは内部スキーマに変換して検証することができる。ある実施形態において、イベントデータを、データ品質パイプラインによるダウンストリーム処理のためにメッセージングシステムに渡される前に、合意されたスキーマ定義と照らし合わせて検証することができる。たとえば、Ａｐａｃｈｅ Ｋａｆｋａメッセージングシステムに検証済みデータを渡す前に、Ａｐａｃｈｅ Ａｖｒｏスキーマ定義を使用することができる。別の実施形態において、生の移動およびイベントデータは、クライアントノードクラスタ構成によって処理することもでき、この場合、各クライアントは消費者または生産者であり、インスタンス内のクラスタはそれらの間でデータを複製することができる。

たとえば、イングレスサーバシステム１００を、パルサークラスタのＡｐａｃｈｅパルサーエンドポイントに接続されたパルサークライアントで構成することができる。ある実施形態において、Ａｐａｃｈｅパルサーエンドポイントは、読み出された最後のデータ読み出しを追跡し、Ａｐａｃｈｅパルサークライアントを、読み出された最後のデータからピックアップするためにいつでも接続できるようにする。パルサーにおいて、「標準」消費者インターフェイスは、「消費者」クライアントを使用して、トピックをリッスンし、着信メッセージを処理し、メッセージが処理されたときにそれらのメッセージを最後に確認応答することを含む。トピックのカーソルはパルサーブローカーモジュールによって自動管理されるので、クライアントは、トピックに接続するときは常に、最も早い確認応答されていないメッセージ以降の読み取りを自動的に開始する。しかしながら、このクライアントのためのクライアントリーダーインタフェースは、クライアントアプリケーションがトピックカーソルをビスポーク方式で管理できるようにする。たとえば、パルサークライアントリーダーを、トピックに接続し、トピックに接続したときからリーダーが読み取りを開始したのはどのメッセージかを指定するように、構成することができる。トピックに接続するとき、リーダーインターフェイスは、クライアントが、トピック内の最も早い利用可能メッセージから、または、トピック内の最新の利用可能メッセージから開始することを可能にする。クライアントリーダーを、たとえばメッセージＩＤを使用して永続データストアまたはキャッシュからメッセージをフェッチすることにより、最も早いメッセージと最新のメッセージとの間の何らかの他のメッセージから開始するように構成することもできる。

少なくとも１つの実施形態において、イングレスサーバシステム１００は、データをクリーンにし検証するように構成される。たとえば、イングレスサーバシステム１００を、取り込まれた車両イベントおよびロケーションデータを検証し、検証したロケーションデータをサーバキュー１０８に、たとえばＡｐａｃｈｅ Ｋａｆｋａキュー１０８に渡すように構成されたイングレスサーバＡＰＩ１０６を含むように構成することができ、上記データはストリーム処理サーバシステム２００に出力される。サーバ１０４を、検証された受信ロケーションデータをデータストア１０７に出力するように構成することもできる。また、イングレスサーバシステム１００を、無効データをデータストア１０７に渡すように構成することができる。たとえば、無効ペイロードをデータストア１０７に格納することができる。具体例としての無効データは、たとえば、不良フィールドもしくは認識されないフィールド、または同一のイベントを有するデータを含み得る。イングレスサーバシステム１００を、たとえばシステム性能を改善するために、格納された無効データを出力するように、または格納されたデータを分析のためにデータストア１０７から分析サーバシステム５００に引き出すことができるように構成することができる。たとえば、分析サーバシステム５００を、認識されていないフィールドを有する無効データのデータベースを分析し検証済み処理のためにフィールドを新たに識別しラベル付けするように構成された診断機械学習を用いて構成することができる。イングレスサーバシステム１００を、分析サーバシステム５００による処理のために、たとえば本明細書に記載の行程分析のために、格納された受信ロケーションデータを渡すように構成することもできる。

本明細書に記載されるように、システム１０は、ストリーミングコンテキストおよびバッチコンテキストの両方でデータを処理するように構成される。ストリーミングコンテキストでは、低レイテンシが完全性よりも重要である、すなわち古いデータを処理する必要はなく、実際、古いデータを処理することは、より最近のデータの処理を遅らせる可能性があるため、有害な影響を与える可能性がある。バッチコンテキストでは、データの完全性が低レイテンシよりも重要である。したがって、これらの２つのコンテキストにおけるデータの処理を容易にするために、ある実施形態において、システムは、すべてのデータを利用になると直ちに受信するストリーミング接続をデフォルトとすることができるが、古いデータをスキップするように構成することもできる。バッチプロセッサを、古いデータを原因とする、ストリーミングプロセッサが残した任意のギャップを埋めるように構成してもよい。

図３は、少なくとも１つの実施形態に係る、データスループットおよび分析のためのストリーム処理サーバシステム２００の論理アーキテクチャである。本明細書に記載のストリーム処理は、毎秒少なくとも２００ｋ～６００ｋレコードの線形スケーリングにおけるスループットの改善を含むシステム処理の改善をもたらす。改善はさらに、２０秒のエンドツーエンドシステム処理を含み、システムレイテンシのさらなる改善が進行中である。少なくとも１つの実施形態において、システムを、マイクロバッチ処理のためのサーバを使用するように構成することができる。たとえば、本明細書に記載のように、少なくとも１つの実施形態において、ストリーム処理サーバシステム２００を、Ａｐａｃｈｅ Ｋａｆｋａ等の高スループットメッセージングサーバおよびスパークストリーミングサーバを使用するＡＷＳ等のウェブサービスプラットフォームホスト上で実行されるように構成することができる。ある実施形態において、ストリーム処理サーバシステム２００は、データ処理サーバからの処理済みデータを入力するように構成することができる、デバイス管理サーバ２０７、たとえばＡＷＳイグナイトを含み得る。デバイス管理サーバ２０７を、外部に提供またはインターフェイスできる、個々の車両データ分析のために匿名化されたデータを使用するように構成することができる。システム１０を、リアルタイムでデータを出力するように、かつ、将来の分析のために１つ以上のデータストアにデータを格納するように、構成することができる。たとえば、ストリーム処理サーバシステム２００を、インターフェイスを介して、たとえばＡｐａｃｈｅ Ｋａｆｋａを介してリアルタイムデータをエグレスサーバシステム４００に出力するように構成することができる。ストリーム処理サーバシステム２００を、リアルタイムデータおよびバッチデータの両方をデータストア１０７に格納するように構成することもできる。さらなる分析のために、データストア１０７内のデータにアクセスする、またはこのデータをインサイト（insight）サーバシステム５００に与えることができる。

少なくとも１つの実施形態において、イベント情報は、後の処理および／または分析のために、１つ以上のデータストア１０７に格納することができる。同様に、少なくとも１つの実施形態において、イベントデータおよび情報は、決定または受信されると処理されてもよい。また、イベントペイロードおよびプロセス情報を、履歴情報および／または比較情報としての使用のため、ならびにさらなる処理のために、データストア１０７等のデータストアに格納することができる。

少なくとも１つの実施形態において、ストリーム処理サーバシステム２００は、車両イベントデータ処理を実行するように構成される。

図３は、少なくとも１つの実施形態に係る、ストリーム処理サーバシステム２００の論理アーキテクチャおよびフローチャート概要を示す。ブロック２０２において、ストリーム処理サーバシステム２００は、受信したロケーション２０１からのロケーションイベントデータの検証を実行する。適切にフォーマットされていない、重複する、または認識されないデータは、フィルタリングによって取り除かれる。具体例としての無効データは、たとえば、不良フィールド、認識されないフィールドを有するデータ、または同一イベント（重複）、または同じ場所および時間において発生するエンジンオン／エンジンオフデータポイントを含み得る。また、検証は、予め定められた期間、たとえば７秒より古いイベントデータを破棄するレイテンシチェックを含む。ある実施形態において、たとえば、４秒と１５秒の間の他のレイテンシフィルタを使用することができる。

ある実施形態において、図７のブロック７０３に示されるように、ストリーム処理サーバシステム２００は、属性範囲フィルタリングを実行するように構成される。属性範囲フィルタリングは、イベントデータ属性が、このデータにとって重要な、データの予め定められた範囲に含まれることを保証するために、チェックする。たとえば、進行方向属性を、円（０→３５９）と定める。ｓｑｕｉｓｈ－ｖｉｎは９～１０文字のＶＩＮである。例は、データプロバイダによって予め定義されたまたは標準によって設定されたデータを含む。これらの範囲にないデータ値は、データが属性について本質的に不良であることを示す。非適合データをチェックし、フィルタリングして取り除くことができる。属性範囲フィルタリングの一例を表３に示す。

ある実施形態において、ブロック７０４において、システムは、属性値フィルタリングを実行するように構成される。属性値フィルタリングは、属性値が内部で設定されたことまたはビスポーク規定範囲であることを保証するために、チェックする。たとえば、１９７０という日付は、イベントの日付属性に対する属性範囲フィルタチェックに合格することができるが、その日付は車両追跡データにとっては妥当なデータではない。したがって、属性値フィルタリングは、チェックしフィルタリングすることができる、予め定められた時間よりも古い、たとえば６週間以上前のデータをフィルタリングするように構成される。属性範囲フィルタリングの一例を表３に示す。

ブロック７０５において、システムは、レコード内の属性についてさらに検証を行い、レコードデータポイントの属性間の関係がコヒーレントであることを確認することができる。たとえば、非ゼロトリップ開始イベントは、本明細書に記載の行程決定にとっては論理的な意味をなさない。したがって、表４に示されるように、システム１０を、「トリップ開始」または行程のイグニッションオンもしくは開始イベントとしての、ロケーションの捕捉タイムスタンプおよび受信タイムスタンプの同一属性に対して記録された、非ゼロ速度イベントをフィルタリングするように構成することができる。

図２に戻ると、ブロック２０４において、少なくとも１つの実施形態において、ストリーム処理サーバ２００は、ロケーションイベントデータのジオハッシュを実行する。Ｕｂｅｒ（商標）が使用するＨ３アルゴリズムまたはＧｏｏｇｌｅ（商標）が使用するＳ２アルゴリズム等の、ジオハッシュに代わるものを利用できるが、ジオハッシュは、システム１０に、具体例としての改善、たとえばシステムレイテンシおよびスループットの改善をもたらすことが見出された。また、ジオハッシュは、システム１０の精度および車両検出におけるデータベースの改善をもたらした。たとえば、９文字の精度のジオハッシュを使用することにより、車両をジオハッシュに一意に関連付けることができる。そのような精度は、本明細書に記載の行程決定アルゴリズムに用いることができる。少なくとも１つの実施形態において、イベントデータ内のロケーションデータは近接度に符号化され、符号化は、各イベントの緯度および経度を各イベントの近接度にジオハッシュすることを含む。イベントデータは、時間、位置（緯度／経度）、および興味のあるイベントデータを含む。興味のあるイベントデータは、急ブレーキおよび急な加速を含み得る。たとえば、急ブレーキは、予め定められた時間内の減速（たとえばｘ秒間で４０－０）であると定義することができ、急な加速は、予め定められた時間内の加速（たとえばｘ秒間で４０－８０ｍｐｈ）であると定義される。興味のあるイベントデータは、他のアルゴリズムにおける使用のために相関させて処理することができる。たとえば、時空間クラスタにロケーションマッピングされた急ブレーキのクラスタを、混雑検出アルゴリズムとして用いることができる。

ジオハッシュアルゴリズムは、イベントデータからの緯度および経度（緯度／経度）データをｎ文字の短いストリングに符号化する。ある実施形態において、ジオハッシュされた緯度／経度データは、ある形状にジオハッシュされる。たとえば、ある実施形態において、緯度／経度データは、そのエッジがストリング内の文字に比例する矩形にジオハッシュすることができる。ある実施形態において、ジオハッシュは、４～９文字に符号化することができる。

いくつかの利点が、本明細書に記載のジオハッシュされたイベントデータを使用するによって得られる。たとえば、データベースにおいて、ジオハッシュでインデックスされたデータは、所定の矩形エリアのすべてのポイントを連続するスライス内に有し、この場合のスライスの数は、符号化のジオハッシュ精度によって決まる。これは、複数インデックスクエリよりも遥かに簡単で高速である単一インデックスに対するクエリを可能にすることにより、データベースを改善する。また、ジオハッシュインデックス構造は、最も近いポイントが最も近いジオハッシュの中にあることが多いので、合理化された近接検索にも役立つ。

ブロック２０６において、少なくとも１つの実施形態において、ストリーム処理サーバシステム２００は、ロケーションルックアップを実行する。先に述べたように、ある実施形態において、システムを、ジオハッシュを符号化することで、定められた地理的エリア、たとえば、国、州、またはジップコードを特定するように構成することができる。システムは、緯度／経度を、そのエッジがストリング内の文字に比例する矩形にジオハッシュすることができる。

たとえば、ある実施形態において、ジオハッシュを５文字に符号化するように、ジオハッシュを構成することができ、州を５文字のジオハッシュされたロケーションで特定するように、システムを構成することができる。たとえば、５つのスライスまたは文字という精度で符号化されたジオハッシュは、＋／－２．５キロメートルの精度であり、これは州を特定するのに十分である。６文字へのジオハッシュは、ジップコードにジオハッシュされたロケーションを特定するために使用することができ、これは＋／－０．６１キロメートルの精度である。４文字へのジオハッシュは国を特定するために使用することができる。ある実施形態において、システム１０を、ジオハッシュを符号化して、ジオハッシュされたロケーションで車両を一意に特定するように構成することができる。ある実施形態において、システム１０を、ジオハッシュを９文字に符号化して車両を一意に特定するように構成することができる。

ある実施形態において、システム１０をさらに、ジオハッシュされたイベントデータマップデータベースにマッピングするように構成することができる。マップデータベースは、たとえばパブリックまたはプロプライエタリマップデータベースを含む、興味あるポイントのデータベースまたは他のマップデータベースとすることができる。具体例としてのマップデータベースは、ローカルストリートマップ用のジオファブリック（Ｇｅｏｆａｂｒｉｃ）またはワールドマップデータベース等の現存ストリートマップデータを含み得る。本明細書に記載のジオハッシュの使用の、具体例としての利点は、ダウンストリームで処理されるときの車両イベントデータをより高速かつ低レイテンシで充実させることを可能にする点である。たとえば、地理的定義、マップデータ、および他の充実化は、ジオハッシュされたロケーションおよび車両ＩＤに容易にマッピングされる。また、フィードデータを、集約されたデータセットに組み込み、インターフェイスを用いて、たとえばＧＩＳ可視化ツール（たとえばＭａｐｂｏｘ、ＣＡＲＴＯ、ＡｒｃＧＩＳ、もしくはＧｏｏｇｌｅ（登録商標） Ｍａｐｓ ＡＰＩ）または他のインターフェイスを用いて、可視化することで、グラフィック報告を生成およびインターフェイスすることができる、または、アナリティックスインサイトを生成するために処理されたデータを使用して、たとえばエグレスサーバシステム４００またはポータルサーバシステム６００を介して第三者１５に報告を出力することができる。

少なくとも１つの実施形態において、ブロック２０８において、ストリームプロセッササーバシステム２００を、たとえば、イベントデータ内の車両データの車両識別番号（ＶＩＮ：Vehicle Identification Number）から個人識別情報を削除するまたはこれを不明瞭にすることによって識別情報を削除するために、データを匿名化するように構成することができる。各種実施形態において、イベントデータまたは他のデータはＶＩＮ番号を含むことができ、ＶＩＮ番号は、製造、モデル、および年等の、車両の製品情報を表す番号を含み、また、車両を一意に特定する文字を含み、所有者に対して個人的に特定するために使用することができる。システム１０は、たとえば、車両データから車両を一意に特定するＶＩＮ内の文字は削除するが他の識別シリアル番号（たとえば、製造、モデル、および年の番号）は残すアルゴリズム、たとえばＳｑｕｉｓｈ Ｖｉｎアルゴリズムを含み得る。ある実施形態において、システム１０を、匿名化されたデータに固有の車両タグを追加するように構成することができる。たとえば、システム１０を、固有の番号、文字、または他の識別情報を匿名化されたデータに追加するように構成することができ、それにより、固有の車両に関するイベントデータを、ＶＩＮに関連する個人識別情報が削除された後に、追跡、処理、および分析することができる。匿名化されたデータの具体例としての利点は、匿名化されたデータが、処理済みイベントデータを外部提供できるようにしつつ、たとえば法的に要求されるかまたはユーザが望む場合もある、データの個人識別情報の保護を可能にする点である。

少なくとも１つの実施形態において、本明細書に記載のように、９文字へのジオハッシュは、ＶＩＮデータ等の個人特定情報を取得または必要とせずに、車両の一意の識別を提供することも可能である。車両を、データベースイベントデータの処理によって識別し、固有の車両を特定するのに十分な精度で、たとえば９文字の精度でジオハッシュすることができ、そうすると、本明細書に記載のように、車両を識別し、追跡し、そのデータを処理することができる。

先に述べたように、リアルタイムストリーミングの場合、ブロック２０２において、データ検証は、過剰レイテンシ、たとえば７秒を超えるレイテンシのデータをフィルタリングによって除去する。しかしながら、バッチデータ処理は、ギャップなしの完全なデータセットで実行することができ、したがって、レイテンシのためにフィルタリングされないデータを含むことができる。たとえば、図５に関して説明する分析のためのバッチデータプロセスは、最大で６週前までのデータを受け入れるように構成することができるが、ストリーム処理サーバシステム２００のストリーミングスタックは、７秒前よりも古いデータをフィルタリングするように構成され、したがって、ブロック２０２におけるレイテンシ検証チェックを含み、より高レイテンシのイベントを拒否する。

ある実施形態において、ブロック２１２において、レイテンシのためにフィルタリングされた変換済みロケーションデータと拒否されたレイテンシデータの両方が、サーバ待ち行列、たとえば、Ａｐａｃｈｅ Ｋａｆｋａ待ち行列に入力される。ブロック２１４において、ストリーム処理サーバシステム２００は、データを、フルデータ２１６を含む、すなわちレイテンシのためにフィルタリングされた変換済みロケーションデータおよび拒否されたレイテンシデータを含むデータセットと、変換済みロケーションデータ２２２の別のデータセットとに、分割することができる。フルデータ２１６は、アクセスのためまたは分析サーバシステム５００への送信のためにデータストア１０７に格納され、フィルタリングされた変換済みロケーションデータは、エグレスサーバシステム４００に送信される。別の実施形態において、拒否されたデータを含むフルデータセットまたはその一部を、第三者プラットフォームのためのエグレスサーバシステム４００に、それ自身による使用および分析のために送信することもできる。そのような実施形態において、ブロック２１３において、レイテンシのためにフィルタリングされた変換済みロケーションデータと、拒否されたレイテンシデータとを、直接、エグレスサーバシステム４００に提供することができる。

図４は、エグレスサーバシステム４００の論理アーキテクチャである。少なくとも１つの実施形態において、エグレスサーバシステム４００は、レコードを取り込み、処理し、イベントデータを出力するように配置された１つ以上のコンピュータとすることができる。エグレスサーバシステム４００を、プッシュまたはプルベースでデータを提供するように構成することができる。たとえば、ある実施形態において、システム１０を、Ａｐａｃｈｅ Ｓｐａｒｋクラスタからのプッシュサーバ４１０を使用するように構成することができる。プッシュサーバを、たとえばレイテンシフィルタリング４１１、ジオフィルタリング４１２、イベントフィルタリング４１３、変換４１４、および送信４１５のために、ストリームプロセスサーバシステム２００からの変換されたロケーションデータを処理するように構成することができる。本明細書に記載されるように、ジオハッシュは、システム１０のスループットレイテンシを大幅に改善し、これは、たとえば数分以内、さらには数秒以内に、イベントに近接して処理されたデータに対する適時プッシュ通知を行うという利点を可能にする。たとえば、ある実施形態において、システム１０は、６０秒未満のレイテンシを目標とするように構成される。先に述べたように、ストリーム処理サーバシステム２００は、７秒未満のレイテンシのイベントをフィルタリングするように構成され、スループットも改善する。ある実施形態において、プルデータのためのデータストア４０６を、ＡＰＩゲートウェイ４０４を介して提供することができ、プルＡＰＩ４０５は、どの第三者１５ユーザがデータをプルしているかおよびユーザが要求しているのはどのデータかを追跡することができる。

たとえば、ある実施形態において、エグレスサーバシステム４００は、システム１０によって提供されるフィルタに基づいてパターンデータを提供することができる。たとえば、システムを、特定の１つまたは複数のロケーションについてのイベントデータをフィルタリングするためにジオフェンスフィルタ４１２を提供するように構成することができる。ジオフェンスを、多数のパターンおよび構成のために本明細書に記載の行程およびイベントデータを境界設定および処理するように構成することができることが、理解されるであろう。たとえば、ある実施形態において、エグレスサーバシステム４００を、ユーザが提供または選択した経度／緯度内での行程の開始および終了（イグニッションキーオン／オフイベント）にデータを制限するように構成された「パーキング」フィルタを提供するように構成することができる。このデータのさらに他のフィルタまたは例外を、たとえば州（州コードまたは緯度／経度）によって構成することができる。また、システム１０を、「トラフィック」フィルタを用いて構成することで、たとえば特定の州および経度／緯度バウンディングボックスをフィルタから除外して、トラフィックパターンデータを提供することもできる。

図５は、データアナリティックスおよびインサイトのための分析サーバシステム５００の論理アーキテクチャを表す。少なくとも１つの実施形態において、分析サーバシステム５００は、イベントデータを分析するように配置された１つ以上のコンピュータとすることができる。リアルタイムデータおよびバッチデータの両方を、本明細書に記載の他のコンポーネントから、処理のために分析サーバシステム５００に送ることができる。ある実施形態において、バッチおよびストリーミングデータ処理を組み合わせる、Ａｐａｃｈｅ Ｓｐａｒｋクラスタ等のクラスタコンピューティングフレームワークおよびバッチプロセッサが、分析サーバシステム５００によって採用されてもよい。分析サーバシステム５００に提供されるデータは、たとえばイングレスサーバシステム１００、ストリーム処理サーバシステム２００、およびエグレスサーバシステム４００からのデータを含み得る。

ある実施形態において、分析サーバシステム５００を、データストア１０７等のデータストアに格納することができる車両イベントペイロードおよび処理済みの情報を受け入れるように構成することができる。図５に示されるように、ストレージは、エグレスサーバシステム４００からのリアルタイムのエグレスデータ、ストリーム処理サーバシステム２００からの変換されたロケーションデータおよび拒否データ、ならびにイングレスサーバシステム１００からのバッチおよびリアルタイムの生データを含む。図２に示されるように、データストア１０７に格納された受信ロケーションは、分析サーバシステム５００に出力またはプルすることができる。分析サーバシステム５００を、図２に示されるストリームプロセッササーバシステム２００と同じ方法で、受信したロケーションデータを処理するように構成することができる。先に述べたように、ストリーム処理サーバシステム２００を、フルデータ（レイテンシのためにフィルタリングされた変換済みロケーションデータおよび拒否されたレイテンシデータ）を含むフルデータセット２１６と、変換されたロケーションデータ２２２のデータセットとに、データを分割するように構成することができる。フルデータセット２１６は、アクセスのためおよび分析サーバシステム５００への送信のためにデータストア１０７に格納され、フィルタリングされた変換済のロケーションデータは、エグレスサーバシステム４００に送信される。図５に示されるように、リアルタイムのフィルタリングされたデータを、パフォーマンス５２２、イングレス対エグレス５２４、動作モニタリング５２６、およびアラート５２８の報告を含む、準リアルタイムでの報告のために、処理することができる。

したがって、図５のブロック５０２において、少なくとも１つの実施形態において、分析処理サーバシステム５００を、図２のブロック２０２および図７のブロック７０１～７０５で示されるのと同じ方法で、受信したロケーションから生のロケーションイベントデータの検証を任意で実行するように構成することができる。ある実施形態において、図７に示されるように、ブロック７０６において、システム１０は、レコードのバッチ処理を用いて、複数のイベントレコードの属性に対するさらなる検証を実施し、イベントデータポイントの属性間のレコード内関係が意味のあるものであることを確認することができる。たとえば、表５に示されるように、システム１０を、行程のイベントの論理的順序付け（たとえばある行程の行程イベントは「トリップ開始－トリップ終了－トリップ開始」のように交互に起こるものであって「トリップ開始－トリップ開始－トリップ終了－トリップ終了」という繰り返しではない）を確実にするために分析されたデータポイントを分析するように構成することができる。

図５のブロック５０４に戻ると、少なくとも１つの実施形態において、分析サーバシステム５００は、任意で、図２のブロック２０４に示されるように、ロケーションイベントデータのジオハッシュを実行するように構成されてもよい。図５のブロック５０６において、分析サーバシステム５００は、任意で、ロケーションルックアップを実行してもよい。図５のブロック５０８において、分析サーバシステム５００を、図２のブロック２０６および２０８に示されるデバイス匿名化を任意で実行するように構成されてもよい。

ブロック５１０において、少なくとも１つの実施形態において、分析サーバシステム５００は、イベントデータの行程セグメント分析を実行する。ある実施形態において、システム１０は、イベントデータから、車両の行程を特定するように構成され、これは、特定の車両のルートまたは移動が行程の目的地への運転を目的とするものか否かを特定することを含み、行程を特定することは、車両のエンジンオンまたは最初の移動を特定することと、車両のエンジンオフまたは移動停止を特定することと、車両の滞留時間を特定することと、最短走行継続時間を特定することとを含む。

少なくとも１つの実施形態において、行程は、出発地から最終目的地までの１つ以上の行程セグメントを含み得る。１つの行程セグメントは、車両のエンジンオン／移動開始イベントとエンジンオフ／移動停止イベントとの間の走行距離および走行継続時間を含む。

しかしながら、実際の運転者は、目的地までの走行時に１回以上停止する可能性がある。行程は、複数回の停止を伴うトリップの場合のように、２つ以上の行程セグメントを有し得る。たとえば、運転者は、自宅から仕事のために走行するときに燃料のために停止する、または信号で停止する必要がある可能性がある。そのため、車両イベントの分析における問題および課題は、本明細書に記載の実施形態のための正確な車両追跡の開発を含む。他の行程アルゴリズムまたはプロセスが当該技術で用いられており、たとえば、識別された車両の既知の目的地からの行程の逆行技術があるが、本開示は、データ分析、データベース、インターフェイス、データ処理、および他の技術的製品を含む、本明細書に記載の技術を使用するアグノスティック（agnostic）な車両追跡のために開発され有利に実現された実施形態およびアルゴリズムを含む。

ブロック５１２において、分析サーバ５００は、イベント情報から行程を認定する（qualify）ための計算を実行するように構成される。ある実施形態において、システム１０は、継続時間基準、距離基準、および滞留時間基準を含む行程検出基準で構成される。少なくとも１つの実施形態において、継続時間基準は最短継続時間基準を含み、システムが行程セグメントを行程内の行程セグメントに含めるには最短走行継続時間が必要である。エンジンオンまたは移動開始後の最短走行継続時間は、たとえば、約６０～約９０秒の走行継続時間を含み得る。具体例としてのある実施形態において、システム１０を、ある車両走行を行程セグメントとして含めるためには６０秒を超える車両走行を必要とするように構成することができる。たとえば、（１）エンジンオン／イグニッション、または（２）（たとえば前のトリップまたは行程の）わかっている最後の移動後の、識別された車両の最初の移動、または（３）新たに識別された車両の最初の移動が、車両について識別され、続いて６０秒未満の短い走行継続時間があった場合、システム１０は、この行程セグメントを行程の判断から除外するように構成される。システム１０は、車両の短い移動継続時間は行程の開始でも目的地でもないと判断するように構成される。

ある実施形態において、行程検出基準は、たとえば２００メートル等の走行距離基準を含む。システム１０を、行程セグメントから２００メートル以下の距離を除外するように構成することができる。最短走行距離基準は、たとえば約１００メートル～約３００メートルの走行距離の予め定められた継続時間を含み得る。最短距離ｘ（たとえば２００メートル）は、最短距離ｘの約５０％の許容誤差を含む指標であると定義することができる。

ある実施形態において、滞留時間基準は、車両の停止時間を含み得る。たとえば、滞留時間基準は、約３０～約９０秒であってもよい。最大滞留時間は、同じ車両のエンジンオフ／移動停止とエンジンオン／移動開始との間の停止継続時間、たとえば約２０～約１２０秒を含み得る。たとえば、システム１０は、車両が停止しているまたはそのエンジンが３０秒未満にわたってオフにされていると判断した場合、その停止期間を行程の終了としてまたは行程オブジェクトの中に含めないように構成することができる。

先に述べたように、ある実施形態において、システム１０は、車両イベントデータを処理して、１つ以上の行程セグメントが車両の行程を含むか否かを判断するように構成される。たとえば、エンジンオンまたは移動開始イベントに続いて、距離基準を超える距離（たとえば２００メートルを超える距離）が生じることがある。そのため、システムの継続時間基準は、行程のセグメントを識別しない。しかしながら、車がその後停止し３０秒を超えて静置し続ける場合、システム１０は、行程のセグメントとしてこれをカウントしないように構成される。車両がその後３０秒未満停止し、その後再び移動する場合は、滞留時間基準が満たされ、システム１０は、この行程セグメントを、車両が最終目的地まで走行する行程に含めるように構成される。したがって、このアルゴリズムは、たとえば運転者が自宅で車をオンにし（エンジンオン／移動開始）、１０マイル（距離基準）運転し、信号機で２９秒停止し、仕事の最終目的地まで走行した（エンジンオフ／移動停止）ときに、毎日のリアルタイムの目的地への運転の行程または行程オブジェクトの複数の行程セグメントを結合することができる。しかしながら、システム１０は、行程における中断を表す可能性が低いイベント、たとえば停止信号での２９秒間の停止（滞留基準）または２００メートル未満の移動（距離基準）または６０秒未満の移動（継続時間基準）を無視するように構成される。

ある実施形態において、システム１０は、たとえば、可変データに基づく、滞留基準、距離基準、または時間基準の各々についての複数の基準を含み得る。そのため、アルゴリズムは、車両およびロケーションに関する追加データが既知である、目的地までの共通のリアルタイムの運転の、複数の行程セグメントを、結合することができる。たとえば、車両が電気自動車等の道路法上の電動車両として識別される場合、滞留基準は、充電ステーションとして識別されるロケーションにおける２０分の最大滞留時間基準を含み得る。そのため、滞留時間は、たとえば、このロケーションに関する他のデータに基づいて、最大２～２０分間延長することができる（たとえば、停止を示すデータは、ガソリンスタンド、パーキングエリア、またはレストラン等の興味のあるポイントである）。システム１０を、電気自動車の運転者が自宅で自動車をオンにし（エンジンオンまたは最初の移動）、充電のために充電ステーションまで１００マイル（距離基準）運転し（エンジンオフ／移動停止、１２分、滞留基準、可変、充電ステーション）、その後再び始動し（エンジンオン／移動開始）セールスミーティングが行われる最終目的地まで走行した（エンジンオフ／移動停止）ときに、行程を特定するように構成することができる。したがって、上記基準のうちの各々を、とりわけ、イベント車両データポイントに関して導き出されたまたは取得された知識に応じて可変となるように構成できることが、理解されるであろう。

ある実施形態において、システム１０は、上記基準に従い、特定のデバイスの行程セグメントの候補チェーンを特定するように構成される。また、複合行程オブジェクトを、その開始をチェーンの開始とし、その終了をチェーン内の最終セグメントの終了として、インスタンス化することができる。行程オブジェクトの別個のテーブルをイベントデータから抽出することができ、導き出された複合行程をさらに他のテーブルに生成することができる。ある実施形態において、すべてのエンジンオン／エンジンオフまたは移動開始／移動停止イベントを含むデータセットは、固有の車両ＩＤと識別される。たとえば、車両のエンジンオン／エンジンオフまたは移動開始／移動停止イベントの各々を、候補行程セグメントを含む単一の行に配置することができる。次にエンジンオン／エンジンオフまたは移動開始／移動停止イベントの行を、距離基準、継続時間基準、および滞留基準の各々によって処理することにより、どの行程セグメントを行程オブジェクトの行程判断に含めるかまたはそこから除外することができるかを、判断することができる。ある実施形態において、システム１０は、さらに他の行程表を生成することができ、この行程表には、上記行程基準を満たす車両のイベントから決定された行程オブジェクトが記入される。

少なくとも１つの実施形態において、ブロック５１４において、システム１０は、車両イベントデータのデータベースを分析し、始動時間、終了時間、始動ロケーション、終了ロケーション、データポイントカウント、平均間隔などのような属性を有する行程オブジェクトへのポイントの行程の要約を分析することにより、能動的な車両検出を提供するように構成される。ある実施形態において、行程オブジェクトは、処理のために別個のデータテーブルに入れることができる。

ある具体例としての実施形態において、システム１０を、車両を（たとえばＶＩＮ番号によって）予め特定することなくこの車両の追跡を実行するように構成することができる。先に述べたように、ジオハッシュをイベントデータのデータベースに対して使用することで、イベントを車両に一意に相関させるのに十分な形状に相当する９文字の精度で、データをジオハッシュすることができる。ある実施形態において、能動的な車両検出は、ある期間にわたる複数のイベントから車両経路を特定することを含む。ある実施形態において、能動的な車両検出は、１日という期間（２４時間）にわたる複数のイベントから車両経路を特定することを含み得る。識別は、たとえば、連結成分アルゴリズム（connected components algorithm）を使用することを含む。ある実施形態において、連結成分アルゴリズムは、車両イベントの日を含む有向グラフにおいて車両経路を特定するために用いられ、グラフにおいて、ノードは車両であり、ノード間の接続は識別された車両経路である。たとえば、行程開始および行程終了のグラフが作成され、この場合、ノードは開始および終了を表し、エッジは車両が辿った行程である。各エッジにおいて、開始および終了が時間でソートされる。エッジは、時間によって順序付けられた、そのノードにおける次の開始に端部を接続するために作成される。ノードは、ＧＰＳ座標の９桁のジオハッシュである。連結成分アルゴリズムは、接続されたノードおよびエッジのセットを発見し、１日の開始時に生成されたデバイスＩＤが、求められたサブグラフに沿って送られて、同じ車両が辿っている行程（エッジ）を一意に特定する。

このアプローチの具体例としての利点は、イベントデータに対して車両を事前に特定する必要をなくしたことである。本明細書に記載の行程基準を満たす車両経路からの行程セグメントを使用して、上記のように行程を検出し認定されない行程イベントを除外することができる。たとえば、車両の移動停止／エンジンオフから移動開始／エンジンオンまでのイベントが相互にｘ秒（３０秒）以内であることを示すイベントデータについて９桁（最高精度）で符号化されたジオハッシュは、行程の同一車両とみなすことができる。一連の到着および出発について、行程は、グラフを通る行程セグメントの最短行程として計算することができる。

少なくとも１つの実施形態において、ブロック５１５において、システム１０を、データウェアハウス５１７内にイベントデータおよび行程判定データを格納するように構成することができる。データはデータベースフォーマットで格納することができる。ある実施形態において、タイムカラムを処理済みデータに追加することができる。ある実施形態において、データベースは、興味のあるポイント（ＰＯＩ：Point of Interest）データを含むこともできる。

分析サーバシステム５００は、データウェアハウス５１７に格納されたデータ、たとえば、スパーク分析クラスタに対してデータ分析を実行する分析サーバコンポーネント５１６を含み得る。分析サーバシステム５００を、評価５３０、クラスタリング５３１、人口統計分析５３２、およびビスポーク分析５３３を実行するように構成することができる。たとえば、ウェアハウス５１７に格納された処理済みの行程データおよびロケーションデータに対するデータに、日付カラムおよび時間カラムを追加することができる。これは、たとえば、日付および時刻によって交差点ｘにどれだけ多くの車両があるかを判断する、ビスポーク分析５３３に使用することができる。また、システム１０を、図４に関して説明したように、エグレスサーバシステム４００におけるビスポーク分析５３３を提供するように構成することもできる。

ある実施形態において、地理空間インデックス行を、格納されたウェアハウス５１７のデータに追加して、たとえば、ジオハッシュされたデータに対するハイパーローカルターゲティングまたはアドホッククエリの高速化を実行することができる。たとえば、４桁または文字に分解されたロケーションデータは、２０メートル以下の分解能に相当し得る。

分析サーバシステム５００を、検証済み処理のためのフィールドを新たに識別しラベル付けするために、認識されていないフィールドを有する無効データのデータベース上で分析を実行するように構成された診断機械学習５３４で構成することができる。

ある実施形態において、システム１０を、ブロック５１０で説明したように行程セグメント化のバッチ分析を実行するように構成することができる。たとえば、図７のブロック７０７において、行程セグメント化抽出は、固有ＩＤでマークされたすべてのイベントを特定することによる行程の単純な抽出を含み得る。行程セグメント化抽出およびカウントの例を表６に示す。

また、システム１０を、図７のブロック７０８における行程値フィルタリングのために、ブロック５１２で説明したように行程基準を使用してイベント情報から行程を認定するための計算を実行するように構成することもできる。行程値フィルタリングの一例を表７に示す。

ある実施形態において、バッチデータを、システムパフォーマンス報告５３５のために処理することができる。たとえば、ある実施形態において、システム１０を、システムレイテンシの報告を生成するように構成することができる。捕捉されたタイムスタンプデータと受信されたタイムスタンプデータとの間のパーセンタイルの範囲に対するバッチ分析レイテンシ報告の一例を表８に示す。システム１０を、潜在データのインターバル分析を実行するように構成することができる。ある範囲のパーセンタイルに対するインターバル／捕捉レート報告の一例を表９に示す。

図６は、ポータルサーバシステム６００の論理アーキテクチャである。少なくとも１つの実施形態において、ポータルサーバシステム６００は、レコードおよびイベントデータを取り込んで処理するように配置された１つ以上のコンピュータとすることができる。ポータルサーバシステム６００を、ポータルＡＰＩ６０８がプラットフォームの第三者１５ユーザからのデータをインターフェイスし受け入れるためのポータルユーザインターフェイス６０４およびＡＰＩゲートウェイ６０６で構成することができる。ある実施形態において、ポータルサーバシステム６００は、毎日の静的総会を提供するように構成されてもよく、分析サーバシステム５００から提供されるデータのリアルタイムアクセスのための検索エンジンおよびアクセスポータルで構成される。少なくとも１つの実施形態において、ポータルサーバシステム６００を、ユーザに、たとえば、第三者１５クライアントコンピュータに、ダッシュボードを提供するように構成することができる。少なくとも１つの実施形態において、分析サーバシステム５００からの情報は、ポータルユーザインターフェイス６０４が提供する報告生成器に流すことができる。少なくとも１つの実施形態において、報告生成器を、パフォーマンス情報に基づいて１つ以上の報告を生成するように配置することができる。少なくとも１つの実施形態において、報告を、１つ以上の報告テンプレートに基づいて決定およびフォーマットすることができる。

図７は、上記データ処理のデータパイプラインを示すフローチャートである。図７に示されるように、ある実施形態において、イベントデータは、データ品質チェックの７段階パイプラインを通してデータを送る。加えて、ストリーム処理とバッチ処理の両方を用いてデータ処理を行う。ストリーミングは、一回につき一レコードに対して機能し、トリップの以前のレコードのコンテキストは保持せず、属性およびレコードレベルで実行されるチェックに使用することができる。バッチ処理は、より完全にデータを観察することができ、エンドツーエンドプロセス全体を包含することができる。バッチ処理は、ストリーミングと同一のチェックに加えて、複数のレコードおよび行程にわたって実行されるチェックを受ける。

少なくとも１つの実施形態において、ダッシュボードディスプレイは、システム１０の他の構成要素によって生成された情報の表示をレンダリングすることができる。少なくとも１つの実施形態において、ダッシュボードディスプレイは、ネットワークを介してアクセスされるクライアントコンピュータ上に提示することができる。少なくとも１つの実施形態において、ユーザインターフェイスを、クレームされる主題の精神および／または範囲から逸脱することなく採用することができる。そのようなユーザインターフェイスは、さまざまな方法で配置することができる任意の数のユーザインターフェイス要素を有し得る。いくつかの実施形態において、ユーザインターフェイスを、ウェブページ、モバイルアプリケーション、ＧＩＳ可視化ツール、マッピングインターフェイス、電子メール、ファイルサーバ、ＰＤＦ文書、テキストメッセージなどを使用して生成することができる。少なくとも１つの実施形態において、イングレスサーバシステム１００、ストリーム処理サーバシステム２００、エグレスサーバシステム４００、分析サーバシステム５００、またはポータルサーバシステム６００は、ユーザインターフェイスを生成するためのプロセスおよび／またはＡＰＩを含み得る。

本明細書に記載されているように、システム１０、プロセスおよびアルゴリズムの実施形態は、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）（登録商標）またはＭｉｃｒｏｓｏｆｔ Ａｚｕｒｅ（登録商標）等のウェブサービスプラットフォームホスト上で実行されるように構成することができる。クラウドコンピューティングアーキテクチャが、設定可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドネットワークアクセスのために構成される。クラウドコンピュータプラットフォームを、プラットフォームプロバイダが、サービスのプロバイダと人間とのやり取りを必要とすることなく、必要に応じて自動的に、サーバ時間およびネットワークストレージ等のコンピューティング機能を単方向にプロビジョニングできるように、構成することができる。さらに、クラウドコンピューティングは、ネットワーク上で利用可能であり、異種の薄いまたは厚いクライアントプラットフォーム（たとえば携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準メカニズムを通じてアクセスされる。クラウドコンピューティングアーキテクチャにおいて、プラットフォームのコンピューティングリソースをプールすることにより、需要に応じて異なる物理および仮想リソースが動的に割り当てられ、再度割り当てられるマルチテナントモデルを使用して、複数の消費者、パートナー、または他の第三者ユーザにサービスすることができる。また、クラウドコンピューティングアーキテクチャは、プラットフォームリソースを迅速かつ弾性的に、場合によっては自動的にプロビジョニングして迅速にスケールアウトし、迅速にリリースして迅速にスケールインするように、構成される。

クラウドコンピューティングシステムを、サービスのタイプ（たとえばストレージ、処理、帯域幅、およびアクティブユーザアカウント）に適した何らかのレベルのメータリング機能を強化することによってリソースの使用を自動的に制御し最適化するシステムで、構成することができる。リソースの使用が、監視、制御、および報告されてもよい。本明細書に記載されるように、実施形態において、システム１０は、低レイテンシのために構成された革新的なアルゴリズムおよびデータベース構造を備えるプラットフォームプロバイダによって有利に構成される。

クラウドコンピューティングアーキテクチャは、いくつかのサービスおよびプラットフォーム構成を含む。

サービスとしてのソフトウェア（ＳａａＳ）は、プラットフォームプロバイダが、クラウドインフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することを可能にするように構成される。アプリケーションは、ウェブブラウザ（たとえばウェブベースの電子メール）等のシンクライアントインターフェイスを介して各種のクライアントデバイスからアクセス可能である。典型的に、消費者は、限定されたユーザ固有のアプリケーション構成設定を場合によっては例外として、ネットワーク、サーバ、オペレーティングシステム、ストレージ、または個々のアプリケーション機能さえ含む基礎となるクラウドインフラストラクチャを、管理または制御しない。

サービスとしてのプラットフォーム（ＰａａＳ）は、プラットフォームプロバイダが、プロバイダがサポートするプログラミング言語およびツールを使用して作成されたクラウドインフラストラクチャ上に、消費者によって作成または取得されたアプリケーションをデプロイすることを可能にするように、構成される。消費者は、ネットワーク、サーバ、オペレーティングシステム、またはストレージを含む基礎となるクラウドインフラストラクチャを管理または制御しないが、デプロイされたアプリケーションおよび場合によってはアプリケーションホスティング環境構成を制御することができる。

サービス（ＩａａＳ）としてのインフラストラクチャは、プラットフォームプロバイダが、処理、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースをプロビジョニングすることを可能にするように構成され、この場合、消費者は、オペレーティングシステムおよびアプリケーションを含み得る任意のソフトウェアをデプロイし実行することが可能である。消費者は、基礎となるクラウドインフラストラクチャを管理または制御しないが、オペレーティングシステム、ストレージ、デプロイされたアプリケーションを制御し、場合によっては選択ネットワーキング構成要素（たとえばホストファイアウォール）に対する制限された制御を行う。

クラウドコンピューティングアーキテクチャは、プライベートクラウドコンピューティングアーキテクチャ、コミュニティクラウドコンピューティングアーキテクチャ、またはパブリッククラウドコンピューティングアーキテクチャとして提供することができる。また、クラウドコンピューティングアーキテクチャを、ハイブリッドクラウドコンピューティングアーキテクチャとして構成することもでき、これは、固有のエンティティのままであるがデータおよびアプリケーション可搬性（たとえばクラウド間の負荷バランスのためのクラウドバースト化）を可能にする標準化されたまたはプロプライエタリ技術によって一緒に結合される、２つ以上のクラウドプラットフォーム（プライベート、コミュニティ、またはパブリック）を含む。

クラウドコンピューティング環境は、ステートレス性、低結合性、モジュール性、およびセマンティック相互運用性に焦点を当てたサービス指向のものである。クラウドコンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

次に図８を参照すると、説明のためのクラウドコンピューティング環境５０が示されている。図示のように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード３０を含み、たとえば、携帯情報端末（ＰＤＡ）または携帯電話２３、デスクトップコンピュータ２１、ラップトップコンピュータ２２等のクラウド消費者が使用するローカルコンピューティングデバイス、ならびに、ＯＥＭ車両センサデータソース１４、アプリケーションデータソース１６、テレマティクスデータソース２０、ワイヤレスインフラストラクチャデータソース１７、第三者データソース１５等のイベント、および／または車両データソース１２等の自動車コンピュータシステムを備える。ノード３０は相互に通信することができる。これらは、本明細書に記載のプライベート、コミュニティ、パブリック、もしくはハイブリッドクラウド、またはそれらの組み合わせ等の、１つ以上のネットワークにおいて、物理的または仮想的にグループ化することができる（図示せず）。クラウドコンピューティング環境５０は、クラウド消費者がローカルコンピューティングデバイス上でリソースを維持する必要がないサービスとして、インフラストラクチャ、プラットフォーム、および／またはソフトウェアを提供するように構成される。図９に示されるタイプのコンピューティングデバイスは、専ら例示を意図しており、コンピューティングノード３０およびクラウドコンピューティング環境５０は、任意のタイプのネットワークおよび／またはネットワークアドレス指定可能接続を介して（たとえばウェブブラウザを使用して）任意のタイプのコンピュータ化されたデバイスと通信できることが、理解される。

次に図９を参照すると、クラウドコンピューティング環境５０（図８）が提供する一組の機能的抽象化層が示されている。図９に示したコンポーネント、層、および機能は例示であって、本明細書に記載の実施形態はこれらに限定されるものではない。図示のように、以下の層および対応する機能が提供される。

ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェアコンポーネントを含み得る。ハードウェアコンポーネントの例は、たとえば、メインフレーム６１、サーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワーキングコンポーネント６６を含む。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含む。

仮想化層７０は抽象化層を提供し、仮想化層から、仮想エンティティの例として、仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、ならびに仮想クライアント７５を、提供することができる。

一例において、管理層８０は、以下で説明する機能を提供することができる。リソースプロビジョニング８１は、クラウドコンピューティング環境内でタスクを実行するために使用されるコンピューティングリソースおよび他のリソースの動的調達を提供する。メーリングおよび価格設定８２は、リソースがクラウドコンピューティング環境内で利用される際にコストトラッキングを提供し、これらのリソースの消費に対する課金および請求を提供する。一例において、これらのリソースはアプリケーションソフトウェアライセンスを含み得る。セキュリティは、クラウド消費者およびタスクのアイデンティティ検証、ならびにデータおよび他のリソースの保護を提供する。ユーザポータル８３は、消費者およびシステム管理者のためにクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、必要なサービスレベルが満たされるようにクラウドコンピューティングリソースの割り当ておよび管理を提供する。サービスレベル合意（ＳＬＡ：Service Level Agreement）計画および履行８５は、ＳＬＡに従って将来の要求が予想されるクラウドコンピューティングリソースの事前配置および調達を提供する。

ワークロード層９０は、クラウドコンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロードおよび機能の例は、マッピングおよびナビゲーション９１、イングレス処理９２、ストリーム処理９３、ポータルダッシュボード配信９４－同一番号、データ分析処理９５、ならびにエグレスおよびデータ配信９６を含む。

本開示はクラウドコンピューティングプラットフォーム上での実施形態を説明するが、本明細書に記載の実施形態の実装は、クラウドコンピューティング環境に限定されない。

図１～図９に関連して説明したシステム１０、５０、１００、２００、４００、５００、６００および７００について説明した実施形態は、単一のネットワークコンピュータによって実装および／または実行することができる。他の実施形態において、これらのプロセスまたはこれらのプロセスの一部は、複数のネットワークコンピュータによって実装および／または実行することができる。同様に、少なくとも１つの実施形態において、システム１０、５０、１００、２００、４００、５００および６００について説明したプロセスまたはその一部は、ネットワークコンピュータ、クライアントコンピュータ、仮想マシンなどのうちの１つ以上の各種組み合わせの上で機能することができる。さらに、少なくとも１つの実施形態において、図１～図９に関連して説明したプロセスは、これも図１～図９に関連して説明したもののような論理アーキテクチャを有するシステム内で機能することができる。

フローチャート図の各ブロック、およびフローチャート図のブロックの組み合わせは、コンピュータプログラム命令によって実現できることが理解されるであろう。これらのプログラム命令をプロセッサに与えてマシンを生成し、プロセッサ上で実行される命令が１つ以上のフローチャートブロックで指定されたアクションを実現するための手段を生成するようにしてもよい。コンピュータプログラム命令をプロセッサが実行することにより、一連の動作ステップをプロセッサに実行させて、コンピュータで実装されるプロセスを生成し、プロセッサ上で実行される命令が、１つ以上のフローチャートブロックで指定されたアクションを実現するためのステップを提供するように、することができる。また、コンピュータプログラム命令は、フローチャートのブロックに示された動作ステップのうちの少なくともいくつかを並行して実行させることもできる。さらに、ステップのいくつかは、マルチプロセッサコンピュータシステムまたは複数のコンピュータシステムからなるグループでのように、２つ以上のプロセッサにまたがって実行することもできる。加えて、フローチャート図における１つ以上のブロックもしくはブロックの組み合わせは、本開示の範囲または精神から逸脱することなく、他のブロックもしくはブロックの組み合わせと同時に、または図示の順序とは異なる順序でさえ実行することもできる。

したがって、フローチャート図のブロックは、指定されたアクションを実行するための組み合わせ、指定されたアクションを実行するためのステップの組み合わせ、および指定されたアクションを実行するためのプログラム命令手段をサポートする。また、フローチャート図の各ブロック、およびフローチャート図のブロックの組み合わせは、指定されたアクションまたはステップを実行する専用ハードウェアベースのシステム、または専用ハードウェアおよびコンピュータ命令の組み合わせによって実現されてもよいことも理解されるであろう。上記例は、限定的および／または網羅的な例と解釈されてはならず、むしろ、さまざまな実施形態のうちの少なくとも１つの実装形態を示す例示のためのユースケースである。

Claims (26)

1. プログラム命令を含むメモリと、方法のための前記命令を実行するように構成されたプロセッサとを備えるシステムであって、前記方法は、
   ロケーションイベントデータを取り込むステップと、
   前記ロケーションイベントデータから車両の行程を特定するステップとを含み、前記行程を特定するステップは、特定の車両の移動が前記行程の行程セグメントであるか否かを特定することを含む、システム。
2. 前記ロケーションイベントデータは、時間、位置（緯度／経度）、および興味のあるイベントを含む、請求項１に記載のシステム。
3. 前記プロセッサは、前記イベントデータにおけるロケーションデータを近接度に符号化することをさらに含む前記方法のための前記命令を実行するように構成されている、請求項１に記載のシステム。
4. 前記イベントデータにおけるロケーションデータを近接度に符号化するための前記方法のための前記命令はさらに、
   緯度および経度を、前記近接度を定める形状にジオハッシュすること、
   前記ジオハッシュを符号化して州を特定すること、
   前記ジオハッシュを符号化してジップコードを特定すること、および
   前記ジオハッシュを精度に符号化して車両を一意に特定すること、
   のうちの少なくとも１つを含む、請求項３に記載のシステム。
5. 前記イベントデータにおけるロケーションデータを近接度に符号化するための前記方法のための前記命令はさらに、
   前記ジオハッシュを５文字に符号化して前記州を特定すること、
   前記ジオハッシュを６文字に符号化して前記ジップコードを特定すること、および
   前記ジオハッシュを９文字に符号化して車両を一意に特定すること、
   のうちの少なくとも１つを含む、請求項４に記載のシステム。
6. 前記イベントデータにおけるロケーションデータを前記近接度を定める形状に符号化することは、前記緯度および経度を、そのエッジがストリング内の文字に比例する矩形に、ジオハッシュすることを含む、請求項５に記載のシステム。
7. 前記イベントデータにおけるロケーションデータを近接度に符号化することは、前記ジオハッシュを４～９文字に符号化することを含む、請求項６に記載のシステム。
8. 前記プロセッサは、前記ジオハッシュをマップデータベースにマッピングすることをさらに含む前記方法のための前記命令を実行するように構成されている、請求項１に記載のシステム。
9. 前記マッピングすることは、前記ジオハッシュを興味のあるポイントデータベースにマッピングすることをさらに含む、請求項８に記載のシステム。
10. 前記行程を特定するステップは、
    前記車両のエンジンオンまたは移動開始を特定することと、
    前記車両のエンジンオフまたは移動停止を特定することと、
    前記車両の滞留時間を特定することと、
    前記車両の最短走行距離を特定することと、
    最短走行継続時間を特定することとを含む、請求項１に記載のシステム。
11. 前記プロセッサは、最短走行継続時間基準で構成され、前記最短走行継続時間基準を用いて前記車両の最短走行継続時間を特定するための命令を実行するように構成されている、請求項１０に記載のシステム。
12. 最短走行継続時間基準は約６０～約１２０秒である、請求項１１に記載のシステム。
13. 最短走行継続時間基準は約６０秒である、請求項１２に記載のシステム。
14. 前記プロセッサは、最長滞留時間基準で構成され、前記最長滞留時間基準を用いて前記車両の最長滞留時間を特定するための命令を実行するように構成されている、請求項１０に記載のシステム。
15. 前記最長滞留時間基準は約２０～約６０秒である、請求項１４に記載のシステム。
16. 前記最長滞留時間基準は約３０秒である、請求項１５に記載のシステム。
17. 前記プロセッサは、最短走行距離基準で構成され、前記最短走行距離基準を用いて前記車両の最短走行距離を特定するための命令を実行するように構成されている、請求項１０に記載のシステム。
18. 前記最短走行距離基準は約１００メートル～約３００メートルである、請求項１７に記載のシステム。
19. 前記最短走行距離基準は約２００メートルである、請求項１８に記載のシステム。
20. 前記行程を特定するステップは、前記行程セグメントが前記行程の一部を形成しないと判断することを含む、請求項１に記載のシステム。
21. 前記システムは能動的車両検出を提供するように構成されている、請求項１に記載のシステム。
22. 前記能動的車両検出は、ある期間にわたる複数の前記イベントから車両経路を特定することを含む、請求項１５に記載のシステム。
23. 前記能動的車両検出は、ある１日の前記期間にわたる前記複数のイベントから前記車両経路を特定することを含み、前記特定することは接続コンポーネントアルゴリズムを使用することを含み、前記接続コンポーネントアルゴリズムは、前記車両イベントの前記日を含む有向グラフ内で前記車両経路を特定することを含み、前記グラフにおいて、ノードが車両であり、ノード間の接続が前記特定された車両経路である、請求項２１に記載のシステム。
24. 前記システムは、データウェアハウスを含み、前記イベントデータおよび行程決定データを前記データウェアハウスに格納する、請求項１に記載のシステム。
25. 前記格納されたデータに追加される少なくとも１つのタイムカラムをさらに含む、請求項２４に記載のシステム。
26. 前記タイムカラムは、日付カラムおよび時間カラムを含む、請求項２５に記載のシステム。

Images