WO2019097279A1

WO2019097279A1 - Virtual currency implementation based on digital files

Info

Publication number: WO2019097279A1
Application number: PCT/IB2017/057193
Authority: WO
Inventors: Zakirov LENAR; Nutfullin TIMUR; Leonid AFANASYEV
Original assignee: Crown Capital Group
Priority date: 2017-11-17
Filing date: 2017-11-17
Publication date: 2019-05-23

Abstract

Method and system embodiments operate on a digital file representing a virtual currency amount. The digital files can be transmitted from a first device to a second device to transfer the virtual currency amount. Further, the data stored in the digital file can be converted into audio data that can be played by a speaker to the second device to transfer the virtual currency amount.

Description

VIRTUAL CURRENCY IMPLEMENTATION BASED ON DIGITAL FILES

FIELD OF THE DISCLOSURE

[0001] This application relates generally to blockchain technology.

BACKGROUND OF THE DISCLOSURE

[0002] The use of virtual currencies or cryptocurrencies, such as Bitcoin™ (BTC), has risen in the past few years. The transactions related to the virtual currencies are generally verified by a distributed network of verification nodes in a peer-to-peer (P2P) system and recorded in a public leger called a blockchain. Each virtual currency (with its own digital currency unit) on the market today has its own version of the blockchain. Existing virtual currencies include: Bitcoin™, Auroracoin™, BlackCoin™, Coinye™, Dogecoin™, Litecoin™, Mastercoin™, MazaCoin™, Monero™, Namecoin™, Nxt™, Peercoin™, PotCoin™, Primecoin™, Ripple™, Titcoin™, Zerocoin™, etc.

[0003] In general, a transaction recorded in the blockchain can include information that identifies a payer A that transmits a B amount of the virtual currency to a payee C. Upon verifying the transaction, the virtual currency of amount B is effectively transferred from payer A’s digital wallet to payee C’s digital wallet. A verified transaction can be added to a block including a plurality of transactions. A verification node can be configured to hash a block before transmitting the block to other verification nodes that each validates the plurality of transactions in the block before adding the block to their copy of the blockchain. New blockchain additions may be broadcasted to verification nodes. Current blockchain is the only location where virtual currencies exist in the form of unspent outputs of transactions.

[0004] In traditional blockchain implementations, each transaction includes a specific address associated with a digital wallet of the payer and a specific address associated with a digital wallet of the payee. Accordingly, each copy of the blockchain at a verification node can independently verify a chain of ownership of virtual currency from digital wallet to digital wallet. To conduct a transaction, a payer must digitally sign the transaction using a private key associated with his digital wallet. Therefore, current virtual currency systems require that each user maintain his or her digital wallet. Further, since current blockchain can be publically accessed, the transactions associated with a specific digital wallet can be traced. Moreover, current virtual currencies exist only as a combination of transaction outputs stored in the blockchain.

SUMMARY OF THE DISCLOSURE

[0005] As discussed above, current blockchain implementations rely on digital wallets to track and manage virtual currency owned by different users. Digital wallets are associated with addresses, i.e., identifiers, used to transfer and receive virtual currencies in transactions. Since all such transactions are recorded in the blockchain, the addresses associated with each digital wallet can be traced and may be used to identify specific users of that digital wallet. Therefore, a technical problem arises in blockchain technology in which to maintain an electronic distributed ledger to enable usage of virtual currencies, current blockchain implementations require that users give up private information to register for digital wallets.

[0006] To maintain the advantages provided by blockchain without requiring users to give up their privacy and register for digital wallets, embodiments described herein describe a technical solution that creates and maintains a completely new data structure. In particular, embodiments create a digital file that itself represents a specific virtual currency amount, without storing any addresses or IDs that identifies the user. Instead of storing addresses to associate with specific users, the digital file stores a specific virtual currency amount and a private key that can be used to certify a right of ownership of that digital file. Therefore, possession of the digital file itself enables the user to possess an amount of the virtual currency. Additionally, since the digital file stores no information identifying the user, embodiments described herein do not require the user to register and create electronic wallets to access virtual currency. Users can receive and transmit the digital file— as if the user possessed a paper bill.

[0007] As a result, virtual currency can be exchanged between users by transmitting the digital file to other users via a variety of communication channels, e.g., email, or social media. Additionally, the digital file can be stored on a variety of computer-readable medium such as a DVD, a CD, a thumb drive, a portable drive, etc. that can be physically handed to another user to transmit virtual currency. In some embodiments, the digital file can be encrypted to prevent unauthorized users from accessing the stored virtual currency amount.

[0008] To provide further flexibility in the means by which virtual currency stored in the digital file can be transmitted, embodiments described herein convert the data in the digital file to audio information for storage in an audio file. By storing virtual currency as audio information, a user operating a first user device can play audio signals in the audio file to a second device capable of recording audio to effectively transmit an amount of the virtual currency to the second device. Further, the audio information in the audio file can be stored in a variety of mediums for storing audio such as a DVD, a CD, a cassette tape, a vinyl record, in addition to computer readable media as described above.

[0009] Current virtual currencies implement a proof-of-work scheme to verify blocks. Proof- of-work schemes are known to have many significant drawbacks. In particular, new virtual currencies can be generated by solving computationally intensive cryptographic problems based on hashing a block to be verified. While hashing the block is itself a fast computational process, the proof-of-work scheme requires that before the verification node transmits the block, the verification node needs to generate a hash value having specified properties, which is much more computationally intensive. When a block is successfully hashed to meet the specified properties, the hashing must have taken some time and computational effort. Thus, a hashed block is considered proof of work. Due to the requirements of proof-of-work, the more transactions that are processed, the harder the cryptographic problems. Therefore, gigawatts of energy are currently being expended to verify transactions. Additionally, transactions may take longer and longer to be verified.

[0010] The cryptocurrency embodiments described herein also address the long latency and high-energy consumption of proof-of-work schemes by implementing an efficient proof-of-stake scheme that operates on the digital files described above. The technical solution of the proof-of- stake scheme and the digital files provide many advantages over traditional proof-of-work schemes. In particular, the current proof-of-stake scheme being contemplated is highly energy efficient because verification nodes do not need to burn gigawatts of energy while doing a resource-intensive mathematical hash selection to verify transactions. Instead, in the current proof-of-stake scheme, the verification nodes merely verify the transactions themselves, which incurs negligible processing load.

[0011] Moreover, due to the means by which verification nodes are selected to generate blocks to be verified, the proof-of-stake scheme being implemented has high integrity and is more resistant to attacks as compared to current proof-of-work schemes. This is because an attacker would need to possess more than 51 % of the virtual currency in the system to undermine the confidence of the verification network. By distributing the virtual currency among many users in the verification network, the likelihood that the attacker would possess 51% of the virtual currency may be further reduced to provide the technical effect of increased security.

[0012] In some embodiments, a method for operating digital files representative of virtual currency amounts includes: retrieving, at a first device, a first digital file including first data associated with a transaction that generated the first digital file, the first digital file representing an amount of a virtual currency assigned to the first digital file during a creation of the transaction; generating, at the first device, a second digital file based on the first digital file, the second digital file comprising audio data that represents the first data in the first digital file; and playing, via a speaker of the first device, the audio data in the second digital file to a second device to transfer the amount represented by the first digital file to the second device.

[0013] In some embodiments, the transaction is created by the first device.

[0014] In some embodiments, the method includes: encrypting the second digital file based on a password selected by a user; and before playing the audio data, requesting the user to enter the password to decrypt the second digital file.

[0015] In some embodiments, the first data includes: a secret key generated in the

transaction, a hash of the transaction, an index associated with the transaction and selected for the first digital file, and the amount. [0016] In some embodiments, generating the second digital file includes: generating a first audio signal based on the first data; generating a second audio signal based on the first data; and combining the first audio signal and the second audio signal data for storing in the second digital file.

[0017] In some embodiments, the first audio signal includes frequencies within a first range of frequencies and the second audio signal includes frequencies within a second range of frequencies different from the first range of frequencies.

[0018] In some embodiments, generating the second digital file includes: generating a first audio signal based on the first data; generating a second audio signal based on the first audios signal; and combining the first audio signal and the second audio signal for storing in the second digital file.

[0019] In some embodiments, the second audio signal includes the first audio signal shifted by a frequency amount and delayed by a predetermined time delay.

[0020] In some embodiments, generating the first audio signal includes: converting the first data into second data based on an alphabet having a plurality of alphanumeric characters;

computing a checksum of the second data; and combining a beginning marker, the second data, the checksum, and an end marker to generate third data, wherein the first audio signal is generated based on the third data.

[0021] In some embodiments, the beginning marker and the end marker correspond to a first and a second character, respectively, from the plurality of alphanumeric characters.

[0022] In some embodiments, the amount of the virtual currency is specified in the transaction, and wherein the transaction is stored in a blockchain.

[0023] In some embodiments, the first digital file includes a first secret key generated in the transaction, and wherein the second device is configured to receive the amount by using the first secret key to generate a second transaction for storage in the blockchain.

[0024] In some embodiments, the second transaction is added to a blockchain after a plurality of nodes verifies the second transaction based on a proof-of-stake scheme. [0025] In some embodiments, the method includes: selecting, by a first node from a plurality of nodes in a verification network, the second transaction to add to a block; verifying, by the first node, a validity of the second transaction before adding the second transaction to the block; transmitting, by the first node, the block to each other node in the plurality of nodes; verifying, at each other node, the block based on a copy of the blockchain stored at each node; receiving, by the first node, verification confirmations from a threshold number of nodes of the plurality of nodes; and upon receiving the verification confirmations from the threshold number of nodes, storing the block in the blockchain.

[0026] In some embodiments, a method includes: receiving, at a first device, first data in a first digital file from a second device, the first data being associated with a first transaction that generated the first digital file, the first digital file representing an amount of a virtual currency assigned to the first digital file during a creation of the first transaction; generating, at the first device, a second transaction to create a second digital file based on the first data in the first digital file to store the amount; transmitting, by the first device, the second transaction to a verification network to verify the second transaction for storage in a blockchain; receiving, at the first device, a result from the verification network, the result indicating that the second transaction is verified; and storing, by the first device, the second digital file in a memory at the first device in response to receiving the result.

[0027] In some embodiments, the first transaction is created by the second device.

[0028] In some embodiments, the second transaction includes a re-issue transaction that generates the second digital file to include the amount.

[0029] In some embodiments, the amount is a first amount, the second transaction is a combination transaction, and the method includes: combining the first amount with a third amount represented by a third digital file stored at the first device to generate a second amount for storing in the second digital file. [0030] In some embodiments, generating the second transaction includes: generating a secret key for the second digital file; computing a hash of the second transaction; and storing the secret key and the hash in the second digital file.

[0031] In some embodiments, receiving the first data includes: wirelessly receiving the first digital file from the second device.

[0032] In some embodiments, receiving the first data includes: receiving, via one or more speakers at the first device, audio played by the second device, wherein the audio represents the first data stored in the first digital file.

[0033] In some embodiments, the method includes extracting, from the audio, frequencies within a first range of frequencies to generate a first audio signal; extracting, from the audio, frequencies within a second range of frequencies to generate a second audio signal; generating a blended audio signal by combining the first audio signal with the second audio signal; and translating each symbol in the blended audio signal to recover the first data represented by the audio.

[0034] In some embodiments, each symbol is translated based on an alphabet having a plurality of alphanumeric characters.

[0035] In some embodiments, generating the first audio signal includes: determining a start of the first audio signal by identifying a first frequency from the frequencies within the first range of frequencies, wherein the first frequency represents a beginning marker; and determining an end of the first audio signal by identifying a second frequency from the frequencies within the first range of frequencies, wherein the second frequency represents an end marker.

[0036] In some embodiments, the first data includes a checksum, and the method includes: determining whether the first data includes one or more errors based on the checksum; and correcting the one or more errors based on the checksum when the one or more errors are detected.

[0037] In some embodiments, the amount of the virtual currency is specified in the first transaction, and wherein the first transaction is stored in the blockchain. [0038] In some embodiments, the first digital file includes a first secret key generated in the first transaction, and wherein the second transaction is generated based on the first secret key.

[0039] In some embodiments, the first digital file includes a first secret key generated in the first transaction, and generating the second transaction includes: generating a transaction input of the second transaction based on the first secret key, wherein the transaction input includes a signature of the second transaction generated using the secret key and includes a public key generated based on the first secret key, and wherein the second transaction is verified by a plurality of nodes in the verification network based on the signature and the public key.

[0040] In some embodiments, a plurality of nodes in the verification network verifies the second transaction based on a proof-of-stake scheme.

[0041] In some embodiments, the method includes: selecting, by a first node from a plurality of nodes in the verification network, the second transaction to add to a block; verifying, by the first node, a validity of the second transaction before adding the second transaction to the block; transmitting, by the first node, the block to each other node in the first plurality of nodes;

verifying, at each other node, the block based on a copy of the blockchain stored at each node; receiving, by the first node, verification confirmations from a threshold number of nodes of the plurality of nodes; and upon receiving the verification confirmations from the threshold number of nodes, storing the block in the blockchain.

[0042] In some embodiments, a system for performing the method of any of the above embodiments includes a first device having one or more processors, memory, and one or more programs stored in the memory and configured to be executed by the one or more processors.

[0043] In some embodiments, a non-transitory computer-readable storage medium includes instructions for performing the method of any of the above embodiments when the instructions are executed by a first device having one or more processors.

BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The foregoing summary, as well as the following detailed description of

embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, the drawings show example embodiments of the disclosure; the disclosure, however, is not limited to the specific methods and instrumentalities disclosed. In the drawings:

[0045] FIG. 1 illustrates a system that enables digital files to be used as currency, according to some embodiments;

[0046] FIG. 2 illustrates a diagram of a digital file formed from a transaction, according to some embodiments;

[0047] FIG. 3 illustrates a diagram showing how a transaction can be generated, according to some embodiments;

[0048] FIGS. 4A-C illustrate diagrams of different types of transactions, according to some embodiments;

[0049] FIG. 5 illustrates a diagram showing a block generated by a node, according to some embodiments;

[0050] FIG. 6 illustrates a diagram showing example blocks that comprise a blockchain, according to some embodiments;

[0051] FIG. 7 illustrates a method for using digital files as currency, according to some embodiments;

[0052] FIG. 8 illustrates a method for converting data in a digital file to audio signals for storage in a digital file having an audio file format, according to some embodiments;

[0053] FIG. 9 illustrates a method for extracting virtual currency information from audio, according to some embodiments;

[0054] FIG. 10 illustrates a method for verifying a block amongst a plurality of verification nodes, according to some embodiments;

[0055] FIGS. 11A-G illustrate example graphical user interfaces that enable a user to use digital files as currency, according to some embodiments; [0056] FIG. 12 illustrates an example of a computer in accordance with one embodiment.

DETAILED DESCRIPTION

[0057] Described herein are computer-readable storage mediums, systems, and methods for operating on a digital file storing an amount of a virtual currency. As discussed above, by creating the digital file storing specific data, the digital file can be used as virtual currency without requiring a user to give up personal information to register for a digital wallet. In fact, the embodiments described herein allow the user to transfer the digital file to another user as if it were physical currency. For example, the user can send the digital file to another user via email, social media, or through other digital communication channels. Additionally, the data in the digital file, stored in a first device, can be converted into audio data that can be played by a speaker on the first device to the second device to transfer the virtual currency amount to the second device. Therefore, the embodiments described herein enables user to more easily exchange virtual currency. As will be further described below, each digital file can be generated by a transaction stored in a blockchain, managed and verified by a plurality of nodes in a verification network. Additionally, the plurality of nodes can implement a proof-of-stake scheme, as opposed to a proof-of-work scheme used in today’s cryptocurrency systems, to improve the security and speed of verifying transactions.

[0058] FIG. 1 illustrates a system 100 that enables digital files to be used as currency, according to some embodiments. System 100 includes user devices 104A-B and a verification network 130 that are coupled to communication network 102. In some embodiments, verification network 130 includes a plurality of nodes 132A-D that accept and distribute transactions to cooperatively verify transactions generated by user devices 104A-B, as will be further described below. In some embodiments, each of nodes 132A-D includes one or more lists that identify each other node in verification network 130.

[0059] Communications network 102 may include a local area network (LAN), a wide area network (WAN), the Internet, a Wi-Fi network, a WiMAX network, a cellular network (e.g., 3G, 4G, 4G Long Term Evolution (LTE)), or a combination thereof. Further, communications network 102 may implement one or more wired and/or wireless standards or protocols.

[0060] In some embodiments, user devices 104A-B can be computing devices capable of storing digital files for usage as currency, as will be further described below. For example, user device 104A may be a desktop computer, a laptop computer, a tablet computer, a mobile device such as a smart phone, a smart watch, or the like. In some embodiments, user device 104A includes a memory 106 for storing one or more digital files 108A-B, each representing a specific amount of a virtual currency.

[0061] In some embodiments, to communicate with verification network 130 or other user devices, such as user device 104B, user device 104A can include a communication interface 114 for accessing one or more network circuitry on user device 104A. For example, communication interface 114 may enable user device 102A to utilize Wi-Fi, Ethernet, FTE, 3G, Bluetooth, among other wired or wireless communication protocols.

[0062] In some embodiments, to enable user device 104A to operate on digital files 108A-B as currency, user device 104A can install a client 120. In some embodiments, client 120 can include the following components: transaction (TXN) manager 122, user interface 124, file manager 126, and security component 128.

[0063] In some embodiments, file manager 126 can be configured to receive or transmit digital files such as digital files 108A-B via communication interface 114. For example, user A of user device 104A may want to transfer digital file 108 A (having a specific amount of virtual currency) to user B of user device 104B. To do so, file manager 126 may wirelessly transmit digital file 108A to user device 104B using, e.g., Bluetooth, an example communication protocol enabled by communication interface 114. Similarly, at a previous time, file manager 126 may have received digital file 108B from another user device, such as user device 104B, via communication interface 114.

[0064] In some embodiments, to facilitate an ease of transferring an amount of the virtual currency embedded in digital files, such as digital files 108A-B, file manager 126 can be configured to transmit and receive data in a digital file via speaker 110 and microphone 112, respectively. Therefore, user device 104A may not need to include communication interface 114 to receive or transmit information in a digital file. In some embodiments, digital file 108A may be an audio file of a specific audio file format. For example, audio file can be one of the following formats: WAV, AIFF, AU, FLAC, MPE3, 7C, MPEG-4, etc. To transmit data in digital file 108A to, for example, user device 104B, file manager 126 can be configured to play digital file 108A using speaker 110. User device 104B may include a microphone to receive the data of digital file 108 A.

[0065] In some embodiments, digital file 108B may not contain audio data, i.e., it is not in an audio file format. To transmit the data in digital file 108B via audio, file manager 126 can include audio generation logic configured to convert data in digital file 108B to audio signals for storage in a digital file that is in an audio file format. Then, like digital file 108A, file manager 126 may transmit the data in the converted digital file 108B via speaker 110.

[0066] In some embodiments, file manager 126 can be configured to receive data from digital file 105 via microphone 112. For example, microphone 112 may receive, from user device 104B, audio representing the data of digital file 105. In some embodiments, file manager 126 can include signal processing logic configured to extract the data from the audio. File manager 126 can be configured to store the extracted data in an audio file such as digital file 108B.

[0067] In some embodiments, by converting virtual currency information into audio data, the virtual currency information can be stored on other data storage mediums in addition to electronic devices capable of storing audio files, such as digital file 108B. For example, virtual currency can be stored on a CD, a DVD, a vinyl record, among other audio storage mediums.

[0068] In some embodiments, TXN manager 122 can be configured to generate transactions that operate on one or more digital files 108A-B. In some embodiments, as will be further described below, transactions can be of the following types: re-issue, division, or combination. For example, user device 104A may have received digital file 105 from user device 104B. In some embodiments, a re-issue transaction can be performed on the received digital file 105 to generate, for example, digital file 108A for storing in memory 106. By re-issuing the received digital file 105 as, for example, digital file 108A, user device 104B may no longer use its stored copy of digital file 105 as currency. In some embodiments, a division transaction can be performed on, for example, digital file 108A having a virtual currency amount to sub-divide the virtual currency amount into smaller denominations stored across two or more digital files. In some embodiments, a combination transaction can be performed on, for example, digital file 108A having a first virtual currency amount and digital file 108B having a second virtual currency amount to generate a new digital file having the first and second virtual currency amounts. For example, the new digital file may have a third virtual currency amount that sums the first and second currency amounts. In effect, the combination transaction may consolidate digital files with associated virtual currency amounts into a single digital file with an equivalent, higher virtual currency amount. In some embodiments, TXN manager 122 can store generated transactions in memory 106.

[0069] In some embodiments, TXN manager 122 can be configured to access communication network 102 to transmit a transaction to verification network 130. In some embodiments, TXN manager 122 can be configured to transmit the transaction to a specific node, such as node 132 A. In some embodiments, TXN manager 122 can be configured to query verification network 130 for a list of nodes and select a node, such as node 132A, to transmit the transaction.

[0070] In some embodiments, security component 128 can be configured to encrypt digital files 108A-B using one or more encryption algorithms to prevent unauthorized users from using digital files 108A-B as currency. In some embodiments, security component 128 can generate and store a private key for encrypting digital files 108A-B according to the one or more encryption algorithms. For example, digital files 108A-B may be encrypted with the AES-256 algorithm and verified for integrity by SHA-2 HMAC. Therefore, to access, for example, digital file 108 A stored in memory 106, an unauthorized user that merely copies digital file 108 A cannot operate on the encrypted data. In some embodiments, before TXN manager 122 can operate on encrypted digital files 108A-B, security component 128 can be configured to access the stored private key to decrypt digital files 108A-B. [0071] In some embodiments, to further enhance the security for using, for example, digital file 108 A as currency, security component 128 can be configured to enable the user to lock digital file 108A with a password (e.g., a pin) or a touch ID when digital file 108A is generated by TXN manager 122. In some embodiments, the password can be a static amount set by the user. In other embodiments, when digital file 108A is being generated by TXN manager 122, security component 128 can prompt the user to enter the password or the touch ID. In either case, when digital file 108A is accessed by TXN manager 122 to generate a transaction, security component 128 may prompt the user for the password or touch ID associated with digital file 108A before information in digital file 108A can be extracted. For example, the password or touch ID may be used by security component 128 to decrypt a secret key used to encrypt digital file 108A.

[0072] In some embodiments, to access client 120 to operate on digital files 108A-B, security component 128 can be configured to enable the user to use a password or touch ID to restrict access to client 120. Therefore, when the user wishes to access client 120, security component 128 may require the user to input the correct password or touch ID before granting the user access to client 120.

[0073] In some embodiments, user interface 124 can be configured to enable the user of user device 104A to operate on digital files 108A-B. For example, user interface 124 may enable the user to generate transactions via TXN manager 122. Additionally, user interface 124 may enable the user to access file manager 126 to choose how virtual currency is to be stored, i.e., in an audio format or not. Further, user interface 124 may enable the user to access security component 128 to lock and unlock access to one or more digital files 108A-B.

[0074] In some embodiments, verification network 130 can communicatively couple nodes 132A-D. For example, nodes 132A-D may communicate with each other using any type of network (e.g., a local area network (LAN), a wide area network (WAN), a virtual network, a telecommunications network) implemented as a wired network and/or wireless network. A node, such as node 132A, can be implemented using one or more computing devices, such as servers.

In some embodiments, nodes 132A-D can be implemented as a“cloud” where a network of remote servers are hosted over the Internet or on a private network that provides shared computer processing resources (e.g., computer networks, servers, data storage, applications, and services). For example, nodes 132A-D may be provisioned within a cloud computing service such as Amazon Web Services (AWS), IBM SmartCloud, Microsoft Azure, Google Cloud Platform, etc.

[0075] In some embodiments, to enable user devices 104A-B to use digital files 108A-B as currency, nodes 132A-D verify transactions and store them as part of blocks in a blockchain stored at each node. In some embodiments, nodes 132A-D verify transactions using a proof-of- stake scheme.

[0076] In some embodiments, node 132A includes processor 140 and memory 134. In some embodiments, memory 134 stores unconfirmed transactions (TXNs) 136 and a blockchain data store 138. As will be further described below, blockchain data store 138 can stored a plurality of linked blocks with each block storing one or more verified transactions. Processor 140 includes verification component 142 and committee selector 144.

[0077] In some embodiments, verification component 142 can be configured to process a transaction received from, for example, user device 104 A. Verification component 142 may verify the received transaction and store the received transaction in unconfirmed TXNs 136. In some embodiments, verification component 142 can be configured to select one or more transactions from unconfirmed TXNs 136 to form a block to be verified by each other node in verification network 130. In some embodiments, verification component 142 transmits the block to nodes 132B-D to be verified. If the other nodes 132B-D each verifies the block, verification component 142 can store the block in blockchain data store 138. In some embodiments, node 132 A may implement the functionality provided by client 120. For example, node 132 A may itself generate a transaction, as described with respect to TXN manager 122, based on a request from user device 104A.

[0078] In some embodiments, committee selector 144 can be configured to select a node from nodes 132A-D to generate the next block to be verified by each of nodes 132A-D. In some embodiments, for a predetermined period of time, committee selector 144 selects a committee 150 of nodes from which the node is to be selected. For example, committee selector 144 may select the committee 150 every 20 hours. In some embodiments, committee selector 144 selects committee 150 after a predetermined number of blocks, e.g., 600 blocks, have been generated. As shown in system 100, committee 150 may include nodes 132A and 132D.

[0079] FIG. 2 illustrates a diagram 200 of a digital file 202 formed from a transaction, according to some embodiments. In some embodiments, digital file 202 can be generated by a client (e.g., client 120) installed on a user device (e.g., user device 104A). In some embodiments, in contrast to traditional cryptocurrency implementations where virtual currency is associated with a user account (e.g., a wallet), digital file 202 includes data that store information that enables the file itself to be used as currency. In particular, digital file 202 stores information related to a transaction that generated digital file. As described with respect to FIG. 1 , digital file 202 can be a digital media file, according to some embodiments. For example, digital file 202 may be stored in an audio file format.

[0080] In some embodiments, digital file 202 includes the following data: secret key 204, a TXN hash 206, an index 208, and an amount 210. Secret key 204 can be a value generated in the transaction that generated digital file 202. TXN hash 206 can include the hash of the transition that generated the digital file 202. Index 208 can be the index of the output of the transaction that corresponds to digital file 202. Amount 210 can store an amount representing a virtual currency amount embodied by digital file 202. In some embodiments, where traditional cryptocurrency implementations include a user account associated with a secret key for accessing virtual currency associated with the user account, the current contemplated system may store secret key 204 within digital file 202 for accessing only amount 210 stored in digital file 202. Accordingly, a privacy of the user can be protected since digital file 202 stores no information identifying the user.

[0081] FIG. 3 illustrates a diagram 300 showing how a transaction 302 can be generated, according to some embodiments. In some embodiments, transaction 302 can be generated by a client (e.g., client 120) on a user device (e.g., user device 104A). In some embodiments, transaction 302 operates on one or more input files 304 to generate one or more output files 310. In some embodiments, each of input files 304 and output files 310 can be a digital file (e.g., digital file 202). For example, as shown in diagram 300, input files 304 includes digital file 342. Digital file 342 includes secret key 344, TXN hash 346, index 348, and amount 349, each of which may correspond to the similarly named components of digital file 202. For example, as shown in diagram 300, output files 310 includes digital file 352. Digital file 352 includes secret key 354, TXN hash 356, index 358, and amount 359, each of which may correspond to the similarly named components of digital file 202.

[0082] In some embodiments, the client generates transaction inputs 320 that correspond to input files 304. For example, the client may generate transaction input 320A based on digital file 342. As shown in diagram 300, transaction input 320A includes TXN hash 322, index 324, and amount 326 that store amounts of TXN hash 346, index 348, and amount 349 of digital file 342, respectively. In some embodiments, the client generates signature information 328 used by a node (e.g., node 132A) to verify transaction input 320A as being part of a previously-verified transaction corresponding to TXN hash 322.

[0083] In some embodiments, signature information includes data indicating signature 327 and public key 329. In some embodiments, signature information 328 includes data associated with program code for processing signature 327 and public key 329. Public key 329 can be generated by client based on secret key 344, according to a public-key signature system (e.g., an Elliptic Curve Digital Signature Algorithm (ECDSA) with a specific curve such as Curve255l9). In some embodiments, client can be configured to generate signature 327 by signing portions of transaction 302 based on secret key 344 of digital file 342. For example, signature 327 may be a signature generated by using secret key 342 to sign a hash of one or more portions of transaction 302. In some embodiments, the one or more portions used to generate signature 327 include data stored in transaction 302 excluding signature information 328 of each of transaction inputs 320. For example, the one or more portions used to generate signature 327 may include version 314, lock time 316, transaction inputs 320 (e.g., TXN hash 322 and index 324) and transaction outputs 330 (e.g., index 332, amount 334, and public key information 336). Accordingly, the client may sign portions of each of input files 304 based on each secret key 344 (corresponding to an input file) to generate corresponding signature 327 for each transaction input 320. In some embodiments, the client may generate signature information 328 based on an Ed255l9 public- key signature system.

[0084] In some embodiments, the client generates transaction outputs 330 that correspond to output files 310. For example, the client may generate digital file 352 including secret key 354, TXN hash 356, index 358, and amount 359, each of which corresponds to the similarly named components of digital file 202. TXN hash 356 can be a hash of the transaction, i.e., transaction hash 312, that generated digital file 352. Index 358 can indicate an index of a transaction from transaction outputs 330 corresponding to digital file 352. For example, index 358 may indicate an index of transaction output 330A. Amount 359 can indicate a virtual currency amount assigned to transaction output 330A corresponding to digital file 352. Amount 359 may be assigned based on an operation performed on input files 304 in transaction 302.

[0085] In some embodiments, to generate a transaction output 330A that corresponds to digital file 352, the client generates an index 332, an amount 334, and public key information 336 based on digital file 352. In some embodiments, index 332 and amount 334 store values of index 358 and amount 359, respectively. In some embodiments, public key information 336 includes data indicating a public key hash 337 that represents a hash of a public key generated based on secret key 354. In some embodiments, public key information 336 includes data associated with program code for processing public key hash 337. As discussed above, the public key may be generated by the client from secret key 352 using a public -key signature system (e.g., an Elliptic Curve Digital Signature Algorithm (ECDSA) with a specific curve such as Curve255l9).

[0086] In some embodiments, the client generates transaction 302 to include blockchain transaction version 314, block number or lock time 316 at which transaction 302 was generated, a number of transaction inputs 320, a list of one or more transaction inputs 320, a number of created transaction outputs 330, and a list of one or more created transaction outputs 330. In some embodiments, the client generates a unique TXN ID to identify transaction. In some embodiments, the unique TXN ID may be transaction hash 312. As described with respect to FIG. 1, the client may store transaction 302 and the TXN ID in memory. [0087] In some embodiments, the client can be configured to generate transaction hash 312 by hashing transaction 302 using a one-way hashing algorithm, such as the sha256 algorithm. For example, the transaction data includes version 314, lock time 316, transaction inputs 320, and transaction outputs 330.

[0088] In some embodiments, as described with respect to FIG. 1, the client can encrypt transaction 302 before transmitting a message to a verification network (e.g., verification network 130) to process transaction 302. In some embodiments, the message transmitted by the client can include a commission amount associated with processing transaction 302. For example, the commission amount may be based on an amount 326 of each of transaction inputs 320.

[0089] FIGs. 4A-C illustrate diagrams 400A-C of different types of transactions, according to some embodiments.

[0090] In some embodiments, diagram 400A illustrates an example of a re-issue transaction 402. In some embodiment, re-issue transaction 402 includes one input and one output where an input file 404 will be converted into an output file 406 having the same virtual currency amount, e.g., an amount of 10.

[0091] As discussed above, input file 404 may be a digital file (e.g., digital file 202) that includes information associated with a previous transaction used to generate input file 404. For example, input file 404 may include a secret key A, a TXN hash A of the previous transaction, an index N representing an index of an output of the previous transaction, and an amount of 10. Similarly, output file 406 includes information associated with re-issue transaction 402 used to generate output file 406. For example, output file 406 may be a digital file (e.g., digital file 202) with an index of 0 because there is only one output, a TXN hash B representing a transaction hash 408 of transaction 402, a secret key B, and the amount of 10.

[0092] In some embodiments, diagram 400B illustrates an example of a division transaction 412. In division transactions, an input file 414 will be converted into two or more output files 416 and 418. For example, as shown in diagram 400B, input file 414 may be a digital file (e.g., digital file 202) as described with respect to input file 404 in diagram 400 A. The amount of 10 stored in input file 414 may be divided into a virtual currency amount of 3 and 7 stored in output files 416 and 418, respectively. In some embodiments, each of output files 416 and 418 may be a digital file (e.g., digital file 202) that stores information associated with transaction 412 that generated the output file.

[0093] For example, output file 416 may be a digital file that stores a secret key of B assigned when transaction 412 was generated, a TXN hash B corresponding to the transaction hash 419 of transaction 412, an index of 0 indicating that output file 416 is the first output of transaction 412, and an amount of 3. Similarly, output file 418 may be a digital file that stores a secret key of C assigned when transaction 412 was generated, a TXN hash B corresponding to the transaction hash 419 of transaction 412, an index of 1 indicating that output file 418 is the second output of transaction 412, and an amount of 7.

[0094] In some embodiments, diagram 400C illustrates an example of a combination transaction 422. In combination transactions, two or more input files 424 and 426 will be converted into a single output file 428 to combine stored amounts of input files 424 and 426 into a single amount. For example, as shown in diagram 400C, two input files 424 and 426 may be two digital files (e.g., digital file 202) having respective amounts 3 and 7 that are combined to generate output file 428 having a total amount of 10. Additionally, input files 424 and 426 may have different TXN hashes to indicate that input files 424 and 426 were previously generated in two different transactions. An index value of 3 in input file 424 may indicate that the transaction associated with generating input file 424 had at least 3 outputs. Similarly, an input value of 5 in input file 426 may indicate that the transaction associated with generating input file 426 had at least 5 outputs. As shown in diagram 400C, output file 428 may be a digital file that stores a secret key C, a TXN hash B corresponding to transaction hash 429 of transaction 422, an index of 0, and an amount of 10.

[0095] FIG. 5 illustrates a diagram 500 showing a block 502 generated by a node, according to some embodiments. For example, the node may be one of nodes 132A-D, as described with respect to FIG. 1. In some embodiments, the node receives a first plurality of transactions from one or more user devices (e.g., user devices 104A-B). This first plurality of transactions may be stored as unconfirmed transactions (e.g., unconfirmed TXNs 136). In some embodiments, the node can be configured to select, from the first plurality of transactions, a second plurality of transactions 506 to include in block 502.

[0096] In some embodiments, before adding a transaction (e.g., transaction 302) to transactions 506, the node can be configured to verify a validity of the transaction. In some embodiments, verifying the validity can include verifying that a sum of amounts in one or more transaction inputs (e.g., transaction inputs 320) equals a sum of the amounts in one or more transaction outputs (e.g., transaction outputs 330).

[0097] In some embodiments, verifying the validity of the transaction can include verifying each of the transaction inputs based on a digital signature stored in the transaction input. For example, a transaction input may include a previous hash, an index, an amount, and signature information such as a signature and a public key, as described with respect to FIG. 3. The transaction input may correspond to a transaction output 330A generated in transaction 302. In some embodiments, to verify the transaction input, the node can be configured to retrieve transaction output 330A in transaction 302 based on the transaction hash and the index stored in the input transaction. If amount 334 does not match the amount stored in the transaction input, the node can determine that the transaction input cannot be verified. In some embodiments, the node can be configured to hash one or more portions of transaction 302, e.g., hash transaction output 330A, and to hash the signature located in the transaction input based on the public key in the transaction input. If the hash of one or more portions of transaction 302 is the same as the hash of the signature, then the transaction input can be verified.

[0098] In some embodiments, the block can be generated at a predetermined time interval (e.g., every two minutes). In some embodiments, the block can be generated for a predetermined number of added transactions 506 (e.g., 1000 transactions). In some embodiments, the node can generate a block header 504 that stores parameters related to transactions 506. Block header 504 may include one or more of the following parameters: height of block 502, size of block 502, version of software generating block 502, previous block hash of a most-recent block in a blockchain, a timestamp, and a transactions count that stores a number of transactions 506 in block 502. In some embodiments, block header 504 includes a Merkle root that represents a hash generated by transactions 506. For example, the Merkle root may be a root hash value of a binary hash tree where the leaf nodes are transactions 506 and each non-leaf node is a cryptographic hash of the hash values of its child nodes. In some embodiments, block header 504 can include a plurality of service fields to expand upon the functionality of block 502. For example, these service fields may include a parameter such as bits and nonce, as used in a proof-of-work scheme. In some embodiments, the node can be configured to generate the previous block hash by hashing a block header of the most-recent block in the blockchain based on a one-way hashing function, such as sha256 algorithm. In some embodiments, the node generates the previous block hash by hashing the previous block header a predetermined number of times (e.g., twice).

[0099] In some embodiments, before transmitting block 502 to other nodes in a verification network, the node signs block 502 with a private key associated with the node and transmits a signature with block 502. On the receiving end, a receiving node in the verification node authenticates block 502 by checking the signature based on a public key associated with the node. In some embodiments, to verify block 502, each receiving node can operate similar to the node to verify each of transactions 506.

[0100] FIG. 6 illustrates a diagram 600 showing example blocks 602A-C that comprise a blockchain, according to some embodiments. In some embodiments, each of blocks 602A-C may correspond to block 502 as described with respect to FIG. 5. As described above, once a block has been verified by a verification network (e.g., verification network 130), then the block can be added to the blockchain stored at a database in each node (e.g., node 132A) in the verification network. For example, a node may store a chain of blocks 602A-C in a blockchain data store (blockchain data store 138). Block 602A-C may include respective headers 604A-C and store respective transaction(s) 608A-C. Further, headers 604A-C may include respective previous transaction hashes 606A-C. For example, previous transaction hash 608B stored in block 602B may be a hash of header 604A of the previous block 602A with respect to block 602B. Similarly, previous transaction hash 606C may be a hash of header 604B of the previous block 602B with respect to previous block 602C.

[0101] FIG. 7 illustrates a method 700 for using digital files as currency, according to some embodiments. As shown, user device 702, user device 704, and verification network 706 may correspond to user device 104 A, user device 104B, and verification network 130, respectively.

[0102] In step 708, user device 702 transmits, to user device 704, data from a first digital file representing a first amount of a virtual currency assigned to the first digital file during a creation of a transaction associated with the data. As described with respect to FIG. 2, the first digital file includes information that stores the first amount, according to some embodiments. In some embodiments, user device 702 can be configured to transmit the data by wirelessly transmitting the first digital file to user device 704. In some embodiments, the first digital file can be an audio file. In these embodiments, user device 702 may transmit the data by playing the first digital file via a speaker of user device 702, as described with respect to FIG. 1.

[0103] In step 710, user device 704 receives, from user device 704, the data in the first digital file. In some embodiments, user device 704 receives the data via a communication interface on user device 704. For example, user device 704 may receive the first digital file via Bluetooth, 4G LTE, Wi-Fi, or other wired or wireless communication protocols. In some embodiments, user device 704 may receive the data via a microphone that records audio signals being transmitted by user device 702.

[0104] In step 712, user device 704 generates a transaction based on the data to generate a second digital file storing the first amount. In some embodiments, the transaction can be a re issue transaction. In some embodiments, user device 704 may store a third digital file storing a third amount of the virtual currency. In these embodiments, the transaction can be a combination transaction that combines the third amount in the third digital file with the first amount in the first digital file to generate the second digital file storing a second amount where the second amount is the sum of the first and third amounts. [0105] In step 714, user device 704 transmits the transaction to verification network 706 to be verified. In some embodiments, user device 704 transmits the transaction to a first node in verification network 706. In some embodiments, user device 704 may query verification network 706 to identify the first node.

[0106] In step 716, verification network 706 receives the transaction from user device 704. In some embodiments, the first node receives the transaction. In some embodiments, the first node can store the transaction as an unconfirmed transaction (e.g., unconfirmed TXNs 136). In some embodiments, as described above, the first node can be configured to verify the transaction before storing the transaction.

[0107] In step 718, the first node adds the transaction to a block to be verified. In some embodiments, the first node selects one or more unconfirmed transactions to add to the block. In some embodiments, the first node can prioritize a selection of an unconfirmed transaction based on a timestamp of the unconfirmed transaction and currency amount(s) included in the unconfirmed transaction.

[0108] In step 720, verification network 706 verifies the block. In some embodiments, the first node transmits the block to a plurality of nodes in verification network 706 that each verifies the block.

[0109] In step 722, the block is stored in a blockchain database at each node once verification network 706 verifies the block.

[0110] In step 724, verification network 706 transmits a result of the verification performed by the plurality of nodes. For example, the first node may transmit a result to user device 704 indicating that the transaction included in a block has been verified.

[0111] In step 726, user device 704 receives the result. In step 728, if the result indicates that the transaction was verified, user device 704 stores the second digital file in a memory on user device 704. In some embodiments, the second digital file can be an audio file. In step 730, user device 704 encrypts the second digital file. For example, a security component (e.g., security component 128) may encrypt the second digital file. [0112] FIG. 8 illustrates a method 800 for converting data in a digital file to audio signals for storage in a digital file having an audio file format, according to some embodiments. In some embodiments, method 800 can be performed by a client (e.g., client 120) running on a user device (e.g., user device 104A).

[0113] In step 802, the client retrieves a first digital file (e.g., digital file 202) including first data associated with a transaction that generated the first digital file, where the first digital file represents an amount of a virtual currency assigned to the first digital file during a creation of the transaction. In some embodiments, the client reads the first digital file stored in a memory of the user device. In some embodiments, the first data includes a secret key, a transaction hash, and an index stored in the first digital file. In some embodiments, the first digital file data also includes an amount stored in the first digital file.

[0114] In step 804, the client converts the first data into second data based on an alphabet having a first plurality of alphanumeric characters. For example, the alphabet may have 34 unique characters. In some embodiments, the client can be configured to perform the conversion by translating each character in the first data into one or more characters in the alphabet.

[0115] In step 806, the client calculates a checksum based on the second data. In some embodiments, the client can be configured to calculate the checksum using a CRC 32 algorithm among other CRC algorithms.

[0116] In step 808, the client combines a beginning marker, the second data, the checksum, and an end marker to generate third data. In some embodiments, the beginning marker and the end marker may correspond to distinct characters in the alphabet of step 804. In some embodiments, the third data starts with the beginning marker to indicate the beginning of a message and ends with the end marker to indicate the end of the message.

[0117] In step 810, the client converts the third data into audio data for storing in a second digital file having an audio file format. For example, the second digital file may be an MP3 file, a WAV file, an MPEG-4 file, etc. In some embodiments, the client can perform steps 810A-C to perform the conversion. In some embodiments, one or more of steps 810A-C can be performed concurrently by the client.

[0118] In step 810A, the client generates a first audio signal based on third data. In some embodiments, to generate the first audio signal, the client converts the third data into a first audio signal by translating each character in the third data into a frequency selected from a first range of frequencies. In some embodiments, the first range of frequencies may start at 6 kHz. The frequency of 6 kHz can be selected to reduce background and household noise from interfering with the frequency to be transmitted. Research studies have shown that most sounds such as background noise, TV noise, human speech, and household sounds are below the 6 kHz mark. In some embodiments, the first range of frequencies may be between 6 kHZ and 11 kHz. In some embodiments, the alphabet may have 34 characters that correspond to numbers 0, 1, ..., 33, respectively. In these embodiments, the client can calculate a frequency for a character based on the following relationship: {character} *135.17241 + 6,000 Hz. In some embodiments, the value of 135.17241 Hz may be selected for an alphabet having 34 characters to be the separation bandwidth between each sound symbol in an audio signal such that interference between sound symbols can be minimized.

[0119] In step 810B, the client generates a second audio signal based on the third data. In some embodiments, to generate the second audio signal, the client converts the third data into a second audio signal by translating each character in the third data into a frequency selected from a second range of frequencies different from the first range of frequencies. In some embodiments, the second range of frequencies can be below a frequency of 16 kHz because most audio codecs cannot process frequencies above 16 kHz. In the example where the first range of frequencies is between 6 kHz and 11 kHz, the second range of frequencies may be between 11 kHz and 16 kHz. In some embodiments, the second audio signal can be generated by the client to be a copy of the first audio signal where each frequency in the first audio signal is shifted by a predetermined frequency. In some embodiments, the alphabet may have 34 characters that correspond to numbers 0, 1, ..., 33, respectively. In these embodiments, the client can calculate a frequency for a character based on the following relationship: {character} *135.17241 + 11,000 Hz. In effect, the second audio signal can be a copy of the first audio signal shifted upwards by 5,000 Hz. In some embodiments, the value of 135.17241 Hz may be selected for an alphabet having 34 characters to be the separation bandwidth between each sound symbol in an audio signal such that interference between sound symbols can be minimized.

[0120] In some embodiments, to reduce interference, the client can apply a predetermined amount of delay to one of the audio signals (e.g., the second audio signal). In some embodiments, the predetermined amount of delay corresponds to a time length of one symbol in the first and second audio signals. For example, the client may add a delay of 50 ms to the second audio signal. In some embodiments, the client generates the second audio signal based on the first audio signal by shifting the first audio signal by a frequency amount and by delaying the first audio signal by a predetermined time delay.

[0121] In step 810C, the client stores the first and second audio signals in the second digital file having the audio file format. In some embodiments, the client combines the first and the second audio signal for storing in the second digital file. In some embodiments, the client can play the second digital file via a speaker to transmit data stored in the second digital file to another user device, as described with respect to FIG. 1.

[0122] FIG. 9 illustrates a method 900 for extracting virtual currency information from audio, according to some embodiments. In some embodiments, method 900 can be performed by a client (e.g., client 120) running on a first user device (e.g., user device 104A).

[0123] In step 902, the client receives audio via a microphone implemented on the first user device. In some embodiments, the audio can be played by a second user device via one or more speakers. The client can receive and record the received audio. In some embodiments, the audio includes audio data from a digital file stored at the second user device. For example, the digital file may include data associated with a first transaction that generated the digital file where the digital file represents an amount of a virtual currency assigned to the digital file during a creation of the transaction. [0124] In step 904, the client extracts, from the audio, frequencies within a first plurality of frequencies to generate a first audio signal. In some embodiments, the first plurality of frequencies can be a first range of frequencies. For example, the first plurality of frequencies may be from 6 kHz to 11 kHz. In some embodiments, the extracted frequencies can include a first frequency that corresponds to a beginning marker of the audio. For example, as described with respect to FIG. 8, the client may determine the first frequency is the beginning marker if the first frequency is within a specific frequency range associated with the beginning marker. Similarly, the client may determine a second frequency, from the extracted frequencies, that represents an end marker based on determining that the second frequency is within a different frequency range associated with the end marker.

[0125] In step 906, similar to step 904, the client extracts, from the audio, frequencies within a second plurality of frequencies to generate a second audio signal. However, as described with respect to FIG. 8, the second plurality of frequencies can be a second range of frequencies that excludes the first plurality of frequencies. Accordingly, the first range of frequencies may be different from the second range of frequencies. Like in step 904, the client can determine a beginning and an end marker based on identifying specific frequencies in the extracted frequencies.

[0126] In step 908, the client generates a blended audio signal by combining the first audio signal with the second audio signal. In some embodiments, step 908 can include

steps 908A-C.

[0127] In step 908A, the client normalizes the frequencies for each symbol in the first audio signal. In some embodiments, a frequency in a symbol can be normalized to be a decimal value between 0 and 1.

[0128] In step 908B, like in step 908A, the client normalizes the frequencies for each symbol in the second audio signal. In some embodiments, a frequency in a symbol can be normalized to be a decimal value between 0 and 1. [0129] In step 908C, the client blends the normalized first audio signal of step 908A with the normalized second audio signal of step 908B to generate the blended audio signal. In some embodiments, the client implements a linear light blending formula to combine the normalized first and second audio signals. For example, the linear light formula implemented by the client may be: (S2 + 2*(Sl - 0.5)) if Sl > 0.5; and (S2 + 2*Sl) if S l <= 0.5 where S l is the first audio signal and S2 is the second audio signal. In some embodiments, by blending the first and second audio signals extracted from the audio of step 902, random noise and interference from other sources of sound other than the second user device can be filtered.

[0130] In step 910, the client translates each symbol in the blended audio signal to recover the data represented in the audio. In some embodiments, the client performs the translation by translating each symbol to a character by reversing the conversion process described with respect to step 810 of FIG. 8. In particular, a symbol in the blended audio signal can be translated into a specific character based on the symbol having a normalized value between a specific range of values. In some embodiments, the client can extract and verify the checksum from the translated symbols. If the checksum can be verified, the client can further convert the remaining, translated characters to virtual currency information based on an alphabet having a plurality of

alphanumeric characters. For example, the client may reverse the conversion process performed in step 804 of FIG. 8.

[0131] In step 916, the client stores the translated, blended audio signal in a digital file. As discussed with respect to step 802 of FIG. 8, the digital file being stored can include a transaction hash, a secret key, and an index. In some embodiments, the digital file also includes a virtual currency amount.

[0132] FIG. 10 illustrates a method 1000 for verifying a block amongst a plurality of verification nodes, according to some embodiments. In some embodiments, method 1000 can be performed by nodes 132A-D as described with respect to FIG. 1.

[0133] In step 1002, a first plurality of nodes from nodes in the verification network can be selected to be members of a committee. For example, nodes in a verification network (e.g., verification network 130) can perform the selecting, as described with respect to FIG. 1. In some embodiments, the first plurality of nodes includes a predetermined amount of nodes. In some embodiments, the first plurality of nodes is selected from the verification networking having a second plurality of nodes. In some embodiment, the verification network reselects nodes in the first plurality of nodes after a predetermined number of blocks (e.g., 600 blocks) has been added to a blockchain or after a predetermined amount of time (e.g., 20 hours). Members of the committee can be configured to verify each transaction placed in a block, as will be described below.

[0134] In some embodiments, the first plurality of nodes can be randomly selected from the second plurality of nodes in the verification network. In some embodiments, a probability that a node from a second plurality of nodes is selected to be included in the first plurality of nodes depends on an amount of time that node has been verifying transactions in the verification network, an amount of virtual currency associated with that node, and a frequency of

participation in the committee.

[0135] In step 1004, a first node from the first plurality of nodes receives a first transaction. For example, the transaction can be received from a user device (e.g., user device 104A). In some embodiments, each node in the first plurality of nodes of the committee can be configured to receive the first transaction for local storage. As described with respect to FIG. 1, the first transaction may be stored as an unconfirmed transaction until the first transaction has been added to a block, verified, and added to the blockchain. In some embodiments, the first transaction can be in a format of transaction 302, as described with respect to FIG. 3. For example, the first transaction may be transaction 402, transaction 412, or transaction 422, as described with respect with FIGS. 4A, 4B, and 4C, respectively.

[0136] In step 1006, the first node selects the first transaction to add to a block. In some embodiment, the first node can be configured to select the first transaction from a first plurality of transactions based on a fee and a timestamp associated with each transaction in the first plurality of transactions. The transactions in the first plurality of transactions may be received from clients (e.g., client 120). Accordingly, the first node can prioritize adding transactions with associated high fees and old transactions having earlier timestamps. In some embodiments, a fee of a transaction can be set to a proportion (e.g., 0.5%) of a total amount in the transaction. In some embodiments, the user device that generates the transaction can set a fixed fee.

[0137] In step 1008, the first node verifies a validity of the first transaction before adding to the block. In some embodiments, to check the validity of a transaction, the first node checks that a sum of the transaction input amounts matches a sum of the transaction output amounts. In some embodiments, checking the validity of the first transaction includes checking a blockchain stored at the first node to confirm that each transaction input exists in the blockchain. In some embodiments, checking the validity of the first transaction includes confirming that each transaction input does not correspond to a digital file that has been spent. In some embodiments, checking the validity of the transaction includes determining whether each transaction input matches a corresponding output of a transaction stored in the blockchain. Other checks are described with respect to step 718 of FIG. 7.

[0138] In step 1010, the first node transmits the block and a signature of the block to each other node in the first plurality of nodes of the committee to be verified. In some embodiments, the first node can be configured to use a private key associated with the first node to generate the signature of the block. In some embodiments, the first node can be configured to transmit the block upon adding a predetermined number of transactions (e.g., 1000), after a predetermined time interval (e.g., 2 minutes), or after both conditions are met.

[0139] In step 1012, the other nodes in the first plurality of nodes each verifies the block using the process described with respect to step 1008. For example, each of the other nodes may verify each transaction in the block based on respective copies of the blockchain. In some embodiments, each node in the first plurality of nodes stores public keys corresponding to private keys of each node in the first plurality of nodes. In some embodiments, a second node may receive the block generated by the first node and a digital signature of the block generated by the first node. In some embodiments, by using the public key of the first node to verify the digital signature, the second node receiving the block can authenticate the block as truly originating from the first node as only the first node has the private key to generate the digital signature. [0140] In some embodiments, the verification network implements a delegation scheme that delegates the verification processing to a node not selected to be in the first plurality of nodes if a node, i.e., an unavailable node, from the first plurality of nodes cannot perform the verification.

In some embodiments, each node in the first plurality of nodes forms its own list of delegate nodes. In some embodiments, the unavailable node can allow a delegate node in its list of delegate nodes to generate blocks on his behalf. However, the delegate node can only be selected if that delegate node is included in a threshold number of lists formed by the nodes in the first plurality of nodes, according to some embodiments.

[0141] In some embodiments, the delegation scheme can be implemented based on proxy signatures. The unavailable node may transfer the right to create blocks by creating a proxy signature key that allows the delegate node to sign messages, according to some embodiments. Further, the unavailable node can be configured to limit a number of blocks that the delegate node can generate or verify.

[0142] In step 1014, the first node stores the block in the blockchain upon receiving verification confirmation from a predetermined threshold number of nodes from the first plurality of nodes. Similarly, each node in the first plurality of nodes stores the block in their respective copies of the blockchain. In some embodiments, the first plurality of nodes in the committee can be configured to select a next node, from the first plurality of nodes, to generate a next block. Method 1000 may proceed to step 1004 where the next node being selected receives transactions.

[0143] In some embodiments, once the block is confirmed by the predetermined threshold number of nodes, a fee (i.e., an amount of virtual currency) associated with the block can be distributed to each node in the first plurality of nodes. In some embodiments, the fee can be a sum of a fee of each transaction in the block.

[0144] FIGS. 11A-G illustrate example graphical user interfaces (GUIs) 1100A-G that enable a user to use digital files as currency, according to some embodiments. In some embodiments, GUIs 1100A-G can be implemented and provided to the user by a client (e.g., user interface 124 on client 120) on a user device (e.g., user device 104A). [0145] In FIG. 11 A, GUI 1100A presents a plurality of digital file icons 1104A-D that represent corresponding digital files stored on the user device. Digital file icons 1104A-C may correspond to approximate currency amounts of 5.12443, 0.00011, 0.00011, and 0.00011, respectively. In some embodiments, GUI 1100A shows a total amount 1102 representing a sum of all amounts of digital files stored in the memory of the user device. In some embodiments,

GUI 1100A enables the user to slide, tap, or click on a digital file icon, such as digital file icon 1104D, to generate a transaction. For example, option 1106 shows requests the user to confirm an initiation of a re-issue transaction based on the digital file corresponding to digital file icon 1104D. In some embodiments, GUI 1100A enables the user to select two or more icons 1104A-D to generate a combination transaction that combines the amount of the digital files corresponding to the two or more icons 11004A-D.

[0146] FIG. 11B shows that GUI 1100B prompts the user to select a format type of the output file generated by the selected transaction, e.g., the re-issue transaction confirmed in GUI 1100A. As shown, GUI 1100B an audio file format icon can be highlighted to show the user’s selection and the non-audio file format icon is not highlighted. In FIG. 11C, GUI 1100C enables the user to select the generate transaction icon 1110 to transmit the transaction to a verification network (e.g., verification network 130). FIG. 11D shows that GUI 1100D presents a verification result 1112 after the user selects transaction icon 1110 in GUI 1100C. As shown, result 1112 may indicate that the digital file corresponding to icon 1104D was verified and issued at a specific timestamp, e.g.,“22 aug 2017 12:22.”

[0147] FIG. 11E shows a GUI 1100E that enables the user to divide a selected digital file (corresponding to icon 1104D) into two or more digital files with divided amounts. For example, graphical element 1114 enables the user to select a number of parts (e.g., 11) to divide the selected digital file. In some embodiments, GUI 1100E enables the user to input an amount for each of the number of parts such that a sum of the amounts total the amount stored in the digital file. For example, as shown and described with respect to FIG. 4B, the user can select a digital file having an amount of 10 for division into two digital files having amounts of 3 and 7, respectively. [0148] FIG. 11F shows a GUI 1100F that enables the user to transmit data in the digital file corresponding to icon 1104D. In particular, GUI 1100F shows graphical elements 1116 that enables the user to select the mode of transmitting the data. For example, the client may transmit the digital file corresponding to icon 1104D via email, instant messenger, a phone call, among other types of social media. As described above with respect to FIG. 1 , the digital file may store audio data and the client can transmit the data in the digital file by using one or more speakers on the user device to play audio from the digital file. In some embodiments, upon transmitting data of the digital file, GUI 1100F may remove icon 1104D from the user’s view. In some

embodiments, GUI 110F may remove icon 1104D after receiving confirmation from the verification network that a recipient of the data in the digital file successfully received the data.

[0149] FIG. 11G shows a GUI 1100G that enables the user to exchange amount within one or more digital files corresponding to icons 1104A-D with other types of virtual currencies 1120A- F.

[0150] FIG. 12 illustrates an example of a computer in accordance with one embodiment. Computer 1200 can be a component of a system for enabling digital files to be used as currency according to the systems and methods described above, such as one of nodes 132A-D or user devices 104A-B as described with respect to FIG. 1. In some embodiments, computer 1200 is configured to execute each of methods 700, 800, 900, and 1000 of FIGS. 7, 8, 9, and 10, respectively.

[0151] Computer 1200 can be a host computer connected to a network. Computer 1200 can be a client computer or a server. As shown in FIG. 12, computer 1200 can be any suitable type of microprocessor-based device, such as a personal computer, workstation, server, videogame console, or handheld computing device, such as a phone or tablet. The computer can include, for example, one or more of processor 1210, input device 1220, output device 1230, storage 1240, and communication device 1260. Input device 1220 and output device 1230 can generally correspond to those described above and can either be connectable or integrated with the computer. [0152] Input device 1220 can be any suitable device that provides input, such as a touch screen or monitor, keyboard, mouse, or voice-recognition device. Output device 1230 can be any suitable device that provides output, such as a touch screen, monitor, printer, disk drive, or speaker.

[0153] Storage 1240 can be any suitable device that provides storage, such as an electrical, magnetic, or optical memory, including a RAM, cache, hard drive, CD-ROM drive, tape drive, or removable storage disk. Communication device 1260 can include any suitable device capable of transmitting and receiving signals over a network, such as a network interface chip or card. The components of the computer can be connected in any suitable manner, such as via a physical bus or wirelessly. Storage 1240 can be a non-transitory computer-readable storage medium comprising one or more programs, which, when executed by one or more processors, such as processor 1210, cause the one or more processors to execute methods described herein, such as each of methods 700, 800, 900, and 1000 of FIGS. 7, 8, 9, and 10, respectively.

[0154] Software 1250, which can be stored in storage 1240 and executed by processor 1210, can include, for example, the programming that embodies the functionality of the present disclosure (e.g., as embodied in the systems, computers, servers, and/or devices as described above). In some embodiments, software 1250 can be implemented and executed on a

combination of servers such as application servers and database servers.

[0155] Software 1250, or part thereof, can also be stored and/or transported within any computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch and execute instructions associated with the software from the instruction execution system, apparatus, or device. In the context of this disclosure, a computer-readable storage medium can be any medium, such as storage 1240, that can contain or store programming for use by or in connection with an instruction execution system, apparatus, or device.

[0156] Software 1250 can also be propagated within any transport medium for use by or in connection with an instruction execution system, apparatus, or device, such as those described above, that can fetch and execute instructions associated with the software from the instruction execution system, apparatus, or device. In the context of this disclosure, a transport medium can be any medium that can communicate, propagate, or transport programming for use by or in connection with an instruction execution system, apparatus, or device. The transport-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation medium.

[0157] Computer 1200 may be connected to a network, which can be any suitable type of interconnected communication system. The network can implement any suitable communications protocol and can be secured by any suitable security protocol. The network can comprise network links of any suitable arrangement that can implement the transmission and reception of network signals, such as wireless network connections, Tl or T3 lines, cable networks, DSL, or telephone lines.

[0158] Computer 1200 can implement any operating system suitable for operating on the network. Software 1250 can be written in any suitable programming language, such as C, C++, Java, or Python. In various embodiments, application software embodying the functionality of the present disclosure can be deployed in different configurations, such as in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.

[0159] The foregoing description sets forth exemplary methods, parameters and the like. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure but is instead provided as a description of exemplary embodiments. The illustrative embodiments described above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described to best explain the principles of the disclosed techniques and their practical applications. Others skilled in the art are thereby enabled to best utilize the techniques and various embodiments with various

modifications as are suited to the particular use contemplated.

[0160] Although the disclosure and examples have been fully described with reference to the accompanying figures, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the disclosure and examples as defined by the claims. In the foregoing description of the disclosure and embodiments, reference is made to the accompanying drawings, in which are shown, by way of illustration, specific embodiments that can be practiced. It is to be understood that other embodiments and examples can be practiced, and changes can be made without departing from the scope of the present disclosure.

[0161] Although the foregoing description uses terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another.

[0162] In addition, it is also to be understood that the singular forms“a,”“an,” and“the” used in the foregoing description are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is also to be understood that the term“and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It is further to be understood that the terms“includes,“including,” “comprises,” and/or“comprising,” when used herein, specify the presence of stated features, integers, steps, operations, elements, components, and/or units but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, units, and/or groups thereof.

[0163] The term“if’ may be construed to mean“when” or“upon” or“in response to determining” or“in response to detecting,” depending on the context. Similarly, the phrase“if it is determined” or“if [a stated condition or event] is detected” may be construed to mean“upon determining” or“in response to determining” or“upon detecting [the stated condition or event]” or“in response to detecting [the stated condition or event],” depending on the context.

[0164] In some embodiments, a non-transitory computer readable storage medium stores one or more programs configured to be executed by one or more processors of a computing device, the one or more programs including instructions for implementing any of the steps described or claimed herein. The present disclosure also relates to a device for performing the operations herein. This device may be specially constructed for the required purposes, or it may include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, computer readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referenced in this disclosure may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0165] The methods, devices, and systems described herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description above. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein.

Claims

CLAIMS What is claimed is:

1. A method, comprising:

retrieving, at a first device, a first digital file comprising first data associated with a transaction that generated the first digital file, the first digital file representing an amount of a virtual currency assigned to the first digital file during a creation of the transaction;

generating, at the first device, a second digital file based on the first digital file, the second digital file comprising audio data that represents the first data in the first digital file; and playing, via a speaker of the first device, the audio data in the second digital file to a second device to transfer the amount represented by the first digital file to the second device.

2. The method of claim 1, wherein the transaction is created by the first device.

3. The method of any of claims 1-2, comprising:

encrypting the second digital file based on a password selected by a user; and

before playing the audio data, requesting the user to enter the password to decrypt the second digital file.

4. The method of any of claims 1-3, wherein the first data comprises: a secret key generated in the transaction, a hash of the transaction, an index associated with the transaction and selected for the first digital file, and the amount.

5. The method of any of claims 1-4, wherein generating the second digital file

comprises:

generating a first audio signal based on the first data;

generating a second audio signal based on the first data; and

combining the first audio signal and the second audio signal data for storing in the second digital file.

6. The method of claim 5, wherein the first audio signal includes frequencies within a first range of frequencies and the second audio signal includes frequencies within a second range of frequencies different from the first range of frequencies.

7. The method of any of claims 1-6, wherein generating the second digital file

comprises:

generating a first audio signal based on the first data;

generating a second audio signal based on the first audios signal; and

combining the first audio signal and the second audio signal for storing in the second digital file.

8. The method of claim 7, wherein the second audio signal comprises the first audio signal shifted by a frequency amount and delayed by a predetermined time delay.

9. The method of any of claims 5-8, wherein generating the first audio signal

comprises:

converting the first data into second data based on an alphabet having a plurality of alphanumeric characters;

computing a checksum of the second data; and

combining a beginning marker, the second data, the checksum, and an end marker to generate third data, wherein the first audio signal is generated based on the third data.

10. The method of claim 9, wherein the beginning marker and the end marker

correspond to a first and a second character, respectively, from the plurality of alphanumeric characters.

11. The method of any of claims 1-10, wherein the amount of the virtual currency is specified in the transaction, and wherein the transaction is stored in a blockchain.

12. The method of any of claims 1-11, wherein the first digital file includes a first secret key generated in the transaction, and wherein the second device is configured to receive the amount by using the first secret key to generate a second transaction for storage in the blockchain.

13. The method of any of claims 1-12, wherein the second transaction is added to a blockchain after a plurality of nodes verify the second transaction based on a proof-of-stake scheme.

14. The method of any of claims 1-13, comprising:

selecting, by a first node from a plurality of nodes in a verification network, the second transaction to add to a block;

verifying, by the first node, a validity of the second transaction before adding the second transaction to the block;

transmitting, by the first node, the block to each other node in the plurality of nodes; verifying, at each other node, the block based on a copy of the blockchain stored at each node;

receiving, by the first node, verification confirmations from a threshold number of nodes of the plurality of nodes; and

upon receiving the verification confirmations from the threshold number of nodes, storing the block in the blockchain.

15. A method, comprising :

receiving, at a first device, first data in a first digital file from a second device, the first data being associated with a first transaction that generated the first digital file, the first digital file representing an amount of a virtual currency assigned to the first digital file during a creation of the first transaction;

generating, at the first device, a second transaction to create a second digital file based on the first data in the first digital file to store the amount;

transmitting, by the first device, the second transaction to a verification network to verify the second transaction for storage in a blockchain; receiving, at the first device, a result from the verification network, the result indicating that the second transaction is verified; and

storing, by the first device, the second digital file in a memory at the first device in response to receiving the result.

16. The method of claim 15, wherein the first transaction is created by the second device.

17. The method of any of claims 15-16, wherein the second transaction comprises a re-issue transaction that generates the second digital file to include the amount.

18. The method of any of claims 15-16, wherein the amount is a first amount, wherein the second transaction comprises a combination transaction, comprising:

combining the first amount with a third amount represented by a third digital file stored at the first device to generate a second amount for storing in the second digital file.

19. The method of any of claims 15-18, wherein generating the second transaction comprises:

generating a secret key for the second digital file;

computing a hash of the second transaction; and

storing the secret key and the hash in the second digital file.

20. The method of any of claims 15-19, wherein the receiving the first data

comprises:

wirelessly receiving the first digital file from the second device.

21. The method of any of claims 15-19, wherein the receiving the first data

comprises:

receiving, via one or more speakers at the first device, audio played by the second device, wherein the audio represents the first data stored in the first digital file.

22. The method of claim 21, comprising:

extracting, from the audio, frequencies within a first range of frequencies to generate a first audio signal;

extracting, from the audio, frequencies within a second range of frequencies to generate a second audio signal;

generating a blended audio signal by combining the first audio signal with the second audio signal; and

translating each symbol in the blended audio signal to recover the first data represented by the audio.

23. The method of claim 22, wherein each symbol is translated based on an alphabet having a plurality of alphanumeric characters.

24. The method of any of claims 22-23, generating the first audio signal comprises: determining a start of the first audio signal by identifying a first frequency from the frequencies within the first range of frequencies, wherein the first frequency represents a beginning marker; and

determining an end of the first audio signal by identifying a second frequency from the frequencies within the first range of frequencies, wherein the second frequency represents an end marker.

25. The method of any of claims 22-24, wherein the first data includes a checksum, comprising:

determining whether the first data includes one or more errors based on the checksum; and

correcting the one or more errors based on the checksum when the one or more errors are detected.

26. The method of any of claims 15-25, wherein the amount of the virtual currency is specified in the first transaction, and wherein the first transaction is stored in the blockchain.

27. The method of any of claims 15-26, wherein the first digital file includes a first secret key generated in the first transaction, and wherein the second transaction is generated based on the first secret key.

28. The method of any of claims 15-26, wherein the first digital file includes a first secret key generated in the first transaction, wherein generating the second transaction comprises:

generating a transaction input of the second transaction based on the first secret key, wherein the transaction input includes a signature of the second transaction generated using the secret key and includes a public key generated based on the first secret key, and wherein the second transaction is verified by a plurality of nodes in the verification network based on the signature and the public key.

29. The method of any of claims 15-28, wherein a plurality of nodes in the

verification network verifies the second transaction based on a proof-of-stake scheme.

30. The method of any of claims 15-29, comprising:

selecting, by a first node from a plurality of nodes in the verification network, the second transaction to add to a block;

transmitting, by the first node, the block to each other node in the first plurality of nodes; verifying, at each other node, the block based on a copy of the blockchain stored at each node;

31. A system for performing the method of any of claims 1 -30, wherein the system comprises a first device having one or more processors, memory, and one or more programs stored in the memory and configured to be executed by the one or more processors.

32. A non-transitory computer-readable storage medium comprising instructions for performing the method of any of claims 1 -30 when the instructions are executed by a first device having one or more processors.