Conditionally granting third parties access to vehicle data based on the geographic location of the vehicle relative to the third party

Abstract

The present disclosure relates to vehicle data access by a third party service provider and / or technician based on a triggering action. The triggering action is triggered when a vehicle location matches a geographic criterion. The geographic criterion indicates a geofenced area. Thus, when the vehicle location is within a geofenced area associated with the third party service provider and / or technician, the vehicle data is accessible by the third party service provider and / or technician.

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application is a non-provisional application of and claims priority to U.S. Provisional Patent Application No. 63 / 262,862, entitled "TRIGGERING ACTIONS BASED GEOGRAPHIC INFORMATION," filed on October 21, 2021, the entirety of which is incorporated by reference for all purposes. [Background technology]

[0002] Generally, various vehicles, such as electric vehicles, internal combustion engine vehicles, hybrid vehicles, etc., may be configured with user-specific or configuration information to assist in operation. In certain scenarios, a third party, such as a service provider, may wish to access operating parameters, sensor values, or other information related to the vehicle, such as to monitor or calculate vehicle performance parameters, user-specific information, etc. Vehicles often include hardware and software capabilities that assist with location-based services or have access to computing devices that provide location-based services. For example, a control component of the vehicle may be configured to utilize external information sources, such as a Global Positioning System ("GPS") source, a Wireless Local Area Network (WLAN) access point source, a Bluetooth source, a Radio Frequency Identification (RFID) source, and available location information to determine the vehicle's general location. [Brief description of the drawings]

[0003] The present disclosure is described herein with reference to drawings of certain embodiments, which are intended to be illustrative and not limiting of the disclosure. It is to be understood that the accompanying drawings, which are incorporated in and constitute a part of this specification, are for the purpose of illustrating the concepts disclosed herein and may not be to scale.

[0004] [Figure 1]FIG. 1 is a block diagram of an example environment for providing vehicular data communication access based on geographic information in accordance with one or more aspects of the present application.

[0005] [Diagram 2] FIG. 1 is a block diagram illustrating an environment corresponding to a vehicle in accordance with one or more aspects of the present application.

[0006] [Figure 3A] FIG. 2 is a block diagram illustrating an architecture for implementing a processing component in accordance with an aspect of the present application.

[0007] [Figure 3B] FIG. 1 is a block diagram illustrating an example architecture for implementing vehicle data services in accordance with aspects of the present application.

[0008] [Figure 4A] 2 is a data flow diagram of the example environment of FIG. 1 according to one embodiment.

[0009] [Figure 4B] FIG. 2 is a data flow diagram of the example environment of FIG. 1 including authentication of a third-party service provider according to one embodiment.

[0010] [Diagram 5] 4 is a flow diagram illustrating a routine for accessing vehicle data according to one or more embodiments disclosed herein.

[0011] [Figure 6] 1 is a flow diagram illustrating a routine for authenticating a third-party service provider. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Generally, one or more aspects of the present disclosure relate to configuration and management of data that a vehicle provides to an external source. As an illustrative example, aspects of the present application address managing data communications to provide vehicle data to one or more external sources based on geographic criteria. By way of illustration, the vehicle data may include, but is not limited to, vehicle operation information, vehicle parameters, sensor configuration information, sensor values, environmental information, and the like. The geographic criteria are evaluated by one or more processing components within (or associated with) the vehicle utilizing geographic location information determined by the vehicle. Thus, through processing of the geographic criteria, the vehicle may determine the timing and scope of transmission of vehicle data, such as within a defined geofence corresponding to a service provider.

[0013] According to an example embodiment, one or more aspects of the disclosure relate to the configuration and accessibility of vehicle data communications provided to one or more external sources. The external sources may include service technicians or other third parties. The vehicle may assist in the validation of the external sources. For example, the vehicle may be configured to verify whether the vehicle can transmit vehicle data or whether the vehicle can grant the external source access to the vehicle data. The network service provider may assist in the initial authentication of the external source to access the vehicle data, provide access to the vehicle data for authenticated and authorized users, and further manage the revocation of vehicle data access rights.

[0014] In some embodiments, the information provided by the components may include processed information where a controller, logic unit, processor, etc., has processed sensor information to generate additional information, for example, a vision system may utilize input from one or more camera sensors to provide an output corresponding to identifying environmental conditions that promote the accumulation of objects / obstacles on the dashboard (e.g., processing raw camera image data and generating an output corresponding to the processing of the raw camera image information). The camera sensor may be a sensor component associated with a heater element. In other embodiments, the camera sensor may be separate from the sensor component, such as a component other than the camera sensor, or a vehicle having multiple camera sensors. In yet another example, the control component may utilize additional information obtained from or associated with a positioning system, a calendaring system, or a time-based system. In yet another example, historical information may be incorporated into the control component as a separate source or may be utilized to process at least a portion of a set of sources, such as detected vehicle speed, exterior temperature measurements, windshield wiper operation status, vision system (e.g., camera input), location information system (e.g., GPS system), timing information, radar component operation status, etc.

[0015] Generally, traditional approaches to managing data communication between vehicles and third-party technicians are defined according to the physical proximity of the vehicle and the technician. For example, a customer provides a vehicle to a service center that provides the technician with physical access to the vehicle. In this regard, access to vehicle data, or the granting of client approval to the technician to provide data to the vehicle, is inferred by the physical provision of the vehicle. As a result, the customer / client may need to provide physical access to the vehicle for a longer period of time, since access to vehicle data does not occur until the physical provision of the vehicle is complete. Furthermore, customers often have no mechanism to define or limit the types of vehicle data that individual technicians, or groups of technicians, can access, or to revoke access after the vehicle is provided.

[0016] To address at least some of the inefficiencies identified above, a network service provider can facilitate data communication between a vehicle and one or more external sources, such as a third party, commonly referred to as a technician. The network service provider can authenticate the technician in a manner that allows the technician to access vehicle data or otherwise interface with the vehicle via a vehicle interface. By way of illustration, the vehicle interface can correspond to a particular operational mode that provides one or more interfaces to the technician, such as a diagnostic mode or a repair mode. In other embodiments, the technician can still access at least a portion of the interface via another computing device (e.g., a short-term wireless connection) that may be in relative proximity to the vehicle, such as a laptop, tablet, mobile device, or the like.

[0017] Further, the network service provider can manage access to vehicle data for technicians while protecting the privacy information of the vehicle owner. Specifically, the network service provider can provide geographic criteria, such as geofencing information, to the vehicle. The vehicle can then utilize a local location service (e.g., a GPS component) to evaluate the geographic criteria to trigger vehicle data transfer to one or more third parties. In the context of services related to vehicle service, maintenance, etc., the vehicle can be configured to transmit vehicle data to a designated service center based on the location of the vehicle, such as during travel to a designated service center, when participating in a designated service, etc. At the same time, the vehicle's location, driving route, and driving attributes (e.g., speed, etc.) are not necessarily provided to the designated service center.

[0018] In some embodiments, the vehicle may store geofencing information depending on the location of the vehicle. For example, if the vehicle is located in City A, the geofencing information related to City A, such as geofencing information of one or more approved vehicle service facilities located in City A. In such embodiments, the geofencing information stored in the vehicle may be periodically updated. In some embodiments, if the vehicle moves to a different geographic area, the geofencing information related to the different geographic area may be automatically stored in the vehicle.

[0019] In some embodiments, the network service provider can implement an authentication function to authenticate one or more external sources and provide authorization to the external sources. For example, the network service provider can authenticate a technician and provide authorized information to the vehicle. By way of illustration, the network service provider can identify one or more attributes associated with the technician, such as the technician's credentials. In this example, the network service provider can authenticate the technician by verifying the credentials and authorizing the technician to access vehicle data.

[0020] In some embodiments, the vehicle may include one or more electronic components disposed in or on the vehicle, the electronic components configured to communicate with a network service provider and a computing device. In some embodiments, the vehicle may include the electronic components and a storage for storing vehicle data. In such embodiments, all data generated from the vehicle may be stored in the storage. The data may include, for example, log data generated from sensors installed in the vehicle, engine oil data, coolant temperature, fuel economy, oxygen, knocking information from various sensors, and all processed data related to the vehicle operation. Additionally, the data may include diagnostic data and automated driving (e.g., autonomous driving) related data. In one embodiment, the data may be received from an external device.

[0021] While various aspects are described according to exemplary embodiments and feature combinations, those skilled in the art will appreciate that the embodiments and feature combinations are exemplary in nature and should not be construed as limiting. In particular, aspects of the present application may be applicable to various types of vehicle data or vehicle processes. However, those skilled in the art will appreciate that aspects of the present application are not necessarily limited in application to a particular type of vehicle data, data communication, or exemplary interactions between third parties, customers, and network service providers. Furthermore, to facilitate the exchange of vehicle data and provide selected customization of data transmission in an efficient manner, one or more aspects of the present application further correspond to an exemplary data structure / organization in which vehicle information is transmitted according to an exemplary communication protocol. Such interactions are not to be construed as limiting.

[0022] FIG. 1 illustrates a block diagram of an example environment of a system 100 for providing vehicular data communication access based on geographically-based triggering actions. The system 100 can include a network that connects a set of vehicles 110, a network service provider 120, one or more third-party service providers 130, and one or more computing devices. The components can correspond to software modules implemented or executed by one or more external computing devices, which can also be separate, standalone external computing devices. Thus, the components of the network service provider 120 shall be considered logical representations of services and do not require any particular implementation on the one or more external computing devices.

[0023] As depicted in FIG. 1, a network 150 can connect the devices and modules of the system. A network can connect any number of devices. In some embodiments, the vehicle 110, the network service provider 120, the third-party service provider 130, and the computing device 140 can communicate or exchange data over the network 150. In some embodiments, the network service provider 120 provides network-based services to the vehicle 110, the third-party service provider 130, and the computing device 140 over the network 150. The network service provider 120 can implement network-based services, which refer to a large shared pool of network-accessible computing resources (e.g., compute, storage, network resources, applications, services, etc.), which may be virtualized or bare metal. The network service provider 120 can provide on-demand network access to a shared pool of configurable computing resources that can be programmably provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Thus, the concept of "cloud computing," or "network-based computing," can be thought of both applications delivered as services over a network and the hardware and software of the network service provider that provides those services.

[0024] In some embodiments, network 150 may be a secure network, such as a local area network that securely communicates with network service provider 120 over the Internet. Network 150 may include a wired network, a wireless network, or a combination thereof. For example, network 150 may be a personal area network, a local area network, a wide area network, a terrestrial broadcast network (e.g., for radio or television), a cable network, a satellite network, a cellular network, or a combination thereof. As a further example, network 150 may be a publicly accessible network of linked networks that may be operated by various separate parties, such as the Internet. In some embodiments, network 150 may be a private or semi-private network, such as a corporate or university intranet. Network 150 may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, a fifth generation wireless communication (5G), or other types of wireless networks. Network 150 may use protocols and components for communicating over the Internet or any of the other types of networks previously mentioned. For example, protocols used by network 150 may include HyperText Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), etc. Protocols and components for communicating over the Internet or any of the other types of communications networks previously mentioned are well known to those of skill in the art and will not be described in further detail herein.

[0025] In some embodiments, the vehicles 110 and the computing devices 140 can be connected via a network 160. In such embodiments, the network 160 can include any combination of wired and / or wireless networks, such as, for example, one or more direct communication channels, local area networks, wide area networks, personal area networks, and / or the Internet. In some embodiments, communication between the vehicles 110 and the computing devices 140 can be performed via short-range communication protocols, such as Bluetooth, Bluetooth low energy ("BLE"), and / or near field communication ("NFC"). In some embodiments, the network 160 can be utilized as a backup network for the network 150. For example, if an engineer accesses one of the vehicles 110 via the network 150, the vehicle 110 and the computing device 140 can communicate via the network 160 if the network 150 connection is interrupted or disconnected.

[0026] In some embodiments, network 150, network 160 may include some or all of the same communication protocols, services, hardware, etc. Thus, although the discussion herein may describe communications between vehicle 110 and computing device 140 over network 160, as well as communications between vehicle 110, network service provider 120, third-party service provider 130, and computing device 140, as occurring over network 150, communication of devices and / or network-based services is not limited in this manner. The various communication protocols discussed herein are exemplary only, and the application is not limited in this respect.

[0027] Illustratively, the set of vehicles 110 may correspond to one or more vehicles configured with data storage for storing data generated from electrical components within the vehicles 110. The data may include any processed data related to vehicle operation, such as log data generated from sensors installed in the vehicle, engine oil data, coolant temperature, fuel economy, oxygen, knocking information from various sensors, etc. Additionally, the data may also include diagnostic data and automated driving (e.g., autonomous driving) related data. In one embodiment, the data may be received from an external device.

[0028] In some embodiments, the vehicle 110 includes communication capabilities, including hardware and software, that support interaction over any of a number of communication media and protocols. In particular, the vehicle includes a number of sensors, components, and data stores for acquiring, generating, and maintaining vehicle data, including operational data. In some embodiments, the information provided by the components can include processed information, where a controller, logic unit, processor, etc. processes sensor information to generate additional information, for example, a vision system can utilize input from one or more camera sensors to provide an output corresponding to identifying an environmental condition (e.g., processing raw camera image data and generating an output corresponding to processing the raw camera image information). The camera sensors can be sensor components associated with the vision system to determine vehicle operating conditions, environmental conditions, or other information.

[0029] By way of illustration, network service provider 120 may include vehicle data services 122 that may provide functionality for responding to data received from a vehicle or a certification technician as applied to aspects of the present application. Network service provider 120 may include one or more data stores 124 for storing vehicle diagnostic results relevant to aspects of the present application. Vehicle data services 122 and data stores 124 of FIG. 1 are logical in nature and may be implemented within network service provider 120 in a variety of ways.

[0030] 1, computing device 140 may be any computing device, such as a desktop, laptop, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA / cell phone, cell phone, smartphone, set-top box, voice command device, digital media player, etc. Computing device 140 may execute applications (e.g., browsers, standalone applications, etc.) that allow a user to access interactive user interfaces, view images, analyses, aggregated data, etc., as described herein. In some embodiments, a technician may utilize computing device 140 to authenticate the technician's credentials for access to vehicle 110 and / or access to vehicle data.

[0031] Additionally, the system 100 may include one or more third party service providers 130, which may include any one of a number of services / entities that may be configured to provide input to the network service provider 120 or receive processing results based on process data, such as vehicle data communication configuration information and / or vehicle data management information. Similarly, the third party services 130 may include entities that make vehicle data available, such as third party approved vehicle service facilities, technicians, vehicle data managers, vehicle management organizations, etc.

[0032] For purposes of this description, FIG. 2 illustrates an example environment corresponding to a vehicle 110 in accordance with one or more aspects of the present application. The environment includes a collection of inputs from local sensors 210 that can provide inputs for the operation of the vehicle or for the collection of information described herein. The collection of local sensors 210 can include one or more sensors or sensor-based systems that are on-board the vehicle or accessible to the vehicle during operation. The local sensor or sensor system can be integrated into the vehicle. Alternatively, the local sensor or sensor system can be provided by an interface associated with the vehicle, such as a physical connection, a wireless connection, or a combination thereof.

[0033] In one aspect, the local sensors 210 may include a vision system that provides inputs to the vehicle, such as detection of objects, attributes of the detected objects (e.g., location, speed, acceleration), and the presence of environmental conditions (e.g., snow, rain, ice, fog, smoke, etc.). For example, the vehicle 110 may include multiple cameras, motion sensors 212, a control component 214, and data 216. In this example, the motion sensors 212 may provide vehicle operating parameters to the processing component 220 in real time. The control component 214 may provide data related to control of the vehicle, such as steering direction, acceleration, braking, etc. The data 216 may provide any stored information related to the current vehicle operating environment, such that if the vehicle 110 is traveling on a highway, the data 216 may provide driving information, including the highway's speed limit, number of lanes, etc. The type of data 216 is not limited in this disclosure, and the type of data may be any data available for autonomous driving by utilizing a vision system. In some embodiments, vehicle 110 may rely on such vision systems for defined vehicle operating functions, including capturing visual positioning information, or positioning cues, in accordance with aspects of the present application.

[0034] In yet another aspect, the local sensor 210 can include one or more positioning systems 218 that can obtain reference information from external sources that enable various levels of accuracy in determining the vehicle's positioning information. For example, the positioning system 218 can include various hardware and software components for processing information from GPS sources, wireless local area network (WLAN) access point sources, Bluetooth sources, radio frequency identification (RFID) sources, and the like. In some embodiments, the positioning system can obtain a combination of information from multiple sources. Illustratively, the positioning system 218 can obtain information from various input sources and determine the vehicle's positioning information, specifically the current location altitude. In other embodiments, the positioning system can further determine driving-related operating parameters, such as driving direction, speed, acceleration, and the like. The positioning system 218 can be configured as part of a vehicle for multiple purposes, such as autonomous driving applications, advanced driving, or user-assisted navigation. Illustratively, the positioning system can include processing components and data that aid in identifying various vehicle parameters or process information.

[0035] As yet another aspect, the local sensors can include one or more navigation systems 222 for identifying navigation-related information. Illustratively, the navigation system 222 can obtain positioning information from the positioning system 218 and further identify identified location characteristics or information, such as elevation, road grade, etc. Additionally, the navigation system 218 can identify proposed or intended lane positions on a multi-lane road based on a provided or predicted direction for a vehicle user. Similar to the position information system 224, the navigation system can be configured as part of a vehicle for multiple purposes, such as autonomous driving applications, advanced driving, or user-assisted navigation. The navigation system 222 can be combined or integrated with the positioning system 218. Illustratively, the positioning system 218 can include processing components and data that aid in identifying various vehicle parameters or process information.

[0036] Additionally, the local resources also include one or more processing components 220 that may be hosted on the vehicle or on a computing device (e.g., a mobile computing device) accessible from the vehicle. Illustratively, the processing components 220 may access inputs from various local sensors or sensor systems, process the input data, and store the processed data. For purposes of this application, the processing components 220 are described with respect to one or more functions related to the exemplary aspects. For example, the processing components in the vehicle 110 may verify the authorized entities or individuals that may access the vehicle data, and may further collect and transmit data sets corresponding to requests from the authorized entities and / or engineers. The processing components 220 may communicate with other vehicle components and authorized entities and / or engineers via the com 226. For example, the com 226 may provide verification information or vehicle data by utilizing the network 150, a vehicle communication bus configured to utilize the network 160, or one or more vehicle interfaces.

[0037] Additionally, the environment may include various additional sensor components, or sensing systems, operable to provide information regarding various operating parameters for use according to one or more operating conditions. Additionally, the environment may also include one or more control components for processing the output, such as transmitting data through a communication output, generating data in a memory, transmitting the output to other processing components, etc.

[0038] 3A, an exemplary architecture for implementing the processing component 220 in the vehicle 110 will now be described. The processing component 220 may be part of a component / system that can provide functionality associated with processing and storing vehicle data, as well as receiving technician approved information and thereby providing access to the stored data for a technician.

[0039] The architecture of FIG. 3A is exemplary in nature and should not be construed as mandating any particular hardware or software configuration for the processing component 220. The general architecture of the processing component 220 is depicted in FIG. 3A, which includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As illustrated, the processing component 220 includes a processing unit 302, a network interface 308, a computer-readable media drive 306, and an input / output device interface 304, all of which may communicate with each other via a communication bus. The components of the processing component 220 may be physical hardware components that may include one or more circuits and software models.

[0040] Network interface 308 may provide connectivity to one or more networks or computing systems, such as network 150, network 160 of FIG. 1. Thus, processing unit 302 may receive information and instructions from other computing systems or services via a network. Processing unit 302 may also communicate with memory 310 and may further provide output information via an input / output device interface. In some embodiments, processing components 220 may include more (or less) components than those shown in FIG. 3A.

[0041] The memory 310 may include computer program instructions executed by the processing unit 302 to implement one or more embodiments. Typically, the memory 310 includes RAM, ROM, or other persistent or non-transitory memory. The memory 310 may store an operating system 314 that provides computer program instructions used by the processing unit 302 in the general management and operation of the processing component 220. The memory 310 may further include computer program instructions and other information for implementing aspects of the present disclosure.

[0042] The memory 310 may include a geofence data processing component 316. The geofence data processing component 316 may be configured to verify that the vehicle 110 is entering a geofenced area (e.g., a geographical area) where a third-party service provider, such as an authorized service center and / or technician, may access the vehicle data. In some embodiments, the geofence data processing component 316 receives the geographic criteria from the vehicle data service 122. In some embodiments, the geofence data processing component 316 receives the geographic criteria automatically upon confirmation of a service appointment for the vehicle, upon detection of entry into a geofenced area (e.g., a geographical area), etc. In some embodiments, the geofence data processing component 316 may receive the geographic criteria from multiple third parties authorized by the vehicle data service 122.

[0043] Illustratively, the geographic criteria can be in the form of computer executable data, such as an executable script, that triggers based on at least the geographic boundary information. The trigger can be based on a determination that the vehicle's location has entered within the defined geographic boundary information (e.g., entered a geofence) or that the vehicle's location has ceased to be within the defined geographic boundary information (e.g., exited a geofence). Illustratively, the geographic criteria can include a designation of one or more specific vehicle data information or types of vehicle data that should be transmitted upon satisfaction of the triggering action. It should be noted that the geographic criteria can also include additional or supplemental criteria that can define filtering criteria for the vehicle data, timing data for transmission of the vehicle data, and the like. Additionally, the geographic criteria can incorporate or be supplemented with user profile information that can specify additional parameters related to the transmission of the vehicle data, such as data format preferences, customization information, prohibition information, and the like.

[0044] In some embodiments, the geofence data processing component 316 can access location information using a local location-based services component, such as a GPS component that is part of the vehicle (positioning system 218 and / or location information system 224), or can access location services, such as via a mobile device. In some embodiments, the geofence data processing component 316 processes geographic criteria to determine whether a current location matches one or more geographic criteria. As previously discussed, this can include determining whether a determined location falls within a geofence or will never again fall within a geofence. Illustratively, a match of geofencing information can be characterized as satisfying a triggering action.

[0045] In some embodiments, if the processed location information indicates that a triggering action should occur, the geofence data processing component 316 can select vehicle data to be transmitted to a third-party service provider and / or technician. As noted above, in some embodiments, the geographic criteria can specify the particular data or types of data to be transmitted to the third party. For example, the selected data can correspond to the type of service to be provided, user preferences, service provider preferences, etc. For example, vehicle data can include software version information, diagnostic logs, sensor values, user information, language settings, etc.

[0046] In yet further embodiments, the triggering action may further include a request for information to be provided by a third-party service provider and / or technician, such as a software update, a specific code used by the third party, or an encryption key. Thus, in some embodiments, transmitting vehicle data may include transmitting data from the vehicle to a third-party service provider and / or technician, transmitting data from a third-party service provider to the vehicle, or a combination thereof.

[0047] In some embodiments, the geofence data processing component 316 is configured to verify the location of the vehicle within a geofenced region. For example, if the GPS component (positioning system 218 and / or location information system 224) indicates that the vehicle is within a geofenced region, the geofence data processing component 316 can further verify the accuracy of the location by utilizing wireless local area network (WLAN) access point sources, Bluetooth sources, radio frequency identification (RFID) sources, etc.

[0048] The memory 310 further includes an interface component 318. The interface component 318 can provide various interfaces to allow authorized third party service providers and / or technicians to access vehicle data, executable code, or configurations to aid in diagnosis or repair. In some embodiments, access to vehicle data or data communication is configured as a set of common interfaces that do not require custom computing devices or hardware for technicians. In one embodiment, the interface can correspond to sensor or component values / status, or vehicle network information that provides access to data collected from the vehicle's sensors / components. In some embodiments, the sensors can include hardware and software components that can acquire, generate, or process various operational or environmental information sources configured in the vehicle for various purposes. In some embodiments, the sensors can provide raw collected data to control components as well as other controls for different functions. For example, information provided to the control component by a sensor, controller component, or other processing unit may be related to the operation of the vehicle, such as detected vehicle speed, exterior temperature measurements, windshield wiper operation status, vision systems (e.g., camera input), location information systems (e.g., GPS systems), timing information, component operating status, etc.

[0049] The memory 310 may further include an authentication component 320. In some embodiments, the authentication component 320 requests authorization information from the third-party service provider and / or the technician. In such embodiments, the authentication component 320 may request authentication information from the third-party service provider and / or the technician over the network 150. In some embodiments, the third-party service provider and / or the technician may obtain authentication credentials provided to the network service provider and subsequently receive a token or other semi-persistent information indicating the technician's authorization to access the vehicle 110. In such embodiments, the third-party service provider and / or the technician may provide the authentication token or other semi-persistent information to the authentication component over the network 150 or 160. After receiving the technician's authorization information, the authentication component 320 may provide access to the vehicle data to the third-party service provider and / or the technician.

[0050] An exemplary architecture for implementing the vehicle data service 122 in the network service provider 120 will now be described with reference to Figure 3B. The vehicle data service 122 may be part of a component / system that can provide functionality associated with the third party service provider and / or technician to authenticate the credentials of the third party service provider and / or technician and further provide authorized information to the third party service provider and / or technician.

[0051] The architecture of Figure 3B is exemplary in nature and should not be construed as mandating any particular hardware or software configuration for the vehicle data service 122. The general architecture of the vehicle data service 122 is depicted in Figure 3B, which includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As illustrated, the vehicle data service 122 includes a processing unit 342, a network interface 348, a computer-readable media drive 346, and an input / output device interface 344, all of which may communicate with each other via a communication bus. The components of the vehicle data service 122 may be physical hardware components, which may include one or more circuits and software models.

[0052] Network interface 348 may provide connectivity to one or more networks or computing systems, such as network 150, network 160 of FIG. 1. Thus, computing device 140 may receive information and instructions from other computing systems or services via the network. Vehicle data service 122 may also communicate with memory 350 and provide output information via input / output device interfaces. In some embodiments, vehicle data service 122 may include more (or fewer) components than those shown in FIG. 3B.

[0053] The memory 350 may include computer program instructions that are executed by the processing unit 342 to implement one or more embodiments. Typically, the memory 350 includes RAM, ROM, or other persistent or non-transitory memory. The memory 350 may store an operating system 352 that provides computer program instructions used by the processing unit 342 in the general management and operation of the vehicle data service 122.

[0054] The memory 350 may further include a geofence component 354. The geofence component 354 may include geographic criteria that may determine whether the vehicle has entered a geofenced area in which the vehicle is configured to provide at least a portion of the vehicle data to an authorized third-party service provider and / or technician. For example, the geofence component 354 may automatically receive the geographic criteria upon confirmation of a service appointment for the vehicle, upon detection of entry into a geofenced area (e.g., a geographic area), etc. In some embodiments, the geographic criteria may be in the form of computer-executable data, such as an executable script, that triggers based on at least the geographic boundary information. The trigger may be based on a determination that the location of the vehicle has entered within the defined geographic boundary information (e.g., entered a defined geofence) or that the location of the vehicle has ceased to be within the defined geographic boundary information (e.g., exited a geofence). Illustratively, the geographic criteria may include a designation of one or more particular vehicle data information or types of vehicle data that should be transmitted upon satisfaction of the triggering action. However, the geographic criteria may further include additional or supplemental criteria that may define filtering criteria for the vehicle data, timing data for the transmission of the vehicle data, etc. Additionally, the geographic criteria may incorporate or be supplemented with user profile information that may specify additional parameters related to the transmission of the vehicle data, such as data format preferences, customization information, prohibition information, etc. The geographic criteria may be updated periodically.

[0055] The memory 350 may further include a user authentication component 356 for authenticating a user. A user may be an approved technician and / or one or more technicians of an approved third-party service provider. In some embodiments, the user authentication component 356 may include a list of approved technicians and / or technicians of approved third-party service providers associated with one or more geofenced regions. For example, all technicians of third-party service provider A are associated with a geofenced region of third-party service provider A. In this example, if the vehicle enters the geofenced region of third-party service provider A, the approved technicians associated with third-party service provider A are authorized to access the vehicle data. In some embodiments, the user authentication component 356 provides one or more criteria for authenticating a technician and terminating the technician's authentication. For example, the criteria may be based on the technician's physical location. In this example, if the vehicle enters a geofenced area associated with third-party service provider A, only technicians in a particular area, such as a service facility of third-party service provider A, may access the vehicle data. In another embodiment, when a technician from third-party service provider A leaves third-party service provider A's facility, the technician's certification ends. Additionally, the criteria may be based on type of service, such that only technicians who specialize in services requested by the vehicle owner (e.g., user) are certified. These criteria are provided for illustrative purposes only, and this disclosure is not intended to be limiting on the type or number of criteria.

[0056] In some embodiments, the user authentication component 356 authenticates the authentication information (e.g., credentials) of the third-party service provider and / or the technician. In such embodiments, the user authentication component 356 receives authorized information, such as a token, of the third-party service provider and / or technician to ensure that the authentication authority allows access to the requested vehicle and vehicle data access type. For example, the user authentication component 356 can verify that the technician has a valid subscription and the technician's subscription / entitlement. For example, the user authentication component 356 can verify that the requesting technician has sufficient credentials to provide the requested service to the vehicle. In another embodiment, the user authentication component 356 can also determine whether the service / access requested by the technician corresponds to the type of service to be performed on the vehicle and whether the requested service is not duplicated or redundant. In yet a further embodiment, the user authentication component 356 further determines whether the requested service is characteristic of an identified technician's behavioral patterns (e.g., services related to various vehicles) that can be characterized as appropriate, potentially harmful, requiring verification from the customer, etc. Additionally, the user authentication component 356 can verify aspects of the requested vehicle, the device utilized by the technician, etc.

[0057] In some embodiments, the user authentication component 356 sends a notification or command to the vehicle 110 indicating that the data access communication has been approved. Additionally, the user authentication component 356 can provide a notification or credentials to the technician that allow access to the vehicle data. The notification can be provided via various communication channels, such as email, short message service, a mobile application, in-vehicle, etc. In some embodiments, the data access approval can be associated with additional approval parameters, including, but not limited to, access duration, type of data accessed, revocation criteria (e.g., criteria that result in automatic revocation of rights), customer notification parameters, etc. In some embodiments, the geofence component 354 is configurable with a customer profile, which can specify default values ​​for the approval parameters. In other examples, the customer can be prompted to provide additional data access parameters.

[0058] Exemplary interactions between the network service, individual third parties, and individual vehicles will now be described with reference to Figure 4A. Although only a single interaction is illustrated, the present application is not limited to a single interaction. Rather, individual iterations of the illustrated interactions may result in different exchanges of vehicle information based on the selected vehicle's configuration, various vehicle data requests, monitoring or diagnostic applications performed by the network service, etc.

[0059] At (1), the network service transmits the geographic criteria to the vehicle. By way of illustration, the network service may transmit the geographic criteria to the vehicle based on a request from a user associated with the vehicle, such as by issuing a service request to a third party or by sending a request directly to the network service. In other embodiments, a third-party service may prompt the network service to transmit the geographic criteria to the vehicle, such as upon confirmation of a service reservation for the vehicle. In other embodiments, the network service provider may transmit the geographic criteria for multiple third parties independent of a request or scheduled service. Additionally, the vehicle may be provided with the geographic criteria, such as when it detects that it has entered a geographic area (e.g., a city or region).

[0060] Illustratively, the geographic criteria may be in the form of computer executable data, such as an executable script, that triggers based on at least the geographic boundary information. The trigger may be based on a determination that the vehicle's location has entered within the defined geographic boundary information (e.g., entered a geofence) or that the vehicle's location has ceased to be within the defined geographic boundary information (e.g., exited a geofence). Illustratively, the geographic criteria may include a designation of one or more particular vehicle data information or types of vehicle data that should be transmitted upon satisfaction of the triggering action. It should be noted that the geographic criteria may further include additional or supplemental criteria that may define vehicle data filtering criteria, vehicle data transmission timing data, and the like. For example, the additional or supplemental criteria may include information to temporarily stop transmitting data if the vehicle temporarily leaves the geofence (e.g., test drive) or otherwise maintain the vehicle in a current state. Additionally, the geographic criteria may incorporate or be supplemented with user profile information that may specify additional parameters related to vehicle data transmission, such as data format preferences, customization information, prohibition information, and the like.

[0061] At (2), the vehicle may obtain vehicle location information by utilizing a local location-based service component, such as a GPS component that is part of the vehicle, to access location information or by accessing a location service, such as via a mobile device (e.g., positioning system 218 and / or location system 224). At (3), the vehicle validates the vehicle location information against geographic criteria. For example, a processing component 220 in the vehicle may process the geographic criteria to determine whether a current location matches one or more of the geographic criteria. As previously discussed, this may include determining whether the determined location falls within a geofence or will never again fall within a geofence. By way of illustration, matching geofencing information may be characterized as satisfying a triggering action. In some embodiments, the vehicle may validate the vehicle's location within a geofenced area. For example, if the GPS component (positioning system 218 and / or location information system 224) indicates that the vehicle is within a geofenced area, the geofence data processing component 316 can further verify the accuracy of the location by utilizing wireless local area network (WLAN) access point sources, Bluetooth sources, radio frequency identification (RFID) sources, etc.

[0062] (4) If the processed location information indicates that a triggering action should occur, vehicle 110 may select vehicle data to be transmitted to the third-party service. As noted above, in some embodiments, the geographic criteria may specify the particular data or types of data to be transmitted to the third party. For example, the selected data may correspond to the type of service to be provided, user preferences, service provider preferences, etc. For example, vehicle data may include software version information, diagnostic logs, sensor values, user information, language settings, etc.

[0063] In yet further embodiments, the triggering action may further include a request for information to be provided by a third party, such as a software update, a specific code utilized by the third party, or an encryption key. Thus, transmitting vehicle data in some embodiments may include transmitting data from the vehicle to a third party, transmitting data from a third party to the vehicle, or a combination thereof.

[0064] At (5), the vehicle 110 and the third-party service provider exchange selected data. The transmission of data may be selected according to any number of communication methods and protocols. For example, the vehicle may establish a communication channel via short-range radio frequency transmission based on geographic proximity to the designated service provider. In other embodiments, the vehicle may encrypt, compress, or otherwise process the transmissions between the service provider and the vehicle.

[0065] In some embodiments, the vehicle 110 exchanges vehicle data with an approved third-party service provider. In such embodiments, the vehicle data service 122 may include a list of approved technicians and / or technicians of approved third-party service providers associated with one or more geofenced regions. For example, all technicians of third-party service provider A are associated with a geofenced region of third-party service provider A. In this example, if the vehicle enters a geofenced region of third-party service provider A, the approved technicians associated with third-party service provider A are approved to access the vehicle data. In some embodiments, the vehicle data service 122 provides one or more criteria for authenticating a technician and terminating the technician's authentication. For example, the criteria may be based on the technician's physical location. In this example, if the vehicle enters a geofenced area associated with third-party service provider A, only technicians in a particular area, such as a service facility of third-party service provider A, may access the vehicle data. In another embodiment, authentication of a technician from third-party service provider A terminates when the technician leaves third-party service provider A's facility (e.g., leaves a geofenced area associated with third-party service provider A's facility). Additionally, the criteria may be based on the type of service, such that only technicians who specialize in the services requested by the vehicle owner (e.g., user) are authenticated. These criteria are provided for illustrative purposes only, and this disclosure is not intended to be limiting on the type or number of criteria.

[0066] In some embodiments, network 160 can be utilized as a backup network for network 150. For example, if an engineer accesses one of the vehicles 110 via network 150, then if the network 150 connection is interrupted or disconnected, the vehicle 110 and computing device 140 can communicate via network 160.

[0067] 4B, an exemplary interaction between a network service, an individual third party, and an individual vehicle will now be described according to one embodiment. Although only a single interaction is illustrated, the present application is not limited to a single interaction. Rather, each iteration of the illustrated interaction may result in different exchanges of vehicle information based on the selected vehicle's configuration, various vehicle data requests, monitoring or diagnostic applications performed by the network service, etc.

[0068] At (1), the network service transmits the geographic criteria to the vehicle. By way of illustration, the network service may transmit the geographic criteria to the vehicle based on a request from a user associated with the vehicle, such as by issuing a service request to a third party or by sending a request directly to the network service. In other embodiments, a third-party service may prompt the network service to transmit the geographic criteria to the vehicle, such as upon confirmation of a service reservation for the vehicle. In other embodiments, the network service provider may transmit the geographic criteria for multiple third parties independent of a request or scheduled service. Additionally, the vehicle may be provided with the geographic criteria, such as when it detects that it has entered a geographic area (e.g., a city or region).

[0069] Illustratively, the geographic criteria can be in the form of computer executable data, such as an executable script, that triggers based on at least the geographic boundary information. The trigger can be based on a determination that the vehicle's location has entered within the defined geographic boundary information (e.g., entered a geofence) or that the vehicle's location has ceased to be within the defined geographic boundary information (e.g., exited a geofence). Illustratively, the geographic criteria can include a designation of one or more particular vehicle data information or types of vehicle data that should be transmitted upon satisfaction of the triggering action. It should be noted that the geographic criteria can also include additional or supplemental criteria that can define filtering criteria for the vehicle data, timing data for transmission of the vehicle data, and the like. Additionally, the geographic criteria can incorporate or be supplemented with user profile information that can specify additional parameters related to the vehicle data transmission, such as data format preferences, customization information, prohibition information, and the like.

[0070] At (2), the vehicle may obtain vehicle location information by utilizing a local location-based service component, such as a GPS component that is part of the vehicle, to access location information or by accessing a location service, such as via a mobile device (e.g., positioning system 218 and / or location system 224). At (3), the vehicle validates the vehicle location information against geographic criteria. For example, a processing component 220 in the vehicle may process the geographic criteria to determine whether a current location matches one or more of the geographic criteria. As previously discussed, this may include determining whether the determined location falls within a geofence or will never again fall within a geofence. By way of illustration, matching geofencing information may be characterized as satisfying a triggering action. In some embodiments, the vehicle may validate the vehicle's location within a geofenced area. For example, if the GPS component (positioning system 218 and / or location information system 224) indicates that the vehicle is within a geofenced area, the geofence data processing component 316 can further verify the accuracy of the location by utilizing wireless local area network (WLAN) access point sources, Bluetooth sources, radio frequency identification (RFID) sources, etc. At (4), the vehicle 110 can send a verification of the vehicle location information to the vehicle data service 122.

[0071] At (5), the third-party service provider 130 and / or the technician may request authentication of the third-party service provider 130 and / or the computing device 140 (e.g., the technician's device accessing the vehicle data) to access the vehicle. Illustratively, the technician and / or the third-party service provider may obtain authentication credentials provided to the network service provider and subsequently receive a token or other semi-persistent information indicating the technician's authentication to access the vehicle 110. In one embodiment, as illustrated below, the authenticated third-party service provider 130 and / or the computing device 140 does not have access to the respective vehicle until the authenticated third-party service provider 130 and / or the technician is authorized (by utilizing the computing device 140). To request authorization, the third-party service provider 130 and / or the technician may issue an access request from the network service (by utilizing the computing device 140) and provide the specified information. For example, in one embodiment, the technician can provide vehicle identifier information such as VIN, customer contact information or identifiers such as customer email address, phone number, and other security or access information. Additionally, the technician can provide additional information regarding the access such as reason for access, time of access, scope of access, etc. Submission of the request can be facilitated through an API or other interface. In some embodiments, the access request can be pre-populated with profile information that defines default information such as access duration or specified restrictions on data access rights (e.g., vehicle logs pertaining to certain components or excluding others).

[0072] At (6), the vehicle data service 122 receives the request and the third-party service provider 130 and / or the technician validates the token (using the computing device 140) to ensure that the authentication authority allows access to the requested vehicle and vehicle data access type. For example, the vehicle data service 122 can validate that the third-party service provider 130 and / or the technician (using the computing device 140) has a valid subscription and technician subscription / entitlements. For example, the vehicle data service 122 can validate that the requesting technician has sufficient credentials to provide the requested service to the vehicle. In another embodiment, the vehicle data service 122 can also determine whether the service / access requested by the technician corresponds to the type of service to be performed on the vehicle and whether the requested service is non-duplicative or non-redundant. In yet a further embodiment, the vehicle data service 122 further determines whether the requested service is characteristic of an identified technician's behavioral patterns (e.g., services related to various vehicles) that can be characterized as appropriate, potentially harmful, requiring verification from the customer, etc. Additionally, the vehicle data service 122 can verify aspects of the requested vehicle, the device utilized by the technician, etc.

[0073] At (7), the vehicle data service 122 can send a notification or command to the vehicle indicating that the data access communication has been approved. Additionally, the vehicle data service 122 can provide (utilizing the computing device 140) a notification or credentials to the third party service provider 130 and / or an engineer that allow access to the vehicle data. The notification can be provided via various communication channels, such as email, short message service, a mobile application, in the vehicle, etc. In some embodiments, the data access approval can be associated with additional approval parameters, including, but not limited to, access duration, type of data accessed, revocation criteria (e.g., criteria that result in automatic revocation of rights), customer notification parameters, etc. In some embodiments, the vehicle data service 122 can be configured with a customer profile that can specify default values ​​for the approval parameters. In other examples, the customer can be prompted to provide additional data access parameters.

[0074] At (8), once notification that the customer has been approved is received (using computing device 140) by the vehicle and third-party service provider 130 and / or technician, the vehicle 110 and third-party service provider 130 and / or technician may exchange vehicle data. The vehicle data may be selected according to any number of communication methods and protocols. For example, the vehicle may establish a communication channel via short-range radio frequency transmissions based on geographic proximity to a designated service provider. In other embodiments, the vehicle may encrypt, compress, or otherwise process transmissions between the service provider and the vehicle.

[0075] As previously mentioned, the vehicle data or communication access is configured as a set of common interfaces that do not require custom computing devices or hardware for the technician. In one aspect, the interface can correspond to sensor or component values / status or vehicle network information that provides access to data collected from the vehicle's sensors / components. As described above, the sensors can include hardware and software components that can acquire, generate, or process various operational or environmental information sources configured in the vehicle for various purposes. In some embodiments, the sensors can provide raw collected data to the control components as well as other controls for different functions. By way of example, information provided to the control components by the sensors, controller components, or other processing units can relate to the operation of the vehicle, such as detected vehicle speed, exterior temperature measurements, windshield wiper operation status, vision systems (e.g., camera input), location systems (e.g., GPS systems), timing information, component operation status, and the like. In some embodiments, the authorized third-party service provider 130 and / or technician can access the vehicle data (utilizing the computing device 140) to perform vehicle diagnostics and store the vehicle diagnostic results in the data store 124.

[0076] In some embodiments, network 160 can be utilized as a backup network for network 150. For example, if an engineer accesses one of the vehicles 110 via network 150, then if the network 150 connection is interrupted or disconnected, the vehicle 110 and computing device 140 can communicate via network 160.

[0077] A vehicle data transmission routine 500 will now be described with reference to Figure 5. The routine 500 is illustratively performed by a processing component 120 implemented in the vehicle 110. The process illustrated in Figure 5A is exemplary in nature and should not be construed as limiting.

[0078] At block 502, the vehicle receives the geographic criteria transmitted from the network service provider. By way of illustration, the network service may transmit the geographic criteria to the vehicle based on a request from a user associated with the vehicle, such as by issuing a service request to a third party or by transmitting a request directly to the network service. In other embodiments, the third-party service may prompt the network service to transmit the geographic criteria to the vehicle, such as upon confirmation of a service reservation for the vehicle. In other embodiments, the network service provider may transmit the geographic criteria for multiple third parties independent of a request or scheduled service. Additionally, the vehicle may be provided with the geographic criteria, such as upon detection of entry into a geographic region (e.g., a city or region).

[0079] Illustratively, the geographic criteria can be in the form of computer executable data, such as an executable script, that triggers based on at least the geographic boundary information. The trigger can be based on a determination that the vehicle's location has entered within the defined geographic boundary information (e.g., entered a geofence) or that the vehicle's location has ceased to be within the defined geographic boundary information (e.g., exited a geofence). Illustratively, the geographic criteria can include a designation of one or more particular vehicle data information or types of vehicle data that should be transmitted upon satisfaction of the triggering action. It should be noted that the geographic criteria can also include additional or supplemental criteria that can define filtering criteria for the vehicle data, timing data for transmission of the vehicle data, and the like. Additionally, the geographic criteria can incorporate or be supplemented with user profile information that can specify additional parameters related to the vehicle data transmission, such as data format preferences, customization information, prohibition information, and the like.

[0080] At block 504, the vehicle may obtain vehicle location information by accessing location information using a local location-based service component, such as a GPS component that is part of the vehicle, or by accessing a location service, such as via a mobile device (e.g., positioning system 218 and / or location system 224).

[0081] At block 506, the vehicle validates the vehicle location information against the geographic criteria. For example, the processing component 220 in the vehicle may process the geographic criteria to determine whether the current location matches one or more geographic criteria. As previously discussed, this may include determining whether the determined location falls within a geofence or never falls within a geofence. Illustratively, matching geofencing information may be characterized as satisfying a triggering action. In some embodiments, the vehicle may validate the vehicle's location within a geofenced area. For example, if the GPS component (positioning system 218 and / or location information system 224) indicates that the vehicle is within a geofenced area, the geofence data processing component 316 may further validate the accuracy of the location by utilizing a wireless local area network (WLAN) access point source, a Bluetooth source, a radio frequency identification (RFID) source, etc. If the processing of the geographic criteria verifies that the vehicle is located within the geofenced area, routing may move to block 508. If the processing of the geographic criteria does not verify that the vehicle is located within a geofenced area, routing may move to block 502.

[0082] At block 508, if the processed location information indicates that a triggering action should occur, the vehicle 110 may select vehicle data to be transmitted to the third-party service provider. As noted above, in some embodiments, the geographic criteria may specify the particular data or types of data to be transmitted to the third party. For example, the selected data may correspond to a type of service, a user preference, a service provider preference, etc. For example, the vehicle data may include software version information, diagnostic logs, sensor values, user information, language settings, etc.

[0083] In yet further embodiments, the triggering action may further include a request for information to be provided by a third party, such as a software update, a specific code utilized by the third party, or an encryption key. Thus, transmitting vehicle data in some embodiments may include transmitting data from the vehicle to a third party, transmitting data from a third party to the vehicle, or a combination thereof.

[0084] At block 510, the vehicle 110 and the third-party service provider exchange selected data. The transmission of data may be selected according to any number of communication methods and protocols. For example, the vehicle may establish a communication channel via short-range radio frequency transmission based on geographic proximity to the designated service provider. In other embodiments, the vehicle may encrypt, compress, or otherwise process transmissions between the service provider and the vehicle.

[0085] In some embodiments, the vehicle 110 exchanges vehicle data with an approved third-party service provider. In such embodiments, the vehicle data service 122 may include a list of approved technicians and / or technicians of approved third-party service providers associated with one or more geofenced regions. For example, all technicians of third-party service provider A are associated with a geofenced region of third-party service provider A. In this example, if the vehicle enters a geofenced region of third-party service provider A, the approved technicians associated with third-party service provider A are approved to access the vehicle data. In some embodiments, the vehicle data service 122 provides one or more criteria for authenticating a technician and terminating the technician's authentication. For example, the criteria may be based on the technician's physical location. In this example, if the vehicle enters a geofenced area associated with third-party service provider A, only technicians in a particular area, such as a service facility of third-party service provider A, may access the vehicle data. In another embodiment, authentication of a technician from third-party service provider A terminates when the technician leaves third-party service provider A's facility (e.g., leaves a geofenced area associated with third-party service provider A's facility). Additionally, the criteria may be based on the type of service, such that only technicians who specialize in the services requested by the vehicle owner (e.g., user) are authenticated. These criteria are provided for illustrative purposes only, and this disclosure is not intended to be limiting on the type or number of criteria.

[0086] In some embodiments, network 160 can be utilized as a backup network for network 150. For example, if an engineer accesses one of the vehicles 110 via network 150, then if the network 150 connection is interrupted or disconnected, the vehicle 110 and computing device 140 can communicate via network 160.

[0087] After completing block 510, routine 500 may be configured to be an automated routine by returning to block 502. By way of illustration, a third-party service provider may be configured to automate the processing of the submitted vehicle data or to implement a defined workflow related to the submitted vehicle data, which may include generating an interface to an output device within a designated service center (e.g., accepting a user), interfacing with a scheduling order system, generating notifications, generating documents, etc.

[0088] 6, a routine 600 for authenticating a third party service provider 130 and / or a technician will now be described. The routine 600 is illustratively implemented by the vehicle data service 122.

[0089] At block 602, the third-party service provider 130 and / or the technician may request authentication of the third-party service provider 130 and / or the computing device 140 (e.g., the technician's device accessing the vehicle data) to access the vehicle. Illustratively, the technician and / or the third-party service provider may obtain authentication credentials provided to the network service provider and subsequently receive a token or other semi-persistent information indicating the technician's authentication to access the vehicle 110. In one embodiment, as illustrated below, the authenticated third-party service provider 130 and / or the computing device 140 does not have access to the respective vehicle until the authenticated third-party service provider 130 and / or the technician is authenticated (by utilizing the computing device 140). To request authorization, the third-party service provider 130 and / or the technician issues an access request from the network service (by utilizing the computing device 140) and provides the specified information. For example, in one embodiment, the technician can provide vehicle identifier information such as VIN, customer contact information or identifiers such as customer email address, phone number, and other security or access information. Additionally, the technician can provide additional information regarding the access such as reason for access, time of access, scope of access, etc. Submission of the request can be facilitated through an API or other interface. In some embodiments, the access request can be pre-populated with profile information that defines default information such as access duration or specified restrictions on data access rights (e.g., vehicle logs pertaining to certain components or excluding others).

[0090] At block 604, the vehicle data service 122 receives the request and verifies (with the aid of the computing device 140) the token to ensure that the authentication authority allows access to the requested vehicle and vehicle data access type. For example, the vehicle data service 122 can verify (with the aid of the computing device 140) that the third-party service provider 130 and / or the technician has a valid subscription and technician subscription / entitlement. For example, the vehicle data service 122 can verify that the requesting technician has sufficient credentials to provide the requested service to the vehicle. In another embodiment, the vehicle data service 122 can also determine whether the service / access requested by the technician corresponds to the type of service to be performed on the vehicle and whether the requested service is non-duplicative or non-redundant. In yet a further embodiment, the vehicle data service 122 further determines whether the requested service is characteristic of the identified technician's behavioral patterns (e.g., services associated with various vehicles), which may be characterized as appropriate, potentially harmful, requiring verification from the customer, etc. Additionally, the vehicle data service 122 may verify the requested aspects of the vehicle, the device utilized by the technician, etc. If the credentials of the third party service provider 130 and / or technician are verified at block 606, the vehicle data service 122 may transmit the authenticated result to the vehicle at block 610. If the credentials of the third party service provider 130 and / or technician are not verified, the vehicle data service 122 may request credentials of the third party service provider 130 and / or technician at block 608.

[0091] At block 610, the vehicle data service 122 can send a notification or command to the vehicle 110 indicating that the data access communication has been approved. Additionally, the vehicle data service 122 can provide (using the computing device 140) the notification or credentials to the third-party service provider 130 and / or an engineer that allow access to the vehicle data. The notification can be provided via various communication channels, such as email, short message service, a mobile application, in-vehicle, etc. In some embodiments, the data access approval can be associated with additional approval parameters, including, but not limited to, access duration, type of data accessed, revocation criteria (e.g., criteria that result in automatic revocation of rights), customer notification parameters, etc. In some embodiments, the vehicle data service 122 can be configured with a customer profile that can specify default values ​​for the approval parameters. In other examples, the customer can be prompted to provide additional data access parameters.

[0092] Once notification of customer approval is received (using computing device 140) by the vehicle and third-party service provider 130 and / or technician at block 612, the vehicle 110 and third-party service provider 130 and / or technician may exchange vehicle data. The vehicle data may be selected according to any number of communication methods and protocols. For example, the vehicle establishes a communication channel via short-range radio frequency transmission based on geographic criteria closest to the designated third-party service provider. In other embodiments, the vehicle may encrypt, compress, or otherwise process transmissions between the service provider and the vehicle. At block 614, the routine 600 may end.

[0093] Various embodiments of the present disclosure may be integrated at any level of technical detail contemplated into systems, methods, and / or computer program products, which may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present disclosure.

[0094] For example, the functions described herein may be performed when and / or in response to software instructions being executed by one or more hardware processors and / or any other suitable computing device. The software instructions and / or other executable code may be read from a computer-readable storage medium (or media).

[0095] A computer readable storage medium may be a tangible device capable of holding and storing data and / or instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device (including any volatile and / or non-volatile electronic storage device), a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer readable storage media includes the following: portable computer diskettes, hard disks, solid state drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM, or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices having instructions recorded thereon, such as raised structures in a groove, and suitable combinations of the above. As used herein, a computer-readable storage medium is not to be construed as being a transient signal itself, such as a freely propagating electromagnetic wave such as an electric wave, an electromagnetic wave propagating through a transmission medium such as a waveguide (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0096] The computer readable program instructions described herein can be downloaded from the computer readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0097] Computer readable program instructions (also referred to herein as, for example, "code," "instructions," "modules," "applications," "software applications," etc.) for performing operations of the present disclosure may be such as assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, procedural programming languages ​​such as the "C" programming language, or similar programming languages. The computer readable program instructions may be invoked from other instructions or from themselves, and / or in response to a detected action or interrupt. The computer readable program instructions configured to execute on a computing device may be provided on a computer readable storage medium and / or as a digital download (and may be originally stored in a compressed or installable format requiring installation, decompression or decryption prior to execution) and then stored on the computer readable storage medium. Such computer readable program instructions may be stored in part or in whole in a memory device (e.g., a computer readable storage medium) of an executing computing device for execution by the computing device. The computer readable program instructions may be executed entirely on the user's computer (e.g., the executing computing device), partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server.In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to individualize the electronic circuitry to perform aspects of the present disclosure.

[0098] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0099] Such computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions executing via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. Further, such computer readable program instructions can be stored in computer readable program instructions that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, whereby a computer readable storage medium having instructions stored thereon includes an article of manufacture including instructions that implement aspects of the functions / operations specified in one or more blocks of the flowchart(s) and / or block diagram(s).

[0100] Further, computer readable program instructions can be loaded into a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process for a sequence of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. For example, the instructions may initially be borne on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions and / or modules into a dynamic memory and transmit the instructions over a telephone, cable or optical line using a modem. A modem local to the server computing system can receive the data over the telephone / cable / optical line and place the data on a bus using a converter device including appropriate circuitry. The bus carries the data to the memory, from which the processor can retrieve and execute the instructions. If desired, the instructions received by the memory can be stored on a storage device (e.g., a solid state drive) either before or after execution by the computer processor.

[0101] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may correspond to a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions described in the blocks may differ from the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or in some cases, the blocks may be executed in the reverse order, depending on the functionality involved. Moreover, in some implementations, certain blocks may be omitted. Additionally, the methods and processes described herein are not limited to a particular order, and the blocks or states thereof may be executed in other orders as appropriate.

[0102] It should further be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by special purpose hardware-based systems performing specific functions or operating or executing a combination of special purpose hardware and computer instructions. For example, the processes, methods, algorithms, elements, blocks, applications, or other functions (or portions of functions) described in the preceding paragraphs may be embodied via electronic hardware such as application specific processors (e.g., application specific integrated circuits (ASICs)), programmable processors (e.g., field programmable gate arrays (FPGAs)), application specific circuits, and / or may be fully or partially automated (further, any of which may combine custom hard-wired logic, logic circuits, ASICs, FPGAs, etc. with the execution of custom programming / software instructions to realize the present techniques).

[0103] As used herein, any of the above-described processors and / or devices incorporating any of the above-described processors may be referred to as, for example, a "computer," a "computing device," a "computing device," a "hardware computing device," a "hardware processor," a "processing unit," or the like. The computing devices of the above embodiments may typically (but not necessarily) be controlled and / or coordinated by operating system software, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g., Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS, VxWorks, or other suitable operating system. In other embodiments, the computing device may be controlled by its own operating system. A conventional operating system, among other things, controls and schedules the execution of computer processes, performs memory management, provides file system, networking, I / O services, and also provides user interface functionality, such as a graphical user interface ("GUI").

[0104] As noted above, in various embodiments, certain features may be accessible to a user through a web-based viewer (such as a web browser) or other suitable software program. In such implementations, the user interface may be generated by a server computing system and transmitted to a user's web browser (e.g., executing on the user's computing system). Alternatively, data necessary to generate the user interface (e.g., user interface data) may be provided by the server computing system to the browser, where the user interface may be generated (e.g., the user interface data may be executed by the browser accessing a web service and configured to render the user interface based on the user interface data). The user may then interact with the user interface through the web browser. The user interface of certain implementations may be accessed through one or more dedicated software applications. In certain embodiments, one or more of the computing devices and / or systems of the present disclosure may include a mobile computing device, and the user interface may be accessed through such a mobile computing device (e.g., a smartphone and / or tablet).

[0105] It should be understood that many variations and modifications are possible in the above-described embodiment, and that elements thereof are among the other acceptable examples. All such variations and modifications are intended to be included herein within the scope of the present disclosure. In the above description, certain specific embodiments have been detailed. However, no matter how detailed the above content is in the text, it will be understood that the systems and methods of the present invention can be implemented in many ways. Also, as mentioned above, it should be noted that the use of a particular term in describing a particular feature or aspect of the systems and methods of the present invention does not imply that the term is redefined herein to be limited to include the particular feature related to the feature or aspect of the system and method to which the term relates.

[0106] Unless otherwise specified or understood within the context of their use, conditional language such as "can," "could," "might," "may," and the like, is generally intended to convey that a particular embodiment includes certain features, elements, and / or steps, and other embodiments may not include them. Thus, such conditional language does not generally imply that features, elements, and / or steps are in any way required for one or more embodiments, or that one or more embodiments necessarily include logic that determines whether such features, elements, and / or steps are included in or should be performed in any particular embodiment, with or without user input or direction.

[0107] Unless otherwise specified, conjunctive language such as "at least one of X, Y, and Z" or "at least one of X, Y, or Z" shall be understood in context as commonly used to convey that an item, term, etc. may be either X, Y, Z, or any combination thereof. Furthermore, the term "or" is used in an inclusive (rather than exclusive) sense, so that, for example, when used to join a list of elements, "or" may mean one, some, or all of the elements in the list. Thus, such conjunctive language does not generally imply that a particular embodiment requires that at least one of X, at least one of Y, and at least one of Z are present.

[0108] As used herein, the term "a" is intended to be given an inclusive rather than exclusive interpretation. For example, unless otherwise specified, the term "a" should not be understood to mean "exactly one" or "only one," but instead, the term "a" means "one or more," or "at least one," regardless of whether the term "a" is used in the claims or elsewhere in the specification, and regardless of the use of quantifiers such as "at least one," "one or more," or "plurality" in the claims or elsewhere in the specification.

[0109] As used herein, the term "comprising" is intended to be given an inclusive rather than exclusive interpretation. For example, a general purpose computer including one or more processors should not be interpreted as excluding other computer components, and may include components such as memory, input / output devices, and / or network interfaces, among others.

[0110] Although the above detailed description has been illustrated and described, and furthermore, novel features as applied to various embodiments have been pointed out, it should be understood that various omissions, substitutions, and changes in the form and details of the illustrated devices or processes may be made without departing from the spirit of the present disclosure. As can be understood, certain embodiments of the invention described herein may be embodied in forms that do not provide all of the features and advantages described herein, since some features may be used or practiced separately from other features. The scope of certain inventions disclosed herein is indicated by the appended claims, rather than by the foregoing description. All changes that come within the meaning and range of equivalence of the claims are embraced within their scope.

Claims

1. 1. A system for providing vehicle data access to a third-party service provider based on vehicle location, the system including one or more external computing devices associated with a processor and a memory for executing computer-executable instructions for implementing processing components; the processing component obtaining, from a vehicle data service, geographic criteria corresponding to a vehicle service request from a user, the geographic criteria specifying selected vehicle data to be exchanged with the third-party service provider in response to the vehicle service request and geographic boundary information, the geographic boundary information indicating a geofenced area associated with the third-party service provider; determining vehicle location information by accessing a vehicle location-based services component; validating the determined vehicle location information against the geographic criteria; Upon verification, authorizing the third-party service provider to access at least a portion of the vehicle data; detecting one or more triggering actions, the triggering actions including a request for vehicle data to be provided to the third-party service provider, the third-party service provider configured to provide vehicle services in response to the vehicle service request and based on authenticated access to at least a portion of the vehicle data; determining the selected vehicle data for exchange with the third-party service provider based on the obtained geographic criteria; and causing the selected vehicle data to be exchanged between the vehicle and the authenticated third-party service provider.

2. The verification may include: matching the vehicle location information with the geographic criteria; or matching the vehicle location information with the geographic criteria based on a vehicle GPS positioning system and at least one of a wireless local area network (WLAN) access point information source, a Bluetooth information source, and a radio frequency identification (RFID) information source; The system of claim 1 , comprising one of:

3. The system of claim 1 , wherein the vehicle location information is generated based on at least a vehicle GPS positioning system.

4. The system of claim 1, wherein the third-party service provider includes one or more engineers associated with the third-party service provider.

5. The system of claim 1 , wherein the third-party service provider is configured to access the vehicle data based on criteria.

6. The system described in claim 5, wherein the third-party service provider is restricted from accessing the vehicle data upon expiration of the criteria, and the expiration of the criteria includes a revocation action that results in automatic revocation of access to the vehicle data, and further, the revocation action is based at least on the time and / or location of the third-party service provider.

7. the vehicle data service is configured to authenticate the third-party service provider; The authentication is Obtaining credentials for a third-party service provider; verifying the authentication information of the third-party service provider; and providing an authentication result to the vehicle in response to verifying the third-party service provider's authentication information; The system of claim 1 , wherein the authentication result indicates that the third-party service provider is authorized to access at least a portion of the vehicle data.

8. The system described in claim 1, wherein the detection of the triggering action is based on verifying vehicle location information associated with the vehicle data within the geographic criteria.

9. The processing component further comprises: obtaining, from a vehicle data service, geographic criteria corresponding to a vehicle service request from a user; and determining vehicle location information by accessing a vehicle location-based services component.

10. The location information of the vehicle is generated based on at least a vehicle GPS positioning system implemented in the vehicle; 9. The system of claim 8, wherein the verification includes matching the location information of the vehicle with the geographic criteria based on a vehicle GPS positioning system and at least one of a wireless local area network (WLAN) access point information source, a Bluetooth information source, and a radio frequency identification (RFID) information source.

11. The method of claim 10, wherein the third-party service provider is authorized to access at least a portion of the vehicle data upon the verification, and the vehicle data service is configured to authenticate the third-party service provider; The authentication is obtaining authentication information for a third-party service provider; verifying the authentication information of the third-party service provider; and in response to verifying the third-party service provider's authentication information, providing an authentication result to the vehicle, the authentication result indicating that the third-party service provider is authorized to access at least a portion of the vehicle data.

12. 1. A computer-implemented method for providing vehicle data access to a third-party service provider based on vehicle location, comprising: The method comprises: obtaining, from a vehicle data service, geographic criteria corresponding to a vehicle service request from a user, the geographic criteria specifying a designation of particular vehicle data information to be exchanged with the third-party service provider in response to the vehicle service request and geographic boundary information, the geographic boundary information indicating a geofenced area associated with the third-party service provider; accessing a vehicle location-based service component to determine vehicle location information, the vehicle location information being generated based on at least a vehicle GPS positioning system; validating the vehicle location information against the geographic criteria; detecting one or more triggering actions, the triggering actions including a request to access the selected vehicle data to be provided to the third-party service provider, the triggering actions further including a request for information provided by the third-party service provider, the third-party service provider configured to provide vehicle services in response to the vehicle service request and based on authenticated access to at least a portion of the vehicle data; determining the selected vehicle data from the vehicle data for exchange with the third-party service provider based on the obtained geographic criteria, the selected vehicle data corresponding to the vehicle service request; and causing the selected vehicle data to be exchanged between the vehicle and the third-party service provider.

13. The verification may include: Matching the vehicle location information with the geographic criteria, the geographic criteria including geographic boundary information, the geographic boundary information indicating a geofenced area associated with the third-party service provider; or matching the vehicle location information with the geographic criteria based on a vehicle GPS positioning system and at least one of a wireless local area network (WLAN) access point information source, a Bluetooth information source, and a radio frequency identification (RFID) information source; 13. The computer-implemented method of claim 12, comprising any one of:

14. Upon said verification, said third-party service provider is authorized to access at least a portion of said vehicle data; 13. The computer-implemented method of claim 12, wherein the third-party service provider is restricted from accessing the vehicle data by expiring criteria, the expiring criteria including a revocation action that results in automatic revocation of access rights to the vehicle data, and further wherein the revocation action is based at least on time and / or location of the third-party service provider.

15. the vehicle data service is configured to authenticate the third-party service provider; The authentication is obtaining authentication information for the third-party service provider; verifying the authentication information of the third-party service provider; and providing an authentication result to the vehicle in response to verifying the third-party service provider's authentication information; 13. The computer-implemented method of claim 12, wherein the authentication result indicates that the third-party service provider is authorized to access at least a portion of the vehicle data.

Images