特許 7598866 輸送方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-04

(45)【発行日】2024-12-12

(54)【発明の名称】輸送方法および装置

(51)【国際特許分類】

   G06Q 10/02 20120101AFI20241205BHJP

   G06Q 50/40 20240101ALI20241205BHJP

   G16Y 10/40 20200101ALI20241205BHJP

   G16Y 20/20 20200101ALI20241205BHJP

   G16Y 40/20 20200101ALI20241205BHJP

【ＦＩ】

G06Q10/02

G06Q50/40

G16Y10/40

G16Y20/20

G16Y40/20

【請求項の数】 11

(21)【出願番号】P 2021544175

(86)(22)【出願日】2019-01-28

(65)【公表番号】

(43)【公表日】2022-04-12

(86)【国際出願番号】 SG2019050042

(87)【国際公開番号】W WO2020159431

(87)【国際公開日】2020-08-06

【審査請求日】2021-07-28

【審判番号】

【審判請求日】2023-05-15

(73)【特許権者】

【識別番号】518236797

【氏名又は名称】グラブタクシー ホールディングス プライベート リミテッド

【氏名又は名称原語表記】ＧＲＡＢＴＡＸＩ ＨＯＬＤＩＮＧＳ ＰＴＥ． ＬＴＤ．

【住所又は居所原語表記】３ Ｍｅｄｉａ Ｃｌｏｓｅ， ＃０１－０３／０６， Ｓｉｎｇａｐｏｒｅ １３８４９８， Ｓｉｎｇａｐｏｒｅ

(74)【代理人】

【識別番号】100137095

【弁理士】

【氏名又は名称】江部 武史

(72)【発明者】

【氏名】ガルグ， アユシュ

(72)【発明者】

【氏名】ファン， チュン カイ

(72)【発明者】

【氏名】アグワル， チャンダン クマール

【合議体】

【審判長】伏本 正典

【審判官】月野 洋一郎

【審判官】古川 哲也

(56)【参考文献】

【文献】中国特許出願公開第１０３６３２５３２（ＣＮ，Ａ）

【文献】ＬＡＩ， Ｙｏｎｇｘｕａｎ， ｅｔ ａｌ．，Ｕｒｂａｎ ｔｒａｆｆｉｃ Ｃｏｕｌｏｍｂ’ｓ ｌａｗ： Ａ ｎｅｗ ａｐｐｒｏａｃｈ ｆｏｒ ｔａｘｉ ｒｏｕｔｅ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ，ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔａｔｉｏｎ Ｓｙｓｔｅｍｓ，２０１８年１０月１８日，２０（８），ｐｐ． ３０２４－３０３７

(58)【調査した分野】(Int.Cl.，ＤＢ名)

G06Q 10/00-99/00

G16Y 10/40

G16Y 20/20

G16Y 40/20

(57)【特許請求の範囲】

【請求項1】

複数の隣接する地理的セルによって構成された輸送システムを動作させる方法であって、
複数の適格サービスプロバイダのそれぞれに対して、前記複数の隣接する地理的セルのうちの１つにおける複数のユーザのそれぞれのための個別の有効供給値を計算する工程と、
前記複数のユーザのそれぞれにおいて、前記個別の有効供給値の合計からトータル有効供給スコアを計算する工程と、を含み、
前記個別の有効供給値は、前記複数の適格サービスプロバイダのうちの１つと前記複数のユーザのうちの１人との間の距離と、前記複数の適格サービスプロバイダのうちの前記１つと前記複数のユーザの前記１人以外の他のユーザとの間の距離との比率に基づいて算出されることを特徴とする輸送システムを動作させる方法。

【請求項2】

前記個別の有効供給値を計算する工程は、
前記複数の適格サービスプロバイダのうちの前記１つのために、前記複数の適格サービスプロバイダのうちの前記１つと、前記複数のユーザのうちの前記１人とのペアである需要－供給ペアを指定する工程と、
前記需要－供給ペアに対し、前記複数の適格サービスプロバイダのうちの前記１つと、前記複数のユーザのうちの前記１人との間の距離値を決定する工程と、
前記決定された距離値を使用して、前記需要－供給ペアのための距離比の値を決定する工程と、
前記需要－供給ペアの前記距離比の値をすべての前記距離比の値の合計で割って計算することにより、前記需要－供給ペアの比例重み付け値を決定する工程と、
前記比例重み付け値を逆数にして、反比例重み付け値を得る工程と、
前記反比例重み付け値を合計して、前記反比例重み付け値の合計を得る工程と、
前記需要－供給ペアの前記反比例重み付け値と、前反比例重み付け値の前記合計との比を計算する工程と、を含む請求項１に記載の方法。

【請求項3】

前記複数の隣接する地理的セルについて需要パラメータを決定するために、前記トータル有効供給スコアを使用する工程をさらに含み、
前記需要パラメータは、供給需用比および供給需要差の一方である請求項１に記載の方法。

【請求項4】

複数の隣接する地理的セルで構成される輸送システムを動作させるためのサーバ装置であって、
前記サーバ装置は、プロセッサと、メモリとを含み、
前記サーバ装置は、前記プロセッサの制御下で、複数の適格サービスプロバイダのそれぞれに対して、前記複数の隣接する地理的セルのうちの１つにおける複数のユーザのそれぞれのための個別の有効供給値を計算し、
前記複数のユーザのそれぞれにおいて、前記個別の有効供給値の合計からトータル有効供給スコアを計算するために、前記メモリに記憶された命令を実行するように構成され、
前記個別の有効供給値は、前記複数の適格サービスプロバイダのうちの１つと前記複数のユーザのうちの１人との間の距離と、前記複数の適格サービスプロバイダのうちの前記１つと前記複数のユーザの前記１人以外の他のユーザとの間の距離との比率に基づいて算出されることを特徴とするサーバ装置。

【請求項5】

前記サーバ装置は、
前記複数の適格サービスプロバイダのうちの前記１つのために、前記複数の適格サービスプロバイダのうちの前記１つと、前記複数のユーザのうちの前記１人とのペアである需要－供給ペアを指定し、
前記需要－供給ペアに対し、前記複数の適格サービスプロバイダのうちの前記１つと、前記複数のユーザのうちの前記１人との間の距離値を決定し、
前記決定された距離値を使用して、前記需要－供給ペアのための距離比の値を決定し、
前記需要－供給ペアの前記距離比の値をすべての前記距離比の値の合計で割って計算することにより、前記需要－供給ペアの比例重み付け値を決定し、
前記比例重み付け値を逆数にして、反比例重み付け値を求め、
前記反比例重み付け値を合計して、前記反比例重み付け値の合計を求め、
前記需要－供給ペアの前記反比例重み付け値と、前記反比例重み付け値の前記合計との比を計算することによって、前記個別の有効供給値を計算するように構成されている請求項４に記載のサーバ装置。

【請求項6】

需要のユニットを形成する複数のユーザが有するユーザ通信デバイスと、供給のユニットを形成する複数のサービスプロバイダが有するサービスプロバイダ通信デバイスとを有する輸送システムオペレーティングシステムであって、
前記輸送システムオペレーティングシステムは、動作領域を共に画定する複数の地理的セルと、プロセッサおよびメモリを有するサーバ装置とを含み、
前記サーバ装置は、前記プロセッサの制御下で、
タイムスロットについて各セルに配置された需要のユニットを決定する工程と、
前記タイムスロットについて各セルに配置された供給のユニットを決定する工程と、
少なくとも１つのパラメータに基づいて適格な供給ユニットを決定する工程と、
前記適格な供給ユニットの位置周辺の需要ユニットを識別する工程と、
前記適格な供給ユニット－前記需要ユニットのペアの間の直線距離を計算する工程と、
以下のａ－ｄによって有効供給を得る工程と、
ａ．前記適格な供給ユニット－前記需要ユニットの前記ペアの前記直線距離の比率を算出する工程
ｂ．前記ペアの重み付けを計算する工程
ｃ．前記ペアごとに前記計算された重み付けを逆数にする工程
ｄ．逆数にされた重み付けの比率を前記有効供給として計算する工程
によって、前記ユーザごとの前記有効供給を決定するために、前記メモリに保存された命令を実行するように構成されていることを特徴とする輸送システムオペレーティングシステム。

【請求項7】

プッシュ技術を使用して、サービスプロバイダデバイスから前記複数の適格サービスプロバイダの位置を示すデータを受信するように構成される請求項４に記載のサーバ装置。

【請求項8】

非同期的に受信されたサービスプロバイダの位置を示すデータが、同期処理のためにプロバイダメッセージキューに流されるように構成された請求項４に記載のサーバ装置。

【請求項9】

同期処理のためにユーザメッセージキューにユーザ位置のデータを流すために、前記ユーザ位置を示すデータを非同期的に受信するように構成された請求項４記載のサーバ装置。

【請求項10】

非同期的に受信されたサービスプロバイダの位置を示すデータが、同期処理のためにプロバイダメッセージキューに流されるように構成され、
同期処理のためにユーザメッセージキューにユーザ位置のデータを流すために、前記ユーザ位置を示すデータを非同期的に受信するように構成され、
前記プロバイダメッセージキューからの同期プロバイダデータと、前記ユーザメッセージキューからの同期ユーザデータとを受信し、前記同期プロバイダデータを集合プロバイダデータとして流し、前記同期ユーザデータを集合ユーザデータとして流すように構成されたサーバデバイスを含む請求項４に記載のサーバ装置。

【請求項11】

前記集合プロバイダデータを使用して対処されるように構成された空間データベースを含む請求項１０に記載のサーバ装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ処理の一般的な分野に関する。いくつかの実施形態は、輸送システム（transportation system）におけるサービスの提供を表すデータの収集、分析、および表示に関する。いくつかの実施形態は、タクシー配車（ride-hailing）タイプのシステムに関する。

【背景技術】

【0002】

最も単純な形態のタクシー配車ビジネスは、そのような輸送を提供することができるサービスプロバイダとの輸送モードを探すマッチメーキングユーザに関するものである。実際のおよび予測されるサービスの提供およびサービスの需要に関連するデータは、機械学習アルゴリズムの対象とすることができる。いくつかのシステムの目的は、ユーザが輸送を望むときに輸送を受け、ユーザがユーザに最も近いサービスプロバイダにマッチすることを保証する目的で、機械学習アルゴリズムを微調整することである。しかしながら、サービスプロバイダは一般に、常に移動中である傾向がある。そして、任意の瞬間に、比較的小さなエリア内で、輸送をリクエストする何百ものユーザがいる。これは、時には最も近くにいる利用可能なサービスプロバイダが所望の輸送を迅速に提供することを可能にするには遠すぎる可能性があることを意味する。

【発明の概要】

【発明が解決しようとする課題】

【0003】

必要なことは、明確に定義されたメトリック（metrics）によって、これらの実例をスケールで分析することである。

【0004】

いくつかの実施形態の目的は、任意の所与の領域および時間で、供給と需要の関係を決定することである。

【課題を解決するための手段】

【0005】

一態様では、輸送システムを動作させる方法が提供される。このシステムは、複数の隣接する（contiguous）地理的セルを含む。この方法は、１つまたは複数のセルに位置する適格なサービスプロバイダに基づいて、少なくとも１人のユーザのためのサービスの有効利用可能性を計算する工程を含む。

【0006】

１つの構成では、この方法は、複数のサービスプロバイダの各々からユーザまでの距離を考慮に入れる工程を含む。

【0007】

１つの構成では、この方法は、複数の隣接する地理的セルのそれぞれについて需要パラメータを決定する工程をさらに含む。

【0008】

別の態様では、輸送システムを動作させるための装置が開示される。この装置は、複数のセル（ユーザが位置するセルを含む）のうちの１つに位置する複数の適格なサービスプロバイダに基づいて、ユーザごとの有効供給（effective supply）を計算するように構成される。

【0009】

一実施形態では、装置は、サービスプロバイダのデバイスから適格なサービスプロバイダの位置を示すデータを受信するように構成される。一実施形態では、サービスプロバイダの位置を示すデータは、プッシュ技術を使用して受信される。一実施形態では、サービスプロバイダの位置を示すデータは、非同期的に受信され、同期処理のためにプロバイダメッセージキューに流される（streamed）される。

【0010】

一実施形態では、装置は、ユーザの位置を示すデータを受信するように構成される。一実施形態では、ユーザの位置を示すデータは、非同期的に受信され、同期処理のためにユーザメッセージキューに流される。

【0011】

一実施形態では、装置は、サーバ装置を含む。そのサーバ装置は、プロバイダメッセージキューから同期的にプロバイダデータを受信し、ユーザメッセージキューから同期的にユーザデータを受信し、同期的プロバイダデータを集合されたプロバイダデータストリームに統合し、同期的ユーザデータを集合されたユーザデータストリームに統合するように構成されている。

【0012】

一実施形態では、装置は、集合されたプロバイダストリームからのデータを使用して対処されるように構成された空間データベースを含む。

【0013】

一実施形態では、装置は、以下のアルゴリズムを達成するためにメモリに格納された命令を実行するように構成されたプロセッサデバイスを含む。
１．パラメータ（ユーザ、プロバイダ、距離、セルの位置）のグループを収集する。
２．プロバイダによるグループ→プロバイダ（（ユーザ１、距離１、セル）、（ユーザ２、距離２、セル２））。
３．各プロバイダについて、比率（距離１、上記からの距離２を合計することによって重み付けされる）を計算する。プロバイダは、各ユーザに寄与し、(ユーザ１、ジオハッシュ１、比率１）を発行する。
４．セルによるグループ→セル１（（ユーザ１、比率１）、（ユーザ２、比率２））。
５．総需要を得るために、各セルのすべてのユーザを合計する。
６．総供給量を得るために、各セルのすべての比率を合計する。
７．総需要を総供給で割る。→各セルのＳ／Ｄメトリック
８．出力データを書き込む。

【0014】

さらなる態様では、複数のモバイルリソースおよび複数の消費者を有する地理的に分散された輸送システムを動作させる方法が提供される。この方法は、少なくとも１つの消費者から消費者の位置データと、少なくとも１つのリソースからリソースロケーションデータとを受信する工程と、リソースの位置の周りのポイントを示すデータを決定するために、空間データベースへのインデックスとしてリソースロケーションデータを使用する工程と、消費者当たりのリソースの有効供給を決定するために、各リソースの周りのグループに対するリソースの周りのポイントを示すデータと共に消費者の位置データを処理する工程とを含む。

【0015】

一実施形態では、モバイルリソースは、サービスプロバイダ、例えばドライバである。一実施形態では、消費者は、サービスユーザ、例えば乗客である。

【0016】

さらなる態様では、輸送システムオペレーティングシステムが開示される。そのシステムは、各々が需要のユニットを形成する複数のユーザと、各々が供給のユニットを形成する複数のサービスプロバイダとを有する。輸送システムは、動作領域を共に定義する複数の地理的セルを含む。ユーザ当たりの有効供給を決定する方法は、
タイムスロットについて各セルに位置された需要のユニットを決定する工程と、
タイムスロットのための各セルに位置された供給のユニットを決定する工程と、
少なくとも１つのパラメータに基づいて、適格な供給ユニットを決定する工程と、
適格な供給ユニットの位置の周辺の需要ユニットを識別する工程と、
適格な供給ユニットと、適格な需要ユニットとの間の直線距離を計算する工程と、
次のａ～ｄの工程によって有効な供給を実行する工程と、を含む。
ａ．適格な供給ユニット－適格な需要ユニットのペアごとの直線距離の比率（ratio）を算出する工程
ｂ．各ペアの重み付けを計算する工程
ｃ．各ペアに対して計算された重み付けを逆数にする工程
ｄ．逆数にされた重み付けの比率を有効な供給量として計算する工程

【0017】

代替物では、直線距離を計算するよりむしろ、経路または道路距離が計算される。これは、異なるバージョン（iteration）であってもよい。

【0018】

需給と供給とを決定しようと試みる従来の方法は、ドライバと乗客の数の単純な比率である。これは、多くの不正確さをもたらす（例えば、定義された領域の境界上のサービスリクエスタが定義された境界の反対側のサービスプロバイダに近い可能性がある）。

【発明の効果】

【0019】

実施形態は、空間および時間における需要と供給のより正確な状況を得るように構成される。

【図面の簡単な説明】

【0020】

【図1】図１は、輸送システムを動作させるための第１の例示的な通信サーバ装置を示す概略ブロック図である。

【図2】図２は、タクシー配車システムの一部の簡略化された図を示す。この場合、１つのサービスプロバイダデバイスを有する９つのセルと、サービスをリクエストする３人のユーザとを示す。

【図3】図３は、図２の一部システムの簡単な計算を示すチャートである。

【図4】図４は、典型的な日の需要－供給ギャップの例を有するシンガポールの地図である。

【図5】図５は、図４と同様の地図であるが、需要－供給分布を示している。

【図6】図６は、シンガポールの小規模住宅地域における、一日の典型的な供給需要分布のグラフである。

【図7】図７は、リバーバレー（シンガポール）で予約する最良の時間を示す、ユーザーデバイス上の需要ウィジェットからの例示的なグラフィック表示を示す。

【図8】図８は、タクシー配車システムの一部のシステムのアーキテクチャのいくつかの態様を示す部分ブロック図である。

【図9】図９は、図８のシステムのプロセッサによって実行される部分フローチャートを示す。

【発明を実施するための形態】

【0021】

まず、図１を参照すると、通信システム１００が示されている。通信システム１００は、通信サーバ装置１０２と、サービスプロバイダ通信デバイス１０４と、ユーザ通信デバイス１０６とを含む。これらのデバイスは、例えば、インターネット通信プロトコルを実現するそれぞれの通信リンク１１０、１１２、１１４を介して、通信ネットワーク１０８（例えば、インターネット）に接続される。通信デバイス１０４、１０６は、他の通信ネットワーク（例えば、移動セルラー通信ネットワークを含む公衆交換電話ネットワーク（ＰＳＴＮネットワーク）など）を介して通信することができる。しかしながら、これらは、明確にするために図１から省略されている。

【0022】

通信サーバ装置１０２は、図１に概略的に示されるように単一のサーバであってもよいし、複数のサーバコンポーネントに分散されたサーバ装置１０２によって実行される機能性を有するものであってもよい。

【0023】

図１の例では、通信サーバ装置１０２は、多数の個々のコンポーネントを含む。これは、特に限定されないが、１つまたは複数のマイクロプロセッサ１１６と、実行可能命令１２０のローディングのためのメモリ１１８（例えば、ＲＡＭのような不揮発性メモリ）と、サーバ装置１０２がプロセッサ１１６の制御の下で実行する機能性を規定する実行可能命令とを含む。通信サーバ装置１０２はまた、サーバが通信ネットワーク１０８を介して通信することができる入出力モジュール１２２を含む。ユーザインターフェース１２４は、ユーザ制御のために提供され、例えば、従来のコンピューティング周辺装置（例えば、ディスプレイモニタ、コンピュータキーボードなど）を含む。サーバ装置１０２はまた、データベース１２６を含む。その目的は、以下の説明から容易に明らかになる。

【0024】

サービスプロバイダ通信デバイス１０４（以下、「サービスプロバイダデバイス」という）は、多数の個々のコンポーネントを含む。このコンポーネントは、特に限定されないが、１つまたは複数のマイクロプロセッサ１２８と、実行可能命令１３２をロードするためのメモリ１３０（例えば、ＲＡＭなどの不揮発性メモリ）と、サービスプロバイダデバイス１０４がプロセッサ１２８の制御下で実行する機能を定義する実行可能命令とを含む。サービスプロバイダデバイス１０４はまた、サービスプロバイダデバイス１０４が通信ネットワーク１０８を介して通信することを可能にする入出力モジュール１３４を含む。ユーザインターフェース１３６は、ユーザ制御のために提供される。サービスプロバイダデバイス１０４が、例えば、スマートフォンまたはタブレットデバイスである場合、ユーザインターフェース１３６は、多くのスマートフォンおよび他の携帯デバイスにおいて普及しているようなタッチパネルディスプレイを有する。あるいは、サービスプロバイダデバイスが、例えば、従来のデスクトップまたはラップトップコンピュータである場合、ユーザインターフェースは、従来のコンピューティング周辺デバイス（例えば、ディスプレイモニタ、コンピュータキーボード等）を有する。

【0025】

ユーザ通信デバイス１０６（以下、「ユーザーデバイス」と呼ぶ）は、例えば、サービスプロバイダデバイス１０４と同一または類似のハードウェアアーキテクチャを有するスマートフォンまたはタブレットデバイスであってもよい。

【0026】

一実施形態では、タクシー配車サービスを提供するために、ユーザは、乗車（ride）をリクエストするためにユーザーデバイス１０６を使用する。「乗車」という用語は、理解の容易のために使用される。この用語は、限定的であることを意図するものではなく、例えば、ユーザがサービスプロバイダに何らかのアイテムをピックアップさせ、それを特定の住所に配達することを要求するような、複数の異なるシナリオをカバーすることを意図することに留意されたい。この実施形態では、ユーザーデバイス１０６は、デバイス上にグラフィカルなアンダーインターフェースを提供するアプリケーションを実行する。ユーザは、例えば、目的地を指定することによって、乗車を要求することができる。場合によっては、出発位置の入力が必要とされ、乗車時間の入力の準備がなされてもよい。これは、もちろん「できるだけ早く」であってもよい。

【0027】

この情報は、通信ネットワーク１０８を介して、サーバ装置１０２に送信される。そこで、その情報は、データベース１２６に保存される。実施形態におけるサーバ１０２は、乗車リクエスト情報を特定のサービスプロバイダデバイス１０４に転送することができるプログラムを実行する。サーバ装置１０２は、各サービスプロバイダデバイス１０４からサーバ装置１０２にプッシュされた情報に基づいて、本実施形態における特定のサービスプロバイダデバイス１０４を選択するようにプログラムされる。それにより、各サービスプロバイダデバイスの位置およびサービスプロバイダの利用可能性（availability）の状態を示している。したがって、この実施形態では、サーバ装置１０２は、最も近い適格なサービスプロバイダのサービスプロバイダデバイスを選択するようにプログラムされる（「適格な」はアイドル状態である、またはアイドル状態になりそうなことを意味する）。

【0028】

サービスプロバイダは、ジョブを受け入れるか、それを受け入れないかのオプションを有する。

【0029】

特定のサービスプロバイダがユーザにサービスを提供するジョブを受け入れると、この情報は、プロバイダデバイス１０４からサーバ装置１０２に提供される。これにより、この情報がデータベース１２６に記憶され、リクエストを行ったユーザのユーザーデバイスにサービスの確認のみを送信する。一実施形態では、プロバイダがユーザに到達できるまでの予測遅延も送信される。

【0030】

サーバ装置１０２は、ユーザおよびサービスプロバイダの位置に関する情報を収集し、その情報を示すデータを記憶するようにプログラムされる。このデータは、本実施形態では、高レベルの詳細であり、各移動（journey）、各乗客、各サービスプロバイダの詳細を含む。

【0031】

上記の説明は、サービスプロバイダが通常容易に利用可能であり、潜在的なユーザが適合しており、利用可能なサービスプロバイダが迅速に見つからない場合に将来のある時点で乗車を受け入れる、単純化された取り決めに関する。

【0032】

しかしながら、現実の世界では、上述したように、サービスプロバイダは、常に移動中である。任意の１つの地点で、同じエリア内に、サービスをリクエストする何百ものユーザがいる可能性がある。これは、時には、最も近い利用可能なサービスプロバイダが満足のいくサービスを提供するには遠すぎるかもしれないということを意味する。

【0033】

本明細書に記載する取り決めは、データベース１２６に記憶された情報と、サービスプロバイダデバイスからのリアルタイムデータとの一方または双方を処理して、サーバ装置１０２上で実行され、または、サーバ装置１０２によって実行される他のプロセスに供給される情報に影響を与える。これらの他のプロセスは、例えば、ジョブの可能性を高めるために、または、高収益ジョブの可能性を改善するために、アイドル状態のサービスプロバイダがどこに移動することができるかについて、アイドル状態のサービスプロバイダにアドバイスする。記述された構成の結果は、供給と需要との間の関係の表示を提供する、または、代わりに提供する。

【0034】

以下の説明では、単一の供給ユニットは、オンラインであり、所定の期間（以下、タイムスロットと呼ぶ）の開始時にアイドル状態（現在ジョブ上にない）であるサービスプロバイダである。各サービスプロバイダデバイスからそのような各タイムスロットの開始時のＧＰＳピンは、自分の位置であるとみなされる。

【0035】

タイムスロット持続時間の非限定的な例は１２０秒である。

【0036】

単一の需要ユニットは、同じタイムスロット内でサービス（例えば、輸送）の価格をチェックしているユーザである。実施形態におけるユーザの位置は、入力されたピックアップアドレスであるように選択される。別の実施形態では、これは、ユーザーデバイスによって送信される実際の現在の位置である。

【0037】

図２を参照すると、以下の開示では、地理的な地域、例えば、その周辺郊外を有する都市がセルに分割される。いくつかの実施形態では、これらのセルは、いわゆる「ジオヘクス」（ジオハッシュの六角形均等物）によって定義される。他の実施形態では、セルは、ジオハッシュによって定義される。そのような一実施形態では、位置は、ｙの精度でジオハッシュ（文字および数字のストリングに符号化された地理的位置）に集合される。ここで、ｙは、マップ上の次元の非常に小さい多角形空間を指す。非限定的な例では、セルサイズは、１．２ｋｍ×６０９．４ｍ（ジオハッシュ６）である。

【0038】

セルは、様々な形状およびサイズであることが想定される。

【0039】

次に、各供給ユニットは、供給が位置するセル内の全ての需要ユニットにマッピングされる。この場合、図２に示すように、次の外側セルにマッピングされる。

【0040】

次いで、各供給ユニットの比（fraction）は、距離によって逆数に重み付けされた隣接するセル内の需要のユニットに割り当てられる。比の合計は、１に合計される。本質的に、これは、サービスプロバイダがより遠いユーザよりも、より近いユーザに利用可能であることを意味する。

【0041】

この実施形態では、ルート距離の代わりに、直線距離がアルゴリズムの複雑さを低減するためのプロキシとして使用される。別の実施形態では、ルート距離自体が使用される。

【0042】

ユーザ当たり（すなわち、需要単位当たり）の有効供給を決定する方法は、以下の通りである。

【0043】

１．（緯度、経度で）各エリア－タイムスロットに位置する需要ユニットを決定する。
２．（緯度、経度で）各エリア－タイムスロットに位置する供給ユニットを決定する。
３．適格な供給ユニットの位置周辺の需要ユニットを特定する。
４．適格な供給ユニットと、需要ユニットとのペアの間の直線距離を計算する。
５．次のa～ｄによる有効供給を得る。
ａ．適格な供給ユニット－需要ユニットのペアの直線距離の比率を算出する。
ｂ．各ペアの重み付けを計算する。
ｃ．各ペアに対して計算された重み付けを逆数にする。
ｄ．有効供給として、逆数にされた重み付けの比率を計算する。

【0044】

一実施形態では、「適格な供給ユニット」は、需要ユニットのセルと同じセル内の供給ユニット、および、そのセルに隣接するセル内の供給ユニットであるとして、需要ユニットを参照して決定される。別の実施形態では、セルの近さの度合いは、場所によって一定ではない。したがって、ピーク時のビジネス区域（ＣＢＤ）において、適格な供給ユニットは、隣接するセルを超えるセルに見つけられる。さらに他の実施形態において、適格性を決定するためのセルは、時間とともに変化する。

【0045】

そのセル内のユーザに利用可能なすべてのプロバイダに対する各ユーザの比の合計は、各ユーザに有効な供給を与える。特定のユーザの全ての比を合計すると、そのユーザがそのタイムスロットでどの程度サービスされているかがわかる。図２は、各ユーザが図示された自動車によってどの程度良好にサービスされるかを示している。各ユーザは、供給の比を共有する。

【0046】

需要と有効な供給とは、多数のセルｉと、タイムスロットｊとの組み合わせにわたって集合される。これにより、２つの単純な集合メトリック、すなわち、供給需要比と供給需要差（図３）をもたらしている。

【0047】

いくつかの実施形態では、集合は、すべてのセルおよびすべてのタイムスロットにわたって実行されない。距離に起因するサービスプロバイダの比の分布は、狭い領域および時間における供給および需要の細分化された画像を与える。より大きな領域に集合された場合、領域の中央におけるサービスプロバイダの位置に起因する分布は失われる。

【0048】

実施形態の一のファミリーでは、すべての価格チェックおよびプロバイダの位置のデータは、履歴的にデータベースに保存される。ＳＱＬクエリの複数のレイヤを使用して、言及されたメトリックは、履歴データに対して導出される。

【0049】

実施形態の別のファミリーでは、同様のロジックは、入力データ（価格チェックおよびプロバイダの位置）がリアルタイムメッセージキューを介して流れる製品（エンジニアリングシステム）において再現される。したがって、必要に応じて、メトリックは、リアルタイム（または２～５分の遅れ）で計算される。このようにして、データは、リアルタイムで、ヒートマップ、価格設定、アプリのインセンティブのような特徴に使用される。

【0050】

いくつかの実施形態では、計算は、現在の状況、すなわち、現在のタイムスロットのみについて実行される。これは、供給／需要状況の管理を可能にする。

【0051】

他の実施形態では、計算は、各タイムスロットが発生するたびに実行され、有効な供給および需要の値はデータベース１２６に保存される。次いで、適切な時間に、例えば、各時計時間の終わりに、供給－需要比および供給／需要差は、性能の指示を提供するために合計される。

【0052】

したがって、この基本形式の下記の式では、「有効供給」の合計は、そのタイムスロット(ｉ＝１、ｊ＝１）のそのセル内のすべてのユーザの有効供給値の合計である。これは、複数の自動車に関するユーザの「有効供給」を考慮に入れる。したがって、特定のセル内に３人のユーザが存在し、これらの３人のユーザの各々にサービスを提供することができる２台の車両が存在するシナリオでは、車両１を有するユーザ１、車両１を有するユーザ２および車両１を有するユーザ３、車両２を有するユーザ１、車両２を有するユーザ２、および、車両２を有するユーザ３に対する個別の有効供給スコアを計算する。トータル有効供給スコアは、車両１および２の各々についてのユーザ１、２および３についての個別の有効供給スコアの全ての合計である。

【0053】

以下の式１ａおよび１ｂは、現在のタイムスロットについて複数の地理的セルにわたって総計するときの集合を示す。

式１ａおよび１ｂ

【0054】

対照的に、式２ａおよび２ｂは、複数の地理的セルおよび複数のタイムスロットにわたって総計するときの集合を示す。

式２ａおよび２ｂ

【0055】

式３ａおよび３ｂ

【0056】

また、式３ａおよび３ｂは、タイムスロットｊ＝０～ｊ＝ｎにわたる単一の指定された地理的セル集合の計算を示す。

【0057】

供給／需要比が１より大きい場合、これは供給過剰を示す。供給需要比が１未満である場合、これは供給不足を示す。供給需要差は、供給過剰／供給不足の程度（大きさ／スケール）を示す。また、供給過剰または供給不足があるかどうかは、（結果が正数か負数かを考慮に入れる限り）「供給需要差」の計算から判断することができる。例えば、結果が正の数をもたらす場合、これは供給過剰を示す。一方、結果が負の数をもたらす場合、これは供給不足を示す。

【0058】

データの処理

結果として得られるメトリックは単純な比および差のように見えるが、隣接する空間におけるのすべてのドライバおよび乗客をマッピングする工程を必要とする有効供給を算出する工程は、かなり重い算出である。

【0059】

この地域では、任意の所与の時点で乗り物を探している数十万人の乗客がいる可能性がある。アルゴリズムの実施形態は、各需要および供給ユニットと、その位置とを特定するだけでなく、各乗客に利用可能なわずかな供給を出力するために、同じ近隣の全ての需要ユニットに全ての供給ユニットをマッピングもする。

【0060】

供給または需要のあらゆる余分な単位は、アルゴリズムの計算能力要件を実質的に増加させる。

【0061】

上述のメトリックを用いて、需要と供給のギャップが一日中どのように変化するかをマッピングすることができる。図４は、シンガポールの典型的な日の需要と供給のギャップを示している。この場合、平日の１６日間から得られた平均値である。

【0062】

各バブルは、地図上の領域を示す。各バブルの大きさは、その地域における供給と需要の差を示している。バブルが大きくなればなるほど、ギャップは大きくなる。バブルは、供給／需要比を示すために着色されている。ここで、赤は供給不足を示し、緑は供給過剰を示す。

【0063】

ユーザがいつでも乗り物を見つけることができるようにするという目標を達成するためには、需要と供給のバランスをとる必要がある。一方で、これは、より高い需要がある領域に過剰供給を移動させる方法を見つけることによって対処される。他方、時間に敏感でない需要をピークタイムスロットからシフトさせることによって対処される。

【0064】

一日の任意の時点で、ある地域ではドライバの過剰供給があり、他の地域では供給不足がある。

【0065】

図５に示すように、これは、朝のピーク時以降のシンガポールでは一般的である。このとき、ほとんどの乗り物はＣＢＤで終わり、その結果、そのエリアで供給過剰となる。このようなシナリオはまた、空港（例えば、チャンギ空港など）の待ち行列スポットにおいても一般的である。

【0066】

この地理的－時間的アンバランスに対処するために、一実施形態では、サービスプロバイダデバイス上に表示されるヒートマップは、ドライバが過剰供給されたエリアから、より高い需要があるエリアに移動することを奨励する。

【0067】

図６は、シンガポールの小規模住宅地域における典型的な平日の需要と供給を集計したものである。

【0068】

図６のハイライトされた領域６００は、需要（水平時間軸の上方）と、供給（水平時間軸の下方）とがミスマッチである期間を示す。過去のデータを使用すると、需要は、通常のピーク時間などの予想される要因と、突然の大雨などの予測不可能な要因との両方に起因して、最大になることが知られている。しかし、需要がすでに落ち着いているときには、供給は後に増大する。

【0069】

このアンバランスに対処するために、一実施形態では、ユーザーデバイスは、数時間にわたり、可能性のある需要分布を示すように動作することができる。これは、いわゆるウィジェットを用いて実現される。ウィジェットは、情報（例えば、図７）を表示するグラフィカルユーザインターフェース（ＧＵＩ）の要素として定義される。ウィジェットは、ユーザの特定の位置に関する履歴データの合計に基づいて、需要の傾向を示す。ここでの目標は、時間に敏感でない需要（すぐに乗物を必要としないユーザ）に、需要が少ないときに予約させるために移動を遅らせることを奨励することである。これは、より緊急のニーズを有する乗客がより容易に割り当てられることを助ける。また、時間に敏感でないユーザは、旅費がより高いときに高い需要時間を見ることができる。

【0070】

次に、図８を参照して、プラットフォームの一部の例を説明する。この図は、例示的なアーキテクチャを示すが、これに限定されるものではない。

【0071】

図８の図は、２つのサービスプロバイダを示す。それぞれは、各サービスプロバイダアプリケーション５１０ａ、５１０ｂと、ユーザアプリケーション５２０を有する単一の意図するユーザとを有する。もちろん、通常、多くのサービスプロバイダおよび多くの潜在的なユーザが存在する。しかし、その数は、理解を容易にするために、ここでは少ない。

【0072】

サービスプロバイダ５１０ａ、５１０ｂと、ユーザアプリ５２０とは、例えば、無線リンク（例えば、インターネット等）を介して、第１および第２のサーバデバイス５１２、５２２からなる入力サーバデバイスに接続するように配置されている。

【0073】

サーバデバイス５１２、５２２は、導電性リンクを介して、メッセージキュー５１４、５２４に信号を出力するように構成されている。これは、導電性リンクを介して、第１および第２の消費者サーバデバイス５１６、５２６に順に接続されている。

【0074】

第１の消費者サーバデバイス５１６は、導電性リンクを介して、空間データベース５３８へ接続される。第２の消費者サーバ５２６は、導電性リンクを介して、リアルタイムイベントメッセージキュー５３６に接続される。

【0075】

リアルタイムイベントメッセージキュー５３６と、空間データベース８３８との両方は、リアルタイムイベントフレームワーク５４０に導通的に接続される。これは、次に、キャッシュ５４２にデータを出力するために接続される。

【0076】

導電性リンクは上述されているが、これらは、本発明にとって本質的なものではなく、他の接続も想定される。

【0077】

データは、サービスプロバイダデバイス５１０ａ、５１０ｂ（例えば、ドライバのデバイス上のアプリ）の両方から、および、意図しているユーザ（例えば、乗客）のユーザアプリ５２０から、非同期方式で、サーバデバイス５１２、５２２に到着する。同期処理を可能にするために、２つの非同期データフローがそれぞれのメッセージキューに形成される。

【0078】

この実施形態では、各サービスプロバイダデバイス５１０ａ、５１０ｂは、本明細書の他の箇所で説明するように、アプリを実行する。このアプリは、それぞれのメッセージ５１１ａ、５１１ｂを処理デバイス５００の第１のサーバ５１２に定期的にプッシュする。一例では、アプリは、１０秒ごとにデータをプッシュする。しかし、この時間は純粋に一例であり、他の期間も想定される。第１のサーバ５１２は、パケット化されたデータストリーム５１３としてメッセージ５１１ａ、５１１ｂからのデータを流し、第１のメッセージキュー５１４に保存する。一実施形態では、非常に高いレベルのデータの各ユニットは、この－＞（プロバイダＩＤ、位置、状態）ように見える。位置＝（緯度、経度）、および状態は、（オンライン、利用可能性、オン＿ジョブ）のうちの任意の１つとすることができる。したがって、転送されるデータは、サービスプロバイダデバイスの位置を示す情報と、それぞれのサービスプロバイダの状態を示すデータとを含む。

【0079】

他の実施形態では、他の場所で述べたように、システムは、プッシュ技術を使用するよりむしろ、状態および他のデータについてサービスプロバイダデバイスにポーリングする。

【0080】

潜在的なユーザがユーザーデバイス５２０を使用して、例えば、運賃をチェックしたり、他の情報をチェックしたりするために配車（hailing）システムにアクセスすると、このアクセスは、第２のサーバ５２２に渡される。サーバ５２２は、パケット化されたデータストリームとしてメッセージ５２１の内容を第２のメッセージキュー５２４に周期的に流す。

【0081】

非常に高いレベルの各データのユニットは、（乗客Ｄ、ピックアップ位置、運賃がチェックされた時間）のようになる。

【0082】

２つのメッセージキュー５１３および５２３からのデータ５１５、５２５は、バックエンドサービスを提供するそれぞれの消費者サーバ５１６、５２６に渡される。一実施形態では、それらは、用語「Ｇｏ」でプログラムされる。

【0083】

消費者サーバ５２６は、データ５２５を使用して、セル毎のベース（例えば、セル毎（またはジオハッシュ毎）のベース）、運賃をチェックする人などの潜在的なユーザをすべて集める。また、消費者サーバ５２６は、パケット化された集合データ５３５をリアルタイムイベントメッセージキュー５３６に流す。実施形態における集合データ５３５は、所定の時間ウィンドウ（例えば、２分ウィンドウ）に対するジオハッシュ毎の累積運賃チェックを含む。一実施形態では、各パケットは、以下のようである。
セル１[{ユーザＩＤ１、ピックアップ位置｝、{ユーザＩＤ２、ピックアップ位置｝］

【0084】

消費者サーバ５１６は、パケット化されたデータ５３７を空間データベース５３８に渡す。データ５３７は、データ５１５から導出され、オンラインでアイドル状態にあるサービスプロバイダの代表である。したがって、これらのサービスプロバイダは、空間データベース５３８内でインデックス付けされる。

【0085】

空間データベース５３８は、幾何学的空間で定義されたオブジェクトを表すデータを保存し、問い合わせるために最適化される。これは、インデックス付けを使用して、空間インデックスに基づいて値を迅速に検索する。そして、ストリーム５３７の各入力インデックス値の指定された半径内のすべてのポイントを見つけて、出力する能力を提供する。空間データベース５３８の出力ストリーム５３９は、リアルタイムイベントキュー５３６からのデータ５４１と共に、リアルタイムデータ処理フレームワーク５４０に渡される。

【0086】

リアルタイムイベントフレームワーク５４０は、データ５４１（乗客のリストおよびジオハッシュ当たりの乗客の位置）を受信し、ジオハッシュ当たりの乗客毎に、データ５３９を使用して半径１ＫＭ内のすべてのドライバを見つける。

【0087】

アルゴリズムの一例は、以下のようである。
パラメータ（乗客、ドライバ、距離、ジオハッシュ）を収集する。
ドライバによるグループ＝＞ドライバ１（（乗客１、距離１、ジオハッシュ１）、（乗客２、距離２、ジオハッシュ２））^＊。
ドライバごとに、比率（距離１、上記からの距離２を合計して加重）を計算する。これは、各乗客に寄与し、（乗客１、ジオハッシュ１、比率１）を発行する。
ジオハッシュによるグループ＝＞ジオハッシュ１（（乗客１、比率１）、（乗客２、比率２））。
総需要を得るために、各ジオハッシュのすべての乗客を合計する。
総供給を得るために、各ジオハッシュのすべての比率を合計する。
総需要を総供給で割る＝＞各ジオハッシュについてのＳ／Ｄメトリック。
出力をキャッシュに書き込む。
^＊は、このドライバ（ドライバ１）が供給源である全ての乗客のセットを表す。

【0088】

このアルゴリズムは、図９にさらに完全に示されている。

【0089】

リアルタイムイベントフレームワークからのデータ５３９は、保存のためにキャッシュ５４０に出力され、様々なアプリケーション（図示しない）への迅速な書き込み（５３９から）および読み出しを可能にする。このようなアプリケーションは、ドライバのヒートマップ、価格急騰、および需要予測を含む。

【0090】

実施形態の別のファミリーでは、有効供給の決定は、タイムスロット終了時に直接実行されるのではなく、代わりに別の時に実行される。これらの他の実施形態の１つでは、前日の全体の計算は、需要が少ない夜間に実行される。

【0091】

本発明は、一例としてのみ記載されていることが理解される。添付の特許請求の範囲の精神および範囲から逸脱することなく、本明細書で説明される技術に様々な修正を行うことができる。開示された技術は、スタンドアロン方式で、または互いに組み合わせて提供される技術を含む。したがって、１つの技術に関して説明した特徴は、別の技術と組み合わせて提示することもできる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】