DETAILED ACTION
Claims 1-20 are pending.
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 .
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
As per claim 1, in step 1 of the 101 analysis, the examiner has determined that the claim is directed to a method. Therefore, the claim is directed to one of the four statutory categories of invention.
In step 2A prong 1 of the 101 analysis, the examiner has determined that the claim recites a judicial exception. Specifically, the limitations “determining, based on the filter rules, that a first advertised route of the advertised routes is an allowed route” and “determining, based on the filter rules, that a second advertised route of the advertised routes is a disallowed route” recite mental processes. Determining by comparing using a criteria/rule constitutes a mental process of observation, evaluation, and judgement because a human with the aid of pen and paper can analyze data entries, identify relationships in data, compared whether a route/path is allowed or not.
In step 2A prong 2 of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not integrate the judicial exceptions into a practical application for the following rationale:
The limitations “an SDDC”, “a control plane”, and “logical routers”, apply judicial exceptions on a generic computer. "Alappat 's rationale that an otherwise ineligible algorithm or software could be made patent-eligible by merely adding a generic computer to the claim was superseded by the Supreme Court's Bilski and Alice Corp. decisions" so therefore applying judicial exceptions on a management entity which are generic computers does not integrate the judicial exceptions into a practical application (MPEP 2106.05(b)).
The limitation “receiving, at a control plane of the SDDC, first configurations for first logical routers comprising advertised routes and a second configuration for a second logical router comprising a global in-filter, the global in-filter including filter rules, applicable to all southbound logical routers, which determine a set of allowable routes for the second logical router, the first logical routers connected to a southbound interface of the second logical router” represent insignificant, extra-solution activities. The term "extra-solution activity" can be understood as "activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim" (MPEP 2106.05(g)). The examiner has determined that the limitation “receiving, first configurations…and a second configuration” is directed to mere data gathering activities which is a category of insignificant extra-solution activities (MPEP 2106.05(g)).
The limitation “distributing, from the control plane, routing information to a host of the SDDC that implements at least a portion of the second logical router, the routing information including a route for the first advertised route and excluding any route for the second advertised route.” is directed to mere data transmission activities which is a category of insignificant extra-solution activities (MPEP 2106.05(g)).
In step 2B of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not recite significantly more than the abstract ideas identified above for the following rationale:
The limitations “an SDDC”, “a control plane”, and “logical routers” apply judicial exceptions on a generic computer and therefore do not provide significantly more.
The limitation “receiving, at a control plane of the SDDC, first configurations for first logical routers comprising advertised routes and a second configuration for a second logical router comprising a global in-filter, the global in-filter including filter rules, applicable to all southbound logical routers, which determine a set of allowable routes for the second logical router, the first logical routers connected to a southbound interface of the second logical router” and “distributing, from the control plane, routing information to a host of the SDDC that implements at least a portion of the second logical router, the routing information including a route for the first advertised route and excluding any route for the second advertised route.” represent insignificant, extra-solution activities and are well-understood, routine, or conventional because they are directed to "receiving or transmitting data" (MPEP 2106.05(d)). These are additional elements that the courts have recognized as well understood, routine, or conventional (MPEP 2106.05(d)). The citation of court cases in the MPEP meets the Berkheimer evidentiary burden since citation of a court case in the MPEP is one of the 4 types of evidentiary support that can be used to prove that the additional elements are well-understood, routine, or conventional (see 125 USPQ2d 1649 Berkheimer v. HP, Inc.). Thus, the limitations do not amount to significantly more than the abstract idea.
Considering the additional elements individually and in combination and the claim as a whole, the additional elements do not provide significantly more than the abstract idea. The claim is not patent eligible.
As per claim 11, it is a media/product claim of claim 1, so it is rejected for the same reasons as claim 1. Additionally, claim 11 recites “a non-transitory computer readable medium comprising instructions to be executed in a computing device” which recite generic computing components that do not integrate the judicial exceptions into a practical application and do not provide significantly more and recite intended use limitations that do not have patentable weight.
As per claim 20, it is a system type claim of claim 1, so it is rejected for the same reasons as claim 1. Additionally, claim 20 recites “a hardware platform” which corresponds to generic computing components that do not integrate the judicial exceptions into a practical application and do not provide significantly more.
As per claim 2 (and similarly for claims 12 and 16), it recites limitations that further define the generic computing structure. This does not provide significantly more than the abstract idea.
As per claim 3 (and similarly for claims 13 and 17), it recites limitations which further describes the rules used to determine an whether to allow or disallow routes. This does not provide significantly more than the abstract idea.
As per claims 4-5, it recites limitations which further describes the obtained data that is then compared against the rules to determine whether they are allowed/disallowed and does not provide significantly more than the abstract idea.
As per claims 6-7 (and similarly for claims 14 and 18), it recites limitations directed to the filter rules used to perform the abstract idea as shown on claim 1. As such, these claims do not provide significantly more than the abstract idea.
As per claim 8 (and similarly for claim 19), it recites limitations which further describes the generic computing environment including a routing table and does not provide significantly more than the abstract idea.
As per claim 9 (and similarly for claim 20), they recite limitations which further describes generic computing components such as a host, hypervisors and MFEs, these do not provide significantly more than the abstract idea or integrate it into practical application.
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-8 and 10-19 are rejected under 35 U.S.C. 103 as being unpatentable over Qian et al. (US 2022/0321469 A1) in view of Wu (US 8,046,490 B1) in further view of Jiang et al. (US 2022/0029858 A1).
Regarding claim 1, Qian teaches a method of implementing a logical network in a [data center] software-defined data center (SDDC), the method comprising:
receiving, at a control plane of the [data center] SDDC, first configurations for first logical routers comprising advertised routes ([0002]; [0050]; [0056] Connectivity among a number of different types of isolated networks 140 may be provided using a VR instance 102 in the depicted embodiment, e.g., in response to programmatic requests submitted via interfaces 170 to the PPS control plane 190 from a PPS client 195. For example, isolated network 140A may comprise a set of resources at a data center or premise external to the provider network's own data centers [0058] In at least some embodiments, a PPS client 195 may provide at least a portion of the routing/forwarding metadata 108 of the VTH instance which is used for generating the actions that are eventually used to forward network packets among the isolated networks 140, e.g., using the programmatic interfaces 170 of the PPS control plane 190. [0153] The dynamic routing information (e.g., BGP advertisements) transferred among the VRs according to the client's configuration settings may be used to transfer network packets from one isolated network to another in the depicted embodiment; [0057]; [0198] advertised routes) and a second configuration for a second logical router comprising a global in-filter, the global in-filter including filter rules, applicable to all southbound logical routers, which determine a set of allowable routes for the second logical router, the first logical routers connected to a southbound interface of the second logical router ([0037] Clients can specify various parameters and settings (such as the specific protocol versions to be used, rules for filtering routing information to be advertised to or from a virtual router, etc.) to control the manner in which routing information is transferred between the virtual routers.; [0047]; [0057]; [0198] a client 2910 may provide rules for controlling the kinds of routing information that is to be transmitted among the VRs and/or between the VRs and the client premise dynamic routing information sources. Such rules may be indicated via DynamicRoutingConfigSettings messages 2925, which may comprise information similar to that contained in RoutingInfoTransferConfigSettings messages 2225 of FIG. 22. Any of a number of different configuration settings may be indicated, including the specific versions or variants of protocols to be used (e.g., any of various flavors of BGP such as eBGP, iBGP, MP-BGP etc.), settings for filtering outbound advertised routes, filtering inbound advertisements, relative priorities assigned to various BGP attributes to select a next hop to a destination, CIDR blocks to be used for the IP addresses of protocol processing engines, autonomous system identifiers to be assigned to the protocol processing engines, and so on.; Fig. 5, wherein FN 520B-C act as interfaces on the virtual router used to enable traffic flow between endpoints, see at least [0079]).
Qian teaches in [0160] “a client may wish to ensure that while traffic is allowed to flow between specified pairs of isolated networks attached to VRs 2110A and 2110B, network flows are prevented or prohibited between other pairs of isolated networks attached to the same VRs. For example, a client may wish to enable dynamic routing of packets (e.g., using exchanges of advertisements of the kind discussed above) between isolated networks (INs) 2140A and 2140B, and also between isolated networks 2140C and 2140D. However, the client may also wish to prevent traffic from flowing (a) between IN 2140A and IN 2140D, (b) between IN 2140A and IN 2140C, (c) between IN 2140B and IN 2140C and (d) between IN 2140B and 2140C.”
Qian does not explicitly teach determining, based on the filter rules, that a first advertised route of the advertised routes is an allowed route;
determining, based on the filter rules, that a second advertised route of the advertised routes is a disallowed route; and
distributing, from the control plane, routing information to a host of the SDDC that implements at least a portion of the second logical router, the routing information including a route for the first advertised route and excluding any route for the second advertised route.
In a similar field of endeavor, Wu teaches in at least Col. 1, lines 19-26: “routers communicate with one another to exchange routing information. For example, a router may "advertise" a particular route to peer routers. The peer routers may receive the advertised route, and may adopt the advertised route to replace existing route information if, for example, the advertised route is shorter or the advertising router is a trusted source. In turn, these peer routers may further advertise the particular route to other routers.” And Col. 5, lines 18-58. Further, Wu teaches determining, based on the filter rules, that a first advertised route of the advertised routes is an allowed route (Col. 6, line 53 through Col. 7, line 9: If the route check controller 120 determines that the advertised route is invalid, that route will be rejected. This may be performed automatically, for example, using a route filtering rule.; Col. 7, lines 10-41: If the route check controller 120 determines that the advertised route is valid, the receiving router 144 will replace the route currently in use and will transmit packets through the network using the advertised route.);
determining, based on the filter rules, that a second advertised route of the advertised routes is a disallowed route (Col. 6, line 53 through Col. 7, line 9: If the route check controller 120 determines that the advertised route is invalid, that route will be rejected. This may be performed automatically, for example, using a route filtering rule. This may be performed automatically, for example, using a route filtering rule. A rejected route will not be considered as a route for transmitting packets, and also will not be advertised as a potential route to other routers… Accordingly, the router 144 will reject this route.); and
distributing, from the control plane, routing information to a host of the [data center] SDDC that implements at least a portion of the second logical router, the routing information including a route for the first advertised route and excluding any route for the second advertised route (Col. 7, lines 10-41: It should also be understood that with regard to advertising the route to further routers, such route may be filtered using a predetermined export policy specified for that router. In other words, the router 144 may determine which routes are appropriate for advertisement to its peers 141-143 and 145-148. The routes that survive the export policy filtering are added to an Adj-RIB-Out database for that router for sharing with peer routers.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Wu of utilizing routing rules to determine whether a route is valid/invalid with the teachings of Qian to ensure all routes are up to date. The modification would have been motivated by the desire of avoiding adopting invalid routes. If an invalid route is adopted, it may result in failure to establish communication between a source and a destination. Worse, the invalid route may be advertised to peer routers and adopted by the peer routers. For networks such as the Internet, where numerous routers are involved and thousands of people may attempt to access a website at one time, such failure to establish communication can be widespread. See at least Wu’s Background.
Qian teaches in at least [0002] “The advent of virtualization technologies for commodity hardware has provided benefits with respect to managing large-scale computing resources for many customers with diverse needs, allowing various computing resources to be efficiently and securely shared by multiple customers. For example, virtualization technologies may allow a single physical virtualization host to be shared among multiple users by providing each user with one or more “guest” virtual machines hosted by the single virtualization host. Each such virtual machine may represent a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators of a given hardware computing resource, while also providing application isolation and security among the various virtual machines. Instantiating several different virtual machines on the same host may also help increase the overall hardware utilization levels at a data center, leading to higher returns on investment.” But neither Qian nor Wu explicitly teach the data center being an SDDC.
However, Jiang teaches an SDDC ([0002] Virtualization allows the abstraction and pooling of hardware resources to support virtual machines in a software-defined data center (SDDC). For example, through server virtualization, virtualized computing instances such as virtual machines (VMs) running different operating systems may be supported by the same physical machine (e.g., referred to as a “host”). Each VM is generally provisioned with virtual resources to run a guest operating system and applications. The virtual resources may include central processing unit (CPU) resources, memory resources, storage resources, network resources, etc. In practice, it is desirable for hosts to support logical network packet handling to facilitate communication among VMs deployed on various logical networks.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jiang of virtualization and SDDCs with the virtualization as defined in at least [0002] of Qian and Wu to yield predictable results of communication and packet handling in virtualized computing environments. See at least [0064].
Regarding claim 2, Qian teaches wherein the first logical routers comprise gateways between tenant address spaces and the second logical router, the second logical router being a provider gateway outside of the tenant address spaces (Fig. 1, shows a system with multiple Isolated Networks 140 and a virtual router VR 102 provided outside of the tenant networks; [0046] According to at least some embodiments, a given protocol stack instance may be configured for use in single-tenant mode (on behalf of no more than one client, or for no more than one virtual router) or in multi-tenant mode, e.g., for auxiliary tasks performed on behalf of several clients or several virtual routers. The tenancy mode may be selected based at least in part on programmatic input from clients on whose behalf the virtual routers are configured in some embodiments.; [0047] create a plurality of virtual routers using resources of a provider network, including a first virtual router and a second virtual router. The transfer of routing information between the first virtual router and the second virtual router in accordance with a group of dynamic routing protocol control settings indicated by a client of the provider network via one or more programmatic interfaces may be enabled.).
Regarding claim 3, Wu teaches wherein the global in-filter further includes a list having a set of network addresses, and wherein the filter rules comprise a first rule disallowing any route for any network address in the set of network addresses and a second rule allowing any route from a selected logical router of the first logical routers, the second rule having precedence over the first rule (Col. 6, line 59 through Col. 7, line 41: If the route check controller 120 determines that the advertised route is invalid, that route will be rejected. This may be performed automatically, for example, using a route filtering rule. A rejected route will not be considered as a route for transmitting packets, and also will not be advertised as a potential route to other routers. For example, and with regard to FIG. 3, the router 144 may determine that the sample packet transmitted through routers 145 and 147 was never received by the server 180 (e.g., if the ping was never returned). Accordingly, the router 144 will reject this route. According to one example, the route check controller may separately store the rejected route for future reference. For example, when the receiving router receives an advertised route, the route check controller may compare the advertised route to its database of stored invalid route. If the advertised route is already in the database, and thus has already been determined to be invalid, the route may be rejected without re-verification. If the route check controller 120 determines that the advertised route is valid, the receiving router 144 will replace the route currently in use and will transmit packets through the network using the advertised route. For example, if router 144 pinged server 180 and the ping was returned within a time frame similar to the expected time frame, router 144 may replace its currently listed route to 180 in its Loc-RIB database with the new route, namely, "router 146 to router 148 to server 180, average time of 0.5 seconds". If the advertised router is valid, the receiving router 144 may optionally advertise this route to its peers. For example, the router 144 may add the route 171 to its Adj-RIB-Out database for sharing with its peers 141-143 and 145-148. It should be understood that the advertised routes which are determined to be valid may still be filtered according to a specified import policy. Such policy may be unique to each router, and may implement any type of algorithm. For example, an import policy may be set to accept route information from only specified peers, or to accept only a limited amount of route information. Moreover, in a scenario where multiple routes to a destination (e.g., server 180) are determined to be valid and pass the filtering policy, a preferred route of the filtered routes may be selected for transmission of the packet. Such selection may be performed according to a predetermined algorithm set for each router. For example, the validated route may be compared to one or more routes currently in use by the router for reaching a particular destination. The preferred route may be determined based on, for example, a local preference attribute, weight, or AS path (i.e., the hops between the router and the destination). Once the preferred route is selected, it may be added to a Loc-RIB database for use in routing packets.).
Regarding claim 4, Wu teaches wherein the first advertised route is for a network address in the set of network addresses, but from the selected logical router of the first logical routers (Fig. 1, Col. 6, line 59 through Col. 7, line 41; advertised route from one router to another for data transmission).
Regarding claim 5, Wu teaches wherein the second advertised route is for a network address in the set of network addresses and from any of the logical routers other than the selected logical router (Fig. 1, Col. 6, line 59 through Col. 7, line 41; advertised routes from one router to another for data transmission).
Regarding claim 6, Wu teaches wherein the list includes a default action, wherein the first rule applies the default action (Col. 6, lines 59-62: If the route check controller 120 determines that the advertised route is invalid, that route will be rejected. This may be performed automatically, for example, using a route filtering rule.), and wherein the second rule includes an action that overrides the default action (Col. 7, lines 10-18: If the route check controller 120 determines that the advertised route is valid, the receiving router 144 will replace the route currently in use and will transmit packets through the network using the advertised route. For example, if router 144 pinged server 180 and the ping was returned within a time frame similar to the expected time frame, router 144 may replace its currently listed route to 180 in its Loc-RIB database with the new route, namely, "router 146 to router 148 to server 180, average time of 0.5 seconds".).
Regarding claim 7, Wu teaches wherein the filter rules comprise a plurality of rules applied in order from highest precedence to lowest precedence (Fig. 5, shows two ‘rules’, first it checks if it is a preferred route and then if it is a valid route), a default rule of the plurality of rules having the lowest precedence and allowing or denying any advertised route (Col. 6, lines 59-62: If the route check controller 120 determines that the advertised route is invalid, that route will be rejected. This may be performed automatically, for example, using a route filtering rule.).
Regarding claim 8, Qian teaches wherein the second logical router comprises a centralized routing component executing in the host and a distributed routing component executing in other hosts of the SDDC, and wherein the routing information comprises a first routing table for the centralized routing component and a second routing table for the distributed routing component ([0058] In the depicted embodiment, the routing/forwarding metadata 108 may include entries of a plurality of route tables 109 and/or policy-based routing rules 110 indicated by a client. A given isolated network 140 may be programmatically associated with a particular route table 109, e.g., using a first type of programmatic interface (an interface used for the “associate” verb or operation) in the depicted embodiment; such an associated route table 109 may be used for directing at least a subset of outbound packets from the isolated network. In another type of programmatic action, route table entries whose destinations are within a given isolated network 140 may be programmatically propagated/installed (e.g., using a different interface for propagation or installation of entries into particular tables) into one or more route tables, enabling traffic from other sources to be received at the isolated network. In at least some embodiments, entries with destinations within a particular isolated network such as 140C may be propagated to one or more route tables 109 that are associated with other isolated networks such as 140A or 140B, enabling, for example, traffic to flow along paths 155A and 155B from those other isolated networks to 140C. Similarly, one or more entries with destinations within isolated network 140D may be propagated to a route table associated with isolated network 140C, enabling traffic to flow from isolated network 140C to isolated network 140D along path 155C. For traffic transferred via path 155D, entries with destinations within isolated network 140D may be propagated to a route table associated with isolated network 140B in the depicted embodiment.).
Regarding claim 10, Wu teaches wherein the centralized routing component advertises the route in the routing information to at least one external physical router (Col. 3, lines 36-47: The databases may be used, for example, for storing route information received from peer routers, for storing route information to be used for forwarding packets through a network, and/or for storing route information to be advertised to further peer routers. For example, routers used with border gateway protocol (BGP) may conceptually include a local routing information base (Loc-RIB), an adjacent routing information base, incoming (Adj-RIB-In), and an adjacent routing information base, outgoing (Adj-RIB-Out). However, while each considered a separate database, they may be structured as one or more physical databases within or external to the routers 141-148.).
Regarding claim 11, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12, it is a media/product type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a media/product type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 14, it is a media/product type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. The additional limitations a hardware platform; a control plane, executing on the hardware platform, is taught by Qian in at least [0002] and Fig. 1, PPS control plane 190.
Regarding claim 16, it is a system type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a system type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, it is a system type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19, it is a system type claim having similar limitations as claim 8 above. Therefore, it is rejected under the same rationale above.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Qian et al. (US 2022/0321469 A1) in view of Wu (US 8,046,490 B1) in view of Jiang et al. (US 2022/0029858 A1), in further view of Han (US 2017/0126726 A1).
Regarding claim 9, Qian, Wu nor Jiang expressly teach but Han teaches wherein the host comprises an edge services gateway that executes the centralized routing component, and wherein the other hosts include hypervisors having managed forwarding elements (MFEs) that execute the distributed routing component ([0003] Some embodiments provide a managed forwarding element (MFE) within a data compute node (DCN) that operates on a host machine in order to enable the DCN to perform network functionalities (e.g., L2 switching, L3 routing, tunneling, etc.) that are normally performed by the virtualization software of the host machine. In some embodiments, the MFE in the data compute node (referred to as DCN-MFE hereinafter) performs these network functionalities instead of, or in conjunction with, a managed forwarding element that resides in the virtualization software (e.g., in the hypervisor) of the host machine.; [0006]; [0013]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Han with the teachings of Qian, Wu and Jiang to implement control logic of data forwarding in shared networks in virtualized computing environments. The modification would have been motivated by the desire of combining known elements to yield predictable results.
Regarding claim 20, it is a system type claim having similar limitations as claim 9 above. Therefore, it is rejected under the same rationale above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Netrakanti et al. (US 2010/0037287 A1) See at least Fig. 2 and its corresponding description.
Kouvelas (US 2004/0081154 A1) See [0280] “In an alternative scenario, provider edge router 2502 uses a single iBPGd session to distribute the paths for both VPNs. The paths are tagged so that the iBGPd session receivers know which VPN forwarding table to assign each path to. There is thus only one session distribution tree to support both VPNs. However, provider edge routers 2506 and 2508 will receive and filter out paths for the VPN that they are not supporting.”
Mo et al. (US 2002/0181477 A1) See at least [0017].
Singh (US 7,990,893 B1) See at least Col. 1, line 49 through Col. 2 line 47.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights