DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in responsive to the RCE filed on August 5, 2025, in which claim 1 has been amended. Accordingly, claim 1 remains pending for examination.
Status of Claims
3. Claim 1 is pending, of which claim 1 is rejected under 35 U.S.C. 103.
Claim Rejections - 35 USC § 103
4. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
5. 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
7. Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Frederick et al. (United States Patent Application Publication No. US 2019/0163887 A1), hereinafter “Frederick” in view of Reddy et al. (United States Patent Application Publication No. US 2019/0303541 A1), hereinafter “Reddy”.
Regarding claim 1, Frederick discloses a system comprising: a processor (full node computing devices 210 including one or more processors 211) (Frederick, FIG. 2, paragraphs [0074]-[0075]) generating a plurality of system categories (wherein FIG. 4 further illustrates a computing environment 400 including several platforms functioning as one of full node computing devices 210A-210F. In particular, data authentication and event execution computing platform 410, first social media service computing platform 450, and second social media service computing platform 460 may all function as full node computing devices 210 in computing environment 400. Consensus data may be categorized as social media data from social media service computing platforms 450, 460, user property records data from property records computing platform 470, user medical records data from medical records computing platform 480, and user data from other sources. For example, Frederick teaches that the blockchain for any given user may further include user transaction data from merchant databases and other financial records databases, estate management data from estate management databases, inheritance data from inheritance records, and other sources) (Frederick, FIGS. 2 and 4, paragraph [0091]). Frederick does not explicitly disclose wherein the processor further: utilizes a training data which contains instances with known features and assigned one system category among the plurality of system categories; utilizes a telemetry system for system composition profile, performance metric and workload composition data to derive features; utilizes a classifier algorithm to generate the plurality of system categories. In an analogous art, however, Reddy discloses wherein a processor utilizes a training data which contains instances with known features and assigned one system category among a plurality of system categories (wherein Reddy discloses adjustable parameters of a machine learning model trained on labeled historical examples of trustworthy and untrustworthy software assets, e.g., by iteratively adjusting model parameters to reduce an amount of error between predictions of the model and labeled trustworthiness determinations on a training set) (Reddy, paragraph [0127]); utilizes a telemetry system for system composition profile, performance metric and workload composition data to derive features (wherein Reddy teaches that during execution in production, various artifacts may be generated as parties report software bugs (See FIG. 2, element 52 of software lifecycle), vulnerabilities (FIG. 2, element 54) and application performance monitoring and management software may monitor performance of the software assets (FIG. 2, element 56). Reddy teaches that each of the foregoing may be performed by different entities (e.g., humans, organizations, or software applications thereof) through operation of different computing devices and corresponding applications and may generate records regarding the software asset that may be of interest to various users of the software asset or other stakeholders. Reddy further teaches that trust policies may specify that performance attributes of a given software asset must satisfy some threshold response latency or load capacity as demonstrated by specified test applications, and that trust criteria may specify parameters of a trust model by which a trust score is calculated, with the trust policy including a threshold trust score for which values below the trust score are determined to be not trustworthy and values above the trust score are determined to be trustworthy (or the relationship may be reversed for scoring systems in which lower values indicate greater trust). Again, the parameters (as shown above) may be adjustable parameters of a machine learning model trained on labeled historical examples of trustworthy and untrustworthy software assets by iteratively adjusting the model parameters to reduce an amount of error between predictions of the model and labeled trustworthiness determinations on the training set) (Reddy, paragraphs [0060], [0126]-[0127]); utilizes a classifier algorithm to generate the plurality of system categories (again, using trained decision trees or classification trees, for classifying whether a software asset is trustworthy or untrustworthy, and categorizing into two different clusters) (Reddy, paragraph [0127]). Frederick and Reddy are analogous art because they deal with subject matter from the same problem solving area, namely, using blockchains and distributed ledgers to establish digital trust and provenance. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Frederick and Reddy before him or her, to modify the decentralized P2P system of Frederick to include the additional limitations of wherein the processor further: utilizes a training data which contains instances with known features and assigned system category; utilizes a telemetry system for system composition profile, performance metric and workload composition data to derive features; utilizes a classifier algorithm to generate the system categories, as disclosed in Reddy, with reasonable expectation that this would result in a system having the added benefit of implementing trust policies from the training sets, thereby providing additional trust and ensuring that the data was sound and reliable (See Reddy, paragraphs [0127]-[0128]). This method of improving the distributed ledger system of Frederick was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Reddy. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Frederick with Reddy to obtain the invention as specified in claim 1. In addition, it would have been obvious to one having ordinary skill in the art to include the additional limitations of wherein the processor further: utilizes a training data which contains instances with known features and assigned system category; utilizes a telemetry system for system composition profile, performance metric and workload composition data to derive features; utilizes a classifier algorithm to generate the system categories, as taught by Reddy into the decentralized P2P system of Frederick, since the operation of a utilizing a training data which contains instances with known features and assigned system category; utilizing a telemetry system for system composition profile, performance metric and workload composition data to derive features; and utilizing a classifier algorithm to generate the system categories is in no way dependent on the operation of the social media service computing platforms 450, 460, the property records computing platform 470, medical records computing platform 480, user computing device 490, and data feed aggregation server 495, and the data authentication and event execution computing platform 410 could be used to implement the limitations of utilizing of a training data which contains instances with known features and assigned system category; utilizing a telemetry system for system composition profile, performance metric and workload composition data to derive features; and utilizing a classifier algorithm to generate the system categories to achieve the predictable results of ensuring data from the social media platforms is reliable. KSR Int’l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41, 82 USPQ2d 1385, 1396 (2007)
Response to Argument
8. Applicant’s arguments, see pages 3-6, filed August 5, 2025, with respect to Objection to the Specification, have been fully considered but they are not persuasive.
(A) Applicant argues on pages 3-4, “The specification does not present the terms ‘Consensus by Conference Proof of Stake 3850’ or ‘Integrity is the Currency 3608’ as vague philosophical concepts, but rather as integral components of the disclosed invention. Specifically, Figure 38 (‘Consensus by Conference 3800’) labels ‘Consensus by Conference Proof of Stake 3850’ as a system component. Paragraph [000201] introduces Figure 38 and lists element 3850 alongside other clearly defined structural elements such as Machine Learning 3804, Classifier 3808, and Preconditions 3810. Thus, the terms are numbered features within the system’s architecture and not unmoored abstractions” (Recited from pages 3-4 of Remarks).
As to point (A), Examiner respectfully disagrees, noting to begin with, that “Integrity is the Currency 3608” is not even illustrated in FIG. 38 at all, nor is there any explanation of any kind of structural relationship between “Integrity is the Currency 3608” and “Machine Learning 3804,” “Classifier 3808,” and “Preconditions 3810”. Rather, as noted in the Final Office Action dated 02/05/2023, hereinafter “Final Rejection,” “Integrity is the Currency 3608” is merely a tenet, along with other “tenets” actually depicted in FIG. 36, and which has no structure. Moreover, as previously noted, the term “Integrity is the Currency 3608” is mentioned on only three occasions throughout instant Specification, once at paragraph [199000], once at paragraph [208000] and once at paragraph [230000]. None of the aforementioned paragraphs discuss any structural component or even a data structure. Rather, each of paragraphs [199000], [208000] and [230000] merely discuss the platform tenet “Integrity is the Currency 3608” in terms of its . In particular, paragraph [199000] merely enumerates all of the different platform tenets and recites that “This diagram details the main tenets of the platform that are essential to addressing the problems with existing social media options and delivering a transformed social media experience based on integrity, civility and fairness”. Paragraph [208000] merely indicates that “Consensus by Conference Proof of Stake 3850 is based on the platform tenet Integrity is the Currency 3608,” and paragraph [230000] merely states that “Publishers provide a valuable service to the platform and its tenet that Integrity is the Currency 3608”. None of the aforementioned paragraphs, however, provide any working detail as to how “Consensus by Conference Proof of Stake 3850” and “Integrity is the Currency 3608” interoperate to address the problems with existing social media options and delivering a transformed social media experience based on integrity, civility and fairness. The disclosure is abstract and conceptual, without any disclosed structural components afforded to the objected-to terms. With respect to the term “Consensus by Conference Proof of Stake 3850,” like “Integrity is the Currency 3608,” the term “Consensus by Conference Proof of Stake 3850,” is also only mentioned a total of three times, in three separate instances among the 104 page instant Specification. The first place appears at paragraph [201000], which merely references the term “Consensus by Conference Proof of Stake 3850,” in enumerating the other elements shown in FIG. 38. The second and third places appear at paragraph [208000], which as discussed above, merely states that “Consensus by Conference Proof of Stake 3850 is at the heart of Consensus by Conference 3800 and based on the platform tenet Integrity is the Currency 3608 in Figure 36” (Recited from paragraph [208000] of instant Specification). Paragraph [208000] goes on to recite, “A hash is a pure mathematical equation, and it is in every publisher’s best interest to do the calculation right. If they don't, it is reported in Conference Graph 2036 in Figure 20 which provides Complete Traceability 3602 and Complete Transparency 3604 within Permanent Public Record 3612 in Figure 36. Bad actors can be called out and held accountable, so there’s really no upside to being a notorious Publisher 3502 in Figure 35 on the network. This is why Consensus by Conference Proof of Stake 3850 works within a protected consensus requirement” (Recited from paragraph [208000] of instant Specification). Paragraph [209000] continues with, “In short, Consensus by Conference 3800 represents a really efficient, highly scalable, massively distributed communication protocol designed to bring integrity back to social media networking” (Recited from paragraph [209000] of instant Specification). However, as stated previously, Examiner can find no technical components that are structural, hardware, or even software-based, that implement functions of either “platform tenet Integrity is the Currency 3608” or “Consensus by Conference Proof of Stake 3850” or even what their technical functions are and how they are achieved. Paragraph [208000] also references hashing and that incorrect hashes are reported to the “Conference Graph 2036,” as well as reciting that the “Conference Graph 2036” provides “provides Complete Traceability 3602 and Complete Transparency 3604 within Permanent Public Record 3612 in Figure 36” (See again, paragraph [208000]). The foregoing sentence is equally unclear, however, as it is not understood whether or not the terms “Complete Traceability 3602” and “Complete Transparency 3604,” which are also disclosed as “platform tenets” are structural working hardware/software components, or abstract concepts similar to the “platform tenet Integrity is the Currency 3608” or “Consensus by Conference 3800” element “Consensus by Conference Proof of Stake 3850”. Based on the context of the disclosure and from reading the instant Specification, it would appear that the elements “Complete Traceability 3602” and “Complete Transparency 3604” are not structural components at all, but rather objectives to be achieved. In short, the disclosed “platform tenets” of FIG. 36, including “Integrity is the Currency 3608” as well as “Consensus by Conference Proof of Stake 3850” of FIG. 38 are not defined components of a technical solution, but are rather abstract concepts, stated objectives and principles.
(B) Applicant argues on page 4, “Paragraph [000208] explicitly explains the operative relationship between these components: ‘Consensus by Conference Proof of Stake 3850 is at the heart of Consensus by Conference 3800 and [is] based on the platform tenet Integrity is the Currency 3608.’ The paragraph goes on to describe that bad actors - publishers who do not compute hashes correctly - are publicly exposed through a Conference Graph (2036), which feeds into a Permanent Public Record (3612), delivering Complete Traceability (3602) and Complete Transparency (3604). This makes the tenet ‘Integrity is the Currency 3608’ functionally meaningful: user behavior impacts how they are perceived and trusted by the network. The use of cryptographic validation, ledger traceability, and transparency mechanisms clearly illustrates that these elements operate as enforceable parts of the system’s trust model - not as abstract concepts” (Recited from page 4 of Remarks).
As to point (B), Examiner respectfully disagrees. The statement, “This makes the tenet ‘Integrity is the Currency 3608’ functionally meaningful: user behavior impacts how they are perceived and trusted by the network” appears to suggest that the “platform tenet Integrity is the Currency 3608” is a structural component having the function of influencing how users are perceived throughout the network, and whether or not such users are trusted by the network, based on their behavior. However, Examiner respectfully submits, there is absolutely no disclosure to support the notion that “Integrity is the Currency 3608” has any function whatsoever. Again, as outlined above, the concepts “Consensus by Conference Proof of Stake 3850,” “Integrity is the Currency 3608,” “Complete Traceability (3602),” and “Complete Transparency (3604)” appear to be nothing more than abstract concepts (e.g., “Consensus by Conference Proof of Stake 3850”) , stated objectives (e.g., having complete traceability and having complete transparency) and principles (e.g., “Integrity is the Currency 3608”), without providing any working components. This is contrasted with the disclosed “Conference Graph (2036),” which at the very least is a data structure (i.e., a graph), having actual nodes and edges.
(C) Applicant argues on pages 4-5 of Remarks, “Additional portions of the specification further reinforce that the terms in question are tied to explicit architectural elements and operational mechanisms: “- Paragraph [000210] describes the Chronicle Record 2000 as the system’s ledger and explains how the Conference Graph 2036 records consensus events, including faulty or malicious behavior. This ensures accountability and immutable history for consensus actions. “- Paragraph [000163] details that the Chronicle Record 2000 includes a Record Hash and Record Signature, establishing cryptographic immutability for records and transactions - core components of maintaining system integrity. “- Paragraph [000181] explains that user participation in consensus affects their Reputation 2518 in the Directory Graph 2034. Reputation is used as a quantifiable enforcement of the principle that integrity matters - again, showing “Integrity is the Currency” operates through measurable outcomes. “- Paragraph [000221] describes how consensus results are confirmed by a coordinator and recorded in the ledger, thus reinforcing the role of Proof of Stake and the necessity of system- level accountability. “Together, these disclosures demonstrate that both “Consensus by Conference Proof of Stake 3850” and “Integrity is the Currency 3608” are implemented via explicit, algorithmic, and data- handling mechanisms. They are embedded into the system’s operation and cannot be reasonably dismissed as abstract or undefined” (Recited from pages 4-5 of Remarks).
As to point (C), Examiner respectfully disagrees, noting again, that the objections were made regarding the elements “Integrity is the Currency 3608” and “Consensus by Conference Proof of Stake 3850” and Examiner never took issue with either the “Chronicle Record 2000,” the “Conference Graph 2036,” “Directory Graph 2034,” “Record Hash” or even “Record Signature”. As above, Applicant outlines several concrete components and then provides a conclusory statement as to their functional relationships supporting the implementation of “Integrity is the Currency 3608” and “Consensus by Conference Proof of Stake 3850”. Examiner respectfully disagrees. While Specification does detail how user participation and overall behavior may affect their reputation, disclosing several features that play a role in establishing user trust (e.g., “Conference Graph 2036,” “Directory Graph 2034,” “Record Hash,” “Record Signature,” etc.), nevertheless, none of those features are disclosed as directly implementing (or even being related to) the “Integrity is the Currency 3608” and “Consensus by Conference Proof of Stake 3850,” and neither the “Integrity is the Currency 3608” or the “Consensus by Conference Proof of Stake 3850” are explicitly disclosed as playing an active role in establishing Applicant’s asserted “cryptographic immutability”. Examiner notes that the hashes, graphs and ledgers are completely separate components from the “Integrity is the Currency 3608” and the “Consensus by Conference Proof of Stake 3850,” neither of which are disclosed as comprising or being comprised of any graphs, hashes and/or ledgers, and the “Consensus by Conference Proof of Stake 3850” is not even part of the “Integrity is the Currency 3608” but is merely disclosed as being based thereon (See again, instant Specification, paragraph [208000]).
(D) Applicant argues on pages 5-6 of Remarks, “Applicant further notes that these terms and architectural components have appeared in one or more prior related applications, which were examined and allowed by the USPTO. In those cases, the Office found the disclosure sufficient to support claim allowance. It would be inconsistent to now assert that the same specification language is ‘incomprehensible’ under § 1.71 when it previously supported patentable subject matter without objection. “Applicant respectfully submits that the terms identified in the objection are supported by multiple, cross-referenced paragraphs in the specification; are linked to well-defined system structures; and are readily understandable to one of ordinary skill in the art. The specification clearly defines ‘Consensus by Conference Proof of Stake 3850’ as a core consensus enforcement mechanism and ‘Integrity is the Currency 3608’ as a measurable, functional platform tenet embedded into system operations. “Therefore, the objection under 37 CFR § 1.71 should be withdrawn. The Specification is and would be understood by one of ordinary skill in the art” (Recited from pages 5-6 of Remarks).
As to point (D), Examiner respectfully disagrees, and notes with particular interest that Applicant has given a mere conclusory statements that “the terms identified in the objection are supported by multiple, cross-referenced paragraphs in the specification; are linked to well-defined system structures; and are readily understandable to one of ordinary skill in the art. The specification clearly defines ‘Consensus by Conference Proof of Stake 3850’ as a core consensus enforcement mechanism and ‘Integrity is the Currency 3608’ as a measurable, functional platform tenet embedded into system operations,” without pointing to specifically where within the 104 page instant Specification, the “Integrity is the Currency 3608” and “Consensus by Conference Proof of Stake 3850” are disclosed structurally, functionally, and/or their implementation and use.
9. Applicant’s remarks, see pages 6-9, filed August 5, 2025, with respect to Applicant’s “Response to Patent Office’s BRI Analysis Regarding ‘Telemetry System’ and ‘Features’,” have been fully considered but they are moot, as 1.) neither any definiteness rejections have been issued, nor any formal arguments been submitted, but rather, on pages 6-9 of Remarks, Applicant provides explanation with regard to Applicant’s clarification of claim terms, and 2.), regardless of Applicant’s clarification, claim terms are nonetheless given their broadest reasonable interpretation, and apart from an explicit and deliberate definition in instant Specification and/or any disavowal of scope, (or interpretation under 35 U.S.C. 112(f)), are afforded their plain dictionary meaning as one of ordinary skill in the art would understand such claim terms, and limitations from the Specification are not to be read into the claims.
10. Applicant’s arguments, see pages 9-25, filed August 5, 2025, with respect to Rejection of Claim 1 under 35 U.S.C. 103, have been fully considered but they are not persuasive.
(A) Applicant argues on pages 10-12 of Remarks, “Applicant respectfully traverses the rejection of claim 1 under 35 U.S.C. § 103 as being unpatentable over Frederick et al. in view of Reddy et al. On this point, Applicant submits that Frederick does not disclose, teach, or suggest several critical elements of claim 1, including (1) a telemetry system for operational system metrics; (2) a mechanism to derive features from telemetry data; or (3) the use of a machine learning classifier to generate system categories” (Recited from page 10 of Remarks). “Claim 1 recites a ‘telemetry system for system composition profile, performance metric and workload composition data to derive features.’ Frederick, however, is directed to a data provenance system that aggregates various categories of user data (e.g., social, financial, and medical) into a blockchain to establish identity or trust (Frederick ¶ [0091]). There is no teaching in Frederick of any telemetry subsystem that monitors system performance or derives operational data from computing nodes or applications. Figures 2 and 4 in Frederick show full-node computing devices aggregating external user data, not internal software performance metrics or workloads (Frederick Figs. 2, 4; ¶ [0074]-[0075]). “Frederick does not address, even implicitly, the gathering or analysis of a system’s real-time operational configuration for use in a classification process. The type of telemetry described and required by claim 1 involves low-level metrics related to system behavior (e.g., system architecture, workload intensity, runtime behavior), which are completely absent in Frederick. “Because Frederick lacks a telemetry system as claimed, it necessarily follows that Frederick does not teach deriving features from telemetry data. While the Examiner refers to categorization in Frederick (e.g., distinguishing social media data from medical data), this is not equivalent to deriving features for classification purposes. Merely labeling the origin of data (e.g., ‘social’ vs. ‘financial’) is fundamentally different from deriving machine learning features based on performance or workload metrics (Frederick ¶ [0091]). “The derivation of features is central to claim 1’s novelty - Applicant’s system extracts telemetry-based attributes which serve as inputs to a classifier. Frederick performs no such transformation or feature engineering. The specification supports this approach in paragraph [000202], where ‘Conference Consensus Features 3806’ are derived from telemetry data managed by Telemetry System 226 (Spec ¶ [000202], Fig. 38)” (Recited from pages 10-11 of Remarks). “Claim 1 further recites a classifier algorithm that, using training data, maps features to system categories. Frederick does not disclose or suggest any classifier - machine learning-based or otherwise. It does not refer to training data, supervised learning, or categorization based on derived features. The only ‘categories’ in Frederick pertain to the types of user data stored in a blockchain, and there is no evidence that such categorization involves or could involve classification models (Frederick ¶ [0091]). “Indeed, the Examiner concedes that Frederick ‘does not explicitly disclose... utilizes a training data with known features and categories; utilizes a telemetry system... to derive features; [or] utilizes a classifier algorithm to generate the categories” (Office Action, p. 25). These three omissions strike directly at the heart of the claimed invention and confirm that Frederick, on its own, cannot render claim 1 obvious. “Frederick may describe a distributed data system that collects user data for blockchain storage and authentication, but it is fundamentally unrelated to the telemetry-driven classification architecture of claim 1. It lacks a telemetry subsystem, a feature derivation process, and a classification algorithm - all of which are critical to Applicant’s invention. At best, Frederick provides a general backdrop of a distributed system but does not teach or suggest any of the specific machine learning mechanisms and performance-based categorization required by claim 1. Applicant respectfully submits that Frederick, alone or in combination with Reddy, cannot render claim 1 obvious and that the rejection should be withdrawn” (Recited from pages 11-12 of Remarks).
As to point (A), Examiner respectfully submits that the arguments are moot, as Examiner never relied upon the reference to Frederick for disclosing the limitation of “telemetry system for system composition profile, performance metric and workload composition data to derive features,” but rather, relied upon the reference to Reddy for this limitation. With regard to Applicant’s general assertions that “[Frederick] is fundamentally unrelated to the telemetry-driven classification architecture of claim 1. It lacks a telemetry subsystem, a feature derivation process, and a classification algorithm - all of which are critical to Applicant’s invention,” and that “Frederick does not teach or suggest any of the specific machine learning mechanisms and performance-based categorization required by claim 1,” Examiner respectfully submits that 1.) as correctly pointed out by Applicant, Examiner never relied upon Frederick for disclosing the limitations of “wherein the processor further: utilizes a training data which contains instances with known features and assigned one system category among the plurality of system categories; utilizes a telemetry system for system composition profile, performance metric and workload composition data to derive features; utilizes a classifier algorithm to generate the plurality of system categories,” and so Examiner never relied upon Frederick alone for rendering claim 1 obvious, and 2.), Examiner notes that the features upon which applicant relies (i.e., a telemetry-driven classification architecture, machine learning mechanisms and performance-based categorization, a system’s real-time operational configuration for use in a classification process, low-level metrics related to system behavior (e.g., system architecture, workload intensity, runtime behavior, etc.) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim language of independent claim 1 says nothing to the effect of any low-level metrics related to system behavior (e.g., system architecture, workload intensity, runtime behavior, etc., or even performance-based categorization, much less machine learning mechanisms and telemetry-driven classification architectures. Indeed, the second limitation of independent claim 1 recites “utilizing a training data which contains instances with known features and assigned one system category among the plurality of system categories”. Apart from reading instant Specification, the above limitation is not inherently tied to machine learning, and “training data” in and of itself is broad. Claim 1 makes absolutely no mentioning of machine learning. As to the recited “telemetry system” at the third limitation, there is no indication that the “system composition profile,” “performance metric” and “workload composition data” relate to a system’s real-time operational configuration for use in a classification process, or even that they are low-level metrics related to system behavior (e.g., system architecture, workload intensity, runtime behavior, etc. Apart from “performance metric,” the terms “system composition profile” and “workload composition data” are overly broad enough that they encompass more than what Applicant alleges (low-level metrics related to system behavior, e.g., system architecture, workload intensity, runtime behavior, etc.). For instance, the “system composition profile” can include any type of “system composition” data (e.g., arrangement of parts, functional components, mapping data, etc., as claim 1 is silent regarding the “system composition profile” other than its use in deriving features, and is still silent regarding how it is used in deriving features). Likewise, the “workload composition data” is not necessarily limited to workload intensity but can also include a breakdown of different tasks and processes (i.e., not limited to intensity), including a mere breakdown of tasks and/or applications that constitute a software lifecycle or deployment pipeline. (As an aside, Examiner further notes that none of the elements from the foregoing discussion have anything to do with how user participation and overall behavior may affect their reputation, or of the several features that play a role in establishing user trust, as discussed above with regard to the Objections to Specification.) Finally, if a telemetry-driven classification architecture, machine learning mechanisms and performance-based categorization, a system’s real-time operational configuration for use in a classification process, low-level metrics related to system behavior (e.g., system architecture, workload intensity, runtime behavior, etc., are in fact critical features of the invention, then they should be present in the claim language.
(B) Applicant argues on pages 12-15 of Remarks, “Applicant respectfully traverses the assertion that Reddy et al. (US 2019/0303541 A1) supplies the features missing from Frederick et al. with respect to claim 1. While the Office Action describes Reddy as involving trustworthiness evaluations for software assets using machine learning, Applicant contends that Reddy does not teach or suggest the specific architecture and methods recited in claim 1, either individually or in combination with Frederick. Reddy discloses a machine learning framework in which labeled examples of software assets (e.g., deemed ‘trustworthy’ or ‘untrustworthy’) are used to train a model. The inputs to this model may include software lifecycle artifacts such as bug reports, vulnerability disclosures, and runtime performance monitoring data (Reddy ¶[0060], ¶[0127]). While this may conceptually resemble telemetry and classification, it diverges in material respects from the claimed invention” (Recited from pages 12-13 of Remarks). “Critically, Reddy does not disclose a structured telemetry system that processes ‘system composition profiles, performance metrics, and workload composition data’ in tandem to derive features for classification. Rather, Reddy generally references disparate sources of software artifacts in the development lifecycle (Reddy ¶[0057]-[0060]). The description lacks any cohesive telemetry pipeline that collects, aggregates, and transforms data into features suitable for a classifier. “By contrast, the invention in claim 1 contemplates a unified telemetry system that captures a holistic view of a computing system’s behavior - its structure, performance, and operational load - and derives features used in real-time classification. As disclosed in the Applicant’s specification (Spec [000202], Fig. 38), telemetry data such as system composition profiles and workload metrics are managed by a dedicated Telemetry System (226) and used to extract features (3806) for classification by the Conference Consensus Classifier (3808). Reddy lacks any comparable framework” (Recited from page 13 of Remarks). “Furthermore, while Reddy alludes to analyzing runtime logs and performance data, it does not provide any meaningful detail on how features are derived from these inputs. There is no disclosure of techniques for aggregating data across performance, composition, and workload dimensions to generate meaningful features for downstream classification (Reddy ¶[0127]). By contrast, the Applicant’s system extracts features that represent real-time operational characteristics of a social media publishing system. These may include, for example, how many requests a system handles, its resource configuration, or content production frequency - all of which inform the system category assignment, enabling fair scheduling and participation in consensus processes (Spec ¶[000205]). “Although Reddy does employ a machine learning classifier, its objective differs significantly from that of claim 1. Reddy’s classifier outputs a binary trustworthiness score or label for software assets - essentially labeling something as trustworthy or not (Reddy ¶[0127]). This is a narrow decision scope focused on evaluating individual software components. Claim 1, by contrast, involves generating a system category from a plurality of possible categories (not merely binary classification). The purpose of this classification is to support equitable consensus participation in a distributed platform. For instance, smaller social media publishers with limited system resources may be classified separately from large-scale publishers so that consensus demands are adjusted accordingly (Spec ¶[000205]). This ensures fairness and efficiency across a distributed network - something entirely absent from Reddy’s disclosure” (Recited from page 14 of Remarks). “Given these distinctions, Applicant respectfully submits that Reddy does not provide the missing elements necessary to support the rejection of claim 1. While it refers generally to machine learning and operational metrics, it does not disclose or suggest a telemetry-feature-classifier pipeline as required by the claim. Nor does it offer a framework for classifying entire systems based on workload and performance for the purpose of consensus scheduling. Importantly, nothing in Reddy suggests integrating its trust model into Frederick’s blockchain system - doing so would represent a significant conceptual and architectural leap, unsupported by either reference. Accordingly, Reddy, even in combination with Frederick, does not render claim 1 obvious. The rejection should therefore be reconsidered and withdrawn”.
As to point (B), Examiner respectfully disagrees. In response to Applicant’s remarks that the reference to Reddy fails to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a structured telemetry system that processes ‘system composition profiles, performance metrics, and workload composition data’ in tandem to derive features for classification, a cohesive telemetry pipeline that collects, aggregates, and transforms data into features suitable for a classifier, a unified telemetry system that captures a holistic view of a computing system’s behavior - its structure, performance, and operational load - and derives features used in real-time classification, system extracts features that represent real-time operational characteristics of a social media publishing system, which may include, for example, how many requests a system handles, its resource configuration, or content production frequency - all of which inform the system category assignment, enabling fair scheduling and participation in consensus processes) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim language of independent claim 1 is silent regarding a “structured telemetry system that processes ‘system composition profiles, performance metrics, and workload composition data’ in tandem to derive features for classification,” or even a “unified telemetry system that captures a holistic view of a computing system’s behavior - its structure, performance, and operational load - and derives features used in real-time classification”. Moreover, Examiner disagrees with Applicant’s assertion that Reddy fails to disclose, teach and/or suggest a cohesive telemetry pipeline that collects, aggregates, and transforms data into features suitable for a classifier, as that is not being claimed either. Indeed, the actually language of claim recites, (emphasis added), “utilizes a telemetry system for system composition profile, performance metric, and workload composition data to derive features”. There is absolutely no indication that the recited “telemetry system” performs processing of any kind. As noted in the Final Rejection, claim 1 fails to specify how each of the recited “system composition profile, performance metric, and workload composition data” or even how the recited “telemetry system” is being used to “derive features”. As further discussed in the Final Rejection, instant Specification is also silent in that regard. There is no flow chart, figure or algorithm in instant Specification that explains how the recited “features” are derived, (or even what they are - i.e., as of yet, the recited “features” are not limited to AI/ML features). As such, the limitation in question, as well as claim 1 as a whole amounts to no more than a mere intended result and intended use (i.e., utilizing a telemetry system for system composition profile, performance metric and workload composition data to derive features). Examiner once again points out that the “utilizing” limitation fails to actually recite that the recited “telemetry system” performs any processing of its own, or what derives the features, or how they are derived. However, Examiner respectfully submits that an intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. In this case, Reddy clearly discloses that trust criteria may specify parameters (i.e., derive the features thereof) of a trust model by which a trust score is calculated, and the trust policy may include a threshold trust score for which values below the trust score are determined to be not trustworthy and values above the trust score are determined to be trustworthy (or the relationship may be reversed for scoring systems in which lower values indicate greater trust). Reddy teaches that in some embodiments, the parameters may be adjustable parameters of a machine learning model trained on labeled historical examples of trustworthy and untrustworthy software assets, for instance, by iteratively adjusting the model parameters to reduce an amount of error between predictions of the model and labeled trustworthiness determinations on the training set (See again, Reddy, at paragraph [0127]). As well, Reddy teaches that a given organization may interface with hundreds or thousands of software assets at various different stages of a software lifecycle like that shown in FIG. 2 (suggesting workload composition data), and those software assets may be composed of relatively complex arrangements of constituent software assets (each of which may constitute a whole/composition profile) (See again, Reddy, paragraph [0062]). Examiner respectfully submits that the language is exceedingly broad and still reads on the teachings of Reddy. As to Applicant’s assertions that “Reddy’s classifier outputs a binary trustworthiness score or label for software assets - essentially labeling something as trustworthy or not (Reddy ¶[0127]),” and that “this is a narrow decision scope focused on evaluating individual software components. Claim 1, by contrast, involves generating a system category from a plurality of possible categories (not merely binary classification). The purpose of this classification is to support equitable consensus participation in a distributed platform. For instance, smaller social media publishers with limited system resources may be classified separately from large-scale publishers so that consensus demands are adjusted accordingly,” Examiner respectfully submits that 1.) even though Applicant may be correct that the classifier of Reddy outputs a binary trustworthiness score or label for software assets, this nevertheless, still reads on “assigned one category among the plurality of system categories”. Examiner respectfully submits that assigning either trustworthy or not from a possibility of either, is how Examiner reads assigning a category from among two, which is a plurality (i.e., binary requires at least two, which is a plurality), and more importantly, 2.) Applicant is again arguing against unclaimed features (i.e., the purpose of the classification is to support equitable consensus participation in a distributed platform, e.g., smaller social media publishers with limited system resources may be classified separately from large-scale publishers so that consensus demands are adjusted accordingly), as well as highlighting an intended result (i.e., again, to support equitable consensus participation in a distributed platform). Examiner once again, kindly reminds Applicant that although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Therefore, Examiner respectfully submits, the combination of Frederick-Reddy does disclose, teach and/or suggest each and every limitation of independent claim 1.
(C) Applicant argues on pages 15-19 of Remarks, “Even if, arguendo, one accepts that Frederick and Reddy each disclose different portions of the subject matter of claim 1 (a position which Applicant does not concede), the rejection still fails because it lacks the legally required rationale to justify combining them. Applicant respectfully asserts that the Examiner’s proffered reason for combination is conclusory and inadequate under controlling law, including the Supreme Court’s decision in KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), and the standards outlined in MPEP § 2143.01. In the Final Office Action, the Examiner states that it would have been obvious to modify Frederick’s decentralized P2P system with the features taught by Reddy, allegedly ‘with reasonable expectation that this would result in a system having the added benefit of implementing trust policies from the training sets, thereby providing additional trust and ensuring that the data was sound and reliable” (Office Action, p. 26). This generalized assertion fails to meet the legal threshold required for an obviousness rationale (Recited from page 15 of Remarks). “The Office Action fails to identify any concrete teaching in Frederick that points to the need for, or compatibility with, a machine learning-based telemetry system. Nor does it cite any teaching in Reddy that suggests its trust-scoring approach is applicable to Frederick’s blockchain-based identity and data provenance framework. A proper combination rationale under KSR requires more than thematic overlap - it must include a logical bridge grounded in the references themselves. “Here, the Office Action essentially argues that because both systems deal with “trust,” one would have been motivated to combine them. But this reasoning is overly simplistic. Frederick already addresses trust - specifically, trust achieved through consensus and verifiable recordkeeping via distributed ledger technology (Frederick ¶[0091]). The Examiner has not identified any deficiency in Frederick’s trust mechanism that would compel a skilled artisan to augment it with Reddy’s ML-based trust scoring of software artifacts. Nor has it explained why Reddy would suggest or be suitable for deployment in a blockchain network such as that disclosed in Frederick. “As articulated by the Supreme Court in KSR, examiners must provide ‘an articulated reasoning with some rational underpinning to support the legal conclusion of obviousness.’ Merely asserting that a combination would yield some general benefit (e.g., ‘additional trust’’ does not satisfy this requirement. MPEP § 2143.01 further emphasizes that a rejection must include ‘some rationale underpinning the combination.’” (Recited from page 16 of Remarks). “Here, the Office Action merely states that combining Frederick and Reddy would lead to ‘a system having the added benefit’ of enhanced trust (Office Action, p. 26). This does not explain why one of ordinary skill would actually be motivated to pursue such a combination in the first place. It simply posits a benefit and retroactively justifies the merger of two unrelated systems - precisely the kind of hindsight-based logic KSR and the MPEP caution against. “The Office Action does not articulate how the combination would be technically implemented. Frederick’s system is based on full-node computing devices that participate in blockchain consensus to valid