Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Response to Arguments
Applicant’s arguments with respect to independent claim(s) 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 § 112
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claim limitation 1-7 has/have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder: server, object storage, assembly service, CSDCS, blueprint, parameters, deployer service, coupled with functional language without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier. Since the claim limitation(s) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claim 13 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification, Fig. 6 [0072] shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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 1, 8, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baryshnikov (Pub. No. US 2018/0075009) in view of Nagaraja (Pat. No. US 9,146,721) in further view of Tidd (Pat. No. US 11,609,747).
Claim 1, 8, 14 Baryshnikov teaches “a cloud architecture, comprising: one or more servers configured to implement: a user computing environment ([Fig. 2, 222] customer account); at least one object storage configured to store a plurality of assets that are deployable in the user computing environment ([Fig. 2, 202] templates 212n); and an assembly service configured to: receive a query for at least one asset of the plurality of assets; return information associated with the at least one asset responsive to the query ([0032] A template, such as template 212.sub.1 may also declare that certain information, such as resource deployment settings, cloud service deployment settings, or the like, should be obtained from the customer during the deployment process. Accordingly, a deployment service that is utilized to manage the deployment process may present a UI for obtaining such information from the customer as part of the deployment process. Content of the UI and/or the information to be obtained via the UI may be specified by the vendor via a file (or other suitable container) that may be published along with a template and packaged therewith.); receive a deployment blueprint that defines a deployment of the at least one asset in the user computing environment and at least one executable script for deploying the at least one asset, the deployment blueprint defined based on the information provided ([0029] FIG. 2 is a block diagram that illustrates the use of templates to deploy a cloud service within cloud services platform 100. A template comprises a file (or other suitable container) that includes information that describes how a cloud service should be deployed within cloud services platform 100. For example, the template may specify resources of cloud services platform 100 that must be allocated in support of a given cloud service and how such resources should be configured. [0030] As shown in FIG. 2, a cloud service vendor can utilize its own vendor computing system 204 to publish a template 212.sub.1 to an online marketplace 202, wherein such template 212.sub.1 provides information necessary for a customer to deploy the vendor's cloud service to the customer's own account (i.e., to the customer's own set of resources) within cloud services platform 100. Template 212.sub.1 may be made available along with a variety of other templates 212.sub.2-212.sub.n for consumption by one or more customers of cloud services. Each template made available in online marketplace 202 may be published by a variety of different cloud service vendors, by a proprietor of cloud services platform 100, or by other entities. Online marketplace 202 may offer hundreds or even thousands of templates. In one implementation, online marketplace 202 comprises the Microsoft® Azure® Marketplace, a Web site published by Microsoft Corporation of Redmond, Wash., although this is only an example. [0031] Template 212.sub.1 includes information necessary to deploy a vendor's cloud service offering within the customer's account. For example, if the vendor's cloud service is a PaaS or SaaS application, template 212.sub.1 may declare that a certain number of virtual machines, storage accounts, databases, network connections, and/or the like, each having a specified configuration, must first be allocated within the customer's account by customer services platform 100 before deploying the PaaS/SaaS application. Template 212.sub.1 may further declare that after such resources have been allocated, that certain specified code (i.e. executable script) comprising the PaaS/SaaS application should be downloaded and installed on one or more of the resources (e.g., one or more virtual machines). Thus, templates may provide for a staged deployment of the cloud service, with certain deployment steps being dependent on the successful execution of certain previous deployment steps.); and store the deployment blueprint in the at least one object storage ([Fig. 2, 202] template 212_1)”.
However, Baryshnikov may not explicitly teach details of a template comprising a link.
Nagaraja teaches “a deployment blueprint that …includes a link to the at least one executable script ([Col. 3, Lines 39-61] To streamline the process of configuring and provisioning VMs 114 and other types of virtual resources, IaaS manager 104 may generate and store various templates that define configuration parameters to be used to instantiate virtual resources in a cloud. Each template may include a copy of a VM 114 that has, for example, certain processor capabilities, memory and storage sizes, network resources, and the like. Templates may further include preinstalled application components that are executed once a VM 114 has been provisioned. For example, a template may include or reference (i.e. link) an IaaS agent (i.e. script) that is to be installed and executed to communicate with IaaS manager 104 once a VM 114 has been instantiated and provisioned, enabling the IaaS agent to receive instructions, a hostname, binaries, etc. from IaaS manager 104. For example, once a VM 114 has been instantiated and IaaS agent has been installed, IaaS agent may communicate with IaaS manager 104 in order to receive a series of tasks specific to the receiving VM 114. The tasks may include scripts that are executed by VMs 114 to install, configure, and/or start one or more application components. For example, a task may be a script that, when executed by a VM 114, causes VM 114 to retrieve and install certain software packages from a central package repository 134.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Nagaraja with the teachings of Baryshnikov in order to provide a system that teaches details of a template. The motivation for applying Nagaraja teaching with Baryshnikov teaching is to provide a system that allows for design choice. Baryshnikov, Nagaraja are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Nagaraja with the teachings of Baryshnikov by known methods before the effective filing date of the claimed invention and gained expected results.
However, the combination may not explicitly teach the new limitations.
Tidd teaches “test the at least one executable script ([Col. 3, Lines 47-49] These code libraries 130 may contain independent units of application functionality and may, in some embodiments, contain executable code.); and update a state of the deployment blueprint as ready to deploy and the link of the at least one executable script ([Col. 5, Lines 4-10] (26) The agent may then use the identified, or newly created, refined manifest 124 to generate the application 120. The various libraries 130 may provide code entry-points conforming to known library interfaces, in some embodiments. The agent may use the provided code entry-points of the various libraries to resolve code references between the various libraries to create the application 120.), wherein the deployment blueprint is in a production environment when the state is ready to deploy ([Col. 15, Lines 45-61] (73) After the application has passed integration testing, the development and deployment process may the proceed in some embodiments to an initial production cell A 530 where the application may be deployed at cell A, as shown in 531, the application platform notified of the deployment 533, and integration tests performed 534. In this illustration, only ten percent of production traffic may be handled by production cell A, in some embodiments. (74) After the application has passed initial production testing, the development and deployment process may the proceed in some embodiments to a full production deployment at production cell B 540 where the application may be deployed at cell Bl, as shown in 541, the application platform notified of the deployment 543, and integration tests performed 544. In this illustration, ninety percent of production traffic may be handled by production cell A, in some embodiments.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Tidd with the teachings of Baryshnikov, Nagaraja in order to provide a system that teaches details of application deployment. The motivation for applying Tidd teaching with Baryshnikov, Nagaraja teaching is to provide a system that allows for improved testing. Baryshnikov, Nagaraja, Tidd are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja, Tidd teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Tidd with the teachings of Baryshnikov, Nagaraja by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 2, 3, 4, 5, 9, 10, 11, 15, 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baryshnikov, Nagaraja, Tidd, in further view of Nasu (Pub. No. US 2020/0264847).
Claim 2, 9, 15 the combination teaches the claim, wherein Baryshnikov teaches “the cloud architecture of claim 1, wherein: the one or more servers are further configured to implement receive, from the user, a request to invoke the deployment blueprint; and request that the deployer service deploy the at least one asset in the user computing environment of the user based on the deployment blueprint and the at least one executable script, wherein the deployer service is configured to deploy the at least one asset in the user computing environment in response to the request ([0029] FIG. 2 is a block diagram that illustrates the use of templates to deploy a cloud service within cloud services platform 100. A template comprises a file (or other suitable container) that includes information that describes how a cloud service should be deployed within cloud services platform 100. For example, the template may specify resources of cloud services platform 100 that must be allocated in support of a given cloud service and how such resources should be configured. [0030] As shown in FIG. 2, a cloud service vendor can utilize its own vendor computing system 204 to publish a template 212.sub.1 to an online marketplace 202, wherein such template 212.sub.1 provides information necessary for a customer to deploy the vendor's cloud service to the customer's own account (i.e., to the customer's own set of resources) within cloud services platform 100. Template 212.sub.1 may be made available along with a variety of other templates 212.sub.2-212.sub.n for consumption by one or more customers of cloud services. Each template made available in online marketplace 202 may be published by a variety of different cloud service vendors, by a proprietor of cloud services platform 100, or by other entities. Online marketplace 202 may offer hundreds or even thousands of templates. In one implementation, online marketplace 202 comprises the Microsoft® Azure® Marketplace, a Web site published by Microsoft Corporation of Redmond, Wash., although this is only an example. [0031] Template 212.sub.1 includes information necessary to deploy a vendor's cloud service offering within the customer's account. For example, if the vendor's cloud service is a PaaS or SaaS application, template 212.sub.1 may declare that a certain number of virtual machines, storage accounts, databases, network connections, and/or the like, each having a specified configuration, must first be allocated within the customer's account by customer services platform 100 before deploying the PaaS/SaaS application. Template 212.sub.1 may further declare that after such resources have been allocated, that certain specified code (i.e. executable script) comprising the PaaS/SaaS application should be downloaded and installed on one or more of the resources (e.g., one or more virtual machines). Thus, templates may provide for a staged deployment of the cloud service, with certain deployment steps being dependent on the successful execution of certain previous deployment steps.)”.
However, the combination may not explicitly teach the remaining limitations.
Nasu teaches “a common schema and data catalog services (CSDCS); and a deployer service, wherein the CSDCS is configured to: receive, from a user, a search request for the at least one asset; return, to the user in response to the search request, information regarding the at least one asset and the deployment blueprint ([0095] A flow template manager GUI 301A exemplarily illustrated in FIG. 3A is an exemplary screen that displays a flow template list to receive, from the user, selection of a flow template desired by the user. When the user 101 clicks a flow template 3011 (for example, an icon indicating a flow template 1) on the GUI 301A, a flow template manager GUI 301B exemplarily illustrated in FIG. 3B opens. The click on the flow template 3011 is an exemplary flow template selection. [0096] The flow template manager GUI 301B is an exemplary screen for receiving, from the user, an instruction to execute flow template information acquisition and flow data download. The user 101 can understand that a flow illustrated by a flow image 3025 displayed on the screen of a flow tab 3021 on the GUI 301B is a flow indicated by the selected flow template. In addition, the user 101 can acquire contents such as detail information and a document related to the selected flow template from a screen displayed upon selection of a description tab 3022 or selection of a relevant material tab 3023. When the user 101 clicks a download button 3024, a flow template manager GUI 301C exemplarily illustrated in FIG. 3C opens.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Nasu with the teachings of Baryshnikov, Nagaraja, Tidd in order to provide a system that teaches details of browsing a marketplace. The motivation for applying Nasu teaching with Baryshnikov, Nagaraja, Tidd teaching is to provide a system that allows for design choice. Baryshnikov, Nagaraja, Tidd, Nasu are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja, Tidd, Nasu teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Nasu with the teachings of Baryshnikov, Nagaraja, Tidd by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 3, 10, 16 the combination teaches the claim, wherein Nasu teaches “the cloud architecture of claim 2, wherein: the CSDCS in further configured, in response to the request to invoke the deployment blueprint, to: query the at least one object storage for asset parameters associated with the at least one asset; and request that the deployer service deploy the at least one asset in the user computing environment based on the asset parameters ([0096] When the user 101 clicks a download button 3024, a flow template manager GUI 301C exemplarily illustrated in FIG. 3C opens. [0097] The flow template manager GUI 301C is an exemplary screen for specifying flow repository information as the download destination of flow data of the flow template, specifying flow editor information, and receiving an external-service deployment execution instruction from the user. The user 101 can use the GUI 301 to input (or browse) the URL of a flow repository, a project name, a user name, and a password through UIs 3031 to 3034 related to the flow repository manager 400, and to input (or browse), through UIs 3035 and 3036 related to the visual programming tool 40, the URL of the flow editor 41 and an access token as authorization for the flow template manager 300 to perform an operation to download flow data to the flow editor 41. When the user 101 clicks a deployment button 3037 for external-service deployment, a flow template manager GUI 301D exemplarily illustrated in FIG. 3D opens.)”.
Rationale to claim 2 is applied here.
Claim 4, 11, 17 the combination teaches the claim, wherein Nasu teaches “the cloud architecture of claim 3, wherein: the CSDCS is further configured, in response to the query for the asset parameters, to: display the asset parameters to the user; receive, from the user, an update to the asset parameters; and request that the deployer service deploy the at least one asset in the user computing environment based on the update to the asset parameters ([0096] When the user 101 clicks a download button 3024, a flow template manager GUI 301C exemplarily illustrated in FIG. 3C opens. [0097] The flow template manager GUI 301C is an exemplary screen for specifying flow repository information as the download destination of flow data of the flow template, specifying flow editor information, and receiving an external-service deployment execution instruction from the user. The user 101 can use the GUI 301 to input (or browse) the URL of a flow repository, a project name, a user name, and a password through UIs 3031 to 3034 related to the flow repository manager 400, and to input (or browse), through UIs 3035 and 3036 related to the visual programming tool 40, the URL of the flow editor 41 and an access token as authorization for the flow template manager 300 to perform an operation to download flow data to the flow editor 41. When the user 101 clicks a deployment button 3037 for external-service deployment, a flow template manager GUI 301D exemplarily illustrated in FIG. 3D opens.)”.
Rationale to claim 2 is applied here.
Claim 5, the combination may not explicitly teach the limitation.
Nasu teaches “the cloud architecture of claim 1, wherein: the at least one asset comprises at least two assets, the deployment blueprint references one or more deployment parameters for the at least two assets, and the deployment parameters define an order of deploying the at least two assets in the user computing environment ([0091] The user 101 can drag and drop a node 2012 in the flow from the pallet area 2019 to the edition area 2017 so that the node becomes usable (editable) on the edition area 2017. The user 101 can define a node processing request by performing a mouse operation, a touch operation, or the like to connect the nodes 2012 with each other through a line 2013. When processing at a certain node 2012 ends, processing at another node 2012 connected with the certain node 2012 through the line 2013 starting at the certain node 2012 is subsequently executed. [0092] When the user 101 double-clicks a node 2012, a node property set screen 2014 on which the property of the node 2012 is set opens. The node property set screen 2014 allows setting of a property value necessary for processing at the node 2012. For example, a URL as the end point of an external service can be set through a user interface (UI) 2015 of the screen 2014 to the property of the invoke node B for invoking the external service, and a header that sets authentication token information of the external service can be set through a UI 2016 of the screen 2014. In the present embodiment, a “UI” of a GUI is a GUI component such as a text box or a pull-down menu. According to the present embodiment, as described above, a URL as an exemplary invocation destination end point and a header as exemplary authentication information are already set to the property of an invoke node in flow data downloaded to the flow editor 41.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Nasu with the teachings of Baryshnikov, Nagaraja, Tidd in order to provide a system that teaches details of asset deployment. The motivation for applying Nasu teaching with Baryshnikov, Nagaraja, Tidd teaching is to provide a system that allows for design choice. Baryshnikov, Nagaraja, Tidd, Nasu are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja, Tidd, Nasu teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Nasu with the teachings of Baryshnikov, Nagaraja, Tidd by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 6, 7, 12, 13, 18, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baryshnikov, Nagaraja, Tidd in further view of Jiang (Pub. No. US 2021/0064417).
Claim 6, 12, 18 the combination may not explicitly teach the limitation.
Jiang teaches “the cloud architecture of claim 1, wherein: the deployment blueprint further includes a state indicator, and the assembly service is further configured to: update the state indicator to indicate that the deployment blueprint is not ready for release to users of the cloud architecture ([0059] If the artifact validation is not successful, the artifact validation module 120 determines reasons for unsuccessful validation of the artifact. The artifact validation module 120 determines whether the issues in the artifact may be resolved automatically. In such a case, the artifact validation module 120 performs corrective actions on the artifact using a machine learning model. The machine learning model is pre-trained to resolve issues in the artifact if the validation of the artifact is unsuccessful. The artifact validation module 120 performs a validation check(s) that was unsuccessful on the modified artifact. [0060] If the issues cannot be resolved, then the artifact validation module 120 sends a second notification to the artifact development module 118 indicating the reasons for unsuccessful validation of the artifact. The developer may fix the issues in the artifact based on the second notification using the development environment and store the updated version of the artifact in the artifact repository 128. Accordingly, the artifact validation module 120 performs validation of new version of the artifact.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Jiang with the teachings of Baryshnikov, Nagaraja, Tidd in order to provide a system that teaches details of status of templates. The motivation for applying Jiang teaching with Baryshnikov, Nagaraja, Tidd teaching is to provide a system that allows for design choice. Baryshnikov, Nagaraja, Tidd, Jiang are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja, Tidd, Jiang teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Jiang with the teachings of Baryshnikov, Nagaraja, Tidd by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 7, 13, 19, the combination teaches the limitation, wherein Jiang teaches “the cloud architecture of claim 6, wherein: the assembly service is further configured to: receive approval to release the deployment blueprint to production; and update the state indicator to indicate that the deployment blueprint is ready for release to the users in response to the approval ([0058] The artifact validation module 120 performs validation of the artifact using the determined validation checks. The artifact validation module 120 signs the artifact using an artifact signature (e.g., hash key) and stores the artifact signature associated with the artifact in the artifact repository 128. In certain embodiments, the artifact validation module signs the artifact using checksum or certificate. Also, the artifact validation module 120 sends a first notification to the artifact development module 118 indicating the artifact validation is successfully performed.)”.
Rationale to claim 6 is applied here.
Claim/s 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baryshnikov, Nagaraja, Tidd in further view of Mathon (Pub. No. US 2020/0387357).
Claim 20, the combination may not explicitly teach the claim.
Mathon teaches “the non-transitory computer-readable medium of claim 14, wherein: the at least one executable script comprises at least one terraform script ([0072] 5. Source code of automation scripts created in Shell, Terraform, Chef, and other infrastructure configuration languages, as well as references to external files containing automation scripts.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Mathon with the teachings of Baryshnikov, Nagaraja, Tidd in order to provide a system that teaches details of scripts. The motivation for applying Mathon teaching with Baryshnikov, Nagaraj, Tidd a teaching is to provide a system that allows for design choice. Baryshnikov, Nagaraja, Tidd, Mathon are analogous art directed towards software deployment. Together Baryshnikov, Nagaraja, Tidd, Mathon teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Mathon with the teachings of Baryshnikov, Nagaraja, Tidd by known methods before the effective filing date of the claimed invention and gained expected results.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
Prosecution Insights