DETAILED ACTION
This office action is in response to the RCE filed on 04/27/2026.
Claims 1-20 are cancelled.
Claims 21-40 have been added.
Claims 21-40 are presented for examination.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/27/2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 21-40 filed on 04/27/2026 in Remarks pg. 7-10 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim(s) 21, 24-25, 27 31, 37, 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1).
Regarding Claim 21, Appala discloses A data processing system (Appala: Fig. 1 Policy Orchestrator) comprising: a processor (Appala: Fig. 6 processor 614); and a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor, cause the data processing system to perform functions (Appala: Fig. 6 memory 616, col. 11 lines 35-51 “One or more programs may be stored in persistent storage 618 for execution by one or more of the respective computer processors 614 via one or more memories of memory 616.”) of:
retrieving network topology data of a computing environment (Appala: Fig. 2, col. 7 lines 48-67 “Turning to FIG. 2, depicted therein is a network environment 200 in which a policy orchestrator 220 determines enforcement points for network policies in a multi-network domain environment. As illustrated in FIG. 2, network environment 200 includes four network domains 210 a-d. Included in the network environment 200 are a plurality of network devices, including switches 215 a-f and routers 217 a-e. ” network environment including each domain 210 a-d, or Fig. 1 domain 110)
wherein the network topology data is examined to determine a location of a device in a region (Appala: col. 4 lines 47-55 “In order to optimize the implementation of network policies, policy orchestrator 120 is aware of the network topology of devices 115 a-e. This network topology includes the relative location of devices 115 a-e and the functionality that each of devices 115 a-e are capable of and configured to perform. For example, policy orchestrator 120 may store data indicative of the topology of network domain 110. This data may indicate that network devices 115 a, 115 c and 115 e are edge network devices through which endpoint devices 130 a-c access network domain 110.” Col. 10 lines 46-59 “In operation 510, a topology of the plurality of devices within the network environment is determined.” The topology of the network is obtained to determine the relative location of each device within the region, i.e. computing environment 100 or 200 in fig. 1-2);
determining data rules specific to the region, one or more rules that are associated with at least one of storage or transfer of data by one or more devices in the computing environment (Appala: Fig. 5 505, col. 10 lines 31-45 “With reference now made to FIG. 5, depicted therein is a flowchart 500 providing a process flow according to the techniques of the present disclosure. The process of flowchart 500 begins in operation 505 in which a plurality of policies are determined. The plurality of policies are to be implemented or enforced in a network environment by a plurality of network devices. The network policies may be user defined or automatically determined by, for example, a policy orchestrator like policy orchestrators 120, 220 and 320 of FIGS. 1-3. The determination of the policies of operation 505 may also include resolving a policy, such as an elevated policy, into a plurality of policy fragments. The network environment referenced in operation 505 may be embodied as a single network domain network environment or a multi-domain network environment.” Rules to be implemented by one or more devices in the network domains 210a-d, therefore specific to the region of each domain, are obtained, for example col. 8 lines 5-15 “Access-Control Section permit traffic from “User1” to “App1” deny traffic from “User1” to “App2” Path Control Section Send “App1” traffic with “gold” QoS Send all other traffic with “silver” QoS.” Showing transfer of data);
retrieving metadata about data flow in the computing environment from a policy governor (Appala: col. 4 lines 47-col. 5 line 25 “ The data stored at policy orchestrator 120 may also indicate the network links 135 a-e that interconnect devices 115 a-e. Accordingly, policy orchestrator 120 may be aware of the network paths though network domain 110…. This data may also indicate the applications and user groups that access network domain 110 and via which of endpoint devices 130 a-c this access takes places.” Data from the storage of the policy orchestrator is also used, therefore retrieved.);
generating an enforcement point decision for configuring the device with configuration data based on the data rules, the metadata, the network topology data, and used by the one or more services provided in the region (Appala: col. 4 line 55-col. 5 line 23 “In order to optimize the implementation of network policies, policy orchestrator 120 is aware of the network topology of devices 115 a-e. … For example, policy orchestrator 120 may store data indicative of the topology of network domain 110. … The data stored at policy orchestrator 120 may also indicate the network links 135 a-e that interconnect devices 115 a-e. Accordingly, policy orchestrator 120 may be aware of the network paths though network domain 110. The data stored at policy orchestrator 120 may also indicate the functionality that each of devices 115 a-e are capable of and configured to implement. For example, different ones of devices 115 a-e may be configured to provide security functionality, such as packet inspection, and ensure QoS levels for traffic traversing network domain 110. … This data allows policy orchestrator 120 to resolve network policies and correlate the network policies with other policies and the network topology to determine where within network domain 110 the policies are to be implemented. … The resolution logic of policy orchestrator 120 looks at the network topology and determines the path traversal for the policy flow. Policy orchestrator 120 then determines the set of domains and devices involved in the traversal path, determines the capabilities and resource levels of the devices along the traversal path, and determines which portions of the policy may be enforced at which devices along the traversal path.” col. 10 line 1-7 “ Furthermore, policy orchestrator 320 may be configured to communicate policy enforcement point decisions to control devices 350 a-e so that the control devices 350 a-e may implement the enforcement point decisions in their respective network domains 310 a-d.” The policies to be enforced, data flow, topology, are all used to determine which policies are enforced at which devices. This information is used to make a policy decision that is sent to the devices for policy enforcement.),
wherein the device is configured with the configuration data that includes only the data rules specific to the region to handle the storage or the transfer of the data by the one or more services in the region (Appala: col. 4 line 55-col. 5 line 23 “Policy orchestrator 120 then determines the set of domains and devices involved in the traversal path, determines the capabilities and resource levels of the devices along the traversal path, and determines which portions of the policy may be enforced at which devices along the traversal path.” col. 10 line 1-7 “ Furthermore, policy orchestrator 320 may be configured to communicate policy enforcement point decisions to control devices 350 a-e so that the control devices 350 a-e may implement the enforcement point decisions in their respective network domains 310 a-d.” only the policies for the region are sent to each device, therefore each device is only configured for those rules for transfer of data for the region.); and
wherein the device utilizes the configuration data to route the data in the computing environment in the region according to the data rules specific to the region, the metadata (Appala: col. 10 line 1-7 “ Furthermore, policy orchestrator 320 may be configured to communicate policy enforcement point decisions to control devices 350 a-e so that the control devices 350 a-e may implement the enforcement point decisions in their respective network domains 310 a-d.” each device of the domain obtains the policies to be implemented at their respective enforcement points of the domain in the network. As shown above, the enforcement point decision is based on the data rules specific to the region, the metadata, in col. 4 line 55-col. 5 line 23).
transmitting the enforcement point decision to each device (Appala: col. 10 line 1-7 “ Furthermore, policy orchestrator 320 may be configured to communicate policy enforcement point decisions to control devices 350 a-e so that the control devices 350 a-e may implement the enforcement point decisions in their respective network domains 310 a-d.”)
However Appala does not explicitly disclose retrieving network topology data of a computing environment wherein the network topology data is examined to determine a location of a Field Programmable Gate Array (FPGA) in a region; retrieving data rules specific to the region from a rule repository that stores one or more rules that are associated with at least one of storage or transfer of data by one or more devices in the computing environment; retrieving data classification information of the data used by one or more services provided by the computing environment; generating a configuration file for configuring the FPGA with configuration data based on the data rules, the metadata, the network topology data, and the data classification information of the data used by the one or more services provided in the region, wherein the FPGA is configured with the configuration data that includes only the data rules specific to the region to handle the storage or the transfer of the data by the one or more services in the region; and transmitting the configuration file to an FPGA configuration loader for loading the configuration data onto the FPGA, wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data rules specific to the region, the metadata, and the data classification information; that is, primarily, while Appala discloses an FPGA in col. 14 lines 60-65, it does not explicitly disclose the network devices implemented as FPGAs, the data rules are not obtained from a repository (only determined), and therefore also does not explicitly disclose an FPGA configuration file.
Bagwell discloses retrieving data rules from a rule repository (Bagwell: para.0021 “SMF 109 and/or some other device or system”) that stores one or more rules that are associated with at least one of storage or transfer of data by one or more devices in the computing environment (Bagwell: para.0021 “UPF-C 107 may obtain (at 108) policies associated with the packet from SMF 109 and/or some other device or system. For example, UPF-C 107 may be communicatively coupled to SMF 109 via a N4 interface. As noted above, the policies may include QoS policies, content filtering policies, and/or other suitable policies.” The SMF or other device/system stores a plurality of policies associated with the transfer of data in the network of the device, para.0029 “The configuration parameters, once configured at UPF-U 105, may cause UPF-U 105 to treat traffic in a manner consistent with the policies (provided at 114) associated with a particular flow with which the traffic is associated.” describes how the device uses the policies to affect data after policies are installed)
generating a configuration file for configuring the FPGA with configuration data based on the data rules, wherein the FPGA is configured with the configuration data (Bagwell: para.0021 “UPF-C 107 may obtain (at 108) policies associated with the packet from SMF 109 and/or some other device or system. ” para.0023 “Additionally, UPF-C 107 may provide (at 114) an indication of the one or more policies (e.g., as obtained at 108) to UPF-U 105. For example, UPF-C 107 may communicate with UPF-U 105 via an application programming interface (“API”), a messaging protocol, and/or some other suitable communication pathway, in order to indicate that UPF-C 107 is providing policy information associated with the traffic provided (at 106) to UPF-C 107.” The UPF-107 uses the set of policies and generates a configuration file comprising the policies, and an indication regarding the policies (described in para.0024-0027), and provides this to the UPF 105-U in step 114.)
transmitting the configuration file to an FPGA configuration loader (Bagwell: Fig. 1A routing component 101, including UPF-U 105) for loading the configuration data onto the FPGA (Bagwell: para.0034 “ As discussed above, UPF-U 105 may have received (at 114) policy information from UPF-C 107, as well as one or more identifiers (e.g., 5-tuples and/or other suitable identifiers) with which such policies are associated.” Para.0028 “For example, UPF-U 105 … may include a Field Programmable Gate Array (“FPGA”). The FPGA may be configurable using the P4 programming language, another programming language, and/or some other suitable configuration technique. UPF-U 105 may perform (at 116) a configuration process (e.g., may configure the FPGA) based on the received policies.” The UPF-C 107 sends the configuration file comprising the policies and the identifiers to UPF-U 105 of routing component 101, in order to configure an FPGA.),
wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data rules (Bagwell: para.0056 “For example, UPF-U 105 may include FPGA or other configurable resources that may be configured (e.g., based on the P4 programming language and/or other suitable parameters) to implement the received policies for traffic associated with a given flow.” para.0029 “The configuration parameters, once configured at UPF-U 105, may cause UPF-U 105 to treat traffic in a manner consistent with the policies (provided at 114) associated with a particular flow with which the traffic is associated. For example, UPF-U 105 may perform QoS-related traffic treatment, buffering, traffic duplication, access control, lawful interception, performance management counter collection (e.g., to track an amount of traffic associated with a given flow), GTP termination (e.g., in lieu of UPF-C 107, for GTP traffic that indicates UPF-C 107 as an endpoint), redirection, gating, steering, and/or other suitable treatment as indicated in the received policies.” para.0034 “As discussed above, UPF-U 105 may have received (at 114) policy information from UPF-C 107, as well as one or more identifiers (e.g., 5-tuples and/or other suitable identifiers) with which such policies are associated. UPF-U 105 may accordingly apply (at 126) the applicable policies to the traffic, such as QoS treatment and/or other suitable treatment based on the policies.” Once configured with the policy information, the FPGA implements the policies in the computing environment on received flow, based on the configuration file received from UPF-C, the traffic is routed, i.e. redirection, gating steering, based on the policies.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala with that of Bagwell in order to incorporate retrieving data rules from a rule repository that stores one or more rules that are associated with at least one of storage or transfer of data by one or more devices in the computing environment; generating a configuration file for configuring the FPGA with configuration data based on the data rules, wherein the FPGA is configured with the configuration data; transmitting the configuration file to an FPGA configuration loader for loading the configuration data onto the FPGA; wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data rules, and apply this concept to that of Appala such that each network device is implemented as FPGA, the location of the FPGA device is determined using the topology data, and the region based rule implementation is performed using FPGA configuration files.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of known efficiencies of an FPGA that would improve network function (Bagwell: para.0028).
However Appala-Bagwell does not explicitly disclose retrieving data classification information of the data used by one or more services provided by the computing environment; generating a configuration file for configuring the FPGA with configuration data based on the data classification information of the data used by the one or more services provided in the region; and wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data classification information
Threefoot discloses retrieving data classification information of the data used by one or more services provided by the computing environment (Threefoot: para.0056 “Data collector 304 may also collect network data received by the data collection components, and store the collected data in network information database 312.” Para.0070 “The traffic data provided to network information database 312 by data collector 304 may include (for each node (e.g., router) from which data is collected) traffic data for different Quality-of-Service (QoS) classes or differentiated service code point (DSCP) markings.” Para.0071 “ Video/Priority Data (High) QoS 606-1, Video/`Priority Data (Low) QoS 608-1,” para.0034“Topology manager 110 may derive routing rules (also referred to as a “routing table”) based on network state variables, a particular PIP network 104, network data, and routes (i.e., paths from a user device to a cloud 102), and ranking policies. The routing rules may specify, for a particular set of network state variables and/or network data (e.g., a network address of a domain name system (DNS), a network address of a device that requested the cloud service, the time of the request, bandwidths available to clouds 102, availability of a particular service, health status of clouds 102, load conditions of clouds 102 for a type of service, etc.), a list clouds 102 or paths that may provide the optimum service (e.g., the fastest download time).” Fig. 6, the data collected and stored in database 312 include classification of data used by the services, such as video business etc. including its priority, type of service, and any of the classification information in para.0034.)
generating a configuration file for configuring the FPGA with configuration data (Threefoot: para.0043-0044 “FIG. 2 is a block diagram of exemplary components of a network device 200. Network device 200 may correspond to any of the devices illustrated in network 100…a Field Programmable Gate Array (FPGA)”) based on the data classification information of the data used by the one or more services provided in the region (Threefoot: para.0034 “Topology manager 110 may derive routing rules (also referred to as a “routing table”) based on network state variables, a particular PIP network 104, network data, and routes (i.e., paths from a user device to a cloud 102), and ranking policies. The routing rules may specify, for a particular set of network state variables and/or network data (e.g., a network address of a domain name system (DNS), a network address of a device that requested the cloud service, the time of the request, bandwidths available to clouds 102, availability of a particular service, health status of clouds 102, load conditions of clouds 102 for a type of service, etc.), a list clouds 102 or paths that may provide the optimum service (e.g., the fastest download time).” Using the data obtained, including topology and network classification data, see also para.0059, 0061-0062, routing rules are generated.); and
wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data classification information (Threefoot: para.0129-0130 “As shown, topology manager 110 may receive policies and/or rules 1620 from administration device. Furthermore, based on the received policies/rules 1620, topology manager 110 may generate routing rules/table 1622 and forward routing rules/table 1622 to request router 112. When request router 112 receives a request for a path 1630 to cloud 102 from a user device 114, request router 112 may provide a redirection address (e.g., IP address, URL, URL, etc.) 1632 to user device 114. Based on redirection address 1632, user device 104 may send a request 1634 for service to cloud 102.” Fiog. 16 1622-1632 the request router implements the rules obtained from the topology manager, i.e. the configuration file, according to the data classification information used to generate the rules as shown above.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell with Threefoot in order to incorporate retrieving data classification information of the data used by one or more services provided by the computing environment; generating a configuration file for configuring the FPGA with configuration data based on the data classification information of the data used by the one or more services provided in the region; and wherein the FPGA utilizes the configuration data to route the data in the computing environment in the region according to the data classification information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of optimizing network routing (Threefoot: abstract, para.0023).
Regarding Claim 24, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell does not explicitly disclose wherein the data classification information of the data used by the one or more services provided by the computing environment is extracted from one or more data sources associated with the one or more services via a Single Source of Truth (SSOT) extracting engine.
Threefoot discloses wherein the data classification information of the data used by the one or more services provided by the computing environment is extracted from one or more data sources associated with the one or more services via a Single Source of Truth (SSOT) extracting engine (Threefoot: data collector 304 para.0056 “Data collector 304 may also collect network data received by the data collection components, and store the collected data in network information database 312.” Para.0070 “The traffic data provided to network information database 312 by data collector 304 may include (for each node (e.g., router) from which data is collected) traffic data for different Quality-of-Service (QoS) classes or differentiated service code point (DSCP) markings.” Para.0071 “ Video/Priority Data (High) QoS 606-1, Video/`Priority Data (Low) QoS 608-1,” Fig. 6, the data collected and stored in database 312 include classification of data used by the services, such as video business etc. including its priority, by the data collector 304, a Single Source of truth extracting engine, from various srouces such as data collection components regarding service metrics. Examiner notes: a Single source of truth under broadest reasonable interpretation refers to the concept of all data for a system being stored in a single location, therefore PCTM 108 is a single source of truth, and the data collector 304 is a single source of truth extracting engine.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell with Threefoot in order to incorporate wherein the data classification information of the data used by the one or more services provided by the computing environment is extracted from one or more data sources associated with the one or more services via a Single Source of Truth (SSOT) extracting engine.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of optimizing network routing (Threefoot: abstract, para.0023).
Regarding Claim 25, Bagwell-Ding-Threefoot discloses claim 24 as set forth above.
However Appala-Bagwell does not explicitly disclose wherein the data classification information extracted via the SSOT extracting engine is used to store a SSOT document for the computing environment in a data store.
Threefoot discloses wherein the data classification information extracted via the SSOT extracting engine is used to store a SSOT document for the computing environment in a data store (Threefoot: data collector 304 para.0056 “Data collector 304 may also collect network data received by the data collection components, and store the collected data in network information database 312.” Para.0070 “The traffic data provided to network information database 312 by data collector 304 may include (for each node (e.g., router) from which data is collected) traffic data for different Quality-of-Service (QoS) classes or differentiated service code point (DSCP) markings.” Para.0071 “ Video/Priority Data (High) QoS 606-1, Video/`Priority Data (Low) QoS 608-1,” para.0057 “In some implementations, data collector 304 may invoke APIs made available by cloud service providers to determine or identify (for devices in clouds 102) CPUs, memory, server/storage throughout each server/storage farm in the cloud 102, etc. Data collector 304 may store such data in cloud database 310.” Fig. 6, the information collected by the data collector 304, is used to generate documents that represent qos information for services such as in Fig. 6 or Fig. 11 corresponding to para.0057, para.0099-0104 explains the information for each service. Stored in database 312 or 310, each of which can be data stores.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell with Threefoot in order to incorporate wherein the data classification information extracted via the SSOT extracting engine is used to store a SSOT document for the computing environment in a data store.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of optimizing network routing (Threefoot: abstract, para.0023).
Regarding Claim 27, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell does not explicitly disclose wherein the network topography data of the computing environment is retrieved from the FPGA configuration loader.
Threefoot discloses wherein the network topography data of the computing environment is retrieved from a network router (Threefoot: para.0128 “FIG. 16 is a diagram illustrating an exemplary flow of messages between network devices/elements of FIG. 1B. As shown, topology manager 110 may receive network topology information 1612, network performance data 1614, cloud information 1616 (e.g., service or cloud topology information, cloud device information, etc.), and cloud or service performance data 1618 from network routers 1602 and clouds 102. ” para.0025 “On PIP network-by-PIP network basis, topology manager 110 collects network service topology information from clouds 102, network topology information from PIP network 104, and policies from administration device 116. Based on the received information, topology manager 110 generates routing rules or a routing table that specify optimum paths over which traffic flow from/to devices in PIPS 104 to/from clouds 102.” Network topology information is obtained from network routers to generate routing rules).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell with Threefoot in order to incorporate wherein the network topography data of the computing environment is retrieved from a network router, and apply this concept to the FPGA configuration loader of Bagwell, which is a router, i.e. routing component 101.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of optimizing network routing (Threefoot: abstract, para.0023).
Regarding Claim 31, it teaches all of the same steps as claim 21 but in A method for ensuring data compliance in a computing environment (Appala: Fig. 2, col. 7 lines 48-67 “Turning to FIG. 2, depicted therein is a network environment 200 in which a policy orchestrator 220 determines enforcement points for network policies in a multi-network domain environment. As illustrated in FIG. 2, network environment 200 includes four network domains 210 a-d. Included in the network environment 200 are a plurality of network devices, including switches 215 a-f and routers 217 a-e. ” network compliance via policies, col. 13 line 65-66 method) Therefore the supporting rationale for the rejection to claims 21 apply equally as well to that of claim 31.
Regarding Claim 37, it teaches all of the same steps as claim 21 but in A non-transitory computer readable medium on which are stored instructions that when executed cause a programmable device to perform functions (Appala: col. 13 line 22-29). Therefore the supporting rationale for the rejection to claims 21 apply equally as well to that of claim 37.
Regarding Claim 39, Appala-Bagwell-Threefoot discloses claim 37 as set forth above.
However Appala does not explicitly disclose wherein the FPGA is included in a network device of the computing environment, the network device being used to route the data in the computing environment
Bagwell further discloses wherein the FPGA is included in a network device of the computing environment, the network device being used to route the data in the computing environment (Bagwell: para.0029 “The configuration parameters, once configured at UPF-U 105, may cause UPF-U 105 to treat traffic in a manner consistent with the policies (provided at 114) associated with a particular flow with which the traffic is associated. For example, UPF-U 105 may perform QoS-related traffic treatment, buffering, traffic duplication, access control, lawful interception, performance management counter collection (e.g., to track an amount of traffic associated with a given flow), GTP termination (e.g., in lieu of UPF-C 107, for GTP traffic that indicates UPF-C 107 as an endpoint), redirection, gating, steering, and/or other suitable treatment as indicated in the received policies.” para.0034 “As discussed above, UPF-U 105 may have received (at 114) policy information from UPF-C 107, as well as one or more identifiers (e.g., 5-tuples and/or other suitable identifiers) with which such policies are associated. UPF-U 105 may accordingly apply (at 126) the applicable policies to the traffic, such as QoS treatment and/or other suitable treatment based on the policies.” Based on the configuration file received from UPF-C, the traffic is routed, i.e. redirection, gating steering, based on the policies by the routing component 101, which comprises the UPF-U with the FPGA. For example in the computing environment in Fig. 3.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala with that of Bagwell in order to incorporate wherein the FPGA is included in a network device of the computing environment, the network device being used to route the data in the computing environment.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of known efficiencies of an FPGA that would improve network function (Bagwell: para.0028).
Claim(s) 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Young et al. (hereinafter Young, US 2024/0163724 A1).
Regarding Claim 22, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
While Appala-Bagwell-Threefoot discloses the process of obtaining rules from a rule repository and generating configuration files, it does not explicitly disclose wherein the data rules are extracted from the rule repository by a rule extracting engine and retrieved from the rule extracting engine by a FPGA configuration generator.
Young discloses wherein the data rules are extracted from the rule repository (Young: Fig. 5 Policy DB 510, or 518 of policy DB) by a rule extracting engine (Young: Fig. 5 Policy engine 508, para.0070 “Furthermore, configuration generator 506 may query policy engine 508 to retrieve policy rules applicable to the flow, from design rules DB 518 and flow properties DB 520 (block 1008). Policy engine 510 may retrieve and provide the requested rules to configuration generator 506.” Policy engine 508 is the rule extracting engine, and it obtains rules from policy DB 518.) and
retrieved from the rule extracting engine by a FPGA configuration generator (Young: Fig. 5 Configuration Generator 506, para.0076 FPGA, para.0070 “Furthermore, configuration generator 506 may query policy engine 508 to retrieve policy rules applicable to the flow, from design rules DB 518 and flow properties DB 520 (block 1008). Policy engine 510 may retrieve and provide the requested rules to configuration generator 506.” The configuration generator 506 obtains the policies that were stored on Policy DB 510, from Policy Engine 508).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing to combine Appala-Bagwell-Threefoot with that of Young in order to incorporate wherein the data rules are extracted from the rule repository by a rule extracting engine and retrieved from the rule extracting engine by a FPGA configuration generator.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of reducing the load at the configuration generator by having a dedicated engine perform the storing and pushing of policies (Young: para.0055-0056).
Regarding Claim 23, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the metadata are extracted from the policy governor by a policy extracting engine and retrieved from the policy extracting engine by a FPGA configuration generator.
Young discloses wherein the metadata are extracted from the policy governor (Young: Fig. 5 Policy DB 510 or the DB 520 of DB 510.) by a policy extracting engine (Young: Fig. 5 Policy engine 508, para.0070 “Furthermore, configuration generator 506 may query policy engine 508 to retrieve policy rules applicable to the flow, from design rules DB 518 and flow properties DB 520 (block 1008). Policy engine 510 may retrieve and provide the requested rules to configuration generator 506.” Policy engine 508 is the rule extracting engine, and it obtains metadata about the flow from DB 510/ DB 520..) and
retrieved from the policy extracting engine by a FPGA configuration generator (Young: Fig. 5 Configuration Generator 506, para.0076 FPGA, para.0070 “Furthermore, configuration generator 506 may query policy engine 508 to retrieve policy rules applicable to the flow, from design rules DB 518 and flow properties DB 520 (block 1008). Policy engine 510 may retrieve and provide the requested rules to configuration generator 506.” The configuration generator 506 obtains the metadata regarding at least flow property metadata obtained by the policy extracting engine Fig. 5.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing to combine Appala-Bagwell-Threefoot with that of Young in order to incorporate wherein the metadata are extracted from the policy governor by a policy extracting engine and retrieved from the policy extracting engine by a FPGA configuration generator.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of reducing the load at the configuration generator by having a dedicated engine perform the storing and pushing of policies (Young: para.0055-0056).
Claim(s) 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Timmons (US 2022/0200915 A1).
Regarding Claim 28, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the FPGA configuration loader receives the network topology data from at least one of a network graph service, a network state service, and a control plane.
Timmons discloses wherein the router receives the network topology data from at least one of a network graph service, a network state service, and a control plane (Timmons: para.0050 “In some examples, routers 110 operate according to a publish-subscribe model. According to this model, each router 110 publishes, to central repository 120, one or more changes in services reachable from the router 110 and/or one or more changes in a network topology for reaching the services from the router 110. Other routers 110 may subscribe to receive publications for the router 110 from central repository 120. In response to receiving changes in the service and topology state information for a router 110, central repository 120 stores the changes in the service and topology state information for the router 110. Further, central repository 120 publishes the changes in the service and topology state information for the router 110 to other routers 110 that are subscribed to receive updates and/or changes for the router 110.” The central repository obtains topology changes and publishes these changes to all other routers. The central repository is at least a network graph service or a network state services as it maintains the topology of the network and provides these as a service to the routers.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot with Timmons in order to incorporate wherein the router receives the network topology data from at least one of a network graph service, a network state service, and a control plane, and apply this concept to the FPGA configuration loader of Bagwell implemented as a router.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving performance of a computer network with better control of routing (Timmons: para.0008).
Claim(s) 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Boyapalle et al. (hereinafter Boyapalle, US 11,979,327 B1).
Regarding Claim 29, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the FPGA configuration loader utilizes an artificial intelligence model to determine whether a new configuration file should be generated for the FPGA.
Boyapelle discloses wherein the Orchestrator utilizes an artificial intelligence model to determine whether a new configuration file should be generated for the HIS (Boyapalle: col. 8 lines 46-58 “OS agent or service 302 may collect telemetry data and transmit the telemetry data to cloud orchestrator 401 (e.g., one or remote services 206A-N). Cloud orchestrator 401 may be configured to execute one or more ML/AI models upon the telemetry data to determine whether changes to traffic routing provided by the current policy can be improved to achieve a particular Key Performance Indicator (KPI), such as a user experience metric, a productivity metric, latency, throughput, etc.” the orchestrator 401 determines using an AI model that routing policy should be changed to achieve a traffic metric.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Appala-Bagwell-Threefoot with Boyapelle in order to incorporate wherein the Orchestrator utilizes an artificial intelligence model to determine whether a new configuration file should be generated for the HIS, and apply this concept to the FPGA configuration loader and the FPGA of Bagwell.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved traffic routing (Boyapelle: col. 8 lines 46-58).
Claim(s) 30, 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Turan et al. (hereinafter Turan, US 2021/0110099 A1).
Regarding Claim 30, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the FPGA configuration loader utilizes a hardware proxy to load the configuration file onto the FPGA.
Turan discloses wherein the FPGA configuration loader (Turan: Fig. 2 Configuration data loading equipment 54) utilizes a hardware proxy (Turan: Fig. 2 configuration device 40) to load the configuration file (Turan: Fig. 2 configuration data) onto the FPGA (Turan: fpga 10, Fig. 6, Fig. 2. Para.0035 “As shown in FIG. 2, the configuration data produced by a logic design system 56 may be provided to equipment 54 over a path such as path 58. The equipment 54 provides the configuration data to device 40, so that device 40 can later provide this configuration data to the programmable logic device 10 over path 42.” The configuration loader uses hardware proxy 40 to configure the FPGA 10).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot in order to incorporate wherein the FPGA configuration loader utilizes a hardware proxy to load the configuration file onto the FPGA.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved security that would come with dedicated read-only memory being used for configuration of the FPGA (Turan: para.0032).
Regarding Claim 38, Appala-Bagwell-Threefoot discloses claim 37 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the FPGA configuration loader utilizes a hardware proxy to load the configuration file onto the FPGA.
Turan discloses wherein the FPGA configuration loader (Turan: Fig. 2 Configuration data loading equipment 54) utilizes a hardware proxy (Turan: Fig. 2 configuration device 40) to load the configuration file (Turan: Fig. 2 configuration data) onto the FPGA (Turan: fpga 10, Fig. 6, Fig. 2. Para.0035 “As shown in FIG. 2, the configuration data produced by a logic design system 56 may be provided to equipment 54 over a path such as path 58. The equipment 54 provides the configuration data to device 40, so that device 40 can later provide this configuration data to the programmable logic device 10 over path 42.” The configuration loader uses hardware proxy 40 to configure the FPGA 10).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot in order to incorporate wherein the FPGA configuration loader utilizes a hardware proxy to load the configuration file onto the FPGA.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved security that would come with dedicated read-only memory being used for configuration of the FPGA (Turan: para.0032).
Claim(s) 26, 32-33, 36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Dickinson et al. (hereinafter Dickenson, US 10,862,796 B1).
Regarding Claim 26, Appala-Bagwell-Threefoot discloses claim 21 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine, wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents.
Dickinson discloses providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine (Dickinson: col. 18 lines 36-60 “As indicated at 1130, in some embodiments, the flow policy service may obtain and aggregate flow logs to generate flow reports for the client. The network appliances attached to or within a client's virtual network may generate flow logs based on the client packets processed at the network appliances. In some embodiments, network devices (e.g., edge routers, host devices, etc.) that apply flow policy rules may also generate flow logs. The flow logs may, for example, be collected and aggregated by the flow policy service to generate flow reports that may be used by the client to confirm that traffic to, from, or within their virtual network is flowing through the correct network appliances according to the flow policy rules.” The flow policy service is the report generating engine, and it collects flow metadata in order to generate reports.),
wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents (Dickinson: col. 18 lines 36-60 “In some embodiments, network devices (e.g., edge routers, host devices, etc.) that apply flow policy rules may also generate flow logs. The flow logs may, for example, be collected and aggregated by the flow policy service to generate flow reports that may be used by the client to confirm that traffic to, from, or within their virtual network is flowing through the correct network appliances according to the flow policy rules.” The flow reports, i.e. metadata, is aggregated into a flow report, the data compliance document.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot with Dickinson in order to incorporate providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine, wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents.
One of ordinary skill would have been motivated to combine because of the expected benefit of improved user experience by being able to personally confirm compliance with rules in the system (Dickinson: col. 18 lines 36-60).
Regarding Claim 32, Appala-Bagwell-Threefoot discloses claim 31 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine, wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents.
Dickinson discloses providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine (Dickinson: col. 18 lines 36-60 “As indicated at 1130, in some embodiments, the flow policy service may obtain and aggregate flow logs to generate flow reports for the client. The network appliances attached to or within a client's virtual network may generate flow logs based on the client packets processed at the network appliances. In some embodiments, network devices (e.g., edge routers, host devices, etc.) that apply flow policy rules may also generate flow logs. The flow logs may, for example, be collected and aggregated by the flow policy service to generate flow reports that may be used by the client to confirm that traffic to, from, or within their virtual network is flowing through the correct network appliances according to the flow policy rules.” The flow policy service is the report generating engine, and it collects flow metadata in order to generate reports.),
wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents (Dickinson: col. 18 lines 36-60 “In some embodiments, network devices (e.g., edge routers, host devices, etc.) that apply flow policy rules may also generate flow logs. The flow logs may, for example, be collected and aggregated by the flow policy service to generate flow reports that may be used by the client to confirm that traffic to, from, or within their virtual network is flowing through the correct network appliances according to the flow policy rules.” The flow reports, i.e. metadata, is aggregated into a flow report, the data compliance document.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot with Dickinson in order to incorporate providing at least one of the data rules, the metadata, the network topology data, the data classification information and one or more auth configuration files associated with the one or more services to a report generating engine, wherein the report generating engine utilizes at least one of the data rules, the metadata, the network topology data, the data classification information and authorization configuration data associated with the one or more services to the report generating engine to generate one or more data compliance documents.
One of ordinary skill would have been motivated to combine because of the expected benefit of improved user experience by being able to personally confirm compliance with rules in the system (Dickinson: col. 18 lines 36-60).
Regarding Claim 33, Appala-Bagwell-Threefoot -Dickinson discloses claim 32 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the report generating engine is a software service or software application for generating data compliance documents.
Dickinson discloses wherein the report generating engine is a software service or software application for generating data compliance documents (Dickinson: col. 18 lines 36-60 “In some embodiments, network devices (e.g., edge routers, host devices, etc.) that apply flow policy rules may also generate flow logs. The flow logs may, for example, be collected and aggregated by the flow policy service to generate flow reports that may be used by the client to confirm that traffic to, from, or within their virtual network is flowing through the correct network appliances according to the flow policy rules.” The flow policy service is the report generating engine, and considered to be both a software service and a software application).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot with Dickinson in order to incorporate wherein the report generating engine is a software service or software application for generating data compliance documents.
One of ordinary skill would have been motivated to combine because of the expected benefit of improved user experience by being able to personally confirm compliance with rules in the system (Dickinson: col. 18 lines 36-60).
Regarding Claim 36, Appala-Bagwell-Threefoot -Dickinson discloses claim 32 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the report generating engine transmits the one or more data compliance documents to a reporting tool.
Dickinson discloses wherein the report generating engine transmits the one or more data compliance documents to a reporting tool (Dickinson: col. 10 lines 15-37 “Aggregation 236 engine may implement, but is not limited to, logic for receiving flow logs from appliances 214 and/or network devices 208 via API 232B, and logic for aggregating and formatting the flow logs to provide flow reports 239 to the interface 284 on client device 282 via API 232A.” the interface 284 is the reporting tool, and the aggregation engine of the flow policy service that produces the flow report provides the flow report to the interface.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot with Dickinson in order to incorporate wherein the report generating engine transmits the one or more data compliance documents to a reporting tool.
One of ordinary skill would have been motivated to combine because of the expected benefit of improved user experience by being able to personally confirm compliance with rules in the system (Dickinson: col. 18 lines 36-60).
Claim(s) 34-35 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Dickinson et al. (hereinafter Dickenson, US 10,862,796 B1) further in view of Yum et al. (hereinafter Yum, US 2015/0067171 A1).
Regarding Claim 34, Appala-Bagwell-Threefoot -Dickinson discloses claim 32 as set forth above.
However Appala-Bagwell-Threefoot -Dickinson does not explicitly disclose wherein the report generating engine generates a user selected type of data compliance document.
Yum discloses wherein the report generating engine generates a user selected type of data compliance document (Yum: para.0096 “ Once the data selection criteria are defined, the user may choose a pre-defined template to present the information. The report may be viewed online, saved as a document, and/or transferred out via different protocols such as email or secure shell (SSH) file transfer protocol (SFTP), etc. ” the template/type of document to be generated is selected by the user.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot -Dickinson with Yum in order to incorporate wherein the report generating engine generates a user selected type of data compliance document.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved user experience by being able to customize the report to the users liking (Yum: para.0096).
Regarding Claim 35 Appala-Bagwell-Threefoot -Dickinson discloses claim 32 as set forth above.
However Appala-Bagwell-Threefoot -Dickinson does not explicitly disclose wherein the report generating engine enables a user to select one or more types of data points to be included in a data compliance document.
Yum discloses wherein the report generating engine enables a user to select one or more types of data points to be included in a data compliance document (Yum: para.0096 “This module may be responsible for generating different views of information generated by the cloud service brokering facility 204, which views may be provided to the user through the interface facility 202. The user may extract the part of information of interest by specifying filtering criteria for each data set. The filtering criteria may include time, duration, resource type, resource location, users, selected data fields, etc. The filtering criteria may be saved for reuse. Once the data selection criteria are defined, the user may choose a pre-defined template to present the information. The report may be viewed online, saved as a document, and/or transferred out via different protocols such as email or secure shell (SSH) file transfer protocol (SFTP), etc.” The user is able to select types of data to be included in the report.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Appala-Bagwell-Threefoot -Dickinson with Yum in order to incorporate wherein the report generating engine enables a user to select one or more types of data points to be included in a data compliance document.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved user experience by being able to customize the report to the users liking (Yum: para.0096).
Claim(s) 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Appala et al. (hereinafter Appala, US 11,374,980 B1) in view of Bagwell et al. (hereinafter Bagwell, US 2022/0021605 A1) in view of Threefoot et al. (hereinafter Threefoot, US 2015/0052247 A1) in view of Carney et al. (hereinafter Carney, US 2012/0167160 A1).
Regarding Claim 40, Appala-Bagwell-Threefoot discloses claim 37 as set forth above.
However Appala-Bagwell-Threefoot does not explicitly disclose wherein the computing environment includes a plurality of FPGAs and the FPGA configuration loader determines the configuration file to load onto each of the plurality of FPGAs.
Carney discloses wherein the computing environment includes a plurality of FPGAs (Carney: para.0024 “The router policy server may manage a routing table for a network, may determine which routers are to receive routing information based on a policy associated with each router, and may provide the routing information to the other routers based on the determined policy.” The environment has a plurality of routers, each router operated via FPGA, para.0041-0042 “Device 300 may correspond to router policy server 115 or to control unit 240 of trusted router 125…. Processor 320 may include… field programmable gate arrays (FPGAs)”) and
the FPGA configuration loader determines the configuration file to load onto each of the plurality of FPGAs (Carney: para.0024 “The router policy server may manage a routing table for a network, may determine which routers are to receive routing information based on a policy associated with each router, and may provide the routing information to the other routers based on the determined policy.” It is determined which router, each of which run on an FPGA, receive which set of routing information).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Appala-Bagwell-Threefoot with Carney in order to incorporate wherein the computing environment includes a plurality of FPGAs and the FPGA configuration loader determines the configuration file to load onto each of the plurality of FPGAs.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved security by only providing needed routing for each FPGA (Carney: para.0024).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Brannon et al. US 2021/0406398 A1 see para.0690 that sets data transfer rules based on rules for areas such as the EU or organization.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/ Examiner, Art Unit 2453
/DHAIRYA A PATEL/ Primary Examiner, Art Unit 2453
Prosecution Insights