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
Claims 1-20 are pending in the application.
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, 3, 6, 8, 10, 13, 15, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub. US 20220222100 to Srivastava et al. (hereafter Srivastava) in view of US 20200099610 to Heron et al. (hereafter Heron).
Srivastava and Heron were cited in the previous office action.
As claim 1, Srivastava teaches the invention substantially as claimed including a computer implemented method [Abstract: “An example method of secure attestation of a workload deployed in a virtualized computing system is described. The virtualized computing system includes a host cluster and a virtualization management server, the host cluster having hosts and a virtualization layer executing on hardware platforms of the hosts.”] for applying hypervisor-based containers to a cluster of a container orchestration system [[0002]: “For deploying such applications, a container orchestration platform known as Kubernetes® has gained in popularity among application developers. Kubernetes provides a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. It offers flexibility in application development and offers several useful tools for scaling.”], the method comprising:
issuing a request to create a sandbox environment ([0050]: “The request for starting a pod VM 130 (Request to create a sandbox environment. The pod VM is considered a sandbox environment) is forwarded to virtualization management server 116 (e.g., to DRS by scheduler extender 306), which will choose an appropriate host to create and start pod VM 130.“) to store a pod containing one or more containers ([0024]: “A pod VM 130 is a virtual machine that includes a kernel and container engine that supports execution of containers (A pod VM is a VM that runs a pod. Supporting execution of containers means it contains one or more containers.), as well as an agent (referred to as a pod VM agent) that cooperates with a controller of an orchestration control plane 115 executing in hypervisor 150 (referred to as a pod VM controller).“; [0048]: “A pod is an object supported by API server 302 that is a group of one or more containers, with network and storage, and a specification on how to execute… For each pod, scheduler 304 also converts the pod specification to a pod VM specification, and scheduler extender 306 asks virtualization management server 116 to reserve a pod VM on the selected host 120.”).
However, Srivastava et al. does not explicitly teach creating a network tunnel between a worker node of said cluster of said container orchestration system and said sandbox environment without packet encapsulation; and routing packets from said worker node to said sandbox environment via said network tunnel using source routing. But Heron et al. teaches creating a network tunnel between a worker node of a cluster of a container orchestration system and a sandbox environment ([0015]: “An alternative approach can be to tunnel traffic (This means a network tunnel is used and must be created) between an ingress host to an egress host and to retain the container service address as the inner destination IP address in the tunnel. Some embodiments of the present disclosure may utilize Segment Routing over IPv6 data plane (SRv6) for the tunneling mechanism.“; [0037]: “The container orchestration platform 200 can comprise one or more clusters. A cluster is a collection of compute, storage, and networking resources that the container orchestration platform 200 can use to run the various workloads of a network. Each cluster can comprise one or more hosts (physical servers and/or virtual machines). Here, master 202 and worker nodes 220A and 220B (collectively, “220”) can represent a single cluster. “; [0043]: “Each worker node 220 can include an agent 222 (e.g., kubelet) and a network interface 224 (e.g., kube proxy, Open vSwitch (OVS)/Contiv netplugin, etc.).” [0047]: “An overlay approach can use a virtual network that may be decoupled from the underlying physical network using tunneling technology (e.g., Virtual Extensible LAN (VXLAN), Generic Routing Encapsulation (GRE), Segment Routing (SR), etc.). Pods in the virtual network can find each other via tunneling”) without encapsulation ([0056]: “In some embodiments, direct or inline SRH insertion may be used instead of encapsulation (Instead of encapsulation means without encapsulation. The packet being wrapped with an outer tunnel header via direct or inline SRH insertion allows the tunnelling to be done without encapsulation). In direct or inline SRH insertion, the SRH 320 can be inserted directly immediately after the IPv6 header 350. This can result in less overhead than encapsulation but may be more susceptible to disruptions in the event of network errors.“); and
Routing packets from said worker node to said sandbox environment via said network tunnel using source routing ([0052]: “Segment Routing is a source routing architecture (Routing packets is done with source routing) in which a source chooses a path or route (also sometimes referred to as an SR Policy) and encodes it in a packet header as an ordered list of instructions referred to as segments.”; [0062]: “FIG. 4A shows an initial state of IPv6 packet 404A generated by a container pod 426A (e.g., the container pods 226 of FIG. 2) within a node 410A (Worker node) (e.g., the compute resources 110 of FIG. 1 or the worker nodes 220 of FIG. 2) that is intended for transmission to a container service labeled SVC:svc1.”; [0101]: “In other embodiments, the SR ingress device can use direct or inline insertion. For example, the SR ingress device can update the DA of the original packet header (e.g., IPv6 header) to be the first segment or SID of the segment list. Then, the SR ingress device can create the SRH and insert the SRH between the original packet header and original packet payload.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Srivastava et al. with the teachings of Heron et al. to create a network tunnel between a worker node of said cluster of said container orchestration system and said sandbox environment without encapsulation by using the tunneling mechanism taught in Heron et al. to tunnel traffic between the pod VM and nodes of a Kubernetes cluster taught in Srivastava et al. ([0027]: “By way of example, a Kubernetes container orchestrator is described herein. In supervisor cluster 101, hosts 120 become nodes of a Kubernetes cluster and pod VMs 130 executing on hosts 120 implement Kubernetes pods. Orchestration control plane 115 includes supervisor Kubernetes master 104 and agents 152 executing in virtualization layer (e.g., hypervisors 150).”). A person of ordinary skill in the art before the effective filing date of the claimed invention would be motivated to create a network tunnel between a worker node of said cluster of said container orchestration system and said sandbox environment to enable the use of segment routing specifically to provide control over forwarding paths using simple network instructions, support fast reroute, and to lower latency as taught by Heron et al. ([0016]: “Segment routing can provide control over forwarding paths using simple network instructions. In addition, segment routing does not require additional protocols and may even remove unnecessary protocols in some deployments to further simplify a network.”; [0017]: “Segment routing does not require path signaling such that only SR ingress devices may need to maintain per-flow state “; [0018]: “Segment routing can also be used to steer traffic along any arbitrary path in a network. This can allow network operators to enforce low-latency and/or disjoint paths, regardless of normal forwarding paths. SR can achieve this flexibility without any additional signaling or midpoint fabric-state.”). One would be motivated to specifically do this without encapsulation to reduce overhead as taught by Heron et al. above ([0056]: “In some embodiments, direct or inline SRH insertion may be used instead of encapsulation. In direct or inline SRH insertion, the SRH 320 can be inserted directly immediately after the IPv6 header 350. This can result in less overhead than encapsulation but may be more susceptible to disruptions in the event of network errors.“). Moreover, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Srivastava et al. to route packets from said worker node to said sandbox environment via said network tunnel using source routing to increase network simplification as taught by Heron et al. ([0015]: “This can provide the various benefits of segment routing, such as increased network simplification, programmability and scalability, and flexibility”).
As to claim 3, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 1 further comprising:
Heron et al. teaches forwarding packets from a pod network in said worker node to said network tunnel ([0016]: “Segment routing can provide control over forwarding paths using simple network instructions.”; [0025]: “EPGs are groupings of applications, or application components, and tiers for implementing forwarding and policy logic. EPGs can allow for separation of network policy, security, and forwarding from addressing by using logical application boundaries.“; [0043]: “Each of the worker nodes 220 can correspond to a single host, which can be a physical or virtual machine. Each worker node 220 can include an agent 222 (e.g., kubelet) and a network interface 224 (e.g., kube proxy, Open vSwitch (OVS)/Contiv netplugin, etc.).”; [0062]: “FIG. 4A shows an initial state of IPv6 packet 404A generated by a container pod 426A (e.g., the container pods 226 of FIG. 2) within a node 410A (e.g., the compute resources 110 of FIG. 1 or the worker nodes 220 of FIG. 2) that is intended for transmission to a container service labeled SVC:svc1.“; [0074]: “In the example of FIG. 4B, the vSwitch 424A can operate as the SR ingress device (The vSwitch is inside the worker nodes. This is considered an entry point of the network tunnel). Upon receiving the IPv6 packet 404A (as shown in FIG. 4A), the vSwitch 424A can search an SID table“; [0055]: “A Destination Address 354 of the outer IPv6 header 350 can be set to the first segment or SID 342, and the packet may be forwarded to the corresponding segment endpoint following the shortest path (The destination address is used to forward the packet from a worker node to the network tunnel). The segment endpoint can process the packet by updating the Destination Address 354 to the next segment and decrementing the Segments Left 328.”;);
Wherein said pod network enables pods to communicate with one another ([0047]: “The container orchestration platform 200 can enable intra-node communication or pod-to-pod communication within the same node via local filesystem… Pod-to-pod communication can utilize Border Gateway Protocol (BGP) peering to not leave the host, and NAT for outgoing traffic. An overlay approach can use a virtual network that may be decoupled from the underlying physical network using tunneling technology (e.g., Virtual Extensible LAN (VXLAN), Generic Routing Encapsulation (GRE), Segment Routing (SR), etc.). Pods in the virtual network can find each other via tunneling. In addition, L2 networks can be isolated from one another, and L3 routing can be utilized for inter-node pod-to-pod communication.“; [0028]: “The nodes typically communicate over the network (Communicates over the pod network) by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol can refer to a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by an intermediate network node, such as a router, to extend the effective size of each network. The endpoints can include any communication device or component, such as a computer, server, blade, hypervisor, virtual machine, container, process (e.g., running on a virtual machine), switch, router, gateway, host, device, external network, etc.“).
As to claim 6, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 1,
Heron et al. teaches wherein said source routing is accomplished via a routing table ([0072]: “For example, a segment endpoint executing the End.S function can search for whether there is an entry in a local SID table (also sometimes referred to as a Forwarding Information Base (FIB)) (Routing table)”; [0076]: “FIG. 4D shows a local SID table 430 (Routing table) for the vSwitch 424B“).
As to claim 8, it is a media/product type claim with similar limitations as claim 1 above.
Moreover, Srivastava et al. teaches the additional limitations of one or more computer readable storage mediums having program code embodied therewith ([0072]: “One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system. Computer readable media may be based on any existing or subsequently developed technology that embodies computer programs in a manner that enables a computer to read the programs. Examples of computer readable media are hard drives, NAS systems, read-only memory (ROM), RAM, compact disks (CDs), digital versatile disks (DVDs), magnetic tapes, and other optical and non-optical data storage devices. A computer readable medium can also be distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.”). Therefore, it is rejected under the same rationale.
As to claim 10, it is a media/product type claim with similar limitations as claim 3 above. Therefore, it is rejected under the same rationale.
As to claim 13, it is a media/product type claim with similar limitations as claim 6 above. Therefore, it is rejected under the same rationale.
As to claim 15, it is a system type claim with similar limitations as claim 1 above. Moreover, Srivastava et al. teaches the additional limitations of a memory ([0017]: “As shown, a hardware platform 122 of each host 120 includes conventional components of a computing device, such as one or more central processing units (CPUs) 160, system memory (e.g., random access memory (RAM) 162”) and a processor connected to said memory ([0072]: “A computer readable medium can also be distributed over a network-coupled computer system so that the computer readable code is stored and executed (A processor executes the code. Since it uses the code stored in memory it is connected to said memory.) in a distributed fashion.”). Therefore, it is rejected under the same rationale.
As to claim 17, it is a system type claim with similar limitations as claim 3 above. Therefore, it is rejected under the same rationale.
As to claim 20, it is a system type claim with similar limitations as claim 6 above. Therefore, it is rejected under the same rationale.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. in view of Heron et al., as applied to claims 1, 8, and 15, in further view of Klink et al. (US 20120063458 A1).
As to claim 2, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 1,
However, Srivastava et al. modified by Heron et al. do not explicitly teach, but Klink et al. teaches wherein said sandbox environment shares a same Internet Protocol address as the other end of said network tunnel in said worker node ([0030]: “In the preferred example described above, all the virtual machines (Sandbox environment) are configured to use the same IP address on the network interface… The host (Worker node) is configured to intercept packets sent to the shared IP address assigned to virtual machines and to forward into the destination machine based on the packet destination port number. All outgoing packets are typically transmitted to the external network unmodified. If the host (Worker node) is also using the shared IP address (Using the shared IP address corresponds to the sandbox environment sharing the same IP address as said worker node), a unique port range is assigned to the host. In this case the host is allocating permanent and ephemeral ports from this range”. This covers the case when worker nodes are bare machines; [0031]: “FIG. 5 illustrates is a block diagram for a computer system with multiple virtual machines (Sandbox environment and worker node) that share the same IP address (For the case where a worker node is a virtual machine instance, this corresponds to a sandbox environment sharing the same IP address as the worker node.)on an external network address space. The computer system of FIG. 5 is similar to the system shown in FIG. 2 but shows an example of how the system can be scaled to multiple physical host computers. In FIG. 5, the host computer 510A has a virtual network manager 123 similar to the host computer 100 described in FIG. 2. In contrast to the system in FIG. 2, the virtual network manager 123 in FIG. 5 communicates with virtual machines that reside on one or more other hosts… the virtual network manager handles communication to the virtual machines on different physical host computers over a physical network 512 rather than a virtual network between the host computers 510A, 510B, 510C”. This covers the case where worker nodes are also virtual machine instances.).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Srivastava et al. modified by Heron et al. such that the sandbox environment shares a same Internet Protocol address as the other end of said network tunnel in said worker node in order to improve system availability and/or provide effective failover for virtual machines by allowing migration without the need to change IP addresses as taught by Klink et al. ([0031]: “The connection to the virtual machines on the other hosts computers can use any suitable physical network connection. This architecture allows a virtual machine to migrate to a different physical host without changing the IP address”).
As to claim 9, it is a media/product type claim with similar limitations as claim 2 above. Therefore, it is rejected under the same rationale.
As to claim 16, it is a system type claim with similar limitations as claim 2 above. Therefore, it is rejected under the same rationale.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. in view of Heron et al., as applied to claims 3, 10, and 17, in further view of McDowall et al. (US 20220385631 A1).
As to claim 4, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 3.
However, Heron et al. modified by Srivastava et al. do not explicitly teach, but McDowall et al. teaches wherein said packets are forwarded from said pod network in said worker node to said network using a redirect filter ([0043]: “As further described below, the communication with the CN-Series and/or VM-Series firewalls can be over a network tunnel (e.g., using a Geneve tunnel or another tunnelling protocol…)“; [0051]: “Each Kubernetes Node includes a management plane (CN-MGMT), such as shown at 108, and a data plane (CN-NGFW), such as shown at 110”; [0052]: “Pod traffic (Packets from pod network) is redirected to an available CN-NGFW instance for inspection and enforcement”; [0060]: “At stage 302, a client (Pod) makes a request. At stage 304, the request (Pod traffic) is intercepted by… Traffic Control (TC) extended Berkeley Packet Filter (eBPF) module (Redirect filter) in the client network namespace (e.g., Protected client application Pod Network NameSpace as shown in FIG. 3A), and the packet is… rerouted/sent to the firewall (As firewalls can be over network tunnels, sending packets to a firewall is also considered forwarding to a network tunnel).”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify invention of Srivastava et al. modified by Heron et al. where packets from said pod network, e.g. pod traffic, are forwarded to said network using a redirect filter to provide protection and security as taught by McDowall et al. ([0003]-[0004]: “A firewall generally protects networks from unauthorized access while permitting authorized communication to pass through the firewall…Firewalls typically deny or permit network transmission based on a set of rules… firewalls can filter inbound traffic… a fire wall can also filter outbound traffic… firewalls can also be capable of performing basic routing functions”).
As to claim 11, it is a media/product type claim with similar limitations as claim 4 above. Therefore, it is rejected under the same rationale.
As to claim 18, it is a system type claim with similar limitations as claim 4 above. Therefore, it is rejected under the same rationale.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. in view of Heron et al., as applied to claims 1, 8, and 15, in further view of Diehl et al. (US 20050050179 A1).
As to claim 5, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 1.
However, Srivastava et al. modified by Heron et al. do not explicitly teach, but Diehl et al. teaches responding to address resolution protocol requests from a pod network in said worker node using a proxy address resolution protocol ([0020]: “A new support feature is added to server computer 100 to allow Virtual IP addresses to be configured as directly routable. This directly routable configuration allows the iSeries server 100 to answer ARP requests, that is, to Proxy ARP, for Virtual IP addresses. Proxy ARP for Virtual IP interfaces provides customers with an increased fault tolerance, and higher system availability.“; [0021]: “Conventional Proxy ARP supported on the other interface types, such as point-to-point protocol (PPP) interface, twinaxial data link control protocol (TDLC) interface, OptiConnect (OPC) serial optical bus interface and Virtual Ethernet interface (Pod network) answers ARP requests (responding to address resolution protocol requests), but has an important difference between this use of new enhanced Proxy ARP (using a proxy address resolution protocol) this embodiment.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Srivastava et al. modified by Heron et al. where the virtual ethernet of the pod network in said worker node uses a proxy address resolution protocol as taught by Diehl et al. to increase fault tolerance and improve system availability as taught by Diehl et al. ([0020]: “Proxy ARP (proxy address resolution protocol) for Virtual IP interfaces provides customers with an increased fault tolerance, and higher system availability”).
As to claim 12, it is a media/product type claim with similar limitations as claim 5 above. Therefore, it is rejected under the same rationale.
As to claim 19, it is a media/product type claim with similar limitations as claim 5 above. Therefore, it is rejected under the same rationale.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. in view of Heron et al., as applied to claims 1 and 8, in further view of Lim et al. (Secure Namespaced Kernel Audit for Containers. (2021) 518-532. 10.1145/3472883.3486976.).
As to claim 7, Srivastava et al. modified by Heron et al. teaches the method as recited in claim 1,
Heron et al. teaches wherein said one or more containers of said pod share an Internet Protocol address ([0015]: “Current implementations of container networks assign a network address (e.g., ClusterIP) to each container service, and then install Network Address Translation (NAT) rules at each container host to map from the container service address to the network address of a specific container or container pod in the container host”. Mapping the IP address of each container host to the IP address of a specific container service address of a container pod will lead to one or more containers of said pod sharing the same IP.).
However, Srivastava et al. modified by Heron et al. do not explicitly teach, but Lim et al. teaches wherein said one or more containers of said pod share an inter-process communication and a hostname (2.3. Namespaces in Linux, para 2: “an application in a Docker container runs within its own set of namespaces. Kubernetes ‘pods’ contain one or more containers so that they share namespaces (and therefore system resources)”. Sharing namespaces means the containers will share an internet protocol address, inter-process communication (IPC), and a hostname; Fig. 3 depicts the structure of a namespace.).
PNG
media_image1.png
404
637
media_image1.png
Greyscale
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Srivastava et al. modified by Heron et al. with the teachings of Lim et al. such that the containers of a pod share the same namespace to enable all the containers within a pod to share system resources as taught by Lim et al. (2.3. Namespaces in Linus, para 2: “an application in a Docker container runs within its own set of namespaces. Kubernetes ‘pods’ contain one or more containers so that they share namespaces (and therefore system resources)”).
As to claim 14, it is a media/product type claim with similar limitations as claim 7 above. Therefore, it is rejected under the same rationale.
Response to Arguments
Applicant's arguments filed 12/18/25 have been fully considered but they are not persuasive.
In the remarks, Applicant argued in substance that:
There is no language in the cited passages that teaches or suggests creating a network tunnel between a worker node of the cluster of the container orchestration system and the sandbox environment without packet encapsulation. Instead, Heron teaches tunneling traffic between an ingress host to an egress host.
Srivastava and Heron taken singly or in combination do not teach or suggest “routing packets from said worker node to said sandbox environment via said network tunnel using source routing” even though Heron teaches segment routing is a source routing architecture in which source chooses a path or route.
Srivastava and Heron taken singly or in combination do not teach or suggest “issuing a request to create sandbox environment to store a pod containing one or more containers” because Srivastava simply teaches starting a pod VM, which contain containers.
Examiner respectfully traversed Applicant's remarks:
As to point (a), the examiner respectfully disagrees and submits that Heron disclosed worker nodes that correspond to a host as well as a VM, a sandboxed environment, such that the node maintain running pods of containers and provide a runtime environment for the container orchestration platform [paragraph 43], such that the virtual switches or ingress/egress hosts are implemented within respective nodes [Figs. 4-7 and corresponding text] in which tunneling traffic was disclosed which clearly satisfy the limitations of worker node of a cluster of container orchestration system as well a sandbox environment in communication via a network tunnel. In addition, Heron disclosed direct or inline SRH insertion may be used instead of encapsulation in the communication, hence, without encapsulation. The packet being wrapped with an outer tunnel header via direct or inline SRH insertion allows the tunnelling to be done without encapsulation [paragraph 56] which in combination with Srivastava satisfy the limitations as claimed. Therefore applicant’s argument is not persuasive.
As to point (b), the examiner respectfully disagrees and submits that as pointed out by the examiner in point (a) above, Heron disclosed worker nodes that correspond to a host as well as a VM, a sandboxed environment, such that the node maintain running pods of containers and provide a runtime environment for the container orchestration platform [paragraph 43], such that the virtual switches or ingress/egress hosts are implemented within respective nodes [Figs. 4-7 and corresponding text] in which tunneling traffic, inclusive of segment routing ingress device (i.e. used of source routing architecture) from a first container/pod in a first host in receiving and transmitting packet destine for container service of another host/VM/node [Fig. 8 and corresponding text] clearly satisfy the limitations as argued.
As to point (c), the examiner respectfully disagrees and submits that Srivastava clearly disclosed the request for starting a pod VM, a sandbox environment, includes the choosing of “an appropriate host to create and start pod VM” [paragraph 50, lines 3-7]. Furthermore, as shown in Figure 2 of Srivastava, containers are running in each pod VM [paragraph 42, lines 1-3] which stores the containers (i.e. pod of containers) either persistently or temporarily, therefore applicant’s argument is not persuasive.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QING YUAN WU whose telephone number is (571)272-3776. The examiner can normally be reached M-F 9AM-6PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 571-272-3759. 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.
/QING YUAN WU/Primary Examiner, Art Unit 2199
Prosecution Insights