DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant first attests that the specification has been amended at paragraph [0053], see page 16. The Examiner respectfully notes that after carefully reviewing the response filed 01/22/2026, there does not appear to be an amended specification or a request to amend the specification present in the formal reply. Therefore, the objection to the specification will be maintained until such an amendment is submitted.
Applicant’s arguments, see pages 16-17, filed 01/22/2026, with respect to the rejection of claims 1-20 under 35 U.S.C. § 112(a) have been fully considered. The rejection of claims 1-20 under 35 U.S.C. § 112(a) have been withdrawn in response to Applicant removing the claim language pertaining to the firmware being specified by one or more values of one or more programmable counters.
Applicant’s arguments, see pages 17-19, filed 01/22/2026, with respect to the rejection of claims 6, 9, 15-17, and 20 under 35 U.S.C. § 112(b) have been fully considered. The previous rejection of claims 6, 9, 15-17, and 20 under 35 U.S.C. § 112(b) have been withdrawn.
Applicant’s arguments, see pages 19-20, filed 01/22/2026, with respect to the rejection of claims 1-5, 10-11, 14-16, and 18-19 under 35 U.S.C. § 102(a)(2) have been fully considered. The rejection of claims 1-5, 10-11, 14-16, and 18-19 under 35 U.S.C. § 102(a)(2) have been withdrawn.
Applicant’s arguments, see page 20, filed 01/22/2026, with respect to the rejection of claims 6-9 under 35 U.S.C. § 103 have been fully considered. The rejection of claims 6-9 under 35 U.S.C. § 103 have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly discovered prior art.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0053] of the originally filed disclosure recites “In 502B, owner 402 evicts renter 404A from security processor 190, for example, by incrementing the value(s) one of one or more irreversible pointers or counters (e.g., 718A and 718B in FIG. 7) within security processor 190, …”. Figure 7 does not contain reference characters 718A or 718B.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 15, and 18:
Independent claims 1, 15, and 18 recite “write access for fuses is disabled”, “write access to one-time programmable memory for fuses is disabled… one-time programmable memory for fuses ”, and “write access to one-time programmable memory for fuses is disabled… one-time programmable memory for fuses” respectively. There is insufficient antecedent basis for these limitations reciting “fuses” in the claims.
Dependent claims fall together accordingly.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-5, 10-11, 14-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Osorio Lozano et. al. (US Publication No. 2022/0108018 A1) hereinafter Osorio in view of Soni et. al. (US Publication No. US 2022/0382873 A1) hereinafter Soni.
Regarding Claim 1, 15, and 18:
Claim 1. Osorio discloses a security processor, comprising: a core; and a memory coupled to the core, the memory configured with program instructions stored thereon that, upon execution by the core, cause the security processor to (Osorio [0017-0018], [0023-0029]): identify a first category of secure boot, of a plurality of categories of secure boot, performed to bootstrap an Information Handling System (IHS) (Osorio [0017-0019]), wherein the plurality of categories of secure boot comprise secure boot by owner security processor boot code associated with owner secure boot encryption keys stored in an owner slot of the security processor (Osorio [0017-0019]; [0030-0037] ownership management, ownership key management, owner boot stages), and secure boot by renter security processor boot code associated with renter secure boot encryption keys stored in a renter slot of the security processor (Osorio [0017-0019]; [0030-0037] ownership management, ownership key management, owner boot stages); boot the security processor based at least in part on the first category of secure boot (Osorio [0017-0019]; [0025-0027]; [0030-0034]), … from (i) an owner slot configured with stored owner secure boot encryption keys (Osorio [0017-0019]; [0030-0037] ownership management, ownership key management, owner boot stages) and (ii) a selected renter slot configured with stored renter secure boot encryption keys of one-time programmable memory of the security processor (Osorio [0017-0019]; [0030-0037] ownership management, ownership key management, owner boot stages), and wherein upon successful security processor boot, the security processor is configured to determine if a signature of an operating system (OS) is valid (Osorio [0052] signature and proper PKI verification of code partitions and software disclosed); in response to a determination the signature of the OS is valid: permit the IHS to boot the OS (Osorio [0052] signature and proper PKI verification of code partitions and software disclosed, [0055] “Further, the Device-Specific Identity Private Key may be used to attest to the authenticity of the boot process before kernel 208 execution. Before execution is handed over to the kernel 208, the DeviceSpecificIdentitySeed and the private portion of the Device-Specific Identity may be cleared to protect the lower-level software secrets from higher-level software. In doing so, the possibility of security attacks may be minimized.”, [0059] “In an aspect, validation of the DeviceSpecificRootKey progresses the boot process to the kernel 208 stage. If at any stage the derived key is deemed invalid, the boot process may be disabled and/or a security component of the embedded system may be alerted.”); derive a symmetric encryption key based upon the first category of secure boot (Osorio [0041] “In a cascading implementation, a new key can be derived from the previous key and a single root secret. In some cases, the new key is used as the previous key for an additional key derived from an additional root secret”).
Osorio does not explicitly disclose wherein the security processor boot code is validated based at least in part on a secure boot public key selected based on one or more values of at least two irreversible programmable counters configured in the security processor, … and evict the renter secure boot encryption keys from the security processor by: upon failure to initiate a secure boot process with the renter secure boot encryption keys stored in the selected renter slot, attempt to use another secure boot public key associated with a second entity to bootstrap the IHS; in response to the boot success or initiation with the other secure boot public key and a determination that the security processor is in an authorized factory environment, increment the one or more values of the at least two irreversible programmable counters to invalidate the selected renter slot, to exclude the renter secure boot encryption keys stored in the selected renter slot from subsequent secure boot key selection by the security processor, to provide control over the security processor to a subsequent renter with secure boot encryption keys stored in a subsequent renter slot of the security processor; and reset the security processor, wherein the security processor is configured to publish, to at least one of a host CPU domain or a Baseboard Management Controller (BMC) domain, a read-only register configured to indicate a type of secure boot last used to bootstrap the IHS, and wherein renter-type secure boot invokes a privilege profile with enabled access to peripherals or controllers while write access for fuses is disabled.
Soni teaches wherein the security processor boot code is validated based at least in part on a secure boot public key selected based on one or more values of at least two irreversible programmable counters configured in the security processor (Soni Figure 2, [0032-0033] “At reset, the RoT loads a boot manifest from a firmware storage device (e.g., a flash memory storage device) and confirms whether the representation of the owner's public key stored in the OTP fuse matches a representation within the boot manifest… If so, the boot manifest signature is verified using the owner's public key. If signature verification is successful, the boot manifest type (i.e., owner or tenant) is determined. The boot process then continues, as will be described below, based on the determined boot manifest type and on a parity of the value stored in the counter” [0051-0055] multiple fuse banks explicitly taught), … and evict the renter secure boot encryption keys from the security processor by: upon failure to initiate a secure boot process with the renter secure boot encryption keys stored in the selected renter slot, attempt to use another secure boot public key associated with a second entity to bootstrap the IHS (Soni [0059-0069] owner-tenant boot flow is described complete with failure to boot and determining if tenant or owner booting); in response to the boot success or initiation with the other secure boot public key and a determination that the security processor is in an authorized factory environment, increment the one or more values of the at least two irreversible programmable counters to invalidate the selected renter slot, to exclude the renter secure boot encryption keys stored in the selected renter slot from subsequent secure boot key selection by the security processor, to provide control over the security processor to a subsequent renter with secure boot encryption keys stored in a subsequent renter slot of the security processor (Soni [0053-0055] “As described herein, the value of the counter is incremented each time a tenancy is granted or revoked. The size of secure storage device 240 determines a maximum number of allowed tenancy transfers. For example, in a case that secure storage device 240 includes 512 bits of fuses, 256 tenancy transfers will be supported”; the broadest reasonable interpretation of “factory environment” as claimed includes using a secure component verification OR cryptography method OR certificate chain, [0059-0069] owner-tenant boot flow is described complete with public keys); and reset the security processor, wherein the security processor is configured to publish, to at least one of a host CPU domain or a Baseboard Management Controller (BMC) domain, a read-only register configured to indicate a type of secure boot last used to bootstrap the IHS (Soni Figure 2 and [0048] is a motherboard supporting discrete components and integrated circuit devices, including at least one CPU. Motherboard 200 and the components mounted thereon are also supported by power supply and cooling components as is known in the art; [0059] “FIG. 5 is a flow diagram of process 500 to verify a boot manifest and to select a boot flow according to some embodiments. Process 500 may be implemented in executable program code and/or in hardware. Such executable program code may be stored in an un-modifiable manner, such as within ROM 212 of RoT 210. Process 500 may be executed by one or more processing units (e.g., processors, processor cores) executing program code, including but not limited to RoT 210.”; [0057] owner manifest includes a flag that indicates a type of boot manifest being used that is read by the RoT), and wherein renter-type secure boot invokes a privilege profile with enabled access to peripherals or controllers while write access for fuses is disabled (Soni [0053-0055] “To maintain cryptographic security, secure storage device 240 must only be updatable by execution of the immutable code stored ROM 212. This code is initially executed upon platform boot, at which point RoT 210 may execute the code to increment the stored value as required by the execution logic. Once RoT 210 exits execution of the code of ROM 212, storage device 240 is locked to prevent any write access”).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the security processor disclosed by Osorio with the system of using a stored counter value and fuses to indicate owner or tenant booting modes as taught by Soni. The motivation for this combination would be to provide irrefutable cryptographic evidence of a change in hardware tenancy and thereby maintain trust and confidentiality of devices as explicitly highlighted by Soni (Soni [0027]).
Claims 15 and 18 recite substantially the same content and are therefore rejected under the same rationales. Osorio further discloses a memory storage device configured with program instructions stored thereon that, upon execution by an Information Handling System (IHS), cause the IHS to (Osorio [0024-0029]): … encrypt, with the symmetric encryption key, data that is locally retained by the IHS (Osorio [0025-0026] “In a specific example, the lowest-level of boot code or boot-ROM code is written or masked in ROM 116. By doing so, the boot code in the ROM 116, or the metal-mask ROM/boot-ROM, cannot be modified after the chip is manufactured. The non-modifiable nature of ROM 116 provides an assurance of authenticity in the boot-ROM.”), wherein the locally retained data comprises private or biometric user data or login data (Osorio [0017] “As discussed herein, these systems and methods provide various implementation details that may further secure against various types of physical level attacks by malicious actors attempting to gain access to software of the device or embedded system”; [0077] “The software may configure runtime lockable inputs as part of the secure boot implementation to fix the construction of identities and root keys in the key manager. Hardware secrets stored in OTP and flash may be scrambled to increase the difficulty of physical attacks. ROM extension updates may invalidate the silicon owner and silicon creator identities as well as the root keys. Lastly, the implementation may consider a software-based backup mechanism to mitigate security and/or certification issues with the main implementation. The backup mechanism may not rely on secrets from the main implementation”). Osorio further discloses a method (Osorio [0017-0022], claim 1) … encrypting data retained by the IHS with the encryption key (Osorio [0025-0026] “In a specific example, the lowest-level of boot code or boot-ROM code is written or masked in ROM 116. By doing so, the boot code in the ROM 116, or the metal-mask ROM/boot-ROM, cannot be modified after the chip is manufactured. The non-modifiable nature of ROM 116 provides an assurance of authenticity in the boot-ROM.”).
Independent claim 15 further recites and wherein owner-type secure boot invokes a second privilege profile with enabled write access to one-time programmable memory for fuses. This limitation is taught by the Soni reference (Soni [0032] if the owner’s public key stored in the OTP fuse matches a representation within the boot manifest, then the boot process continues based on the manifest type and a parity value stored in the counter; [0053-0055] “As described herein, the value of the counter is incremented each time a tenancy is granted or revoked”)
Independent claim 18 further recites wherein an endpoint device coupled to the host CPU domain or the BMC domain permits injection of a secret key only when the read-only register indicates owner-type secure boot, … and wherein owner-type secure boot invokes a second privilege profile with enabled write access to one-time programmable memory for fuses. These limitations are taught by the Soni reference at (Soni [0026] “Tenancy transfer according to some embodiments utilizes a grant token which is cryptographically bound to the specific hardware platform to prevent its usage on other hardware platforms” (emphasis added) and [0033] “For example, owner device 12 may install and configure applications on hardware platform 14 and execute those applications to utilize their functionality directly and/or to expose the functionality to public users for consumption over the Web”) and (Soni [0032] if the owner’s public key stored in the OTP fuse matches a representation within the boot manifest, then the boot process continues based on the manifest type and a parity value stored in the counter; [0053-0055] “As described herein, the value of the counter is incremented each time a tenancy is granted or revoked”) respectively.
Regarding Claim 2:
The combination of Osorio and Soni further teaches the security processor of claim 1 (Osorio [0017-0018], [0023-0029]), wherein the first category of secure boot performed comprises a category of secure boot, of the plurality of categories of secure boot, last performed (Osorio [0017-0019]).
Regarding Claim 3:
The combination of Osorio and Soni further teaches the security processor of claim 1 (Osorio [0017-0018], [0023-0029]), The security processor of claim 1, wherein to identify the first category of secure boot, the program instructions, upon execution by the core, cause the security processor to identify an entity, a category of the entity of a plurality of entity categories, or an order of the entity associated with a secure boot public key used to initiate the secure boot (Osorio [0017] and [0051-0052])), wherein the plurality of entity categories comprises at least an owner and a renter (Osorio [0017] and [0051-0052])).
Regarding Claim 4:
The combination of Osorio and Soni further teaches the security processor of claim 3 (Osorio [0017-0018], [0023-0029]), wherein the entity comprises a customer or brand of an Original Equipment Manufacturer (OEM) (Osorio [0017]).
Regarding Claim 5:
The combination of Osorio and Soni further teaches the security processor of claim 4 (Osorio [0017-0018], [0023-0029]), wherein to identify the entity, the category of the entity, or the order of the entity, the program instructions, upon execution, further cause the security processor to read the one or more values of the one or more programmable counters configured to be incremented upon an eviction of any customer or brand of the OEM from the security processor (Osorio [0076] “1. Factory time provisioned entropy (seed). 2. Hash function required to compress additional data into DRBG (additional_data or perso_string). 3. Global counter to keep track of key derivations (may require device lifetime key manager keygen counter, which can be implemented in software. This can be very difficult since the key derivation paths change per ownership transfer)”).
Regarding Claim 10:
The combination of Osorio and Soni further teaches the security processor of claim 5 (Osorio [0017-0018], [0023-0029]), wherein to derive the symmetric encryption key, the program instructions, upon execution by the core, further cause the security processor to select one of a plurality of seeds usable by an Advanced Encryption Standard (AES) hardware engine within the security processor (Osorio [0021] and [0045-0046] secrets may be fused; [0026] boot code may be fused) based, at least in part, upon the one or more values of the one or more programmable counters (Osorio [0076] “Global counter to keep track of key derivations (may require device lifetime key manager keygen counter, which can be implemented in software. This can be very difficult since the key derivation paths change per ownership transfer)”).
Regarding Claim 11:
The combination of Osorio and Soni further teaches the security processor of claim 10 (Osorio [0017-0018], [0023-0029]), wherein the plurality of seeds is fused into the security processor (Osorio [0021] and [0045-0046] secrets may be fused; [0026] boot code may be fused).
Regarding Claim 14:
The combination of Osorio and Soni further teaches the security processor of claim 5 (Osorio [0017-0018], [0023-0029]), wherein the program instructions, upon execution by the core, further cause the security processor to, in response to a rekeying command from the customer or brand, derive the symmetric encryption key based, at least in part, upon at least one additional input (Osorio [0022] may use multiple root secrets and require a vetted software environment; [0036] “KM_Derive may use one or more cryptographic operations to combine the multiple root secrets or other values in a cryptographically safe manner. These operations may include logical operations, comparators, concatenation or any other cryptographically safe operation.”).
Regarding Claims 16 and 19:
Claim 16. The combination of Osorio and Soni further teaches the memory storage device of claim 15 (Osorio [0024-0029]), wherein to identify the first category of secure boot, the program instructions, upon execution by IHS, further cause the IHS to read the one or more values of the one or more programmable counters associated with a number of evicted customers of an Original Equipment Manufacturer (OEM) (Osorio [0076] “Global counter to keep track of key derivations (may require device lifetime key manager keygen counter, which can be implemented in software. This can be very difficult since the key derivation paths change per ownership transfer)”).
Claim 19 recites substantially the same content and is therefore rejected under the same rationales.
Claim(s) 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Osorio and Soni as applied to claims 1-5, 10-11, 14-16, and 18-19 above, and further in view of Gorog et. al. (US Publication No. US 2022/0109667 A1) hereinafter Gorog.
Regarding Claim 6:
Osorio discloses the security processor of claim 5 (Osorio [0017-0018], [0023-0029]).
Osorio and Soni do not explicitly disclose wherein the eviction of the customer or brand is associated with a processed return, service, or warranty claim for the IHS in an authorized factory environment determined based at least in part on a digital electronic input.
Gorog teaches wherein the eviction of the customer or brand is associated with a processed return, service, or warranty claim for the IHS in an authorized factory environment determined based at least in part on a digital electronic input (Gorog [0051-0053]).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the security processor disclosed by Osorio with the system of using a stored counter value and fuses to indicate owner or tenant booting modes as taught by Soni, further with the IoT lifecycle provisioning taught by Gorog including customer or brand eviction being associated with a return, service, or warranty claim. The motivation for this combination would be to enable the processor to insert the set of secrets data corresponding to the target state onto the device, and seal the set of secrets data corresponding to the current state (Gorog [0052]).
Regarding Claim 7:
The combination of Osorio, Soni, and Gorog further teaches the security processor of claim 5 (Osorio [0017-0018], [0023-0029]), wherein the one or more values of the one or more programmable counters are usable by the security processor to identify a number of times the security processor has been shipped to a plurality of customers or brands (Gorog [0053]).
Regarding Claim 8:
The combination of Osorio, Soni, and Gorog further teaches the security processor of claim 5 (Osorio [0017-0018], [0023-0029]), wherein the one or more values of the one or more programmable counters are usable by the security processor to identify a number of times the IHS has been returned to the OEM (Gorog [0053]).
Regarding Claim 9:
The combination of Osorio, Soni, and Gorog further teaches the security processor of claim 5 (Osorio [0017-0018], [0023-0029]), wherein the one or more values of the one or more programmable counters are configured to identify a number of times the security processor has been provisioned or reprovisioned by the OEM (Gorog, [0022] “From time to time, as the device progresses throughout the supply chain, the possession of the device may be transferred between entities. To securely provision secrets at each stage of the supply chain as possession/ownership is transferred, the device can participate in a state transition process to transition from a first state to a second state (e.g., to elevate the device from a current state to a subsequent state, or revert the device from the current state to a previous state).”; [0053] “The API method “Read Manufacturer Programming Count” passes a properly formatted message from the brokering agent for the device and returns a current number of manufacturing programming counts. A manufacturing programming count is an openly-readable number corresponding to a number of times that the manufacturing programming method has been successfully completed.”), and wherein the number of times is determined based on the one or more values of the one or more programmable counters (Soni [0053-0055] “As described herein, the value of the counter is incremented each time a tenancy is granted or revoked. The size of secure storage device 240 determines a maximum number of allowed tenancy transfers. For example, in a case that secure storage device 240 includes 512 bits of fuses, 256 tenancy transfers will be supported”).
Claim(s) 12-13, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Osorio and Soni as applied to claims 1-5, 10-11, 14-16, and 18-19 above, and further in view of Luciani; Luis (US Publication No. US 2022/0188468 A1) hereinafter Luciani.
Regarding Claim 12:
Osorio discloses the security processor of claim 5 (Osorio [0017-0018], [0023-0029]).
Osorio and Soni do not explicitly disclose wherein to derive the symmetric encryption key, the program instructions, upon execution by the core, further cause the security processor to select one of a plurality of seeds usable by an Advanced Encryption Standard (AES) hardware engine within a Baseboard Management Controller (BMC) based, at least in part, upon the one or more values of the one or more programmable counters.
Luciani teaches wherein to derive the symmetric encryption key, the program instructions, upon execution by the core, further cause the security processor to select one of a plurality of seeds usable by an Advanced Encryption Standard (AES) hardware engine within a Baseboard Management Controller (BMC) based, at least in part, upon the one or more values of the one or more programmable counters (Luciani [0041] “For example, the BMC 102 can encrypt the information 106 by applying a public key. An entity that seeks to access the information 106 can decrypt the encrypted information by using a corresponding private key that is part of a public-private key pair. The technique used to encrypt information can be selected by the BMC 102. In some examples, the BMC 102 can use any of various different encryption techniques, such as Advanced Encryption Standard (AES) encryption, Rivest-Shamir-Adleman (RSA) encryption, Data Encryption Standard (DES) encryption, and so forth.”).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the security processor disclosed by Osorio with the system of using a stored counter value and fuses to indicate owner or tenant booting modes as taught by Soni, further with the secure memory and processor for protecting information in memory as taught by Luciani. The motivation for this combination would be to produce encrypted information that cannot be read by entities or users without an appropriate decryption key to decrypt the encrypted information. (Luciani, [0041]).
Regarding Claim 13:
The combination of Osorio, Soni, and Luciani further teaches the security processor of claim 12 (Osorio [0017-0018], [0023-0029]), wherein the plurality of seeds is fused into the security processor (Osorio [0021] and [0045-0046] secrets may be fused; [0026] boot code may be fused).
Regarding Claims 17 and 20:
Claim 17. The combination of Osorio, Soni, and Luciani further teaches the memory storage device of claim 15 (Osorio [0024-0029]), wherein the locally retained data comprises at least one of fingerprint data, facial recognition data, a username, or a password (Luciani [0042] “For example, the key 110 can be a private key that signs the information 106 to produce a digital signature that can be associated with the signed information. The digital signature can be used to verify the authenticity of the information 106 and/or verify an authenticity of a source of the information 106”; the broadest reasonable interpretation of at least a username or password includes user data (see Applicant’s originally filed specification paragraph [00143]) [0025] “The information 106 stored in the system memory 108 can include data (such as user data, application program data, or another type of data)”).
Claim 20 recites substantially the same content and is therefore rejected under the same rationales.
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
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 MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496 /JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496