特許 7334260 複数のデータ構造を管理するための通信装置、通信方法、コンピュータプログラム、非一時的な記憶媒体および通信システム

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

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

(11)【特許番号】

(24)【登録日】2023-08-18

(45)【発行日】2023-08-28

(54)【発明の名称】複数のデータ構造を管理するための通信装置、通信方法、コンピュータプログラム、非一時的な記憶媒体および通信システム

(51)【国際特許分類】

   G06Q 50/30 20120101AFI20230821BHJP

   G06F 16/635 20190101ALI20230821BHJP

   G06F 9/52 20060101ALN20230821BHJP

【ＦＩ】

G06Q50/30

G06F16/635

G06F9/52 150Z

【請求項の数】 15

(21)【出願番号】P 2021556283

(86)(22)【出願日】2019-03-21

(65)【公表番号】

(43)【公表日】2022-06-02

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

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

(87)【国際公開日】2020-09-24

【審査請求日】2022-01-07

(73)【特許権者】

【識別番号】518236797

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

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

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

(74)【代理人】

【識別番号】100137095

【弁理士】

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

(74)【代理人】

【識別番号】100173691

【弁理士】

【氏名又は名称】高橋 康久

(74)【代理人】

【識別番号】100091627

【弁理士】

【氏名又は名称】朝比 一夫

(72)【発明者】

【氏名】マダーン，ヨゲシュ

(72)【発明者】

【氏名】テオ，ヨンカイ

【審査官】牧 裕子

(56)【参考文献】

【文献】特開２０１９－０２０９４２（ＪＰ，Ａ）

【文献】特開２００３－３１６８６１（ＪＰ，Ａ）

【文献】特開２０１０－２６７３０２（ＪＰ，Ａ）

【文献】特表２０１９－５３７１６６（ＪＰ，Ａ）

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

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

Ｇ０６Ｑ １０／００ － ９９／００

Ｇ０６Ｆ １６／６３５

Ｇ０６Ｆ ９／５２

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

【請求項1】

ライドヘイリング輸送サービスにおける複数のデータ構造を管理する通信装置であって、プロセッサとメモリを備え、前記通信装置は、前記プロセッサの制御下で、
通信サーバ装置から送信されたデータストリームの状態の変化を監視し、前記データストリームは複数のデータ構造を含み、各データ構造は関連するタイムスタンプ、および前記通信サーバ装置に送信されたライドヘイリング輸送サービスに関連付けられたジョブに関するリクエストに対応するデータを有し、
監視された変化を引き起こしたリクエストに関連するデータ構造を、関連付けられたタイムスタンプに基づいて順次フィルタリングする、メモリ内の命令を実行するように構成され、
フィルタリングのために、前記通信装置は、各データ構造に対して、
前記データ構造に対応するリクエストに関連するジョブに対応するデータをデータベースに照会し、
前記ジョブに対応するデータが前記データベースに含まれている場合、
前記ジョブに対応する前記データから、前記ジョブのステータスを決定し、
前記ステータスおよび前記データ構造の前記データに基づいて、前記データ構造の前記データが有効なデータであるかどうかを判断し、
キャンセルのリクエストにより、前記ジョブのステータスと、前記データ構造の前記データとが互いに矛盾するとき、前記データ構造の前記データを無効なデータと判断し、
前記ジョブに対応するデータがデータベースに存在しない場合、前記データ構造の前記データを有効なデータと判断し、
有効なデータであると判断された前記データ構造の前記データを処理するように構成され、
前記データ構造の前記データを処理するために、前記通信装置は、各データ構造について、有効なデータに基づいて関連するジョブのデータでデータベースを更新するように構成される、
通信装置。

【請求項2】

前記データ構造の前記データを処理するために、前記通信装置は、データ構造ごとに、前記有効なデータを、前記通信装置のユーザインターフェースを介して提示可能なテンプレートにマッピングするように構成される、
請求項１に記載の通信装置。

【請求項3】

前記ライドヘイリング輸送サービスが、ピックアップ場所および少なくとも１つの目的地からなる行程を構成し、
前記通信装置は、
サービス提供者が前記ピックアップ場所に到着したことを示すデータのデータソースを監視し、
前記ピックアップ場所に到着したことを示すデータで前記データベースを更新するように構成される、
請求項１に記載の通信装置。

【請求項4】

前記通信装置が、
前記ピックアップ場所でのピックアップ動作の完了を示すデータのデータソースを監
視し、
前記ピックアップ動作の完了を示すデータで前記データベースを更新するようにさらに構成される、
請求項３に記載の通信装置。

【請求項5】

前記少なくとも１つの目的地が、行程の終わりの最終目的地を含み、
前記通信装置は、さらに
前記ライドヘイリング輸送サービスの終了リクエストに対応するデータを有するデータ構造を前記通信サーバ装置に送信するように構成され、
前記データは最終目的地に到着したことを示す、
請求項３または４に記載の通信装置。

【請求項6】

前記少なくとも１つの目的地が、最終目的地に向かう行路の途中にある中間地点を含み、
前記通信装置は、さらに
前記サービス提供者が中間地点に到着したことを示すデータのデータソースを監視し、
前記中間地点に到着したことを示すデータで、前記データベースを更新するように構成される、
請求項５に記載の通信装置。

【請求項7】

ライドヘイリング輸送サービスにおける複数のデータ構造を管理するために通信装置で実行される方法であって、前記通信装置のプロセッサの制御の下で行われ、
通信サーバ装置から送信されたデータストリームの状態の変化を監視し、前記データストリームは、複数のデータ構造を含み、各データ構造は、関連するタイムスタンプと、前記通信サーバ装置に送信されたライドヘイリング輸送サービスに関連付けられたジョブに関するリクエストに対応するデータとを有し、
監視された変化を引き起こしたリクエストに関連する前記データ構造を、関連付けられた前記タイムスタンプに基づいて順次フィルタリングすることを含み、
各データ構造に対してフィルタリングすることは、
前記データ構造に対応する前記リクエストに関連する前記ジョブに対応するデータをデータベースに照会し、
前記ジョブに対応するデータが前記データベースに含まれている場合、
前記ジョブに対応する前記データから、前記ジョブのステータスを決定し、
前記ステータスおよび前記データ構造の前記データに基づいて、前記データ構造の前記データが有効なデータであるかどうかを判断し、
キャンセルのリクエストにより前記ジョブのステータスと、前記データ構造の前記データとが互いに矛盾するとき、前記データ構造の前記データを無効なデータと判断し、
前記ジョブに対応するデータが前記データベースに存在しない場合、前記データ構造の前記データを有効なデータと判断し、
有効なデータであると判断された前記データ構造の前記データを処理し、
前記データ構造の前記データを処理することは、各データ構造について、有効なデータに基づいて関連するジョブのデータで前記データベースを更新することを含む、
方法。

【請求項8】

前記データ構造の前記データを処理することは、データ構造ごとに、前記有効なデータを、前記通信装置のユーザインターフェースを介して提示可能なテンプレートにマッピングすることを含む、
請求項７に記載の方法。

【請求項9】

前記ライドヘイリング輸送サービスが、ピックアップ場所および少なくとも１つの目的地からなる行程を構成し、
前記方法は、
サービス提供者がピックアップ場所に到着したことを示すデータのデータソースを監視し、
前記ピックアップ場所に到着したことを示すデータでデータベースを更新する、
請求項７に記載の方法。

【請求項10】

前記方法は、
前記ピックアップ場所でのピックアップ動作の完了を示すデータの前記データソースを監視し、
前記ピックアップ動作の完了を示すデータで前記データベースを更新することをさらに含む、
請求項９に記載の方法。

【請求項11】

前記少なくとも１つの目的地が、行程の終わりの最終目的地を含み、
前記方法は、さらに
前記ライドヘイリング輸送サービスの終了リクエストに対応するデータを有するデータ構造を前記通信サーバ装置に送信することを含み、
前記データは前記最終目的地に到着したことを示す、
請求項９または１０に記載の方法。

【請求項12】

前記少なくとも１つの目的地が、前記最終目的地に向かう行路の途中にある中間地点を含み、
前記方法は、さらに
前記サービス提供者が中間地点に到着したことを示すデータのデータソースを監視し、
前記中間地点に到着したことを示すデータで、データベースを更新することを含む、
請求項１１に記載の方法。

【請求項13】

請求項７乃至１２のいずれか一項に記載の方法を実施するための命令を含む、
コンピュータプログラム。

【請求項14】

プロセッサによって実行されると、前記プロセッサに請求項７乃至１２のいずれか一項に記載の方法を実行させる命令を格納する、
非一時的な記憶媒体。

【請求項15】

ライドヘイリング輸送サービスにおける複数のデータ構造を管理するための通信システムであって、通信サーバ装置と、少なくとも１つのユーザ通信装置と、前記通信サーバ装置と前記少なくとも１つのユーザ通信装置がその中で相互に通信を確立するために動作可能な通信ネットワーク装置とを備え、
前記通信サーバ装置が、第１のプロセッサおよび第１のメモリを備え、前記通信サーバ装置が、前記第１のプロセッサの制御下で、
前記複数のデータ構造を含むデータストリームを送信する、前記第１のメモリ内の第１の命令を実行するように構成されており、各データ構造は、関連するタイムスタンプと、通信サーバ装置に送信されたライドヘイリング輸送サービスに関連付けられたジョブに関するリクエストに対応するデータとを有し、
前記少なくとも１つのユーザ通信装置は、第２のプロセッサおよび第２のメモリを備え
、前記少なくとも１つのユーザ通信装置が、前記第２のプロセッサの制御下で、
データストリームの状態の変化に対して前記通信サーバ装置から送信されたデータストリームを監視し、
監視された変化を引き起こしたリクエストに関連するデータ構造を、関連付けられたタイムスタンプに基づいて順次フィルタリングする、前記第２のメモリ内の第２の命令を実行するように構成され、
フィルタリングのために、前記ユーザ通信装置は、各データ構造に対して、
前記データ構造に対応する前記リクエストに関連する前記ジョブに対応するデータをデータベースに照会し、
前記ジョブに対応するデータが前記データベースに含まれている場合、
前記ジョブに対応する前記データから、前記ジョブのステータスを決定し、
前記ステータスおよび前記データ構造の前記データに基づいて、前記データ構造の前記データが有効なデータであるかどうかを判断し、
キャンセルのリクエストにより前記ジョブのステータスと、前記データ構造の前記データとが互いに矛盾するとき、前記データ構造の前記データを無効なデータと判断し、
前記ジョブに対応するデータがデータベースに存在しない場合、前記データ構造の前記データを有効なデータと判断し、
有効なデータであると判断された前記データ構造の前記データを処理するように構成され、
前記データ構造の前記データを処理するために、前記ユーザ通信装置は、各データ構造について、有効なデータに基づいて関連するジョブのデータでデータベースを更新するように構成される、
通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、通信の分野に関する。本発明の一態様は、複数のデータ構造を管理するための通信装置に関するものである。本発明の他の態様は、複数のデータ構造を管理するための方法、および複数のデータ構造を管理するための通信システムに関するものである。

【0002】

本発明の１つの側面は、輸送関連サービス、例えばライドヘイリング輸送サービスに関連する複数のデータ構造を管理することに特に適用されるが、それだけではない。

【背景技術】

【0003】

現在の技術では、データベースへの直接アクセスを公開しているため、複数のコンポーネントやチャネルが同時にデータベースにアクセスしようとする可能性があり、アクセス制御が非常に困難になっている。その結果、データベースにアクセスするＵＩ（ユーザインターフェース）レイヤーは、複数のコンポーネントがアクセスすることで競合状態を引き起こす可能性がある。

【0004】

また、ビジネスロジックを含むアクティビティは、アクティビティにＡｎｄｒｏｉｄのランタイムライフサイクルが依存しているため、Ａｎｄｒｏｉｄでアクティビティコードをテストすることは比較的困難である。

【発明の概要】

【0005】

本発明の態様は、独立請求項に記載されている通りである。いくつかの任意の機能は、従属請求項に定義されている。

【0006】

本明細書で開示されている技術を実装することで、大きな技術的利点が得られる可能性がある。これらは、既に関連するタイムスタンプと共に通信サーバ装置から送信されるデータ構造を有するデータストリームを含んでもよい。データストリームは、データストリームの状態におけるあらゆる変化について監視されてもよい。その後、データ構造の少なくとも一部は、関連付けられたタイムスタンプおよびジョブの状態に基づいて処理／フィルタリングされてもよい。

【0007】

少なくともいくつかの実装では、本明細書で開示されている技術により、データベースへの問い合わせと更新、およびデータベースからの読み取りを、１つのアクセスポイントまたはコンポーネントを介して実行することができる。少なくともいくつかの他の実装では、データベースの照会および更新は１つのアクセスポイントまたはコンポーネントを介して行われ、データベースからの読み取りは別のアクセスポイントまたはコンポーネントを介して行われてもよい。

【0008】

少なくともいくつかの実装では、データ構造の処理が関連するタイムスタンプの順に実行されるため、本明細書で開示されている技術により、データベースへのアクセスをよりよく制御することができる。したがって、望ましくない競合状態のリスクを最小限に抑えることができる。実質的に、この技術は、データベースへの逐次的なアクセスを制御し、データベース内のデータの整合性を損なう可能性のある、複数のスレッドによるデータベースへの同時書き込みを阻止することができる。さらに、ジョブのステータスに基づいてフィルタリングを行い、さらなる処理に有効なデータ構造を特定することで、効率性と処理の高速化を図ることができる。

【0009】

例示的な実装では、ここで開示されている技術の機能は、携帯電話などの携帯型通信装置上で動作するソフトウェアに実装されている場合がある。本明細書で開示された技術の機能を実装したソフトウェアは、ユーザがオンラインストアからダウンロードした「アプリ」（コンピュータプログラム、またはコンピュータプログラム製品）に含まれている場合がある。例えば、ユーザの携帯電話で実行する場合、携帯電話のハードウェア機能を使用して、複数のデータ構造を管理するための安全な通信チャネルを確立するために携帯電話のトランシーバーコンポーネントを使用するなど、以下に説明する機能を実装することができる。

【図面の簡単な説明】

【0010】

以下、本発明を例示しながら、添付の図面を参照して説明する。

【図1】通信サーバ装置を含む例示的な通信システムを示す概略ブロック図である。

【図2A】複数のデータ構造を管理する通信装置の構成を示す概略ブロック図である。

【図2B】複数のデータ構造を管理するために通信装置で実行される方法を示すフローチャートである。

【図3A】複数のデータ構造を管理する技術を示すフローチャートである。

【図3B】複数のデータ構造を管理する技術を示すフローチャートである。

【図3C】複数のデータ構造を管理する技術を示すフローチャートである。

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

【0011】

様々な実施形態は、スケーラブルな未来のためにジョブトランジットスクリーンを再設計することに関するものである。

【0012】

本技術は、ジョブデータベースへのアクセスに対するアクセス制御を実装してもよい。以下でさらに説明するように、いくつかの実施形態では、表示ジョブディスパッチャは、（データ）ストリームからイベントを受信する際に、データベースに書き込むことができる唯一のコンポーネントであってもよい。ジョブディスパッチャは、イベントの連続的な処理を維持するために、タイムスタンプに基づいてリクエストをフィルタリングする責任を負うかもしれない。また、アプリケーション内で統一されたデータフローを実現するために、ＵＩ（ユーザインターフェース）で消費されるアクティブなジョブにアクセスするためのＡＰＩ（アプリケーション・プログラミング・インターフェース）を公開することもできる。

【0013】

少なくともいくつかの実装では、すべてのリクエストを「表示ジョブディスパッチャ」を介してルーティングし、すべてのフィルタリング・ロジックを共通の場所でスマートに処理することで、データベースへのアクセスを制御することができる。

【0014】

本明細書で開示されている技術のＵＩ層は、ＭＶＶＭ（Ｍｏｄｅｌ－Ｖｉｅｗ－Ｖｉｅｗ Ｍｏｄｅｌ）パターンに基づき、１つのアクティビティが（ちょうど）１２の異なるビューモデルを使用することができる。これらのビューモデルの各々は、アクティビティのライフサイクルを認識し、他のビューモデルに関する情報を持たないこともあり、これは独立した非結合のシステムとなる。これにより、他のビューモデルに影響を与えることなく、いずれかのビューモデルに機能を追加することができ、プロセスやシステムを迅速に進めることができる。ビューモデルは完全にテストされており、様々な公開技術に採用される可能性がある。

【0015】

まず図１を参照すると、様々な実施形態で適用可能な通信システム１００が図示されている。通信システム１００は、通信サーバ装置１０２と、第１のユーザ（またはクライアント）通信装置１０４と、第２のユーザ（またはクライアント）通信装置１０６とを含む。これらの装置１０２，１０４，１０６は、例えばインターネット通信プロトコルを実装したそれぞれの通信リンク１１０，１１２，１１４を介して、通信ネットワーク１０８（例えばインターネット）に接続されている。通信装置１０４，１０６は、携帯電話通信網を含む公衆交換電話ネットワーク（ＰＳＴＮネットワーク）などの他の通信網を介して通信することができてもよいが、これらは明確にするために図１では省略されている。装置１０４，１０６と同様の１つ以上の他の通信装置があってもよいことを理解すべきである。

【0016】

通信システム１００は、複数のデータ構造を管理するためのものであってもよい。

【0017】

通信サーバ装置１０２は、図１に模式的に示されているように単一のサーバであってもよいし、通信サーバ装置１０２によって実行される機能を複数のサーバコンポーネントに分散させてもよい。図１の例では、通信サーバ装置１０２は、１つまたは複数のマイクロプロセッサ（μＰ）１１６と、実行可能な命令１２０をロードするためのメモリ１１８（例えば、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）などの揮発性メモリ）とを含むが、これらに限定されない多数の個別コンポーネントを含んでもよく、実行可能な命令１２０は、プロセッサ１１６の制御下でサーバ装置１０２が遂行する機能を定義するものである。また、通信サーバ装置１０２は、サーバ装置１０２が通信ネットワーク１０８を介して通信することを可能にする入出力（Ｉ／Ｏ）モジュール１２２を含んでもよい。ユーザインターフェース（ＵＩ）１２４は、ユーザ制御のために提供され、例えば、ディスプレイモニタ、コンピュータキーボードなどの１つまたは複数のコンピューティング周辺機器を含んでもよい。また、通信サーバ装置１０２は、データベース（ＤＢ）１２６を含んでもよく、その目的は以下の議論から容易に明らかになるであろう。

【0018】

なお、通信サーバ装置１０２は、複数のデータ構造を有するデータストリームを送信するものであってもよい。

【0019】

ユーザ通信装置１０４は、１つまたは複数のマイクロプロセッサ（μＰ）１２８と、実行可能な命令１３２をロードするためのメモリ１３０（例えば、ＲＡＭなどの揮発性メモリ）とを含むが、これらに限定されない多数の個別コンポーネントを含んでもよく、実行可能な命令１３２は、プロセッサ１２８の制御下でユーザ通信装置１０４が遂行する機能を定義する。ユーザ通信装置１０４はまた、ユーザ通信装置１０４が通信ネットワーク１０８を介して通信することを可能にする入力／出力（Ｉ／Ｏ）モジュール１３４を含む。ユーザ制御のために、ユーザインターフェース（ＵＩ）１３６が提供される。ユーザ通信装置１０４が、例えば、スマートフォンやタブレットデバイスである場合、ユーザインターフェース１３６は、多くのスマートフォンや他のハンドヘルドデバイスで普及しているようなタッチパネルディスプレイを有していてもよい。あるいは、ユーザ通信装置１０４が、例えば、ポータブルコンピュータまたはラップトップコンピュータである場合、ユーザインターフェースは、例えば、ディスプレイモニタ、コンピュータキーボードなどの１つまたは複数のコンピューティング周辺機器を有していてもよい。

【0020】

ユーザ通信装置１０６は、例えば、ユーザ通信装置１０４と同一または類似のハードウェアアーキテクチャを有するスマートフォンやタブレット端末であってもよい。

【0021】

なお、ユーザ通信装置１０４及び／又はユーザ通信装置１０６は、複数のデータ構造を管理するためのものであってもよい。

【0022】

図２Ａは、複数のデータ構造を管理するための通信装置２０４を例示する概略ブロック図である。通信装置２０４は、プロセッサ２２８およびメモリ２３０を含み、通信装置２０４は、プロセッサ２２８の制御下で、メモリ２３０内の命令を実行して、通信サーバ装置から送信されたデータストリーム２５２を監視して、データストリーム２５２の状態の変化を監視するように構成され、データストリーム２５２は、複数のデータ構造（例えば、２つのデータ構造２５３ａ、２５３ｂが図示されている）を有し、各データ構造２５３ａ、２５３ｂは、関連付けられたタイムスタンプと、通信サーバ装置に送信されたジョブに関連するリクエストに対応するデータを有し、関連付けられたタイムスタンプに基づいて順次監視された変化を引き起こしたリクエストに関連するデータデータ構造（例えば、２５３ａ）をフィルタリングするように構成され、フィルタリングのために、通信装置２０４は、各データ構造２５３ａについて、データ構造２５３ａに対応するリクエストに関連するジョブに対応するデータをデータベースに照会し、ジョブに対応するデータがデータベースに含まれている場合、ジョブに対応するデータ、ジョブのステータスから決定するように構成され、データ構造２５３ａのステータスとデータとに基づいて、データ構造２５３ａのデータが有効なデータであるかどうかを判断し、データベースにジョブに対応するデータがない場合には、データ構造２５３ａのデータを有効なデータと判断し、有効なデータと判断されたデータ構造２５３ａのデータを処理する。プロセッサ２２８およびメモリ２３０は、（線２２９で表されるように）互いに結合されていてもよく、例えば、物理的に結合および／または電気的に結合されていてもよい。プロセッサ２２８は、プロセッサ１２８（図１）の文脈で説明したとおりであってもよく、および／または、メモリ２３０は、メモリ１３０（図１）の文脈で説明したとおりであってもよい。

【0023】

言い換えれば、（ユーザ）通信装置２０４が提供されてもよい。通信装置２０４は、通信サーバ装置から提供されるか、または通信サーバ装置から／によって送信される可能性のあるデータストリーム２５２を監視し、データストリーム２５２の状態の変化について監視してもよい。データストリーム２５２は、複数のデータ構造２５３ａ、２５３ｂ（例えば、２つ、３つ、４つ、またはそれ以上の数のデータ構造）を含んでもよい。各データ構造２５３ａ、２６３ｂは、自身のタイムスタンプを有していてもよく、ジョブに関連するリクエストに対応するデータまたは情報を含んでいてもよい。リクエストは、通信サーバ装置に送信されてもよい。非限定的な例として、関連するタイムスタンプは、リクエストが通信サーバ装置によってまたは通信サーバ装置で受信されるときに割り当てられてもよい。

【0024】

非限定的な例として、データストリーム２５２の一部として、新たなリクエストまたは新たなジョブに対応するデータ構造、または１つ以上のジョブの状態の変化（例えば、ジョブに関連する更新、例えば、ジョブのキャンセル、ジョブが別のサービス提供者に割り当てられることなど）に対応するデータ構造が組み込まれる／挿入されることにより、データストリーム２５２の状態に変化が生じることがある。

【0025】

通信装置２０４は、監視された変化を引き起こすリクエストに関連する（すべての）データ構造を、関連するタイムスタンプに基づいて順次フィルタリングしてもよい。これは、各データ構造について、通信装置２０４が、データベース（例えば、通信装置２０４に含まれる）に、データ構造に対応するリクエストに関連するジョブに対応するデータを照会することを含んでもよい。データベースにジョブに対応する既存のデータまたは情報がある場合、通信装置２０４は、ジョブに対応するデータから、ジョブのステータスを判断し、ステータスおよびデータ構造のデータに基づいて、データ構造のデータが有効なデータであるかどうかを判断してもよい。

【0026】

非限定的な例として、サービス提供者に割り当てられた、または受け入れられたジョブが既に存在する場合がある。その後、ジョブをリクエストした人によってジョブがキャンセルされることがある。このようにして、データベース内のジョブのステータスとキャンセルリクエストは互いに互換性があり、キャンセルリクエストに関連するデータ構造のデータは、有効なデータであると判断されてもよい。

【0027】

さらなる非限定的な例として、新しいジョブの依頼があるかもしれない。その後、ジョブリクエスト者によってジョブリクエストがキャンセルされ、続いてサービス提供者がジョブリクエストを「受理」してもよい。このようにして、キャンセルリクエスト後のデータベース内のジョブの状態と、サービス提供者がジョブリクエストを「受け入れる」ことに関連するデータ構造のデータとは、キャンセルによりサービス提供者が受け入れるべきジョブが事実上存在しないため、互いに対立する。そのため、サービス提供者がジョブリクエストを「受け入れる」ことに関連するデータ構造のデータは、無効なデータであると判断することができる。

【0028】

データベースにジョブに対応するデータが存在しない場合、通信装置２０４は、データ構造のデータを有効なデータと判断してもよい。これは、データ構造のデータと衝突する可能性があるデータベースに既存のジョブの状態が、存在しないためである。非限定的な例として、データ構造のデータは、新しいジョブリクエストに対応していてもよい。

【0029】

続いて、通信装置２０４は、有効なデータであると判断されたデータ構造のデータを処理してもよい。これは、関連付けられたタイムスタンプに基づいて、順次行われてもよい。

【0030】

データ構造のデータを処理するために、通信装置２０４は、各データ構造（例えば、２５３ａ）について、有効なデータに基づいて、関連するジョブのデータでデータベースを更新するように構成されてもよい。

【0031】

データ構造のデータを処理するために、通信装置２０４は、各データ構造（例えば、２５３ａ）について、有効なデータを、通信装置２０４のユーザインターフェース（ＵＩ）を介して提示可能（または閲覧可能）なテンプレートにマッピングするように構成されてもよい。これにより、通信装置上でユーザ／サービス提供者に提示するための「ビュー」モードへのマッピングが提供される。実質的に、生データを持つＤＢ（データベース）モデルは、ビューデータを持つドメインモデルにマッピングされる可能性がある。

【0032】

様々な実施形態において、ジョブは、輸送関連のサービスを含んでいてもよいし、輸送関連のサービスであってもよい。これは、１つまたは複数のアイテムを１つまたは複数の場所に届けるサービス、１つまたは複数の人のための輸送サービスなどを含んでもよい。

【0033】

様々な実施形態において、輸送関連サービスは、ライドヘイリング交通サービスを含んでもよいし、ライドヘイリング交通サービスであってもよい。これには、例えば、車のヘイリング、および（モーター）バイクのヘイリングサービスが含まれる場合がある。

【0034】

様々な実施形態において、輸送関連サービスは、ピックアップ場所および少なくとも１つの目的地場所を有する行程を含んでもよい。通信装置２０４は、ピックアップ場所へのサービス提供者の到着を示すデータについて、データソース（またはデータストレージ）を監視し（例えば、データソース内の１つまたは複数のファイルを監視し）、ピックアップ場所への到着を示すデータでデータベースを更新するようにさらに構成されてもよい。例えば、サービス提供者（例えば、ドライバー）は、ピックアップ場所に到達するとき、または到達したときに、更新として「私はここにいます」というリクエストを送信してもよい。

【0035】

様々な実施形態の文脈において、データソースは、パブリックメモリプールまたは共有メモリプールであってもよい。

【0036】

様々な実施形態では、通信装置２０４は、ピックアップ場所でのピックアップ動作の完了を示すデータについてデータソースを監視し、ピックアップ動作の完了を示すデータでデータベースを更新するようにさらに構成されてもよい。非限定的な例として、ピックアップ動作の完了を示すデータは、ピックアップ場所の住所を代表するデータを含んでもよい。例えば、サービス提供者（例えば、ドライバー）は、乗客がピックアップされた場合など、ピックアップ場所でピックアップ動作が履行された場合に、更新として、「完了した住所」というリクエストを送信してもよい。

【0037】

様々な実施形態において、少なくとも１つの目的地の場所は、行程の終わりの最終目的地の場所を含んでもよい。通信装置２０４は、輸送関連サービスの終了リクエストに対応するデータを有するデータ構造を通信サーバ装置に送信するようにさらに構成されてもよく、このデータは、最終目的地の場所への到着を示す。このデータ構造は、データストリームに組み込まれてもよい。

【0038】

様々な実施形態において、少なくとも１つの目的地の場所は、最終目的地の場所に向かう行程の途中にある中間場所を含んでもよい。通信装置２０４は、中間地点へのサービス提供者の到着を示すデータについてデータソースを監視し（例えば、データソース内の１つまたは複数のファイルを監視し）、中間地点への到着を示すデータでデータベースを更新するようにさらに構成されてもよい。例えば、サービス提供者（例えば、ドライバー）は、更新として、中間地点に到達するとき、または到達したときに、「私はここにいます」というリクエストを送信してもよい。また、中間地点でのピックアップ動作が完了した場合、または完了した場合には、さらに「完了したアドレス」のリクエストを更新として送信してもよい。中間地点は、ピックアップ（例えば、１人または複数の追加の乗客が乗るため）および／またはドロップオフ（例えば、１人または複数の既存の乗客が降りるため）のためのものであってもよい。

【0039】

様々な実施形態の文脈において、データソースは、データベースに加えて、別のデータソースとして機能する。

【0040】

様々な実施形態の文脈において、データソースは、パブリックメモリプールである共有設定データストレージ（ＡｎｄｒｏｉｄのＯＳまたは環境の場合）であってもよいし、それを含んでいてもよい。

【0041】

様々な実施形態において、複数の目的地の場所や複数のドロップオフの場所があってもよい。最終目的地の場所への到着を示すデータは、通信サーバ装置に知らされるが、中間地点の到着を示すデータは、通信装置２０４上のアプリにのみ知らされてもよい。

【0042】

図２Ｂは、複数のデータ構造を管理するための通信装置で実行され、通信装置のプロセッサの制御下にある、方法を示すフローチャート２４０である。

【0043】

２４２において、通信サーバ装置から送信されたデータストリームの状態の変化について監視する。データストリームは、複数のデータ構造を有し、各データ構造は、関連するタイムスタンプと、通信サーバ装置に送信されたジョブに関連するリクエストに対応するデータとを有している。

【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】

フローチャート３８０の文脈における実装では、「表示ジョブディスパッチャ」３８４は、図３Ｂの文脈で説明され得るように、任意のデータベース変更３８７ａ、および／または「完了した私はここにいる」に関連するデータ３８７ｂまたは「完了したアドレス」に関連するデータ３８７ｃのうちの少なくとも１つについて、対応する通信装置に関連付けられた共有設定データストレージを監視してもよい。

【0081】

「表示ジョブディスパッチャ」３８４は、図３Ａの文脈で説明したような「Ｄｂ－ドメインマッパー」３８５から出力を受け取ってもよい。「表示ジョブディスパッチャ３８４は、さらに、図３Ａの文脈で説明されるような、ＵＩモジュール３８１ｂにおける対応する垂直デポジトリおよびＵＩを介して、表示ジョブのリストを提供してもよい。

【0082】

図３Ｃの文脈における実施例では、「表示ジョブディスパッチャ」３８４は、データベース３８３から読み出す唯一のコンポーネントである。さらに、データベース３８３の更新は、「状態ロジック」３８２に委ねられるようになった。

【0083】

本技術の様々な実装では、データストリームは、個人または単一のユーザまたはサービス提供者（例えば、ドライバー）を対象としており、サービス提供者の通信装置がデータストリームを監視するために使用されてもよい。本明細書に記載の「表示ジョブディスパッチャ」は、サービス提供者の通信装置上のサービス提供者のアプリに常駐していてもよい。この技術により、ジョブに関連するデータの変化、例えば、新しいジョブ、ジョブの変更などを探すことができてもよい。フィルタリングは、ジョブＩＤによって実行されてもよい。さらに、本技術は、データベースの変更を監視すること、および／または、サービス提供者の電話／アプリのストリームバッファを監視することを可能にしてもよい。本明細書に開示された技術では、ジョブが有効なジョブであるかどうかを判断するためにクエリが実行されてもよく、そうであれば、ジョブの新しい状態のためにデータベースの更新が実行されてもよい。

【0084】

上述したように、現行技術に関連する１つ以上の問題に対処するために、データベースへの複数のアクセスを制御することによって、データベースに対するアクセス制御を実施し、データベースに変更を加えるための技術が提供される。この技術は、「表示ジョブディスパッチャ」を提供することができ、これは、データベースから読み取り、（データ）ストリームからイベントを受信してデータベースに書き込む唯一のコンポーネントであってもよい。これは、イベントの連続的な処理を維持するために、タイムスタンプに基づいてリクエストをフィルタリングする責任を処理する。「表示ジョブディスパッチャ」は、ユーザの通信装置上のアプリに常駐する一連の命令によって定義されてもよい。

【0085】

「表示ジョブディスパッチャ」は、サーバからのジョブ／ブッキングストリームを監視してもよい。「表示ジョブディスパッチャ」は、ジョブストリームにおける何らかの状態の変化（例えば、新規ジョブ、ジョブステータスの変更など）を監視すると、データベースに問い合わせ、当該ジョブについてデータベースに記録／存在する可能性のある既存のステータスに基づいて、当該ジョブが有効であるかどうかを判断してもよい。また、ジョブに関連する詳細がデータベースで更新されてもよい。ジョブが有効であると判断された場合、「Ｄｂ－ドメインマッパー」が、データベースデータをＵＩモデルに変換し、対応するアプリを介して通信装置のＵＩ（ユーザインターフェース）上でユーザに表示してもよい。その後、表示ジョブのリストが、対応する垂直リポジトリ（ＡＰＩ）を介してＵＩに中継され、ユーザがジョブを見て、ジョブを受け入れるかどうかを決定してもよい。表示されるジョブのリストは、予約ストリームおよび／またはデータベースに更新があるたびに更新されてもよい。また、ユーザは、ユーザの通信装置上の対応するアプリのＵＩを介して更新情報を提供し、それがサーバに送信されてもよい。「表示ジョブディスパッチャ」は、その更新／変更を拾い上げ、データベースに問い合わせ／更新を行うことができる。このように、すべてのデータ、データベースへの変更などは、単一のコンポーネントである「表示ジョブディスパッチャ」を介してルーティングされる可能性がある。

【0086】

あるいは、同じく上述したように、「表示ジョブディスパッチャ」について上述したのと同じ機能、すなわち、予約ストリームを監視し、データベースを照会し、データベースを更新することを行う追加の「状態ロジック」を設けてもよい。このような手法では、「表示ジョブディスパッチャ」は、その後、データベースに変更がないかどうかを監視してもよく、さらに、「Ｄｂ－ドメインマッパー」からの出力を受信してもよく、対応する垂直デポジトリを通じて表示ジョブのリストを提供してもよい。この実装では、「表示ジョブディスパッチャ」は、データベースから読み取る唯一のコンポーネントであってもよい。さらに、データベースの更新は、「状態ロジック」に委ねられてもよい。

【0087】

本明細書で開示されている技術は、ライドヘイリングサービスで実装されてもよい。“表示ジョブディスパッチャ”は、サーバから予約ストリームを受信し、対応するアプリのドライバーのＵＩを介してドライバーにジョブを提示することができる。また、ドライバーは、ＵＩを介して更新情報を提供することができ（例えば、特定の目的地またはドロップオフポイントに到達したことなど）、その更新情報は、データベースを更新するためにサーバを介して「表示ジョブディスパッチャ」に送信されてもよい。

【0088】

本明細書で開示されている技術は、通信装置にインストールされた「アプリ」の助けを借りて、通信装置を使用して実施されてもよいことを理解すべきである。非限定的な例として、ジョブに関連するリクエストは、アプリを介して提供または送信されてもよい。アクティブなジョブは、アプリまたはアプリのＵＩを介して表示されてもよい。

【0089】

本発明は、例示のみによって説明されていることが理解されるであろう。添付の特許請求の範囲の精神と範囲から逸脱することなく、本明細書に記載された技術に様々な変更を加えることができる。開示された技術は、独立した方法で提供されてもよいし、互いに組み合わせて提供されてもよい技術からなる。したがって、ある技術に関して記載された特徴は、別の技術と組み合わせて提示することもできる。

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図3C】