Managing user profiles and preferences in autonomous vehicles

A method includes receiving a message from a requesting device indicating a passenger request for ride services performed by an autonomous vehicle. The system determines, based on the request message, the pooling status of the requested ride services, generates a seat assignment and provides individualized vehicle options to individual users in the vehicle based on profile information in the mission packet.

TECHNICAL FIELD

The present disclosure relates to management of user profiles, and more particularly, to the use of single- and multi-user profiles to enact rider preferences during the use of an autonomous vehicle (AV).

BACKGROUND

Ridehailing companies may utilize user profiles to match users with appropriate vehicles that can accommodate user preferences for vehicle type, seating availability, cargo holding capabilities, and other factors associated with Transportation-As-A-Service. User profiles have also been used to select appropriate vehicles for passengers with disabilities, as described in U.S. Patent Application Publication No. 2017/0316696 A1 (“the '696 publication”). While conventional systems such as those used by ridehail platforms, such as the system disclosed in the '696 publication, utilize a user profile to select an appropriate vehicle for the passenger, conventional profile management systems may not differentiate between multiple passengers traveling under the same profile. Furthermore, conventional systems such as the disclosed system of the '696 publication do not address the use of fully autonomous vehicles (AVs), or address issues associated with the use of single-user and multi-user profiles to manage AV travel. Multi-passenger profiles can be important if a group chooses to travel together with a single account, or if a business uses multi-passenger group profiles for commuting or business travel.

DETAILED DESCRIPTION

Overview

In an example embodiment, a profile determination system may determine whether an AV transportation request is categorized as a pooled-type or non-pooled-type. In a pooled ride share, multiple riders may travel together in the same vehicle, where each rider has their own profile and user preferences. In a non-pooled ride share, multiple riders may travel together in the same vehicle, where a single profile is used to define the parameters of the trip, and store preferences and limitations for the group of riders.

In an embodiment, the system includes an application instantiated on a mobile device or other computing device to match vehicles (service providers) with users (which can include one or more ridehail passengers seeking on-demand transportation. The system may work with a mobility on demand (MoD) platform to connect the ridehail users to an AV in-service near the requesting device, then direct the AV to pick up the passenger and then drop them off at their desired destination. The disclosed system utilizes user profiles and preferences to control vehicle operation for groups of users riding in the same vehicle, including the manner and order in which the AV passengers(s) are picked up, routed, and dropped off, user seat selection, vehicle cabin climate controls, infotainment options, and other user preferences.

A cost-effective driverless AV system makes efficient use of vehicle selection and routing to provide a trip that accommodates individual user preferences. The disclosed system utilizes individual profiles in an AV ridehail pool, and determines the needs of each individual passenger preferences based on unique passenger profiles. In one aspect, the system learns and remembers a particular seat preference, a number of stops the passenger requests during a trip, a preference indicating a maximum and/or minimum number passengers with whom the user prefers to share a trip, and other user preferences.

In an embodiment, the system determines when a ride is in pooled mode or non-pooled mode and generates a mission packet. The mission packet can include, for example, a ride type (pooled or non-pooled), a ride start and end location, rider profiles, and other information. The system may generate the mission packet according to user instructions, determine individual AV's that are available nearby the requesting device that can accommodate the user instructions, and provide the criteria by which the final AV is chosen. The system may choose the AV among available vehicles in the area, and send the mission packet to the AV, where the automotive computer generates a route between passenger pick-up locations and final destinations. Additionally, the system may provide mission packets having information with which the AV may control an AV experience platform, where users may interact with Seat Display Modules (SDMs) to adjust ambient conditions, access entertainment options, and control other trip aspects according to user preferences.

Disclosed embodiments of the present disclosure may provide seamless and individualized user experiences for ridehail users sharing a ride in an AV, with convenient access to SDMs at each seat of the vehicle.

These and other advantages of the present disclosure are provided in greater detail herein.

Illustrative Embodiments

As used herein “rider profile,” “profile,” “user profile,” and “rider preferences,” describe a persistent collection of user preferences and personal information associated with the user. Such preferences can include, but are not limited to, temperature of the vehicle cabin, the volume and nature of ambient music and other entertainment options, physical features of a desirable vehicle, such as size or number of seats, etc., entertainment options recommended to the user during the trip, the number of passengers who may be present during a shared trip, and other options.

Having a single profile that defines the preferences of a group of riders makes it much easier to pool groups into AV vehicles. When the transportation request is non-pooled, i.e., a single user profile sets forth the preferences and desires of the group, the AV size and type preferences are consistent, the passenger count, routing information, drop-off or pick-up order and others can be determined in advance of the request for transportation. A non-pooled profile can also determine which passenger will have the lead or dominant profile and, in some instances, the ability to over-ride and control, many or all, aspects of the AV trip.

A non-pooled profile may be used when a rideshare group requires a single vehicle from the same pick-up location and the same drop-off destination. However, a non-pooled profile is also useful when a group requires, for example, multiple vehicles or a variety of pick-up locations, since the non-pooled user profile informs the AV vehicle in advance of the order and manner of executing the AV trip to assure all of the group's preferences are met.

A non-pooled profile may also be useful when the group takes up less than an entire vehicle. The group's non-pooled profile may be a single profile that includes group preferences.

FIG.1illustrates a functional schematic of an example architecture of an automotive control system100(hereafter “system100”) disposed in an AV105that may be configured and/or programmed to control aspects of the vehicle, in accordance with the present disclosure.

The vehicle105may be any type of passenger vehicle, such as, for example, a sedan, a bus, a van, a truck, etc. In some aspects, vehicle105may operate as a manually-controllable vehicle, an autonomous vehicle where driving functionality is performed entirely by a computing platform onboard and/or offboard the vehicle105, or a semi-autonomous vehicle where aspects of the vehicle control are automatic and other aspects are user-controlled.

The automotive control system100may include an AV experience platform107disposed in communication with and/or operating on the automotive computer110, and may further include vehicle control hardware including, for example, a vehicle powertrain115, one or more driver control components121, vehicle hardware125, sensor(s)130, a mobile device120, and other components not shown inFIG.1.

The automotive computer110depicts a simplified example of an automotive computing system that may include any number of the engine control units. In one embodiment, the automotive computer110may be disposed in and/or distributed in any portion of the vehicle105including, for example, an engine compartment (or elsewhere in the vehicle105), and can include one or more processor(s) (not shown inFIG.1), and a memory (not shown inFIG.1) communicatively coupled to the one or more processor(s). The one or more processor(s) are collectively a hardware device for executing program instructions (aka software), stored in a computer-readable memory (e.g., the memory). The one or more processor(s) may embody a custom made or commercially-available processor, a central processing unit (CPU), a plurality of CPUs, an auxiliary processor among several other processors associated with the automotive computer110, a semiconductor based microprocessor (in the form of a microchip or chipset), or generally any device for executing program instructions.

The automotive computer110may operatively connect to and communicate information with one or more internal and/or external memory devices (not shown inFIG.1) such as, for example, one or more databases, via a storage interface. The storage interface can also connect to one or more memory devices including, without limitation, one or more other memory drives including, for example, a removable disc drive, a vehicle computing system memory, cloud storage, etc., employing connection protocols such as serial advanced technology attachment (SATA), integrated drive electronics (IDE), IEEE-1394, universal serial bus (USB), fiber channel, small computer systems interface (SCSI), etc.

The memory can include random access memory (RAM) such as, for example, dynamic random access memory (DRAM), synchronous random access memory (SRAM), synchronous dynamic random access memory (SDRAM), etc., and read only memory (ROM), which may include any one or more nonvolatile memory elements (e.g., erasable programmable read only memory (EPROM), flash memory, electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), etc.). Moreover, the memory can incorporate electronic, magnetic, optical, and/or other types of non-transitory computer-readable storage media. In some example embodiments, the memory may also include a distributed architecture, where various components are physically situated remotely from one another, but can be accessed by the one or more processor(s).

The instructions in the memory can include one or more separate programs, any of which including an ordered listing of computer-executable instructions for implementing logical functions. Examples of one such program are described in the following sections. The instructions in the memory may further include an operating system (not shown inFIG.1).

The automotive computer110may further include one or more network adaptor(s) (not shown inFIG.1) enabled to communicatively connect the automotive computer110with the one or more network(s). In some example embodiments, the network(s) may be or include a telecommunications network infrastructure. In such embodiments, the automotive computer110can further include one or more communications adaptor(s) (not shown inFIG.1). The communications adapter(s) can include a global positioning system (GPS), cellular, mobile, and/or other communications protocols for wireless communication.

The sensors130may include any number of devices configured and/or programmed to generate signals that help navigate the vehicle105when the vehicle is operating in an autonomous mode. The sensors130may help the vehicle105“see” the roadway and the vehicle surroundings and/or negotiate various obstacles while the vehicle is operating in the autonomous mode. The sensors130may include, for example, a Radio Detection and Ranging (RADAR or “radar”) sensor configured for detection and localization of objects using radio waves, a Light Detecting and Ranging (LiDAR or “lidar”) sensor, a vision sensor system having trajectory, obstacle detection, object classification, augmented reality, and/or other capabilities, and/or the like.

The AV experience platform107may be disposed in communication with mobile device120, which may connect to a Transportation-As-A-Service (TAAS) cloud-based system (e.g., one or more server(s)) and/or may include a TAAS, and provide feedback to the user through a mobile application135(hereafter “application135”). The application135may be instantiated on the mobile device120, and/or may include components distributed to the mobile device120as a service application. The mobile device120may provide updates to a user profile300, (described hereafter with respect toFIG.3A). The application135may receive input from the user and provide the input data to the vehicle control unit165. In one aspect, the vehicle control unit165may alter one or more environmental settings in vehicle105based upon the preferences stored in the user profile (described in greater detail hereafter with respect toFIG.3).

The AV experience platform107may provide access to entertainment features through the application135, including but not limited to, for example, music, movies, and television programs, etc. In an embodiment, the AV experience platform107may be disposed in communication with one or more Seat Display Modules (SDMs)200, as seen inFIG.2. The SDMs200can receive user input and save aspects of the input as new information stored as part of the user profile300. The SDMs200may also provide access to entertainment features available through AV experience platform107.

FIG.2illustrates a functional schematic of an example architecture for the AV experience platform107. In one aspect, the automotive control system100may store information collected from users via one or more network(s)210(discussed in greater detail hereafter inFIG.4). The network(s)210may be disposed in communication with an Electronic Control Gateway (ECG)220. In one aspect, the AV experience platform107may create a user profile (e.g., the user profile300as shown inFIG.3), and store the user profile to a computer-readable memory (not shown inFIG.2) via the one or more network(s)210.

In one example embodiment, the AV experience platform107may receive a ride request and assign a ride to an AV through transmission of the mission packet. A mission packet can include information, including, for example, a ride type (pooled or non-pooled), a ride start and end location, a seat assignment, the user profile300, etc. The automotive control system100may deliver the mission packet to AV experience platform107by an Autonomous Vehicle Platform Interface Module (AVPIM)240through the ECG220.

In one embodiment, the ECG220is connected, via an ethernet switch230, to an auxiliary display module (ADM)250and one or more of the SDMs200. The AV experience platform107may designate any one of the ADM250, SDM200, or AVPIM240as a master node. A designated master node may be responsible for matching user profiles with particular seats, according to where the relevant user is going to sit.

After associating a user profile to a seat, the master node may send the user profile to the SDMs200. Responsive to receiving the mission packet, the SDMs200may display the profile information and trip information on a vehicle display disposed in the AV cabin (not shown inFIG.2), and receive user input that can include confirmation of the trip information. The ECG220may forward the user confirmation to the application135and/or the cloud server(s) via the network(s)210. After the ride is complete (e.g., the AV drops off the user at the intended destination), the master node may update the user profile300by transmitting any new information, preferences, etc., to the network(s)210.

FIG.3Adepicts an example architecture of user profile modes, according to an example embodiment. The user profile modes can include a User Mode307, a Guest Mode308, a Child Mode309, and an Admin Mode310.

Respective user profile modes may be associated with one or more control options or permissions. In one aspect, a user may set or change available permissions through the interface on the SDMs200or the ADM250(seeFIG.2). A system administrator (or “admin”) may utilize the Admin Mode310in order to access all permissions, including a profile creator311with which the admin user may create new user profiles, a profile switcher312for switching profiles between seating positions in the vehicle, an app installation feature313for installing new apps on the system, an Initiate System Update option for updating the system with software, firmware, etc., and an “Act As” feature315that permits the admin user to see a screen display as it would be displayed for a particular user associated with a selected user profile.

In an embodiment, users associated with a user profile300can enter the User Mode307, which allows access to parental controls301, and provide access to applications320that are associated with other user profiles302. Additionally, User Mode307can access a vehicle control app321.

Without a user profile, a guest user may access a Guest Mode308, which may provide reduced access according to rules set in the User Mode307. Example settings or rules can include access permitted to particular users or groups of users, access provided to guest users, and other similar settings. In one example, a guest may access guest applications304, for example. In another example embodiment, a plurality of entertainment options may be tiered such that the Guest Mode308permissions include only certain entertainment options. On the other hand, the User Mode307may include a larger or broader entertainment options list, having a changeable scope of variety, type, etc., of entertainment options. In some aspects, the permissions can be set to a Child Mode309, which may be adjustable in the User Mode307to accommodate parental controls that limit access to options for children operating child applications322. This limitation can be used to prevent children from consuming harmful or undesirable entertainment, for example. The guest mode308may also allow the guest user to provide control inputs using the Vehicle Control App305, which can provide access to climate features associated with the seat position in which the guest may sit. For example, using the Vehicle Control App305, a guest user may enable a seat warmer, cabin climate controls, etc. Other options are possible.

FIG.3Bdepicts an example set of rider permissions associated with a Super User Mode315and the user mode307in a Non-Pooled Rider Mode324. A Super User may have full administrative access and control of the system107. The example depicted inFIG.3Bshows user permissions associated with the Child Mode309, which can provide user controls for setting permissions associated with child applications306. In some aspects, permissions may be available to a user through the SDMs200and/or the ADM250, where the SDMs200and/or the ADM250are configured and/or programmed for the Non-Pooled Ride mode324.

The Non-Pooled Rider Mode324may allow the user profile300associated with a primary user to be accessed by multiple SDM's200. The Super User mode315can alter the mode of each of SDM's200by altering the Non-Pooled Seat Assignment options319. Further, the Super User mode315may provide access to the Parental Control mode316, where the super user may add or subtract child access to entertainment and other options. In some aspects, content available to users in the Child Mode309may be controllable through the parental Control option316, which may be accessible on the SDMs200and/or the ADM250in the Super User mode315. The SDMs200, when in the User Mode307, can also access the Vehicle Control App318and other applications that require association with a user profile.

FIG.4Ais a flow diagram of an example method for controlling vehicle options according to embodiments of the present disclosure.FIG.4Adepicts one example of a sequence of events during the creation of a user profile.

At step405, the Application135may send a mission packet (not shown inFIG.4A) to the ECG220. The mission packet can include user-defined preferences. The ECG220may forward the mission packet to the AVPIM240at step410. The AVPIM240or the master ADM may decrypt the mission packet for use by the system.

The AVPIM240then sends user profile information to the ADM250at step415. For the purposes of this example, the ADM250is designated the master node.

At step420, the ADM250may send a reply to the AVPIM240, with confirmation that the user profile300information was received by the AVPIM240.

At step425, the ADM250may assign a seat for the user by sending the seat assignation to the SDMs200as profile information, and forward the profile mode and blob to the SDM(s)200, with which the SDM(s)200can create the user profile300. The SDMs200may confirm to ADM250that user profile300has been created at step430.

At step435, the ADM250sends confirmation and user profile creation information to the ECG220. At step440, the ECG220may send a confirmation to the application135that user profile300has been created to application135, as well as providing application135with the user's seat assignment.

The user can request a change in seat assignment using the SDMs200, at step445. When a seat change is requested, SDMs200may send the request to the ADM250. The ADM250may determine whether another seat is available. If another seat is available, ADM250may send the new seat assignment to ECG220at step450. The ECG220may also send confirmation of the profile creation and seat assignments to the application135at step455.

The ADM250then confirms the seat change to the SDMs200at step460. The SDM(s)200may then send confirmation to the ADM250at step465, and update the change in seat assignment with the application135at step470.

FIG.4Bcontinues a flow diagram for controlling vehicle options, according to embodiments of the present disclosure. At step475, the AV may determine that the vehicle has completed the transport assignment, signaling an end of the ride. The end of the ride may occur when the AV reaches the target destination, and the riders exit the vehicle.

At step475, responsive to receiving the notification, the AVPIM240may notify the ADM250of the end of the ride. At step476, the ADM may send an acknowledgement of the end of the ride is returned to the AVPIM240.

At step477, the ADM250may send a profile update and cleanup request to the SDMs200. The profile update and cleanup request may update records at each respective SDM200, and purge unneeded profile information from memory.

At step478A, the SDMs200may perform the profile update, and send an updated user profile binary large object (BLOB)300to the ECG220, and send the profile update blob to the ADM250. The ADM may confirm the profile cleanup, and forward the profile update blob to the ECG220at step478B.

At step478C, the ECG220may forward the profile update BLOB to the application135by transmitting the user profile300, via the network(s) for persistent storage and reference.

At step479, the SDMs may perform the profile cleanup by saving the updated profile data to a computer-readable memory, and purging cache in the SDMs by deleting prior user profiles from the system memory.

At step480A, confirmation of the profile cleanup is sent from the SDM(s)200to the ADM250at step480A, then to the ECG220at step480B, and finally to the TAAS135at step480C.

Certain words and terms are used herein solely for convenience and such words and terms should be interpreted as referring to various objects and actions that are generally understood in various forms and equivalencies by persons of ordinary skill in the art. For example, words such as “automobile,” “vehicle,” “car,” and “truck” may be used interchangeably and should be understood in the context of the disclosure. Words such as “controls,” “signals,” “indication,” and “information” may be used interchangeably and should be understood in the context of the disclosure. Furthermore, the word “information” as used herein may refer to various items such as digital data, analog data, audio content, video content, and/or messages. These items may be operated upon by a computer containing a processor. Phrases such as “a signal is transmitted” or “a door being opened” should not be construed exclusively in a singular sense. The phrase should be understood to also encompass “a set of signals” that may be transmitted (concurrently or sequentially) to one door and/or to multiple doors. It should also be understood that the word “example” as used herein is intended to be non-exclusionary and non-limiting in nature. More particularly, the word “exemplary” as used herein indicates one among several examples, and it should be understood that no undue emphasis or preference is being directed to the particular example being described.