DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on May 29, 2026, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when sending the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 29, 2026, has been entered.
Claim Status
The status of claims is as follows:
Claims 1–7, 9–17, 19, and 20 are pending and examined with Claims 1, 11, and 19 in independent form.
Claims 1, 11, and 19 are presently amended.
Claims 8 and 18 are presently cancelled.
No Claims are presently added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Dec. 12, 2023, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant argues the claims are not a fundamental economic practice or method f organizing human activity because they are “directed to a specific, technological process implemented by computing devices and applications arranged in a specific manner to extend the functionality of conventional messaging applications.” Applicant’s Reply at 10.
Examiner respectfully disagrees. The claims steps, stripped of generic hardware, recite displaying and selecting gift options, transmitting a gift message, receiving a request to convert points to a monetary amount, authenticating the recipient, and crediting the monetary amount to the account (i.e., selecting, purchasing, gifting, and crediting). Applicant’s own specification teaches this is a “p2p transaction [person-to-person] to provide a gift card and/or rewards points from a sender to a recipient” and an “improve[ment] [to] the gift giving process,” (Spec. ¶¶ 13, 16) involving third party vendors and third-party vendor pricing (Spec. ¶ 23) and vendor reward conversion to cash rules (Spec. ¶¶ 27, 28), which confirms a fundamental economic practice long-prevalent in our system of commerce under MPEP § 2106.04(a)(2)(II)(A) and Intellectual Ventures I v. Symantec.
Applicant argues the amended claims integrate any alleged judicial exception into a practical application by improving the functioning of messaging applications. The provider institution client application is “invoked by and displayed within” the first messaging application “[a]s an overlay via an [API], which eliminates manual switching, reducing user interactions, processing power, and bandwidth. Applicant’s Reply at 10–12 (citing Spec. ¶¶ 16, 34, 43, 44).
Examiner respectfully disagrees. Under MPEP § 2106.05(a), the alleged improvement must (1) be described in the disclosure in sufficient detail so that a POSITA would recognize a technological improvement, and (2) be reflected in the claim itself as a particular way rather than a mere functional result. Although the specification describes embodiments that are encompassed by the BRI of “overlay” (e.g., Spec. 44, new message window popup”) and discloses that the provider institution client application “may include an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications” (Spec. ¶ 34), the specification does not describe the mechanism by which the recited API produces the overlay. The single API/SDK sentence in Spec. ¶ 34 is purely functional. Spec ¶ 44 describes the visual result only of “A new message window pops up” and Spec. ¶ 16 disclose of “may reduce processing power and increase bandwidth, which may in tum improve the functionality of the device on which the messaging application is executed (e.g., a user device)” is the kind of “bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art” that MPEP § 2106.05(a) instructs Examiners to disregard. The use of the permissive “may reduce” and “may improve” indicates the alleged benefit is a possibility rather than a demonstrated technological improvement. The claim element “displayed within the first messaging application as an overlay via an application programming interface (API) provided by the provider institution client application” recited by Independent Claims is the same level of generality (i.e., reciting the layered display outcome rather than how the outcome is achieved). Under MPEP 2106.05(a), an alleged improvement set forth in only functional terms rather than a particular way to achieve it cannot be an improvement in technology or the computer.
Applicant argues that unlike cxLoyalty, the amended claims do not automate a pre-existing human process. Rather, they solve a technical problem unique to computing (i.e., integrating two applications via an API-based overlay,” which has no pre-computer analog. Applicant’s Reply at 9.
Examiner respectfully disagrees. cxLoyalty involved a loyalty-points redemption system using a GUI and API, which is the same fact pattern here. The Federal Circuit there expressly rejected the same (“API/GUI” = technological improvement” argument Applicant now advances. See, cxLoyalty at 1377–78. The “no pre-computer analog” argument conflates the computing environment (apps, devices, messaging) with the alleged claimed advance. The claims steps, stripped of generic hardware, is plainly a human activity (gift giving) and performing it with generic computers and applications at this functional level of claiming (i.e., inside a messaging app overlay with an API) is merely a field-of-use under MPEP § 2106.05(h) and cannot be a practical application.
Applicant argues the “invoked by and displayed within … as an overlay via an [API]” claim language captures the technological improvement. Applicant’s Reply at 11–12.
Examiner respectfully disagrees. This is a functional-results limitation that states what is displayed, not how it is displayed. Thus, the “overlay via an API” reads on any conceivable technique for layering one application’s UI inside another. The specification’s own treatment is likewise generic. Spec. ¶ 43 (“The application 210 and the application 212 can be any type of application configured to provide information to the messaging application 116”); ¶ 44 (the display 202 changes (e.g., a new message window pops up”); ¶ 34 (“may include an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications with the provider institution client application 114”). Where, as here, the disclosure describes the alleged improvement is permissive language, e.g., “may,” “can”, the disclosure cannot satisfy the specificity required under MPEP § 2106.05(a).
Applicant argues the “provider institution client application invoked by and displayed within a first messaging application … as an overlay via an [API]” cannot be considered well-understood, routine, and conventional (“WRC”) and therefore supplies an inventive concept. Applicant’s Reply at 12.
Examiner respectfully disagrees. Berkheimer is met here by Applicant’s own disclosure describing every additional element in exemplary and generic terms (Spec. ¶¶ 17, 18, 19, 23, 24, 25, 33, 34, 39, 43, 90, 91, 92, 93, 94, 95, 96) and the cited NPL overlay prior art showing the overlay-via-API technique was conventional. Considered as an ordered combination, the additional elements (messaging application, provider client application, API, display overlay) are recited at a high level of generality and are invoked merely as tools to implement the abstract idea i.e., "mere instructions to apply" the exception on a generic computer (MPEP § 2106.05(f)) using well-understood, routine, conventional computer functions (MPEP § 2106.05(d)). Neither individually nor in combination do these elements amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–7, 9–17, 19, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–7, 9–17, 19, and 20 are directed to a statutory category. Claims 1–7, 9, and 10 recite a “system” and are therefore, directed to the statutory category of a “machine.” Claims 11–17 recite a “method” and are therefore, directed to the statutory category of a “process.” Claims 19 and 20 recite a “non-transitory computer-readable medium” and are therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination. Normal font is used for limitations that recite the judicial exception. Bold font is used to indicate additional elements evaluated under Step 2A, Prong Two (practical application) and Step 2B (significantly more). Italics font is used where necessary to identify intended use limitations1 and underline font is used, as needed, in further describing the judicial exception. Each limitation is identified by a letter designator for use as a shorthand notation when analyzing/referencing each limitation. Rep. Claim 1 recites:
[A] 1. A provider institution computing system associated with a provider institution, comprising: a network interface circuit; and at least one processing circuit coupled to the network interface circuit, the at least one processing circuit comprising at least one processor coupled to at least one non-transitory memory storing instructions that, when executed by the at least one processor, cause the at least one processing circuit to:
[B] receive, from a provider institution client application executing on a sender device of a sender, a request to send a gift to a recipient associated with a recipient device via a second messaging application of the recipient device, the provider institution client application invoked by and displayed within a first messaging application executing on the sender device;
[B1] wherein the provider institution client application is displayed within the first messaging application as an overlay via an application programming interface (API) provided by the provider institution client application;
[C] verify that a first account associated with the sender includes a first value of points;
[D] determine, based on the request, a first gift value having a first gift type and a second gift value having a second gift type;
[E] provide a first gift option to the sender device for display in a second user interface of the provider institution client application, the first gift option comprising a first gift with the first gift value and a second gift with the second gift value;
[F] receive a first gift selection from the first messaging application via the provider institution client application, the first gift selection comprising one of the first gift or the second gift;
[G] responsive to receiving the first gift selection, provide data to generate a gift message to the sender device, causing the provider institution client application to generate and transmit the gift message to the recipient via the second messaging application;
[H] based on an interaction with the gift message, receive a request for a monetary amount in lieu of the first gift selection; and
[I] authenticate the recipient device as being associated with the recipient to permit a conversion of the first value of points to the monetary amount.
[J] responsive to authenticating the recipient device as being associated with the recipient, determine the monetary amount based on the first value of points;
[K] credit the monetary amount to an account of the recipient maintained by the provider institution.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “receive … a request to send a gift to a recipient,” in in Limitation B, “verify that a first account associated with the sender includes a first value of points,” in Limitation C; “determine, based on the request, a first gift value having a first gift type and a second gift value having a second gift type,” in Limitation D; “provide a first gift option to the sender … the first gift option comprising a first gift with the first gift value and a second gift with the second gift value,” in Limitation E; “receive a first gift selection … the first gift selection comprising one of the first gift or the second gift,” in Limitation F; “responsive to receiving the first gift selection, provide data to generate a gift message to the sender … to generate and transmit the gift message to the recipient,” in Limitation G; “based on an interaction with the gift message, receive a request for a monetary amount in lieu of the first gift selection,” in Limitation H; and “permit a conversion of the first value of points to the monetary amount,” in Limitation I, “determine the monetary amount based on the first value of points” in Limitation J and “credit the monetary amount to an account of the recipient maintained by the provider institution” in Limitation K, which recites a fundamental economic practices under the organizing human activity exception because selecting, purchasing, giving a monetary gift to a recipient, and crediting the monetary amount to a recipient account is a longstanding commercial practice or fundamental economic practice long prevalent in our system of commerce. The gift giving process being old and well known “indicates that the practice is fundamental.” MPEP § 2106.04(a)(2)(II)(A) (citing Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1313, 120 USPQ2d 1353, 1356 (Fed. Cir. 2016) ("The category of abstract ideas embraces ‘fundamental economic practice[s] long prevalent in our system of commerce,’ … including ‘longstanding commercial practice[s]’").
Step 2A, Prong Two: The additional elements identified in Rep. Claim 1, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d).
The additional elements are limited to the computer components, generic software components, and message application environment indicated in bold, supra. The additional elements are: A provider institution computing system comprising: a network interface circuit; at least one processing circuit, at least one processor and at least one non-transitory memory storing instructions; a sender device executing a provider institution client application, a first messaging application, and a second user interface; a recipient device having a second messaging application; and the provider institution client application is displayed within the first messaging application as an overlay via an application programming interface (API) provided by the provider institution client application [Limitation B].
The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a).
A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the abstract idea exception of gift-giving with loyalty-point redemption was previously performed manually, as acknowledged by Applicant’s Specification in describing the pre-existing problem of recipients lacking accounts, not desiring the rewards, or not wishing to use a particular vendor’s e-gift card. Spec. ¶¶ 3, 12. Because the process can be performed manually, the computer is not being improved and is merely being used as a tool to perform the pre-existing manual process. Applying a pre-existing manual process using generic computer components, even via a GUI, is not an improvement to computer technology. cxLoyalty, Inc. v. Maritz Holdings Inc., 986 F.3d 1367, 1377–78 (Fed. Cir. 2021) (use of GUI and API to facilitate loyalty-points exchange does not improve computer technology).
The specification confirms this characterization by describing the alleged advantages of the claimed system in terms of business and user-experience (UX) outcomes (“improve the gift-giving process by 1) enabling a faster transaction by conducting the transaction through a messaging application … and 2) avoiding instances of unwanted e-gift cards or rewards points” (Spec. ¶ 16), “enable a sender to quickly send a gift (e.g., an e-gift card, rewards points, etc.) to a recipient via a messaging application” (Spec. ¶ 15); and “enable a recipient to quickly receive the gift and, if the gift is undesirable, select an alternative gift” (Spec. ¶ 16). These outcomes are described rather than in terms of any specific technical improvement to the computer, GUI, server, mobile device, or network infrastructure itself. Even where the specification might describe a technical benefit (e.g., “reduce processing power and increase bandwidth, which may in tum improve the functionality of the device on which the messaging application is executed (e.g., a user device) (Spec. ¶ 16)), the assertion is conclusory and described using permissive “may” language which indicates the alleged benefit is a possibility rather than a demonstrated technological improvement. Such bare assertions of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art are insufficient to integrate the abstract idea into a practical application. MPEP § 2106.05(a). The specification provide no engineering detail to substantiate the “may reduce processing power and increase bandwidth.”
The specification does not describe any specific technical improvement to APIs, message or app-extension frameworks, overlay rendering, encryption, authentication algorithms, network communication protocols, display technology, rendering algorithms, data structures or computer architecture. The single API/SDK disclosure in Spec. ¶ 34 (“may include an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications with the provider institution client application 114” is purely functional. Further, the specification describes the GUI elements (e.g., display 202, application selection portion 206, messaging input 208, selection box 302, pop up window) only at a high functional level without any unconventional technical mechanism. Spec. ¶¶ 42, 43, 44, 46, 47. Thus, these are generic GUI elements. Any improvements describe in the specification are business and UX outcomes, not technical improvements to the computers themselves.
The additional elements do not apply the abstract idea with a particular machine.
Although the claims recite specific hardware components (i.e., A provider institution computing system comprising: a network interface circuit; at least one processing circuit, at least one processor and at least one non-transitory memory storing instructions; a sender device executing a provider institution client application, a first messaging application, and a second user interface; a recipient device having a second messaging application), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. ¶¶ 17, 18, 19, 33, 34. A machine is “particular” only when it imposes a meaningful limit on the claims scope. MPEP § 2106.05(b). Here, any general-purpose computer, server, mobile device, and mobile application with messaging capability would satisfy the claim’ hardware requirements, which confirms that the hardware components are generic rather than “particular.” MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language without restricting the claimed hardware to any particular design, configuration, or architecture. Spec. ¶ 17, 33, 34, 91, 92, 93.
The additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f). (2) generally link the judicial exception to a particular technological environment; MPEP § 2106.05(h); and/or (3) are insignificant extra solution activity; MPEP § 2106.05(g).
Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language and instead describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. The specification failure to describe these components in any detail beyond exemplary language is itself an admission that the components are so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶ 93 (“Each processor may be implemented as one or more general-purpose processors”); ¶ 17 (“The network 180 may be any type of type of network. For example, the network 180 may be a wireless network interface (e.g., 802.11X, ZigBee, Bluetooth, Internet, etc.), a wired network interface (e.g., Ethernet), or any combination thereof. The network 180 is structured to permit the exchange of data, values, instructions, messages, and the like between and among the sender device 112, the recipient device 132 and the provider institution computing system 160.”); ¶ 23 (“any vendor from which a gift (e.g., an e-gift card, rewards points, etc.) may be provided”); ¶ 24 (“the mobile transaction circuit 170 receives information associated with the e-gift card. The information may include, for example, an e-gift card number, an authentication number, a code (e.g., a bar code, a quick response (QR) code, etc.) that can be scanned, and any other information that may identify the e-gift card and the value associated with the e-gift card for use with the designated vendor”); ¶ 25 (“The information may include, for example, an e-gift card number, an authentication number, a code ( e.g., a bar code, a quick response (QR) code, etc.) that can be scanned, and any other information that may identify the alternative e-gift card and the value associated with the alternative e-gift card for use with the designated vendor.”); ¶ 33 (“The sender device 112 and the recipient device 132 may be or include a mobile device (i.e., a device that is substantially portable or movable as opposed to a stationary or fixed device) and/or a wearable device … any type of device that the sender 110 or the recipient 130 wears … The sender device 112 and the recipient device 132 may also include any type of mobile device … The sender device 112 and the recipient device 132 may also include voice-activated digital assistance devices (e.g., a voice activated device structured to assist a user, smart speakers having chatbot capabilities, etc.), portable media devices, vehicle infotainment systems, etc. that may access one or more programs, servers, networks, central computers, etc. Accordingly, the sender device 112 and the recipient device 132 may include a display device (e.g., a screen) and one or more input/output devices”); ¶ 39 (“The verification information may include a personal identification number, a password, a biometric (e.g., a fingerprint, retina scan, etc.), a voice command, or any other type of information that may verify that the individual executing the transaction is the sender 110.”); ¶ 43 (“The application 210 and the application 212 can be any type of application configured to provide information to the messaging application 116.”); ¶ 90 (“However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.”); ¶ 92 (“a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOC) circuits), telecommunication circuits, hybrid circuits, and any other type of "circuit." In this regard, the "circuit" may include any type of component for accomplishing or facilitating achievement of the operations described herein.”); ¶ 94 (“"input devices," as described herein, may include any type of input device”); ¶ 94 (“"output device," as described herein, may include any type of output device”); ¶ 95 (“Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies).”); ¶ 96 (“The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments”); ¶ 96 (“software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.”); ¶ 17 (“provider institution computing system 160 is a backend computer system”); ¶ 18 (any known exemplary and generic “processing circuit 162,” “processor 164”, “memory device 166,” and “computer code”), ¶ 19 (any known generic and exemplary “network interface circuit 172”), ¶ 91 (any known generic and exemplary “circuit”).The generic processor, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. ¶¶ 93, 96. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea.
The “overlay via aa API” amendment (Limitation B1) likewise does not integrate the abstract idea into a practical application. The amended limitation recites a functional result (a layered display achieved through an API) without reciting how the API produces the overlay. The specification describes embodiments within the BRI of “overlay” (e.g., Spec. ¶ 44 “a new message window pops up”), but does not describe any mechanism, by which the recited API produces the overlay. The disclosure is silent as to the API call structure and other technical details necessary. Spec. ¶¶ 34, 44. Under MPEP § 2106.05(a), an alleged improvement set forth in functional terms alone rather than a particular way cannot be an improvement in technology or an improvement in the functioning of a computer. Further the alleged overlay/integration improvement is performed by the sender-device client application, which is a separate unclaimed element (not by the provider institution computing system). AN alleged improvement not performed by the claimed invention cannot integrate the abstract idea into a practical application.
Limitation E does not provide a practical application because it they merely describe the field of use and technical environment in which the abstract idea is implemented, without resulting in an improvement to the computer or GUI itself. MPEP 2106.05(h) (citing Electric Power Group). The specification confirms that the GUI elements are described only at a high, functional level without any specific technical improvement to the GUI or display technology. E.g., Spec. ¶¶ 42, 43, 44, 46, 47. Further, requiring the use of software to tailor information and provide it to the user on a generic computer also does not provide a practical application. MPEP § 2106.05(f) (citing Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)).
Limitations B–K describe the computer components performing the steps of the claimed invention, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively, the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Independent Claims 11 and 19 are not substantially different than Rep. Claim 1, recite the same abstract idea as Rep. Claim 1, and contain no additional elements not otherwise analyzed for Rep. Claim 1. Therefore, Independent Claims 11 and 19 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05. The additional elements (i.e., A provider institution computing system comprising: a network interface circuit; at least one processing circuit, at least one processor and at least one non-transitory memory storing instructions; a sender device executing a provider institution client application, a first messaging application, and a second user interface; a recipient device having a second messaging application; and Limitation B1), are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure2. Further, Applicant’s Specification discloses that these components operate in no particular order and are implemented using generic, off-the-shelf computing technology. Spec. ¶ 96 (steps/functions may be performed in any order or concurrently); ¶¶ 17, 18, 19, 33, 34, 91, 92, 93 (describing each component using exemplary language as generic or known computing equipment and networks).
(1) The provider institution computing system comprising: a network interface circuit; at least one processing circuit, at least one processor and at least one non-transitory memory storing instructions is WRC in the financial technology field. Spec. ¶¶ 17, 18, 19, 91, 92, 93.
(2) The sender device executing a provider institution client application and a first messaging application, and a second user interface are WRC. Spec. ¶¶ 33, 34, 36, 37.
(3) The recipient device and a second messaging application are WRC. Spec. ¶¶ 33, 36, 37.
(4) Limitation B1 - wherein the provider institution client application is displayed within the first messaging application as an overlay via an application programming interface (API) provided by the provider institution client application; is WRC. Spec. ¶ 34 (“may include an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications with the provider institution client application 114”); ¶ 44 (“the display 202 changes (e.g., a new message window pops up)”); see also cxLoyalty, Inc. v. Maritz Holdings Inc., 986 F.3d 1367, 1377–78 (Fed. Cir. 2021) (use of GUI and API to facilitate loyalty-points exchange is conventional). Additionally, previously cited prior art NPL Overlay (2015) established that the overlay via API technique was conventional as of the priority date.
The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and the steps may be performed in any order or concurrently. See, e.g., Spec. ¶¶ 17, 96.
The combination is also WRC at the high level of generality recited:
The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(2). Here, the combination performs each step in exactly the manner described as conventional throughout Applicant’s own Specification. There is no indication that the combination of these elements operates in an unconventional manner or produces a result that is other than what would be expected from the generic application of these individual components.
Unlike BASCOM, where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 1 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. At the high level of generality recited, the combination is WRC. Any BASCOM argument fails because nothing in Applicant’s Specification describes a non-conventional ordered arrangement of components that is then recited in the claims. Rep. Claim 1 recites only the abstract steps of receiving a request, verifying an account balance, determining gift values, providing gift options, receiving a gift selection, providing data to generate a gift message, receiving a request for monetary substitute, authenticating the recipient, determining monetary amount, and crediting an account without incorporating any specific technical details for how these elements are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, the claim cannot be an improvement to the computer or another technology. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d).
Accordingly, the additional elements of Rep. Claim 1 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Reevaluated under Step 2B, Limitations B, G, and H are found to be no more than well-understood, routine, and conventional post-solution activity in the field of electronic transaction processing and do not provide an inventive concept. As discussed above, Limitations B, G, and H, merely recite the processor receiving requests, generating data for an electronic gift message, and routing communications via generic messaging application (normal input/output operations of a generic computer). Applicant’s Specification describes these operations as occurring within a conventional messaging and transaction processing environment implemented using standard client devices, servers, messaging applications, and databases, and does not indicate that these functions are performed in an unconventional manner. Spec. ¶¶ 17, 18, 19, 33, 34, 36, 37. Moreover, neither the Specification nor the record identifies Limitations B, G, and H as providing any improvement to the functioning of the computer itself or to the underlying network or storage technology; nor has Applicant provided any evidence that such operations were not well-understood, routine, and conventional in the field at the time of the invention. Spec. ¶¶ 16, 34, 44. In view of this disclosure and the absence of contrary evidence, and consistent with MPEP § 2106.05(d) and USPTO guidance interpreting Berkheimer, these limitations are found to be well-understood, routine, and conventional pre- and post-solution activity in the field of electronic transaction processing and do not supply an inventive concept.
Independent Claim 19 is a computer-readable medium claim whose instructions cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 11 is a method claim reciting steps that perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claims 11 and 19 add no additional elements beyond those of Rep. Claim 1 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 11 and 19 also do not recite an inventive concept under Step 2B.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons:
Dependent Claims 2, 12, and 20 merely add additional steps of offering substitute commercial options and receiving a selection (i.e., further commercial-interaction steps that fall within the same abstract idea of gift-giving and loyalty-points redemption identified for Rep. Claim 1.) The specification describes the alternative-gift mechanism only at the same functional level as Rep. Claim 1. Spec. ¶¶ 12, 25, 27–30. No new technological mechanism or particular machine is introduced. Under Step 2B, the additional steps are themselves part of the abstract idea, and to the extent they constitute additional elements, they are recited at the same high level of generality and are well-understood, routine, and conventional ("WRC") for the same reasons as Rep. Claim 1. Spec. ¶¶ 27, 28, 29, 30. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 3 and 13 recite the abstract concept of selectively withholding information from a counterparty in a commercial transaction, which is a longstanding commercial practice (e.g., concealing gift details from the giver) and a method of organizing human activity (managing interpersonal interactions). MPEP § 2106.04(a)(2)(II)(A), (B). The specification describes the obscuring step only at a functional level with no disclosure of any particular masking algorithm or cryptographic technique. Spec. ¶¶ 16, 28, 29. The limitation therefore does not integrate the abstract idea into a practical application under Step 2A, Prong Two, and adds nothing beyond conventional message-content selection performed by a generic computing system under Step 2B. MPEP § 2106.05(a), (f).
Dependent Claims 4 and 14 merely narrows the data fields that are subject to the abstract obscuring step of Claims 3 and 13 (i.e., it identifies the content of the data being concealed (vendor identity, monetary value, rewards-point value), which is the type of commercial data inherent to the abstract idea itself. Identifying particular categories of commercial information does not transform an abstract idea into a patent-eligible practical application. Under Step 2B, the recited data categories are conventional fields long used in commercial transactions and add no inventive concept.
Dependent Claims 5 and 15 recite "receiv[ing] a code from the second messaging application, the code associated with the second gift selection." Receiving an identifying code in connection with a commercial transaction is itself part of the abstract idea of transaction processing (e.g., redemption code receipt) and, alternatively, is insignificant extra-solution activity and mere data gathering. MPEP § 2106.05(g). The specification describes code receipt only at the functional level with no particular machine, transmission protocol, or technical mechanism disclosed. Under Step 2B, data reception by a generic computing system using a generic messaging application is WRC. MPEP § 2106.05(d).
Dependent Claims 6 and 16 recite "provid[ing] a code to the second messaging application, the code associated with the second gift selection" and do not recite a practical application or inventive concept for the same reason as Claims 5 and 15 supra do not.
Dependent Claims 7 and 17 recite that the code "comprises one of a bar code, a QR code, or an authentication number." Bar codes, QR codes, and authentication numbers are well-known, conventional encoding formats. The specification describes them in fully exemplary, generic terms. Spec. ¶¶ 24, 25. This is a Berkheimer admission of conventionality. The recited code formats add no technological improvement under Step 2A, Prong Two, and are WRC under Step 2B. MPEP § 2106.05(d).
Dependent Claim 9 merely specify the commercial nature of the gift being transferred, which does not integrate the abstract idea into a practical application. It is a field-of-use limitation narrowing the abstract idea to the e-gift-card subset of the loyalty-points and gift-giving commercial practice. MPEP § 2106.05(h); cxLoyalty, Inc. v. Maritz Holdings, Inc., 986 F.3d 1367, 1377 (Fed. Cir. 2021). The specification describes e-gift cards and vendor association only at the functional level. Spec. ¶¶ 23, 26. Under Step 2B, e-gift cards and vendor-associated monetary values are conventional commercial instruments providing no inventive concept. MPEP § 2106.05(d).
Dependent Claim 10 recites a parallel narrowing limitation specifying that the gift takes the form of vendor-associated rewards points rather than an e-gift card. For the same reasons as in Claim 9, this limitation is a field-of-use restriction within the same loyalty-points-redemption abstract idea and is not a practical application. MPEP § 2106.05(h); cxLoyalty, 986 F.3d at 1377 (loyalty-points redemption is itself a fundamental economic practice). The specification describes vendor-associated rewards points only at the functional level. Spec. ¶¶ 23, 26, 27. Under Step 2B, vendor-tied rewards points are a conventional commercial construct and add no inventive concept. MPEP § 2106.05(d).
Combined Consideration. Considered in any combination, the dependent claims' additional limitations merely add further commercial-transaction sub-steps or narrow the type of commercial instrument involved. None of these limitations recites a particular machine, a non-conventional ordered arrangement of components in the sense of BASCOM, or any specific technical mechanism for performing the recited steps. Accordingly, none of Dependent Claims 2–7, 9, 10, 12–17, and 20 integrates the abstract idea into a practical application under Step 2A, Prong Two, and none amounts to significantly more than the abstract idea under Step 2B.
Conclusion
Claims 1–7, 9–17, 19, and 20 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
Examiner Statement of Prior Art—No Prior Art Rejections
Based on the prior art search results, the prior art of record fails to anticipate or render obvious the claimed subject matter of the instant application. While some individual features of Claims 1–20 may be shown in the prior art of record—no known reference, alone or in combination, would provide the invention of Claims 1–20.
The prior art most closely resembling the applicant’s claimed invention are:
Sirota (U.S. Pat. Pub. No. 2020/0294110) is pertinent because it discloses systems and methods for gift selection and distribution using messaging applications. The gifting system recommends a plurality of gift options and permits the recipient to exchange their gift to avoid unwanted gifts. Sirota, Abstract, ¶ 55.
FOR: (Int. Pat. Pub. No. WO 2019/142050 A1) is pertinent because it discloses systems and methods for gift selection and distribution using gift applications. One or more techniques authenticate the recipient user prior to processing the gift requests initiated by the sender user. Abstract.
NPL: SMS based Pooled or Collective Monetary Fund, IPCOM000227834D, May 21, 2023 is pertinent because it discloses pooled gifts to a recipient using SMS.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
2 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights