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 .
Status of Claims
This is the first office action on the merits in response to the application filed on 06/21/2025.
Claims 1-20 are currently pending and have been examined.
Priority
Acknowledge is made that the instant application is a divisional on US Application 17/726,402 filed on 04/21/2022. Acknowledge is made of applicant’s claim for priority based on PCT Application PCT/CN2021/076438 filed on 02/10/2021. Acknowledgment is made of applicant's claim for foreign priority based on an application filed in People’s Republic of China on 03/23/2020.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Under Step 1 of the Section 101 analysis, claim 1 is directed to a method, claim 8 is directed to a payment authentication server, and claim 15 is directed to a non-transitory computer-readable storage medium (a process, an apparatus, and an article of manufacture).
Under Step 2A Prong One, Claims 1, 8, and 15 recite: receiving an authentication request transmitted by the biometric payment device based on a signature and device information, the signature being generated by the biometric payment device according to a key and the device information, and the key being a key recognized by the payment authentication server and acquired by communicating with the payment authentication server through a manufacturer device during a production phase; verifying the signature according to the device information; generating an authentication result of the biometric payment device according to a verification result; and returning the authentication result to the biometric payment device, to implement a biometric payment based on biometric data transmitted by the authenticated biometric payment device.
Claims 1, 8, and 15 as drafted include language (see underlined language above) that recite an abstract idea of receive a request, verify a signature, generate a result, and return the result, which falls under certain methods of organizing human activity (i.e., fundamental economic principles, specifically mitigating risk).
Under Step 2A Prong Two, the additional claim element(s), considered individually, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The additional claim elements(s) “a payment authentication server, comprising: a memory and a processor,” “a non-transitory computer-readable storage medium,” and “signature,” generally “apply” the concept of receive a request, verify a signature, generate a result, and return the result. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform the abstract idea. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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.
Under Step 2A Prong Two, the additional claim element(s), considered in combination, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a payment authentication server, comprising: a memory and a processor, a non-transitory computer-readable storage medium, and signature amounts to no more than applying the abstract idea of receive a request, verify a signature, generate a result, and return the result. Mere instructions to apply an exception using a generic component cannot provide an inventive concept. The claim is not patent eligible.
Under Step 2B, the additional claim element(s), considered individually and in combination, do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself for similar reasons outlined under Step 2A Prong Two.
A similar analysis can be applied to dependent claims 2, 9, and 16 which claim “wherein acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase comprises: acquiring a public key of the biometric payment device uploaded by the manufacturer device, wherein the public key and a private key corresponding to the public key are generated according to a key production instruction, and the public key is exported to the manufacturer device” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 3, 10, and 17 which claims “wherein acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase comprises: acquiring multi-factor device information of the biometric payment device uploaded by the manufacturer device; generating a dynamic link library file storing the key of the biometric payment device according to the multi-factor device information; and transmitting the dynamic link library file to the manufacturer device, the dynamic link library file being used for instructing the manufacturer device to burn the dynamic link library file to the biometric payment device” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 4, 11, and 18 which claims “wherein the dynamic link library file is a shared object (SO) library file” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 5, 12, and 19 which claims “wherein the verifying the signature according to the device information comprises: acquiring the corresponding public key, and verifying the signature according to the device information and the public key” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 6, 13, and 20 which claims “obfuscating and reinforcing the dynamic link library file storing the key” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 7 and 14 which claims “wherein the dynamic link library file is a shared object (SO) library file, and a code of the SO library file is obfuscated and reinforced at the payment authentication server before burning to the biometric payment device” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 102(a)(1)
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 (i.e., changing from AIA to pre-AIA ) 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 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.
Claims 1-2, 5, 8-9, 12, 15-16, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hu (US 20170148029).
Regarding Claims 1, 8, and 15, Hu teaches receiving an authentication request transmitted by the biometric payment device based on a signature and device information (Paragraph 0059 teaches upon receiving a payment request carrying third signature information), the signature being generated by the biometric payment device according to a key and the device information (Paragraphs 0054-0058 teach the payment verification server receives a second payment function provisioning request uploaded by the user device and carrying a user public key and second signature information, wherein the second signature information is obtained by signing specific content by the user device with an application private key of the user device; the second payment function provisioning request may be sent after the user device sends the first payment function provisioning request, and does not need to be sent to the device verification server; the second payment function provisioning request is used to apply to the payment verification server for provisioning of the payment function for the user device; the payment verification server verifies the second signature information based on the application public key of the user device; when the verification of the second signature information by the payment verification server is successful, the payment verification server stores the user public key of the user device; after the above verification process, the payment verification server may store the user public key of the user device, so that the subsequent payment process may be verified using the user public key of the user device), and the key being a key recognized by the payment authentication server and acquired by communicating with the payment authentication server through a manufacturer device during a production phase (Paragraphs 0040-0042 teach a device verification server has the biological recognition information-based payment function registered thereon for the payment verification server; a payment application may be registered by an application operator on a device verification server, which may provision the biological recognition information-based payment function, so that a third party's application registered on the device verification server can use the payment function for transactions; the device verification server stores a device public key of the user device; Paragraph 0043 teach the user device has a public key and a private key; the device public key of the user device may be stored in the device verification server before the user device leaves the factory; this pair of keys is closely and uniquely related to the user device and can be used to verify the authenticity of the user device; after the user device leaves the factory, an application key pair and a user key pair may be generated based on a preset algorithm. The application key pair may comprise an application public key and an application private key); verifying the signature according to the device information (Paragraph 0059 teaches the payment verification server verifies the third signature information based on the user public key of the user device); generating an authentication result of the biometric payment device according to a verification result (Paragraph 0059 teaches when the verification of the third signature information is successful the payment verification server executes the payment request); and returning the authentication result to the biometric payment device, to implement a biometric payment based on biometric data transmitted by the authenticated biometric payment device (Paragraph 0059 teaches when the verification of the third signature information is successful the payment verification server executes the payment request).
Regarding Claim 1, Hu teaches an authentication method of a biometric payment device, performed by a payment authentication server (Paragraph 0039 teaches FIG. 2 is a flow chart illustrating interactions in the architecture of the above payment verification system).
Regarding Claim 8, Hu teaches a payment authentication server, comprising: a memory and a processor, the memory storing a computer program, and the processor, when executing the computer program, being configured to perform operations (Paragraph 0077 teaches FIG. 5 is a block diagram of a payment verification apparatus 500 according to an exemplary embodiment; for example, the apparatus 500 may be provided as a server; as shown in FIG. 5, the apparatus 500 comprises: a processing component 522 which further comprises one or more processors; and memory resources represented by a memory 532 for storing instructions executable by the processing component 522, such as applications; the applications stored in the memory 532 may comprise one or more modules, each module corresponding to a group of instructions; in addition, the processing component 522 is configured to execute instructions to perform the above payment verification method).
Regarding Claim 15, Hu teaches a non-transitory computer-readable storage medium, storing a computer program, the computer program, when executed by a processor of a payment authentication server, causing the processor to perform operations (Paragraph 0077 teaches memory resources represented by a memory 532 for storing instructions executable by the processing component 522, such as applications; the applications stored in the memory 532 may comprise one or more modules, each module corresponding to a group of instructions).
Regarding Claims 2, 9, and 16, Hu teaches all the limitations of claims 1, 8, and 15 above; and Hu further teaches wherein acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase comprises: acquiring a public key of the biometric payment device uploaded by the manufacturer device, wherein the public key and a private key corresponding to the public key are generated according to a key production instruction, and the public key is exported to the manufacturer device (Paragraph 0043-0046, 0048, 0051, and 0053 teach the user device has a public key and a private key; the device public key of the user device may be stored in the device verification server before the user device leaves the factory; this pair of keys is closely and uniquely related to the user device and can be used to verify the authenticity of the user device; after the user device leaves the factory, an application key pair and a user key pair may be generated based on a preset algorithm; the application key pair may comprise an application public key and an application private key; upon receiving a first payment function provisioning request from the user device, the device verification server verifies first signature information carried by the first payment function provisioning request according to the device public key of the user device; the first payment function provisioning request may be sent by the user via a payment application operating on the user device; when the verification of the first signature information by the device verification server is successful, the device verification server sends a verification success message to the payment verification server; the payment verification server receives an application public key uploaded by the user device; upon receiving the verification success message sent by the device verification server, the payment verification server stores the application public key of the user device; as shown by the above steps, through preliminary verification of the user device, the device verification server stores the application public key of the user device in the payment verification server, so that exchange of keys between the device verification server at the device manufacturer's side and the payment verification server at the payment service provider's side is realized, thereby ensuring communication security between the two servers).
Regarding Claims 5, 12, and 19, Hu teaches all the limitations of claims 2, 9, and 16 above; and Hu further teaches wherein the verifying the signature according to the device information comprises: acquiring the corresponding public key, and verifying the signature according to the device information and the public key (Paragraphs 0058-0059 teach after the above verification process, the payment verification server may store the user public key of the user device, so that the subsequent payment process may be verified using the user public key of the user device; upon receiving a payment request carrying third signature information, the payment verification server verifies the third signature information based on the user public key of the user device; and when the verification of the third signature information is successful the payment verification server executes the payment request).
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 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20170148029) in view of Sun (US 20190036917).
Regarding Claims 3, 10, and 17, Hu teaches all the limitations of claims 1, 8, and 15 above; however, Hu does not explicitly teach wherein acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase comprises: acquiring multi-factor device information of the biometric payment device uploaded by the manufacturer device; generating a dynamic link library file storing the key of the biometric payment device according to the multi-factor device information; and transmitting the dynamic link library file to the manufacturer device, the dynamic link library file being used for instructing the manufacturer device to burn the dynamic link library file to the biometric payment device.
Sun from same or similar field of endeavor teaches wherein acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase comprises: acquiring multi-factor device information of the biometric payment device uploaded by the manufacturer device; generating a dynamic link library file storing the key of the biometric payment device according to the multi-factor device information; and transmitting the dynamic link library file to the manufacturer device, the dynamic link library file being used for instructing the manufacturer device to burn the dynamic link library file to the biometric payment device (Paragraphs 0062 teach the user equipment stores a device private key, which is stored and used by the token and key manager; a biometric authentication center server can obtain a correspondence between a device identity of the user equipment and a device public key of the user equipment locally or from another accessible network storage location; a device private key of user equipment is corresponding to its device public key; the device private key can be pre-stored on the user equipment before factory delivery; or the user equipment, the biometric authentication center server, or another network node generates a device private key and a corresponding device public key, and separately sends them to the user equipment and the biometric authentication center server for storage).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified Hu to incorporate the teachings of Sun for acquiring the key recognized by the payment authentication server by communicating with the payment authentication server through the manufacturer device during the production phase to comprise: acquiring multi-factor device information of the biometric payment device uploaded by the manufacturer device; generating a dynamic link library file storing the key of the biometric payment device according to the multi-factor device information; and transmitting the dynamic link library file to the manufacturer device, the dynamic link library file being used for instructing the manufacturer device to burn the dynamic link library file to the biometric payment device.
There is motivation to further combine Sun into Hu because the device private key pre-stored on the user equipment and the device public key pre-stored on the server are used to verify whether the user equipment is reliable, so the user equipment can securely register the correspondence among the device identity, the virtual account identity, the biometric authentication type, the biometric feature token, and the service public key into the authentication server, thereby improving identity registration security (Sun Paragraph 0045).
Claims 4, 6-7, 11, 13-14, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20170148029) in view of Sun (US 20190036917) in further view of Adelgren (US 20180012213).
Regarding Claims 4, 11, and 18, the combination of Hu and Sun teaches all the limitations of claims 3, 10, and 17 above; however, the combination does not explicitly teach wherein the dynamic link library file is a shared object (SO) library file.
Adelgren from same or similar field of endeavor teaches wherein the dynamic link library file is a shared object (SO) library file (Paragraph 0017 teaches this pre-certified payment application driver code can be an application programming interface (API) or a shared library stored in a memory, thus allowing for simple and easy integration with a POS application on general computing devices, including mobile devices).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hu and Sun to incorporate the teachings of Adelgren for the dynamic link library file to be a shared object (SO) library file.
There is motivation to combine Adelgren into the combination of Hu and Sun because the system enables more simplicity and easiness, more flexibility, and more security, in configuring a payment transaction processing system (Adelgren Paragraph 0017).
Regarding Claims 6, 13, and 20, the combination of Hu and Sun teaches all the limitations of claims 3, 10, and 17 above; however, the combination does not explicitly teach obfuscating and reinforcing the dynamic link library file storing the key.
Adelgren from same or similar field of endeavor teaches obfuscating and reinforcing the dynamic link library file storing the key (Paragraphs 0050 teaches the integration can be initiated by selecting a desired platform (e.g., a particular operating system), network and hardware, in a manner similar to a setup for a direct web services integration; a payment client system can include an installation module that can provide a user interface for such selection so that the installation module installs the payment application driver code on the payment client system; the payment application driver code can be a software development kit (SDK) that allows the creation of payment applications for POS applications; the SDK can be downloaded appropriate for a selected device manufacturer(s) of the payment client system in a compressed form; then, the SDK can be uncompressed and a framework file (e.g., a file listing APIs or software libraries in the SDK) can be imported to a project directory of the uncompressed SDK; in some implementations, a shared library of the payment application driver code can be built based on configuration files (e.g., the framework file, project file and information property list file).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hu and Sun to incorporate the teachings of Adelgren to obfuscate and reinforce the dynamic link library file storing the key.
There is motivation to combine Adelgren into the combination of Hu and Sun because the payment application driver code can provide the following advantages. The payment application driver code can be an SDK or an API or a shared library and therefore can be easy to install, similar to installation of a printer driver. The payment application driver code can be pre-certified, thereby decreasing a merchant's time to market. The payment application driver code can meet certain condition (e.g., no cardholder data is stored in merchant's environment) to reduce PCI Compliance scope and liability for merchants. The payment application driver code can be separately maintained (sometimes repaired) from POS applications, thereby incurring no ongoing maintenance costs (Adelgren Paragraph 0082).
Regarding Claims 7 and 14, the combination of Hu, Sun, and Adelgren teaches all the limitations of claims 6 and 13 above; however, the combination does not explicitly teach wherein the dynamic link library file is a shared object (SO) library file, and a code of the SO library file is obfuscated and reinforced at the payment authentication server before burning to the biometric payment device.
Adelgren further teaches wherein the dynamic link library file is a shared object (SO) library file, and a code of the SO library file is obfuscated and reinforced at the payment authentication server before burning to the biometric payment device (Paragraphs 0029 and 0050 teach the payment server includes a key manager which can be implemented in digital electronic circuitry, or in computer software embodied on a tangible medium, firmware, or hardware; the key manager can manage cryptographic keys, for example, generation, exchange, storing, use and replacement of cryptographic keys; in some implementations, the key manager can use a specific key management scheme, e.g., Derived Unique Key Per Transaction (DUKPT); the integration can be initiated by selecting a desired platform (e.g., a particular operating system), network and hardware, in a manner similar to a setup for a direct web services integration; a payment client system can include an installation module that can provide a user interface for such selection so that the installation module installs the payment application driver code on the payment client system; the payment application driver code can be a software development kit (SDK) that allows the creation of payment applications for POS applications; the SDK can be downloaded appropriate for a selected device manufacturer(s) of the payment client system in a compressed form; then, the SDK can be uncompressed and a framework file (e.g., a file listing APIs or software libraries in the SDK) can be imported to a project directory of the uncompressed SDK; in some implementations, a shared library of the payment application driver code can be built based on configuration files (e.g., the framework file, project file and information property list file).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hu, Sun, and Adelgren to incorporate the further teachings of Adelgren for the dynamic link library file to be a shared object (SO) library file, and a code of the SO library file is obfuscated and reinforced at the payment authentication server before burning to the biometric payment device.
There is motivation to further combine Adelgren into the combination of Hu, Sun, and Adelgren because of the same reasons listed above for claims 6 and 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ding et al. (WO 2017197974) teaches a biometric characteristic-based security authentication method, device and electronic equipment, said method comprising: a terminal obtaining a first biometric characteristic according to a received biometric authentication request; the terminal matching said first biometric characteristic to a pre-set second biometric characteristic, generating a match result; the terminal using a private key of the security credentials of the terminal to encrypt the match result and obtain first ciphertext data, said security credentials uniquely corresponding to said terminal; the terminal sending to an authenticator the first ciphertext data and public key credentials of the security credentials, said authenticator being a server or the terminal. The present invention is used to solve the problem of security risks in current identity authentication.
Chumbley (US 20200021448) teaches an improved account authentication using public-private key cryptography instead of passwords. Instead of registering a password and using that password to login to an account, an authentication server of an account provider registers a public key received from a user device. To authenticate the user device for logging into an account, the authentication server generates a challenge and encrypts using the registered public key. The encrypted challenge is sent to the user device, which can decrypt the challenge using the private key corresponding to the registered public key. The decrypted challenge is used for authentication instead of using a password. The private key corresponding to the public key is securely stored and not revealed to the authentication server.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699