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 .
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 September 3, 2025 has been entered.
Status of Claims
• This action is in reply to the RCE filed on September 3, 2025.
• Claims 1 and 16-17 have been amended and are hereby entered.
• Claims 1-18 are currently pending and have been examined.
• This action is made Non-FINAL.
Response to Arguments
Applicant’s arguments filed September 3, 2025 have been fully considered but they are not persuasive.
New 35 USC § 112 rejections have been entered.
Applicant’s arguments with respect to 35 USC § 112 have been fully considered and are not persuasive.
Regarding Applicant’s argument on page 8, that “sufficient” as claimed in not definite, the Examiner respectfully disagrees. Applicant further relies upon the dictionary definition of “sufficient” to show that a person having ordinary skill in the art would have a standard of sufficient information based on the service provider processing system. The argument is not persuasive. Although Applicant argues a person having ordinary skill in the art would have a “standard of sufficient information,” the Applicant does not demonstrate where in the Specification there is support for what is “sufficient information.” Not does the Specification give any example as to what is “sufficient” information to complete a transaction. Rather, Applicant points to the Specification at [0013] which states “the remote transaction processing system can redact the original information and show the least amount of information necessary for the business teller to conduct commercial activities.” Again, there is no description as to what information is sufficient to process a transaction. Furthermore, in view of the Specification, a person having ordinary skill in the art would not know how much information to redact until left with the sufficient information to complete the transaction. Therefore the limitation is indefinite.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on page 13, that the Office ignores the detailed limitations presented in the claims and the specific order which the limitations are recited, the Examiner respectfully disagrees. The Examiner notes that each claim was given the full and proper analysis under the test set forth by the Supreme Court and the Patent Subject Matter Eligibility analysis (see MPEP 2106). Furthermore, under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the claims recite a server; a service provider processing system; a user system; data acquisition instructions to activate software in the user system; communication via a first communication network; and a second communication network such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic service provider system in communication with a user system and a first and second communication network. The system and network are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at [0002]-[0007], describing a problem with industry standards of processing payment with credit cards and improvement to ease of transacting by enabling contactless payment.
Applicant further argues on pages 13-14 that the claims are not directed to an abstract idea. The Examiner respectfully disagrees. Applicant further argues, on page 14 that the claims are tailored to a specific technological advancement. The argument is not persuasive. As indicated in the 35 USC § 101 rejection below, the claimed inventions allows for receiving a transaction request, redacting data from the transaction request, verifying user information related to the transaction, and processing and confirming the transaction. The Specification describes a problem and improvement to a business or commercial process at least at [0002]-[0007], describing a problem with industry standards of processing payment with credit cards and improvement to ease of transacting by enabling contactless payment. The Specification and claims focus on an improvement to the ease and convenience of users transacting with merchants, which is a fundamental economic practice which falls within the category of Certain Methods of Organizing Human Activity and therefore is an abstract idea.
Regarding Applicant’s arguments on page 14, that the claims are directed to a new, specific, concrete way of achieving a result and that the claims are novel, the arguments have been considered and are not persuasive. As an initial matter, regarding the argument regarding novelty, the Examiner respectfully points out that the claims have been rejected under 35 USC § 103 for being unpatentable over the cited prior art, as discussed in detail below. Furthermore, it is noted that the inventiveness inquiry of § 101 should not be confused with the separate novelty inquiry of § 102 or obviousness inquiry of § 103. A novel and non-obvious claim directed to a purely abstract idea is, nonetheless, patent ineligible. See Mayo, 566 U.S. at 79. “Even assuming that is true, it does not avoid the problem of abstractness.” Affinity Labs, 838 F.3d at 1263; Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 (Fed. Cir. 2014) (“That some of [these] steps were not previously employed in this art is not enough—standing alone—to confer patent eligibility upon the claims ”). Indeed, “a claim for a new abstract idea is still an abstract idea.” Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151 (Fed. Cir. 2016) (explaining that the search for an inventive concept under § 101 is distinct from demonstrating novelty under § 102).
Regarding Applicant’s arguments on pages 14-15, that the claims are directed to significantly more than the abstract idea, the Examiner respectfully disagrees. Applicant further argues on pages 14-15 that the claims are not well understood, routine, or conventional. The arguments have been considered and are not persuasive. The Specification recites the following concerning the apparatus for performing the claimed operations: “it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer.” See Specification at [0059]. Furthermore, the Specification at [0060] states: “Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps.” In the claims of the instant application, the additional elements of the claim include a server; a service provider processing system; a user system; communication via a first communication network; and a second communication network. These are merely generic computer components performing customary and generic steps. Therefore, the claims merely amount to the application or instructions to apply the abstract idea (i.e., a user conducting a transaction with a merchant) using generic computing components, and is considered to amount to nothing more than requiring a generic computer network merely to carry out the abstract idea itself. The specifics about the abstract idea do not overcome the rejection.
Regarding Applicant’s arguments on page 15 regarding pre-emption, the arguments have been considered and are not persuasive. In response to this argument, it is noted, “While preemption may signal patent ineligible subject matter, the absence of complete preemption does not demonstrate patent eligibility.” Ariosa Diagnostics, Inc. v. Sequenom, Inc., 788 F.3d 1371, 1379 (Fed. Cir. 2015). The instant application is reviewed within the framework of the Revised Guidance which specifies and particularizes the Mayo/Alice framework.
Regarding Applicant’s arguments on pages 15, that the claims recite features that are unconventional, the Examiner respectfully disagrees. Applicant further argues on page 16 that claims do not merely collect information via the internet, and therefore pass Prong Two. The argument is not persuasive. The limitations are directed to an abstract idea and when determining if the claims are directed to significantly more, the additional limitations of the claims in addition to the abstract idea are analyzed. For example, in the claims of the instant application, the claims recite a generic computer network consisting of a server; a service provider processing system; a user system; communication via a first communication network; and a second communication network is recited as performing steps to process a transaction between a user and a merchant, the steps including receiving a transaction request, providing instructions related to the request, receiving and verifying user information, redacting providing information, and providing a confirmation of the transaction. The computer components of the computer network are merely generic computer components performing customary and generic steps to carry out the abstract idea. The Examiner fails to see, and the Applicant fails to point out, how the steps are unconventional steps that confine the claims to a particular useful application.
Applicant’s reliance upon Weisner, on page 15, is misplaced. The claims here are not like those the Court found patent eligible in Weisner, in which the court found that the claims were directed to the solution particular to search queries targeting a geographic area. The court found that the inventive concept of the claims “improves computerized search results by taking into account the ‘past visit of such user.’” Weisner at 24. In contrast, the claims of the instant application do not effect improvement in the technical field of computers by improving computerized searches. Rather, the claims and Specification focus on solving a problem with industry standards of processing payment with credit cards and improvement to ease of transacting by enabling contactless payment.
The claims are not patent eligible.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 22-27, that the cited art of record does not teach “providing, by the server, a confirmation of the transaction to the service provider processing system to instruct the service provider to generate a confirmation of the transaction for transmission to the user system in response to the verifying of the authenticity of the requested transaction in response to the verified received user information related to the transaction,” and “redacting,” the Examiner respectfully disagrees. As discussed in the 103 rejection below, Davis teaches the limitation of providing, by the server, a confirmation of the transaction to the service provider processing system to instruct the service provider to generate a confirmation of the transaction for transmission to the user system in response to the verifying of the authenticity of the requested transaction in response to the verified received user information related to the transaction at least at [0129], disclosing that the application can send the payment message content to the merchant client device so that the client application of the merchant client device can post the payment message content, for example by adding text of the payment message to a messaging thread between the consumer and the merchant, and at least at [0149], in which a payment message is added to a thread such as “Your order # is 35… Hi Brad, your order is ready.” The cited art of record therefore teaches this limitation.
Furthermore regarding the argument that the cited art of record does not teach “redacting,” the Examiner respectfully disagrees. As discussed in the 103 rejection below, Brotsky teaches this limitation at least at [0059]-[0060], describing sanitizing information by removing sensitive information. The cited art of record therefore teaches this limitation.
For the reasons above, Applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the limitation “only information that is sufficient for the service provider processing system to complete the transaction” is relative and renders the claim indefinite. “Sufficient” information is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Therefore, the limitation “only information that is sufficient for the service provider processing system to complete the transaction” is rendered indefinite by use of the term “sufficient.”
Furthermore regarding claim 1, the claim recites “redacting… user information to include only information that is sufficient… to complete the transaction.” The limitation is confusing because it is not clear whether the sufficient information is being redacted or left intact. For example, is the claim redacting information including the sufficient information, or is the claim redacting other information until only sufficient information is left. For examination purposes, the Examiner interprets this limitation as “redacting, by the server, user information until the user information includes only information that is sufficient for the service provider processing system to complete the transaction.” (emphasis added).
Furthermore regrading claim 1, claim 1 recites the limitation “instruct the service provider to generate a confirmation… in response to verifying the authenticity of the requested transaction in response to the verified received user information related to the transaction.” This limitation is confusing because it is not clear what is meant by performing an action (e.g., instruct) in response to a value (e.g., the verified received user information). For examination purposes, the Examiner is interpreting the limitation as “instruct the service provider to generate a confirmation… in response to verifying the authenticity of the requested transaction, and in response to verifying the received user information related to the transaction” (emphasis added).
Claims 16 and 17 recite similar limitations found in claim 1 above, and therefore are rejected by the same rationale.
The rest of the dependent claims are rejected due to their dependency to a rejected claim.
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-18 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 16, and 17 are directed to a method (claim 1), a system (claim 16), and an apparatus (claim 17). Therefore, on its face, each independent claim 1, 16, and 17 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 16, and 17 recite, in part, a method, a system, and an apparatus of organizing human activity. Using the limitations in claim 1 to illustrate, the claim recites a method for facilitating a transaction and authenticating a user in the transaction, the method comprising: receiving a transaction request related to a transaction; providing user instructions related to the transaction in response to the transaction request; receiving user information related to the transaction; verifying the received user information related to the transaction; verifying authenticity of the requested transaction in response to the received user information; redacting user information to include only information that is sufficient for the service provider processing system to complete the transaction; providing, the redacted user information and providing a confirmation of the transaction to instruct the service provider to generate a confirmation of the transaction for transmission to the user system in response to the verifying of the authenticity of the requested transaction in response to the verified received user information related to the transaction. The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for receiving a transaction request, redacting data from the transaction request, verifying user information related to the transaction, and processing and confirming the transaction, which is a commercial and legal interaction, specifically a commercial interaction of sales activities or behaviors. The mere nominal recitation of a server does not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of a server; a service provider processing system; a user system; data acquisition instructions to activate software in the user system; communication via a first communication network; and a second communication network are recited at a high-level or generality (i.e., as a generic computer components performing generic computer functions of receiving a request, providing instructions, receiving information, verifying information, and providing a confirmation) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claims 9-12, 13-15, and 18 simply help to define the abstract idea.
Dependent claims 2-8 simply further describes the technological environment.
Claim 2 recites the additional elements of the second communication network is the first communication network. Claim 3 recites the additional elements of the first communication network is an Internet and the second communication network is a cellular network. Claim 4 recites the additional elements of each of the first and second communication networks are at least one selected from a group of Internet, cellular network, near field communication, Bluetooth, radio encoded communication and visually encoded communication. These limitations merely further describe the communication networks of the generally linked computer network and do not impose any meaningful limits on practicing the abstract idea.
Claim 5 recites the additional elements of the server and the service provider processing system are co-located in the same device. Claim 6 recites the additional elements of the server and the service provider processing system are co-located in the same location. These limitations merely further describe the devices of the generally linked computer network and do not impose any meaningful limits on practicing the abstract idea.
Claim 7 recites the additional elements of user instructions are included in at least one selected from a group of a text message, visually encoded message, and radio encoded message to the user system and include a uniform resource identifier. Claim 8 recites the additional elements of providing, by the server, a software application to the user system to process the user information related to the transaction via the first communication network in response to a user selection of the uniform resource identifier. These limitations merely further describes the types of transmission of message used by the devices of the generally linked computer network and do not impose any meaningful limits on practicing the abstract idea.
The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-18 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 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.
The factual inquiries 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.
Claims 1-4 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160180325 A1 (“Davis”) in view of US 20170098215 A1 (“Brotsky”).
Regarding claim 1, Davis discloses a method for facilitating a transaction and authenticating a user in the transaction, the method comprising (see at least FIG. 3A.):
receiving, by a server, a transaction request related to a transaction between a service provider processing system and a user system from the service provider processing system (Payment request message sent from Merchant Client Device to Server Device. See at least [0109] and FIG. 3A, Message 300 being sent from Merchant Client Device 200 to Server Device 108. The payment request message can be a payment message indicating a payment amount for a product or service provided by the merchant. See at least [0109]. The payment request message may include an identifier for the consumer, an identifier for the merchant, a payment amount, a product/service ID, a currency type. See at least [0110]. Transaction may be between a merchant client device and consumer client device. See at least [0036]. The Examiner is interpreting the Server Device (for example, FIG. 3A Server Device 108) as the server. The Examiner is also interpreting the Merchant Client Device (for example, FIG. 3A Merchant Client Device 200b) as the service provider processing system. And the Examiner is interpreting the Consumer Client Device (for example, FIG. 3A, Consumer Client Device 200a) as the user system.)
via a first communication network (Server Device and Merchant Client Device in communication via Network. See at least FIG. 1, Server Device 108 in communication with Merchant Client Device 200b via Network 105. The client devices can communicate with the through the network. In one or more embodiments, the network includes the Internet or World Wide Web. The network, however, can include one or more private and/or public networks that use various communication technologies and protocols. See at least [0041]. Communication handler of the Service Device can re-format or otherwise modify the content or format of a message based on the messaging protocol used by a destination communication device or a type. See at least [0083]. Examples of communication protocols, see at least [0244].);
providing, by the server, data acquisition instructions to activate software in the user system and user instructions related to the transaction to the user system via a second communication network in response to the transaction request (The Server Device forwards the payment request message to the consumer client device. See at least [0117]. See also FIG. 3A, Send Payment Request Message 300 sent from Server Device 108 to Consumer Client Device 200a. See also [0175] and FIG. 4C, depicting a payment request message stating “A 2% grande latte costs $3.75.” The “$3.75” of the payment message may be selectable, or the user device can be provided a notification (e.g., a pop-up window or other onscreen element) to ask the consumer if the consumer would like to initiate a payment transaction with the merchant based on the payment request message. See at least [0176]. Server Device and Consumer Client Device in communication via Network. See at least FIG. 1, Server Device 108 in communication with Consumer Client Device 200a via Network 105. The client devices can communicate with the through the network. In one or more embodiments, the network includes the Internet or World Wide Web. The network, however, can include one or more private and/or public networks that use various communication technologies and protocols. See at least [0041]. Communication handler of the Service Device can re-format or otherwise modify the content or format of a message based on the messaging protocol used by a destination communication device or a type. See at least [0083]. Examples of communication protocols, see at least [0244]. In view of the Specification of the instant application at para. 42-43, the Examiner is interpreting the request to pay the payment amount (e.g., $3.75) in the form of a selectable message or a notification asking the consumer if the consumer would like to initiate a payment transaction as “data acquisition instructions” and “user instructions related to the transaction.);
receiving, by the server, user information related to the transaction from the user system (The consumer client device can generate a payment message in response to the payment request message. The payment message can include the same contents as the payment request message and provide authorization to the charge the payment credential of the consumer. In particular, the payment message can include the identifier for the consumer, an identifier for the merchant, a payment amount, a product/service ID, a currency type, a message thread identifier, and a time stamp. See at least [0120] and FIG. 3A, Generate Payment Message 310 and Consumer Client Device 200a performing Send Payment Message 312 to Server Device 108. The client application of the Consumer Client Device can send the obfuscated user identifier with the payment message. See at least [0125].);
verifying, by the server, the received user information related to the transaction; verifying, by the server, authenticity of the requested transaction in response to the received user information (The network application of the Server Device can receive the obfuscated user identifier with the payment message. The network application and payment engine of the Server Device can verify that the obfuscated user identifier is valid. This process may server as the authentication for the consumer. See at least [0125].);
providing, by the server, user information to the service provider processing system (The payment engine of Server Device can provide a token to the merchant client device. See at least [0130] and see also FIG. 3B, the Server Device 108 performing the step of Provide Token 330 to the Merchant Client Device 200b. Token includes user information, see at least [0074].)
via the first communication network (Server Device and Merchant Client Device in communication via Network. See at least FIG. 1, Server Device 108 in communication with Merchant Client Device 200b via Network 105.); and
providing, by the server, a confirmation of the transaction to the service provider processing system to instruct the service provider to generate a confirmation of the transaction for transmission to the user system in response to the verifying of the authenticity of the requested transaction in response to the verified received user information related to the transaction (The network application can send the payment message content to the merchant client device so that the client application of the merchant client device can post the payment message content, for example by adding text of the payment message to a messaging thread between the consumer and the merchant. See at least [0129]. See also FIG. 3B, Server Device 108 performing Send Payment Message Content 326 to Merchant Client Device 200b, and Merchant Client Device 200b performing Post Payment Message Content 328. Payment message added to thread from merchant device to client device may be “Your order # is 35. Give us 3-5 minutes. Hi Brad. Your order is ready.” See at least [0194] and FIG. 4I.).
Davis does not expressly disclose redacting, by the server, user information to include only information that is sufficient for the service provider processing system to complete the transaction. Furthermore, while Davis discloses providing, by the server, information, Davis does not expressly disclose providing the redacted information.
However, Brotsky discloses redacting, by the server, user information to include only information that is sufficient for the service provider processing system to complete the transaction; providing the redacted information (The data protection system receives the sensitive information in the form of the online purchase data from the computing device. Sensitive information is removed to sanitize the online purchase data. For instance, the sanitizer module of the data protection system removes the sensitive information from the online purchase data to sanitize the online purchase data. The sanitized online purchase data is communicated to the eCommerce server that then initiates a communication intended for a payment service provider to obtain payment authorization of the online purchase. For example, the data protection system communicates the sanitized purchase data to the eCommerce server, thereby relieving security compliance requirements at the eCommerce server. Because the eCommerce server does not store or receive the sensitive information, security compliance requirements are relieved. In some implementations, the eCommerce server initiates a communication intended for the payment service provider by generating a purchase authorization request. See at least [0059]-[0060]. See also FIG. 4, steps 402-410.).
From the teaching of Brotsky, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the providing of information of Davis by redacting the information to include only information that is sufficient to complete the transaction, as taught by Brotsky, in order to relieve security compliance requirements for a merchant (see Brotsky at least at Abstract, [0060], and [0014]), in order to reduce cost associated with security standards for protecting customer sensitive data (see Brotsky at least at [0001]-[0002]), and in order to optimize security and reduce applicable security compliance requirements (see Brotsky at least at [0016]-[0017]).
Regarding claim 2, the combination of Davis and Brotsky disclose the limitations of claim 1, as discussed above, and Davis further discloses the second communication network is the first communication network (The client devices can communicate with the through the network. In one or more embodiments, the network includes the Internet or World Wide Web. The network, however, can include one or more private and/or public networks that use various communication technologies and protocols. See at least [0041]. Communication handler of the Service Device can re-format or otherwise modify the content or format of a message based on the messaging protocol used by a destination communication device or a type. See at least [0083]. Examples of communication protocols that may be used include, but are not limited to… Internet Protocol (“IP”), and other suitable communications networks. See at least [0244]. See also FIG. 1, Network 105 which may be an Internet network communication channel for Server Device 108, Consumer Client Device 200a, and Merchant Client Device 200b.).
Regarding claim 3, the combination of Davis and Brotsky disclose the limitations of claim 1, as discussed above, and Davis further discloses the first communication network is an Internet network and the second communication network is a cellular network (The client devices can communicate with the through the network. In one or more embodiments, the network includes the Internet or World Wide Web. The network, however, can include one or more private and/or public networks that use various communication technologies and protocols. See at least [0041]. Communication handler of the Service Device can re-format or otherwise modify the content or format of a message based on the messaging protocol used by a destination communication device or a type. See at least [0083]. Examples of communication protocols that may be used include, but are not limited to, data transmission media, communications devices, Transmission Control Protocol (“TCP”), Internet Protocol (“IP”), File Transfer Protocol (“FTP”), Telnet, Hypertext Transfer Protocol (“HTTP”), Hypertext Transfer Protocol Secure (“HTTPS”), Session Initiation Protocol (“SIP”), Simple Object Access Protocol (“SOAP”), Extensible Mark-up Language (“XML”) and variations thereof, Simple Mail Transfer Protocol (“SMTP”), Real-Time Transport Protocol (“RTP”), User Datagram Protocol (“UDP”), Global System for Mobile Communications (“GSM”) technologies, Code Division Multiple Access (“CDMA”) technologies, Time Division Multiple Access (“TDMA”) technologies, Short Message Service (“SMS”), Multimedia Message Service (“MMS”), radio frequency (“RF”) signaling technologies, Long Term Evolution (“LTE”) technologies, wireless communication technologies, in-band and out-of-band signaling technologies, and other suitable communications networks and technologies See at least [0244]. The Examiner interprets the messaging app between the merchant and consumer (as depicted in FIG. 4C) over a network such as the Internet as the first communication channel. And the Examiner interprets the communication channel between the server device and client device (for example, wireless communication technologies) as the second communication channel.).
Regarding claim 4, the combination of Davis and Brotsky disclose the limitations of claim 1, as discussed above, and Davis further discloses each of the first and second communication networks are at least one selected from a group of Internet network, cellular network, near field communication, Bluetooth, radio encoded communication and visually encoded communication (The client devices can communicate with the through the network. In one or more embodiments, the network includes the Internet or World Wide Web. The network, however, can include one or more private and/or public networks that use various communication technologies and protocols. See at least [0041]. Communication handler of the Service Device can re-format or otherwise modify the content or format of a message based on the messaging protocol used by a destination communication device or a type. See at least [0083]. Examples of communication protocols that may be used include, but are not limited to, data transmission media, communications devices, Transmission Control Protocol (“TCP”), Internet Protocol (“IP”), File Transfer Protocol (“FTP”), Telnet, Hypertext Transfer Protocol (“HTTP”), Hypertext Transfer Protocol Secure (“HTTPS”), Session Initiation Protocol (“SIP”), Simple Object Access Protocol (“SOAP”), Extensible Mark-up Language (“XML”) and variations thereof, Simple Mail Transfer Protocol (“SMTP”), Real-Time Transport Protocol (“RTP”), User Datagram Protocol (“UDP”), Global System for Mobile Communications (“GSM”) technologies, Code Division Multiple Access (“CDMA”) technologies, Time Division Multiple Access (“TDMA”) technologies, Short Message Service (“SMS”), Multimedia Message Service (“MMS”), radio frequency (“RF”) signaling technologies, Long Term Evolution (“LTE”) technologies, wireless communication technologies, in-band and out-of-band signaling technologies, and other suitable communications networks and technologies See at least [0244]. The Examiner interprets the messaging app between the merchant and consumer (as depicted in FIG. 4C) over a network such as the Internet as the first communication channel. And the Examiner interprets the communication channel between the server device and client device (for example, IP protocol over the Internet or World Wide Web) as the second communication channel.).
Claim 16 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Davis discloses a system comprising: a memory storing computer-executable instructions; and a processor executing the computer-executable instructions (See at least [0228]-[0230].).
Claim 17 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Davis discloses a non-transitory computer-readable storage medium comprising instructions executable by a processor (See at least [0228]-[0230].).
Claims 5-6, 9-10, and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Brotsky, and in further view of US 20160335637 A1 (“Deshpande”).
Regarding claim 5, the combination of Davis and Brotsky discloses the limitations of claim 1, as discussed above. While Davis generally discloses that devices of a system may be physically or logically co-located with each other (see Davis at least at [0247]), Davis does not expressly disclose the server and the service provider processing system are co-located in the same device.
However, Deshpande discloses the server and the service provider processing system are co-located in the same device (Each of the merchant, the acquirer, the payment network, the issuer, and the message transaction host may be implemented in one computing device. See at least [0027].).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the location of the server and the service provider processing system to be co-located in the same device, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Regarding claim 6, the combination of Davis and Brotsky discloses the limitations of claim 1, as discussed above. While Davis generally discloses that devices of a system may be physically or logically co-located with each other (see Davis at least at [0247]), Davis does not expressly disclose the server and the service provider processing system are co-located in the same location.
However, Deshpande discloses the server and the service provider processing system are co-located in the same location (Each of the merchant, the acquirer, the payment network, the issuer, and the message transaction host, may be implemented in one or more computing devices, such as a computing device or multiple computing devices located together, or distributed across a geographic region. See at least [0027]).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the location of the server and the service provider processing system of Davis to be co-located in the same location, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Regarding claim 9, the combination of Davis and Brotsky teaches the limitations of claim 1, as discussed above, and Davis further discloses the transaction is related to a service provided by the service provider processing system to the user system (The system can allow a consumer to make a pay a merchant for a product or service. See at least [0029].),
the user instructions include payment information related to the transaction (The Server Device forwards the payment request message to the consumer client device. See at least [0117]. See also FIG. 3A, Send Payment Request Message 300 sent from Server Device 108 to Consumer Client Device 200a. See also [0175] and FIG. 4C, depicting a payment request message stating “A 2% grande latte costs $3.75.” The “$3.75” of the payment message may be selectable, or the user device can be provided a notification (e.g., a pop-up window or other onscreen element) to ask the consumer if the consumer would like to initiate a payment transaction with the merchant based on the payment request message. See at least [0176]. The Examiner is interpreting Server Device as the server. The Examiner is interpreting the request to pay the payment amount (e.g., $3.75) in the form of a selectable message or a notification asking the consumer if the consumer would like to initiate a payment transaction as “user instructions related to the transaction.” The Examiner is also interpreting the payment amount (e.g., $3.75) as including payment information related to the transaction.).
Davis does not expressly disclose the user information includes information that completes the payment information and also includes a digital approval of the transaction by the user system.
However, Deshpande discloses the user information includes information that completes the payment information and also includes a digital approval of the transaction by the user system (The consumer may be prompted to respond (with the approval code) with a PIN or password associated with the portable communication device or payment account. See at least [0043]. The Examiner interprets the approval code, which is used to process and complete the transaction for the charge amount, as user information that completes the payment information. The Examiner also interprets the PIN as a digital approval of the transaction by the user system.).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the user information of Davis to include information that completes the payment information and also includes a digital approval of the transaction by the user system, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Regarding claim 10, the combination of Davis, Brotsky, and Deshpande teach the limitations of claim 9, as discussed above. Davis does not expressly disclose the digital approval includes at least one selected from a group of a personal identification number, handwritten signature, biometrics, digital signature, user knowledge and user identifier.
However, Deshpande discloses the digital approval includes at least one selected from a group of a personal identification number, handwritten signature, biometrics, digital signature, user knowledge and user identifier (The consumer may be prompted to respond (with the approval code) with a PIN or password associated with the portable communication device or payment account. See at least [0043].).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the user information of Davis to include information that completes the payment information and also includes a digital approval of the transaction by the user system, the digital approval being a PIN, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Regarding claim 12, the combination of Davis and Brotsky disclose the limitations of claim 1, as discussed above, and Davis further discloses providing, by the server, an electronic notification of the confirmed transaction to the user system (Server Device provides a payment complete status message to the Client Customer Device. See at least [0142] and FIG. 3C, Step 348.).
While Davis discloses providing an electronic notification, Davis does not expressly disclose providing by the server instructions to the service provider processing system to provide the notification.
However, Deshpande discloses providing by the server instructions to the service provider processing system to provide the notification (The message transaction host receives the authorization response, and at, transmits a transaction conformation, including an approval or decline of the transaction, to the portable communication device associated with the merchant. See at least [0045] and FIG. 5, step 514.).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the providing of Davis to provide instructions to the service provider processing system to provide the notification, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Regarding claim 13, the combination of Davis, Brotsky, and Deshpande disclose the limitations of claim 12, as discussed above, and Davis further discloses the electronic notification is at least one selected from a group of a receipt, a confirmation, an invoice, an authorization code, and an acknowledgement (Server Device provides a payment complete status message to the Client Customer Device. See at least [0142] and FIG. 3C, Step 348. The Examiner is interpreting the payment complete status message as a confirmation.).
Regarding claim 14, the combination of Davis and Brotsky teach the limitations of claim 1, as discussed above. Davis does not expressly disclose the service provider processing system is a point of service system.
However, Deshpande further discloses the service provider processing system is a point of service system (The merchant includes a sales person, who is associated with portable communication device, such as, for example, a mobile phone, etc. The sales person is associated with the merchant, and may include, for example, an owner, employee, checkout clerk, sales associate, service person, worker, etc., who (is affiliated with merchant and) aids consumer in the purchase of products offered for purchase, or performs or causes to be performed the service(s), for which the consumer is paying, and/or any other person associated with the merchant and involved in the transaction, etc. The portable communication device is configured to exchange SMS messages with other devices, and in particular, the message transaction host. See at least [0017].).
From the teaching of Deshpande, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the service provider processing system of Davis to be a point of service system, as taught by Deshpande, in order to in order to enable merchants to accept payment account transactions regardless of location, size, or sophistication of the merchant (see Deshpande at least at [0014]).
Claims 7-8, 11, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Brotsky, and in further view of US 20170256007 A1 (“Barman”).
Regarding claim 7, the combination of Davis and Brotsky teach the limitations of claim 1, as discussed above. Davis does not expressly disclose the user instructions are included in at least one selected from a group of a text message, visually encoded message, and radio encoded message to the user system and include a uniform resource identifier that requests the user information related to the transaction.
However, Barman discloses the user instructions are included in at least one selected from a group of a text message, visually encoded message, and radio encoded message to the user system and include a uniform resource identifier that requests the user information related to the transaction (A customer may receive a text message with a URL to access bill. See at least [0063] and FIG. 4, Message with URL 410. The URL requesting payment information of the payer. See at least [0077] and FIG. 8.).
From the teaching of Barman, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the user instructions of Davis to be included in a text message and include a URI, as taught by Barman, in order to improve efficiency of processing transactions between service providers and customers, in order to increase profits for merchants and in order to reduce customer’s time and convenience (see Barman at least at [0002]).
Regarding claim 8, the combination of Davis, Brotsky, and Barman teach the limitations of claim 7, as discussed above. Davis does not expressly disclose providing, by the server, a software application to the user system to process the user information related to the transaction via the first communication network in response to a user selection of the uniform resource identifier.
However, Barman discloses providing, by the server, a software application to the user system to process the user information related to the transaction via the first communication network in response to a user selection of the uniform resource identifier (A customer may receive a text message with a URL to access bill to pay. See at least [0063] and FIG. 4, Message with URL “upngopay.com” 410. A webpage application may then be access on the user device. The webpage application may be created by the Text payment server. See at least [0078], [0085], and FIGs. 5-8. Webpage may be accessed via application. See at least [0333]. Text payment server may be a part of a payment system and in network communication with restaurant point of sale devices. See at least [0052] and [0044]-[0046]. See also FIG. 1, Text payment server 105 in communication with Customer devices 110, 115, 120 via Network 125. See also FIGs. 5-8, depicting interactive elements including buttons and a slider button.).
From the teaching of Barman, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Davis to provide a software application to the user system in response to the user selection of the uniform resource identifier, as taught by Barman, in order to improve efficiency of processing transactions between service providers and customers, in order to increase profits for merchants and in order to reduce customer’s time and convenience (see Barman at least at [0002]).
Regarding claim 11, the combination of Davis and Brotsky teach the limitations of claim 1, as discussed above, and Davis further discloses the transaction is related to a service to be provided by the service provider processing system to the user system (The system can allow a consumer to make a pay a merchant for a product or service. See at least [0029].).
Davis does not expressly disclose the user information includes the user instructions include at least one form to be completed by the user system, and the user information includes information that completes the form and a digital signature of the user.
However, Barman discloses the user information includes the user instructions include at least one form to be completed by the user system (The URL requesting payment information of the payer in the form of a webpage application form. See at least [0077] and FIG. 8.), and
the user information includes information that completes the form and a digital signature of the user (The webpage may include a signature entry field; and the method may further include: receiving a signature from the customer device via the webpage; and sending an image of the signature to the restaurant computing system using the restaurant network address via the second network. See at least [0019]. See also [0072] and [0077]-[0080].).
From the teaching of Barman, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the user instructions of Davis to include the form taught by Barman, and to modify the user information of Davis to include information that completes the form and a digital signature of the user, as taught by Barman, in order to improve efficiency of processing transactions between service providers and customers, in order to increase profits for merchants and in order to reduce customer’s time and convenience (see Barman at least at [0002]).
Regarding claim 15, the combination of Davis and Brotsky teach the limitations of claim 1, as discussed above. Davis does not expressly disclose the service provider processing system is a check-in processing terminal.
However, Barman discloses the service provider processing system is a check-in processing terminal (Text payment server can receive information related to restaurant reservations made by customers. See at least [0091] and [0140]. The Examiner interprets the text payment server that can receive information related to restaurant reservations as a check-in processing terminal.).
From the teaching of Barman, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the service provider processing system of Davis to be a check-in processing terminal, as taught by Barman, in order to improve efficiency of processing transactions between service providers and customers, in order to increase profits for merchants and in order to reduce customer’s time and convenience (see Barman at least at [0002]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Brotsky, and in further view of US 20110166884 A1 (“Lesselroth”) .
Regarding claim 18, the combination of Davis and Brotsky teach the limitations of claim 1, as discussed above, and Davis further discloses providing, by the server, an information request to the user system (Server device sends a payment request message to consumer client device. See at least [0117] and FIG. 3A, step 300.); and
receiving, by the server, user information from the user system (The consumer client device sends an obfuscated user identifier with the payment message to the Server Device. See at least [0125] and FIG. 3A, step 302.).
While Davis discloses providing, by the server, information request, Davis does not expressly disclose the information requests for checking in by the user prior to a service related to the transaction. Furthermore, while Davis discloses receiving, by the server, user information, Davis does not expressly disclose user information that is related to the checking in by the user.
However, Lesselroth discloses the information requests for checking in by the user prior to a service related to the transaction (Patient portal check-in for a clinic appointment before entering the clinic exam room. See at least [0010]. Check-in interface includes various screens with questionnaire for patient intake. See at least FIG. 4 - FIG. 8, and see also [0080]-[0094].);
user information that is related to the checking in by the user (User may enter information on the interface to complete questionnaire. See at least FIG. 4- FIG. 8, and see also [0080]-[0094].).
From the teaching of Lesselroth, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the information request of Davis to be multiple information requests for checking in by a user prior to a service, as taught by Lesselroth, and to modify the user information of Davis to be information that is related to the checking in of the user, as taught by Lesselroth, in order to more accurately and more reliably gather information from users (see Lesselroth at least at [0005]-[0006]), and in order to increase efficiency while simultaneously completing important compliance measures (see Lesselroth at least at [0013]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mary MacPherson, "Website vs Web App: What’s the Difference?" dated July 26, 2019, https://medium.com/@essentialdesign/website-vs-web-app-whats-the-difference-e499b18b60b4 (hereinafter “MacPherson”) discloses “Websites are one-way informational feeds, they do not allow viewers to interact or communicate back to the site… Web applications are websites with functionality and interactive elements. Gmail, Facebook, YouTube, Twitter, etc. are all web apps that are dynamic, and built for user engagement… A web application is computer software accessed through a web browser.”
US 20120290421 A1 (“Qawami”) discloses a mobile payment system authorizes payment by sending a Short Message Service (SMS) text message or secure hypertext transfer protocol (HTTPS) request to a customer's mobile phone or mobile device requiring customer to respond by SMS or HTTPS.
US 20190130397 A1 (“Hameed”) discloses a host system pushing hosted Universal Resource Locators (URLs) to mobile computing devices.
US 20090327114 A1 (“Sheth”) discloses A method and system for securely verifying over an open network a transaction using a payment card requiring authorization, such as a PIN, to be used. The system utilizes a secure host system to establish two lines of communication between a merchant and a consumer device used by an individual using the payment card. The secure host system provides a verification interface that is presented to the consumer device, providing a means for the individual to provide verification information. The secure host system receives verification information from the consumer device, couples the verification information with card information supplied by a merchant for verification from a third party payment provider. The transaction service provider verifies the transaction without sending the cardholder's actual PIN over the open network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM 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 on (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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights