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 2, 2025 in which claims 1, 5, 9, 12, and 16 have been amended; and claims 4, 6-8, 10-11, 15, and 17-21 have been canceled. Therefore, claims 1-3, 5, 9, 12-14, and 16 are currently pending in the application.
Priority
Application 18/697,684 filed on 04/01/2024 is a 371 of PCT/CN2022/1 22850 09/29/2022 and claims priority to CHINA 202111165698.9 09/30/2021.
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-3, 5, 9, 12-14, and 16 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). Claims 1 and 9 are directed to a method 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 digital currency-based transaction method, comprising: establishing a Near Field Communication (NFC) connection with a transaction receiver;
exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection,
performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction; and
initiating the transaction according to the transaction features, and
completing the transaction with the transaction receiver according to the transaction features; and
notifying, if the transaction feature negotiation fails, both parties of the transaction of a reason of the negotiation failure, and terminating the transaction;
wherein if the reason of the negotiation failure is application version mismatching, both parties of the transaction are prompted to upgrade an application before the transaction and if the reason of the negotiation failure is not application version mismatching, the transaction is terminated immediately;
wherein the performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction comprises performing the transaction feature negotiation according to a preset negotiation rule to obtain the transaction features supported by both parties of the transaction, wherein the negotiation rule comprises:
determining whether a transaction amount exceeds a transaction limit of the transaction receiver;
determining whether an application version number and a cryptographic algorithm are matched with an application version number and a cryptographic algorithm of the transaction receiver, wherein application version number matching comprises that application versions of both parties of the transaction are being identical or compatible, and
cryptographic algorithm matching comprises that cryptographic algorithms of both parties of the transaction are being identical or compatible; and
determining a transaction model supported by both parties of the transaction according to a terminal form, a networking capability, and a transaction model, as well as the transaction model of the transaction receiver.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction. 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 Near Field Communication (NFC) connection with a transaction receiver” and “an application”, to perform the steps of “exchanging”, “performing”, “initiating”, “completing”, “notifying”, and “notifying”, 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 judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses at pages [15]-[17], “As shown in Fig. 4, the system architecture 400 may include terminal devices 401, 402 and 403, a network 404, and a server 405. The network 404 is configured to provide media for communication links between the terminal devices 401, 402 and 403, and the server 405. The network 404 may include various connection types, such as wired, wireless communication links, or fiber optic cables. A user may interact with the server 405 by using the terminal devices 401, 402 and 403 through the network 404 to receive or send messages, etc. Various client applications, such as digital currency applications, digital currency wallet applications, commercial banking applications, instant messaging tools, email clients, social platform software, etc. (examples only) may be installed on the terminal devices 401, 402 and 403. The terminal devices 401, 402 and 403 may be a variety of electronic devices having a display screen and supporting web browsing, including, but is not limited to, smartphones, tablets, laptops, desktops, etc.
The server 405 may be a server that provides various services, for example, a background management server that provides support for a digital currency transaction request sent by the user through the terminal devices 401, 402 and 403. The background management server may perform processing, such as establishing an NFC connection with a transaction receiver; exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection, and performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction; and initiating the transaction according to the transaction features, and completing the transaction with the transaction receiver according to the transaction features, on data such as the received digital currency transaction request, and feed back a processing result (such as a digital currency transaction result-only an example) to the terminal device.
It is to be noted that the digital currency-based transaction method provided by the embodiments of the present disclosure is generally executed by the server 405, and accordingly, the digital currency-based transaction apparatus is generally provided in the server 405.
It is to be understood that the number of terminal devices, networks, and servers in Fig. 4 is merely illustrative. There may be any number of terminal devices, networks, and servers according to implementation requirements.
Referring to Fig. 5 below, which shows a schematic structural diagram of a computer system 500 suitable for implementing a terminal device or a server according to an embodiment of the present disclosure. The terminal device or the server shown in Fig. 5 is merely an example and should not impose any restrictions on the functionality and scope of use of the embodiments of the present disclosure.”
Additionally, the claimed human-computer interface is merely adding pre-solution activity to the judicial exception, as merely data gathering means between a user and the transaction entity, and the interface objects are generally linking the judicial exception to a particular technological environment. The specification says no more than the human-computer interface refers to an interactive interface between a user and the transaction entity (such as a receipt and payment device), including a key, a touch, a fingerprint collector, etc. (See Spec. at page [06]).
Furthermore, the specification discloses at page [06], “The cryptographic algorithm refers to a security operation encryption algorithm used in the transaction.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “a Near Field Communication (NFC) connection with a transaction receiver” and “an application”, to perform the steps of “exchanging”, “performing”, “initiating”, “completing”, “notifying”, and “notifying”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 9 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 9 recites the additional elements of “An electronic device for a digital currency-based transaction, comprising: one or more processors; and a storage apparatus, configured to store one or more programs; wherein the one or more programs are executed by the one or more processors to cause the one or more processors to implement following actions:”.
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 claims 2-3, 5, 12-14, and 16 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-3, 5, 9, 12-14, and 16 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-3, 5, 9, 12-14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao, U.S. Patent Application Publication Number 2021/0287204; in view of Fujian, CN Patent Application Publication Number CN111401869A; in view of Sanchez-Llorens, U.S. Patent Application Publication Number 2024/0394706; in view of Lu, WIPO Patent Application Publication Number WO2019228074A1; in view of Luo, CN Patent Application Publication Number CN103871163A.
As per claim 1,
Zhao explicitly teaches:
establishing a Near Field Communication (NFC) connection with a transaction receiver;
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0026] According to another aspect, an embodiment of the present invention provides a device, and the device includes a function that can be used to implement the foregoing transaction manner screening and transaction manner negotiation by using an NFC connection, to complete a transaction. The function may be implemented by using hardware, or may be implemented by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the foregoing function. The module may be hardware and/or software.")
exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection, and
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0027] In a possible implementation, the device includes an NFC unit, a memory, a processor, and a communications unit. The NFC unit performs communication between devices, to complete transaction manner negotiation. The memory stores a transaction manner list and a corresponding account list. The processor reads and screens a transaction manner list from the memory, matches transaction manners of different devices, and initiates a transaction request to a server corresponding to a transaction manner by using the communications unit.")
performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction;
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0027] In a possible implementation, the device includes an NFC unit, a memory, a processor, and a communications unit. The NFC unit performs communication between devices, to complete transaction manner negotiation. The memory stores a transaction manner list and a corresponding account list. The processor reads and screens a transaction manner list from the memory, matches transaction manners of different devices, and initiates a transaction request to a server corresponding to a transaction manner by using the communications unit.")
initiating the transaction according to the transaction features, and
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0027] In a possible implementation, the device includes an NFC unit, a memory, a processor, and a communications unit. The NFC unit performs communication between devices, to complete transaction manner negotiation. The memory stores a transaction manner list and a corresponding account list. The processor reads and screens a transaction manner list from the memory, matches transaction manners of different devices, and initiates a transaction request to a server corresponding to a transaction manner by using the communications unit.")
completing the transaction with the transaction receiver according to the transaction features; and
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0026] According to another aspect, an embodiment of the present invention provides a device, and the device includes a function that can be used to implement the foregoing transaction manner screening and transaction manner negotiation by using an NFC connection, to complete a transaction. The function may be implemented by using hardware, or may be implemented by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the foregoing function. The module may be hardware and/or software.")
notifying, if the transaction feature negotiation fails, both parties of the transaction of a reason of the negotiation failure, and terminating the transaction;
(Zhao US20210287204 at paras. 112-114) ("[0112] In a possible implementation, if a transaction fails for reasons such as an insufficient balance or a permission limitation, the server 30 corresponding to the transaction manner 2 sends, to the second terminal 20, a message indicating that the transaction fails. The second terminal 20 sends a remaining available transaction manner to the first terminal 10, and the remaining available transaction manner is a transaction manner 3 in this implementation. The first terminal 10 returns an account 13 corresponding to the transaction manner 3 to the second terminal 20. The second terminal 20 initiates a transaction request to a server corresponding to the transaction manner 3. [0113] In a possible implementation, the transaction request includes an account 13 of the first terminal 10, an account 23 of the second terminal 20, and a transaction amount. [0114] In a possible implementation, the server 30 corresponding to the transaction manner 2 further sends, to the first terminal 10, a message indicating a transaction failure.")
wherein the performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction comprises performing the transaction feature negotiation according to a preset negotiation rule to obtain the transaction features supported by both parties of the transaction, wherein the negotiation rule comprises:
(Zhao US20210287204 at paras. 24-29, 49-54) ("[0027] In a possible implementation, the device includes an NFC unit, a memory, a processor, and a communications unit. The NFC unit performs communication between devices, to complete transaction manner negotiation. The memory stores a transaction manner list and a corresponding account list. The processor reads and screens a transaction manner list from the memory, matches transaction manners of different devices, and initiates a transaction request to a server corresponding to a transaction manner by using the communications unit.")
Zhao does not explicitly teach, however, Fujian does teach:
A digital currency-based transaction method, comprising:
(Fujian CN111401869A at page 2) ("a digital currency issuing mechanism for issuing digital currency and performing digital currency transaction, wherein the digital currency is provided with information including digital signature, face value and number of the digital currency issuing mechanism;")
determining a transaction model supported by both parties of the transaction according to a terminal form, a networking capability, and a transaction model, as well as the transaction model of the transaction receiver.
(Fujian CN111401869A at pages 7-8) ("The invention also discloses a digital currency circulation method based on any one of the digital currency circulation systems, which is realized as follows: the digital currency issuing mechanism issues digital currency, the user exchanges the digital currency and stores the digital currency in the user terminal, and the information of the digital currency comprises digital signature information, face value information, number information, owner identity information and digital currency transaction flow information of the digital currency issuing mechanism; when in off-line transaction, the user A pays the corresponding face value and the digital currency with the corresponding number to the user B through the user terminal A, at the moment, the corresponding face value and the digital currency with the corresponding number also comprise identity information of the user A, digital signature information of a digital currency issuing mechanism and transaction flow direction information of a digital currency issuing mechanism to A, and after the transaction is completed, the corresponding face value and the digital currency with the corresponding number stored in the user terminal B of the user B are added with the transaction flow direction information of the user A to B and the identity information of the user B; by analogy, the stored information of the corresponding face value and the digital currency with the corresponding number of the user terminal of the last digital currency owner comprises all digital currency transaction flow information, the past owner identity information of all digital currency transaction flow chains and the identity information of the last owner of the digital currency; when each user terminal is in an on-line state, each user terminal deletes the digital currency related information by synchronizing with the digital currency issuing mechanism or the network node, and the user terminal of the final digital currency owner deletes the past owner identity information and the digital currency transaction flow direction information of the digital currency transaction flow chain in the digital currency information and adds the transaction flow direction information of the digital currency issuing mechanism to the final owner.")
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 Fujian, because it allows for improving the circulation of the digital currency can be realized and the problem of large volume of the digital currency transaction process can be realized. (Fujian at Abstract and pages. 2-3).
Zhao and Fujian do not explicitly teach, however, Sanchez-Llorens does teach:
wherein if the reason of the negotiation failure is application version mismatching, both parties of the transaction are prompted to upgrade an application before the transaction and if the reason of the negotiation failure is not application version mismatching, the transaction is terminated immediately;
(Sanchez-Llorens US20240394706 at paras. 105-107) ("[0106] Based at least in part on determining that the second customer-facing device 104N does not have the same version of software and/or firmware as the merchant-facing device 102A (or an incompatible version of software and/or firmware), the merchant application 106 can update the software and/or firmware of the merchant-facing device 102A and/or the second customer-facing device 104N, as illustrated in block 710. In some examples, the second customer-facing device 104N can have a newer version of software and/or firmware than the merchant-facing device 102A. In such examples, the merchant application 106 can send a request to the payment processing service server(s) 124 for an update, that can be applied upon a subsequent reboot of the merchant-facing device 102A. If the second customer-facing device 104N has an older version of software and/or firmware than the merchant-facing device 102A, the merchant application 106 can push an update to the second customer-facing device 104N. In some examples, the second customer-facing device 102N can be docked to the merchant-facing device 102A to receive the update. In other examples, the merchant-facing device 102A can push the update to the second customer-facing device 104N via another communication interface (e.g., wired or wireless). Then, based at least in part on the second customer-facing device 102N having the same version of software and/or firmware as the merchant-facing device 102A, the merchant application 106 can enable the merchant-facing device 102A to interact with the first customer-facing device 104A and the second customer-facing device 104N, as illustrated in block 708.")
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, Fujian, and Sanchez-Llorens, because it improves customer experience and/or security by minimizing the time where a payment instrument is out of sight of a customer. (Sanchez-Llorens at Abstract and paras. 2-3, 105-107).
Zhao, Fujian, and Sanchez-Llorens do not explicitly teach, however, Lu does teach:
determining whether a transaction amount exceeds a transaction limit of the transaction receiver;
(Lu WO2019228074A1 at pages 13-14) ("Step 108-13: The terminal determines whether the upper limit and lower limit of continuous offline transactions have been read. If yes, execute step 108-14, otherwise execute step 109; Step 108-14: The terminal sends a GETDATA command to the IC card, waits for and receives the ATC (Chinese name: Application Transaction Counter, English full name: Application Transaction Counter) returned by the IC card and the last online ATC saved in the register The value of Step 108-15: Whether the terminal receives the completed ATC returned by the IC card and the value of the last online ATC register, if yes, execute step 108-17, otherwise execute step 108-16; Step 108-16: The terminal sets the "missing IC card data" bit in the TVR to 1, and sets the "exceeds the offline continuous transaction lower limit" and the "exceeds the offline continuous transaction upper limit" bits in the TVR to 1, and performs step 108- 17; Step 108-17: The terminal determines whether the difference between the received ATC and the last online ATC register value is greater than the lower limit of offline continuous transactions, if yes, executes step 108-18, otherwise executes step 108-21; Step 108-18: The terminal sets the "exceeded offline offline transaction lower limit" bit to 1, and executes step 108-19; Step 108-19: the terminal determines whether the difference between the received ATC and the last online ATC register value is greater than the upper limit of offline continuous transactions, if yes, executes step 108-20, otherwise executes step 108-21;")
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, Fujian, Sanchez-Llorens, and Lu, because it provides an improved method and device for realizing a contactless EMV contact transaction, which can achieve a small amount of passwordless effect, improve the user experience, and does not need to upgrade the IC card, which is convenient for users. (Lu at Abstract and pages. 7-8).
Zhao, Fujian, Sanchez-Llorens, and Lu do not explicitly teach, however, Luo does teach:
determining whether an application version number and a cryptographic algorithm are matched with an application version number and a cryptographic algorithm of the transaction receiver, wherein application version number matching comprises that application versions of both parties of the transaction are being identical or compatible, and
(Luo CN103871163A at pages. 7-8) ("In the time that above-mentioned fiscard is compound Electronic Finance wallet/electronic bankbook card, in the time coordinating financial terminal to complete electronic wallet/electronic passbook consumption related service, after fiscard (compound Electronic Finance wallet/electronic bankbook card) inserts the card reader in financial terminal, first financial terminal carries out symmetric cryptographic algorithm with fiscard and selects to consult. Financial terminal carries out application choice, according to the self-defined FCI(File Control of the card issuer of fiscard loopback Information, document control information) symmetric cryptographic algorithm that adopts of first byte identification application of data element, when the self-defined FCI data element indication of above-mentioned card issuer adopts domestic cryptographic algorithm, and above-mentioned fiscard is supported domestic cryptographic algorithm, financial terminal and fiscard carry out negotiating algorithm, inform that fiscard adopts domestic cryptographic algorithm, and configure the secure access processing environment of domestic cryptographic algorithm with compound financial PSAM card; Otherwise acquiescence adopts external cryptographic algorithm, and financial terminal informs that fiscard adopts domestic cryptographic algorithm, and configure the secure access processing environment of external cryptographic algorithm with terminal backstage." "In the time that above-mentioned fiscard is compound Electronic Finance wallet/electronic bankbook card, in the time that financial terminal completes electronic wallet/electronic passbook consumption service, financial terminal utilizes PSAM calorimeter calculate MAC1 and the value of MAC1 and terminal offline transaction sequence number are returned to financial terminal, then financial terminal sends consumption order to compound Electronic Finance wallet/electronic bankbook card, compound Electronic Finance wallet/electronic bankbook card returns to financial terminal with MAC2 and TAC2, and then financial terminal utilizes PSAM card to carry out verification MAC2, the check results of returning by PSAM card, complete this time electronic wallet/electronic passbook consumption service of compound Electronic Finance wallet/electronic bankbook card." "Step 24, compound Electronic Finance wallet/electronic bankbook card return to the file info of compound Electronic Finance wallet/electronic bankbook card to financial terminal, this file packets of information is drawn together the information such as card issuer mark, application sequence number; Step 25, financial terminal are consumed initialization; Step 26, compound Electronic Finance wallet/electronic bankbook card return to random number, electronic wallet/electronic passbook transaction sequence number, consumption key version number, consumption key algorithm mark to financial terminal;")
cryptographic algorithm matching comprises that cryptographic algorithms of both parties of the transaction are being identical or compatible; and
(Luo CN103871163A at pages. 7-8) ("In the time that above-mentioned fiscard is compound Electronic Finance wallet/electronic bankbook card, in the time coordinating financial terminal to complete electronic wallet/electronic passbook consumption related service, after fiscard (compound Electronic Finance wallet/electronic bankbook card) inserts the card reader in financial terminal, first financial terminal carries out symmetric cryptographic algorithm with fiscard and selects to consult. Financial terminal carries out application choice, according to the self-defined FCI(File Control of the card issuer of fiscard loopback Information, document control information) symmetric cryptographic algorithm that adopts of first byte identification application of data element, when the self-defined FCI data element indication of above-mentioned card issuer adopts domestic cryptographic algorithm, and above-mentioned fiscard is supported domestic cryptographic algorithm, financial terminal and fiscard carry out negotiating algorithm, inform that fiscard adopts domestic cryptographic algorithm, and configure the secure access processing environment of domestic cryptographic algorithm with compound financial PSAM card; Otherwise acquiescence adopts external cryptographic algorithm, and financial terminal informs that fiscard adopts domestic cryptographic algorithm, and configure the secure access processing environment of external cryptographic algorithm with terminal backstage." "In the time that above-mentioned fiscard is compound Electronic Finance wallet/electronic bankbook card, in the time that financial terminal completes electronic wallet/electronic passbook consumption service, financial terminal utilizes PSAM calorimeter calculate MAC1 and the value of MAC1 and terminal offline transaction sequence number are returned to financial terminal, then financial terminal sends consumption order to compound Electronic Finance wallet/electronic bankbook card, compound Electronic Finance wallet/electronic bankbook card returns to financial terminal with MAC2 and TAC2, and then financial terminal utilizes PSAM card to carry out verification MAC2, the check results of returning by PSAM card, complete this time electronic wallet/electronic passbook consumption service of compound Electronic Finance wallet/electronic bankbook card." "Step 24, compound Electronic Finance wallet/electronic bankbook card return to the file info of compound Electronic Finance wallet/electronic bankbook card to financial terminal, this file packets of information is drawn together the information such as card issuer mark, application sequence number; Step 25, financial terminal are consumed initialization; Step 26, compound Electronic Finance wallet/electronic bankbook card return to random number, electronic wallet/electronic passbook transaction sequence number, consumption key version number, consumption key algorithm mark to financial terminal;")
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, Fujian, Sanchez-Llorens, Lu, and Luo, because it provides an improved financial transaction system, can promote the application of domestic cryptographic algorithm in financial payment field, strengthen security and the controllability of the fiscard in financial payment field, in the extension process of domestic cryptographic algorithm fiscard, keep the compatibility to the existing financial terminal of not supporting domestic cryptographic algorithm, the application for domestic cryptographic algorithm in financial payment field has good facilitation. (Luo at Abstract and pages. 2-3).
As per claim 2,
Zhao explicitly teaches:
wherein the exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection comprises: sending its own interaction capability parameter to the transaction receiver by means of the NFC connection; and receiving an interaction capability parameter sent by the transaction receiver.
(Zhao US20210287204 at paras. 72-80, 147-153) ("[0072] In a possible implementation, the first terminal 10 first sends the transaction manner 1 and the corresponding account 12 to the second terminal 20, to negotiate whether the transaction manner 1 is available. [0076] In a possible implementation, multiple transaction manners such as the transaction manner 2 and the transaction manner 3 may be sent in a list form, or may be sent one by one. [0077] The second terminal 20 performs matching between a transaction manner sent by the first terminal 10 and a transaction manner supported by the second terminal 20, determines that the transaction manner 2 and the transaction manner 3 are available, selects an available transaction manner from the transaction manner 2 and the transaction manner 3, and returns the selected available transaction manner to the first terminal 10. In this embodiment, the selected available transaction manner is the transaction manner 2.")
As per claim 3,
Zhao explicitly teaches:
wherein the interaction capability parameter comprises at least one of the following: an application version number, a transaction model, a cryptographic algorithm, a communication mode, a human-computer interface, a wallet type, a terminal form, a networking capability, a transaction amount, and a transaction limit.
(Zhao US20210287204 at paras. 62-66, 147-153) ("[0063] For example, a transaction manner with a largest balance is sorted in the forefront. Alternatively, sorting may be performed according to a result of matching between a current transaction amount and amount data that is generated when each payment client is previously used each time, or the like. For example, a current transaction amount is RMB 500, a transaction amount generated when a first payment client is previously used each time may range from RMB 200 to RMB 1000, and a transaction amount generated when a second payment client is previously used each time ranges from RMB 0 to RMB 300; in this case, the first payment client may be sorted before the second payment client." "[0152] In this embodiment of the present invention, after the first terminal 10 or the second terminal 20 receives a message sent by the other party, that is, after the NFC unit or the NFC function module receives a message sent by the other party by using the NFC antenna, the NFC unit or the NFC function module may parse a part of or all information in the message. For example, the message header in FIG. 15 or FIG. 16 is parsed, and it is assumed that a parsed role identifier is a charge payer. The terminal may be triggered to determine, as described in the foregoing embodiment, whether a transaction manner is bound to another authorized account or whether an account balance is sufficient, and to perform operations on the transaction manner according to the determining result, such as screening and sorting. Payment application identification information in FIG. 15 or FIG. 16 is parsed, and it is assumed that parsed payment application identification information is an Alipay client identifier. The terminal may be triggered to determine, as described in the foregoing embodiment, whether a transaction manner (that is, a payment client) supported by the terminal has an Alipay client, the terminal is triggered according to the determining result to perform an operation, for example, start or invoke a payment client matched by two parities, and the like. Certainly, partial information may not be parsed by the NFC unit or the NFC function module, for example, the account information carried in the message, a transaction amount, or other additional information related to a service (such as transaction description information: payment, charge receiving, borrowing, repayment, and entrusted payment).")
As per claim 5,
Zhao, Fujian, and Sanchez-Llorens do not explicitly teach, however, Lu does teach:
wherein the negotiation rule further comprises: checking whether a cumulative transaction amount of the offline transactions reaches a limit, and
(Lu WO2019228074A1 at pages 13-14) ("Step 108-13: The terminal determines whether the upper limit and lower limit of continuous offline transactions have been read. If yes, execute step 108-14, otherwise execute step 109; Step 108-14: The terminal sends a GETDATA command to the IC card, waits for and receives the ATC (Chinese name: Application Transaction Counter, English full name: Application Transaction Counter) returned by the IC card and the last online ATC saved in the register The value of Step 108-15: Whether the terminal receives the completed ATC returned by the IC card and the value of the last online ATC register, if yes, execute step 108-17, otherwise execute step 108-16; Step 108-16: The terminal sets the "missing IC card data" bit in the TVR to 1, and sets the "exceeds the offline continuous transaction lower limit" and the "exceeds the offline continuous transaction upper limit" bits in the TVR to 1, and performs step 108- 17; Step 108-17: The terminal determines whether the difference between the received ATC and the last online ATC register value is greater than the lower limit of offline continuous transactions, if yes, executes step 108-18, otherwise executes step 108-21; Step 108-18: The terminal sets the "exceeded offline offline transaction lower limit" bit to 1, and executes step 108-19; Step 108-19: the terminal determines whether the difference between the received ATC and the last online ATC register value is greater than the upper limit of offline continuous transactions, if yes, executes step 108-20, otherwise executes step 108-21;")
whether a password-free amount of the offline transactions reaches a limit.
(Lu WO2019228074A1 at pages 8-9) ("Step T2: The terminal obtains the password-free IC card transaction limit in the application parameters corresponding to the selected current application, and determines whether the transaction amount in the transaction information is greater than the password-free IC card transaction limit, and if so, executes Step S2, otherwise, if the current application does not require the cardholder to verify the PIN code, step S2 is performed. According to another aspect of the present invention, a device for realizing a contactless EMV contact transaction is provided, which includes a selection application module, a passwordless setting module, an initialization module, an offline authentication module, a processing restriction module, a first judgment module, and a prompt. A receiving module, a second judgment module, a risk management module, a behavior analysis module, an online processing module, a transaction end processing module, and a third judgment module; The selection application module is configured to perform a selection application when the terminal receives the transaction information, and trigger the secret-free setting module; The password-free setting module is configured to set a password-free function and trigger the initialization module; The initialization module is configured to initialize a current application selected by the selection application module, and trigger the offline authentication module; The offline authentication module is configured to perform offline data authentication and trigger the processing restriction module;")
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, Fujian, Sanchez-Llorens, Lu, and Luo, because it provides an improved method and device for realizing a contactless EMV contact transaction, which can achieve a small amount of passwordless effect, improve the user experience, and does not need to upgrade the IC card, which is convenient for users. (Lu at Abstract and pages. 7-8).
Claims 9 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 13 is substantially similar to claim 2, thus, it is rejected on similar grounds.
Claim 14 is substantially similar to claim 3, thus, it is rejected on similar grounds.
Claims 12 and 16 are substantially similar to claim 5, thus, they are rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on December 2, 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-3, 5, 9, 12-14, and 16, Examiner notes the following:
Applicant argues that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “claim 1 recites the additional elements ‘exchanging an interaction capability parameter’ and ‘transaction features’ that integrate the abstract idea into a practical application because they impose the meaningful limits ‘a quick transaction is realized, a transaction success rate is improved, and the transaction performance is optimized’ on practicing the abstract idea.”
Examiner disagrees, however, and notes that the additional elements of the computer system - a “computer device” - to perform the “a Near Field Communication (NFC) connection with a transaction receiver” and “an application”, 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 to facilitate a financial transaction, which is a fundamental economic practice or commercial interaction or managing personal behavior or relationships or interactions between people. The claims invoke the “a Near Field Communication (NFC) connection with a transaction receiver” and “an application” 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 certain method of organizing human activity or mental process or mathematical calculation) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Examiner notes that, the stated “problem of how both parties can successfully transact” is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of providing an optimized transaction process is part of the abstract idea, as it is merely involves collecting, analyzing, and transmitting data to facilitate a financial transaction. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-3, 5, 9, 12-14, and 16, Examiner notes the following:
As to claim 1, technical feature “(1) A digital currency-based transaction method, comprising:”, Applicant argues that Fujian is non-analogous art. Examiner disagrees and notes that the instant invention recites a digital currency-based transaction method and apparatus and Fujian similarly recites a digital currency circulation system and circulation method, which falls within the same technological field as the claimed invention. Fujian expressly discloses a system enabling secure and successful digital currency transactions between users, including bidirectional authentication, protection of sensitive data, and reducing transaction failure by preventing multiple transactions of the same currency, and limiting overdraft of the digital currency during offline transactions. 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 Fujian, because it allows for improving the circulation of the digital currency can be realized and the problem of large volume of the digital currency transaction process can be realized. (Fujian at Abstract and pages. 2-3).
As to claim 1, technical feature “(2) exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection, and performing a transaction feature negotiation to obtain transaction features supported by both parties of a transaction;” Applicant argues that Zhao fails to teach the claim limitation. Applicant’s argument is not persuasive. Zhao explicitly discloses NFC communication between devices to negotiate transaction manners. Determining and matching compatible transaction manners between devices requires exchanging and comparing information indicative of each device’s supported capabilities to identify mutually supported transaction features. Furthermore, a list of supported transaction manners represents a set of interaction capability parameters describing supported device functionality, and exchanging interaction capability parameters. Under a broadest reasonable interpretation, Zhao’s negotiation of transaction manners constitutes “exchanging an interaction capability parameter with the transaction receiver by means of the NFC connection, and performing a transaction feature negotiation to obtain transaction features supported by both parties of the transaction”. (See Zhao US20210287204 at paras. 6-8, 24-29, 49-54).
As to claim 1, technical feature “(3) notifying, if the transaction feature negotiation fails, both parties of the transaction of a reason of the negotiation failure, and terminating the transaction; wherein if the reason of the negotiation failure is application version mismatching, both parties of the transaction are prompted to upgrade an application before the transaction; and if the reason of the negotiation failure is not application version mismatching, the transaction is terminated immediately;” Applicant argues that “Sanchez-Llorens does not teach taking appropriate measures taking appropriate measures based on the reason for the transaction failure. Therefore, the technical feature (3) would have not been obvious to one of ordinary skill in the art by combining the teachings of Zhou, Fujian, and Sanchez-Llorens.” Examiner disagrees and notes that Applicant argues the references in isolation rather than in combination. Examiner notes that the combination of Zhou, Fujian, and Sanchez-Llorens teaches the limitation at issue. Zhou explicitly teaches “notifying, if the transaction feature negotiation fails, both parties of the transaction of a reason of the negotiation failure, and terminating the transaction;” (See Zhao US20210287204 at paras. 112-114) and Sanchez-Llorens explicitly teaches “wherein if the reason of the negotiation failure is application version mismatching, both parties of the transaction are prompted to upgrade an application before the transaction and if the reason of the negotiation failure is not application version mismatching, the transaction is terminated immediately;” (See Sanchez-Llorens US20240394706 at paras. 105-107). 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, Fujian, and Sanchez-Llorens, because it improves customer experience and/or security by minimizing the time where a payment instrument is out of sight of a customer. (Sanchez-Llorens at Abstract and paras. 2-3, 105-107).
As to claim 1, technical feature (4-I) Applicant argues that Lu fails to teach the limitation of “determining whether a transaction amount exceeds a transaction limit of the transaction receiver.” Examiner disagrees and notes that Lu explicitly discloses determining whether a transaction amount exceeds configured limits associated with the receiving transaction entity and modifying transaction behavior based on that determination. (See Lu WO2019228074A1 at pages 13-14)
As to claim 1, technical feature (4-II) Applicant argues that Luo fails to teach the limitation of “determining whether an application version number and a cryptographic algorithm are matched with an application version number and a cryptographic algorithm of the transaction receiver, wherein application version number matching comprises that application versions of both parties of the transaction are being identical or compatible, and cryptographic algorithm matching comprises that cryptographic algorithms of both parties of the transaction are being identical or compatible.” Examiner disagrees and notes that Luo explicitly discloses, under a broadest reasonable interpretation, negotiation and selection of mutually supported application environments and cryptographic algorithms between transaction devices. Such negotiation determines whether the respective application configurations and cryptographic algorithms are compatible so that a transaction may proceed. Selecting a mutually supported environment constitutes determining that the parties’ versions and algorithms are identical or compatible. Accordingly, Luo teaches the claimed limitation. (See Luo CN103871163A at pages. 7-8)
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