DETAILED ACTION
Status of the Claims
The following is a Non-final Office Action in response to amendments and remarks filed 23 September 2025 and 10 October 2025.
Claims 1 and 6 have been amended.
Claims 4 and 9 have been cancelled.
Claims 1-3, 5-8, and 10 are pending and have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10 October 2025 has been entered.
Response to Arguments
Applicant argues that the claims are patent eligible over §101 by satisfying Step 2A Prong 2; however the Examiner respectfully disagrees. Here, as noted in the previous rejection, the judicial exception is not integrated into a practical application (Step 2A Prong Two). The “retrieve,” “send,” “receive,” “store,” and “display” steps are simply insignificant extrasolution data gathering and post solution output activities. The “application programming interface (API)” is only recited as receiving input and the “graph dao (Data Access Object)” is only sending data, which are also simply insignificant extrasolution data gathering activities. Next, the claim only recites one additional element – using “a reporting service controller, coupled to the processor and the display, configured to:,” (or “by the report management system” in claim 6) to perform the steps. The reporting service controller and report management system in the steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of electronic data storage, query, and retrieval, some of the most basic functions of a computer) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Specifically the claims amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). The claims recitation of the “graph database,” “certified application programming interface (API)” “graph dao (Data Access Object),” and “communications” is/are only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.04(d)(I) discussing MPEP 2106.05(h). Accordingly, the combination of these additional elements does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea, even when considered as a whole (Step 2A Prong Two: NO). As such, this argument is not persuasive, and the rejection not withdrawn.
Applicant argues that the Hunn reference does not teach or disclose the amended claims; however the Examiner respectfully disagrees for a plurality of reasons. Firstly, and contrary to Applicant’s arguments regarding the instant claim language, the claims do in fact create a query via filtering the data prior to providing it to the user as “create one query to retrieve the based on the list of filters indicated in the BI report request, wherein the one query is configured by the list of filters to obtain specific data from the graph database” which clearly is reciting that the retrieved BI data from the graph database is using filters indicated (i.e. selected or chosen which is a creation of a query). To put another way, the instant claims are retrieving the BI data based upon some sort of received filtered criteria for a query as part of a query creation, before generating and storing the results or report (again contrary to Applicant’s assertions) which is precisely what a query does—a query is some sort of search which will query or search based upon received filters or keywords (as noted in the interview). Secondly, this is exactly what is disclosed by the Hunn reference, as previously cited “filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters (Hunn ¶119)” which clearly discloses that some sort of filter is selected/received/input by a user for which the data is then filtered and provided to the user. Thirdly, Hunn expressly recites how the database is able to be quired in various ways, none of which are limiting. Therefore, even assuming arguendo, one of ordinary skill in the art would reasonably interpret the various ways of querying the graph as including the instant claimed “create one query to retrieve the based on the list of filters indicated in the BI report request, wherein the one query is configured by the list of filters to obtain specific data from the graph database” This is also disclosed by Hunn (again, as previously cited and not addressed by Applicant) “These relationships in the graph structure can be queried to provide data and metadata on the relationships between the contract objects (Hunn ¶104)” which is clearly the ability to have a query based upon a filter (relationships) and thus a “only report query solution.” As such, this argument is not persuasive, and the rejection not withdrawn.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
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-3, 5-8, and 10 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims are directed to a process (an act, or series of acts or steps), a machine (a concrete thing, consisting of parts, or of certain devices and combination of devices), and a manufacture (an article produced from raw or prepared materials by giving these materials new forms, qualities, properties, or combinations, whether by hand labor or by machinery). Thus, each of the claims falls within one of the four statutory categories (Step 1). However, the claim(s) recite(s) generate business intelligence reports based upon requests with filters and a graph database which is an abstract idea of organizing human activities.
The limitations of “create a BI report request to download the BI report using a BI template from the plurality of BI templates, wherein the BI report request comprises a list of data filters and a specific report format required by a user; create a connection with a graph database, wherein the graph database comprises graphs containing nodes, edges, and properties, all of which are used to represent and store the BI data; create one query to retrieve the based on the list of filters indicated in the BI report request, wherein the one query is configured by the list of filters to obtain specific data from the graph database; generate, without other input from the user, the BI report comprising the retrieved BI data from the graph database, the retrieved BI data only being based on the one query,” as drafted, is a process that, under its broadest reasonable interpretation, covers organizing human activities--fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) but for the recitation of generic computer components (Step 2A Prong 1). That is, other than reciting “a reporting service controller, coupled to the processor and the display, configured to:,” (or “by the report management system” in claim 6) nothing in the claim element precludes the step from the methods of organizing human interactions grouping. For example, but for the “a reporting service controller, coupled to the processor and the display, configured to:,” (or “by the report management system” in claim 6) language, “create” “create” “create,” and “generate” in the context of this claim encompasses the user manually creating reports based upon information that has been requested which is a business relation/fundamental economic practice/commercial or legal interaction/managing personal behavior. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as one of the methods of organizing human activities but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activities” grouping of abstract ideas. Accordingly, the claim(s) recite(s) an abstract idea (Step 2A, Prong One: YES).
This judicial exception is not integrated into a practical application (Step 2A Prong Two). The “retrieve,” “send,” “receive,” “store,” and “display” steps are simply insignificant extrasolution data gathering and post solution output activities. The “application programming interface (API)” is only recited as receiving input and the “graph dao (Data Access Object)” is only sending data, which are also simply insignificant extrasolution data gathering activities. Next, the claim only recites one additional element – using “a reporting service controller, coupled to the processor and the display, configured to:,” (or “by the report management system” in claim 6) to perform the steps. The reporting service controller and report management system in the steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of electronic data storage, query, and retrieval, some of the most basic functions of a computer) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Specifically the claims amount to nothing more than an instruction to apply the abstract idea using a generic computer or invoking computers as tools by adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.04(d)(I) discussing MPEP 2106.05(f). The claims recitation of the “graph database,” “certified application programming interface (API)” “graph dao (Data Access Object),” and “communications” is/are only generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.04(d)(I) discussing MPEP 2106.05(h). Accordingly, the combination of these additional elements does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea, even when considered as a whole (Step 2A Prong Two: NO).
The claim does not include a combination of additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B). As discussed above with respect to integration of the abstract idea into a practical application (Step 2A Prong 2), the combination of additional elements of using reporting service controller and report management system to perform the steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Reevaluating here in step 2B, the “retrieve,” “send,” “receive,” “store,” and “display” step(s) which are insignificant extrasolution activities and “application programming interface (API)” and “graph dao (Data Access Object)” which are elements that are also only performing insignificant extrasolution activities are also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs court decisions in MPEP 2106.05(d)(II) indicate that the mere receipt or transmission of data over a network is well-understood, routine, and conventional function when it is claimed in a merely generic manner (as is here). Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim. As such, the claim(s) is/are not patent eligible, even when considered as a whole (Step 2B: NO).
Claims 2-3, 5, 7-8, and 10 are dependent on claims 1 and 6 and include all the limitations of claims 1 and 6. Therefore, claims 2-3, 5, 7-8, and 10 recite the same abstract idea of “generate business intelligence reports based upon requests with filters and a graph database.” The claim recites the additional limitations further limiting how the reports are generated and displayed, which is still directed towards the abstract idea previously identified and is not an inventive concept that meaningfully limits the abstract idea. Again, as discussed with respect to claims 1 and 6, the claims are simply limitations which are no more than mere instructions to apply the exception using a computer or with computing components. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Even when considered as a whole, the claims do not integrate the judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claims 1-3, 5-8, and 10 are therefore not eligible subject matter, even when considered as a 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 5-8, and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunn et al. (US PG Pub. 2018/0315141) and further in view of Siebel et al. (US PG Pub. 2017/0006135).
As per claims 1 and 6, Hunn discloses a report management system and method for generating business intelligence (BI) report, wherein the report management system comprises: a display; a processor; a storage coupled to the processor, wherein the storage storing a plurality of BI templates; a reporting service controller, coupled to the processor and the display, configured to (system, method, processor, Hunn ¶127; display, GUI dashboards, ¶46; user interface, API, ¶60):
create a BI report request to download the BI report using a BI template from the plurality of BI templates, wherein the BI report request comprises a list of data filters and a specific report format required by a user (data is stored and then be queried and used for analytics, Hunn ¶73 and ¶77);
create a connection with a graph database using a certified application programming interface (API), wherein the graph database comprises graphs containing nodes, edges, and properties, all of which are used to represent and store the BI data (One or more graphs may be used. For example, separate graph may be used for each chain/ledger, or graphs may be combined to model relationships on each chain and then linkages between chains to model interoperability. In one implementation this could be a graph per contract or a series of linked contracts. By doing so, it may serve as an extension to a graph data structure that models a contract (e.g. by linking common or related objects between the graph data structures), where applicable. Furthermore, graph data structures may model links between off-chain/off-ledger data and on-chain/on-ledger data. One such example may be, off-chain/off-ledger computable (or hybrid) clauses in a contract that are linked to or otherwise use on-chain/on-ledger data as inputs, product outputs, invoke and/or deploy on-chain/on-ledger code or perform some other operation. Graph data structures enables the relationships between on-chain/on-ledger code and perform business and contractual processes may be mapped to the graph, Hunn ¶81);
retrieve the BI data from the graph database using the certified API based on the list of filters indicated in the BI report request, wherein retrieve the BI data comprises (Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, Hunn ¶119):
accept a report name from the user (storing the data, reports, Hunn ¶75-¶79 and ¶108) (Examiner interprets the ability to run reports and store data as the ability for a user to name a specific report and save the report file);
accept the list of filters from the user (Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, Hunn ¶119);
create one query to retrieve the based on the list of filters indicated in the BI report request, wherein the one query is configured by the list of filters to obtain specific data from the graph database (The graph may be queried in a number of ways, including (but not limited to): (a) API and (b) using a SQL-based (or other) query language, Hunn ¶104; Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, ¶119; data can be stored and queried for analytics, ¶73; see also ¶110) (Examiner notes the created query based upon user input of filters as the creation of the only report query solution);
send the one query to the graph database using a graph dao (Data Access Object) interface through the certified API, wherein the one query triggers the certified API to obtain the BI graph from the graph database thereby integrating, in a scalable manner, a generic process of a BI tool by fetching data from the graph database with the one query to create the report which will be served to a user by a BI display screen, wherein the graph database is created from a Structured Query Language (SQL) database of inventory data (The graph may be queried in a number of ways, including (but not limited to): (a) API and (b) using a SQL-based (or other) query language, Hunn ¶104; The graph processing engine may operate on a distributed basis or may operate locally. In the former, the GPE preferably organizes the main memory of a cluster of machines as a globally addressable address space to store large scale data sets, ¶105; Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, ¶119; workflow automation tools, data aggregation tools, ¶120; The instructions can be executed by computer-executable components integrated with the application, applet, host, server, network, website, communication service, communication interface, hardware/firmware/software elements of a user computer or mobile device, wristband, smartphone, or any suitable combination thereof , ¶127; see also ¶110) (Examiner notes the user query/input of formatting/filtering for display as the equivalent to the filters in a BI report request); and
generate, without other input from the user, the BI report comprising the retrieved BI data from the graph database, the retrieved BI data only being based on the one query (visualizations and reports, Hunn ¶107-¶108; automate a computer-driven action, ¶106; automated system, ¶126);
store the BI report in the storage in association with the report name (storage, and presentation of business and other data, Hunn ¶26); and
display to the user, responsive to a demand from the user referring to the report name, the BI report on the display (The output of the analytic engine can then passed to data visualization engine 700 to display analytics results via GUI dashboards or other visualization means. As seen in FIG. 2, alternatively and where appropriate, data may be passed from the contract to analytics engines 600 and data visualization engine 700 directly, Hunn ¶46).
Hunn does not expressly disclose receive, responsive to the one query, a response comprising the BI data from the graph database using the graph dao interface through the certified API based on a CRUD (Create, Read, Update, Delete) operation.
However, Seibel teaches receive, responsive to the one query, a response comprising the BI data from the graph database using the graph dao interface through the certified API based on a CRUD (Create, Read, Update, Delete) operation (provides common database operations such as create, read, update, and delete, Seibel ¶163).
Both the Seibel and Hunn references are analogous in that both are directed towards/concerned with enterprise/business intelligence. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to include Seibel’s database operations in Hunn’s system to improve the system and method with reasonable expectation that this would result in a business intelligence management system that is able to provide improved reporting.
The motivation being that data visualization and analysis products may offer visualization and exploration tools, which may be useful for an enterprise, but generally lack complex analytic design and customizability with regard to their data. For example, existing data exploration tools may be capable of processing or displaying snapshots of historical statistical data, but lack offerings that can trigger analytics on real-time or streaming events or deal with complex time-series calculations. As big data, PaaS, IaaS, and cyberphysical systems have application to all industries, the systems, methods, algorithms, and other solutions in the present disclosure are not limited to any specific industry, data type, or use case (Seibel ¶85).
As per claims 2 and 7, Hunn discloses as shown above with respect to claims 1 and 6. Hunn further discloses wherein create the BI report request to download the BI report comprises: detect a template from the plurality of templates selected by a user; display the selected template on the report management system; and receive the list of filters and the specific requirements of the BI report in the selected template; create the BI report request to download the BI report based on the selected template, the list of filters and the specific requirements of the BI report (visualizations and reports, Hunn ¶107-¶108; Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, ¶119; see also ¶110).
As per claims 3 and 8, Hunn discloses as shown above with respect to claims 1 and 6. Hunn further discloses wherein certified template is specified by the certified API (API, API gateway, Hunn ¶67).
As per claims 5 and 10, Hunn discloses as shown above with respect to claims 1 and 6. Hunn further discloses wherein generate the BI report based on the specific report format required by the user comprises: determine a list of fields to be included in the BI report based on the specific report format required by the user; and generate the BI report comprising the list of fields with corresponding BI data retrieved from the graph database (visualizations and reports, Hunn ¶107-¶108; Aggregated feeds may preferably be used in addition. Events may be aggregated so that all users of a given organization see all events, or filtered according to various parameters (e.g. job function, contract signatory, organizational department, etc.). Feeds may also be filterable by event/action/notification type, source, date/time, or other appropriate parameters/filters. Feed data may be pushed via API to external systems (e.g. work-based chat/communication systems, IRC, other dashboards, etc.). Alternatively, or in addition, webhooks or any other appropriate mechanism may be used. Notifications/events may be permissioned so that only certain users may view certain types/sources of data, ¶119; see also ¶110).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629