DETAILED ACTION
This action is responsive to RCE filed on 05/21/2026, in which claims 1-20 are pending; claims 1, 8, and 15 are amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20, are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1: In the instant case, claims 15-20, are directed to a method, claims 1-7, are directed to a system, and claims 8-14 are directed to a product, therefore the claims are directed to statutory categories of invention.
Step 2A- Prong 1: The independent claims comprise steps of: accessing, by an evidence collector, data for a plurality of services, the evidence collector sharing a trusted environment with the plurality of services, the trusted environment comprising a Kubernetes cluster; filtering the data according to a set of compliance rules; generating, by the evidence collector, an object store; the compliance rules relating to determining whether backups for the plurality of services were successful; and providing, via a network, the object store outside of the trusted environment.
The independent claims are directed to evidence collection for standards compliance, and more specifically, to automated evidence collection within a cloud service. Accordingly, the claimed steps represent a fundamental economic principles or practices (including hedging, insurance, mitigating risk ) which falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping, wherein all the claim steps can be seen as being part of the abstract idea of evidence collection for standards compliance.
In addition, it is noted, accessing data, filtering data, generating an object store and providing the object store outside of the trusted environment, are steps which, but for the use of generic computer components that execute them, are abstract generic functions performed by general-purpose computers. In addition, Kubernetes cluster is being applied to provide trusted environment.
Step 2A- Prong 2: Additional elements include: a system comprising: a memory that stores instructions; and one or more processors coupled to the memory and configured to execute the instructions, an evidence collector; an object store; and a network.
These additional elements are recited at a high level of generality and the steps that they execute: accessing data, filtering data, generating an object store and providing/transmitting the object store, represent generic functions which can be performed by a general purpose computer without any novel programming or improvement in the operation of the computer itself. These additional elements are merely invoked as tools to perform an abstract idea (mere instructions to apply the exception) as discussed in MPEP 2106.05(f). The internet/network features of the invention only represent a particular technological environment, merely a particular technical field of use to which the judicial exception is linked to, and this technological environment is used to merely transmit, receive, store, gather, analyze, make determinations/correlations with, and display data. Accordingly, the additional elements when the claim elements are viewed individually and as a whole do not integrate the abstract idea into a practical application.
Step 2B: Based on the reasoning provided under Step 2A- Prong 2, the claims under Step 2B do not recite “significantly more” than the abstract idea. In addition, there has been no characterization of any additional element representative of insignificant extra-solution activity which needed to be reevaluated under Step 2B. At this point, under the “Certain Methods of Organizing Human Activity” grouping scenario where all the claim steps can be seen as being part of the abstract ideas, , the analysis is terminated because the same analysis with respect to Step 2A Prong 2 applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B
The dependent claims have been considered.
Dependent claims 2, 9, 16, recite the additional element of an API, and merely narrows the abstract idea of accessing the data using REST API.
Dependent claims 4-5, 7, 11-12, 14, 18, merely narrow the abstract idea of filtering the data according to a set of compliance rules using a REST API.
Dependent claims 3, 10, 17, add limits to generating an object store.
Dependent claims 6, 13, 20, add limits to the rules.
These limitations only limit the application of the idea, and do not add significantly more than the idea. When considered as a whole, the same analysis with respect to Step 2A Prong 2 and step 2B, apply to these additional elements. They cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
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.
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, 7-8, 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Wells et al. (US 2021/0295234) (hereinafter “Wells5234”) in view of Dou et al. (CN 109885389 A) and further in view of Bindal et al. (US 20120102088 A1)
Regarding claims 1, 8, 15, Wells5234 discloses:
(execute the instructions to perform operations). Compliance server system 110 executing automated evidence collection instructions (see at least Wells5234, fig. 1, ¶30-34).
(system comprising: a memory that stores instructions; and one or more processors coupled to the memory and configured to execute the instructions). (see at least Wells5234, fig. 1, ¶30-34)
(accessing, by an evidence collector, data for a plurality of services, the evidence collector sharing a trusted environment with the plurality of services).
Techniques are provided for automated evidence collection. A first standard is processed to generate first collection instructions that, when executed, obtain evidence data corresponding to a first plurality of evidence types from cloud environments deployed at a cloud service provider system. A request is received to perform an audit operation, related to the first standard and a first cloud environment deployed at the cloud service provider system. First selected instructions are determined that are associated with at least one evidence type associated with the audit operation. The first selected instructions are executed to obtain first evidence data on the first cloud environment from the cloud service provider system. An audit result is determined based on the first evidence data. (see at least Wells5234, abstract)
[0027] In some embodiments, the compliance server system accesses one or more customer environments to generate a compliance report. For example, the compliance server system may generate one or more portions of a compliance report that describes an entity's compliance with a particular standard. Alternatively and/or in addition, the compliance server system may present evidence data related to an audit. In some embodiments, the compliance server system provides an auditor interface to present a compliance report and/or relevant evidence data to a third party, such as an auditor. (see at least Wells5234, ¶27)
(generating, by the evidence collector, an object store by filtering the data according to a set of compliance rules). The compliance server system 110 may implement one or more “standards”, also referred to as “a set of one or more rules” (see at least Wells5234, fig. 1, ¶38-43).
(providing, via a network, the object store outside of the trusted environment).
The compliance server system 110 may store evidence data (objects) for one or more customers in an evidence database 116 (object store). For example, the evidence collection module 106 may store evidence data obtained from customer environments 122 and other sources in the evidence database 116. (see at least Wells5234, fig. 1, ¶86-87, 121). Evidence object (see at least Wells5234, fig. 4B, ¶86-87, 104-109).
The compliance server system 110 may generate an audit result after collecting evidence data (see at least Wells5234, fig. 4A-4B, ¶113). The reporting instructions may generate a report for internal use in an organization (see at least Wells5234, ¶115). Alternatively and/or in addition, the reporting instructions may generate a report for an auditor, a client of the customer, or another party (providing, via a network, the object store outside of the trusted environment) (see at least Wells5234, ¶27, 116).
However, does not explicitly teaches the trusted environment comprising a Kubernetes cluster; the compliance rules relating to determining whether backups for the plurality of services were successful.
Dou teaches the trusted environment comprising a Kubernetes cluster (Pg. 7, “the container cluster management is used for using Kubernetes (K8S) to arrange the container and manage the cluster; Kubernetes node is a set of one or more containers, sharing storage and network and managing life cycle; the content of the Kubernetes node is always located at the same position and cooperative scheduling, and sharing the operation state in the context; all containerized core service is executed as the K8S; the service is abstracted through the K8S; the DL operation and state are deployed.”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to implement Kubernetes cluster as taught by Dou into Wells5234.
One would be motivated to do so to sharing resources and managing life cycle. (See, Pg. 7)
However, Wells5234 as modified by Dou does not explicitly teach the compliance rules relating to determining whether backups for the plurality of services were successful.
Bindal teaches y Dou does not explicitly teach the compliance rules relating to determining whether backups for the plurality of services were successful (“[0005] The degree of compliance with a backup policy indicates how closely the client is to complying with a backup policy. For example, a policy may indicate that each client is to be backed up once per day and the degree of compliance may indicate how many days it has been since the client has performed a successful backup operation. A backup policy may also indicate a threshold low level of policy compliance that will indicate that a client is out of compliance and trigger specified acts. For example, a client may attempt to trigger a backup outside the backup window if it has been seven days or more since the client successfully backed up. Many other backup policies can be used, such as policies with different time periods between backups (backing up once per hour, backing up once per week, backing up at different variable backup periods, backing up upon specified events (e.g., when a logoff event occurs), etc.), different out-of-compliance thresholds, no out-of-compliance thresholds, etc.”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention (AIA ) to implement backup compliance policy as taught by Bindal into Wells5234 as modified by Dou.
One would be motivated to do so to indicate how closely the client is is complying with the backup policy. (See, Para 0005)
Regarding claims 7, 14, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
As explained in the rejection of the parent claims, Wells5234 teaches that evidence data is stored in evidence database 116 (object store) (see at least Wells5234, fig. 1, ¶86-87, 121), and the compliance server system 110 may generate an audit result after collecting evidence data (see at least Wells5234, fig. 4A-4B, ¶113); and the reporting instructions may generate a report for an auditor, a client of the customer, or another party (providing, via a network, the object store outside of the trusted environment) (see at least Wells5234, ¶27, 116).
Since data stored in evidence database 116 is evidence data (object store), then by virtue of being proof of evidence, it is filtered data Accordingly, only filtered evidence data is available for retrieval from the DB, and therefore unfiltered data is “being prevented” from being provided outside of the trusted environment.
Claims 2-4, 9-11, 16-18, are rejected under 35 U.S.C. 103 as being unpatentable over Wells5234 as modified by Dou and Bindal and further in view of Joyce et al. (US 2021/0042207) (hereinafter “Joyce2207”).
Regarding claims 2, 9, 16, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
Wells5234 discloses: APIs including REST API (see at least Wells5234, ¶47). APIs in association with implementation an evidence collection system architecture (see at least Wells5234, ¶85), but does not specifically disclose: (wherein the accessing of the data for the plurality of services is via a representational state transfer (REST) application programming interface (API)).
However, Joyce2207 discloses: A distributed API architecture which can be validated and developed in a continuous integration environment which implements a system integration testing (SIT) tool which according to an exemplary embodiment of the disclosure is configured to perform API security validation testing. The system 100 comprises a client computing device 110, a communications network 120, and a cloud computing platform 130. (see at least Joyce2207, fig. 1, ¶13-15).
Cloud computing systems typically implement a Representational State Transfer (REST) API (see Joyce2207, ¶3). REST API implementation (see at least Joyce2207, fig. 1, ¶21, 28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wells5234 as modified by Dou with the REST API implementation of Joyce2207, to gain the known benefits of a set of recommendations for designing loosely coupled applications that use the HTTP protocol for data transmission (see Joyce2207, ¶3).
Examiner Note: The examiner have kept the previous rejection to stay consistent with previous office action; however alternatively Dou reference also teaches use of REST API (see, Pg. 7). The rational would be same as cited with regard to claim 1.
Regarding claims 3, 10, 17, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
Wells5234 discloses: Audit request (see at least Wells5234, fig. 4A, ¶103), but does not specifically disclose: (receiving, via a representational state transfer (REST) application programming interface (API), a request for the object store).
However, as explained, the Wells523/Joyce2207 combination formulated in the rejection of claim 2 (not repeated here) teaches: REST APIs. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Wells523 with Joyce2207 to execute audit requests using REST APIs, to continue gaining the known benefits of REST APIs, of a set of recommendations for designing loosely coupled applications that use the HTTP protocol for data transmission (see Joyce2207, ¶3).
Regarding claims 4, 11, 18, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
It could be argued that the deployment of the evidence collection architecture in Wells5234, in association with using APIs, may not specifically disclose: (deploying the evidence collector in accordance with production software deployment requirements); however, Joyce2207 teaches this limitation.
Joyce2207 discloses: Automation tests for a REST API (see at least Joyce2207, fig. 3, ¶39). API security validation testing (see at least Joyce2207, fig. 3-4, ¶51).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Wells523 with Joyce2207 to implement testing associated with production software deployment requirements, to ensure smooth transition from a development environment to a production environment.
Claims 5, 12, 19, are rejected under 35 U.S.C. 103 as being unpatentable over Wells et al. (US 2021/0295234) (hereinafter “Wells5234”) as modified by Dou and Bindal in view of Tang et al. (CN 110445756).
Examiner’s note: For the purpose of examining the instant claims, an Espacenet English machine-translation of Tang et al. (CN 110445756) (hereinafter “Tang5756”) is used.
Regarding claims 5, 12, 19, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
Wells5234 does not disclose: (wherein the filtering of the data comprises identifying lines of log files that contain a key word), however Tang5756 teaches this limitation.
Tang5756 discloses: Methodology for keyword search of audit logs in a cloud service storage. Searchable encrypted audit log technology comprising: generating and encrypting the audit logs to be uploaded to the cloud server in a specific way. When conducting a search, users upload a "trapdoor"—a key to their search terms—to the cloud server, which is created by encrypting the keywords (identifying lines of log files that contain a key word) using searchable encrypted audit log technology. The cloud server then uses the search algorithm based on this trapdoor to perform a matching search and finally returns the search results. Users only need to download the corresponding file based on the search results and then decrypt it locally, without having to download extra data, thus saving users communication and computing costs. (see at least Tang5756, ¶8, 24-35).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify filtering the data for the generation of an object store in Wells5234 as modified by Dou, based on keyword filtering as taught by Tang5756, since keywords can be a rich source of evidence data for the purpose of making an evidence collection determination.
Claims 6, 13, 20, are rejected under 35 U.S.C. 103 as being unpatentable over Wells et al. (US 2021/0295234) (hereinafter “Wells5234”) as modified by Dou and Bindal in view of Maeser et al. (US 20200327434) (hereinafter “Maeser7434”).
Regarding claims 6, 13, 20, Wells5234 as modified by Dou and Bindal discloses: All the limitations of the corresponding parent claims (claims 1 and 9; claim 15; and claims 25 and 30; respectively) as per the above rejection statements.
Wells5234 teaches: Service Organization Control 2 (SOC 2) standard (see at least Wells5234, ¶24).
Wells5234 does not disclose: (wherein the compliance rules comprise rules for compliance with an International Standards Organization (ISO) standard).
However, Maeser7434 discloses:
System and method for calculating cloud service provider (CSP) trustworthiness levels based on quantitative and qualitative analysis and measurements of CSP capabilities, and historical CSP cloud service level agreement (SLA) and cloud computing service performance, and for analyzing and applying the measurements and CSP trustworthiness level against cloud industry SLA standards to predict cloud computing service performance and cloud SLA availability. (see at least Maeser7434, ¶2).
Exemplary embodiments of the present invention provide a system to model and evaluate a CSP with respect to a broad set of criteria, including cloud computing service level agreements (SLAs) between the (cloud service customer) CSC and CSP, CSP cloud capabilities including cloud services and cloud security, and CSP compliance against industry cloud SLAs standards (e.g. from standards bodies such as ISO/IEC, EC, ENISA) (ISO standard) and cloud security standards (e.g. CSA CCM, CAIQ). (see at least Maeser7434, ¶23).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Wells5234 as modified by Dou with Maeser7434 to implement ISO testing, since this would be a simple substitution of one known standard element (i.e. the ISO standard in Whitton8236) for another (i.e. the SOC 2 of Wells5234) to obtain the predictable result of complying with industry standards.
Response to Arguments
Regarding prior art, Applicant’s arguments with respect to claims 1-20 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.
Regarding 35 U.S.C 101, Applicant's arguments filed on 05/21/2026 have been fully considered but they are not persuasive.
Applicant argues, “the claimed operations (accessing log data from services executing within a Kubernetes cluster, filtering that data based on backup-success compliance rules, generating an object store, and providing the object store outside the trusted environment) are not a fundamental economic practice such as hedging, insurance, or risk mitigation. The recited operations are computer-implemented data collection and filtering operations performed by a software component (the evidence collector) co-located with the monitored services in a container orchestration environment. These operations are not practices that humans have traditionally performed to organize commercial activity.” (Pg. 1)
The examiner respectfully disagree. The certain method of organizing human activity can include:
fundamental economic principles or practices (including hedging, insurance, mitigating risk)
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)
managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)
Here, “evidence collection for standards compliance” falls at least within business relations, agreement in the form of contracts, legal obligations etc.… Here the rules are being used to determine the compliance, for example “the compliance rules relating to determining whether backups for the plurality of services were successful.” The technology being used for collection, environment, etc.… is merely applying the technical environment to the abstract idea. The claims, and specification makes it very clear that standard technological environment is being used, without providing any technical details related to the improvement. For example, the trusted environment is being provided using Kubernetes cluster. Further para 0034 states “The evidence collector 140 generates, in operation 420, an object store by filtering the data according to a set of compliance rules. The set of compliance rules may include rules for compliance with an International Standards Organization (ISO) standard, a Security Operations Center (SOC) standard, a British Standards Institution (BSI) standard, a Compliance, Safety, Accountability (CSA) standard, or any suitable combination thereof.”
Applicant argues “Moreover, the claimed operations cannot practically be performed in the human mind or by humans using pen and paper. The claims require an evidence collector co-resident with a plurality of services inside a Kubernetes cluster, which is a container-orchestration construct that has no analog outside of computer networking. Accessing service logs within such a cluster, filtering log entries to determine backup success, and exporting the filtered data across a network boundary to an object store located outside the trusted environment are operations rooted in distributed computing architecture.” (Pg. 2)
The examiner have rejected the claim under organizing human activity; however, one could make a case that claims also fall under mental process, as rules can be written using pen on paper, and the conformity to the rules can be determines by analyzing the evidence. The examiner agree, the evidence collections, and environment are technical aspects; however, that is merely applying the cloud environment to implement the abstract idea of evidence collection for standard compliance, more specifically Kubernetes cluster environment.
Applicant argues “Even assuming that the claims recite an abstract idea, the claims integrate any such idea into a practical application by reciting a particular arrangement of computing components that addresses a problem arising in cloud-service auditing.
As the specification explains, conventional auditing of cloud services is performed by
external tools that require extending access to production cloud resources to additional audit users, which presents "a security and stability risk". The claimed arrangement addresses this problem by deploying the evidence collector within the same trusted environment as the services being audited, so that the evidence collector obtains data using the access already granted to in-cluster components. Only the filtered output is exposed outside the trusted environment via the object store. The specification states that this arrangement transfers less data across the network and enhances data control because "only the filtered data in the object store 150 is made accessible outside of the data center 110." (pg. 2)
There are two aspects in the above argument, first providing data outside the trusted environment, which is being done by accessing Kubernetes cluster environment; as mentioned with regard to above arguments, this is merely applying Kubernetes cluster, and accessing the data over the network. The second aspect is filtering only data in the object store; here filtering the data is user design choice rather than technical improvement.
Applicant argues, “The amended claims further recite that the compliance rules relate to determining whether backups for the plurality of services were successful. This limitation, read together with the in- cluster evidence collector and the export of a filtered object store, defines a specific technical arrangement for producing backup-verification evidence from service logs generated inside a Kubernetes cluster, and making only that filtered evidence available outside the trusted environment. Figures 1 and 3 depict this arrangement: the evidence collector 140 resides in the data center 110 alongside the services 130A, 130B and their logs 135A, 135B, and writes filtered backup results (tables 310, 320 of FIG. 3) to the object store 150, which is then accessible via network 190.” (pg. 3)
The amended language makes it further clear that claimed limitation and claim as whole is an abstract idea. Para 0034 of the instant specification recites “The evidence collector 140 generates, in operation 420, an object store by filtering the data according to a set of compliance rules. The set of compliance rules may include rules for compliance with an International Standards Organization (ISO) standard, a Security Operations Center (SOC) standard, a British Standards Institution (BSI) standard, a Compliance, Safety, Accountability (CSA) standard, or any suitable combination thereof.” Thus, standards are being used to determine the compliance.
Applicant argues “For the reasons above, the claims recite a non-conventional and non-generic arrangement of components. The combination of (a) an evidence collector sharing a Kubernetes cluster with the services it audits, (b) filtering of service-log data according to backup-success compliance rules to generate an object store, and (c) exposing that object store outside the trusted environment via a network is not a well-understood, routine, or conventional activity. The cited art, including Wells, describes compliance evidence collection generally, but the Office Action relies on a secondary reference (Dou) to supply the Kubernetes-cluster trusted environment, which itself demonstrates that the specific claimed arrangement is not a conventional baseline.” (Pg. 3)
To the contrary the claim makes it clear that trusted environment is Kubernetes environment, and the secondary reference teaches that use of K8s is conventional technique. Please see Wikipedia related to Kubernetes, that provides history of Kubernetes, and how it can provide the configures environment to provide control plane and nodes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20250200630 A1: “……The generative AI KG engine supports generating the knowledge graph using a generative AI model (e.g., an LLM). In operation, a seed product is accessed in a product listing system. Using a product knowledge graph, a plurality of candidate products associated with the seed product are identified. The product knowledge graph comprises a plurality of products as nodes and a plurality of relationships as edges…... Using a ranker of the product listing system, a plurality of recommended products are identified. The plurality of recommended products are a subset of the plurality of candidate products. The plurality of recommended products are communicated and caused to be generated on a graphical user interface.” (See, Abstract)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WASEEM ASHRAF whose telephone number is (571)270-3948. The examiner can normally be reached Monday-Friday 09:30 A.M-06:00 P.M.
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, Tariq Hafiz can be reached at 571-272-5350. 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.
/WASEEM ASHRAF/Supervisory Patent Examiner, Art Unit 3621
Prosecution Insights