DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to applicant’s correspondence of 01/12/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/12/2026 has been entered.
Response to Arguments
Applicant's arguments presented in Arguments/Remarks on 01/12/2026 (hereafter Remarks) in response to the Office Action on 08/12/2025 (hereafter OA) have been fully considered but they are not persuasive.
Applicant agreed with claims 8 and 12 – 14 interpretation under 112f and insist on further use of the “means” as a chosen claim construction. No corrections have been made. Accordingly claims interpretation under 112f maintained. Statement in OA regarding rejection of claim 9 was in error and is corrected in the instant OA.
On p. 12 of the Remarks Applicant argues that new limitations in the amended claim version overcome the prior art. The new limitations disclose first/second hash values comprising “an extension or a protocol version” and that first/second hash values are generated and stored “based on the TLS client sub-profile or TLS server sub-profile being not a known TLS profile”.
Examiner respectfully disagrees. Inclusion of TLS client/server profile parameters not known from the TLS profile are met in the prior art of Althouse disclosing in para. [0013] an inclusion in the running TLS protocol, i.e., processing the known TLS profile, a number of sub-protocols allowing client and server to determine and instantiate security parameters which are processed including handshake message according to a handshake protocol, i.e., processing TLS sub-protocol with TLS sub-profile not known in the base parameter set.
Other arguments are moot in view of new ground of rejection.
Regarding the second round of the RCE consideration, in examiner view it would be important to incorporate the previously discussed concerns and suggestions. Several rejection OAs indicate that claims are written very broad and cannot overcome the prior art. On the other hand, SPECS discloses several new features presenting new views of the inventive concept. These features were discussed before with applicant. In an applicant-initiated interview on 05/19/2025 the examiner suggested introducing new limitations disclosing application of machine learning, ML, technology processing TLS parameters of a TLS flow based on patterns previously learned by the ML model via a training process. Therefore, the TLS sub-profile processing could be performed using pattern recognition technique by ML model; support in para. [0081 – 0082]. The recommended amendments should result in improvement of TLS data communication security, thus indicating required practical application of the invention, see applicant-initiated interview on 11/14/2024. However, these suggestions are only partially incorporated into dependent claim 71 to 78 and mostly disclosing application of the ML model for malicious detection in the system. These specific applications of the ML technology are disclosed by the prior art of Mv as indicated in OA. But the independent claims are silent regarding the recited above features which leaves the entire claim set unpatentable.
In summary, the amended claim set is still written very broad without properly highlighted inventive concept limitations. The amendments cannot overcome prior art presented in OA. Accordingly, interpretation under 112f and rejection under 103 of the claim set maintained.
Claim Objections
Claims 8, 12 – 14, 22, and 23 objected under 37 CFR 1.75 as being substantial duplicates of claims 1, 2 and 5 – 7, MPEP § 608.01(m).
Claims 8 and 22 each disclose an apparatus that duplicates the apparatus of claim 1 despite a slight difference in wording without adding any new limitations. Dependent claims 9, 12 – 14 duplicate claims 2, 5 – 7, respectively, and claim 23 duplicates claim 2.
Appropriate actions are required.
Claim Interpretation - 35 U.S.C. § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application in claims 8 and 12 – 14 that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In claims 8 and 12 – 14 the limitations are:
In claim 8:
first means for generating…
second means for generating…
means for comparing…
means for transmitting…
In claim 12:
first means for generating…
In claim 13:
second means for generating…
means for transmitting…
In claim 14:
means for identifying…
means for receiving…
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 2, 5 – 9, 12 – 16, and 19 – 23 are rejected under 35 U.S.C. 103 as being unpatentable over Althouse et al. (US 20220053023) (hereafter Althouse), in view of Vijayanarayanan et al. (US 20220029803) (hereafter V2022), and in view of Yumer et al. (US 9158915) (hereafter Yumer).
As per claim 1, Althouse discloses: (Currently Amended) An apparatus comprising: at least one memory; instructions; and at least one processor to execute the instructions to: generate a Transport Layer Security (TLS) client sub-profile based on first telemetry data associated with a client device (Althouse, [0013]: client and server applications may use the transport layer security (TLS) protocol to provide security for communications over the Internet),
the TLS client sub-profile including a first TLS parameter extracted from a first communication associated with the client device (Examiner note: first/second TLS parameter sets within a respective sub-profile are met in Althouse by the first/second security parameters sets/messages) (Althouse, [0063]: The client hello component 520 may transmit, to a first TLS server and a second TLS server, a same set of client-side security parameter messages (e.g., client hello messages));
generate a TLS server sub-profile based on second telemetry data associated with a first server, the TLS server sub-profile including a second TLS parameter extracted from a second communication associated with the first server (Althouse, in Para. [0064] and in Fig. 8 discloses communication of the first/second sets of TLS security parameters between first/second servers);
[generate a first hash value based on the first TLS parameter of the TLS client sub- profile and a second hash value based on the second TLS parameter]
of the TLS server sub-profile, where the first TLS parameter and the second TLS parameter include at least one of a cipher suite, an extension, or a protocol version; (Althouse discloses in para. [0013] an inclusion in the running TLS protocol, i.e., in known TLS profile, a number of sub-protocols, i.e. resulting in TLS sub-profile, allowing client and server to determine and instantiate security parameters which is performed by handshake message according to a handshake protocol, i.e., processing TLS sub-protocol or TLS sub-profile not known in the base parameter set);
and store at least one of the first hash value or the second hash value in the datastore based on the TLS client sub-profile or the TLS server sub-profile being not a known TLS profile. (Althouse in para [0065-0066] and Figs. 5-7 discloses processing the TLS configuration information including TLS protocol version including storage in the database);
Althouse does not explicitly disclose: generation of hash values corresponding to respective telemetry data and perform a comparative analysis of the generated hash values followed by appropriated system actions.
However, V2022 discloses: generate a first hash value based on the first TLS parameter of the TLS client sub- profile and a second hash value based on the second TLS parameter (Examiner note: generation of hash values corresponding to telemetry data is met in V2022 by generation hash values of different data sets corresponding to processing or content data) (V2022, in para [0006, 00143, 0166] discloses hash values generation of different data sets corresponding to data sets or session information to be processed in the system including telemetry data [0516]);
compare the at least one of the first hash value or the second hash value to a plurality of hash values in a datastore, the plurality of hash values corresponding to known TLS profiles (V2022, in para [0183-0184] discloses comparison of hash values with the values stored in the system),
in response to a determination that the at least one of the TLS client sub-profile or the TLS server sub-profile is not a known TLS profile based on the not matching any of the plurality of hash values, transmit at least one of the first telemetry data or the second telemetry data to a second server, (V2022, in para [0183-0184] discloses actions followed matching or not matching results of the hash values comparison performed by processing unit 135 as depicted in Figs. 4, 12 and 15).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse for teaching of V2022 because they both disclose similar subject matter, i.e., data processing in the system including telemetry. The motivation to combine would be to modify method of Althouse for performing hash value generation for respective data packages and comparative hash values analysis to improve security of telemetry data processing.
Althouse as modified does not explicitly disclose: external, off-path service and detection of malicious activity related to a telemetry database based on respective hash values comparison. However, Yumer discloses: the second server to perform off-path network security services (Examiner note: the off-path networking service is disclosed by Applicant in para. [0024] of SPECS as external networking service which is met in Yumer by communication per respective peripherals with external network, i.e., external bus and communication channel) (Yumer, col. 7 ll. 1-20: external server may further analyze potential threat data based on telemetry hash);
including analyzing the at least one of the first telemetry data or second telemetry data to detect malicious activity (Yumer, col.9, ll.21-23: Upon making these correlations, correlation module 106 may store the correlations in memory, such as in hash-exploit vulnerability correlations 542.) and generating a rule based on the analysis of the at least one of the first telemetry data or the second telemetry data datastore (Yumer, col.14, ll.33-35: comparison module 108 may create one or more security policies and/or configure one or more security systems).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse-V2022 for teaching of Yumer because they all disclose similar subject matter, i.e., the telemetry data processing in the system. The motivation to combine would be to modify method of Althouse-Healy for performing comparative TLS data related hash values analysis including off-path devices to improve efficiency of telemetry data processing.
As per claim 2 Althouse as modified discloses: (Original) The apparatus of claim 1, wherein the first telemetry data is generated in response to the client device transmitting a first data communication to the first server, (Examiner note: first/second TLS parameter sets are met in Althouse by the first/second security parameters sets/messages) (Althouse, [0063]: The client hello component 520 may transmit, to a first TLS server and a second TLS server, a same set of client-side security parameter messages (e.g., client hello messages)), and the second telemetry data is generated in response to the first server transmitting a second data communication to the client device (Althouse, in Para. [0064] and in Fig. 8 discloses communication of the first/second sets of TLS security parameters between first/second servers).
As per claim 5 Althouse as modified discloses: (Previously presented) The apparatus of claim 1, wherein the TLS server sub-profile is a first TLS server sub-profile, and one or more of the at least one processor is to generate a second TLS server sub-profile based on third telemetry data associated with a third server, (Althouse, [0073]: handler 630 may generate a third hash value corresponding to the third TLS server), the second TLS server sub-profile including the second TLS parameter or a third TLS parameter associated with the third server, the third telemetry data generated in response to the third server transmitting a data communication to the client device (Althouse, [0100]: the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for transmitting, to a third TLS server, the same set of client-side security parameter messages).
As per claim 6 Althouse as modified discloses: (Previously presented) The apparatus of claim 5, wherein the at least one processor is to: generate a third hash value based on the second TLS server sub-profile; and in response to the third hash value not matching any of the plurality of hash values, transmit the third telemetry data to the second server (Examiner note: Althouse discloses in para. [0015] and Fig. 4 processing of different hash values, first, second, third etc.) (Althouse, [0065]: The hash generator 530 may generate a first hash value corresponding to the first TLS server based on the first set of server-side security parameter messages and a second hash value corresponding to the second TLS server based on the second set of server-side security parameter messages.); and in response to the second hash value not matching any of the plurality of hash values, transmit the third telemetry data to the second server (Althouse, [0057]: the device 405 may compare the hash value for the TLS server 410 to hash values generated for other TLS servers. At 440, the device 405 may determine whether a TLS configuration for the TLS server 410 is different from a TLS configuration for another TLS server based on the comparison of the hash value for the TLS server 410 with a hash value for the other TLS server. Althouse, [0084]: At 805, the device may transmit, to a first TLS server and a second TLS server, a same set of client-side security parameter messages).
As per claim 7 Althouse as modified discloses: (Previously presented) The apparatus of claim 1, wherein the client device is a first client device with a first type, the TLS client sub-profile is a first TLS client sub-profile the TLS server sub-profile is a first TLS server sub-profile and one or more of the at least one processor is to: identify a second type of a second client device in a network including the first client device; (Examiner note: first/second TLS parameter sets within a respective sub-profile are met in Althouse by the first/second security parameters sets/messages) (Althouse, [0063]: The client hello component 520 may transmit, to a first TLS server and a second TLS server, a same set of client-side security parameter messages (e.g., client hello messages)), and receive at least one of a second TLS client sub-profile or a second TLS server sub-profile from the second server, the second TLS client sub-profile and the second TLS server sub-profile corresponding to the second type. (Althouse, [0054]: At 420, the device 405 may transmit, to the TLS server 410, a set of client-side security parameter messages. The device 405 may transmit the same set of client-side security parameter messages to each TLS server 410).
As per claim 8 Althouse discloses: (Currently Amended) An apparatus comprising: first means for generating to: generate a Transport Layer Security (TLS) client sub-profile based on first telemetry data associated with a client device, the TLS client sub-profile including a first TLS parameter extracted from a first communication associated with the client device (Althouse, in Para. [0064] and in Fig. 8 discloses creation and communication of the first/second sets of TLS security parameters between first/second servers);
and generate a TLS server sub-profile based on second telemetry data associated with a first server, the TLS server sub-profile including a second TLS parameter extracted from a second communication associated with the first server (Althouse, [0063]: The client hello component 520 may transmit, to a first TLS server and a second TLS server, a same set of client-side security parameter messages (e.g., client hello messages));
[second means for generating a first hash value based on the first TLS parameter of the TLS client sub-profile and a second hash value based on the second TLS parameter]
of the TLS server sub-profile, where the first TLS parameter and the second TLS parameter include at least one of a cipher suite, an extension, or a protocol version; (Althouse discloses in para. [0013] an inclusion in the running TLS protocol, i.e., in known TLS profile, a number of sub-protocols, i.e. resulting in TLS sub-profile, allowing client and server to determine and instantiate security parameters which is performed by handshake message according to a handshake protocol, i.e., processing TLS sub-protocol or TLS sub-profile not known in the base parameter set);
Althouse does not explicitly disclose: generation of hash values corresponding to respective telemetry data and perform a comparative analysis of the generated hash values followed by appropriated system actions.
However, V2022 discloses: second means for generating a first hash value based on the first TLS parameter of the TLS client sub-profile and a second hash value based on the second TLS parameter (Examiner note: generation of hash values corresponding to telemetry data is met in V2022 by generation hash values of different data sets corresponding to processing or content data) (V2022, in para [0006, 00143, 0166] discloses hash values generation of different data sets corresponding to data sets or session information to be processed in the system including telemetry data [0516]);
means for comparing the at least one of the first hash value or the second hash value to a plurality of hash values corresponding to known TLS profiles (V2022, in para [0183-0184] discloses comparison of hash values with the values stored in the system);
and means for transmitting at least one of the first telemetry data or the second telemetry data to a second server in response to determining the at least one of the TLS client sub-profile or the TLS server sub-profile is not a known TLS profile based on the first hash value or the second hash value not matching any of the plurality of hash values,
(V2022, in para [0183-0184] discloses actions followed matching or not matching results of the hash values comparison performed by processing unit 135 as depicted in Figs. 4, 12 and 15).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse for teaching of V2022 because they both disclose similar subject matter, i.e., data processing in the system including telemetry. The motivation to combine would be to modify method of Althouse for performing hash value generation for respective data packages and comparative hash values analysis to improve security of telemetry data processing.
Althouse as modified does not explicitly disclose: data processing on the off-path server. However, Yumer discloses: the second server to perform off-path network security services based on the at least one of the first telemetry data or the second telemetry data.
(Examiner note: the off-path networking service is disclosed by Applicant in para. [0024] of SPECS as external networking service which is met in Yumer by communication per respective peripherals with external network, i.e., external bus and communication channel) (Yumer, col.17, ll.6-10: communication interface 622 may also represent a host adapter configured to facilitate communication between computing system 610 and one or more additional network or storage devices via an external bus or communications channel);
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse-V2022 for teaching of Yumer because they all disclose similar subject matter, i.e., the telemetry data processing in the system. The motivation to combine would be to modify method of Althouse-V2022 for performing TLS data processing on off-path devices to improve efficiency of telemetry data processing.
As per claims 9, 12 – 14, claims 9, 12 – 14 encompass same or similar scope as claims 2, 5 – 7, respectively. Therefore, claims 9, 12 – 14 are rejected based on the same reasons set forth above in rejecting claims 2, 5 – 7.
As per claim 15, claim 15 encompasses same or similar scope as claim 1. Therefore, claim 15 is rejected based on the same reasons set forth above in rejecting claim 1.
As per claims 16, 19 – 21, claims 16, 19 – 21 encompass same or similar scope as claims 2, 5 – 7, respectively. Therefore, claims 16, 19 – 21 are rejected based on the same reasons set forth above in rejecting claims 2, 5 – 7.
As per claim 22, claim 22 encompasses same or similar scope as claim 8 Therefore, claim 22 is rejected based on the same reasons set forth above in rejecting claim 8.
As per claim 23, claim 23 encompasses same or similar scope as claim 2. Therefore, claim 23 is rejected based on the same reasons set forth above in rejecting claim 2.
Claims 71 – 78 are rejected under 35 U.S.C. 103 as being unpatentable over Althouse et al. (US 20220053023) (hereafter Althouse), in view of Vijayanarayanan et al. (US 20220029803) (hereafter V2022), in view of Yumer et al. (US 9158915) (hereafter Yumer), and in view of Mv et al. (US 12380327) (hereafter Mv).
As per claim 71 Althouse as modified discloses: (Currently Amended) The apparatus of claim 1, wherein one or more of the at least one processor is to, in response to a determination that the at least one of the TLS client sub-profile or the TLS server sub-profile is not a known TLS profile (Althouse discloses in para. [0013] an inclusion in the running TLS protocol, i.e., in known TLS profile, a number of sub-protocols, i.e. resulting in TLS sub-profile, allowing client and server to determine and instantiate security parameters which is performed by handshake message according to a handshake protocol, i.e., processing TLS sub-protocol or TLS sub-profile not known in the base parameter set);
based on V2022, in para [0183-0184] discloses actions followed matching or not matching results of the hash values comparison performed by processing unit 135 as depicted in Figs. 4, 12 and 15).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse for teaching of V2022 because they both disclose similar subject matter, i.e., data processing in the system including telemetry. The motivation to combine would be to modify method of Althouse for performing hash value generation for respective data packages and comparative hash values analysis to improve security of telemetry data processing.
Althouse as modified does not explicitly disclose: detection of abnormalities in the system using machine learning technique. However, Mv discloses: execute a machine-learning model to generate a machine-learning output based on at least one of the first telemetry data or the second telemetry data. (Mv, col.9, ll.56-51: Referring now to FIG. 3, this figure shows data preprocessing techniques for training a first machine learning model in an illustrative embodiment. The data preprocessing techniques, in some embodiments, are applied by the telemetry preprocessor 122 to generate data in a format digestible by the edge image prediction model 126.).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse-V2022-Yumer for teaching of Mv because they both disclose similar subject matter, i.e., the telemetry data processing in the system. The motivation to combine would be to modify method of Althouse-V2022-Yumer for usage of machine learning technique to detect and treat abnormalities to improve security of telemetry data processing.
As per claim 72 Althouse as modified discloses: (Previously presented) The apparatus of claim 71, wherein one or more of the at least one processor is to: determine that the machine-learning output is indicative of malicious activity associated with the client device or the first server; (Mv, col.3, ll.19-21: Illustrative embodiments herein describe techniques for detecting container incidents using machine learning techniques. Mv, col.6, ll.44-48: The term "incident" in the context of containers is intended to be broadly construed so as to encompass an event when a software container is no longer performing as expected, such as failures or errors associated with software and/or hardware.); and block communications from the client device or from the first server (Examiner note: blocking a communication is one of the recovery actions in the system) (Mv, col.11, ll.11-15: the system can predict the container incident far enough in advance so that a repair or recovery action can be performed before the container incident occurs, thereby reducing the likelihood of down time).
It would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify Althouse-V2022-Yumer for teaching of Mv because they both disclose similar subject matter, i.e., the telemetry data processing in the system. The motivation to combine would be to modify method of Althouse-V2022 for usage of machine learning technique to detect and treat abnormalities to improve security of telemetry data processing.
As per claims 73 and 74, claims 73 and 74 encompass same or similar scope as claims 71 and 72, respectively. Therefore, claims 73 and 74 are rejected based on the same reasons set forth above in rejecting claims 71 and 72.
As per claims 75 and 76, claims 75 and 76 encompass same or similar scope as claims 71 and 72, respectively. Therefore, claims 75 and 76 are rejected based on the same reasons set forth above in rejecting claims 71 and 72.
As per claims 77 and 78, claims 77 and 78 encompass same or similar scope as claims 71 and 72, respectively. Therefore, claims 77 and 78 are rejected based on the same reasons set forth above in rejecting claims 71 and 72.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Clark US_20190109820, Duraj US_11388225.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VLADIMIR IVANOVICH GAVRILENKO whose telephone number is (313)446-6530. The examiner can normally be reached on Monday-Friday 7:30-4:30 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, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VLADIMIR I GAVRILENKO/Examiner, Art Unit 2431