Authentication in decentralized networks

文档序号：1866559 发布日期：2021-11-19 浏览：8次中文

阅读说明：本技术 去中心化网络中的验证 (Authentication in decentralized networks ) 是由 M·A·贝诺列尔 G·金斯曼 L·卢瓦索 E·泰索尼埃于 2019-12-23 设计创作，主要内容包括：一种系统可包含经配置以执行指令来致使系统执行包含从中间装置接收源于端点节点处的数据的操作的处理逻辑。所述数据可与通过所述中间装置与所述数据相关联的元数据相关联。所述操作还可包含从所述元数据提取一或多个项。所述操作可包含基于从所述元数据提取的所述一或多个项验证所述中间装置的活动。(A system may include processing logic configured to execute instructions to cause the system to perform operations including receiving data originating at an endpoint node from an intermediary device. The data may be associated with metadata associated with the data by the intermediary device. The operations may also include extracting one or more terms from the metadata. The operations may include verifying activity of the intermediary device based on the one or more terms extracted from the metadata.)

1. A method, comprising:

receiving data originating at an endpoint node from an intermediary device, the data associated with metadata associated with the data by the intermediary device;

extracting one or more terms from the metadata;

verifying activity of the intermediary device based on the extracted one or more terms;

creating and storing a record of the verified activity with reference to an account associated with the intermediary device;

identifying a reward for the verified activity based at least in part on the one or more items from the metadata; and

assigning the reward to the account associated with the intermediary device.

2. The method of claim 1, wherein the extracted one or more terms include at least one geographic location associated with the data or the intermediary device, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

comparing the geographic location associated with the data or the intermediary device to an expected geographic location of the data;

responsive to determining that the geographic location associated with the data or the intermediary device and the expected geographic location of the data are within a threshold geographic distance, verify the activity of the intermediary device; and

refraining from verifying the activity of the intermediary device in response to determining that the geographic location associated with the data or the intermediary device and the expected geographic location of the data are outside of a threshold geographic distance.

3. The method of claim 2, wherein refraining from verifying the activity of the intermediary device includes imposing a penalty on the intermediary device in response to the geographic location associated with the data or the intermediary device and the expected geographic location of the data being outside a threshold geographic distance.

4. The method of claim 1, wherein the extracted one or more terms include a geographic location of the intermediary device, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

identifying a set of intermediary devices based on the geographic location of the intermediary devices;

identifying a set of data collected by the set of intermediary devices;

comparing the extracted one or more terms to the set of data collected by the set of intermediary devices;

determining that the extracted one or more terms and the set of data collected by the set of intermediary devices are within a similarity threshold; and

verifying the activity of the intermediary device based on a determination that the extracted one or more terms and the set of data collected by the set of intermediary devices are within the similarity threshold.

5. The method of claim 1, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device comprises appending the verified activity to an existing record of prior verified activity associated with the account.

6. The method of claim 4, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device further comprises:

creating a summary of each activity in the record;

generating a hash of the summary; and

storing the hash in a decentralized data storage system.

7. The method of claim 1, wherein allocating the reward to the account associated with the intermediary device comprises selecting the intermediary device from among a plurality of intermediary devices based on the extracted one or more terms.

8. A non-transitory machine-readable medium comprising a plurality of machine-readable instructions executable to perform operations comprising:

receiving data originating at an endpoint node from an intermediary device, the data associated with metadata associated with the data by the intermediary device;

extracting one or more terms from the metadata;

verifying activity of the intermediary device based on the extracted one or more terms;

creating and storing a record of the verified activity with reference to an account associated with the intermediary device;

identifying a reward for the verified activity based at least in part on the one or more items from the metadata; and

assigning the reward to the account associated with the intermediary device.

9. The non-transitory machine-readable medium of claim 8, wherein the extracted one or more terms include at least one geographic location associated with the data or the intermediary device, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

comparing the geographic location associated with the data or the intermediary device to an expected geographic location of the data;

10. The non-transitory machine-readable medium of claim 9, wherein refraining from verifying the activity of the intermediary device includes applying a penalty to the intermediary device in response to the geographic location associated with the data or the intermediary device and the expected geographic location of the data being outside a threshold geographic distance.

11. The non-transitory machine-readable medium of claim 8, wherein the extracted one or more terms includes a geographic location of the intermediary device, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

identifying a set of intermediary devices based on the geographic location of the intermediary devices;

identifying a set of data collected by the set of intermediary devices;

comparing the extracted one or more terms to the set of data collected by the set of intermediary devices;

determining that the extracted one or more terms and the set of data collected by the set of intermediary devices are within a similarity threshold; and

12. The non-transitory machine-readable medium of claim 8, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device comprises appending the verified activity to an existing record of previously verified activity associated with the account.

13. The non-transitory machine-readable medium of claim 12, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device further comprises:

creating a summary of each activity in the record;

generating a hash of the summary; and

storing the hash in a decentralized data storage system.

14. The non-transitory machine-readable medium of claim 8, wherein allocating the reward to the account associated with the intermediary device comprises selecting the intermediary device from among a plurality of intermediary devices based on the extracted one or more terms.

15. A system, comprising:

a memory; and

one or more processors operably coupled to the memory, the one or more processors configured to perform operations to cause the system to perform operations comprising:

receiving data originating at an endpoint node from an intermediary device, the data associated with metadata associated with the data by the intermediary device;

extracting one or more terms from the metadata;

verifying activity of the intermediary device based on the extracted one or more terms;

creating and storing a record of the verified activity with reference to an account associated with the intermediary device;

identifying a reward for the verified activity based at least in part on the one or more items from the metadata; and

assigning the reward to the account associated with the intermediary device.

16. The system of claim 15, wherein the extracted one or more terms include at least one geographic location associated with the data or the intermediary device, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

comparing the geographic location associated with the data or the intermediary device to an expected geographic location of the data;

17. The system of claim 16, wherein refraining from verifying the activity of the intermediary device includes imposing a penalty on the intermediary device in response to the geographic location associated with the data or the intermediary device and the expected geographic location of the data being outside a threshold geographic distance.

18. The system of claim 15, wherein the extracted one or more terms include a timestamp associated with the data, wherein verifying the activity of the intermediary device based on the extracted one or more terms includes:

identifying a plurality of timestamps associated with a set of data;

comparing the extracted timestamp to the timestamp associated with the data;

determining that the extracted timestamp is within a similarity threshold with the timestamp associated with the data; and

validating the activity of the intermediary device based on the determination that the extracted timestamp and the timestamp associated with the data are within the similarity threshold.

19. The system of claim 15, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device comprises appending the verified activity to an existing record of prior verified activity associated with the account.

20. The system of claim 19, wherein creating and storing the record of the verified activity with reference to the account associated with the intermediary device further comprises:

creating a summary of each activity in the record;

generating a hash of the summary; and

storing the hash in a decentralized data storage system.

Technical Field

Embodiments discussed herein relate to authentication in decentralized networks.

Background

The internet of things (IoT) -a network of connected "smart" devices that communicate seamlessly via the internet-is expanding to aspects of human life. IoT devices are increasingly used in health care and medical device and drug manufacturing in hospitals. In cities, IoT devices help to track and monitor pollution. Governments, military, companies, and individuals may also use IoT devices for asset tracking and management. Although these applications are used for different purposes, they all share a characteristic-relying on strong connectivity. Soon, conventional networks will not be able to meet the bandwidth and power requirements needed to support connections for billions of IoT devices.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided merely to illustrate one example area of technology in which some embodiments described herein may be practiced.

Disclosure of Invention

According to an aspect of an embodiment, a system may include processing logic configured to execute instructions to cause the system to perform operations including receiving data originating at an endpoint node from an intermediary device. The data may be associated with metadata associated with the data by the intermediary device. The operations may also include extracting one or more terms from the metadata. The operations may include verifying activity of the intermediary device based on the one or more terms extracted from the metadata.

The objects and advantages of the embodiments will be realized and attained by at least the elements, features, and combinations particularly pointed out in the claims.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention as claimed.

Drawings

Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1A illustrates an example network architecture in which embodiments of the present disclosure may be implemented;

FIG. 1B illustrates an example network architecture in which embodiments of the present disclosure may be implemented;

FIG. 2 illustrates another example network architecture in which embodiments of the present disclosure may be implemented;

FIG. 3 illustrates an example sequence diagram of a process for verifying activity in a network;

FIG. 4 illustrates another example sequence diagram of a process for verifying activity in a network;

FIG. 5 illustrates a flow diagram of an example method related to authentication in a decentralized network; and

figure 6 illustrates a diagrammatic representation of a machine in the example form of a computing device within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed,

all arranged in accordance with at least one embodiment described herein.

Detailed Description

The internet of things (IoT) is expanding into aspects of human life. It is expected that over 750 hundred million IoT devices will be deployed by 2025, so a more efficient new network infrastructure is needed to bring these devices online and connect them to each other.

There are many connection solutions for IoT devices. Unfortunately, all of these schemes suffer from limited bandwidth, reduced connectivity degradation, high power consumption, and/or high cost. For example, a cellular connection may consume a large amount of power in the device and may also be expensive. Low power solutions, such as Low Power Wide Area Networks (LPWANs), may consume less power than cellular connections. LPWANs, however, may be limited by limited bandwidth and may not be able to transmit enough data to fully meet the needs of a distributed network. Conventional systems fail to consume a relatively low amount of power while still providing high bandwidth.

In particular, to connect small devices to the internet today, existing solutions include: (a) using an existing wireless network, such as by incorporating a cellular module with a Subscriber Identity Module (SIM) card or soft SIM into the device to give it cellular connectivity, (b) establishing a new alternative wireless network and establishing fixed infrastructure to support this network by incorporating a custom radio chipset, and (c) using remote network technologies, such as the LoRa alliance technology. LoRa uses a complex "star-in-star" topology of gateways and bridges between IoT devices and "central network servers" over the industrial, scientific, and medical (ISM) band.

Each of these methods has significant drawbacks. For example, each of these approaches requires a significant amount of power, which is often a major contributor to battery depletion in mobile devices. Furthermore, method (a) requires expensive cellular modules and, in addition, monthly payment to the wireless carrier for wireless cellular service fees for both service subscription and data. Methods (b) and (c) are also expensive because they require the establishment of a new fixed infrastructure and are generally in addition to popular onesThe chip set needs to be purchased for radio transmission in addition to the chip set. Conveying applianceThe longer the input distance, the greater the power requirements, so each of these methods requires significant power. Similarly, cellular devices and Global Positioning System (GPS) enabled devices require high power to communicate with cell towers or satellites due to the long distances.

Aspects of the present disclosure address these and other problems with conventional networks by providing a new decentralized network. In some aspects, a decentralized network may connect numerous devices using less power while providing higher connectivity and/or bandwidth. Embodiments include a crowdsourcing method for sending data from IoT devices to a server without relying on a fixed or centralized infrastructure. Another embodiment includes a crowdsourcing method for a cloud server to send data to IoT devices without relying on a fixed or centralized infrastructure. Another embodiment includes a method for routing data (e.g., beacons and/or data packets) from multiple services on multiple IoT devices to an appropriate device manufacturer server. Yet another embodiment includes a method for reducing energy consumption on a mobile device for collecting or exchanging any amount of data with a remote IoT device, which may include two-way communication between the devices.

On the other hand, storing content locally on an intermediary device may be used for the following purposes: to reach some IoT devices located in areas lacking an infrastructure network; such as underground or remote locations; and deliver data using short range communication, such as bluetooth, whenever the intermediary device is within range of the IoT device. Alternatively, the intermediary device may use short-range communication to download some data usage from the IoT device and store it in its local cache, delivering it to the appropriate manufacturer server only if the intermediary device comes back within the centralized infrastructure.

In one aspect, the present disclosure describes systems and techniques that improve on existing technologies by eliminating the need for a separate, fixed infrastructure using crowd sourcing techniques. Some aspects provide a method for IoT device-to-server communication with a low power profile and without requiring a large-scale fixed hardware infrastructure. Other benefits of the present disclosure are the ability to reduce internet access costs and create a platform for new innovations in the IoT realm. Another benefit of the present disclosure is that it can increase the reliability of data in the system by verifying each device and each activity of the device in the decentralized network.

The present disclosure is applicable to every field using network-based communication. Example parties that may benefit from the present disclosure include, but are not limited to, smart phone manufacturers, bicycles, scooters and ride-sharing companies, outdoor advertisers, environmental analysis companies, and the like. Example applications may include for pollution tracking, asset tracking, finding lost devices, industrial predictive maintenance, and the like. Furthermore, aspects of the present disclosure may not rely on connectivity using a SIM or LPWAN modem, which enables devices to become smaller and more efficient.

For example, in the case of location tracking of devices and assets, most low-cost tracking device manufacturers rely on application users to locate the device, and there is insufficient application density to provide global coverage. Adding cellular modules and GPS modules is costly and power consuming. Aspects of the present disclosure may provide solutions that do not require the endpoint device to include a cellular or GPS module, which interoperate globally and reduce costs.

In the example of low power sensor connectivity, the cost of some sensors is so low that the cost of adding a cellular or GPS connection may be an order of magnitude higher than the cost of the sensors. Aspects of the present disclosure may provide connectivity services at very low cost.

Some aspects may also be used for firmware updates, updating date and time of device, creating wearable device networks, data IP connectivity, measuring population density (e.g., by detecting in a given location)Number of devices), the presence of a specific device for an insurance company is checked, and the sales tendency of the specific device is detected for a market analysis company, a hedge fund, a private share company, and the like. In at least one embodiment, storing firmware updates, software, or content locally on an intermediary device may be used for the purpose of reducing latencyAnd may also advantageously use the network edge to perform content distribution, software or firmware updates or installations.

Furthermore, in such systems, without careful planning, bad actors may enter the system and send bad data. This type of behavior may have a negative and persistent impact on decentralized networks. To combat undesirable actors in such decentralized networks, the present disclosure provides various techniques for validating (validation/verification) activities in the decentralized network. In at least one embodiment, a reward may be given to the verified activity. In at least one embodiment, a penalty may be imposed on activities that may compromise the integrity of the decentralized network.

Fig. 1A illustrates an example network architecture 100 in which embodiments of the present disclosure may be implemented. The network architecture 100 may include one or more endpoint devices 105, one or more intermediate devices 115, one or more supernodes 125, and one or more destination nodes 135. In some embodiments, the network architecture 100 may be capable of moving data between one or more endpoint devices 105 and various destination nodes 135 through one or more crowdsourcing intermediary devices 115 and one or more supernodes 125, which may serve as network clients.

The endpoint device 105 may include one or more IoT devices. Endpoint devices 105 may include power supplies, data collection devices (e.g., sensors), and network devices. The power supply may include a battery or a connection to a power grid. Additionally or alternatively, the power supply may include an energy harvesting device, such as a solar panel, solar cell, solar photovoltaic, electromagnetic, or the like. In at least some embodiments, the endpoint device 105 may not include a power supply and may instead use ambient backscatter techniques. The endpoint device 105 may also include one or more sensors. One or more sensors may be configured to detect any type of condition and generate electronic data based on the detected condition.

For example, endpoint device 105 may include a smart watch with a heart rate monitor configured to generate heart rate data using heart rate conditions collected by the heart rate monitor. In at least one embodiment, endpoint device 105 does not have the capability to communicate over the internet and only includes hardware and/or software capable of communicating with a nearby device, such as nearby intermediate device 115.

The network device of endpoint device 105 may include any hardware, software, or combination thereof capable of communicating with another device over a network. In at least one embodiment, the network device can include a network device configured to be over a short-range network (e.g., a wireless network)Or any other short-range network). In at least one embodiment, a network device may include any network controller configured to communicate over any network of any range. In at least one embodiment, the network device may include any network controller configured to communicate over a low power network. Example endpoint devices 105 include, but are not limited to, industrial devices, household appliances, commercial equipment, inventory trackers, smart watches, wearable devices, heart rate monitors, logistics trackers, environmental sensors, cash registers, credit card readers, point of sale (POS), bicycles, electric scooters, electric skateboards, automobiles, electric cars, satellites, point of sale (POS), electric scooters, electric skateboards, electric cars, electric vehicles, and the like,A label,Stickers or any device, including mobile devices and non-mobile devices of a wireless radio interface. The network architecture 100 may include any number of endpoint devices 105, and the endpoint devices 105 in the network architecture 100 may be any type of endpoint device 105, including any type of network-capable device. The endpoint device 105 may be fixed or relatively stationary in the network architecture 100, such as a POS or pollution sensor. Additionally or alternatively, the endpoint device 105 may be a mobile device, such as a smart watch or any car or vehicle.

One or more endpoint devices 105 may be configured to communicate with other devices via at least one wireless network 110. For example, the first endpoint device 105a may be in electronic communication with the first intermediary device 115a via the wireless network 110 a. The one or more intermediary devices 115 may include any type of device capable of communicating with the endpoint device 105 via the wireless network 110 and communicating with the supernode 125 via the wireless network 110 and/or via the second network 120. In at least one embodiment, intermediary device 115 may comprise two network controllers-a first network controller communicating via wireless network 110 and a second network controller communicating via second network 120. Example intermediary devices 115 include Personal Computers (PCs), laptops, smart phones, netbooks, e-readers, Personal Digital Assistants (PDAs), cellular phones, mobile phones, tablets, vehicles, drones, cars, trucks, wearable devices, routers, televisions, or set-top boxes, and the like.

As illustrated, the first endpoint device 105a may be in electronic communication with the first intermediary device 115a via a wireless network 110a (e.g., a short range network). Further, the second endpoint device 105b may be in electronic communication with a second intermediary device 115b via another wireless network 110b (e.g., a low power network). The third endpoint device 105c may be in electronic communication with a third intermediary device 115c via another wireless network 110 c. The fourth endpoint device 105d may be in electronic communication with a fourth intermediate device 115d via another wireless network 110 d.

In some embodiments, wireless network 110 may be any network that uses a relatively low amount of power. Example wireless network 110 may include anyNetwork type (e.g., Bluetooth Low Energy (BLE), Bluetooth 4.0, Bluetooth 5.0, Bluetooth remote), NB-IoT, LTE Direct, LTE-M, LTE M2M, 5G, Wi-Fi, Wi-Fi Aware, voice transmission data, two-dimensional code (qrcode), or any network. One or more endpoint devices 105 may connect to various intermediary devices 115 using different types of wireless networks 110. For example, a first endpoint device 105a may be in electronic communication with a first intermediary device 115a via a first short-range wireless network 110a, and a second endpoint device 105b may be in electronic communication with a second intermediary device 115b via a second short-range wireless network 110 b.

The endpoint device 105, the intermediary device 115, or both may be fixed, relatively stationary, or movable. When the endpoint device 105 and the intermediary device 115 come within wireless range of each other, the endpoint device 105 and the intermediary device 115 may perform handshaking and/or authentication to initiate data exchange between the endpoint device 105 and the intermediary device 115.

In some embodiments, endpoint device 105 may periodically send data (e.g., beacons and/or data packets) via wireless network 110. Endpoint device 105 may include various services that may run on endpoint device 105. For example, a smart watch may include a clock service, a heart rate monitor service, a motion detection service, a music service, and so forth. A beacon or data packet may be generated for each of these services, or a single beacon or data packet may be generated to include data for some or all of the services.

The intermediary device 115 may listen for this data from the endpoint device 105. In response to receiving the data, the intermediary 115 may send the data to the supernode 125 via a network (e.g., the second network 120). In at least one embodiment, wireless network 110 and second network 120 are different types of networks. For example, wireless network 110 may beAnd the second network 120 may be a cellular network, Wi-Fi, or the internet. In at least one embodiment, the intermediary 115 may use a directory to locate the supernode 125. Additionally or alternatively, the intermediary device 115 may identify more than one supernode 125 and may select one of the supernodes 125 in which to send data. The intermediary 115 may select the supernode 125 based on proximity, latency, or any other factor. The second network 120 may include a public network (e.g., the internet), a private network (e.g., a Local Area Network (LAN), or a Wide Area Network (WAN)), a wired network (e.g., an ethernet network), a wireless network (e.g., an 802.xx network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE-advanced network, 1G, 2G, 3G, 4G, 5G, etc.), a router, a hub, a switch, a server computer, and/or combinations thereof.

The one or more supernodes 125 may include one or more computing devices, such as rack-mounted servers, router computers, server computers, personal computers, mainframe computers, laptop computers, tablet computers, desktop computers, smart phones, automobiles, drones, robots, vehicles, or any mobility device with an operating system, etc.), data storage devices (e.g., hard disks, memory, databases), networks, software components, and/or hardware components.

The one or more supernodes 125 may perform functions related to one or more of data routing, activity verification, storage, and insight management. These specific functions are described in more detail in connection with fig. 2. For example, the supernode 125 may verify activities performed by the intermediary devices 115a and 115 b. The supernode 125 may verify the activities performed by the intermediary devices 115c and 115 d. In at least one embodiment, any supernode 125 may verify the activity of any intermediary device 115.

The supernode 125 may include or may be coupled to a data storage device 145. The data storage 145 may include any memory or data storage device. In at least one embodiment, the data store 145 uses an interplanetary file system (IPFS). In some embodiments, data storage 145 may include computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Computer-readable storage media can include any available media that can be accessed by a general purpose or special purpose computer, such as a processor. For example, the data storage 145 may include a computer-readable storage medium, which may be a tangible or non-transitory computer-readable storage medium including Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), compact disc read only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium that can be used to carry or store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer. Combinations of the above may be included in the data storage device 145. In the depicted embodiment, the data store 145 is separate from the supernode 125 and accessible via the network 130. In some embodiments, the data store 145 may be part of the supernode 125. In at least one embodiment, the data storage device 145 may include a plurality of data storage devices. The data store 145 may include routing data, verification data, storage data, and insight data, as further described in connection with fig. 2.

The one or more supernodes 125 may be configured to receive data from the intermediary device 115. One or more supernodes 125 may send data (or other information related to or associated with the received data) to destination node 135.

The one or more supernodes 125 may send the data or other information related to the data to the destination node 135 via the third network 130. The third network 130 may include a public network (e.g., the internet), a private network (e.g., a Local Area Network (LAN) or a Wide Area Network (WAN)), a wired network (e.g., an ethernet network), a wireless network (e.g., an 802.xx network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE-now network, 1G, 2G, 3G, 4G, 5G, etc.), a router, a hub, a switch, a server computer, and/or combinations thereof. In at least one embodiment, the second network 120 and the third network 130 are the same network or include at least some overlapping components. In at least one embodiment, first network 110, second network 120, and third network 130 are part of the same network or include at least some overlapping components.

Destination node 135 may include one or more computing devices, such as rack-mounted servers, router computers, server computers, personal computers, mainframe computers, laptop computers, tablet computers, desktop computers, smart phones, automobiles, drones, robots, or any mobility device with an operating system, etc.), data storage (e.g., hard disks, memory, databases), networks, software components, and/or hardware components. Destination node 135 may be associated with one or more endpoint devices 105. For example, an entity may sell or purchase the endpoint device 105 and may use the destination node 135 to communicate with the endpoint device 105 and/or control the endpoint device 105. In at least one embodiment, at least one of the destination node 135 and the endpoint device 105 are manufactured and/or sold by different entities.

Destination node 135 may send one or more messages to a particular endpoint device 105 or a group of endpoint devices 105. For example, destination node 135 may send an update (e.g., firmware, software) to a particular endpoint device 105 or a group of endpoint devices 105. Destination node 135 may send other communications to endpoint device 105, such as a response to a request from a beacon generated by a particular endpoint device 105 or any other type of communication.

Modifications, additions, or omissions may be made to network architecture 100 without departing from the scope of the disclosure. The present disclosure applies more generally to a network architecture 100 that includes one or more endpoint devices 105, one or more wireless networks, one or more intermediate devices 115, one or more second networks 120, one or more supernodes 125, one or more third networks 130, and one or more destination nodes 135, or any combination thereof.

Fig. 1B illustrates an example network architecture 150 in which embodiments of the present disclosure may be implemented. The network architecture 150 may include the components illustrated and described in fig. 1A, the one or more endpoint devices 105, the one or more intermediate devices 115, the one or more supernodes 125, the one or more destination nodes 135, and the one or more data storage devices 145.

In at least one embodiment, the one or more supernodes 125 may receive the message from the destination node 135, and in some embodiments, the one or more supernodes 125 may send the message from the destination node 135 to the intermediary device 115 b. In at least some embodiments, intermediary device 115b may perform one or more operations in response to receiving a message from destination node 135. The operations may include operations performed locally at intermediary device 115b and/or sending a message from destination node 135 to another intermediary device 115 a. Any number of intermediary devices 115 may be implemented and may be configured in a mesh network. Intermediary device 115a may perform one or more operations in response to receiving a message from intermediary device 115b, such as operations performed locally at intermediary device 115a and/or sending a message from destination node 135 to endpoint device 105 via network 110 a.

The endpoint device 105 may also send a message to the intermediary device 115 a. The intermediary device 115a may send the message to any number of intermediary devices 115 rather than sending the message directly to the supernode 125 via the network 120. As illustrated, the intermediary device 115a may send the message to the intermediary device 115b, but any number of intermediary devices may be used to ultimately route the message to the supernode 125. In at least one embodiment, an intermediary device 115a may select another intermediary device 115 to be closer to the intermediary device 115a than the supernode 125. Any factor may be used by the intermediary device 115a to decide where to send the message, including the latency between the intermediary device 115a and the supernode 125, the latency between the intermediary device 115a and another intermediary device 115c, and the like.

The supernode 125 may send the message to the destination node 135 via the network 130.

Fig. 2 illustrates another example network architecture 200 in which embodiments of the present disclosure may be implemented. The network architecture 200 may include the components illustrated and described in fig. 1A or 1B, the one or more endpoint devices 105, the one or more intermediate devices 115, the one or more supernodes 125, the one or more destination nodes 135, and the one or more data storage devices 145.

The data storage 145 may include various data that may be used by the supernode 125. For example, the data store 145 may include routing data that may be used to route data, validation data that may be used to validate the activities of the intermediary device 115, storage data that may be used to store various data received by the supernode 125, and insight data that may be used to generate information and statistics related to the system 200 and the operations performed therein.

In particular, FIG. 2 illustrates a supernode 125 that may perform routing, authentication, storage, and insight operations. For example, the supernode 125 may verify the activity of the intermediary device 115. The supernode 125 may include one or more of a routing manager 205, an authentication manager 210, a storage manager 215, and/or an insight manager 220.

The routing manager 205, the verification manager 210, the storage manager 215, and/or the insight manager 220 may each be implemented using hardware including a processor, a microprocessor (e.g., for performing or controlling the performance of one or more operations), an FPGA, or an ASIC. In some other examples, the routing manager 205 may be implemented using a combination of hardware and software. Implementations in software may include, for example, rapid activation and deactivation of one or more transistors or transistor elements that may be included in the hardware of a computing system, such as the supernode 125. Additionally, software-defined instructions may operate on information within the transistor elements. The implementation of software instructions may at least temporarily reconfigure the electronic paths and transform the computing hardware.

Routing manager 205 may route data about endpoint device 105, intermediary device 115, and destination node 135. To route data, routing manager 205 may track and/or access relationships between endpoint device 105, intermediary device 115, and destination node 135. For example, the routing manager 205 may access routing data, such as a routing table or a list of endpoint devices associated with a particular destination node 135, in the data store 145.

Routing manager 205 may handle communications between endpoint device 105, intermediary device 115, and destination node 135. In an example, the routing manager 205 may receive data (e.g., beacons and/or data packets) from the intermediary device 115 via the second network 120. The data may have been sent by the endpoint device 105 to the intermediary device via the wireless network 110. The data may contain characteristics about the endpoint device 105 including an identifier (e.g., MAC address, unique ID) of the endpoint device 105, an advertisement for the UUID of the endpoint device's 105 geographic location and services it supports, etc. The routing manager 205 may identify characteristics of the endpoint device 105, such as by analyzing data to identify information about the endpoint device 105. The routing manager 205 may access the data store 145 to identify a destination node 135 associated with the endpoint device 105 and/or data based on characteristics of the endpoint device 105 in the data. For example, the identifier of an endpoint device 105 may be associated with a particular manufacturer that operates a particular destination node 135. The routing manager 205 may identify this particular destination node 135 and address and/or path in the data storage 145 to send the data in order to reach the destination node 135. In at least some embodiments, the routing manager 205 can send data or beacons or data packets to the destination node 135 via the third network 130. The data may include beacons, may not include beacons, or may include information about beacons and endpoint devices 105.

In at least one embodiment, the data may include information and/or data from a plurality of services associated with the endpoint device 105. Additionally or alternatively, multiple beacons or data packets from a single endpoint device 105 may be generated and broadcast over wireless network 110. Each of the multiple beacons or data packets may be associated with a different service associated with endpoint device 105, for example. The routing manager 205 may identify the service and, based on the information of the service, identify the appropriate destination node 135 that should receive the data.

The verification manager 210 may verify activities performed in the system 200. Because the supernode 125 is typically not directly connected to the endpoint device 105, the supernode 125 does not necessarily know whether the data actually came from the endpoint device 105. Simply trusting data from the intermediary, the verification manager 210 can verify that the intermediary sends accurate and actual data from the endpoint device 105. For example, the verification manager 210 may verify whether the intermediary device 115 actually processed the data received from the endpoint device 105.

In at least one embodiment, the verification manager 210 may also reward the intermediary 115 for performing activities within the system 200. For example, the verification manager 210 may allocate cryptographic currency to the intermediary device 115 (or to an account associated with the intermediary device 115). To reduce the likelihood of awarding a device that is not actually performing a particular activity, the verification manager 210 may verify the activity purportedly performed by the intermediary device 115 prior to distributing the award.

In at least one embodiment, in response to receiving the data, the intermediary 115 may send the data to the supernode 125 along with the metadata. The verification manager 210 may identify the metadata and may use the metadata to verify the activity of the intermediary device 115. The metadata may be, for example, additional information added to or sent with the data to the supernode 125. The metadata may include data about data received from the endpoint devices, such as a timestamp of the data received by the intermediary device 115, a timestamp of the data created by the endpoint device (e.g., a beacon and/or a data packet), a timestamp of the data transmitted by the intermediary device 115 to the supernode 125, a geographic location associated with the data and/or the endpoint device 105 that created or transmitted the data, sensor data associated with the endpoint device, a geographic location associated with the intermediary device 115, a type of network used to communicate the data from the endpoint to the intermediary device 115, an amount of data received by the endpoint device 105, an amount of data sent by the intermediary device 115, an amount of data received by the supernode 125, an endpoint device density, an intermediary device density, a latency, local sensor data from the intermediary device, and so forth. The metadata may be stored as authentication data in the data storage 145.

To verify the activity of the intermediary device 115, the verification manager 210 may extract metadata from communications received by the supernode 125 from the intermediary device 115. For example, the verification manager 210 may extract one or more timestamps associated with the data. The verification manager 210 may, for example, extract a timestamp of the data received by the intermediary device 115, a timestamp associated with the creation of the data by the endpoint device, a timestamp of the transmission of the data by the intermediary device 115 to the supernode 125, and may also determine a timestamp of the data received by the supernode 125. The verification manager 210 may compare at least some of these timestamps to ensure that they are meaningful. For example, the verification manager 210 may check whether the timestamp chronology matches the expected route of the data. The timestamp of data creation, for example, should precede any other timestamp, and the receipt of data at the supernode 125 should follow any other timestamp. In at least one embodiment, when the verification manager 210 determines that the timestamps chronologically fit the expected travel path, the verification manager 210 may determine that the intermediary device 115 actually did receive data from the endpoint device 105. The authentication manager 210 may then award the intermediary device 115 to perform the activity.

In at least one embodiment, the verification manager 210 may verify the activity of the intermediary device 115 using two or more timestamps. The verification manager 210 may identify a timestamp associated with the data received from the intermediary device 115. To verify an activity, the verification manager 210 may identify different dates having different timestamps. For example, the authentication manager 210 may identify different data from the intermediary device 115. Additionally or alternatively, the verification manager 210 may identify different data from different intermediary devices 115 within the predetermined geographic area. The verification manager 210 may compare the different timestamps to timestamps associated with the data. The verification manager 210 may determine that the different timestamps are within a similarity threshold with the timestamps associated with the data. For example, the verification manager 210 may determine that a timestamp chronology of different timestamps and timestamps associated with the data matches an expected route and timing of the data. The validation manager 210 may validate activity of the intermediary device based on a determination that the extracted timestamp is within a similarity threshold with a timestamp associated with the data.

Other verification schemes are not exhaustive. For example, the authentication manager 210 may use any or all or any combination of metadata as part of authentication. The verification manager 210 may, for example, determine (e.g., via metadata) that the endpoint device 105 used a short-range network to send data to the intermediary device 115. With this in mind, the verification manager 210 may then compare the similarity of the geographic locations of the endpoint device 105 and the intermediary device 115, due to the use of short-range communications between the endpoint device 105 and the intermediary device 115. In response to determining that the geographic location of the endpoint device 105 and the geographic location of the intermediary device 115 are within the threshold range, the verification manager 210 may determine that the intermediary device 115 did in fact receive data from the endpoint device 105.

In at least one embodiment, metadata from multiple intermediary devices 115 may be used to perform the verification. In at least one embodiment, the authentication manager 210 on the plurality of intermediary devices 115 may function as a cluster of authentication nodes. For example, multiple intermediary devices 115 in close proximity to each other (e.g., within the same room, within the same building, outside nearby, etc.) may receive similar information from multiple connected devices. In at least one embodiment, the plurality of intermediary devices 115 may each receive a similar set of data from the near endpoint device 105. To the extent that the plurality of intermediary devices 115 are not within the exact same location, the plurality of intermediary devices 115 may not receive the exact same data as each other but may receive at least some of the same data (e.g., beacons, data packets). To verify a particular activity of a particular intermediary device 115, the verification manager 210 may query the verification data in the data store 145 to determine whether any other received metadata is similar to metadata associated with the particular intermediary device 115. For example, the authentication manager 210 may identify the geographic location of a particular intermediary device 115 and may search the data store 145 for authentication data for similar geographic locations. In response to identifying a similar geographic location associated with the second intermediary device, the authentication manager 210 may examine any data associated with the second intermediary device to determine a similarity to the data associated with the particular intermediary device 115. For example, authentication manager 210 may determine that the data received from a particular intermediary device 115 includes a payload. The validation manager 210 may determine whether the second intermediary device also sends the payload to the supernode 125. In response to determining that the second intermediary device also sends a payload to the supernode 125, the validation manager 210 may validate the activity of the particular intermediary device 115.

Similar to the example above, instead of or in addition to comparing payloads, the authentication manager 210 may determine whether a second intermediary device receives two or more beacons or data packets that were also received by a particular intermediary device 115 as part of authentication. In response to determining that the second intermediary device received two or more beacons or data packets that were also received by the particular intermediary device 115, the verification manager 210 may verify the activity of the particular intermediary device 115.

Similar to the example above, the authentication manager 210 may determine whether two or more intermediary devices receive data (or more than one of the same beacon or data packet) that was also received by a particular intermediary device 115 as part of authentication. In response to determining that two or more intermediary devices received data (or more than one of the same beacon or data packet) that was also received by a particular intermediary device 115, the verification manager 210 may verify the activity of the particular intermediary device 115.

Further, the authentication manager 210 may also verify the integrity of the data of similarly located intermediary devices. For example, the validation manager 210 may determine that a set of intermediary devices send substantially similar data to the supernode 125, and that an outlier intermediary device (which has a similar geographic location to that of the set of intermediary devices) sends incomplete data to the supernode 125 compared to data received by the supernode 125 through the set of intermediary devices.

In at least one embodiment, to verify activity, verification manager 210 may examine the payload and compare it to other received payloads. In response to determining that the received payload exceeds the threshold number of times, authentication manager 210 may refuse authentication activities because sending intermediary 115 may be sending incorrect data to fraudulently receive the reward.

In addition, the authentication manager 210, as part of authentication, may compare the types of endpoint devices. For example, the supernode 125 may receive data from a plurality of intermediary devices indicating that the plurality of intermediary devices communicate with sensors, televisions, set-top boxes, connected skateboards, smart watches, and laptop computers. An outlier intermediary device with a similar geographic location as the plurality of intermediary devices indicates communication with sensors, televisions, set-top boxes, connected skateboards, smart watches, and laptop computers, but the outlier intermediary device also indicates communication from additional devices (e.g., by forwarding beacons or data packets). In response to determining that the plurality of intermediary devices each communicate with similar devices and that the outlier intermediary device also communicates with additional devices, the verification manager 210 may determine that the outlier intermediary device did not send correct and accurate data to the supernode 125. In response, the authentication manager 210 may avoid rewarding the outlier, even for legitimate beacons or data packets, because the outlier appears to be trying to trick the authentication manager 210 into awarding a reward for activities that are not actually performed by the outlier. In at least one embodiment, the verification manager 210 can also cause the outlier intermediary to disconnect from the system 200. For example, the authentication manager 210 may add the group intermediary (or an identifier of the outlier intermediary) to a blacklist. The blacklist may be used by the supernode 125, or by any other component of the system 200, to deny or prevent communication with the outlier intermediary.

In at least one embodiment, multiple authentication managers 210 can be used to authenticate activities based on consistency among multiple authentication managers 210. In at least one embodiment, multiple authentication managers 210 may have 100% authentication consistency. Alternatively, multiple verification managers 210 may have verification consistency of less than 100%, provided that the consistency is above a threshold consistency amount.

Additionally or alternatively, the verification manager 210 may use data mining, deep learning, artificial intelligence, cryptographic signatures in order to provide a more robust verification scheme and determine whether the data is valid. For example, data mining may be used to estimate the expected route of a single IoT device 105 or the intermediate device 115 in order to automatically calculate a confidence score on the trustworthiness of the intermediate device by measuring the deviation between the received metadata sent by the intermediate device and the expected path.

In response to successful verification of the activity, the verification manager 210 may assign a reward for the activity to the intermediary device 115 or an account associated with the intermediary device 115. Example rewards may include cryptocurrency, title, status, upgrade, credit, and the like.

The rewards may be different for different activities. Different data may have different values. For example, relaying a relatively small piece of data may be associated with a smaller reward than a larger reward for relaying a relatively larger piece of data. Additionally or alternatively, the entity may adjust the rewards for particular types of activities. For example, a particular entity may wish to collect data in a highly concentrated area and at a particular time (e.g., at a sporting event). The entity may allocate a reward for the empirical data received from near the region during a particular time. The verification manager 210 can assign the reward to activities that meet the criteria for the reward set by the entity. In at least one embodiment, the data collected in the first region may have a different (e.g., higher or lower) value than the data collected in the second region.

In at least one embodiment, the supernode 125 may receive the same data from two different intermediate nodes, and the verification manager 210 may verify the activity of two of the different intermediate nodes. In some embodiments, for example, where the reward is a maximum reward with an upper limit, the validation manager 210 may split the reward or share the reward with two different intermediate nodes. The splitting or sharing may be equal or unequal. For unequal splitting or sharing, the validation manager 210 may take into account any metadata. For example, the validation manager 210 may determine a first delay associated with a first intermediate node when relaying data and a second delay associated with a second intermediate node when relaying data. The verification manager 210 may split rewards based on the latency. Any other metadata or any other data may be used to split the reward or share the reward with any number of different intermediary nodes. Additionally or alternatively, the validation manager 210 selects one of two different intermediate nodes to receive the entire reward. Similarly, the verification manager 210 may use any data to select one of two different intermediate nodes to receive the entire reward. Similar to the example above, the validation manager 210 may select the first intermediate node when a first latency associated with the first intermediate node is shorter (e.g., faster) than a second latency associated with the second intermediate node when relaying data.

In at least one embodiment, for example in an environment including a mesh network, a single intermediary device 115 may not be able to relay data to the supernode 125 alone. Instead, the plurality of intermediary devices 115 may relay the data through the mesh network until the egress intermediary device sends the data to the supernode 125. The reward may be divided among each of the intermediary devices that assist in relaying data to the supernode 125, for example. In at least one embodiment, the export intermediary may be given a higher portion of the reward due to its role as an export intermediary. In at least one embodiment, the export intermediary may be awarded the entire reward due to its role as an export intermediary.

The verification manager 210 may create activity and contribution records on both an individualized basis and an aggregated basis. For example, the verification manager 210 may create activity and contribution records associated with a particular user account (which may be associated with more than one intermediary device). In at least one embodiment, the verification manager 210 may create activity and contribution records in a hash tree data structure and store the hash in the data store 145 (e.g., IPFS). In at least one embodiment, the validation manager 210 can write the hash or a portion of the hash to the cryptocurrency transaction and/or blockchain.

In at least one embodiment, data received from the intermediary device may not be sent to destination node 135. The storage manager 215 may cause the data to be stored and indexed for later retrieval for verification or other purposes.

The insight manager 220 can generate various statistics and reports based on all data that contacts the supernode 125. For example, the insight manager 220 can identify how much activity was verified by a particular verification manager 210.

Network architecture 100 may be used to exchange any amount of data between any device capable of network-based communication in a manner different from conventional communication via the internet.

In an example, network architecture 100 may utilize existing smartphone infrastructure to create connectivity as an alternative to conventional internet communications. In at least one embodiment, the network architecture 100 may move data to the cloud in an initially delay tolerant manner, which may be useful for many types of IoT communications (e.g., firmware updates, state updates, log file storage, and micropayments). The intermediary device may include software running on a smartphone to periodically scan other devices, such as endpoint device 105, such as industrial devices, smart watches, wearable devices, logistics trackers, and environmental sensors. These endpoint devices 105 may connect with software clients running on smartphones to create large-scale wide area networks to move data to and within the cloud. The present disclosure may be used to authenticate communications via this new network.

Furthermore, it is estimated that 95% of the population is covered by some type of cellular service. The network architecture 100 may be deployed anywhere in the world and enable areas with lower connectivity to increase their connectivity. Further, the network architecture 100 may be used, for example, inEnabling software running on a smartphone provides coverage not achievable by conventional cellular networks. The user may travel to a region with limited or no cellular connectivity, but may still receive data from endpoint device 105 via wireless network 110. Using the network architecture 100, a telecommunications carrier, for example, can now easily deploy software updates to its user devices to begin communicating with the endpoint devices 105 described herein to provide higher latency IoT connectivity for the most remote regions of the world.

In a particular example, the network architecture 100 may be used for asset tracking and management. For example, the network architecture 100 may be used to find lost items configured as endpoint devices 105, such as skateboards with wireless radio chipsets, additional tracking beacons, bluetooth tags or notes, laptops, and the like. The user may indicate, for example, that the item is lost, such as by using a mobile application or web site to indicate the item is lost to the destination node 135 or to the supernode 125. In a first embodiment, the destination node 135 may send a message to one or more supernodes 125 to monitor for lost items. The supernode 125 may add an identifier of the lost item to the lost item surveillance list. As the intermediary device 115 moves to different geographic locations, it may receive data from different endpoint devices 105. The intermediary 115 then forwards the data to the supernode 125. When the supernode 125 server receives the data, the supernode 125 may analyze the data to verify whether the data originated from the endpoint device 105 on the watch list. When a supernode 125 identifies data originating from an endpoint device 105 on the watch list, the supernode 125 may notify destination node 135 that a missing item has been found. In at least some embodiments, the supernode 125 may send a notification that a lost item has been found as a push notification or as a pull notification (i.e., in response to a request from the destination node 135). In at least some embodiments, the supernode 125 may send a notification to a user device used by the user to indicate that the item was lost that the lost item was found.

Modifications, additions, or omissions may be made to network architecture 200 without departing from the scope of the disclosure. The present disclosure applies more generally to a network architecture 200 that includes one or more endpoint devices 105, one or more wireless networks, one or more intermediate devices 115, one or more second networks 120, one or more supernodes 125, one or more third networks 130, and one or more destination nodes 135, or any combination thereof.

Moreover, the separation of various components in the embodiments described herein is not intended to indicate that the separation occurs in all embodiments. Additionally, it should be appreciated that the described components may be integrated together in a single component or separated into multiple components with the benefit of the present disclosure. And vice versa; for example, as illustrated in FIG. 2, the routing manager 205, the verification manager 210, the storage manager 215, and the insight manager 220 are all part of a single supernode 125. However, the supernode 125 may contain all or a portion of all of these managers. For example, a supernode 125 dedicated to routing may include only a route manager. Similarly, a supernode 125 dedicated to authentication may only include an authentication manager 210. In such examples, the various managers may still communicate with each other, e.g., via a network. Further, any of the routing manager 205, the authentication manager 210, the storage manager 215, and the insight manager 220 may be part of or executable on any device. For example, intermediary device 115 may also include an authentication manager 210 that may authenticate the activities of intermediary device 115 as well as other intermediary devices. In such embodiments, authentication manager 210 may be physically or logically separate from other portions of intermediary device 115 in order to maintain the integrity of authentication manager 210.

Fig. 3 illustrates an example sequence diagram 300 of a process for verifying activity in a network. Sequence diagram 300 may include the components illustrated and described in fig. 1 and 2, the one or more endpoint devices 105, the one or more intermediate devices 115, the one or more supernodes 125, and the one or more destination nodes 135.

At 305, endpoint device 105 may generate data (e.g., beacons, data packets). At 310, the endpoint device 105 may broadcast the data. The intermediary device 115 may listen for data and, at 310, the intermediary device 115 may receive the data.

At 315, the intermediary 115 may add metadata to the packet. The metadata may include, for example, any of the metadata described herein, including a device identifier. In at least one embodiment, the device identifier may be anonymous, such as by using homomorphic encryption. In an example, the true identity of the intermediary device may be stored in a container that is only accessible using the key. Externally, anonymous identifiers may be used for the device. At 320, the intermediary 115 may send the data to the supernode 125 along with the metadata.

At 325, the supernode 125 may verify the activity of the intermediary device based on the metadata. For example, the supernode 125 may verify (valid/verify) that the intermediary device 115 actually received (or likely received) data from the endpoint device 105. At 330, the supernode 125 may provide an award to the intermediary device 115 (or to an account associated with the intermediary device 115) for the verified activity. At 335, the supernode 125 may optionally send the data to the destination node 135.

Fig. 4 illustrates another example sequence diagram 400 of a process for verifying activity in a network. Sequence diagram 400 may include the components illustrated and described in fig. 1 and 2, the one or more endpoint devices 105, the one or more intermediate devices 115, the one or more supernodes 125, and the one or more destination nodes 135.

At 405, destination node 135 may generate a message. The message may comprise any message, such as a response to receiving data. For example, destination node 135 may generate a response message regarding the data. The response message may include a message expected by one or more of the supernode 125, the intermediary device 115, the endpoint device 105 that generated the data, or another endpoint device 105 that did not generate the data. At 410, destination node 135 may send a response message to the same supernode 125 that sent the data to destination node 135, or to a different supernode 125 that did not send the data to destination node 135.

The supernode 125 may receive a response message from the destination node 135 regarding the data. The supernode 125 may process the response message, for example, by performing an operation at the supernode 125 or by sending data to the intermediary 115 at 415.

At 420, intermediary 115 may send the message to endpoint 420. At 425, the intermediary 115 may send an activity notification to the supernode 125 to notify the supernode 125 that the intermediary 115 has performed an activity to send the message to the endpoint device 105.

At 430, the supernode 125 may verify the activity of the intermediary device based on the activity notification. For example, the supernode 125 may verify (valid/verify) that the intermediary device 115 actually received (or likely received) data from the endpoint device 105. At 435, the supernode 125 may provide an award to the intermediary device 115 (or to an account associated with the intermediary device 115) for the verified activity.

FIG. 5 illustrates a flow diagram of an example method 500 related to authentication in a decentralized network. The method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both, which may be included in the intermediate device 115 and/or the supernode 125 of fig. 1, 2, 3, or 4, or another computer system or device. However, another system or combination of systems may be used to perform the method. For simplicity of explanation, the methodologies described herein are depicted and described as a series of acts. However, acts in accordance with this disclosure may occur in various orders and/or concurrently, and with other acts not presented and described herein. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methodologies could alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, the methods disclosed in this specification can be stored on an article of manufacture, such as a non-transitory computer readable medium, to facilitate transmission and transfer of such methods to a computing device. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage medium. Although illustrated as discrete blocks, the individual blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

FIG. 5 illustrates a flow diagram of an example method 500 for verifying execution of an activity in a decentralized network. For example, example method 500 may be performed to handle communications handled by an intermediary device (e.g., intermediary device 115 of fig. 1A or 1B).

The method 500 may begin at block 505, where processing logic may receive data from an intermediary device via a first network. The first intermediary device may comprise intermediary device 115a of fig. 1A or 1B. The data may have been received by the first intermediary device from an endpoint device (e.g., endpoint device 105a of fig. 1A or 1B) via a second network (e.g., wireless network 110a of fig. 1A or 1B). In at least some embodiments, the first network is a longer range network or a higher power network, as compared to the second network. The data may be associated with metadata associated with the data by the intermediary device.

At block 510, processing logic may extract one or more terms from the metadata, which may include identifying characteristics of the data. For example, the data may include data indicating a geographic location of the endpoint device and an identifier of the endpoint device. Identifying characteristics of the data may include scanning the data to identify data indicative of a geographic location of the endpoint device and an identifier of the endpoint device.

At block 515, processing logic may verify activity of the intermediary device based on the extracted one or more terms. In at least one embodiment, the extracted one or more terms may include at least one geographic location associated with the data or the intermediary device. In at least one embodiment, verifying the activity of the intermediary device based on the extracted one or more terms may include comparing a geographic location associated with the data or the intermediary device to an expected geographic location of the data. In at least one embodiment, verifying the activity of the intermediary device based on the extracted one or more terms may include verifying the activity of the intermediary device in response to a determination that the geographic location associated with the data or the intermediary device and the expected geographic location of the data are within a threshold geographic distance. In at least one embodiment, verifying the activity of the intermediary device based on the extracted one or more terms may include avoiding the activity of verifying the intermediary device in response to determining that the geographic location associated with the data or the intermediary device and the expected geographic location of the data are outside of the threshold geographic distance. In at least one embodiment, refraining from verifying the activity of the intermediary device may include applying a penalty to the intermediary device in response to the geographic location associated with the data or the intermediary device and the expected geographic location of the data being outside a threshold geographic distance.

In at least one embodiment, the extracted one or more terms may include a geographic location of the intermediary device. In at least one embodiment, verifying the activity of the intermediary device based on the extracted one or more terms includes identifying a set of intermediary devices based on a geographic location of the intermediary devices. Verifying the activity of the intermediary device may also include identifying a set of data collected by the set of intermediary devices. Verifying the activity of the intermediary device may further include comparing the extracted one or more terms to a set of data collected by a set of intermediary devices. Verifying the activity of the intermediary device may also include determining that the extracted one or more terms and the set of data collected by the set of intermediary devices are within the similarity threshold. Verifying the activity of the intermediary device may include verifying the activity of the intermediary device based on a determination that the extracted one or more terms and the set of data collected by the set of intermediary devices are within the similarity threshold.

At block 520, processing logic may create and store a record of the verified activity with reference to an account associated with the intermediary device. In at least one embodiment, creating and storing the record of the verified activity with reference to the account associated with the intermediary device may include appending the verified activity to an existing record of previously verified activity associated with the account. In at least one embodiment, creating and storing the record of the verified activities with reference to the account associated with the intermediary device may include creating a summary of each activity in the record, generating a hash of the summary, and storing the hash in a decentralized data storage system.

At block 525, processing logic may identify a reward for the verified activity based at least in part on one or more items from the metadata. At block 530, processing logic may assign the reward to an account associated with the intermediary device. In at least one embodiment, allocating the reward to the account associated with the intermediary device may include selecting the intermediary device from among a plurality of intermediary devices based on the extracted one or more items.

Fig. 6 illustrates a diagrammatic representation of a machine in the example form of a computing device 600 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. Computing device 600 may include a mobile phone, a smart phone, a netbook computer, a rack-mounted server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, or any computing device having at least one processor within which a set of instructions for causing a machine to perform any one or more of the methods discussed herein may be executed, etc. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an internal network, an external network, and/or the internet. The machine may operate in the capacity of a server machine in a client-server network environment. The machine may comprise a Personal Computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" may also include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computing device 600 includes a processing device (e.g., a processor) 602, a main memory 604 (e.g., Read Only Memory (ROM), flash memory, Dynamic Random Access Memory (DRAM) (e.g., synchronous DRAM (sdram)), a static memory 606 (e.g., flash memory, Static Random Access Memory (SRAM)), and a data storage system 616), which communicate with each other via a bus 608.

The processing device 602 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 602 may include a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 602 may also include one or more special-purpose processing devices, such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a network processor, or the like. The processing device 602 is configured to execute instructions 626 for performing the operations and steps discussed herein.

The computing device 600 may further include a network interface device 622 that may communicate with a network 618. The computing device 600 may also include a display device 610, such as a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT), an alphanumeric input device 612, such as a keyboard, a cursor control device 614, such as a mouse, and a signal generation device 620, such as a speaker. In at least one embodiment, the display device 610, the alphanumeric input device 612, and the cursor control device 614 may be consolidated into a single component or device (e.g., an LCD touch screen).

The data storage 616 may include a machine-readable storage medium 624 on which is stored one or more sets of instructions 626 embodying any one or more of the methodologies or functions described herein. The instructions 626 may also reside, completely or at least partially, within the main memory 604 and/or within the processing device 602 during execution thereof by the computing device 600, the main memory 604 and the processing device 602 also constituting computer-readable media. The instructions may further be transmitted or received over a network 618 via a network interface device 622.

While the computer-readable storage medium 626 is shown in an example embodiment to be a single medium, the term "computer-readable storage medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

Terms used herein, and particularly in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" can be interpreted as "including (but not limited to)", the term "having" can be interpreted as "having at least," the term "including" can be interpreted as "including (but not limited to)").

Additionally, if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" or "an" may be interpreted to mean "at least one" or "one or more"); the same holds true for the use of definite articles used to introduce claim recitations.

In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation may be interpreted to mean at least the recited number (e.g., the bare recitation of two recitations, without other modifiers, "means at least two recitations, or two or more recitations). Further, in those instances where a convention analogous to "at least one of A, B and C, etc." or "one or more of A, B and C, etc." is used, in general, such a construction is intended to include a alone, B alone, C, A and B together, a and C together, B and C together, or A, B and C together, etc. For example, use of the term "and/or" is intended to be interpreted in this manner.

Furthermore, any disjunctive word or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, may be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" may be understood as a possibility to include "a" or "B" or "a and B".

The embodiments described herein may be implemented using a computer-readable medium for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise non-transitory computer-readable storage media including Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), compact disc read only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium that can be used to carry or store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

Computer-executable instructions may include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used herein, the term "module" or "component" may refer to a specific hardware implementation that is configured to perform the operations of the module or component and/or a software object or software routine that may be stored on and/or executed by general purpose hardware of a computing system (e.g., a computer-readable medium, a processing device, etc.). In some embodiments, the different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). Although some of the systems and methods described herein are generally described as being implemented in software (stored on and/or executed by general purpose hardware), specific hardware implementations or combinations of software and specific hardware implementations are possible and contemplated. In this description, a "computing entity" may be any computing system or any module or combination of modules running on a computing system as previously defined herein.

All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although the present disclosure has been described in detail, it should be understood that various changes, substitutions, and alterations can be made hereto without departing from the spirit and scope of the present disclosure.

27页详细技术资料下载

上一篇：一种医用注射器针头装配设备

下一篇：端口扫描检测

Authentication in decentralized networks

相关技术

网友询问留言