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 January 08, 2026, has been entered.
Status of Claims
Applicant filed an amendment on January 08, 2026. Claims 1-30 were pending in the Application. Claim 11 is amended. No new claims have been added. No new claims have been canceled with claim 6 remaining canceled, and claims 12-30 remaining withdrawn from consideration. Claim 1 is the independent claim, the remaining claims depend on claim 1. Thus claims 1-5 and 7-11 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Response to Arguments
In the context of 35 U.S.C. § 112(d), Improper Dependent Claim, for paragraph 17 of the Final Rejection Office Action dated October 08, 2025, Applicant has not adequately amended to render the rejection under 35 U.S.C. § 112(d), Improper Dependent Claim, moot. Applicant has amended claim 11 to recite “The method according to claim 1, wherein the method further comprises: determining that the terminal application does not exist in the mobile terminal, and …”. Claim 1 lacks a “terminal application in the mobile terminal”, but instead recites “the mobile terminal is displaying an application image of a second application”, and it is not made clear whether the application image of a second application is a terminal application in the mobile termination. Specification, (PG Pub US 20250131410 A1, para 76), recites “The payment application can represent a terminal application with a payment function. After obtaining, through near field communication, instruction information that is in the tag information and that is used to start the payment application, the mobile terminal can start the payment application in the mobile terminal, and then display the payment page based on the started payment application. The payment page can indicate an application page of the payment application …”, providing support for the payment application representing a terminal application with a payment function, with the tag information being used to start the payment application and the mobile terminal starting the payment application in the mobile terminal.
However, the limitation “determining that the terminal application does not exist …” in claim 11, contradicts the limitations “determining that the mobile terminal is displaying an application image of a second application; in response to determining that the mobile terminal is displaying the application image of the second application, displaying, based on the payment link information, a payment page …” in claim 1. Therefore, claim 11 does not further limit claim 1, according to specification, (‘410 A1, para 76), that discloses the payment application can be represented as a terminal function with a payment function, with the tag information being used to start the payment application and the mobile terminal starting the payment application in the mobile terminal. Examiner hereby maintains the rejection under 35 U.S.C. § 112(d), Improper Dependent Claim, paragraph 17 of the Final Rejection Office Action dated October 08, 2025.
In the context of 35 U.S.C. § 103, Applicant respectfully submits that the rationale cited by the Examiner “that it would have been obvious to combine Lin with Liu and Herwig to “provide an information display resolving a problem … that when there are a plurality of codes to be scanned, scanning efficiently is relatively low” is fundamentally misaligned with the problem solved by the present invention. As clearly stated in the specification (see para [0002]), the problem is simplifying user payment operations and improving user experience, specifically avoiding the need for a user to exit a current application (e.g., a game, a video, or book reader) to locate and open a separate payment application.
Applicant further submits that Lin addresses the problem of low efficiency when scanning multiple graphic codes. There is no motivation for one of ordinary skill in the art, seeking to solve the problem of payment workflow interruption, to look to Lin's teachings on multi-code scanning efficiency. The fields of endeavor and the core problems addressed are entirely distinct. Combining these references amounts to using the Applicant's disclosure as a blueprint, which is a classic example of hindsight reconstruction.
Examiner has considered these arguments and is not persuaded. Examiner submits that the specification (para [0002]) recites, “This application relates to the field of computer technologies, and in particular, to payment methods, apparatuses, and devices based on near field communication, and media”, and that it is para [0003] that recites “With development of computer technologies, mobile payment based on a payment code becomes more popular, and greatly improves payment experience of a user. However, as mobile applications develop, applications such as games, novels, and short videos occupy a terminal screen for more time. When payment needs to be performed, the user needs to exit a current application, find a payment application with a payment function from an application list of a mobile terminal, and enable a code scanning function or display a payment code in the payment application. In this way, user operations are relatively complex”, and para [0004], recites “Therefore, how to simplify payment operations of the user and improve user experience is an urgent technical problem to be resolved”.
Examiner further submits the Applicant did not completely recite the whole justification cited in the Final Rejection Office Action dated October 08, 2025, for motivation to combine the references of Lin, Herwig, and Lu. Examiner provided the motivation to combine references as “to provide an information display resolving a problem in the existing technology, that when there are a plurality of codes to be scanned, scanning efficiency is relatively low. This is accomplished by implementing a mobile terminal that can scan a plurality of graphic codes on the page of scanning, jump to the information display page after the predetermined condition is satisfied, and display a plurality of pieces of information simultaneously, improving the efficiency in scanning a plurality of graphic codes”. Examiner submits that the motivation is fundamentally aligned with the problem solved by the present invention in that when there are multiple codes to be scanned, Lin discloses that the multiple codes can be scanned and the information displayed on a single page without having to leave the information display page to scan each code, and that when a predetermined condition is satisfied, then displays the plurality of pieces of information simultaneously, thus improving the efficiency in scanning a plurality of codes, without having to leave and enter the single information page. Examiner maintains that one of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references of Lin, Herwig, and Lu. Therefore, claim 1 stands rejected under 35 U.S.C. § 103. Dependent claims 2-5 and 7-11, which depend on claim 1, also stand rejected under 35 U.S.C. § 103. The rejection under 35 U.S.C. § 103 for claims 1-5 and 7-11 is maintained.
In the context of 35 U.S.C. § 103, Applicant respectfully submits, even if combined, the references fail to disclose or suggest the specific, integrated process of claim 1: "determining that the mobile terminal is displaying an application image of a second application": This step establishes the context of the user's current activity. None of the cited references teach or suggest detecting the state of an unrelated, foreground application (the "second application") to conditionally trigger a payment flow.
"displaying, based on the payment link information, a payment page at an upper layer of the application page of the second application through superimposition": Lin's display of information occurs within its own dedicated scanning/display application. It does not teach or suggest superimposing a payment interface, retrieved via NFC -triggered "payment link information," as a layer on top of an arbitrary, pre-existing, and unrelated "second application." This seamless, non-disruptive overlay is a key technical contribution of the present invention, preserving the user's context.
Applicant submits that the prima facie case of obviousness is not established. Withdrawal of the rejection of claim 1 is requested.
Examiner has considered the argument of none of the cited references teach or suggest detecting the state of an unrelated, foreground application (the "second application") to conditionally trigger a payment flow, and is not persuaded. Examiner submits that for the limitation “determining that the mobile terminal is displaying an application image of a second application”, Lin, (US 10853436 B2, FIG. 2, 3, items 10, 11, 20, 21, 22; C/L 5/30-35; 6/6-11), discloses the mobile phone displaying a mobile phone screen, and therefore, teaches and suggests the mobile terminal; and Lin, (‘436 B2, FIG. 4, 5, items S220, S230, S240, 32; C/L 6/61-7/6; 7/25-51) discloses simultaneously display of the page for scanning in the upper part of the screen and an information display page displaying the first information on the information display page in the lower part of the screen being displayed, and therefore, teaches and suggests displaying an application of a second application. Therefore, claim 1 stands rejected under 35 U.S.C. § 103. Dependent claims 2-5 and 7-11, which depend on claim 1, also stand rejected under 35 U.S.C. § 103.
Examiner has considered the argument of Lin's display of information occurs within its own dedicated scanning/display application. It does not teach or suggest superimposing a payment interface, retrieved via NFC -triggered "payment link information," as a layer on top of an arbitrary, pre-existing, and unrelated "second application", and is not persuaded. Examiner submits that for the limitation “displaying, based on the payment link information, a payment page at an upper layer of the application page of the second application through superimposition”, Lin, (‘436 B2, FIG. 6, items 40, 411, 412, 42, 421, 422, 423, 43; C/L 8/3-34), discloses displaying product information including the product name, a unit price, and the number of products for one or more products on an information page with a payment button also being simultaneously displayed on the information display page, and therefore, teaches and suggests displaying, based on the payment link information, a payment page at an upper layer of the application page of the second application through superimposition. Therefore, claim 1 stands rejected under 35 U.S.C. § 103. Dependent claims 2-5 and 7-11, which depend on claim 1, also stand rejected under 35 U.S.C. § 103.
In the context of 35 U.S.C. § 103, Applicant respectfully submits, that the rejection of amended claim 1 now relies on Lin "applying to the applicable amended sections for claim 1" (Office Action, p. 5). The introduction of a new ground of rejection based on Lin in this Final Office Action is procedurally improper. A final action should only incorporate new grounds if it is in response to an amendment. Here, the amendment was made to incorporate features from canceled claim 6, which was previously argued to be non-obvious. The Examiner's new application of Lin to these features constitutes a new ground of rejection, for which a non-final action would be appropriate. Applicant respectfully requests withdrawal of this rejection on this procedural basis, or alternatively, requests that this Office Action be converted to non-final. Applicant submits that the prima facie case of obviousness is not established. Withdrawal of the rejection of claim 1 is requested.
Examiner submits that the original claim language for claim 6 of “The method according to claim 1, wherein if the mobile terminal is displaying an application page of a second application when the tag information that is in the NFC tag and that comprises the payment link information is obtained, the displaying a payment page comprising user information of a first transaction party specifically comprises: displaying the payment page at an upper layer of the application page of the second application through superimposition” was interpreted as conditional language, as the limitation “The method according to claim 1, wherein if the mobile terminal is displaying an application page of a second application when the tag information that is in the NFC tag and that comprises the payment link information is obtained, … displaying the payment page in an upper layer …” does not necessarily occur in the case “the mobile terminal is not displaying an application page of a second application”. The language “if the mobile terminal is displaying an application page of a second application” is optional language as the step “when the tag information that is in the NFC tag and that comprises the payment link information is obtained, …” does not necessarily occur in the case “the mobile terminal is not displaying an application page of a second application”, and as a result, will not differentiate the claim from the prior art.
According to MPEP § 2103 (I)(C), “The subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation, and as a result, will not differentiate the claim from the prior art for claim 6 in the Non-Final Rejection Office Action, dated June 10, 2025, as being optional language.
Examiner finds the applicant arguments for the limitations “determining that the mobile terminal is displaying an application image of a second application” and “in response to determining that the mobile terminal is displaying the application image of the second application, displaying, based on the payment link information, a payment page at an upper layer of the application page of the second application through superimposition, the payment page comprising user information of a first transaction party” moot in view of new grounds of rejection, and therefore, amended claim 1 is not patentable, as Applicant amended the original claim language for claim 6 to eliminate the conditional language, which was then canceled and incorporated into claim 1, Examiner interpreted this as an amendment to claim 1, and thus the Final Rejection Office Action, dated October 08, 2025, is proper.
Amended claim 1 stands rejected under 35 U.S.C §103, and is therefore, not patentable in view of Lin et al (US 10853436 B2) now applying to the applicable amended sections for claim 1. Dependent claims 2-5 and 7-11, which depend from claim 1, also stand rejected under 35 U.S.C. § 103. Examiner maintains the current rejection under 35 U.S.C. § 103.
Claim Interpretation – Intended Use
Regarding claim 7, Examiner notes that the following limitations: “The method according to claim 1, wherein tag information comprises first triggering information, the first triggering information is used to trigger the mobile terminal to determine a terminal application … and generate an application selection page, …” are intended uses of the “tag information” and the “mobile terminal”, respectively, and therefore carries limited patentable weight. Claim 8 also carries limited patentable weight as it depends from claim 7, and as a claim in proper dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. (MPEP § 2103 I C).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 11 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Improper Dependent Claim
Claim 1 recites “determining that the mobile terminal is displaying an application image of a second application; in response to determining that the mobile terminal is displaying the application image of the second application, displaying, based on the payment link information, a payment page ...”. Claim 11 recites “The method of claim 1, … comprises: determining that the terminal application does not exist in the mobile terminal …”. Claim 1 lacks a “terminal application in the mobile terminal”, but instead recites “the mobile terminal is displaying an application image of a second application”, and it is not made clear that the application image of a second application is a terminal application in the mobile terminal. Specification, (PG Pub US 20250131410 A1, para 76), recites “The payment application can represent a terminal application with a payment function. After obtaining, through near field communication, instruction information that is in the tag information and that is used to start the payment application, the mobile terminal can start the payment application in the mobile terminal, and then display the payment page based on the started payment application. The payment page can indicate an application page of the payment application …”, providing support for the payment application representing a terminal application with a payment function, with the tag information being used to start the payment application and the mobile terminal starting the payment application in the mobile terminal.
However, the limitation “determining that the terminal application does not exist …” in claim 11, contradicts the limitations “determining that the mobile terminal is displaying an application image of a second application; in response to determining that the mobile terminal is displaying the application image of the second application, displaying, based on the payment link information, a payment page …” in claim 1. Therefore, claim 11 does not further limit claim 1, according to specification, (‘410 A1, para 76), that discloses the payment application can be represented as a terminal function with a payment function, with the tag information being used to start the payment application and the mobile terminal starting the payment application in the mobile terminal. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Following the statute, the test as to whether a claim is a proper dependent claim is that it shall include every limitation of the claim from which it depends and specify a further limitation of the subject matter claimed.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5 and 10 are rejected under 35 U.S.C. § 103 as being unpatentable over Lu et al (U. S. Patent No. 11562344 B2), herein referred to as Lu, in view of Herwig et al (U. S. Patent No. 8494908 B2), herein referred to as Herwig, and in further view of Lin et al (U. S. Patent No. 10853436 B2), herein referred to as Lin.
Regarding claim 1, Lu discloses a payment method based on near field communication, comprising: …
… wherein the tag information comprises payment link information (C/L 5/21-30, “… since in the NFC tag, tag content such as merchant information has been saved, the mobile phone PAY can directly read the content in the tag directly and display the content directly in the mobile phone PAY according to a preset display format, and the process may not require networking; or the mobile phone PAY reads the content and parameters in the tag, and composes a webpage link according to a preset format, and calls the content in the NFC tag payment platform …”); …
… the payment page comprising user information of a first transaction party (FIG. 2, item S23; C/L 5/30-49, “… In step S23, under the condition that the mobile phone PAY supports the issuing authority, the mobile phone PAY organizes the network link, calls a tag payment HS page (HS: HTML5, Hyper Text Markup Language 5), and sends the NFC tag payment request information, wherein the NFC tag payment request information comprises the NFC tag content and the tag ID. Here, there exist two cases for the display of the HS page: (1) Under the condition of an environment with a better network, after the tag content is read by the mobile phone, forming a webpage link according to a certain format, accessing the NFC tag payment platform, pushing the HS page and the merchant data saved at the backend by the platform, and displaying the content on the HS page; (2) Under the condition of an environment with a poor network, the HS page is generated directly by the mobile phone and the content is read from the tag and displayed on the HS page …”);
obtaining payment information provided by a second transaction party based on the payment page (FIG. 2, item S28; C/L 6/4-8, “… In step S28, the mobile phone PAY wallet displays a payment interface according to the NFC tag parsing reply, and the user enters the payment amount … under the condition that it is a merchant with fixed amount, the user does not need to enter an amount …”); and …
Lu does not specifically disclose, however, Herwig discloses sending, by a mobile terminal (FIG. 2, items 102, 112; C/L 8/16-20, “… The mobile telephone 102 comprises a keypad 110, a screen 112, a speaker 114, a wireless transceiver, 116, a cellular transceiver 118, a processor 120 and an NFC module 122 …”) with a near field communication function, an electromagnetic signal used to trigger an NFC tag (FIG. 3, items 106, 132, 134; C/L 8/47-67, “… The NFC product tag 106 comprises an antenna 132 and a processor 134. The processor 134 modulates and demodu-lates radio-frequency signals and stores product data locally … the NFC tag 106 will be described with reference to a passive device with no internal power source in which power for generating an output signal is derived from a signal receive at the antenna … it will be appreciated that the present invention is equally applicable to semi-passive and active NFC modules as it is to passive RFID tags. A semi-passive module incorporates a power source that powers the IC. An active module comprises a power source that powers the IC and provides power to the output of a broadcast signal in response to an interrogation signal … the NFC tag 106 emits and receives electromagnetic radiation at 13.56 MHz with a 2.0 MHz bandwidth and usually supports data rates of 106 Kbps-1 using modified Miller coding with 100% modulation, or 212 or 424 Kbps-1using Manchester coding with a 10% modulation ratio. A typical effective range of an NFC tag is between 5 and 20 cm, usually 15 cm or less … ”; FIG. 4, items 400, 402, 404, 406, 408, 410; C/L12/4-15, “… Referring now to FIG. 4, a method of self-checkout com-prises outputting an interrogation signal from an NFC com-munication 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) …”);
obtaining tag information in the NFC tag in response to the electromagnetic signal (FIG. 4, items 400, 402, 404, 406, 408, 410; C/L 12/4-15, “… Referring now to FIG. 4, a method of self-checkout com-prises outputting an interrogation signal from an NFC com-munication 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) …”), …
sending a payment processing request comprising the payment information to a server, wherein the server is configured to complete payment based on the payment processing request (C/L 11/43-59, “… Irrespective of whether the pricing data is downloaded from the tag 106, or uploaded from the PLU database of the retail server 109, once the consumer has completed their shopping, they take the shopping cart 104 to the payment terminal 108. The respective NFC communication modules 122, 136 of the mobile telephone 102 and the payment terminal 108 establish a communication channel substantially as described hereinbefore. The processor 120 uploads the list data to the payment terminal 108 via the communication channel and the payment terminal 108 opens a connection to
a payment authorisation host (not shown), via a network connection 142. Typically, the authorisation host is that of a financial institution with whom the consumer has a bank account or a store/charging account. The total value of the items purchased by the consumer is sent to the authorisation host for authorisation in a manner known to those skilled in the art …”).
Herwig discloses a retail checkout system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide self-checkout in retail sales transactions utilizing near field communication (NFC) enabled mobile devices, NFC tags, and NFC communication modules, sending and receiving interrogation signals, and passing product data to a mobile processor where customers benefit from the convenience and reduced queuing times associated with self-checkout in completing transactions.
Lu and Herwig do not specifically disclose, however, Lin discloses determining that the mobile terminal (FIG. 2, items 10, 11; C/L 5/30-35, “… FIG. 2, when a user enables a scan tool on a mobile phone, a scan box 11 is displayed on a mobile phone screen 10. A two-dimensional code 12 that needs to be scanned is placed in a scan box for scanning. After the scanning is complete, the information recorded in the two-dimensional code 12 can be obtained …”; FIG. 3, items 20, 21, 22; C/L 6/6-11, “… When the terminal receives the predetermined instruction, as shown in FIG. 3, the terminal jumps to the information display page 20 to display the first information 21 and the second information 22 so that the user can view and compare the first information 21 and the second information 22 …”) is displaying an application image of a second application (FIG. 4, items S220, S230, S240, 32; C/L 6/61-7/6, “… S220: Simultaneously display the page for scanning and an information display page and display the first information on the information display page … the simultaneous display can be performed in at least one of a vertical form, a horizontal form, a pop-up window form, and a transparent background form. The vertical display form may be that the page for scanning is displayed in the upper part of a screen, and the information display page is displayed in the lower part of the screen; or the page for scanning is displayed in the lower part of the screen, and the information display page is 5 displayed in the upper part of the screen … ”; FIG. 5, items S320, S330, 32; C/L 7/25-51, “… the page for scanning in the upper part and the information display page in the lower part are displayed simultaneously. As shown in FIG. 5, after obtaining the first information by scanning the first graphic code, the page for scanning 31 is displayed in the upper part of the screen, and the information display page 32 is 30 displayed in the lower part of the screen. The scan box 310 is still located on the page for scanning 31, and can always scan a graphic code, and the first information 320 is dis-played on the information display page 32. S230: Receive second information obtained after the scan 35 box scans a second graphic code. This step is similar to step S210, "first" and "second" are merely for differentiation, and the second graphic code and the first graphic code may be different or may be the same. S240: Add the second information to the information display page. As shown in FIG. 5, after step S230, the second infor-mation 330 is added to the information display page 32 for comparison by the user … after scanning the graphic code on the page for scanning, the terminal simultaneously displays the page for scanning and the information display page so that the terminal can scan a plurality of graphic codes on the page for scanning. The information obtained by each scan can be added to the information display page in real time to improve efficiency in scanning a plurality of graphic codes …”);
in response to determining that the mobile terminal is displaying the application image of the second application (FIG. 4, items S220, S230, S240, 32; C/L 6/61-7/6, “… S220: Simultaneously display the page for scanning and an information display page and display the first information on the information display page … the simultaneous display can be performed in at least one of a vertical form, a horizontal form, a pop-up window form, and a transparent background form.
The vertical display form may be that the page for scanning is displayed in the upper part of a screen, and the information display page is displayed in the lower part of the screen; or the page for scanning is displayed in the lower part of the screen, and the information display page is displayed in the upper part of the screen …”; FIG. 5, items 32, S310, S320, S330; C/L7/25-51, “… the page for scanning in the upper part and the information display page in the lower part are displayed simultaneously … after obtaining the first information by scanning the first graphic code, the page for scanning 31 is displayed in the upper part of the screen, and the information display page 32 is displayed in the lower part of the screen. The scan box 310 is still located on the page for scanning 31, and can always scan a graphic code, and the first information 320 is displayed on the information display page 32. S230: Receive second information obtained after the scan box scans a second graphic code.
This step is similar to step S210, "first" and "second" are merely for differentiation, and the second graphic code and the first graphic code may be different or may be the same. S240: Add the second information to the information display page.
As shown in FIG. 5, after step S230, the second information 330 is added to the information display page 32 for comparison by the user … after scanning the graphic code on the page for scanning, the terminal simultaneously displays the page for scanning and the information display page so that the terminal can scan a plurality of graphic codes on the page for scanning. The information obtained by each scan can be added to the information display page in real time to improve efficiency in scanning a plurality of graphic codes …”), displaying, based on the payment link information, a payment page at an upper layer of the application page of the second application through superimposition (FIG. 6, items 40, 411, 412, 42, 421, 422, 423, 43; C/L 8/3-34, “… A shopping scan scenario is used as an example below to illustrate an information display method corresponding to the previous example shown in FIG. 1. The information display method includes the following: receiving first product information obtained after a scan box on a page for scanning scans a first graphic code; simultaneously displaying the page for scanning and an information display page and displaying the first product information on the information display page; receiving second product information obtained after the scan box scans a second graphic code, where the product information includes a unit price and the number of products; adding the second product information to the information display page; and calculating a total price based on a unit price and the number of products when a payment instruction is received and settling based on the total price. As shown in FIG. 6, as displayed on the information display page 40, the first product information 41 includes a product name 411, a unit price 412, and the number of products 413, and the second product information 42 includes a product name 421, a unit price 422, and the number of products 423. A payment button 43 is also displayed on the information display page 40. When the user clicks the payment button 43, step S350 is performed, and a total price is 8.5x1+18.0x2=44.5 yuan. The terminal settles based on the total price, namely, 44.5 yuan … the user can display a plurality of pieces of product information at a time after a plurality of graphic codes are scanned to improve efficiency in scanning a plurality of graphic codes… a plurality of products are purchased at a time when the terminal receives a payment instruction …”), …
Lin discloses an information display method and device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an information display method and device, as in Lin; to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide an information display resolving a problem in the existing technology, that when there are a plurality of codes to be scanned, scanning efficiency is relatively low. This is accomplished by implementing a mobile terminal that can scan a plurality of graphic codes on the page of scanning, jump to the information display page after the predetermined condition is satisfied, and display a plurality of pieces of information simultaneously, improving the efficiency in scanning a plurality of graphic codes without having to exit and enter the scanning application for multiple codes while displaying all scanned code information on an information display page.
Regarding claim 2, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu further discloses the method according to claim 1, wherein the displaying, based on the payment link information, a payment page comprises:
starting a terminal application with a payment function in the mobile terminal (FIG. 3, items S41, S42; C/L 4/51-5/5, “… a payment processing performed based on the NFC tag fabricated above is illustrated … the mobile phone PAY wallet reading the NFC tag is taken as an example, but of course other data processing systems capable of performing data processing on the NFC tag may be used apart from the mobile phone PAY wallet … the mobile phone PAY wallet touches the NFC tag, reads the tag ID, sends an NFC tag payment request to the NFC tag payment platform; the NFC tag payment platform sends an NFC tag parsing request to the merchant service platform after receiving the NFC tag payment request; the merchant service platform parses the tag and returns the analysis information to the NFC tag payment platform; the informa-tion again returns to the mobile phone PAY wallet, the mobile phone PAY wallet generates an order generation request based on the returned information and sends the request to the NFC tag payment platform, the NFC tag payment platform returns the generated order generation reply, and the mobile phone PAY wallet completes the payment …”; C/L 6/37-49, “… As shown in FIG. 3, in step S41, the mobile phone PAY wallet touches the NFC tag. In step S42, the NFC tag content and the tag ID are read and the issuing authority of the NFC tag is identified. In step S42, since tag content such as merchant information has already been saved in the tag, the mobile phone PAY wallet can directly read the content in the tag and display the content directly in the mobile phone PAY according to a preset display format, and the process may not require networking; or the mobile phone PAY reads the content and parameters in the tag, and composes a webpage link accord-ing to a preset format, and calls the content in the NFC tag payment platform …”); and
displaying the payment page based on the terminal application (FIG. 3, items S43; C/L 6/50-55, “… In step S43, under the condition that the mobile phone PAY supports the issuing authority, the mobile phone PAY organizes the network link, calls a tag payment HS, and sends the NFC tag payment request information, wherein the NFC tag payment request information comprises the NFC tag content and the tag ID …”; FIG. 3, items S48, S49;C/L 7/10-16, “… In step S48, the NFC tag payment platform returns an NFC tag parsing reply to the tag payment HS. In step S49, the tag payment HS displays a payment interface according to the parsing reply, and the payment amount is entered … the user does not need to enter an amount under the condition that it is a merchant with fixed amount …”).
Regarding claim 3, Lu, Herwig, and Lin disclose the limitations of claims 1-2. Lu further discloses the method according to claim 2, wherein the tag information comprises request identification information used to request to obtain payment page information, and the displaying the payment page based on the terminal application comprises:
generating, by the terminal application (C/L 4/51-5/5, “… a payment processing performed based on the NFC tag fabricated above is illustrated … the mobile phone PAY wallet reading the NFC tag is taken as an example, but of course other data processing systems capable of performing data processing on the NFC tag may be used apart from the mobile phone PAY wallet. The payment process based on the NFC tag is mainly as follows: the mobile phone PAY wallet touches the NFC tag, reads the tag ID, sends an NFC tag payment request to the NFC tag payment platform; the NFC tag payment platform sends an NFC tag parsing request to the merchant service platform after receiving the NFC tag payment request; the merchant service platform parses the tag and returns the analysis information to the NFC tag payment platform; the information again returns to the mobile phone PAY wallet, the mobile phone PAY wallet generates an order generation request based on the returned information and sends the request to the NFC tag payment platform, the NFC tag payment platform returns the generated order generation reply, and the mobile phone PAY wallet completes the payment …”), a payment page information obtaining request based on the request identification information (FIG. 3, items S42, S43; C/L 6/41-55, “… In step S42, since tag content such as merchant information has already been saved in the tag, the mobile phone PAY wallet can directly read the content in the tag and display the content directly in the mobile phone PAY according to a preset display format, and the process may not require networking; or the mobile phone PAY reads the content and parameters in the tag, and composes a webpage link accord-ing to a preset format, and calls the content in the NFC tag payment platform. In step S43, under the condition that the mobile phone PAY supports the issuing authority, the mobile phone PAY organizes the network link, calls a tag payment HS, and sends the NFC tag payment request information, wherein the NFC tag payment request information comprises the NFC tag content and the tag ID …”);
sending the payment page obtaining request to the server (FIG. 3, item S44; C/L 6/56-59, “… In step S44, after the tag payment HS receives the request, an NFC tag parsing request is sent to the NFC tag payment platform, the request comprising the tag content and the tag ID …”);
obtaining payment page information that is generated by the server based on the payment page obtaining request and that comprises the user information of the first transaction party (FIG. 3, items S47, S48; C/L 7/1-11, “… In step S47, the merchant service platform parses the NFC tag data, and verifies the validity of the tag, wherein the verification of validity comprises: judging whether the parsed merchant information is consistent with the merchant information saved at the backend or not. When the tag is verified to be valid, an NFC tag parsing reply is returned to the NFC tag payment platform, wherein the NFC tag parsing reply comprises the parsed tag content, the tag ID and the merchants' receipt account. In step S48, the NFC tag payment platform returns an NFC tag parsing reply to the tag payment HS …”); and
displaying, based on the payment page information, the payment page comprising the user information of the first transaction party (FIG. 3, item S49; C/L 7/12-16, “… In step S49, the tag payment HS displays a payment interface according to the parsing reply, and the payment amount is entered … the user does not need to enter an amount under the condition that it is a merchant with fixed amount …”).
Regarding claim 4, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu further discloses the method according to claim 1, wherein the tag information comprises user identification information of the first transaction party, and the method further comprises:
determining, based on the user identification information, whether the first transaction party has transaction permission, to obtain a determining result (FIG. 2, items S21, S22, S23, S41, S42, S43; C/L 5/10-14, “… As shown in FIG. 2, in step S21, the mobile phone PAY wallet touches the NFC tag. In step S22, the mobile phone PAY wallet reads the NFC tag content and the tag ID and is able to identify the issuing authority of the NFC tag based on the tag content …”; FIG. 2, item S23; C/L 5/21-37, “… since in the NFC tag, tag content such as merchant information has been saved, the mobile phone PAY can directly read the content in the tag directly and display the content directly in the mobile phone PAY according to a preset display format, and the process may not require networking; or the mobile phone PAY reads the content and parameters in the tag, and composes a webpage link according to a preset format, and calls the content in the NFC tag payment platform. In step S23, under the condition that the mobile phone PAY supports the issuing authority, the mobile phone PAY organizes the network link, calls a tag payment HS page (HS: HTML5, Hyper Text Markup Language 5), and sends the NFC tag payment request information, wherein the NFC tag payment request information comprises the NFC tag content and the tag ID …”; FIG. 3, items S41, S42, S43; C/L 6/37-55, “… As shown in FIG. 3, in step S41, the mobile phone PAY wallet touches the NFC tag. In step S42, the NFC tag content and the tag ID are read and the issuing authority of the NFC tag is identified. In step S42, since tag content such as merchant information has already been saved in the tag, the mobile phone PAY wallet can directly read the content in the tag and display the content directly in the mobile phone PAY according to a preset display format, and the process may not require networking; or the mobile phone PAY reads the content and parameters in the tag, and composes a webpage link accord-ing to a preset format, and calls the content in the NFC tag payment platform. In step S43, under the condition that the mobile phone PAY supports the issuing authority, the mobile phone PAY organizes the network link, calls a tag payment HS, and sends the NFC tag payment request information, wherein the NFC tag payment request information comprises the NFC tag content and the tag ID …”); and
the displaying a payment page comprising user information of a first transaction party comprises: in response to determining that the first transaction party has the transaction permission, displaying the payment page comprising the user information of the first transaction party (FIG. 2, items S25, S26, S27, S28; C/L 5/37-49, “… Here, there exist two cases for the display of the HS page: (1) Under the condition of an environment with a better network, after the tag content is read by the mobile phone, forming a webpage link according to a certain format, accessing the NFC tag payment platform, pushing the HS page and the merchant data saved at the backend by the platform, and displaying the content on the HS page; (2) Under the condition of an environment with a poor network, the HS page is generated directly by the mobile phone and the content is read from the tag and displayed on the HS page …”; C/L 5/56-6/8, “… In step S25, the NFC tag payment platform again sends an NFC tag parsing request to the merchant service platform, the request comprising the tag content and the tag ID. In step S26, after the merchant service platform receives the NFC tag parsing request, it parses the NFC tag content, verifies the validity of the tag, judges whether the parsed merchant information is consistent with the merchant infor-mation saved at the backend or not, and an NFC tag parsing reply is returned to the NFC tag payment platform when verified to be consistent. The NFC tag parsing reply comprises the parsed tag content, whether the tag ID is consistent and the merchants' receipt account. In step S27, the NFC tag payment platform receives the NFC tag parsing reply and returns the reply to the mobile phone PAY wallet. In step S28, the mobile phone PAY wallet displays a payment interface according to the NFC tag parsing reply, and the user enters the payment amount … under the condition that it is a merchant with fixed amount, the user does not need to enter an amount …”).
Regarding claim 5, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu further discloses the method according to claim 1, wherein the NFC tag is located in a carrier comprising a payment code of the first transaction party (FIG. 4, items 120, 130, 140; C/L 7/44-62, “… a tag reading module 110 for reading an NFC tag, wherein the NFC tag contains tag content and a tag ID; a payment request generation module 120 for generating and sending an NFC tag payment request based on the tag content and the tag ID, wherein the NFC tag payment request is for obtaining first account information by being parsed; an order generation request module 130 for receiving the first account information obtained by parsing the NFC tag payment request and generating an order generation request in combination with current transaction information, wherein the order generation request is for causing an order to be generated based on the first account information and the current transaction information; and a payment module 140 for receiving the generated order, calling second account information, and performing pay-ment based on the order …”), or is located in a carrier that does not comprise a payment code of the first transaction party.
Regarding claim 10, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu further discloses the method according to claim 1, wherein the payment page comprises at least one of a control used to confirm payment information (FIG. 2, items S25, S26; C/L 5/56-67, “… In step S25, the NFC tag payment platform again sends an NFC tag parsing request to the merchant service platform, the request comprising the tag content and the tag ID. In step S26, after the merchant service platform receives the NFC tag parsing request, it parses the NFC tag content, verifies the validity of the tag, judges whether the parsed merchant information is consistent with the merchant information saved at the backend or not, and an NFC tag parsing reply is returned to the NFC tag payment platform when verified to be consistent. The NFC tag parsing reply comprises the parsed tag content, whether the tag ID is consistent and the merchants' receipt account …”), an area used to fill in or select a payment amount (FIG. 2, item S28; C/L 6/4-8, “... In step S28, the mobile phone PAY wallet displays a 5 payment interface according to the NFC tag parsing reply, and the user enters the payment amount … under the condition that it is a merchant with fixed amount, the user does not need to enter an amount …”), or an area used to fill in or select a payment manner.
Claim7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al (U. S. Patent No. 11562344 B2), herein referred to as Lu, in view of Herwig et al (U. S. Patent No. 8494908 B2), herein referred to as Herwig, in view of Lin et al (U. S. Patent No. 10853436 B2), herein referred to as Lin, and in further view of Ding et al (U. S. Patent No. 11410156 B2), herein referred to as Ding.
Regarding claim 7, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu, Herwig, and Lin do not specifically disclose, however, Ding discloses the method according to claim 1, 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 (C/L 1/60-67, “…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 ...”; C/L 2/36-43, “…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 ...”):
determining, in response to the first triggering information, the terminal application with the payment function in the mobile terminal (C/L 1/63-65, “… 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; and displaying the application selection page (C/L 2/20-25, “…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 ...”).
Ding discloses an NFC payment method and terminal. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an NFC payment method and terminal, as in Ding; to include information display method and device, as in Lin; and to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to resolve a prior art problem that operations are troublesome when a third-party payment application is used to make payment by providing an NFC payment method and terminal that reduces user operations and increases the speed for making payment by using the third-party payment application.
Regarding claim 8, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu, Herwig, Lin, and Ding disclose the limitations of claim 7. Lu, Herwig, and Lin do not specifically disclose, however, Ding discloses the method according to claim 7, wherein after the displaying the application selection page, the method further comprises:
obtaining a target terminal application selected by the second transaction party from the application selection page (FIG. 10a, items 902, 903; C/L 23/26-45, “… 902. The first terminal receives an application selection instruction sent by the second terminal. The application selection instruction carries an AID of the target third-party payment application … that the AID of the target third-party payment application is registered by the target third-party payment application from a system when the target third-party payment application is being installed in the first terminal, and may need to be applied for from a specific institution by a developer of the application in advance, so as to specially identify this type of application. 903. The first terminal determines, based on the AID of the target third-party payment application, an HCE service corresponding to the target third-party payment application … the first terminal stores a correspondence between the AID of the target third-party payment application and a service type; and the first terminal determines, based on the prestored correspondence, the I-ICE service corresponding to the AID of the target third-party payment application ...”); and
the displaying, based on the payment link information, the payment page comprising user information of a first transaction party comprises:
accessing the payment link information by using the target terminal application; and displaying, in the target terminal application, the payment page comprising the user information of the first transaction party (C/L 2/44-47, “… when the displaying, by a first terminal, at least one third-party payment application, the method further includes: displaying, by the first terminal, a card application supporting NFC payment...”; C/L 6/19-31, “… displaying, by a first terminal, a first screen, where the first screen displays an icon of at least one third-party payment application; receiving, by the first terminal, a selection operation of a user for selecting an icon of a target third-party payment application on the first screen; and in response to the selection operation, interacting, by the first terminal, with a second terminal by using the target third-party payment application, to complete NFC payment … the displaying, by a first terminal, a first screen includes: when the first terminal is in a screen locked state, receiving, by the first terminal, a quick operation entered by the user; and displaying, by the first terminal, the first screen in response to the quick operation …”; C/L 6/39-48, “… before the interacting, by the first terminal, with a second terminal to complete NFC payment, the method further includes: displaying, by the first terminal, a second screen in response to the selection operation, where the second screen displays first prompt information, and the first prompt information is used to prompt the user to perform identity authentication; and correspondingly, in response to an operation of successful user identity authen-tication, interacting, by the first terminal, with the second terminal to complete NFC payment …”).
Ding discloses an NFC payment method and terminal. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an NFC payment method and terminal, as in Ding; to include information display method and device, as in Lin; and to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to resolve a prior art problem that operations are troublesome when a third-party payment application is used to make payment by providing an NFC payment method and terminal that reduces user operations and increases the speed for making payment by using the third-party payment application.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Lu et al (U. S. Patent No. 11562344 B2), herein referred to as Lu, in view of Herwig et al (U. S. Patent No. 8494908 B2), herein referred to as Herwig, in view of Lin et al (U. S. Patent No. 10853436 B2), herein referred to as Lin, and in further view of Prakash et al (U. S. Patent No. 11030514 B2), herein referred to as Prakash.
Regarding claim 9, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu, Herwig, and Lin do not specifically disclose, however, Prakash discloses the method according to claim 1, wherein before the obtaining tag information in the NFC tag in response to the electromagnetic signal, the method comprises:
determining that the mobile terminal has not started a code scanning application used to scan a payment code image (FIG. 4, items 402; C/L 9/19-24, “… FIG. 4 illustrates a specific method embodiment of the method more generally described in FIG. 2. It would be understood that the method of FIG. 4 is intended to be implemented through a user device (i) having both near-field-communication capability and optical code scanning capability, and …”; C/L 9/28-46, “… Step 402 includes receiving, at a user device having both near-field-communication capability and optical code scan-ning capability, a user input or user action identifying a mode of information acquisition, wherein the identified mode of information acquisition is one of a near field communication mode and an optical code scanning mode … a user input for identifying the mode of information acquisition may be received through a user interface corresponding to the user device … identification of the mode of information acquisition may be based on a user action. For example a user action of tapping the user device on the dual protocol display label, on the NFC tag within the dual protocol display label or an NFC tag region demarcated on the dual protocol display label may result in identification of the near field communication mode (which identification may in an embodiment, be based on the user device detecting the presence of an NFC tag within the dual protocol display label …”); and
the obtaining tag information in the NFC tag in response to the electromagnetic signal (FIG. 4, items 404, 406, 408; C/L 6/37-39, “… "Active RFID tag" shall mean an internally powered RFID tag that periodically or continuously broadcasts a data signal, bearing information encoded within the RFID tag …”; C/L 6/54-56, “… "NFC tag" shall mean an active RFID tag or a passive RFID tag configured to broadcast information based on the near-field-communication protocol …”; C/L 9/51-62, “… Step 404 includes initiating information acquisition from a dual protocol display label through the user device oper-ating in one of the near-field-communication mode and the optical code scanning mode, wherein the implemented mode of information acquisition is selected based on the mode of information acquisition identified at step 402. Step 406 thereafter includes extracting merchant infor-mation (including merchant payment account information) from the information acquired at step 404. Step 408 includes initiating transfer of a transaction amount from a user payment account to a merchant account, using the extracted merchant information …”) comprises:
obtaining the tag information in the NFC tag in response to the electromagnetic signal in response to determining that the mobile terminal has not started the code scanning application used to scan the payment code image (FIG. 1, item 102; C/L 7/61-8/10, “…NFC tag 102 may be configured to broadcast a data signal including encoded (i) merchant payment account information, (ii) merchant infor-mation, and/or (iii) any other information that may be necessary or relevant to effect an electronic payment transaction from a customer payment account to a merchant payment account … the data signal broadcast by NFC tag 102 may addi-tionally include descriptive information or a data field identifying the display label 100 as a dual protocol display label which simultaneously includes at least one other mechanism for communicating the information encoded within the data signal broadcast by NFC tag 102 … NFC tag 102 may additionally be configured to broadcast encoded information that specifies that said other mechanism for communicating the information being broadcast by the NFC tag, is an optical code ...”; C/L 8/28-38, “… in the event merchant information is being acquired from the NFC tag, said information is obtained by receiving one or more data signals from the NFC tag and processing said one or more data signals to decode the information encoded within said data signals. The obtained merchant information may in certain embodiments include all information necessary to effect an electronic payment to a merchant payment account, and may at the very least include acquirer bank information and an account identifier identifying the merchant's payment account with said acquirer bank …”).
Prakash discloses methods, systems and computer program products for contactless payments. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include methods, systems and computer program products for contactless payments, as in Prakash; to include information display method and device, as in Lin; and to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a dual protocol display label for implementing electronic payment transactions from a single contactless payment card, including optical scan and near-field communication capabilities. This solution addresses problems in enabling a payer to conveniently acquire merchant payment account information despite any problems in reading an optical code on a display label.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Lu et al (U. S. Patent No. 11562344 B2), herein referred to as Lu, in view of Herwig et al (U. S. Patent No. 8494908 B2), herein referred to as Herwig, in view of Lin et al (U. S. Patent No. 10853436 B2), herein referred to as Lin, and in further view of Hirasawa (U. S. Patent Application Publication No. 20190102771 A1), herein referred to as Hirasawa.
Regarding claim 11, Lu, Herwig, and Lin disclose the limitations of claim 1. Lu, Herwig, and Lin do not specifically disclose, however, Hirasawa discloses the method according to claim 1, wherein the method further comprises:
determining that the terminal application does not exist in the mobile terminal (FIG. 5, para 14, “…if a mobile terminal that has not installed the payment application reads the information code displayed on the display unit, the address information of the download site of the payment application is acquired. Therefore, the purchaser is not only prompted to download the payment application, but also can readily download the payment application …”); and
in response to determining that the terminal application does not exist in the mobile terminal, generating prompt information indicating that payment cannot be performed, or
prompting a user to download and install the terminal application (FIG. 5, para 14, “…if a mobile terminal that has not installed the payment application reads the information code displayed on the display unit, the address information of the download site of the payment application is acquired. Therefore, the purchaser is not only prompted to download the payment application, but also can readily download the payment application …”; para 43, “…as shown in FIG. 5, the screen displays, together with the application payment code C1, the information indicating the necessity of reading the application payment code C1 to carry out application pay-ment, and the information prompting the purchaser to down-load the payment application if not yet installed in the mobile terminal. It should be noted that the computer can correspond to an example of the display unit on which the application payment code C1 is displayed …”; para 56, “…if the application payment code C1 displayed on the computer is read by a mobile terminal or the like that has not installed the payment application, the address information of the download site of the payment application is acquired. Therefore, the purchaser can be prompted to download the payment application, and can easily download the payment application …”).
Hirasawa discloses a payment system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a payment system and method, as in Hirasawa; to include information display method and device, as in Lin; and to include a retail checkout system and method, as in Herwig, to improve and/or enhance the technology for a data processing method based on NFC label, system, and server, as in Lu, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment system and method preventing the purchaser, when purchasing a product and/or service, from selecting a payment method, which is not available to the purchaser at the time of receiving the product and/or service. Thus, if a mobile terminal that has not installed the payment application reads the information code displayed on the display unit, the address information of the download site of the payment application is acquired. Therefore, the purchaser is not only prompted to download the payment application, but also can readily download the payment application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zhao et al (U. S. Patent No. 11023881 B2) – Near Field Communication NFC-Based Transaction Method And Device
Zhao discloses electronic hardware, and in particular, a handheld terminal that performs a transaction based on NFC. A first terminal and a second terminal each support multiple transaction manners, negotiate a to-be-used transaction manner by using an NFC connection, and automatically invoke a payment client to initiate a transaction request to a transaction server. The first terminal and the second terminal further sort and screen the multiple trans-action manners before negotiation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, 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, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights