DETAILED ACTION
This action is responsive to Request for Continued Examination filed on March 11, 2026.
The amendments filed on February 05, 2026 have been acknowledged and considered.
Claims 1, 19-23, 29 and 104-109 have been amended.
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 .
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 March 11, 2026 has been entered.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated March 11, 2026 is acknowledged by the examiner and the cited references have been
considered in the examination of the claims now pending.
Response to Amendment
Applicant's Remarks, filed February 05, 2026, has been fully considered and entered.
Accordingly, Claims 1-5, 7-8, 17-24, 29-31, 33-34 and 104-109 are pending in this application. Claims 1, 19-23, 29 and 104-109 have been amended. Claim 1 is independent claim. Claims 6, 9-16, 25-28, 32 and 35-103 were previously been canceled.
Response to Arguments
Applicant’s arguments, see pages 7-18, filed February 05, 2026, with respect to the
rejection of claim 1 have been fully considered, but they are not persuasive.
Argument 1: Applicant argues on the Applicant Arguments and Remarks: that the amended claim language “iteratively populating, by traversing the source group according to the iterator type, a plurality of batch reports” is not taught by Kovacs in view of Stadnisky. Specifically, applicant argues that Kovacs’ “iterates over a set of data” in paragraph [0039] is used to filter data in final reports for recipient-level preferences (i.e. customizing presentation per recipient using [Country_ID]-<$Country_ID> -type expression), and is therefore only used in automation for generating graphical presentations rather than a “data processing construct” that traverses source group data according to an iterator type. Applicant further argues that Kovacs’ iteration is “implicit… only capable of iterating once per report recipient” and that Stadnisky only identifies populations within the data (e.g. PBMC populations) rather than iteratively traversing source group data according to the iterator type.
Response to Argument 1: Examiner respectfully disagrees. Kovacs in view of Stadnisky still teaches the amended-argued claim limitations. Examiner would like to clarify that applicant’s characterization that Kovacs “iterates once per report recipient” is not commensurate with the actual disclosure of Kovacs. Kovacs paragraph [0039] expressly states that the system provides “the ability to easily define custom data driven automation that iterates over a set of data to provide individual reports across an unlimited number of breaks.” The “set of data” being iterated over is the data set that comprises the source group, and the “breaks” represent each traversal step. Kovacs paragraph [0037] further states that a data workflow engine allows the user to specify “each report recipient criteria for selecting a subset of data from the data set [e.g. iterator type] to be graphically presented in a report.” When the system iterates over an unlimited number of breaks where each break corresponds to a different value (e.g. a different Country_ID), the system is necessarily traversing the source group according to the iterator type (the Country_ID column). Thus, Kovacs teaches “traversing the source group according to the iterator type”. The Specification paragraph [0044] describes the iterator type as specifying “what aspect (e.g., which variable or which type of data or the like) of each data set is to be presented in each automatically generated report.” Kovacs’ Country_ID column [0039] is such an aspect, it specifies which variable (country identifier) is used to step through the source data, and for each row 46 in the automation driver table, the expression [Country_ID]=<$Country_ID> is evaluated by replacing the placeholder with the Country_ID value of the corresponding row. This is a step-wise traversal of the source group keyed to the iterator type (the Country_ID column). Thus, the iterator type in Kovacs (e.g. Country_ID column) operates as a unit of iteration that traverses the source group per-country basis to produce each batch report, as required by claim 1.
Stadnisky [0084, 0100-0101] disclose traversing source data according to a defined iterator (a gating tree applied per sample), where for example a first template component applies gating to gather all PBMCs, a second component finds samples having low PBMC amounts, and a third generates a batch report. Each stage iterates trough the source data (FCS files) according to the gating-tree iterator type, producing a separate batch report for each traversal step. Thus, Stadnisky teaches iteratively populating, by traversing the source group according to the iterator type, a plurality of batch reports. See rejection below.
Therefore Kovacs in view of Stadnisky still teaches the amended limitation of claim 1, and applicant’s argument is not persuasive.
Claim Objections
Claims 23 and 29 is objected to because of the following informalities:
Claim 17, which depends on claim 1, recites “receiving a data set of the source group”, should read “receiving one data set of the plurality of data sets of the source group”. Claim 1 already recites “the source group comprises a plurality of data sets”
In claim 23 “each batch report corresponds to each traversal” seems unclear. It’s not clear whether each batch report correspond to a respective (one) traversal, or each batch report correspond to every traversal. Examiner request clarification from Applicant.
Claim 23 also recites the phrase “by iterator type” which lacks a definite article and is inconsistent with the terminology of independent claim 1. It should read “according to the iterator type”
In claim 29, “a graphical presentation of each batch reports.”, the phrase “each batch reports” should read “each batch report” or “the batch reports”.
In claim 106 recites “wherein a data set of the source group comprises constituent data elements” seems to confuse the antecedent basis of claim 1 which already recites “the source group comprises a plurality of data sets”. The use of “a data set” in claim 106 creates ambiguity as to whether it refers to one specific data set of the previous recited plurality, or any data set of the previous recited plurality, or an a newly introduced data set. Examiner request clarification from Applicant.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 7-8, 17, 19-24, 29-31, 33-34 and 104-109 are rejected under 35 U.S.C. 103 as being unpatentable over Kovacs (US Patent Application Publication No. US 20150067520 A1), in view of Stadnisky (US Patent Application Publication No. US 20160170980 A1).
Regarding claim 1, Kovacs teaches a computer-implemented method for automatically generating reports, the method comprising: generating, based on input from a user, a report template; (See Kovacs abstract “A system and method is provided for batch generation of graphic reports from one or more data sets for multiple recipients including, among other features, creation of a report template [Thus, generating, based on input from a user, a report template] for graphically presenting information regarding a plurality of subsets of the data set… also provides for a user to specify the data set(s) and to automatically and periodically send a generated report to each report recipient. [Thus, automatically generating reports]” See also Kovacs [0034] “FIG. 1 is a screen capture 10 of the present system illustrating the ability to create a report/report template for graphically representing information regarding data and subsets of data… As seen in the screen capture 10, the system 83 provides report generation tabs 14 (Report Book, Data Sets, Data Sources, Style Palettes and Indicators) from which a user may generate graphical reports by clicking on a report generation tab 14 and utilizing its components, options, selections and the like [Thus, based on input from a user]”)
selecting, based on input from the user, a source group and an iterator type, wherein the source group comprises a plurality of data sets, and the iterator type corresponds to a type of data present in the source group; and (See Kovacs [0035] “In the screen capture 10, the Report Book tab 13 has been selected… A page 12 of the report template as shown in area 17 can have its properties selected, de-selected, or modified as desired with the shown properties menu/area 15. These graphs have been selected from a plurality of graphic (object) templates (see FIG. 5 and the below description thereof) and populated with data and/or subsets of data from various data sources 90 [e.g. source group comprising a plurality of data sets] as specified by the user [Thus, based on input from the user] via the Data Sources tab 21 (see, e.g., FIG. 2) and Data Sets tab 32 (see. e.g., FIG. 3) [e.g. plurality of data sets]…. Series mapping provides mapping columns from the data set to the various regions of the graphic.” See also Kovacs Fig. 2, [0036] “In screen capture 20 the Data Source tab 21 has been selected from the report generation tabs 14 and various selections are provided… The Data Source screen provides a data source list area 22 where a user may create, select and/or delete a data source and where the selection of a data source [e.g. source group] is shown [Thus, selecting, based on input from the user, a source group]”
PNG
media_image1.png
891
1382
media_image1.png
Greyscale
See also Kovacs Fig. 3, [0037] “FIG. 3 is a screen capture 30 of the present system 83 illustrating the data workflow engine of the present system that allows one to cut, combine, and manipulate data as needed or desired, such as specifying for each report recipient criteria for selecting a subset of data from the data set [(e.g. iterator type) Thus, corresponding to a type of data present in the source group] to be graphically presented in a report… A data set modifier stack area 36 is provided for modification of the selected data set 35”
PNG
media_image2.png
890
1376
media_image2.png
Greyscale
[Thus, the source group comprises a plurality of data sets])
However, Stadnisky also teaches selecting, based on input from the user, a source group and an iterator type, wherein the source group comprises a plurality of data sets, and the iterator type corresponds to a type of data present in the source group in more details. (See Stadnisky [0011-0013] “disclosed herein are modular experiment templates that can be divided into individual components for future use in multiple experiments… The modular experiment templates provide easily reusable template components… may also generate batch reports or reports for various populations.” See also Stadnisky [0062-0063] “a user through the interface 110 [Thus, based on input from a user] may review or create new template [e.g. report template] components that define an automated analysis of the acquired data to be run on the server 106 after acquisition… the interface 110 links the acquisition software 108 to the analysis server 106, a data set may be sent to an analysis pipeline on the server so that reports and workspaces are generated immediately upon data transfer” See also Stadnisky [0048] “a user configures [i.e. input from the user] the interface 110 to search a specified file directory for FCS files [e.g. source group] to be analyzed [Thus, selecting, based on input from the user, a source group], which may be called a “watch folder” (see, for example, FIG. 13A discussed below).” See also Stadnisky [0081-0084, 0089] “Modular experiment templates break a full experiment template down into individual steps or operations via modular experiment template components… These individual steps may include… applying gating trees [e.g. iterator type]… The server 106 may first apply a first modular template component that corresponds to a gating tree that finds peripheral blood mononuclear cell (PBMC) populations within the data. [Thus, the iterator type corresponds to a type of data present in the source group]… once a researcher creates a gating tree or a sample organization template component, that template component may be used in any other data set by any other researcher in any other experiment” See also Stadnisky [0092, 0100-0101] “The template components may perform… repeated analysis steps… the modular template components are individual components which may be used together to generate results of an experiment… For example, a first template component may apply gating to gather all the PBMCs, a second template component may find all samples having a low amount of PBMCs (e.g. less than 55%), and a third template component may generate a batch report of the samples having a low amount of PBMCs” [Thus, selecting, based on input from the user, a source group and an iterator type, wherein the source group comprises a plurality of data sets, and the iterator type corresponds to a type of data present in the source group])
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Kovacs; which uses report template for a user to specify data sources including data files and specific columns (i.e. type of data) to be included in the report to incorporate, the teachings of Stadnisky of using reusable modular templates that define an automated analysis and report of the acquired data, including files to be analyzed and populations within the data.
One would be motivated to do so to efficiently minimize the time to create an entire experiment template (Stadnisky 0081).
Kovacs further in view of Stadnisky, [hereinafter Kovacs-Stadnisky] additionally disclose automatically determining an aspect of the report template capable of being populated with data from the source group; (See Kovacs [0016] “all of the tailored definitions/business rules that are defined for each recipient's preferences, are defined and saved in an automation driver data set. This dataset is used in the automation process [Thus, automatically] for generating the user defined uniqueness of the report over the plurality of report recipients. Automation provides the ability to easily manipulate virtually any property value within the report setup based on conditions of a particular report recipient.” See also Kovacs [0038-0039] “Typically, the automation driver has... specifications that would determine the uniqueness of the final deliverables (e.g. graphical report(s)) at a recipient level (i.e. chart types, colors, dataset filters, and the like). As shown in the screen capture 40 of the present system 83 the ability to easily define custom data driven automation that iterates over a set of data [e.g. data from the source group] to provide individual reports across an unlimited number of breaks is illustrated… The automated properties area 42 shows the properties throughout the report setup that have been selected to be controlled by automation. The columns 44 represent each of the properties throughout the report setup that have been selected to be controlled by automation [Thus, automatically, without user interaction]. The rows 46 correspond to each row in the automation driver table. However, the values [e.g. aspects of the report template capable of being populated with data from the source group] of the displayed are the evaluation of the property value expression 48 based on the values in the automation driver table for each corresponding row. [Thus, by evaluating the property value expression for columns, the automation is automatically determining a value for each corresponding row. Thus, it is automatically determining, without user interaction, an aspect of the report template capable of being populated with data from the source group]”)
automatically determining an aspect of the report template associated with the iterator type; automatically identifying data from each data set of the source group corresponding to the iterator type; (See Kovacs [0037-0039] "The system 83 allows the creation of as many data sets and sub-data sets as desired where a sub-data set derives its source data from its parent data source and can contain specific manipulations to the data for the sub-data set... FIG. 4 is a screen capture 40 of the present system 83 illustrating the ability of a user to specify for each report, a data subset [e.g. iterator type] through automation filtering via the automation driver such as assigning an ID based on the current report recipient's country… The columns 44 represent each of the properties throughout the report setup that have been selected to be controlled by automation [Thus, automatically, without user interaction]… For example, column 44 is the automated property entry for filter expression 49. In this case, the automated property value expression 48 is set to ‘[Country_ID]=<$Country_ID>’. This means that for each row 46, the expression will be evaluated [Thus, automatically determining/identifying] by replacing <$Country_ID> with the value [e.g. an aspect of the report template associated with the iterator type] of the ‘Country_ID’ column [e.g. iterator type] in the automation driver for each corresponding row. [Thus, by evaluating each automated property value expression for columns, the automation is automatically determining/identifying a value for each corresponding row. Thus, it is automatically determining, without user interaction, an aspect of the report template associated with the iterator type] This is shown in the table 46 as each row has a different ‘Country_ID’ value. [Thus, automatically identifying data from each data set of the source group corresponding to the iterator type]")
iteratively populating, by traversing the source group according to the iterator type, a plurality of batch reports with a separate data set of the plurality of data sets of the source group based on the determined aspects of the report template and the data sets of the source group, in each case corresponding to the iterator type. (See Kovacs abstract “A system and method is provided for batch generation of graphic reports [i.e. populating a plurality of batch reports] from one or more data sets [Thus, using the plurality of data sets of the source group] for multiple recipients… the ability to specify different graphical presentations of identical data types for different report recipients, and the ability to generate for each report recipient from a library of graphic templates [Thus, based on the determined aspects of the report template], a report [Thus, based on the generated report template] that graphically displays the same type of data differently for different report recipients… The system and method also provides for a user to specify the data set(s) and to automatically and periodically [e.g. iteratively] send a generated report to each report recipient.” See also Kovacs Fig. 4, [0037-0039] "the present system that allows one to cut, combine, and manipulate data as needed or desired, such as specifying for each report recipient criteria for selecting a subset of data [Thus, with a separate data set of the plurality of data sets of the source group] from the data set [e.g. based on the selected iterator type] to be graphically presented in a report [Thus, based on the determined aspects of the report template and the data sets of the source group, in each case corresponding to the iterator type]… The system 83 allows the creation of as many data sets and sub-data sets as desired where a sub-data set derives its source data from its parent data source and can contain specific manipulations to the data for the sub-data set [Thus, with a separate data set of the plurality of data sets of the source group]… the automation driver has an email column that might be a list of people to receive (send to) the graphical report or any specifications that would determine the uniqueness of the final deliverables (e.g. graphical report(s)) at a recipient level (i.e. chart types, colors, dataset filters [i.e. aspects], and the like [Thus, based on the determined aspects of the report template and the data sets of the source group, in each case corresponding to the iterator type])… system 83 the ability to easily define custom data driven automation that iterates over a set of data [Thus, the automation iterates over the source group] to provide individual reports across an unlimited number of breaks [e.g. traversal steps] for each row in the automation drive… For example, column 44 is the automated property entry for filter expression 49 [e.g. an aspect of the report template associated with the iterator type]. "
PNG
media_image3.png
883
1398
media_image3.png
Greyscale
Thus, the property value expression [Country_ID]=<$Country_ID> is evaluated with that row’s Country_ID value, which selects the corresponding subset of source group data for that iteration and produces a separate batch report. The iteration is keyed to the iterator type column (Country_ID), and so the source group is being traversed “according to the iterator type”.)
Stadnisky also teaches iteratively populating, by traversing the source group according to the iterator type, a plurality of batch reports. (See Stadnisky [0081-0084, 0089, 0092, 0100-0101] disclosing the modular template components iterating through (traversing) the FCS files of the source group according to the gating-tree iterator type (“the second template component receives the PBMC population numbers… generated by the first modular template component to determine which samples have PBMC populations below a given threshold… a third template component may generate a batch report of the samples”). Each pass of the gating tree over a sample is a traversal step of the source group keyed to the iterator type, and produces a corresponding batch report. Thus, batch reports are iteratively populated by traversing the source group according to the iterator type.)
Regarding claim 2, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the report template comprises a data visualization structure. (See Kovacs Fig.1, [0035] “A page 12 of the report template as shown in area 17 can have its properties selected, de-selected, or modified as desired with the shown properties menu/area 15… The plurality of pages 17 of the report may graphically present information regarding a plurality of subsets of data including the ability to specify different graphical presentation of identical data types for different report recipients. [Thus, the report template comprises a data visualization structure]”
PNG
media_image4.png
915
1371
media_image4.png
Greyscale
Regarding claim 5, Kovacs-Stadnisky teaches all limitations and motivations of claim 2, wherein generating, based on input from a user, a report template comprises receiving from the user a configuration of the data visualization structure. (See Kovacs [0035] “A page 12 of the report template as shown in area 17 can have its properties selected, de-selected, or modified as desired with the shown properties menu/area 15. [Thus, receiving from the user a configuration of the data visualization structure]”)
Regarding claim 7, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the report template is configured to present flow cytometric data. (See Stadnisky [0013] “modular templates… may also generate batch reports or reports for various populations.” See also Stadnisky [0035-0039] “a data acquisition instrument 102 is connected to an acquisition computer 104. In the example embodiment shown in FIG. 1, the acquisition instrument 102 is a flow cytometer… The acquisition computer 104 is connected to a server 106… The acquisition computer 104 executes acquisition software 108… The results of data acquisition and sample analysis [i.e. flow cytometric data] may be contained within one or more flow cytometry standard format files (e.g., a FCS file)… the server 106 may be a remote server 106 dedicated to flow cytometry analysis.” See also Stadnisky [0062-0063] “a user through the interface 110 may review or create new template [e.g. report template] components that define an automated analysis of the acquired data [i.e. flow cytometric data] to be run on the server 106 after acquisition… the interface 110 links the acquisition software 108 to the analysis server 106, a data set may be sent to an analysis pipeline on the server so that reports and workspaces are generated immediately upon data transfer [Thus, report template is configured to present flow cytometric data]”)
Regarding claim 8, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein each data set of the source group comprises flow cytometric data. (See Stadnisky [0038-0039] “The results of data acquisition and sample analysis [i.e. flow cytometric data] may be contained within one or more flow cytometry standard format files (e.g., a FCS file) [e.g. data sets comprising flow cytometric data] … the server 106 may be a remote server 106 dedicated to flow cytometry analysis.” See also Stadnisky [0048] “a user configures the interface 110 to search a specified file directory for FCS files, which may be called a “watch folder” [Thus, each data set of the source group comprises flow cytometric data]”)
Regarding claim 17, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, further comprising receiving a data set of the source group. (See Stadnisky [0062-0063] “a user through the interface 110 may review or create new template components that define an automated analysis of the acquired data to be run on the server 106 after acquisition. In other words, a user may cause an analysis of the acquired data to be commenced instantly after that data is acquired from the instrument 102 and transferred to the server 106… a data set may be sent to an analysis pipeline [Thus, receiving a data set of the source group] on the server so that reports and workspaces are generated immediately upon data transfer”)
Regarding claim 19, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type determines a number of batch reports to be generated. (See Kovacs [0039] “the ability to easily define custom data driven automation that iterates over a set of data to provide individual reports across an unlimited number is breaks… The rows 46 correspond to each row in the automation driver table” Thus, the number of breaks/rows in the automation driver, which is keyed to the iterator type column (e.g. Country_ID), determines how many batch reports are generated (e.g. one per break/row). Thus, the iterator type determines a number of batch reports to be generated.)
Stadnisky also teaches wherein the iterator type determines a number of batch reports to be generated. (See also Stadnisky [0103] “perhaps seven samples were provided to the processor and two samples had low PBMC counts [Thus, determined by the iterator type (e.g. gating-tree thresholding) applied to the source group]. Thus, the processor would only need to generate reports about two of the seven samples. [Thus, the iterator type determines a number of batch reports to be generated]”)
Regarding claim 20, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type defines which portion of the report template varies among each batch report. (See Kovacs [0039] “The automated properties area 42 shows the properties throughout the report setup that have been selected to be controlled by automation. The columns 44 represent each of the properties throughout the report setup that have been selected to be controlled by automation [Thus, defining which portion of the report template varies]. The rows 46 correspond to each row in the automation driver table.” [The columns 44 (controlled by the iterator type) define exactly which portions of the report template vary from the batch report to the next.] See also Kovacs [0035] describing the ability to “specify different graphical presentation of identical data types for different report recipients”)
Regarding claim 21, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type specifies which data of the source group is iteratively populated in the batch reports. (See Kovacs abstract “A system and method is provided for batch generation of graphic reports from one or more data sets for multiple recipients” See also Kovacs Fig. 3, [0037] “screen capture 30 of the present system 83 illustrating the data workflow engine of the present system that allows one to cut, combine, and manipulate data as needed or desired, such as specifying for each report recipient criteria for selecting a subset of data [i.e. type of data] from the data set [e.g. iterator type] to be graphically presented in a report [Thus, iterator type specifies which data of the source group is iteratively populated in the batch reports]… A data set modifier stack area 36 is provided for modification of the selected data set 35”)
Regarding claim 22, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type defines a unit of iteration for iteratively populating the plurality of batch reports. (See Kovacs [0039] describing the automation that “iterates over a set of data to provide individual reports across an unlimited number of breaks”. Thus, each row 46 in the automation driver, which corresponds to one value of the iterator type column (e.g. one Country_ID) defines a unit of iteration. The iterator type column this defines what one “unit” of iteration is (one row = one break = one batch report).
See also Stadnisky [0089, 0100-0101] each application of the gating tree to a sample is one unit of iteration that produces one batch report, the gating-tree iterator type defines the unit of iteration as the application oof the gating tree to a single sample.)
Regarding claim 23, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein each batch report corresponds to each traversal of the source group by iterator type. (See Kovacs [0037, 0039] describing the “ability to easily define custom data driven automation that iterates over a set of data to provide individual reports across an unlimited number is breaks”. Thus, each break corresponds to a single traversal of the source group keyed to one value of the iterator type columns, and each break produces one corresponding individual report.
See also Stadnisky [0100-0101] each pass of the gating tree over a sample is a single traversal of the source group, and a corresponding batch report is generated for each qualifying traversal.)
Regarding claim 24, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type determines whether batch reports are iteratively populated by statistic. (See Kovacs Fig. 3, [0037] “screen capture 30 of the present system 83 illustrating the data workflow engine of the present system that allows one to cut, combine, and manipulate data as needed or desired, such as specifying for each report recipient criteria for selecting a subset of data from the data set [e.g. iterator type] to be graphically presented in a report [Thus, iteratively populated]… A data set modifier stack area 36 is provided for modification of the selected data set 35 [(e.g. Aggregate by Current Country) Thus, the iterator type determines the batch reports are iteratively populated by statistics]”
PNG
media_image2.png
890
1376
media_image2.png
Greyscale
Regarding claim 29, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein the iterator type is independent of a report recipient and a graphical presentation of each batch reports. (See Stadnisky [0048, 0081-0089] describing that “a user configures the interface 110 to search a specified file directory for FCS files” and selects modular template components (gating trees) [iterator type] independently of any specific report recipient, where “once a researcher creates a gating tree or a sample organization template component, that template component may be used in any other data set by any other researcher in any other experiment.” [Thus, the iterator type selection is independent of a particular report recipient]. See also Stadnisky [0099] “regarding reporting, any tabular or graphical reports may be created and used as part of a template component” [Thus, indicating that the gating tree iterator type selection is independent of the graphical presentation choice (the iterator type is selected at the analysis stage, while graphical presentation is configured separately at the reporting stage).
See also Kovacs [0037-0039] describing that the iterator type column (e.g. Country_ID) is selected as part of the data workflow/automation driver definition independently from whom the report is sent to the recipient list is a separate column in the automation driver: “the automation driver has an email column that might be a list of people to receive (send to) the graphical report”, and independently from the graphical presentation of each batch report which is governed by the report-template graphical pages 12 and separate report generation tabs 14.
Thus, Kovacs-Stadnisky teaches that the selection of the iterator type is independent of a report recipient and a graphical presentation of each batch reports.
Regarding claim 30, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, further comprising selecting a number of reports to include on a presentation page. (See Kovacs [0039] “As shown in the screen capture 40 of the present system 83 the ability to easily define custom data driven automation that iterates over a set of data to provide individual reports across an unlimited number of breaks is illustrated” See also Kovacs [0041-0043] “FIG. 6 is a screen capture 60 of the present system 83 illustrating the selection of multiple output deliverable types including, but not limited to, PowerPoint, PDF, Excel, and images with the ability to send individual emails to each automated report recipient within the Report Book tab/area 13. A published specifications area 62 shows the automation recipient and lookup data source (automation driver) for the graphical report. The system 83 provides for each recipient, generation of a report where the graphical template and data workflow is adjusted via automation for each report recipient [Thus, by selecting report recipients it is selecting a number of reports to include on a presentation page]… To include a report recipient, the report recipients are selected in the automation driver table.”
PNG
media_image5.png
896
1431
media_image5.png
Greyscale
Regarding claim 31, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, further comprising generating, based on input from a user, static content. (See Kovacs [0033-0034] “The present system and method allows the user to customize all aspects of the nature of the report [Thus, based on input from a user] for an individual recipient of multiple recipients… FIG. 1 is a screen capture 10 of the present system illustrating the ability to create [Thus, generating] a report/report template for graphically representing information regarding data and subsets of data and, particularly to import a file, such as a PowerPoint file, as a background graphical theme [e.g. static content], and add data driven charts and other graphics to it via report pages 12.” See also Kovacs claim 4 “the graphic parameters include text, chart type, visibility, titles [e.g. static content], color, font, and size;” [Thus, generating, based on input from a user, static content])
Regarding claim 33, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, further comprising designating, based on input from a user, that aspects of a presentation page comprise a report template. (See Kovacs [0033-0035] ““The present system and method allows the user to customize all aspects of the nature of the report [Thus, based on input from a user] for an individual recipient of multiple recipients… FIG. 1 is a screen capture 10 of the present system illustrating the ability to create [Thus, designating] a report/report template for graphically representing information regarding data and subsets of data and, particularly to import a file, such as a PowerPoint file, as a background graphical theme, and add data driven charts and other graphics to it via report pages 12 [e.g. presentation page]… A page 12 of the report template as shown in area 17 can have its properties selected, de-selected, or modified as desired with the shown properties menu/area 15. [Thus, designating, based on input from a user, that aspects of a presentation page comprise a report template]”)
Regarding claim 34, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, further comprising designating, based on input from a user, that aspects of a presentation page comprise static content. (See Kovacs [0033-0034] “The present system and method allows the user to customize all aspects of the nature of the report [Thus, based on input from a user] for an individual recipient of multiple recipients… FIG. 1 is a screen capture 10 of the present system illustrating the ability to create [Thus, designating] a report/report template for graphically representing information regarding data and subsets of data and, particularly to import a file, such as a PowerPoint file, as a background graphical theme [e.g. static content], and add data driven charts and other graphics to it via report pages 12 [e.g. a presentation page].” See also Kovacs claim 4 “the graphic parameters include text, chart type, visibility, titles [e.g. static content], color, font, and size;” [Thus, designating, based on input from a user, that aspects of a presentation page comprise static content])
Regarding claim 104, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein automatically determining an aspect of the report template capable of being populated with data from the source group comprises identifying, without employing a uniquely tagged field, an aspect of the report template capable of being populated with data from the source group. (See Kovacs [0038-0039] describes that the automation driver determined the aspect of the report template (i.e. the values displayed) by evaluating the property value expression 48 against the values in the automation driver table for each corresponding row 46. This evaluation dies not rely on any “uniquely tagged field”, rather it relies on column-name expressions evaluated against the automation driver table. In the example expression [Country_ID]=<$Country_ID>, the bracketed [Country_ID] is a column name reference to a non-unique value column (where multiple rows may have the same country code in different reports) and <$Country_ID> is a placeholder substituted with the row’s value (this is a generic column lookup, not a uniquely tagged field. See also Kovacs [0016] describing automated definitions defined and saved in an automation driver data set used to generate reports without per-recipient user interaction. Thus, the aspect of the report template capable of being populated with data is identified without employing a uniquely tagged field.)
Regarding claim 105, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein automatically determining an aspect of the report template associated with the iterator type comprises identifying, without employing a uniquely tagged field, an aspect of the report template associated with the iterator type. (See Kovacs [0037-0039] describes that the iterator-type associated aspect (e.g. the filter expression value for each row) is identified by evaluating expressions against the automation driver columns, which is a generic column-lookup operation not by use of any uniquely tagged field. Each row 46 shares the same column structure, uniqueness is by row position rather than by tagged field.)
Regarding claim 106, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein data of each data set of the source group comprises constituent data elements, and the constituent data elements are stored in a hierarchical data structure based on the iterator type. (See Kovacs [0032] “Both storages 84, 86 can receive and store graphical reports… library of graphic templates, report setups, customized graphical representations of data for report recipients, references to multiple data files where data to be included in the data set, report templates,… data, data subsets [e.g. constituent data elements], and/or the like.” See also Kovacs Fig. 3, [0037] “FIG. 3 is a screen capture 30 of the present system 83 illustrating the data workflow engine of the present system… the Data Sets tab/area 32 has been selected and various selections are provided… A hierarchal data set selection area 34 is shown in which a data set may be selected or created to be viewed and modified [Thus, constituent data elements are stored in a hierarchical data structure based on the iterator type, the iterator type/data set determines the structure if the hierarchy of sub-data sets]… The system 83 allows the creation of as many data sets and sub-data sets as desired where a sub-data set derives its source data from its parent data source [Thus, a hierarchical structure of constituent data elements]”)
PNG
media_image2.png
890
1376
media_image2.png
Greyscale
Regarding claim 107, Kovacs-Stadnisky teaches all limitations and motivations of claim 106, wherein automatically identifying data from each data set of the source group corresponding to the iterator type comprises iteratively accessing corresponding aspects of the hierarchical data structure. (See Kovacs Fig. 4, [0037-0039] describe that for each row 46, the expression [Country_ID]=<$Country_ID> is evaluated, thus, iteratively, one row at a time by replacing <$Country_ID> with the corresponding Country_ID value. Each evaluation accesses an aspect of the hierarchical data structure (the parent dataset / sub-data set hierarchy) corresponding to that row. Thus, automatically identifying data from each data set comprises iteratively accessing corresponding aspects of the hierarchical data structure.)
PNG
media_image3.png
883
1398
media_image3.png
Greyscale
Regarding claim 108, Kovacs-Stadnisky teaches all limitations and motivations of claim 106, wherein the hierarchical data structure comprises a plurality of file system nodes within a file system structure. (See Stadnisky [0048] "a user configures the interface 110 to search a specified file directory for FCS files to be analyzed, which may be called a “watch folder” (see, for example, FIG. 13A discussed below).. then automatically monitor the watch folder for new data files (such as FCS files) [Thus, a plurality of file system nodes (FCS files) within a file system structure (the watch folder directory)]." See also Stadnisky [0093] "Regarding hierarchical analysis, a binding node preserves the hierarchical analysis of data... Thus, searching a directory for files is searching a file system structure... FIG. 6 illustrates how one gating tree binds to the “TCRb+CD3e+” in the workspace GUI and applies the gates and statistics at that level of the hierarchy [Thus, stored in a hierarchical data structure], to a group of samples." Therefore, the hierarchical data structure if Stadnisky comprises a plurality of file system nodes (FCS files in a watch folder) within a file system structure.)
Regarding claim 109, Kovacs-Stadnisky further in view of Racine teaches all limitations and motivations of claim 1, wherein iteratively populating a plurality of batch reports comprises repeatedly instantiating the report template corresponding to each traversal of the source group according to the iterator type. (See Kovacs [0039] See Kovacs [0041] describing the automation that “iterates over a set of data to provide individual reports across an unlimited number of breaks”. The system 83, “for each recipient, generation of a report where the graphical template… is adjusted via automation for each report recipient” [Thus, the report template is repeatedly instantiated for each break (each row 46) corresponding to each traversal of the source group according to the iterator type column (e.g. Country_ID), where each iteration produces a new instance of the report template populated with the data for that traversal step.
See also Stadnisky [0100-0101] “a first template component may apply gating to gather all the PBMCs, a second template component may find all samples having a low amount of PBMCs (e.g. less than 55%), and a third template component may generate a batch report of the samples having a low amount of PBMCs.” Thus, each batch report is a separate instantiation of the report template corresponding to each traversal of the source group according to the gating-tree iterator type.)
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Kovacs-Stadnisky in view of Racine (US Patent Application Publication No. US 20150131887 A1).
Regarding claim 3, Kovacs-Stadnisky teaches all limitations and motivations of claim 2, wherein the data visualization structure comprises: a chart, a legend or text. (See Kovacs [0034] “FIG. 1 is a screen capture 10 of the present system illustrating the ability to create a report/report template for graphically representing information regarding data and subsets of data and, particularly to import a file, such as a PowerPoint file, as a background graphical theme, and add data driven charts and other graphics to it via report pages 12.” See also Kovacs [0041] “FIG. 6 is a screen capture 60 of the present system 83 illustrating the selection of multiple output deliverable types including… images” See also Kovacs Fig. 1, disclosing a visualization structure (e.g. page 12) including a chart with a legend and text.”)
PNG
media_image6.png
805
1226
media_image6.png
Greyscale
Stadnisky also teaches a data visualization structure comprising an a chart or a table. (See Stadnisky [0099] “regarding reporting, any tabular [e.g. table] or graphical reports [e.g. image, may be created and used as part of a template component… plugin architecture allows a template component to establish a link to a LIMS, repository, or database to use any of the data and elements as input… This also allows for the extension of visualization tools and importing those artifacts into a workspace, the possibility to integrate with open and save functionalities for communicating with other services' API's (e.g. LIMS, database, etc.), and exporting of populations, statistic tables, or chart objects for any other type of 3rd-party application.” See also Stadnisky [0064] “the analysis server 106 is able to generate outputs, such as… plots”)
However, Racine teaches a data visualization structure comprising an image in more details. (See Racine Fig. 2, [0031-0032] “a method for generating representations and analyses of cytometric information performed by the system according to the invention. The invention also proposes a user interface for use with the system of the invention, for visualizing and analyzing data from cellular image processing, comprising a graphical interface operative to designate image and statistics files source and destination, display parameters, scatter plots [i.e. plot], heat-maps, dose responses, biological conditions input, gates in scatter-plots and histograms.”
PNG
media_image7.png
803
1051
media_image7.png
Greyscale
[Thus, having a data visualization structure comprising a plot, a chart, a legend or text.]”
See also Racine Fig. 14, [0125] “ With reference to FIG. 14, a cell montage window is shown. It represents a list of many cells contained in a given well (D04 in the current example) and in the gate “Gate 3”. For each channel image, the user can choose what the color to represent it is. The montage is composed of numbers of cells cropped from the initial images and reassemble to form a montage.”
PNG
media_image8.png
888
719
media_image8.png
Greyscale
Thus, a visualization structure comprising an image.)
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Kovacs-Stadnisky; which provide a user interface for graphically represent data using charts and graphics, to incorporate the teachings of Racine of using a user interface for generating graphical representations and analyses of data including visualizing images.
One would be motivated to do so to effectively convey results / information. Thus, improving user comprehension.
Regarding claim 4, Kovacs-Stadnisky further in view of Racine teaches all limitations and motivations of claim 3, wherein the image is an image of a cell. (See Racine Fig. 14
PNG
media_image8.png
888
719
media_image8.png
Greyscale
[Thus, the image is an image of a cell])
Claims 18 is rejected under 35 U.S.C. 103 as being unpatentable over Kovacs-Stadnisky in view of Bhatia (US Patent Application Publication No. US 20110035744 A1).
Regarding claim 18, Kovacs-Stadnisky teaches all limitations and motivations of claim 1, wherein selecting the source group comprises selecting a source group from a drop-down menu. (Kovacs Fig. 2, [0036] teaches a user interface to easily pull (obtain) data from multiple data sources including selecting a data source [e.g. source group] from a source list.)
Kovacs-Stadnisky does not explicitly disclose selecting a source group from a drop down menu.
However, Bhatia teaches selecting a source group from a drop-down menu. (See Bhatia abstract “The present disclosure enables users to interactively create, customize, and execute reports on data stored in databases” See also Bhatia [0048-0052] “Referring to FIG. 2, a UI screen 200 is depicted illustrating a data source tab 202… The user activates the data source selector visual component by clicking on a table menu 208 which can include a drop down list of various data sources 210 [e.g. source groups]… The user can select a relevant data source such as categories 212.” [Thus, selecting a source group from a drop-down menu])
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to modify Kovacs-Stadnisky to incorporate the teachings of Bhatia of using a drop-down menu for selecting data sources.
One would be motivated to do so to help conserve screen space as options are displayed when needed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OSCAR WEHOVZ whose telephone number is (571)272-3362. The examiner can normally be reached 8:00am - 5:00pm ET.
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, APU M MOFIZ can be reached at (571) 272-4080. 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.
/OSCAR WEHOVZ/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights