DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on XXXXXXXXXXXXXX has been entered.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 15-20 are canceled by Applicant.
Claims 1-14 and 21-26 are pending and have been examined.
This action is in reply to the papers filed on 07/17/2026 (effective filing date 02/12/2021).
Information Disclosure Statement
The information disclosure statement(s) submitted: 06/17/2026, has/have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on 10/07/2024 as modified by the amendment filed on 07/17/2026.
Terminal Disclaimer
The terminal disclaimer filed on 07/17/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. No. 12,112,297 has been reviewed and has been placed in the file.
Double Patenting - Withdrawn
The double patenting rejection is withdrawn per the filed terminal disclaimer noted above.
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims 1-14 and 21-26 are allowable over the prior-art – subject to the pending 35 USC 101 subject matter ineligibility rejection herein. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed: Claim 1. (Currently Amended) A method, comprising: receiving first data from a development ecosystem, wherein the development ecosystem corresponds to a first system used to develop a technology product; receiving second data from a non-development ecosystem, wherein the non-development ecosystem corresponds to a second system corresponding to end-use of the technology product; generating a combined set of data from both the first data from the development ecosystem and the second data from the non-development ecosystem; performing machine-learning (ML) on the combined set of data from both the development ecosystem and the non-development ecosystem; and funneling results from performing ML-based analysis into multiple levels of funneled data objects, wherein a plurality of levels of funneling are applied such that each level of funneling takes in a set of data and generates an increasingly smaller set of data at the each level of the funneling, where the plurality of levels of funneling are implemented with machine learning clustering that performs aggregation in a unified manner across both the first data from the development ecosystem and the second data from the non-development ecosystem based upon an object commonality between the first data from the development ecosystem and the second data from the non-development ecosystem.
The closest prior-art (Toyoshima et al. 2005/0187737, Bui et al. 2021/0200760, Sarferaz 2021/0342738, Zhou et al. 2020/0374696, Duncan et al. 2017/0220943, Natarajan et al. 2020/0174774, White et al. 2020/0126117, Sachan et al. 2020/0293946, Venkataraman et al. US 10,459,951) teach the features as disclosed in Non-final Rejection (03/17/2026), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
Claim 1. (Currently Amended) A method, comprising: … funneling results from performing ML-based analysis into multiple levels of funneled data objects, wherein a plurality of levels of funneling are applied such that each level of funneling takes in a set of data and generates an increasingly smaller set of data at the each level of the funneling, where the plurality of levels of funneling are implemented with machine learning clustering that performs aggregation in a unified manner across both the first data from the development ecosystem and the second data from the non-development ecosystem based upon an object commonality between the first data from the development ecosystem and the second data from the non-development ecosystem.
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
Claim Rejections - 35 USC § 101 – electromagnetic signals per se
Per Applicants’ amendments/arguments, this rejection is withdrawn.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–14 and 21–26 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
The claims are analyzed under the Alice/Mayo two-step framework as set forth in Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208 (2014) and Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66 (2012), and as implemented in MPEP §§ 2103–2106.07(c) (9th ed., Rev. 01.2024), including the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) and the July 2024 Guidance Update on Patent Subject Matter Eligibility, Including on Artificial Intelligence (2024 AI-SME Update).
Step 1 — Statutory Category
Claim 1 recites ‘[a] method, comprising:…’ a series of steps and is therefore a process; Step 1: Yes.
Claim 8 recites a "non-transitory computer program product embodied on a computer readable medium" and is therefore a manufacture; Step 1: Yes. (See discussion below regarding the "non-transitory" recitation and 35 U.S.C. § 101 signal-per-se considerations.)
Claim 21 recites "a processor" and "a memory" and is therefore a machine; Step 1: Yes.
Because all claims fall within a statutory category, the analysis proceeds to Step 2A.
Step 2A, Prong One — Does the Claim Recite a Judicial Exception?
Independent claims 1, 8, and 21 recite substantially identical limitations and are addressed together.
The claims recite the steps of:
"receiving first data from a development ecosystem";
"receiving second data from a non-development ecosystem";
"generating a combined set of data from both the first data ... and the second data";
"performing machine-learning (ML) on the combined set of data"; and
"funneling results from performing ML-based analysis into multiple levels of funneled data objects, wherein a plurality of levels of funneling are applied such that each level of funneling takes in a set of data and generates an increasingly smaller set of data ... where the plurality of levels of funneling are implemented with machine learning clustering that performs aggregation in a unified manner ... based upon an object commonality."
Under their broadest reasonable interpretation, these limitations recite concepts that fall into the "mental processes" grouping and the "mathematical concepts" grouping of abstract ideas identified in MPEP § 2106.04(a).
Mental processes. Receiving data, combining data sets, and organizing/categorizing that data into a smaller, more refined set based on a shared "object commonality" are observations, evaluations, and judgments that (apart from generic data-gathering and generic computer implementation) can practically be performed in the human mind or with the aid of pen and paper. A human analyst reviewing records from a development system (e.g., bug reports) and an end-use system (e.g., support tickets) could mentally identify which records share a common subject, group ("funnel") them into successively narrower categories, and note commonality among them. See CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366 (Fed. Cir. 2011); MPEP § 2106.04(a)(2)(III).
Mathematical concepts. "Machine learning clustering that performs aggregation ... based upon an object commonality" recites, at the level of generality claimed, a mathematical algorithm for grouping data points by similarity (i.e., a clustering algorithm). Clustering, correlation, and aggregation of data are mathematical operations, and the claim does not recite any specific mathematical formula, model architecture, or algorithmic technique beyond the result to be achieved ("increasingly smaller set of data" via "commonality"). See MPEP § 2106.04(a)(2)(I); SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161 (Fed. Cir. 2018) (claims to selecting, analyzing, and manipulating data through mathematical/statistical techniques are directed to an abstract idea); Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016) (collecting, analyzing, and displaying/organizing data is abstract).
Because the claims recite limitations that fall within the mental processes and mathematical concepts groupings, and those limitations are not integrated into a practical application (addressed below), the claims recite an abstract idea. Step 2A, Prong One: Yes.
Step 2A, Prong Two — Integration into a Practical Application
The additional elements recited beyond the abstract idea are: a "development ecosystem," a "non-development ecosystem," a "united analysis platform," an "ML processor" (claims 2, 9, 22), a "processor" and "memory" (claim 21), and a "non-transitory computer readable medium" (claim 8).
These additional elements are recited at a high level of generality and amount to no more than (i) generic computer components used to receive, store, and transmit data, and (ii) instructions to implement the abstract idea using generic machine learning on a generic computer platform. See MPEP § 2106.05(f) ("apply it" / mere instructions to implement an abstract idea on a computer). The claims do not recite:
any particular clustering algorithm, model architecture, distance/similarity metric, or training methodology;
any technical explanation of how "object commonality" is computed across heterogeneous data types from disparate ecosystems; or
any improvement to the functioning of the computer itself or to another technology or technical field (contrast with Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) (self-referential database structure) and McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299 (Fed. Cir. 2016) (specific rules improving computer animation)).
Rather, the claims are result-oriented: they recite the desired outcome ("an increasingly smaller set of data at ... each level") without reciting the specific means by which a computer achieves that outcome beyond generic "machine learning" and "clustering," applied as a tool. See MPEP § 2106.04(d)(1) (examiners should assess whether the claim reflects a concrete technical improvement, not merely an improved abstract idea implemented generically). The mere combination of data from two (or, per claim 5, four) sources and application of generic ML thereto is not, without more, a technical improvement; it is automation of a data-analysis task using a generic tool. See In re TLI Commc'ns LLC Patent Litig., 823 F.3d 607 (Fed. Cir. 2016); Content Extraction & Transmission LLC v. Wells Fargo Bank, N.A., 776 F.3d 1343 (Fed. Cir. 2014).
Accordingly, the additional elements, considered individually and as an ordered combination, do not integrate the judicial exception into a practical application. Step 2A, Prong Two: No — the claims are directed to an abstract idea.
Step 2B — Inventive Concept ("Significantly More")
The additional elements — a "development ecosystem," "non-development ecosystem," "united analysis platform," "ML processor," generic "processor," "memory," and "non-transitory computer readable medium" — are described in the claims only in terms of their generic functions (receiving data, storing data, executing instructions, performing machine learning). Receiving/transmitting data over a network or between systems and storing data in a database are well-understood, routine, and conventional functions of generic computer components when claimed generically. See MPEP § 2106.05(d); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350 (Fed. Cir. 2014); OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359 (Fed. Cir. 2015); Two-Way Media Ltd. v. Comcast Cable Commc'ns, LLC, 874 F.3d 1329 (Fed. Cir. 2017) (collecting, analyzing, and generating/funneling data through generic components is not an inventive concept); BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281 (Fed. Cir. 2018) (narrowing/organizing data does not supply an inventive concept). Applying a generic "ML processor" to perform generic "machine learning clustering" is the abstract idea itself, not an additional inventive element. See MPEP § 2106.05(f).
Considered as an ordered combination, the elements add nothing beyond what is already present when considered separately — the claims simply automate data aggregation and categorization using off-the-shelf machine learning on a general-purpose computing platform. There is no indication of record (e.g., in the specification) that the specific combination itself was unconventional at the time of filing such that it would satisfy the Berkheimer factual inquiry (Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018)); Applicant is invited to point to specification support demonstrating that the ordered combination was not well-understood, routine, and conventional, if such support exists.
Step 2B: No — the claims do not recite significantly more than the abstract idea.
Conclusion: Independent claims 1, 8, and 21 are not patent-eligible and are rejected under 35 U.S.C. § 101.
Dependent Claims
Claims 2, 9, 22 (united analysis platform / ML processor performing the machine learning) merely recite that the previously-generic "development ecosystem" and "non-development ecosystem" data are provided to a "united analysis platform" with a resident "ML processor." This adds only a generic computing platform performing the same abstract data-aggregation/clustering functions and does not integrate the abstract idea into a practical application or provide an inventive concept. Rejected under § 101 for the reasons set forth above.
Claims 3, 10, 23 (automatic processing to generate a database of raw and categorized data, with correlation performed against both) recite additional data organization and correlation — further mental-process/mathematical-concept limitations (correlating records is itself an abstract data-comparison operation) implemented generically via "automatic processing." Rejected under § 101.
Claims 4, 11, 24 (event hierarchies with differing "stages of funneling") further characterize the abstract data-categorization scheme without adding any technical implementation detail. Rejected under § 101.
Claims 5, 12 (adding third data from a "user ecosystem" and fourth data from a "customer relations ecosystem") merely broaden the abstract idea to additional generic data sources. Mere data gathering from additional sources is insignificant extra-solution activity under MPEP § 2106.05(g); see In re Bilski, 545 F.3d 943, 963 (Fed. Cir. 2008) (en banc), aff'd on other grounds, Bilski v. Kappos, 561 U.S. 593 (2010). Rejected under § 101.
Claims 6, 13, 25 (analyzing events to identify an "incident," and the incident to identify a "ticket" assigned "within a software organization") recite a further mental process / certain-methods-of-organizing-human-activity limitation (i.e., managing personal behavior or relationships or interactions between people, including managing business/organizational task assignment). See MPEP § 2106.04(a)(2)(II). This is a quintessential abstract business/organizational practice (assigning work tickets) automated on generic computer components. Rejected under § 101.
Claims 7, 14, 26 (ticket creation "based upon clustering of multiple incidents") again recites a mathematical/mental-process clustering operation without additional technical implementation. Rejected under § 101.
Additional 35 U.S.C. § 101 Considerations — Transitory Signal
Claim 8 recites a "non-transitory computer program product embodied on a computer readable medium." Because claim 8 expressly and unambiguously limits the claimed medium to a non-transitory computer-readable medium, the claim, on its face, is not reasonably subject to a broadest-reasonable-interpretation reading that would encompass a transitory propagating signal. See MPEP § 2106.03; In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007) (a transitory, propagating signal is not a "manufacture" and therefore not statutory subject matter). Accordingly, claim 8 as currently amended is not rejected on transitory-signal / "signal per se" grounds.
Examiner notes for completeness, however, that this conclusion depends on the specification providing a definition of "computer readable medium" that is consistent with, and does not broaden, the "non-transitory" claim language (e.g., the specification should not define "computer readable medium" to include carrier waves or transmission media). If the specification's definition of "computer readable medium" is broader than or inconsistent with a non-transitory medium, the claim term should be construed in light of the specification and may still raise an eligibility issue notwithstanding the "non-transitory" preamble language. Applicant should confirm consistency between the claim language and specification definition.
Claims 1–7 and 21–26 do not recite any computer-readable-medium or signal language and are not implicated by this issue; the “software per se” concern is instead addressed via the mathematical-concepts/mental-processes abstract-idea rejection above, as the claims as drafted are functionally results-oriented and not limited to any particular technical implementation.
Claim Rejections – 35 U.S.C. § 112(b)
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.
Claims 1, 8, and 21 (and their dependents) are rejected under 35 U.S.C. § 112(b) as indefinite for failing to particularly point out and distinctly claim the subject matter regarded as the invention.
"ML-based analysis" lacks antecedent basis. The claims recite "performing machine-learning (ML) on the combined set of data" and then, in the following clause, recite "funneling results from performing ML-based analysis." It is unclear whether "ML-based analysis" refers back to the previously recited "machine-learning (ML)" step, or is intended to introduce a separate, unclaimed analysis step. For purposes of examination, "ML-based analysis" is being interpreted as referring to the previously recited "performing machine-learning (ML)" step; Applicant should amend to use consistent terminology (e.g., "results from performing the ML" or "results from the machine-learning") to resolve the antecedent-basis ambiguity. See MPEP § 2173.05(e).
"at the each level of the funneling" is grammatically indefinite. The phrase "generates an increasingly smaller set of data at the each level of the funneling" contains a grammatical error ("the each level") that renders the metes and bounds of the limitation unclear. It is unclear whether this is intended to mean "at each level" or "at each of the levels." Clarification/correction is required.
Claims 6, 13, and 25 — "events" lacks antecedent basis. These claims (depending from claims 1, 8, and 21, respectively — none of which recite "events") recite "wherein events from the combined set of data are analyzed to identify an incident." There is insufficient antecedent basis for "events," and it is unclear whether "events" refers to the previously recited "data," a subset thereof, or a new, unclaimed data type. (Note: "event hierarchies" is recited only in claims 4, 11, and 24, which are not in the claim 6/13/25 dependency chain.) Clarification is required.
"where" clauses used as run-on limitations. Independent claims 1, 8, and 21 each present a single "wherein ... where ..." compound clause chaining multiple limitations (the funneling limitation, followed by "where the plurality of levels of funneling are implemented with machine learning clustering ... based upon an object commonality"). The use of "where" following "wherein" without clear demarcation makes it difficult to determine whether "where" introduces a further limitation on "funneling," on "clustering," or is an independent claim requirement. Applicant is encouraged to reformat these limitations into clearly delineated clauses (e.g., separate "wherein" clauses or a step-formatted list) to improve clarity.
"object commonality" is not defined and is a relative/subjective term. It is unclear what degree or type of "commonality" between "objects" is required to satisfy this limitation, and the claims do not identify what an "object" is in this context (e.g., a data object, a record, a field). Absent a standard for assessing "commonality," a person of ordinary skill in the art cannot determine the scope of the claim with reasonable certainty. See Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898 (2014); MPEP § 2173.05(b).
Claim Rejections – 35 U.S.C. § 112(a) — Written Description
The following is a quotation of 35 U.S.C. §112(a):
IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1–14 and 21–26 are rejected under 35 U.S.C. § 112(a) because the specification, as it would appear based on the claim language alone, fails to demonstrate that Applicant had possession of the full scope of the claimed invention at the time of filing.
The claims recite highly result-oriented, functional language — e.g., "machine learning clustering that performs aggregation in a unified manner ... based upon an object commonality," and "generates an increasingly smaller set of data at [each] level of the funneling" — without reciting the specific algorithm, model, or technique used to achieve these results across heterogeneous data originating from structurally different sources (a "development ecosystem" versus a "non-development ecosystem," and, per claim 5, also "user" and "customer relations" ecosystems). Where a claim covers a genus of ways of achieving a functional result (here, any clustering/aggregation technique capable of unifying disparate data types by "commonality"), written description support requires disclosure of either a representative number of species within the genus or structural/algorithmic features common to the genus that would allow one skilled in the art to recognize members of the genus. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336 (Fed. Cir. 2010) (en banc); Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671 (Fed. Cir. 2015) (claims requiring "unifying" or synchronizing heterogeneous, differently-structured databases require written description support for how that unification is technically accomplished, not merely a statement that it is achieved). To the extent the specification discloses only a single embodiment or discloses the "unified manner" aggregation and "object commonality" determination only in purely functional terms (i.e., by restating the claim language), the claims are not adequately supported.
Examiner further notes that claim 4's recitation that "the first event hierarchy has different stages compared to the second event hierarchy" is a structural/comparative limitation that should be supported by specific disclosure of what those differing stages are for each ecosystem; if the specification discloses this only generically, written description support should be reassessed.
This is a rejection based on the claim language considered on its face; upon full review of the specification, Examiner will confirm whether adequate corresponding written description exists and may withdraw this rejection in whole or in part accordingly. Applicant's response should identify by page and line number where the specification supports the "unified manner" clustering/aggregation across the recited disparate ecosystems and the "object commonality" determination.
Claim Rejections – 35 U.S.C. § 112(f) — Means-(or Step-)Plus-Function Considerations
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claim 21 recites "a memory for holding programmable code" and "the programmable code includes instructions for: receiving ..., generating ..., performing ..., and funneling ...." This is a "nonce"-type, function-only recitation similar in kind to "means for" claiming addressed in Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015) (en banc), in that "instructions for [performing a function]," standing alone, does not recite any structure, material, or acts for performing the recited functions — it recites only the functions themselves ("receiving," "generating," "performing," "funneling") to be carried out by unspecified "programmable code."
While the term "instructions for" does not use the word "means" and therefore does not trigger the statutory presumption of 35 U.S.C. § 112(f), Examiner notes that if, upon further consideration, "instructions for" is treated as a substitute term invoking § 112(f) (because it recites function without reciting sufficiently definite structure to a person of ordinary skill in the art), the corresponding structure must be limited to the specific algorithm(s) disclosed in the specification for performing each function (particularly the "funneling"/clustering function), per Aristocrat Techs. Australia Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328 (Fed. Cir. 2008). If the specification fails to disclose a corresponding algorithm for the recited "funneling" and "machine learning clustering" functions, the claim would additionally be indefinite under 35 U.S.C. § 112(b) for failure to disclose adequate corresponding structure. Applicant should clarify whether "programmable code" and "instructions for" are intended to invoke § 112(f) and, if not, should amend to recite sufficiently definite structure (e.g., naming a specific processor configuration or non-generic component) to avoid this construction.
Examiner’s Response to Arguments
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Regarding Claims 1-14 and 21-26, page(s) 9-14 of Applicant’s Remarks (dated 07/17/2026), Applicants traverse the 35 USC §101 rejections. Applicant's arguments have been fully considered but are not persuasive.
1. Applicant's Argument That the Claims Recite "the Architecture by Which the Computer Processes Heterogeneous Technical Information"
Applicant argues that the amended limitations — unifying data from two ecosystems, clustering based on "object commonality," and progressively reducing data through funnel levels — define a specific technological processing architecture rather than a mere abstract concept, citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016).
This argument is not persuasive because it is not commensurate with the actual scope of the claim language. The claims do not recite how the "machine learning clustering" achieves "aggregation in a unified manner ... based upon an object commonality" — they recite only the desired result of that clustering (a progressively smaller set of data objects). No particular clustering algorithm (e.g., k-means, hierarchical, density-based), similarity/distance metric, feature representation, or data structure is recited. "Object commonality" is itself undefined in the claim and is not tied to any specific technical criterion. Under MPEP § 2106.04(d)(1), a claim reciting only a desired outcome, without reciting the particular technical means for achieving it, does not integrate an abstract idea into a practical application, regardless of how the outcome is characterized in the Remarks. See Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016) ("[M]erely selecting information, by content or source, for collection, analysis, and display does nothing significant to differentiate a process from ordinary mental processes...."); SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1167 (Fed. Cir. 2018) ("[A] claim for a new abstract idea is still an abstract idea.").
Enfish is distinguishable. The claims at issue in Enfish recited a specific, structurally-defined self-referential logical table — a particular database architecture with defined characteristics (e.g., all entity types stored in a single table, with column definitions provided by rows) that Applicant demonstrated to concretely improve how the computer stored and retrieved data. 822 F.3d at 1330–33, 1339. The claims here recite no analogous data-structure limitation; they instead describe, at a functional level, that clustering occurs and that each successive level produces a smaller data set. That is a result, not a structural or algorithmic improvement of the kind found dispositive in Enfish. The Federal Circuit's admonition against evaluating claims "at such a high level of abstraction" cuts against Applicant here, not for the Office: the Office's characterization tracks the actual limitations recited, whereas Applicant's characterization imports technical specificity ("architecture," "processing mechanism") that does not appear in the claim language itself.
2. Applicant's Reliance on McRO and Finjan
Applicant argues that, as in McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016), and Finjan, Inc. v. Blue Coat Systems, Inc., 879 F.3d 1299 (Fed. Cir. 2018), the claims recite a specific technical mechanism rather than an abstract result.
This argument is not persuasive. In McRO, the claims recited a specific set of rules — including particular timing relationships based on phoneme sequences and morph weight sets — that were expressly set forth in the claim and that replaced subjective, manual animator judgments with an automated process governed by those specific rules. 837 F.3d at 1313–15. In Finjan, the claims recited generating a specific new file — a "security profile" that identifies suspicious code operations — a defined data construct enabling a specific new mode of malware detection (behavior-based rather than code-matching) that was recited with particularity in the claims. 879 F.3d at 1304–05.
By contrast, the instant claims recite no comparable rule set or defined data construct. They recite only that "machine learning clustering" is used to achieve aggregation "based upon an object commonality" — a functional, black-box description of an outcome, not a recitation of specific rules or a specifically-defined new data structure analogous to the security profile in Finjan or the morph-weight timing rules in McRO. Absent comparable claim specificity, McRO and Finjan do not control.
3. Applicant's Argument Regarding Reduced Computational Burden
Applicant argues that the funnel architecture reduces the computational burden of downstream processing by operating on progressively smaller data sets, and that this constitutes an improvement in the operation of the computer itself.
This argument is not persuasive because it is not commensurate with the scope of the claims. The claims do not recite any reduction in computational burden, processing time, memory usage, or any other technical performance metric; they recite only that each funnel level "generates an increasingly smaller set of data." A reduction in the quantity of information selected for further review is the expected and inherent result of any filtering or categorization scheme — mental or computerized — and is not itself evidence of a technical improvement to the computer's operation. See MPEP § 2145(I) (arguments that are not based on limitations appearing in the claims are not persuasive); In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1368 (Fed. Cir. 2004). To the extent Applicant relies on unclaimed benefits described only in the Remarks, such benefits cannot supply eligibility unless recited in the claims themselves. Two-Way Media Ltd. v. Comcast Cable Commc'ns, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (unclaimed features cannot establish eligibility).
4. Applicant's Reliance on Ex parte Desjardins and MPEP § 2106.05(a)
Applicant argues that under the precedential Appeals Review Panel decision in Ex parte Desjardins, Appeal No. 2024-000567 (PTAB Sept. 26, 2025), and MPEP § 2106.05(a) as updated, the claims fall within the category of claims that recite a technological mechanism for an AI/ML improvement, rather than claims that merely invoke machine learning as a desired analytical tool.
This argument is not persuasive because Desjardins is factually and legally distinguishable. The claims at issue in Desjardins recited a specific algorithmic training mechanism — namely, selective adjustment of particular model parameters during training on a second task so as to preserve the model's performance on a first, previously-learned task (i.e., a specifically claimed technique for mitigating catastrophic forgetting during sequential model training). The ARP found that this specific parameter-adjustment mechanism was itself a claimed technical solution to a technical problem in how the model is trained — not merely an invocation of "training" as a label for an unspecified process.
The instant claims contain no analogous recitation. They do not claim any particular adjustment to model parameters, training procedure, loss function, or internal model architecture; they instead apply "machine learning clustering" as a generic analytical tool to reduce the volume of aggregated data from two (or more) sources. This is precisely the category of claim that Desjardins and MPEP § 2106.05(a) distinguish from eligible claims — one that "merely invoke[s] machine learning as a desired analytical tool" rather than one that "define[s] a specific technological implementation." Applicant's Remarks assert the latter characterization but do not identify any claim language reciting a specific technological implementation comparable to the parameter-adjustment mechanism in Desjardins. Absent such a recitation, Desjardins supports the rejection rather than overcoming it.
5. Applicant's Step 2B Argument Under BASCOM
Applicant argues that, even if the claims are directed to an abstract idea, the ordered combination of unifying heterogeneous datasets, clustering across ecosystems, and implementing successive funnel levels supplies an inventive concept under BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016), and that the Office Action has not identified evidence that this combination was conventional.
This argument is not persuasive for two reasons.
First, the inventive concept found in BASCOM rested on a specific, concretely-claimed technical arrangement — installation of a customizable content-filtering tool at a specific location in the network (a remote ISP server) rather than at the local client or a remote server on the Internet — that the court found provided a non-conventional and non-generic arrangement of otherwise-conventional components, yielding a specific technical benefit (filtering customized to individual network accounts while retaining the benefits of a remote server). 827 F.3d at 1350. No comparably specific arrangement is recited in the instant claims. The claims recite only that data from generic "ecosystems" is provided to a generic "united analysis platform" with a generic "ML processor" that performs generic "clustering" — i.e., the same generic, off-the-shelf computer components arranged in the conventional manner one would expect for any data-analysis task (receive data, aggregate data, analyze data, output a reduced result). This is materially different from the specific, claimed network-topology arrangement in BASCOM.
Second, Applicant's assertion that the Office has not established that the claimed combination was conventional does not shift the evidentiary burden in the manner suggested. Under Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018), the well-understood, routine, conventional nature of an additional element is a question that can be resolved by citation to controlling case law recognizing the routine nature of the functions at issue, without need for further factual evidence, where (as here) the functions in question — receiving/transmitting data between systems, storing data in a database, and applying an off-the-shelf machine-learning technique to reduce a data set — have been repeatedly found routine and conventional as claimed at this level of generality. See buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014); OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); Two-Way Media, 874 F.3d at 1339; TLI Commc'ns, 823 F.3d at 611. Applicant has not identified, in the specification, any disclosure indicating that the specific combination of generic data-collection and generic clustering was unconventional at the time of filing, and the Remarks do not point to any such disclosure. Accordingly, the record does not support a Step 2B inventive concept.
Conclusion – 35 U.S.C. § 101
For the foregoing reasons, Applicant's arguments have been fully considered but are not persuasive, and the rejection of claims 1–14 and 21–26 under 35 U.S.C. § 101 is maintained.
Should Applicant wish to pursue eligibility further, the rejection could potentially be overcome by claim amendments that recite the specific technical mechanism by which the claimed clustering/aggregation is performed (e.g., a particular algorithm, feature representation, distance/similarity computation, or model architecture) and that tie any alleged technical benefit (e.g., reduced computational burden, improved processing throughput, reduced memory footprint) directly to recited claim limitations, consistent with the level of specificity found dispositive in Enfish, McRO, Finjan, and Ex parte Desjardins.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
Venkataraman et al. US 10,459,951: Abstract - The present disclosure relates to a method and system for determining automation sequences for resolution of an incident ticket by an automation system. The automation system retrieves data associated with plurality of incident tickets received from a ticketing system during predefined time duration and groups the plurality of incident tickets into one or more clusters based on the data. The automation system receives a plurality of user actions associated with the plurality of incident tickets performed across a plurality of user devices and identifies similarity among sequences of the plurality of user actions for each ticket cluster. Based on the similarity, the automation system groups the sequences of the plurality of user actions into one or more bucket and determines automation sequences for resolution of the incident ticket by correlating the data associated with plurality of incident tickets with one or more buckets of the sequences.
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
E. F. Coutinho, I. Santos and C. I. Moreira Bezerra, "A Software Ecosystem for a Virtual Learning Environment: SOLAR SECO," 2017 IEEE/ACM Joint 5th International Workshop on Software Engineering for Systems-of-Systems and 11th Workshop on Distributed Software Development, Software Ecosystems and Systems-of-Systems (JSOS), Buenos Aires, Argentina, 2017, pp. 41-47, doi: 10.1109/JSOS.2017.2.
Patricia A. Soranno, Edward G. Bissell, Kendra S. Cheruvelil, Samuel T. Christel, Sarah M. Collins, C. Emi Fergus, Christopher T. Filstrup, Jean-Francois Lapierre, Noah R. Lottig, Samantha K. Oliver, Caren E. Scott, Nicole J. Smith, Scott Stopyak, Shuai Yuan, Mary Tate Bremigan, John A. Downing, Corinna Gries, Emily N. Henry, Nick K. Skaff, Emily H. Stanley, Craig A. Stow, Pang-Ning Tan, Tyler Wagner, Katherine E. Webster, Building a multi-scaled geospatial temporal ecology database from disparate data sources: fostering open science and data reuse, GigaScience, Volume 4, Issue 1, December 2015, s13742–015–0067–4, https://doi.org/10.1186/s13742-015-0067-4
THIS ACTION IS MADE FINAL
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
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.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b
Claims 1, 8, 21 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738.
18/908,603 – Claim 1. Toyoshima et al. 2005/0187737 teaches A method, comprising: receiving first data from a development ecosystem (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.), wherein the development ecosystem corresponds to a first system used to develop a technology product (Toyoshima et al. 2005/0187737 [Fig. 7; 0030 - a data analysis system, and an environment with which it is used, for processing and analyzing production and non-production data] FIG. 7 is a block diagram illustrating generally, among other things, one example of portions of a data analysis system, and an environment with which it is used, for processing and analyzing production and non-production data. [0053 - processor 730 may receive data from the input device] The processor 730 may represent a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor 730 may execute instructions and may include that portion of the computer 702 that controls the operation of the entire computer. Although not depicted in FIG. 7, the processor 730 typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the computer 702. The processor 730 may receive data from the input device 750, may read and store code and data in the storage device 740, may send data to the output device 760, and may send and receive code and/or data to/from the network 710.); receiving second data from a non-development ecosystem, wherein the non-development ecosystem corresponds to a second system corresponding to end-use of the technology product (Toyoshima et al. 2005/0187737 [0004 – non-production interpreted as non-development] Further compounding the analysis problem is that factors typically thought to be non-production are not considered in the analysis. Environmental measurements which can greatly affect the quality of manufacturing end-product are just one example of these factors. Even when one is able to qualitatively measure these factors, connecting that meaningfully to other measurements considered to be non-production for the purposes of data analysis requires a user to manually examine the data for commonalities and correlate the data based on those. Further combining that combination with actual production data greatly compounds the amount of data as well as compounding the inability to perform meaningful and timely data analysis. [0005 - combine data from production and non-production sources into a combined set of data for quicker analysis] What is needed is a technique to quickly combine data from production and non-production sources into a combined set of data for quicker analysis. [0006 - a method for performing data analysis on data gathered … method includes collecting production data, collecting non-production data…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0035 – end product] FIG. 1 depicts a pictorial representation of a simplified manufacturing process for items. Items, in an embodiment, include integrated circuits. The item undergoing processing 101 enters the process 110 and exits as a finished product 102. The process 110 is located in a larger manufacturing facility 120. Conditions in the machine performing the process are very important to the quality of the end product 102. The conditions of the item undergoing processing 103 are also very important to the quality of the end product. In addition, the conditions of the manufacturing facility 120 may also impact the quality of the end product. Measurements may be taken on the item 101, 102, and 103, as well as conditions of the actual manufacturing process 110. These measurements can be called production data. The production data is from sources that are directly related to the manufacturing process being performed. These sources include, but are not limited to, test probe data, parametric data, film thickness data, and critical dimension data. In an embodiment, a particular production data sample is gathered once per lot, i.e. production lot data. A production lot can be defined as a subset of the entirety of manufactured items, for example a plurality of work pieces such as electronic devices, integrated circuits, substrates, semiconductor wafers, or other similar structures in this art. A lot may further be considered as that quantity of product produced under similar conditions, at a similar establishment, over some period of time. In an embodiment, a particular production data sample is gathered multiple times per lot. In an embodiment, a particular data sample is applied across multiple production lots. Though this detailed description uses the term production data to refer to these data measurements, this is not to be taken in a limiting sense, as any data that relates directly to the manufacturing process being performed is considered to be production data, regardless of what it is actually called. Further, production data may be further defined as being either online or offline. Online data may be data which is measured directly on the item being manufactured and may be things such as the temperature of the manufactured item, or its thickness. Online data may also be data measured from the manufacturing process in question while the item is being processed. Offline data is that data that, though directly related to the manufacturing process, is not measured on the actual manufactured item or during the actual manufacturing step, such as the operating temperature of the machine, the operating pressure, or some other measurement.); generating a combined set of data from both the first data from the development ecosystem and the second data from the non-development ecosystem (Toyoshima et al. 2005/0187737 [0005 - a technique to quickly combine data from production and non-production sources into a combined set of data for quicker analysis] What is needed is a technique to quickly combine data from production and non-production sources into a combined set of data for quicker analysis. [0006-0008]); performing machine-learning (ML) on the combined set of data from both the development ecosystem and the non-development ecosystem (Toyoshima et al. 2005/0187737 [0006 - a method for performing data analysis on data gathered] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed.); and funneling results from performing ML-based analysis into multiple levels of funneled data objects (Toyoshima et al. 2005/0187737 [0030; FIG. 7 is a block diagram illustrating generally, among other things, one example of portions of a data analysis system, and an environment with which it is used, for processing and analyzing production and non-production data] FIG. 7 is a block diagram illustrating generally, among other things, one example of portions of a data analysis system, and an environment with which it is used, for processing and analyzing production and non-production data.).
Toyoshima et al. 2005/0187737 may not expressly disclose the performing machine-learning (ML) features, however, Bui et al. 2021/0200760 teaches these features as follows (Bui et al. 2021/0200760 [0011 - machine learning operations may be performed] In various embodiments, this lack of point-in-time consistency of data between datacenters may present significant technical problems. As one non-limiting example, within a particular multi-datacenter topology, there may be both a production environment, which includes one or more datacenters primarily used to host software applications and serve online traffic from end users, and a non-production environment, which includes one or more datacenters used primarily to perform testing, simulations, or other analytical operations. (Note, however, that datacenters in a production environment may also be used to perform operations other than servicing online traffic, such as performing analytical operations, and that datacenters in a non-production environment may be used to perform operations other than testing and simulations. The terms “production environment” and “non-production environment,” are simply used herein to denote a significant or common function performed by datacenters within their respective environments.) In some instances, it is desirable to perform analytical operations both in the production environment and, at a subsequent time, to perform the same or similar analytical operations in the non-production environment. As a non-limiting example, machine learning operations may be performed at a first datacenter that is in the production environment, using a particular dataset maintained at the first datacenter to perform a simulation (e.g., to test a risk-detection scenario). In such an example, the machine learning model is trained based on the particular dataset as it existed at a first point in time.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Bui et al. 2021/0200760. One of ordinary skill in the art would have been motivated to do so to utilize well known ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
Toyoshima et al. 2005/0187737 may not expressly disclose the ‘funneling results’ from performing ML-based analysis features, however, Sarferaz 2021/0342738 teaches these features as follows (Sarferaz 2021/0342738 [0222 - provide information regarding analysis provided by a machine learning algorithm] The first level explanation of the user interface screen 2918 can provide a global explanation 2922. The global explanation 2922 can provide information regarding analysis provided by a machine learning algorithm, generally (e.g., not with respect to any particular analysis, but which may be calculated based at least in part on a plurality of analyses). The global explanation 2922 can include information such as the predictive power of a machine learning model, the confidence level of a machine learning model, contributions of individual features to results (generally), relationships (such as dependencies) between features, how results are filtered, sorted, or ranked, details regarding the model (e.g., the theoretical basis of the model, details regarding how the model was trained, such as a number of data points used to trained the model, information regarding when the model was put into use or last trained, how many analyses have been performed using the model, user ratings of the model, etc.), or combinations of these types of information.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Sarferaz 2021/0342738. One of ordinary skill in the art would have been motivated to do so in order to utilize well known ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 8. Toyoshima et al. 2005/0187737 teaches A computer program product embodied on a computer readable medium (Toyoshima et al. 2005/0187737 [0055 - machine-readable media] The storage device 740 represents one or more mechanisms for storing data. For example, the storage device 740 may include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and/or other machine-readable media. In other embodiments, any appropriate type of storage device may be used. Although only one storage device 740 is shown, multiple storage devices and multiple types of storage devices may be present. Further, although the computer 702 is drawn to contain the storage device 740, it may be distributed across other computers, for example on server 701. [0067 - invention may be implemented as a program product…] As was described in detail above, aspects of an embodiment pertain to specific apparatus and method elements implementable on a computer or other electronic device. In another embodiment, the invention may be implemented as a program product for use with an electronic device. The programs defining the functions of this embodiment may be delivered to an electronic device via a variety of signal-bearing media, which include, but are not limited to:), the computer readable medium having stored thereon a sequence of instructions which, when executed by a processor (Toyoshima et al. 2005/0187737 [0053 - processor 730 may execute instructions…] The processor 730 may represent a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor 730 may execute instructions and may include that portion of the computer 702 that controls the operation of the entire computer. Although not depicted in FIG. 7, the processor 730 typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the computer 702. The processor 730 may receive data from the input device 750, may read and store code and data in the storage device 740, may send data to the output device 760, and may send and receive code and/or data to/from the network 710.), performs: …
receiving first data from a development ecosystem, wherein the development ecosystem corresponds to a first system used to develop a technology product; receiving second data from a non-development ecosystem, wherein the non-development ecosystem corresponds to a second system corresponding to end-use of the technology product; generating a combined set of data from both the first data from the development ecosystem and the second data from the non-development ecosystem; performing machine-learning (ML) on the combined set of data from both the development ecosystem and the non-development ecosystem; and funneling results from performing ML-based analysis into multiple levels of funneled data objects.
18/908,603 – Claim 21. (New) A system, comprising: a processor; a memory for holding programmable code (Toyoshima et al. 2005/0187737 [0030 - FIG. 7 is a block diagram illustrating generally, among other things, one example of portions of a data analysis system] FIG. 7 is a block diagram illustrating generally, among other things, one example of portions of a data analysis system, and an environment with which it is used, for processing and analyzing production and non-production data. [0053 - FIG. 7, the processor 730 typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the computer 702. The processor 730 may receive data from the input device 750, may read and store code and data in the storage device 740, may send data to the output device 760, and may send and receive code and/or data to/from the network] The processor 730 may represent a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor 730 may execute instructions and may include that portion of the computer 702 that controls the operation of the entire computer. Although not depicted in FIG. 7, the processor 730 typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the computer 702. The processor 730 may receive data from the input device 750, may read and store code and data in the storage device 740, may send data to the output device 760, and may send and receive code and/or data to/from the network 710.); and wherein the programmable code includes instructions (Toyoshima et al. 2005/0187737 [0071 - machine-readable instructions] Such signal-bearing media, when carrying machine-readable instructions that direct the functions of the present invention, represent embodiments of the present invention. [0061 - programming devices] The computer 702 may be implemented using any suitable hardware and/or software, such as a personal computer or other electronic computing device. Portable computers, laptop or notebook computers, PDAs (Personal Digital Assistants), two-way alphanumeric pagers, keypads, portable telephones, appliances with a computing unit, pocket computers, and mainframe computers are examples of other possible configurations of the computer 702. The hardware and software depicted in FIG. 7 may vary for specific applications and may include more or fewer elements than those depicted. For example, other peripheral devices such as audio adapters, or chip programming devices, such as EPROM (Erasable Programmable Read-Only Memory) programming devices may be used in addition to or in place of the hardware already depicted. [0033 - programming instructions] Parts of the description may be presented in terms of operations performed through the execution of programming instructions. As well understood by those skilled in the art, those operations may take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, and otherwise manipulated through, for example, electrical components.) for: …
receiving first data from a development ecosystem, wherein the development ecosystem corresponds to a first system used to develop a technology product; receiving second data from a non-development ecosystem, wherein the non-development ecosystem corresponds to a second system corresponding to end- use of the technology product; generating a combined set of data from both the first data from the development ecosystem and the second data from the non-development ecosystem; performing machine-learning (ML) on the combined set of data from both the development ecosystem and the non-development ecosystem; and funneling results from performing ML- based analysis into multiple levels of funneled data objects.
The remaining features/limitations of Claims 8 and 21, have similar features/limitations as of Claim 1, therefore those features/limitations and the claims are REJECTED under the same rationale as Claim 1.
Claims 2, 9, 22 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738; in even further view of Zhou et al. 2020/0374696.
18/908,603 – Claim 2. Toyoshima et al. 2005/0187737 further teaches The method of claim 1, wherein the first data from the development ecosystem and the second data from the non-development ecosystem are both provided to a united analysis platform (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.), and an ML processor resides at the united analysis platform to perform the machine learning (Toyoshima et al. 2005/0187737 [0006 - a method for performing data analysis on data gathered] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed.).
Toyoshima et al. 2005/0187737 may not expressly disclose the “platform” features, however, Zhou et al. 2020/0374696 teaches these features as follows (Zhou et al. 2020/0374696 [0051 – IoT platform interpreted as united analysis platform] “IoT platform” described in this application is a relatively broad concept, can perform operations such as integration, sorting, analysis, and feedback on data information collected by an IoT terminal, and mainly performs management on many terminals, data management, operation management, and security management. The IoT platform integrates many advanced technologies, including cloud computing, big data, artificial intelligence, and the like, to meet requirements for performing information transmission and exchange on the IoT. The IoT platform may include a plurality of processing platforms with different functions, and is responsible for extracting data used for control and decision making from perception data based on an application requirement, and converting the data into different formats for sharing among a plurality of application systems. In actual application, the IoT platform may include one or more devices. In terms of a type, the IoT platform may be divided into four types of platforms from bottom to top a terminal management platform, a connection management platform, an application development platform, and a service analysis platform. The terminal management platform is mainly responsible for performing registration management, identity identification, access control, configuration, monitoring, query, system upgrade, troubleshooting, lifecycle management, and the like on the IoT terminal. The connection management platform is mainly responsible for performing configuration and fault management, network resource usage management, connection resource management, package change, number/IP address/media access control (MAC) resource management, and the like on an IoT connection. The application development platform may provide a platform as a service (Paas) platform used for application development and unified data storage, and provide an application development tool, middleware, data storage, a service logic engine, an application platform interface (API) for connecting to a third party, and the like. The service analysis platform is mainly configured to classify and analyze service data, and provide a visual data analysis result. The service analysis platform monitors a device status and gives a warning through real-time dynamic analysis, or analyzes and predicts a service through machine learning.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Zhou et al. 2020/0374696. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 9. The computer program product of claim 8, wherein the first data from the development ecosystem and the second data from the non-development ecosystem are both provided to a united analysis platform, and an ML processor resides at the united analysis platform to perform the machine learning.
18/908,603 – Claim 22. (New) The system of claim 21, wherein the first data from the development ecosystem and the second data from the non-development ecosystem are both provided to a united analysis platform, and an ML processor resides at the united analysis platform to perform the machine learning.
Claims 9 and 2, have similar limitations as of Claim 2, therefore they are REJECTED under the same rationale as Claim 2.
Claims 3, 10, 23 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738; in even further view of Duncan et al. 2017/0220943.
18/908,603 – Claim 3. Toyoshima et al. 2005/0187737 further teaches The method of claim 1, wherein the machine-learning performed on the combined set of the data from both the development ecosystem and the non-development ecosystem (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.) comprises automatic processing of the data to generate a database comprising both raw data and categorized data, where correlation is performed against the raw data and the categorized data from both the development ecosystem and the non-development ecosystem (Toyoshima et al. 2005/0187737 [0024 - FIG. 2 is a flowchart illustrating … a method for collecting and correlating production and non-production data for analysis] FIG. 2 is a flowchart illustrating generally, among other things, a method for collecting and correlating production and non-production data for analysis according to an embodiment of the present invention.).
Toyoshima et al. 2005/0187737 may not expressly disclose the “raw and uncategorized data” features, however, Duncan et al. 2017/0220943 teaches these features as follows (Duncan et al. 2017/0220943 [0009 - statistical, pattern recognition, and machine learning tools to support the discovery of patterns, trends and rules that lie within the data] To satisfy this need, a new interdisciplinary field appeared. It encompasses statistical, pattern recognition, and machine learning tools to support the discovery of patterns, trends and rules that lie within the data. [0011 - machine-learning algorithms are applied to extract non-obvious knowledge from data] In this approach, machine-learning algorithms are applied to extract non-obvious knowledge from data to reduce, or even eliminate, the above-mentioned drawbacks. The methods also extend the possibilities of discovering information, trends and patterns by using richer model representations (e.g. decision rules, decision trees) than standard statistical methods, and are therefore well suited for making the results more comprehensible to non-technically oriented business users. [0301 - machine-learning techniques available for each type of CRM model] There are numerous machine-learning techniques available for each type of CRM model. The expert system 11 may choose algorithms using methods knowledge base 42 based on data characteristics and business requirements as determined in stages 100 and 200 of the process shown in FIG. 3. Exemplary algorithms include association rule, decision tree, genetic algorithm, neural networks, K-Nearest neighbor, and linear/logistic regression, as outlined below. [0048 - production environment – interpreted as non-development ecosystem] Embodiments of the presently disclosed methods and systems bring scientific and engineering dimensions to automated knowledge extraction and application to business users in the retail sector, with minimal help from various human experts; furthermore, as the area of analytical CRM (for example) represents a dynamic environment with continuous need for repeated analyses, the automation of processes present in a production environment is key to meeting an entity's business objectives. Embodiments focus on business users and other decision makers, enabling them to develop data models via a user-friendly and intuitive GUI, and through a cloud-computing platform. As a result, knowledge extraction and application become more fully integrated in business environments and their decision processes. [0091- production environment – interpreted as non-development ecosystem] The business user is an active executor of the production stage 2. The production stage 2 provides the business user with updated models for its production environment when data changes, or the business user's strategy, warrant it. [0336 – raw input data] In certain embodiments, the system 810 may have functionality for generating and applying one or more models to data acquired by the system. For example, the retail network management system 850 may comprise an expert system 11 as described above. The expert system 11 determines, based on user input, the analysis objectives, applies preprocessing 200 to the raw input data acquired by system 810 to obtain processed input data, generates and validates 300 one or more models, and applies 400 the model(s) to the processed input data to produce numerical and graphical output which is displayable on a display 822 of a device of a user 832. [0372 - categorized data] Just like with the sales force CRM application, the use of a digital application over a paper form greatly enhances the reliability of the data obtained. Also, similarly, data based on categories and limited multiple choice options over free text fields is privileged whenever possible; indeed, from a data quality point of view, categorized data is easier to control, whereas free text fields may need additional post-processing, given that data may be entered inconsistently by customers (e.g. address fields). [0012 - applying the patterns, trends, relationships and correlations that have lain undiscovered within large amounts of data] Retailers should, in theory, be able to improve their businesses by applying the patterns, trends, relationships and correlations that have lain undiscovered within large amounts of data. [0184 - Expert system 11 systematically computes the correlation (grade of relation) between pairs of input variables in order to identify variables that have a low correlation with other variables in the dataset] Expert system 11 systematically computes the correlation (grade of relation) between pairs of input variables in order to identify variables that have a low correlation with other variables in the dataset, for the user to possibly eliminate. [0320 - Association rule finds interesting correlation relationships among a large set of data items] Association rule finds interesting correlation relationships among a large set of data items. A typical application would be market basket analysis, which analyzes customers' buying habits by finding associations between the different items that customers place in their shopping baskets.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Duncan et al. 2017/0220943. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 10. The computer program product of claim 8, wherein the machine-learning performed on the combined set of the data from both the development ecosystem and the non-development ecosystem comprises automatic processing of the data to generate a database comprising both raw data and categorized data, where correlation is performed against the raw data and the categorized data from both the development ecosystem and the non-development ecosystem.
18/908,603 – Claim 23. (New) The system of claim 21, wherein the machine-learning performed on the combined set of the data from both the development ecosystem and the non-development ecosystem comprises automatic processing of the data to generate a database comprising both raw data and categorized data, where correlation is performed against the raw data and the categorized data from both the development ecosystem and the non-development ecosystem.
Claims 10 and 23, have similar limitations as of Claim 3, therefore they are REJECTED under the same rationale as Claim 3.
Claims 4, 11, 24 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738; in even further view of Natarajan et al. 2020/0174774.
18/908,603 – Claim 4. Toyoshima et al. 2005/0187737 further teaches The method of claim 1, wherein the first data from the development ecosystem and the second data from the non-development ecosystem (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.) correspond to event hierarchies, the event hierarchies comprise stages of funneling for receiving and analyzing the first and second data (Toyoshima et al. 2005/0187737 [0006 - a method for performing data analysis on data gathered] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed.), where a first event hierarchy corresponds to the first data from the development ecosystem and a second event hierarchy corresponds to the second data from the non-development ecosystem (Toyoshima et al. 2005/0187737 [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.), and the first event hierarchy has different stages compared to the second event hierarchy (Toyoshima et al. 2005/0187737 [0037; 0054]).
Toyoshima et al. 2005/0187737 may not expressly disclose the “hierarchical structure” and “stages” features, however, Natarajan et al. 2020/0174774 teaches these features as follows (Natarajan et al. 2020/0174774 [0032 – first data and second data] In some implementations, the metric platform may select one or more of the data processing techniques to process the historical application creation data based on a source of the data. For example, if the historical application creation data is received from a first source, the metric platform may utilize a first data processing technique to process the historical application creation data, if the historical application creation data is received from a second source, the metric platform may utilize a second data processing technique to process the historical application creation data, and/or the like. As shown in FIG. 1E, and by reference number 125, the metric platform may receive new application creation data associated with a new application (e.g., data associated with creation of the new application). In some implementations, the new application may be newly written and the new application data may include data identifying source code of the new application, a development environment in which the new application may be developed, a testing environment in which the new application may be tested, a production environment in which the new application may be deployed, and/or the like. [0028 - hierarchical structure] In some implementations, the metric platform may utilize a natural language processing technique, a computational linguistics technique, a text analysis technique, and/or the like, with the historical application creation data in order to make the historical application creation data (e.g., the processed historical application creation data) analyzable. For example, the metric platform may apply natural language processing to interpret the historical application creation data and generate additional data associated with the potential meaning of data within the historical application creation data. Natural language processing involves techniques performed (e.g., by a computer system) to analyze, understand, and derive meaning from human language in a useful way. Rather than treating text like a mere sequence of symbols, natural language processing considers a hierarchical structure of language (e.g., several words can be treated as a phrase, several phrases can be treated as a sentence, and the words, phrases, and/or sentences convey ideas that can be interpreted). Natural language processing can be applied to analyze text, allowing machines to understand how humans speak, enabling real world applications such as automatic text summarization, sentiment analysis, topic extraction, named entity recognition, parts-of-speech tagging, relationship extraction, stemming, and/or the like. [0032 – first data and second data] In some implementations, the metric platform may select one or more of the data processing techniques to process the historical application creation data based on a source of the data. For example, if the historical application creation data is received from a first source, the metric platform may utilize a first data processing technique to process the historical application creation data, if the historical application creation data is received from a second source, the metric platform may utilize a second data processing technique to process the historical application creation data, and/or the like. [0042 - development systems] In some implementations, the metric platform may receive updated historical application creation data in real time and/or periodically (e.g., from one or more software development systems associated with the applications currently being developed). In such implementations, the metric platform may update the trained machine learning model based on the updated historical application creation data. [0044 - a development environment in which the new application may be developed, a testing environment in which the new application may be tested, a production environment in which the new application may be deployed] As shown in FIG. 1E, and by reference number 125, the metric platform may receive new application creation data associated with a new application (e.g., data associated with creation of the new application). In some implementations, the new application may be newly written and the new application data may include data identifying source code of the new application, a development environment in which the new application may be developed, a testing environment in which the new application may be tested, a production environment in which the new application may be deployed, and/or the like. [0062 - several different stages…] In this way, several different stages of the process for predicting metrics associated with an application development process may be automated with a machine learning model, which may remove human subjectivity and waste from the process, and which may improve speed and efficiency of the process and conserve computing resources (e.g., processing resources, memory resources, and/or the like). Furthermore, implementations described herein use a rigorous, computerized process to perform tasks or roles that were not previously performed, or were previously performed using subjective human intuition or input. For example, currently there does not exist a technique that utilizes a machine learning model to predict metrics for an application development process in the manner described herein. Further, automating the process for predicting metrics associated with an application development process conserves computing resources (e.g., processing resources, memory resources, and/or the like) that would otherwise be wasted in using a less efficient technique to predict such metrics. In some implementations, the metric platform may utilize a natural language processing technique, a computational linguistics technique, a text analysis technique, and/or the like, with the historical application creation data in order to make the historical application creation data (e.g., the processed historical application creation data) analyzable. For example, the metric platform may apply natural language processing to interpret the historical application creation data and generate additional data associated with the potential meaning of data within the historical application creation data. Natural language processing involves techniques performed (e.g., by a computer system) to analyze, understand, and derive meaning from human language in a useful way. Rather than treating text like a mere sequence of symbols, natural language processing considers a hierarchical structure of language (e.g., several words can be treated as a phrase, several phrases can be treated as a sentence, and the words, phrases, and/or sentences convey ideas that can be interpreted). Natural language processing can be applied to analyze text, allowing machines to understand how humans speak, enabling real world applications such as automatic text summarization, sentiment analysis, topic extraction, named entity recognition, parts-of-speech tagging, relationship extraction, stemming, and/or the like.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Natarajan et al. 2020/0174774. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue. 18/908,603 – Claim 11. The computer program product of claim 8, wherein the first data from the development ecosystem and the second data from the non-development ecosystem correspond to event hierarchies, the event hierarchies comprise stages of funneling for receiving and analyzing the first and second data, where a first event hierarchy corresponds to the first data from the development ecosystem and a second event hierarchy corresponds to the second data from the non-development ecosystem, and the first event hierarchy has different stages compared to the second event hierarchy. 18/908,603 – Claim 24. (New) The system of claim 21, wherein the first data from the development ecosystem and the second data from the non-development ecosystem correspond to event hierarchies, the event hierarchies comprise stages of funneling for receiving and analyzing the first and second data, where a first event hierarchy corresponds to the first data from the development ecosystem and a second event hierarchy corresponds to the second data from the non-development ecosystem, and the first event hierarchy has different stages compared to the second event hierarchy.
Claims 11 and 24, have similar limitations as of Claim 4, therefore they are REJECTED under the same rationale as Claim 4.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738; in even further view of White et al. 2020/0126117.
18/908,603 – Claim 5. Toyoshima et al. 2005/0187737 further teaches The method of claim 1, further comprising: receiving third data from a user ecosystem (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.), wherein the user ecosystem corresponds to one or more users that use the technology product; receiving fourth data from a customer relations ecosystem, wherein the customer relations ecosystem corresponds to a customer relations system related to the technology product (Toyoshima et al. 2005/0187737 [0067 - invention may be implemented as a program product for use with an electronic device] As was described in detail above, aspects of an embodiment pertain to specific apparatus and method elements implementable on a computer or other electronic device. In another embodiment, the invention may be implemented as a program product for use with an electronic device. The programs defining the functions of this embodiment may be delivered to an electronic device via a variety of signal-bearing media, which include, but are not limited to:); and wherein the combined set of data comprises the first data, the second data, the third data, and the fourth data (Toyoshima et al. 2005/0187737 [0005 - a technique to quickly combine data from production and non-production sources into a combined set of data for quicker analysis] What is needed is a technique to quickly combine data from production and non-production sources into a combined set of data for quicker analysis. [0006-0008]).
Toyoshima et al. 2005/0187737 may not expressly disclose the “customer relations” features, however, White et al. 2020/0126117 teaches these features as follows (White et al. 2020/0126117 [0025 - customer relationship management system…] Furthermore, detection component 110 can extract another subset of first data representing a user browsing an e-commerce website application for mini-van vehicle accessories. For instance, detection component 110 can extract data from data stores that store dealership website data, third party shopping data, or any tangential or related online or offline consumer behavioral data or indicator of intent to purchase a relevant good or service. In an aspect, processor 112 can execute matching component 120 to integrate the subsets of first data and correlate them (based on identification data) as corresponding to the same user. Furthermore, matching component 120 can compare the combined subsets of first data to second data representing existing customers of an automotive dealership stored in a data management system implemented on a dealership data store and determine that the subsets of first data (e.g., newly generated online and offline data) correspond to an existing customer (e.g., user device or user account of an existing customer). For instance, offline data can include wireless access point data, offline geographic positioning data, consumer data, public record data, credit data, credit score data, predictive income data, vehicle ownership data, pre-screen offer data, and other information that is not online data. Furthermore, in an aspect, online data can include data associated with web browsing, click-through data, click stream data, cookies, mobile ad identifiers (MAIDs), e-mail account information, online registration data, online site usage data (e.g., social media usage data), transaction data, mobile app data and other such data. Accordingly, processor 112 can execute notification component 130 to transmit notification data representing the detection and identification of an existing customer having interest in shopping for a vehicle. Furthermore, notification component 130 can transmit notification data to one or more device (e.g., dealership sales personnel smart phone) or one or more data store (e.g., dealership management system data store or dealership customer relationship management system data store). In another aspect, notification component 130 can transmit notification data to one or more device or data store that represents a matching event has not occurred, such that an indication that a subset of first data does not match an existing customer data has occurred.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by White et al. 2020/0126117. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 12. The computer program product of claim 8, further comprising: receiving third data from a user ecosystem, wherein the user ecosystem corresponds to one or more users that use the technology product; receiving fourth data from a customer relations ecosystem, wherein the customer relations ecosystem corresponds to a customer relations system related to the technology product; and wherein the combined set of data comprises the first data, the second data, the third data, and the fourth data.
Claim 12, has similar limitations as of Claim 5, therefore it is REJECTED under the same rationale as Claim 5.
Claims 6, 7, 13, 14, 25, 26 are rejected under 35 U.S.C. 103 as being unpatentable over: Toyoshima et al. 2005/0187737; in view of Bui et al. 2021/0200760; in further view of Sarferaz 2021/0342738; in even further view of Sachan et al. 2020/0293946.
18/908,603 – Claim 6. Toyoshima et al. 2005/0187737 further teaches The method of claim 1, wherein events from the combined set of data are analyzed to identify an incident (Toyoshima et al. 2005/0187737 [0006 – performing data analysis on data gathered…] An embodiment of the present invention is a method for performing data analysis on data gathered in an electronic device manufacturing process. The method includes collecting production data, collecting non-production data, keying the production data, keying the non-production data, combining the production data and the non-production data into a single data set, and analyzing single data-set. An embodiment of the present invention further includes performing calculations on the production data and the non-production data. Collection of production data includes at least one of collecting parametric production data, collecting film thickness data, critical dimension data, and any other data that is relevant to the production process and its condition. Collection of non-production data includes at least one of collecting non-production data from a single data source at a single source location or from a plurality of locations, and collecting non-production data from a single data source with some temporal periodicity. In an embodiment, the temporal periodicity is fixed. In an embodiment, the temporal periodicity is not fixed. [0037 – Data is collected from both production and non-production sources…] FIG. 2 presents a method, according to an embodiment of the present invention, for combining the data taken during the manufacturing process for the purposes of data analysis. Data is collected from both production and non-production sources, at 201, 202, 203. Non-production sources may include, but not be limited to, thermometers providing temperature readings 201a, barometers providing pressure measurements 201c, staff productivity recording systems, electrical measurements 201b, equipment control data, metrology tool calibration data, etc. Non-production sources also include sources that provide any other data relevant to the production environment, where the production environment may include, but not be limited to, the facility where the production is performed, a larger physical gathering of multiple production facilities in a single geographical location, etc. Production sources may further be divided into online production sources and offline production sources. Online production sources may include, but not be limited to, critical dimension readings 202a, chemical sampling 202b, surface readings, 202c, etc. Offline production sources may include, but not be limited to, offline circuit testing 203a, photomask inspection 203b, operating temperature readings 203c, etc. At 204 and 205 the non-production data and the production data are keyed to some value, respectively. In an embodiment, the data is keyed to a temporal, or date-time, value. In an embodiment, at 204, that data is keyed with a date-time value. In an embodiment, at 205, that data is keyed with production lot data, which may be further keyed with date-time values associated with the time that a particular production lot began a manufacturing process as well as the time that the particular production lot completed the manufacturing process. In an embodiment, non-production data is measured at a single location, such as depicted in FIG. 3. In an embodiment, the sampling location for the data measurement 310 is separated some distance 320 from the process equipment 301. In an embodiment, production data is measured at a plurality of locations, such as depicted in FIG. 4. The process equipment 301 is separated by a variable distance from the locations where data is being measured. For sampling location 1 at 310, the distance 320 can be defined as d.sub.1. For sampling location 2 at 410, the distance 420 can be defined as d.sub.2. There may be many locations where the data is being measured. For all sampling locations I at 411, the distance 421 can be defined as d.sub.i. Such multiple sampling locations 310, 410, 411 allow statistical operations on a similar type of sampled data from a plurality of different sample locations. For example, the different sample locations allow a similar type of data to be collected at a plurality of locations in a lot.), and the incident is analyzed to identify a ticket that is assigned within a software organization to address the ticket (Toyoshima et al. 2005/0187737 [0061] The computer 702 may be implemented using any suitable hardware and/or software, such as a personal computer or other electronic computing device. Portable computers, laptop or notebook computers, PDAs (Personal Digital Assistants), two-way alphanumeric pagers, keypads, portable telephones, appliances with a computing unit, pocket computers, and mainframe computers are examples of other possible configurations of the computer 702. The hardware and software depicted in FIG. 7 may vary for specific applications and may include more or fewer elements than those depicted. For example, other peripheral devices such as audio adapters, or chip programming devices, such as EPROM (Erasable Programmable Read-Only Memory) programming devices may be used in addition to or in place of the hardware already depicted.).
Toyoshima et al. 2005/0187737 may not expressly disclose the “incident ticket” features, however, Sachan et al. 2020/0293946 teaches these features as follows (Sachan et al. 2020/0293946 [0029 - If the incident ticket is an actionable incident ticket, a machine learning based incident ticket creation and routing model may be utilized to determine appropriate routing information for the incident ticket] The apparatuses, methods, and non-transitory computer readable media disclosed herein may operate in a reactive mode and/or a proactive mode. In the reactive mode, an indication of an incident (or an issue associated with an incident) that is being experienced by a user may be received. Metadata associated with the incident may be analyzed to generate an incident ticket, and to determine a state (e.g., new or existing) of the incident. If the incident is new, a determination may be made as to whether the incident is actionable or non-actionable. This determination may be made by utilizing a machine learning based incident classification model that is trained on historical incident tickets, where each such historical incident tickets may be labeled as actionable or non-actionable. Thus, the machine learning based incident classification model may be utilized to determine a type of an incident ticket, and to take action such as closure of the incident ticket in the event of a non-actionable ticket, as well as prediction of a nature of the incident ticket. If the incident ticket is an actionable incident ticket, a machine learning based incident ticket creation and routing model may be utilized to determine appropriate routing information for the incident ticket. In this regard, the machine learning based incident ticket creation and routing model may learn incident ticket routing patterns from historical incident ticket assignments, and determine a correct assignment group for a new incident ticket based on prior assignment of similar incident tickets for the assigned group. [0171 - incident ticket router 112 may determine whether a new incident ticket will be actionable or non-actionable type of ticket, for example by using the machine learning based incident classification model] The incident ticket router 112 may provide for the reduction of time consumed and maintenance of incident tickets that require no user intervention for their resolution. The incident ticket router 112 may determine whether a new incident ticket will be actionable or non-actionable type of ticket, for example by using the machine learning based incident classification model 114. The machine learning based incident classification model 114 may be trained by utilizing labeled historical incident tickets, where such historical incident tickets may be labeled as actionable or non-actionable. In real time, the machine learning based incident classification model 114 may be utilized to determine the type of incident ticket, and take action such as closure of the incident ticket in the event of a non-actionable incident ticket, and to further predict the nature of the associated incident ticket such as category, subcategory, configuration item, severity, assignment group in the event of an actionable incident ticket. An actionable incident ticket may include an issue that requires some human (e.g., manual) intervention to fix an issue. A non-actionable incident ticket may include an issue/incident that requires no human intervention. Therefore, if a given incident ticket is of a non-actionable nature, then the incident ticket may not need to be logged in. However, an actionable incident ticket may need to be logged. While logging or creating an incident ticket, some mandatory information specific to the incident ticket may need to be completed. Since the incident ticket logging (or creation) process may be automated as disclosed herein, the mandatory information of the incident ticket may be predicted, and may include a “category” of the incident ticket, a “subcategory” of the incident ticket, an “impacted application” which may also be referred to as a configuration item, a “severity” of the incident ticket, etc.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Sachan et al. 2020/0293946. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 13. The computer program product of claim 8, wherein events from the combined set of data are analyzed to identify an incident, and the incident is analyzed to identify a ticket that is assigned within a software organization to address the ticket.
18/908,603 – Claim 25. (New) The system of claim 21, wherein events from the combined set of data are analyzed to identify an incident, and the incident is analyzed to identify a ticket that is assigned within a software organization to address the ticket.
Claims 13 and 25, have similar limitations as of Claim 6, therefore they are REJECTED under the same rationale as Claim 6.
18/908,603 – Claim 7. Toyoshima et al. 2005/0187737 may not expressly teach the following, however, Sachan et al. 2020/0293946 teaches The method of claim 6, wherein the ticket is created based upon clustering of multiple incidents (Sachan et al. 2020/0293946 [0196 - incident ticket router … may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters…). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. In order to find similar behavior existing between the incident and the identified cluster members, a determination may be made as to how many incidents have similar severity…] At block 1406, the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. In order to find similar behavior existing between the incident and the identified cluster members, a determination may be made as to how many incidents have similar severity (e.g., impact of the incident such as Sev1, Sev2, Sev3, etc.), how many incidents are impacting similar applications such as App1, App2, App3, etc., how many incidents have similar issue type such as network issues, database issues, etc. Further, all incident attributes in the repository may be compared to find common patterns. The top three most occurring common behaviors may be considered as the dominant patterns.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Toyoshima et al. 2005/0187737 to include the features as taught by Sachan et al. 2020/0293946. One of ordinary skill in the art would have been motivated to do so to utilize well known data analysis and ML techniques for analyzing data which should prove to improve user experience, maximize profits, and optimize revenue.
18/908,603 – Claim 14. The computer program product of claim 13, wherein the ticket is created based upon clustering of multiple incidents.
18/908,603 – Claim 26. (New) The system of claim 25, wherein the ticket is created based upon clustering of multiple incidents.
Claims 14 and 26, have similar limitations as of Claim 7, therefore they are REJECTED under the same rationale as Claim 7.
Prosecution Insights