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-20 are pending in this office action.
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-5, 7-12, 14 15-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lang et al US20200257612A1 in view of Tsantilis et al US 20120151455A1
As per claim 1, Lang discloses a computer-implemented method, comprising:
presenting, by an integration system operating on an instance of an electronic information exchange platform in a test mode, processing steps of a workflow to be implemented on the instance of the electronic information exchange platform:
[0031] “As part of the testing, the system 100 can define workflows (e.g., sequences of operations using the application) based on the customer's data. These workflows can be tested by attempting to run the operations of the workflows in the newly created computing environments, in order to ensure that upgraded software will function properly for that customer.”;
the workflow involving entity systems:
[0031]“Software developers can use the system 100 is to test different build versions of an enterprise application on a variety of computing environments that are based on the data and usage of particular customer’;
the processing steps corresponding to tasks specified in a task model:
[0060]“In these implementations, testing system 120 may extract workflows from usage logs 112 that represent specific sequences of tasks, or those that simulate typical usage. ;
the integration system having an enhanced user interface (UI):
[0005] The testing system may provide a user interface so that users can initiate the creation and testing of computing environments. As an example, the user interface may be provided to a software developer, who may test computing environments representing different customer installations to develop software to be distributed. As another example, the user interface may be provided to an administrator for a specific organization, who may test the environments to verify compatibility in preparation for an upgrade
receiving, through the enhanced UI, a scope of the processing steps for testing, wherein one of the processing steps has a dependency on a predecessor in the workflow:
[0057]“This analysis of system data 108 may include analyzing the metadata 110, the data sets 114, and/or the usage logs 112. Analyzing the metadata 110 may include searching through metadata 110 and identifying any software objects within it, determining any dependencies or other associations between software objects, identifying any links to data sources”;
receiving, through the enhanced UI, an instruction to run a test on the scope of the processing steps:
[0054]“The client device 102 can provide a user interface to an administrator that enables the administrator to select one or more build versions of the enterprise application to be tested, make changes to the server environment configuration found in snapshot 128, and/or initiate testing. “;
responsive to failure of the test, determining variations of tasks in the scope and making recommendations based on the variations of tasks in the scope:
[0108] “For example, there may be multiple versions of the application, potentially with different sets of software modules, different combinations of features, and/or different configuration profiles. The computer system can use the identified errors, incompatibilities, and performance issues, as well as the information about functions or features of the software used by the data objects, to select which version or configuration of the application to recommend or install on the first software environment”;
and presenting, through the enhanced UI, the recommendations with documentation describing each of the recommendations:
[0110]“In some implementations, the computer system can initiate (or provide a recommendation and user interface element for an administrator to initiate) a conversion process or standardization process to bring non-standard or incompatible data objects into compliance for the second version of the application;
[0111]“The computer system may annotate the development codebase for the second version of the application based on errors, incompatibilities, performance decreases, or other items noted. This can provide a feedback mechanism where testing of the customized configuration and data objects of different installations of the application can signal areas to update the application functionality or even specific code of the application”;
But not explicitly:
flagging, by the integration system, the dependency without generating an error message.
Tsantilis discloses:
flagging, by the integration system, the dependency without generating an error message.
[0039] “An annotation may specify that a unit is dependent on another unit (e.g., that a method is dependent on a class, or that one package is dependent on another package).”;
[0046]“The unit test execution module 202 optionally determines not to execute some units when those units depend on units having errors during their unit tests. The unit test execution module 202 determines how to handle such errors, for example, according to test mode parameters. For example, suppose a first unit depends on a second unit. If the second unit fails, the unit test execution module 202 may determine to log the resulting failure and continue to execute a unit test for the first unit. The unit test execution module 202 may alternatively stop execution of the unit test for the first unit because the first unit depends on the second unit. In implementations where dependency annotations specify a strength of dependency, the unit test execution module 202 may stop execution of the unit test for the first unit if the first unit depends strongly on the second unit”;”;
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 Tsantilis into teachings of Lang for analyzing a plurality of units of a software application to determine a dependency graph defining that at least a first unit depends on a second unit, each unit comprising one or more executable instructions; determining an execution order for the units based on the dependency graph, wherein the execution order specifies execution of the second unit before the first unit in a weak or strong dependency. Furthermore, to Improve quality and robustness of software using unit testing that ensures improved and fast unit testing. [Tsantilis0 016]
As per claim 2, the rejection of claim1 is incorporated and furthermore Lang discloses:
wherein the task model is part of a testing framework of the electronic information exchange platform:
[0060]”In these implementations, testing system 120 may extract workflows from usage logs 112 that represent specific sequences of tasks, or those that simulate typical usage. In other implementations, during workflow validation testing, the administrator may choose the workflows to be tested through client device 102. In yet other implementations, during workflow validation testing, workflows are chosen based on a combination of usage logs 112 and administrator input. The testing system 120 may also determine the most common objects and functions used within data sets 114.”
As per claim 3, the rejection of claim1 is incorporated and furthermore Lang discloses:
presenting a configuration of the test through the enhanced UI:
[0054]”The client device 102 can provide a user interface to an administrator that enables the administrator to select one or more build versions of the enterprise application to be tested, make changes to the server environment configuration found in snapshot 128, and/or initiate testing.”
[0055] “The administrator's instructions may include a modification to the configuration of server environment 106. This modification may include a change to the hardware capabilities of the server environment, such as a change to the amount of memory allocated (e.g., random-access memory), the number of CPUs allocated, the type of CPUs, network bandwidth, the latency, etc. Here, the instructions from an administrator indicate the creation of server environment 124 and server environment 126.”;
As per claim 4, the rejection of claim 3 is incorporated and furthermore Lang discloses:
receiving a change to the configuration; and updating a configuration file to reflect the change to the configuration:
[0055]“In some implementations, one or more variations of snapshot 128 are created automatically by testing system 120. In some implementations, an administrator selects the build version of the enterprise application for testing, but the testing system 120 automatically varies the configuration of the resulting server environments. After instructions are received for the creation of one or more variations of snapshot 128, testing system 120 may cause the environments 124, 126 to run installers 132 for the new build versions.”;
As per claim 5, the rejection of claim 4 is incorporated and furthermore Lang discloses:
receiving configurations of tests of the workflow or a portion thereof; and aggregating the configurations in the configuration file:
[0059] At stage (H), testing system 120 determines what tests should be performed using the system data 108 and one or more build versions of the enterprise application. The tests may include, for example, metadata integrity testing, workflow validation, capacity testing, performance testing, dynamic stress testing, and application of new software features to customer data (e.g., system data 108). In some implementations, the testing system 120 receives input from the administrator through the client device 102 indicating which tests should be performed. In other implementations, the testing system 120 automatically chooses which tests to be performed. In other implementations, the testing system 120 is configured to perform all tests available. In these implementations, not all tests may be available. For example, if the build version of the enterprise application being tested does not have any new features, then no new features can be applied to a customer's data.
As per claim 7, the rejection of claim 1 is incorporated and furthermore Lang discloses:
wherein a least a portion of the processing steps are performed by avatars of the entity systems, the avatars operated by the integration system.
[0052] “At stage (D), after obtaining the system data 108, the testing system 120 customizes the one or more server environments by loading them with custom configuration data derived from the system data 108.”;[0108] “For example, the computer system can select a software version or configuration that provides the functions needed to support the customized set of data objects and configuration data of the first server environment”;
Claims 8, 9, 10, 11, 12, 14 are the system claim corresponding to method claims 1, 2, 3, 4, 5, 7 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 4, 5, 7 above.
Claims 15, 16, 17, 18, 20 are the computer program product comprising a non-transitory computer-readable medium claim corresponding to method claims 1, 3, 4, 5, 7 and rejected under the same rational set forth in connection with the rejection of claims 1, 3, 4, 5, 7 above.
Claims 6 , 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lang et al US20200257612A1 in view of Tsantilis et al US 20120151455A1, and further in view of Frank et al US 20170180487A1
As per claim 6, the rejection of claim 5 is incorporated and furthermore Lang discloses:
receiving a confirmation that a system-wide test of the workflow is successful; and starting to monitor communication between the entity systems in a production mode.
Frank discloses:
receiving a confirmation that a system-wide test of the workflow is successful; and starting to monitor communication between the entity systems in a production mode.
[0046]“Provided the automated testing is successful, then the pipeline deployment agent 129 may begin pushing the executables into increasingly broader production environments. At each stage, the pipeline deployment agent 129 may monitor the production service 125 to ensure the software being deployed continues to function correctly or within any limits on performance metrics throughout the deployment process.”
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 Frank into teachings of Lang and Tsantilis to allow an enterprise to ensure that operational best practices for availability, security, testing, performance, deployment, and monitoring are followed in continuous deployment pipelines used to push applications, services, and upgrades into production. Furthermore, for enforcement and validation with tools to bring applications or services into compliance with deployment best practices, keep deployment pipelines for applications or services up-to-date as operational guidelines or best practices evolve, and help developers set up new services correctly. Doing so may substantially reduce outages caused by defects in the deployment process that are easily preventable and to reduce developer time spent on operational setup and configuration.[Frank 0041].
Claim 13 is the system claim corresponding to method claim 6 and rejected under the same rational set forth in connection with the rejection of claim 6 above.
Claim 19 is the computer program product comprising a non-transitory computer-readable medium claim corresponding to method claim 6 and rejected under the same rational set forth in connection with the rejection of claim 6 above.
Pertinent arts:
US 11409644 B2:
validation of mobile device workflows. A user can choose configuration parameters for the one or more remote devices, for the application, and for a server environment used in the testing. In some implementations, the system varies the configuration parameters of the one or more remote devices, of the application, and/or of the server environment.
US 20230106929 A1:
determining constraints based on inputs and corresponding outputs of an API in a production environment; generating initial test inputs based at least in part on the constraints; creating a program dependency graph based on trace sequences and request-response data obtained in response to providing the initial test inputs to an endpoint of the API; enhancing the program dependency graph by generating additional test inputs directed to one or more paths of the dependency graph; identifying, based on the enhanced program dependency graph, at least a portion of the API that is not covered by an existing test suite; and using the enhanced program dependency graph to generate new test cases for the test suite based on the identifying.
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