A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction b anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent Ides or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the disclosure herein and to the drawings that form a part of this document: Copyright 2010-2012, CloudCar Inc., All Rights Reserved.
This patent document pertains generally to tools (systems, apparatuses, methodologies, computer program products, etc.) for allowing electronic devices to share information with each other, and more particularly, but not by way of limitation, to an ambient intelligent environment supported by a cloud-based vehicle information and control system.
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 lot 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 rid 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 direction 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 scat 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.
Additionally, consumers use their smart phones for many things (there is an app for that). They want to stay connected and bring their digital. worlds along when they are driving a vehicle. They expect consistent experiences as they drive. But, smartphones and vehicles are two different worlds. While the smartphone enables their voice and data to roam with them, their connected life experiences and application (app)/service relationships do not travel with them in a vehicle.
Consider a vehicle as an environment that has ambient intelligence by virtue of its sensory intelligence, IVI (in-vehicle infotainment) systems, and other in-vehicle computing or communication devices. The temporal context of this ambient intelligent environment of the vehicle changes dynamically (e.g., the vehicle's speed, location, what is around the vehicle, weather, etc. changes dynamically) and the driver may want to interact in this ambient intelligent environment with mobile apps and/or cloud based services. However, conventional systems are unable to react and adapt to these dynamically changing environment.
Vehicle users consume navigation and several other in-vehicle services, such as communication and music. These users have relationships outside the vehicle with people, places, and things (e.g., apps and services). Users would like to be always connected with these relationships when the users are in the vehicle or on the move. Today, users have a very limited ability to use these relationships for the exchange of data and messages with these people, places, and things outside the vehicle, in a manner that is easily accessible and vehicle-safe.
Likewise, users have relationships with some others by virtue of owning a vehicle. These relationships include people, places, and things that users visit or have to work with for routine tasks, such as fueling up the vehicle, getting n serviced, its maintenance and repair, its registration, insurance and meeting regulatory compliances like emission checks. Users also have relationships with their vehicle dealer and others involved with the sale, in-life purchases (like options), and resale of the vehicle. The data, information, and messages that are exchanged between with these end points are mostly done in the physical world. Consequently the users do not have whenever and wherever access to their vehicle data, much less a transportable digital identity.
A system and method for providing a secure data container for an ambient intelligent environment is described herein in various example embodiments. An example embodiment reifies the vehicle as a digital identity in its own right and provides mechanisms to unify vehicle related data and associated relationships in a linked data cloud in a manner that is secure (e.g., encrypted) and gives the user the provenance over this unified data. In an example embodiment, a linked data cloud is a data network for exposing, sharing, and connecting items of data, information, and knowledge on the semantic Web using conventional data linking technologies. In other words, the example embodiments enable unified vehicle and driver data to be linked to the vehicle via the cloud. For example, the unified data can include: status attributes of the vehicle, such as its make, model, year, vehicle identification number (VIN), etc.; usage data, such as mileage, fuel level, oil level, etc.; real-time performance data, such as speed, location, traffic, torque, fuel efficiency, bumps jumped over/pothole encountered, etc.; vehicle service and repair data, including warranties and part replacements; vehicle insurance data; vehicle regulatory compliance data, such as registration, smog check, tickets, etc.; driver(s) data, such as identities and information of all who drive the vehicle, routes, destinations, preferences, etc.; the driver(s) qualitative driving data, such as average speed, hard use of brakes, use of signals, violations, etc. It will be apparent to those of ordinary skill in the art that a variety of other data of vehicle and/or the driver(s) can be captured and retained in the unified data and linked to a vehicle. Further, the example embodiment enables the user/driver(s) to link their profile, their calendar, social graph/contacts, and other data from their mobile applications (apps) and cloud services to create custom, personalized datasets of their digital identity and share them with user-configured controls.
In an example embodiment, this unified data set is normalized, homogenized, semanticized, aggregated, encrypted, and stored in association with a persistent digital identity. Entities and relationships in a vehicle data graph get cross-linked and cross-referenced. The vehicle data graph can be annotated, queried, and used as a knowledge endpoint. The various embodiments enable a user to share a subset of the processed unified data with others while retaining and asserting sharing controls, such as access, privacy, expiry, synchronization and usage.
This sharing is enabled by means of a vehicle-based Distributed Shared Data Object that represents a secure data container with bi-directional links to shared data providing a fail-safe mechanism to enforce the controls on the shared data.
The vehicle-based Distributed Shared Data Objects of an example embodiment can be personalized using templates and shared under user control. A vehicle-based Distributed Shared Data Object template can be shared under user-control, at-will or automatically, based on user defined/configured triggers with a dynamically determined set of receivers. The triggers/receivers encapsulate or identify information including:
In other words, the vehicle-based Distributed Shared Data Object and its related service of an example embodiment act like “banker for vehicle data”—a trusted third party that helps vehicle drivers sham their vehicle related and other data in the same way banks help exchange funds or e-mail providers help exchange e-mail and files. The various example embodiments also include the ability to link and nest multi-sourced information To provide context; full addressability of all the shared data in manner that authorization and control enforcement can be built into the vehicle-based Distributed Shared Data Object.
In various typical scenarios enabled by the various embodiments described herein, the vehicle-based Distributed Shared Data Object can be shared with a variety of different types of recipients of the data. Three example types of shared data recipients are described below.
1. Other People (Friends, Family, Colleagues . . . , Someone in the Social Graph of the User/Driver)
As described in more detail below, a user/driver/vehicle occupant (sender) may send a vehicle-based Distributed Shared Data Object to other people (recipients) to share with them a sender's expected time of arrival (ETA) and real-time location including their route so that the recipients can see on a map where the sender is located at a given point of time; and how they are progressing towards their destination. The ETA can be automatically updated based on the driver's real-time location, traffic data, distance left, real speed clocked, time of the day, etc. Additionally, a sender may share their current location on a map (that shows their dynamic or real-time location) and send pictures from their current location (e.g., a scenic route—a picture taken with their vehicle's front camera, or a point of interest (POI) enroute, etc.). Users may also post their vehicle-based Distributed Shared Data Object on post channels like Facebook and Twitter and share their location, or the music they are listening to, their fuel efficiency or any subset of the unified vehicle/driver data that is associated with their vehicle.
2. Service Providers
A user may select a subset of their unified vehicle/driver data and use a vehicle-based Distributed Shared Data Object to send the data subset to a service provider, such as a repair shop. The vehicle-based Distributed Shared Data Object can include the service records and the health records of the vehicle, as this data is captured as part of the unified data associated with the vehicle. Additionally, the service provider can be an insurance company covering the vehicle and the vehicle drivers (the insured) with insurance coverage. The insured can send the insurance company a vehicle-based Distributed Shared Data Object with quantitative and qualitative data, such as vehicle mileage, routes, destinations, time of the clay usage, speed, excessive speed incidents, violation incidents, such as incomplete stops at a STOP sign, making illegal U-turns, not signalling while changing lanes, late entries into exits, distracted driving incidents, such as abnormal steering deviations, sudden speed changes not correlated to traffic, tail-gating (or coming too close) the vehicle ahead, etc. This shared data can enable the insurance company to rate the driver and offer Pay as you Drive (usage-based insurance) or Pay How You Drive (PHYD) Insurance. A Vehicle-based Distributed Shared Data Object can also be sent to a service provider, such as the Department of Motor Vehicles (DMV) with emissions data of the vehicle to perform a virtual smog check. A user may also send a vehicle-based Distributed Shared Data Object to the DMV to get their vehicle registration renewed, etc.
3. Vehicle Dealer and Original Equipment Manufacturer (OEM)
A user can configure an embodiment to automatically send a vehicle-based Distributed Shared Data Object to their vehicle dealer and OEM whenever the vehicle detects an abnormality with the operation or status of the vehicle. For example, the standard subsystems of the vehicle may detect a Low ABS (Anti-Look Braking System) Traction condition. On the occurrence of this condition, the vehicle with one of the embodiments described herein can automatically send a vehicle-based Distributed Shared Data Object to the vehicle dealer and/or OEM with information related to the anomaly detection. In this manner, the vehicle-based Distributed Shared Data Object of an example embodiment can be used to send problem reports and diagnostics data back to the vehicle dealer and/or OEM so the problem/condition can be reported in real-time and analyzed individually or as a whole (aggregated problem/issue data across all cars of a certain model, make, year, etc.).
In all cases, the user maintains provenance over the shared data and the user can configure and assert controls on the data being shared via a set of data sharing controls. The data sharing controls can include: Access, Privacy, Synchronization, Usage, and Expiry controls.
Access controls enable the sharing user to control who gets to access or see what is shared. The various embodiments ensure that the access is secure and the recipient is authenticated so the shared data can only be accessed by the intended recipient.
The data sharing controls can include Privacy controls. Privacy controls enable the sharing user to allow the recipient to control who can view the shared data—the recipient only, or their mutual friends, or any interested parties as determined by the recipient under control of the sharing user. The Privacy controls can also be used to specify whether the recipient can make the data public. The Privacy controls can also be used to enable the recipient to forward the shared data, or the sharing user can choose to make the shared data only for the eyes of the recipient and the shared data cannot be shared by the recipient, and no one else can view the Shared data. In this case, even if the recipient forwards the Distributed Shared Data Object to a friend or someone else, that party to who the Distributed Shared Data Object was forwarded cannot de-reference and access the data.
The data sharing controls can include Synchronization controls enabling the recipient to get a copy of the latest data as it changes in real-time. This means that the user does not have to keep pushing versioned or updated data to the recipient—the synchronization data controls detect when the source data changes and push a new copy. The vehicle-based Distributed Shared Data Object system of an example embodiment implements a push and poll data mechanism to keep the information that is shared synchronized and up-to-date. For example, if the user shares their location and ETA with another user, the ETA and current location (on a map) is updated as the user is driving.
The data sharing controls can include Usage controls. The Usage controls ensure that the shared data is used by the recipients only in the manner specified by the sharing user. The Usage controls enable the sharing user to specify the types of usages of the shared data that are authorized by the sharing user. For example, a user's qualitative driving data can be configured via the usage controls for sharing only to get a PHYD insurance quote from the insurance provider and not to report the user's qualitative driving data to authorities.
The data sharing controls can include Expiry controls. The Expiry controls ensure that the data shared by use of a vehicle-based Distributed Shared Data Object expires at the user-controlled time. After expiration, the recipient does not get to access or see the shared data.
All the data sharing controls are enforced by having a push and pull link between the container (the Distributed Shared Data Object) and the linked data cloud of the vehicle. These embodiments are explained in more detail below.
As described in more detail below, a user can configure a vehicle-based Distributed Shared Data Object to automatically collect their vehicle/driver shared data, or the user can submit the vehicle data manually (through a form submission to a web service), or to receive their vehicle/driver shared data by subscribing to and configuring known data sources. Users can create, edit or choose a Presentation template (e.g., choose a theme, color, font, etc.) from a library of vehicle-based Distributed Shared Data Object profiles, such as templates for sharing ETA information for business, sharing ETA information with friends and family, sharing current location with current music selections; sharing vehicle service records, sharing driver rating information, etc. Users can also customize templates in terms of what dataset to share and the look and feel (e.g., the style or theme of the data presentation) and store the configured templates in their library. Users can also set triggers to auto-share specific vehicle-based Distributed Shared Data Objects based on specified conditions and dynamically picked information and recipient. For example, in an example embodiment, a Trigger÷Action rule can be configured that will perform the following actions in response to the following conditions: when the user leaves for home, send a vehicle-based Distributed Shared Data Object to a family member (as previously specified), wherein the vehicle-based Distributed Shared Data Object specifies the ETA and the current location of the user. Another example would be sharing ETA with other users who are at the destination to which the user is headed, as inferred by an upcoming meeting event in the user's calendar and matching the vehicle's destination to the location of the meeting. Various embodiments can also enable the user to set fine-grained sharing rules for a particular vehicle-based Distributed Shared Data Object. The sharing rules can be specialized on a per attribute and per relationship basis (e.g., share the song I am listening to with my friends, but not with my business colleague). In addition, in a particular embodiment, vehicle-based Distributed Shared Data Objects can be shared in run-time using voice commands. For example, the user can speak a command: Send ETA to John. In response to the voice command, a particular embodiment can send a vehicle-based Distributed Shared Data Object to John, where John is the person on the calendar that the user is headed to meet.
In an example embodiment as described in more detail below, the vehicle-based Distributed Shared Data Object system is a cloud based service that provides at least three basic services: data unification, data sharing, and enforcement of controls. The data unification service is a data pipeline architecture that considers at least three types of data sources: 1) data sources that are structured, such as vehicle data, for which a data adapter exists; 2) sources which are unstructured/manual (form based data submission); and 3) data sources that do not have a data adapter, but provide a pull mechanism/subscription mechanism (e.g., a location feed). The data unification service of an example embodiment receives multi-sourced data, normalizes the received data, semanticizes the data using a vehicle ontology and/or other known ontologies, such as Friend of a Friend (FOAF) as relevant, and homogenizes the data so that the data can be unified as a linked graph. The data is encrypted and stored. The data sharing service of an example embodiment enables a user to configure a vehicle-based Distributed Shared Data Object and specify data sharing rules. At run-time, when a vehicle-based Distributed Shared Data Object is shared, the recipient receives a secure access token as an encrypted link. When the recipient de-references the secure access token (e.g., the user clicks on the link), an embodiment presents the secure access token to the vehicle-based Distributed Shared Data Object delivery gateway (e.g., a content delivery network), which authenticates that the user who is presenting the secure access token is indeed the user to whom the secure access token was sent, authorizes the data to be shared with the recipient (e.g., looks up the data sharing policy referenced by the secure access token), and redirects the user (silently) to the vehicle-based Distributed Shared Data Object. The shared data can be served in the context of a web browser or a social network service like Facebook or the shared data can be viewed, on a mobile device via a browser. The various embodiments enforce sharing controls via the vehicle-based Distributed Shared Data Object, which is a secure container that maintains a push and pull link with the content delivery network to enable the pushing of data updates to the vehicle-based Distributed Shared Data Object. In one embodiment, this push mechanism is implemented using AJAX.
In summary, the various example embodiments provide a system and method of aggregating and unifying a vehicle's data and user data with to persistent digital identity and enriching the data with the user profile and configurable parameters of the user. Further, the various example embodiments enable mechanisms to share a subset of this unified data under user-configured control. The user-configured controls go beyond access control and include privacy, expiry, usage, and synchronization controls.
The various example embodiments described herein provide a system to unify the various data, identifiers, apps, and services, both in-vehicle and outside-the-vehicle. This unified data is linked to the user and the vehicle's digital identity so that the data can be accessed by the user anytime, anywhere, on any device, and shared with others (under user control) in their larger social and vehicle related ecosystem. Further, the various example embodiments enable sharing of the data automatically and autonomously based on certain triggers (e.g., such as the user is likely to be late in arriving at a destination, or the user crossed a geo fence, or is running low on gas, etc.).
The vehicle-based Distributed Shared Data Object comprises the key services described in more detail below.
The various embodiments is illustrated by way of example, and not by of limitation, in the figures of the accompanying drawings in which:
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. It will be evident, however, to one of ordinary skill in the art that the various embodiments may be practiced without these specific details.
As described in various example embodiments, a system and method for providing a secure data container for an ambient intelligent environment are described herein. In one particular embodiment, a system and method for providing a secure data container for an ambient intelligent environment is provided in the context of a cloud-based vehicle information and control ecosystem configured and used as a computing environment with access to a wide area network, such as the Internet. However, it will be apparent to those of ordinary skill in the art that the system and method for providing as secure data container for an ambient intelligent environment as described and claimed herein can be implemented, configured, and used in a variety of other applications and systems.
Referring now to
In an example embodiment the vehicle-based Distributed Shared Data Object system 110 and its related services comprise the key services described below and illustrated in
The Vehicle Reification and Digital Vehicle Registry Service, implemented by the Vehicle Reification and Digital Vehicle Registry Service Module 210 of an example embodiment, associates a persistent digital identifier with a vehicle (or other digital network information resource or endpoint) to create a digital network resource that can be identified and uniquely addressed. The identifier enables data and services to be associated with the digital network information resource (e.g., the vehicle). In one embodiment, the Vehicle Reification and Digital Vehicle Registry Service uses the VIN (vehicle identification number) number of the vehicle as the persistent, non-repudiable identifier to create a new abstract and persistent digital identifier(s) for the vehicle in the network cloud. The persistent digital identifier can be derived from a unique set of information related to a particular digital network information resource or endpoint, such as a vehicle. These persistent digital identifiers are designed so that they are both human friendly and machine friendly. As such, these persistent digital identifiers can be used across all contexts. All of the static attributes of the vehicle, such as the make, model year color, brand, VIN, etc, as well as the vehicle's dynamic attributes, such as mileage, speed, location, destination, rating, emissions, resale value, registration, insurance data, and the like can be associated with the persistent digital identifier of the vehicle. Likewise, the driver(s) data, such as a particular driver's preferences (e.g., mirror position, seat position, music selections, etc.), driver profile, the driver's usage data (e.g., routes, places, violations, ratings, usage of services in car, etc.), and the like can be linked with the persistent digital identifier of the vehicle and thus the vehicle-based digital identity. All of the data associated with a persistent digital identifier is stored behind a privacy barrier in a secure and encrypted manner. Thus, a secure data container with an associated persistent digital identifier for an ambient intelligent environment can be created.
The Vehicle Reification and Digital Vehicle Registry Service of an example embodiment provides all of the services required to reify vehicles as digital endpoints and the services required to register the digital endpoints with the digital vehicle registry in the network cloud. The registration of the digital endpoints and an associated secure data container enables users (e.g., drivers, dealers, resellers, and the like), mobile apps, and services to access, update and share data sets of the secure data container linked to the digital endpoints under the explicit control of the user and/or the original equipment manufacturer (OEM), depending on who has provenance over what data.
The Data Unification Service, implemented by the Data Unification Service Module 220 of an example embodiment, aggregates and homogenizes a user's preferences, profile, usage, data, relationships, calendar, mobile apps, and cloud services consumed by the user (e.g., service identifiers or handles) and links this data to the user's or vehicle's persistent digital identity as created or obtained by the Vehicle Reification and Digital Vehicle Registry Service described above. The Data Unification Service also links the vehicle's real-time data, such as speed, mileage, vehicle sensory and intelligence data, the vehicle's service, repairs and maintenance data to the vehicle's persistent digital identity and makes the linked data available, under user control, with other data owned by the user. As described in more detail below, the Data Unification Service semanticizes the multi-sourced, ontologically diverse data in the dataset using a particular ontology that provides the concepts related to the user resources, the vehicle resources, and their usage in terms of entities and relationships and the network of semantic concepts, their properties, and behaviors to enable contextual exchange of data between user resources, vehicle resources, cloud resources, with the resources of other users, mobile apps, and other services. The Data Unification Service maintains the linked data associated with the vehicle resources and its user(s) resources and provides mechanisms to address and identify specific components of data. The Data Unification Service of an example embodiment can generate a unified database with an ontology of the user, the vehicle, and related resources in terms of entities and relationships and a network of semantic concepts, their properties, and behaviors. The database can act as a knowledge end point that can be queried by and exchange messages with other services.
The various example embodiments described herein provide a system to unify the various data, identifiers, apps, and services, both in-vehicle and outside-the-vehicle. This unified data is linked to the user and the vehicle's persistent digital identity so that the data can be accessed by the user anytime, anywhere, on any device, and shared with others (under user control) in their larger social and vehicle related ecosystem. Further, the various example embodiments enable sharing of the data automatically and autonomously based on certain triggers (e.g., such as the user is likely to be late in arriving at a destination, or the user crossed a geo fence, or is running low on gas, etc.).
A Data Sharing Service, implemented by the Data Sharing Service Module 230 of an example embodiment, enables the user to select a subset of their unified data and to share the selected data subset with others under user control. The ability of the user to share the selected data is enabled by the vehicle-based Distributed Shared. Data Object described herein. For example, the shared data subset could be the data related to the vehicle's current location, the music to which the vehicle occupants are listening, and where the vehicle is currently heading (e.g., pre-defined vehicle destination). This data subset can be shared with their friends, an auto dealer, employer, advertiser, or any other entity or endpoint of the user's choosing. Alternatively, the shared data set could include the vehicle's expected time of arrival (ETA) and the average speed the vehicle is travelling. For example, this data can be shared with a person the vehicle occupants are driving to visit. To simplify data sharing, the system provides a library of Distributed Shared Data Object profiles that have pre-defined data sets. The user can create new profiles, edit, and customize existing profiles.
Apart from enabling the user to select data attributes or data subsets and share the dataset with others, the Data Sharing Service of an example embodiment provides two other capabilities: 1) presentation personalization; and 2) sharing with control. Presentation personalization relates to selecting a template that will be used to present the data the user has selected for sharing. Given that the template is also described as data, the template is also treated at par with the user's other data. The sharing with control capability enables the user to provide, specify, or configure the controls that are applied to the selected data the user wants to share. In one embodiment, these controls include: 1) access control (e.g., with whom does the user want to share the dataset and/or who can access the shared dataset); 2) privacy control (e.g., is the shared dataset only for the eyes of the specified entity or can the specified entity forward the shared dataset to someone else, like a mutual friend); 3) synchronization control (e.g., controls for updating shared data if the data changes); 4) Expiry Control (e.g., controls that specify the period of time for which the data can be shared); and 5) Usage Control (e.g., controls to specify the purpose for which the data can be used). The Data Sharing Service of an example embodiment essentially enables the user to specify and modify the various controls for various types of datasets. The Data Sharing Service also enables the user to customize the specified controls for an individual user, as group of users, a type of user, a service, or the like. As described in more detail below, the data is essentially shared with others using a secure token that needs to be de-referenced to obtain access to the shared data. The enforcement of the controls is performed by another service of the vehicle-based Distributed Shared Data Object system 110 that is described below.
The Data Access/Sharing Control Enforcement Service, implemented by the Data Access/Sharing Control Enforcement Service Module 250 of an example embodiment, enforces the sharing controls described above by acting as a secure content delivery network for the two way links associated with the vehicle-based Distributed Shared Data Object. In other words, the vehicle-based Distributed Shared Data Object represents a secure data container that can only be opened by the intended person, service, and/or endpoint for which the secure data container was configured by the user. The secure data container maintains a push and pull link with the cloud-based Data Access service that uses the two way mechanism to enforce controls. If the vehicle-based Distributed Shared Data Object secure access token is authenticated and authorized, the secure access token redirects the data requests corning from the vehicle-based Distributed Shared Data Object container to a Content Delivery Network/Storage Service that is described below. The Data Access/Sharing Control Enforcement Service records all the data sharing transactions for enabling audits.
The Storage Service, implemented by the Storage Service Module 260 of an example embodiment, encrypts and stores the linked dataset for the vehicle and its user(s) in the network cloud and acts like a Content Delivery Network. The Storage Service acts in concert with the Data Access Service to provide ready-to-be-consumed data securely to the endpoint that presents a valid vehicle-based Distributed Shared Data Object.
The Vehicle-based Distributed Shared Data Object Service, implemented by the Vehicle-based Distributed Shared Data Object Service Module 240 of an example embodiment, is a generalized, extensible service for unifying ontologically diverse, multi-sourced data for the vehicle and its user(s), homogenizing the data, and making the data available for sharing under control of the user wherever and whenever the user chooses, The Vehicle-based Distributed Shared Data Object Service provides a standardized and portable authorization mechanism for sharing the secure data container (e.g., represented by the vehicle-based Distributed Shared Data Object) with user-configured controls. The Vehicle-based Distributed Shared Data Object Service enforces control over the authority (provenance), security, privacy, and rights of shared data expressed in a standard machine-readable format by the vehicle-based Distributed Shared Data Object. The vehicle-based Distributed Shared Data Object is a human and machine-readable document that governs the sharing of particular user-specified vehicle and user datasets. Unlike a conventional Web link, which is essentially a one-dimensional ‘string’ that ‘pulls’ a linked document into as browser, a vehicle-based Distributed Shared Data Object is a graph of metadata (typically in JavaScript Object Notation—JSON or Extensible Markup Language—XML) that can actively control the flow of data from a publisher (e.g., the Data Access/Sharing Control Enforcement Service and the Storage Service) to a subscriber (e.g., the user, service, and/or endpoint to which the vehicle-based Distributed Shared Data Object is sent) by either as ‘push’ or ‘pull’ data transfer mechanism. The data flow is controlled by the terms of the user-configured controls, which can be highly flexible and extensible. For example, in several example embodiments, the vehicle-based Distributed Shared Data Objects can govern a variety of common data sharing scenarios. Several example data sharing scenarios are presented next.
A vehicle-based Distributed Shared Data Object can be used for sharing vehicle location and ETA data with a friend, sharing vehicle performance data with a rating service, sharing vehicle service and repair data with a service provider, sharing driver rating and violations data with parents or insurance providers, sharing, vehicle usage, service and collision data with a reseller, etc.
The vehicle-based Distributed Shared Data Objects can be a key element of digital trust frameworks enabled by connected cars ranging from enabling simple For Your Information (FYI) exchanges to commercial applications, such as Pay How You Drive Insurance to business-to-government services, such as smog, checks.
As an example, the user may explicitly choose to send a vehicle-based Distributed Shared Data Object with their ETA to a contact or configure a service to implicitly/automatically send a vehicle-based Distributed Shared Data Object to a contact based on the calendar and destination information. But, depending on to whom the vehicle-based Distributed Shared Data Object is being sent (e.g., friend, family, business colleague, etc.) and depending on the context of the user (e.g., on a business trip, vacation, location, time/date, status, etc.), the vehicle-based Distributed Shared Data Object can be configured to send different datasets depending on the recipient and the context at the moment the data is ready to be sent. For example, as part of the dataset shared by the vehicle-based Distributed Shared Data Object, some people may only get the ETA information, some others may get the ETA information plus the current location of the vehicle, while some others may get the ETA information plus the current location of the vehicle plus information indicative of the current song being played in the vehicle, etc. This means that the same vehicle-based Distributed Shared Data Object when de-referenced by different people resolves to a different data set. The vehicle-based Distributed Shared Data Object becomes an expression of sharing with control. This means there is a privacy barrier between the user and the vehicle's aggregated profile and what is visible to the person de-referencing the vehicle-based Distributed Shared Data Object at a particular time.
In another scenario, a user can send a vehicle-based Distributed Shared Data Object to a repair/maintenance workshop. When the repair/maintenance workshop dereferences the vehicle-based Distributed Shared Data Object, the repair/maintenance workshop may get access to the appropriate health records, maintenance data, and/or service data of the vehicle that the user has chosen to share with the repair shop. As a result, the vehicle-based Distributed Shared Data Object represents a secure access token that can be shared under the provenance and control of the user with other parties in their ecosystem. The vehicle-based Distributed Shared Data Object of an example embodiment provides the user with mechanisms to control not only the access of the appropriate data by the appropriate recipients, but also provides other data controls, such as privacy (e.g., is the shared data for the recipient's eyes only), expiry (e.g., is the shared data for one view, or will the shared data persist for one hour, one day, or will the shared data persist for a longer period). The vehicle-based Distributed Shared Data Object of an example embodiment also provides other controls including synchronization to take into account that the shared data can change dynamically. For example, the ETA information shared might, change based on live traffic conditions as the user is driving to the destination. Once the vehicle-based Distributed Shared Data Object is shared, the synchronization control remains active and auto-updates the ETA and distance/location information.
Referring now to
Similarly, corresponding portions of the vehicle-based Distributed Shared Data Object system 110 of an example embodiment can be implemented in part on a computing platform of an endpoint 282. Endpoint 282 represents a computing platform of another person, another vehicle, another mobile device, another service, or other type of computing endpoint. In another example embodiment, corresponding portions of the vehicle-based Distributed Shared Data Object system 110 of an example embodiment can be implemented in part on a computing platform of a mobile device, such as a mobile telephone (e.g., iPhone™, Android™ phone, etc.) or a mobile app executing therein. The mobile device executing portions of the vehicle-based Distributed Shared Data Object system 110 can be located proximately to the endpoint 282, coupled to a computing subsystem of the endpoint 282, or the mobile device itself may represent the endpoint 282. The endpoint 282 or the mobile device therein represents the consumer or the recipient of data to be shared by others using the vehicle-based Distributed Shared Data Object system 110 of art example embodiment. In general, the sample system diagram shown in
Referring still to
The vehicle-based Distributed Shared Data Object system 110 of an example embodiment can link the assembled collection of information with a persistent digital identity. The persistent digital identity, generated by the Vehicle Reification and Digital Vehicle Registry Service, associates an identifier with the vehicle 280 to create a digital network resource that can be identified and uniquely addressed. In one embodiment, the Vehicle Reification and Digital Vehicle Registry Service uses the VIN (vehicle identification number) number of the vehicle 280 as the persistent digital identity. In another embodiment, the VIN number can be concatenated (or otherwise combined with) with a user name/identifier, a time/date stamp, a location identifier, a random number, or other information to generate a unique persistent digital identity. This persistent digital identity can be linked to, associated with, combined with, or used to index the assembled collection of information corresponding to the vehicle 280 from which the persistent digital identity was derived. As shown in
When the vehicle-based Distributed Shared Data Object system 110 receives the collection of information and the associated persistent digital identity, the Data Unification Service of an example embodiment operates on the received data to create and register a unified data set associated with the persistent digital identity of the corresponding vehicle 280.
As also shown in
As also shown in
As also shown in
Referring again to
As shown in
As also shown in
Referring now to
Referring now to
Referring now to
Referring now to
Thus, a system and method for providing a secure data container for an ambient intelligent environment are disclosed.
The example computer system 700 includes a data processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 704 and a static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 700 also includes an input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), a disk drive unit 716, a signal generation device 718 (e.g., a speaker) and a network interface device 720.
The disk drive unit 716 includes a non-transitory machine-readable medium 722 on which is stored one or more sets of instructions (e.g., software 724) embodying any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, the static memory 706, and/or within the processor 702 during execution thereof by the computer system 700. The main memory 704 and the processor 702 also may constitute machine-readable media. The instructions 724 may further be transmitted or received over a network 726 via the network interface device 720. While the machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single non-transitory medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” can also be taken to include any non-transitory medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the various embodiments, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” can accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.