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 .
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-4, 6-15, and 17-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a mental process without significantly more.
Independent claim 1 recites:
“A method, comprising:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw clickstream data and raw real-time streaming data;
extracting, utilizing a connection with one or more back end databases associated with the one or more target digital portals, transactional data corresponding to events of the one or more target digital portals;
storing the raw clickstream data in one or more storage components;
sending the raw real-time streaming data to a set of components configured to convert the raw real-time streaming data to reformatted real-time streaming data;
executing an extract, load, transform (ELT) pipeline to convert the stored raw clickstream data into transformed data;
storing the transformed data into one or more schemas;
generating, using a semantic layer comprising a cube file generating component configured to generate cube files for each captured new event from the one or more target digital portals, the cube files corresponding to respective events within the raw clickstream data, wherein the cube files specify one or more of measures, dimensions, joins, or pre-aggregations associated with digital portal data corresponding to the respective events;
receiving, from a user of a front-end application, an initial query corresponding to a requested action;
validating, using the semantic layer, column names and metrics of one or more of the cube files associated with the initial query;
generating, using the semantic layer and the validated one or more of the cube files, a structured query language (SQL) query based on the initial query;
generating results for the SQL query based on one or more of the reformatted real-time streaming data or the transformed data; and
outputting the generated results to the user of the front-end application.”
Claim 13 contains similar subject matter.
The independent claims contain mental process steps of “extracting … transactional data corresponding to events of the one or more target digital portals,” “executing an extract, load, transform (ELT) pipeline to convert the stored raw clickstream data into transformed data,” “generating, using a semantic layer comprising a cube file generating component configured to generate cube files for each captured new event from the one or more target digital portals, cube files corresponding to respective events within the raw clickstream data, wherein the cube files specify one or more of measures, dimensions, joins, or pre-aggregations associated with digital portal data corresponding to the respective events,” “validating, using the semantic layer, column names and metrics of one or more of the cube files associated with the initial query,” “generating, using the semantic layer and the validated one or more cube files, a structured query language (SQL) query based on the initial query,” and “generating results for the SQL query based on one or more of the reformatted real-time streaming data or the transformed data.” All of these steps are data analysis steps that may be accomplished by a human being using a generic computer.
Independent claims 1 and 13 contain additional elements beyond the mental process in the form of the “receiving…,” “storing…,” “sending…,” “storing…,” “receiving…,” and “outputting…” steps. Claim 13 also contains additional elements of “one or more memories…,” and “one or more processors…,”
This judicial exception is not integrated into a practical application because the claimed additional elements do not appear to improve the processing of a computer, require the use of a specific machine, effect a transformation or reduction of a particular article to a different state or thing, or provide a technological solution to a technological problem.
The “one or more memories” and “one or more processors” are recited at a high level of generality. They appear to be generic computing hardware elements. The recitation of generic hardware is little more than using a computer to perform an abstract idea, see MPEP 2106.05(f)(2). The “receiving…” steps appear to be a data gathering step, and is thus mere pre-solution insignificant activity (see MPEP 2106.05(g). The “storing…” steps are similarly insignificant extra-solution activity and is well-known (see MPEP 2106.05(d)(II) and MPEP 2106.05(g)). ”Sending…” data by simply transmitting information does not appear to improve the functioning of a computer or any technology or technical field because they involve the mere transmission of instructions (see MPEP 2106.05(a)). Outputting a result of a data analysis by displaying the results is insignificant post-solution activity (see MPEP 2106.05(g)(3)).
It is noted that none of the additional elements appear to improve the processing of a computer, require the use of a specific machine, effect a transformation or reduction of a particular article to a different state or thing, or provide a technological solution to a technological problem. As such, none of the additional elements appear to integrate the judicial exception into a practical application.
None of the additional elements are sufficient to amount to significantly more than the judicial exception, in part or in whole.
The “one or more memories” and “one or more processors” are little more than using a computer to perform an abstract idea, see MPEP 2106.05(f)(2). The additional element of the “receiving…” steps are merely extra-solution activity data gathering and is well understood, routine, and conventional (see MPEP 2106.05(g)). The “storing…” steps are nothing more than storing data in a memory, which is recognized as well-understood, routine, and conventional (see MPEP 2106.05(d)(II)). “Sending…” data by transmitting information appears to be regarded as well understood, routine, and conventional (see MPEP 2106.05(d)(II)). Outputting a result of a data analysis is insignificant extra-solution activity and is well known (see MPEP 2106.05(g)((3).
None of the additional elements, in part or in whole, appear to improve the processing of a computer, require the use of a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or add a specific limitation other than what is well understood, routine, or conventional. As such, none of the additional elements appears to be, in part or in whole, significantly more than the judicial exception.
Dependent claims 2-4, 6-12, 14-15, and 17-19 are merely directed towards additional limitations that further define data types or further describe analyses that will occur. The dependent claims contain additional “sending…” steps (claims 2, 6, 8, 17, and 18) and “storing…,” steps (claims 3-4, 7, and 14-15). However, as above, the “sending…” steps do not appear to improve the functioning of a computer or any technology or technical field because they involve the mere transmission of data (see MPEP 2106.05(a)) and the mere sending of data appears to be regarded as well understood, routine, and conventional (see MPEP 2106.05(d)(II)). The “storing…” steps merely store data and is insignificant extra-solution activity and is well known (see MPEP 2106.05(d)(II)). None of additional elements of dependent claims 2-4, 6-12, 14-15, and 17-19 appear to integrate the judicial exception into a practical application. None of the additional elements of dependent claims 2-4, 6-12, 14-15, and 17-19 are sufficient to amount to significantly more than the judicial exception, in part or in whole.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1-2, 9-10, 13, and 19 is rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930).
As to claim 1, Beg teaches a method, comprising:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw … data and raw real-time streaming data (see Beg paragraph [0028]. Beg creates an ETL data flow that receives input data from one or more sources, transforms the data, and routes the transformed data to a destination. As noted in paragraphs [0029] and [0047], Beg inputs real-time continuous, or streaming, data);
…
storing the raw … data in one or more storage components (see Beg paragraphs [0028]-[0029]. The data is received by the system is stored in defined schemas);
sending the raw real-time streaming data to a set of components configured to convert the raw real-time streaming data to reformatted real-time streaming data (see Beg paragraphs [0028]-[0029]. Data is transformed to an output format);
executing an extract, load, transform (ELT) pipeline to convert the stored raw … data into transformed data (see Beg paragraphs [0028]-[0029]. Data is transformed to an output format);
storing the transformed data into one or more schemas (see Beg paragraphs [0028]-[0029]. Transformed data is stored in an output schema);
…
Beg does not teach:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw clickstream data …;
extracting, utilizing a connection with one or more back end databases associated with the one or more target digital portals, transactional data corresponding to events of the one or more target digital portals;
storing the raw clickstream data in one or more storage components;
generating, using a semantic layer comprising a cube file generating component configured to generate cube files for each captured new event from the one or more target digital portals, the cube files corresponding to respective events within the raw clickstream data, wherein the cube files specify one or more of measures, dimensions, joins, or pre-aggregations associated with digital portal data corresponding to the respective events; and
receiving, from a user of a front-end application, an initial query corresponding to a requested action;
validating, using the semantic layer, column names and metrics of one or more of the cube files associated with the initial query;
generating, using the semantic layer and the validated one or more of the cube files, a structured query language (SQL) query based on the initial query;
generating results for the SQL query based on one or more of the reformatted real-time streaming data or the transformed data; and
outputting the generated results to the user of the front-end application.
Ogievetsky teaches:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw clickstream data (see paragraph [0027]. Data sources relied upon in Ogievetsky include clickstream data) …;
extracting, utilizing a connection with one or more back end databases associated with the one or more target digital portals, transactional data corresponding to events of the one or more target digital portals (see Ogievetsky paragraphs [0060]-[0061]. A database is periodically checked to determine if new data needs to be pulled into the visualization);
storing the raw clickstream data in one or more storage components (see paragraph [0028]. Raw data is at least temporarily stored. As noted in paragraph [0027], raw data includes clickstream data);
generating, using a semantic layer comprising a cube file generating component configured to generate cube files for each captured new event from the one or more target digital portals, the cube files corresponding to respective events within the raw clickstream data, wherein the cube files specify one or more of measures, dimensions, joins, or pre-aggregations associated with digital portal data corresponding to the respective events (see Ogievetsky paragraphs [0047]-[0048] and [0027]. A data cube may be built over the data sources. It is noted that the data sources include clickstream data. As noted in paragraph [0048], “data cubes may be dynamic and backed by streaming data with high-frequency updates from the data sources.” Paragraph [0049] discloses how the data cube includes measurements and dimensions);
receiving, from a user of a front-end application, an initial query corresponding to a requested action (see Ogievetsky paragraph [0052]. Users may query the cube by filtering it);
…
generating, using the semantic layer … , a structured query language (SQL) query based on the initial query (see Ogievetsky paragraph [0028] for support of SQL queries and [0075]-[0076]. A user can issue a query for the data cube. The system generates an SQL query to retrieve the data and populate the data cube);
generating results for the SQL query based on one or more of the reformatted real-time streaming data or the transformed data (see Ogievetsky paragraph [0054]. Results are calculated and displayed to a user); and
outputting the generated results to the user of the front-end application (see Ogievetsky paragraph [0054] and [0075]-[0076]. Results are calculated and displayed to a user).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Ogievetsky because both references are directed towards managing ETL functions for inputting streaming data and because Ogievetsky provides to Beg a dynamic query mechanism to facilitate data exploration, ad-hoc data analytics, and interactive visualizations (see paragraph [0005]), which will help a user of Beg to more easily navigate the ingested data.
Colle teaches:
validating, using the semantic layer, column names and metrics of one or more of the cube files associated with the initial query (see paragraphs [0016]-[0017]. The dimensions and data in Cubes may be validated before performing user filters and queries);
generating, using the semantic layer and the validated one or more of the cube files, a structured query language (SQL) query based on the initial query (see Colle paragraphs [0016]-[0017] for validating a cube to help with user querying. See Ogievetsky paragraph [0028] for support of SQL queries and paragraphs [0075]-[0076] for generating an SQL query for a cube based on an initial filtering operation. The references combined teach the claimed subject matter);
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Colle because both references are directed towards managing data for user searching and filtering. Colle provides to Beg a validation method that facilitates user filtering operations, which will help a user of Beg to more easily navigate the ingested data.
As to claim 2, Beg as modified by Ogievetsky teaches the method of claim 1, wherein sending the raw data of the one or more target digital portals to the set of components or to the ELT pipeline is based on a data type of the raw data (see Ogievetsky paragraphs [0048]-[0050]).
As to claim 9, Beg as modified by Ogievetsky teaches the method of claim 1, wherein generating, using the semantic layer, the cube files corresponding to the respective events within the received raw data further comprises:
detecting, for an existing event, an additional attribute associated with the existing event (see Ogievetsky paragraph [0121]); and
adding the additional attribute to an existing cube file corresponding to the existing event (see Ogievetsky paragraph [0121]).
As to claim 10, Beg as modified by Ogievetsky teaches the method of claim 1, wherein the generated results comprise values corresponding to a user-selected aggregate function applied to one or more user properties or one or more event properties (see Ogievetsky paragraph [0048]-[0050]).
As to claim 13, see the rejection of claim 1.
As to claim 19, see the rejection of claim 9.
Claims 3-4 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Das et al. (US Patent 11,941,014).
As to claim 3, Beg as modified teaches the method of claim 1, wherein executing the ELT pipeline to convert the stored raw clickstream data into the transformed data, and storing the transformed data into one or more schemas further comprises:
storing the transformed data in an operational data store (ODS) schema (see Beg paragraphs [0029]-[0034]. Input data is transformed into an operational schema);
extracting the stored transformed data from the ODS schema (see Beg paragraphs [0029]-[0034]. The data in the operational schema is extracted); and
Beg as modified does not teach:
joining the extracted transformed data with secondary tables comprising internal back end data.
Das teaches:
joining the extracted transformed data with secondary tables comprising internal back end data (see Das 26:35-61).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Das because both references are directed towards managing data from multiple sources and because Das provides to Beg a method of adaptive querying that allows customers to write queries regardless of the differences between storage locations (see Das 26:35-61).
As to claim 4, Beg as modified by Das teaches the method of claim 3, wherein storing the transformed data into the one or more schemas further comprises storing the joined extracted data and the secondary tables into an enterprise data warehouse schema (see Das 26:35-61).
As to claim 14, see the rejection of claim 3.
As to claim 15, see the rejection of claim 4.
Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Wing et al. (US Pre-Grant Publication 2017/0083386).
As to claim 5, Beg as modified by Ogievetsky teaches the method of claim 1, wherein the set of components comprise:
…
a distributed event streaming platform configured to:
receive the raw real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. Streaming data may be received and processed using OLAP into data cubes) … ; and
stream, using a streaming engine, the raw real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]); and
a real-time distributed Online Analytical Processing (OLAP) component (see Ogievetsky paragraphs [0025]) configured to:
ingest the streamed raw real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]);
convert the ingested raw real-time streaming data to reformatted real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The data is converted into a cube format);
index the reformatted real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The data is indexed into a cube); and
store the indexed reformatted real-time streaming data for querying (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The processed data may be filtered in response to a user instruction).
Beg as modified does not teach:
a webhook configured to send the raw real-time streaming data downstream;
receive the raw real-time streaming data from the webhook
Wing teaches:
a webhook configured to send the raw real-time streaming data downstream (see Wing paragraphs [0039]. Webhooks may be used to receive event data streams);
receive the raw real-time streaming data from the webhook (see Wing paragraphs [0039] and [0132]-[0133]. Data streams may be received and processed into OLAP data structures).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Wing because both references are directed towards managing data from multiple sources and because Wing provides to Beg an additional method of accepting streaming data triggered by events, which will expand the data sources available to a user of Beg.
As to claim 16, see the rejection of claim 5.
Claims 6 and 17 rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Hao et al. (US Pre-Grant Publication 2019/0130007).
As to claim 6, Beg as modified teaches the method of claim 1, further comprising:
sending the raw clickstream data in the one or more storage components to a unified analytics engine component (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]);
partitioning, using the unified analytics engine component, the raw clickstream data in the one or more storage components into a series of partitions (see Ogievetsky paragraphs [0047]-[0048]);
…
populating a series of relevant attributes associated with the respective events (see Ogievetsky paragraphs [0047]-[0048]); and
creating meta files for the respective events (see Ogievetsky paragraphs [0047]-[0048]).
Beg as modified does not teach:
flattening schemas corresponding to the respective events within the raw clickstream data;
standardizing column names of the flattened schemas by removing irregularities within the column names;
Hao teaches:
flattening schemas corresponding to the respective events within the raw clickstream data (see Hao paragraph [0035]. Source schemas are flattened to produce flattened tables);
standardizing column names of the flattened schemas by removing irregularities within the column names (see Hao paragraph [0035]. Column names may be standardized);
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Hao because both references are directed towards managing ETL processes and because Hao provides to Beg a way of reducing the complexity of mapping and transformation when extracting and processing input data (see Hao paragraph [0035]).
As to claim 17, see the rejection of claim 6.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Hopeman et al. (US Pre-Grant Publication 2003/0204534).
As to claim 7, Beg as modified teaches the method of claim 1.
Beg as modified does not teach further comprising:
storing the cube files into a binary large object storage component.
Hopeman teaches:
storing the cube files into a binary large object storage component (see Abstract and paragraph [0060]. Cubes may be stored as binary large objects).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Hopeman because both references are directed towards managing data and because Hopeman provides to Beg an improved interface for managing multidimensional data that allows for a user to perform analyses of the multidimensional data (see Hopeman paragraph [0060]).
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Roy et al. (US Pre-Grant Publication 2025/0300978).
As to claim 8, Beg as modified teaches the method of claim 1.
Beg as modified does not teach further comprising:
in response to receiving a bulk export request from the user, sending, a dataset comprising stored event records to a binary large object storage component; and
sending, to the user, a notification including a link to download the dataset.
Roy teaches further comprising:
in response to receiving a bulk export request from the user, sending, a dataset comprising stored event records to a binary large object storage component (see Roy paragraph [0017]); and
sending, to the user, a notification including a link to download the dataset (see Roy paragraph [0017]).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Roy because both references are directed towards managing data and because Roy provides to Beg a more secure and efficient approach to data analysis in response to user requests via a data management UI (see Roy paragraph [0018]).
As to claim 18, see the rejection of claim 8.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), and further in view of Colle et al. (US Pre-Grant Publication 2014/0258930), and further in view of Harik et al. (US Pre-Grant Publication 2011/0264508).
As to claim 11, Beg as modified teaches the method of claim 1.
Beg as modified does not teach wherein the generated results are based on calculating a number of users that convert from a previous event to a next subsequent event within a predetermined duration of time.
Harik teaches wherein the generated results are based on calculating a number of users that convert from a previous event to a next subsequent event within a predetermined duration of time (see Harik paragraph [0043] and [0045]. Click-through rates and conversion counts in a particular window of time may be tracked).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Harik because both references are directed towards data analysis and because Harik provides to Beg different data analysis to perform when measuring data, which will give a user additional insights into the collected data to help a user better understand data and trends.
As to claim 12, Beg as modified by Harik teaches the method of claim 11, further comprising: generating secondary results by adjusting the predetermined duration of time (see Harik paragraph [0045]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Beg et al. (US Pre-Grant Publication 2024/0020313) in view of Ogievetsky (US Pre-Grant Publication 2022/0382779), in view of Wing et al. (US Pre-Grant Publication 2017/0083386).
As to claim 20, Beg teaches a method comprising:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw … data and raw real-time streaming data (see Beg paragraphs [0028]-[0029] and [0047]);
extracting, utilizing a connection with one or more back end databases associated with the one or more target digital portals, transactional data corresponding to events of the one or more target digital portals;
storing the raw … data in one or more storage components (see Beg paragraphs [0028]-[0029]);
sending the raw real-time streaming data to a set of components configured to convert the raw real-time streaming data to reformatted real-time streaming data (see Beg paragraphs [0028]-[0029]);
…
executing an extract, load, transform (ELT) pipeline to convert the stored raw clickstream data into transformed data (see Beg paragraphs [0028]-[0029]. Data is transformed to an output format);
storing the transformed data into one or more schemas (see Beg paragraphs [0028]-[0029]. Transformed data is stored in an output schema); and
Beg does not teach:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw clickstream data;
storing the raw clickstream data in one or more storage components;
wherein the set of components comprises:
a webhook configured to continually process the raw real-time streaming data;
a distributed event streaming platform configured to:
receive the processed raw real-time streaming data from the webhook; and
stream, using a streaming engine, the raw real-time streaming data; and
a real-time distributed Online Analytical Processing (OLAP) component configured to:
ingest the streamed raw real-time streaming data;
convert the ingested raw real-time streaming data to reformatted real-time streaming data;
index the reformatted real-time streaming data; and
store the indexed reformatted real-time streaming data for querying;
generating, using a semantic layer, cube files corresponding to respective events within the raw clickstream data; and
processing a user query associated with the one or more target digital portals by accessing one or more of the reformatted real-time streaming data or the transformed data, wherein the user query is at least partially derived from the cube files.
Ogievetsky teaches:
receiving, from one or more target digital portals, raw data of the one or more target digital portals comprising raw clickstream data (see Ogievetsky paragraph [0027]);
storing the raw clickstream data in one or more storage components (see Ogievetsky paragraphs [0047]-[0048] and [0027]);
wherein the set of components comprises:
...
a real-time distributed Online Analytical Processing (OLAP) component (see Ogievetsky paragraphs [0025]) configured to:
ingest the streamed raw real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]);
convert the ingested raw real-time streaming data to reformatted real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The data is converted into a cube format);
index the reformatted real-time streaming data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The data is indexed into a cube); and
store the indexed reformatted real-time streaming data for querying (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]. The processed data may be filtered in response to a user instruction);
…
generating, using a semantic layer, cube files corresponding to respective events within the raw clickstream data (see Ogievetsky paragraphs [0025], [0027], and [0047]-[0048]); and
processing a user query associated with the one or more target digital portals by accessing one or more of the reformatted real-time streaming data or the transformed data, wherein the user query is at least partially derived from the cube files (see Ogievetsky paragraphs [0025], [0027], [0047]-[0048] and [0075]-[0076]).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Ogievetsky because both references are directed towards managing ETL functions for inputting streaming data and because Ogievetsky provides to Beg a dynamic query mechanism to facilitate data exploration, ad-hoc data analytics, and interactive visualizations (see paragraph [0005]), which will help a user of Beg to more easily navigate the ingested data.
Wing teaches:
wherein the set of components comprises:
a webhook configured to continually process the raw real-time streaming data (see Wing paragraphs [0039]. Webhooks may be used to receive event data streams);
a distributed event streaming platform configured to:
receive the processed raw real-time streaming data from the webhook (see Wing paragraphs [0039] and [0131]-[0133]. Data streams may be received and processed into OLAP data structures); and
stream, using a streaming engine, the raw real-time streaming data (see Wing paragraphs [0039] and [0131]-[0133]); and
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Beg by the teachings of Wing because both references are directed towards managing data from multiple sources and because Wing provides to Beg an additional method of accepting streaming data triggered by events, which will expand the data sources available to a user of Beg.
Response to Arguments
Applicant's arguments filed 29 July 2026 have been fully considered but they are not persuasive.
Applicant argues that “Applicant respectfully submits that the Office Action's characterization of independent Claims 1 and 13 as reciting a mental process is in error because the claims, when considered as a whole, recite a specific machine-implemented architecture and workflow for ingesting, transforming, and querying heterogeneous digital portal data that cannot practically be performed in the human mind.”
Applicant elaborates, listing out the “receiving…,” “extracting…,” “sending…,” “executing...”, “storing…,” “generating…,” “validating…,” “generating…,” and “generating…,” steps.
In response to this argument, it is noted that the “extracting…,” “executing...”, “generating…,” “validating…,” “generating…,” and “generating…,” steps are all mental process steps that a human being equipped with a generic computer is capable of performing. They are not additional elements beyond the mental process. The remaining steps are addressed as additional elements in the rejection above.
Applicant continues, arguing that “the Office Action is applying an erroneous standard. The MPEP describes "In evaluating whether a claim that requires a computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. For instance, examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process. See MPEP § 2106.04(a)(22), Section III(C), emphasis added. In other words, even if the claim features are performed on a generic computer (a point which Applicant does not concede), the claim features must still be performable in the human mind (or by a human using pen and paper) to recite a mental process.”
In response to this argument, a human mind is capable of performing the “extracting…,” “executing...”, “generating…,” “validating…,” “generating…,” and “generating…” steps.
For example, a human being is capable of “validating … column names and metrics of one or more of the cube files associated with the initial query.” A human being, with pen and paper or a generic machine, can go through logical processes to validate data by looking at the data.
This analysis is true of each of the listed claim elements (absent any generic computing elements contained in the claimed elements). Thus, the claims do contain mental process steps.
Applicant argues that “For example, in Ex Parte Hannun et al., an informative opinion from the PTAB, the PTAB found that claims directed to a computer-implemented method for transcribing speech were not directed to a mental process because they could not be practically performed mentally. Appeal No. 2018-003323, p. 9-10. (P.T.A.B. April 1, 2019) ("Ex Parte Hannun"). The PTAB found that "[w]hile transcription generally can be performed by a human, the claims here are directed to a specific implementation including the steps of normalizing an input file, generating a jitter set of audio files, generating a set of spectrogram frames, obtaining predicted character probabilities from a trained neural network and decoding a transcription of the input audio using the predicted character probability outputs." Id., pp. 9-10. Because "[t]hese are not steps that can practically be performed mentally," the claims did not recite a mental process. Id., p. 10.”
In response to this argument, it is noted that none of the current limitations are directed toward “generating a jitter set of audio files,” “generating a set of spectrogram frames,” or “obtaining predicted character probabilities from a trained neural network and decoding a transcription of the input audio using the predicted character probability outputs.”
Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
In response to this argument, Applicant argues that “Applicant respectfully submits that the Office Action's characterization of independent Claims 1 and 13 as reciting a mental process is in error because the claims, when considered as a whole, recite a specific machine-implemented architecture and workflow for ingesting, transforming, and querying heterogeneous digital portal data that cannot practically be performed in the human mind.”
In response to this argument, the Examiner is not arguing that the entirety of the claim, as a whole, can be performed solely in the human mind. Instead, the Examiner is arguing that the claim contains mental process steps, as outlined above.
Applicant asserts that “claim 1 recites a coordinated sequence of operations, including” several of the claimed steps.
Applicant elaborates, “Regarding Claims 1 and 13 as-filed, the Office Action alleges "All of these steps are data analysis steps that may be accomplished by a human being using a generic computer." See Office Action at p. 4. However, Applicant respectfully submits that the Office Action is applying an erroneous standard. The MPEP describes "In evaluating whether a claim that requires a computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. For instance, examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process. See MPEP § 2106.04(a)(22), Section III(C), emphasis added. In other words, even if the claim features are performed on a generic computer (a point which Applicant does not concede), the claim features must still be performable in the human mind (or by a human using pen and paper) to recite a mental process.”
In response to this argument, Examiner notes that the rejection does not insist that all of the steps of the claims may be accomplished by a human being using a generic computer. Instead, Examiner separated the claimed elements into those that are mental process steps and those that are additional elements beyond the mental process.
The claimed “extracting…,” “executing…,” “generating…,” “validating…,” “generating…,” and “generating…” steps appears as if they may be accomplished by a human being using a generic computer. For example, as noted above with reference to the “validating…,” step, a human being equipped with a generic computer is capable of performing validation of data by analyzing the data. This analysis applies to each of the claimed mental process steps. The claimed “receiving…,” “sending….,” and “storing…,” steps appear as if they may be additional elements. However, as noted above, each of those elements does not integrate the mental process steps into a practical application nor provide significantly than the mental process.
Applicant argues that “With regard to the recited features of Claims 1 and 13 discussed above, these features are not akin to mere observation, evaluation, or judgment that could practically be carried out mentally or with pencil and paper. Rather, they recite features involving extraction of digital portal data via direct connection with back-end databases, differentiated handling of multiple data types, conversion of raw real-time streaming data into reformatted streaming data using a set of computer-based components configured for that purpose, execution of an ELT pipeline on stored clickstream data, storage of transformed data into schemas, generation of cube files using a semantic layer, and generation of an SQL query and corresponding results based on the combined use of cube files and transformed or reformatted data. The recited operations therefore define a computer-centric data-ingestion and analytics pipeline that is not practically performable in the human mind.”
As noted in MPEP 2106.04(a)(2) III C, “claims can recite a mental process even if they are claimed as being performed on a computer.
The Supreme Court recognized this in Benson, determining that a mathematical algorithm for converting binary coded decimal to pure binary within a computer’s shift register was an abstract idea. The Court concluded that the algorithm could be performed purely mentally even though the claimed procedures "can be carried out in existing computers long in use, no new machinery being necessary." 409 U.S at 67, 175 USPQ at 675. See also Mortgage Grader, 811 F.3d at 1324, 117 USPQ2d at 1699 (concluding that concept of "anonymous loan shopping" recited in a computer system claim is an abstract idea because it could be "performed by humans without a computer").”
MPEP 2106.04(a)(2) III C 1-3 further elaborate on the idea that a claim may still be directed towards an abstract idea despite the use of a generic machine. Thus, though the claims may not be performed solely in a human mind, the “extracting…,” “executing…,” “generating…,” “validating…,” “generating…,” and “generating…” steps may be performed by a human with a generic computer.
As note above, the steps listed as mental process steps appear to be data analysis steps that occur in the context of the claimed invention. Those data analysis steps are mental process that a human being equipped with a generic computer is capable of performing.
It is additionally noted that the claims do not appear to require “differentiated handling of multiple data types.” Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Applicant argues that “the specification provides direct support to confirm that the claimed subject matter is directed to computer-implemented processing of diverse portal data through a specialized architecture. For example, Applicant's Specification states that "... aspects described herein provide a technical solution to the described shortcoming of conventional techniques by utilizing novel system architecture including improved staging layers configured to ingest (for subsequent processing) diverse digital portal data in a more efficient and comprehensive manner." See Applicant's Specification at [0024]. The specification further explains that the computer- implemented system architecture includes "a staging layer configured to utilize direct connections with back end databases associated with one or more digital portals, enabling aspects herein to ingest and process digital portal data with improved fidelity and reduced data loss." Id., emphasis added. The claims are thus directed to implementation details of a computer-based data architecture, not to a disembodied mental concept.”
In response to this argument, it is noted that the clams require neither “diverse digital portal data” nor “direct connections” with back end databases. As such, the current claims do not contain subject matter that appears to be required to realize the purported improvements from the specification.
Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Applicant argues that “Further, the claimed use of a semantic layer and cube files underscores that the claims are not directed to mental steps. The specification explains that generated cube files "represent the digital portal data across multiple dimensions, and organize the data to enable more efficient querying and aggregation for facilitating downstream performance of various data analytic functions." See id., [0049]. The specification further explains that a "query building component 613 of semantic layer 610 may be configured to communicate with a server of a cube.js framework to cause the cube.js framework to validate column names and metrics of one or more cube files," and may "generate an improved query (e.g. an SQL query) based on the cube files and the received high-level query," which is then used "to generate results for the improved query by fetching the transformed data." See id., [0049]. Such operations are plainly not the sort of acts that can practically be carried out in the human mind.”
In response to this argument, it is noted that the claims do not require “"query building component 613 of semantic layer 610 may be configured to communicate with a server of a cube.js framework to cause the cube.js framework to validate column names and metrics of one or more cube files.” While a validation is performed, the details from the specification on how this is done are not claimed.
It is noted that a human being equipped with a generic computer is capable of performing a generic validation of data types. Similarly, generating a query in view of data is something that a human being with a generic computer is capable of performing.
Thus, as claimed, these elements appear to merely be mental process and data analysis steps. Even if they are an improvement, an improved mental process remains a mental processed and is patent ineligible.
Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Applicant argues that “Applicant's Specification expressly identifies various technological problems with certain conventional systems for ingesting and processing digital portal data.”
Applicant then cites paragraphs [0023]-[0025] of the specification and adds “Thus, Claim 1 is not merely directed to collecting data and displaying a result. Instead, Claim 1 recites a specific architecture and ordered combination of steps for: (1) receiving raw clickstream data and raw real-time streaming data from digital portals; (2) extracting transactional event data through a connection with one or more back-end databases; (3) routing different data types to different processing paths; (4) converting real-time streaming data to reformatted streaming data using configured components; (5) executing an ELT pipeline to transform stored clickstream data into transformed data and schemas; (6) generating cube files corresponding to events using a semantic layer; and (7) generating improved queries and corresponding results based on the semantic layer, cube files, reformatted streaming data, and transformed data. In turn, Claims 1 and 13 recite specific technological implementation directed to improving the fidelity, efficiency, and comprehensiveness of computer-based digital portal data ingestion and analytics.”
In response to this argument, it is noted that not all of the subject matter that leads to any alleged improvements from Applicant’s specification is claimed. Specifically, the claims do not require “a staging layer configured to utilize direct connections with back end databases associated with one or more digital portal.” It is also noted that the claims do not require processing “diverse digital portal data.”
Applicant is reminded that unclaimed features from the specification do not receive patentable weight until claimed.
Applicant argues that “The claims as supported by Applicant's Specification further provide for improved computer functionality in the relevant technical context based on describing that the recited cube files organize the digital portal data "to enable more efficient querying and aggregation." See Applicant's Specification at [0049]. In particular, Applicant's Specification describes how the query building component of the semantic layer communicates with a cube framework to validate column names and metrics and generate an SQL query based on cube files and a received initial query from a user, such as a high-level query, which is then used to generate results from transformed data stored in schemas. See id. Thus, the claims do not merely use a computer as a tool to perform an otherwise abstract process. Rather, they recite a specific improvement to computer-implemented data ingestion, transformation, organization, and querying.”
In response to this argument, it is noted that organizing, aggregating, and searching data are mental process steps that a human being equipped with a generic computer is capable of performing. An improved mental process remains a mental process, albeit improved, and remains patent ineligible.
It is additionally noted that the claims do not require any “downstream performance of various data analytics functions.”
Applicant is reminded that unclaimed features of the specification receive no patentable weight until claimed.
Applicant adds “For at least the reasons above, Applicant respectfully submits Claims 1 and 13 are analogous to the claims in cases in which the Federal Circuit found eligibility where the claims were rooted in computer technology to solve a problem arising in computer systems and networks. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258-59 (Fed. Cir. 2014). Here too, the claimed solution is necessarily rooted in computer technology because it addresses technical problems arising from conventional systems and processes for ingesting and processing digital portal data, including latency, data loss, incomplete ingestion of internal back-end data, and inefficient querying.”
Applicant argues “Accordingly, even if the claims were deemed to recite an abstract idea, Applicant respectfully submits that Claims 1 and 13, as a whole, integrate any such alleged abstract idea into a practical application in the form of a technical solution to technical problems in computer-based digital portal data ingestion and processing. The claims are therefore patent eligible under Step 2A, Prong Two. Applicant notes that Claim 20 is allowable for similar reasons as it recites certain described features that provide for the above-described technical solutions and benefits while further incorporating the allowable features of Claim 5.”
As noted above, Applicant’s arguments rely upon unclaimed features from the specification. As such, Applicant’s arguments are unpersuasive.
Applicant argues that “The Office Action asserts that the "receiving," "storing," "sending," and "outputting" limitations are merely extra-solution activity and well-understood, routine, and conventional, and concludes that "[n]one of the additional elements ... appears to be, in part or in whole, significantly more than the judicial exception." See Office Action, pp. 5-6, 8-10. However, that analysis improperly dissects the claims into isolated verbs and ignores the ordered combination actually recited. At a minimum, Applicant respectfully submits that the Office Action does not provide an adequate factual basis, in accordance with the standards discussed above, for concluding that the claimed combination, as arranged and recited, was well-understood, routine, and conventional. Furthermore, even if individual components such as memory, processors, storage, or query generation may be known in the abstract, the relevant inquiry under Step 2B considers whether the claimed ordered combination amounts to significantly more. Here, Applicant respectfully submits it does.”
Applicant adds “In particular, the inventive concept lies in the specific arrangement of claim elements and the technological architecture they define. For example, Claims 1 and 13 recite a non-conventional combination of features that includes, among other things: receipt of heterogeneous raw portal data including clickstream and real-time streaming data; direct extraction of transactional event data using a connection with one or more back-end databases; conversion of raw real-time streaming data into reformatted streaming data by a configured set of components; execution of an ELT pipeline to transform stored clickstream data into transformed data and schemas; generation of cube files using a semantic layer; and generation of improved SQL queries and accompanying results based on both the cube files and the transformed or reformatted data. Applicant's Specification repeatedly describes, as discussed above at Step 2A Prong Two, how the recited features (such as contained within Claims 1 and 13) overcome deficiencies of conventional systems and provide technical benefits including improved fidelity, reduced data loss, fewer HTTP network calls, more comprehensive datasets, improved governance and security control, and more efficient querying. See Applicant's Specification at [0023] - [0025], [0049], [0098].”
In response to this argument, it is noted that the current claims do not require “receipt of heterogeneous raw portal data including clickstream and real-time streaming data” or “direct extraction of transactional event data using a connection with one or more back-end databases.” As such, the current claims do not embody any purported improvements recited by the specification.
Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Response to Rejections under 35 USC 103
Applicant argues that “The Office Action relies upon Ogievetsky and Das to cure the above deficiencies of Beg. However, despite Ogievetsky disclosing clickstream data as one possible data source, and visualization data cubes having dimensions and measures, Ogievetsky does not disclose the claimed relationships recited within Claims 1 and 13. See Ogievetsky at [0025], [0027]). In particular, Ogievetsky's cubes are created for and "defined on top of a datasource or SQL query", and are configured for interactive visualization. Id., [0025], [0048], emphasis added. The cited passages do not disclose "a cube file generating component configured to generate cube files for each captured new event from the one or more target digital portals," with those files "corresponding to respective events within the raw clickstream data" as recited in Claims 1 and 13. In addition, the cited passages of Ogievetsky further fail to disclose that the measures or dimensions are specified in event-corresponding cube files and "associated with digital portal data corresponding to the respective events" as recited in Claims 1 and 13. Although Ogievetsky discloses dimensions and measures generally, disclosure of those individual concepts does not establish the claimed event-to-cube-file relationship recited in Claims 1 and 13.”
In response to this argument, Ogievetsky teaches the generation of “cube files” for “each captured new event from the one or more target digital profiles” by showing that data cubes are generated from and kept up to date in view of new events (see Ogievetsky paragraphs [0047]-[0048] and [0027]. A data cube may be built over the data sources. It is noted that the data sources include clickstream data. As noted in paragraph [0048], “data cubes may be dynamic and backed by streaming data with high-frequency updates from the data sources.” Paragraph [0049] discloses how the data cube includes measures and dimensions).
It is noted that the claims do not contain a specific definition for “cube files” or “events.” Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Applicant argues that “Notably, the event-related example provided within Ogievetsky describes use of a "number of events" as a measure within a visualization cube and browser information as dimensions for splitting displayed data based on "a user input to split up the data by one or more dimensions in the visualization of the data cube." See id., [0052]. However, use of an event-related measure inside a datasource-level cube is not disclosure of the claimed relationship between respective events and corresponding cube files as recited in Claims 1 and 13. Interpreting any cube containing event data as satisfying the relationship of the recited claim features would read "corresponding to respective events" out of the claim features reciting "generating, using a semantic layer, cube files corresponding to respective events within the raw clickstream data" within Claims 1 and 13.”
In response to this argument, as noted above, the data cubes of Ogievetsky are “dynamic and backed by streaming with high-frequency updates from the data sources.” (see Ogievetsky paragraphs [0047]-[0048] and [0027]). Thus, Ogievetsky does show that the cubes containing event data satisfy the relationship of the generation of cube files corresponding to respective events within the raw clickstream data to the extent claimed.
As noted above, Applicant is reminded that unclaimed features from the specification receive no patentable weight until claimed.
Applicant argues that “As discussed above, the Office Action relies upon Ogievetsky and Das to cure the deficiencies of Beg with regard to the recited features related to querying. Ogievetsky generates database queries from visualization states, including user-selected splits, nesting levels, measures, filters, and visibility constraints. Id., [0052], [0067], [0076]. However, analyzing the schema of a datasource when initializing a seed cube as performed in Ogievetsky is not the same as validation of column names and metrics of query-associated cube files, such as provided within the features of Claim 1 reciting "validating, using the semantic layer, column names and metrics of one or more of the cube files associated with the initial query." Likewise, the generating of a query from visualization selections as performed in Ogievetsky is not "generating, using the semantic layer and the one or more of the validated cube files, a structured query language (SQL) query based on the initial query" as recited in Claim 1. With regard to the recited ordered sequence of operations, Ogievetsky also does not disclose the recited validation of the cube files followed by generation of the SQL query using the validated cube files.”
In response to this argument, it is noted that newly cited reference Colle in combination with Ogievetsky renders this subject matter obvious to one of ordinary skill in the art before the earliest filing date of the invention to the extent claimed for the reasons provided in the rejection above.
Applicant argues that “Accordingly, none of the cited references, alone or in any reasonable combination, establish the claimed ordered combination. In particular, none of the cited references teaches the claimed sequence in which the semantic layer generates event-corresponding cube files for captured new events (e.g., extracted from the digital portal data), validates column names and metrics of the cube files associated with the initial query, and then generates an SQL query based on the initial query using the validated cube files.”
As noted above, the combination of Beg, Ogievetsky, and Colle does teach the claimed subject matter to the extent claimed for the reasons provided in the rejection above.
Applicant argues that “The stated rationales in the Office Action for combining the references do not provide a rational basis for modifying the cited references to supply the missing architecture and ordered sequence of features. The Office Action reasons that Ogievetsky "provides to Beg a dynamic query mechanism to facilitate data exploration, ad-hoc data analytics, and interactive visualizations which will help a user of Beg to more easily navigate the ingested data." See Office Action, p. 12. The provided rationale does not explain why Ogievetsky's datasource-oriented visualization cubes would be replaced or modified to become event-corresponding cube files generated "for each captured new event," why the semantic layer would validate column names and metrics of cube files associated with an initial query, or why the resulting SQL query would be generated using those validated files.”
As noted above, Ogievetsky does teach event-corresponding cube files generated for each captured new event to the extent claimed (see paragraphs [0047]-[0048]). Ogievetsky is not relied upon to teach the validation of column names and metrics. Thus, motivation to “replace or modify” Ogievetsky in view of those features is not required.
Applicant argues that “Similarly, the Office Action reasons modifying Beg in view of Das "provides to Beg a method of adaptive querying that allows customers to write queries regardless of the differences between storage locations." See id., p. 13. However, the rationale provided by the Office Action concerns execution of queries across heterogeneous storage. It does not explain why a skilled artisan would introduce the preceding semantic-layer process of validating query-associated, event-corresponding cube files and generating an SQL query using the validated files. Adding Ogievetsky's visualization capability and Das's storage-independent query execution to Beg would not, without further modification and reasoning, produce the ordered sequence of features and accompanying architecture recited by amended claims 1 and 13.”
As noted above, newly cited reference Colle is relied upon to teach the validation step. An additional motivation to modify Beg in view of Colle has been provided in the rejection above.
Applicant argues that “Put differently, the proposed combination would not merely involve substitution of a known equivalent component. Rather, it would require reworking Beg's streaming-data transformation framework into a materially different semantic-layer architecture in which event- corresponding cube files are generated for captured new events and then used as validated query- building artifacts. The Office Action does not explain why a skilled artisan would have been motivated to make that architectural redesign, as opposed to simply using Ogievetsky as a downstream visualization interface and Das as a storage-tier query mechanism. Absent such reasoning, the rejection appears to rely on impermissible hindsight.”
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Applicant argues that “For at least the above reasons, Applicant respectfully submits that the rationales provided within the Office Action, as discussed above, identify general benefits of the visualization scheme of Ogievetsky and the adaptive querying of Das, but do not provide a proper rational basis to explain why a skilled artisan would have made the specific modifications necessary to arrive at the recited features of Claims 1 and 13. In turn, Applicant respectfully submits that the cited combinations therefore do not establish a prima facie case of obviousness with regard to Claims 1 and 13. Accordingly, Applicant respectfully requests withdrawal of the rejection of Claims 1 and 13 and allowance thereof.”
As noted above, Applicant’s identified “modifications” would not be needed in view of Ogievetsky. The cited references teach the claims to the extent claimed. The motivations provided give a rational basis for why one of ordinary skill in the art would combine the references to render the claims, to the extent claimed, as obvious.
Applicant argues that “For at least the reasons discussed above with regard to Claims 1 and 13, Applicant respectfully submits that Beg in view of Ogievetsky similarly fails to teach or suggest "extracting, utilizing a connection with one or more back end databases associated with the one or more target digital portals, transactional data corresponding to events of the one or more target digital portals" and "generating, using a semantic layer, cube files corresponding to respective events within the raw clickstream data" as recited in Claim 20. Accordingly, Applicant requests withdrawal of the rejection of Claim 20 and allowance thereof.”
In response to this assertion, it is noted that these limitations are taught by the cited references as set forth in the rejection above.
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 CHARLES D ADAMS whose telephone number is (571)272-3938. The examiner can normally be reached M-F, 9-5:30 EST.
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, Aleksandr Kerzhner can be reached at 5712701760. 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.
/CHARLES D ADAMS/ Primary Examiner, Art Unit 2165
