Navigation and Transit Communication at Google

Navigation and Transit Communication at Google

I recently wrote a post about Locally Prominent Semantic Features. It focused on Google finding ways to improve the navigation services, which can often benefit commerce by making it easier for consumers to find and shop at and use services at businesses.

Related Content:

• Technical SEO Agency
• Ecommerce SEO Agency
• Shopify SEO Services
• Franchise SEO Agency
• Enterprise SEO Services

Closely related to navigation services are transportation services that a search engine such as Google provides information about. I have been writing about Google Transit services on mobile devices since at least 2007. Google Maps is a useful way to navigate to many places using Google’s Location History to help me navigate to those places.

When a Google patent gets granted, that is about Google Applications and Navigation and Transit Communication. I felt I needed to learn more and share what I learned.

This new patent relates to inter-application communications between Navigation and Transit at Google.

Navigation Communication At Google

Today, digital maps of geographic areas get displayed on computers, such as computers, tablets, and mobile phones via mapping applications, web browsers. Many mapping applications provide a searcher with the ability to select the type of map information or features for viewing and adjust the display of a digital map.

Additionally, mapping application providers offer application programming interfaces (APIs) for accessing map and navigation data to display digital maps and provide step-by-step navigation directions to a destination location. A ride service application may invoke a mapping application API to provide a digital map of a geographic area that includes:

• A pick-up location for the user
• A destination location
• Navigation directions for traveling to the destination location
• Etc.

To provide ride services within a mapping application without directing the user to a separate ride service application, the mapping application invokes ride service APIs to access ride service data from various ride service providers. A person may request navigation directions within the mapping application to a destination location. That user may then select from several modes of transportation for traveling to the destination location, including a ride service mode.

Pick-Up Locations

When the user selects the ride service mode, the mapping application may communicate with ride service applications. It may invoke respective ride service APIs. The map application communicates with the ride service applications and rides service servers to retrieve ride service providers’ types of ride services.

Types of ride services may include:

• A carpooling ride service, where the ride service providers pick up more passengers on the way to the user’s destination
• A taxi service that does not pick up more passengers on the way to the user’s destination
• A limo service that includes more features within the vehicle
• Extra-large vehicle service for picking up large groups of passengers
• Etc

The mapping application may also communicate with the ride service applications to:

• Retrieve price estimates for each type of ride service
• Monitor wait times for each type of ride service
• Track ride duration for each type of ride service
• Record ride status information about the status of the trip (e.g., waiting for the driver to accept the ride, waiting for the driver to arrive at the pick-up location, ride in progress, ride completed)
• Locate many vehicles within a geographic area surrounding the user’s current location
• Etc

In some scenarios, ride service applications do not need to get downloaded to the user’s client device. Instead, the mapping application invokes the respective ride service APIs to communicate with ride service servers.

Ride Service Providers

The user may then select a ride service provider and type of ride service from the mapping application to order transportation services to her destination location. A user may select from several candidate ride service providers within the mapping application without opening each of the corresponding ride service applications for comparison and without leaving the mapping application.

Moreover, a user may identify pick-up locations and destination locations in an application with built-in map functionality. The user may view a three-dimensional street-level view of the area around the pick-up location so that the user may find the driver at the pick-up location.

The mapping application may also provide recommendations on pick-up locations based on the context and location of the user. They can also have walking directions from the user’s current location to the pick-up location.

Destination Location Communication

In particular, an example embodiment of the techniques of the present disclosure is a method in a computer for providing multi-modal travel directions. The method includes receiving, via a user interface, a request to get travel directions to a destination and generating multi-modal travel directions for traveling to the destination.

Generating the multi-modal travel directions includes obtaining, from a third-party provider of a ride service, a sign of a ride to traverse a first segment of the route between a pick-up location and a drop-off location, the ride service defining the first mode of transport, and obtaining navigation directions to traverse a second segment of the route using a second mode of transport different from the first mode. The method further includes providing a sign of the generated multi-modal directions via the user interface.

Another example embodiment is a computer including a user interface, one or more processors, and a non-transitory computer-readable medium storing instructions thereon.

Navigation Directions for Traveling to The Destination Location

When executed by the processors, the instructions cause the computer to receive a request to obtain travel directions to a destination and generate multi-modal travel directions for traveling to the destination. To generate the multi-modal travel directions, the instructions cause the computer to get, from a third-party provider of a ride service, a sign of a ride to traverse a first segment of the route between a pick-up location and a drop-off location.

The ride service would define the first mode of transport and get navigation directions to traverse a second segment of the route using a second mode of transport different from the first mode. The instructions further cause the computer to sign the generated multi-modal directions via the user interface.

Yet another example is a method in a computer for providing multi-modal travel directions. The method includes providing an interactive digital map via a user interface. Also, receiving a request to get travel directions to a destination. As well as obtaining, from a third-party provider of a ride service, a sign of a ride from a pick-up location to a drop-off location to traverse at least a part of the route.

The method further includes receiving, from the third-party provider of the ride service, visualization information for rendering a visualization of the ride on the digital map. As well as generating the visualization of the ride on the digital map by the received visualization information.

Navigation and Transit Communication Between Applications

This can include a computer including a user interface, one or more processors, and a non-transitory computer-readable medium.

When the processors execute, the instructions cause the computer to provide an interactive digital map via a user interface. It can cause them to receive, via the user interface, a request to get travel directions to a destination. They can also get, from a third-party provider of a ride service, a sign of a ride from a pick-up location to a drop-off location to traverse at least a part of the route.

These instructions further cause the computer to receive, from the third-party provider of the ride service, visualization information for rendering a visualization of the ride on the digital map. Then can then generate the visualization of the ride on the digital map by the received visualization information.

Another embodiment is a method in a portable computer for providing ride service information on a digital map.

This method includes:

• Providing, via a user interface, an interactive digital map of a geographic area
• Receiving, via the user interface, a request to get travel directions to a destination
• Requesting from a plurality of third-party providers of ride services, respective indications of candidate rides for at least a part of a route to the destination, each of the indications including a pick-up location, a price estimate, and pick-up time

The Navigation and Transit Communication Method Further Includes:

• Maintaining the requested indications of the candidate rides
• Determining a ranking of the candidate rides according to at least one of price and pick-up time
• Providing, on the digital map, a listing of the candidate rides by the determined ranking
• Transmitting a request for the selected ride to the corresponding third-party provider

Yet another example is a method in a portable computer for providing map data related to a ride service on a computer. This method includes:

• Displaying an interactive two-dimensional digital map via a user interface
• Receiving a request to get travel directions to a destination
• Obtaining from a third-party provider of a ride service a sign of a ride from a pick-up location to a drop-off location to traverse at least a part of the route
• Keeping street-level imagery for the pick-up location
• Transitioning the two-dimensional digital map to an interactive three-dimensional panoramic display of street-level imagery

Providing street-level imagery related to a ride service in a navigation application
Inventors: Jon Ovrebo Dubielzyk and Scott Ogden
Assignee: GOOGLE LLC
US Patent: 11,099,025
Granted: August 24, 2021
Filed: December 14, 2018

Abstract

An interactive two-dimensional digital map gets provided via a user interface. A request to get travel directions to a destination becomes received. A sign of a ride from a pick-up location to a drop-off location to traverse at least a part of the route becomes obtained from a third-party provider of ride service. Street-level imagery for the pick-up location gets obtained and displayed on the digital map. In response to detecting a selection of the street-level imagery via the user interface, the two-dimensional digital map gets transitioned to an interactive three-dimensional panoramic display of street-level imagery.

Navigation and Transit Communication Overview

Generally speaking, techniques for providing ride services within a mapping application can get implemented in a mapping application operating in a portable computer or a wearable device, one or several network servers, or a system that includes a combination of these devices. But, for clarity, the examples below focus on an embodiment in which a user requests ride services via a mapping application within a portable computer.

The mapping application invokes one or several ride service APIs to communicate with respective ride service applications and ride service servers. The mapping application may also communicate with a map data server and a navigation data server to retrieve map and navigation data for displaying an interactive two-dimensional digital map of a geographic area surrounding the user’s current location and navigation directions to a destination location (also referred to herein as a “drop-off location”) selected by the user.

The mapping application may then display ride service data for one or several ride service providers, including the types of ride services offered by each ride service provider, price estimates for each type of ride service, wait times for each type of ride service, ride duration for each type of ride service, vehicles within a geographic area surrounding the user’s current location, etc.

When the user selects a ride service provider and type of ride service, the mapping application may prompt the user to select a pick-up location. The mapping application provides a default pick-up location near the user’s current location. The user may adjust the pick-up location via user controls. Also, the mapping application may provide a recommended pick-up location based on the user’s current location and context information.

In an area with several one-way streets, the mapping application may recommend a pick-up location at a street that allows drivers to travel in the direction of the destination location so that the driver does not need to make unnecessary turns after picking up the user. In another example, the recommended pick-up location may get determined based on traffic to avoid streets with heavy traffic to cut costs.

In response to selecting the pick-up location, the mapping application may invoke a ride service API corresponding to the selected ride service provider and provide rider identification information for the user, the requested pick-up location, and the type of ride service the corresponding ride service application. The ride service application may then provide a ride identifier, an updated wait time, updated price estimate, updated ride duration, and driver identification information for display on the mapping application via the ride service API. As a result, a driver may pick up the user at the requested pick-up location and drop the user off at the destination location.

Some Example Hardware and Software Components For Navigation and Transit Communication

Navigation and Transit Communication are essential for the operation of this system to work correctly. Because of that. It is helpful to take a good look at the many parts involved in this system.

This patented process includes a portable device configured to execute one or several ride service applications and a mapping application. Besides the client computer, the communication system includes a server device, such as a navigation server device configured to provide a map display and navigation data to the client computer.

The communication system also includes a third-party provider device. It operates independently and separately from the server device. It may also become configured to communicate with the client computer and the server device to provide ride service functionality. The client computer, the server device, and the third-party provider device may get communicatively connected through a network. The network may become a public network, such as the Internet, or a private network, such as an intranet.

The server device can get coupled to a database that stores map data for various geographic areas. The server device can get coupled to a database that stores vehicle data for various vehicles associated with a user of the client computer, vehicles associated with the third-party provider, other vehicles whose data gets collected by the server device, or other servers or combinations of all three.

Communication with Databases That Store Geospatial Information That Assist with Navigation and Transit Communication

More generally, the server device can communicate with one or several databases that store any type of suitable geospatial information or information that can get linked to a geographic context, such as coupons or offers. The server device can also get coupled to a database (not shown) that stores navigation data, including step-by-step navigation directions such as driving, walking, biking, or public transit.

These may get utilized by both the ride service application, the mapping application, or both. The server device may request and receive map data from the map data database and relevant vehicle data from the vehicle data database. The server device may include several connected server devices. The map and vehicle data stored in the databases may become several databases connected in a cloud database configuration.

The client computer could be a smartphone or a tablet computer and includes a memory, one or more processors, a network interface, a user interface (UI), and one or several sensors. The memory can become a non-transitory memory and include one or several suitable memory modules, such as random access memory (RAM), read-only memory (ROM), flash memory, other types of persistent memory, etc. The UI may become a touch screen. More generally, the disclosed techniques can get implemented in other devices, such as laptops or desktop computers, embedded in a vehicle such as a vehicle head unit, wearable devices, smartwatches or smart glasses, etc.

Depending on the implementation, sensors can include a global positioning system (GPS) module to detect the position of the client computer, a compass to determine the direction of the client computer, a gyroscope to determine the rotation and tilt, an accelerometer, etc.

The Memory Behind this Communication System

The memory stores an operating system (OS) – any type of suitable mobile or general-purpose operating system. The OS can include API functions that allow applications such as the ride service and mapping applications. These may interface with each other. They may also retrieve sensor readings. A software application configured to execute on the client computer can include instructions that invoke an OS API for retrieving a current location and orientation of the client computer at that instant. The API can also return a quantitative sign of how certain the API is of the estimate (e.g., as a percentage).

The memory also stores the mapping application, which gets configured to generate interactive digital maps. The mapping application can receive map data in a raster (e.g., bitmap) or non-raster (e.g., vector graphics) format from the map data database and the server device. In some cases, the map data can get organized into layers, such as a basic layer depicting roads, streets, natural formations, etc., a traffic layer depicting current traffic conditions, a weather layer depicting current weather conditions, a navigation layer depicting a path to reach a destination, etc. The mapping application also can display navigation directions from a starting location to a destination location. The navigation directions may include driving, walking, or public transit directions.

The Mapping Application Behind the Navigation and Transit Communication

The mapping application is a standalone application. The mapping application’s functionality can also become provided in the form of an online service accessible via a web browser executing on the client computer, as a plug-in or extension for another software application executing on the client computer, etc. The mapping application generally can get provided in different versions for different respective operating systems. The maker of the client computer can provide a Software Development Kit (SDK), including the mapping application for the Android platform, another SDK for the iOS platform, etc.

The server device includes one or more processors, APIs, a network interface, and a memory. The APIs may provide functions for interfacing with applications that may get stored in the memory 136 on the server device. The memory is tangible or non-transitory memory. It may include any types of suitable memory modules, including random access memory (RAM), read-only memory (ROM), flash memory, other types of persistent memory, etc. The memory stores instructions are executable on the processors, generating map displays to become displayed by the mapping application for a geographic area.

Similarly, the memory, or the memory in another server, can store instructions that generate navigation directions to a geographic location within the geographic area and may get displayed overlaying the map display by the mapping application. In some implementations, the third-party provider may start calls to the server device for navigations directions that may get used by the ride service application on the client computer.

The Server Devices Behind the Navigation and Transit Communication

For simplicity, the illustration shows the server device as only one instance of a server. But, the server device may include a group of one or more server devices, each equipped with one or more processors and capable of operating independently of the other server devices.

Server devices operating in such a group can process requests from the client computer individually (e.g., based on availability), in a distributed manner where one operation associated with processing a request gets performed on one server device. In contrast, another operation associated with processing the same request becomes performed on another server device or according to any suitable technique. For this discussion, the term “server device” may refer to an individual server device or a group of two or more server devices.

The Third Party Provider Devices Behind the Navigation and Transit Communication

The third-party provider device or ride service provider device may include processors, APIs, a network interface, and a memory. The APIs may provide functions for interfacing with applications that may get stored in the memory of the third-party provider. The memory may include any types of suitable memory modules, including random access memory (RAM), read-only memory (ROM), flash memory, other types of persistent memory, etc.

The memory stores instructions executable on the processors, which can generate, handle and send requests for ride service functions in a ride service application, such as the ride service application stored in the client computer’s memory.

The system includes several third-party provider devices correspondings to several different ride service providers. Also, the client computer includes several ride service applications corresponding to each ride service provider in some instances.

In this manner, a user may compare:

• Ride service types
• Price estimates
• Ride durations
• Estimated wait times for several ride service providers

A Software Architecture On The Client Computer With Protocols For Communicating

The Navigation and Transit Communication could exist between:

• The operating system
• The ride service application
• The mapping application
• Services on the client computer
• As well as other applications

The ride service application exposes a ride service API that gets invoked by the mapping application. The mapping application may allow users to request ride services without leaving the mapping application. This mapping application may provide:

• Pick-up and destination locations to the ride service API
• Provide the types of ride services in the geographic area
• Price estimates for each type of ride service
• Wait times for each type of ride service
• Ride duration for each type of ride service
• Many vehicles within the geographic area
• Etc

In general, the mapping application may make function calls to the ride service application or a ride service server by accessing the ride service API. The API facilitates inter-application communication. It also allows the mapping and rides service applications to maintain control over how processes, logic, and users get handled. It also still exposes functionality to other applications.

The applications can communicate using an inter-process communication (IPC) scheme provided by the operating system. In the client computer, the functionality of the ride service application can become provided as a static library of functions accessible via the ride service API. Some or all functions of the ride service application can execute as part of the mapping application.

More generally, the ride service API provides, to the mapping application, access to a ride service using any suitable software architecture and communication schemes, including those currently known in the art. The ride service API generally can get provided in different versions for different respective operating systems. The maker of the client computer can provide a Software Development Kit (SDK) including the ride service API for the Android platform, another SDK for the iOS platform, etc.

In some instances, the mapping application may communicate with several ride service applications via respective APIs. If the user does not have a ride service application that the mapping application communicates with, the user may become prompted to download the ride service application.

The user does not download the ride service application. The mapping application may communicate via the ride service API with a ride service server, such as the third-party provider device.

A Sequence Diagram With Calls Between a Mapping Application and a Ride Service Application Using APIs

The sequence diagram illustrates an example message sequence chart for one implementation of Navigation and Transit Communication. This diagram for Navigation and Transit Communication can include:

• A user
• A mapping application
• A ride service application
• A ride service API

In the example sequence diagram, the user requests ride services via user controls on the display presented by the mapping application. The user may request directions to a selected destination location for a ride services mode of transportation. The mapping application may generate an API call for ride services to the ride service application API in response to the request. The API call includes a request for ride services, the user’s current location, and the destination location.

The API call is then sent as a request to a ride service application or a ride service server, such as the third-party provider device.

The ride service application may perform its own internal functions to determine:

• The types of ride services available to service the user
• Price estimates for transporting the user to the destination location
• Wait times for picking up the user
• Many vehicles within a geographic area surrounding the user’s current location
• Etc

As part of the navigation and transit communication, the ride service application then prepares a response to get sent to the mapping application with:

• Types of ride services available
• An estimated time for the arrival of a ride through each type of ride service
• An estimated price for each type of ride service
• An estimation of the vehicles/drivers in the area
• Combinations thereof

The response gets received by the ride service API and then formatted and provided to the mapping application. It gets handled and manipulated if necessary for a display to the user.

What May Get Displayed of the Navigation and Transit Communication To A System User

The mapping application may display indications of each type of ride service available. These services can include:

• A carpooling ride service
• A taxi ride service
• A limo ride service
• An extra-large vehicle service

Other information from the navigation and transit communication could include:

• A price estimate for each type of ride service
• A ride duration for each type of ride service
• An estimated wait time for each type of ride service

The mapping application may also display indications of vehicles on the map display in proportion to the number of vehicles within the geographic area, as indicated by the ride service API. While the locations of the vehicles on the map display may not be an accurate representation of the vehicles employed by the ride service provider, the number of vehicles on the map display may get used to showing the user an approximation of the number of vehicles in the area.

When many ride service providers are available, the mapping application may display the vehicles employed by each ride service provider in a different style or color.

Requests From A System User for Navigation and Transit Communication Information

The displayed indications of available types of ride services may include:

• Selectable user controls for selecting a type of ride service. The user views the displayed indications and selects a type of ride service
• A user control for selecting a pick-up location (a pin placed at the user’s current location or a nearby the user’s current location and the user may be able to move the pin to another location by entering an address or point of interest
• Moving the pin to another locatio

The selected type of ride service is then provided to the ride service API and forwarded to the ride service application.

The ride service application then selects a driver for picking up and the user. It transmits driver identification information for the selected driver (e.g., the name of the driver, the vehicle make, model, and color, a license plate number, etc.), an updated price estimate, an updated wait time, a ride ID for retrieving status information indicating that the driver is on the way to pick-up the user, etc. to the ride service API which is then formatted and provided to the mapping application.

The mapping application may present a sign of the driver’s status (e.g., on the way to pick up the user), the updated price estimate, the updated wait time, and the driver identification information to the user.

Transitioning Between User Interfaces During A Ride Service Request Within A Mapping Application

This information reminds me of what I have seen in how Uber and Lyft have been set up. It makes sense that a patent that focuses on navigation and transit communication information would cover such things.

This method can get implemented by a mapping application, a ride service, or any suitable combination.

Showing a Geographic Area Surrounding The User’s Current Location

If you provide navigation and transit communication information for someone, it will make sense to show that for an area near where they are.

Here is what is in this system:

A map display gets presented that includes a geographic area surrounding the user’s current location.

A sign of the user’s current location may also get presented on the map display.

Then, the mapping application presents a search bar for obtaining a geographic search query from a user and providing search results in response to the geographic search query.

The search results may include POIs, addresses, intersections, etc. The user may select one of the search results as a destination location and request directions to the selected destination location.

Selecting Between Different Modes of Transportation

The mapping application may also include user controls for selecting between several modes of transportation, including a ride services mode of transportation. It also provides navigation and transit communication information about a nearby location and those different types of services.

In response to receiving a selection of the ride service mode of transportation, the mapping application may present a ride request display including:

• Indications of ride service providers
• Types of ride services from the ride service providers
• Price estimates for each type of ride service
• Ride duration for each type of ride service
• Wait times for each type of ride service
• Etc

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 (e.g., 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 (e.g., 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 (e.g., 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.

Navigation and Transit Communication Conclusion

I cut off the end of the patent, which discusses how different transit types may combine. Nothing in the patent says that Google will offer any transit services; however, offering information about these services and different ways to combine them could become useful.

Ridesharing services such as Uber and Lyft have become disruptive ways of traveling. We see driverless cars and companies such as Waymo, which could enter that market. Many people ride Busses. Trains, Subways, and Taxis. It makes sense for Google to explore this navigation and transit space. They may have looked at a lot more than what exists in this patent.
.

About Bill Slawski

With more than 26 years of SEO experience and a Juris Doctor Degree, Bill Slawski is the foremost expert on Google’s patents as related to SEO. Patent Exploration is one of the quickest and most detailed ways to find new information about SEO. Bill is the Editor of SEO by the Sea, a prominent search engine optimization blog, where he is the author of over 1,300 posts. Bill’s experience includes Fortune 500 brands and some of the largest websites in the world. Bill is a contributing author for Moz, Search Engine Land, and Search Engine Journal. In 2014-2021, he spoke at industry-leading international conferences about topics including search engine algorithms, universal and blended search, personalization in search, search and social, and duplicate content problems, structured data, and schema