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 November 25, 2025 in which claims 1, 3, 6, and 9 have been amended; claim 2 has been canceled; and claims 11-15 have been added. Therefore, claims 1 and 3-15 are currently pending in the application.
Priority
Application 18/566,755 filed on 12/04/2023, is a 371 of PCT/EP2022/065178 06/03/2022, and claims benefit of FRANCE FR2105933 06/04/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 § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function.
Claim 9 recites the following: “means for preparing the transaction”, “means for transmitting said at least one item of intermediate transaction execution data”, “means for executing the transaction”, and “means for transmitting the execution result”.
Here: “means for preparing the transaction”, “means for transmitting said at least one item of intermediate transaction execution data” are associated with the claimed “terminal of the professional”; and “means for executing the transaction” and “means for transmitting the execution result” is associated with the claimed “user communication device”, which provides sufficient structure respectively.
Because these claim limitations are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitations do not recite sufficient structure, materials, or acts to perform the claimed function.
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 and 3-15 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 method for executing a transaction between a transaction implementation terminal of a professional (TProf) and a user communication device (DTon) which is located near the transaction implementation terminal of the professional (TProf), comprising a step of preparing the transaction to be executed within the transaction implementation terminal of the professional (TProf), thereby outputting at least one item of intermediate transaction execution data;
a step of transmitting said at least one item of intermediate transaction execution data to the user communication device (DTon); and
a step of executing the transaction by the user communication device (DTon) using said at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon), said execution thereby outputting an execution result that is transmitted to the transaction implementation terminal of the professional (TProf),
wherein the step of executing the transaction by the user communication device (DTon) using said at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon) comprises a step of obtaining, by the user communication device (DTon), at least one item of data from an additional transactional device (DTa) held by the user.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a transaction between a professional and user. 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 transaction implementation terminal of a professional (TProf)”, “a user communication device (DTon)”, and “an additional transactional device (DTa)”, to perform the steps of “preparing”, “executing”, and “obtaining”, 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 transaction between a professional and user 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 8-9, “Thus, so that the professional can ensure that the user can perform the transaction without providing personal and/or confidential data to the professional, the method consists in using a communication terminal of the user (typically their mobile communication terminal such as a smartphone or tablet) to execute a portion of the transaction initiated by the terminal of the professional.” “Figure 1 describes a system in which the technique proposed can be implemented. Such a system (SystET) comprises a terminal of a professional (TProt), the terminal of the professional comprising transaction execution means. Such a terminal (TPro) is described in relation with Figure 3. Such a system also comprises a user communication device (DTon), physical device belonging to a user and generally consisting of a tablet or a smartphone, this device being portable and available to the user when the user is physically on the premises or in the presence of the professional who uses the professional terminal (TPro). This system may also comprise, depending on the embodiments, a transactional server (ServT). In this case, the transactional server is at least accessible via a communication network for the professional terminal (TPro) and/or the user communication device (DTon). Depending on the embodiments, the system also comprises an additional transactional device (DTa) (access card, credit card) in particular when the transaction implementation requires the use of such an additional transactional device (transaction to access premises, payment transaction by bank card, credit card).”
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 transaction implementation terminal of a professional (TProf)”, “a user communication device (DTon)”, and “an additional transactional device (DTa)”, to perform the steps of “preparing”, “executing”, and “obtaining”, 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 transaction between a professional and user 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”.
Claim 9 is substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 9 recites the additional elements of “A system for executing a transaction, system comprising a transaction implementation terminal of a professional (TProf), a user communication device (DTon) which is located near the transaction implementation terminal of the professional (TProf), and an additional transactional device (DTa) held by the user, comprising”.
Claim 3 recites “a near-field communication (NFC) interface of the user communication device (DTon)”.
Claim 4 recites “a dedicated memory space of said user communication device (DTon)” and “a validation application (AppVT)”.
Claim 5 recites “a transactional server to which the user communication device (DTon) is connected via the validation application (AppVT)”.
Claim 7 recites “a communication interface of the transaction implementation terminal of a professional (TProf), for transmission via a main channel”.
Claim 8 recites “a sound interface, configured to emit a previously encoded file in a form of an ultrasonic signal; - a screen of the transaction implementation terminal of a professional (TProf), configured to display the previously encoded file in the form of a two-dimensional code; - an interface for the transmission of data via a communication network, configured to transmit the previously encoded file in the form of a message”.
Claim 10 recites “A computer program product downloadable from a communication network and/or stored on a non-transitory computer-readable medium and/or executable by a microprocessor, comprising program code instructions to execute the method for executing the transaction according to claim 1, when it is executed on a computer.”
Claims 11 and 13 recite “a payment terminal including a card reader”.
Claim 15 recites “the user communication device (DTon) comprises a dedicated memory space storing a validation application (AppVT)”.
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 3-8 and 11-15 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 and 3-15 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, and 6-14 are rejected under 35 U.S.C. 103 as being unpatentable over Flurscheim, U.S. Patent Application Publication Number 2018/0204206; in view of Singh, U.S. Patent Application Publication Number 2024/0095697.
As per claim 1,
Flurscheim explicitly teaches:
A method for executing a transaction between a transaction implementation terminal of a professional (TProf) and a user communication device (DTon) which is located near the transaction implementation terminal of the professional (TProf), comprising a step of preparing the transaction to be executed within the transaction implementation terminal of the professional (TProf), thereby outputting at least one item of intermediate transaction execution data;
(Flurscheim US20180204206 at paras. 5-7) ("[0005] In some embodiments of the invention, a systems and methods for incorporating QR codes in payment transactions are provided. The systems and methods provide a platform that can be leveraged by various entities such as third party wallet providers, merchants, acquirers, payment processors, etc. that use QR codes to facilitate payment transactions. In the QR code based system, an access device can generate a QR code at the time of the payment transaction. The generated QR code can encode various data pertinent to the transaction, such as the transaction amount, a merchant identifier, a random number, and/or any relevant coupon data.")
a step of transmitting said at least one item of intermediate transaction execution data to the user communication device (DTon); and
(Flurscheim US20180204206 at paras. 5-7) ("[0005] A user may scan the generated code with his/her communication device and the communication device may in turn generate another QR code based on a cryptogram, financial data associated with the user, and the random number decoded from the access device generated QR code.")
a step of executing the transaction by the user communication device (DTon) using said at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon), said execution thereby outputting an execution result that is transmitted to the transaction implementation terminal of the professional (TProf),
(Flurscheim US20180204206 at paras. 5-7) ("[0005] A user may scan the generated code with his/her communication device and the communication device may in turn generate another QR code based on a cryptogram, financial data associated with the user, and the random number decoded from the access device generated QR code. The communication device generated QR code can be scanned at the access device and the access device can format the relevant data from the QR code into a standard authorization request message to be sent to an issuer.")
Flurscheim does not explicitly teach, however, Singh teaches:
wherein the step of executing the transaction by the user communication device (DTon) using said at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon) comprises a step of obtaining, by the user communication device (DTon), at least one item of data from an additional transactional device (DTa) held by the user.
(Singh US20240095697 at paras. 50-52) ("[0050] At reference numeral 510, a connection is established between a payment card and a device with a display. The connection can be either by way of contact or contactless. For instance, a card can be inserted into a slot provided by the device. Alternatively, the card can be connected wirelessly by radio frequency, for example by way of Bluetooth, or near field communication (NFC) protocol, among other protocols." "[0051] At numeral 520, credentials are requested and received by way of the connected device. An application on the payment card can be executed that generates a user interface that requests credentials or answers to security questions. The user interface can be conveyed to the device and presented on a display of the device. In response to receiving the request, the user can provide the credentials or answers to the security questions by interacting with the interface. In one instance, interaction can correspond to providing input through a touch screen display. Alternatively, input can be provided by other controls on the device such as buttons, knobs, dials, or sliders, among other things. In one embodiment, credentials can be provided automatically from the payment card. For example, prior input can be saved and retrieved, or a token can be acquired from the payment card.")
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 Flurscheim and Singh because it allows for an improved system for authenticating a user, and allowing a user to employ a payment card as disclosed to perform banking activities, such as account management, bill payment, and fund transfer, through substantially any compatible device with a display. (Singh at Abstract and paras. 1-7).
As per claim 3,
Flurscheim does not explicitly teach, however, Singh teaches:
wherein the step of obtaining, by the user communication device (DTon), said at least one item of data from the additional transactional device (DTa) held by the user comprises: - a step of issuing, by the user communication device (DTon), a request to obtain transactional data, said issuing step using a near-field communication (NFC) interface of the user communication device (DTon); - a step of receiving, by the user communication device (DTon), a response to said request to obtain transactional data via a near-field communication (NFC) interface of the user communication device (DTon).
(Singh US20240095697 at paras. 50-52) ("[0050] At reference numeral 510, a connection is established between a payment card and a device with a display. The connection can be either by way of contact or contactless. For instance, a card can be inserted into a slot provided by the device. Alternatively, the card can be connected wirelessly by radio frequency, for example by way of Bluetooth, or near field communication (NFC) protocol, among other protocols." "[0051] At numeral 520, credentials are requested and received by way of the connected device. An application on the payment card can be executed that generates a user interface that requests credentials or answers to security questions. The user interface can be conveyed to the device and presented on a display of the device. In response to receiving the request, the user can provide the credentials or answers to the security questions by interacting with the interface. In one instance, interaction can correspond to providing input through a touch screen display. Alternatively, input can be provided by other controls on the device such as buttons, knobs, dials, or sliders, among other things. In one embodiment, credentials can be provided automatically from the payment card. For example, prior input can be saved and retrieved, or a token can be acquired from the payment card.")
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 Flurscheim and Singh because it allows for an improved system for authenticating a user, and allowing a user to employ a payment card as disclosed to perform banking activities, such as account management, bill payment, and fund transfer, through substantially any compatible device with a display. (Singh at Abstract and paras. 1-7).
As per claim 6,
Flurscheim explicitly teaches:
a step of inserting, within said at least one item of intermediate execution data, said at least one encryption key obtained.
(Flurscheim US20180204206 at paras. 5-7) ("[0078] At step s4, the decoded information from the scanned QR code may be used to generate a cryptogram. That is, the cryptogram may be generated based on the decoded transaction amount, random number, optional coupon data, or any other variable data in the QR code. The cryptogram may also be generated using any suitable encryption algorithm including DES, triple DES, and AES. Since the random number is uniquely generated by the access device 120 for each payment transaction, the cryptogram generated by the communication device 110 may also be unique for each transaction. The cryptogram may be generated by cryptogram generation module 278 of the communication device 110. Accordingly, the cryptogram would be difficult for a fraudster to duplicate because of the various data that is uniquely generated for each transaction. Even if a fraudster were to steal the cryptogram, any attempt by the fraudster to use the cryptogram would likely fail as the random number that the cryptogram was generated based on may be different in a subsequent transaction." "[0083] Additionally, at step s4, the communication device 110 may combine the cryptogram and the obtained financial credentials 281. The combination may then be encoded into a QR code generated by the communication device 110. The QR code may be generated by the mobile application 272 via the QR generator module 276 of the communication device 110. The QR code generated by the communication device 110 may then be displayed on a display of the communication device 110.")
Flurscheim does not explicitly teach, however, Singh teaches:
wherein the step of preparing the transaction to be executed within the transaction implementation terminal of the professional (TProf) comprises: - a step of obtaining, via the additional transactional device (DTa) held by the user, at least one encryption key intended to be transmitted to the user communication device; and -
(Singh US20240095697 at paras. 50-52) ("[0051] At numeral 520, credentials are requested and received by way of the connected device. An application on the payment card can be executed that generates a user interface that requests credentials or answers to security questions. The user interface can be conveyed to the device and presented on a display of the device. In response to receiving the request, the user can provide the credentials or answers to the security questions by interacting with the interface. In one instance, interaction can correspond to providing input through a touch screen display. Alternatively, input can be provided by other controls on the device such as buttons, knobs, dials, or sliders, among other things. In one embodiment, credentials can be provided automatically from the payment card. For example, prior input can be saved and retrieved, or a token can be acquired from the payment card. [0052] At numeral 530, connection of the payment card to an enterprise server, such as a bank server is initiated. This action can involve connection to a service provider network. For instance, the service provider can be a cellular network. The payment card can employ at least an embedded antenna and a subscriber identification module (SIM) to initiate and establish a connection with the service provider. In accordance with one embodiment, connection is established with a channel dedicated for communication between cards and an enterprise server. In one instance, no other application can access or transmit data over this dedicated channel. Further, channel communications can be encrypted for additional security.")
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 Flurscheim and Singh because it allows for an improved system for authenticating a user, and allowing a user to employ a payment card as disclosed to perform banking activities, such as account management, bill payment, and fund transfer, through substantially any compatible device with a display. (Singh at Abstract and paras. 1-7).
As per claim 7,
Flurscheim explicitly teaches:
wherein the step of transmitting said at least one item of intermediate transaction execution data to the user communication device (DTon) comprises: - a step of activating a communication interface of the transaction implementation terminal of a professional (TProf), for transmission via a main channel; - a step of transmitting, via the communication interface, a file comprising said at least one item of intermediate data.
(Flurscheim US20180204206 at paras. 5-7) ("[0005] In some embodiments of the invention, a systems and methods for incorporating QR codes in payment transactions are provided. The systems and methods provide a platform that can be leveraged by various entities such as third party wallet providers, merchants, acquirers, payment processors, etc. that use QR codes to facilitate payment transactions. In the QR code based system, an access device can generate a QR code at the time of the payment transaction. The generated QR code can encode various data pertinent to the transaction, such as the transaction amount, a merchant identifier, a random number, and/or any relevant coupon data. A user may scan the generated code with his/her communication device and the communication device may in turn generate another QR code based on a cryptogram, financial data associated with the user, and the random number decoded from the access device generated QR code. The communication device generated QR code can be scanned at the access device and the access device can format the relevant data from the QR code into a standard authorization request message to be sent to an issuer.")
As per claim 8,
Flurscheim explicitly teaches:
wherein the communication interface activated to transmit the file comprising said at least one item of intermediate data belongs to the group comprising: - a sound interface, configured to emit a previously encoded file in a form of an ultrasonic signal; - a screen of the transaction implementation terminal of a professional (TProf), configured to display the previously encoded file in the form of a two-dimensional code; - an interface for the transmission of data via a communication network, configured to transmit the previously encoded file in the form of a message.
(Flurscheim US20180204206 at paras. 5-7) ("[0005] In some embodiments of the invention, a systems and methods for incorporating QR codes in payment transactions are provided. The systems and methods provide a platform that can be leveraged by various entities such as third party wallet providers, merchants, acquirers, payment processors, etc. that use QR codes to facilitate payment transactions. In the QR code based system, an access device can generate a QR code at the time of the payment transaction. The generated QR code can encode various data pertinent to the transaction, such as the transaction amount, a merchant identifier, a random number, and/or any relevant coupon data.")
As per claim 10,
Flurscheim explicitly teaches:
A computer program product downloadable from a communication network and/or stored on a non-transitory computer-readable medium and/or executable by a microprocessor, comprising program code instructions to execute the method for executing the transaction according to claim 1, when it is executed on a computer.
(Flurscheim US20180204206 at paras. 57, 102) ("[0102] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.")
As per claim 11,
Flurscheim explicitly teaches:
wherein the terminal of a professional (TProf) is a payment terminal including a card reader, wherein the user communication device (DTon) is a payment card, and wherein the transaction is a payment transaction.
(Flurscheim US20180204206 at paras. 49-52) ("[0050] In some implementations, the communication device 120 may be capable of communicating with the access device 120 using a short range communication technology such as NFC. For example, the communication 110 may interact with the access device 130 by tapping or waving the consumer device 120 in proximity of the access device 130. In some implementations, the communication device 120 may be a payment card such as a credit card, debit card, prepaid card, loyalty card, gift card, etc." "[0051] In some implementations, the access device 120 may be associated with or operated by the merchant computer 125. For example, the access device 120 may be a point of sale device that may include a contactless reader, an electronic cash register, a display device, etc.")
As per claim 12,
Flurscheim does not explicitly teach, however, Singh teaches:
wherein the additional transactional device (DTa) is an access card or a credit card.
(Singh US20240095697 at paras. 50-52) ("[0050] At reference numeral 510, a connection is established between a payment card and a device with a display. The connection can be either by way of contact or contactless. For instance, a card can be inserted into a slot provided by the device. Alternatively, the card can be connected wirelessly by radio frequency, for example by way of Bluetooth, or near field communication (NFC) protocol, among other protocols." "[0051] At numeral 520, credentials are requested and received by way of the connected device. An application on the payment card can be executed that generates a user interface that requests credentials or answers to security questions. The user interface can be conveyed to the device and presented on a display of the device. In response to receiving the request, the user can provide the credentials or answers to the security questions by interacting with the interface. In one instance, interaction can correspond to providing input through a touch screen display. Alternatively, input can be provided by other controls on the device such as buttons, knobs, dials, or sliders, among other things. In one embodiment, credentials can be provided automatically from the payment card. For example, prior input can be saved and retrieved, or a token can be acquired from the payment card.")
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 Flurscheim and Singh because it allows for an improved system for authenticating a user, and allowing a user to employ a payment card as disclosed to perform banking activities, such as account management, bill payment, and fund transfer, through substantially any compatible device with a display. (Singh at Abstract and paras. 1-7).
Claim 9 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 13 is substantially similar to claim 11, thus, it is rejected on similar grounds.
Claim 14 is substantially similar to claim 12, thus, it is rejected on similar grounds.
Claims 4, 5, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Flurscheim, U.S. Patent Application Publication Number 2018/0204206; in view of Singh, U.S. Patent Application Publication Number 2024/0095697; in view of Gadotti, U.S. Patent Application Publication Number 2013/0262309.
As per claim 4,
Flurscheim explicitly teaches:
wherein the step of executing the transaction by the user communication device (DTon) using said at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon) comprises: - a step of receiving said at least one item of intermediate transaction execution data by the user communication device (DTon); a step of dynamically configuring the user communication device (DTon), according to said at least one item of intermediate execution data,
(Flurscheim US20180204206 at paras. 76-77) ("[0076] At step s2, the user may scan the QR code generated by the access device 120 that is displayed on a display of the access device 120, with communication device 110. The scanning may be accomplished via a camera or scanner internal to communication device 110. The communication device 110 may decode the information encoded in the scanned QR code via mobile application 272 interfacing with the QR reader module 274, as described above. The information may include transaction amount, a random number, optional coupon data, or any other variable data. The random number may be unique to each transaction and serve as a fraud prevention mechanism, described in further detail below. The communication device 110 may display a confirmation for a successful scan or an error message for an unsuccessful scan. [0077] At step s3, the mobile application 272 running on the communication device 110 may interface with the secure element 280 to obtain the user's financial credentials 281. As described above, the financial credentials may be securely stored within the secure element 280 on the communication device 110. In some embodiments, the mobile application 272 may have exclusive access to the secure element 280.")
said step of dynamic configuration comprising a step of executing, within a dedicated memory space of said user communication device (DTon),
(Flurscheim US20180204206 at paras. 76-77) ("[0076] At step s2, the user may scan the QR code generated by the access device 120 that is displayed on a display of the access device 120, with communication device 110. The scanning may be accomplished via a camera or scanner internal to communication device 110. The communication device 110 may decode the information encoded in the scanned QR code via mobile application 272 interfacing with the QR reader module 274, as described above. The information may include transaction amount, a random number, optional coupon data, or any other variable data. The random number may be unique to each transaction and serve as a fraud prevention mechanism, described in further detail below. The communication device 110 may display a confirmation for a successful scan or an error message for an unsuccessful scan. [0077] At step s3, the mobile application 272 running on the communication device 110 may interface with the secure element 280 to obtain the user's financial credentials 281. As described above, the financial credentials may be securely stored within the secure element 280 on the communication device 110. In some embodiments, the mobile application 272 may have exclusive access to the secure element 280.")
Flurscheim and Singh do not explicitly teach, however, Gadotti teaches:
a validation application (AppVT) for entering said at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon); - a step of receiving, by the validation application (AppVT), at least one item of data entered by said user; - a step of validating, by the validation application (AppVT), the transaction according to said at least one item of data entered by said user and said intermediate data, outputting a validation result.
(Gadotti US20130262309 at paras. 14-17) ("[0014] The payment or transaction process comprises optically capturing a barcode image by the initiating user's mobile communication device running the secure mobile payment mobile application; and decoding, by secure mobile payment mobile application, the barcode, and displaying the decoded information to the initiating user for verification. Optionally, the initiating user is allowed to make modification to the decoded information and/or append new data, such as a payment amount, to be transmitted to the central processing server by the secure mobile payment mobile application. The payment or transaction process further comprises prompting and receiving from the initiating user, by the secure mobile payment mobile application, his/her security PIN. The security PIN is then transmitted to the central processing server along with the decoded information, the modified data, appended new data, and identification data about the mobile communication device. [0015] The central processing server receives the information and verifies the authenticity of the information received and the initiating user using the initiating user's security PIN, the identification data about the mobile communication device, and data in initiating user account preserved in the central processing server. If the authenticity of the information received and the initiating user's identity are positively verified, the central processing server executes the transaction transferring funds from the eWallet of the payer user account to the eWallet of the payee or barcode originator user account. [0016] The central processing server then sends the execution result of the transaction to both the initiating user and the barcode originator by electronic mail, Internet instant message, SMS telecommunication message, communication message for the secure mobile payment mobile application, or machine-to-machine communication via its secure mobile payment server backend APIs. The transaction execution results and history logs are also shown in a user interface, such as a web site accessible and readable by a computing device or a mobile communication device running a web browser application, or any application software or firmware designed specifically to access and display web contents.")
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 Flurscheim, Singh, and Gadotti because it allows for improved system to provide a mobile payment method and system that can substitute the use of physical currency with the same level of ubiquity and ease of use. It is a further objective of the presently claimed invention to provide a mobile payment method and system that can leverage existing mobile communication devices and communication infrastructures, and does not require a dedicated infrastructure of hardware or network. It is still a further objective of the presently claimed invention to provide a mobile payment method and system having a higher level of security than existing payment methods and systems. (Gadotti at Abstract and paras. 1-7).
As per claim 5,
Flurscheim explicitly teaches:
wherein, after the step of validating, by the validation application (AppVT), the transaction according to said at least one item of data entered by said user and said intermediate data, the method comprises: - a step of transmitting said intermediate data and said validation result to a transactional server to which the user communication device (DTon) is connected via the validation application (AppVT), -
(Flurscheim US20180204206 at paras. 82-84) ("[0083] Additionally, at step s4, the communication device 110 may combine the cryptogram and the obtained financial credentials 281. The combination may then be encoded into a QR code generated by the communication device 110. The QR code may be generated by the mobile application 272 via the QR generator module 276 of the communication device 110. The QR code generated by the communication device 110 may then be displayed on a display of the communication device 110. [0084] At step s5, the user may point the communication device 110 at the access device 120 such that the access device 120 can scan the QR code generated by the communication device 110 in step s4. The access device 120 may then scan the QR code displayed on the communication device 110 using an internal camera or sensor to the access device 120. The access device 120 may display a confirmation for a successful scan or an error message for an unsuccessful scan.")
Flurscheim and Singh do not explicitly teach, however, Gadotti teaches:
a step of validating, by the transactional server, said intermediate data and said validation result, comprising a check of validation cryptographic operations performed by said validation operation (AppVT); - a step of transmitting, to the transaction implementation terminal of a professional (TProf), said transaction validation result, when the check of the validation cryptographic operations outputs a positive result.
(Gadotti US20130262309 at paras. 14-17) ("[0014] The payment or transaction process comprises optically capturing a barcode image by the initiating user's mobile communication device running the secure mobile payment mobile application; and decoding, by secure mobile payment mobile application, the barcode, and displaying the decoded information to the initiating user for verification. Optionally, the initiating user is allowed to make modification to the decoded information and/or append new data, such as a payment amount, to be transmitted to the central processing server by the secure mobile payment mobile application. The payment or transaction process further comprises prompting and receiving from the initiating user, by the secure mobile payment mobile application, his/her security PIN. The security PIN is then transmitted to the central processing server along with the decoded information, the modified data, appended new data, and identification data about the mobile communication device. [0015] The central processing server receives the information and verifies the authenticity of the information received and the initiating user using the initiating user's security PIN, the identification data about the mobile communication device, and data in initiating user account preserved in the central processing server. If the authenticity of the information received and the initiating user's identity are positively verified, the central processing server executes the transaction transferring funds from the eWallet of the payer user account to the eWallet of the payee or barcode originator user account. [0016] The central processing server then sends the execution result of the transaction to both the initiating user and the barcode originator by electronic mail, Internet instant message, SMS telecommunication message, communication message for the secure mobile payment mobile application, or machine-to-machine communication via its secure mobile payment server backend APIs. The transaction execution results and history logs are also shown in a user interface, such as a web site accessible and readable by a computing device or a mobile communication device running a web browser application, or any application software or firmware designed specifically to access and display web contents.")
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 Flurscheim, Singh, and Gadotti because it allows for improved system to provide a mobile payment method and system that can substitute the use of physical currency with the same level of ubiquity and ease of use. It is a further objective of the presently claimed invention to provide a mobile payment method and system that can leverage existing mobile communication devices and communication infrastructures, and does not require a dedicated infrastructure of hardware or network. It is still a further objective of the presently claimed invention to provide a mobile payment method and system having a higher level of security than existing payment methods and systems. (Gadotti at Abstract and paras. 1-7).
As per claim 15,
Flurscheim explicitly teaches:
wherein the user communication device (DTon) comprises a dedicated memory space storing a validation application (AppVT),
(Flurscheim US20180204206 at paras. 43, 77) ("[0041] A “cryptogram” may be a uniquely signed digital payload associated with a primary account number (PAN) or token. The cryptogram may uniquely identify the device that emulated the payment card and is a form of validation. The cryptogram may be uniquely generated for every payment transaction." "[0043] A “secure element” can be a dynamic environment in which application code and application data can be securely stored and administered and which secure execution of applications occur. The secure element can reside in highly secure crypto chips. The financial credentials can be stored within the secure element." " [0077] At step s3, the mobile application 272 running on the communication device 110 may interface with the secure element 280 to obtain the user's financial credentials 281. As described above, the financial credentials may be securely stored within the secure element 280 on the communication device 110. In some embodiments, the mobile application 272 may have exclusive access to the secure element 280.")
Flurscheim and Singh do not explicitly teach, however, Gadotti teaches:
wherein the user communication device (DTon) executes the validation application (AppVT) to receive the at least one item of personal data (Sgn, PIN) of the user who holds the user communication device (DTon), validate the transaction according to the at least one item of personal data entered by the user and the intermediate transaction execution data, and output a validation result.
(Gadotti US20130262309 at paras. 14-17) ("[0014] The payment or transaction process comprises optically capturing a barcode image by the initiating user's mobile communication device running the secure mobile payment mobile application; and decoding, by secure mobile payment mobile application, the barcode, and displaying the decoded information to the initiating user for verification. Optionally, the initiating user is allowed to make modification to the decoded information and/or append new data, such as a payment amount, to be transmitted to the central processing server by the secure mobile payment mobile application. The payment or transaction process further comprises prompting and receiving from the initiating user, by the secure mobile payment mobile application, his/her security PIN. The security PIN is then transmitted to the central processing server along with the decoded information, the modified data, appended new data, and identification data about the mobile communication device. [0015] The central processing server receives the information and verifies the authenticity of the information received and the initiating user using the initiating user's security PIN, the identification data about the mobile communication device, and data in initiating user account preserved in the central processing server. If the authenticity of the information received and the initiating user's identity are positively verified, the central processing server executes the transaction transferring funds from the eWallet of the payer user account to the eWallet of the payee or barcode originator user account. [0016] The central processing server then sends the execution result of the transaction to both the initiating user and the barcode originator by electronic mail, Internet instant message, SMS telecommunication message, communication message for the secure mobile payment mobile application, or machine-to-machine communication via its secure mobile payment server backend APIs. The transaction execution results and history logs are also shown in a user interface, such as a web site accessible and readable by a computing device or a mobile communication device running a web browser application, or any application software or firmware designed specifically to access and display web contents.")
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 Flurscheim, Singh, and Gadotti because it allows for improved system to provide a mobile payment method and system that can substitute the use of physical currency with the same level of ubiquity and ease of use. It is a further objective of the presently claimed invention to provide a mobile payment method and system that can leverage existing mobile communication devices and communication infrastructures, and does not require a dedicated infrastructure of hardware or network. It is still a further objective of the presently claimed invention to provide a mobile payment method and system having a higher level of security than existing payment methods and systems. (Gadotti at Abstract and paras. 1-7).
Response to Arguments
Applicant’s arguments filed on November 25, 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 and 3-15, Examiner notes the following:
Applicant argues that the amended claim features would integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “the technical features of claim 1, and similarly the technical features of claim 9, meaningfully limit the claim scope and improve security in transactions between terminals and communication devices.”
Examiner disagrees, however, and notes that the additional elements of the computer system - a “a transaction implementation terminal of a professional (TProf)”, “a user communication device (DTon)”, and “an additional transactional device (DTa)”, to perform the steps of “preparing”, “executing”, and “obtaining”, 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 transaction between a professional and user. The claims invoke the “a transaction implementation terminal of a professional (TProf)”, “a user communication device (DTon)”, and “an additional transactional device (DTa)”, to perform the steps of “preparing”, “executing”, and “obtaining” 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))
Furthermore, Examiner notes that, the stated problems of an insufficiently secure transaction process, and the claimed solution is not a technical solution. In the claim, the solution of preparing and transmitting transaction data is part of the abstract idea, as it is merely involves collecting, analyzing, and transmitting data to facilitate a transaction between a professional and user. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea. Applicant argues that “The specific arrangement-a professional terminal preparing intermediate data and sending it to a user communication device located near the terminal, the user communication device communicating with the terminal and an additional transaction device to execute the transaction and return an execution result to the terminal-reflects a non-conventional and non-generic arrangement of components that yields a technical security improvement in transactions between devices.”
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the additional elements do not amount to an inventive concept. The additional elements of the computer system - “a transaction implementation terminal of a professional (TProf)”, “a user communication device (DTon)”, and “an additional transactional device (DTa)”, to perform the steps of “preparing”, “executing”, and “obtaining” are merely generic computer components performing their well-known basic functions of collecting, analyzing, and transmitting data to facilitate a transaction between a professional and user. Per the specification, the recited computer elements are described only at a high level of generality, (see Spec. at paras. 8-9). 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))
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1 and 3-15, Examiner notes the following:
Applicant argues at page 13 that Singh is non-analogous art. Examiner disagrees and notes that claim 1 of the instant application broadly recites a method for securely processing a transaction between two computer devices, e.g., a payment card, bank card, or credit card. Similarly, Singh is directed to secure execution of financial transactions and authentication between devices, which is directly applicable to the transaction framework of claim 1. 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 Flurscheim and Singh because it allows for an improved system for authenticating a user, and allowing a user to employ a payment card as disclosed to perform banking activities, such as account management, bill payment, and fund transfer, through substantially any compatible device with a display. (Singh US20240095697 at Abstract and paras. 1-7).
Finally, Applicant argues at page 14 that Flurscheim fails to teach “outputting an execution result”, because Flurscheim transmits only personal data (Sgn, PIN) of the user. Examiner disagrees and notes that Flurscheim discloses at [0005]-[0007] that the user communication device scans a first machine readable code (first QR code) encoding transaction data (e.g., amount, merchant id, random number), which corresponds to the claimed intermediate transaction execution data. The communication device obtains financial credential data from the user communication device, and generates a cryptogram based on the first machine readable code data. The device then generates and outputs a second machine readable code (second QR code) encoding both the financial credential data and the cryptogram, and transmits this second code to the access device. This second machine readable code is produced by executing transaction processing on the user communication device using both intermediate transaction execution data and the personal data. (Flurscheim US20180204206 at paras. 5-7)
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