About a week before the holidays, the U.S. Patent and Trademark Office quietly published a trio of new subject matter eligibility examples directed to the abstract idea exception to patentability.  These are the latest in a series of examples provided by the USPTO to its examining corps, the series including previous examples published in December 2014, January 2015, and July 2015 (other USPTO publications include example claims directed to the law of nature and natural phenomenon exceptions).  While the focus of this guidance is to educate examiners about how to determine whether pending claims are valid under 35 U.S.C. § 101, practitioners and patentees will find the examples to be helpful when considering how to draft and amend claims.

Notable about the new examples (which we will call "the December 2016 examples" for sake of differentiation), is that all three are so-called business methods.  In the January 2015 and July 2015 sets, the example claims focused on computer hardware and software -- this is the USPTO's first detailed characterization of business method claims.  The line between software and business methods is blurry at best (many business methods are intended to be computer-implemented).  But, as we will see, the December 2016 examples do little to sharpen any such distinction.

In recent years, business methods have become the red-headed step child of patent law.  In the 1994 State Street Bank & Trust v. Signature Financial Group case, the Federal Circuit held that business methods are patent-eligible so long as they produce a "useful, concrete and tangible result."  This test was overturned in Bilski v. Kappos, where the Supreme Court found a disembodied business method claim to be too abstract for eligibility.  Post-Bilski, however, all one had to do was add hardware components to a claim in order to meet the requirements of § 101.  Given the aforementioned overlap between software and business methods, doing so was not particular burdensome in most cases.

But in 2014, the Supreme Court opined once again regarding a business method's validity under § 101, this time clarifying that merely adding computer elements to an otherwise abstract claim was just "draftsman's art."  This case, of course, was Alice Corp. Pty. Ltd. v. CLS Bank Int'l, which set forth a two-part test to determine whether claims are directed to patent-eligible subject matter.  One must first determine whether the claim at hand is directed to a judicially-excluded law of nature, a natural phenomenon, or an abstract idea.  If so, then one must further determine whether any element or combination of elements in the claim is sufficient to ensure that the claim amounts to significantly more than the judicial exclusion.  But generic computer implementation of an otherwise abstract process does not qualify as "significantly more."

It is well-established that Alice had a deleterious impact on a large number of patents and applications, with the district courts finding claims challenged under § 101 to be invalid at a rather astounding rate of 75% immediately after the decision came down (more recently this rate has dropped below 55%).  While several art units in the USPTO issued significantly more § 101 rejections post-Alice, none was impacted more than the technical center 3600 which examines most business method patent applications.  Therein, these applications have been subject to a rejection rate of over 85%.

As a consequence, there has been a significant amount of consternation and wringing of hands amongst patentees and attorneys over how to claim inventions that might incorporate financial and/or administrative subject matter.  Now that the USPTO has spoken on the issue, some extent of clarity has been added to the mix.  Still, it is likely that this aspect of the eligibility debate will remain open for some time to come.

Example 34

Example 34, the first of the December 2016 examples, is directed to the fact pattern of the BASCOM Global Internet v. AT&T Mobility LLC case, and the USPTO closely follows the reasoning of the Federal Circuit therein.  In short, BASCOM stands for the principle that a claim directed to an abstract idea, with addition elements that are individually generic and conventional, can be patent-eligible if the combination of these elements is nonnconventional and non‐generic.  Since we have covered the BASCOM decision in detail, we will not repeat the analysis here.

Example 35

Example 35 is a hypothetical invention provided by the USPTO.  Thus, it is not based on the facts of any particular case.  This example is titled "Verifying A Bank Customer's Identity To Permit An ATM Transaction," but is better summarized as "two-factor authentication for ATM transactions."

As background, it is assumed that basic ATM transactions are well-known.  According to the example:

To conduct a transaction, a customer typically inserts a bank card into the appropriate slot in the ATM and inputs a personal identification number (PIN) that verifies that the user is an authorized user for the bank account associated with the bank card.  The account data is read from the card using the reader in the ATM and the PIN associated with the card.  The network communicator transmits the read data and PIN to a remote computer at the financial institution, which then transmits instructions back to the ATM regarding authorization to carry out the requested transaction.

These transactions, however, are subject to at least two types of fraud.  An unauthorized could gain access to a user's card and PIN, and fraudulently use these to obtain funds from the user's account.  Also, a false card reader can be affixed to the ATM, allowing unauthorized users to acquire information about the card and PIN.

The hypothetical invention purports to solve both of these problems by requiring two-factor authentication for all ATM transactions.  In order to use an ATM, the user must be issued a smart card and download an application to their wireless communication device (e.g., smartphone).  When the ATM reads the user's card (which may be accomplished by the card reader or wirelessly via RFID), the ATM generates a random code and displays it to the user on a screen of the ATM.  The user must then enter this code into the application.  Then, the wireless communication device transmits a secure acknowledgment of the code to the ATM or a related system for verification.  In some embodiments, the ATM transmits the code to the wireless communication device (e.g., by way of Bluetooth).  Responsively, the application displays a representation of the code on the screen of the wireless communication device, which can be scanned by the ATM to verify the code.  In either case, when the code is validated within a pre-defined period of time from its generation, the ATM unlocks its keypad so that the user can enter his or her PIN.

According the example, this invention involves the following improvements:

Applicant's method allows the ATM to receive user card data in a more secure and efficient manner.  Customer card data entry begins before PIN entry and verification, so if the ATM user is not the authorized customer and does not have the appropriate verification software on their mobile device, the transaction is concluded before entry of the PIN.  This method prevents skimming and other techniques to fraudulently obtain a customer's PIN and even theft of the card since the downloaded software can authenticate the user and likewise authenticate the ATM before the PIN is produced.

The example includes three claims, which we will discuss in turn.  Claim 1 recites:

1.  A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer's identity, comprising the steps of:
    obtaining customer‐specific information from a bank card,
    comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer's identity, and
    determining whether the transaction should proceed when a match from the comparison verifies the authenticity of the customer's identity.

Conducting part one of the Alice analysis, the USPTO characterized the claim as being directed to the abstract idea of "fraud prevention by verifying the authenticity of the customer's identity prior to proceeding with a banking transaction" which is a conventional, long-standing business practice.  Thus, the claim is analogous to those found to be abstract in Alice, Bilski v. Kappos, CyberSource Corp. v. Retail Decisions, Inc., and other cases.

Moving to part two, the USPTO found that the claim recites the additional limitations of "obtaining customer‐specific information from a bank card" and "a processor comparing data."  The former, however, is a conventional action of an ATM and "is recited at a high level of generality such that it amounts to insignificant pre‐solution activity," while the latter "does not represent any computer function beyond what processors typically perform."  Therefore, taken individually, these additional elements do not confer patent-eligibility.  Further, even when viewed as an ordered combination, this combination of elements is "no more than the sum of their parts, and provides nothing more than mere automation of verification steps that were in years past performed mentally by tellers when engaging with a bank customer."  Since, "mere automation of an economic business practice does not provide significantly more," the USPTO concluded that this claim fails to meet the requirements of § 101.

The next example claim recites:

2.  A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer's identity, comprising the steps of:
    obtaining customer‐specific information from a bank card,
    comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer's identity, by
    generating a random code and transmitting it to a mobile communication device that is registered to the customer associated with the bank card,
    reading, by the automated teller machine, an image from the customer's mobile communication device that is generated in response to receipt of the random code, wherein the image includes encrypted code data,
    decrypting the code data from the read image, and
    analyzing the decrypted code data from the read image and the generated code to determine if the decrypted code data from the read image matches the generated code data, and
    determining whether the transaction should proceed when a match from the analysis verifies the authenticity of the customer's identity.

Beginning with part one of Alice, the USPTO concluded that this claim also recites an abstract method of fraud prevention by identity verification -- a fundamental business transaction.  Moving quickly to part two, the USPTO viewed the generating, reading, decrypting, and analyzing sub-steps individually as additional limitations.  According to the USPTO, "obtaining information from a bank card and the comparing data do not provide significantly more" for similar reasons as the additional elements of claim 1.  Further, the "the processor and the mobile communication device are recited at a high level of generality and perform programmed functions that represent conventional and generic operations for these devices, including reading data, generating random codes, and analyzing data."  Thus, individually, these elements do not provide an inventive concept.

But, when viewed in combination, the elements of the claim provide for "a nonconventional and non‐generic way to ensure that the customer's identity is verified in a secure manner that is more than the conventional verification process employed by an ATM alone."  Particularly, these steps represent "a sequence of events that address unique problems associated with bank cards and ATMs (e.g., the use of stolen or 'skimmed' bank cards and/or customer information to perform unauthorized transactions)."  As such, the claim is a practical application of an abstract idea to solve a specific problem through nonconventional technical means, and is patent-eligible.

The final example claim recites:

3.  A method of conducting a secure automated teller transaction with a financial institution by authenticating a customer's identity, comprising the steps of:
    obtaining customer‐specific information from a bank card,
    comparing, by a processor, the obtained customer‐specific information with customer information from the financial institution to verify the customer's identity, by
    generating a random code and visibly displaying it on a customer interface of the automated teller machine,
    obtaining, by the automated teller machine, a customer confirmation code from the customer's mobile communication device that is generated in response to the random code, and
    determining whether the customer confirmation code matches the random code, and
    automatically sending a control signal to an input for the automated teller machine to provide access to a keypad when a match from the analysis verifies the authenticity of the customer's identity, and to deny access to a keypad so that the transaction is terminated when the comparison results in no match.

Applying step one of Alice, the USPTO concluded that this claim, like claims 1 and 2, is directed to the abstract idea of "a method of fraud prevention by identity verification before proceeding with a banking transaction."  Regarding step two, the USPTO observed that the generating, obtaining, and determining sub-steps, when considered individually, are generic or conventional steps recited at a high level of generality.  Accordingly, from this perspective, they do not lend eligibility to the claim.

Nonetheless, when considered in combination, these elements "operate[] in a non‐conventional and non‐generic way to ensure that the customer's identity is verified in a secure manner that is more than the conventional verification process employed by an ATM alone."  Like the Office's position regarding claim 2, this combination goes beyond the conventional sequence of events in an ATM transaction, and therefore entails an inventive concept.

Analysis

The inclusion of BASCOM in these examples as a "business method" is curious, though telling.  While the claims in BASCOM are arguably technical rather than business-oriented, the USPTO relied heavily on the reasoning of that case to justify its positions on the claims of Example 35.

But more substantively, the USPTO is making it clear that in order for a claim related to a financial or business transaction to be eligible, that claim should recite technical content in detail and not just at a high level.  The claim should include more than just a recitation that a transaction occurs, but the steps used to enable that transaction.  Further, the claimed invention should enable capabilities that were not enabled or not possible with known, conventional transactions.  In other words, when a claim uses technological steps to provide a nonconventional and desirable result, the claim will be viewed more favorably in the § 101 determination.  In contrast, claim 1 is ineligible because it recites the transaction without specifying exactly how it takes place, while the steps and the combination thereof were arguably known and conventional.

Of course, this begs the question of whether pure business methods that recite new and/or improved non-technical procedures are eligible post-Alice.  The USPTO does not provide answer here, perhaps because the Federal Circuit has yet to find such a claim valid.