However, getting a patent on blockchain technology that uses a peer-to-peer network using proof-of-work to record a public history of transactions is like getting a patent on an algorithm, is directed to an abstract idea, and is likely going to fail the first step of the Mayo test under US law. But even if a specific blockchain technology is considered to be patentable subject matter, the claims in the patent application must still be shown to be novel and nonobvious.
Recently, some banks have been granted patents on their own version of blockchain technology. Moving forward though, it may be harder to get such patents given that organizations like R3CEV and Chain plan to make their blockchain software code open to the public, thus making it harder for a patentee to show its invention meets the definition of novel and nonobvious. Searchable Patents Journal , U. What Is Blockchain Technology?
- bitcoin highest dollar price.
- The Relationship Between Patents & Cryptocurrency | OpenMind.
- nilai tukar bitcoin sekarang.
- btc 4000.
- bitcoin tak bertuan.
Myriad Genetics, Inc. See, e. Mayo , U. Patent No. Symbian Ltd. Patent Act, R. Patent Application No. She went back to school to get her Masters in Law after receiving her JD and working in San Francisco for a year on intellectual property, technology, and privacy law issues. Search ABA.
Close Search Submit Clear.
Microsoft looks to buy Discord
Blockchain Patents and Innovation The most notable patent filers in the blockchain technology space have been banks. Conclusion The number of patent applications being filed for blockchain technology is on the rise. Endnotes 1. Patents Act , c. Authors Inayat Chaudhry. At step 74, the secure device 10 sends a request to the API server 50 with the packet.
The request is sent and, at step 76 various individual case uses apply as will be described below. The timestamp is verified before the device database 54 is ever modified. The process flow 60 checks that the timestamp is newer than the timestamp currently stored in the device database 54 under the device ID of the user device Process flow 60 then checks that the timestamp is "roughly" the current time e. The second check ensures that an attacker cannot insert an incorrect time through process flow 60, either too early or too late. The first check plus the assurance of the second check ensures that no properly encrypted transaction may be stored and then replayed.
First time setup begins at step 82 where web browser 42 communicates to begin web server process flow First time set up process flow 80 includes process flow occurring at secure device 10, API server 50, user accounts server 52, and web server From step 88, process flow goes to API server 50 to execute a step 90 in which API server 50 receives a "setup link request" to pass to the user account server At the user account server 52, step 92 includes checking that the user is fully verified and not setup with a secure device At step 92, user account server 52 stores the encryption key from the authorized token as a temporary password.
Next, user account server 52 generates an authorization code and stores the code in the device database 54 under the given user name.
Momentum for Cashless Gaming
User account server 52 then generates 64 bytes, for example, as a one-time key, and encrypts the one-time key with a master SPK. Then user account server 52 stores the encrypted one-time key in a temporary one-time key field. Finally, user account server 52 sends the user name, authorization code and the one-time key to the internet Process flow then proceeds to step 94 at API server 50 which recognizes the setup link initiated command and passes that to web server 46 at step Web server 46 then sends a packet to the secure device 10 to store the authorization code in the user device's cookies and to prompt the secure device 10 to continue the setup process.
And then further display the public key and the request for user confirmation. At step , secure device 10 generates 64 bytes of random data for the secure device 10 SPK. Secure device 10 generates 64 bytes of random data for the secure device 10 UDEK. Further, secure device 10 generates a device Bitcoin private key, for example, and public key and then further decrypts a one-time key with a master SPK. In addition, process flow continues from step to step 1 18 which will be described shortly. At step a send request timestamp is sent to API server 50 which timestamp is sent to secure device From secure device 10 step , process flow continues to step 1 10 where API server 50 recognizes the setup link signature and passes that information to the user account server From step 1 10 process flow continues to step 1 12 where user account server 52 decrypts the data with a one-time key.
User account server 52 validates the authorization code for the user and links the secure device 10 and user entries. Next, user account server 52 generates HD private and public keys.
Step 1 12 further includes encrypting three public keys with the UDEK, and storing the secure device 10 in the device database. The user account server 52 encrypts three public keys with a temporary password and stores this information in the device database Finally, at step 1 12, user account server 52 encrypts the UDEK-encrypted public keys with SPK and sends that information to the secure device 10 with setup FP request.
Now, the user needs to swipe for his fingerprint. At this point, process flow continues to step 1 16 at API server 50 where API server 50 recognizes the setup FP request and passes that information to secure device If a third public key was scanned secure device 10 verifies that as well. Then, secure device 10 stores server and cold storage public keys. Secure device 10 then tells the user to swipe his finger a predetermined number of times on the fingerprint scanner 14, which can be How many times?.
The secure device 10 then uses fingerprint data to compile a fingerprint blueprint or template. The secure device 10 then sends a command to user account server 52, which user account server 52 receives at step If the fingerprint template is not sufficiently robust, user account server 52 calls for fingerprint setup again with UDEK-encrypted public keys.
Conversely, if the fingerprint template is sufficiently robust, user account server 52 encrypts the fingerprint template with the UDEK and then adds the fingerprint template to the device database Next, at step , user account server 52 determines that the setup status is complete. Process flow then continues to API server 50 at step At step API server 50 recognizes the setup fp success state and passes that to secure device At step , the secure device 10 receives the fingerprint setup success signal and then, at step , indicates that setup is complete and sets a flag so next startup doesn't enter the setup process.
The Bitcoin Patent – Only A Matter Of Time?
If the secure device 10 is set up, then the web server 56 supplies a home screen to the web browser At step , web server 56 performs a first step to send username and password to confirm a first time set up. This may include a serial number for a particular secure device At step , user account server 52, in response generates an RSA key from the password deterministically, for example. User account server 52 stores an RSA public key in the device database 54 and sends an encrypted RSA private key to the user with an authorization code via the web server At step , web browser 82 further stores the RSA private key, again encrypted, with the authorization token.
At step , secure device 10 sends an authorization code that is signed by the private key of the user device The authorization code is sent to the user account server 52, which at step verifies the authorization code and decrypts the public keys with the UDEK. Further user account server 52 encrypts the public keys with the stored RSA public key. At step , web server 56 sends the RSA private key back to the user account server 52 with the authorization code, furthermore, the user account server 52 decrypts the public keys with the RSA private key, encrypts the public keys with the keys stored in the authorization code.
The multi-factor authentication process will be described hereinafter as using a two factor authentication.
- IGT Furthers Cashless Gaming Cause with Bitcoin Slot Patent Win.
- The Patentability of Blockchain Technology and the Future of Innovation.
- Bitcoin Features?
- Landslide® March/April 2018!
- The Relationship Between Patents & Cryptocurrency.
However, it should be understood that additional factors could also be used. The multi-factor authentication process begins at step when a logged in user requests a page that requires two factor authentication 2FA. At step API server 50 recognizes the OP code and routes the request to the user account server At step , user account server 52 validates the token and generates a 2FA code and further stores the 2FA code in the device database If a 2FA code already exists, user account server 52 overwrites the 2FA code.
User account server 52 further encrypts the data with the shared private key, SPK, for example. The OP next step is the operation to execute after a successful 2FA. The extra information is additional information necessary to continue such as user name to change to a new phone number, etc. Then process control returns back to web server 56 for performing step At step web server 56 encodes the data and the OP code in a QR code and displays that code to the user.
Microsoft will mine bitcoin with your brain | Information Age | ACS
Thereafter, web server 56 sends information to the secure device The secure device 10 decodes and parses the QR code to create a signature that includes the 2FA code, and an OP next step command. If the requested operation is changing the web password then at step user account server 52 re-encrypts the public keys with a new temporary password. Then, process flow continues to API server This continues until a five minute timeout occurs, for example.
Thereafter, web server 56 sends process control to API server 50 to perform step to recognize the 2FA follow up and to determine the OP code value and then route control to the user account server At step in response to the user's account being verified user account server 52 begins the operation that the user requested.
For example, change the password or whatever may be required. As shown, an exemplary 'received Bitcoin' process flow may begin at step where secure device 10 requests a receive address and sends OP code value corresponding to the receive request to the PI server This transmission from the secure device 10 may include UDEK, a fingerprint scan, and a time stamp and be encrypted with the shared private key.
At step , user account server 52 may further validate the fingerprint scan, and validates the time stamp. User account server 52 may retrieve from the device database 54 the public keys 1 , 2 and 3 and then decrypt the public keys using the UDEK. Continuing the process, user account server 52 may send public key 1 , public key 2 and public key 3 as well as a device ID to wallet server At step , wallet server 46 receives the row from lock table of the wallet database 48 that corresponds to the particular secure device If the row is nonexistent, wallet server 46 will insert one into the lock table.
Wallet server 46 also retrieves from the wallet database 48 in the child public key at least the highest recorded index. Alternatively, if the index is zero, if no key is in the wallet database 48 for the desired branch. Then, wallet server 46 will acquire the database lock.
Further at step , if the current address has an empty transaction history wallet server 46 will send the current address. If the current address has a non empty transaction history, but all of the transactions are unconfirmed wallet server 46 will send the current address only if the current address was derived at index 0. Otherwise wallet server 46 will send the address at the previous index.
If the current address has a non empty transaction history and at least one of those transactions has been confirmed wallet server 46 will update the wallet database 48 and recurse, checking the address at the next index. Next, at step , user account server 52 applies the IFF time stamp verification passes an update the time stamp.
From step , secure device 10 continues to step to display the QR code of the receive address. At step , secure device 10 presumes that coins have been received. Thus, at step block card 40 receives input at both step where coins are presumed received or from step if a receive is verified, information indicative of the verification and the amount will be displayed to the user, if unsuccessful, information indicative of the funds not being received will be displayed to the user. As shown, a 'get Bitcoin balance' process flow may begin at web server 56, when the secure device 10 requests a corresponding user balance.