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 .
Claims 1-4, 6-14, 16-19 are amended and pending in this office action.
Claims 5, 15 and 20 are cancelled.
Response to Arguments
Applicant's arguments filed 02/09/2026 have been fully considered but they are not persuasive.
Applicant’s argument:
Avisror's software artifacts refer to files in the form of a computer readable program code that can provide a software application. See Avisror at paragraph [0026]. According to Avisror, source code files can be converted into software artifacts and deployed to a computing system during a software build. Id. However, while Avisror identifies modified software artifacts of respective builds and tracks those modified software artifacts using a build tracker (see id. at paragraph [0025]), Avisror has not been shown to teach or suggest "obtaining metadata of [a] subset of changed source code files," "in response to a change to a subset of source code files." Avisror's alarm or flag is to suggest prioritization in testing, and is not for obtaining metadata, as claimed. see id. at paragraph [0072]. Also, Avisror tracks modification of the converted code files into software artifacts and identifies changes or modifications relative to a previous build combination. See id. at paragraph [0061]. Avisror's comparison is a version comparison of retrieved build combinations, and version information of build combinations is not "metadata of [a] subset of changed source code files," that is obtained in response to "a change," as required by the language of claim 1.
Examiner response:
The issue in the argument is that Avisor does not teach metadata of files(name, identifier, associated comment, developer…) and cannot retrieve metadata from repository, but applicant’s representative acknowledged that Avisor” identifies modified software artifacts of respective builds and tracks those modified software artifacts using a build tracker”;
Avisror discloses a repository for source code files:
[0043] “The build management system may further include a source control engine 278 that is configured to track and commit source data 279 to a source repository 280. The source data 279 includes the source code, such as files including programming languages and/or object code, from which the software artifacts of a respective build combination are created”;
Based on the modified artifact source code a set of metadata is retrieved:
[0071] Likewise, for a respective software artifact detected as being modified at block 910, an automated historical analysis of stored historical data for one or more previous versions of the modified software artifact (or a reference software artifact, such as a software artifact corresponding to a same class and/or method) may be performed at block 930 (e.g., by analysis engine 296). ……. The historical activity information for a software artifact may be quantified or measured as a historical activity score, for example, based on an amount/size and/or frequency of previous changes/modifications to that particular software artifact and/or to another reference low-risk software artifact, for example, an artifact in the in the same class or associated with a corresponding method. Historical activity for a software artifact may also be quantified or measured based on calculation of a ratio of changes relating to fixing defects versus overall changes to that particular software artifact. Changes relating to fixing defects may be identified, for example, based on analysis of statistics and/or commit comments stored in a source repository (e.g., using github, bitbucket, etc.), as well as based on key performance indicators (KPIs) including but not limited to SQALE scores, size of changes, frequency of changes, defect/commit ratio, etc.
[0072] “An output such as alarm/flag and/or a suggested prioritization for testing of the code may be generated based on the risk score”;
Based on the changed artifact a set of data and configuration ,specification about the artifact is retrieved: version information, such as KPIs and an alarm is suggested for testing the artifact/build.
Also, among the metadata for identifying the changes is version comparison:
[0061]:”The version comparison may indicate or otherwise be used to identify particular software artifact(s) including changes or modifications relative to the previous build combination(s). The comparison need not be limited to consecutive versions; for example, if a version 2.0 is problematic, changes between a version 3.0 and a more stable version 1.0 may be identified. Other methods for detecting new or changed software artifacts (more generally referred to herein as modified software artifacts) may also be used.
As the artifacts that include the changes are identified, the metadata is used to identify a subset of test , for testing the changed artifact or source code files:
[0062] “ A subset of the stored test assets may thereby be selected as may be required for testing the modified software artifact, and/or as may be warranted based on the associated risk score. Also, at block 830, a subset of stored test cases (e.g., test cases 287) may be associated with a test operation or test cycle for the retrieved build combination, likewise based on the software artifact(s) identified as having the changes modifications and/or the associated risk score(s)”;
The subset of tests is executed:
[0067] “ Still referring to FIG. 4B and FIG. 8, automated testing of the retrieved build combination 402 is executed based on the associated subset(s) of test cases in response to the automated deployment of the build combination to the test environment at block 860.”;
Applicant’s argument:
However, Avisror's subset has not been shown to disclose or suggest "identifying a subset of tests of a plurality of tests" that are "associated with the subset of changed source code files." Since Avisror's one or more subset of stored test assets are associated with a build combination, such subset of stored test assets is not associated a "subset of changed source code files," as required by the language of claim 1.
Examiner’s response:
In response each build has associated artifact and any test for that build is etest associated with the artifacts.
Avisor discloses a correlation between test cases and artifacts(source code file):
[0078] “Further embodiments of the present disclosure are directed to operations for dynamic test case selection and execution by correlating test cases with software artifact(s) based on corresponding temporal data.”;
Further in [0079], a set of metadata is disclosed for artifacts: associated test, when test is executed to test the artifact.
No as the artifact are changed I association with previous version of respective artifacts, a subset of test is selected.:
[0089] “At least one subset 1187B of the test cases 1187A is selected for automated testing of the build combination 1102B responsive to identifying the modified software artifacts 1104A′ and 1104B′ and based on the temporal associations at block 1050. That is, the subset of test cases 1187B for the automated testing of the build combination 1102B includes test cases that are associated with the modified software artifacts 1104A′ and 1104B′, based on the correlations indicated by the time-correlated coverage data 1191A′.”;
The coverage of test identifies the test that should be selected for the associated artifacts. Artifacts for previous build now includes some modification: 0094]” That is, test cases associated with software artifacts having higher code coverage in the testing of a previous build combination based on the corresponding code coverage data may be weighted or otherwise granted a higher priority in the testing of a subsequent build combination that includes changes to those same software artifacts, which may drive faster test failure.”;
And based on changes in the artifacts the subset of tests are selected for the modified artifacts.
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.
Claims 1-4, 6, and 8-14 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Avisror et al US20190294536A1 in view of Spiro et al US20220269582A1.
As per claim 1, a computer implemented method, the method comprising:
in response to a change to a subset of source code files stored in a source code repository:
[0071]“Changes relating to fixing defects may be identified, for example, based on analysis of statistics and/or commit comments stored in a source repository (e.g., using github, bitbucket, etc.), as well as based on key performance indicators (KPIs) including but not limited to SQALE scores, size of changes, frequency of changes, defect/commit ratio, etc.”;
[0025] “For example, in continuous delivery (CD), software may be built, deployed, and tested in short cycles, such that the software can be reliably released at any time. Code may be compiled and packaged by a build server whenever a change is committed to a source repository, then tested by various techniques (which may include automated and/or manual testing) before it can be marked as releasable.”;
[0082] “As discussed above, modified software artifacts of respective builds may be identified and tracked using a build tracking engine 278 that is configured to track and store build data 277 indicating the various sets of software artifacts and modifications that are included in respective build combinations and changes thereto, which may be stored in repository 280.
the source code files being used to deploy a version of a software product:
[0039] “The build combination includes software artifacts (e.g., artifacts 104) of a specific software version to be deployed for testing.”;
[0031] “The data can be processed by the deployment automation server 105 to generate a deployment plan or specification that can then be read by the deployment automation server 105 to perform the deployment of the software artifacts onto one or more target systems (such as the test environments described herein) in an automated manner, that is, without the further intervention of a user”;
the change resulting in a subset of changed source code files:
[0061] “ For example, a project management system 445 may transmit a notification to a build management system 435 including a version number of the build combination, and the build management system 435 may fetch the build combination (e.g., build combination 102) from the build server 410 based on the requested version number. At block 810, one or more software artifacts of the retrieved build combination may be identified as including changes or modifications relative to one or more previous build combinations.”;
obtaining from the source repository metadata of the subset of changed source code files stored in the source code repository:
[0061] “At block 810, one or more software artifacts of the retrieved build combination may be identified as including changes or modifications relative to one or more previous build combinations…. The version comparison may indicate or otherwise be used to identify particular software artifact(s) including changes or modifications relative to the previous build combination(s). The comparison need not be limited to consecutive versions; for example, if a version 2.0 is problematic, changes between a version 3.0 and a more stable version 1.0 may be identified. Other methods for detecting new or changed software artifacts (more generally referred to herein as modified software artifacts) may also be used.”
[0030] “As described herein, a software artifact 104 that includes or comprises a modification may refer to a software artifact that is new or changed relative to one or more corresponding software artifacts 104′, 104″ of a previous build combination 102′, 102″.
analyzing, based on a rule set, the metadata of the subset of changed source code files and content of at least one code file of the subset of changed source code files:
[0062] “At block 820, one or more subsets of stored test assets (e.g., test assets 261, 262, 263) may be associated with a test environment for the retrieved build combination, based on the software artifact(s) identified as having the changes or modifications, and/or risk score(s) associated with the software artifact(s). For example, for each software artifact identified as having a change or modification, a risk score may be computed based on complexity information and/or historical activity information for the modified software artifact, as described by way of example with reference to FIG.9 “
[0073]”For example, as discussed herein, the calculated risk score for a respective software artifact may be used for selection and association of test cases and/or test assets. More particularly, for a build combination under test, the risk score may assist in determining where relative risk lies among the modified software artifacts thereof. A testing priority in the automated testing may be determined among the set of software artifacts of the build combination based on the risk assessment or risk score, such that testing of particular artifacts may be prioritized in an order that is based on the calculated risk for the respective artifacts.
in response to analyzing, identifying a subset of tests of a plurality of tests included in a default test plan to be executed to test the version of the software product, wherein the subset of tests is associated with the subset of changed source code files:
[0062] “. A subset of the stored test assets may thereby be selected as may be required for testing the modified software artifact, and/or as may be warranted based on the associated risk score…. Also, at block 830, a subset of stored test cases (e.g., test cases 287) may be associated with a test operation or test cycle for the retrieved build combination, likewise based on the software artifact(s) identified as having the changes modifications and/or the associated risk score(s). For example, the subset of test assets and/or test cases may be selected based on identification of classes and/or methods of the modified software artifact(s), for instance based on tags or identifiers indicating that particular test assets and/or test cases may be useful or desirable for testing the identified classes and/or methods. In some embodiments, the tags or identifiers may include metadata indicating respective start and end times of execution of respective test cases, which may be used to correlate test cases with timestamps indicating code coverage of particular files and/or methods, as described in greater detail below.”;
and executing the subset of tests at a test landscape running a set of software components the version of the software product deployed and compiled based on the [[set]] subset of changed source code files.
and executing the subset of tests at a test landscape running the subset of changed files source code files:
[0067] “Still referring to FIG. 4B and FIG. 8, automated testing of the retrieved build combination 402 is executed based on the associated subset(s) of test cases in response to the automated deployment of the build combination to the test environment at block 860. For example, after deployment is completed and the application server 415 in the test environment is set-up, a testing cycle or operation may be initiated by a test automation system (e.g., system 125). Tests may be executed based on the deployment plan 440 and based on the changes/modifications represented by the software artifacts of the deployed build combination 402”;
[0043]” The build management system may further include a source control engine 278 that is configured to track and commit source data 279 to a source repository 280. The source data 279 includes the source code, such as files including programming languages and/or object code, from which the software artifacts of a respective build combination are created. A development system may be used to create the build combination 102 and/or the software artifacts 104 from the source data 279, for example, using a library of development tools (e.g., compilers, debuggers, simulators and the like).
But not explicitly:
running the version of the software product deployed and compiled based on the set of changed source code files;
Spiro discloses:
running the version of the software product deployed and compiled based on the set of changed source code files:
[0028]”In some embodiments, the command center then retrieves the test microservice from the code repository, replacing the corresponding microservice from the production artifacts with the test microservice in a test configuration, or in the case of a new microservice adding the test microservice to the test configuration.
[0041]“In the depicted embodiment, command center 112 is coupled to provisioner 118. Provisioner 118 receives the test environment configuration 145 to provision test tenant 136 to instantiate test environment 139 based on the test environment configuration 145. Once test tenant 136 is provisioned, test tenant 136 is deployed, which includes the test microservice 109 as well as other microservices of microservices 121 through microservice 124, databases, and other elements defined in the test environment configuration 145”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Spiro into teachings of Avisror to ensure simple and efficient creation of a tenant in a multi-tenant environment. A test environment configuration is generated based on the repository, where the configuration comprises a set of test tenant microservices including the microservices having a dependency relationship with the microservice. A test tenant is provisioned based on configuration in an instance, and the set of tenant microservice is deployed in the test tenant reducing the a cost prohibitive due to resource requirements to run a microservice-based application[Spiro 0003]
As per claim 2, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
analyzing metadata for a plurality of source code files obtained stored at the source code repository:
[0071] “Changes relating to fixing defects may be identified, for example, based on analysis of statistics and/or commit comments stored in a source repository (e.g., using github, bitbucket, etc.), as well as based on key performance indicators (KPIs) including but not limited to SQALE scores, size of changes, frequency of changes, defect/commit ratio, etc.’;
[0030] “As described herein, a software artifact 104 that includes or comprises a modification may refer to a software artifact that is new or changed relative to one or more corresponding software artifacts 104′, 104″ of a previous build combination 102′, 102″.
wherein the source code repository provides the metadata of the plurality of source code files in response to receiving the change in the subset of changed source code files:
[0071] “The historical data may be stored in a database (e.g., database 280), and/or derived from data 679 stored in a source repository in some embodiments. The historical activity information for a software artifact may be quantified or measured as a historical activity score, for example, based on an amount/size and/or frequency of previous changes/modifications to that particular software artifact and/or to another reference low-risk software artifact, for example, an artifact in the in the same class or associated with a corresponding method. Historical activity for a software artifact may also be quantified or measured based on calculation of a ratio of changes relating to fixing defects versus overall changes to that particular software artifact”;
[0072] “Measurements generated based on the modifications to the respective software artifacts of the build combination may be used to calculate and associate a risk score with a respective modified software artifact at block 940. The risk score is thus a measure that recognizes change complexity and change history as indicators of risk”;
As per claim 3, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
defining the rule set to include rules to skip or enforce testing of portions of the software product based on identifying flags in changed portions of source code in the set of changed source code files:
[0080] “In some embodiments, the subsequent build combination may include software artifacts that have been modified (e.g., new or changed) relative to one or more previous build combinations, and the subset(s) of the test cases may be selected for the automated testing based on detection or identification of the modification(s) to the particular software artifact(s) relative to the previous build combination(s). The subset(s) of the test cases may be a proper subset that omits at least one of the previously-executed test cases, thereby reducing the amount of test cases for the automated testing of the subsequent build combination (and thus, associated computer processing requirements and duration for test cycle execution). The operations 1000A may be recursively performed such that the number of test cases is iteratively reduced for each subsequent build combination.
As per claim 4, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
wherein executing the subset of tests comprises: creating the test landscape as a temporary landscape, and providing a set of instances of a set of software components of the software product to deploy at the test landscape and execute the subset of tests:
[0074] “Conversely, one or more pre-existing (i.e., existing prior to identifying the software artifact having the modification) test assets and/or test cases may be removed from a test environment and/or test cycle for lower-risk changes to a build combination, resulting in improved testing efficiency. That is, the test environment and test cycle may include only test assets and/or test cases that are relevant to the code modification (e.g., using only a subset of the test assets and/or test cases that are relevant or useful to test the changes/modifications), allowing for dynamic automated execution and reduced processing burden.
[0080] At block 1060, automated testing of a subsequent build combination that includes at least one of the tested software artifacts (as indicated by the code coverage data) is executed using or otherwise based on one or more subsets of the test cases associated therewith based on the corresponding temporal data. In some embodiments, the subsequent build combination may include software artifacts that have been modified (e.g., new or changed) relative to one or more previous build combinations, and the subset(s) of the test cases may be selected for the automated testing based on detection or identification of the modification(s) to the particular software artifact(s) relative to the previous build combination(s).
As per claim 6, the rejection of claim 1 is incorporated and furthermore Avisror does not explicitly disclose:
wherein after the execution of the subset of tests at the test landscape, deleting the test landscape.
Spiro discloses:
wherein after the execution of the subset of tests at the test landscape, deleting the test landscape.
[0026] To overcome these and other shortcomings of prior approaches, methods and systems described herein provide a test environment configured as a “light” version of the production environment, within a tenant simultaneously with the production tenant in the same instance, and removing the test environment after a predetermined amount of time.
[0031] After a predetermined amount of time, or at the command of the developer, the test tenant and test environment are automatically deprovisioned after completion of testing, and removed from the instance.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Spiro into teachings of Avisror to ensure simple and efficient creation of a tenant in a multi-tenant environment. A test environment configuration is generated based on the repository, where the configuration comprises a set of test tenant microservices including the microservices having a dependency relationship with the microservice. A test tenant is provisioned based on configuration in an instance, and the set of tenant microservice is deployed in the test tenant reducing the a cost prohibitive due to resource requirements to run a microservice-based application[Spiro 0003]
As per claim 8, the rejection of claim 4 is incorporated and furthermore Avisror discloses:
wherein executing the subset of tests comprises: determining a landscape type for executing a test over a component of the set of software components:
[0031]“The data can be provided by a variety of sources and can include information defined by users and/or computing systems. The data can be processed by the deployment automation server 105 to generate a deployment plan or specification that can then be read by the deployment automation server 105 to perform the deployment of the software artifacts onto one or more target systems(such as the test environments described herein) in an automated manner, that is, without the further intervention of a user”;
wherein a set of landscape types are defined for the testing:
[0034] “Different types of testing may utilize different test environments, some or all of which may be virtualized to allow serial or parallel testing to take place.
wherein each of the landscape types corresponds to a type of infrastructure for running the software component.
[0041] “The test environment management system 120 is configured to perform automated association of subset(s) of stored test assets with the test environment for the build combination 102, and automated provisioning of one or more servers of the test environment based on the associated test assets”;See also 0064 -0065 for provisioning servers of test environment for testing specific components.
As per claim 9, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
wherein the test landscape is a cloud test landscape configured to host software components of the software product as a service:
[0037]“test environment management system 120, or other sub-system of computing environment 100 can be at least partially (or wholly) cloud-implemented, web-based, or distributed to remotely host, serve, or otherwise manage data, software services and applications interfacing, coordinating with, dependent on, or used by other services and devices in environment 100.”;
As per claim 10, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
wherein the test landscape comprises at least two landscapes of different infrastructure types, wherein a component of the software componentsof the software product are tested in parallel on the at least two landscapes:
[0034] “Different types of testing may utilize different test environments, some or all of which may be virtualized to allow serial or parallel testing to take place”;
Examiner interpretation: different test environment is different landscape and executing the build in this different environment i.e executing different test of the selected subset in parallel.
Claims 11, 12, 13, 14 are the system claims corresponding to methods claims 1, 2, 3, 4 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 4 above.
Claims 16, 17, 18, 19 are non-transitory, computer-readable medium claims corresponding to methods claims 1, 2, 3, 4 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 4 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Avisror et al US20190294536A1 in view of Spiro et al US20220269582A1 and Reeve et al US20190156199A1.
As per claim 7, the rejection of claim 1 is incorporated and furthermore Avisror discloses:
wherein executing the subset of tests comprises: executing unit tests over portions of set of the software components:
[0044] “The test cases 287 may include particular types of testing (e.g., performance, UI, security, API, etc.), and/or particular categories of testing (e.g., regression, integration, etc.). The test cases 287 may be selected to define a test operation or test cycle that specifies how the testing engine 286 is to simulate the inputs of a user or client system to the deployed build combination 102.”
[0034]“Different types of testing may utilize different test environments, some or all of which may be virtualized to allow serial or parallel testing to take place.
wherein the unit tests and the integrations tests are identified as part of the subset of tests based on the rule set:
[0083] The build combination 1102A may be deployed to an application server (such as the server 415 of FIG. 4) in a test environment, and a code coverage tool 1190 may be executed or otherwise enabled at block 1010. Automated testing of the build combination 1102A may be executed based on a set of test cases 1187A at block 1015, concurrently with the execution of the code coverage tool 1190. For example, the testing engine 286 of the test automation system 125 of FIG. 2B may access the test cases 287 stored in database 290 to retrieve a set of test cases 1187A and execute the automated testing of the build combination 1102A based on the set of test cases 1187A. The test cases 287 may include particular types of testing (e.g., performance, UI, security, API, etc.), and/or particular categories of testing (e.g., regression, integration, etc.).
But not explicitly:
and executing integration tests in parallel between at least two of the set of software components:
Reeve discloses:
and executing integration tests in parallel between at least two of the set of software components:
[0011]”Embodiments of the present invention improve existing technologies for the automated integration testing of a software application that comprises a microservices architecture. As explained above, integration testing requires concurrently testing all, or a significant subset of all, the microservices comprised by the application.
[0023] “This allows the present invention to run integration test scripts by means of technologies and techniques similar to those used to generate and run unit tests. This advantage also facilitates development and maintenance of integration test scripts by allowing integration tests to be written in formats and styles similar to those of unit tests. For all these reasons, the present invention allows the development of integration test scripts that comprehensively describe a tested unit's expected behavior under test in an easily understandable manner.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Reeve into teachings of Avisror and Spiro to perform an integration test on an integrated subsystem of the microservice-based application .This advantage also facilitates development and maintenance of integration test scripts by allowing integration tests to be written in formats and styles similar to those of unit tests. For all these reasons, the present invention allows the development of integration test scripts that comprehensively describe a tested unit's expected behavior under test in an easily understandable manner.[Reeve 0023].
Pertinent arts:
US 8276123 B1:
Based on these changed functions, the control unit determines those functions of the source code not changed but impacted by the changes within a set distance. The control unit then selects, for each of these determined functions, one or more test cases in accordance with one or more test selection algorithms.
US10922216B1:
Techniques are included for intelligently testing a software product using a limited number of test cases that are configured to test portions of the software product that have changed since a prior testing.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Y Mui can be reached at 571-270-2738. 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.
/BRAHIM BOURZIK/Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights