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, with the increasing adoption of technologies such as distributed cloud computing and the digitalization of various industries, data has become a critical component of the modern global economy. As the importance of data has increased, so has the interest of various jurisdictions, such as countries, to regulate data storage and transmission. One such regulation is data residency, which 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 data retention and / or use. Such requirements or regulations affect the use of IT infrastructure and affect operations that create, process, store, protect, and exchange electronic data, including data about vehicles. [Brief explanation 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. [Figure 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 migrates vehicle data to one or more jurisdictions, according to some embodiments. [Figure 3]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, 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. [Figure 5] 1 illustrates a more detailed diagram of an exemplary 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] 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 exemplary computer system that may implement some or all of the techniques described herein, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0003] While 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 forms disclosed; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling 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 the permissive sense (i.e., meaning having the potential to), rather than the 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 across multiple jurisdictions. With the increasing importance of data in the modern economy and the increasing complexity of its computing environments, public authorities have voiced concerns regarding data security, retention, and / or sharing. As a result, some governments have determined that mandating data residency—i.e., the requirement that data content be processed and stored on IT systems within the boundaries of a particular jurisdiction—provides an additional layer of security. Additionally, some countries have mandated privacy-related protections, such as restrictions on data retention and sharing. Data residency and data privacy primarily reflect a combination of issues 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 various countries, as data residency and / or privacy requirements affect operations that create, process, store, and exchange many forms of electronic data between infrastructure assets across borders. Various data storage and transfer regulations may also conflict with one another, 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 input from these sensors and determine various control actions to be taken for the vehicle or its systems. Some vehicles may contain as many as 70 such electronic control units (ECUs) and 20–30 sensor modalities. Furthermore, modern vehicles rely more heavily on sensors, generating more data than previous vehicles. For example, autonomous, semi-autonomous, or self-driving vehicles may include multiple cameras, radars, audio microphones, and the like. Such sensors may generate large amounts of data that are stored in various jurisdictions. 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 subject to security assessment by government authorities before it can be transferred abroad. 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 by 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 challenging, as vehicles may cross borders into new jurisdictions and be registered in new locations. Furthermore, because vehicles are mobile, these jurisdictional changes may occur repeatedly. Therefore, applying various jurisdictional regulations and migrating the resulting vehicle data to the correct jurisdiction becomes a significant issue.

[0006] A 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 interconnection of connected vehicle services located in different jurisdictions and automatically detect vehicle signals or other vehicle information that can be used to determine a vehicle's jurisdiction change. A vehicle data streaming system may manage a pipeline / flow of vehicle data from external sources, including vehicles or associated vehicle service centers, and transmit that information to the data jurisdiction system. A data jurisdiction system (either as part of a vehicle data management service or separate from the vehicle data management service) may interconnect instances of a 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 different and independent jurisdictional rules, which can result in conflicts between 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. Migration jobs are tasks that delete, partially or completely copy, or partially or completely move data remaining in one jurisdiction, such as a vehicle shadow, to another jurisdiction, such as a vehicle shadow in another jurisdiction. Interconnected data jurisdiction systems can maintain a single synchronized view of the corpus of vehicle identification numbers (VINs), the current associated jurisdiction for each VIN, and the jurisdiction with the data associated with each VIN. This can be used by the data jurisdiction system to determine the appropriate jurisdiction to connect to for a vehicle or external application (e.g., a mobile application).

[0008] FIG. 1 illustrates a vehicle data management system and data jurisdiction system that determines a vehicle's jurisdictional change, resolves conflicts between jurisdictional rules (if necessary), and retains, deletes, or migrates the vehicle's data to one or more other jurisdictions in accordance with the jurisdictional rules. 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 geographic regions or territories within which authority affecting the management of vehicle data is exercised. In some embodiments, jurisdictions may be based on countries representing separate sovereign polities, such as the United States. In other embodiments, jurisdictions may be based on states or territories that subdivide a country into separate jurisdictions, such as California and San Francisco. Jurisdictions may further consist 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 depicts each vehicle data management system 110a, 110b, and 110c as being comprised of respective components, each of the systems comprising the vehicle data management systems may be external to and independent of vehicle data management systems 110a, 110b, and 110c.

[0010] In some embodiments, vehicle 150 may generate one or more vehicle information 106 to transmit to vehicle data streaming system 120a. In some embodiments, vehicle 150 may transmit vehicle information 106 including data such as video frames, images, radar amplitude, temperature data, engine speed, and other information about vehicle 150. Vehicle information 106 may include Global Positioning System (GPS) information determined using cellular, radio passive, satellite, and other types of GPS systems. In some embodiments, the geographic location of vehicle 150 may be determined in various ways. For example, in some embodiments, GPS may be used, or a 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 of 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 series of vehicle data records generated by one or more data producers (e.g., vehicles 150, vehicle service centers 160) and that may be accessed by one or more data consumers.

[0012] Upon receiving vehicle information 106, vehicle data streaming system 120a may use vehicle information 106 to detect a jurisdiction change event. In some embodiments, detection of a change in jurisdiction for vehicle 150 may be performed by data jurisdiction system 124a instead of vehicle data streaming system 120a. A jurisdiction change event may be inferred or estimated based on a single, clear indication of a vehicle jurisdiction change, such as a change in registration information from 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, and vehicle location history. A jurisdiction change event may further be detected or inferred based on one or more machine learning models trained using past history of vehicle information 106 and jurisdiction rules 128a, as further described in FIGS. 2 and 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 migrations 170a, 170b, and 170c, respectively. However, in some embodiments, application of the set of jurisdiction rules may result in the continued retention of vehicle data, regardless of migration, or the 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 the 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. Jurisdiction rules 128a may include rules based on the jurisdiction of a 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. Jurisdiction rules 128a, 128b, and 128c may be added, deleted, or modified and may be synchronized between multiple jurisdictions. Synchronization of 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 identifying one or more portions of vehicle data to be moved. The migration of vehicle data may involve vehicle migration systems 140a, 140b, and 140c in each jurisdiction 102a, 102b, and 102c. In some embodiments, the data migration system 140a may transfer 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. In some embodiments, the workflow engine 130a communicates with other data jurisdiction systems in which data related to the associated VIN is stored. The workflow engine 130a may reconcile applicable regulations and priorities associated with each vehicle data to determine a transition strategy to be implemented for all affected jurisdictions.

[0015] In some embodiments, the jurisdiction rules engine 128a may determine that a jurisdictional conflict exists between one or more rules in the set of jurisdiction rules 128a that have been selected to apply. The jurisdiction rules engine 126a may initiate a jurisdiction conflict resolution workflow to resolve the conflict. The workflow engine 130a may resolve conflicts between jurisdiction rules 128a using a predetermined prioritization scheme. In some embodiments, manual resolution may be required in a conflict resolution workflow in which 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 FIGS. 8 and 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] 2, vehicle 150 and vehicle service center 160 may send vehicle information 106 to vehicle data streaming system 120a, as described in FIG. 1. In some embodiments, vehicle data streaming system 120a may include a jurisdiction change event detection engine 122a that detects a jurisdiction change event for vehicle 150. Jurisdiction change event detection engine 122a may interpret one or more of vehicle information 106 to detect a jurisdiction change event and, based on the change in jurisdiction, send a jurisdiction change event 202 to jurisdiction rules engine 126a. Although vehicle data streaming system 120a is shown in FIG. 1 as being part of vehicle data management system 110a, vehicle data streaming system 120a may be a separate system external to vehicle data management system 110a. Jurisdiction change event 202 may be communicated to 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 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) from 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 vehicle's jurisdiction, or any combination thereof. The jurisdiction rules 128a may be added, removed, or modified and may be synchronized across 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, jurisdictional rules engine 126a initiates a workflow for workflow engine 130a to create / update routing rules 278 and / or migration jobs 206. Once the jurisdictional rules that apply to the vehicle data are determined, workflow engine 130a creates routing rules 278 for vehicle data streaming system 120a and / or migration jobs for data migration system 140a. Vehicle migration system 140a migrates the vehicle data to another jurisdiction 208 as determined by the workflow engine in accordance with jurisdictional rules 128a. In some embodiments, vehicle data streaming system 120a routes the incoming vehicle information to another jurisdiction 280 based on routing rules 278 as determined by workflow engine 130a in accordance with jurisdictional rules 128a. The routing rules may include various parameters for routing the incoming vehicle information 106, such as a time period, vehicle information type, jurisdictional destination, VIN, etc.

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

[0021] 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 jurisdictional rule training data 344 may further include information related to past jurisdictional change events (such vehicle identification information for vehicles that experienced jurisdictional change events), associated vehicle information, and applied jurisdictional rules. The jurisdictional change event model 338 may be transmitted to the vehicle data streaming system 120a or the jurisdictional rule engine 126a. The transmitted jurisdictional change event model 338 may be used to determine whether one or more of the received vehicle information results in a jurisdictional change event.

[0022] In some embodiments, data jurisdiction system 124a may include a jurisdiction rules interface 328a that may retrieve / update jurisdiction rules 312 in jurisdiction rules engine 126a. Jurisdiction rules interface 328a may retrieve a set of jurisdiction rules 128a stored in jurisdiction rules engine 126a and may further provide an interface for adding, deleting, or modifying one or more of the jurisdiction rules in the set of jurisdiction rules. In some embodiments, updates to 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 jurisdiction machine learning system 320 may further include a jurisdiction rule application machine learning engine 340 that receives jurisdiction rule training data 344 of vehicle information related to past jurisdiction change events similar to that provided to the jurisdiction change event machine learning engine 330. The jurisdiction rule training data 344 may include vehicle identification information of vehicles that experienced jurisdiction change events, their associated vehicle information, and applied jurisdiction rules. The jurisdiction rule application machine learning engine 340 may be used to train a machine learning model to determine jurisdiction rules to apply to vehicles based on the jurisdiction change events. The jurisdiction rule application machine learning engine 340 may send a jurisdiction rule application event model 348 to the jurisdiction rule engine 126a, which may use the trained model to determine which jurisdiction rules 128a to apply to vehicles that experienced jurisdiction rule change events.

[0024] The jurisdictional rules engine 126a may initiate a workflow to resolve the jurisdictional rule conflict 304 when a conflict in one or more jurisdictional rules is detected among the jurisdictional rules 128a determined to apply to the vehicle data. In some embodiments, the workflow engine may use a predetermined conflict resolution mechanism, such as a predetermined prioritization scheme 360, to determine which jurisdictional rules among the conflicting rules to apply. The predetermined prioritization scheme 360 ​​may be a set of instructions regarding how the conflicting jurisdiction rules 128a are resolved based on various factors, such as the type of jurisdictional rule, the vehicle identification information, and the affected vehicle data. The predetermined prioritization scheme 360 ​​may determine which of the one or more jurisdictional rules 128a among the conflicting rules applies to one or more data of the vehicle. In some embodiments, jurisdictional 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 a workflow to resolve conflicts instead of or in combination with the rule prioritization scheme 360. The jurisdictional rule 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 rule conflict resolution interface 314 may be used to provide an interface that requests one or more user decisions to resolve the conflict. The jurisdictional rule 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 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, vehicle jurisdiction 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 sends a jurisdictional rule conflict resolution model 354 to workflow engine 130a. Jurisdiction 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, jurisdictional rule conflict resolution training data 358 may include a past history of user decisions from jurisdictional rule conflict resolution interface 314, such as choosing between two conflicting jurisdiction rules, ranking the priority of jurisdiction rules, and determining the importance of vehicle data. Jurisdiction rule conflict resolution machine learning engine 350 may use the received jurisdictional rule conflict resolution training data 358 to generate jurisdictional rule conflict resolution model 354. The jurisdictional rule conflict resolution machine learning engine 350 may send the jurisdictional rule conflict resolution model 354 to the workflow engine 130a, and the trained model 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 rules are determined, the workflow engine creates routing rules and / or migration jobs for the data migration system based on the jurisdictional rules.

[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 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 multiple jurisdictions. Any respective changes to jurisdiction rules 128a, 128b, and 128c by each jurisdiction rules interface 328a, 328b, and 328c trigger the jurisdiction rules engines 126a, 126b, and 126c to synchronize jurisdiction rules 480 with their counterparts in 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, allowing 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 jurisdiction rules 410a, such as adding, deleting, or modifying one or more of jurisdiction rules 128a, may be replicated asynchronously, with the changes stored in a queue in data jurisdiction system 124a and then propagated to other systems. In some embodiments, replication of various updates to 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 providing a single authoritative view of jurisdiction rules may include a mixture 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 state 496 to maintain a single authoritative view of vehicle state across 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 state between the physical vehicle and the vehicle shadow itself in real time. The vehicle shadow may retrieve / update vehicle state 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, jurisdiction systems 124a, 124b, and 124c may synchronize information regarding where portions of vehicle data are stored in 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 their respective updates. In some embodiments, vehicle state updates may be triggered by the movement of vehicle data from one jurisdiction to another as the vehicle's jurisdiction 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 rules, similar to that of FIG. 4A , may be provided using multi-reader replication, allowing data to be stored and updated by any member of the group. In some embodiments, replication between locally stored vehicle shadows 492a may be asynchronous, with updates to the vehicle state 490a being queued and then propagated. In some embodiments, replication between locally stored vehicle shadows 492a of various updates to the vehicle state 490a may be synchronous, with changes being performed across 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, instead of vehicle shadow 492a, other systems that provide vehicle state may be synchronized instead 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 of jurisdiction for 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] 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. 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. While FIG. 1 depicts each vehicle data management system 110a, 110b, and 110c as being comprised of respective components, each of the systems comprising the vehicle data management system may be external to and independent of the vehicle data management system.

[0034] In some embodiments, vehicle data streaming system 120a may receive vehicle information from vehicle 150, vehicle service center 160, or other source that also indicates a change of jurisdiction from jurisdiction C 102a to jurisdiction B 102b. In applying the relevant jurisdiction rules 128a and resolving any jurisdiction rule conflicts that may arise (as discussed in FIGS. 2 and 3), the jurisdiction system may determine (510) that vehicle data from both jurisdictions A and C will be migrated. The determination may be based on synchronized vehicle state, including information about the location of the vehicle data. Once data jurisdiction system 124a determines (510) that vehicle data from both jurisdictions A and C will be migrated, workflow engine 130a initiates data routing / migration of vehicle data stored in jurisdiction C. 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. Based on the determination, 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. In some embodiments, the vehicle data streaming system 120c may route 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 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 transition 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 the 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 , vehicle 150 may transmit vehicle information 106 to vehicle data streaming system 120a via network 620 to vehicle data streaming system 120a. Vehicle 150 may transmit vehicle information 160 to vehicle data streaming system 120a in jurisdiction A 102a according to a configuration setting having jurisdiction A 102a as the destination for vehicle information 106. In some embodiments, the destination configuration setting may be a specific data center or availability zone within the jurisdiction. Network 620 may be a private or public network, such as a direct connection to the service provider network hosting vehicle data streaming system 120a or an Internet connection. Additionally, network 620 may be a wireless network, such as a cellular network, Wi-Fi network, or other wireless network. Although not specifically shown in FIG. 6A , in some embodiments, 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 send / receive vehicle information 630a to / from the vehicle shadow 492a, the virtual engine control unit (ECU) 610a, and the data jurisdiction system 124a of jurisdiction A 102a. Jurisdiction A 102a may be the jurisdiction in which the vehicle shadow 492a and / or the vehicle ECU 610a are the preferred primary instances for updating and synchronizing the vehicle 150. As described in FIG. 4B , the vehicle shadow 492a stored locally in jurisdiction A 102a 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. In some embodiments, the vehicle shadow 492a may send / 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 multiple sensors in the vehicle, interpret sensor data, and adjust the vehicle's controlled systems. 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 vehicle's jurisdiction. 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 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 jurisdiction A 102a. The data jurisdiction system 124b also cooperates to activate the instance 660 of the vehicle shadow 492b and virtual ECU 610b implemented in 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 jurisdiction A 102a to jurisdiction B 608. In other embodiments, the deactivation / activation of the vehicle shadow 494b, 492b and virtual ECUs 610a, 610b may not involve a data migration but may occur independently based on jurisdiction rules 128a, 128b. In some embodiments, a snapshot 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 an unauthorized instance. 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 in accordance with 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 in jurisdiction of vehicle 150 from jurisdiction A 102a to jurisdiction B 102b may result in data jurisdiction system 124a in jurisdiction A 102a sending a vehicle scheme packet to the vehicle to modify the destination to which 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 data system 124b in 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 by vehicle data streaming system 120b may be used to update various vehicle shadow 492b attributes, as discussed in FIG. 4B. Virtual ECU 610b may also send / receive vehicle information 630b from vehicle 150 via network 620. As discussed in FIG. 6A, the virtual ECU may be used to control numerous sensors in the vehicle, interpret sensor data, and adjust engine actuators from jurisdiction B 102b. As discussed in FIG. 2, vehicle information 106 sent to vehicle data streaming system 120a, in conjunction with data jurisdiction system 124a and vehicle transition system 140a, may detect changes in the vehicle's jurisdiction and subsequent downstream application of jurisdiction rules 128a using jurisdiction rules engine 126a and workflow engine 130a.

[0044] FIG. 7 illustrates a flowchart of operations performed by a data jurisdiction system to determine a change in jurisdiction for a vehicle based on a set of jurisdiction rules, resolve conflicts between 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, clear indication of a change in vehicle jurisdiction, 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 jurisdiction change event may be detected using a vehicle data streaming system of the vehicle data management system.

[0046] At block 720, the data jurisdiction system determines that one or more portions of the vehicle data stored in the first jurisdiction will be deleted, moved, or retained based on a set of jurisdictional rules for vehicle data storage requirements. The set of jurisdictional 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 experienced jurisdiction change events, their associated vehicle information, applied jurisdiction rules, and other vehicle information to determine which jurisdictional 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 migration strategy that affects the strategies of multiple other jurisdictions and causes the data stored in the other jurisdictions to be moved to the second jurisdiction.

[0048] FIG. 8 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.

[0049] In block 810, the data jurisdiction system determines whether a conflict exists between jurisdiction rules of a first jurisdiction and jurisdiction rules of a 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] In 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 Figures 3 and 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 Figure 3, the machine learning model may be trained using not only the past history of conflict resolution, but also other data relevant to resolving 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 jurisdiction rules of the first jurisdiction and jurisdiction rules of the second jurisdiction using a conflict resolution mechanism including a rule prioritization scheme. The predetermined prioritization scheme may be a set of instructions regarding 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 predetermined prioritization scheme may determine which of the one or more jurisdiction rules of the conflicting rules to apply to one or more data of the vehicle.

[0053] FIG. 9 illustrates a flowchart for implementing the conflict resolution workflow of the vehicle data jurisdiction system 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 visualize the conflicts and enable configuration and resolution of the conflicts. In some embodiments, the conflicts presented to the user via the interface may translate the conflicts in the jurisdiction's 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 specifying 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 shows a flowchart of the operations performed by the 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 the jurisdiction having 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 for 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 for the first jurisdiction may be stored in the first jurisdiction, as discussed in FIG. 6B .

[0060] In 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 the instance of the vehicle shadow for 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 for the first jurisdiction may be stored in the first jurisdiction, as discussed in FIG. 6B .

[0062] In 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 the 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 shows a flow chart of the 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 the vehicle's jurisdiction, 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 a GPS signal, 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 containing 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 exemplary computer system 1200 that can be used to implement a vehicle data management system and a data jurisdiction system such as those described above with reference to Figures 1-11. In different embodiments, computer system 1200 may be any of a variety of types of device, including, but not limited to, a personal computer system, a desktop computer, a laptop, a notebook, a tablet, a slate, a pad, or a 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, a modem, a router, or generally any type of computing 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 jurisdictional rules, resolving conflicts between jurisdictional rules, and migrating vehicle data to one or more other jurisdictions may be executed on one or more computer systems 1200, which may interact with various other devices. Note 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 display(s) 1280. While in some cases, as described above for various embodiments, 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 comprising computer system 1200, may be configured to host different portions or instances of 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 implementing 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 implementation may implement a reduced instruction set computing (RISC) architecture, or any other suitable architecture.

[0070] System memory 1220 may be configured to store compressed or decompressed program instructions 1222 and / or sensor data accessible by processor 1210. In various embodiments, 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, program instructions 1222 may be configured to implement any of the functionality described above. In other embodiments, program instructions and / or data may be received, sent, or stored on a different type of computer-accessible medium, or on a similar medium separate from 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 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 between two or more separate components, such as 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., an 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 communication over a wired or wireless general data network, such as 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] Input / output devices 1250, in some embodiments, may include one or more display terminals, keyboards, keypads, touchpads, 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 alternatively, may operate as a stand-alone system. Furthermore, 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 stored in memory or storage while in use, those skilled in the art will also understand 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 readable by an appropriate 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 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 a computer-accessible medium. Generally, computer-accessible media may include non-transitory, computer-readable storage or memory media such as magnetic or optical media, e.g., disks or DVDs / CD-ROMs, volatile or non-volatile media such as 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 method blocks may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. Various modifications and variations 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. Accordingly, 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 particular 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 by the following claims.

[0078] Embodiments of the present disclosure can be described in light of the following clauses. 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, 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; Based on the determination, 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; the one or more computing devices configured to: Including, the system.

[0079] Clause 2. said determining is to move said one or more portions of said vehicle data based on said 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 migration notification; the one or more computing devices configured to: 2. The system of claim 1, comprising:

[0080] Article 3. The Data Jurisdiction Management System shall further: receiving a rules update that adds, removes, or modifies 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 jurisdiction rule sets stored in the respective jurisdictions; 2. 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, 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.

[0082] Clause 5. The Data Jurisdiction Management System further: 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; 5. The system of 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, wherein the detecting is based on received vehicle information, and vehicle data for the vehicle is stored in a first jurisdiction; using the data jurisdiction management system to determine 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; Based on the determination, 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; 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 clause 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 clause 6 or clause 7, further comprising:

[0086] Clause 9. Determining, based on said set of jurisdictional rules, that one or more portions of said vehicle data should be stored in a different jurisdiction; 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 of any one of clauses 6 to 8, further comprising:

[0087] Clause 10. Determining whether said first jurisdiction, said second jurisdiction, or another jurisdiction is a jurisdiction having authority over said 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 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 jurisdiction having the authority over the vehicle; and 10. The method of any one of clauses 6 to 9, further comprising:

[0088] Clause 11. Determining whether said first jurisdiction, said second jurisdiction, or another jurisdiction is a jurisdiction having authority over said 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 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 the jurisdiction having the authority over the vehicle; and 10. The method of 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, 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 are to be deleted, moved, or retained based on a set of jurisdictional rules regarding data storage requirements for the vehicle; Based on the determination, 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; Implement a data jurisdiction management system that implements: the one or more non-transitory computer-readable storage media.

[0090] Clause 13. When executed on or between said one or more processors, causes said one or more processors to: receiving a rules update that adds, removes, or modifies 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 jurisdiction rule sets stored in the respective jurisdictions; 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, causes said one or more processors to: detecting a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of the second jurisdiction in the set of jurisdiction rules; and initiating a jurisdiction conflict resolution workflow to resolve the conflict, wherein the determining is performed according to a result of the conflict resolution workflow.

[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 said conflict resolution workflow comprises: providing a conflict resolution user interface; receiving one or more user decisions to resolve the conflict via the conflict resolution user interface;

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

[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 described in any of clauses 12 to 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, causes said one or more processors to: 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 regarding data storage requirements for the vehicle; Based on the determination, 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; 20. One or more non-transitory computer-readable storage media according to any of clauses 12 to 19, storing further program instructions to cause the implementation of

Claims

1. 1. One or more computing devices configured to implement a data jurisdiction management system, wherein jurisdictions correspond to areas to which predetermined data policies apply, said 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; detecting a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of a second jurisdiction based on the set of jurisdiction rules; initiating a jurisdiction conflict resolution workflow to resolve the conflict; Based on the determination and in accordance with an outcome of the conflict resolution workflow, causing the 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; the one or more computing devices configured to perform 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; and moving the one or more portions of the vehicle data stored in the first jurisdiction to the second jurisdiction based on the received migration notification. The system of claim 1 , comprising:

3. The data jurisdiction management system further comprises: receiving a rules update that adds, removes, or modifies 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 jurisdiction rule sets stored in the respective jurisdictions; The system of claim 1 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 determining, 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. The 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 regarding data storage requirements for the vehicle; Based on the determination, 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; The system of claim 1 configured to:

6. 2. The system of claim 1, 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.

7. The system of claim 6 , 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.

8. 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 1 , comprising:

9. A method executed by one or more computing devices configured to implement a data jurisdiction management system, wherein the jurisdictions correspond to areas to which predetermined data policies apply; Detecting, by the one or more computing devices, a jurisdiction change event for a vehicle, the detecting being based on received vehicle information, and vehicle data for the vehicle being stored in a first jurisdiction; determining, by the one or more computing devices, to delete, move, or retain one or more portions of the vehicle data stored for the vehicle based on a set of jurisdictional rules regarding data storage requirements for the vehicle; detecting, by the one or more computing devices, a conflict between jurisdiction rules of the first jurisdiction and jurisdiction rules of a second jurisdiction based on the set of jurisdiction rules; initiating, by the one or more computing devices, a jurisdictional conflict resolution workflow to resolve the conflict; based on the determination and in accordance with a result of the conflict resolution workflow, removing, by the one or more computing devices, from the first jurisdiction, moving to the second jurisdiction, or retaining in the first jurisdiction, the one or more portions of the vehicle data stored in the first jurisdiction; A method comprising:

10. receiving, by the one or more computing devices, a rules update that adds, removes, or modifies one or more of the jurisdiction rules in the set of jurisdiction rules; propagating, by the one or more computing devices, the rule updates to one or more locally stored copies of the set of jurisdiction rules; 10. The method of claim 9, further comprising:

11. Determining, by the one or more computing devices, that another portion of the vehicle data stored for the vehicle will be deleted, moved, or retained in a third jurisdiction based on the set of jurisdiction rules, wherein the jurisdiction change event is between the first jurisdiction and the second jurisdiction; 10. The method of claim 9, further comprising: determining, by the one or more computing devices, based on the set of jurisdictional rules, that one or more portions of the vehicle data should be stored in a different jurisdiction; and transmitting, by the one or more computing devices, 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; 10. The method of claim 9, further comprising: determining, by the one or more computing devices, whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; and deactivating, by the one or more computing devices, 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, by the one or more computing devices, an instance of a new virtual ECU for the vehicle in the second or other jurisdiction based on a further determination that the second or other jurisdiction is the jurisdiction having the authority over the vehicle; and The method of any one of claims 9 to 12, further comprising: determining, by the one or more computing devices, whether the first jurisdiction, the second jurisdiction, or another jurisdiction is a jurisdiction having authority over the vehicle; and deactivating, by the one or more computing devices, an instance of a vehicle shadow for the vehicle in the first jurisdiction based on a determination that the first jurisdiction is not the competent jurisdiction; and activating, by the one or more computing devices, 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 the jurisdiction having the authority over the vehicle; and The method of any one of claims 9 to 12, further comprising:

Images