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 .
Election/Restrictions
Applicant's election with traverse of claims 32-40, 46, and 48-51 in the reply filed on February 13, 2026 is acknowledged. The traversal is on the ground(s) that “the burden on the Patent Office to consider all of the groups together is less than the burden on Applicant/the public to prosecute/search the applications/patents separately.” This is not found persuasive. It is noted that Applicant did not specifically point out why the established burden set forth in the election was not shown. The examiner restates there is a serious search and/or examination burden for the patentably distinct species because the species or groupings require a different field of search.
The requirement is still deemed proper and is therefore made FINAL.
Claims 32-40, 46, and 48-51 have been examined in this application. This communication is the first action on the merits.
Priority
Application 18/775,774 was filed on July 17, 2024 and claims benefit of CHINA 202310884417.8 July 18, 2023.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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 32-40, 46, and 49-50 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 pre-AIA the applicant regards as the invention.
Claims 32 and 40 provide no antecedent basis for the term “the payment application”.
Claims 36 and 37 provide no antecedent basis for the term “the first transaction party”.
Claim 36 provides no antecedent basis for the term “the server”.
Claim 38 provides no antecedent basis for the term “the payment link” and the term “the second transaction party”.
It is noted that Withdrawn Claim 42 has similar issues as claims 32 and 40.
Appropriate correction is required.
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 32-40, 46, and 48-51 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 32 recites the limitations of:
A payment method based on near field communication, comprising: sending, by a mobile terminal with a near field communication function, an electromagnetic signal used to trigger an NFC tag; obtaining tag information in the NFC tag in response to the electromagnetic signal; starting, based on the tag information, the payment application in the mobile terminal; and displaying the payment page based on the started payment application.
Claim 40 recites the limitations of:
A payment method based on near field communication, comprising:
sending, by a mobile terminal with a near field communication function, an electromagnetic signal used to trigger an NFC tag;
obtaining tag information in the NFC tag in response to the electromagnetic signal;
starting the payment application based on the tag information;
sending, based on the started payment application, payment processing request to a server, wherein the server is configured to process a payment service and to feed back a transaction result information based on the payment processing request; and
displaying a transaction result page based on the transaction result information fed back by the server.
Claim 48 recites the limitations of:
A payment method based on near field communication,
comprising: obtaining, by a server, a payment processing request generated by a mobile terminal with a near field communication function starting a payment application based on obtained tag information in an NFC tag; and
processing a payment service and to feed back a transaction result information based on the payment processing request.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction. For example, the specification discloses [0075] that the payment information is used to trigger a payment procedure and to perform payment and [0074] a user can complete payment by entering payment information such as a payment amount. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of a mobile terminal with a near field communication function providing a payment page for collecting, analyzing, and transmitting data to facilitate a financial transaction. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting “a mobile terminal with a near field communication function”, “NFC tag”, “payment application”, and “a server”, to perform the steps of “obtaining”, “starting”, and “displaying”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity or mental process. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification at discloses “[0299]The systems, apparatuses, modules, or units described in the above-mentioned embodiments can be specifically implemented by a computer chip or an entity, or can be implemented by a product having a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices. [0300]For ease of description, the above-mentioned apparatuses are described by dividing the apparatus into various units based on functions. Certainly, when this specification is implemented, functions of the units can be implemented in one or more pieces of software and/or hardware. [0301]A person skilled in the art should understand that an embodiment of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can use a form of hardware only embodiments, software only embodiments, or embodiments with a combination of software and hardware. Moreover, a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, a CD-ROM, an optical memory, etc.) that include computer-usable program code can be used in this specification.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, 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 of using “a mobile terminal with a near field communication function”, “NFC tag”, “payment application”, and “a server”, to perform the steps of “obtaining”, “starting”, and “displaying”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 40 and 48 are substantially similar to claim 32, thus, they are rejected on similar grounds.
Claim 40 recites the additional elements of “a server”.
Claim 48 recites the additional elements of “a server”.
For similar reasons as explained above with regard to claim 32, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 33-39, 46, and 49-51 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 32-40, 46, and 48-51 are not patent-eligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 48 and 51 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Rule, U.S. Patent Application Publication Number 2023/0419295.
As per claim 48,
Rule explicitly teaches:
A payment method based on near field communication, comprising: obtaining, by a server, a payment processing request generated by a mobile terminal with a near field communication function starting a payment application based on obtained tag information in an NFC tag; and
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list." "If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user." "The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
processing a payment service and to feed back a transaction result information based on the payment processing request.
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0024] Once authenticated, the account application may associate the user ID and the session ID with the account (e.g., in an account database stored by the application and/or a server). The application may then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a cryptogram. The application may read the cryptogram and transmit the cryptogram to a server associated with the first financial institution for verification. The application may further the parameters of the URI to the server." "[0026] The merchant server may receive the information from the server associated with the first financial institution, and identify the browsing session based on the session ID and/or user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include the payment information (e.g., VCN, expiration date, CVV) as well as any other personal information (e.g., name, address, email address, phone number, etc.) received from the server associated with the first financial institution. [0027] Furthermore, the server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the cryptogram and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and/or by the mobile device). Once refreshed, the payment information and personal information may be populated into the form in the web page. The user may then submit the form to process the payment in the web browser.")
As per claim 51,
Rule explicitly teaches:
A server comprising a memory and a processor, wherein the memory stores executable instructions that, in response to execution by the processor, cause the server to implement the payment method of claim 48.
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0024] Once authenticated, the account application may associate the user ID and the session ID with the account (e.g., in an account database stored by the application and/or a server). The application may then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a cryptogram. The application may read the cryptogram and transmit the cryptogram to a server associated with the first financial institution for verification. The application may further the parameters of the URI to the server." "[0026] The merchant server may receive the information from the server associated with the first financial institution, and identify the browsing session based on the session ID and/or user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include the payment information (e.g., VCN, expiration date, CVV) as well as any other personal information (e.g., name, address, email address, phone number, etc.) received from the server associated with the first financial institution. [0027] Furthermore, the server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the cryptogram and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and/or by the mobile device). Once refreshed, the payment information and personal information may be populated into the form in the web page. The user may then submit the form to process the payment in the web browser.")
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.
Claims 32-37, 39-40, and 46 are rejected under 35 U.S.C. 103 as being unpatentable over Herwig, U.S. Patent Application Publication Number 2010/0161434; in view of Rule, U.S. Patent Application Publication Number 2023/0419295.
As per claim 32,
Herwig explicitly teaches:
A payment method based on near field communication, comprising: sending, by a mobile terminal with a near field communication function, an electromagnetic signal used to trigger an NFC tag;
(Herwig US20100161434 at paras. 87-92, 101-103) ("[0102] Referring now to FIG. 4, a method of self-checkout comprises outputting an interrogation signal from an NFC communication module of a mobile telephone (Step 400). An antenna of an NFC tag receives the interrogation signal (Step 402). The interrogation signal is passed to a tag processor of the NFC tag (Step 404). The tag processor passes product data, related to a product associated with the NFC tag, to the antenna in response to receipt of the interrogation signal (Step 406). The antenna transmits the product data such that the product data is received by the NFC communications module of the mobile telephone (Step 408). The product data is passed to the mobile processor (Step 410). The mobile processor updates a list data structure stored at thereupon, the list data structure representing a list of items purchased by a user of the mobile device in response to receiving the product data. (Step 412).")
obtaining tag information in the NFC tag in response to the electromagnetic signal;
(Herwig US20100161434 at paras. 87-92, 101-103) ("[0102] Referring now to FIG. 4, a method of self-checkout comprises outputting an interrogation signal from an NFC communication module of a mobile telephone (Step 400). An antenna of an NFC tag receives the interrogation signal (Step 402). The interrogation signal is passed to a tag processor of the NFC tag (Step 404). The tag processor passes product data, related to a product associated with the NFC tag, to the antenna in response to receipt of the interrogation signal (Step 406). The antenna transmits the product data such that the product data is received by the NFC communications module of the mobile telephone (Step 408). The product data is passed to the mobile processor (Step 410). The mobile processor updates a list data structure stored at thereupon, the list data structure representing a list of items purchased by a user of the mobile device in response to receiving the product data. (Step 412).")
Herwig does not explicitly teach, however, Rule does teach:
starting, based on the tag information, the payment application in the mobile terminal; and
(Rule US20230419295 at paras. 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list. The graphical representation may include a matrix code (also referred to as a matrixed code, matrix barcode, etc.). Examples of matrix codes include, but are not limited to, a quick response (QR) code, app clip code, and the like. Therefore, in such embodiments, a camera (not pictured) or other optical reader of the computing device 102 may detect the matrix code that encodes the URI 144, e.g., in one or more images. Once the matrix code is detected, the operating system 136, web browser 140, and/or the web page 142 may decode the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144 as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user. As stated, the downloaded application may include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138. The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
displaying the payment page based on the started payment application.
(Rule US20230419295 at paras. 33, 38, 45-50, 101-104) ("[0046] the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user. As stated, the downloaded application may include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138. The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 33,
Herwig does not explicitly teach, however, Rule does teach:
wherein the payment page comprises at least one of information of a first transaction party, a control used to determine payment information, an area used to fill in or select a payment amount, and an area used to fill in or select a payment manner.
(Rule US20230419295 at paras. 33, 38, 45-50, 101-104) ("[0038] More generally, when accessing web pages provided by merchant server 108, a user may select one or more products, services, or other items for purchase via the web browser 140. For example, the user may wish to purchase a basketball and a soccer ball, and may add these items to their shopping cart. To complete the purchase, the web page 142 may include a form with one or more payment fields. The payment fields may include fields for an account number, expiration date, CVV, customer name, customer billing address, customer email address, customer phone number, etc." "[0046] As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 34,
Herwig does not explicitly teach, however, Rule does teach:
wherein the tag information comprises an application identification of a to-be-started payment application; starting the payment application in the mobile terminal based on the tag information specifically comprises: starting the payment application in the mobile terminal based on the application identification.
(Rule US20230419295 at paras. 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list. The graphical representation may include a matrix code (also referred to as a matrixed code, matrix barcode, etc.). Examples of matrix codes include, but are not limited to, a quick response (QR) code, app clip code, and the like. Therefore, in such embodiments, a camera (not pictured) or other optical reader of the computing device 102 may detect the matrix code that encodes the URI 144, e.g., in one or more images. Once the matrix code is detected, the operating system 136, web browser 140, and/or the web page 142 may decode the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144 as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user. As stated, the downloaded application may include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138. The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 35,
Herwig does not explicitly teach, however, Rule does teach:
wherein the method further comprises: determining whether the payment application exists in the terminal; and generating prompt information indicating that user downloads and installs the payment application if the payment application does not exist in the terminal.
(Rule US20230419295 at paras. 33, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list. The graphical representation may include a matrix code (also referred to as a matrixed code, matrix barcode, etc.). Examples of matrix codes include, but are not limited to, a quick response (QR) code, app clip code, and the like. Therefore, in such embodiments, a camera (not pictured) or other optical reader of the computing device 102 may detect the matrix code that encodes the URI 144, e.g., in one or more images. Once the matrix code is detected, the operating system 136, web browser 140, and/or the web page 142 may decode the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144 as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user. As stated, the downloaded application may include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138. The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 36,
Herwig does not explicitly teach, however, Rule does teach:
wherein the tag information includes request identification information used to request to obtain payment page information, and displaying the payment page based on the started payment application specifically comprises: generating, by the payment application in a started state, a payment page information obtaining request based on the request identification information;
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list." "If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user." "The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
sending the payment page information obtaining request to the server; obtaining payment page information that is generated by the server based on the payment page obtaining request and that includes the user information of the first transaction party; and displaying the payment page, based on the payment page information.
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0024] Once authenticated, the account application may associate the user ID and the session ID with the account (e.g., in an account database stored by the application and/or a server). The application may then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a cryptogram. The application may read the cryptogram and transmit the cryptogram to a server associated with the first financial institution for verification. The application may further the parameters of the URI to the server." "[0026] The merchant server may receive the information from the server associated with the first financial institution, and identify the browsing session based on the session ID and/or user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include the payment information (e.g., VCN, expiration date, CVV) as well as any other personal information (e.g., name, address, email address, phone number, etc.) received from the server associated with the first financial institution. [0027] Furthermore, the server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the cryptogram and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and/or by the mobile device). Once refreshed, the payment information and personal information may be populated into the form in the web page. The user may then submit the form to process the payment in the web browser.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 37,
Herwig explicitly teaches:
wherein the NFC tag is located in a carrier comprising a payment code of the first transaction party, or is located in a carrier that does not comprise a payment code of the first transaction party.
(Herwig US20100161434 at paras. 14-16) ("[0015] The at least one NFC tag may be located upon a shelf adjacent the product associated with the at least one NFC tag. The at least one NFC tag may be embedded in a price label on the shelf. The at least one NFC tag may be permanently attached to a shelf location and reprogrammed to reflect a product adjacent to the at least one NFC tag, as said product is changed. Alternatively, or additionally, the at least one NFC tag may be affixed to the product with which it is associated.")
As per claim 39,
Herwig explicitly teaches:
the method comprises: generating a page indicating a transaction result or prompt information.
(Herwig US20100161434 at paras. 87-92, 101-103) ("[0090] In some embodiments, the customer receives a prompt on the screen 112 of the mobile phone 102 to confirm that they wish to purchase the item 150. The prompt may contain pricing information about the item, confirmation usually proceeds via the consumer pressing a key on the keypad 110. If the customer rejects the item no further action is taken, a timeout period may be set where a consumer is presumed to have rejected the item if its purchase is not confirmed within the timeout period. This prevents items being added to the consumer's list when they have merely picked up the item to browse.")
As per claim 40,
Herwig explicitly teaches:
A payment method based on near field communication, comprising: sending, by a mobile terminal with a near field communication function, an electromagnetic signal used to trigger an NFC tag;
(Herwig US20100161434 at paras. 87-92, 101-103) ("[0102] Referring now to FIG. 4, a method of self-checkout comprises outputting an interrogation signal from an NFC communication module of a mobile telephone (Step 400). An antenna of an NFC tag receives the interrogation signal (Step 402). The interrogation signal is passed to a tag processor of the NFC tag (Step 404). The tag processor passes product data, related to a product associated with the NFC tag, to the antenna in response to receipt of the interrogation signal (Step 406). The antenna transmits the product data such that the product data is received by the NFC communications module of the mobile telephone (Step 408). The product data is passed to the mobile processor (Step 410). The mobile processor updates a list data structure stored at thereupon, the list data structure representing a list of items purchased by a user of the mobile device in response to receiving the product data. (Step 412).")
obtaining tag information in the NFC tag in response to the electromagnetic signal;
(Herwig US20100161434 at paras. 87-92, 101-103) ("[0102] Referring now to FIG. 4, a method of self-checkout comprises outputting an interrogation signal from an NFC communication module of a mobile telephone (Step 400). An antenna of an NFC tag receives the interrogation signal (Step 402). The interrogation signal is passed to a tag processor of the NFC tag (Step 404). The tag processor passes product data, related to a product associated with the NFC tag, to the antenna in response to receipt of the interrogation signal (Step 406). The antenna transmits the product data such that the product data is received by the NFC communications module of the mobile telephone (Step 408). The product data is passed to the mobile processor (Step 410). The mobile processor updates a list data structure stored at thereupon, the list data structure representing a list of items purchased by a user of the mobile device in response to receiving the product data. (Step 412).")
Herwig does not explicitly teach, however, Rule does teach:
starting the payment application based on the tag information;
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list." "If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user." "The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts." )
sending, based on the started payment application, payment processing request to a server, wherein the server is configured to process a payment service and to feed back a transaction result information based on the payment processing request; and displaying a transaction result page based on the transaction result information fed back by the server.
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0024] Once authenticated, the account application may associate the user ID and the session ID with the account (e.g., in an account database stored by the application and/or a server). The application may then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a cryptogram. The application may read the cryptogram and transmit the cryptogram to a server associated with the first financial institution for verification. The application may further the parameters of the URI to the server." "[0026] The merchant server may receive the information from the server associated with the first financial institution, and identify the browsing session based on the session ID and/or user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include the payment information (e.g., VCN, expiration date, CVV) as well as any other personal information (e.g., name, address, email address, phone number, etc.) received from the server associated with the first financial institution. [0027] Furthermore, the server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the cryptogram and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and/or by the mobile device). Once refreshed, the payment information and personal information may be populated into the form in the web page. The user may then submit the form to process the payment in the web browser.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
As per claim 46,
Herwig does not explicitly teach, however, Rule does teach:
wherein the tag information comprises identification of the payment application; starting the payment application based on the tag information, specifically comprises: starting the payment application based on the identification of the payment application.
(Rule US20230419295 at paras. 33, 38, 45-50, 101-104) ("[0046] As stated, in some embodiments, the account application 138 may not be installed on the computing device 102. Therefore, in some embodiments, the web page 142 may encode a graphical representation of the URI 144 (including the merchant ID parameter, user ID parameter, and session ID parameter), which may be displayed in the web page 142. The graphical representation may generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and/or select a financial institution from the list. The graphical representation may include a matrix code (also referred to as a matrixed code, matrix barcode, etc.). Examples of matrix codes include, but are not limited to, a quick response (QR) code, app clip code, and the like. Therefore, in such embodiments, a camera (not pictured) or other optical reader of the computing device 102 may detect the matrix code that encodes the URI 144, e.g., in one or more images. Once the matrix code is detected, the operating system 136, web browser 140, and/or the web page 142 may decode the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144 as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 may download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from a user. As stated, the downloaded application may include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138. The downloaded account application 138 may then be accessed, launched, or otherwise displayed. As stated, the parameters of the URI 144 may be provided to the account application 138, which opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited in these contexts.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Herwig, U.S. Patent Application Publication Number 2010/0161434; in view of Rule, U.S. Patent Application Publication Number 2023/0419295; in view of Ding, U.S. Patent Application Publication Number 2020/0134601.
As per claim 38,
Herwig does not explicitly teach, however, Rule does teach:
displaying, based on the payment link information, the payment page specifically comprises: accessing the payment link information by using the target terminal application; and
(Rule US20230419295 at paras. 24-27, 33, 38, 45-50, 101-104) ("[0024] Once authenticated, the account application may associate the user ID and the session ID with the account (e.g., in an account database stored by the application and/or a server). The application may then instruct the user to tap their contactless card to the device, which causes the contactless card to generate a cryptogram. The application may read the cryptogram and transmit the cryptogram to a server associated with the first financial institution for verification. The application may further the parameters of the URI to the server." "[0026] The merchant server may receive the information from the server associated with the first financial institution, and identify the browsing session based on the session ID and/or user ID. The merchant server may then cause one or more form fields on the checkout page to be populated with the received information from the server. In some embodiments, the merchant server may push these values to the mobile web browser. In other embodiments, the merchant server causes the checkout page to be reloaded. Once reloaded, the form fields may include the payment information (e.g., VCN, expiration date, CVV) as well as any other personal information (e.g., name, address, email address, phone number, etc.) received from the server associated with the first financial institution. [0027] Furthermore, the server associated with the first financial institution may transmit a decryption result to the account application. The decryption result may specify that the server verified (or decrypted) the cryptogram and generated the VCN. The decryption result may cause the account application to return the device to the mobile web browser. The checkout page may be refreshed in the web browser (e.g., by the merchant server and/or by the mobile device). Once refreshed, the payment information and personal information may be populated into the form in the web page. The user may then submit the form to process the payment in the web browser.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig and Rule, because it allows for an improved system to provide secure, automated, checkout processes using a contactless card. (Rule at Abstract and paras. 1-2, 28).
Herwig and Rule do not explicitly teach, however, Ding does teach:
wherein the tag information comprises first triggering information, the first triggering information is used to trigger the mobile terminal to determine a terminal application with a payment function in the mobile terminal and generate an application selection page, and the method further comprises:
(Ding US20200134601 at paras. 5-20) ("[0007] According to a first aspect, an NFC payment method is provided, where the method includes: displaying, by a first terminal, at least one third-party payment application based on a preset trigger condition; and determining, by the first terminal, one of the at least one third-party payment application as a target third-party payment application, and interacting with a second terminal by using the target third-party payment application, to complete NFC payment." "[0010] In a possible design, the displaying, by a first terminal, at least one third-party payment application based on a preset trigger condition includes: receiving, by the first terminal, a quick operation of a user; and displaying the at least one third-party payment application based on the quick operation.")
determining, in response to the first triggering information, the terminal application with the payment function in the mobile terminal;
(Ding US20200134601 at paras. 5-20) ("[0007] determining, by the first terminal, one of the at least one third-party payment application as a target third-party payment application.")
generating the application selection page based on the terminal application with the payment function; displaying the application selection page; obtaining a target terminal application selected by the second transaction party from the application selection page; and
(Ding US20200134601 at paras. 5-20) ("[0010] In a possible design, the displaying, by a first terminal, at least one third-party payment application based on a preset trigger condition includes: receiving, by the first terminal, a quick operation of a user; and displaying the at least one third-party payment application based on the quick operation.")
displaying, in the target terminal application, the payment page.
(Ding US20200134601 at paras. 5-20) ("[0013] In a possible design, the first terminal receives, through an NFC connection established between the first terminal and the second terminal, an application selection instruction that carries an application identifier (application identification, AID) of the target third-party payment application and that is sent by the second terminal; and The first terminal displays the target third-party payment application based on the application selection instruction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Herwig, Rule, and Ding, because it allows for an improved system to provide an NFC payment method and a terminal, to resolve a prior-art problem that operations are troublesome when a third-party payment application is used to make payment. (Ding at Abstract and paras. 1-6, 28).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695