(57)【要約】ルートに関する推定到着時間（ｅｓｔｉｍａｔｅｄ  ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ、ＥＴＡ）をＥＴＡモデルに基づき決定するためのシステムおよび方法。システムが、方法を遂行して、少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得て（３１０）、第１の電気信号に基づき、少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間からなる第１の構造化データを生成および保存し（３２０）、ＥＴＡモデルの第２の構造化データを、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間に基づきモデルをトレーニングすることにより生成し（３３０）、ＥＴＡモデルの第２の構造化データを、少なくとも１つの非一時的コンピュータ可読記憶媒体に保存（３４０）してもよい。【選択図】図３
2019507316.tif 000002
【特許請求の範囲】
【請求項１】
システムであって、
命令のセットを含む少なくとも１つの非一時的コンピュータ可読記憶媒体と、
前記少なくとも１つの非一時的コンピュータ可読記憶媒体と通信する少なくとも１つのプロセッサと、
を備え、前記命令を実行するとき、前記少なくとも１つのプロセッサは、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得て、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存し、
推定到着時間（ｅｓｔｉｍａｔｅｄ  ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ、ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成し、
前記ＥＴＡモデルの前記第２の構造化データを前記少なくとも１つの非一時的コンピュータ可読記憶媒体に保存する
ように指示されるシステム。
【請求項２】
少なくとも１つの大域特徴ベクトルのうち少なくとも２つは、行列式に統合される、請求項１に記載のシステム。
【請求項３】
前記少なくとも１つの大域特徴ベクトルは、前記少なくとも１つの道路区間のうち少なくとも２つの間の関係を示す特徴を含む総合特徴ベクトルを含む、請求項２に記載のシステム。
【請求項４】
前記少なくとも１つの道路区間のうち前記少なくとも２つは、互いに離れている、請求項３に記載のシステム。
【請求項５】
前記総合特徴ベクトルは、リアルタイムの道路速度または推定道路速度を含む交通状態のうち少なくとも１つを含む、請求項３に記載のシステム。
【請求項６】
前記ＥＴＡモデルは、回帰モデル、決定木モデル、人工ニューラル・ネットワーク・モデル、サポートベクター回帰モデル、制限付きボルツマン・マシン・モデル、または遺伝的アルゴリズムのうち少なくとも１つを含む、請求項１に記載のシステム。
【請求項７】
前記ＥＴＡモデルは、時間間隔または地図内の領域のうち少なくとも１つに対応する複数のＥＴＡサブモデルを含む、請求項１に記載のシステム。
【請求項８】
前記少なくとも１つのプロセッサは、
少なくとも１つの道路区間を有する意図するルートに関連付けられる第２の電気信号を受信し、
前記第２の電気信号に基づき、前記意図するルートに関連付けられる少なくとも１つの意図する大域特徴ベクトルの第３の構造化データを生成および保存し、
前記ＥＴＡモデルの前記第２の構造化データを実行して、前記意図する特徴ベクトルおよび前記ＥＴＡモデルに基づき、前記意図するルートに対応するＥＴＡを決定する
ようにさらに指示される、請求項１に記載のシステム。
【請求項９】
前記意図するルートに対応する前記ＥＴＡを決定するために、前記少なくとも１つのプロセッサは、
前記意図するルートの開始時間の時間間隔を決定し、
前記開始時間に基づき、前記時間間隔に対応する前記ＥＴＡサブモデルを選択する
ようにさらに指示される、請求項７に記載のシステム。
【請求項１０】
前記意図するルートに対応する前記ＥＴＡを決定するために、前記少なくとも１つのプロセッサは、
前記意図するルートの、開始位置の領域、または終了位置を決定し、
前記開始位置および前記終了位置に基づき、地図内の前記領域に対応する前記ＥＴＡサブモデルを選択する
ようにさらに指示される、請求項７に記載のシステム。
【請求項１１】
少なくとも１つのプロセッサ、少なくとも１つの非一時的コンピュータ可読記憶媒体、およびネットワークに接続された通信プラットフォームを有するコンピューティング機器上に実装される方法であって、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得るステップと、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存するステップと、
推定到着時間（ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成するステップと、
前記ＥＴＡモデルの前記第２の構造化データを前記少なくとも１つの非一時的コンピュータ可読記憶媒体に保存するステップと
を備える方法。
【請求項１２】
前記少なくとも１つの大域特徴ベクトルのうち少なくとも２つは、行列式に統合される、請求項１１に記載の方法。
【請求項１３】
前記少なくとも１つの大域特徴ベクトルは、前記少なくとも１つの道路区間のうち少なくとも２つの間の関係を示す特徴を含む総合特徴ベクトルを含む、請求項１２に記載の方法。
【請求項１４】
前記少なくとも１つの道路区間のうち前記少なくとも２つは、互いに離れている、請求項１３に記載の方法。
【請求項１５】
前記総合特徴ベクトルは、リアルタイムの道路速度または推定道路速度を含む交通状態のうち少なくとも１つを含む、請求項１３に記載の方法。
【請求項１６】
前記ＥＴＡモデルは、回帰モデル、決定木モデル、人工ニューラル・ネットワーク・モデル、サポートベクター回帰モデル、制限付きボルツマン・マシン・モデル、または遺伝的アルゴリズムのうち少なくとも１つを含む、請求項１１に記載の方法。
【請求項１７】
前記ＥＴＡモデルは、時間間隔、または地図内の領域のうち少なくとも１つに対応する複数のＥＴＡサブモデルを含む、請求項１１に記載の方法。
【請求項１８】
少なくとも１つの道路区間を有する意図するルートに関連付けられる第２の電気信号を受信するステップと、
前記第２の電気信号に基づき、前記意図するルートに関連付けられる少なくとも１つの意図する大域特徴ベクトルの第３の構造化データを生成および保存するステップと、
前記ＥＴＡモデルの前記第２の構造化データを実行して、前記意図する特徴ベクトルおよび前記ＥＴＡモデルに基づき、前記意図するルートに対応するＥＴＡを決定するステップと
をさらに備える、請求項１１に記載の方法。
【請求項１９】
前記意図するルートに対応する前記ＥＴＡを決定する前記ステップは、
前記意図するルートの開始時間の時間間隔を決定するステップと、
前記開始時間に基づき、前記時間間隔に対応する前記ＥＴＡサブモデルを選択するステップと
をさらに備える、請求項１７に記載の方法。
【請求項２０】
命令を含む非一時的コンピュータ可読記憶媒体であって、要求者端末からのオンライン・オン・デマンド・サービス・プラットフォームの少なくとも１つのプロセッサによりアクセスされたとき、前記命令が、前記少なくとも１つのプロセッサに、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得させ、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存させ、
推定到着時間（ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成させ、
前記ＥＴＡモデルの前記第２の構造化データを前記非一時的コンピュータ可読記憶媒体に保存させる
非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、内容が参照により本明細書に組み入れられる、２０１６年４月１８日に提出された中国特許出願第２０１６１０２４２０６７．５号明細書の優先権を主張する。
【０００２】
本開示は、一般にルートに関する推定到着時間（ｅｓｔｉｍａｔｅｄ  ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ、ＥＴＡ）を決定するためのシステムおよび方法に関し、詳細にはＥＴＡモデルを使用してＥＴＡを決定するためのシステムおよび方法に関する。
【背景技術】
【０００３】
インターネット技術の進展に伴い、オンラインタクシー呼出サービスおよび配送サービスなどのオン・デマンド・サービスが、人々の日常生活で重要な役割を果たしている。たとえば、輸送のためのオンデマンド輸送サービスが、ユーザ（たとえば、乗客）により大いに使用されてもよい。
【発明の概要】
【０００４】
オンライン・オン・デマンド・サービス・プラットフォームによって、ユーザが、スマートホン端末などのユーザ装置にインストールしたアプリケーションを通したオン・デマンド・サービスの形で、オン・デマンド・サービスを要求してもよい。
【０００５】
本開示の一様態によれば、システムが、少なくとも１つの非一時的コンピュータ可読記憶媒体と、少なくとも１つの非一時的コンピュータ可読記憶媒体と通信するように構成された要求者端末からのオンライン・オン・デマンド・サービス・プラットフォームの少なくとも１つのプロセッサとを含んでもよい。少なくとも１つの非一時的コンピュータ可読記憶媒体が、意図するルートに関する推定到着時間（ＥＴＡ）を決定するための命令のセットを含んでもよい。少なくとも１つのプロセッサが、命令のセットを実行するとき、少なくとも１つのプロセッサは、以下の動作のうち１つまたは複数を遂行するように指示されてもよい。少なくとも１つのプロセッサが、少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得てもよい。少なくとも１つのプロセッサが、第１の電気信号に基づき、少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存してもよい。少なくとも１つのプロセッサが、ＥＴＡモデルの第２の構造化データを、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間に基づきモデルをトレーニングすることにより生成してもよい。少なくとも１つのプロセッサが、少なくとも１つの非一時的コンピュータ可読記憶媒体にＥＴＡモデルの第２の構造化データを保存してもよい。
【０００６】
本開示の他の一様態によれば、方法が、以下の動作のうち１つまたは複数を含んでもよい。要求者端末からのオンライン・オン・デマンド・サービス・プラットフォームの少なくとも１つのコンピュータサーバが、少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得てもよい。少なくとも１つのコンピュータサーバが、第１の電気信号に基づき、少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存してもよい。少なくとも１つのコンピュータサーバが、ＥＴＡモデルの第２の構造化データを、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間に基づきモデルをトレーニングすることにより生成してもよい。少なくとも１つのコンピュータサーバが、少なくとも１つの非一時的コンピュータ可読記憶媒体にＥＴＡモデルの第２の構造化データを保存してもよい。
【０００７】
本開示の別の様態によれば、非一時的機械可読記憶媒体が、命令を含んでもよい。非一時的機械可読記憶媒体が、要求者端末からのオンライン・オン・デマンド・サービス・プラットフォームの少なくとも１つのプロセッサからアクセスされるとき、命令により、少なくとも１つのプロセッサが、以下の動作のうち１つまたは複数を遂行してもよい。命令により、少なくとも１つのプロセッサが、無線ネットワークを通して現在のデフォルトサービス位置を含むオン・デマンド・サービスのリクエストを得てもよい。命令により、少なくとも１つのプロセッサが、少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得てもよい。命令により、少なくとも１つのプロセッサが、第１の電気信号に基づき、少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存してもよい。命令により、少なくとも１つのプロセッサが、ＥＴＡモデルの第２の構造化データを、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間に基づきモデルをトレーニングすることにより生成してもよい。命令により、少なくとも１つのプロセッサが、非一時的コンピュータ可読記憶媒体にＥＴＡモデルの第２の構造化データを保存してもよい。
【０００８】
本開示について、代表的実施形態に関してさらに説明する。これらの代表的実施形態について、図面を参照して詳細に説明する。これらの実施形態は、限定しない代表的実施形態であり、そこでは、類似の参照番号が、図面のいくつかの図全体を通して類似の構造を表す。
【図面の簡単な説明】
【０００９】
【図１】本開示のいくつかの実施形態による代表的オン・デマンド・サービス・システムを例示する構成図である。
【図２】本開示のいくつかの実施形態による代表的処理エンジンを例示する構成図である。
【図３】本開示のいくつかの実施形態による、輸送サービスに関するＥＴＡを決定するための、代表的な処理および／または方法を例示する流れ図である。
【図４】本開示のいくつかの実施形態による、意図するルートに関するＥＴＡを決定するための、代表的な処理および／または方法を例示する流れ図である。
【図５】本開示のいくつかの実施形態による、ＥＴＡサブモデルに基づき、ＥＴＡを決定するための、代表的な処理および／または方法を例示する流れ図である。
【図６】本開示のいくつかの実施形態による、大域特徴ベクトルに関連付けられるテーブルの、代表的な図を例示する。
【図７】本開示のいくつかの実施形態によるＥＴＡモデルとして、決定木の代表的な図を例示する。
【図８】本開示のいくつかの実施形態によるＥＴＡモデルとして、人工ニューラルネットワークの代表的な図を例示する。
【図９】本開示のいくつかの実施形態による、ＥＴＡを予測するための物理モデルの代表的な図を例示する。
【図１０】本開示のいくつかの実施形態による、コンピューティング機器の代表的なハードウェアおよび／またはソフトウェアの構成要素を例示する概略図である。
【図１１】本開示のいくつかの実施形態による、ユーザ端末が実装されてもよい代表的移動体機器の、代表的なハードウェアおよび／またはソフトウェアの構成要素を例示する概略図である。
【発明を実施するための形態】
【００１０】
以下の説明は、当業者が本開示を作成し、使用することができるようにするために提示され、特定の適用例およびその要件に関連して提供される。開示する実施形態に対するさまざまな修正が、当業者には容易に明らかになり、本明細書で規定する一般的原理が、本開示の精神または範囲から逸脱することなく他の実施形態および適用例に応用されてもよい。したがって、本開示は、示される実施形態に限定されるのではなく、特許請求の範囲と矛盾しない最も広い範囲が与えられるべきである。
【００１１】
本明細書で使用する用語は、特定の実施例の実施形態を説明するためのものであり、限定するものではない。本明細書で使用するとき、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈が明らかにそうではないと示さない限り、複数形も含むことが意図される場合がある。用語「ｃｏｍｐｒｉｓｅ（備える）」、「ｃｏｍｐｒｉｓｅｓ（備える）」、および／もしくは「ｃｏｍｐｒｉｓｉｎｇ（備える）」、ならびに「ｉｎｃｌｕｄｅ（含む）」、「ｉｎｃｌｕｄｅｓ（含む）」、および／もしくは「ｉｎｃｌｕｄｉｎｇ（含む）」は、本明細書で使用するとき、言及された特徴、完全体、ステップ、動作、要素、および／または構成要素の存在を明示するが、１つもしくは複数の他の特徴、完全体、ステップ、動作、要素、構成要素、および／もしくはそれらのグループの存在または追加を除外しないことをさらに理解されたい。
【００１２】
本開示のこれらおよび他の特徴、ならびに特性だけではなく、動作方法、および構造物の関係する要素の機能、および部分の組合せ、および製造の経済性が、すべて本開示の一部を形成する添付図面を参照して以下の説明を考慮したときに、より明らかになる場合がある。しかしながら、図面が、例示および説明するためだけにあり、本開示の範囲を限定することを意図するものではないことをはっきりと理解されたい。図面が、縮尺通りではないことが理解される。
【００１３】
本開示で使用する流れ図は、本開示のいくつかの実施形態に従ってシステムが実現する動作を例示する。流れ図の動作が、順序通りに実現されなくてもよいことをはっきりと理解されたい。逆に、動作を逆順で、または同時に実現してもよい。さらに、１つまたは複数の他の動作を流れ図に追加してもよい。１つまたは複数の動作を流れ図から取り除いてもよい。
【００１４】
さらに、本開示では、システムおよび方法が、輸送サービスに関するリクエストを分配することに関して主に記述されているが、本開示は、限定することを意図するものではないこともまた理解されたい。本開示のシステムおよび方法を、任意の他の種類のオン・デマンド・サービスに適用してもよい。たとえば、本開示のシステムまたは方法を、陸上、海洋、航空宇宙空間など、またはそれらの任意の組合せを含む、異なる環境の輸送システムに適用してもよい。輸送システムの車両が、タクシー、自家用車、ヒッチハイク、バス、列車、超特急列車、高速鉄道、地下鉄、船、航空機、宇宙船、熱気球、無人車両など、またはそれらの任意の組合せを含んでもよい。輸送システムはまた、管理および／または流通のための任意の輸送システム、たとえば、速達便を送るおよび／または受け取るためのシステムを含んでもよい。本開示のシステムおよび方法のアプリケーションが、ユーザ機器上に実装されてもよく、さらにウェブページ、ブラウザのプラグイン、クライアント端末、カスタムシステム、内部分析システム、人工知能ロボットなど、またはそれらの任意の組合せを含んでもよい。
【００１５】
本開示では、「乗客」、「要求者」、「サービス要求者」、および「顧客」という用語を、サービスを要求または注文してもよい、個人、実体、またはツールを指すために、交換可能に使用する。また、本開示では、「運転者」、「提供者」、および「サービス提供者」という用語を、サービスを提供またはサービスの提供を容易にしてもよい、個人、実体、またはツールを指すために、交換可能に使用する。
【００１６】
本開示では、用語「サービスリクエスト」、「サービスのリクエスト」、「リクエスト」、および「注文」を、乗客、サービス要求者、顧客、運転者、提供者、サービス提供者など、またはそれらの任意の組合せにより開始されてもよいリクエストを指すために、交換可能に使用する。サービスリクエストが、乗客、サービス要求者、顧客、運転者、提供者、またはサービス提供者のうち任意の１つにより受け入れられてもよい。サービスリクエストが、有料であっても、または無料であってもよい。
【００１７】
本開示では、用語「サービス提供者端末」および「運転者端末」を、サービス提供者がサービスを提供するために、またはサービスの提供を容易にするために使用する移動体端末を指すために、交換可能に使用する。本開示では、用語「サービス要求者端末」および「乗客端末」を、サービス要求者がサービスを要求するために、またはサービスを注文するために使用する移動体端末を指すために、交換可能に使用する。
【００１８】
本開示で使用する測位技術が、全地球測位システム（ｇｌｏｂａｌ  ｐｏｓｉｔｉｏｎｉｎｇ  ｓｙｓｔｅｍ、ＧＰＳ）、全地球航法衛星システム（ｇｌｏｂａｌ  ｎａｖｉｇａｔｉｏｎ  ｓａｔｅｌｌｉｔｅ  ｓｙｓｔｅｍ、ＧＬＯＮＡＳＳ）、コンパス航法システム（ｃｏｍｐａｓｓ  ｎａｖｉｇａｔｉｏｎ  ｓｙｓｔｅｍ、ＣＯＭＰＡＳＳ）、Ｇａｌｉｌｅｏ測位システム、準天頂衛星システム（ｑｕａｓｉ−ｚｅｎｉｔｈ  ｓａｔｅｌｌｉｔｅ  ｓｙｓｔｅｍ、ＱＺＳＳ）、およびＷｉ−Ｆｉ（ｗｉｒｅｌｅｓｓ  ｆｉｄｅｌｉｔｙ）測位技術など、またはそれらの任意の組合せに基づいてもよい。本開示では、上記測位システムの１つまたは複数を交換可能に使用する場合がある。
【００１９】
本開示の一様態が、ルートに関する推定到着時間（ＥＴＡ）をＥＴＡモデルに基づき決定するための、オンラインシステムおよび方法に関する。システムおよび方法が、全体として少なくとも１つの道路区間を含むルートを取得し、その大域特徴ベクトルを得る。その結果、大域特徴が、個々の道路区間それぞれの特徴だけではなく、隣接する、または隣接しない、異なる道路区間の間の相互影響関係もまた含む。複数のルートの大域特徴ベクトルを得た後、システムおよび方法が、複数のルートの大域特徴ベクトル、および車両が複数のルートを通って走行するのにかかる過去の走行継続時間により、ＥＴＡモデルをトレーニングしてもよい。次いで、トレーニングしたＥＴＡモデルを使用して、実際の運転者のＥＴＡを決定してもよい。
【００２０】
オンラインタクシー呼出しなどのオンライン・オン・デマンド輸送サービスが、インターネット以後の時代に根ざした、新たに台頭したサービスであることに留意されたい。オンライン・オン・デマンド輸送サービスが、インターネット以後の時代に向上する可能性がある技術的解決策を乗客および運転者に提供する。インターネット以前の時代では、乗客が、タクシーを呼ぶとき、目的地または位置に至る推定到着時間に関する知識がまったくない場合がある。乗客が電話を通してタクシーを呼ぶ場合、サービス提供者（たとえば、運転者、タクシー会社、郵便局、配送会社、または代理人など）が、乗客の目的地に到着する時間を推定することが困難な場合がある。しかしながら、オンライン・オン・デマンド輸送システムが、ＥＴＡモデル、および意図するルートから得られる意図する特徴ベクトルに基づき、乗客の推定到着時間を決定してもよい。大域特徴ベクトルおよび過去の継続時間をトレーニングすることにより、オンライン・オン・デマンド輸送システムが、意図するルートに関するＥＴＡモデルまたはＥＴＡサブモデルを提供してもよい。乗客または運転者などのユーザが、ＥＴＡモデルまたはＥＴＡサブモデルを使用して、輸送サービスに関するサービスリクエストを確認する（たとえば、タクシーを呼ぶ）前に、ＥＴＡを予測してもよい。ＥＴＡモデルまたはＥＴＡサブモデルをトレーニングするための大域特徴ベクトルを、少なくとも１つの道路区間に関連付けられる電気信号から得てもよい。したがって、インターネットを通して、オンライン・オン・デマンド輸送システムが、従来のインターネット以前の輸送サービス・システムでは決して遭遇しえなかった、はるかに便利で効率的な取引プラットフォームを、乗客および運転者に提供しうる。
【００２１】
図１は、いくつかの実施形態による、代表的オン・デマンド・サービス・システム１００を例示する構成図である。たとえば、オン・デマンド・サービス・システム１００が、輸送サービスのためのオンライン・輸送サービス・プラットフォームであってもよい。オン・デマンド・サービス・システム１００が、サーバ１１０、ネットワーク１２０、サービス要求者端末１３０、サービス提供者端末１４０、車両１５０、データベース１６０、およびナビゲーションシステム１７０を含んでもよい。
【００２２】
オン・デマンド・サービス・システム１００が、複数のサービスを提供してもよい。代表的サービスが、タクシー呼出サービス、お抱え運転手サービス、急行貨物サービス、カープールサービス、バスサービス、運転者雇用サービス、およびシャトルサービスを含んでもよい。いくつかの実施形態では、オン・デマンド・サービスが、食事の予約、ショッピングなど、またはそれらの任意の組合せなどの、任意のオンラインサービスであってもよい。
【００２３】
いくつかの実施形態では、サーバ１１０が、単一サーバであっても、またはサーバグループであってもよい。サーバグループが、集中型であっても、または分散型であってもよい（たとえば、サーバ１１０が、分散システムであってもよい）。いくつかの実施形態では、サーバ１１０が、ローカルにあっても、または遠隔にあってもよい。たとえば、サーバ１１０が、ネットワーク１２０を介して、サービス要求者端末１３０、サービス提供者端末１４０、および／またはデータベース１６０に記憶された情報および／またはデータにアクセスしてもよい。別の実施例として、サービス要求者端末１３０、サービス提供者端末１４０、および／またはデータベース１６０にサーバ１１０を直接接続して、記憶された情報および／またはデータにアクセスしてもよい。いくつかの実施形態では、サーバ１１０をクラウドプラットフォーム上に実装してもよい。単なる実施例として、クラウドプラットフォームが、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウドなど、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、本開示で図１０に例示する１つまたは複数の構成要素を有するコンピューティング機器１０００上にサーバ１１０を実装してもよい。
【００２４】
いくつかの実施形態では、サーバ１１０が、処理エンジン１１２を含んでもよい。処理エンジン１１２が、サービスリクエストに関係がある情報および／またはデータを処理して、本開示で説明する１つまたは複数の機能を遂行してもよい。たとえば、処理エンジン１１２が、サービス要求者端末１３０から受信したサービスリクエストに応答して、１つまたは複数のサービス提供者端末候補を決定してもよい。いくつかの実施形態では、処理エンジン１１２が、１つまたは複数の処理エンジン（たとえば、１つもしくは複数のシングルコア処理エンジン、または１つもしくは複数のマルチコアプロセッサ）を含んでもよい。単なる実施例として、処理エンジン１１２が、中央処理装置（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ、ＣＰＵ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ、ＡＳＩＣ）、ＡＳＩＰ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ  ｐｒｏｃｅｓｓｏｒ）、グラフィックス・プロセッシング・ユニット（ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ、ＧＰＵ）、ＰＰＵ（ｐｈｙｓｉｃａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）、デジタル・シグナル・プロセッサ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、フィールド・プログラマブル・ゲート・アレイ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ、ＦＰＧＡ）、プログラム可能論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅ、ＰＬＤ）、コントローラ、マイクロコントローラユニット、縮小命令セットコンピュータ（ｒｅｄｕｃｅｄ  ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ  ｃｏｍｐｕｔｅｒ、ＲＩＳＣ）、マイクロプロセッサなど、またはそれらの任意の組合せを含んでもよい。
【００２５】
ネットワーク１２０が、情報および／またはデータの交換を容易にしてもよい。いくつかの実施形態では、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素（たとえば、サーバ１１０、サービス要求者端末１３０、サービス提供者端末１４０、車両１５０、データベース１６０、およびナビゲーションシステム１７０）が、ネットワーク１２０を介して、オン・デマンド・サービス・システム１００内の１つまたは複数の他の構成要素に情報および／またはデータを送信してもよい。たとえば、サーバ１１０が、ネットワーク１２０を介してサービス要求者端末１３０からサービスリクエストを受信してもよい。いくつかの実施形態では、ネットワーク１２０が、任意のタイプの有線もしくは無線のネットワークであっても、またはそれらの組合せであってもよい。単なる実施例として、ネットワーク１２０が、ケーブルネットワーク、有線ネットワーク、光ファイバネットワーク、電気通信ネットワーク、イントラネット、インターネット、ローカル・エリア・ネットワーク（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ、ＬＡＮ）、広域ネットワーク（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ、ＷＡＮ）、無線ローカル・エリア・ネットワーク（ｗｉｒｅｌｅｓｓ  ｌｏｃａｌ  ａｒｅａ、ｎｅｔｗｏｒｋ、ＷＬＡＮ）、メトロポリタン・エリア・ネットワーク（ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ、ＭＡＮ）、広域ネットワーク（ＷＡＮ）、公衆電話交換網（ｐｕｂｌｉｃ  ｔｅｌｅｐｈｏｎｅ  ｓｗｉｔｃｈｅｄ  ｎｅｔｗｏｒｋ、ＰＳＴＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、ＺｉｇＢｅｅネットワーク、近距離無線通信（ｎｅａｒ  ｆｉｅｌｄ  ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＮＦＣ）ネットワークなど、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、ネットワーク１２０が、１つまたは複数のネットワーク・アクセス・ポイントを含んでもよい。たとえば、ネットワーク１２０が、オン・デマンド・サービス・システム１００の１つまたは複数の構成要素がデータおよび／または情報を交換するためにネットワーク１２０に接続されてもよい、基地局および／または相互接続点１２０−１、１２０−２、…などの、有線または無線のネットワーク・アクセス・ポイントを含んでもよい。
【００２６】
いくつかの実施形態では、乗客が、サービス要求者端末１３０の所有者であってもよい。いくつかの実施形態では、サービス要求者端末１３０の所有者が、乗客以外のだれかであってもよい。たとえば、サービス要求者端末１３０の所有者Ａが、サービス要求者端末１３０を使用して、乗客Ｂへのサービスリクエストを送信しても、またはサーバ１１０からサービス確認および／もしくは情報もしくは命令を受信してもよい。いくつかの実施形態では、サービス提供者が、サービス提供者端末１４０のユーザであってもよい。いくつかの実施形態では、サービス提供者端末１４０のユーザが、サービス提供者以外のだれかであってもよい。たとえば、サービス提供者端末１４０のユーザＣが、サービス提供者端末１４０を使用して、サーバ１１０からサービス提供者Ｄへのサービスリクエスト、および／または情報もしくは命令を受信してもよい。いくつかの実施形態では、「乗客」および「乗客端末」を交換可能に使用する場合があり、「サービス提供者」および「サービス提供者端末」を交換可能に使用する場合がある。いくつかの実施形態では、サービス提供者端末を、１つまたは複数のサービス提供者（たとえば、夜間勤務のサービス提供者または昼間勤務のサービス提供者）と関連づけてもよい。
【００２７】
いくつかの実施形態では、サービス要求者端末１３０が、移動体機器１３０−１、タブレットコンピュータ１３０−２、ラップトップコンピュータ１３０−３、車両内の内蔵機器１３０−４など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、移動体機器１３０−１が、スマートホーム機器、ウェアラブル機器、スマート移動体機器、仮想現実機器、拡張現実感機器など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、スマートホーム機器が、スマート照明機器、インテリジェントな電気器具の制御機器、スマート監視機器、スマートテレビ、スマート・ビデオ・カメラ、インターホンなど、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、ウェアラブル機器が、スマートブレスレット、スマート履物、スマートメガネ、スマートヘルメット、スマートウォッチ、スマート衣服、スマートバックパック、スマートアクセサリなど、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、スマート移動体機器が、スマートホン、携帯情報端末（ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｃｅ、ＰＤＡ）、ゲーム機器、ナビゲーション機器、ＰＯＳ（ｐｏｉｎｔ  ｏｆ  ｓａｌｅ）機器など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、仮想現実機器および／または拡張現実感機器が、仮想現実ヘルメット、仮想現実メガネ、仮想現実パッチ、拡張現実感ヘルメット、拡張現実感メガネ、拡張現実感パッチなど、またはそれらの任意の組合せを含んでもよい。たとえば、仮想現実機器および／または拡張現実感機器が、Ｇｏｏｇｌｅ（登録商標）グラス、オキュラスリフト（Ｏｃｕｌｕｓ  Ｒｉｆｔ）、ホロレンズ（Ｈｏｌｏｌｅｎｓ）、ギアＶＲ（Ｇｅａｒ  ＶＲ）などを含んでもよい。いくつかの実施形態では、車両内の内蔵機器１３０−４が、車載コンピュータ、車載テレビなどを含んでもよい。いくつかの実施形態では、サービス要求者端末１３０が、乗客および／またはサービス要求者端末１３０の場所を位置決めするための測位技術を有する機器であってもよい。
【００２８】
サービス提供者端末１４０が、複数のサービス提供者端末１４０−１、１４０−２、…、１４０−ｎを含んでもよい。いくつかの実施形態では、サービス提供者端末１４０が、サービス要求者端末１３０に類似する機器であっても、またはそれと同じ機器であってもよい。いくつかの実施形態では、オンライン・オン・デマンド輸送サービスを実装することができるように、サービス提供者端末１４０をカスタマイズしてもよい。いくつかの実施形態では、サービス提供者端末１４０が、サービス提供者、サービス提供者端末１４０、および／またはサービス提供者端末１４０に関連付けられる車両１５０を位置決めするための測位技術を有する機器であってもよい。いくつかの実施形態では、サービス要求者端末１３０および／またはサービス提供者端末１４０が、他の測位機器と通信して、乗客、サービス要求者端末１３０、サービス提供者、および／またはサービス提供者端末１４０の場所を決定してもよい。いくつかの実施形態では、サービス要求者端末１３０および／またはサービス提供者端末１４０が、測位情報をサーバ１１０に周期的に送信してもよい。いくつかの実施形態では、サービス提供者端末１４０が、同じく可用性状態をサーバ１１０に周期的に送信してもよい。可用性状態が、サービス提供者端末１４０に関連付けられる車両１５０が乗客を運ぶために利用可能であるかどうかを示してもよい。たとえば、サービス要求者端末１３０および／またはサービス提供者端末１４０が、測位情報および可用性状態をサーバ１１０に３０分ごとに送信してもよい。別の実施例として、サービス要求者端末１３０および／またはサービス提供者端末１４０が、ユーザがオンライン・オン・デマンド輸送サービスに関連付けられる移動体アプリケーションにログインするたびに、測位情報および可用性状態をサーバ１１０に送信してもよい。
【００２９】
いくつかの実施形態では、サービス提供者端末１４０が、１つまたは複数の車両１５０に対応してもよい。車両１５０が、乗客を運び、目的地まで走行してもよい。車両１５０が、複数の車両１５０−１、１５０−２、…、１５０−ｎを含んでもよい。１台の車両が、１つのタイプのサービス（たとえば、タクシー呼出サービス、お抱え運転手サービス、急行貨物サービス、カープールサービス、バスサービス、運転者雇用サービス、およびシャトルサービス）に対応してもよい。
【００３０】
データベース１６０が、データおよび／または命令を記憶してもよい。いくつかの実施形態では、データベース１６０が、サービス要求者端末１３０および／またはサービス提供者端末１４０から得たデータを記憶してもよい。いくつかの実施形態では、データベース１６０が、本開示で説明する代表的方法を遂行するためにサーバ１１０が実行または使用してもよい、データおよび／または命令を記憶してもよい。いくつかの実施形態では、データベース１６０が、大容量記憶領域、取外し可能記憶領域、揮発性読出し書込みメモリ、読出し専用メモリ（ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ、ＲＯＭ）など、またはそれらの任意の組合せを含んでもよい。代表的大容量記憶領域が、磁気ディスク、光ディスク、ＳＳＤ（ｓｏｌｉｄ−ｓｔａｔｅ  ｄｒｉｖｅ）を含んでもよい。代表的取外し可能記憶領域が、フラッシュドライブ、フロッピーディスク、光ディスク、メモリカード、ｚｉｐディスク、磁気テープなどを含んでもよい。代表的揮発性読出し書込みメモリが、ランダム・アクセス・メモリ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ、ＲＡＭ）を含んでもよい。代表的ＲＡＭが、ダイナミックＲＡＭ（ｄｙｎａｍｉｃ  ＲＡＭ、ＤＲＡＭ）、ＤＤＲ  ＳＤＲＡＭ（ｄｏｕｂｌｅ  ｄａｔａ  ｒａｔｅ  ｓｙｎｃｈｒｏｎｏｕｓ  ｄｙｎａｍｉｃ  ＲＡＭ）、スタティックＲＡＭ（ｓｔａｔｉｃ  ＲＡＭ、ＳＲＡＭ）、サイリスタＲＡＭ（ｔｈｙｒｉｓｔｏｒ  ＲＡＭ、Ｔ−ＲＡＭ）、およびゼロキャパシタＲＡＭ（ｚｅｒｏ−ｃａｐａｃｉｔｏｒ  ＲＡＭ、Ｚ−ＲＡＭ）などを含んでもよい。代表的ＲＯＭが、マスクＲＯＭ（ｍａｓｋ  ＲＯＭ、ＭＲＯＭ）、プログラム可能ＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ、ＰＲＯＭ）、消去可能プログラム可能ＲＯＭ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ、ＰＥＲＯＭ）、電気的消去可能プログラム可能ＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ  ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ、ＥＥＰＲＯＭ）、コンパクトディスクＲＯＭ（ｃｏｍｐａｃｔ  ｄｉｓｋ  ＲＯＭ、ＣＤ−ＲＯＭ）、およびデジタル多用途ディスクＲＯＭなどを含んでもよい。いくつかの実施形態では、データベース１６０をクラウドプラットフォーム上に実装してもよい。単なる実施例として、クラウドプラットフォームが、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウドなど、またはそれらの任意の組合せを含んでもよい。
【００３１】
いくつかの実施形態では、データベース１６０が、ネットワーク１２０に接続され、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素（たとえば、サーバ１１０、サービス要求者端末１３０、サービス提供者端末１４０など）と通信してもよい。オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素が、データベース１６０に記憶されたデータまたは命令にネットワーク１２０を介してアクセスしてもよい。いくつかの実施形態では、データベース１６０が、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素（たとえば、サーバ１１０、サービス要求者端末１３０、サービス提供者端末１４０など）に直接接続されてもよく、またはそのような１つもしくは複数の構成要素と通信してもよい。いくつかの実施形態では、データベース１６０が、サーバ１１０の一部であってもよい。
【００３２】
ナビゲーションシステム１７０が、対象物に関連付けられる、たとえば、サービス要求者端末１３０、サービス提供者端末１４０、車両１５０などのうち１つまたは複数に関連付けられる情報を決定してもよい。いくつかの実施形態では、ナビゲーションシステム１７０が、全地球測位システム（ＧＰＳ）、全地球航法衛星システム（ＧＬＯＮＡＳＳ）、コンパス航法システム（ＣＯＭＰＡＳＳ）、北斗（ＢｅｉＤｏｕ）航法衛星システム、Ｇａｌｉｌｅｏ測位システム、準天頂衛星システム（ＱＺＳＳ）などであってもよい。情報が、対象物の位置、高度、速度、もしくは加速度、または現在の時間を含んでもよい。ナビゲーションシステム１７０が、１つまたは複数の衛星を、たとえば、衛星１７０−１、衛星１７０−２、および衛星１７０−３を含んでもよい。衛星１７０−１〜１７０−３が、上述の情報を独立に、または共同で決定してもよい。衛星ナビゲーションシステム１７０が、無線接続を介して、ネットワーク１２０、サービス要求者端末１３０、サービス提供者端末１４０、または車両１５０に上述の情報を送信してもよい。
【００３３】
いくつかの実施形態では、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素（たとえば、サーバ１１０、サービス要求者端末１３０、サービス提供者端末１４０など）が、データベース１６０にアクセスする許可を得てもよい。いくつかの実施形態では、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素が、１つまたは複数の条件が満たされたとき、乗客、サービス提供者、および／または公衆に関係がある情報を読み出してもよい、および／または修正してもよい。たとえば、サーバ１１０が、サービス終了後に、１つまたは複数の乗客の情報を読み出してもよい、および／または修正してもよい。別の実施例として、サーバ１１０が、サービス終了後に、１つまたは複数のサービス提供者の情報を読み出してもよい、および／または修正してもよい。
【００３４】
いくつかの実施形態では、オン・デマンド・サービス・システム１００内の１つまたは複数の構成要素による情報交換が、サービスを要求することによって開始されてもよい。サービスリクエストの対象が、任意の製品であってもよい。いくつかの実施形態では、製品が、食糧、医薬品、日用品、化学製品、電気器具、衣服、乗用車、住宅、ぜいたく品など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、製品が、サービス財、金融商品、知識製品、インターネット製品など、またはそれらの任意の組合せを含んでもよい。インターネット製品が、個々のホスト製品、ウェブ製品、移動体インターネット製品、商用ホスト製品、組込型製品など、またはそれらの任意の組合せを含んでもよい。移動体インターネット製品を、移動体端末のソフトウェア、プログラム、システムなど、またはそれらの任意の組合せの形で使用してもよい。移動体端末が、タブレットコンピュータ、ラップトップコンピュータ、携帯電話、携帯情報端末（ＰＤＡ）、スマートウォッチ、ＰＯＳ機器、車載コンピュータ、車載テレビ、ウェアラブル機器など、またはそれらの任意の組合せを含んでもよい。たとえば、製品が、コンピュータまたは携帯電話内で使用する、任意のソフトウェアおよび／またはアプリケーションであってもよい。ソフトウェアおよび／またはアプリケーションが、社交、ショッピング、輸送、娯楽、学習、投資など、またはそれらの任意の組合せに関係があってもよい。いくつかの実施形態では、輸送に関係があるソフトウェアおよび／またはアプリケーションが、走行ソフトウェアおよび／またはアプリケーション、車両スケジューリングソフトウェアおよび／またはアプリケーション、マッピングソフトウェアおよび／またはアプリケーションなどを含んでもよい。車両スケジューリングソフトウェアおよび／またはアプリケーションでは、車両が、馬、馬車、人力車（たとえば、手押し車、自転車、三輪車など）、乗用車（たとえば、タクシー、バス、自家用車など）、列車、地下鉄、船、航空機（たとえば、飛行機、ヘリコプタ、スペースシャトル、ロケット、熱気球など）など、またはそれらの任意の組合せを含んでもよい。
【００３５】
オン・デマンド・サービス・システム１００の要素が遂行するとき、要素が電気信号および／または電磁信号を通して遂行してもよいことを当業者は認識されよう。たとえば、サービス要求者端末１３０が、サービスリクエストをサーバ１１０に送り出すとき、サービス要求者端末１３０のプロセッサが、リクエストを符号化する電気信号を生成してもよい。このとき、サービス要求者端末１３０のプロセッサが、電気信号を出力ポートに送信してもよい。サービス要求者端末１３０が、有線ネットワークを介してサーバ１１０と通信する場合、出力ポートが、ケーブルに物理的に接続されてもよく、ケーブルが、サーバ１１０の入力ポートに電気信号をさらに伝送する。サービス要求者端末１３０が、無線ネットワークを介してサーバ１１０と通信する場合、サービス要求者端末１３０の出力ポートが、電気信号を電磁信号に変換する１つまたは複数のアンテナであってもよい。同様に、サービス提供者端末１３０が、電気信号または電磁信号を介してサーバ１１０から命令および／またはサービスリクエストを受信してもよい。サービス要求者端末１３０、サービス提供者端末１４０、および／またはサーバ１１０などの電子機器内部で、電子機器のプロセッサが、命令を処理し、命令を送り出し、および／または活動を遂行するとき、命令および／または活動が、電気信号を介して伝えられる。たとえば、プロセッサが、記憶媒体からデータを取り出す、または保存するとき、記憶媒体中の構造化データを読み出してもよい、または書き込んでもよい、記憶媒体の読出し／書込み機器に、電気信号を送り出してもよい。構造化データを、電子機器のバスを介して電気信号の形でプロセッサに伝送してもよい。この場合、電気信号が、１つの電気信号、一連の電気信号、および／または複数の別個の電気信号を指す場合がある。
【００３６】
図２は、本開示のいくつかの実施形態による代表的処理エンジン１１２を例示する構成図である。処理エンジン１１２が、獲得モジュール２１０、解析モジュール２２０、決定モジュール２３０、および予測モジュール２４０を含んでもよい。各モジュールが、以下の活動を遂行するように設計されたハードウェア回路、１つもしくは複数の記憶媒体に記憶された命令のセット、ならびに／またはハードウェア回路および１つもしくは複数の記憶媒体の任意の組合せであってもよい。
【００３７】
獲得モジュール２１０が、オンライン・オン・デマンド・サービス・システム１００から１つ（または複数）のルートに関連付けられる道路関係データを得るように構成されてもよい。いくつかの実施形態では、道路関係データを、電気信号として伝送してもよい。たとえば、道路関係データが、本開示の他の箇所で説明するように、電気信号、または道路関係データを符号化する電気信号により置換されても、またはそれと同等であってもよい。ルートが、輸送サービスに対応しても、または商品配送サービスに対応してもよい。輸送サービスが、タクシー呼出サービス、お抱え運転手サービス、急行貨物サービス、カープールサービス、バスサービス、短期運転者賃貸サービス、シャトルサービスなど、またはそれらの任意の組合せを含んでもよい。ルートが、少なくとも１つのユーザ端末、またはシステム１００などのオンライン・オン・デマンド輸送プラットフォームのサーバにより生成されてもよい。少なくとも１つのユーザ端末が、運転者などの少なくとも１つのサービス提供者、または乗客などのサービス要求者と関連づけられてもよい。たとえば、乗客端末が、輸送サービスに関するリクエストを送信した後に、輸送サービスに関する地図の形でルートを生成しても、またはプラットフォームから得てもよい。いくつかの実施形態では、ルートが、オンライン・オン・デマンド・サービス・システム１００に記録および／または記憶されてもよい。たとえば、輸送サービス中に、オンライン・オン・デマンド・サービス・システム１００が、ネットワーク１２０を介してルートに関係がある任意の情報を記録し、データベース１６０、またはオンライン・オン・デマンド・サービス・システム１００内の任意の構成要素に情報を記憶してもよい。
【００３８】
いくつかの実施形態では、獲得モジュール２１０が、オン・デマンド・サービス・システム１００で、複数のルートに関連付けられる道路関係データを獲得してもよい。たとえば、獲得モジュール２１０が、カープールサービスに関してオン・デマンド・サービス・プラットフォームで、この６か月の間に生成された複数のルートを獲得してもよい。いくつかの実施形態では、複数のルートを、異なるクラスタにさらに分割してもよい。たとえば、車両のタイプ、サービスのタイプ、ルートの領域、またはルートの時間間隔に基づき、ルートを分割してもよい。車両のタイプが、自家用車、タクシー、トラック、オートバイ、自律車両、電気自動車、自転車など、またはそれらの任意の組合せを含んでもよい。サービスのタイプが、貨物サービス、郵便サービス、食糧注文サービス、バスサービス、ヒッチハイキングサービス、特別車サービス、急行貨物サービス、車両賃貸サービス、運転サービス、お抱え運転手サービスなど、またはそれらの任意の組合せを含んでもよい。ルートの領域が、ルートの少なくとも一部が位置する、地図内の地理的位置および／または行政区域であってもよい。ルートの時間間隔が、ルートの開始時間および／または終了時間が属する期間であってもよい。単なる実施例として、１日（午前０時〜午後２４時）を複数の時間間隔に分割してもよい。単なる実施例として、時間間隔が、午前０時〜午前２時、午前２時〜午前４時、…、午後１１時〜午後２４時を含んでもよい。いくつかの実施形態では、時間間隔を、たとえば、休暇、仕事日、混雑時間、気象など、またはそれらの任意の組合せを含む他の情報に従って決定してもよい。ルートの開始時間または終了時間が、１つの時間間隔（たとえば、午前８時〜午前１０時）に属するとき、それに応じて、ルートが、この時間間隔（たとえば、午前８時〜午前１０時）に属してもよい。いくつかの実施形態では、１つのルートが、１つの時間間隔に属してもよい。いくつかの実施形態では、１つのルートが、少なくとも２つの時間間隔に属してもよい。
【００３９】
解析モジュール２２０が、ルートの大域特徴ベクトルおよび過去の走行継続時間を決定するように構成されてもよい。
【００４０】
大域特徴ベクトルが、ルートの特性を全体として記述するための数式表現（たとえば、ベクトル）であってもよい。たとえば、ルートが、少なくとも１つの道路区間を含んでもよい。大域特徴ベクトルが、ルート内の個々の区間の特徴だけではなく、異なる個々の区間の間の相互影響を反映する特徴もまた含んでもよい。
【００４１】
いくつかの実施形態では、大域特徴ベクトルが、１つの単一列または１つの単一行を有するベクトルであってもよい。大域特徴ベクトルが、Ｎ次元座標系に対応してもよい。各次元が、ルートの１つの項目または特徴に関連づけられてもよい。いくつかの実施形態では、大域特徴ベクトルが、少なくとも１つの道路区間のうち少なくとも２つの間の関係を含んでもよい。いくつかの実施形態では、大域特徴ベクトルの項目または特徴が、ルートと他のルートとの相互影響関係を除外してもよい。たとえば、大域特徴ベクトルを、ただ１つの単一ルートに従って決定してもよい。いくつかの実施形態では、大域特徴ベクトルの項目または特徴が、異なるルート間の相互影響関係を含んでもよい。たとえば、道路状況が、対象となるルートの道路状況に影響を及ぼす場合がある２つ以上のルート（たとえば、何１００ものルート、何１００万ものルート、または何１０億ものルートなど）に従って、対象となるルートの大域特徴ベクトルを決定してもよい。大域特徴ベクトルを、解析モジュール２２０によりさらに解析してもよい、または大域特徴ベクトルを使用して、複数のトレーニング実施例を含むトレーニング集合を確立してもよい。たとえば、機械学習法を使用することにより、トレーニング集合を使用して、決定モジュール２３０でモデルをトレーニングしても、または確立してもよい。
【００４２】
いくつかの実施形態では、大域特徴ベクトルが、たとえば、交通状態、運転距離、開始時間、開始位置、目的地位置、衛星測位サンプリング点のシーケンス、指定された道路レベルでの運転距離、道路区間数、交通信号を有する交差点の数、交通信号のない交差点の数、車両状態など、またはそれらの任意の組合せを含む、複数の項目または特徴（たとえば、数１００万もの項目または特徴）を含んでもよい。交通状態が、リアルタイムの道路速度、または推定道路速度を含んでもよい。運転距離が、ルート全体の距離、または道路区間の各々の距離を含んでもよい。開始時間が、乗客を乗せた時間、またはユーザ（たとえば、運転者）がサービスリクエストを受信した、もしくは確認した時間を含んでもよい。開始位置が、乗客を乗せた位置、または乗客が運転者を待つ位置であってもよい。衛星測位サンプリング点のシーケンスが、（たとえば、ＧＰＳシステムを介して）衛星により決定されてもよい車両の場所を含むシーケンスであってもよい。指定された道路レベルでの運転距離が、幹線道路、地方道路、一等道路、二等道路、三等道路などのような指定された道路レベルで車両が疾走する距離であってもよい。道路区間数が、１つのルート内の道路区間の総数であってもよい。車両状態が、輸送サービスリクエストに対するアクセス状態（たとえば、サービスリクエストを受け入れるための可用性）、応答確率、運転者の好み、車両タイプ、車両内にいる現在の乗客数、車両の最大乗客収容能力、車両の色、運転者のサービス水準、車両の現在の速度、車両に関係がある任意の情報など、またはそれらの任意の組合せを含んでもよい。
【００４３】
いくつかの実施形態では、別のシステム（たとえば、気象予報システム、交通誘導システム、または交通無線放送システムなど）からの情報に基づき、または少なくとも一部は基づき、大域特徴ベクトルを決定してもよい。オフライン情報が、気象条件、交通事故情報、交通渋滞状況、交通規制、またはルートに関係がある任意の情報を含んでもよい。気象条件が、リアルタイムの気象情報、実質的にリアルタイムの気象情報、気象予報情報などを含んでもよい。処理エンジン１１２が、データベース１６０、気象条件プラットフォーム（たとえば、気象予報ウェブサイト）、交通誘導プラットフォーム、および／またはこれらの情報を提供することができる、任意の他の機器から情報を得て、大域特徴ベクトルを決定してもよい。たとえば、ルートに関連付けられるデータ、およびルートに関係がある気象条件に基づき、大域特徴ベクトルを決定してもよい。
【００４４】
いくつかの実施形態では、ルートの過去の走行継続時間（たとえば、「過去の継続時間」）が、ルートで発生した過去の走行記録、たとえば、ルートを（開始位置から終了位置または目的地まで）通って運転した各車両の、記録された全時間であってもよい。いくつかの実施形態では、全時間が、たとえば、歩行時間、サイクリング時間、乗車時間、運転時間、飛行時間、乗船時間など、またはそれらの任意の組合せをさらに含んでもよい。
【００４５】
いくつかの実施形態では、解析モジュール２２０が、ルートに関連付けられる大域特徴ベクトルおよび過去の継続時間の構造データを生成および保存してもよい。構造化データを、Ｂ木またはハッシュテーブルに基づき構築または取り出してもよい。
【００４６】
決定モジュール２３０が、大域特徴ベクトルおよび過去の継続時間に基づき、推定到着時間（ＥＴＡ）モデルの構造化データを決定するように構成されてもよい。ＥＴＡモデルを使用して、ＥＴＡを予測してもよい。いくつかの実施形態では、ユーザ端末（たとえば、運転者端末）またはオンラインプラットフォーム（たとえば、ウェブサイト）で使用してもよいアプリケーションとして、ＥＴＡモデルを記憶してもよい。たとえば、輸送サービスのための運転者端末として使用してもよいスマートホンに、ＥＴＡモデルを送信してもよく、運転者は、一方の位置から別の位置に至るＥＴＡを予測するために、アプリケーションにログインしてもよい。別の実施例として、オンライン・オン・デマンド・サービス・システム１００（たとえば、データベース１６０）にモデルを記憶してもよく、乗客は、ネットワーク１２０または有線接続を介してオンラインでＥＴＡモデルをダウンロードまたは使用してもよい。いくつかの実施形態では、ＥＴＡモデルを記憶媒体に記憶してもよい。たとえば、オンライン・オン・デマンド・サービス・システム１００またはユーザ端末（たとえば、乗客端末）が使用してもよい非一時的コンピュータ可読記憶媒体（たとえば、ユニバーサル・シリアル・バス・フラッシュ・ディスク）にＥＴＡモデルを記憶してもよい。
【００４７】
いくつかの実施形態では、ＥＴＡを予測するために、ＥＴＡモデルを別のシステムにインストールしてもよい。たとえば、ＥＴＡを予測するために、自動車レースのためのビデオ・ゲーム・システムにＥＴＡモデルをインストールしてもよい。別の実施例として、ゲームパッドにおけるおもちゃの自動車制御システムで、おもちゃの自動車のＥＴＡを決定するために、ＥＴＡモデルを適用してもよい。さらに別の実施例として、ＥＴＡモデルを運転シミュレータでさらに使用して、運転シミュレータでレース・ドライバーまたは宇宙飛行士をトレーニングしてもよい。さらに別の実施例として、ＥＴＡモデルをパブリッククラウドで使用してもよく、パブリッククラウドにアクセスしてもよいユーザが、ＥＴＡモデルを使用してもよい。
【００４８】
少なくとも１つの道路区間を有する意図するルートに関連付けられる道路関係データを符号化する第２の電気信号に関するＥＴＡを決定するように、予測モジュール２４０を構成してもよい。意図するルートに関するＥＴＡを使用して、意図するルートの開始位置から終了位置に至る時間を決定してもよい。たとえば、開始位置と終了位置の間の意図するルートに関するＥＴＡを、５分、２時間、または１日などとして予測してもよい。
【００４９】
いくつかの実施形態では、ＥＴＡを動的に決定してもよい。たとえば、気象条件（たとえば、もや、もしくは雷雨）または交通事故情報に基づき、ＥＴＡを動的に調節してもよい。別の実施例として、車両がその運転モードを変更したとき、ＥＴＡを動的に調節してもよい。たとえば、車両が、非自動化モード、運転者支援モード、部分的自動化モード、条件付き自動化モード、高度自動化モード、および完全自動化モードのうち少なくとも２つを含んでもよい。車両が、これらのモードの１つから別のモードに切り替えたとき、ＥＴＡを動的に調節してもよい。
【００５０】
処理エンジン１１２内のモジュールが、有線接続または無線接続を介して、互いに接続されてもよく、または互いに通信してもよい。有線接続が、金属ケーブル、光ケーブル、ハイブリッドケーブルなど、またはそれらの任意の組合せを含んでもよい。無線接続が、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ、近距離無線通信（ＮＦＣ）など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、モジュールのうち任意の２つを組み合わせて、単一モジュールとしてもよく、およびモジュールの任意の１つを２つ以上のユニットに分割してもよい。
【００５１】
図３は、本開示のいくつかの実施形態による、輸送サービスに関するＥＴＡを決定するための、代表的な処理および／または方法３００を例示する流れ図である。処理および／または方法３００を、オン・デマンド・サービス・システム１００により実行してもよい。たとえば、処理および／または方法３００を、データベース１６０に記憶された命令のセット（たとえば、アプリケーション）として実装してもよい。処理エンジン１１２が、命令のセットを実行してもよく、それに応じて、オンライン・オン・デマンド・サービス・プラットフォームで処理および／または方法３００を遂行するように指示されてもよい。プラットフォームが、インターネットを通してオン・デマンド・サービス提供者および要求者を接続する、インターネットに基づくプラットフォームであってもよい。
【００５２】
ステップ３１０で、処理エンジン１１２が、ルートに関連付けられる道路関係データを得てもよい。いくつかの実施形態では、処理エンジン１１２により、電気信号を使用して道路関係データを符号化してもよい。ルートが、少なくとも１つの道路区間を有してもよい。道路レベル、交通信号、都市、州、国、地理的条件、道路もしくはルートに関係がある交通識別など、またはそれらの任意の組合せに基づき、または少なくとも一部は基づき、道路区間を分割してもよい。たとえば、道路レベルに基づき、道路区間を分割してもよい。道路レベルが、一等幹線道路、二等幹線道路、三等幹線道路、地方道路の区間など、またはそれらの任意の組合せを含んでもよい。
【００５３】
別の実施例として、交通信号および／または幹線道路出口などに基づき、道路区間を分割してもよい。それに応じて、ルートが、第１の道路区間、第２の道路区間、第３の区間、…、第Ｎの道路区間を含んでもよい。互いに隣接する２つの道路区間を、少なくとも１つの交通信号と連結してもよい。
【００５４】
さらに別の実施例として、地理的条件に基づき、道路区間を分割してもよい。たとえば、川、橋、線路、有料道路料金所など、またはそれらの任意の組合せを使用して、それに隣接する道路を２つの道路区間に分割してもよい。
【００５５】
いくつかの実施形態では、道路区間のデータが、同じルート内の別の道路区間だけではなく、別ルートからの１つまたは複数の道路区間によっても影響を受けてもよい。たとえば、ルート内の道路区間が、１つまたは複数の同じおよび／または異なるルートからの、１つまたは複数の別の道路区間と直接または間接的に関係があってもよい。たとえば、ある道路区間に関連付けられる第１の道路関係データ（たとえば、第１のルートの第１の道路区間で発生した自動車衝突）が、別の道路区間に関連付けられる第２の道路関係データ（たとえば、第２のルートの第２の道路区間の交通）に影響を及ぼしても、またはそれと相関関係があってもよい。別の実施例として、ある単一ルートが、交通信号により連結されてもよい２つの道路区間を含んでもよい。第１の道路区間での交通事故が、第２の道路区間での走行速度に影響を及ぼす場合がある、または第１の道路区間での交通混雑（たとえば、事故が引き起こした交通混雑）が第２の道路区間に広がり、続いて第２の道路区間での交通混雑を引き起こす場合がある。さらに別の実施例として、幹線道路が、緑の車線境界線により接続された２つの反対側のルートを含む場合、第１のルート内のある道路区間での車両制限が、第１のルートと反対側の第２のルート内の別の道路区間で交通混雑を引き起こす場合がある。
【００５６】
いくつかの実施形態では、道路区間および／またはルートの間の関係を、関数、パラメータ、値、しきい値、ベクトル、重み、定数など、またはそれらの任意の組合せにより量子化してもよい。単なる実施例として、互いに隣接する２つの道路区間が、０．７〜０．９の重みを指定された関係を有してもよく、および互いに離れた２つの道路区間が、０．１〜０．３の重みを指定されてもよい。
【００５７】
いくつかの実施形態では、処理エンジン１１２が、地図に従って、複数のルートを得てもよい。地図が、ナビゲーション地図、衛星地図、行政図、道路に基づく地図、地下鉄に基づく地図、線路に基づく地図、地形図、幹線道路地図、観光地図など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、地図を統合しても、修正または変更してもよい。たとえば、ナビゲーション地図、衛星地図、および道路に基づく地図を統合して、修正された地図としてもよい。いくつかの実施形態では、処理エンジン１１２が、都市または地区に対応する地図に従って、複数のルートを得てもよい。たとえば、ニューヨーク州、またはニューヨーク州のロングアイランド地区に対応する地図に従って、複数のルートを得てもよい。別の実施例として、処理エンジン１１２が、米国幹線道路システムの地図に従って、時間間隔の間中のルートをすべて得てもよい。
【００５８】
いくつかの実施形態では、ルートが、互いに直接または間接的に影響を受ける場合がある。たとえば、吹雪が米国の西海岸を襲った場合、ワシントン州では複数のルートの速度が落ちる場合があり、これが、アイダホ州で複数のルートの速度に影響を及ぼす場合がある。別の実施例として、新設された道路が、新設された道路に近い複数のルートに影響を及ぼす（たとえば、交通状況を拡大する）場合がある。
【００５９】
いくつかの実施形態では、ルートに関連付けられる道路関係データが、リクエストデータ、注文データ、取引データ、地図データ、交通システムのデータ、気象に関係があるデータ、ユーザデータ、ルートで計測した任意のデータなど、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、道路関係データを、量子化により得てもよい。たとえば、通りの名前を、通りの名前および対応する数値を集めるルックアップテーブルに基づき、数値に量子化してもよい。いくつかの実施形態では、ルートに基づき、または少なくとも一部は基づき、道路関係データを解析してもよい。たとえば、国民の祝日に際して、市条例がＡＢＣ街に交通規制を加える場合、または代わりに、ＡＢＣ街が非常に激しい交通量を経験する場合がある。それに応じて、処理エンジン１１２が、ＡＢＣ街に交通規制を加えることを決定し、ＡＢＣ街での交通規制に対応する道路関係データを得てもよい。別の実施例として、処理エンジン１１２が、ユーザのＩＤ番号（たとえば、運転者の運転免許証番号、および／または運転者の社会保障番号）を得た場合、処理エンジン１１２が、ＩＤ番号に従って、データベース（たとえば、公安部により確立されてもよい公安ネットワークデータベース）からユーザのユーザデータを得てもよい。
【００６０】
ルートに関連付けられる道路関係データを符号化する電気信号を、運転者端末または乗客端末により生成してもよい。たとえば、移動体機器１１００により実装された運転者端末により、電気信号を伝送してもよく、および電気信号を、処理エンジン１１２により受信してもよい。いくつかの実施形態では、電気信号を、有線接続または有線接続を介して伝送してもよい。たとえば、処理エンジン１１２が、ネットワーク１２０を介してデータベース１６０から電気信号を得てもよい。
【００６１】
ステップ３２０で、処理エンジン１１２が、道路関係データに基づきルートに関連付けられる、大域特徴ベクトルの構造化データおよび過去の継続時間の構造化データを決定してもよい。大域特徴ベクトルの構造化データおよび／または過去の継続時間の構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。大域特徴ベクトルおよび過去の継続時間を使用して、複数のトレーニングサンプルを生成してもよい。複数のトレーニングサンプルが、潜在的に予測可能な関係を発見するために、または予測のためのモデルを確立するために使用してもよいトレーニング集合を形成してもよい。
【００６２】
いくつかの実施形態では、大域特徴ベクトルが、たとえば、交通状態、運転距離、開始時間、開始位置、目的地位置、衛星測位サンプリング点のシーケンス、指定された道路レベルでの運転距離、道路区間数、交通信号を有する交差点の数、交通信号のない交差点の数、車両状態など、またはそれらの任意の組合せを含む、複数の項目または特徴を含んでもよい。交通状態が、リアルタイムの道路速度、または推定道路速度を含んでもよい。運転距離が、ルート全体の距離、または道路区間の各々の距離を含んでもよい。開始時間が、乗客を乗せた時間、またはユーザ（たとえば、運転者）がサービスリクエストを受信した、もしくは確認した時間を含んでもよい。開始位置が、乗客を乗せた位置、または乗客が運転者を待つ位置であってもよい。衛星測位サンプリング点のシーケンスが、車両の場所を含むシーケンスであってもよい。車両の場所を、（たとえば、ＧＰＳシステムを介して）衛星により決定してもよい。指定された道路レベルでの運転距離が、幹線道路、地方道路、一等道路、二等道路、三等道路などのような指定された道路レベルで車両が疾走する距離であってもよい。道路区間数が、１つのルート内の道路区間の総数であってもよい。車両状態が、輸送サービスリクエストに対するアクセス状態（たとえば、サービスリクエストを受け入れるための可用性）、応答確率、運転者の好み、車両タイプ、車両内にいる現在の乗客数、車両の最大乗客収容能力、車両の色、運転者のサービス水準、車両の現在の速度など、またはそれらの任意の組合せを含んでもよい。
【００６３】
いくつかの実施形態では、大域特徴ベクトルが、総合特徴ベクトルを含んでもよい。互いに関係がある道路区間から、総合特徴ベクトルを決定してもよい。いくつかの実施形態では、総合特徴ベクトルが、１つまたは複数の同じおよび／または異なるルートからの少なくとも１つの道路区間と連携してもよい。たとえば、１つの単一ルート内の道路区間から、総合特徴ベクトルを決定してもよい。別の実施例として、２つ以上のルート（たとえば、２つの隣接するルート）内の道路区間から、総合特徴ベクトルを決定してもよい。
【００６４】
いくつかの実施形態では、領域内の、または地図（たとえば、ナビゲーション地図）の範囲内にある、すべての道路区間に基づき、総合特徴ベクトルを決定してもよい。たとえば、運転者端末内にナビゲーション地図をインストールしてもよい。ナビゲーション地図が、たとえば、２００個の道路区間を有してもよく、処理エンジン１１２が、２００個の道路区間から総合特徴ベクトルを決定してもよい。いくつかの実施形態では、領域または地図のサイズを、運転者、乗客、または処理エンジン１１２により調節または修正してもよい。たとえば、処理エンジン１１２が、北京の行政図内にある３５００個の道路区間に関連付けられる道路関係データを得てもよい。別の実施例として、処理エンジン１１２が、北京の行政図のサイズを制限して、関心のある領域にすることにより、３００個の道路区間を選択してもよい。別の実施例として、処理エンジン１１２が、領域または地図を２つ以上の副領域（たとえば、１０個の同等の副領域）に分割してもよい。副領域の各々内にある道路区間を使用して、総合特徴ベクトルを決定してもよい。いくつかの実施形態では、処理エンジン１１２が、副領域に従って２つ以上の総合特徴ベクトル（たとえば、１０個の総合特徴ベクトル）を決定してもよい。
【００６５】
いくつかの実施形態では、大域特徴ベクトルを、１つの列または１つの行を有するベクトルとして表現してもよい。たとえば、大域特徴ベクトルが、１×Ｎの行列式（たとえば、１×２５の行列式）として表現した行ベクトルであってもよい。別の実施例として、大域特徴ベクトルが、Ｎ×１の行列式（たとえば、２００×１の行列式）として表現してもよい列ベクトルであってもよい。いくつかの実施形態では、大域特徴ベクトルが、Ｎ次元座標系に対応してもよい。Ｎ次元座標系を、ルートのＮ個の項目または特徴と関連づけてもよい。いくつかの実施形態では、処理エンジン１１２により、１つまたは複数の大域特徴ベクトルを処理してもよい。たとえば、３つの大域特徴ベクトル（たとえば、３つの行ベクトル）を、３×Ｎの行列式に統合してもよい。別の実施例として、Ｎ個の大域特徴ベクトル（たとえば、Ｎ個の１×Ｎの行ベクトル）を、Ｎ×Ｎの行列式に統合してもよい。
【００６６】
たとえば、図９を参照すると、ルート９００を道路に基づく地図で示す。ルート９００が、１０個の道路区間（たとえば、第１の道路区間、第２の道路区間、…、第１０の道路区間）および９個の交通信号（たとえば、第１の交通信号、第２の交通信号、…、第９の交通信号）を含んでもよい。２つの隣接する道路区間が、１つまたは複数の交通信号で連結される。道路区間での速度の各々に基づき、道路区間の各々を通過する時間を決定してもよい。たとえば、第１の道路区間を通過する時間をＴ１として決定してもよく、第２の道路区間を通過する時間をＴ２として決定してもよく、…、および第１０の道路区間を通過する時間をＴ１０として決定してもよい。交通信号の各々を通過する時間を、Ｌ１、Ｌ２、…、およびＬ９として決定してもよい。処理エンジン１１２が、ルート９００内の道路区間に従って、大域特徴ベクトルを決定してもよい。大域特徴ベクトルが、地図中のすべての道路区間に関連付けられる道路関係データを含んでもよく、たとえば、大域特徴ベクトルが、第１の道路区間から第２７の道路区間に至る道路関係データを含んでもよい。
【００６７】
各道路区間に関連付けられる道路関係データが、リクエストデータ、注文データ、取引データ、地図データ、交通システムのデータ、気象に関係があるデータ、ユーザデータなど、またはそれらの任意の組合せを含んでもよい。大域特徴ベクトルが、地図中の道路区間の関係を表すデータをさらに含んでもよい。道路区間の関係が、地図中の任意の２つの道路区間の間の関係、または地図中の任意の３つ以上の道路区間の間の関係を含んでもよい。任意の２つの道路区間の間のいくつかの関係が、２７個のうち２つの組合せであってもよい。地図中の道路区間の関係を表すデータを、関数、パラメータ、値、しきい値、ベクトル、重み、定数など、またはそれらの任意の組合せとして表現してもよい。道路区間の関係を表すデータを、公式（たとえば、ピアソンの積率相関係数）により決定してもよい。いくつかの実施形態では、道路区間の関係を表すデータを、Ｍ列Ｍ行の行列に基づき生成してもよく、ここで、Ｍが、地図中の２７個の道路区間を表す任意の整数であってもよい。行列が、たとえば、次式のように疎に記述されてもよい。
【００６８】
【数１】
2019507316.tif 000003
【００６９】
式中、対角線の場所の値、たとえば、第２列第２行の値が、１であってもよい。これは、第２の道路区間が、それ自身と１００％の相関関係があることを表してもよい。第１列第２行の値が、０．２であってもよく、これは、第２の道路区間が、第１の道路区間と２０％の相互影響関係があることを表してもよい。行列内の値の大部分が、０であってもよく、これは、対応する２つの道路区間が、相関関係がないことを表してもよい。
【００７０】
ステップ３３０で、処理エンジン１１２が、大域特徴ベクトルおよび過去の継続時間に基づき、推定到着時間（ＥＴＡ）モデルを決定してもよい。
【００７１】
いくつかの実施形態では、処理エンジン１１２が、機械学習法を使用して、ＥＴＡモデルを決定してもよい。いくつかの実施形態では、機械学習法が、決定木アルゴリズム、アソシエーション・ルール・アルゴリズム、人工ニューラル・ネットワーク・アルゴリズム、ディープ・ラーニング・アルゴリズム、帰納的論理プログラミングアルゴリズム、サポート・ベクター・マシン・アルゴリズム、クラスタリングアルゴリズム、ベイジアン・ネットワーク・アルゴリズム、強化学習アルゴリズム、表現学習アルゴリズム、類似度および計量学習アルゴリズム（ｓｉｍｉｌａｒｉｔｙ  ａｎｄ  ｍｅｔｒｉｃ  ｌｅａｒｎｉｎｇ  ａｌｇｏｒｉｔｈｍ）、スパース辞書学習アルゴリズム、遺伝的アルゴリズム、ルールベース機械学習アルゴリズムなど、またはそれらの任意の組合せを含んでもよい。
【００７２】
いくつかの実施形態では、処理エンジン１１２が、決定木アルゴリズムを使用して、ＥＴＡモデルを決定してもよい。決定木アルゴリズムが、ＩＤ３（ｉｔｅｒａｔｉｖｅ  ｄｉｃｈｏｔｏｍｉｓｅｒ  ３）アルゴリズム、分類木・回帰木（ｃｌａｓｓｉｆｉｃａｔｉｏｎ  ａｎｄ  ｒｅｇｒｅｓｓｉｏｎ  ｔｒｅｅ）アルゴリズム、ＩＤ３の後継アルゴリズム、ＣＨＡＩＤ（ＣＨｉ−ｓｑｕａｒｅｄ  ａｕｔｏｍａｔｉｃ  ｉｎｔｅｒａｃｔｉｏｎ  ｄｅｔｅｃｔｏｒ）アルゴリズム、条件付き推論木アルゴリズムなど、またはそれらの任意の組合せを含んでもよい。
【００７３】
いくつかの実施形態では、ＥＴＡモデルを、構造化データとしての形で記憶媒体に保存してもよい。ＥＴＡモデルの構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。
【００７４】
ステップ３４０で、処理エンジン１１２が、ＥＴＡモデルの構造化データを非一時的コンピュータ可読記憶媒体に保存してもよい。いくつかの実施形態では、処理エンジン１１２が、意図するルートに関するＥＴＡを処理する電子機器に、ＥＴＡモデルの構造化データを送信してもよい。非一時的コンピュータ可読記憶媒体が、ユニバーサル・シリアル・バス・フラッシュ・ディスク、ハードディスク、ＳＳＤ、ＣＤ  ＲＯＭ、および／または任意のコンピュータ可読一時的もしくは非一時的メモリを含んでもよい。たとえば、処理エンジン１１２が、ＥＴＡモデルの構造化データをハードディスクに保存してもよく、運転者端末は、ハードディスクを読み出して、ＥＴＡモデルの構造化データを得てもよい。
【００７５】
ＥＴＡモデルを、構造化データとして記憶し、アプリケーションの命令のセットとして実装し、電子機器にインストールしてもよい。電子機器が、スマートホン、携帯情報端末（ＰＤＡ）、タブレットコンピュータ、ラップトップ、カーピュータ（ボードコンピュータ）、プレイステーション・ポータブル（ｐｌａｙ  ｓｔａｔｉｏｎ  ｐｏｒｔａｂｌｅ、ＰＳＰ）、スマートメガネ、スマートウォッチ、ウェアラブル機器、仮想表示機器、もしくは表示強化設備（たとえば、Ｇｏｏｇｌｅ（登録商標）グラス、オキュラスリフト、ホロレンズ、ギアＶＲなど）など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、電子機器が、オンライン・オン・デマンド・サービス・システム１００の構成要素（たとえば、データベース１６０）であってもよい。電子機器が、ネットワーク１２０を介してオンライン・オン・デマンド・サービス・システム１００内の任意の構成要素からダウンロードすることにより、ＥＴＡモデルを得てもよい。いくつかの実施形態では、電子機器が、非一時的コンピュータ可読記憶媒体（たとえば、ユニバーサル・シリアル・バス・フラッシュ・ディスク、ハードディスク、ＳＳＤ、ＣＤ  ＲＯＭ、および／または任意のコンピュータ可読一時的もしくは非一時的メモリなど）からＥＴＡモデルを得てもよい。
【００７６】
図４は、本開示のいくつかの実施形態による、意図するルートに関するＥＴＡを決定するための、代表的な処理および／または方法４００を例示する流れ図である。処理および／または方法４００を、オンライン・オン・デマンド・サービス・システム１００により実行してもよい。たとえば、処理および／または方法４００を、データベース１６０に記憶された命令のセット（たとえば、アプリケーション）として実装してもよい。処理エンジン１１２が、命令のセットを実行してもよく、それに応じて、電気信号を受信および／または送信することによって、オンライン・オン・デマンド・サービス・プラットフォームで処理および／または方法４００を遂行するように指示されてもよい。プラットフォームが、インターネットを通してオン・デマンド・サービス提供者および要求者を接続する、インターネットに基づくプラットフォームであってもよい。
【００７７】
ステップ４１０で、処理エンジン１１２が、少なくとも１つの道路区間を有するルートを得てもよい。
【００７８】
いくつかの実施形態では、処理エンジン１１２が、道路に基づく地図（たとえば北京の道路に基づく地図）を選択してもよく、道路に基づく地図に関連付けられるルートを得てもよい。一定期間の間（たとえば、この３か月、またはこの半年）オンライン・オン・デマンド・サービス・システム１００により、ルートを記録してもよい。たとえば、運転者が、オンライン・オン・デマンド・サービス・システム１００からサービスリクエストを得てもよい。乗客端末を使用して、乗客によりサービスリクエストを伝送してもよい。運転者がサービスリクエストを確認した後、オンライン・オン・デマンド・サービス・システム１００が、サービスリクエストに対応するルートに関連付けられる道路関係データを記録し始めてもよい。いくつかの実施形態では、処理エンジン１１２が、北京の道路に基づく地図に従って、一定期間の間、何１００万ものルート、または何１０億ものルートを記録してもよい。いくつかの実施形態では、ルートのうち任意の２つを、互いに関係づけてもよい。たとえば、ニューヨーク市の５番街での事故が、５番街で交通を遮断する場合がある。５番街での交通を避けるために、ますます多くの運転者が、ニューヨーク市の５番街から１３８番街に方向を変える場合がある。多数の車両が５番街と１３８番街の間を走るので、５番街と１３８番街の間にあるすべての大通りのルートが、激しい交通状態（たとえば、徐行）になる場合がある。いくつかの実施形態では、ルートが、少なくとも１つの道路区間を含んでもよい。複数の道路区間が、２つの交通信号間の道路区間、異なる道路レベルの間の道路区間、橋により連結された道路区間、川により分離された道路区間、線路により分割された道路区間、固定距離（たとえば、１マイル、もしくは２キロメートル）を有する道路区間、異なる行政領域（たとえば、異なる都市、異なる州、もしくは異なる国）間の道路区間、乗客を乗せることの各々に対応する道路区間、同じもしくは異なる道路属性を有する道路区間など、またはそれらの任意の組合せを含んでもよい。たとえば、ルートが、類似する道路属性を有する少なくとも１つの道路区間（たとえば、５０個の道路区間）を含んでもよい。たとえば、ルートが、２つの交通信号間の区間を含んでもよい。道路幅、速度制限、気象条件などのような、区間の道路状況が、この区間全体を通して同じであってもよい。したがって、ルートの区間をルートの単一区間として記述してもよい。
【００７９】
ルートの少なくとも１つの道路区間を、互いに直接または間接的に関係づけてもよい。たとえば、第１の道路区間が、第２の道路区間と連結された場合、第２の道路区間と関係があってもよい。第１の道路区間での速度が、第２の道路区間での速度に影響を及ぼしても、またはそれと相関関係があってもよい。別の実施例として、第１のルート内の道路区間を、第２のルート内の道路区間に関係づけてもよい。第１のルート内の道路区間が第２のルート内の道路区間に近接する、または近い場合、第１のルート内の道路区間での交通事故が、第２のルート内の道路区間での速度に影響を及ぼす場合がある。さらに別の実施例として、地区または都市で大規模な活動（たとえば、オリンピック大会または万国博覧会）が主催される場合、地区または都市の複数の道路区間の激しい交通が、すぐ近くの地区またはすぐ近くの都市の道路区間の速度に影響を及ぼす場合がある。
【００８０】
いくつかの実施形態では、道路区間および／またはルートの間の関係を、関数、パラメータ、値、しきい値、ベクトル、重み、定数など、またはそれらの任意の組合せにより量子化してもよい。単なる実施例として、互いに隣接する２つの道路区間が、０．７〜０．９の重みを指定された関係を有してもよく、および互いに離れた２つの道路区間が、０．１〜０．３の重みを指定されてもよい。
【００８１】
ステップ４２０で、処理エンジン１１２が、複数の道路区間を有するルートに基づき、道路関係データを得てもよい。いくつかの実施形態では、処理エンジン１１２により、電気信号を使用して道路関係データを符号化してもよい。
【００８２】
処理エンジン１１２が、データベース１６０、またはオンライン・オン・デマンド・サービス・システム１００内の任意の構成要素から道路関係データを得てもよい。いくつかの実施形態では、道路関係データを、ユーザ端末（たとえば、サービス要求者端末１３０またはサービス提供者端末１４０）から得てもよい。たとえば、処理エンジン１１２が、リクエスト、サービスリクエスト、取引、ナビゲーション情報、ユーザ端末内の電子地図など、またはそれらの任意の組合せを解析することにより、運転者端末または乗客端末から道路関係データを得てもよい。
【００８３】
ステップ４３０で、処理エンジン１１２が、道路関係データを符号化する電気信号に基づき、大域特徴ベクトルを決定してもよい。いくつかの実施形態では、処理エンジン１１２が、道路関係データを使用して、データライブラリ、データシート、行列、シーケンス、集合、データを組織化してもよい任意の表現など、またはそれらの任意の組合せを構築してもよい。たとえば、運転者端末から道路関係データを得る場合、処理エンジン１１２が、道路関係データを使用して、たとえば、Ｎ列Ｎ行を含む疎行列を生成してもよい。いくつかの実施形態では、疎行列が、たとえば、開始位置、目的地、開始時間、待ち時間、取引時間、性別、顧客のコメント、運転経験など、またはそれらの任意の組合せを含む項目または特徴を含んでもよい。処理エンジン１１２が、疎行列から１つまたは複数の項目または特徴を選択して、大域特徴ベクトルを決定してもよい。
【００８４】
いくつかの実施形態では、処理エンジン１１２が、道路関係データに基づき、総合特徴ベクトルを決定してもよい。たとえば、運転者端末のナビゲーション地図の範囲内にあるすべての道路区間に関連付けられる道路関係データを使用して、総合特徴ベクトルを決定してもよい。別の実施例として、道路関係データを、互いに関係があってもよい、少なくとも１つの道路区間と関連づけてもよい。関係がある道路区間に関連付けられる道路関係データを使用して、総合特徴ベクトルを決定してもよい。本開示によれば、総合特徴ベクトルを決定するための方法または処理について、他の箇所のように説明する場合がある。
【００８５】
ステップ４４０で、処理エンジン１１２が、道路関係データに基づき、過去の継続時間を決定してもよい。処理エンジン１１２が、道路関係データから過去の継続時間を直接得てもよい。たとえば、処理エンジン１１２が、データベース１６０から過去の継続時間を得てもよい。別の実施例として、処理エンジン１１２が、開始時間と終了時間の間の時間を計算することにより、過去の継続時間を決定してもよい。いくつかの実施形態では、過去の継続時間が、大域特徴ベクトルに対応していてもよく、大域特徴ベクトルの各々、およびその対応する過去の継続時間が、機械学習中にトレーニングサンプルとして決定されてもよい。たとえば、大域特徴ベクトルの各々を、入力として決定してもよく、大域特徴ベクトルの各々の対応する過去の継続時間を、機械学習中にラベルとして決定してもよい。別の実施例として、何１００万もの大域特徴ベクトル、およびそれらの対応する何１００万もの過去の継続時間を使用して、ＥＴＡモデルをトレーニングしてもよい。
【００８６】
いくつかの実施形態では、大域特徴ベクトルおよび過去の継続時間が、構造化データの形であってもよい。大域特徴ベクトルの構造化データおよび／または過去の継続時間の構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。
【００８７】
ステップ４５０で、処理エンジン１１２が、大域特徴ベクトルおよび過去の継続時間に基づき、推定到着時間（ＥＴＡ）モデルをトレーニングしてもよい。いくつかの実施形態では、何１００万もの大域特徴ベクトルおよび何１００万もの過去の継続時間を使用して、ＥＴＡモデルをトレーニングしてもよい。処理エンジン１１２を、ＥＴＡモデルをトレーニングする処理を実装するためのプログラミング言語のために使用してもよい。プログラミング言語が、Ｃプログラミング言語、Ｊａｖａ（登録商標）プログラミング言語、ＰＨＰプログラミング言語、ＪａｖａＳｃｒｉｐｔ（登録商標）プログラミング言語、Ｃ＋＋プログラミング言語、Ｐｙｔｈｏｎプログラミング言語、シェルプログラミング言語、Ｒｕｂｙプログラミング言語、Ｏｂｊｅｃｔｉｖｅ−Ｃプログラミング言語、Ｃ＃プログラミング言語など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、ＥＴＡモデルをトレーニングする処理を、ＭＡＴＬＡＢ（ｍａｔｒｉｘ  Ｌａｂｏｒａｔｏｒｙ）、ＲａｐｉｄＭｉｎｅｒ、Ｏｒａｎｇｅ、ＯｐｅｎＣＶ（ｏｐｅｎ  ｓｏｕｒｃｅ  ｃｏｍｐｕｔｅｒ  ｖｉｓｉｏｎ  ｌｉｂｒａｒｙ）、ＳＰＡＡ（ｓｔａｔｉｓｔｉｃａｌ  ｐｒｏｄｕｃｔ  ａｎｄ  ｓｅｒｖｉｃｅ  ｓｏｌｕｔｉｏｎｓ）、ＳＡＳ（ｓｔａｔｉｓｔｉｃａｌ  ａｎａｌｙｓｉｓ  ｓｙｓｔｅｍ）など、またはそれらの任意の組合せを含むコンピュータソフトウェアにより実装してもよい。コンピュータソフトウェアの各々（たとえば、ＭＡＴＬＡＢ）が、モデルをトレーニングするための複数のアルゴリズムを含んでもよい。
【００８８】
いくつかの実施形態では、ＥＴＡモデルが、構造化データの形であってもよい。ＥＴＡモデルの構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。
【００８９】
ステップ４６０で、処理エンジン１１２が、意図するルートを得てもよい。意図するルートが、乗客によりタクシーまたは自家用車に関して生成されてもよいリクエストに対応していてもよい。オンライン・オン・デマンド・サービス・システム１００が、リクエストを受信し、リクエストの内容（たとえば、開始位置、開始時間、または目的地など）に基づき、意図するルートを決定してもよい。いくつかの実施形態では、運転者が、オンライン・オン・デマンド・サービス・システム１００からサービスリクエストを確認または受信したとき、意図するルートを運転者端末から得てもよい。いくつかの実施形態では、乗客が、輸送サービスに関するリクエストを確立し、オンライン・オン・デマンド・サービス・システム１００から伝送されたサービスリクエストを確認したとき、意図するルートを乗客端末から得てもよい。いくつかの実施形態では、処理エンジン１１２が、地図（たとえば、北京の道路に基づく地図）に対応してもよい複数の意図するルートを得てもよく、複数の意図するルートを互いに直接または間接的に関係づけてもよい。いくつかの実施形態では、意図するルートが、本開示の他の箇所で、たとえば、ステップ３１０で、および／またはステップ４１０で説明するように、少なくとも１つの道路区間を含んでもよい。
【００９０】
ステップ４７０で、処理エンジン１１２が、意図するルートに基づき、意図する大域特徴ベクトルを決定してもよい。いくつかの実施形態では、意図する大域特徴ベクトルが、Ｎ次元を有してもよく、ここで、Ｎが、意図するルートから得たＮ個の項目または特徴に対応してもよい。たとえば、処理エンジン１１２が、意図するルートから２０００個の項目または特徴を選択してもよい場合、意図するルートに関する意図する大域特徴ベクトルとして、２０００列または２０００行を含むベクトルを決定してもよい。
【００９１】
いくつかの実施形態では、意図する大域特徴ベクトルの次元が、大域特徴ベクトルの次元よりも小さくてもよい。意図するルートで１つまたは複数の項目または特徴が欠けている場合、意図するルートに対応する意図する大域特徴ベクトルの次元が低下し、失われた次元を有する、意図する大域特徴ベクトルとなる（たとえば、Ｒ列またはＲ行のベクトル、ここで、Ｒが、Ｎよりも小さくてもよい）。いくつかの実施形態では、意図するルートで１つまたは複数の項目または特徴が欠けている場合、処理エンジン１１２が、依然としてＮ列またはＮ行の意図する大域特徴ベクトルを決定してもよく、欠けている項目に対応する列または行を、デフォルト値（たとえば、ゼロ）により記述してもよい。
【００９２】
ステップ４８０で、処理エンジン１１２が、ＥＴＡモデル、および意図する大域特徴ベクトルに基づき、意図するルートに関するＥＴＡを決定してもよい。処理エンジン１１２が、意図する大域特徴ベクトルを、ＥＴＡモデルへの入力として決定してもよく、ＥＴＡモデルが、入力に従う出力になってもよい。たとえば、運転者が、タクシーに関するリクエストをオンライン・オン・デマンド・サービス・システム１００に送信する場合、１つまたは複数の道路区間を有する意図するルートを決定してもよい。処理エンジン１１２が、意図するルートに従って、Ｎ次元の意図する大域特徴ベクトルを決定してもよく、処理エンジン１１２が、意図する大域特徴ベクトルをＥＴＡモデルに入力することにより、意図するルートに関するＥＴＡをさらに決定してもよい。いくつかの実施形態では、ステップ４８０を、スマートホン、携帯情報端末（ＰＤＡ）、タブレットコンピュータ、ラップトップ、カーピュータ（ボードコンピュータ）、プレイステーション・ポータブル（ＰＳＰ）、スマートメガネ、スマートウォッチ、ウェアラブル機器、仮想表示機器、表示強化設備（たとえば、Ｇｏｏｇｌｅ（登録商標）グラス、オキュラスリフト、ホロレンズ、もしくはギアＶＲ）など、またはそれらの任意の組合せのような電子機器内に実装してもよい。
【００９３】
図５は、本開示のいくつかの実施形態による、ＥＴＡサブモデル、および意図するルートのシナリオに基づき、意図するルートに関するＥＴＡを決定するための、代表的な処理および／または方法５００を例示する流れ図である。処理および／または方法５００を、オン・デマンド・サービス・システム１００により実行してもよい。たとえば、処理および／または方法５００を、データベース１６０に記憶された命令のセット（たとえば、アプリケーション）として実装してもよい。処理エンジン１１２が、命令のセットを実行してもよく、それに応じて、オンライン・オン・デマンド・サービス・プラットフォームで処理および／または方法５００を遂行するように指示されてもよい。プラットフォームが、インターネットを通してオン・デマンド・サービス提供者および要求者を接続する、インターネットに基づくプラットフォームであってもよい。
【００９４】
ステップ５１０で、処理エンジン１１２が、少なくとも１つの道路区間を有するルートを得てもよい。ルートに関するさらに多くの説明を、本開示の他の箇所で、たとえば、ステップ３１０で、および／またはステップ４１０で得てもよい。
【００９５】
ステップ５２０で、処理エンジン１１２が、ルートに基づき、ルートのシナリオを決定してもよい。シナリオが、ルートの領域、またはルートの時間間隔を含んでもよい。ルートの領域を、ルートの開始位置、ルートの目的地、ルートがそばを通る、もしくは中を通過する行政地区など、またはそれらの任意の組合せに基づき決定してもよい。たとえば、処理エンジン１１２が、地図を領域（たとえば、混雑している領域、中心業務地区（ｃｅｎｔｒａｌ  ｂｕｓｉｎｅｓｓ  ｄｉｓｔｒｉｃｔ、ＣＢＤ）領域、鉄道駅の周囲の領域など）に分割してもよい場合、ルートに関連付けられる運転者が、開始位置で乗客を乗せてもよく、開始位置が、ＣＢＤ領域内にあってもよく、処理エンジン１１２が、ＣＢＤ領域としてルートのシナリオを決定してもよい。いくつかの実施形態では、処理エンジン１１２が、（たとえば、鉄道駅の周囲の領域で）同じまたは類似するシナリオを有するルートを集めてもよい。たとえば、処理エンジン１１２が、この３日間のＣＢＤ領域内のルートを得てもよい。別の実施例として、処理エンジン１１２が、混雑時間（たとえば、午前７時〜午前９時）中のルートを集めてもよい。
【００９６】
ステップ５３０で、処理エンジン１１２が、少なくとも１つの道路区間を有するルートに基づき、道路関係データを得てもよい。いくつかの実施形態では、処理エンジン１１２により、電気信号を使用して道路関係データを符号化してもよい。処理エンジン１１２が、ユーザ端末（たとえば、運転者端末もしくは乗客端末）、またはオンライン・オン・デマンド・サービス・システム１００内の任意の構成要素から道路関係データを得てもよい。たとえば、処理エンジン１１２が、同じまたは類似するシナリオ（たとえば、北京西駅に近い）を有するルートに関連付けられる道路関係データを運転者端末から受信してもよい。たとえば、処理エンジン１１２が、混雑時間（たとえば、午前７時〜午前９時）中のルートに関連付けられる道路関係データをデータベース１６０から得てもよい。
【００９７】
ステップ５４０で、処理エンジン１１２が、道路関係データに基づき、大域特徴ベクトルおよび過去の継続時間を決定してもよい。ルートに関連付けられる大域特徴ベクトルが、同じルートに関連付けられる過去の継続時間に対応してもよく、シナリオでの（たとえば、ＣＢＤ領域内での）各大域特徴ベクトル、および対応する過去の継続時間を、トレーニングサンプルとして決定してもよく、トレーニングサンプルを使用して、推定到着時間サブモデルを決定するために使用してもよいトレーニング集合を形成してもよい。同じまたは類似するシナリオに関連付けられるトレーニング集合が、何１００ものトレーニングサンプル、または何１００万ものトレーニングサンプルを含んでもよい。
【００９８】
いくつかの実施形態では、大域特徴ベクトルおよび過去の継続時間が、構造化データの形であってもよい。大域特徴ベクトルの構造化データおよび／または過去の継続時間の構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。
【００９９】
ステップ５５０で、処理エンジン１１２が、大域特徴ベクトルおよび過去の継続時間に基づき、推定到着時間（ＥＴＡ）サブモデルをトレーニングしてもよい。ＥＴＡサブモデルが、同じシナリオで意図するルートに関するＥＴＡを予測するためのモデルであってもよい。ＥＴＡサブモデルが、決定木、アソシエーションルール、人工ニューラルネットワーク、ディープラーニング、帰納的論理プログラミング、サポート・ベクター・マシン、クラスタ化、ベイジアンネットワーク、強化学習、表現学習、類似度および計量学習、スパース辞書学習、遺伝的アルゴリズム、ルールベース機械学習など、またはそれらの任意の組合せを含んでもよい。いくつかの実施形態では、ＥＴＡモデルを修正または更新することにより、ＥＴＡサブモデルを決定してもよい。いくつかの実施形態では、１つまたは複数のＥＴＡサブモデルを使用して、ＥＴＡモデル、または新しいＥＴＡサブモデルを合成してもよい。いくつかの実施形態では、少なくとも１つのＥＴＡサブモデルを使用して、意図するルートに関するＥＴＡを予測してもよい。たとえば、第１のＥＴＡサブモデルが、意図するルートに関する第１のＥＴＡを決定してもよく、および第２のＥＴＡサブモデルが、同じ意図するルートに関する第２のＥＴＡを決定してもよい。処理エンジン１１２が、第１のＥＴＡサブモデルと第２のＥＴＡサブモデルの数学平均を計算することにより、意図するルートに関する第３のＥＴＡを決定してもよい。たとえば、処理エンジン１１２が、第１のＥＴＡサブモデルおよび第２のＥＴＡサブモデルに基づき、合成されたＥＴＡサブモデルを決定してもよい。合成されたＥＴＡサブモデルを使用して、ＥＴＡを決定してもよい。
【０１００】
いくつかの実施形態では、ＥＴＡサブモデルが、構造化データの形であってもよい。ＥＴＡサブモデルの構造化データを、Ｂ木またはハッシュテーブルに基づき、処理エンジン１１２により構築または取り出してもよい。いくつかの実施形態では、構造化データを、データライブラリの形としてデータベース１６０に記憶または保存してもよい。
【０１０１】
ステップ５６０で、処理エンジン１１２が、少なくとも１つの道路区間を有する意図するルートに関連付けられる道路関係データを符号化する電気信号を得てもよい。意図するルートが、シナリオに対応しても、またはそれに属してもよい。たとえば、乗客が、自家用車に関するリクエストをオンライン・オン・デマンド・サービス・システム１００に送信してもよい。処理エンジン１１２が、自家用車に関するリクエストに基づき、意図するルートを決定してもよく、処理エンジン１１２が、ステップ５７０で、意図するルートのシナリオをさらに決定してもよい。
【０１０２】
いくつかの実施形態では、処理エンジン１１２が、同じまたは異なるシナリオを有する１つまたは複数の意図するルートを決定してもよい。いくつかの実施形態では、処理エンジン１１２が、１つの意図するルートに関して１つまたは複数のシナリオを決定してもよい。たとえば、意図するルートが、混雑時間（たとえば、午前７時〜午前９時）中にＣＢＤ領域を通過した場合、処理エンジン１１２が、意図するルートが属してもよい２つのシナリオを決定してもよい。
【０１０３】
ステップ５８０で、処理エンジン１１２が、意図するルートに基づき、意図する大域特徴ベクトルを決定してもよい。いくつかの実施形態では、意図する大域特徴ベクトルが、Ｎ次元を有してもよく、ベクトルにより表されてもよく、ここで、Ｎが、任意の整数であってもよい。疎行列が、Ｎ列またはＮ行を示してもよく、ここで、Ｎが、意図するルートから得たＮ個の項目または特徴に対応してもよい。たとえば、処理エンジン１１２が、意図するルートから５０個の項目を選択する場合、意図するルートに関する意図する大域特徴ベクトルとして、５０列または５０行を含むベクトルを決定してもよく、意図する大域特徴ベクトルが、５０次元のベクトルであってもよい。
【０１０４】
ステップ５９０で、処理エンジン１１２が、ＥＴＡサブモデル、意図する大域特徴ベクトル、および意図するルートのシナリオに基づき、意図するルートに関するＥＴＡを決定してもよい。いくつかの実施形態では、乗客が、混雑時間に、タクシーに関するリクエストを、オンライン・オン・デマンド・サービス・システム１００に伝送してもよい。処理エンジン１１２が、意図するルートおよび意図するルートに関連付けられるシナリオを決定してもよく、意図するルートに基づき、意図する大域特徴ベクトルを決定してもよく、処理エンジン１１２が、意図するルートに関連付けられるシナリオに基づき、シナリオに（たとえば、混雑時間に）関連付けられるトレーニング集合によりトレーニングしてもよいＥＴＡサブモデルを選択してもよく、処理エンジン１１２が、意図する大域特徴ベクトルをＥＴＡサブモデルに入力して、混雑時間の、意図するルートに関するＥＴＡを生成してもよい。
【０１０５】
いくつかの実施形態では、処理エンジン１１２が、運転者端末、乗客端末、および／またはオンライン・オン・デマンド・サービス・システム１００の任意の構成要素（たとえば、データベース１６０）にＥＴＡを送信してもよい。乗客がサービスリクエストを確認すべきかどうかを判断するのを容易にするために、乗客端末が、ユーザインタフェースに表示してもよい。いくつかの実施形態では、サービスリクエストに関する意図するルートを選択すべきかどうかを判断してもよい運転者に、ＥＴＡを送信してもよい（たとえば、運転者が、意図するルートと異なる別のルートに従ってタクシーを運転してもよい）。
【０１０６】
図６は、本開示のいくつかの実施形態による、大域特徴ベクトルに関連付けられるテーブルの、代表的な図を例示する。処理エンジン１１２が、運転者端末から道路関係データを得てもよい。いくつかの実施形態では、道路関係データを、電気信号として伝送してもよい。道路関係データが、テキストデータ、数値データ、画像データ、ビデオデータ、音声データ、および／またはカテゴリデータを含んでもよい。処理エンジン１１２が、テキストデータ、画像データ、ビデオデータ、音声データ、およびカテゴリデータを数値データに変換してもよい。処理エンジン１１２が、ルートに関連付けられる数値データに基づき、大域特徴ベクトルおよび過去の継続時間をさらに構築してもよい。いくつかの実施形態では、処理エンジン１１２が、大域特徴ベクトルおよび過去の継続時間を構築した後に、道路関係データを変換してもよい。
【０１０７】
たとえば、処理エンジン１１２が、３つのルートＩＤ、すなわち（６１０に示すように）それぞれ１、２、および３を指定される３つのルートに関連付けられる道路関係データを集めてもよい。ルートＩＤに関連付けられる道路関係データの各々が、運転距離６２０、交通信号の数６３０、道路幅６４０、車両のタイプ６５０、運転ランキング６６０、および過去の継続時間６７０を含んでもよい。処理エンジン１１２が、道路関係データの各々に基づき、大域特徴ベクトルを構築してもよい。大域特徴ベクトル内の項目または特徴が、それぞれ運転距離６２０、交通信号の数６３０、道路幅６４０、車両のタイプ６５０、および運転ランキング６６０を含んでもよい。処理エンジン１１２が、大域特徴ベクトル内のテキストデータおよび／またはカテゴリデータ（たとえば、タクシー、もしくは自家用車など）を数値データにさらに変換してもよい。たとえば、タクシーおよび自家用車を、それぞれ１および２に変換してもよい。いくつかの実施形態では、ＥＴＡモデルをトレーニングする前に、処理エンジン１１２が、大域特徴ベクトル内の数値データを２進データに変換してもよい。大域特徴ベクトルが、過去の継続時間６７０に対応してもよい。たとえば、過去の継続時間をラベルとして使用して、モデルをトレーニングしてもよい。大域特徴ベクトルおよび対応する過去の継続時間が、トレーニング集合を形成してもよい。処理エンジン１１２が、入力を大域特徴ベクトルとして決定し、かつ対応する過去の継続時間として出力を決定することにより、ＥＴＡモデルをトレーニングしてもよい。
【０１０８】
図７は、本開示のいくつかの実施形態によるＥＴＡモデルとして、決定木の代表的な図を例示する。決定木が、分類木、回帰木、または分類木・回帰木を含んでもよい。決定木を構築する際に使用するアルゴリズムが、ＩＤ３アルゴリズム、分類木・回帰木アルゴリズム、ＩＤ３の後継アルゴリズム、ＣＨＡＩＤアルゴリズム、または条件付き推論木アルゴリズムを含んでもよい。決定木７００の構築中、処理エンジン１１２が、情報利得を使用して、決定木７００でどの変数または項目を最初に決定してもよいかを判断してもよい。情報利得を、式（２）として表現してもよい。
【数２】
2019507316.tif 000004
式中、Ｇａｉｎが、利得情報を表し、ｉｎｆｏｂｅｆｏｒｅｓｐｌｉｔが、分割前のエントロピーを表し、ｉｎｆｏａｆｔｅｒｓｐｌｉｔが、分割後のエントロピーを表す。
【０１０９】
エントロピーを、式（３）として表現してもよい。
【０１１０】
【数３】
2019507316.tif 000005
【０１１１】
式中、Ｈ（Ｔ）が、ｎ個の値を有する変数Ｔに関するエントロピーを表し、Ｐｉが、Ｔがｉであるときの確率を表す。
【０１１２】
たとえば、処理エンジン１１２が、変数（たとえば、運転距離、交通信号の数、道路幅、および乗客を乗せたかどうか）の各々に関する情報利得を決定してもよく、最大情報利得を有する変数（たとえば、運転距離）を選択してもよく、決定木７００を対照させる第１の分割として運転距離を決定してもよい。交通信号の数、道路幅、および乗客を乗せたかどうかなどの他の変数を、それぞれ対応する情報利得に基づき分割してもよい。図７に示すように、決定木７００を、最初に運転距離を使用して分割してもよい。運転距離が、１０以上である場合、交通信号の数により、決定木７００をさらに分割してもよく、交通信号の数が、１以上である場合、乗客を乗せたかどうかにより、決定木７００をさらに分割してもよく、客を乗せた場合、式（４）によりＥＴＡを計算してもよい。
【数４】
2019507316.tif 000006
式中、ｆ１が、運転距離の関数を表し、ｆ２が、交通信号の数の関数を表す。乗客を乗せなかった場合、式（５）によりＥＴＡを計算してもよい。
【数５】
2019507316.tif 000007
式中、ｆ１が、運転距離の関数を表し、ｆ２が、交通信号の数の関数を表す。
【０１１３】
運転距離が、０．５以上、かつ１０以下である場合、道路幅により、決定木７００をさらに分割してもよく、たとえば、道路幅が、１２に等しい場合、式（６）によりＥＴＡを計算してもよい。
【数６】
2019507316.tif 000008
式中、ｆ１が、運転距離の関数を表す。道路幅が、１２に等しい場合、式（７）によりＥＴＡを計算してもよい。
【数７】
2019507316.tif 000009
式中、ｆ１が、運転距離の関数を表す。
【０１１４】
運転距離が、０．５未満である場合、ＥＴＡが、３分であってもよい。いくつかの実施形態では、決定木７００が、式記述の１つに基づき、数値を出力してもよい。たとえば、決定木７００が、式（７）に基づき、ＥＴＡを３２分として出力してもよい。
【０１１５】
図８は、本開示のいくつかの実施形態によるＥＴＡモデルとして、人工ニューラルネットワーク（ＡＮＮ）の代表的な図を例示する。ＡＮＮ８００が、入力層８１０、隠れ層８２０、および出力層８３０を含んでもよい。入力層８１０が、ネット構造を形成するために互いに接続してもよい１つまたは複数の人工ニューロンからなってもよい。図８に示すように、入力層８１０が、人工ニューロンＸ１、人工ニューロンＸ２、人工ニューロンＸ３、…、人工ニューロンＸｎを含んでもよい。いくつかの実施形態では、入力層８１０内の人工ニューロンの数が、大域特徴ベクトルを表す行列の列の数に対応してもよい。たとえば、Ｎ個の項目または特徴に対応する大域特徴ベクトルが、Ｎ列またはＮ行のベクトルとして表現される場合、入力層８１０内の人工ニューロンの数が、Ｎ（たとえば、２０００）に等しくてもよい。隠れ層８２０が、３つの人工ニューロンを、すなわち、人工ニューロンＺ１、人工ニューロンＺ２、および人工ニューロンＺ３を含んでもよい。隠れ層８２０内の人工ニューロンの各々を、入力層８１０内の人工ニューロンの各々と接続してもよく、隠れ層８２０内の人工ニューロンの各々を、出力層８３０内の人工ニューロンと接続してもよい。たとえば、人工ニューロンが、それぞれ人工ニューロンＸ１、人工ニューロンＸ２、人工ニューロンＸ３、…、人工ニューロンＸｎと接続してもよい。隠れ層８２０内の人工ニューロンの各々が、総和関数を含んでもよい。総和関数が、しきい値関数、または制限関数であってもよい。たとえば、隠れ層内の総和関数を、式（８）として表現してもよい。
【０１１６】
【数８】
2019507316.tif 000010
【０１１７】
式中、Ｏが、出力層８３０内の人工ニューロンへの、人工ニューロンの出力を表し、ｆが、活性化関数を表し、ｗｊが、隠れ層８２０内の人工ニューロン間の重みを表し、ｘｊが、入力層内の人工ニューロンＸｊから隠れ層８２０内の人工ニューロンへの入力を表し、θが、しきい値を表す。出力層８３０が、少なくとも１つの人工ニューロンを含んでもよい。出力層８３０内の少なくとも１つの人工ニューロンの各々が、隠れ層８２０内の人工ニューロンの各々と接続してもよい。たとえば、出力層８３０内の１つの人工ニューロンを、人工ニューロンＺ１、人工ニューロンＺ２、および人工ニューロンＺ３のそれぞれと接続してもよい。出力層８３０内の人工ニューロンの各々が、同じく式（８）などの総和関数を含んでもよい。たとえば、出力層８３０内の人工ニューロン内の活性化関数が、式（９）で表現する階段関数であってもよい。
【０１１８】
【数９】
2019507316.tif 000011
【０１１９】
一実施例として、活性化関数を、連続関数値を有する関数（たとえば、式（４））として表現してもよい。出力層８３０内の、活性化関数を有する人工ニューロンが、ルートまたは意図するルートに関するＥＴＡを出力してもよい。
【０１２０】
図８で説明するＡＮＮ８００は、例示のためだけに提供され、かつ本開示の範囲を限定することを意図するものではないことに留意されたい。当業者については、上記の方法およびシステムの適用例の形態および詳細にさまざまな修正および変更を、本開示の原理を逸脱することなく行ってもよい。たとえば、隠れ層８２０の数が、２つ以上であってもよい。別の実施例として、ＡＮＮ８００が、畳み込み層および／またはプーリング層をさらに含んでもよい。畳み込み層およびプーリング層を、隠れ層８２０内に交互に配置してもよい。さらに別の実施例として、ＡＮＮ８００を、ディープラーニング法により修正またはトレーニングしてもよい。
【０１２１】
図９は、本開示のいくつかの実施形態による、ＥＴＡを予測するための物理モデルの代表的な図を例示する。処理エンジン１１２が、道路に基づく地図に記述された（図９に実線で示すような）ルート９００を得てもよい。ルート９００が、１０個の道路区間（たとえば、第１の道路区間、第２の道路区間、…、第１０の道路区間）および９個の交通信号（たとえば、第１の交通信号、第２の交通信号、…、第９の交通信号）を含む。２つの隣接する道路区間が、１つまたは複数の交通信号で連結されている。道路区間での速度の各々に基づき、道路区間の各々を通過する時間を決定してもよい。たとえば、第１の道路区間を通過する時間をＴ１として決定してもよく、第２の道路区間を通過する時間をＴ２として決定してもよく、…、および第１０の道路区間を通過する時間をＴ１０として決定してもよい。交通信号の各々を通過する時間を、Ｌ１、Ｌ２、…、およびＬ９として決定してもよい。
【０１２２】
処理エンジン１１２が、道路区間の各々を通過する時間と、交通信号の各々を通過する時間を加算することにより、ルート９００に関するＥＴＡを決定してもよい。いくつかの実施形態では、処理エンジン１１２が、ルート９００内の道路区間、および道路に基づく地図内の他の道路区間に基づき、ルート９００に関するＥＴＡを決定してもよい。ルート９００内の道路区間を、道路に基づく地図内の他の道路区間に直接または間接的に関連づけてもよい。たとえば、Ｔ２２に対応する道路区間（図９のように点線で示す）が、ルート９００内の道路区間（たとえば、第１の道路区間）と関係があってもよく、およびＴ２２に対応する道路区間での速度が、第１の道路区間、およびルート９００内の任意の他の道路区間での速度に影響を及ぼす場合がある。いくつかの実施形態では、処理エンジン１１２が、ルート内の道路区間、および道路に基づく地図内の他の道路区間に基づき、大域特徴ベクトルを決定してもよい。大域特徴ベクトルによりトレーニングしたＥＴＡモデルを使用して、図９のように示す道路に基づく地図内の任意のルートに関するＥＴＡを予測してもよい。
【０１２３】
図１０は、本開示のいくつかの実施形態による、サーバ１１０、要求者端末１３０、および／または提供者端末１４０を実装してもよいコンピューティング機器１０００の、代表的なハードウェアおよび／またはソフトウェアの構成要素を例示する概略図である。たとえば、処理エンジン１１２が、コンピューティング機器１０００上に実装され、本開示で明らかにする処理エンジン１１２の機能を遂行するように構成されてもよい。
【０１２４】
コンピューティング機器１０００が、汎用コンピュータであっても、または専用コンピュータであってもよく、両方とも、本開示のためのオン・デマンド・システムを実装するために使用されてもよい。コンピューティング機器１０００を、本明細書で説明するように、オン・デマンド・サービスの任意の構成要素を実装するために使用してもよい。たとえば、処理エンジン１１２を、コンピューティング機器１０００のハードウェア、ソフトウェアプログラム、ファームウェア、またはそれらの任意の組合せによって、コンピューティング機器１０００上に実装してもよい。便宜上、そのようなコンピュータを１つだけ示すが、本明細書で説明するように、オン・デマンド・サービスに関係があるコンピュータ機能を、処理負荷を分配するために、いくつかの類似のプラットフォーム上に分散方式で実装してもよい。
【０１２５】
コンピューティング機器１０００が、たとえば、データ通信を容易にするために、コンピューティング機器１０００に接続されたネットワークに双方向接続されたＣＯＭポート１０５０を含んでもよい。コンピューティング機器１０００はまた、プログラム命令を実行するための中央処理装置（ＣＰＵ）１０２０を、１つまたは複数のプロセッサの形で含んでもよい。代表的コンピュータプラットフォームが、内部通信バス１０１０、異なる形態のプログラム記憶領域およびデータ記憶領域、たとえば、ディスク１０７０、および読出し専用メモリ（ＲＯＭ）１０３０、またはコンピュータにより処理および／もしくは伝送すべき、さまざまなデータファイルのためのランダム・アクセス・メモリ（ＲＡＭ）１０４０を含んでもよい。代表的コンピュータプラットフォームはまた、ＲＯＭ１０３０、ＲＡＭ１０４０、および／また他のタイプの非一時的記憶媒体に記憶された、ＣＰＵ１０２０により実行すべきプログラム命令を含んでもよい。本開示の方法および／または処理を、プログラム命令として実装してもよい。コンピューティング機器１０００はまた、ユーザインタフェース要素１０８０などの、コンピュータとコンピュータ内の他の構成要素との間の入出力を支援するＩ／Ｏ（入出力）構成要素１０６０を含む。コンピューティング機器１０００はまた、ネットワーク通信を介して、プログラミングおよびデータを受信してもよい。
【０１２６】
単に例示のために、コンピューティング機器１０００内に、１つのＣＰＵおよび／またはプロセッサだけが記述されている。しかしながら、本開示では、コンピューティング機器１０００はまた、複数のＣＰＵおよび／またはプロセッサを含んでもよく、その結果、本開示で説明するような、１つのＣＰＵおよび／またはプロセッサにより遂行される動作および／または方法ステップはまた、複数のＣＰＵおよび／またはプロセッサにより、共同でまたは別々に遂行されてもよいことに留意されたい。たとえば、本開示で、コンピューティング機器１０００のＣＰＵおよび／またはプロセッサが、ステップＡとステップＢの両方を実行する場合、ステップＡおよびステップＢはまた、コンピューティング機器１０００で２つの異なるＣＰＵおよび／またはプロセッサにより、共同でまたは別々に遂行されてもよい（たとえば、第１のプロセッサがステップＡを実行し、第２のプロセッサがステップＢを実行する、または第１および第２のプロセッサが、ステップＡおよびＢを共同で実行する）ことを理解されたい。
【０１２７】
図１１は、本開示のいくつかの実施形態による、ユーザ端末が実装されてもよい代表的な移動体機器１１００の、代表的なハードウェアおよび／またはソフトウェアの構成要素を例示する概略図である。図１１に例示するように、移動体機器１１００が、通信プラットフォーム１１１０、表示装置１１２０、グラフィック・プロセッシング・ユニット（ｇｒａｐｈｉｃ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ、ＧＰＵ）１１３０、中央処理装置（ＣＰＵ）１１４０、Ｉ／Ｏ１１５０、メモリ１１６０、記憶領域１１９０を含んでもよい。いくつかの実施形態では、システムバスまたはコントローラ（図示せず）を含むが、それらに限定されない任意の他の適切な構成要素もまた、移動体機器１１００に含まれてもよい。いくつかの実施形態では、ＣＰＵ１１４０により実行するために、記憶領域１１９０からメモリ１１６０の中に、移動体オペレーティングシステム１１７０（たとえば、ｉＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｗｉｎｄｏｗｓ  Ｐｈｏｎｅ（登録商標）など）および１つまたは複数のアプリケーション１１８０をロードしてもよい。アプリケーション１１８０が、ブラウザ、または画像処理に関係がある情報もしくは他の情報を処理エンジン１１２から受信し描画するための任意の他の適切な移動体アプリケーションを含んでもよい。情報ストリームとのユーザ対話を、Ｉ／Ｏ１１５０を介して達成し、ネットワーク１２０を介して、処理エンジン１１２および／またはオンライン・オン・デマンド・サービス・システム１００の他の構成要素に提供してもよい。
【０１２８】
本開示で説明するさまざまなモジュール、ユニット、およびそれらの機能を実装するために、本明細書で説明する要素の１つまたは複数のための１つまたは複数のハードウェアプラットフォームとして、コンピュータ・ハードウェア・プラットフォームを使用してもよい。ユーザインタフェース要素を有するコンピュータを使用して、パーソナルコンピュータ（ｐｅｒｓｏｎａｌ  ｃｏｍｐｕｔｅｒ、ＰＣ）または任意の他のタイプのワークステーションもしくは端末機器を実装してもよい。コンピュータはまた、適切にプログラムされた場合、サーバの役割を果たしてもよい。
【０１２９】
このように基本的な考え方について説明してきたが、この詳細な開示を読んだ後では、前述の詳細な開示が、実施例として提示されることだけが意図され、制限するものではないことが、当業者にはかなりの程度、明らかであろう。本明細書で明示的にはっきりと述べていないが、さまざまな変形、改善、および修正が行われてもよく、また当業者に意図される。これらの変形、改善、および修正が、本開示により示唆されることが意図され、本開示の代表的実施形態の精神および範囲に入る。
【０１３０】
さらに、本開示の実施形態を説明するために、ある種の専門用語を使用してきた。たとえば、用語「一実施形態」、「ある実施形態」、および／または「いくつかの実施形態」は、その実施形態に関連して説明する特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書のさまざまな部分における「ある実施形態」または「一実施形態」または「代替実施形態」への２つ以上の参照が、必ずしもすべて同じ実施形態を参照しているわけではないことが、強調されており、またそのことを認識されたい。さらに、特定の特徴、構造、または特性を、本開示の１つまたは複数の実施形態で、適切に組み合わせてもよい。
【０１３１】
さらに、本開示の様態について、任意の新しく有用な処理、機械、製品、もしくは組成物、またはそれらの任意の新しく有用な改善を含む、いくつかの特許性のあるクラスまたは関係のいずれかで、本明細書で例示し、説明している場合があることが当業者には理解されるであろう。それに応じて、本開示の様態を、完全にハードウェアで、完全にソフトウェアで（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書で一般にすべて「ユニット」、「モジュール」、もしくは「システム」と呼ぶ場合がある、ソフトウェアとハードウェアを組み合わせる実装で、実装してもよい。さらに、本開示の様態が、具体化されたコンピュータ可読プログラムコードを有する１つまたは複数のコンピュータ可読媒体の形で具体化されたコンピュータプログラム製品の形をとってもよい。
【０１３２】
コンピュータ可読信号媒体が、その中に具体化された、たとえばベースバンドの中に、または搬送波の一部として具体化された、コンピュータ可読プログラムコードを有する、伝播データ信号を含んでもよい。そのような伝播信号が、電磁的、光学的など、またはそれらの任意の適切な組合せを含むさまざまな形のいずれをとってもよい。コンピュータ可読信号媒体が、コンピュータ可読記憶媒体ではなく、かつ命令実行システム、装置、もしくは機器により、またはそれらと接続して使用するために、プログラムを伝達し、伝搬し、または転送してもよい、任意のコンピュータ可読媒体であってもよい。コンピュータ可読信号媒体上に具体化されたプログラムコードを、無線、有線、光ファイバケーブル、ＲＦなど、または前述の任意の適切な組合せを含む、任意の適切な媒体を使用して伝送してもよい。
【０１３３】
本開示の様態に関する動作を行うためのコンピュータ・プログラム・コードを、Ｊａｖａ、Ｓｃａｌａ、Ｓｍａｌｌｔａｌｋ、Ｅｉｆｆｅｌ、ＪＡＤＥ、Ｅｍｅｒａｌｄ、Ｃ＋＋、Ｃ＃、ＶＢ．ＮＥＴ、Ｐｙｔｈｏｎなどのようなオブジェクト指向プログラミング言語、「Ｃ」プログラミング言語、Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｆｏｒｔｒａｎ  ２００３、Ｐｅｒｌ、ＣＯＢＯＬ  ２００２、ＰＨＰ、ＡＢＡＰなどの従来の手続き型プログラミング言語、Ｐｙｔｈｏｎ、Ｒｕｂｙ、およびＧｒｏｏｖｙなどの動的プログラミング言語、または他のプログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組合せで書いてもよい。プログラムコードは、全部をユーザのコンピュータ上で、スタンド・アロン・ソフトウェア・パッケージとして部分的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上でかつ部分的に遠隔コンピュータ上で、または全部を遠隔コンピュータもしくはサーバ上で実行されてもよい。後者のシナリオでは、遠隔コンピュータが、ローカル・エリア・ネットワーク（ＬＡＮ）もしくは広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通して、ユーザのコンピュータに接続されてもよく、または接続が（たとえば、インターネットサービスプロバイダを使用しインターネットを通して）外部コンピュータに行われても、もしくはクラウドコンピューティング環境で行われてもよく、またはＳａａＳ（ｓｏｆｔｗａｒｅ  ａｓ  ａ  ｓｅｒｖｉｃｅ）などのサービスとして提供されてもよい。
【０１３４】
さらに、要素の処理もしくはシーケンスについて説明された順序、または数値、文字、もしくは他の指定の使用はすなわち、特許請求の範囲で指定する場合があるときを除いて、特許請求される処理および方法をいかなる順序にも限定することを意図するものではない。上記の開示は、開示のさまざまな有用な実施形態であると現在考えられることを、さまざまな実施例を通して説明しているが、そのような詳細が、単にその目的のためだけのものであること、および添付の特許請求の範囲が、開示する実施形態に限定されるのではなく、それどころか、開示する実施形態の精神および範囲に入る修正形態および均等の構成を包含することが意図されることを理解されたい。たとえば、上述のさまざまな構成要素の実装が、ハードウェア機器の形で具体化されてもよいが、同じく、ソフトウェアだけの解決策として、たとえば、既存のサーバまたは移動体機器上へのインストールとして実装されてもよい。
【０１３５】
同様に、本開示の実施形態についての前述の説明では、さまざまな特徴が、本開示を合理化し、さまざまな実施形態の１つまたは複数について理解する手助けとする目的で、単一の実施形態、図、またはそれらの説明の形で一緒にグループ化されることがあることを認識されたい。しかしながら、この開示方法は、特許請求される主題が、各請求項で明示的に説明されているよりも多くの特徴を必要とするという意図を反映していると解釈されるべきではない。むしろ、特許請求される主題が、単一の前述の開示された実施形態の特徴すべてよりも少ない特徴に見いだされる場合がある。
【図１】
2019507316.tif 000012
【図２】
2019507316.tif 000013
【図３】
2019507316.tif 000014
【図４】
2019507316.tif 000015
【図５】
2019507316.tif 000016
【図６】
2019507316.tif 000017
【図７】
2019507316.tif 000018
【図８】
2019507316.tif 000019
【図９】
2019507316.tif 000020
【図１０】
2019507316.tif 000021
【図１１】
2019507316.tif 000022
【手続補正書】
【提出日】平成30年7月27日(2018.7.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
オンライン・オン・デマンド輸送サービスを動作するように構成されるシステムであって、
命令のセットを含む少なくとも１つの記憶媒体と、
前記少なくとも１つの記憶媒体と通信する少なくとも１つのプロセッサと、
を備え、前記命令を実行するとき、前記少なくとも１つのプロセッサは、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得て、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存し、
推定到着時間（ｅｓｔｉｍａｔｅｄ  ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ、ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成し、
前記ＥＴＡモデルの前記第２の構造化データを前記少なくとも１つの記憶媒体に保存する
ように指示されるシステム。
【請求項２】
前記少なくとも１つの大域特徴ベクトルのうち少なくとも２つは、行列式に統合される、請求項１に記載のシステム。
【請求項３】
前記少なくとも１つの大域特徴ベクトルは、前記少なくとも１つの道路区間のうち少なくとも２つの間の関係を示す特徴を含む総合特徴ベクトルを含む、請求項２に記載のシステム。
【請求項４】
前記少なくとも１つの道路区間のうち前記少なくとも２つは、互いに離れている、請求項３に記載のシステム。
【請求項５】
前記総合特徴ベクトルは、リアルタイムの道路速度または推定道路速度を含む交通状態のうち少なくとも１つを含む、請求項３に記載のシステム。
【請求項６】
前記ＥＴＡモデルは、回帰モデル、決定木モデル、人工ニューラル・ネットワーク・モデル、サポートベクター回帰モデル、制限付きボルツマン・マシン・モデル、または遺伝的アルゴリズムのうち少なくとも１つを含む、請求項１に記載のシステム。
【請求項７】
前記ＥＴＡモデルは、時間間隔または地図内の領域のうち少なくとも１つに対応する複数のＥＴＡサブモデルを含む、請求項１に記載のシステム。
【請求項８】
前記少なくとも１つのプロセッサは、
少なくとも１つの道路区間を有する意図するルートに関連付けられる第２の電気信号を受信し、
前記第２の電気信号に基づき、前記意図するルートに関連付けられる少なくとも１つの意図する大域特徴ベクトルの第３の構造化データを生成および保存し、
前記ＥＴＡモデルの前記第２の構造化データを実行して、前記意図する特徴ベクトルおよび前記ＥＴＡモデルに基づき、前記意図するルートに対応するＥＴＡを決定する
ようにさらに指示される、請求項１に記載のシステム。
【請求項９】
前記意図するルートに対応する前記ＥＴＡを決定するために、前記少なくとも１つのプロセッサは、
前記意図するルートの開始時間の時間間隔を決定し、
前記開始時間に基づき、前記時間間隔に対応する前記ＥＴＡサブモデルを選択する
ようにさらに指示される、請求項８に記載のシステム。
【請求項１０】
前記意図するルートに対応する前記ＥＴＡを決定するために、前記少なくとも１つのプロセッサは、
前記意図するルートの、開始位置の領域、または終了位置を決定し、
前記開始位置および前記終了位置に基づき、地図内の前記領域に対応する前記ＥＴＡサブモデルを選択する
ようにさらに指示される、請求項８に記載のシステム。
【請求項１１】
少なくとも１つのプロセッサ、少なくとも１つの記憶媒体、およびネットワークに接続された通信プラットフォームを有するコンピューティング機器上に実装される方法であって、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得るステップと、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存するステップと、
推定到着時間（ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成するステップと、
前記ＥＴＡモデルの前記第２の構造化データを前記少なくとも１つの記憶媒体に保存するステップと
を備える方法。
【請求項１２】
前記少なくとも１つの大域特徴ベクトルのうち少なくとも２つは、行列式に統合される、請求項１１に記載の方法。
【請求項１３】
前記少なくとも１つの大域特徴ベクトルは、前記少なくとも１つの道路区間のうち少なくとも２つの間の関係を示す特徴を含む総合特徴ベクトルを含む、請求項１２に記載の方法。
【請求項１４】
前記少なくとも１つの道路区間のうち前記少なくとも２つは、互いに離れている、請求項１３に記載の方法。
【請求項１５】
前記総合特徴ベクトルは、リアルタイムの道路速度または推定道路速度を含む交通状態のうち少なくとも１つを含む、請求項１３に記載の方法。
【請求項１６】
前記ＥＴＡモデルは、回帰モデル、決定木モデル、人工ニューラル・ネットワーク・モデル、サポートベクター回帰モデル、制限付きボルツマン・マシン・モデル、または遺伝的アルゴリズムのうち少なくとも１つを含む、請求項１１に記載の方法。
【請求項１７】
前記ＥＴＡモデルは、時間間隔、または地図内の領域のうち少なくとも１つに対応する複数のＥＴＡサブモデルを含む、請求項１１に記載の方法。
【請求項１８】
少なくとも１つの道路区間を有する意図するルートに関連付けられる第２の電気信号を受信するステップと、
前記第２の電気信号に基づき、前記意図するルートに関連付けられる少なくとも１つの意図する大域特徴ベクトルの第３の構造化データを生成および保存するステップと、
前記ＥＴＡモデルの前記第２の構造化データを実行して、前記意図する特徴ベクトルおよび前記ＥＴＡモデルに基づき、前記意図するルートに対応するＥＴＡを決定するステップと
をさらに備える、請求項１１に記載の方法。
【請求項１９】
前記意図するルートに対応する前記ＥＴＡを決定する前記ステップは、
前記意図するルートの開始時間の時間間隔を決定するステップと、
前記開始時間に基づき、前記時間間隔に対応する前記ＥＴＡサブモデルを選択するステップと
をさらに備える、請求項１８に記載の方法。
【請求項２０】
命令を含む非一時的コンピュータ可読記憶媒体であって、要求者端末からのオンライン・オン・デマンド・サービス・プラットフォームの少なくとも１つのプロセッサによりアクセスされたとき、前記命令が、前記少なくとも１つのプロセッサに、
少なくとも１つの道路区間を有する少なくとも１つのルートに関連付けられる第１の電気信号を得させ、
前記第１の電気信号に基づき、前記少なくとも１つのルートに関連付けられる、少なくとも１つの大域特徴ベクトルおよび少なくとも１つの過去の継続時間の第１の構造化データを生成および保存させ、
推定到着時間（ＥＴＡ）モデルの第２の構造化データを、前記少なくとも１つの大域特徴ベクトルおよび前記少なくとも１つの過去の継続時間に基づき前記ＥＴＡモデルをトレーニングすることにより生成させ、
前記ＥＴＡモデルの前記第２の構造化データを前記非一時的コンピュータ可読記憶媒体に保存させる
非一時的コンピュータ可読記憶媒体。
【国際調査報告】
2019507316.tif 000023
2019507316.tif 000024