CXLOYALTY, INC., Appellant v. MARITZ HOLDINGS INC., Cross-Appellant
2020-1307, 2020-1309
United States Court of Appeals for the Federal Circuit
February 8, 2021
Appeals from the United States Patent and Trademark Office, Patent Trial and Appeal Board in No. CBM2018-00037.
ROBERT M. EVANS, JR., Lewis Rice LLC, St. Louis, MO, argued for cross-appellant. Also represented by MICHAEL J. HARTLEY.
Before PROST, Chief Judge, LOURIE and HUGHES, Circuit Judges.
cxLoyalty, Inc. (“cxLoyalty“) petitioned for a covered business method (“CBM“) review of claims 1–15 of U.S. Patent No. 7,134,087 (“the ‘087 patent“), which is owned by Maritz Holdings Inc. (“Maritz“). The Patent Trial and Appeal Board (“Board“) instituted CBM review and concluded that original claims 1–15 are ineligible for patenting under
We do not have authority to entertain Maritz‘s challenge to the CBM eligibility of the ‘087 patent. SIPCO, LLC v. Emerson Elec. Co., 980 F.3d 865, 867 (Fed. Cir. 2020). As to the merits, we conclude that both the original and substitute claims are directed to patent-ineligible subject matter under
BACKGROUND
I
Customer loyalty programs “issue points to customers . . . as a reward for certain activities” and “allow[] the customer[s] to redeem the points” for various goods and services. ‘087 patent col. 1 ll. 16–23. The purpose of such programs is to “create a loyalty or affinity with the customer and encourage the customer to continue a desired behavior.” Id. at col. 1 ll. 19–21.
Before the invention of the ‘087 patent, loyalty programs frequently “provide[d] the customer with a limited
The ‘087 patent explains:
Some rewards are of a nature that human intervention is needed to redeem/fulfill [them]. For example, if the customer selects a roundtrip airline ticket, the loyalty program on behalf of the customer or the customer directly would purchase the ticket through a selected travel agent or a selected airline employee and provide the ticket (or have it sent) to the customer.
Id. at col. 1 ll. 37–43.
The invention of the ‘087 patent “eliminate[s] the human intervention” needed “to redeem such rewards.” Id. at col. 1 ll. 49–50. The ‘087 patent relates to a system and method for permitting a customer of a loyalty program to redeem loyalty points for rewards offered by vendors without the need for human intervention. More specifically, a graphical user interface (“GUI“) provides the interface for the participant (i.e., a customer) to communicate with a web-based vendor system, such as an airline-reservation system. Id. at col. 2 ll. 14–26, col. 4 ll. 11–29. An application programming interface (“API“) interfaces with the GUI and the vendor system to facilitate information transfer between them. Id. at col. 2 ll. 11–16.
The API receives vendor-related information from the vendor system, such as “a listing of the [products] available
The GUI receives participant-related information from the participant, such as the participant‘s name, address, and selection of goods or services to purchase in exchange for points. Id. at col. 2 ll. 15–18, col. 6 ll. 18–26. After receiving this information, the GUI interfaces with the loyalty program and the participant‘s point account to ensure that the participant has enough points to make the desired purchase. Id. at col. 4 ll. 29–33. If so, the GUI purchases the desired item with a program account, such as a cash account or shadow credit card, that is connected to the loyalty program. Id. at col. 4 ll. 33–41. The GUI completes this transaction by providing the participant-related information (including the purchase request) and the program account information to the API, which provides that information to the vendor system to make the purchase. Id. at col. 4 ll. 47–50, col. 5 ll. 55–58. The specification explains that the API‘s function of “transmitting information to the vendor system” is its “standard function.” Id. at col. 7 ll. 9–14.
The system may complete the purchase with a “shadow” credit card—a credit card that is “hidden or ‘shadowed’ from the participant so that the participant is not aware that the transaction is actually being transacted using the shadow credit card or other program account.” Id. at col. 4 ll. 42–47. Instead, from the participant‘s perspective, the “transaction with the vendor system [occurred] based in whole or in part on the points in the participant‘s point account.” Id. at col. 3 ll. 6–9. At the same time, from the vendor system‘s perspective, the transaction occurred “with the participant based on the program account.” Id. at col. 3 ll. 9–12.
Claim 1 is representative of the original claims and provides:
1. A computerized system for use by a participant of a program which awards points to the participant, wherein the awarded points are maintained in a point account for the participant, said system for permitting the participant to transact a purchase using the awarded points with a vendor system which transacts purchases in currency, said system comprising a processor including instructions for defining:
an application programming interface (API) for interfacing with the vendor system;
a program account hidden from the participant connected to the program for use in currency transactions;
a graphical user interface (GUI) for providing an interface between the participant and the API and for communicating with the program;
wherein said GUI includes instructions for receiving participant-related information from the participant and providing the received participant-related information to the API;
wherein said GUI includes instructions for receiving information regarding the program account hidden from the participant and for providing the received program account information to the API;
wherein said API is adapted to receive the participant-related information and the program account
information from the GUI and adapted to provide the received participant-related information and the received program account information to the vendor system; wherein said API is adapted to receive vendor-related information from the vendor system and adapted to provide the received vendor-related information to the GUI; and
wherein said GUI includes [i]nstructions for receiving vendor-related information from the API and for providing the received vendor-related information to the participant;
such that from the perspective of the participant, the participant uses the GUI to conduct a purchase transaction with the vendor system based in whole or in part on the points in the participant‘s point account; and
such that from the perspective of the vendor system, the vendor system conducts the purchase transaction with the participant as a currency transaction based on the program‘s program account hidden from the participant whereby the participant is not aware that the purchase transaction with the vendor system is being transacted using program account.
‘087 patent claim 1.
Substitute claims 16 and 22 are representative of the substitute claims. Compared with claim 1, substitute claim 16 adds in relevant part that the GUI includes instructions for converting the vendor-related information from the format of the vendor system into a format of the GUI. Claim 16 provides (with underlines indicating language added to original claim 1 and brackets indicating language removed):
16 (replaces claim 1): A computerized system for use by [[a]] participants of a program which awards points to the participants, wherein the awarded points for each participant are maintained in a point account for the respective participant, said system for permitting [[the]] each participant to transact a purchase using the respective awarded points with a vendor system which transacts purchases in currency, said system comprising a processor including instructions for defining:
an application programming interface (API) for interfacing with the vendor system;
a program account hidden from the participants connected to the program for use in currency transactions;
a program database storing information about the program including a listing of the point accounts of the participants;
a graphical user interface (GUI) for providing an interface between the participants and the API and for communicating with the program, wherein the GUI is configured so that the participants can connect to the GUI using an internet connection;
wherein said GUI includes instructions for receiving participant-related information from [[the]] each participant via the internet connection and providing the received participant-related information to the API;
wherein said GUI includes instructions for receiving information regarding the program account hidden from the participants and for providing the received program account information to the API;
wherein said API is adapted to receive the participant-related information and the program account
information from the GUI and adapted to provide the received participant-related information and the received program account information to the vendor system; wherein said API is adapted to receive vendor-related information from the vendor system in a format of the vendor system and adapted to provide the received vendor-related information to the GUI; [[and]]
wherein said GUI includes instructions for receiving vendor-related information from the API, for converting the received vendor-related information from the format of the vendor system into a format of the GUI, and for providing the received vendor-related information to the participants in the format of the GUI via the internet connection;
wherein the computerized system is configured to use the program account to complete purchase transactions with the vendor system based on participant-related information received from the participants via the internet connection including purchase requests based on points; and
wherein in response to each completed purchase transaction, the computerized system is configured to store an indication of the completed purchase transaction in the program database and display an order message indicating the completion of the purchase transaction to the respective participant;
such that from the perspective of the participants, the participants use[[s]] the GUI to conduct [[a]] the purchase transactions with the vendor system based in whole or in part on the points in [[the]] each participant‘s point account; and
such that from the perspective of the vendor system, the vendor system conducts the purchase
transactions with the participants as [[a]] currency transactions based on the program‘s program account hidden from the participants whereby the participants [[is]] are not aware that the purchase transactions with the vendor system [[is]] are being transacted using the program account.
J.A. 413-15.
Compared with claim 1, substitute claim 22 adds in relevant part that the GUI communicates with multiple APIs having corresponding vendor systems, allowing participants to use the GUI to make points-based purchases directly from multiple third-party vendor systems. Claim 22 provides (with underlines indicating language added to original claim 13 and brackets indicating language removed):
22 (replaces claim 13): A computerized system for permitting a participant to transact a purchase using awarded points with a vendor system which transacts purchases in currency, said system comprising a processor including instructions for defining:
a loyalty program which awards points to a participant, wherein the awarded points are maintained in a point account for the participant;
an application programming interface (API) for interfacing with the vendor system;
a program account hidden from the participant connected to the program for use in currency transactions;
a program database storing information about the loyalty program including a listing of point accounts of a plurality of users of the loyalty program including the participant;
a graphical user interface (GUI) for providing an interface between the participant and the API and for communicating with the program, wherein the GUI is configured so that the participant can connect to the GUI using an internet connection; wherein said GUI includes instructions for:
receiving participant-related information from the participant via the internet connection and providing the received participant-related information to the API;
receiving a purchase request from the participant via the internet connection to conduct a purchase with the vendor system based on the points in the participant‘s point account;
receiving information regarding the program account hidden from the participant from the loyalty program;
converting the received purchase request based on the points into a corresponding purchase request based on the program account information if the point account has sufficient points to cover the purchase; [[and]]
providing the corresponding purchase request based on the program account information to the API wherein the API is adapted to receive the corresponding purchase request from the GUI and provide the received corresponding purchase request to the vendor system as a purchase request based on the program account information;
based on the purchase request, completing a purchase transaction with the vendor system on behalf of the participant using the program account;
receiving a vendor purchase confirmation from the vendor system, the vendor purchase confirmation
comprising a record of the order being successfully placed based on the program account information; and in response to receiving the vendor purchase confirmation:
storing an indication of the completed purchase transaction in the program database;
and displaying an order message to the participant indicating the completion of the purchase transaction;
wherein said API is adapted to receive the participant-related information from the GUI and to provide the received participant-related information to the vendor system;
wherein said API is adapted to receive vendor-re-lated information from the vendor system and provide the received vendor-related information to the GUI; and
wherein said GUI includes instructions for receiving vendor-related information from the API and providing the received vendor-related information to the participant via the internet connection;
such that from the perspective of the participant, the participant uses the GUI to conduct a purchase transaction with the vendor system based in whole or in part on the points in the participant‘s point account; and
such that from the perspective of the vendor system, the vendor system conducts the purchase transaction with the participant based on the loyalty program‘s program account hidden from the participant whereby the participant is not aware that the purchase transaction with the vendor system is being transacted using the program account;
wherein the API comprises an airline reservation system API and the vendor system comprises an airline reservation system; and
wherein the processor further includes instructions for providing another vendor system API for interfacing with another vendor system of a vendor that sells other goods or services, the other vendor system API being adapted to:
receive the participant-related information from the GUI and provide the received participant-related information to said other vendor system; and
receive vendor-related information from said other vendor system and provide the received vendor-related information from said other vendor system to the GUI.
J.A. 425-28.
II
The Board concluded that the ‘087 patent is eligible for CBM review, that the original claims are patent ineligible under
As to the original claims, the Board determined that claim 1 was illustrative. Decision, at 7. The Board concluded:
Petitioner has shown persuasively that, by virtue of the limitations reproduced above, claim 1, as a whole, recites facilitating, or brokering, a commercial transaction (i.e., the sale and purchase of goods and services) between a purchaser using a first form of value (i.e., a rewards program participant using points in whole or in part) and a seller transacting in a second form of value (i.e., a vendor system which transacts purchases in currency).
The Board also determined that “Petitioner has shown persuasively that claim 1 does not recite any element or combination of elements that would transform the claim into a patent-eligible application of the alleged abstract idea.” Id. at 47. Rather, “[c]laim 1 merely recites generic and conventional computer components . . . and functionality for carrying out” the abstract idea. Id.; see also id. at 49.
Maritz argued that claim 1 was directed to more than an abstract idea because it permitted a participant to redeem points for rewards “without knowing that the actual transaction is a currency transaction at less than the perceived price.” Id. at 32 (emphasis omitted). The Board rejected this argument for two reasons: first because claim 1 “does not include any requirement that the value of the transaction be concealed from the participant,” and second because claim 1 is directed to the above-identified abstract idea regardless. Id. at 34-37.
The Board concluded that the substitute claims were directed to the same abstract idea as the original claims. Id. at 81–82, 94–95. Unlike for the original claims, however, the Board concluded that the substitute claims contained an inventive concept. Id. at 83, 89, 95, 97. The Board focused heavily on the fact that although cxLoyalty opposed the motion to amend, it “did not submit any [new] testimony . . . or other . . . evidence” in support of its opposition to the motion, relying instead on the same evidence it submitted with respect to the original claims. Id. at 84. Conversely, Maritz did submit new expert testimony specifically supporting the motion to amend. Id. at 88–89; see also id. at 97; J.A. 1753–67 (Weiner Decl. in Support of
cxLoyalty appealed and Maritz cross-appealed. We have jurisdiction to review the Board‘s final written decision under
DISCUSSION
On appeal, cxLoyalty challenges the Board‘s determination that substitute claims 16–23 are patent eligible under
I
In its briefing, Maritz argued that “[c]xLoyalty did not satisfy its burden of establishing that the ‘087 patent is eligible for CBM review.” Maritz‘s Op. Br. 24. After the close of briefing but before oral argument, this court decided SIPCO, LLC v. Emerson Electric Co., in which we
II
Now we turn to the merits of the Board‘s
A
We conclude that the original claims are ineligible for patenting under
As to step one, we agree with the Board that representative claim 1 is directed to “facilitating, or brokering, a
The claims also fail at step two. The claims amount to nothing more than applying the above-identified abstract idea using techniques that are, whether considered individually or as an ordered combination, well-understood, routine, and conventional. The claims apply the abstract idea on a computer by replacing the human intermediary with a GUI and API, but as the Board concluded, representative claim 1 “merely recites generic and conventional computer components (i.e., ‘processor,’ ‘GUI,’ and ‘API‘) and functionality for carrying out” the abstract idea. Decision, at 47. And the “communication of information by GUIs and APIs” was “well-known in the prior art.” Id. at 49; see also id. at 47–51. Accordingly, the claims do not survive step
Maritz argues that claim 1 is eligible for patenting because the claimed invention “conceals the nature of the transaction between the participant and the vendor system such that the participant can redeem points for goods/services without knowing that the actual transaction is a currency transaction at less than the perceived price.” Maritz‘s Op. Br. 32. We disagree.
As an initial matter, and as the Board noted, the claims do not require that the actual dollar amount of the transaction be hidden from the participant. See Decision, at 34. In any event, the claims would be ineligible even if they did include such a requirement because the requirement would also constitute part of the abstract idea. Indeed, loyalty program intermediaries have long brokered loyalty program transactions in a manner where, from the participant‘s perspective, the actual price paid by the loyalty program is withheld from the participant. See, e.g., Maritz‘s Op. Br. 5–7; J.A. 1653–56 (Weiner Decl.).
Maritz also argues that the claims are eligible under
Maritz further contends that the claims are patent eligible at one or both steps because they recite a “novel combination of technical elements” that provides “technological solutions to [a] technological problem within the loyalty awards industry.” Maritz‘s Op. Br. 45–46, 61–64; see, e.g., Amdocs (Isr.) Ltd. v. Openet Telecom, Inc., 841 F.3d 1288, 1300-01 (Fed. Cir. 2016) (holding claim eligible at step two because it “entails an unconventional technological solution to a technological problem,” and the solution “requires that arguably generic components . . . operate in an unconventional manner to achieve an improvement in computer functionality“); BASCOM Glob. Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1350–51 (Fed. Cir. 2016) (holding claims eligible at step two because the claims recited a “technical improvement over prior art ways of filtering . . . content” that “improve[s] the performance of the computer system itself“). Maritz points to expert testimony in support. J.A. 1634–90 (Weiner Decl.).
For the reasons provided above, the claims are directed to an abstract idea, and they implement the abstract idea using conventional techniques; the claims are not directed to a technological solution to a technological problem. Although Maritz points to expert testimony, that testimony merely labels, in conclusory fashion, the invention as a technological solution to a technological problem. We do not accord weight to conclusory expert testimony. See TQ Delta, LLC v. CISCO Sys., Inc., 942 F.3d 1352, 1359 n.5, 1360 (Fed. Cir. 2019).
Furthermore, the claims provide no useful guidance as to how this purported function is achieved and thus cannot be directed to a technological solution. See, e.g., Univ. of Fla. Res. Found., Inc. v. Gen. Elec. Co., 916 F.3d 1363, 1368-69 (Fed. Cir. 2019) (holding claims relating to format conversion ineligible where the “drivers [were] described in purely functional terms” and the claims did not “explain[] how the drivers do the conversion that [the patent owner] points to“).
For these reasons, we conclude that the original claims are ineligible under
B
We also conclude that the substitute claims are also ineligible under
1
Claim 16 is ineligible under
Maritz argues that the added limitation constitutes a technological solution to a technological problem. However, Maritz does not contend that the claimed invention improves the use of computers as a tool by reciting a new way for computers to conduct format conversion. Nor do the claims provide any guidance as to how this purported function is achieved. Thus, claim 16 does not claim a patent-eligible technological solution to a technological problem. See, e.g., Univ. of Fla., 916 F.3d at 1368–69.
Maritz also argues that claim 16 is patent eligible because it recites unconventional subject matter. To that end, Maritz relies on expert testimony providing:
Vendor-specific formats were designed to communicate and transact fundamentally in currency price of the goods or services available for purchase. They lacked the capability to communicate from a reward program participant any special arrangement that might exist between the vendor and the reward program in terms of the price the reward program would ultimately pay on the program account. Furthermore, vendor-specific formats lacked any indication of an association with
the loyalty program. Thus, providing vendor information to a participant in the vendor-specific format would confuse participants about whether they were shopping from the vendor based on the points in their program account, as intended. Additionally, many vendor-specific formats were quite technical and therefore not suitable for unsophisticated participants and there were significant differences between vendor-specific formats. By using a GUI associated with the loyalty program, in communication with an API, to convert vendor information from a vendor-specific format to the format of the GUI, the inventions described in the ‘087 patent could, for the first time, remedy these concerns and provide an e-commerce platform that participants use to purchase goods and/or services directly from third-party vendor systems using points in their point accounts. The uniquely programmed combination of an API and GUI . . . was not well-understood, routine, or conventional in the field of reward programs.
J.A. 1762–63; see also Decision, at 88; Maritz‘s Op. Br. 33, 40-41; J.A. 1634–90 (Weiner Decl.), 1753–67 (Weiner Decl. in Support of Patent Owner‘s Mot. to Amend).
Although this expert testimony invokes the words “well-understood, routine, or conventional,” the type of unconventionality described by Maritz‘s expert does not spare the claims. To be sure, a patent claim may be eligible under
Maritz also analogizes the claims here to those in CardioNet, LLC v. InfoBionic, Inc., 955 F.3d 1358, 1374–75 (Fed. Cir. 2020) on the basis that “both pass [step one] by reciting claim limitations that are more than merely automating a prior art process using a computer.” Maritz‘s Op. Br. 47. But Maritz‘s reliance on CardioNet is misplaced.
The claims in CardioNet related to a cardiac monitoring device that “detects beat-to-beat timing of cardiac activity, detects premature ventricular beats, and determines the relevance of the beat-to-beat timing to atrial fibrillation or atrial flutter, taking into account the variability in the beat-to-beat timing caused by premature ventricular beats identified by the device‘s ventricular beat detector.” 955 F.3d at 1368. The court rejected the argument that the claims were directed to automating basic diagnostic processes that doctors had long used, explaining that “[n]othing in the record in this case suggests that the claims merely computerize pre-existing techniques for diagnosing atrial fibrillation and atrial flutter.” Id. at 1370. In contrast, here the record demonstrates that the claims are directed to the application of longstanding commercial practices using well-understood, routine, and conventional activities. Accordingly, Maritz‘s reliance on CardioNet is not compelling.
Maritz also attempts to liken its claims to those in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), but Maritz‘s reliance on DDR Holdings is likewise unpersuasive. The claims in DDR Holdings did not relate to a longstanding commercial practice but rather to a business challenge particular to the internet, and the claims did not merely employ conventional techniques to apply an abstract idea but rather involved the use of a computer
2
Claim 22 is ineligible under
CONCLUSION
We have considered Maritz‘s remaining arguments but find them unpersuasive. For the foregoing reasons, we affirm-in-part, reverse-in-part, and dismiss-in-part.
AFFIRMED-IN-PART, REVERSED-IN-PART, AND DISMISSED-IN-PART
COSTS
Costs to cxLoyalty.
