DETAILED ACTION
A response to the notice of non-compliant amendment was received on 12 May 2026. By the present response, Claims 1-12 and 14 have been amended. No claims have been added or canceled. Claims 1-12 and 14 are currently pending in the present application.
Response to Amendment
The substitute specification does not clearly comply with the requirement of 37 CFR 1.121(b)(3)(ii) and 37 CFR 1.125(c) that the substitute specification must be submitted with markings showing all changes relative to the immediate prior version of the specification of record. In particular, on at least page 12 of the substitute specification (marked-up version), there appears to have been text added without being marked with underlining as required. The substitute specification also does not clearly comply with the requirement of 37 CFR 1.121(b)(3)(ii) and 37 CFR 1.125(c) that the text of any deleted subject matter must be shown by being placed within double brackets if strikethrough cannot be easily perceived, noting that double brackets may also be used to show deletion of five or fewer characters. Throughout the substitute specification, there still appear to be several instances of text (e.g. single letters such as “s”, “a”, or “e”, or words beginning or ending with such letters, as well as punctuation marks and certain numerals) which may be intended to be marked with strikethrough for deletion; however, in the font used, it is difficult to discern whether such text is, in fact, marked with strikethrough. See also MPEP § 714 II.B. Applicant is required to resubmit the substitute specification in a manner fully compliant with 37 CFR 1.121(b)(3)(ii) and 37 CFR 1.125.
Further, the amendment to the abstract in the response filed 13 January 2026 was considered to be part of the amendments to the specification, which were indicated as non-compliant in the notice mailed 05 May 2026. Applicant is hereby required to resubmit the amendments to the abstract on their own page as per 37 CFR 1.72 to avoid any confusion, so that the compliant amendments may be entered.
Response to Arguments
Applicant's arguments filed 13 January 2026 have been fully considered but they are not persuasive.
Regarding the objections to the drawings, Applicant states that reference characters 7a-7d and 19 have been removed from Figure 3 (renumbered as amended Figure 2) and all reference characters now appear in the description (page 10 of the 13 January 2026 response). However, reference numeral 19 still appears in amended Figure 2 but not in the specification. Applicant further asserts that reference character 12 “refers to ‘connector/interface’” (page 11 of the 13 January 2026 response). However, it does not appear that reference numeral 12 in Figure 2 shows such a connector or interface and appears to instead show some sort of data flow. It is still not clear what this is intended to refer to. Applicant also states that the labels “n” and “T” have been removed from Figure 2 (page 12 of the 13 January 2026 response). However, the label “n” still appears in at least one place in amended Figure 2.
Regarding the rejection of Claims 1-12 and 14 under 35 U.S.C. 112(a) for failure to comply with the enablement requirement, Applicant argues that the specification describes a security evaluation mechanism based on recorded execution behavior of duplicated network sessions in emulated infrastructure followed by comparison against previously established signature information, generally pointing to the specification as describing, inter alia, comprising said signature information to previously established signatures to compute a security index (pages 13-14 of the 13 January 2026 response, no particular citations to the specification provided), and Applicant further argues that the security index is not abstract or undefined but is instead a quantitative or qualitative metric derived from behavioral similarity analysis, as allegedly described in the specification (page 14 of the 13 January 2026 response, no particular citations to the specification provided). However, none of this provides a particular algorithm, equation, or other example by which to derive such a metric from such analysis. Although Applicant asserts that the disclosure teaches that the security index represents a distance or similarity measure between observed behavior and known malicious behavior and that such parameters may be evaluated in a multi-dimensional space (page 14 of the 13 January 2026 response, no particular citations to the specification provided). However, to the extent that the specification describes a distance or similarity measure and parameters in a multi-dimensional space (see page 5, lines 22-27 of the specification as originally filed), this portion merely states that this “allows the comparison and hence the calculation of an index”. There is nothing in the specification that defines an algorithm or equation of how the comparison of behavior (in the specification) or of signature information (in the claims) would map that comparison to the calculation of an index, nor is there anything that actually describes how “behavior” would be mapped to something for which a distance could be calculated. As per MPEP § 2161.01, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed (emphasis in original). Although Applicant asserts that one of ordinary skill in the art “would readily understand how to implement such an index using known similarity functions, clustering techniques, rule-based evaluation, or heuristic scoring mechanisms, all of which are expressly contemplated by the specification” (page 14 of the 13 January 2026 response, no particular citations to the specification provided), Applicant has provided no evidence or explanation in support of this assertion. Applicant has not explained where the specification describes the implementation of an index using any of these functions, and it appears that there is no description of using any of these functions or mechanisms to generate an index. As previously set forth, there is no equation, algorithm, or other example for how comparing two signatures would lead to the computation of a security index as claimed. Although Applicant asserts that “the specification need only teach how to make and use the invention without undue experimentation, which it does” (page 15 of the 13 January 2026 response), this statement is conclusory. In contrast, the lack of details or examples in any detail suggests that there is little direction provided by the inventor (MPEP § 2164.02 and 2164.03). Combined with the broad scope of the claims, this suggests that the enablement of the description is not commensurate in scope with the claims (MPEP § 2164.08) and that undue experimentation would be required to make or use the invention based on the disclosure (MPEP § 2164.06).
Applicant also asserts, under the heading of the rejection of Claims 1-12 and 14 under 35 U.S.C. 112(b) as indefinite, that executing the computing instructions as a function of the security index is definite (page 15 of the 13 January 2026 response). However, this limitation was not included in the indefiniteness rejection under 35 U.S.C. 112(b), but rather was also discussed in the context of the lack of enablement with respect to the rejection under 35 U.S.C. 112(a). Although Applicant asserts that the specification explains that the security index governs whether computing instructions are executed in the requested infrastructure, blocked, restricted, redirected to emulated infrastructure, or subjected to monitoring or further interaction (page 15 of the 13 January 2026 response, no particular citations to the specification provided), it does not appear that there is a clear mapping or example provided of what values of the index, for example, would lead to which of those system behaviors, because there are no particular values or mapping of the index described in the specification. Again, the lack of details or examples in any detail suggests that there is little direction provided by the inventor (MPEP § 2164.02 and 2164.03). Combined with the broad scope of the claims, this suggests that the enablement of the description is not commensurate in scope with the claims (MPEP § 2164.08) and that undue experimentation would be required to make or use the invention based on the disclosure (MPEP § 2164.06).
Regarding the rejection of Claims 1-12 and 14 under 35 U.S.C. 112(b) as indefinite, Applicant generally asserts that terms such as emulating, scanning, and recording execution are used consistently throughout the specification and are technically well-understood in the context of virtualization, sandboxing, and intrusion detection systems, and that the specification provides examples and architectures illustrating such operations (pages 15-16 of the 13 January 2026 response, no particular citations to the specification provided). However, this assertion does not appear to directly address any particular issue of indefiniteness set forth in the previous Office action. The amendments to the claims have addressed certain issues of indefiniteness, but have raised new issues, and other issues have not been clearly addressed, as detailed below in the revised rejections.
Regarding the rejection of Claims 1-12 and 14 under 35 U.S.C. 102(a)(1) as anticipated by Aziz et al, US Patent 8898788, and with particular reference to amended independent Claim 1, Applicant generally argues that Aziz does not disclose executing duplicated network session information “in any case” and asserts that Aziz only intercepts the data if it is determined that there is a possible malware attack (pages 17-18 of the 13 January 2026 response, citing Aziz, Figure 4). Applicant argues that the claims do not require a preliminary determination of whether the network session information possibly contains malware before executing it in the emulated infrastructure and that the invention teaches that the duplicated network session information is executed in the emulated infrastructure in any case, whereas in Aziz, network data that is not suspicious bypasses the virtual machine analysis (page 18 of the 13 January 2026 response). In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., executing in the emulated infrastructure “in any case”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims do not clearly require that all network session information must be copied/duplicated and executed in the emulated infrastructure, and the claims do not clearly exclude some data bypassing the virtual machine analysis.
Applicant further argues that Aziz does not disclose that the duplicated network session identification is assigned new identifier and the original network session information remains in a secure area unused as recited in amended Claim 1 (page 19 of the 13 January 2026 response, no evidence cited). Although Applicant alleges that Aziz discloses that the copied network data is analyzed directly, this would appear to correspond to the duplicated network information being analyzed rather than the original network information, and thus comports with the claim. Aziz also discloses quarantining the packets (i.e. the network data remains in a secured area and is not used, see column 11, lines 53-65, packets quarantined and routed away from intended destination device; see also column 10, lines 56-58, various identifiers such as addresses).
Applicant additionally argues that Aziz does not disclose that the previously established signature information is stored as a function of data transmissions from several computing devices and data transmissions to several requested infrastructures as recited in amended independent Claim 1 and does not create a global database of attack signatures or enable a global approach (page 20 of the 13 January 2026 response, no evidence cited). In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a “global database”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Further, Aziz does disclose that the previously established signature information is based on data transmissions from plural computing devices or to plural infrastructures (see column 10, line 62-column 11, line 21, plural network data intended for plural destinations and routed to plural virtual machines; see also column 5, lines 17-25, any number of sending and receiving devices).
Therefore, for the reasons detailed above, the Examiner maintains the rejections as set forth below.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The objections to the drawings for failure to comply with 37 CFR 1.84(p)(4) and (5) are partially withdrawn, because not all issues have been addressed. The objection to the drawings for informalities is not withdrawn, because not all issues have been fully addressed as discussed above and because the amendments have raised new issues, as detailed below.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: 19 (see Figure 2 as amended). Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application.
The drawings are objected to because they include informalities. In Figure 1, in steps 100-107, the capitalization of the first word in each step is inconsistent. In step 103, “a” should be deleted before “duplicated network session information” because “information” is an uncountable noun that does not take the indefinite article. In step 104, it appears that “information” should be inserted after “duplicated network session”. In step 105, it is not clear what “this signature information” is intended to refer to. In Figure 2, it is not clear what reference character 12 is intended to refer to. In Figure 2, it is also not clear what the label “n” is intended to refer to. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application.
Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
As noted above, the abstract and substitute specification must be resubmitted in a manner fully compliant with 37 CFR 1.121(b) and 1.125. The objection to the abstract is conditionally withdrawn in light of the non-entered amendments to the abstract filed 13 January 2026, and will be withdrawn upon the re-filing and entry of the compliant amendments to the abstract. The objection to the disclosure has been considered to the extent possible in light of the non-entered substitute specification, and new issues in the substitute specification are detailed below.
The disclosure is objected to because of the following informalities:
The specification includes minor grammatical and other errors. For example, on page 2, line 28 (where all page and line numbers are with reference to the non-entered marked-up copy of the substitute specification filed 12 May 2026), it is not clear what the subject of the verbs “operates” and “evaluates” are intended to be. For example, it is not clear if the subject is intended to be the method and network component, or the infrastructure, the computer network, or the attacks. On page 8, line 15, the phrase “the record is evaluated” is not clear with respect to what “the record” is, and on page 8, line 17, it is not clear what it means if “the index is positive” in context. On page 12, the list at lines 12-18 is not clear as to what elements of the list go together because there are now multiple conjunctions; further, it appears that it may be appropriate to separate the list items using semicolons because it appears that some of the list items may include internal commas. On page 15, lines 11-12, the descriptions of A and B as a new and original session, respectively, does not clearly correspond to the use of A and B in Figure 2.
Appropriate correction is required. Applicant’s cooperation is again requested in correcting any other errors of which applicant may become aware in the specification.
The amendment filed 12 May 2026 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows: a Network Address Translation (NAT) identifier (see page 7, lines 12-13 of the marked-up copy of the substitute specification, as well as Claim 4).
Applicant is required to cancel the new matter in the reply to this Office Action.
Claim Objections
The objections to Claims 1-12 and 14 for informalities are withdrawn in light of the amendments to the claims.
Claim Rejections - 35 USC § 101
The rejection of Claim 14 under 35 U.S.C. 101 is withdrawn in light of the amendments clearly limiting the claim to non-transitory computer-readable media.
Claim Rejections - 35 USC § 112
The rejections of Claims 1-12 and 14 under 35 U.S.C. 112(a) for failure to comply with the enablement requirement and under 35 U.S.C. 112(b) as indefinite are NOT withdrawn, for the reasons detailed above, because not all issues have been addressed, and/or because the amendments have raised new issues, as detailed below.
The following is a quotation 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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1-12 and 14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claims contain subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
A determination of a failure to comply with the enablement requirement is made considering the undue experimentation factors set forth in MPEP § 2164.01(a). In the present application, the factors which appear to weigh most heavily are the breadth of the claims (MPEP § 2164.08), the amount of direction provided by the inventor (MPEP § 2164.03), and the existence of working examples (MPEP § 2164.02). Independent Claims 1, 12, and 14 broadly recite “comparing (105) this signature information with previously established signature information… thereby computing (106) a security index” or similar language. The phrase “computing a security index” is a broad recitation, and although the claims recite that the computing is performed by the comparison of the signature data, there are no details of the steps used to actually compute the index or how simply comparing data would result in computation of an index. Although the specification generally discusses similarity being above a threshold or that behavior can be described by parameters in a multi-dimensional space (page 5, lines 22-27), there appears to be no detail provided in the specification of how similarity is calculated, how to determine a threshold, or how the multi-dimensional parameters may be used to compute the index. The specification appears to have no specific algorithm, instructions, or other working example of how the index is to be computed. The independent claims also recite “executing (107) the computing instructions in the requested infrastructure as a function of the security index” or similar language. The phrase “as a function of the security index” is a broad recitation, and there are no details in the claims or specification of the steps used to execute the instructions “as a function of the index”. Although the specification generally discusses merely executing instructions if the index reveals no attack (page 5, lines 28-30), there appears to be no detail provided in the specification of how the instructions are actually executed “as a function of the index”. The specification appears to have no specific algorithm, instructions, or other working example of how the instructions are to be executed as a function of the index. The lack of details or examples in any detail suggests that there is little direction provided by the inventor. Combined with the broad scope of the claims, this suggests that the enablement of the description is not commensurate in scope with the claims (MPEP § 2164.08) and that undue experimentation would be required to make or use the invention based on the disclosure (MPEP § 2164.06).
Claims not explicitly referred to above are rejected due to their dependence on a rejected base 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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-12 and 14 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 1 recites “the original network session information” in line 16. There is not clear antecedent basis for “original” network session information, although for the purposes of interpreting the prior art, it has been assumed that this is intended to refer to the received network session information. The claim further recites “storing (104)… the execution of the computing instructions” in lines 18-19. It is not clear how the “execution” is to be stored. The claim additionally recites “several” in lines 23 and 24. The term “several” is, by definition, an indefinite quantity and is therefore ambiguous. The above ambiguities render the claim indefinite.
Claim 2 recites “at least one actions of a group of actions the group comprising…” in line 4. This does not properly define a Markush group because a Markush group must be a closed group defined by “consisting of”. See MPEP § 2173.05(h). The claim further recites “restricting access of the at least one computing device” in line 4. It is not clear what access is actually restricted (i.e. access to what is restricted). The claim additionally recites “the computing device” in line 8. It is not clear to which of the plural computing devices (e.g. the at least one computing device of Claim 1, lines 4-5, or the several computing devices of Claim 1, line 23) this is intended to refer.
Claim 3 recites “a new identifier” in line 3. It is not clear whether this is distinct from the new identifier in Claim 1.
Claim 5 recites a list of what the emulation comprises in lines 3-7. It is not clear whether “providing at least one of predefined functionality or an imitation of an infrastructure configuration” is intended to be a single item of the list or if the providing and imitation here are two separate items. If they are a single item, then the list appears to be missing a coordinating conjunction (e.g. “and” or “or”) defining whether all of the list items are required or if they are alternatives. The use of an Oxford comma may clarify the list items, or if the list items include internal commas, then semicolons should be used to separate the list items.
Claim 7 recites “several” in line 5. The term “several” is, by definition, an indefinite quantity and is therefore ambiguous.
Claim 12 recites “the new network session information” in line 16. There is not clear antecedent basis for “new” network session information, although for the purposes of interpreting the prior art, it has been assumed that this is intended to refer to the duplicated network session information. The claim further recites that “the duplicated network session information remains in a secured area and is left unused” in lines 17-18; however, the claim subsequently recites storing the duplication network session information in lines 20-21 and comparing the signature information that includes the duplicated network session information in lines 22-24. This appears to be contradictory because it is a further use of the duplicated network session information. The claim additionally recites “store (104)… the execution of the computing instructions” in lines 20-21. It is not clear how the “execution” is to be stored. The claim also recites “several” in lines 25 and 26. The term “several” is, by definition, an indefinite quantity and is therefore ambiguous. The above ambiguities render the claim indefinite.
Claim 14 recites “the requested infrastructure” in line 9. There is not clear antecedent basis for this limitation; it is not clear whether this is intended to refer to the infrastructure of line 4 or a more specific element. The claim further recites “the original network session information” in line 18. There is not clear antecedent basis for “original” network session information, although for the purposes of interpreting the prior art, it has been assumed that this is intended to refer to the received network session information. The claim further recites “storing (104)… the execution of the computing instructions” in lines 20-21. It is not clear how the “execution” is to be stored. The claim additionally recites “several” in lines 25 and 26. The term “several” is, by definition, an indefinite quantity and is therefore ambiguous. The above ambiguities render the claim indefinite.
Claims not explicitly referred to above are rejected due to their dependence on a rejected base claim.
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.
Claims 3 and 7 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, fourth 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 3 only requires that the duplicated network session information is assigned a new identifier. However, amended Claim 1 now also requires that the duplicated network session information is assigned a new identifier, and therefore, Claim 3 does not further limit the subject matter of Claim 1 from which it depends.
Claim 7 only requires that the previously established signature information is stored as a function of at least one of data transmissions from a plurality of computing devices or data transmissions to several requested infrastructures. However, amended Claim 1 now also requires that the previously established signature information is stored as a function of data transmissions from several computing devices or to several requested infrastructures. Therefore, Claim 7 does not further limit the subject matter of Claim 1 from which it depends.
Applicant may cancel the claims, amend the claims to place the claims in proper dependent form, rewrite the claims in independent form, or present a sufficient showing that the dependent claims comply with the statutory requirements.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-12 and 14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Aziz et al, US Patent 8898788.
In reference to Claim 1, Aziz discloses a method for securing requested infrastructure in a computer network against malicious attacks, where the method includes receiving network session information from at least one computing device over a network, where the session information includes computing instructions to be performed in the requested infrastructure (column 4, lines 42-44; column 3, lines 6-7; column 8, lines 8-13); scanning and emulating the requested infrastructure (column 7, lines 1-17); executing duplicated network session information using the emulated infrastructure and recording execution of the computing instructions (column 4, lines 50-56; column 8, lines 8-16) where the duplicated network session information is assigned a new identifier with which it is addressed and the original network session information remains in a secured area and is left unused (column 11, lines 53-65, packets quarantined and routed away from intended destination device; see also column 10, lines 56-58, various identifiers such as addresses); storing the duplicated network session information as signature information, comparing the signature information with previously established signature information based on a similarity function, and computing a security index (column 5, lines 62-63; column 6, lines 7-15; column 13, lines 31-39; column 8, lines 59-64; column 9, lines 8-13; column 13, lines 22-25) where the previously established signature information is stored as a function of data transmissions from plural computing devices and to plural infrastructures (see column 10, line 62-column 11, line 21, plural network data intended for plural destinations and routed to plural virtual machines; see also column 5, lines 17-25, any number of sending and receiving devices); and executing the computing instructions in the requested infrastructure (column 14, lines 1-4; column 15, lines 12-14).
In reference to Claim 2, Aziz further discloses blocking a computing device, restricting the device’s access, recording requests from the device, or executing predefined response commands (column 15, lines 12-17).
In reference to Claims 3 and 4, Aziz further discloses assigning a new identifier and that the session information includes an IP address, identifiers, port numbers, time stamps, or packets (column 10, lines 56-58, for example).
In reference to Claims 5, 6, and 11, Aziz further discloses imitating hardware, software, or database behavior or infrastructure configuration, or providing predefined or random data sets or functionality, where the requested and emulated infrastructure are secured, separately operated on different hardware or software components or restricted from exchanging data (column 7, lines 19-21).
In reference to Claim 7, Aziz further discloses the previously established signature information is stored (column 13, lines 31-39).
In reference to Claim 8, Aziz further discloses a security risk, violation of an access right, an addressed component, or an identifier (column 8, lines 33-35).
In reference to Claims 9 and 10, Aziz further discloses reconfiguring the emulated infrastructure according to stored configuration and that infrastructure descriptions are read from storage (column 7, lines 4-6).
Claim 12 is directed to a network component having functionality corresponding to the method of Claim 1, and is rejected by a similar rationale, mutatis mutandis.
Claim 14 is directed to a software implementation of the method of Claim 1, and is rejected by a similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zachary A Davis whose telephone number is (571)272-3870. The examiner can normally be reached Monday-Friday, 9:00am-5:30pm, Eastern Time.
Examiner interviews are available via telephone 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, Rupal D Dharia can be reached at (571) 272-3880. 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.
/Zachary A. Davis/Primary Examiner, Art Unit 2492
Prosecution Insights