DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Aug. 7, 2025, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on Aug. 7, 2025 (x2) and Jan. 22, 2026, were filed before the mailing of a first office action on the merits and therefore, are in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDSs have been considered.
Claim Status
The status of claims is as follows:
Claims 1–13 are pending and examined with Claims 1, 12, and 13 in independent form.
This is a first action on the merits.
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 2–9 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 2–8: Claim 1 introduces a singular “user who uses a payment service” and ties that user only to the “first user terminal.” Claim 1 does not recite any user of the second user terminal and only recites that the second user terminal is “different from the first user terminal.” Dependent Claim 2 recites “acquire second user information relating to the user who has logged in to the payment service from the second user terminal,” where “the user” applied to the second terminal being indefinite for antecedent basis. The definite article “the user” purports to refer back to “a user” introduced in Claim 1, however, Claim 1 only associates “a user” with the first user terminal and is silent on who logs in from, operates, or is otherwise associated with the second user terminal. Thus, it cannot be determined with reasonably certainty whether “the user who has logged in to the payment service from the second user terminal” is (1) the same “user who uses a payment service” recited in Claim 1 (a fact that is not established by the claims) or (2) some other user who has logged in to the second user terminal. This ambiguity is not resolved by, and in fact exacerbated by, the specification, which teaches the user associated with the second terminal may be either the user of Claim 1 or an impersonator. Spec. ¶ 35 (“when a malicious third party impersonates the user, a terminal of the malicious third party may correspond to the second user terminal 30B.”); ¶ 69 (“When a malicious third party performs a login, the first user terminal 30A belongs to the valid user, but the second user terminal 30B belongs to the malicious third party.”). Thus, it is unclear with when read in light of the specification whether “the user who has logged in to the payment service from the second user terminal” refers to the “valid user” or a “malicious third-party user.” Dependent Claim 3–8 recite “the user” and are rejected for the same reasoning. For examination purposes, the “user” associated with the second user terminal is the same user who uses the payment service via the first user terminal.
Claim 9: Claim 9 depends from Claim 1. Claim 1 recites “read information from the code for payment” read by a “second user terminal.” Claim 9 recites two separate reading events attributed to two different devices: (1) when the code for payment is read by the shop terminal; and (2) when the code for payment is read by the second user terminal. The “read information” associated with the shop terminal lacks antecedent basis because the only antecedent for “read information” provided in Claim 1 is information read by the second user terminal.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–13 are directed to a statutory category. Claims 1–11 recite a “system” and are therefore, directed to the statutory category of a “machine.” Claim 12 recites a “method” and is therefore, directed to the statutory category of a “process.” Claim 13 recites a “non-transitory information storage medium having stored thereon a program” and is therefore, directed to the statutory category of an "article of manufacture.”
Representative Claim
Claim 1 is representative [“Rep. Claim 1”] of the subject matter under examination. Normal font is used for limitations that recite the judicial exception. Bold font is used to indicate additional elements evaluated under Step 2A, Prong Two (practical application) and Step 2B (significantly more). Italics font is used where necessary to identify intended use limitations and underline font is used, as needed, in further describing the judicial exception. Each limitation is identified by a letter designator for use as a shorthand notation when analyzing/referencing each limitation. Rep. Claim 1 recites:
[A] 1. An authentication system, comprising at least one processor configured to:
[B] … when a code for payment displayed on a first user terminal of a user who uses a payment service is read by a second user terminal different from the first user terminal, …
[C] acquire … read information read from the code for payment;
and
[D] execute, when the read information is acquired, a code-for-payment authentication using the code for payment.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 1 recites “execute, when the read information is acquired, a code-for-payment authentication using the code for payment” in Limitation D, which recites commercial or legal interactions under the organizing human activity exception because “execute … a code-for-payment authentication using the code for payment, recites “sales activities or behaviors, and business relations” between two or more parties. MPEP § 2106.04(a)(2)(II)(B).
Step 2A, Prong Two: The additional elements identified in Rep. Claim 1, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d).
The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: An authentication system, comprising at least one processor; and when a code for payment displayed on a first user terminal … is read by a second user terminal different from the first user terminal.
The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a).
A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the specification identifies asserted advantages of the claimed system as improved user convenience (Spec. ¶ 5), improved security (Spec. ¶ 109), and as reducing the time and effort required of the user by requiring only a single authentication (Spec. ¶¶ 83, 84). None of these asserted advantages is a specific improvement to the functioning of a computer, server, terminal, camera, or network. The specification describes each component only at a generic, functional level land teaches that processing “may be the same as processing for a publicly-known payment service” (Spec. ¶ 90) and a “publicly-known flow” (Spec. ¶¶ 43, 45). The specification does not describe any specific technical improvement to code-reading, image analysis, network communication protocols, encryption, or databases. Instead, the specification teaches that the components’ functions “may be the same as” those of a generic server or terminal. Spec. ¶¶ 33–35. Rep. Claim 1 is not directed to a new code-for-payment structure/format or to an improved method of generating, displaying, or reading the code but merely to reading a code for payment and executing an authentication using it. The specification teaches the code C30 for payment is a conventional “barcode or the two-dimensional code.” Spec. ¶ 44. As the Federal Circuit held on similar facts, claims reciting the use of a machine-readable code to communicate and verify information are directed to an abstract idea where they “are not directed to a new barcode format, an improved method of generating or scanning barcodes, or similar improvements in computer functionality.” Secured Mail Sols. LLC v. Universal Wilde, Inc., 873 F.3d 905, 910 (Fed. Cir. 2017). Here, as in Secured Mail, “rather than citing a specific way to solve a specific problem as in DDR, the asserted claims cite well known and conventional ways to allow generic communication between a sender and recipient using generic computer technology.” Id. at 912. The specification’s own description of the components confirms that the hardware employed is conventional. Spec. ¶¶ 33–35. Accordingly, the computer is not being improved and is merely used as a tool to implement the abstract idea.
“Improving security can be a non-abstract computer-functionality improvement if done by a specific technique that departs from earlier approaches to solve a specific computer problem.” CosmoKey Solutions GmbH & Co. KG v. Duo Security LLC, 15 F.4th 1091, 1097, 1101 (Fed. Cir. 2021). However, the security improvement recited in the specification is not recited in Rep. Claim 1. E.g., Spec. ¶ 54 (authentication switching “enhancing security”); ¶¶ 109, 110 (using the first or second authentication based on telephone number changes to “improve security”); ¶ 35 (malicious third party impersonates the user from a second terminal); MPEP § 2106.05(a) (claim must recite the improvement with sufficient specificity to reflect how the improvement is achieved rather than claiming the desired outcome.).
The additional elements do not apply the abstract idea with a particular machine.
Although the claims recite specific hardware components (i.e., processor and first and second terminals), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. ¶¶ 30–37. A machine is “particular” only when it imposes a meaningful limit on the claims scope. MPEP § 2106.05(b). Here, any general-purpose server and any general-purpose smartphone, tablet, or personal computer, or wearable terminal would satisfy the claim’s hardware requirements, which confirms that the hardware components are generic rather than “particular.” Spec. ¶¶ 31, 34; MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language (Spec. ¶¶ 31, 34), without restricting the claimed hardware to any particular design, configuration, or architecture.
The additional elements are mere instructions to apply the abstract idea exception, MPEP § 2106.05(f); (2) generally link the judicial exception to a particular technological environment, MPEP § 2106.05(h); and/or (3) are insignificant extra solution activity; MPEP § 2106.05(g).
Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language and instead describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. The specification failure to describe these components in any detail beyond exemplary language is itself an admission that the components are so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). See, Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Myers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶¶ 31, 34.
The generic processor, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. ¶ 101. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea.
Limitation A describes the processor “configured to” to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, displaying and sending data, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations B–D describe the processor performing the steps of the claimed invention, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively, the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3).
Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 1 is directed to an abstract idea.
Independent Claims 12 and 13 are not substantially different than Rep. Claim 1, recite the same abstract idea as Rep. Claim 1, and contain no additional elements not otherwise analyzed for Rep. Claim 1. Therefore, Independent Claims 12 and 13 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 1 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05. The additional elements (i.e., An authentication system, comprising at least one processor; and when a code for payment displayed on a first user terminal … is read by a second user terminal different from the first user terminal), are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure1. Further, Applicant’s Specification discloses that these components are implemented as, or may e the same as generic and publicly-known computing equipment and that the units and modules may be combined into a single device or distributed. Spec. ¶¶ 30–38, 55.
(1) An authentication system, comprising at least one processor is WRC in the financial technology field. Spec. ¶¶ 30, 31.
(2) a code for payment displayed on a first user terminal … is read by a second user terminal different from the first user terminal is WRC. Spec. ¶¶ 34–36, 44.
The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and that the system units and nodules may be combined or distributed among devices. See, e.g., Spec. ¶¶ 31, 55, 101.
The combination is also WRC at the high level of generality recited:
The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(2). Here, the combination performs each step in exactly the manner described as conventional throughout Applicant’s own Specification. There is no indication that the combination of these elements operates in an unconventional manner or produces a result that is other than what would be expected from the generic application of these individual components.
Unlike BASCOM, where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 1 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. At the high level of generality recited, the combination is WRC. Any BASCOM argument fails because nothing in Applicant’s Specification describes a non-conventional ordered arrangement of components that is then recited in the claims. Here, the only feature the specification teaches is “novel” (i.e., switching the authentication based on “change necessity/unnecessity information” is described but is not recited in Rep. Claim 1. Spec. ¶ 84.
Rep. Claim 1 recites only abstract steps without incorporating any specific technical details for how these elements are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, the claim cannot be an improvement to the computer or another technology. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d).
Accordingly, the additional elements of Rep. Claim 1 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Reevaluated under Step 2B, the recitation that the code for payment is “read by a second user terminal” (Limitation B) is found to be no more than WRC data-gathering activity in the field of electronic payment authentication. As discussed above, Limitation B, merely recites acquiring read information from a code for payment that is read by a second user terminal. Applicant’s Specification describes the reading of the code by a generic camera (Spec. ¶ 36) of a conventional smartphone, tablet, personal computer, or wearable terminal, (Spec. ¶ 34) and teaches the code itself as a conventional barcode or two-dimensional code (Spec. ¶ 44), in the context of an ordinary computer system (Spec. ¶ 34). For example, the Specification explains that the associated payment and authentication processing “may be the same as” that of a “publicly-known payment service” and be a “publicly-known flow.” Spec. ¶ 84. Moreover, neither the Specification nor the record identifies Limitation B as providing any improvement to the functioning of the computer itself, to the underlying network or storage technology; nor has Applicant provided any evidence that such operations were not well-understood, routine, and conventional in the field at the time of the invention. Spec. ¶¶ 31, 33–37. In view of this disclosure and the absence of contrary evidence, and consistent with MPEP § 2106.05(d) and USPTO guidance interpreting Berkheimer, these limitations are found to be well-understood, routine, and conventional extra-solution activity in the field of electronic payment authentication.
Independent Claim 13 is a medium claim whose instructions cause a system to perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claim 12 is a method claim reciting steps that perform the same abstract processing and generic computer operations recited in Rep. Claim 1. Independent Claims 12 and 13 add no additional elements beyond those of Rep. Claim 1 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 12 and 13 also do not recite an inventive concept under Step 2B.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons:
Dependent Claims 2 and 3 recite additional data-gathering steps within the same commercial authentication workflow, which merely further limits the abstract idea of the independent claim. The specification describes these elements at a high level as modules that acquire user IDs, login account, telephone numbers, terminal IDs, or other payment related data from existing databases and then compares them during “code-for-payment authentication.” Spec. ¶¶ 166–173. This is conventional information collection and comparison using generic servers and user devices over a network—not an improvement in computer technology or any other technical field.
Dependent Claims 4, 5, 6, 7 recite authentication conditions relating to the code for payment authentication and display of “authentication content” under certain conditions, which is extra-solution activity and field of use limitations within the commercial authentication workflow and does not improve how computers operate. The specification teaches these elements are conventional modules that acquire specific user information from a database and determine whether that information satisfies preset business rules for allowing or restricting authentication. Spec. ¶¶ 55–68. This is not more than evaluating and applying business rules and displaying appropriate information.
Dependent Claim 8 specifies more business logic and narrows the abstract idea of the independent claim. The specification teaches users have a choice to permit telephone number authentication and then route them into different authentication workflows based on that choice. Spec. ¶¶ 41–44. This is conventional user choice information flows using generic servers and user devices over a network—not an improvement in computer technology or any other technical field.
Dependent Claim 9 and 10 recite transmitting and reading payment information under certain conditions and applies “setting information” from one terminal to another (transmitting and storing), which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Using different endpoints and APIs to route data, and copying or applying stored configuration information from one device to another is a conventional client-server function and does not improve the functioning of a computer or network. There is no unconventional arrangement as the elements merely invoke the authentication abstract idea in a standard payment service client server environment.
Dependent Claim 11 recites additional business logic for managing the code (invalidating the code) under certain conditions/operations (e.g., payment completion, cancellation, expiration). The specification teaches that code IDs and associated payment codes have expiration dates and are marked valid or invalid based on issuance, use, and timing with those states stored and updated in conventional databases on servers. Spec. ¶¶ 58–63. Updating a record to mark a code as invalid upon a predetermined “operation” is routine data maintenance in payment services (transmitting, receiving, storing) performed by generic servers, clients, and databases, without any improvement to the functioning of a computer, server, or the network.
Conclusion
Claims 1–13 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 1 otherwise styled as another statutory category is subject to the same analysis.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1–5 and 11–13 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada (U.S. Pat. Pub. No. 2020/0342440) [“Yamada”] in view of Fukushima (U.S. Pat. Pub. No. 2022/0318884) [“Fukushima”].
Regarding Claim 1, Yamada discloses:
An authentication system, comprising at least one processor configured to:
(See at least ¶ 63, “the control unit 11 includes various processing units such as a reading processing unit 111, an authentication information acquiring unit 116, an authentication information transmitting unit 112, an authentication result acquiring unit 113.” “The control unit 11 includes control equipment such as a CPU … CPU is a processor for executing various types of calculation processes.” ¶ 62.)
acquire, when a code for payment displayed on a first user terminal of a user who uses a payment service is read by a second user terminal different from the first user terminal,
(See at least Fig 3 disclosing a QR code C1 displayed on a first terminal of a user who uses a payment service. “[T]he QR code payment process is started when the user activates the payment application and performs the log-in operation to buy a product at the shop.” ¶ 86. “buying a product at a shop, the user activates (logs in) the payment application, acquires an information code (hereinafter referred to as a "QR code") issued from the payment site, and causes the shop terminal 1 to read the QR code.” ¶ 35. “The reading processing unit 111 is configured to cause the camera 25 to capture an image of the QR code image (see FIG. 3) displayed on the operation/display unit 23 of the user terminal 2, and read the QR code Cl from the captured digital image data.” ¶ 64. “It is noted that the first terminal, the information processing apparatus, and the second terminal are included in the scope of the present invention regardless of whether they are user terminals or shop terminals.” ¶ 31. Thus, a first user terminal and second user terminal may display and read, respectively, the QR code.)
read information read from the code for payment; and
(See at least ¶ 64, “The reading processing unit 111 is configured to cause the camera 25 to capture an image of the QR code image (see FIG. 3) displayed on the operation/display unit 23 of the user terminal 2, and read the QR code Cl from the captured digital image data. The authentication information acquiring unit 116 acquires information (user ID) (authentication information) included in the read QR code C1.”)
execute, when the read information is acquired, a code-for-payment authentication using the code for payment.
(See at least ¶ 35, “Each of the payment apparatuses 3A, 3B, and 3C executes an authentication process to authenticate the user based on the user ID.” “[T]he authentication processing unit 313 determines whether or not the user ID included in the QR code Cl transmitted to the user terminal 2, namely, the user ID of the user to whom the QR code Cl has been issued (see FIG. 6) matches the user ID acquired from the shop terminal 1. The authentication processing unit 313 determines the authentication as a success when the user IDs match each other, and determines the authentication as an authentication error when the user IDs do not match.” ¶ 81.
Yamada discloses all the limitations of Claim 1. In the alternative, to the extent Applicant contends Yamada’s code is used only for authentication and is not a “code for payment” as claimed, Fukushima discloses
code for payment
(See at least ¶ 43, “A code C40 for electronic payment is displayed on the home screen G4. The code C40 includes an ID that can identify the user in the first service.” “The user can execute electronic payment through use of the code C40.” ¶ 45.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the code displayed and read in Yamada’s authentication system as a “code for payment,” as taught by Fukushima, in the same field of invention, with the motivation to “enhance convenience of electronic payment to be executed when a user visits a predetermined place to use a series of services.” Fukushima, ¶ 5; Yamada, ¶ 6.
Regarding Claim 2, Yamada and Fukushima disclose:
The authentication system according to claim 1 and the at least one processor is configured to;
Yamada further discloses:
wherein the at least one processor is configured to: acquire second user information [user ID] relating to the user who has logged in to the payment service from the second user terminal, and
(See at least ¶ 64, “The reading processing unit 111 is configured to cause the camera 25 to capture an image of the QR code image (see FIG. 3) displayed on the operation/display unit 23 of the user terminal 2, and read the QR code Cl from the captured digital image data. The authentication information acquiring unit 116 acquires information (user ID) (authentication information) included in the read QR code Cl. The
authentication information is information corresponding to the user terminal 2, and in the present example, the authentication information includes identification information (user ID) of the user of the user terminal 2.”
execute, when the read information is acquired, the code-for-payment authentication based on first user information relating to the user who has logged in to the payment service from the first user terminal and the second user information.
(See at least ¶ 35, “Each of the payment apparatuses 3A, 3B, and 3C executes an authentication process to authenticate the user based on the user ID” and “determines whether or not the user ID included in the QR code Cl transmitted to the user terminal 2, namely, the user ID of the user to whom the QR code Cl has been issued (see FIG. 6) matches the user ID acquired from the shop terminal 1.” ¶ 81.
Regarding Claim 3, Yamada and Fukushima disclose:
The authentication system according to claim 2 and the at least one processor is configured to;
Yamada further discloses:
wherein the at least one processor is configured to: acquire the first user information based on the read information, and execute, when the read information is acquired, the code- for-payment authentication based on the first user information and the second user information.
(See at least ¶ 64, “The authentication information acquiring unit 116 acquires information (user ID) (authentication information) included in the read QR code Cl. The authentication information is information corresponding to the user terminal 2, and in the present example, the authentication information includes identification information (user ID) of the user of the user terminal 2” and the user is authenticated by matching the user ID. ¶¶ 81; see also ¶ 66. The first user information (the user ID carried in the code displayed) is thus acquired based on the read information. ¶ 65.)
Regarding Claim 4, Yamada and Fukushima disclose:
The authentication system according to claim 1 and the at least one processor is configured to;
Yamada further discloses:
wherein the at least one processor is configured to: determine whether the user satisfies a predetermined authentication condition relating to the code-for-payment authentication [match]; and
(See at least ¶ 81, “The authentication processing unit 313 determines the authentication as a success when the user IDs match each other, and determines the authentication as an authentication error when the user IDs do not match.”)
display, when it is determined that the user satisfies the predetermined authentication condition, authentication content relating to the code-for-payment authentication on the second user terminal.
(See at least ¶ 66, “The authentication result acquiring unit 113 acquires, from each of the payment apparatuses 3A, 3B, and 3C, a result (authentication result) of the authentication process of the user that was executed based on the user ID. The authentication result is "authentication success" indicating an authentication success, or "authentication error" indicating an authentication failure.) See Fig 9 and associated text ¶¶ 134, et seq.
Regarding Claim 5, Yamada and Fukushima disclose:
The authentication system according to claim 4 and the at least one processor is configured to;
Yamada further discloses:
wherein the at least one processor is configured to determine whether the user satisfies the predetermined authentication condition by determining whether a change in user information relating to the user exists.
(See at least ¶ 81, “The authentication processing unit 313 determines the authentication as a success when the user IDs match each other, and determines the authentication as an authentication error when the user IDs do not match.” See at least ¶ 81, “The authentication processing unit 313 determines the authentication as a success when the user IDs match each other, and determines the authentication as an authentication error when the user IDs do not match.” A user ID that does not match is a change in user information.)
Regarding Claim 11, Yamada and Fukushima disclose:
The authentication system according to claim 1 and the at least one processor is configured to
Yamada further discloses:
wherein the at least one processor is configured to invalidate the code for payment [ending process] when a predetermined operation [3 minutes] for the code for payment is performed on the first user terminal.
(See at least ¶ 130, “the QR code Cl issued by a payment apparatus 3 may be what is called a one-time QR code in which an effective time for usage is set. For example, in a case where the effective time of the QR code Cl is set to three minutes, it can be used only for three minutes after the payment apparatus 3 transmits the QR code Cl to the user terminal 2, or after the QR code Cl is displayed on the user terminal 2, and the usage is restricted after an elapse of three minutes”. See also, Fig. 8. ¶ 86, “It is noted that the QR code payment process may be ended halfway in response to a predetermined operation performed by the user on the user terminal 2.” See also, Fukushima, ¶ 44. For Fukushima, the resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 11.
Regarding Claim 12, Yamada disclose:
An authentication method
(See at least Abstract, “method”)
The remaining limitations of Claim 12 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Yamada and Fukushima for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 12.
Regarding Claim 13, Yamada disclose:
A non-transitory information storage medium having stored thereon a program for causing a computer to:
(See at least Claim 11)
The remaining limitations of Claim 13 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Yamada and Fukushima for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 13.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada and Fukushima and further in view of FOR: Int. Pat. Pub. No. WO 2014/032549 A1 [“FOR Chen”]
Regarding Claim 6, Yamada and Fukushima disclose:
The authentication system according to claim 5 and the at least one processor is configured to whether a change in the user information exists;
Yamada does not disclose but FOR Chen discloses:
wherein the at least one processor is configured to whether a change in the user information exists by determining whether a change in a telephone number of the user exists.
(See at least p. 9, “the authentication determining unit is configured to determine …whether the phone number is consistent; the authentication status unit is used to determine Chane user … the user telephone number judging unit confirms whether the telephone number obtained by the identity authentication system from the telecommunication carrier matches the telephone number provided by the authentication request provider, and feeds back the information to the identity authentication system.” See also, 11 (third paragraph beginning with “The above-mentioned identity authentication system …”); p. 25 (third paragraph from bottom beginning with “The system of Claim 30, where the identity authentication system includes … “).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined whether a change in the user information exists by determining whether a change in a telephone number of the user exists, as taught by FOR Chen, to the known authentication invention of Yamada, in the same field of invention, with the motivation to improve authentication security and make the authentication process less “cumbersome and time consuming.” FOR Chen, p. 6, third paragraph.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada and Fukushima and further in view of Lee et al. (U.S. Pat. Pub. No. 2014/0136421 [“Lee”]
Regarding Claim 7, Yamada and Fukushima disclose:
The authentication system according to claim 4 and the at least one processor is configured to determine whether the user satisfies the predetermined authentication condition
Yamada does not disclose but Lee discloses:
wherein the at least one processor is configured to determine whether the user satisfies the predetermined authentication condition by determining whether the user owns the first user terminal.
(See at least ¶ 83, “when second authentication information including at least one of phone number information given to the terminal 110 and resident registration number information on the user of the terminal 110 coincides with the user information of the terminal 110, the second authentication procedure performing unit 320 determines that the second authentication information is authenticated.” “[W]hen there is information that coincides with owner information of the terminal 110 or corporate name information included in the telecommunication company member information, the member registration apparatus 130 authenticates the telecommunication company member information using the communication service providing apparatus 140.” ¶ 69.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined determine whether the user satisfies the predetermined authentication condition by determining whether the user owns the first user terminal, as taught by Lee, to the known authentication invention of Yamada, in the same field of invention, with the motivation to “enable secure electronic payment.” Lee, ¶¶ 32, 34.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada and Fukushima and further in view of Kim et al. (U.S. Pat. Pub. No. 2012/0157062 [“Kim”]
Regarding Claim 8, Yamada and Fukushima disclose:
The authentication system according to claim 1, wherein the at least one processor is configured to: acquire the read information and execute the code-for-payment authentication.
Yamada discloses acquire the read information and execute the code-for-payment authentication but not gated on when the user has not selected telephone number authentication using a telephone number registered in the payment service. Thus, Yamada does not disclose but Kim discloses:
when the user has not selected telephone number authentication using a telephone number registered in the payment service, and … when the user has not selected the telephone number authentication.
(See at least Kim, ¶ 238, “In Fig. 25, the interchange (101) is configured to present (532) a user interface to receive a user selection for a preference to skip authentication performed via mobile communications with a mobile phone (117) at a phone number (123). For example, an option can be provided via a checkbox (or another user interface element) presented in a web page displayed in a browser of the user, or via a mobile application running on the mobile phone (117).” Claim 3, “providing a user interface to allow the user to select a preference option to skip the mobile communications; and storing the preference option [(¶ 240)] selected by the user in association with the phone number after the user selects the preference option.” Claim 1, “in response to a determination to skip the mobile communications, billing a user of the phone number using a funding source associated with the phone number without the communicating with the mobile phone.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the acquire the read information and execute the code-for-payment authentication of Yamada gated to when the user has not selected telephone number authentication using a telephone number registered in the payment service of Kim, in the same field of invention, with the motivation to accelerate transaction made in mobile communications and improve user convenience thereby reducing payment friction. Kim, Abstract. ¶ 238.)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada and Fukushima and further in view of Bae (U.S. Pat. Pub. No. 2016/0203452) [“Bae”] and further in view of Kumar (U.S. Pat. Pub. No. 2016/0335630) [“Kumar”]
Regarding Claim 9, Yamada and Fukushima disclose:
The authentication system according to Claim 1, the payment service, and the second user terminal
Yamada further discloses:
wherein a shop terminal in the payment service is configured to transmit, when the code for payment is read by the shop terminal, the read information to an API for payment,
(See at least ¶ 66, “The authentication result acquiring unit 113 acquires, from each of the payment apparatuses 3A, 3B, and 3C, a result (authentication result) of the authentication process of the user that was executed based on the user ID.” ¶ 32, “The plurality of payment apparatuses 3 (3A, 3B, 3C, ...) are apparatuses (for example, management servers) managed by different payment companies.” ¶ 65, “The authentication information transmitting unit 112 transmits the authentication information to each of the payment apparatuses 3A, 3B, and 3C based on information (access information) of the payment apparatuses 3A, 3B, and 3B stored in the storage unit 12 (see FIG. 5), wherein the authentication information includes the user ID read by the reading processing unit 111 “the authentication result acquiring unit 113” is part of “shop terminal 1”. ¶ 114. Under BRI, the recited “API for payment” is met by Yamada’s disclosed interfaces. “API” is a generic term for a software interface for transmitting data.)
[…]
wherein the at least one processor is configured to acquire the read information transmitted to the API for authentication.
(See at least ¶ 80, “The authentication information acquiring unit 312 acquires, from the shop terminal 1, the authentication information that includes: the user ID acquired from the QR code Cl displayed on the user terminal 2; and the shop ID.” Under BRI, the recited “API for authentication” is met by Yamada’s disclosed interfaces. ¶¶ 46, 57, 73, 173 (“communication interface 24/14/34/44” and “units”). “API” is a generic term for a software interface for transmitting data.)
Yamada further discloses that the reading terminal may be a user terminal rather than a shop terminal. ¶ 168 (“the user terminal 2 may read the QR code Cl displayed on
the shop terminal 1, and the user terminal 2 may transmit the authentication information corresponding to the shop terminal 1 to a plurality of payment apparatuses 3. Namely, the first terminal (a terminal on which the QR code Cl is displayed) of the present invention may be the shop terminal 1, and the information processing apparatus and the second terminal (a terminal that reads the QR code Cl) may be the user terminal 2.”); ¶ 169 (“Upon reading the QR code Cl, the user terminal 2 transmits authentication information including the shop ID and the user ID to a plurality of payment apparatuses 3.”)
Yamada discloses routing to payment “apparatuses/management servers” (¶ 32) but not two distinct APIs. Yamada discloses a user terminal reading a code (¶¶ 168, 169). Yamada does not disclose that the second user terminal (different form the first user terminal on which the code for payment is displayed) reads the displayed code for payment and transmits read information on an authentication path. Thus, Yamada does not disclose but Bae discloses:
wherein the second user terminal is configured to transmit, when the code for payment is read by the second user terminal, the read information to an API for authentication different from the API for payment,
(See at least ¶ 38, “The graphical code generated by the payment server 120 may be displayed on the user terminal 131 (e.g., the PC) and the user terminal 141 (e.g., the TV). In this case, the user may recognize the graphical code using the mobile terminal 150. Specifically, the mobile terminal 150 may extract information necessary for payment by recognizing the graphical code using its camera.” ¶ 63, “a mobile terminal may recognize the graphical code displayed on the user terminal using its camera and the like. In step 680, the mobile terminal may execute a payment application.” ¶ 64, “the mobile terminal may access the payment server and may share information extracted from the graphical code with the payment server. In this case, in step 691, the payment server may verify the validity of the graphical code according to the information shared by the mobile terminal.” Thus, Bae discloses a second user terminal (131/141) on which the code for payment is displayed, that reads the displayed code and transmits read information to a server for verification/authentication of the payment, separate from the shopping/payment request path performed by the first terminal (¶¶ 63, 64).
wherein the at least one processor is configured to acquire the read information transmitted to the API for authentication.
(See at least ¶ 64, “the mobile terminal may access the payment server and may share information extracted from the graphical code with the payment server. In this case, in step 691, the payment server may verify the validity of the graphical code according to the information shared by the mobile terminal.” ¶ 68, “If a mobile terminal of a user recognizes the at least one graphical code and proceeds with a payment procedure, the processor 720 may approve the payment procedure proceeded with by the mobile terminal using the information about the at least one product corresponding to the at least one graphical code.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the second user terminal is configured to transmit, when the code for payment is read by the second user terminal, the read information to an API for authentication different from the API for payment and the at least one processor is configured to acquire the read information transmitted to the API for authentication, as taught by Bae, to the known invention of Yamada, in the same field of invention, with the motivation to “proceed[ ] with payment in a more secure way by separately having a user terminal which performs shopping and a mobile terminal which proceeds with payment.” Bae, ¶ 6.
The combination of Yamada, Fukushima, and Bae disclose all the Claim 9 limitations. However, should a reviewing court construe “API” more narrowly that its ordinary generic meaning, in the alternative, Kumar discloses this limitation.
wherein a shop terminal in the payment service is configured to transmit … the read information to an API for payment, [and] the second user terminal is configured to transmit … the read information to an API for authentication different from the API for payment,
(See at least ¶ 61, “To implement the present invention, APIs are provided to merchants to integrate with their existing sign off process with their existing transaction processing. The merchant will supply sign off option information to the API.” See also, ¶ 11 (defining API). Kumar further discloses that the payment and verification (authentication) functions are separate operations performed via APIs. See at least ¶ 92, “the credit card transaction
is processed first 801. Then, the SMS is sent to smart phone to complete the sign off process 802.” See also, Fig. 8. Fig. 7 and associated text ¶ 91, “a QR Code is shown on the screen 702 and the user is asked the user to scan it using their smart phone 703. … Once the QR code is read successfully on the smart phone 706, the app will display transaction details 707 and will ask to scan the credit card 708. Once the credit card is scanned 708, the app will ask the user to sign on the smart phone or other equivalent electronic mobile device 709. Once the user signs and taps "Done" 710, a message is displayed that the transaction is processed successfully 711. At this time, the online transaction on the computer is marked completed too 712.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine separate APIs for the payment and authentication functions, as taught by Kumar, to the known read-information routing of Yamada and Bae, in the same field of invention, with the motivation to provide a modular, integration friendly architecture that lets merchants integrate their verification steps with their existing sign off process and with their existing transaction processing (Kumar, ¶ 61) and “assist otherwise distinct applications with sharing data, which can help to integrate and enhance the functionalities of the applications.” Kumar, ¶ 11.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada and Fukushima and further in view of Bae (U.S. Pat. Pub. No. 2016/0203452) [“Bae”]
Regarding Claim 10, Yamada and Fukushima disclose:
The authentication system according to claim 1 and the at least one processor is configured
Yamada further discloses
wherein the at least one processor is configured to apply setting information relating to the payment service, which is stored in the first user terminal, to the second user terminal when the code-for-payment authentication is executed.
(See at least Fig. 6 where the payment apparatus stores the user’s payment information (“CREDIT CARD CR1”) keyed to “user ID.” ¶ 144, “The authentication processing unit 313 of the payment apparatus 3B determines whether or not the user ID of the user to whom the QR code Cl has been issued (see FIG. 6) matches the user ID included in the authentication information, and transmits the authentication result ("authentication success" or "authentication error") to the shop terminal 1. In the present example, the payment apparatus 3B has issued the QR code Cl, and thus the authentication result is "authentication success".” The processor performs this when the “code-for-payment authentication s executed. ¶¶ 64, 144. Under BRI and in view of the specification, “setting information relating to the payment service” is the user’s payment information (Fig. 6, ¶ 144); Spec. ¶¶ 92, 95. Under BRI and in view of the specification, stored in the first user terminal applied to the second user terminal is met by the server applying the same user’s stored payment information upon the user ID match, where the code carrying that user ID is displayed on Bae’s first user terminal and read by Bae’s second user terminal. Fig. 6, ¶ 144; Spec. ¶¶ 92, 95, 170, 171, 184, 185 (specification mechanism is server mediated and applied via the server resolving the code ID/user ID when the second user terminal reads the code displayed on the first user terminal).
Yamada does not disclose a first user terminal and a second user terminal as two distinct devices. Thus, Yamada does not disclose but Bae discloses:
a second user terminal (131/141) on which the code for payment is displayed, that reads the displayed code and transmits read information to a server for verification/authentication of the payment, separate from the shopping/payment request path performed by the first terminal (¶¶ 63, 64). See also Rejection of Claim 9.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 9 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES H MILLER/ Primary Examiner, Art Unit 3694
1 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights