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 .
Detailed Action
Office Action is in response to the reply filed by Applicant on 8/25/2026. Claims 1-20 are pending. This Office Action is Final.
Response to Arguments
A) Applicant’s arguments with respect to claim(s) 1 and 9 have been considered but are moot because the new ground of rejection does not rely on the same combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim 17 was not amended similarly to claims 1 and 9. As such, the arguments are moot then they pertain to claim 17. Examiner has re-written the rejections of claims 17-20 in full to reflect the previous rejection which was not argued.
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 (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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-3, 7-11, 15 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Manohar et al. (US 2018/0019986) in view of Violleau et al. (US 2016/0232335).
As per claim 1, Manohar teaches an electronic device comprising:
memory storing instructions; and at least one processor, comprising processing circuitry, connected to the memory, wherein the instructions, when executed by the at least one processor individually and/or collectively (Manohar, Paragraph 0024 recites “The server 18 is a computing device including at least one processor and a memory and is configured to execute computer executable instructions. The processor is preferably an intelligent device, e.g., a personal computer central processing unit (CPU) such as those made by Intel® Corporation or AMD®, a microcontroller, an application specific integrated circuit (ASIC), etc. The memory includes a non-transitory, processor-readable storage medium that stores processor executable and processor-readable instructions (i.e., software code) that are configured to, when executed, cause the processor to perform various functions as may be described herein (although the description may refer only to the processor performing the functions).”),
cause the electronic device to: receive a user credential through a first authenticator application executed in a secure area of the electronic device, and perform a user authentication procedure in the first authenticator application in the secure area, based on the user credential, based on the user authentication procedure being successfully completed in the first authenticator application in the secure area, issue an access token in the first authenticator application in the secure area (Manohar, Paragraph 0043 recites “The user authenticator unit 270 can include a user authenticator HAL 372 and a user authenticator trusted application 374. The user authenticator HAL 372 can be configured to provide an interface between the user authenticator trusted application 374, which is configured to operate within the TEE of the processor 220 and one or more hardware components of the computing device 11 that can be used to authenticate the user of the computing device 11. For example, the user authenticator HAL 372 can be configured to interface with the biometric sensors 263 and/or the I/O device interface 265 of the computing device 11. The user authenticator trusted application 374 can be configured to obtain user authentication information for the computing device 11 via the user authenticator HAL 372. The user authenticator trusted application 374 can be configured to make a determination whether the user authentication information provided by the user of the computing device 11 matches user authentication information bound to an authentication key. The user authenticator trusted application 374 can be configured receive a user authentication request from the SKM 290. The user authentication request can include user authentication information bound to an authentication key associated with an RP application 350 for which the SKM 290 is attempting to authenticate the user, such as biometric information and/or a password or PIN. The location authenticator trusted application 384 can be configured obtain user authentication information via the user authenticator HAL 372 responsive to the user authentication request and to make a determination whether the user authentication information obtained from a user of the computing device matches user authentication information bound to the authentication key. The user authenticator trusted application 374 can be configured generate an authentication token and to pass the authentication token to the SKM 290 responsive to the authentication information matching the authentication information bound to an authentication key. The user authenticator trusted application 374 can also be configured to generate and send an error message to the SKM 290 responsive to the authentication information not matching the authentication information bound to an authentication key.”).
But fails to teach transmit the access token issued in the first authenticator application in the secure area to an external electronic device through a second authenticator application executed in a non-secure area of the electronic device.
However, in an analogous art Violleau teaches transmit the access token issued in the first authenticator application in the secure area to an external electronic device through a second authenticator application executed in a non-secure area of the electronic device (Violleau, Paragraph 0042 recites “The trusted kernel/trusted functions (212) may also allow for communication with trusted peripherals (232) in the device hardware (230). Trusted peripherals (232) may include input/output devices associated with a trusted user interface (UI) session (236). In one or more embodiments, a trusted UI session may be initiated by the REE (216) and is a secure UI that may be used to bind a user to the device, and by extension, the TEE (204) of the device. A user-binding trusted application may be dedicated to a given service provider and/or to a group of service providers. Further, although not shown in FIG. 2, the TEE may be configured to provide trusted storage of data, keys, authorization tokens, etc. such that no unauthorized internal and/or external entity may access, copy, or modify the data contained in trusted storage. For example, the device on which a TEE is configured may include one or more types of available storage, of which a portion may be provided solely to the TEE for storing sensitive information.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Violleau’s mechanism for enforcing user-specific and device-specific security constraints in an isolated execution environment on a device in view of Manohar’s user privacy protected location-based authentication on mobile devices because it offers the advantage of a more secure way of permitting sensitive operations based on verification to be facilitated.
As per claim 2, Manohar in combination with Violleau teaches the electronic device of claim 1, Manohar further teaches wherein the non-secure area is implemented in a rich execution environment (REE), and the secure area is implemented in a trusted execution environment (TEE) (Manohar, Paragraph 0035 recites “The processor 220 can support a system-wide trusted execution environment (TEE) security platform. Example implementations of the TEE include, but are not limited to, Open Source TEE (OP-TEE) and QUALCOMM® Secure Execution Environment (QSEE), Intel® TXT, and AMD® Secure Execution Environment. The TEE security platform partitions hardware and software resources of the processor 220 and the memory 230 to create a secure world processing environment and a non-secure world processing environment. The non-secure world processing environment is typically referred to as a Rich Execution Environment (REE). The TEE and the REE can be embedded in one processor or in separate processors. The TEE is a security focused execution environment designed to store and manipulate sensitive information and to keep this information private from the REE. The REE interacts with the user of the computing device 11 via a high level operating system (HLOS) (e.g., iOS®, Android®, Windows®, Blackberry®, Chrome®, Linux®, Symbian®, Palm®, etc.).”).
As per claim 3, Manohar in combination with Violleau teaches the electronic device of claim 1, Manohar further teaches wherein the instructions, when executed by the at least one processor individually and/or collectively, cause the electronic device to receive an authentication request message from the external electronic device through the second authenticator application in the non-secure area (Manohar, Paragraph 0043 recites “The user authenticator unit 270 can include a user authenticator HAL 372 and a user authenticator trusted application 374. The user authenticator HAL 372 can be configured to provide an interface between the user authenticator trusted application 374, which is configured to operate within the TEE of the processor 220 and one or more hardware components of the computing device 11 that can be used to authenticate the user of the computing device 11. For example, the user authenticator HAL 372 can be configured to interface with the biometric sensors 263 and/or the I/O device interface 265 of the computing device 11. The user authenticator trusted application 374 can be configured to obtain user authentication information for the computing device 11 via the user authenticator HAL 372. The user authenticator trusted application 374 can be configured to make a determination whether the user authentication information provided by the user of the computing device 11 matches user authentication information bound to an authentication key. The user authenticator trusted application 374 can be configured receive a user authentication request from the SKM 290. The user authentication request can include user authentication information bound to an authentication key associated with an RP application 350 for which the SKM 290 is attempting to authenticate the user, such as biometric information and/or a password or PIN. The location authenticator trusted application 384 can be configured obtain user authentication information via the user authenticator HAL 372 responsive to the user authentication request and to make a determination whether the user authentication information obtained from a user of the computing device matches user authentication information bound to the authentication key. The user authenticator trusted application 374 can be configured generate an authentication token and to pass the authentication token to the SKM 290 responsive to the authentication information matching the authentication information bound to an authentication key. The user authenticator trusted application 374 can also be configured to generate and send an error message to the SKM 290 responsive to the authentication information not matching the authentication information bound to an authentication key.”).
As per claim 7, Manohar in combination with Violleau teaches the electronic device of claim 1, Manohar further teaches wherein the first authenticator application in the secure area includes: an App user interface (UI) module comprising circuitry and/or instructions executed by the circuitry configured to provide a UI; an authentication module comprising circuitry and/or instructions executed by the circuitry configured to perform the user authentication procedure; a token generation module comprising circuitry and/or instructions executed by the circuitry configured to issue the access token; and a resource server module comprising circuitry and/or instructions executed by the circuitry configured to transmit user information and the access token to an external server (Manohar, Paragraph 0043 recites “The user authenticator unit 270 can include a user authenticator HAL 372 and a user authenticator trusted application 374. The user authenticator HAL 372 can be configured to provide an interface between the user authenticator trusted application 374, which is configured to operate within the TEE of the processor 220 and one or more hardware components of the computing device 11 that can be used to authenticate the user of the computing device 11. For example, the user authenticator HAL 372 can be configured to interface with the biometric sensors 263 and/or the I/O device interface 265 of the computing device 11. The user authenticator trusted application 374 can be configured to obtain user authentication information for the computing device 11 via the user authenticator HAL 372. The user authenticator trusted application 374 can be configured to make a determination whether the user authentication information provided by the user of the computing device 11 matches user authentication information bound to an authentication key. The user authenticator trusted application 374 can be configured receive a user authentication request from the SKM 290. The user authentication request can include user authentication information bound to an authentication key associated with an RP application 350 for which the SKM 290 is attempting to authenticate the user, such as biometric information and/or a password or PIN. The location authenticator trusted application 384 can be configured obtain user authentication information via the user authenticator HAL 372 responsive to the user authentication request and to make a determination whether the user authentication information obtained from a user of the computing device matches user authentication information bound to the authentication key. The user authenticator trusted application 374 can be configured generate an authentication token and to pass the authentication token to the SKM 290 responsive to the authentication information matching the authentication information bound to an authentication key. The user authenticator trusted application 374 can also be configured to generate and send an error message to the SKM 290 responsive to the authentication information not matching the authentication information bound to an authentication key.”).
As per claim 8, Manohar in combination with Violleau teaches the electronic device of claim 1, Manohar further teaches wherein the user credential includes at least one of a password, a fingerprint, a face, voice, an iris, a palm, or a finger vein pattern, identifying an owner of the user credential (Manohar, Paragraph 0043 recites “The user authenticator unit 270 can include a user authenticator HAL 372 and a user authenticator trusted application 374. The user authenticator HAL 372 can be configured to provide an interface between the user authenticator trusted application 374, which is configured to operate within the TEE of the processor 220 and one or more hardware components of the computing device 11 that can be used to authenticate the user of the computing device 11. For example, the user authenticator HAL 372 can be configured to interface with the biometric sensors 263 and/or the I/O device interface 265 of the computing device 11. The user authenticator trusted application 374 can be configured to obtain user authentication information for the computing device 11 via the user authenticator HAL 372. The user authenticator trusted application 374 can be configured to make a determination whether the user authentication information provided by the user of the computing device 11 matches user authentication information bound to an authentication key. The user authenticator trusted application 374 can be configured receive a user authentication request from the SKM 290. The user authentication request can include user authentication information bound to an authentication key associated with an RP application 350 for which the SKM 290 is attempting to authenticate the user, such as biometric information and/or a password or PIN. The location authenticator trusted application 384 can be configured obtain user authentication information via the user authenticator HAL 372 responsive to the user authentication request and to make a determination whether the user authentication information obtained from a user of the computing device matches user authentication information bound to the authentication key. The user authenticator trusted application 374 can be configured generate an authentication token and to pass the authentication token to the SKM 290 responsive to the authentication information matching the authentication information bound to an authentication key. The user authenticator trusted application 374 can also be configured to generate and send an error message to the SKM 290 responsive to the authentication information not matching the authentication information bound to an authentication key.”).
Regarding claim 9, claim 9 is directed to a method associated with the device of claim 1. Claim 9 is of similar scope to claim 1 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a method associated with the device of claim 2. Claim 10 is of similar scope to claim 2 and is therefore rejected under similar rationale.
Regarding claim 11, claim 11 is directed to a method associated with the device of claim 3. Claim 11 is of similar scope to claim 3 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a similar method associated with the device of claim 7 respectively. Claim 15 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a similar method associated with the device of claim 8 respectively. Claim 16 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
Claim(s) 4 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Manohar et al. (US 2018/0019986) and Violleau et al. (US 2016/0232335) and in further view of Amar (US 2020/0311299).
As per claim 4, Manohar in combination with Violleau teaches the electronic device of claim 1, but fails to teach wherein the first authenticator application in the secure area includes at least one of an integrity measurement value, a public key of a service provider, or a certificate chain for a public key of a certified authority (CA).
However, in an analogous art Amar teaches wherein the first authenticator application in the secure area includes at least one of an integrity measurement value, a public key of a service provider, or a certificate chain for a public key of a certified authority (CA) (Amar, Paragraph 0049 recites “The Identity and Profiling System 120 would receive that request from the bank. In some embodiments, the Identity and Profiling System 120 may authenticate the bank by verifying the entity identifier. For instance, the entity identifier can be sent to a certificate authority to verify (e.g., if the entity identifier is a public key). The Identity and Profiling System 120 may then check to see if the user's phone number exists in the records of the Identity and Profiling System 120 (e.g., if it exists in a data store). If the user's phone number exists in the records, that means the user has already signed up with the Identity and Profiling System 120 and the requested information has likely been collected and stored.”)
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use, Amar’s Secure identity and profiling system with Manohar’s user privacy protected location-based authentication on mobile devices because using a Certificate Authority (CA) enhances online security, builds trust, and ensures the authenticity of digital communications.
Regarding claim 12, claim 12 is directed to a method associated with the device of claim 4. Claim 12 is of similar scope to claim 4 and is therefore rejected under similar rationale.
Claim(s) 5 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Manohar et al. (US 2018/0019986) and Violleau et al. (US 2016/0232335) and in further view of Juriasingani (US 2018/0144146).
As per claim 5, Manohar in combination with Violleau teaches the electronic device of claim 1 but fails to teach further comprising a remote monitoring and management (RMM) implemented in the secure area, configured to manage a stage page table for the secure area, and manage a CPU context of a realm.
However, in an analogous art Juriasingani teaches further comprising a remote monitoring and management (RMM) implemented in the secure area, configured to manage a stage page table for the secure area, and manage a CPU context of a realm (Juriasingani, Paragraph 0012 recites “Also, in some embodiments, one or more of the unique private keys can also be established/loaded after manufacturing outside of the factory (e.g., by the customer, or by a Remote Monitoring and Management (RMM) server component (hereinafter referred to as a “customer identity”). Accordingly, a customer can supplement the at factory or manufacturer identity with their own customer identity.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Juriasingani’s printer identity and security with Manohar’s user privacy protected location-based authentication on mobile devices because it offers the advantage of being able to manage secure memory areas remotely.
Regarding claim 13, claim 13 is directed to a similar method associated with the device of claim 5 respectively. Claim 13 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Manohar et al. (US 2018/0019986) and Violleau et al. (US 2016/0232335) and in further view of Sahita et al. (US 2022/0222358).
As per claim 6, Manohar in combination with Violleau teaches the electronic device of claim 1, but fails to teach wherein the memory includes a first storage and a second storage, wherein the first storage includes a sealing key, and wherein the second storage includes a user credential, a subscription status, a user profile, and an encryption key, encrypted based on the sealing key.
However, in an analogous art Sahita teaches wherein the memory includes a first storage and a second storage, wherein the first storage includes a sealing key, and wherein the second storage includes a user credential, a subscription status, a user profile, and an encryption key, encrypted based on the sealing key (Sahita, Paragraph 0035 recites “As illustrated in FIG. 3, a system 300 includes global orchestration (such operations by an orchestrator) 302 and virtual machine manager (VMM) 308 for a system 300. In some embodiments, the system 300 further includes a cloning and escrow service (CES) trust domain (TD) 304, including an escrow and cloning policy, to enable a hibernated state of a TD or enclave, to perform operations including quote verification and generating sealing keys for TDs and enclaves, and to perform escrow and cloning policy enforcement in connection with the cloning of TEEs. For simplicity of illustration, FIG. 3 generally refers to trust domains (TDs), but embodiments also include secure enclaves.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Sahita’s scalable cloning and replication for trusted execution environments with Manohar’s user privacy protected location-based authentication on mobile devices because it offers the advantage of securing and protecting data within a trusted execution environment (TEE).
Regarding claim 14, claim 14 is directed to a similar method associated with the device of claim 6 respectively. Claim 14 is similar in scope to claim 6, respectively, and are therefore rejected under similar rationale.
Claim(s) 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US 2019/0334718) in view of Violleau et al. (US 2016/0232335).
As per claim 17, Li teaches a non-transitory computer-readable storage medium
storing one or more programs comprising instructions which, when executed by at least one processor of an electronic device individually or collectively (Li, Paragraph 0157 recites “Steps of methods or algorithms described in the embodiments disclosed in this specification may be implemented by hardware, a software module executed by a processor, or a combination thereof. The software module may reside in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.”),
cause the electronic device to: obtain a user credential corresponding to a user input through a first authenticator application executed in a secure area; perform a user authentication procedure in the first authenticator application in the secure area, based on the user credential (Li, Paragraph 0013 recites “In a possible implementation, the sending, by the at least one second application on the terminal, a second request message to the first application server includes: receiving, by the terminal, user-input personal identification information, and when the terminal determines that the user-input personal identification information is consistent with personal identification information stored in the terminal, sending, by the at least one second application on the terminal, the second request message to the first application server.”);
based on the user authentication procedure being successfully completed in the first authenticator application in the secure area, issue an access token in the first authenticator application in the secure area (Li, Paragraph 0089 recites “For example, step 204 specifically includes: The second application on the terminal sends a fifth request message to the first application, where the fifth request message is used for requesting the first application server to authorize the second application to obtain the resource access permission of the first application server. The fifth request message includes the account of the first application that is bound to the second application. If the first application logs into a plurality of accounts simultaneously, the user may select one of the accounts to generate the fifth request message. The first application checks for an account associated with the first application, to confirm that an access token associated with the account of the first application exists. The first application obtains the service public key (or the service public key and one challenge value) of the first application from the TEE operating environment of the terminal, and generates a digital signature for the access token (or for the access token and the one challenge value) by using the service private key of the first application.”).
But fails to teach transmit the access token issued in the first authenticator application in the secure area to an external electronic device through a second authenticator application executed in a non-secure area.
However, in an analogous art Violleau transmit the access token issued in the first authenticator application in the secure area to an external electronic device through a second authenticator application executed in a non-secure area (Violleau, Paragraph 0087 recites “After the authorization token is generated, the authorization token is transmitted, by the authorization server (716) via the Internet (710), to a trusted application executing in the TEE (706) of the smart phone as a part of a larger Secure Bank application that includes portions in both the TEE (706) and the REE (704) of the smart phone. The authorization token is encrypted before being sent, and therefore includes a digital signature which may be used to decrypt the authorization token.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Violleau’s mechanism for enforcing user-specific and device-specific security constraints in an isolated execution environment on a device in view of Li’s Application Program Authorization Method, Terminal, And Server because it offers the advantage of a more secure way of permitting sensitive operations based on verification to be facilitated.
As per claim 18, Li in combination with Violleau teaches the non-transitory computer-readable storage medium of claim 17, Violleau further teaches wherein the non-secure area is implemented in a rich execution environment (REE), and the
secure area is implemented in a trusted execution environment (TEE) (Violleau, Paragraph 0087 recites “After the authorization token is generated, the authorization token is transmitted, by the authorization server (716) via the Internet (710), to a trusted application executing in the TEE (706) of the smart phone as a part of a larger Secure Bank application that includes portions in both the TEE (706) and the REE (704) of the smart phone. The authorization token is encrypted before being sent, and therefore includes a digital signature which may be used to decrypt the authorization token.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Violleau’s mechanism for enforcing user-specific and device-specific security constraints in an isolated execution environment on a device in view of Li’s Application Program Authorization Method, Terminal, And Server because it offers the advantage of a more secure way of permitting sensitive operations based on verification to be facilitated.
As per claim 19, Li in combination with Violleau teaches the non-transitory computer-readable storage medium of claim 17, Violleau further teaches wherein the instructions, when executed by the at least one processor individually and/or
collectively, cause the electronic device to receive an authentication request message from the external electronic device through the second authenticator application in the non-secure area (Violleau, Paragraph 0086 recites “Once the authorization server (716) receives the request from Secure Bank (712), the authorization server then generates the authorization token (not shown). The authorization token includes a binding code constraint that includes the binding code, which may be encrypted, that was received from Secure Bank and which was provided to the authenticated user by Secure Bank.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Violleau’s mechanism for enforcing user-specific and device-specific security constraints in an isolated execution environment on a device in view of Li’s Application Program Authorization Method, Terminal, And Server because it offers the advantage of a more secure way of permitting sensitive operations based on verification to be facilitated.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US 2019/0334718) and Violleau et al. (US 2016/0232335) and in further view of Amar (US 2020/0311299).
As per claim 20, Li in combination with Violleau the non-transitory computer-readable storage medium of claim 17, but fails to teach wherein the first authenticator application in the secure area includes at least one of an integrity measurement value, a public key of a service provider, or a certificate chain for a public key of a
certified authority (CA).
However, in an analogous art Amar teaches wherein the first authenticator application in the secure area includes at least one of an integrity measurement value, a public key of a service provider, or a certificate chain for a public key of a
certified authority (CA) (Amar, Paragraph 0049 recites “The Identity and Profiling System 120 would receive that request from the bank. In some embodiments, the Identity and Profiling System 120 may authenticate the bank by verifying the entity identifier. For instance, the entity identifier can be sent to a certificate authority to verify (e.g., if the entity identifier is a public key). The Identity and Profiling System 120 may then check to see if the user's phone number exists in the records of the Identity and Profiling System 120 (e.g., if it exists in a data store). If the user's phone number exists in the records, that means the user has already signed up with the Identity and Profiling System 120 and the requested information has likely been collected and stored.”)
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use, Amar’s Secure identity and profiling system with Li’s Application Program Authorization Method, Terminal, And Server because using a Certificate Authority (CA) enhances online security, builds trust, and ensures the authenticity of digital communications.
Regarding claims 12 and 20, claims 12 and 20 are directed to a method and a non-transitory computer-readable storage medium associated with the device of claim 4. Claims 12 and 20 are of similar scope to claim 4, and are therefore rejected under similar rationale.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached at 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Prosecution Insights