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 .
Claims 1-20, filed on 11/14/2024, is acknowledged and considered.
Claims 1, 5, and 12 are independent. Claims 1-20 are pending.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 2/12/2025 was filed after the mailing date of the Claims on 11/14/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
4. Claims 9-11 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.:
Claim 9-11 recites “the crypto operation method”, where this method appears to be applied to a confidential computing environment created according to claim 1. This renders the method of claim 9 indefinite as to whether or not it can be interpreted as merely intended use.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
5. Claims 9-11 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 9 recites “the crypto operation method”, where the method is merely applied to a confidential computing environment created according to claim 1. Thus, the method of claim 9 is not proper dependent of claim 1 since the method cannot necessarily be interpreted to always include the entirety of claim 1. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
6. Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because:
Claim 17 recite “a storage medium”, where the claim nor the original disclosure fails to define the storage medium as excluding signals or is non-transitory type media. Thus, suggest the storage medium encompasses signals per se.
Allowable Subject Matter
7. Claims 2-3 and 6-7 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
8. Claim(s) 1, 4-5, and 8-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lang, et al. [US 20190228163] in view of Krawczewicz, et al. [US 20190095655].
As per claim 1: Lang, et al. teaches a method for creating a confidential computing environment, applied to a crypto module manager, and comprising:
acquiring image information of a crypto module; [Lang: para 0004, 0011; crypto module can broadly be in the form of a security module or crypto card. Para 0028; the logical partition image profile specifies the coprocessor of the hardware security module and the crypto domain (i.e. confidential computing environment)]
determining a hardware resource required for running the crypto module based on the image information of the crypto module; [Lang: para 0028-0030; coprocessor of the hardware security module hosts physical crypto domains. Control domains are used to administer the coprocessors of the hardware security module. The control domains are defined in an image activation profile. A hardware management console (HMC) used for defining and/or setting up the image activation profile, where a number of logical partitions and/or a number of processors is defined. Para 0044; another example of the hardware resource required for running the crypto module is determined by an image activation profile. The limitation “a confidential computing environment” is not defined nor suggest what constitutes as a confidential computing environment. Thus, the domain or processor may broadly be a confidential computing environment]
**generating a confidential computing environment creation request [**rejected under a secondary reference, discussion below] based on the hardware resource required for running the crypto module; and [Lang: para 0033; FIG. 2 depicts a flow chart for initialization of a computer system with hardware security modules]
**sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module. [**rejected under a secondary reference, discussion below]
Lang provides in FIG. 2 that depicts a flow chart for initialization of a computer system with hardware security modules [Lang: para 0033]. Thus, suggest ability to a confidential computing environment created based on the hardware resource required for running the crypto module. However, Lang does not clearly teach “generating a confidential computing environment creation request” and “sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module”.
Krawczewicz teaches the present invention provides a localized security architecture for a smartphone based upon an NFC crypto module. The crypto module is the hardware trust anchor when connected to a smartphone [Krawczewicz: para 0040]. The crypto module can actively respond to a data breach by terminating all trusted processes, make sure that any unprotected private data is encrypted and stored, erase unprotected keys, and block any further requests for trusted processes [Krawczewicz: para 0069]. Thus, Krawczewicz obviously suggest utility of “a confidential computing environment creation request”, since the request for trusted processes can be blocked or denied. Leveraging the hardware encryption processor incorporated in the commercial smartphone transceiver chip, the crypto module architecture integrates a compatible hardware cryptographic processor [Krawczewicz: para 0115]. This suggest “to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module” and “wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module”. Further, Art discusses the user brings the Crypto Module within approximately 1 cm of the smartphone where upon both the internal cryptographic processor and bus isolation processor sense an RF field and senses any commands sent from the smartphone NFC transceiver. Both Antenna #1 and #2 couple power to the crypto module and sends an initiator return ping request to the smartphone whereby an acknowledge response is received back from the smartphone [Krawczewicz: para 0129-0130]. The crypto module is securely tethered to the smartphone to proceed with any requested secure processing. The smartphone utilized a single NFC chip to and are fully compatible with all three communications modes [Krawczewicz: para 0135]. Krawczewicz obviously suggest “generating a confidential computing environment creation request” and “sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module”. Another security feature of the crypto module and the trusted NFC bus is to cryptographically verify using a digital signature algorithm. To achieve these security measures and prevent malicious running apps from access, the crypto module continually verifies the proper access and data bus configuration between the application processor and the peripherals [Krawczewicz: para 0208]. As such, one would be motivated to securely tether to the smartphone to proceed with any requested secure processing and continually verify the proper access.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Krawczewicz with Lang to teach “generating a confidential computing environment creation request” and “sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module” for the reason to continually verify the proper access and securely tether to the smartphone to proceed with any requested secure processing [Krawczewicz: para 0208].
Claim 2: Objected
Claim 3: Objected
Claim 4: Lang: para 0028-0035 in view of Krawczewicz: para 0069, 0129-0135 [suggesting “confidential computing environment creation request”, under the same pretext and motivation as in claim 1]; discussing the method for creating a confidential computing environment according to claim 1, after the sending the confidential computing environment creation request, further comprising: sending the image information of the crypto module, to enable that the confidential environment manager loads the image information of the crypto module into the created confidential computing environment, thereby enabling the crypto module to be run in the confidential computing environment.
As per claim 5: Lang, et al. teaches a method for creating a confidential computing environment, applied to a confidential environment manager, and comprising:
acquiring a confidential computing environment creation request sent by a crypto module manager, wherein the confidential computing environment creation request is generated by the crypto module manager based on a hardware resource required for running a crypto module, and the hardware resource required for running the crypto module is determined by the crypto module manager based on acquired image information of the crypto module; and [Lang: para 0004, 0011; crypto module can broadly be in the form of a security module or crypto card. Para 0028; the logical partition image profile specifies the coprocessor of the hardware security module and the crypto domain (i.e. confidential computing environment)]
creating a confidential computing environment matching a running requirement of the crypto module [Lang: para 0028-0030; coprocessor of the hardware security module hosts physical crypto domains. Control domains are used to administer the coprocessors of the hardware security module. The control domains are defined in an image activation profile. A hardware management console (HMC) used for defining and/or setting up the image activation profile, where a number of logical partitions and/or a number of processors is defined. Para 0044; the hardware resource required for running the crypto module is determined by an image activation profile. The limitation “a confidential computing environment” is not defined nor suggest what constitutes as a confidential computing environment. Thus, the domain or processor may broadly be a confidential computing environment] based on the confidential computing environment creation request [**rejected under a secondary reference, discussion below], wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module. [Lang: para 0033; FIG. 2 depicts a flow chart for initialization of a computer system with hardware security modules] [Lang: para 00]
Lang provides in FIG. 2 that depicts a flow chart for initialization of a computer system with hardware security modules [Lang: para 0033]. Thus, suggest ability to a confidential computing environment created based on the hardware resource required for running the crypto module. However, Lang does not clearly teach “based on the confidential computing environment creation request”.
Krawczewicz teaches the present invention provides a localized security architecture for a smartphone based upon an NFC crypto module. The crypto module is the hardware trust anchor when connected to a smartphone [Krawczewicz: para 0040]. The crypto module can actively respond to a data breach by terminating all trusted processes, make sure that any unprotected private data is encrypted and stored, erase unprotected keys, and block any further requests for trusted processes [Krawczewicz: para 0069]. Thus, Krawczewicz obviously suggest utility of “a confidential computing environment creation request”, since the request for trusted processes can be blocked or denied. Leveraging the hardware encryption processor incorporated in the commercial smartphone transceiver chip, the crypto module architecture integrates a compatible hardware cryptographic processor [Krawczewicz: para 0115]. This suggest “to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module” and “wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module”. Further, Art discusses the user brings the Crypto Module within approximately 1 cm of the smartphone where upon both the internal cryptographic processor and bus isolation processor sense an RF field and senses any commands sent from the smartphone NFC transceiver. Both Antenna #1 and #2 couple power to the crypto module and sends an initiator return ping request to the smartphone whereby an acknowledge response is received back from the smartphone [Krawczewicz: para 0129-0130]. The crypto module is securely tethered to the smartphone to proceed with any requested secure processing. The smartphone utilized a single NFC chip to and are fully compatible with all three communications modes [Krawczewicz: para 0135]. Krawczewicz obviously suggest “generating a confidential computing environment creation request” and “sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module”. Another security feature of the crypto module and the trusted NFC bus is to cryptographically verify using a digital signature algorithm. To achieve these security measures and prevent malicious running apps from access, the crypto module continually verifies the proper access and data bus configuration between the application processor and the peripherals [Krawczewicz: para 0208]. As such, one would be motivated to securely tether to the smartphone to proceed with any requested secure processing and continually verify the proper access.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Krawczewicz with Lang to teach “generating a confidential computing environment creation request” and “sending the confidential computing environment creation request, to enable that a confidential environment manager creates a confidential computing environment matching a running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module” for the reason to continually verify the proper access and securely tether to the smartphone to proceed with any requested secure processing [Krawczewicz: para 0208].
Claim 6: Objected
Claim 7: Objected
Claim 8: Lang: para 0028-0035 [image profile specifies the coprocessor of the hardware security module and the crypto domain]; discussing the method for creating a confidential computing environment according to claim 5, after the creating the confidential computing environment matching the running requirement of the crypto module, further comprising: acquiring the image information of the crypto module sent by the crypto module manager, and loading the image information of the crypto module into the confidential computing environment to run the crypto module in the confidential computing environment.
Claim 9: Lang: para 0044-0045 [crypto card as hardware security module is initialized in a secure boot process. Secure hash loaded by the operating system instance into the crypto card, followed by a verifying process in the crypto card] in view of Krawczewicz: para 0010, 0208 [suggesting “sending, by a crypto application, a verification request”, under the same pretext and motivation as in claim 1]; discussing the crypto operation method, applied to a confidential computing environment created by the method for creating a confidential computing environment according to claim 1, and comprising: acquiring a key file and obtaining a key for a crypto operation based on the key file, by a crypto module; sending, by a crypto application, a verification request to the crypto module to verify the integrity of the crypto module; and in response to the crypto module being integral, invoking, by the crypto application, the crypto module to perform the crypto operation.
Claim 10: Lang: para 0012 in view of Krawczewicz: para 0116 [suggesting “decrypting”, under the same pretext and motivation as in claim 1]; discussing the crypto operation method according to claim 9, wherein the crypto module comprises a sealing key; and the obtaining, by the crypto module, the key for the crypto operation based on the key file comprises: decrypting, by the crypto module, the key file utilizing the sealing key to obtain the key for the crypto operation.
Claim 11: Lang: para 0044-0045 [crypto card as hardware security module is initialized in a secure boot process. Secure hash loaded by the operating system instance into the crypto card, followed by a verifying process in the crypto card]; discussing the crypto operation method according to claim 10, wherein the crypto module utilizes a crypto operation module to assist in performing the crypto operation; and the invoking, by the crypto application, the crypto module to perform the crypto operation comprises: invoking, by the crypto application, the crypto module, and performing, by the crypto module, the crypto operation utilizing the crypto operation module.
As per claim 12: Lang, et al. teaches a crypto operation system, comprising at least a crypto module [Lang: para 0004, 0011; crypto module can broadly be in the form of a security module or crypto card], a crypto application, a crypto module manager, and a confidential environment manager, wherein the crypto module manager and the confidential environment manager are configured to create a confidential computing environment matching a running requirement of the crypto module; [Lang: para 0028-0030; coprocessor of the hardware security module hosts physical crypto domains (i.e. confidential environment). Control domains are used to administer the coprocessors of the hardware security module. The control domains are defined in an image activation profile. A hardware management console (HMC) used for defining and/or setting up the image activation profile, where a number of logical partitions and/or a number of processors is defined. Para 0044; another example of the hardware resource required for running the crypto module is determined by an image activation profile. The limitation “a confidential computing environment” is not defined nor suggest what constitutes as a confidential computing environment. Thus, the domain or processor may broadly be a confidential computing environment]
the crypto module is configured to acquire a key file and obtain a key for a crypto operation based on the key file in the confidential computing environment; and [Lang: para 0012; Configuration of the secure storage device may securely be stored, protected by a system specific key (i.e. key file), and maintained in a crypto card. Checking of these configuration data may be performed in every scenario where the configuration might have changed. See also para 0043-0045; discussion of firmware key for generating a hash with association to trusted key entry flag which corresponds to the crypto card of the domain (i.e. confidential environment). The secure binding process is started by generating a secure hash with the OSid and a system firmware key as a certificate. The secure hash is loaded by the operating system instance into the crypto card, followed by a verifying process in the crypto card. Para 0057; the firmware of the crypto card sends the secure hash to the crypto card]
**the crypto application is configured to send a verification request to the crypto module to verify the integrity of the crypto module in the confidential computing environment [**rejected under a secondary reference, discussion below], wherein in response to the crypto module being integral, the crypto application invokes the crypto module to perform the crypto operation. [Lang: para 0033; initialization of a computer system with hardware security modules. Para 0044; crypto card as hardware security module is initialized in a secure boot process]
Lang provides in FIG. 2 that depicts a flow chart for initialization of a computer system with hardware security modules [Lang: para 0033]. Thus, suggest ability to a confidential computing environment created based on the hardware resource required for running the crypto module. However, Lang does not clearly teach “sending, by a crypto application, a verification request to the crypto module to verify the integrity of the crypto module”.
Krawczewicz teaches the present invention provides a localized security architecture for a smartphone based upon an NFC crypto module. The crypto module is the hardware trust anchor when connected to a smartphone [Krawczewicz: para 0040]. The crypto module can actively respond to a data breach by terminating all trusted processes, make sure that any unprotected private data is encrypted and stored, erase unprotected keys, and block any further requests for trusted processes [Krawczewicz: para 0069]. Leveraging the hardware encryption processor incorporated in the commercial smartphone transceiver chip, the crypto module architecture integrates a compatible hardware cryptographic processor [Krawczewicz: para 0115]. Further, Art discusses another security feature of the crypto module and the trusted NFC bus is to cryptographically verify using a digital signature algorithm. To achieve these security measures and prevent malicious running apps from access, the crypto module continually verifies the proper access and data bus configuration between the application processor and the peripherals [Krawczewicz: para 0208]. As such, Krawczewicz obviously suggest “sending, by a crypto application, a verification request to the crypto module to verify the integrity of the crypto module”, where one would be motivated to securely tether to the smartphone to proceed with any requested secure processing and continually verify the proper access.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Krawczewicz with Lang to teach “sending, by a crypto application, a verification request to the crypto module to verify the integrity of the crypto module” for the reason to continually verify the proper access and securely tether to the smartphone to proceed with any requested secure processing [Krawczewicz: para 0208].
Claim 13: Lang: para 0012, 0028 [The image profile specifies the coprocessor of the hardware security module and the crypto domain] in view of Krawczewicz: para 00 [suggesting “CLAIM”, under the same pretext and motivation as in claim 1]; discussing the crypto operation system according to claim 12, wherein the crypto module manager comprises: an information acquisition unit, configured to acquire image information of the crypto module; a resource determination unit, configured to determine a hardware resource required for running the crypto module based on the image information of the crypto module; a request generation unit, configured to generate a confidential computing environment creation request based on the hardware resource required for running the crypto module; and a request sending unit, configured to send the confidential computing environment creation request, to enable that the confidential environment manager creates the confidential computing environment matching the running requirement of the crypto module based on the confidential computing environment creation request, wherein the running requirement of the crypto module is compatible with the hardware resource required for running the crypto module.
Claim 14: Lang: para 0024-0028 in view of Krawczewicz: para 00 [suggesting “request… the confidential computing environment creation request”, under the same pretext and motivation as in claim 1]; discussing the crypto operation system according to claim 13, wherein the confidential environment manager comprises: a request acquisition unit, configured to acquire the confidential computing environment creation request sent by the crypto module manager; and an environment creation unit, configured to create the confidential computing environment matching the running requirement of the crypto module based on the confidential computing environment creation request.
Claim 15: Lang: para 0014; discussing the crypto operation system according to claim 12, further comprising a crypto operation module configured to assist the crypto module in performing the crypto operation in the confidential computing environment.
Claim 16: Lang: para 0013; discussing an electronic device, comprising at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions; and the processor invokes the one or more computer-executable instructions to perform the method for creating a confidential computing environment according to claim 1.
Claim 17: Lang: para 0014; discussing the storage medium, storing one or more computer-executable instructions, wherein the one or more computer-executable instructions, when executed, implement the method for creating a confidential computing environment according to claim1.
Claim 18: Lang: para 0028, 0044-0045 [crypto card as hardware security module is initialized in a secure boot process. Secure hash loaded by the operating system instance into the crypto card, followed by a verifying process in the crypto card] in view of Krawczewicz: para 0010, 0208 [suggesting “sending, by a crypto application, a verification request”, under the same pretext and motivation as in claim 1]; discussing the crypto operation method, applied to a confidential computing environment created by the method for creating a confidential computing environment according to claim 5, and comprising: acquiring a key file and obtaining a key for a crypto operation based on the key file, by a crypto module; sending, by a crypto application, a verification request to the crypto module to verify the integrity of the crypto module; and in response to the crypto module being integral, invoking, by the crypto application, the crypto module to perform the crypto operation.
Claim 19: Lang: para 0012, 0028 in view of Krawczewicz: para 0116 [suggesting “decrypting”, under the same pretext and motivation as in claim 1]; discussing the crypto operation method according to claim 18, wherein the crypto module comprises a sealing key; and the obtaining, by the crypto module, the key for the crypto operation based on the key file comprises: decrypting, by the crypto module, the key file utilizing the sealing key to obtain the key for the crypto operation.
Claim 20: Lang: para 0044-0045 [crypto card as hardware security module is initialized in a secure boot process. Secure hash loaded by the operating system instance into the crypto card, followed by a verifying process in the crypto card];; discussing the crypto operation method according to claim 19, wherein the crypto module utilizes a crypto operation module to assist in performing the crypto operation; and the invoking, by the crypto application, the crypto module to perform the crypto operation comprises: invoking, by the crypto application, the crypto module, and performing, by the crypto module, the crypto operation utilizing the crypto operation module.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
