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 .
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.
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 6, 7, 13, 14, and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for deriving a semantic graph from operational data and generating an identity semantic network (ISN), does not reasonably provide enablement for processing the ISN using an array of Kalman filters to capture a topological structure and spatial features representing changes in network characteristics, or for adjusting an optimal number of RPI instances based on a predetermined threshold and the changes in network characteristics. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the invention commensurate in scope with these claims.
Claims 6, 13, and 20 recite “processing the ISN using an array of Kalman filters to capture a topological structure of the network and spatial features representing changes in the characteristics of the network.” Claims 7, 14, and 20 further recite “adjusting an optimal number of RPI instances required for operation in the network based on a pre-determined threshold and at least one of the changes in the characteristics of the network.”
The specification explains how operational data is used to derive a semantic graph, extract an adjacency matrix, and generate an ISN. See paragraphs [0063]-[0070]. It also states that an array of Kalman filters acts on the graph nodes and their first-order neighborhoods. See paragraphs [0071]-[0075]. However, the specification does not explain how the information represented by the ISN is actually provided to or processed by the individual Kalman filters.
For example, the specification does not identify how the graph nodes, causal relationships, and sensor measurements are converted into filter states and observations. It also does not identify the state-transition model, observation model, noise parameters, initialization values, or manner in which the ISN data is assigned among the filters.
Equation (4) does not provide that missing information. Paragraph [0071] describes σ and ReLU as activation functions in an expression involving an adjacency matrix, feature matrix, and weight matrices. Paragraph [0072] then states that σ is the array of Kalman filters. The specification does not explain how an array of Kalman filters functions as the activation function in equation (4) or how the filter outputs provide the claimed topological structure and spatial features.
Paragraphs [0073]-[0075] discuss comparing estimates from a main filter and representative filters. However, the specification does not disclose the underlying filter models used to produce those estimates or explain how the estimates identify changes in the physical or data-processing structure of the network.
Claims 7, 14, and 20 present an additional enablement issue. Paragraphs [0076]-[0078] describe a latency threshold, a representational error, and a spawning index. Equations (9) and (10) show a mathematical relationship between those values, but the specification does not explain how the spawning index is converted into a number of RPI instances, when an instance should be added or removed, or how the resulting number is determined to be “optimal.”
As explained in MPEP § 2164.01(a) and In re Wands, whether the necessary experimentation would be undue depends on the facts of the particular application. The relevant Wands factors are applied below.
(1) Breadth of the claims: The claims cover different network topologies, sensor measurements, ISN representations, and Kalman-filter arrangements. They do not identify a particular filter model, number of filters, or method for assigning ISN data to the filters. Claims 7, 14, and 20 also do not identify how the threshold and detected changes are converted into an optimal RPI count. This broad scope would require a skilled person to develop an implementation for a wide range of network configurations.
(2) Nature of the invention: The claimed invention combines several technical areas, including semantic networks, IoT sensing, Kalman filtering, network-topology estimation, anomaly detection, and allocation of RPI resources. These components must be coordinated to produce the claimed results. Implementing that coordination is more involved than simply using each component separately.
(3) State of the prior art: Semantic graphs, sensor processing, and Kalman filters were individually known in the art. This would assist a skilled person in implementing those individual components. However, the record does not show that connecting the claimed ISN to an array of Kalman filters in the broadly claimed manner was a routine or standardized procedure. The known individual components therefore do not provide the missing implementation by themselves.
(4) Level of ordinary skill: A person of ordinary skill would be familiar with network architecture, graph-based data structures, sensor processing, and conventional Kalman filtering. That knowledge would reduce the amount of instruction needed for the individual components. Nevertheless, the skilled person would still have to design the particular filter models, data assignments, and RPI-adjustment procedure that the specification does not disclose.
(5) Predictability of the art: Kalman filters generally produce predictable results when their states, observations, inputs, and operating parameters are defined. Those items are not defined here. Different selections could produce different topology estimates, detected changes, and RPI-spawning results. A skilled person therefore could not reasonably predict, based on the disclosure alone, which implementation would produce the claimed results throughout the full scope of the claims.
(6) Amount of direction provided: The specification provides the general objective and several mathematical expressions, but it does not provide the programmed steps or procedures needed to connect the ISN to the Kalman filters. It also does not explain how to use the filter outputs and spawning index to determine the number of RPI instances. This leaves essential parts of the claimed process for the skilled person to develop.
(7) Working examples: The specification does not provide a working example that includes an actual network topology, sensor dataset, ISN, Kalman-filter configuration, filter output, and resulting RPI-count adjustment. A working example is not required in every case, but its absence is relevant here because the specification otherwise does not show how the claimed components operate together.
(8) Amount of experimentation: To practice the claimed invention, a skilled person would have to select and test the state and observation models, determine how the ISN data is distributed among the filters, tune the filter parameters, determine whether the outputs accurately represent network changes, and develop a procedure for converting the spawning index into an RPI count. These steps would require iterative design and testing for different network configurations, rather than merely routine programming.
Considering the factors together, the known nature of the individual components and the relatively high level of ordinary skill favor enablement to some extent. However, those considerations are outweighed by the breadth of the claims, the limited guidance regarding how the components operate together, the absence of a working implementation, and the amount of design and testing needed to achieve the claimed results. Therefore, a person of ordinary skill would have been required to engage in undue experimentation to make and use the claimed invention throughout its full scope.
Claims 7 and 14 depend from claims 6 and 13, respectively, and inherit the enablement deficiency of their respective base claims. Claim 20 independently recites both the ISN/Kalman-filter processing and RPI-adjustment limitations and is rejected for the reasons set forth above.
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 7, 14, and 20 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 7 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “adjusting an optimal number of RPI instances required for operation in the network” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. The claim does not identify the criterion by which the number of RPI instances is considered “optimal.” It is unclear whether “optimal” refers to a minimum number needed to satisfy a latency requirement, a number that maximizes throughput or inspection capacity, a number that minimizes computing resources, or some other standard. Although the specification generally associates the number of RPI instances with latency, it does not provide an objective standard for determining when a particular number is the claimed “optimal number.” Therefore, the scope of claim 7 is unclear.
Claim 7 is further rejected under 35 U.S.C. 112(b) as being indefinite because the term “a pre-determined threshold” does not identify the parameter to which the threshold applies. Paragraph 27 describes a predetermined threshold applied to the magnitude of a change in a network characteristic, whereas paragraphs 76-78 describe a latency threshold used in determining a spawning index. It is unclear whether the claimed “pre-determined threshold” is a threshold for latency, a threshold for a change in a network characteristic, or some other threshold. Therefore, the scope of claim 7 is unclear.
Claim 14 recites substantially the same indefinite limitations as claim 7 in system form, including “adjusting an optimal number of RPI instances required for operation in the network based on a pre-determined threshold.” Accordingly, claim 14 is rejected under 35 U.S.C. 112(b) for the same reasons set forth above with respect to claim 7.
Claim 20 recites substantially the same indefinite limitations as claim 7 in computer program product form, including “adjust an optimal number of RPI instances required for operation in the network based on a pre-determined threshold.” Accordingly, claim 20 is rejected under 35 U.S.C. 112(b) for the same reasons set forth above with respect to claim 7.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 8-9, 11, 15-16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”).
Regarding claim 1,
Hartley teaches:
A computer-implemented method for reverse proxy inspection (RPI) of encrypted traffic in an edge-based network, comprising: (see Hartley, [¶0046]: “EDITH-enabled VPN Client and VPN Gateway products 120 enable this multiple security level operations scenario by implementing the MA CP compliant two-layered IPsec tunnel connecting the end user device (EUD) of warfighter E 108b with the remote TS LAN 114 over the waveform-diverse SECRET IP tactical network shown in the figure.”);
(Hartley implements a software based, two-layer IPsec arrangement between an edge device and a remote secure network. Hartley’s infrastructure Outer VPN Gateway corresponds to the claimed RPI instance because it terminates and processes the outer tunnel.)
sharing a first certificate from an RPI instance of the network to an edge-based network gateway of the network, wherein the first certificate is issued to the RPI instance; (see Hartley, [¶¶0071, 0125]: “Authentication may use certificates, verified by a certificate authority, but for efficiency, the following calculations assume pre-placed keys for authentication. An Outer VPN Gateway, whether at the EUD or Infrastructure, can form IPsec Security Associations with any number of different Outer VPN Gateways. Each security association would have a different set of data encryption keys.”);
(Hartley establishes certificate-authenticated IPsec associations directly between infrastructure and edge side Outer VPN Gateways. In the proposed combination, Murray’s CA issued gateway certificate distribution supplies the certificate of Hartley’s infrastructure gateway to its edge side gateway peer.)
receiving, at the RPI instance, an encrypted message with an initial layer of encryption and a subsequent layer of encryption, wherein the initial layer of encryption is encrypted using a second certificate issued to an edge-based network device of the network, and the subsequent layer of encryption is encrypted using the first certificate; (see Hartley, [¶¶0027, 0119]: “The EDITH VPN Gateways or EDITH VPN Clients on the infrastructure may receive the double encrypted and double compressed data packets, and decrypt the outer layer encryption with Outer EDITH Gateway and decrypt the inner layer encryption with Inner EDITH Gateway. The EDITH Client (EC) deployed on the mobile device performs only the inner VPN Client role, imposing the first layer of EDITH encryption and header compression. An EDITH Dedicated Outer VPN Gateway (EVG) provides the second layer of encryption.”);
(Hartley’s infrastructure receives a single message containing an inner layer applied for the edge device and an outer layer applied by the edge gateway. In the proposed combination, Murray’s separately issued device and gateway certificates authenticate the keying material used for Hartley’s respective layers.)
decrypting, at the RPI instance, the subsequent layer of encryption using the first certificate, resulting in the encrypted message with the initial layer of encryption intact; (see Hartley, [¶0027]: “The EDITH VPN Gateways or EDITH VPN Clients on the infrastructure may receive the double encrypted and double compressed data packets, and decrypt the outer layer encryption with Outer EDITH Gateway and decrypt the inner layer encryption with Inner EDITH Gateway.”);
(Hartley’s infrastructure Outer Gateway removes only the outer layer, leaving the inner layer for a separate Inner Gateway. In the proposed combination, Murray’s certificate based key distribution procedure supplies the certificate associated keying material used for Hartley’s outer layer.)
inspecting, at the RPI instance, the encrypted message; (see Hartley, [¶¶0076, 0111]: “An MA CP compliant path requires Outer VPN tunnel connections have exactly two endpoints, one in the EUD and one in the Infrastructure, which can log and monitor traffic in the gray network. This abstractly identifies the type of traffic in the encrypted payload so routing priority decisions in the Radio Network can account for different traffic needs (e.g., low latency or high priority) without decrypting the traffic.”);
(Hartley’s infrastructure endpoint logs and monitors gray network traffic while the inner encryption remains intact. Hartley specifically inspects exposed traffic type information for routing decisions without decrypting the protected payload, satisfying the claimed inspection of the encrypted message.)
and forwarding the encrypted message from the RPI instance to a centralized hub of the network. (see Hartley, [¶0123]: “The EDITH Outer Gateway receives communication from the radio network, decrypts it, and forwards it to the Inner Gateway, which decrypts it and forwards the resulting plain text packets to a secure infrastructure Ethernet network, for example connecting data servers or connecting to SIPRnet via other gateways.”);
(Hartley’s Outer Gateway forwards the still inner encrypted message to the infrastructure Inner Gateway, which fronts the centralized secure network. The infrastructure Inner Gateway therefore corresponds to the claimed centralized hub.)
Hartley does not expressly teach, but Murray teaches:
authenticating, at the RPI instance, the first certificate; (see Murray, [¶¶0079, 0115]: “CA 208 then sends this certificate to edge device 108E which can now verify the authenticity of the certificate by decrypting it with the public key of CA 208. In one embodiment, gateway 104A of FIG. 2 obtains a public key certificate from CA 208 by following the above-explained process in reference to device enrollment.”);
(Murray applies its previously described enrollment process to the gateway, and that process includes the certificate recipient locally verifying its CA issued certificate using the CA’s public key. In the proposed combination, Hartley’s infrastructure Outer Gateway performs this local certificate validation before using the certificate for its outer security association, thereby authenticating the first certificate at the RPI instance.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s two layer IPsec architecture, including its certificate authenticated associations between edge-side and infrastructure Outer VPN Gateways, to incorporate Murray’s CA issued gateway and edge device certificate enrollment, distribution, verification, and key distribution procedures. Hartley expressly permits CA verified certificates instead of prepositioned authentication keys and Murray provide that implementation by obtaining a CA issued certificate for a gateway, verifying the issued certificate through the CA’s public key, distributing the gateway certificate to communicating network nodes, and using certificate associated keying material to protect encryption keys. A person of ordinary skill would have been motivated to employ Murray’s certificate procedures in Hartley’s architecture to authenticate the participating gateways, automate certificate and key distribution, and avoid manually prepositioned authentication keys. The combination predictably preserves Hartley’s gateway to gateway architecture and two-layer packet structure while implementing Hartley’s expressly contemplated certificate authentication option.
Regarding claim 2,
Murray teaches:
wherein the first certificate and the second certificate are different signed certificates issued by a Certificate Authority (CA). (see Murray, [¶¶0079, 0115]: “CA 208 then digitally signs the public key certificate with its private key to obtain a digitally signed certificate for our newly enrolled edge device 108E. In one embodiment, gateway 104A of FIG. 2 obtains a public key certificate from CA 208 by following the above-explained process in reference to device enrollment. In summary, it sends its public key in a CSR to CA 208 which after its validation returns it its PK certificate.”);
(Murray’s CA issues separate signed certificates to the edge device and gateway based on their respective public keys. In the proposed combination, the certificate issued to Hartley’s infrastructure Outer Gateway is the first certificate, and the different certificate issued to Hartley’s EUD is the second certificate.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s multilayer IPsec architecture, including its distinct inner and outer security associations, to incorporate Murray’s separately issued, CA signed edge device and gateway certificates. Hartley expressly permits CA verified certificate authentication for its VPN associations. Murray provides the issuance of separate certificates to its participating devices and gateways implementation by issuing a digitally signed certificate to an edge device based on the device’s public key and a separate certificate to a gateway based on the gateway’s own public key. A person of ordinary skill would have been motivated to employ Murray’s separate certificates in Hartley’s architecture to independently authenticate the EUD and infrastructure Outer Gateway, bind each participant to its respective public key, permit individual credential revocation, and avoid sharing certificate credentials between the inner and outer security associations. The combination would have predictably resulted in different CA signed certificates being issued to Hartley’s EUD and infrastructure Outer Gateway.
Claim 9 recites substantially the same limitation as claim 2 in system form. Accordingly, claim 9 is rejected for the same reasons set forth above with respect to claim 2.
Claim 16 recites substantially the same limitation as claim 2 in computer program product form. Accordingly, claim 16 is rejected for the same reasons set forth above with respect to claim 2.
Regarding claim 4,
Hartley teaches:
wherein the initial layer of encryption is encrypted at the edge-based network device, and the subsequent layer of encryption is encrypted at the edge-based network gateway. (see Hartley, [¶0119]: “The EDITH Client (EC) deployed on the mobile device performs only the inner VPN Client role, imposing the first layer of EDITH encryption and header compression. An EDITH Dedicated Outer VPN Gateway (EVG) provides the second layer of encryption.”);
(Hartley’s mobile device applies the initial inner encryption layer, and its Dedicated Outer VPN Gateway applies the subsequent outer encryption layer.)
Claim 11 recites substantially the same limitation as claim 4 in system form. Accordingly, claim 11 is rejected for the same reasons set forth above with respect to claim 4.
Claim 18 recites substantially the same limitation as claim 4 in computer program product form. Accordingly, claim 18 is rejected for the same reasons set forth above with respect to claim 4.
Regarding claim 8:
Hartley teaches:
A system for reverse proxy inspection (RPI) of encrypted traffic in an edge-based network, comprising: at least one processor; and a non-transitory processor-readable memory device storing instructions that when executed by the at least one processor causes the at least one processor to perform operations including: (see Hartley, [¶¶0127, 0167]: “A typical MA CP compliant infrastructure architecture 1108 will include at least two PCs running EDITH Gateway software, which in the figure are Linux-based and FreeBSD-based to address the requirement for implementation diversity. When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a computer-readable or processor-readable storage medium.”);
(Hartley implements its EDITH Gateway system using processor-based computers executing gateway software stored as processor executable instructions on non-transitory processor-readable storage media.)
Claim 8 recites substantially the same limitations as claim 1 in System form. Accordingly, claim 8 is rejected for the same reasons set forth above with respect to claim 1.
Regarding claim 15,
Hartley teaches:
A computer program product for reverse proxy inspection (RPI) of encrypted traffic in an edge-based network, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to: (see Hartley, [¶0167]: “When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a computer-readable or processor-readable storage medium.”);
(Hartley stores the disclosed software functions as processor executable instructions on a computer-readable storage medium, thereby providing a computer program product for performing Hartley’s encrypted-traffic operations.)
Claim 15 recites substantially the same limitations as claim 1 in computer program product form. Accordingly, claim 15 is rejected for the same reasons set forth above with respect to claim 1.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”) and in further view of Gooding et al, (U.S. Pub. No. 2015/028,1278 A1, hereinafter “Gooding”).
Regarding claim 3,
Gooding teaches:
wherein the first certificate is part of a first certificate chain used for end-to-end communication between the edge-based network gateway and the RPI instance, and the second certificate is part of a second certificate chain that is different from the first certificate chain and used for end-to-end communication between the edge-based network device and the centralized hub. (see Gooding, [¶¶0170-0172]: “Referring now to FIG. 6, there is shown a diagram of a CCS public key infrastructure (PKI) service 600 hierarchy. The PKI service 600 comprises instructions that provide X509v3 certificates for the CCS 100. Various types of certificates can be used for authentication, secure communications establishment, and bill of health attestation by both services and clients. Entities trust the communication or information based on the trust of the signer of the certificate, also known as a trust anchor. A root certificate authority (CA) 602 is the top of the certificate hierarchy, and is the only self-signed certificate in the infrastructure. The CA's 602 primary purpose is to certify subordinate CAs as they are needed within the PKI service 600 hierarchy. Operational and administrative domain CAs 604 are subordinate CAs that comprise instructions to handle day-to-day certificate issuance and revocation actions of end entities 610.”);
(Gooding teaches end entity certificates, subordinate domain CA certificates, and a root CA certificate used to establish trust for secure communications. In the proposed combination, these certificates form separate validation chains for Hartley’s outer gateway association and inner EUD to-hub association.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s multilayer IPsec architecture, as implemented using Murray’s CA issued certificates, to incorporate Gooding’s hierarchical PKI having separate subordinate domain CAs and corresponding certificate validation chains. Hartley separates its inner and outer VPN associations into isolated encryption domains using different keys and different VPN components. Murray provides CA enrollment and certificate issuance. Gooding provides a known PKI implementation having end entity certificates, subordinate domain CAs, a root CA, and trust anchor verification for secure communications. A person of ordinary skill would have been motivated to organize the certificates for Hartley’s separate VPN domains into different validation chains to permit independent authentication, administration, and revocation of the inner and outer security associations. The outer chain would validate communication between the edge side Outer VPN Gateway and the infrastructure Outer VPN Gateway the RPI instance while the different inner chain would validate communication between the EUD and the centralized hub the infrastructure Inner VPN Gateway.
Claim 10 recites substantially the same limitation as claim 3 in system form. Accordingly, claim 10 is rejected for the same reasons set forth above with respect to claim 3.
Claim 17 recites substantially the same limitation as claim 3 in computer program product form. Accordingly, claim 17 is rejected for the same reasons set forth above with respect to claim 3.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”) and in further view of Nolan et al, (U.S. Pub. No. 2021/012,6826 A1, hereinafter “Nolan”).
Regarding claim 5,
Nolan teaches:
further comprising: monitoring operational data relating to the network, wherein the operational data comprises measurements of characteristics of the network, and the operational data is captured via Internet of Things (IoT) sensors coupled to or integrated in edge-based network devices of the network. (see Nolan, [¶¶0059, 0130, 0208-0209]: “Low levels indicate devices that may be located at or near the edges of networks, such as the last devices before the networks end. As used herein, an IoT device may include a device performing a function, such as sensing or control, among others, in communication with other IoT devices and a communications network. The bus 906 may couple the processor 902 to an interface 918 that is used to connect external devices. The external devices may include sensors 920, such as accelerometers, level sensors, flow sensors, temperature sensors, pressure sensors, barometric pressure sensors, and the like. The method 1900 may be run using the system 900 described with respect to FIG. 9. At block 1902, an IoT device may obtain a network topology map and listing by identifying connected nodes and physical network characteristics. Physical network characteristics may also include inter-node distances, clustering, dispersal information, received signal strengths, and signal to noise ratios. As part of the abstraction, signal measurements may be retrieved from IoT devices. An example of signal measurements may include received signal strength indicator (RSSI) and broadcasting power.”);
(Nolan’s network monitoring method operates on an edge IoT device having sensors coupled through an interface and obtains operational measurements of network characteristics, including inter node distances, received signal strength, signal to noise ratio, RSSI, and broadcasting power. In the proposed combination, Nolan’s coupled IoT sensors and network monitoring functionality are implemented in Hartley’s EUDs edge based network devices to capture operational measurements relating to Hartley’s edge network.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s multilayer edge network architecture, as implemented using Murray’s certificate-based authentication, to incorporate Nolan’s edge based IoT sensing and network monitoring functionality. Hartley provides secure communication paths between edge-based network devices and infrastructure components but does not detail capturing operational measurements of network characteristics through IoT sensors coupled to its edge devices. Nolan provides this implementation by operating its network monitoring method on an edge IoT device having coupled sensors and obtaining measurements including inter node distances, received signal strength, signal to-noise ratio, RSSI, and broadcasting power. A person of ordinary skill would have been motivated to incorporate Nolan’s sensing and monitoring functionality into Hartley’s edge-based network devices to monitor network topology, link quality, signal conditions, and device connectivity, thereby facilitating fault detection and reliable network operation. The combination predictably results in Hartley’s edge-based network devices capturing operational measurements of network characteristics using coupled IoT sensors.
Claim 12 recites substantially the same limitation as claim 5 in system form. Accordingly, claim 12 is rejected for the same reasons set forth above with respect to claim 5.
Claim 19 recites substantially the same limitation as claim 5 in computer program product form. Accordingly, claim 19 is rejected for the same reasons set forth above with respect to claim 5.
Claims 6, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”) in view of Nolan et al, (U.S. Pub. No. 2021/012,6826 A1, hereinafter “Nolan”) in view of Ploennings et al, (U.S. Pub. No. 2020/024,2199 A1, hereinafter “Ploennings”) and in further view of Tang et al, (U.S. Pub. No. 2017/015,3122 A1, hereinafter “Tang”)
Regarding claim 6, the combination of Ploennigs and Tang teaches:
Deriving a semantic graph of the network from the operational data, wherein the semantic graph is a knowledge graph representing a physical structure of the network and a data and event processing structure of the network. (see Ploennigs, [¶¶0057-0058]: “Conversational dialog flows/workflows may be generated from context dependencies in the graph. That is, the semantic graph may be created by linking observed and unobserved sensors by a physical process model with spatial and system context. Different graph patterns can be used such as, for example, spatial relationships, aggregation hierarchies, physical process models linking explanatory variables.”);
Generating an identity semantic network (ISN) based on the semantic graph, wherein the ISN represents causal relationships between the edge-based network devices. (see Ploennigs, [¶¶0081-0083]: “A knowledge graph 510 (e.g., a semantic knowledge graph may be created/generated from a sensor list. A causal link may be created and/or identified between each sensor using physical knowledge. A cognitive reasoning operation may be performed to reason that one or more physical relationships of the sensor influences one or more linked or associated sensors.”);
Ploennigs does not teach but, Tang teaches:
Processing the ISN using an array of Kalman filters to capture a topological structure of the network and spatial features representing changes in the characteristics of the network. (see Tang, [¶¶0075, 0077]: “Alternatively the calibration may be achieved by connecting a plurality of Kalman filters in parallel with each other. Each of the Kalman filters in the parallel architecture may be independent of the rest of the filters. At least one Kalman filter per subset may determine an actual spatial relationship between the at least two sensors in each subset based on the sensor data. A plurality of Kalman filters may work in parallel to determine the actual spatial relationship between the sensors in a plurality of subsets. An additional calculation may be performed to determine the spatial configuration of the plurality of sensors relative to one another based on the actual spatial relationship between the at least two sensors in each subset.”);
(Ploennigs generates a semantic knowledge graph from IoT sensor data representing spatial, physical, system context, and processing relationships, and subsequently applies cognitive reasoning to derive causal relationships corresponding to the claimed ISN. In the proposed combination, Ploennigs’s graph is generated from Nolan’s operational measurements of Hartley’s edge devices. The measurements and device-state variables associated with the ISN’s causal relationships are supplied to Tang’s parallel Kalman filters to determine overall topology and spatial changes in the network.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s multilayer edge network architecture, as implemented using Murray’s certificate-based authentication and Nolan’s IoT sensor monitoring, to incorporate Ploennigs’s semantic knowledge graph and causal reasoning functionality and Tang’s parallel Kalman filter processing. Nolan captures operational measurements through sensing capable edge devices but does not detail organizing those measurements into a semantic network model or processing the represented device relationships to track topological changes. Ploennigs provides this implementation by generating a semantic knowledge graph representing spatial, physical, system-context, and causal relationships. Tang further provides parallel Kalman filters for processing sensor measurements to determine spatial relationships and overall spatial configuration. A person of ordinary skill would have been motivated to employ Ploennigs’s semantic and causal graph in Hartley’s architecture to organize Nolan’s operational measurements and identify relationships among the edge devices. The person would further have been motivated to process the measurements and device state variables associated with those relationships using Tang’s parallel Kalman filters to reduce sensor noise, track spatial and topological changes, and efficiently analyze multiple edge devices. The combination would predictably results in a causal semantic network processed using an array of Kalman filters to capture network topology and spatial changes.
Claim 13 recites substantially the same limitations as claim 6 in system form. Accordingly, claim 13 is rejected for the same reasons set forth above with respect to claim 6.
Claims 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”) in view of Nolan et al, (U.S. Pub. No. 2021/012,6826 A1, hereinafter “Nolan”) in view of Ploennings et al, (U.S. Pub. No. 2020/024,2199 A1, hereinafter “Ploennings”) in view of Tang et al, (U.S. Pub. No. 2017/015,3122 A1, hereinafter “Tang”) and in further view of Dube et al, (U.S. Pub. No. 2015/016,9291 A1, hereinafter “Dube”)
Regarding claim 7,
Dube teaches:
Adjusting an optimal number of RPI instances required for operation in the network based on a pre-determined threshold and at least one of the changes in the characteristics of the network. (see Dube, [¶¶0073, 0082]: “The estimated values of the system state are used to compute the required scaling actions for the cloud service. Specifically, given a response time SLA, Eqns. (1) and (2) are used to determine the minimum n.sub.j required to ensure SLA compliance. "THRES(x,y)" refers to a rule-based provisioning policy that adds one application VM when the average application tier utilization exceeds y % for successive intervals and removes one application VM when the average utilization falls below x % for successive intervals.”);
(Dube adjusts the number of deployed service instances by adding or removing virtual machine instances when monitored utilization crosses predetermined thresholds and determines the minimum number required to satisfy a performance constraint. In the proposed combination, Dube’s application instances correspond to virtual instances implementing Hartley’s RPI functionality, and the number of RPI instances is adjusted when the network changes detected through Nolan, Ploennigs, and Tang satisfy the predetermined threshold.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartley’s multilayer edge network architecture, as implemented using Murray’s certificate authentication, Nolan’s IoT monitoring, Ploennigs’s semantic modeling, and Tang’s Kalman filter processing, to incorporate Dube’s threshold-based instance scaling technique. The combined system detects changes in network characteristics, but does not detail adjust the number of deployed processing instances in response to those changes. Dube provides this implementation by monitoring system conditions, comparing the monitored values with predetermined thresholds, and adding or removing virtual-machine instances while determining the minimum number necessary to satisfy a performance requirement. A person of ordinary skill would have been motivated to apply Dube’s scaling technique to Hartley’s RPI instances to maintain required network performance while avoiding overprovisioning or insufficient inspection capacity. The combination would predictably results in adjusting the number of RPI instances when detected changes in network characteristics satisfy a predetermined threshold.
Claim 14 recites substantially the same limitation as claim 7 in system form. Accordingly, claim 14 is rejected for the same reasons set forth above with respect to claim 7.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Hartley et al, (U.S. Pub. No. 2024/011,4010 A1, hereinafter “Hartley”) in view of Murray et al, (U.S. Pub. No. 2021/004,4972 A1, hereinafter “Murray”) in view of Nolan et al, (U.S. Pub. No. 2021/012,6826 A1, hereinafter “Nolan”) in view of Ploennings et al, (U.S. Pub. No. 2020/024,2199 A1, hereinafter “Ploennings”) in view of Tang et al, (U.S. Pub. No. 2017/015,3122 A1, hereinafter “Tang”) and in further view of Dube et al, (U.S. Pub. No. 2015/016,9291 A1, hereinafter “Dube”)
Claim 20 recites substantially the same limitation as claim 7, including the limitations of claim 6 from which claim 7 depends, in computer program product form. Accordingly, claim 20 is rejected for the same reasons set forth above with respect to claim 6 and 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-3726. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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 at (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.
/ARHAM NMN AHMED/Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Prosecution Insights