Back to all blog posts
Aug 15, 2018
The Ultimate Blockchain Patent Teardown
Why blockchain applications are patent-eligible
As a patent practitioner, one of the questions I often get asked is whether distributed ledger technology (DLT), such as blockchain, is patentable. I naturally respond in the affirmative (with some qualifiers of course), and inevitably there is a deluge of follow-up questions and statements such as: “That can’t be! Blockchain is just software, and isn’t it nearly impossible to get patents for software these days? or “This technology has been around for almost 10 years, there is nothing new to patent here,” and so forth.
Exemplary patents related to blockchain technology
According to a recent analysis by Thomson Reuters, 225 out of the 406 blockchain-related patents (55.4%) filed in 2017 were filed by applicants based China, 91 (22.4%) blockchain-related patents were filed by U.S. applicants, and the North American corporation with the most blockchain-related patents to date (50) is Bank of America Corp. Other top North American blockchain-related patent holders include International Business Machines Corporation, Mastercard International Incorporated, Accenture Global Solutions Limited, and Toronto Dominion Bank. While there is not a single foundational patent that covers blockchain technology, most of the blockchain-related patents are in the financial services sector, however, other areas in which blockchain technology is being applied include:
- Payment processing and money transfers (e.g. U.S. Patent No. 10,026,082 (issued to Mastercard International Incorporated on July 17, 2018, title: Method and system for linkage of blockchain-based assets to fiat currency accounts);
- Supply chain monitoring (e.g. U.S. Patent No. 9,641,338, issued to SKUChain, Inc. on May 2, 2017, title: Method and apparatus for providing a universal deterministically reproducible cryptographic key-pair representation for all SKUs, shipping cartons, and items);
- Rewards programs (e.g. U.S. Patent No. 9,436,935 issued to Coinbase, Inc. on September 6, 2016, title: Computer system for making a payment using a tip button);
- Digital IDs (e.g. U.S. Patent No. 10,007,913, (issued to ShoCard, Inc. on June 26, 2018, title: Identity management service using a blockchain providing identity transactions between devices);
- Data sharing (e.g. U.S. Patent No. 9,942,259, issued to Socure Inc. on April 10, 2018), title: Risk assessment using social networking data);
- Digital voting (e.g. U.S. Patent No. 9,836,908 (issued to Blockchain Technologies Corporation on December 5, 2017, title: System and method for securely receiving and counting votes in an election);
- Real estate, land, title transfers (e.g. U.S. Patent No. 9,992,028 issued to International Business Machines Corporation on June 5, 2018, title: System, method, and computer program product for privacy-preserving transaction validation mechanisms for smart contracts that are included in a ledger);
- Tax regulation and compliance (e.g. U.S. Patent No. 9,298,806, issued to Coinlab, Inc. on March 29, 2016, title: System and method for analyzing transactions in a distributed ledger);
- Security and Authentication (e.g. U.S. Patent No. 9,875,592 issued to International Business Machines Corporation on January 23, 2018, title: Drone used for authentication and authorization for restricted access via an electronic lock);
- Wills or inheritances (e.g. U.S. Patent No. 9,853,819, issued to Guardtime IP Holdings Limited on December 26, 2017, title: Blockchain-supported, node ID-augmented digital record signature method);
- Equity trading (e.g. U.S. Patent No. 9,870,562 issued to Mastercard International Incorporated on January 16, 2018, title: Method and system for integration of market exchange and issuer processing for blockchain-based transactions);
- Managing Internet of Things networks (e.g. U.S. Patent No. 9,928,290, issued to Accenture Global Solutions Limited on March 27, 2018, title: Trust framework for platform data);
- Tracking prescription drugs (e.g. U.S. Patent No. 10,002,277 issued to Merck Patent GmbH on June 19, 2018 Reader device for reading a marking comprising a physical unclonable function); and
- Asset-based tokens (e.g. U.S. Patent No. 9,747,586, issued to CPN Gold B.V. on August 29, 2017, title: System and method for issuance of electronic currency substantiated by a reserve of assets).
Therefore, this non-exhaustive list illustrates that patents related to blockchain technology have been issued, and continue to be issued, by the United States Patent and Trademark Office (USPTO), despite the 2014 U.S. Supreme Court ruling in Alice Corp. v. CLS Bank (Alice) which has severely impacted patents for computer-related inventions, particularly software patents. The Alice case involved a computerized scheme for mitigating settlement risk (U.S. Patent No. 5,970,479; U.S. Patent No. 6,912,510; U.S. Patent No. 7,149,720; U.S. Patent No. 7,725,375). The Supreme Court held that “the claims at issue are drawn to the abstract idea of intermediated settlement, and that merely requiring generic computer implementation fails to transform that abstract idea into a patent-eligible invention” under 35 U.S.C. § 101. The court, however, did not specify what would make the invention patent-eligible, except that an invention could only qualify for a patent if it delivered something “significantly more” than an abstract idea. Following, the Alice decision, the number of software patent applications rejected by the USPTO skyrocketed, and the Federal Courts invalidated hundreds of patents for computer-related inventions.
The question now is: “How were these companies that hold blockchain-related patents able to fend off Alice-based patent non-eligibility rejections and rejections under 35 U.S.C. § 101?” One way to determine this is to perform a complete teardown of a blockchain-related patent (similar to a product teardown), that is, strip the blockchain-related patent down to its component parts: the title, the abstract, the summary of the invention, the drawings, the detailed description of the invention, and lastly the all-too-important claims. Included in this reverse-engineering process is also a review and analysis of the prosecution history of the blockchain-related patent to gain some insights into the manner in which the description and the claims were drafted, and also how the claims were amended during prosecution, and the arguments that were put forth in order to overcome the Examiner’s rejections under 35 U.S.C. § 101.
Teardown of a Blockchain Patent
An exemplary blockchain-related patent is U.S. Patent No. 10,007,913, which was issued to ShoCard Inc., a blockchain startup founded in 2015 and based in Cupertino, U.S.A. The patent was issued on June 26, 2018, and is a fine specimen to disassemble because the invention solves a problem that we are all too familiar with, and it clearly articulates a real-world application of blockchain technology.
The invention described in the application tackles the problem of identity theft, and is aptly entitled: “Identity management service using a blockchain providing identity transactions between devices”.
The background of the invention succinctly spells out the problem being addressed, specifically that current systems in place for curbing identity theft are largely ineffective as they can be attacked and can be easily defeated. The patentee provides an example of two-factor authentication methods for carrying out a transaction, which involves the use of a bank card/credit card and a PIN or a unique code provided via a text message.
The summary of the invention outlines several embodiments for managing the identity of users, and mirrors the language of the independent claims.
The description of the invention reveals how users and enterprises can establish their identities with one another in a secure manner, and how the verification of transactions e.g. login, sharing personal information, or completing a financial transaction, is accomplished in an expedient and frictionless way. To aid in the description of the invention, U.S. Patent No. 10,0007,913 includes a number of drawings such as block diagrams pertaining to the system architecture and flowcharts outlining the various processes for carrying out the method steps for identity verification. For example, one of the schematics shows a simplified block diagram of a system and method for sealing an identity of a person in a public storage facility, while another shows a flowchart diagram for a method for verifying an acknowledgement record and its underlying certification record.
The main steps for practicing the invention include: (a) a user creating an identity; (b) storing the user identity information on the user device; (c) encrypting the user identity information on the user device; (d) hashing and digitally signing the user data (e); writing the hashed, signed data on to the blockchain; and (f) sharing the personal information with a third party once the identities of the user and the third party have been verified on the blockchain.
In more detail, step (a) involves the creation of the identity based on a valid government-issued ID with personal data which identifies the user e.g. driver license or passport. The personal data can include a photo of the user; the user's name, address and driver license number, and/or a bar code, a QR code or similar computer code for storing, scanning and/or retrieving additional data. The identification card can be a government-issued form of identification such as an employee badge, military identification, political documentation, or the like. The identification card can also be a privately issued form of identification such as a student ID, library card, social club card, or any other form of identification issued by a third party. Using an input device, such as the user’s smartphone with an application program (i.e. the ShoCard App), the user takes a picture of the valid government-issued ID, and the app extracts the personal information from the captured ID.
Next, in steps (b) and (c) the input data collected from user's smartphone is encrypted using software, firmware, hardware, or any combination thereof, with a public key and the public key is paired with an associated private key as is conventional when generating such keys using a Rivest–Shamir–Adleman (RSA) encryption algorithm, an Elliptic Curve Digital Signature Algorithm (ECDSA), or other encryption algorithms. The encrypted data is then stored locally on the user's smartphone, and can then only be accessed with the private key of the user on the user's smartphone.
In step (d) algorithms, such as a Secure Hash Algorithm (SHA) algorithm implemented in software, firmware and/or hardware, uses the input data (e.g., personal information collected) to provide or generate a hash value or hash data. Using the private key on the input device, a digital signature on the hash value is performed using digital-signature logic which may be defined by separate code, firmware, and/or hardware. The digital-signature logic then passes the signed hash value and the public key to a user accessible interface (e.g., a graphical user interface or GUI), which is part of the application (or app) that includes encryption logic, hashing logic, and digital-signature logic, and/or other modules or code.
Next, in step (e) via the user accessible interface, the digitally signed hash value and the public key is transmitted to a public storage facility such as a blockchain database or any other public or private distributed database via the Internet, such that the digitally signed hash value is written or sealed on the blockchain. Accordingly, a record of the data is generated and can be later verified, and if the data is modified, the hash will not match. The blockchain database then sends back a transaction number corresponding to the transmitted hash value and public key.
In step (f) cryptographic operations are used to authenticate that particular data is from a particular user. Anyone who has access to the public key can verify the data with the signature and determine that the data presented is identical to the data that was signed with a private key previously and no other key. This provides for authentication of data by any third party, but only when the user explicitly chooses to share the data.
The claims section is the heart of the patent, in that the claims define the limits of exactly what the patent covers, and does not cover. U.S. Patent No. 10,007,913 comprises 22 claims, 4 of which are independent claims and directed towards methods for managing an identity of a user, a non-transitory computer-readable medium storing a computer program for managing an identity of a user, and a system for managing an identity of a user.
Representative independent claim 15 as originally filed in 2016 recited:
A method, comprising operations of:
receiving personal data identifying a user from an identification card, wherein the personal data is received on a first smartphone;
creating a hash value from the personal data using a hashing algorithm;
signing the hash value with a digital signature created using a first private key paired with a first public key;
transmitting, over a network, the signed hash value and the first public key from the first smartphone to a blockchain database;
receiving a first transaction number from the blockchain database; and
transmitting the first transaction number and the personal data to a second smartphone, wherein logic on the second smartphone,
uses the first transaction number to retrieve the signed hash value and the first public key from the blockchain database,
hashes the personal data using the hashing algorithm to create a generated hash value,
verifies that the hash value in the signed hash value is the same as the generated hash value,
verifies that the signed hash value was signed with the first private key, and
creates a certification.
It is clear that the claimed method mirrors the above-noted steps (a) to (f), and are drafted as broadly as possible to cover all aspects of the invention as described in the detailed description, including its equivalents or likely future versions.
During the examination of the application, the Examiner did not find any prior art references that described the invention, however, the above-noted claim was rejected under 35 U.S.C. § 101 “because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more” and “the series of steps for certifying personal data identifying a user, which is an idea of itself and thus, an abstract idea.” The Examiner also rejected the claim citing Alice:
“If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include fundamental economic practices; certain methods of organizing human activities; an idea itself; and mathematical relationships/formulas.”
Clearly on a roll, the Examiner further stated that the method steps of independent claim 15 could be performed mentally (or by a human using a pen and paper), and were similar to the concepts identified as abstract ideas by the courts, such as collecting information, analyzing it, and displaying certain results of the collection and analysis (Electric Power Group, LLC, v. Alstom S.A. et al., Fed. Cir. 2016).
In response to the Examiner’s rejections, ShoCard Inc. argued that:
“the claims of the invention were directed to more than the collecting of information, the analyzing the information through mental steps, and the presenting of the results of the analysis that were ruled abstract (see page 7, Electric Power Group) because “the present claims provide the ability for managing the identity of a user by creating a hash value from personal data, signing the hash value using a public/private key pair, transmitting the signed hash value to a blockchain database, receiving a transaction number from the blockchain database, and transmitting the transaction number and personal data to a second smartphone for certification including retrieving the signed hash value and public key from the blockchain, hashing the personal data, verifying the signed hash value and the generated hash value are the same, verifying that the signed hash value was signed using the private key, and creating a certification to certify the personal data was signed using the first private key and was stored to the blockchain. Because the claimed embodiments go beyond the application of human performed processes by improving the relevant technology, Cybersource cannot show ineligible subject matter.
In particular, independent claim 15, as amended, does provide for a unique and specific way of solving the computer-related technological problem (e.g., verifying the digital identity of a user) or technology improvement that has not been applied before in computers.
Further, the claims of the present invention provide significantly more to the technical field (e.g., certifying personal data identifying a user) that has not been applied before in computers or networking, and recite patent-eligible subject matter. That is, Applicant believes that the claimed invention points to a combination that amounts to significantly more than an abstract idea because the claimed solution is necessarily rooted in computer technology since they address a problem (e.g., digitally certifying the identity of a user) specifically arising in the realm of computer networks.
In particular, the claimed embodiments provide a technological improvement over traditional verification and certification processes, such as those using passwords, to provide for improved certification of personal data identifying a user through a multi-step process involving the creation of signed hash value and delivery of the signed hash value to a blockchain database, receipt of a transaction number based on the signed hash value, and delivery of the transaction number and personal data to a second smartphone for certification based on the signed hash value and a newly generated hash value. Beyond the use of passwords, the certification process further provides for retrieving the signed hash value and public key from the blockchain, hashing the personal data, verifying the signed hash value and the generated hash value are the same, verifying that the signed hash value was signed using the private key, and creating a certification to certify the personal data was signed using the first private key and was stored to the blockchain.
As such, the claimed invention provides significantly more than the abstract idea by providing an improvement to the technological process of managing the identity of a user by way of making verifiable transactions with a blockchain database using a certification process including the digital identification and certification of a user through the use of a signed hash value, public/private key pair and a blockchain, wherein the certification is configured to certify the personal data was signed using the first private key and was stored to the blockchain, and wherein the certification used for purposes of verifying the identity of the user.”
Original representative claim 15 was amended accordingly to highlight the system components i.e. the hardware, essential for solving the computer-related technological problem of verifying the digital identity of a user, and the technology improvement. Specifically, the processors of the smartphones for executing the computer instructions related to the cryptographic schemes and features of the blockchain i.e. hashing the personal data using the hashing algorithm to create a generated hash value by the second processor; and subsequent verification of the hash value and signed hash value; and certification that the personal data was signed using a first private key and was stored to the blockchain, were added to the claim in order to overcome the 35 U.S.C. § 101 and Alice-based rejections.
The amendments to the claim (underlined portions) are shown below:
A method for managing an identity of a user as executed by a first processor of a first smartphone and a second processor of a second smartphone, the method comprising operations of:
receiving by the first processor personal data identifying the user from an identification card, wherein the personal data is received on the first smartphone;
creating by the first processor a hash value from the personal data using a hashing algorithm;
signing by the first processor the hash value with a digital signature created using a first private key paired with a first public key;
transmitting by the first processor, over a network, the signed hash value and the first public key from the first smartphone to a blockchain database;
receiving by the first processor a first transaction number from the blockchain database; and
transmitting by the first processor the first transaction number and the personal data to the second processor of the second smartphone;
using by the second processor the first transaction number to retrieve the signed hash value and the first public key from the blockchain database;
hashing by the second processor the personal data using the hashing algorithm to create a generated hash value;
verifying by the second processor that the hash value in the signed hash value is the same as the generated hash value,
verifying by the second processor that the signed hash value was signed with the first private key; and
creating by the second processor a certification to certify that the personal data was signed using the first private key and was stored to the blockchain, the certification used for verifying the identity of the user.
Following these arguments and claim amendments, the application was allowed by the USPTO on March 26, 2018.
Building up a blockchain patent
Now with the blockchain patent’s innards bared, here are some instructive patent drafting lessons for positioning a blockchain-related patent application for an early allowance by the patent office:
(i) The title, abstract and claims should be drafted such that the patent application is assigned to the “business cryptography” subclass (Art Unit 3685) of the USPTO’s Technology Center (TC) 3600, an examination unit focused on e-commerce patent applications. Patent applications in “business cryptography” subclass have been impacted the least by the Alice decision, and therefore the technical details of the cryptographic aspects inherent in the application of blockchain technology should be included in the claims, especially. Patents applications that end up being assigned to other art units within TC 3600 are likely to face a considerably more arduous path to allowance, if at all.
(ii) The specification should be drafted with a heavy focus on how the invention is tied to the underlying hardware, and should include comprehensive technical details and terminology, such as security aspects (e.g., encryption, hashing, digital signatures), networking aspects (e.g. consensus protocols, smart contract protocols). Focussing on the distributed ledger features, instead of the transaction features, will greatly enhance the prospects of overcoming Alice-based rejections and §101 rejections by facilitating the analysis that the inventive concept is “significantly more” than an abstract idea.
(iii) The problem being solved by the invention should be clearly defined in the background section of the specification. A well-written background may be critical during prosecution as it may come in handy for highlighting the deficiencies of the state of the art that make the invention patentable. Accordingly, the prior art should be fully discussed and disparaged, if necessary, in order to let the invention shine. The background may also provide the necessary ammunition useful for tackling Alice-type rejections i.e. arguing that the claimed features that distinguish over the cited prior art as constituting the “significantly more,” and that there is an improvement in the technology. In Enfish LLC v. Microsoft Corporation, the Court relied on the specification’s extensive discussion of the “conventional” prior art to support the conclusion that the invention was an improvement over the prior art.
(iv) Technical drawings, such as system architecture diagrams, flowcharts, and dataflow diagrams, transaction process flow diagrams, and user interface (UI) screenshots, should be included to demonstrate how the invention is implemented and thus avoid a §101 rejection based on the claimed subject matter being drawn to a patent-ineligible abstract idea.
(v) The claims, whether they are directed towards a system, a method or a computer-readable medium, should be drafted to recite a fair amount of physical elements or hardware.
This article was originally published in the Association of Intellectual Property Firms (AIPF) IP LAW BUGLE, August 2018. ISSUE 22