Mobile computing network query content capture

Abstract

Mobile computing network query content capture is performed by receiving a task executable by a mobile computing network and a retention policy from a server, executing the task using the mobile computing network to capture target content, assigning a reduced probability to a first instance of the captured target content based on the retention policy, in response to the available storage amount becoming equal to or below a threshold amount, at least one of the first instance and a portion of the other stored data is reduced based on the probability of reduction, and each instance of the captured target content is transmitted in response to connecting to the wide area network.

Description

Background Art

[0001] Distributed databases are typically queried by replicating the database and directing all queries to the replica rather than the original database. As connectivity between different products increases, software developers seek to develop new applications that allow users to customize their experience for different products. To develop applications, software developers rely on data structures within the product in order to develop applications that can run reliably on the product. In some cases, application program interfaces (APIs) help allow applications to exchange data with products without having to customize the application specifically for the product. However, in some cases, understanding the data types and data formats available within the product helps software developers enhance applications to improve the user experience of the product. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various aspects of the present disclosure can be best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, in accordance with standard practice in the industry, various features are not drawn to scale. In fact, the size of various features may be arbitrarily increased or reduced for clarity of discussion.

[0003] Figure 1 is a schematic diagram of a system for mobile computing network content querying and capturing, in accordance with at least some embodiments of the present disclosure.

[0004] Figure 2 is a diagram of a graphical user interface (GUI) for mobile computing network content query according to at least some embodiments of the present disclosure.

[0005] Figure 3 is a diagram of a data structure for a content retrieval task according to at least some embodiments of the present disclosure.

[0006] Figure 4 is a schematic diagram of a query content retrieval system according to at least some embodiments of the present disclosure.

[0007] Figure 5 An operational flow for mobile computing network query content capture according to at least some embodiments of the present disclosure.

[0008] Figure 6 is an operational flow for performing a content capture task according to at least some embodiments of the present disclosure.

[0009] Figure 7

[0026] An operational flow for assigning reduced probabilities in accordance with at least some embodiments of the present disclosure.

[0010] Figure 8

[0026] Operational flows for transmitting captured content in accordance with at least some embodiments of the present disclosure.

[0011] Fig. 9 is a diagram of a hardware configuration for mobile computing network content querying and capturing, in accordance with at least some embodiments of the present disclosure. DETAILED DESCRIPTION

[0012] The following disclosure provides many different embodiments or examples for realizing the different features of the provided subject matter. Specific examples of components, values, operations, materials, arrangements or the like are described below to simplify the present disclosure. Of course, these are merely examples and are not intended to be restrictive. Other components, values, operations, materials, arrangements, etc. may also be considered. For example, in the following description, the formation of a first feature above or on a second feature may include an embodiment in which the first feature and the second feature are formed as direct contacts, and may also include an embodiment in which additional features may be formed between the first feature and the second feature so that the first feature and the second feature may not be in direct contact. In addition, the present disclosure may repeat figure numerals and / or letters in various embodiments. This repetition is for the purpose of brevity and does not itself determine the relationship between the various embodiments and / or configurations discussed.

[0013] In addition, for ease of description, spatially relative terms such as "below," "beneath," "lower," "above," "upper," etc. may also be used herein to describe the relationship of one element or feature to another (one or more) elements or (one or more) features shown in the figures. Spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientations depicted in the figures. The device may also be in other orientations (rotated 90 degrees or at other orientations), and the spatially relative descriptors used herein may be interpreted similarly.

[0014] As a distributed database, the fleet of vehicles is expensive and time-consuming to replicate, as all data must be uploaded from each vehicle, and their connections and bandwidth are unstable and expensive. Direct queries to the distributed database must be done carefully to ensure that the query does not cause the system to crash.

[0015] To help maintain the working status of the distributed database, ie, the working status of each vehicle in the group, at least some embodiments herein filter queries for feasibility and customize queries for different vehicle models in the group.

[0016] In at least some embodiments, customizing a query for a vehicle model includes referencing a database of computing resources and running processes for that vehicle model. In at least some embodiments, processes are carefully designed for execution on a specific vehicle model to help vehicles of that model avoid resource shortages. In at least some embodiments, even vehicles with fewer computing resources are programmed to perform more complex tasks, and the query creator is notified if the amount of time to collect data is too large. In at least some embodiments, the query engine estimates when results can be obtained based on the likelihood of encountering an event that generates the requested data, bandwidth to the server, and computing resources of the vehicle model.

[0017] In at least some embodiments, the vehicle is configured to perform a query to collect the requested data. In at least some embodiments, the vehicle is configured to store the requested data in the vehicle until one or more conditions for uploading the data are met. In at least some embodiments, the vehicle is configured to perform multiple queries and store multiple instances of the requested data until uploaded. In at least some embodiments, the vehicle is configured to compress, filter, or clear the requested data in response to unavailable storage resources based on corresponding priority values ​​established by the server. At least some embodiments of the present invention enable direct querying of distributed databases and notify the inquirer of the likelihood and waiting time of receiving results.

[0018] Users (such as software developers, insurance providers, market researchers, and law enforcement officials) can use the On-Demand Data Retrieval (ODDR) system to enter data requests into a user interface, such as a graphical user interface (GUI). Software developers are software developers who develop application software, middleware, or OS (Operating System) that runs on a vehicle. Example applications include autonomous driving system applications, such as object recognition applications, road recognition applications, sensor fusion applications, positioning applications, path planning applications, controller applications, etc. The data request is analyzed and stored in the server and then transmitted to the vehicle by the server. On the server side, the data request is stored in a storage unit, and a request queue is generated based on the stored requests. The user can view or request an update to the status of the data request. For example, when the data request is still in the server before being transmitted to the vehicle, the status can be indicated as "in progress". Once the server transmits the data request to the vehicle, the status can be updated to "submitted". This allows the user to view and track the status of the data request made to the vehicle. Those of ordinary skill in the art will recognize that for clarity, the description refers to one vehicle; however, in addition to a single vehicle, the description also applies to multiple groups of vehicles.

[0019] The user interface for generating a data request includes a table related to vehicle identification information, the type of data requested, a start time, and an end time. In some embodiments, the start time and the end time are absolute times, such as Unix time, i.e., the time elapsed from the Unix epoch time. In some embodiments, the start time and the end time are relative times relative to the time when the vehicle receives the data request. In some embodiments, the start time and the end time are relative times relative to a triggering event. A triggering event refers to an event that occurs in the environment inside or around a vehicle where a user is searching for data or receiving a data request for a vehicle. For example, a triggering event caused by the environment around the vehicle includes sudden acceleration, sudden braking, capturing an image of the target of the data request, detecting the target of the data request, or other suitable events. User information for monitoring the status of a data request includes identification information of the data request and the status of the data request, such as in progress or submitted.

[0020] In some embodiments, once a data request is received by the vehicle, the data request is processed so that the data request is independent of the source of the data request. In some embodiments, a data request identification (ID) is assigned to a received data request by the vehicle, such as by a request abstractor in the vehicle. In some embodiments, the data request ID is assigned to the data request before the data request is transmitted to the vehicle. In some embodiments, the data request is generated by an application running in the vehicle and the data request ID is assigned by the application. In other words, data is processed in a consistent manner regardless of the program or system that transmits 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 a manner consistent with the data request received from the external device. This helps to share the same data collection software component between triggered data collection where an application generates a data collection request to a recorder and an external data collection request based on ODDR.

[0021] In some embodiments, once the vehicle receives the data request, the data request is processed so that the data request is independent of the sensors and servers in the vehicle. In some embodiments, the data request is generated by an application running in the vehicle. In some embodiments, an application programming interface (API) can be used to make the data request from the application independent of the sensors in the vehicle or the information from the server. This helps to maximize the user's ability to collect data without programming requests for specific sensor models. The data request is then passed to the data collector and the requested data is collected in response to the occurrence of a triggering event. In the event that a triggering event (such as a traffic accident) has occurred, the data request will be completed based on the data stored in the storage device in the vehicle. The time range of the collected data, i.e., the start time and the end time, is determined based on the data request. The collected data is passed back to the server.

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

[0023] In some examples, a budget management system or payment system is implemented on the server side or the vehicle side so that a data request fee is charged to the user. The fee can be paid when the request is submitted or when the data collection is completed. The fee can be adjusted based on the type and amount of data requested. In some embodiments, when the total amount of fees charged to the user reaches a maximum threshold of the user's budget, the data request from the user is rejected.

[0024] The ODDR system allows users to access information collected by the vehicle in an on-demand form. That is, data does not have to be collected continuously, but can be collected to meet the specific wishes of the user. In some embodiments, the ODDR system helps users (such as software developers) collect data and update the design, implementation, and parameter adjustments of their software in an exploratory manner based on the collected data, so that users can deliver updates from the server to the vehicle via the network (for example, as an Over-the-Air (OTA) update), thereby continuously improving the software. In some embodiments, the ODDR system can help machine learning developers who develop machine learning models for applications that collect data to train the models using data that was not available when the models were initially developed, so that machine learning developers can update the models and continuously correct the weaknesses and problems of the models. In some instances, insurance providers can collect data related to traffic accidents. In some instances, law enforcement officers can collect information related to crimes or traffic accidents.

[0025] Figure 1is a schematic diagram of a request retrieval system 100 according to some embodiments. The request retrieval system 100 includes a user interface (UI) 110. The UI 110 is configured to receive a user request for data from a vehicle 140. The request retrieval system 100 also includes a server 120, which is configured to: receive the user request from the UI 110; transmit 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 portion 130 for communicating with the UI 110 and the vehicle 140. The request retrieval system 100 also includes an accessible console 150, which is configured to communicate the data collected from the vehicle 140 to the user.

[0026] UI 110 is configured to receive input instructions from a user. In some embodiments, the user includes a software developer. In some embodiments, the user includes a machine learning model developer. In some embodiments, the user includes an insurance provider. In some embodiments, the user includes a law enforcement officer. In some embodiments, the user includes a market research company. UI 110 provides options for the user to select what type of vehicle and what type of data to request. In some embodiments, UI 110 can generate a data request using a form associated with vehicle identification information, requested data type, start time and end time. In some embodiments, the start time and end time are absolute times, such as Unix time, i.e., the time elapsed from the Unix epoch time. In some embodiments, the start time and end time are relative times relative to the time when the vehicle receives the data request. In some embodiments, the start time and end time are relative times relative to the triggering event. In some embodiments, UI 110 also provides the user with options for selecting a triggering event and a duration of data collection relative to the triggering event. In some embodiments, UI 110 includes information related to the type of vehicle from which data is requested. In some embodiments, UI 110 includes a vehicle ID that can uniquely identify the vehicle as the target of the request. For example, the vehicle ID includes a Universally Unique Identifier (UUID) format. In some embodiments, UI 110 includes data types that can identify the source of data that the user wishes to collect. For example, the data types include the sensor ID of the sensor from which the sensor data is collected, the application ID of the application from which the application log is collected. In some embodiments, the format of the sensor ID and the application ID includes a universal unique identifier (UUID) format. In some embodiments, UI 110 includes a drop-down menu. In some embodiments, UI 110 includes an editable field for receiving information related to the data request. In some embodiments, UI 110 provides information about what 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, law enforcement officers can select more data options than insurance providers.

[0027] In some embodiments, UI 110 includes a graphical user interface (GUI). In some embodiments, UI 110 includes a mobile terminal, such as a mobile phone, that can be connected to server 120. In some embodiments, UI 110 includes a network interface, such as a RESTful API. In some embodiments, UI 110 includes a computer that can be connected to server 120. In some embodiments, UI 110 can be wirelessly connected to server 120. In some embodiments, the user interface can be connected to server 120 via a wired connection. UI 110 can also provide updates on the status of data requests to the user. In some embodiments, UI 110 provides status updates on data requests in response to additional queries from the user. In some embodiments, UI 110 automatically provides status updates on data requests when receiving update information from server 120 without user interaction. In some embodiments, the status update causes UI 110 to trigger an alarm to the user. In some embodiments, the alarm includes an audio or visual alarm.

[0028] In some embodiments, UI 110 includes a device for accepting payment from a user. In some embodiments, UI 110 includes a data entry field that allows a user to enter payment card information. In some embodiments, UI 110 includes a reader for detecting payment card information, such as a magnetic stripe reader, barcode reader, chip reader, or other suitable reader.

[0029] The server 120 includes a communication portion 130 configured to communicate with the UI 110 and the vehicle 140. The communication portion 130 includes a receiver 131 configured to receive a data request from the UI 110. In some embodiments, the receiver 131 includes a wireless receiver. In some embodiments, the receiver is configured to receive the data request via a wired connection. In some embodiments, the receiver 131 is also configured to perform initial processing on the received data request. In some embodiments, the received data request includes priority level information. In some embodiments, the receiver 131 is configured to assign a priority level to the data request based on the identity of the user submitting the data request or the fee paid by the user submitting the data request. In some embodiments, the receiver 131 is configured to assign a request identification (ID) number to each received data request. In some embodiments, the server 120 is configured to restrict access to certain sensors in the vehicle 140 based on the identity of the user. For example, in some embodiments, third-party users will not be able to access sensors related to the safety functions of the vehicle 140.

[0030] The communication portion 130 also includes a memory unit 132 configured to store data requests received by the receiver 131. In some embodiments, the memory unit 132 includes random access memory, solid-state memory, or other types of memory. In some embodiments, the memory unit 132 is configured to store data requests and the status of the data requests. In some embodiments, the status of the data request includes in progress (before transmitting the data request to the vehicle 140), submitted (after transmitting 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 to a user. In some embodiments, an update to the information in the memory unit 132 triggers a notification to a user associated with the updated information in the memory unit 132. In some embodiments, the memory unit 132 stores the data request in conjunction with timestamp data indicating the time when the data request was received. In some embodiments, the memory unit 132 stores the data request 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 officers have a higher priority than insurance providers, and insurance providers have a higher priority than ordinary users such as software developers. In some embodiments, the priority level is determined based on fees paid by the user. For example, in some embodiments, a user can pay a fee to increase the priority level of their request to obtain the requested data more quickly. In some embodiments, the priority level of a data request increases as the amount of time between initial storage of the data request and transmission of the data request to the vehicle increases.

[0031] The communication portion 130 also 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 transmitted to the UI 110 wirelessly. 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 updates to the data request in response to updates in the memory unit 132. In some embodiments, the transmitter 133 is configured to provide updates to the data request in response to an update request received from a user. In some embodiments, the transmitter 133 is configured to automatically transmit the request ID when the data request is initially saved in the memory unit 132. In some embodiments, the status of the data request includes a priority level of the data request. In some embodiments, the status of the data request includes an estimated time until the data request is transmitted to the vehicle 140.

[0032] The communication portion 130 also includes a query queue 134 configured to store data requests for transmission to the vehicle 140 in priority order. In some embodiments, the query queue 134 is integrated into 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 the timestamp information. In some embodiments, the query queue 134 is configured to sort the data requests based on the priority level; and in response to data requests having the same priority level, sort according to the time since they were initially stored in the memory unit 132.

[0033] The communication portion 130 also includes a transmitter 135 configured to transmit a data request from the query queue 134 to the vehicle 140. The transmitter 135 is configured to transmit the data request to the vehicle 140 based on the order of the data request in the query queue 134. In some embodiments, the data request is transmitted to the vehicle 140 wirelessly. In some embodiments, the data request is transmitted to the vehicle 140 through a wired connection. The data request transmitted to the vehicle 140 includes trigger event information, data duration information related to how long before and after the trigger event data should be collected, and sensor information indicating the type of sensor in the vehicle 140 that should collect data. In some embodiments, the data request transmitted to the vehicle 140 includes priority level information. In some embodiments, the transmitter 135 is configured to transmit the data request to the vehicle 140 when the vehicle 140 sends a request to the server 120 to transmit the data request to the vehicle 140. In some embodiments, the transmitter 135 is configured to transmit a data request to the vehicle 140 whenever the communication portion 130 has sufficient connectivity with the vehicle 140 to transmit the data request, unless the communication portion 130 receives information indicating that the vehicle 140 cannot accept new data requests. In some embodiments, the transmitter 135 is configured to periodically transmit data requests to the vehicle 140 as long as the vehicle 140 is able to receive new data requests and the transmitter 135 has sufficient connectivity with the vehicle 140. In some embodiments, the transmitter 135 is configured to transmit data requests to the vehicle 140 in batches, such as 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 acknowledgment of receipt of the data request from the vehicle 140. The transmitter 135 is configured to retransmit the data request in response to not receiving an acknowledgment of receipt from the vehicle within a predetermined time period. In some embodiments, in response to the communication portion 130 receiving an acknowledgement of receipt of the data request from the vehicle 140 , the status of the data request stored in the memory unit 132 is updated to indicate submission to the vehicle 140 .

[0034] The communication portion 130 also includes a receiver 136 configured to receive a notification of the occurrence of a triggering event from the vehicle 140. In some embodiments, the occurrence of the triggering event is the receipt of a data request. In some embodiments, the receiver 136 is configured to receive the notification of the triggering event wirelessly. In some embodiments, the receiver 136 is configured to receive the notification of the triggering event via a wired connection. In some embodiments, the receiver 136 is configured to send a signal to the memory unit 132 to update the status of the data request associated with the notified triggering event.

[0035] The communication portion 130 also includes a receiver 137 configured to receive data from the vehicle 140 in response to a data request transmitted by the transmitter 135. In some embodiments, the data is segmented by the vehicle 140 into data packets, which are transmission units from the vehicle 140 to the server 120, and the receiver 137 receives the data packets from the vehicle 140. In some embodiments, the receiver 137 is configured to receive the data wirelessly. In some embodiments, the receiver 137 is configured to receive the data via a wired connection. In some embodiments, the receiver 137 is configured to send a signal to the memory unit 132 to update the status of the data request related to the reception of the requested data. In some embodiments, the data in response to a single data request is received from the vehicle 140 in a single data packet. In some embodiments, the data in response to a single data request is received from the vehicle 140 in multiple data packets. The receiver 137 passes the received data to the preprocessor 122.

[0036] The server 120 also includes a preprocessor 122 configured to receive data from the receiver 137 and perform preprocessing on the data to generate collected data. In some embodiments, preprocessing includes reorganizing data from multiple data packets to compile data in response to data requests. In some embodiments, preprocessing includes deserializing the data to compile structured data from the received byte array. In some embodiments, if the data has been compressed by the vehicle 140 before transmission, the preprocessing includes decompression of the data. In some embodiments, preprocessing includes error correction by error correction codes (Error Correction Code, ECC) such as Reed-Solomon (RS) code, Bose-Chaudhuri-Hocquenghem code (BCH) code, Low-Density Parity-Check (LDPC) code, etc. In some embodiments, preprocessing includes smoothing the data by removing outliers to reduce the risk of reporting erroneous data to the user. In some embodiments, preprocessing includes associating data request ID information, priority level information, or other appropriate information with data received from receiver 137. In some embodiments, preprocessing the data allows the information to be provided to the user in an easily understandable format without relying on expertise or equipment to discern the information.

[0037] The server 120 also 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 integrated with the memory unit 132. In some embodiments, the data storage 126 is separated from the memory unit 132. In some embodiments, the data storage 126 includes a solid state drive (SSD), a random access memory, or other suitable memory. In some embodiments, the user can access the data storage 126, 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 the data associated with the data request being available. In some embodiments, the notification includes an alarm to the user. In some embodiments, the alarm includes an audio or visual alarm. In some embodiments, the data storage 126 is configured to automatically display a notification of the availability of the collected data by 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 submitting a data request. In some embodiments, the user can search the data in the data storage 126 via the accessible console 150. In some embodiments, the collected data is visualized in the console 150.

[0038] The request retrieval system 100 also includes a vehicle 140. The vehicle 140 includes sensors for detecting the internal state of the vehicle 140 and the external environment around the vehicle 140. In some embodiments, the sensors include cameras, light detection and ranging (Light Distance And Ranging, LiDAR) sensors, radio detection and ranging (Radio Distance And Ranging, RADAR) sensors, sound navigation and ranging (Sound Navigation And Ranging, SONAR) sensors, accelerometers, steering wheel positions, speedometers, or other suitable sensors. The vehicle 140 is capable of receiving data requests wirelessly or via a wired connection.

[0039] In some embodiments, the vehicle 140 is configured to assign a data request ID to the received data request in response to receiving the data request, and the data request is processed to be independent of the initiating system or program of the data request. In other embodiments, the communication portion 130 specifies the data request ID instead of the vehicle 140, and the data request ID is included in the data request sent from the communication portion 130 to the vehicle 140. Making the data request independent of the initiating system or program of the data request helps to expand the ability of the vehicle 140 to receive and process various data requests from different users and systems. The vehicle 140 includes a processor for processing the data request and determining which type of information from which sensors available in the vehicle 140 can satisfy the data request. In at least some embodiments, the vehicle 140 includes a mobile computing network, which is a network of processors, controllers, or a combination thereof, such as a controller area network (CAN). In at least some embodiments, each processor is an electronic control unit (ECU). The vehicle 140 also includes a memory for storing data from the sensor. In some embodiments, the processor accesses the memory to determine whether the stored data can satisfy the data request. The vehicle 140 can also transmit data deemed to satisfy the data request to the server 120 wirelessly or via a 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 of the received data requests. In some embodiments, the vehicle 140 is configured to prioritize transmission of data to the server based on the priority level of the received data requests.

[0040] In some embodiments, the memory and processor of the vehicle 140 are configured to store and execute software applications in an electronic control unit (ECU) within the vehicle 140. In some embodiments, the data request is generated by the software application stored in the ECU. In some embodiments, the data request is generated in response to a trigger event, such as sudden acceleration, sudden braking, sensor data captured including a specific object or a specific scene predefined in the software application, a software application "crash", an anomaly detected in the software application, or other appropriate detected occurrences. In some embodiments, the vehicle 140 is configured to generate a notification to the maintainer (e.g., user) of the software application in response to detecting a trigger event related to the software application. In some embodiments, the notification is transmitted directly to the user, for example, wirelessly or via a wired connection via the UI 110. In some embodiments, the notification is transmitted to the user wirelessly or via a wired connection via the server 120. In some embodiments, the notification includes an audio or visual notification. In some embodiments, the notification is configured to cause the UI 110 to automatically display the notification without user interaction.

[0041] The request retrieval system 100 also includes an accessible console 150. The accessible console 150 allows a user to access the collected data stored in the data storage 126. In some embodiments, the accessible console 150 is integrated with 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 separate from the server 120. In some embodiments, the accessible console 150 automatically receives the collected data related to the data request from the user after the data storage 126 receives the collected data. In some embodiments, the accessible console 150 allows the user to search the data storage 126 to determine whether any of the collected data stored in the data storage 126 is useful to the user without the user submitting a data request.

[0042] Using the request retrieval system 100, accurate users can obtain information from one or more vehicles 140 in an easily understandable format without relying on specialized equipment to request or read the received data. The ability to prioritize data requests in the request retrieval system 100 helps ensure that law enforcement or other users can obtain the data, while also allowing users to pay a fee to obtain the data more quickly. This flexibility helps increase the usefulness of the request retrieval system 100 to a wide range of users.

[0043] Figure 2 2 is a diagram of a graphical user interface (GUI) 200 and 250 of a request retrieval system according to some embodiments. In some embodiments, GUI 200 may be used as a request retrieval system 100 ( Figure 1) in the UI 110. In some embodiments, the GUI 200 may be used to generate a user interface for the receiver 131 ( Figure 1 ) received by the user. The GUI 200 includes a plurality of information types 210, which identify the types of information that the GUI 200 can accept from the user. The GUI 200 also includes a plurality of fields 220, which are configured to receive information related to the corresponding information types 210 of the GUI 200. The GUI 200 also includes a submit button 230, which is configured to submit a request to a server (e.g., the server 120 ( Figure 1 )) submits a data request. Those skilled in the art will recognize that the names and quantities of the plurality of information types 210 are merely exemplary, and that different quantities and types of information are also within the scope of the present disclosure.

[0044] In some embodiments, field 220 includes fields for the user to enter a vehicle ID, a data type, a start time, and an end time. In some embodiments, field 220 also includes a field for the user to enter a priority level for the data request. In some embodiments, GUI 200 also includes information related to how the user can increase the priority level of the data request, such as indicating the fees associated with each available priority level. In some embodiments, GUI 200 includes field 220 for allowing the user to enter 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 also includes field 220 for receiving payment information related to the fees for establishing the priority level of the data request.

[0045] GUI 250 is configured to be displayed to the user after the user selects the submit button 230 on GUI 200. In some embodiments, GUI 250 can be used as an ODDR system 100 ( Figure 1 ) in the GUI 110. The GUI 250 includes information indicating that the data request has been received. The GUI 250 includes a query ID tag 260 and a query ID field 270. After the server receives and stores the data request, the server (e.g., server 120 ( Figure 1 )) receives information for populating the query ID field 270. In some embodiments, the GUI 250 includes vehicle ID information. 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 in progress, submitted, completed, etc.). In some embodiments, the GUI 250 includes information related to the status of the data request until the data request is submitted to the vehicle (e.g., vehicle 140) ( Figure 1). In at least some embodiments, GUI 250 includes information related to an estimated time until the requested data is received. In at least some embodiments, GUI 250 includes information related to an estimated energy consumption of receiving the requested data. In some embodiments, GUI 250 is automatically displayed in response to query ID information received from the server. In some embodiments, GUI 250 is displayed in response to a user-submitted request for an update to the uploaded data request.

[0046] Figure 3 3 is a diagram of a data structure 300 of a request retrieval command 310 according to some embodiments. In some embodiments, the request retrieval command 310 is transmitted from the server 120 to the vehicle 140 ( Figure 1 ). The request retrieval command 310 includes a request to a vehicle (eg, vehicle 140 ( Figure 1 ))Information about the type of data sought by the data request made.

[0047] The request to retrieve command 310 includes a transfer priority parameter 311, which indicates the priority level of the data request. The request to retrieve command 310 also includes a log level parameter 312, which indicates what type of data (if any) should be retrieved from other applications on the vehicle. For example, in some embodiments, the request to retrieve command 310 retrieves data from an object recognition application. The log level parameter 312 determines what type of data to retrieve from other applications, such as an error level or a critical level. In some embodiments, the log level parameter 312 is omitted from the request to retrieve command 310, or the log level parameter 312 is in a null state. The request to retrieve command 310 also includes a time range to be collected parameter 313, which indicates the time period before and / or after the triggering event to collect data. The time range corresponds to the time range specified by the user in the GUI 200 ( Figure 2) in the event time range 313. The request retrieval command 310 also includes a Uniform Resource Locator (URL) endpoint parameter 314, which indicates the destination of the data collected in response to the data request. The request retrieval command 310 also includes a frequency parameter 315, which indicates how frequently (if any) data should be sampled from the time range 313. For example, when the event time is t=100 seconds, the time range includes a start time=-1 second and an end time=2 seconds, and the frequency is 10 Hz (100 millisecond period), then according to the request retrieval command, data of t=99.0 seconds, 99.1 seconds, 99.2 seconds, ..., 101.9 seconds, 102.0 seconds are collected. The request retrieval command 310 also includes a log ID parameter 316, which indicates the type of sensor and / or application that can be used to collect the data requested by the data request. In some embodiments, a unique ID (such as a universally unique identifier (UUID)) is pre-assigned to all sensors and applications, and the unique ID from which the user wishes to collect data is specified in the log ID parameter 316. The request retrieval command 310 also includes a requestor ID parameter 317, which indicates the identity of the user making the data request. The request retrieval command 310 also includes an event ID parameter 318, which indicates a triggering event associated with the data request. The request retrieval command 310 also includes a budget ID parameter 319, which indicates the vehicle (e.g., vehicle 140 ( Figure 1 )) should be allocated to satisfy the data request. It will be appreciated by those skilled in the art that other parameters in the request to retrieve command 310 are possible. For example, in some embodiments, the request to retrieve command 310 includes a vehicle location parameter that indicates a geographic area where the triggering event may occur. It will also be appreciated by those skilled in the art that the request to retrieve command 310 does not always include a vehicle location parameter. Figure 3 For example, in some embodiments, the budget ID parameter 319 is omitted.

[0048] Figure 4 4 is a block diagram of a request retrieval system 400 according to some embodiments. In some embodiments, the request retrieval system 400 is a request retrieval system 100 ( Figure 1 ). In some embodiments, the request retrieval system 400 may be connected to the request retrieval system 100 ( Figure 1 ) is used in combination. In some embodiments, the request retrieval system 400 is used in combination with the request retrieval system 100 ( Figure 1 )Separation.

[0049] The request retrieval system 400 includes a detection vehicle system 410 configured to capture information about a vehicle or the surroundings of the vehicle. The detection vehicle system 410 captures information about the vehicle and the surroundings and transmits the information to a server. The request retrieval system 400 also includes a server 440 configured to receive the information, encode the information, and transmit the information to a user terminal 460.

[0050] 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 designator 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.

[0051] In some embodiments, the ECU 420 also includes a positioning unit configured to receive data from the GPS 416 and the map 418 and determine the position of the vehicle and the attitude and state of the vehicle relative to detected and / or known objects and / or road positions. The attitude is the orientation of the vehicle relative to a reference point (such as a road). In some embodiments, the position of the vehicle also refers to the position vector of the vehicle. The attitude and state of the vehicle refers to the speed and heading of the vehicle. In some embodiments, the attitude and state of the vehicle also refers to the velocity vector, acceleration vector and bump vector of the vehicle. In some embodiments, the position vector, velocity vector, acceleration vector and bump vector include an angle vector. In some embodiments, the state of the vehicle also refers to whether the engine or motor of the vehicle is running.

[0052] Sensor 414 is configured to capture information about the vehicle's surroundings, such as images. In some embodiments, sensor 414 includes a visible light camera, an infrared camera. In some embodiments, sensor 414 is replaced or further accompanied by a light detection and ranging (LiDAR) sensor, a radio detection and ranging (RADAR) sensor, a sound navigation and ranging (SONAR) sensor, or other suitable sensors. In some embodiments, sensor 414 includes additional cameras located at other locations of the vehicle. For example, in some embodiments, additional cameras are located on both sides of the vehicle to detect and observe a larger portion of the environment on the left and right sides of the vehicle. Since vehicle occupants can look out from the side windows of the vehicle, using additional cameras to detect a larger portion of the environment around the vehicle helps to increase the accuracy of detecting objects or scenes around the vehicle. For example, in some embodiments, additional cameras are located on the rear side of the vehicle to detect a larger portion of the environment behind the vehicle. This information helps to capture information about objects. In some embodiments, data from sensor 414 includes timestamps or other metadata to help synchronize data from sensor 414 with data from other components.

[0053] GPS 416 is configured to determine the location of the vehicle. Knowing the location of the observed vehicle helps to correlate objects or scenes with locations determined on map 418.

[0054] Map 418 includes information related to roads and known objects along the roads. In some embodiments, map 418 can be used in conjunction with GPS 416 to determine the location and heading of the vehicle. In some embodiments, map 418 is received from an external device (such as server 440). In some embodiments, map 418 is regularly updated based on information provided by sensor 414 and / or GPS 416. In some embodiments, map 418 is regularly 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 determine whether an object is a known object. Including map 418 with known objects helps increase the accuracy of new object detection.

[0055] Situation detector 422 is configured to generate information related to the performance of the vehicle and systems within the vehicle. Situation detector 422 is capable of collecting information from components within the vehicle, such as sensors 414, braking systems, acceleration systems, and other suitable components. Using this information, situation detector 422 is able to determine the performance of the vehicle. In some embodiments, situation detector 422 is also configured to monitor the performance of software and network operations within the vehicle. For example, in some embodiments, situation detector 422 is configured to receive information related to software or application "crashes" within the vehicle. In some embodiments, situation detector 422 is configured to collect information related to 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 power of a processor within the vehicle.

[0056] 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 information related to vehicle speed, acceleration, pitch, braking, steering, pitch, roll, yaw, flashing hazard lights, horn honking, or other appropriate information. The vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates that the criteria for satisfying the request have been met, such as detecting a triggering event.

[0057] The object detector 426 is configured to receive sensor data from the sensor 414 to determine whether any unusual objects are located in the road. In some embodiments, the object detector 426 is further configured to determine whether any objects are present along the road or adjacent to the road. In some embodiments, the sensor data from the sensor 414 includes images, and the object detector 426 is configured to perform image recognition on the received images, for example, using a trained neural network, to identify unusual objects. In some embodiments, the object detector 426 is configured to compare any identified objects with information from the GPS 416 and the map 418 to help determine the type of object identified. In some embodiments, the object detector 426 is configured to identify objects, such as tires, car parts, etc., animals, potholes, traffic control panels, emergency vehicles, vehicles with hazard lights activated, or other suitable objects as objects.

[0058] The scene detector 428 is configured to receive sensor data from the sensor 414 to determine whether there are any scenes in the vehicle's surroundings that meet the conditions for satisfying the request. 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 a vehicle is surrounded by multiple fallen objects. In some embodiments, the scene detector 428 is configured to determine that construction is occurring based on detecting that multiple construction vehicles are approaching. In some embodiments, the scene detector 428 is configured to determine that the vehicle is parked on the shoulder of the road based on determining that the vehicle is located near the road and is not moving or is moving significantly slower than other vehicles. In some embodiments, the scene detector 428 is configured to use image recognition (such as through a trained neural network) to determine the content of the scene surrounding the vehicle.

[0059] In some embodiments, each of object detector 426 and scene detector 428 is activated during the entire operation period of the vehicle (e.g., when the engine or motor of the vehicle is running). In some embodiments, at least one of object detector 426 or scene detector 428 is activated in response to vehicle control monitor 424 determining that a specific behavior (e.g., a triggering event) is detected.

[0060] The data designator 432 is configured to receive a determination that an executed request is satisfied or a triggering event has been detected. The data designator 432 is configured to analyze the received information to determine which sensor data should be collected from the sensor 414 based on the received data. For example, in some embodiments where an abnormal steering behavior of the driver is detected, the data designator 432 is configured to determine that image data from the front camera of the sensor 414 should be captured. In addition, the data designator 432 is configured to determine a time period during which data should be collected from the determined sensor based on the time of the detected situation. In some embodiments, the data designator 432 is configured to determine the sensor 414 from which data is to be collected based on instructions in a request received from a user.

[0061] In some embodiments, data designator 432 is configured to determine an area of ​​the received sensor data that is relevant to the detected condition. In some embodiments, the area of ​​the received sensor data is identified based on object recognition performed on the sensor data, for example, by object detector 426 or scene detector 428. In some embodiments, data designator 432 is configured to crop the received image from the sensor data, or if the sensor data is not an image, remove irrelevant data from the sensor data to reduce the amount of information in the abnormal condition log. In some embodiments, data designator 432 is configured to remove personal information, such as license plates, faces, etc., from the sensor data.

[0062] Log collector 434 is configured to receive data from data designator 432. In some embodiments, log collector 434 is configured to receive data directly from sensor 414, GPS 416, or situation detector 422 based on information provided by data designator 432. Log collector 434 is also configured to determine what information is useful for identifying the type and location of the object, such as location information from GPS 416 or map 418, image information from sensor 414, cropping or reduction information from data designator 432, timestamp information related to the time when the object or scene was detected, or other suitable information.

[0063] The log collector 434 generates log data based on the received related data (such as cropped images and position data). The log collector 434 also associates timestamp information with the log data to help synchronize the collected data and the queue priority within the server 440. In some embodiments, the log data generated by the log collector 434 also includes the world coordinates associated with the cropped image. In some embodiments, the log data generated by the log collector 434 also includes the map location associated with the cropped image. In some embodiments, the log collector 434 includes additional information that helps increase the accuracy of determining an object or scene.

[0064] Although the above description relates to generating log data based on images from sensor 414, it will be understood by those of ordinary skill in the art that log collector 434 is not limited to generating log data based on images. In some embodiments, 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 occupant wears smart glasses, log collector 434 is also configured to generate log data based on information received from the smart glasses.

[0065] 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 transmit the log data directly 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 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 or other 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 rate from the mobile device to the server 440 is higher than the transfer rate from the log transmitter 436 to the server 440. The log transmitter 436 is configured to, in response to determining that the data transfer rate from the mobile device to the server 440 is higher, transmit the log data to the mobile device for transmission to the server 440. The log transmitter 436 is configured to, in response to determining that the data transfer rate from the mobile device to the server 440 is not higher, transmit the log data directly from the vehicle system 410 to the server 440 without transmitting the log data to the mobile device.

[0066] In some embodiments, the detection vehicle system 410 also includes a memory configured to store sensor data from a sensor connected to the vehicle. In some embodiments, the memory is also configured to store information associated with a previously detected object or scene. In some embodiments, the data designator 432 is configured to provide a result based on the matched object or scene in response to detecting an object or scene that matches a previous object or scene. In some embodiments, the detection vehicle system 410 is also configured to determine whether the detection vehicle has received information related to an object or scene that matches an object or scene determined from the situation detector 422 from the server 440. In some embodiments, the detection vehicle system 410 is configured to prevent the transmission of log data to the server 440 in response to determining that the detection vehicle has received information related to a determined object or scene. Avoiding the transmission of redundant information to the server 440 helps to reduce the data transmitted to the server 440 and helps to minimize the power consumption of the detection vehicle system 410. In some embodiments, storing previous requests is referred to as caching. Those of ordinary skill in the art will understand caching as using hardware or software to store data so as to meet future requests for the data more quickly.

[0067] 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 also includes a log encoder 444 configured to encode the log data. The server 440 also includes a log transmitter 446 configured to transmit the encoded log data to the user terminal 460. The server 440 also includes a request / rule receiver 448 configured to receive a request or rule from the user terminal 460.

[0068] 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 attach a timestamp of the time when the log data is received to the log data.

[0069] 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 ensure that the user terminal 460 can reliably decode the log data for use by the user terminal 460. In some embodiments, the log encoder 444 is configured to perform log data compression, image encoding, thumbnail creation, or other suitable encoding protocols. In some embodiments, the log encoder 444 is configured to perform log data encryption. In some embodiments, the log encoder 444 is also configured to perform super-resolution to make it easier for users to see the data. Those of ordinary skill in the art will understand that super-resolution is the process of receiving a high-resolution image from a low-resolution image. Improving the resolution of the log data helps reduce false positives or false positives.

[0070] In some embodiments, the server 440 also includes a database for storing received log data. In some embodiments, the log data is stored in the database before and / or after being encoded 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 the time when the object or scene (e.g., triggering event) is detected, the time when the log data receiver 442 receives the log data, the type of the object or scene, the identity of the driver of the detection vehicle, or other suitable priority standards.

[0071] The log delivery device 446 is configured to receive the coded log data from the log encoder 444. The log delivery device 446 is configured to transmit the coded log data to the user terminal 460. In some embodiments, the log delivery device 446 is configured to transmit the coded log data to a mobile device accessible to the user. In some embodiments, the log delivery device 446 is configured to wirelessly transmit the coded log data. In some embodiments, the log delivery device 446 is configured to transmit the coded log data via a wired connection. In some embodiments, the log delivery device 446 is configured to transmit the coded log data together with the coded log data. The coded log data transmission protocol information helps the mobile device or the user terminal 460 to accurately decode the coded log data for use by the user terminal 460.

[0072] Request / rule receiver 448 is configured to receive new or updated rules or data requests from users. In some embodiments, request / rule receiver 448 is configured to receive new or updated rules or requests wirelessly. In some embodiments, request / rule receiver 448 is configured to receive new or updated rules or requests via a wired connection. In some embodiments, request / rule receiver 448 is configured to receive new or updated rules or requests from UI 110 ( Figure 1 ) receives new or updated rules or requests.

[0073] In some embodiments, server 440 is configured to receive location information from a plurality of vehicles. In some embodiments, server 440 is configured to receive navigation plans from a plurality of vehicles. In some embodiments, log deliverer 446 is configured to limit transmission of the encoded log data to only vehicles within a predetermined distance of a detected triggering event.

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

[0075] User terminal 460 is a user terminal accessible by a user associated with a satisfied request. In some embodiments, user terminal 460 includes a GUI. In some embodiments, user terminal 460 is configured to automatically generate an alarm in response to data received from server 440. In some embodiments, the alarm includes an audio or visual alarm.

[0076] Those skilled in the art will appreciate that modifications to the request retrieval system 400 are within the scope of the present disclosure. For example, in some embodiments, the detection vehicle system 410 can transmit the log data directly to the user terminal 460 via a network (such as a wireless network). In some embodiments, the mobile device of the occupant in the detection vehicle can transmit the log data directly to the user terminal 460, such as a wireless network.

[0077] By automatically identifying and disseminating information relevant to satisfying rules or requests detected within or around the vehicle, a user can improve the performance of applications or software executed using the vehicle's processing system (e.g., ECU 420). In some embodiments, a user can receive object information related to an event such as an accident.

[0078] Figure 5The present invention is an operational flow for mobile computing network query content capture according to at least some embodiments of the present disclosure. The operational flow provides a method for mobile computing network query content capture. In at least some embodiments, the method is performed by a mobile computing network, such as Figure 1 The vehicle 140 shown in Figure 4 In at least some embodiments, the method is performed by one or more processors of a mobile computing network that together comprise a portion for performing certain operations, such as Figure 4 ECU 420 shown in .

[0079] At 550, the receiving portion receives the content capture task and the retention policy. In at least some embodiments, the receiving portion receives the task and the retention policy executable by the mobile computing network from the server. In at least some embodiments, the server receives the content capture task and the retention policy via a communication network (such as Fig. 9 The server is a network 914) that communicates with the receiving portion, which will be explained below. In at least some embodiments, the server is Figure 1 Server 120 or Figure 4 In at least some embodiments, the task includes a program to capture target content. In at least some embodiments, the task is programmed to be performed by the mobile computing network using available resources of the mobile computing network. In at least some embodiments, the task includes instructions for detecting target content from at least one sensor. In at least some embodiments, the task is programmed to consume available resources and avoid interfering with other tasks being performed simultaneously.

[0080] At S552, the execution portion performs a task to capture the content. In at least some embodiments, the execution portion performs the task using the mobile computing network to capture the target content. In at least some embodiments, the execution portion instructs at least one sensor to detect the target content. In at least some embodiments, the execution portion instructs at least one sensor to record the target content to a volatile memory in response to detecting the target content. In at least some embodiments, the execution portion performs Figure 6 This is the operational flow shown in the figure, which will be explained below.

[0081] At S553, the allocating portion allocates the probability of reduction. In at least some embodiments, the allocating portion allocates the probability of reduction to the first instance of the captured target content based on the retention policy. In at least some embodiments, the allocating portion allocates the probability according to a priority value relative to another priority value of a task being executed simultaneously. In at least some embodiments, the retention policy includes a probability of clearing each instance of the captured target content, the probability of clearing being inversely related to the priority value. In at least some embodiments, the probability of clearing is a function of age and the priority value. In at least some embodiments, the allocating portion performs Figure 7The operating flow shown in , which will be explained below.

[0082] At S554, the mobile computing network determines whether storage is low. In at least some embodiments, the mobile computing network determines whether the amount of storage consumed exceeds a threshold level. In at least some embodiments, the mobile computing network determines whether the amount of storage remaining is less than a threshold level. In at least some embodiments, the mobile computing network also determines whether memory is low, and performs operations in response to each determination. If the mobile computing network determines that storage is not low, operational flow proceeds to a network connection determination at S556. If the mobile computing network determines that storage is low, operational flow proceeds to a stored data reduction at S555.

[0083] At S555, the reduction part reduces the stored data. In at least some embodiments, the reduction part reduces at least one of the first instance or a part of the other stored data based on the probability of reduction in response to the available storage amount becoming equal to or lower than the threshold amount. In at least some embodiments, the reduction part determines which content is used to reduce the consumed storage space based on the assigned probability of reduction. In at least some embodiments, the reduction part generates a random number to determine which content is used to reduce the consumed storage space according to the assigned probability of reduction. In at least some embodiments, the reduction part updates the probability of reduction assigned to the first instance based on the retention policy and the existence time of the first instance before determining which content is used to reduce the consumed storage space. In at least some embodiments, the reduction part clears the instance of the captured content in response to the available storage amount becoming equal to or lower than the threshold amount. In at least some embodiments, the reduction part uses the filtering subtask of the captured content to filter the first instance in response to the available storage amount becoming equal to or lower than the threshold amount. In at least some embodiments, the reduction part uses the compression subtask of the captured content to compress the first instance in response to the available storage amount becoming equal to or lower than the threshold amount.

[0084] At S556, the mobile computing network determines whether a network connection is available. In at least some embodiments, the mobile computing network determines whether the wireless communication transceiver detects an available access point. If the mobile computing network determines that a network connection is available, then the operational flow proceeds to the data transmission at S557. If the mobile computing network determines that a network connection is not available, then the operational flow proceeds to the termination condition determination at S558.

[0085] At S557, the transmission portion transmits data. In at least some embodiments, the transmission portion transmits each instance of the captured target content in response to connecting to the wide area network. In at least some embodiments, the transmission portion transmits the instance of the target content to the server in order of priority according to the content transmission policy. In at least some embodiments, the transmission portion performs Figure 8This is the operational flow shown in the figure, which will be explained below.

[0086] At S558, the mobile computing network determines whether the termination condition has been met. In at least some embodiments, the mobile computing network determines whether a sufficient amount of the target content has been captured and transmitted. If the mobile computing network determines that the termination condition has not been met, the operational flow returns to the task execution at S552. If the mobile computing network determines that the termination condition is met, the operational flow ends.

[0087] Figure 6 is an operational flow for performing a content capture task according to at least some embodiments of the present disclosure. The operational flow provides a method for performing a content capture task. In at least some embodiments, the method is performed by a mobile computing network, such as Figure 1 The vehicle 140 shown in Figure 4 In at least some embodiments, the method is performed by an execution portion of one or more processors of a mobile computing network that together include a portion for performing certain operations, such as Figure 4 ECU 420 shown in .

[0088] At S660, the execution portion detects resource usage. In at least some embodiments, the execution portion detects resource usage of each controller among the plurality of controllers. In at least some embodiments, the controller is included in a mobile computing network, such as Figure 4 ECU 420, also referred to as a processor, is shown in FIG. 4. In at least some embodiments, the execution portion detects resource usage based on the number of active threads. In at least some embodiments, the execution portion detects resource usage based on internal cache memory consumption.

[0089] At S662, the execution portion determines whether any controller is available. In at least some embodiments, the execution portion determines the available controllers based on resource usage. In at least some embodiments, the execution portion determines whether the resource usage of each controller among the plurality of controllers is less than a threshold amount. In at least some embodiments, the execution portion determines that the resource usage of the available controllers is less than a threshold amount. If the execution portion determines that no controller is available, the operation flow returns to the resource usage detection at S660. If the execution portion determines that at least one controller is available, the operation flow proceeds to the task execution at S664.

[0090] At S664, the execution portion executes the task. In at least some embodiments, the execution portion causes the available controller to execute the task in response to detecting that the resource usage of the available controller is less than a threshold amount. In at least some embodiments, the execution portion executes the task within a sandbox of limited computing resources. In at least some embodiments, the sandbox is a computing environment that is secure and isolated from the rest of the mobile computing network, such as a virtual machine or container running within the mobile computing network.

[0091] At S665, the execution portion captures an instance of the content. In at least some embodiments, the execution portion causes at least one sensor to record the target content to a volatile memory in response to detecting the target content. In at least some embodiments, the target content is a video recording of an environment. In at least some embodiments, the target content is a reading from a motor sensor during an extreme event. In at least some embodiments, the execution portion transfers the recorded content from the volatile memory to a storage.

[0092] At S667, the execution portion determines whether a priority task instruction has been received. In at least some embodiments, the execution portion determines whether, for example, Figure 1 The execution part determines that the task instruction with higher priority has been received. If the execution part determines that the task instruction with higher priority has been received, the operation flow proceeds to the task closing at S669. If the execution part determines that the task instruction with higher priority has not been received, the operation flow ends.

[0093] At S669, the execution section closes the task. In at least some embodiments, the execution section closes the task in response to receiving an instruction to execute a priority task. In at least some embodiments, the execution section closes the task in response to determining that a task has the lowest priority among the tasks currently executed by the controller.

[0094] Figure 7 is an operational flow for assigning a reduction probability according to at least some embodiments of the present disclosure. The operational flow provides a method for assigning a reduction probability. In at least some embodiments, the method is performed by a mobile computing network, such as Figure 1 The vehicle 140 shown in Figure 4 In at least some embodiments, the method is performed by a distributed portion of one or more processors of a mobile computing network that together include a portion for performing certain operations, such as Figure 4 ECU 420 shown in .

[0095] At S770, the allocation portion allocates a probability of purging. In at least some embodiments, the allocation portion allocates the probability of purging to the first instance of the captured target content based on a retention policy. In at least some embodiments, the probability of purging is negatively correlated with the priority value. In at least some embodiments, the probability of purging is a function of the age and the priority value. In at least some embodiments, the priority value is based on a retention policy, such as in Figure 5 The retention policy received at S550.

[0096] At S772, the allocation portion determines whether a filtering subtask exists. In at least some embodiments, the allocation portion receives from a server a filtering subtask programmed to filter instances of captured target content, the filtering subtask being programmed to be performed by the mobile computing network. If the allocation portion determines that a filtering subtask exists, the operation flow proceeds to a filtering probability allocation at S774. If the allocation portion determines that a filtering subtask does not exist, the operation flow proceeds to a compression subtask determination at S776.

[0097] At S774, the allocating portion allocates a probability of filtering. In at least some embodiments, the allocating portion allocates the probability of filtering to the first instance of the captured target content based on a retention policy. In at least some embodiments, the probability of filtering is greater than the probability of purging, so that data is saved while reducing storage consumption. In at least some embodiments, the allocating portion reduces the probability of purging in response to determining that a filtering subtask exists.

[0098] At S776, the allocation portion determines whether there is a compression subtask. In at least some embodiments, the allocation portion receives from the server a compression subtask programmed to compress an instance of the captured target content, the compression subtask being programmed to be performed by the mobile computing network. If the allocation portion determines that there is a compression subtask, the operation flow proceeds to the compression probability allocation at S778. If the allocation portion determines that there is no compression subtask, the operation flow ends.

[0099] At S778, the allocating portion allocates a probability of compression. In at least some embodiments, the allocating portion allocates the probability of compression to the first instance of the captured target content based on a retention policy. In at least some embodiments, the probability of compression is greater than the probability of purging, so that data is saved while reducing storage consumption. In at least some embodiments, the allocating portion reduces the probability of purging in response to determining that a compression subtask exists. In at least some embodiments, the allocating portion further reduces the probability of purging in response to determining that a compression subtask and a filtering subtask exist.

[0100] Figure 8is an operational flow for transmitting captured content according to at least some embodiments of the present disclosure. The operational flow provides a method for transmitting captured content. In at least some embodiments, the method is performed by a mobile computing network, such as Figure 1 The vehicle 140 shown in Figure 4 In at least some embodiments, the method is performed by a transmission portion of one or more processors of a mobile computing network that together include a portion for performing certain operations, such as Figure 4 ECU 420 shown in .

[0101] At S880, the transmission portion transmits metadata of the captured content. In at least some embodiments, the transmission portion transmits metadata of each instance of the captured target content in response to connecting to the wide area network. In at least some embodiments, the metadata provides a description or keywords that explain the corresponding instance of the captured target content.

[0102] At S882, the transmission portion receives a content transmission policy. In at least some embodiments, the transmission portion receives from the server a transmission policy defining a transmission priority value corresponding to a first instance of the captured target content in response to transmitting metadata of each instance of the captured target content. In at least some embodiments, the transmission priority value is based on a transmission priority function of the content transmission policy.

[0103] At S883, the transmission portion determines a priority value based on the content transmission policy. In at least some embodiments, the transmission portion reads a transmission priority value explicitly stated in the content transmission policy. In at least some embodiments, the transmission portion derives the transmission priority value from a transmission priority function of the transmission policy. In at least some embodiments, the transmission priority function is based on one or more of the size of the instance, the age of the instance, and the bandwidth of the connection to the server.

[0104] At S885, the transmission portion determines a bandwidth of the network connection. In at least some embodiments, the transmission portion determines the bandwidth of the connection to the server in response to connecting to the wide area network prior to transmitting the first instance. In at least some embodiments, the transmission portion determines the bandwidth prior to determining the priority value, such as where the transmission priority function depends on the bandwidth. In at least some embodiments, the transmission portion determines the bandwidth at regular intervals during transmission of the captured content, such as where the connection bandwidth is irregular, so that the priority value changes according to the transmission priority function.

[0105] At S887, the transmission portion transmits an instance of the captured content based on the priority value. In at least some embodiments, the transmission portion transmits the first instance of the captured target content among each instance of the captured target content in an order based on the transmission priority value. As the instance transmission operation at S887 is iterated, the transmission portion transmits each instance of the captured content to the server. In at least some embodiments, the transmission portion refers to the transmission priority value determined at S883 or re-determined in response to a change in bandwidth before transmitting each instance of the captured content.

[0106] At S889, the transmission portion determines whether all instances of the captured content have been transmitted. In at least some embodiments, the transmission portion determines whether all instances captured and retained in the memory have been transmitted. In at least some embodiments, the transmission portion determines whether all instances requested by the server have been transmitted. If the transmission portion determines that untransmitted instances of the captured content remain, the operational flow returns to the instance transmission operation at S887. If the transmission portion determines that all instances of the captured content have been transmitted, the operational flow ends.

[0107] Fig. 9 is a diagram of a system 900 for implementing a request retrieval system according to some embodiments. The system 900 includes a hardware processor 902 and a non-transitory computer-readable storage medium 904 encoding (i.e., storing) useful computer program code 906 (i.e., a set of execution instructions). The computer-readable storage medium 904 is also encoded with instructions 907 for interfacing with external devices. The processor 902 is electrically coupled to the computer-readable storage medium 904 via a bus 908. The processor 902 is also electrically coupled to an I / O interface 910 via the bus 908. A network interface 912 is also electrically connected to the processor 902 via the bus 908. The network interface 912 is connected to a network 914, so that the processor 902 and the computer-readable storage medium 904 can be connected to external elements via the network 914. The processor 902 is configured to execute the computer program code 906 encoded in the computer-readable storage medium 904 so that the system 900 can be used to perform operations such as in the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ) or some or all of the operations described in .

[0108] In some embodiments, the processor 902 is a central processing unit (CPU), a multi-processor, a distributed processing system, an application specific integrated circuit (ASIC) and / or a suitable processing unit.

[0109] In some embodiments, the computer-readable storage medium 904 is an electronic, magnetic, optical, electromagnetic, infrared and / or semiconductor system (or device or apparatus). For example, the computer-readable storage medium 904 includes semiconductor or solid-state memory, magnetic tape, removable computer floppy disk, random access memory (RAM), read-only memory (ROM), rigid disk and / or optical disk. In some embodiments using optical disks, the computer-readable storage medium 904 includes compact disk read only memory (CD-ROM), compact disk read / write (CD-R / W) and / or digital video disc (DVD).

[0110] In some embodiments, the storage medium 904 stores a configuration to cause the system 900 to perform the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ) in part or all of the operations described in the computer program code 906. In some embodiments, the storage medium 904 also stores a computer program code for executing the operations described in the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ) and information required for some or all of the operations described in the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ), such as priority level parameter 916, query ID parameter 918, query status parameter 920, query data parameter 922, and / or information generated during some or all of the operations described in the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ) is a set of executable instructions that implement some or all of the operations described in .

[0111] In some embodiments, storage medium 904 stores instructions 907 for interfacing with a manufacturing machine. Instructions 907 enable processor 902 to generate manufacturing instructions readable by a manufacturing machine to efficiently implement method 600 during a manufacturing process.

[0112] System 900 includes an I / O interface 910. I / O interface 910 is coupled to external circuitry. In some embodiments, I / O interface 910 includes a keyboard, keypad, mouse, trackball, trackpad, and / or cursor direction keys for communicating information and commands to processor 902.

[0113] The system 900 also includes a network interface 912 coupled to the processor 902. The network interface 912 allows the system 900 to communicate with a network 914 to which one or more other computer systems are connected. The network interface 912 includes a wireless network interface such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA; or a wired network interface such as ETHERNET, USB, or IEEE-1394. In some embodiments, such as in the ODDR system 100 ( Figure 1 )、ODDR System 400( Figure 4 ) or Method 600( Figure 6 ) are implemented in two or more systems 900, and information such as priority level, query ID, query status and query data are exchanged between different systems 900 via network 914.

[0114] In at least some embodiments, mobile computing network query content capture is performed by: receiving a task executable by the mobile computing network and a retention policy from a server, performing the task using the mobile computing network to capture target content, assigning a decreasing probability to a first instance of the captured target content based on the retention policy, responsive to an available storage amount becoming equal to or below a threshold amount, decreasing at least one of the first instance and a portion of other stored data based on the decreasing probability, and responsive to connecting to the wide area network, transmitting each instance of the captured target content.

[0115] The features of several embodiments are summarized above so that those skilled in the art can better understand the various aspects of the present disclosure. Those skilled in the art should understand that they can easily use the present disclosure as a basis for designing or modifying other processes and structures to achieve the same purpose and / or achieve the same advantages of the embodiments described herein. Those skilled in the art should also recognize that such equivalent structures do not depart from the spirit and scope of the present disclosure, and they can make various changes, substitutions and modifications to this article without departing from the spirit and scope of the present disclosure.

Claims

1. Methods, including: receiving from the server tasks executable by the mobile computing network and a reservation policy, performing the task to capture target content using the mobile computing network, assigning a reduced probability to a first instance of the captured target content based on the retention policy, In response to the amount of available storage becoming equal to or below a threshold amount, reducing at least one of the first instance or a portion of other stored data based on the decreased probability, In response to connecting to the wide area network, each instance of the captured target content is transmitted.

2. The method according to claim 1, wherein: The allocation includes: Based on the retention policy, a probability of cleanup is assigned to a first instance of the captured target content.

3. The method according to claim 2, wherein: The reductions include: In response to the amount of available storage becoming equal to or below a threshold amount, the first instance is cleared.

4. The method according to any one of claims 1 to 3, wherein: The allocation includes: Based on the retention policy, a probability of filtering is assigned to a first instance of the captured target content.

5. The method according to claim 4, further comprising: A filtering subtask programmed to filter the captured first instance of target content is received from the server, the filtering subtask being programmed to be executed by the mobile computing network.

6. The method according to claim 5, wherein: The reductions include: In response to the amount of available storage becoming equal to or below a threshold amount, the first instance is filtered using the filtering subtask.

7. The method according to any one of claims 1 to 6, wherein: The allocation includes: Based on the retention policy, a probability of compression is assigned to a first instance of the captured target content.

8. The method according to claim 7, further comprising: A compression subtask programmed to compress the first instance of the captured target content is received from the server, the compression subtask being programmed to be performed by the mobile computing network.

9. The method according to claim 8, wherein: The reductions include: In response to the amount of available storage becoming equal to or below a threshold amount, the first instance is compressed using the compression subtask.

10. The method according to any one of claims 1 to 9, wherein: The execution includes: The tasks are performed within a sandbox of limited computing resources.

11. The method according to any one of claims 1 to 10, wherein: The execution includes: In response to receiving an instruction to execute a priority task, the task is closed.

12. The method according to any one of claims 1 to 11, wherein: The execution includes: In response to detecting that resource usage of an available controller is less than a threshold amount, causing the available controller to perform the task.

13. The method according to any one of claims 1 to 12, wherein: The transmission includes: In response to connecting to the wide area network, metadata for each instance of the captured target content is transmitted.

14. The method according to claim 13, wherein: The transmission includes: In response to transmitting the metadata of each instance of the captured target content, a transmission policy defining a transmission priority value corresponding to a first instance of the captured target content is received from the server.

15. The method according to claim 14, wherein: The transmission includes: A first instance of the captured target content among each instance of the captured target content is transmitted in an order based on the transmission priority value.

16. The method according to claim 15, wherein: The transmission includes: In response to connecting to the wide area network prior to transmitting the first instance, a bandwidth of the connection to the server is determined.

17. The method according to any one of claims 14 to 16, wherein: The transmission includes: The transmission priority value is derived from a transmission priority function of the transmission policy.

18. The method according to claim 17, wherein The transmission priority function is based on one or more of a size of the first instance, an age of the first instance, and a bandwidth of a connection to the server.

19. A non-transitory computer readable medium comprising instructions executable by a processor to cause the processor to perform operations comprising: receiving from the server tasks executable by the mobile computing network and a reservation policy, performing the task to capture target content using the mobile computing network, assigning a reduced probability to a first instance of the captured target content based on the retention policy, In response to the amount of available storage becoming equal to or below a threshold amount, based on the decreased probability, reducing at least one of the first instance and a portion of the other stored data, In response to connecting to the wide area network, each instance of the captured target content is transmitted.

20. Equipment, including: A controller comprising circuitry configured to perform operations comprising: receiving from the server tasks executable by the mobile computing network and a reservation policy, performing the task to capture target content using the mobile computing network, assigning a reduced probability to a first instance of the captured target content based on the retention policy, In response to the amount of available storage becoming equal to or below a threshold amount, based on the decreased probability, reducing at least one of the first instance and a portion of the other stored data, In response to connecting to the wide area network, each instance of the captured target content is transmitted.

Images