DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The office action is being examined in response to the application filed by the Applicant on October 2, 2025.
Claims 1-20 are pending and have been examined.
This action is made NON-FINAL.
The Examiner would like to note that this application is now being handled by examiner Ivonnemary Rivera González.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 16, 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 - 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claim 17, the most representative claim of the independent claims set 1, 17 and 20, as follows:
At Step 1: Claims 1 - 16 falls under statutory category of process, while claims 17 - 19 are directed to a machine and claim 20 is an article of manufacture.
At Step 2A Prong 1: Claim 17 (representative of claims 1 and 20) recites an abstract idea in the following limitations:
… interface one or more data sources comprising crime-related data with a framework configured for crime data analysis;
define an ontology including classes, properties, and relationships representing the crime-related data;
pre-process the crime-related data to generate a dataset, the pre-processing comprising at least one of removing analytically irrelevant columns, removing rows including fields with null values, and converting date and time fields to numerical values;
import the dataset into…accessible to the framework;
generate RDF triples…to represent relationships between elements of the dataset;
expose the RDF datastore…
receive a query…
return a response to the query…and
output, for display, a data visualization…based on the response.
Generally, and as disclosed in the specification in ¶0023, this claimed invention provides “systems, methods, and apparatuses for structuring and analyzing crime-related data using a semantic data framework” that further “enable the transformation of raw crime data into a semantically rich and queryable format.” The steps of “define an ontology…”, “pre-process the crime-related data to generate a dataset…” and “generate RDF triples…to represent relationships between elements of the dataset” fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because defining classes, properties, and relationships representing the crime-related data, pre-process the data by “removing analytically irrelevant columns, removing rows” and “converting date and time fields to numerical values” to generate the relationships between the dataset elements via the “RDF triples” encompass observation, evaluation and judgement. Also, these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps do not negate and further still reads in the mental nature of the limitation(s), when organizing/normalizing such information, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of visualizing/analyzing the crime-related data to resolve crimes or legal prosecution (see MPEP 2106.04(a)(2)(III)(B & C)).
As for step of “pre-process the crime-related data to generate a dataset, the pre-processing comprising at least one of…converting date and time fields to numerical values”, these steps encompass mathematical processes that can be performed mentally or in pen and paper and requires specific mathematical calculations (i.e. through the use of normalization algorithms/scripts; see dependent claim 5 and at least ¶0054 – 55 from Applicant disclosure also) for the system to able to ingest the data in a readable/compatible format.
At Step 2A Prong 2: For independent claims 1, 17 and 20, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of processing circuitry; non-transitory computer readable media (from claims 17 and 20); Resource Description Framework (RDF) datastore and a dashboard user interface module (from claims 1, 17 and 20) and A non-transitory computer-readable storage medium (from claim 20). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Specifically, these steps are recited as being performed by the computer (i.e. “processing circuitry” including “processor(s)” of the “computing device”; see ¶0034, ¶0116 and Fig.1). The computer is recited at a high level of generality that is being used as a tool to perform the generic computer functions for structuring and analyzing crime-related data. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
As for the step of “pre-processing the crime-related data to generate a dataset, the pre-processing comprising at least one of…converting date and time fields to numerical values”, this step is also broadly recited is performed generally to apply the abstract idea without placing any limits on how the “converting” of the text data is performed distinctively from generic computer components and without the function being generally be invoked as an “apply it” to a computer.
Finally, the steps of “interface one or more data sources…”, “import the dataset…”, “expose the RDF datastore…”, “receive a query…”, “return a response to the query…” and “output, for display, a data visualization …” in the representative claim is really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)). Thus, in these limitation steps, the computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer.
Step 2B: For independent claims 1, 17 and 20, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: processing circuitry; non-transitory computer readable media (from claims 17 and 20); Resource Description Framework (RDF) datastore and a dashboard user interface module (from claims 1, 17 and 20) and A non-transitory computer-readable storage medium (from claim 20). These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2-16 and 18 - 19, the same analysis is incorporated. Due to their dependency to the independent claims analyzed, these claims cover or fall under the same abstract idea(s) of a method of mental and mathematical processes. They describe additional limitations steps of:
Claims 2-16 and 18 - 19: further describes the abstract idea of the computer-implemented method and merely recites further embellishments of the abstract idea and do not claim anything that amounts to significantly more than the abstract idea itself. Thus, being directed to the abstract idea group of “commercial or legal interactions” as it handling agreements in the form of contracts and/or legal obligations for the purpose of visualizing/analyzing the crime-related data to resolve crimes or legal prosecution. Finally certain limitations require observation, evaluation and judgement as well as encompasses mathematical calculations (i.e. through the use of normalization algorithms/scripts; see dependent claim 5).
Step 2A Prong 2 and Step 2B: For dependent claims 5 – 6, 8 and 10, these claims recite the additional elements of: converting categorical values of the crime-related data into numerical representations (claim 5); transforming the dataset from a tabular format into a linked data format (claim 6); a triple store server (claim 8); and executing a join operation across multiple RDF datasets (claim 10). These additional elements recited are invoking computers merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of normalizing, structuring and store the crime-related data. Thus, amounting to no more than mere instructions to “apply” the exception using a generic computer component (MPEP 2106.05(f) and (f)(2)). Accordingly, for the same reasons stated above, these additional element(s) claimed cannot provide an inventive concept at Step 2B.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
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- 3 and 5 - 6 and 8 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Guo (U.S. Pub No. 20210117445 A1) in view of Ianakiev (U.S. Pub No. 20160021181 A1).
Regarding claims 1, 17 and 20:
This independent claim set is represented by claim 17.
Guo teaches:
processing circuitry; non-transitory computer readable media; and instructions that, when executed by the processing circuitry, configure the processing circuitry to: (In ¶0012; Fig. 1 (102 and 104): teaches “a representative processing device 100” that may “comprise a workstation computer or server computer” and “a processor 102 coupled to a storage component 104” that further comprises “stored executable instructions 116 and data 118.”)
interface one or more data sources comprising crime-related data with a framework configured for crime data analysis; (In ¶0022; Fig. 1 (104 and 118); Fig. 3 (304 – 308): teaches “the system 300, a controller 302 communicates with a plurality of databases 304-308 that include, in the illustrated example, a relational database 304, a columnar database 306 and a triplestore database 308” wherein the data is treated as objects that are in a “triple” data representation concept in which statements can be made about, in the context of the instant disclosure, relationships between objects. For example, the so-called Resource Data Framework (RDF) specifications establishes subject-predicate-object expressions (triples) in order to make statement concerning “resources” (e.g., web resources)” (see ¶0025).)
define an ontology including classes, properties, and relationships representing the crime-related data; (In ¶0026: teaches that “conventions like RDF also provide statements that convey ontology information, i.e., information describing the structural framework used to organize information thereby providing a knowledge representation, which ontology information may be used to assist in the conversion of data from one storage format to another.” Refer to ¶0067 and ¶0071 for details when there’s “no ontology information to tell its class (which is quite common), then the conversion process may identify any available properties and compare those properties with an existing class/table and try to match them if possible” via “the conversion bridge 412” that “searches through all available tables that a current user has access to and, for each table, counts the number of columns and compares that column count value with the unclassified resource's number of properties, i.e., a property count value.” See ¶0112 wherein the system “uses both the ontology information and natural language syntax. A word's ontology information can be directly mapped to question words.”)
pre-process the crime-related data to generate a dataset, the pre-processing comprising at least one of removing analytically irrelevant columns, removing rows including fields with null values, (In ¶0041 – 42: teaches that “all data is initially stored in the triplestore database 308 and the controller 302 determines when conversion from the triplestore format to another format is required, or vice versa”. Further, “format conversions will be required both into the triplestore database storage format from another database storage format and from the triplestore database storage format into another database storage format” wherein “conversions into the triplestore database storage format are based on identifying the most primitive or fundamental data structure in the source database storage format and mapping those data structures to triples. For example, when converting from a key-value storage format to the triplestore storage format, a conversion process (such as an RDF reasoned, as described in a further example below) can iterate through each key-value and make a corresponding triple.When converting from a wide column storage format to the triplestore storage format, the conversion process may iterate through each keyspace, column family, column and row forming triples along the way.” Refer to ¶0087 – 88 and ¶0090 wherein “the automated data mining component 332 operates to best pre-process data for a given data mining task, and to select the best data mining algorithms for the data mining task”)
and converting date and time fields to numerical values; (In ¶0088: teaches that “The automated data mining component 332 can engage in training in order to automatically select the best data pre-processing. To this end, a sample dataset is first gathered and the statistical characteristics thereof are extracted. Such statistical characteristics may include, for example, mathematical features such as mean, mode, median, range and standard deviation, etc. They may also include simple facts such as the number of attributes, the type of each attributes (e.g., nominal versus numerical), dataset size, etc.” Refer to ¶0113 – 115 wherein generated queries and corresponding answering results can include date/time fields.)
import the dataset into a Resource Description Framework (RDF) datastore accessible to the framework; (In ¶0068; Fig. 4 (406 and 408): teaches that the “RDF data from an external RDF datastore 406 may be imported into the RDF DBMS 404 via an RDF loader 408, as known in the art.”)
generate RDF triples within the RDF datastore to represent relationships between elements of the dataset; (In ¶0043 – 44: teaches that “when converting from the triplestore storage format to a key value storage format, each triple is converted to a key-value. When converting from the triplestore storage format to a wide column storage format, the conversion process first identifies all distinct predicates in the triples data and creates a column family for each. Thereafter, the conversion process iterates through each triple and forms a row for each”. Further, for “a conversion of external RDF data starts with the creation of a table that has two default columns: an identification column, serving as a primary key for the table, comprising serial integers starting from 1; and a resourceName column that includes strings designating the names of resources (as that term is generally used in RDF parlance). From this basic table, almost all properties (predicates) within the triples data are identified and converted into columns within the table.”)
expose the RDF datastore to a dashboard user interface module; (In ¶0073; Fig. 3 (322, 324 and 326) Fig. 4 (424 and 426): teaches “a number of query interfaces may be provided to offer various ways for users to access the RDF and relational data. For example, a SPARQL endpoint 424, as known in the art, supports the so-called SPARQL RDF query protocol 426. In this manner, a user may directly access the RDF DBMS 404 using SPARQL queries 428. Alternatively, the unified API 430 noted above may be used to not only support SPARQL queries 428 and SQL-like queries 432 for accessing the RDF DBMS 402, but to also support the use of SQL queries 433 for accessing the relational DBMS 402.” Refer to ¶0079 wherein “applications for use in conjunction with the data stored in the system 200, 300 may be developed using a plurality of hierarchical user interfaces” that include “first major developer interface 322, a second major developer interface 324 and a minor developer interface 326.”.)
receive a query from the dashboard user interface module; (In ¶0092: teaches that “the question-driven data mining component 334 receives users' questions expressed in natural language via, for example, an user interface for that specific purpose. As these complex questions (e.g., questions expressed in “why” or “how” form) are received, the question-driven data mining component 334 invokes processing by the NLP engine component 336 (as described below). See ¶0112 – 114 for examples of assembling/generating “potential questions based on the schema words and their relationships” or as user commands via a “text box”)
return a response to the query from the RDF datastore; and output, for display, a data visualization from the dashboard user interface module based on the response. (In ¶0115; Fig. 3 (340): teaches “If the user input does match an available question, the NLIDB modules searches the question in the Q&A table, locates the “answer” which is stored in the form of a database query, executes the query against database, and then returns the result back to the end user. If an user input does not match to an available question, then statistical processing, as described above, is employed” (see ¶0109 also). Further, in ¶0118, “a report engine component 340 is provided” wherein “the report engine component is a sub-component of minor developer interface 326. In particular, it is a GUI report builder that allows users to build reports by first generating a grand table that contains all (selected) data in the system. From the grand table, users can remove columns, add aggregate functions (e.g. sum, average, etc.) to columns, or add new columns based on calculations on existing columns resulting in a new table. This process may be repeated until the final desired table is acquired. Having set up this table, users can view all tables in one screen and the report engine component 340 visualizes the relationships between table columns.”)
Guo does not explicitly teach the crime-related data. However, Ianakiev teaches crime-related data as the system can “create a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (see ¶0048; Lanakiev).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions to crime-related data with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claim 2:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo teaches the defining ontology or “ontology information, i.e., information describing the structural framework used to organize information thereby providing a knowledge representation” which is used to “assist in the conversion of data from one storage format to another” (see ¶0026; Guo). However, Guo does not explicitly teach the ontology with specifying classes of crime-related data. However, Ianakiev further teaches:
wherein defining the ontology comprises specifying classes including crime, offender, victim, location, and time, and defining properties linking the classes. (In ¶0049: teaches that “once information is retrieved, it is classified using a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” which would include the specifying classes claimed.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide an ontology with specifying classes of crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions to crime-related data and its corresponding ontology classes with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claims 3 and 18:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claims 1 and 17, respectively.
Ianakiev teaches that “one can build ontology language upon Resource Description Framework (RDF)” (see ¶0125; Ianakiev) and teaches creating “a matrix of evidence types mapped to geolocation, criminology, prison systems databases” and classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” (see ¶0048 – 49; Ianakiev). However, Guo further teaches:
wherein defining the ontology comprises obtaining a definition for the ontology specifying a structured framework that enables both data organization and semantic enrichment of the crime-related data. (In ¶0110 – 111: teaches that “for schema fields with non-natural language symbols, the NLIDB module firstly tries to define the schema field's semantic meaning from the data type. If a data type is not available or does not meet the need, the NLIDB module then requires users to define their semantic meanings. For example, this could be done via the minor developer interface 326 described above.” Further, for “the interpretable schema field names, the NLIDB module looks up the words in an ontology definition, i.e., a description of the structure used in the underlying ontology. Once a meaning is located, the NLIDB module starts to expand the list of aliases that can be used as alternatives to the word in users' queries. This expansion can be performed in a number of different ways. According to one method, upper level ontology definitions are used as aliases. For example, an “employee” is the same thing as a “person” which is an example of obtaining the ontology definition with a structured framework to enable data organization and semantic enrichment of the data. Refer to ¶0044 wherein “Not all RDF properties are used in that manner because some properties (referred to herein as meta-properties) provide information about the underlying ontological structure of the data, rather than the semantic data itself, which ontological information may be used to further develop the relational database representation of the triples data being converted”.)
Regarding claim 5:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo further teaches:
wherein pre-processing further comprises converting categorical values of the crime-related data into numerical representations. (In ¶0088: teaches that “The automated data mining component 332 can engage in training in order to automatically select the best data pre-processing. To this end, a sample dataset is first gathered and the statistical characteristics thereof are extracted. Such statistical characteristics may include, for example, mathematical features such as mean, mode, median, range and standard deviation, etc. They may also include simple facts such as the number of attributes, the type of each attributes (e.g., nominal versus numerical), dataset size, etc.” Refer to ¶0113 – 115 wherein generated queries and corresponding answering results can include date/time fields.)
Regarding claim 6:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo further teaches:
wherein importing the dataset into the Resource Description Framework datastore comprises transforming the dataset from a tabular format into a linked data format compatible with the ontology. (In ¶0042: teaches that “When converting from a relational database storage format, the conversion process initially iterates through each table and, for each table, establishes a triple in which the predicate is fixed to “is a table of” Also, any foreign key relationships or other indexes or properties are identified in each table and included in the form of triples, e.g., “x:table1.column1 y:is_foreign_key_to_z:table2.column2.”” See ¶0048 wherein “a table can be viewed as a class, while the columns can be viewed as class properties and the tuples (rows/records) as the instances. Thus, in an embodiment, the approach to converting RDF formatted data to relational formatted data relies on converting RDF classes into relational tables and RDF instances into relational tuples.” See ¶0026 for a general example.)
Regarding claim 8:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo further teaches:
wherein the Resource Description Framework datastore is hosted on a triple store server configured to respond to semantic queries. (In ¶0068; Fig. 3 (308); Fig.4 (402 and 404): teaches that “FIG. 4 illustrates components of the triplestore database 308 and the relational database 304, particularly those components involved in data conversion, in greater detail. As shown, RDF data is maintained by an RDF DBMS 402 and, likewise, relational data is maintained by a relational DBMS 404. In an embodiment, RDF data from an external RDF datastore 406 may be imported into the RDF DBMS 404 via an RDF loader 408, as known in the art. To accomplish conversion of the external RDF data to relational data, the triplestore database 308 may include a conversion bridge 412 and inference engine 414.”.)
Regarding claims 9 and 19:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claims 1 and 17, respectively.
Guo further teaches:
wherein the instructions further configure the processing circuitry to receive a SPARQL (SPARQL Protocol and RDF Query Language) query and to return the response from the RDF datastore responsive to the SPARQL query. (In ¶0073: teaches “a SPARQL endpoint 424, as known in the art, supports the so-called SPARQL RDF query protocol 426. In this manner, a user may directly access the RDF DBMS 404 using SPARQL queries 428”. Refer to ¶0028 – 29 wherein “In querying the triplestore database 308, the controller 302 will form a SPARQL query of the type illustrated in Table 7” and “further mappings of this type will be readily derivable by those having ordinary skill in the art.”)
Regarding claim 10:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 9.
Guo further teaches:
wherein returning the response comprises executing a join operation across multiple RDF datasets. (In ¶0039: teaches “rules could be established to search for query patterns that imply many relationships, e.g. foreign key relationships, which, as known in the art, involve multiple join operations in relational databases that are very costly in time.”)
Regarding claim 11:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 1.
Ianakiev further teaches creating “a matrix of evidence types mapped to geolocation, criminology, prison systems databases” and classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” (see ¶0048 – 49; Ianakiev). Further, Ianakiev teaches “personalized report that includes Federal Agency Funded Actions for the list of contract number specified in the initial request” which includes data visualization of a pie chart with the inputted data (see ¶0189 and Fig. 12; Ianakiev). Thus, Guo further teaches:
wherein the data visualization comprises a temporal analysis of crime incidents reported during a selected year. (In ¶0118: teaches this non-functional descriptive matter under the broadest reasonable interpretation (BRI), such data visualization as the “report engine component 340 visualizes the relationships between table columns” based on user inputs from building a report which can be a temporal analysis of crime incidents reported for a selected year. Further, Guo teaches searching queries based on years (i.e. time period) such as “Who earned more than $10,000.00 last year?” (see ¶0107).)
Guo does not explicitly teach the crime-related data. However, Ianakiev teaches crime-related data as the system can “create a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (see ¶0048; Lanakiev).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions and data visualization to crime-related data with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claim 12:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Ianakiev further teaches creating “a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (i.e. which is directed to demographics) and classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” as crime-related data (see ¶0048 – 49; Ianakiev). Further, Ianakiev teaches “personalized report that includes Federal Agency Funded Actions for the list of contract number specified in the initial request” which includes data visualization of a pie chart with the inputted data (see ¶0189 and Fig. 12; Ianakiev). Thus, Guo further teaches:
wherein the data visualization comprises a demographic analysis of shooting incidents based on race, age, or location. (In ¶0118: teaches this non-functional descriptive matter under the broadest reasonable interpretation (BRI), such data visualization as the “report engine component 340 visualizes the relationships between table columns” based on user inputs from building a report which can be a demographic analysis of shooting incidents based on race, age, or location.)
Guo does not explicitly teach the crime-related data. However, Ianakiev teaches crime-related data as the system can “create a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (see ¶0048; Lanakiev).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions and data visualization to crime-related data with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claim 13:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Ianakiev further teaches creating “a matrix of evidence types mapped to geolocation, criminology, prison systems databases” and classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” as crime-related data (see ¶0048 – 49; Ianakiev). Further, Ianakiev teaches “personalized report that includes Federal Agency Funded Actions for the list of contract number specified in the initial request” which includes data visualization of a pie chart with the inputted data (see ¶0189 and Fig. 12; Ianakiev). Thus, Guo further teaches:
wherein the data visualization comprises a correlation analysis between different categories of crime-related data. (In ¶0118: teaches this non-functional descriptive matter under the broadest reasonable interpretation (BRI), such data visualization as the “report engine component 340 visualizes the relationships between table columns” based on user inputs from building a report which can be a correlation analysis between different categories of crime-related data. Further, in ¶0078, Guo teaches “complex and/or vague social networks, correlational relationships can be identified subject to additional human analysis. For example, a number of objects relating to an object “employee efficiency” may include “employee age,” “employee skill level,” “day of the week,” “factory temperature,” etc. In the case of neural network analysis, the data underlying these objects may be analyzed using known techniques to reveal a network function that effectively reveals the most significant factor in predicting the values of the “employee efficiency” object. The identification of such root causes may then be used to create associations between objects that previously did not exist, or to update or even delete previously defined associations.”)
Guo does not explicitly teach the crime-related data. However, Ianakiev teaches crime-related data as the system can “create a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (see ¶0048; Lanakiev).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions and data visualization to crime-related data with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claim 14:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Ianakiev further teaches creating “a matrix of evidence types mapped to geolocation, criminology, prison systems databases” and classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” as crime-related data (see ¶0048 – 49; Ianakiev) which further the “interplay of custodian scoping and early evidence review delivers timely insights that legal teams have, until now struggled to obtain” (see ¶0262; Ianakiev). Further, Ianakiev teaches “personalized report that includes Federal Agency Funded Actions for the list of contract number specified in the initial request” which includes data visualization of a pie chart with the inputted data (see ¶0189 and Fig. 12; Ianakiev). Thus, Guo further teaches:
further comprising generating insights from the RDF datastore responsive to the query, wherein the data visualization displays the insights. (In ¶0118: teaches this descriptive matter under the broadest reasonable interpretation (BRI), such data visualization as the “report engine component 340 visualizes the relationships between table columns” based on user inputs from building a report which can the generation of insights from the RDF datastore responsive to the query since Guo teaches searching queries such as “Who earned more than $10,000.00 last year?” (see ¶0107) and the user can obtain results when the system “searches the question in the Q&A table, locates the “answer” which is stored in the form of a database query, executes the query against database, and then returns the result back to the end user” (see ¶0115). Refer to ¶0116 – 117 wherein an “NLIDB function is employed, with the exception that schema fields are replaced by application module keywords, and questions are replaced by function description statements. That is, the NLAG function helps users (e.g., minor developer interface users, etc.) generate applications based on natural language descriptions. An application is assembled by functional modules or components, with each module achieving a sub functionality. The description of the application should explain the expected functionality of the application or what the application should accomplish. Examples include “I need a program that manages my employees” or more specific ones like “I want an application from which I can add, edit, update and delete employee information, accept P.O.s, and view assembly line status.” These descriptions reveal either high level or hierarchical functional requirements.” Finally, “after a user's input has been successfully parsed and a list of modules returned, the applicable development tool (e.g., the minor developer interface 326) allows the user to assemble the modules into an unified application, as described above.”)
Guo does not explicitly teach the crime-related data. However, Ianakiev teaches crime-related data as the system can “create a matrix of evidence types mapped to geolocation, criminology, prison systems databases” (see ¶0048; Lanakiev).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide crime-related data, as taught by Ianakiev in order to provide “an automated framework and technical devices for intelligent integration of two or more data sources or assets, data consumers, repositories and/or services together to automate, manage, synchronize, protect and/or monitor data fusion and exchange in real-time” as well as “to derive further value by organizations and/or individuals to support operations and guide actions” wherein it would be “obvious to try” to apply these functions and data visualization to crime-related data with the purpose of resolving criminal cases that are on an ongoing legal prosecution (¶0005 and ¶0016; Ianakiev), see also MPEP 2143.I.G.
Regarding claim 15:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo further teaches:
wherein returning the response comprises optimizing query execution to provide a near real-time response. (In ¶0108: teaches “By applying natural language grammar rules, the NLIDB module generates all possible questions that have definite answers including variant forms of the same question. This strategy sacrifices storage capacity (needed to store this huge list), which is relatively cheaper, to gain parsing accuracy and real-time performance. Since the parsing is as simple as matching strings, the performance is very fast and achieves real-time response.”)
Regarding claim 16:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Guo further teaches:
further comprising dynamically updating the Resource Description Framework datastore responsive to changes in the one or more data sources. (In ¶0027: teaches that “all data is added to, changed in, read from or deleted from the databases 304-308 via the controller 302, which, as noted above, terminates all database-specific protocols such that users of the controller 302 are presented with only a single interface”.)
Claims 4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Guo (U.S. Pub No. 20210117445 A1) in view of Ianakiev (U.S. Pub No. 20160021181 A1) in further view of Nevill (WO Pub No. 2024137770 A1).
Regarding claim 4:
The combination of Guo and Lanakiev, as shown in the rejection above, discloses the limitations of claim 1.
Lanakiev teaches classifying “a pre-defined ontology model based on the type of e-Discovery” like “criminal defense, etc.” (see ¶0048 – 49; Lanakiev) and the recognition of duplicate information in the algorithm used for processing input (see ¶0199; Lanakiev). However, neither Guo or Lanakiev explicitly teach the ability of specifically removing duplicate fields from the data. However, Nevill teaches:
wherein pre-processing further comprises removing duplicate fields from the crime-related data. (In ¶0070: teaches “detecting, by the data analysis system and based on the math model, a duplication of a component in the initial design and removing the duplicated component to improve execution speed”.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide the ability of specifically removing duplicate fields from the data., as taught by Nevill in order “to improve execution speed” and “to decrease the power consumption and improve execution speed” (¶0070 and ¶00330; Nevill), see also MPEP 2143.I.G.
Regarding claim 7:
The combination of Guo and Ianakiev, as shown in the rejection above, discloses the limitations of claim 6.
Guo further teaches:
wherein transforming the dataset comprises applying one or more transformation rules to generate axioms and the RDF triples representing relationships between elements of the dataset. (In ¶0031: teaches “the query parser is able to match existing query patterns to predefined data transformation triggering rules, examples of which are provided below. These rules are designed such, when a data pattern satisfies a given rule's conditions, the need to transform data from one storage format to another, either partially or in the whole, is detected. That is, predefined transformation rules permit the controller 302 to decide whether certain data can be transformed; if it can be transformed, the controller 302 initiates a transformation process that iterates through the original data (i.e., stored in the first data storage format) and creates new data in the targeted or second data storage format.” Further in ¶0033, “rules may be employed to determine when the controller 302 should initiate data transformations. In an embodiment, various factors may be considered to establish such rules, which factors may be generally grouped into data factors or characteristics and usage factors or characteristics.”)
Neither Guo or Ianakiev explicitly teaches generating axioms when applying transformation rules. However, Nevill teaches the generation of axioms when “applying, by the data analysis system, at least one of an axiom or theorem from the knowledge base to modify the math model to satisfy the one or more target properties.” (see ¶0070; Nevill).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Guo to provide the ability of generating axioms when applying transformation rules to datasets, as taught by Nevill in order “to optimize the math model” and “to optimize a circuit design” (¶00330 and ¶00349; Nevill), see also MPEP 2143.I.G.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Piecko (U.S. Pub No. 20200320045 A1) is pertinent because it “provides methods and systems that may enable a user to translate a search path used for a particular data model into a semantic format, such that the semantic form search path can be applied to different data models.”
Chakravarthy (U.S. Pub No. 20210232617 A1) is pertinent because it “relates to a method of interrogating a sematic database, and more specifically to Semantic Search Algorithms (SSAs), where the user starts with partial or incomplete knowledge and derives the full picture which the use of the algorithm. In the field of information retrieval, known SSAs can receive as an input a search pattern (also known as search query), comprising of a series of nodes and associated values, which the algorithm then uses to look up within a database patterns which correspond to the search query. For example, a travel website may take input values for a series of nodes corresponding to location, cost, and date range (with associated values such as “Spain”, “under £3000”, “from 1/8/2018”) and return suitable patterns from the database which match the search query.”
O'Malley (U.S. Patent No. 9710836 B1) is pertinent because it “generally related to firearm transactions and, even more particularly, to systems and methods for monitoring, analyzing, evaluation, scoring, and interrogating weapon and ammunition transactions, buyers, sellers, FFLs, actors/users, along with trends, storage, transporting, training, targeting, firing and usage patterns.”
Mayer (U.S. Pub No. 20130144863 A1) is pertinent because it “relates to the field of collecting data from a wide variety of sources, restructuring the data, and searching the data. In particular, but not by way of limitation, the present disclosure teaches techniques for collecting, restructuring, and searching text data used by law enforcement officials.”
Gomadam (U.S. Pub No. 20160253364 A1) is pertinent because it “relates to complex system architectures for linking databases within a diverse data system.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights