Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 03/04/2026. Claims 1, 9 and 17 have been amended. Claims 1-20 are pending, of which claims, of which claim 1, claim 9 and 17 are in independent form.
Response to Argument
3. Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
4. Claims 1-20 are pending, of which claims, of which claims 1, 9 and 17 are in independent form.
The Office's Note:
5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
6. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Oleszkiewicz (US 20200110654– hereinafter Oleszkiewicz), in view of Ranjan (US 20180349150– hereinafter Ranjan), i n view of Kancharia (US 20200293626– hereinafter Kancharia), in view of Dutta (US 20110258611– hereinafter Dutta) and further in view of Chevallier-Mames(US 20130232578– hereinafter Chevallier-Mames).
Claim 1 is rejected, Oleszkiewicz teaches a method for managing operation of endpoint devices of a deployment, the method comprising (Oleszkiewicz, abstract and summary):
obtaining logs for operation of a service hosted by at least an endpoint device of the endpoint devices (Oleszkiewicz, US 20200110654, fig. 1 and para [0026], The arrow labeled 112 indicates a request of a service being sent via the network interface 102 to the computer system 100... the memory 108 is further shown as containing a stack trace 120. The stack trace 120 is used to determine a subset of the multiple software methods 122. The subset 122 may for example be responsible for causing the service failure. Fig. 2 and para [0028], Next at block 206, a stack trace 120 is performed to identify a subset 122 of the multiple software methods 114. Then at block 208 source code 124 is provided for the subset 122 of the multiple software methods 114);
for a flow of the flows (Oleszkiewicz, para [0026-0028], stack trace 120):
identifying a first portion of source code for the service corresponding to the flow using a first flow classified logs (Oleszkiewicz, fig. 2 and para [0028-0029], at block 208 source code 124 is provided for the subset 122 of the multiple software methods 114. The source code 124 could be provided from several sources. The source code could for example be retrieved from a repository or could be provided by decompiling the software methods. Para [0034-0046], The ALM identifies automatic variables/method parameters in the source code for the methods identified in step (2).), and
identifying a second portion of source code for the service corresponding to the flow using a second flow classified log(Oleszkiewicz, fig. 2 and para [0028-0029], at block 208 source code 124 is provided for the subset 122 of the multiple software methods 114. The source code 124 could be provided from several sources. The source code could for example be retrieved from a repository or could be provided by decompiling the software methods. Para [0034-0046], The ALM identifies automatic variables/method parameters in the source code for the methods identified in step (2).)
obtaining at new service using the aggregate source code (Oleszkiewicz, fig. 2 and para [0028-0029], at block 210, the source code 124 is modified for the subset 122 of the multiple software methods 114 by adding logging statements to generate modified source code 126.); and
replacing the service using at least the new service to update operation of the deployment to obtain an updated deployment(Oleszkiewicz, fig. 2 and para [0029], Next at block 212, the service is re-executed using the modified source code 126. ); and
providing computer implemented services using the updated deployment(Oleszkiewicz, fig. 2 and para [0029], Next at block 212, the service is re-executed using the modified source code 126. ).
The Office would like to use prior art Ranjan to back up Oleszkiewicz to further teach limitation
a service (Ranjan, US 20210334384, para [0003], the method includes storing a request of a service to be executed by a computer system. The service is performed using multiple software methods. The method further includes executing the service by providing the request to a computer system. The method further includes detecting a failure of the service. Para [0015-0024], the service is a microservice. The computer-implemented method may be particularly applicable to a microservice because they tend to be particularly fine grained and lightweight protocols. The use of micro services enables the decomposing or breaking apart of an application into a number of smaller services that improves modularity. This increase in modularity may facilitate the automated generation of the log file.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Ranjan into Oleszkiewicz to enable facilitating building, testing, and releasing of software in a rapid and reliable manner. The method allows a cloud computing environment to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device, thus enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. The cloud consumer can unilaterally provision computing capabilities such as server time and network storage, as needed automatically without requiring human interaction with the service's provide as suggested by Ranjan (See abstract and summary).
Oleszkiewicz and Ranjan do not explicitly teach
classifying the logs into flows based on behavior identifiers to obtain flow classified logs, the logs comprising behavior identifiers usable to discriminate flows corresponding to the flows, and the logs being generated by the service during the operation of the service;
wherein each of the behavior identifiers is time stamped based on a function invocation time, and wherein classifying the logs into flows comprises comparing the behavior identifiers of the logs to an identifier of each flow
However, Kancharia teaches
classifying the logs into flows based on behavior identifiers to obtain flow classified logs, the logs comprising behavior identifiers usable to discriminate flows corresponding to the flows, and the logs being generated by the service during the operation of the service(Kancharia, US 20200293626, fig. 7 and para [0048-0054], FIG. 7 illustrates one example of a product behavior document that may be generated in certain embodiments of the disclosed system. In this example, the product flow for a successful order creation for an existing customer is shown. Here, the functional blocks invoked in the source code during runtime in this product use scenario have been logged and mapped to functional block information in the pre-configured document object 600. In this example, the high-level operations executed by the functional blocks of the source code are shown in a hierarchical manner in the product behavior document. In certain embodiments, the product behavior document also includes the functional IDs executed in the source code.);
wherein classifying the logs into flows comprises comparing the behavior identifiers of the logs to an identifier of each flow(Kancharia, para [0048], FIG. 7 illustrates one example of a product behavior document that may be generated in certain embodiments of the disclosed system. In this example, the product flow for a successful order creation for an existing customer is shown. Here, the functional blocks invoked in the source code during runtime in this product use scenario have been logged and mapped to functional block information in the pre-configured document object 600. In this example, the high-level operations executed by the functional blocks of the source code are shown in a hierarchical manner in the product behavior document. In certain embodiments, the product behavior document also includes the functional IDs executed in the source code. Para [0049-0054], In this example, item 1 of the product behavior document has the title “Received Order Request.” Functional block IDs 602 and 604 correspond to the functional blocks executed in the source code when executing a “Received Order Request.” A high-level description of the operation executed in the source code with respect to functional block ID 602 is presented at item 1.a—“Read order request message.” A high-level description of the operation executed in the source code with respect to functional block ID 604 is presented at item 1.b—“Read order request message.”)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Kancharia into Oleszkiewicz and Ranjan to execute source code in a product use scenario, where the source code has a multiple of functional blocks executed to implement the product use scenario. The multiple of functional blocks are configured with embedded functional block information. The product behavior information is generated for the product use scenario using the embedded functional block information of functional blocks executed during run time of the source code in the product use scenario. The product behavior information is used to generate a product behavior document for display to a user. The product behavior document displays human readable functional flow information corresponding to a sequence in which the multiple of functional blocks are executed during run time of the source code in the product use scenario as suggested by Kancharia (See abstract and summary).
The Office notes that Kancharia also teaches
identifying a first portion of source code for the service corresponding to the flow using a first flow classified logs ((Kancharia, para [0048], FIG. 7 illustrates one example of a product behavior document that may be generated in certain embodiments of the disclosed system. In this example, the product flow for a successful order creation for an existing customer is shown. Here, the functional blocks invoked in the source code during runtime in this product use scenario have been logged and mapped to functional block information in the pre-configured document object 600. In this example, the high-level operations executed by the functional blocks of the source code are shown in a hierarchical manner in the product behavior document. In certain embodiments, the product behavior document also includes the functional IDs executed in the source code. Para [0049-0054], In this example, item 1 of the product behavior document has the title “Received Order Request.” Functional block IDs 602 and 604 correspond to the functional blocks executed in the source code when executing a “Received Order Request.” A high-level description of the operation executed in the source code with respect to functional block ID 602 is presented at item 1.a—“Read order request message.” A high-level description of the operation executed in the source code with respect to functional block ID 604 is presented at item 1.b—“Read order request message.”);
identifying a second portion of source code for the service corresponding to the flow using a second flow classified log(Kancharia, para [0048], FIG. 7 illustrates one example of a product behavior document that may be generated in certain embodiments of the disclosed system. In this example, the product flow for a successful order creation for an existing customer is shown. Here, the functional blocks invoked in the source code during runtime in this product use scenario have been logged and mapped to functional block information in the pre-configured document object 600. In this example, the high-level operations executed by the functional blocks of the source code are shown in a hierarchical manner in the product behavior document. In certain embodiments, the product behavior document also includes the functional IDs executed in the source code. Para [0049-0054], In this example, item 1 of the product behavior document has the title “Received Order Request.” Functional block IDs 602 and 604 correspond to the functional blocks executed in the source code when executing a “Received Order Request.” A high-level description of the operation executed in the source code with respect to functional block ID 602 is presented at item 1.a—“Read order request message.” A high-level description of the operation executed in the source code with respect to functional block ID 604 is presented at item 1.b—“Read order request message.”);
Oleszkiewicz, Ranjan and Kancharia do not explicitly teach
wherein each of the behavior identifiers is time stamped based on a function invocation time
However, Dutta teaches
wherein each of the behavior identifiers is time stamped based on a function invocation time(Dutta, US 20110258611, para [0073], During a message time comparing step 324, an embodiment compares message time at a caller with message time at a callee, to help stitch together static diagrams 122 during correlation 306 by using runtime information 210, namely, the message's path as it crosses a boundary 206. Time comparisons supplemented by experimental data or assumptions about transmission latency may help distinguish messages from one another, making it possible to trace the path of a given message. Para [0063], Several examples of direct correlation 336 tools and techniques are discussed below, namely, type identifying, identifier tracing, causality hooks, message content comparison, message time comparison. Another example of a direct correlation technique is communication infrastructure tracing: when a given implementation of a communication mechanism between two components has built-in tracing, the built-in tracing output (created at runtime) can be used to connect static diagrams. Para [0103], Using of techniques to correlate 306 calls between systems (such as dye injection, causality, message comparisons, time comparisons, etc.) the runtime data of exactly what systems are invoked, what systems those systems invoke, and so on can be used to connect separate diagrams together, producing an enhanced architecture diagram 204 that spans runtime boundaries 206. Runtime data provides this connection, since, in loosely-coupled systems, the configuration of services and systems used is not known until runtime, and can change over the lifetime of a run.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Dutta into Oleszkiewicz, Ranjan and Kancharia to locate a runtime determination boundary in a software architecture, where the software architecture is represented by a software architecture diagram. Runtime information is obtained for execution of an instance of the software architecture, where function level runtime information is obtained. The runtime information is correlated with the software architecture diagram for producing an enhanced architecture diagram, which documents an execution history across the runtime determination boundary as suggested by Dutta (See abstract and summary).
Oleszkiewicz, Ranjan, Kancharia don’t explicitly teach
aggregating the first portion and the second portion to obtain aggregate source code;
However, Chevallier-Mames teaches
aggregating the first portion and the second portion to obtain aggregate source code(Chevallier-Mames, US 20130232578, para [0021], An aggregating operation includes compressing or merging some lines of related instructions into fewer lines of instructions, such as, for example, merging some constants used by related instructions (in that case, aggregating can be seen as a kind of optimization process). Para [0033-0034], algorithm represented by source code can be transformed into another equivalent process or algorithm represented by another source code via an aggregation process. Aggregating is basically using some techniques of an optimizer, in order to reduce a number of lines, but they still behave the same as original. In other words, some transformations injected the fertilization or neutralization may be removed by the aggregation process, letting only those that are correctly mixed in the rest of the code. From a practical point of view, this means making some modifications in the code such that the compiler is able to simplify some parts of the code. Fig. 5 and para [0035-0039].);
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Chevallier-Mames into Oleszkiewicz, Ranjan, Kancharia and Dutta to enable iteratively performing obfuscating computer program code until difference between the original source code and the obfuscated code exceed a predetermined threshold, which can be user configurable so as to difficult to perform a reverse engineering process to reveal the original source code for security purposes when the obfuscated source code is compiled into an executable image as suggested by Chevallier-Mames (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 1, wherein replacing the service comprises(Oleszkiewicz, fig. 2 and para [0028-0029]):
identifying a plurality of new services comprising the at least the new service that provide, in aggregate, functionality that is equivalent to functionality of the service(Oleszkiewicz, fig. 2 and para [0028-0029], at block 210, the source code 124 is modified for the subset 122 of the multiple software methods 114 by adding logging statements to generate modified source code 126.);
instantiating instances of the plurality of new services on the endpoint devices(Oleszkiewicz, fig. 2 and para [0029], Next at block 212, the service is re-executed using the modified source code 126. ); and
terminating operation of the service(Oleszkiewicz, fig. 2 and para [0029], Next at block 212, the service is re-executed using the modified source code 126. ).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 2, wherein the service is a monolithic service and the plurality of new services are microservices(Ranjan, para [0003], Microservice architecture takes advantage of the fact that applications are simpler to build and maintain when broken down into smaller pieces that work seamlessly together. As such, in contrast to the more traditional monolithic application architectures, the microservice architecture is an architectural style that structures an application as a collection of smaller, more specialized parts called services (or microservices), each of which communicate with one another across common interfaces (e.g., application programming interfaces (APIs) and representational state transfer (REST) interfaces, like Hypertext Transfer protocol (HTTP). Microservices are increasingly being used in the development world as developers work to create larger, more complex applications that are better developed and managed as a combination of smaller services that work cohesively together for more extensive, application-wide functionality. Para [0015-0024], the service is a microservice. The computer-implemented method may be particularly applicable to a microservice because they tend to be particularly fine grained and lightweight protocols. The use of micro services enables the decomposing or breaking apart of an application into a number of smaller services that improves modularity. This increase in modularity may facilitate the automated generation of the log file).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 3, wherein each of the microservices is adapted to perform different flows of the flows (Ranjan, para [0046], The service input interaction test creator 124 may be responsible for creating the service interaction test cases 143, that subject the microservice under test to rigorous test scenarios to evaluate whether the microservice under test leaks sensitive information relating to the microservices with which it interacts. Para [0015-0024], the service is a microservice. The computer-implemented method may be particularly applicable to a microservice because they tend to be particularly fine grained and lightweight protocols. The use of micro services enables the decomposing or breaking apart of an application into a number of smaller services that improves modularity. This increase in modularity may facilitate the automated generation of the log file. Kancharia, fig. 7 and para [0048-0054], ).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 1, wherein the logs are obtained from at least two endpoint devices of the endpoint devices, and the service is distributed across at least the two endpoint devices (Ranjan, para [0069], At block 328, test cases in which the peer microservice responds with sensitive data are identified. For example, the service input interaction test creator may generate test cases in which the REST API of the peer microservice leaks sensitive data (e.g., via files, logs, failed call stack traces, API responses, and the like) to allow a determination to be made regarding whether the microservice under test propagates the leakage of sensitive information by the peer microservice. Para [0072], subjecting the microservice under test to the automation test cases causes the microservice under test to output results to generated datasets (e.g., files, error logs, debug logs, service logs, reports, stack traces, call stack traces, information presented to a user interface, and responses (e.g., error messages) generated by REST APIs of the microservice under test). Kancharia, US 20200293626, fig. 7 and para [0048-0054], ).
Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 5, wherein the logs are generated by software objects hosted by the at least two endpoint devices, and the software objects participate in the service (Ranjan, para [0069]. Para [0072], subjecting the microservice under test to the automation test cases causes the microservice under test to output results to generated datasets (e.g., files, error logs, debug logs, service logs, reports, stack traces, call stack traces, information presented to a user interface, and responses (e.g., error messages) generated by REST APIs of the microservice under test). Para [0015-0024], the service is a microservice. The computer-implemented method may be particularly applicable to a microservice because they tend to be particularly fine grained and lightweight protocols. The use of micro services enables the decomposing or breaking apart of an application into a number of smaller services that improves modularity. This increase in modularity may facilitate the automated generation of the log file. Kancharia, US 20200293626, fig. 7 and para [0048-0054], ).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 1, wherein the flow is a domain specific flow or a behavior specific flow(Ranjan, para [0073], At block 430, input validation test cases are run. According to one embodiment, the input validation test cases (e.g., input validation test cases 142) represent a rigorous set of tests that fully exercise all REST calls that can be made to the microservice under test and cause the microservice under test to output results to the generated datasets (e.g., generated dataset 130). Kancharia, US 20200293626, fig. 7 and para [0048-0054].).
Claim 8 is rejected for the reasons set forth hereinabove for claim 7, Oleszkiewicz, Ranjan, Kancharia, Dutta and Chevallier-Mames teach the method of claim 7, wherein the flow comprises a plurality of steps that when performed accomplish a domain specific goal or a behavior specific goal (Ranjan, para [0046], The service input interaction test creator 124 may be responsible for creating the service interaction test cases 143, that subject the microservice under test to rigorous test scenarios to evaluate whether the microservice under test leaks sensitive information relating to the microservices with which it interacts. Kancharia, US 20200293626, fig. 7 and para [0048-0054].).
As per claim 9, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 10, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 11, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the medium claim to method claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to method claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to method claim 8. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the system claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the system claim to method claim 4. Therefore, it is rejected for the same reasons as above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/
Primary Examiner, Art Unit 2199
Prosecution Insights