DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. The Applicant filed Applicant’s Arguments/Remarks on 11/212025. Claims 1-5, 7, 9-13, and 26-27 are pending and are rejected for the reasons set forth below.
Claim Rejections - 35 USC § 101
3. 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.
4. Claims 1-5, 7, 9-13, and 26-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
5. Analysis:
Step 1: Statutory Category?: (is the claim(s) directed to a process, machine, manufacture or composition of matter?) - YES: In the instant case, claims 1-5, 7, 9-13 are directed to a method (i.e., process), claim 26 is directed to a non-transitory computer-readable storage medium (i.e., machine), and claim 27 is directed to a computer device (i.e., machine).
Regarding independent claim 1:
Step 2A - Prong 1: Judicial Exception Recited?: (is the claim(s) recited a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon) – YES: Independent claim 1 recites the at least following limitations of “detecting a facial recognition payment trigger event; obtaining a face image; performing identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtaining risk data of the user; obtaining risk data … ; determining, by using the risk data of the user, whether a payment risk of a transaction is controllable; and if yes, notifying the user that the user can leave.” These recited limitations of the claim, as drafted, under its broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they cover performance of the limitations in commercial interactions (including sales activities for performing a facial recognition payment of a user). Accordingly, the claim recites an abstract idea.
Step 2A - Prong 2: Integrated into a Practical Application?: (is the claim(s) recited additional elements that integrate the exception into a practical application of the exception) - NO: This judicial exception is not integrated into a practical application. In particular, independent claim 26 further to the abstract idea includes additional elements of “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network”. However, the additional elements recite generic computer components such as a computer, computing devices, a server, and/or software programing that are recited a high-level of generality that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself. Accordingly, the additional elements evaluated individually and in combination do not integrate the abstract idea into a practical application because they comprise or include limitations that are not indicative of integration into a practical application such as adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- See MPEP 2106.05(f). The claim is directed to an abstract idea.
2B: Claim provides an Inventive Concept?: (is the claim(s) recited additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception) - NO: The claim does not include additional elements 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 “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network” evaluated individually and in combination do not amount to more than a recitation of the words "apply it" (or an equivalent) or are not more than mere instructions to implement an abstract idea or other exception on a computer, or are not more than merely using a computer as a tool to perform an abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more - See MPEP 2106.05(f)(2). None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, the claim is patent-ineligible.
Regarding independent claim 26:
Step 2A - Prong 1: Judicial Exception Recited?: (is the claim(s) recited a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon) – YES: Independent claim 26 recites the at least following limitations of “detect a facial recognition payment trigger event; obtain a face image; perform identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtain risk data of the user; obtain risk data … ; determine, by using the risk data of the user, whether a payment risk of a transaction is controllable; and if yes, notify the user that the user can leave.” These recited limitations of the claim, as drafted, under its broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they cover performance of the limitations in commercial interactions (including sales activities for performing a facial recognition payment of a user). Accordingly, the claim recites an abstract idea.
Step 2A - Prong 2: Integrated into a Practical Application?: (is the claim(s) recited additional elements that integrate the exception into a practical application of the exception) - NO: This judicial exception is not integrated into a practical application. In particular, independent claim 26 further to the abstract idea includes additional elements of “a non-transitory computer-readable storage medium”, “a processor”, “a device”, “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network”. However, the additional elements recite generic computer components such as a computer, computing devices, a server, and/or software programing that are recited a high-level of generality that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself. Accordingly, the additional elements evaluated individually and in combination do not integrate the abstract idea into a practical application because they comprise or include limitations that are not indicative of integration into a practical application such as adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- See MPEP 2106.05(f). The claim is directed to an abstract idea.
2B: Claim provides an Inventive Concept?: (is the claim(s) recited additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception) - NO: The claim does not include additional elements 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 “a non-transitory computer-readable storage medium”, “a processor”, “a device”, “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network” evaluated individually and in combination do not amount to more than a recitation of the words "apply it" (or an equivalent) or are not more than mere instructions to implement an abstract idea or other exception on a computer, or are not more than merely using a computer as a tool to perform an abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more - See MPEP 2106.05(f)(2). None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, the claim is patent-ineligible.
Regarding independent claim 27:
Step 2A - Prong 1: Judicial Exception Recited?: (is the claim(s) recited a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon) – YES: Independent claim 27 recites the at least following limitations of “detect a facial recognition payment trigger event; obtain a face image; perform identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtain risk data of the user; obtain risk data …; determine, by using the risk data of the user, whether a payment risk of a transaction is controllable; and if yes, notify the user that the user can leave.” These recited limitations of the claim, as drafted, under its broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas as they cover performance of the limitations in commercial interactions (including sales activities for performing a facial recognition payment of a user). Accordingly, the claim recites an abstract idea.
Step 2A - Prong 2: Integrated into a Practical Application?: (is the claim(s) recited additional elements that integrate the exception into a practical application of the exception) - NO: This judicial exception is not integrated into a practical application. In particular, independent claim 27 further to the abstract idea includes additional elements of “a computing device”, “a memory”, “a processor”, “a non-transitory computer-readable storage medium”, “a processor”, “a device”, “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network”. However, the additional elements recite generic computer components such as a computer, computing devices, a server, and/or software programing that are recited a high-level of generality that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself. Accordingly, the additional elements evaluated individually and in combination do not integrate the abstract idea into a practical application because they comprise or include limitations that are not indicative of integration into a practical application such as adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- See MPEP 2106.05(f). The claim is directed to an abstract idea.
2B: Claim provides an Inventive Concept?: (is the claim(s) recited additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception) - NO: The claim does not include additional elements 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 “a computing device”, “a memory”, “a processor”, “a non-transitory computer-readable storage medium”, “a processor”, “a device”, “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network” evaluated individually and in combination do not amount to more than a recitation of the words "apply it" (or an equivalent) or are not more than mere instructions to implement an abstract idea or other exception on a computer, or are not more than merely using a computer as a tool to perform an abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more - See MPEP 2106.05(f)(2). None of the additional elements taken individually or when taken as an ordered combination amount to significantly more than the abstract idea. Accordingly, the claim is patent-ineligible.
Dependent claims 2-5, 7, and 9-13 have been given the full two-part analysis, analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually and in combination, are also held to be patent-ineligible under 35 U.S.C. 101.
Dependent claim 2: simply provides further definition to “the detecting a facial recognition payment trigger event” recited in independent claim 1. Simply stating that wherein the detecting the facial recognition payment trigger event comprises any one of the following: detecting that a face appears on a screen of a facial recognition device; detecting a tap input on a facial recognition payment button, wherein the facial recognition payment button is located on the screen of the facial recognition device; detecting a key operation that is entered by using a physical keyboard and that corresponds to facial recognition payment; detecting that an eye of a face gazes at the screen of the facial recognition device; detecting that a human body movement corresponding to facial recognition payment appears on the screen of the facial recognition device; and detecting a voice password corresponding to facial recognition payment amounts to no more than merely applying generic computer components and/or software programing to implement the abstract idea on a computer (i.e., a screen of a facial recognition device).Thus, the dependent claim does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 3: simply provides further definition to “after the obtaining a face image, and before the performing identity verification on a user based on the obtained face image” recited in independent claim 1. Simply stating that wherein after the obtaining a face image, and before the performing identity verification on a user based on the obtained face image, any one of the following processing further is performed: performing attention recognition based on the obtained face image, and if it is determined that attention is on a screen of the facial recognition device, continuing to perform the step of performing identity verification on the user based on the obtained face image; if at least two face images are currently obtained, calculating spatial location data of a face corresponding to each face image relative to the screen of the facial recognition device, calculating a probability corresponding to each face image by using the calculated spatial location data, determining a face image with a maximum probability value as a face image of the user, and performing identity verification on the user based on the face image of the user; and if it is detected that a human torso appears on the screen of the facial recognition device, determining whether the human torso and the obtained face image belong to a same user, and if yes, continuing to perform the step of performing identity verification on a user based on the obtained face image amounts to no more than merely applying generic computer components and/or software programing to implement the abstract idea on a computer (i.e., a screen of a facial recognition device).Thus, the dependent claim does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 4: simply provides further definition to “the performing identity verification on a user based on the obtained face image” recited in independent claim 1. Simply stating that wherein the performing identity verification on a user based on the obtained face image comprises: performing liveness detection based on the obtained face image; and if the liveness detection succeeds, performing facial recognition based on the obtained face image, determining whether a user identity corresponding to the face image can be recognized, and if yes, enabling the identity verification on the user succeeds does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 5: simply provides further definition to “the obtaining risk data of the user” recited in independent claim 1. Simply stating that wherein the obtaining risk data of the user comprises: obtaining user risk data in N dimensions, wherein N is a positive integer; and performing normalization processing on user risk data in each dimension, to obtain a user risk vector in the dimension; and the determining, by using the risk data, whether a payment risk of a transaction is controllable comprises: calculating a user risk value by using the following equation: … and if the user risk value is greater than a first predetermined value, determining that the payment risk of the transaction is controllable does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 7: simply provides further definition to “the obtaining risk data of a facial recognition device” recited in independent claim 1. Simply stating that wherein the obtaining risk data of the facial recognition device comprises: obtaining the risk data of the facial recognition device in M dimensions, wherein M is a positive integer; and performing normalization processing on risk data of the facial recognition device in each dimension, to obtain a risk vector of the facial recognition device in the dimension; and the determining, by using the risk data of the facial recognition device, whether the payment risk of the transaction is controllable comprises: calculating a device risk value by using the following equation: … and if the device risk value is 1, determining that the payment risk of the transaction is controllable amounts to no more than merely applying generic computer components and/or software programing to implement the abstract idea on a computer (i.e., a facial recognition device).Thus, the dependent claim does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 9: simply provides further definition to “before the notifying the user that the user can leave” recited in independent claim 1. Simply stating that wherein before the notifying the user that the user can leave, the method further comprises: obtaining risk data of a merchant; and determining, by using the risk data of the merchant, whether the payment risk of the transaction is controllable does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 10: simply provides further definition to “the obtaining risk data of a merchant” recited in dependent claim 9. Simply stating that wherein the obtaining risk data of a merchant comprises: obtaining merchant risk data in I dimensions, wherein I is a positive integer; and performing normalization processing on merchant risk data in each dimension, to obtain a merchant risk vector in the dimension; and the determining, by using the risk data of the merchant, whether the payment risk of the transaction is controllable comprises: calculating a merchant risk value by using the following equation: … and if the merchant risk value is greater than a second predetermined value, determining that the payment risk of the transaction is controllable does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 11: simply provides further definition to “the risk data of the merchant” recited in dependent claim 9. Simply stating that wherein the risk data of the merchant comprise any one of the following: historical behavior data of the merchant, credit status data of the user, and service level data of the merchant does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 12: simply provides further definition to “the risk data of the user” recited in independent claim 1. Simply stating that wherein the risk data of the user comprise any one of the following: historical behavior data of the user, consumption capability statistics data of the user, credit status data of the user, and a Zhima credit score of the user does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Dependent claim 13: simply provides further definition to “after it is determined, by using the risk data, that the payment risk of the transaction is controllable” recited in independent claim 1. Simply stating that wherein after it is determined, by using the risk data, that the payment risk of the transaction is controllable, the method further comprises: performing deduction processing by using account information of the user, and if the deduction does not succeed, performing deduction from an account of a pre-established facial recognition payment fund pool; and/or after it is determined, by using the risk data, that the payment risk of the transaction is not controllable, the method further comprises: performing deduction processing by using account information of the user; and if the deduction does not succeed, notifying the user that the deduction fails; or if the deduction succeeds, notifying the user that the user can leave does not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application, a play interface) that results in the claim being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Claim Rejections - 35 USC § 102
6. 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.
7. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
8. Claims 1-5, 7, 9-13, and 26-27 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fiterman (U.S. Pub. No. 2018/0349912), hereinafter, “Fiterman”.
Claim 1 –
Fiterman discloses:
a facial recognition payment method, comprising: detecting a facial recognition payment trigger event; obtaining, by a camera on a facial recognition device, a face image; performing identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtaining risk data of the user ;obtaining risk data of the facial recognition device comprising at least one of: risk data of a software environment of the facial recognition device, risk data of a software environment of the facial recognition device, or risk data of a communication network; determining, by using the risk data of the user and the risk data of the facial recognition device, whether a payment risk of a transaction is controllable; and if yes, notifying the user that the user can leave (Fiterman, [0035], [0036], [0037], [0040], [0057], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203 … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata”, see also Figure 1).
Claim 2 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein the detecting a facial recognition payment trigger event comprises any one of the following: detecting that a face appears on a screen of the facial recognition device; detecting a tap input on a facial recognition payment button, wherein the facial recognition payment button is located on the screen of the facial recognition device; detecting a key operation that is entered by using a physical keyboard and that corresponds to facial recognition payment; detecting that an eye of a face gazes at the screen of the facial recognition device; detecting that a human body movement corresponding to facial recognition payment appears on the screen of the facial recognition device; and detecting a voice password corresponding to facial recognition payment (Fiterman, [0035], [0036], [0037], [0040], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203 … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata”, see also Figure 1).
Claim 3 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein after the obtaining a face image, and before the performing identity verification on a user based on the obtained face image, any one of the following processing further is performed: performing attention recognition based on the obtained face image, and if it is determined that attention is on a screen of the facial recognition device, continuing to perform the step of performing identity verification on the user based on the obtained face image; if at least two face images are currently obtained, calculating spatial location data of a face corresponding to each face image relative to the screen of the facial recognition device, calculating a probability corresponding to each face image by using the calculated spatial location data, determining a face image with a maximum probability value as a face image of the user, and performing identity verification on the user based on the face image of the user; and if it is detected that a human torso appears on the screen of the facial recognition device, determining whether the human torso and the obtained face image belong to a same user, and if yes, continuing to perform the step of performing identity verification on a user based on the obtained face image (Fiterman, [0035], [0036], [0037], [0040], [0057], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203 … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 4 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein the performing identity verification on a user based on the obtained face image comprises: performing liveness detection based on the obtained face image; and if the liveness detection succeeds, performing facial recognition based on the obtained face image, determining whether a user identity corresponding to the face image can be recognized, and if yes, enabling the identity verification on the user succeeds (Fiterman, [0035], [0036], [0037], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203”, see also Figure 1).
Claim 5 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein the obtaining risk data of the user comprises: obtaining user risk data in N dimensions, wherein N is a positive integer; and performing normalization processing on user risk data in each dimension, to obtain a user risk vector in the dimension; and the determining, by using the risk data, whether a payment risk of a transaction is controllable comprises: calculating a user risk value by using the following equation, where 01,constanta>1wherein RU(X") represents the user risk value, represents a user risk vector in an nth dimension, and n is any integer from 1 to N; and if the user risk value is greater than a first predetermined value, determining that the payment risk of the transaction is controllable (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 7 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein the obtaining risk data of the facial recognition device comprises: obtaining risk data of the facial recognition device in M dimensions, wherein M is a positive integer; and performing normalization processing on risk data of the facial recognition device in each dimension, to obtain a risk vector of the facial recognition device in the dimension; and the determining, by using the risk data of the facial recognition device, whether the payment risk of the transaction is controllable comprises: calculating a device risk value by using the following equation: wherein R represents the device risk value, x, represents a device risk vector in an mth dimension, a value of x is 0 or 1, and m is any integer from 1 to M; and if the device risk value is 1, determining that the payment risk of the transaction is controllable (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 9 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein before the notifying the user that the user can leave, the method further comprises: obtaining risk data of a merchant; and determining, by using the risk data of the merchant, whether the payment risk of the transaction is controllable (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 10 –
Fiterman discloses the method according to claim 9, as shown above.
Fiterman further discloses:
wherein the obtaining risk data of a merchant comprises: obtaining merchant risk data in I dimensions, wherein I is a positive integer; and performing normalization processing on merchant risk data in each dimension, to obtain a merchant risk vector in the dimension; and the determining, by using the risk data of the merchant, whether the payment risk of the transaction is controllable comprises: calculating a merchant risk value by using the following equation:where01, constant b > 1 wherein Rm(x) represents the merchant risk value, xr represents a merchant risk vector in an ith dimension, andiis any integer from1toI;andif the merchant risk value is greater than a second predetermined value, determining that the payment risk of the transaction is controllable (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 11 –
Fiterman discloses the method according to claim 9, as shown above.
Fiterman further discloses:
wherein the risk data of the merchant comprise any one of the following: historical behavior data of the merchant, credit status data of the user, and service level data of the merchant (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 12 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein the risk data of the user comprise any one of the following: historical behavior data of the user, consumption capability statistics data of the user, credit status data of the user, and a Zhima credit score of the user (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 13 –
Fiterman discloses the method according to claim 1, as shown above.
Fiterman further discloses:
wherein after it is determined, by using the risk data, that the payment risk of the transaction is controllable, the method further comprises: performing deduction processing by using account information of the user, and if the deduction does not succeed, performing deduction from an account of a pre-established facial recognition payment fund pool; and/or after it is determined, by using the risk data, that the payment risk of the transaction is not controllable, the method further comprises: performing deduction processing by using account information of the user; and if the deduction does not succeed, notifying the user that the deduction fails; or if the deduction succeeds, notifying the user that the user can leave (Fiterman, [0040], [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 assigns a composite risk score to the pending transaction using the risk analytics application 202, which has determined that the transaction can be authorized. The payment processing application 204 conducts a preauthorization of the customer's stored payment method, and if successful, queries the transaction database 205 to retrieve face image data, a payment token, and other transaction metadata”, see also Figure 1).
Claim 26 –
Fiterman discloses:
a non-transitory computer-readable storage medium having stored therein instructions that, in response to execution by a processor of a device, cause the device to: detect a facial recognition payment trigger event; obtain, by a camera on a facial recognition device, a face image; perform identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtain risk data of the user; obtain risk data of the facial recognition device comprising at least one of: risk data of a software environment of the facial recognition device, risk data of a software environment of the facial recognition device, or risk data of a communication network; determine, by using the risk data of the user and the risk data of the facial recognition device, whether a payment risk of a transaction is controllable; and if yes, notify the user that the user can leave (Fiterman, [0035], [0036], [0037], [0040], [0057], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203 … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata”, see also Figure 1).
Claim 27 –
Fiterman discloses:
a computing device, comprising a memory and a processor, wherein the memory stores executable instructions that, in response to execution by the processor, cause the computing device to: detect a facial recognition payment trigger event; obtain, by a camera on a facial recognition device, a face image; perform identity verification on a user based on the obtained face image; after the identity verification on the user succeeds, obtain risk data of the user; obtain risk data of the facial recognition device comprising at least one of. risk data of a software environment of the facial recognition device, risk data of a software environment of the facial recognition device, or risk data of a communication network; determine, by using the risk data of the user and the risk data of the facial recognition device, whether a payment risk of a transaction is controllable; and if yes, notify the user that the user can leave (Fiterman, [0035], [0036], [0037], [0040], [0057], “The sensor system 300 is an optional system located at a merchant location that assists in detecting the presence of registered users … The sensor system 300 is responsible for performing any of the following functions: 1) transmitting collected face image data to the back end 200 for user identification via the facial recognition application 203; 2) transmitting location identifiers received from sensors 301 to the location manager application 101; 3) receiving customer location data from the location manager application 101. The merchant sensor system 300 may be connected to the payment manager 400 by the network 600 or may be directly integrated into the software and hardware available in the payment manager 400 … The sensor processor 302 includes software to locally cache customer images that are sent to the facial recognition application 203 … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata … The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata”, see also Figure 1).
Response to Applicant’s Arguments
9. 35 U.S.C. §101 Rejections: Applicant’s arguments with respect to amended claims 1-5, 7, 9-13, and 26-27 that are rejected under 35 U.S.C. 101 have been considered but they are not persuasive because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Applicant’s Argument: From Applicant Arguments/Remarks, with respect to Step 2A, Applicant asserts that claim 1 as amended is not directed to a judicial exception to patent eligibility, such as an abstract idea. Amended independent claim 1 recites "A facial recognition payment method, comprising: detecting a facial recognition payment trigger event; obtaining, by a camera on a facial recognition device, a face image; performing identity verification on a user based on the obtained face image … and if yes, notifying the user that the user can leave." Even assuming arguendo that the claim recites a judicial exception (Step 2A, Prong One), the claim also recites additional elements that integrate the alleged judicial exception into a practical application (Step 2A, Prong Two). For example, the claim requires obtaining a face image "by a camera on a facial recognition device," an operation that cannot be abstractly performed but requires a particular physical device … Furthermore, the claimed invention uses "the risk data of the facial recognition device," along with other risk data, to determine "whether a payment risk of a transaction is controllable." According to the specification, this determination makes it possible to reduce the user's waiting time in a transaction when the risk associated with the user and the facial recognition device is controllable … In short, by reciting limitations relating to the risk data of the user and the risk data of the facial recognition device, the claim as amended makes an improvement to the technology of payment based on facial recognition. Accordingly, the limitations in question integrate the alleged judicial exception into a practical application, thereby making the amended claim patent-eligible under Step 2A, Prong Two. With this determination, it is not necessary to proceed to the Step 2B analysis. For at least the above reasons, amended independent claims 1, 26, and 27, and all claims depending therefrom, are patent-eligible under 35 U.S.C. § 101. Accordingly, Applicant respectfully requests withdrawal of these rejections (See Applicant Arguments/Remarks Pages 1-3).
In response to Applicant’s arguments, Examiner respectfully disagrees and submits that independent claims 1, 26, and 27 further to the abstract idea includes additional elements of “a camera”, “a facial recognition device”, “a software environment of the facial recognition device”, and “a communication network”. However, the additional elements recite generic computer components such as a computer, computing devices, a server, and/or software programing that are recited a high-level of generality that merely perform, conduct, carry out, implement, and/or narrow the abstract idea itself. Accordingly, the additional elements evaluated individually and in combination do not integrate the abstract idea into a practical application because they comprise or include limitations that are not indicative of integration into a practical application such as adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea -- See MPEP 2106.05(f). See details of Claim Rejections - 35 USC § 101 of claims 1-5, 7, 9-13, and 26-27 in the section above.
10. 35 U.S.C. §102 Rejections: Applicant’s arguments with respect to claims 1-5, 7, 9-13, and 26-27 that are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fiterman (U.S. Pub. No. 2018/0349912), hereinafter, “Fiterman”, have been considered but they are not persuasive (See Applicant Arguments/Remarks Pages 3-4). The Examiner notes that Fiterman teaches the amended limitations of independent claims 1, 26, and 27 as in (Fiterman, [0057], “The back end 200 may assign a composite risk score to the pending transaction using the risk analytics application 202. The risk analytics application 202 evaluates a transaction based on a variety of data inputs, including, but not limited to, facial recognition data, location data, credit data, social media data, customer transaction history, customer behavior, customer demographics, transaction details, date/time, and other metadata”, see also Figure 1). See details of Claim Rejections - 35 USC § 102 of claims 1-5, 7, 9-13, and 26-27 in the section above
Relevant Prior Art
11. The prior art made of record and not relied upon are considered pertinent to applicant's disclosure:
Agarwal et al. (U.S. Pub. No. 2015/0348045) teach systems and methods for implementing transactions based on facial recognition.
Vedula et al. (U.S. Pub. No. 2020/0193401) teach platform-agnostic account access using facial recognition.
Conclusion
12. 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.
13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Liz Nguyen whose telephone number is (571) 272-5414. The examiner can normally be reached on Monday to Friday 8:00 A.M to 5:00 P.M.
14. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matthew Gart, can be reached on (571) 272-3955. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
15. Information regarding the status of an application may be obtained from the Patent Center system (visit: https://patentcenter.uspto.gov). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (USA or CANADA) or (571) 272-1000.
/LIZ P NGUYEN/
Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696