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 .
DETAILED ACTION
1. Claims 1 - 40 are pending. Claims 1, 21 are independent. File date on 1-13-2025.
Claim Rejections - 35 USC § 101
2. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
3. Claim 21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter as follows. The claim(s) does/do fall within at least one of the four categories of patent eligible subject matter because Claim 11 is directed to software per se. Claim 11 is to be construed as a computer system of "software per se", unless the claim makes clear "network node" includes at least one hardware inclusive component.
Claim Rejections - 35 USC § 103
4. 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.
5. Claims 1, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev et al. (US PGPUB No. 20160119163) and in view of Carr et al. (US Patent No. 9,268,853).
Regarding Claims 1, 21, Fadeev discloses a method for tagging Internet Protocol (IP) packets with application-specific and session-specific information in a network communication system and a network node, comprising:
a) receiving a data packet from a client or server; (Fadeev ¶ 063: Client router 120 may identify each data flow based on the client device 110 (or data flow generating entity) that sends or receives each of the packet data flows (block 820). For example, client router 120 may identify the packet data flow based on a client device 110, an application, etc.) and
b) extracting header information from the received data packet. (Fadeev ¶ 107: Packets may flow from the IPv6-capable communication device in lead vehicle 1510 to PGW 1540. PGW 1540, in a similar manner as gateway 130 defined hereinabove, may read the extended header flags and, based on the flags and command, forward this packet to its destination. However, PGW 1540 may extract the extension header and send that extracted data (including traffic information) to rendezvous server 1550, which may be a collection server for traffic information.)
Fadeev does not explicitly disclose for c) determining whether the received data packet includes an application-specific tag or session-specific tag.
However, Carr discloses:
c) determining whether the received data packet includes an application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for c) determining whether the received data packet includes an application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether a application flow includes an application specific tag. (Carr col 8)
6. Claims 2, 5, 6, 13, 16, 22, 25, 26, 33, 36 are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev in view of Carr and further in view of Chang et al. (US PGPUB No. 20190207868).
Regarding Claims 2, 22, Fadeev-Carr discloses the method of claim 1 and a network node of claim 21, further comprising:
f) sending the received data packet to its intended destination using the determined processing route. (Fadeev ¶ 063: Client router 120 may identify each data flow based on the client device 110 (or data flow generating entity) that sends or receives each of the packet data flows (block 820). For example, client router 120 may identify the packet data flow based on a client device 110, an application, etc.)
Fadeev does not explicitly disclose for c) assigning a new application-specific tag or a new session-specific tag to the received data packet; d) updating the received data packet with the assigned application-specific tag or session-specific tag.
However, Carr discloses:
b) assigning a new application-specific tag or a new session-specific tag to the received data packet; d) updating the received data packet with the assigned application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended (updated) to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for c) determining whether the received data packet includes an application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
Fadeev does not explicitly disclose for a) analyzing the received data packet to determine an application-specific context and session-specific context based on source and destination IP addresses, transport layer port numbers, and payload content, and for e) determining an appropriate processing route based on the assigned application-specific tag or session-specific tag.
However, Chang discloses:
in response to determining that the received data packet does not include the application-specific tag or session-specific tag:
a) analyzing the received data packet to determine an application-specific context and session-specific context based on source and destination IP addresses, transport layer port numbers, and payload content; (Chang ¶ 111: commands and/or information can include one or more of: packet flow, packet state, packet context, buffer level, specific accelerator or compute device to use, memory transaction attributes, memory transaction data, and so forth. A packet parser can provide flow, state and context information. An accelerator could provide its queue level or level of busyness. A header or payload can convey commands or information using one or more of: a MAC source address, MAC destination address, IP source address, IP destination address, VLAN tags, MPLS headers, meta data, and so forth.)
e) determining an appropriate processing route based on the assigned application-specific tag or session-specific tag. (Chang ¶ 133: a determination can be made as to a next stage processing for a packet. For example, the determination can be made in connection with processing of a packet (e.g., by inspection of a header, VLAN tag, MPLS header, meta-data, or payload) so that after the processing of the packet, there is to be additional processing to be performed on the packet or information determined based on the processing of the packet. Next stage processing can be performed by a local device, accelerator, host device processor, remote accelerator, network interface, and so forth. ... A packet parser, accelerator, event block or other device or process can determine a next accelerator to process packet or destination of packet. Packet processing paths can be predefined or configurable. An example processing path includes: parsing a received packet, decrypting a packet, parsing decrypted portions of the packet, and providing the packet to a host.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for a) analyzing the received data packet to determine an application-specific context and session-specific context based on source and destination IP addresses, transport layer port numbers, and payload content, and for e) determining an appropriate processing route based on the assigned application-specific tag or session-specific tag as taught by Chang. One of ordinary skill in the art would have been motivated to employ the teachings of Chang for the benefits achieved from the flexibility of a system that enables the generation of a processing path for packets based on metadata tag information. (Chang ¶ 133)
Regarding Claims 5, 25, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22, wherein updating the received data packet with the assigned application-specific tag or session-specific tag comprises: adding an extension header that includes the application-specific tag or the session-specific tag to the received data packet. (Fadeev ¶ 094: client router 120 may add an IPv6 extension header (e.g., type 26) to the TCP flow. Client router 120 may identify one or more packet data flows based on a user application running on a user (or client) device, wherein the one or more packet flows are flowing over a communication link between the router 120 and the one or more user devices.; ¶ 111: Traffic alert system 1500 may transparently tag any application with extension headers. In this instance, a media stream may carry the header information for other applications without needing modifications of its own.)
Regarding Claims 6, 26, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose updating the received data packet with the assigned application-specific tag or session-specific tag comprises: inserting the application-specific tag or the session-specific tag into initial bytes of an IP packet payload of the received data packet.
However, Carr discloses wherein updating the received data packet with the assigned application-specific tag or session-specific tag comprises: inserting the application-specific tag or the session-specific tag into initial bytes of an IP packet payload of the received data packet. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for updating the received data packet with the assigned application-specific tag or session-specific tag comprises: inserting the application-specific tag or the session-specific tag into initial bytes of an IP packet payload of the received data packet as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
Regarding Claims 13, 33, Fadeev discloses the method of claim 12 and a network node of claim 21, further comprising:
b) sending the received data packet to its intended destination using the determined processing route. (Fadeev ¶ 063: Client router 120 may identify each data flow based on the client device 110 (or data flow generating entity) that sends or receives each of the packet data flows (block 820). For example, client router 120 may identify the packet data flow based on a client device 110, an application, etc.)
Fadeev does not explicitly disclose for a) determining an appropriate processing route based on the extracted metadata.
However, Chang discloses:
a) determining an appropriate processing route based on the extracted metadata; (Chang ¶ 133: a determination can be made as to a next stage processing for a packet. For example, the determination can be made in connection with processing of a packet (e.g., by inspection of a header, VLAN tag, MPLS header, meta-data, or payload) so that after the processing of the packet, there is to be additional processing to be performed on the packet or information determined based on the processing of the packet. Next stage processing can be performed by a local device, accelerator, host device processor, remote accelerator, network interface, and so forth. ... A packet parser, accelerator, event block or other device or process can determine a next accelerator to process packet or destination of packet. Packet processing paths can be predefined or configurable. An example processing path includes: parsing a received packet, decrypting a packet, parsing decrypted portions of the packet, and providing the packet to a host.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for a) determining an appropriate processing route based on the extracted metadata as taught by Chang. One of ordinary skill in the art would have been motivated to employ the teachings of Chang for the benefits achieved from the flexibility of a system that enables the generation of a processing path for packets based on metadata tag information. (Chang ¶ 133)
Regarding Claims 16, 36, Fadeev-Carr-Chang discloses the method of claim 12 and a network node of claim 32, wherein the received data packet is an IPv6 data packet. (Fadeev ¶ 063: Client router 120 may identify each data flow based on the client device 110 (or data flow generating entity) that sends or receives each of the packet data flows (block 820). For example, client router 120 may identify the packet data flow based on a client device 110, an application, etc.)
7. Claims 3, 12, 15, 23, 32, 35 are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev and in view of Carr and further in view of Chang and Wang et al. (Patent No. WO 2013059991 A1).
Regarding Claims 3, 23, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet.
However, Wang discloses wherein extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet. (Wang page 15: extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet as taught by Wang. One of ordinary skill in the art would have been motivated to employ the teachings of Wang for the benefits achieved from the flexibility of a system that enables the extraction of source and destination addresses including traffic class and flow labels in the processing of packet data. (Wang page 15)
Regarding Claims 12, 32, Fadeev-Carr discloses the method of claim 1 and a network node of claim 21.
Fadeev does not explicitly disclose for a) validating the application-specific tag or session-specific tag against a predefined table of valid application-specific tags and session-specific tags.
However, Carr discloses wherein further comprising:
in response to determining that the received data packet includes the application-specific tag or session-specific tag:
a) validating the application-specific tag or session-specific tag against a predefined table of valid application-specific tags and session-specific tags; (Carr col 2: The search can comprise connecting to the server, accessing a process table of the server, comparing a unique identifier associated with the application to active processes listed in the process table, and identifying the application when one of the listed active processes includes a segment that matches the unique identifier. In some examples, the search can further comprise accessing a file system of the server, comparing the unique identifier to files listed in the file system, and identifying the application when one of the listed files includes a segment that matches the unique identifier.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for c) determining whether the received data packet includes an application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
Fadeev does not explicitly disclose for b) extracting metadata associated with the validated application-specific tag or the validated session-specific tag (packet data)
However, Wang discloses:
b) extracting metadata associated with the validated application-specific tag or the validated session-specific tag. (Wang page 15: extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet; (extracting packet data))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for for b) extracting metadata associated with the validated application-specific tag or the validated session-specific tag (packet data) as taught by Wang. One of ordinary skill in the art would have been motivated to employ the teachings of Wang for the benefits achieved from the flexibility of a system that enables the extraction of source and destination addresses including traffic class and flow labels in the processing of packet data. (Wang page 15)
Regarding Claims 15, 35, Fadeev-Carr discloses the method of claim 12 and a network node of claim 32.
Fadeev does not explicitly disclose extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet.
However, Wang wherein extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet. (Wang page 15: extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for extracting header information from the received data packet comprises extracting a source IP address, a destination IP address, a traffic class, and flow label fields from the received data packet as taught by Wang. One of ordinary skill in the art would have been motivated to employ the teachings of Wang for the benefits achieved from the flexibility of a system that enables the extraction of source and destination addresses including traffic class and flow labels in the processing of packet data. (Wang page 15)
8. Claims 4, 24 are rejected under 35 U.S.C. 103 as being unpatentable over
Fadeev and in view of Carr and further in view of Chang and Young et al. (US Patent No. 10,736,029).
Regarding Claims 4, 24, Fadeev-Carr discloses the method of claim 2 and a network node of claim 22, wherein:
a) the received data packet is an IPv6 data packet; (Fadeev ¶ 063: Client router 120 may identify each data flow based on the client device 110 (or data flow generating entity) that sends or receives each of the packet data flows (block 820). For example, client router 120 may identify the packet data flow based on a client device 110, an application, etc.)
Fadeev does not explicitly disclose for b) concatenating traffic class and flow label fields in an IPv6 header of the received data packet.
However, Young discloses wherein updating the received data packet with the assigned application-specific tag or session-specific tag comprises:
b) concatenating traffic class and flow label fields in an IPv6 header of the received data packet. (Young col 10: Preparing the new IPv6 header 714 includes setting values of certain fields of the IPv6 header 708, such as the version field 802, a traffic class field 804, flow label field 806, and payload length field 808 (block 1004). For example, the source SRv6 node 102 may set version field 802 to a value corresponding to the IPv6, traffic class field 804 to the value for the obtained packet (e.g., a value indicating the Quality-of-Service), flow label field 806 to a sequence number associated with the obtained packet, and payload length field 808 to the value obtained by calculating the combined size of the new SRv6 header 716 and the obtained packet.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for b) concatenating traffic class and flow label fields in an IPv6 header of the received data packet as taught by Young. One of ordinary skill in the art would have been motivated to employ the teachings of Young for the benefits achieved from the flexibility of a system that enables the combining of parameters such as traffic class and flow labels fields in the processing of data packets. (Young col 10)
9. Claims 7, 27 are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev and in view of Carr and further in view of Chang and Dittmer et al. (Patent No. EP3822726 A1) and Miller et al. (US Patent No. 10,003,466).
Regarding Claims 7, 27, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22, further comprising:
Fadeev does not explicitly disclose for a) initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata.
However, Dittmer discloses:
a) initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata; (Dittmer ¶ 006: a method for monitoring (tracking) one or more components of one or more manufacturing application systems with respect to application-specific metrics is provided. In accordance with this embodiment, a processor may receive a first set of data associated with the one or more application-specific metrics corresponding to the one or more manufacturing application systems. The processor may also receive a second set of data from the one or more components associated with the one or more manufacturing application systems.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata as taught by Dittmer. One of ordinary skill in the art would have been motivated to employ the teachings of Dittmer for the benefits achieved from the flexibility of a system that enables the monitoring of application-specific metrics. (Dittmer ¶ 006)
Fadeev does not explicitly disclose for b) establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags.
However, Miller discloses:
b) establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags. (Miller col 16: The environment, in one embodiment, is a distributed and/or virtual computing environment utilizing several computer systems and components that are interconnected via communication links (connections), using one or more computer networks or direct connections.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
10. Claims 17, 37 are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev and in view of Carr and further in view of Wang and Dittmer et al. (Patent No. EP3822726 A1) and Miller et al. (US Patent No. 10,003,466).
Regarding Claims 17, 37, Fadeev-Carr discloses the method of claim 12 and a network node of claim 32, further comprising:
Fadeev does not explicitly disclose for a) initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata.
However, Dittmer discloses:
a) initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata; (Dittmer ¶ 006: a method for monitoring one or more components of one or more manufacturing application systems with respect to application-specific metrics is provided. In accordance with this embodiment, a processor may receive a first set of data associated with the one or more application-specific metrics corresponding to the one or more manufacturing application systems. The processor may also receive a second set of data from the one or more components associated with the one or more manufacturing application systems.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for a) initializing network configuration settings and data structures for tracking application-specific tags, session-specific tags, and flow metadata as taught by Dittmer. One of ordinary skill in the art would have been motivated to employ the teachings of Dittmer for the benefits achieved from the flexibility of a system that enables the monitoring of application-specific metrics. (Dittmer ¶ 006)
Fadeev does not explicitly disclose for b) establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags.
However, Miller discloses:
b) establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags. (Miller col 16: The environment, in one embodiment, is a distributed and/or virtual computing environment utilizing several computer systems and components that are interconnected via communication links, using one or more computer networks or direct connections.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for b) establishing connections with key servers for encryption and secure assignment and validation of application-specific tags and session-specific tags as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
11. Claims 8, 9, 28, 29, are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev in view of Carr and further in view of Chang et al. (US PGPUB No. 20190207868) and Miller et al. (US Patent No. 10,003,466).
Regarding Claims 8, 28, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose using a public/private key mechanism to verify integrity and source of the received data packet.
However, Miller discloses further comprising using a public/private key mechanism to verify integrity and source of the received data packet. (Miller col 18: The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for using a public/private key mechanism to verify integrity and source of the received data packet as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
Fadeev does not explicitly disclose determining whether the received data packet includes an application-specific tag or session-specific tag.
However, Carr discloses wherein determining whether the received data packet includes an application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for determining whether the received data packet includes an application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
Regarding Claims 9, 29, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose using an encryption protocol to secure the received data packet.
However, Miller discloses wherein further comprising using an encryption protocol to secure the received data packet. (Miller col 18: The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for using an encryption protocol to secure the received data packet as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
Fadeev does not explicitly disclose determining whether the received data packet includes an application-specific tag or session-specific tag.
However, Carr discloses wherein determining whether the received data packet includes an application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for determining whether the received data packet includes an application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
12. Claims 14, 18, 19, 34, 38, 39, are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev in view of Carr and further in view of Wang et al. (US PGPUB No. 20190207868) and Miller et al. (US Patent No. 10,003,466).
Regarding Claims 14, 34, Fadeev-Carr discloses the method of claim 12 and a network node of claim 32.
Fadeev does not explicitly disclose performing a security check based on the extracted metadata to verify an authenticity or an integrity of the data packet in response to determining that the received data packet includes the application-specific tag or session-specific tag.
However, Miller discloses further comprising performing a security check based on the extracted metadata to verify an authenticity or an integrity of the data packet in response to determining that the received data packet includes the application-specific tag or session-specific tag. (Miller col 18: The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for performing a security check based on the extracted metadata to verify an authenticity or an integrity of the data packet in response to determining that the received data packet includes the application-specific tag or session-specific tag as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
Regarding Claims 18, 38, Fadeev-Carr discloses the method of claim 12 and a network node of claim 32.
Fadeev does not explicitly disclose using a public/private key mechanism to verify integrity and source of the received data packet.
However, Miller discloses wherein further comprising using a public/private key mechanism to verify integrity and source of the received data packet. (Miller col 18: The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for using a public/private key mechanism to verify integrity and source of the received data packet as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
Fadeev does not explicitly disclose determining whether the received data packet includes the application-specific tag or session-specific tag.
However, Carr discloses wherein determining whether the received data packet includes the application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for determining whether the received data packet includes the application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
Regarding Claims 19, 39, Fadeev-Carr discloses the method of claim 12 and a network node of claim 32.
Fadeev does not explicitly disclose using an encryption protocol to secure the received data packet.
However, Miller discloses wherein further comprising using an encryption protocol to secure the received data packet. (Miller col 18: The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for using an encryption protocol to secure the received data packet as taught by Miller. One of ordinary skill in the art would have been motivated to employ the teachings of Miller for the benefits achieved from the enhanced security of a system that enables encryption techniques to be utilized providing data protection. (Miller col 18)
Fadeev does not explicitly disclose determining whether the received data packet includes the application-specific tag or session-specific tag.
However, Carr discloses wherein determining whether the received data packet includes the application-specific tag or session-specific tag. (Carr col 8: If the terminal 120 determined in step 305 that a potentially-unique fingerprint was not identified, the terminal 120 proceeds to step 309, where it determines whether any unique fingerprints are already associated with the target application. If so, the terminal 120 proceeds to step 313. Otherwise, the terminal 120 proceeds to step 311 where a unique ID in the form of a tag or metadata is appended to one or more processes and/or files associated with the target application.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for determining whether the received data packet includes the application-specific tag or session-specific tag as taught by Carr. One of ordinary skill in the art would have been motivated to employ the teachings of Carr for the benefits achieved from the flexibility of a system enabling the determination of whether an application flow includes an application specific tag. (Carr col 8)
13. Claims 10, 11, 30, 31, are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev and in view of Carr and further in view of Chang and Dittmer et al. (Patent No. EP3822726 A1).
Regarding Claims 10, 30, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose updating session states and flow metadata with the application-specific tag or session-specific tag for tracking ongoing sessions.
However, Dittmer discloses wherein further comprising updating session states and flow metadata with the application-specific tag or session-specific tag for tracking ongoing sessions. (Dittmer ¶ 006: a method for monitoring one or more components of one or more manufacturing application systems with respect to application-specific metrics is provided. In accordance with this embodiment, a processor may receive a first set of data associated with the one or more application-specific metrics corresponding to the one or more manufacturing application systems. The processor may also receive a second set of data from the one or more components associated with the one or more manufacturing application systems.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for updating session states and flow metadata with the application-specific tag or session-specific tag for tracking ongoing sessions as taught by Dittmer. One of ordinary skill in the art would have been motivated to employ the teachings of Dittmer for the benefits achieved from the flexibility of a system that enables the monitoring of application-specific metrics. (Dittmer ¶ 006)
Regarding Claims 11, 31, Fadeev-Carr-Chang discloses the method of claim 2 and a network node of claim 22.
Fadeev does not explicitly disclose tracking ongoing sessions and their corresponding application-specific tag or session-specific tags.
However, Dittmer discloses further comprising tracking ongoing sessions and their corresponding application-specific tag or session-specific tags. (Dittmer ¶ 006: a method for monitoring one or more components of one or more manufacturing application systems with respect to application-specific metrics is provided. In accordance with this embodiment, a processor may receive a first set of data associated with the one or more application-specific metrics corresponding to the one or more manufacturing application systems. The processor may also receive a second set of data from the one or more components associated with the one or more manufacturing application systems.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for tracking ongoing sessions and their corresponding application-specific tag or session-specific tags as taught by Dittmer. One of ordinary skill in the art would have been motivated to employ the teachings of Dittmer for the benefits achieved from the flexibility of a system that enables the monitoring of application-specific metrics. (Dittmer ¶ 006)
14. Claims 20, 40, are rejected under 35 U.S.C. 103 as being unpatentable over Fadeev and in view of Carr and further in view of Wang and Dittmer et al. (Patent No. EP3822726 A1).
Regarding Claims 20, 40, Fadeev-Carr-Chang discloses the method of claim 12 and a network node of claim 32.
Fadeev does not explicitly disclose tracking ongoing sessions and their corresponding application-specific or session-specific tags.
However, Dittmer discloses wherein further comprising tracking ongoing sessions and their corresponding application-specific or session-specific tags. (Dittmer ¶ 006: a method for monitoring (tracking) one or more components of one or more manufacturing application systems with respect to application-specific metrics is provided. In accordance with this embodiment, a processor may receive a first set of data associated with the one or more application-specific metrics corresponding to the one or more manufacturing application systems. The processor may also receive a second set of data from the one or more components associated with the one or more manufacturing application systems.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Fadeev for tracking ongoing sessions and their corresponding application-specific or session-specific tags as taught by Dittmer. One of ordinary skill in the art would have been motivated to employ the teachings of Dittmer for the benefits achieved from the flexibility of a system that enables the monitoring of application-specific metrics. (Dittmer ¶ 006)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kyung H Shin whose telephone number is (571)272-3920. The examiner can normally be reached M - F: 12pm - 8pm.
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, Joon H Hwang can be reached at 571-272-4036. 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.
/KYUNG H SHIN/ 7-9-2026Primary Examiner, Art Unit 2447
Prosecution Insights