Mobile Computing Network Programming for Queried Content Retrieval

Abstract

To provide mobile computing network programming.SOLUTION: Mobile computing network programming for queried content capture is performed by receiving, from a client device, a query for a target content of data capturable by a fleet of mobile computing networks, the query including a target content identifier that identifies the target content, programming a task to capture the target content, the task programmed to be executed by each mobile computing network using available resources of the mobile computing network, transmitting the task to each mobile computing network; and receiving data including the target content from each mobile computing network among the fleet of mobile computing networks.SELECTED DRAWING: Figure 1

Description

Background Art

[0001] Distributed databases typically execute queries (request searches, inquiries) by replicating the database and sending all queries to the replica rather than the original database. As connectivity between different products increases, software developers are exploring the development of new applications to allow users to customize their experiences across different products. To develop an application, software developers rely on the data structures within the product to develop an application that will work reliably on that product. In some cases, using an application programming interface (API) allows the application to exchange data with the product without having to specially adapt the application to the product. However, in some cases, understanding the types of data available within the product and the format of that data can help software developers enhance the application and improve the user experience of the product.

Summary of the Invention

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

Brief Description of the Drawings

[0003]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0004] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. To simplify the present disclosure, specific examples of components, values, operations, materials, arrangements, etc. are described below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are contemplated. For example, forming a first feature over or on a second feature in the following description may include embodiments in which the first and second features are formed in direct contact, and may also include embodiments in which additional features are formed between the first and second features so that the first and second features are not in direct contact. Further, the present disclosure may repeat reference numerals and / or letters in various examples. This repetition is for purposes of simplification and clarity and does not in itself define a relationship between the various embodiments and / or configurations being discussed.

[0005] Furthermore, as used herein, spatially relative terms such as "beneath", "below", "lower", "above", "upper", etc. may be used for ease of explanation to describe the relationship of one element or feature to another. Spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation shown in the drawings. The device may be in other orientations (rotated 90 degrees or otherwise), and the spatially relative descriptors used herein may be interpreted accordingly as well.

[0006] A group of vehicles as a distributed database needs to upload all data from each vehicle, and since its connection and bandwidth are unstable and expensive, replication is costly and time-consuming. When directly executing a query on a distributed database, care must be taken so that the system does not crash due to the query.

[0007] To help maintain the operating state of the distributed database, i.e., the operating state of each vehicle within the group, at least some embodiments of this specification screen queries for feasibility and adjust the queries according to different models within the group.

[0008] In at least some embodiments, adjusting a query for a model includes referring to a database of computing resources and executing a process on that model. In at least some embodiments, the process is created to be executed on a specific model, enabling the vehicles of that model to avoid resource shortages. In at least some embodiments, even models with a small amount of computing resources are programmed to execute more complex tasks and are notified to the query creator when the time taken for data collection is extremely long. In at least some embodiments, the query engine estimates when the result will be obtained based on the likelihood of encountering an event that generates the requested data, the bandwidth to the server, and the computing resources of the model.

[0009] In at least some embodiments, the vehicle is configured to execute a query to collect the requested data. In at least some embodiments, the vehicle is configured to store the requested data within the vehicle until one or more conditions for uploading the data are met. In at least some embodiments, the vehicle is configured to execute multiple queries and store multiple instances of the requested data until uploading. In at least some embodiments, the vehicle is configured to compress, filter, or purge (remove) the requested data according to the corresponding priority value established by the server according to the available storage resources. At least some embodiments of this specification enable direct execution of queries on the distributed database and notifying those queries of the possibility of receiving results and the latency.

[0010] Users such as software developers, insurance companies, market researchers, and law enforcement officers can use an on-demand data retrieval (ODDR) system to enter data requests into a user interface such as a graphical user interface (GUI). A software developer is, for example, a software developer who develops applications, middleware, an operating system (OS), etc. that operate on a vehicle. Examples of applications include applications for an autonomous driving system such as an object recognition application, a road recognition application, a sensor fusion application, a position estimation application, a path planner application, and a controller application. The data request is analyzed, stored in a server, and sent by the server to the vehicle. On the server side, the data request is stored in a storage unit, and a request queue is generated based on the stored request. The user can check or request an update of the status of the data request. For example, the status may be displayed as "pending" even though the data request is still in the server before being sent to the vehicle. When the server sends the data request to the vehicle, the status may be updated to "sent". This enables the user to check and track the status of data requests made to the vehicle. Those skilled in the art will recognize that, for the sake of clarity, reference is being made to one vehicle. However, this description applies not only to one vehicle but also to a group of vehicles.

[0011] The user interface for generating a data request includes forms related to vehicle identification information, the type of data requested, start time, and end time. In some embodiments, the start time and end time are absolute times, such as Unix (registered trademark) time, which is the elapsed time from the Unix (registered trademark) epoch time. In some embodiments, the start time and end time are relative times with respect to the time when the data request is received by the vehicle. In some embodiments, the start time and end time are relative times with respect to a trigger event. The trigger event is an event in the environment inside or around the vehicle where the user is requesting data or requesting the reception of a data request by the vehicle. For example, trigger events due to the environment around the vehicle include hard acceleration, hard braking, capture of an image of the target of the data request, detection of the target of the data request, or other appropriate events. The user information for monitoring the status of the data request includes the identification information of the data request and the status of the data request, such as pending or sent.

[0012] In some embodiments, when a data request is received by the vehicle, the data request is processed to be a data request that is independent of the source of the data request. In some embodiments, a data request identifier (ID) is assigned to the received data request by the vehicle, for example, by a request abstractor within the vehicle. In some embodiments, the data request ID is assigned to the data request before the data request is sent to the vehicle. In some embodiments, the data request is generated by an application running within the vehicle, and the application assigns the data request ID. In other words, regardless of the program or system that sends the data request to the vehicle, the data is processed in a consistent manner. In some embodiments, the data request is generated by a software component stored within the vehicle, and the data is processed in accordance with the data request received from an external device. This helps to share the same data collection software component between trigger data collection where an application generates a data collection request to a logger and ODDR-based external data collection requests.

[0013] In some embodiments, when a data request is received by a vehicle, it is processed so as not to depend on sensors and servers within the vehicle. In some embodiments, the data request is generated by an application running within the vehicle. In some embodiments, an application programming interface (API) can be used to make a data request that does not depend on information from sensors or servers within the vehicle from an application. Thereby, the user's data collection ability can be maximally enhanced without programming requests for a specific sensor model. Thereafter, the data request is transferred to a data collector, and the requested data is collected in response to the occurrence of a trigger event. In a situation where a trigger event such as a traffic accident has already occurred, the data request is satisfied based on the data stored in the storage device within the vehicle. The time frame of the collected data, i.e., the start time and the end time, is determined based on the data request. The collected data is transferred to a server.

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

[0015] In some cases, a budget management system or a payment system is implemented on the server side or the vehicle side, and the user is billed for the data request. The fee is paid at the time of sending the request or at the completion of data collection. The fee can be adjusted based on the type and amount of data requested. In some embodiments, when the total amount of the fee billed to the user reaches the maximum threshold of the user's budget, data requests from the user are rejected.

[0016] With this ODDR system, users can access information collected for each vehicle in an on-demand style. That is, the data does not necessarily have to be continuously collected and may be collected to meet specific user requirements. In some embodiments, the ODDR system assists users such as software developers in collecting data for updating software design, implementation, and parameter adjustment in an exploratory manner based on the collected data. As a result, the user can continuously improve the software, for example, by providing an update from the server to the vehicle via the network as an over-the-air (OTA) update. In some embodiments, the ODDR system helps machine learning developers who develop machine learning models for data collection applications to train the models using data that was not available when the models were first developed so that the models can be continuously updated to correct weaknesses and problems in the models. In some cases, an insurance company may be able to collect data related to traffic accidents. In some cases, a law enforcement agency may be able to collect information related to crimes and traffic accidents.

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

[0018] UI110 is configured to receive input commands from a user. In some embodiments, the user includes software developers. In some embodiments, the user includes developers of machine learning models. In some embodiments, the user includes insurance companies. In some embodiments, the user includes law enforcement officers. In some embodiments, the user includes market research companies. UI110 provides the user with options for selecting which types of vehicles and which types of data are requested. In some embodiments, UI110 can generate a data request using a form related to vehicle identification information, the type of data requested, start time, and end time. In some embodiments, the start time and end time are absolute times such as Unix (registered trademark) time, which is the elapsed time from the Unix (registered trademark) epoch time. In some embodiments, the start time and end time are relative times with respect to the time when the data request is received by the vehicle. In some embodiments, the start time and end time are relative times with respect to a trigger event. In some embodiments, UI110 also provides the user with options for selecting a trigger event and a data collection period related to the trigger event. In some embodiments, UI110 includes information related to the type of vehicle for which data is requested. In some embodiments, UI110 includes a vehicle ID that can uniquely identify a vehicle as the target of a request. For example, the vehicle ID includes the UUID (Universally Unique Identifier) format. In some embodiments, UI110 includes a data type that can identify the source of the data that the user wants to collect. For example, the data type includes a sensor ID of a sensor from which sensor data is collected, and an application ID of an application from which application logs are collected. In some embodiments, the formats of the sensor ID and the application ID include the Universal Unique Identifier (UUID) format. In some embodiments, UI110 includes a drop-down menu. In some embodiments, UI110 includes editable fields for receiving information related to the data request.In some embodiments, UI110 provides information regarding what types of data options are available to the user. In some embodiments, the types of data options available depend on the user. For example, in some embodiments, a law enforcement agency can select more data options than an insurance company.

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

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

[0021] Server 120 includes a communication unit 130 configured to communicate with UI 110 and vehicle 140. The communication unit 130 includes a receiver 131 configured to receive data requests from UI 110. In some embodiments, the receiver 131 includes a wireless receiver. In some embodiments, the receiver is configured to receive data requests via a wired connection. In some embodiments, the receiver 131 is further configured to perform initial processing on the received data requests. In some embodiments, the received data requests include priority level information. In some embodiments, the receiver 131 is configured to assign a priority level to the data requests based on the identity of the user who submitted the data requests, or the fees paid by the user who submitted the data requests. 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 specific sensors within the vehicle 140 based on the identity of the user. For example, in some embodiments, third-party users may not be able to access sensors related to the safety functions of the vehicle 140.

[0022] The communication unit 130 further includes a memory unit 132 configured to store data requests received by the receiver 131. In some embodiments, the memory unit 132 includes a random access memory, a semiconductor memory, or another type of memory. In some embodiments, the memory unit 132 is configured to store the data request together with the status of the data request. In some embodiments, the status of the data request includes pending (before sending the data request to the vehicle 140), after transmission (following the sending of the data request to the vehicle 140), and completed (after receiving the data requested from the vehicle 140). In some embodiments, the memory unit 132 is accessible by the user. In some embodiments, the update of the information in the memory unit 132 triggers a notification to the user related to the information updated in the memory unit 132. In some embodiments, the memory unit 132 stores the data request together 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 agencies have a higher priority than insurance companies, and insurance companies have a higher priority than ordinary users such as software developers. In some embodiments, the priority level is determined based on the fees paid by the user. For example, in some embodiments, the user can pay a fee to increase the priority level of the request in order to obtain the requested data earlier. In some embodiments, the priority level of the data request increases as the time between the initial storage of the data request and the sending of the data request to the vehicle increases.

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

[0024] The communication unit 130 further includes a query queue 134 configured to store data requests in order of priority for transmission to the vehicle 140. In some embodiments, the query queue 134 is integrated with the memory unit 132. In some embodiments, the query queue 134 is separated from the memory unit 132. In some embodiments, the query queue 134 is configured to read data requests from the memory unit 132 based on the priority level and timestamp information. In some embodiments, the query queue 134 is configured to order the data requests based on the priority level and, in response to data requests having the same priority level, by the time since first stored in the memory unit 132.

[0025] The communication unit 130 further includes a transmitter 135 configured to send data requests to the vehicle 140 from the query queue 134. The transmitter 135 is configured to send data requests to the vehicle 140 based on the order of the data requests in the query queue 134. In some embodiments, the data requests are wirelessly sent to the vehicle 140. In some embodiments, the data requests are sent to the vehicle 140 by a wired connection. The data requests sent to the vehicle 140 include trigger event information, data duration information regarding how much time before and after the trigger event data should be collected, and sensor information indicating the types of sensors of the vehicle 140 for which data should be collected. In some embodiments, the data requests sent to the vehicle 140 include priority level information. In some embodiments, when the vehicle 140 sends a request to the server 120 for the server 120 to send a data request to the vehicle 140, the transmitter 135 is configured to send the data request to the vehicle 140. In some embodiments, the transmitter 135 is configured to send data requests to the vehicle 140 whenever the communication unit 130 has sufficient connectivity to the vehicle 140, unless the communication unit 130 has received information indicating that the vehicle 140 cannot accept new data requests. In some embodiments, the transmitter 135 is configured to periodically send data requests to the vehicle 140 as long as the vehicle 140 can receive new data requests and the transmitter 135 has sufficient connectivity to the vehicle 140. In some embodiments, the transmitter 135 is configured to send data requests to the vehicle 140 in batches, such as groups of 5 data requests, 20 data requests, or other numbers of data requests. In some embodiments, the transmitter 135 is configured to request a receipt confirmation of the data requests from the vehicle 140. In response to failing to receive a receipt confirmation from the vehicle within a predetermined period, the transmitter 135 is configured to re-send the data requests. In some embodiments, the status of the data requests stored in the memory unit 132 is updated to indicate submission to the vehicle 140 in response to the communication unit 130 receiving a receipt confirmation of the data requests from the vehicle 140.

[0026] The communication unit 130 further includes a receiver 136 configured to receive a notification of the occurrence of a trigger event from the vehicle 140. In some embodiments, the occurrence of the trigger event is the receipt of a data request. In some embodiments, the receiver 136 is configured to receive the notification of the trigger event wirelessly. In some embodiments, the receiver 136 is configured to receive the notification of the trigger 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 trigger event.

[0027] The communication unit 130 further includes a receiver 137 configured to receive data from the vehicle 140 in response to a data request sent by the transmitter 135. In some embodiments, the data is split by the vehicle 140 into data packets that are units of transmission 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 associated with the receipt of the requested data. In some embodiments, the data responding to a single data request is received from the vehicle 140 in a single packet. In some embodiments, the data responding to a single data request is received from the vehicle 140 in multiple packets. The receiver 137 transfers the received data to the preprocessor 122.

[0028] Server 120 further includes a pre-processor 122 configured to receive data from receiver 137 and perform pre-processing on the data to generate collected data. In some embodiments, the pre-processing includes reconstructing data from multiple packets to compile the data in response to a data request. In some embodiments, the pre-processing includes de-serializing the data to compile structured data from the received byte array. In some embodiments, the pre-processing includes decompressing the data if the data has been compressed by vehicle 140 prior to transmission. In some embodiments, the pre-processing includes error correction by error correction codes (ECC) such as Reed-Solomon (RS) codes, Bose-Chaudhuri-Hocquenghem (BCH) codes, and Low-Density Parity-Check (LDPC) codes. In some embodiments, the pre-processing includes smoothing the data by removing outliers to reduce the risk of reporting inaccurate data to the user. In some embodiments, the pre-processing includes associating data request ID information, priority level information, or other appropriate information with the data received from receiver 137. In some embodiments, the data is pre-processed such that the information is provided to the user in an easily understandable format and is independent of specialized knowledge or equipment for identifying the information.

[0029] Server 120 further includes a data storage 126 configured to store the collected data generated by the data preprocessor 122. In some embodiments, the data storage 126 is integrated with the memory unit 132. In some embodiments, the data storage 126 is separated from the data storage 126. In some embodiments, the data storage 126 includes a solid state drive (SSD), random access memory, or another suitable memory. In some embodiments, the data storage 126 is accessible by a user, for example, using the UI 110 or the accessible console 150. In some embodiments, the data storage 126 is configured to notify the user in response to data related to a data request. In some embodiments, the notification includes an alert to the user. In some embodiments, the alert includes an audible or visual alert. In some embodiments, the data storage 126 is configured to automatically cause the UI 110 or the accessible console 150 to display a notification of the availability of the collected data. 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 data within the data storage 126 is searchable by a user via the accessible console 150. In some embodiments, the collected data is visualized within the console 150.

[0030] The request search system 100 further includes a vehicle 140. The vehicle 140 includes sensors that detect both the internal state of the vehicle 140 and the external environment surrounding the vehicle 140. In some embodiments, the sensors include cameras, LiDAR sensors, RADAR sensors, SONAR sensors, accelerometers, steering wheel position, speedometers, or other suitable sensors. The vehicle 140 can receive data requests via a wireless or wired connection.

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

[0032] In some embodiments, the memory and processor of vehicle 140 are configured to store and execute software applications in an electronic control unit (ECU) within vehicle 140. In some embodiments, data requests are generated by software applications stored in the ECU. In some embodiments, data requests are in response to trigger events such as sudden acceleration, sudden braking, obtaining sensor data including a specific object or specific scenery predefined within the software application, a "crash" of the software application, an anomaly detected within the software application, or another suitable detected occurrence. In some embodiments, vehicle 140 is configured to generate a notification to a maintainer of the software application, such as a user, in response to the detection of a trigger event associated with the software application. In some embodiments, the notification is sent directly to the user via a wireless or wired connection, such as through UI110. In some embodiments, the notification is sent to the user via server 120 via a wireless or wired connection. In some embodiments, the notification includes an audio or visual notification. In some embodiments, the notification is configured to automatically display the notification on UI110 without user intervention.

[0033] The claim search system 100 further includes an accessible console 150. The accessible console 150 enables a user to access the collected data stored in the data storage 126. In some embodiments, the accessible console 150 is integrated with the UI 110. In some embodiments, the accessible console 150 is separated from the UI 110. In some embodiments, the accessible console 150 includes a separate server that is separated from the server 120. In some embodiments, the accessible console 150 automatically receives the collected data related to the data request from the user in response to receiving the collected data by the data storage 126. In some embodiments, the accessible console 150 enables the user to search the data storage 126 and 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.

[0034] By using the claim search system 100, a user can obtain information from one or more vehicles 140 in an understandable format without relying on a dedicated device to request or read the received data. The function of prioritizing data requests in the claim search system 100 helps to ensure that law enforcement agencies or other users can obtain the data, while also enabling the user to pay a fee to obtain the data more quickly. This flexibility helps to improve the usefulness of the claim search system 100 for a wide range of users.

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

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

[0037] The GUI250 is configured to be displayed to the user after the user selects the submission button 230 on the GUI200. In some embodiments, the GUI250 can be used as the GUI110 of the ODDR system 100 (Figure 1). The GUI250 includes information indicating that a data request has been received. The GUI250 includes a query ID label 260 and a query ID field 270. The information for input into the query ID field 270 is received from a server, such as server 120 (Figure 1), after the server receives and stores the data request. In some embodiments, the GUI250 includes vehicle ID information. In some embodiments, the GUI250 includes information related to the priority level of the data request. In some embodiments, the GUI250 includes information related to the status of the data request, such as pending, submitted, completed, etc. In some embodiments, the GUI250 includes information related to the estimated time until the data request is submitted to a vehicle, such as vehicle 140 (Figure 1). In at least some embodiments, the GUI250 includes information related to the estimated time until the requested data is received. In at least some embodiments, the GUI250 includes information related to the estimated energy consumption for receiving the requested data. In some embodiments, the GUI250 is automatically displayed in response to receiving query ID information from the server. In some embodiments, the GUI250 is displayed in response to a user submitting a request for an update to an uploaded data request.

[0038] Figure 3 is a diagram of a data structure 300 of a request search command 310 according to some embodiments. In some embodiments, the acquisition request command 310 is transmitted from the server 120 to the vehicle 140 (Figure 1). The request search command 310 includes information related to the type of data requested by a data request to a vehicle, such as vehicle 140 (Figure 1).

[0039] The request search command 310 includes a transfer priority parameter 311 indicating the priority level of the data request. The request search command 310 further includes a log level parameter 312 indicating what type of data should be retrieved if there is data from other applications on the vehicle. For example, in some embodiments, the request search 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 error level or critical level. In some embodiments, the log level parameter 312 is omitted from the request search command 310 or remains null. The request search command 310 further includes a collection time range parameter 313 indicating the period before and / or after the trigger event for collecting data. The time range corresponds to the start time and end time entered by the user in the GUI 200 (Figure 2). The request search command 310 further includes a uniform resource locator (URL) endpoint parameter 314 indicating the destination of the data collected in response to the data request. The request search command 310 further includes a frequency parameter 315 indicating how often data should be sampled if it is necessary to sample data from the time range 313. For example, if the event time is t = 100 seconds, the time range is start time = -1 second, end time = 2 seconds, and the frequency is 10 Hz (100 millisecond period), the request search command collects data at t = 99.0 seconds, 99.1 seconds, 99.2 seconds, …, 101.9 seconds, 102.0 seconds. The request search command 310 further includes a log ID parameter 316 indicating the types of sensors and / or applications available for collecting the data requested by the data request. In some embodiments, a unique ID (such as a universal unique identifier (UUID)) is pre-assigned to all sensors and applications, and the unique ID for which the user wants to collect data is specified by the log ID parameter 316. The request search command 310 further includes a requester ID parameter 317 indicating the identity of the user who made the data request.The request search command 310 further includes an event ID parameter 318 indicating a trigger event associated with the data request. The request search command 310 further includes a budget ID parameter 319 indicating how much resources of a vehicle, for example, vehicle 140 (FIG. 1), should be allocated to satisfy the data request. Those skilled in the art will understand that additional parameters are possible in the request search command 310. For example, in some embodiments, the request search command 310 includes a vehicle position parameter indicating a geographical area where the trigger event may occur. Those skilled in the art will also understand that the request search command 310 does not necessarily include all of the parameters of FIG. 3. For example, in some embodiments, the budget ID parameter 319 is omitted.

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

[0041] The request search system 400 includes a detection vehicle system 410 configured to obtain information about a vehicle or the surroundings of the vehicle. The detection vehicle system 110 obtains information about the vehicle and the surroundings and transmits the information to the server. The request search system 400 further includes a server 440 configured to receive the information, encode the information, and distribute the information to the user terminal 460.

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

[0043] In some embodiments, the ECU 420 further includes a position estimation unit configured to receive data from the GPS 416 and the map 418 and determine the position, attitude, and state of the vehicle relative to the detected objects and / or known objects and / or the positions of the roads. 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 refer to the speed and orientation of the vehicle. In some embodiments, the attitude and state of the vehicle also refer to the velocity vector, acceleration vector, and jerk vector of the vehicle. In some embodiments, the position vector, velocity vector, acceleration vector, and jerk vector include angular vectors. In some embodiments, the state of the vehicle also refers to whether the engine or motor of the vehicle is operating.

[0044] The sensor 414 is configured to acquire information such as an image of the environment around the vehicle. In some embodiments, the sensor 414 includes a visible light camera, an IR camera. In some embodiments, the sensor 414 can be replaced by or further accompanied by a LiDAR sensor, a RADAR sensor, a SONAR sensor, or other suitable sensors. In some embodiments, the sensor 414 includes additional cameras disposed at other positions on the vehicle. For example, in some embodiments, additional cameras are disposed on both sides of the vehicle to detect most of the environment on the left and right sides of the observed vehicle. Since the occupants of the vehicle can look out through the side windows of the vehicle, using additional cameras to detect most of the environment around the vehicle improves the detection accuracy of the objects and scenery around the vehicle. For example, in some embodiments, additional cameras are disposed on the rear side of the vehicle to detect most of the environment behind the vehicle. This information helps to acquire information about the objects. In some embodiments, the data from the sensor 414 includes a time stamp or other metadata to help synchronize the data from the sensor 414 with the data from other components.

[0045] The GPS 416 is configured to determine the position of a vehicle. Knowing the position of the observed vehicle helps to associate an object or a landscape with a determined position on the map 418.

[0046] The map 418 includes information about roads and known objects along the roads. In some embodiments, the map 418 can be used in conjunction with the GPS 416 to determine the position and orientation of the vehicle. In some embodiments, the map 418 is received from an external device such as the server 440. In some embodiments, the map 418 is periodically updated based on information from the sensor 414 and / or the GPS 416. In some embodiments, the map 418 is periodically updated based on information received from an external device. In some embodiments, the map 418 is generated from sensor data by a Simultaneous Localization and Mapping (SLAM) algorithm. Including the map 418 helps to determine whether an object is a known object. Including a map 118 with known objects helps to improve the accuracy of new object detection.

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

[0048] 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, jerk, braking, steering, pitching, rolling, yawing, the flashing of hazard lights, the beeping of a horn, or other appropriate information. The vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates fulfillment of criteria for meeting a requirement, e.g., whether a trigger event has been detected.

[0049] The object detector 426 is configured to receive sensor data from the sensor 414 and determine whether there are abnormal objects on the road. In some embodiments, the object detector 426 is further configured to determine whether there are objects along 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 using, for example, a trained neural network to identify abnormal 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 the identified objects. In some embodiments, the object detector 426 is configured to identify objects such as tires, automobile parts, animals, holes in the road (potholes), traffic control signs, emergency vehicles, vehicles with hazard lights activated, or other appropriate objects as objects.

[0050] The scene detector 428 is configured to receive sensor data from the sensor 414 and determine whether a landscape satisfying the conditions for meeting the requirements is located in the environment around the vehicle. In some embodiments, the scene detector 428 is configured to determine that a vehicle accident has occurred in response to detecting that two or more vehicles are in contact with each other or that the vehicle is surrounded by a plurality of falling objects. In some embodiments, the scene detector 428 is configured to determine that construction work is being performed based on the detection of a plurality of adjacent construction vehicles. In some embodiments, the scene detector 428 is configured to determine that the vehicle is parked on the road shoulder based on the determination that the vehicle is located adjacent to the lane 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 by a trained neural network, to determine the content of the landscape around the vehicle.

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

[0052] The data identifier 432 is configured to receive a determination that the fulfillment of a request has been executed or that a trigger event has been detected. The data identifier 432 is configured to analyze the received information and determine, based on the received data, what sensor data from the sensor 414 to collect. For example, in some embodiments where an abnormal steering behavior by the driver is detected, the data identifier 432 is configured to determine to obtain image data from the front camera of the sensor 414. Further, the data identifier 432 is configured to determine the period for which data from the sensors determined based on the time of the detected situation needs to be collected. In some embodiments, the data identifier 432 is configured to determine the sensor 414 that collects data based on the instructions within the request received from the user.

[0053] In some embodiments, the data identifier 432 is configured to determine the area of the received sensor data related to the detected situation. In some embodiments, the area of the received sensor data is identified in the sensor data based on, for example, object recognition performed by the object detector 426 or the scene detector 428. In some embodiments, if the sensor data is not an image for reducing the amount of information in the log of the abnormal situation, the data identifier 432 crops the image received from the sensor data or removes heterogeneous data from the sensor data. In some embodiments, the data identifier 432 is configured to remove personal information such as license plates and human faces from the sensor data.

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

[0055] The log collector 434 generates log data based on the received and correlated data, such as trimmed images and position data. The log collector 434 assists in synchronizing the collected data and associates timestamp information with the log data for the priority of the queue in the server 440. In some embodiments, the log collector 434 further generates log data to include world coordinates associated with the trimmed image. In some embodiments, the log collector 434 generates log data to further include the position on the map associated with the trimmed image. In some embodiments, the log collector 434 includes additional information to assist in improving the accuracy of determining an object or scene.

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

[0057] The log transmitter 436 is configured to receive log data from the log collector 434 and transmit the log data to the server 440. In some embodiments, the log transmitter 436 is configured to transmit the log data wirelessly. In some embodiments, the log transmitter 436 is configured to transmit the log data via a wired connection. In some embodiments, the log transmitter 436 is configured to directly transmit the log data to the user terminal 460. In some embodiments, the log transmitter 436 is configured to transmit the log data to a mobile device accessible by the user, and the mobile device is configured to transmit the log data to the server 440. In some embodiments, the log transmitter 436 is configured to use Bluetooth (registered trademark) or 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 speed from the mobile device to the server 440 is higher than the transfer speed from the log transmitter 436 to the server 440. In response to a determination that the data transfer speed from the mobile device to the server 440 is higher, the log transmitter 436 is configured to transmit the log data to the mobile device for transmission to the server 440. In response to a determination that the data transfer rate from the mobile device to the server 440 is not higher, the log transmitter 436 is configured to directly transmit the log data from the vehicle system 410 to the server 440 without transferring the log data to the mobile device.

[0058] In some embodiments, the detection vehicle system 410 further includes a memory configured to store sensor data from sensors attached to the vehicle. In some embodiments, the memory is further configured to store information related to previously detected objects or landscapes. In some embodiments, in response to detecting an object or landscape that matches a previous object or landscape, the data identifier 432 is configured to provide a result based on the matching object or landscape. In some embodiments, the detection vehicle system 410 is further configured to determine whether the detection vehicle has received from the server 440 information related to an object or landscape that matches the determined object or landscape from the situation detector 422. In some embodiments, in response to determining that the detection vehicle has already received information related to the determined object or landscape, the detection vehicle system 410 is configured to prevent the transmission of log data to the server 440. Avoiding the transmission of redundant information to the server 440 helps reduce the data transmitted to the server 440 and helps minimize the power consumption by the detection vehicle system 410. In one embodiment, the saving of previous requests is referred to as caching. One of ordinary skill in the art will understand that caching is the use of hardware or software to store data so that future requests for that data can be processed more quickly.

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

[0060] 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 by the log data receiver 442 to the log data.

[0061] 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 compression of the log data, image encoding, thumbnail image creation, or other suitable encoding protocols. In some embodiments, the log encoder 444 is configured to perform encryption of the log data. In some embodiments, the log encoder 444 is further configured to perform super-resolution to make the data more legible to the user. One 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 negatives.

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

[0063] Log transfer device 446 is configured to receive the encoded log data from log encoder 444. Log transfer device 446 is configured to transmit the encoded log data to user terminal 460. In some embodiments, log transfer device 446 is configured to transmit the encoded log data to a mobile device accessible by the user. In some embodiments, log transfer device 446 is configured to wirelessly transfer the encoded log data. In some embodiments, log transfer device 446 is configured to transfer the encoded log data via a wired connection. In some embodiments, log transfer device 446 is configured to transmit the encoded protocol information together with the encoded log data. Transmitting the encoded protocol information of the encoded log data helps the mobile device or user terminal 460 to accurately decode the encoded log data for use by user terminal 460.

[0064] The request / rule receiver 448 is configured to receive requests for new or updated rules or data from a user. In some embodiments, the request / rule receiver 448 is configured to receive new or updated rules or requests wirelessly. In some embodiments, the request / rule receiver 448 is configured to receive new or updated rules or requests via a wired connection. In some embodiments, there is a request / rule receiver 448 from the UI 110 (FIG. 1).

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

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

[0067] The user terminal 460 is a user terminal accessible by a user associated with a fulfilled request. In some embodiments, the user terminal 460 includes a GUI. In some embodiments, the user terminal 460 is configured to automatically generate an alert in response to received data from the server 440. In some embodiments, the alert includes an audible or visual alert.

[0068] One skilled in the art will understand that changes to the claim search system 400 are within the scope of this disclosure. For example, in some embodiments, the detection vehicle system 410 can directly transmit log data to the user terminal 460 via a network such as a wireless network. In some embodiments, the mobile device of the passenger in the detected vehicle can directly transmit log data to the user terminal 460 via a network such as a wireless network.

[0069] By automatically identifying and transmitting information related to the fulfillment of rules or requirements detected in the environment inside or around the vehicle, the user can improve the performance of applications or software executed using the vehicle's processing system, such as the ECU 420. In some embodiments, the user can objectify information related to events such as accidents.

[0070] FIG. 5 is an operation flow for querying and obtaining mobile computing network content according to at least some embodiments of the present disclosure. The operation flow provides a method for querying and obtaining mobile computing network content. In at least some embodiments, the method is executed by a server such as the server 120 shown in FIG. 1 or the server 440 shown in FIG. 4. In at least some embodiments, the method is executed by a processor of a server that includes a section for performing specific operations, such as the processor 1002 shown in FIG. 10, which will be described below.

[0071] In S550, the query receiving unit of the processor receives a query. In at least some embodiments, the query receiving unit receives, from a client device, a query for target content of data obtainable by a group of mobile computing networks, and the query includes a target content identifier that identifies the target content. In at least some embodiments, the client device is an accessible console such as the accessible console 150 of FIG. 1, or a user terminal such as the user terminal 460 of FIG. 4. In at least some embodiments, the query receiving unit executes the operation flow shown in FIG. 6 described below.

[0072] In S552, the programming unit of the processor programs a task for a vehicle model within a group of mobile computing networks. In at least some embodiments, the programming unit programs a task to obtain target content, and the task is programmed to be executed by each mobile computing network using available resources of the mobile computing network. In at least some embodiments, the programming unit refers to a database of vehicle models to determine the total resources of the model and the currently executed tasks. In at least some embodiments, the programming unit programs the task to include instructions for detecting target content from at least one sensor. In at least some embodiments, the programming unit programs the task to consume available resources and avoid interference with other simultaneously executed tasks. In at least some embodiments, the programming unit executes the operation flow shown in FIG. 7 described below.

[0073] In S553, the processor determines whether tasks are programmed for all models. In at least some embodiments, the processor refers to a database of vehicle models to determine whether all models are programmed. In at least some embodiments, the mobile computing network group includes only one vehicle model. If the processor determines that there are remaining models for which tasks are not programmed, the operation flow returns to programming the model tasks in S552 to program tasks for other vehicle models. If the processor determines that tasks are programmed for all models, the operation flow proceeds to task transmission in S555.

[0074] In S555, the transmission unit of the processor transmits tasks to the vehicle. In at least some embodiments, the transmission unit transmits content search tasks and subtasks to the vehicle. In at least some embodiments, as the iteration of the operation in S555 progresses, the transmission unit transmits tasks to each mobile computing network. In at least some embodiments, the transmission unit executes the operation flow shown in FIG. 8 described below.

[0075] In S556, the processor determines whether tasks have been transmitted to all vehicles. In at least some embodiments, the processor refers to a database of vehicles within the mobile computing network group to determine whether tasks have been transmitted to all vehicles. If the processor determines that there are remaining vehicles to which tasks have not been transmitted, the operation flow returns to task transmission in S555 to transmit tasks to other vehicles. If the processor determines that tasks have been transmitted to all vehicles, the operation flow proceeds to data reception in S558.

[0076] In S558, the data receiving unit of the processor receives the queried content data. In at least some embodiments, the data receiving unit receives data including target content from each mobile computing network in a group of mobile computing networks. In at least some embodiments, the data receiving unit receives instances of target content from a vehicle in a rank according to the priority according to a content transmission policy. In at least some embodiments, the data receiving unit executes the operation flow shown in FIG. 9 described below.

[0077] FIG. 6 is an operation flow for receiving a content query according to at least some embodiments of the present disclosure. The operation flow provides a method for receiving a content query. In at least some embodiments, the method is executed by a server such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is executed by a query receiving unit of a processor of a server such as processor 1002 shown in FIG. 10, which will be described later.

[0078] In S660, the query receiving unit receives an initial query. In at least some embodiments, the query receiving unit receives a draft query for target content of data obtainable by a group of mobile computing networks from a client device.

[0079] In S662, the query receiver estimates the delay. In at least some embodiments, the query receiver estimates the delay until the target amount of target content is received. In at least some embodiments, the query includes the target amount of target content. In at least some embodiments, the query receiver estimates the delay for each mobile computing network based on the likelihood that the mobile computing network will encounter the target content, the bandwidth of the connection to the mobile computing network, and the number of available resources of the mobile computing network.

[0080] In S664, the query receiver estimates the energy consumption. In at least some embodiments, the query receiver estimates the energy consumption by the group of mobile computing networks for obtaining and transmitting the target amount of target content. In at least some embodiments, the query receiver estimates the energy consumption for each mobile computing network based on the complexity of the task and the type of connection to the mobile computing network. In at least some embodiments, the query receiver estimates the energy consumption not only of the mobile computing network but also of vehicles, connection service providers, and any other entity that consumes energy in the process, particularly the entity that bills for the energy consumption. In at least some embodiments, the energy consumption represents the cost of obtaining and transmitting the target amount of target content.

[0081] In S666, the query receiver transmits the estimated values to the client device. In at least some embodiments, the query receiver transmits the estimated delay time and the estimated energy consumption to the client device.

[0082] In S668, the query receiver determines whether the estimated value is acceptable. In at least some embodiments, the query receiver requests confirmation after transmitting the estimated delay and the estimated energy consumption. If the query receiver determines that the estimated value is not acceptable, the operation flow receives a modified query (S669) and returns to the estimation of the delay in S662. If the query receiver determines that the estimated value is acceptable, the operation flow ends.

[0083] FIG. 7 is an operation flow for programming a content query task according to at least some embodiments of the present disclosure. The operation flow provides a method for programming a content query task. In at least some embodiments, the method is executed by a server such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, the method is executed by a programming unit of a processor of a server such as processor 1002 shown in FIG. 10, which will be described below.

[0084] In S770, the programming unit determines whether the vehicle model includes an embedded detection function. In at least some embodiments, the programming unit determines each mobile computing network having an embedded function for directly detecting target content from among a group of mobile computing networks. If the programming unit determines that the vehicle model does not include an embedded detection function, the operation flow proceeds to the detection subtask programming in S771. If the programming unit determines that the vehicle model has an embedded detection function, the operation flow proceeds to the retention policy adjustment in S773.

[0085] In S771, the programming unit programs the detection subtask. In at least some embodiments, the programming unit programs the detection subtask within the task of detecting target content for each mobile computing network that does not have an embedded function. In at least some embodiments, the programming unit programs an image recognition algorithm for recognizing target content from an image sensor.

[0086] In S773, the programming unit adjusts the retention policy. In at least some embodiments, the query includes a priority value of the target content. In at least some embodiments, the programming unit adjusts the retention policy of each mobile computing network based on the priority value with respect to other priority values of the tasks to be executed simultaneously. In at least some embodiments, the retention policy includes a probability of purging (removing, deleting) each instance of the acquired target content, and the probability of purging is inversely proportional to the priority value. In at least some embodiments, the probability of purging is a function of the elapsed time (age) and the priority value.

[0087] In S775, the programming unit determines whether the retention policy includes filtering. In at least some embodiments, the retention policy includes filtering as an alternative to purging. In at least some embodiments, the retention policy includes a probability of filtering each instance of the acquired target content, and the probability of filtering is inversely correlated with the priority value and is greater than the probability of purging. In at least some embodiments, the probability of filtering is a function of the elapsed time and the priority. If the programming unit determines that the retention policy includes filtering, the operation flow proceeds to filtering subtask programming in S776. If the programming unit determines that the retention policy does not include filtering, the operation flow proceeds to compression determination in S778.

[0088] In S776, the programming unit programs a filtering subtask. In at least some embodiments, the programming unit programs a filtering subtask within a task of filtering each instance of the acquired target content, and the filtering subtask is programmed to be executed by each mobile computing network using the available resources of the mobile computing network.

[0089] In S778, the programming unit determines whether the retention policy includes compression. In at least some embodiments, the retention policy includes compression as an alternative to purging. In at least some embodiments, the retention policy includes a probability of compressing each instance of the acquired target content, the probability of compressing is inversely correlated with the priority value, and is greater than the probability of purging. In at least some embodiments, the probability of compression is a function of the elapsed time and the priority value. If the programming unit determines that the retention policy includes compression, the operation flow proceeds to compression subtask programming in S779. If the programming unit determines that the retention policy does not include compression, the operation flow ends.

[0090] In S779, the programming unit programs a compression subtask. In at least some embodiments, the programming unit programs a compression subtask within a task of compressing each instance of the acquired target content, and the compression subtask is programmed to be executed by each mobile computing network using the available resources of the mobile computing network.

[0091] FIG. 8 is an operation flow for transmitting a content query according to at least some embodiments of the present disclosure. This operation flow provides a method for transmitting a content query. In at least some embodiments, this method is executed by a server such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, this method is executed by a transmission unit of a processor of a server such as processor 1002 shown in FIG. 10, which will be described below.

[0092] In S880, the transmission unit transmits a task. In at least some embodiments, the transmission unit transmits the task to each mobile computing network. In at least some embodiments, as the iteration of S555 progresses, the transmission unit transmits the task to each mobile computing network.

[0093] In S882, the transmission unit transmits a retention policy. In at least some embodiments, the transmission includes transmitting the task and the adjusted retention policy to each mobile computing network. In at least some embodiments, as the iteration of S555 progresses, the transmission unit transmits the task and the adjusted retention policy to each mobile computing network.

[0094] In S884, the transmission unit determines whether the bandwidth of the connection between the mobile computing network and the server is higher than a threshold. In at least some embodiments, the transmission unit transmits a large data payload such as a subtask only via a high-bandwidth connection. If the transmission unit determines that the bandwidth of the connection between the mobile computing network and the server is higher than the threshold, the operation flow proceeds to subtask transmission in S886. If the transmission unit determines that the bandwidth of the connection between the mobile computing network and the server is not higher than the threshold, the operation flow returns to bandwidth determination in S884.

[0095] In S886, the transmitting unit transmits subtasks to the vehicle. In at least some embodiments, the transmitting unit transmits the detection subtask to each mobile computing network in response to detecting that the connection to the mobile computing network has a bandwidth higher than a threshold bandwidth value. In at least some embodiments, the transmitting unit transmits the filtering subtask to each mobile computing network in response to detecting that the connection to the mobile computing network has a bandwidth higher than a threshold bandwidth value. In at least some embodiments, the transmitting unit transmits the compression subtask to each mobile computing network in response to detecting that the connection to the mobile computing network has a bandwidth higher than a threshold bandwidth value. In at least some embodiments, the transmitting unit stops transmitting in response to the bandwidth falling below the threshold and resumes transmitting in response to the bandwidth exceeding the threshold.

[0096] FIG. 9 is an operation flow for receiving queried content according to at least some embodiments of the present disclosure. This operation flow provides a method for receiving queried content. In at least some embodiments, this method is executed by a server such as server 120 shown in FIG. 1 or server 440 shown in FIG. 4. In at least some embodiments, this method is executed by the data receiving unit of a processor of a server such as processor 1002 shown in FIG. 10, which will be described below.

[0097] In S990, the data receiving unit receives metadata. In at least some embodiments, the data receiving unit receives the metadata of each instance of the acquired target content. In at least some embodiments, the metadata provides a description or keyword that describes each instance of the acquired target content.

[0098] In S993, the data receiving unit transmits a content transmission policy. In at least some embodiments, the data receiving unit transmits, in response to receiving metadata of each instance of the acquired target content, a content transmission policy including a transmission priority value corresponding to each instance of the acquired target content from the server.

[0099] In S996, the data receiving unit receives an instance of the acquired target content. In at least some embodiments, the data receiving unit receives the first instance of the acquired target content among each instance of the acquired target content in the order based on the transmission priority value. In at least some embodiments, the transmission priority value is based on a function of the transmission priority value of the content transmission policy, and the function of the transmission priority value is based on the size of the first instance, the elapsed time of the first instance, and the bandwidth of the connection to the server.

[0100] In S999, the data receiving unit determines whether all of the acquired target content has been received. If the data receiving unit determines that the acquired target content has not yet been received, the operation flow returns to S996. If the data receiving unit determines that all of the acquired target content has been received, the operation flow ends.

[0101] FIG. 10 is a diagram of a system 1000 for implementing a claim search system according to some embodiments. System 1000 includes a hardware processor 1002 and a non-transitory computer-readable storage medium (memory) 1004 encoded with, i.e., storing, a set of executable instructions, i.e., computer program code 1006. The computer-readable storage medium 1004 is also encoded with instructions 1007 for interacting with external devices. The processor 1002 is electrically coupled to the computer-readable storage medium 1004 via a bus 1008. The processor 1002 is also electrically coupled to an I / O interface 1010 by the bus 1008. A network interface 1012 is also electrically connected to the processor 1002 via the bus 1008. The network interface 1012 is connected to a network 1014, enabling the processor 1002 and the computer-readable storage medium 1004 to be connected to external elements via the network 1014. The processor 1002 is configured to execute the computer program code 1006 encoded in the computer-readable storage medium 1004 to enable the use of system 1000 to perform some or all of the operations as described in ODDR system 100 (FIG. 1), ODDR system 400 (FIG. 4), or method 600 (FIG. 6).

[0102] In some embodiments, the processor 1002 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application specific integrated circuit (ASIC), and / or a suitable processing device.

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

[0104] In some embodiments, the storage medium 1004 stores computer program code 1006 configured to cause the system 1000 to perform some or all of the operations as described in the ODDR system 100 (FIG. 1), the ODDR system 400 (FIG. 4), or the method 600 (FIG. 6). In some embodiments, the storage medium (memory) 1004 stores the information necessary to perform some or all of the operations as described in the ODDR system 100 (FIG. 1), the ODDR system 400 (FIG. 4), or the method 600 (FIG. 6), as well as priority level parameters 1016, query ID parameters 1018, query status parameters 1020, query data parameters 1022, and / or information generated during the execution of some or all of the operations as described in the ODDR system 100 (FIG. 1), the ODDR system 400 (FIG. 4), or the method 600 (FIG. 6), such as a set of executable instructions for performing some or all of the operations as described in the ODDR system 100 (FIG. 1), the ODDR system 400 (FIG. 4), or the method 600 (FIG. 6).

[0105] In some embodiments, the memory medium 1004 stores instructions 1007 for interacting with a manufacturing machine. The instructions 1007 enable the processor 1002 to generate manufacturing instructions that are readable by the manufacturing machine in order to effectively implement the method 400 during the manufacturing process.

[0106] The system 1000 includes an I / O interface 1010. The I / O interface 1010 is coupled to an external circuit. In some embodiments, the I / O interface 1010 includes a keyboard, keypad, mouse, trackball, trackpad, and / or cursor direction keys for communicating information and instructions to the processor 1002.

[0107] The system 1000 also includes a network interface 1012 coupled to the processor 1002. The network interface 1012 enables the system 1000 to communicate with a network 1014 to which one or more other computer systems are connected. The network interface 1012 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, some or all of the operations as described in the ODDR system 100 (FIG. 1), ODDR system 400 (FIG. 4), or method 600 (FIG. 6) are implemented in two or more systems 1000, and information such as priority levels, query IDs, query statuses, and query data is exchanged between different systems 1000 via the network 1014.

[0108] Mobile computing network programming for querying content acquisition receives, from a client device, a query for target content of data obtainable by a group of mobile computing networks, the query including a target content identifier identifying the target content, programs a task to acquire the target content, the task being programmed to be executed by each mobile computing network using available resources of the mobile computing network, sends the task to each mobile computing network, and receives data including the target content from each mobile computing network in the group of mobile computing networks, and is implemented thereby.

[0109] As described above, the features of several embodiments have been outlined so that those skilled in the art can better understand aspects of the present disclosure. Those skilled in the art should understand that the present disclosure can be readily used as a basis for designing or modifying other processes and structures for achieving the same purposes and / or achieving the same advantages as the embodiments introduced herein. Those skilled in the art should also understand that such equivalent structures do not depart from the spirit and scope of the present disclosure and that various changes, substitutions, and modifications may be made herein without departing from the spirit and scope of the present disclosure.

Claims

1. The processor receives a query for target content of data obtainable by a mobile computing network group from a client device, the query including a target content identifier identifying the target content; programs a task including instructions for obtaining the target content, the task being programmable to be executed by each mobile computing network using available resources of the mobile computing network; sends the task to each mobile computing network; receives data including the target content from each mobile computing network in the mobile computing network group; and programming the task includes determining, from among the mobile computing network group, each mobile computing network having a built-in function for directly detecting the target content; programming a detection subtask within the task that includes instructions for detecting the target content for each mobile computing network not having the built-in function.

2. Sending the task includes the processor sending the detection subtask to each mobile computing network in response to detecting that a connection to the mobile computing network has a bandwidth higher than a bandwidth threshold. The method according to claim 1.

3. The query includes a priority value of the target content, programming the task includes the processor adjusting a retention policy of each mobile computing network based on a priority value relative to other priority values of tasks executed simultaneously, and sending the task includes the processor sending the task and the adjusted retention policy to each mobile computing network. The method according to claim 1.

4. The method according to claim 3, wherein the retention policy includes a probability of purging each instance of the acquired target content, and the probability of purging is inversely correlated with the priority value.

5. The method according to claim 4, wherein the probability of purging is a function of the elapsed time and the priority value.

6. The method according to claim 4, wherein the retention policy includes a probability of filtering each instance of the acquired target content, the probability of filtering is inversely proportional to the priority value and is greater than the probability of purging.

7. Programming the task comprises programming, by the processor, a filtering subtask within the task that includes instructions for filtering each instance of the acquired target content, the filtering subtask being programmed to be executed by each mobile computing network using available resources of the mobile computing network, the method according to claim 6.

8. The method according to claim 4, wherein the retention policy includes a probability of compressing each instance of the acquired target content, the probability of compression is inversely correlated with the priority value and is greater than the probability of purging.

9. Programming the task comprises programming, by the processor, a compression subtask within the task that includes instructions for compressing each instance of the acquired target content, the compression subtask being programmed to be executed by each mobile computing network using available resources of the mobile computing network, the method according to claim 8.

10. Further comprising estimating a delay until a target amount of the target content is received, The query includes a target amount of the target content, the method according to claim 1.

11. The delay is estimated for each of the mobile computing networks based on the likelihood that the mobile computing network will encounter the target content, the bandwidth of the connection to the mobile computing network, and the number of available resources of the mobile computing network, according to the method of claim 10.

12. The method of claim 10, further comprising estimating energy consumption by a group of mobile computing networks for obtaining and transmitting a target amount of the target content.

13. The energy consumption is estimated for each of the mobile computing networks based on the complexity of the task and the type of connection to the mobile computing network, according to the method of claim 12.

14. The method of claim 12, further comprising the processor transmitting the estimated delay and the estimated energy consumption to the client device.

15. Receiving the data includes the processor receiving metadata of each instance of the obtained target content, according to the method of any one of claims 1 to 14.

16. Receiving the data includes the processor transmitting a content transmission policy including a transmission priority value corresponding to each instance of the obtained target content in response to receiving the metadata of each instance of the obtained target content, according to the method of claim 15.

17. Receiving the data includes the processor receiving a first instance of the obtained target content from among each instance of the obtained target content in an order based on the transmission priority value, according to the method of claim 16.

18. Receiving a query from a client device for target content of data obtainable by a group of mobile computing networks, the query including a target content identifier identifying the target content. Programming a task that includes instructions for obtaining the target content, the task being programmed to be executable by each mobile computing network using the available resources of the mobile computing network, and programming the task; Sending the task to each mobile computing network; Receiving data including the target content from each mobile computing network in the group of mobile computing networks; A non-transitory computer-readable medium including instructions executable by a processor to cause the processor to perform a process including: Programming the task includes: Determining, from among the group of mobile computing networks, each mobile computing network having an embedded function for directly detecting the target content; Programming a detection subtask within the task that includes instructions for detecting the target content for each mobile computing network that does not have the embedded function.

19. Receiving, from a client device, a query for target content of data obtainable by a group of mobile computing networks, the query including a target content identifier that identifies the target content; Programming a task that includes instructions for obtaining the target content, the task being programmed to be executable by each mobile computing network using the available resources of the mobile computing network, and programming the task; Sending the task to each mobile computing network; Receiving data including the target content from each mobile computing network in the group of mobile computing networks; Configured to perform a process including: Programming the task includes: From among the mobile computing network group, each mobile computing network having an embedded function for directly detecting the target content is determined; For each mobile computing network that does not have the embedded function, a detection subtask within a task including instructions for detecting the target content is programmed, and an apparatus having a controller including a circuit is included.

Images