DETAILED ACTION
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 .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 3/27/25, Applicant, on 8/27/25, amended claims. Claims 1-15 are pending in this application and have been rejected below.
Some of the previous 112b rejections are withdrawn; new 112b rejections are necessitated by the amendments.
Claim Interpretation
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.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“unit calculator for calculating KPI” in claim 1;
“plan execution module comprising processing means adapted to process a plan” in claim 1;
“plan generator module configured to generate at least one plan” in claim 1;
“inventory module programmed to generate KPI definitions…” in claim 2;
“inventory module further comprises memory means adapted to store plans” in claim 3;
“inventory module comprises processing means adapted to manage at least one managed entity type” in claim 6;
“plan generator module comprises processing means programmed to generate a plan” in claim 11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 now recites “thereby ensuring recalculation of KPIs for periods with late-arriving data.” There is insufficient antecedent basis for this limitation. It is unclear which data this is referring to – as the earlier limitations recite that if a timestamp is “greater than the previously stored value for a given period, automatically trigger generation and execution of a new collection plan… and replace the plan.” Accordingly, is the “recalculation of KPIs” for the “new collection plan”? Applicant’s specification [0076] as published appears to have a different scope – as it appears to refer to data that occurs earlier – “Dates that where already collected but were found to have a sequence number greater than the previous maximum will have a new collection plan generated, one that contains only the KPIs that use counter or attributes from those data sources.” [0005] as published states “On periodical calculations of KPIs, another situation arises in that sometimes the raw data might not be have been fully available at the time of execution and is at a later date, so those periods should be identified for later reprocessing.” [0010] as published states “sequence number is used by the system to validate if there is data, related to time periods older than the most recent currently on the data sources, being inserted later than expected.” It is unclear what to suggest as it is not clear if the “later data” in 0005, 0010 is related to the plans, or exactly which KPI is referred to. Perhaps the last limitation is referring to [0045] as published stating “From a data analysis standpoint it is useful for KPIs to be periodical, so that their evolution can be evaluated and monitored over time and compared over homologous periods. A KPI's period is at least equal to that of the counters of the data sources it is related to. If the period is greater, this means that a time aggregation must be applied to the data from those data sources, so that the results are in the time frame of the KPI.” Or possibly [0065] as published “For example, a data source (103) with a delay of 5 minutes is expected to have all data of a given interval stored up to 5 minutes after the end of this interval. Should that fail to happen and some or all data be stored at a later date, given the periodic nature of KPIs the unit (100) should be able to detect these situations so that a new plan can be generated for this interval for the KPIs whose data was incomplete.” In addition, “thereby ensuring” is not even a positively recited action. For purposes of applying prior art only, Examiner suggests considering amending claim 1 as reciting a new limitation, positively reciting: “recalculating [[of]] KPIs for the new plan
Claims 2-15 depend from claim 1 and are rejected for the same reasons.
Claim 4 is indefinite, as it recites “replace the plan,” but claim 1 already recited “replace the plan.” It appears the 2nd limitation in claim 4 of “replace the plan” should be removed.
Claim 4 is indefinite, as it recites “a new collection plan,” but claim 1 already recited “a new collection plan.” Examiner suggests “the new collection plan” or removing the limitation.
Claim 4 at the end recites “thereby ensuring KPI completeness despite out-of-order data ingestion.” There is insufficient antecedent basis for the limitation as claim 1 already recites “thereby ensuring recalculation of KPIs for periods with late-arriving data.” First, this appears to be the same limitation. Second, this has many of the same issues as claim 1, as it is unclear which KPI for which plan is being completed, and Examiner suggests similar language as in claim 1, but Examiner is not sure what is desired by Applicant.
Claim limitations “Key performance indicator (KPI) unit calculator for calculating KPI” in claim 1;
“a plan execution module comprising processing means adapted to process a plan” in claim 1;
“a plan generator module configured to generate at least one plan” in claim 1;
“an inventory module programmed to generate KPI definitions…” in claim 1, 2;
“inventory module further comprises memory means adapted to store plans” in claim 3;
“inventory module comprises processing means adapted to manage at least one managed entity type” in claim 6;
“plan generator module comprises processing means programmed to generate a plan” in claim 11” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function:
“unit calculator for calculating KPI” in claim 1 – [0041 as published states “The present disclosure relates to computer systems .” [0078] as published states “A number of computer systems have been described in this disclosure.” Claims as filed indicated unit calculator as referring to “100”, which is the overall system in FIG. 1, but the number is now deleted from the claim. The current claim as recited is for the function of “calculating KPI of a processing system.” However, there is no “processing system” throughout the specification, but this is just what the KPI is referring to as best understood. So it is unclear what the structure for the “unit calculator” may be.
“plan execution module comprising processing means adapted to process a plan” in claim 1 – appears that [0047] as published gives example where module 101 [presumably “plan execution module” since claims as filed indicated 101, but number since deleted] can be a “computer program that is able to execute a set of instructions delivered to it as a plan (102).” However, since the claim is written as an apparatus claim (as best understood), it is unclear whether this refers to structure of a computer, as it then also recites “processing means.” However, the disclosure never explains what “processing means” refers to. Suggestions are below to avoid 112f interpretation, and hopefully clarify the claim.
“plan generator module configured to generate at least one plan” in claim 1 – similar to limitation above – unclear which structure in current arrangement of limitations.
“inventory module programmed to generate KPI definitions…” in claim 2 - similar to limitation above – unclear which structure in current arrangement of limitations and whether or not this is using the “processing means” of claim 1.
“inventory module further comprises memory means adapted to store plans” in claim 3 - - similar to limitation above – unclear which structure in current arrangement of limitations and whether or not this is using the “processing means” of claim 1.
“inventory module comprises processing means adapted to manage at least one managed entity type” in claim 6 - - similar to limitation above – unclear which structure in current arrangement of limitations along with the “processing means” of claim 1.
“plan generator module comprises processing means programmed to generate a plan” in claim 11 - unclear which structure in current arrangement of limitations along with the “processing means” of claim 1.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 2-15 depend from claim 1 and are rejected for the same reasons.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Examiner suggests amending the claim to avoid the 112f interpretation since it is unclear what structure corresponds to various terms as disclosed. In light of “computer” disclosed, Examiner suggests amending the claim to recite (or something similar to), based on [0041-0042, 0047-0048, 0078]:
A computer system comprising storage for the computer executing instructions comprising:
calculating Key Performance Indicator (KPI)
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a “unit calculator for calculating,” which based on claim interpretation, is a statutory category of an apparatus [however, it is unclear in the 112b rejection what the structure entails]. For purposes of claim interpretation here, it is believed the intention is to claim a “computer” by the recitation of the “unit”. As stated above, Examiner suggests Applicant recite “A computer system comprising storage for the computer executing instructions comprising:
calculating Key Performance Indicator” or similar limitations to clarify, and help pave a way to make persuasive 101 arguments directed to “improving computing technology.”
Examiner has provided suggestions below for overcoming the 101 rejections.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“A Key Performance Indicator (KPI) … calculator for calculating KPI comprising the following modules:
-A plan execution module comprising … adapted to process a plan for calculating at least one KPI, wherein the plan is a collection of nodes, each node corresponding to one operation selected from a list of operations;
-A plan generator module configured to a plan; wherein the plan comprises instructions to: i.) access to raw data on data sources of the processing system, ii.) process the raw data, iii.) and send an output …;
wherein the plan generator module is further configured to automatically generate a recovery-detection plan, distinct from the plan;
the recovery-detection plan comprising instructions to perform:
(a) access sequence numbers or timestamps from each data source for a given time interval;
(b) compare the accessed sequence numbers or timestamps with previously stored values in an inventory module; and
(c) upon detecting a sequence number or timestamp greater than the previously stored value for a given period, automatically trigger generation and execution of a new collection plan for an affected period and replace the plan, thereby ensuring recalculation of KPIs for periods with late-arriving data
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “mathematical relationships” as here we are performing a series of mathematical operations- first, calculating KPIs, having a plan to perform different operations (which can be mathematical or logical – see 0045 as published). Accordingly, claim 1 is directed to an abstract idea because it is doing a series of mathematical calculations to calculate KPI (key performance indicators).
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements that are:
““A Key Performance Indicator (KPI) unit calculator for calculating KPI of a processing system, comprising the following modules:
-A plan execution module comprising processing means adapted to process a plan for calculating at least one KPI, wherein the plan is a collection of nodes, each node corresponding to one operation selected from a list of operations;
-A plan generator module configured to generate a plan; wherein the plan comprises instructions to: i.) access to raw data on data sources of the processing system, ii.) process the raw data, iii.) and send an output to at least one data sink;
-at least one data source;
-at least one data sink (dependent claim 15 states “Data sink (104) is or more databases, filesystems, other computer readable storage mediums, or other applications or computer systems such as, but not limited to, messaging systems.” )
… [the remaining limitations only have automatically generate a recovery-detection plan, and analyze time sequence to generate a new plan and recalculate the KPI [and are considered part of the “directed to an abstract idea above”]
(MPEP 2106.05f applies –the claim involves a computer (as likely to be amended towards this given the 112 issues, and based on “unit” and “processing means” as best understood), and is considered “apply it [the abstract idea – math relationships] on a computer”; merely uses a computer as a tool to perform an abstract idea; combination of computer/unit, “send output to data sink; and having a “data source” is viewed as “field of use” (MPEP 2106.05h)).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a computing system, is treated as MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
The limitations of “send the output to data sinks; At least one data source, at least one data sink” are conventional computer functions – See MPEP 2106.05d(II)(iv) - Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334.
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. The claim is not patent eligible. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Claim 2 narrows the abstract idea by generating a plan based on definitions of KPI and metadata. Claim 2 has additional elements of naming a “module” of presumably the computer. This is viewed as “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2B. It is also a conventional computer function at step 2B (MPEP 2106.05d(II) - iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334).
Claim 3 has an additional elements of “memory means adapted to store plans”. This is viewed as “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2B. It is also a conventional computer function at step 2B (MPEP 2106.05d(II) - iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334).
Claim 4 narrows the abstract idea by appearing [as best understood in light of 112b rejections] to duplicate many of limitations now in claim 1 and have a “new plan”.
Claim 5 narrows the abstract idea by describing characteristics of the KPI (e.g. type, period, OR delay).
Claim 6 narrows the abstract idea by allowing one to manage the “entity type”, which [0044] as published states examples including that this refers to a description of a process or organization whose performance over time may be evaluated.
Claim 7 narrows the abstract idea by further having attributes, associated KPIs, filters, relations, and plans. Claim 7 also has additional elements in that there are data repository definitions to “configure access” to a data source and a data sink. This is viewed as “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2B.
Claim 8 narrows the abstract idea by giving a list of alternative “attributes” that can be included in the KPI, definition which is viewed as just describing the data.
Claims 9-11 narrow the abstract idea by stating the various mathematical/logical operations that will occur (as in claim 2), and which are child/parents relative to each other in claims 9-10. Examiner notes claim 1 only recites “corresponding to one operation selected from a list of operations”, such that the “list” in claim 10 is considered an alternative list of operations.
Claims 12-13 narrow the abstract idea by including temporal and spatial data that is needed for the desired KPI mathematical calculation.
Claims 14-15 have additional element naming one of a number of alternative computer components included as the “data source” in claim 14 or “data sink” in claim 15. This is viewed as “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong 2 and step 2B.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
Examiner’s suggestions for overcoming 101 [though many 112b issues remain] – focusing on explicitly reciting that there is a computer, that the computer executes the plan [so the “plan” isn’t a future item that never occurs], and focusing on a technological problem and solution – [e.g. maybe [0065] – detect out-of-sync data in data sources; delay in data sources; [0067 – configure plan to eliminate redundancy; 0068 - A filter's expression is transpiled, or converted, from its declaration in the inventory (303) to an expression in a format executable by module (101). This transpilation process aims to reduce the time an expression needs to be evaluated, so it is not interpreted by the plan execution module (101), but executed. ]
Examiner’s suggestion here is the starting point, to clarify things are actually executed by a computer:
A computer system comprising storage for the computer, executing instructions comprising:
calculating Key Performance Indicator (KPI)
a plan execution module, executed by the computer,:
execute a plan for accessing a collection of data sources, and executing operations for how data sources are accessed;
calculating at least one KPI on the delay between data generation from the data source to storage in a data sink;
a plan generator module, executed by the computer, configured to generate sets of instructions based on [0048, 0067 as published] based on a new KPI definition and data source access configurations to configure a plan to eliminate redundancy in accessing the data sources…
[then further extensive amendments need to occur in the current last paragraph, based on the above and the 112b issues].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6, 8, 11, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Simon (US 2011/0131199) and Park (US 2017/0116210).
Concerning claim 1, Simon discloses:
A Key Performance Indicator (KPI) unit calculator for calculating KPI (Simon – see par 292-0294 - the content of this disclosure, one of ordinary skill in the art will understand the manner in which a software program can be launched from a computer-readable medium (1222, such as memory) in a computer-based system (processor 1202) to execute the functions defined in the software program.) of a processing system (Simon – see par 2 - goal of operational Business Intelligence (BI) is to help organizations improve the efficiency of their business by giving users information that can be used to make better operational decisions. Operational BI reporting contributes to this goal by embedding analytics and reporting information into workflow applications so that the business user has information (e.g., contextual and business data) on which to base a variety of decisions. The creation and querying of customized virtual database schemas over a set of distributed and heterogeneous data sources can provide input to operational BI reports. See par 19 -compact query plan enables rapid traversal of a simplified query tree, increasing the speed of processing, and reducing the amount of memory used; see par 37 - In operational BI reporting applications, target schemas often have a "star"-like configuration, which distinguish fact tables from dimension tables. Fact tables can either be measures (in the traditional sense of multi-dimensional data modelling), such as sales-unit or sales-dollar, or entity data that are described using multiple dimensions), comprising modules:
-a plan execution module comprising processing means (Simon – see par 292-294 - the content of this disclosure, one of ordinary skill in the art will understand the manner in which a software program can be launched from a computer-readable medium (1222, such as memory) in a computer-based system (processor 1202) to execute the functions defined in the software program) adapted to process a plan for calculating at least one KPI, wherein the plan is a collection of nodes, each node corresponding to one operation selected from a list of operations ([0047] as published states “Plan (102) is illustrated in FIG. 2, as a graph (200) which describes the steps needed to execute the plan: execution starts at the nodes with no connections to them (inputting data from data sources (103) as per the previous example) and finishes at the ones with no connections from them (outputting data to data sinks (104) as per the previous example).” [0064] as published states “A Plan is defined by a collection of nodes, each corresponding to one of aforementioned operations, while a Configurable Plan is a wrapper providing the plan with a generic configuration object for all or some of its nodes such as, but not limited to, data source access configurations.”
Simon discloses the limitations based on broadest reasonable interpretation in light of the specification – see FIGS. 3-9 – using various nodes and operations such as par 21 - The CQP has source nodes that include scan operations to source tables; singleton nodes that include a single operation selected from Aggregate, Union, Order by, null accepting Full Outer Joins (FOJs); and Abstract nodes that include a set of operations selected from Cartesian Product, Evaluation, Filter, Left Outer Join (LOJ) and null rejecting FOJs.: see par 28 - a new model to represent the execution plan of a query, called the CQP, is introduced. This model can be viewed as the compact normal form of an original query that groups all of the database operations that could possibly be permuted into macro-nodes. A "classical query processing tree" is a tree comprising the following nodes (operators): (Inner) Join, Filter, Evaluation, LOJ, FOJ, Aggregate Group by, Order by, and Union. See par 33, 35 - Wrappers expose the metadata relational schema of the data sources called source tables. The Query Engine (QE) then provides an SQL interface to express multi-source queries referring to source tables or target tables (i.e., tables belonging to target schemas). See par 35 - At the time of executing a multi-source SQL query by the Query Engine, the query is first unfolded using the mapping definition of the target tables and then decomposed into a set of sub-queries. The sub-queries are processed by the wrappers and an assembly query that is processed by the QE using the results returned by the sub-queries. This decomposition is called a query processing plan, and represents the original query plan; see par 39 - Customer data can be co-located with order data, while Customer Support data can be partitioned into regional databases. In this example, this means that the mapping definition of the Customer table will include a first level of union operations (disclosing an operation) to address horizontal partitioning and then a level of join operations (join, outer joins) to address vertical partitioning (disclosing another operation));
-a plan generator module configured to generate a plan; wherein the plan comprises instructions to: i.) access to raw data on data sources of the processing system (Simon - see par 40 - we define an original query processing plan P (or, simply original query plan) for a query Q as comprising a tree having the following nodes (operators): (Inner) Join, Filter, Evaluation, LOJ, FOJ, Aggregate Group by, Order by, and Union., ii.) process the raw data (Simon – see par 40 - An operator takes as input one or more data streams and produces an output data stream. The edges in the query processing plan represent the data flow among the operators. The "Evaluation" operator takes as input one table R(A1, . . . , An) and produces one table R'(A1, . . . , An, E) where E is a calculated column associated with a function f that takes as arguments a subset of the columns A1, . . . , An), iii.) and send an output to at least one data sink … (0047] as published states “Data sink (104) can be one or more databases, filesystems, other computer readable storage mediums, or other applications or computer systems such as, but not limited to, messaging systems” – Simon – see par 49 - An operator takes as input one or more data streams and produces an output data stream. see par 253-254 – FIG. 10 is apparatus and system; the apparatus 1000 also comprises an analysis module 1018 to couple to the processing node 1014. The analysis module 1018 can be used to transform the original query plan into an equivalent executable CQP to store on a machine readable device (e.g., the storage nodes 1030, and/or the memory in the processing node 1014). The CQP may be stored in one or more databases 1026. see par 257 - apparatus 1000 may comprise one or more desktop computers, for example, clients, servers, or even multiple processing nodes 1014 that operate to receive the original query plan, and then to process the original query plan. see par 258 - the apparatus 1000 includes a display 1038 to display output from the apparatus 1000 to an end-user).
To any extent Simon does not disclose sending output from calculating KPIs and plan to data sink, Park discloses:
-A plan generator module configured to generate at least one plan; wherein a plan comprises instructions to: i.) access to raw data on data sources of the processing system, iii.) “and send an output to at least one data sink” (Park – see FIG. 2 – event source, to CQL to output stream to event sink 210, 212; See par 63 - When the CQL query is started, for example, by issuing an “alter query <queryname> start” DDL, the logical query plan may be converted to a physical query plan. In one example, the physical query plan may be represented as a directed acyclic graph (DAG) of physical operators. Then, the physical operators may be converted into execution operators to arrive at the final query plan for that CQL query. See also par 168)
Simon and Park disclose:
-at least one data source (Simon – see par 32 - In order to facilitate the deployment of operational BI reports, the Semantic Layer attempts to provide rapid creation of data models from multiple data sources; see par 33 - An EII system may be implemented as middleware that includes wrappers and a query engine. Wrappers expose the metadata relational schema of the data sources called source tables. A wrapper describes the capabilities of the underlying data source in terms of, for example, SQL query processing over the source tables.;
-the at least one data sink ([0047] as published states “Data sink (104) can be one or more databases, filesystems, other computer readable storage mediums, or other applications or computer systems such as, but not limited to, messaging systems”
“and send the output to data sinks” (Park – see FIG. 2 – event source, to CQL to output stream to event sink 210, 212; See par 63 - When the CQL query is started, for example, by issuing an “alter query <queryname> start” DDL, the logical query plan may be converted to a physical query plan. In one example, the physical query plan may be represented as a directed acyclic graph (DAG) of physical operators. Then, the physical operators may be converted into execution operators to arrive at the final query plan for that CQL query. See also par 76 - Examples of event sources include, without limitation, an adapter (e.g., JMS, HTTP, and file), a channel, a processor, a table, a cache, and the like. Examples of event sinks include, without limitation, an adapter (e.g., JMS, HTTP, and file), a channel, a processor, a cache, and the like. See also par 168).
Simon discloses having an optimization strategy decomposed into stages that are processed sequentially (See par 59) and having query simplification techniques, by exploiting dependencies between variables and behavior with respect to null values (See par 60) and then transforming the original query plan into an equivalent executable CQP (compact query plan) where operations executed in a different order from original query plan based on upward compatibility (See par 268-270).
Park discloses “recovery” and related limitations:
wherein the plan generator module is further configured to automatically generate a recovery-detection plan, distinct from the plan (Park – see par 73 – event recovery module 126; see par 89 - As noted above, the event processing system (e.g., 200) may be configured to execute queries in a continuous manner over potentially unbounded, real-time data streams. For example, the event processing system can receive one or more data streams, register a query against the data streams, and continuously execute the query as new data appears in the streams.
see par 95 - In the event of system failure, only the events that have occurred after the checkpoint marker event need to be re-processed. Thus, upon recovery of the system, only the events that have occurred before the failure and after reconciling the state to the checkpoint marker event need to be re-processed and replayed. The manner in which the event processing system processes batches of events using checkpoint marker events is discussed in detail in relation to FIG. 3), the recovery-detection plan comprising instructions to perform:
(a) access sequence numbers or timestamps from each data source for a given time interval (Park – see par 34 - the time information associated with an event may be used to ensure that the events in the event stream arrive in the order of increasing timestamp values. This may enable events received in the event stream to be ordered based upon their associated time information. In order to enable this ordering, timestamps may be associated with events in an event stream in a non-decreasing manner such that a later-generated event has a later timestamp than an earlier-generated event),
(b) compare the accessed sequence numbers or timestamps with previously stored values in an inventory module (Park – see par 38 - a stream may be the principle source of data that CQL queries may act on. A stream S may be a bag (also referred to as a “multi-set”) of elements (s, T), where “s” is in the schema of S and “T” is in the time domain. Additionally, stream elements may be tuple-timestamp pairs, which can be represented as a sequence of timestamped tuple insertions. In other words, a stream may be a sequence of timestamped tuples. In some cases, there may be more than one tuple with the same timestamp. And, the tuples of an input stream may be requested to arrive at the system in order of increasing timestamps), and
(c) upon detecting a sequence number or timestamp greater than the previously stored value for a given period (Park – see par 109 - To reconcile and/or reconstruct the state from log based storage 322, the logs have to be replayed from the start to the desired point. Such an approach may not be desirable for fast recovery. In order to provide more efficient recovery, in one embodiment of the present disclosure, the logs may include full snapshots in a pre-determined duration and separate synopsis snapshots may be generated to reconcile the state from log based storage. In other embodiments, the synopsis for a range window operator may be reconstructed by replaying the events since essentially the synopsis of the range window operator requires the same set of events as the input events after reconstructing a full snapshot. This approach may also reduce the amount of information stored in the synopsis logs; see par 110 - In the event of failure, only the events that have occurred after the checkpoint marker event need to be re-processed. Thus, upon recovery, only the input events that have occurred before the failure and after reconciling the state to the checkpoint are re-processed and replayed).
Simon and Park disclose:
automatically trigger generation and execution of a new collection plan for an affected period and replace the plan, thereby ensuring recalculation of KPIs for periods with late-arriving data (Applicant’s [0048] as published states “KPI definition (301) is comprised of attributes including, but not limited to, the KPI's name, the name of the managed entity type (MET) it refers to, periodicity, delay (time difference between the expected availability of raw data and the time period it refers to), its formula or expression, aggregations and any associated filters.”
Simon – see par 56 - It may thus be useful to find a CQP that reduces the value of dps(P(Q)) with respect to the original query plan. Reduction does not necessarily produce the lowest cost query processing plan, but it often provides a good approximation for at least two reasons. First, data transfer often turns out to be a dominant cost factor in query processing by an EII. This is more in evidence for operational BI queries that may access very large tables. Second, in cases where there exists a query plan with a small data processing set (e.g., narrow queries), such a (reduced) plan provides an assembly query that can be run quickly, without further ordering of operations. Derivative query plans with a small data processing set can provide a dramatic improvement in terms of performance. See par 59 - They are oriented toward providing a low worst case time complexity (linear or polynomial), and low memory consumption, so as to favor "in place" transformations that avoid the cloning of query plans (costly in terms of memory space). In most embodiments, the search for semi-join reducers precedes the ordering of joins. Although this approach will not necessarily produce the best query plan in all cases, it usually reduces the size of the data processing set. The following stages will now be described: operation simplification and push-down, searching for maximal sub-queries, and semi-join data provider reduction.
Park –see par 61 - the JMS may queue things up and, if things back up it's okay while the engine is doing a query because it can catch up later and it doesn't have to worry about whether it's synchronous. If it's not here, listening, it won't miss it, it just gets queued until the engine comes back, as long as it has its listener established. see par 111 - upon recovery, the state of the system rewinds to the checkpoint marker event before the failure. In one example, the reader offset is rewound to the location stored in the snapshot and the reader offsets are used to read the same set of input events for the snapshot before the failure. See par 112 - It is desirable, however, to achieve precise recovery of events in which downstream clients see exactly the same stream of events that would have been produced if no upstream failure had occurred and no missed events and duplicate events were allowed. See par 113-114 - One technique of providing precise recovery is to use output queue trimming. As described herein, ‘output queue trimming’ refers to proactively discarding queued events by the system when the system determines that the events are no longer needed for recovery. This enables the secondary servers to “trim” their buffer of output events so that it contains only those events that have not been sent by the primary server at a particular point in time. This allows the secondary server to avoid missing any output events when there is a failover, since events are only trimmed after they have been sent by the current primary server).
Both Simon and Park are analogous art as they are directed to analyzing information from databases (see Simon Abstract, par 2, 37, 41; Park Abstract, par 36-37 – stock ticker with price). Simon discloses producing an output data stream (See par 49), storing a CQP (compact query plan) (See par 253-254) and displaying output to an end-user (See par 257-258). Simon discloses having an optimization strategy decomposed into stages that are processed sequentially (See par 59) and having query simplification techniques, by exploiting dependencies between variables and behavior with respect to null values (See par 60) and then transforming the original query plan into an equivalent executable CQP (compact query plan) where operations executed in a different order from original query plan based on upward compatibility (See par 268-270). Park improves upon Simon by disclosing having a sink (See FIG. 2, par 63, 168) and having a recovery for the system using checkpoint markers (See par 95), and only using input events before a failure for reconciling the system after a failure using the checkpoints (See par 110) and pursuing recovery with no missed events and “trimming” a buffer of events (See par 112-114). One of ordinary skill in the art would be motivated to further include having a sink and having recovery to efficiently improve upon the outputs in Simon.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the query plans in Simon, to further include sinks and recovery processing as disclosed in Park, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning claim 2, Simon discloses:
The KPI unit calculator according to claim 1, further comprising the inventory module programmed to generate KPI definitions and to collect metadata from the processing system ([044] as published states “The attributes of a MET are mapped to those defined in one or more data source's metadata—that is, attribute A of a data source corresponds to attribute X of a MET—linking in this way the raw data of a system to its abstraction as a managed entity type.” [0048] as published – metadata 304
[0048 as published states “KPI definition (301) is comprised of attributes including, but not limited to, the KPI's name, the name of the managed entity type (MET) it refers to, periodicity, delay (time difference between the expected availability of raw data and the time period it refers to), its formula or expression, aggregations and any associated filters. For the rest of the information, plan generator (302) accesses inventory (303), from where it extracts metadata (304) for all the objects deemed pertinent and the relations between them.” Simon discloses the limitations based on broadest reasonable interpretation in light of the specification –See par 30 - A typical operational BI architecture distinguishes three main logical layers: a Data Source Layer that comprises all the required data sources needed by operational BI reporting; a Semantic Layer that provides a layer of virtual "business objects”; See par 31 - The data access functionality stands at the bottom level, and provides a unified interface to retrieve metadata and query the set of distributed and heterogeneous data sources. see par 39 - Consider a Customer dimension table with attributes such as identification (ID), name, address, home-phone, nation-name, etc. Vertical partitioning may occur because the attributes of a customer originate from multiple source tables (e.g., detailed data coming from Customer Support). For instance, Customer data can be co-located with order data, while Customer Support data can be partitioned into regional databases. In this example, this means that the mapping definition of the Customer table will include a first level of union operations to address horizontal partitioning and then a level of join operations (join, outer joins) to address vertical partitioning.) ; and
wherein, the plan generator is further configured to generate the plan based on the KPI definition and the metadata extracted from the inventory module (Simon – See par 49 - we define an original query processing plan P (or, simply original query plan) for a query Q as comprising a tree having the following nodes (operators): (Inner) Join, Filter, Evaluation, LOJ, FOJ, Aggregate Group by, Order by, and Union. An operator takes as input one or more data streams and produces an output data stream. see par 170-171 – CQP (Compact Query Plan) involves construction of maximal source sub-queries; metadata-based capabilities, which overwrite an SQL capability depending on the tables and columns to which the operations are applied. This is because SQL-based capabilities describe the evaluations (functional expressions) that can be computed by a data source).
Concerning claim 3, Simon discloses:
The KPI unit calculator according to claim 2, wherein the inventory module further comprises memory means adapted to store plans generated by the plan module generator (Simon – See par 254, FIG. 10 - analysis module 1018 can be used to transform the original query plan into an equivalent executable CQP to store on a machine readable device (e.g., the storage nodes 1030, and/or the memory in the processing node 1014). The CQP may be stored in one or more databases 1026; see par 285-286, FIG. 11 – from Compact Query Plan (CQP) , compute semi-join reductions to provide Derivative Query Plan (DQP) an store the DQP on a machine readable device at block 1153).
Concerning claim 6, Simon discloses:
The KPI unit calculator according to claim 2, wherein the inventory module comprises processing means (Simon – see par 292-0294 - the content of this disclosure, one of ordinary skill in the art will understand the manner in which a software program can be launched from a computer-readable medium (1222, such as memory) in a computer-based system (processor 1202) to execute the functions defined in the software program) adapted to manage at least one managed entity type (MET) ([0044] as published - a managed entity type (MET) is a description of a system, device, process or organization whose performance over time may be evaluated) (Simon – see par 37 - Fact tables can either be measures (in the traditional sense of multi-dimensional data modelling), such as sales-unit or sales-dollar, or entity data that are described using multiple dimensions, such as a customer or an archive box. Indeed, customer data can be that subject of analysis that is described using different dimensions (e.g., location, organization, market position (disclosing entity type); See par 39 - Customer data can be co-located with order data, while Customer Support data can be partitioned into regional databases. In this example, this means that the mapping definition of the Customer table will include a first level of union operations to address horizontal partitioning and then a level of join operations (join, outer joins) to address vertical partitioning; see par 54 - Usually, the query parameters represent filters on dimension tables, such as a customer ID value, a region, a quarter or a range of dates, a product ID, etc. One or more of these filters can be quite selective, since it may correspond to the specific context of a particular instance of a business process.).
Concerning claim 8, Simon discloses:
The KPI unit calculator according to claim 2, wherein a KPI definition is comprised of attributes including, a name of the KPI, a name of a managed entity type (MET) it refers to, periodicity, delay define as a time difference between an expected availability of the raw data and the time period it refers to, a formula or expression, aggregations and any associated filters (Claim is viewed as an alternative of attributes
Simon discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 31 - The data access functionality stands at the bottom level, and provides a unified interface to retrieve metadata and query the set of distributed and heterogeneous data sources. see par 39 - Consider a Customer dimension table with attributes such as identification (ID), name, address, home-phone, nation-name, etc. Vertical partitioning may occur because the attributes of a customer originate from multiple source tables (e.g., detailed data coming from Customer Support). For instance, Customer data can be co-located with order data, while Customer Support data can be partitioned into regional databases. In this example, this means that the mapping definition of the Customer table will include a first level of union operations to address horizontal partitioning and then a level of join operations (join, outer joins) to address vertical partitioning;
Park – see par 28 - Complex Event Processing (CEP) provides a modular platform for building applications based on an event-driven architecture. At the heart of the CEP platform is the Continuous Query Language (CQL) which allows applications to filter, query, and perform pattern matching operations on streams of data using a declarative, SQL-like language. see par 55-56 - a window size for a given archived relation may be specified by a user. A window, in some aspects, in relation to an archived relation, may include a node in a query graph that analyzes or otherwise evaluates incoming streamed content. In other words, the window may define the amount of streamed content that be analyzed and/or processed by the query engine and/or the amount of historical data that will be included in the archived relation; see par 79 - Continuous queries typically perform filtering and aggregation functions to discover and extract notable events from the input event streams).
Concerning claim 11, Simon discloses:
The KPI unit calculator according to claim 1, wherein the plan generator module comprises processing means programmed to generate a plan by establishing relations between operations of the list of operations, which are connected in such a way to calculate one or more KPIs (Simon – see par 49 - an original query processing plan P (or, simply original query plan) for a query Q as comprising a tree having the following nodes (operators): (Inner) Join, Filter, Evaluation, LOJ, FOJ, Aggregate Group by, Order by, and Union. An operator takes as input one or more data streams and produces an output data stream. The edges in the query processing plan represent the data flow among the operators. The "Evaluation" operator takes as input one table R(A1, . . . , An) and produces one table R'(A1, . . . , An, E) where E is a calculated column associated with a function f that takes as arguments a subset of the columns A1, . . . , An. ; see par 131 - It is noted here that the term "blocks" is used interchangeably herein with the term "sets", both meaning a collection of objects--in this case, the objects normally comprise operations. The concept of precedence relationships, represented by precedence links, or "p-links", are introduced to determine the ordering constraints under which the blocks of an abstract node should be executed; see FIG. 3, par 140-141 – showing compact query plan (CQP) with nodes, and different operations (e.g. LOJ (left outer join), FOJ (full outer join), C (Cartesian product – lower right of FIG. 3), E (evaluation – at top of FIG. 3); see also FIG. 6, 7, 9 – alternative operations and nodes and relationships for generating KPI).
Concerning claim 13, Simon discloses customer have a “location” dimension (see par 37); and having aggregate operation (See par 49). Simon discloses that query parameters represent filters on dimension tables, such as “a region, a quarter or a range of dates, a product ID, etc.” (See par 54).
Park discloses:
The KPI unit calculator according to claim 10, wherein in case temporal and spatial aggregations are to be applied, the plan generator module generates aggregate operations (Park – see par 39 - For example, BI may be focused on periodic queries of historic data. As such, it may have a backward-looking focus. However, BI may also be placed into operational applications, and it may therefore expand from a mere strategic analytical tool into the front lines in business operations. As such, BI systems may also be configured to analyze event streams and compute aggregates in real time. see par 152 - The output from the Window operator is a set of events that can be used for further processing such as joining event streams or calculating aggregate functions like sum and average. For instance, a window operator can collect all events (e.g., sales orders for a product) placed in the last hour and output the average value of the order once every hour. The Aggr operator is an operator that can compute an aggregate function such as sum, average, count, max on a set of events of an event stream. The groupBy operator refers to an operator than can perform the grouping and aggregation of events in an event stream.).
It is obvious to combine Simon and Park for the same reasons as claim 1 above.
Simon discloses customer have a “location” dimension (see par 37); and having aggregate operation (See par 49). Simon discloses that query parameters represent filters on dimension tables, such as “a region, a quarter or a range of dates, a product ID, etc.” (See par 54). Park improves upon Simon by disclosing aggregating data. One of ordinary skill in the art would be motivated to further include having aggregated data to efficiently improve upon the “location” dimension and the aggregate operation and the possibility of filtering by “region” and “range of dates” in Simon.
Concerning claim 14, Simon discloses:
The KPI unit calculator according to claim 1 wherein the at least one data source is one or more databases, filesystems or other computer readable storage mediums where data pertaining to one or more processing systems is stored (Simon –See par 262, FIG. 10 - multiple storage nodes 1030 may be used to store multiple databases 1026 that are processed as a result of executing the CQP (Compact Query Plan), or a derivative of the CQP. see par 301 - implementing the apparatus, systems, and methods described herein may operate to render the processing of large data files more efficiently, providing higher performance and a simplified desktop experience).
Concerning claim 15, Simon and Park disclose:
The KPI unit calculator according to claim 2, wherein the at least one data sink is one or more databases, filesystems, other computer readable storage mediums, or other applications or computer systems (Park – see par 74 - The notable events may then be sent to one or more event sinks (210, 212) in the form of one or more output event streams. For example, in FIG. 2, EPS 202 outputs a first output event stream 226 to event sink 210, and a second output event stream 228 to event sink 212; see par 76 - Examples of event sinks include, without limitation, an adapter (e.g., JMS, HTTP, and file), a channel, a processor, a cache, and the like).
It is obvious to combine Simon and Park for the same reasons as claim 1 above.
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Simon (US 2011/0131199) and Park (US 2017/0116210), as applied above to claims 1-3, 6, 8, 10-11, and 13-15, and further in view of Chamieh (US 2019/0146970).
Concerning claim 4, Simon discloses having metadata (See par 31) and attributes of customers (See par 39) and “revising” the “CQP” (Compact Query Plan) (See par 273-275).
Chamieh discloses:
The KPI unit calculator according to claim 3, wherein the plan generator module is configured to check the inventory module for plans that share characteristics of the at least one KPI, prior to generating a new plan ([0066] as published states Graph (700) in FIG. 7 illustrates the connections between the operations of what could be a plan to calculate one or more KPIs. In embodiments, the generation of such a plan starts with the definition of a KPI, as per module (300) of FIG. 3. Considering a KPI expressed by the formula A$x+B$y, where “A” and “B” are data sources, “x” and “y” are counters and “$” is a separator character denoting “x” belongs to “A” and “y” belongs to “B”, a plan like the one depicted by graph (700) could be generated by module (302) as its definition is read from inventory (303).” 0074 as published states “after plan (305) is generated by module (302), it is saved in inventory (303). When handling the creation of a new KPI definition, module (302) needs to check inventory (303) for plans that share the characteristics of that KPI, namely its managed entity type, period and delay
Chamieh discloses the limitations based on broadest reasonable interpretation in light of the specification – See par 52 - Thus, the query plans are connected (also referred to as “overlap”) in that they share at least a node. The query plans can also share more than one node (e.g., a subgraph of two or more nodes and one or more edges). For there to be one or more shared nodes, at least one query plan operation must be the same in more than one query plan. One embodiment supports one of the query plans being generated and executed prior to another of the query plans being generated and executed.),
such that if a plan exists, the new plan is generated with all its KPIs plus a new one (Chamieh – See par 52 - where a first query plan is already generated and kept in memory after execution, then the generation of a second query plan does not require creating those one or more nodes (and possibly one or more subgraphs of nodes and edge(s)) that are already in the first query plan and can be shared because they are the same; the generation of the second query plan reuses (more specifically, “incorporates”) those of the one or more nodes (and possibly one or more subgraphs) from the first query plan that are the same.); replace the plan ([0074 as published states “after plan (305) is generated by module (302), it is saved in inventory (303). When handling the creation of a new KPI definition, module (302) needs to check inventory (303) for plans that share the characteristics of that KPI, namely its managed entity type, period and delay. If such a plan exists, then a new plan is generated with all these KPIs, plus the new one, and the old plan is replaced. The edition or removal of a KPI will also force the generation of a new plan.” Chamieh – see par 72 - In one embodiment, for each of the logical query plans, the query plan connector 232 determines whether the required physical query plan can be generated by reusing or incorporating into the required physical query plan, one or more of the nodes and/or subgraphs (as well as, in some embodiments, entire directed graphs) already in the physical query plans 242 that are currently being kept in memory (i.e., in volatile memory, non-volatile memory, and/or combinations thereof) after execution. If the query plan connector 232 determines that reuse or incorporation is possible for a given logical query plan, then only the missing part(s) (if any) for the physical query plan (be it one or more nodes, edges, and/or subgraphs) are added to the physical query plans 242 and connected by one or more edges to the one or more nodes and/or subgraphs (as well as, in some embodiments, entire directed graphs) that were determined to be reusable.),
wherein, upon detection by the recovery-detection plan of late-arriving data for a previously collected period, the plan generator module is further configured to generate a new collection plan for that period and replace the prior plan (same as in claim 1 – which recites “a new collection plan” - Simon – see par 56 – derivative quality plan can provide improvement in terms of performance; See par 59 ; Park –see par 61; see par 111-114), thereby ensuring KPI completeness despite out-of-order data ingestion (Simon – see par 56 - derivative quality plan can provide improvement in terms of performance; See par 59 ; Park –see par 61; see par 111-114).
Both Simon and Park are analogous art as they are directed to analyzing information from databases related to businesses (see Simon Abstract, par 2, 37, 41; Park Abstract, par 36-37 – stock ticker with price; Chimieh Abstract, par 48, 88, FIG. 3); In addition, Simon discloses having metadata (See par 31) and attributes of customers (See par 39) and “revising” the “CQP” (Compact Query Plan) (See par 273-275). Chamieh improves upon Simon and Park by checking for plans that “share” nodes, reusing parts of plans, and adding to them accordingly. One of ordinary skill in the art would be motivated to further include consideration of shared nodes and reusing plans to efficiently improve upon the query plans in Simon and the recovery processing in Park.
Concerning claim 5, Simon discloses:
The KPI unit calculator according to claim 4, wherein the characteristics of the KPI relates to entity type… (Simon – see par 37 - Fact tables can either be measures (in the traditional sense of multi-dimensional data modelling), such as sales-unit or sales-dollar, or entity data that are described using multiple dimensions, such as a customer or an archive box. Indeed, customer data can be that subject of analysis that is described using different dimensions (e.g., location, organization, market position (disclosing entity type), . .).
Simon discloses that queries can be processes within a range of 20 seconds to 2 minutes (See par 54).
Park or Chamieh disclose:
KPI unit calculator according to claim 4, wherein the characteristics of the KPI relates to entity type, “period or delay” (Park – see par 95 - The processing of events in event batches as discussed above results in improved system performance since only the checkpoint marker event in each event batch is processed, rather than processing all the individual events in an event batch. In the event of system failure, only the events that have occurred after the checkpoint marker event need to be re-processed.
Chamieh – See par 59 - Different embodiments may determine when to make the indication “inactive” differently (e.g., the connection corresponding to that SQL query has been closed; the client who submitted that SQL query has indicated that the query is no longer of interest; a fixed or programmable period of time has passed). Also, different embodiments may perform the actual removal at different times (e.g., immediately, after a fixed or programmable period time, when a threshold amount of memory is exceeded by the query plans and TTs in memory, as part of normal garbage collection operations; see par 62 - updating is delayed until one or more events occur (e.g., a need to send a query result (e.g., initial or incremental) to a client, a fixed amount of time elapses, a programmable amount of time elapses, a calculated amount of time based the nodes and edges (e.g., based on the nodes' connectedness to other nodes, the types of the nodes, their historical use, etc.) elapses; see par 154 – time of last refresh field; timestamp).
It is obvious to combine Simon and Park and Chamieh for the same reasons as claim 1 and 4 above.
Claims 7 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Simon (US 2011/0131199) and Park (US 2017/0116210), as applied above to claims 1-6, 8, 10-11, and 14-15, and further in view of Dumant (US 2018/0173750).
Concerning claim 7, Simon discloses that once the Original Query Plan is transformed to a Compact Query Plan (QCP) it is “stored” in memory (See par 270-272), and then if the CQP is of an acceptable size or complexity, it can then be executed at 1137 (See par 278, FIG. 11). Park discloses having event sources (par 74, FIG.2 - 204, 206, 208) where one event in an event stream can be a price of a stock symbol changed (See par 33).
Dumont discloses:
The KPI unit calculator according to claim 6, wherein the MET is identified in the inventory module by a name (Dumont – See par 24 - Semantic layer designer 130 maps logical entities of the relational schema to a set of abstract entities known as business objects. The business objects and their mappings comprise a semantic layer, which is defined in metadata of BIL runtime 140. See par 25 - The business objects may represent business entities, such as customers, time periods, financial figures, etc. See par 35 - a BIL entity generalizes the notion of entity set in Entity Relationship (“ER”) model or tuple set in relational algebra. Similar to an entity that has named attributes or a table that has named columns, a BIL entity may have named properties (also sometimes referred to as attributes). Note however, that a property of a BIL entity is itself an arbitrary entity, so BI entities can be arbitrarily nested; See par 38, FIG. 2 – BIL entity 220, named entity 230)
Simon, Park, and Dumont disclose:
the MET comprising one or more attributes (Simon – see par 37 - Fact tables can either be measures (in the traditional sense of multi-dimensional data modelling), such as sales-unit or sales-dollar, or entity data that are described using multiple dimensions, such as a customer or an archive box. Indeed, customer data can be that subject of analysis that is described using different dimensions (e.g., location, organization, market position (disclosing attributes of entity type
See also Dumont par 35 – BIL may have…. properties/attributes ), one or more KPIs, filters (Simon – see par 54 - the query parameters represent filters on dimension tables, such as a customer ID value, a region, a quarter or a range of dates, a product ID, etc. One or more of these filters can be quite selective, since it may correspond to the specific context of a particular instance of a business process. For instance, the customer ID of the caller in a self-service system will be relatively specific, although the region to which the customer belongs is not.), relations to other METs (Simon – see par 31 - The data foundation functionality may stand at the middle level, to enable the creation of multiple entity-relationship models from the metadata exposed by the data access layer. The business object functionality enables the creation of so-called "business objects" (such as measures, dimensions, details, etc) that can be freely composed to create ad-hoc business object (BO) user queries that are consumed by the consumption tools (e.g., reporting or dashboarding tools)., one or more associated plans, a relation to the at least one data source and to data repository definitions to configure access the at least one data source and the at least one data sink (
Park – see par 39 - In some examples, business intelligence (BI) may help drive and optimize business operations at particular intervals (e.g., on a daily basis in some cases). This type of BI is usually called operational business intelligence, real-time business intelligence, or operational intelligence (OD. Operational Intelligence, in some examples, blurs the line between BI and business activity monitoring (BAM). For example, BI may be focused on periodic queries of historic data. See par 56 - At a high level, once a window is applied on a Stream it becomes a Relation and then regular relational logic may be applied, as with relational databases. As tuples arrive and leave the window, the Relation under consideration changes with queries compiled against it emitting results at the same time. see par 65 - . The databases 112 may be relational databases, SQL servers, or the like and may, in some examples, manage historical data, event data, relations, archived relations, or the like on behalf of the users 102.
Dumont – see par 24 - Semantic layer designer 130 maps logical entities of the relational schema to a set of abstract entities known as business objects. The business objects and their mappings comprise a semantic layer, which is defined in metadata of BIL runtime 140. The BIL runtime 140 may use semantic layer information and the data foundation (or data model) to translate a BIL query into native queries and to process the results. see par 27 - BIL runtime 140 receives a BIL query from client 120 and creates a calculation plan based on the mappings which bind the semantic layer to the logical entities of the relational schema of data store 110 (sometimes named data foundation or data model). The calculation plan mixes local computations with zero, one, or more SQL queries. The queries may depend on each other, in the sense that a given query can information provided as the result of another query. The calculation plan defines in which order local computations and SQL queries should be executed. SQL database server 150 receives the corresponding SQL queries and, based on its knowledge of the relational schema and its underlying physical entities, creates query plans to be executed by data store 110 (disclosing configuring… for data source). The BIL runtime 140 formats the included data based on the semantic layer, and provides the thusly-formatted dataset to client 120 (disclosing configuring… for data sink).)
Simon and Park and Dumant are analogous art as they are directed to analyzing information from databases related to businesses (see Simon Abstract, par 2, 37, 41; Park Abstract, par 36-37 – stock ticker with price; Dumant Abstract, par 24-25, 53-54 – business intelligence… output of “revenue” for countries/products). Simon discloses that once the Original Query Plan is transformed to a Compact Query Plan (QCP) it is “stored” in memory (See par 270-272), and then if the CQP is of an acceptable size or complexity, it can then be executed at 1137 (See par 278, FIG. 11) and having a “multiple entity relationship model” (See par 31). Park discloses having event sources (par 74, FIG.2 - 204, 206, 208) where one event in an event stream can be a price of a stock symbol changed (See par 33) and improves upon Simon by disclosing “relations” between event sources, streams, and event sinks (See FIG. 2). Dumant improves upon Simon and Simon by disclosing having named business entities (See par 25, 35, 38), where entities can be customers that have “properties/attributes” (See par 35), and further uses mappings to form a relational scheme and create query plans (See par 27). One of ordinary skill in the art would be motivated to further include explicitly having computer components to send results of the querying to efficiently improve upon the outputs in Simon.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the query plans in Simon and Park, and to further have names for entities as well as configuring as disclosed in Dumant since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning claim 9, Simon discloses that there is a Customer dimension table with attributes such as identification (ID), name (See par 39).
KPI unit calculator according to claim 2, wherein the operation associated to each node of a plan is defined by…, its parent operations and its child operations ([0054] as published states “As illustrated in the class diagram in FIG. 5, an operation is defined by its name, its parent operations and its child operations. Every operation defined in module (101) is an extension of the operation in FIG. 5, inheriting in this way the aforementioned attributes. In embodiments, an operation can compute its output as a list of rows from a table, where each entry has a name, type and value associated. An operation output is used as input of the operation's children, but it is not obligatory for an operation to have parents or children.”.
Simon – see par 21 - The CQP has source nodes that include scan operations to source tables; singleton nodes that include a single operation selected from Aggregate, Union, Order by, null accepting Full Outer Joins (FOJs); and Abstract nodes that include a set of operations selected from Cartesian Product, Evaluation, Filter, Left Outer Join (LOJ) and null rejecting FOJs. In the CQP, the children of an Abstract Node can be source nodes or singleton nodes. The CQP contains all the information that is necessary to generate a query tree equivalent to the original query plan. see par 107-137, FIGS. 3-4 – talks about parents and children and operations in a query path (e.g. FOJ = Full Outer Joins; LOJ = Left outer join)).
Simon discloses that there is a Customer dimension table with attributes such as identification (ID), name (See par 39). Park discloses “ an event stream may represent an occurrence of some worldly event (e.g., when a temperature sensor changed value to a new value, when the price of a stock symbol changed)” (See par 33) and “stateless operators may just take input and send it to the parent, for example, down-stream operators” (See par 53).
Dumont discloses:
KPI unit calculator according to claim 2, wherein the operation associated to each node of a plan is defined by “its names” (Dumont – see par 39 - a BIL expression has a map of nested expressions, each associated to a locally unique name. A nested expression can appear as a component in the expression's topology, and may also be used for calculations defined inside the expression. It may, for example, be necessary to give a name to an expression that is computed several times (possibly in different contexts) to produce the resulting entity.).
It is obvious to combine Simon and Park and Dumant for the same reasons as claim 7 above. In addition, Simon discloses that there is a Customer dimension table with attributes such as identification (ID), name (See par 39). Park discloses “ an event stream may represent an occurrence of some worldly event (e.g., when a temperature sensor changed value to a new value, when the price of a stock symbol changed)” (See par 33) and “stateless operators may just take input and send it to the parent, for example, down-stream operators” (See par 53). Dumont improves upon Park and Dumant by disclosing a name related to the querying plan.
Concerning claim 10, Simon and Park disclose:
The KPI unit calculator according to claim 9 wherein the list of operations further includes:
…
-joint operations, for joining or selecting data from parent operations into a single output ([0056] as published states “FIG. 5B illustrates the Join operation, which is responsible for joining and/or selecting data from parent operations into a single output, akin to the “JOIN” clause in SQL. In embodiments, this operation has two input operations and adds attributes to the ones defined by its parent class: two operations, their context, their selected fields and what type of join to use. The two operations, named “left” and “right” after this operation's counterpart in SQL, are the Join operation's parents.” Simon discloses the limitations based on broadest reasonable interpretation, where the limitation includes “join” – see par 28 - a new model to represent the execution plan of a query, called the CQP, is introduced. This model can be viewed as the compact normal form of an original query that groups all of the database operations that could possibly be permuted into macro-nodes. A "classical query processing tree" is a tree comprising the following nodes (operators): (Inner) Join,;
-filter operations, for filtering data from a parent operation (Simon – see par 28 – , Filter,);
-aggregate operations, for aggregating data of a parent operation (Simon – see par 28 - Aggregate Group by,);
…
-multi-joint operations, for joining an input of multiple operations into a single output (Simon see par 28 - a new model to represent the execution plan of a query, called the CQP, is introduced. This model can be viewed as the compact normal form of an original query that groups all of the database operations that could possibly be permuted into macro-nodes.);
-calculation operations, for calculating a value of an expression using data from an input operation and associating that value to an entity (Simon – see par 49 - he "Evaluation" operator takes as input one table R(A1, . . . , An) and produces one table R'(A1, . . . , An, E) where E is a calculated column associated with a function f that takes as arguments a subset of the columns A1); and
-sink operations, for outputting data to a data sink (Park – see FIG. 2 – event sinks 210, 212).
Simon discloses paths in a query plan (See par 73-75). Simon also discloses having arrows representing parent-child relationships in a query plan (See par 143).
Park discloses the remaining two operations:
-load operations, for retrieving data from at least one data source (Park – see par 58 - For example, a query may be loaded, wherein it may start running and listening for changes, etc. In some cases, if a user asks for sales by state, in a bar chart, and then somebody makes a new sale, the table may get updated and the user may expect to see a change in the graph, pushed out to them; see par 74 - For example, in FIG. 2, EPS 202 outputs a first output event stream 226 to event sink 210, and a second output event stream 228 to event sink 212. In certain embodiments, event sources, event processing applications, and event sinks are decoupled from each other such that one can add or remove any of these components without causing changes to the other components.).
-project operations, for mapping names of fields from a parent operation (Park – see par 38 - . Alternatively, a relation (also referred to as a “time varying relation,” and not to be confused with “relational data,” which may include data from a relational database) may be a mapping from the time domain to an unbounded bag of tuples of the schema R. see par 53 - In some examples, once the query is constructed in the CQL engine (e.g., as a graph), the system may analyze the query graph. Additionally, in some aspects, there are certain operators that are stateful, like “distinct,” “group aggr,” “pattern,” and/or “group by.” However, stateless operators may just take input and send it to the parent, for example, down-stream operators. See par 99 - Checkpoint marker events may be similar to pass-through events by which each operator can transmit the checkpoint marker event to its child operators).
It is obvious to combine Simon and Park and Dumant for the same reasons as claim 1 and 9 above.
Claims 12 are rejected under 35 U.S.C. 103 as being unpatentable over Simon (US 2011/0131199) and Park (US 2017/0116210), as applied above to claims 1-6, 8, 11, and 14-15, and further in view of Bishnoi (US 2019/0102431).
Concerning claim 12, Simon discloses customer have a “location” dimension (see par 37); and having aggregate operation (See par 49). Simon discloses that query parameters represent filters on dimension tables, such as “a region, a quarter or a range of dates, a product ID, etc.” (See par 54).
The KPI unit calculator according to claim 11, wherein the plan generator module is configured to determine whether there is a need to apply temporal and spatial aggregations (Park – see par 38 - A stream S may be a bag (also referred to as a “multi-set”) of elements (s, T), where “s” is in the schema of S and “T” is in the time domain. Additionally, stream elements may be tuple-timestamp pairs, which can be represented as a sequence of timestamped tuple insertions. In other words, a stream may be a sequence of timestamped tuples. In some cases, there may be more than one tuple with the same timestamp. And, the tuples of an input stream may be requested to arrive at the system in order of increasing timestamps. see par 152 - The output from the Window operator is a set of events that can be used for further processing such as joining event streams or calculating aggregate functions like sum and average. For instance, a window operator can collect all events (e.g., sales orders for a product) placed in the last hour and output the average value of the order once every hour. The Aggr operator is an operator that can compute an aggregate function such as sum, average, count, max on a set of events of an event stream. The groupBy operator refers to an operator than can perform the grouping and aggregation of events in an event stream.
Unclear if Park discloses “Spatial” aggregations. Bishnoi discloses:
The KPI unit calculator according to claim 11, wherein the plan generator module is configured to determine whether there is a need to apply temporal and “spatial” aggregations (Bishnoi – see par 48 - the present disclosure may describe the boundary of database stored information and in-flight information. Both the database stored information and the inflight information may include business intelligence (BI) data. As such, the database may, in some examples, be a BI server or it may be any type of database. see par 102 – aggregate functions (COUNT, MAX, MIN, SUM, AVG); can have “time stamp,” location displayed, time of day; par 116 – count average revenue for every time of day based on the … location filter)
Simon, Park, and Bishnoi disclose:
depending of a period of the KPI being bigger than any of the at least one data sources, and a number of attributes defined by the at least one data sources being more than those needed by a MET (Park discloses the limitations as best understood in light of the 112b rejections – see par 38 - In some examples, a relation may be an unordered, time-varying bag of tuples (i.e., an instantaneous relation). In some cases, at each instance of time, a relation may be a bounded set. It can also be represented as a sequence of timestamped tuples that may include insertions, deletes, and/or updates to capture the changing state of the relation. Similar to streams, a relation may have a fixed schema to which each tuple of the relation may conform. Further, as used herein, a continuous query may generally be capable of processing data of (i.e., queried against) a stream and/or a relation. Additionally, the relation may reference data of the stream. see par 99 - In an example, the checkpoint marker events may refer to identifiers of the oldest events on each input stream that still contribute to the state up to the time before a snapshot of the current state of the system is generated. The checkpoint marker events may be injected to the input stream similar to heartbeat events. Checkpoint marker events may be similar to pass-through events by which each operator can transmit the checkpoint marker event to its child operators. See par 105 - In one embodiment, the operator synopsis may refer to a mutable state of the operator for processing events, such as the last timestamp of the event, and the actual synopsis that includes the summary of events for processing the events, such as a list of events for a specified window size for the window operator or an aggregated result for the GroupAggr operator.
Bishnoi discloses the limitations as best understood in light of the 112b rejections – see par 48 - the present disclosure may describe the boundary of database stored information and in-flight information. Both the database stored information and the inflight information may include business intelligence (BI) data. As such, the database may, in some examples, be a BI server or it may be any type of database. see par 102 – aggregate functions (COUNT, MAX, MIN, SUM, AVG); can have “time stamp,” location displayed, time of day; par 116 – count average revenue for every time of day based on the …location filter; par 86 - The filter section in a query stage or query group stage allows events in the data stream to be filtered out. For example, only events which satisfy the filter condition are passed to the downstream stage. see par 95 - Continuous queries typically perform filtering and aggregation functions to discover and extract notable events from the input event streams. As a result, the number of outbound events in an output event stream is generally much lower than the number of events in the input event stream from which the events are selected; see par 133 - n some embodiments, a query stage 340 is used to configure the logical CQL query on the data stream from the source 315 and may comprise additional sources for joins, filters, subsections such as summaries, group by, and time windows, and so on.
It would have been obvious to combine Simon, Park, and Bishnoi for the same reasons as claim 1 above. In addition, Simon and Park and Bishnoi are analogous art as they are directed to analyzing information from databases related to businesses (see Simon Abstract, par 2, 37, 41; Park Abstract, par 36-37 – stock ticker with price; Bishnoi Abstract, par 48). Simon discloses customer have a “location” dimension (see par 37); and having aggregate operation (See par 49). Simon discloses that query parameters represent filters on dimension tables, such as “a region, a quarter or a range of dates, a product ID, etc.” (See par 54). Park discloses having windows and looking at data every hour. Bishnoi improves upon Simon and Park by disclosing aggregating data based on both time and location. One of ordinary skill in the art would be motivated to further include having aggregated data to efficiently improve upon the “location” dimension and the aggregate operation and the possibility of filtering by “region” and “range of dates” in Simon and the aggregation and consideration of different time/hours/windows in Park.
Response to Arguments
Applicant's arguments filed 8/27/25 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
Arguments are moot in light of the revised rejections necessitated by the amendments.
Applicant’s arguments are not persuasive for 101. A number of suggestions are provided above for moving towards overcoming the 101 and 112b issues. Applicant’s arguments are not persuasive, as the claim is currently still directed to an abstract idea of calculating KPI and having “plans,” with no clarity as to if/when any plans are even implemented, nor as to what is “executing” various steps.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at 571-270-3614. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
Prosecution Insights