CTNF 19/107,630 CTNF 88322 DETAILED ACTION This Office Action is in response to the application 19/107,630 filed on 02/28/2025/2025. Claims 26-45 have been examined and are pending. Notice of Pre-AIA or AIA Status 07-03-01-aia AIA 07-03-01-r-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This Action is made Non-FINAL . Priority This application is a national stage application of PCT/IB2022/058263, filed Sept 2, 2022. Information Disclosure Statement The information disclosure statements (IDS) submitted on 02/28/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner. Claim Objection Claim 43 is objected to because of the failure to comply with 37 C.F.R. 1.75(e): Regarding claim 43 , Claim 43 is objected to as failing to comply with 37 C.F.R. 1.75(e). An independent claim should include a preamble, a transitional phrase, and a body of the claim, in which claimed limitations that the Applicants consider as new or improved elements/steps/features are positively recited within the body of the claim. Claim 1, which is directed to a “network node,” recites only functions performed by the network node and does not positively recite any embodiments of the claimed “network node.” It is suggested that claim 1 be amended to include a preamble, a transitional phrase, and sufficient descriptions of structures/features of the “network node.” Following are such examples: “A network node in a management system for configuring logging in telecommunication networks, the network node comprising : a processor; and a memory for storing instructions that, when executed by the processor cause the processor perform the steps of: …” (emphasis added). ….“ OR: “A network node in a management system for configuring logging in telecommunication networks, the network node comprising : communication circuitry configured to …; processing circuitry configured to …; and input/output devices configured to …: (emphasis added). Appropriate corrections are requested. Claim Rejections- 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claim 43 is 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. Regarding claim 43, claim 43 is directed to a “network node.” However, the claim does not recite any embodiments/components to form the claimed “network node.” As the claim does not positively recite any embodiments within the claimed “network node,” metes and bounds of the claimed network node is unclear. In addition, it’s unclear how a network node could be built without at least an embodiment. As a result, the claim is found to be indefinite for failing to particularly point out and distinctly claim the subject matter which the applicant regards as the invention. See M.P.E.P. § 2172.01 Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 26-45 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. Regarding claim 43, the claim is directed to a “network node.” However, the body of the claim does not positively recite any hardware elements within the claimed “network node.” In fact, the claim recites only functions performed by the claimed “network node.” The specification does not explicitly define the claimed “ network node ” as only implemented in hardware. One of ordinary skill in the art would understand that “ network node ” could be implemented in software, such as virtual network node. The Examiner respectfully suggests that the claim be further amended to positively recite at least one hardware element within the body of the claim to make the claim statutory subject matter under 35 U.S.C. 101. Claims 26-45 are rejected under 35 U.S.C 101 as being directed to an abstract idea without being integrated into a practical application or being significantly more. Regarding claims 26, 43-46 , the claims recite the limitations “ generate trace records …of a service .” Broadly interpreted, the aforementioned steps are directed to mental processes as said steps could be performed in the human mind. Therefore, the claims recite an abstract idea. Said abstract idea and/or judicial exception is not integrated into a practical application as the claim does not recite any other active steps that could be considered that the abstract idea is being integrated into a practical application. It’s noted that the claim recites the steps of “obtaining …,” “configuring…” However, said steps are not sufficient to consider that the abstract idea is being interpreted into a practical application as the steps are recited at a high level of generality in gathering/processing/storing information, which are a form of insignificant extra-solution activity. It’s also noted that the claims recite additional limitation/elements (i.e., “telecommunication network,” “network node” and “distributed workflow,” etc.). However, said additional elements are recited at a high-level of generality (i.e., as a generic computing device in a generic network and performing generic computing functions/workflows) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. It is noted that the claim recites some additional elements such as “ vulnerability information” and “vulnerability identifier.” However, these additional elements, taken individually and as a combination, do not result in the claim amounting to significantly more than the abstract idea because “vulnerability information” and “vulnerability identifier” in a network is recited as performing generic computer functions routinely used in information processing and software vulnerability warning and detection (Schwarzbauer [0003]. Software applications typically rely on publicly available 3rd party libraries to perform common tasks, like interacting with data bases, providing web-interfaces or to transfer, store and read data in various forms. Those 3rd party libraries are cyclically scanned by vulnerability identification services that provide reports describing identified vulnerabilities. As an example, the MITRE corporation cyclically provides the Common Vulnerabilities and Exposures list (CVE®), which contains detailed reports about identified vulnerabilities in specific versions of 3rd party libraries. ). Generic computer components recited as performing generic computer functions that are well-understood, routine, and conventional activities amounts to no more than implementing the abstract idea with a computerized system. Therefore, the claim is directed to non-statutory subject matter. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of abstract idea into a practical application, the additional element of “vulnerability information” and “vulnerability identifier” amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, these claims are not patent eligible. Regarding claims 27-42, claims 27-42 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter for the same reasons addressed above as the claims recite an abstract idea and the claims do not positively recite any other operations that could be considered as the abstract idea is being integrated into a practical application or significantly more. It’s noted that claim 27 recites the limitations: “generate …trade record …and …vulnerability scores,” claim 28 recites the limitations: “ obtaining, ” “ configuring …with the list ,” claim 29 recites the limitations “configured to generate the trace records, ” Claim 30 recites the limitations “generates the trace records,” … Said steps are either directed to mental processes and/or in a form of insignificant extra-solution activities; The aforementioned steps are not sufficient to consider that the abstract idea is being integrated into a practical application or significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As mentioned above, although the claims recite additional elements, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because as the additional elements perform generic computer content distributing functions routinely used in information technology field. Therefore, these claims are directed to non-statutory subject matter. Claim Rejections - 35 USC § 103 07-20-aia AIA 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 discloses as set forth in section 102 of this title, 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. 07-21-aia AIA Claim s 26-28, 32-36, 39-45 are rejected under 35 U.S.C. 103 as being unpatentable over Schwarzbauer et al. (“Schwarzbauer,” US 20220156383, published May 19, 2022) in view of Kumar et al. (“Kumar,” US 20220198011, published June 23, 2022) . Regarding claim 26, Schwarzbauer discloses A method for configuring logging in [telecommunication] networks executing one or more services in a distributed workflow, the method implemented by a network node in a management system and comprising ( Schwarzbauer [0016], [0092]. The so created transaction monitoring data may also be sent to a monitoring server for further processing, especially to create end-to-end transaction trace data that describes the execution of distributed transactions that cross thread, process, and host computing system boundaries. The configuration data may be fetched from a monitoring server, intermediate nodes that relays communication between agents and monitored nodes or from a storage location situated at the host computing system executing the starting process .): obtaining vulnerability information for one or more services currently deployed in a communications network, wherein the vulnerability information comprises, for each of the one or more services ( Schwarzbauer [0195]-[0196]. Coming now to FIG. 7c , which shows a vulnerability issue record 159, which may be used to represent identified vulnerabilities in a monitored environment . A vulnerability issue record 159 may contain but is not limited to a vulnerability issue identifier 731, which identifies the vulnerability issue record 159, a vulnerability report identifier 732, which identifies the vulnerability report 148 describing the found vulnerability, a library identifier 733, which identifies a library, e.g. by a vendor name, a product name and a version, a location independent priority scores section 734, which contains priority scores for the identified vulnerability that are independent from the topological location of the entity on which the vulnerability was observed, and an affected topology entity list 738, describing the locations on which the vulnerability was observed .): a vulnerability identifier (VID) identifying a vulnerability of the service; and a vulnerability score indicating a severity of the vulnerability ( Schwarzbauer [0188]. A vulnerability report 148 may contain but is not limited to a vulnerability report identifier 701, which uniquely identifies the vulnerability, a vulnerability type 702, which specifies the type of the vulnerability (e.g. SQL injection, XSS, etc.), a vulnerability severity level 703 quantifying the general severity of the vulnerability , data describing the affected technology type 704 (e.g. Java, .NET, HTML/JavaScript etc.), an affected library list 705 which identifies libraries that are affected by the vulnerability, fix information data 714 specifying whether a fix for the vulnerability exists optionally also and how it can be applied, and exploit information 715 describing known techniques to exploit the vulnerability .); and configuring a logging framework to generate trace records including the VID and the vulnerability score of a service currently deployed in the communications network for a use case associated with execution of the service ( Schwarzbauer [0057], [0061], [0188]. The transaction trace and topology data processor uses the received transaction trace data to incrementally create end-to-end transaction trace records describing individual transaction executions . Created end-to-end transaction trace records are stored in a transaction trace repository 151. If the reported vulnerable API calls were initiated by monitored transactions, the corresponding end-to-end transaction traces 152 are fetched and updated 162 with the corresponding vulnerable API call data. Transaction trace data for vulnerable API calls reported in vulnerability issues 157 may also be fetched 173 by the vulnerability priority calculator for its analyses, and the vulnerability priority calculator may also fetch detail data from vulnerability reports referred by vulnerability issues, like a severity grade of the vulnerability or indicators for the existence of an exploit or a fix of the vulnerability. A vulnerability report 148 may contain but is not limited to a vulnerability report identifier 701, which uniquely identifies the vulnerability, a vulnerability type 702, which specifies the type of the vulnerability (e.g. SQL injection, XSS, etc.), a vulnerability severity level 703 quantifying the general severity of the vulnerability , data describing the affected technology type 704 (e.g. Java, .NET, HTML/JavaScript etc.) .). Schwarzbauer does not explicitly disclose: a telecommunication network. However, in an analogous art, Kumar discloses a method comprising: a telecommunication network ( Kumar [0074], [0101]. FIG. 1 is a block diagram illustration of a security ecosystem 100. In the example of FIG. 1, security ecosystem 100 may be an enterprise, a government entity, a data center, a telecommunications provider, a “smart home” with computers, smart phones, and various internet of things (IoT) devices, or any other suitable ecosystem. Client device 300 may also include an operating system 316. Operating system 316 may be configured to provide notifications of any attempt to exploit a known vulnerability. For example, operating system 316 could be a Microsoft Windows operating system that is configured to provide a CVE event trace whenever there is an attempt to exploit a known vulnerability. ). Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Kumar and Schwarzbauer to include the step of: a telecommunication network. One would have been motivated to provide users with a means for extending the detection of software vulnerability through known vulnerability libraries and patches to a telecommunication network. ( See Kumar [0101]. ) Regarding claim 27 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses wherein the logging framework is configured to generate at least one trace record including a plurality of VIDs and a plurality of corresponding vulnerability scores, and wherein each VID in the at least one trace record identifies a different vulnerability of the service ( Schwarzbauer [0057], [0061], [0188]. The transaction trace and topology data processor uses the received transaction trace data to incrementally create end-to-end transaction trace records describing individual transaction executions . Created end-to-end transaction trace records are stored in a transaction trace repository 151. If the reported vulnerable API calls were initiated by monitored transactions, the corresponding end-to-end transaction traces 152 are fetched and updated 162 with the corresponding vulnerable API call data. Transaction trace data for vulnerable API calls reported in vulnerability issues 157 may also be fetched 173 by the vulnerability priority calculator for its analyses, and the vulnerability priority calculator may also fetch detail data from vulnerability reports referred by vulnerability issues, like a severity grade of the vulnerability or indicators for the existence of an exploit or a fix of the vulnerability. A vulnerability report 148 may contain but is not limited to a vulnerability report identifier 701, which uniquely identifies the vulnerability, a vulnerability type 702, which specifies the type of the vulnerability (e.g. SQL injection, XSS, etc.), a vulnerability severity level 703 quantifying the general severity of the vulnerability , data describing the affected technology type 704 (e.g. Java, .NET, HTML/JavaScript etc.) .). Regarding claim 28, Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses obtaining a list of one or more service component identifiers, wherein each service component identifier identifies a respective service currently deployed in the network and a version of the respective service ( Schwarzbauer [0053]. Loading sensors 113 may be placed to code that loads external packages of executable code (e.g., in form of 3rd party libraries) into the process for execution. Loading sensors may analyze 120 the loaded executable code and meta-data bundled with the executable code to create identity evidence data 121 that may be used to determine the identity of loaded executable packaged. This evidence data may contain but is not limited to data identifying vendor, name, and version of the loaded package . Generated evidence data will be sent to the in-process-agent, which forwards 133 it to the monitoring server 140 in form of in-process library evidence data .); and configuring the logging framework with the list of one or more service component identifiers ( Schwarzbauer [0083]. A library loading evidence data record 240 contains data describing a library loading event and identity evidence data for the loaded library. A library loading evidence data record 240 may contain but is not limited to a loading entity identifier 241, which identifies the entity, like e.g. a process that performed the observed library loading, a loading event identifier 242 which uniquely identifies the monitored loading event, a loading event timestamp 243 . A library identity evidence data set 245 may contain multiple library identity evidence entries 246 and a library identity evidence entry 246 may contain but is not limited to an evidence type 247 that specifies the source of the described evidence (e.g. executable code, file name or package manager data) and its sematic (e.g. package name, file name, library name/vendor/version extracted from package manager data) , and an evidence value 248 that contains the extracted evidence (e.g. extracted library/library vendor name, library version, class/package name, library file name) .). Regarding claim 32, Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses wherein the vulnerability information comprises a Common Vulnerabilities and Exposures (CVE) list identifying one or more publicly known cybersecurity vulnerabilities for the one or more services currently deployed in the communications network ( Schwarzbauer [0204]. FIG. 8a described the process of updating the unified vulnerability repository 157 with new and updated vulnerability report data from external, public vulnerability databases. Various public vulnerability databases are available for public usage, most of them also providing APIs to access and query structured vulnerability report data. Example vulnerability data bases include the Common Vulnerability and Exposures database (CVE), managed by the MITRE corporation, VULDB, a community managed vulnerability database or the Vulnerability Lab database, managed by the Evolution Security GmbH .). Regarding claim 33, Schwarzbauer and Kumar disclose the method of claim 32. Schwarzbauer further discloses wherein each entry on the CVE list comprises the VID and the vulnerability score for a respective service currently deployed in a communications network ( Schwarzbauer [0188], [0204]. A vulnerability report 148 may contain but is not limited to a vulnerability report identifier 701, which uniquely identifies the vulnerability, a vulnerability type 702, which specifies the type of the vulnerability (e.g. SQL injection, XSS, etc.), a vulnerability severity level 703 quantifying the general severity of the vulnerability , data describing the affected technology type 704 (e.g. Java, .NET, HTML/JavaScript etc.) . FIG. 8a described the process of updating the unified vulnerability repository 157 with new and updated vulnerability report data from external, public vulnerability databases. Various public vulnerability databases are available for public usage, most of them also providing APIs to access and query structured vulnerability report data. Example vulnerability data bases include the Common Vulnerability and Exposures database (CVE), managed by the MITRE corporation, VULDB, a community managed vulnerability database or the Vulnerability Lab database, managed by the Evolution Security GmbH .). Regarding claim 34 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses obtaining updated vulnerability information responsive to determining that: at least one service currently deployed in the communications network has been modified; or a new service has been deployed in the communications network ( Schwarzbauer [0244]. The process starts with step 1000, either when a specific time (1 minute, 5 minutes, 1 hour etc.) since the last execution of the vulnerability detection process has elapsed, when new or updated vulnerability reports 148 are available or when specific changes of the monitored environment are observed, like deployment of new software versions or libraries or the addition of new entities, like host computing systems or processes, to the monitored environment. ); and re-configuring the logging framework to generate the trace records for the use case according to the updated vulnerability information ( Schwarzbauer [0061], [0247], [0258]. If the reported vulnerable API calls were initiated by monitored transactions, the corresponding end-to-end transaction traces 152 are fetched and updated 162 with the corresponding vulnerable API call data . Following step 1003 may then, for each vulnerability report fetched by step 1002 identify library entries 706 matching the library identification data determined in step 1001. Vulnerability reports and identified library entries may then be used to create or update corresponding vulnerability issues 159 , as described in detail in FIG. 10 b. Afterwards, step 1022 may fetch those vulnerable API call records 210 contained in the potentially vulnerable API call list 506 of the received topology entity node 500 that represent calls to the API of the library that is identified by the library identifier 733 of the received vulnerability issue 159 .). Regarding claim 35 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses: obtaining updated vulnerability information responsive to determining that the vulnerability information for any of the one or more services currently deployed in the communications network has changed ( Schwarzbauer [0244]. The process starts with step 1000, either when a specific time (1 minute, 5 minutes, 1 hour etc.) since the last execution of the vulnerability detection process has elapsed, when new or updated vulnerability reports 148 are available or when specific changes of the monitored environment are observed, like deployment of new software versions or libraries or the addition of new entities, like host computing systems or processes, to the monitored environment. ); and re-configuring the logging framework to generate the trace records according to the updated vulnerability information ( Schwarzbauer [0061], [0247], [0258]. If the reported vulnerable API calls were initiated by monitored transactions, the corresponding end-to-end transaction traces 152 are fetched and updated 162 with the corresponding vulnerable API call data . Following step 1003 may then, for each vulnerability report fetched by step 1002 identify library entries 706 matching the library identification data determined in step 1001. Vulnerability reports and identified library entries may then be used to create or update corresponding vulnerability issues 159 , as described in detail in FIG. 10 b. Afterwards, step 1022 may fetch those vulnerable API call records 210 contained in the potentially vulnerable API call list 506 of the received topology entity node 500 that represent calls to the API of the library that is identified by the library identifier 733 of the received vulnerability issue 159 .). Regarding claim 36 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses: wherein configuring the logging framework configures one or more logging agent functions of the logging framework to generate the trace records including the VID and the vulnerability score of the service ( Schwarzbauer [0057], [0073], [0188]. The transaction trace and topology data processor uses the received transaction trace data to incrementally create end-to-end transaction trace records describing individual transaction executions . Created end-to-end transaction trace records are stored in a transaction trace repository 151. Transaction trace data for vulnerable API calls reported in vulnerability issues 157 may also be fetched 173 by the vulnerability priority calculator for its analyses, and the vulnerability priority calculator may also fetch detail data from vulnerability reports referred by vulnerability issues, like a severity grade of the vulnerability or indicators for the existence of an exploit or a fix of the vulnerability. A vulnerability report 148 may contain but is not limited to a vulnerability report identifier 701, which uniquely identifies the vulnerability, a vulnerability type 702, which specifies the type of the vulnerability (e.g. SQL injection, XSS, etc.), a vulnerability severity level 703 quantifying the general severity of the vulnerability , data describing the affected technology type 704 (e.g. Java, .NET, HTML/JavaScript etc.), an affected library list 705 which identifies libraries that are affected by the vulnerability .). Regarding claim 39 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer further discloses: wherein the network node is a logging framework configuration node ( Schwarzbauer [0084]. Transaction trace records 250 as shown in FIG. 2e , may be used to transfer transaction trace data, describing a portion of a monitored transaction that was executed on a specific process, from in-process agents 110 injected into processes, to monitoring servers 140 .). Regarding claim 40 , Schwarzbauer and Kumar disclose the method of claim 39. Schwarzbauer further discloses wherein the vulnerability information is received from a vulnerability entity associated with the management system ( Schwarzbauer [0064]. The converted vulnerability reports are stored 166 in a unified vulnerability repository. Different vulnerability databases 150 may use different formats to describe vulnerabilities and provide different type and quality of data describing vulnerabilities. The vulnerability report importer aligns these different formats and data qualities and generates vulnerability reports 148 in a unified format .). Regarding claim 41 , Schwarzbauer and Kumar disclose the method of claim 40. Schwarzbauer further discloses wherein the list of one or more service component identifiers is received from a configuration management entity associated with the management system ( Schwarzbauer [0075], [0083]. Coming now to FIGS. 2a-2g which show various data records that may be used by a monitoring system to transfer data between agents and monitoring servers. A library loading evidence data record 240 contains data describing a library loading event and identity evidence data for the loaded library. A library loading evidence data record 240 may contain but is not limited to a loading entity identifier 241, which identifies the entity, like e.g. a process that performed the observed library loading, a loading event identifier 242 which uniquely identifies the monitored loading event, a loading event timestamp 243. A library identity evidence data set 245 may contain multiple library identity evidence entries 246 and a library identity evidence entry 246 may contain but is not limited to an evidence type 247 that specifies the source of the described evidence (e.g. executable code, file name or package manager data) and its sematic (e.g. package name, file name, library name/vendor/version extracted from package manager data), and an evidence value 248 that contains the extracted evidence (e.g. extracted library/library vendor name, library version, class/package name, library file name) .). Regarding claim 42 , Schwarzbauer and Kumar disclose the method of claim 40. Schwarzbauer further discloses wherein one or both of the vulnerability entity and the configuration management entity are implemented by the logging framework configuration node ( Schwarzbauer [0075], [0083]. Coming now to FIGS. 2a-2g which show various data records that may be used by a monitoring system to transfer data between agents and monitoring servers. A library loading evidence data record 240 contains data describing a library loading event and identity evidence data for the loaded library. A library loading evidence data record 240 may contain but is not limited to a loading entity identifier 241, which identifies the entity, like e.g. a process that performed the observed library loading, a loading event identifier 242 which uniquely identifies the monitored loading event, a loading event timestamp 243. A library identity evidence data set 245 may contain multiple library identity evidence entries 246 and a library identity evidence entry 246 may contain but is not limited to an evidence type 247 that specifies the source of the described evidence (e.g. executable code, file name or package manager data) and its sematic (e.g. package name, file name, library name/vendor/version extracted from package manager data), and an evidence value 248 that contains the extracted evidence (e.g. extracted library/library vendor name, library version, class/package name, library file name) .). Regarding claim 43, claim 43 is directed to a network node corresponding to the method of claim 26. Claim 43 is similar to claim 26 and is therefore rejected under similar rationale. Regarding claim 44, claim 44 is directed to a network node corresponding to the method of claim 26. Claim 44 is similar to claim 26 and is therefore rejected under similar rationale. Regarding claim 45, claim 45 is directed to a non-transitory computer readable medium corresponding to the method of claim 26. Claim 45 is similar to claim 26 and is therefore rejected under similar rationale . 07-21-aia AIA Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Schwarzbauer et al. (“Schwarzbauer,” US 20220156383, published May 19, 2022) in view of Kumar (“Kumar,” US 20220198011, published June 23, 2022) and Ertl (“Ertl,” US 20220245552, published Aug. 4, 2022) . Regarding claim 29 , Schwarzbauer and Kumar disclose the method of claim 28. Schwarzbauer and Kumar do not explicitly disclose: wherein the logging framework is configured to generate the trace records when a service component identifier of the service associated with the use case matches a service component identifier on the list of one or more service component identifiers. However, in an analogous art, Ertl discloses a method, comprising the step of: wherein the logging framework is configured to generate the trace records when a service component identifier of the service associated with the use case matches a service component identifier on the list of one or more service component identifiers ( Ertl [0109], [0111], [0138]. An end-to-end transaction record 310 may contain but is not limited to a service execution identifier 311, identifying a specific service execution that is part of a monitored end-to-end transaction, a service identifier 312, identifying the service on which the service execution was performed. The end-to-end transaction trace records 310 stored in the transaction list 322 of a visit record may be used to describe a specific interaction of a specific end-user (i.e., the end-user operating the browser instance identified by visit origin data 321). If parent execution identifier data 306 is available in the received service execution record, an end-to-end transaction record with a service execution identifier 311 matching the parent execution identifier may be fetched. A new service execution identifier 319 record may be created in the nested service call list 318 of the fetched end-to-end transaction record. The created service execution identifier 319 may be set to refer to the service execution identifier 311 of the new created end-to-end transaction record .). Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Ertl, Kumar and Schwarzbauer to include the step of: wherein the logging framework is configured to generate the trace records when a service component identifier of the service associated with the use case matches a service component identifier on the list of one or more service component identifiers. One would have been motivated to provide users with a means for creating an up-to-date trace record of various computing services. ( See Ertl [0138]. ) 07-21-aia AIA Claim s 30-31 are rejected under 35 U.S.C. 103 as being unpatentable over Schwarzbauer et al. (“Schwarzbauer,” US 20220156383, published May 19, 2022) in view of Kumar (“Kumar,” US 20220198011, published June 23, 2022) and Deily et al. (“Deily,” US 20050203952, published Sept. 15, 2005) . Regarding claim 30 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer and Kumar do not explicitly disclose: wherein the logging framework generates the trace records to include a use case identifier (UCID) identifying the use case and an instance of the use case. However, in an analogous art, Deily discloses a method, comprising the step of: wherein the logging framework generates the trace records to include a use case identifier (UCID) identifying the use case and an instance of the use case ( Deily [0058]. At a block 312, in the depicted implementation, the tracing infrastructure associates a Web Request GUID with the trace message. The event is then logged by the tracing infrastructure at block 314 into a trace output file (e.g., event trace log) along with the Web Request GUID of the corresponding Web request, including an event GUID for each event that is being traced. Note the Web Request GUID corresponds to the request and the event GUID corresponds to a particular event .). Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Deily, Kumar and Schwarzbauer to include the step of: wherein the logging framework generates the trace records to include a use case identifier (UCID) identifying the use case and an instance of the use case. One would have been motivated to provide users with a means for identifying trace record of a service with a unique GUID identifier. ( See Deily [0058]. ) Regarding claim 31 , Schwarzbauer, Kumar and Deily and disclose the method of claim 30. Deily further discloses wherein the trace records are correlated according to the UCID and the instance of the use case ( Deily [0058]. At a block 312, in the depicted implementation, the tracing infrastructure associates a Web Request GUID with the trace message. The event is then logged by the tracing infrastructure at block 314 into a trace output file (e.g., event trace log) along with the Web Request GUID of the corresponding Web request, including an event GUID for each event that is being traced. Note the Web Request GUID corresponds to the request and the event GUID corresponds to a particular event .). The motivation is the same as that of claim 30 above . 07-21-aia AIA Claims 3 7-38 are re jected under 35 U.S.C. 103 as being unpatentable over Sc hwarzbauer et al. (“Schwarzbauer,” US 20220156383, published May 19, 2022) in view of Kumar (“Kumar,” US 20220198011, published June 23, 2022) and Eker et al. (“Eker,” US 20130318500, published Nov. 29, 2013). Re garding claim 37 , Schwarzbauer and Kumar disclose the method of claim 26. Schwarzbauer and Kumar do not explicitly disclose: obtaining one or more trace records for one or more selected use cases; generating a graphical user interface (GUI) to display the one or more trace records; and outputting the graphical user interface to a display device for a user. However, in an analogous art, Eker discloses a method, comprising the step of: obtaining one or more trace records for one or more selected use cases; generating a graphical user interface (GUI) to display the one or more trace records; and outputting the graphical user interface to a display device for a user ( Eker [0091]. When execution has stopped (“YES” path out of decision block 705), a first subset of the first set of trace records is displayed to a user (e.g., via a Graphical User Interface—“GUI”) (step 707). It is advantageous to include a representation of a last-generated record in the first subset, although this is not a requirement in all embodiments. Such an embodiment is particularly suitable when the program is halted based on a breakpoint, since it is likely that, in such cases, the user will want to see the last thing that happened. Using the GUI, the user has an opportunity to interact with the data collected during program execution and to select, from the first subset of trace records, one of the trace records (e.g., a trace record relating to a produced/consumed token or actor state) for observation (step 709). Then, as shown in step 711, the debugging tool 213 processes the first set of trace records to identify a second set of one or more trace records from which the first trace record's existence depends (i.e., “dependence” in this case means that the first trace record came into existence during the execution of the dataflow program as a result of information (e.g., a token, state, or action firing) represented by the identified second set of trace records). A second subset of trace records is then displayed to the user, wherein the second subset of trace records is a subset of the second set of trace records (step 713) .). Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Eker, Kumar and Schwarzbauer to include the step of: obtaining one or more trace records for one or more selected use cases; generating a graphical user interface (GUI) to display the one or more trace records; and outputting the graphical user interface to a display device for a user. One would have been motivated to provide users with a means for using a GUI to display status of trace records and debugging analysis and progress. ( See Eker [0091]. ) Regarding claim 38 , Schwarzbauer, Kumar and Eker disclose the method of claim 37. Schwarzbauer further discloses an extent to which the vulnerabilities affect a workload of the one or more services currently deployed in the communications network ( Schwarzbauer [0342]-[0343]. The shown portion may be filtered 1610 to display only the subset of the topology model that is affected by a specific vulnerability issue (e.g., the vulnerability issue with vulnerability issue identifier 731 “972”). A specific entity 1605, on which a vulnerability was detected may currently be selected by a user of the monitoring system and in response to the selection, the monitoring system may display detail data 1611 of the vulnerability, a corresponding fix proposal 1612 and detail data describing the affected entity 1613 .); and one or more locations in the communications network where the one or more services are affected by the vulnerabilities ( Schwarzbauer [0340]. Further an affected entity section 1507 may identify those topology entities that are most affected by the selected vulnerability. The here displayed affected entity section e.g., lists 24 services that are provided by processes (represented as the 3 vulnerable process groups mentioned in the affected entities detail section 1503) running on 3 host computing systems .). Eker further discloses wherein the GUI is generated to include one or more control objects based on information in the one or more trace records, wherein the one or more control objects visually represent ( Eker [0091]. When execution has stopped (“YES” path out of decision block 705), a first subset of the first set of trace records is displayed to a user (e.g., via a Graphical User Interface—“GUI”) (step 707). It is advantageous to include a representation of a last-generated record in the first subset, although this is not a requirement in all embodiments. Such an embodiment is particularly suitable when the program is halted based on a breakpoint, since it is likely that, in such cases, the user will want to see the last thing that happened. Using the GUI, the user has an opportunity to interact with the data collected during program execution and to select, from the first subset of trace records, one of the trace records (e.g., a trace record relating to a produced/consumed token or actor state) for observation (step 709). Then, as shown in step 711, the debugging tool 213 processes the first set of trace records to identify a second set of one or more trace records from which the first trace record's existence depends (i.e., “dependence” in this case means that the first trace record came into existence during the execution of the dataflow program as a result of information (e.g., a token, state, or action firing) represented by the identified second set of trace records). A second subset of trace records is then displayed to the user, wherein the second subset of trace records is a subset of the second set of trace records (step 713) .). The motivation is the same as that of claim 37 above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /EDWARD LONG/ Examiner, Art Unit 2439 /LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439 Application/Control Number: 19/107,630 Page 2 Art Unit: 2439 Application/Control Number: 19/107,630 Page 3 Art Unit: 2439 Application/Control Number: 19/107,630 Page 4 Art Unit: 2439 Application/Control Number: 19/107,630 Page 5 Art Unit: 2439 Application/Control Number: 19/107,630 Page 6 Art Unit: 2439 Application/Control Number: 19/107,630 Page 7 Art Unit: 2439 Application/Control Number: 19/107,630 Page 8 Art Unit: 2439 Application/Control Number: 19/107,630 Page 9 Art Unit: 2439 Application/Control Number: 19/107,630 Page 10 Art Unit: 2439 Application/Control Number: 19/107,630 Page 11 Art Unit: 2439 Application/Control Number: 19/107,630 Page 12 Art Unit: 2439 Application/Control Number: 19/107,630 Page 13 Art Unit: 2439 Application/Control Number: 19/107,630 Page 14 Art Unit: 2439 Application/Control Number: 19/107,630 Page 15 Art Unit: 2439 Application/Control Number: 19/107,630 Page 16 Art Unit: 2439 Application/Control Number: 19/107,630 Page 17 Art Unit: 2439 Application/Control Number: 19/107,630 Page 18 Art Unit: 2439 Application/Control Number: 19/107,630 Page 19 Art Unit: 2439 Application/Control Number: 19/107,630 Page 20 Art Unit: 2439 Application/Control Number: 19/107,630 Page 21 Art Unit: 2439 Application/Control Number: 19/107,630 Page 22 Art Unit: 2439 Application/Control Number: 19/107,630 Page 23 Art Unit: 2439 Application/Control Number: 19/107,630 Page 24 Art Unit: 2439 Application/Control Number: 19/107,630 Page 25 Art Unit: 2439 Application/Control Number: 19/107,630 Page 26 Art Unit: 2439 Application/Control Number: 19/107,630 Page 27 Art Unit: 2439 Application/Control Number: 19/107,630 Page 28 Art Unit: 2439
Prosecution Insights