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 .
Response to Arguments
Applicant’s arguments, see pages 8-11, filed 02/06/2026, with respect to the rejection(s) of claims 1-20 under Inamdar et al. in view of Cahana et al. have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Olmsted-Thompson (US 20180007162 A1)
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. US 12,088,560 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because limitation features of claims 1, 10 and 19 of the current application are generic to corresponding limitations of claims 1, 10 and 19 of the U.S. Patent No. US 12,088,560 B2 respectively.
Current US Application No.:18/789,781
U.S. Pat.No:.12,088,560 B2
1. A computer-implemented method, comprising: receiving, through a socket of a loopback interface, a plurality of data packets, the plurality of data packets being part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identifying a particular network session of a remote application container through analyzing the plurality of data packets received through the socket; and monitoring security associated with the particular network session of the service mesh.
1. A computer-implemented method, comprising: opening a socket to a loopback interface of an application container, wherein the application container participates in a service mesh and communicates with a plurality of remote application containers in the service mesh via a service mesh proxy associated with the application container; receiving, through the socket of the loopback interface, a plurality of data packets, the data packets being part of one or more network sessions of the service mesh, at least one of the network sessions is encrypted at the service mesh proxy; identifying a particular network session of the application container with a particular remote application container through analyzing the plurality of data packets received through the socket; and monitoring security associated with the particular network session of the service mesh.
10. A system comprising: one or more processors comprising instructions, when executed by the one or more processors, further cause the one or more processors to: receive through a socket of a loopback interface, a plurality of data packets, the plurality of data packets are part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identify a particular network session of a remote application container through analyze the plurality of data packets received through the socket; and monitor security associated with the particular network session of the service mesh.
10. A system comprising: an application container, wherein the application container participates in a service mesh; a service mesh proxy connected to the application container, wherein the service mesh proxy allows the application container to communicate with a plurality of remote application containers in the service mesh via the service mesh proxy; and a computing device comprising one or more processors and memory, the memory configured to store computer code comprising instructions, the instructions, when executed by the one or more processors, cause the one or more processors to: open a socket to a loopback interface of the application container; receive, through the socket of the loopback interface, a plurality of data packets, the data packets being part of one or more network sessions of the service mesh, at least one of the network sessions is encrypted at the service mesh proxy; identify a particular network session of the application container with a particular remote application container through analyzing the plurality of data packets received through the socket; and monitor security associated with the particular network session of the service mesh.
19. A non-transitory computer-readable medium configured to store computer code comprising instructions, the instructions, when executed by one or more processors, cause the one or more processors to perform: receiving, through a socket of a loopback interface, a plurality of data packets, the plurality of data packets being part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identifying a particular network session of a remote application container through analyzing the plurality of data packets received through the socket; and monitoring security associated with the particular network session of the service mesh.
19. A non-transitory computer-readable medium configured to store computer code comprising instructions, the instructions, when executed by one or more processors, cause the one or more processors to: open a socket to a loopback interface of an application container, wherein the application container participates in a service mesh and communicates with a plurality of remote application containers in the service mesh via a service mesh proxy associated with the application container; receive, through the socket of the loopback interface, a plurality of data packets, the data packets being part of one or more network sessions of the service mesh, at least one of the network sessions is encrypted at the service mesh proxy; identify a particular network session of the application container with a particular remote application container through analyzing the plurality of data packets received through the socket; and monitor security associated with the particular network session of the service mesh.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No:. 11,075,884 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because limitation features of claims 1, 10 and 19 of the current application are generic to corresponding limitations of claims 1, 8 and 15 of the U.S. Patent No:.11,075,884 B2 respectively.
Current US Application No.:18/789,781
U.S. Pat No:. 11,075,884 B2
1. A computer-implemented method, comprising: receiving, through a socket of a loopback interface, a plurality of data packets, the plurality of data packets being part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identifying a particular network session of a remote application container through analyzing the plurality of data packets received through the socket; and monitoring security associated with the particular network session of the service mesh.
1. A method in a container system, comprising: monitoring network communications at a loopback interface of a pod in the container system, the pod including a service mesh proxy connected to an application container via the loopback interface, wherein the application container includes computer-readable instructions, is initiated via a container service, and is isolated using operating system-level virtualization, wherein the service mesh proxy enables features of a service mesh infrastructure of the container system, and wherein the application container communicates with the service mesh proxy using the loopback interface; extracting network address and port information from packet data in the network communications at the loopback interface; and determining one or more connection contexts of the network communications at the loopback interface, each connection context used to identify a network session of the application container with a remote application container.
10. A system comprising: one or more processors comprising instructions, when executed by the one or more processors, further cause the one or more processors to: receive through a socket of a loopback interface, a plurality of data packets, the plurality of data packets are part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identify a particular network session of a remote application container through analyze the plurality of data packets received through the socket; and monitor security associated with the particular network session of the service mesh.
8. A container system comprising: a pod, comprising: an application container, wherein the application container includes computer-readable instructions, is initiated via a container service, and is isolated using operating system-level virtualization, wherein the a service mesh proxy connected to the application container via a loopback interface and enabling features of a service mesh infrastructure of the container system, and wherein the application container communicates with the service mesh proxy using the loopback interface; a security monitor configured to perform operations comprising: monitoring network communications at the loopback interface of the pod; extracting network address and port information from packet data in the network communications at the loopback interface; and determining one or more connection contexts of the network communications at the loopback interface, each connection context used to identify a network session of the application container with a remote application container.
19. A non-transitory computer-readable medium configured to store computer code comprising instructions, the instructions, when executed by one or more processors, cause the one or more processors to perform: receiving, through a socket of a loopback interface, a plurality of data packets, the plurality of data packets being part of one or more network sessions of a service mesh, at least one of the one or more network sessions is encrypted at a service mesh proxy; identifying a particular network session of a remote application container through analyzing the plurality of data packets received through the socket; and monitoring security associated with the particular network session of the service mesh.
15. A non-transitory computer storage readable medium configured to store instructions, the instructions that when executed by a processor, cause the processor to perform operations comprising: monitoring network communications at a loopback interface of a pod in the container system, the pod including a service mesh proxy connected to an application container via the loopback interface, wherein the application container includes computer-readable instructions, is initiated via a container service, and is isolated using operating system-level virtualization, wherein the service mesh proxy enables features of a service mesh infrastructure of the container system, and wherein the application container communicates with the service mesh proxy using the loopback interface; extracting network address and port information from packet data in the network communications at the loopback interface; and determining one or more connection contexts of the network communications at the loopback interface, each connection context used to identify a network session of the application container with a remote application container.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Inamdar et al. (US 20200112487 A1—hereinafter—" Inamdar”) in view of Cahana et al. (US 20190356693 A1—hereinafter—" Cahana”) in furtherview of Olmsted-Thompson (US 20180007162 A1)
As per claim 1: Inamdar a computer-implemented method, comprising:
receiving a plurality of data packets, the plurality of data packets being part of one or more network sessions of a service mesh ([0046] A pod is the unit of work in the container orchestration platform 200. Pods can help to manage groups of closely related containers that may depend on each other and that may need to cooperate on the same host to accomplish their tasks. Each pod 226 can include one or more containers 228. Pods can be scheduled together and run on the same machine. The containers 228 in each pod 226 can have the same IP address and port space; they can communicate using localhost or standard inter-process communication. In addition, the containers 228 in each pod 226 can have access to shared local storage on the node 220 hosting the pod. The shared storage can be mounted on each container 228. [0047] The proxies 224 can be responsible for container networking, including low-level network housekeeping on each node, reflection of local services, TCP and UDP forwarding, finding cluster IPs through environmental variables or Domain Name System (DNS). In some embodiments, the container orchestration platform 200 may employ a networking model that relates how the nodes 220, pods 226, and containers 228 interact with one another, such as ensuring that containers can communicate with other containers without NAT, nodes can communicate with containers (and vice-versa) without NAT, and the IP address that a container sees itself as is the same IP address that others see it as. This networking model can assign IP addresses at the pod level such that containers within a pod share an IP address and port space. This networking model can also enable containers within a pod to reach other containers ports on localhost (Examiner further notes that the lookback interface is a virtual network interface used for internal communication where the localhost is a corresponding hostname that resolves the loopback interface). [0048] The container orchestration platform 200 can enable intra-node communication or pod-to-pod communication within the same node via local filesystem, any IPC mechanism, or localhost. The container orchestration platform 200 can support various approaches for inter-node communication or pod-to-pod communication across nodes, including L2 (switching), L3 (routing), and overlay networking. The L2 approach can involve attaching an L2 network to a node's physical network interface controller (NIC) and exposing the pod directly to the underlying physical network without port mapping. Bridge mode can be used to enable pods to interconnect internally so that traffic does not leave a host unless necessary. The L3 approach may not use overlays in the data plane, and pod-to-pod communication can happen over IP addresses leveraging routing decisions made by node hosts and external network routers. Pod-to-pod communication can utilize Border Gateway Protocol (BGP) peering to not leave the host, and NAT for outgoing traffic) at least one of the one or more network sessions is encrypted at a service mesh proxy. [0056] The Authentication component 332 can manage certificate signing, certificate issuance, and revocation/rotation. In some embodiments, the Authentication component 332 can issue x509 certificates to services and microservices, allowing for mutual Transport Layer Security (mTLS) between these services and microservices and transparent encryption of their traffic. In some embodiments, the Authentication component 332 may use service identity built into the underlying container orchestration platform to generate certificates);
identifying a particular network session of an application container through analyzing the plurality of data packets ([0034] The L4-L7 services 114 can provide networking services for the network 100, such as network address translation (NAT), firewalling, Internet Protocol Security (IPSec), session border control (SBC), deep packet inspection (DPI), traffic monitoring, load balancing, etc. [0062] The core proxy service 404 can comprise a cluster of container pods for performing additional processing of network traffic. Each pod of the core proxy service 404 can comprise a sidecar proxy and one or more application containers, including one or more SIP application containers. After receiving the inbound communications from the edge proxy service 402, the core proxy service 404 can determine whether to route the communications further downstream (e.g., to the SBC service 406) or to reject the communications, such as due to locally defined policy, routing rules, and the like. If a decision is made to route the communications further downstream, the core proxy service 404 can select an instance of the SBC service 406 to further process the communications); and
monitoring security associated with the particular network session of the service mesh ([0063] The SBC service 406 can manage the signaling and media streams involved in setting up, conducting, and tearing down telephone calls or other interactive media communications (e.g., sessions). This can include advanced session management and control features, such as bandwidth management, call admission control, quality of service (QoS), The SBC service 406 can also provide security features, such as access control, Network Address Translation (NAT) or firewall traversal, flow-specific encryption, Denial of Service (DoS) protection. The SBC service 406 is a back-to-back user agent that can make individual connections to participating devices. This can enable the SBC service 406 to provide signaling protocol conversions (e.g., between SIP and H.323), transport protocol conversions (e.g., between Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)), call signaling normalization for interoperability between vendors (e.g., H.323 to H.323, SIP to SIP, etc.), protocol mediation to enable advanced features in multi-vendor environment, and security interworking between platforms that may use different forms of encryption (e.g., interworking between Secure Real-Time Transport Protocol (SRTP) and RTP).
Inamdar does not explicitly disclose the application container is a remote application container. Cahana, in analogous art however, discloses the application container is a remote application container ([0011] Microservice-based applications may be composed of multiple services, referred to herein as microservices, interacting using a network protocol. For example, the network protocol may be Hyper Text Transfer Protocol (HTTP), Hyper Text Transfer Protocol Secure (HTTPS), or based on a remote procedure call (RPC) system. In some examples, a microservice system may employ a service mesh. A service mesh may include components that communicate indirectly using intermediate proxies. These proxies may be used to simplify communication handling and may also improve communication resiliency and security. As long as communication between the services of a microservice-based application uses the proxies, the proxies can complete any prerequisites without impacting the microservice code directly. An example prerequisite may be a mutual transport layer security (mTLS) handshake. Mutual TLS, or mTLS, as used herein refers to a technique for performing mutual authentication between clients and servers. For example, a server may begin authentication of itself with a client by sending the client a certificate. [0024] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. [0025] Platform as a Service (PaaS). [0026] Infrastructure as a Service (IaaS). [0043] FIG. 3 is block diagram of an example computing device that can selectively provide mTLS using alternative server names. The computing device 300 may be for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computing device 300 may be a cloud computing node. Computing device 300 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computing device 300 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the application container disclosed by Inamdar to include a remote application container. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide techniques for selectively providing mTLS using alternative server names in response to detecting a legacy indicator and associate the alternative server name with an address of a pod and further configure a proxy associated with the pod to selectively provide mutual transport layer security (mTLS) based on the alternative server name as suggested by Cahana ([0004]).
Inamdar in view of Cahana does not explicitly disclose the received packet is through a socket of a loopback interface. Olmsted-Thompson, in analogous art however, discloses the received packet is through a socket of a loopback interface ([0081-0085] A proxy instance listens on ports that are allocated for a log application's data (log) communication in order to receive incoming network connections destined for the log application. The proxy instance forwards the incoming connections to the log application through a loopback interface on which the log application listens. The port numbers of an external interface of a device that are dedicated to a log application and on which the proxy instance listens, in some embodiments, are divided to (1) log ports, through which the different generated events are received and (2) admin ports, through which admin queries and other API calls are received. The log application, instead of the dedicated ports, listens on a loopback interface (also referred to as a local host), through which the incoming events are received from the proxy instance. Through the loopback interface, the proxy instance mirrors incoming connections to the log application when the log application is active and online. [0094-0095] Forwarding new API connections to other nodes allows new connections (e.g., HTTP connections) continue to be made throughout the upgrade process of a log instance, without any change in buffering the event data. Once the upgrade is completed, some embodiments close the connections to the remote instance of the log application and create new connections to the local and upgraded instance of the log application. In order to redirect the connections to remote nodes, a local proxy instance should be able to communicate to other remote instances of the log application in a manner other than through a loopback interface (through which a proxy instance communicates with a standalone log application). This is because the loopback interface can be used only for internal communications of a single machine and no data can be passed to a remote node through deployments of a loopback interface. In a clustered implementation of a log application, some embodiments employ a virtual interface of an overlay network between each pair of local proxy instance and local log instance (of the distributed log application). In some embodiments, instead of binding to a loopback interface, a local log instance is bound to its corresponding virtual interface. The local proxy instance of some such embodiments forwards the incoming log and API data to the local log instance through this virtual interface when the log instance in active and online. When the local log instance is offline though, the local proxy instance (1) buffers the log data in the same manner the log data is buffered for a standalone log application, and (2) redirects the incoming API data (instead of rejecting this data) to a remote log instance running on a remote node of the cluster using the same virtual interface). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations the received packet disclosed by Inamdar in view of Cahana is through a socket of a loopback interface. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a method that instantiates a proxy instance that is an updated version of a proxy instance to seamlessly transfers the incoming network data from the first proxy instance to the second proxy instance such that the second proxy instance continues on performing a set of responsibilities of the first proxy instance without any interruption as suggested by Olmsted-Thompson ([0003]-[0006]).
As per claim 2: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, wherein the remote application container is isolated using operating system-level virtualization (Inamdar [0002] Containers are an example of an approach for implementing operating-system-level virtualization. They are self-contained execution environments that can have their own isolated CPU, memory, input/output (I/O), and network resources, and may share a kernel of a host operating system. Containers can be isolated from one other and from their hosts (physical and/or virtual servers). For example, they can have their own file systems. They may have no visibility into each other's processes. Their computing resources (e.g., processing, storage, networking, etc.) can be bounded. Containers can be easier to build and configure than virtual machines, and because containers can be decoupled from their underlying infrastructure and from host file systems, they can be highly portable across various clouds and operating system distributions. Enterprises can rapidly develop software for distributed applications, services, and microservices in private networks, public clouds, or both (e.g., hybrid clouds or multi-clouds) by running them in containers in development and test environments).
As per claim 3: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, wherein the particular network session of the remote application container is identified based on network address identified from packet data in network communications at the loopback interface (Cahana [0035] FIG. 1, the first application instance 112 may send a server name APP.sub.B corresponding to the application instance 120 to the service registry 110 as shown by an arrow 134. The first application instance 112 may then receive an IP address IP.sub.B in response. The first sidecar proxy 114 may send a request for the IP address of the server with the name APP.sub.B of the second application instance 120 as indicated by an arrow 138. The first sidecar proxy 114 may then receive the IP address in response as shown by an arrow 140. The sidecar proxy 114 may then communicate with the second sidecar proxy 116 using the IP address IPB. For example, the IP address may correspond to the endpoint 124 of the second sidecar 116 associated with the second application instance 120. The sidecar proxy 114 may send a server name indication (SNI) message of APP.sub.B to indicate to the second sidecar 116 that a normal communication using mTLS is to occur between the first sidecar proxy 114 and the second sidecar proxy 116).
As per claim 4: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, wherein the particular network session of the remote application container is identified based on port information identified from packet data in network communications at the loopback interface (Inamdar [0047] The proxies 224 can be responsible for container networking, including low-level network housekeeping on each node, reflection of local services, TCP and UDP forwarding, finding cluster IPs through environmental variables or Domain Name System (DNS). In some embodiments, the container orchestration platform 200 may employ a networking model that relates how the nodes 220, pods 226, and containers 228 interact with one another, such as ensuring that containers can communicate with other containers without NAT, nodes can communicate with containers (and vice-versa) without NAT, and the IP address that a container sees itself as is the same IP address that others see it as. This networking model can assign IP addresses at the pod level such that containers within a pod share an IP address and port space. This networking model can also enable containers within a pod to reach other containers' ports on localhost).
As per claim 5: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, further comprising: extracting a source network address and port information from incoming packet data; extracting a destination network address and port information from outgoing packet data (Inamdar [0089] The feature extractor 606 can receive preprocessed network traffic data and extract its features or discriminative characteristics. A feature is generally a quality of a unit of network traffic data that can define the unit in part and that may be used to compare the similarities or differences between units. Some examples of features for network traffic data include packet header or flow fields, such as a source address, source port, destination address, destination port, protocol type, or class of service, among others; content-based features (e.g., features within the payload, such as specific tokens or words in the payload); time-based features (e.g., round-trip time (RTT), inter-arrival time (IAT) for request/response pairs or packets, number of connections to the same host during a time interval, etc.); and connection- or session-based features (e.g., number of packets, number of bytes, number of flows, bandwidth usage, latency, packet loss, jitter, etc.). Table 2 sets forth different levels of granularity of network traffic data that the traffic analysis engine 600 can capture and various examples of features that the feature extractor 606 may acquire from the network traffic data); and
comparing the source network address and port number of the incoming packet data with the destination network address and port information of outgoing packet data (Cahana TABLE-US-00002 TABLE 2 Bidirectional Flow; Source address, source port, destination address, destination port, flow Request/Response Pair; duration, flow volume in bytes and packets, packet statistics Connection (minimum, mean, maximum, standard deviation, etc.), packet inter- arrival times between packets or request/response pairs (minimum, mean, maximum, standard deviation, etc.), connection duration Session Session duration, Number of request/response pairs or connections);
identifying packets of the incoming packet data with the source network address and port information matching the destination network address and port information of packets of the outgoing packet data as a set of ingress connection packets (Cahana [0060] The edge proxy service 402 can comprise a cluster of container pods (e.g., the container pods 226 of FIG. 2 or the container pods 326 of FIG. 3) for handling ingress traffic received from and egress traffic sent to L3 network (e.g., the L3 network 106 of FIG. 1). Each container pod of the edge proxy service 402 can comprise a sidecar proxy (e.g., the sidecar proxies 325 of FIG. 3) and one or more application containers (e.g., the containers 228 of FIG. 2 or the containers 328 of FIG. 3), including one or more Session Initiation Protocol (SIP) application containers. [0086] Data type conversion can involve mapping raw data from one data type to another. For example, raw data may include numeric data and categorical data (e.g., the protocol of a packet can take values such as TCP, ICMP, Telnet, UDP, etc.). Some machine learning techniques may work with either numeric data or categorical data but not both. Thus, in some embodiments, the preprocessor 604 can convert raw data to a form usable with a particular machine learning technique (e.g., converting numeric data to categorical data or vice versa); and
determining that the set of ingress connection packets belongs to the particular network session (Cahana [0060] The edge proxy service 402 can comprise a cluster of container pods (e.g., the container pods 226 of FIG. 2 or the container pods 326 of FIG. 3) for handling ingress traffic received from and egress traffic sent to L3 network (e.g., the L3 network 106 of FIG. 1). Each container pod of the edge proxy service 402 can comprise a sidecar proxy (e.g., the sidecar proxies 325 of FIG. 3) and one or more application containers (e.g., the containers 228 of FIG. 2 or the containers 328 of FIG. 3), including one or more Session Initiation Protocol (SIP) application containers).
As per claim 6: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 5, further comprising:
determining that particular network session is an ingress connection by determining that the destination network address and port information indicate a network address of an ethernet interface (Inamdar [0084] The preprocessor 604 can perform initial processing tasks on the data captured by the data collector 602 for input to the feature extractor 606. The preprocessing tasks can include assembly, filtration, data type conversion, normalization, discretization, and/or missing value completion. Assembly can involve constructing units of data at a specified level of granularity from raw traffic data, such as building packets into segments, segments into application layer protocol messages (e.g., unidirectional flows, requests, or responses), messages into connections (e.g., bidirectional flows or request/response pairs), connections into sessions, and so forth. For example, the traffic analysis engine 420 of FIG. 4 may analyze traffic data at the level of granularity of an SIP call or session, and assembly can involve constructing the SIP calls or sessions from raw traffic data. Other embodiments may utilize units of network traffic data of coarser granularity (e.g., real time traffic, TCP/IP traffic, VoIP traffic, etc.) or units of network traffic data of finer granularity (e.g., connections, messages, segments, packets, etc).
As per claim 7: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 6, wherein the remote application container functions as a server (Cahana [0024] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. [0025] Platform as a Service (PaaS). [0026] Infrastructure as a Service (IaaS). [0043] FIG. 3 is block diagram of an example computing device that can selectively provide mTLS using alternative server names).
As per claim 8: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, further comprising:
determining whether the remote application container is coupled to the service mesh proxy by:
determining whether network addresses at an ethernet interface matche network addresses at the loopback interface (Cahana [0011] Microservice-based applications may be composed of multiple services, referred to herein as microservices, interacting using a network protocol. For example, the network protocol may be Hyper Text Transfer Protocol (HTTP), Hyper Text Transfer Protocol Secure (HTTPS), or based on a remote procedure call (RPC) system. In some examples, a microservice system may employ a service mesh. A service mesh may include components that communicate indirectly using intermediate proxies. These proxies may be used to simplify communication handling and may also improve communication resiliency and security. As long as communication between the services of a microservice-based application uses the proxies, the proxies can complete any prerequisites without impacting the microservice code directly. An example prerequisite may be a mutual transport layer security (mTLS) handshake. Mutual TLS, or mTLS, as used herein refers to a technique for performing mutual authentication between clients and servers. For example, a server may begin authentication of itself with a client by sending the client a certificate); and
in response to determining that the network addresses at the ethernet interface do not match the network addresses at the loopback interface, determining that the remote application container is coupled to the service mesh proxy (Cahana [0025] Platform as a Service (PaaS). [0026] Infrastructure as a Service (IaaS). [0043] FIG. 3 is block diagram of an example computing device that can selectively provide mTLS using alternative server names. The computing device 300 may be for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computing device 300 may be a cloud computing node. Computing device 300 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computing device 300 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices).
As per claim 9: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the computer-implemented method of claim 1, further comprising:
transmitting a report including information about the particular network session, the report further including a reconstruction of payload data of packet data in the particular network session (Inamdar [0083] The data collector 602 can capture network traffic data, such as frame or packet traces, session logs, and performance metrics from different layers of the Open Systems Interconnection (OSI) model, the TCP/IP model, or other network model. The data collector 602 may record the network traffic data at various levels of granularity, such as per packet, flow, session, or other level of granularity. In some embodiments, the data collector 602 may collect the network traffic data in different phases. For example, the machine learning modeler 608 may implement supervised learning such that the data collector 602 may capture network traffic data during an offline or training stage during which the parameters of the machine learning modeler 608 are determined and an online or evaluation stage during which the machine learning modeler 608 is applied to new traffic data instances).
As per claims 10-17: Claims 10-17 are directed to a system comprising: one or more processors comprising instructions, when executed by the one or more processors, further cause the one or more processors to perform substantially similar corresponding limitations of claims 1-8 respectively and therefore claims 10-17 are rejected with the same rationale given above to reject corresponding features of claims 1-8 respectively.
As per claim 18: Inamdar in view of Cahana in further view of Olmsted-Thompson discloses the system of claim 10, wherein the remote application container and the service mesh proxy are stored in a memory of a computing device (Cahana [0038] FIG. 2 is a process flow diagram of an example method that can selectively provide mTLS using alternative server names. The method 200 can be implemented with any suitable computing device, such as the computing device 300 of FIG. 3 and is described with reference to the systems 100 of FIG. 1. For example, the methods described below can be implemented by the processor 302 of the computing device 300 of FIG. 3. [0043-0047] FIG. 3 is block diagram of an example computing device that can selectively provide mTLS using alternative server names. The computing device 300 may be for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computing device 300 may be a cloud computing node. Computing device 300 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computing device 300 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices).
As per claims 19-20: Claims 19-20 are directed to a non-transitory computer-readable medium configured to store computer code comprising instructions, the instructions, when executed by one or more processors, cause the one or more processors to perform substantially similar corresponding limitations of claims 1 and 3 respectively and therefore claims 19-20 are rejected with the same rationale given above to reject corresponding features of claims 1and 3 respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Johnson et al. (US 20160087933 A1) discuses A localhost (as described, for example, in RFC 2606) is the hostname given to the address of the loopback interface (also virtual loopback interface, loopback network interface, loopback device, network loopback), referring to “this computer”. For example, directing a browser on a computer running an HTTP server to a loopback address (e.g., http://localhost, http://127.0.0.1, etc.) may display the website of the computer (assuming a web server is running on the computer and is properly configured). Using a loopback address allows connection to any locally hosted network service (e.g., computer game server, or other inter-process communications, etc.). The localhost hostname corresponds to an IPv4 address in the 127.0.0.0/8 net block i.e., 127.0.0.1 (for IPv4, see RFC 3330) or ::1 (for IPv6, see RFC 3513). The most common IP address for the loopback interface is 127.0.0.1 for IPv4, but any address in the range 127.0.0.0 to 127.255.255.255 maps to the loopback device. The routing table of an operating system (OS) may contain an entry so that traffic (e.g., packet, network traffic, IP datagram, etc.) with destination IP address set to a loopback address (the loopback destination address) is routed internally to the loopback interface. In the TCP/IP stack of an OS the loopback interface is typically contained in software (and not connected to any network hardware).
THOMAS et al (US 20110208838 A1) discusses a session manager (communication protocol client) that can be, for example, a client such as a Win32 client (in some cases, ActiveX based) that can accept some or all traffic from the LSP service and/or can forward the traffic to the intermediate server using the communication protocol. The session manager listens on, for example, loopback addresses (127.0.0.1, 127.0.0.2. etc) for one, some, or all destination hosts secured via the LSP service. A portmap request arrives from the LSP before it initiates the connection. The secure application manager proxy can find an available local address and port, such as a loopback address and port, to bind to and returns both back to the LSP while recording the association. The LSP then can initiate a connection to this loopback address and port. When the secure application manager proxy receives a connection indication it can initiate a connection to the intermediate server. When this connection is successfully made, the incoming connection from the loopback address can be accepted. Once the connections are made, a state machine based on, for example, the asynchronous 10 characteristics of the Winsock API and/or communication protocol API can handle the port mapped data. The secure application manager can use a range of loopback addresses for port mapping, starting at 127.1.0.1 and ending at 127.1.255.254. There are many ways to choose a loopback address. In one embodiment, the secure application manager can first attempt to bind the starting address 127.1.0.1 and destination port. If this address is already in use, it can attempt to bind to the next address, 127.1.0.2. This can continue until it finds an available address to bind to. In the event that all 65 k addresses are in use on a given port, it can start over at 127.1.0.1 attempting to bind to alternate port numbers. Port mapping the connections through loopback addresses is done by some embodiments for proxying the traffic. Network data makes an extra round trip from the from user space to the kernel and back. Certain Windows services bind to loopback addresses and ports in the kernel for which Winsock has no knowledge of. The secure application manager proxy can think it successfully bound to a loopback address and port yet never receive any connections or data because a kernel service intercepted the request. One example of this is Microsoft remote desktop protocol takes over and controls 127.0.0.1:3389 without notifying Winsock.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/ Primary Examiner, Art Unit 2408
Prosecution Insights