An electronic wallet that allows for the expiration of cryptocurrencies

Abstract

A computer-implemented system and method uses a processor in a device of an expiring virtual currency (EVC) wallet user to retrieve an EVC transaction associated with a blockchain and addressed to an address associated with the EVC wallet. The EVC transaction includes an expiration date for the EVC as part of the virtual currency user rules (VCUR). When the EVC expiration date has passed, the method automatically transfers the EVC to a transferee specified in the VCUR without user intervention.

Description

[Background technology]

[0001] Disclosed herein is a system and associated method for utilizing an electronic wallet that allows virtual currency to have an expiration date. Virtual currency (crypto assets) using blockchain technology has gained well-recognized use as a medium of exchange in industry and the global economy. Bitcoin is one such virtual currency that has operated very reliably for over a decade. Bitcoin's reliability is such that even some companies have adopted a system of paying part of their salary in virtual currency due to Bitcoin's high recognition rate and excellent convenience. Virtual currency users using wallet applications may use virtual currency to perform transactions including payments, money transfers, money receipts, balance management, etc.

[0002] However, currently, no mechanisms exist to regulate or control the use of virtual currencies. After a virtual currency transaction has occurred, the recipient of the virtual currency may use the virtual currency in any manner the recipient chooses. This may be advantageous in some situations, but disadvantageous in other situations, such as when the currency is intended to be used in a specific manner, such as a gift card with an intended use at a specific merchant. By not allowing control over the use of virtual currencies, the functional value of virtual currencies may be reduced compared to real currency. Summary of the Invention

[0003] It may be desirable for there to be a special virtual currency with an expiration date to encourage usage within a certain time period. Furthermore, it may be desirable for there to be a predefined set of recipients who have a special virtual currency wallet to hold the special virtual currency, to whom transfers / transactions may be made prior to the expiration. Upon expiration, transfers may be made to the transferee in an automatic manner and without the restrictions that the virtual currency had prior to the expiration.

[0004] According to one aspect disclosed herein, a computer-implemented method is provided that includes using a processor of an expiring virtual currency (EVC) wallet user's device and retrieving an EVC transaction associated with a blockchain and addressed to an address associated with the EVC wallet. The EVC transaction includes an expiration date for the EVC, and the EVC is subject to virtual currency user rules (VCURs) of which the expiration date is a part. The method further determines whether the expiration date of the EVC in the EVC transaction has passed based on a first condition that the expiration date has passed. After the expiration date has passed, the method automatically transfers the EVC to a transferee specified in the VCUR without user intervention. Providing a method of using an EVC that is subject to a VCUR is advantageous in that it increases flexibility in using virtual currency and can encourage the EVC to be used in a manner intended by the EVC issuer.

[0005] According to another aspect disclosed herein, an expiring virtual currency (EVC) device includes a memory and a processor. The processor is configured to retrieve an EVC transaction associated with a blockchain and addressed to an address associated with an EVC wallet. The EVC transaction includes an expiration date for the EVC, and the EVC is subject to Virtual Currency User Rules (VCUR) of which the expiration date is included. The processor is further configured to determine whether an expiration date for the EVC in the EVC transaction has passed based on a first condition that the expiration date has passed, and to automatically transfer the EVC to a transferee specified in the VCUR without user intervention. Providing a device for using an EVC that is subject to a VCUR is advantageous in that it provides a platform for utilizing the EVC that is separate from users who use standard virtual currencies, while at the same time allowing the EVC to be converted to standard virtual currencies under pre-specified conditions.

[0006] According to another aspect disclosed herein, a computer-implemented method for issuing a time-limited virtual currency (EVC) by an issuer using a processor to create an account list including a plurality of account records, each account record including an indicator as to whether an EVC recipient associated with an EVC recipient identifier is included or not included in a predefined set of EVC recipients. The account records correspond to a plurality of EVC recipients. The method further includes creating an EVC recipient destination list including a plurality of destination records, each destination record including an EVC recipient identifier, a public key, a virtual currency address, and an indicator as to whether the EVC recipient is included or not included in a predefined set of EVC recipients. The method further includes setting an EVC recipient address and a security key for each of a plurality of EVC wallets used to hold the EVC of the EVC recipient, and distributing each of the aforementioned EVC wallets to each of the aforementioned EVC recipients. Providing a method for issuing EVCs that are subject to VCUR is advantageous in that it allows an EVC issuer to encourage the use of EVCs in a manner desired by the EVC issuer.

[0007] According to another aspect, a time-limited virtual currency (EVC) system includes an EVC issuer device as described herein. A computer program product for a time-limited virtual currency system includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions including program instructions for implementing the aforementioned method.

[0008] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer usable or computer readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer usable or computer readable medium may be any apparatus that can include a mechanism for storing, communicating, propagating, or carrying a program for use by or in connection with an instruction execution system, instruction execution apparatus, or instruction execution device.

[0009] Various embodiments are described herein with reference to different subject matter. In particular, some embodiments may be described with reference to methods, while other embodiments may be described with reference to devices and systems. However, a person skilled in the art will infer from the above and following descriptions that, unless otherwise noted, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, in particular between method features and device and system features, is considered to be disclosed within this document.

[0010] The above defined aspects and other aspects disclosed herein will become apparent from and will be explained with reference to one or more example embodiments described hereinafter, without however limiting the invention.Various embodiments are illustrated, by way of example only, with reference to the following drawings, in which: [Brief description of the drawings]

[0011] [Figure 1A] FIG. 1 is a block diagram of a data processing system (DPS) in accordance with one or more embodiments disclosed herein. [Figure 1B] FIG. 1 illustrates a cloud computing environment in accordance with embodiments disclosed herein. [Figure 1C]FIG. 2 illustrates an abstract model layer according to embodiments disclosed herein. [Figure 1D] FIG. 2 is a block diagram illustrating a network diagram of a system including a database according to an example embodiment. [Figure 2A] FIG. 1 is a block diagram illustrating an exemplary blockchain architecture configuration, according to an example embodiment. [Figure 2B] FIG. 1 is a flow diagram illustrating a blockchain transaction flow, according to an example embodiment. [Figure 3A] FIG. 1 is a block diagram illustrating a permissioned network, according to an example embodiment. [Figure 3B] FIG. 2 is a block diagram illustrating another permissioned network, according to an example embodiment. [Figure 3C] 1 is a block diagram illustrating a permission-free network, according to an example embodiment. [Figure 4] A block diagram showing a basic blockchain sequence. [Figure 5A] 1 is a block diagram illustrating an example system configured to perform one or more operations described herein, in accordance with an example embodiment. [Figure 5B] 1 is a block diagram illustrating another example system configured to perform one or more operations described herein, in accordance with an example embodiment. [Figure 5C] FIG. 1 is a block diagram illustrating a further exemplary system configured to utilize smart contracts, in accordance with an example embodiment. [Figure 5D] FIG. 1 is a block diagram illustrating yet another exemplary system configured to utilize blockchain, in accordance with an example embodiment. [Figure 6A] FIG. 1 is a block diagram illustrating the process of a new block being added to a distributed ledger according to an example embodiment. [Figure 6B] FIG. 11 is a block diagram illustrating the contents of a new data block, according to an example embodiment. [Figure 6C]FIG. 1 is a block diagram illustrating a blockchain for digital content, according to an example embodiment. [Figure 6D] FIG. 2 is a block diagram illustrating a block that may represent the structure of a block in a blockchain according to an example embodiment. [Figure 7A] FIG. 1 is a block diagram illustrating an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 7B] FIG. 1 is a block diagram illustrating an exemplary quantum secure blockchain, in accordance with an example embodiment. [Figure 8] FIG. 1 is a block diagram illustrating a high-level block diagram of an exemplary computer system that may be used in implementing one or more of the methods, tools, and modules, and any associated functionality, described herein in accordance with embodiments of the present disclosure. [Figure 9] FIG. 1 is a block diagram illustrating a distributed ledger (blockchain) according to some implementations. [Figure 10] 1 is a block diagram illustrating a transfer of two assignors to an assignee according to some implementations. [Figure 11A] 1 is a block diagram illustrating the use of a predefined set of EVC recipients to which an EVC can be forwarded according to some implementations. [Figure 11B] 11B is a block diagram similar to FIG. 11A but further illustrating potential assignees to which unused EVCs may be automatically forwarded, according to some implementations. [Figure 12] 1 is a flowchart illustrating a process for implementing some embodiments of a system used by an entity / issuer in creating and distributing EVCs. [Figure 13A] 1 includes a flowchart of a process that may be utilized by an EVC recipient via an EVC wallet application on the EVC recipient's device according to some implementations. [Figure 13B]1 includes a flowchart of a process that may be utilized by an EVC recipient via an EVC wallet application on the EVC recipient's device according to some implementations. [Figure 14] 1 is a flow chart illustrating a process for automatic payment to a transferee according to some embodiments. [Figure 15A] FIG. 1 is a portion of a combined block and process diagram illustrating components and the interaction of these components to operate the system in accordance with some embodiments. [Figure 15B] FIG. 1 is a portion of a combined block and process diagram illustrating components and their interactions to operate the system in accordance with some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Overview of electronic wallets that allow expiry of cryptocurrencies This disclosure contemplates the use of electronic wallets that use blockchain technology to enable virtual currencies, such as virtual currencies that are subject to certain virtual currency usage rules (VCURs) associated with virtual currencies. As defined herein, the term "virtual currency" may also include digital currencies. One such VCUR may include an expiration date. Thus, the term "expired virtual currency" (EVC) is used herein for convenience to describe virtual currencies that are subject to VCURs (which do not necessarily include an expiration date) and to distinguish EVCs from "standard" virtual currencies. Also, as indicated below, the term "virtual currency" as used herein is a substitute for any type of blockchain-based virtual currency, unless referenced with the adjective "standard" before "virtual currency."

[0013] Another such VCUR is a list of recipients who have EVC wallets that can receive the EVC and to which the EVC transfer can be made. If the VCUR indicates the expiration of the EVC, such as an expiration date, the VCUR may indicate an automatic transfer of the EVC to the transferee. This transfer may convert the EVC into standard virtual currency, i.e., virtual currency that can be held in a regular virtual currency wallet without a VCUR. EVC wallets may hold various types of electronic / digital / virtual currency.

[0014] In what follows, the following abbreviations may be used:

[0015] [Table 1]

[0016] General Data Processing System 1A is a block diagram of an exemplary DPS according to one or more embodiments. In this example, the DPS 10 may include a communication bus 12 that may provide communication between a processor unit 14, a memory 16, a persistent storage 18, a communication unit 20, an I / O unit 22, and a display 24.

[0017] Processor unit 14 serves to execute instructions of software that may be loaded into memory 16. Processor unit 14 may be multiple processors, a multi-core processor, or other types of processors, depending on the particular implementation. "Multiple," when used herein with reference to an item, means one or more items. Additionally, processor unit 14 may be implemented using multiple heterogeneous processor systems in which a main processor resides on a single chip along with secondary processors. As another example, processor unit 14 may be a symmetric multiprocessor system that includes multiple processors of the same type.

[0018] Memory 16 and persistent storage 18 are examples of storage devices 26. A storage device may be any piece of hardware that can store information, such as, but not limited to, data, program code in a functional form, or other suitable information, or any combination thereof, on a temporary or persistent basis. In these examples, memory 16 may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 18 may take various forms, depending on the particular implementation.

[0019] For example, persistent storage 18 may include one or more components or devices. For example, persistent storage 18 may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or a combination thereof. The media used by persistent storage 18 may be removable. For example, a removable hard drive may be used for persistent storage 18.

[0020] In these examples, the communication unit 20 may provide communication with other DPSs or devices. In these examples, the communication unit 20 is a network interface card. The communication unit 20 may provide communication using either a physical communication link or a wireless communication link, or both.

[0021] Input / output unit 22 may allow for the input and output of data with other devices that may be connected to DPS 10. For example, input / output unit 22 may provide a connection for user input via a keyboard, mouse, or other suitable input device, or combination thereof. In addition, input / output unit 22 may send output to a printer. Display 24 may provide a mechanism for displaying information to a user.

[0022] Instructions for the operating system, applications, and / or programs may be located in storage device 26, which communicates with processor unit 14 via communication bus 12. In these examples, the instructions reside in functional form on persistent storage 18. These instructions may be loaded into memory 16 for execution by processor unit 14. The processes of the various embodiments may be executed by processor unit 14 using computer-implemented instructions, which may be located in a memory, such as memory 16. These instructions are referred to as program code 38 (described below), computer usable program code, or computer readable program code, which may be read and executed by a processor in processor unit 14. The program code in the various embodiments may be embodied on different physical or tangible computer readable media, such as memory 16 or persistent storage 18.

[0023] DPS 10 may further include an interface for network 29. This interface may include hardware, drivers, software, etc. to enable communication over wired and wireless networks 29 and may implement any number of communication protocols including, for example, communication protocols at various levels of the Open Systems Interconnection (OSI) seven-layer model.

[0024] FIG. 1A further illustrates computer program product 30, which may include program code 38. Program code 38 may be disposed in a functional form on a selectively removable computer readable medium 32 and may be loaded or transferred to DPS 10 for execution by processor unit 14. In these examples, program code 38 and computer readable medium 32 may form computer program product 30. In one example, computer readable medium 32 may be computer readable storage medium 34 or computer readable signal medium 36. Computer readable storage medium 34 may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of persistent storage 18 for transfer to a storage device, such as a hard drive that is part of persistent storage 18. Computer readable storage medium 34 may take the form of persistent storage, such as a hard drive, thumb drive, or flash memory connected to DPS 10. In some cases, computer readable storage medium 34 may not be removable from DPS 10.

[0025] Alternatively, program code 38 may be transferred to DPS 10 using computer readable signal medium 36. Computer readable signal medium 36 may be, for example, a propagated data signal containing program code 38. For example, computer readable signal medium 36 may be an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, fiber optic cable, coaxial cable, a wire, or any other suitable type of communications link, or a combination thereof. In other words, in these examples, the communications links and / or connections may be physical or wireless.

[0026] In some example embodiments, program code 38 may be downloaded from another device or DPS via computer readable signal medium 36 over a network to persistent storage 18 for use within DPS 10. For example, program code stored on a computer readable storage medium in a server DPS may be downloaded from the server over a network to DPS 10. The DPS providing program code 38 may be a server computer, a client computer, or other device capable of storing and transmitting program code 38.

[0027] The different components illustrated in DPS 10 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. Different example embodiments may be implemented in a DPS that include components in addition to or in place of the components illustrated in DPS 10.

[0028] General Cloud Computing Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the subject matter presented herein is not limited to a cloud computing environment. Embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0029] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computational resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) and for rapidly provisioning and releasing these resources with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0030] The features are as follows: On-Demand Self-Service: Cloud customers can automatically provision server time, network storage, and other computing power as they need it, without any unilateral, human interaction with the service provider. Broad network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating usage by heterogeneous thin- or thick-client platforms (e.g., mobile phones, laptops, and PDAs). Resource Pool: The provider's computing resources are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence, consumers usually have no control or knowledge regarding the exact location of the resources offered, although at a higher level of abstraction they may be able to specify a location (e.g. country, state, or data center). Rapid Elasticity: Cloud capacity can be provisioned quickly and elastically, in some cases automatically, to scale out quickly, and quickly released to scale in quickly. Capacity available for provisioning often appears to consumers as unlimited, available for purchase in any amount at any time. Metered Services: Cloud systems leverage metering to automatically control and optimize resource usage at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

[0031] The service model is as follows: SaaS (Software as a Service): The capability provided to the consumer is the use of the provider's applications running on a cloud infrastructure. Those applications can be accessed from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for the possibility of limited user-specific application configuration settings. PaaS (Platform as a Service): The capability provided to a consumer is to deploy applications that the consumer creates or acquires, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capability provided to a consumer is the provisioning of processing, storage, network, and other basic computing resources over which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases has limited control over selected network components (e.g., host firewalls).

[0032] The deployment model is as follows: Private Cloud: This cloud infrastructure is operated solely for one organization. It can be managed by this organization or a third party and can exist on-premise or off-premise. Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by these organizations or a third party and can reside on-premise or off-premise. Public Cloud: This cloud infrastructure is available for use by general users or large industry organizations and is owned by an organization that sells cloud services. Hybrid cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique but are bound together by standardized or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting to balance the load between clouds).

[0033] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that contains a network of interconnected nodes.

[0034] 1B, an exemplary cloud computing environment 52 is shown. As shown, the cloud computing environment 52 includes one or more cloud computing nodes 50 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N) can communicate. The nodes 50 may communicate with each other. The nodes 50 may be physically or virtually grouped in one or more networks (not shown), such as in a private cloud, community cloud, public cloud, or hybrid cloud, or combination thereof, as previously described herein. This allows the cloud computing environment 52 to provide an infrastructure, platform, and / or SaaS that does not require the cloud consumer to maintain resources on a local computing device. The types of computing devices 54A-N illustrated in FIG. 1B are intended as examples only, and it will be understood that computing node 50 and cloud computing environment 52 may communicate with any type of computer-controlled device via any type of network and / or network-addressable connection (e.g., a connection using a web browser).

[0035] Referring now to Figure 1C, a set of functional abstraction layers provided by cloud computing environment 52 (Figure 1B) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 1C are intended to be illustrative only and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0036] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, Reduced Instruction Set Computer (RISC) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0037] The virtualization layer 70 provides an abstraction layer that can provide virtual entities such as virtual servers 71 , virtual storage 72 , virtual networks including virtual private networks 73 , virtual applications and operating systems 74 , and virtual clients 75 .

[0038] As an example, the management layer 80 may provide the functions described below: Resource provisioning 81 provides dynamic procurement of computational and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking and billing or invoicing for the utilization of resources within the cloud computing environment. As an example, the resources may include application software licenses. Security provides identity verification of cloud users and tasks, as well as protection of data and other resources. User portal 83 provides access to the cloud computing environment to users and system administrators. Service level management 84 provides allocation and management of cloud computational resources to meet required service levels. Service level agreement (SLA) planning and execution 85 provides pre-provisioning and procurement of cloud computational resources in anticipation of upcoming demands in accordance with SLAs.

[0039] The Workload Layer 90 illustrates examples of functionality available in a cloud computing environment. Examples of workloads and functionality that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and time-bound virtual currency processing 96.

[0040] In addition to the computing devices 54A-N, any of the nodes 50 in the computing environment 52 may also be a DPS 10.

[0041] Basic details of blockchain As generally described and illustrated in the figures herein, the components herein can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as illustrated in the accompanying figures, is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

[0042] Features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrase "example embodiment," "some embodiments," or other similar language throughout this specification refers to the fact that certain features, structures, or characteristics described in connection with an embodiment may be included in at least one embodiment. Thus, the appearances of the phrase "example embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Additionally, in each figure, any connection between elements may permit one-way or two-way communication, or both, even if the connection shown is a one-way or two-way arrow. Also, any devices shown in the figures may be different devices. For example, where a mobile device is shown transmitting information, a wired device may also be used to transmit the information.

[0043] In addition, although the term "message" may be used in describing the embodiments, the application may apply to many types of networks and data. Further, although particular types of connections, messages, and signaling may be shown in the example embodiments, the application is not limited to the particular types of connections, messages, and signaling.

[0044] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide implementation of expiration mechanisms or other cryptocurrency usage rules for cryptocurrencies within a blockchain network.

[0045] In one embodiment, an application utilizes a distributed database (such as a blockchain), which is a distributed storage system that includes multiple nodes that communicate with each other. A distributed database includes an append-only immutable data structure, similar to a distributed ledger, in which records can be maintained among mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching consensus among the distributed peers. For example, peers may run a consensus protocol to verify the validity of blockchain stored transactions, group those stored transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering the stored transactions, as necessary, for consistency. In various embodiments, permissioned or permissionless blockchains or both may be used. Public or permissionless blockchains allow anyone to participate without specific identification. Public blockchains include native cryptocurrencies and can use consensus based on various protocols, such as Proof of Work (PoW). Permissioned blockchain databases, on the other hand, provide for secure interaction within a group of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, or information.

[0046] The application can utilize the blockchain to operate arbitrary programmable logic, called “smart contracts” or “chaincodes”, that are aligned with the distributed storage method. In some cases, there may be specialized chaincodes for managing functions and parameters, called system chaincodes. The application can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof properties of the blockchain database and the underlying agreement between nodes, called endorsement or endorsement policy. Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain, while transactions that are not endorsed are ignored. The endorsement policy allows the chaincode to specify endorsers for the transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, a transaction is executed to validate the transaction. After validation, the transaction moves to the ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0047] This application can utilize nodes, which are the communicating entities of the blockchain system. A "node" may perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes may include different types, such as client or submit client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers can also have the role of endorser, but this is not a requirement. An ordering service node or ordering node is a node that performs communication services for all nodes and enforces delivery guarantees, such as broadcasting to each of the peer nodes in the system when committing transactions and when modifying the blockchain world state (another name for the initial blockchain transaction, which usually contains control and configuration information).

[0048] The application may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (e.g., peer node) may maintain a copy of the ledger. A transaction may result in a set of key-value pairs of assets being committed to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a blockchain (also called a chain) that is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0049] The application may utilize a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is greater than or equal to 1. The block header contains a hash of the block’s transactions, and a hash of the previous block’s header. In this way, all transactions in the ledger may be ordered and cryptographically linked to each other. Thus, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added block of the blockchain represents all transactions on the chain that occurred before it, allowing all peer nodes to be assured that they are in a consistent and trustworthy state. The chain may be stored in the file systems of the peer nodes (i.e., locally, attached storage, cloud, etc.), which efficiently supports the append-only nature of blockchain workloads.

[0050] The immutable ledger's current state represents the latest values ​​of all keys contained in the chain's transaction log. The current state is sometimes called the world state, as it represents the most recent key values ​​known to the channel. Chaincode invocations execute transactions against data in the ledger's current state. To make those chaincode interactions efficient, the most recent key values ​​may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log, and thus may be regenerated from the chain at any time. The state database may be automatically restored (or generated if necessary) at peer node startup, before any transactions are received.

[0051] Some of the advantages of the solutions described and illustrated herein include methods and systems for using time-limited virtual currencies or virtual currencies in a blockchain network that are subject to virtual currency usage rules within the blockchain network. Example embodiments solve the time and trust issues by extending database features such as immutability, digital signatures, and the existence of a single source of truth. Example embodiments provide a solution for document sharing in a blockchain-based network based on confidential attributes within the blockchain network. A blockchain network can be homogenous based on asset types and rules governing assets based on smart contracts.

[0052] Blockchain differs from traditional databases in that blockchain is not a central storage device, but a decentralized, immutable, and secure storage, and each node must share changes to the records in the storage. Some of the characteristics that are unique to blockchain and that are useful for implementing blockchain include, but are not limited to, immutable ledger, smart contracts, security, confidentiality, decentralization, consensus, endorsement, accessibility, and the like, which are further described herein. According to various aspects, a system for document sharing based on confidential attributes in a blockchain network is implemented due to the inherent immutable accountability, security, confidentiality, permissioned decentralization, smart contract availability, endorsement, and accessibility that are unique to blockchain. In particular, the data in the blockchain ledger is immutable and provides an efficient way for time-limited cryptocurrency or cryptocurrency that is subject to cryptocurrency usage rules in the blockchain network. Alternatively, the use of cryptography in blockchain provides security and builds trust. Smart contracts manage the state of the assets and complete their lifecycle. An exemplary blockchain is decentralized and permissioned. Thus, each end user may have their own copy of the ledger to access. Multiple organizations (and peers) may be incorporated into the blockchain network. A central organization may act as an endorsing peer to verify the validity of smart contract execution results, read sets, and write sets. In other words, the unique features of blockchain provide an efficient implementation of methods for time-bound cryptocurrencies or cryptocurrencies that are subject to cryptocurrency usage rules within the blockchain network.

[0053] One advantage of the example embodiment is to improve the functionality of a computing system by implementing a method for time-limited cryptocurrency or cryptocurrency subject to cryptocurrency usage rules in a blockchain-based system. The computing system can perform functions for document sharing based on confidential attributes in a blockchain network by providing access to capabilities such as distributed ledgers, peers, cryptography, MSP, event processing, etc. through the blockchain system described herein. Blockchain also allows for business networks to be created and incorporated to join any user or organization. Therefore, blockchain is not just a database. Blockchain has the ability to create a business network of users and incorporated / unincorporated organizations to cooperate and execute service processes in the form of smart contracts.

[0054] Example embodiments provide numerous advantages over traditional databases, for example, blockchain provides the inherent immutable accountability, security, confidentiality, permissioned decentralization, smart contract enablement, endorsement, and accessibility that are unique to blockchain.

[0055] On the other hand, example embodiments cannot be implemented using traditional databases because traditional databases do not engage all parties in a business network, do not create trusted cooperation, and do not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage and do not provide protection for stored digital assets. Thus, the proposed methods for time-limited virtual currencies or virtual currencies that are subject to virtual currency usage rules in a blockchain network cannot be implemented with traditional databases.

[0056] On the other hand, if a traditional database were used to implement the example embodiments, the example embodiments would suffer from unnecessary drawbacks such as lack of searchability, security, and slower transaction speeds. Furthermore, an automated method for sharing time-bound cryptocurrency implementations within a blockchain network would simply not be possible.

[0057] Thus, example embodiments provide a specific solution to a problem in the technology / area of ​​virtual currencies that is subject to usage rules.

[0058] Example embodiments also modify how data may be stored within the block structure of a blockchain. For example, digital asset data may be securely stored within a specific portion of a data block (i.e., within a header, data segment, or metadata). By storing digital asset data within a data block of a blockchain, the digital asset data may be added to an immutable blockchain ledger via a hash-linked chain of blocks. In some embodiments, a data block may differ from a traditional data block in that personal data associated with a digital asset is not stored with the asset within a traditional block structure of a blockchain. By removing personal data associated with a digital asset, a blockchain may provide the benefits of anonymity based on immutable accountability and security.

[0059] According to example embodiments, a system and method is provided for a time-bound cryptocurrency or a cryptocurrency that is subject to cryptocurrency usage rules within a blockchain network. A blockchain document processor may include two components: - Private off-chain processors that manage the secure processing of personal information relating to participants; and - A ledger processor that manages the processing of common information shared with all participants in a blockchain network using the network's consensus algorithm.

[0060] According to an example embodiment, each organization that wishes to share a document with another organization uses a blockchain document processor connected to the blockchain network. The organization may use the document processor to set the following items on the ledger: - list of document templates, - Attributes of each document template shared in hashed form in the ledger; - Combining key attributes from different templates to collate and share documents; and - partnership Merkel trees. Each partnership Merkel tree may be built based on the identifiers of the partnering organizations.

[0061] All documents (files, JSON) are stored in an off-chain data store. Only a hash of attributes and the document identifier (ID) are submitted as part of a blockchain transaction.

[0062] According to one example embodiment, the document identifier and document type may be linked to a hashed attribute for sharing. The hashed owner's org id may contain a composite key such that: - Given a document ID, a document processor can retrieve all hashed attributes for sharing; and - Given the hashed attributes for sharing, the document processor can get all document ids and their hashed owner organization ids.

[0063] Given the hashed attributes for sharing when a document is recorded, the document processor may retrieve all documents and their hashed owner organization IDs. The processor may check whether the owner organization IDs of the incoming documents and each owner organization ID are part of the partnership Merkle tree. If they belong to the partnership Merkle tree of the subset of documents in the eligible organizational relationship, the processor may retrieve the template required for logical matching. Based on evaluating the match of the hashed attributes, the processor may retrieve a list of documents (and their owners) to which the incoming document needs to be linked. The processor may then create the linked document. The processor may generate and pass a one-time passcode to all participants so that they can link to this document. The participants may then query the blockchain using the one-time passcode and the hashed organization IDs to retrieve the incoming document key. The participants may use the document key to retrieve the shared document from the parties (i.e., blockchain nodes) that own it and store the document in the recipient's off-chain storage.

[0064] FIG. 1D illustrates a logical network diagram for a time-bound virtual currency or a virtual currency that is subject to virtual currency usage rules within a blockchain network, according to an example embodiment.

[0065] Referring to FIG. 1D, an exemplary network 100 includes a document processor node 102 connected to other blockchain (BC) nodes 105 representing document owner organizations. The processor node 102 may be connected to a blockchain 106 that includes a ledger 108 for storing data (110) shared among the nodes 105. Although this example shows only one document processor node 102 in detail, multiple such nodes may be connected to the blockchain 106. It should be understood that the document processor node 102 may include additional components and that some of the components described herein may be removed and / or modified without departing from the scope of the document processor node 102 disclosed herein. The document processor node 102 may include a processor 104, which may be a computing device or server computer, or the like, and may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another hardware device, or a combination thereof. Although a single processor 104 is shown, it should be understood that the document processor node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the document processor node 102 system disclosed herein.

[0066] The document processor node 102 may include a non-transitory computer readable medium 112 that may store machine readable instructions executable by the processor 104. Examples of machine readable instructions are shown as 114-120 and are further described below. Examples of the non-transitory computer readable medium 112 include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0067] In some embodiments, the processor 104 may execute first machine-readable instructions 114 to retrieve an EVC transaction associated with the blockchain and addressed to an address associated with the EVC wallet, the EVC transaction including an expiration date for the EVC, and the EVC is subject to Virtual Currency User Rules (VCUR) of which the expiration date is included as part. As previously described, the blockchain ledger 108 may store data shared among the nodes 105. The blockchain 106 network may be configured to use one or more smart contracts to govern transactions of multiple participating nodes. The processor 104 may execute second machine-readable instructions 116 to determine whether an expiration date for the EVC in the EVC transaction has passed. The processor 104 may execute third machine-readable instructions 118 to automatically transfer the EVC to a transferee specified in the VCUR without user intervention based on the first condition that the expiration date has passed.

[0068] FIG. 2A illustrates a configuration 200 of a blockchain architecture according to an example embodiment. With reference to FIG. 2A, the blockchain architecture 200 may include a particular blockchain element (e.g., a group of blockchain nodes 202). The blockchain nodes 202 may include one or more nodes 204-210 (four of these nodes are shown merely by way of example). These nodes participate in a number of activities, such as adding and validating blockchain transactions (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide an ordering service to all blockchain nodes in the architecture 200. A blockchain node may initiate a blockchain authentication and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 216, and a copy of this write may also be stored in the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to application programming interfaces (APIs) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations required by participants and can maintain their own state, control their own assets, and receive external information. Blockchain configurations can be deployed as transactions and installed on all blockchain nodes 204-210 by adding them to the distributed ledger.

[0069] The blockchain base or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 216 may expose interfaces that provide access to the virtual execution environments necessary to process and enlist program code into the physical infrastructure 214. The cryptographic trust services 218 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0070] The blockchain architecture of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control assets of the blockchain. For example, the code 220 may store and transfer data and may be executed by the nodes 204-210 in the form of associated chaincode including smart contracts and conditions or other code elements subject to execution. As a non-limiting example, smart contracts may be created to perform reminders, updates, or modifications, other notifications subject to updates, or combinations thereof. The smart contracts themselves may be used to identify permission and access requirements and rules associated with the use of the ledger. For example, the document attribute information 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The results 228 may include multiple linked shared documents. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

[0071] Using high-level application and programming languages, smart contracts may be created and then written into blocks in the blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated in the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition associated with the smart contract being satisfied. Execution of a smart contract may trigger a trusted change to the state of the digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0072] A smart contract may write data to the blockchain in the form of key-value pairs. Additionally, smart contract code can read values ​​stored in the blockchain and use them in the operation of the application. Smart contract code can write the output of various logical operations to the blockchain. This code may be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain may become public and / or be kept private and encrypted. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and deleted after the data required for the blockchain has been identified.

[0073] The chaincode may include a code interpretation of the smart contract along with additional functionality. As described herein, the chaincode may be program code deployed on a computing network and executed together to be validated by chain validators during a consensus process. The chaincode receives the hash and retrieves the hash from the blockchain associated with the data template created by use of the previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends the authorization key to the requested service. The chaincode may write data associated with the cryptographic details to the blockchain.

[0074] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. With reference to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of versions of the keys / values ​​read into the chaincode (the read set), and a set of keys / values ​​written into the chaincode (the write set). A proposal response 292 is sent back to the client 260, along with an endorsement if approved. The client 260 packages the endorsement into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block on a channel to all peers 281-283. Each peer 281-283 may verify the validity of the transaction before committing it to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct allocation of a given peer has signed the result and authenticated the signature on the transaction payload 293.

[0075] Referring again to FIG. 2B, a client node 260 initiates a transaction 291 by constructing and sending a request to a peer node 281 (endorser). The client 260 may include an application that utilizes a supported software development kit (SDK) to generate a transaction protocol using available APIs. A proposal is a request to invoke a chaincode function so that data can be read from and / or written to the ledger (i.e., writing a new key-value pair for an asset). The SDK may act as a shim to package the transaction proposal into a suitably designed format (e.g., protocol buffers over remote procedure calls (RPC)), receive the client's cryptographic credentials, and generate a unique signature for the transaction proposal.

[0076] In response, the endorsing peer node 281 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in the example, client 260) has the proper permissions to perform the proposed operation on the channel. The endorsing peer node 281 may take the transaction proposal input as an argument to a chaincode function that is invoked. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set, although no updates are made to the ledger at this time. At 292, the set of values, along with the signature of the endorsing peer node 281, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for use by the application.

[0077] In response, the client 260 application checks / verifies the signature of the endorsing peer and compares the proposal response to determine if the proposal response is the same. If the chaincode simply queried the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application is going to submit a transaction to the ordering node service 284 to update the ledger, the application determines if the specified endorsement policy is satisfied (i.e., if all required peer nodes for the transaction have endorsed the transaction) before submitting. Here, a client may include only one of multiple parties of the transaction. In this case, each client may include its own endorsing node, and each endorsing node must endorse the transaction. The architecture ensures that the endorsement policy is still enforced by peers and maintained during the commit validation phase, even if the application chooses not to check the response or otherwise forwards an unendorsed transaction.

[0078] After successful validation, in step 293, the client 260 bundles the endorsements into a transaction and broadcasts the transaction proposal and transaction response in a transaction message to the ordering node 284. The transaction may include the read / write set, the signature of the endorsing peer, and the channel ID. The ordering node 284 does not need to validate the entire contents of the transaction to perform its operation; instead, the ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions for each channel.

[0079] The block of transactions is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 in the block are validated to ensure that any endorsement policies are satisfied and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the execution of the transaction. The transactions in the block are tagged as being valid or invalid. Further, in step 295, each peer node 281-283 adds the block to the channel's chain and, for each valid transaction, the write set is committed to the current state database. Events are published to inform the client application that the transaction (invocation) has been immutably added to the chain and to inform whether the transaction has been validated or invalidated.

[0080] FIG. 3A illustrates an example of a permissioned blockchain network 300, which features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction to a permissioned blockchain 304. In this example, the transaction may be a deploy, invoke, or query, and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as “auditors” and blockchain users 302 as “clients.” Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0081] A blockchain developer 310 can write chaincode and client-side applications. Through an interface, the blockchain developer 310 can deploy the chaincode directly to the network. To include authentication information from traditional data sources 312 in the chaincode, the developer 310 can use an out-of-band connection to access the data. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before initiating any transactions, the peer node 314 obtains a certificate of the user's registration and transaction from a certificate authority 316 that manages the user's roles and permissions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 304. On the other hand, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 312. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0082] FIG. 3B illustrates another example of a permissioned blockchain network 320, which features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 322 may submit a transaction to the permissioned blockchain 324. In this example, the transaction may be a deploy, invoke, or query, and may be issued via a client-side application utilizing an SDK, directly via an API, etc. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as “auditors” and blockchain users 322 as “clients.” Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0083] A blockchain developer 330 writes the chaincode and client-side applications. Through an interface, the blockchain developer 330 can deploy the chaincode directly to the network. To include authentication information from traditional data sources 332 in the chaincode, the developer 330 can use an out-of-band connection to access the data. In this example, a blockchain user 322 connects to the network through a peer node 334. The peer node 334 obtains a certificate of the user's registration and transaction from a certificate authority 336 before initiating any transactions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 324. On the other hand, users seeking to utilize the chaincode may need to verify their user's authentication information on traditional data sources 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0084] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions, thus adding entries to the ledger. Additionally, any participant may choose to run a node on the system and adopt a mining protocol to help validate transactions.

[0085] FIG. 3C illustrates a process 350 of a transaction being processed by a permissionless blockchain 352 that includes multiple nodes 354. A sender 356 wishes to send a payment or other form of value (e.g., a deed, medical record, contract, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, the sender device 356 and the receiver device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and display of transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes validate (360) the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this validation may include verifying the identities of the parties involved, etc. The transaction may be validated immediately, or the transaction may be placed in a queue with other transactions and node 354 determines whether the transaction is valid based on a set of network rules.

[0086] In structuring 362, valid transactions are formed into blocks and sealed using a lock (hash). This process may be performed between nodes 354 by mining nodes. Mining nodes may utilize additional software to, among other things, mine and create blocks of the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent chain of blocks.

[0087] Before a block can be added to the blockchain, it must be validated. Validation of a permissionless blockchain 352 may involve Proof of Work (PoW), which is the solution to a puzzle derived from the block's header. Another process for validating a block, not shown in the example of FIG. 3C, is Proof of Stake. Unlike Proof of Work, where an algorithm rewards miners for solving a mathematical problem, in Proof of Stake, the creators of new blocks are selected in a deterministic way depending on their wealth (also defined as "stake"). Similar proofs are then performed by the selected nodes.

[0088] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates a proof of work, thereby guaranteeing a correct answer. In other words, a possible solution must prove that computational resources were expended in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0089] Here, the PoW process, along with the chaining of blocks, makes it extremely difficult to modify the blockchain, since an attacker must modify all subsequent blocks for a change to one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and so does the number of subsequent blocks. At distribution 366, the successfully validated block is distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0090] FIG. 4 is a block diagram illustrating a basic blockchain sequence 400 of three transactions. The first block includes a first header 410a and a first group of transactions 420a that make up the first block. The block header includes a hash 412a of the previous block header and a Merkle root 414a. The Merkle root 414a is a hash of all hashes of all transactions that are part of the block in the blockchain network, ensuring that the entire data block passed between peers is undamaged and unaltered. The second block includes a second header 410b and a second group of transactions 420b that make up the second block. The block header includes a hash 412b of the previous block header 410a and a Merkle root 414b. The third block includes a third header 410c and a third group of transactions 420c that make up the third block. The block header includes a hash 412c of the previous block header 410b and a Merkle root 414c. The number of blocks may be extended to any feasible length and the hash value can be checked / verified relatively easily.

[0091] FIG. 5A illustrates an example system 500 including a physical infrastructure 510 configured to perform various operations according to example embodiments. With reference to FIG. 5A, the physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may be present in the blockchain 520) that may perform any of the operational steps 508 (within the module 512) included in any of the example embodiments. The steps / operations 508 may include one or more of the embodiments described or illustrated in the figures and may represent information written or read, output or written from one or more smart contracts 530 and / or the blockchain 520. The physical infrastructure 510, the module 512, and the module 514 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the module 512 and the module 514 may be the same module.

[0092] FIG. 5B illustrates another exemplary system 540 configured to perform various operations according to example embodiments. Referring to FIG. 5B, the system 540 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside in the blockchain 520) that may perform any of the operational steps 508 (within the module 512) included in any of the example embodiments. The steps / operations 508 may include one or more of the embodiments described or illustrated in the figures and may represent information written or read, outputted, or written from one or more smart contracts 530 and / or the blockchain 520. The physical modules 512 and 514 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Additionally, the modules 512 and 514 may be the same module.

[0093] FIG. 5C illustrates an exemplary system configured to utilize an intermediary server configured to enforce the terms of a smart contract on a blockchain, as well as the composition of a smart contract between contracting parties, according to an example embodiment. With reference to FIG. 5C, the composition 550 may represent a communication session, an asset transfer session, or a process or procedure, and is driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the execution of the smart contract may be managed by a server 554. The contents of the smart contract 530 may require digital signatures by one or more of the entities 552 and 556 that are participants in the smart contract transaction. The results of the execution of the smart contract may be written to the blockchain 520 as a blockchain transaction. The smart contract 530 resides on the blockchain 520, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0094] FIG. 5D illustrates a system 560 including a blockchain, according to an example embodiment. Referring to the example of FIG. 5D, an application programming interface (API) gateway 562 provides a common interface for accessing the logic (e.g., smart contracts 530 or other chaincode) and data (e.g., distributed ledger, etc.) of the blockchain. In this example, the API gateway 562 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to blockchain peers (i.e., servers 554). Here, the servers 554 are peer components of the blockchain network that hold copies of the world state and the distributed ledger, which allow clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, and the endorsing peers execute the smart contracts 530 according to the smart contracts 530 and endorsement policies.

[0095] The foregoing embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination thereof. The computer program may be embodied on a computer readable medium, such as a storage medium. For example, the computer program may reside in a random access memory (RAM), a flash memory, a read only memory (ROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a register, a hard disk, a removable disk, a compact disk read only memory (CD-ROM), or any other form of storage medium known in the art.

[0096] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit (ASIC). In the alternative, the processor and the storage medium may reside as discrete components.

[0097] Figure 6A illustrates the process 600 of a new block being added to a distributed ledger 620 according to an example embodiment, and Figure 6B illustrates the contents of a blockchain new data block structure 630 according to an example embodiment. The new data block 630 may contain documents that link data.

[0098] With reference to FIG. 6A, a client (not shown) may submit a transaction to blockchain nodes 611, 612, or 613, or a combination thereof. A client may be an instruction received from any source to prescribe an activity on the blockchain 620. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, proposing a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 611, 612, and 613) may maintain a copy of the blockchain network state and the distributed ledger 620. Various types of blockchain nodes / peers may exist in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that verify the endorsements, confirm the validity of the transactions, and commit the transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may perform the role of endorser nodes, committer nodes, or both.

[0099] The distributed ledger 620 includes a blockchain that stores immutable ordered records in blocks, and a state database 624 (current world state) that maintains the current state of the blockchain 622. There may be one distributed ledger 620 per channel, with each peer maintaining its own copy of the distributed ledger 620 for each channel in which it is a member. The blockchain 622 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may include various components, such as those shown in FIG. 6B. Block links (shown by arrows in FIG. 6A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 622 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 622 represents all transactions that came before it. The blockchain 622 may be stored in the file system (local or attached storage) of a peer that supports additional dedicated blockchain workloads.

[0100] The current state of the blockchain 622 and the distributed ledger 622 may be stored in a state database 624, where the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 622. Chaincode invocations execute transactions against the current state in the state database 624. To make those chaincode interactions highly efficient, the latest values ​​of all keys are stored in the state database 624. The state database 624 may contain an indexed view into the blockchain 622 transaction log and therefore may be regenerated off-chain at any time. The state database 624 may be automatically restored (or generated if necessary) at peer startup and before transactions are received.

[0101] An endorsing node receives transactions from clients and endorses transactions based on the simulation results. An endorsing node holds a smart contract that simulates a transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The manner in which a transaction is endorsed is determined by an endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels may have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 610.

[0102] The ordering service 610 receives endorsed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 610 may start a new block when a transaction threshold is reached, a timer times out, or another condition. In the example of FIG. 6A, blockchain node 612 is a committing peer that receives a new data block 630 of new data for storage in the blockchain 620. The first block in a blockchain may be called a genesis block, which contains information about the blockchain, the members of the blockchain, the stored data, etc.

[0103] The ordering service 610 may consist of a cluster of ordering nodes. The ordering service 610 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 610 may receive endorsed transactions and specify the order in which those transactions are committed to the distributed ledger 620. The architecture of the blockchain network may be designed such that a particular implementation of “ordering” (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0104] Transactions are written to the distributed ledger 620 in a consistent order. The order of transactions is established to ensure that updates to the state database 624 are valid when transactions are committed to the network. Unlike cryptocurrency blockchain systems (e.g., virtual currencies) where ordering occurs through solving cryptographic puzzles or through mining, in this example, the participants in the distributed ledger 620 may choose the ordering mechanism that best suits their network.

[0105] When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to the commit peers (e.g., blockchain nodes 611, 612, and 613). In response, each commit peer validates the validity of the transactions in the new data block 630 by checking to ensure that the read set and write set still match the current world state in the state database 624. In particular, the commit peer may determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 624. If the commit peer validates the transaction, the transaction is written to the blockchain 622 of the distributed ledger 620 and the state database 624 is updated with the write data from the read / write set. If the transaction fails, i.e., if the commit peer detects that the read / write set does not match the current world state in the state database 624, the transactions ordered in the block are still included in the block but are marked as invalid and the state database 624 is not updated.

[0106] With reference to FIG. 6B, a new data block 630 (also referred to as a data block) stored in the blockchain 622 of the distributed ledger 620 may include multiple data segments, such as a block header 640, block data 650, and block metadata 660. It should be understood that the various illustrated blocks and their contents, such as the new data block 630 and its contents illustrated in FIG. 6B, are examples only and are not intended to limit the scope of the example embodiments. The new data block 630 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the data block 650. The new data block 630 may include a link to a previous block (e.g., on the blockchain 622 of FIG. 6A) in the block header 640. In particular, the block header 640 may include a hash of the header of the previous block. The block header 640 may include a unique block number for the new data block 630, a hash of the block data 650, etc. The block numbers for the new data block 630 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

[0107] The block data 650 may store transaction information for each transaction recorded in the new data block 630. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 620 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploy transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, endorser identification, endorser signature, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0108] In some embodiments, the block data 650 may store new data 662 that adds additional information to the hash-linked chain of blocks in the blockchain 622. The additional information may include one or more of the steps, features, processes, or operations, or combinations thereof, described or illustrated herein. Accordingly, the new data 662 may be stored in an immutable log of blocks on the distributed ledger 620. Some of the advantages of storing such new data 662 are reflected in the various embodiments disclosed and illustrated herein. In FIG. 6B, the new data 662 is illustrated in the block data 650, but it may also be in the block header 640 or the block metadata 660. The new data 662 may include a document composite key used to link documents within an organization.

[0109] The block metadata 660 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persistent offset of the ordering service that ordered the block, etc. The signature, the last constituent block, and the ordering node metadata may be added by the ordering service 610. Meanwhile, the committer of the block (e.g., blockchain node 612) may add valid / invalid information based on the endorsement policy, validation of the read / write set, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 650, and a validation code that identifies whether the transaction was valid / invalid.

[0110] FIG. 6C illustrates an embodiment of a blockchain 670 for digital content, according to embodiments described herein. Digital content may include one or more files and associated information. These files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only characteristics of blockchain serve as a safeguard to protect the integrity, validity, and authenticity of digital content, making its use appropriate in legal proceedings where admissibility rules apply, or in other situations where evidence is considered or the presentation and use of digital information is otherwise subject. In this case, the digital content may be referred to as digital evidence.

[0111] A blockchain may be formed in a variety of ways. In one embodiment, digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of the reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis to reference the previous block. This may be shown as follows: Block 1 B Rock 2 ... Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0112] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the contents of each block that does not contain any digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then searching in the storage area for that hash value stored corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be shown as follows: Blockchain Storage Space Hash value of block 1 Hash value of block 1...Contents Hash value of block N Hash value of block N... contents

[0113] In the example embodiment of FIG. 6C , the blockchain 670 comprises multiple cryptographically linked blocks 6781, 6782, ... 678 in an ordered sequence. N , where N >= 1. Blocks 6781, 6782, ... 678 N The encryption used to link the ciphers may be either multiple keyed or unkeyed hash functions. In one embodiment, blocks 6781, 6782, ... 678 N are subjected to a hash function (where n is 256 or another number) that produces an n-bit alphanumeric output from an input that is based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, the Merkle-Dangard algorithm, the HAIFA algorithm, the Merkle tree algorithm, nonce-based algorithms, and non-collision resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ..., 678 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is given with reference to a hash function (eg, SHA-2).

[0114] Blocks 6781, 6782, ... 678 in the blockchain N Each of the files includes a header, a file version, and a value. The header and value vary from block to block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0115] The first block 6781 in a blockchain is called the genesis block and contains a header 6721, an original file 6741, and an initial value 6761. The hashing scheme used for the genesis block, and indeed for all subsequent blocks, may vary. For example, all of the information in the first block 6781 may be hashed together simultaneously, or each or a portion of the information in the first block 6781 may be hashed separately, and then a hash of the separately hashed portions may be performed.

[0116] The header 6721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, or other information associated with the original file 6741 or the blockchain or both, or a combination thereof. The header 6721 may be generated automatically (e.g., by blockchain network management software) or manually by a participant of the blockchain. Other blocks 6782-678 in the blockchain N Unlike headers in the 6721 block, header 6721 in the genesis block does not reference a previous block, because there is simply no previous block.

[0117] The original file 6741 in the genesis block may be, for example, data captured by a device, with or without processing prior to inclusion in the blockchain. The original file 6741 may be received from a device, media source, or node through an interface of the system. The original file 6741 may be associated with metadata, which may be generated, for example, by a user, device, or system processor, or a combination thereof, either manually or automatically. The metadata may be included in the first block 6781 in association with the original file 6741.

[0118] The value 6761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 6741. In one embodiment, the one or more unique attributes may include a hash value of the original file 6741, metadata of the original file 6741, and other information associated with the file. In one implementation, the initial value 6761 may be based on the following unique attributes: (1) The hash value calculated for the original file using SHA-2 (2) Calling device ID (3) The start timestamp of the original file (4) The initial storage location of the original file (5) The blockchain network member ID of the software that currently controls the original file and associated metadata.

[0119] Other blocks in the blockchain: 6782 to 678 N However, unlike the first block 6721, the headers 6722 to 6723 in the other blocks also include a header, a file, and a value. N Each of the remaining blocks contains the hash value of the immediately preceding block, which may simply be a hash of the previous block's header, or may be a hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block tracing can be performed from the Nth block to the genesis block (and associated original file), as indicated by arrow 680, establishing an auditable and immutable evidential chain of custody.

[0120] Headers 6722 to 672 in other blocks N Each of the may generally include other information (e.g., a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof).

[0121] Files 6742 to 674 in other blocks N may be the same as the original file in the genesis block or may be a modified version of the original file, depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any modification of the file in the preceding block, such as, for example, editing information or otherwise changing the content of the file, removing information from the file, or adding information to the file.

[0122] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of the file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another storage or memory location, or performing operations on the file and / or associated metadata on the blockchain. Processing including analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0123] Other blocks 6762~676 N The value contained in each of the blocks is unique and different as a result of the operations that were performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block to which the value was assigned. Thus, the value of a block indicates what operations were performed in the block, and also makes it possible to trace the blockchain back to the original file. This tracking ensures the evidential integrity of the file throughout the blockchain.

[0124] For example, consider the case where a portion of a file in a previous block is edited, blocked, or pixelated to protect the identity of a person indicated in the file. In this case, the block containing the edited file will include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp of when the edit occurred, etc. This metadata may be hashed to form a value. Because the metadata of the block is different from the information hashed to form the value in the previous block, the values ​​are different from each other and may be recovered when decrypted.

[0125] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block when any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information set forth below: (a) A new SHA-2 computed hash value whenever the file is processed in any way (e.g., when the file is edited, copied, modified, accessed, or any other action is performed on it). (b) The new storage location of the file. (c) Identified new metadata associated with the file. (d) Transfer of access to or control of a file from one blockchain participant to another blockchain participant.

[0126] FIG. 6D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 690, according to one example embodiment. i ) is header 672 i , File 674 i , and the value 676 i Contains:

[0127] Header 672 i is the previous block (blocki-1 ) and additional reference information, which may be, for example, any of the types of information described herein (e.g., header information containing references, properties, parameters, etc.). Every block references the hash of the previous block, except of course for the genesis block. The hash value of the previous block may simply be a hash of the header in the previous block, or it may be a hash of all or part of the information in the previous block, including files and metadata.

[0128] File 674 i contains multiple data, such as Data 1, Data 2, ..., Data N, in turn. The data are tagged with Metadata 1, Metadata 2, ..., Metadata N, describing content and / or characteristics associated with the data. For example, the metadata for each data may include information to indicate a timestamp of the data, keywords indicative of the process of the data, people or other content depicted in the data, or other characteristics that establish the validity and content of the file as a whole and may be useful in particular for using digital evidence, for example as described in connection with the embodiments described below, or a combination thereof. In addition to the metadata, each data may include a reference to the previous data (Reference 1, Reference 2, ..., Reference 3) to prevent tampering, gaps in the file, and successive references throughout the file. N ) may be tagged.

[0129] After metadata is assigned to data (e.g., via a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Thus, the metadata creates a data log of information that may be accessed for use by participants in the blockchain.

[0130] Value 676 i is a hash value or other value calculated based on any of the types of information previously described. For example,i ), the value of that block may be updated to reflect the operation performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other operation or added information). Although the values ​​in each block are shown as being separate from the metadata of the file and header data, in alternative embodiments the values ​​may be based in part or in whole on this metadata.

[0131] At any point after the blockchain 670 is formed, an immutable evidential integrity of the file may be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or trace procedure may begin by decrypting the value of the last included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may include decrypting the header and file and associated metadata at each block.

[0132] Decryption is performed based on the type of encryption performed on each block. This decryption may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, a blockchain participant or processor in the network may generate a public and private key pair using a predefined algorithm. The public and private keys are related to each other by some mathematical relationship. The public key may be distributed publicly to serve as an address (e.g., an IP address or a home address) for receiving messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent this message.

[0133] Generating a key pair is similar to creating an account on the blockchain, but in reality, there is no need to register anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using a private key. This signature ensures that only the account owner can track and process files on the blockchain (if within the scope of their permissions, as determined by the smart contract).

[0134] 7A and 7B illustrate additional use cases for blockchain that may be incorporated and used herein. In particular, FIG. 7A illustrates an example 700 of a blockchain 710 storing machine learning (artificial intelligence) data. Machine learning relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can sift through millions of records to discover often non-intuitive patterns.

[0135] In the example of FIG. 7A, a host platform 720 builds and deploys machine learning models for predictive monitoring of assets 730, where the host platform 720 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The assets 730 may be any type of asset (e.g., machinery or equipment, etc.), such as an aircraft, a locomotive, a turbine, a medical device, an oil and gas device, a boat, a ship, a vehicle, etc. As another example, the assets 730 may be intangible assets, such as stocks, currencies, digital coins, insurance, etc.

[0136] The blockchain 710 may be used to significantly improve both the machine learning model training process 702 and the prediction process 704 based on the trained machine learning model. For example, in 702, historical data may be stored on the blockchain 710 by the assets 730 themselves (or through an intermediary not shown) rather than requiring a data scientist / engineer or other user to collect the data. This may significantly reduce the collection time required by the host platform 720 when performing training of the predictive model. For example, smart contracts may be used to transfer data directly and reliably from its original location to the blockchain 710. The smart contract may use the blockchain 710 to send data directly from the assets to the individuals who use the data to build the machine learning model, ensuring the security and ownership of the collected data. This allows for the sharing of data between the assets 730.

[0137] The collected data may be stored in the blockchain 710 based on a consensus mechanism. The consensus mechanism controls (authorized nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Thus, the recorded data is auditable, transparent, and secure. By adding IoT devices that write directly to the blockchain, it is possible to increase the frequency with which data is recorded and improve its accuracy in certain cases (i.e., in the case of supply chain, healthcare, logistics, etc.).

[0138] Further, the training of the machine learning model on the collected data may undergo a series of refinements and tests by the host platform 720. Each refinement and test may be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. At 702, the different training and testing steps (and associated data) may be stored in the blockchain 710 by the host platform 720. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored in the blockchain 710. This provides verifiable proof of how the model was trained and what data was used to train the model. Further, when the host platform 720 realizes the final trained model, the resulting model may be stored in the blockchain 710.

[0139] After the model is trained, it may be deployed into a live environment and predictions / decisions may be made based on the execution of the final trained machine learning model. For example, at 704, the machine learning model may be used for condition-based maintenance (CBM) for assets such as aircraft, wind turbines, medical machines, etc. In this example, data fed back from the asset 730 may be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. Decisions made by the execution of the machine learning model on the host platform 720 may be stored on the blockchain 710 to provide auditable / verifiable proof. As one non-limiting example, the machine learning model may predict a future outage / failure on a part of the asset 730 and create an alert or notification to replace the part. The data behind this decision may be stored on the blockchain 710 by the host platform 720. In one embodiment, the features and / or operations described and / or illustrated herein may occur on or with respect to the blockchain 710.

[0140] New transactions on the blockchain can be collected together in a new block and added to an existing hash value. This hash value is then encrypted to create a new hash for the new block. This new hash is added to the next list of transactions as they are encrypted, and so on. The result is a chain of blocks, each containing the hash values ​​of all preceding blocks. The computers that store these blocks periodically compare the hash values ​​of the blocks to ensure that they are all in agreement. Any computers that are not in agreement discard the offending records. This method is good at guaranteeing that the blockchain is tamper-proof, but it is not perfect.

[0141] One way to rig the system is for a malicious user to modify the list of transactions in a way that does not change the hash. This can be done by a brute force attack, in other words by modifying the record, encrypting the result, and checking if the hash value is the same. If the hash value is not the same, it tries again and again until it finds a matching hash. The security of the blockchain is based on the idea that a normal computer can only perform this kind of brute force attack over totally impractical timescales, such as the age of the universe. Quantum computers, by contrast, are very fast (thousands of times faster) and therefore pose a very large threat.

[0142] FIG. 7B shows an example 750 of a quantum secure blockchain 752 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD, which involves transmitting information using quantum particles, such as photons, that cannot be copied by an eavesdropper without being corrupted. In this way, senders and receivers can verify each other's identities via the blockchain.

[0143] In the example of Figure 7B, there are four users (754, 756, 758, and 760). Each pair of users can share a secret key 762 (i.e., QKD) between themselves. Since there are four nodes in this example, there are six pairs of nodes, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CDSix different private keys 762 are used, including the 1000-key ...

[0144] The operation of the blockchain 752 is based on two steps: (i) the creation of a transaction, and (ii) the construction of a block that collects new transactions. New transactions may be created in the same way as in a traditional blockchain network. Each transaction may contain information about the sender, the recipient, the time of creation, the amount (or value) to be transferred, a list of reference transactions that justify the sender having funds for the operation, etc. This transaction record is then sent to all other nodes and entered into the pool of unconfirmed transactions. Now, two parties (i.e., a pair of users among 754-760) authenticate the transaction by providing a shared secret key 762 (QKD). This quantum signature is attached to every transaction, making it extremely difficult to tamper with. Each node checks the transaction entry with respect to its local copy of the blockchain 752 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0145] Rather than performing a traditional mining process on a block, a broadcast protocol may be used to create blocks in a distributed manner. At a predefined time period (e.g., seconds, minutes, hours, etc.), the network may apply the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine consensus on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). First, the nodes send the private value to each other. Then, the nodes communicate the information they previously received from other nodes. Now, an authentic node can create a complete set of transactions in a new block. This new block can be added to the blockchain 752. In one embodiment, the features and / or operations described and / or illustrated herein may occur in or with respect to the blockchain 752.

[0146] 8, there is shown a high-level block diagram of an exemplary computer system 800 that may be used in implementing one or more of the methods, tools, and modules described herein, and any associated functionality, in accordance with embodiments of the present disclosure (e.g., using one or more processor circuits or computer processors of a computer). The computer system may be a DPS 10, as previously described, in some embodiments. In some embodiments, the major components of the computer system 800 may include one or more CPUs 802, a memory subsystem 804, a terminal interface 812, a storage interface 816, an I / O (Input / Output) device interface 814, and a network interface 818, all of which may be communicatively coupled, directly or indirectly, for communication between the components via a memory bus 803, an I / O bus 808, and an I / O bus interface unit 810.

[0147] Computer system 800 may include one or more programmable general-purpose central processing units (CPUs) 802A, 802B, 802C, and 802D, collectively referred to herein as CPUs 802. In some embodiments, computer system 800 may include multiple processors, as is typical in larger systems, although in other embodiments computer system 800 may alternatively be a single-CPU system. Each CPU 802 may execute instructions stored in memory subsystem 804 and may include one or more levels of on-board cache.

[0148] The system memory 804 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 822 or cache memory 824. The computer system 800 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 826 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium, such as a "hard drive." Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In addition, the memory 804 may include flash memory (e.g., a flash memory stick drive or flash drive). Memory devices may be connected to the memory bus 803 by one or more data media interfaces. The memory 804 may include at least one program product comprising a series of (eg, at least one) program modules configured to perform functions of various embodiments.

[0149] One or more programs / utilities 828, each including at least one set of program modules 830, may be stored in memory 804. The programs / utilities 828 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a network environment. The programs 828 and / or program modules 830 typically perform the functions or methods of the various embodiments.

[0150] 8, memory bus 803 is shown as a single bus structure providing a direct communication path between CPU 802, memory subsystem 804, and I / O bus interface 810, memory bus 803 may in some embodiments include multiple different buses or communication paths that may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, redundant parallel paths, or any other suitable type of configuration. Additionally, while I / O bus interface 810 and I / O bus 808 are each shown as single units, computer system 800 may in some embodiments include multiple I / O bus interface units 810, multiple I / O buses 808, or both. Additionally, while multiple I / O interface units are shown isolating I / O bus 808 from the various communication paths reaching the various I / O devices, in other embodiments some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0151] In some embodiments, computer system 800 may be a multi-user mainframe computer system, a single-user system, or a server computer, or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 800 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0152] Figure 8 illustrates major representative components of an exemplary computer system 800. However, in some embodiments, individual components may have greater or less complexity than those depicted in Figure 8, there may be other or additional components than those depicted in Figure 8, and the number, type, and configuration of such components may vary.

[0153] As described in further detail herein, it is contemplated that some or all of the operations of some of the embodiments of the methods described herein may be performed in a different order, or not performed at all, and further, that multiple operations may occur simultaneously or as part of a larger process.

[0154] An electronic wallet that allows for the expiration of cryptocurrencies System Overview This disclosure contemplates the use of an electronic wallet that allows a virtual currency using blockchain technology to have an expiration date as one of a set of virtual currency usage rules (VCUR) associated with the virtual currency. Such a virtual currency is referred to herein as an expiry virtual currency (EVC), i.e., a blockchain virtual currency with associated usage rules. Contrary to the designation of EVC, the expiration date need not be an actual VCUR among the VCURs associated with the EVC, and the use of the term EVC is used merely for brevity. Additionally, "expiry virtual currency" and "EVC" refer to any virtual currency that uses blockchain technology, has at least one associated VCUR, and contains optional information within the transaction. The term "virtual currency" is defined herein for brevity to include all blockchain virtual currencies and digital currencies, and does not refer solely to actual or regular virtual currencies, unless expressly indicated (by the use of the term "standard virtual currency"). An EVC may represent a digital token, sometimes referred to herein as a "local virtual currency." Such an EVC may represent, for example, a currency token that may expire and be made unusable after a specified time period, or that may be automatically transferred to a freely selected destination / transferee (e.g., a charity, etc.).

[0155] It may be desirable for purchases and / or payments to be made to a particular set of entities according to a VCUR, such as within a particular time period. As an example, it may be desirable to use EVC for subsidies, such as financial aid, or subsidies for economic stimulus measures within a country or a particular district, which should be consumed within a particular time period. Existing effective methods for such situations are limited to indirect methods, such as gift certificates and coupons, which have an expiration date. In electronic money systems, such methods are limited to point redemptions, which have a limited time period, and the like. In some situations, it may be desirable to develop a method for the use of electronic money by a large organization or entity, such as a country, a special region, or a large corporation, that sets an expiration date for measures costs, financial aid, and the like, as a VCUR, thereby obtaining immediate effective and efficient results. Disclosed herein is a mechanism for implementing EVC, in which a management entity (e.g., a local government, a corporation, or other such entity) distributes EVCs and dedicated wallets with VCURs to users, according to some embodiments.

[0156] EVC may be used, for example, for payments at stores outside the local economic zone or for payments to users within the local economic zone. EVC paid outside the local economic zone can be used as a general virtual currency that does not expire. A VCUR, such as an expiration date, may be determined by a management entity that creates the original VCUR of the EVC. The expiration date may be, for example, predetermined, or may be extended, for example, N days after each transaction is made. A scheme may be implemented such that EVC that has expired without being used within a predefined set of EVC recipients is transferred to a transfer destination (account) on a pre-specified list of transfer destinations. The transfer destination may be a donation destination that receives the transfer as a gift in some embodiments. As a result, the use of EVC within the expiration date according to the VCUR may be promoted. In some embodiments, the system allows a transferee, such as a donor organization, to automatically issue a receipt, such as a donation certificate, for the transferred EVC, thereby contributing, for example, to the donor's tax savings and / or promotion. To realize the above-mentioned use of EVC, a predefined set of EVC recipients may be established.

[0157] In some embodiments, the destination of the EVC may be restricted to destinations in the EVC Recipient Destination List (see Table 2 below). The recipients in this list may be classified as destinations that have an EVC wallet (local, internal - i.e., destinations included in the predefined set of EVC recipients) and destinations that do not have an EVC wallet (global, external - i.e., destinations outside the predefined set of EVC recipients). When sending money by specifying a destination that has an EVC wallet (local, internal), deadline information may be provided in the transaction, and the amount received by the remittance partner is automatically sent when it is used within the deadline or when the deadline is reached (or other VCUR is triggered). In that case, this amount is sent to the destination (e.g., a charity). If a destination that does not have an EVC wallet (global, external) is specified and an EVC is sent to such a destination, deadline information is not added to the transaction. A "global, external" remittance recipient may use a regular wallet and use the received amount as regular cryptocurrency with no deadline or destination restrictions. In other words, an EVC wallet sends money subject to the limitations imposed by expiration times set in transactions addressed to the EVC wallet itself, and the limitations that limit destinations to a list imposed by the dedicated wallet's specifications.

[0158] The following definitions and explanations may apply to various terms used herein. In the case of cryptocurrencies, transactions are recorded on a distributed ledger (blockchain) on a decentralized peer-to-peer network. The original token may be implemented by using an optional space (such as Bitcoin's OP_RETURN field) within each cryptocurrency transaction. A local cryptocurrency, sometimes referred to as EVC, is a medium for exchanging value in the form of a token with an expiration date. Due to the use of a cryptocurrency blockchain, EVC may have security and resistance to tampering equivalent to that of cryptocurrencies. A local economic zone network, sometimes referred to as a predefined set of EVC recipients, that limits the circulation range or scope of EVC, is defined as follows: While cryptocurrency transactions are carried out between an unspecified number of users, local cryptocurrency or EVC transactions may be carried out only between dedicated wallet applications distributed by the issuer to specific users. Along with this, a network of a predefined set of EVC recipients, such as a local economic zone, managed by an issuer, may be built on a global decentralized network of cryptocurrencies or on a network of other cryptocurrencies. An apparatus for generating addresses and private keys generates cryptocurrency addresses between which local cryptocurrency or EVC transactions may be performed. The apparatus generates private keys corresponding to those addresses. The generated information is retained within wallet applications distributed to designated users, enabling each wallet application to make payments to another generated address.

[0159] Each dedicated wallet application may perform a transfer of money to another address inside or outside a predefined set of EVC recipients. The dedicated wallet application may obtain basic information such as a list of counterparty destination addresses, automatic transfer destinations, and expiration coefficients by periodically accessing the presentation device. The dedicated wallet application may extract balances that have not been used in transactions from the virtual currency blockchain, extract expired balances, and automatically transfer those balances to the destination in the manner of normal virtual currency transfers. The device for inputting and presenting basic information may receive input of basic information such as addresses of specific users in the local economic zone network, automatic transfer destinations, and expiration coefficients. The basic information may be periodically referenced and used by each dedicated wallet application. This device may be managed by the issuer of the EVC.

[0160] As explained below, the life of an EVC can be described in terms of each stage. The first stage is the creation of an EVC by an issuer, who may convert regular virtual currency (or other currency) into an EVC, for example by adding VCUR. In the second stage, the issuer may distribute the EVC to a set of EVC recipients. To do this, the EVC recipient must have a special EVC wallet application, which may be configured by the issuer or by the EVC recipient, for example by downloading this application from an online store to a device. After the EVC wallet is configured, the issuer may transfer the EVC to the EVC recipient. The life of the EVC continues with the EVC recipient storing the EVC in its EVC wallet when it is received from the issuer.

[0161] In the next stage of the EVC's life, the EVC Recipient's use or automatic transfer stage, the EVC Recipient may transfer the EVC to other EVC Recipients before the expiration specified in the VCUR, but only to EVC Recipients specified by the Issuer in a further VCUR in the EVC Recipient destination list described below. However, after the EVC expires, the EVC is automatically transferred to a transferee, such as a charity, without the intervention of the EVC Recipient (or other EVC Recipients). In some embodiments, the transferee is specified only by the Issuer. In other embodiments, the transferee may be specified by the EVC Recipient (either initially or by changing the Issuer's transferee), but may be subject to certain restrictions. Also, in some embodiments, the EVC Recipient may transfer parts of the EVC to other EVC Recipients before the expiration of the EVC, and such transfers may be made without a VCUR (i.e., as regular virtual currency). In other embodiments, the EVC receiver may transfer the EVC with a VCUR containing the same, more, or less limits depending on the issuer's initial VCUR. The VCUR may be transferred in the same or modified form across multiple ordered transactions, possibly indefinitely, or the VCUR may end at some point and the EVC may be converted to regular virtual currency.

[0162] In some embodiments, funds represented by the EVC are transferred to the transferee without the VCUR (i.e., as regular virtual currency or other forms of currency). The EVC recipient may transfer the EVC before it expires. In some embodiments, the transfer may preserve the VCUR, while in other embodiments, the transfer may remove some or all of the VCUR. The VCUR may be incorporated as part of the transaction (e.g., an expiration date) or may be communicated as an out-of-band (i.e., outside of regular virtual currency communications) communication (e.g., the EVC recipient destination list and transferee destination list described below), or both.

[0163] FIG. 9 is a block diagram illustrating a distributed ledger (blockchain) cryptocurrency ledger 900 consisting of multiple blocks 910, each containing multiple transactions 920. The distributed ledger 900 is implemented on a decentralized peer-to-peer network. A cryptocurrency address identifies a cryptocurrency user. Using a wallet application, the cryptocurrency user proves ownership of the amount transferred in a transaction with the destination address set to the user's address by using a private key combined with the address.

[0164] The transferred amount of virtual currency owned by the user may be transferred to another virtual currency user. As shown in the example transaction 920, Alice starts with 10 virtual currency units (VCUs) (transaction input) 930 and then transfers 2 virtual currency VCUs to Bob. After the transaction is generated, the miner (mining operator) records the virtual currency transaction in the ledger 900, and thus a fee (mining fee) of 0.05 VCUs is set in the transaction 920 to be paid as compensation to the miner. The obtained result (transaction output) 940 becomes part of the recorded transaction 920. Due to the data structure of the virtual currency transaction 920, optional information (metadata) 950 other than information related to the transfer and receipt of virtual currency may be set in the virtual currency transaction. Depending on the implementation of the wallet application, the system may transfer any asset other than virtual currency and record information related to the virtual currency and the transaction.

[0165] Transactions 920 are continuously recorded in the cryptocurrency ledger 900. The wallet application sums the amounts transferred in each transaction 920 and considers the calculated amount the available balance. The wallet application controls a private key that is paired with the public key embedded in the transaction 920 to prove ownership of the amounts transferred in the transaction 920.

[0166] Figure 10 is a block diagram showing the transfer of two transferors (transactions 920 on the left) to a transferee (transactions 920 on the right). In these transactions 920, Alice starts with 10 VCUs and then transfers 2 VCUs to Bob, leaving Alice with 7.95 VCUs 940 after a 0.05 VCU fee is applied. Similarly, Joe starts with 10 VCUs and then transfers 3 VCUs to Bob, leaving Joe with 6.95 VCUs 940 after a 0.05 VCU is applied. The right-most transaction 920 shows Bob's receipt of 2+3 VCUs from Alice and Joe as 5 VCUs in the transaction input 930 of Bob's wallet application.

[0167] FIG. 10 further illustrates the rightmost transaction 920 as being one in which Bob transfers 2 VCU to Erin. However, in this case, the 2 VCU are in an EVC with expiration information stored in optional information 950. Optional information 950 includes an area, such as an 80-byte area called OP_RETURN in Bitcoin™, for which free description is allowed in the cryptocurrency script. An expiration date may be specified in optional information 950, and a transferee destination, such as a donation destination, may be specified in destination information 960, which may or may not form part of transaction 920. Dedicated wallet applications described herein may be configured to perform automated transfers to transferee addresses upon limit / VCUR and expiration. This transaction 920 using EVC may enable automated transfers, such as a donation of the expired amount of the EVC to a designated transferee, such as a charity. In the example of FIG. 10, if the expiration date is August 1, 2020 and the transferee's destination is Red Cross®, the EVC may be automatically transferred to a Red Cross® wallet if the EVC is not spent before August 1, 2020. In some embodiments, the EVC reverts to regular cryptocurrency with no VCUR upon first use, either before or after expiration. If the EVC was sent to an address other than an EVC wallet, or if the EVC was sent to an automatic destination due to expiration, the recipient will spend the amount received in their regular cryptocurrency wallet, and therefore there is no restriction on the expiration date or destination, and therefore the recipient may send standard cryptocurrency.

[0168] 11A is a block diagram illustrating the use of a predefined set of EVC recipients to which an EVC can be transferred. In a typical cryptocurrency transaction 920', a first person 1105 directs a transfer of funds from their own cryptocurrency wallet to a second person 1110. This transaction is recorded in the blockchain ledger 1120 and shared among the blockchain peers.

[0169] In a system 1130 using EVC (local coin), a management entity (issuer) 1152 provides an EVC to a user (EVC receiver) 1154, who may use the EVC within the scope of the VCUR, such as an expiration date. The issuer 1152 establishes a usage limit (VCUR) for the virtual currency to make it an EVC. The issuer 1152 may utilize an issuer device, such as a DPS 10, in performing the process described herein. The issuer 1152 may issue the original EVC on, for example, a decentralized peer-to-peer network with high robustness provided by a virtual currency blockchain, which allows the construction of a VCUR, such as a VCUR that defines an internal receiver 1156 that is a member of a predefined set 1140 of EVC receivers (e.g., an economic zone (regional economic zone)), such that the circulation range of the EVC or the set of internal receivers 1156 is limited within the predefined set 1140 of EVC receivers. An internal recipient 1156 is a recipient that may receive an EVC and use the EVC in a VCUR. In some embodiments, if an EVC recipient 1154 uses an EVC with an internal recipient 1156 (i.e., a recipient in a predefined set of EVC recipients 1140, such as a local economy that has an EVC-enabled wallet) before the EVC expires, the EVC loses their restricted characteristics (from the VCUR) and may be used as regular virtual currency by the internal recipient 1156. In other embodiments, if an EVC recipient 1154 uses an EVC with an internal recipient 1156 before the EVC expires, the EVC retains their restricted characteristics (from the VCUR) and may be used as an EVC by the internal recipient 1156. Any expired unused EVC may be utilized in a transfer to a pre-designated assignee 1147, such as a donation to a charity that has been pre-designated as a donation destination.

[0170] In some embodiments, the issuer 1152 distributes exclusive wallets to EVC recipients 1154 and other internal recipients 1156 and issues transactions with expiration dates to remittance partners at addresses corresponding to the exclusive wallets. The EVC wallets can send money subject to the expiration date constraints set in the transactions addressed to the EVC wallet itself, and the constraint that the next destination is limited to the list resulting from the dedicated wallet specifications (Table 2). These expiration dates and destination restrictions constitute the VCURs imposed on recipients with their own wallets. The governing body 1152, the distributor of the EVC wallet, sets the expiration dates and defines the distribution list. The governing body 1152 is also the entity that imposes the VCURs. In some embodiments, outsiders cannot be subject to these VCURs. The realm of the predefined set of recipients 1150 may be considered as a network of users who have their own EVC wallets.

[0171] In some embodiments, a transferee 1147, such as a donation destination (hospital in FIG. 11B), may use EVC as a general virtual currency, in other words, as a virtual currency without VCUR (expired). The EVC receiver 1145 and transferee 1147 are included in the "EVC receiver destination list" (Table 2) and can be specified as a destination from a dedicated wallet, but in some embodiments, neither the EVC receiver 1145 nor the transferee 1147 has a dedicated EVC wallet.

[0172] In some embodiments, a recipient 1156 who receives an EVC before the expiration date cannot use the received amount as regular cryptocurrency. The EVC wallet sends the transaction as an EVC to "local" destinations described in the "EVC Recipient Destination List" (Table 2) and as regular cryptocurrency to "global" destinations. A VCUR is charged on the EVC received in the dedicated wallet. In addition, if the address of the recipient 1156's standard cryptocurrency wallet is defined in the "EVC Recipient Destination List" (Table 2), it is possible to send money from the dedicated wallet to that address, but this is not expected. This is because if the recipient 1156 sends the entire amount of the EVC with an expiration date to a standard cryptocurrency wallet that he owns, neither the definition of an economy nor the definition of an EVC wallet is meaningful. This provides a mechanism for sending money as "standard cryptocurrency" to "global" destinations in time, encouraging EVC owners to use their EVC in time.

[0173] In other embodiments, the issuer may provide a tiered VCUR that may be changeable each time an EVC is transferred. In an example embodiment, unused EVCs may contribute to stimulating charitable and social contributions in some implementations. When used in this manner, the owner of the EVC (the initial EVC recipient 1154) may receive a certificate of donation of the unused EVC as evidence that these EVC recipients 1154 are eligible for tax benefits. In some embodiments, one or more of the EVC recipient 1154, issuer 1152, and internal recipient 1156 may utilize an EVC wallet as a specialized application loaded onto a device such as the DPS 10.

[0174] The issuer 1152 may be the one who imposes the VCUR on the EVC, or in some embodiments, may impose additional VCURs on the EVC along with the existing VCUR. The VCUR may describe who the EVC may and may not be used by as part of a transaction using the EVC. This may be done by defining a predefined set of EVC recipients 1150 (including at least internal recipients 1156), and the EVC may be used with the predefined set of EVC recipients 1150 prior to expiration of the EVC. The EVC may not be used with recipients other than the predefined set of EVC recipients 1140 prior to expiration. The VCUR may be quite flexible in defining who / what is included in the predefined set of EVC recipients 1150 and who is not 1140. For example, the predefined set of EVC recipients 1150 may be defined by geographic boundaries. Such a definition may be, for example, a geographic fence (including discontinuous areas) and may include one or more countries, states, counties, cities, or any other definable area.

[0175] In some embodiments, such boundaries may apply to the residence or work of an internal recipient 1156 that is included in a predefined set of EVC recipients. As described elsewhere herein, in some embodiments, after the first use of the EVC by the original EVC recipient 1154 to the internal recipient 1156 before expiration, the internal recipient 1156 may not be used for other internal recipients 1156 without failure (VCUR).

[0176] Although the VCUR may include geophysical boundaries, this is only one type of restriction rule that may be applied. However, there are other types of restrictions or rules that may be applied as part of the VCUR in addition to or instead of geophysical boundaries. For example, the VCUR may be restricted to a company or its subsidiaries, a government agency, a type of business (e.g., green technology), a specific motive (e.g., fighting breast cancer), or any other definable entity. Thus, according to some embodiments, the VCUR may provide a means for building a local economic zone using the EVC built on the blockchain 1120. The VCUR may also provide a means for promoting the use of the EVC so that the EVC is used within the local economic zone or a predefined set of EVC recipients within the expiration date. The predefined set of EVC recipients may be built between specific participants / transferees using the cryptocurrency blockchain ledger 1120. The EVC (predefined date or transaction date + N days) may then be distributed within the local economic zone or a predefined set of EVC recipients. The EVC may be readable by a specialized wallet application for a particular predefined set of EVC recipients, such as EVC recipients in a local economic zone, and may be transacted on the blockchain only within the expiration date. In some embodiments, the EVC that has passed its expiration date may then be automatically transferred to a transferee 1147 (e.g., a charity) identified by the governing body / issuer 1152. In some embodiments, the transferee 1147 receives all of the virtual currency without any encumbrances (VCUR), while in other embodiments, some other VCUR may accompany the virtual currency. Such additional VCUR may be any or all of the VCURs described herein, except that the same expiration date should not be used since the expiration date has already expired. By using a virtual currency blockchain ledger such as a virtual currency ledger 1120, transactions can be performed using an existing blockchain ledger, thus eliminating the need to build a new original blockchain.

[0177] Various embodiments disclosed herein advantageously allow for effective and efficient use of countermeasure costs, funding, etc., by large organizations, such as large corporations or countries, within a particular time period. Even if the EVC expires, proof of the transfer, such as a donation, may be provided in the form of a receipt so that the person receiving the EVC may enjoy certain benefits, such as tax benefits, when the expiration triggers the transfer.

[0178] FIG. 11B is a block diagram similar to FIG. 11A but further illustrates an assignee 1147 to which unused EVCs may be automatically transferred upon expiration of the EVC (or according to either other VCURs, or both). In FIG. 11B, the assignee is a hospital 1147, which is designated in the VCUR of the EVC as the recipient of the EVC resulting from the EVC having expired. Upon receipt of the transfer, the hospital 1147 may issue a receipt of the transfer to the holder of the original EVC recipient 1154. If the transfer is designated as a donation, the receipt may be in the form of a proof of donation. Such a receipt may be utilized, for example, for record-keeping, tax returns, and the like.

[0179] 12 is a flow chart illustrating a process 1200 for implementing some embodiments of a system used by an entity / issuer 1152 in creating and distributing EVCs. At operation 1205, the system receives and processes instructions by the issuer 1152 to then raise "standard" virtual currency as funds to be used as EVCs. At operation 1210, an account list is created. This operation may include generating private keys, public keys, and virtual currency addresses for each user identified by the issuer 1152. The following table illustrates what such an account list might look like:

[0180] [Table 2] Table 1 Example Account List

[0181] The issuer 1152 may manage users who may be recipients (internal recipients 1156 and transferees 1147) from the EVC recipient 1154, in addition to the users to whom the EVC is initially distributed (EVC recipients 1154). The designation of a user as local (i.e., internal recipient 1156) means that the user is a participant in a predefined set of EVC recipients 1150, such as a participant in a local economic zone. The designation of a user as global means that the user is a designated account outside the set of recipients 1140, such as being outside the local economic zone. As an example, to restrict the use of medical financial assistance, hospitals and / or pharmacies may participate as global accounts, and to promote circulation within a corporate group, specific stores may be designated. Upon receipt of the information from the issuer 1152, the system may set up an appropriate storage area to structure and store this information, including a specialized EVC wallet application that may be distributed to the user of the EVC (or more specifically, the user device, which may be the DSP 10).

[0182] At operation 1215, a destination list containing the addresses is created. This list may look similar to the account list in Table 1, except that the private keys are omitted. Table 2 below shows an example of an EVC recipient destination list.

[0183] [Table 3] Table 2 Example EVC Recipient Destination List

[0184] At operation 1220, a destination list for the assignees 1147, such as a donation destination list, is created, formatted, and stored in memory of the system and / or each device in the system by the issuer 1152. The assignee destination list may specify the entities that will receive unused EVCs upon expiration of the EVCs. In some embodiments, the assignee destination list may allow for entry of a ratio or percentage of expired EVCs that each assignee will receive. Table 3 below shows an example of a recipient (e.g., donation) destination list and the forwarding percentages to which unused expired EVCs will be automatically forwarded upon expiration.

[0185] [Table 4] Table 3 Exemplary Assignee Recipient List

[0186] In operation 1225, in some embodiments, the issuer 1152 creates, formats, and stores the expiration factor in the memory of the system and / or each device in the system. In some embodiments, according to one exemplary way to do this, the expiration factor sets a value N as the number of days past the current (issue) date as the expiration date per transaction. For example, if the creation / issue date of the EVC is October 14, 2020, and N is set to 5, the expiration date will be October 19, 2020. In other words, N may act as a time delta value from the creation of the EVC. In addition to the creation date of the EVC, other events may act as triggers. For example, the Easter holiday, which changes every year, may act as an expiration trigger. In other embodiments, a fixed date may be set that does not change based on the creation date of the EVC. The trigger need not be based on time, but may be based on an event. As an example, the trigger may be based on an event defined as seasonal rainfall exceeding a certain amount. More complex rules for triggering may be implemented, for example using Boolean logic. For example, a trigger may be "first occurrence of seasonal rainfall = 20 cm and August 15, 2020." A trigger event may be any type of event, such as a time-related event, weather condition, economic or business performance state, etc.

[0187] At operation 1230, a transaction may be issued to pay the EVC to an address that is on a distribution list and within a predefined set of EVC recipients, such as an economy. As an example, a transaction 920 may be created where transaction input 930 indicates an issuer with 20 VCU and transaction output 940 indicates Alice with 19.95 VCU and a fee of 0.05 VCU. Within optional information 950 of transaction 920, an expiration date of March 8, 2021 at 10:00 AM may be specified. This optional information may be written to the OP_RETURN field (80 bytes) specific to standard cryptocurrencies, and this information may include the expiration date, as well as optionally the time and identification information of the EVC (e.g., LOCAL_VCU_20201910). With this information, the EVC has a balance with an expiration date set at the time of its distribution. The 80 byte limit of OP_RETURN for some cryptocurrencies limits the amount of information that can be passed in the transaction data and metadata tabulated herein is passed using an EVC wallet application, but other blockchains may be able to accommodate even larger optional data sizes that allow some or all of the tabular data or other VCUR to be passed within the transaction itself.

[0188] In some embodiments, the value N may change for each address in operation 1230 when the issuer 1152 issues the EVC to a destination address of the EVC wallet. However, the value N may not change independently when sending the EVC from the destination EVC wallet address (1154, 1156). It is assumed that one of the following may be set as the expiration time within a transaction that sends an EVC from a destination EVC wallet address (1154, 1156): Current (payment execution) date + number of days N The date originally specified by the governing body when issuing the EVC

[0189] In the former, the expiration date may be extended with each transaction, while in the latter, the expiration date remains unchanged from the time of issue.

[0190] In operation 1235, the system sets its "own" address and key into each EVC wallet application that is distributed. For example, Alice's EVC wallet application may be set to Address:XXX, Private Key:111, and Public Key:xxx. Bob's EVC wallet application may be set to Address:YYY, Private Key:222, and Public Key:yyy. This information is built into the EVC wallet, but need not be disclosed to users of the EVC wallet.

[0191] At operation 1240, the EVC wallet application containing the particular user's information may be distributed to each user, such as the EVC recipient 1154 of each wallet (or EVC wallet application).

[0192] 13A and 13B include a flow chart of a process that may be utilized by the EVC Receiver 1154 via an EVC Wallet application on the EVC Receiver's device. In a process 1300 of obtaining relevant information, the EVC Receiver 1154 may receive a destination list, such as the EVC Receiver Destination List shown in Table 2. In operation 1302, the EVC Receiver Destination List may be obtained by the EVC Receiver 1154, along with the expiration factor (N) as described above in operation 1304. Other structures of data may be used to convey the same or similar data to the EVC Receiver 1154, such as passing information using standard cryptocurrency functions. Through communication between the EVC Wallet and a server system, without going through the blockchain, a "get destination list" may be obtained, and the value N may be obtained. This information may be obtained by obtaining it from the server system at the time of activating the EVC Wallet or at regular intervals during activation.

[0193] At operation 1312 of the balance presentation (to EVC Recipient 1154) process 1310, unspent EVC transactions addressed to the EVC Recipient 1154 are retrieved from the blockchain. For example, it may be determined that Alice, as an EVC Recipient, has 20 VCUs as an EVC (EVCTC). At operation 1314, a determination may be made as to whether there are any current unspent EVC transactions addressed to the EVC Recipient 1154. If there are not (1314, no), the balance is 0, as shown in block 1315, and processing proceeds to operation 1318. If there are (1314, yes), at operation 1316, the system determines the amount of EVCTCs that have not yet expired. At operation 1318, the amount of unexpired EVCTCs is presented as the balance. In this example, 15 of Alice's EVCTCs are not expired, so they are presented as Alice's balance. A determination of whether a transaction 920 is addressed to an EVC recipient address may be made based on the transaction output 940 of each transaction 920 that includes an EVC recipient 1154. A determination of whether a transaction 920 is a transaction that includes an original EVC may be made based on the description (identifier and expiration time) in the OP_RETURN in the optional information 950.

[0194] FIG. 13B continues with various processes that may be utilized by the EVC recipient 1154. Process 1320 illustrates a payment using an EVC. At operation 1322, the EVC recipient 1154 may select an internal recipient 1156, for example, by selecting a destination address from an EVC recipient destination list using the EVC recipient's 1154 EVC wallet application. With reference to Table 2 above, the EVC recipient 1154 (Alice) may select Bob as the internal recipient 1156 (i.e., the person who will receive the EVC payment). At operation 1324, the EVC recipient 1154 may indicate a payment amount (e.g., 1 VCU) to be paid to the internal recipient (Bob) 1156. At operation 1326, the wallet application of the EVC recipient 1154 checks to see if the balance in the EVC recipient's wallet is adequate to make the payment. If not (operation 1326, "no"), the process ends and, in some embodiments, an indication of the unsuitability (such as a message displayed on the screen of the user's device) may be presented to the EVC recipient 1154. If not (operation 1326, "yes"), at operation 1328, the wallet application of the EVC recipient 1154 issues a payment transaction addressed to the internal recipient (Bob) 1156.

[0195] Transaction 920 in FIG. 13B illustrates an example transaction that may take place. As transaction input 930, the address of the EVC recipient indicates the balance of the EVC recipient (Alice). As transaction output 940, the destination (internal recipient 1156) address and the payment amount (e.g., minus mining fees, as described above) are shown. OP_Return 950 may include an identification and an expiration date (e.g., the current date plus N days). The identification may be provided to identify the EVC for transaction tracking and aggregation purposes, but may or may not be actually used. In some embodiments, EVCs may only be sent to dedicated EVC wallets, and thus the EVC wallet only needs to identify transactions going to the EVC wallet's address to determine if the transaction is an EVC.

[0196] A determination may be made based on the transaction output 940 of each transaction 920 as to whether the transaction is addressed to an internal recipient 1156 address. A determination may be made as to whether the transaction 920 is a transaction that includes the original EVC based on the description (identifier and expiration date) in the OP_RETURN 950. If the destination is other than a dedicated wallet (i.e., a transaction with a "global, external" party in the "EVC Recipient Destination List" (Table 2)), the EVC may be usable as a regular standard cryptocurrency.

[0197] Process 1330 illustrates receipt of an EVC transaction and its use by an internal recipient 1156 or transferee 1147. Process 1330 describes a process by which the recipient displays the information needed to send the EVC to the sender (destination address, amount). In some embodiments, the EVC wallet may display and read a quick response (QR) code. For use by these latter two entities (1156, 1147), the VCUR is removed and the EVC is converted to standard virtual currency that may be used to make purchases at external recipients 1145, such as stores.

[0198] FIG. 14 is a flow chart illustrating a process 1400 for automatic payments to a grantee 1147, such as a grantee (e.g., the hospital shown in the drawing). Each EVC wallet application may maintain an expiration date for the EVC set within each unspent transaction (i.e., the transaction that constitutes the balance of the EVC wallet application). The wallet application may automatically initiate an automatic payment upon expiration. Expired balances may then be distributed according to a VCUR, such as a pre-set ratio, to the automatic donation destinations.

[0199] At operation 1405, the EVC wallet application may obtain the destination of the transferee 1147 (e.g., the grantee) and the ratio of the various transferees 1147, if there is one (or in other words, if a single transferee gets 100% of the transfer). This information may be provided, for example, in the form of Table 3 above. At operation 1410, the EVC wallet application may retrieve EVC transactions from the blockchain that are addressed to the EVC recipient 1154. At operation 1415, if no such EVC transactions exist (1415-No), the process ends. If there are (1415-Yes), at operation 1420, the EVC wallet application may add the amount of the EVC transaction for those EVC transactions that have passed their expiration date.

[0200] Next, in operation 1425, the EVC wallet application may automatically issue a transaction according to the destination of the assignee 1147 in the assignee destination list (e.g., Table 3). Transaction 920 shown in FIG. 14 illustrates this transaction, where the EVC recipient 1154 is listed in the transaction input 930 description, and the destination address of the assignee (e.g., the donee) and each payment amount are listed in the transaction output 940 description. In this embodiment, the optional information 950 is not listed in OP_RETURN, and the transaction is usable as regular cryptocurrency at the destination of the assignee 1147. For the assignee destination list presented in Table 3, when the expired balance is 1000, a payment of 800 is made to the assignee destination organization AA, and a payment of 200 is made to the assignee destination organization BB.

[0201] At operation 1430, the transaction ID of the automatic payment to the transferee 1147 may be recorded and a notice (e.g., in the form of a transfer receipt) may be sent back to the EVC Receiver 1154 (the owner of the EVC wallet). A record of the automatic payment may be presented to the EVC Receiver 1154 and output in a predefined format. The transaction ID may be used to search for the transaction in the cryptocurrency blockchain, such as by using a blockchain explorer, and then output for display or other use.

[0202] 15A and 15B are portions of a combined block and process diagram illustrating the components and the interaction of these components to operate the system, using numerical reference directions to the processes and operations described above. As shown in FIG. 15A, an issuer 1152 may raise standard virtual currency and convert it to an EVC (operation 1510 (1205)). The leftmost transaction 920, with nothing in the transaction input 930 column, shows, by way of example, that the issuer 1152 takes 1000 virtual currency and converts it to 1000 EVC. The setting of these EVCs as VCUR is shown in block 1515. In operations 1520 (1210-1235), the generation of a basic input address may be performed, in which Alice, Bob, and Joe are designated as EVC recipients 1154. The EVC is set to expire N=15 days after the issuance of the EVC.

[0203] Act 1530 (1240) involves the actual distribution of the EVC to each of the EVC wallets 1525 of the EVC recipients 1154 (Alice, Bob, and Joe). The right-most transaction 920 shows the issuer 1152 distributing 1000 EVC (transaction input 930) 500 to Alice, 300 to Bob, and 200 to Joe as EVC recipients 1154. Service fees that may be present in the transaction are not shown for simplicity.

[0204] Referring to FIG. 15B, in operation 1540 (1320), a transaction occurs between EVC receiver 1153 (Joe) and internal receiver 1156 (Alice). Joe transfers 150 EVC to Alice, who has an existing balance of 650 in her EVC wallet. The left-most transaction 920 shows Joe with 200 EVC in transaction input 930, and transaction output 940 shows Alice with 150 EVC and Joe with 50 EVC, both with an expiration date of September 23rd.

[0205] In action 1550 (1400), the expiration of a portion of the EVC triggers an automatic transfer from the EVC receiver 1154 to the transferee 1147. Today's date for the action of transfer 1550 is September 20th. The automatic transfer to the transferee 1147 occurs because the EVC receiver 1154 has the EVC in her wallet, and 500 EVC in that wallet have expired and 150 have not expired. In the transfer 1550 shown, the transferee 1147 is the hospital. The right-most transaction 920 illustrates this automatic transfer, with Alice's 500 EVC (the expired EVC) shown as a transaction input 930 and transaction output 940 showing the result of the automatic transfer to the transferee. The 150 EVC amount remains in Alice's wallet until it expires at a later date. Action 1560 (1440) simply indicates that a certificate, such as a receipt or other form of acknowledgement for the automated transfer, may be provided (1565) to the EVC recipient 1154 (Alice) so that Alice has a record of the transfer of the EVC. The transaction between Joe and Alice occurs between dedicated EVC wallets, and the 150 EVC paid to Alice has an expiration date.

[0206] Technical Applications Thus, one or more embodiments disclosed herein provide improvements to computer technology. For example, improvements to digital transaction ledgers and the additional flexibility to data and transactions that digital transaction ledgers support allow for more efficient and effective documentation of computer transactions, including greater flexibility and security. One technical problem solved herein is that certain usage rules may not fit within the transaction data itself. As used herein, a standard virtual currency transaction allows for 80 bytes for optional data, but a complex VCUR does not fit within that limited space. Nevertheless, the inclusion of a partial VCUR within this limited optional data allows the virtual currency to be recognized as an EVC. The utilization of out-of-band communication for the remaining portion of the VCUR advantageously allows for a much more complex VCUR to be applied to the EVC than would otherwise be possible.

[0207] Computer-Readable Medium The present invention may be a system, method, and / or computer readable medium at any possible level of technical detail of integration. A computer program product may include a computer readable storage medium containing computer readable program instructions for causing a processor to perform aspects of the present invention.

[0208] A computer readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge structures in grooves on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not itself be construed as a transitory signal, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0209] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to each computing device / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof) that may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing device / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage on a computer readable storage medium within each computing device / processing device.

[0210] The computer readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions to customize the electronic circuitry by utilizing state information of the computer readable program instructions.

[0211] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks included in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0212] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / operations specified in the blocks of the flowcharts and / or block diagrams. These computer readable program instructions may be stored on a computer readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions for performing aspects of the functions / operations specified in the blocks of the flowcharts and / or block diagrams.

[0213] Computer readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in the blocks of the flowcharts and / or block diagrams, thereby causing a series of operable steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process.

[0214] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may occur in a different order than that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously or in reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flowchart illustrations, as well as combinations of blocks included in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

Claims

1. 1. A computer-implemented method including using a processor of an Expired Virtual Currency (EVC) wallet user device, the processor comprising: Retrieving an EVC transaction associated with the blockchain and addressed to an address associated with the EVC wallet, the transaction including an expiration date for the EVC; determining whether the expiration date of the EVC in the EVC transaction has passed; and automatically transferring the EVC to a transferee specified in Virtual Currency User Rules (VCUR) without user intervention based on a first condition that the expiration date has passed; The computer-implemented method, wherein the EVC is subject to the VCUR, of which the expiration date is included as a part.

2. obtaining the assignee from an assignee destination list; The computer-implemented method of claim 1 , wherein the EVC is transferred to the transferee as virtual currency without the VCUR.

3. 3. The computer-implemented method of claim 2, wherein the assignee distribution list is received out-of-band from a normal blockchain transaction.

4. The computer-implemented method of claim 1 , further comprising receiving a receipt of the transfer of the EVC to the transferee.

5. 2. The computer-implemented method of claim 1 , wherein the expiration time is stored in an optional information field of the EVC transaction recorded on the blockchain.

6. The computer-implemented method of claim 1 , wherein the expiration date is a number of days after creation of the EVC transaction.

7. The assignee includes a plurality of assignees, each of which indicates a portion of the EVC that each of the assignees will receive; The method further comprising: The computer-implemented method of claim 1 , further comprising: forwarding each portion of the EVC to a respective assignee corresponding to the indicated portion.

8. obtaining an EVC recipient destination list defining a predefined set of recipients to which the EVC may be forwarded by an EVC user, the EVC recipient destination list forming part of the VCUR; 2. The computer-implemented method of claim 1, further comprising: forwarding the EVC to a recipient of the predefined set of recipients in the VCUR based on a second condition that the expiration date has not passed.

9. and obtaining the recipient from the EVC recipient destination list; 10. The computer-implemented method of claim 8, wherein the EVC is transferred to the recipient as virtual currency along with the VCUR.

10. receiving a destination address of a recipient selected from the EVC recipient destination list; Receiving an entered payment amount; making a sufficiency determination that the EVC wallet contains an EVC balance equal to or greater than the entered amount; 10. The computer-implemented method of claim 8, further comprising: in response to the sufficiency determination being true, transferring the entered payment amount from the EVC wallet to the recipient.

11. The computer-implemented method of claim 10 , wherein the transfer of the entered payment amount is transferred without the VCUR.

12. Memory, and a processor, the processor comprising: Retrieving an EVC transaction associated with the blockchain and addressed to an address associated with the EVC wallet, the transaction including an expiration date for the EVC; determining whether the expiration date of the EVC in the EVC transaction has passed; and automatically transferring the EVC to a transferee specified in Virtual Currency User Rules (VCUR) without user intervention based on a first condition that the expiration date has passed; An expiring virtual currency (EVC) device, wherein the EVC is subject to the VCUR, the expiry date of which is included as part of the EVC.

13. The processor, further configured to obtain the assignee from an assignee destination list; The expiring virtual currency (EVC) device of claim 12 , wherein the EVC is transferred to the transferee as virtual currency without the VCUR.

14. The processor, obtaining an EVC recipient destination list defining a predefined set of recipients to which the EVC may be forwarded by an EVC user, the EVC recipient destination list forming part of the VCUR; 14. The expiry virtual currency (EVC) device of claim 13, further configured to: transfer the EVC to a recipient among the set of recipients predefined in the VCUR based on a second condition that the expiration date has not passed.

15. A computer program product causing a computer to carry out the method according to any one of claims 1 to 11.

16. 1. A time-limited virtual currency (EVC) system comprising an EVC issuer device, the EVC issuer device comprising: Memory, and a processor, the processor comprising: creating an account list including a plurality of account records, each of which includes an EVC recipient identifier, a private key, a public key, a virtual currency address, and an indicator as to whether the EVC recipient associated with the EVC recipient identifier is included or not included in a predefined set of EVC recipients, each of which corresponds to a plurality of EVC recipients; creating an EVC recipient destination list including a plurality of destination records, each of the destination records including the EVC recipient identifier, the public key, the virtual currency address, and an indicator as to whether the EVC recipient is included or not included in a predefined set of EVC recipients; Creating a value associated with an expiration time of the EVC; establishing an EVC recipient address and a security key for each of a plurality of EVC wallets used to hold the EVC of the EVC recipient; and distributing each of the EVC wallets to each of the EVC recipients.

17. The processor of the EVC issuer device, receiving a destination address of a recipient selected from the EVC recipient destination list; Receiving an entered payment amount; making a sufficiency determination that the EVC wallet contains an EVC balance equal to or greater than the entered amount; 17. The EVC system of claim 16, further configured to: in response to the determination of sufficiency being true, transfer the entered payment amount from the EVC wallet to the recipient.

18. 20. The EVC system of claim 17, further configured such that the transfer of the entered payment amount is transferred without Virtual Currency User Rules (VCUR).

19. The processor of the EVC issuer device, Raising initial cryptocurrency, 17. The expiring virtual currency (EVC) system of claim 16, further configured to: issue a transaction for an EVC recipient by creating a transaction using the initial virtual currency by including an amount and the value associated with the expiration date.

20. each of the plurality of account records includes an EVC recipient identifier, a private key, a public key, and a virtual currency address; a processor of the EVC issuer device, 17. The expiring virtual currency (EVC) system of claim 16, further configured to create an assignee destination list including a plurality of assignee destination records, each of the assignee destination records including an assignee destination identifier and a virtual currency address.

21. The transferee destination list includes a plurality of transferees, each of which indicates a portion of the EVC that the transferee will receive; 21. The expiring virtual currency (EVC) system of claim 20, wherein the processor of the EVC issuer device is further configured to transfer each portion of the EVC to each transferee corresponding to the indicated portion.

22. 1. A computer-implemented method comprising using a processor of an Expiry Virtual Currency (EVC) issuer device, the processor comprising: creating an account list including a plurality of account records, each of which includes an EVC recipient identifier, a private key, a public key, a virtual currency address, and an indicator as to whether the EVC recipient associated with the EVC recipient identifier is included or not included in a predefined set of EVC recipients, each of which corresponds to a plurality of EVC recipients; creating an EVC recipient destination list including a plurality of destination records, each of the destination records including the EVC recipient identifier, the public key, the virtual currency address, and an indicator as to whether the EVC recipient is included or not included in a predefined set of EVC recipients; Creating a value associated with an expiration time of the EVC; establishing an EVC recipient address and a security key for each of a plurality of EVC wallets used to hold the EVC of the EVC recipient; and distributing said each of said EVC wallets to said respective EVC recipients.

23. Raising initial cryptocurrency, 23. The computer-implemented method of claim 22, further comprising: issuing a transaction for an EVC recipient by creating a transaction using the initial virtual currency by including the value associated with an amount and the expiration date.

24. 23. The computer-implemented method of claim 22, further comprising creating an assignee destination list including a plurality of assignee destination records, each of the assignee destination records including an assignee destination identifier and a virtual currency address.

25. The computer-implemented method of claim 24, wherein the transferee destination list includes a plurality of transferees, each of the plurality of transferees being associated with a percentage or proportion of an amount of EVC associated with the transfer.

Images