Camera and sensor data request systems and related methods

Abstract

Described are various embodiments of systems and methods for requesting and receiving sensor data collected by third-party sensor devices, the system comprising one or more servers in network communication with a telecommunications network, the one or more servers comprising access to data storage and a processor; the processor being configured to execute computer-readable instructions stored in the data storage, wherein the computer-readable instructions cause the one or more servers to: release requests over the telecommunications network, readable by third-party devices communicatively connected therewith, for sensor data, wherein the requests are configured to specify request characteristics of the requested sensor data; and receive responses from participating third-party devices with response characteristics permitting such responses, the responses comprising sensor data matching at least some of the characteristics specified in corresponding requests.

Description

CAMERA AND SENSOR DATA REQUEST SYSTEMS AND RELATED METHODSFIELD OF THE DISCLOSURE

[0001] The present disclosure relates to systems and methods for making requests for camera data, and particularly for requesting and receiving camera, sensor, and related data.BACKGROUND

[0002] The ubiquity of network-enabled cameras, and other such sensors, has provided for a wealth of available of image and sensed data. Much of this data, however, rests in the control of the individual owners of the cameras and / or sensors. The existence of useful camera and sensor data is not easily obtained by authorities (e.g. police), insurance companies, or other individuals or entities that may have need of such information. Moreover, the data is highly distributed amongst devices and storage resources that have no association with one another, other than being connected to the Internet. Indeed, some estimates put the number of loT (Internet of Things) devices as approximately 16.7 billion devices in 2023, which is expected to increase to over 29.7 billion by 2027. While highly useful information may exist, identifying and then obtaining relevant data is increasingly difficult.

[0003] Currently, policing and insurance organizations make requests available online to users to upload data that may relate to traffic events or other types of policing events that occurred on specific dates. Users must monitor such requests and then directly communicate with policing organizations to provide the information. Disincentives for such communications are numerous, including a lack of scalability, slow response times, privacy concerns, and an inability to incentivize participation.

[0004] This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art or forms part of the general common knowledge in the relevant art.11428P-FVO-WO01SUMMARY

[0005] The following presents a simplified summary of the general inventive concept(s) described herein to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is not intended to restrict key or critical elements of embodiments of the disclosure or to delineate their scope beyond that which is explicitly or implicitly described by the following description and claims.

[0006] There is provided in some embodiments systems and methods for releasing requests for camera data, sensor data, or other related data, wherein the requests are accompanied by request characteristics and the requests are in accordance with a specific request protocol. Third-party devices can be configured to automatically respond to such requests but generally only if the third- party devices have data that meets the request characteristics and the third-party devices comply with permissions associated with the owner of the third-party devices. In some cases, the permissions can be conditional upon anonymization and / or remuneration. In some cases, the requests can be associated with events that have already occurred or are currently in progress, thus providing requesting entities with valuable insight into how or why something happened at the location or time associated with the request, or can enable live video or image feeds associated with the event in progress. To facilitate efficient searching of locally stored data, third-party devices may generate a unified spatio-temporal index of the sensor data, enabling rapid identification of data matching the request characteristics without exhaustive searching.

[0007] A need exists for making camera and sensory data requests that overcome some of the drawbacks of known techniques for obtaining third party data, or at least, provide a useful alternative thereto. Some aspects of this disclosure provide examples of such data request systems and methods.

[0008] In accordance with one aspect of the disclosure, there is provided a system for requesting and receiving sensor data collected by third-party sensor devices, the system comprising: one or more servers in network communication with a telecommunications network, the one or more servers comprising access to data storage and a processor; the processor being configured to execute computer-readable instructions stored in the data storage, wherein the computer-readable instructions cause the one or more servers to: release requests over the21428P-FVO-WO01telecommunications network, readable by third-party devices communicatively connected therewith, for sensor data, wherein the requests are configured to specify request characteristics of the requested sensor data; and receive responses from participating third-party devices with response characteristics permitting such responses, the responses comprising sensor data matching at least some of the characteristics specified in corresponding requests.

[0009] In one embodiment, the one or more request characteristics comprises at least one of: location data relating to where the sensor data was collected, time data relating to when the sensor data was collected, content data relating to objects represented in the sensor data, or a purpose of the sensor data collection.

[0010] In one embodiment, the participating third-party sensor devices are configured to evaluate the request by querying a locally stored, unified spatio-temporal index of collected sensor data, the index generated by mapping spatio-temporal coordinates of the data to one-dimensional codes.

[0011] In one embodiment, the one-dimensional codes are generated using a space-filling curve.

[0012] In one embodiment, the space-filling curve is a Hilbert space-filling curve.

[0013] In one embodiment, the third-party sensor devices are configured to query the index by performing a binary search on a sorted collection of the one-dimensional codes.

[0014] In one embodiment, the request characteristics include a predefined response format that the third-party sensor devices must adhere to in the responses.

[0015] In one embodiment, the system further comprises a user interface module that allows requestor users to define the specific characteristics of the sensor data to be requested.

[0016] In one embodiment, the user interface module allows users to specify one or more of: a geographical area, a temporal range, content data, or a purpose for the sensor data collection.31428P-FVO-WO01

[0017] In one embodiment, the one or more servers further comprise a remuneration module that transmits remuneration information to third-party sensor devices upon receipt by the one or more servers of a response that matches at least some of the request characteristics.

[0018] In one embodiment, the remuneration module is further configured to initiate a transfer of a stablecoin cryptocurrency from a first digital wallet associated with the requesting entity to a second digital wallet associated with the third-party sensor device.

[0019] In one embodiment, the transfer is automatically executed by a smart contract on a blockchain network upon a data evaluation module verifying that the response meets a predefined data quality threshold.

[0020] In one embodiment, the response excludes identifying information relating to the third- party sensor devices and corresponding end-users associated therewith.

[0021] In one embodiment, the one or more servers are configured to make available to third- party sensor devices over the telecommunications network, configuration instructions that, once functionally stored on the third-party sensor devices, render participating third-party sensor devices responsive to requests based on one or more response characteristics.

[0022] In one embodiment, the configuration instructions render participating third-party sensor devices automatically responsive to requests.

[0023] In one embodiment, the system further comprises a data evaluation module configured to filter the responses based on data quality.

[0024] In one embodiment, the one or more servers are configured to handle secure data transmissions to and from the third-party sensor devices, and to and from requesting entities.

[0025] In one embodiment, the one or more servers are configured to support encrypted communication protocols.

[0026] In one embodiment, the system further comprises a consent management module that tracks and manages permissions of third-party sensor device end-users for providing the sensor data collected.41428P-FVO-WO01

[0027] In one embodiment, the consent management module provides a mechanism for endusers of third-party sensor devices to at least one of provide, withdraw, or modify their permissions.

[0028] In one embodiment, the one or more servers are configured to send periodic or event- driven requests for specific types of sensor data.

[0029] In one embodiment, the response is provided to requesting entities in real-time.

[0030] In one embodiment, the system further comprises a data aggregation module configured to aggregate and process the collected data received from multiple third-party sensor devices relating to the same request.

[0031] In one embodiment, the one or more servers comprise virtual servers integrated into a cloud-based platform accessible via the Internet.

[0032] In one embodiment, releasing a request comprises at least one of a push, a broadcast, or a response to a poll for requests.

[0033] In one embodiment, the third-party sensor devices comprise at least one of a camera, a light sensor, a motion sensor, or other data sensor.

[0034] In accordance with one aspect of the disclosure, there is provided a method for requesting and receiving specific types of sensor data collected by third-party sensor devices, the method comprising: releasing requests from a requesting entity for sensor data to third-party sensor devices, wherein the requests specify characteristics of the requested sensor data comprising location data, time data, and object data, the location data relating to where the sensor data was collected, the time data relating to when the data was collected, and data relating to objects represented in the sensor data; evaluating response data from the third-party sensor devices based on the characteristics specified in the requests; and forwarding the response data from the third- party sensor devices, whose end-user have granted permission for sending the response data, to the requesting entity.51428P-FVO-WO01

[0035] In one embodiment, the evaluating comprises evaluating the requests by querying a unified spatio-temporal index generated from the collected sensor data by mapping spatiotemporal coordinates of the data to one-dimensional codes.

[0036] In one embodiment, the mapping is performed using a space-filling curve.

[0037] In one embodiment, the space-filling curve is a Hilbert space-filling curve.

[0038] In one embodiment, the method further comprises transmitting remuneration data to third-party sensor devices corresponding with received responses.

[0039] In one embodiment, the transmitting remuneration data comprises initiating a transfer of a stablecoin cryptocurrency from a first digital wallet associated with the requesting entity to a second digital wallet associated with the third-party sensor device.

[0040] In one embodiment, the transfer is automatically executed by a smart contract on a blockchain network upon verifying that the response meets a predefined data quality threshold.

[0041] In one embodiment, the method further comprises removing identifying information relating to an end-user of the third-party sensor devices from the permitted responses before transmission to a requesting entity.

[0042] In one embodiment, the release of requests comprises at least one of a push, a broadcast, or a response to a poll for requests.

[0043] In one embodiment, the third-party sensor devices comprise at least one of a camera, a light sensor, a motion sensor, or other data sensor.

[0044] Other aspects, features and / or advantages will become more apparent upon reading of the following non-restrictive description of specific embodiments thereof, given by way of example only with reference to the accompanying drawings.BRIEF DESCRIPTION OF THE FIGURES

[0045] Several embodiments of the present disclosure will be provided, by way of examples only, with reference to the appended drawings, wherein:61428P-FVO-WO01

[0046] Figure 1 is a schematic diagram of an exemplary data request system in accordance with at least one embodiment as disclosed herein, as well as devices and third parties interacting therewith;

[0047] Figure 2 is a schematic diagram of a data request system in accordance with another exemplary embodiment as disclosed herein, as well as devices and third parties interacting therewith;

[0048] Figure 3 is a block flow diagram of an exemplary data request method in accordance with at least one embodiment as disclosed herein;

[0049] Figure 4 is a schematic diagram of an exemplary data request system in accordance with at least one embodiment as disclosed herein, as well as devices and third parties interacting therewith;

[0050] Figure 5 is a schematic diagram of another exemplary data request system in accordance with at least one embodiment as disclosed herein, as well as devices and third parties interacting therewith;

[0051] Figure 6 is a block flow diagram of another exemplary data request method in accordance with at least one embodiment as disclosed herein;

[0052] Figure 7 is a block flow diagram of one aspect of at least one embodiment of the data request method as disclosed herein; and

[0053] Figure 8 is a block flow diagram of one aspect of at least one embodiment of the remuneration method as disclosed herein.

[0054] Elements in the several figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be emphasized relative to other elements for facilitating understanding of the various presently disclosed embodiments. Also, common, but well-understood elements that are useful or necessary in commercially feasible embodiments are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure.71428P-FVO-WO01DETAILED DESCRIPTION

[0055] Various implementations and aspects of the specification will be described with reference to details discussed below. The following description and drawings are illustrative of the specification and are not to be construed as limiting the specification. Numerous specific details are described to provide a thorough understanding of various implementations of the present specification. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of implementations of the present specification.

[0056] Various implementations and aspects of the specification will be described with reference to details discussed below. The following description and drawings are illustrative of the specification and are not to be construed as limiting the specification. Numerous specific details are described to provide a thorough understanding of various implementations of the present specification. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of implementations of the present specification.

[0057] Various apparatuses and processes will be described below to provide examples of implementations of the system disclosed herein. No implementation described below limits any claimed implementation and any claimed implementations may cover processes or apparatuses that differ from those described below. The claimed implementations are not limited to apparatuses or processes having all of the features of any one apparatus or process described below or to features common to multiple or all of the apparatuses or processes described below. It is possible that an apparatus or process described below is not an implementation of any claimed subject matter.

[0058] Furthermore, numerous specific details are set forth in order to provide a thorough understanding of the implementations described herein. However, it will be understood by those skilled in the relevant arts that the implementations described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the implementations described herein.

[0059] In this specification, elements may be described as "configured to" perform one or more functions or "configured for" such functions. In general, an element that is configured to perform81428P-FVO-WO01or configured for performing a function is enabled to perform the function, or is suitable for performing the function, or is adapted to perform the function, or is operable to perform the function, or is otherwise capable of performing the function.

[0060] It is understood that for the purpose of this specification, language of "at least one of X, Y, and Z" and "one or more of X, Y and Z' may be construed as X only, Y only, Z only, or any combination of two or more items X, Y, and Z (e.g., XYZ, XY, YZ, ZZ, and the like). Similar logic may be applied for two or more items in any occurrence of "at least one..." and "one or more..." language.

[0061] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

[0062] Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase "in one of the embodiments" or "in at least one of the various embodiments" as used herein does not necessarily refer to the same embodiment, though it may. Furthermore, the phrase "in another embodiment" or "in some embodiments" as used herein does not necessarily refer to a different embodiment, although it may. Thus, as described below, various embodiments may be readily combined, without departing from the scope or spirit of the innovations disclosed herein.

[0063] In addition, as used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and / or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of "a," "an," and "the" include plural references. The meaning of "in" includes "in" and "on."

[0064] The term “comprising” as used herein will be understood to mean that the list following is non-exhaustive and may or may not include any other additional suitable items, for example one or more further feature(s), component(s) and / or element(s) as appropriate.

[0065] The systems and methods described herein provide, in accordance with different embodiments, different but non-limiting exemplary embodiments of camera and sensor device 91428P-FVO-WO01data request systems and related methods and devices. Embodiments hereof relate to systems comprising one or more servers, such as web servers, that are configured to release camera or sensor requests which relate to a specific time, location, event, or subject matter. The released requests may be pushed or broadcast or sent in response to a poll to participating devices. The participating devices in general comprise a device having installed thereon a local software client, which may be configured to receive the released request. The released requests will comprise at least one request characteristic, generally incorporated as part of a request and in accordance with a request protocol which enables the participated device to identify the existence of the request as well as any associated request characteristics. The participating device and / or software client can read the request characteristic and compare it to any camera or sensor data that is stored in data storage that is accessible to the device. If the participating device has camera or sensor data that complies with the request characteristics, which may include data indicative of time, data indicative of location, and / or data indicative of specific content, the camera data or sensor data can, depending on whether the participating device determines whether the request meets permission requirements, automatically return the camera data or sensor data that complies with the request characteristics to the requesting server. As illustrative examples, the permission requirements may include some of the following: whether or not to respond to a particular requestor, whether or not the requested data is associated with identifying information of the owner of the participating device, and whether or not remuneration will be provided in exchange for responding to the request.

[0066] For example, a requesting police force may wish to release a request for any camera data from any dash cams, doorbell cams, traffic cameras, social media feeds, mobile device cameras, or any third-party network-connected cameras, that may have recorded a particular incident, such as a traffic accident, that may have occurred at a particular location at a particular time and may contain image data therein of particular content (e.g. a white vehicle). The request is created at the server by the requestor; the server releases the request with request characteristics that describe the particular time, location, and / or content. Any participating devices that receive the request automatically determine one or more of the following as a result of the request characteristics: whether device has in accessible storage any camera data that comprises images of the particular location, whether it was captured at the given time, and whether the image data includes the content. If the participating device identifies camera data which meets the101428P-FVO-WO01characteristics associated with the request, such camera data may be communicated automatically to the server in response to the request; in general, however, the participating device will respond if certain permissions are met, including, for example: that owner has agreed to provide responsive data to the requestor in question, and that the responsive camera data does not include any data identifying the responding device or its owner. In some cases, the server, if the requestor agrees to provide remuneration for any responsive camera data, may cause remuneration information to the participating device, which may be used by the participating device to be paid for responding, but without identifying the responder in any way to the requestor. As such, camera data may be automatically requested broadly to any participating third-party devices, while both incentivizing and removing disincentives for such responses. Police forces, insurance companies, investigators, and private individuals can efficiently request and obtain responsive camera or sensor data in respect of a particular event. Any network-enabled participating device may provide data responsive to request, while protecting privacy as required and in some cases receiving remuneration.

[0067] In accordance with various embodiments of video request systems disclosed herein, there is provided a system for enabling entities, organizations, and individuals a means of requesting and receiving camera data collected by third-party camera devices. The system comprises one or more servers which are configured to accept from a requestor a request for data in which the request can be associated with one or more characteristics. The server or servers (referred to as the "server" in this example) may be any server configured to receive and send network communications over a network, such as the Internet; it may comprise a web server, a communications server, as storage server, a proxy server, or virtualized instances of a server, such as in a cloud-based environment. The server is in network communication with a telecommunications network, such as the Internet, and the server will comprise data storage, or alternatively access to data storage, as well as a processor. The processor is configured to execute computer readable instructions stored in the data storage, wherein the instructions cause the one or more servers to carry out the following functions: the server releases requests over the telecommunications network; the requests are recognized and accepted by participating third-party camera devices that are configured for network communication (or other types of participating sensor devices); the requests comprise request characteristics which may be used by the participating third-party camera devices to automatically identify camera data that complies with111428P-FVO-WO01the request; the request further provides response information which may be used to send camera data (or other sensor data) that is responsive to the requests.

[0068] Embodiments hereof release requests in one or more various manners. For example, systems and methods may push requests, through a “Push API” as published by the World Wide Web Consortium; the Push API enables the sending of a push message by a server, including a web server, to a web application, or other software client running on a participating device, including, in some embodiments, when such web application or software client may be inactive. Other push technologies may include APN (Apple push notification service for iOS) or FCM (Firebased Cloud Messaging for Android), as two non-limiting push methodologies known in the art. Once the participating third-party device receives the pushed request, it may respond according. Systems and methods hereof may also broadcast a request to all accessible network nodes, wherein connected participating devices will receive the request. In some embodiments, participating devices regularly or periodically poll the server, for example using an RSS feed technology, to obtain new released requests; for example, it may poll to see all requests released since the last poll.

[0069] Third-party camera or sensor devices may be participating devices if they have installed thereon a software client that has been configured to: accept requests for camera or sensor data from the server; identify the request characteristics, including those which may be required for the software client to consider whether permissions will be complied with should the request be responded to; and to send a response to server from which the request originated. In some embodiments, the software client can accept remuneration or remuneration related information that permits the device or its owner to receive the remuneration. Such installation may occur by requesting the necessary software (e.g. API) from the server or a related system. In some cases, camera device and sensor device manufacturers may pre-install the necessary software client and / or API or similar to render a network connected device as a participating device. In some cases, a third-party device owner may download an app to act as a software client that is configured to receive released camera / sensor data requests. In some cases, the software client is pre-installed on firmware or installed software on a door cam, dash cam, vehicle or non-stationary telematics device. Having an API, app, firmware, or integrated third-party device that can act as a software client for receiving and responding to camera / sensor data requests render a third-party device as a121428P-FVO-WO01participating third-party device. Third-party device owners may access the web server to request software products, including through a SaaS (software-as-a-service) model where third-party devices implement SaaS-based web services on their device (e.g. via a browser or special purpose app or other software product) to appropriately configure the third party device to recognize pushed or broadcast requests or to poll for released requests, identify request characteristics, automatically identify stored camera or sensor data meeting the request characteristics, assess permissions, and response by sending such camera or sensor data in the format indicated by the request to the server as identified in the request.

[0070] In some of the embodiments disclosed herein, released requests are pushed, broadcast, or sent as a result of a polling, over the telecommunications network. The requests, as well as the request characteristics are readable by participating third-party camera devices communicatively connected on the same network. The requests are configured to specify characteristics of the requested camera and / or sensor data. For example, the characteristics may specify a requested time, location, or content information, and also whether and how much remuneration is offered for responses that comply with the request characteristics.

[0071] In some embodiments, the servers are configured to receive responses from participating third-party camera devices with response characteristics permitting such responses, the responses comprising camera data or sensor data the meet at least some of the characteristics specified in corresponding requests. In some embodiments, the server may evaluate a response to confirm that it meets the request characteristics before forwarding same to the requestor and, if applicable, forwarding remuneration or the like to the responder.

[0072] In some embodiments, the requests are triggered by a specific request and applicable request characteristics provided by a requestor in association with an event that has previously occurred. For example, participating third-party devices may respond to released requests by providing video or image data of an accident or similar event that was captured by one or more dash cams in vehicles that happened to be in, or doorbell or security cams, that happened to be directed at, the location of event. In embodiments, a request may trigger a live video feed as a response. In some cases, the occurrence of an event, such as a call to an emergency responder (e.g. 911 may trigger a request for a live video feed that meets the request characteristics).131428P-FVO-WO01

[0073] In some embodiments, requesting entities may post video requests to a camera or sensor data request aggregation service. The data request aggregation service is made available through the server. Such a camera or sensor data request could originate from a user interacting with a website running from the server, when acting as a web server (e.g. https: / / requestvideo.com) or sent via an API that has been acquired by the requesting entity, it or could be automatically extracted, including for example, an Al-based analysis function, by assessing, for example, police or emergency incident posts or activities. For example, a call to a 911 responder in which a location is provided in association with a particular type of request for assistance, either by a caller or automatically by assessing the location of a device, such as a mobile phone, through triangulation of its use of cell antennas / base stations. Once a location has been determined, a requesting entity software client / application and / or API may automatically provide a request to the server, in respect of which, some embodiments may be configured to release a camera / sensor data request automatically. If there is a participating third-party device in the vicinity of the location, and any other characteristics are met (e.g. field of view direction, image quality, remuneration level, etc.) the third-party device permission settings permit it, a live feed of the incident may be acquired via the server (or in some cases a separate server running a data submissions service). If the request is responded to after the fact, the recorded data can nevertheless be uploaded to the server (or in some cases a separate server running a data submissions service) and from which the requestor can access the responsive data.

[0074] In some embodiments, the server provides a camera / sensor data request aggregator service. The data request aggregator service in some embodiments compiles all data requests and makes them available as a feed, in one or more formats: for example, JSON & RSS to be accessible by request feed consumers (which may comprise participating third-party device and / or their owners, operators, or controllers). In embodiments using JSON & RSS, the request feeds may be broadcast or multicast (e.g. IP Multicast Protocol or other broadcast or multicast technologies configured to send a message to multiple destinations) to all available participating third-party devices, pushed via a push API or function to all or specific participating third-party devices, or the feed may be made available upon receiving a poll for requests in the feed from participating third-party devices (e.g. the last specific number of requests, or all requests since the last poll from that participating third-party device).141428P-FVO-WO01

[0075] In embodiments, the participating third-party device may comprise a camera device configured to collect video data or image data (including still image data), including for visible and non-visible light spectrums. In other cases, the participating third-party device may be any network enabled sensor that collects sensor data and is configured to provide such data over a network. For example, the participating third-party device may comprise an loT sensor device. In some embodiments, the participating third-party devices may comprise doorbell cams (e.g. RING™ video doorbell), dash cameras (e.g. aftermarket and installed), sensors and camera devices in telematics devices installed in vehicles or mounted on people or things, traffic cameras and sensors, mobile devices with cameras and telematics sensors, computing devices having access to social media feeds, and security devices including cameras, motion detectors, door / window sensors, etc.). In some cases, third-party manufacturers may pre-install a software client, API, or application to enable a participating device to receive and respond to requests in accordance with the subject matter disclosed herein. In other cases, a software client, API, or application can be made available to third-party devices whose users wish to receive released requests. In some cases, the software client, API, application, or other computer-readable instructions can be made available for download by the server, by the device manufacturer, or by one or more of the requesting entities. In embodiments, third-party device manufacturers can subscribe to a feed of data requests and integrate the feed into their product offering. In general, data requests are assessed and forwarded from the third-party end-user devices locally in a web app, mobile app, or local software client / software application, partly to protect the privacy of the end-users.

[0076] In some embodiments, end-users would be notified from their web or mobile app that they might have data of interest and can decide if they want to provide the video back to the requesting entity; alternatively, they can set their permission settings to allow for the sending of such data automatically. In some embodiments, an end-user could choose to provide the video (or other data) anonymously or not and be compensated for the video (or other data) submission. The end-users privacy would be protected in at least one of the following manners: all identifying data, including metadata, is removed from the response; the response is first sent to the server, in some cases as part of a data submission service running thereon, before the response is forwarded to the requesting entity.151428P-FVO-WO01

[0077] In some embodiments, the one or more request characteristics may comprise a locationindicative characteristic readable by the participating device, which permits the participating device to assess whether camera or sensor data was collected by it, or is otherwise stored in accessible data storage, at or near the location associated with the location-indicative characteristic. It may comprise geofence data, or coordinate information. In some embodiments, the one or more request characteristics may comprise a time-indicative characteristic readable by the participating device, which permits the participating device to assess whether camera or sensor data was collected by it, or is otherwise stored in accessible data storage, during or immediately before or after the time associated with the time-indicative characteristic. Such time-indicative characteristics may be a time value or a time value associated with a period of time, including a start time / date and end time / date. In some embodiments, the one or more request characteristics may comprise a content-indicative characteristic readable by the participating device, which permits the participating device to assess whether camera or sensor data was collected by it, or is otherwise stored in accessible data storage, that contains content related to the content-indicative characteristic. Such time-indicative characteristics may be an image or image data that can be compared to stored image data for similarity (including, for example, using Al, LLM, or a neural net to make such assessment). Other characteristics may include whether identification information of the responder is required, the identity of the requestor, and whether and how much remuneration will be forwarded to the participating device for camera and / or sensor data meeting the request characteristics.

[0078] In some embodiments, to facilitate an efficient assessment of whether stored sensor data corresponds to the location-indicative and time-indicative characteristics of a request, the participating device is configured to generate and maintain a unified spatio-temporal index of its collected data. For sensor data comprising a plurality of spatio-temporal data points (e.g., a video file with associated GPS and timestamp data), a brute-force comparison of each data point against the request characteristics can be computationally expensive and slow, particularly on resource- constrained devices. To overcome this, the participating device may process its sensor data to create a compact index.

[0079] In one implementation, this index is created by treating each data point's location (e.g., latitude and longitude) and time (e.g., a timestamp) as a unified three-dimensional coordinate. A161428P-FVO-WO01space-filling curve, such as a Hilbert curve, is used to map this three-dimensional coordinate to a single one-dimensional value, or code. This process generates a list of codes for the sensor data, which can be stored in a sorted manner. When a request is received, its spatio-temporal characteristics (e.g., a geographic bounding box and a time interval) are also converted into one or more ranges of the one-dimensional codes. The participating device can then perform a highly efficient search, such as a binary search, on its sorted list of codes to determine if it possesses any data within the requested spatio-temporal volume. This method significantly reduces the computational overhead and response time for identifying matching data.

[0080] In some embodiments, the one or more servers of the system have incorporated therewith, or have access to, an Al-based image analysis engine for, without limitation, identifying objects and / or object types captured in video or images from the associated image data, identifying incidents with objects from the associated image data, and searching existing image data relating to previously captured video or images for objects, object types, and incidents that meet certain criteria. In some embodiments, Al-based image analysis engine is configured with a real-time processing pipeline that is configurable to prioritizes speed and / or low-latency analysis, including through the use of machine learning models, neural networks, or similar methodologies, for analyzing video frames and / or image captures within milliseconds of capture and / or receipt of same over the network. This pathway includes immediate preprocessing, rapid object detection and classification, incident pattern recognition, and instant alert generation when specified criteria are met. The system maintains configurable alert thresholds and can simultaneously monitor multiple video sources for different types of objects or incidents. In some embodiments, speed and / or low latency analysis may not be use (or the system may be configurable to deprioritize it), in favour of dedicating processing resources to identification. In some embodiments, parallelized or prioritized processing may provide comprehensive analysis using computationally intensive algorithms that extract detailed metadata, feature analysis, and creation of searchable indexes relating to objects and / or incidents involving objects in the video or images. In some cases, critical alerts can delivered be immediately (or in a timely fashion depending on prioritization of speed of analysis, which may not be required in all cases) while building searchable archives for future analysis. In some embodiments, there is a preprocessing stage that automatically handles various video and image formats, resolutions, and encoding standards, normalizing content for consistent analysis across both pipelines while applying enhancement techniques optimized for different171428P-FVO-WO01lighting conditions and video qualities. In some cases, the Al-based image analysis engine can identify personally identifiable data, such as license plates and faces of individuals, and the preprocessing can obfuscate all such personally identifiable data from the image data; in some cases, the obfuscated data can be stored elsewhere and associated with the obfuscated raw image data in a privacy -protected manner (i.e. to later identify a license plate if needed by, for example, police or insurance companies). In some cases, the level of preprocessing and obfuscation may be determined in accordance in advance by user preferences (e.g. a user may only allow uploading, disclosure of their video, or analysis of their video, if certain privacy protective measures are required or available).

[0081] In some embodiments, there may be provided object identification capabilities using a monitoring functionality associated with the Al-based image analysis engine that continuously analyzing video feeds / image captures provided to the system to identify objects and incidents as they occur, or at least immediately upon acquisition of such video feeds / image, including in realtime or near real-time. For the purposes of this disclosure, “real time” means within a sufficient amount of time to take corrective or mitigative action, which can be different depending on context (e.g. alerts with a few seconds may be required for theft or accident intervention or avoidance, but minutes or even hours may be sufficient to provide notification to send an ambulance or road workers in respect of an road-based incident). In some embodiments, machine learning models process each video frame / image capture within the constraints of real-time performance requirements, including achieving analysis speeds of 30-60 frames per second depending on prioritization of identification analysis, image resolution, network traffic and latency, and computational resources. In embodiments, the detection system maintains persistent object tracking across frames, enabling it to follow objects as they move through the field of view and triggering alerts based on both instantaneous detection, motion analysis of objects, and behavioral patterns over time. The Al-based image analysis engine may comprise, or be associated with a notification generation function that is configured to respond, and trigger alerts on notifications, in response to virtually any combination of object types, spatial locations, temporal patterns, or behavioral / motion characteristics in either or both real-time or during a later analysis of the stored information. Users can define alert criteria ranging from simple object presence notifications to complex multi -condition scenarios involving object interactions, movement patterns, or unusual behaviors. For example, the system can generate immediate alerts when specific vehicle types 181428P-FVO-WO01enter restricted areas, when objects are left unattended in sensitive locations, or when equipment operates outside normal parameters, or when objects or the device capturing the video undergoes a sudden deceleration or acceleration. Notification delivery mechanisms may be configurable and can include real-time notifications through multiple channels such as email, SMS, mobile applications, network communication, or integration with existing security management systems. Notifications may include relevant metadata such as timestamp, location coordinates, confidence levels, and can be accompanied by automatically extracted video clips or still images showing the detected object or incident. The system maintains alert logs and can provide statistical analysis of detection patterns over time.

[0082] In some embodiments, different neural network and / or machine learning model configurations can be prioritized for real-time analysis versus accuracy in archival processing. For example, less resource-intensive convolutional neural networks can be implemented to handle immediate object detection and classification for alert generation, while more comprehensive models perform detailed analysis for archival indexing and / or later analysis and searching. In some embodiments, Al-based image analysis engine recognizes objects and object types through hierarchical classification, initially detecting broad object categories before applying specialized models for granular identification. In some embodiment, the Al-based image analysis engine prioritizes rapid classification of alert-relevant objects, while deferring for later analysis exhaustive analysis to extract detailed attributes such as color, size, brand markings, license plates, or unique identifying features when visible. In some embodiments, the latter detailed analysis is prioritized and real-time alert generation is deprioritized or not available; in some of the foregoing cases, prioritizations therebetween are available on a configurable basis.

[0083] Embodiments of the Al-based image analysis engine may include specialized models trained for specific domains such as vehicles, people, industrial equipment, animals, or custom object types relevant to particular applications. These models can be continuously updated and retrained based on new data or changing requirements, ensuring that detection accuracy improves over time and adapts to evolving monitoring needs.

[0084] Embodiments of the Al-based image analysis engine provide Al-based search functionality, including, in some cases, that operate seamlessly alongside real-time monitoring,191428P-FVO-WO01providing access to comprehensive archives of analyzed video data from video and image captures. The system maintains detailed historical records of all detected objects, incidents, and temporal patterns, enabling complex queries that can combine multiple criteria and contextual information. Users can search for objects based on visual characteristics, temporal patterns, spatial relationships, behavioral attributes, or any combination of these factors. Search capabilities may include object and object type matching, as well as queries such as "red vehicles moving faster than normal between 2 PM and 4 PM in the northeast section during the past month" or "people carrying large obj ects near the main entrance after hours in the week following security incidents. " The system supports fuzzy matching and similarity -based searches, allowing users to find objects or incidents similar to reference examples even when exact matches may not be available. In some cases, embodiments of the Al-based image analysis engine comprise large language model analysis.

[0085] In some embodiments of the Al-based image analysis engine, there is provided machine learning algorithms that use existing learning sets, comprising historic data, to develop recognition models. In some embodiments, existing learning sets can be added to, including from both realtime detections and user search patterns associated with the Al-based image analysis engine, thus refining both immediate alert accuracy and historical search results based on user feedback and validation of alert relevance. This learning capability ensures that the system becomes increasingly accurate and useful over time, adapting to the specific needs and patterns of each deployment environment.

[0086] In some embodiments, there is provided metadata extraction, including both in realtime as well as from post-collection analysis, creating searchable indexes that include object characteristics, which may include object classifications, temporal coordinates, spatial locations, movement vectors, size estimations, color profiles, confidence scores, and contextual environmental information. Metadata enables search across large datasets while minimizing the need to process existing raw video during queries. Such metadata extraction may create multiple searchable dimensions to facilitate searches across years of archived footage and return results in real or near real time.201428P-FVO-WO01

[0087] In some embodiments, the requests are sent in a predefined format, and may require a predefined response format that the third-party camera devices must adhere to in their responses. In such cases, the requests, responses, and request characteristics are in a standardized format (e.g. JSON). In embodiments, the request comprises at least some of the following characteristics: date and time window, a location indictor (e.g. a geofence), an orientation relating to the field of few or area of interest relating to the where the data was collected from, a reason for the data request (e.g. a car accident or a crime had taken place at the location), and the requesting entity or the nature or type of entity (e.g. researcher or police service or insurance company).

[0088] In some cases, the server makes available, either through a web interface, accessible by using a browser, or though downloading a request access API or app, a requestor interface module that allows requestor requestors to define the specific characteristics of the sensed data that is to be requested. In such requestor interface, a requestor may, for example, specify the time, location, and content associated with a data request. It may also specify a remuneration amount associated with successful camera or sensor data acquisition, where success may include meeting at least one of the associated request characteristics.

[0089] In some embodiments, the predefined response format does not permit inclusion of any identifying information that identifies responding third-party camera devices or corresponding individuals or owners associated therewith. In some embodiments, the server may be configured to remove identifying information from responsive camera / sensor data and / or the server acts as an intermediary to disintermediate the requestor from the responder, thus keeping the identity of the responder unknown to the requestor.

[0090] In embodiments, the server may comprise a response evaluation module which assesses response data for quality, reliability, and sufficiently responsive content. Partial remuneration or no remuneration may be sent if the response data has reduced informational value relating to the event in question or poor quality.

[0091] In some embodiments, the remuneration module may be implemented using blockchain technology to enhance automation, security, and user privacy. Upon the response evaluation module confirming that received sensor data meets the required quality and responsiveness criteria, the remuneration module may be configured to automatically trigger a smart contract on a211428P-FVO-WO01blockchain network. This smart contract executes a trustless payment from the requesting entity to the end-user of the participating third-party device. The payment may be in the form of a stablecoin cryptocurrency (e.g., USDC, USDT) transferred from a digital wallet associated with the requester to a digital wallet associated with the end-user. This method provides for instant, automated, and low-cost settlement of remuneration, which is particularly advantageous for micropayments. Furthermore, it enhances the privacy of the end-user, as the transaction is pseudonymous and does not require the sharing of traditional banking information.

[0092] In embodiments, the server encrypts the requests and the participating third-party devices are configured to respond by sending the responses in an encryption that can be decrypted by the server. In embodiments, requests and responses are communicated over secure transmissions, such as a secure data tunnel or virtual private networks. Such encryption and / or secure transmission may be implemented specifically to avoid unauthorized identification of responders or requestors, or use or access of request or response data.

[0093] In some embodiments, the server may comprise instructions for instantiating a consent management module on the server that tracks and manages the consent of third-party camera or sensor device owners for providing the collected data. The consent may be rendered conditional on any request characteristic or other information associated with a request. This permits a participating device to automatically respond with camera or sensor data automatically if (a) there is data responsive to the request in accessible storage or that is being collected or has previously been collected by the device; and (b) the permissions allow for a response based on one or more of the request characteristics, the requestor, or the discretion of the end-user of the participating device. The server may implement such consent module via a SaaS or web-based application, and render such module via a distributed API, wherein access to the consent module thereby allows the owner of a third-party camera or sensor device to create, change, or withdraw their permission settings at any time.

[0094] In some embodiments, multiple requests may be received from unrelated or different third-party devices. In such cases, where all of the requests meet at least some of the request characteristics, the responses may be integrated or indexed together so as to provide multiple sets221428P-FVO-WO01of related camera or sensor data, that can later be identified as being associated with the event relating to the requested data (or at least with each other).

[0095] In some embodiments, the one or more servers comprise virtual servers distributed across multiple network-enabled server or data storage systems, such as AWS. Embodiments as disclosed herein may provide for the server to be integrated into a cloud-based platform accessible via the Internet.

[0096] Turning now the figures, various embodiments will be described in more detail, below.

[0097] With reference to Figure 1, and in accordance with one exemplary embodiment, a sensor data request system, generally referred to using the numeral 100, will now be described. The sensor data request system 100 comprises one or more end-users, operators and / or controllers 130. In some embodiments, the end-users 130 engage services such as those provided, for example, by a door camera company 120a, a security camera company 120b, a vehicle camera monitoring company 120c, or a mobile application that enables video storage and posting 120d. The sensor data services 120a, 120b, 120c, 120d may receive sensor data request from video request aggregator 110. In some embodiments, this sensor data request aggregator 110 may make available, via an API or a web application portal, an interface for receiving sensor data requests from requesting entities including police departments 101a, insurance companies 101b and private investigators 101c. In some embodiments, the sensor data systems 120a, 120b, 120c, 120d may in some embodiment direct responses comprising camera or sensor data responsive the requests and meeting the request characteristics, and in some embodiments, necessary permissions settings, to a sensor data distribution service 106 to ensure that responses meets certain criteria, relating to quality and responsiveness in view of the corresponding request characteristics, as well as ensuring that only identifying data that meets permissions settings is included in each corresponding data response, and then forwards the data response to the requesting entities 101a, 101b, 101c. In some embodiments, a remuneration module (not shown), which may or may not be instantiated in the same server or servers as the sensor data request aggregator 110 and sensor data distribution service 106, causes remuneration to be received from the requesting entity 101a, 101b, 101c, 105 and forwarded to the applicable end-user 130. In some embodiments, this remuneration is executed automatically via a smart contract on a blockchain network, transferring a stablecoin231428P-FVO-WO01cryptocurrency to a digital wallet associated with the end-user 130. Some embodiments may further comprise a sensor data request website 105 that is configured to accept requests, along with request characteristics, via a web portal, and forward same to the sensor data request aggregator 110 and, assuming responsive data exists and the end-user has established permissions permitting the response, receiving from the sensor data distribution service 106 responsive sensor data.

[0098] With reference to Figure 2, and in accordance with one exemplary embodiment, a sensor data request system, generally referred to using the numeral 200, will now be described. There is provided a server 215 configured to execute at least some of the following functions: it provides configuration software or instructions (including via a web site) for third-party devices to receive and respond to requests in accordance with the systems and methods disclosed herein; it provides an interface for requesting entities 220a, 220b, 220c, to request sensor data, along with request characteristics relating to the time, place, content, and purpose of data requests; forwards and receives responses from the third-party devices 201, 205; processes the data in accordance with permissions established by end-users of the third-party devices 201, 205, including predefined permissions or permission provided to each specific data request; evaluate response data to ensure that the response meets the data request characteristics, meets quality and responsiveness criteria, and / or has no identifying information associated with the end users; distributes data response to the appropriate requesting entity 220a, 220b, 220c; transfers remuneration in accordance with the instructions of the requesting entity 220a, 220b, 220c. The sensor data request system 200 comprises a network connection over a communications network 210a with one or more third- party camera or sensor devices 201, 205, as well as with one or more requesting entities 220a, 220b, 220c over a communications network 210b. Although Figure 2 shows the network communications networks 210a and 210b as separate networks, they will generally form the same network, i.e. the Internet (although the connections may comprise distinct virtual private networks therebetween), the communication of sensor data requests and responses will not be communicated directly over the network between the requesting entities and the participating devices, but rather will be intermediated by the server 215. In some embodiments, the one or more requesting entities 220a, 220b, 220c may be police departments, insurance companies and / or private investigators, or others seeking camera or sensor data.241428P-FVO-WO01

[0099] In embodiments, there are provided various methods for requesting and receiving specific types of camera and / or sensor data collected by third-party devices. In some embodiments, the method comprises causing a server, in accordance with computer readable instructions stored in accessible storage and executable by a processor associated with the server, to releasing requests for specific types of camera or sensor data collected by or accessible from third-party camera and sensor devices. The release of the data request may in accordance with an RSS or JSON feed. The requests may be pushed, broadcast, or multicasted to, or alternatively forwarded in response to polling requests from, one or more participating third-party sensor devices, which may comprise network enabled cameras, sensors, motion detectors, or other devices collecting data relating to their surroundings. The requests may specify characteristics of the requested camera or sensor data comprising location data relating to where the data was collected, time data relating to when the data was collected, data relating to objects represented in the camera or sensor data, the reason or purpose of the data request, whether and how much remuneration is associated with a given request, the identity or the nature of the requesting entity; and whether identifying information of the end-user may be required. In some embodiments, response data is then evaluated in accordance with the characteristics specified in the requests and, in some cases, in accordance permissions settings; and receiving third-party camera devices with the collected camera data that meets the characteristics specified in the request from the third-party camera devices whose end-user have granted permission for sending the response.

[0100] With reference to Figure 3, there is provided an exemplary method for releasing data requests. A release of a data request 301 is shown, which may comprise a push, broadcast, or poll response of request including request characteristics is executed by a server. The request will specify one or more characteristics that may include: a geographical indicator (e.g. geofence), a time range, a content indicator, requestor information, remuneration information, and request reason. At 302, the format of the request facilitates a third-party device in assessing whether it has access to camera or sensor data that shares the request characteristics. At 303, the request format facilitates the evaluation of permissions; this may permit a response upon a confirmation by an end user in respect of a specific request or it may comprise of one or more permissions settings that would facilitate an automatic response. At 304, the system is configured to receive a request response and, in some embodiments, evaluate response quality and responsiveness (including in view of the corresponding request characteristics), evaluate and in some cases excluded identifying 251428P-FVO-WO01information relating to the end user, and forward to the requesting entity. In some embodiments, at 306, a remuneration engine provides for the forwarding of remuneration to the end user associated with a request response that has offered to provide remuneration.

[0101] With reference to Figure 4, there is provided an exemplary system architecture consistent with embodiments of systems disclosed herein, comprising blockchain-based remuneration. Figure 4 shows an exemplary system illustrative of how an embodiment may manage and compensate sensor data requests using blockchain technology. There is shown various: (i) Requesting Entities (left side), including a Police Department (401a), an Insurance Company (401b), a Private Investigator (401c); (ii) a Central Server System (400), comprising or associated with the following modules: Sensor Data Request Aggregator (410), Sensor Data Distribution Service (406), Data Evaluation Module (450), Remuneration Module (460); (iii) Third-Party Services (right side), comprising exemplary services including: Door Camera Service (420a), Security Camera Service (420b), Vehicle Camera Mobile App Service (420c); (iv) various exemplary End-User Components (bottom), comprising: End-User Digital Wallet (435), End-User (430), and a Blockchain Network / Smart Contract (440). Figure 4 illustrates how in some embodiments hereof requesting entities submit verified sensor data requests, which are processed through the server system. The system evaluates data and handles payment authorization through a blockchain-based remuneration system. Third-party camera services provide sensor data responses, and end-users are compensated through their digital wallets via stablecoin payments processed through smart contracts. Figure 4 illustrates how exemplary a decentralized system, in accordance with embodiments hereof, can interact with individuals monetizing their camera / sensor data by providing it to legitimate requesting organizations, with blockchain ensuring transparent and secure compensation.

[0102] With reference to Figure 5, there is provided another exemplary system architecture consistent with embodiments of systems disclosed herein, comprising a high-level architecture showing an alternative implementation of systems disclosed herein. Figure 5 shows a system architecture with three main components: (1) Requesting Entities (left side), as shown by Requesting Entity A (520a), Requesting Entity B (520b), Requesting Entity C (520c); (2) Central Infrastructure, as shown by Communications Network (510b) connecting the requesting entities to the server via a network connection or other type of communication system, Server (515), and a261428P-FVO-WO01Communications Network (510a) connecting the server to third-party devices; and (3) Third-Party Devices (right side), as shown by Third-Party Device (501) and Third-Party Device (505), as two from among many possible such devices that may be connected. There is shown bidirectional communication between all components through the communications networks. Such architecture as shown focuses on the core communication pathways between requesting entities, the central server, and third-party devices that provide sensor data.

[0103] With reference to Figure 5, there is provided an embodiment of a method disclose herein relating to a data request and response method. Figure 5 shows a flowchart showing an exemplary process for handling data requests in embodiments of the systems disclosed herein. Figure 6 shows an exemplary linear workflow with five main steps (keeping in mind that, where applicable, some of these steps may be performed in parallel or in different orders). At Step 601, a Server Executes Release of Data Request, in which characteristics such as geofence, time, content, and remuneration information may accompany a data request. At Step 602, Third-Party Device Assesses for Matching Sensor Data (some of which may be shown in more detail in Figure 7). At Step 603 : Third-Party Device Evaluates User Permissions, which may involve either manual or automatic approval processes for accessing and / or releasing information based on the request. At Step 604: Server Receives Response, Evaluates Quality & Responsiveness, which may automatically detect and exclude any identifying information during this evaluation. At Step 606: Remuneration Engine Forwards Remuneration to End-User provides for providing remuneration to a user that has provided data in response to a request (Figure 8 may provide additional information about this compensation process). Figure 6 represents an exemplary illustration of the operational workflow that would occur within the system architectures shown in the previous figures, focusing specifically on how individual data requests are processed and how users are compensated for providing sensor data.

[0104] With reference to Figure 7, there is provided, in accordance with at least one embodiment of a method disclosed herein, a representative On-Device Spatio-Temporal Indexing and Query Process, showing a technical workflow for how third-party devices process and match sensor data requests using indexing techniques. Figure 7 illustrates two parallel processes that converge. On the Left Side there is shown a Data Indexing Process, comprising the following steps (shown here in one possible linear order): Step 701 : Sensor Data Input, which collects video, GPS,271428P-FVO-WO01and timestamp data. Step 702: On-Device Indexing Module, which processes the raw sensor data. Step 703: Apply Hilbert Curve Mapping, which converts 3D spatio-temporal data into ID code using mathematical mapping. Step 704: Store in Local, Sorted ID Code Index, which creates an efficient searchable database (shown as a cylinder). On the right side of Figure 7, a possibly parallel and independent process is shown, prior to converging: Query Processing, which comprises the following steps: Step 705: Receive Data Request, which gets geofence and time range parameters. Step 706: On-Device Query Module, which processes the incoming request. Step 707: Convert Request Parameters to ID Code Range, which transforms the request into the same format as the stored data. The output of these processing steps converge as follows: Step 708: Execute Binary Search on Local Index, which efficiently searches the indexed data, at which there is a decision point, determining if relevant data exists that is responsive to the request. If there is none, at Step 711, the request is discarded (and in some cases causes a notification or other event). If there is any data that is responsive, Step 710, the system proceeds to user permission check (as shown in Step 603 from Figure 6). Figure 7 represents, in accordance with one embodiment, a data matching system that may, in some embodiments, use Hilbert space-filling curves to efficiently index and search spatio-temporal data without requiring centralized processing, and maintaining privacy while enabling quick data retrieval.

[0105] With reference to Figure 8, there is shown an exemplary aspect of automated remuneration module using smart contracts in accordance with at least on embodiment hereof. It illustrates the blockchain-based payment system that automatically compensates users for providing sensor data, optionally, in a privacy-protective manner. There is shown a payment workflow with five main components. First, a Server System (801) comprising or associated with: a Data Evaluation Module (802), which receives and processes verified sensor data; a remuneration module (803), which handles payment processing once data quality is verified. Second, there is shown a Central Blockchain Infrastructure comprising or associated with: a Blockchain Network (804), which operates as a smart contract system that executes automated payments. Third, there are shown digital wallets, that may or may form part of systems disclosed herein as third party or existing digital wallet systems, comprising or associated with: a Requester's Digital Wallet (805), which holds funds for data purchases, and an End-User's Digital Wallet (806), which receives compensation for provided data. The shown in Figure 8 comprises a Payment Flow Process, which further comprises: that Data Quality is verified, in which the server confirms the 281428P-FVO-WO01sensor data meets requirements; a Trigger Payment step with Proof & Wallet Addresses, at which the remuneration module initiates a blockchain transaction; a Smart Contract Execution, in which a blockchain (or other DLT) automatically processes the payment; a Financial Transfer: as shown by the step of withdrawing a stablecoin (4a), wherein funds are moved from requester's wallet, and then a stablecoin is deposited (4b), wherein payment arrives in end-user's wallet. There is then shown a Return Transaction Confirmation (Tx Hash), in which the blockchain provides proof of completed transaction back to the server as hashed information. As shown, there is provided automated and verifiable compensation using cryptocurrency (stablecoins) while maintaining an audit trail through blockchain transaction records. It should be recognized that embodiments hereof are not limited to blockchain technology or specific cryptocurrencies, and that other digital ledger technologies or cryptocurrencies may be used.

[0106] While the present disclosure describes various embodiments for illustrative purposes, such description is not intended to be limited to such embodiments. On the contrary, the applicant's teachings described and illustrated herein encompass various alternatives, modifications, and equivalents, without departing from the embodiments, the general scope of which is defined in the appended claims. Except to the extent necessary or inherent in the processes themselves, no particular order to steps or stages of methods or processes described in this disclosure is intended or implied. In many cases the order of process steps may be varied without changing the purpose, effect, or import of the methods described.

[0107] Information as herein shown and described in detail is fully capable of attaining the above-described object of the present disclosure, the presently preferred embodiment of the present disclosure, and is, thus, representative of the subject matter which is broadly contemplated by the present disclosure. The scope of the present disclosure fully encompasses other embodiments which may become apparent to those skilled in the art, and is to be limited, accordingly, by nothing other than the appended claims, wherein any reference to an element being made in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more." All structural and functional equivalents to the elements of the above-described preferred embodiment and additional embodiments as regarded by those of ordinary skill in the art are hereby expressly incorporated by reference and are intended to be encompassed by the present claims. Moreover, no requirement exists for a system or method to address each and every problem sought to be291428P-FVO-WO01resolved by the present disclosure, for such to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. However, that various changes and modifications in form, material, work-piece, and fabrication material detail may be made, without departing from the spirit and scope of the present disclosure, as set forth in the appended claims, as may be apparent to those of ordinary skill in the art, are also encompassed by the disclosure.301428P-FVO-WO01

Claims

CLAIMSWhat is claimed is:

1. A system for requesting and receiving sensor data collected by third-party sensor devices, the system comprising: one or more servers in network communication with a telecommunications network, the one or more servers comprising access to data storage and a processor; the processor being configured to execute computer-readable instructions stored in the data storage, wherein the computer-readable instructions cause the one or more servers to: release requests over the telecommunications network, readable by third-party devices communicatively connected therewith, for sensor data, wherein the requests are configured to specify request characteristics of the requested sensor data; and receive responses from participating third-party devices with response characteristics permitting such responses, the responses comprising sensor data matching at least some of the characteristics specified in corresponding requests.

2. The system of Claim 1, wherein the one or more request characteristics comprises at least one of: location data relating to where the sensor data was collected, time data relating to when the sensor data was collected, content data relating to objects represented in the sensor data, or a purpose of the sensor data collection.

3. The system of either one of Claim 1 or Claim 2, wherein the participating third-party sensor devices are configured to evaluate the request by querying a locally stored, unified spatio-temporal index of collected sensor data, the index generated by mapping spatio-temporal coordinates of the data to one-dimensional codes.

4. The system of Claim 3, wherein the one-dimensional codes are generated using a spacefilling curve.

5. The system of Claim 4, wherein the space-filling curve is a Hilbert space-filling curve.311428P-FVO-WO016. The system of Claim 3, wherein the third-party sensor devices are configured to query the index by performing a binary search on a sorted collection of the one-dimensional codes.

7. The system of any one of Claims 1 to 6, wherein the request characteristics include a predefined response format that the third-party sensor devices must adhere to in the responses.

8. The system of any one of Claims 1 to 7, further comprising a user interface module that allows requestor users to define the specific characteristics of the sensor data to be requested.

9. The system of Claim 8, wherein the user interface module allows users to specify one or more of: a geographical area, a temporal range, content data, or a purpose for the sensor data collection.

10. The system of any one of Claims 1 to 9, wherein the one or more servers further comprise a remuneration module that transmits remuneration information to third-party sensor devices upon receipt by the one or more servers of a response that matches at least some of the request characteristics.

11. The system of Claim 10, wherein the remuneration module is further configured to initiate a transfer of a stablecoin cryptocurrency from a first digital wallet associated with the requesting entity to a second digital wallet associated with the third-party sensor device.

12. The system of Claim 11, wherein the transfer is automatically executed by a smart contract on a blockchain network upon a data evaluation module verifying that the response meets a predefined data quality threshold.

13. The system of any one of Claims 1 to 12, wherein the response excludes identifying information relating to the third-party sensor devices and corresponding end-users associated therewith.

14. The system of any one of Claims 1 to 13, wherein the one or more servers are configured to make available to third-party sensor devices over the telecommunications network, configuration instructions that, once functionally stored on the third-party sensor devices, render321428P-FVO-WO01participating third-party sensor devices responsive to requests based on one or more response characteristics.

15. The system of Claim 14, wherein the configuration instructions render participating third- party sensor devices automatically responsive to requests.

16. The system of any one of Claims 1 to 15, further comprising a data evaluation module configured to filter the responses based on data quality.

17. The system of any one of Claims 1 to 16, wherein the one or more servers are configured to handle secure data transmissions to and from the third-party sensor devices, and to and from requesting entities.

18. The system of any one of Claims 1 to 17, wherein the one or more servers are configured to support encrypted communication protocols.

19. The system of any one of Claims 1 to 18, further comprising a consent management module that tracks and manages permissions of third-party sensor device end-users for providing the sensor data collected.

20. The system of Claim 19, wherein the consent management module provides a mechanism for end-users of third-party sensor devices to at least one of provide, withdraw, or modify their permissions.

21. The system of any one of Claims 1 to 20, wherein the one or more servers are configured to send periodic or event-driven requests for specific types of sensor data.

22. The system of any one of Claims 1 to 21, wherein the response is provided to requesting entities in real-time.

23. The system of any one of Claims 1 to 22, further comprising a data aggregation module configured to aggregate and process the collected data received from multiple third-party sensor devices relating to the same request.331428P-FVO-WO0124. The system of any one of Claims 1 to 23, wherein the one or more servers comprise virtual servers integrated into a cloud-based platform accessible via the Internet.

25. The system of any one of Claims 1 to 24, wherein releasing a request comprises at least one of a push, a broadcast, or a response to a poll for requests.

26. The system of any one of Claims 1 to 25, wherein the third-party sensor devices comprise at least one of a camera, a light sensor, a motion sensor, or other data sensor.

27. A method for requesting and receiving specific types of sensor data collected by third-party sensor devices, the method comprising: releasing requests from a requesting entity for sensor data to third-party sensor devices, wherein the requests specify characteristics of the requested sensor data comprising location data, time data, and object data, the location data relating to where the sensor data was collected, the time data relating to when the data was collected, and data relating to objects represented in the sensor data; evaluating response data from the third-party sensor devices based on the characteristics specified in the requests; and forwarding the response data from the third-party sensor devices, whose end-user have granted permission for sending the response data, to the requesting entity.

28. The method of Claim 27, wherein the evaluating comprises evaluating the requests by querying a unified spatio-temporal index generated from the collected sensor data by mapping spatio-temporal coordinates of the data to one-dimensional codes.

29. The method of Claim 28, wherein the mapping is performed using a space-filling curve.

30. The method of Claim 29, wherein the space-filling curve is a Hilbert space-filling curve.

31. The method of Claim 27, further comprising transmitting remuneration data to third-party sensor devices corresponding with received responses.341428P-FVO-WO0132. The method of Claim 31, wherein the transmitting remuneration data comprises initiating a transfer of a stablecoin cryptocurrency from a first digital wallet associated with the requesting entity to a second digital wallet associated with the third-party sensor device.

33. The method of Claim 32, wherein the transfer is automatically executed by a smart contract on a blockchain network upon verifying that the response meets a predefined data quality threshold.

34. The method of any one of Claims 27 to 33, further comprising moving identifying information relating to an end-user of the third-party sensor devices from the permitted responses before transmission to a requesting entity.

35. The method of any one of Claims 27 to 34, wherein the release of requests comprises at least one of a push, a broadcast, or a response to a poll for requests.

36. The method of any one of Claims 27 to 35, wherein the third-party sensor devices comprise at least one of a camera, a light sensor, a motion sensor, or other data sensor.351428P-FVO-WO01

Images