DE102015119823B4 - System for state-dependent microinteraction execution - Google Patents

Abstract

A system comprising:a processor (3) configured to:receive a micro-interaction for occupant presentation;collect data regarding vehicle context and/or vehicle system states and/or micro-interaction type prior to presenting the micro-interaction in a vehicle;determine: whether the collected data matches recorded data defining conditions under which a wait command has been issued at a threshold frequency; andautomatically delay the presentation of the microinteraction until a wait condition associated with the wait command is satisfied.

Description

FIELD OF TECHNOLOGY

The invention relates to a system for state-dependent microinteraction execution.

GENERAL STATE OF THE ART

Drivers driving modern vehicles may frequently interact with a vehicle computer system.

Such systems are, for example DE 10 2015 200 065 A1 known.

In CN 1 02 480 560 A discloses a portable navigation device (PND), a mobile terminal corresponding to the PND, an information synchronization system including the PND and the mobile terminal, and an information synchronization method that applies the information synchronization system. The PND system and the mobile device are connected via Bluetooth, so that a user can query unread information at any time; and voice reproduction of contents of the unread information can be realized by a voice reproduction module of the PND.

From interactions as simple as changing a radio station or adjusting a vehicle's air conditioning to responding interactively to the vehicle's computer, drivers have much greater options when interacting with the vehicle's computer than in older vehicles where interaction is limited to simply pressing buttons (e.g. B. Changing the radio station) was limited. Many of the vehicle computers also contain a human-machine interface (HMI) through which the vehicle and the human can communicate. This may include, among other things, touch-selectable input or display and/or audio output and input. The vehicle HMI can present numerous micro-interactions to the driver during a journey, consisting of questions and answers such as “do you want to turn on the lights?” when it gets dark, or “do you want to answer the call now?” when the phone rings, consist. Typically the answer is via a very simple binary choice for a micro-interaction. For example yes/no, now/later, left/right, up/down, on/off etc.

However, many micro-interactions can lead to changes in the state of the vehicle. For example, a question like "do you want the wipers off?" will stop the wiper state, which can be problematic if it is still raining. In such a case, the driver must make a decision about the condition of the wiper, and this decision is better left to a later date in case the question is asked at a time when the driver should be concentrating on the road, such as when a driver just turns left in the middle of traffic. If the driver has to think about the answer to the question, this can be a distraction from more important driving tasks.

Additionally, radio advertisements can announce favorable opportunities such as “if you like this great offer, select xxx-xxx-xxxx”. Next-generation systems using connected vehicle technologies could use these advertisements to display "if you like this great offer, say yes and you will be connected to xxx-xxx-xxxx." Here, too, answers or reactions require active thought processes and considerations to a certain extent, and accordingly, the moments in which the driver is not concentrating on driving should be chosen as the times when the offer is presented.

BRIEF PRESENTATION OF THE INVENTION

According to the invention, a system includes a processor configured to receive micro-interaction for occupant presentation. The processor is also configured to collect data regarding vehicle context and/or vehicle system states and/or microinteraction type prior to presenting the microinteraction to a vehicle. Further, the processor is configured to determine whether the collected data matches recorded data, define the conditions under which a wait command has been issued at a threshold frequency, and then automatically delay the presentation of the microinteraction until one with the Wait condition associated with wait command is fulfilled.

BRIEF DESCRIPTION OF THE DRAWINGS

• 1 shows an example vehicle computer system;
• 2A shows an exemplary microinteraction structure;
• 2 B shows an example process for controlling microinteraction presentation based on state;
• 3 shows an example system that uses microinteractions;
• 4 shows an example microinteraction delay process;
• 5 shows an example process for microinteraction state delay command processing;
• 6 shows an example process for delay condition learning; and
• 7 shows an example process for automatic delay activation.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosed herein; It is to be understood, however, that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of specific components. Therefore, specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art how to make various uses of the present invention.

1 illustrates an example of a block topology for a vehicle based computing system 1 (VCS) for a vehicle 31. An example of such a vehicle based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle in which a vehicle-based computer system is enabled may include an in-vehicle front-end graphical user interface 4. The user may also be able to interact with the interface if, for example, it is equipped with a touch-sensitive screen. In another embodiment, interaction occurs by pressing buttons, a spoken dialogue system with automatic speech recognition and speech synthesis.

In the in 1 1, a processor 3 at least partially controls the operation of the vehicle-based computer system. The processor provided within the vehicle enables on-board processing of commands and routines. The processor is also connected to both a volatile 5 and a non-volatile memory chip 7. In this embodiment, the volatile memory device is a random access memory (RAM) and the non-volatile memory device is a hard disk drive (HDD) or flash memory. In general, non-volatile (non-transient) memory can include any form of memory that retains data when a computer or other device is turned off. This includes, but is not limited to, HDDs, CDs, DVDs, magnetic tapes, solid state drives, portable USB drives, and any other suitable form of non-volatile storage.

The processor is also equipped with a number of different inputs through which the user can communicate with the processor via an interface. In this embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 which may be a touch screen display, and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided to allow a user to switch between different inputs. The input to both the microphone and the auxiliary connection is converted from analog to digital by a converter 27 before being forwarded to the processor. Although not shown, many of the vehicle components and auxiliary components in communication with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to route data to and from the VCS (or components thereof).

Outputs of the system may include, among other things, a display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. The output can also be sent to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation device 60 along the bidirectional data streams with the reference numbers 19 and 21 respectively.

In one embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's nomadic device 53 (e.g., cell phone, smartphone, PDA, or any other device with wireless remote network connectivity) 17. The Nomadic Device may then be used to communicate 59 with a network 61 external to the vehicle 31, for example by communicating 55 with a cell tower 57. In some embodiments, the tower 57 may be a WiFi access point.

An exemplary communication between the nomadic device and the BLUETOOTH transceiver is represented by signal 14.

To pair a Nomadic Device 53 and the BLUETOOTH transceiver 15 can be done through a button 52 or a similar input element can be instructed. Accordingly, the CPU is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a Nomadic Device.

For example, data may be communicated between the CPU 3 and the network 61 using a data plan, data over voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to include an on-board modem 63 with an antenna 18 therein to communicate data between the CPU 3 and the network 61 over the voice band 16. The nomadic device 53 may then be used to communicate with a network 61 outside the Vehicle 31 to communicate 59, for example, through communication 55 with a cell tower 57. In some embodiments, modem 63 may establish communication 20 with tower 57 to communicate with network 61. As a non-exclusive example, the modem 63 may be a USB radio modem and the communication 20 may be a radio communication.

In one embodiment, the processor is equipped with an operating system that includes an API to communicate with modem application software. The modem application software can access an embedded module or firmware in the BLUETOOTH transceiver to perform wireless communications with a remote BLUETOOTH transceiver (such as the one in a Nomadic Device). Bluetooth is a subset of the protocols for IEEE 802 PANs (Personal Area Networks). Protocols for IEEE 802 LANs (Local Area Networks) include WiFi and have significantly similar functionality to IEEE 802 PANs. Both are suitable for wireless communications within a vehicle. Other means of communication that can be used in this area are free space optical messaging (such as IrDA) and non-standard consumer IR protocols.

In another embodiment, the nomadic device 53 includes a modem for voice band or broadband data communications. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented if the owner of the nomadic device can speak over the device while data is being transferred. At other times, when the owner is not using the device, the entire bandwidth (in one example, 300 Hz to 3.4 kHz) can be used for data transfer. Although frequency division multiplexing is quite common in analog mobile communication between the vehicle and the Internet and is still used, it has largely been replaced by hybrids such as Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) for digital mobile communications. These standards are each compliant with ITU IMT-2000 (3G) and provide data rates of up to 2 Mbps for stationary or moving users and 385 kbps for users in a moving vehicle. 3G standards are currently being superseded by IMT-Advanced (4G), which offers 100 Mbit/s for users in a vehicle and 1 Gbit/s for stationary users. If the user has a data plan associated with the Nomadic Device, it is possible that the data plan allows broadband transmission and the system could use a much larger bandwidth (thus speeding up data transfer). In yet another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed on the vehicle 31. In yet another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communicating over, for example, an 802.11g network (i.e., WiFi) or a WiMax network (among others).

In one embodiment, incoming data may be routed through the nomadic device via data over voice or a data plan, through the on-board BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, in the HDD or in another storage medium 7 until the data is no longer needed.

Additional sources that may interface with the vehicle include a personal navigation device 54, for example with a USB connection 56 and/or an antenna 58, a vehicle navigation device 60 with a USB connection 62 or other connection, an on-board GPS device 24 or a remote navigation system (not shown) with connectivity to the network 61. USB is one of a class of serial port protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) series protocols, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) form the backbone of serial standards between devices. Most protocols can be implemented for either electrical or optical communications.

Furthermore, the CPU could be in communication with various other auxiliary devices 65. This Devices can be connected through a wireless 67 or a wired 69 connection. The assistive device 65 may include, among other things, personal media players, wireless medical devices, portable computers, and the like.

Additionally or alternatively, the CPU could be connected to a vehicle-based wireless router 73, for example using a WiFi (IEEE 803.11) transceiver 71. This would allow the CPU to connect to remote networks within the range of the local router 73.

In addition to example processes being executed by a vehicle computing system located on a vehicle, in certain embodiments the example processes may be executed by a computer system in communication with a vehicle computing system. Such a system may include, among other things, a wireless device (e.g., but not limited to a cell phone) or a remote computer system (e.g., but not limited to a server) connected through the wireless device. Collectively, such systems may be referred to as Vehicle Associated Computing Systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of a process depending on the specific implementation of the system. By way of example and without limitation, if a process includes a step of sending or receiving information with a paired wireless device, then it is likely that the wireless device is not currently performing that portion of the process because the wireless device is not communicating information with itself would “send and receive”. It will be apparent to one of ordinary skill in the art when it is inappropriate to apply a specific computer system to a given solution.

In each of the embodiments discussed herein, an exemplary, non-exclusive example of a process performable by a computer system is shown. With respect to each process, it is possible that the computer system executing the process may be configured as a special purpose processor for performing the process for the limited purpose of executing the process. None of the processes need be performed in their entirety, and it is understood that they are examples of types of processes that may be performed to realize elements of the invention. Additional steps can be added or omitted from the example processes if desired.

Current vehicle-based computer software solutions provide external entities and the vehicle computer with ways to interact with vehicle occupants. “Smart” computer systems may require occupant feedback before automatically arming or disarming a system. Advertisers may wish to deliver customized or semi-customized messages to vehicle occupants and provide the option of vehicle occupant responses to advertisements.

Interactions with a vehicle occupant may be known as microinteractions. A microinteraction contains a piece of executable software code with four components: 1) code for asking a question; 2) code to receive a response; and 3) code to execute the result.

2A shows an exemplary microinteraction structure. In the in 2A In the illustrative example shown, a number of microinteraction structures 201 are shown. These are exemplary of a form of microinteraction and do not define all microinteraction types, but rather are provided as examples of the types of vehicle behavior that could be interrupted by the driver according to the illustrative examples shown herein.

As part of the microinteractions, a context for execution is included 203. Based on this context, the vehicle computer can “know” when to present the microinteraction. For example, in the case of a phone call notification, the context may be “immediate” because the phone will only ring for a short period of time. For example, in the context of restaurant advertising, the context might be: "If the restaurant within the user's radius is within 3 miles."

Another component of the micro-interaction contains an initial utterance 205. This could be, for example, the vehicle issue, and in the case of the telephone call it could be: "A call is coming in from <contact name>, would you like to answer it?" In Restaurant example could be: “You are currently <distance> miles from McFoodles, would you like to hear the current promotional price offers?”

Since a microinteraction is often accompanied by a user reaction, the structure can also contain a recognition grammar 207. Different users may answer the same question differently, and because a computer is not “intelligent,” it cannot understand that when answering a question about the offers Promotional price, if no instructions are given, “yes, I would like to listen to the offers at the promotional price” means the same as “yes”. The recognition grammar is intended for this purpose.

Recognition grammar provides specific words that a computer should look for in a response and based on which, if present, the tone of a response is determined. For example, the words “yes,” “yeah sure,” “yeah,” and “ouch yeah” could all be counted as the answer yes, and “no,” “no,” “nope,” and “absolutely not” could all be considered as the answer no. Then, regardless of the contents of the other inmate outputs, the presence of the trigger word could alert the computer which response 209 should be used. This allows a computer to recognize a wide variety of answers without having to consider all the possible ways to answer a question or without requiring a computer that understands complex sentences.

Response logic tells the computer what action to take based on what response. For example, in response to the promotional price offers question, the system may provide a list of offers in response to a "yes" but a different question in response to a "no". Or the system can simply terminate the process if the user says “no”. Similarly, a "yes" in response to the phone call question may result in the call being answered, while a "no" may result in another question, such as whether to send a short text response, whether to forward the call to voicemail whether the connection to the caller should be kept etc.

2 B shows an example process for controlling microinteraction presentation based on state. With respect to the embodiments described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of executing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may temporarily function for another purpose, namely as a special purpose processor, until the method is performed. In another example, where appropriate, firmware running according to a preconfigured processor may cause the processor to function as a special purpose processor provided for the purpose of performing the method or any reasonable variant thereof.

When the microinteraction is processed by the vehicle's computer, the context delivery instructions that may be included are first examined. If a context for presentation instructions is present, the process may examine the current context (weather, occupants, time, position, etc.) to determine whether the context matches the instructional context for delivery 221. If appropriate context is given and driver interaction is permitted 223, the process may next present outputs 225 to the vehicle occupants. This could be, for example, voice, a graphical display, haptic signals, etc.

A user response to the interaction is then received 227, which of course could not contain a response within a given time. This answer is then compared to the recognition grammar to determine which course of action to take next 229. This involves executing both the recognition grammar step and the answer-based step. If another microinteraction is required (return) 231, the process will perform the next microinteraction. Otherwise the microinteraction will be terminated 233 and deleted.

Because answering the question posed by the computer sometimes requires active thought, the driver may not want to answer the question unless his or her attention is not otherwise heavily occupied. Via a proposed Wait-Until-Later (WUL) feature, discussed in more detail in the exemplary embodiments, the driver can delay the response to a micro-interaction, including a fourth piece of code - 4) Code to be executed when waiting is requested.

Microinteractions may originate from the Internet, from one of the devices connected to the vehicle computing system, or from within the vehicle computing system. Regardless of their origin, they all require some form of inmate interaction. Therefore, they are all useful for considering the appropriateness of presentation times.

3 shows an example system that uses microinteractions. In this example, web servers (from which interactions can originate) 301 are connected 303 directly to a vehicle 309 or connected to a driver mobile device 305. The mobile device can then be connected to a vehicle via a connectivity network (e.g. wireless BLUETOOTH interaction) 307.

In the vehicle, a multimedia gateway 309 may include a WUL broker 311 and may also be provided as the mechanism through which the interactions are processed. The gateway 309 can be used to grant access to various vehicle systems 315, 317, 319, 321, 323 via a vehicle network 313 (e.g. the CAN bus). These systems can be used for driver interactions and/or to determine the context for the appropriateness of presentation type decisions.

Even if a vehicle determines that time is appropriate to ask a question or present an option that requires/permits an occupant response, the occupant may not be interested in answering that question, questions of this type, or any questions at all , when the question is presented. There could be various reasons for this, including, but not limited to, occupant mood, vehicle speed, traffic density, weather conditions, additional vehicle occupants, etc. Accordingly, the occupant will be given the opportunity to decline the question. However, if the inmate wishes to respond to the question and simply cannot do so at this time, the inmate will also be presented with the option to wait regarding the question.

• 1) Warten (verwendet integrierte Regeln, um zu bestimmen, worauf gewartet werden soll)
• 2) Eine Minute warten
• 3) Zehn Minuten warten
• 4) Warten auf Anhalten an Kreuzung
• 5) Warten bis nach Kreuzung
• 6) Warten, bis geparkt
• 7) Warten, bis Fahrtrichtungsanzeiger aus
• 8) Warten, bis geradeaus gelenkt wird
• 9) Warten auf geringe Querbeschleunigung
• 10) Warten, bis ich „nicht mehr warten“ sage
• 11) Abbrechen (will diese Mikrointeraktion nicht)
• 12) Warten, bis ich das Auto neu anlasse
• 14) Warten, bis ich mit dem Reden fertig bin
• 15) etc.

One such way to present the option to wait is an exemplary wait-until-later feature, examples of which are shown in the embodiments. The Wait-Until-Later feature executes the microinteraction, but parses the driver input and executes Wait-Until-Later commands before passing them to the microinteraction code. Oral wait-until-later commands include, but are not limited to, the following:

• 1) Wait (uses built-in rules to determine what to wait for)
• 2) Wait a minute
• 3) Wait ten minutes
• 4) Waiting to stop at intersection
• 5) Wait until after the intersection
• 6) Wait until parked
• 7) Wait until direction indicators turn off
• 8) Wait until you steer straight ahead
• 9) Wait for low lateral acceleration
• 10) Wait until I say “wait no more.”
• 11) Cancel (don't want this micro-interaction)
• 12) Wait until I restart the car
• 14) Wait until I'm done talking
• 15) etc.

When the driver issues one of these commands, the microinteraction is suspended. The Wait-Until-Later function monitors events on the vehicle bus, on the Internet and from the driver and applies a set of built-in rules to determine when to resume micro-interaction. The relative importance of rules can be learned online from driver interactions.

In another embodiment of the embodiments, an embedded system learns and tracks the frequency of times and scenarios in which the driver issues the "wait" command. In addition, the relative importance of the microinteractions is categorized. WUL is then automatically activated when the situation tailored to the driver is detected before a micro-interaction is initiated. According to WUL, micro-interactions are then transmitted in a timely manner with a view to increasing driver concentration and increased driver comfort.

The verbal commands may include coherent commands in other modes of communication between the driver and the vehicle. For example, the driver may perform a gesture equivalent to saying “wait,” or may press a button on the steering wheel or control panel, or touch an area of a touch screen.

Example: A driver is waiting in a left-turn lane and begins cooperative acceleration as the vehicle in front of him begins to move. A call arrives on the driver's cell phone and the phone app generates a phone call microexpression for the vehicle computer system. The system interrupts the radio that is currently playing with a live pause and says: “Phone call from your mother, would you like to take it?”

Without the wait-until-later feature, the driver would have to decide whether to say yes or no, but with the wait-for-me feature, the driver says “wait.” The Wait-For-Later feature performs the 4th component of the micro-interaction, which signals the phone app to put the connection on hold and then puts itself on hold. The Wait For Later feature executes built-in rules that cause it to wait until the left turn signal is turned off for 5 seconds, then it resumes executing the microexpression, thereby transferring control to the question component and the driver is notified of: “Phone call from your mother, would you like to answer it Take?" Control is transferred to the response component and the driver answers "yes" and control is passed to the execution component which signals the phone app to take the phone off hold. The driver starts the conversation.

4 shows an example process for microinteraction delay. With respect to the embodiments described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of executing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may temporarily function for another purpose, namely as a special purpose processor, until the method is performed. In another example, where appropriate, firmware running according to a preconfigured processor may cause the processor to function as a special purpose processor provided for the purpose of performing the method or any reasonable variant thereof.

In this exemplary interaction, there is an appropriate context for an interaction presentation, so the process begins with the interactive portion of the microinteraction (i.e., presenting a question and waiting for an answer) 401. If the driver does not issue the "wait" command, but instead responds to the question asked, the process proceeds to the interaction 405. Because the interaction may actually be a set of interactions, checking for the "wait" command 407 may need to be repeated numerous times until the microinteraction occurs is 409.

For example, a driver might answer “no” to the example question about “promotional price offers.” However, if this is not the end of the interaction, the driver may not want to complete the interaction at that time and may instead want to pause the interaction until more time can be allowed to answer follow-up questions. For example, the system might next ask, "Do you want to stop receiving offers from McFoodles?" The driver may have to think about the answer and may say "wait until the vehicle is stopped" to allow for more careful consideration Answer can be made. Once the vehicle is stopped (new delivery condition), interactions in the process may continue until they are completed 409. Any appropriate response-based outcomes may then be performed 411 (e.g., instructing the delivery of McFoodles offers).

As noted above, a condition may be included as part of a wait command 413. On the other hand, a command such as "wait" without a condition may cause a system interruption for a predetermined period of time. Or, to give yet another example, if the condition is still "wait until the vehicle is stopped", receiving the "wait" command may trigger the commonly observed condition.

Once the condition in this example is met 415, the process is resumed 405 and the process of waiting command reception, suspension and resumption can continue until the microinteraction is performed.

5 shows an example process for microinteraction state delay command processing. With respect to the embodiments described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of executing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may temporarily function for another purpose, namely as a special purpose processor, until the method is performed. In another example, where appropriate, firmware running according to a preconfigured processor may cause the processor to function as a special purpose processor provided for the purpose of performing the method or any reasonable variant thereof.

In this illustrative example, the process received a wait command 501 and an accompanying condition 503. A typical wait response is either "wait" or "wait for X to happen". The system can be programmed to receive and respond to any number of conditions, although sometimes the driver may request a condition that the vehicle is not programmed to recognize. In some cases, the driver may simply want to wait for a while before responding.

If the command requires a simple timer 505 (e.g., "wait 10 minutes" or "wait"), the process may next set a timer 507 and the process may then continue when the time is up. The timepiece can be used with For example, preset “wait” commands or may be based on observed user preferences (e.g. the “wait + timer” version of the command always has a duration of 5 minutes).

On the other hand, if a real vehicle state or context state (e.g. “wait until I stop” or “wait until it stops raining,” among others) is set 509, the process may require monitoring one or more vehicle-associated systems 513 to determine the state or context for the delivery. For example, vehicle speed could be monitored to determine when to stop and a rain sensor could be monitored to determine when it is not raining. Once the condition is met 515, the interaction can then be processed 517.

It may also happen that the requested condition is not recognized, for example “wait until the next solar eclipse”. In such a case, the system may ask for a detected condition or may, for example, simply end the interaction 511. In still further cases, unrecognized conditions may be assigned the same default condition as a simple "Wait" command.

6 shows an example process for delay condition learning. With respect to the embodiments described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of executing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may temporarily function for another purpose, namely as a special purpose processor, until the method is performed. In another example, where appropriate, firmware running according to a preconfigured processor may cause the processor to function as a special purpose processor provided for the purpose of performing the method or any reasonable variant thereof.

Because vehicle computer systems are capable of rudimentary "learning," it may be desirable to learn what types of wait commands are issued in connection with which situations and to predictively activate the relevant wait commands even in the absence of instructions from a user. For example, if a user issues the command "wait until it stops raining" whenever a microinteraction is received while it is currently raining, the system can predictively activate this wait command when a context for an interaction implementation is otherwise appropriate and it's raining right now. Similarly, for example, for a user who issues the command "wait until I get off the expressway" very frequently, this wait command is activated predictively whenever an appropriate context is given and the user is currently driving on an expressway.

However, for certain micro-interactions, automatic wait commands can be ignored based on severity. For example, an interaction that says "Your vehicle's gas level is low, would you like to drive to the nearest gas station?" may ignore settings for automatic wait commands because the message is "critical" and should be at the user's discretion to decide whether he wants to consciously ignore the message for now, if desired. Occupant presence can be determined using known techniques, including, but not limited to, identification of occupants based on mobile devices, observation of driving behavior, etc.

In the in 6 In the example process shown, "learning" is performed by the processor by observing and recording frequent instances of "wait" commands, along with the accompanying context. In this example, a “Wait” command is received following the presentation of a microinteraction 601.

In this example, a condition 603 is also received, although this is not necessary. The system is also capable of tracking simple "wait" commands without conditions (also known as a NULL condition) and applying the standard (typically predefined) wait to such commands. In this example, the process begins by recording a type of micro-interaction 605. Micro-interactions can vary widely in type, from coupons and advertisements to vehicle setting adjustments to maintenance notifications, and it is possible to track user behavior based on the micro-interaction type as well as other contextual data to classify. Even within a classification such as “advertising,” there can be numerous real-world subtypes (e.g., fast food, restaurant, drive-thru, Mexican, Italian, American, etc., among others).

In addition to the interaction type, the process may also record state and/or contextual data 607. As noted previously, contextual data includes various factors such as, but not limited to, the number of occupants, weather, time of day, location, traffic volume, etc. State data may include: Among other things, various vehicle states are included (steering wheel tilt, Indicator status, vehicle speed, radioactive/inactive etc.).

A data repository is created and stored for each driver profile in a location accessible to the process. This could be stored locally with respect to a driver account or stored in the cloud. The repository tracks instances of wait commands and/or the accompanying conditions whenever wait commands are issued for the associated contexts. For example, if a driver always issues the command "wait to stop at intersection" when restaurant advertisements are played, the process will record such instances related to restaurant advertisements. Sufficient observations make it clear that with respect to these micro-interactions, only a state of not stopping at an intersection is relevant, therefore other contexts can be ignored, and every time a dining-related micro-interaction occurs, the vehicle learns that the Typically requested wait command is to be activated automatically.

However, it may also happen that the driver only issues the command "wait to stop at intersection" when a micro-interaction (food-based or other) occurs and it is raining or the vehicle is moving above 50 miles per hour. The instances of the wait command would be stored with reference to these contexts/vehicle states, and future micro-interactions (once a learning threshold has been exceeded) will be automatically delayed if it is currently raining or the vehicle is currently moving above 50 miles per hour. It should be noted that “context,” as used herein, is a fairly broad description of various factors and may include vehicle conditions, although vehicle conditions are also discussed separately.

Once the appropriate context/state data has been observed and recorded 607, an instance of the wait command and any accompanying conditions may be added 609 to the data repository for the respective context(s) and/or the respective state(s). Instances of an observed command for a given condition/context/ad type exceeds a predefined threshold 611, an auto-wait feature can be set to the process 613. This causes the system to automatically activate a wait + appropriate context command when the observed threshold conditions occur. Otherwise, the system processes wait command 615 and continues until enough instances of the command occur to reach a threshold.

The threshold may be based on a percentage of the occurrence frequency or, for example, may be based on a total number corresponding to the occurrence frequency. Other threshold values can also be set as appropriate. The system can also record the context/state for instances of microinteractions where no wait commands have been issued, or can expire recorded data when such instances occur, allowing an accurate representation of how frequently a driver issues the wait commands to be observed .

7 shows an example process for automatic delay activation. With respect to the embodiments described in this figure, it is noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of executing some or all of the example methods shown herein. When executing code that provides instructions for performing some or all of the steps of the method, the processor may temporarily function for another purpose, namely as a special purpose processor, until the method is performed. In another example, where appropriate, firmware running according to a preconfigured processor may cause the processor to function as a special purpose processor provided for the purpose of performing the method or any reasonable variant thereof.

This example process activates Wait or Wait+Condition whenever a corresponding scenario occurs in which the driver would typically issue a wait command (based on observations or driver settings). In at least one example, in addition to or instead of tracking the frequency of issued wait commands, the process may also ask the driver whether to set a wait command for a given context or advertisement type following issuance of the wait command. This question can also be delayed until the actual microinteraction is processed, because the question itself is a form of microinteraction and could therefore be dependent on the driver's desire not to interact with the system immediately at the time of occurrence.

In this process, a microinteraction 701 begins based on the occurrence of the appropriate conditions for this specific microinteraction. First, in this example, the process checks the “type” of the interaction 703 (e.g. E.g., among other things, advertising, vehicle systems, etc.). Type definitions can be as granular as they are convenient, so “advertising” may not be sufficiently nuanced and can instead be further categorized as appropriate.

If there is a match 705, which in this case indicates that the "Type" has auto-wait associated, the process will activate the appropriate auto-wait command based on the previously observed behavior 717. If there is no match, the Process next checks the vehicle conditions 707. As previously noted, the process may have observed that if the wipers are activated and the vehicle is currently moving above N miles per hour, the driver always issues a hold command. If the vehicle states match the conditions for issuing a wait command 709, where the interaction type is not relevant, the process can therefore automatically activate a wait command for this micro-interaction 717. Here too, the type of condition activated, if any, can be determined based on observed previous behavior.

Finally, in this example, the system can check the context 711. This can include, among other things, the type of street, the volume of traffic, the weather, the number of people present, the composition of the occupants (e.g. children present), the time of day, the day of the week, etc . contain. If the driver always issues wait commands such as “wait until the vehicle stops” when children are present, the detection of one or more children in the vehicle could trigger the automatic issuance of a wait command + the wait until the vehicle stops condition for any micro-interactions when children are present. If there is a match 713 between any current context and any context for which a relevant pattern has been observed, the process may enable automatic waiting 717. If none of the states/contexts/ad types match any previously observed behavior, for that sufficient data has been collected, the process can perform the microinteraction (which of course may result in the receipt of a wait command initiated by an occupant).

Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the invention. Rather, the words used in the specification are descriptive rather than restrictive, and it is to be understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of various implementing embodiments can be combined to form further embodiments of the invention.

Claims (11)

System that includes: a processor (3) configured to: receive a micro-interaction for inmate presentation; collect data regarding vehicle context and/or vehicle system states and/or microinteraction type prior to presenting the microinteraction in a vehicle; determine whether the collected data matches recorded data defining conditions under which a wait command has been issued at a threshold frequency; and to automatically delay the presentation of the microinteraction until a wait condition associated with the wait command is met. System after Claim 1 , wherein the wait condition is a NULL condition, and wherein the processor (3) is configured to delay the presentation for a predetermined period of time associated with a NULL condition. System after Claim 1 , wherein the condition is associated with a vehicle state change, and wherein the processor (3) is configured to delay the presentation until the vehicle state change occurs. System after Claim 1 , wherein the condition is accompanied by a context change, and wherein the processor (3) is configured to delay the presentation until the context change occurs. System after Claim 1 , where the vehicle context contains a time of day. System after Claim 1 , where the vehicle context includes weather conditions at a vehicle location. System after Claim 1 , where the vehicle context contains a traffic volume at a vehicle position. System after Claim 1 , where the vehicle context includes whether or not children are present as vehicle occupants. System after Claim 1 , where the vehicle context contains a type of road on which the vehicle travels. System after Claim 1 , where the vehicle context contains a day of the week. System after Claim 1 , where the vehicle context contains a vehicle position.

Images