DETAILED ACTION
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 .
Status
This action is in response to applicant’s response filed on 3/19/2025. Claims 1-20 are pending. Claims 1-8 are withdrawn. Claims 9-20 are pending and examined. Claim 9 is amended. No claims have been added. No claims have been cancelled.
Election/Restrictions
Applicant’s election without traverse of claims 9-20 in the reply filed on 11/5/2024 is acknowledged.
Claims 1-8 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 11/5/2024.
Response to Arguments
Applicant's arguments filed 3/19/2025 have been fully considered but they are not persuasive. The applicant has argued “The claimed invention provides a technical solution to the technical problem of securely managing consumer receipt data while maintaining consumer control over that data. This is not a fundamental economic practice, commercial interaction, or mental process that can be performed in the human mind. The claimed method involves complex technological operations including blockchain-based verification, digital signature verification, and secure data transmission that cannot be practically performed in the human mind.” The examiner respectfully disagrees. The claimed invention registers a retailer, obtains a consent, provides a credential, facilities a payment, provides a receipt data, receives authorizations, facilitates delivery, and provides an audit trail. The abstract idea of commercial interactions (e.g., generating and managing receipt data) is not untethered from the language of the claims. The claims simply recite a method for gathering receipt data and providing the receipt data. Such a process clearly recites a commercial interaction between a customer and a transaction receipt management service. Although the claims recite detail regarding how the receipt data is retrieved, the claims do not recite any limitation which amounts to an improvement to any technology or technological field. Rather, the claims simply utilize generic computer-related devices to gather and output the receipt data. The specification discloses a blockchain-based data consent manager. The blockchain technology used in the invention is done so on a generic server and or terminal. The blockchain technology is used in its ordinary and customary manner to provide an audit trail. Providing an irrefutable audit trail is not an improvement to the technology nor is it something that can only be done by a blockchain process. Providing an irrefutable audit trail through uses of a distributed blockchain process is merely using a blockchain as a generic manager, it remains as a generic software entity that by its nature is used by the processor. The claim does not provide any technical implementation details that would indicate an improvement to a technical field. See Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016) (“[T]he essentially result-focused, functional character of claim language has been a frequent feature of claims held ineligible under § 101, especially in the area of using generic computer and network technology to carry out economic transactions.”). Rather than being a technical problem, the performance of a providing an irrefutable audit trail is a business problem and the claim merely requires providing data within a generic blockchain, i.e., the claim merely generally links the abstract idea to a technological environment.
The applicant has argued “Similar to the claims in Ancora Technologies v. HTC America, our claims are directed to an improvement in computer security technology, not an abstract idea. In Ancora, the Federal Circuit found claims eligible that addressed vulnerability in license authorization software by using a specific technique. Similarly, our claims address vulnerabilities in consumer data privacy by using specific blockchain and cryptographic techniques to create an irrefutable audit trail.” The examiner respectfully disagrees. In Ancora Technologies, the court determined that, by moving the software-verification structure, including the license record (i.e., the information used to indicate whether a specified program is licensed to run on the computer), to a BIOS location less susceptible to hacking, the verification structure was protected against alteration–– a circumstance that, in turn, yields a tangible technological benefit by making the computer itself less susceptible to hacking. Ancora, 908 F.3d at 1350. In other words, the court determined in Ancora that the claims are patent eligible because the claimed method provides advantages with respect to computer functionality, involving specific computer parts and programming which altered the normal functioning of the computer. The claims differ from those found patent eligible in Ancora, where the claims were “a concrete assignment of specified functions among a computer’s components to improve computer security.” A comparable situation is presented here. The claims are not directed to an improvement in the way computers operate, without any supporting evidence or technical reasoning, applicant’s invention merely uses the capabilities of a general purpose computer.
The applicant has argued “The amended claim also specifies that "the audit trail is reproduced to verify that delivery of the receipt data was made to the consumer and was signed by a retailer issuing authority, a proof request was sent to the consumer, and delivery of raw receipt data and the consent-to-access credential back to the retailer occurred." This provides a specific technological solution that improves the security and verifiability of digital receipt data management.” The examiner respectfully disagrees. The verifying of receipt data does not appear to be a technological improvement. The improvement at most would be directed to the abstract idea of verifying received data over a specified channel. This limitation is also claimed awkwardly in a wherein clause it is unclear which limitations are actually being claimed as the “is reproduced to verify” is merely intended use. The applicant does not claim that the “audit trail” is reproduced. Merely when it is reproduced it does so with the purpose of verifying… Everything claimed after that is not an active step in the claim.
The applicant has argued “Like the claims in Finjan v. Blue Coat Systems, our claims recite specific steps that accomplish a result, not merely the result itself. The Federal Circuit found in Finjan that claims directed to a non-abstract improvement in computer functionality were eligible. Similarly, our claims provide specific improvements to computer functionality in the realm of digital receipt management and data privacy.” The examiner respectfully disagrees. The claimed invention involves a method of virus scanning that scans an application program, generates a security profile identifying any potentially suspicious code in the program, and links the security profile to the application program. The claims were held patent eligible because the court concluded that the claimed method recites specific steps that accomplish a result that realizes an improvement in computer functionality. In particular, the method generates a security profile that identifies both hostile and potentially hostile operations, and can protect the user against both previously unknown viruses and "obfuscated code." This is an improvement over traditional virus scanning, which only recognized the presence of previously-identified viruses. The method also enables more flexible virus filtering and greater user customization. The invention in Finjan was found by the district court to be similar to the hypothetical claim published by the Office as Abstract Idea Example 1 (eligible). As the instant application’s claims are viewed as the merely the obtaining and providing data the claims in the instant application do not claim an improvement over traditional virus scanning in conventional industry practice therefore they are viewed as an abstract idea and therefore non-statutory.
The applicant has argued “The combination of elements in the claim, particularly the use of "distributed blockchain processes and public-private key digital signature verification" to create an "irrefutable audit trail" that can be reproduced to verify specific transaction events, amounts to significantly more than the abstract idea of "consumer consent processing." Similar to the claims in BASCOM Global Internet v. AT&TMobility, our claims recite a specific, discrete implementation of the abstract idea that contains an inventive concept. In BASCOM, the Federal Circuit found that an inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces. Similarly, our claims arrange known technological components (blockchain, digital signatures) in a non-conventional way to achieve the technological improvement of an irrefutable audit trail for digital receipt data.” The examiner respectfully disagrees. As claimed the use of the blockchain and public-private key digital signature verification are merely known steps being carried out by a generic tool. The irrefutable audit trail is awkwardly claimed in the last step. Specifically “wherein the audit trail is reproduced to verify.” The applicant has failed to claim the active step of reproducing the audit trail. Therefore, the arguments directed to the steps are moot. However, it is noted that the applicant has argued that both blockchains and digital signatures are “known technological components.” The use of both blockchain and a digital signature which are known technology to credit an audit trail is not non-conventional. Applicant’s arguments are not found persuasive. The previous 101 rejection is maintained and updated below.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, both prior art references Elliot and Veltman disclose user consent and secure and private interaction between users. Both references work to protect the identity of the users.
In response to applicant's argument that the prior art does not teach “wherein the audit trail is reproduced to verify that delivery of the receipt data was made to the consumer and was signed by a retailer issuing authority, a proof request was sent to the consumer, and delivery of raw receipt data and the consent-to-access credential back to the retailer occurred, thereby providing the consumer complete control over data of the consumer in a secure and verifiable manner and providing the retailer with evidence when consent was given” a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. The concept of “wherein the audit trail is reproduced to verify that delivery…” the applicant does not claim the step of reproducing an audit trail. Therefore, applicant does not appear to be claiming the audit train being reproduced, merely the intent of on the off chance that the audit trail is reproduced it is done so to verify the delivery. Applicant’s arguments are not found persuasive. An updated search and an updated prior art rejection is below.
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 9-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because the claim(s) as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. The claim(s) is/are directed to the abstract idea of consumer consent processing. The claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 9-20 are directed to a method. Therefore, claims 9-20 are directed to patent eligible categories of invention.
Step 2A Prong 1
The claim(s) recite(s) (mathematical relationships/formulas, mental process or certain methods of organizing human activity). Specifically the independent claims recite:
(a) mental process: as drafted, the claim recites the limitations of registering a retailer, obtaining and providing a consent-to-access credential, facilitating a payment, providing receipt data, receiving authorizations, and facilitating delivery of a receipt to a retailer which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “by the processor,” nothing in the claim precludes the determining step from practically being performed in the human mind. For example, but for the “by the processor” language, the claim encompasses a user manually determining consumer consent and facilitating delivery of receipt data. The mere nominal recitation of a generic processor does not take the claim limitation out of the mental processes grouping. This limitation is a mental process.
(c) certain methods of organizing human activity: The claim as a whole recites a method of organizing human activity. The claimed invention is a method that allows for users to access consumer-designated portions of a receipt which is “Commercial or Legal Interactions.” “Commercial interactions” or “legal interactions” include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Thus, the claim recites an abstract idea.
Dependent claims 15, 19, 20, further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration.
Dependent claims 10-14, 16-18, will be evaluated under Step 2A, Prong 2 below.
Step 2A Prong 2
Independent claim 9 does not integrate the judicial exception into a practical application. Claim 9 is a method comprising “a processor.” Claim 9 further recites the additional elements of “obtaining, by the processor, a consent-to-access credential”, “providing, by the processor, the consent-to-access credential”, “providing, by the processor, authenticated receipt data for the given transaction and a transaction credential for the given transaction to the consumer”, “receiving, by the processor, authorizations” , “facilitating, by the processor, delivery of the certain consumer-designated portions of the authenticated receipt data”, “providing, by the processor, an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, manipulate, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 15, 19, 20 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which does not integrate the judicial exception into a practical application.
Dependent claim 10 discloses the additional element of “a Decentralized Identity (DID) connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claim 11 discloses the additional element of “providing the payment information over the DID connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claim 12 discloses the additional element of “receiving a proof request from the retailer over the DID connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Dependent claims 13, 16, discloses the additional element of “the consumer device.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 14 discloses the additional element of “to the retailer over the DID connection.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 17 introduces the additional element of “a wallet application that processes on the consumer device.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 18 introduces the additional element of “an Application Programming Interface (API).” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not sufficient to prove integration into a practical application.
Thus the problem the claimed invention is directed to answering the question based on gathered and analyzed data about the consumer related to a consent data structure. This is not a technical or technological problem but is rather in the realm of business or transaction management and therefore an abstract idea.
Step 2B
Independent claim 9 does not comprise anything significantly more than the judicial exception. As can be seen above with respect to Step 2A, Prong 2, Claim 9 is a method comprising “a processor.” Claim 9 further recites the additional elements of “obtaining, by the processor, a consent-to-access credential”, “providing, by the processor, the consent-to-access credential”, “providing, by the processor, authenticated receipt data for the given transaction and a transaction credential for the given transaction to the consumer”, “receiving, by the processor, authorizations” , “facilitating, by the processor, delivery of the certain consumer-designated portions of the authenticated receipt data,” “providing, by the processor, an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f). The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed with respect to Step 2A Prong Two, the additional elements in the claims amounts to no more than mere instructions to apply the exception using a generic computer component.
The additional elements of the independent claims, when considered both individually and in combination, do not comprise anything significantly more than the judicial exception.
Dependent claims 15, 19, 20 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which is not anything significantly more than the judicial exception.
Dependent claim 10 discloses the additional element of “a Decentralized Identity (DID) connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Dependent claim 11 discloses the additional element of “providing the payment information over the DID connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) is not anything significantly more than the judicial exception. MPEP 2106.05(f).
Dependent claim 12 discloses the additional element of “receiving a proof request from the retailer over the DID connection.” Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea 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., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
Dependent claims 13, 16, discloses the additional element of “the consumer device.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 14 discloses the additional element of “to the retailer over the DID connection.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 17 introduces the additional element of “a wallet application that processes on the consumer device.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claim 18 introduces the additional element of “an Application Programming Interface (API).” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
The dependent claims recite elements that narrow the metes and bounds of the abstract idea. Specifically, the dependent claims do not remedy the deficiencies of the independent claims. The depending claims further narrow the abstract idea described above and do not introduce any additional elements. The dependent claims do not integrate the abstract idea into a practical application and do not provide significantly more.
The additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not anything significantly more than the judicial exception. Therefore based on the above analysis as conducted based on MPEP 2106 from the United States Patent and Trademark Office the claims are viewed as a court recognized abstract idea, are viewed as a judicial exception, does not integrate the claims into a practical application, does not provide significantly more, and does not provide an inventive concept, therefore the claims are ineligible.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 9, 15, 18-20, is/are rejected under 35 U.S.C. 103 as being unpatentable over Veltman et al. (US 20190370487 A1) in view of Elliot et al. (US 20180089660 A1) in view of Narayan et al. (US 20200273031 A1).
Regarding claim 9, Veltman teaches registering, by a processor, a retailer to receive consumer-designated portions of receipt data produced during transactions by a consumer with the retailer (¶ 15, The user is then asked to provide legal consent to disclosure of private/sensitive information and is presented with a list of selectable consents with scope, such as agree to allow the retailer to send emails to the user, allow the retailer to make phone calls to the user, allow the retailer to make text messages to the user, allow the retailer to send postage mail to the user, and the like. ¶ 16-18, In another case, the user directly utilizes the privacy app/interface 120 (can be a mobile app or a web-based browser interface) on the user-operated device 120 and access the user interface 112 for registering with the privacy server 110. Again, the user is presented with a registration page and consents for sharing specific private/sensitive information (which the user supplies for that which is being shared). The legal consents and the sharable private/sensitive information is stored in the privacy vault 111 and the user is returned a token that uniquely represents the user and is usable by the privacy server 110 to identify the user's private/sensitive information and corresponding consents. ¶ 37-43, At 220, the private/sensitive information controller provides the requesting service the portion of the info when the token identifies the registered user and a consent that indicates that the registered user has recorded the consent to allow the requesting service access to the portion of information.);
obtaining, by the processor, a consent-to-access credential from a first authority (¶ 16-20, The user interface 112 then obtains, from the user, the private/sensitive information that the user consented to (email, phone number, address, name, age, gender, etc.), stores the legal consent provided by the user, and records the user's private/sensitive information along with the consents in the privacy vault 111. A token is generated that uniquely represents the user and provided back to retailer server 130 through the privacy API 131. The retailer server 130 completes registration of the user and records the user privacy token with the user record. ¶ 22, Each retailer is provided a specific user token that is specific to the user and specific to the retailer (based on each retailer's roles). Each user token includes an indication as to the consents that have been recorded and stored by the user for that particular retailer. The consent may be viewed as the retailers' security roles for accessing the privacy vault 111 of a particular user and based on the user tokens possessed by the retailers with the roles mapping to the consents available for those retailers. A user may have different personas with each retailer that maps to a single specific identity for the user in the privacy vault 111. ¶ 37-41, 52-55, Fig. 2);
providing, by the processor, the consent-to-access credential to a consumer device operated by the consumer (¶ 15-17, In another case, the user directly utilizes the privacy app/interface 120 (can be a mobile app or a web-based browser interface) on the user-operated device 120 and access the user interface 112 for registering with the privacy server 110. Again, the user is presented with a registration page and consents for sharing specific private/sensitive information (which the user supplies for that which is being shared). The legal consents and the sharable private/sensitive information is stored in the privacy vault 111 and the user is returned a token that uniquely represents the user and is usable by the privacy server 110 to identify the user's private/sensitive information and corresponding consents. ¶ 44-46, FIG. 3 is a diagram of another method 300 for consent-driven privacy disclosure control processing, according to an example embodiment. The software module(s) that implements the method 300 is referred to as an “information consent gatekeeper.” The information consent gatekeeper is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device. The processors that execute the information consent gatekeeper are specifically configured and programmed to process the information consent gatekeeper. The information consent gatekeeper may or may not have access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless. ¶ 31, Fig. 2).
Veltman does not specifically teach an anonymous payment. However, Elliot teaches
facilitating, by the processor, an anonymous payment for a given transaction between the consumer and the retailer (¶ 4-5, The systems and methods disclosed herein provide features that allow a user (e.g., sender) to make anonymous direct person-to-person payments to a recipient (e.g., another user). In some cases, the recipient may be someone that the sender of the payment does not know. Thus, the sender and/or recipient of the payment may wish to obfuscate (e.g., hide, obscure, etc.) at least a portion of their respective identities. The sender and/or recipient can configure the system to provide a limited amount (e.g., some, or none) of personal information to the other party to the transaction. When the system processes the transaction, the configured amount of personal information can be shared with each party (e.g., sender, recipient) to the transaction so that each party can maintain a desired level of anonymity. ¶ 17-19, FIG. 1 is a block diagram of an example system for making anonymous payments. For example, system 100 can be configured to perform a person-to-person transaction between parties (e.g., a payment sender and a payment recipient) to the transaction while obfuscating at least a portion of the parties' personal information. For example, the personal information can include an image of the party, an identifier (e.g., name) of the party, contact information for the party, and/or other personal information, as may be described herein. ¶ 27, 31-32, 34, 40, 49, 51-55, 59);
providing, by the processor, authenticated receipt data for the given transaction and a transaction credential for the given transaction to the consumer (¶ 49-50, FIG. 6 illustrates an example graphical user interface 600 for displaying payment confirmation notification 602. For example, sender device 102 may receive payment confirmation notification 602 indicating that payment was processed. In some implementations, payment confirmation notification 602 may include a brief description for the payment transaction. For example, the brief description may include the recipient and the payment amount. In some implementations, user may select “learn more” item 604 within payment confirmation notification 602 to view the receipt of the payment transaction which includes more detail about the transaction. For example, the receipt may provide the final payment amount, the anonymous information of the recipient, the transaction date etc. In some implementations, the sender can select “OK” item 606 to dismiss the payment confirmation notification 602. ¶ 59, At step 712, payment processing server 112 can transfer the payment amount from the sender to the recipient. As described above, in some implementations, payment processing server 112 can determine whether the payment should be transferred from sender's account to recipient's account based on sender authentication credentials provided by sender device 102. For example, once the sender authentication credentials are validated, payment processing server 112 can send a payment confirmation notification to sender device 102 indicating that payment was processed. In some implementations, once the payment transaction is complete, payment processing server 112 can send a payment completed notification (e.g., recipient's receipt) to the recipient's device (e.g., recipient mobile device). In some implementations, the payment completed notification may include a brief description for the payment transaction. For example, the brief description may include the sender and the payment amount. In some implementations, user may select the payment completed notification to view more detail about the transaction. For example, the receipt may provide the final payment amount, the anonymous information of the sender, the transaction date etc.);
receiving, by the processor, authorizations for certain consumer-designated portions of the authenticated receipt data for delivery to the retailer (¶ 46-47, For example, from payment options screen 400, the user may authorize payment using a default or selected payment option (e.g., default credit card 404) by providing biometric input 412. For example, biometric input 412 can be a scan of a fingerprint, an image of the user's face, a retinal scan, or other type of biometric input. Sender device 102 can authenticate the user based on biometric input 412 and initiate payment of the final payment amount when the sender has been authenticated. For example, sender device 102 can then send the sender authentication credentials including the above sender's selection (e.g., card 406, contact 408, options 410, etc.) to payment processing server 112 over network 108. ¶ 32, In some implementations, sender device 102 may receive multiple candidate recipient notifications associated with anonymous information from more than one recipient. In some implementations, the candidate recipient notification can include the information about the potential recipient. For example, upon receiving multiple candidate recipient notifications, sender device 102 can present those candidate recipient notifications including their additional recipient's anonymous information to the user. In some implementations, sender device 102 may receive and present multiple candidate recipient notifications at same time. Thus, the sender may process the payment to the particular recipient by selecting (e.g., slide to view, click the notification etc.) the corresponding candidate recipient notification. In some implementations, the graphical user interface of sender device 102 can display the graphical candidate recipient notification 210 on the sender device 102 display screen. For example, the graphical user interface can be a home screen, navigational menu, or application selection user interface. For example, graphical element 208 can be an image, icon, or other graphical objects for a user to select to initiate the anonymous payment. ¶ 44, In some implementations, graphical user interface 400 can include limited sender's personal information 408 about the sender. For example, as shown in FIG. 4, the limited sender's personal information 408 about the sender includes sender's email address and sender phone number. In some implementations, the sender can change the limited sender's personal information 408 regarding the sender by selecting or clicking graphical element 408. For example, if sender does not want the recipient to know who sent the money to the recipient, sender may do so by selecting graphical element 408 and change the limited sender's personal information. ¶ 40, 45-46, 58-59, 64);
facilitating, by the processor, delivery of the certain consumer-designated portions of the authenticated receipt data to the retailer based on the authorizations (¶ 46-47, For example, from payment options screen 400, the user may authorize payment using a default or selected payment option (e.g., default credit card 404) by providing biometric input 412. For example, biometric input 412 can be a scan of a fingerprint, an image of the user's face, a retinal scan, or other type of biometric input. Sender device 102 can authenticate the user based on biometric input 412 and initiate payment of the final payment amount when the sender has been authenticated. For example, sender device 102 can then send the sender authentication credentials including the above sender's selection (e.g., card 406, contact 408, options 410, etc.) to payment processing server 112 over network 108. ¶ 32, In some implementations, sender device 102 may receive multiple candidate recipient notifications associated with anonymous information from more than one recipient. In some implementations, the candidate recipient notification can include the information about the potential recipient. For example, upon receiving multiple candidate recipient notifications, sender device 102 can present those candidate recipient notifications including their additional recipient's anonymous information to the user. In some implementations, sender device 102 may receive and present multiple candidate recipient notifications at same time. Thus, the sender may process the payment to the particular recipient by selecting (e.g., slide to view, click the notification etc.) the corresponding candidate recipient notification. In some implementations, the graphical user interface of sender device 102 can display the graphical candidate recipient notification 210 on the sender device 102 display screen. For example, the graphical user interface can be a home screen, navigational menu, or application selection user interface. For example, graphical element 208 can be an image, icon, or other graphical objects for a user to select to initiate the anonymous payment. ¶ 44, In some implementations, graphical user interface 400 can include limited sender's personal information 408 about the sender. For example, as shown in FIG. 4, the limited sender's personal information 408 about the sender includes sender's email address and sender phone number. In some implementations, the sender can change the limited sender's personal information 408 regarding the sender by selecting or clicking graphical element 408. For example, if sender does not want the recipient to know who sent the money to the recipient, sender may do so by selecting graphical element 408 and change the limited sender's personal information. ¶ 40, 45-46, 58-59, 64).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Veltman to include/perform an anonymous payment, as taught/suggested by Elliot. This known technique is applicable to the system of Veltman as they both share characteristics and capabilities, namely, they are directed to protecting the identity of users. One of ordinary skill in the art would have recognized that applying the known technique of Elliot would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Elliot to the teachings of Veltman would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such anonymous payment features into similar systems. Further, applying an anonymous payment would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the user extra security and the ability to protect their identity.
Veltman does not specifically teach providing, by the processor, an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification.
However, Narayan teaches providing, by the processor, an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification (abstract, discloses secure end-to-end transactions, ¶ 106-112, disclose the use of a blockchain, ¶ 118-121, disclose public-private key pairs, ¶ 107, 110, disclose how a digital signature becomes an irrefutable record. ¶ 110, discloses receipt or transmission of communications).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Veltman to include/perform providing an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification, as taught/suggested by Elliot. This known technique is applicable to the system of Veltman as they both share characteristics and capabilities, namely, they are directed to providing secure systems. One of ordinary skill in the art would have recognized that applying the known technique of Elliot would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Elliot to the teachings of Veltman would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such audit trail features into similar systems. Further, applying providing, by the processor, an irrefutable audit trail evidencing authorized access to the receipt data through uses of distributed blockchain processes and public-private key digital signature verification would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow the user extra security.
Regarding claim 15, Veltman teaches modifying the consumer- designated portions based on a revised consent-to-access credential defined by the consumer for the retailer (¶ 17-19, If the user initially provided consents through a specific user service 132 of a specific retailer, then when the user initially registers with that service 132, the registration page may identify the privacy server 110 and ask if the user has a current registration and wants to sign in through the SSO 114. In this embodiment, if the user successfully logs on, the user may be presented with the previous consents and asked if the user wants any further changes to the current registered consents for this particular retailer. The user may also be able to bypass providing basic information to the retailer, such as address, phone number, etc., since the retailer API 113 can provide this directly to the appropriate retailer through the privacy server API 131 based on this being provided by the user during the previous registration with the privacy server 110. If the user changes consents for this particular retailer, then the privacy server 110 provides that retailer a modified user token representing that retailer's specific agreed to consents provided by the user to the user's private/sensitive information. So, the user is in control and can custom provided different levels of consent based on the specific user services 132., ¶ 44).
Regarding claim 18, Veltman teaches interacting with a retailer system of the retailer through an Application Programming Interface (API) (¶ 15-20, When a user registers for a user service 132 of a retailer, the user service 132 presents a registration interface within the retailer app 123 on the user-operated device 120 (note that this can also be web-based such that the registration interface is accessible through a browser so no specific retailer app 123 may be necessary). The user provides required information, such as name, address, email, and password. The privacy server API 131 utilizing the retailer API 113 redirects the registration interface to the user interface 112 of the privacy server 110. The user is then asked to provide legal consent to disclosure of private/sensitive information and is presented with a list of selectable consents with scope, such as agree to allow the retailer to send emails to the user, allow the retailer to make phone calls to the user, allow the retailer to make text messages to the user, allow the retailer to send postage mail to the user, and the like. ¶ 21, When a retailer requests private/sensitive information for which the presented user token does not authorize, no information is returned and a message of “unauthorized is sent from the retailer API 113 to the corresponding privacy server API 131. ¶ 58, 62, 70).
Regarding claim 19, Veltman teaches verifying a digital signature (¶ 24, 60) but does not specifically teach a receipt.
However, the combination of Veltman and Elliot teaches wherein providing the authenticated receipt further includes verifying a retailer digital signature on certain receipt data for the given transaction and providing the certain receipt data with the retailer digital signature as the authenticated receipt (Elliot, ¶ 46-47, For example, from payment options screen 400, the user may authorize payment using a default or selected payment option (e.g., default credit card 404) by providing biometric input 412. For example, biometric input 412 can be a scan of a fingerprint, an image of the user's face, a retinal scan, or other type of biometric input. Sender device 102 can authenticate the user based on biometric input 412 and initiate payment of the final payment amount when the sender has been authenticated. For example, sender device 102 can then send the sender authentication credentials including the above sender's selection (e.g., card 406, contact 408, options 410, etc.) to payment processing server 112 over network 108. ¶ 32, In some implementations, sender device 102 may receive multiple candidate recipient notifications associated with anonymous information from more than one recipient. In some implementations, the candidate recipient notification can include the information about the potential recipient. For example, upon receiving multiple candidate recipient notifications, sender device 102 can present those candidate recipient notifications including their additional recipient's anonymous information to the user. In some implementations, sender device 102 may receive and present multiple candidate recipient notifications at same time. Thus, the sender may process the payment to the particular recipient by selecting (e.g., slide to view, click the notif