Google 的導航和公交通信

Google 的導航和公交通信

我最近寫了一篇關於本地突出語義特徵的文章。 它專注於谷歌尋找改進導航服務的方法，這通常可以通過讓消費者更容易地找到、購物和使用企業服務來使商業受益。

與導航服務密切相關的是諸如穀歌之類的搜索引擎提供相關信息的交通服務。 至少從 2007 年起，我就一直在撰寫有關移動設備上的 Google 公交服務的文章。Google 地圖是一種有用的方式，可以使用 Google 的位置記錄導航到許多地方，以幫助我導航到這些地方。

當 Google 專利獲得授權時，這與 Google 應用程序以及導航和交通通信有關。 我覺得我需要學習更多並分享我學到的東西。

這項新專利涉及 Google Navigation 和 Transit 之間的應用程序間通信。

Google 的導航通信

今天，地理區域的數字地圖通過地圖應用程序、網絡瀏覽器顯示在計算機上，例如計算機、平板電腦和手機。 許多地圖應用程序為搜索者提供了選擇地圖信息或特徵類型以查看和調整數字地圖顯示的能力。

此外，地圖應用程序提供商提供應用程序編程接口 (API) 以訪問地圖和導航數據以顯示數字地圖並提供到目的地位置的逐步導航方向。 乘車服務應用程序可以調用地圖應用程序 API 來提供地理區域的數字地圖，其中包括：

• 用戶上車地點
• 目的地位置
• 前往目的地的導航路線
• 等等。

為了在地圖應用程序中提供乘車服務而不將用戶定向到單獨的乘車服務應用程序，地圖應用程序調用乘車服務 API 以訪問來自各種乘車服務提供商的乘車服務數據。 一個人可以在地圖應用程序中請求到目的地位置的導航方向。 然後，該用戶可以從多種交通模式中進行選擇，以前往目的地位置，包括乘車服務模式。

上車地點

當用戶選擇乘車服務模式時，地圖應用可以與乘車服務應用進行通信。 它可以調用相應的乘車服務 API。 地圖應用程序與乘車服務應用程序和乘車服務服務器通信以檢索乘車服務提供商的乘車服務類型。

乘車服務的類型可能包括：

• 拼車服務，拼車服務提供商在前往用戶目的地的途中接載更多乘客
• 在前往用戶目的地的途中不會接載更多乘客的出租車服務
• 包含更多車內功能的豪華轎車服務
• 大客群接送超大車服務
• 等等

地圖繪製應用程序還可以與乘車服務應用程序通信以：

• 檢索每種乘車服務的價格估算
• 監控每種乘車服務的等待時間
• 跟踪每種乘車服務的乘車時長
• 記錄有關行程狀態的乘車狀態信息（例如，等待司機接受乘車、等待司機到達上車地點、乘車進行中、乘車已完成）
• 在用戶當前位置周圍的地理區域內定位許多車輛
• 等等

在某些情況下，乘車服務應用程序不需要下載到用戶的客戶端設備。 相反，地圖應用程序調用相應的乘車服務 API 來與乘車服務服務器進行通信。

乘車服務提供商

然後，用戶可以從地圖應用程序中選擇乘車服務提供商和乘車服務類型，以訂購到她目的地位置的交通服務。 用戶可以從地圖應用程序內的幾個候選乘車服務提供商中進行選擇，而無需打開每個對應的乘車服務應用程序進行比較，也無需離開地圖繪製應用程序。

此外，用戶可以在具有內置地圖功能的應用程序中識別上車地點和目的地地點。 用戶可以查看上車地點周圍區域的三維街道視圖，以便用戶可以在上車地點找到司機。

地圖繪製應用程序還可基於用戶的上下文和位置提供關於上車位置的推薦。 他們還可以擁有從用戶當前位置到上車地點的步行路線。

目的地位置通訊

特別地，本公開的技術的示例實施例是在計算機中用於提供多模式行進方向的方法。 該方法包括經由用戶界面接收穫得到目的地的行進方向的請求並且生成用於行進到目的地的多模式行進方向。

生成多模式旅行方向包括從乘車服務的第三方提供者獲得乘車標誌以穿越上車地點和下車地點之間的路線的第一段，乘車服務定義第一運輸方式，並獲得導航方向以使用不同於第一運輸方式的第二運輸方式穿越路線的第二段。 該方法還包括通過用戶界面提供生成的多模式方向的標誌。

另一個示例實施例是一種計算機，包括用戶界面、一個或多個處理器以及在其上存儲指令的非暫時性計算機可讀介質。

前往目的地的導航路線

當由處理器執行時，指令使計算機接收穫取到目的地的行進方向的請求並生成用於行進到目的地的多模式行進方向。 為了生成多模式旅行方向，指令使計算機從乘車服務的第三方提供商處獲得乘車標誌，以穿越上車地點和下車地點之間的路線的第一段-關閉位置。

乘車服務將定義第一種運輸方式，並使用不同於第一種運輸方式的第二種運輸方式獲得導航方向以穿越路線的第二段。 這些指令還使計算機通過用戶界面對生成的多模式方向進行簽名。

又一示例是計算機中用於提供多模式行進方向的方法。 該方法包括通過用戶界面提供交互式數字地圖。 此外，接收請求以獲取前往目的地的行進路線。 以及從乘車服務的第三方提供商處獲得從上車地點到下車地點的乘車標誌以穿越路線的至少一部分。

該方法還包括從乘車服務的第三方提供商接收用於在數字地圖上呈現乘車的可視化的可視化信息。 以及通過接收到的可視化信息在數字地圖上生成乘車的可視化。

應用程序之間的導航和傳輸通信

這可以包括具有用戶界面、一個或多個處理器和非暫時性計算機可讀介質的計算機。

當處理器執行時，指令使計算機通過用戶界面提供交互式數字地圖。 它可以使他們通過用戶界面接收穫取前往目的地的行進路線的請求。 他們還可以從乘車服務的第三方提供商處獲得從上車地點到下車地點的乘車標誌，以至少穿越部分路線。

這些指令進一步使計算機從乘車服務的第三方提供商接收用於在數字地圖上呈現乘車的可視化的可視化信息。 然後可以通過接收到的可視化信息在數字地圖上生成乘車的可視化。

另一個實施例是在便攜式計算機中用於在數字地圖上提供乘車服務信息的方法。

該方法包括：

• 通過用戶界面提供地理區域的交互式數字地圖
• 通過用戶界面接收穫取前往目的地的旅行路線的請求
• 從多個第三方乘車服務提供商請求前往目的地的路線的至少一部分的候選乘車的相應指示，每個指示包括上車地點、價格估計和上車時間

導航和中轉通信方法還包括：

• 保持候選遊樂設施的請求指示
• 根據價格和上車時間中的至少一個確定候選乘車的排名
• 在數字地圖上按確定的排名提供候選遊樂設施列表
• 將所選行程的請求傳輸到相應的第三方提供商

又一示例是便攜式計算機中用於在計算機上提供與乘車服務相關的地圖數據的方法。 該方法包括：

• 通過用戶界面顯示交互式二維數字地圖
• 接收穫取前往目的地的旅行路線的請求
• 從乘車服務的第三方提供商處獲取從上車地點到下車地點的乘車標誌，以至少穿越部分路線
• 保留上車地點的街道圖像
• 將二維數字地圖轉換為街道級圖像的交互式三維全景顯示

在導航應用程序中提供與乘車服務相關的街道級圖像
發明人：Jon Ovrebo Dubielzyk 和 Scott Ogden
受讓人：GOOGLE LLC
美國專利：11,099,025
授予時間：2021 年 8 月 24 日
提交時間：2018 年 12 月 14 日

抽象的

通過用戶界面提供交互式二維數字地圖。 接收到獲取到目的地的旅行方向的請求。 從乘車服務的第三方供應商處獲得從上車地點到下車地點以穿越路線的至少一部分的乘車標誌。 獲取上車地點的街道級圖像並顯示在數字地圖上。 響應於通過用戶界面檢測到街道級圖像的選擇，二維數字地圖轉變為街道級圖像的交互式三維全景顯示。

導航和公交通信概述

一般而言，用於在地圖繪製應用程序內提供乘車服務的技術可以在便攜式計算機或可穿戴設備、一個或多個網絡服務器或包括這些設備的組合的系統中運行的地圖繪製應用程序中實現。 但是，為了清楚起見，下面的示例集中於用戶通過便攜式計算機內的地圖應用程序請求乘車服務的實施例。

地圖應用調用一個或多個乘車服務 API 來與相應的乘車服務應用程序和乘車服務服務器進行通信。 地圖應用程序還可以與地圖數據服務器和導航數據服務器通信以檢索地圖和導航數據，以顯示圍繞用戶當前位置的地理區域的交互式二維數字地圖和到目的地位置的導航方向（也稱為此處作為“下車地點”）由用戶選擇。

地圖應用然後可以顯示一個或多個乘車服務提供商的乘車服務數據，包括每個乘車服務提供商提供的乘車服務類型、每種乘車服務的價格估計、每種乘車服務的等待時間、乘車持續時間對於每種類型的乘車服務，用戶當前位置周圍地理區域內的車輛等。

當用戶選擇乘車服務提供商和乘車服務類型時，地圖繪製應用程序可以提示用戶選擇上車地點。 地圖繪製應用程序提供了一個靠近用戶當前位置的默認上車位置。 用戶可以通過用戶控件調整拾取位置。 此外，地圖繪製應用程序可以基於用戶的當前位置和上下文信息提供推薦的上車位置。

在有多條單向街道的區域，地圖應用程序可能會在一條街道上推荐一個上車位置，讓司機可以沿著目的地位置的方向行駛，這樣司機在上車後就不需要做不必要的轉彎了。用戶。 在另一個例子中，推薦的上車地點可以基於交通來確定以避免交通繁忙的街道以降低成本。

響應於選擇上車地點，地圖應用可以調用與所選乘車服務提供商對應的乘車服務 API，並為用戶提供乘車人識別信息、請求的上車地點以及相應的乘車服務類型。乘車服務應用程序。 然後，乘車服務應用程序可以提供乘車標識符、更新的等待時間、更新的價格估計、更新的乘車持續時間和駕駛員標識信息以通過乘車服務API顯示在地圖應用程序上。 結果，司機可以在所請求的上車地點上車並在目的地地點下車。

用於導航和交通通信的一些示例硬件和軟件組件

導航和交通通信對於該系統的正常運行至關重要。 正因為如此。 仔細看看這個系統中涉及的許多部分是有幫助的。

這一獲得專利的過程包括一個便攜式設備，該設備被配置為執行一個或多個乘車服務應用程序和一個地圖應用程序。 除了客戶端計算機之外，通信系統還包括服務器設備，例如配置為向客戶端計算機提供地圖顯示和導航數據的導航服務器設備。

該通信系統還包括第三方提供商設備。 它獨立於服務器設備運行。 它還可以被配置為與客戶端計算機和服務器設備通信以提供乘車服務功能。 客戶端計算機、服務器設備和第三方提供商設備可以通過網絡通信連接。 該網絡可以成為公共網絡，例如 Internet，或專用網絡，例如內部網。

服務器設備可以耦合到存儲各種地理區域的地圖數據的數據庫。 服務器設備可以耦合到數據庫，該數據庫存儲與客戶端計算機的用戶相關聯的各種車輛、與第三方提供商相關聯的車輛、其數據由服務器設備收集的其他車輛、或其他服務器或組合的車輛數據所有三個。

與存儲地理空間信息的數據庫通信，這些信息有助於導航和交通通信

更一般地，服務器設備可以與一個或多個數據庫通信，這些數據庫存儲任何類型的合適的地理空間信息或可以鏈接到地理上下文的信息，例如優惠券或優惠。 服務器設備還可以耦合到存儲導航數據的數據庫（未示出），包括逐步導航方向，例如駕駛、步行、騎自行車或公共交通。

這些可能會被乘車服務應用程序、地圖應用程序或兩者同時使用。 服務器設備可以請求和接收來自地圖數據數據庫的地圖數據和來自車輛數據數據庫的相關車輛數據。 服務器設備可以包括多個連接的服務器設備。 存儲在數據庫中的地圖和車輛數據可以成為連接在雲數據庫配置中的多個數據庫。

客戶端計算機可以是智能手機或平板計算機，並且包括存儲器、一個或多個處理器、網絡接口、用戶界面（UI）和一個或多個傳感器。 內存可以變成非暫態內存，包括一個或幾個合適的內存模塊，例如隨機存取內存（RAM）、只讀內存（ROM）、閃存、其他類型的持久內存等。 UI 可以變成觸摸屏。 更一般地，所公開的技術可以在其他設備中實現，例如膝上型計算機或台式計算機，嵌入車輛中，例如車載主機、可穿戴設備、智能手錶或智能眼鏡等。

根據實施方式，傳感器可以包括用於檢測客戶端計算機位置的全球定位系統 (GPS) 模塊、用於確定客戶端計算機方向的指南針、用於確定旋轉和傾斜的陀螺儀、加速度計等。

這個通訊系統背後的記憶

內存存儲操作系統 (OS) – 任何類型的合適的移動或通用操作系統。 操作系統可以包括允許諸如乘車服務和地圖應用程序之類的應用程序的 API 功能。 這些可以相互連接。 他們還可以檢索傳感器讀數。 被配置為在客戶端計算機上執行的軟件應用程序可以包括調用OS API以在該時刻檢索客戶端計算機的當前位置和方向的指令。 API 還可以返回 API 對估計值的確定程度的定量符號（例如，作為百分比）。

內存還存儲地圖應用程序，該應用程序被配置為生成交互式數字地圖。 地圖繪製應用程序可以從地圖數據數據庫和服務器設備接收光柵（例如位圖）或非光柵（例如矢量圖形）格式的地圖數據。 在某些情況下，地圖數據可以組織成多個圖層，例如描繪道路、街道、自然地貌等的基本圖層，描繪當前交通狀況的交通圖層，描繪當前天氣狀況的天氣圖層，描繪當前天氣狀況的導航圖層。到達目的地的路徑等。地圖繪製應用程序還可以顯示從起始位置到目的地位置的導航方向。 導航方向可包括駕車、步行或公共交通方向。

導航和公交通信背後的測繪應用

地圖繪製應用程序是一個獨立的應用程序。 地圖應用程序的功能也可以通過在客戶端計算機上執行的網絡瀏覽器訪問的在線服務的形式提供，作為在客戶端計算機上執行的另一個軟件應用程序的插件或擴展等。地圖應用程序通常可以為不同的操作系統提供不同的版本。 客戶端電腦的製造商可以提供軟件開發工具包（SDK），包括Android平台的地圖應用程序，iOS平台的另一個SDK等。

服務器設備包括一個或多個處理器、API、網絡接口和存儲器。 API可以提供用於與可以存儲在服務器設備上的存儲器136中的應用程序接口的功能。 記憶是有形的或非暫時性的記憶。 它可以包括任何類型的合適的存儲器模塊，包括隨機存取存儲器 (RAM)、只讀存儲器 (ROM)、閃存、其他類型的持久性存儲器等。存儲器存儲指令可在處理器上執行，生成地圖顯示由地理區域的地圖應用程序顯示。

類似地，存儲器或另一服務器中的存儲器可以存儲生成到地理區域內的地理位置的導航方向的指令，並且可以由地圖繪製應用程序覆蓋地圖顯示進行顯示。 在一些實現方式中，第三方提供者可以開始調用服務器設備以獲得可以由客戶端計算機上的乘車服務應用程序使用的導航方向。

導航和交通通信背後的服務器設備

為簡單起見，圖中僅將服務器設備顯示為服務器的一個實例。 但是，服務器設備可以包括一組一個或多個服務器設備，每個服務器設備配備一個或多個處理器並且能夠獨立於其他服務器設備運行。

在這樣的組中操作的服務器設備可以以分佈式方式單獨處理來自客戶端計算機的請求（例如，基於可用性），其中在一個服務器設備上執行與處理請求相關聯的一個操作。 相反，與處理相同請求相關聯的另一操作變為在另一服務器設備上或根據任何合適的技術執行。 對於該討論，術語“服務器設備”可以指單獨的服務器設備或兩個或更多服務器設備的組。

導航和公交通信背後的第三方提供商設備

第三方提供商設備或乘車服務提供商設備可以包括處理器、API、網絡接口和存儲器。 API 可以提供與應用程序接口的功能，這些應用程序可以存儲在第三方提供商的存儲器中。 存儲器可以包括任何類型的合適的存儲器模塊，包括隨機存取存儲器（RAM）、只讀存儲器（ROM）、閃存、其他類型的持久性存儲器等。

存儲器存儲可在處理器上執行的指令，這些指令可以生成、處理和發送對乘車服務應用程序中乘車服務功能的請求，例如存儲在客戶端計算機的存儲器中的乘車服務應用程序。

該系統包括對應於多個不同乘車服務提供商的多個第三方提供商設備。 此外，在某些情況下，客戶端計算機包括對應於每個乘車服務提供商的多個乘車服務應用程序。

通過這種方式，用戶可以比較：

• 乘車服務類型
• 價格估計
• 騎行時長
• 幾家乘車服務提供商的預計等待時間

具有通信協議的客戶端計算機上的軟件體系結構

導航和過境通信可能存在於：

• 操作系統
• 乘車服務應用
• 地圖應用
• 客戶端計算機上的服務
• 以及其他應用程序

乘車服務應用程序公開一個乘車服務 API，地圖應用程序會調用該 API。 地圖應用程序可以允許用戶在不離開地圖應用程序的情況下請求乘車服務。 該地圖應用程序可以提供：

• 乘車服務 API 的接送地點和目的地位置
• 提供地理區域內的乘車服務類型
• 每種乘車服務的價格估算
• 每種乘車服務的等待時間
• 每種乘車服務的乘車時長
• 地理區域內的許多車輛
• 等等

通常，地圖應用程序可以通過訪問乘車服務API對乘車服務應用程序或乘車服務服務器進行函數調用。 API 促進了應用程序間的通信。 它還允許地圖和乘車服務應用程序保持對流程、邏輯和用戶的處理方式的控制。 它還向其他應用程序公開功能。

應用程序可以使用操作系統提供的進程間通信 (IPC) 方案進行通信。 在客戶端計算機中，乘車服務應用程序的功能可以作為可通過乘車服務 API 訪問的靜態函數庫提供。 乘車服務應用程序的一些或所有功能可以作為地圖應用程序的一部分執行。

更一般地，乘車服務API使用任何合適的軟件架構和通信方案，包括本領域當前已知的那些，向地圖應用程序提供對乘車服務的訪問。 乘車服務API通常可以針對不同的操作系統提供不同的版本。 客戶端計算機的製造商可以提供一個軟件開發工具包（SDK），包括Android平台的乘車服務API，另一個iOS平台的SDK等。

在某些情況下，地圖繪製應用程序可以通過相應的 API 與多個乘車服務應用程序進行通信。 如果用戶沒有與地圖應用程序通信的乘車服務應用程序，則可能會提示用戶下載乘車服務應用程序。

用戶不下載乘車服務應用程序。 地圖繪製應用程序可以通過乘車服務 API 與乘車服務服務器（例如第三方提供商設備）進行通信。

地圖應用程序和使用 API 的乘車服務應用程序之間調用的序列圖

序列圖說明了導航和傳輸通信的一種實現的示例消息序列圖。 此導航和交通通信圖可以包括：

• 一個用戶
• 地圖應用程序
• 乘車服務應用程序
• 乘車服務 API

在示例序列圖中，用戶通過地圖應用程序呈現的顯示器上的用戶控件請求乘車服務。 用戶可以請求前往所選目的地位置的路線，以用於乘車服務運輸模式。 地圖應用可以響應於該請求向乘車服務應用程序API生成乘車服務的API調用。 API 調用包括對乘車服務的請求、用戶的當前位置和目的地位置。

API 調用然後作為請求發送到乘車服務應用程序或乘車服務服務器，例如第三方提供商設備。

乘車服務應用程序可以執行其自己的內部功能來確定：

• 可為用戶提供服務的乘車服務類型
• 將用戶運送到目的地的價格估算
• 接機用戶的等待時間
• 圍繞用戶當前位置的地理區域內的許多車輛
• 等等

作為導航和交通通信的一部分，乘車服務應用程序然後準備響應以發送到地圖應用程序：

• 可用的乘車服務類型
• 通過每種類型的乘車服務預計乘車到達的時間
• 每種乘車服務的估計價格
• 對該地區車輛/司機的估計
• 它們的組合

響應由乘車服務 API 接收，然後格式化並提供給地圖應用程序。 如果需要向用戶顯示，它會被處理和操縱。

可能會向系統用戶顯示導航和傳輸通信的內容

地圖繪製應用程序可以顯示每種可用乘車服務的指示。 這些服務可以包括：

• 拼車服務
• 出租車乘車服務
• 豪華轎車接送服務
• 超大車輛服務

來自導航和過境通信的其他信息可能包括：

• 每種乘車服務的價格估算
• 每種乘車服務的乘車時長
• 每種乘車服務的預計等待時間

如乘車服務API所指示的，地圖應用還可以與地理區域內的車輛數量成比例地在地圖顯示器上顯示車輛的指示。 雖然地圖顯示上的車輛位置可能無法準確表示乘車服務提供商所使用的車輛，但地圖顯示上的車輛數量可能會習慣於向用戶顯示該區域中車輛數量的近似值。區域。

當有許多乘車服務提供商可用時，地圖繪製應用程序可以以不同的樣式或顏色顯示每個乘車服務提供商使用的車輛。

系統用戶對導航和交通通信信息的請求

可用的乘車服務類型的顯示指示可能包括：

• 用於選擇乘車服務類型的可選用戶控件。 用戶查看顯示的指示並選擇一種乘車服務
• 用於選擇取車位置的用戶控件（放置在用戶當前位置或用戶當前位置附近的圖釘，用戶可以通過輸入地址或興趣點將圖釘移動到另一個位置
• 將圖釘移動到另一個位置

然後將所選類型的乘車服務提供給乘車服務 API 並轉發到乘車服務應用程序。

乘車服務應用程序然後選擇要接載的司機和用戶。 它傳輸所選駕駛員的駕駛員身份信息（例如，駕駛員姓名、車輛品牌、型號和顏色、車牌號等）、更新的價格估計、更新的等待時間、乘車 ID向乘車服務 API 檢索指示駕駛員正在接載用戶等的狀態信息，然後將其格式化並提供給地圖應用程序。

地圖繪製應用程序可以向用戶呈現駕駛員狀態的標誌（例如，在接用戶的路上）、更新的價格估計、更新的等待時間和駕駛員標識信息。

在地圖應用程序內的乘車服務請求期間在用戶界面之間轉換

這些信息讓我想起了我在 Uber 和 Lyft 的建立過程中所看到的。 一項專注於導航和交通通信信息的專利將涵蓋這些內容是有道理的。

該方法可以通過地圖應用程序、乘車服務或任何合適的組合來實現。

顯示用戶當前位置周圍的地理區域

如果您為某人提供導航和交通通信信息，則顯示他們所在區域附近的信息是有意義的。

這是這個系統中的內容：

地圖顯示被呈現，其中包括圍繞用戶當前位置的地理區域。

用戶當前位置的標誌也可以呈現在地圖顯示器上。

然後，地圖應用呈現用於從用戶獲得地理搜索查詢並響應於地理搜索查詢提供搜索結果的搜索欄。

搜索結果可以包括POI、地址、路口等。用戶可以選擇搜索結果之一作為目的地位置並且請求到所選擇的目的地位置的方向。

選擇不同的運輸方式

地圖繪製應用程序還可包括用於在多種交通模式之間進行選擇的用戶控件，包括乘車服務交通模式。 它還提供有關附近位置和那些不同類型服務的導航和交通通信信息。

響應於接收到對乘車服務運輸模式的選擇，地圖繪製應用程序可以呈現乘車請求顯示，包括：

• 乘車服務提供商的適應症
• 乘車服務提供商提供的乘車服務類型
• 每種乘車服務的價格估算
• 每種乘車服務的乘車時長
• 每種乘車服務的等待時間
• 等等

The mapping application may invoke a ride service API for each of one or several ride service applications. It may provide the user's current location and destination location to each ride service application via the respective APIs.

The Pick Up Request in the Navigation and Transit Communication System

In response to receiving a selection of a ride service provider and type of ride service, the mapping application may present a pick-up request display that includes a user control for selecting a pick-up location. The pick-up request display may include a default pick-up location within a threshold distance of the user's current location (eg, 500 feet), where the user adjusts the pick-up location.

The user may enter the pick-up location or drag a pin presented at the default pick-up location to select the pick-up location. The mapping application may provide a recommended pick-up location to save time and money. The recommended pick-up location is 350 feet from the user's current location. The pick-up request display may state that the user can “Save 3 mins and $2” by selecting the recommended pick-up location. The pick-up request display may also include a user control for confirming the pick-up location, such as a “Confirm Pick-up” button after selecting the pick-up location.

In response to selecting a pick-up location, the mapping application may present a wait for ride display. The wait for ride display may include a sign of the driver's current location, identification information for the driver, an estimated wait time for the driver to arrive at the selected pick-up location, and user control for contacting the driver.

Once the driver arrives, the user may get transported to the destination location.

When the user requests ride services within the mapping application, the mapping application provides user login information to a ride service provider to log in to a user profile maintained by the ride service provider.

The user profile may include:

• Payment methods for the user
• The name of the user
• An email address of the user
• A phone number of the user
• A picture of the user for the driver to identify the user
• A rating of the user
• A ride ID for a ride currently in progress or ride the user is requesting
• Any other suitable user profile information

Once the user confirms a ride request, the mapping application may receive a ride ID for retrieving status information for the ride, such as “Waiting for the driver to accept the ride request,” “Waiting for the driver to arrive at the pick-up location,” “Ride in progress,” and “Ride completed.”

Requesting Ride Services Via The Mapping Application By Invoking The Ride Service API

In the past, Google has provided both Navigation services and has provided navigation and transit communication information. This patent tells us that it may include third-party information from ride-sharing providers. But it feels like it may provide those ride-sharing services or finding a way to make some money from providing information about those ride-sharing services.

The patent includes a state diagram that depicts several states, such as an initial state, a sign-in state, a confirm/book state, a restored state, a ride-in-progress state, and a transition state. At any moment, any of the states may return to the initial state as denoted in the state diagram. It depicts this ride-sharing approach in a great amount of detail.

The Initial Ride Sharing State in the Navigation and Transit Communication System

A user may open a mapping application and begins in the initial state. In the initial state, the mapping application presents a map display of a geographic area. It may receive geographic search queries, provide search results in response to the geographic search queries, and display navigation or travel directions from the user's current location or some other specified starting location to a selected destination location.

The navigation or travel directions are provided for several different modes of transportation (eg, walking, biking, driving, public transit, ride services, a recommended mode of transportation that may include multiple modes of transportation for arriving at the destination location based on the shortest duration, distance, or lowest cost, etc.).

When the user selects a ride services mode of transportation or selects multi-modal travel directions that include a segment covered by a ride service and selects a ride service provider/type of ride service, the mapping application proceeds to the sign-in state.

A Sign-In State For this Navigation and Transit Communication System

In the sign-in state, the mapping application determines whether the user gets signed into a client account associated with a provider of the mapping application.

If the user is not signed in, the mapping application may provide user controls for entering user login information, such as a username and password, to sign in to the client account when the user signs in, the mapping application signs the user into a user profile associated with the third-party provider that provides the ride service.

The Confirm/Book State of the Navigation and Transit Communication Information System

The user may sign in to the third-party provider using the client account associated with the provider of the mapping application. When the user gets signed into the third-party provider, the mapping application invokes the ride service API to retrieve a ride ID associated with the user profile to determine whether a ride is currently in progress. Suppose there are a ride currently in progress, the mapping application transitions to the restored state. If there is no ride ID, the mapping application proceeds to the confirm/book state.

In the confirm/book state and, more specifically, the confirm state, the mapping application presents a pick-up request display that includes a user control for selecting a pick-up location, like the display. The pick-up request display may also include user controls for selecting or adding payment methods.

The mapping application may retrieve payment methods for the user stored with the ride service provider via the ride service API. The mapping application may display masked indications of each payment method for the user to choose from and display more user control to enter a new payment method.

A Pick Up Request in the Navigation and Transit Communication System

When the user has selected a pick-up location and payment method, the mapping application may present a user control such as a “Confirm Pick-up” button, which transitions the mapping application to the booking state.

Booking in the Navigation and Transit Communication System

In the booking state, the mapping application requests ride services from the ride service provider from the pick-up location to the destination location via the ride service API. The ride service API then communicates with the ride service provider to select a driver for the ride. The ride service provider may broadcast a message to each driver within a threshold distance of the pick-up location and select the first driver to respond to the broadcasted message.

In any event, the ride service API may then provide a ride ID to the mapping application, and the mapping application proceeds to the ride in progress state. In the ride-in-progress state, the mapping application continuously or periodically (eg, every 5-10 seconds) calls a get ride status function to receive status information about the ride's status by providing the ride ID to the ride service API.

The ride service API may provide status information to the mapping application. The status information may include: waiting for the driver to accept the ride, waiting for the driver to arrive at the pick-up location, ride in progress, and ride completed.

waiting for The Driver To Arrive

While waiting for the driver to arrive at the pick-up location and ride in progress states, the ride service API may also return the driver's current location for display via the mapping application. The mapping application may present a sign of the driver on the map display along with the pick-up location or destination location for the user to view the driver's progress to the pick-up location or on the route to the destination location.

Additionally, while waiting for the driver to accept the ride, waiting for the driver to arrive at the pick-up location, and ride in progress states, the mapping application may present a user control for canceling the ride. When that gets selected, it may cause the mapping application to provide a cancel request to the ride service provider via the ride service API to cancel the ride.

This mapping application may also present a user control for modifying the destination location, which, when selected, may cause the mapping application to provide a change destination request to the ride service provider via the ride service API.

Dropping the User Off at a Destination

Once the user gets dropped off at the destination location, the mapping application proceeds to the completed state. In the completed state, the mapping application may present:

• A summary of the ride including a final price of the ride
• A user control for rating the driver
• Any other suitable information about the rate

Then the mapping application may return to the initial state.

Returning to the Restored State

As mentioned above, the mapping application transitions to the restored state when the user signs into the third-party provider, and there is a ride currently in progress. The user may have exited the mapping application and then reopened it while requesting a ride. In the restored state, the mapping application proceeds to the ride in progress state and or under every 5-10 seconds, get ride status information about the ride's status.

Besides providing ride services, the mapping application provides multi-modal modes of transportation for navigating a user to her destination location. The user may select a recommended mode of transportation that may include many modes of transportation for providing an optimal route to the destination location based on the shortest duration, distance, lowest cost, etc.

The user may provide preferences, such as “Avoid highways,” “Use public transit,” “Avoid walking directions at night,” “Lowest cost,” “Shortest duration,” may state:

• A preferred mode of transportation
• A preferred ride service provider
• A preferred ride service type, such as a carpooling ride service
• Any other suitable preferences

The mapping application may present one or several optimal routes to the destination location using one or several modes of transportation and according to the user's preferences.

This mapping application provides a request for navigation directions using a recommended mode of transportation to the server device. These can include a starting location, a destination location, and user data, including the user's preferences.

The server may retrieve map data, navigation data, traffic data, etc., to generate routes from start to destination.

The server device may invoke ride service APIs to retrieve ride service data for ride service providers. These could be estimated wait times and price estimates for particular route segments. An optimal route may include a ride service to and from a public transit stop.

The server device may generate a recommended multi-modal route that includes a first public transit stop one mile from the user's starting location and a second one mile from the user's destination location. The recommended multi-modal route may include a ride service from the starting location to the first public transit stop and another ride service from the second public transit stop to the destination location. The recommended multi-modal route may include walking directions from the starting location to the first public transit stop or from the second public transit stop to the destination location.

The server device may identify a ride service provider and ride service type that minimizes cost and wait time by communicating with the ride service providers. When the user indicates a preferred ride service provider or ride type, the server device may retrieve ride service data from the preferred ride service provider.

They can include the preferred ride service provider in the route. The server device may generate one or several recommended multi-modal routes and provide the recommended routes to the mapping application to select and navigate to the destination location.

Other Aspects of the Navigation and Transit Communication System

This system may allow identified routes that include a particular ride service provider and ride service type.

Some ride service providers may include a shuttle ride service type. A route may include taking a train to a stop near a shuttle pick-up location and then taking the ride service from the shuttle pick-up location to a shuttle stop walking distance from the destination location. The user may save time and reduce costs when the shuttle pick-up location is timed with the train stop.

Each of the identified routes gets ranked or scored according to an optimization technique in such a decision. The identified routes may become ranked or scored according to several factors, such as distance, duration, cost, user data, including user preferences.

Ranking Identified Routes to Cut Travel Time

The identified routes may get ranked to cut the time of travel to the destination location. In another example, the identified routes may get ranked to cut the travel price to the destination location.

Each identified route may receive a distance score, a duration score, a cost score, a user preferences score, or any other suitable score. The scores may get weighted, aggregated, or combined in any suitable manner to generate a score for each route.

The routes may then get ranked according to their respective scores to cut cost, time, and distance. Toutes that do not meet the user preferences may get filtered out or receive a score of zero. The recommended routes and the ride service provider/type may become ranked/selected because of user data.

If the user indicates he would not like to walk at night, any routes that include a walking segment after a threshold time may become filtered out or ranked at the bottom. The cost may get determined by using a particular public transit system or ride service provider and ride service type.

The server device may invoke one or several ride-sharing APIs to determine price estimates for using a particular ride service provider and ride service type for a segment of a route.

Besides ranking the identified routes, the server device may rank candidate rides, where each candidate ride corresponds to a particular ride service provider and ride service type.

The candidate rides may become ranked or scored according to factors such as distance, duration, cost, user data, including user preferences.

The candidate rides may get ranked to cut the wait time for the driver to arrive at the pick-up location.

The candidate rides may get ranked to cut the travel price to the destination location. The server device may rank the candidate rides according to wait time, price, or any other suitable category.

The candidate rides may also get ranked according to user feedback data for the ride service providers. The user feedback data may include data show past ratings or reviews of the ride service providers by riders.

The server device provides routes or a listing of rides ranked above a threshold ranking. Such as the top three highest-ranking routes. Those could become recommended routes or rides to the mapping application for the user to choose from.

導航和交通通信結論

我切斷了專利的結尾，該專利討論了不同的運輸類型如何組合。 專利中沒有任何內容表明谷歌將提供任何交通服務； 然而，提供有關這些服務的信息以及將它們組合起來的不同方式可能會很有用。

優步和 Lyft 等拼車服務已成為顛覆性的出行方式。 我們看到無人駕駛汽車和 Waymo 等公司可以進入該市場。 許多人乘坐巴士。 火車、地鐵和出租車。 谷歌探索這個導航和交通空間是有意義的。 他們可能已經查看了比該專利中存在的內容更多的內容。
.