WO2022115846A1 - Système de connexion de covoiturage - Google Patents

Système de connexion de covoiturage Download PDF

Info

Publication number
WO2022115846A1
WO2022115846A1 PCT/US2021/072544 US2021072544W WO2022115846A1 WO 2022115846 A1 WO2022115846 A1 WO 2022115846A1 US 2021072544 W US2021072544 W US 2021072544W WO 2022115846 A1 WO2022115846 A1 WO 2022115846A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
ride
connection
connections
sharing
Prior art date
Application number
PCT/US2021/072544
Other languages
English (en)
Inventor
Kenneth FARMER
Paola Giovanna Piacentini BARUFFALDI
Original Assignee
Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology And Development Co., Ltd. filed Critical Beijing Didi Infinity Technology And Development Co., Ltd.
Publication of WO2022115846A1 publication Critical patent/WO2022115846A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management

Definitions

  • Vehicles such as vehicles used for ride-sharing purposes, vehicles that provide driver-assist functionality, and/or automated or autonomous vehicles (AVs) — may obtain and process sensor data using an on-board data processing system to perform a variety of functions.
  • functions can include determining and/or displaying navigational routes, identifying road signs, detecting objects and/or road obstructions, controlling vehicle operation, and/or the like.
  • Some ride-sharing services enable multiple riders to be pooled together to reduce costs for the riders. For example, a user may request a ride indicating they desire to use a ride-sharing pool to reduce costs. The ride-sharing service may then identify another user who is travelling in the same direction and setup a carpool with the two users.
  • connection users may be identified by accessing one or more third-party services used by the user (e.g., social networking services or communication services) where the connection users may be connected to the user. Further, it can be determined which of the connection users spend at least a threshold amount of time in a location zone (e.g., a particular geographic area) as the user.
  • location zone e.g., a particular geographic area
  • connection users may be considered neighbors of the user. It should be understood that the neighbors may not necessarily live in the same geographic area. For example, a connection user that works in the same geographic area as the user may be considered a neighbor.
  • the ride may be scheduled with a neighbor.
  • scheduling the ride with a neighbor may improve the safety of the ride compared to a shared ride with strangers.
  • the shared ride may reduce the cost of the ride.
  • machine learning models may be used to predict whether a neighbor is likely to take a similar ride as a user at a particular time. Neighbors associated with an above threshold likelihood of taking the same ride as a user, or a ride that overlaps by more than a particular percentage as a ride the user has scheduled or is attempting to schedule, may be presented with an opportunity to join the user as part of a ride-share pool. Further, machine learning models may be used to predict the safety or the sense of safety the user would feel with a particular neighbor joining the ride. Neighbors associated with an above threshold likelihood that the user would be or feel safe with the neighbor may be invited to join the ride- share pool ride.
  • Figure 1A illustrates a block diagram of a networked vehicle environment in which one or more vehicles and/or one or more user devices interact with a server via a network, according to certain aspects of the present disclosure.
  • Figure 1 B illustrates a block diagram showing the vehicle of Figure 1 A in communication with one or more other vehicles and/or the server of Figure 1 A, according to certain aspects of the present disclosure.
  • Figure 2 illustrates a block diagram showing additional and/or alternative details of the networked vehicle environment of Figure 1A in accordance with certain aspects of the present disclosure.
  • Figure 3 illustrates a block diagram of a model generation system in accordance with certain aspects of the present disclosure.
  • FIG. 4 presents a flowchart of an example ride-sharing connection process in accordance with certain embodiments.
  • Figure 5 presents a flowchart of an example ride-sharing pool suggestion process in accordance with certain embodiments.
  • FIG. 6 presents a flowchart of an example ride-sharing pool request process in accordance with certain embodiments.
  • Figure 7 illustrates an example user interface for inviting neighbors to an eligible ride-sharing group in accordance with certain embodiments.
  • Figure 8 illustrates an example user interface for displaying one or more ride-sharing messages in accordance with certain embodiments.
  • Figure 9 illustrates an example user interface for displaying one or more available ride-sharing pool trips in accordance with certain embodiments.
  • Figure 10 illustrates an example user interface for building a ride sharing pool community in accordance with certain embodiments.
  • Figure 11 illustrates an example user interface for accepting an offer to become neighbors with a user in accordance with certain embodiments.
  • Figure 12 illustrates an example user interface for inviting users to a join a ride-share pool trip in accordance with certain embodiments.
  • Figure 13 illustrates an example user interface for scheduling a ride- share pool trip in accordance with certain embodiments.
  • Figure 14 illustrates an example user interface for illustrating a ride- share pool progress in accordance with certain embodiments.
  • Figure 15 illustrates an example user interface for joining a ride- share pool trip in accordance with certain embodiments.
  • Figure 16 illustrates an example user interface for identifying connection users in accordance with certain embodiments.
  • Systems and methods disclosed herein solve the above problems by identifying neighbors, or connections of a user that are known to the user, to share a ride-pool.
  • the system disclosed herein may use machine learning to identify connections of the user that are likely to be travelling between the same or similar location zones as a user requesting a ride.
  • the system may use machine learning to predict a likelihood that the riders will be or feel safe together. For example, machine learning may be used to predict the likelihood that one user may harass another user within the ride-pool.
  • the systems and methods disclosed herein enable a user to reacquaint themselves with a friend and/or learn about a travel destination.
  • a user may desire to reduce the number of people he/she interacts with. By identifying connections of the user that are likely to share a ride with the user, the user is able to take advantage of the ride-pooling service without exposing themselves to additional people, thereby reducing the changes of a stranger spreading a virus or other sickness to the user.
  • Detailed descriptions and examples of systems and methods according to one or more illustrative embodiments of the present disclosure may be found, at least, in the section entitled Ride-Share Pooling with Neighbors, as well as in the section entitled Example Embodiments, and also in Figures 2-16 herein.
  • components and functionality for ride-share pooling with neighbors may be configured and/or incorporated into the networked vehicle environment 100 described herein in Figures 1A-1 B.
  • Various embodiments described herein are intimately tied to, enabled by, and would not exist except for, vehicle and/or computer technology. For example, identifying and scheduling ride-share pool trips with automatically and autonomously identified connection users that are determined to share at least one location zone with a user as described herein in reference to various embodiments cannot reasonably be performed by humans alone, without the vehicle and/or computer technology upon which they are implemented.
  • FIG. 1A illustrates a block diagram of a networked vehicle environment 100 in which one or more vehicles 120 and/or one or more user devices 102 interact with a server 130 via a network 110, according to certain aspects of the present disclosure.
  • the vehicles 120 may be equipped to provide ride sharing and/or other location-based services, to assist drivers in controlling vehicle operation (e.g., via various driver-assist features, such as adaptive and/or regular cruise control, adaptive headlight control, anti-lock braking, automatic parking, night vision, blind spot monitor, collision avoidance, crosswind stabilization, driver drowsiness detection, driver monitoring system, emergency driver assistant, intersection assistant, hill descent control, intelligent speed adaptation, lane centering, lane departure warning, forward, rear, and/or side parking sensors, pedestrian detection, rain sensor, surround view system, tire pressure monitor, traffic sign recognition, turning assistant, wrong-way driving warning, traffic condition alerts, etc.), and/or to fully control vehicle operation.
  • driver-assist features such as adaptive and/or regular cruise control, adaptive headlight control
  • the vehicles 120 can be regular gasoline, natural gas, biofuel, electric, hydrogen, etc. vehicles configured to offer ride- sharing and/or other location-based services, vehicles that provide driver-assist functionality (e.g., one or more of the driver-assist features described herein), and/or automated or autonomous vehicles (AVs).
  • the vehicles 120 can be automobiles, trucks, vans, buses, motorcycles, scooters, bicycles, and/or any other motorized vehicle.
  • the server 130 can communicate with the vehicles 120 to obtain vehicle data, such as route data, sensor data, perception data, vehicle 120 control data, vehicle 120 component fault and/or failure data, etc.
  • vehicle data such as route data, sensor data, perception data, vehicle 120 control data, vehicle 120 component fault and/or failure data, etc.
  • the server 130 can process and store the vehicle data for use in other operations performed by the server 130 and/or another computing system (not shown).
  • Such operations can include running diagnostic models to identify vehicle 120 operational issues (e.g., the cause of vehicle 120 navigational errors, unusual sensor readings, an object not being identified, vehicle 120 component failure, etc.); running models to simulate vehicle 120 performance given a set of variables; identifying objects that cannot be identified by a vehicle 120, generating control instructions that, when executed by a vehicle 120, cause the vehicle 120 to drive and/or maneuver in a certain manner along a specified path; and/or the like.
  • vehicle data such as route data, sensor data, perception data, vehicle 120 control data, vehicle 120 component fault and/or failure data, etc
  • the server 130 can also transmit data to the vehicles 120.
  • the server 130 can transmit map data, firmware and/or software updates, vehicle 120 control instructions, an identification of an object that could not otherwise be identified by a vehicle 120, passenger pickup information, traffic data, and/or the like.
  • the server 130 can communicate with one or more user devices 102.
  • the server 130 can provide a network service to enable a user to request, via an application running on a user device 102, location-based services (e.g., transportation services, such as ride-sharing services).
  • location-based services e.g., transportation services, such as ride-sharing services
  • the user devices 102 can correspond to a computing device, such as a smart phone, tablet, laptop, smart watch, or any other device that can communicate over the network 110 with the server 130.
  • a user device 102 can execute an application, such as a mobile application, that the user operating the user device 102 can use to interact with the server 130.
  • the user device 102 can communicate with the server 130 to provide location data and/or queries to the server 130, to receive map-related data and/or directions from the server 130, and/or the like.
  • the server 130 can process requests and/or other data received from user devices 102 to identify service providers (e.g., vehicle 120 drivers) to provide the requested services for the users.
  • the server 130 can receive data — such as user trip pickup or destination data, user location query data, etc. — based on which the server 130 identifies a region, an address, and/or other location associated with the various users.
  • the server 130 can then use the identified location to provide services providers and/or users with directions to a determined pickup location.
  • the application running on the user device 102 may be created and/or made available by the same entity responsible for the server 130.
  • the application running on the user device 102 can be a third-party application that includes features (e.g., an application programming interface or software development kit) that enables communications with the server 130.
  • a single server 130 is illustrated in Figure 1 A for simplicity and ease of explanation. It is appreciated, however, that the server 130 may be a single computing device, or may include multiple distinct computing devices logically or physically grouped together to collectively operate as a server system.
  • the components of the server 130 can be implemented in application-specific hardware (e.g., a server computing device with one or more ASICs) such that no software is necessary, or as a combination of hardware and software.
  • the modules and components of the server 130 can be combined on one server computing device or separated individually or into groups on several server computing devices.
  • the server 130 may include additional or fewer components than illustrated in Figure 1 A.
  • the network 110 includes any wired network, wireless network, or combination thereof.
  • the network 110 may be a personal area network, local area network, wide area network, over-the-air broadcast network (e.g., for radio or television), cable network, satellite network, cellular telephone network, or combination thereof.
  • the network 110 may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet.
  • the network 110 may be a private or semi-private network, such as a corporate or university intranet.
  • the network 110 may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network.
  • GSM Global System for Mobile Communications
  • CDMA Code Division Multiple Access
  • LTE Long Term Evolution
  • the network 110 can use protocols and components for communicating via the Internet or any of the other aforementioned types of networks.
  • the protocols used by the network 110 may include Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like.
  • HTTP Hypertext Transfer Protocol
  • HTTPS HTTP Secure
  • MQTT Message Queue Telemetry Transport
  • CoAP Constrained Application Protocol
  • Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and, thus, are not described in more detail herein.
  • the server 130 can include a navigation unit 140, a vehicle data processing unit 145, and a data store 150.
  • the navigation unit 140 can assist with location-based services.
  • the navigation unit 140 can facilitate the transportation of a user (also referred to herein as a “rider”) and/or an object (e.g., food, packages, etc.) by another user (also referred to herein as a “driver”) from a first location (also referred to herein as a “pickup location”) to a second location (also referred to herein as a “destination location”).
  • the navigation unit 140 may facilitate user and/or object transportation by providing map and/or navigation instructions to an application running on a user device 102 of a rider, to an application running on a user device 102 of a driver, and/or to a navigational system running on a vehicle 120.
  • the navigation unit 140 can include a matching service (not shown) that pairs a rider requesting a trip from a pickup location to a destination location with a driver that can complete the trip.
  • the matching service may interact with an application running on the user device 102 of the rider and/or an application running on the user device 102 of the driver to establish the trip for the rider and/or to process payment from the rider to the driver.
  • the navigation unit 140 can also communicate with the application running on the user device 102 of the driver during the trip to obtain trip location information from the user device 102 (e.g., via a global position system (GPS) component coupled to and/or embedded within the user device 102) and provide navigation directions to the application that aid the driver in traveling from the current location of the driver to the destination location.
  • GPS global position system
  • the navigation unit 140 can also direct the driver to various geographic locations or points of interest, regardless of whether the driver is carrying a rider.
  • the vehicle data processing unit 145 can be configured to support vehicle 120 driver-assist features and/or to support autonomous driving. For example, the vehicle data processing unit 145 can generate and/or transmit to a vehicle 120 map data, run diagnostic models to identify vehicle 120 operational issues, run models to simulate vehicle 120 performance given a set of variables, use vehicle data provided by a vehicle 120 to identify an object and transmit an identification of the object to the vehicle 120, generate and/or transmit to a vehicle 120 vehicle 120 control instructions, and/or the like.
  • the data store 150 can store various types of data used by the navigation unit 140, the vehicle data processing unit 145, the user devices 102, and/or the vehicles 120.
  • the data store 150 can store user data 152, map data 154, search data 156, and log data 158.
  • the user data 152 may include information on some or all of the users registered with a location-based service, such as drivers and riders.
  • the information may include, for example, usernames, passwords, names, addresses, billing information, data associated with prior trips taken or serviced by a user, user rating information, user loyalty program information, and/or the like.
  • the map data 154 may include high definition (FID) maps generated from sensors (e.g., light detection and ranging (LiDAR) sensors, radio detection and ranging (RADAR) sensors, infrared cameras, visible light cameras, stereo cameras, an inertial measurement unit (IMU), etc.), satellite imagery, optical character recognition (OCR) performed on captured street images (e.g., to identify names of streets, to identify street sign text, to identify names of points of interest, etc.), etc.; information used to calculate routes; information used to render 2D and/or 3D graphical maps; and/or the like.
  • sensors e.g., light detection and ranging (LiDAR) sensors, radio detection and ranging (RADAR) sensors, infrared cameras, visible light cameras, stereo cameras, an inertial measurement unit (IMU), etc.
  • satellite imagery e.g., optical character recognition (OCR) performed on captured street images (e.g., to identify names of streets, to identify street sign text, to identify names of points of interest, etc
  • the map data 154 can include elements like the layout of streets and intersections, bridges (e.g., including information on the height and/or width of bridges over streets), off-ramps, buildings, parking structure entrances and exits (e.g., including information on the height and/or width of the vehicle entrances and/or exits), the placement of street signs and stop lights, emergency turnoffs, points of interest (e.g., parks, restaurants, fuel stations, attractions, landmarks, etc., and associated names), road markings (e.g., centerline markings dividing lanes of opposing traffic, lane markings, stop lines, left turn guide lines, right turn guide lines, crosswalks, bus lane markings, bike lane markings, island marking, pavement text, highway exist and entrance markings, etc.), curbs, rail lines, waterways, turning radiuses and/or angles of left and right turns, the distance and dimensions of road features, the placement of barriers between two-way traffic, and/or the like, along with the elements’ associated geographical locations (e
  • the map data 154 can also include reference data, such as real-time and/or historical traffic information, current and/or predicted weather conditions, road work information, information regarding laws and regulations (e.g., speed limits, whether right turns on red lights are permitted or prohibited, whether U- turns are permitted or prohibited, permitted direction of travel, and/or the like), news events, and/or the like.
  • reference data such as real-time and/or historical traffic information, current and/or predicted weather conditions, road work information, information regarding laws and regulations (e.g., speed limits, whether right turns on red lights are permitted or prohibited, whether U- turns are permitted or prohibited, permitted direction of travel, and/or the like), news events, and/or the like.
  • map data 154 is illustrated as being stored in the data store 150 of the server 130, this is not meant to be limiting.
  • the server 130 can transmit the map data 154 to a vehicle 120 for storage therein (e.g., in the data store 129, described below).
  • the search data 156 can include searches entered by various users in the past.
  • the search data 156 can include textual searches for pickup and/or destination locations.
  • the searches can be for specific addresses, geographical locations, names associated with a geographical location (e.g., name of a park, restaurant, fuel station, attraction, landmark, etc.), etc.
  • the log data 158 can include vehicle data provided by one or more vehicles 120.
  • the vehicle data can include route data, sensor data, perception data, vehicle 120 control data, vehicle 120 component fault and/or failure data, etc.
  • Figure 1 B illustrates a block diagram showing the vehicle 120 of Figure 1A in communication with one or more other vehicles 170A, 170B, . . 170N and/or the server 130 of Figure 1A, according to certain aspects of the present disclosure.
  • the vehicle 120 can include various components and/or data stores.
  • the vehicle 120 can include a sensor array 121 , a communications array 122, a data processing system 123, a communication system 124, an interior interface system 125, a vehicle control system 126, operative systems 127, a mapping engine 128, and/or a data store 129.
  • Communications 180 may be transmitted and/or received between the vehicle 120, one or more vehicles 170A-N, and/or the server 130.
  • the server 130 can transmit and/or receive data from the vehicle 120 as described above with respect to Figure 1 A.
  • the server 130 can transmit vehicle control instructions or commands (e.g., as communications 180) to the vehicle 120.
  • the vehicle control instructions can be received by the communications array 122 (e.g., an array of one or more antennas configured to transmit and/or receive wireless signals), which is operated by the communication system 124 (e.g., a transceiver).
  • the communication system 124 can transmit the vehicle control instructions to the vehicle control system 126, which can operate the acceleration, steering, braking, lights, signals, and other operative systems 127 of the vehicle 120 in order to drive and/or maneuver the vehicle 120 and/or assist a driver in driving and/or maneuvering the vehicle 120 through road traffic to destination locations specified by the vehicle control instructions.
  • the vehicle control instructions can include route data 163, which can be processed by the vehicle control system 126 to maneuver the vehicle 120 and/or assist a driver in maneuvering the vehicle 120 along a given route (e.g., an optimized route calculated by the server 130 and/or the mapping engine 128) to the specified destination location.
  • the vehicle control system 126 can generate control commands 164 for execution by the operative systems 127 (e.g., acceleration, steering, braking, maneuvering, reversing, etc.) to cause the vehicle 120 to travel along the route to the destination location and/or to assist a driver in maneuvering the vehicle 120 along the route to the destination location.
  • the operative systems 127 e.g., acceleration, steering, braking, maneuvering, reversing, etc.
  • a destination location 166 may be specified by the server 130 based on user requests (e.g., pickup requests, delivery requests, etc.) transmitted from applications running on user devices 102.
  • a passenger and/or driver of the vehicle 120 can provide user input(s) 169 through an interior interface system 125 (e.g., a vehicle navigation system) to provide a destination location 166.
  • the vehicle control system 126 can transmit the inputted destination location 166 and/or a current location of the vehicle 120 (e.g., as a GPS data packet) as a communication 180 to the server 130 via the communication system 124 and the communications array 122.
  • the server 130 (e.g., the navigation unit 140) can use the current location of the vehicle 120 and/or the inputted destination location 166 to perform an optimization operation to determine an optimal route for the vehicle 120 to travel to the destination location 166.
  • Route data 163 that includes the optimal route can be transmitted from the server 130 to the vehicle control system 126 via the communications array 122 and the communication system 124.
  • the vehicle control system 126 can cause the operative systems 127 to maneuver the vehicle 120 through traffic to the destination location 166 along the optimal route, assist a driver in maneuvering the vehicle 120 through traffic to the destination location 166 along the optimal route, and/or cause the interior interface system 125 to display and/or present instructions for maneuvering the vehicle 120 through traffic to the destination location 166 along the optimal route.
  • the route data 163 includes the optimal route and the vehicle control system 126 automatically inputs the route data 163 into the mapping engine 128.
  • the mapping engine 128 can generate map data 165 using the optimal route (e.g., generate a map showing the optimal route and/or instructions for taking the optimal route) and provide the map data 165 to the interior interface system 125 (e.g., via the vehicle control system 126) for display.
  • the map data 165 may include information derived from the map data 154 stored in the data store 150 on the server 130.
  • the displayed map data 165 can indicate an estimated time of arrival and/or show the progress of the vehicle 120 along the optimal route.
  • the displayed map data 165 can also include indicators, such as reroute commands, emergency notifications, road work information, real-time traffic data, current weather conditions, information regarding laws and regulations (e.g., speed limits, whether right turns on red lights are permitted or prohibited, where U-turns are permitted or prohibited, permitted direction of travel, etc.), news events, and/or the like.
  • indicators such as reroute commands, emergency notifications, road work information, real-time traffic data, current weather conditions, information regarding laws and regulations (e.g., speed limits, whether right turns on red lights are permitted or prohibited, where U-turns are permitted or prohibited, permitted direction of travel, etc.), news events, and/or the like.
  • the user input 169 can also be a request to access a network (e.g., the network 110).
  • the interior interface system 125 can generate an access request 168, which can be processed by the communication system 124 to configure the communications array 122 to transmit and/or receive data corresponding to a user’s interaction with the interior interface system 125 and/or with a user device 102 in communication with the interior interface system 125 (e.g., a user device 102 connected to the interior interface system 125 via a wireless connection).
  • the vehicle 120 can include on-board Wi-Fi, which the passenger(s) and/or driver can access to send and/or receive emails and/or text messages, stream audio and/or video content, browse content pages (e.g., network pages, web pages, etc.), and/or access applications that use network access.
  • the interior interface system 125 can receive content 167 via the network 110, the communications array 122, and/or the communication system 124.
  • the communication system 124 can dynamically manage network access to avoid or minimize disruption of the transmission of the content 167.
  • the sensor array 121 can include any number of one or more types of sensors, such as a satellite-radio navigation system (e.g., GPS), a LiDAR sensor, a landscape sensor (e.g., a radar sensor), an IMU, a camera (e.g., an infrared camera, a visible light camera, stereo cameras, etc.), a Wi-Fi detection system, a cellular communication system, an inter-vehicle communication system, a road sensor communication system, feature sensors, proximity sensors (e.g., infrared, electromagnetic, photoelectric, etc.), distance sensors, depth sensors, and/or the like.
  • the satellite-radio navigation system may compute the current position (e.g., within a range of 1 -10 meters) of the vehicle 120 based on an analysis of signals received from a constellation of satellites.
  • the LiDAR sensor, the radar sensor, and/or any other similar types of sensors can be used to detect the vehicle 120 surroundings while the vehicle 120 is in motion or about to begin motion.
  • the LiDAR sensor may be used to bounce multiple laser beams off approaching objects to assess their distance and to provide accurate 3D information on the surrounding environment.
  • the data obtained from the LiDAR sensor may be used in performing object identification, motion vector determination, collision prediction, and/or in implementing accident avoidance processes.
  • the LiDAR sensor may provide a 360° view using a rotating, scanning mirror assembly.
  • the LiDAR sensor may optionally be mounted on a roof of the vehicle 120.
  • the IMU may include X, Y, Z oriented gyroscopes and/or accelerometers.
  • the IMU provides data on the rotational and linear motion of the vehicle 120, which may be used to calculate the motion and position of the vehicle 120.
  • Cameras may be used to capture visual images of the environment surrounding the vehicle 120. Depending on the configuration and number of cameras, the cameras may provide a 360° view around the vehicle 120. The images from the cameras may be used to read road markings (e.g., lane markings), read street signs, detect objects, and/or the like.
  • road markings e.g., lane markings
  • read street signs e.g., street signs
  • detect objects e.g., lane markings
  • the Wi-Fi detection system and/or the cellular communication system may be used to perform triangulation with respect to Wi-Fi hot spots or cell towers respectively, to determine the position of the vehicle 120 (optionally in conjunction with then satellite-radio navigation system).
  • the inter-vehicle communication system (which may include the Wi Fi detection system, the cellular communication system, and/or the communications array 122) may be used to receive and/or transmit data to the other vehicles 170A-N, such as current speed and/or location coordinates of the vehicle 120, time and/or location coordinates corresponding to when deceleration is planned and the planned rate of deceleration, time and/or location coordinates when a stop operation is planned, time and/or location coordinates when a lane change is planned and direction of lane change, time and/or location coordinates when a turn operation is planned, time and/or location coordinates when a parking operation is planned, and/or the like.
  • the other vehicles 170A-N such as current speed and/or location coordinates of the vehicle 120, time and/or location coordinates corresponding to when deceleration is planned and the planned rate of deceleration, time and/or location coordinates when a stop operation is planned, time and/or location coordinates when a lane change is planned and direction of
  • the road sensor communication system (which may include the Wi Fi detection system and/or the cellular communication system) may be used to read information from road sensors (e.g., indicating the traffic speed and/or traffic congestion) and/or traffic control devices (e.g., traffic signals).
  • road sensors e.g., indicating the traffic speed and/or traffic congestion
  • traffic control devices e.g., traffic signals
  • the origination location may be the current location of the vehicle 120, which may be determined using the satellite-radio navigation system installed in the vehicle (e.g., GPS, Galileo, BeiDou/COMPASS, DORIS, GLONASS, and/or other satellite-radio navigation system), a Wi-Fi positioning System, cell tower triangulation, and/or the like.
  • the origination location may be specified by the user via a user interface provided by the vehicle 120 (e.g., the interior interface system 125) or via the user device 102 running the application.
  • the origination location may be automatically determined from location information obtained from the user device 102.
  • one or more waypoints may be specified, enabling multiple destination locations.
  • Raw sensor data 161 from the sensor array 121 can be processed by the on-board data processing system 123.
  • the processed data 162 can then be sent by the data processing system 123 to the vehicle control system 126, and optionally sent to the server 130 via the communication system 124 and the communications array 122.
  • the data store 129 can store map data (e.g., the map data 154) and/or a subset of the map data 154 (e.g., a portion of the map data 154 corresponding to a general region in which the vehicle 120 is currently located).
  • the vehicle 120 can use the sensor array 121 to record updated map data along traveled routes, and transmit the updated map data to the server 130 via the communication system 124 and the communications array 122.
  • the server 130 can then transmit the updated map data to one or more of the vehicles 170A-N and/or further process the updated map data.
  • the data processing system 123 can provide continuous or near continuous processed data 162 to the vehicle control system 126 to respond to point- to-point activity in the surroundings of the vehicle 120.
  • the processed data 162 can comprise comparisons between the raw sensor data 161 — which represents an operational environment of the vehicle 120, and which is continuously collected by the sensor array 121 — and the map data stored in the data store 129.
  • the data processing system 123 is programmed with machine learning or other artificial intelligence capabilities to enable the vehicle 120 to identify and respond to conditions, events, and/or potential hazards.
  • the data processing system 123 can continuously or nearly continuously compare raw sensor data 161 to stored map data in order to perform a localization to continuously or nearly continuously determine a location and/or orientation of the vehicle 120.
  • Localization of the vehicle 120 may allow the vehicle 120 to become aware of an instant location and/or orientation of the vehicle 120 in comparison to the stored map data in order to maneuver the vehicle 120 on surface streets through traffic and/or assist a driver in maneuvering the vehicle 120 on surface streets through traffic and identify and respond to potential hazards (e.g., pedestrians) or local conditions, such as weather or traffic conditions.
  • potential hazards e.g., pedestrians
  • local conditions such as weather or traffic conditions.
  • localization can enable the vehicle 120 to tune or beam steer the communications array 122 to maximize a communication link quality and/or to minimize interference with other communications from other vehicles 170A-N.
  • the communication system 124 can beam steer a radiation patterns of the communications array 122 in response to network configuration commands received from the server 130.
  • the data store 129 may store current network resource map data that identifies network base stations and/or other network sources that provide network connectivity.
  • the network resource map data may indicate locations of base stations and/or available network types (e.g., 3G, 4G, LTE, Wi-Fi, etc.) within a region in which the vehicle 120 is located.
  • Figure 1 B describes certain operations as being performed by the vehicle 120 or the server 130, this is not meant to be limiting.
  • the operations performed by the vehicle 120 and the server 130 as described herein can be performed by either entity.
  • certain operations normally performed by the server 130 e.g., transmitting updating map data to the vehicles 170A-N
  • may be performed by the vehicle 120 for load balancing purposes e.g., to reduce the processing load of the server 130, to take advantage of spare processing capacity on the vehicle 120, etc.
  • any of the vehicles 170A-N may include some or all of the components of the vehicle 120 described herein.
  • a vehicle 170A-N can include a communications array 122 to communicate with the vehicle 120 and/or the server 130.
  • ride-sharing with connections of the user may increase rider safety, reduce the spread of disease during a pandemic, enable users to connect or re connect with each other, and enable a user to get insights into his/her destination.
  • Connections can be identified based on other services used by a user.
  • connections that are likely to share a ride with a user and/or provide safety benefits for the users may be identified using user data of the ride-sharing service. This user data may be applied to one or more machine learning algorithms to make one or more predictions regarding trip routes and/or user safety.
  • FIG 2 illustrates a block diagram showing additional and/or alternative details of the networked vehicle environment of Figure 1A in accordance with certain aspects of the present disclosure.
  • the networked vehicle environment 200 may include one or more of the embodiments previously described with respect to the networked vehicle environment 100. Further, although not depicted by the networked vehicle environment 200, the networked vehicle environment 200 can include one or more of the systems of the networked vehicle environment 100, such as the vehicle 120 or the navigation unit 140.
  • the networked vehicle environment 200 may include one or more user devices 102.
  • Figure 2 illustrates a single user device 102, it should be understood that a user may have multiple user devices 102 and that there may be multiple users each with one or more user devices 102 as part of the networked vehicle environment 200.
  • the one or more user devices 102 can include any type of computing device, such as a smartphone, tablet, or laptop.
  • the one or more user devices 102 can include any type of computing device that can be used to request a ride using a ride-sharing application 202, which may be hosted at least in part by the one or more user devices 102.
  • the ride-sharing application 202 can include any type of application that may be used to request or order a ride from one location to another location. Typically, the ride-sharing application 202 is used to request a car ride, but the ride sharing application 202 is not limited as such and can be used to request rides on other types of vehicles, such as motorcycles, airplanes, helicopters, rickshaws, etc.
  • the user devices 102 may further include one or more social networking, social media, or neighborhood networking applications 204 and/or one or more communication applications 206. Moreover, the user devices 102 may include a geolocation system 210.
  • the one or more neighborhood networking applications 204 can include any application that enables a user to connect with one or more friends, neighbors, acquaintances, colleagues, coworkers, etc. in a virtual social environment.
  • the neighborhood networking applications 204 may include one or more social networking applications.
  • the one or more neighborhood networking applications 204 can include Facebook®, Linkedln®, Instagram®, Twitter®, etc.
  • Some neighborhood networking applications 204 may be hybrid applications in that they may provide additional services or functionality that incorporate a social network component.
  • the neighborhood networking applications 204 may be social media applications that include media streaming, such as YouTube® or TikTok®.
  • the neighborhood networking applications 204 may communicate with one or more neighborhood networking provider systems 214.
  • the neighborhood networking provider systems 214 can include any system that enables at least part of the functionality of the neighborhood networking application 204 or that can host a portion of a social network application service that interacts with the neighborhood networking application 204 of the user device 102 to provide a social network.
  • the neighborhood networking provider systems 214 may be a server, such as a server used by a social networking service (e.g., a FaceBook® server or a Twitter® server).
  • the one or more communication applications 206 may include any application that enables a user to communicate with one or more friends, acquaintances, colleagues, coworkers, etc. with whom the user has the contact information (e.g., a phone number or email address).
  • the one or more communication applications 206 can include WhatsApp®, Flangouts®, Messenger®, etc.
  • an application hosted by the user device 102 may be both a neighborhood networking application and a communication application.
  • the communication applications 206 may communicate with one or more communication service provider systems 216.
  • the communication service provider systems 216 can include any system that enables at least part of the functionality of the communication applications 206 or that can host a portion of a communication application service that interacts with the communication application 206 of the user device 102 to provide a communication service.
  • the communication service provider systems 216 may be a server, such as a WhatsApp® server or a Google Flangouts® server.
  • the neighborhood networking applications 204 and/or communication applications 206 may be used in certain embodiments disclosed herein to identify one or more connections (e.g., friends, coworkers, family, acquaintances, or other contacts) of a user. Further, the user device 102 may host one or more other types of applications that may be used with certain embodiments described herein to identify connections of the user.
  • connections e.g., friends, coworkers, family, acquaintances, or other contacts
  • the user devices 102, and the hosted systems or applications thereof, may communication with the neighborhood networking provider systems 214, the communication service provider systems 216, and/or the server 130 via the network 110.
  • the network 110 may include any wired network, wireless network, or combination thereof, including, in some cases, the Internet.
  • the geolocation system 210 may include any system that facilitates determining a location of a user device 102.
  • the geolocation system 210 may include a global positioning system (GPS) receiver.
  • GPS global positioning system
  • the geolocation system 210 may include additional hardware and/or software that can determine a location of the user device 102 based at least in part on a signal received by the GPS receiver.
  • the user devices 102 may communicate with the server 130 to request a ride between two or more locations.
  • the ride-sharing application 202 can be used to request a pool ride that enables multiple users to travel between the same set of locations and/or to share at least a partially overlapping route.
  • the two users may be paired together to be serviced by the same driver if at least a portion of the trips overlap.
  • pairing or pooling two or more users together enables the users to reduce the price of the trip and, in some cases, to obtain a greater sense of safety.
  • pooling riders can have a positive impact on climate change and traffic by reducing the number of cars on the road and/or the number of miles driven.
  • a ride-share as used herein may refer to a ride between two or more locations that is provided by a driver to a user.
  • the term ride-share may be used to indicate that the driver is sharing use of his/her vehicle.
  • a ride-share may include multiple users or passengers who typically are riding between the same two or more locations together.
  • the multiple users may be a family or a group of friends that intend to travel to the same target location.
  • a ride-pool or pooled ride may refer to a ride provided by a driver to a group of users who may or may not be travelling between the same two or more locations. Typically, at least a portion of the ride-pool is overlapping.
  • the server 130 may include a number of systems that facilitate generating a pooled ride or a ride of a group of users that are requesting a ride-share trip using a pool feature of the ride-sharing application 202. Further, the server 130 may include a number of systems that facilitate forming a ride-pool that groups or pools together users who know each other to some minimum degree. For example, the groups or pools of users may be coworkers, neighbors, acquaintances, or any other type of connection.
  • the systems of the server 130 may include a model generation system 208, a ride-sharing group generator 218, a ride-sharing pool engine 220, a safety prediction system 222, ride prediction system 224, and the data store 150.
  • the server 130 may further include the systems illustrated in Figure 1 A.
  • the ride-sharing group generator 218 may include any system that is capable of determining a ride-sharing group or a group of users that are potentially willing and/or available to share a ride-pool with a user.
  • the ride-sharing group of a particular user may include one or more users who are known to the user and/or who know the user.
  • a ride-sharing group may be formed from coworkers, friends, neighbors, or other acquaintances of the user.
  • the ride-sharing group generator 218 may determine a ride-sharing group of a user based at least in part on connections of the user as determined from one or more data sources associated with the user.
  • These data sources may include any source of data that may include connections to other people known to some degree by the user.
  • the data sources may include one or more neighborhood networking applications 204 (or neighborhood networking provider systems 214) and/or one or more communication applications 206 (or communication service provider systems 216).
  • the ride-sharing group generator 218 may use additional factors besides an existence of a connection to the user to generate a ride-sharing group of a user. For example, the inclusion of a connection of a user in ride-sharing group of the user may be based at least in part on a rating of the connection with respect to the ride-sharing service associated with the server 130, verified metadata of the connection, a safety prediction of the connection and/or user when sharing a ride, etc.
  • the ride-sharing group(s) determined by the ride-sharing group generator 218 may be stored at the data store 150 as ride-sharing groups 226.
  • Each ride-sharing group 226 may be associated with a different user and may identify connections of the user who may potentially share a pooled ride or join a ride-pool with the user.
  • the ride-sharing groups 226 may not be associated with specific rides.
  • one connection user in the ride-sharing group 226 may potentially share a ride-pool with a user between particular locations, the connection user may not potentially share a ride-pool with the user between other locations.
  • the ride-sharing pool engine 220 may include any system that is capable of scheduling a ride-share for a pool of users.
  • the ride-sharing pool engine 220 may identify a pool of users to share a ride.
  • the pool of users may be selected based at least in part on a ride-share group associated with at least one of the users included in the ride-share pool.
  • the at least one of the users may be a user who first initiated the ride-share pool request or who is designated as the owner of the ride- share pool.
  • the pools of users may be selected based at least in part on a ride-share group of each user included in the ride-share pool.
  • the ride-share pool may be a set of users who may potentially share a particular ride with a user as selected from a ride-share group of the user.
  • the ride-share pool may be selected based at least in part on a prediction that each connection user in the ride-share pool of a ride-requesting user is likely to travel from a location of the ride-request user and/or to a target location that the ride- requesting user desires to travel at a particular time.
  • the prediction of whether the connection user is likely to travel from a location of the ride-requesting user and/or to a target location that the ride-requesting user desires to travel may be determined by the ride-prediction system 224.
  • the ride-prediction system 224 can include any system that can predict whether one or more connections of a user are likely to travel at least part of a route that a user desires to travel at a particular time.
  • the ride-prediction system 224 can use a machine learning model to predict the likelihood that a connection user of a user will desire to travel along at least part of a route that a user desires to travel at a particular time.
  • the machine learning model may use user data 152 stored at the data store 150 to make the prediction.
  • This user data 152 may include data collected relating to the each user’s use of the ride-sharing application 202, location data at different times of day as may be determined from use of the ride-sharing application 202 and/or the geolocation system 210, or any other data that may be used to predict the likelihood of a user travelling between locations during a particular time.
  • the user data 152 may include travel data provided by the user.
  • the ride-share pool may be selected based on the likelihood that the user will be, or will feel, safe sharing a ride with a particular user connection.
  • the safety or feeling of safety may be predicted using a safety prediction system 222.
  • the safety prediction system 222 can include any system that can predict whether a user will be or will feel safe sharing a ride with a connection of the user included in a ride-sharing group 226 of the user.
  • the safety prediction system 222 can use a machine learning model to predict the likelihood that a user will be or will feel safe sharing a ride pool with a connection user of the user.
  • the machine learning model may use user data 152 stored at the data store 150 to make the prediction.
  • This user data 152 may include data collected relating to the each user’s use of the ride-sharing application 202, location data at different times of day, publically available health data, criminal background data, employment data, financial data, or any other data that may be used to predict the safety or feeling of safety of a user sharing a ride with a particular connection user. It should be understood that the types of user data used may vary based on local laws. For example, in some jurisdictions, health or financial data may be protected by privacy laws. In other jurisdictions, such data may be publically and legally accessible.
  • the model generation system 208 may generate a prediction model using one or more machine learning algorithms.
  • the machine learning algorithms may use historical data to generate the prediction model.
  • the historical data may include any of the previously described user data 152.
  • the historical data may include travel data, location data, harassment data, criminal or other complaint data, financial data, etc.
  • the historical data may include reports, labels, and/or annotations regarding data included in the historical data that indicate harassment, types of harassment, level of harassment, and any other information that may facilitate the identification of an occurrence of harassment or a likelihood of safety for a user riding with a connection associated with the harassment data.
  • the data store 150 can store user data 152, which can include any type of data related to a user’s use of the ride-sharing application 202.
  • the user data 152 may include usernames, passwords, names, addresses, billing information, data associated with prior trips taken or serviced by a user, user rating information, user loyalty program information, the types of services provided by the ride-sharing service that the user uses (e.g., ride-sharing pool services, luxury car requests, etc.), the frequency of services used by the user, and/or the like.
  • the data store 150 may store ride-sharing groups 226 data.
  • the ride-sharing groups 226 data may include one or more ride-sharing groups.
  • Each ride-sharing group may be associated with a particular user and may identify connections of the user. These connections of the user may serve as the universe of people that a user may potentially ride with in a ride-pool. In some cases, the user may ride with people not included in the ride-sharing group. For example, if no connection users of the user are travelling to the same location, or if the user is not associated with a ride-sharing group, the user may be paired with other users of the ride-sharing application 202 to form a ride-share pool that may share a particular ride.
  • FIG. 3 illustrates a block diagram of a model generation system 208 in accordance with certain aspects of the present disclosure.
  • the model generation system 208 may be used to determine one or more prediction models 306 based on historical data 352 for a number of users, ride-sharing requests or orders, or ride-sharing events.
  • the historical data 352 includes data associated with a large number of ride-sharing requests, orders or ride sharing events, such as hundreds, thousands, hundreds of thousands, or more orders.
  • the present disclosure is not limited as such, and the number of ride-sharing events or orders may include any number. These orders or events may each be associated with unique ride-sharing events or drives and/or unique users.
  • ride-sharing requests or events may be request for ride-share pools that includes multiple users requesting to share at least a portion of a ride with at least one other user.
  • at least some of the orders may be associated with the same driver and/or the same user or set of users.
  • some users may request multiple ride-sharing drives over time.
  • drivers may be associated with one order or multiple orders for ride-shares.
  • the historical data 352 can include data received from one or more data sources, such as, for example one or more instances of the ride-sharing application 202, one or more neighborhood networking applications 204, one or more communication applications 206, customer service users, customer service systems, user devices 102, and/or one or more public data sources. Further, the historical data 352 can include data from different data sources, different data types, and any data generated during one or more orders and/or one or more safety reports generated by a customer service representative or customer service system of an entity associated with the ride-sharing application 202. The historical data 352 may generally include sets of real-world data and/or safety incident reports.
  • the historical data 352 may include a very large number of data points, such as millions of data points, which may be aggregated into one or more data sets. In some cases, the historical data 352 may be accessed from a data store 150. Further, in some instances, one or more subsets of the historical data 352 may be limited by a date restriction, such as, for example, limited to include only data from the last 6 months, data that is between 3-6 months old, or data less than a year old. Changing language and culture can cause words to obtain new meanings. These new meanings may result in certain word-usages that might not have been harassing to become associated with harassment.
  • Limiting the training data to a particular time period may facilitate generating a prediction model 306 that reflects changes in the use of certain language over time.
  • different geopolitical regions e.g., countries, states, prefectures, etc.
  • the historical data 352 may vary based on the types of user data that may permissibly be used within the laws of the geopolitical region or jurisdiction.
  • the model generation system 208 may, in some cases, also receive feedback data 354.
  • This data may be received as part of a supervised model generation process that enables a user, such as an administrator, to provide additional input to the model generation system 208 that may be used to facilitate generation of the prediction model 306. For example, if an anomaly exists in the historical data 352, the user may tag the anomalous data enabling the model generation system 208 to handle the tagged data differently, such as by applying a different weight to the data or excluding the data from the model generation process.
  • the model generation system 208 may receive control data 356.
  • This control data 356 may identify one or more features or characteristics for which the model generation system 208 is to determine a model. Further, in some cases, the control data 356 may indicate a value for the one or more features identified in the control data 356. For example, suppose the control data 356 indicates that a prediction model is to be generated using the historical data 352 to determine whether a connection user is likely to travel between the same location zones as the user to which the connection user is connected.
  • control data 356 may include data or labels indicating such classifications of location zones of the connection user and/or times of day the connection user may be at said locations as part of the historical data 352.
  • the model generation system 208 may generally include a model generation ruleset 370 for generation of the prediction model 306.
  • the model generation ruleset 370 may include one or more parameters 362. Each set of parameters 362 may be combined using one or more mathematical functions to obtain a parameter function or prediction model 306. Further, one or more specific parameters may be weighted by the weights 364. In some cases, the parameter function or prediction model 306 may be obtained by combining a set of parameters with a respective set of weights 364.
  • the prediction model 306 and/or the respective parameters 362 of the prediction models 306 may be derived during a training process based on particular input data, such as the historical data 352, the feedback data 354, and the control data 356, and defined output criteria, which may be included with the control data 356, used for training purposes.
  • the model generation ruleset 370 can define the specific machine learning rules and/or algorithms the model generation system 208 uses to generate the model based on a defined objective function, such as determining whether a user feels safe or in danger when sharing a pool ride with another connection user or a particular connection user connected to the user.
  • initial parameters 362 and weights 364 can be manually provided during the initiation of the model generation process.
  • the parameters 362 and weights 364 can be updated and modified during the model generation phase to generate the prediction model 306.
  • the model generation ruleset 370 can indicate the type of machine learning algorithms to perform on the historical data 352.
  • the model generation ruleset 370 may indicate that the model generation system 208 use a FastText algorithm, a deep learning algorithm (e.g., a convolutional neural network (CNN) or a Recurrent Neural Network (RNN)), linear regression, decision tree, a Bayesian algorithm (e.g., na ' ive Bayes or Bayesian Network), a clustering algorithm (e.g., K-Means or k-Medians), an association rule learning algorithm (e.g., Apriori algorithm or Eclat algorithm), an artificial neural network algorithm (e.g., perception, Hopfield Network, or Radial Basis Function Network), or a hierarchical attention network (FIAN), and the like.
  • Any type of machine learning algorithm may be used including an unsupervised learning, semi- supervised learning or supervised learning algorithm.
  • the model generation system 208 can filter and categorize the historical data 352 according to various characteristics and parameters of the data.
  • the data can be categorized by the data source (for example, data collected by the ride-sharing application 202, data collected from an external source (e.g., a neighborhood networking application 204), data collected from customer complaints or reviews, or data collected from any other source).
  • the data may be categorized by type (e.g., location data, usage data, reviews data, financial data, criminal record data, etc.).
  • the model generation system 208 can filter the information to identify subset of historical data 352 for further processing.
  • the model generation system 208 is configured to filter and separate the historical data 352 into a plurality of data types or categories before further processing.
  • some of the historical data 352 may be filtered out or removed from the historical data 352 based on the data being associated with a relevance that does not satisfy a threshold relevance as determined by the model generation system 208. For example, trip or location data obtained at a location that is more than a particular distance from the user’s residence (e.g., a vacation location) may be ignored or filtered from the historical data 352.
  • the model can be deployed or used during runtime of the ride prediction system 224 to determine or predict whether a connection user likely to travel at the same time as the user to the same, or nearby, location as the user.
  • the model can be deployed or used during runtime of the safety prediction system 222 to determine or predict whether the user will feel or will be safe when travelling in a pool-ride with a particular connection user.
  • the prediction model 306 generated based at least on the historical data 352 may be provided as an input to the model generation system 208.
  • the prediction model 306 may then be modified based on additional training data received including, in some cases, more recent ride-sharing events and/or user data for one or more connection users of a user than those initially used as part of the historical data 352 to initially generate the prediction model 306. In other words, in some cases, the prediction model 306 can be modified or updated over time as more data and/or audio segments are obtained.
  • FIG. 4 presents a flowchart of an example ride-sharing connection process 400 in accordance with certain embodiments.
  • the process 400 can be implemented by any system that can identify one or more connections or connection users of a particular user and that can form a ride-sharing group.
  • the ride-sharing group may include connections of the user that may potentially share a ride, or participate in a ride-pool, with the user either at a current time, or at some point in time in the future.
  • the process 400 in whole or in part, can be implemented by, for example, a server 130, a ride-sharing group generator 218, a safety prediction system 222, a ride prediction system 224, or a ride-sharing application 202, among others.
  • any number of systems, in whole or in part can implement the process 400, to simplify discussion, the process 400 will be described with respect to particular systems.
  • the process 400 may be performed when or in response to a user requesting a ride-share pool, or a ride-share trip with a group or pool of users. Alternatively, or in addition, the process 400 may be performed when a user registers or opts-in to using a ride-share pool service. In some cases, the process 400 may be performed in response to a command from a user or an application, such as the ride-sharing application 202. Further, the process 400 may be performed once for a user or a plurality of times.
  • the process 400 may be performed on a scheduled basis, as triggered by a user or system, in response to a change in accessible applications or services that may be used to identify connections of the user, or any other trigger that may cause the process 400 to be performed. In some cases, the process 400 may be performed automatically for each user who installs or registers with the ride-sharing application 202 or a service associated with or accessible via the ride-sharing application 202.
  • the process 400 begins at block 402 where, for example, the ride sharing group generator 218 receives an indication from a user of a desire to use a grouped ride-sharing feature of a ride-sharing application 202, or a ride-sharing service accessible using the ride-sharing application 202.
  • the ride-sharing group generator 218 may receive the indication from the user in response to the user interacting with a user interface of the ride-sharing application 202 hosted by the user device 102 of the user.
  • the grouped ride-sharing feature may include any ride-share features that enables a plurality of users to group or pool together to share at least a portion of a ride-share trip. Typically, although not necessarily, each user within the ride-share pool or group may separately request a ride.
  • the ride sharing application 202 may automatically determine users that can be grouped or pooled together in a shared ride based on the location and destinations requested by each of the users.
  • the ride-sharing group generator 218 accesses one or more user connection applications to identify connections of the user. These connections of the user may be referred to as “connection users” herein to distinguish them from the user. However, any user may be a connection user, and any connection user may also serve as a user with respect to performing an instance of the process 400.
  • the user connection applications can include any type of application that enables or permits a user to connect with other users.
  • the user connections applications can include a neighborhood networking application 204, a communication application 206, an electronic address book hosted by the user device 102, or any other type of application that connects users together.
  • Accessing the user connection applications can include causing the ride-sharing application 202 to access the user connection applications (e.g., the neighborhood networking application 204 or the communication application 206) hosted by the user devices 102.
  • the ride-sharing application 202 may perform one or more of the operations associated with the block 404.
  • accessing the user connection applications may include accessing a server associated with the user connection applications instead of or in addition to access the applications hosted by the user device 102.
  • the ride-sharing group generator 218 and/or the ride-sharing application 202 may access one or more of the neighborhood networking provider systems 214 and/or the communication service provider systems 216 to identify connections of the user.
  • the applications accessed to determine user connections include applications that have granted access permissions to the ride-sharing group generator 218 and/or a ride-sharing service associated with the server 130.
  • accessing the user connection applications may include accessing one or more user accounts of the user associated with the user connection applications to determine connection users connected to the user.
  • Accessing the user connection applications and/or provider systems 214, 216 may include accessing one or more accounts of the user.
  • the accounts may be accessed via permissions granted by the user on the user devices 102.
  • the accounts may be accessed using access information (e.g., user name and/or password) provided by the user.
  • access information e.g., user name and/or password
  • the ride-sharing application 202 may provide the information to the ride-sharing group generator 218 over the network 110.
  • the block 404 may include receiving an identifier, a profile, or any other type of information associated with connections of the user. Further, the block 404 may include a ride-sharing application 202 accessing the identifier or profile of the connections of the user. The ride-sharing application 202 may provide the accessed identifier or profile of the connections of the user to the ride-sharing group generator 218.
  • the ride-sharing group generator 218 identifies a registered subset of the connections of the user that are registered with the ride sharing application 202, or a ride-sharing service accessible using the ride-sharing application 202.
  • the ride-sharing group generator 218 may determine whether a user connection is registered with the ride-sharing application 202 (or a service that is accessible via the ride-sharing application 202) by accessing a data store 150 to determine whether the user data 152 includes an identifier or an account associated with the user connection.
  • the determination of whether the user connection is registered with the ride-sharing application 202 may be based on one or more pieces of information or data obtained for the connection user at the block 404 from the one or more user connection applications.
  • the ride-sharing group generator 218 may obtain account names, user names, addresses, phone numbers, and etcetera of one or more connection users connected to the user. Using one or more pieces of the obtained data, the ride-sharing group generator 218 can determine whether the connection user is registered with the ride-sharing service. The determination of whether a connection user is registered with the ride-sharing service may be based on any uniquely identifying information of the connection user that can be obtained from the one or more user connection applications.
  • determining whether a connection user is registered with the ride-sharing application may further include determining whether the connection user has opted-in to a grouped or pool ride-sharing feature. If the connection user has not opted-in to the grouped or pool ride-sharing feature, or if the connection user has opted to maintain his/her profile as private, the connection user may be excluded from the registered subset of the connections of the user. Further, in some cases, connection users who do have not provided a minimum set of profile information for creating his/her ridesharing account may be excluded from the registered subset of the connections of the user. For example, connections users without a picture or a full legal name may be excluded because, for example, such information may be desirable for a user to feel a sense of safety that they know the connection user with whom they are travelling.
  • the ride-sharing group generator 218 identifies one or more location zones associated with the user.
  • the one or more location zones may be addresses, regions, areas, neighborhoods, geographic locations, or other destinations where the user is present for at least a threshold period of time or a threshold percentage of time within a particular time period.
  • the location zone may be a residence, workplace, shopping center, town, or any other locality wherein the user spends a minimum amount of time or a minimum amount of time over a particular time period (e.g., per day, per week, every 2-3 days, per month, per year etc.).
  • location zones may be determined at least in part based on time spent at the location over a particular time period
  • location zones that a user visits once or infrequently may be excluded from location zones associated with the user, thereby reducing the likelihood that a user who rarely visits a particular location zone is paired with someone that frequently visits a location zone, or vice versa.
  • the location zones may be an area around a particular location that the user is determined to be or to spend time.
  • a location zone may be a housing complex or neighborhood that includes the user’s residence.
  • the location zone may the user’s residence itself.
  • the size of the location zone may vary based on the location. For example, a location zone may be larger when associated with a user’s place of residence than when associated with a user’s place of employment.
  • a location zone may be larger in an area that is easy to traverse quickly (e.g., due to many walking paths or low traffic levels) and smaller in an area that is difficult to traverse (e.g., due to high traffic levels, or natural or man-made barriers, etc.).
  • the ride-sharing group generator 218 may determine the one or more location zones based on a ride-share history or a history of use of the ride sharing application 202 by the user.
  • the one or more location zones may be determined based on detected locations of the user device 102 using geolocation data, which may be determined by the geolocation system 210.
  • at least some of the location zones may be determined based on information supplied by the user, such as home address.
  • the location zones may be associated with a particular zip code, neighborhood, bootsla, or other zone that is defined by an official body (e.g., government). Further, in some cases, a location zone may include any geographic area that may be recognized officially or unofficially by a group of people. For example, the location zone may be a city or neighborhood region known or recognized by its residents or other users.
  • the ride-sharing group generator 218 identifies one or more location zones associated with each connection user included in the registered subset of connections of the user.
  • the location zones for each connection user may be determined using one or more of the embodiments described with respect to the block 408. For example, location zones of a connection user may be determined based at least in part on use of the ride-sharing application 202 by the connection user, information provided by the connection user, and/or determination of a location of a user device 102 of the connection user. Further, it should be understood that each connection user, as well as the user, may be associated with his/her own user device 102 and may have his/her own instance of the ride-sharing application 202 installed on his/her user device 102. In some cases, if location zones cannot be determined for a connection user, the connection user may be excluded from the registered subset of connections of the user.
  • connection users that share a residence or work location zone may be included in the set of neighbor connections while connection users that do not share the residence or work location zones may be excluded.
  • any shared location zone may be sufficient to include the connection zone in the set of neighbor connections.
  • the set of neighbor connections may include any connection user that shares a location zone (e.g., residence zone, work zone, shopping zone, school zone, entertainment zone, or any other geographic location) with the user and is not limited to neighbors per se.
  • the block 412 may be optional or omitted.
  • any connection user of the user may be included as a potential connection user to share a ride-pool with the user.
  • the ride-sharing group generator 218 filters the set of neighbor connections based at least in part on one or more verified user characteristics and/or safety-related predictions associated with one or more connections in the set of neighbor connections.
  • the one or more verified user characteristics may include any data or metadata of a connection user that can be verified with a government source, an official source, or via any trusted third-party.
  • the verified user characteristics may include name, address, identifier number (e.g., social security number), picture, employer, credit rating, health data, and the like.
  • Neighbor connections that are not successfully verified or that are unverified may be filtered or removed from the set of neighbor connections.
  • Unverified neighbor connections may include neighbor connections that are associated with one or more pieces of metadata that is unsuccessfully verified.
  • the safety-related predictions may include any type of prediction relating to the actual safety or perceived safety of a user.
  • the safety- prediction may be determined by application of user data 152 of the connection user and/or the user to a machine learning model by the safety prediction system 222.
  • the machine learning model which may be generated by the model generation system 208, can predict the likelihood that a user will be or feel safe when sharing a ride-pool with a particular connection user. Conversely, the machine learning model may predict the likelihood that a user will not be safe or feel safe sharing a ride with a particular connection user of the user.
  • This predicted safety or lack of safety may be due to a likelihood that the connection user will harass or otherwise commit a crime with respect to the user.
  • the prediction may be based on any user data of the connection user including name, address, identifier number (e.g., social security number), picture, employer, criminal history, credit rating, health data, rating of the connection user with the ride-sharing service, complaints against the connection user by drivers or other users who have shared a ride with the connection user, and the like.
  • the safety prediction may be a prediction of an occurrence or likelihood of an occurrence of a safety event or an event related to the safety of the user and/or connection user.
  • the safety prediction may be a prediction of the likelihood that the connection user verbally or physically harasses the user.
  • the safety prediction may be a prediction of the likelihood that the user or connection user harasses the driver of the ride-share pool.
  • the ride-sharing group generator 218 presents an identity of one or more of the filtered connections to the user as one or more potential ride-sharing connections.
  • the ride-sharing group generator 218 may present the identity of the one or more filtered connections by providing the identity of the one or more filtered connections to the ride-sharing application 202, which can present the identity of the one or more filtered connections to the user of the user device 102.
  • the identity of the one or more filtered connections may be presented to the user when requesting a ride-sharing pool.
  • the identity of the one or more filtered connections may be presented or accessible at any time by the user in response to a user interaction with the ride-sharing application 202.
  • the block 416 is optional or omitted.
  • the ride sharing application 202 and/or the ride-sharing pool engine 220 may automatically select one or more connection users from the filtered connections to join a ride-pool or to present an opportunity to join a ride-pool with the user.
  • the identity of the one or more connection users may be presented to the user, and in other cases the identity may not be presented or only presented upon confirmation of acceptance of the ride by the connection user.
  • the selection of connection user(s) from the filtered connections may be based on the start and/or ending location of a requested trip, or the predicted likelihood that the connection user(s) will desire to take a trip within a threshold distance of a start or end location of the user at a particular time.
  • presenting the identity of the one or more filtered connections to the user can include presenting information about each user connection from the one or more filtered connections.
  • the ride-sharing group generator 218 and/or the ride-sharing application 202 may present a profile of each connection user.
  • connection users of the user may be filtered based on one or more of the aforementioned data instead of or in addition to presenting the data to the user.
  • the ride-sharing group generator 218 receives a selection from the user of one or more connections from the filtered connections.
  • the selection of the one or more connections or connection users may be received in response to the filtered connections being presented to the user on the user device 102 via, for example, the ride-sharing application 202.
  • the connection user may only be presented as a potential ride-sharing connection with the consent of the connection user.
  • the consent may be specific with respect to the user or may be associated with whether the connection user agrees to use the ride-share pool feature of the ride-sharing service.
  • the ride-sharing group generator 218 forms an eligible ride-sharing group based at least in part on the one or more connections selected by the user.
  • the eligible ride-sharing group may include some or all of the connections of a user who may be willing to share a ride-share pool trip or group ride with the user. Further, the eligible ride-sharing group may include some or all of the connections of a user who may potentially travel between two destinations that the user may travel and/or who may potentially take a trip that at least partially overlaps with a trip the user may take.
  • the user may feel safer and be able to take advantage of ride-sharing pools without some of the concerns (e.g., safety) that may arise with sharing a ride with strangers.
  • a similar process to the process 400 can be used to connect drivers and potential riders.
  • the driver can be the user of the process 400 and the connections users can be potential riders.
  • the eligible ride-sharing group may be a group of potential riders.
  • the safety of the driver can be increased or the risk of harm to the driver by unruly or malicious passengers can be reduced.
  • FIG. 5 presents a flowchart of an example ride-sharing pool suggestion process 500 in accordance with certain embodiments.
  • the process 500 can be implemented by any system that can identify or propose one or more connection users of a user to include in a ride-share pool with the user for a particular ride.
  • the particular ride may be a ride the user is requesting for a current time or scheduling for a future time.
  • the process 500 in whole or in part, can be implemented by, for example, a server 130, a ride-sharing group generator 218, a ride-sharing pool engine 220, a safety prediction system 222, a ride prediction system 224, or a ride sharing application 202, among others.
  • a ride-sharing group generator 218, a ride-sharing pool engine 220, a safety prediction system 222, a ride prediction system 224, or a ride sharing application 202 among others.
  • the process 500 may be performed in response to a request for a ride at a current time or in response to a request for a ride in the future. In cases where the request for the ride is in the future, the process 500 may be performed upon receiving the request, at a time when the scheduled ride is to occur, or at a time that is shortly before or within a threshold time prior to the scheduled ride time. In some cases, the process 500 may be performed multiple times for a particular ride. For example, the process 500 may be performed upon receipt of the request and then may be subsequently performed, at least in part, at some time after the initial performance of the process 500 but prior to the scheduled ride time.
  • the process 500 may begin at block 502 where, for example, the ride-sharing pool engine 220 receives an indication of a user’s desire to schedule a ride-sharing pool.
  • the indication may be received from a ride-sharing application 202 in response to a user interacting with a user interface of the ride-sharing application 202 at the user device 102.
  • the indication may be received from a neighborhood networking application 204 and/or a communication application 206 in response to a user interacting with a plugin or other element associated with the ride-sharing service accessible via the ride-sharing application 202.
  • the indication may include an identification of a location of the user, a target location of the user, a time that the ride-share is desired (e.g., immediately, as soon as possible, or at a particular time), the type of ride-share service desired (e.g., a ride-share pool or group service, a particular vehicle class, and the like), a number of riders or users in the requesting user’s party, or any other information that may facilitate scheduling a ride- share trip.
  • the indication may be an indication of a desire to schedule a ride-sharing trip and may not specifically identify a desire to use a ride-sharing pool service.
  • the ride-sharing pool engine 220 may identify one or more trip options and may indicate to the user whether a ride-sharing pool may be available for the identified ride-share trip. [0126] At block 504, the ride-sharing pool engine 220 determines a location of the user at a particular time. The location may be the current location of the user, or the user device 102 of the user. Alternatively, or in addition, the location may be a location where the user will begin the ride-share trip. The location where the user desires the ride-share trip to begin may differ from the user’s current location because, for example, the user may be walking (or otherwise travelling) to the desired trip start location and/or the user may be scheduling the trip for some time in the future when the user expects to be at a different location. The particular time may be a current time, a scheduled time, or any particular desired time or time range in the future.
  • the location of the user may be determined based at least in part on the request to schedule a ride-sharing ride and/or a ride-sharing pool ride received at the block 502.
  • the location of the user may be determined based at least in part on location information obtained from one or more location tracking or determination systems.
  • the location of the user may be determined based at least in part on a geolocation signal received from a geolocation system 210 (e.g., a GPS) of the user device 102.
  • a geolocation system 210 e.g., a GPS
  • the location of the user may be determined based at least in part on a signal from a wireless router and/or a location determined by the user device 102 using, for example, triangulation of a wireless signal or a cellular signal.
  • the location of the user device 102 may be determined from a cellular base station.
  • the ride-sharing pool engine 220 determines a target location for the user.
  • the target location may include any location or destination where the user desires to travel using the ride-sharing service accessible via the ride-sharing application 202.
  • the target location may be a final destination during a user’s excursion or trip, on other cases, the target location may be an intermediary location or destination during the user’s excursion or trip.
  • the target location may include a plurality of locations of a user’s trip itinerary. For example, a user may schedule multiple stops as part of the ride-sharing trip.
  • one of the target locations may be the initial location enabling a user to schedule a round-trip.
  • the identity of the target location may be determined based at least in part on the request to schedule a ride-sharing ride and/or a ride-sharing pool ride received at the block 502. It should be understood that both the location and target location may be received as part of separately received commands or requests.
  • the ride-sharing pool engine 220 may separately receive: 1 ) a request to schedule a ride-sharing pool ride; 2) an indication of a user’s current location or planned start location; and 3) an indication of the user’s target location.
  • the ride-sharing pool engine 220 accesses an eligible ride-sharing group 226 associated with the user.
  • the eligible ride-sharing group 226 may include an identity and/or other data regarding connection users connected to the user who may potentially share a ride-sharing pool trip with the user.
  • the eligible ride-sharing group 226 may include all users connected to the user who have been determined as potentially eligible to share a ride-sharing pool trip with the user.
  • the eligible ride-sharing group 226 may include a subset of users connected to the user who have been determined as potentially eligible to share a ride-sharing pool trip with the user.
  • the subset of users may be selected at random or based on a frequency of which each user in the subset of users has previously agreed to share a ride-pool with the user.
  • the eligible ride-sharing group 226 may be reduced to a subset to prevent overwhelming the user with too large of a selection of potential connections uses to share a ride-share pool ride.
  • the eligible ride-sharing group 226 may be accessed from a data store 150. Further, the eligible ride-sharing group 226 may be determined using any process of identifying connection users, or users connected to the trip requesting user, that may potentially share a ride-share pool ride with the user. For example, the eligible ride sharing group 226 may be determined using the process 400.
  • the ride-sharing pool engine 220 accesses user data for each connection user included in the eligible ride-sharing group 226.
  • the user data may be accessed from the data store 150.
  • the user data may include any data associated with the connection user that may be used to determine a likelihood that the connection user will travel between the location and the target location, will take a trip that at least partially overlaps with the trip requested by the user, will travel within the particular time the user is travelling or plans to travel, and/or will accept an offer to share a ride-sharing trip pool with the user.
  • the user data may include an identity of location zones where the connection user works, lives, shops, travels to an above threshold amount of time within a time period, or spends an above threshold amount of time within a time period.
  • the user data may include information about how frequently the connection user uses the ride-sharing service, uses a pool feature of the ride-sharing service, travels to particular locations, etc.
  • the ride-sharing pool engine 220 identifies a subgroup of the eligible ride-sharing group 226 likely to travel between the location and the target location at the particular time.
  • the block 512 may include determining whether a connection user included in the eligible-ride sharing group 226 is likely to travel within a threshold distance of the location, the target location (or one of a plurality of target locations of the user’s trip itinerary), and/or along a particular portion of a route between the location and the target location. If it is determined that the connection user is likely to travel within the threshold distance of the aforementioned locations, the connection user may be included in the subgroup of the eligible ride-sharing group. Otherwise, the connection user may be excluded from the subgroup of the eligible ride-sharing group.
  • Determining whether a connection user included in the eligible-ride sharing group 226 is likely to travel within the threshold distance of the aforementioned locations may include determining whether connection user is likely to travel within the threshold distance of the aforementioned locations during a particular time period that encompasses the particular time.
  • the particular time period may be the particular time, or may be within or less than a threshold time difference from the particular time (e.g., within 15, 30, or 60 minutes of the particular time specified by the user).
  • determining whether a connection user included in the eligible-ride sharing group 226 is likely to travel within the threshold distance of the aforementioned locations and/or within a threshold time of the particular time may include applying the user data to a ride-prediction system 224.
  • the ride-prediction system 224 may use one or more machine learning models to predict the likelihood that the connection user will travel within the threshold distance of the aforementioned locations and/or within a threshold time of the particular time.
  • Connection users determined by the ride-prediction system 224 to have an above threshold likelihood of travelling within the threshold distance of the aforementioned locations and/or within a threshold time of the particular time may be included in the subgroup of the eligible ride-sharing group, and other connection users may be excluded.
  • the ride-sharing pool engine 220 outputs an identifier for each connection user included in the subgroup of the eligible ride-sharing group.
  • Outputting the identifier may include outputting one or more pieces of user data associated with the connection user.
  • outputting the identifier may include outputting a user profile of the connection user, a link to the user profile of the connection user, a rating associated with the ride-sharing service for the connection user, a frequency of use of a ride-sharing pool service of the ride-sharing service, or any other information that may help a user select a connection user for a ride-sharing pool trip or for requesting that the connection user join a ride-sharing pool trip with the user.
  • Outputting the identifier for each connection user may include providing the identifier to a ride-sharing application 202 installed or hosted by the user device 102 enabling the identifier for each connection user to be presented to a user associated with or otherwise using the user device 102.
  • the ride-sharing application 202 may present the identifiers for the connection users included in the subgroup of the eligible ride-sharing group to the user enabling the user to select one of more of the connection users to be offered an opportunity to join a ride-share pool with the user.
  • FIG. 6 presents a flowchart of an example ride-sharing pool request process 600 in accordance with certain embodiments.
  • the process 600 can be implemented by any system that can schedule a ride-sharing pool with one or more connection users of a user.
  • the ride-sharing pool may be scheduled for a particular trip plan or trip itinerary at a particular time or time period.
  • the process 600 in whole or in part, can be implemented by, for example, a server 130, a ride-sharing group generator 218, a ride-sharing pool engine 220, a safety prediction system 222, a ride prediction system 224, or a ride-sharing application 202, among others.
  • a ride-sharing group generator 2148 can implement the process 600, to simplify discussion, the process 600 will be described with respect to particular systems.
  • the process 600 may be performed in response to a request for a ride at a current time or in response to a request for a ride in the future. Further, the process 600 may be performed as part of the process 500. For example, after receiving an identifier for each connection user at the block 514, the process 600 may be performed. In some cases, the process 600 may be performed multiple times for a particular trip. For example, a user may select one connection user to join him/her on a ride-sharing pool. If the connection user declines to join the user, the process may be repeated, at least in part, with another selected connection user.
  • the process 600 may begin at block 602 where, for example, the ride-sharing pool engine 220 receives a selection of one or more connection users of a user and a trip plan.
  • the trip plan may include the start location, destination location, and any intermediary locations, if any, for the user’s trip itinerary.
  • the selection of the one or more connection users may include an identity of one or more connection users from an eligible ride-sharing group if the user.
  • This eligible ride sharing group may be a subset or subgroup of an eligible ride-sharing group as described with respect to the process 500.
  • the selection of connections may be determined by the ride-sharing pool engine 220 based at least in part on an application of user data of the user connections included in the eligible ride-sharing group to a machine learning model, such as a machine learning model implemented by the ride prediction system 224.
  • the ride prediction system 224 may predict the likelihood that a connection user will join a trip corresponding to the trip plan. If the likelihood is above a threshold, the connection user may be selected at the block 602.
  • the ride-sharing pool engine 220 automatically selects one or more connection users of the user without input from the user.
  • the ride-sharing pool engine 220 may present (e.g., by presenting identifiers and/or profiles) a set of potential connection users to share a ride-sharing pool ride to the user. These presented connection users may be the users included in the eligible ride-sharing group, or a subset thereof. The user may then select the one or more connection users from the presented connections by, for example, interacting with a user interface of the ride-sharing application 202 and/or a communication application 206 that includes a plug-in or other software add-on associated with the ride-sharing service. In some cases, the user selects the connection users without the ride-sharing pool engine 220 performing an automated process to present a set or subset of connection users to the user. In some cases, the ride-sharing application 202 may perform one or more of the operations described with respect to the block 602. In some such cases, the ride-sharing application 202 may provide the selected connection users to the ride-sharing pool engine 220.
  • the ride-sharing pool engine 220 receives a ride- request message associated with the trip plan.
  • the message may be automatically generated based on an identity of the user connection selected at the block 602 and the locations included in the trip plan. For example, the message may state that the user desired to take a particular trip at a particular time and may offer the connection user an opportunity to indicate if the connection user desired to join the trip as part of a ride-share pool.
  • the message may be created by or personalized by the user. For example, the user may create a message explaining where and why the user is taking a particular trip, and may provide some personalized text requesting that the connection user join the user on the trip.
  • the message may include any type of information that may be useful or helpful for the connection user to decide whether to join a trip of the user.
  • the message may include location information, an identity of the user, a reason for the trip, a timing of the trip, a reason why the connection user was selected to be offered to join the trip, an identity of any shared location zones (e.g., work in same area, live in same area, etc.), a relationship between the connection user and the user (e.g., have similar circle of friends, live in same neighborhood, attended same school, etc.), an indication of whether the connection user and the user have previously ridden together, or any other information that may help the connection user decide whether to join the user on the proposed trip associated with the trip plan.
  • shared location zones e.g., work in same area, live in same area, etc.
  • a relationship between the connection user and the user e.g., have similar circle of friends, live in same neighborhood, attended same school, etc.
  • an indication of whether the connection user and the user have previously ridden together
  • the ride-request message is generated by or received by the ride-sharing application 202. Further, in some cases, the ride-request message is provided directly to a user device 102 of a connection user of the user without being provided to the server 130. For example, the user device 102 of the user may establish a peer-to-peer connection with a user device 102 of the connection user. As another example, the ride-request message may be communication via a neighborhood networking application 204 or a communication application 206. In some such cases, the ride-request message may be communicated via a neighborhood networking provider system 214 and/or a communication service provider system 216.
  • the ride-sharing pool engine 220 causes the ride- request message to be displayed on a user device 102 of each of the selected user connections of the user.
  • the ride-sharing pool engine 220 may transmit the ride- request message to the user device 102 of each of the selected user connections of the user.
  • the ride-request message may be displayed via a user interface of the ride sharing application 202.
  • the ride-sharing message may be displayed via an email, text message, social networking feed, or any other communication mechanism available to the connection user.
  • the ride-request message may be presented for a particular period of time. In some cases, the ride-request message may be presented until a particular number of connection users accepts the request to join the user as part of a ride-share pool.
  • the ride-request message may be associated with a time-to-live value. Once the time-to-live message is reached the ride-request message may be retracted, disappear, deleted, marked no longer valid, or otherwise modified to indicate that the availability of the offer to join the user in a ride-share pool has changed. In other words, the ride-request message may cease being displayed at the use device 102 of the connection user. Alternatively, the ride-request message may continue to be displayed, but may be marked as expired.
  • the connection user may still response. For example, the connection user may indicate that he/she did not see the message, but would be open to sharing a ride in the future to that location. Or the connection user may indicate that he/she has changed jobs or moved and no longer travels to a particular location. It should be noted that if the change in circumstances of the connection user has been obtained by the ride-sharing pool engine 220, the connection user may be removed from the set of eligible ride-sharing group 226 or may be moved to a different group of the user associated with the updated location zone(s) of the connection user. Similarly, if circumstances of the user changes, the processed described herein may be repeated to update the ride-sharing group(s) 226 of the user based on the change in location zones or travel patterns.
  • the ride-sharing pool engine 220 receives an indication that a user connection from the selected connections accepted the trip plan.
  • the indication may be received in response to the connection user interacting with the ride sharing application 202 on the connection user’s user device 102.
  • the indication is presented to the user requesting the ride-sharing pool.
  • the indication may be presented to the user via a user interface of the ride-sharing application 202 on the user’s user device 102. If no connection users accepts to join the user in a ride-share pool as proposed by the user, the process 600 may include identifying additional user connections and providing the ride-request message to the additional connection users.
  • the user may be presented with an opportunity to modify the trip plan, to request that a ride-share pool be scheduled with any available user, and/or request a standard or non-pool ride-share trip.
  • a connection user may tentatively accept the ride-request pool and/or offer a modification not the trip plan.
  • the connection user may modify a destination location to be between the destination location desired by the user and another destination location desired by the connection user.
  • the connection user may present an alternative time option to the user.
  • the user may accept the connection user’s modification to the trip plan and the process may proceed to the block 610 with the modified trip plan.
  • the process 600 may repeat with a different selection of connection users.
  • the driver may be instructed to pick up both the user and the connection user at the same location and/or to drop off the user and the connection user at the same destination location. In other cases, the driver may be instructed to pick up and/or drop off the user and the connection user at different locations.
  • at least a particular percentage of the trip may overlap. For example, at least 50%, 66%, 75%, 90%, etc., of the trip may overlap.
  • the driver may be selected to service the ride-sharing pool ride based on the location of the driver as determined from geolocation data and/or the geolocation system 210 of the user’s wireless device or user device 102.
  • a trip plan (e.g., starting location, location of one or more destination locations, or one or more drop-off locations) may be provided to the driver.
  • information about each of the users that are part of the ride-sharing pool ride may be provided to the driver, such as profile information for each of the users.
  • a time of pick up for each location included in the ride-sharing pool ride may be provided to the driver. For example, if the ride is scheduled in the future, the driver may receive a time of when to pick up each rider. Further, the driver may be given information of when to start driving to a pickup location based at least in part on the driver’s current location and/or expected location at a particular amount of time prior to when the ride- share pool ride is scheduled to begin.
  • the process 600 may be performed during a trip.
  • the process 600 may be performed during a current trip or after a trip has been scheduled to identify a connection user to join the trip.
  • the connection user may modify the ride to add the user to the ride and the deriver may be instructed to add the user to the connection user’s existing ride by picking up the user along the way or modifying the trip to pick up the user.
  • Figures 7-16 illustrate a series of non-limiting example user interfaces in accordance with certain embodiments disclosed herein.
  • the example user interfaces may be presented by an instance of the ride-sharing application 202 installed, hosted, and/or executed by a user device 102 of a user. Further, the example user interfaces may be presented to a plurality of users each with a user device 102 executing an instance of the ride-sharing application 202.
  • At least some of the user interfaces may be presented to a user requesting a ride-share pool ride, a connection user of the user being offered to join the ride-share pool ride, and/or a driver who is presented with an opportunity to accept a request to provide the ride- share pool service to the user and the connection user (or neighbor) and/or who provides the ride-share pool service to the user and the connection user (or neighbor).
  • FIG. 7 illustrates an example user interface 700 for inviting neighbors to an eligible ride-sharing group in accordance with certain embodiments.
  • the neighbors may be physical neighbors who live next to a user or within a neighborhood where the user resides.
  • the neighbors may be other users connected to a user who shares at least one connection user with the user whether that be an area of residence, work, shopping, entertainment, or any other shared location where both the user and the neighbor or connection user spend an above-threshold period of time.
  • the user interface 700 presents an identity of eligible users who are connected to a user accessing the ride-sharing application 202 and gives the user the opportunity to invite one or more of the eligible users to join the user’s ride-share group.
  • This ride-share group may be used to identify users to join one or more ride-share pool rides with the user.
  • connection users or neighbors may be identified from connections between the connection user and the user on one or more services.
  • the user interface 700 may identify from where the user connection was identified. For example, the connection user 702 may have been identified from the user’s address book, the connection user 704 may have been identified from a messaging service (e.g., WhatsApp®), and the connection user 706 may have been identified from a social networking service (e.g., Facebook®).
  • the user interface 700 may identify how many rides each connection user has taken (e.g., ride count 708) using the ride-sharing service (or has taken over a period of time) and the rating 710 of the connection user. These ratings may be provide by passengers or drivers who provide feedback or rate the connection user during or after use of the ride-sharing service.
  • FIG 8 illustrates an example user interface 800 for displaying one or more ride-sharing messages in accordance with certain embodiments.
  • Each ride sharing message may identify an offer from a user to a connection user to share a specific ride-sharing pool trip or to generally share some set of one or more ride sharing pool trips.
  • the ride-sharing message 802 asks one or more connection users whether they would be willing to share a specific trip from a bar to an area near a coffee shop (e.g., an intersection near the user’s home).
  • the ride-sharing message 802 asks a specific connection user who works with the user whether the connection user would be interested in sharing a daily ride sharing pool to/from work.
  • each connection user may also be a user who can request ride-sharing pools from one or more other connection users and vice versa.
  • each user may be a connection user for another user.
  • FIG. 9 illustrates an example user interface 900 for displaying one or more available ride-sharing pool trips in accordance with certain embodiments.
  • the user interface 900 may include an entry 902 for each of a user’s contacts (e.g., connection users or neighbors) that are scheduling a trip.
  • a user can select one of the trips and indicate if they are available or desire to join the trip as part of a ride- share pool ride.
  • a user can choose to block one of his or her contacts.
  • the blocked contact may be grayed out, made translucent, or otherwise displayed differently from unblocked contacts, or may be removed from the list of contacts.
  • the contact is not informed that he or she is blocked.
  • the contact may receive a message indicating that the user is not available for the ride-pool, or any other type of message that may be supplied to a blocked contact.
  • FIG 10 illustrates an example user interface 1000 for building a ride-sharing pool community in accordance with certain embodiments.
  • a user may add a new contact by selecting an add contact option from a menu 1002.
  • the user may add the new contact by adding one or more identifying prices of information for the contact or connection user, such as name, phone number, address, etc.
  • the user may add one or more contacts by requesting that the ride-sharing application 202 import contacts from one or more other applications or services, such as a neighborhood networking application 204 or a communication application 206.
  • the use may request the contacts be imported using the menu 1002. Further, using the menu 1002, the user can initiate a chat with a connection user or attempt to schedule a ride-sharing pool trip.
  • FIG 11 illustrates an example user interface 1100 for accepting an offer to become neighbors with a user in accordance with certain embodiments.
  • the user interface 1100 may present to a user one or more invitations to connect with one or more other users (e.g., contacts, neighbors, or connection users) through a ride sharing application 202.
  • the user may choose to connect to the user by adding the connection user to a community or a eligible ride-sharing group. Alternatively, the user can choose to discard or ignore an invitation.
  • a user may remove a connection user that was previously part of the user’s community or ride-sharing eligible group.
  • the connection user may be removed altogether, or may be removed from particular eligible ride-sharing groups of the user.
  • a connection user may or may not be informed that the connection user has been removed as a connection or from an eligible ride-sharing group of a user.
  • FIG 12 illustrates an example user interface 1200 for inviting users to a join a ride-share pool trip in accordance with certain embodiments.
  • the user interface 1200 may be a chat system or may provide chat functionality that enables a user to communicate directly with a connection user through the ride-sharing application 202.
  • the user interface 1200 may be for a communication application 206 that enables a user to initiate a ride or access the ride-sharing application 202 via the user interface 1200 of the communication application 206 by, for example, interacting with the ride-request element 1202.
  • Figure 13 illustrates an example user interface for scheduling a ride- share pool trip in accordance with certain embodiments.
  • a user may identify his or her location in field 1302 and may identify a target location using field 1304. Further, the user may add additional target locations as part of a multi-location itinerary by interacting with the interface element 1306.
  • the user interface 1300 may also include bookmarks of oft travelled locations, such as home 1308, work 1310, or other favorite 1312 or oft travelled locations.
  • a set of eligible locations may be displayed in the location list panel 1314 based on the target location searched or entered in the field 1304.
  • FIG 14 illustrates an example user interface 1400 for illustrating a ride-share pool progress in accordance with certain embodiments.
  • the user interface 1400 may indicate a location of the ride-share pool car, a driving path to the user to be picked up, a driving path to a target location to drop off a user, and/or an estimated time of travel along the driving path.
  • the user interface 1400 may provide a status message 1402 indicating the status of the ride-share pool ride.
  • the illustrated example status message 1402 indicates that the driver is waiting to pick up the neighbor or connection user that is joining the user on the ride-share pool ride.
  • Figure 15 illustrates an example user interface 1500 for joining a ride- share pool trip in accordance with certain embodiments.
  • the user interface 1500 may include by included as part of a chat interface (e.g., such as illustrated in Figure 12). Further, the user interface 1500 may include a trip offer panel 1502 that identifies the start and end location of a trip, an estimated time of arrival or drop-off time, and a cost to join the trip. The user may opt to join the ride- share pool trip, or may ignore, decline, or cancel the trip offer.
  • the cost of the ride- share pool trip may be the total price or the price per user. In some cases, the price per user may vary based on the number of users that join the ride-share pool trip.
  • FIG 16 illustrates an example user interface 1600 for identifying connection users in accordance with certain embodiments.
  • the user interface 1600 may present users that have similar routines or travel to similar locations as the user.
  • the similar routines may include more than a threshold number of trips in common and/or trips between locations that are less than a threshold distance from locations the user routinely travels or travels more than a threshold number of times. Additional profile information may be presented for each potential connection user to help the user decide whether to connect to the potential connection users.
  • the user interface 1600 may indicate how the connection user is connected to the user or how the user may know the potential connection user.
  • the user interface 1600 may indicate that the potential connection user lives or works in the same neighborhood as the user, is a friend of a friend, or a friend of an acquaintance, etc. Further, the user interface 1600 may indicate how often the connection user uses the ride-sharing application 202 to schedule a trip, a rating within the ride-sharing application 202, a picture of the potential connection user, a note from the potential connection user indicating how he or she knows the user, or any other information that may help a user decide whether to connection to a potential connection user or neighbor.
  • the example embodiments may include methods, systems, and non-transitory computer- readable media, without limitation.
  • a computer-implemented method may determine eligible ride-sharing connections of a user of a ride-sharing service.
  • the computer- implemented method may be implemented by an interactive computing system comprising one or more hardware processors and configured with specific computer- executable instructions.
  • the method may include: receiving an identifier for each of a set of connections of a user; identifying, from the set of connections of the user, a registered subset of connections of the user that are registered with the ride-sharing service; determining one or more location zones associated with the user; determining, for each connection of the registered subset of connections, one or more location zones associated with the connection; determining, based at least in part on the one or more location zones of the user and the one or more location zones associated with each connection of the registered subset of connections, one or more connections of the registered subset of connections that share at least one location zone with the user to obtain a set of neighbor connections of the user; causing an identity of the set of neighbor connections of the user to be output for display to the user; receiving an indication of a selected set of neighbor connections from the set of neighbor connections that share at least one location zone with the user; and forming an eligible ride-sharing group based on the selected set of neighbor connections that share at least one location zone with the user.
  • the method of the preceding paragraph can include any combination or sub-combination of the following features: where the method further includes accessing one or more user accounts of the user at one or more user connection applications; and determining the set of connections of the user based on the one or more user accounts of the user; where the one or more user connection applications are separate from the ride-sharing service; where the one or more user connection applications comprise a neighborhood networking application or a communication application; where the one or more location zones comprises one or more geographic locations where the user is present for at least a threshold percentage of time within a time period; where the one or more location zones are determined based at least in part on geolocation data obtained from a wireless device of the user; where the one or more location zones are determined based at least in part on usage of a ride sharing application by the user; where the method further includes: verifying, for each connection of the set of neighbor connections, metadata associated with the connection; and removing an unverified connection from the set of neighbor connections, wherein the unverified connection is associated with at least one metadata item from the metadata that
  • the system may include a non-volatile storage configured to store user data of users registered with the ride-sharing service and a hardware processor of an interactive computing system in communication with the non-volatile storage.
  • the hardware processor may be configured to execute specific computer-executable instructions to at least: receive an identifier for each of a set of connections of a user; identify, from the set of connections of the user, a registered subset of connections of the user that are registered with the ride-sharing service; determine one or more location zones associated with the user; determine, for each connection of the registered subset of connections, one or more location zones associated with the connection; determine, based at least in part on the one or more location zones of the user and the one or more location zones associated with each connection of the registered subset of connections, one or more connections of the registered subset of connections that share at least one location zone with the user to obtain a set of neighbor connections of the user; cause an identity of the set of neighbor connections of the user to be output for display to the user; receive an indication of a selected set of neighbor connections from the set of neighbor connections that share at least one location zone with the user; and form an eligible ride-sharing group based on the selected set of neighbor connections that share at least one location zone with the user.
  • the system of the preceding paragraph can include any combination or sub-combination of the following features: where the hardware processor is further configured to execute specific computer-executable instructions to at least: access one or more user accounts of the user at one or more user connection applications; and determine the set of connections of the user based on the one or more user accounts of the user; where the one or more user connection applications comprise a neighborhood networking application or a communication application that is separate from the ride-sharing service; where the one or more location zones comprises one or more geographic locations where the user is present for at least a threshold percentage of time within a time period; where the one or more location zones are determined based at least in part on geolocation data obtained from a wireless device of the user or usage of a ride-sharing application by the user; where the hardware processor is further configured to execute specific computer-executable instructions to at least: verify, for each connection of the set of neighbor connections, metadata associated with the connection; and remove an unverified connection from the set of neighbor connections, wherein the unverified connection is associated with at least one metadata item from the
  • Certain aspects of the present disclosure relate to a method of scheduling a ride-sharing pool via a ride-sharing service.
  • the computer-implemented method may be implemented by an interactive computing system comprising one or more hardware processors and configured with specific computer-executable instructions.
  • the method may include receiving a request to schedule a ride-sharing pool for a user; determining a location of the user at a particular time; determining a target location for the user; accessing an eligible ride-sharing group associated with the user, wherein the eligible ride-sharing group comprises one or more connection users of the user that share at least one location zone with the user; selecting a set of connection users included in the eligible ride-sharing group; accessing user data for each connection user of the set of connection users included in the eligible ride sharing group; based at least in part on the user data for each connection user of the set of connection users, identifying a subgroup of the eligible ride-sharing group comprising connection users that are associated with a threshold likelihood of travelling between the location and the target location at the particular time; and causing an identifier for each connection user included in the subgroup of the eligible ride-sharing group to be output on a display of a wireless device of the user.
  • the method of the preceding paragraph can include any combination or sub-combination of the following features: where the location of the user is determined based at least in part on geolocation data obtained from a wireless device of the user; where the at least one location zone comprises a geographic location where the user is present for at least a threshold percentage of time within a time period; where the subgroup of the eligible ride-sharing group further comprises connection users that are associated with a threshold likelihood of travelling between a first zone that includes the location and a second zone that includes the target location; where the particular time comprises a current time or a scheduled time specified as part of the request to schedule the ride-sharing pool; where identifying the subgroup of the eligible ride-sharing group comprises applying the user data for each connection user included in the set of connection users to a machine learning model configured to predict a likelihood of the connection user travelling between the location and the target location at the particular time; where the method further includes, for each connection user included in the eligible ride-sharing group: determining a current location of the connection user; and adding the connection user to the set
  • the system may include a non-volatile storage configured to store user data of users registered with the ride sharing service and a hardware processor of an interactive computing system in communication with the non-volatile storage.
  • the hardware processor may be configured to execute specific computer-executable instructions to at least: receive a request to schedule a ride-sharing pool; determine a location of the user at a particular time; determine a target location for the user; access an eligible ride-sharing group associated with the user, wherein the eligible ride-sharing group comprises one or more connection users of the user that share at least one location zone with the user; select a set of connection users included in the eligible ride-sharing group; access, from the non-volatile storage, user data for each connection user of the set of connection users included in the eligible ride-sharing group; based at least in part on the user data for each connection user of the set of connection users, identify a subgroup of the eligible ride-sharing group comprising connection users that are associated with a threshold likelihood of travelling between the location and the target location at the particular time; and cause an identifier for each connection user included in the subgroup of the eligible ride-sharing group to be output on a display of a wireless device of the user.
  • the system of the preceding paragraph can include any combination or sub-combination of the following features: where the at least one location zone comprises a geographic location where the user is present for at least a threshold percentage of time within a time period; where the hardware processor is further configured to identify the subgroup of the eligible ride-sharing group by at least applying the user data for each connection user included in the set of connection users to a machine learning model configured to predict a likelihood of the connection user travelling between the location and the target location at the particular time; where the hardware processor is further configured to execute specific computer-executable instructions to at least: determine a connection user location of the connection user; and add the connection user to the set of connection users in response to determining that the connection user location of the connection user is within a location zone that includes the location of the user at the particular time; where the connection user location comprises a predicted location of the connection user at the particular time, and wherein the hardware processor is further configured to execute specific computer-executable instructions to at least predict the predicted location of the connection user by at least applying the user data for the
  • a system or systems may operate according to one or more of the methods and/or computer-readable media recited in the preceding paragraphs.
  • a method or methods may operate according to one or more of the systems and/or computer-readable media recited in the preceding paragraphs.
  • a computer-readable medium or media, excluding transitory propagating signals may cause one or more computing devices having one or more processors and non-transitory computer-readable memory to operate according to one or more of the systems and/or methods recited in the preceding paragraphs.
  • Conditional language such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.
  • the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense, i.e., in the sense of “including, but not limited to.”
  • the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof.
  • the words “herein,” “above,” “below,” and words of similar import when used in this application, refer to this application as a whole and not to any particular portions of this application.
  • words using the singular or plural number may also include the plural or singular number respectively.
  • the word "or” in reference to a list of two or more items covers all of the following interpretations of the word: any one of the items in the list, all of the items in the list, and any combination of the items in the list.
  • the term “and/or” in reference to a list of two or more items covers all of the following interpretations of the word: any one of the items in the list, all of the items in the list, and any combination of the items in the list.
  • certain operations, acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all are necessary for the practice of the algorithms).
  • operations, acts, functions, or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
  • Systems and modules described herein may comprise software, firmware, hardware, or any combination(s) of software, firmware, or hardware suitable for the purposes described.
  • Software and other modules may reside and execute on servers, workstations, personal computers, computerized tablets, PDAs, and other computing devices suitable for the purposes described herein.
  • Software and other modules may be accessible via local computer memory, via a network, via a browser, or via other means suitable for the purposes described herein.
  • Data structures described herein may comprise computer files, variables, programming arrays, programming structures, or any electronic information storage schemes or methods, or any combinations thereof, suitable for the purposes described herein.
  • User interface elements described herein may comprise elements from graphical user interfaces, interactive voice response, command line interfaces, and other suitable interfaces.
  • processing of the various components of the illustrated systems can be distributed across multiple machines, networks, and other computing resources. Two or more components of a system can be combined into fewer components.
  • Various components of the illustrated systems can be implemented in one or more virtual machines, rather than in dedicated computer hardware systems and/or computing devices.
  • the data repositories shown can represent physical and/or logical data storage, including, e.g., storage area networks or other distributed storage systems.
  • the connections between the components shown represent possible paths of data flow, rather than actual connections between hardware. While some examples of possible connections are shown, any of the subset of the components shown can communicate with any other subset of components in various implementations.
  • Embodiments are also described above with reference to flow chart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products.
  • Each block of the flow chart illustrations and/or block diagrams, and combinations of blocks in the flow chart illustrations and/or block diagrams may be implemented by computer program instructions.
  • Such instructions may be provided to a processor of a general purpose computer, special purpose computer, specially- equipped computer (e.g., comprising a high-performance database server, a graphics subsystem, etc.) or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor(s) of the computer or other programmable data processing apparatus, create means for implementing the acts specified in the flow chart and/or block diagram block or blocks.
  • These computer program instructions may also be stored in a non-transitory computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the acts specified in the flow chart and/or block diagram block or blocks.
  • the computer program instructions may also be loaded to a computing device or other programmable data processing apparatus to cause operations to be performed on the computing device or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computing device or other programmable apparatus provide steps for implementing the acts specified in the flow chart and/or block diagram block or blocks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Artificial Intelligence (AREA)
  • Educational Administration (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)

Abstract

La présente invention concerne un système de covoiturage qui peut identifier automatiquement et de manière autonome des connexions d'un utilisateur en accédant à un ou plusieurs services de réseautage tiers utilisés par l'utilisateur. En outre, le système peut déterminer lesquelles des connexions de l'utilisateur passent au moins une quantité de temps de seuil dans une zone géographique où l'utilisateur passe du temps, telle qu'une zone résidentielle ou le lieu de travail de l'utilisateur. Lorsqu'un utilisateur demande un trajet en groupe de covoiturage, le trajet peut être planifié avec une connexion de l'utilisateur, améliorant la sécurité du trajet. Des modèles d'apprentissage machine peuvent être utilisés pour prédire la probabilité qu'une connexion de l'utilisateur emprunte le même itinéraire que l'utilisateur et améliore la sécurité du passager.
PCT/US2021/072544 2020-11-25 2021-11-22 Système de connexion de covoiturage WO2022115846A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202017104761A 2020-11-25 2020-11-25
US202017104911A 2020-11-25 2020-11-25
US17/104,761 2020-11-25
US17/104,911 2020-11-25

Publications (1)

Publication Number Publication Date
WO2022115846A1 true WO2022115846A1 (fr) 2022-06-02

Family

ID=81756179

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/072544 WO2022115846A1 (fr) 2020-11-25 2021-11-22 Système de connexion de covoiturage

Country Status (1)

Country Link
WO (1) WO2022115846A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4361913A1 (fr) * 2022-10-26 2024-05-01 Volvo Car Corporation Optimisation de service de partage de véhicule

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248573A1 (en) * 2005-04-28 2006-11-02 Content Guard Holdings, Inc. System and method for developing and using trusted policy based on a social model
US20110238755A1 (en) * 2010-03-24 2011-09-29 Hameed Khan Proximity-based social networking
US20120142318A1 (en) * 2010-12-05 2012-06-07 Shmuel Okon Method and system for determining and managing the presence and availability of cellular phones
US20160025507A1 (en) * 2014-07-25 2016-01-28 GM Global Technology Operations LLC Carpool finder assistance
US20160320195A1 (en) * 2015-04-29 2016-11-03 Ford Global Technologies, Llc Ride-sharing long-term ride-share groups

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248573A1 (en) * 2005-04-28 2006-11-02 Content Guard Holdings, Inc. System and method for developing and using trusted policy based on a social model
US20110238755A1 (en) * 2010-03-24 2011-09-29 Hameed Khan Proximity-based social networking
US20120142318A1 (en) * 2010-12-05 2012-06-07 Shmuel Okon Method and system for determining and managing the presence and availability of cellular phones
US20160025507A1 (en) * 2014-07-25 2016-01-28 GM Global Technology Operations LLC Carpool finder assistance
US20160320195A1 (en) * 2015-04-29 2016-11-03 Ford Global Technologies, Llc Ride-sharing long-term ride-share groups

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4361913A1 (fr) * 2022-10-26 2024-05-01 Volvo Car Corporation Optimisation de service de partage de véhicule

Similar Documents

Publication Publication Date Title
US11287270B2 (en) Systems and methods for safe route planning for a vehicle
JP7386295B2 (ja) 自律型車両のためのリアルタイム車線変更選択
US10514697B2 (en) Vehicle remote assistance mode
US11131554B2 (en) Systems and methods for vehicle telemetry
US10082793B1 (en) Multi-mode transportation planning and scheduling
US20180300660A1 (en) Systems and methods for provider claiming and matching of scheduled requests
US11604464B2 (en) Virtual valet
US20200026279A1 (en) Smart neighborhood routing for autonomous vehicles
WO2020142548A1 (fr) Système d'itinéraire autonome reposant sur des modèles d'objet d'ia et d'apprentissage automatique
CN113748316B (zh) 用于车辆遥测的系统和方法
CN112446989A (zh) 用于自主运载工具的乘员认证和门操作的方法
CN113874803A (zh) 用于基于远程干预更新车辆操作的系统和方法
US20150371537A1 (en) Traffic surveillance and guidance system
EP3782097A1 (fr) Système de transport à la demande facilitant le fonctionnement de véhicules autonomes de tiers
US11670286B2 (en) Training mechanism of verbal harassment detection systems
US11847385B2 (en) Variable system for simulating operation of autonomous vehicles
WO2020139324A1 (fr) Systèmes et procédés de planification d'itinéraire sûr pour un véhicule
GB2607192A (en) Autonomous vehicle stations
Chai et al. Autonomous driving changes the future
US11507978B2 (en) Dynamic display of driver content
US11367108B1 (en) Dynamic display of route related content during transport by a vehicle
US11620987B2 (en) Generation of training data for verbal harassment detection
WO2022115846A1 (fr) Système de connexion de covoiturage
US11741400B1 (en) Machine learning-based real-time guest rider identification
US11562306B2 (en) Geolocation trajectory based guest rider determination

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21899257

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08/09/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21899257

Country of ref document: EP

Kind code of ref document: A1