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 .
1. This action is responsive to the application filed on 06/30/2023.
2. Claims 1-20 are pending.
3. Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/30/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-12 are directed to one of the four statutory classes of invention (e.g. process, machine, manufacture, or composition of matter). The claims include a device, method, or product and is a method of assigning as task using a computer which is a process (Step 1: YES).
The Examiner has identified independent method Claim 1 as the claim that represents the claimed invention for analysis and is similar to independent method Claim 10 and Claim 11. Claim 1 recites the limitations of (abstract ideas highlighted in italics):
receiving an attestation request from the server, the attestation request being randomly selected by the server from a predetermined subset of a plurality of attestation requests, the attestation request defining a list of characteristics of the mobile terminal;
collecting a list of values for the mobile terminal, a value of the list of values corresponding to a characteristic of the list of characteristics of the mobile terminal transmitted by the server;
transmitting the list of values to the server;
and establishing a trusted communication channel with the server, the trusted communication channel being based on the list of values and a security level of the mobile terminal determined by the server on the basis of the list of values.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of mental process. Receiving a request to perform an action, collecting the information requested, and determining to perform an action based on the collected information (e.g., comparing the received information to a value) recites a mental process. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a mental process that can be performed by the human mind, including, for example, observations, evaluations, judgements, and opinions, then it falls within the “Mental Process” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The system in Claim 11 is just applying generic computer components (i.e., computer-based device) to the recited abstract limitations. Claim 10 is also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract)
Additionally, the limitations, under their broadest reasonable interpretation, cover performance of the limitation as mental processes. Requesting information, receiving said information, and then comparing it to a value in order to perform a function, recites a concept performed in the human mind. The claim encompasses a user simply using judgement and observation to compare traffic patterns/behaviors to determine if adjustment is needed using his/her mind. The mere nominal recitation of a generic device does not take the claim out of the mental processes grouping. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a concept performed in the human mind then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The system in Claim 11 is just applying generic computer components to the recited abstract limitations. Claims 5 and 11 is also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract)
This judicial exception is not integrated into a practical application. In particular, the claims only recite a method (Claim 1), a method (Claim 5), and a mobile terminal (claim 11). The computer hardware is recited at a high-level of generality (i.e., as a generic device performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore claims 1, 5, and 11 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Insert comment if appropriate, MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus claims 1, 5, and 11 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-4, 6-10, and 12 further define the abstract idea that is present in their respective independent claims 1, 5, and 11 and thus correspond to Mental Processes and hence are abstract for the reasons presented above. The dependent claims do not include any 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. Therefore, the claims 2-4, 6-10, and 12 are directed to an abstract idea. Thus, the claims 1-12 are not patent-eligible.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Dino Dai Zovi et al (US 20180005230 A1), hereinafter “Zovi”.
Regarding Claim 1, Zovi discloses a method for attesting a mobile terminal for implementing a payment application on the mobile terminal, the mobile terminal being configured to communicate with a server (Zovi, Abstract, establishing a secure communication channel between a payment object reader and a payment terminal by having a server determining whether a payment terminal has associated with an attestation ticket), the method being implemented by the mobile terminal and comprising:
receiving an attestation request from the server, the attestation request being randomly selected by the server from a predetermined subset of a plurality of attestation requests, the attestation request defining a list of characteristics of the mobile terminal (Zovi, Paragraph 0018, commands initiated by a server in order to detect any augmented tamper or fraud by using trust routines/commands, wherein the trust commands include varying levels of specificity and granularity including, but not limited to, hashing a portion of a software code, scanning memory of the payment entity, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on) based on reliably measured data or test criteria collected over a population of payment platforms or pre-set values determined by security experts);
collecting a list of values for the mobile terminal, a value of the list of values corresponding to a characteristic of the list of characteristics of the mobile terminal transmitted by the server (Zovi, Fig 6, Paragraphs 0193-0194, payment object reader obtains information and sends information to a server based on the attestation routine);
transmitting the list of values to the server (Zovi, Paragraph 0030, sending attestation ticket to prove that it is trusted and secure. Fig 6, Paragraphs 0195-0196, server receives the information (attestation data) and analyzes the attestation data using server test criteria and based on other sources of information);
and establishing a trusted communication channel with the server, the trusted communication channel being based on the list of values and a security level of the mobile terminal determined by the server on the basis of the list of values (Zovi, Paragraph 0018, After incorporation of the trust routine, a payment processing system (PPS) assigns the payment platform as trusted for a predetermined period of time and assigns an attestation ticket for all future interactions. Paragraphs 0197-0199, server determines whether there is a fraudulent transaction or tamper attempt being made. Providing approval message indicating that the transaction has been approved and including information regarding the processed transaction, and transmit the message to payment object reader via network and merchant device. Processing unit of payment object reader may process the transaction based on the approval message and the transaction processing instructions).
Regarding Claim 2, Zovi discloses the method according to claim 1 above, wherein the established trusted communication channel is secure (Zovi, Paragraphs 0169, 0208, establishing a secure session/connection).
Regarding Claim 3, Zovi discloses the method according to claim 1 above, further comprising the following, implemented after the establishment of the trusted communication channel:
reception of another attestation request from the server, the other attestation request being randomly selected by the server among the plurality of attestation requests, the other attestation request defining another list of characteristics of the mobile terminal (Zovi, Paragraphs 0028, 0062, attestation occurs periodically or at random time intervals and the attestation ticket is valid until it expires. Paragraph 0213, payment terminal sends request to payment server requesting to facilitate generation of attestation ticket. The attestation includes an attestation trigger, wherein the trigger varies or can be a combination of several triggers. Paragraphs 0216-0217, server sends attestation routines to terminal, wherein the attestation routine includes hashing a portion of a software code, scanning memory of the payment terminal, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on);
collection of another list of values for the mobile terminal, a value of the other list of values corresponding to a characteristic of the other list of characteristics of the mobile terminal (Zovi, Paragraphs 0216-0217, server sends attestation routines to terminal, wherein the attestation routine includes hashing a portion of a software code, scanning memory of the payment terminal, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on);
another transmission to the server of the other list of values (Zovi, Paragraph 0218, server receives information corresponding to the routines);
the communication channel being maintained or interrupted by the server depending on the other list of values (Zovi, Paragraph 0227, server generates a session certificate to set up a secure connection).
Regarding Claim 4, Zovi discloses the method according to claim 3 above, wherein the receiving another attestation request takes place at a time depending on a time randomly determined by the server (Zovi, Paragraphs 0028, 0062, attestation occurs periodically or at random time intervals and the attestation ticket is valid until it expires).
Regarding Claim 5, Zovi discloses a method for attesting a mobile terminal for implementing a payment application on the mobile terminal, the mobile terminal being configured to communicate with a server (Zovi, Abstract, establishing a secure communication channel between a payment object reader and a payment terminal by having a server determining whether a payment terminal has associated with an attestation ticket), the method being implemented by the server and comprising:
transmission to the mobile terminal of an attestation request, the attestation request being randomly selected by the server from a predetermined subset of a plurality of attestation requests, the attestation request defining a list of characteristics of the mobile terminal (Zovi, Paragraph 0018, commands initiated by a server in order to detect any augmented tamper or fraud by using trust routines/commands, wherein the trust commands include varying levels of specificity and granularity including, but not limited to, hashing a portion of a software code, scanning memory of the payment entity, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on) based on reliably measured data or test criteria collected over a population of payment platforms or pre-set values determined by security experts);
reception of a list of values, a value of the list of values corresponding to a characteristic of the list of characteristics of the mobile terminal transmitted by the server (Zovi, Paragraph 0030, sending attestation ticket to prove that it is trusted and secure. Fig 6, Paragraphs 0193-0194, payment object reader obtains information and sends information to a server based on the attestation routine, wherein the server receives the information (attestation data) and analyzes the attestation data using server test criteria and based on other sources of information);
determination of, on the basis of the list of values, a security level of the mobile terminal (Zovi, Paragraphs 0197-0199, server determines whether there is a fraudulent transaction or tamper attempt being made);
and establishment of a trusted communication channel based on the security level of the mobile terminal (Paragraphs 0197-0199, Providing approval message indicating that the transaction has been approved and including information regarding the processed transaction, and transmit the message to payment object reader via network and merchant device. Processing unit of payment object reader may process the transaction based on the approval message and the transaction processing instructions).
Regarding Claim 6, Zovi discloses the method according to claim 5 above, wherein the trusted communication channel is established according to the security level of the mobile terminal and according to a delay between the reception of the list of values and the transmission of the attestation request (Zovi, Paragraph 0063, communicating via an obfuscated and encrypted protocol, hereinafter referred to as “trusted channel,” for example, implemented on top of HTTP Secure (HTTPS). Paragraph 0064, validating a secure session. Paragraph 0067, sharing information of attestation ticket during a secure session. Paragraph 0169, communication interface establishes a secured connection. Paragraph 0174, attestation routine include instructions for identifying fraudulent transactions or tamper attempts based on communications received from payment terminal).
Regarding Claim 7, Zovi discloses the method according to claim 6 above, further comprising the following, implemented by the server (S) after the establishment of the communication channel:
transmission of at least one other attestation request, the at least one other attestation request being randomly selected by the server among the plurality of attestation requests (Zovi, Paragraph 0018, commands initiated by a server in order to detect any augmented tamper or fraud by using trust routines/commands, wherein the trust commands include varying levels of specificity and granularity including, but not limited to, hashing a portion of a software code, scanning memory of the payment entity, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on) based on reliably measured data or test criteria collected over a population of payment platforms or pre-set values determined by security experts);
reception of another list of values, a value from the other list of values corresponding to a characteristic from the other list of characteristics of the mobile terminal (Zovi, Paragraph 0030, sending attestation ticket to prove that it is trusted and secure. Fig 6, Paragraphs 0193-0194, payment object reader obtains information and sends information to a server based on the attestation routine, wherein the server receives the information (attestation data) and analyzes the attestation data using server test criteria and based on other sources of information);
another determining, based on the other list of values ,another security level of the mobile terminal (Zovi, Paragraphs 0197-0199, server determines whether there is a fraudulent transaction or tamper attempt being made);
and maintaining or interrupting the trusted communication channel depending on the other security level (Paragraphs 0197-0199, Providing approval message indicating that the transaction has been approved and including information regarding the processed transaction, and transmit the message to payment object reader via network and merchant device. Processing unit of payment object reader may process the transaction based on the approval message and the transaction processing instructions).
Regarding Claim 8, Zovi discloses the method according to claim 7 above, wherein the transmitting at least one other attestation request takes place at a time randomly determined by the server (Zovi, Paragraphs 0028, 0062, attestation occurs periodically or at random time intervals and the attestation ticket is valid until it expires).
Regarding Claim 9, Zovi discloses the method according to claim 7 above, wherein the communication channel is established according to the other security level of the mobile terminal and according to another delay between the reception of the other list of values and the transmission of the other attestation request (Zovi, Paragraph 0063, communicating via an obfuscated and encrypted protocol, hereinafter referred to as “trusted channel,” for example, implemented on top of HTTP Secure (HTTPS). Paragraph 0064, validating a secure session. Paragraph 0067, sharing information of attestation ticket during a secure session. Paragraph 0169, communication interface establishes a secured connection. Paragraph 0174, attestation routine include instructions for identifying fraudulent transactions or tamper attempts based on communications received from payment terminal).
Regarding Claim 10, Zovi discloses a non-transitory computer readable medium comprising a computer program stored thereon comprising a set of instructions configured to implement the method according to claim 1 above when the instructions are executed on a processor of the mobile terminal (Please see the rejection of claim 1 above. A non-transitory computer-readable recording medium is inherent in the operation of a method and therefore does not further limit the claimed subject matter).
Regarding Claim 11, Zovi discloses a mobile terminal (Zovi, Paragraph 0094, NFC device includes a smart phone, tablet, etc.) comprising:
at least one processor (Zovi, Paragraph 0094, smart phone contains a processor);
and at least one memory storing a set of instructions, the set of instructions being configured to implement a method for attesting a mobile terminal for implementing a payment application on the mobile terminal, when the instructions are executed on the at least one processor of the mobile terminal, the mobile terminal being configured to communicate with a server (Zovi, Abstract, establishing a secure communication channel between a payment object reader and a payment terminal by having a server determining whether a payment terminal has associated with an attestation ticket. Paragraph 0059, NFC device contains memory), the method comprising:
receiving an attestation request from the server, the attestation request being randomly selected by the server from a predetermined subset of a plurality of attestation requests, the attestation request defining a list of characteristics of the mobile terminal (Zovi, Paragraph 0018, commands initiated by a server in order to detect any augmented tamper or fraud by using trust routines/commands, wherein the trust commands include varying levels of specificity and granularity including, but not limited to, hashing a portion of a software code, scanning memory of the payment entity, checking for jail-breaking of the software code, gathering metadata of a mounted file system, and so on) based on reliably measured data or test criteria collected over a population of payment platforms or pre-set values determined by security experts);
collecting a list of values for the mobile terminal, a value of the list of values corresponding to a characteristic of the list of characteristics of the mobile terminal transmitted by the server (Zovi, Fig 6, Paragraphs 0193-0194, payment object reader obtains information and sends information to a server based on the attestation routine);
transmitting the list of values to the server (Zovi, Paragraph 0030, sending attestation ticket to prove that it is trusted and secure. Fig 6, Paragraphs 0195-0196, server receives the information (attestation data) and analyzes the attestation data using server test criteria and based on other sources of information);
and establishing a trusted communication channel with the server ,the trusted communication channel being based on the list of values and a security level of the mobile terminal determined by the server on the basis of the list of values (Zovi, Paragraph 0018, After incorporation of the trust routine, a payment processing system (PPS) assigns the payment platform as trusted for a predetermined period of time and assigns an attestation ticket for all future interactions. Paragraphs 0197-0199, server determines whether there is a fraudulent transaction or tamper attempt being made. Providing approval message indicating that the transaction has been approved and including information regarding the processed transaction, and transmit the message to payment object reader via network and merchant device. Processing unit of payment object reader may process the transaction based on the approval message and the transaction processing instructions).
Regarding Claim 12, Zovi discloses a non-transitory computer readable medium comprising a computer program stored thereon comprising a set of instructions configured to implement the method according to claim 5 when the instructions are executed on a processor of the server (Please see the rejection of claim 5 above. A non-transitory computer-readable recording medium is inherent in the operation of a method and therefore does not further limit the claimed subject matter).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. All the references listed on 892 are related to the subject matter of establishing secure connections for making payments using smartphones.
Some of the prior art include:
US 20050039057 A1, which discloses a method for authenticating a user using query directed passwords.
US 20180330360 A1, which discloses a method of credit payment based on card emulation of mobile terminal.
US 20190207953 A1, which discloses a method of logical validation of devices against fraud and tampering.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAVIER O GUZMAN whose telephone number is (571)270-0588. The examiner can normally be reached Monday - Friday 8 am to 4 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/JAVIER O GUZMAN/ Primary Examiner, Art Unit 2496
Prosecution Insights