DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. Claims 1-11 and 19-20 are currently pending in this application.
Claims 1 and 19 are amended as filed on 04/30/2025.
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.
Claim(s) 1-2, 5-9, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al. (Pre-Grant Publication No. US 2020/0349252 A1), hereinafter Yu, in view of Ibasco et al. (Pre-Grant Publication No. US 2017/0180136 A1), hereinafter Ibasco.
2. With respect to claims 1 and 19, Yu taught a computer system comprising: one or more processors configured to execute instructions to cause the computer system to perform operations (0044); and a non-transitory computer accessible storage medium coupled to the one or more processors and configured to store a plurality of instructions forming a secure execution environment controller configured to control a secure execution environment including a first code sequence (0044, the code that is executing, which implements the trusted applications), wherein the secure execution environment is configured to execute the first code sequence on input data provided from a separate computer system over a trusted channel to generate output data (0044, where the output data can be seen in 0114), and wherein the secure execution environment controller is configured to cause the computer system to digitally sign the output data (0023), the secure execution environment controller is configured to cause the computer system to digitally sign the response packet to attest to the execution of the input data in the first code sequence which is unaltered from its installation in the computer system to produce the output data in a specific secure execution environment at a specific time (0043, where the validity of the transaction implicitly teaches the unaltered input data. However, even assuming arguendo that said limitations are not implicitly taught by the validity clause, it would still be reasoned that the system does not claim to ensure the unaltered input data. Rather, the system claims that the digital signature is an attestation of unaltered input data. In other words, claiming, in such a way, that the data has been unaltered is to claim the intended use and/or results of the invention and is thus, not provided patentable weight).
However, Yu did not explicitly state that the system was configured to implement one or more hardware security module functions and that the secure execution environment controller is configured to generate a response packet that includes the output data and data describing the input data and the first code sequence. On the other hand, Ibasco did teach that the system was configured to implement one or more hardware security module functions (claim 13, where the secure environment can be seen by the TEE of 0046) and that the secure execution environment controller is configured to generate a response packet that includes the output data and data describing the input data and the first code sequence (claim 13, where the first code sequence was the authentication request of the response is output). Both of the systems of Yu and Ibasco are directed managing secure trusted environments and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Yu to teach output the specified data from the trusted environment, as taught by Ibasco, in order to provide a more secure environment.
3. As for claim 2, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment is configured to transactionally execute the first code sequence (0032, where the transactions implement the invention, which implements the code sequence), such that the same output is produced by the each execution of the first conde sequence on the same input (Maheshwari: 0067 & 0071, where the encrypted logs will produce the same output).
4. As for claim 5, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment controller is configured to generate a hash of the first code sequence and is configured to include the hash in the digitally signed response packet (0062).
5. As for claim 6, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment controller is configured to capture a time stamp that corresponds the execution of the first code sequence, and wherein the secure execution environment controller is configured to include the time stamp in the digitally signed response packet (0038, where the blockchain is generated by the secure environment & the digital signature can be seen in 0062).
6. As for claim 7, it is rejected on the same basis as claim 6. In addition, Yu taught wherein the time stamp indicates a time at which execution finished and the output data is calculated (0038).
7. As for claim 8, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment controller is configured to generate a hash of the input data, wherein the secure execution environment controller is configured to include the hash in the digitally signed response packet (0062).
8. As for claim 9, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment controller is configured to collect environment data describing hardware or software configuration of the computer system, and wherein the secure execution environment controller is configured to include the environment data in the digitally signed response packet (0023, where the environment data is implicitly taught as any data associated with the TEE under broadest reasonable interpretation).
Claim(s) 3-4 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yu, in view of Ibasco, and in further view of Smith et al. (Pre-Grant Publication No. US 2022/0141026 A1), hereinafter Smith.
9. As for claim 3, it is rejected on the same basis as claim 2. However, Yu did not explicitly state wherein the secure execution environment controller is configured to delete the secure execution environment subsequent to transmitting the response packet to the separate computer system. On the other hand, Smith did teach wherein the secure execution environment controller is configured to delete the secure execution environment subsequent to transmitting the response packet to the separate computer system (0287). Both of the systems of Yu and Smith are directed towards managing trusted execution environments and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Yu, to utilize deleted and expired application that’s operating in a TEE, as taught by Smith, as this frees up processing resources for the executions, which maintains the system’s efficiency.
10. As for claim 4, it is rejected on the same basis as claim 3. In addition, Smith taught wherein the secure execution environment controller is configured to instantiate the secure execution environment subsequent to deletion of the secure execution environment and to load the first code sequence into the secure execution environment (0287, where the instantiation is given in order for the system to be able to handle a plurality of executions).
11. As for claim 20, it is rejected on the same basis as claim 19. In addition, Yu taught transactionally executing the first code sequence (0032, where the transactions implement the invention, which implements the code sequence); and deleting the specific secure execution environment subsequent to transmitting the response packet to the separate computer system (Smith: 0287, where the response transmission is taught by Yu: 0047). Both of the systems of Yu and Smith are directed towards managing trusted execution environments and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Yu, to utilize deleted and expired application that’s operating in a TEE, as taught by Smith, as this frees up processing resources for the executions, which maintains the system’s efficiency.
Claim(s) 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Yu, in view of Ibasco, and in further view of Chhabra (Patent No. US 10,460,130 B1).
12. As for claim 10, it is rejected on the same basis as claim 1. In addition, Yu taught wherein the secure execution environment controller is configured to request a counter value maintained by the computer system, wherein the computer system is configured to modify the counter value based on the request from the secure execution environment controller, and wherein the secure execution environment controller is configure to include a value corresponding to the counter value in the digitally signed response packet (14:53-65). Both the systems of Smith and Chhabra are directed towards managing trusted operating environments and therefore, it would have been obvious to a person having ordinary skill in the art, at the time of the effective filing of the invention, to modify the teachings of Yu, to utilize counters to track executions/operations, as taught by Chhabra, in order to provide systems that operate more accurately to expectations.
13. As for claim 11, it is rejected on the same basis as claim 10. In addition, Chhabra taught wherein the counter value is one of a plurality of counter values maintained by computer systems in a cluster, and wherein the computer system is configured to include a sum of the plurality of counter values as the value in the digitally signed response packet (14:53-65 & 14:1-32, where the clustered environment can be seen in 24:43-51).
Response to Arguments
Applicant's arguments filed 10/24/2025 have been fully considered but they are not persuasive.
14. The applicant argues on pages 7-8 that “as can be seen above in Fig. 1, Ibasco’s TEE and HSM are associated with separate devices—i.e., Ibasco’s smartphone/authentication device 12 and host server 16, respectively. In contrast, claim 1 recites the same “computer system [as] configured to implement one or more hardware security module (HSM) functions” and the “secure execution environment controller.” Accordingly, Ibasco’s smartphone 12 is not described as “implement[ing] one or more hardware security module (HSM) functions,” as recited in claim 1; Ibasco’s host server 16 is not described as implementing “a secure execution environment controller,””.
However, assuming arguendo that the above state is correct, the claim does not require that a single device contain the HSM and Secure Execution Environment. Claim 1 is directed towards a system that comprises (potentially) a plurality of devices. Accordingly, claim 19 is directed towards a method of operating a system containing the aforementioned features. Thus, the claimed limitations have been shown.
15. The applicant also argues on page 8 that “Ibasco never describes its smartphone/authentication device 12 as “generat[ing] a response packet that includes the output data and data describing the input data and the first code sequence” (emphasis), as recited in claim 1. Again, Ibasco merely describes its “authentication device” as producing “encrypted data compris[ing] information relating to the transaction, a personal identification number (PIN), and a digital signature.” /d. at ¢ [0012]. At a minimum, none of these are “data describing ... the first code sequence,””.
However, as cited in the claim rejection, claim 13 teaches a first code sequence (i.e. authentication request) to which the system responds after validation (i.e. the response to the prompt). Neither the claims nor the specification specifically define a first code sequence. Thus, the limitations are taught, at least, based on the broadest reasonable interpretation of a first code sequence receiving a response.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(a) Zage et al. (Pre-Grant Publication No. US 2022/0138286 A1), 0333, 0257.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH L GREENE whose telephone number is (571)270-3730. The examiner can normally be reached Monday - Thursday, 10:00am - 4:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas R. Taylor can be reached at 571 272-3889. 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.
/JOSEPH L GREENE/Primary Examiner, Art Unit 2443