The patent's assignee is
News editors obtained the following quote from the background information supplied by the inventors: "An increasing number of vehicles are being equipped with one or more independent computer and electronic processing systems. Certain of the processing systems are provided for vehicle operation or efficiency. For example, many vehicles are now equipped with computer systems for controlling engine parameters, brake systems, tire pressure and other vehicle operating characteristics. A diagnostic system may also be provided that collects and stores information regarding the performance of the vehicle's engine, transmission, fuel system and other components. The diagnostic system can typically be connected to an external computer to download or monitor the diagnostic information to aid a mechanic during servicing of the vehicle.
"Additionally, other processing systems may be provided for vehicle driver or passenger comfort and/or convenience. For example, vehicles commonly include navigation and global positioning systems and services, which provide travel directions and emergency roadside assistance. Vehicles are also provided with multimedia entertainment systems that include sound systems, e.g., satellite radio, broadcast radio, compact disk and MP3 players and video players. Still further, vehicles may include cabin climate control, electronic seat and mirror repositioning and other operator comfort features.
"However, each of the above processing systems is independent, non-integrated and incompatible. That is, such processing systems provide their own sensors, input and output devices, power supply connections and processing logic. Moreover, such processing systems may include sophisticated and expensive processing components, such as application specific integrated circuit (ASIC) chips or other proprietary hardware and/or software logic that are incompatible with other processing systems in the vehicle or the surrounding environment.
"Today, a user consumes many mobile applications (apps) and cloud services. Consumers expect that these applications and cloud services are available and can be consumed in any connected environment (e.g., a vehicle with network connectivity, an environment with a connected device like a smart phone or a smart TV; and a connection to the internet like a network-connected home or office, or the like). Users expect that just like their voice and data roams with them as when they move from one location to another; their application and cloud service experience, should also roam with them--from one device to another device; and one connected environment to another connected environment. Although the consumer expectation, in general, is that their set of applications and services are available across different screens, devices, and environments, experience roaming imposes higher expectations. Better experience roaming makes the applications and services not only available, but also useful, usable, and desirable in those environments. Conventional solutions have not met that standard.
"A satisfying user experience is more than just being connected to the application or an application being available on a given device in a given environment. Experience satisfaction also includes the way a user feels about the experiential, meaningful and personally relevant aspects of the application. These aspects of the experience need to be preserved even though the user interface and the human-computer interaction may change from device to device or environment to environment The experience needs to dynamically adapt to the user's temporal context as well as take into account the available computing and interaction resources that are available in that connected environment. Hence, experience roaming should go beyond just making an application available. Experience roaming should preserve what makes an application useful, usable, and desirable to a user across their connected environments. The experience should adapt and transform the presentation and expression based on the available resources ensuring that the practical aspects of the experience, such as utility, ease of use, and efficiency are preserved. Again, conventional solutions have not met that standard.
"As an example, a user might be positioned in front of their network-connected TV as one of the devices in their home, which might represent a connected environment. If the user receives an on-TV notification alerting the user to an incoming telephone call, but the connected environment does not enable the user to answer that call in that environment, the environment is not considered to support experience roaming. Genuine experience roaming would enable the phone service experience to roam from a mobile device environment to a TV environment and enable the user to take actions, such as pause the TV, take the call using the TV's available microphone and speaker, and resume watching TV from where they left alter the call was over. Experience roaming should also enable the user to pick a contact from their address book using the interaction resources available in that environment (e.g., the TV remote, voice commands, etc.) and make a phone call while in front of the TV. Experience roaming should mean that the physical connection and access to the mobile device resources, such as the address book on the mobile device, are transparent to the user. If the user is in a connected environment with a TV as a primary display device, the user should still have access to mobile device resources via the TV. These resources should be available to the user on the TV device and any related user interfaces should get presented on the TV in a useable manner so that user can meet their telephony goals in that environment.
"While, some use cases have been addressed in a pairwise manner (e.g., some apps partially roam on some connected device screens and environments), there is no general purpose framework that enables the experience of a user-selected set of applications or services to roam across other connected devices and environments while preserving the apps' utility, usability, and experiential value. The connected vehicle is one such environment where this problem manifests itself when consumers want to bring along their mobile applications and cloud services to their vehicle as a connected environment. Currently, there are three approaches (described below) for making applications available in a vehicle; but, none of these approaches address or support experience roaming.
"One conventional approach is mirroring the mobile phone onto the vehicle's IVI (in-Vehicle Infotainment) systems or head unit display. Simply mirroring the mobile phone interface onto the vehicle's display does not solve the problem or support experience roaming, because the mobile applications, although now available, cannot be consumed as such in a moving vehicle. The high-sensitivity touch user interfaces designed for the mobile device are just not usable as such in a moving vehicle. These interfaces require far too much cognitive, manual, and visual workload to understand what is being presented, how to use it, and how to make sense of their interactions. Further, mirroring only deals with the view part of the application and not the control part of the application. Mirroring does not adapt or transform the user interfaces of these applications into a form that is vehicle-appropriate (e.g., usable in the vehicle); Finally, mirroring does not take into account the changing context of the vehicle-environment; does not leverage the available in-vehicle interaction resources; and does not fake into account the fact that using the application in a moving vehicle increases the manual, visual, and cognitive workload on the driver. Hence, the application interface would have to be re-designed for it to be vehicle-centric, presenting user interfaces and interaction patterns that can be safely used in a moving vehicle. In other words, mirroring only makes applications somewhat available, but does not make them usable or desirable in the vehicle's environment.
"Another conventional approach is to create native instances of the mobile applications that leverage the in-vehicle resources and express the application as vehicle-appropriate. This makes the application useful and usable in the vehicle. However, the problem with this approach is that making mobile applications available as native in-vehicle apps is expensive, time consuming, and requires pair-wise integration between the application and the vehicle's platform and the available in-vehicle human-machine interface (HMI) resources. This means that this solution is available only for the few applications that are handpicked by the vehicle original equipment manufacturers (OEMs) and integrated into the vehicle platform. However, a large number of applications and services at large that a user may want to be available will not be supported.
"A variant to this approach is writing applications using Hypertext Markup Language Rev. 5 (HTML5). This may address the diversity of vehicle platforms problem, as potentially, an HTML5 browser can be made available on all vehicle platforms. However, HTML5 does not make the applications usable as such, because these apps have not been designed for vehicle as the target environment. Thus, the user interfaces that these applications present may not be appropriate for consumption in a moving vehicle.
"Additionally, there is a higher order problem that these approaches cannot solve, that is, providing an integrated user experience. Switching from application to application changes the experience context and consumes all of the available cognitive resources of the driver. Solving context switching across applications is outside the domain of influence of a single application. While natively written applications (hand-picked by the OEM) strive to provide a consistent, OEM specified experience, the experience is not integrated as one continuous whole. Mirroring or HTML5 applications do not even guarantee that any of the user selected applications will have the same interface. Hence, switching between applications results in context switching, which increases the driver workload and renders the applications less usable or desirable.
"In summary, none of these conventional approaches (e.g., mirroring, native apps or non-native apps) address the user experience problem holistically or support genuine experience roaming."
As a supplement to the background information on this patent application, VerticalNews correspondents also obtained the inventors' summary information for this patent application: "A system and method enabling service and application roaming is described herein in various example embodiments. Roaming in the context of voice or telephony generally refers to the extension of connectivity service in a location that is different from the home location where the telephony service was registered. For example, a voice roaming service ensures that as the user roams or moves around, their mobile/wireless telephony device is kept connected to the network, without losing the connection, including when a call is in progress. Voice roaming got extended In conventional telephony services to cover data as well and it meant that the data connection was maintained as the user moved around.
"In the context of a connected vehicle, experience roaming, as described herein, means that the user expects that their entire set of connected life experiences to roam with them. This means they do not have to tell the vehicle who they are, who their friends are, what apps and services they consume on their mobile device, on their tablet or at home or at work. Their entire ecosystem of services and apps remains available and active as they enter their vehicle and drive around; but, the experience gets transformed appropriately, making it vehicle-appropriate and safe.
"The system and method enabling service and application roaming, described herein in various example embodiments, enables the service and app roaming experience to travel with the user, transforming the experience appropriately for consumption (presentation and interaction) in a moving vehicle. The service and application roaming described herein unifies the siloed worlds of various mobile apps, cloud services and vehicle data, sensory intelligence and vehicle services into one consistent experience that is vehicle safe, relevant, and inclusive while addressing distracted driving.
"The system and method enabling service and application roaming, described herein, incarnates the application to deliver a safe, vehicle-centric experience when a smartphone gets paired with the car. In the system model described herein, while the application continues to run on the smartphone, the application experience gets transformed to an implementation presented in a vehicle-safe manner. Additionally, the application experience gets transformed so the user can interact with the application using in-vehicle controls. This application experience transformation is denoted herein as Experience Roaming to suggest that the user gets a consistent experience as they move from the direct use of their mobile device to use of the mobile device in and with a vehicle's available computing environment and interaction resources. This means the user does not have to tell the vehicle who they are, who their friends are, what apps and services they consume on their mobile device, on their tablet or at home or at work. The user gets a consistent experience; because, their devices, data and services get linked to their digital identity and the experience roams with the identity from device to device, location to location, and context to context. The services and applications of the shared ecosystem of services and applications remain available using their digital identity; but, the experiences get appropriately transformed preserving their utility, usability, and desirability.
"The system and method enabling service and application roaming is described herein in various example embodiments. The various embodiments enable experience roaming that is lacking in conventional systems. Instead of just making an application 'available' in a connected environment by mirroring the user interface that was designed for another device, the embodiments described herein decouple the application's user interface from the application's functionality. The embodiments described herein specify the application in terms of its intent(s), that is, the set of tasks that help a user accomplish a certain goal. The application intent could be enabling a user task (or an activity), a service, or delivering a notification to the user. The application's intent can be specified in application messages. These messages can carry the information required to understand the temporal intent of the application in terms of the object (e.g., the noun or content) of the application, the input/output (I/O) modality of the intent/task at hand (e.g., how to present the object to the user), and the actions (e.g., the verbs associated with the application) that can be associated with the task at hand (the intent). As such, an intent as used herein can refer to a message, event, or request associated with a particular task, application, or service in a particular embodiment. One example embodiment provides a Service Creation interface that enables the developer of the application or service to describe their application's intent so that the application's intent can be handled/processed at run-time. The description of the application's intent can include information, such as the Noun (object) upon which the application will act, the Verbs or the action, or actions that can be taken on that Noun, and the Interaction and Launch Directives that specify how to interact with that object and launch a target action or activity (e.g., the callback application programming interface--API to use). In other words, the Service Creation interface enables a developer to describe their application in terms of intents and related semantics using a controlled vocabulary of Nouns and Verbs that represent well-defined concepts specified in an environment-specific ontology. Further, an application intent description can also carry metadata, such as the application's domain or category, context of use, criticality, time sensitivity, etc. enabling the system to deal appropriately with the temporal intent of the application.
"The application's temporal intent description can be received by a particular embodiment as messages. The metadata in the messages can be used to filter, order, and queue the received messages for further processing. The further processing can include transforming the messages appropriately for presentation to the user so that the messages are useful, usable, and desirable. In the context of a vehicle, the processing can also include presenting the messages to the user in a manner that is vehicle-appropriate using a consistent visual language with minimal interaction patterns (keeping only what is required to disambiguate the interaction) that are carefully designed to minimize driver distraction. The processing of ordered application intent description messages includes mapping the particular application intent descriptions to one or more tasks that will accomplish the described application intent. Further, the particular application intent descriptions can be mapped onto abstract I/O objects. At run-time, the abstract I/O objects can be visualized by mapping the abstract I/O objects onto available concrete I/O resources. The various embodiments also perform processing operations to determine where, how, and when to present application information to the user in a particular environment, so that the user can use the application, obtain results, and achieve their goals. Any number of application intent descriptions, from one or more applications, can be requested or published to the various embodiments for concurrent presentation to a user. The various intents received from one or more applications get filtered and ordered based on the metadata, such as criticality and relevance based on the knowledge of the temporal context. The various embodiments compose the application intent descriptions into an integrated user experience employing the environmentally appropriate visual language and interaction patterns. Application intent transitions and orchestration are also handled by the various embodiments. At run-time, the application intent descriptions can be received by the various embodiments using a services gateway as a message receiver.
"In addition to the Service Creation interface, another interface can be provided by an example embodiment. This interface is used before the application intent descriptions are orchestrated in run-time. This interface is implemented in an example embodiment using an experience roaming widget. The widget is used by users to configure the applications and services they want to consume in the vehicle (or other connected environment). In other words, the widget is used by the user to specify the applications or services they want to enable for experience roaming. As part of the interface, the user can configure an access token giving the system the ability to receive application intent descriptions on the user's behalf. The access token enables the user to enable or disable the processing of application intent descriptions that are available for the application being configured. Any application intent description that is disabled by the user or is not subscribed to by the system is filtered out at run-time. Any application intent description that is not disabled by the user and is subscribed to by the system is presented to the user.
"As described in more detail below, an example embodiment of the system and method enabling service and application roaming uses six key services.
BRIEF DESCRIPTION OF THE DRAWINGS
"The various embodiments is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which:
"FIG. 1 illustrates an example embodiment of the components of the system and method enabling service and application roaming;
"FIG. 2 illustrates an example embodiment of the run time model of the service and application roaming system;
"FIG. 3 illustrates an example of the service and application roaming in a social and vehicle related ecosystem;
"FIG. 4 illustrates an example embodiment of the shared ecosystem of services and applications (apps) in an example embodiment;
"FIG. 5 illustrates an example embodiment of the Two-way Messaging Service in an example embodiment;
"FIG. 6 illustrates an example of the service and application roaming system in a vehicle environment in an example embodiment;
"FIG. 7 is a processing flow chart illustrating an example embodiment of a system and method enabling service and application roaming; and
"FIG. 8 shows a diagrammatic representation of machine in the example form of a computer system within which a set of instructions when executed may cause the machine to perform any one or more of the methodologies discussed herein."
For additional information on this patent application, see: Madhok, Ajay; Malahy, Evan; Morris, Ron. System and Method Enabling Service and Application Roaming. Filed
Keywords for this news article include:
Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC
Most Popular Stories
- Prosecutor to Investigate Walmart Police Shooting
- GM to Announce New Jobs in Tennessee
- Emirates Hit Libyan Targets With Airstrikes
- Michael Brown Funeral: Can Americans Change the Script of Violence?
- Smith & Wesson Misses Target
- American Killed With ISIS Fighters in Syria
- Marco Rubio Warns Obama on Deportations
- Hamas Claims Gaza Ceasefire as Victory Over Israel
- Surf's Up! SoCal Prepares for Big Storm Surf
- Ford Hires 300 at Louisville Lincoln Plant