DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a response dated December 30, 2025 in which claims 1, 6, 7, and 12 are currently pending in the application.
Priority
Application 17/354,255 was filed on June 22, 2021 and claims priority to CHINA 202010767469.3 August 3, 2020.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 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, 6, 7, and 12 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A payment verification method, comprising: generating and broadcasting, by a payment collection device, at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal,
the first wireless signal including verification information for a to-be-processed target payment transaction, the verification information including a random number generated based on a current time;
obtaining, by a payment device, the verification information from the first wireless signal after detecting the first wireless signal;
generating, by the payment device, a two-dimensional code representing payment information, by encoding payment account information and the verification information, and displaying the two-dimensional code in an interactive interface to the payment collection device;
scanning, by the payment collection device, the displayed two-dimensional code to obtain the payment information;
searching, by the payment collection device, a memory of the payment collection device for the verification information locally generated and sent to the payment device, and
performing, by the payment collection device, matching verification on the verification information included in the payment information and the verification information locally generated and sent to the payment device; and
if the matching verification succeeds, completing, by the payment collection device, a payment request by using the account information included in the payment information, wherein the method further comprises: generating and broadcasting, by the payment device, a second wireless signal that includes a verification information acquisition request;
after detecting the second wireless signal, sending, by the payment collection device, a third wireless signal that includes the verification information to the payment device; and
obtaining, by the payment device, the verification information from the third wireless signal.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “payment collection device”, “at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal”, “payment device”, “interactive interface”, “payment collection device”, “a memory”, “second wireless signal”, “third wireless signal”, to perform the steps of “obtaining”, “generating”, “scanning”, “searching”, “performing”, and “matching”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0088] The system, apparatus, module, or device described above can be implemented by using a computer chip or an entity, or can be implemented by using a product having a certain function. An example implementation device is a computer, and the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device, or any combination of these devices. [0089] The apparatuses described above are merely examples. The modules described as separate parts may or may not be physically separate. Each module may be implemented as software, or hardware, or a combination of software and hardware. Some or all of the modules can be selected based on an actual need.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “payment collection device”, “at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal”, “payment device”, “interactive interface”, “payment collection device”, “a memory”, “second wireless signal”, “third wireless signal”, to perform the steps of “obtaining”, “generating”, “scanning”, “searching”, “performing”, and “matching”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 7 and 12 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 7 recites the additional elements of “A payment collection device, comprising: a processor; and a memory storing instructions executable by the processor, wherein the processor is configured to:”.
Claim 12 recites the additional elements of “A payment device, comprising: a processor; and a memory storing instructions executable by the processor, wherein the processor is configured to:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claim 6 merely limits the abstract idea and does not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1, 6, 7, and 12 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6, 7, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao, WIPO Patent Application Publication Number 2016/061769; in view of Huang, WIPO Patent Application Publication Number 2017/206833; in view of Samuelsson, U.S. Patent Application Publication Number 2023/0065383.
As per claim 1,
Zhao explicitly teaches:
A payment verification method, comprising: generating and broadcasting, by a payment collection device, at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal,
(Zhao WO2016061769A1 at pp.17-18) ("Referring to FIG. 3 to FIG. 4, in the embodiment of the present invention, the terminal B performs the following steps as the terminal that needs to obtain the verification information. B1, terminal B enters the verification interface through the web client. B2, according to the condition, the web client can call the NFC function. It should be noted that the above conditions may be any of the following: (1) Terminal B receives the NFC function call request sent by the web client. For example, the user can trigger the web client to send an NFC function call request to the terminal B by clicking the "get verification code" button on the payment browser page. For another example, add the “acquire verification code through NFC” button on the payment browser page, or add the “NFC acquisition method” option to the “acquire verification code” button. After the user selects the verification code through NFC, the web client can be triggered. The terminal sends an NFC call function request to the terminal B. (2) Terminal B actively monitors an event. For example, the terminal B monitors the operation of the web client, and after the browser jumps to the payment page, the web client can be triggered to invoke the NFC function; For another example, when the terminal B detects that an event such as the “acquire verification code” button in the browser acquires the verification information, the terminal triggers the web client to invoke the NFC function.")
if the matching verification succeeds, completing, by the payment collection device, a payment request by using the account information included in the payment information, wherein the method further comprises: generating and broadcasting, by the payment device, a second wireless signal that includes a verification information acquisition request;
(Zhao WO2016061769A1 at pp. 12-13) ("FIG. 1 is a flowchart of a method for transmitting authentication information according to an embodiment of the present invention. As shown in FIG. 1, the method can include the following steps. In step S101, the first terminal detects whether the condition for performing the verification operation is satisfied. Step S102: If yes, the first terminal generates a verification information acquisition request, where the verification information acquisition request is used to request the second terminal to feed back verification information." "In a preferred embodiment, before the first terminal sends the verification information acquisition request to the second terminal, the first terminal may establish a connection with the near field communication between the second terminal; the verification information acquisition request and the verification information. The acquisition response is sent over the connection of the near field communication. Among them, the near field communication may include NFC, Bluetooth, Wi-Fi, and the like as described above. Step S103: The first terminal sends the verification information acquisition request to the second terminal. In an embodiment, when the first terminal detects that a verification operation is required, and generates verification information After obtaining the request, the first terminal may send a verification information acquisition request to the second terminal by using a communication mode agreed with the second terminal or by calling the wireless connection mode. For example, the first terminal may send the verification information acquisition request to the second terminal through the NFC, and the method is similar for other wireless functions, such as Wi-Fi, Bluetooth, and the like. Optionally, the first terminal and the second terminal may preset an operation mode of the wireless function. For example, when performing NFC communication, the first terminal may be preset to send the verification information acquisition request in a P2P mode or a card reader mode.")
after detecting the second wireless signal, sending, by the payment collection device, a third wireless signal that includes the verification information to the payment device; and
(Zhao WO2016061769A1 at pp. 14-15) ("In the embodiment of the present invention, when the first terminal detects that the condition for performing the verification operation is satisfied, the verification information acquisition request may be generated to request the second terminal to feed back the verification information, and then the first terminal may automatically send the verification information to the second terminal. Acquiring the request and receiving the verification information acquisition response returned by the second terminal, including the verification information. The first terminal may send the verification information to the server, so that the server may verify the first terminal according to the verification information. In this way, the input operation of the user is reduced, the efficiency and accuracy of the verification information are improved, and the interaction capability of the terminal is enhanced.")
obtaining, by the payment device, the verification information from the third wireless signal.
(Zhao WO2016061769A1 at pp. 14-15) ("In the embodiment of the present invention, when the first terminal detects that the condition for performing the verification operation is satisfied, the verification information acquisition request may be generated to request the second terminal to feed back the verification information, and then the first terminal may automatically send the verification information to the second terminal. Acquiring the request and receiving the verification information acquisition response returned by the second terminal, including the verification information. The first terminal may send the verification information to the server, so that the server may verify the first terminal according to the verification information. In this way, the input operation of the user is reduced, the efficiency and accuracy of the verification information are improved, and the interaction capability of the terminal is enhanced.")
Zhao does not explicitly teach, however, Huang teaches:
the first wireless signal including verification information for a to-be-processed target payment transaction, the verification information including a random number generated based on a current time;
(Huang WO2017206833A1 at pp. 11-12) (""S106. After receiving the payment request, the payment device may send a request message for the payment authorization code to the payment server. The request message may carry information such as a user identifier (such as OpenID) of the user, so that the payment server generates a payment authorization code for the user.
S108. After receiving the payment authorization code request message sent by the payment device, the payment server may generate a payment authorization code according to multiple payment information such as a user identifier of the user, a payment method of the user, a payment time, a timestamp, and a random number generator."") obtaining, by a payment device, the verification information from the first wireless signal after detecting the first wireless signal;
(Huang WO2017206833A1 at pp. 11-12) ("S110. The payment server sends a payment authorization code generated by the payment server to the payment device. After receiving the payment authorization code, the payment device may be stored in the TEE or may be stored in the REE. S112. After receiving the payment authorization code sent by the payment server, the payment device can obtain the payment security in the TEE. The full code is then generated in the TEE based on the payment security code and the payment authorization code, and the secure payment authorization code is displayed in the TEE. It should be noted that embodiments of the present invention do not limit the order in which the payment device acquires the payment security code and obtains the payment authorization code from the payment server. The payment security code may be obtained by the payment device from the payment server or other device before, or may be generated by the payment device itself.")
generating, by the payment device, a two-dimensional code representing payment information, by encoding payment account information and the verification information, and displaying the two-dimensional code in an interactive interface to the payment collection device;
(Huang WO2017206833A1 at pp. 12-13) ("Since the function of the payment security code is to verify whether the payment authorization code is derived from the TEE, the payment security code is not limited to the foregoing generation manner, as long as the information is obtained from the TEE of the payment device, and the information and the user are reported to the payment server. The corresponding relationship of the payment account, which may be referred to as a payment security code, may generate a secure payment authorization code based on the information. When the payment device generates the secure payment authorization code according to the payment authorization code and the payment security code, an implementation manner may be: calculating a hash value of the payment authorization code and the payment security code, and using the hash value as the security payment authorization code. Of course, the secure payment authorization code can also be generated by other means, such as directly using the encryption algorithm to encrypt the payment authorization code and the payment security code, for example, the hash value of the payment information and the payment security code can be directly calculated, and the hash value is used. As a secure payment authorization code. The payment device can display the secure payment authorization code in various ways, such as by one-dimensional code, two-dimensional code, barcode, number, and the like.")
scanning, by the payment collection device, the displayed two- dimensional code to obtain the payment information;
(Huang WO2017206833A1 at pp. 12-13) ("S114. The payee or the cashier can scan the secure payment authorization code displayed in the TEE of the user's payment device through the scanning device. The scanning device may be a dedicated scanning device, such as an infrared scanning device, or a scanning device integrated on other devices such as a mobile phone.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Zhou and Huang, because it allows for an improved system and improved security that prevents a malicious application from obtaining the private payment information of the payment authorization code generated by an authorization code calculator. (Huang at Abstract and pp. 5-6).
Zhao and Huang do not explicitly teach, however, Samuelsson teaches:
searching, by the payment collection device, a memory of the payment collection device for the verification information locally generated and sent to the payment device, and
(Samuelsson US20230065383 at paras. 92-94, 100-102) (See also at least Samuelsson Feb. 11, 2020 (SE) 2050145-8 at pages 1-3 and Jul. 3, 2020 (SE) 2050844-6 at pages 13-15) ("[0093] When the payer P1 wishes to make an offline digital payment to the payee P2 in the embodiment of FIGS. 3A-3B, the following activity takes place. It is recalled from the description of the previous embodiments that the payer communication device PD1 and the payee communication device PD2 use short-range data communication when the devices are in proximity of each other to agree upon the offline digital payment without requiring long-range data communication with the remote digital payment settlement service DPSS at that stage. In the embodiment of FIGS. 3A-3B, the short-range data communication takes place by exchange of optical code data, such as presentation and scanning/reading of QR codes (or barcodes), in both directions between the devices PD1, PD2." "[0101] The application 310 in the payee communication device PD2 scans the QR code at 350 in order to retrieve the QR data, i.e. the digital payment information. In step 352, the application 310 first verifies the certificate PC1 in the retrieved QR data by using the digital certificate cert_pub_cloud. If this verification is successful, the application 310 verifies S by using PC1. The application 310 also compares the ID in the retrieved QR data with the ID generated in step 332 to verify that they are the same. Moreover, the payee communication device PD2 checks that it is the correct payment receiver by verifying that the received payment token S comprises the digital certificate PC2 (or the public cryptographic key) of the payee communication device PD2.")
performing, by the payment collection device, matching verification on the verification information included in the payment information and the verification information locally generated and sent to the payment device; and
(Samuelsson US20230065383 at paras. 92-94, 100-102) (See also at least Samuelsson Feb. 11, 2020 (SE) 2050145-8 at pages 1-3 and Jul. 3, 2020 (SE) 2050844-6 at pages 13-15) ("[0101] The application 310 in the payee communication device PD2 scans the QR code at 350 in order to retrieve the QR data, i.e. the digital payment information. In step 352, the application 310 first verifies the certificate PC1 in the retrieved QR data by using the digital certificate cert_pub_cloud. If this verification is successful, the application 310 verifies S by using PC1. The application 310 also compares the ID in the retrieved QR data with the ID generated in step 332 to verify that they are the same. Moreover, the payee communication device PD2 checks that it is the correct payment receiver by verifying that the received payment token S comprises the digital certificate PC2 (or the public cryptographic key) of the payee communication device PD2.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Zhou, Huang, and Samuelsson, because it allows for an improved system that enables offline frictionless mobile payments. (Samuelsson at Abstract and paras. 1-20).
As per claim 6,
Zhao explicitly teaches:
A payment verification system, comprising: a payment collection device; and a payment device, wherein the payment collection device and the payment device are configured to perform the method according to claim 1.
(Zhao WO2016061769A1 at pp. 6-7) (A first terminal and a second terminal representing payer and payee devices, e.g., "The embodiment of the invention discloses a method and a terminal for transmitting verification information, which can enable two terminals to automatically transmit verification information, thereby completing the verification operation, reducing the input operation of the user, improving the acquisition efficiency and accuracy of the verification information, and enhancing The interactive capabilities of the terminal.")
Claims 7 and 12 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on December 30, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1, 6, 7, and 12, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea.
Regarding the applicant's argument that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees. Applicant argues that “The technological problem relates to payment efficiency and security when no authentication operation is performed on a user (see Applicant's specification at, e.g., para. [0003]-[0005]). The present claims address this problem by the payment collection device and the payment device performing the operations recited therein, thereby providing a technological solution to the technological problem (see Applicant's specification at, e.g., para. [0010]).
Examiner notes that the stated problems of payment efficiency and security is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of the payment collection device and the payment device performing the operations is part of the abstract idea, as it is merely involves receiving and transmitting data to provide verification and completion of a financial transaction. Furthermore, the collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction could be completed mentally or manually by paper or pen.
Furthermore, Examiner notes that the additional elements of the computer system - a “payment collection device”, “at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal”, “payment device”, “interactive interface”, “payment collection device”, “a memory”, “second wireless signal”, “third wireless signal”, to perform the steps of “obtaining”, “generating”, “scanning”, “searching”, “performing”, and “matching”, in all steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The claims at issue covers collecting, analyzing, and transmitting data for verification of payment information to facilitate a financial transaction. The claims invoke the “payment collection device”, “at least one of a near field communication (NFC) signal or a Bluetooth signal as a first wireless signal”, “payment device”, “interactive interface”, “payment collection device”, “a memory”, “second wireless signal”, “third wireless signal”, to perform the steps of “obtaining”, “generating”, “scanning”, “searching”, “performing”, and “matching” merely as tools to execute the abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mental process) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea. Applicant argues that “the claims are a unique configuration and implementation of devices that enable computers to ask authentication questions involving data that, prior to such unique configuration/implementation, the computers would not have”.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the various specific, discrete steps carried out by the computer system are a routine, well-understood, and conventional function of a generic computer and, thus, are not sufficient to add significantly more. Per the specification, the recited computer elements are described only at a high level of generality, (see Spec. at paras. [0088]-[0089]). In view of the specification, the application of the computer elements is merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
Finally, Applicant argues that “the Examiner's § 101 analysis is incorrect, because it also applies to claims of issued US patents, such as claim 15 of US 10,664,817, claim 7 of US 10,558,960, claim 1 of US 11,176,538, which are randomly found” and “Because an issued US patent is presumed to be valid (35 U.S.C. 282) but, as shown above, the Examiner's § 101 analysis applies to the issued US patent, the Examiner's § 101 analysis is incorrect and the § 101 rejection is improper.”
Examiner notes that this is merely a conclusory argument without any support. Furthermore, pursuant to MPEP 1701:
“Every patent is presumed to be valid. See 35 U.S.C. 282, first sentence. Public policy demands that every employee of the United States Patent and Trademark Office (USPTO) refuse to express to any person any opinion as to the validity or invalidity of, or the patentability or unpatentability of any claim in any U.S. patent or the expiration date of any patent, except to the extent necessary to carry out:
(A) an examination of a non-reissue patent application where determination of the expiration date of a patent is necessary to conduct examination of the non-reissue patent application,
(B) an examination of a reissue application of the patent,
(C) a supplemental examination proceeding or reexamination proceeding to reexamine the patent,
(D) an interference or derivation proceeding involving the patent,
(E) a patent term adjustment or extension under 35 U.S.C. 154 and/or 35 U.S.C. 156 where determination of the expiration date of a patent is necessary to determine the adjustment or extension,
(F) a notification that a patent has expired for failure to pay maintenance fee,
(G) a consideration of a request under the regulations (e.g., a petition) wherein determination of patent term is necessary or arises as an ancillary matter, or
(H) an inter partes or post-grant review of the patent.”
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1, 6, 7, and 12, Examiner notes the following:
Applicant argues that “Samuelsson does not qualify as prior art for the present application.” “Specifically, the present application is based upon and claims priority to Chinese Patent Application No. 202010767469.3, filed on August 3, 2020. Samuelsson is a US national phase application of PCT/SE2020/051251, filed on December 22, 2020, which claims priority to 4 SE applications: (1) SE 2050086-4 filed on January 29, 2020 (2) SE 2050145-8 filed on February 11, 2020 (3) SE 2050844-6 filed on July 3, 2020 (4) SE 2051201-8 filed on October 15, 2020 As can be seen, (1) SE 2050086-4, (2) SE 2050145-8, and (3) SE 2050844-6 were filed before the priority date of the present application; and (4) SE 2051201-8 and PCT/SE2020/051251 were filed after the priority date of the present application.”
Examiner disagrees and notes that Samuelsson teaches the limitations of the claim as noted above in the instant rejection. (See Samuelsson US20230065383 at paras. 92-94, 100-102) (See also at least Samuelsson Feb. 11, 2020 (SE) 2050145-8 at pages 1-3 and Jul. 3, 2020 (SE) 2050844-6 at pages 13-15).
searching, by the payment collection device, a memory of the payment collection device for the verification information locally generated and sent to the payment device, and.
See e.g., Samuelsson Jul. 3, 2020 (SE) 2050844-6 at page 13, “As seen at preparatory steps 1 and 2, each of the payer communication device PD 1 and payee communication device PD2 requests and receives a respective cryptographic key pair from the cloud, which may include the digital payment settlement service DPSS and a national bank cloud. The respective cryptographic key pair comprises a public key and a private (secure) key, as is generally known for asymmetric data encryption and decryption. The private (secure) key is advantageously accommodated in secure memory SM in the respective device. As seen at further preparatory steps 3 and 4, the payer communication device PD 1 requests and receives digital cash, to be accommodated in the secure memory SM as a local digital wallet, as previously described. The payee communication device PD2 may have its own local digital wallet to accommodate digital cash in its secure memory SM, as is seen in Fig 6.”
See e.g., Samuelsson Jul. 3, 2020 (SE) 2050844-6 at page 14, “The payee communication device PD2 initiates a payment transaction and sends a payment request to the payer communication device PDl in step 6. In step 7, the payer communication device PD 1 checks the current balance or credit of the local digital wallet to that it is enough to cover the payment amount. If the check passes, the payer communication device PD 1 updates the current balance or credit of the local digital wallet by deducting the payment amount of the digital payment to be performed. The payer communication device PD 1 moreover signs the transaction information of the 10 payment transaction with its private (secure) key, and stores the signed transaction information ( cf. digital payment information DPI as previously described) in the local buff er B 1 ("Offline Transaction Ledger") in step 8.
The payer communication device PD 1 then sends the signed transaction information, together with its public key, to the payee communication device PD2 in step 9. The payee communication device PD2 checks the received signed transaction information in step 10 using the received public key. If the check is passed, the payee communication device PD2 proceeds to update its digital cash, accommodated in the local digital wallet in the secure memory SM, with the amount of the payment transaction. It moreover stores the signed transaction information ( cf. digital payment information DPI as previously described) in the local buffer B2 ("Offline Transaction Ledger").”
performing, by the payment collection device, matching verification on the verification information included in the payment information and the verification information locally generated and sent to the payment device; and
See e.g., Samuelsson Feb. 11, 2020 (SE) 2050145-8 at page 2, “In embodiments of the invention, at the moment of payment, the transaction is digitally signed by the payer and transmitted locally to the payee, so the payee has a digitally signed commitment, similar to a guaranteed check. If both parties are offline at the moment of payment, the transfer of money will take place later when one of the parties has internet connection and access to the payment service's back-end in the cloud. All the transactions are logged locally by both the payer and the payee and update the offline digital balance of both parties. In those cases where one or both parties are online, the transfer of money takes place at the moment of payment.”
See e.g., Samuelsson Jul. 3, 2020 (SE) 2050844-6 at page 14, “The payee communication device PD2 initiates a payment transaction and sends a payment request to the payer communication device PDl in step 6. In step 7, the payer communication device PD 1 checks the current balance or credit of the local digital wallet to that it is enough to cover the payment amount. If the check passes, the payer communication device PD 1 updates the current balance or credit of the local digital wallet by deducting the payment amount of the digital payment to be performed. The payer communication device PD 1 moreover signs the transaction information of the 10 payment transaction with its private (secure) key, and stores the signed transaction information ( cf. digital payment information DPI as previously described) in the local buff er B 1 ("Offline Transaction Ledger") in step 8.
The payer communication device PD 1 then sends the signed transaction information, together with its public key, to the payee communication device PD2 in step 9. The payee communication device PD2 checks the received signed transaction information in step 10 using the received public key. If the check is passed, the payee communication device PD2 proceeds to update its digital cash, accommodated in the local digital wallet in the secure memory SM, with the amount of the payment transaction. It moreover stores the signed transaction information ( cf. digital payment information DPI as previously described) in the local buffer B2 ("Offline Transaction Ledger").”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Tran can be reached on 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695