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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/11/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments, see page(s) 10 and 11, filed 6/5/2026, with respect to interpretation of claim(s) 1, 5, and 7 under 35 U.S.C. 112(f) have been fully considered and are persuasive. The associated claim(s) is/are no longer being interpreted under this statute.
Applicant’s arguments, see page(s) 11 and 12, filed 6/5/2026, with respect to the rejection of claim(s) 1-8 under 35 U.S.C. 112(b) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see page(s) 12-18, filed 6/5/2026, with respect to the rejection of claim(s) 1-8 under 35 U.S.C. 103 have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Claim Objections
Claim(s) 13 is/are objected to because of the following informalities:
Regarding claim 13:
This claim is not present in the previous draft of the claims, but is lacking the required markup. The claim should be preceded by the label “(New)” to indicate that it is a newly added claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claim(s) 1-14 is/are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contain(s) subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding insufficient written description in claims 1 and 8:
Claim 1 recites, “… receive … an instruction … to tamper with the designated part of the verification software …”. Claim(s) 8 recite(s) similar language. The specification fails to adequately describe this limitation. While there are numerous references to performing tampering throughout the specification, the original disclosure fails to describe how this tampering is accomplished. The specification teaches at ¶ 0070 that the “designated part” refers to either a “binary part” or a “signature part,” where the “signature part” is a hash value of the binary part. It may be inferred that the action of tampering somehow affects the “binary part,” which in turn alters the hash value (“signature part”); however, it is unclear how the “binary part” is altered, or even to what, specifically, the “binary part” refers. Specification ¶ 0071 indicates that the “binary part” may refer to some part of the binary code representing selected verification software, but there is no indication of what part of the code represents the “binary part,” if this interpretation is even the case.
These rejections can be overcome by amending the claim(s) such that they recite only that subject matter which is has adequate description in the original disclosure.
It is important to note that in regards to an adequate written description, “It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015)” (MPEP 2161.01).
Regarding new matter in claim(s) 2 and 9:
Claim 2 recites, “… the first management-controller firmware verifies the second management-controller firmware …” Claim(s) 9 recite(s) similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitute new matter. The specification at ¶ 0046, “The first MGC activation program 211 activates other programs in the first MGC firmware 210, which include the first MGC verification program 212.”, and at ¶ 0047 recites, “The first MGC verification program 212 verifies the second MGC firmware 220 …”. The specification is explicit that the “management-controller firmware” is distinct from, though located within, the “management-controller verification program.”
Claim 2 also recites, “… the OS and management software verifies the first disk-controller firmware …”. Claim(s) 9 recite(s) similar language. Similar to above, the original disclosure is explicit that what performs the claimed verification is the “first DKC verification program,” which is distinct from, though located within, the “OS and management software.”
Claim 2 also recites, “… the first disk-controller firmware verifies the second disk-controller firmware …”. Claim(s) 9 recite(s) similar language. Similar to above, the original disclosure is explicit that what performs the claimed verification is the “second DKC verification program,” which is distinct from, though located within, the “first DKC firmware.”
These rejections can be overcome by amending the claim(s) such that they recite only that subject matter which is explicitly supported by the original disclosure.
Regarding new matter in claim(s) 5, 6, 12, and 13:
Claim 5 recites, “… the storage controller stores A-side software and B-side software, the management controller is configured to update only the A-side software with the verification software having the designated part tampered with …”. Claim(s) 12 recite similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitute new matter. Specification ¶ 0076 seems to describe a typical A/B software update process, where the software is updated with the tampered with software, presumably to monitor it while it executes to assess whether tamper is detected. The claims, on the other hand, indicate that the tampered-with software performs an update on “normal software” which is subject to the A/B update process. It seems clear that this claim is meant to reference the above specification paragraph; however, the claims must be examined as they are written, and not how they are presumed to be interpreted. This rejection can be overcome by amending the claims such that they accurately recite the subject matter from the specification.
Claims 6 and 13 depend on claims 5 and 12, respectively, and while they represent new matter in the current context of their parent claims, their current wording would not be problematic were their parent claims amended as indicated above to recite supported subject matter from the original disclosure.
Regarding claims 3, 4, 7, 10, 11, and 14:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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.
Claim(s) 1- 14 is/are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim(s) 1 and 8:
Claim 1 recites, “…selecting a designated part of the verification software to be tampered with …”, and other limitations referencing a “designated part.” Claim(s) 8 recite similar language. The claims are indefinite because it is unclear to what this “designated part” refers. The specification at ¶ 0071 describes selecting from a “binary part” or a “signature part”; however, it is unclear what “part” means in this context. While it seems clear that they represent some portion of the verification software chosen One of ordinary skill in the art is left to question what actually constitutes each “part.” Specification ¶ 0070 teaches that the “binary part” is the “program part,” but this does nothing to further explain the element. It is ambiguous whether the “binary part” is meant to be a complete representation of the binary code of the verification software, or only a portion of it. If only a portion, which portion is also unclear. Similarly, while the specification describes the “signature part” as a hash value of the “binary part,” it is unclear which part is hashed and whether this hash is meant to correspond to the hash value which is validated during the secure boot process.
Regarding claim(s) 4 and 11:
Claim 4 recites, “… the verification software performs only secure boot, and omits, from normal software to be installed in the storage system, at least one function selected from changing a volume structure, setting hosts, and host input/output processing.” Claim(s) 11 recite similar language. The claims are indefinite because it is unclear what action is being performed, or what limitation is being described. The claims and specification at ¶ 0057 begin by describing the “verification software” as only performing a secure boot process. It then indicates that the verification software somehow removes a list of functions from “normal software” which is “to be installed.” The claims are indefinite because they are self-contradictory. Actively removing or omitting functions from other software constitutes more than performing only a secure boot. It is also unclear by what mechanism such a function occurs. This rejection can be overcome by amending the claims such that it is made clear what function is being claimed.
Regarding claim(s) 7 and 14:
Claim 7 recites, “… information indicating a current verification status including a program structure of the verification software …, and to present the information on the output device to the user.” Claim(s) 14 recite similar language. The claims are indefinite because it is unclear what a “program structure” means in the context of the claims. Specification ¶ 0096, while not elaborating on the term, indicates that the information displayed to a user is represented in Fig. 14 of the drawings. However, nothing in the specification or drawings represents anything that could be interpreted as a “program structure.” One of ordinary skill in the art would expect a “program structure” to illustrate the packages and libraries used, an explanation of functions and methods called, and a control flow of the program. In contrast, Fig. 14 is captioned as representing “verification status” through a flow chart of various systems that are presumably being verified. This rejection can be overcome by amending the claims such that it is clear what function is being claimed.
Regarding claims 2, 3, 5, 6, 9, 10, 12, and 13:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Allowable Subject Matter
Claim(s) 1 and 8 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112 set forth in this Office action.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 1:
ZIESE (Doc ID US 6567917 B1) teaches the following limitation(s):
A system for performing test for tampering verification in activation of software to be executed by a storage controller, the system comprising: a management device comprising a processor, a memory, an auxiliary storage device, an input device, an output device, and a communication device ((9) Col 4 lines 16-18 "Referring to FIG. 2, a computer method is illustrated for generating the tamper-resistant software. The method begins at step 50 in which an executable file 34 is received."); and
a storage controller comprising a management controller and a disk controller, wherein the auxiliary storage device stores verification software to be executed by the storage controller ((3) Col 3 lines 16-20 "… the computer system 10 includes an input/output system 20, processor or processors 22, and system memory 24. Computer software is loaded into system memory 24 and executed by the processor 22."),
the verification software includes a program for detecting tampering in the verification software ((11) Col 2 lines 24-27 "… software … self-determines whether or not unauthorized tampering has occurred."),
the processor is configured to present, on the output device to a user, a result of verification of tampering by the verification software, which is received from the storage controller ((18) Col 5 lines 55-57 "At step 112, the security file 32 generates an alarm to indicate to an operator that tampering with the executable file 34 has occurred.").
POH et al (Doc ID WO 2013009262 A1) teaches the following limitation(s):
the processor is configured to receive, through the input device, an instruction selecting a designated part of the verification software to be tampered with (Page 25 "Tamper detection capability is evaluated by performing both systematic tampering and real-case tampering."),
The following limitation(s) is/are not taught by ZIESE or POH, alone or in combination:
to tamper with the designated part of the verification software, and
to transmit the verification software having the designated part tampered with to the storage controller for storage in a predetermined memory area in the management controller or the disk controller,
the management controller and the disk controller are configured to activate the verification software stored in the predetermined memory area to start secure boot,
Regarding claim 8:
This claim is allowable with the same justification, mutatis mutandis, as its counterpart claim 1.
Regarding claims 2-7 and 9-14:
These claim(s) is/are objected to as being dependent upon a rejected base claim(s), and would be allowable if the depended-on claim(s) were rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112 set forth in this Office action.
It should be noted that the determination of allowability is made on the combination of all limitations/features recited in the independent claims and not a single limitation.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Conclusion
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 BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights