DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
2. Claim 5 is objected to because of the following informalities:
Claim recites “providing … redeemable contact…” wherein underlined word “contact” should be corrected into “content”.
Appropriate correction is required.
Claim Interpretation
Contingent Limitations
3. Contingent limitations are generally not given patentable weight. For example, if a claim states that a step occurs if a condition is met, the broadest reasonable interpretation of the claim does not require that the contingent step occurs because the condition may not be satisfied. System claims differ in that even if a condition that is required to perform a function is not met, the structure for performing the contingent limitation is given patentable weight. See MPEP 2111.04(II); see also Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016).
4. Claim 5 recites “permitting redemption if gift code is active as indicated in public smart contract; updating public and private smart contracts with redemption status if gift code is active; and providing access to redeemable contact if gift code is active”. There are no positively recited limitations that permitting redemption, updating public and private smart contracts, and providing access to redeemable contact “if” gift code is active. For example, in order that the underlined limitations to be performed the gift code should be active which might not happen.
Claim Rejections - 35 USC §101
5. 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.
6. Claims 1-5 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
7. In the instant case, claim 1 is directed to a “method for managing gift card codes”.
8. Claim 1 recites “generating a gift code; generating a unique identification code to be associated with …; associating the gift code with a storage index and the unique identification code …; applying gift code to a gift card; distributing … code to a recipient; entering gift code …; and accepting gift code … and checking validity …”. Subject matter grouped under “Certain methods of organizing human activity (e.g., fundamental economic principles and practices) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
9. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a smart public contract”, “a blockchain”, “a smart private contract”, “digital code”, and “a redemption interface” do no more than represent the use of a computer as a tool to perform an abstract idea in a particular technological environment or field of use, and therefore, neither improve computer functionality nor improve another technology or technical field. With respect to “distributing digital code to a recipient” and “entering gift code into a redemption interface” is simply transmitting data, “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more. (MPEP2106.05(f)(2)).
10. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of managing gift card codes using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
11. Hence, claim 1 is not patent eligible.
12. Dependent claim 2 further describes the abstract idea of managing gift card codes as recites wherein the gift card is a physical card”.
Dependent claim 3 further describes the abstract idea of managing gift card codes as recites “wherein the gift card is a … card”. The additional element such as “a digital card” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 4 further describes the abstract idea of managing gift card codes as recites “further comprising the step of: checking if gift code is active if gift code is valid”.
Dependent claim 5 further describes the abstract idea of managing gift card codes as recites “further comprising the step of: permitting redemption if gift code is active as indicated …; updating … with redemption status if gift code is active; and providing access to redeemable [content] contact if gift code is active”. The additional elements such as “public smart contract”, and “public and private smart contracts” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
13. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
14. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
15. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
16. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
17. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
18. Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over US20220383317A1 to Tu in view of US20240420123A1 to Gupta et al.
19. As per claim 1:
Tu discloses the following limitations:
generating a gift code (Fig.2, items 205, 215, 228; [0055] “…the cloud service 215 can generate a notification message to the buyer 205 at 228, which can indicate the issuance of the gift card and association with the buyer's account…”)
generating a unique identification code to be associated … (Fig.2, items 205, 210, 222; [0054] “…At 222, the seller 210 can complete the transaction, and can prompt the buyer 205 for a unique SMS (or other) identifier to be associated, or already associated with, the buyer's account…”)
associating the gift code with a storage index and the unique identification code … (Fig.1, items 130, 133, 134, 135; [0050] “…the cloud service 130 can allow for secure and simple registration of gift cards to specific SMS (or other) numbers associated with consumers… As shown, a database or other storage mechanism can store a plurality of consumer accounts 133 for multiple consumers. Each consumer may be associated with one SMS number 134 (or other suitable identifier), which acts as a unified account identifier. That SMS number 134 can then be associated with one or more registered gift cards 135…”)
applying gift code to a gift card (Fig.2, items 205, 230; [0055] “…At 230, the buyer 205 can receive the issuance notification and can present it via a GUI of a mobile device of the buyer 205. The presentation can provide the link to the buyer-specific card wallet and its availability. In some instances, that wallet may include information about multiple stored cards, such as where other gift cards have already been associated with the SMS account.”)
distributing digital code to a recipient (Fig.2, items 205, 230; [0055] “…At 230, the buyer 205 can receive the issuance notification and can present it via a GUI of a mobile device of the buyer 205…”)
entering gift code into a redemption interface (Fig.4, items 205, 210, 404; [0056] “… This flow describes the ability of a buyer 205 to review the newly created gift card and any additional cards associated with his SMS or other identifier. In some instances, the flow 240 may be performed directly after receiving the notification at 230…”, [0057] “At 250, the buyer 205 can request to access his or her card wallet, such as by activating the link in the notification, or by otherwise typing in the URL to another browser or application…”)
accepting gift code from the redemption interface and checking validity … (Fig.2, items 205, 215, 252, 254, 256; [0057] “…The request is sent to the cloud service 215, which receives and confirms the account information associated with the URL or instructions included in the link 252. The cloud service 215 can perform account verification and validation with the buyer 205 at 254…”, [0058] “At 256, the buyer 205 can provide the information requested or required. Upon verification, the buyer 205 associated with the link can be authenticated, as well as the device, and access to the cloud service 215 and the consumer's related account can be provided…” [Under broadest reasonable interpretation “checking validity” interpreted as “performing validation” because claim does not specifically require it to be the “gift code”])
Tu does not disclose, however, Gupta et al., as shown, teaches the following limitations:
[generating] … to be associated with a smart public contract in a blockchain (Fig.1, items 102, 106, 110, 128; [0052] “…The smart contract 110 is part of a blockchain 128 of the decentralized blockchain platform 106, which governs how the credits are monetized across different enterprises 102.”, [0053] “… The issuing enterprise 102 a transfers the associated credit tokens 112 to a blockchain account that is generated for the consumer, wherein the credit tokens 112 are redeemable at a redeeming enterprise 102 b …”)
[associating] … from smart public contract within a smart private contract of a blockchain ([0069] “…the decentralized blockchain platform 106 maintains mapping of a consumer ID that is associated with the blockchain account, with the public key generated based on the consumer account in the blockchain.”, [0070] “… the customer account is created in the baseline blockchain credit platform, and its public and private keys are shared with the customer. This credit platform also maintains the mapping of customer ID with the blockchain account public key…”
[accepting] … within the smart private contract (Fig.5, items 502, 504, 506, 508; [0080] “FIGS. 5A and 5B exemplarily illustrate the redeeming of the CDV tokens 112 associated with the decentralized system for crediting and redemption of credit points using scannable code, as an embodiment of the present disclosure. At 502, the customer instructs enterprise 102 for a transaction using earned CDV tokens 112. At 504, the enterprise kiosk 114 generates a dynamic QR Code 124 with transaction details embedded in it. At 506, the customer scans the QR Code 124 using mobile application 120. At 508, the mobile application 120 interfaces with CDV computation smart contract 110 and computes differentiated value of each customer CDV tokens 112 for the redemption destination…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a decentralized system for crediting and redemption of credit points using scannable codes that operates and controls multiple enterprises, a blockchain platform, smart contracts, and a mobile device of Gupta et al. (‘123, [0025]) with teaching of Tu for providing payment card management with a unique messaging identifier corresponding to a consumer account associated with the new payment card and a value of the new payment card (‘317, [0006]) for associating a generated consumer’s blockchain account with credit tokens represented by smart contracts and accepting the generated code represented by the smart contract for redemption (‘123, [0052]-[0053], [0069], [0080]).
20. As per claim 2:
Tu discloses the following limitations:
wherein the gift card is a physical card ([0081] “Since this solution is layered on top of existing gift card delivery systems, if the buyer still wishes to use the traditional physical or electronic gift card medium, he still can… Further, funds can be reloaded and redeemed for a physical, electronic gift card without exposing the gift card number to the public by using the mobile number as a unique account identifier, and using a dynamic redemption code generated by the cardholder for a single-use and time-limited solution to control fraud and fight theft…”)
21. As per claim 3:
Tu discloses the following limitations:
wherein the gift card is a digital card ([0081] “Since this solution is layered on top of existing gift card delivery systems, if the buyer still wishes to use the traditional physical or electronic gift card medium, he still can… Further, funds can be reloaded and redeemed for a physical, electronic gift card without exposing the gift card number to the public by using the mobile number as a unique account identifier, and using a dynamic redemption code generated by the cardholder for a single-use and time-limited solution to control fraud and fight theft…”)
22. As per claim 4:
Tu discloses the following limitations:
checking if gift code is active if gift code is valid ([0047] “…Importantly, messages related to the present solution can be received and interacted with, such as by activating links associated with a cloud-based gift card service, or reviewing or presenting unique values, strings, bar codes, or other values, images, or other identifiers to merchants or sellers for verification of the consumer's active gift card account…”, [0051] “…The consumer can show or provide that second identifier to the merchant, who can type in, capture, scan, or otherwise enter the value in the POS application 121 and its gift card module 122. The information can be sent to the cloud service 130 and validated…”)
23. As per claim 5:
Tu discloses the following limitations:
permitting redemption if gift code is active … (Fig.4, items 205, 418, 420; [0068] “…The buyer 205 can then determine whether the redemption is allowed, and can approve the request to generate the code in any suitable manner through interactions with his or her mobile device. In such instances, operation 418 can be used to trigger the unique code or identifier generation, which then is received at the buyer at 420…”
[updating] … with redemption status if gift code is active (Fig.1, items 103, 130; [0047] “…In some instances, such as where gift card redemption is attempted, the browser or dedicated application 103 can be used to view a unique code generated by the cloud service 130, and can be presented to a merchant to verify the consumer's identity…”)
providing access to redeemable [content] contact if gift code is active (Fig.4, items 205, 210, 400, 402; [0063] “FIG. 4 illustrates an example process 400 for redeeming values of a particular gift card via a merchant. Again, interactions are described between buyer 205, seller 210, and cloud service 215. At 402, the buyer 205 can elect to redeem a gift card via a seller 210…”)
Tu does not disclose, however, Gupta et al., as shown, teaches the following limitations:
[permitting] … as indicated in public smart contract ([0065] “… the smart contract 110 is responsible for these rewards earning and redemption seamlessly enables the rewards consumption across different enterprises 102, without any explicit reward points exchange.”)
updating public and private smart contracts… ([0064] “5. In an embodiment, the smart contract 110 facilitates earning and redeeming of the credit points, and enables the credits consumption across different enterprises 102, without any explicit credit points exchange. The smart contract 110 is a combination of instructions and rules defining credit points conversion, where each onboarded enterprise 102 defines and changes their conversion rules respectively…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a decentralized system for crediting and redemption of credit points using scannable codes that operates and controls multiple enterprises, a blockchain platform, smart contracts, and a mobile device of Gupta et al. (‘123, [0025]) with teaching of Tu for providing payment card management with a unique messaging identifier corresponding to a consumer account associated with the new payment card and a value of the new payment card (‘317, [0006]) permitting the smart contract is being responsible for redemption appropriate value seamlessly and changing the rules defining conversion of redeemable content (‘123, [0064]-[0065]).
Conclusion
24. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20170193473A1 – Arora – Discloses methods and servers for processing payment using a generic gift card wherein the generic gift card is usable for payment across one or more participating merchants. One of the methods is performed at a server that administers usage of the generic gift card, the method comprises generating a unique code for identifying the generic gift card against which payment will be deducted for purchases made at a selected participating merchant
US20170161781A1 – Parekh – Discloses a method of providing a digital gift card to a beneficiary, the method including, in one or more electronic processing devices: receiving, from a digital wallet of an individual, a request to create a digital gift card including information indicative of at least one of: an occasion associated with the digital gift card and beneficiary information associated with the beneficiary.
US20100200655A1 – Wolfe et al. – Discloses systems, methods, and computer-readable storage media for generating a gift code wherein the system receives an indication from a first user identifying a closed loop card, receives a confirmation of an amount of money in an account associated with the closed loop card, offers to purchase the closed loop card at an amount less than the amount of money in the account associated with the closed loop card, and upon acceptance of the offer, deactivates the closed loop card.
25. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692