Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-8 are presented for examination.
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: a scenario generation portion configured to …, a pact generation portion configured to … , a program generation portion configured to …, in claim 1, the scenario generation portion is configured to … in Claim 2 and 3, the test support apparatus is configured to … in Claim 5, a correspondence information management portion configured to … in Claim 6 and 7 .
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 3 and 5 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 phrase "an occurrence event that has a possibility of occurring in conjunction with the state transition" renders the claim indefinite. The term "has a possibility" is relative and lacks any objective standard (e.g., probability level), leaving unclear what events are encompassed. For examination purposes, the claim is interpreted as best understood based on the specification (e.g., "possibility" as any potential event per [0043]).
Claim 5 recites the limitation "the test result" in “wherein the test support apparatus is configured to conduct the test by executing the program, and present, based on the test result”. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1 and 8 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation “generate, based on state transition information indicating a state transition that occurs in each of the plurality of individual services and correspondence information indicating a correspondence relationship between a state transition in each of the plurality of individual services and a trigger event that triggers a state transition of another of the individual services caused by the state transition, a test scenario indicating a target transition pattern that is a pattern of state transition of a target service that is any of the individual services, and a coupling destination transition pattern of state transition of a coupling destination service that is one of the individual services different from the target service that occur in conjunction with the target transition pattern”, “generate, based on the test scenario, a stateful pact that is a pact describing a response of the coupling destination service that takes into account the coupling destination transition pattern” and “generate, based on the test scenario and the stateful pact, a pact test program that is a program for conducting the test” as drafted, is a process that, under its broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. The claims recites the following additional elements “a test support apparatus,” “a scenario generation portion,” “a pact generation portion,” and “a program generation portion,” which are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus fail to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are generic computer components and instructions used as the tools to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims cannot provide an inventive concept. Thus, the claims are not patent eligible.
Claim 2 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation “generate, based on the state transition information of the target service, a test scenario indicating the target transition pattern, and add, based on the state transition information of the coupling destination service and the correspondence information, the coupling destination transition pattern to the test scenario” as drafted, is a process that, under its broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. The claims recites the following additional elements “a scenario generation portion,” which are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus fail to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are generic computer components and instructions used as the tools to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims cannot provide an inventive concept. Thus, the claims are not patent eligible.
Claim 3 further define the “correspondence information” as part of the “generate” function set forth in the claims from which they depend, thus, are also considered to recite a mental process that can be reasonably carried out through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper.
Claim 4 further define the “occurrence event” as part of the “generate” function set forth in the claims from which they depend, thus, are also considered to recite a mental process that can be reasonably carried out through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper.
Claim 5 recites the following additional elements “test support apparatus,” “conduct the test by executing the program,” and “present, based on the test result, a measure regarding modification of a program for providing the target service.” The additional elements “test support apparatus,” “conduct the test by executing the program,” are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). The additional element ““present, based on the test result, a measure regarding modification of a program for providing the target service” does nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, to perform a task. See MPEP 2106.05(g). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus fail to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element “test support apparatus,” “conduct the test by executing the program,” are generic computer components and instructions used as the tools to perform the abstract idea. See MPEP 2106.05(f). As to the additional element “present, based on the test result, a measure regarding modification of a program for providing the target service,” the courts have identified gathering data and displaying the output of the abstract idea is well-understood, routine, conventional activity. See MPEP 2106.05(d). Accordingly, the additional elements recited in the claims cannot provide an inventive concept. Thus, the claims are not patent eligible.
Claim 6 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitation “generate at least part of the correspondence information by analyzing a source file of a program for providing the target service” as drafted, is a process that, under its broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. The claims recites the following additional elements “a correspondence information management portion,” which are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus fail to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are generic computer components and instructions used as the tools to perform the abstract idea. See MPEP 2106.05(f). Accordingly, the additional elements recited in the claims cannot provide an inventive concept. Thus, the claims are not patent eligible.
Claim 7 recites the following additional elements “a correspondence information management portion,” “a correspondence information management portion configured to display a screen for inputting the correspondence information,” and “receive the correspondence information via the screen.” The additional elements “a correspondence information management portion,” “a correspondence information management portion configured to display a screen for inputting the correspondence information,” are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea. See MPEP 2106.05(f). The additional element “receive the correspondence information via the screen” does nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, to perform a task. See MPEP 2106.05(g). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus fail to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element “a correspondence information management portion,” “a correspondence information management portion configured to display a screen for inputting the correspondence information,” are generic computer components and instructions used as the tools to perform the abstract idea. See MPEP 2106.05(f). As to the additional element “receive the correspondence information via the screen,” the courts have identified gathering data and displaying the output of the abstract idea is well-understood, routine, conventional activity. See MPEP 2106.05(d). Accordingly, the additional elements recited in the claims cannot provide an inventive concept. Thus, the claims are not patent eligible
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.
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-5 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu (US 11755461 B2) in view of Rajagopalan (US 10169220 B2).
Regarding Claim 1, Liu (US 11755461 B2) teaches
A test support apparatus for supporting a test regarding maintenance of data integrity in a predetermined service composed of a plurality of individual services, the test support apparatus comprising: (Col. 1, lines 20-35, MSA brings some advantages, such as easy deployment, automatic scaling, service resilience, and so on. But it also brings some challenges. For example, in a traditional software development process, such as one involving a monolithic architecture, integration testing is an important phase to ensure software quality. But, in MSA, integration testing has some problems, including being slow, easy to break, hard to fix, and so on; Col. 5, lines 14-47, The consumer service does at least two things: it defines the contract 350 and uploads the contract 350 to a central server. FIG. 4 is an example environment in which the steps described herein may be implemented. A contract server 402 manages contracts established between a consumer service and a provider service. A docker 404 is a container in which steps and tools implemented and used on the provider side are placed. A provider service 408 communicates with a database 410 and a message queue 412 to allow for the verification of the message in the docker 404 using the provider-side steps described herein. JMeter 406 may include a docker file, such as the file depicted in FIG. 11 , which is invokable by the CI/CD pipeline to perform the message verification. In example embodiments, the verification is triggered when a change is identified in the provider source repository.) Examiner Comments: Liu's integration testing in MSA ensures contract (data integrity) between consumer/provider services (individual services) using tools like Pact in a testing apparatus.
a pact generation portion configured to generate, based on the test scenario, a stateful pact that is a pact describing a response of the coupling destination service that takes into account the coupling destination transition pattern; (Col. 5, lines 53-64, contracts pertaining to asynchronous messages may have one or more preconditions. In the product update example, when a product is created, updated, or deleted, the provider service will generate and transmit a message that describes this change. The receiver side will receive this message and propagate the related change to the front-end side. So, in this scenario, the contract between backend and frontend includes the following: when a product is created, then generate a product creation message. In this contract, “create product” is a precondition of the “product creation message.”; Col. 7, lines 25-29, Sixth, the message may be verified based on the message contract. For example, a third-party tool or framework can do this check. For example, Pact may be used. As described above, a match rules section may be used to define the message such that it is compatible with such a third-party tool, allowing the third-party tool to be called directly to perform the verification.”) Examiner Comments: Liu's contracts include preconditions (stateful aspects) for messages (responses) between services, generated based on scenarios like product changes.
a program generation portion configured to generate, based on the test scenario and the stateful pact, a pact test program that is a program for conducting the test. (Col. 2, lines 38-52, a method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.) Examiner Comments: Liu generates verification programs (e.g., UT programs, docker files) using contracts (pacts) and scenarios (preconditions, message flows) for testing in CI/CD.
Liu did not specifically teach
a scenario generation portion configured to generate, based on state transition information indicating a state transition that occurs in each of the plurality of individual services and correspondence information indicating a correspondence relationship between a state transition in each of the plurality of individual services and a trigger event that triggers a state transition of another of the individual services caused by the state transition, a test scenario indicating a target transition pattern that is a pattern of state transition of a target service that is any of the individual services, and a coupling destination transition pattern of state transition of a coupling destination service that is one of the individual services different from the target service that occur in conjunction with the target transition pattern;
However, Rajagopalan (US 10169220 B2) teaches
a scenario generation portion configured to generate, based on state transition information indicating a state transition that occurs in each of the plurality of individual services and correspondence information indicating a correspondence relationship between a state transition in each of the plurality of individual services and a trigger event that triggers a state transition of another of the individual services caused by the state transition (Col 8, Lines 24-46, Resiliency testing component 104 can include user interface crawling component 202 that can automatically traverse a state transition graph of a user interface of a microservices-based application. Resiliency testing component 104 can also include state transition graph annotation component 204 that can automatically annotate edges of the state transition graph with API call subgraphs of an API call graph, where the API call subgraphs represent APIs invoked based on user interface events associated with the edges. Resiliency testing component 104 can also include prioritization component 206 that can analyze an annotated state transition graph and generate a prioritized list of API call subgraphs for resiliency testing that has reduced redundant resiliency testing) Examiner Comments: This teaches state transition information (state transition graph of UI invoking microservices). This teaches correspondence information (annotations linking UI events/triggers to API subgraphs between services).
a test scenario indicating a target transition pattern that is a pattern of state transition of a target service that is any of the individual services, and a coupling destination transition pattern of state transition of a coupling destination service that is one of the individual services different from the target service that occur in conjunction with the target transition pattern; (Col. 8, lines 24-46, Resiliency testing component 104 can also include test execution component 208 that can automatically test the API call subgraphs for resiliency according to the prioritized order in the list, such that a highest prioritized portion of the API call subgraphs are tested in a limited available time prior to deployment in a live environment for employment of the microservices-based application by end users and the remaining portion of the API call subgraphs are tested after deployment, according to an algorithm that reduces redundant resiliency testing) Examiner Comments: This teaches generating test scenarios (failure scenarios from API subgraphs) indicating target transition patterns (parent API patterns) and coupling patterns (dependent API transitions in subgraph).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu’s teaching into Rajagopalan’s in order to enhance scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems, because both address testing in microservice architectures (Liu for contracts, Rajagopalan for resiliency), and integrating Rajagopalan’s state transition graphs would enhance Liu's scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems (Rajagopalan, Col. 5, lines 25-67: motivation for efficient resiliency in volatile microservices).
Regarding Claim 2, Liu and Rajagopalan teach
The test support apparatus according to claim 1.
Liu teaches wherein the scenario generation portion is configured to generate, based on the state transition information of the target service, a test scenario indicating the target transition pattern, and add, based on the state transition information of the coupling destination service and the correspondence information, the coupling destination transition pattern to the test scenario. (Col. 6, lines 33-38, FIG. 7 is a flow chart depicting a source repository pipeline in which the disclosed solution is incorporated, in accordance with some example embodiments. An actor submits changed code. Once a change is submitted, it will trigger a CI/CD pipeline that will do compile, test, package, and deploy tasks. A CDC contract is placed into a consumer repository and uploaded to a central server in the CI/CD pipeline. To verify an asynchronous message efficiently, the disclosed solution also involves performing one or more steps on the provider side. First, basic master data is prepared in a test tenant template. For example, a cloud ERP system may have two categories data. One is master data; another is for transaction data. Based on business domain logic, when a user does some transactions, such as, for example, creating a Sales Order, some predefined master data like product, customer, tax code, and so on, may be needed. That means that, in order to test a Sales Order related feature, many basic master data items may need to be prepared or created, which can be a time-consuming task.; Col. 7, lines 53-63, FIG. 13 is a flow diagram depicting the message verification process. The JMeter requests a creation of a test message queue. The test message queue is then created. The JMeter performs an action that causes a message to be generated (e.g., by calling an API at the provider service). The provider service generates a message and places it into the test message queue. The message is retrieved from the test message queue by the JMeter. The message is then verified by the JMeter (e.g., by using a third-party tool, such as Pact).) Examiner Comments: Liu generates consumer-side scenarios (target patterns) first in pipelines, then verifies with provider-side additions (coupling patterns).
Rajagopalan teaches wherein the scenario generation portion is configured to generate, based on the state transition information of the target service, a test scenario indicating the target transition pattern, and add, based on the state transition information of the coupling destination service and the correspondence information, the coupling destination transition pattern to the test scenario. (Col. 18, lines 18-44, Test execution component 208 can perform resiliency testing on an API call subgraph by injecting fake failures in the communication between a parent API calling a dependent API. In a non-limiting example, for a timeout pattern test and/or a bounded retry pattern test, test execution component 208 can inject a fake transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can return an error code to a parent API indicating a transient failure such as an error code indicating a service overload, delay the parent API call indicating transient network congestion, terminate the Transmission Control Protocol (TCP) connection of the parent API calls for a defined period to indicate transient network connectivity issues, simulate an inability to connect to a remote microservice, simulate prolonged execution time due to temporary network delays, or any other suitable transient failure. In another non-limiting example, for a circuit breaker pattern test and/or a bulkhead pattern test, test execution component 208 can inject a fake non-transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can simulate a non-transient failure between a parent API and a dependent API, such as a connection failures due to network partition, a microservice crash, error codes to indicate internal execution error in the dependent microservice, or any other suitable non-transient failure.; Col. 19, lines 34- Col. 20, line 5, Test execution component 208 can employ a systematic resilience testing process that reduces redundant resiliency testing when testing an API call subgraph. The systematic resilience testing process can comprise a depth first traversal pattern of the API call subgraph, where during the depth first traversal pattern at a stop at a parent API, the following are performed:
Perform a bounded retry pattern test on the parent API for a call to the current dependent API of the parent API in the depth first traversal pattern, record the results of the bounded retry pattern test on the parent API for a call to the current dependent API, and if the bounded retry pattern test was passed, mark the parent API as bounded retry pattern tested for the current dependent API to which the bounded retry pattern test was performed; and * If the parent API have been marked as tested for bounded retry pattern for the current dependent API of the parent API in the depth first traversal pattern, perform a circuit breaker pattern test on the parent API for the call to the current dependent API of the parent API, record the results of the circuit breaker pattern test on the parent API for a call to the current dependent API, and if the circuit breaker pattern test was passed, mark the parent API as circuit breaker pattern tested for the current dependent API to which the circuit breaker pattern test was performed.
If the parent API has multiple dependent APIs, the calls to all of the direct and indirect dependent APIs of the parent API have been marked as tested for bounded retry pattern and circuit breaker retry pattern (which can be determined by the boundary pattern tested marking and the circuit breaker pattern tested marking in (1)), and the parent API is not marked as bulkhead pattern tested, perform a bulkhead pattern test on the parent API, record the results of the bulkhead pattern test on the parent API, and mark the parent API as bulkhead pattern tested.) Examiner Comments: Rajagopalan generates base graphs (target patterns) from UI states, then annotates with subgraphs (adds coupling patterns) based on logs and correspondences.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu’s teaching into Rajagopalan’s in order to enhance scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems, because both address testing in microservice architectures (Liu for contracts, Rajagopalan for resiliency), and integrating Rajagopalan’s state transition graphs would enhance Liu's scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems (Rajagopalan, Col. 5, lines 25-67: motivation for efficient resiliency in volatile microservices).
Regarding Claim 3, Liu and Rajagopalan teach
The test support apparatus according to claim 1.
Liu did not specifically teach wherein the correspondence information further indicates a correspondence relat ionship between the state transition and an occurrence event that has a possibility of occurring in conjunction with the state transition, and the scenario generation portion is configured to newly generate, as the test scenario, an expanded test scenario in which the target transition pattern in a situation, where the occurrence event occurs, is added to the test scenario.
However, Rajagopalan teaches wherein the correspondence information further indicates a correspondence relationship between the state transition and an occurrence event that has a possibility of occurring in conjunction with the state transition, and (Col. 18, lines 18-44, Test execution component 208 can perform resiliency testing on an API call subgraph by injecting fake failures in the communication between a parent API calling a dependent API. In a non-limiting example, for a timeout pattern test and/or a bounded retry pattern test, test execution component 208 can inject a fake transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can return an error code to a parent API indicating a transient failure such as an error code indicating a service overload, delay the parent API call indicating transient network congestion, terminate the Transmission Control Protocol (TCP) connection of the parent API calls for a defined period to indicate transient network connectivity issues, simulate an inability to connect to a remote microservice, simulate prolonged execution time due to temporary network delays, or any other suitable transient failure. In another non-limiting example, for a circuit breaker pattern test and/or a bulkhead pattern test, test execution component 208 can inject a fake non-transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can simulate a non-transient failure between a parent API and a dependent API, such as a connection failures due to network partition, a microservice crash, error codes to indicate internal execution error in the dependent microservice, or any other suitable non-transient failure.; Col. 19, lines 34- Col. 20, line 5, Test execution component 208 can employ a systematic resilience testing process that reduces redundant resiliency testing when testing an API call subgraph. The systematic resilience testing process can comprise a depth first traversal pattern of the API call subgraph, where during the depth first traversal pattern at a stop at a parent API, the following are performed:
Perform a bounded retry pattern test on the parent API for a call to the current dependent API of the parent API in the depth first traversal pattern, record the results of the bounded retry pattern test on the parent API for a call to the current dependent API, and if the bounded retry pattern test was passed, mark the parent API as bounded retry pattern tested for the current dependent API to which the bounded retry pattern test was performed; and * If the parent API have been marked as tested for bounded retry pattern for the current dependent API of the parent API in the depth first traversal pattern, perform a circuit breaker pattern test on the parent API for the call to the current dependent API of the parent API, record the results of the circuit breaker pattern test on the parent API for a call to the current dependent API, and if the circuit breaker pattern test was passed, mark the parent API as circuit breaker pattern tested for the current dependent API to which the circuit breaker pattern test was performed.
If the parent API has multiple dependent APIs, the calls to all of the direct and indirect dependent APIs of the parent API have been marked as tested for bounded retry pattern and circuit breaker retry pattern (which can be determined by the boundary pattern tested marking and the circuit breaker pattern tested marking in (1)), and the parent API is not marked as bulkhead pattern tested, perform a bulkhead pattern test on the parent API, record the results of the bulkhead pattern test on the parent API, and mark the parent API as bulkhead pattern tested.) Examiner Comments: Rajagopalan's annotations include failure impacts (occurrence events like transients) corresponding to transitions.
the scenario generation portion is configured to newly generate, as the test scenario, an expanded test scenario in which the target transition pattern in a situation, where the occurrence event occurs, is added to the test scenario. (Col. 13, lines 40-55, (Col. 18, lines 18-44, Test execution component 208 can perform resiliency testing on an API call subgraph by injecting fake failures in the communication between a parent API calling a dependent API. In a non-limiting example, for a timeout pattern test and/or a bounded retry pattern test, test execution component 208 can inject a fake transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can return an error code to a parent API indicating a transient failure such as an error code indicating a service overload, delay the parent API call indicating transient network congestion, terminate the Transmission Control Protocol (TCP) connection of the parent API calls for a defined period to indicate transient network connectivity issues, simulate an inability to connect to a remote microservice, simulate prolonged execution time due to temporary network delays, or any other suitable transient failure. In another non-limiting example, for a circuit breaker pattern test and/or a bulkhead pattern test, test execution component 208 can inject a fake non-transient failure scenario in the communication between a parent API calling a dependent API. For example, test execution component 208 can simulate a non-transient failure between a parent API and a dependent API, such as a connection failures due to network partition, a microservice crash, error codes to indicate internal execution error in the dependent microservice, or any other suitable non-transient failure.; Col. 19, lines 34- Col. 20, line 5, Test execution component 208 can employ a systematic resilience testing process that reduces redundant resiliency testing when testing an API call subgraph. The systematic resilience testing process can comprise a depth first traversal pattern of the API call subgraph, where during the depth first traversal pattern at a stop at a parent API, the following are performed:
Perform a bounded retry pattern test on the parent API for a call to the current dependent API of the parent API in the depth first traversal pattern, record the results of the bounded retry pattern test on the parent API for a call to the current dependent API, and if the bounded retry pattern test was passed, mark the parent API as bounded retry pattern tested for the current dependent API to which the bounded retry pattern test was performed; and * If the parent API have been marked as tested for bounded retry pattern for the current dependent API of the parent API in the depth first traversal pattern, perform a circuit breaker pattern test on the parent API for the call to the current dependent API of the parent API, record the results of the circuit breaker pattern test on the parent API for a call to the current dependent API, and if the circuit breaker pattern test was passed, mark the parent API as circuit breaker pattern tested for the current dependent API to which the circuit breaker pattern test was performed.
If the parent API has multiple dependent APIs, the calls to all of the direct and indirect dependent APIs of the parent API have been marked as tested for bounded retry pattern and circuit breaker retry pattern (which can be determined by the boundary pattern tested marking and the circuit breaker pattern tested marking in (1)), and the parent API is not marked as bulkhead pattern tested, perform a bulkhead pattern test on the parent API, record the results of the bulkhead pattern test on the parent API, and mark the parent API as bulkhead pattern tested.) Examiner Comments: Rajagopalan generates expanded failure scenarios (with events like failures) added to subgraphs.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu’s teaching into Rajagopalan’s in order to enhance scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems, because both address testing in microservice architectures (Liu for contracts, Rajagopalan for resiliency), and integrating Rajagopalan’s state transition graphs would enhance Liu's scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems (Rajagopalan, Col. 5, lines 25-67: motivation for efficient resiliency in volatile microservices).
Regarding Claim 4, Liu and Rajagopalan teach
The test support apparatus according to claim 3.
Liu did not specifically teach
wherein the occurrence event is an abnormal event.
However, Rajagopalan teaches
wherein the occurrence event is an abnormal event. (Col. 18, lines 18-45, Test execution component 208 can inject a fake transient failure scenario; Col 4, lines 25-44, one or more embodiments described herein can implement resiliency testing protocols that can emulate different types of application-level failures by intercepting and manipulating network messages/interactions between communicating microservices) Examiner Comments: Rajagopalan's failure emulation directly corresponds to abnormal events in expanded scenarios.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu’s teaching into Rajagopalan’s in order to enhance scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems, because both address testing in microservice architectures (Liu for contracts, Rajagopalan for resiliency), and integrating Rajagopalan’s state transition graphs would enhance Liu's scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems (Rajagopalan, Col. 5, lines 25-67: motivation for efficient resiliency in volatile microservices).
Regarding Claim 5, Liu and Rajagopalan teach
The test support apparatus according to claim 1.
Liu teaches wherein the test support apparatus is configured to conduct the test by executing the program, (Col. 7, lines 35-43, FIG. 10 is a flowchart depicting verification of a message. The JMeter requests the message content from the message queue. The JMeter generates a unit testing (UT) program to test the message content. The JMeter calls the UT program, which in turn calls a third-party tool, such as Pact, to verify the message. The result of the verification is returned to the JMeter.) Examiner Comments: Liu executes verification programs (e.g., Pact calls in CI/CD) to conduct tests.
Liu did not specifically teach, based on the test result, a measure regarding modification of a program for providing the target service.
However, Rajagopalan teaches
based on the test result, a measure regarding modification of a program for providing the target service. (Claim 7, wherein the test execution component transmits a recommendation to at least one recipient entity indicating whether to deploy the microservices-based application in a live environment, and wherein the recommendation is determined based on an analysis of results of the resiliency testing) Examiner Comments: Rajagopalan’s post-test recommendations provide actionable modifications for Liu's detected breaks.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu’s teaching into Rajagopalan’s in order to enhance scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems, because both address testing in microservice architectures (Liu for contracts, Rajagopalan for resiliency), and integrating Rajagopalan’s state transition graphs would enhance Liu's scenario generation by providing structured correspondence for handling state-dependent interactions, improving data integrity verification in asynchronous systems (Rajagopalan, Col. 5, lines 25-67: motivation for efficient resiliency in volatile microservices).
Regarding Claim 8, is a method claim corresponding to the apparatus claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Claim 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu (US 11755461 B2) in view of Rajagopalan (US 10169220 B2) further in view of Silva (US 20220091829 A1).
Regarding Claim 6, Liu and Rajagopalan teach
The test support apparatus according to claim 1.
Liu and Rajagopalan did not specifically teach
further comprising a correspondence information management portion configured to generate at least part of the correspondence information by analyzing a source file of a program for providing the target service.
However, Silva (US 20220091829 A1) teaches
further comprising a correspondence information management portion configured to generate at least part of the correspondence information by analyzing a source file of a program for providing the target service. (Para 0025, Aspects of the present disclosure are directed toward techniques for automatically shrinking and decomposing an image including an application to be migrated to reduce operational costs for the application to be migrated in a target cloud platform. Aspects of the present disclosure realize numerous features such as, but not limited to (i) post-deployment on-the-fly application decomposition based on workload execution tracing and/or source code analysis; (ii) generation of a cost-aware code dependency graph based on the execution tracing and/or source code analysis, customizable objective functions, and/or collected performance metrics; (iii) removal (e.g., pruning) of unused nodes in the cost-aware code dependency graph; (iv) replacement of source code corresponding to high-cost subgraphs in the cost-aware code dependency graph with a generated microservice, where the generated microservice can be implemented by a different virtual machine of the target cloud platform than the application to be migrated; and/or (v) use of a generated microservice for other subgraphs in the cost-aware code dependency graph) Examiner Comments: Silva's source code analysis generates dependency graphs (correspondence info) for migration, analyzing program files.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu and Rajagopalan’s teaching into Silva’s in order to automate correspondence discovery from code, reducing manual effort in testing setups by enabling automatically modifying the application to realize improved performance of the application on the target cloud infrastructure by removing source code corresponding to unused nodes and replacing identified source code of high-cost subgraphs with calls to a generated microservice (Silva [Summary]).
Claim 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu (US 11755461 B2) in view of Rajagopalan (US 10169220 B2) further in view of Iborra (US 20090125546 A1).
Regarding Claim 7, Liu and Rajagopalan teach
The test support apparatus according to claim 1.
Liu and Rajagopalan did not specifically teach
further comprising a correspondence information management portion configured to display a screen for inputting the correspondence information and receive the correspondence information via the screen.
However, Iborra (US 20090125546 A1) teaches further comprising a correspondence information management portion configured to display a screen for inputting the correspondence information and receive the correspondence information via the screen. (Claim 42, wherein said computer-readable instructions, when executed by a computer, control said computer to display tools which allow a designer of said target program to enter user input data which defines valuation data structures such that each variable attribute can include a list of valuation data structures that define how the variable attribute's value, and therefore the object's state, is changed by means of the different events.) Examiner Comments: Iborra's dialogs facilitate manual entry of transition info, complementing automated aspects for user-defined refinements.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Liu and Rajagopalan’s teaching into Iborra’s in order to provide intuitive input for complex correspondences, enhancing usability providing predetermined properties, which aid a designer of a target computer program to guide the designer in entering user input data, and the primitives of the conceptual model are automatically converted into data structures in a form of formal language statements organized by a formal language grammar with rules of syntax and semantics (Iborra [Summary]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191