DETAILED ACTION
Claims 1-20 rejected under non-statutory double patenting.
Claims 1, 2, and 5-20 rejected under 35 USC § 101.
Claims 1-20 rejected under 35 USC § 103.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,086,618 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claim language corresponds as follows:
Claims 1, 12, and 17
Claim 1 is the representative operational mapping. Claims 12 and 17 recite the same service execution, request, rule selection, response, and return sequence in system and medium form.
Present Application
‘618 Patent
A computer-implemented method, comprising: executing, by a virtual service proxy engine executed via a first computing system, a virtual service that corresponds with a service executed by a second computing system;
Claim 1: A computer-implemented method, comprising: maintaining, by a virtual service proxy engine executed by one or more processors, a plurality of virtual service rules that correspond to a virtual service executed by the virtual service proxy engine, wherein:
receiving, by the virtual service proxy engine, and from a client application configured
to use a particular identifier, a service request indicating the particular identifier and at least
one input parameter;
Claim 1: receiving, by the virtual service proxy engine, a service request from a client application configured to use a team identifier, of a particular team, that comprises a particular port number of a particular port exposed by the virtual service proxy engine, wherein the service request indicates: the team identifier, and at least one input parameter associated with the virtual service;
identifying, by the virtual service proxy engine, a particular virtual service rule, of a plurality of virtual service rules for the virtual service, that corresponds with the particular identifier and the at least one input parameter;
Claim 1: identifying, by the virtual service proxy engine, a virtual service rule, of the plurality of virtual service rules, that is associated with: the team identifier, and match criteria that corresponds with the at least one input parameter;
determining, by the virtual service proxy engine, and based on the particular virtual service rule, a response corresponding to the at least one input parameter; and
Claim 1: determining, by the virtual service proxy engine, a team response indicated by the virtual service rule; generating, by the virtual service proxy engine, a service response based on the team response; and
sending, by the virtual service proxy engine, the response to the client application in response to the service request.
Claim 1: sending, by the virtual service proxy engine, the service response to the client application in response to the service request.
Claim 2
Present Application
‘618 Patent
The computer-implemented method of claim 1, further comprising: identifying, by the virtual service proxy engine, a particular set of rules that corresponds to the team identifier; and identifying, by the virtual service proxy engine, the virtual service rule from among the particular set of rules based on a determination that the at least one input parameter corresponds with the match criteria of the virtual service rule.
Claim 1: receiving, by the virtual service proxy engine, a service request from a client application configured to use a team identifier, of a particular team, that comprises a particular port number of a particular port exposed by the virtual service proxy engine, wherein the service request indicates: the team identifier, and at least one input parameter associated with the virtual service;
Claim 3
Present Application
‘618 Patent
The computer-implemented method of claim 1, wherein: the virtual service proxy engine is associated with a test environment,
Claim 1: A computer-implemented method, comprising: maintaining, by a virtual service proxy engine executed by one or more processors, a plurality of virtual service rules that correspond to a virtual service executed by the virtual service proxy engine, wherein:
the virtual service proxy engine is configured, at a first time when the test environment is active, to identify the particular virtual service rule, determine the response based on the particular virtual service rule, and send the response to the client application, and
Claim 1: identifying, by the virtual service proxy engine, a virtual service rule, of the plurality of virtual service rules, that is associated with: the team identifier, and match criteria that corresponds with the at least one input parameter; determining, by the virtual service proxy engine, a team response indicated by the virtual service rule; generating, by the virtual service proxy engine, a service response based on the team response; and sending, by the virtual service proxy engine, the service response to the client application in response to the service request.
the virtual service proxy engine is configured, at a second time when the test environment is inactive, to serve as a pass-through and to forward the service request to the service executed by the second computing system instead of identifying the particular virtual service rule, determining the response based on the particular virtual service rule, and sending the response to the client application
Claim 7: determining, by the virtual service proxy engine, that the at least one second input parameter is not associated with any virtual service rules associated with the team identifier; forwarding, by the virtual service proxy engine, the second service request to a real service that corresponds with the virtual service;
Claim 4
Present Application
‘618 Patent
The computer-implemented method of claim 1, further comprising: receiving, by the virtual service proxy engine, and from the client application, a second service request that indicates the particular identifier and at least one second input parameter;
Claim 7: receiving, by the virtual service proxy engine, a second service request from the client application, wherein the second service request indicates the team identifier and at least one second input parameter;
determining, by the virtual service proxy engine, that the at least one second input
parameter does not satisfy match criteria of any virtual service rule, of the plurality of virtual
service rules, that is associated with the particular identifier; and
Claim 7: determining, by the virtual service proxy engine, that the at least one second input parameter is not associated with any virtual service rules associated with the team identifier;
forwarding, by the virtual service proxy engine, and based on determining that the at least one second input parameter does not satisfy the match criteria of any virtual service rule that is associated with the particular identifier, the second service request to the service executed by the second computing system.
Claim 7: determining, by the virtual service proxy engine, that the at least one second input parameter is not associated with any virtual service rules associated with the team identifier; forwarding, by the virtual service proxy engine, the second service request to a real service that corresponds with the virtual service; and forwarding, by the virtual service proxy engine, and to the client application, a response from the real service to the second service request.
Claim 5
Present Application
‘618 Patent
The computer-implemented method of claim 1, wherein the service request is a
Hypertext Transfer Protocol (HTTP) request or a Simple Object Access Protocol (SOAP) message.
Claim 9: wherein the service request is at least one of a Representational State Transfer (REST) request, a Hypertext Transfer Protocol (HTTP) request, or a Simple Object Access Protocol (SOAP) message sent by the client application to the virtual service proxy engine via a network.
Claims 6, 13, and 18
Claim 6 is the representative operational mapping. Claims 13 and 18 recite the same service execution, request, rule selection, response, and return sequence in system and medium form.
Present Application
‘618 Patent
identifying, by the virtual service proxy engine, a set of virtual service rules that
corresponds to the particular identifier indicated by the service request, wherein different virtual service rules, within the set of virtual service rules, are respectively associated with different match criteria; and
Claim 2: identifying, by the virtual service proxy engine, a particular set of rules that corresponds to the team identifier
identifying, by the virtual service proxy engine, the particular virtual service rule from among the set of virtual service rules by determining that match criteria of the particular virtual service rule is satisfied by the at least one input parameter indicated by the service request.
Claim 2: identifying, by the virtual service proxy engine, the virtual service rule from among the particular set of rules based on a determination that the at least one input parameter corresponds with the match criteria of the virtual service rule.
Claims 7, 14, and 19
Claim 7 is the representative operational mapping. Claims 14 and 19 recite the same service execution, request, rule selection, response, and return sequence in system and medium form.
Present Application
‘618 Patent
the at least one input parameter indicated by the service request comprises multiple
input parameters
Claim 1: receiving, by the virtual service proxy engine, a service request from a client application configured to use a team identifier, of a particular team, that comprises a particular port number of a particular port exposed by the virtual service proxy engine, wherein the service request indicates: the team identifier, and at least one input parameter associated with the virtual service;
the set of virtual service rules is associated with a priority order
Claim 3: the particular set of rules is associated with a priority order
identifying the particular virtual service rule further comprises: identifying multiple virtual service rules, in the set of virtual service rules, that have distinct match criteria satisfied by at least one of the multiple input parameters indicated by the service request; and
Claim 3: identifying the virtual service rule comprises identifying, based on the priority order, a highest-priority virtual service rule in the particular set of rules that corresponds with the at least one input parameter.
identifying the particular virtual service rule as a highest-priority virtual service
rule, of the multiple virtual service rules, based on the priority order.
Claim 3: identifying the virtual service rule comprises identifying, based on the priority order, a highest-priority virtual service rule in the particular set of rules that corresponds with the at least one input parameter.
Claim 8
Present Application
‘618 Patent
receiving, by the virtual service proxy engine, and via a user interface, user input corresponding with the particular identifier; and
Claim 6: receiving, by the virtual service proxy engine, and via a virtual service manager, user input associated with the virtual service rule;
adjusting, by the virtual service proxy engine, at least one virtual service rule, of the plurality of virtual service rules, that corresponds with the particular identifier based on the user input.
Claim 6: adjusting, by the virtual service proxy engine, and one or more of the match criteria or the team response associated with the virtual service rule based on the user input.
Claim 1: identifying, by the virtual service proxy engine, a virtual service rule, of the plurality of virtual service rules, that is associated with: the team identifier, and match criteria that corresponds with the at least one input parameter;
Claim 9
Present Application
‘618 Patent
wherein the service request indicates
the particular identifier via at least one of:
a header value associated with the service request, a body of the service request, a uniform resource locator (URL) path used by the client application to submit the service request to the virtual service proxy engine, or a port used by the client application to submit the service request to the virtual service proxy engine
Claim 8: wherein the virtual service proxy engine receives the service request via the particular port that corresponds to the particular port number.
Claim 1: receiving, by the virtual service proxy engine, a service request from a client application configured to use a team identifier, of a particular team, that comprises a particular port number of a particular port exposed by the virtual service proxy engine, wherein the service request indicates: the team identifier, and at least one input parameter associated with the virtual service;
Claims 10 and 15
Claim 10 is the representative operational mapping. Claim 15 recites the same service execution, request, rule selection, response, and return sequence in system form.
Present Application
‘618 Patent
different sets of virtual service rules, within the plurality of virtual service rules,
respectively correspond with different identifiers, and
Claim 1: maintaining, by a virtual service proxy engine executed by one or more processors, a plurality of virtual service rules that correspond to a virtual service executed by the virtual service proxy engine, wherein: different sets of rules, included in the plurality of virtual service rules, respectively correspond with team identifiers of different teams, and the team identifiers of the different teams comprise port numbers of respective different ports exposed by the virtual service proxy engine;
the different sets of virtual service rules comprise: a first virtual service rule associated with the particular identifier and the at least one input parameter, the first virtual service rule defining a first value of the response; and
Claim 1: identifying, by the virtual service proxy engine, a virtual service rule, of the plurality of virtual service rules, that is associated with: the team identifier, and match criteria that corresponds with the at least one input parameter; determining, by the virtual service proxy engine, a team response indicated by the virtual service rule;
a second virtual service rule associated with a second identifier, of the different
identifiers, the second virtual service rule defining a second value of the response.
Claim 5: identifying, by the virtual service proxy engine, a second virtual service rule that is associated with: the second team identifier, and second match criteria that corresponds with the at least one input parameter; determining, by the virtual service proxy engine, a second team response indicated by the second virtual service rule, wherein the second team response is different from the first team response;
Claims 11, 16, and 20
Claim 11 is the representative operational mapping. Claims 16 and 20 recite the same service execution, request, rule selection, response, and return sequence in system and medium forms.
Present Application
‘618 Patent
wherein the different identifiers are respectively associated with at least one of: different client applications, or
different development teams associated with the different client applications.
Claim 1; receiving, by the virtual service proxy engine, a service request from a client application configured to use a team identifier, of a particular team, that comprises a particular port number of a particular port exposed by the virtual service proxy engine, wherein the service request indicates: the team identifier, and at least one input parameter associated with the virtual service;
Claim 5: receiving, by the virtual service proxy engine, a second service request from a second client application configured to use a second team identifier, of a second team, that comprises a second port number of a second port exposed by the virtual service proxy engine, wherein the second service request indicates: the second team identifier, and the at least one input parameter;
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, 2, and 5-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 12, and 17
Step 2A, Prong One. Claims 1, 12, and 17 recite identifying a rule that corresponds with a request’s particular identifier and input parameter, and determining a response based on that rule. These limitations encompass evaluating supplied information against stated conditions and selecting the corresponding answers. For example, a person given a short table of identifiers, input conditions, and corresponding answers can identify the row matching a supplied identifier and input and determine the answer specified by that row. The claims impose no minimum volume, complexity, or timing that prevents this evaluation from practically being performed mentally or with pen and paper. These evaluation and selection limitations therefore recite a mental process under MPEP § 2106.04(a)(2), subsection III. Execution of a service and communication between software components are additional elements, rather than acts attributed to the human mind.
Step 2A, Prong Two. This judicial exception is not integrated into a practical application. Claim 1 additionally recites a virtual service proxy engine executed through a first computing system, execution of a virtual service corresponding to a service on a second computing system, receipt of a request from a client configured with an identifier, and return of the determine response to that client. Claim 12 recites processors and memory storing instructions implementing the corresponding operations, with the real service executed on a separate computing platform. Claim 17 recites a non-transitory computer-readable media storing instructions that cause processors of a first computing system to perform the operations, with the corresponding service executed by a second computing system.
The virtual service is specified through correspondence to another service and the receipt, rule evaluation, and response functions. The identifier configures which information is used in the evaluation; the input supplies the condition to be evaluated; and the returned response communicates the selected answer. The claims do not require a particular implementation that changes how the computer stores information, executes instructions, or communicates data. They also do not require separate configuration for different applications or teams, a transition between simulated and real service processing, or forwarding to the real service when no rule matches. The claimed relationships to a separately executed service identifies the software context for generating the answer, without requiring a particular interaction with that real service.
Considered, together, these limitations implement the information evaluation through software and return its result. They do not recite the components or operations that implement the disclosed avoidance of conflicts between different applications’ or teams’ configurations. The computing component accordingly serve as tools for performing the received evaluation and supplying the answer, rather than implementing a claimed improvement to their operation. MPEP §§ 2106.04(d)(1), 2106.05(a), 2106.05(f), and 2106.05(h).
Step 2B. The claims do not include additional elements sufficient to amount to significantly more than the judicial exception. The memory and stored instructions in claims 12 and 17 perform the function of “Storing and retrieving information in memory,” identified in the computer functions list of MPEP § 2106.05(d), subsection II, item iv, at the general level recited. The processors and software engine are instructed to executed the same evaluation and response procedure; the claims specify no additional processing technique for accomplishing those functions. Such an instruction to implement the exception on a computer does not supply an inventive concept. MPEP § 2106.05(f).
Receipt of the identifier and input obtains the information used in the evaluation, and transmission of he response communicates the answer selected by it. Reconsidered individually and in the ordered combination, the sequence remains receipt of the information, selection of a matching rule, determination of tits answer, and return of that answer through the virtual service. The distributed service context does not change this operation: the separate real service need not participate in the claimed sequence. No additional technical cooperation or processing is required beyond using the computing system to perform the valuation and communicate its results. The combination therefore does not supply significantly more under MPEP §§ 2106.05(f) and 2106.05(g). Claims 1, 12, and 17 are directed to the mental process without significantly more.
Claim 2
Claim 2 further recites configuring the client to send the request to the virtual service proxy engine instead of the real service during testing. This limits the use of the inherited response selection procedure to supplying test responses in place of real service response. The claim does not further specify a testing operation, an assessment of test results, or a mechanism that changes computer operation beyond the inherited request and response procedure. The substitution identifies the use and destination of the generated information, while the manner of generating it remains the recited rule evaluation. Together with the inherited limitations this restriction does not integrate the exception into a practical application or provide significantly more. MPEP §§ 2106.05(f) and 2106.05(h).
Claims 5 and 9
Claim 5 further recites an HTTP request or SOAP message. Claim 9 further recites conveying the identifier through a request header, request body, URL path, or submission port. These limitations specify the protocol or location used to convey the information evaluated by the inherited procedure. They do not specify a changed protocol. Message processing technique, or technical use of the identifier beyond selecting the applicable response rule. To the extent the claimed request is transmitted over a network, that general communication function corresponds to “receiving or transmitting data over a network” in MPEP § 2106.05(d), subsection II, computer functions item I. Receipt of the information remains data collection for the evaluation, and its encoding does not change the role of the information in the ordered combination. Neither claim integrates the exception into a practical application or supplies significantly more. MPEP §§ 2106.05(f), 2106.05(g), and 2106.05(h).
Claims 6, 13, and 18
Claims 6, 13, and 18 further recite identifying the set of rules associated with the particular identifier, with different rules having different match criteria, and identifying the particular rule by determining that its criteria are satisfied by the input parameter. These limitations further specify the mental evaluation: a person can first choose the table with the supplied identifier and then select the row whose condition matches the supplied input. The claims do not require a particular computer data structure or retrieval mechanism beyond organizing and evaluating the stated information. Applying this evaluation within the inherited virtual service does not add a technical operation beyond generating and returning the selected answer. Together with the respective inherited limitations, these steps do not integrate the exception or supply significantly more. MPEP §§ 2106.04(a)(2), subsection III, and 2106.05(f).
Claims 7, 14, and 19
Claims 7, 14, and 19 further recite multiple input parameters, a priority order for the rules, identification of multiple rules whose distinct criteria match at least one input parameter, and selection of a matching rule having the highest priority. A person can evaluate a small number of inputs against different conditions, identify the matching entries, and select the entry with the greatest stated priority. The claims impose no size or timing requirement preventing that evaluation. The priority specifies which answer controls when multiple conditions are met; it does not specify a different computer processing architecture or a technical operation applied after the answer is chosen. With the inherited limitations, the claims remain directed to the mental evaluation implemented through the virtual service without significantly more.
Claim 8
Claim 8 further recites receiving user input through an interface corresponding with the particular identifier and adjusting an associated rule based on that input. The interface collects the user’s change, and the adjustment changes the information used for subsequent evaluations. No particular interface arrangement, update protocol, or mechanism for maintaining consistency between concurrent configuration is required. The rule editing therefore modifies the evaluation criteria while leaving the inherited software implementation at the same level of generality. Considered with claim 1, the additional steps among to using the computer to accept and apply an edit to the rule and do not integrate the exception or supply significantly more. MPEP §§ 2106.05(f) and 2106.05(g).
Claims 10 and 15
Claims 10 and 15 further recite different sets of virtual service rules corresponding to different identifiers, including a first rule associated with the particular identifier and input parameter and defining a first response value, and a second rule associated with a second identifier and defining a second response value. These limitations further specify the mental evaluations of the respective parent claims. A person can maintain two lists of rules labeled with different identifiers, choose the list corresponding to a supplied identifier, compare the input with the rules in that list, and determine the response value specified by the applicable rule. The other list can contain a rule specifying its own response value. Nothing in these limitations requires a quantity or complexity f rules that presents this evaluation from practically being performed mentally or with pen and paper. The additional organization and selection fall within the mental processes grouping. MPEP § 2106.04(a)(2), subsection III.
Using these separate lists as rule sets for the same virtual service organizes the information evaluated by the inherited procedure. The identifiers select the relevant information, and the rules supply the answer; the claims do not require a particular storage or execution mechanism that changes how the computer performs those functions. Considered with the inherited limitations, the virtual service executes the same evaluation and returns the selected response. Claim 15’ processors and stored instructions implement that procedure without adding a further technical operation. The additional rule sets thus refine the abstract evaluation itself, rather than integrate it into a practical application or supply significantly more. MPEP §§ 2106.04(d)(1), 2106.05(f), and 2106.05(h). Accordingly, claims 10 and 15 are directed to the abstract idea without significantly more.
Claims 11 and 16
Claims 11 and 18 further recite that the different identifiers are respectively associated with different client applications or different development teams associated with the different client applications. These associations specify what the identifiers represent within the inherited rule evaluation. A person can label separate lists of rules by application or development team, select the list corresponding to a supplied identifier, and apply its condition to determine the response. The associations therefore further describe the organization and evaluation of information within the mental process. MPEP § 2106.04(a)(2), subsection III.
The identifiers perform the inherited function of selecting corresponding rules, but their added meaning as application or team designations does not change that operation. The claims require no further operation that depends on characteristics of the represented application or team. Considered with all inherited limitations, the engine still matches the supplied identifier and input to a rule and returns the specified response. Associating the labels with applications or teams limits the context of that evaluation without adding a particular improvement to computer operation. The associations therefore do not integrate the exception into a practical application. MPEP §§ 2106.04(d)(1), 2106.05(f), and 2106.05(h). Individually and in the ordered combination, these associations refine the information used by the same evaluation; implementing that evaluation through the inherited computing elements does not supply significantly more. Accordingly, claims 11 and 16 remain directed to the abstract idea without significantly more. MPEP §§ 2106.05(d) and 2106.05(f).
Claim 20
Claim 20 further recites different sets of virtual service rules corresponding to different identifiers, with the identifiers associated with different client applications or development teams associated with those applications. A person can organize separate lists by those identifiers and select the appropriate list and rule for a supplied identifier and input. These limitations further specify the inherited mental evaluation. The indenters select rules, bur their application or team associations require no further operation based on characteristics of the represented application or team. In combination with claim 17, the sorted instructions implement the same identifier comparison, rule selection, and response procedure, The organization and meaning of the evaluated information do not integrate the exception into a practical application, and storing instructions to perform that evaluation and communicate its answer does not supply significantly more. MPEP §§ 2106.04(a) (2), subsection III; 2106.04(d)(1); 2106.05(d), subsection II, computer functions item iv; 2106.05(f); and 2106.05(h).
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-10, 12-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Burde, U.S. PG-Publication No. 2020/0394122 A1 (hereinafter BURDE), in view of Reddy et al., U.S. PG-Publication No. 2016/0191415 A1 (hereinafter REDDY).
Claim 1
BURDE discloses a computer-implemented method. ¶ 0022: Client device 110, service 120, and service provider server 130 include processors and memory for executing program instructions implementing the disclosed operations.
BURDE discloses executing, by a virtual service proxy engine executed via a first computing system, a virtual service that corresponds with a service executed by a second computing system. ¶ 0021: Service provider server 130 provides a testing framework with a simulation service that “simulates service 120” and returns corresponding status codes and data. ¶ 0037: Simulation framework 130 executes software modules on server 130 and utilizes simulation service 142 to simulate real service requests and responses. ¶ 0030: Service 120 is a real data service implemented by a data processing device/server with processing applications.
BURDE discloses receiving, by the virtual service proxy engine, and from a client application configured to use a particular identifier, a service request indicating the particular identifier and at least one input parameter. ¶ 0015: The framework changes an identifier in the application’s configuration or code so that application calls the simulation endpoint. ¶ 0014: The simulated service has an “endpoint identifier” used for application API calls; examples include database lookups and cached data retrieval “using a key.” ¶ 0053: A simulated account service test uses an account number passed between the application and service provider.
BURDE discloses sending, by the virtual service proxy engine, the response to the client application in response to the service request. ¶ 0016: After the application calls the simulation service, that service “returns the result to the application.”
BURDE does not expressly disclose identifying, by the virtual service proxy engine, a particular virtual service rule, of a plurality of virtual service rules for the virtual service, that corresponds with the particular identifier and the at least one input parameter; and determining, by the virtual service proxy engine, and based on the particular virtual service rule, a response corresponding to the at least one input parameter.
REDDY discloses identifying, by the virtual service proxy engine, a particular virtual service rule, of a plurality of virtual service rules for the virtual service, that corresponds with the particular identifier and the at least one input parameter. ¶ 0056: The request includes a network-resource identifier and additional parameters. The input processing module passes the request to the analysis module to determines rules associated with the requested resource. ¶ 0059: A mapping table maps an index associated with each network resource to an indicator of a corresponding set of rules. ¶ 0057: The mapping module compares the request with each retrieved rule based on the request’s content and parameters, identifying matches between request parameters and rules.
REDDY discloses determining, by the virtual service proxy engine, and based on the particular virtual service rule, a response corresponding to the at least one input parameter. ¶ 0053: The server specific plug-in is incorporated into the server’s runtime processing flow, applies rules to incoming requests, and generates responses based on applying those rules. ¶ 0077: The plug-in evaluates whether rules apply to the request. If a rule applies, “the configured response parameters are returned in the HTTP response.”
The modified BURDE framework would maintain multiple response rules for its simulated service. The request’s simulation service identifier would identify the applicable resource associated rules, and its input parameters would select a matching rule. The framework would determine the simulated response from that rule and return it through BURDE’s existing response path.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the simulation service request processing of BURDE to incorporate the resource associated rule lookup, request parameter matching, and rule based response generation taught by REDDY. One of ordinary skill in the art would be motivated to integrate that rule processing functionality into BURDE, with a reasonable expectation of success, in order to configure and update simulation response behavior through centrally maintained rules applied locally by the server, thereby reducing the time needed to implement, test, and deploy behavior changes and reducing reliance on infrastructure specialists, as supported by REDDY ¶¶ 0022-0023 and 0093.
Claim 2
BURDE discloses wherein the client application is configured to send the service request to the virtual service proxy engine, instead of to the service executed by the second computing system, during testing of the client application. ¶ 0060: To perform application testing, service call identifiers are replaced with simulation service identifiers in the application’s dependencies, causing the application to call “the simulation service in place of the real or live service.” After testing, those changes may be reversed. ¶ 0015: The framework changes the service identifier in the application’s configuration or code so that the application is directed to the simulation endpoint instead of the original service.
Claim 3
BURDE discloses wherein: the virtual service proxy engine is associated with a test environment. ¶ 0013: The application testing platform simulation services for testing application behavior in different environments and conditions.
BURDE discloses the virtual service proxy engine is configured, at a first time when the test environment is active, to identify the particular virtual service rule, determine the response based on the particular virtual service rule, and send the response to the client application. ¶ 0046: During the execute phase, applications to simulation services “trigger policy rules” and cause the simulation service to return data, status information, or other responses to the application. ¶ 0060: Application dependencies are changes to call simulation services during test. After testing, the changes may be reversed so that the application again obtains data from the real service.
BURDE does not expressly disclose the virtual service proxy engine is configured, at a second time when the test environment is inactive, to serve as a pass-through and to forward the service request to the service executed by the second computing system instead of identifying the particular virtual service rule, determining the response based on the particular virtual service rule, and sending the response to the client application.
REDDY discloses the virtual service proxy engine is configured, at a second time when the test environment is inactive, to serve as a pass-through and to forward the service request to the service executed by the second computing system instead of identifying the particular virtual service rule, determining the response based on the particular virtual service rule, and sending the response to the client application. ¶ 0089: An administrator can “remove, add, or update rules” while the application server remains active. ¶ 0057: An existing process may already handle the request. When no rule matches, the request may require no modification. ¶ 0066: When no mapping exists between the request and the rules associated with the resource, modification of the request may be unnecessary.
The proposed combination is configured so that the proxy applies simulation rules while the test environment is active. When testing ends, change the proxy’s runtime configuration to bypass simulation rules selection and forward requests to the corresponding real service.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the transition between simulated and real service processing of BURDE to incorporate REDDY’s removal or updating of rules while the server remains active and its processing of requests without modification when rules do not apply. One of ordinary skill in the art would be motivated to integrate this functionality into BURDE, with a reasonable expectation of success, in order to change between testing and ordinary service operation through the proxy’s runtime configuration without stopping the server or repeatedly changing the client’s service configuration, as inferred from REDDY ¶¶ 0057, 0066, and 0089.
Claim 4
REDDY discloses receiving, by the virtual service proxy engine, and from the client application, a second service request that indicates the particular identifier and at least one second input parameter. ¶ 0056: The input processing module receives a request from a client, such as a web browser. The request includes a network resource identifier and additional parameters including a query.
REDDY discloses determining, by the virtual service proxy engine, that the at least one second input parameter does not satisfy match criteria of any virtual service rule, of the plurality of virtual service rules, that is associated with the particular identifier. ¶ 0059: A mapping table associates each network resource’s index with an indicator of a corresponding set of rules. ¶ 0057: The mapping module compares the request’s content and parameters with each retrieved rule and may determine that “no match” was found. ¶ 0066: The mapping module may determine that no mapping exists between the request and the rules associated with the network resource.
REDDY discloses forwarding, by the virtual service proxy engine, and based on determining that the at least one second input parameter does not satisfy the match criteria of any virtual service rule that is associated with the particular identifier, the second service request to the service executed by the second computing system. ¶ 0057: An existing process may already handle the request; if no rule matches, the request may require no modification. ¶ 0066: When no mapping is found between the request and the resource’s rules, “no modification may be necessary on the request.”
Claim 5
REDDY discloses wherein the service request is a Hypertext Transfer Protocol (HTTP) request or a Simple Object Access Protocol (SOAP) message. ¶ 0076: HTTP client 405 “sends HTTP requests to HTTP server 411” and receives HTTP responses. ¶ 0077: The server delegates incoming HTTP requests to its plug-in, which evaluates applicable rules and returns configured response parameters when a rule applies.
Claim 6
REDDY discloses identifying, by the virtual service proxy engine, a set of virtual service rules that corresponds to the particular identifier indicated by the service request, wherein different virtual service rules, within the set of virtual service rules, are respectively associated with different match criteria. ¶ 0056: The request includes a network resource identifier and other parameters. The analysis module determines rules associated with the requested resource. ¶ 0059: A mapping table maps an index associated with each network resource to an indicator of a corresponding set of rules. ¶ 0063: Rules direct requests based on parameters such as location, device type, or version. The example directs a technical assistance request for “model A” to one page and the same request for “model B” to a different page.
REDDY discloses identifying, by the virtual service proxy engine, the particular virtual service rule from among the set of virtual service rules by determining that match criteria of the particular virtual service rule is satisfied by the at least one input parameter indicated by the service request. ¶ 0057: After the analysis module determines the applicable rules, the mapping module retrieves them and compares the request with each rule based on the request’s content and parameters, identifying matches. ¶ 0063: The mapping module determines a mapping between the request’s components and each applicable rule; the device model example illustrates conditional handling based on a request parameter.
Claim 7
REDDY discloses the at least one input parameter indicated by the service request comprises multiple input parameters. ¶ 0056: A request may include multiple parameters, including a domain name, IP address, resource identifier, port number, and query.
REDDY discloses the set of virtual service rules is associated with a priority order. ¶ 0088: The rule configuration interface includes “a priority 505 of the rule compares to other rules.”
REDDY discloses identifying the particular virtual service rule further comprises:
identifying multiple virtual service rules, in the set of virtual service rules, that have distinct match criteria satisfied by at least one of the multiple input parameters indicated by the service request. ¶ 0057: The mapping module evaluates the request against each retrieved rule using the request’s content and parameters. The evaluation can produce “one or more matches” between request parameters and rules. ¶ 0063: Rules can depend on different request attributes, including device location, type, or version.
REDDY discloses identifying the particular virtual service rule as a highest-priority virtual service rule, of the multiple virtual service rules, based on the priority order. ¶ 0088: Each rule may have a configured priority relative to other rules. ¶ 0077: When a rule applies, its configured response parameters are returned in the HTTP response.
Claim 8
BURDE discloses receiving, by the virtual service proxy engine, and via a user interface, user input corresponding with the particular identifier. ¶ 0038: Interfaces allow a user to generate or adjust simulation service 142, including its identifiers simulated output, and response or status codes. ¶ 0026: The testing application allows users to select simulation services and modify them by providing service call identifiers, response data, or status identifiers.
BURDE does not expressly disclose adjusting, by the virtual service proxy engine, at least one virtual service rule, of the plurality of virtual service rules, that corresponds with the particular identifier based on the user input.
REDDY discloses adjusting, by the virtual service proxy engine, at least one virtual service rule, of the plurality of virtual service rules, that corresponds with the particular identifier based on the user input. ¶ 0079: Administrators or business users can “update and deploy rules using a rule builder interface.” Update requests cause changes according to supplied parameters. ¶ 0059: A mapping table associates each network resource’s index with its corresponding set of rules. ¶ 0089: Users can “remove, add, or update rules” while the server remains active. The server plug-in detects update requests and performs the appropriate action using their supplied data.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the simulation configuration interface and processing of BURDE to incorporate REDDY’s interface for updating rules and its execution of tule updates, such that user input for an identified simulation service adjusts a rule associated with that identifier. One of ordinary skill in the art would be motivated to integrate this functionality into BURDE, with a reasonable expectation of success, in order to reduce the time needed to implement, text, and deploy changes in service behavior and reduce reliance on infrastructure specialists through configurable rules, as supported by REDDY ¶¶ 0022 and 0093.
Claim 9
REDDY discloses wherein the service request indicates the particular identifier via at least one of: a header value associated with the service request, a body of the service request, a uniform resource locator (URL) path used by the client application to submit the service request to the virtual service proxy engine, or a port used by the client application to submit the service request to the virtual service proxy engine. ¶ 0020: The server assigns the resource a simplified URL containing the path /ccc/resrouce1. ¶ 0021: The server stores a rule mapping the simplified URL to the resource’s actual URL. ¶ 0056: The request URL includes a network resource identifier and other parameters. The analysis module determines rules associated with the requested resource.
Claim 10
REDDY discloses different sets of virtual service rules, within the plurality of virtual service rules, respectively correspond with different identifiers. ¶ 0059: A mapping table associates an index for each network resource with “an indicator of a set of rules.” ¶ 0056: The request includes a network resource identifier, and the analysis module determines rules associated with the requested resource.
REDDY discloses the different sets of virtual service rules comprise: a first virtual service rule associated with the particular identifier and the at least one input parameter, the first virtual service rule defining a first value of the response. ¶ 0057: After retrieving the applicable rules, the mapping module compares the request’s content and parameters with each rule and identifies matches. ¶ 0077: If a rule applies, “the configured response parameters are returned in the HTTP response.”
REDDY discloses a second virtual service rule associated with a second identifier, of the different identifiers, the second virtual service rule defining a second value of the response. ¶ 0059: Each resource index is associated with its corresponding set of rules. ¶ 0077: The applicable rules supplies configured response parameters.
Claims 12-15
Claims 12-15 are rejected utilizing the rationale for claims 1, 6, 7, and 10; the claims are directed to a system performing the method.
Claims 17-19
Claims 17-19 are rejected utilizing the rationale for claims 1, 6, and 7; the claims are directed to a medium storing instructions corresponding to the method.
Claims 11, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over BURDE, in view of REDDY, further in view of Burruss et al., U.S. PG-Publication No. 2018/0165112 A1 (hereinafter BURRUSS).
Claim 11
BURRUSS discloses wherein the different identifiers are respectively associated with at least one of: different client applications, or different development teams associated with the different client applications. ¶ 0027: Test identifiers can identify test associated with particular customers or users. A client device initiates test requests through an API, and a specific API may be associated with the test identifier. ¶ 0045: Customers may have respective APIs that permit tagging test commands with their identifiers. The identifier can accompany the command in metadata. ¶ 0046: A lookup table identifies the test service associated with the same test identifier as the command. ¶ 0050: A request containing a test identifier can identify a customer’s variation of a service algorithm and cause the corresponding test service to be instantiated.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the identifier associations used to select virtual service rules in the combination of BURDE-REDDY to incorporate BURRUSS’s test identifiers and selection of corresponding test configurations, by assigning respective identifiers to different client applications. One of ordinary skill in the art would be motivated to integrate that selection technique into the combination of BURDE-REDDY, with a reasonable expectation of success, in order to ensure that each application receives the intended test behavior when different applications share the testing infrastructure, avoiding application of another test’s configuration, as inferred from BURRUSS ¶¶ 0027, 0045-0046, and 0050.
Claim 16
Claim 16 is rejected utilizing the rationale for claim 11; the claims are directed to a system performing the method.
Claim 20
Claim 20 is rejected utilizing the rationale for claims 10 and 11; the claims are directed to a medium storing instructions corresponding to the method.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Battaglia, U.S. PG-Publication No. 2020/02333787 A1. BATTAGLIA discloses a mocking server that retrieves an API specification using an identifier, generates a mock implementation, and returns simulated responses based on request parameters and the specification. BATTAGLIA, ¶¶ 0035-0038.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 9-5:30 CT.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 September 18, 2026
Prosecution Insights