Determination of Program Operation Sequence for Reducing Potential Leakage of Personal Identification Information

Abstract

To provide a method.SOLUTION: Determination of a program operation sequence for reducing potential leakage of personal identification information includes: identifying a plurality of candidate program operations of taking a data sample including first class information and second class information, and reducing the second class information of the data sample; allocating leakage cost indicating potential leakage of personal identification information associated with various effective combinations of a candidate program operation among a plurality of candidate program operations and a calculation resource among a plurality of calculation resources; applying an objective function to the effective combination and the allocated leakage cost, and determining a sequence of the program operation, wherein the respective program operations of the sequence are performed by the one or more selected calculation resources so that total leakage cost is less than threshold leakage cost and an amount of the first class information becomes larger than a data threshold.SELECTED DRAWING: Figure 6

Description

Background Art

[0001] In-vehicle sensors have become even more common. With the advent of autonomous driving, not only conventional cameras but also arrays of sensors such as GPS and LiDAR have been added to vehicles. With these combinations of sensors, a vehicle can obtain a detailed representation of the world around the vehicle. Most of the sensor data that makes up this representation is overwritten due to storage issues, but some of the information is stored for the purpose of generating simulation environments for training and prediction of ADAS, maps, etc. using information that is executable live or historical information. The usefulness of this information increases with quality. Generally, as the quality of information increases, the required data transfer and storage capacity also increases.

Brief Description of the Drawings

[0002] Aspects of the present disclosure are best understood by reading the following detailed description with reference to the accompanying drawings. Note that various features are not drawn to scale according to standard practice in the industry. In fact, for clarity of explanation, the dimensions of various features may be arbitrarily increased or decreased.

[0003]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0004] The following disclosure provides numerous different embodiments or examples implementing various features of the provided subject matter. To simplify the present disclosure, specific examples regarding components, values, operations, materials, arrangements, or the like are described below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like are envisioned. For example, forming a first feature above or on top of a second feature in the following description may include embodiments where the first and second features are formed in direct contact, and embodiments where additional features may be formed between the first and second features such that the first and second features may not be in direct contact. Additionally, the present disclosure may repeat reference numbers and / or reference characters in various examples. This repetition is for purposes of simplification and clarity and does not in itself define the relationship between the various embodiments and / or configurations being described.

[0005] Furthermore, spatially relative terms such as "below", "beneath", "under", "lower than", "above", "higher than", and the like may be used herein to facilitate descriptions of the relationship of one element or feature to another element or feature as shown in the figures. Spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. The device may be in other orientations (rotated 90 degrees or other orientations), and the spatially relative descriptions used herein may be interpreted accordingly.

[0006] As the quality of information increases, the likelihood that the information is sufficient to identify a person increases, and the likelihood of transmitting irrelevant information increases. For example, a full-quality image of a crowd may easily identify an individual, but even if facial information is removed / blurred, it may be possible to determine identity by a combination of height, clothing, location, time, etc. Depending on the query, only specific information may be useful, and by filtering out other information, the likelihood of retaining personally identifiable information (PII) or information that can regenerate PII is reduced.

[0007] At least some embodiments of the disclosure of the subject matter described herein take into account the effects of filtering and compression on PII in the overall determination of calculation and location in the stages of vehicle sensors with respect to a cloud network, thereby balancing the levels of filtering and compression at each stage of the vehicle sensors with respect to the cloud network.

[0008] To obtain useful information from vehicle sensors through the cloud, the samples detected by the sensors include both a first class of information that is useful and a second class of information that is not usable. As the sample data passes through the stages, the second class of information is reduced according to a program operation sequence determined by at least some embodiments. The sequence according to at least some embodiments attempts to globally minimize or remove the second class of information based on the time the sample data is stored in cloud storage. In at least some embodiments, resources are allocated to perform detection, filtering, compression, transmission, etc. of information through the stages.

[0009] Various filters, compressors, and analyzers are determined for use at various stages in the sequence according to at least some embodiments, where the stages differ with respect to the complexity of the calculations. For example, removing color information from an image is relatively simple compared to object detection in terms of the complexity of the calculations.

[0010] The computational cost and the transmission cost also vary by stage. For example, adding processing resources to the sensor is costly, but transmitting data from the sensor to the next level is not. In contrast, adding processing resources to the cloud is not costly, but transmitting data from vehicle storage to the cloud is costly.

[0011] The likelihood of PII leakage also varies by stage. For example, in at least some embodiments, filtering or compression in a sensor is assigned a significantly low likelihood of PII leakage. In contrast, in at least some embodiments, filtering or compression at the cloud level is assigned a significantly high likelihood of PII leakage. In at least some embodiments, the likelihood assigned with respect to PII leakage further varies by the level or type of compression or filtering. In at least some embodiments, the likelihood assigned with respect to PII leakage for removing pornographic information from an image is maintained relatively high compared to object detection that reduces the image to a number of encoded observational representations.

[0012] In at least some embodiments, the overall determination of computation and location within the stage of a vehicle sensor relative to a cloud network involves evaluating a set of computing resources and a set of program operations, where each operation has a flow requirement representing the amount of data that needs to be processed by the resources, and each resource has a capacity representing the amount of data that each resource can process. In at least some embodiments, each pair of a given resource and a given operation is associated with a cost for that pair. In at least some embodiments, the cost is represented alone or in combination with conventional transmission and computation costs in terms of the likelihood of PII leakage.

[0013] Users such as software developers, insurance providers, market researchers, and law enforcement officers can use an on-demand data retrieval (ODDR) system to input data requests into a user interface such as a graphical user interface (GUI). The software developer is, for example, a software developer who develops an application, middleware, or an OS (operating system) that runs on a vehicle. Exemplary applications include an autonomous driving system application, such as an object recognition application, a road recognition application, a sensor fusion application, a localization application, a path planner application, a controller application, and the like. The data request is analyzed and stored in a server and then sent by the server to the vehicle. On the server side, the data request is stored in a storage unit, and a request queue is generated based on the stored request. The user can check or request an update regarding the status of the data request. For example, while the data request is still in the server before being sent to the vehicle, the status can be indicated as "pending". When the server sends the data request to the vehicle, the status can be updated to "sent". Thereby, the user can check and track the status of the data request made to the vehicle. Although the description refers to a vehicle for clarity, those skilled in the art will recognize that the description is applicable to a group of vehicles in addition to a single vehicle.

[0014] The user interface that generates data requests includes vehicle-related forms that identify information, the type of data requested, start time, and end time. In some embodiments, the start time and end time are absolute times, such as UNIX time which is the elapsed time from the UNIX epoch time. In some embodiments, the start time and end time are relative times with respect to the time when the data request is received by the vehicle. In some embodiments, the start time and end time are relative times with respect to a trigger event. The trigger event is an event inside the vehicle or an event in the environment around the vehicle for which the user is requesting data, or the receipt of the data request by the vehicle. For example, trigger events arising from the environment around the vehicle include hard acceleration, hard braking, capture of an image of the target of the data request, detection of the target of the data request, or other suitable events. The user information that monitors the status of the data request includes identifying the information of the data request and the status of the data request, such as pending or sent.

[0015] In some embodiments, when a data request is received by the vehicle, the data request is processed to be agnostic with respect to the source of the data request. In some embodiments, a data request identification information (ID) is assigned to the received data request by the vehicle, for example, by a request extraction unit in the vehicle. In some embodiments, the data request ID is assigned to the data request before the transmission of the data request to the vehicle. In some embodiments, the data request is generated by an application running in the vehicle, and the application assigns the data request ID. In other words, the data is processed in a consistent manner regardless of the program or system that sends the data request to the vehicle. In some embodiments, the data request is generated by a software component stored in the vehicle, and the data is processed in accordance with the data requests received from external devices. This helps to share the same data collection software components between trigger data collections, where the application generates data collection requests for the logger and ODDR-based external data collection requests.

[0016] In some embodiments, when a data request is received by a vehicle, the data request is processed to be agnostic to sensors and servers within the vehicle. In some embodiments, the data request is generated by an application running on the vehicle. In some embodiments, an application programming interface (API) can be used to be agnostic to data requests from an application with respect to information from sensors or servers within the vehicle. This helps to enable the user to collect data to the greatest extent without having to program requests for a specific sensor model. The data request is then transferred to a data collection unit, and the requested data is collected in response to the occurrence of a trigger event. In a situation where a trigger event such as a traffic accident has already occurred, the data request is satisfied based on data stored in a storage device within the vehicle. The time frame for the collected data, i.e., the start time and end time, is determined based on the data request. The collected data is transferred to and returned by the server.

[0017] The collected data is then stored on the server, and a notification regarding the completion of the data request is sent to the user. For example, the status of the data request is updated to "completed" on the user interface.

[0018] In some examples, a budget management system or a payment system is implemented on the server side or the vehicle side such that a fee is charged to the user for the data request. The fee is payable either at the time of sending the request or at the completion of data collection. The fee is adjustable based on the type and amount of data requested. In some embodiments, when the total amount of the fee charged to the user reaches the maximum threshold of the user's budget, data requests from the user are rejected.

[0019] With this ODDR system, a user can access information collected by a vehicle on an on-demand basis. That is, data is not necessarily collected continuously and can be collected to meet specific user requirements. In some embodiments, the ODDR system helps a user such as a software developer collect data and update the design, implementation, and parameter adjustment of the user's software in a trial manner based on the collected data. As a result, the user can continuously improve the software, for example, by delivering updates from a server to the vehicle via a network as an Over-the-Air (OTA) update. In some embodiments, the ODDR system helps a machine learning developer who develops a machine learning model for an application collect data and train the model using data that was not available when the model was first developed. As a result, the machine learning developer can update the model and continuously correct the weaknesses and problems of the model. In some examples, an insurance provider can collect data related to traffic accidents. In some examples, in law enforcement, information related to a crime or a traffic accident can be collected.

[0020] FIG. 1 is a schematic diagram of a request acquisition system 100 according to some embodiments. The request acquisition system 100 includes a user interface (UI) 110. The UI 110 is configured to receive user requests for data from the vehicle 140. The request acquisition system 100 further includes a server 120. The server 120 is configured to receive a user request from the UI 110, send the user request to the vehicle 140, receive data from the vehicle 140, and provide the data to the user via an accessible console 150. The server 120 includes a communication section 130 that communicates with the UI 110 and the vehicle 140. The request acquisition system 100 further includes an accessible console 150 configured to communicate data collected from the vehicle 140 to the user.

[0021] UI110 is configured to receive input commands from a user. In some embodiments, the user includes software developers. In some embodiments, the user includes machine learning model developers. In some embodiments, the user includes insurance providers. In some embodiments, the user includes law enforcement officers. In some embodiments, the user includes market research companies. UI110 provides the user with options to select which type of vehicle and which type of data is being requested. In some embodiments, UI110 can generate a data request using a form related to the vehicle that identifies information, the data type requested, the start time, and the end time. In some embodiments, the start time and the end time are absolute times, for example, UNIX time which is the elapsed time from the UNIX epoch time. In some embodiments, the start time and the end time are relative times with respect to the time when the data request is received by the vehicle. In some embodiments, the start time and the end time are relative times with respect to a trigger event. In some embodiments, UI110 also provides the user with options to select a trigger event and a data collection duration with respect to the trigger event. In some embodiments, UI110 includes information related to the type of vehicle for which data is requested. In some embodiments, UI110 includes a vehicle ID that can uniquely identify the vehicle that is the target of the request. For example, the vehicle ID includes a Universal Unique Identifier (UUID) format. In some embodiments, UI110 includes a data type that can identify the source of the data that the user desires to collect. For example, the data type includes a sensor ID of the sensor from which sensor data is collected, and an application ID of the application from which application logs are collected. In some embodiments, the formats of the sensor ID and the application ID include a Universal Unique Identifier (UUID) format. In some embodiments, UI110 includes a drop-down menu. In some embodiments, UI110 includes an editable field that receives information related to the data request. In some embodiments, UI110 provides information regarding which data option types are available to the user.In some embodiments, the available data option types depend on the user. For example, in some embodiments, in law enforcement, more data options can be selected than by an insurance provider.

[0022] In some embodiments, UI110 includes a graphical user interface (GUI). In some embodiments, UI110 includes a mobile terminal connectable to server 120, such as a mobile phone. In some embodiments, UI110 includes a web interface such as a RESTful API. In some embodiments, UI110 includes a computer connectable to server 120. In some embodiments, UI110 can be wirelessly connected to server 120. In some embodiments, the UI can be connected to server 120 by a wired connection. UI110 can also provide the user with updates regarding the status of the data request. In some embodiments, UI110 provides a status update regarding the data request in response to an additional query by the user. In some embodiments, when UI110 receives update information from server 120, it automatically provides a status update regarding the data request without interaction with the user. In some embodiments, the status update causes UI110 to trigger a warning to the user. In some embodiments, the warning includes an audio warning or a visual warning.

[0023] In some embodiments, UI110 includes means for receiving payment from the user. In some embodiments, UI110 includes a data input field that enables the user to enter payment card information. In some embodiments, UI110 includes a reader for detecting payment card information, such as a magnetic stripe reader, a barcode reader, a chip reader, or another suitable reader.

[0024] Server 120 includes a communication section 130 configured to communicate with UI 110 and vehicle 140. Communication section 130 includes a receiver 131 configured to receive data requests from UI 110. In some embodiments, receiver 131 includes a wireless receiver. In some embodiments, the receiver is configured to receive data requests via a wired connection. In some embodiments, receiver 131 is further configured to perform initial processing on received data requests. In some embodiments, the received data requests include priority level information. In some embodiments, receiver 131 is configured to assign a priority level to a data request based on the identity of the user who sent the data request or the fee paid by the user who sent the data request. In some embodiments, receiver 131 is configured to assign a request identification information (ID) number to each received data request. In some embodiments, server 120 is configured to restrict access to specific sensors within vehicle 140 based on the identity of the user. For example, in some embodiments, a third-party user cannot access sensors related to the safety functions of vehicle 140.

[0025] The communication section 130 further includes a memory unit 132 configured to store data requests received by the receiver 131. In some embodiments, the memory unit 132 includes a random access memory, a solid state memory, or another type of memory. In some embodiments, the memory unit 132 is configured to store data requests along with the status of the data requests. In some embodiments, the status of the data requests includes pending (before sending the data request to the vehicle 140), sent (after sending the data request to the vehicle 140), and completed (after receiving the requested data from the vehicle 140). In some embodiments, the memory unit 132 is accessible by a user. In some embodiments, an update to the information in the memory unit 132 triggers a notification to the user associated with the information being updated in the memory unit 132. In some embodiments, the memory unit 132 stores data requests along with timestamp data indicating the time at which the data requests were received. In some embodiments, the memory unit 132 stores data requests in association with a priority level. In some embodiments, the priority level is determined based on the identity of the user. For example, in some embodiments, law enforcement has a higher priority than an insurance provider, and the insurance provider has a higher priority than a normal user such as a software developer. In some embodiments, the priority level is determined based on the fees paid by the user. For example, in some embodiments, a user can pay a fee to increase the priority level of the user's request to obtain requested data more quickly. In some embodiments, as the amount of time between the initial storage of a data request and the sending of the data request to the vehicle increases, the priority level of the data request increases.

[0026] The communication section 130 further includes a transmitter 133. The transmitter 133 is configured to transmit the status of the data request to the UI 110. In some embodiments, the status of the data request is wirelessly transmitted to the UI 110. In some embodiments, the status of the data request is transmitted to the UI 110 via a wired connection. In some embodiments, the transmitter 133 is configured to automatically provide an update to the data request in response to an update within the memory unit 132. In some embodiments, the transmitter 133 is configured to provide an update to the data request in response to an update request received from the user. In some embodiments, the transmitter 133 is configured to automatically transmit a request ID when the data request is first saved to the memory unit 132. In some embodiments, the status of the data request includes the priority level of the data request. In some embodiments, the status of the data request includes the estimated time until the data request is transmitted to the vehicle 140.

[0027] The communication section 130 further includes a query queue 134 configured to store data requests in the order of priority for transmission to the vehicle 140. In some embodiments, the query queue 134 is incorporated within the memory unit 132. In some embodiments, the query queue 134 is separate from the memory unit 132. In some embodiments, the query queue 134 is configured to retrieve data requests from the memory unit 132 based on the priority level and timestamp information. In some embodiments, the query queue 134 is configured to sort the data requests based on the priority level and, for data requests having the same priority level, sort the data requests by the time since first saved to the memory unit 132.

[0028] The communication section 130 further includes a transmitter 135 configured to send data requests from the query queue 134 to the vehicle 140. The transmitter 135 is configured to send data requests to the vehicle 140 based on the order of data requests in the query queue 134. In some embodiments, the data requests are sent wirelessly to the vehicle 140. In some embodiments, the data requests are sent to the vehicle 140 by a wired connection. The data requests sent to the vehicle 140 include trigger event information, data duration information related to the periods before and after the trigger event for which data is to be collected, and sensor information indicating that a certain type of sensor of the vehicle 140 should collect data. In some embodiments, the data requests sent to the vehicle 140 include priority level information. In some embodiments, when the vehicle 140 sends a request to send a data request to the vehicle 140 to the server 120, the transmitter 135 is configured to send the data request to the vehicle 140. In some embodiments, the transmitter 135 is configured to send data requests to the vehicle 140 at any time when the communication section 130 has sufficient connectivity to the vehicle 140, unless the communication section 130 has received information indicating that the vehicle 140 cannot accept new data requests. In some embodiments, the transmitter 135 is configured to send data requests to the vehicle 140 periodically, as long as the vehicle 140 can receive new data requests and the transmitter 135 has sufficient connectivity to the vehicle 140. In some embodiments, the transmitter 135 is configured to send data requests to the vehicle 140 in batches, for example, in groups of 5 data requests, 20 data requests, or some other number of data requests. In some embodiments, the transmitter 135 is configured to request an acknowledgement of receipt of the data request from the vehicle 140. In response to not receiving an acknowledgement of receipt from the vehicle within a predetermined period, the transmitter 135 is configured to re-send the data request. In some embodiments, the status of the data requests stored in the memory unit 132 is updated to indicate transmission to the vehicle 140 in response to the communication section 130 receiving an acknowledgement regarding the receipt of the data request from the vehicle 140.

[0029] Communication section 130 further includes a receiver 136 configured to receive from vehicle 140 a notification of the occurrence of a trigger event. In some embodiments, the occurrence of the trigger event is the receipt of a data request. In some embodiments, receiver 136 is configured to receive wirelessly a notification of the trigger event. In some embodiments, receiver 136 is configured to receive via a wired connection a notification of the trigger event. In some embodiments, receiver 136 is configured to send to memory unit 132 a signal that updates the status of the data request associated with the notified trigger event.

[0030] Communication section 130 further includes a receiver 137 configured to receive data from vehicle 140 in response to a data request transmitted by transmitter 135. In some embodiments, the data is segmented by vehicle 140 into data packets that are units of transmission from vehicle 140 to server 120, and receiver 137 receives the data packets from vehicle 140. In some embodiments, receiver 137 is configured to receive the data wirelessly. In some embodiments, receiver 137 is configured to receive the data via a wired connection. In some embodiments, receiver 137 is configured to send to memory unit 132 a signal that updates the status of the data request associated with the receipt of the requested data. In some embodiments, the data in response to a single data request is received from vehicle 140 in a single packet. In some embodiments, the data in response to a single data request is received from vehicle 140 in multiple packets. Receiver 137 transfers the received data to preprocessor 122.

[0031] Server 120 further includes a preprocessor 122, which is configured to receive data from the receiver 137 and perform preprocessing on the data to generate collected data. In some embodiments, the preprocessing includes modifying data from a plurality of packets to compile the data in response to a data request. In some embodiments, the preprocessing includes deserializing the data to compile structured data from the received byte array. In some embodiments, the preprocessing includes decompressing the data if the data has been compressed by the vehicle 140 prior to transmission. In some embodiments, the preprocessing includes error correction by an error correction code (ECC) such as a Reed - Solomon (RS) code, a Bose - Chaudhuri - Hocquenghem (BCH) code, a low - density parity - check (LDPC) code, and the like. In some embodiments, the preprocessing includes smoothing the data by removing outliers to reduce the risk of reporting incorrect data to the user. In some embodiments, the preprocessing includes associating data request ID information, priority level information, or other suitable information with the received data from the receiver 137. In some embodiments, the data is preprocessed such that the information is provided to the user in a format that is easy to understand and does not rely on specialized knowledge or equipment to identify the information.

[0032] Server 120 further includes a data storage 126 configured to store the collected data generated by the data preprocessor 122. In some embodiments, the data storage 126 is incorporated into the memory unit 132. In some embodiments, the data storage 126 is separate from the memory unit 132. In some embodiments, the data storage 126 includes a solid state drive (SSD), random access memory, or another suitable memory. In some embodiments, the data storage 126 is accessible by a user, for example, using the UI 110 or the accessible console 150. In some embodiments, the data storage 126 is configured to notify the user in response to data related to the data request being available. In some embodiments, the notification includes a warning to the user. In some embodiments, the warning includes an audible warning or a visual warning. In some embodiments, the data storage 126 is configured to automatically display a notification of the availability of the collected data on the UI 110 or the accessible console 150. In some embodiments, the data storage 126 is accessible by a user using the accessible console 150 without the user sending a data request. In some embodiments, the data within the data storage 126 is searchable by a user via the accessible console 150. In some embodiments, the collected data is visualized at the console 150.

[0033] The request acquisition system 100 further includes a vehicle 140. The vehicle 140 includes sensors for detecting both the internal situation of the vehicle 140 and the external environment around the vehicle 140. In some embodiments, the sensors include cameras, optical ranging (LiDAR) sensors, radio ranging (RADAR) sensors, acoustic navigation and ranging (SONAR) sensors, accelerometers, steering wheel position, speedometers, or other suitable sensors. The vehicle 140 can receive data requests via either a wireless or a wired connection.

[0034] In some embodiments, in response to receiving a data request, vehicle 140 is configured to assign a data request ID to the received data request, and the data request is processed to be agnostic to the system or program in which the data request originated. In another embodiment, communication section 130 instead of vehicle 140 assigns a data request ID, and the data request ID is included in the data request transmitted from communication section 130 to vehicle 140. Making the data request agnostic to the system or program in which the data request originated helps to extend the ability of vehicle 140 to receive and process a wide range of data requests from various users and systems. Vehicle 140 includes a processor that processes the data request to determine the type of information that the sensors available in vehicle 140 can satisfy the data request. In at least some embodiments, vehicle 140 includes a mobile computing network that is a network of processors, controllers, or combinations thereof, such as a controller area network (CAN). In at least some embodiments, each processor is an electronic control unit (ECU). Vehicle 140 further includes a memory that stores data from the sensors. In some embodiments, the processor accesses the memory to determine whether any stored data can satisfy the data request. Vehicle 140 can further transmit data that is considered to satisfy the data request to server 120 via either a wireless or wired connection. In some embodiments, the processor is configured to attempt to satisfy the received data requests in a priority order based on the priority level at which the data requests are received. In some embodiments, vehicle 140 is configured to preferentially transmit data to the server based on the priority level at which the data requests are received.

[0035] In some embodiments, the memory and processor of vehicle 140 are configured to store and execute software applications in an electronic control unit (ECU) within vehicle 140. In some embodiments, data requests are generated by software applications stored in the ECU. In some embodiments, data requests are generated in response to a trigger event, such as a hard acceleration, hard braking, ingestion of sensor data including a particular object or particular scene predefined in the software application, a "crash" of the software application, an anomaly detected in the software application, or another suitable detectable event. In some embodiments, vehicle 140 is configured to generate a notification to a maintainer of the software application, such as a user, in response to detection of a trigger event associated with the software application. In some embodiments, the notification is sent directly to the user, for example, through UI110, either wirelessly or via a wired connection. In some embodiments, the notification is sent to the user through server 120, either wirelessly or via a wired connection. In some embodiments, the notification includes an audio notification or a visual notification. In some embodiments, the notification is configured to automatically display the notification on UI110 without user interaction.

[0036] The request acquisition system 100 further includes an accessible console 150. The accessible console 150 enables a user to access the collected data stored in the data storage 126. In some embodiments, the accessible console 150 is incorporated into the UI 110. In some embodiments, the accessible console 150 is separate from the UI 110. In some embodiments, the accessible console 150 includes another server that is separate from the server 120. In some embodiments, the accessible console 150 automatically receives the collected data related to a data request from the user when the data storage 126 receives the collected data. In some embodiments, the accessible console 150 enables the user to search the data storage 126 without sending a data request and determine whether any of the collected data stored in the data storage 126 is useful to the user.

[0037] The use of the request acquisition system 100 enables a user to obtain information from one or more vehicles 140 in a format that is easy to understand without relying on specialized equipment to request or read the received data. The ability to prioritize data requests in the request acquisition system 100 helps ensure that law enforcement or other users can obtain the data while also allowing the user to pay a fee to obtain the data more quickly. This flexibility helps improve the usefulness of the request acquisition system 100 for a wide range of users.

[0038] Figure 2 is a diagram of graphical user interfaces (GUIs) 200 and 250 for a request acquisition system according to some embodiments. In some embodiments, GUI 200 can be used as UI 110 in request acquisition system 100 (FIG. 1). In some embodiments, GUI 200 can be used to generate data requests received by receiver 131 (FIG. 1). GUI 200 includes a plurality of information types 210 that identify the types of information that GUI 200 can receive from a user. GUI 200 further includes a plurality of fields 220 configured to receive information related to the corresponding information types 210 of GUI 200. GUI 200 further includes a send button 230, which is configured to send a data request to a server, such as server 120 (FIG. 1), based on the information in fields 220. Those skilled in the art will recognize that the names and numbers of the plurality of information types 210 are merely exemplary, and that different numbers and types of information are also within the scope of the present disclosure.

[0039] In some embodiments, fields 220 include fields for a user to input a vehicle ID, data type, start time, and end time. In some embodiments, fields 220 further include a field for a user to input a priority level of the data request. In some embodiments, GUI 200 further includes information related to how a user can increase the priority level of a data request, such as information indicating a fee associated with each available priority level. In some embodiments, GUI 200 includes a field 220 that enables a user to input login information to establish the user's identity. In some embodiments, GUI 200 is configured to display the user's priority level after receiving the login information. In some embodiments, GUI 200 further includes a field 220 for receiving payment information related to a fee for establishing a priority level of a data request.

[0040] The GUI 250 is configured to be displayed to the user after the user selects the send button 230 on the GUI 200. In some embodiments, the GUI 250 can be used as the GUI 110 in the ODDR system 100 (FIG. 1). The GUI 250 includes information indicating that a data request has been received. The GUI 250 includes a query ID label 260 and a query ID field 270. The information entered in the query ID field 270 is received from a server, for example, the server 120 (FIG. 1), after the server receives and stores the data request. In some embodiments, the GUI 250 includes information about the vehicle ID. In some embodiments, the GUI 250 includes information related to the priority level of the data request. In some embodiments, the GUI 250 includes information about the status of the data request, such as pending, sent, completed, etc. In some embodiments, the GUI 250 includes information related to the estimated time until the data request is sent to a vehicle, for example, the vehicle 140 (FIG. 1). In at least some embodiments, the GUI 250 includes information related to the estimated time until the requested data is received. In at least some embodiments, the GUI 250 includes information related to the estimated energy consumption for receiving the requested data. In some embodiments, the GUI 250 is automatically displayed in response to receiving query ID information from the server. In some embodiments, the GUI 250 is displayed in response to the user sending a request for an update to the uploaded data request.

[0041] FIG. 3 is a diagram of a data structure 300 of a request acquisition command 310 according to some embodiments. In some embodiments, the request acquisition command 310 is sent from the server 120 to the vehicle 140 (FIG. 1). The request acquisition command 310 includes information related to the type of data requested by a data request for a vehicle, for example, the vehicle 140 (FIG. 1).

[0042] The request acquisition command 310 includes a transfer priority parameter 311 indicating the priority level of the data request. The request acquisition command 310 further includes, if any, a log level parameter 312 indicating the type of data to be acquired from other applications in the vehicle. For example, in some embodiments, the request acquisition command 310 acquires data from an object recognition application. The log level parameter 312 determines the type of data to be acquired from other applications such as the error level or the critical level. In some embodiments, the log level parameter 312 is omitted from the request acquisition command 310, or the log level parameter 312 is set to a null state. The request acquisition command 310 further includes a collection time range parameter 313 indicating the period before and / or after the trigger event for collecting data. The time range corresponds to the start time and the end time input by the user to the GUI 200 (Figure 2). The request acquisition command 310 further includes a uniform resource locator (URL) endpoint parameter 314 indicating the destination of the data collected in response to the data request. The request acquisition command 310 further includes, if any, a frequency parameter 315 indicating the frequency at which data should be sampled from the time range 313. For example, if the event time is t = 100 seconds, the time range has a start time = -1 second and an end time = 2 seconds, and the frequency is 10 Hz (100 millisecond cycle), the data at t = 99.0 seconds, 99.1 seconds, 99.2 seconds,..., 101.9 seconds, 102.0 seconds is collected by the request acquisition command. The request acquisition command 310 further includes a log ID parameter 316 indicating the type of sensors and / or applications available for collecting the data requested by the data request. In some embodiments, a unique ID (such as a universal unique identifier (UUID)) is pre-assigned to all sensors and applications, and the unique ID for which the user desires to collect data is specified in the log ID parameter 316. The request acquisition command 310 further includes a requester ID parameter 317 indicating the identity of the user who made the data request. The request acquisition command 310 further includes an event ID parameter 318 indicating the trigger event associated with the data request.The request acquisition command 310 further includes a budget ID parameter 319 indicating the amount of resources of a vehicle, such as vehicle 140 (FIG. 1), to be allocated to meet the data request. Those skilled in the art will understand that additional parameters are possible in the request acquisition command 310. For example, in some embodiments, the request acquisition command 310 includes a vehicle location parameter indicating a geographic area where a trigger event can occur. Those skilled in the art will also understand that the request acquisition command 310 does not always include all of the parameters of FIG. 3. For example, in some embodiments, the budget ID parameter 319 is omitted.

[0043] FIG. 4 is a block diagram of a request acquisition system 400 according to some embodiments. In some embodiments, the request acquisition system 400 is part of the request acquisition system 100 (FIG. 1). In some embodiments, the request acquisition system 400 can be used together with the request acquisition system 100 (FIG. 1). In some embodiments, the request acquisition system 400 is separate from the request acquisition system 100 (FIG. 1).

[0044] The request acquisition system 400 includes a detection vehicle system 410 configured to capture information about the vehicle or the surroundings of the vehicle. The detection vehicle system 410 captures information about the vehicle and its surroundings and transmits the information to the server. The request acquisition system 400 further includes a server 440, which is configured to receive the information, encode the information, and stream the information to the user terminal 460.

[0045] The detection vehicle system 410 includes an electronic control unit (ECU) 420 configured to receive data from a sensor 414, a global positioning system (GPS) 416, and a map 418. The ECU 420 includes a situation detector 422, a data specifier 432, a log collector 434, and a log transmitter 436. The situation detector 422 includes a vehicle control monitor 424, an object detector 426, and a scene detector 428.

[0046] In some embodiments, the ECU 420 further includes a localization unit, which is configured to receive data from the GPS 416 and the map 418 to determine the position of the vehicle relative to the positions of detected and / or known objects and / or roads, as well as the attitude and state of the vehicle. The attitude is the orientation of the vehicle relative to a reference point such as a lane. In some embodiments, the position of the vehicle also refers to the position vector of the vehicle. The attitude and state of the vehicle refer to the speed and direction of travel of the vehicle. In some embodiments, the attitude and state of the vehicle also refer to the speed vector, acceleration vector, and jerk vector of the vehicle. In some embodiments, the position vector, speed vector, acceleration vector, and jerk vector include angular vectors. In some embodiments, the state of the vehicle also refers to whether the engine or motor of the vehicle is operating.

[0047] Sensor 414 is configured to capture information about the environment around the vehicle, such as an image. In some embodiments, sensor 414 includes a visible light camera, an IR camera. In some embodiments, sensor 414 is replaced by or further accompanied by a light detection and ranging (LiDAR) sensor, a radio detection and ranging (RADAR) sensor, a sound-based navigation and ranging (SONAR) sensor, or another suitable sensor. In some embodiments, sensor 414 includes additional cameras disposed at other locations in the vehicle. For example, in some embodiments, the additional cameras are disposed on the sides of the vehicle to detect a larger portion of the environment on the left and right of the vehicle being viewed. Since the vehicle occupants can look out of the side windows of the vehicle, using additional cameras to detect a larger portion of the environment around the vehicle helps increase the accuracy of detecting objects or scenes around the vehicle. For example, in some embodiments, the additional cameras are disposed at the rear side of the vehicle to detect a larger portion of the environment behind the vehicle. This information helps capture information about the object. In some embodiments, the data from sensor 414 includes a timestamp or other metadata to help synchronize the data from sensor 414 with the data from other components.

[0048] GPS 416 is configured to determine the location of the vehicle. Knowing the location of the vehicle being viewed helps associate an object or scene with the location determined on map 418.

[0049] Map 418 includes information related to a roadway and known objects along the roadway. In some embodiments, Map 418 can be used together with GPS 416 to determine the location and direction of travel of a vehicle. In some embodiments, Map 418 is received from an external device such as Server 440. In some embodiments, Map 418 is periodically updated based on information from Sensor 414 and / or GPS 416. In some embodiments, Map 418 is periodically updated based on information received from an external device. In some embodiments, Map 418 is generated from sensor data by a Simultaneous Localization and Mapping (SLAM) algorithm. Including Map 418 helps to determine whether an object is a known object. Including Map 418 with known objects helps to increase the accuracy of new object detection.

[0050] Situation Detector 422 is configured to generate information related to the performance of the vehicle and the performance of systems within the vehicle. Situation Detector 422 can collect information from components within the vehicle, such as Sensor 414, the braking system, the acceleration system, and other suitable components. Using this information, Situation Detector 422 can determine the performance of the vehicle. In some embodiments, Situation Detector 422 is further configured to monitor the performance of software and networking operations within the vehicle. For example, in some embodiments, Situation Detector 422 is configured to receive information related to a "crash" of software or an application within the vehicle. In some embodiments, Situation Detector 422 is configured to collect information regarding the storage capacity of a memory device within the vehicle. In some embodiments, Situation Detector 422 is configured to receive information related to the processing capabilities of a processor within the vehicle.

[0051] The vehicle control monitor 424 is configured to receive sensor data and control logs related to the current operation of the vehicle. In some embodiments, the sensor data includes the speed, acceleration, jerk, brakes, steering, pitch, roll, yaw, flashing of hazard lights, information related to sounding a siren, or other suitable information of the vehicle. The vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates that it meets the criteria for satisfying a request, for example, whether a trigger event has been detected.

[0052] The object detector 426 is configured to receive sensor data from the sensor 414 and determine whether any abnormal object is located in the lane. In some embodiments, the object detector 426 is further configured to determine whether any object exists along or adjacent to the lane. In some embodiments, the sensor data from the sensor 414 includes an image, and the object detector 426 is configured to perform image recognition on the received image using, for example, a trained neural network to identify abnormal objects. In some embodiments, the object detector 426 is configured to assist in determining the type of the identified object by comparing any identified object with information from the GPS 416 and the map 418. In some embodiments, the object detector 426 is configured to identify an object, for example, a tire, a vehicle part, an animal, a hole, a traffic control board, an emergency vehicle, a vehicle with active hazard lights, or other suitable objects as an object.

[0053] The scene detector 428 is configured to receive sensor data from the sensor 414 and determine whether any scene that meets the conditions to satisfy the request is located in the environment around the vehicle. In some embodiments, the scene detector 428 is configured to determine that a vehicle accident has occurred in response to detecting that two or more vehicles are in contact with each other or that the vehicle is surrounded by a plurality of falling objects. In some embodiments, the scene detector 428 is configured to determine that construction is being performed based on the detection of a plurality of construction vehicles in the vicinity. In some embodiments, the scene detector 428 is configured to determine that the vehicle is parked on the shoulder based on determining that the vehicle is located adjacent to the roadway and is not moving or is moving significantly slower than other vehicles. In some embodiments, the scene detector 428 is configured to determine the content of the scene around the vehicle using image recognition, such as through a trained neural network or the like.

[0054] In some embodiments, each of the object detector 426 and the scene detector 428 is active during the entire period of operation of the vehicle, for example, when the engine or motor of the vehicle is operating. In some embodiments, at least one of the object detector 426 or the scene detector 428 is activated in response to the vehicle control monitor 424 determining that a specific behavior, such as a trigger event, has been detected.

[0055] The data specifying unit 432 is configured to receive a determination that the requirement has been fulfilled or that a trigger event has been detected. The data specifying unit 432 is configured to analyze the received information and determine, based on the received data, which sensor data from the sensor 414 should be collected. For example, in some embodiments where abnormal steering behavior by the driver is detected, the data specifying unit 432 is configured to determine that image data from the front camera of the sensor 414 should be captured. Further, the data specifying unit 432 is configured to determine, based on the time of the detected situation, the period during which data from the determined sensor should be collected. In some embodiments, the data specifying unit 432 is configured to determine the sensor 414 that collects data based on an instruction in a request received from the user.

[0056] In some embodiments, the data specifying unit 432 is configured to determine a region of the received sensor data related to the detected situation. In some embodiments, the region of the received sensor data is identified based on, for example, object recognition performed on the sensor data by the object detector 426 or the scene detector 428. In some embodiments, the data specifying unit 432 is configured to crop a received image from the sensor data or remove heterogeneous data from the sensor data if the sensor data is not an image, in order to reduce the amount of information in the log of the abnormal situation. In some embodiments, the data specifying unit 432 is configured to remove personal information, such as license plates, human faces, etc., from the sensor data.

[0057] The log collector 434 is configured to receive data from the data specifying unit 432. In some embodiments, the log collector 434 is configured to directly receive data from the sensor 414, the GPS 416, or the situation detector 422 based on the information provided by the data specifying unit 432. The log collector 434 is also configured to determine which information is useful for identifying the type and location of the object, for example, location information from the GPS 416 or the map 418, image information from the sensor 414, cropped or reduced information from the data specifying unit 432, timestamp information related to the time when the object or scene was detected, or other suitable information.

[0058] The log collector 434 generates log data based on the received and related data, for example, the cropped image and the location data. The log collector 434 also associates the timestamp information with the log data to assist in synchronizing the collected data and for queue prioritization within the server 440. In some embodiments, the log collector 434 generates log data that further includes the world coordinates associated with the cropped image. In some embodiments, the log collector 434 generates log data that further includes the map location associated with the cropped image. In some embodiments, the log collector 434 includes additional information to assist in increasing the accuracy of determining the object or scene.

[0059] The above description relates to generating log data based on the image from the sensor 414, but those skilled in the art will understand that the log collector 434 is not limited to only generating log data based on images. In some embodiments, the log collector 434 is configured to generate log data based on information from other sensors attached to the vehicle, such as RADAR, LiDAR, or other suitable sensors. In some embodiments where the passengers are wearing smart glasses, the log collector 434 is further configured to generate log data based on the information received from the smart glasses.

[0060] The log transmitter 436 is configured to receive log data from the log collector 434 and transmit the log data to the server 440. In some embodiments, the log transmitter 436 is configured to transmit the log data wirelessly. In some embodiments, the log transmitter 436 is configured to transmit the log data via a wired connection. In some embodiments, the log transmitter 436 is configured to directly transmit the log data to the user terminal 460. In some embodiments, the log transmitter 436 is configured to transmit the log data to a mobile device accessible by the user, and then the mobile device is configured to transmit the log data to the server 440. In some embodiments, the log transmitter 436 is configured to use Bluetooth (registered trademark) or another suitable wireless technology to transmit the log data to the mobile device. In some embodiments, the ECU 420 is configured to determine whether the data transfer speed from the mobile device to the server 440 is higher than the transfer speed from the log transmitter 436 to the server 440. In response to a determination that the data transfer speed from the mobile device to the server 440 is higher, the log transmitter 436 is configured to transmit the log data to be sent to the server 440 to the mobile device. In response to a determination that the data transfer speed from the mobile device to the server 440 is not higher, the log transmitter 436 is configured to directly transmit the log data from the vehicle system 410 to the server 440 without transferring the log data to the mobile device.

[0061] In some embodiments, the detection vehicle system 410 further includes a memory configured to store sensor data from sensors attached to the vehicle. In some embodiments, the memory is further configured to store information associated with previously detected objects or scenes. In some embodiments, in response to detecting an object or scene that matches a previous object or scene, the data specifying unit 432 is configured to provide a result based on the matching object or scene. In some embodiments, the detection vehicle system 410 is further configured to determine whether the detection vehicle has received from the server 440 information related to an object or scene that matches the object or scene determined by the situation detector 422. In some embodiments, in response to detecting that the detection vehicle has already received information related to the determined object or scene, the detection vehicle system 410 is configured to prevent the transmission of log data to the server 440. Avoiding the transmission of redundant information to the server 440 helps reduce the data transmitted to the server 440 and helps minimize the power consumption by the detection vehicle system 410. In some embodiments, the storage of previous requests is referred to as caching. Those skilled in the art will understand caching as being able to store data using hardware or software, such that future requests for that data can be satisfied more quickly.

[0062] The server 440 includes a log data receiver 442 configured to receive log data from the log transmitter 436. In some embodiments, the log data receiver 442 is configured to receive log data from a mobile device. The server 440 further includes a log encoder 444 configured to encode the log data. The server 440 further includes a log forwarder 446 configured to transmit the encoded log data to the user terminal 460. The server 440 further includes a request / rule receiver 448 configured to receive requests or rules from the user terminal 460.

[0063] The log data receiver 442 is configured to receive log data from the log transmitter 436. In some embodiments, the log data receiver 442 is configured to receive log data from a mobile device. In some embodiments, the log data receiver 442 is configured to receive log data wirelessly. In some embodiments, the log data receiver 442 is configured to receive log data via a wired connection. In some embodiments, the log data receiver 442 is configured to add a timestamp about the time when the log data is received to the log data.

[0064] The log encoder 444 is configured to encode the received log data according to a predetermined encoding protocol. Encoding the log data according to a predetermined encoding protocol helps to ensure that the user terminal 460 can surely decode the log data for use by the user terminal 460. In some embodiments, the log encoder 444 is configured to perform compression of the log data, image encoding, thumbnail image generation, or other suitable encoding protocols. In some embodiments, the log encoder 444 is configured to perform encryption of the log data. In some embodiments, the log encoder 444 is further configured to perform super-resolution to enable the user to better recognize the data. Those skilled in the art will understand that super-resolution is a process of receiving a high-resolution image from a low-resolution image. Improving the resolution of the log data helps to reduce false positives or false negatives.

[0065] In some embodiments, the server 440 further includes a database that stores received log data. In some embodiments, the log data is stored in the database before and / or after encoding by the log encoder 444. In some embodiments, the log data is stored in the database in a priority queue. In some embodiments, the priority of the priority queue is determined based on an object or scene, such as the time when a trigger event was detected, the time when the log data was received by the log data receiver 442, the type of the object or scene, the identity of the driver of the detected vehicle, or other suitable priority criteria.

[0066] The log transfer machine 446 is configured to receive the encoded log data from the log encoder 444. The log transfer machine 446 is configured to transmit the encoded log data to the user terminal 460. In some embodiments, the log transfer machine 446 is configured to transmit the encoded log data to a mobile device accessible by the user. In some embodiments, the log transfer machine 446 is configured to wirelessly transmit the encoded log data. In some embodiments, the log transfer machine 446 is configured to transmit the encoded log data via a wired connection. In some embodiments, the log transfer machine 446 is configured to transmit encoding protocol information along with the encoded log data. The transmission of the encoding protocol information about the encoded log data helps the mobile device or the user terminal 460 to accurately decode the encoded log data for use by the user terminal 460.

[0067] The requirement / rule receiver 448 is configured to receive new or updated rules or requirements about data from the user. In some embodiments, the requirement / rule receiver 448 is configured to receive new or updated rules or requirements wirelessly. In some embodiments, the requirement / rule receiver 448 is configured to receive new or updated rules or requirements via a wired connection. In some embodiments, the requirement / rule receiver 448 is by the UI110 (FIG. 1).

[0068] In some embodiments, the server 440 is configured to receive formation locations from a plurality of vehicles. In some embodiments, the server 440 is configured to receive navigation plans from a plurality of vehicles. In some embodiments, the log forwarder 446 is configured to limit the transmission of encoded log data to only those vehicles that are within a predetermined distance of the detected trigger event.

[0069] In some embodiments, the server 440 is configured to transmit only the log data associated with newly detected trigger events. That is, if a trigger event has already been reported by the server 440, the trigger event is not reported again. Limiting the repeated reporting of trigger events helps the server 440 reduce redundant data received by the user terminal.

[0070] The user terminal 460 is a user-accessible user terminal associated with a satisfied requirement. In some embodiments, the user terminal 460 includes a GUI. In some embodiments, the user terminal 460 is configured to automatically generate a warning in response to received data from the server 440. In some embodiments, the warning includes an audio warning or a visual warning.

[0071] Those skilled in the art will understand that modifications to the request acquisition system 400 are within the scope of the present disclosure. For example, in some embodiments, the detection vehicle system 410 can directly transmit log data to the user terminal 460 over a network such as a wireless network. In some embodiments, a mobile device of an occupant within the detection vehicle can directly transmit log data to the user terminal 460 over a wireless network or the like.

[0072] By automatically identifying and streaming information related to meeting rules or requirements detected in the environment inside or around the vehicle, the user can improve the performance of applications or software executed using the vehicle's processing system, such as the ECU 420. In some embodiments, the user can oppose information related to an event such as an accident.

[0073] FIG. 5 is an operation flow regarding the capture of inquiry content of a mobile computing network according to at least some embodiments of the present disclosure. The operation flow provides a method for capturing inquiry content of a mobile computing network. In at least some embodiments, the method is performed by a server, such as the server 120 shown in FIG. 1, or the server 440 shown in FIG. 4. In at least some embodiments, the method is performed by a controller of the server, such as the controller 1102 shown in FIG. 11.

[0074] In S550, the controller receives a content query. In at least some embodiments, the controller receives the content query from an accessible console, such as the accessible console 150 shown in FIG. 1. In at least some embodiments, the controller receives the content query through the user interface 200 shown in FIG. 2. In at least some embodiments, the content query is a request for information identifiable from data that can be collected using sensors mounted on one or more vehicles. In at least some embodiments, the content query relates to one or more classes of an ontology.

[0075] In S552, the controller creates a program operation sequence. In at least some embodiments, the controller creates a sequence of program operations that involves taking in data samples, where the data samples include first class information and second class information, and reducing the second class information of the data samples. In at least some embodiments, the controller creates various program operation sequences. In at least some embodiments, the various program operation sequences target the same content but differ in program operations and / or combined computational resources. In at least some embodiments, the various program operation sequences target different content for a single query. In at least some embodiments, the controller performs the operation flow of FIG. 6 described below.

[0076] In S554, the controller transmits the sequence to one or more vehicles. In at least some embodiments, the controller transmits the program operation sequence to each of one or more vehicles. In at least some embodiments, the controller transmits various program operation sequences to multiple vehicles.

[0077] In S556, the controller receives the resulting content. In at least some embodiments, the controller receives content from each of a plurality of vehicles through various connections at various times. In at least some embodiments, the controller receives content in a uniform format. In at least some embodiments, the controller receives content in various formats.

[0078] In S558, the controller transmits the resulting content. In at least some embodiments, the controller transmits the content to an accessible console or other terminal. The content query is received from the accessible console or other terminal. In at least some embodiments, the controller transmits the content to storage for later acquisition by the accessible console or other terminal.

[0079] FIG. 6 is an operation flow regarding the determination of a program operation sequence for reducing potential leakage of personal identification information according to at least some embodiments of the disclosure of the subject matter. The operation flow provides a method for determining a program operation sequence for reducing potential leakage of personal identification information. In at least some embodiments, the method is performed by a server, such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is performed by a controller of a server including a section that performs a specific operation, such as controller 1102 shown in FIG. 11.

[0080] In S660, the identification section of the controller identifies candidate program operations. In at least some embodiments, the identification section takes in data samples, where the data samples include first-class information and second-class information, and identifies a plurality of candidate program operations that reduce the second-class information of the data samples. In at least some embodiments, the identification section identifies required program operations and optional program operations. In at least some embodiments, the plurality of candidate program operations includes at least one detection operation, at least one compression operation, and at least one filtering operation. In at least some embodiments, the identification section performs identification in response to receiving a content query from a client terminal. In at least some embodiments, the identification section performs the operation flow of FIG. 7 described below.

[0081] In S664, the allocation section allocates costs. In at least some embodiments, the allocation section allocates costs to each valid combination of a candidate program operation among the plurality of candidate program operations and a computing resource among the plurality of computing resources. In at least some embodiments, the allocation section allocates a leakage cost representing a potential leakage of personal identification information to each valid combination. In at least some embodiments, the allocation section allocates a monetary cost representing at least one of a computing cost and a transmission cost to each valid combination. In at least some embodiments, the allocation section allocates a leakage cost representing a potential leakage of personal identification information associated with each valid combination of a candidate program operation among the plurality of candidate program operations and a computing resource among the plurality of computing resources. In at least some embodiments, the allocation section performs the operation flow of FIG. 9 described below.

[0082] The likelihood of PII leakage as a cost is calculated in various ways in various embodiments. In at least some embodiments, the likelihood of PII leakage is calculated from the perspective of monetary cost. In at least some embodiments, the calculation of the likelihood of PII leakage from the perspective of monetary cost has lower accuracy and precision but can be combined with conventional transmission costs and calculation costs. In at least some embodiments, the likelihood of PII leakage is expressed from a non-monetary perspective. In at least some embodiments, expressing the likelihood of PII leakage from a non-monetary perspective has higher accuracy and precision but is not compatible with conventional transmission costs and calculation costs. In at least some embodiments where the cost of the likelihood of PII leakage is expressed from a non-monetary perspective, the cost is weighted against the conventional calculation costs and transmission costs to account for an appropriate ratio. In other words, if a high weight is given to the likelihood of PII leakage, the solution may support reducing the likelihood of PII leakage rather than the monetary cost. In contrast, if a high weight is given to the calculation costs and transmission costs, the solution may support reducing the monetary cost rather than the likelihood of PII leakage.

[0083] In S668, the application section applies an objective function. In at least some embodiments, the application section applies the objective function to valid combinations and assigned costs to determine a sequence of program operations. In at least some embodiments, the application section applies the objective function to valid combinations and assigned leakage costs to determine a sequence of program operations, where each program operation in the sequence is performed by one or more selected computing resources such that the total leakage cost is less than a threshold leakage cost and the amount of first-class information is more than a data threshold. In at least some embodiments, the application section determines a sequence of program operations, where the sequence is a sequence such that the total monetary cost is less than a threshold monetary cost. In at least some embodiments, the application section performs the operation flow of FIG. 10 described below.

[0084] In at least some embodiments, the objective function takes into account a set of constraints and maximizes the flow while minimizing the cost. In at least some embodiments, the program operations have order constraints, and the computing resources also have order constraints. Accordingly, the overall determination according to at least some embodiments is a combinatorial optimization of a bipartite graph, where the bipartite graph includes a set of computing resources and a set of program operations. In at least some embodiments, the solution includes the case of matching nodes so as to minimize the cost and maximize the amount of first-class information reaching the cloud server.

[0085] FIG. 7 is an operation flow for identifying candidate program operations according to at least some embodiments of the disclosure of the subject matter. The operation flow provides a method for identifying candidate program operations. In at least some embodiments, the method is performed by a server, such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is performed by an identification section, such as identification section 1120 shown in FIG. 11.

[0086] At S770, the identification section or its sub-section determines the ontology class of the content query. In at least some embodiments, the identification section reads one or more ontology classes indicated by the content query. In at least some embodiments, the identification section applies a model to the content query, and the model is configured to output an ontology class in response to the input of the content query. In at least some embodiments, the identification section performs the operation flow of FIG. 8 described below.

[0087] In S773, the identification section or its sub-section identifies the candidate detection operation. In at least some embodiments, the identification section identifies a program operation configured to instruct one or more sensors to capture raw data including at least a portion of the query content. In at least some embodiments, the identification section identifies a program operation configured to instruct one or more sensors to capture raw data collectively including the query content. In at least some embodiments, the identification section identifies a program operation configured to instruct one or more sensors to capture raw data from which at least a portion of the query content can be derived.

[0088] In S776, the identification section or its sub-section identifies the candidate compression operation. In at least some embodiments, the identification section identifies a program operation configured to compress raw data, filtered data, or previously compressed data. In at least some embodiments, the identification section identifies a program operation configured to reduce the capacity required to store data while preventing or minimizing data loss.

[0089] In S779, the identification section or its sub-section identifies the candidate filtering operation. In at least some embodiments, the identification section identifies a program operation configured to filter raw data, compressed data, or previously filtered data. In at least some embodiments, the identification section identifies a program operation configured to reduce the capacity required to store data by removing data portions not related to the query content.

[0090] FIG. 8 is an operation flow for determining an ontology class of a content query according to at least some embodiments of the disclosure of the subject matter. The operation flow provides a method for determining an ontology class of a content query. In at least some embodiments, the method is performed by a server, such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is performed by a controller of the server, such as controller 1102 shown in FIG. 11.

[0091] At S880, the controller determines whether a new ontology class exists. In at least some embodiments, the controller determines whether a new ontology class exists in response to receiving one or more content queries. In at least some embodiments, the controller determines whether a new ontology class exists in response to receiving an instruction to implement a new ontology class. If the controller determines that a new ontology class exists, the operation flow proceeds to ontology update at S884. If the controller determines that no new ontology class exists, the operation flow ends.

[0092] At S884, the controller updates the ontology. In at least some embodiments, the controller adds a new class to the ontology database. In at least some embodiments, the controller associates one or more program operations with the new ontology class. In at least some embodiments, the controller associates one or more previous content queries with the new ontology class.

[0093] With S888, a generation section of the controller, for example, the generation section 1126 shown in FIG. 11, generates one or more program operations. In at least some embodiments, the generation section generates one or more program operations associated with new ontology inputs. In at least some embodiments, the generation section generates program operations in response to an update of the ontology. In at least some embodiments, the generation section modifies one or more existing program operations to generate new program operations. In at least some embodiments, the generation section generates program operations to detect, compress, or filter data related to a new ontology class.

[0094] For a given ontology of classes, in at least some embodiments, the program operations are generated to obtain useful information applicable to each class. In at least some embodiments, the ontology of classes is periodically updated by adding new classes and, in some cases, removing unused classes. When the ontology is changed, the program operations required to collect information about the classes of the ontology are also changed. Thus, at least some embodiments perform updates at regular intervals or in response to a specific event, for example, each time the ontology is updated. In at least some embodiments, the controller updates the ontology at regular intervals or in response to a specific amount of content queries.

[0095] FIG. 9 is an operation flow for assigning costs according to at least some embodiments of the disclosure of the subject matter. The operation flow provides a method for assigning costs. In at least some embodiments, the method is performed by a server, for example, the server 120 shown in FIG. 1 or the server 440 shown in FIG. 4. In at least some embodiments, the method is performed by an assignment section, for example, the assignment section 1122 shown in FIG. 11.

[0096] At S990, the allocation section or its sub-section selects a candidate program operation. In at least some embodiments, the allocation section selects a candidate program operation from among a plurality of candidate program operations identified by the identification section. In at least some embodiments, as the iteration of operation S990 proceeds, the allocation section selects each candidate program operation once.

[0097] At S992, the allocation section or its sub-section combines with computing resources. In at least some embodiments, the allocation section combines the candidate program operation selected at S990 with computing resources. In at least some embodiments, the allocation section combines the candidate program operation with computing resources from among a plurality of computing resources available in a particular vehicle, along with any relevant edge and cloud computing resources. In at least some embodiments, the plurality of computing resources includes at least one vehicle sensor, at least one vehicle processor, at least one vehicle memory, and at least one cloud server. In at least some embodiments, the plurality of computing resources further includes at least one vehicle storage and at least one edge computing node. In at least some embodiments, the particular vehicle is of a certain manufacturer and model. In at least some embodiments, the computing resources include computing resources in each of a plurality of vehicles such as a plurality of vehicle manufacturers and models. In at least some embodiments, as the iteration of operation S992 proceeds, the allocation section combines each candidate program operation with each computing resource from among the plurality of computing resources.

[0098] In S994, the allocation section or its sub-section assigns potential PII leakage costs. In at least some embodiments, the allocation section assigns leakage costs representing the potential leakage of personal identification information associated with each valid combination of candidate program operations among a plurality of candidate program operations and computing resources among a plurality of computing resources. In at least some embodiments, the allocation section assigns leakage costs in units other than monetary values. In at least some embodiments, the allocation section assigns leakage costs in units of monetary values. In at least some embodiments, the allocation section assigns leakage costs according to an estimate of the damage resulting from the disclosure of PII. In at least some embodiments, as the iteration of operation S994 progresses, the allocation section assigns leakage costs to each valid combination.

[0099] In S995, the allocation section or its sub-section assigns monetary costs. In at least some embodiments, the allocation section further assigns the monetary costs of computation and transmission associated with each valid combination. In at least some embodiments, the allocation section assigns computation costs from the perspective of hardware costs and / or energy consumption. In at least some embodiments, the allocation section assigns transmission costs from the perspective of network usage costs and / or energy consumption. In at least some embodiments, as the iteration of operation S995 progresses, the allocation section assigns monetary costs to each valid combination.

[0100] In S997, the allocation section determines whether the selected candidate program operation is combined with all computing resources. If the allocation section determines that there are remaining uncombined computing resources, the operation flow returns to the combination of computing resources in S992. If the allocation section determines that the selected candidate program operation is combined with all computing resources, the operation flow proceeds to the candidate processing determination in S998.

[0101] In S998, the assignment section determines whether all candidate program operations have been selected. If the assignment section determines that there are remaining candidate program operations that have not been selected, the operation flow returns to the selection of candidate program operations in S990. If the assignment section determines that all candidate program operations have been selected, the operation flow ends.

[0102] FIG. 10 is an operation flow for applying an objective function according to at least some embodiments of the disclosure of the subject matter. The operation flow provides a way to apply the objective function. In at least some embodiments, the method is performed by a server, such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is performed by an application section, such as application section 1124 shown in FIG. 11.

[0103] In S1000, the application section or its sub-section identifies a candidate sequence. In at least some embodiments, the application section causes the identification section to identify the candidate sequence. In at least some embodiments, the application section takes in a data sample, where the data sample includes first class information and second class information, and identifies a sequence of possible combinations of candidate program operations and computing resources that perform the act of reducing the second class information of the data sample before transmitting the resulting data to the server. In at least some embodiments, the candidate sequence includes a varying number of candidate program operations. For example, one candidate sequence includes a number of different types of filtering and compression at various computational stages of a vehicle, while another candidate sequence gets by with little or no filtering and compression. In at least some embodiments, the application section identifies, as candidate sequences, all paths of valid combinations from the intake of the data sample to the transmission of the resulting data.

[0104] In S1003, the application section applies the objective function to the candidate sequences. In at least some embodiments, the application section applies the objective function to the candidate sequences to calculate the total cost. In at least some embodiments, as the iteration of operation S1003 progresses, the application section calculates the total cost of each candidate sequence.

[0105] In S1006, the application section determines whether all candidate sequences have been processed. If the application section determines that there are remaining candidate sequences that have not been processed, the operation flow returns to the application of the objective function in S1003 for the next candidate sequence. If the application section determines that all candidate sequences have been processed, the operation flow proceeds to sequence determination in S1009.

[0106] In S1009, the application section or its sub-section determines a sequence. In at least some embodiments, the application section determines which sequence to send for execution by the vehicle. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total cost for execution. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total leakage cost for execution. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total monetary cost for execution. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total leakage cost among the candidate sequences having a monetary cost less than the threshold monetary cost for execution. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total monetary cost among the candidate sequences having a leakage cost less than the threshold leakage cost for execution. In at least some embodiments, the application section determines to send the candidate sequence with the lowest total cost for execution, where the leakage cost is expressed in the same unit as the monetary cost.

[0107] In at least some embodiments, the overall determination can be made for a single vehicle or a group of vehicles. For a group in at least some embodiments, particularly where the group has heterogeneous capabilities, the overall solution output from the objective function assigns operations in a fixed or weighted manner. For example, a high-performance vehicle is given a high probability of being assigned a complex operation at a given start, while a lower-performance vehicle is associated with a low probability of being assigned a complex operation.

[0108] FIG. 11 is a diagram of a hardware configuration related to the determination of a program operation sequence for reducing potential leakage of personal identification information, according to at least some embodiments of the present disclosure.

[0109] A preferred hardware configuration includes a server 1100 that interacts with an input device 1109 and communicates with the input device 1109 through a network 1108. In at least some embodiments, the server 1100 is a computer or other computing device that receives an input or command from the input device 1109. In at least some embodiments, the server 1100 is incorporated into the input device 1109. In at least some embodiments, the server 1100 is a computer system that executes computer-readable instructions to perform operations regarding the determination of a program operation sequence for reducing potential leakage of personal identification information.

[0110] Server 1100 includes a controller 1102, a memory unit 1104, an input / output interface 1106, and a communication interface 1107. In at least some embodiments, controller 1102 includes a processor or programmable circuit that executes instructions to cause the processor or programmable circuit to operate in accordance with the instructions. In at least some embodiments, controller 1102 includes an analog or digital programmable circuit, or any combination thereof. In at least some embodiments, controller 1102 includes physically separated storage or circuitry that communicates with each other. In at least some embodiments, memory unit 1104 includes a non-volatile computer-readable medium that can store executable data and non-executable data that controller 1102 accesses during instruction execution. Communication interface 1107 transmits and receives data with network 1108. Input / output interface 1106 connects to various input and output units, such as input device 1109, via a parallel port, serial port, keyboard port, mouse port, monitor port, and the like, to receive commands and present information. In some embodiments, memory unit 1104 is external to server 1100.

[0111] Controller 1102 includes an identification section 1120, an allocation section 1122, an application section 1124, and a generation section 1126. Memory unit 1104 includes candidate operations 1130, cost parameters 1132, objective functions 1134, and sequences 1136.

[0112] The identification section 1120 is a circuit or instruction of the controller 1102 configured to identify candidate program operations. In at least some embodiments, the identification section 1120 is to capture data samples, where the data samples include first class information and second class information, and is configured to identify a plurality of candidate program operations that reduce the second class information of the data samples. In at least some embodiments, the identification section 1120 records information such as candidate operations 1130 in the storage unit 1104. In at least some embodiments, the identification section 1120 includes subsections that perform additional functions as described in the above flowchart. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0113] The allocation section 1122 is a circuit or instruction of the controller 1102 configured to allocate costs. In at least some embodiments, the allocation section 1122 is configured to allocate leakage costs representing potential leakage of personal identification information associated with each valid combination of a candidate program operation among a plurality of candidate program operations and a computing resource among a plurality of computing resources. In at least some embodiments, the allocation section 1122 utilizes information in the storage unit 1104 such as candidate operations 1130 and cost parameters 1132. In at least some embodiments, the allocation section 1122 includes subsections that perform additional functions as described in the above flowchart. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0114] The application section 1124 is a circuit or instruction of the controller 1102 configured to apply an objective function. In at least some embodiments, the application section 1124 is configured to apply the objective function to valid combinations and assigned leakage costs to determine a sequence of program operations, where each program operation of the sequence is performed by one or more selected computing resources such that the total leakage cost is less than a threshold leakage cost and the amount of first-class information is more than a data threshold. In at least some embodiments, the application section 1124 utilizes information within the storage unit 1104 such as candidate operations 1130 and objective function 1134 to record information such as sequence 1136 in the storage unit 1104. In at least some embodiments, the application section 1124 includes subsections that perform additional functions as described in the above flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0115] The generation section 1126 is a circuit or instruction of the controller 1102 configured to generate program operations. In at least some embodiments, the generation section 1126 is configured to generate program operations in response to an update of the ontology. In at least some embodiments, the generation section 1126 records information from the storage unit 1104 such as candidate operations 1130. In at least some embodiments, the generation section 1126 includes subsections that perform additional functions as described in the above flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0116] In at least some embodiments, the apparatus is another device capable of processing the logic functions for performing the operations herein. In at least some embodiments, the controller and the memory unit need not be completely separate devices, and in some embodiments, share circuitry or one or more computer-readable media. In at least some embodiments, the memory unit includes a hard drive storing both computer-executable instructions and data accessed by the controller, and the controller includes a combination of a central processing unit (CPU) and RAM, where the computer-executable instructions are wholly or partially copyable to be executed by the CPU during the execution of the operations herein.

[0117] In at least some embodiments where the apparatus is a computer, the program installed on the computer can cause the computer to function as or perform the operations associated with the apparatus of the embodiments described herein. In at least some embodiments, such a program is executable by a processor to cause the computer to perform certain operations associated with some or all of the blocks of the flowcharts and block diagrams described herein.

[0118] At least some embodiments are described with reference to flowcharts and block diagrams, where the blocks represent (1) steps of a process in which an operation is performed, or (2) sections of a controller that performs the operation. In at least some embodiments, certain steps and sections are implemented by dedicated circuits, programmable circuits supplied with computer-readable instructions stored on a computer-readable medium, and / or processors supplied with computer-readable instructions stored on a computer-readable medium. In at least some embodiments, the dedicated circuits include digital and / or analog hardware circuits, including integrated circuits (ICs) and / or discrete circuits. In at least some embodiments, the programmable circuits include reconfigurable hardware circuits having logical AND, OR, XOR, NAND, NOR, and other logical operations, flip-flops, registers, memory elements, etc., such as field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), and the like.

[0119] In at least some embodiments, a computer-readable storage medium includes a tangible device that can hold and store instructions used by an instruction execution device. In some embodiments, a computer-readable storage medium includes, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes, hereinafter, namely, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in a groove in which instructions are recorded, and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0120] In at least some embodiments, the computer-readable program instructions described herein are downloadable from a computer-readable storage medium to respective computing / processing devices or via a network, such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network, to an external computer or an external storage device. In at least some embodiments, the network includes copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. In at least some embodiments, a network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each respective computing / processing device.

[0121] In at least some embodiments, the computer-readable program instructions for performing the operations described above may be source code or object code written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or object-oriented programming languages such as Smalltalk, C++, or the like, and conventional procedural programming languages such as the "C" programming language or similar programming languages. In at least some embodiments, the computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In at least some embodiments, in the latter scenario, the remote computer is connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer is made (e.g., through the Internet using an Internet service provider). In at least some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) executes the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electronic circuit for performing aspects of the subject disclosure.

[0122] Embodiments of the subject disclosure are described, but the technical scope of any claimed subject is not limited to the embodiments described above. Those skilled in the art will understand that various modifications and improvements to the above-described embodiments are possible. Those skilled in the art will also understand from the claims that such additional embodiments added by such modifications or improvements are included in the technical scope of the present invention.

[0123] Unless the order is indicated by terms such as "first", "before", or the like, and unless the output from a previous process is used in a subsequent process, the operations, procedures, steps, and stages of each process performed by the apparatus, system, program, and method shown in the claims, embodiments, or figures can be performed in any order. Even if the process flow is described using phrases such as "first" or "next" in the claims, embodiments, or figures, such descriptions do not necessarily mean that the process must be performed in the described order.

[0124] In at least some embodiments, determining a program operation sequence to reduce potential leakage of personal identification information includes capturing a data sample including first class information and second class information, and identifying a plurality of candidate program operations that perform reducing the second class information of the data sample, and assigning a leakage cost representing the potential leakage of personal identification information associated with each valid combination of a candidate program operation among the plurality of candidate program operations and a computing resource among the plurality of computing resources, and applying an objective function to the valid combinations and the assigned leakage costs to determine a sequence of program operations, wherein each program operation of the sequence is performed by one or more selected computing resources such that the total leakage cost is less than a threshold leakage cost and the amount of the first class information is more than a data threshold.

[0125] Some embodiments include instructions in a computer program, a method performed by a processor that executes the instructions of the computer program, and an apparatus that performs the method. In some embodiments, the apparatus includes a controller that includes a circuit configured to perform operations within the instructions.

[0126] The above outlines the features of several embodiments so that those skilled in the art can more fully understand aspects of the present disclosure. Those skilled in the art should understand that they can readily use the present disclosure as a basis for designing or modifying other processes and structures that perform the same functions and / or achieve the same advantages as the embodiments incorporated herein. Those skilled in the art should also understand that such equivalent structures do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations can be made by those skilled in the art without departing from the spirit and scope of the present disclosure.

Claims

1. 1. A method, comprising: acquiring a data sample, the data sample including first class information and second class information; and Reducing the second class information of the data samples. identifying a plurality of candidate program actions that perform assigning a leakage cost representative of a potential leakage of personally identifiable information associated with each valid combination of candidate program operations among the plurality of candidate program operations and computing resources among the plurality of computing resources; applying an objective function to the valid combinations and assigned leakage costs to determine a sequence of program operations, each program operation of the sequence being performed by one or more selected computational resources such that a total leakage cost is less than a threshold leakage cost and an amount of first class information is greater than a data threshold; A computer-implemented method comprising:

2. The allocation may be further assigning a computational and transmission monetary cost associated with each valid combination; The method of claim 1 , wherein the sequence is one whose total monetary cost is less than a threshold monetary cost.

3. The method of claim 2 , wherein the plurality of computing resources comprises at least one vehicle sensor, at least one vehicle processor, at least one vehicle memory, and at least one cloud server.

4. The method of claim 3 , wherein the plurality of computing resources further comprises at least one vehicle storage and at least one edge computing node.

5. The method of any one of claims 1 to 4, wherein the plurality of computational resources comprises a computational resource in each of a plurality of vehicles.

6. The method of any one of claims 1 to 4, wherein the plurality of candidate program operations includes at least one detection operation, at least one compression operation, and at least one filtering operation.

7. The method according to any one of claims 1 to 4, wherein said identifying is performed in response to receiving a content query from a client terminal.

8. The method of claim 7 , wherein the content query is for one or more classes of an ontology.

9. The method of claim 8 , further comprising generating program actions in response to updating the ontology.

10. A non-transitory computer-readable medium containing instructions executable by a processor, the non-transitory computer-readable medium comprising: acquiring a data sample, the data sample including first class information and second class information; and Reducing the second class information of the data samples. identifying a plurality of candidate program actions that perform assigning a leakage cost representative of a potential leakage of personally identifiable information associated with each valid combination of candidate program operations among the plurality of candidate program operations and computing resources among the plurality of computing resources; applying an objective function to the valid combinations and assigned leakage costs to determine a sequence of program operations, each program operation of the sequence being performed by one or more selected computational resources such that a total leakage cost is less than a threshold leakage cost and an amount of first class information is greater than a data threshold; A non-transitory computer readable medium for causing operations to be performed, comprising:

11. The allocation may be further assigning a computational and transmission monetary cost associated with each valid combination; The computer-readable medium of claim 10 , wherein the sequence is one where the total monetary cost is less than a threshold monetary cost.

12. 12. The computer-readable medium of claim 11, wherein the plurality of computational resources comprises at least one vehicle sensor, at least one vehicle processor, at least one vehicle memory, and at least one cloud server.

13. The computer-readable medium of claim 12 , wherein the plurality of computing resources further comprises at least one vehicle storage and at least one edge computing node.

14. The computer-readable medium of any one of claims 10 to 13, wherein the plurality of computing resources comprises a computing resource in each of a plurality of vehicles.

15. The computer-readable medium of any one of claims 10 to 13, wherein the plurality of candidate program operations includes at least one detection operation, at least one compression operation, and at least one filtering operation.

16. The computer-readable medium of any one of claims 10 to 13, wherein the identifying is performed in response to receiving a content query from a client terminal.

17. The computer-readable medium of claim 16 , wherein the content query is for one or more classes of an ontology.

18. The computer-readable medium of claim 17 , further comprising generating program actions in response to updating the ontology.

19. An apparatus, comprising: a controller including circuitry configured to perform operations, the operations including: acquiring a data sample, the data sample including first class information and second class information; and Reducing the second class information of the data samples. identifying a plurality of candidate program actions that perform assigning a leakage cost representative of a potential leakage of personally identifiable information associated with each valid combination of candidate program operations among the plurality of candidate program operations and computing resources among the plurality of computing resources; applying an objective function to the valid combinations and assigned leakage costs to determine a sequence of program operations, each program operation of the sequence being performed by one or more selected computational resources such that a total leakage cost is less than a threshold leakage cost and an amount of first class information is greater than a data threshold; 13. An apparatus comprising:

20. The allocation may be further assigning a computational and transmission monetary cost associated with each valid combination; 20. The apparatus of claim 19, wherein the sequence is one such that a total monetary cost is less than a threshold monetary cost.

Images