Details
Claims 1-20 are pending.
Claims 1-20 are rejected.
Claim Rejections - 35 USC § 101
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.
Claims 1-14 rejected under 35 U.S.C. 101 because the claims are directed to a device/system comprising storage media which can include transitory media such as signals. Thus, the claims are not statuary.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6 and 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mariappan (Pub. No.: US 2020/0314015) in view of Liu et al (Pub. No.: US 2022/0400053 A1).
As per claim 1, Mariappan discloses a computing device (Mariappan, Fig 1 item 12A, Fig 2 item 200) comprising: - processing circuity (Mariappan, Fig 1, Fig 2 item 210) and storage media (Mariappan, Fig 1, Fig 2 item 244/246) configured with instructions, wherein the processing circuitry has access to the storage media and is configured to execute (Mariappan, paragraph 0090, wherein “Microprocessor 210 may include one or more processors each including an independent execution unit to perform instructions that conform to an instruction set architecture, the instructions stored to storage media. Execution units may be implemented as separate integrated circuits (ICs) or may be combined within one or more multi-core processors (or “many-core” processors) that are each implemented using a single IC (i.e., a chip multiprocessor)”):- a containerized application (Mariappan, Fig 1 item 22A “POD”, paragraph 0006, wherein “With containers' inherently lightweight nature, a single host can often support many more container instances than traditional virtual machines (VMs). Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, such as Kubernetes)”, paragraph 0055, wherein “For example, a virtual network endpoint may be a virtual machine, a set of one or more containers (e.g., a pod), or another other virtual execution element(s), such as a layer 3 endpoint for a virtual network. The term “virtual execution element” encompasses virtual machines, containers, and other virtualized computing resources that provide an at least partially independent execution environment for applications. The term “virtual execution element” may also encompass a pod of one or more containers.”);- a virtual router (Mariappan, Fig 1 item 21A, paragraph 0061, wherein “One or more of servers 12 may each include a virtual router 21 that executes one or more routing instances for corresponding virtual networks within data center 10 to provide virtual network interfaces and route packets among the virtual network endpoints”);- an interface for the containerized application, the interface enabling communications between the containerized application and the virtual router (Mariappan, Fig 1 item 26A “virtual network interface connecting POD 22A with vROUTER 21A”, paragraph 0082, wherein “For example, network module 17A may attach one end of a veth pair implementing virtual network interface 26A to virtual router 21A and may attach the other end of the same veth pair to pod 22A. Similarly, network module 17A may attach one end of a veth pair implementing virtual network interface 26N to virtual router 21A and may attach the other end of the same veth pair to pod 22A. In this way, a single instance of network module 17A configures multiple virtual network interfaces 26 for one or more virtual execution element that share at least one virtual network interface, in this case pod 22A”);- a container networking interface (CNI) plugin (Mariappan, Fig 1 item 17A, paragraph 0072, wherein “Network module 17A may represent a library, a plugin, a module, a runtime, or other executable code for server 12A. Network module 17A may conform, at least in part, to the Container Networking Interface (CNI) specification or the rkt Networking Proposal. Network module 17A may represent a Contrail or OpenContrail network plugin. Network module 17A may alternatively be referred to as a network plugin or CNI plugin or CNI instance”) configured to configure, based on data generated from a specification for the containerized application and from (Mariappan, paragraph 0072-0076, wherein “For purposes of the CNI specification, a container can be considered synonymous with a Linux network namespace. What unit this corresponds to depends on a particular container runtime implementation: for example, in implementations of the application container specification such as rkt, each pod runs in a unique network namespace. In Docker, however, network namespaces generally exist for each separate Docker container. For purposes of the CNI specification, a network refers to a group of entities that are uniquely addressable and that can communicate amongst each other”, “The CNI specification specifies a number of considerations for a conforming plugin (“CNI plugin”). These include the following: The container runtime must create a new network namespace for a container before invoking any CNI plugin. The container runtime must then determine which networks this container should belong to, and for each network, which plugins must be executed. The container runtime must add the container to each network by executing the corresponding plugins for each network sequentially”); and - a containerized routing protocol process configured to advertise the route in a routing protocol message in accordance with a routing protocol (Mariappan, paragraph 0117, wherein “The hosts of pods 202. advertise their respective next-hop routes to network controller 24, using a service IP address associated with service monitor 231 of computing device 200. Network controller 24 aggregates the next-hop routes received from the hosts of pods 202, to form the consolidated ECMP next-hop scheme for pods 202. Network controller 24 sends the ECMP next-hop information to all of pods 202. Using the relevant portions of the ECMP next-hop composite, each of pods 202 can provide the service IP to a selected VRF 222. In turn, each of pods 202 can advertise/expose a particular selected virtual network connection 212 or 213 (based on the particular VRF 222 to which the service IP was provided) to the load balancer member object created by orchestration agent 209”). Mariappan does not explicitly disclose a network attachment definition. However, a network attachment definition is well known in the art. For example, Liu discloses a network attachment definition used to configure a networking interface (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Mariappan with Liu to achieve the claimed limitations because this would have provided a convenient way of adding secondary interfaces to a pod (see Liu par. 0002-0003).
As per claim 2, claim 1 is incorporated and Mariappan further discloses wherein the route comprises a network address prefix for a network subnet reachable via the containerized application (Mariappan, paragraph 0047-0048, wherein “The forwarding tables of the underlay physical routers and switches may, for example, only contain the IP prefixes or MAC addresses of the physical servers 12. (Gateway routers or switches that connect a virtual network to a physical network are an exception and may contain tenant MAC or IP addresses.) Virtual routers 21 of servers 12 often contain per-tenant state. For example, any of virtual routers 21 may contain a separate forwarding table (a routing-instance) per virtual network. That forwarding table contains the IP prefixes (in the case of a layer 3 overlays) or the MAC addresses (in the case of layer 2 overlays) of the virtual machines or other virtual execution elements (e.g., pods of containers).”);
As per claim 3, claim 2 is incorporated and Mariappan further discloses wherein the specification for the containerized application specifies the network address prefix to an orchestration system, and wherein the CNI plugin is configured to receive the network address prefix from the orchestration system (Mariappan, Fig 1, paragraph 0047-0048, wherein “The forwarding tables of the underlay physical routers and switches may, for example, only contain the IP prefixes or MAC addresses of the physical servers 12. (Gateway routers or switches that connect a virtual network to a physical network are an exception and may contain tenant MAC or IP addresses.) Virtual routers 21 of servers 12 often contain per-tenant state. For example, any of virtual routers 21 may contain a separate forwarding table (a routing-instance) per virtual network. That forwarding table contains the IP prefixes (in the case of a layer 3 overlays) or the MAC addresses (in the case of layer 2 overlays) of the virtual machines or other virtual execution elements (e.g., pods of containers).”; paragraph 0084, wherein “A single network module 17A invoked by container platform 19A extends the functionality of a conventional CNI plugin by obtaining interface configuration data 25 and adding multiple different virtual network interfaces 26”);
As per claim 4, claim 3 is incorporated and Liu further discloses wherein the specification for the containerized application includes a reference to the network attachment definition, and wherein the network attachment definition defines a virtual routing and forwarding (VRF) instance or virtual switch to implement a virtual private network (VPN) (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”);
As per claim 5, claim 3 is incorporated and Liu further discloses wherein the specification for the containerized application includes a reference to the network attachment definition, wherein the network attachment definition defines a virtual routing and forwarding (VRF) instance in part using a route target, and wherein the containerized routing protocol process is configured to generate the routing protocol message to include the route target (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”);
As per claim 6, claim 1 is incorporated and Mariappan further discloses wherein the route comprises a virtual private network (VPN) route for implementing a VPN service model with the containerized routing protocol process and virtual router operating as a provider edge (PE) router and the containerized application operating as a customer edge (CE) device (Mariappan, paragraph 0044-0045, 0096, wherein “Virtual networks can be connected to, and extended across physical Multi-Protocol Label Switching (MPLS) Layer 3 Virtual Private Networks (L3VPNs) and Ethernet Virtual Private Networks (EVPNs) networks using a datacenter 10 edge router (not shown in FIG. 1), Virtual networks may also be used to implement Network Function Virtualization (NFV) and service chaining. Virtual networks can be implemented using a variety of mechanisms. For example, each virtual network could be implemented as a Virtual Local Area Network (VLAN), Virtual Private Networks (VPN), etc.”, “Virtual router 220 may replace and subsume the virtual routing/bridging functionality of the Linux bridge/OVS module that is commonly used for Kubernetes deployments of pods 202. Virtual router 220 may perform bridging (e.g., E-VPN) and routing (e.g., L3VPN, IP-VPNs) for virtual networks. Virtual router 220 may perform networking services such as applying security policies, NAT, multi cast, mirroring, and load balancing. Additional details for IP-VPNs are described in “BGP/MPLS IP Virtual Private Networks (VPNs),” Request for Comments 4364, Internet Engineering Task Force Network Working Group, February 2006, hereinafter “RFC 4364,” which is incorporated by reference herein in its entirety. Virtual router 220 may represent a PE router and virtual execution endpoints may be examples of CE devices described in RFC 4364”);
As per claim 8, claim 1 is incorporated and Mariappan in view of Liu further discloses wherein the containerized routing protocol process is configured to execute the routing protocol to establish a routing protocol peering session with a physical router that is external to the computing device (Mariappan, Fig 1, paragraph 0049, wherein “The control plane protocol between the control plane nodes of the network controller 24 or a physical gateway router (or switch) may be BGP (and may be Netconf for management). This is the same control plane protocol may also be used for MPLSL3VPNs and MPLS EVPNs. The protocol between the network controller 24 and the virtual routers 21 may be based on XMPP, for instance”, paragraph 0065, 0080, wherein “In general, network controller 24 controls the network configuration of the data center 10 fabric to, e.g., establish one or more virtual networks for packetized communications among virtual network endpoints. Network controller 24 provides a logically and in some cases physically centralized controller for facilitating operation of one or more virtual networks within data center 10”).
As per claim 9, Mariappan discloses an orchestration system (Mariappan, Fig 1 item 10/23) comprising: processing circuity and storage media configured with instructions, wherein the processing circuitry has access to the storage media and is configured to (Mariappan, Fig 1, paragraph 0012, wherein “n one example, a system includes one or more computing devices interconnected by a physical network, where each of the computing devices comprises processing circuitry coupled to a memory device. The system includes an orchestrator for a virtualized computing infrastructure, where the orchestrator is configured for execution by the computing devices”): - deploy a containerized application to a compute node (Mariappan, Fig 1 item 22A “POD”, paragraph 0006-0007, wherein “With containers' inherently lightweight nature, a single host can often support many more container instances than traditional virtual machines (VMs). Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, such as Kubernetes)”, paragraph 0055, wherein “For example, a virtual network endpoint may be a virtual machine, a set of one or more containers (e.g., a pod), or another other virtual execution element(s), such as a layer 3 endpoint for a virtual network. The term “virtual execution element” encompasses virtual machines, containers, and other virtualized computing resources that provide an at least partially independent execution environment for applications. The term “virtual execution element” may also encompass a pod of one or more containers … The container network should also be agnostic to work with the multiple types of orchestration platforms that are used to deploy containerized applications”);- deploy a containerized routing protocol process to the compute node (Mariappan, Fig 1 item 22A “POD”, paragraph 0006-0007, wherein “A computing infrastructure that manages deployment and infrastructure for application execution may involve two main roles: (1) orchestration—for automating deployment, scaling, and operations of applications across clusters of hosts and providing computing infrastructure, which may include container-centric computing infrastructure; and (2) network management—for creating virtual networks in the network infrastructure to enable packetized communication among applications running on virtual execution environments, such as containers or VMs, as well as among applications running on legacy (e.g., physical) environments”);- send, to the compute node, data generated from a specification for the containerized application and from (Mariappan, paragraph 0072-0076, wherein “For purposes of the CNI specification, a container can be considered synonymous with a Linux network namespace. What unit this corresponds to depends on a particular container runtime implementation: for example, in implementations of the application container specification such as rkt, each pod runs in a unique network namespace. In Docker, however, network namespaces generally exist for each separate Docker container. For purposes of the CNI specification, a network refers to a group of entities that are uniquely addressable and that can communicate amongst each other”, “The CNI specification specifies a number of considerations for a conforming plugin (“CNI plugin”). These include the following: The container runtime must create a new network namespace for a container before invoking any CNI plugin. The container runtime must then determine which networks this container should belong to, and for each network, which plugins must be executed. The container runtime must add the container to each network by executing the corresponding plugins for each network sequentially”), wherein the data causes: a container networking interface (CNI) plugin of the compute node to configure an interface for the containerized application with a route (Mariappan, paragraph 0072-0076, wherein “For purposes of the CNI specification, a container can be considered synonymous with a Linux network namespace. What unit this corresponds to depends on a particular container runtime implementation: for example, in implementations of the application container specification such as rkt, each pod runs in a unique network namespace. In Docker, however, network namespaces generally exist for each separate Docker container. For purposes of the CNI specification, a network refers to a group of entities that are uniquely addressable and that can communicate amongst each other”, “The CNI specification specifies a number of considerations for a conforming plugin (“CNI plugin”). These include the following: The container runtime must create a new network namespace for a container before invoking any CNI plugin. The container runtime must then determine which networks this container should belong to, and for each network, which plugins must be executed. The container runtime must add the container to each network by executing the corresponding plugins for each network sequentially”), and the containerized routing protocol process to advertise the route in a routing protocol message in accordance with a routing protocol (Mariappan, paragraph 0117, wherein “The hosts of pods 202. advertise their respective next-hop routes to network controller 24, using a service IP address associated with service monitor 231 of computing device 200. Network controller 24 aggregates the next-hop routes received from the hosts of pods 202, to form the consolidated ECMP next-hop scheme for pods 202. Network controller 24 sends the ECMP next-hop information to all of pods 202. Using the relevant portions of the ECMP next-hop composite, each of pods 202 can provide the service IP to a selected VRF 222. In turn, each of pods 202 can advertise/expose a particular selected virtual network connection 212 or 213 (based on the particular VRF 222 to which the service IP was provided) to the load balancer member object created by orchestration agent 209”). Mariappan does not explicitly disclose a network attachment definition. However, a network attachment definition is well known in the art. For example, Liu discloses a network attachment definition used to configure a networking interface (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Mariappan with Liu to achieve the claimed limitations because this would have provided a convenient way of adding secondary interfaces to a pod (see Liu par. 0002-0003).
As per claim 10, claim 9 is incorporated and Mariappan further discloses wherein the route comprises a network address prefix for a network subnet reachable via the containerized application (Mariappan, paragraph 0047-0048, wherein “The forwarding tables of the underlay physical routers and switches may, for example, only contain the IP prefixes or MAC addresses of the physical servers 12. (Gateway routers or switches that connect a virtual network to a physical network are an exception and may contain tenant MAC or IP addresses.) Virtual routers 21 of servers 12 often contain per-tenant state. For example, any of virtual routers 21 may contain a separate forwarding table (a routing-instance) per virtual network. That forwarding table contains the IP prefixes (in the case of a layer 3 overlays) or the MAC addresses (in the case of layer 2 overlays) of the virtual machines or other virtual execution elements (e.g., pods of containers).”);
As per claim 11, claim 10 is incorporated and Mariappan further discloses wherein the specification for the containerized application specifies the network address prefix, and wherein the data includes the network address prefix (Mariappan, Fig 1, paragraph 0047-0048, wherein “The forwarding tables of the underlay physical routers and switches may, for example, only contain the IP prefixes or MAC addresses of the physical servers 12. (Gateway routers or switches that connect a virtual network to a physical network are an exception and may contain tenant MAC or IP addresses.) Virtual routers 21 of servers 12 often contain per-tenant state. For example, any of virtual routers 21 may contain a separate forwarding table (a routing-instance) per virtual network. That forwarding table contains the IP prefixes (in the case of a layer 3 overlays) or the MAC addresses (in the case of layer 2 overlays) of the virtual machines or other virtual execution elements (e.g., pods of containers).”; paragraph 0084, wherein “A single network module 17A invoked by container platform 19A extends the functionality of a conventional CNI plugin by obtaining interface configuration data 25 and adding multiple different virtual network interfaces 26”);
As per claim 12, claim 11 is incorporated and Liu further discloses wherein the specification for the containerized application includes a reference to the network attachment definition, and wherein the network attachment definition defines a virtual routing and forwarding (VRF) instance or virtual switch to implement a virtual private network (VPN) (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”);
As per claim 13, claim 11 is incorporated and Liu further discloses wherein the specification for the containerized application includes a reference to the network attachment definition, wherein the network attachment definition defines a virtual routing and forwarding (VRF) instance in part using a route target, and wherein the data includes the route target (Liu, paragraph 0052, wherein “The process 600 determines (at 610) that the pod includes an identifier of a network attachment definition (ND). An ND designates a network segment to attach to a secondary network interface of the pod. In some embodiments, designating a network segment may include identifying, in the ND, a pre-created network segment of a logical network and/or providing attributes in the ND that allow an NCP to command a network manager or controller to dynamically create a network segment in the logical network. When the pod includes an identifier of an ND, the NCP uses that identifier (e.g., in operation 620) to determine which ND designates the network segment to be attached to a secondary interface of the pod”);
As per claim 14, claim 9 is incorporated and Mariappan further discloses wherein the route comprises a virtual private network (VPN) route for implementing a VPN service model with the containerized routing protocol process and a virtual router of the compute node operating as a provider edge (PE) router and the containerized application operating as a customer edge (CE) device (Mariappan, paragraph 0044-0045, 0096, wherein “Virtual networks can be connected to, and extended across physical Multi-Protocol Label Switching (MPLS) Layer 3 Virtual Private Networks (L3VPNs) and Ethernet Virtual Private Networks (EVPNs) networks using a datacenter 10 edge router (not shown in FIG. 1), Virtual networks may also be used to implement Network Function Virtualization (NFV) and service chaining. Virtual networks can be implemented using a variety of mechanisms. For example, each virtual network could be implemented as a Virtual Local Area Network (VLAN), Virtual Private Networks (VPN), etc.”, “Virtual router 220 may replace and subsume the virtual routing/bridging functionality of the Linux bridge/OVS module that is commonly used for Kubernetes deployments of pods 202. Virtual router 220 may perform bridging (e.g., E-VPN) and routing (e.g., L3VPN, IP-VPNs) for virtual networks. Virtual router 220 may perform networking services such as applying security policies, NAT, multi cast, mirroring, and load balancing. Additional details for IP-VPNs are described in “BGP/MPLS IP Virtual Private Networks (VPNs),” Request for Comments 4364, Internet Engineering Task Force Network Working Group, February 2006, hereinafter “RFC 4364,” which is incorporated by reference herein in its entirety. Virtual router 220 may represent a PE router and virtual execution endpoints may be examples of CE devices described in RFC 4364”);
Claims 15-20 are rejected under the same rationale as claims 1-6.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mariappan (Pub. No.: US 2020/0314015) in view of Liu et al (Pub. No.: US 2022/0400053 A1) and Duong et al (Pub. No.: US 2017/0180154 A1).
As per claim 7, claim 1 is incorporated and Mariappan in view of Liu further discloses wherein the containerized routing protocol process is configured to execute the routing protocol to establish a routing protocol peering session with (Mariappan, Fig 1, paragraph 0049, wherein “The control plane protocol between the control plane nodes of the network controller 24 or a physical gateway router (or switch) may be BGP (and may be Netconf for management). This is the same control plane protocol may also be used for MPLSL3VPNs and MPLS EVPNs. The protocol between the network controller 24 and the virtual routers 21 may be based on XMPP, for instance”, paragraph 0065, 0080, wherein “In general, network controller 24 controls the network configuration of the data center 10 fabric to, e.g., establish one or more virtual networks for packetized communications among virtual network endpoints. Network controller 24 provides a logically and in some cases physically centralized controller for facilitating operation of one or more virtual networks within data center 10”). Mariappan and Liu do not explicitly disclose that the network controller is a virtualized provider edge (PE) router. However, a virtualized provider edge (PE) router is well known in the art. For example, Duong discloses a virtualized provider edge (PE) router (Duong, Fig 1, paragraph 0053, wherein “In another embodiment, the PE router is a virtual entity that resides within a physical entity. When the PE router is a virtual entity, referred to as VPE router, the tunnel is called the head-end tunnel. The head-end tunnel can anchor the customer VLANs under a logical interface (mode1) or operates as native IP packets under the logical interface (mode2). In mode 2, the first PE or the physical PE first strips the VLAN to expose the IP packets that are carried by the VLAN. For example, the source PE node may strip the VLAN tag from the customer interface before mapping the customer payload into a tunnel for traversing the service provider's network. When the payload reaches the remote VPE router (the destination), the payload is native IP packets which are anchored by the logical interface on the VPE and are ready to be processed and forwarded to the ultimate destination.”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Mariappan and Liu with Duong to achieve the claimed limitations because this would have provided a lower hardware costs, faster service rollout, and easier network scaling.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Ario Etienne can be reached on ario.etienne@uspto.gov. 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.
/HAMZA N ALGIBHAH/ Primary Examiner, Art Unit 2457
Prosecution Insights