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 .
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 3/30/2026 has been entered.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 5/6/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Response to Amendment
This communication is in response to the amendment filed on 3/30/2026. The Examiner acknowledges amended claims 1-22. No claims have been cancelled. Claims 21-22 have been added. Claims 1-22 are pending and claims 1-22 are rejected. Claims 1, 9, and 15 is/are independent.
The rejection(s) of claims under 35 U.S.C. § 103 are maintained as indicated below.
Response to Arguments
Applicant's arguments filed 3/30/2026 have been fully considered. Applicant argues (see Remarks, page 7, para. 4-page 11, para. 2) that the references cited in the previous rejection fail to disclose the newly amended claim features. This argument is unpersuasive.
On page 9 of the remarks, 1st paragraph through 5th paragraph, Applicant argues that:
A. Blatt
As Applicant understands, Blatt describes privacy-preserving routing using homomorphic encryption of routing information in packet headers, homomorphic computations performed in a non-TEE, and selective decryption of routing decisions using secret keys stored in a trusted execution environment (TEE) (see, for example, paragraphs [008], [0016]-[0019].
Blatt' s routing intermediary is fundamentally a cryptographic processing node operating on encrypted routing values and using secret keys in a TEE to decrypt a next hop address. Thus, Blatt does not teach or suggest the amended features that. [sic]A secure plaintext label is readable by packet routers without using the encryption key used to encrypt the encrypted content of the network packet." Rather, Blatt is directed to routing privacy via encrypted computation and selective decryption, not to providing a packet-router readable label that is readable without using the packet's encrypted-content encryption key.
Examiner respectfully disagrees. Blatt et al. U.S. Publication 20210399983 (hereinafter “Blatt”) describes (Blatt para 8) the packet header is read and used to perform homomorphic computations, and the “one or more public encryption keys” used to encrypt (Blatt para 25) the data payload is not needed to perform the homomorphic computations. The packet header of the Blatt reference can disclose “the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet” if the Blatt reference is cited by itself, because of the homomorphic computations using header data. However, there is an additional layer of encryption required by the combination of this rejection and so we address the 2nd layer of encryption from the secondary reference below.
On page 10 of the remarks, 2nd paragraph through top paragraph of page 11, Applicant argues that:
B. Scott
As Applicant understands Scott teaches multiplayer encryption of packets using at least two keys (a ''secure key'' and a ''general key''), where packet components such as the body and secure header are encrypted using the secure key and then further encrypted using the general key (see, for example, Scott at paragraphs [0051]-[0053], [0083]-[0086].
Scott expressly explains that a key (or keys) is used to encrypt and decrypt packet content, with the secure entity managing the secure key and the general entity managing the general key (Scott, at paragraphs [0051]-[0051]). Scott further describes decrypting the multi player-encrypted packet using the general key to reveal an encrypted packet and then decrypting using the secure key to reveal restricted data (Scott, for example, at [0090]-[0091], Fig. 4) Scott, therefore, is key-dependent by design. To the extent Scott is relied upon to supply a ''secure data encoding of a portion of the encrypted content'', as the Examiner maintains in the Final Office Action and the Advisory Action, that encoding is accomplished by encrypting packet components so that meaningful access/interpretation requires the corresponding key(s).
This is incompatible with amended claims 1, 9, and 15, which no[w] require that the secure plaintext label is readable by packet routers ''without using the encryption key used to encrypt the encrypted content of the network packet."
While Scott describes an embodiment where ''updated general header 314 remains unencrypted'' (paragraph [0085]), that unencrypted header cannot satisfy the ''secure data encoding... wherein the secure data encoding prevents a third-party interceptor from understanding the information the secure plaintext label represents'' feature, as recited in independent claims 1, 9, and 15, because Scott expressly leaves it unencrypted for routing and translation. Conversely, Scott's embodiments that do encrypt header components do so using the relevant key(s) (general key and/or secure key), making readability/interpretation key dependent. This therefore does not meet the amended requirement in claims 1, 9, and 15 that the packet routers read the secure plaintext label without using the encryption key used to encrypt encrypted content of the network packet.
Examiner respectfully disagrees. Applicant argues that the amended limitation excludes reading on the teaching of Scott et al. U.S. Publication 20210160228 (hereinafter “Scott”). Examiner disagrees with applicant’s interpretation and application of the limitation.
Under the broadest reasonable interpretation, “the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet” reads on a scope that at least includes information can be extracted from the secure plaintext label without needing to decrypt the payload of the packet. In Scott, the double encrypted packet does not require the decrypting of the payload, and instead only decrypts the double encrypted packet one time using the general key (Scott, para 6) to reveal the information of the header. Furthermore, the specification does not expressly define readable. Para 41 of applicant’s published application states “The secure plaintext label is accessible (e.g., readable, interpretable, translatable, or decodable) by the one or more packet routers.” The scope of this limitation under the broadest reasonable interpretation can include just simply reading bits of the header without necessarily understanding the header, which reads on Scott because Scott teaches a technique that can read the bit data of the header (para 6, 85).
Scott does require using both the general key and the secure key to fully decrypt the double encrypted packets until the packets reach their destination. However, completing a task of forwarding the packets do not require using the 2nd secure key to decrypt the payload. The embodiment in Scott discussed by applicant where ''updated general header 314 remains unencrypted'' (paragraph [0085]) is not needed to disclose the amended claim limitations.
Regarding applicant’s argument (page 11, 2nd to 3rd paragraph) against Diehl, the combination of Blatt and Scott discloses the newly added language of the amendment and the office action does not allege that Diehl discloses the specific newly added language of the amendment. Instead, Diehl discloses filtering packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets, as argued below. Examiner therefore agrees that the Diehl reference does not disclose “the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet”.
Regarding applicant’s argument (page 11, bottom four paragraphs and top paragraph of page 12) against the combination of Blatt, Scott, and Diehl, “the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet” can read on the combination of references even with the key dependency of the references, because the key dependency occurs only at the destination of the packet, and during the routing at the intermediary information can be extracted from the general header (Scott para 6) without needing to decrypt the payload of the packet and without requiring the secure key (Scott para 6 and 85).Applicant's arguments have been fully considered and are unpersuasive. Therefore, the rejection of claim 1 is maintained.
Regarding applicant’s arguments for claims 21 and 22 (page 12, 3rd paragraph to page 14, 3rd paragraph), examiner agrees that the currently cited references do not disclose the limitations of claims 21 and 22. Instead, the examiner has cited new reference Kneckt et al. U.S. Publication 20240048974 (hereinafter “Kneckt”). Kneckt at para 63 discloses an encrypted header includes a quality of service control field. Claim 22 recites that the static communication label represents one of a list of objects which includes quality of service label. The once encrypted header described in Scott discloses a portion of the encrypted content, and the twice encrypted header described in Scott discloses a secure data encoding. Adding the QoS control field of Kneckt to the encrypted header will turn the encrypted header described in Scott into a static communication label, thereby disclosing the limitations of newly added claims 21 and 22.
Examiner has considered Applicant's remarks to the extent that they may be applicable to the remaining independent claims (e.g., independent claims 9 and 15) and finds them unpersuasive for the same reasons.
Regarding applicant’s arguments with respect to the dependent claims, the dependent claims inherit the limitations of the independent claims from which the dependent claims depend and are rejected for the same reasons. Furthermore, the dependent claims do not recite additional limitations that are allowable, as indicated in the office action below.
Accordingly, Applicant's argument is not persuasive with respect to the rejection under the cited art, and the rejection is maintained. Applicant's arguments/amendments have been fully considered, but are not persuasive.
Claim Rejections - 35 USC § 112
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-22 is/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 pre-AIA the applicant regards as the invention.
Claims 1, 9, and 15 recite “the encryption key” However, there is no antecedent basis for the encryption key.
The dependent claims inherit the limitations of their respective independent claims and are rejected for the same reasons as their respective independent claim.
Appropriate correction is required.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 6, 9-10, and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt et al. U.S. Publication 20210399983 (hereinafter “Blatt”) in view of Scott et al. U.S. Publication 20210160228 (hereinafter “Scott”), further in view of Diehl et al. U.S. Publication 20090222877 (hereinafter “Diehl”).
As per claim 1, Blatt discloses
A method [method, para. 8] of enforcing a communication policy [source and destination addresses must be homomorphically encrypted but available to be read by intermediaries for forwarding, para. 8; adopt a homomorphic encryption scheme for data packets, para. 25] at a communication intermediary [one of the intermediate routing device, para. 8; intermediate routing device 116, para. 25] configured to communicate between a first communicating entity [source device, para. 8] and a second communicating entity, [final destination device, para 8] wherein the communication intermediary includes one or more packet routers,[intermediate routing device transmits data packet to decrypted address, para. 8;] the method comprising:
Blatt [0008] In an embodiment of the invention, a system, method, and non-transitory computer readable storage medium is provided for privacy preserving routing of a data packet originating at a source device, forwarded through a sequence of intermediate routing devices, and destined to terminate at a final destination device. One of the intermediate routing devices may receive the data packet comprising a packet header and a data payload. The packet header may comprise at least a final destination address of the final destination device that may be homomorphically encrypted by one or more public homomorphic encryption keys. At the one of the intermediate routing devices, in a non-trusted execution environment (non-TEE), embodiments of the invention may perform homomorphic computations on the homomorphically encrypted final destination address in homomorphically encrypted space to determine a homomorphically encrypted address of a next intermediate routing device in the sequence to route the data packet. At the one of the intermediate routing devices, in a trusted execution environment (TEE), embodiments of the invention may store one or more secret homomorphic decryption keys. At the one of the intermediate routing devices, at the TEE, embodiments of the invention may decrypt the homomorphically encrypted address of the next intermediate routing device in the sequence to generate an unencrypted address of the next intermediate routing device. At the one of the intermediate routing devices, embodiments of the invention may transmit the data packet to the decrypted address of the next intermediate routing device according to an updated packet header with the unencrypted address of the next intermediate routing device in the sequence.
identifying,[perform homomorphic computations on encrypted final destination address extracted from header, para. 8] by the one or more packet routers, [intermediate routing device 116, para. 25] a secure plaintext label [packet header includes encrypted source and destination addresses, para. 25] in each network packet of labeled network traffic received at the one or more packet routers, each network packet further including encrypted content [the header and payload are encrypted using separate keys, para. 25] configured to be inaccessible [only final destination device can decrypt data payload, para. 25] by the one or more packet routers, the secure plaintext label being accessible [the intermediate routing device can determine a homomorphically encrypted address from the header, para. 8; only the forwarding address may be decrypted in a TEE, para. 16, 19] by the one or more packet routers
Blatt [0025] Data packet 102 may comprise a packet header 106 and data payload 118. To preserve routing privacy and protect against network attacks it may be desirable to adopt a homomorphic encryption scheme for data packets. Accordingly, packet header 106 may comprise an encrypted source address 112 of a source device 108(1) and/or an encrypted final destination address 140 of a final destination device 108(n) homomorphically encrypted by one or more public homomorphic encryption keys. Packet header 106 may also comprise an address 116 of an intermediate routing device 116 to which data packet 102 is forwarded in the routing sequence. Data payload 118 may be encrypted 120 (homomorphically or non-homomorphically) by one or more public encryption keys. In some embodiments, only the final destination device 108(n) that is the intended recipient of the data packet 102, and no other intermediate and/or source device, may possess the corresponding secret key to decrypt data payload 118. In the example of FIG. 1A, data packet 102 is forwarded from intermediate routing device 108(i−1) to next intermediate routing device 108(i).
Para 8 At the one of the intermediate routing devices, in a non-trusted execution environment (non-TEE), embodiments of the invention may perform homomorphic computations on the homomorphically encrypted final destination address in homomorphically encrypted space to determine a homomorphically encrypted address of a next intermediate routing device in the sequence to route the data packet.
[0025] Data packet 102 may comprise a packet header 106 and data payload 118. To preserve routing privacy and protect against network attacks it may be desirable to adopt a homomorphic encryption scheme for data packets. Accordingly, packet header 106 may comprise an encrypted source address 112 of a source device 108(1) and/or an encrypted final destination address 140 of a final destination device 108(n) homomorphically encrypted by one or more public homomorphic encryption keys. Packet header 106 may also comprise an address 116 of an intermediate routing device 116 to which data packet 102 is forwarded in the routing sequence. Data payload 118 may be encrypted 120 (homomorphically or non-homomorphically) by one or more public encryption keys. In some embodiments, only the final destination device 108(n) that is the intended recipient of the data packet 102, and no other intermediate and/or source device, may possess the corresponding secret key to decrypt data payload 118. In the example of FIG. 1A, data packet 102 is forwarded from intermediate routing device 108(i−1) to next intermediate routing device 108(i).
[The Blatt reference describes (para 8) the packet header is read and used to perform homomorphic computations, and the “one or more public encryption keys” used to encrypt (para 25) the data payload is not needed to perform the homomorphic computations. However, there is an additional layer of encryption required by the combination of this rejection and so we address the 2nd layer of encryption from the secondary reference]
However, Blatt does not expressly disclose and including a secure data encoding of a portion of the encrypted content, wherein the secure data encoding prevents a third-party interceptor from understanding the information the secure plaintext label represents and the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet;
evaluating whether the labeled network traffic satisfies an enforcement condition of the communication policy based on the secure plaintext label; and
instructing a network controller to operate on the labeled network traffic according to the communication policy, based on the operation of evaluating.
Scott discloses encrypting the encrypted header
[the once encrypted header discloses a portion of the encrypted content
the twice encrypted header discloses a secure data encoding
Scott discloses does not require using the secure key to decrypt the payload (the encrypted packet) of the double-encrypted packet in order to route the packet based on reading the contents of the general header. The packet header (disclosing secure plaintext label) in the Blatt reference is modified according to this combination rejection so that the packet header includes the Scott secure data encoding, and so the modified packet header is addressed with respect to Scott]
[0006] In another illustrative example, a method is provided for providing secure aerial or space communications. A satellite having a general payload and a hosted payload receives a multilayer-encrypted packet. The general payload decrypts the multilayer-encrypted packet using a general key to reveal an encrypted packet and a general header for the encrypted packet. The general payload determines that the encrypted packet is to be routed to the hosted payload based on contents of the general header. The general payload relays the encrypted packet to the hosted payload. The hosted payload decrypts the encrypted packet using a secure key to reveal a data packet containing restricted data.
[0085] To create double-encrypted packet 310, the contents of general header 306 are processed in some manner but updated general header 314 remains unencrypted. For example, general header 306 may be updated to form updated general header 314 without encryption of general header 306. Updating general header 306 may include updating one or more fields of general header 306 to ensure that the data will be routed to the correct destination. For example, some network translation of general header 306 may be performed to convert between a secure IP address space and a general IP address space (or between a secure Ethernet address space and a general Ethernet space). Creating double-encrypted packet 310 also includes further encrypting (e.g., adding another layer or level of encryption) encrypted body 311 and encrypted secure header 313 of encrypted packet 308 using general key 309 to form double-encrypted body 316 and double-encrypted secure header 318, respectively.
[0086] Creating double-encrypted packet 312 includes further encrypting encrypted body 311 encrypted secure header 313 of encrypted packet 308 using general key 309 to form double-encrypted body 320 and double-encrypted secure header 322, respectively and encrypting general header 306 to form encrypted general header 324. I
[Under the broadest reasonable interpretation, “the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet” reads on a scope that at least includes information can be extracted from the secure plaintext label without needing to decrypt the payload of the packet. In Scott, the double encrypted packet does not require the decrypting of the payload, and instead only decrypts the double encrypted packet one time using the general key (Scott, para 6) to reveal the information of the header. Furthermore, the specification does not expressly define readable. Para 41 of applicant’s published application states “The secure plaintext label is accessible (e.g., readable, interpretable, translatable, or decodable) by the one or more packet routers.” The scope of this limitation under the broadest reasonable interpretation can include just simply reading bits of the header without necessarily understanding the header, which reads on Scott because Scott teaches a technique that can read the bit data of the header (para 6, 85).
Scott does require using both the general key and the secure key to fully decrypt the double encrypted packets when the packets reach their destination. However, completing a task of forwarding the packets do not require using the 2nd secure key to decrypt the payload.
]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Blatt with the technique for double encrypting the header of Scott to include the secure plaintext label being accessible by the one or more packet routers and including a secure data encoding of a portion of the encrypted content, wherein the secure data encoding prevents a third-party interceptor from understanding the information the secure plaintext label represents and the secure plaintext label is readable by the one or more packet routers without using the encryption key used to encrypt the encrypted content of the network packet;
One of ordinary skill in the art would have made this modification to improve the ability of the system to double encrypt the header, so that the system may provide an additional level of protection for sensitive data. The system of the primary reference can be modified to double encrypt the header of the packet, so that the header can be protected by two different keys which can be controlled by different entities or components. Due to the second level encryption, third parties may not understand information represented by the header, even if the first level encryption is compromised. Furthermore, the ability to read the header to facilitate routing without decrypting the encrypted packet adds an additional security layer to prevent eavesdropping by malicious 3rd parties.
However, the combination of Blatt and Scott does not expressly disclose evaluating whether the labeled network traffic satisfies an enforcement condition of the communication policy based on the secure plaintext label; and
instructing a network controller to operate on the labeled network traffic according to the communication policy, based on the operation of evaluating.
Diehl discloses filtering packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets,
for example:
evaluating [inspecting network packets and dropping or rejecting network packets that meet a set of firewall filtering rules, para. 19] whether the labeled network traffic [packet source and destination IP address, para. 19, 40; packet ports used, para. 19; packet application characteristics, para. 19] satisfies an enforcement condition [filtering based by examining characteristics such as source and destination network addresses, ports used, para. 19] of the communication policy [intrusion prevention rule set comprising a plurality of rules, para. 10] based on the secure plaintext label; and
instructing a network controller [module, para. 19 ] to operate on [module within network device inspects and rejects packets, para. 19] the labeled network traffic according to the communication policy, [inspects and rejects packets according to set of firewall filtering rules, para. 19] based on the operation of evaluating.
Diehl [0010] Some example embodiments of the invention comprise a computer network device that comprises an intrusion prevention rule set comprising a plurality of rules, each of the plurality of rules associated with two or more rule classification parameters, and an intrusion prevention module that is operable to use two or more of the classification parameters associated with the plurality of intrusion protection rules to selectively apply the rules to provide network intrusion protection of network traffic. In further examples, the rules comprise signatures, policies, responses, and other such information.
[0041] The response mapping shown here comprises a series of possible actions that can be associated with the response map, including allowing the traffic with no audit, allowing the traffic but auditing or logging the traffic, denying the traffic and auditing it, dropping the traffic and auditing it, dropping the traffic with no auditing, and blackholing a traffic stream by blocking all traffic from the originating IP address for a period of time and auditing the event.
Diehl [0019] The network device 103 is in various embodiments a firewall device, and intrusion protection device, or functions as both. A firewall device or module within the network device provides various network flow control functions, such as inspecting network packets and dropping or rejecting network packets that meet a set of firewall filtering rules. As described previously, firewalls typically perform their filtering functions by observing communication packets, such as TCP/IP or other network protocol packets, and examining characteristics such as the source and destination network addresses, what ports are being used, and the state or history of the connection. Some firewalls also examine packets traveling to or from a particular application, or act as a proxy device by processing and forwarding selected network requests between a protected user and external networked computers.
Diehl [0032] A packet or network stream having a detect/IDS policy type and a certain attack type can be configured to be handled in a certain way, as described above. Desirably, the response should be associated with the anticipated severity and type of the attack, but can be handled as the network administrator sees fit using the.
[0040] Here, a rule set that describes Oracle.TM.-specific attacks that target an Oracle database server have been configured with one signature group as an IDS rule that is set to Allow and for another signature group as an IPS rule that is set to black hole or drop all traffic from the originating IP address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt and Scott with the technique for filtering packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets of Diehl to include
evaluating whether the labeled network traffic satisfies an enforcement condition of the communication policy based on the secure plaintext label; and
instructing a network controller to operate on the labeled network traffic according to the communication policy, based on the operation of evaluating.
One of ordinary skill in the art would have made this modification to improve the ability of the system to detect network intrusion and filter packets to prevent or mitigate the network intrusion. The system of the primary reference as modified can be further modified to filter packets based on packet characteristics according to a set of rules.
As per claim 2, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt and Scott does not expressly disclose wherein the operation of instructing includes an instruction to operate on the labeled network traffic to restrict transmission of the labeled network traffic from the communication intermediary, responsive to determining that the labeled network traffic satisfies the enforcement condition.
Diehl discloses filtering (i.e. restricting transmission of) packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets [See Para. 19; see claim 1 for citations]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt and Scott with the technique for
filtering packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets of Diehl to include
wherein the operation of instructing includes an instruction to operate on the labeled network traffic to restrict transmission of the labeled network traffic from the communication intermediary, responsive to determining that the labeled network traffic satisfies the enforcement condition.
One of ordinary skill in the art would have made this modification to improve the ability of the system to detect network intrusion and filter packets to prevent or mitigate the network intrusion. The system of the primary reference can be modified to filter packets based on packet characteristics according to a set of rules.
As per claim 6, the rejection of claim 1 is incorporated herein.
Blatt discloses wherein the secure plaintext label is included in each network packet [Data packet 102 may comprise a packet header 106, para. 25] of a communication sequence [ queue outbound packets, para. 30] between the first communicating entity and the communication intermediary.
[0003] A network routes data packets, such as IP packets, from a source address, forwarded through a sequence of intermediate nodes, to a final destination address
As per claim 9, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. Claim 9 also recites A system for …
one or more hardware processors;
one or more packet routers including a label identifier configured to …
a network traffic evaluator executable by the one or more hardware processors and configured to…
a network controller instructor executable by the one or more hardware processors and configured to …
Blatt discloses A system [system, para 8] for …
one or more hardware processors; [secure processor, para. 7]
one or more packet routers [one of the intermediate routing device, para. 8; intermediate routing device 116, para. 25] including a label identifier [secure processor, para. 7]
However, the combination of Blatt and Scott does not expressly disclose, but Diehl discloses
a network traffic evaluator [network device, para 19] executable by processor resources [para. 26]
a network controller instructor[module within network device, para 19] executable by processor resources [para. 26]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt and Scott with the technique for
filtering packets based on packet characteristics according to a set of rules and a module of a network device performing the inspection and rejection of packets of Diehl to include
a network traffic evaluator executable by the one or more hardware processors and configured to evaluate whether the labeled network traffic satisfies an enforcement condition of the communication policy based on the secure plaintext label; and
a network controller instructor executable by the one or more hardware processors and configured to instruct a network controller to operate on the labeled network traffic according to the communication policy, based on the evaluation.
One of ordinary skill in the art would have made this modification to improve the ability of the system to detect network intrusion and filter packets to prevent or mitigate the network intrusion. The system of the primary reference can be modified to filter packets based on packet characteristics according to a set of rules.
As per claim 10, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 14, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 6, and is/are rejected for the reasons detailed with respect to claim 6.
As per claim 15, the claim(s) is/are directed to one or more tangible processor-readable storage media with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. The specification defines tangible processor-readable storage media as excluding signals per se at para. 50.
Claim 15 also recites, and Blatt discloses
One or more tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a computing device [intermediate routing devices 240, 250, and 210 a male ] a process for enforcing a communication policy at a communication intermediary configured to communicate between a first communicating entity and a second communicating entity, the process comprising: [see claim 1 rejection]
[0047] Embodiments of the invention may include an article such as a non-transitory computer or processor readable medium, or a computer or processor non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory, encoding, including or storing instructions, e.g., computer-executable instructions, which, when executed by a processor or controller, carry out methods disclosed herein.
[0037] Source, final destination, and intermediate routing devices 240, 250, and 210 may include one or more controller(s) or processor(s) 246 in non-TEE 243 and 247 in TEE 245, 256 in non-TEE 253 and 257 in TEE 255, and 216 in non-TEE 214 and 219 in TEE 215, respectively, for executing operations according to embodiments of the invention and one or more memory unit(s) 248 in non-TEE 243 and 249 in TEE 245, 258 in non-TEE 253 and 259 in TEE 255, and 218 in non-TEE 214 and 217 in TEE 215, respectively, for storing data (e.g., keys and encrypted or decrypted data) and/or instructions (e.g., software for applying keys to encrypt or decrypt data, or performing HE computations over encrypted data, according to embodiments of the invention) executable by the processor(s). Processor(s) 246, 247, 256, 257, 216 and/or 219 may include, for example, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a controller, a chip, a microchip, an integrated circuit (IC),
As per claim 16, the claim(s) is/are directed to one or more tangible processor-readable storage media with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
Claims 3, 11 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt in view of Scott, in view of Diehl, further in view of Abley et al. U.S. Publication 20190280948 (hereinafter “Abley”).
As per claim 3, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose wherein the data encoding includes an encoded representation of a domain of a tenant to which the labeled network traffic is directed, the tenant being one of multiple tenants in a multi-tenant system.
Abley discloses encoding a domain name of a tenant [customer of tenant environment, para. 15] that receives packet traffic
[multi-tenant system disclosed by tenant environment. Since the customers in the tenant environments receive as well as send traffic network traffic, some of the labeled network traffic, disclosed by the headers with labels, is directed to the tenants]
para. 23 The header contains various parameters that relate to the sections of the messages which follow it. In general, the header section contains the following fields: …The domain name can be broken into discrete labels which are concatenated; each label is encoded in the wire format of the DNS message as the length of that label followed by the label itself, or as a pointer to another encoding of a domain name in the same message
Abley para. 15 and cloud provider (e.g. Amazon™, Digital Ocean™) operated servers coupled to network source devices 8 such as tenant environments containing connected source devices 8 operated by their customers. It is recognised that the network traffic 7 receipt and/or processing capabilities (e.g. traffic handling and processing capacity) of the responder server(s) 10 and/or other portions of the responder network 18 (e.g. one or more network devices 22) can become strained
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the technique for encoding a domain name of a tenant that receives packet traffic of Abley to include wherein the data encoding includes an encoded representation of a domain of a tenant to which the labeled network traffic is directed, the tenant being one of multiple tenants in a multi-tenant system.
One of ordinary skill in the art would have made this modification to improve the ability of the system to encode the tenant domains, thereby allowing for a representation of the tenant domain information in the headers to facilitate routing and inspection and rejection of tenant-directed traffic as necessary. The system of the primary reference can be modified to encode the domain of a tenant for multiple tenants in the tenant environment.
As per claim 11, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
As per claim 17, the claim(s) is/are directed to one or more tangible processor-readable storage media with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
Claims 4, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt in view of Scott, in view of Diehl, further in view of Pinheiro et al. U.S. Publication 20240114014 (hereinafter “Pinheiro”), further in view of Venkatachalam et al. U.S. Publication 20070086434 (hereinafter “Venkatachalam”)..
As per claim 4, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose wherein each network packet includes a connection identifier generated in a handshake between the first communicating entity and the second communicating entity prior to the operation of identifying, the connection identifier including the secure plaintext label.
Pinheiro discloses generating connection identifier during handshake [para. 163, 188, 204] and subsequently identifying the connection identifier [reconstruct application data based on connection identifier, para. 188]
[see also para. 163 establishing encrypted tunnel with handshake]
[0204] The request may further include an offer to establish an encrypted tunnel as part of a handshake procedure. For example, the encrypted tunnel may be based on TLS (e.g., TLS 1.3). The offer may be forwarded to the application server 230, based on one or more of the proxies 432, 434, to establish the encrypted tunnel.
[0188] In FIG. 8, example packet headers 800 in accordance with one or more implementations of the present disclosure are shown. For example, HTTP layer 620, 640, 652 packet headers may include an HTTP MASQUE payload (e.g., an HTTP method along with a forwarding address) to establish HTTP communications. The QUIC or MPQUIC layers (e.g., layer 622) may be defined by a packet header including a type bit or bits 802, a connection identifier 804, a version 806, a packet number 808, and a payload 810. This information may be encrypted as part of the UDP payload 820. …. The application server 230 can reconstruct the application data (e.g., application data 510) based on the connection identifier, packet number, and stream identifier in the encrypted payload
detail, this CID may later be used to regenerate the corresponding 4-tuple.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the technique for generating connection identifier during handshake and subsequently identifying the connection identifier of Pinheiro to include wherein each network packet includes a connection identifier generated in a handshake between the first communicating entity and the second communicating entity prior to the operation of identifying, the connection identifier including the secure plaintext label.
One of ordinary skill in the art would have made this modification to improve the ability of the system to establish the communication path by generating the communication identifier. Furthermore, subsequently identifying the connection identifier and the secure plaintext label facilitates communication over the correct communication path when there are multiple communication paths to choose from.
However, the combination of Blatt, Scott, Diehl, and Pinheiro does not expressly disclose the connection identifier including the secure plaintext label.
Venkatachalam discloses the connection identifier including the content from UDP header
para. 14 The resulting packet is then delivered to the flow classifier 18 which generates a connection ID (CID) value that uniquely identifies the communication connection associated with the VoIP packet 28. Classification rules are set up within the flow classifier 18 in a manner that generates a unique CID using information within the UDP header and the IP header of the VoIP packet 28
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, Diehl, and Pinheiro with the teaching of the connection identifier including the content from UDP header of Venkatachalam to include the connection identifier including the secure plaintext label.
One of ordinary skill in the art would have made this modification to improve the ability of the system to include the information from the UDP header (disclosing the secure plaintext label) in the connection identifier, in order to facilitate compatibility with networks that may utilize UDP header information as part of the communication identifier. The system of the primary reference can be modified to add the UDP header information to the communication identifier.
As per claim 12, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
As per claim 18, the claim(s) is/are directed to one or more tangible processor-readable storage media with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
Claims 5, 8, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt in view of Scott, in view of Diehl, further in view of Gupta et al. U.S. Publication 20180295134 (hereinafter “Gupta”).
As per claim 5, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose wherein the data encoding includes data representing a domain identifier of a destination domain of a communication destination, a server name indication of a server at the communication destination, a quality of service label associated in data with a communication source, or a geolocation associated in data with a communication source.
Gupta discloses encoding a destination server name
Gupta [0338] To further address these and potential issues, the present systems and methods may leverage wildcard domain name system (DNS) entries and/or wildcard secure socket layer (SSL) certificates to achieve transparent proxying of applications hosted at the server. The user of the client may be provided with a webpage including a link to the resource. The link may include an absolute URL to the particular resource or service of the application. The absolute URL may include the domain name of the intermediary device followed by the domain name of the server. Upon the user clicking the link, the client in turn may send a HTTP request.
The intermediary device may identify the absolute URL present in a HTTP request from the client for an application hosted at the server. From the identified absolute URL, the intermediary device may extract the domain name of the server hosting requested application. The intermediary device may generate an encoding for the domain name of the server hosting requested application,
and store a mapping between the generated encoding and the original domain name for the server. The intermediary device may then generate an HTTP redirect response with a rewritten absolute URL to transmit to the client. The rewritten URL may include a domain name of the intermediary device prefixed with the encoding for the domain name of the server. The DNS server for the client may be configured with a DNS entry with the hostname for the device and a wildcard, such that the DNS server resolves any subsequent requests with the rewritten URL to land on the device.
[0339] Upon receiving the HTTP redirect response, the client may be redirected to the URL indicated in the response, and may generate a second HTTP request to transmit to the intermediary device. The HTTP request may include the rewritten absolute URL. As the rewritten absolute URL includes the domain name of the intermediary device, the HTTP request may land on the intermediary device, as opposed to directly on the server hosting the server. Prior to forwarding the request to the server hosting the resource, the intermediary device may fetch the mapping for the encoding to identify the original domain name of the server hosting requested application. The intermediary device may rewrite the absolute URL included in the HTTP request by replacing the prefixed encoding and the domain name for the intermediary device with the original domain name for the server, so as to direct the HTTP request to the server hosting the requested application.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the technique for encoding a destination server name of Gupta to include wherein the data encoding includes data representing a domain identifier of a destination domain of a communication destination, a server name indication of a server at the communication destination, a quality of service label associated in data with a communication source, or a geolocation associated in data with a communication source.
One of ordinary skill in the art would have made this modification to improve the ability of the system to encode a server name, to facilitate adding a server name encoding where the original server name may be sensitive or inappropriate, such as adding the information in the header of a packet. The system of the primary reference can be modified to encode a server name and add the server name to a header of a packet.
As per claim 8, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose wherein the data encoding includes data representing a server name indication.
Gupta discloses wherein the data encoding includes data representing a server name indication.
Para. 338 The intermediary device may identify the absolute URL present in a HTTP request from the client for an application hosted at the server. From the identified absolute URL, the intermediary device may extract the domain name of the server hosting requested application. The intermediary device may generate an encoding for the domain name of the server hosting requested application,
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the technique for encoding a server name of Gupta to include wherein the data encoding includes data representing a server name indication.
One of ordinary skill in the art would have made this modification to improve the ability of the system to encode a server name, to facilitate adding a server name encoding where the original server name may be sensitive or inappropriate, such as information in the header of the packet. The system of the primary reference can be modified to encode a server name and add the server name to a header of a packet.
As per claim 13, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
As per claim 20, the claim(s) is/are directed to one or more tangible processor-readable storage media with limitations which correspond to limitations of claim 8, and is/are rejected for the reasons detailed with respect to claim 8.
Claims 7 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt in view of Scott, in view of Diehl, further in view of Nedeltchev et al. U.S. Publication 20130191628 (hereinafter “Nedeltchev”).
As per claim 7, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose wherein the secure plaintext label is positioned at a predefined position within a communication identifier in a header of each network packet.
Nedeltchev discloses that there are multiple different subheaders at different positions in the main header
for example, Nedeltchev discloses
wherein the secure plaintext label [UDP header 415 and UDP header 420, para. 27; unencrypted packet header, para. 15] is positioned at a predefined position [Figure 4 shows UDP header 415 and UDP header 420,at the predetermined position of each packet header ] within a communication identifier[ any combination of element 415, 420, 430 within the header of element 402a] in a header [the combination of all the depicted headers] of each network packet.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the teaching that there are multiple different subheaders at different positions in the overall header group of Nedeltchev to include wherein the secure plaintext label is positioned at a predefined position within a communication identifier in a header of each network packet.
One of ordinary skill in the art would have made this modification to improve the ability of the system to organize a group of sub- headers within the overall main header. The system of the primary reference can be further modified to include many different sub- headers so that when combined there is a group of headers, to facilitate transmitting greater amounts of information within the headers.
Claim 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blatt in view of Scott, in view of Diehl, further in view of Kneckt et al. U.S. Publication 20240048974 (hereinafter “Kneckt”).
As per claim 21, the rejection of claim 1 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose
wherein the secure plaintext label includes a secure data encoding of a static communication label derived from a portion of the encrypted content of the network packet.
Kneckt discloses an encrypted header includes a quality of service control field
[0063] FIG. 20 is an illustration 2000 for encryption-based secure scrambling, according to one or more embodiments. FIG. 20 relates to the second alternative. As illustrated FIG. 20 introduces the idea of a frame 2002 with an encrypted header 2004 and a message integrity check (MIC) field 2006 that follows the encrypted header 2004. The payload 2008 can be encrypted as described in IEEE 80.11. The encrypted header 2004 can, however, be encrypted differently than the payload 2008. Once the device encrypts the header, the encrypted header 2004 is added as a block cipher having a 16-octet size to the frame 2002. The encrypted header 2004 can include a QoS control field, a HT control field, a CCMP header or a GCMP header, a frame control field. The CCMP header or the GCMP header can include a MPDU specific value that can be used to encrypt the fields to generate the encrypted header. The MIC field 2006 can be added to the frame 2002 to protect the integrity of the encrypted header 2002. The MIC field 2006 can be 2 octets or 4 octets.
[as argued above in claim 1 with respect to Scott:
the once encrypted header described in Scott discloses a portion of the encrypted content
the twice encrypted header described in Scott discloses a secure data encoding
claim 22 indicates that the static communication label represents one or more objects and such an object can be a quality of service label. Adding the QoS control field to the encrypted header will therefore turn the encrypted header into a static communication label, thereby disclosing derived
]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the teaching that the encrypted header includes the quality of service of Kneckt to include wherein the secure plaintext label includes a secure data encoding of a static communication label derived from a portion of the encrypted content of the network packet.
One of ordinary skill in the art would have made this modification to improve the ability of the system to include the quality of service in the encrypted header. The system of the primary reference can be modified to include the quality of service in the encrypted header as a static value and the encrypted header becomes a static communication label. This allows for providing service at various quality levels.
As per claim 22, the rejection of claim 21 is incorporated herein.
However, the combination of Blatt, Scott, and Diehl does not expressly disclose
wherein the static communication label represents one or more of a server name indication, a domain identifier, a tenant domain, a server identifier, or a quality of service label.
Kneckt discloses encrypting header includes quality of service
[0063] FIG. 20 is an illustration 2000 for encryption-based secure scrambling, according to one or more embodiments. FIG. 20 relates to the second alternative. As illustrated FIG. 20 introduces the idea of a frame 2002 with an encrypted header 2004 and a message integrity check (MIC) field 2006 that follows the encrypted header 2004. The payload 2008 can be encrypted as described in IEEE 80.11. The encrypted header 2004 can, however, be encrypted differently than the payload 2008. Once the device encrypts the header, the encrypted header 2004 is added as a block cipher having a 16-octet size to the frame 2002. The encrypted header 2004 can include a QoS control field, a HT control field, a CCMP header or a GCMP header, a frame control field. The CCMP header or the GCMP header can include a MPDU specific value that can be used to encrypt the fields to generate the encrypted header. The MIC field 2006 can be added to the frame 2002 to protect the integrity of the encrypted header 2002. The MIC field 2006 can be 2 octets or 4 octets.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Blatt, Scott, and Diehl with the teaching that the encrypted header includes the quality of service of Kneckt to include wherein the static communication label represents one or more of a server name indication, a domain identifier, a tenant domain, a server identifier, or a quality of service label.
One of ordinary skill in the art would have made this modification to improve the ability of the system to include the quality of service in the encrypted header. The system of the primary reference can be modified to include the quality of service in the encrypted header as a static value, to facilitate providing service at various quality levels.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOWARD H LOUIE whose telephone number is (571)272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM 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, Jung W. Kim can be reached on 571-272-3804. 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 http://pair-direct.uspto.gov. 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.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
Prosecution Insights