DETAILED ACTION
The Office Action is in response to claims filed 02/08/2024.
Claims 1-20 are pending.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-5, 7, and are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation "the definition" in line 1. There is insufficient antecedent basis for this limitation in the claim. It is unclear if “the definition” refers to the aforementioned “a model definition” or to something else entirely.
Claim 4 recites the limitation “wherein each field” in line 1. It is unclear if “field” refers to a singular instance of aforementioned “plurality of fields” or to something else entirely. Thus, the claim is further rejected for being vague and indefinite.
Claims 4-5 are rejected in light of their chain of dependency upon claim 3.
Claim 7 recites the limitation "comprises processor-executable program" in line 2. It is unclear if “processor-executable program code” refers to aforementioned “processor-executable program code” in claim 1 line 3 or to something else entirely. Thus, the claim is rejected for being vague and indefinite.
Claim 9 recites the limitation "comprises processor-executable program code” in lines 2-3. It is unclear if “processor-executable program code” refers to aforementioned “processor-executable program code” in claim 1 line 3 or to something else entirely. Thus, the claim is rejected for being vague and indefinite.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over US 20250181485 A1 hereinafter “Kuboniwa” in view of US 20150007129 A1 hereinafter “William”.
With regards to claim 1, Kuboniwa teaches
one or more models, each model defining a respective data entity; (Kuboniwa [0050], “The test scenario information 312 is information in which the contents of individual test scenarios constituting a combined test, parameters used for the test, test data, and the like are defined. Each of test scenarios is a unit test that can be executed by one of the test automation tool 401 and the like, and a content of each of these test scenarios is a process or the like executed individually for the information system 1000 [defining a respective data entity]. Further, a content of each of the test scenarios is a process independent of other test scenarios [one or more models, each model]. Further, each of the test scenarios may be defined in a plurality of combined tests.”) [Examiner’s Note: A test scenario comprises a structure of multiple tests to model an entire business process/data entity]
a memory storing processor-executable program code;
and a processing unit to execute the processor-executable program code to cause the system to: (Kuboniwa [0040], “Note that the combined test apparatus 1 includes a processor [and a processing unit to execute the processor-executable program code], a memory, and a storage device as a configuration which is not shown. Further, a computer program in which processing of the combined test method according to this example embodiment is implemented is stored in the storage device. Further, the processor loads a computer program or the like from the storage device into the memory and executes the loaded computer program [a memory storing processor-executable program code]. In this way, the processor implements the functions of the selection unit 11, the test execution unit 12, and the determination unit 13.”)
receive a request to execute a test executable code for a first model of the one or more models; (Kuboniwa [0046], “The test execution apparatus 400 includes a plurality of test automation tools 401 to 40n (n is a natural number greater than or equal to two). The test automation tool 401 or the like is software that performs a unit test or the like on the information system 1000 and is an example of a test program. The test automation tool 401 or the like performs, for example, data import processing to a database or the like in the information system 1000, transmission of a specific request and reception of the response to the information system [receive a request to execute a test executable code] 1000, and acquisition of results of execution of tests. The test automation tool 401 or the like has a function of executing a specified test scenario [for a first model of the] to a specified destination. A plurality of types of known tools can be applied to the test automation tool 401 or the like.”) [Examiner’s Note: FIG 2. Describes selecting a test scenario of a plurality of test scenarios analogous to a first model of a business process of a plurality of models]
Kuboniwa does not teach: identify a model framework for the first model;
generate the test executable code for the first model based on the identified model framework;
generate an output via execution of the test executable code; and
report an analysis of the generated output.
However, in an analogous art William teaches: identify a model framework [for the first model;] (William [0034], “To generate the script execution framework, a selection of a script-pattern residing in a data source--is received. Source tags corresponding to the selected script-pattern are determined, to be able to receive an input. From an associated user interface, business intelligence (BI) script is received as an input to the source tags, to execute the business process. The BI script received from the UI is embedded with the selected script-pattern to generate a BI source code. The generated BI source code is validated and processed to generate the script execution framework. Such a generated BI script execution framework is operable to simulate the business process and generate a corresponding BI report, which can be used for decision-making.”)
generate the test executable code for [the first model] based on the identified model framework; (William [0016], “A BI script framework such as script execution framework 110 acts as a BI functionality that allows scripts to be generated by the configuration module and/or written by the user, which are compiled with the existing instructions to execute the business process… An elaborate script writer (user or module) may write the entire source codes corresponding to the business data service providers and the functionalities associated with the business process. A minimal script writer (a user or a script generation module) may write mere variables in the available source codes as inputs to script execution framework 110.”)
generate an output via execution of the test executable code; and
report an analysis of the generated output. (William [0020], “Upon receiving the trigger to simulate the execution from UI component 215, query module 235 associated with script execution framework 220 generates a query by determining a plurality of result objects and a plurality of query filters [generate an output via execution of the test executable code]. Result objects and query filters represent a plurality of source tags operable to receive an input. Based upon the input to the source tags associated with the script-pattern, an analytical report is generated as a resultant of the execution of the business process. Result objects may include a plurality of fields that are represented as report fields the analytical report, and the query filters may include a plurality of conditions to be satisfied to generate the analytical report [report an analysis of the generated output].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
With regards to claim 2, the rejection of claim 1 is incorporated.
Kuboniwa does not teach: wherein the model framework includes a model structure and a model definition.
However, in an analogous art William teaches wherein the model framework includes a model structure and a model definition. (William [0025], “A script-pattern may be a complete or an incomplete reusable solution that can be transformed to source code by appending corresponding inputs from client-side system 205. Such script-patterns are configurable depending on the selected data service provider and the business process to be executed [includes a model structure]. By doing so, a set of script-patterns are available for multiple executions of the business process associated with the data service provider, at various instances. To configure such script-patterns, pattern keys and display values are generated for the selected data service provider. Pattern keys and display values represent various functionalities and classifications of script-pattern. Utility methods and associated member variables are generated for the selected business process. Utility methods represent structures, collaborations, implementations, and various other contexts in which the script-pattern can be utilized [and a model definition]. Input member variables provided for such methods are applied according to documentation formats of the script-pattern. Based upon the input received for the pattern keys and the display values, the script-patterns may be configured for the corresponding business process.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
With regards to claim 3, the rejection of claim 2 is incorporated.
Kuboniwa does not teach: wherein the definition includes operations supported by the model framework, and a plurality of fields included in the respective data entity.
However, in an analogous art William teaches: wherein the definition includes operations supported by the model framework, and a plurality of fields included in the respective data entity. (William [0025], “Utility methods represent structures, collaborations, implementations, and various other contexts [wherein the definition includes operations] in which the script-pattern can be utilized [supported by the model framework]. Input member variables provided for such methods are applied according to documentation formats of the script-pattern [and a plurality of fields included in the respective data entity]. Based upon the input received for the pattern keys and the display values, the script-patterns may be configured for the corresponding business process.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William, as applied to claim 3, and further in view of US 20170109269 A1 hereinafter “Angermayer”.
With regards to claim 4, the rejection of claim 3 is incorporated.
The combination of Kuboniwa and William does not teach: wherein each field is marked as one of mandatory and read only.
However, in an analogous art Angermayer teaches wherein each field is marked as one of mandatory and read only. (Angermayer [0032-33], “FIG. 4 shows exemplary test data container and test metaobject instances that can be created by test data packager 134. MDRS_CTDF 402 is a test metaobject instance. MDRS_CTDF 402 has only one ROOT node that holds all mandatory attributes for test metaobjects, such as node identifier, proxy name, status, creation date, creation user, update date, update user, etc. In addition, MDRS_CTDF includes associations with business object MDRS_BO 404 and TestDataContainer 410. Business object MDRS_BO 404 is referenced by dependent business objects Employee 406a and Product 406b. Each business object (404 and 406a-b) contains mandatory attributes 407a-c, such as node identifier, proxy name, status, creation date, creation user, update date and update user. Mandatory attributes 407a-c may be the same for all business objects and test metaobject instances [wherein each field is marked as one of mandatory] … Test data values 512a-b corresponding to the relevant specific attributes 510 may be persisted in test data container TDC_EMPLOYEE 504. For example, two sets of test data values 512a-b may be persisted in test data container 504 to create two different “Employee” business object instances. The test data values 512a-b may be retrieved from, for example, database 136 or from the developer via a user interface. [and read only]”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Angermayer into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, with the metadata fields of business scenarios being read only and mandatory. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a development system that can analyze software applications for a business object using data stored therein (Angermayer [0023]).
Claims 5-8, 13-14, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William and further in view of US 20240143417 A1 hereinafter “Hrastnik”.
With regards to claim 5, the rejection of claim 3 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the operations supported by the model are at least one of a create operation, a read operation, an update operation, a delete operation, an execute operation, a validate locks operation, and an authorization verification operation.
However, in an analogous art Hrastnik teaches wherein the operations supported by the model are at least one of a create operation, a read operation, an update operation, a delete operation, an execute operation (Hrastnik [0075], “In some aspects, the mappings (also referred to as mapping information herein) may be captured as an abstract definition of service operations that cover different service operations (e.g., create, read, update, delete and execute (CRUDE) operations). When composing new services/applications, statically or dynamically, these definitions may be used to realize the service requirements of the users on the requested concrete technical protocol level, such as an OData level.”), a validate locks operation, and an authorization verification operation. (Hrastnik [0162], “At this point, the tracing can be stopped and the recorded trace can be evaluated. As illustrated in FIG. 43, the traced interaction shows that there are a plurality of processing steps being executed in the context of the processed status transition. The trace reveals framework internal processing logic, general processing steps, etc. For example, steps such as, Start Authorization check, Instance Authorization checks, Lock Handling, and other operations may be invoked.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 6, the rejection of claim 1 is incorporated.
The combination of Kuboniwa and William does not teach: wherein each model is a RESTful Application Programming (RAP) model defining the respective data entity.
However, in an analogous art Hrastnik teaches wherein each model is a RESTful Application Programming (RAP) model defining the respective data entity. (Hrastnik [0087], “In a programming model (e.g., an SAP RAP (Restful ABAP Programming Model) representation, the application stack may look as shown in the example of FIG. 3. The application stack depicted in FIG. 3, including a UI 305, a BO projection 310, a BO 315, and a database layer 320, might be representative of many different applications. In FIG. 3, both the data and operation flow are based on service invocations between the different representations/realizations of the business objects within the application stack. The infrastructure (i.e., system and methods) disclosed herein establishes mappings between the different services down to the detailed aspects of the BO models (entities, relations, fields and operations).”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 7, the rejection of claim 1 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the generation of the test executable code further comprises processor-executable program code to cause the system to: dynamically generate at least one Entity Manipulation Language (EML) test executable code query based on the model framework;
execute each EML test executable code query.
However, in an analogous art Hrastnik teaches wherein the generation of the test executable code further comprises processor-executable program code to cause the system to: dynamically generate at least one Entity Manipulation Language (EML) test executable code query based on the model framework; (Hrastnik [0158-159], “In some embodiments, the disclosed infrastructure may derive the SQL statement (e.g. in ABAP) depicted in FIG. 39 from the referenced service mapping definition and the concrete request instruction…In some embodiments for simplifying the usage of the infrastructure's generic service wrapper functionality, such sample code snippets could be generated by the infrastructure. The generated logic (e.g., the discussed SQL select statement) might also be provided to developers by the infrastructure for increasing the efficiency of the development process and supporting the creation of automated tests, including tests independent from the direct usage of the core infrastructure functionality.”) [Examiner’s Note: EML is a type of ABAP Querying language. A request to generate SQL code snippets in ABAP encompasses EML code.] and
execute each EML test executable code query. (Hrastnik [0163], “For the actual service mapping and composition, from a perspective of the disclosed infrastructure, only those steps that can directly be addressed by a service consumer (e.g., in this case by an OData and/or an EML consumer) may be of interest. These particular steps are highlighted in FIGS. 43 at 4305, 4310, and 4315. In greater detail, the first functional OData call may have the form as shown in FIG. 44. That is, the UI action “Activate” is bound to the OData action “ActivateProduct” and the entity instance that is identified by the property evaluation “ID”=“MON_1”. This OData action in turn invokes the action, depicted in FIG. 45, on the EML (Entity Manipulation Language) level.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 8, the rejection of claim 7 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the at least one EML test query is generated for each operation supported by the model.
However, in an analogous art Hrastnik teaches wherein the at least one EML test query is generated for each operation supported by the model. (Hrastnik [0163], “For the actual service mapping and composition, from a perspective of the disclosed infrastructure, only those steps that can directly be addressed by a service consumer (e.g., in this case by an OData and/or an EML consumer) may be of interest. These particular steps are highlighted in FIGS. 43 at 4305, 4310, and 4315. In greater detail, the first functional OData call may have the form as shown in FIG. 44. That is, the UI action “Activate” is bound to the OData action “ActivateProduct” and the entity instance that is identified by the property evaluation “ID”=“MON_1”. This OData action in turn invokes the action, depicted in FIG. 45, on the EML (Entity Manipulation Language) level.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 13, Kuboniwa teaches
receiving a request to execute a test executable code for a first model of one or more models, each model defining a respective data entity; (Kuboniwa [0050], “The test scenario information 312 is information in which the contents of individual test scenarios constituting a combined test, parameters used for the test, test data, and the like are defined. Each of test scenarios is a unit test that can be executed by one of the test automation tool 401 and the like, and a content of each of these test scenarios is a process or the like executed individually for the information system 1000 [defining a respective data entity]. Further, a content of each of the test scenarios is a process independent of other test scenarios [one or more models, each model]. Further, each of the test scenarios may be defined in a plurality of combined tests.”)
Kuboniwa does not teach: identifying a model framework for the first model, the identified model framework including a model structure defining fields for the data entity, a model definition defining operations performable by the data entity and a corresponding runtime implementation;
generating an output via execution of the test executable code; and
reporting an analysis of the generated output.
However, in an analogous art William teaches identifying a model framework for the first model, […] (William [0034], “To generate the script execution framework, a selection of a script-pattern residing in a data source--is received. Source tags corresponding to the selected script-pattern are determined, to be able to receive an input. From an associated user interface, business intelligence (BI) script is received as an input to the source tags, to execute the business process. The BI script received from the UI is embedded with the selected script-pattern to generate a BI source code. The generated BI source code is validated and processed to generate the script execution framework. Such a generated BI script execution framework is operable to simulate the business process and generate a corresponding BI report, which can be used for decision-making.”)
generating an output via execution of the test executable code; and
reporting an analysis of the generated output. (William [0020], “Upon receiving the trigger to simulate the execution from UI component 215, query module 235 associated with script execution framework 220 generates a query by determining a plurality of result objects and a plurality of query filters [generate an output via execution of the test executable code]. Result objects and query filters represent a plurality of source tags operable to receive an input. Based upon the input to the source tags associated with the script-pattern, an analytical report is generated as a resultant of the execution of the business process. Result objects may include a plurality of fields that are represented as report fields the analytical report, and the query filters may include a plurality of conditions to be satisfied to generate the analytical report [report an analysis of the generated output].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
The combination of Kuboniwa and William does not teach: [identifying a model framework for the first model,] the identified model framework including a model structure defining fields for the data entity, a model definition defining operations performable by the data entity and a corresponding runtime implementation;
However, in an analogous art Hrastnik teaches […] the identified model framework including a model structure defining fields for the data entity, a model definition defining operations performable by the data entity and a corresponding runtime implementation; (Hrastnik [0087], “In a programming model (e.g., an SAP RAP (Restful ABAP Programming Model) representation, the application stack may look as shown in the example of FIG. 3. The application stack depicted in FIG. 3, including a UI 305, a BO projection 310, a BO 315, and a database layer 320, might be representative of many different applications. In FIG. 3, both the data and operation flow are based on service invocations between the different representations/realizations of the business objects within the application stack. The infrastructure (i.e., system and methods) disclosed herein establishes mappings between the different services down to the detailed aspects of the BO models (entities, relations, fields and operations).”)
dynamically generating the test executable code for the first model as an Entity Manipulation Language (EML) test executable code query, the generated test executable code based on the identified model framework; (Hrastnik [0158-159], “In some embodiments, the disclosed infrastructure may derive the SQL statement (e.g. in ABAP) depicted in FIG. 39 from the referenced service mapping definition and the concrete request instruction…In some embodiments for simplifying the usage of the infrastructure's generic service wrapper functionality, such sample code snippets could be generated by the infrastructure. The generated logic (e.g., the discussed SQL select statement) might also be provided to developers by the infrastructure for increasing the efficiency of the development process and supporting the creation of automated tests, including tests independent from the direct usage of the core infrastructure functionality.”) [Examiner’s Note: EML is a type of ABAP Querying language. A request to generate SQL code snippets in ABAP encompasses EML code.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 14, the rejection of claim 13 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the operations supported by the model are at least one of a create operation, a read operation, an update operation, a delete operation, an execute operation, a validate locks operation, and an authorization verification operation.
However, in an analogous art Hrastnik teaches wherein the operations supported by the model are at least one of a create operation, a read operation, an update operation, a delete operation, an execute operation (Hrastnik [0075], “In some aspects, the mappings (also referred to as mapping information herein) may be captured as an abstract definition of service operations that cover different service operations (e.g., create, read, update, delete and execute (CRUDE) operations). When composing new services/applications, statically or dynamically, these definitions may be used to realize the service requirements of the users on the requested concrete technical protocol level, such as an OData level.”), a validate locks operation, and an authorization verification operation. (Hrastnik [0162], “At this point, the tracing can be stopped and the recorded trace can be evaluated. As illustrated in FIG. 43, the traced interaction shows that there are a plurality of processing steps being executed in the context of the processed status transition. The trace reveals framework internal processing logic, general processing steps, etc. For example, steps such as, Start Authorization check, Instance Authorization checks, Lock Handling, and other operations may be invoked.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 16, Kuboniwa teaches
receiving a request to execute a test executable code for a first model of one or more models, each model defining a respective data entity; (Kuboniwa [0050], “The test scenario information 312 is information in which the contents of individual test scenarios constituting a combined test, parameters used for the test, test data, and the like are defined. Each of test scenarios is a unit test that can be executed by one of the test automation tool 401 and the like, and a content of each of these test scenarios is a process or the like executed individually for the information system 1000 [defining a respective data entity]. Further, a content of each of the test scenarios is a process independent of other test scenarios [one or more models, each model]. Further, each of the test scenarios may be defined in a plurality of combined tests.”)
Kuboniwa does not teach: identifying a model framework for the first model;
generating an output via execution of the test executable code; and
reporting an analysis of the generated output.
However, in an analogous art William teaches identifying a model framework for the first model; (William [0034], “To generate the script execution framework, a selection of a script-pattern residing in a data source--is received. Source tags corresponding to the selected script-pattern are determined, to be able to receive an input. From an associated user interface, business intelligence (BI) script is received as an input to the source tags, to execute the business process. The BI script received from the UI is embedded with the selected script-pattern to generate a BI source code. The generated BI source code is validated and processed to generate the script execution framework. Such a generated BI script execution framework is operable to simulate the business process and generate a corresponding BI report, which can be used for decision-making.”)
generating an output via execution of the test executable code; and
reporting an analysis of the generated output. (William [0020], “Upon receiving the trigger to simulate the execution from UI component 215, query module 235 associated with script execution framework 220 generates a query by determining a plurality of result objects and a plurality of query filters [generate an output via execution of the test executable code]. Result objects and query filters represent a plurality of source tags operable to receive an input. Based upon the input to the source tags associated with the script-pattern, an analytical report is generated as a resultant of the execution of the business process. Result objects may include a plurality of fields that are represented as report fields the analytical report, and the query filters may include a plurality of conditions to be satisfied to generate the analytical report [report an analysis of the generated output].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
The combination of Kuboniwa and William does not teach: generating the test executable code for the first model as an Entity Manipulation Language (EML) test executable code query, the generated test executable code based on the identified model framework;
However, in an analogous art Hrastnik teaches generating the test executable code for the first model as an Entity Manipulation Language (EML) test executable code query, the generated test executable code based on the identified model framework; (Hrastnik [0158-159], “In some embodiments, the disclosed infrastructure may derive the SQL statement (e.g. in ABAP) depicted in FIG. 39 from the referenced service mapping definition and the concrete request instruction…In some embodiments for simplifying the usage of the infrastructure's generic service wrapper functionality, such sample code snippets could be generated by the infrastructure. The generated logic (e.g., the discussed SQL select statement) might also be provided to developers by the infrastructure for increasing the efficiency of the development process and supporting the creation of automated tests, including tests independent from the direct usage of the core infrastructure functionality.”) [Examiner’s Note: EML is a type of ABAP Querying language. A request to generate SQL code snippets in ABAP encompasses EML code.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Hrastnik into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a developer the means to create new services and applications that are optimized with service recomposing (Hrastnik [0067]).
With regards to claim 17, the rejection of claim 16 is incorporated.
Kuboniwa does not teach: wherein the model framework includes a model structure and a model definition.
However, in an analogous art William teaches wherein the model framework includes a model structure and a model definition. (William [0025], “A script-pattern may be a complete or an incomplete reusable solution that can be transformed to source code by appending corresponding inputs from client-side system 205. Such script-patterns are configurable depending on the selected data service provider and the business process to be executed [includes a model structure]. By doing so, a set of script-patterns are available for multiple executions of the business process associated with the data service provider, at various instances. To configure such script-patterns, pattern keys and display values are generated for the selected data service provider. Pattern keys and display values represent various functionalities and classifications of script-pattern. Utility methods and associated member variables are generated for the selected business process. Utility methods represent structures, collaborations, implementations, and various other contexts in which the script-pattern can be utilized [and a model definition]. Input member variables provided for such methods are applied according to documentation formats of the script-pattern. Based upon the input received for the pattern keys and the display values, the script-patterns may be configured for the corresponding business process.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of William into the teachings of Kuboniwa. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of simulating a business process ahead of actual execution through a script framework to bring awareness to source codes and execution outcomes (William [0015]).
Claims 9, 10, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William, as applied to claim 1, and further in view of US 20250173133 A1 hereinafter “Jain”.
With regards to claim 9, the rejection of claim 1 is incorporated.
Kuboniwa further teaches comprises processor-executable program code to cause the system to: generate an expected output; (Kuboniwa [0071], “At this time, the determination unit 346 may acquire an expected value of the combined test from the CMDB 200 and determine whether or not the combined test has been successfully performed using the expected value. Note that a part of the configuration information 210 in the CMDB 200 may be used as the expected value. By doing so, data in the configuration information database can be linked with a flow of the combined test.”)
The combination of Kuboniwa and William does not teach: assign the generated output to a category based on a comparison of the generated output to the expected output.
However, in an analogous art Jain teaches assign the generated output to a category (Jain [0077], “On the other hand, machine learning models trained using unsupervised learning algorithms may be used to group (e.g., C_1, C_2 . . . C_n 338) live data 334 based on how similar they are to one another to solve exploratory challenges where little is known about the data, provide a description or label (e.g., C_1, C_2 . . . C_n 338) to live data 334, such as in classification, and/or the like. These categorized outputs, groups (clusters), or labels are then presented to the user input system 130.”) based on a comparison of the generated output to the expected output. (Jain [0097], “For example, and in some embodiments, the application package orchestrator model may validate the at custom program action(s) it generated to resolve the computer-readable instruction(s) based on comparing the output of the custom program action (e.g., upon applying an example input) to an expected output and determining whether the output of the custom program action matches the expected output. In the instance where the output of the custom program action does not match the expected output, the custom program action may be determined to be invalid. In the instance where the output of the custom program action does match the expected output, the custom program action may be determined to be valid.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
With regards to claim 10, the rejection of claim 9 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the expected output is generated via execution of a Structured Query Language (SQL) query directly on a database table.
However, in an analogous art Jain teaches wherein the expected output is generated via execution of a Structured Query Language (SQL) query directly on a database table. (Jain [0089], “As shown in block 410, the process flow 400 may include the step of querying—by the application package orchestrator model—a programming template database based on the stepwise metadata package, wherein the programming template database comprises at least one pre-generated programming action. As used herein, the term “query” and/or “querying” refers to searching and/or submitting a request for a computer storage component (e.g., a programming template database) to search itself in order to find the computer component identified in the query [wherein the expected output is generated via execution of a Structured Query Language (SQL) query] (e.g., the pre-generated programming action that will resolve the computer-readable instruction(s) of the stepwise metadata packet). By way of example, the programming template database may comprise a plurality of pre-generated programming components (such as lines of code, a plurality of lines of code, databases, tables, indexes, files, and/or the like) [directly on a database table.] which may be used by the application package orchestrator model to build an application package (e.g., such as by combining the pre-generated programming components, filling in the necessary data from the stepwise metadata packet such as any inputs necessary for the instructions to be resolved, and/or the like) that resolves the instruction(s) received and/or identified from block 402.”) [Examiner’s Note: Submitting a query to a database can be executed through program instructions that comprise Structured Query Language]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
With regards to claim 12, the rejection of claim 9 is incorporated.
The combination of Kuboniwa and William does not teach: wherein the assignment is via execution of a machine learning algorithm.
However, in an analogous art Jain teaches wherein the assignment is via execution of a machine learning algorithm. (Jain [0064], “An NLP engine tuning engine 222 may be used to train the NLP engine 251 using the training data 218 to make predictions or decisions without explicitly being programmed to do so. The NLP engine 251 represents what was learned by a selected machine learning algorithm 220 and represents the rules, numbers, and any other algorithm-specific data structures required for classification.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William in view of Jain, as applied to claim 9, and further in view of US 20220374341 A1 hereinafter “Brown”.
With regards to claim 11, the rejection of claim 9 is incorporated.
The combination of Kuboniwa, William, and Jain does not teach: wherein the category is one of: “Correct data present for the entity” and “Incorrect data present for the entity”.
However, in an analogous art Brown teaches wherein the category is one of: “Correct data present for the entity” and “Incorrect data present for the entity”. (Brown [0171], “In some embodiments, if a corresponding workflow playback operation associated with a corresponding automated testing workflow step has successfully executed a captured user interaction associated with the corresponding automated testing workflow step with respect to a web environment defined by a corresponding automated testing workflow data entity that comprises the corresponding automated testing workflow step, then the success indicator for the corresponding workflow playback operation may be a positive value. [wherein the category is one of: “Correct data present for the entity”] In some embodiments, if a corresponding workflow playback operation associated with a corresponding automated testing workflow step has not successfully executed a captured user interaction associated with the corresponding automated testing workflow step with respect to a web environment defined by a corresponding automated testing workflow data entity that comprises the corresponding automated testing workflow step, then the success indicator for the corresponding workflow playback operation may be a negative value [and “Incorrect data present for the entity”.]. In some embodiments, the success indicator for a workflow playback operation that is associated with an automated testing workflow step may be negative if one of the following conditions is satisfied: (i) no interactive page element is detected at a page region of a corresponding webpage that is determined in accordance with the element location data for the automated testing workflow step; or (ii) an interactive page element is detected at a page region of a corresponding webpage that is determined in accordance with the element location data for the automated testing workflow step, but the detected interactive page element has an element type that is inconsistent with an element type of an interactive page element for the corresponding automated testing workflow step as determined in accordance with the element type data for the automated testing workflows step.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Brown into the teachings of Kuboniwa in view of William and further in view of Jain. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, to analyze and classify the program results with the use of a predetermined expected output, as in Jain, the classification of the business step output as success or failure according to testing prerequisite analysis, as in Brown. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using a test case data entity to define execution conditions, expected results, and objectives that a test is expected to achieve in order to determine verification (Brown [0040]).
Claims 15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William in view of Hrastnik, as applied to claims 13 and 16, and further in view of Jain.
With regards to claim 15, the rejection of claim 13 is incorporated.
The combination of Kuboniwa William and Hrastnik does not teach: executing a Structured Query Language (SQL) query directly on a database table to generate an expected output; and
assigning the generated output to a category based on a comparison of the generated output to the expected output.
However, in an analogous art Jain teaches executing a Structured Query Language (SQL) query directly on a database table to generate an expected output; (Jain [0089], “As shown in block 410, the process flow 400 may include the step of querying—by the application package orchestrator model—a programming template database based on the stepwise metadata package, wherein the programming template database comprises at least one pre-generated programming action. As used herein, the term “query” and/or “querying” refers to searching and/or submitting a request for a computer storage component (e.g., a programming template database) to search itself in order to find the computer component identified in the query [to generate an expected output] (e.g., the pre-generated programming action that will resolve the computer-readable instruction(s) of the stepwise metadata packet). By way of example, the programming template database may comprise a plurality of pre-generated programming components (such as lines of code, a plurality of lines of code, databases, tables, indexes, files, and/or the like) [directly on a database table.] which may be used by the application package orchestrator model to build an application package (e.g., such as by combining the pre-generated programming components, filling in the necessary data from the stepwise metadata packet such as any inputs necessary for the instructions to be resolved, and/or the like) that resolves the instruction(s) received and/or identified from block 402.”) [Examiner’s Note: Submitting a query to a database can be executed through program instructions that comprise Structured Query Language] and
assigning the generated output to a category (Jain [0077], “On the other hand, machine learning models trained using unsupervised learning algorithms may be used to group (e.g., C_1, C_2 . . . C_n 338) live data 334 based on how similar they are to one another to solve exploratory challenges where little is known about the data, provide a description or label (e.g., C_1, C_2 . . . C_n 338) to live data 334, such as in classification, and/or the like. These categorized outputs, groups (clusters), or labels are then presented to the user input system 130.”) based on a comparison of the generated output to the expected output. (Jain [0097], “For example, and in some embodiments, the application package orchestrator model may validate the at custom program action(s) it generated to resolve the computer-readable instruction(s) based on comparing the output of the custom program action (e.g., upon applying an example input) to an expected output and determining whether the output of the custom program action matches the expected output. In the instance where the output of the custom program action does not match the expected output, the custom program action may be determined to be invalid. In the instance where the output of the custom program action does match the expected output, the custom program action may be determined to be valid.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William and further in view of Hrastnik. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
With regards to claim 18, the rejection of claim 16 is incorporated.
The combination of Kuboniwa, William, and Hrastnik does not teach: executing a Structured Query Language (SQL) query directly on a database table to generate an expected output; and
assigning the generated output to a category based on a comparison of the generated output to the expected output.
However, in an analogous art Jain teaches executing a Structured Query Language (SQL) query directly on a database table to generate an expected output; (Jain [0089], “As shown in block 410, the process flow 400 may include the step of querying—by the application package orchestrator model—a programming template database based on the stepwise metadata package, wherein the programming template database comprises at least one pre-generated programming action. As used herein, the term “query” and/or “querying” refers to searching and/or submitting a request for a computer storage component (e.g., a programming template database) to search itself in order to find the computer component identified in the query [to generate an expected output] (e.g., the pre-generated programming action that will resolve the computer-readable instruction(s) of the stepwise metadata packet). By way of example, the programming template database may comprise a plurality of pre-generated programming components (such as lines of code, a plurality of lines of code, databases, tables, indexes, files, and/or the like) [directly on a database table.] which may be used by the application package orchestrator model to build an application package (e.g., such as by combining the pre-generated programming components, filling in the necessary data from the stepwise metadata packet such as any inputs necessary for the instructions to be resolved, and/or the like) that resolves the instruction(s) received and/or identified from block 402.”) [Examiner’s Note: Submitting a query to a database can be executed through program instructions that comprise Structured Query Language] and
assigning the generated output to a category (Jain [0077], “On the other hand, machine learning models trained using unsupervised learning algorithms may be used to group (e.g., C_1, C_2 . . . C_n 338) live data 334 based on how similar they are to one another to solve exploratory challenges where little is known about the data, provide a description or label (e.g., C_1, C_2 . . . C_n 338) to live data 334, such as in classification, and/or the like. These categorized outputs, groups (clusters), or labels are then presented to the user input system 130.”) based on a comparison of the generated output to the expected output. (Jain [0097], “For example, and in some embodiments, the application package orchestrator model may validate the at custom program action(s) it generated to resolve the computer-readable instruction(s) based on comparing the output of the custom program action (e.g., upon applying an example input) to an expected output and determining whether the output of the custom program action matches the expected output. In the instance where the output of the custom program action does not match the expected output, the custom program action may be determined to be invalid. In the instance where the output of the custom program action does match the expected output, the custom program action may be determined to be valid.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William and further in view of Hrastnik. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
With regards to claim 20, the rejection of claim 18 is incorporated.
The combination of Kuboniwa, William, and Hrastnik does not teach: wherein the assignment is via execution of a machine learning algorithm.
However, in an analogous art Jain teaches wherein the assignment is via execution of a machine learning algorithm. (Jain [0064], “An NLP engine tuning engine 222 may be used to train the NLP engine 251 using the training data 218 to make predictions or decisions without explicitly being programmed to do so. The NLP engine 251 represents what was learned by a selected machine learning algorithm 220 and represents the rules, numbers, and any other algorithm-specific data structures required for classification.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Jain into the teachings of Kuboniwa in view of William and further in view of Hrastnik. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik, to analyze and classify the program results with the use of a predetermined expected output, as in Jain. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of determining whether a current application needs to be uninstalled, installed, and/or upgraded based on a variety of categorizations (Jain [0087-88]).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Kuboniwa in view of William in view of Hrastnik in view of Jain, as applied to claim 18, and further in view of Brown.
With regards to claim 19, the rejection of claim 18 is incorporated.
The combination of Kuboniwa, William, Hrastnik, and Jain does not teach: wherein the category is one of: “Correct data present for the entity” and “Incorrect data present for the entity”.
However, in an analogous art Brown teaches wherein the category is one of: “Correct data present for the entity” and “Incorrect data present for the entity”. (Brown [0171], “In some embodiments, if a corresponding workflow playback operation associated with a corresponding automated testing workflow step has successfully executed a captured user interaction associated with the corresponding automated testing workflow step with respect to a web environment defined by a corresponding automated testing workflow data entity that comprises the corresponding automated testing workflow step, then the success indicator for the corresponding workflow playback operation may be a positive value. [wherein the category is one of: “Correct data present for the entity”] In some embodiments, if a corresponding workflow playback operation associated with a corresponding automated testing workflow step has not successfully executed a captured user interaction associated with the corresponding automated testing workflow step with respect to a web environment defined by a corresponding automated testing workflow data entity that comprises the corresponding automated testing workflow step, then the success indicator for the corresponding workflow playback operation may be a negative value [and “Incorrect data present for the entity”.]. In some embodiments, the success indicator for a workflow playback operation that is associated with an automated testing workflow step may be negative if one of the following conditions is satisfied: (i) no interactive page element is detected at a page region of a corresponding webpage that is determined in accordance with the element location data for the automated testing workflow step; or (ii) an interactive page element is detected at a page region of a corresponding webpage that is determined in accordance with the element location data for the automated testing workflow step, but the detected interactive page element has an element type that is inconsistent with an element type of an interactive page element for the corresponding automated testing workflow step as determined in accordance with the element type data for the automated testing workflows step.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Brown into the teachings of Kuboniwa in view of William in view of Hrastnik and further in view of Jain. This combination of teachings would have resulted in a system containing multiple business scenario models for testing, as in Kuboniwa, with a model framework for execution of test scripts to generate an analysis of the output thereby, as in William, wherein the model enables multiple operations in accordance with the business process scenario, as in Hrastnik, to analyze and classify the program results with the use of a predetermined expected output, as in Jain, the classification of the business step output as success or failure according to testing prerequisite analysis, as in Brown. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using a test case data entity to define execution conditions, expected results, and objectives that a test is expected to achieve in order to determine verification (Brown [0040]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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 Mui can be reached at 571-272-3708. 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191