Distributed ledger inventory management

Abstract

Inventory management systems, computer-implemented methods, and computer-readable media for managing resources are disclosed. The method comprises the following steps: receiving a resource request from a user; identifying one or more resources capable of satisfying the resource request from a resource pool; generating a smart contract including a resource service protocol for the identified one or more resources; storing data associated with the smart contract in a distributed account book; arranging for the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record use of the identified one or more resources; and generating a settlement request based on updated data associated with the smart contract stored in the distributed ledger.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for inventory management. The present disclosure has particular (but not exclusive) relevance to using a distributed ledger (such as a blockchain) to manage a pool of resources and maintain an immutable record of the use of the resources in the pool.

[0002] Related technical description

[0003] Inventory management systems are used to organize, maintain, sell, and track the use of resources. In such systems, the use of any resource can be tracked. Conventional inventory management systems may need to manage a large number of records to accurately reflect the resources being managed. To achieve this, conventional inventory management systems require considerable computing resources, memory requirements, and a large amount of human effort to create, verify, and maintain the records maintained by the system.

[0004]

[0006] Therefore, a need exists for systems and methods that can overcome one or more of the challenges identified above. Summary of the invention

[0005] According to a first embodiment, an inventory management system for managing resources is provided, the system comprising at least one memory and at least one processor, the memory storing instructions which, when executed by the at least one processor, cause the at least one processor to: receive a resource request from a user; identify one or more resources from a resource pool that can satisfy the resource request; generate a smart contract including a resource service agreement for the identified one or more resources; store data associated with the smart contract in a distributed ledger; arrange for the identified one or more resources to be provisioned to the user; update the data associated with the smart contract stored in the distributed ledger to record the use of the identified one or more resources; and generate a settlement request based on the updated data associated with the smart contract stored in the distributed ledger.

[0006] According to a second embodiment, a computer-implemented method is provided, the method comprising: receiving a resource request from a user; identifying one or more resources from a resource pool that can satisfy the resource request; generating a smart contract including a resource service agreement for the identified one or more resources; storing data associated with the smart contract in a distributed ledger; arranging the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record the use of the identified one or more resources; and generating a settlement request based on the updated data associated with the smart contract stored in the distributed ledger.

[0007] According to a third embodiment, a non-transitory computer-readable medium storing instructions is provided, which, when executed by one or more processors, performs a method for managing resources, the method comprising: receiving a resource request from a user; identifying one or more resources from a resource pool that can satisfy the resource request; generating a smart contract including a resource service agreement for the identified one or more resources; storing data associated with the smart contract in a distributed ledger; arranging the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record the use of the identified one or more resources; and generating a settlement request based on the updated data associated with the smart contract stored in the distributed ledger.

[0008] Further features and advantages will become apparent from the following description of embodiments, which is given by way of example only with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 An inventory management method for managing resources is shown;

[0010] Figure 2 Yet another inventory management method for managing resources is shown;

[0011] Figure 3 An example inventory management system for managing resources is shown;

[0012] Figure 4 An example distributed ledger processing network for use with an inventory management system is shown;

[0013] Figure 5 A method suitable for generating a smart contract is shown;

[0014] Figure 6 A method suitable for generating a settlement request is shown;

[0015] Figure 7 A method suitable for generating a remittance is shown;

[0016] Figure 8 A computing device that may be used to implement one or more of the methods described herein is shown according to an embodiment. DETAILED DESCRIPTION

[0017] Before proceeding with the detailed description, it should be recognized that the present teachings are provided by way of example only and not by way of limitation. The concepts herein are not limited to the use or application of a particular system or method for providing or using an inventory management method and an inventory management system. Therefore, while the means described herein are for convenience of explanation with respect to the exemplary embodiments shown and described, it should be understood and appreciated that the principles herein may be equally applied to other types of systems and methods for managing inventory.

[0018] The present disclosure describes exemplary embodiments with reference to the accompanying drawings, in which like numerals represent the same or similar elements. In addition, with respect to the numbering of the same or similar elements, it should be understood that the preceding number identifies the figure in which the element is first identified and described, e.g., element 100 first appears in the figure. Figure 1 middle.

[0019] A novel method for managing inventory is disclosed. In the following description, the inventory being managed is related to the provisioning of communication services (such as telephone and Internet services). However, the principles described herein can be equally applied to any other type of managed resources, including software services, logistics services, data processing services, data storage services, cloud computing services, management and tracking of physical objects, etc.

[0020] Overview of Provisioning Resources

[0021] Figure 1 A high-level overview of an inventory management method is provided that enables provisioning of resources in response to user requests and subsequently generating settlement requests covering the use of the provisioned resources. Figure 1 As shown, the inventory management method 100 may begin by receiving a resource request at step S110 .

[0022] The received resource request may be in any form that can be understood or interpreted by a computer. The received resource request indicates the type of resource that the user sending the request wishes to access. For example, the resource request may indicate a request for an Internet connection, a telephone service, or any other communication resource. In addition to the resource type, the resource request may also include further requirements that define the resource requirements of the request. For example, when requesting an Internet connection, the resource request may also specify one or more of the required bandwidth, the required upload data speed, the required download data speed, the required service guarantee, the required data quota, etc. Therefore, in one example, the received resource request may specify an Internet connection capable of 50 Mbps (megabits per second) upload and 200 Mbps download, specify an always-online connection guarantee, and an unlimited data quota.

[0023] In some examples, the resource request may be more speculative and may include a request for information about resources available for request. In such cases, an additional process may be implemented in which a summary of some or all of the resources available for request may be sent to the user, prompting subsequent receipt of yet another more specific resource request. For the sake of brevity, this additional process is not shown. In other examples, the initial resource request may be highly specific, indicating, for example, a specific port and connection that the user wants to access.

[0024] Once the resource request has been received, one or more resources will be identified from the available resource pool according to the requirements of the resource request at step S120. Any known method for matching available resources with resource requests can be used. When more than one available resource matches the resource request, the first suitable resource identified can be used in the steps following the method. In other examples, other factors such as cost, availability or geographical distance can be used to select suitable resources among a group of suitable available resources. In some cases, no available resources can meet all the requirements of the request. In such cases, the resources that are closest to the request will be identified. In some examples, multiple resources may be needed to meet a single resource request. In some examples, multiple suitable available resources can be presented to the user requesting the resource and the user is invited to select his preferred resource. In other examples, this selection is not provided to the user.

[0025] After identifying one or more resources for satisfying the resource request, at step S130, a smart contract defining a contract agreement is generated, the contract agreement listing parameters (i.e., terms) for supplying the requested resources to the requesting user. When the resources supplied to the user are provided by the operator of the inventory management system, the smart contract includes a two-party agreement to supply the requested resources. In other examples, when one or more of the resources provided to the user are provided by a third-party supplier, the smart contract may include a multi-party agreement, or may require multiple smart contracts. For simplicity, a two-party smart contract will be described below.

[0026] Smart contracts can be generated by any known mechanism. Several example methods of creating smart contracts will be discussed in more detail in later sections of this specification. For now, it is sufficient to understand that a smart contract is generated and that the smart contract includes a resource service agreement. The resource service agreement lists the parameters of the resources requested by the user to be supplied to the user, and therefore may include a resource identifier, a user identifier, and a billing agreement (i.e., the duration for which the resource will be supplied, the billing frequency, the payment terms, and the agreed fee for a given resource).

[0027] Once a smart contract has been generated, the smart contract may need to be confirmed by the requesting user to inform them of their agreement to the terms of the resource service agreement. In this case, the smart contract can be sent to the user and the method stops until a confirmed smart contract is returned. In other examples, the initial resource request may include explicit or implicit agreement to any provided resource service agreement, in which case the method can proceed without the user confirmation step. In other examples, user confirmation of the smart contract can be received after the requested resources are supplied.

[0028] At step S140, data associated with the smart contract is stored on a distributed ledger. The distributed ledger may be, for example, a blockchain suitable for storing smart contracts. The distributed ledger may be implemented on an Ethereum-based blockchain, a Ripple-based blockchain, a Hyperledger Fabric-based blockchain, or any other suitable distributed ledger technology. In some examples, the entire smart contract may be stored on the distributed ledger, while in other examples, only the smart contract identification information is stored on the distributed ledger, while the smart contract is stored on a separate medium.

[0029] At step S150, the requested resources are provisioned to the user. For example, when an Internet connection is requested, the requested Internet connection can now be provided to the user according to the resource service agreement.

[0030] Thereafter, the user's use of the provisioned resources may be measured or otherwise monitored. For example, in the case of an Internet connection, data usage, the size of data downloaded, and / or the size of data uploaded may be continuously or periodically monitored. In other examples, when the provisioned resources are related to logistics services, the number of resources delivered, picked up, and / or the distance traveled may be monitored. In another example, when the provisioned resources are related to cloud storage, the size of data uploaded, downloaded, and / or stored may be monitored. Similarly, when the provisioned resources are related to cloud computing, uploads, downloads, and / or computing cycles may be monitored. In essence, any metric that can be measured and that provides an in-depth understanding of the user's use of the provisioned resources may be monitored.

[0031] At step S160, data associated with the smart contract is updated based on the user's use of the provisioned resources. In some examples, the smart contract itself stored on the blockchain may be refreshed or renewed as part of this update process. In other examples, only a portion of the data associated with the smart contract may be updated. The updated data indicates the user's use of the provisioned resources and may include a summary of the use within a given time period. For example, for an Internet connection, the updated data may indicate one or more of the total data usage, total downloaded data size, and / or total uploaded data size within a given time period (i.e., a day, a week, a month, a quarter, a half year, or a year).

[0032] Data may be updated on a distributed ledger in response to contract refresh criteria associated with a smart contract. For example, a smart contract may require that data be updated periodically (daily, weekly, monthly, etc.), in which case the data is updated when a specified time period has passed. When a time period is specified in a smart contract, the time period may be associated with a billing cycle listed in a resource service agreement. In other examples, the contract refresh criteria may be associated with one or more of the usage metrics monitored and / or measured for provisioned resources. For example, for an Internet connection, usage data may be updated when the download data size or upload data size exceeds a threshold (such as 1GB, 100GB, 1TB, 100TB, etc.).

[0033] At step S170, a settlement request is generated. The settlement request may include a payment request, an invoice, a remittance, or any other agreed method for settling the use of the provisioned resources. In some examples, the inventory management system may be arranged to send and receive legal payments and / or cryptocurrency payments. The settlement request is generated based on the resource service agreement and the use of the resources as recorded on the distributed ledger. In the example of a provisioned Internet connection, the settlement request may include an invoice for data consumed at a rate agreed in the resource service agreement or a fixed price agreed in the resource service agreement. The form of the settlement request (e.g., to whom the settlement request is made, the format of the request, etc.) may be specified in the smart contract. The generated settlement request may then be sent to the user.

[0034] As can be seen from this high-level overview, the use of smart contracts enables the provisioning of a wide range of resources to users. The use of resources by users can be easily monitored and tracked, and by using a distributed ledger, an immutable record of the use of resource service agreements and resources can be maintained. This immutable record enables the generation of settlement requests based on the actual use of resources, and enables both parties of the transaction to have confidence in the authenticity of the settlement request. Therefore, a flexible "high-trust" inventory management system can be provided. In the following description, it will be explained how this method can be built to further improve the method, thereby providing improved resource onboarding, further automation of the generation of smart contracts, automated dispute management, and two-way automated settlement / remittance.

[0035] Overview of Supply Resources

[0036] Figure 2 A high-level overview of an inventory management method is provided that enables the directing of resources into an inventory management system; the directed resources can then be supplied to users according to the methods described herein. Figure 2 As shown, the inventory management method 200 may begin by receiving a request to supply one or more resources from a supplier at step S210 .

[0037] Alternatively, before a supplier can submit a request to provision resources, the supplier may be required to perform an initial bootstrapping process, which may include subscribing to a supplier access portal that provides partial or full access to the inventory management system, verifying the supplier's legal entity (which may include checking sanctions lists, credit checks, etc.), and accepting / signing a service agreement (which may include a resale agreement (defining how the supplier's resources may be resold to users), a privacy policy, and / or terms of service). In some examples, during or after this bootstrapping process, the supplier may be provided with a supplier wallet stored by the supplier, the inventory management system, or both. The supplier wallet may be suitable for storing one or more tokens associated with the resources they wish to provision (which will be described in more detail below). In some examples, during or after the bootstrapping process, the supplier may also be allocated one or more ports on a system network device. The allocated ports may allow the supplier to provision services to other participants in the inventory management system via the allocated ports. The supplier may also be provided or otherwise exposed to an inventory management system software development kit (SDK) and API so that its resources can be "mapped" to the requirements of the inventory management system.

[0038] Returning to step S210, the received request to supply resources may provide details of one or more resources that the supplier wishes to make available through the inventory management system. Consistent with the previous example, the resource may be, for example, an Internet connection service. Alternatively, the resource may be a cloud computing resource that may supply remote data storage services and / or remote data processing services. For the following description, cloud computing resources will be used to illustrate the method. The received request may also include pricing information that defines the pricing at which the supplier wishes to resell their services. In many cases, the pricing information includes a pricing model that defines a plurality of different prices for different resources and resource service levels.

[0039] The received provisioning request may include all data needed to enable later provisioning of the associated resources. For cloud computing resources, the request may include port and connection information, available capacity, etc. When further information is needed to enable provisioning of the associated resources, the method may generate and send a request for further information in response to receiving the provisioning request (not shown). The received provisioning request may also include information about the supplier (name, address, etc.) and any other information relevant to provisioning the specific resource.

[0040] At optional step S220, the resources associated with the supply request can be evaluated to determine whether they are suitable for inclusion in the resource pool. This evaluation can be based entirely on the received supply request. Alternatively, the evaluation can also be based on further information requested from the supplier and / or based on testing of the resources offered. In some embodiments, this evaluation also includes tokenizing the resources into a standard token format. In the case of large resources, these resources can be split into several parts to enable multiple users to access the same resources. For example, a 100TB cloud data storage resource can be divided into smaller parts, which is a more typical case of data storage required by users: a 100TB resource can be divided into 100 1TB parts, each of which can be represented by its own token (so that 100 tokens represent 1TB of data storage). In other examples where the user is a commercial-scale user, a single 100TB token can be appropriate. It is not necessary to tokenize a given resource, and each of the methods described herein can be equally applied to non-tokenized resources. However, as will be explained later, tokenization can provide a convenient way to manage the ownership of resources handled by an inventory management system.

[0041] At step S230, a smart contract is generated that defines a contractual agreement that lists the terms of use of the supplied resources. In some examples, the smart contract may be based in part on a supplier bootstrapping process. The contractual agreement may cover terms for including the provisioned resources in a pool of available resources and / or for provisioning the supplied resources to users requesting access to the supplied resources. The smart contract may include a two-party agreement to supply the requested resources. In other examples, when providing resources to one or more users, the smart contract may include a multi-party agreement, or may require multiple smart contracts. For simplicity, a two-party smart contract describing the relationship between a supplier and an operator of an inventory management system will be described below.

[0042] Smart contracts can be generated by any known mechanism. Several example methods for creating smart contracts will be discussed in more detail in later chapters of this specification. For now, it is sufficient to understand that a smart contract is generated and that the smart contract includes a resource supply agreement (and optionally one or more resource service agreements as previously described). The resource supply agreement lists the terms for supplying resources to a resource pool and optionally the terms for supplying resources to a user (where standard supply terms have not yet been agreed upon). Therefore, the resource supply agreement may include a resource identifier, a supplier identifier, and a billing agreement (i.e., the billing frequency, payment terms, and agreed fees for a given resource).

[0043] Once a smart contract has been generated, the smart contract may need to be confirmed by the supplier to inform them of their agreement to the terms of the resource provision agreement. In this case, the smart contract may be sent to the supplier, and no further method steps may be performed until the confirmed smart contract is returned. In other examples, the initial provision request may include explicit or implicit agreement to any provided resource provision agreement, in which case the method may proceed without the supplier confirmation step. In other examples, supplier confirmation of the smart contract may not be required at all, or may be requested after the provisioned resources are included in the resource pool.

[0044] At step S240, the data associated with the generated smart contract is stored on a distributed ledger. The distributed ledger may be, for example, a blockchain suitable for storing smart contracts. The distributed ledger may be implemented on a blockchain based on Ethereum, a blockchain based on Ripple, a blockchain based on Hyperledger Fabric, or any other suitable distributed ledger technology. In some examples, the entire smart contract may be stored on the distributed ledger, in other examples, only the smart contract identification information is stored on the distributed ledger, and the smart contract is stored on a separate medium.

[0045] At step S250, the resource associated with the smart contract is added to the resource pool. This step may include adding a representation of the resource to the resource representation pool. Alternatively, when the resource has been tokenized, the token associated with the supplied resource may be moved from a wallet associated with the supplier to a centralized wallet associated with the inventory management system (or otherwise recreated in the centralized wallet), thereby indicating the availability of the supplied resource. Thus, the resource is now available to satisfy a resource request according to any of the methods described herein.

[0046] The use of the provisioned resources may thereafter be measured or otherwise monitored. For example, in the case of cloud computing resources, storage capacity usage, downloaded data size, uploaded data size, and / or processing cycles may be continuously or periodically monitored. In other examples, monitoring may be performed by the provider, who may then periodically or upon request provide usage data.

[0047] At step S260, data associated with the smart contract is updated based on the use of the supplied resources. In some examples, the smart contract itself stored on the blockchain may be refreshed or renewed as part of this update process. In other examples, only a portion of the data associated with the smart contract may be updated. The updated data indicates the use of the supplied resources and may include a summary of the use within a given time period. For example, for cloud computing resources, the updated data may indicate one or more of the total storage usage, total downloaded data size, total uploaded data size, and / or total processing cycles used within a given time period (i.e., one day, one week, one month, one quarter, half a year, or one year).

[0048] Data may be updated on a distributed ledger in response to contract refresh criteria associated with a smart contract. For example, a smart contract may require periodic (daily, weekly, monthly, etc.) updates to the data, in which case the data is updated when a specified time period has passed. When a time period is specified in a smart contract, the time period may be associated with a billing cycle listed in a resource supply agreement. In other examples, the contract refresh criteria may be associated with one or more of the usage metrics monitored and / or measured for the supplied resources. For example, for cloud computing services, usage data may be updated when the download data size or upload data size exceeds a threshold (such as 1GB, 100GB, 1TB, 100TB, etc.), when the total storage capacity exceeds a threshold (such as 10%, 20%, 50%, 80%, 90%, etc.), and / or when the number of processing cycles used exceeds a threshold.

[0049] At step S270, a remittance is generated. Remittances may include automatic payments, invoices, or any other agreed methods for paying for or arranging for the use of supplied resources. In some examples, the inventory management system may be arranged to send and receive legal payments and / or cryptocurrency payments. Remittances are generated based on resource process agreements and the use of resources as recorded on distributed ledgers. In the example of cloud computing services, remittances may include automatic payments for the data storage capacity used and / or the number of used or processing cycles at a rate agreed upon in the resource supply agreement or a fixed price agreed upon in the resource supply agreement. The form of remittance (e.g., where to send the payment, to whom the payment is made, the format of the payment, etc.) may be specified in the smart contract.

[0050] Generating a payment to a supplier may also trigger or otherwise be associated with the generation of a corresponding remittance request to be sent to the user consuming the supplied resource.Any of the methods described herein for generating such a settlement request may be used.

[0051] From this high-level overview, it can be seen that a wide range of resources can be imported into an inventory management system using smart contracts and then provisioned to users. The inventory management system can easily track resources provided by suppliers, and through the use of distributed ledgers, an immutable record of resource supply agreements and the use of the supplied resources can be maintained. This immutable record enables automatic remittances to suppliers based on the actual use of resources, which allows both parties to the transaction to have confidence in the authenticity of the remittances. Therefore, a flexible "high-trust" inventory management system can be provided.

[0052] In addition, the tokenization of resources can provide a convenient method of tracking the ownership / use of resources made available by the inventory management system by using tokens as representations of resources. For example, each resource managed by the inventory management system can initially be represented by a token stored in a centralized wallet managed by the inventory management system, or by a token stored in a wallet associated with the supplier of the resource. When a new resource is supplied to the inventory management system, a corresponding token is created. When a resource is provisioned to a user, the corresponding token can be moved from the centralized wallet to the wallet associated with the user, thereby indicating the provisioning, the user's current "use", and the fact that the resource is no longer available to be supplied to a different user. The movement of the token can include transferring the associated token digitally, wherein the transfer of the token is recorded on the distributed ledger. Alternatively, instead of moving the token, the token in the centralized wallet can be removed, burned, or otherwise destroyed, and then the corresponding token is created or recreated in the user's wallet. In another example, instead of moving the token, the token in the centralized wallet can be amended to indicate the provisioning of the associated resource. Modifying a token may include modifying one or more token data fields to indicate that an associated resource has been provisioned, to link the token to an identifier associated with a user, thereby linking the token to an identifier associated with a wallet of the user. Any token modification, token movement, or token creation / destruction may be recorded on a distributed ledger associated with the inventory management system.

[0053] In some examples, tokens may be used as follows. First, suppliers may initialize the assets they wish to supply to one or more users through an inventory management system. For example, if a supplier wishes to supply 1TB of data storage space, the supplier (or inventory management system) may divide and tokenize the 1TB of storage into 1024 tokens of 1GB storage or 2048 tokens of 0.5GB storage, a combination of different storage sizes, or any other divisions. After tokenization, the supplier's resources may be made available to users of the inventory management system according to any of the methods described herein. For example, a user may then request a set amount of storage (e.g., 2.5GB of storage) from a supplier. In response to this request, 2 tokens of 1GB and 1 token of 0.5 (or 5 tokens of 0.5GB storage) may be selected to provision to the user.

[0054] Once the terms of the provision of resources are agreed with the user and recorded in the smart contract, the supplier or inventory management system can then transfer the three tokens to the user's wallet or recreate the three tokens. Signing or recording the smart contract can directly trigger the allocation of the associated resources to the user, or this can occur at a later time or date. The allocation of resources to the user can also cause (or force) the tokens corresponding to the allocated resources to be moved from the supplier wallet to the user's wallet. In some examples, once the smart contract is finalized, this resource allocation step can occur without further input from the inventory management system. While moving the tokens, one or more tokens in the supplier wallet can be destroyed. For example, when the system has a minimum tokenized denomination of 1GB of storage and 0.5GB of storage (or other non-integer amount) is allocated to the user, then moving the token can cause the 1GB token to be destroyed (to avoid creating a 0.5GB token or maintaining a partially used 1GB token). The destruction of any such token can be recorded, and the destroyed token can be regenerated when the resource is returned from the user. In some examples, when a token does not match the size of the requested resource (i.e., when only 1GB tokens are available and the user requests a non-integer amount of resources), a resource token with an associated capacity greater than requested may be allocated.

[0055] In some examples, the management, monitoring, and / or control of resources supplied to users may be controlled by the supplier supplying the resources. For example, a supplier may tokenize its own resources, make its resources available through an inventory management system, approve smart contracts that define the supply of its resources, transfer tokens associated with its resources from its supplier wallet to a user wallet, monitor the consumption of its resources, and / or contribute to a distributed ledger according to any of the methods described herein. In addition, or in the alternative, some monitoring functions (such as monitoring of the consumption of one or more resources) may be performed by the user. In this way, the functionality of the inventory management system may be distributed across suppliers and / or users, thereby reducing the computational, processing, and storage requirements of the inventory management system.

[0056] When the smart contract associated with the supplied resources expires or otherwise terminates, the tokens in the user's wallet will be returned to the supplier's wallet or centralized wallet, or recreated in the supplier's wallet or centralized wallet. Although the tokens of the "reserved" / "in-use" resources are moved between wallets to describe the business relationship, the supplier's wallet and / or inventory management system may have a "ledger" that records initialized resources, "in-use" resources, and "reserved" but currently unused resources. In many examples, multiple suppliers can contribute resources to the inventory management system. Generating and using smart contracts according to the methods described herein enables monitoring, tracking and management of wholesale relationships (i.e., suppliers to suppliers) and retail relationships (suppliers to users). In other examples, multiple suppliers can contribute resources to meet a single user request. For example, a user can request ports, connections, and cloud resources from the inventory management system. In order to meet this request, the first supplier can enter into a business agreement with the second supplier to meet the resource request. That is, the first supplier may be able to supply ports and connections, but needs to obtain cloud resources from the second supplier (e.g., through a wholesale smart contract). The first provider can then bundle the cloud resources with its own services to offer them to users (e.g., via a retail smart contract).

[0057] In some examples, a token representing a resource may be "simple," containing only an indication of which resource the token is associated with (i.e., a resource identifier). In other examples, a token may include more information and be considered "smart." Such a "smart" token may define certain properties of the resource with which it is associated, and / or provide sufficient data to enable a user to access the resource. In such cases, the token itself may enable a user to access a provisioned resource. For example, consider a "smart token" corresponding to an Internet-connected resource. In this example, the smart token may define three categories of data: 1) provider-side configuration information, 2) connection information, and 3) user-side configuration information. Table 1 below shows the information stored in such a "smart token," which may be provided to enable a user to access a particular Internet-connected resource.

[0058] Supplier Configuration Connection Path User Configuration DC ID path DC ID Switch ID bandwidth Switch ID Port ID EVC ID NNI ID speed VLAN ID speed

[0059] Table 1: Smart Token Configuration Information

[0060] In Table 1, "DC ID" refers to the identifier of the data center that provides Internet connection resources. "Switch ID" refers to the identifier of the switch on which the resources are hosted. "Port ID" refers to the identifier of the port assigned to the user. "Speed" refers to the speed of the port to be provisioned to the user (i.e., 1GB, 10GB, or 100GB). "Path" refers to two access points on both sides of the network, which define the path through which data will be sent between the provider and the user (i.e., the A end and the B end of the network). "Bandwidth" refers to the bandwidth of the connection path. "EVC ID" refers to an Ethernet Virtual Connection (EVC), which is an actual path across the network, which, among other attributes, includes a VLAN ID assigned to the user at the provider NNI. "NNI ID" refers to the identifier of the network-to-network (NNI) port assigned to the resource that the user is trying to reach. "VLAN ID" refers to the identifier of the virtual local area network (VLAN) assigned to the user.

[0061] In other examples, such configuration information may form part of a smart contract, or may be provided to a user separately as part of a provisioning process. For other types of resources, the information stored in a "smart token" (or otherwise provided to a user) will be different, depending on the requirements of the particular resource.

[0062] Inventory Management System

[0063] Figure 3 A high-level overview of an inventory management system 300 is provided. The inventory management system 300 includes an inventory management controller 310, which may be arranged to perform the functionality of any of the methods described herein.

[0064] The inventory management controller 310 controls the resource pool 315. In this example, the resource pool 315 includes four resources 315a to 315d. However, in practice, the resource pool may include hundreds of resources, thousands of resources or more. The inventory management controller may communicate data with each of the resources in the resource pool and / or with one or more suppliers 330 that control the supply of one or more resources in the resource pool. The resource pool may include actual resources that can be provisioned to the user, or a representation of each resource. For example, consider that the resources 315a to 315d in the resource pool represent logistics resources, such as freight containers or cargo trucks. In such examples, resources 315a to 315d may be representations of associated resources, such as tokenized records of resources. For example, a cargo truck may be represented in the resource pool 315 by a token, which includes data such as current, past or future location information, truck size, loading time, loading capacity, travel speed, cost per mile, cost per load, refrigeration capacity, types of goods that can be carried, etc.

[0065] The inventory management controller 310 is arranged to add resources to the resource pool 315 and to provision resources from the resource pool 315 according to any of the methods described herein. The inventory management controller is also arranged to generate or otherwise receive a smart contract that defines a contractual agreement for placing resources into the resource pool 315 and / or receiving access to resources in the resource pool 315.

[0066] In addition, the inventory management controller 310 can be in data communication (directly or through a distributed ledger manager (not shown)) with a distributed ledger 320. The distributed ledger can be addressed by the inventory management controller 310 to create and propagate an immutable record of smart contracts generated or received by the distributed ledger.

[0067] In this example, the inventory management controller 310 is shown as being in data communication with three users 340a to 340c. This data communication can be achieved through any known wired or wireless communication technology. In practice, the inventory management controller can be connected to more users. Figure 3 , user 340a and user 340c are shown within a dashed box 350, which indicates associated resources 315e to 315g. The bounding box can be considered to indicate a "user wallet" that contains tokens associated with resources 315e to 315g. As previously explained, when resources are provisioned to users, the tokenized representation can be moved from the central wallet (i.e., resource pool 315) to the user wallet (i.e., one of wallets 350). In some examples, a particular resource may have multiple associated tokens in the resource pool. In this case, each time a resource (or a portion of a resource) is assigned to a user, the token associated with the resource can be moved from the centralized wallet to the user wallet to represent the assignment of the resource to the user. When all tokens associated with a particular resource have been removed from the centralized wallet, the particular resource will no longer be represented in the resource pool and therefore will no longer be available to satisfy future resource requests. In some examples, rather than moving a token, a corresponding token may be recreated in the user's wallet to represent the allocation of a resource to the user; the token in the centralized wallet may then be deleted, marked as inactive, marked as "in use," or otherwise modified to indicate that the associated resource has been allocated to the user. In another example, as will be explained in more detail below, resources may be supplied to the user from a supplier external to the inventory management system, the supplier having a supplier wallet, which may also be updated to reflect the allocation of resources to the user. The update of the supplier wallet may also include one or more tokens indicating that the supplied resource was deleted, marked as inactive, marked as "in use," or otherwise modified.

[0068] User 340b has no associated resources or “user wallet” which may indicate that either the resources have not been allocated (and therefore no user wallet needs to be created), or user 340b is not actively using the resources (in which case the user's wallet may have been deleted or otherwise suspended).

[0069] Each user 340a-340c is in data communication with the inventory management controller 310 and can be provisioned with one or more resources from the resource pool 315 according to the methods described herein by interacting with the inventory management controller. Once provisioned, the inventory management controller can monitor the use of the resources (either through direct communication with the resources or through reports received from the users). Thereafter, the inventory management controller can record the use of the provisioned resources on a distributed ledger.

[0070] In some examples, users may interact directly with distributed ledger 320 . Figure 3 This is shown in FIG. 3 by a 2-way link between user 340c and distributed ledger 320. User 340c may be provided with read-only access to the distributed ledger, enabling user 340c to review data stored in the distributed ledger. A user may have continuous read-only access to the distributed ledger, or may receive temporary access in response to the inventory management controller receiving (and verifying) a distributed ledger viewing request from the user. Any known security verification process may be used to implement access to the distributed ledger. For example, a distributed ledger viewing request may include a user identifier and one or more security credentials (such as a password). The inventory management controller may then verify the user identifier and password by cross-checking the information with a verification database. Additionally or alternatively, public-private key pairing, hashed passwords, two-step verification, verification codes, or other security processes may be implemented. In some examples, secure user data may be stored on a private portion of the distributed ledger.

[0071] Once the distributed ledger viewing request has been authenticated, the inventory management controller 310 may identify one or more smart contracts stored on the distributed ledger that correspond to the user identifier included in the request. The user may then be allowed to view only the smart contracts (and any associated data) that correspond to the user identifier. In this way, the user is able to view and authenticate data associated with them stored on the distributed ledger while maintaining the privacy of data associated with other users of the system. In other examples, such as those described in reference to FIG. Figure 4 As explained in more detail, users may be provided with both read access and write access to the distributed ledger. In addition, users may be able to locally host processing nodes for the distributed ledger, thereby facilitating the proliferation of the distributed ledger.

[0072] Overview of the Distributed Ledger Processing Network

[0073] Figure 4 An overview of a distributed ledger processing network 400 suitable for use in conjunction with an inventory management system is provided. As previously described, the distributed ledger processing network 400 may be directly controlled by an inventory management controller 410. Alternatively, as Figure 4 As shown, a distributed ledger manager 420 may be introduced, which is arranged to set up and operate a processing node of the distributed ledger processing network 400. In some examples, the inventory management controller 410 and the distributed ledger manager 420 may be combined.

[0074] In this example, the distributed ledger processing network 400 includes four centrally managed nodes 430, labeled 430a to 430d. Figure 4 Four centrally managed processing nodes are shown, but in practice more or fewer nodes may be used depending on the underlying technology of the distributed network. The systems and methods described herein are independent of the type of distributed network technology. Each centrally managed node 430 can communicate data with each other centrally managed node, or with its nearest neighbor (as shown). Each processing node maintains a copy of the distributed ledger and updates the distributed ledger in conjunction with other processing nodes of the system according to any known distributed ledger protocol. In this way, the centrally managed processing nodes 430 together form a network of processing nodes that can process and verify all new data added to the distributed ledger.

[0075] The greater the number of processing nodes in the network, the more difficult it is to successfully conduct a "brute force" attack on the network (since a successful brute force attack requires 51% of the network). However, each additional processing node requires computing and memory resources, increasing the cost of running a distributed ledger processing network. In some examples, the number of centralized processing nodes is selected to consist of the minimum number required to protect the network from any reasonably anticipated risk of attack. As described below, by introducing remote processing nodes, the system can also be made more secure and the centralized processing burden can be reduced.

[0076] When the distributed ledger processing network 400 is first set up, most processing nodes will likely be centrally set up and managed by the distributed ledger manager 420. However, in some examples, users are able to contribute to the operation of the distributed ledger processing network by hosting their own local processing nodes (also referred to as “remote processing nodes” because they are located “remotely” from the centralized processing nodes 430).

[0077] exist Figure 44, user 440a does not host a remote processing node. For user 440a, any interaction with the distributed ledger is handled through communication with inventory management controller 410, as previously described. There are many reasons why user 440a may not be able to host a remote processing node. For example, the user may not be able to handle the burden of hosting a remote processing node, the user may be content to access the network only through the inventory management controller, or the system may not have enough trust in the user to authorize the user to own a remote processing node.

[0078] exist Figure 4 , two users 440b and 440c have been entrusted with their own remote processing nodes 430e and 430f. In some examples, users who wish to host their own processing nodes may need to submit to additional verification steps, such as credit checks, address verification, etc. In addition, system security requirements may be imposed on users who wish to host their own processing nodes. In other examples, users may be verified by analyzing a history of successful transactions with the system or any other known method of verifying users. User verification may be performed by the distributed ledger manager 420 or the inventory management controller 410. In other examples, the system may have sufficient trust in the user to not require any verification steps.

[0079] Users may wish to undergo this verification process and accept the burden of hosting a processing node in order to have a high degree of trust in the data maintained by the inventory management system and to enable automated billing based on a distributed ledger in accordance with any of the methods described herein. Additionally, in some examples, users hosting processing nodes may be rewarded for processing the computations required to propagate the distributed ledger. For example, in a "proof of work" or "proof of stake" type distributed ledger (such as a blockchain-based system), users may receive block rewards (i.e., mining rewards). In other examples, each user hosting a remote processing node may receive a set amount of compensation based on their contribution to the system.

[0080] The user may be authenticated by the distributed ledger manager in response to receiving a distributed ledger inclusion request from the user or some other indication that the user is capable of hosting a remote processing node. Once the user is authenticated (if necessary), the distributed ledger manager may generate a set of configuration settings for the new processing node. The distributed ledger manager may then send the generated configuration settings and a copy of the current distributed ledger to the user for use by the user to set up the remote distributed ledger processing node. The user may then apply the generated configuration settings to the locally hosted processing node, thereby configuring the locally hosted processing node as a remote distributed ledger processing node.

[0081] Remote processing nodes 430e and 430f may be indistinguishable from processing nodes 430a to 430d, except that they are hosted by the user and are therefore located at a remote location. In order for remote processing nodes 430e and 430f to contribute to the proliferation of the distributed ledger, the remote processing nodes must be in data communication with at least one other remote processing node. In other examples, remote processing nodes 430e and 430g may be connected to every other processing node in system 400 or only adjacent processing nodes (as shown). Once established, distributed ledger processing network 400 may operate in conjunction with any of the methods described herein.

[0082] Smart Contract Generation

[0083] In the methods described herein, one or more smart contracts are generated to record contractual agreements to supply or consume resources managed by an inventory management system. Figure 5 A method for generating a smart contract is shown, which can be used in conjunction with any other method described herein. Figure 5 The described methods may be applied to smart contracts defining relationships with suppliers who wish to place resources into a resource pool and to smart contracts defining relationships with users who seek to access one or more of the resources of the resource pool.

[0084] The method 500 starts at step S510 by receiving a request to create a smart contract. This request can be a resource request (as previously described), a supply request (as previously described), or any other request indicating that a new smart contract needs to be generated.

[0085] At step S520, the received request is analyzed to extract parameters suitable for use in the smart contract. For example, when the received request is a resource request, the extracted parameters may include one or more of the following: the name of the requesting user, the address of the requesting user, the parameters of the requested resource, the financial offer for using the requested resource, etc. Parameters may be extracted from the received request using any known data extraction technology. In some examples, the analysis step includes applying an optical character recognition (OCR) process to the received document to extract machine-readable text. The received document may be a handwritten or computer-generated resource request form, an invoice, or other user document. In other examples, a machine learning algorithm may be applied to extract relevant parameters. In other examples, the inventory management system may be configured or implement an application programming interface (API) that is arranged to receive and process requests according to any method described herein. The API may also be configured to generate and process smart contracts, settlement requests, and / or remittances according to any method described herein. Once the request has been analyzed and the parameters have been identified, the parameters may be sorted, annotated, or otherwise interpreted to define which parameters have been extracted from the request.

[0086] At step S530, the extracted parameters are reviewed to determine whether sufficient parameters have been extracted to generate a smart contract. This step may include comparing the extracted parameters to a set of required parameters that are predetermined to be necessary to generate a smart contract. For example, it may have been determined that each smart contract requires at least: 1) a user name, 2) a user address, and 3) a requested resource type. In other examples, a broader set of required parameters may be required to establish a suitable smart contract. However, for ease of understanding, the following examples will be explained assuming that only the three listed parameter types are required.

[0087] In this example, it is determined whether additional parameters are required at step S530. Although the analyzed request may contain a user name and a resource request type, in this example, the user address may be missing or incomplete. In this case, the method proceeds to one or more of steps S540, S542, S544, or S546 to obtain one or more parameters corresponding to the missing parameters from the required parameter set (user address). In the following, each step in steps S540 to S546 is described as optional. In some examples, only one of the following four steps may be used. In other examples, two, three, or four of the steps may be implemented in the smart contract generation method.

[0088] At optional step S540, to find the missing parameters, a distributed ledger including previously created smart contracts may be searched to identify one or more similar smart contracts. In this example, the distributed ledger may be searched based on the username parameter retrieved from the initial request to identify other smart contracts associated with the same username. If one or more such smart contracts can be identified, the missing address parameter may be extracted from the smart contract. In some examples, the identified smart contract may also be used to verify any other parameters extracted from the original request.

[0089] In addition to or as an alternative to the name parameter search, the distributed ledger may be searched to identify a smart contract based on the resource type parameter of the request. In this case, if a particular resource from a resource pool is only requested by a particular user, a unique address parameter may be identified. In other examples, any parameter or combination of parameters extracted from the original request may be used to search the distributed ledger in an effort to identify missing parameters. In other examples, the parameters used to search the distributed ledger are prioritized based on their likelihood of retrieving a unique or correct result.

[0090] Some of the possible search combinations that can be used may return smart contracts with different suggestions for missing parameters. In this case, the search results may be analyzed to produce a "best guess" result, which may be, for example, the most common result or the most recent result. It is not necessary to identify the correct missing parameters at this stage, as there may be a later data verification step. In such cases, it is preferable to collect enough information to generate a smart contract so that a verifiable contract can be generated (which is likely to be correct anyway), rather than requiring human intervention at the initial contract creation step.

[0091] If no similar smart contracts are identified or an insufficient number of similar smart contracts are identified at step S540 (or if step S540 is not performed), the method may proceed to optional step S542. At step S542, a request for further information may be generated and then sent to the user. In this example, the request for further information may include a request for missing user address parameters. In other examples, any missing parameters may be requested from the user. Although the request for further information may be computationally simpler than some of the alternatives described herein, requesting further information may cause a time delay in the process while the user responds. In addition, in some cases, if the user is required to provide information that has been previously provided, requesting information that would otherwise be available by analyzing the distributed ledger may cause frustration to the user. However, in some cases, requesting further information from the user may be the only way to obtain the missing parameters, or may be a preferred option for other reasons.

[0092] Additionally or alternatively, at step S544, an artificial intelligence engine (which is trained on a corpus of training data including data extracted from the distributed ledger) may be implemented to suggest a "best guess" for the missing parameters. Any suitable known artificial intelligence algorithm may be used, such as a naive Bayes classification algorithm (supervised learning - classification algorithm). The artificial intelligence algorithm may also be trained using additional data that does not form part of the distributed ledger but is otherwise relevant to the suggestion of parameters for the smart contract. Using an artificial intelligence engine may provide suggested parameters that were not originally derivable from the user request or data contained within the distributed ledger.

[0093] Additionally or alternatively, at step S546, a request for manual input from an operator associated with an inventory management system implementing the presently described method may be generated. Generally, a request for manual input is only required when one or more of options S540 to S544 have been unable to identify a suggestion for the missing parameter. In some examples, any manual input received from the operator may be stored in a distributed ledger and / or fed into a training corpus for an artificial intelligence engine to reduce the likelihood of needing similar manual input in the future.

[0094] Regardless of which steps S540 to S546 or combination of steps is used, once a suggestion for a missing parameter has been identified, the method may return to step S530 to check whether any additional parameters are required to generate the smart contract. If additional parameters are required, one or more of steps S540 to S546 may be repeated. When multiple options for missing parameters are obtained, the options may be analyzed to identify a "best guess" or multiple options may be presented during the contract verification step, enabling the user to select the correct option.

[0095] Once all required parameters of the smart contract have been obtained, the method proceeds to step S550 of retrieving the definition of one or more resources. In the present example, this may include identifying one or more resources from a resource pool that are suitable for satisfying the requirements of the resource type parameters of the request. Returning to the earlier example, when the resource is related to an Internet connection service, step S550 may require analyzing the resource pool to determine which available resources most closely match the resource type parameters of the request. For example, this may require identifying one or more resources that match a request for a 50MB unlimited data cap Internet connection. At step S550, additional information related to the one or more identified resources may also be retrieved. This additional information may include, for example, who the supplier of the resource is, the cost of the resource per unit time, additional capabilities of the resource, technical parameters of the resource (such as connection port number and port address), geographic location of the connection point, etc.

[0096] At step S552, one or more rules that help define the contractual relationship for supplying or receiving resources can be defined. For example, these rules can be related to the minimum service (or minimum resource) that can be provisioned to the user. In addition, the rules can define the breach of contract criteria, i.e., what constitutes a breach of contract and / or what steps will be taken when a smart contract is breached, such as terminating or reducing the resources supplied, canceling the smart contract, fines, etc. The rules can define parameters related to the supply of specific resources and / or the payment for the use of specific resources. For example, these rules can define the service level of a given resource, the parameters of the supplied resources (such as upload speed or download speed), what happens to the supply of smart contracts / resources in the case of non-payment, partial payment, failure to supply resources, partial failure of supply resources, etc. In addition or as an alternative, these rules can provide one or more difference thresholds, which allow the smart contract to operate normally as long as the change in use or supply does not exceed the threshold amount. For example, for a 50MB Internet connection, a rule that enables data speed to vary within + / -5MB can be created. Similarly, if the smart contract agrees to a monthly price of $100 for a given resource, a rule can be created that will accept any payment within + / - 5% of this amount. If the internet connection is consistent with a capped 100GB download limit, a rule can be created that will implement a 10% excess of this download limit before applying any penalty terms associated with the smart contract. Thus, such thresholds enable more flexible smart contracts that can take into account, for example, variability in the supply of resources, variability in the accuracy of monitoring consumption of resources, and / or variability in exchange rates (which can result in unexpected underpayments / overpayments).

[0097] The rules generated as step S552 may be predefined. For example, each smart contract generated for supplying a specific resource may automatically generate one or more predefined rules (such as those described above). Alternatively or in addition, one or more rules may be created (or existing rules may be modified) based on an analysis of the resources to be supplied and / or an analysis of the user. For example, when the resource to be supplied to the user is a 50MB internet connection as a subdivision of a larger 1GB internet connection, the rule that would normally allow a download speed of + / -5MB may be reduced (to + / -1MB or 0MB) to avoid excessive consumption of resources (which may be caused when the entire 1GB internet connection is allocated to different users). In another example, analysis of other smart contracts associated with a specific user may indicate that the user frequently violates specific rules (data usage or payment terms) in the smart contract. In this case, additional user-specific rules may be generated (e.g., requiring additional restrictions on data usage, or stricter payment terms), or existing rules may be adjusted to achieve the same effect.

[0098] In addition, one or more of the rules generated at step S552 may include smart contract refresh parameters that define when the smart contract should be updated or extended, when a request for payment for use of associated resources should be requested (i.e., when a settlement request should be generated), and / or when data associated with the smart contract should be updated. For example, a rule may be generated that requires that use of resources associated with the smart contract be recorded every 24 hours, that a settlement request should be generated at the end of each calendar month, and that the smart contract should be extended (and possibly amended) annually.

[0099] At step S554, a smart contract can now be generated. The generated smart contract may include parameters extracted from the request initially received, any additional parameters obtained in any of the optional steps S540, S542, S544, and / or step S546, definitions of one or more resources identified at step S550, and any rules generated at step S552. Once generated, optionally at step S556, the smart contract may be sent to the user to request their consent to the terms of the smart contract. In some examples, this consent may be limited to a binary "yes" or "no" selection, where the process may stop if the contract is not agreed to. In other examples, if the contract is not agreed to at step S556, the disagreement may be reported to the operator of the inventory management system, who may decide whether to edit any terms of the smart contract and request consent to the revised smart contract or end the process.

[0100] Generating rules at step S554 may also include using a machine learning algorithm to predict (or rank) user reliability, which indicates how reliable the client is predicted to be in settling any future payment requests and / or complying with any other rules generated at step S554 (similar to a credit score). For example, a naive Bayes classification algorithm (supervised learning—classification) may be used to determine the probability that a user will make a false claim (dispute) during settlement based on the supplied user information and any other information recorded in the distributed ledger or otherwise accessible to the inventory management system. The machine learning algorithm and / or the predictions made by the machine learning algorithm may be updated over time based on observations of the user's behavior and their use of provisioned resources.

[0101] In other examples, the smart contract sent to the user at step S556 may be user editable, enabling the user to edit one or more of the terms of the smart contract. This user edit may be limited to certain parts of the smart contract, such as user addresses or supplier preferences. In other examples, any terms of the smart contract may be edited, enabling the revision of financial terms, rules, and thresholds. When a smart contract is edited by a user, the edited smart contract may be reported to an operator of the inventory management system to decide whether to agree to the user edit. Alternatively, the edited smart contract may be consulted by an artificial intelligence engine or a rule-based algorithm to determine whether the edit is acceptable based on the allowed edits in similar smart contracts stored on a distributed ledger. In some examples, any acceptable edits made by the user may be stored and used to edit predefined rules, or otherwise affect the creation of rules created for future smart contracts.

[0102] In some examples, multiple smart contracts can be generated and presented to the user for consent. For example, when multiple resources in a resource pool can satisfy a user's request, several options can be presented to the user, which may have different suppliers, different unit time costs of resources, different geographical locations, etc. In this way, the user can be enabled to select (for example) more expensive resources from their preferred suppliers rather than cheaper resources from different suppliers. Other user preferences can also be processed similarly, enabling users to select based on, for example, geographical location, maximum upload speed, maximum download speed, etc. In other examples, a single "best fit" smart contract is generated and presented to the user for consent. In other examples, the request protocol step S556 is not used at all, and the initial resource request is regarded as an explicit or implicit acceptance of the generated smart contract. In these examples, the "best fit" smart contract can be used based on: any resource from the resource pool that is considered to be closest to the requirements of the original resource request.

[0103] Next, at step S558, the smart contract is stored on the distributed ledger. Recording the smart contract on the distributed ledger can cause the resources associated with the smart contract to be provisioned to the user directly from the supplier or through the inventory management controller as previously described. Alternatively, the resources associated with the smart contract may have been provisioned in response to the user accepting the terms of the smart contract at step S556 or at any previous step. In other examples, the resources associated with the smart contract may not be provisioned until one or more future conditions are met. For example, the smart contract may include a pre-payment rule that prevents the provisioning of resources before payment for the use of the resources is received.

[0104] In conjunction with storing the smart contract at step S558, in some examples, the user wallet, supplier wallet, and / or centralized wallet may be updated to indicate to the user the allocation of resources associated with the smart contract. For example, a token associated with the allocated resource may be moved from the supplier or centralized wallet to the user's wallet to indicate the resource being allocated. In some examples, rather than moving the token, the token associated with the allocated resource may be modified to indicate the allocation of the resource. In other examples, a new token (or tokens) may be created in the user's wallet indicating the resource now allocated to the user, and any corresponding tokens in the supplier or centralized wallet may be updated or deleted to reflect the allocation of the resource.

[0105] Operation of Inventory Management System—User Settlement Request

[0106] Figure 6 Another method of operating an inventory management system to monitor the use of resources of a token and automatically generate a settlement request for use is shown. At step S610, the use of one or more resources being used by a user is monitored. The use of one or more resources is periodically recorded. As previously described, the method of monitoring and the frequency of recording can be set by one or more rules present in a smart contract associated with one or more resources. For the following description, an Internet connection service will be used again as an example. For example, consider a 50MB Internet connection, where a user is provided with a 100GB monthly usage cap. The smart contract associated with this Internet connection may include a rule requiring monitoring of the size of downloaded data (i.e., the amount of data downloaded using the Internet connection) and recording the use daily (i.e., recording the total downloaded data size daily). This information can be recorded together with the smart contract stored on the distributed ledger. In this way, both users and operators of the inventory management system can access an immutable record of the daily use of the supplied Internet connection.

[0107] At step S620, one or more contract refresh criteria are reached, which triggers execution of step S630. The contract refresh criteria may be, for example, reaching a billing date specified in the smart contract (i.e., when monthly billing is specified, when the date reaches the end of the calendar month). Alternatively, the contract refresh criteria may be related to recorded usage (i.e., a payment request is generated once a 100GB usage cap is reached).

[0108] At step S630, the smart contract may be retrieved or otherwise analyzed to extract parameters needed to generate a settlement request. These parameters may include, for example, a user identifier, an address identifier, an agreed-upon fee rate for a particular resource, etc. In addition, at step S630, usage data associated with the resources associated with the smart contract is retrieved to enable the recorded usage to be compared with the terms of the smart contract at step S640.

[0109] Based on the comparison at step S640, a decision is made at step S650. If the recorded usage of the particular resource matches the usage parameters defined in the smart contract (which may have been modified by one or more rules defining threshold deviations from the agreed usage parameters), the method proceeds to step S660.

[0110] At step S660, a settlement request is generated (and subsequently sent to the user). The settlement request may be generated based on parameters defined in the smart contract (which may, for example, define to whom the invoice should be made, where the invoice should be sent, and how much the invoice should be). Once the settlement request is generated and sent to the user, the method may return to step S610 where the method repeats. In some examples, the method may require confirmation that the user has paid the settlement request within a timeframe defined in the resource provision agreement, wherein if confirmation is not received, the use of one or more resources may be limited or stopped.

[0111] Returning to step S650, if the recorded usage does not match the usage parameters defined in the smart contract, the method can proceed in different ways. In some examples, the usage may exceed the usage parameters defined in the smart contract. For example, in the Internet connection example, the user may have used more than their agreed data quota. Similarly, in the cloud computing example, the user may have exceeded their agreed data storage quota or agreed data processing quota. In such cases, it is helpful to identify the overuse of resources to enable charging for the overuse and / or to adjust the associated smart contract to better reflect the user's requirements.

[0112] In other examples, usage may be below the agreed usage parameters. For example, a user may have used less of a resource than they originally expected, or stopped using a resource altogether. In such cases, it is helpful to identify under-usage of resources because this enables the reallocation of persistently under-used resources to other users, which enables finalization and disposal of smart contracts related to services that are no longer in use. In some examples, identifying under-usage of resources may also enable charging users only for actual usage of the resource, which may be beneficial compared to charging a fixed fee for the resource.

[0113] After identifying at step S650 that the recorded usage does not match the usage parameters defined in the smart contract, the method may proceed to step S670 where a partial settlement request may be generated and then sent to the user. The partial settlement request may be generated in the same manner as the settlement request of step S660, i.e., based on the parameters defined in the smart contract (which may, for example, define to whom the invoice should be made, where the invoice should be sent, and what the invoice should be for). However, the partial settlement request may be limited to covering only the recorded usage (when the usage is less than the agreed usage parameters). In other examples, the partial settlement request may be capped at a level agreed upon in the smart contract (when the usage is above the agreed usage parameters).

[0114] At step S680, a discrepancy notification may be generated that alerts an operator or another element of the inventory management system to the discrepancy between the recorded usage and the expected usage as defined in the smart contract. The discrepancy notification may include the smart contract and the associated recorded usage, and the discrepancy notification may be graphically represented in a user interface visible to an operator of the inventory management system.

[0115] At optional step S690, a supplemental settlement request may be generated to cover any additional resource usage not covered by the partial settlement request. The supplemental settlement request may be generated in response to input from an operator of the inventory management system. Alternatively, the supplemental settlement request may be automatically generated based on an analysis of the difference notification. In some examples, further data may be analyzed to determine whether to generate a supplemental settlement request, such as previous resource usage data, payment history data, usage trend data, global resource usage data, etc. (each of which may be retrieved from a distributed ledger or otherwise derived). In other examples, it may be determined by an operator or automatically that a supplemental settlement request is not warranted.

[0116] At optional step S695, it may be recognized that it may be necessary to amend one or more terms of the smart contract in response to previously detected unexpected resource usage, or terminate the smart contract, in order to avoid future unexpected usage. For example, when it is discovered that a user has overused a resource (once or repeatedly), it may be necessary to amend the terms of the smart contract to allocate different resources, add additional resources, change expected usage parameters, change the unit time cost of a particular resource, etc. In some examples, access to a resource may be limited or removed in response to unexpected resource usage. Similarly, when it is discovered that a user has underused a resource, the terms of the smart contract may be amended to allocate different resources (better suited to the user's needs), remove access to one or more resources, change expected usage parameters, change the unit time cost of a particular resource, etc.

[0117] However, since smart contracts are generally immutable, in order to amend the terms of a smart contract, a new smart contract may need to be generated to replace the original smart contract. This new smart contract may be generated by any of the methods described herein. The terms of the new smart contract may be modified manually by an operator or automatically using a rule-based algorithm or artificial intelligence engine. Any modifications to the terms of a smart contract may need to be approved by the user, and a copy of the new smart contract may be sent to the user for approval. In other examples, the terms of a smart contract may be modified before a new smart contract is generated without such approval. Once modified, the new smart contract may be stored on a distributed ledger. In some examples, the original smart contract may then be marked as "terminated" on the distributed ledger.

[0118] After any of steps S670, S680, S690, S695, the unexpected use of the resource may be deemed to have been adequately resolved, and the method may return to step S610 where the method is repeated. In some examples, the method may require confirmation that the user has paid for the settlement request, partial settlement request, and / or supplemental settlement request within a time frame defined in the resource supply agreement, wherein if confirmation is not received, the use of one or more resources may be limited or stopped.

[0119] Advantageously, the currently described method enables monitoring of resource usage and enables flexible and accurate billing of users of resources for their use of resources. The use of smart contracts enables dynamic allocation, adjustment, and removal of resources based on actual consumption of resources, thereby improving the overall utilization of available resources. The use of distributed ledgers to immutably record resource usage data enables users to have increased trust in the system, thereby enabling automated billing in many cases. In addition, the level of required human interaction is reduced because in many cases, available resources can be imported into an inventory management system, offered to users, and provisioned to users, and the use of resources can be tracked, recorded, and then billed, all without any human interaction. In addition, the inventory management system can also be flexible enough to adjust resource allocation and adapt to changing resource usage, while still without any human interaction.

[0120] Operation of Inventory Management System - Remittance from Supplier

[0121] Figure 7Another method of operating an inventory management system is shown, which can be used to monitor the use of resources provided by a third-party supplier and generate remittances for the use. At step S710, the use of one or more resources supplied by the supplier is monitored. Monitoring can include active monitoring performed by an inventory management controller and / or based on reports received from the supplier. The use of one or more resources is recorded periodically in conjunction with monitoring. As previously described, the method of monitoring and the frequency of recording use can be set by one or more rules present in a smart contract associated with one or more resources. For the following description, cloud computing services will be used as an example. For example, consider that a supplier wants to provide access to a data center capable of storing 100TB of data. A single smart contract can be associated with this data storage capability, and the single smart contract can include rules defining the following: the minimum data quota that a user can obtain (i.e., a user must request at least 100GB of space to avoid excessive subdivision of resources), how to monitor the use of data storage (i.e., regular reports from suppliers summarizing current storage use, or monitoring of network traffic by an inventory management controller or some entity), and weekly records of use (i.e., at the end of each week, the size of the stored data is recorded). This usage information can then be recorded in association with a smart contract associated with the supplier stored on a distributed ledger (in addition, the usage information can also be stored in conjunction with one or more smart contracts associated with the user of the resource). In this way, both the supplier and the operator of the inventory management system can access an immutable record of the use of the data center.

[0122] At step S720, one or more contract refresh criteria are reached, which triggers execution of the following steps. The contract refresh criteria may be, for example, reaching a billing date specified in the smart contract (i.e., when monthly billing is specified, when the date reaches the end of the calendar month). Alternatively, the contract refresh criteria may be related to recorded usage (i.e., once a predetermined storage capacity such as 1, 10, 20, or 50 TB has been used, a payment request is generated).

[0123] At step S730, the supplier's smart contract may be retrieved or otherwise analyzed to extract the parameters required to generate a settlement for the use of the supplied resources. These parameters may include, for example, a supplier identifier, an address identifier, an agreed fee rate for a particular resource, and the like. In addition, at step S730, usage data associated with the resources associated with the smart contract is retrieved to enable the recorded usage to be compared with the terms of the smart contract. In addition, when one or more users are charged again for partial or full use of the supplied resources, the smart contracts associated with these users and any accompanying usage data may also be retrieved from the distributed ledger. In other examples, a single multi-party smart contract may be associated with a resource, storing both user data and supplier data.

[0124] After retrieving the usage and smart contract data, at step S740, the data is compared to determine whether the recorded usage of the resource (as recorded in the distributed ledger) matches the expected usage of the resource (as specified in the retrieved smart contract). Based on the comparison at step S740, a decision is made at step S750. If the recorded usage of the particular resource matches the usage parameters defined in the smart contract (which may have been modified by one or more rules defining threshold deviations from the agreed usage parameters), the method proceeds to step S760.

[0125] At step S760, a remittance is generated, which may include a payment instruction, an invoice, or other financial instruments suitable for paying for the use of a resource or indicating that the use of a resource is paid. In some examples, the inventory management system can automatically complete the remittance, thereby paying the supplier for the resources used to supply. In other examples, the remittance may need to be manually or automatically cross-checked before paying the remittance. In other examples, the remittance can be completed until the user using the resource has completed the relevant settlement request. The remittance can be generated based on the parameters defined in the smart contract (which can, for example, define who should be paid, where the money should be sent, and how much money should be paid). Once the remittance is generated and completed, the method can directly return to the step S710 that the method repeats. Alternatively, the method can go to optional step S765.

[0126] At step S765, one or more settlement requests may be generated, suitable for collecting remittances from one or more users who use the provided resources. The settlement request may be generated according to any method described herein (e.g., according to Figure 5 After generating any settlement request, the method may return to step S710 where the method is repeated.

[0127] Returning to step S750, if the recorded usage does not match the usage parameters defined in the supplier's smart contract, the method can proceed in a different manner. In some examples, the usage may exceed the usage parameters defined in the smart contract. For example, the supplied resources may have been overused by a group of users (requiring the supplier to adjust the size of the supplied resources), and / or one or more users from a group of users may have used more than their agreed storage limit (which may also cause supplier resource balancing issues). In such cases, it is helpful to identify the overuse of resources to enable charging for overuse and / or to enable adjustment of the associated smart contract to better utilize the supplied resources and / or adjust the supplier's resource contribution.

[0128] In other examples, usage may be below agreed usage parameters. For example, if there is under-usage of supplied resources, a supplier who wishes to optimize the use of its data center may wish to reduce the amount of resources it supplies to the inventory management system. Alternatively, a supplier may find that understanding the under-usage of its supplied resources is useful for setting the cost of using its resources. In such cases, it is helpful to identify under-usage of resources because this enables persistently under-used resources to be reallocated to other users or have their capacity reduced, which enables finalization and disposal of smart contracts related to services that are no longer used, and which enables re-negotiation of the parameters of smart contracts to better reflect the demand for a given resource. In some examples, identifying under-usage of resources may also enable the supplier to be paid only by the operator of the inventory management system for the actual use of the resources, which may be beneficial compared to paying a fixed charge for the supply of the resources.

[0129] After identifying that the recorded usage does not match the usage parameters defined in the smart contract at step S750, the method can proceed to step S770 where a partial remittance can be generated and then completed as previously described. The partial remittance can be generated in the same manner as the remittance of step S760 (i.e., based on the parameters defined in the smart contract). However, the partial remittance can be limited to only covering the recorded usage (when the usage is less than the agreed usage parameters). In other examples, the upper limit of the partial remittance can be set at the agreed level in the smart contract (when the usage is higher than the agreed usage parameters).

[0130] At step S780, a discrepancy notification may be generated that alerts an operator and / or another element of the inventory management system and / or a supplier to the discrepancy between the recorded usage and the expected usage as defined in the smart contract. The discrepancy notification may include one (or more) smart contracts associated with the provision of the resource and any associated recorded usage. The discrepancy notification may be graphically represented in a user interface visible to an operator of the inventory management system, to one or more users, or to a supplier.

[0131] At optional step S790, a supplemental remittance may be generated to cover any additional resource usage not covered by the partial remittance. The supplemental remittance may be generated in response to input from an operator of the inventory management system. Alternatively, the supplemental remittance may be automatically generated based on an analysis of the difference notification. In some examples, further data such as previous resource usage data, payment history data, usage trend data, global resource usage data, etc. (each of which may be retrieved from a distributed ledger or otherwise derived) may be analyzed to determine whether to generate a supplemental remittance. In other examples, it may be determined by an operator or automatically that the supplemental remittance is not guaranteed.

[0132] At optional step S795, one or more of the smart contracts associated with the supplied resources may be amended in response to previously detected unexpected resource usage in order to avoid future unexpected usage. For example, when it is found that a user has overused resources (once or repeatedly), the user's smart contract may be amended to allocate different resources to them, change expected usage parameters, change the unit time cost of a particular resource, etc. Similarly, the supplier's smart contract may be adjusted to change the amount of resources supplied to the inventory management system, the cost per unit of the supplied resources, or any other parameter recorded in the smart contract. The smart contract may be manually modified by an operator or supplier, or may be automatically modified using a rule-based algorithm or artificial intelligence engine. Any amendments made to the smart contract may require approval from the user, supplier, and / or operator of the inventory management system, and a copy of any modified smart contract may be sent to each of them for approval. In other examples, the smart contract may be modified without the need for such approval. Once modified, the modified smart contract may be stored on a distributed ledger, or the original smart contract may be modified on a distributed ledger to reflect the modifications made.

[0133] After any of steps S770, S780, S790, S795, the unexpected use of resources may be deemed to have been adequately resolved and the method may return directly to step S710 where the method is repeated. Alternatively, as described above, one or more settlement requests may be generated at step S765 before returning to step S710.

[0134] Advantageously, the method currently described enables third-party suppliers to supply resources to users of the inventory management system. The resources supplied can be monitored so that payment can be made to the supplier, and the user of the resource can be billed flexibly and accurately for its use of the resource. The use of smart contracts enables the dynamic allocation, adjustment and removal of resources based on the actual consumption of the resources, thereby improving the overall utilization of the resources supplied. The use of distributed ledgers to immutably record resource usage data enables both suppliers and users to have increased trust in the system, thereby achieving automated billing in many cases. In addition, the level of required manual interaction is reduced because in many cases, available resources can be imported into the inventory management system, offered to users, and provided to users, and the use of resources can be tracked, recorded, and then billed, all without any manual interaction. In addition, the inventory management system can also be flexible enough to adjust resource allocation and adapt to changing resource usage, without any manual interaction.

[0135] Distributed ledger data analysis

[0136] It is recognized that distributed ledgers contain a wealth of useful data that can be used to provide insight into the use of resources managed by an inventory management system. Therefore, in some examples, the inventory management system may also be arranged to analyze data stored on the distributed ledger continuously, periodically, or in response to a request from a supplier, operator, or user of the system.

[0137] The data may be analyzed by any known statistical technique or model and analyzed on a resource-by-resource basis to generate resource usage statistics that provide insight into each resource. Any known forecasting model may be used to implement supply / demand forecasting. For a particular resource, the recorded usage of the resource may be analyzed to identify usage trends, usage gaps, usage outliers. Forecasting autoregressive integrated moving average (ARIMA) or Monte Carlo based models may be implemented to analyze the data to gain insight into resource usage and to enable prediction of future usage of the resource.

[0138] This analyzed data can be used to generate a graphical representation of the use of the resource over time. The graphical representation can be configured to highlight any deviations from the expected use of the resource. For example, highlighting under-use or over-use of the resource. In addition, based on the analysis of the recorded usage data, one or more warnings can be generated and sent to users, suppliers, or operators of the system to highlight unexpected use of the resource. In addition, the analyzed data can be used to determine whether the operator of the inventory management system needs to expand its network resources based on the following assessments: a) existing use, b) growth in use over time, c) interest of new users, and / or d) growth of users in a specific location or geographic area.

[0139] In some examples, the inventory management system can use an artificial intelligence engine or other rule-based algorithm to suggest actions to be implemented in response to the analysis of a particular resource. For example, if a resource has been underutilized, a more suitable alternative resource can be identified within the resource pool, and the system can suggest to the operator, supplier, or user to switch to the alternative resource to optimize the use of the available resources. This suggestion can be presented in a graphical user interface. In addition, a new or modified smart contract can be automatically generated and presented as part of the suggestion to switch resources. Similarly, if a resource is overutilized, or if a user has been violating one or more of the parameters of the smart contract, alternative resources and / or smart contract modifications can be identified and suggestions can be made to the user, operator, or supplier.

[0140] The data on the distributed ledger can also be collectively analyzed to generate resource usage data that provides insight into the resources managed by the inventory management system. For example, multiple resources, a specific kind of resource, or all resources whose usage data is recorded on the distributed ledger can be analyzed. Analyzing data for all resources or a group of resources can provide insight into the most popular types of resources, when and where different resources are consumed, whether any particular resource is underused or overused, etc.

[0141] In some examples, the inventory management system can use an artificial intelligence engine or other rule-based algorithm to suggest actions implemented in response to a collective analysis of the managed resources. For example, if a group or class of resources has been underutilized, a more suitable alternative resource can be identified within the resource pool, and the system can suggest to the operator, supplier, or user to switch to the alternative resource to optimize the use of the available resources. In addition, a new or modified smart contract can be automatically generated and presented as part of the suggestion to switch resources. Similarly, if a resource or a class of resources is overused, or if a user or a group of users has been violating one or more of the parameters of the smart contract, alternative resources and / or smart contract modifications can be identified and suggestions can be given to the user, operator, or supplier. In other examples, if certain resource types are thus popular, unpopular, oversubscribed, or undersubscribed, a suggestion to increase or decrease the availability of a class of resources can be generated and sent to the operator or supplier.

[0142] The analyzed data (both individually and collectively) and / or identified trends may be stored by the inventory management system for further use. This stored information may be fed into the method described herein for creating a new smart contract. This information may be used to help suggest the most appropriate resource from the resource pool to provision a specific request and to help dynamically manage the allocation of managed resources. For example, since it is known that underutilized resource types are highly available, their provisioning priority may be increased in response to future resource requests. Alternatively, if underutilized resources are considered to be less preferred by users, their provisioning priority may be reduced, thereby increasing user satisfaction with the resources they provide. In another example, the collective utilization of resources may affect the rules written in future smart contracts, giving great weight to highly used resources and reducing the cost of underutilized resources. In this way, resources available for provisioning may be better utilized over time.

[0143] Inter-network communication

[0144] In some cases, users and / or suppliers may be operating computing devices (or computing networks) that are not able to communicate directly with the inventory management system. In such examples, the inventory management system may employ one or more application programming interfaces (APIs) to translate incoming and outgoing network traffic to enable the inventory management system and the users / suppliers to communicate seamlessly.

[0145] To determine the appropriate functionality of such an API, the inventory management system may first analyze incoming network traffic to determine the data format of the incoming communication (such as a resource request or an offer to supply a resource). After determining the incoming data format, the inventory management system may then identify functionality suitable for converting the incoming data format into a data format used by the inventory management system. The API configured with the relevant functionality may be stored locally in the inventory management system's memory or retrieved from a third-party provider when necessary.

[0146] Once the appropriate API has been configured, the inventory management system may thereafter use the API to translate all incoming and outgoing network traffic so that both the inventory management system and the user / supplier may communicate seamlessly.

[0147] In other examples, users or suppliers may operate their own internal distributed ledgers. When such internal distributed ledgers are not based on a protocol that is compatible with the distributed ledger of the inventory management system, the inventory management system may identify (and implement) functions or drivers suitable for converting between the two protocol types. For example, the inventory management system may identify and implement an instruction toolkit that can convert between two distributed ledger protocol types, such as a plug-in DAML driver. Other interoperability solutions that help facilitate communication between two different distributed ledger protocols (two different networks) may be used. These interoperability solutions are typically implemented as an abstraction layer that implements communication between two different protocols. Examples of interoperability solutions suitable for use with the currently described examples include Chainlink (RTM), Harmony (RTM), and Cross-Chain Bridge (RTM).

[0148] In this way, all of the above advantages can be provided to users and / or supplier operating systems with different data formats, thereby reducing the barriers to using the inventory management system and expanding the pool of potential users and suppliers. In addition, different distributed ledger technologies can be made to communicate with the inventory management system, further reducing the barriers to using the system.

[0149] Example computing device

[0150] In one or more embodiments, the methods for managing inventory described herein can be implemented on a computing device. Figure 8An example of the internal components of a computing device 800 for use with the methods described herein is provided. The computing device 800 may include a storage device 802, which may include: one or more volatile memories, such as random access memory (RAM); and non-volatile memory, such as read-only memory (ROM) or a solid-state drive (SSD) (such as flash memory). The storage device 802 may include other storage devices, such as, for example, magnetic or optical storage devices, and may be in a format such as a compact disk (CD), a digital versatile disk (DVD), or other storage medium. The storage device 802 may be removable, such as an SD or USB type drive, or non-removable from the computing device 800.

[0151] Computing device 800 may include at least one processor 804 communicatively coupled to a storage device 802 . Figure 8 At least one processor 804 in the example may include a microprocessor, a general purpose processor, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA) or other programmable logic device, discrete hardware components, discrete gate or transistor logic, or any suitable combination thereof capable of performing the functions described herein. The processor may also be implemented as a combination of computing devices, such as, for example, multiple microprocessors, a combination of a DSP and a microprocessor, one or more microprocessors combined with a DSP core, or other such configurations.

[0152] Figure 8 The computing device 800 includes a network interface 806 that can be communicatively connected to a network 808 to receive data, such as data related to resource usage, provider resource availability, user resource usage data, and / or other data. The computing device 800 can accumulate data from the network 808 into a data set in the storage device 802.

[0153] exist Figure 8 In the example of , storage device 802 includes computer program instructions that are configured to implement a method for managing resources associated with an inventory management system according to any of the example methods described herein when processed by at least one processor 804. Computer program instructions and data may be stored in an accessible non-transitory computer-readable medium and loaded into a memory such as storage device 802.

[0154] Computing device 800 may also include interface 810 for user interface 812. Interface 810 and user interface 812 may combine to provide a user with the ability to interact with computing device 800 to input commands, data, and / or other information. Figure 8The components of the computing device 800 in the example of FIG. 8 are interconnected using a system bus 820 . This enables the transfer of data between the various components of the computing device 800 .

[0155] The above embodiments should be understood as illustrative examples of the present disclosure. Additional embodiments are contemplated. It should be understood that any feature described with respect to any one embodiment can be used alone or in combination with other features described, and can also be used in combination with one or more features of any other embodiment in the embodiment or any combination of any other embodiment in the embodiment. In addition, equivalents and modifications not described above may also be adopted without departing from the scope of the embodiments defined in the appended claims.

Claims

1. An inventory management system for managing resources, the system comprising at least one memory and at least one processor, the memory storing executable instructions, the executable instructions when executed by the at least one processor causing the at least one processor to: receiving a resource request from a user; identifying one or more resources from a resource pool that can satisfy the resource request; generating a smart contract including a resource service agreement for the identified one or more resources; storing data associated with the smart contract on a distributed ledger; arranging for the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record use of the identified one or more resources; and A settlement request is generated based on updated data associated with the smart contract stored in the distributed ledger.

2. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: generating one or more rules that define one or more of resource usage thresholds, resource usage limits, payment terms, and dispute resolution mechanisms; and The one or more rules are stored in association with the smart contract on the distributed ledger.

3. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: Based on the received resource request, identifying a smart contract stored on the distributed ledger that is associated with a similar resource request; extracting one or more parameters from the identified smart contract; and The smart contract is generated using the extracted one or more parameters.

4. The inventory management system according to claim 3, wherein: The step of identifying smart contracts stored on the distributed ledger associated with similar resource requests is performed by an artificial intelligence engine configured to analyze one or more parameters of the resource request and identify the one or more smart contracts stored on the distributed ledger based on similarity of the one or more smart contracts to the analyzed parameters.

5. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: receiving an agreement document from the user; applying an optical character recognition process to the protocol document to extract one or more parameters; and The smart contract is generated using the extracted one or more parameters.

6. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: Configuring or implementing an application programming interface API, wherein the API is arranged to: receiving an agreement document from the user; processing the protocol document to extract one or more parameters; and The smart contract is generated using the extracted one or more parameters.

7. The inventory management system according to claim 1, wherein: The smart contract includes contract refresh criteria that, when satisfied, cause the inventory management system to update the data associated with the smart contract and store the updated data in the distributed ledger to record use of the identified one or more resources.

8. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: comparing the generated smart contract to a desired set of parameters for the smart contract; determining that the generated smart contract is missing one or more parameters from the required parameter set; and A notification is generated requesting a manual amendment to the smart contract.

9. The inventory management system according to claim 1, further comprising: The artificial intelligence engine is configured to generate the smart contract based on the received resource request.

10. The inventory management system according to claim 1, further comprising: a distributed ledger manager configured to communicate with a plurality of processing nodes, wherein each processing node maintains a copy of the distributed ledger and updates the distributed ledger in conjunction with other processing nodes of the plurality of processing nodes, Wherein, the distributed ledger manager is further configured to: Generate configuration settings for new processing nodes; The generated configuration settings and a copy of the current distributed ledger are sent to one of the processing nodes for configuring the processing node as a remote distributed ledger processing node.

11. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: receiving a distributed ledger viewing request from a user, the distributed ledger viewing request comprising a user identifier and one or more security credentials; verifying the one or more security credentials; identifying one or more smart contracts stored on the distributed ledger that are associated with the user identifier; and Arranging viewing access for the user to the identified one or more smart contracts.

12. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: analyzing the data associated with the smart contract to identify trends in the usage of the one or more resources associated with the smart contract; determining a difference between the usage of the one or more resources associated with the smart contract and the resource service agreement; and Generates a discrepancy notification.

13. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: analyzing the data associated with a plurality of smart contracts stored in the distributed ledger to generate resource usage statistics; generating one or more graphical representations of the resource usage statistics; and The generated graphical representation is transmitted to a user interface so that the generated graphical representation can be presented to a user.

14. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: analyzing the data associated with a plurality of smart contracts stored in the distributed ledger to generate resource usage data; The resource usage data is stored for use in generating additional smart contracts.

15. The inventory management system according to claim 1, wherein: Each resource in the resource pool is associated with one or more tokens, each of which is stored in a centralized wallet. Each time a resource is allocated to a user, the token associated with the resource is moved from the centralized wallet to the user wallet, or the token associated with the resource is removed from the centralized wallet and recreated in the user wallet, and In particular, when all tokens associated with a particular resource have been moved or removed from the centralized wallet, the particular resource can no longer be used to satisfy future resource requests.

16. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: identifying whether the user has an associated user wallet, wherein, if the user has an associated wallet, the inventory management system is arranged to move tokens associated with the identified one or more resources from a wallet associated with the resource pool to the user wallet, or to create tokens associated with the identified one or more resources in the user wallet, while provisioning the identified one or more resources to the user, Wherein, if there is no user wallet associated with the user, the executable instructions, when executed by the at least one processor, cause the at least one processor to: creating a user wallet for storing tokens associated with resources available to the user; and Moving tokens associated with the identified one or more resources from a wallet associated with the resource pool to the created user wallet, or creating tokens associated with the identified one or more resources in the created user wallet.

17. The inventory management system according to claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: receiving an offer from a supplier for supplying one or more resources; generating a second said smart contract, said second said smart contract comprising a resource provisioning agreement for provisioning one or more of the offered resources; and Representations of the one or more resources covered by the resource provisioning protocol are added to the resource pool, indicating that the resources are available to satisfy resource requests.

18. The inventory management system according to claim 17, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: monitoring usage of the resource associated with the second smart contract over time, Wherein, when the contract refresh criteria specified in the second smart contract is reached, the executable instructions, when executed by the at least one processor, cause the at least one processor to: updating the data associated with the second smart contract stored in the distributed ledger to record the use of the resource associated with the second smart contract; generating a remittance for use of the resource associated with the second smart contract in accordance with the resource supply agreement; and Refresh the second smart contract to record the generated remittance.

19. The inventory management system according to claim 18, wherein: When the contract refresh criteria specified in the second smart contract is met, the executable instructions, when executed by the at least one processor, cause the at least one processor to: comparing recorded usage of the resource associated with the second smart contract with the resource supply agreement, wherein if the recorded usage does not match the resource supply agreement, the inventory management system is arranged to: limiting said generated remittance to cover only said recorded use; generating a dispute notification for the resource supply agreement including the updated data and the second smart contract; and The dispute notification is sent to a dispute management system.

20. The inventory management system of claim 18, wherein: When the contract refresh criteria specified in the second smart contract is met, the executable instructions, when executed by the at least one processor, cause the at least one processor to: comparing recorded usage of the resource associated with the second smart contract with the resource supply agreement, wherein if the recorded usage does not match the resource supply agreement, the inventory management system is arranged to: determining whether the second smart contract includes one or more rules defining a resource usage threshold; and The remittance is generated only if the recorded usage differs from the updated data of the second smart contract by less than the resource usage threshold.

21. The inventory management system of claim 1, wherein: The executable instructions, when executed by the at least one processor, cause the at least one processor to: determining a data format of a received resource request; identifying an application programming interface for converting the data format of the received resource request into a data format used by the inventory management system; and The received resource request is converted into the data format used by the inventory management system using the identified application programming interface.

22. A computer-implemented method comprising: receiving a resource request from a user; identifying one or more resources from a resource pool that can satisfy the resource request; generating a smart contract including a resource service agreement for the identified one or more resources; storing data associated with the smart contract on a distributed ledger; arranging for the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record use of the identified one or more resources; as well as A settlement request is generated based on updated data associated with the smart contract stored in the distributed ledger.

23. A non-transitory computer readable medium storing instructions that, when executed by one or more processors, perform a method for managing resources, the method comprising: receiving a resource request from a user; identifying one or more resources from a resource pool that can satisfy the resource request; generating a smart contract including a resource service agreement for the identified one or more resources; storing data associated with the smart contract on a distributed ledger; arranging for the identified one or more resources to be provisioned to the user; updating the data associated with the smart contract stored in the distributed ledger to record use of the identified one or more resources; as well as A settlement request is generated based on updated data associated with the smart contract stored in the distributed ledger.

Images