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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/09/2026 has been entered.
Response to Arguments
Applicant’s arguments filed 02/09/2026, with respect to the rejections of independent claims 1, 6, and 12 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Gopal, Chhabra, and Duflot, in addition to a newly applied reference from Chhabra et al. (US 20190102322 A1), hereinafter ‘322. Specifically, ‘322 teaches the newly added limitations “wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines”.
Regarding Applicant’s argument beginning on P. 7/9 of Applicant Arguments that the clearCount value taught by Duflot is not sufficient to read on the claimed on-apparatus counter, Examiner respectfully disagrees. Applicant cites the passage from Duflot: “the clearCount value is included in the HMAC of a context for an object with the stClear attribute so that the context will be invalidated on each TPM Restart as well as each TPM Reset” and adds that the clearCount value is useful in context invalidation, which is not applicable to the claimed invention. However, Examiner respectfully submits that despite the subjective reason for using the clearCount as input for a MAC, Duflot expressly teaches the claim limitation “an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the MAC”, per se. That is, the argument conflates why clearCount is used with how clearCount is used, introducing purpose-based limitations not present in the claim. The invention, as claimed, requires only a counter that is used as input to generate a MAC, which is rendered obvious by Duflot’s clearCount. The clearCount value taught by Duflot is intended to be used for context invalidation, but that does not discount that the clearCount value represents an on-apparatus counter that is incremented on a power save event and is used as input to generate a MAC. Thus, Duflot provides a known mechanism implementing a state-transition counter as input for a MAC calculation. This routine cryptographic design choice offers the predictable and obvious benefit of MAC-based integrity evaluations for saved/restored objects, and is therefore obvious to combine with the previously applied references in view of KSR.
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-3, 5-8, 10, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gopal et al. (US 20160380772 A1), hereinafter Gopal, in view of Chhabra et al. (US 20190156043 A1), hereinafter Chhabra, Duflot et al. (Duflot, L., Chin, G.-W., Kremer, N., Guihery, F., Ebrecht, R., Regenscheid, A., & Trusted Computing Group. (2014). Trusted Platform Module Library Part 1: Architecture. https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf), hereinafter Duflot, and Chhabra et al. (US 20190102322 A1), hereinafter ‘322.
Regarding Claim 1:
Gopal teaches an apparatus comprising: decoder circuitry to decode a single instruction (Gopal – Paragraph [0032]: Referring again to FIG. 1, the processor includes a decode unit or decoder 102. The decode unit may receive and decode the keyed-hash MAC with obfuscated key information instruction 101), the single instruction to include one or more fields for an opcode (Gopal – Paragraph [0098]: The instruction includes an operation code or opcode 860. The opcode may represent a plurality of bits, or one or more fields, that are operative to identify the instruction and/or the operation to be performed) and one or more fields to identify a source operand which is to store or encode a destination address (Gopal – Paragraph [0034]: In some embodiments, the keyed-hash MAC with obfuscated key information instruction 101 may explicitly specify (e.g., through one or more fields or a set of bits), or otherwise indicate (e.g., implicitly indicate), data often referred to as a message 112, obfuscated key information 111, and a destination storage location (e.g., a packed data register 113) where a message authentication code (MAC) 114 is to be stored responsive to and/or as a result of the instruction. As one example, the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands), wherein the opcode is to indicate that execution circuitry is to (Gopal – Paragraph [0098]: The instruction includes an operation code or opcode 860. The opcode may represent a plurality of bits, or one or more fields, that are operative to identify the instruction and/or the operation to be performed); generate a message authentication code (MAC) [on at least the encrypted, read key data structure] (Gopal – Paragraph [0027]: The keyed-hash MAC with obfuscated key information instruction 101 may corresponds to, and may be used to implement, a keyed-hash MAC algorithm. The keyed hash MAC algorithm represents a type of MAC algorithm that is operative to calculate a MAC based on both a secret cryptographic key as well as a cryptographic hash algorithm. The calculated MAC may represent a cryptographic checksum that may be used to check or ensure both the integrity and the authenticity of data, for example, data transmitted over and/or stored in an unreliable medium. Ensuring the integrity of the data may help to ensure that the data has not been corrupted or changed since the MAC was computed; and Paragraph [0037]: The message 112 is to be interpreted broadly as various different types of data on which the keyed-hash MAC algorithm is to be performed; and Paragraph [0042]: In some embodiments, the MAC 114 may be generated based on the entire message 112 within the confines of the performance of the same single keyed-hash MAC with obfuscated key information instruction 101), store the MAC [and encrypted, read key data structure] at the destination address (Gopal – Paragraph [0035]: in some embodiments, a storage location used for the message and/or the obfuscated key information may optionally be reused as the destination storage location for the MAC; and Paragraph [0037]: The message 112 is to be interpreted broadly as various different types of data on which the keyed-hash MAC algorithm is to be performed. Although it is referred to as a message, it need not be any type of communication message but rather may be any arbitrary type of data); and the execution circuitry to execute the decoded single instruction according to the opcode (Gopal – Paragraph [0154]: Certain operations may be performed by hardware components, or may be embodied in machine-executable or circuit-executable instructions, that may be used to cause and/or result in a machine, circuit, or hardware component (e.g., a processor, potion of a processor, circuit, etc.) programmed with the instructions performing the operations. The operations may also optionally be performed by a combination of hardware and software. A processor, machine, circuit, or hardware may include specific or particular circuitry or other logic (e.g., hardware potentially combined with firmware and/or software) is operative to execute and/or process the instruction and store a result in response to the instruction).
Gopal does not expressly teach read a key data structure of a memory encryption engine, encrypt contents of the read key data structure; [generate a message authentication code (MAC)] on at least the encrypted, read key data structure; [store the MAC] and encrypted, read key data structure.
However, Chhabra teaches wherein the opcode is to indicate that execution circuitry is to read a key data structure of a memory encryption engine (Chhabra – Paragraph [0037]: The cryptographic engine 140 may cache the internal key data structure 142, which the cryptographic engine 140 may use to identify domain accesses to be protected; Paragraph [0038]: The key data structure 142 may be adapted to store keys and domain information for the domains; Paragraph [0054]: … The second domain information may include a second key and second domain identifier; Paragraph [0098]: instruction 1400 includes a page address 1402, optional opcode 1404; and Paragraph [0115]: processor core is to execute instructions to c) select a second secure domain to be de-scheduled, wherein the second secure domain is indexed within the key data structure at a target entry; d) issue a read key command to read second domain information from the target entry of the key data structure), encrypt contents of the read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310)); [generate a message authentication code (MAC)] on at least the encrypted, read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310); and Paragraph [0115]: issue a read key command to read second domain information from the target entry of the key data structure; Examiner’s Comment: This teaching in combination with Gopal’s teaching to generate a MAC on arbitrary message data is sufficient to read on the claim limitation); [store the MAC] and encrypted, read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310); and Paragraph [0115]: issue a read key command to read second domain information from the target entry of the key data structure; Examiner’s Comment: This teaching in combination with Gopal’s teaching to store a message comprising some arbitrary data and a MAC according to an instruction is sufficient to read on the claim limitation).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, further incorporating Chhabra to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chhabra’s teachings to read and encrypt key data according to an instruction into Gopal’s combined decoder and execution circuitry to process an instruction comprising opcode and a destination address and store a MAC and key data at the destination address. This combination would result in the capability to encrypt and store key information at a designated location in response to an instruction.
The combination of Gopal and Chhabra does not expressly teach wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the MAC.
However, Duflot teaches wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the MAC (Duflot – P. 185: The HMAC integrity computation for a saved context is: contextHMAC ≔ HMACvendorAlg (hProof, resetValue { || clearCount} || sequence || handle || encContext) (56) where HMACvendorAlg: HMAC using a vendor-defined hash algorithm; hProof: the hierarchy proof as selected by the hierarchy parameter of the TPMS_CONTEXT; … clearCount: a counter value that is incremented on each TPM Resume and may be incremented or set to zero on TPM Reset; and P. 56: TPM Resume is a Startup(STATE) that follows a Shutdown(STATE). This indicates a system that is restarting the OS from RAM memory, sometimes called “sleep.” For sleep, the expectation is that the CRTM will perform the minimal actions required to make the system functional and then “return” to the running OS rather than rebooting it).
It would have been obvious before the effective filing data of the claimed invention to a person having ordinary skill in the art to modify Gopal and Chhabra, further incorporating Duflot to arrive at the conclusion of the claimed invention. Duflot is directed to a TPM-style secure object context save/restore mechanism, including an on-die counter of state transitions that is used as input to generate a MAC. Thus, Duflot established well-known mechanisms for HMAC-based integrity protection of saved object states, counters for freshness and/or replay protection, and prevention of stale state reuse. Under KSR, combining these mechanisms with the further known single-instruction reading and encryption of a key data structure taught by the combination of Gopal and Chhabra would have been obvious to a skilled artisan. One would have been motivated to combine these known concepts because each addresses the technical issue of secure data continuity, and the combination would result in the predictable benefit of state-transition-influenced MAC-based integrity protection of an encrypted key data structure.
The combination of Gopal, Chhabra, and Duflot does not expressly teach wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines.
However, ‘322 teaches wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines (‘322 – Paragraph [0003]: One security approach involves the use of multi-key total memory encryption (MKTME) where a hypervisor may assign a cryptographic key to each of the customer workloads running in its own VM. Each workload may use its key to protect information that it stores in the server's physical memory; and Paragraph [0039]: FIG. 4 is a functional diagram illustrating operation of a multi-key memory encryption arrangement according to some embodiments. Workloads 402A and 402B may be implemented as mutually-isolated VMs. Each workload 402 is to have its corresponding data optionally encrypted with its own cryptographic key, such that the other workloads (or any another entity) are not able to decipher the stored data; and Paragraph [0042]: Each allocated memory page is to be associated with a key identifier (keyID) corresponding to a particular cryptographic key. Each keyID is a pointer, or reference, to a specific cryptographic key that is stored separately from memory 418, secure memory allocator 404 and workloads 402. In an example, as illustrated in FIG. 4, key lookup data store 408 may be contained in memory 418, in MKE engine 406, or elsewhere that is efficiently accessible to MKE engine 406, which is described below. Key lookup data store 408 associates keyIDs with the corresponding cryptographic keys. Key lookup data store 408 may be implemented using any suitable data structure; and Paragraph [0043]: the keys stored in key lookup data store 408 are themselves encrypted).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, and Duflot, further incorporating ‘322 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate ‘322’s teachings to associate isolated VMs with particular cryptographic keys and corresponding key IDs in a key table into Gopal, Chhabra, and Duflot’s combined decoder and execution circuitry to process an instruction comprising opcode and a destination address and store a MAC and key data at the destination address. This additional functionality would prevent potentially malicious VMs from accessing and/or modifying memory addresses they are not entitled to.
Regarding Claim 2:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Gopal further teaches wherein the one or more fields to identify the source operand is to identify a vector register to store the destination address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Gopal further teaches wherein the one or more fields to identify the source operand is to identify a memory location to store the destination address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Chhabra further teaches wherein entries of the key data structure are further to include an encryption key (Chhabra – Paragraph [0038]: The key data structure 142 may be adapted to store keys and domain information for the domains; and Figure 2: see Key Data Structure 142)
The motivation for combining the arts is the same as that of Claim 1.
Regarding Claim 6:
Gopal teaches a method comprising: decoding a single instruction (Gopal – Paragraph [0032]: Referring again to FIG. 1, the processor includes a decode unit or decoder 102. The decode unit may receive and decode the keyed-hash MAC with obfuscated key information instruction 101), the single instruction to include one or more fields for an opcode (Gopal – Paragraph [0098]: The instruction includes an operation code or opcode 860. The opcode may represent a plurality of bits, or one or more fields, that are operative to identify the instruction and/or the operation to be performed) and one or more fields to identify a source operand which is to store or encode a destination address (Gopal – Paragraph [0034]: In some embodiments, the keyed-hash MAC with obfuscated key information instruction 101 may explicitly specify (e.g., through one or more fields or a set of bits), or otherwise indicate (e.g., implicitly indicate), data often referred to as a message 112, obfuscated key information 111, and a destination storage location (e.g., a packed data register 113) where a message authentication code (MAC) 114 is to be stored responsive to and/or as a result of the instruction. As one example, the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands), wherein the opcode is to indicate that execution circuitry is to (Gopal – Paragraph [0098]: The instruction includes an operation code or opcode 860. The opcode may represent a plurality of bits, or one or more fields, that are operative to identify the instruction and/or the operation to be performed); generate a message authentication code (MAC) [on at least the encrypted, read key data structure] (Gopal – Paragraph [0027]: The keyed-hash MAC with obfuscated key information instruction 101 may corresponds to, and may be used to implement, a keyed-hash MAC algorithm. The keyed hash MAC algorithm represents a type of MAC algorithm that is operative to calculate a MAC based on both a secret cryptographic key as well as a cryptographic hash algorithm. The calculated MAC may represents a cryptographic checksum that may be used to check or ensure both the integrity and the authenticity of data, for example, data transmitted over and/or stored in an unreliable medium. Ensuring the integrity of the data may help to ensure that the data has not been corrupted or changed since the MAC was computed; and Paragraph [0037]: The message 112 is to be interpreted broadly as various different types of data on which the keyed-hash MAC algorithm is to be performed; and Paragraph [0042]: In some embodiments, the MAC 114 may be generated based on the entire message 112 within the confines of the performance of the same single keyed-hash MAC with obfuscated key information instruction 101), store the MAC [and encrypted, read key data structure] at the destination address (Gopal – Paragraph [0035]: in some embodiments, a storage location used for the message and/or the obfuscated key information may optionally be reused as the destination storage location for the MAC; and Paragraph [0037]: The message 112 is to be interpreted broadly as various different types of data on which the keyed-hash MAC algorithm is to be performed. Although it is referred to as a message, it need not be any type of communication message but rather may be any arbitrary type of data); and the execution circuitry to execute the decoded single instruction according to the opcode (Gopal – Paragraph [0154]: Certain operations may be performed by hardware components, or may be embodied in machine-executable or circuit-executable instructions, that may be used to cause and/or result in a machine, circuit, or hardware component (e.g., a processor, potion of a processor, circuit, etc.) programmed with the instructions performing the operations. The operations may also optionally be performed by a combination of hardware and software. A processor, machine, circuit, or hardware may include specific or particular circuitry or other logic (e.g., hardware potentially combined with firmware and/or software) is operative to execute and/or process the instruction and store a result in response to the instruction).
Gopal does not expressly teach read a key data structure of a memory encryption engine, encrypt contents of the read key data structure; [generate a message authentication code (MAC)] on at least the encrypted, read key data structure; [store the MAC] and encrypted, read key data structure.
However, Chhabra teaches wherein the opcode is to indicate that execution circuitry is to read a key data structure of a memory encryption engine (Chhabra – Paragraph [0037]: The cryptographic engine 140 may cache the internal key data structure 142, which the cryptographic engine 140 may use to identify domain accesses to be protected; Paragraph [0038]: The key data structure 142 may be adapted to store keys and domain information for the domains; Paragraph [0054]: … The second domain information may include a second key and second domain identifier; Paragraph [0098]: instruction 1400 includes a page address 1402, optional opcode 1404; and Paragraph [0115]: processor core is to execute instructions to c) select a second secure domain to be de-scheduled, wherein the second secure domain is indexed within the key data structure at a target entry; d) issue a read key command to read second domain information from the target entry of the key data structure), encrypt contents of the read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310)); [generate a message authentication code (MAC)] on at least the encrypted, read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310); and Paragraph [0115]: issue a read key command to read second domain information from the target entry of the key data structure; Examiner’s Comment: This teaching in combination with Gopal’s teaching to generate a MAC on arbitrary message data is sufficient to read on the claim limitation); [store the MAC] and encrypted, read key data structure (Chhabra – Paragraph [0047]: method 300 may begin with the trusted software 305, in order to set up a domain, invoking special instruction BIND to encrypt the key associated with the domain and other domain programming information (e.g., domain ID) into a wrapped binary large object (“blob”) (310); and Paragraph [0115]: issue a read key command to read second domain information from the target entry of the key data structure; Examiner’s Comment: This teaching in combination with Gopal’s teaching to store a message comprising some arbitrary data and a MAC according to an instruction is sufficient to read on the claim limitation).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, further incorporating Chhabra to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chhabra’s teachings to read and encrypt key data according to an instruction into Gopal’s combined decoder and execution circuitry to process an instruction comprising opcode and a destination address and store a MAC and key data at the destination address. This combination would result in the capability to encrypt and store key information at a designated location in response to an instruction.
The combination of Gopal and Chhabra does not expressly teach wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the MAC.
However, Duflot teaches wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the MAC (Duflot – P. 185: The HMAC integrity computation for a saved context is: contextHMAC ≔ HMACvendorAlg (hProof, resetValue { || clearCount} || sequence || handle || encContext) (56) where HMACvendorAlg: HMAC using a vendor-defined hash algorithm; hProof: the hierarchy proof as selected by the hierarchy parameter of the TPMS_CONTEXT; … clearCount: a counter value that is incremented on each TPM Resume and may be incremented or set to zero on TPM Reset; and P. 56: TPM Resume is a Startup(STATE) that follows a Shutdown(STATE). This indicates a system that is restarting the OS from RAM memory, sometimes called “sleep.” For sleep, the expectation is that the CRTM will perform the minimal actions required to make the system functional and then “return” to the running OS rather than rebooting it).
It would have been obvious before the effective filing data of the claimed invention to a person having ordinary skill in the art to modify Gopal and Chhabra, further incorporating Duflot to arrive at the conclusion of the claimed invention. Duflot is directed to a TPM-style secure object context save/restore mechanism, including an on-die counter of state transitions that is used as input to generate a MAC. Thus, Duflot established well-known mechanisms for HMAC-based integrity protection of saved object states, counters for freshness and/or replay protection, and prevention of stale state reuse. Under KSR, combining these mechanisms with the further known single-instruction reading and encryption of a key data structure taught by the combination of Gopal and Chhabra would have been obvious to a skilled artisan. One would have been motivated to combine these known concepts because each addresses the technical issue of secure data continuity, and the combination would result in the predictable benefit of state-transition-influenced MAC-based integrity protection of an encrypted key data structure.
The combination of Gopal, Chhabra, and Duflot does not expressly teach wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines.
However, ‘322 teaches wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines (‘322 – Paragraph [0003]: One security approach involves the use of multi-key total memory encryption (MKTME) where a hypervisor may assign a cryptographic key to each of the customer workloads running in its own VM. Each workload may use its key to protect information that it stores in the server's physical memory; and Paragraph [0039]: FIG. 4 is a functional diagram illustrating operation of a multi-key memory encryption arrangement according to some embodiments. Workloads 402A and 402B may be implemented as mutually-isolated VMs. Each workload 402 is to have its corresponding data optionally encrypted with its own cryptographic key, such that the other workloads (or any another entity) are not able to decipher the stored data; and Paragraph [0042]: Each allocated memory page is to be associated with a key identifier (keyID) corresponding to a particular cryptographic key. Each keyID is a pointer, or reference, to a specific cryptographic key that is stored separately from memory 418, secure memory allocator 404 and workloads 402. In an example, as illustrated in FIG. 4, key lookup data store 408 may be contained in memory 418, in MKE engine 406, or elsewhere that is efficiently accessible to MKE engine 406, which is described below. Key lookup data store 408 associates keyIDs with the corresponding cryptographic keys. Key lookup data store 408 may be implemented using any suitable data structure; and Paragraph [0043]: the keys stored in key lookup data store 408 are themselves encrypted).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, and Duflot, further incorporating ‘322 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate ‘322’s teachings to associate isolated VMs with particular cryptographic keys and corresponding key IDs in a key table into Gopal, Chhabra, and Duflot’s combined decoder and execution circuitry to process an instruction comprising opcode and a destination address and store a MAC and key data at the destination address. This additional functionality would prevent potentially malicious VMs from accessing and/or modifying memory addresses they are not entitled to.
Regarding Claim 7:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Gopal further teaches wherein the one or more fields to identify the source operand is to identify a vector register to store the destination address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Gopal further teaches wherein the one or more fields to identify the source operand is to identify a memory location to store the destination address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 10:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
Chhabra further teaches wherein entries of the key data structure are further to include an encryption key (Chhabra – Paragraph [0038]: The key data structure 142 may be adapted to store keys and domain information for the domains; and Figure 2: see Key Data Structure 142)
The motivation for combining the arts is the same as that of Claim 1.
Regarding Claim 11:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the method of claim 6.
Gopal further teaches further comprising translating the single instruction into one or more instructions of a different instruction set architecture prior to decoding (Gopal – Paragraph [0033]: By way of example, the instruction conversion module may receive the keyed-hash MAC with obfuscated key information instruction, which may be of a first instruction set, and may emulate, translate, morph, interpret, or otherwise convert the keyed-hash MAC with obfuscated key information instruction into one or more corresponding intermediate instructions or control signals, which may be of a second different instruction set. The one or more intermediate instructions or control signals of the second instruction set may be provided to a decode unit (e.g., decode unit 102), which may decode them into one or more lower-level instructions or control signals executable by native hardware of the processor (e.g., one or more execution units) wherein executing of the one or more instructions of the different instruction set architecture is to be functionally equivalent as the executing according to the opcode of the single instruction (Gopal – Paragraph [0149]: This converted code is not likely to be the same as the alternative instruction set binary code 1610 because an instruction converter capable of this is difficult to make; however, the converted code will accomplish the general operation and be made up of instructions from the alternative instruction set).
The motivation to combine the arts is the same as that of Claim 6.
Claims 4 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Gopal, in view of Chhabra, Duflot, ‘322, and Chhabra et al. (US 20190042476 A1), hereinafter Chhabra (‘476).
Regarding Claim 4:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the apparatus of claim 1.
The combination of Gopal, Chhabra, Duflot, and ‘322 does not expressly teach wherein entries of the key data structure include an encryption key identifier and a mode for use of a key.
However, Chhabra (‘476) teaches wherein entries of the key data structure include an encryption key identifier and a mode for use of a key (Chhabra (‘476) – Paragraph [0052]: The entries 207a-d of domain key table 207 each correspond to a different protected domain. For example, each entry 207a-d includes a key or domain identifier (ID), a protection mode, and an associated encryption key).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, and Duflot, further incorporating Chhabra (‘476) to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chhabra (‘476)’s teachings of specific elements which populate the key data structure into Gopal, Chhabra, and Duflot’s combined apparatus for establishing a secure storage space for MAC and key information. The combination would result in streamlining the process to identify important key information within the key data structure.
Regarding Claim 9:
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches the method of claim 6.
The combination of Gopal, Chhabra, Duflot, and ‘322 teaches does not expressly teach wherein entries of the key data structure include an encryption key identifier and a mode for use of a key.
However, Chhabra (‘476) teaches wherein entries of the key data structure include an encryption key identifier and a mode for use of a key (Chhabra (‘476) – Paragraph [0052]: The entries 207a-d of domain key table 207 each correspond to a different protected domain. For example, each entry 207a-d includes a key or domain identifier (ID), a protection mode, and an associated encryption key).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, and Duflot, further incorporating Chhabra (‘476) to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chhabra (‘476)’s teachings of specific elements which populate the key data structure into Gopal, Chhabra, and Duflot’s combined method for establishing a secure storage space for MAC and key information. The combination would result in streamlining the process to identify important key information within the key data structure.
Claims 12-14, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra (‘354), in view of Gopal, Burger et al. (US 20170083331 A1), hereinafter Burger, Duflot, and ‘322.
Regarding Claim 12:
Chhabra (‘354) teaches an apparatus comprising: decoder circuitry to decode a single instruction (Chhabra (‘354) – Paragraph [0075]: Cores 720, 730 may include an instruction decoder to recognize and/or decode an instruction); and one or more fields to identify a source operand which is to store or encode a source address (Chhabra (‘354) – Paragraph [0044]: this instruction may have three operands to identify source address information, destination address information and a cryptographic response structure; and Paragraph [0054]: method 400 begins by obtaining the encrypted application from a source location, namely the source location identified in a source operand of the instruction. Examiner’s Comment: It is well-known in the art that in the x86 architecture, the source operand may encode a source/destination address for storing information/data/etc. See attached Oracle Corporation reference); and generate a MAC on [at least the decrypted, read key] data structure (Chhabra (‘354) – Paragraph [0054]: more particularly, the memory execution circuit may generate a MAC value on a per cacheline width of data, per page width of data or so forth); determine when the generated MAC matches the read MAC (Chhabra (‘354) – Paragraph [0047]: If the memory execution circuitry determines that the second MAC does not match the first stored MAC, it can raise an error to identify an integrity violation and potentially recalculate the second MAC. Furthermore, the memory execution circuitry device can decrypt the first portion of data in response to detecting the calculated second MAC matches the first MAC, and transmit the decrypted data to a core for execution, e.g., for a given key domain), wherein when the generated MAC and the read MAC do not match an exception is to be generated (Chhabra (‘354) – Paragraph [0047]: If the memory execution circuitry determines that the second MAC does not match the first stored MAC, it can raise an error to identify an integrity violation …) and when the generated MAC and the read MAC do match the key data structure is to be restored in a cryptographic engine (Chhabra (‘354) – Paragraph [0047]: the memory execution circuitry device can decrypt the first portion of data in response to detecting the calculated second MAC matches the first MAC, and transmit the decrypted data to a core for execution, e.g., for a given key domain; and Paragraph [0076]: core 720 includes memory encryption engine 740) and the execution circuitry to execute the decoded instruction according to the opcode (Chhabra (‘354) – Paragraph [0075]: Cores 720, 730 may include an instruction decoder to recognize and/or decode an instruction (e.g., from an instruction register), to activate appropriate circuitry to execute the instruction, to verify that a stream of instructions (e.g., operation codes, etc.) will compute, and so on, or combinations thereof).
Chhabra (‘354) does not expressly teach the single instruction to include one or more fields for an opcode, wherein the opcode is to indicate that execution circuitry is to: read an encrypted key data structure and associated message authentication code (MAC) from the source address, decrypt contents of the read key data structure; and [generate a MAC] on at least the decrypted, read key data structure.
However, Gopal does teach the single instruction to include one or more fields for an opcode (Gopal – Paragraph [0098]: The instruction includes an operation code or opcode 860. The opcode may represent a plurality of bits, or one or more fields), wherein the opcode is to indicate that execution circuitry is to: read an encrypted key data structure (Gopal – Paragraph [0065]: The encrypted key information is stored in a storage location 510 (e.g., a register or memory location) that may be specified or otherwise indicated by the instruction; the decryption unit may be coupled to receive the encrypted key information) and associated message authentication code (MAC) (Gopal – Paragraph [0065]: execution unit 503 that is operative to determine key information 545 from encrypted key information 511 responsive to a keyed-hash MAC with encrypted key information instruction) from the source address (Gopal – Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand), decrypt contents of the read key data structure (Gopal – Paragraph [0065]: The decryption unit may receive the secret cryptographic key and may be operative to use the secret cryptographic key to decrypt the encrypted key information into the decrypted key information 545) and [generate a MAC on] at least the decrypted, read key data structure (Gopal – Paragraph [0065]: The decryption unit may receive the secret cryptographic key and may be operative to use the secret cryptographic key to decrypt the encrypted key information into the decrypted key information 545; Examiner’s Comment: Gopal’s teaching of a decrypted, read key data structure in combination with Chhabra (354’)’s teaching to generate a MAC value on a per cacheline width of data (Paragraph [0054]: more particularly, the memory execution circuit may generate a MAC value on a per cacheline width of data, per page width of data or so forth) would render obvious to a skilled artisan any process of generating a MAC on the decrypted, read key data structure).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Chhabra (‘354), further incorporating Gopal to arrive at the conclusion of the claimed invention. One would have been motivated to incorporate Gopal’s means to read and decrypt key information according to opcode of an instruction into Chhabra (‘354)’s apparatus to decode and execute an instruction to generate, and use for subsequent verification, a MAC on the decrypted key information. The combination would result in the capability to securely store and regain access to key information within the system based on an instruction.
The combination of Chhabra (‘354) and Gopal does not expressly teach and one or more fields to identify a destination operand location that is to store an operational status; and generate and store operational status in the identified destination operand location.
However, Burger teaches and one or more fields to identify a destination operand location that is to store an operational status (Burger – Paragraph [0135]: Some examples of the method further include, if the memory operation is successful, sending the status indicator value indicating success to a target operand specified by the memory store instruction. Some examples of the method further include, if the memory operation is not successful, then sending the status indicator value indicating failure to a target operand specified by the memory store instruction); and generate and store operational status in the identified destination operand location (Burger – Paragraph [0135]: Some examples of the method further include, if the memory operation is successful, sending the status indicator value indicating success to a target operand specified by the memory store instruction. Some examples of the method further include, if the memory operation is not successful, then sending the status indicator value indicating failure to a target operand specified by the memory store instruction).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Chhabra (‘354) and Gopal, further incorporating Burger to arrive at the conclusion of the claimed invention. One would have been motivated to incorporate Burger’s generation and storage of operational status into Chhabra (‘354) and Gopal’s combined apparatus for generating and verifying integrity information related to key information. The combination would result in designating a space to indicate the success of a security check for decrypted key information.
The combination of Chhabra (‘354), Gopal, and Burger does not expressly teach wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the generated MAC.
However, Duflot teaches wherein an on-apparatus counter that is to be incremented on a power save event is to be used as an input to generate the generated MAC (Duflot – P. 185: The HMAC integrity computation for a saved context is: contextHMAC ≔ HMACvendorAlg (hProof, resetValue { || clearCount} || sequence || handle || encContext) (56) where HMACvendorAlg: HMAC using a vendor-defined hash algorithm; hProof: the hierarchy proof as selected by the hierarchy parameter of the TPMS_CONTEXT; … clearCount: a counter value that is incremented on each TPM Resume and may be incremented or set to zero on TPM Reset; and P. 56: TPM Resume is a Startup(STATE) that follows a Shutdown(STATE). This indicates a system that is restarting the OS from RAM memory, sometimes called “sleep.” For sleep, the expectation is that the CRTM will perform the minimal actions required to make the system functional and then “return” to the running OS rather than rebooting it).
It would have been obvious before the effective filing data of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, and Burger, further incorporating Duflot to arrive at the conclusion of the claimed invention. Duflot is directed to a TPM-style secure object context save/restore mechanism, including an on-die counter of state transitions that is used as input to generate a MAC. Thus, Duflot established well-known mechanisms for HMAC-based integrity protection of saved object states, counters for freshness and/or replay protection, and prevention of stale state reuse. Under KSR, combining these mechanisms with the further known single-instruction reading and encryption of a key data structure taught by the combination of Gopal, Chhabra, and Burger would have been obvious to a skilled artisan. One would have been motivated to combine these known concepts because each addresses the technical issue of secure data continuity, and the combination would result in the predictable benefit of state-transition-influenced MAC-based integrity protection of an encrypted key data structure.
The combination of Gopal, Chhabra, burger, and Duflot does not expressly teach wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines.
However, ‘322 teaches wherein the key data structure is to store key identifiers for keys that are to be used by isolated virtual machines (‘322 – Paragraph [0003]: One security approach involves the use of multi-key total memory encryption (MKTME) where a hypervisor may assign a cryptographic key to each of the customer workloads running in its own VM. Each workload may use its key to protect information that it stores in the server's physical memory; and Paragraph [0039]: FIG. 4 is a functional diagram illustrating operation of a multi-key memory encryption arrangement according to some embodiments. Workloads 402A and 402B may be implemented as mutually-isolated VMs. Each workload 402 is to have its corresponding data optionally encrypted with its own cryptographic key, such that the other workloads (or any another entity) are not able to decipher the stored data; and Paragraph [0042]: Each allocated memory page is to be associated with a key identifier (keyID) corresponding to a particular cryptographic key. Each keyID is a pointer, or reference, to a specific cryptographic key that is stored separately from memory 418, secure memory allocator 404 and workloads 402. In an example, as illustrated in FIG. 4, key lookup data store 408 may be contained in memory 418, in MKE engine 406, or elsewhere that is efficiently accessible to MKE engine 406, which is described below. Key lookup data store 408 associates keyIDs with the corresponding cryptographic keys. Key lookup data store 408 may be implemented using any suitable data structure; and Paragraph [0043]: the keys stored in key lookup data store 408 are themselves encrypted).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Gopal, Chhabra, Burger, and Duflot, further incorporating ‘322 to arrive at the conclusion of the claimed invention. One would be motivated to incorporate ‘322’s teachings to associate isolated VMs with particular cryptographic keys and corresponding key IDs in a key table into Gopal, Chhabra, Burger, and Duflot’s combined decoder and execution circuitry to process an instruction comprising opcode and a destination address and store a MAC and key data at the destination address. This additional functionality would prevent potentially malicious VMs from accessing and/or modifying memory addresses they are not entitled to.
Regarding Claim 13:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
Gopal further teaches wherein the one or more fields for the identifier of the source operand is to identify a vector register to store the source address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 12.
Regarding Claim 14:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
Gopal further teaches wherein the one or more fields for the identifier of the source operand is to identify a memory location to store the source address (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands; and Paragraph [0068]: The HMAC_LOCKED_K instruction may explicitly specify or implicitly indicate a first 64-bit general-purpose register (r64) that is to store an effective address, pointer, or other indication of a location in memory that is to store a first source operand (SRC1)).
The motivation to combine the arts is the same as that of Claim 12.
Regarding Claim 17:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
Gopal further teaches wherein the one or more fields to identify the destination operand is to identify a vector register (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands).
The motivation to combine the arts is the same as that of Claim 12.
Regarding Claim 18:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
Gopal further teaches wherein the one or more fields to identify the destination operand is to identify a memory location (Gopal – Paragraph [0034]: the instruction may have source and/or destination operand specification fields to specify registers, memory locations, or other storage locations that may have these operands, or may store data to indicate these operands).
The motivation to combine the arts is the same as that of Claim 12.
Claims 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra (‘354), in view of, Gopal, Burger, Duflot, ‘322, and Chhabra (‘476).
Regarding Claim 15:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 does not expressly teach wherein entries of the key data structure include an encryption key identifier and a mode for use of a key.
However, Chhabra (‘476) teaches wherein entries of the key data structure include an encryption key identifier and a mode for use of a key (Chhabra (‘476) – Paragraph [0052]: The entries 207a-d of domain key table 207 each correspond to a different protected domain. For example, each entry 207a-d includes a key or domain identifier (ID), a protection mode, and an associated encryption key (if applicable)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Chhabra (‘354), Gopal, Burger, Duflot, and ‘322, further incorporating Chhabra (‘476) to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chhabra (‘476)’s teachings of specific elements which populate the key data structure into Chhabra (‘354), Gopal, Burger, Duflot, and ‘322’s combined apparatus for generating and verifying integrity information related to key information. The combination would result in streamlining the process to identify important key information within the key data structure.
Regarding Claim 16:
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 teaches the apparatus of claim 12.
The combination of Chhabra (‘354), Gopal, Burger, Duflot, and ‘322 does not expressly teach wherein entries of the key data structure are further to include an encryption key.
However, Chhabra (‘476) teaches wherein entries of the key data structure are further to include an encryption key (Chhabra (‘476) – Paragraph [0052]: The entries 207a-d of domain key table 207 each correspond to a different protected domain. For example, each entry 207a-d includes a key or domain identifier (ID), a protection mode, and an associated encryption key (if applicable)).
The motivation to combine the arts is the same as that of Claim 15.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Chhabra (‘354), in view of, Gopal, Duflot, ‘322, and Intel (Intel Corporation. Power Transitions in Intel® Software Guard Extensions (Intel® SGX) Applications for Windows. Intel Corporation, 2016. Intel Software Development Resources, https://cdrdv2-public.intel.com/671295/powertransition-in-intel-sgx.pdf), hereinafter Intel.
Regarding Claim 19:
The combination of Chhabra (‘354), Gopal, Duflot, and ‘322 teaches the apparatus of claim 1.
The combination of Chhabra (‘354), Gopal, Duflot, and ‘322 does not expressly teach wherein the single instruction is to be used before the apparatus transitions to a low power state.
However, Intel teaches wherein the single instruction is to be used before the apparatus transitions to a low power state (Intel – P. 1: Modern operating systems provide mechanisms to enable applications to be notified of major power events on the platform. When the computer enters a lower power state, the OS suspends to RAM or saves to disk context information for future restoration. For Intel SGX, power transitions from an S0/S1 state to an S2-S5 state cause the protected memory encryption key for an enclave to be destroyed. This makes the enclave effectively unreadable; therefore, it must be recreated on a system resume. Enclaves that need to preserve secrets across S2-S5 power states must save their state information to a disk; and P. 7: Intel SGX applications cannot depend on Windows power-transition event notification for sealing secret data, because the OS cannot guarantee that it can give enough time for a given enclave to seal its secret data to disk. And the WindowProc callback function cannot be used for notification. So Intel SGX applications uses a specific methodology for dealing with power-transition events, to achieve minimal data loss. [Symbol font/0xB7] Intel SGX applications identify the occurrence of power-transition events based on the error code SGX_ERROR_ENCLAVE_LOST. Because the error code returns only when a power-transition event has already occurred and the OS has resumed, an Intel SGX application’s secret data must be sealed periodically by the enclave when the OS is running. This allows stored secret data to be retrieved from disk (or the cloud) after the enclave is rebuilt. [Symbol font/0xB7] Also, to minimize the overhead of regularly saving secret data to a disk or cloud, the secret data that an enclave stores should be kept minimal; Examiner’s Comment: the sealing of an Intel SGX application’s secret data is interpreted as a functionally analogous process as that which is performed based on the claimed single instruction, and the periodic performance of the sealing includes sealing the data before or in anticipation of power-transition events to minimize data loss resulting from such events).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Chhabra (‘354), Gopal, Duflot, and ‘322, further incorporating Intel to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Intel’s teachings to save and protect secret data in anticipation of low power or power save events into Chhabra (‘354), Gopal, Duflot, and ‘322’s combined apparatus for generating and verifying integrity information related to key information. The combined functionality would further enhance security of the encrypted key data by taking pre-emptive measures to ensure data freshness and continuity.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Bishop (US 20230168915 A1) teaches an apparatus for isolating VMs in data transfer channels that have particular encryption keys associated therewith
Caspi et al. (US 20200202013 A1) teaches a system for managing encryption keys securely in trust domains, including various structures for associating entity relationships with/ownership of keys
Ouziel et al. (US 20200201786 A1) teaches a system and methods for associating restricted and non-restricted keys with partitions of physical memory, the keys accessible by particular trust domains
Harp (US 20170331627 A1) teaches methods and systems for key management that include implementing variable permission levels regarding access to encryption keys per isolated VM
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights