DETAILED ACTION
Remarks
Applicant presents a communication filed 31 July 2025 responsive to the 15 May 2025 non-final Office action (the “Previous Action”).
Claims 1, 26 and 32 are amended.
Claims 1 and 21-37 are pending. Claims 1, 26 and 32 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Response to Arguments
Claim Rejections under 35 U.S.C. § 112
Applicant suggest that the claims have been amended to address these rejections. (Remarks, pp. 9-10 Section IV). Examiner respectfully disagrees for the reasons set forth below. Applicant presents no analysis to the contrary.
Claim Rejections under 35 U.S.C. § 103
Applicant argues with respect to claim 1 that the cited references do not teach or suggest to “identify, by the test manager, a plurality of test plan units, the plurality of generated test plan units comprising asset-based test units generated from artifacts of the migrated application based on configuration files of the migrated application, and risk-based test units generated from conversion rules that define changes made tot eh application for executing the application on the rehosting platform.” (Remarks, p. 12, 2nd to last par.)
This argument is moot in view if the new ground(s) of rejection necessitated by Applicant’s amendments. Note however, at least portions of the above features are taught by the previously cited references as set forth below.
Applicant’s arguments with respect to the remaining claims by virtue of their dependency from claim 1, similarity with claim 1 or dependence from a similar claim are moot for the same reasons.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
The “…capture, via a test driver…a baseline execution record…” in claim 1;
The “…the test driver being configured to capture baseline execution…” in claim 1;
The “…using a test execution driver, capture a sequence of jobs…” in claim 21;
The “…wherein the test execution driver is configured to automatically test the software application…” in claim 22;
The “…wherein the test execution driver operations…to provide an indication of migration success…” in claim 23;
The to “…capture, via a test driver…a baseline execution record…” in claim 26;
The “…the test driver being configured to capture baseline execution…” in claim 26;
The “…test manager configured to…determine an indication of migration success…” in claim 26;
The “…using a test execution driver, capture a sequence of jobs…” in claim 27;
The “…wherein the test execution driver is configured to automatically test the software application…” in claim 28;
The “…wherein the test execution driver operations…to provide an indication of migration success…” in claim 29;
The to “…capture, via a test driver…a baseline execution record…” in claim 32;
The “…the test driver being configured to capture baseline execution…” in claim 32;
The “…using a test execution driver, capture a sequence of jobs…” in claim 33;
The “…wherein the test execution driver is configured to automatically test the software application…” in claim 34;
The “…wherein the test execution driver operations…to provide an indication of migration success…” in claim 35.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 1 and 21-37 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.
LACK OF CORRESPONDING STRUCTURE IN THE SPECIFICATION FOR MEAN-PLUS-FUNCTION LIMITATIONS
As to claim 1, the limitations of this claim noted above all invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph as noted. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions of the limitations and to clearly link the structure, material, or acts to the functions. Note that for computer-implemented means plus function limitations, the disclosed structure must include an algorithm for performing the function claimed. See MPEP § 2181(II)(B). And the specification provides no algorithm sufficient for performing any of the claimed functions here. It does little more than repeat the language of the claims.
Since the specification lacks sufficient corresponding structure, the claims reciting these limitations are indefinite and an equivalent is any element that performs the specified function. See M.P.E.P. §§ 2181(II)(B) and 2185.
As to claims 21-25, the claims are dependent on claim 1, do not cure the deficiencies of that claim and are rejected for the same reasons.
Further as to claims 21-23, the means plus function limitations of these claims lack sufficient corresponding structure as well, for reasons substantially the same as those set forth above with respect to claim 1, i.e., the written description fails to disclose the corresponding structure for performing the entire claimed functions of the limitations and to clearly link the structure, material, or acts to the functions.
As to claim 26, the means plus function limitations of this claim lack sufficient corresponding structure for reasons substantially the same as those set forth above with respect to claim 1.
As to claims 27-31, the claims are dependent on claim 26, do not cure the deficiencies of that claim and also include means plus function limitations lacking sufficient corresponding structure as well, for reasons substantially the same as those set forth above.
Further as to claims 27-29, the means plus function limitations of these claims lack sufficient corresponding structure as well, for reasons substantially the same as those set forth above with respect to claim 1.
As to claim 32, the means plus function limitations of this claim lack sufficient corresponding structure for reasons substantially the same as those set forth above with respect to claim 1.
As to claims 33-37, the claims are dependent on claim 32, do not cure the deficiencies of that claim and also include means plus function limitations lacking sufficient corresponding structure as well, for reasons substantially the same as those set forth above.
Further as to claims 33-25, the means plus function limitations of these claims lack sufficient corresponding structure as well, for reasons substantially the same as those set forth above with respect to claim 1.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
OTHER INDEFINITENESS
As to claim 1, the claim refers to “the plurality of generated test plan units” at lines 24-25. There is insufficient antecedent basis for this limitation in the claim and it is unclear to which previously recited element, if any, the claim is referring. For the purposes of examination, “the plurality of generated test plan units” will be interpreted as -the plurality of identified test plan units-.
As to claims 21-25, the claims are dependent on claim 1, do not cure the deficiencies of that claim and are rejected for the same reasons.
As to claim 26, the claim includes the same indefinite limitations as claim 1 and is rejected for the same reasons. for reasons substantially the same as those set forth above with respect to claim 1.
As to claims 27-31, the claims are dependent on claim 26, do not cure the deficiencies of that claim and also include means plus function limitations lacking sufficient corresponding structure as well, for reasons substantially the same as those set forth above.
As to claim 32, the claim includes the same indefinite limitations as claim 1 and is rejected for the same reasons. for reasons substantially the same as those set forth above with respect to claim 1.
As to claims 33-37, the claims are dependent on claim 32, do not cure the deficiencies of that claim and also include means plus function limitations lacking sufficient corresponding structure as well, for reasons substantially the same as those set forth above.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 and 21-37 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As to claims 1 and 21-37, the claims include means-plus function limitations lacking sufficient corresponding structure as noted above. Such limitations also lack written description. See M.P.E.P. § 2163.03(VI).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 24-26, 30-32, 36 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Ding (“Splitter: A Proxy-based Approach for Post-Migration Testing of Web Applications”) in view of Oracle (“Oracle Tuxedo Application Runtime for CICs and Batch”), Pasala et al. (US 2012/0254665) (art of record – hereinafter Pasala), Humelsine (US 5,694,540) (art made of record – hereinafter Humelsine) and Allocca (US 9,483,387) (art of record – hereinafter Allocca).
As to claim 1, Ding discloses a system for capturing a baseline execution of a deployed software application of a deployed software application, for use during migration and assessment of the software application from a source computing platform to a target platform (see below), comprising:
a computer comprising a microprocessor and a memory; (see below, a computer necessarily comprises a microprocessor and memory)
a test manager running in a server provided at the computer, (e.g., Ding, p. 97 left col. par. 2: Splitter, a software module; p. 98 Figure 1 and associated text [see figure, Splitter provides (serves) responses to users, making it a server. Its internal components shown are together a test manager]; p. 104 left col. Sec. 3.1 par 1: Splitter is deployed on a Dell Dimension 3100 desktop [computer]) wherein the test manager performs steps comprising:
capture, via a test driver of the test manager from the source computing platform at a network data stream layer, a baseline execution record, at a network data stream layer, describing an online execution of a software application at the source computing platform (e.g., Ding, p. 109 right col. par. 5: Splitter can be integrated with a Web proxy or a load balancer that has already been deployed in a production system; p. 1 left col. par. 2 disclose a proxy [test driver] is put in front of the production application to intercept requests from real users [baseline from an online execution, at a network data stream layer because the data captured is a data stream]; p. 3, Fig. 2 and associated text, left col. Sec. 2.1 par. 2 discloses we call this component a Proxy. This is placed on the critical path to the production application [see figure, the requests are directed to (executed against) the production application]; p. 8 left col. Sec. 3.2 discloses two instances of each application are set up on both the production and migrated systems [platforms, the production system being a source computing platform]) the captured baseline execution record comprising job execution sequences, (e.g., Ding, left col. Sec. 4.2: there are 3 separates streams of request response traffic—(A) user to Splitter, (B) Splitter to production and (C) Splitter to migrated application. We would like to preserve the order of requests in stream A to those of B and C [ the requests (jobs) captured comprise a sequence because they have an order]) input files, output files, (e.g., Ding, p. 107 left col. par. 2: data files used by Splitter to store request [input] and response [output] data) terminal interactions (e.g., Ding, p. 100 left col. Sec. 2.2.2 par. 2: if the user clicks on the link [a terminal interaction, the user’s computer being a terminal], the browser will generate a GET request; p. 1, p. 1 left col. par. 2 disclose a proxy is put in front of the production application to intercept requests from real users) and message interactions (e.g., Ding, p. 102 left col. Sec. 2.3.4 Figure 7 shows responses of a real Web forum page [and see figure, it comprises “Recently Posted Messages”), the test driver being configured to capture baseline execution for applications, interactive online applications, and message-driven online applications (e.g., Ding, p. 98 right col. last par.: to observe the behavior of Web [online] applications, Splitter provides 3 capabilities: i) capture user requests [and see above, since requests from user interactions such as clicking on a link and responses such as message posts are captured, the baseline execution captured by the driver noted above includes interactive applications message-driven applications]) and
replay the captured baseline record against an instance of the software application executing at the rehosting platform, for use with the target computing platform; (e.g., Ding, p. 3 left col. Sec. 2.1 par. 2 discloses upon receiving a user request Proxy passes the request to the production application. Once the request is sent, it makes a replica of the request and sends it to the Session Manager, which will make any necessary instrumentations before passing it to the migrated application; p. 8 left col. Sec. 3.2 discloses two instances of each application are set up on both the production and migrated systems [platforms, the migrated system being both a rehosting platform and a target computing platform. Note that the rehosting platform and target platform of the specification are the same as well (Tuxedo ART). See, e.g., paragraphs [000142], par. [00025] and Figure 1 element 101 of the instant specification]) and
compare corresponding data streams and interface screens from execution of the software application at both of source computing platform and the rehosting platform, to determine an indication of migration success of the platform when migrated from the source computing platform to the target computing platform (e.g., Ding, p. 1 left col. par. 2 discloses results generated by both applications are then compared, and mismatches due to migration problems can be detected; p. 5 right col. Sec. 2.3.2 discloses for binary contents [data streams, or part of data streams], we only need to know whether two binary objects are the same or not. For text/plain [data stream, or part of one] and text/HTML contents, we do a more in-depth analysis; p. 5 Sec. 2.3.3 last par. discloses SES is not very useful for comparing HTML pages [screens]. Therefore, we convert HTML data to DOM tree format. Analysis engine compares two trees node-by-node)
changes made to the application for executing the application on the rehosting platform (e.g., Ding, p. 97 right col. last par. – p. 98 left col. par. 1: even though code change is usually not needed for migration, many applications require configuration or tweaking after they are migrated to accommodate changes in the target environment)
comparing the corresponding data streams and interface screens from execution of the software application at both the source computing platform and the rehosting platform (see above, since the results are generated by both applications [production and migrated instances, see above], they are from execution of the application at both the production system [source computing platform] and the migrated system [rehosting platform]) and
screen fields (e.g., Ding, p. 1 left col. par. 2 disclose results generated by both applications are compared; p. 5 right col. last par. and p. 7 Figure 9: comparing HTML pages [screens, and note from figure 9 that the screens can include fields]).
Ding does not explicitly disclose a rehosting platform provided at the computer, wherein the rehosting platform comprises a plurality of application runtimes for executing a plurality of software applications migrated from a source computer at a source computing platform; batch applications, to identify, by the test manager, a plurality of test plan units, the plurality of generated test plan units comprising asset-based test units generated from artifacts of the migrated application based on configuration files of the migrated application, and risk-based test units generated from conversion rules that define changes made to the application for executing the application; and to determine another indication of migration success by executing one or more generated test plan sequences against the rehosting platform, each of the one or more generated test plan sequences comprising a set of the identified plurality of test plan units, at least one of the one or more generated test plan sequences being generated based upon a scan, by the test manager, of configuration files of the software application at the rehosting platform, wherein at least another of the generated one or more test plan sequences is generated based upon a review, made by the test manager, of a log associated with the capture baseline execution record; or wherein the comparing the corresponding data streams and interface screens automatically excludes from the comparison one or more screen fields, the one or more fields being defined by the test manager.
However, in an analogous art, Oracle discloses:
a rehosting platform provided at the computer, wherein the rehosting platform that comprises a plurality of application runtimes for executing a plurality of software applications migrated from a source computer at a source computing platform; (e.g., Oracle, p. 1 Figure 1 and par. 1: Oracle Tuxedo Application Runtime for CICS and Batch [necessarily executing on a microprocessor of a computer] runs IBM mainframe [source computing platform] applications rehosted [migrated] to Oracle Tuxedo [the applications at the mainframe necessarily from a computer]; p. 1 Figure 1 last paragraph: rehosted CICS application run in Tuxedo containers using the programming model and services provided by the CICs runtime. Rehosted batch jobs run under the batch runtime [see figure Tuxedo includes both a CICS and Batch runtime])
batch applications (e.g., Oracle, p. 1 par. 2: Oracle Tuxedo Application Runtime for CIC and Batch helps organizations migrate online and batch mainframe applications)
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding, which discloses migrating an application to a new platform by including to include a rehosting platform comprising a plurality of application runtimes for executing software applications migrated from a source computer at the source computing platform, as taught by Oracle, as Oracle would provide the advantage of a means of running migrated mainframe applications with no change to business logic. (See Oracle, p. 1 par. 1).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify the capturing the baseline execution of applications taught by Ding such that those applications include batch applications, as taught by Oracle, as Oracle would provide the advantage of a means of testing migrations of those types of applications. (See Ding, p. 1 Abstract par. 2, Oracle, p. 1 par. 2).
Further, in an analogous art, Pasala discloses to:
identify, by the test manager, a plurality of test plan units, the plurality of generated test plan units comprising asset-based test units generated from artifacts of the migrated application based on configuration files of the migrated application, (e.g., Pasala, abstract: generating functional tests to verify code migrated from a first host to a second host; par. [0025]: the parser [test manager, or part of one] can parse the UI code for all data fields [artifacts] and capture their variable names as input parameters [also artifacts] and the non-editable fields as output parameters; par. [0053]: the input and output variables are extracted in process block 1052 from UI description files 1054 [configuration files]; par. [0026]: in block 420, interactions can be modeled. The set of input and output parameters are linked together to form a CFG. The CFG can show all paths through the application; par. [0032]: in block 430, test scenarios [test units] are formed. Every independent path corresponds to a test scenario).
determine another indication of migration success by executing one or more generated test plan sequences against the rehosting platform, (e.g., Pasala, par. [0004]: for proper migration, the re-hosted applications need to be verified for its original functionality on the new systems. To ascertain the accuracy of the original functionality, organizations perform system testing of re-hosted application in new environments using test cases; par. [0023]: all of the test scenarios together form the functional test suite [one or more generated test plan sequences]; Fig. 9 and associated text, par. [0052]: A sample test scenarios is shown in FIG. 9 [see figure, “Scenario/Test Cases”, i.e., scenarios are test cases]; par. [0006]: once these test cases are executed successfully, it is assumed that the re-hosting or migration is successful) each of the one or more generated test plan sequence comprising a set of the identified plurality of test plan units, (e.g., Pasala, par. [0023]: all of the test scenarios [test plan units] together form the functional test suite [test plan sequences]) at least one of the one or more generated test plan sequences being generated based upon a scan, by the test manager, of configuration files of the software application at the rehosting platform (e.g., Pasala, Fig, 4 and associated text, par. [0025]: the parser [test manager, or part of one] can parse [scan] the UI code for all data fields and capture their variable names as input parameters and the non-editable fields as output parameters; par. [0053]: the input and output variables are extracted in process block 1052 from UI description files 1054 [configuration files]; par. [0026]: the set of input and output parameters are linked together to form a CFG. The CFG can show all paths through the application; par. [0032]: in block 430, test scenarios are formed. Every independent path corresponds to a test scenario; par. [0023]: all the test scenarios together form the functional test suite).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify the test manager and determining of migration success using replayed baselines taught by Ding, such that the test manager identifies a plurality of test plan units comprising asset-based test units generated from artifacts of the migrated application based on the test manager scanning configuration files of the migrated application and determining another indication of migration success by executing one or more test plan sequences comprising a set of the identified test plan units against the rehosting platform, as taught by Pasala, as Pasala would provide the advantage of a means of ensuring all paths of the re-hosted application are tested. (See Pasala, par. [0010]).
Further still, in an analogous art, Humelsine discloses to:
identify a plurality of risk-based test units generated from conversion rules that define changes made to the application; (e.g., Hulesine, col. 2 l. 4: Modification Request (MR) [conversion rule]; col. 2 ll. 19-25: a MR is taken to mean a mechanism that is used to identify [define] changes to a software program [application]; col. 5 ll. 23-48: program 10 sends the resulting list of MRs to program 15. Program 15 scans database 20 to identify the pathnames to all test cases [test units] associated with the MRs; Program 10 instructs program 15 to execute the test cases).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the changing of an application for executing the application on the rehosting platform taught by Ding to include identifying risk-based test units generated from conversion rules that define the changes made to the application, as taught by Humelsine, as Humelsine would provide the advantage of a means of determining whether or not changes have affected some other aspect of the application. (See Humelsine, abstract).
Finally in an analogous art, Allocca discloses:
wherein at least another of the generated one or more test plan sequences is generated based upon a review, made by the test manager, of a log associated with the captured baseline execution record (e.g., Allocca, col. 11 ll. 50-54: service 118 may request replay of a set of intercepted requests 124 represented in the logs generated by the request log generator 222. To select the one or more logged or stored intercepted requests 124 to be replayed, the service 118 [test manager] may provide search capability for stored requests [searching the log being reviewing it]; col. 17 ll. 23-29 the logged intercepted requests may be stored in a searchable catalog organized in a hierarchical manner. For example, the following may be paths in the hierarchy: NA->US->Company the retailer->digital items->address is in New York. For each node in the hierarchy, the testing service may provide support to replay all or a subset of the intercepted requests under that node [each path, or the intercepted requests for the path being a test plan sequence]).
wherein the comparing automatically excludes from the comparison one or more fields, the one or more fields being defined by the test manager (e.g., Allocca, col. 23 ll. 29-31 discloses ignored fields may be defined to avoid differences; col. 23 ll. 50-57 discloses in a candidate test scenario in which the user knows that item “a” has been removed and item “d” has been added, this mismatch is an expected result and inclusion in the candidate test differences may not be desired. Thus, items “a” and “d” may be defined as ignored [the software used to do this being the test manager]; col. 25 ll. 23-28 discloses at 608, comparison module may determine if ignored fields are present. If so, the ignored fields are removed from the comparison operation or otherwise not considered in the comparison operation).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding, which discloses comparing data streams and interface screens including fields from execution of the software application at both of source computing platform and the rehosting platform, by incorporating filtering fields expected to be different from the comparison, as taught by Allocca, as Allocca would provide the advantages of a means of avoiding the identification of meaningless test differences and a means of achieving lower runtime complexity. (See Allocca, col. 23 ll. 30-40).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify the determining of migration success using replayed baselines taught by Ding, by incorporating generating one or more test plan sequences based upon a review, made by the test manager, of a log associated with the captured baseline execution record, as taught by Allocca, as Allocca would provide the advantage of a means of replaying a subset of tests and/or a particular path. (See Allocca, col. 17 ll. 23-29, col. 18 ll. 21-23).
As to claim 24, Ding/Oracle/Pasala/Humelsine/Allocca renders obvious the system of claim 1 (see rejection of claim 1 above), Ding further discloses wherein the test manager is further configured to:
record the baseline execution record describing an online execution of a software application at the source computing platform, including user interactions with the software application at the source computing platform; (e.g., Ding, p. 98 figure 1 and associated text, p. 97 left col. par. 2: to intercept requests from real users and the requests are sent to the production application; p. 104 left col. Sec. 3.1: a fully functional online store application; p. 107 left col. par. 2: data files used by Splitter to store request data) and
replay the captured the baseline execution record, including the user interactions, against an instance of the software application executing at the rehosting platform, for use with the target computing platform (e.g., Ding, p. 104 left col. Sec. 3.1 par. 1: Two Dell Optiplex desktops are used as production and migrated systems. We use Tomcat 5.5.27 as application server; p. 99 left col. Sec. 2.1: once the request is sent, it makes a replica of the request and sends it to the Session Manager, which, will make any necessary instrumentation before passing it to the migrated application).
As to claim 25, Ding/Oracle/Pasala/Humelsine/Allocca renders obvious the system of claim 1 (See rejection of claim 1 above), Ding further discloses:
wherein the test manager is further configured to execute jobs as test cases against both the computer and the rehosting platform (e.g., Ding, p. 3 left col. Sec. 2.1 par. 2 discloses upon receiving a user request Proxy passes the request to the production application. Once the request is sent, it makes a replica of the request and sends it to the Session Manager, which will make any necessary instrumentations before passing it to the migrated application [sending a request to an application (i.e., a request for the application to perform some task) being executing a job against the application]; p. 8 left col. Sec. 3.2 discloses two instances of each application are set up on both the production and migrated systems) and compare output files and return codes from both of the computer and the rehosting platform, to determine the migration success of the application migrated from the computer (e.g., Ding, p. 1 left col. par. 2 discloses results generated by both applications are then compared, and mismatches due to migration problems can be detected; p. 5 left col. Sec. 2.3.1 discloses when comparing HTTP headers, we focus on three fields, Status Code [return code], Content Type and Content Length; p. 5 right col. last par. discloses SES is not very useful for comparing HTML pages since two HTML document scan be semantically the same with many differences. Therefore, we convert HTML data top DOM tree format. Analysis Engine compares two trees node by node [i.e., comparing two HTML files]).
Ding does not explicitly disclose wherein the source computing platform is a mainframe computer; batch jobs; or the mainframe computer.
However, in an analogous art, Oracle discloses:
wherein the source computing platform is a mainframe computer; (e.g., Oracle, p. 1 Figure 1 and par. 1: IBM mainframe applications [necessarily on a computer] rehosted to Oracle Tuxedo).
batch jobs; (e.g., Oracle, p. 1 last par. discloses rehosted batch jobs run under the batch runtime) and
the mainframe computer (see above).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding, which discloses executing jobs as test cases against computer that is a source of migration and a rehosting platform and comparing output files and return codes from the computer and rehosting platform to determine migration success of the application migrated from the computer, by incorporating a mainframe computer as a source of the migration and batch jobs, as taught by Oracle, as Oracle would provide the advantages of a means of testing migrated batch applications and a means of migrating mainframe applications. (See Oracle, p. 1 par. 1).
As to claim 26, it is a method claim having limitations substantially the same as those of claim 1 and is rejected for substantially the same reasons.
As to claim 30, it is a method claim having limitations substantially the same as those of claim 24 and is rejected for substantially the same reasons.
As to claim 31, it is a method claim having limitations substantially the same as those of claim 25 and is rejected for substantially the same reasons.
As to claim 32, it is a medium claim having limitations substantially the same as those of claim 1 and is rejected for substantially the same reasons.
Further limitations, disclosed by Ding, include:
a non-transitory computer readable-medium storing instructions (e.g., Ding, p. 104 left col. Sec. 3.1: Splitter [test manager] is deployed on a desktop [i.e., in a non-transitory medium of the desktop]) for (see rejection of claim 1 above).
As to claim 36, it is a medium claim having limitations substantially the same as those of claim 24 and is rejected for substantially the same reasons.
As to claim 37, it is a medium claim having limitations substantially the same as those of claim 25 and is rejected for substantially the same reasons.
Claims 21-23, 27-29 and 33-35 are rejected under 35 U.S.C. 103 as being unpatentable over Ding (“Splitter: A Proxy-based Approach for Post-Migration Testing of Web Applications”) in view of Oracle (“Oracle Tuxedo Application Runtime for CICs and Batch”) in in view of Pasala (US 2012/0254665) in view of Humelsine (US 5,694,540) in view of Allocca (US 9,483,387) in further view of Huang et al. (US 2012/0047492) (art of record – hereinafter Huang).
As to claim 21, Ding/Oracle/Pasala/Humelsine/Allocca renders obvious the system of claim 1 (see rejection of claim 1 above), but does not explicitly disclose wherein the test manager is further configured to: capture a sequence of jobs associated with the software application at the source computing platform, using a test execution driver; and based upon the captured sequence of jobs associated with the software application, generate the one or more test plan sequences for automatic execution against the rehosting platform.
However, in an analogous art, Huang discloses:
wherein the test manager is further configured to:
using an execution driver, capture a sequence of jobs associated with the software application at the source computing platform; (e.g., Huang, par. [0011]: a testing tool observing real user traffic. Such a tool may store requests [jobs] and replies coming to and from the production system [source computing platform]) and
wherein at least another of the one or more generated test plan sequences for automatic execution against the rehosting platform is generated based upon the captured sequence of jobs associated with the software application, at the source computing platform (e.g., Huang, par. [0024]: modification and comparison tool 116 may modify the captured traffic 107 before replay. It may change IP addresses and DNS names in the traffic. The tool 116 may also strip out incoming traffic; par. [0026] a replay tool 122 obtains the to-be-replayed traffic 112 [test plan sequences] from the storage 110 “(with the modifications that the modification and comparison tool 116 may have made).” Reponses from the migrated application 108 corresponding to the replayed requests and stored in correct sequence with the requests).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding/Pasala, which discloses testing of a migrated application and generation of test plan sequences based upon a scan of configuration files, such that the test plan sequences include, in addition to test plan sequences generated based upon a scan of configuration files, at least one other test plan sequence generated based on capturing a sequence of jobs associated with the application at the source computing platform using a test execution driver, as taught by Huang, as Huang would provide the advantages of a means of performing off-line testing of the rehosting platform (see Huang, par. [0015]) and a means of making modifications needed for testing with the captured data jobs. (See Huang, par. [0028])
As to claim 22, Ding/Oracle/Pasala/Humelsine/Allocca/Huang renders obvious the system of claim 21 (see rejection of claim 21 above), but Ding does not explicitly disclose wherein the test execution driver is configured to automatically test the software application migrated from the source computing platform by automatically executing a test plan against the migrated application in an application runtime of the plurality of application runtimes of the rehosting platform.
However, in an analogous art, Oracle discloses
the migrated application in an application runtime of the plurality of application runtimes of the rehosting platform (e.g., Oracle, p. 1 Figure 1 and last par: rehosted CICs applications run in Tuxedo contains using services provided by the CICs runtime. Rehosted batch jobs run under the batch runtime).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding, which discloses migrating an application to a new platform by the migrated application running in an application runtime of a plurality of application runtimes in the rehosting platform, as taught by Oracle, as Oracle would provide the advantage of a means of running migrated CICs and batch applications with no change to business logic. (See Oracle, p. 1 par. 1).
Further, in an analogous art, Huang discloses:
wherein the test execution driver is configured to automatically test the software application migrated from the source computing platform by automatically executing a test plan against the migrated application (e.g., Huang, par. [0026]: a replay tool 122 obtains the to-be-played data traffic 112 “(with the modifications that the modification and comparison tool 116 may have made).” It replays this to-be-replayed traffic [test plan] for the target system and thus to run the migrated application. For example, requests are used “(replayed)” as requests to the migrated application 108; par. [0001]: the present invention relates to a tool for testing migrated systems).
It would have been obvious to one of ordinary skill in the art at the time the invention was effectively filed to modify Ding, which discloses replaying sequences of captured jobs to test a migrated application in a runtime of a plurality on a rehosting platform, by executing a test plan against the migrated application, as taught by Huang, as Huang would provide the advantage of a means of performing off-line testing of the rehosted platform (see Huang, par. [0015]) and a means of testing with captured data jobs modified as desired. (See Huang, par. [0028])
As to claim 23, Ding/Oracle/Pasala/Humelsine/Allocca/Huang renders obvious the system of claim 22 (see rejection of claim 22 above), Ding further discloses
wherein the test execution driver operates responsive to the migration and testing of the software application when migrated from the source computing platform to the target computing platform, to provide an indication of migration success of the application when migrated from the source computing platform to the target computing platform (e.g., Ding, p. 2 left col. par. 3: we treat production and migrated system as black boxes and use identical workloads to exercise them during the testing phase. The response from the migrated application is compared to the production application’s response, and if they are identical, the migrated application is assumed to be working correctly; p. 5 left col. Sec. 2.3, analysis engine compares and analyzes responses to determine to help engineers determine if the migration is successful).
As to claim 27, it is a method claim whose limitations are substantially the same as claim 21. Accordingly, it is rejected for substantially the same reasons.
As to claim 28, it is a method claim whose limitations are substantially the same as claim 22. Accordingly, it is rejected for substantially the same reasons.
As to claim 29, it is a method claim whose limitations are substantially the same as claim 23. Accordingly, it is rejected for substantially the same reasons.
As to claim 33, it is a method claim whose limitations are substantially the same as claim 21. Accordingly, it is rejected for substantially the same reasons.
As to claim 34, it is a method claim whose limitations are substantially the same as claim 22. Accordingly, it is rejected for substantially the same reasons.
As to claim 35, it is a method claim whose limitations are substantially the same as claim 23. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
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, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
Prosecution Insights