Computer-Implemented Method and System

Abstract

The present invention relates to a computer-implemented communication method. The method includes a mechanism for service provisioning from a service provider to one or more devices within a plurality of devices controlled by or associated with a device controller. In an exemplary embodiment, the service provider assigns a set of IPv6 addresses to the device controller. The device controller then assigns or communicates one or more of the set of IPv6 addresses to at least one of the devices. The device then includes the one or more IPv6 addresses received from the device controller in an access request to the service provider. After verifying that the requesting device is authorized by the device controller, the service provider provides service to the one or more addresses included in the access request.

Description

[Technical Field]

[0001] The embodiments disclosed herein relate to improvements to the transmission of data, e.g., packets of data, over a computer-implemented network. The embodiments are particularly, but not exclusively, suited for the transmission of data related to service provisioning between a service provider and at least one service recipient. The service provider may also be known herein as a “data provider.” The service (i.e., data) recipient may be a controller of multiple devices, each of which requires receiving and / or transmitting data between a separate device and the service provider. The embodiments provide enhanced control, transmission, and / or monitoring of such data-related services over an electronic network between the service provider and the controller's multiple devices. The embodiments also provide improved verification and permissioning techniques for multiple devices owned or controlled by a common controller. Preferred embodiments provide a solution that includes a combination of public key infrastructure (PKI) and mobile IP (MIP), and some embodiments may utilize blockchain for access control, device verification, and authorization process execution. [Background technology]

[0002] Devices on the Internet are assigned a unique identifier (an address) that enables them to be identified by other devices and to locate them on the network. The original IP protocol was built with the expectation that the number of IP addresses that could be generated from a 32-bit address block would be sufficient to uniquely identify every device connecting to the Internet. However, the overwhelming appeal of the Internet to individuals and businesses, nor the variety and volume of devices seeking to connect to the Internet, was not anticipated when the original IP protocol was designed. As a result, with the growth of personal and mobile computing technology, it soon became clear that the 4.3 billion addresses possible with IPv4 were insufficient.

[0003] The threat of IPv4 address exhaustion has spawned some creative ways to mitigate the limited set (e.g., classless addressing (CIDR), unnumbered interfaces, network address translation), but these measures have not been sufficient to address the problem. The emergence of the Internet of Things (IoT) is set to further exacerbate IPv4's limitations in both the short and long term.

[0004] Due to these challenges, IPv6 was proposed as a replacement for the IPv4 address standard. At its core, IPv6 has a theoretical 3.4 x 10 38 The first major advance was the use of 128-bit addresses, which can generate 128 addresses. While some ranges of the key space have been pre-designated for specific purposes, the remaining address space is large enough to meet the current and future needs for each resource connecting to the Internet to have its own unique IPv6 address. While the most significant advantage of IPv6 is its large address space, there are several other advantages that IPv6 is expected to offer. These include the IPv6 approach to multicast and anycast, as well as implementations such as Mobile IPv6 and Proxy Mobile IPv6 (PMIPv6).

[0005] Multicast, which allows a data packet to be sent to multiple destinations in a single send operation, is inherent in the base specification of IPv6. In IPv6, packets are sent to a multicast group address, which then transmits the packet to the members of the group. On the other hand, anycast transmission in IPv6 allows a source resource to send a data packet to a group address, but only one receiver in the group (the receiver topologically closest to the sender) receives the transmitted data.

[0006] The group subscription model of multicast and its incorporation into the IPv6 protocol leads to increased efficiency in sending data packets over the Internet and reduced network congestion compared to other methods of transmitting / casting packets, such as unicast and broadcast. Unicast is a one-to-one connection where a packet is sent from one IP address to another. Broadcast is a one-to-all transmission where a packet is sent to all addresses / nodes in a network. Therefore, the use of multicast in IPv6 provides a more efficient and scalable solution for transmitting data over the Internet.

[0007] In situations where a controller has multiple devices that require service from a service provider, challenges arise, including, but not limited to, how the device controller manages aspects of the PKI between devices and how the service provider can verify that requests from a particular device are authorized by the controller without repeatedly returning to the controller to confirm the device's authorization. In the latter scenario, such repeated authorization of individual devices by the controller is not only inefficient in terms of time and processing, but also creates potential abuse by third parties who can eavesdrop on communications and places an undue processing burden on the controller. This also reduces the scalability of the system and reduces resilience by centralizing permissioning responsibility in the controller. These challenges are exacerbated in dynamic, frequently changing environments where many devices may be joining or leaving the controller's group.

[0008] Therefore, a solution is needed that addresses at least these challenges. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] International Publication No. WO2017 / 145016 [Patent Document 2] International Patent Application No. PCT / IB2017 / 050856 Summary of the Invention [Means for solving the problem]

[0010]

[0003] Embodiments of the present disclosure provide solutions for the transmission of data over computer-based networks. In particular, embodiments include the integration and use of PKI, cryptographic keys, and IP address blocks for entities (e.g., users) associated with multiple devices. Ideally, although not necessarily, embodiments may also incorporate the use of Mobile IP (MIP) and / or blockchain technology.

[0011] Embodiments of the present disclosure involve the use of a cryptographic key for access by a first entity / user to a service provided by a second entity / user. Preferably, the key holder (or one or more entities / users authorized by and / or on behalf of the key holder) is the only party who can access the service. Preferably, ownership of the key remains secret, thereby preserving the user's privacy.

[0012] A service provider may offer any type of digital service over an electronic network or communication channel for consumption by an electronic device associated with a first user. This may include the provision of data for any end use, in any format, and for any purpose. As such, the service may be referred to as a "data service." In some examples, the service may be cloud-based. The data may include the provision of multiple packets over a network. The electronic device is not limited to any particular form of hardware, software, or purpose, but may include mobile phones, laptops, drones, vehicles and transportation equipment, desktop computers, IoT devices, wearable devices, and more.

[0013] Here, we refer to the first entity / user as the "device controller" to distinguish this entity from the end users of the individual devices that belong to, i.e., are under the control or authority of, the first user. The term "device" is used broadly herein for convenience and should be interpreted to include both a single, standalone device and a collection of related devices or systems.

[0014] In an exemplary embodiment, a device controller is associated at the service provider with at least one of an assigned IP address and at least one master encryption key or key pair. Each master key may be associated with one or more sets or subsets of assigned IP addresses, and vice versa. Hereinafter, when we refer to a set of addresses, we mean at least one address; the set may be a subset of a larger set of addresses or may include at least one subset of addresses. In embodiments where multiple address sets are associated with (i.e., assigned to) the same device controller, a different master key may be linked to each address set, although this is not necessarily true in all embodiments. In some embodiments, the IP block may be an IPv6 block that may be assigned to device controllers that include or are associated with multiple computing resources (devices). One or more addresses in the set may be IPv6 multicast or anycast addresses.

[0015] Non-limiting examples of device controllers may include a department, group, or section within a company, organization, or other entity; e.g., a household; or an authorized party that is a signatory or participant in an agreement such as a contract, e.g., personnel performing a designated role or occupation; members of a military regiment or group; a vehicle dealership or business that owns a fleet of autonomous vehicles. For example, if the device controller is a member of a household, e.g., a parent, associated devices may include laptops, cell phones, electric vehicles, etc. owned or operated by different family members in the household. In another non-limiting example, the device controller may manage a group of workers or operators (e.g., emergency personnel, soldiers, salespeople, autonomous vehicles, etc.) who are each associated with a transmitting device so that the location of the device and any other relevant data can be monitored at a location such as a home, headquarters, office, car showroom, etc.

[0016] The device controller may then assign one or more addresses from a respective one or more of the assigned address sets (or subsets) to at least one designated device in a group of associated (controlled) devices. The device controller may assign at least one subkey to at least one of the designated devices. The subkey may be derived from a master key associated with (e.g., generated or controlled by) the device controller. The subkey may be generated in a deterministic manner such that it is provably derived from the master key (or another subkey derived from the master key).

[0017] When a device desires to access a service of a service provider, the device may provide a cryptographically signed access request to the service provider. The request may include an identifier that allows the service provider to identify the service provider. For example, the request may include an account number or cryptographic key that the service provider recognizes as associated with the device controller.

[0018] In some embodiments, the request may be signed by the requesting device using the device controller's master key or its own deterministic subkey, which may allow the service provider to identify the device controller from the request and / or facilitate verification of the device controller's authorization of the request.

[0019] Additionally or alternatively, the access request may include a key that allows the service provider to extract a copy of the key from the request. The access request may also include an indication of the assigned IP address. After receiving the request, the service provider can check which IP block the device's IP address belongs to and determine the master key associated with that IP block. If the device provides a subkey instead of a master key, the service provider can verify that the subkey is derived from a master key recorded in a storage facility associated with the device controller.

[0020] If the (sub)key provided by the device in the request does not match or cannot be verified as derived from the master key of the device controller associated at the provider with the device controller and / or IP address indicated in the request, the service provider may reject the request and deny access to the data-related service. Alternatively, if the verification is successful, the service provider may grant access to the data service. This may include transmission of data from the service provider or another entity on its behalf to the IP address indicated in the request. If the indicated IP address is a multicast address, this may allow the provider's service to be distributed to multiple members of that multicast address.

[0021] Thus, embodiments may provide at least the benefit of efficient, secure, pseudonymous provisioning of data and services to multiple receivers, one, some, or all of which may be a multicast group or an anycast group, further enhancing the delivery of services and data to multiple receivers.

[0022] Advantages include, but are not limited to, the following aspects: Authorized receiving devices can be dynamically added or removed by the device controller without any processing or cost impact to the service provider. This is useful in situations where a controlling entity wants to provide specified data services temporarily to authorized devices, e.g., hotel guests for the duration of their stay, employees using their company cell phones during work hours, etc. The assigned addresses can be multicast, unicast, or anycast addresses, which means that data can be delivered from the service provider to one or many recipients in an efficient and fast manner. Embodiments allow data provisioning to devices based on subkeys generated from the authorized device controller's master key, so that access can be pseudonymous. This can be useful, for example, in situations where the device controller is not authorized or willing to share information related to the device's end user, but can provably track devices that have requested access using deterministic and provable subkeys.

[0023] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0024] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 is a diagram illustrating schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 1 is a schematic block diagram of a blockchain-based client application. [Figure 3B] 3B is a schematic diagram of a mock-up of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 is a schematic block diagram of some node software for processing blockchain transactions. [Figure 5] FIG. 1 is a diagram of one embodiment of the present invention showing how resources in a multicast group communicate with each other to deliver electronic data securely, efficiently, and quickly. [Figure 6a] FIG. 1 is a diagram illustrating an example of an IPv4 address in dotted decimal notation. [Figure 6b] FIG. 10 is a diagram showing an example of an IPv6 address in hexadecimal notation. [Figure 6c] FIG. 1 illustrates how address prefixes can be reserved to represent IPv6 address types. [Figure 7] 1 illustrates a unicast transmission of a data packet from a server's address to a global unicast address of a computer (shown as PC1). [Figure 8] For comparison with the unicast transmission of FIG. 7, we now show a multicast transmission in which data packets sent by a server are routed through the Internet to a multicast address and retrieved by subscribers. [Figure 9] For comparison with Figures 7 and 8, this figure shows an anycast transmission in which a server sends a data packet to an anycast address, and the data packet is forwarded to the topologically closest router / node of the resource's subscribed set. [Figure 10]FIG. 1 illustrates the propagation of data through a network, such as a blockchain network or other network. [Figure 11] FIG. 1 illustrates an exemplary embodiment of the present disclosure in which nodes of a network perform multicast transmissions of one or more portions of data. [Figure 12] FIG. 1 illustrates an exemplary embodiment of the present disclosure in which nodes of a network perform anycast transmissions to an anycast address. [Figure 13] 1 illustrates a node B on a network broadcasting via multicast transmission to multiple nodes N1 to N4 in the network. [Figure 14] FIG. 1 illustrates a node B on a network broadcasting via a multicast transmission to an assigned address via each of eight outputs to nodes N1 through N8 in the network. [Figure 15] 1 illustrates a node B on a network receiving data from node A and broadcasting it via multicast transmission to assigned addresses represented by multiple nodes N1 to N4 in the network. [Figure 16] FIG. 1 illustrates node B on a network that subscribes to receive broadcasts multicasted from nodes C, D, and E, and broadcasts to an assigned address via multicast transmission to each of eight outputs to nodes N1 through N8 in the network. [Figure 17] FIG. 1 illustrates a Node B transmitting packets of data to a multicast group, a first subscriber, and a second subscriber, the second subscriber optionally further transmitting packets of data to the first user directly or via a second multicast group. [Figure 18]FIG. 1 illustrates a Node B transmitting eight packets of data to eight respective multicast groups, a first subscriber that subscribes to and accesses packets of data from two of the eight multicast groups, and a second subscriber that optionally aggregates the eight packets of data and transmits them to a ninth multicast group, thereby providing the first subscriber with alternative access to the eight packets of data. [Figure 19] FIG. 1 illustrates a Node B transmitting eight packets of data to eight respective multicast groups, and six subscribers, such as drones, accessing one or more packets of data. [Figure 20] 1 is a flowchart illustrating steps potentially taken by a participant in a method according to some embodiments of the present disclosure. [Figure 21] FIG. 1 illustrates some of the possible components of a system configured according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0025] Next, with reference to the accompanying figures, exemplary embodiments that can be used to provide the technical effects and advantages of the present disclosure will be presented.

[0026] In an exemplary embodiment, computer-based resources may be associated to form one or more multicast groups, each group having its own respective multicast address. The multicast group address is a logical, collective identifier for the resources in the group so that they can all receive data packets from a sending node via multicast communication. In some embodiments, the address is an IPv6 multicast address, and data is sent and received over the Internet.

[0027] FIG. 5 illustrates each of three multicast groups of resources communicating with each other. The communication may include sending one or more packets of data in a transmission. The data may be, but is not necessarily, blockchain-related data. In some embodiments, the data may be any type of data provided from a service provider to a device controlled (and / or owned) by a device controller. There may be multiple devices controlled by a device controller. These devices may take any form or be used for any purpose. Herein, the term “device” may be used interchangeably with “computing resource” or “system” to include multiple individual devices. Each device may be operated by one or more human operators or may be automated such that the device's behavior and / or function is influenced or directed by a portion of machine-executable code.

[0028] When using multicast, a multicast group, e.g., group 502a, may send data to the same group 502a and / or to another multicast group, e.g., 502b, in the form of a single transmission to a single multicast address corresponding to or associated with multicast group 502a / 502b. In this way, only one transmission is sent, and only (but not all) resources that are members of the receiving multicast group receive the data.

[0029] When using anycast, resources 501 of a multicast group, e.g., group 502a, may transmit data to the same group 502a or to another multicast group, e.g., 502b, by sending the data in the form of a single transmission to a single anycast address corresponding to or associated with multicast group 502b. The data packet is routed to resources 501 of multicast group 502b that are determined to be topologically closest to the transmitting resource. The receiving resource may then forward the data to one or more of the other resources of multicast group "b," or to any other resource in one or more other groups, or even to any other resource that is not part of any group. In this way, only one data transmission is sent to a single receiver in a particular group, but the data can then be spread throughout the other members of the group via multicast transmission. This is advantageous in situations where only one or a subset of the multicast group needs to receive the transmission to provide the data to the entire group. Similarly, resources in a multicast group may transmit or receive data using multicast or anycast.

[0030] When using multicast, resources of a multicast group, e.g., group "b," may transmit data, such as data requested in response to such a request, by sending the data to multicast group "a" in the form of a single data transmission to a single multicast address corresponding to multicast group "a." In this manner, only one data transmission instance is required, and only member resources of multicast group "a" receive the data. In this embodiment, the transmitting resources may be referred to as "transmitting resources," and the member resources of multicast group "a" may be referred to as "receiving resources."

[0031] When using anycast, resources in a multicast group, e.g., group "b," may transmit data, such as data requested in response to a received request, to multicast group "a" by sending the data in the form of a single data transmission to a single anycast address corresponding to multicast group "a." The data is routed to the resource in multicast group "a" that is determined to be topologically closest to the resource that sent the data. The receiving resource may then forward the data to other resources in multicast group "a." In this way, only one data transmission instance is required for the data to arrive at multicast group "a," and the possibility that only member resources of multicast group "a" receive the data and only a subset of the multicast group needs the data is addressed.

[0032] As known in the art, the Internet Protocol (IP) is a communications protocol that provides an identification and location system for computers on a network and routes data packets across the Internet. Resources (i.e., devices / systems) on the Internet are assigned unique IP addresses for identification and location definition. IPv6 was designed to provide a solution to the IP address shortage that resulted from IPv4.

[0033] IPv6 address: An example of an IPv4 address in dotted-decimal notation is shown in Figure 6a. It consists of four 8-bit sections, each separated by a dot and called an octet. For comparison, an example of an IPv6 address is shown in hexadecimal notation in Figure 6b, where each hexadecimal character represents a string of 4 bits. The address consists of eight 16-bit sections, each separated by a colon. Each 16-bit section is called a hextet. This address can be abbreviated using various rules, including i) replacing multiple consecutive all-zero hextets with a double colon (only once), and ii) removing leading zeros from hextets, which 2001:db8::a111:b222:0:abcd Form. Given the differences in address formats, IPv6 allows for a larger amount of addresses than IPv4. This in turn allows for the reservation of address subspace for different address types. Address prefixes are reserved to represent various address types as illustrated in Figure 6c, where the global prefix is ​​the block of IP addresses provided to end users by Internet Service Providers (ISPs). At a minimum, it is 88 bits long, with subnet IDs containing 16 bits and host / interface IDs containing 64 bits. These address types typically represent different ways of casting information within a network, including those shown in Table 1 below.

[0034] [Table 1]

[0035] Multicast: Multicast is a one-to-many network transmission solution in which a transmitting resource transmits a single data packet to multiple destinations. The resource only sends one copy of the data through the network. Resources subscribed to the data feed transmitted by the sender then receive copies of the data after it has been replicated at the appropriate junctions in the network. Multicast transmission is particularly efficient in terms of bandwidth consumption because the transmitting resource only sends one copy of the data even if all group subscribers receive a copy. This contrasts with unicast, in which the transmitting resource establishes a connection with each intended receiver and sends a separate copy of the data to each.

[0036] As shown in Figure 6c, IPv6 address subspaces can be designated for use with different types of addresses (unicast, multicast, etc.). The address shown in Figure 6c (2001:0db8::a111:b222:0:abcd) is an example of such an address. In a unicast transmission, a data packet is sent from one global unicast address to another. There are different types of IPv6 unicast addresses: Global unicast addresses are routable unicast addresses (their usage is similar to public IPv4 addresses) - see, for example, https: / / www.ciscopress.com / articles / article.asp?p=2803866&seqNum=4.

[0037] Referring to Figure 7, the unicast transmission of the data packet from the server's address to the global unicast address of PC1 results in the data packet being routed through the Internet and arriving at PC1 with address 2001:db8::a111:b222:0:abcd. PC1 becomes the only resource available to process the data packet.

[0038] For multicast, instead of sending data packets to the address of PC1, the data packets are sent to a multicast address, which is an IPv6 address with the prefix FF. Resources that want to receive data from the sender join the multicast group associated with that multicast address; this is called a "subscription."

[0039] When a data packet is sent from the server, it is routed through the Internet to a multicast address (e.g., "RLocal" in Figure 8 indicates a multicast transmission from the server to subscribers PC1 and PC2). When the packet arrives, subscribers, e.g., PC1 and PC2, can read the data, while non-subscribers PC3 and PC4 ignore the data packet. Multicast thereby reduces the need to send two separate data packets from the server to PC1 and PC2. A separate copy of the data packet is made only upon arrival at RLocal.

[0040] For the multicast packet to arrive at PC1, resource PC1 must report to RLocal that it wants to join the multicast group FF00: / 8. When RLocal sees this report, it opens an interface to PC1 in the expectation that it will forward any multicast messages to PC1 if it sees any multicast packets on the network. A router in the network (say, R2) will have been selected as the rendezvous point (RP) for multicasts to FF00: / 8. Knowing that the best path to R2 is through R1, RLocal sends a join report to R1 asking R1 to forward the request for the FF00: / 8 multicast transaction to the rendezvous point R2. R1 sends the join report to R2. When the rendezvous point receives the multicast packet, it forwards this packet to R1, which then passes the packet to RLocal, which then passes the packet to PC1.

[0041] Multicast Listener Discovery (MLD) and MLD Snooping As is known in the art, MLD is built into the IPv6 protocol. See, for example, https: / / en.wikipedia.org / wiki / Multicast_Listener_Discovery. MLD snooping provides many efficiencies over the use of MLD, as it avoids flooding the entire network with packets and thus avoids transmitting data to network resources that have not signaled an interest in receiving that data. In addition, it improves network security by avoiding Denial of Service (DOS) attacks from unknown network sources.

[0042] By default, MLD snooping is disabled. As a result, when a switch receives a packet addressed to a multicast group, it sends the packet to all interface ports in the VLAN except the port on which the packet was received. In other words, the switch floods the packet throughout the entire VLAN. If a resource is not a member of the multicast group and is not interested in the data on that channel, it ignores the packet. Obviously, this results in unnecessary network traffic and inefficient use of energy and processing resources.

[0043] However, when MLD snooping is enabled, the switch forwards multicast-addressed packets only to interface ports that have indicated an interest in receiving packets destined for that address. In other words, it sends packets only to ports that belong to members that are subscribed to that multicast group. Thus, MLD snooping allows a transmitting resource to selectively transmit data packets to resources that have indicated an interest in receiving them. If no network resources are subscribed to the multicast group, the transmitting resource will not transmit any packets. Further details can be found at https: / / techhub.hpe.com / eginfolib / networking / docs / switches / WB / 15-18 / 5998-8170_wb_2920_ipv6_config_guide / content / v33585413.html.

[0044] Anycast IPv6 anycast includes the situation where multiple routers share a common IPv6 anycast address. As shown in Table 1 above, any anycast address shares the same prefix as a global unicast address. For example, 2001:db8::a111:b222:0:abcd can also be used as an anycast address.

[0045] When a data packet is sent by a transmitting resource to an anycast address, it is forwarded to the router / node closest to the resource's subscribed set. Geographic distance is one factor in determining the closest resource, but there are other influencing factors in the calculation, such as number of hops, efficiency, latency, and cost. Ultimately, in anycast, only one resource is expected to receive the data packet, which is often described as one-to-nearest-neighbor transmission.

[0046] Referring to Figure 9, which shows an anycast transmission from the server to router R3, we see that the packet is sent to 2001:db8: / 32, an anycast address shared by at least three routers (R1, R3, and RLocal). The closest of these is R3, so the data packet is sent to R3. Recall that "closest" does not necessarily mean geographic proximity.

[0047] Anycast is particularly suitable when transmission speed is of particular concern. A network node (device) may choose to participate in an anycast address by assigning it to itself (i.e., its network interface). An anycast address is essentially a shared unicast address. The device can then send a transmission to the anycast address, and the transmission will reach the topologically closest node (device) to the anycast address. This closest device may respond by taking any appropriate action based on the received transmission, such as forwarding the transmission to another destination, performing a calculation, processing the received data in some way, or sending an alert to one or more recipients. While FIG. 10 illustrates the propagation of data across a network, FIG. 11 illustrates an exemplary embodiment of the present disclosure in which nodes in a network perform multicast transmissions of one or more portions of data.

[0048] Figure 12 shows an example of an anycast transmission from node 5 to anycast address 2001:db8: / 32. Nodes 1, 2, and 3 are obtaining copies of specific data, such as a message, a cryptographic key, the output of a computation, positioning data for a military target, executable code for a software installation or upgrade, or a block or transaction ID on a specific blockchain ledger. After receiving the transmission containing the data, they each assign themselves to anycast address 2001:db8: / 32. The shared understanding is that this anycast address signifies that the receiver owns a copy of a portion of the data. Node 5 sends a request for a copy of the data to the anycast address, and the topologically closest node (among nodes 1, 2, and 3) is the one that receives the request.

[0049] In the case of Figure 12, the closest is node 1, which then, if it chooses, sends a copy of the data via unicast to node 5. If the closest node is selected, this means that node 1 is more likely to receive a complete copy of the data more quickly.

[0050] However, note that the "closest" node depends on several factors other than geographic proximity. Latency and cost were listed as factors in the determination. If the channel to node 1 becomes overwhelmed with data transmissions and data requests, the "closest" calculation may in some cases select another node as the new closest node. This distributes requests and data transmissions among nodes that own the new data. In some cases, requests for data may be performed through anycast requests. Once the closest node is determined, a unicast transmission may be sent from the requesting node (node ​​5) asking for the unprocessed data from the closest node (node ​​1). The data is sent to the requesting node (node ​​5).

[0051] Mobile IP and IPv6 Protocol In some exemplary embodiments, the use of Mobile IP and IPv6 protocols allows for greater flexibility in how services are accessed. Mobile IP and IPv6 are both networking protocols, but they serve different purposes and are used for different networking aspects. Mobile IP is a standard protocol that allows a user to move from one network to another while maintaining their original IP address. This is particularly useful for mobile devices, such as smartphones or laptops, that need to switch between different networks (e.g., moving from a home Wi-Fi network to a cellular network) without interrupting ongoing activities or sessions. In a Mobile IP setup, a device typically has two IP addresses. Home Address: The IP address assigned to you in your home network remains static. Care-of Address: A temporary IP address assigned by the external network the device is accessing.

[0052] A third component, the "home agent," keeps track of the mapping between the two addresses and forwards packets accordingly.

[0053] In the context of the present disclosure, embodiments combine the advantages of Mobile IP with those of IPv6 to create a more flexible, secure, and scalable network architecture. Mobile IP allows users to move seamlessly between networks, while IPv6 ensures a vast, virtually unlimited number of unique addresses and improved security features. Because each device controller has its own set of associated devices, a block of IPv6 addresses can be used across multiple devices and services. Thus, the network can effectively "follow" a user / device from one location to another, e.g., from a mobile phone to a home network, and to various services such as telephone or Internet-related services, while maintaining a high level of security and privacy.

[0054] Referring now to Figures 13 et seq., and particularly to Figures 20 and 21, solutions are provided that utilize these transmission techniques for fast, secure, and scalable distribution of data across a network and improved control of multiple devices that need to receive data over the network. Multiple devices 3003a, 3003b, and 3003c are controlled, at least in part, by a device controller. While three devices are shown in Figure 21 for illustrative purposes, more or fewer devices may be associated with the device controller. Advantageously, embodiments of the present disclosure allow devices to be added or removed from association with the device controller. This may, in some examples, be accomplished via software (apps) provided by the device controller and installed on the device (3003a, 3003b, or 3003c), thereby allowing the device controller to grant / remove authorization for receiving service provider services with provisioning or deletion of encryption keys.

[0055] By way of non-limiting example, a device controller could be a household with multiple laptops, cell phones, etc. for family members, or a taxi company with a fleet of electronic vehicles, a company that issues laptops / cell phones to traveling employees, or a military command center that needs to track and communicate with multiple user-worn devices, vehicles, drones, etc. out in the field. In many situations, access to services by individual devices needs to remain confidential. Advantageously, embodiments of the present disclosure provide pseudonymous access to data provisioning.

[0056] Accordingly, embodiments of the present disclosure may be arranged and configured to provide a solution enabling secure, pseudonymous, and faster delivery of data provisioning services to end users associated with a shared or common controlling entity. In a preferred embodiment, the services are provided, at least in part, via electronic transmission of data over any suitable known type of computer-implemented network or data communication channel, including services provided from or via cloud-based computing resources. In some (non-limiting) examples, the services may include telecommunications services such as telephone and / or Internet services, or media and other digital content delivery via streaming capabilities, video conferencing services, and the like. Where the services include telecommunications, this may also include telecommunications services such as the ability to make telephone calls, send and receive text messages, or use mobile data. The embodiments are not limited with respect to the type or purpose of the services provided or the purpose / nature of the data provided.

[0057] Essentially, the service provider 3002 provides data to one or more IP addresses if the request for provision of that data is verified by the provider as authorized by the device controller. The service provider may be external to the device controller and / or unconnected. For example, the service provider may be a third party that the device controller simply uses by contractual agreement for the provision of one or more specified services. In other examples, the service provider may be internal to the device controller or have an organizational relationship with the device controller. For example, the device controller and the service provider may be separate divisions within the same organization. There may be one or more device controllers within the same organization.

[0058] Referring to FIG. 21 , in a preferred embodiment, an encryption key and IP block are assigned or associated with a device controller 3001 by a service provider 3002. The IP block includes a range of IP addresses as known in the art. These addresses are preferably IPv6 addresses of any known type, as described above. The encryption key may be part of a public-private key pair as known in the art. The service provider stores at least the device controller's associated public key in a storage facility 3005, along with the range of addresses assigned to the device controller 3001. The device controller 3001 can then assign one or more of the addresses in the assigned address block to individual devices 3003a, 3003b, 3003c that are permanently or temporarily associated with the device controller.

[0059] In some examples, the key pair may be generated by the service provider 3002 and distributed to the device controller. In other embodiments, the cryptographic key pair may be generated by the device controller 3001 (or another entity acting on behalf of the device controller). The public key may then be provided to the service provider without revealing details of the user's identity or other user-related data that needs to remain secret, such as location, date of birth, or gender. The private key may be held by the device controller and kept secret. In any case, regardless of where the key pair is generated, the device controller 3001 may store the cryptographic key pair in a storage facility 3006 to which it has access.

[0060] The cryptographic key pair enables the device controller 3001 and its associated devices 3003a, 3003b, 3003c to access services provided remotely by the provider 3002. The device controller's key serves as a control and validation mechanism facilitating authorized access to provisioned services. Additionally or alternatively, the device controller's key may be used as an encryption / decryption mechanism for data, such as communications, shared between the device controller 3001, the devices 3003a, 3003b, 3003c, and / or the service provider. Thus, the identities of the device controller 3001 and its devices 3003a, 3003b, 3003c may be kept private and secure. Only the public key associated with the device controller may be disclosed to the service provider, thereby ensuring secure yet pseudonymous access to associated services.

[0061] In some embodiments, key distribution may involve transmitting a key pair from the service provider to the device controller, or transmitting a public key and / or access request from the device controller or one or more of the controller's devices to the service provider, over an electronic network such as a LAN or WAN, or over a public network such as the Internet, or over a wireless network, or over a text message, or over any other suitable communication means. In some cases, the transition of data (requests, keys, etc.) may be performed between the service provider, the device controller, and / or individual devices via a blockchain network and / or a (blockchain) ledger associated with the blockchain network.

[0062] In some cases, the key may be obtained by the device controller or service provider via a blockchain transaction. This may be done using a digital wallet. The public key may be provided by the device controller in the transaction (e.g., in the transaction output / script), and the output containing the key may be available to an address controlled by the service provider. The transaction may be signed by the device controller using the private key. The service provider can use the public key to check the signature of the transaction, thereby verifying that the device controller has the corresponding private key.

[0063] The advantage of providing the key via a blockchain transaction is that there is an auditable, immutable, timestamped record of the key associated with the device controller and when the device controller accessed it (by spending the output).

[0064] The key associated with a device controller may hereafter be referred to as its master key.

[0065] In a preferred embodiment, each device controller is associated with an IP block (otherwise known as an IP range). This is preferably an IPv6 block that includes a range of contiguous IPv6 addresses. IP addresses within the device controller's designated IP block can then be linked to the user's various processing resources 3003a, 3003b, and 3003c, such as mobile phones, laptops, IoT devices, vehicles, and other devices that want or need access to data provided by the service provider. Thus, the device controller 3001 can be assigned at least one set of IP addresses. The service provider keeps a record of the IP addresses assigned to the device controller 3001 in its storage facility 3005. The service provider 3002 also keeps a copy of the device controller's (public) encryption key. Thus, the service provider knows which master key and which IP address range are associated with a given device controller. If multiple address blocks are assigned to a given device controller, a different master key can be associated with each address block. However, in other embodiments, the same master key may be associated with multiple IP blocks of a device controller.

[0066] Advantageously, each of the associated devices of a device controller may act as a mobile node. Thus, each of the devices of a device controller may be associated with a home address that is a member address of a user's assigned IP block. Each of the devices 3003a, 3003b, and 3003c of the device controller may be arranged to be non-permanently associated with at least one care-of address associated with a network to which the device temporarily connects. Thus, embodiments of the present disclosure may involve the use of, or combination or integration with, Mobile IP, Mobile IPv6, or Hierarchical IPv6 (HMIPv6).

[0067] In some embodiments, the associated devices 3003a, 3003b, and 3003c of a device controller may be organized into a hierarchy or related to one another through some logical and / or technical relationship. In such cases, it may be advantageous to generate cryptographic subkeys derived from a master key. Subkey generation may be performed by the device controller's cryptographic wallet 3004 to reflect the hierarchical or other relationship between the device controller's various devices. The subkeys may be shared by the device controller with devices 3003a, 3003b, or 3003c. In some embodiments, the keying techniques disclosed in International Publication No. WO 2017 / 145016 (International Application No. PCT / IB2017 / 050856) may be used for subkey generation. This technique is summarized below in the section entitled "International Patent Application No. PCT / IB2017 / 050856 (Published as International Publication No. WO / 2017 / 145016)" and described in more detail as published in the PCT application.

[0068] Advantages of using the technology of International Application No. PCT / IB2017 / 050856 include: Deterministic generation of subkeys. This allows a verifying party, e.g., a service provider, to prove that the subkey provided in the access request was derived from a master key known to belong to the device controller. To verify the subkey, the verifier may use a message that is pre-agreed between the provider 3002 and the device controller 3001, or that is provided in some manner by the controller 3001 or the requesting device 3003a, 3003b, or 3003c. In some embodiments, the message may be provided within the request, sent separately from the request, or calculated by the service provider using predetermined operations and / or numbers of operations. The ability to generate a common, or shared, secret between two parties independently of each other. This means that the shared secret does not need to be transmitted or communicated between the two parties, thus avoiding the potential for interception by unauthorized parties. The shared secret can be used to generate a key pair independently at each party, e.g., the device and the service provider. The key pair can then be used to encode, decode, and verify the authenticity of subsequent communications between the parties, including transmissions of data sent from the provider to the device as part of a requested and authorized service. The ability to generate a hierarchy of subkeys. This means that the device controller's master key can provide the root of a hierarchy of authorization mechanisms that reflects the structure of an organization. This also means that access to services can be enabled / disabled for entire sections or sub-parts of an organization by the device controller or parties authorized by it.

[0069] According to a preferred embodiment, the device controller is assigned a key and an IP block. Each of the user's devices is then assigned an individual access address from the user's IP block. Because the device controllers have been assigned cryptographic access keys by the service provider or have generated key pairs themselves, the device controller (or another party on behalf of the device controller) can generate subkeys from the master access key for each of the devices. Thus, each device of the device controller is assigned its own subkey derived from the master key and is further assigned at least one address from the device controller's assigned IP block. (We use the terms "assigned," "associated," and "allocated" interchangeably herein.) The combination of an individual device's subkey and associated address allows the individual device to access the service in a pseudonymous manner, since only the subkey is revealed to the service provider. The service provider can prove that a given device's subkey is generated from the device controller's master access key and can therefore be confident that the device is authorized via the registered device controller. This provides the advantage that individual devices can always be traced back to an authorized controller and the verification and authorization process for individual devices is simplified and improved. Each time a device controller acquires or receives a new device, it simply associates it with an IP address from the block and generates a subkey for it from the master key.

[0070] In some cases, the assigned address obtained by the service provider in connection with the access request may include a "care of" address or home address of the access-requesting device (3003a, 3003b, or 3003c) as is known for IPv6 mobiles.

[0071] Each time a request for access to a given service is made to a service provider, the service provider can look up the address of the requesting device in a storage facility, such as a database, DHT, or storage disk. After determining the device's address, the service provider can then determine which block the address is in and which device controller is registered with or associated with that given address block. The device controller's master access key, associated with the address block, can then be used to determine whether the device's encryption key is generated from the registered master encryption key. If so, the service provider considers the device's access request authorized by the device controller.

[0072] In particularly useful embodiments, after successful validation of an access request, data is communicated from one or more transmitting resources to one or more receiving resources over a network, e.g., the Internet. For convenience, we will refer to one or more transmitting resources as “service providers” and the receiving resources as “devices” or “end devices.” In some scenarios, the receiving resources are organized into logical groups, each of which may include one or more resources. The resources may include any type of computing resource and may be configured for use for any suitable purpose. Each transmitting resource and / or receiving resource may include one or more hardware and / or software components and may be configured to communicate with other resources over an electronic network. In some cases, the transmitting resource, receiving resource, and / or device controller may include a digital (e.g., crypto) wallet for generating or storing cryptographic keys.

[0073] 18 and 19 show how exemplary embodiments may be used for controlled access to data provided by a service provider 3002. Advantageously, the address assigned to a device (3003a, 3003b, or 3003c) may be a multicast address, meaning that the service provider only needs to send data or provide a service once to one assigned address specified by an authorized requesting device, and that data may then be distributed throughout a potentially large number of end recipients.

[0074] Access to the multicast group may be controlled by any security mechanism, such as the use of passwords, encryption keys, etc., to prevent unauthorized access to the service. In one or more embodiments, access to the multicast group (and thus the data sent to subscribers of the group) may be controlled through the execution of a smart contract running in conjunction with a blockchain. This may be a blockchain implemented via the Ethereum blockchain, the Bitcoin blockchain, or any other blockchain protocol. For example, a user wishing to join a multicast group associated with an assigned address may be required to satisfy one or more conditions specified in the smart contract and, after successfully satisfying the conditions, may be provided with the information necessary to be able to subscribe to the group and begin receiving packets of data from the multicast stream. For example, a user may be provided with a key or token or other resource that enables them to join the group. These conditions may include any suitable conditions, such as the payment of a joining fee or the provision of identity-related data to verify the user's identity. The same or additional smart contracts may control the user's continued access to the multicast group and the data packets disseminated to / over the multicast group. For example, a smart contract may require a user to periodically pay a fee, update identification documents, or perform some other action.

[0075] In our example, the requesting device (3003a, 3003b, or 3003c in FIG. 21) receiving the provisioned data may be referred to as Alice "A," Charlie "C," or Dave "D," and the transmitting resource (service provider 3002 or intermediary) may be referred to as Bob "B" or Charlie "C." The exchange of data may be accomplished using transmissions to one or more multicast groups "MG," each group having its own respective multicast address.

[0076] In Figure 17, a transmitting resource represented by Bob B or Charlie C functions to perform at least one of generating, storing, processing, accessing, and / or maintaining packets of data. The packets of data may include blockchain-related data. Bob or Charlie sends, at least in part, transmissions of the data over the electronic network to multicast groups MG1 and MG2. Bob represents a node controlled by service provider 3002 from which the packets of data originate.

[0077] The multicast group makes data available for an end user. In some cases, this may be Alice A (shown in FIG. 21 as device 3003a, 3003b, or 3003c). In other cases, Alice may not be a subscriber to the multicast group associated with the multicast address assigned to her by the device controller. In such cases, Alice simply acts as a request and access control mechanism that interacts with the service provider (3002 / Bob) on behalf of the device controller. In such cases, Alice is an intermediary between the service provider and end users who subscribe to the multicast group but are not themselves end users of the service. In this way, Alice may act as an intermediary for Charlie C.

[0078] However, Charlie may also access and / or subscribe to multicast group MG1 and make said packets of data available to end user Alice directly or via a further multicast group MG2.

[0079] Hash lines are used in FIG. 21 to indicate the optional transmission of packets of data between Bob and Alice, i.e., via Charlie. Alice can obtain packets of data from MG1, but for example, the data could be multimedia data, e.g., a live transmission of a football game. Alice may not be able to watch it live, so an intermediary, e.g., Charlie C, also subscribes to receive the data from MG1 and stores it, making it available to Alice independently of Bob's transmission. Charlie can transmit the data to Alice directly or via a further multicast group, MG2, at a different time than the original transmission.

[0080] Data is transmitted directly to multicast group MG1 and indirectly to multicast group MG2, and authorized consumers / end users of the data can obtain the data by subscribing to the multicast group.

[0081] 20 and 21, an example of a possible data flow according to one embodiment of the present disclosure is presented.

[0082] In step 2001, a device controller 3001 registers with a service provider 3002 because the device controller wishes to facilitate the provisioning of the service provider's services to various devices 3003a, 3003b, 3003c associated with and / or known to the device controller. In some cases (but not all), registration may include the generation of a key pair by the device controller for association with the device controller. In some cases, registration may include capturing data related to the device controller, such as an IP address.

[0083] In step 2002, the service provider assigns a set of IP addresses for association with the device controller. Preferably, these are IPv6 addresses. The service provider may keep a record of the assignment in a storage facility, such as storage 3005. The service provider notifies the device controller of the assignment. This may be accomplished by transmitting information related to the set of addresses from the service provider to the device controller over a network. Upon receiving the information from the service provider, the device controller may save a copy of the information in a storage facility, such as storage 3006. In other possible embodiments, the device controller or an individual device 3003a, 3003b, or 3003c notifies the service provider of the addresses already assigned to it. In any case, the device controller will now be aware of the range of IP addresses that the service provider has assigned to the device controller.

[0084] In step 2003, the device controller may possess or have access to an existing cryptographic key pair (in storage such as 3006 or in crypto wallet 3004), or may generate a new key pair. The key pair includes a private key 3008 and a public key 3007. In a scenario such as that illustrated in Figure 21, where there is no relationship and / or trust between the parties, the device controller sends public key 3007 to the service provider but keeps private key 3008 secret. The service provider needs public key 3007 to be able to verify the device's access request later in the process.

[0085] After receiving the public key from the device controller, the service provider stores the public key for future reference in the device controller's account / in a storage facility such as 3005. Note that when it is said that data is stored in a storage facility such as 3005 or 3006, this is not limiting and different portions of the data may be stored in separate storage facilities.

[0086] In some cases, the device controller may request an encryption key pair from a service provider (see step 2005). The service provider then generates or otherwise obtains the key pair, associates it in storage with the device controller or the device controller's account, and transmits the key pair to the device controller. Upon or after receiving it from the service provider, the device controller stores the key pair in a storage facility, e.g., 3006.

[0087] In other cases, step 2005 may be omitted and the service provider may automatically, i.e., unprompted, send the key pair to the device controller, which may be performed as part of the registration process described above in step 2001 or upon / after completion of the registration process.

[0088] In still other cases, where the service provider and device controller have a trusted relationship, for example, belonging to the same organization, they may each independently generate a key pair using techniques disclosed in International Publication No. WO2017 / 145016 (International Application No. PCT / IB2017 / 050856) and inputs that are predetermined, agreed upon, calculated, or otherwise both known. In such cases, the key pair may actually be derived from another key, and / or the service provider and device controller may store copies of both the public and private keys of the pair.

[0089] Once steps 2008 / 2003 are complete, the device controller has a stored key pair and a set of assigned IP addresses. The service provider has at least the public key 3007 that corresponds to the private key 3008 of the device controller's key pair, and has a stored record of which IP addresses it has assigned (i.e., associated) to the device controller.

[0090] In step 2009, for each device that the device controller can control, the device controller does the following: 1) Generate a key pair for each device 3003a, 3003b, or 3003c and send the key pair to that device. In other cases, the device may generate the key pair itself or obtain it from another source rather than obtaining it from the device controller. In such cases, the device may inform the device controller of its private key. In a preferred embodiment, the key pair associated with a given device is deterministically and provably generated as a subkey of another key that is ultimately derived from a master key known to the device controller. 2) and assigning to the device 3003a, 3003b or 3003c at least one IP address from the set of IP addresses assigned to it by the service provider.

[0091] In step 2010, when device 3003a, 3003b, or 3003c wishes to access a service from a service provider, the device generates an access request and makes it available to the service provider. This may be accomplished via any suitable mechanism, such as those described above. Preferably, the request is signed with the device's private key. In some cases, it may also include the device's public key. It may also include an IP address assigned by the device controller. The address included in the request becomes the recipient of the service. In other words, upon successful verification, the service provider sends the data to the address provided in the access request. In some cases, instead of providing the public key, the access request may include an identifier that identifies the device controller or account, allowing the service provider to retrieve the public key from storage or otherwise obtain it.

[0092] In step 2011, the service provider performs one or more of the following actions: 1) Get the device's access request. 2) Determine the address block to which the specified address belongs. 3) Determine which device controller the block is assigned to. 4) Retrieve the public key associated with the device controller from the service provider's storage facility 3005. 5) If the device provides a subkey, the service provider checks whether the device's subkey is derived from the device controller's key.

[0093] The service provider can use the device's public key to check the signature applied to the request or a portion thereof. If the service provider cannot verify that the signature was applied by an authorized private key (e.g., which is a valid subkey derived from the device controller's key), the service provider refuses to provide the requested service to the device (step 2012). Alternatively, if the verification is successful in step 2013, the service provider sends the requested data to the address specified in the request. Service provisioning is indicated in Figure 22 via dotted lines.

[0094] Example in use: Streaming data In view of the teachings and figures herein, it will be apparent that a transmitting resource, e.g., a network node or router of a service provider, may transmit multiple packets of data, and / or a receiving resource, e.g., an end device, may receive multiple packets of data. As a non-limiting example, the packets of data may be a data stream, such as multimedia data, and a multimedia communication channel, at least in part, provided by a service provider.

[0095] The multimedia data may be, for example, a football game, or a subportion thereof. The football game may be transmitted over a single channel including a combination of video and audio, but the football game footage may be provided in multiple portions, with one or more portions transmitted on different channels. For example, multiple video streams may be provided, with each stream supported by a different channel. For example, the portions may include different camera angles, goal-line camera views, commentary in different languages, replays, etc. Each of the channels may be transmitted with different packets of data to a respective multicast group.

[0096] Using Figure 18 as an example, suppose Node B is the service provider described above. Node B is a transmission resource that offers a streaming service that brings live sporting events to consumers. Also, suppose a particular hotelier owns hotels in London and Berlin and wants devices in the hotel bedrooms and bars to be able to access data made available by the service provider. The hotel owner is the device controller, and Node B is the service provider. The device controller has been assigned a range of IPv6 multicast addresses by the service provider, and the service provider has a stored (master) key associated with the device controller. The device controller then generates a subkey for the London hotel and another subkey for the Berlin hotel.

[0097] A service provider (Node B in FIG. 18) can transmit packets of data in six different streams to respective multicast groups MGa to MGf, the packets containing multimedia data of a live football match. Groups MGa and MGb receive packets of data containing visual camera angle data, the former following the game play and the latter showing exclusive goal-line action. Groups MGc and MGd receive packets of data containing play-by-play commentary in different languages, the former English and the latter German. Groups MGe and MGf receive packets of data for optional extras, the former providing exclusive replay action and the latter providing footage from referee-worn body cameras.

[0098] During the game, Alice (on a TV or other media-enabled device in her bedroom at the London hotel) wants to access a service from a service provider and sends an access request to the service provider as described above. Alice may do this by providing her signature and public subkey to the service provider and writing a transaction to the blockchain in which she also provides at least one IP address provided by the device controller. The service provider can use the IP address to look up the device controller associated with that address. The service provider may perform checks such as "Is the device controller's account a paid account?" or "Is this account still active?" The service provider then a) checks that the subkey is derived from a stored key that the service provider knows is assigned to or associated with the device controller, and b) verifies the signature provided by Alice using the public subkey provided in the request.

[0099] Upon successful verification of Alice's subkey, the service provider makes the data available to Alice. Alice streams the match play and English commentary by accessing multicast groups MGa and MGc. Concurrently, and optionally, Charlie at node C (a TV or other device in a bedroom at the Berlin hotel) performs the same request sequence as Alice, as described above. Upon successful verification, Charlie accesses and captures data packets from all multicast groups MGa through MGf. The captured data is collected and / or aggregated by Charlie at node C and made available separately and independently via multicast group MGm, which makes available all data packets transmitted by node B to multicast groups MGa through MGf, thus providing full match information, language, and camera views on demand. Devices authorized by the device controller to do so (i.e., they have been assigned at least one IP address and at least one subkey) can access group MGm to rewatch the match play or access additional information contained in the packets of data.

[0100] An intermediary, such as Charlie, may operate to merge, e.g., pool, packets of data from one or more multicast groups for subsequent transmission to another multicast group that is authorized to subscribe to the multicast address assigned to the device controller.

[0101] Charlie, for example, could be a device in a Berlin hotel to which registered guests can connect via an app on their mobile phones or laptops. When guests check in, they download the hotel's app to their mobile devices, which generates at least one subkey for the device and provides an associated IP address from the device controller's allocated block. The mobile device's subkey pair is derived from Charlie's subkey pair, thus creating a hierarchy of subkeys. When the guest checks out of the hotel, the checkout system may notify Charlie, who then sends an instruction to delete the subkey to the app on the guest's mobile device. Thus, the guest can only access the service provider's data while staying at the hotel. Other trigger conditions, such as a predetermined time limit or period (e.g., the date the guest paid to stay at the hotel) or the device's perhaps geographic location, e.g., being within the hotel, may be used to delete the mobile device's subkey.

[0102] A service provider, i.e., Node B, can transmit multiple packets of data. Additionally or alternatively, the packets of data can have subcomponents for providing multiple data channels. The packets of data can be separable for independent transmission to multicast groups (i) according to channel capabilities, as described in the examples above with respect to different aspects of a football game, and / or (ii) based on the packets of data themselves.

[0103] Clearly, the teachings herein are not limited to football games; in other examples, the transmission of packets of data may apply to a delivery driver, where the service provider is a control room that transmits packets of data related to delivery addresses, driving routes, traffic information, weather information, and the like, for selective reception by the delivery vehicle. In other examples, embodiments may be used to enhance the operation and / or coordination of drones that are controlled by a device controller and need to receive GPS or other location-related data, software updates, instructions, or other data from a service provider. Still other examples include situations where the device controller is a warehouse manager or production line operator that needs to control and guide multiple devices in a warehouse or factory, and the service provider is a corporate division that sends instructions or operational data to the warehouse / factory for use by the devices, or a subscription media service such as Netflix™ or Sky™ television.

[0104] Packets of data and / or multicast groups may be secured, e.g., encrypted, or otherwise locked by an access key that must be applied when subscribing to a multicast group and / or to packets of data to control access to the content therein. Separate access keys may be required to access different multicast groups and / or packets of data. For example, a first access key may be required to access packets of data, while a second access key may be required to access the multicast group, e.g., via a subscription. These may be subkeys derived from the data controller's master key as described above.

[0105] In some embodiments, a transmission resource can protect access to a multicast group and / or determine whether an access key is required to access packets of data by protecting the data. A transmission resource can manage access to a multicast group, e.g., manage subscriptions that require an access key. In an example, Bob B and Charlie C are transmission resources, each capable of protecting packets of data to transmit and / or managing access to the multicast group to which they are transmitted.

[0106] The device controller that manages the multicast group with the assigned multicast address can generate access keys needed by an intermediary that acts as an aggregator and pools packets of data for subsequent access by end users such as Alice, e.g., Charlie C, and / or an end user, e.g., subscriber Alice A. The access keys are provided to Charlie and Alice, in one example.

[0107] The access key may be obtained by an intermediary or an end user, e.g., an aggregator or an end user, in a traditional exchange, i.e., providing the access key in exchange for payment. In embodiments that implement access requests using blockchain transactions, at least one access key may be provided to the intermediary or end user (i.e., device) via a payment channel, which is known from https: / / wiki.bitcoinsv.io / index.php / Payment_Channels.

[0108] Using a payment channel, at least one access key can be quickly and efficiently exchanged for payment using a blockchain transaction. In practice, an intermediary or end user can use and / or establish a payment channel to obtain a bundle of access keys. The payment channel and key provisioning can be handled by a service provider or a device controller.

[0109] Efficient access to secure packets of data using access keys can benefit from the use of payment channels, where each key can be used to subscribe to and / or unlock packets of data, for example, to trigger automatic payments to transmission resources, the transmission resources being the source of the packets of data. The access key can provide access to the multicast group and / or packets of data for at least one of: (i) a fixed period of time, and (ii) a fixed amount of data, (iii) a fixed number of units, (iv) a fixed number of packets of data, and (v) unlimited access.

[0110] A transmission resource, such as Bob or Charlie, can transmit packets of data to a large number of multicast groups. The scope of the IPv6 protocol and blockchain applications is such that the amount of packets of data transmitted can be significant, and the packets are transmitted to an equally significant number of multicast groups. This allows for a scalable and granular means of distributing packets of data, while reducing bottlenecks and balancing resource usage.

[0111] In addition to the transmission and / or subscription and / or access techniques taught herein, transmission resources can be assigned to packets of data to a multicast address, the multicast address being determined from at least one of the packets of data and an access key.

[0112] The allocation techniques taught with respect to features and embodiments of enumerated item set 9 and elsewhere herein can be applied to complement efficient and scalable solutions for transmitting data using IPv6, as taught herein. Balancing can mitigate bottlenecks in the transmission of packets of data, particularly when the packets of data are large blocks that may result in delays in nodes or routers, or when the packets of data are transactions whose propagation in a general manner would result in a volume of transactions that would flood the network.

[0113] 19 shows a further example of how a transmission resource 3002, represented at Node B, e.g., Bob, transmits packets of data to eight different multicast groups—nominally MGa to MGH. A packet of data may be transmitted to each multicast group based on the packet of data being transmitted.

[0114] Alternatively, the allocation may be determined using an access key and / or the content of the packets of data. For example, a multicast group—nominally MGa to MGH—may hold data associated with geographic locations received from transmissions from Node B, Bob, which is a transmission resource. Each geographic location may have its own access key, which may be obtained via a subscription.

[0115] In one example, a transmission resource (3002 in FIG. 22 or B in FIG. 19) transmits packets of data, e.g., map and traffic information, associated with a city having eight districts. Six autonomous vehicles, e.g., taxis, operating in a drone-like manner, labeled D1 through D6, are needed to transport goods or residents within the city. Each drone, D1 through D6, operating as a taxi, determines the start and end points for a given driving route, as well as the districts it needs to traverse. The drone then accesses corresponding packets of data related to those districts from the multicast groups associated with those districts, e.g., by subscribing.

[0116] Each district and / or drone may be licensed. Thus, for a drone to operate in one or more districts, it needs a license for each district, with the license providing an access key corresponding to packets of data associated with the licensed district. Alternatively, or in addition, each drone may obtain the license and corresponding access key from the device controller 3001, or an entity authorized by the device controller, or by subscribing to a multicast group from which it obtains the necessary license, map, and traffic data. Subscription may occur when needed and may be turned "on" or "off" depending on requirements. Subscribing to a multicast group to obtain packets of data for a licensed district may be time-based, unit-based, etc.

[0117] In the example of FIG. 19, drones D1, D2, D4, and D5 start and stop in the same district and switch on to receive or otherwise subscribe to multicast groups Mga and MGb, respectively. Drone D3, however, traverses three districts and accesses data associated with districts MGa, MGb, and MGc. In contrast, drone D6 traverses six districts and accesses data associated with districts MGc through Mgh. During normal operation, drone D6 operates only in the district supported by MGc and may need to move to other districts on demand. Thus, drone D6 may have an annual subscription to an access key for multicast group MGc and / or the data it provides, while subscribing to other multicast groups as needed when moving between other districts.

[0118] Accordingly, the present disclosure provides methods and related system requirements for controlled transmission, dissemination, and / or access to packets of data (as part of a provided service). The data may include information such as multimedia content, map data, or similar content. Access may be achieved, for example, through a subscription that can be paid for using a payment channel supported by the blockchain node and the blockchain network. An exemplary application may be a "pay-per-view" or "pay-per-use" service. Embodiments may be particularly useful for applications where enhanced control is needed over data streamed from a source to multiple potential data consumers.

[0119] Accordingly, some examples provided herein relate to the transmission of data using nodes and / or routers that optimize resource spreading and / or balancing through management and / or allocation, as summarized in each section. In particular, examples relate to controlled transmission and / or access to data. More particularly, contractual access to data, e.g., payment, is presented. According to one possible aspect, the present invention may reside in a computer-implemented method that includes operating a transmission resource to generate, store, process, access, and / or maintain packets or portions of data. The transmission resource may be the origin, e.g., creator or producer, of the packets or portions of data, or the service provider or transmission resource may be an operator, such as a distributor, that collates, aggregates, or pools packets of data for subsequent transmission, independent of the original transmission or creation of the data. The transmission resource may transmit, at least in part, transmissions of data from the transmission resource (over an electronic network) to an assigned multicast address that can be accessed by (verified) devices associated with an authorized control entity. Devices may be dynamically added or removed by a device controller without processing or cost impact to the service provider.

[0120] Multiple packets / portions of data may be transmitted and / or received. For example, rather than transmitting a movie in a large packet of data, the movie may be divided into multiple parts and each part may be transmitted as a single packet of data. The packets of data may be, at least in part, a data stream, such as a multimedia communication channel. The packets of data may have subcomponents to provide multiple data channels.

[0121] An end user may typically be a consumer, e.g., a subscriber, who accesses packets of data via a multicast group. The multicast group and / or packets of data are protected, and a recipient, e.g., an end user, may pay to obtain an access key to access the multicast group and / or packets of data. Multiple access keys may be provided. A first access key may be required to access the packets of data. A second access key may be required to access the multicast group.

[0122] The transmitting resource can generate an access key. The transmitting resource can transmit the necessary access key to the recipient of the packet of data and / or to the end user to access the packet of data. The access key can be provided during a transaction using a payment channel. Additionally or alternatively, in some embodiments, a smart contract can be used in conjunction with a blockchain to control a user's initial and / or ongoing access to a multicast group. When executed in conjunction with a blockchain, the smart contract can require a user to fulfill one or more conditions in order to subscribe to and / or remain a member of the group.

[0123] The access key may be configured to provide access to data and / or simultaneously represent a license and / or access to a digital or physical asset protected with a digital lock. The access key may provide access to, for example, a multicast group and / or data for at least one of: (i) a fixed time period, (ii) a fixed amount of data, (iii) a fixed number of units, (iv) a fixed number of packets of data, and (v) unlimited access.

[0124] In another example, a computer-implemented method includes operating a receiving resource to store, process, access, and / or maintain packets of data, the packets of data preferably including blockchain-related data. The method further includes receiving, at least in part, a transmission of the packets of data via a multicast group that received the packets of data from an electronic network, and consuming the data as an end user. Access to the data and / or the multicast group may be secured. The receiving resource may obtain access rights using an access key. The access key may be obtained via a payment channel.

[0125] The packet of data may include at least one of a portion of a transaction (Tx), an output (e.g., a UTXO) identifier, a hash of a script (e.g., a script associated with an output of a transaction), a transaction identifier (TXID), a blockchain block, and / or a block header.

[0126] summary In non-limiting summary, the present disclosure provides a solution for a comprehensive, secure, and flexible framework for service provisioning across various platforms and services. The embodiments disclosed herein facilitate or enable a range of use cases across various industries and applications due, at least in part, to the provision of secure, scalable, and flexible data service provisioning. Potential use cases include, but are not limited to, the following: IoT (Internet of Things) Smart Home: Device controllers in smart homes can securely assign IP addresses to connected devices like thermostats, security cameras, and smart speakers. o Industrial IoT: In a factory environment, this method can securely manage data services to sensors, machines, and control units. Cloud Computing o Resource Allocation: Embodiments may facilitate secure dynamic allocation of cloud computing resources among multiple clients. o Multi-tenancy: Embodiments may provide an additional layer of security and isolation between tenants in a multi-tenant cloud environment. Telecommunications o Mobile Networks: Embodiments may be useful in dynamically allocating IP addresses and data services to mobile devices in a secure manner. o Virtual Private Network (VPN): Embodiments may provide an additional layer of verification for business users who require secure remote access. Streaming services ○ Content Delivery Network (CDN): Securely manages resource allocation for optimized content delivery. o Live Streaming: Embodiments may securely and dynamically allocate resources during live streaming events. Financial Services o Secure Transactions: Cryptographic elements / keys can be used for secure online financial transactions. o High Frequency Trading: Embodiments may help provision secure and fast data services in trading environments where latency and security are paramount. Blockchain and decentralized systems ○ Smart Contracts: Securely execute and verify smart contracts. Asset Tokenization: Securely manage data services related to asset tokenization on the blockchain. Public health services ○ Telemedicine: Securely connect patients with healthcare providers in telemedicine scenarios. ○ Patient Data Sharing: Secure and controlled sharing of medical records between healthcare providers. · others o Self-driving cars: Embodiments may be used for secure communication between self-driving cars and control stations. Military applications: Secure dynamic allocation of resources can be essential in scenarios requiring high security, such as military drone operations.

[0127] According to one possible interpretation, "provisioning" may refer to allocating and managing resources within an organization or computing environment. Embodiments disclosed herein may provide a computer-implemented method for securely providing data services using assigned IP addresses and encryption keys. Next, for illustrative purposes, several non-limiting examples are provided showing how such methods and systems can be used in various provisioning scenarios.

[0128] Cloud resource provisioning: Dynamic Allocation: Safe and efficient allocation of computing resources (CPU, memory, storage, etc.) can be optimized by the device controller to ensure that each client or service gets the resources it needs. - On-demand scaling: Secure cryptographic keys allow for easy management of on-demand scaling of resources without compromising security.

[0129] IoT Device Provisioning: - Bulk Device Onboarding: For environments where a large number of IoT devices need to be onboarded, the device controller can assign IP addresses in bulk while maintaining high security through cryptographic keys. - Device Identification and Trust: Devices may be assigned subkeys generated from a primary cryptographic key, which serve as identifiers and secure service access tokens.

[0130] Network Provisioning: - VPN assignment: This method can dynamically and securely assign VPN addresses to employees in a corporate environment. - Subnet management: The controller manages the allocation of subnets within the internal network and may provide a layer of security through encryption keys.

[0131] Data Center Provisioning: - Virtual Machine (VM) Allocation: Securely allocate VMs to different clients or departments within an organization, ensuring that VMs are isolated and secure. - Storage provisioning: Cryptographic keys can act as a security measure when dynamically allocating storage resources.

[0132] Database provisioning: - User Access: Embodiments may control who can access a particular database and what type of access rights (read, write, admin) they have based on encryption keys. - Data Sharding: Data shards can be safely and efficiently allocated among different servers of a distributed database.

[0133] Telecommunications Service Provisioning: Dynamic Bandwidth Allocation: Service providers can use the disclosed embodiments to securely and dynamically allocate bandwidth to various clients or services. Mobile Data Plans: Some embodiments may be adapted to dynamically and securely manage various mobile data plans and services for multiple users.

[0134] Software License Provisioning: License Allocation: Software licenses can be securely and dynamically provisioned to users based on their needs and usage patterns, providing scalability and security.

[0135] Blockchain-based systems: - Deploying smart contracts: The secure provisioning of smart contracts on the blockchain can facilitate automated and secure transactions between parties.

[0136] The combination of IP address assignment and cryptographic security makes this method suitable for secure, dynamic, and flexible provisioning across many scenarios.

[0137] Software Licensing Information: With respect to software licensing, embodiments of the disclosed method and system can be leveraged to create a highly secure and flexible licensing framework. Embodiments can be applied to various aspects of software license provisioning, including at least the following:

[0138] Secure license key generation and distribution: - A cryptographic key or key pair allows for the secure generation of unique license keys for each customer or device. - Subkeys generated from these cryptographic keys can be distributed to individual users or devices, allowing for more granular control and tracking.

[0139] Dynamic Allocation - Embodiments of the disclosed method and system may support on-demand or dynamic allocation of software licenses, allowing businesses to provide licenses exactly when and where they are needed. - The device controller manages the assignment of licenses to specific IP addresses or computing resources, essentially locking licenses to specific systems for added security.

[0140] Flexible License Types The same framework can be used to provision different licenses, from simple single-user licenses to more complex enterprise or network licenses. Additional services, such as data streaming or sharing, can be included as part of the license package and controlled via encryption keys.

[0141] License Validation and Compliance: - User verification at the service provider may be based on cryptographic keys or subkeys, ensuring that only authorized users can access the software or specific functions within the software. - This may help ensure license compliance and prevent unauthorized distribution or use.

[0142] Multi-device support: For users or organizations that need software to be used across multiple devices, a device controller may assign an IP address to each device and manage them centrally. - Each device / device user has a subkey, making it easy to manage multi-device licenses securely.

[0143] Blockchain-enabled transparency: By recording transactions on the blockchain, embodiments enable maintaining a transparent and immutable record of license assignments, renewals, and revocations. - This can be particularly advantageous in compliance audits and resolving disputes regarding software use.

[0144] Enhanced access control: Embodiments of the disclosed method and system restrict software functionality based on the type of license purchased, all of which is securely managed through encryption keys.

[0145] Real-time fixes: Embodiments of the disclosed method and system may also support real-time license modifications, such as upgrades or downgrades, securely enabled through cryptographic subkeys and digital wallets.

[0146] By integrating such capabilities, embodiments of the disclosed method and system may provide a highly secure, flexible, and dynamic approach to software license provisioning that can be advantageous regarding the needs of both providers and consumers, ensuring compliance while providing the flexibility required for modern software usage.

[0147] Music streaming services have fundamentally changed the way users access and listen to music. Rather than downloading or purchasing individual songs or albums, users may pay a monthly fee and access a vast library of songs, albums, and playlists using embodiments of the present disclosure. The following non-limiting example illustrates how music streaming can relate to technologies such as Mobile IP and IPv6.

[0148] Benefits of music streaming over Mobile IP: 1. Seamless connectivity: Mobile IP allows music streaming to be switched from one network to another without interruption. For example, when a user moves from their home Wi-Fi network to a cellular network, their streaming can continue without interruption. 2. Location-based services: Mobile IP makes it easier for services to provide location-specific content without disrupting the user experience. 3. Personalization: The same mobile IP address can be used (assigned) across multiple devices, enabling a more personalized user experience as preference and usage data is centralized.

[0149] The advantages of using IPv6 are: 1. Scalability: Because IPv6 provides a virtually unlimited number of IP addresses, each device (such as a smartphone, laptop, or smart speaker) may have its own IP address, making it easier for music streaming services to provide a highly personalized experience. 2. Improved Security: IPv6's enhanced security features can add an additional layer of security, making unauthorized access to your account more difficult. 3. Quality of Service (QoS): IPv6 can support better QoS parameters than IPv4, which is essential for high-quality music streaming.

[0150] The combination of Mobile IP and IPv6 enables the provision of a diverse and secure user experience. Users can seamlessly move from network to network and device to device without losing their session or having to log in again. This can be especially useful for people who use multiple devices to access their music library.

[0151] According to disclosed embodiments, cryptographic keys can be used to allocate and / or authenticate access to streaming services, providing an additional layer of security and enabling new business models, such as more flexible usage-based subscription services. The integration of Mobile IP with IPv6 provides a seamless, secure, and highly personalized music streaming experience. NAP and Enterprise

[0152] Mobile IP and IPv6 technologies can significantly improve how users authenticate to corporate servers and Network Access Protection (NAP) systems, improving both security and convenience. 1. Enhanced Security: The expansive addressing scheme of IPv6 makes it more difficult for attackers to scan the entire IP address space, thereby improving network security. Advanced cryptography can be easily integrated for stricter authentication. 2. Seamless Roaming: Mobile IP allows seamless roaming between different networks without changing IP addresses. For corporate users who need to switch between various networks (e.g., from office Wi-Fi to a 4G / 5G network), this ensures they maintain authentication to corporate servers without session interruption. 3. Multi-Factor Authentication (MFA): A cryptographic key or key pair can be used alongside traditional authentication methods to add an extra layer of security. These keys can be stored securely in digital wallets and quickly verified over IPv6 networks. 4. Policy Enforcement: With Network Access Protection (NAP), enterprises can enforce policies for network access and ensure that only devices that meet certain health criteria (such as having up-to-date antivirus software) can access the network. IPv6 and Mobile IP can enhance this by making it easier to track and authenticate devices. 5. IoT and Beyond: With more and more devices connecting to corporate networks, IPv6 allows for better scalability, which can be beneficial not only for computers and smartphones, but also for IoT devices that need secure and authenticated access to corporate resources. 6. Improved Auditing and Monitoring: The combination of unique encryption keys (subkeys) and extensible IPv6 addressing allows for improved tracking of who accessed what, when, and from where, which is essential for corporate governance and compliance with regulations such as GDPR, HIPAA, or SOX. 7. Quality of Service (QoS): IPv6 also natively supports QoS features, allowing priority to be given to certain types of traffic, such as VOIP or video conferencing, which is important in corporate environments. 8. Simpler configuration: With IPv6, address autoconfiguration is simpler, which makes it easier to manage large deployments of devices that need to connect to corporate servers.

[0153] Therefore, the combination of Mobile IP and IPv6 can provide a more robust, secure, and efficient mechanism for authenticating enterprise servers and enforcing NAP policies, significantly improving user experience and security posture. Service provisioning using blockchain transactions

[0154] The examples described above illustrate how blockchain can be used, among other things, to securely distribute access requests for use in providing services. Blockchain transactions can additionally or alternatively be used to provide the service itself. That is, data related to services provided by a service provider can be included (in encrypted or clear) in one or more blockchain transactions sent to the blockchain. Each service can be associated with a particular one or more of the assigned IP addresses. The service provider includes service-related data in one or more blockchain transactions sent to the associated IP addresses. The device then uses the assigned IP addresses to obtain one or more blockchain transactions, for example, by listening and / or subscribing to IP addresses. In some examples, the device may also send data related to the service as part of a blockchain transaction sent to an IP address associated with the service. A blockchain node or service provider may monitor the IP address for transactions. The node may then choose to record the transaction on the blockchain. The service provider may process the data contained in the transaction.

[0155] In some examples, one or more IP addresses associated with a service may be generated based on the service. That is, the IP address is a function of some aspect of the service, such as the name and / or identifier of the service, the name and / or identifier of the service provider, etc. The IP address may also be based on the identifier of the device to which it is assigned and / or the identifier of the device controller. The IP address may also be cryptographically linked to the service; for example, the IP address may include or be generated based on a hash of some aspect of the service.

[0156] These examples provide an efficient mechanism for capturing transactions with application (or service) specific data without having to capture or listen to all transactions, such as those not related to the application of interest.

[0157] These examples allow for optimizing traffic management on the blockchain, allowing users to receive only the transactions that interest them. This creates an overlay network with all the transactions necessary to run a particular application or service. The overlay network is established by dividing network traffic using multicast addresses (e.g., IPv4 or IPv6) linked to use cases and / or applications. In this way, users and other stakeholders can listen to only the portion of traffic that interests them. Traffic related to an application may include transactions submitted for publication by users / applications, transactions published by blockchain nodes with their respective SPV proofs, or any other information that may be interesting or relevant to that application, such as alerts, updates, etc.

[0158] Several benefits are presented by these examples. For example, the use-case-specific overlay network created by distributing transactions using IP addresses linked to the use case reduces overall network traffic (i.e., the number of transactions exchanged) since only interested parties receive them. In addition, application / service providers and users are provided with a simplified interface to the blockchain: rather than connecting to blockchain nodes, they simply submit transactions to a multicast address linked to their application and, optionally, wait for SPV proofs.

[0159] In embodiments, multicast addresses are utilized to communicate application-specific data. An application may take any form, such as a protocol, e.g., a communication protocol such as instant messaging, or a token protocol such as CBDC. Each application is associated with (i.e., assigned) a dedicated multicast address, e.g., an IPv4 or IPv6 multicast address. The multicast address associated with a particular application may be assigned by the application owner (e.g., a social media platform) or by a standards body such as IANA, the global coordinating authority for the DNS root, IP addressing, and other Internet protocol resources. In the latter case, service providers may need to apply for address assignment. Users, devices, and other stakeholders may subscribe to that multicast address to receive updates as described above.

[0160] The following use cases can be achieved using the above example: Central banks could release blockchain-based CBDC solutions and monitor all relevant transactions without setting up a full node. Similarly, a user could send a direct payment (peer-to-peer) to another user. The recipient would broadcast the transaction to make it public on the blockchain, and both parties would receive SPV confirmation from the blockchain node 104. Video games could use blockchain to record transactions. Players could subscribe to multicast addresses to receive updates. In an even more lightweight approach, multicast addresses could be linked to different parts of the game (e.g., different worlds, circuits, battles depending on the game). A blockchain node 104 may specialize in validating transactions from multicast addresses, processing them with high priority and responding quickly with SPV proof. The blockchain node 104 may charge a premium service fee for applications and services willing to pay for priority or guaranteed SPV proof. Storage services can subscribe to a multicast address, store data and SPV certificates, and sell access to data relevant to a particular application or use case. Blockchain nodes 104 can prune data without impacting the functioning of the application and the overlay network. Router services could help connect users to blockchain-based applications such as CBDC.

[0161] Government Service Providers In some examples, the service provider may be a government service provider providing services by or on behalf of a government or government provider, or similar public entity, such as an international organization acting for or on behalf of one or more government agencies. The service provider may be referred to as "GOvNet," short for Government Overlay Network. This section describes an architecture for GovNet that may be implemented using embodiments of the present disclosure.

[0162] A defining feature of GovNet is that it maintains a registry of information related to government agencies and / or other government entities. This information can be created by government agencies or citizens. Despite its name explicitly referring to governments, this type of overlay network is equally suitable for any organization wishing to move its government infrastructure onto a blockchain.

[0163] GOvNet is maintained by a Government Server (GS) that communicates with the blockchain and approves data submitted by users to GOvNet. GSs have the authority to create transactions on the blockchain, providing proof of existence of the data. Users of the overlay network register to participate. Registration relies on a public key infrastructure to ensure only authorized and recognized users can access the network's functionality. Below, two primary use cases for GOvNet are described: document management, including creation and distribution, and central bank digital currency.

[0164] GOvNet is a government-maintained overlay network that stores information related to governments, citizens, and other public or private entities. This information may be created by government agencies or citizens and may include citizen information (e.g., personal documents), government information (e.g., residential registration), and payment services (e.g., central bank digital currency).

[0165] GOvNet is maintained by network devices called Government Servers (GS). These servers process information in the overlay network, securely store data, and share it with other devices, such as user devices, public agencies, and other network devices. Government servers guarantee data integrity and timestamp accuracy by publishing anonymized data to the blockchain. To ensure the privacy of authorities and users, only a fingerprint of the data is published.

[0166] Citizens willing to interact with GOvNet may need to be identified and pre-authorized. Information retrieval may be managed through an LDAP service.

[0167] Government Servers (GS) are the main hardware infrastructure of GOvNet. They can replicate necessary data, act as load balancers, or have specific functions. In the latter case, servers can be linked to specific use cases; for example, one or more of them can provide registry services, while others can support Central Bank Digital Currency (CBDC) transactions.

[0168] GS processes and stores information it receives from other GSs and authorized third parties. This information may then be accessed by authorized parties for government-related services. The data is stored in an internal database, called the GS Database, maintained by GS.

[0169] The government server may provide one or more of the following functions: GS Database: GS stores information corresponding to the government services they provide in an internal database. Data may be stored in various formats (e.g., plain text or hashed) to accommodate privacy protection for authorities and users. · Communication with other GSs: GSs communicate with each other to transmit user data and other information, ensuring that data is up to date and consistent. Interaction with the blockchain network: GS uses blockchain technology to timestamp information and ensure data immutability and authenticity. GS manages all services related to transaction publishing and management, such as creating, funding, and publishing blockchain transactions, including the necessary data (or their fingerprints). Proofs of publication (e.g., SPV proofs) are stored in the GS database for lightweight verification. Data Validation: Providing information about the status of stored data when needed for government use (e.g., verifying the validity of a driver's license). This includes proof of publicity on the blockchain (e.g., SPV proof) and proof of inclusion in the GS database. Proof of inclusion in the GS database is called overlay proof. User Access Management: Manages user services, such as verifying that users are authorized to create and access data. The GS communicates to interested users when data is added to the network and provides public proofs (e.g., SPV proofs and overlay proofs).

[0170] The GS databases contain all information necessary for GS to provide the intended government services. For each piece of information received, the minimum information that must be stored in these databases is as follows: A fingerprint of the information to be recorded (e.g., a document hash). Public proofs on the blockchain (e.g., SPV proofs)—also referred to herein as “blockchain proofs.” Proof of Inclusion in GOvNet (e.g., Overlay Proof)—also referred to herein as “Proof of Storage.”

[0171] Optionally, documents and other data may be stored in the GS database either in plain text or encrypted. If documents are stored, the GS may provide data access services (e.g., ID card retrieval), otherwise it only provides proof of validity services (e.g., verifying that a given ID card is legitimate and not expired or invalid).

[0172] SPV proofs are lightweight techniques used to prove that a transaction is publicly available on a blockchain. Typically, an SPV proof contains at least a Merkle proof of the transaction and the corresponding block header. The Merkle proof is used to prove that a given transaction was inserted into a block. The validity of the block is verified by checking that the block ID is part of the longest honest chain.

[0173] Overlay proofs are proof that some data has been accepted into GOvNet. When a fingerprint of the data is added to a blockchain block, an overlay proof can be generated. These can be unforgeable signatures associated with a public key derived from the data. Users can verify overlay proofs independently without relying on GS.

[0174] The following use cases can be realized using GOvNet:

[0175] The government overlay network provides a natural framework for implementing CBDC protocols. CBDC transactions (i.e., blockchain transactions that issue and transfer CBDC) can be submitted to the blockchain by GOvNet. GOvNet is agnostic to design choices regarding the CBDC system.

[0176] Embodiments of the present disclosure may be used to store tax-related data. For example, businesses and / or individuals may use GOvNet to file tax returns, submit invoices, provide tax certifications, etc. For individuals, GOvNet may perform checks to ensure that the tax-related data meets certain criteria. For example, a user filing a tax return may be required to provide entries for different types of taxable income, such as salary, bonuses, dividends, investment income, rent, etc.

[0177] Similarly, the overlay network can also be used to record licenses. For example, nodes of the network can specialize in recording television licenses or business licenses (e.g., licenses to trade certain products). Companies can use storage proof of license to prove to regulators or the like that they are truly licensed. Other types of licenses can be stored on the network, such as intellectual property licenses. The overlay server can verify that a license for the same IP has not already been granted (at least in the case of exclusive licenses).

[0178] The overlay network may be used to store data related to land and / or vehicle ownership and changes in said ownership. For example, each data packet may contain a separate land or vehicle registration or a transfer of land or vehicle ownership. GOvNet may perform a validation step, for example, to ensure that a parcel of land is not sold twice (either inadvertently or fraudulently). To do so, GOvNet may verify that the same land is not already on the overlay network shown as owned by someone else. A user may use proof of containment (proof of storage) to verify that the seller of the land or vehicle is the legitimate owner of the land / vehicle.

[0179] GOvNet can also be used to prove something about a document (e.g., that a document exists, or that a document contains certain data or meets certain requirements) without revealing the document itself. Consider age checks at entry to venues (pubs, nightclubs, etc.), which might involve proving that a person is over 18 without revealing their actual age or any other information that happens to be included on the ID document. In this context, an overlay certificate could be handed out at the entrance to the venue, and security could use that certificate to check with GOvNet that it has accepted the document, which would confirm that the user is over 18 without revealing their details. Since security staff trust GOvNet, no additional checks are needed. Other similar use cases include visas that allow the holder to enter the country.

[0180] Referring now to the embodiments described above, GOvNet provides services to users using assigned IP addresses, i.e., services (e.g., document vaulting, CBDC issuance, age verification, ownership verification, document integrity checks, etc.) may be provided to users (i.e., devices) using the IP addresses assigned to those devices.

[0181] For example, a user may submit data (e.g., a document) to GOvNet from an assigned IP address. In response, GOvNet stores the data and / or its fingerprint (e.g., a hash). GOvNet then submits a proof to the user indicating that the data is stored on GOvNet's servers using the assigned IP address. The proof may take the form of an overlap proof. Additionally or alternatively, GOvNet submits a proof to the user indicating that the data and / or its fingerprint is stored on the blockchain using the assigned IP address. The proof may take the form of an SPV proof.

[0182] As another example, GOvNet may use the assigned IP address to provide service requests to the user. For example, GOvNet may send an indication to the user indicating whether a document is stored by GOvNet and / or whether the document meets one or more criteria. GOvNet may return information about data stored by GOvNet, such as who owns an asset (e.g., in the land registry use case described above).

[0183] In summary, some embodiments of the present disclosure provide a mechanism for proving that data has been accepted for storage on a storage network. The storage network may be maintained by a network of storage providers (e.g., nodes, servers, etc.). The data (or a hash or other type of commitment) is stored by the storage provider. After storing the data, the storage provider generates and provides a proof of data storage (e.g., a signature), which a user may use to verify that the data has been stored or to attest to a different user. The proof (e.g., signature) proves that the data has been accepted by the storage provider. A commitment (e.g., a hash) of the data is also stored on the blockchain. A proof of storage of the commitment on the blockchain may also be provided to the user.

[0184] term As known in the art, the term “node” can refer to a fundamental unit of data structure (in computer science), a connection point in a communications network (networking / telecom), an entity in a mesh network, or a computing resource that runs an implementation of a blockchain protocol, e.g., a miner on the Bitcoin network. Alongside these, devices or systems on a network may also be referred to as “hosts” or “peers” depending on the context. Thus, with respect to the present disclosure, confusion may arise between various terms given that some embodiments may encompass or cross various technical fields. Therefore, to avoid confusion and for clarity, we will use the inclusive terms “network resource,” “processing resource,” “computer-based resource,” or simply “resource” to include “node,” “peer,” or “host,” or any device / system on a network.

[0185] Also, we may refer to the Bitcoin protocol / network / ledger herein for convenience and because it is the most widely known of such technologies. However, this disclosure is not limited to use with Bitcoin, and other ledger-based protocols / networks are intended to fall within the scope of this disclosure. For example, blockchain protocols, networks, and implementations that include a proof-of-stake mechanism or utilize an account-based model rather than a UTXO-based model are intended to fall within the scope of this disclosure. Also, note that "Bitcoin" is not limited to referring to a specific Bitcoin-related protocol; any protocol or implementation that flows from, varies, or deviates from the original Bitcoin protocol is intended to fall within the scope of this disclosure. Public, private, or permissioned blockchains are also intended to fall within the scope of this disclosure.

[0186] As used herein, the phrase "assign" is intended to include "communicatively transmit" or "associate." Thus, assigning a set of IP addresses to a device controller includes associating the device controller with the set of addresses and / or communicatively transmitting the set of IP addresses to the device controller.

[0187] The term "user" includes electronic, processor-based entities as well as human individuals or groups.

[0188] International Patent Application No. PCT / IB2017 / 050856 (published as International Publication No. WO / 2017 / 145016) The embodiments disclosed herein may utilize one or more of the techniques disclosed in International Patent Application No. PCT / IB2017 / 050856, which discloses several embodiments and techniques that can be used advantageously in connection with the present disclosure. These include the generation of subkeys from a master key and the independent generation of a common or shared secret by multiple parties.

[0189] In one aspect, International Patent Application No. PCT / IB2017 / 050856 relates to a technique for generating new cryptographic keys from existing keys. The disclosed technique enables an entity or party to receive a cryptographic private-public key pair (called a master key) and apply a series of mathematical steps to derive related key pairs (called subkeys) that stem from the master key pair. This allows for the construction of chains and hierarchies of cryptographic keys, which a verifier can then mathematically prove are linked to one another.

[0190] At a high level, the technology of International Patent Application No. PCT / IB2017 / 050856 involves the use of a deterministic key (DK) for the generation of new cryptographic keys. This DK is based on a hash of a message. The nature or content of the message is not restricted or limited to any particular format. It may, in some instances, have some meaning or relevance to the parties involved, or it may simply be an arbitrary or random value or string. The choice of message depends on the needs of the parties using the technology for a particular implementation or application. However, messages may be securely transmitted between different parties even over insecure communication channels such as the Internet.

[0191] To illustrate the deterministic subkey generation technique, suppose Alice has a master public-private key pair generated using elliptic curve cryptography (ECC) and a common generator (G). Generator (G) may be selected by Alice according to some criteria, may be generated randomly, or may be obtained by another party, such as Bob. In some use case scenarios, G is shared with Bob over a communications network.

[0192] To generate Alice's private subkey (PvSK), Alice does the following: 1. A selected, obtained, or randomly generated message (M) is hashed using a hashing algorithm. This produces a deterministic key DK. DK=H(M) 2. Generate PvSK using the master private key (MPvk) and scalar addition (+) of DK. PvSK = MPvK + DK

[0193] Please note the following: In the above, the "+" operator represents scalar addition. These steps generate a secret subkey PvSK that is not a random value. Instead, it is derived deterministically from Alice's master private key MPvK.

[0194] Alice can then mathematically derive the corresponding public subkey (PubSK) using the master public key (MPubK) and knowledge of the message. To do so, she calculates: PubSK=PvSK×G Here, the "x" operator represents multiplication of points on the elliptic curve. However, note that using the above formula for generating the secret subkey, this can be expressed as the following series of formulas: 1. PubSK = (MPvK + DK) × G 2. PubSK = MPvK × G + DK × G 3. PubSK = MPubK + DK × G 4. PubSK = MPubK + H(M) × G

[0195] Therefore, another party, say Bob, can also derive Alice's public subkey if he knows the relevant information: the common generator (G), the message (M), and Alice's master public key. This is important because it enables a variety of use cases.

[0196] For example, consider a scenario in which Alice and Bob want to be able to authenticate each other's identities and / or transmit sensitive data between them in a secure manner over communications. Suppose Alice has a cryptographic key pair, called a master public / private key, and knows the same message as Bob. Using her master private key and the message M (which she hashed to generate DK), Alice can perform the mathematical procedure described above to generate a new private subkey. What is important is that the corresponding public subkey can be mathematically derived using Alice's master public key and the message M. Thus, if Bob knows Alice's master public key and M, he can generate Alice's public subkey without requiring it to be transmitted over a communications channel and therefore without the risk of being intercepted.

[0197] Now suppose Bob performs the same procedure described above using his public master key-private master key pair and the same message M. As a result, Bob generates his own pair of subkeys. Each party can then use the new private subkey to sign a message (or other data) and send it to the other. They can then independently generate the other's public subkey and use it to verify that the signed communication must have been provided using the corresponding private subkey, thereby authenticating each other's identity.

[0198] Another aspect of International Patent Application No. PCT / IB2017 / 050856 allows Alice and Bob to generate the same (common) secret independently of each other without the need to transmit the secret over the wire between them. This is described in detail in International Publication No. WO / 2017 / 145016, pages 25 et seq. Alice and Bob can calculate the common secret for themselves by performing a mathematical operation using their own private subkey and the other party's public subkey, which they can calculate for themselves using a shared message M as described above. This shared (i.e., "common"), independently generated secret can be used for various purposes, such as forming the basis of a private key for a symmetric key algorithm that can be used for secure communications between Alice and Bob without the need for over-the-wire transmission over a network and without the risk of being intercepted by unauthorized parties during transmission.

[0199] Some important aspects derived from the technology of International Patent Application No. PCT / IB2017 / 050856 include (but are not limited to): 1) Each subkey is provably and deterministically derived from the master key. It is possible to mathematically prove that a given subkey is derived from a given master key. This is especially important for purposes related to identity verification, traceability and provenance. One way of expressing this is that there is a mathematical audit trail that can be traced from a subkey to its derivation. 2) We can build levels and hierarchies of subkeys that derive from the master key. This is important because it allows us to build structures that reflect the relationship and organizational nature of an entity, such as a business. For example, a parent company may own a master key, from which subkeys are derived for subsidiaries, and further subkeys for internal divisions, and so on. 3) We can share secrets with each other without transmitting them over the wire. Two or more parties can use this technique to generate the same mathematically generated, provable secret, and can do so independently of each other without having to transmit the secret from one to the other over a communications network.

[0200] Exemplary System Overview For illustrative purposes only, and with reference to Figures 1-4, we now present an example of a computing environment in which one or more embodiments of the present disclosure may be implemented. Reference numbers referenced below refer to Figures 1-4.

[0201] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0202] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing unit including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0203] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 within a distributed or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing a quantity of a digital asset as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock it and thereby be redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0204] Each block 151 also contains a block pointer 155 that points back to a previously created block 151 in the chain, defining an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer that points back to a previous transaction, defining an order for the sequence of transactions (note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 stretches all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0205] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "member pool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept any other transactions attempting to consume the same output.

[0206] For a given current transaction 152j, its (or each) input includes a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even transmitted to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and thus does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

[0207] The input of this transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of this transaction 152j can then be cryptographically locked to the new user or entity 103b. The current transaction 152j can therefore transfer to the new user or entity 103b the amount defined in the input of the previous transaction 152i as defined in the output of this transaction 152j. In some cases, transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction can also have multiple inputs to collect amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0208] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more blockchain nodes 104 of the network 106 (currently typically a server or data center, but in principle could be other user terminals). It is also not excluded that the party 103 establishing a new transaction 152j transmits this transaction directly to one or more blockchain nodes 104 and, in some instances, does not transmit it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that the cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction assigns, which condition typically involves at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may be fixed simply by the blockchain node protocol, or result from a combination thereof.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same blockchain node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0209] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., spent) is whether it has yet been validly redeemed by the input of another, forward transaction 152j, according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single defined state at any given time.

[0210] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition could be that the hash output has a certain predefined number of leading zeros. This is just one particular type of proof-of-work puzzle; others are not excluded. A property of a hash function is that it has an unpredictable output given an input. Therefore, this search can only be performed by brute force, thus consuming a substantial amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0211] The first blockchain node 104 to solve the puzzle publishes it to the network 106, providing the solution as a proof that can be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes, who accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. Transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, thus providing an immutable public ledger of transactions.

[0212] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that have not yet been published at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when the same transaction appears in both forks.

[0213] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate the additional accepted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is commonly referred to as a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node constructing the new block’s intention to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0214] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could also take the form of a user terminal or a group of user terminals networked together.

[0215] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any activity attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0216] Also connected to the network 101 are computing devices 102 for each of a number of participants 103 who act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store copies of the blockchain 150 (e.g., obtaining copies of the blockchain from blockchain nodes 104).

[0217] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the necessary roles of blockchain nodes. Instead, each participant 103 interacts with the blockchain network 106 by connecting to (i.e., communicating with) a blockchain node 106, thereby utilizing the blockchain 150. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many more such participants 103 and their respective computing devices 102 may exist and participate in the system 100, but are not illustrated for convenience. Each participant 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0218] The computing device 102 of each participant 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing device 102 of each participant 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given participant 103 herein may be performed using software executing on the processing device of the respective computing device 102. The computing device 102 of each participant 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given participant 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0219] The client application 105 may be initially provided to the computing equipment 102 of any given participant 103 on a suitable computer-readable storage medium, for example downloaded from a server, or may be provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0220] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets they currently own. In an output-based system, this second function involves reconciling the amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0221] NOTE: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugging one into the other. More generally, client functions may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following description will be given with respect to client application 105, it will be understood that this is not limiting.

[0222] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides trust in transactions, in part through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to one another; a given transaction protocol goes hand in hand with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0223] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 most connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, this condition could simply be a built-in feature of the node protocol or be defined by a combination of the script and the node protocol.

[0224] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j forward-propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, then, assuming the transaction 152j is valid, this means that it will immediately propagate throughout the network 106.

[0225] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 begins a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Remember, other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever gets there first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will have solved the puzzle for the portion of the ordered pool 154 that contains Alice's transaction 152j.) After proof-of-work has been done for the pool 154 containing new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer back to previous transactions, so the order of transactions is also immutably recorded.

[0226] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is "valid," with one instance being published in a new block 151, before all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0227] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the transfer amount not by referencing back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called the "position"). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0228] UTXO-based model Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0229] In the UTXO-based model, each transaction (“Tx”) 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0230] For example, Alice 103a wants to create transaction 152j to transfer an amount of digital assets of interest to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could also point back to any previous (i.e., previous) transaction that still has unspent outputs 203 locked for Alice.

[0231] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates, or at least submits, the new transaction Tx1 to the network 106. It may already be included in one of the blocks 151 at that time or may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 could be created and submitted to the network 106 together, or Tx0 could even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (e.g., which transactions point back to which other transactions). These could equally be interchanged with “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” or the like. This does not necessarily imply the order in which they are created, transmitted to the network 106, or arrive at any given blockchain node 104. Nevertheless, subsequent transactions (descendant transactions or "children") that point to a preceding transaction (previous transaction or "parent") are not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await its parent, depending on the node protocol and / or node behavior.

[0232] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be validated and therefore the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, including a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0233] A locking script (aka scriptPubKey) is a fragment of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S), used in blockchain networks. A locking script specifies the information needed to consume a transaction output 203, for example, Alice's signature requirements. An unlocking script appears within the transaction's output. An unlocking script (aka scriptSig) is a fragment of code written in a domain-specific language that provides the information needed to satisfy the locking script's criteria. For example, this could include Bob's signature. An unlocking script appears within the transaction's input 202.

[0234] Thus, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ] is equipped. [Checksig P A ] is Alice's public key P from her public-private key pair.A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer back to Tx1 (e.g., using its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0 to distinguish it from any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that contains Alice's cryptographic signature, created by Alice applying the private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0235] When new transaction Tx1 arrives at blockchain node 104, the node applies its node protocol, which involves running the lock script and unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] where "||" denotes concatenation, "<...>" means putting data on the stack, and "[...]" is a function composed by the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other, with a common stack, rather than concatenating the scripts. Either way, when executed together, the scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature, which signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes Tx1 in its entirety (and thus there is no need to include a separate element specifying the signed portion of the data in plaintext, as it is already inherently present).

[0236] The details of authentication via public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then, given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature with the message, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion, transaction portion, etc., can, in embodiments, mean signing a hash of that data portion or transaction portion.

[0237] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby propagating throughout the network 106. After Tx1 is validated and entered into the blockchain 150, it defines Tx0 to UTXO0 as spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, a blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0238] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0239] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. A small portion of the amount defined in the UTXO cannot be "left" as spent while another small portion is spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay other parties.

[0240] In practice, Alice is typically required to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will be rejected by the blockchain node 104 and, thus, while technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not wish to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a pointer to UTXO0 is the only input to Tx1, which has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that won the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively, or in addition, be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0241] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the responsibility of the wallet function within the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0242] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0243] Typically, the input to a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is a four-byte code typically included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0244] A lock script is sometimes referred to as a "scriptPubKey," referring to the fact that it typically includes the public key of the party to whom each transaction is locked. An unlock script is sometimes referred to as a "scriptSig," referring to the fact that it typically provides the corresponding signature. However, more generally, in all applications of blockchain 150, it is not essential that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language can be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0245] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b may each include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of some participant or third party). The side channel 107 allows for the exchange of data away from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing on the chain 150 until one of the participants chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively, or in addition, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0246] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, a side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over a side channel 107, this does not necessarily imply that all pieces of this data must be transmitted over the exact same link or the same type of network.

[0247] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data via side channels 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the scheme set forth above and / or as will be described in more detail shortly.

[0248] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computing device 102, including outputting information to each user 103 via the device's 102's user output means and receiving input back from each user 103 via the device's 102's user input means. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may also include, for example, an input array of one or more touchscreens (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, joysticks, etc.

[0249] Note: Although various functions described herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in a set of two or more different applications, for example, one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, or the like, it will be understood that this is merely an example, and more generally, the described functionality may be implemented in any form of software.

[0250] 3B shows a mockup of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b, or on the device of another party.

[0251] 3B shows a UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as different UI elements via user output means.

[0252] For example, the UI elements may include one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, or the like. User input means are arranged and configured to allow user 103 (in this case, Alice 103a) to select or otherwise manipulate one of those options, such as by clicking or touching the UI element on the screen or speaking the name of the desired option (Note: as used herein, the term "manual" is meant only in contrast to automatic and is not necessarily limited to the hand or use of the hand).

[0253] Alternatively or additionally, the UI elements may include one or more data entry fields 502. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received verbally, e.g., based on voice recognition.

[0254] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user, for example, this / these may be rendered on a screen or audibly.

[0255] It will be understood that the particular means of rendering the various UI elements, selecting options, and entering data is not important. The functionality of these UI elements will be described in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may, in fact, include one or more additional UI elements that are not illustrated for the sake of brevity.

[0256] Node Software FIG. 4 illustrates an example of node software 450 running on each blockchain node 104 of the network 106, using an example UTXO- or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may run node software including, but not limited to, all three of a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UTXO) j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine calculates Tx from a copy of block 151 of the blockchain 150 stored on the node 104. i Alternatively, Tx i may not yet have been published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi and passes it to the script engine 452.

[0257] Therefore, the script engine 452 executes the Tx i Lock script and Tx j , and the corresponding inputs of the transaction. For example, transactions labeled Tx0 and Tx1 are illustrated in FIG. 2, but the same could apply to any pair of transactions. Script engine 452 executes the two scripts together as previously described, which includes placing data on and popping data from stack 453 according to the stack-based scripting language being used (e.g., Script).

[0258] By executing the scripts together, script engine 452 determines whether the unlock script satisfies one or more criteria defined in the lock script, i.e., whether to "unlock" the output that the lock script is included in. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0259] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, thereby validating the Tx j The total amount of digital assets specified in the output of Tx does not exceed the total amount indicated by its input. iThe pointed-to output of has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions and executes the transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually valid, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j , which the consensus module 455C selects to perform respective blockchain-related functions on Tx j to each ordered set of transactions 154 of the node, and the propagation module 455P j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to only publish a transaction conditional on the transaction being valid and having sufficient remaining transaction fees.

[0260] Also, note that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although this is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome might be indicated by a combination of an implicit protocol-level approval of a signature and an additional positive output of a smart contract (with the overall result considered to indicate true if both individual outcomes are true).

[0261] Enumerated items The items listed therein are provided for the purpose of illustrating some possible embodiments that may be provided in accordance with the present disclosure. The sets of items presented below are for illustrative purposes and should not be construed as limiting, exclusive, or exhaustive. Features described in one set of items may be utilized and incorporated in one or more of the other sets of items. In any one or more of the sets of items below, embodiments may provide computer-implemented methods and / or data distribution methods. Additionally or alternatively, embodiments may provide improved data transmission or exchange methods or improved electronic communications.

[0262] A computer-implemented data distribution method is disclosed. The method may include transmitting a portion of (e.g., blockchain-related) data from a sending resource to one or more groups of receiving resources, each of the one or more groups being associated with a respective address, which may be a multicast address. In other words, groups of resources may be formed, and for each group, the resource subscribes to the members of the group, and all members are associated with an address that identifies the group. Embodiments of the present disclosure may include generating, creating, or providing an IPv6 multicast address.

[0263] One, some, or all of the receiving resources may be full nodes 104 on the blockchain network, or nodes in an overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. The sending resources may be full blockchain nodes 104, or nodes on a blockchain overlay network that reside on one or more full nodes on the blockchain network but communicate with one or more full nodes on the blockchain network. These features may apply to one or more of the set of items presented below.

[0264] Also disclosed herein is a method for producing a medicament for the treatment of a pulmonary arthritis. - a computing device comprising a memory including one or more memory units and a processing device including one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any embodiment described or defined herein; and / or - a computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform any of the methods described or defined in this specification.

[0265] Item Set 1: Item 1. A computer-implemented method for providing data services from a service provider to at least one IP address from a set of IP addresses assigned by the service provider to a device controller associated with one or more computing resources, comprising: associating the device controller with at least one cryptographic key or key pair by or on behalf of a service provider; and assigning, by the device controller, at least one IP address from the set of IP addresses to at least one computing resource of the one or more computing resources.

[0266] Item 2. Data services are Cloud-based services, telecommunications, telephone, internet or broadband related services, television or broadcasting services, or video conferencing services; Data provisioning, Item 14. The method of claim 1, including one or more of the following: data streaming or data sharing services.

[0267] Item 3. Generating subkeys from the at least one cryptographic key or key pair and assigning the subkeys to at least one of the one or more computing resources; and / or 3. The method of claim 1 or 2, further comprising storing at least one cryptographic key, key pair, and / or subkey in a digital wallet.

[0268] Item 4. The method of item 3, wherein the subkey is provably and deterministically generated from at least one cryptographic key.

[0269] Item 5. The method of any one of items 1 to 4, wherein the set of IP addresses is or includes an IP block that includes a range of contiguous IP addresses.

[0270] Item 6. The set of IP addresses includes a range of IPv6 addresses, and / or 6. The method of any one of items 1 to 5, wherein one or more of the following applies: the provision of data services from the service provider to the device controller includes use of the IPv6 protocol, Mobile IP, Mobile IPv6, or Hierarchical IPv6.

[0271] Item 7. The method of any one of items 1 to 6, wherein at least one cryptographic key and / or subkey provides an access control mechanism configured to verify a user at a service provider and, if verified, obtain access to a service.

[0272] Item 8. The method of any one of items 1 to 7, wherein at least one of the IP addresses in the set of IP addresses is a multicast address or an anycast address.

[0273] Item 9. The method of any one of items 1 to 8, including providing a service from a service provider to at least one IP address in a set of IP addresses assigned to or transmitted in a communication to at least one computing resource of the one or more computing resources.

[0274] Item 10. The method of any one of items 1 to 9, comprising providing an access request for access to the data service from at least one computing resource of the one or more computing resources to the service provider.

[0275] Item 11. The method of item 9, wherein the access request or encryption key is provided via or using a blockchain.

[0276] Item 12. The access request or a portion thereof, at least one cryptographic key or key pair, or a subkey derived from at least one cryptographic key or key pair, is provided to or by the service provider via a cryptographically enforced electronic ledger, preferably An electronic ledger is a blockchain ledger implemented by a network of nodes on a blockchain network, and / or 12. The method of any one of items 1 to 11, wherein the access request or a portion thereof, the at least one cryptographic key or key pair, or a subkey derived from the at least one cryptographic key or key pair is provided within an input or output of a blockchain script.

[0277] Item 13. The method of any one of items 1 to 12, including assigning, by the device controller, to at least one computing resource of the one or more computing resources, a deterministic subkey derived from at least one cryptographic key or key pair.

[0278] Item 14. The method of any one of items 1 to 13, wherein one or more respective IP addresses of the set of IP addresses are associated with respective applications or services, and the one or more respective IP addresses are generated based on the respective applications or services.

[0279] Item 15. The method of item 15, wherein one or more respective IP addresses are cryptographically linked to a respective application or service.

[0280] Item 16. The method of item 14 or item 15, wherein the providing of the data service includes providing application-related data or service-related data in one or more respective blockchain transactions submitted to the respective IP addresses associated with the respective IP addresses.

[0281] Item 17. The method of item 16, including using at least one IP address to send and / or receive one or more respective blockchain transactions and / or one or more respective proofs of inclusion associated with each one or more blockchain transactions.

[0282] Item 18. The provision of data services includes: receiving a request to store data from a device assigned a respective IP address; causing a commitment transaction to be submitted to the blockchain, the commitment transaction including a commitment of data; storing and / or publishing data and / or data commitments; 18. The method of any one of items 1 to 17, comprising providing a proof of storage to each IP address, the proof of storage being generated as a function of the data in response to a commitment transaction being submitted to one or more blockchain nodes, the proof of storage attesting that the data and / or commitment of the data has been accepted for storage by the storage provider.

[0283] Item 19. The method of item 18, wherein the storage proof is generated based on the data and / or a commitment of the data and includes a digital signature that is verifiable using a public key associated with and / or generated by the service provider.

[0284] Item 20. The method of item 18 or 19, wherein the data commitment includes at least a hash of the data.

[0285] Item 21. The method of any one of items 18 to 20, including providing a blockchain certificate for each IP address, the blockchain certificate verifying that the commitment transaction is recorded on the blockchain.

[0286] Item 22. The method of item 21, wherein the blockchain proof includes a simplified payment verification (SPV) proof.

[0287] Item 23. A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, wherein the memory stores code configured to run on the processing device, and the code, when on the processing device, is configured to perform the method of any one of items 1 to 22.

[0288] Item 24. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of items 1 to 22.

[0289] Disclaimer No admission is made that any reference cited or referred to herein constitutes prior art. The statements in such references state what their authors assert, and applicants reserve the right to challenge the accuracy and pertinence of the cited documents. A number of prior art documents are cited herein, and it will be expressly understood that such reference does not constitute an admission that any of these documents form part of the general knowledge in the art in the UK, the USA, or any other country.

[0290] Also, International Patent Application No. PCT / IB2017 / 050856 (published as International Publication No. WO2017 / 145016) and its derivative applications filed in the United States are incorporated herein by reference. All references cited herein are incorporated by reference to the fullest extent permitted by law, except that the incorporation by reference of such documents is limited so as not to incorporate subject matter that is contrary to the express disclosure herein. The incorporation by reference of the above patent documents is further limited so that claims contained therein are not incorporated by reference. The incorporation by reference of the above patent documents is further limited so that definitions provided in the patent documents are not incorporated by reference herein, unless expressly included herein. [Explanation of symbols]

[0291] 1 node 5 nodes 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 102a, 120b Computer equipment 103 Users, Parties, and Agents 103a User, first participant, Alice 103b New User or Entity, Second Party, Bob 104 full blockchain nodes, Bitcoin nodes 105 Client Applications 105a Client Applications 105b Client 106 Peer-to-Peer (P2P) Networks 107 Side Channel 150 Blockchain 151 Blocks of Data 151n-1 Block 151n Block 152 transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 154 Pool, Ordered Set 155 Block Pointer 201 Header 202 Input, input field 203 Output, Output Field 301 Side Channel 401 Transaction Engine 402 User Interface (UI) Layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 500 User Interface (UI) 501 resources 501 User Selectable Elements 501, 502 UI elements 502 Data Entry Fields 502a multicast group "a" 502b multicast group "b" 503 Information Elements 3001 Device Controller 3002 Service Provider 3003a, 3003b, 3003c devices 3004 Crypto Wallet 3005 Storage Facilities 3006 Storage Facilities 3007 Public Key 3008 private key

Claims

1. 1. A computer-implemented method for providing data services from a service provider to at least one IP address from a set of IP addresses assigned by the service provider to a device controller associated with one or more computing resources, the method comprising: associating the device controller with at least one cryptographic key or key pair by or on behalf of the service provider; assigning, by the device controller, to at least one computing resource of the one or more computing resources, the at least one IP address from the set of IP addresses; A method comprising:

2. The data service is Cloud-based services, telecommunications, telephone, internet or broadband related services, television or broadcasting services, or video conferencing services; Data provisioning, data streaming or data sharing services; 10. The method of claim 1, comprising one or more of:

3. generating a subkey from said at least one cryptographic key or key pair and assigning said subkey to at least one computing resource of said one or more computing resources; and / or storing said at least one cryptographic key, key pair, and / or subkey in a digital wallet; 3. The method of claim 1 or 2, further comprising:

4. The method of claim 3 , wherein the subkeys are deterministically and provably generated from the at least one cryptographic key.

5. 5. The method of claim 1, wherein the set of IP addresses is or comprises an IP block comprising a range of contiguous IP addresses.

6. the set of IP addresses includes a range of IPv6 addresses; and / or the provision of the data service from the service provider to the device controller includes use of an IPv6 protocol, Mobile IP, Mobile IPv6, or Hierarchical IPv6; 6. The method according to claim 1, wherein one or more of the following applies:

7. 7. The method of claim 1, wherein the at least one cryptographic key and / or subkey provides an access control mechanism arranged to verify a user at the service provider and, if verified, to gain access to the service.

8. The method of claim 1 , wherein at least one of the IP addresses in the set of IP addresses is a multicast address or an anycast address.

9. 9. The method of claim 1, comprising providing the service from the service provider to the at least one of the IP addresses in the set of IP addresses assigned to or communicated to the at least one computing resource of the one or more computing resources.

10. 10. The method of claim 1, comprising providing an access request for access to the data service from the at least one computing resource of the one or more computing resources to the service provider.

11. The method of claim 10 , wherein the access request or the cryptographic key is provided via or using a blockchain.

12. The access request or a portion thereof, the at least one cryptographic key or key pair, or subkeys derived from the at least one cryptographic key or key pair are provided to or by the service provider via a cryptographically enforced electronic ledger, preferably the electronic ledger is a blockchain ledger implemented by a network of nodes on a blockchain network; and / or the access request or a portion thereof, the at least one cryptographic key or key pair, or a subkey derived from the at least one cryptographic key or key pair, is provided within an input or output of a blockchain script; 12. The method according to any one of claims 1 to 11.

13. 13. The method of claim 1, comprising assigning, by the device controller, to the at least one computing resource of the one or more computing resources a deterministic subkey derived from the at least one cryptographic key or key pair.

14. 14. The method of claim 1, wherein one or more respective IP addresses of the set of IP addresses are associated with a respective application or service, and the one or more respective IP addresses are generated based on the respective application or service.

15. 15. The method of claim 14, wherein the one or more respective IP addresses are cryptographically linked to the respective application or service.

16. 16. The method of claim 14 or claim 15, wherein the providing of the data service comprises providing application-related data or service-related data in one or more respective blockchain transactions submitted to the respective IP addresses associated with the respective IP addresses.

17. 17. The method of claim 16, comprising using the at least one IP address to send and / or receive the one or more respective blockchain transactions and / or one or more respective inclusion proofs associated with the respective one or more blockchain transactions.

18. said providing said data service comprising: receiving a request to store data from a device assigned a respective IP address; submitting a commitment transaction to a blockchain, the commitment transaction including a commitment of the data; storing and / or publishing said data and / or said commitment to said data; providing a proof of storage to each of the IP addresses, the proof of storage being generated as a function of the data in response to the commitment transaction being submitted to the one or more blockchain nodes, the proof of storage attesting that the data and / or the commitment of the data has been accepted for storage by a storage provider; 18. The method of any one of claims 1 to 17, comprising:

19. 20. The method of claim 18, wherein the storage proof includes a digital signature generated based on the data and / or the commitment of the data, the digital signature being verifiable using a public key associated with and / or generated by the service provider.

20. 20. The method of claim 18 or claim 19, wherein the commitment of the data includes at least a hash of the data.

21. 21. The method of claim 18, further comprising providing each of the IP addresses with a blockchain certificate, the blockchain certificate verifying that the commitment transaction is recorded on the blockchain.

22. 22. The method of claim 21, wherein the blockchain proof comprises a Simple Payment Validation (SPV) proof.

23. 23. A computing device comprising a memory including one or more memory units and a processing device including one or more processing units, the memory storing code arranged to run on the processing device, the code configured to perform the method of any one of claims 1 to 22 when present on the processing device.

24. 23. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 22 when executed on one or more processors.

Images