Patent Application
20190066067
The present disclosure relates to collaborative sharing of digital currency, and more specifically to distributing digital currency among two or more wireless devices.
As the Internet of Things continues to evolve, communications between devices continues to evolve. For example, autonomous cars are being designed to use mesh networks for communications between cars, such that every car is aware of the speed, direction, braking, etc., of the other cars. Drones and Unmanned Aerial Vehicles are being similarly designed, allowing unprecedented coordination. Similarly, devices within the home, such as thermostats and light switches, can communicate with one another to save power and improve power efficiency.
However, while the currently available communications between devices or vehicles allow for more informed devices, they do not necessarily improve other aspects of the devices. For example, having more informed devices does not, by itself, provide for collaborative computing, collaboratively storing data in databases, collaboratively sharing battery power, and/or collaboratively sharing digital currency between those informed devices.
A method for performing concepts disclosed herein can include: identifying, via a processor at a first device in a plurality of devices, a need for additional digital currency to complete a task; transmitting, via a wireless mesh network, a request for the additional digital currency to one or more member devices in the plurality of devices, wherein the request indicates a planned computing state required to share the additional digital currency; receiving, via the wireless mesh network and from the one or more member devices in the plurality of devices, a plurality of responses to the request, wherein each response in the plurality of responses contains a binary competence of a respective member device in the plurality of devices to provide the additional digital currency; aggregating, via the processor, the plurality of responses to the request until a predefined time period expires, to yield aggregated responses, wherein the aggregated responses comprise a state of digital currency being used by each device in the plurality of devices when the request was made; modifying the planned computing state based on the aggregated responses, to yield a modified planned computing state, wherein in the modified planned computing state the need for additional digital currency is received by the first device from and at least one additional member device in the plurality of member devices; initiating the modified planned computing state within the first device; transmitting instructions to the at least one additional member device to execute the modified planned computing state to transfer at least a portion of the additional digital currency; and receiving, at the first device, the additional digital currency from the at least one additional member device.
A system configured as disclosed herein can include: a processor; and a computer-readable storage medium having instructions stored which, when executed by the processor, cause the processor to perform operations comprising: identifying, at a first device in a plurality of devices, a need for additional digital currency; transmitting a request for the additional digital currency to one or more member devices in the plurality of devices, wherein the request indicates a planned computing state required to achieve the additional digital currency; receiving, from at least one member device in the plurality of devices, at least one response to the request, wherein the at least one response contains a binary competence of the at least one member device to provide the additional digital currency; and initiating, based on the binary competence, the planned computing state based on the at least one response to the request.
A non-transitory computer-readable storage medium configured as disclosed herein can have instructions stored which, when executed by a computing device, cause the computing device to perform operations which include: identifying, at a first device in a plurality of devices, a need for additional digital currency; transmitting a request for the additional digital currency to one or more member devices in the plurality of devices, wherein the request indicates a planned computing state required to share the additional digital currency; receiving, from at least one member device in the plurality of devices, at least one response to the request, wherein the at least one response contains a binary competence of the at least one member device to provide the additional digital currency; and initiating, based on the binary competence, the planned computing state based on the at least one response to the request.
Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
Systems, methods, and computer-readable storage media configured according to this disclosure are capable of distributing digital currency among two or more devices. Digital currency can be used by the devices to perform tasks, computations, consume power, communicate with other devices, etc. For example, in some configurations, each device in a group of devices can receive an allocation (or an allowance) of digital currency each day, week, month, or other time frame. As each device then performs tasks, their digital currency is used to “pay” for the ability to do the task. When a device determines that it needs additional digital currency to complete a task, it can send a request to other devices requesting that those other devices provide at least a portion of the digital currency which is needed. This distribution request can, for example, be broadcast through a mesh network between devices, until all the devices within a group, or within a radius of the initial requesting device, have received the request. As devices receive the request, responses to the request are generated and sent back to the requesting device, each response providing an answer as to the ability of each respective device to fulfill the request. The requesting device can receive the responses, aggregate and/or analyze the responses, and determine how to transition information and resources to a new configuration where the digital currency can be received based on the responses. In some cases, enabling this configuration can require transferring information from the requesting device to another device through the mesh network. In addition, enabling the configuration can require modifying computing capacities or configurations at the requesting device as well as other devices within the group of devices. These changes would be broadcast to the group through the mesh network, with any computing resource transitions likewise similarly being broadcast to the group.
Consider the following example. A smart home is configured with a smart thermostat, smart refrigerator, smart washing machine, smart dryer, smart microwave, and a smart oven. Each of these devices are capable of being remotely controlled and configured by a user through a WiFi connection each device has with a WiFi network. In addition, the smart devices within this smart home can communicate with one another, such that the smart thermostat can communicate with the smart microwave, the smart refrigerator can communicate with the smart washing machine, etc. In some configurations, such communications can utilize a mesh network (i.e., each device communicates with the other devices directly using RF, low power, Bluetooth, or other wireless short range communication mechanisms, or if direct communication is not possible due to power or range restriction, indirectly through communication relays provided by another device in the group), whereas in other configurations the communications occur directly though the Wifi network.
As a device in the smart home begins an assigned task (or tasks), the device can determine if the device has enough digital currency to complete the task. If not, or if performing the task would result in the device having a shortage of digital currency for future tasks, would requesting additional digital currency from other devices likely outweigh the costs of sending a request to other devices, receiving responses, and making adjustments based on those responses?
This determination as to whether sending a request would likely be desirable can be based on historical data. More specifically, the device making the request can determine if similar requests in the past proved to result in increased efficiency, or if they resulted in wasted resources. In addition, the device making the request can identify a range where, based on responses, it may make the request despite a statistical calculation indicating that the likely result will be wasted resources.
In some configurations, communications between the devices can take the form of a blockchain, where each request and response made by devices can be added to the blockchain ledger. As any device takes an action (sending a request, sending a response to a request), that information is added to the blockchain. More specifically, the request, response, or other action is hashed into the previous blockchain. This new, updated blockchain is then distributed to the other devices within the group. Similarly, in some configurations, the digital currency being used and/or traded can be a blockchain based digital currency.
In some configurations, requests for resources, and responses to the request, can take the form of a binary competency. For example, whereas a normal request for help may result in a binary response from a responding device, where providing a “1” indicates the responding device is able to meet the request and a “0” indicates the responding device is unable to meet the request, with a binary competency response an array of values indicates just how capable the responding device is to fulfill the request. In one example, if a first device requests that the second device provide an amount “X” of digital currency, the second device could provide a response indicating it is not fully able to meet that demand, but can assist to a degree. An exemplary response may take the form of “0000001000”, a ten-digit binary response, where each binary digit represents a percentage of competence for the second device to fulfill the request. In this example, the “1” is found at the seventh digit, indicating that the second device is 70% capable of providing the “X” digital currency requested, or that the second device can provide an amount “Y”, but not “X”.
The example of an array of binary digits indicating competence to fulfill a request, with each binary digit expressing the responding device's ability to fulfill the request within 10% windows, can vary according to needs and precision desired. For example, the binary competence can have a longer length/shorter corresponding windows. If more than one factor is being requested (i.e., resources in a specified time window), the binary competence can have multiple arrays indicating competence based on availability. Alternatively, the binary competence can be one extended array, with different portions of the array providing distinct details about the responding device's capabilities and availability.
The example of a smart home is provided above. However, in other circumstances the devices may be unmanned or autonomous vehicles, drones, robotics, communication devices, or any other electronic device. For example, in one configuration the devices communicating availability may be delivery drones, whereas in another configuration the devices may be autonomous vehicles or smart home devices. In yet another configuration, the devices may be distinct types of devices, such as a drone and smart home devices communicating, making requests, and generating responses to those requests.
Distributing digital currency, or collaborative sharing of digital currency, among the devices can include sharing processor and/or memory utilization. By implementing the requests/responses, the devices within a group can determine which devices are unused, under utilized, or in use, and will allow the entire group of devices to share the computing power workload through sharing of digital currency. In other words, devices in the group can collaborate using distributed intelligence as it relates to their respective computing power/digital currency requirements and can make decisions on sharing the combined digital currency as needed to meet the overall computing power workload. To do this, each device has a predictive element as part of its operations, whereby each of the devices understands its own peaks and troughs of performance, and can be ready to share their digital currency based on that understanding. This can help with registry and shared repository information of devices within the network, failing devices, backup and recovery of information, etc. For example, the group of devices may share a registry redundantly among themselves or on the cloud which would also provide a method of failover from one device to another, or from the cloud. In other words, just because a smart toaster burns up does not mean the data about bread consumption is lost.
The information shared on or between devices (i.e., on the mesh network) will do so in a peer-peer network of devices that is decentralized. That is, all devices have the potential for sharing and distributing information on the digital currency needed. This system can be authenticated, shared, and managed, by a block chain system for authentication and decentralization. For instance, if a first device receives a request from an individual, such as order groceries, yet the first device lacks the digital currency to fulfill the order, the first device can relay an initial block chain of information, as a request, to all other devices in the group. This request can contain the grocery list, time stamp, digital currency required, authentication information, etc. Other devices within the group will receive and authenticate the transmission, then provide digital currency to solve the request from the first device. This in turn causes an update to the previous block within the block chain, which will contain the “slave” (second) device's updates with the original “master” initial block (the request). Thus, information will be accurately shared between the devices with the necessary information, including updates, etc.
By sharing the data and information between devices, replacement devices can be swapped and retain the history from the prior devices once the devices make the association. An association can be made either by manufacture's data from a web site using an API call, or by a user making the association. For example, a broken coffee maker version 1 may be replaced by version 2 and the version 2 machine would gather the version 1 data from the network once it is registered into the network. All the data associated with version 1 would now carry over to the version 2. Data could be when different coffees were used, how many cups, and when predicted inventories of coffee need to be replenished. What would not carry over would be the old version 1 maintenance schedule, if there was one. If the coffee maker was swapped out for a different type of coffee maker, the user may have to do the association through the new coffee machine to let it know it needs to retain the old coffee maker data. This may not be automatic because in some instances a location may want to use more than one coffee maker and still keep the old information. In such circumstances it would not be a replacement, but rather an addition.
The information shared and transmitted between devices (such as requests for assistance, responding to requests for assistance, authentication, digital currency, and protocol sharing), can utilize block chain or other authentication methods. Exemplary data which can be stored on a device (and transmitted/received between devices as required) can include a history log, a usage of the device, consumption of power (or other measurement of use), maintenance performed, downtime, consumption of products or other received elements, digital currency available, and/or schedule for future usage.
To share digital currency can require moving data, updating or changing processors, modifying memory, or other similar tasks. In one example, a device is scheduled to perform a task but determines it would be faster, or could be better performed, if another device shared digital currency with the device. One way the device can do this is by planning a sharing configuration, where the digital currency required for the task is divided between the device and another device in a planned manner, then sending the sharing configuration to other devices to determine availability. If another device can assist, the initiating device could send out a signal to the other device to alter its configuration (i.e., processor or memory) to share the digital currency as instructed by the initiating device. Simultaneously, the initiating device can modify its configuration according to the planned sharing configuration.
In addition, the device can send a request to other devices inquiring about the ability of the other devices to share digital currency. Upon receiving the responses to the request, the initiating device can aggregate and analyze the responses, then determine based on the aggregated/analyzed data how to receive the digital currency and may, if needed, divide up the sources of that digital currency between multiple devices. Such determinations can result in the planned sharing configuration, which could be sent to the other devices in the group. The initiating device and the other devices could then modify their respective configurations to match the planned sharing configuration and share the digital currency accordingly.
Various specific embodiments of the disclosure are described in detail below. While specific implementations are described, it should be understood that this is done for illustration purposes only. Other components and configurations may be used without parting from the spirit and scope of the disclosure, and can be implemented in combinations of the variations provided. These variations shall be described herein as the various embodiments are set forth. The disclosure now turns to
A supervisor 112 can be, for example, an application (“app”) on a smartphone which organizes the information associated with the IoT devices 102, or a human being operating the app. This supervisor 112 can help with resource handling 128, where the specific resources for each device are organized and scheduled. This resource handling 128 can, for example, be performed on an IoT server 126. Communications with the access point 118 can further include mechanisms via the Internet 124 and/or other computers 130.
When requesting and distributing digital currency, the various exemplary devices illustrated in
In the case of distributing computational requests, and reallocating computational tasks among the various devices based on the responses to the requests, the blockchain can take the form illustrated in
As the device generates the block 302 for the initial request, the block 302 is hashed 312 into the previous blockchain 304, resulting in an updated blockchain which is distributed among the devices in the group. The other devices receive the updated blockchain containing the request 332 and generate blocks 314 in response to the request. These responses are hashed 316 into the blockchain. In some scenarios, an additional block could be generated by the initiating device based on the response blocks 314, indicating what action will be taken based on the responses received.
When a device completes the request 334, that device generates a block 318 which is subsequently hashed 320 and added to the blockchain. If a completion notice 336 needs to be generated and sent to the initiating device, the completing device can generate another block 322, which can similarly be hashed 324 and added to the blockchain. Once the initiating device receives the completion notice 338, it may generate a notification indicating the request has been fulfilled, which would similarly require a block 326 to be generated and hashed 328 into the blockchain.
If the transition needs to occur, and the transition will involve other members of the group of devices, requests for assistance can be distributed to other devices within the group 406. In addition, the device (or another device) can initiate a state transition 408, where the configuration of the network of devices can be will be modified. For example, if a task needs to be shared among multiple devices, the processor, memory, or other aspects of the computing systems can be modified to transition to a new configuration, or state, to accommodate that shared task. In some cases, the requesting device can identify what this state would look like and communicate that state to other devices within the request, whereas in other instances the state transition 408 can be initiated after receiving responses 410 from devices within the group.
In response to the requests distributed to the group 406, responses are received from the group of devices, which the initial device aggregates and analyzes 410. Based on these responses, the initiating device can initiate a transition 412 to a new configuration which will allow the task in question to be performed. The initiating device advertises the final decision to the group 414, the task is completed in the new configuration (i.e., with data or digital currency redistributed, computing or other tasks shared, and/or using updated processes). At this point the process can return to the initial diagnostic algorithm 402 for the device.
The device can then aggregate, via the processor, the plurality of responses to the request until a predefined time period expires, to yield aggregated responses, wherein the aggregated responses comprise a state of digital currency being used by each device in the plurality of devices when the request was made (608). The device can modify the planned computing state based on the aggregated responses, to yield a modified planned computing state, wherein in the modified planned computing state the need for additional digital currency is received by the first device from and at least one additional member device in the plurality of member devices (610). The device can then initiate the modified planned computing state within the first device (612) and can transmit instructions to the at least one additional member device to execute the modified planned computing state to transfer at least a portion of the additional digital currency (614). The device can then receive, at the first device, the additional digital currency from the at least one additional member device (616).
In some configurations, this method can be augmented to include planning a state transition to the modified planned computing state based on a local computing power algorithm at the first device Likewise, in some configurations, the method can include sharing a final decision indicating that the modified planned computing state will be initiated to the plurality of devices by updating a block chain ledger shared among the plurality of devices and initiating the modified planned computing state subsequent to sharing the final decision.
Moreover, the exemplary method can, for example, require that at least one response in the plurality of responses is incorporated into a block chain. Similarly, in some configurations, the binary competence can indicate a degree to which each member device in the plurality of devices may be able to assist with the request. Furthermore, initiating the modified planned computing state can comprise reallocating computing resources within at least one of the processor and a memory electronically connected to the processor.
In some configurations, each device in the plurality of devices can analyze a potential impact associated with the planned computing state based on a dependency tree that describes relationships among the plurality of devices, and determine whether the each device may assist with the planned computing state based on a potential impact to the each device. In such configurations, it may be that when a member device in the plurality of devices has no digital currency available the member device does not send a response to the request. Similarly, at least one member device in the plurality of devices can be designated as a proxy device to determine whether to approve or disapprove the planned computing state on behalf of the at least one member device.
It is noted that components, elements, features, and/or limitations of this method can be combined as needed for specific configurations. For example, another exemplary method using this disclosure may be: identifying, at a first device in a plurality of devices, a need for additional digital currency; transmitting a request for the additional digital currency to one or more member devices in the plurality of devices, wherein the request indicates a planned computing state required to achieve the additional digital currency; receiving, from at least one member device in the plurality of devices, at least one response to the request, wherein the at least one response contains a binary competence of the at least one member device to provide the additional digital currency; and initiating, based on the binary competence, the planned computing state based on the at least one response to the request.
With reference to
The system bus 710 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM 740 or the like, may provide the basic routine that helps to transfer information between elements within the computing device 700, such as during start-up. The computing device 700 further includes storage devices 760 such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive or the like. The storage device 760 can include software modules 762, 764, 766 for controlling the processor 720. Other hardware or software modules are contemplated. The storage device 760 is connected to the system bus 710 by a drive interface. The drives and the associated computer-readable storage media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device 700. In one aspect, a hardware module that performs a particular function includes the software component stored in a tangible computer-readable storage medium in connection with the necessary hardware components, such as the processor 720, bus 710, display 770, and so forth, to carry out the function. In another aspect, the system can use a processor and computer-readable storage medium to store instructions which, when executed by the processor, cause the processor to perform a method or other specific actions. The basic components and appropriate variations are contemplated depending on the type of device, such as whether the device 700 is a small, handheld computing device, a desktop computer, or a computer server.
Although the exemplary embodiment described herein employs the hard disk 760, other types of computer-readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs) 750, and read only memory (ROM) 740, may also be used in the exemplary operating environment. Tangible computer-readable storage media, computer-readable storage devices, or computer-readable memory devices, expressly exclude media such as transitory waves, energy, carrier signals, electromagnetic waves, and signals per se.
To enable user interaction with the computing device 700, an input device 790 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 770 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 700. The communications interface 780 generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Various modifications and changes may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.
| Number | Date | Country | |
|---|---|---|---|
| 62551444 | Aug 2017 | US |
