DETAILED ACTION
This Office Action is in response to Applicant’s reply filed 02/02/2026, after the non-final Office Action of 10/31/2025 in response to Appeal Brief filed 07/09/2025.
Claims 1-4, 6, 10-16, and 18-20 are pending.
Claims 1-4, 6, 10-16, and 18-20 are rejected.
Notice of AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Priority
This application is a continuation of application number 14/054,803 (filed 10/15/2018), application number 15/497,130 (filed 04/15/2017), and provisional application number 61/714,181 (filed 10/15/2012).
Statutory Review under 35 USC § 101
Claims 1-4, 6, and 10-13 are directed towards a method and have been reviewed.
Claims 1-4, 6, and 10-13 appear to remain statutory as the method is directed to significantly more than an abstract idea based on currently known judicial exceptions. Specifically, the claims involve aggregating measure fields of data derived from distinct data sources based on a more granular aggregation to circumvent a lack of dimension fields within one of the distinct data sources. Similarly, the features scrutinized in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 118 USPQ2d 1684 (Fed. Cir. 2016) were considered to reflect an improvement to existing technology, particularly enabling its claimed table to achieve benefits over conventional databases (see MPEP 2106.05(d)(I)).
Claims 14-16 and 18-19 are directed toward a system and have been reviewed.
Claims 14-16 and 18-19 appear to remain statutory, as the system includes hardware (memory) as disclosed in ¶ 0034 of the applicant’s specification. Claims 14-19 also perform a method directed to significantly more than an abstract idea based on currently known judicial exceptions. Specifically, the claims involve aggregating measure fields of data derived from distinct data sources based on a more granular aggregation to circumvent a lack of dimension fields within one of the distinct data sources. Similarly, the features scrutinized in Enfish were considered to reflect an improvement to existing technology, particularly enabling its claimed table to achieve benefits over conventional databases (see MPEP 2106.05(d)(I)).
Claim 20 is directed toward an article of manufacture and have been reviewed.
Claim 20 appears to remain statutory, as the article of manufacture excludes transitory signals (claim says non-transitory). Claim 20 also appears to remain statutory as it performs a method directed to significantly more than an abstract idea based on currently known judicial exceptions. Specifically, the claims involve aggregating measure fields of data derived from distinct data sources based on a more granular aggregation to circumvent a lack of dimension fields within one of the distinct data sources. Similarly, the features scrutinized in Enfish were considered to reflect an improvement to existing technology, particularly enabling its claimed table to achieve benefits over conventional databases (see MPEP 2106.05(d)(I)).
Response to Arguments
Applicant's arguments filed 02/02/2026 have been fully considered but they are not persuasive.
Regarding claims 1, 14, and 20, Applicant argues (A) in Remarks p7 that the cited portions of Cushing do not teach “receiving user selection of a first data source and a second data source.”
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing.
Cushing is relied on for user selection through ¶ 0037-0040 describing allowing a user to specify a query/request over columns of a specified cube to retrieve desired data..
Even despite Cushing ¶ 0038 describing the information in the above Tables having been loaded into an OLAP system in its talk of the cube and its cells, allowing a user to query on columns from a particular cube comprising first data and second data contemplates “receiving user selection of a first data source and a second data source.”
Regarding claims 1, 14, and 20, Applicant argues (B) in Remarks p8 that the cited portions of Cushing do not teach “receiving user selection of a plurality of data fields, from the first data source and the second data source, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields from the first data source, one or more second measure fields from the second data source, and an initial set of dimension fields.”
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing.
In the previous limitation, Cushing is relied on for user selection through ¶ 0037-0040 describing a user submitting a request as a query over columns from a cube.
More relevantly, Cushing allows the user to specify a query/request over specified hierarchies (such as [Customer].[Gender] and [Customer].[Marital Status]), from a particular dimension ([Customer] in this example but capable of including [Time]), from columns of a specified cube to retrieve desired data.
As a result, ¶ 0040-0046 of Cushing cited for this limitation, referring to a user submitting a request for unit purchase data aggregated according to gender and marital status or a request for sales data for name, gender, and marital status, in the year 2009, fulfills the claimed receiving user selection of a plurality of data fields, for inclusion in a data visualization.
Despite Cushing ¶ 0004 falling under the “Related Art section” of its specification (see Remarks p8, ¶ 3), it still provides important context as to the layout of cells of cubes containing measures such as unit sales and gross revenue.
Thus, Cushing fulfills the claimed receiving user selection of a plurality of data fields, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields, one or more second measure fields.
Cushing FIG. 2, step 210, ¶ 0024 cited for this limitation summarizes the request as including a cross-join involving plural hierarchies of data attributes of the same dimension.
As a result, Cushing fulfills the claimed receiving user selection of a plurality of data fields, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields, one or more second measure fields, and an initial set of dimension fields.
As seen above, Cushing ¶ 0037-0040 describing the information in the above Tables having been loaded into an OLAP system in its talk of the cube and its cells, allowing a user to query on columns from a particular cube comprising first data and second data contemplates “a first data source and a second data source”; thus, Cushing fulfills the claimed receiving user selection of a plurality of data fields, from the first data source and the second data source, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields from the first data source, one or more second measure fields from the second data source, and an initial set of dimension fields.
Regarding claims 1, 14, and 20, Applicant argues (C) in Remarks pp8-9 that the cited portions of Cushing do not teach “in accordance with a determination that the initial set of dimension fields includes a first dimension field not in the second data source, selecting an alternative set of pre-existing dimension fields that is (1) more granular than the initial set of dimension fields and (2) consists of dimension fields in both the first data source and the second data source, wherein the alternative set of pre-existing dimension fields are a different category of dimension fields from the initial set of dimension fields.”
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing in view of at least Chitnis.
Cited Cushing ¶ 0052 refers to using a join relationship for Year/Month and Year/Quarter hierarchies at the granularity of “day” and the instances of “day” being used as the convergence “level,” showing selecting an alternative set of pre-existing dimension fields that is (1) more granular than the initial set of dimension fields.
This passage also discovers a common relationship between hierarchies, thus discovering that data is retained at the day level in locations such as the cells of a MOLAP system, resulting in Cushing showing selecting an alternative set of pre-existing dimension fields that is (1) more granular than the initial set of dimension fields and (2) consists of dimension fields in both the first data source and the second data source.
This passage also shows constructing a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users, such as in consideration of Year/Month and Year/Quarter; this disparity between the two results in Cushing showing executing in accordance with a determination that the initial set of dimension fields includes a first dimension field not in the second data source.
As seen above, Cushing ¶ 0037-0040 describing the information in the above Tables having been loaded into an OLAP system in its talk of the cube and its cells, allowing a user to query on columns from a particular cube comprising first data and second data contemplates “a first data source and a second data source”; thus, even while operating within a single OLAP cube, Cushing fulfills the requirements for multiple data sources.
Regarding claims 1, 14, and 20, Applicant argues (D) in Remarks pp9-10 that the cited portions of Cushing do not teach “aggregating the first measure fields according to the alternative set of pre-existing dimension fields to form a first intermediate data set and separately aggregating the second measure fields according to the alternative set of pre-existing dimension fields to form a second intermediate data set.”
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing.
Cited Cushing ¶ 0045-0046 also shows a second example involving a user requesting sales data for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status. This passage subsequently shows specifying the Measure of Purchases in the query/request, thus allowing Cushing to show “aggregating the first measure fields to form a first intermediate data set.”
Cushing is shown above in ¶ 0052 to be capable of utilizing an alternative set of pre-existing dimension fields, thus allowing Cushing to show “aggregating the first measure fields according to the alternative set of pre-existing dimension fields to form a first intermediate data set.”
Cited Cushing ¶ 0004 provides context showing that a plurality of measures are possible in addition to the example embodiments provided later in Cushing ¶ 0045-0046, including at least unit sales and gross revenue.
With this in mind and in light of the queries of Cushing, Cushing is capable of showing “aggregating the first measure fields according to the alternative set of pre-existing dimension fields to form a first intermediate data set and separately aggregating the second measure fields according to the alternative set of pre-existing dimension fields to form a second intermediate data set.”
Regarding claims 1, 14, and 20, Applicant argues (E) in Remarks p10 that the cited portions of Cushing do not teach “joining the first intermediate data set with the second intermediate data set, using the alternative set of pre-existing dimension fields, to form a single combined data set.”
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing.
Cushing ¶ 0050 describes cross-joining two sets of tuples and filtering the result, then subsequently cross-joining the filtered result an additional time, showing joining the first intermediate data set with the second intermediate data set to form a single combined data set.
Cushing is shown above in ¶ 0052 to be capable of utilizing an alternative set of pre-existing dimension fields, thus showing joining the first intermediate data set with the second intermediate data set, using the alternative set of pre-existing dimension fields, to form a single combined data set.
Applicant specifies that the cross-join in Cushing is intra-source, not inter-source; as currently structured, the claims are capable of being addressed by Cushing, as this particular claim limitation requires joining of a first intermediate data set (formed by aggregating first measure fields from a first data source) with a second intermediate data set (formed by aggregating second measure fields from a second data source), and Cushing ¶ 0037-0040 allows a user to query on columns from a particular cube comprising first data and second data.
Regarding claims 1, 14, and 20, Applicant argues (F) in Remarks p10 that the cited combination of Cushing and Chitnis is improper because it renders Cushing inoperative for its intended purpose.
In response to Applicant’s arguments, the claim requirement of the language “different category” within “wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields” can still exist within the embodiments of Cushing and Chitnis as relied upon.
Regarding claims 1, 14, and 20, Applicant argues (G) in Remarks p11 that the cited portions of Cushing and Ziauddin do not teach “forming a final data set by rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields and performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields,” specifically as the cited portions of Cushing do not teach forming the combined data set as in (E).
In response to Applicant’s arguments, the claims as currently structured are capable of being addressed by Cushing in view of at least Ziauddin, and as Cushing is argued above in (E) as addressing forming a single combined data set, Cushing in view of at least Ziauddin do teach “forming a final data set by rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields and performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields” at this time.
The dependent claims remain rejected at least by virtue of their dependence on rejected base claims (see Remarks pp11-13).
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1, 10-11, 13; 14; and 20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing et al., U.S. Patent Application Publication No. 2014/0074769 (the publication for previously-utilized U.S. Patent No. 9,886,460, most recently used in the rejection of claims 11 and 13 and not utilized as a reference in the rejection of the independent claims since the non-final Office Action of 12/22/2022); hereinafter Cushing in view of Chitnis et al., U.S. Patent Application Publication No. 2009/0112927 (hereinafter Chitnis) in further view of Ziauddin et al., U.S. Patent No. 6,493,708 (published December 10, 2002; hereinafter Ziauddin).
Regarding claim 1, Cushing teaches:
A method for dynamically combining data from multiple data sources, comprising: (Cushing ¶ 0025: the OLAP server at step 250 forms a set of tuples by cross-joining the members of the current dimension that are included in the request … At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source, and the results are returned (e.g., as a set of tuples formed by merging each tuple of the final set with its corresponding result) at step 290)
receiving user selection of a first data source and a second data source; (Cushing p3, ¶ 0037 shows multiple data sources: sample data in the Purchases and Customer Data Tables … the information in the above Tables is considered to have been loaded into an OLAP system. The cube has a time dimension and a customer dimension; Cushing ¶ 0040 shows user selection: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... ON COLUMNS FROM [cube])
receiving user selection of a plurality of data fields, from the first data source and the second data source, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields from the first data source, one or more second measure fields from the second data source, and an initial set of dimension fields; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0040-0046: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... a user requests sales data for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009; Cushing FIG. 2, step 210, ¶ 0024: the OLAP server (e.g., via server system 10) receives a request at step 210. The request preferably includes a cross-join involving plural hierarchies of data attributes of the same dimension)
in accordance with a determination that the initial set of dimension fields includes a first dimension field not in the second data source, selecting an alternative set of dimension fields that is (1) more granular than the initial set of dimension fields and (2) consists of dimension fields in both the first data source and the second data source, (Cushing FIG. 3, ¶ 0027: A manner in which OLAP server 16 filters non-existing tuples (e.g., step 260 of FIG. 2) ... is illustrated in FIG. 3. At step 310, the OLAP server determines the levels at which each combination of the data attribute hierarchies of the current dimension converge. A level is designated as a convergence level of plural hierarchies of the same dimension if the hierarchies share the particular level and all levels below that particular level. For example, in the case of a time dimension with RegularCalendar and FiscalCalendar hierarchies as shown in the Time Dimensions Hierarchy Table below, the convergence level is Month; Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users. For example, a time dimension may contain Year/Month and a Year/Quarter hierarchies which to the user do not have a convergence level ... Another embodiment of the present invention looks for a common relationship between the hierarchies and the data which is known to the system and which can be used as the convergence level. In the time example above, if data is retained at the day level (e.g., in a fact table of a ROLAP system or in cells of MOLAP system), both the Year/Month and Year/Quarter hierarchies use a join relationship at the granularity of "day" to the data, and the instances of "day" may be used as the convergence "level")
aggregating the first measure fields according to the alternative set of dimension fields to form a first intermediate data set and separately aggregating the second measure fields according to the alternative set of dimension fields to form a second intermediate data set; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0045-0046: a user requests aggregate units [serving as one measure] for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order. In still another example, a user requests sales data [shown in ¶ 0004 to be a measure] for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009)
joining the first intermediate data set with the second intermediate data set, using the alternative set of dimension fields, to form a single combined data set; (Cushing FIG. 2, step 270, ¶ 0025: Once each dimension in the OLAP request has been processed as determined at step 265, the OLAP server cross-joins the saved sets of tuples at step 270 to form a final set of tuples. The order of members within the tuples is managed across the cross-joins so that tuples in the final set correspond to the request; Cushing ¶ 0045: a user requests aggregate units for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order; see also relevant Cushing ¶ 0050: an embodiment of the present invention may cross-join {Alexandra, Bob, Cathy, David, Edwina} with {Male, Female}, filter the result, cross-join the filtered result with {Single, Married}, and then filter those results ... an embodiment of the present invention may form {Alexandra, Bob, Cathy, David, Edwina}.times.{Male, Female}.times.{Single, Married} and filter the results in one pass)
forming a final data set… (Cushing FIG. 2, step 280, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source)
…performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; and (Cushing ¶ 0048-0049: Without removing non-existent tuples, the results include: [Table 9] ... With non-existent tuple removal, this reduces to: [Table 10]; Cushing ¶ 0053: a query may be executed by running a report specification as illustrated in FIG. 4A to generate reports as illustrated in FIGS. 4B (without non-existent tuple removal) and 4C (with non-existent tuple removal))
generating and displaying the data visualization using the data from the final data set. (Cushing FIG. 2, step 290, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source, and the results are returned (e.g., as a set of tuples formed by merging each tuple of the final set with its corresponding result) at step 290)
Cushing also teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users)
This embodiment of Cushing arguably does not expressly disclose:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields;
Cushing further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Chitnis teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Chitnis FIG. 5, ¶ 0036-0037: The remaining data transformations shown in FIG. 5 illustrate how different aggregations can be specified by modifying the levels of aggregation of one or more key fields. A subsequent example presented below (drawn to customer propensity) illustrates levels of aggregation along dimensions other than those defined by the key fields; see also Chitnis FIG. 8, ¶ 0043: The tenth data transformation shown in FIG. 8 is a product affinity calculation that measures customer buying preferences by product department. Because the aggregation is over a dimension that does not appear as a key field, the tenth transformation defines a pivot calculation that generates multiple columns, one column per product department)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing with the data aggregation of Chitnis.
In addition, both of the references (Cushing and Chitnis) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing with the similar data aggregation of Chitnis but with the improvement of efficient calculation of data transformation as seen in Chitnis ¶ 0037.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to implement the generation of data transformation code as output based on high-level input specifications of desired transformations which are more natural for statisticians and data analysts to provide as seen in Chitnis ¶ 0001.
Cushing in view of Chitnis further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Ziauddin addresses this by teaching:
forming a final data set by rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields and performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; (Ziauddin col. 2, lines 46-49: A materialized view is a table where the pre-computed data corresponding to a materialized view definition is stored. For example, a materialized view "mv1" may be defined...; Ziauddin col. 4, line 7-19: When a hierarchical dimension is represented by a dimension table that has one column for each hierarchical level, rolling up aggregate values from a finer level to a coarser level may merely involve a re-aggregation of aggregated values using the appropriate column at the coarser level, or a join between the materialized view and the dimension table followed by a re-aggregation of aggregated values using the coarser level column; see the claimed 'retaining the dimension fields in the initial set of dimension fields' through Ziauddin col. 4, lines 20-30: the materialized view may be created with a column for each level of the hierarchy, and the roll-up may be performed by aggregating based on groups associated with the appropriate column. For example, mv1 was created with a year column, so rolling values in mv1 up to the year level may be performed based on the year column of mv1)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data aggregation of Ziauddin.
In addition, both of the references (Cushing as modified and Ziauddin) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing as modified with the similar data aggregation of Ziauddin but with its improved aggregation and rollup techniques (Ziauddin col. 6, lines 49-62).
Regarding claim 14, Cushing teaches:
A client device, comprising: one or more processors; memory; and one or more programs stored in the memory for execution by the one or more processors, the one or more programs comprising instructions for: (Cushing ¶ 0073: It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks)
receiving user selection of a first data source and a second data source; (Cushing p3, ¶ 0037 shows multiple data sources: sample data in the Purchases and Customer Data Tables … the information in the above Tables is considered to have been loaded into an OLAP system. The cube has a time dimension and a customer dimension; Cushing ¶ 0040 shows user selection: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... ON COLUMNS FROM [cube])
receiving user selection of a plurality of data fields, from the first data source and the second data source, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields from the first data source, one or more second measure fields from the second data source, and an initial set of dimension fields; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0040-0046: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... a user requests sales data for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009; Cushing FIG. 2, step 210, ¶ 0024: the OLAP server (e.g., via server system 10) receives a request at step 210. The request preferably includes a cross-join involving plural hierarchies of data attributes of the same dimension)
in accordance with a determination that the initial set of dimension fields includes a first dimension field not in the second data source, selecting an alternative set of dimension fields that is (1) more granular than the initial set of dimension fields and (2) consists of dimension fields in both the first data source and the second data source, (Cushing FIG. 3, ¶ 0027: A manner in which OLAP server 16 filters non-existing tuples (e.g., step 260 of FIG. 2) ... is illustrated in FIG. 3. At step 310, the OLAP server determines the levels at which each combination of the data attribute hierarchies of the current dimension converge. A level is designated as a convergence level of plural hierarchies of the same dimension if the hierarchies share the particular level and all levels below that particular level. For example, in the case of a time dimension with RegularCalendar and FiscalCalendar hierarchies as shown in the Time Dimensions Hierarchy Table below, the convergence level is Month; Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users. For example, a time dimension may contain Year/Month and a Year/Quarter hierarchies which to the user do not have a convergence level ... Another embodiment of the present invention looks for a common relationship between the hierarchies and the data which is known to the system and which can be used as the convergence level. In the time example above, if data is retained at the day level (e.g., in a fact table of a ROLAP system or in cells of MOLAP system), both the Year/Month and Year/Quarter hierarchies use a join relationship at the granularity of "day" to the data, and the instances of "day" may be used as the convergence "level")
aggregating the first measure fields according to the alternative set of dimension fields to form a first intermediate data set and separately aggregating the second measure fields according to the alternative set of dimension fields to form a second intermediate data set; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0045-0046: a user requests aggregate units [serving as one measure] for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order. In still another example, a user requests sales data [shown in ¶ 0004 to be a measure] for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009)
joining the first intermediate data set with the second intermediate data set, using the alternative set of dimension fields, to form a single combined data set; (Cushing FIG. 2, step 270, ¶ 0025: Once each dimension in the OLAP request has been processed as determined at step 265, the OLAP server cross-joins the saved sets of tuples at step 270 to form a final set of tuples. The order of members within the tuples is managed across the cross-joins so that tuples in the final set correspond to the request; Cushing ¶ 0045: a user requests aggregate units for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order; see also relevant Cushing ¶ 0050: an embodiment of the present invention may cross-join {Alexandra, Bob, Cathy, David, Edwina} with {Male, Female}, filter the result, cross-join the filtered result with {Single, Married}, and then filter those results ... an embodiment of the present invention may form {Alexandra, Bob, Cathy, David, Edwina}.times.{Male, Female}.times.{Single, Married} and filter the results in one pass)
forming a final data set… (Cushing FIG. 2, step 280, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source)
…performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; and (Cushing ¶ 0048-0049: Without removing non-existent tuples, the results include: [Table 9] ... With non-existent tuple removal, this reduces to: [Table 10]; Cushing ¶ 0053: a query may be executed by running a report specification as illustrated in FIG. 4A to generate reports as illustrated in FIGS. 4B (without non-existent tuple removal) and 4C (with non-existent tuple removal))
generating and displaying the data visualization using the data from the final data set. (Cushing FIG. 2, step 290, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source, and the results are returned (e.g., as a set of tuples formed by merging each tuple of the final set with its corresponding result) at step 290)
Cushing also teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users)
This embodiment of Cushing arguably does not expressly disclose:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields;
Cushing further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Chitnis teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Chitnis FIG. 5, ¶ 0036-0037: The remaining data transformations shown in FIG. 5 illustrate how different aggregations can be specified by modifying the levels of aggregation of one or more key fields. A subsequent example presented below (drawn to customer propensity) illustrates levels of aggregation along dimensions other than those defined by the key fields; see also Chitnis FIG. 8, ¶ 0043: The tenth data transformation shown in FIG. 8 is a product affinity calculation that measures customer buying preferences by product department. Because the aggregation is over a dimension that does not appear as a key field, the tenth transformation defines a pivot calculation that generates multiple columns, one column per product department)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing with the data aggregation of Chitnis.
In addition, both of the references (Cushing and Chitnis) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing with the similar data aggregation of Chitnis but with the improvement of efficient calculation of data transformation as seen in Chitnis ¶ 0037.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to implement the generation of data transformation code as output based on high-level input specifications of desired transformations which are more natural for statisticians and data analysts to provide as seen in Chitnis ¶ 0001.
Cushing in view of Chitnis further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Ziauddin addresses this by teaching:
forming a final data set by rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields and performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; (Ziauddin col. 2, lines 46-49: A materialized view is a table where the pre-computed data corresponding to a materialized view definition is stored. For example, a materialized view "mv1" may be defined...; Ziauddin col. 4, line 7-19: When a hierarchical dimension is represented by a dimension table that has one column for each hierarchical level, rolling up aggregate values from a finer level to a coarser level may merely involve a re-aggregation of aggregated values using the appropriate column at the coarser level, or a join between the materialized view and the dimension table followed by a re-aggregation of aggregated values using the coarser level column; see the claimed 'retaining the dimension fields in the initial set of dimension fields' through Ziauddin col. 4, lines 20-30: the materialized view may be created with a column for each level of the hierarchy, and the roll-up may be performed by aggregating based on groups associated with the appropriate column. For example, mv1 was created with a year column, so rolling values in mv1 up to the year level may be performed based on the year column of mv1)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data aggregation of Ziauddin.
In addition, both of the references (Cushing as modified and Ziauddin) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing as modified with the similar data aggregation of Ziauddin but with its improved aggregation and rollup techniques (Ziauddin col. 6, lines 49-62).
Regarding claim 20, Cushing teaches:
A non-transitory computer readable storage medium storing one or more programs configured for execution by a client device having one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs comprising instructions for: (Cushing ¶ 0073-0074: It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner)
receiving user selection of a first data source and a second data source; (Cushing p3, ¶ 0037 shows multiple data sources: sample data in the Purchases and Customer Data Tables … the information in the above Tables is considered to have been loaded into an OLAP system. The cube has a time dimension and a customer dimension; Cushing ¶ 0040 shows user selection: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... ON COLUMNS FROM [cube])
receiving user selection of a plurality of data fields, from the first data source and the second data source, for inclusion in a data visualization, wherein the plurality of data fields includes one or more first measure fields from the first data source, one or more second measure fields from the second data source, and an initial set of dimension fields; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0040-0046: a user submits a request to OLAP server 16 for unit purchase data aggregated according to gender and marital status ... a user requests sales data for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009; Cushing FIG. 2, step 210, ¶ 0024: the OLAP server (e.g., via server system 10) receives a request at step 210. The request preferably includes a cross-join involving plural hierarchies of data attributes of the same dimension)
in accordance with a determination that the initial set of dimension fields includes a first dimension field not in the second data source, selecting an alternative set of dimension fields that is (1) more granular than the initial set of dimension fields and (2) consists of dimension fields in both the first data source and the second data source, (Cushing FIG. 3, ¶ 0027: A manner in which OLAP server 16 filters non-existing tuples (e.g., step 260 of FIG. 2) ... is illustrated in FIG. 3. At step 310, the OLAP server determines the levels at which each combination of the data attribute hierarchies of the current dimension converge. A level is designated as a convergence level of plural hierarchies of the same dimension if the hierarchies share the particular level and all levels below that particular level. For example, in the case of a time dimension with RegularCalendar and FiscalCalendar hierarchies as shown in the Time Dimensions Hierarchy Table below, the convergence level is Month; Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users. For example, a time dimension may contain Year/Month and a Year/Quarter hierarchies which to the user do not have a convergence level ... Another embodiment of the present invention looks for a common relationship between the hierarchies and the data which is known to the system and which can be used as the convergence level. In the time example above, if data is retained at the day level (e.g., in a fact table of a ROLAP system or in cells of MOLAP system), both the Year/Month and Year/Quarter hierarchies use a join relationship at the granularity of "day" to the data, and the instances of "day" may be used as the convergence "level")
aggregating the first measure fields according to the alternative set of dimension fields to form a first intermediate data set and separately aggregating the second measure fields according to the alternative set of dimension fields to form a second intermediate data set; (Cushing ¶ 0004: The tuple, (August of 2010, Chicago), identifies a cell of the cube that contains the corresponding set of measures (e.g., unit sales, gross revenue, etc.); Cushing ¶ 0045-0046: a user requests aggregate units [serving as one measure] for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order. In still another example, a user requests sales data [shown in ¶ 0004 to be a measure] for a combination of more than two hierarchies belonging to the same dimension, specifically for name, gender, and marital status, in the year 2009)
joining the first intermediate data set with the second intermediate data set, using the alternative set of dimension fields, to form a single combined data set; (Cushing FIG. 2, step 270, ¶ 0025: Once each dimension in the OLAP request has been processed as determined at step 265, the OLAP server cross-joins the saved sets of tuples at step 270 to form a final set of tuples. The order of members within the tuples is managed across the cross-joins so that tuples in the final set correspond to the request; Cushing ¶ 0045: a user requests aggregate units for each name, gender, fiscal quarter, and regular calendar month. The OLAP server cross-joins names with genders, and filters out the non-existing pairs. It also cross-joins fiscal quarters with months, and filters out the non-existing pairs. The OLAP server further cross-joins the two resulting filtered sets, keeping track of the order of the elements to make sure that the final tuple has its elements in the requested order; see also relevant Cushing ¶ 0050: an embodiment of the present invention may cross-join {Alexandra, Bob, Cathy, David, Edwina} with {Male, Female}, filter the result, cross-join the filtered result with {Single, Married}, and then filter those results ... an embodiment of the present invention may form {Alexandra, Bob, Cathy, David, Edwina}.times.{Male, Female}.times.{Single, Married} and filter the results in one pass)
forming a final data set… (Cushing FIG. 2, step 280, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source)
…performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; and (Cushing ¶ 0048-0049: Without removing non-existent tuples, the results include: [Table 9] ... With non-existent tuple removal, this reduces to: [Table 10]; Cushing ¶ 0053: a query may be executed by running a report specification as illustrated in FIG. 4A to generate reports as illustrated in FIGS. 4B (without non-existent tuple removal) and 4C (with non-existent tuple removal))
generating and displaying the data visualization using the data from the final data set. (Cushing FIG. 2, step 290, ¶ 0025: At step 280, the data corresponding to each tuple in the final set is retrieved from the underlying data source, and the results are returned (e.g., as a set of tuples formed by merging each tuple of the final set with its corresponding result) at step 290)
Cushing also teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Cushing ¶ 0052: determine whether an operable convergence level among multiple hierarchies of a single dimension exists and may construct a convergence level even if the hierarchies of a dimension do not have a convergence level visible to users)
This embodiment of Cushing arguably does not expressly disclose:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields;
Cushing further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Chitnis teaches:
wherein the alternative set of dimension fields are a different category of dimension fields from the initial set of dimension fields; (Chitnis FIG. 5, ¶ 0036-0037: The remaining data transformations shown in FIG. 5 illustrate how different aggregations can be specified by modifying the levels of aggregation of one or more key fields. A subsequent example presented below (drawn to customer propensity) illustrates levels of aggregation along dimensions other than those defined by the key fields; see also Chitnis FIG. 8, ¶ 0043: The tenth data transformation shown in FIG. 8 is a product affinity calculation that measures customer buying preferences by product department. Because the aggregation is over a dimension that does not appear as a key field, the tenth transformation defines a pivot calculation that generates multiple columns, one column per product department)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing with the data aggregation of Chitnis.
In addition, both of the references (Cushing and Chitnis) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing with the similar data aggregation of Chitnis but with the improvement of efficient calculation of data transformation as seen in Chitnis ¶ 0037.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to implement the generation of data transformation code as output based on high-level input specifications of desired transformations which are more natural for statisticians and data analysts to provide as seen in Chitnis ¶ 0001.
Cushing in view of Chitnis further does not expressly disclose:
…rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields…
However, Ziauddin addresses this by teaching:
forming a final data set by rolling up the combined data set, including retaining the dimension fields in the initial set of dimension fields and performing an additional aggregation to aggregate the first measure fields and the second measure fields according to the initial set of dimension fields; (Ziauddin col. 2, lines 46-49: A materialized view is a table where the pre-computed data corresponding to a materialized view definition is stored. For example, a materialized view "mv1" may be defined...; Ziauddin col. 4, line 7-19: When a hierarchical dimension is represented by a dimension table that has one column for each hierarchical level, rolling up aggregate values from a finer level to a coarser level may merely involve a re-aggregation of aggregated values using the appropriate column at the coarser level, or a join between the materialized view and the dimension table followed by a re-aggregation of aggregated values using the coarser level column; see the claimed 'retaining the dimension fields in the initial set of dimension fields' through Ziauddin col. 4, lines 20-30: the materialized view may be created with a column for each level of the hierarchy, and the roll-up may be performed by aggregating based on groups associated with the appropriate column. For example, mv1 was created with a year column, so rolling values in mv1 up to the year level may be performed based on the year column of mv1)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data aggregation of Ziauddin.
In addition, both of the references (Cushing as modified and Ziauddin) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the data aggregation of Cushing as modified with the similar data aggregation of Ziauddin but with its improved aggregation and rollup techniques (Ziauddin col. 6, lines 49-62).
Regarding claim 10, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claim 1 above including:
the primary data source comprises one or more tables in a relational database. (Cushing ¶ 0061: Database systems may be implemented by any number of any conventional or other databases, data stores or storage structures (e.g., files, databases, data structures, data or other repositories, etc.) to store information (e.g., cubes, arrays, fact tables, dimension tables, conventional relational tables, indexes, metadata, etc.))
Regarding claim 11, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claim 1 above including:
the primary data source is a data cube. (Cushing ¶ 0004: An OLAP database can be conceptualized as a multidimensional array called a "cube"; see this in light of at least Cushing ¶ 0056: The topology or environment of the present invention embodiments may include any number of computer or other processing systems (e.g., client or end-user systems, server systems, etc.) and OLAP engines, databases)
Regarding claim 13, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claim 1 above including:
wherein at least two data sources are accessed using distinct software applications. (Cushing ¶ 0021-0022: The client systems may include an OLAP client 20, such as a spreadsheet, report generator, or other client software, and present any graphical user (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) to solicit queries from users and display results ... Server systems 10 and client systems 14 may be implemented by any conventional or other computer systems preferably equipped with ... any commercially available and custom software (e.g., reporting software, spreadsheet software, communications software, server software, OLAP clients, OLAP servers, relational database clients, relational database servers, etc.). The computer systems may include server, desktop, laptop, and hand-held devices)
Claim 2 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing in view of Chitnis and Ziauddun and Arning, U.S. Patent Application Publication No. 2001/0054034 (hereinafter Arning).
Regarding claim 2, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claim 1 above including:
one or more of the data sources are selected from the group consisting of spreadsheets, text files, (Cushing ¶ 0021-0022: The client systems may include an OLAP client 20, such as a spreadsheet, report generator, or other client software ... Server systems 10 and client systems 14 may be implemented by any conventional or other computer systems preferably equipped with ... any commercially available and custom software (e.g., reporting software, spreadsheet software...); Cushing ¶ 0055: Results may be presented in any format including text and graphics representing sets, tables, charts, etc.)
Cushing in view of Chitnis and Ziauddun does not expressly disclose the group consisting of CSV files.
However, Arning teaches:
one or more of the data sources are selected from the group consisting of spreadsheets, text files, and CSV files. (Arning ¶ 0043: second multi-dimensional database has data stored in a spreadsheet data file; Arning ¶ 0085: spreadsheet data file is a comma separated values (.CSV) file)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data tables of Cushing as modified with the multiple multidimensional databases of Arning.
In addition, both of the references (Cushing as modified and Arning) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as obtaining data.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to provide capabilities for exploration and visualization of result data against a subject multi-dimensional database as seen in Arning (¶ 0040-0044).
Claims 3 and 15 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing in view of Chitnis and Ziauddun and Li et al., U.S. Patent Application Publication No. 2009/0006370 (hereinafter Li).
Regarding claims 3 and 15, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claims 1 and 14 above but does not expressly disclose:
wherein a first data source is designated as a primary data source and the second data source is designated as a secondary data source.
However, Li teaches:
wherein a first data source is designated as a primary data source and the second data source is designated as a secondary data source. (Li FIG. 8, ¶ 0049-0050: FIG. 8 shows a portion of an original fact table 800 in which some of the original data is stored that will be used as source data in the present example of deriving an answer to the business rule expressed by Eq. (3) ... For referencing by other queries, the original fact table is designated as facttable 890; see this fact table used in Li ¶ 0054: The first intermediary table 1000 is used to gather appropriate data from the fact table for the time period of interest in Eq. (3); Li FIG. 9, ¶ 0051: For referencing by other queries, the original assumptions table is designated as a table 990; see both tables used in Li ¶ 0059: the v1 column 1140 will include data derived from the first intermediary table 1000 (FIG. 10), while the v2 column 1150 will include data derived from the assumptions table 900 (FIG. 9))
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data gathering of Li.
In addition, both of the references (Cushing as modified and Li) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to use mapping to facilitate generation of intermediate datasets to facilitate data retrieval and manipulation (Li ¶ 0005, ¶ 0065).
Claims 4 and 16 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing in view of Chitnis and Ziauddun and Li and Graefe, U.S. Patent Application Publication No. 2013/0013585 (hereinafter Graefe).
Regarding claims 4 and 16, Cushing in view of Chitnis and Ziauddun and Li teaches all the features with respect to claims 3 and 15 above but does not expressly disclose:
wherein joining the first data source with the second data source comprises performing an outer join locally at the client device with an intermediate data set from the primary data source as the outer data set with respect to all other intermediate data sets.
However, Graefe addresses this by teaching:
wherein joining the first data source with the second data source comprises performing an outer join locally at the client device with an intermediate data set from the primary data source as the outer data set with respect to all other intermediate data sets. (Graefe ¶ 0002: An operation with multiple inputs, for example two inputs, may match up items from the two input based on some criterion or predicate. One example may include a SQL "join" query, including the variants of "outer joins"; Graefe ¶ 0045-0047: The join operation may also include any form of outer join in ANSI SQL ... The system 100 thus provides for deep integration of aggregation and join operations as well as intermediate results records in the hash table that contain intermediate fields for multiple aggregations, e.g., sums and counts as appropriate for two separate average calculations ... If no match is found, the appropriate action depends on the join condition among the inputs and the processing sequence for inputs)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data aggregation of Graefe.
In addition, both of the references (Cushing as modified and Graefe) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to implement improved query processing performance by integrating hash join and hash aggregation (Graefe ¶ 0024).
Claims 6 and 18 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing in view of Chitnis and Ziauddun and Li and Brown, U.S. Patent Application Publication No. 2009/0319548 (hereinafter Brown).
Regarding claims 6 and 18, Cushing in view of Chitnis and Ziauddun and Li teaches all the features with respect to claims 3 and 15 above including:
wherein rolling up the combined data set comprises aggregating measure fields from the second data source, (Ziauddin col. 2, lines 46-49: A materialized view is a table where the pre-computed data corresponding to a materialized view definition is stored. For example, a materialized view "mv1" may be defined...; Ziauddin col. 4, line 7-19: When a hierarchical dimension is represented by a dimension table that has one column for each hierarchical level, rolling up aggregate values from a finer level to a coarser level may merely involve a re-aggregation of aggregated values using the appropriate column at the coarser level, or a join between the materialized view and the dimension table followed by a re-aggregation of aggregated values using the coarser level column; see Ziauddin col. 4, lines 20-30: the materialized view may be created with a column for each level of the hierarchy, and the roll-up may be performed by aggregating based on groups associated with the appropriate column)
…generating a query for the primary data source… (Cushing ¶ 0053: A query can be generated directly or indirectly from any combination of languages such as MDX, SQL, a report specification language, etc. For example, a query may be executed by running a report specification as illustrated in FIG. 4A to generate reports as illustrated in FIGS. 4B (without non-existent tuple removal) and 4C (with non-existent tuple removal))
wherein the linking fields correspond to fields in the … data source. (Ziauddin col. 4, lines 8-19: The dimension table 102 embeds the hierarchical relationships between granules in the various levels of the dimension. For example, row 108 indicates a mapping between the day granule "3", the month granule "m5", the quarter granule "q2" and the year granule "1988")
Cushing in view of Chitnis and Ziauddun and Li does not expressly disclose:
including generating a query for the primary data source that includes adding one or more linking fields,
Cushing in view of Chitnis and Ziauddun and Li further does not expressly disclose correspond[ing] to fields in the secondary data sources.
However, Brown teaches:
including generating a query for the primary data source that includes adding one or more linking fields, (Brown ¶ 0032, FIG. 5: the component accesses the primary data store to retrieve information about the entity; the component may store an entry identifier [linking field] from the secondary data store along with the entry in the primary data store to associate the information in the secondary data store with the related entry in the primary data store; retrieved information may contain a reference to a secondary data store that contains additional information about the entity; FIG. 1, ¶ 0015-0017 further emphasize the primary and secondary data stores)
wherein the linking fields correspond to fields in the secondary data source. (Brown ¶ 0032: the component sends a response to the request that contains the information from the primary data store and the additional information from the secondary data store)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the aggregation of data stored in multiple data stores of Brown.
In addition, both of the references (Cushing as modified and Brown) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would be to improve the functioning of the data aggregation of Cushing as modified with the data aggregation of similar reference Brown but with the improvement of the primary data store entry and secondary data store entry association with each other.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to allow access from multiple tables as if it were originating from one table (Brown ¶ 0006) as well as to optimize storage and memory usage as taught by Brown (¶ 0014).
Claims 12 and 19 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Cushing in view of Chitnis and Ziauddun and Wolge et al., U.S. Patent Application Publication No. 2013/0159307 (filed October 15, 2012; hereinafter Wolge).
Regarding claims 12 and 19, Cushing in view of Chitnis and Ziauddun teaches all the features with respect to claims 1 and 14 above but does not expressly disclose:
wherein the first data source and the second data source are not collocated.
However, Wolge teaches:
wherein the first data source and the second data source are not collocated. (Wolge ¶ 0087: a mass storage device 704, an operating system 705, Data Analysis software 706, data 707, a network adapter 708, system memory 712, an Input/Output Interface 710, a display adapter 709, a display device 711, and a human machine interface 702, can be contained within one or more remote computing devices 714a,b,c at physically separate locations)
It would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the data aggregation of Cushing as modified with the data conversion of Wolge.
In addition, both of the references (Cushing as modified and Wolge) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as management of data aggregation.
Motivation to do so would also be the teaching, suggestion, or motivation of one of ordinary skill in the art to minimize memory requirements in executing the computer program (Wolge ¶ 0052).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pasumansky et al., U.S. Patent Application Publication No. 2009/0228436; see Pasumansky ¶ 0035 describing aggregating by product-year-state in one data domain but by product-month-state in a different data domain, relevant to at least the independent claim limitations involving selecting an alternative set of fields for aggregation.
THIS ACTION IS MADE FINAL. 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 JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday, Tuesday, Friday, 12:00pm-9:00pm.
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, Kavita Stanley can be reached at (571)272-8352. 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.
/J.P.F/Examiner, Art Unit 2153 May 29, 2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights