DETAILED ACTION
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 .
This Office Action is in response to the correspondence filed 01/22/2024.
Claims 1-20 are pending and rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/30/2025 & 06/23/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Moorthi et al (US20130152047A1) in view of Nix (US20190313246A1).
Regarding claim 1, Moorthi discloses a device, comprising:
a processor ([0195]-[0196], discloses a system architecture involving networked computing services that execute logic (processor/memory) and communicate over a network (network interface); networked system/services supporting request handling via network/API);
at least one network interface controller configured to provide access to a network ([0195]-[0196], discloses a system architecture involving networked computing services that execute logic (processor/memory) and communicate over a network (network interface); networked system/services supporting request handling via network/API); and
a memory communicatively coupled to the processor, wherein the memory comprises a workload protection logic that is configured to:
receive a disaster recovery request ([0281]-[0284], teaches receiving operational “requests” via API endpoints, i.e. the system receives a request that triggers execution actions (start/stop/keygen); hub API receives POST requests including start/stop/keygen);
create a plurality of keys ([0281], [0283], explicitly teaches multiple key types and key generation; describes “three key types” and includes ephemeral key generation; POST/1/emcee/keygen generates/returns a registered ephemeral key);
replicate one or more configuration components ([0180], [0185], describes using/copying configuration materials such as configuration files contained key data and environment settings; create and copy an API key into a config file, e.g. ~/.tddium; read config file; configuration drives environment selection and execution); and
But Moorthi fails to teach execute a disaster recovery process.
However, Nix teaches execute a disaster recovery process ([0237], explicitly describes backup of running configuration and restore if applying the update fails—this is highly consistent with executing a “disaster recovery process.”; backup running configurations + restore when update fails).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 2, Moorthi fails to teach the device wherein the disaster recovery request is received in response to a disaster event.
However, Nix teaches the device wherein the disaster recovery request is received in response to a disaster event ([0237], describes situations where applying configuration updates may fail, and the device restores a prior backed-up configuration; this maps well to “disaster recovery” being invoked in response to a failure/adverse condition (i.e. disaster event) – supporting a disaster event as an operational failure/error condition triggering recovery).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 3, Moorthi teaches the device wherein the disaster recovery request is received in response to a time-based event ([0281]-[0284], supports repeated/polled start logic and blocking/wait responses, which supports time-based triggers and periodic requests patterns.
Regarding claim 4, Moorthi teaches the device wherein the plurality of keys are application programming interface keys ([0185], [0207], [0281], explicitly requires API key authentication using an API key header, and also describes keys in the context of configurations files; authentication header “X-tddium-api-key”; requires a user API key; X-tddium-api-key header insertion; key pulled from config).
Regarding claim 5, Moorthi fails to teach the device wherein the network comprises a plurality of network devices.
However, Nix teaches the device wherein the network comprises a plurality of network devices ([0016]-[0019], explicitly discloses multiple network devices/entities communicating: device, configuration server, authentication server, reporting server, mobile handset, and IP network).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 6, Moorthi fails to teach the device wherein the plurality of network devices are configured with security certificates.
However, Nix teaches the device wherein the plurality of network devices are configured with security certificates ([0232], [0255], explicitly discloses device recording certificate authority certificates and root certificate; devices records root certificates/certificate authority certificates; device records root certificate + intermediate certificates for verification).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 7, Moorthi fails to teach the device wherein the security certificates are identical across the plurality of network devices.
However, Nix teaches the device wherein the security certificates are identical across the plurality of network devices ([0232], explicitly supports “identical across devices” by stating certificate authorities in the system can share the same root certificate (i.e. an identical root/trust-anchor certificate across multiple entities; could share the same root certificate).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 8, Moorthi fails to teach the device wherein the replication of the one or more configuration components comprises at least: querying a source network device for one or more configurations; copying the one or more configurations; replicating the one or more configurations to a target network device.
However, Nix teaches the device wherein the replication of the one or more configuration components comprises at least:
querying a source network device for one or more configurations ([0190], [0192]-[0193], expressly teaches selecting/identifying nodes and querying sources to obtain information needed for configuration package creation, including querying an access network for credentials);
copying the one or more configurations ([0018]-[0019], [0237], teaches the configuration server collecting configuration files/credentials for a configuration package and sending them to the device);
replicating the one or more configurations to a target network device ([0019], [0237], explicitly sends a configuration package to the device where the device records/applies it).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 9, Moorthi fails to teach the device wherein executing the disaster recovery process comprises at least: determining a plurality of configurations to replicate; selecting one or more target network devices; and replicating the plurality of configurations to the one or more target network devices.
However, Nix teaches the device wherein executing the disaster recovery process comprises at least:
determining a plurality of configurations to replicate ([0018]-[0019], [0236], teaches collecting a configuration package which includes multiple configuration files/parameters (plurality);
selecting one or more target network devices ([0192]-[0193], [0237], centered around the system preparing/collecting a configuration package for the device (target); and
replicating the plurality of configurations to the one or more target network devices ([0237], device records files and loads the configuration package).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 10, Moorthi fails to teach the device wherein the replication of at least two of the one or more configuration components are done in parallel.
However, Nix teaches the device wherein the replication of at least two of the one or more configuration components are done in parallel ([0192]-[0193], describes the configuration system communicating with several elements/nodes to collect files for the configuration package, which supports obtaining/collecting multiple configuration components in a distributed manner (including parallelized secure session setups and collection).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 11, Moorthi teaches the device wherein the configuration components include at least one of: user defined labels, scopes, inventory filters, agent profiles, agent intents, workspaces, workspace policies, or workspace clusters ([0314], [0318], discusses creating system “profiles” and saving containers including tools/libraries/executables/configurations, which supports the concept of “configuration components” such as profiles and workspace/container policies—system determines dependencies/resources and builds a profile; saving isolation containers for future use; pre-populating with tools/libraries/executables/configurations).
Regarding claim 12, Moorthi teaches the device wherein the configuration components include at least one of: user roles, user accounts, exclusion filters, external orchestrators, client server configurations, forensics profiles and intents, policy templates, collection rules, default application dependency mapping configuration, alert configurations, or connectors ([0203], [0208], [0314], explicitly discloses user accounts and user roles (owner/admin/member/inactive)—user can be member of account; roles including owner/admin/member/inactive—user JSON includes account display name and role; explicitly determines dependencies and applies recursion to determine and manage dependency information (a form of default dependency mapping/config).
Regarding claim 13, Moorthi teaches the device wherein the workload protection logic is further configured to determine a recovery interval ([0344], [0349], supports time-window and scheduling-type logic through its describes use of “time window” and execution timing constructs; indexing by session start/stop time and time-related session tracking; session allowed to start if usage/time conditioned satisfied).
Regarding claim 14, Moorthi teaches the device wherein the recovery interval is dynamically determined ([0344]-[0345], supports dynamic control of system operation based on usage/session timing conditions (i.e. not fixed).
Regarding claim 15, Moorthi teaches the device wherein the dynamic determination is based on an event ([0281]-[0284], teaches event-driven process control via received requests through API endpoints (start/stop/keygen); POST requests trigger start/stop/key generation).
Regarding claim 16, Moorthi teaches the device wherein the event is one of:
receiving a warning notification ([0314], describes warning users when dependencies have known defects/performance problems, which supports warning notifications ties to system status/events; warn user that dependencies have defects/performance problems),
receiving a command to change the recovery interval ([0281]-[0284], supports command/request-driven control via API endpoints, i.e. receiving a “command” through REST calls to initiate/change operations), or
But Moorthi fails to teach determining that one or more connection problems are present.
However, Nix teaches determining that one or more connection problems are present ([0236]-[0237], expressly teaches detecting failure conditions such as failed signature verification or refusing to process a configuration package—these correspond to connection/communication problems or integrity/authentication problems during secure session data transfer).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 17, Moorthi teaches A device, comprising:
a processor ([0195]-[0196], discloses a system architecture involving networked computing services that execute logic (processor/memory) and communicate over a network (network interface); networked system/services supporting request handling via network/API);
at least one network interface controller configured to provide access to a network ([0195]-[0196], discloses a system architecture involving networked computing services that execute logic (processor/memory) and communicate over a network (network interface); networked system/services supporting request handling via network/API); and
a memory communicatively coupled to the processor ([0195]-[0196], discloses a system architecture involving networked computing services that execute logic (processor/memory) and communicate over a network (network interface); networked system/services supporting request handling via network/API), wherein the memory
receive a disaster recovery request ([0281]-[0284], teaches a system receiving API requests that trigger actions (requests to start/stop/keygen)—Hub API receives POST requests such as start/stop/keygen);
But Moorthi fails to teach:
comprises a workload protection logic that is configured to:
establish a connection with a plurality of network devices on the network;
configure identical security certificates on each of the plurality of network devices;
determine at least one target network device;
select a source network device from the plurality of network devices;
replicate one or more configuration components from the source network device; and
apply the one or more configuration components to the target network device.
However, Nix teaches comprises a workload protection logic that is configured to:
establish a connection with a plurality of network devices on the network ([0016]-[0019], [0181], teaches establishing secure sessions between different entities (device [Wingdings font/0xDF][Wingdings font/0xE0] configuration server, mobile phone [Wingdings font/0xDF][Wingdings font/0xE0] configuration server), which is establishing connections among multiple network devices in the system);
configure identical security certificates on each of the plurality of network devices ([0130], [0133], [0232], supports deployment shared/identical trust anchors by describing root certificates recorded by the device and/or shared root certificates across certificate authorities; ;
determine at least one target network device ([0017]-[0019], describes preparing a configuration package for the device (target) based on identity information gathered and stored in a configuration database; identifies list gathered; configuration system records identities and collects a configuration package for the device);
select a source network device from the plurality of network devices ([0190], [0192]-[0193], teaches selecting among possible sources (e.g. preferred access network and/or nodes in the system) and querying them for information/credentials/configuration data);
replicate one or more configuration components from the source network device ([0018], [0217]-[0219], teaches collecting configuration package components and delivering them to the device through a secure session); and
apply the one or more configuration components to the target network device ([0019], [0237], expressly teaches applying the configuration package and using it to update the device).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 18, Moorthi fails to teach the device wherein the disaster recovery request is received in response to an event.
However, Nix teaches the device wherein the disaster recovery request is received in response to an event ([0237], describes situations where applying configuration updates may fail, and the device restores a prior backed-up configuration; this maps well to “disaster recovery” being invoked in response to a failure/adverse condition (i.e. disaster event) – supporting a disaster event as an operational failure/error condition triggering recovery).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 19, Moorthi teaches the device wherein the event is one of:
receiving a warning notification ([00314], teaches warning the user about dependency defects/performance problems), receiving a command to change the recovery interval ([0281]-[0284], supports receiving commands/requests through the API that control system behavior), or
But Moorthi fails to teach determining that one or more connection problems are present.
Nix teaches determining that one or more connection problems are present ([0016], [0236], supports detecting secure session/authentication failures and refusing processing, which correspond to connection/session problems).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Regarding claim 20, Moorthi teaches a method generating an application dependency mapping ([0310]-[0314], explicitly performs dependency analysis from code/configuration files to determine dependencies, and does so recursively (mapping dependencies)), comprising:
receive a disaster recovery request ([0281]-[0284], supports receiving requests via APIs);
But Moorthi fails to teach configure identical security certificates on a plurality of network devices; determine at least one target network device;
select a source network device from the plurality of network devices;
replicate one or more configuration components from the source network device; and
apply the one or more configuration components to the target network device.
However, Nix teaches—
configure identical security certificates on a plurality of network devices ([0133], [0232], supports shared root certificates and certificate-based trust across devices and servers);
determine at least one target network device ([0017]-[0019], supports selecting/configuring a specific device target based on identity information and generating its configuration package);
select a source network device from the plurality of network devices ([0190], [0192]-[0193], supports choosing a preferred access network and querying nodes/elements to obtain data);
replicate one or more configuration components from the source network device ([0018], [0218]-[0219], supports packaging configuration from multiple sources and delivering it to the target device); and
apply the one or more configuration components to the target network device ([0019], [0237], expressly discloses applying configuration files from the configuration package).
One of ordinary skill in the art would have been motivated to combine before the effective filing date of the invention, Moorthi with Nix because both references are directed to secure, network-based management of distributed computing environments and provide complementary teachings that predictably improve workload protection and recovery. Moorthi teaches receiving network requests through APIs, generating/managing a plurality of keys (including API keys), using configuration information to control execution, and executing processes in response to such requests, while Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A skilled artisan would have recognized that incorporating Nix’s certificate-based secure configuration distribution and restoration mechanisms into Moorthi’s request-driven workload protection framework would enhance security, reliability, and disaster recovery functionality across a plurality of network devices (including consistent certificate deployment), with a reasonable expectation of success.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yepez et al (US20100309815A1) discloses network association in an environment with hidden networks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419