Vehicle Data Jurisdiction Management

Abstract

The vehicle data management system and data jurisdiction system manage vehicle data between multiple jurisdictions and enable a set of jurisdiction rules that include rules for the various jurisdictions that are consistently applied. The vehicle data jurisdiction system can detect a change in the jurisdiction of the vehicle based on various portions of the received vehicle information and apply the appropriate jurisdiction rule from the set of jurisdiction rules. The various jurisdictions may have conflicting jurisdiction rules, and in such situations, the data jurisdiction system uses a jurisdiction rule resolution workflow to resolve potential conflicts between the rules. Based on the resolution of the conflict, the data jurisdiction system can migrate the vehicle's data to one or more other jurisdictions or otherwise implement the correct rule determined by resolving the conflict.

Description

[Background technology]

[0001] In recent years, data has become a vital component of the modern global economy due to the increasing adoption of technologies such as distributed cloud computing as well as the digitalization of various industries. As data becomes more important, so too has the interest of various jurisdictions, such as countries, to regulate the storage and transfer of data. One such regulation is data residency. Data residency is the requirement that data processed and stored in information technology (IT) systems must remain within the boundaries of a particular jurisdiction. Other such regulations address data retention and data privacy. For example, different jurisdictions may have different rules regarding the retention and / or use of data. Such requirements or regulations impact the use of IT infrastructure and affect operations that create, process, store, protect, and exchange electronic data, including data about vehicles. [Brief description of the drawings]

[0002] [Figure 1] 1 illustrates a vehicle data management system and a data jurisdiction system that determines a change in jurisdiction for a vehicle. The data jurisdiction system determines one or more actions to take in response to the change in jurisdiction for the vehicle based on a set of jurisdiction rules. Further, according to some embodiments, the data jurisdiction system resolves conflicts between jurisdiction rules in different jurisdictions, and the data management system migrates the vehicle's data to one or more other jurisdictions, if applicable, in accordance with non-conflicting jurisdiction rules. [Diagram 2] FIG. 1 illustrates a more detailed view of a data jurisdiction system that determines a change in jurisdiction for a vehicle, determines an action to take based on a set of jurisdiction rules, resolves conflicts between jurisdiction rules, and transitions vehicle data to one or more jurisdictions, according to some embodiments. [Diagram 3]FIG. 1 illustrates a logical block diagram illustrating various components of a data jurisdiction system, a vehicle data streaming system, and a vehicle jurisdiction machine learning system, according to some embodiments. [Figure 4A] 1 illustrates a more detailed view of a data jurisdiction system including a jurisdiction rules interface that provides a single, authoritative view of jurisdiction rules and enables jurisdiction rule conflict resolution and update of jurisdiction rules, according to some embodiments. [Figure 4B] 1 illustrates a more detailed view of a data jurisdiction system including a vehicle shadow system that synchronizes jurisdiction rules to provide a single authoritative view of vehicle status, according to some embodiments. [Diagram 5] FIG. 1 illustrates a more detailed diagram of an example use case of a data jurisdiction system, according to some embodiments, where the data jurisdiction system determines a change in jurisdiction of a vehicle from a first jurisdiction to a second jurisdiction and migrates vehicle data stored in a third jurisdiction. [Figure 6A] 1 illustrates a more detailed view of a data jurisdiction system before a vehicle information destination configuration is changed to a different jurisdiction and before deactivation of a virtual electronic control unit (virtual ECU) or vehicle shadow in one jurisdiction and activation in another jurisdiction, according to some embodiments. [Figure 6B] FIG. 1 illustrates a more detailed diagram of a data jurisdiction system for changing a vehicle information destination configuration to a different jurisdiction and deactivating a virtual electronic control unit (virtual ECU) or vehicle shadow in one jurisdiction and activating the virtual ECU and / or vehicle shadow in another jurisdiction, according to some embodiments. [Figure 6C] 1 illustrates a more detailed view of a data jurisdiction system after a vehicle information destination configuration is changed to a different jurisdiction and after deactivation of a virtual electronic control unit (virtual ECU) or vehicle shadow in one jurisdiction and activation in another jurisdiction, according to some embodiments. [Figure 7]1 illustrates a flowchart of operations performed by a vehicle data management system to determine a change in jurisdiction for a vehicle, resolve conflicts between jurisdictional rules, and migrate the vehicle's data to one or more other jurisdictions in accordance with the jurisdictional rules, according to some embodiments. [Figure 8] 1 illustrates a flowchart of operations performed by a vehicle data management system to determine whether a conflict exists between jurisdictional rules and to resolve the conflict between jurisdictional rules, according to some embodiments. [Figure 9] 1 illustrates a flowchart for implementing a conflict resolution workflow of a vehicle data jurisdiction system via a conflict resolution user interface, according to some embodiments. [Figure 10] 1 illustrates a flowchart of operations performed by a vehicle data management system to deactivate a virtual electronic control unit (virtual ECU) or vehicle shadow in one jurisdiction and activate the virtual ECU or vehicle shadow in another jurisdiction, according to some embodiments. [Figure 11] 1 illustrates a flowchart of operations performed by a vehicle data management system to change the jurisdiction to which a vehicle transmits its vehicle information, according to some embodiments. [Figure 12] FIG. 1 shows a block diagram illustrating an example computer system for implementing some or all of the techniques described herein, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0003] Although the embodiments are described herein by way of example in several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and detailed description thereof are not intended to limit the embodiments to the particular disclosed forms, but rather the intent is to cover all modifications, equivalents, and alternatives that are within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description and claims. As used throughout this application, the term "may" is used in an permissive sense (i.e., meaning having the potential to), rather than an essential sense (i.e., meaning required). Similarly, the terms "include," "including," and "includes" mean including, but not limited to.

[0004] The systems and methods described herein include techniques for implementing a vehicle data jurisdiction system for managing vehicle data among multiple jurisdictions. With the increasing importance of data in the modern economy, as well as the increasing complexity of the computing environment of the modern economy, public authorities have voiced concerns regarding the security, retention, and / or sharing of data. As a result, some governments have determined that data residency mandates, i.e., the requirement that data content be processed and stored in IT systems within the boundaries of a particular jurisdiction, provide an additional layer of security. Some countries have also mandated privacy-related protections, such as restrictions on data retention and sharing. Data residency and data privacy reflect a combination of issues primarily related to security risks and privacy risks associated with third-party access to data. Data residency and data privacy regulations particularly impact multinational cloud service providers (CSPs) with infrastructure assets located in different countries, as data residency and / or privacy requirements impact operations that create, process, store, and exchange many forms of electronic data among infrastructure assets across borders. Various data storage and transfer regulations may further conflict with one another, thus creating a need to find ways to resolve such conflicts. Data policies in various jurisdictions affect many types of data, including data generated by or related to vehicles.

[0005] Modern vehicles, such as cars, trucks, and motorcycles, are often manufactured with electronic sensors and include computer systems programmed with control algorithms that receive inputs from such electronic sensors and determine various control actions to be taken for the vehicle or systems implemented on the vehicle. Some vehicles may include as many as 70 such electronic control units (ECUs), and 20-30 sensor modalities, etc. Furthermore, modern vehicles are increasingly dependent on sensors that generate more data than previous vehicles. For example, an autonomous, semi-autonomous, or self-driving vehicle may include multiple cameras, radars, audio microphones, etc. Such sensors may generate large amounts of data that are stored in various jurisdictions, etc. However, data localization rules may require that vehicles associated with citizens / residents of a given jurisdiction or located within the geography of a given jurisdiction be collected, processed, and / or stored within that jurisdiction or in accordance with jurisdiction-specific data retention and / or sharing rules. For example, a jurisdiction such as Country A may require vehicle data to be stored within the country and may require a security assessment by government authorities before it is transferred outside the country. In addition to the increasing volume of data, as modern vehicles such as cars, trucks, and motorcycles become more advanced, they increasingly include electronic sensors that are utilized for various cloud applications, such as virtual electronic control units (virtual ECUs) that remotely provide computing resources to the vehicle. In the context of data captured from vehicle sensors, complying with these regulations can be difficult as vehicles may cross borders and move to new jurisdictions and be registered in new locations. Additionally, because vehicles are mobile, such jurisdictional changes may occur repeatedly. Thus, the application of various jurisdictional regulations, and the migration of the resulting vehicle data to the correct jurisdiction, becomes a significant issue.

[0006] The data jurisdiction system may provide mechanisms for various connected vehicle services to comply with data localization, retention, and / or privacy regulations. The data jurisdiction system may enable connected vehicle services located in different jurisdictions to interconnect and automatically detect vehicle signals or other vehicle information that may be used to determine a change in jurisdiction of the vehicle. The vehicle data streaming system may manage a pipeline / flow of vehicle data from external sources, including the vehicle or associated vehicle service centers, and transmit that information to the data jurisdiction system. The data jurisdiction system (as part of the vehicle data management service or a system independent of the vehicle data management service) may interconnect instances of the vehicle data management service located in different jurisdictions (data centers and / or availability zones) and facilitate the movement of vehicle data between jurisdictions based on a set of jurisdictional rules. The jurisdictional rules may relate to legal requirements for each jurisdiction regarding the storage, processing, retention, sharing, and / or transfer of vehicle data. Many jurisdictions specify independent jurisdictional rules that differ by jurisdiction, which may result in conflicts between the jurisdictional rules. When a conflict between jurisdictional rules occurs, the data jurisdiction system may use a conflict resolution workflow to resolve the conflict and determine the correct jurisdictional rule to apply.

[0007] Once the applicable jurisdictional rules are determined, the data migration system, which regulates the flow of data between jurisdictions and manages migration jobs and routing rules, automatically deletes, transfers, or retains the appropriate vehicle data as required by the jurisdictional rules. Routing rules are configurations that allow the data migration system to divert or copy data flowing through the vehicle data streaming system in one jurisdiction to its counterpart in another jurisdiction. A migration job is a task that deletes, partially or completely copies, or partially or completely moves data remaining in one jurisdiction, such as a vehicle shadow, to another jurisdiction, such as a vehicle shadow in another jurisdiction. An interconnected data jurisdiction system may maintain a single synchronized view of the jurisdictions with a corpus of vehicle identification numbers (VINs), the current associated jurisdiction for each VIN, and the data associated with each VIN. This may be used by the data jurisdiction system to determine the appropriate jurisdiction to connect to for a vehicle or an external application (e.g., a mobile application).

[0008] FIG. 1 illustrates a vehicle data management system and data jurisdiction system that determines a change in jurisdiction for a vehicle, resolves conflicts between jurisdiction rules (if necessary), and retains, deletes, or transitions the vehicle's data to one or more other jurisdictions in accordance with the jurisdiction rules. The various vehicle data management systems 110a, 110b, and 110c may be located in two or more jurisdictions, such as Jurisdiction A 102a, Jurisdiction B 102b, and Jurisdiction C 102c. The various jurisdictions may be geographical areas or territories within which authority affecting the management of vehicle data is exercised. In some embodiments, the jurisdictions may be based on countries representing separate sovereign polities, such as the United States. In other embodiments, the jurisdictions may be based on states or territories that subdivide a country into separate jurisdictions, such as California and San Francisco. Jurisdictions may further be comprised of multiple countries or states, as well as any number and / or combination of various territories, such as the European Union. In some embodiments, there may be jurisdictions with overlapping authority affecting the management of vehicle data.

[0009] Vehicle data management systems 110a, 110b, and 110c may be comprised of respective vehicle data streaming systems 120a, 120b, and 120c, data jurisdiction systems 124a, 124b, and 124c, and vehicle transition systems 140a, 140b, and 140c. Although FIG. 1 illustrates each vehicle data management system 110a, 110b, and 110c as being comprised of respective components, each system that comprises the vehicle data management system may be external to and independent of vehicle data management systems 110a, 110b, and 110c.

[0010] In some embodiments, the vehicle 150 may generate one or more vehicle information 106 to transmit to the vehicle data streaming system 120a. In some embodiments, the vehicle 150 may transmit the vehicle information 106 including data such as video frames, images, radar amplitude, temperature data, engine speed, and other information about the vehicle 150. The vehicle information 106 may include Global Positioning System (GPS) information determined using cellular, wireless passive, satellite, and other types of GPS systems. In some embodiments, the geographic location of the vehicle 150 may be determined in various ways. For example, in some embodiments, GPS may be used, and Global Navigation Satellite System (GNSS) may be used. In some embodiments, the vehicle may determine its location using local sensors and / or algorithms, such as using computer vision, light detection and ranging (LIDAR), vehicle odometry, etc.

[0011] 1 shows only vehicles 150 and vehicle service centers 160 as generating vehicle information 106, any number of data sources within or outside a jurisdiction may contribute to the vehicle information 106 transmitted to vehicle data streaming system 120a. Vehicle data streaming system 120a, in various embodiments, may be a device or system for managing the creation, storage, retrieval, and processing of large-scale vehicle data streams. Vehicle data streaming system 120a may be designed to accommodate hundreds or thousands of simultaneous data producers and data consumers. As used herein, the term "data stream" refers to a set of vehicle data records that may be generated by one or more data producers (e.g., vehicles 150, vehicle service centers 160) and accessed by one or more data consumers.

[0012] Upon receiving the vehicle information 106, the vehicle data streaming system 120a may detect a jurisdiction change event using the vehicle information 106. In some embodiments, detection of a change in jurisdiction of the vehicle 150 may be performed by the data jurisdiction system 124a instead of the vehicle data streaming system 120a. A jurisdiction change event may be inferred or presumed based on a single unambiguous indication of a jurisdiction change of the vehicle, such as a change in registration information from a vehicle service center 160. In some embodiments, a jurisdiction change event may be detected based on multiple vehicle information signals, such as a GPS signal, vehicle service information, vehicle location history, etc. A jurisdiction change event may be further detected or presumed based on one or more machine learning models trained using the past history of the vehicle information 106 and the jurisdiction rules 128a, as further described in FIG. 2 and FIG. 3.

[0013] The detected jurisdiction change event is then sent or requested by the data jurisdiction system 124a, which applies a set of jurisdiction rules 128a to initiate vehicle data migration 170a, 170b, 170c, respectively. However, in some embodiments, application of the set of jurisdiction rules may result in continued retention of vehicle data, with or without migration, or deletion of vehicle data. The data jurisdiction system 124a may include a workflow engine 130a and a jurisdiction rules engine 126a. The jurisdiction rules engine 126a may have access to a set of jurisdiction rules 128a and may utilize the jurisdiction rules 128a to determine whether one or more portions of vehicle data stored for the vehicle 150 should be deleted, moved, or retained in a particular jurisdiction. The set of jurisdiction rules 128a may include various data storage / transfer requirements of one or more jurisdictions. The jurisdiction rules 128a may include rules based on the jurisdiction of the change event (e.g., a jurisdiction change from Jurisdiction A to Jurisdiction B triggers data migration to Jurisdiction B), rules based on data type (e.g., vehicle user identification data, vehicle location, vehicle camera data are allowed to migrate), rules based on jurisdiction (e.g., data migration to Jurisdiction B is prohibited), or any combination thereof. For example, one jurisdiction rule may require that GPS vehicle data be migrated to Jurisdiction B 102b upon detection of a jurisdiction change trigger event to Jurisdiction B 102b. The jurisdiction rules 128a, 128b, and 128c may be added, deleted, or modified and may be synchronized between multiple jurisdictions. Synchronization of the jurisdiction rules 128a, 128b, and 128c is further described in FIG. 4A.

[0014] Once the jurisdiction rules that apply to the vehicle data are determined, the workflow engine 130a creates routing rules and / or migration jobs for the data migration system 140a. The data migration system 140a receives a migration notification from the data jurisdiction management system 130a that identifies one or more portions of the vehicle data to be moved. The migration of the vehicle data may involve the vehicle migration systems 140a, 140b, and 140c of the respective jurisdictions 102a, 102b, and 102c. In some embodiments, the data migration system 140a may transfer the vehicle data in batches. The jurisdiction rules engine 126a may determine whether one or more portions of the vehicle 150's data should be deleted, moved, or retained based on the set of jurisdiction rules 128a. The data migration system 140a moves one or more portions of the vehicle data stored in jurisdiction A 102a to jurisdiction B 102b based on the received migration notification. The workflow engine 130a, in some embodiments, communicates with other data jurisdiction systems in which data related to the associated VIN is stored. The workflow engine 130a may reconcile the applicable regulations and priorities associated with each vehicle data to determine the transition strategy to be implemented for all of the affected jurisdictions.

[0015] In some embodiments, the jurisdiction rules engine 128a may determine that a jurisdictional conflict exists between one or more rules of the set of jurisdiction rules 128a that have been selected to be applied. The jurisdiction rules engine 126a may initiate a jurisdiction conflict resolution workflow to resolve the conflict. The workflow engine 130a may resolve conflicts between the jurisdiction rules 128a using a predefined prioritization scheme. In some embodiments, manual resolution may be required in a conflict resolution workflow where the conflict is presented to a user via a user interface and a user decision is received. Based on the user decision, the workflow engine 130a may resolve the conflict. The conflict resolution workflow is further described in FIG. 8 and FIG. 9.

[0016] FIG. 2 shows a more detailed view of a data jurisdiction system that determines a vehicle's change of jurisdiction, resolves conflicts between jurisdiction rules, and migrates the vehicle's data to one or more other jurisdictions.

[0017] In FIG. 2, the vehicle 150 and the vehicle service center 160 may send vehicle information 106 to the vehicle data streaming system 120a as described in FIG. 1. In some embodiments, the vehicle data streaming system 120a may include a jurisdiction change event detection engine 122a that detects a jurisdiction change event for the vehicle 150. The jurisdiction change event detection engine 122a may interpret one or more of the vehicle information 106 to detect a jurisdiction change event and send a jurisdiction change event 202 to the jurisdiction rules engine 126a based on the change of jurisdiction. Although the vehicle data streaming system 120a is illustrated in FIG. 1 as being part of the vehicle data management system 110a, the vehicle data streaming system 120a may be a separate system external to the vehicle data management system 110a. The jurisdiction change event 202 may be communicated to the jurisdiction rules engine 126a using an application programming interface (API) call, sending one or more messages including the jurisdiction change event, or other communication protocol. The jurisdiction change event includes vehicle identification information, such as a VIN, the jurisdiction of the vehicle before the jurisdiction change event, and the jurisdiction of the vehicle after the jurisdiction change event. The jurisdiction change event may further include a description of one or more of the vehicle information 106 used to detect the jurisdiction change event.

[0018] In some embodiments, the jurisdiction change event detection engine 122a may be part of the jurisdiction rules engine 126a instead of the vehicle data streaming system 120a. The vehicle data streaming system 120a sends vehicle data 252 to the jurisdiction change event detection engine 122a. Additionally, the jurisdiction change event detection engine 122a may determine that a jurisdiction change event 202 has occurred. When a jurisdiction change event is detected, the jurisdiction rules engine 126a uses the jurisdiction change event to determine the appropriate jurisdiction rule(s) of the set of jurisdiction rules 128a to apply. As described in FIG. 1, the jurisdiction rules 128a may include rules based on various data storage / transfer requirements of one or more jurisdictions. The jurisdiction rules 128a may include rules based on jurisdiction changes, rules based on vehicle information, rules based on the jurisdiction of the vehicle, or any combination thereof. The jurisdiction rules 128a may be added, removed, or modified and may be synchronized between multiple jurisdictions. The jurisdiction rules engine 126a determines the jurisdiction rules 128a to apply based on the vehicle information, the past jurisdictions, and the current jurisdiction.

[0019] In some embodiments, the jurisdictional rules engine 126a initiates a workflow for the workflow engine 130a to create / update the routing rules 278 and / or migration jobs 206. Once the jurisdictional rules that apply to the vehicle data are determined, the workflow engine 130a creates the routing rules 278 for the vehicle data streaming system 120a and / or migration jobs for the data migration system 140a. The vehicle migration system 140a migrates the vehicle data to another jurisdiction 208 as determined by the workflow engine according to the jurisdictional rules 128a. In some embodiments, the vehicle data streaming system 120a routes the incoming vehicle information to another jurisdiction 280 based on the routing rules 278 as determined by the workflow engine 130a according to the jurisdictional rules 128a. The routing rules may include various parameters for routing the incoming vehicle information 106, such as time period, vehicle information type, jurisdictional destination, VIN, etc.

[0020] FIG. 3 illustrates a logical block diagram illustrating various components of a data jurisdiction system, a vehicle data streaming system, and a vehicle jurisdiction machine learning system, according to some embodiments.

[0021] As discussed in FIG. 2, the jurisdiction change event detection engine 122a may be part of the vehicle streaming system 120a or part of the jurisdiction rules engine 126a. Depending on the orientation, the vehicle data streaming system 122a may send the jurisdiction change event 202 to the jurisdiction rules engine 126a, or the vehicle data streaming system 120a may send the vehicle data 252 to the jurisdiction change event detection engine 250 of the jurisdiction rules engine 126a to detect the jurisdiction change event. In some embodiments, the jurisdiction change event machine learning engine 220 of the vehicle jurisdiction machine learning system 320 may receive jurisdiction change event training data 334 from the vehicle data streaming system 334. The received jurisdiction change event training data 334 may be used to train a machine learning model to determine that a jurisdiction change has occurred. The received jurisdiction change event training data 334 may include past history or a generated set of various types of vehicle information including GPS data, vehicle registration information, or vehicle service information. The jurisdiction rule training data 344 may further include information related to past jurisdiction change events (such vehicle identification information for vehicles that have experienced jurisdiction change events), associated vehicle information, and applied jurisdiction rules. The jurisdiction change event model 338 may be transmitted to the vehicle data streaming system 120a or the jurisdiction rule engine 126a. The transmitted jurisdiction change event model 338 may be used to determine whether one or more of the received vehicle information results in a jurisdiction change event.

[0022] In some embodiments, the data jurisdiction system 124a may include a jurisdiction rules interface 328a that may retrieve / update the jurisdiction rules 312 in the jurisdiction rules engine 126a. The jurisdiction rules interface 328a may retrieve the set of jurisdiction rules 128a stored in the jurisdiction rules engine 126a and may further provide an interface for adding, deleting, or modifying one or more of the jurisdiction rules of the set of jurisdiction rules. In some embodiments, updates to the jurisdiction rules 128a may be propagated to other locally stored copies of the set of jurisdiction rules stored in various other jurisdictions, as further described in FIG. 4A.

[0023] In some embodiments, the vehicle jurisdictional machine learning system 320 may further include a jurisdictional rule application machine learning engine 340 that receives jurisdictional rule training data 344 of vehicle information related to past jurisdictional change events similar to that provided to the jurisdictional change event machine learning engine 330. The jurisdictional rule training data 344 may include vehicle identification information of vehicles that have experienced jurisdictional change events, their associated vehicle information, and the jurisdictional rules that have been applied. The jurisdictional rule application machine learning engine 340 may be used to train a machine learning model to determine jurisdictional rules to apply to a vehicle based on the jurisdictional change event. The jurisdictional rule application machine learning engine 340 may send a jurisdictional rule application event model 348 to the jurisdictional rule engine 126a, which may use the trained model to determine which jurisdictional rules 128a to apply to a vehicle that has experienced a jurisdictional rule change event.

[0024] The jurisdiction rules engine 126a may initiate a workflow to resolve the jurisdiction rule conflict 304 when a conflict of one or more jurisdiction rules is detected among the jurisdiction rules 128a determined to apply to the vehicle data. In some embodiments, the workflow engine may use a predefined conflict resolution mechanism, such as a predefined prioritization scheme 360, to determine which jurisdiction rules among the conflicting rules to apply. The predefined prioritization scheme 360 ​​may be a set of instructions on how the conflicting jurisdiction rules 128a are resolved based on various factors, such as the type of jurisdiction rule, the vehicle identification information, and the affected vehicle data. The predefined prioritization scheme 360 ​​may determine which of the one or more jurisdiction rules 128a of the conflicting rules apply to the vehicle's data or data. In some embodiments, the jurisdiction rule resolution may involve partial application of one or more conflicting rules. The workflow engine 130a reconciles the applicable rules and their associated priorities to determine a transition strategy to be implemented in multiple affected jurisdictions, not just jurisdiction A 102a.

[0025] In some embodiments, manual resolution may be used in the workflow to resolve conflicts instead of or in combination with the rule prioritization scheme 360. The jurisdictional rules conflict resolution interface 314 of the data jurisdiction system 124a may be used to obtain / update the conflict resolution 316. In some embodiments, the jurisdictional rules conflict resolution interface 314 may be used to provide an interface to request one or more user decisions to resolve the conflict. The jurisdictional rules conflict resolution interface 314 may request a user to make one or more decisions to resolve the jurisdictional conflict, such as selecting between two conflicting jurisdiction rules which one to apply to the vehicle data, or other such related decisions that may be used by the workflow engine 130a to resolve the jurisdictional rule conflict. For example, the related decisions may further include ranking the priority of the jurisdictional rules, determining the importance of the vehicle data, determining a threshold transfer cost for the affected vehicle data, etc. The conflict resolution workflow is further described in FIG. 9.

[0026] In some embodiments, the vehicle jurisdictional machine learning system 320 may further include a jurisdictional rule conflict resolution machine learning engine 350 that receives jurisdictional rule conflict resolution training data 358 and transmits a jurisdictional rule conflict resolution model 354 to the workflow engine 130a. The jurisdictional rule conflict resolution training data 358 may include data related to resolving jurisdictional conflicts, such as a past history of conflict resolutions between one or more jurisdictions, their associated jurisdiction rules, their vehicle identification information, and affected vehicle data. Additionally, as described above, the jurisdictional rule conflict resolution training data 358 may include a past history of user decisions from the jurisdictional rule conflict resolution interface 314, such as choosing between two conflicting jurisdictional rules, ranking the priority of jurisdiction rules, and determining the importance of vehicle data. The jurisdictional rule conflict resolution machine learning engine 350 may generate a jurisdictional rule conflict resolution model 354 using the received jurisdictional rule conflict resolution training data 358. The jurisdictional rule conflict resolution machine learning engine 350 sends a jurisdictional rule conflict resolution model 354 to the workflow engine 130a, which may be used as part of a conflict resolution mechanism to resolve jurisdictional rule conflicts. Once the jurisdictional rule conflicts are resolved and the applicable jurisdictional rule is determined, the workflow engine creates routing rules and / or migration jobs for the data migration system based on the jurisdictional rule.

[0027] FIG. 4A shows a more detailed view of the data jurisdiction system including a jurisdiction rules interface that synchronizes jurisdiction rules to provide a single authoritative view of jurisdiction rules.

[0028] The data jurisdiction systems 124a, 124b, and 124c in each of Jurisdiction A 102a, Jurisdiction B 102b, and Jurisdiction C 102c may be interconnected to provide a single authoritative view of jurisdiction rules. Each jurisdiction rules engine 126a, 126b, and 126c may synchronize jurisdiction rules 480 to maintain a single authoritative view of the various sets of jurisdiction rules 128a, 128b, and 128c in the multiple jurisdictions. Any of the respective changes to the jurisdiction rules 128a, 128b, and 128c by the respective jurisdiction rules interfaces 328a, 328b, and 328c trigger the jurisdiction rules engines 126a, 126b, and 126c to synchronize the jurisdiction rules 480 with their counterparts in the other jurisdictions so that they match the respective updates. The locally stored copies of the sets of jurisdiction rules 128a, 128b, and 128c stored in each jurisdiction may be synchronized using various methods to provide a single authoritative view. For example, a single authoritative view of the rules may be provided using multi-primary replication that allows data to be stored and updated by any member of the group. Various methods may be applied to resolve any conflicts that may arise between concurrent changes made by different members. In some embodiments, replication of updates to the jurisdiction rules 410a, such as adding, deleting, or modifying one or more of the jurisdiction rules 128a, may be replicated asynchronously, with the changes stored in a queue in the data jurisdiction system 124a and then propagated to other systems. In some embodiments, replication of various updates to the jurisdiction rules 410a may be performed synchronously, with the updates performed in multiple jurisdictions as part of a single transaction. In some embodiments, a multi-primary replication environment that provides a single authoritative view of the jurisdiction rules may include a mix of both synchronous and asynchronous replication.

[0029] FIG. 4B shows a more detailed view of a data jurisdiction system that includes a vehicle shadow system that synchronizes vehicle shadows to provide a single authoritative view of vehicle status.

[0030] The data jurisdiction systems 124a, 124b, and 124c in each jurisdiction A 102a, jurisdiction B 102b, and jurisdiction C 102c may be interconnected to provide a single authoritative view of vehicle status. Each jurisdiction rules engine 126a, 126b, and 126c may synchronize vehicle status 496 to maintain a single authoritative view of vehicle status in multiple jurisdictions. In some embodiments, each data jurisdiction system 124a may be associated with a vehicle shadow 492a stored locally in jurisdiction A 102a. The vehicle shadow 492a may be a virtual representation of a physical vehicle. The vehicle shadow 492a may be connected to its associated physical vehicle and may execute remote commands to synchronize vehicle status between the physical vehicle and the vehicle shadow itself in real time. The vehicle shadow may retrieve / update vehicle status 490a based on the current jurisdiction of authority and its VIN, such as various vehicle attributes including vehicle model, make, vehicle sensor history status / current status, and vehicle registration information. In some embodiments, in addition to vehicle information, the jurisdiction systems 124a, 124b, and 124c may synchronize information regarding where portions of the vehicle data are stored in the various jurisdictions / locations.

[0031] In some embodiments, changes to the locally stored vehicle shadow 492a may trigger the data jurisdiction system 124a to synchronize the vehicle state 496 with its counterparts in other jurisdictions so that they are consistent with the respective updates. In some embodiments, updates to the vehicle state may be triggered by the movement of vehicle data from one jurisdiction to another as the jurisdiction of the vehicle changes. The locally stored copies of the vehicle shadow 492a stored in each jurisdiction may be synchronized using various methods to provide a single authoritative view. For example, a single authoritative view of the rules, similar to that of FIG. 4A, may be provided using multi-reader replication that allows data to be stored and updated by any member of the group. In some embodiments, replication between the locally stored vehicle shadows 492a may be asynchronous, with updates to the vehicle state 490a being stored in a queue and then propagated. In some embodiments, replication between the locally stored vehicle shadows 492a of various updates to the vehicle state 490 may be synchronous, with changes being performed in multiple jurisdictions as part of a single transaction. In some embodiments, a multi-reader replication environment that provides a single authoritative view of jurisdictional rules may include a mix of both synchronous and asynchronous replication. In some embodiments, in place of the vehicle shadow 492a, other systems that provide vehicle state may be synchronized in place of the vehicle shadow, such as virtual ECUs, which are further described in Figures 6A-6C.

[0032] FIG. 5 shows a more detailed view of a data jurisdiction system that determines a change in jurisdiction of a vehicle from a first jurisdiction to a second jurisdiction and causes the jurisdiction system to migrate vehicle data stored in a third jurisdiction.

[0033] Similar to Fig. 1, the various vehicle data management systems 110a, 110b, and 110c may be located in two or more jurisdictions, such as Jurisdiction A 102a, Jurisdiction B 102b, and Jurisdiction C 102c. The vehicle data management systems 110a, 110b, and 110c may be comprised of respective vehicle data streaming systems 120a, 120b, and 120c, data jurisdiction systems 124a, 124b, and 124c, and vehicle transition systems 140a, 140b, and 140c. Although Fig. 1 shows each vehicle data management system 110a, 110b, and 110c as being comprised of respective components, each system that comprises the vehicle data management system may be external to and independent of the vehicle data management system.

[0034] In some embodiments, the vehicle data streaming system 120a may receive vehicle information from the vehicle 150, the vehicle service center 160, or other sources that also indicates a change of jurisdiction from Jurisdiction C 102a to Jurisdiction B 102b. In applying the relevant jurisdiction rules 128a and in resolving any jurisdiction rule conflicts that may arise (as discussed in FIG. 2 and FIG. 3), the jurisdiction system may determine (510) that vehicle data from both Jurisdictions A and C is to be migrated. The determination may be based on the synchronized vehicle state, including information regarding the location of the vehicle data. Once the data jurisdiction system 124a determines (510) that vehicle data from both Jurisdictions A and C is to be migrated, the workflow engine 130a initiates data routing / migration of the vehicle data stored in Jurisdiction C (520). In some embodiments, a jurisdiction rule conflict may exist between the rules for Jurisdiction C and the rules for Jurisdiction B. The data jurisdiction system 124a may resolve jurisdictional rule conflicts between various jurisdictions other than the jurisdiction in which the data jurisdiction system 124a resides (i.e., conflicts between the rules of Jurisdiction C and the rules of Jurisdiction B) via the jurisdictional rule conflict workflow described in FIG. 3. In some embodiments, instead of the data jurisdiction system 124a resolving jurisdictional rule conflicts, the data jurisdiction system 124c of the subsequent vehicle transition system 140c may resolve the conflict using its workflow engine 130c. The vehicle transition system 140c may cause one or more portions of the vehicle data stored in Jurisdiction C to be deleted, moved to Jurisdiction B, or retained in Jurisdiction C based on the determination. In some embodiments, the vehicle data streaming system 120c may route the incoming vehicle data from Jurisdiction C 102c to Jurisdiction B 102b based on the output of the workflow engine 130a of Jurisdiction A 102a.In addition to the data jurisdiction system 124c resolving jurisdiction rule conflicts, in some embodiments, the data jurisdiction system 124c may detect jurisdiction rules to apply based on a data migration initiation notification received from the workflow engine 130a of jurisdiction A 102a. In other embodiments, the workflow engine 130a uses a routing rule / migration notification to indicate to the vehicle data management system 110c to route / migrate one or more portions of the vehicle data to jurisdiction B as determined by the data jurisdiction system 124a.

[0035] Vehicle data management system 110c may route / migrate the vehicle data to jurisdiction C 530. Vehicle transition system 140c may cause one or more portions of the vehicle data stored in jurisdiction C to be deleted and / or moved to jurisdiction B. Additionally, vehicle transition system 140a in jurisdiction A 102a may migrate vehicle data 540 to jurisdiction B. Vehicle transition system 140b may then cause one or more portions of the vehicle data stored in jurisdiction C 102c and jurisdiction A 102a to be copied, partially copied, or refused to be copied.

[0036] FIG. 6A shows a more detailed view of the data jurisdiction system before the vehicle information destination configuration is changed to a different jurisdiction and before deactivation of a virtual electronic control unit (virtual ECU) and / or vehicle shadow in one jurisdiction and activation in another jurisdiction, according to some embodiments.

[0037] Similar to FIG. 2, the vehicle 150 may transmit vehicle information 106 to the vehicle data streaming system 120a via a network 620 to the vehicle data streaming system 120a. The vehicle 150 may transmit vehicle information 160 to the vehicle data streaming system 120a in Jurisdiction A 102a according to a configuration setting having Jurisdiction A 102a as the destination for the vehicle information 106. In some embodiments, the destination configuration setting may be a specific data center or availability zone within the jurisdiction. The network 620 may be a private or public network, such as a direct connection to the service provider network hosting the vehicle data streaming system 120a, or an Internet connection. Additionally, the network 620 may be a wireless network, such as a cellular network, a Wi-Fi network, or other wireless network. Although not specifically shown in FIG. 6A, in some embodiments, the vehicle data streaming system 120a may receive vehicle information from various other vehicle information sources, such as vehicle service centers.

[0038] The vehicle data streaming system 120a may transmit / receive vehicle information 630a to / from the vehicle shadow 492a, the virtual engine control unit (ECU) 610a, and the data jurisdiction system 124a of the jurisdiction A 102a. The jurisdiction A 102a may be the jurisdiction in which the vehicle shadow 492a and / or the vehicle ECU 610a have the authority to be the primary instance that is preferred in updating and synchronizing the vehicle 150. As described in FIG. 4B, the vehicle shadow 492a stored locally in the jurisdiction A 102a may be a virtual representation of a physical vehicle and may execute remote commands to synchronize the vehicle state between the physical vehicle and the vehicle shadow itself in real time. In some embodiments, the vehicle shadow 492a may transmit / receive vehicle information using multiple sources separate from the vehicle data streaming system 120a. The vehicle information 106 may be used to update various vehicle shadow 492a attributes as discussed in FIG. 4B. The virtual ECU may also send / receive vehicle information 610a from the vehicle 150 via the network 620. The virtual ECU may be used to control a number of sensors in the vehicle, interpret sensor data, and adjust the controlled systems of the vehicle. The virtual ECU may be used to control the vehicle's vehicle systems in real-time or near real-time. The vehicle information 106 sent to the vehicle data streaming system 120a may operate with the data jurisdiction system 124a and the vehicle transition system 140a to detect changes in the jurisdiction of the vehicle. As discussed in FIG. 2, the jurisdiction rules engine 126a and the workflow engine 130a may be used to perform subsequent downstream application of the jurisdiction rules 128a.

[0039] FIG. 6B shows a more detailed view of the data jurisdiction system for changing the vehicle information destination configuration to a different jurisdiction and deactivating virtual electronic control units (virtual ECUs) and / or vehicle shadows from one jurisdiction and activating them in another jurisdiction.

[0040] Upon detection of a jurisdiction change event and resolution of the applicable rules, the data jurisdiction system 124a may send a deactivate instance 650 command to the vehicle shadow 492a and to the instance of the virtual ECU 610a of the vehicle 150 stored locally in the jurisdiction A 102a. The data jurisdiction system 124b also cooperates to activate the instance 660 of the vehicle shadow 492b and the virtual ECU 610b implemented in the jurisdiction B 102b. In some embodiments, the deactivate instance 650 and activate instance 660 commands may occur as a result of a migration of vehicle data from the jurisdiction A 102a to the jurisdiction B 608. In other embodiments, the deactivation / activation of the vehicle shadow 494b, 492b and the virtual ECU 610a, 610b may not involve a data migration, but may occur independently based on the jurisdiction rules 128a, 128b. In some embodiments, snapshots of the deactivated vehicle shadow 492a and virtual ECU 610a for jurisdiction A 102a may be stored in jurisdiction A 102a. In other embodiments, the vehicle shadow 492a and virtual ECU 610a for jurisdiction A 102a may not be deactivated, but may become unauthorized instances. In some embodiments, the workflow engine 130a may initiate routing of the vehicle data 678 to route the incoming vehicle information to jurisdiction B 680, such as jurisdiction B 102b. The workflow engine 130a may create one or more routing rules (or modify one or more existing routing rules) to reconfigure the vehicle data streaming system 120a to route the incoming vehicle information 106 to jurisdiction B 102b as determined by the workflow engine 130a according to the jurisdiction rules 128a. The routing rules may include various parameters for routing the incoming vehicle information 106, including a time period, a vehicle information type, a jurisdiction destination, a VIN, etc. Vehicle data streaming system 120a, in some embodiments, may route vehicle data to vehicle data streaming system 120b in jurisdiction B 102b.

[0041] In some embodiments, a change of jurisdiction for a vehicle 150 from Jurisdiction A 102a to Jurisdiction B 102b may result in the data jurisdiction system 124a for Jurisdiction A 102a sending a vehicle scheme packet to the vehicle to modify the destination to which the vehicle information 106 is sent. The vehicle scheme packet may update the configuration setting of the vehicle information destination to Jurisdiction B 102b upon receiving the vehicle scheme packet sent to the vehicle.

[0042] FIG. 6C shows a more detailed view of the data jurisdiction system after the vehicle information destination configuration has been changed to a different jurisdiction and after deactivation of a virtual electronic control unit (virtual ECU) and / or vehicle shadow from one jurisdiction and activation in another jurisdiction.

[0043] A vehicle 150 with an updated vehicle information destination configuration may send vehicle information 106 to a vehicle data streaming system 120b in jurisdiction B 102b. Similar to FIG. 6A, but taking place in jurisdiction B, the vehicle data streaming system 120b sends / receives vehicle information 630b to a vehicle shadow 492b, a virtual engine control unit (ECU) 610b, and a system 124b in data jurisdiction B 102b. The most recently activated vehicle shadow 492b stored locally in jurisdiction B 102b may be a virtual representation of a physical vehicle and may execute remote commands to synchronize vehicle state between the physical vehicle and the vehicle shadow itself in real time via the vehicle data streaming system 120b in jurisdiction B 102b. The most recently activated vehicle shadow 492b may also send / receive vehicle information using multiple sources separate from the vehicle data streaming system 120b. The subsequent vehicle information 106 received at the vehicle data streaming system 120b may be used to update various vehicle shadow 492b attributes, as discussed in FIG. 4B. The virtual ECU 610b may also send / receive vehicle information 630b from the vehicle 150 via the network 620. As discussed in FIG. 6A, the virtual ECU may be used to control a number of sensors in the vehicle, interpret sensor data, and adjust engine actuators from jurisdiction B 102b. As discussed in FIG. 2, the vehicle information 106 sent to the vehicle data streaming system 120a may, in conjunction with the data jurisdiction system 124a and the vehicle transition system 140a, detect changes in the vehicle's jurisdiction and subsequent downstream application of jurisdiction rules 128a using the jurisdiction rules engine 126a and workflow engine 130a.

[0044] FIG. 7 illustrates a flowchart of operations performed by the data jurisdiction system to determine a change in jurisdiction for a vehicle based on a set of jurisdiction rules, resolve conflicts between the jurisdiction rules, and migrate the vehicle's data to one or more other jurisdictions.

[0045] At block 710, the data jurisdiction system of the vehicle data management system detects a jurisdiction change event for the vehicle based on the received vehicle information. As discussed in FIG. 1, the jurisdiction change event may be detected using a single unambiguous indication of a change in the jurisdiction of the vehicle, such as a change in registration information from a vehicle service center. In some embodiments, the jurisdiction change event may be detected based on multiple different types of information, such as GPS signals, vehicle service information, vehicle location history, etc. The jurisdiction change event may further be detected using machine learning models and jurisdiction rules trained using various vehicle information, as discussed in FIG. 3. In some embodiments, the vehicle data streaming system of the vehicle data management system may be used to detect the jurisdiction change event.

[0046] At block 720, the data jurisdiction system determines that one or more portions of the vehicle data stored in the first jurisdiction are to be deleted, moved, or retained based on a set of jurisdiction rules for the vehicle's data storage requirements. The set of jurisdiction rules may include rules based on jurisdiction change events, data type, jurisdiction identification, or any combination herein, as discussed in FIG. 1. In some embodiments, the data jurisdiction system may be independent of the larger data management system and may be a separate service. As discussed in FIG. 3, the data jurisdiction system may use a model trained with the VINs of vehicles that have experienced jurisdiction change events, their associated vehicle information, the jurisdiction rules applied, and other vehicle information to determine which jurisdiction rules to apply to the vehicle.

[0047] At block 730, the data jurisdiction system causes one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to the second jurisdiction, or retained in the first jurisdiction based on the determination. In some embodiments, as discussed in FIG. 5, the data jurisdiction system determines a transition strategy that affects strategies of multiple other jurisdictions and causes the data stored in the other jurisdiction to be moved to the second jurisdiction.

[0048] FIG. 8 illustrates a flow chart of operations performed by the vehicle data management system to determine whether a conflict exists between jurisdictional rules and to resolve the conflict between jurisdictional rules.

[0049] At block 810, the data jurisdiction system determines whether a conflict exists between the jurisdiction rules of the first jurisdiction and the jurisdiction rules of the second jurisdiction. The jurisdiction rule conflict may be limited to a portion of the vehicle data, and in some embodiments may include three or more jurisdiction rules for more than the first jurisdiction and the second jurisdiction.

[0050] At block 820, if a conflict exists between the jurisdiction rules of the first jurisdiction and the jurisdiction rules of the second jurisdiction, the data jurisdiction system initiates a jurisdiction conflict resolution workflow to resolve the conflict. The jurisdiction conflict resolution workflow may include obtaining a user decision, as further discussed in FIG. 3 and FIG. 9.

[0051] In some embodiments, at block 830, the data jurisdiction system uses a machine learning model to determine a rule prioritization scheme based on a past history of conflict resolution between one or more inter-jurisdictional conflicts. As discussed in FIG. 3, the machine learning model may be trained using not only the past history of conflict resolution, but also other data relevant to the resolution of jurisdictional conflicts, such as the past history of relevant jurisdictional rules, vehicle identification information, and affected vehicle data.

[0052] At block 840, the data jurisdiction system resolves conflicts between the jurisdiction rules of the first jurisdiction and the jurisdiction rules of the second jurisdiction using a conflict resolution mechanism that includes a rule prioritization scheme. The predefined prioritization scheme may be a set of instructions on how conflicting jurisdiction rules are resolved based on various factors such as the type of jurisdiction rule, the vehicle identification information, and the affected vehicle data. As discussed in FIG. 3, the predefined prioritization scheme may determine which of the one or more jurisdiction rules of the conflicting rules to apply to the vehicle's one or more data.

[0053] FIG. 9 illustrates a flow chart for implementing the vehicle data jurisdiction system conflict resolution workflow via the conflict resolution user interface.

[0054] At block 910, the data jurisdiction system presents the conflicts via a conflict resolution user interface. The conflict resolution user interface may provide a programmatic interface (e.g., an API, a web page or website, a graphical user interface, or a command line tool) to make the conflicts visible and to enable configuration and resolution of the conflicts. In some embodiments, the conflicts presented to the user via the interface may translate conflicts in jurisdiction rules into actionable decisions. In some embodiments, the conflict resolution user interface may notify the user of the conflicts.

[0055] At block 920, the data jurisdiction system receives one or more user decisions to resolve the conflict via the conflict resolution user interface. The user decisions may include relevant decisions including ranking the priority of jurisdiction rules, determining the importance of the vehicle data, determining a threshold transfer cost for the affected vehicle data, etc., as discussed in FIG.

[0056] At block 930, the data jurisdiction system resolves the conflict based on one or more user decisions. The conflict resolution may be based directly on the user decisions (i.e., decisions that specify which jurisdiction rules apply relative to others) or may be based indirectly on the user decisions. In some embodiments, the user decisions may be used as part of a conflict resolution mechanism to resolve conflicts in jurisdiction rules. In some embodiments, the data jurisdiction system may use a machine learning model trained using decisions obtained via the conflict resolution interface.

[0057] FIG. 10 illustrates a flow chart of operations performed by a vehicle data management system to deactivate a virtual engine control unit / vehicle shadow from one jurisdiction and activate it in another jurisdiction.

[0058] In block 1010, the data jurisdiction system determines whether the first jurisdiction, the second jurisdiction, or another jurisdiction is an authority over the vehicle. The determination may be made based on vehicle state available in a vehicle shadow or other vehicle information storage node.

[0059] At block 1020, the data jurisdiction system deactivates the instance of the virtual ECU of the vehicle in the first jurisdiction based on the determination that the first jurisdiction is not an authoritative jurisdiction. The deactivation of the virtual ECU may be partial or complete. In some embodiments, a snapshot of the deactivated virtual ECU in the first jurisdiction may be stored in the first jurisdiction, as discussed in FIG. 6B.

[0060] At block 1030, the data jurisdiction system activates a new virtual ECU instance for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is the authoritative jurisdiction for the vehicle. The new virtual ECU instance may transfer data from the virtual ECU in the first jurisdiction and become the new authoritative virtual ECU for the vehicle. In some embodiments, the new vehicle shadow instance as the authoritative instance may control multiple sensors in the vehicle in real time.

[0061] At block 1040, the vehicle information extraction service deactivates an instance of the vehicle shadow of the vehicle in the first jurisdiction based on the determination that the first jurisdiction is not an authoritative jurisdiction. The deactivation of the vehicle shadow may be partial or complete. In some embodiments, a snapshot of the deactivated vehicle shadow in the first jurisdiction may be stored in the first jurisdiction, as discussed in FIG. 6B.

[0062] At block 1050, the vehicle information extraction service activates a new vehicle shadow instance for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is an authoritative jurisdiction for the vehicle. The new vehicle shadow instance may transfer data from the vehicle shadow in the first jurisdiction and become the new authoritative vehicle shadow for the vehicle. In some embodiments, the new vehicle shadow instance as the authoritative instance may execute remote commands to synchronize vehicle state between the physical vehicle and the vehicle shadow itself in real time.

[0063] FIG. 11 illustrates a flow chart of operations performed by a vehicle data management system to change the jurisdiction to which a vehicle transmits its vehicle information.

[0064] At block 1110, the data jurisdiction system detects a jurisdiction change event for the vehicle based on the received vehicle information. As discussed in Figures 1 and 7, the jurisdiction change event may be detected using a single unambiguous indication of a change in jurisdiction for the vehicle, such as a change in registration information from a vehicle service center. In some embodiments, the jurisdiction change event may be detected based on multiple different types of information, such as GPS signals, vehicle service information, vehicle location history, etc.

[0065] At block 1120, the data jurisdiction system determines that one or more portions of the vehicle data should be stored in a different jurisdiction based on a set of jurisdictional rules for vehicle data storage requirements.

[0066] In block 1130, the data jurisdiction system transmits a vehicle scheme packet that includes information identifying the vehicle information destination for the vehicle in a different jurisdiction. As discussed in FIG. 6C, the vehicle scheme packet may change the vehicle information destination configuration setting to the vehicle information destination configuration setting for another jurisdiction so that subsequent vehicle information is directed to the new jurisdiction.

[0067] Exemplary Computer System Figure 12 illustrates an example computer system 1200 that can be used to implement a vehicle data management system and a data jurisdiction system as described above with reference to Figures 1-11. In different embodiments, computer system 1200 may be any of a variety of types of devices, including, but not limited to, a personal computer system, a desktop computer, a laptop, notebook, a tablet, slate, pad, or notebook computer, a handheld computer, a workstation, a network computer, a mobile device, a consumer device, an application server, a storage device, a peripheral such as a switch, modem, router, or in general any type of computing device or electronic device.

[0068] As described herein, various embodiments of program instructions for determining a change of jurisdiction for a vehicle based on a set of jurisdiction rules, resolving conflicts between jurisdiction rules, and migrating data for a vehicle to one or more other jurisdictions may be executed on one or more computer systems 1200 that may interact with various other devices. It should be noted that any of the components, actions, or functionality described above with respect to FIGS. 1-11 according to various embodiments may be implemented on one or more computers configured as computer system 1200 of FIG. 12. In the embodiment shown, computer system 1200 includes one or more processors 1210 connected to system memory 1220 via an input / output (I / O) interface 1230. Computer system 1200 further includes a network interface 1240 coupled to I / O interface 1230, and one or more input / output devices 1250, such as a cursor control device 1260, a keyboard 1270, and a display(s) 1280. While in some cases, as discussed above for various embodiments, the embodiments may be implemented using a single instance of computer system 1200, it is contemplated that in other embodiments, multiple such computer systems, or multiple nodes that make up computer system 1200, may be configured to host different portions or instances of the program instructions. For example, in one embodiment, some elements of the program instructions may be implemented via one or more nodes of computer system 1200 that are separate from the nodes that implement other elements.

[0069] In some embodiments, computer system 1200 may be implemented as a system on a chip (SoC). For example, in some embodiments, processor 1210, memory 1220, I / O interface 1230 (e.g., fabric), etc. may be implemented in a single SoC that includes multiple components integrated on a single chip. For example, an SoC may include multiple CPU cores, a multi-core GPU, a multi-core neural engine, a cache, one or more memories, etc. integrated on a single chip. In some embodiments, an SoC embodiment may implement a reduced instruction set computing (RISC) architecture, or any other suitable architecture.

[0070] The system memory 1220 may be configured to store compressed or decompressed program instructions 1222 and / or sensor data accessible by the processor 1210. In various embodiments, the system memory 1220 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash type memory, or any other type of memory. In the illustrated embodiment, the program instructions 1222 may be configured to implement any of the functionality described above. In other embodiments, the program instructions and / or data may be received, transmitted, or stored on a different type of computer-accessible medium, or on a similar medium separate from the system memory 1220 or computer system 1200.

[0071] In one embodiment, I / O interface 1230 may be configured to coordinate I / O traffic between processor 1210, system memory 1220, and any peripheral devices within the device, including other peripheral interfaces such as network interface 1240 or input / output devices 1250. In some embodiments, I / O interface 1230 may perform any necessary protocol conversions, timing conversions, or other data conversions to convert data signals from one component (e.g., system memory 1220) into a format suitable for use by another component (e.g., processor 1210). In some embodiments, I / O interface 1230 may include support for devices attached via various types of peripheral buses, such as, for example, variations on the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, the functionality of I / O interface 1230 may be split into two or more separate components, such as, for example, a northbridge and a southbridge. Also, in some embodiments, some or all of the functionality of I / O interface 1230, such as the interface to system memory 1220, may be incorporated directly into processor 1210.

[0072] Network interface 1240 may be configured to allow data to be exchanged between computer system 1200 and other devices connected to network 1285 (e.g., carrier or agent devices) or between nodes of computer system 1200. Network 1285, in various embodiments, includes one or more networks, including, without limitation, a local area network (LAN) (e.g., Ethernet or enterprise network), a wide area network (WAN) (e.g., the Internet), a wireless data network, other electronic data network, or some combination thereof. In various embodiments, network interface 1240 may support communications over a general data network, either wired or wireless, such as, for example, any suitable type of Ethernet network, over a telecommunications / telephony network, such as an analog voice network or a digital fiber communications network, over a storage area network, such as a Fibre Channel SAN, or over any other suitable type of network and / or protocol.

[0073] The input / output devices 1250, in some embodiments, may include one or more display terminals, keyboards, keypads, touch pads, scanning devices, voice or optical recognition devices, or any other devices suitable for inputting or accessing data by one or more computer systems 1200. Multiple input / output devices 1250 may be present within computer system 1200 or distributed on various nodes of computer system 1200. In some embodiments, similar input / output devices may be separate from computer system 1200 and may interact with one or more nodes of computer system 1200 through wired or wireless connections, such as via network interface 1240.

[0074] 12, memory 1220 may include program instructions 1222, which may be processor-executable to perform any of the elements or actions described above. In one embodiment, the program instructions may perform the methods described above. In other embodiments, different elements and data may be included.

[0075] Computer system 1200 may also be connected to other devices not illustrated, or may instead operate as a stand-alone system. Additionally, the functionality provided by the illustrated components may in some embodiments be combined into fewer components or distributed among additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided, and / or other additional functionality may be available.

[0076] While various items are shown as being stored in memory or storage while in use, those skilled in the art will also appreciate that these items, or portions thereof, may be transmitted between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments, some or all of the software components may execute in memory on another device and communicate with the illustrated computer system via computer-to-computer communications. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or portable item that is read by a suitable drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from computer system 1200 may be transmitted to computer system 1200 via a transmission medium or a signal, such as an electrical, electromagnetic, or digital signal, transmitted over a communications medium, such as a network and / or a wireless link. Various embodiments may further include receiving, transmitting, or storing instructions and / or data implemented in accordance with the foregoing description of the computer-accessible medium. Generally, computer-accessible media may include non-transitory computer-readable storage media or memory media such as magnetic or optical media, e.g., volatile or non-volatile media such as disks or DVDs / CD-ROMs, RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc. In some embodiments, computer-accessible media may include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted over a communications medium, such as a network and / or wireless link.

[0077] The methods described herein may be implemented in software, hardware, or a combination thereof. Additionally, the order of blocks of the methods may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. Various modifications and alterations may be made, as would be apparent to one of ordinary skill in the art having the benefit of this disclosure. The various embodiments described herein are intended to be illustrative and not limiting. Many variations, modifications, additions, and improvements are possible. Thus, components described herein as a single instance may be provided with multiple instances. Boundaries between various components, operations, and data stores are somewhat arbitrary, and certain operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are contemplated and may be included within the scope of the following claims. Finally, structures and functionality presented as separate components in illustrative configurations may be implemented as combined structures or components. These and other variations, modifications, additions, and improvements may be included within the scope of the embodiments, as defined in the following claims.

[0078] Embodiments of the present disclosure can be described in light of the following provisions. Clause 1. One or more computing devices configured to implement a data jurisdiction management system, said data jurisdiction management system comprising: Detecting a jurisdiction change event for a vehicle based on the received vehicle information, where vehicle data for the vehicle is stored in a first jurisdiction; determining that one or more portions of the vehicle data stored for the vehicle will be deleted, moved, or retained based on a set of jurisdictional rules, the set of jurisdictional rules being based on data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to a second jurisdiction, or retained in the first jurisdiction based on the determination; the one or more computing devices configured to Including, the system.

[0079] Clause 2. The determining is to move the one or more portions of the vehicle data based on the set of jurisdictional rules; The system further comprises: 1. One or more computing devices configured to implement a data migration system, the data migration system comprising: receiving a migration notification from the data jurisdiction management system identifying the one or more portions of the vehicle data to be moved; moving the one or more portions of the vehicle data stored in the first jurisdiction to the second jurisdiction based on the received transition notification; the one or more computing devices configured to 2. The system of claim 1, comprising:

[0080] Article 3. The data jurisdiction management system further comprises: receiving a rules update that adds, removes, or modifies one or more of the jurisdiction rules of the set of jurisdiction rules; propagating the rule updates to one or more locally stored copies of the set of jurisdiction rules stored in the respective jurisdiction; 3. The system of claim 1 or 2, configured to:

[0081] Clause 4. The vehicle data is further stored in a third jurisdiction, and the jurisdiction change event is between the first jurisdiction and the second jurisdiction, and the data jurisdiction management system further comprises: The system of any of clauses 1-3, further configured to determine, based on the set of jurisdictional rules, that another portion of the vehicle data stored for the vehicle in the third jurisdiction is to be deleted, moved, or retained.

[0082] Clause 5. The data jurisdiction management system further comprises: detecting a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of the second jurisdiction based on the set of jurisdiction rules; initiating a jurisdiction conflict resolution workflow to resolve the conflict; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted, moved, or retained according to an outcome of the conflict resolution workflow; The system according to any one of clauses 1 to 4, configured to:

[0083] Clause 6. Detecting a jurisdiction change event for a vehicle using one or more computing devices configured to implement a data jurisdiction management system, the detecting being based on received vehicle information, and vehicle data for the vehicle being stored in a first jurisdiction; determining, using the data jurisdiction management system, that one or more portions of the vehicle data stored for the vehicle are to be deleted, moved, or retained based on a set of jurisdictional rules for data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to a second jurisdiction, or retained in the first jurisdiction based on the determination; A method comprising:

[0084] Clause 7. Using said data jurisdiction management system, receiving rule updates that add, remove, or modify one or more of said jurisdiction rules in said set of jurisdiction rules; propagating the rule updates to one or more locally stored copies of the set of jurisdiction rules; 7. The method of claim 6, further comprising:

[0085] Clause 8. determining that another portion of the vehicle data stored for the vehicle in a third jurisdiction is deleted, moved, or retained based on the set of jurisdiction rules, wherein the jurisdiction change event is between the first jurisdiction and the second jurisdiction; 8. The method of claim 6 or 7, further comprising:

[0086] Clause 9. Determining that one or more portions of the vehicle data should be stored in a different jurisdiction based on the set of jurisdictional rules; and transmitting one or more vehicle scheme packets to the vehicle based on the determination, the vehicle scheme packets including information identifying a vehicle information destination in the different jurisdiction for information generated by the vehicle; 9. The method according to any one of clauses 6 to 8, further comprising:

[0087] Clause 10. Determining whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; and deactivating an instance of a virtual engine control unit (ECU) of the vehicle in the first jurisdiction based on a determination that the first jurisdiction is not the competent jurisdiction; and activating an instance of a new virtual ECU for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is a jurisdiction having the authority over the vehicle; and 10. The method according to any one of clauses 6 to 9, further comprising:

[0088] Clause 11. Determining whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; and deactivating an instance of a vehicle shadow for the vehicle in the first jurisdiction based on a determination that the first jurisdiction is not the jurisdiction having authority; activating a new vehicle shadow instance for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is a jurisdiction having the authority over the vehicle; and 10. The method according to any one of clauses 6 to 9, further comprising:

[0089] Clause 12. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or between one or more processors, cause the one or more processors to: Detecting a jurisdiction change event for a vehicle based on the received vehicle information, where vehicle data for the vehicle is stored in a first jurisdiction; determining that one or more portions of the vehicle data stored for the vehicle are to be deleted, moved, or retained based on a set of jurisdictional rules regarding data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to a second jurisdiction, or retained in the first jurisdiction based on the determination; Implement a data jurisdiction management system that implements: said one or more non-transitory computer-readable storage media.

[0090] Clause 13. When executed on or between said one or more processors, said one or more processors may receiving a rules update that adds, removes, or modifies one or more of the jurisdiction rules of the set of jurisdiction rules; propagating the rule updates to one or more locally stored copies of the set of jurisdiction rules stored in the respective jurisdiction; 13. One or more non-transitory computer-readable storage media according to clause 12, storing further program instructions causing the implementation of

[0091] Clause 14. When executed on or between said one or more processors, said one or more processors may: detecting a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of the second jurisdiction in the set of jurisdiction rules; One or more non-transitory computer-readable storage media as described in clause 12 or clause 13, further storing program instructions for causing the initiation and the determination to be performed according to a result of the conflict resolution workflow, to resolve the conflict.

[0092] Clause 15. The one or more non-transitory computer-readable storage media of clause 14, wherein the conflict resolution workflow includes a predetermined conflict resolution mechanism including a rule prioritization scheme for resolving the conflict between the jurisdiction rules of the first jurisdiction and the jurisdiction rules of the second jurisdiction.

[0093] Clause 16. The one or more non-transitory computer-readable storage media of clause 15, wherein the rule prioritization scheme is determined using a machine learning model based on a past history of conflict resolution between the one or more jurisdictions.

[0094] Clause 17. Executing the conflict resolution workflow providing a conflict resolution user interface; receiving one or more user decisions to resolve the conflict via the conflict resolution user interface;

[0036] 15. One or more non-transitory computer-readable storage media as described in clause 14,

[0095] Clause 18. One or more non-transitory computer-readable storage media described in any of clauses 12 to 17, wherein the detecting of the jurisdiction change event for the vehicle is further based on a machine learning model trained using a past history of received vehicle information and the jurisdiction rules.

[0096] Clause 19. One or more non-transitory computer-readable storage media according to any of clauses 12-18, wherein the vehicle information used to detect a change in jurisdiction includes Global Positioning System (GPS) data, vehicle registration information, or vehicle service information.

[0097] Clause 20. When executed on or between said one or more processors, said one or more processors determining that the one or more portions of the vehicle data stored for the vehicle are to be copied, partially copied, or denied from being copied based on the set of jurisdictional rules for data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be copied to the second jurisdiction, partially copied to the second jurisdiction, or denied from being copied to the second jurisdiction based on the determination; One or more non-transitory computer-readable storage media according to any of clauses 12 to 19, storing further program instructions for carrying out the above.

Claims

1. 1. One or more computing devices configured to implement a data jurisdiction management system, the data jurisdiction management system comprising: Detecting a jurisdiction change event for a vehicle based on the received vehicle information, wherein vehicle data for the vehicle is stored in a first jurisdiction; determining that one or more portions of the vehicle data stored for the vehicle will be deleted, moved, or retained based on a set of jurisdictional rules, the set of jurisdictional rules being based on data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to a second jurisdiction, or retained in the first jurisdiction based on the determination; the one or more computing devices configured to Including, the system.

2. the determining is to move the one or more portions of the vehicle data based on the set of jurisdictional rules; The system further comprises:

1. One or more computing devices configured to implement a data migration system, the data migration system comprising: receiving a migration notification from the data jurisdiction management system identifying the one or more portions of the vehicle data to be moved; moving the one or more portions of the vehicle data stored in the first jurisdiction to the second jurisdiction based on the received transition notification. The system of claim 1 , comprising:

3. The data jurisdiction system further comprises: receiving a rules update that adds, removes, or modifies one or more of the jurisdiction rules of the set of jurisdiction rules; propagating the rule updates to one or more locally stored copies of the jurisdiction rule sets stored in the respective jurisdictions; The system according to claim 1 or claim 2, configured to:

4. The vehicle data is further stored in a third jurisdiction, and the jurisdiction change event is between the first jurisdiction and the second jurisdiction, and the data jurisdiction management system further comprises: and configured to determine, based on the set of jurisdictional rules, to delete, move, or retain another portion of the vehicle data stored for the vehicle in the third jurisdiction. A system according to any one of claims 1 to 3.

5. The data jurisdiction management system further comprises: determining that the one or more portions of the vehicle data stored for the vehicle are to be copied, partially copied, or denied from being copied based on the set of jurisdictional rules for data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be copied to the second jurisdiction, partially copied to the second jurisdiction, or denied from being copied to the second jurisdiction based on the determination; The system according to any one of claims 1 to 4, configured to:

6. The data jurisdiction management system further comprises: detecting a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of the second jurisdiction based on the set of jurisdiction rules; initiating a jurisdiction conflict resolution workflow to resolve the conflict; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted, moved, or retained according to an outcome of the conflict resolution workflow; The system according to any one of claims 1 to 5, configured to:

7. 7. The system of claim 6, wherein the conflict resolution workflow includes a predetermined conflict resolution mechanism including a rule prioritization scheme for resolving the conflict between the jurisdictional rules of the first jurisdiction and the jurisdictional rules of the second jurisdiction.

8. 8. The system of claim 7, wherein the rule prioritization scheme is determined using a machine learning model based on a past history of conflict resolution between the one or more jurisdictions.

9. executing the conflict resolution workflow, providing a conflict resolution user interface; receiving one or more user decisions to resolve the conflict via the conflict resolution user interface; The system of claim 6 , comprising:

10. Detecting a jurisdiction change event for a vehicle using one or more computing devices configured to implement a data jurisdiction management system, the detecting being based on received vehicle information, and vehicle data for the vehicle being stored in a first jurisdiction; determining, using the data jurisdiction management system, that one or more portions of the vehicle data stored for the vehicle are to be deleted, moved, or retained based on a set of jurisdictional rules for data storage requirements for the vehicle; causing the one or more portions of the vehicle data stored in the first jurisdiction to be deleted from the first jurisdiction, moved to a second jurisdiction, or retained in the first jurisdiction based on the determination; A method comprising:

11. receiving a rule update using the data jurisdiction management system to add, remove, or modify one or more of the jurisdiction rules in the set of jurisdiction rules; propagating the rule updates to one or more locally stored copies of the set of jurisdiction rules; The method of claim 10 further comprising:

12. determining, based on the set of jurisdictional rules, that another portion of the vehicle data stored for the vehicle in a third jurisdiction is deleted, moved, or retained, wherein the jurisdictional change event is between the first jurisdiction and the second jurisdiction; The method of claim 10 or claim 11, further comprising:

13. determining, based on the set of jurisdictional rules, that one or more portions of the vehicle data should be stored in a different jurisdiction; transmitting one or more vehicle scheme packets to the vehicle based on the determination, the vehicle scheme packets including information identifying a vehicle information destination in the different jurisdiction for information generated by the vehicle; The method of claim 10 further comprising:

14. determining whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; deactivating an instance of a virtual engine control unit (ECU) of the vehicle in the first jurisdiction based on a determination that the first jurisdiction is not the competent jurisdiction; activating an instance of a new virtual ECU for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is the jurisdiction having the authority over the vehicle; and The method of any one of claims 10 to 13, further comprising:

15. determining whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; deactivating an instance of a vehicle shadow for the vehicle in the first jurisdiction based on a determination that the first jurisdiction is not the authorized jurisdiction; and activating a new vehicle shadow instance for the vehicle in the second or other jurisdiction based on an additional determination that the second or other jurisdiction is a jurisdiction having the authority over the vehicle; and The method of any one of claims 10 to 13, further comprising:

Images