Data collection optimization system and method of use thereof

Abstract

A method of in-vehicle data collection includes determining whether a first rule of a plurality of rules overlaps any other rule of the plurality of rules. The method also includes, in response to determining that the first rule overlaps at least one other rule of the plurality of rules, identifying overlapping data collection data. The method also includes, in response to detecting a trigger event, collecting data associated with the first rule. The method also includes storing a single copy of the overlapping data collection data regardless of a number of rules of the plurality of rules that overlap the first rule.

Description

Background Technology

[0001] In-vehicle systems feature an increased level of computerization. This computerization facilitates the use of sensors within the vehicle to collect information about vehicle performance or related to the vehicle's surrounding environment. This information can be transmitted to a central server for review and analysis to help improve vehicle performance or gather information related to the environment the vehicle is traversing. In some instances, third parties (such as application developers, insurance companies, or government agencies) submit queries for information related to vehicle performance or the vehicle's surrounding environment. Attached Figure Description

[0002] The various aspects of this disclosure can be best understood from the following detailed description, which is taken in conjunction with the accompanying drawings. It should be noted that, in accordance with industry standard practice, the features are not drawn to scale. In fact, for clarity of discussion, the dimensions of the features may be arbitrarily enlarged or reduced.

[0003] Figure 1 This is a schematic diagram of a request retrieval system according to some embodiments.

[0004] Figure 2 It is a view of a graphical user interface (GUI) for a request retrieval system according to some embodiments.

[0005] Figure 3 This is a diagram of the data structure of a request retrieval command according to some embodiments.

[0006] Figure 4 This is a schematic diagram of a request retrieval system according to some embodiments.

[0007] Figure 5 This is a flowchart of a method for implementing a request retrieval system according to some embodiments.

[0008] Figure 6 This is a flowchart of a method for collecting data using an in-vehicle system according to some embodiments.

[0009] Figure 7 This is a diagram of a system for implementing a request retrieval system according to some embodiments. Detailed Implementation

[0010] The following disclosure provides numerous different embodiments or examples for implementing various features of the provided subject matter. Specific examples of components, values, operations, materials, arrangements, or the like are described below to simplify this disclosure. These are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc., may also be contemplated. For example, in the following description, the formation of a first feature above or on a second feature may include embodiments where the first and second features are formed in direct contact, or embodiments where an additional feature may be formed between the first and second features such that the first and second features do not need to be in direct contact. Furthermore, reference numerals and / or letters may be repeated in various embodiments of this disclosure. Such repetition is for brevity purposes and does not in itself determine the relationship between the various embodiments and / or configurations discussed.

[0011] In addition, for ease of description, this document may use spatial relative terms such as “below,” “under,” “lower,” “above,” “upper,” etc., to describe the relationship of an element or feature to another element(s) or feature(s) shown in the figures. Besides the orientations described in the figures, spatial relative terms are also intended to cover different orientations of the device during use or operation. The device may also be in other orientations (rotated 90 degrees or other orientations), and the spatial relative descriptors used herein will be interpreted similarly.

[0012] Data collection can be used to satisfy rules or requests received by a third-party customer based on triggering events detected in one or more vehicles. Data collection for a rule or request occurs in response to the detection of a triggering event. In some embodiments, data collection includes retrieving data stored in memory within the vehicle. In some embodiments, data collection includes capturing newly detected data from one or more sensors within the vehicle. In some embodiments, data collection includes both retrieving stored data and capturing new data.

[0013] In some instances, rules or requests for different users seek to collect the same or similar data. In some embodiments, similar data includes data from the same sensor with overlapping collection time periods. In some embodiments, the time periods are of equal duration. In some embodiments, one of the multiple time periods extends beyond the other time periods before or after the collection duration of that time period. In some instances, similar data includes overlap in the requested sensor data. For example, in some embodiments, a first rule requests data from a first sensor and a second sensor in a first time period; and a second rule requests data from a first sensor and a third sensor in the first time period. There is overlap in the data collection requests for data from the first sensor in the first time period. Other permutations of overlap will be understood by those skilled in the art. A rule or request is a query about vehicle performance or information related to the vehicle's surrounding environment. In some instances, a rule is a persistent query that seeks to be satisfied over multiple occurrences of a triggering event. In some instances, a request is a single query that is satisfied in response to the detection of a triggering event or in response to the receipt of a request. In some instances, rules and requests are used interchangeably.

[0014] Rules requesting data capture can request multiple data types, and as the number of rules increases, the likelihood of multiple rules requesting the same data also increases. When multiple rules request the same type of data, the data collection process identifies the similarity and collects and stores the data only once to avoid redundant processing and storage costs.

[0015] In some embodiments, the priority of data collection processing increases when multiple rules request the same type of data. The priority of data collection processing, or a factor thereof, is adjusted based on the number of rules requesting data collection processing. In some embodiments, the priority of data collection processing, or a factor thereof, is defined by the sum of the priorities of the rules requesting the data collection processing, or by other calculation methods.

[0016] Figure 1This is a schematic diagram of a request retrieval system 100 according to some embodiments. The request retrieval system 100 includes a user interface (UI) 110. The UI 110 is configured to receive user requests for data from a vehicle 140. The request retrieval system 100 also includes a server 120 configured to: receive user requests from the UI 110; transmit user requests to the vehicle 140; receive data from the vehicle 140; and provide the data to the user via an accessible console 150. The server 120 includes a communication portion 130 for communicating with the UI 110 and the vehicle 140. The request retrieval system 100 also includes an accessible console 150 configured to communicate data collected from the vehicle 140 to the user.

[0017] UI 110 is configured to receive input instructions from a user. In some embodiments, the user includes a software developer. In some embodiments, the user includes a machine learning model developer. In some embodiments, the user includes an insurance provider. In some embodiments, the user includes law enforcement. In some embodiments, the user includes a market research company. UI 110 provides the user with options to select what type of vehicle and what type of data to request. In some embodiments, UI 110 is capable of generating a data request using forms associated with vehicle identification information, the data type requested, and start and end times. In some embodiments, the start and end times are absolute times, such as Unix time, i.e., time elapsed since the Unix epoch. In some embodiments, the start and end times are relative times relative to the time when the vehicle receives the data request. In some embodiments, the start and end times are relative times relative to a triggering event. In some embodiments, UI 110 also provides the user with options for selecting a triggering event and the duration of data collection relative to the triggering event. In some embodiments, UI 110 includes information related to the type of vehicle from which it requests data. In some embodiments, UI 110 includes a vehicle ID that can uniquely identify the vehicle as the target of the request. For example, the vehicle ID includes a Universally Unique Identifier (UUID) format. In some embodiments, UI 110 includes data types that can identify the source of data that a user wishes to collect. For example, data types include sensor IDs of sensors from which sensor data is collected, and application IDs of applications from which application logs are collected. In some embodiments, the sensor IDs and application IDs are formatted using a Universally Unique Identifier (UUID) format. In some embodiments, UI 110 includes drop-down menus. In some embodiments, UI 110 includes editable fields for receiving information related to data requests. In some embodiments, UI 110 provides information about which data option types are available to the user. In some embodiments, the available data option types depend on the user. For example, in some embodiments, law enforcement officers are able to select more data options than insurance providers.

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

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

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

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

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

[0023] The communication section 130 also includes a query queue 134 configured to store data requests for transmission to the vehicle 140 in priority order. In some embodiments, the query queue 134 is integrated into the memory unit 132. In some embodiments, the query queue 134 is separate from the memory unit 132. In some embodiments, the query queue 134 is configured to retrieve data requests from the memory unit 132 based on priority level and timestamp information. In some embodiments, the query queue 134 is configured to sort data requests based on priority level; and in response to data requests with the same priority level, to sort them according to the time since they were initially stored in the memory unit 132.

[0024] The communication section 130 also includes a transmitter 135 configured to transmit data requests from a query queue 134 to a vehicle 140. The transmitter 135 is configured to transmit data requests to the vehicle 140 based on the order of data requests in the query queue 134. In some embodiments, the data requests are transmitted wirelessly to the vehicle 140. In some embodiments, the data requests are transmitted to the vehicle 140 via a wired connection. The data requests transmitted to the vehicle 140 include trigger event information, data duration information relating to how long before and after the trigger event should be collected, and sensor information indicating the type of sensor in the vehicle 140 from which data should be collected. In some embodiments, the data requests transmitted to the vehicle 140 include priority level information. In some embodiments, the transmitter 135 is configured to transmit the data requests to the vehicle 140 when the vehicle 140 sends a request to the server 120 to transmit data to the vehicle 140. In some embodiments, the transmitter 135 is configured to transmit a data request to the vehicle 140 whenever the communication unit 130 has sufficient connectivity with the vehicle 140 to transmit the data request, unless the communication unit 130 receives information indicating that the vehicle 140 cannot accept a new data request. In some embodiments, the transmitter 135 is configured to periodically transmit data requests to the vehicle 140 as long as the vehicle 140 is able to receive new data requests and the transmitter 135 has sufficient connectivity with the vehicle 140. In some embodiments, the transmitter 135 is configured to transmit data requests to the vehicle 140 in batches (e.g., in groups of 5 data requests, 20 data requests, or some other number of data requests). In some embodiments, the transmitter 135 is configured to request acknowledgment of receipt of the data request from the vehicle 140. The transmitter 135 is configured to retransmit the data request in response to not receiving acknowledgment of receipt from the vehicle within a predetermined time period. In some embodiments, in response to the communication section 130 receiving an acknowledgment of receipt of a data request from the vehicle 140, the status of the data request stored in the memory unit 132 is updated to indicate submission to the vehicle 140.

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

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

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

[0028] Server 120 also includes a data storage 126 configured to store collected data generated by data preprocessor 122. In some embodiments, data storage 126 is integrated with memory unit 132. In some embodiments, data storage 126 is separate from memory unit 132. In some embodiments, data storage 126 includes a solid-state drive (SSD), random access memory, or other suitable memory. In some embodiments, a user can access data storage 126, for example, using UI 110 or accessible console 150. In some embodiments, data storage 126 is configured to notify a user in response to the availability of data in relation to a data request. In some embodiments, the notification includes issuing an alert to the user. In some embodiments, the alert includes an audio or visual alarm. In some embodiments, data storage 126 is configured to cause UI 110 or accessible console 150 to automatically display a notification of the availability of collected data. In some embodiments, data storage 126 can be accessed by a user using accessible console 150 without the user submitting a data request. In some embodiments, a user can search for data within data storage 126 via accessible console 150. In some embodiments, collected data is visualized in console 150.

[0029] The request retrieval system 100 also includes a vehicle 140. The vehicle 140 includes sensors for detecting the internal state of the vehicle 140 and the external environment surrounding the vehicle 140. In some embodiments, the sensors include cameras, light distance and ranging (LiDAR) sensors, radio distance and ranging (RADAR) sensors, sound navigation and ranging (SONAR) sensors, accelerometers, steering wheel position sensors, speedometers, or other suitable sensors. The vehicle 140 is capable of receiving data requests wirelessly or via a wired connection.

[0030] In some embodiments, vehicle 140 is configured to assign a data request ID to a received data request in response to receiving the data request, and the data request is processed independently of the system or program that initiated the data request. In other embodiments, communication section 130, rather than vehicle 140, specifies the data request ID, and the data request ID is included in the data request sent from communication section 130 to vehicle 140. Making the data request independent of the system or program that initiated the data request helps expand the ability of vehicle 140 to receive and process a variety of data requests from different users and systems. Vehicle 140 includes a processor for processing data requests and determining which type of information from which sensors available in vehicle 140 can satisfy the data request. Vehicle 140 also includes memory for storing data from the sensors. In some embodiments, the processor accesses the memory to determine whether the stored data can satisfy the data request. Vehicle 140 is also capable of wirelessly or via a wired connection transmitting data deemed to satisfy the data request to server 120. In some embodiments, the processor is configured to attempt to satisfy received data requests in a priority order based on a priority level of the received data requests. In some embodiments, vehicle 140 is configured to prioritize transmitting data to the server based on the priority level of received data requests.

[0031] 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 the software application stored in the ECU. In some embodiments, the data request is generated in response to a triggering event, such as sudden acceleration, sudden braking, capture of sensor data including a specific object or scene predefined in the software application, a software application “crash,” an anomaly detected in the software application, or other appropriately detected occurrence events. In some embodiments, vehicle 140 is configured to generate a notification to the maintainer of the software application (e.g., a user) in response to the detection of a triggering event related to the software application. In some embodiments, the notification is transmitted to the user wirelessly or directly via a wired connection, for example, through UI 110. In some embodiments, the notification is transmitted to the user wirelessly or via a wired connection through server 120. In some embodiments, the notification includes audio or visual notifications. In some embodiments, the notification is configured to cause UI 110 to display the notification automatically without user interaction.

[0032] The request retrieval system 100 also includes an accessible console 150. The accessible console 150 allows a user to access collected data stored in the data storage 126. In some embodiments, the accessible console 150 is integrated with the UI 110. In some embodiments, the accessible console 150 is separate from the UI 110. In some embodiments, the accessible console 150 includes a separate server from the server 120. In some embodiments, the accessible console 150 automatically receives collected data related to a data request from a user after the data storage 126 receives the collected data. In some embodiments, the accessible console 150 allows a user to search the data storage 126 to determine if any of the collected data stored in the data storage 126 is useful to the user, without requiring the user to submit a data request.

[0033] Using the request retrieval system 100, users can obtain information from one or more vehicles 140 in an easily understandable format without relying on specialized equipment to request or retrieve received data. The ability of the request retrieval system 100 to prioritize data requests helps ensure that law enforcement or other users can access data, while also allowing users to pay for faster access. This flexibility enhances the usability of the request retrieval system 100 to a wide range of users.

[0034] Figure 2 These are views of graphical user interfaces (GUIs) 200 and 250 of a request retrieval system according to some embodiments. In some embodiments, GUI 200 may be used as a request retrieval system 100 ( Figure 1UI 110 in ) . In some embodiments, GUI 200 can be used to generate UI 110 for receiver 131 ( Figure 1 The GUI 200 receives data requests. The GUI 200 includes multiple information types 210 that identify the types of information the GUI 200 can accept from the user. The GUI 200 also includes multiple fields 220 configured to receive information associated with the corresponding information type 210 of the GUI 200. The GUI 200 also includes a submit button 230 configured to submit information to the server (e.g., server 120) based on the information in the fields 220. Figure 1 Submit a data request. Those skilled in the art will recognize that the names and quantities of the multiple information types 210 are merely exemplary, and different quantities and types of information are also within the scope of this disclosure.

[0035] In some embodiments, field 220 includes fields for a user to input a vehicle ID, data type, start time, and end time. In some embodiments, field 220 also includes a field for a user to input a priority level for a data request. In some embodiments, GUI 200 also includes information related to how a user can increase the priority level of a data request, such as an indication of the cost associated with each available priority level. In some embodiments, GUI 200 includes a field 220 allowing a user to input login information to establish a user identity. In some embodiments, GUI 200 is configured to display the user's priority level upon receiving login information. In some embodiments, GUI 200 also includes a field 220 for receiving payment information related to the cost of establishing a priority level for a data request.

[0036] GUI 250 is configured to be displayed to the user after the user selects the submit button 230 on GUI 200. In some embodiments, GUI 250 may be used as a request retrieval system 100. Figure 1 GUI 110 in ) . GUI 250 includes information indicating that a data request has been received. GUI 250 includes a query ID label 260 and a query ID field 270. After the server receives and stores the data request, it is retrieved from the server (e.g., server 120) Figure 1 The GUI 250 receives information used to populate the query ID field 270. In some embodiments, the GUI 250 includes vehicle ID information. In some embodiments, the GUI 250 includes information related to the priority level of the data request. In some embodiments, the GUI 250 includes information about the status of the data request (such as in progress, submitted, completed, etc.). In some embodiments, the GUI 250 includes information related to the time until the data request is submitted to a vehicle (e.g., vehicle 140). Figure 1Information related to the estimated time up to [date / time]. In some embodiments, GUI 250 automatically displays this information in response to a query ID received from the server. In some embodiments, GUI 250 displays this information in response to a user-submitted request to update uploaded data.

[0037] Figure 3 This is a diagram of the data structure 300 for a request retrieval command 310 according to some embodiments. In some embodiments, the request retrieval command 310 is transmitted from server 120 to vehicle 140 ( Figure 1 The request retrieval command 310 includes a request to a vehicle (e.g., vehicle 140). Figure 1 The data request sent contains information related to the type of data it seeks.

[0038] The request retrieval command 310 includes a priority parameter 311, which indicates the priority level of the data request. The request retrieval command 310 also includes a log level parameter 312, which indicates what type of data (if any) should be retrieved from other applications on the vehicle. For example, in some embodiments, the request retrieval 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 retrieval command 310, or the log level parameter 312 is empty. The request retrieval command 310 also includes a collection time range parameter 313, which indicates the time period before and / or after the triggered event to be collected. This time range corresponds to the user's input in GUI 200 (…). Figure 2The request retrieval command 310 also includes a Uniform Resource Locator (URL) endpoint parameter 314, which indicates the destination of the data collected in response to the data request. The request retrieval command 310 also includes a frequency parameter 315, which indicates how frequently data should be sampled from the time range 313 (if any). For example, when the event time is t = 100 seconds, the time range includes a start time = -1 second and an end time = 2 seconds, and the frequency is 10 Hz (100 millisecond periods), then according to the request retrieval command, data is collected for t = 99.0 seconds, 99.1 seconds, 99.2 seconds, ..., 101.9 seconds, 102.0 seconds. The request retrieval command 310 also includes a log ID parameter 316, which indicates the type of sensor and / or application that can be used to collect the data requested in the data request. In some embodiments, unique IDs (such as Universally Unique Identifiers (UUIDs)) are pre-assigned to all sensors and applications, and the unique ID from which the user wishes to collect data is specified in the Log ID parameter 316. The request retrieval command 310 also includes a requester ID parameter 317, which indicates the identity of the user making the data request. The request retrieval command 310 also includes an event ID parameter 318, which indicates a triggering event associated with the data request. The request retrieval command 310 also includes a budget ID parameter 319, which indicates the vehicle (e.g., vehicle 140) Figure 1 How much of the resources should be allocated to satisfy the data request? Those skilled in the art will understand that other parameters are possible in the request retrieval command 310. For example, in some embodiments, the request retrieval command 310 includes a vehicle location parameter indicating the geographic area where the triggering event may occur. Those skilled in the art will also understand that the request retrieval command 310 does not always include… Figure 3 All parameters in the budget ID parameter are omitted. For example, in some embodiments, the budget ID parameter 319 is omitted.

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

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

[0041] The vehicle detection system 410 includes an electronic control unit (ECU) 420 configured to receive data from sensors 414, a Global Positioning System (GPS) 416, and a map 418. The ECU 420 includes a situation detector 422, a data assigner 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.

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

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

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

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

[0046] Condition detector 422 is configured to generate information related to the performance of the vehicle and its in-vehicle systems. Condition detector 422 is capable of collecting information from components within the vehicle, such as sensor 414, braking system, acceleration system, and other suitable components. Using this information, condition detector 422 can determine the vehicle's performance. In some embodiments, condition detector 422 is also configured to monitor the performance of software and network operations within the vehicle. For example, in some embodiments, condition detector 422 is configured to receive information related to software or application "crashes" within the vehicle. In some embodiments, condition detector 422 is configured to collect information related to the storage capacity of memory devices within the vehicle. In some embodiments, condition detector 422 is configured to receive information related to the processing power of the processor within the vehicle.

[0047] 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, bumps, braking, steering, pitch, roll, yaw, flashing hazard lights, horn sounds, or other appropriate information. Vehicle control monitor 424 is configured to determine whether any of the received sensor data indicates that a requested criterion has been met, such as the detection of a triggering event.

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

[0049] Scene detector 428 is configured to receive sensor data from sensor 414 to determine whether any scene in the environment surrounding the vehicle satisfies requested conditions. In some embodiments, scene detector 428 is configured to determine that a vehicle accident has occurred in response to detecting two or more vehicles in contact with each other or a vehicle being surrounded by multiple fallen objects. In some embodiments, scene detector 428 is configured to determine that construction is taking place based on detecting multiple construction vehicles approaching. In some embodiments, scene detector 428 is configured to determine that a vehicle is parked on the shoulder of a road based on determining that the vehicle is located near the road and is not moving or is moving at a significantly slower speed than other vehicles. In some embodiments, scene detector 428 is configured to use image recognition (such as through a trained neural network) to determine the content of the scene surrounding the vehicle.

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

[0051] In some embodiments, the ECU 420 also includes a duplicate filter that can be used to identify duplicate data requests based on one or more rules stored in the vehicle detection system 410.

[0052] Data designator 432 is configured to receive confirmation that a request has been fulfilled or a triggering event has been detected. Data designator 432 is configured to analyze the received information to determine, based on the received data, which sensor data should be collected from sensor 414. For example, in some embodiments where abnormal driver steering behavior is detected, data designator 432 is configured to determine that image data from a front camera of sensor 414 should be captured. Furthermore, data designator 432 is configured to determine the time period from which data should be collected from the determined sensor based on the time of the detected event. In some embodiments, data designator 432 is configured to determine the sensor 414 from which data should be collected based on instructions in a request received from a user.

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

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

[0055] Log collector 434 generates log data based on received relevant data, such as cropped images and location data. Log collector 434 also associates timestamp information with the log data to help synchronize the collected data and queue priorities within server 440. In some embodiments, the log data generated by log collector 434 also includes world coordinates associated with the cropped image. In some embodiments, the log data generated by log collector 434 also includes map locations associated with the cropped image. In some embodiments, the log data generated by log collector 434 also includes additional information to help increase the accuracy of identifying objects or scenes.

[0056] While the foregoing description relates to generating log data based on images from sensor 414, those skilled in the art will understand that log collector 434 is not limited to generating log data based on images. In some embodiments, log collector 434 is configured to generate log data based on information from other sensors attached to the vehicle, such as RADAR, LiDAR, or other suitable sensors. In some embodiments where the occupant wears smart glasses, log collector 434 is also configured to generate log data based on information received from the smart glasses.

[0057] Log transmitter 436 is configured to receive log data from log collector 434 and transmit the log data to server 440. In some embodiments, log transmitter 436 is configured to transmit log data wirelessly. In some embodiments, log transmitter 436 is configured to transmit log data via a wired connection. In some embodiments, log transmitter 436 is configured to transmit log data directly to user terminal 460. In some embodiments, log transmitter 436 is configured to transmit log data to a user-accessible mobile device, which in turn is configured to transmit the log data to server 440. In some embodiments, log transmitter 436 is configured to use... Log data is transmitted to the mobile device using other suitable wireless technologies. In some embodiments, ECU 420 is configured to determine whether the data transfer rate from the mobile device to server 440 is higher than the transfer rate from log transmitter 436 to server 440. Log transmitter 436 is configured to transmit log data to the mobile device for transmission to server 440 in response to determining that the data transfer rate from the mobile device to server 440 is higher. Log transmitter 436 is also configured to transmit log data directly from vehicle detection system 410 to server 440 without transmitting log data to the mobile device in response to determining that the data transfer rate from the mobile device to server 440 is not higher.

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

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

[0060] Log data receiver 442 is configured to receive log data from log transmitter 436. In some embodiments, log data receiver 442 is configured to receive log data from a mobile device. In some embodiments, log data receiver 442 is configured to receive log data wirelessly. In some embodiments, log data receiver 442 is configured to receive log data via a wired connection. In some embodiments, log data receiver 442 is configured to append a timestamp of the time the log data was received to the log data.

[0061] Log encoder 444 is configured to encode received log data according to a predetermined encoding protocol. Encoding log data according to the predetermined encoding protocol helps ensure that user terminal 460 can reliably decode the log data for use by user terminal 460. In some embodiments, log encoder 444 is configured to perform log data compression, image encoding, thumbnail creation, or other suitable encoding protocols. In some embodiments, log encoder 444 is configured to perform log data encryption. In some embodiments, log encoder 444 is also configured to perform super-resolution, making the data easier for the user to see. Those skilled in the art will understand that super-resolution is the process of receiving a high-resolution image from a low-resolution image. Increasing the resolution of log data helps reduce false alarms or misreports.

[0062] In some embodiments, server 440 further includes a database for storing received log data. In some embodiments, the log data is stored in the database before and / or after being encoded by log encoder 444. In some embodiments, the log data is stored in the database in a priority queue. In some embodiments, the priority of the priority queue is determined based on the time when an object or scene (e.g., a triggering event) is detected, the time when log data receiver 442 receives log data, the type of object or scene, the identity of the detected vehicle driver, or other suitable priority criteria.

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

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

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

[0066] In some embodiments, server 440 is configured to transmit only log data related to newly detected triggering events. That is, if a triggering event has already been reported by server 440, it will not be reported again. Limiting duplicate reporting of triggering events helps reduce redundant data received by user terminals from server 440.

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

[0068] Those skilled in the art will understand that modifications to the request retrieval system 400 are within the scope of this disclosure. For example, in some embodiments, the vehicle detection system 410 is capable of transmitting log data directly to the user terminal 460 via a network (such as a wireless network). In some embodiments, the detection system can transmit log data directly to the user terminal 460, such as via a wireless network, by means of the occupants' mobile devices in the vehicle.

[0069] By automatically identifying and disseminating information related to fulfilling rules or requests detected in or around the vehicle, users can improve the performance of applications or software executed using the vehicle's processing system (e.g., ECU 420). In some embodiments, users can receive object information related to events such as accidents.

[0070] Figure 5 This is a flowchart of a method 500 for implementing a request retrieval system according to some embodiments. In some embodiments, method 500 uses a request retrieval system 100 ( Figure 1 ) or request retrieval from the 400 ( Figure 4 In some embodiments, method 500 uses request retrieval system 700 (…). Figure 7 In some embodiments, method 500 uses a request retrieval system 100 (in addition to request retrieval system 100) to achieve this. Figure 1 ), request retrieval system 400 ( Figure 4 ) or request retrieval system 700 ( Figure 7 This is implemented outside of other systems. The following description pertains to the processing of rules or requests received by the vehicle.

[0071] In operation 505, sensor data is collected. The sensor data is collected by one or more sensors that can be connected to the vehicle. In some embodiments, the sensor data includes control parameters of the vehicle. In some embodiments, the sensor data includes information related to the environment surrounding the vehicle. In some embodiments, the sensor data includes data from sensor 414 (… Figure 4 (and / or data from other sensors in the vehicle.)

[0072] In operation 510, sensor data is processed. The sensor data is processed to identify one or more triggering events associated with one or more rules stored in the vehicle's memory. In some embodiments, the sensor data is processed by situation detector 422 ( Figure 4 Processing. In some embodiments, sensor data is processed based on preprocessing instructions associated with one or more rules stored in the vehicle's memory. In some embodiments, sensor data is processed to remove sensor data that raises privacy concerns. In some embodiments, sensor data is processed to compress sensor data for storage in the vehicle's memory.

[0073] In operation 515, a determination is made regarding whether there is overlap between the rules. Overlap between rules means that at least a portion of the requested data collection for the first rule matches at least a portion of the requested data collection for the second rule. For example, in some embodiments, the first rule requests data collection from a first sensor for a duration from 5 seconds before the detected trigger event until 10 seconds after the detected trigger event; and the second rule requests data collection from the time the trigger event is detected until 15 seconds after the detected trigger event. These two rules overlap in their data collection of data from the first sensor for the duration from the time the trigger event is detected until 10 seconds after the detected trigger event. In operation 515, this overlap in data collection is determined to be rule overlap. In a further example, the first rule requests data collection from the first sensor for a duration of 10 seconds after the detected trigger event and from the second sensor for a duration of 15 seconds after the detected trigger event; and the second rule requests data from the second sensor for 10 seconds after the detected trigger event and from the third sensor for 5 seconds after the detected trigger event. These two rules overlap for data from the second sensor within 10 seconds following the detected trigger event. In operation 515, this overlap in data collection will be determined as rule overlap. Those skilled in the art will recognize that, according to some embodiments described herein, other arrangements of the sensor and data collection durations also conform to the overlap rules.

[0074] The above examples assume that the same triggering event applies to both the first rule and the second rule. In some embodiments, the triggering event for the first rule is related to, but not entirely equivalent to, the triggering event for the second rule. For example, in some embodiments, the first triggering event for the first rule is the detection of a traffic accident involving a vehicle; and the second triggering event for the second rule is the detection of a sudden change in vehicle speed. Those skilled in the art will understand that a sudden change in speed occurs in a traffic accident; however, in some instances, a sudden change in speed does not necessarily involve a traffic accident. In some embodiments, operation 515 is configured to analyze the triggering events of the rule to determine whether the triggering event is likely relevant. In some embodiments, this analysis is performed by a neural network before or after the rule is transmitted to the vehicle. In some embodiments, based on data stored on a server (e.g., server 440... Figure 4 )) or vehicle system (e.g., vehicle system 410) Figure 4 The analysis is performed using a database of related triggering events in the rules. In some embodiments, the relationships between triggering events are defined by the user when creating the rules (e.g., using UI 110). Figure 1In response to determining the correlation of triggering events, operation 515 treats two rules as having the same triggering event for the purpose of determining whether the rules overlap. This does not mean that if the second triggering event is met, the first rule will be activated even if the first triggering event is not met. Rather, it simply means that the rules are considered to overlap for the purpose of adjusting rule priority or increasing the efficiency of vehicle memory usage.

[0075] The above description includes an example where two rules are used to determine rule overlap. Those skilled in the art will recognize that more than two rules can also overlap. In some embodiments, all rules stored in a database within the vehicle are analyzed to determine if any of these rules overlap with at least one other rule. In some embodiments, rule overlap is determined before rules are transmitted to the vehicle, and transmitting new rules to the vehicle includes information related to overlaps with rules already stored by the vehicle. Analyzing rule overlap before transmitting rules to the vehicle helps minimize the consumption of processing resources within the vehicle.

[0076] By determining whether rules overlap, Method 500 helps improve the efficiency of data collection, data processing, and data storage consumption. By storing only a set of data that at least partially satisfies multiple rules, the efficient use of memory within the vehicle is improved. Furthermore, data processing on individual sets of collected data (e.g., removing data with privacy concerns) reduces the processing load on the vehicle. As a result, the vehicle can satisfy rules faster; and the number of rules processed is increased by improving the efficiency of resources within the vehicle.

[0077] In response to determining that rule overlap exists, method 500 proceeds to operation 517. In response to determining that no rule overlap exists, method 500 proceeds to operation 520.

[0078] In operation 517, the priority of each overlapping rule in the overlapping rules is adjusted for data collection. In some embodiments, the priority of a rule is determined based on at least one of the following: rule type (e.g., security device, entertainment, etc.), user identity (e.g., police, insurance company, application creator, etc.), fee paid by the user, or other suitable criteria. Operation 517 further adjusts the priority of rules that overlap with at least one other rule. Operation 517 adjusts the priority of all overlapping rules to increase the priority of overlapping rules. By increasing the priority of overlapping rules, operation 517 helps method 500 satisfy as many rules as possible. For example, in the case where resources are insufficient to start all rules associated with a detected triggering event, an attempt is made to start the rule with the highest priority before the rule with the lower priority. By increasing the priority of overlapping rules, the ability to satisfy multiple rules by consuming fewer resources (e.g., processing and memory) of the vehicle will allow more rules to be started. In some instances, by starting overlapping rules before other rules, method 500 is actually able to start all rules because less resources are consumed than initially expected.

[0079] In some embodiments, the priority of overlapping rules is increased by a predetermined amount (e.g., one priority level), regardless of the number of overlapping rules in any group. In some embodiments, the priority of a rule increases as the number of overlapping rules within a group increases. For example, in some embodiments, if fewer than five rules overlap, the rule increases by one priority level; however, if the number of overlapping rules is five or more, the rule increases by two priority levels. In some embodiments, the increase in priority level is associated with the resource consumption associated with the overlapping rule. For example, in some embodiments, the priority adjustment amount increases as the amount of resources saved by joint data collection or joint data processing increases.

[0080] In some embodiments, the priority level of all overlapping rules is set to the highest priority level in the overlapping group. In some embodiments, overlapping rules are maintained at their respective priority levels adjusted by operation 517.

[0081] In some embodiments, the priority level of the rules is based on the developer of the vehicle system (e.g., the vehicle system 410). Figure 4Priority levels are set according to different levels determined by [the relevant authority / entity]. For example, in some embodiments, priority levels are set as low, medium, high, critical, and essential. Those skilled in the art will recognize that the labels for different priority levels are merely exemplary, and the current description is not limited to these levels. In some embodiments, the priority level of a rule is a score, for example, a score ranging from 1 to 100. In some embodiments, the score of the priority level is determined based on the factors discussed above regarding priority considerations. Operation 517 can adjust the priority of rules based on any priority algorithm used by the vehicle system.

[0082] In some embodiments, operation 517 is omitted where the vehicle system developer does not seek to adjust rule priority levels based on rule overlap. In such embodiments, method 500 proceeds from operation 515 to operation 520 regardless of the determination in operation 515.

[0083] In operation 520, a rule-based determination is made regarding what sensor information should be collected. The rules stored in the vehicle's memory include information related to the type of sensor data and the time period for which the sensor data will be collected. In some embodiments, the collected data is cropped or processed to reduce or remove irrelevant data.

[0084] In operation 525, the collected data is stored. In some embodiments, the collected data is stored in memory. In some embodiments, the collected data is stored in association with timestamp information about when the data was collected or when the triggering event occurred. In some embodiments, a log collector 434 is used. Figure 4 ) to store the collected data.

[0085] In operation 530, the stored data is transferred to server 440. In some embodiments, the stored data is transferred wirelessly. In some embodiments, the stored data is transferred via a wired connection. In some embodiments, a log transmitter 436 is used. Figure 4 ) to transmit stored data.

[0086] In operation 535, the transmitted data is received by server 440. In some embodiments, the data is received by log data receiver 442. Figure 4 Receive data. In some embodiments, the received data is stored in memory on server 440. In some embodiments, the received data is stored in a priority queue on server 440.

[0087] In operation 540, the received data is encoded. In some embodiments, the received data is encoded according to a predetermined encoding protocol. In some embodiments, the received data is encoded according to a standard determined by rules associated with the received data. In some embodiments, the received data is encoded based on the type of received data. In some embodiments, the data is encoded according to the priority of data in a priority queue. In some embodiments, the encoded data is stored in memory on server 440. In some embodiments, the encoded data is stored in memory in a priority queue on server 440. In some embodiments, operation 540 is omitted and the received data is not encoded.

[0088] In operation 545, the encoded data is transmitted to user terminal 460. In some embodiments, the encoded data is transmitted wirelessly. In some embodiments, the encoded data is transmitted via a wired connection. In some embodiments, the encoded data is transmitted according to its priority in a priority queue. In some embodiments, the encoded data is transmitted by log transmitter 446 ( Figure 4 Transmit encoded data.

[0089] In operation 550, encoded data is received. In some embodiments, the encoded data is received by user terminal 460 ( Figure 4 ) Received. In some embodiments, the received data is stored in the user terminal 460 before decoding. Figure 4 In some embodiments, the received data is stored in the memory of the user terminal 460. Figure 4 In the priority queue on ).

[0090] In operation 555, the data is decoded. In some embodiments, the data is decoded according to a predetermined decoding protocol. In some embodiments, the data is decoded based on encoding protocol information received from server 440 along with the data. In some embodiments, the data is decoded according to the type of the received data. In some embodiments, the data is decoded based on priority in a priority queue. In some embodiments, the decoded data is stored in user terminal 460. Figure 4 In some embodiments, the decoded data is stored in the memory of the user terminal 460 in a priority queue. Figure 4 In the memory of ).

[0091] In operation 560, the decoded data is visualized. Visualizing the decoded data provides a visual representation of the data. In some embodiments, the visual representation includes images of the data from the vehicle. In some embodiments, the visual representation includes icons representing the data from the vehicle. In some embodiments, the visual representation includes a data table. In some embodiments, the visual representation includes text, such as JSON text. In some embodiments, the visual representation includes the location of detected triggering events on a map. In some embodiments, user terminal 460 ( Figure 4 This allows for the visualization of decoded data.

[0092] In operation 565, visualized data is presented to the user. In some embodiments, a UI (e.g., UI 110) is used. Figure 1 The notification is used to notify the user. In some embodiments, a mobile device accessible to the occupant is used to notify the user. In some embodiments, the notification includes an audio or visual alarm. In some embodiments, the notification is configured to automatically generate an alarm on a mobile device accessible to the user.

[0093] Those skilled in the art will understand that modifications to method 500 are within the scope of this specification. In some embodiments, method 500 includes at least one additional operation. For example, in some embodiments, method 500 further includes receiving confirmation of a triggering event from a vehicle occupant. In some embodiments, at least one operation in method 500 is excluded. For example, in some embodiments, operation 540 is excluded and data is provided to user terminal 460 without encoding the data. In some embodiments, the order of operations of method 500 is adjusted. For example, in some embodiments, operation 525 occurs before determining whether a triggering event has been detected to help preserve sensor data. Those skilled in the art will understand that other modifications to method 500 are also within the scope of this specification.

[0094] Figure 6 This is a flowchart of a method 600 for collecting data using an in-vehicle system according to some embodiments. In some embodiments, method 600 comprises method 500 ( Figure 5 Operations 515 and 520 are implemented. In some embodiments, method 600 is implemented by situation detector 422 ( Figure 4 In some embodiments, method 600 uses request retrieval system 100 (…). Figure 1 ) or request retrieval from the 400 ( Figure 4 In some embodiments, method 600 uses a different system than the request retrieval system 100. Figure 1 ) or request retrieval from the 400 ( Figure 4 This is implemented using a system. Method 600 can be used to determine whether rules overlap and whether to adjust the priority of overlapping rules.

[0095] In operation 605, data collection for a rule stored in the vehicle's memory is checked. In some embodiments, operation 605 is omitted, and the data collection for the rule is checked before the rule is transmitted to the vehicle. Checking the data collection for a rule stored in the vehicle's memory includes: determining what data to collect for each rule instruction in response to detecting a trigger event associated with the rule. The check includes an identifier of the type of sensor data (such as image data, vehicle operation data, vehicle position data, etc.) and the duration of sensor data collection. The duration of sensor data includes the time period from the start to the end of data collection. In some embodiments, the duration includes the time period prior to the detection of the trigger event. In some embodiments, data can be retrieved from temporary storage within the vehicle to collect data captured prior to the detection of a trigger event initiating a request for data in the temporary storage.

[0096] In operation 610, data collection information is compiled in association with corresponding rules. The compiled information associated with the corresponding rules helps identify identical or similar data collection requests to determine if the rules overlap. In some embodiments, the compiled data collection information is stored in onboard memory. In some embodiments, operation 610 is integrated with operation 615.

[0097] In operation 615, a determination is made regarding whether there is any rule overlap. Rule overlap means that at least a portion of the requested data collection for the first rule matches at least a portion of the requested data collection for the second rule. Examples of overlapping rules are as described above and will not be repeated here for the sake of brevity. Those skilled in the art will recognize that, according to some embodiments of this specification, other arrangements of sensors and data collection durations also conform to overlapping rules.

[0098] In some embodiments, the triggering event for the first rule is related to, but not entirely equivalent to, the triggering event for the second rule, as discussed above. In response to determining that the triggering events are related, operation 615 treats the two rules as having the same triggering event for the purpose of determining whether the rules overlap. This does not mean that if the second triggering event is met, the first rule will be activated even if the first triggering event is not met. Rather, it simply means that the rules are considered overlapping for the purpose of adjusting rule priority or increasing the efficiency of vehicle memory usage.

[0099] The above description includes an example where two rules are used to determine rule overlap. Those skilled in the art will recognize that more than two rules can also overlap. In some embodiments, all rules stored in a database within the vehicle are analyzed to determine if any of these rules overlap with at least one other rule. In some embodiments, rule overlap is determined before rules are transmitted to the vehicle, and transmitting new rules to the vehicle includes information related to overlaps with rules already stored by the vehicle. Analyzing rule overlap before transmitting rules to the vehicle helps minimize the consumption of processing resources within the vehicle.

[0100] By determining whether rules overlap, Method 600 helps improve the efficiency of data collection, data processing, and data storage. By storing only a set of data that at least partially satisfies multiple rules, the efficient use of memory within the vehicle is improved. Furthermore, data processing on individual sets of collected data (e.g., removing data with privacy concerns) reduces the processing load on the vehicle. As a result, the vehicle can satisfy rules more quickly; and the number of rules processed is increased by improving the efficiency of resources within the vehicle.

[0101] In response to determining that rule overlap exists, method 600 proceeds to operation 620. In response to determining that no rule overlap exists, method 600 proceeds to operation 625.

[0102] In operation 620, the priority of each overlapping rule in the overlapping rules is adjusted for data collection. In some embodiments, the priority of a rule is determined based on at least one of the following: rule type (e.g., security device, entertainment, etc.), user identity (e.g., police, insurance company, application creator, etc.), fee paid by the user, or other suitable criteria. Operation 625 further adjusts the priority of rules that overlap with at least one other rule. Operation 625 adjusts the priority of all overlapping rules to increase the priority of the overlapping rules. By increasing the priority of overlapping rules, operation 625 helps method 600 satisfy as many rules as possible. For example, in the case where resources are insufficient to start all rules associated with a detected triggering event, an attempt is made to start the rule with the highest priority before the rule with the lower priority. By increasing the priority of overlapping rules, the ability to satisfy multiple rules by consuming fewer resources (e.g., processing and memory) of the vehicle will allow more rules to be started. In some instances, by starting overlapping rules before other rules, method 600 is actually able to start all rules because less resources are consumed than initially expected.

[0103] Examples of rule priority levels and increasing rule priority levels are as described above and will not be repeated here for brevity. Those skilled in the art will recognize that other permutations of priority levels and increases in priority levels also exist within some embodiments of this specification. In some embodiments, operation 625 is omitted where the vehicle system developer does not attempt to adjust rule priority levels based on rule overlap. In such embodiments, method 600 proceeds from operation 615 to operation 625 regardless of the determination in operation 615.

[0104] In operation 625, one or more trigger events are detected. Trigger events are detected based on a comparison between data collected by sensors attached to the vehicle and information about rules stored in the vehicle's memory. That is, the rules include information indicating conditions (i.e., trigger events) for which data should be collected. In some embodiments, the data is collected by sensor 414 ( Figure 4 )collect.

[0105] In operation 630, data is collected based on the priority level of the rules associated with the triggering event detected in operation 625. An attempt is made to initiate rules with higher priority levels for data collection before attempting to initiate rules with lower priority levels. In some embodiments including operation 620, the updated priority levels are used to determine which rules are attempted to be initiated during operation 630. In some embodiments, operation 630 initiates multiple rules. In some embodiments, operation 630 initiates a single rule. The collected data is stored, at least temporarily, in the vehicle's memory. In some embodiments, the collected data is processed before being stored in the vehicle's memory, such as encoding, removing privacy information, or other suitable processing.

[0106] In operation 630, data collection for overlapping rules is limited to generating a single copy of the data that determines the rules to be overlapping. For example, if a first rule requests data from the first sensor for a period of 10 seconds from the detected trigger event until 5 seconds after the detected trigger event, operation 630 will store only one copy of the data from the first sensor for the period from the detected trigger event until 5 seconds after the detected trigger event. By storing a single copy of the overlapping data collection requests, the vehicle can improve the efficiency of data collection or processing, and the vehicle can reliably satisfy more rules.

[0107] In operation 635, the collected data is transmitted to a server (e.g., server 440). Figure 4 )) or user terminal (e.g., user terminal 460 ( Figure 4In some embodiments, the stored data is transmitted wirelessly. In some embodiments, the stored data is transmitted via a wired connection. In some embodiments, a log transmitter 436 is used. Figure 4 ) to transmit stored data.

[0108] In operation 640, the vehicle receives a new rule. The new rule is received after compiling the data collection associated with the corresponding rule. In some embodiments, the new rule is received wirelessly. In some embodiments, the new rule is received via a wired connection.

[0109] In operation 645, data collection for the new rule is determined. In some embodiments, data collection for the new rule is determined in a manner similar to that described above with respect to operation 605. In some embodiments, data collection for the new rule is determined based on a comparison between the new rule and data in the compiled data collection request. After operation 645, method 600 proceeds to operation 610, and the compiled data collection request is updated based on the new rule.

[0110] Those skilled in the art will understand that modifications to method 600 are within the scope of this specification. In some embodiments, method 600 includes at least one additional operation. For example, in some embodiments, method 600 further includes sending data to a user terminal (e.g., user terminal 460). Figure 4 The transmission detects a triggering event. In some embodiments, at least one operation in method 600 is excluded. For example, in some embodiments, operation 620 is excluded without seeking an adjustment of priority level. In some embodiments, the order of operations in method 600 is adjusted. For example, in some embodiments, operation 615 occurs simultaneously with operation 610. Those skilled in the art will understand that other modifications to method 600 are also within the scope of this specification.

[0111] Figure 7This is a diagram of a system 700 for implementing a request retrieval system according to some embodiments. System 700 includes a hardware processor 702 and a non-transitory computer-readable storage medium 704 encoded (i.e., storing) computer program code 706 (i.e., a set of executable instructions). The computer-readable storage medium 704 also encodes instructions 707 for interfacing with external devices. Processor 702 is electrically coupled to computer-readable storage medium 704 via bus 708. Processor 702 is also electrically coupled to I / O interface 710 via bus 708. Network interface 712 is also electrically connected to processor 702 via bus 708. Network interface 712 is connected to network 714, enabling processor 702 and computer-readable storage medium 704 to be connected to external components via network 714. Processor 702 is configured to execute the computer program code 706 encoded in computer-readable storage medium 704, so that system 700 can be used to perform operations such as those in request retrieval system 100. Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6 Some or all of the operations described in ).

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

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

[0114] In some embodiments, storage medium 704 is configured to cause system 700 to perform actions such as when requesting retrieval from system 100. Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6 Computer program code 706, comprising some or all of the operations described in the request retrieval system 100. In some embodiments, storage medium 704 also stores computer program code 706 for performing operations as described in the request retrieval system 100. Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6 Information required for some or all of the operations described in the document, and information required for the execution of the request retrieval system 100. Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6 Information generated during some or all of the operations described in the document, such as sensor data parameter 716, rule parameter 718, collected data parameter 720, priority data parameter 722, and / or used in requests for retrieval by system 100 ( Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6 A set of executable instructions that comprise some or all of the operations described in ().

[0115] In some embodiments, storage medium 704 stores instructions 707 for interfacing with a manufacturing machine. Instructions 707 enable processor 702 to generate manufacturing instructions that can be read by the manufacturing machine to efficiently implement method 400 during the manufacturing process.

[0116] System 700 includes an I / O interface 710. The I / O interface 710 is coupled to external circuitry. In some embodiments, the I / O interface 710 includes a keyboard, keypad, mouse, trackball, trackpad, and / or cursor arrow keys for communicating information and commands to processor 702.

[0117] System 700 also includes a network interface 712 coupled to processor 702. Network interface 712 allows system 700 to communicate with network 714, to which one or more other computer systems are connected. Network interface 712 includes a wireless network interface such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA; or a wired network interface such as ETHERNET, USB, or IEEE-1394. In some embodiments, such as when requesting retrieval from system 100 (… Figure 1 ), request retrieval system 400 ( Figure 4 Method 500 Figure 5 ) or method 600 ( Figure 6Some or all of the operations described in the document are implemented in two or more systems 700, and information such as priority level, query ID, query status and query data are exchanged between different systems 700 via network 714.

[0118] Supplementary Note 1

[0119] A method for collecting vehicle-mounted data, the method comprising: determining whether a first rule among a plurality of rules overlaps with any other rule among the plurality of rules. The method further comprises: identifying overlapping data collection data in response to determining that the first rule overlaps with at least one other rule among the plurality of rules. The method further comprises: collecting data associated with the first rule in response to detecting a triggering event. The method further comprises: storing a single copy of the overlapping data collection data, regardless of the number of rules among the plurality of rules that overlap with the first rule.

[0120] Supplementary Note 2

[0121] As in Supplementary Explanation 1, determining whether a first rule overlaps with any other rule among the plurality of rules includes: identifying data collection information for the first rule, wherein the data collection information includes a first sensor and a first duration; and determining that the first rule overlaps with the at least one rule among the plurality of rules in response to determining that at least one rule among the plurality of rules includes data collection information including a first sensor and a time period at least partially matching the first duration.

[0122] Supplementary Note 3

[0123] As in Supplementary Explanation 2, the first duration is a time period set relative to the triggering event.

[0124] Supplementary Note 4

[0125] The method, as further described in any of 1 to 3, includes: adjusting the priority level of the first rule in response to determining that the first rule overlaps with at least one other rule among the plurality of rules, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

[0126] Supplementary Note 5

[0127] As in Supplementary Explanation 4, adjusting the priority level of the first rule includes: adjusting the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

[0128] Supplementary Note 6

[0129] The method, as described in any of Supplementary Explanation 1 to 5, further includes: in response to determining that the first rule overlaps with at least one other rule among the plurality of rules, adjusting the priority level of each rule among the plurality of rules that overlaps with the first rule, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

[0130] Supplementary Note 7

[0131] As in Supplementary Explanation 6, adjusting the priority level of each rule that overlaps with the first rule among the plurality of rules includes: making the priority level of the first rule equal to the priority level of each rule that overlaps with the first rule among the plurality of rules.

[0132] Supplementary Note 8

[0133] A system for onboard data collection includes: a non-transitory computer-readable medium configured to store instructions thereon; and a processor connected to the non-transitory computer-readable medium. The processor is configured to execute instructions for: determining whether a first rule among a plurality of rules overlaps with any other rule among the plurality of rules; identifying overlapping data collection data in response to determining that the first rule overlaps with at least one other rule among the plurality of rules; collecting data associated with the first rule in response to detecting a triggering event; and storing a single copy of the overlapping data collection data in the non-transitory computer-readable medium, regardless of the number of rules among the plurality of rules that overlap with the first rule.

[0134] Supplementary Note 9

[0135] As in Supplementary Note 8, the system wherein the processor is further configured to execute instructions for: identifying data collection information for a first rule, wherein the data collection information includes a first sensor and a first duration; and determining, in response to determining that at least one of the plurality of rules includes data collection information comprising a first sensor and a time period at least partially matching the first duration, that the first rule overlaps with the at least one of the plurality of rules.

[0136] Supplementary Note 10

[0137] As in the system described in Supplementary Note 9, the first duration is a time period set relative to the triggering event.

[0138] Supplementary Note 11

[0139] As in any of Supplementary Descriptions 8 to 10, in a system wherein the processor is configured to execute instructions for: adjusting the priority level of the first rule in response to determining that the first rule overlaps with at least one other rule among the plurality of rules, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

[0140] Supplementary Note 12

[0141] As in Supplementary Note 11, in a system where the processor is further configured to execute instructions for: adjusting the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

[0142] Supplementary Note 13

[0143] The system of any one of Supplementary Descriptions 8 to 12, wherein the processor is further configured to execute instructions for: adjusting the priority level of each rule among the plurality of rules that overlaps with the first rule in response to determining that the first rule overlaps with at least one other rule among the plurality of rules, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

[0144] Supplementary Note 14

[0145] As in the system described in Supplementary Note 13, the processor is further configured to execute instructions for: making the priority level of the first rule equal to the priority level of each of the plurality of rules that overlaps with the first rule.

[0146] Supplementary Note 15

[0147] A non-transitory computer-readable medium configured to store instructions thereon for causing a processor to perform operations including: determining whether a first rule among a plurality of rules overlaps with any other rule among the plurality of rules; identifying overlapping data collection data in response to determining that the first rule overlaps with at least one other rule among the plurality of rules; collecting data associated with the first rule in response to detecting a triggering event; and storing a single copy of the overlapping data collection data, regardless of the number of rules among the plurality of rules that overlap with the first rule.

[0148] Supplementary Note 16

[0149] As in Supplementary Note 15, in a non-transitory computer-readable medium, determining whether a first rule overlaps with any other rule among the plurality of rules includes: identifying data collection information for the first rule, wherein the data collection information includes a first sensor and a first duration; and determining that the first rule overlaps with at least one rule among the plurality of rules in response to determining that at least one rule among the plurality of rules includes data collection information including a first sensor and a time period at least partially matching the first duration.

[0150] Supplementary Note 17

[0151] As in Supplementary Note 15 or 16, in a non-transitory computer-readable medium, instructions are used to cause a processor to perform operations including: adjusting the priority level of a first rule in response to determining that a first rule overlaps with at least one other rule among a plurality of rules, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

[0152] Supplementary Note 18

[0153] As in Supplementary Note 17, in a non-transitory computer-readable medium, adjusting the priority level of the first rule includes adjusting the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

[0154] Supplementary Note 19

[0155] As described in any of Supplementary Notes 15 to 18, in a non-transitory computer-readable medium, the instructions are configured to cause a processor to perform the following operations: in response to determining that a first rule overlaps with at least one other rule among the plurality of rules, adjusting the priority level of each rule among the plurality of rules that overlaps with the first rule, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

[0156] Supplementary Note 20

[0157] As in Supplementary Note 19, in a non-transitory computer-readable medium, adjusting the priority level of each rule that overlaps with the first rule among the plurality of rules includes: making the priority level of the first rule equal to the priority level of each rule that overlaps with the first rule among the plurality of rules.

[0158] The foregoing has outlined features of several embodiments to enable those skilled in the art to better understand various aspects of this disclosure. Those skilled in the art should understand that they can readily use this disclosure as the basis for designing or modifying other processes and structures to achieve the same objectives and / or attain the same advantages of the embodiments described herein. Those skilled in the art should also recognize that such equivalent structures do not depart from the spirit and scope of this disclosure, and that various changes, substitutions, and modifications can be made to this document without departing from its spirit and scope.

Claims

1. A method for collecting vehicle-mounted data, the method comprising: Receive multiple rules, each of which is associated with a triggering event and includes data collection information; Determining whether a first rule among the plurality of rules overlaps with any other rule among the plurality of rules includes: Identify data collection information for the first rule, wherein the data collection information includes a first sensor and a first duration; and In response to determining that at least one other rule among the plurality of rules includes data collection information comprising the first sensor and a time period at least partially matching the first duration, it is determined that the first rule overlaps with at least one other rule among the plurality of rules; In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, overlapping data is identified and collected. In response to detecting a trigger event associated with the first rule, data associated with the first rule is collected; and Store a single copy of the overlapping data collection data, regardless of the number of rules that overlap with the first rule among the plurality of rules.

2. The method according to claim 1, wherein, The first duration is a time period set relative to the triggering event.

3. The method according to claim 1, further comprising: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of the first rule is adjusted, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

4. The method according to claim 3, wherein, Adjusting the priority level of the first rule includes: adjusting the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

5. The method according to any one of claims 1 to 4, further comprising: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of each rule among the plurality of rules that overlaps with the first rule is adjusted, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

6. The method according to claim 5, wherein, Adjusting the priority level of each rule that overlaps with the first rule among the plurality of rules includes: making the priority level of the first rule equal to the priority level of each rule that overlaps with the first rule among the plurality of rules.

7. A system for collecting vehicle-mounted data, the system comprising: A non-transitory computer-readable medium configured to store instructions thereon; as well as A processor connected to the non-transitory computer-readable medium, wherein the processor is configured to execute the instructions for: Receive multiple rules, each of which is associated with a triggering event and includes data collection information; Determining whether a first rule among the plurality of rules overlaps with any other rule among the plurality of rules includes: Identify data collection information for the first rule, wherein the data collection information includes a first sensor and a first duration; and In response to determining that at least one other rule among the plurality of rules includes data collection information comprising the first sensor and a time period at least partially matching the first duration, it is determined that the first rule overlaps with at least one other rule among the plurality of rules; In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, overlapping data is identified and collected. In response to detecting a trigger event associated with the first rule, data associated with the first rule is collected; and A single copy of the overlapping data collection data is stored in the non-transitory computer-readable medium, regardless of the number of rules that overlap with the first rule among the plurality of rules.

8. The system according to claim 7, wherein, The first duration is a time period set relative to the triggering event.

9. The system according to claim 7, wherein, The processor is configured to execute the instructions for: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of the first rule is adjusted, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

10. The system according to claim 9, wherein, The processor is also configured to execute the instructions to: adjust the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

11. The system according to any one of claims 7 to 10, wherein, The processor is also configured to execute the instructions for: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of each rule among the plurality of rules that overlaps with the first rule is adjusted, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

12. The system according to claim 11, wherein, The processor is further configured to execute the instructions for: making the priority level of the first rule equal to the priority level of each of the plurality of rules that overlaps with the first rule.

13. A non-transitory computer-readable medium configured to store instructions thereon, the instructions being used to cause a processor to perform operations including: Receive multiple rules, each of which is associated with a triggering event and includes data collection information; Determining whether a first rule among the plurality of rules overlaps with any other rule among the plurality of rules includes: Identify data collection information for the first rule, wherein the data collection information includes a first sensor and a first duration; and In response to determining that at least one other rule among the plurality of rules includes data collection information comprising the first sensor and a time period at least partially matching the first duration, it is determined that the first rule overlaps with at least one other rule among the plurality of rules; In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, overlapping data is identified and collected. In response to detecting a trigger event associated with the first rule, data associated with the first rule is collected; and Store a single copy of the overlapping data collection data, regardless of the number of rules that overlap with the first rule among the plurality of rules.

14. The non-transitory computer-readable medium according to claim 13, wherein, The instructions are used to cause the processor to perform the following operations: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of the first rule is adjusted, wherein collecting data associated with the first rule includes: collecting data associated with the first rule based on the priority level of the first rule.

15. The non-transitory computer-readable medium according to claim 14, wherein, Adjusting the priority level of the first rule includes: adjusting the priority level of the first rule based on the number of rules that overlap with the first rule among the plurality of rules.

16. The non-transitory computer-readable medium according to any one of claims 13 to 15, wherein, The instructions are used to cause the processor to perform the following operations: In response to determining that the first rule overlaps with at least one other rule among the plurality of rules, the priority level of each rule among the plurality of rules that overlaps with the first rule is adjusted, wherein collecting data associated with each rule among the plurality of rules that overlaps with the first rule includes: collecting data associated with the corresponding rule based on the priority level of the corresponding rule among the plurality of rules that overlaps with the first rule.

17. The non-transitory computer-readable medium according to claim 16, wherein, Adjusting the priority level of each rule that overlaps with the first rule among the plurality of rules includes: making the priority level of the first rule equal to the priority level of each rule that overlaps with the first rule among the plurality of rules.

Images