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 .
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.
Examiner Notes
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121 (b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131 (b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as "Applicants believe no new matter has been introduced" may be deemed insufficient.
(2) Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Response to Arguments
Applicant’s arguments, see page 10, filed 05/04/2026, with respect to the rejection of claims 1, 8 and 16 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Li et al. (U.S. Pub. No. 2016/0210327 A1).
Claim Rejections - 35 USC § 103
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 of this title, 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, 6-7, 13 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Vaitheeswaran et al. (U.S. Pub. No. 2013/0166573 A1) in view of Atkins et al. (U.S. Patent No. 6,240,422 B1) and Li et al. (U.S. Pub. No. 2016/0210327 A1).
Regarding claim 1, Vaitheeswaran teaches a method comprising:
receiving a request to identify targeted data for a data subject, the request comprising a first data value of a first data type for the data subject (paragraph [0104], paragraph [0030], receiving a search query that includes one or more query terms; each query terms at least partially represents metadata associated with at least one business objects data source of multiple object data sources);
determining, by computing hardware, that the targeted data comprises a second data type (paragraph [0030], [0044], [0058], [0069], for each query term, the business object engine also identifies metadata associated with the identified one or more business object data sources by searching the multiple master tables; the search engine can identify a match for query term by identifying the type of data that the query term represented, the search engine can search index document storage and metadata that satisfies the converted query format, upon identifying columns that match the search query, the search engine can generate a query that includes the identified metadata; also see paragraph [0078], [0080], [0082], [0085]-[0086], generating tuples that use for searching with various combination; validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; validating the tuples based on relationship between vertex; the validated tuples as follow: {City, Sales Revenue}, {Store Name, Sales Revenue}, {City, Store name, Sales Revenue}).
Vaitheeswaran does not explicitly disclose: determining, based on a first graph data structure by the computing hardware, that a first data source stores data of the second data type.
Atkins teaches: determining, based on a first graph data structure by the computing hardware, that a first data source stores data of the second data type (Fig. 5, col. 9, line 5-55, the next child node to be processed is the List Node object 122 representing the list of Account object 124 maps the number of object contained in the list to the database; the node object 124 provides the functionality to map from and to the number of entries in the list of accounts; the node object 132, 134 provides functionality to map from and to the AccountID attribute in Account objects; the associated database fields object 136, 138 provides the functionality to map to and from the buffer of ACCOUNT_ID_1 respectively ACCOUNT_ID_2 column of the CUSTOMER table; the list node 122 also contains a reference TableManager object 140 for the ACCOUNT_OVERFLOW table, this part of the tree is traversed for any overflow objects that exist in the list of Account objects).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include determining, based on a first graph data structure by the computing hardware, that a first data source stores data of the second data type into data retrieval of Vaitheeswaran.
Motivation to do so would be to include determining, based on a first graph data structure by the computing hardware, that a first data source stores data of the second data type utilizing a third data type to provide an overflow mechanism used to enhance the speed of access (Atkins, col. 1, line 60-67).
Vaitheeswaran as modified by Atkins do not explicitly disclose: the first data source is queryable utilizing a third data type.
Li teaches: the first data source is queryable utilizing a third data type (paragraph [0036], the data sources 106 A-C can includes a variety searchable and retrievable indexed in variety way; also see paragraph [0037], querying a data source server (as determined by looking up the type of data in the library)…; also see paragraph [0014], the API can be configured to analyze the query and determine the type of data that is being requested, and based on the type(s) of data being request, the API can determine which of the plurality of data source to query to receive the information; also see paragraph [0044], the API can analyze the request and determine the source(s) to be queried to satisfy the request; the API can look up the hierarchy to determine the order in which the data sources will be queried; the API determines that it is to query the data source 106B for article ID; also see paragraph [0052], the engagement field can indicate a type of user engagement that is required to return a result; also see paragraph [0053], the returned type field can indicate the data to be returned and/or a format of data to be returned; the use can indicate that the content of an article and/or specific metadata of article (author, publisher, length data of publication, etc.) is to be returned; also see pargraph [0022]).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include the first data source is queryable utilizing a third data type into data retrieval of Vaitheeswaran.
Motivation to do so would be to include the first data source is queryable utilizing a third data type that retrieve data from multiple data sources automatically (e.g., without human interference) (Li, paragraph [0011], line 6-7).
Vaitheeswaran as modified by Atkins and Li further teach:
determining, based on a second graph data structure by the computing hardware, that a second data source stores data of the first data type (Vaitheeswaran, paragraph [0030], [0044], [0058], [0069], for each query term, the business object engine also identifies metadata associated with the identified one or more business object data sources by searching the multiple master tables; the search engine can identify a match for query term by identifying the type of data that the query term represented, the search engine can search index document storage and metadata that satisfies the converted query format, upon identifying columns that match the search query, the search engine can generate a query that includes the identified metadata; also see paragraph [0078], [0080], [0082], [0085]-[0086], generating tuples that use for searching with various combination; validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; validating the tuples based on relationship between vertex; the validated tuples as follow: {City, Sales Revenue}, {Store Name, Sales Revenue}, {City, Store name, Sales Revenue}) and that the second data source is queryable utilizing the first data type (Li, paragraph [0036], the data sources 106 A-C can includes a variety searchable and retrievable indexed in variety way; also see paragraph [0037], querying a data source server (as determined by looking up the type of data in the library)…; also see paragraph [0014], the API can be configured to analyze the query and determine the type of data that is being requested, and based on the type(s) of data being request, the API can determine which of the plurality of data source to query to receive the information; also see paragraph [0044], the API can analyze the request and determine the source(s) to be queried to satisfy the request; the API can look up the hierarchy to determine the order in which the data sources will be queried; the API determines that it is to query the data source 106B for article ID; also see paragraph [0052], the engagement field can indicate a type of user engagement that is required to return a result; also see paragraph [0053], the returned type field can indicate the data to be returned and/or a format of data to be returned; the use can indicate that the content of an article and/or specific metadata of article (author, publisher, length data of publication, etc.) is to be returned; also see pargraph [0022]);
based on determining that the second data source is queryable utilizing the first data type, querying, by the computing hardware, the second data source utilizing the first data value to retrieve a second data value of the third data type for the data subject (Vaitheeswaran, paragraph [0073]-[0074], [0078], [0098], line 10-13, matching ‘Sales Revenue’ and ‘Sale Person’ with term ‘sales’, matching ‘store name’ with ‘Store Name’, matching ‘Bangalore’ with column ‘City’, generating tuples as ‘Sales Revenue, Store Name, City’, ‘Sales Revenue, Store Name’, ‘Sales Revenue, City’; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; the business object data sources can be searched to identify data items that satisfy the tuples);
based on determining that the first data source is queryable utilizing the third data type, querying, by the computing hardware, the first data source utilizing the second data value to retrieve a third data value of the second data type for the data subject (Li, paragraph [0036], the data sources 106 A-C can includes a variety searchable and retrievable indexed in variety way; also see paragraph [0037], querying a data source server (as determined by looking up the type of data in the library)…; also see paragraph [0014], the API can be configured to analyze the query and determine the type of data that is being requested, and based on the type(s) of data being request, the API can determine which of the plurality of data source to query to receive the information; also see paragraph [0044], the API can analyze the request and determine the source(s) to be queried to satisfy the request; the API can look up the hierarchy to determine the order in which the data sources will be queried; the API determines that it is to query the data source 106B for article ID; also see paragraph [0052], the engagement field can indicate a type of user engagement that is required to return a result; also see paragraph [0053], the returned type field can indicate the data to be returned and/or a format of data to be returned; the use can indicate that the content of an article and/or specific metadata of article (author, publisher, length data of publication, etc.) is to be returned; also see pargraph [0022]; in combination with the teaching of Vaitheeswaran, paragraph [0078], [0080], [0082], [0085]-[0086], paragraph [0098], line 10-13, teaches: generating tuples that use for searching with various combination; validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; validating the tuples based on relationship between vertex; the validated tuples as follow: {City, Sales Revenue}, {Store Name, Sales Revenue}, {City, Store name, Sales Revenue}; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; also see paragraph [0073]-[0074], [0078], [0098], line 10-13, matching ‘Sales Revenue’ and ‘Sale Person’ with term ‘sales’, matching ‘store name’ with ‘Store Name’, matching ‘Bangalore’ with column ‘City’, generating tuples as ‘Sales Revenue, Store Name, City’, ‘Sales Revenue, Store Name’, ‘Sales Revenue, City’; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; the business object data sources can be searched to identify data items that satisfy the tuples, it reads on as claimed);
and performing, by the computing hardware, a targeted data action utilizing the third data value as the targeted data for the data subject (Vaitheeswaran, paragraph [0084], executing on multiple business objects data sources through the data source connection to fetch data items represented by the tuples).
Regarding claim 2, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 1, further teach determining that the first data source is not queryable utilizing the first data type (Vaitheeswaran, paragraph [0085]-[0086], [0098], line 10-13, validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; determining the ‘Review group’ may not have relationship with other, and consequently disregard all tuples containing ‘Review Group’, noted, tuples that are not passed validation check, which are considered “not queryable”; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; in combination with retrievable based on data type taught by Li, it reads on as claimed).
Regarding claim 3, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 1, further teach wherein performing the targeted data action comprises: generating a location map for the targeted data that comprises storage locations for the targeted data; providing the targeted data for display on a graphical user interface of a client device that submitted the request to identify the targeted data for the data subject; or removing the targeted data from the first data source (Atkins, Fig. 5, col. 9, line 5-55, the next child node to be processed is the List Node object 122 representing the list of Account object 124 maps the number of object contained in the list to the database; the node object 124 provides the functionality to map from and to the number of entries in the list of accounts; the node object 132, 134 provides functionality to map from and to the AccountID attribute in Account objects; the associated database fields object 136, 138 provides the functionality to map to and from the buffer of ACCOUNT_ID_1 respectively ACCOUNT_ID_2 column of the CUSTOMER table; the list node 122 also contains a reference TableManager object 140 for the ACCOUNT_OVERFLOW table, this part of the tree is traversed for any overflow objects that exist in the list of Account objects).
Regarding claim 6, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 1, further teach: determining, based on a third graph data structure by the computing hardware, that a third data source stores data of the second data type (Vaitheeswaran, paragraph [0030], [0044], [0058], [0069], for each query term, the business object engine also identifies metadata associated with the identified one or more business object data sources by searching the multiple master tables; the search engine can identify a match for query term by identifying the type of data that the query term represented, the search engine can search index document storage and metadata that satisfies the converted query format, upon identifying columns that match the search query, the search engine can generate a query that includes the identified metadata; also see paragraph [0078], [0080], [0082], [0085]-[0086], [0098], generating tuples that use for searching with various combination; validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; validating the tuples based on relationship between vertex; the validated tuples as follow: {City, Sales Revenue}, {Store Name, Sales Revenue}, {City, Store name, Sales Revenue}); determining the ‘Review group’ may not have relationship with other, and consequently disregard all tuples containing ‘Review Group’, noted, tuples that are passed validation check, which are considered “queryable”; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified) and that the third data source is queryable utilizing the first data type (Li, paragraph [0036], the data sources 106 A-C can includes a variety searchable and retrievable indexed in variety way; also see paragraph [0037], querying a data source server (as determined by looking up the type of data in the library)…; also see paragraph [0014], the API can be configured to analyze the query and determine the type of data that is being requested, and based on the type(s) of data being request, the API can determine which of the plurality of data source to query to receive the information; also see paragraph [0044], the API can analyze the request and determine the source(s) to be queried to satisfy the request; the API can look up the hierarchy to determine the order in which the data sources will be queried; the API determines that it is to query the data source 106B for article ID; also see paragraph [0052], the engagement field can indicate a type of user engagement that is required to return a result; also see paragraph [0053], the returned type field can indicate the data to be returned and/or a format of data to be returned; the use can indicate that the content of an article and/or specific metadata of article (author, publisher, length data of publication, etc.) is to be returned; also see pargraph [0022]); and based on determining that the third data source is queryable utilizing the first data type, querying, by the computing hardware, the third data source utilizing the second data value to retrieve a fourth data value of the second data type for the data subject (Li, paragraph [0036], the data sources 106 A-C can includes a variety searchable and retrievable indexed in variety way; also see paragraph [0037], querying a data source server (as determined by looking up the type of data in the library)…; also see paragraph [0014], the API can be configured to analyze the query and determine the type of data that is being requested, and based on the type(s) of data being request, the API can determine which of the plurality of data source to query to receive the information; also see paragraph [0044], the API can analyze the request and determine the source(s) to be queried to satisfy the request; the API can look up the hierarchy to determine the order in which the data sources will be queried; the API determines that it is to query the data source 106B for article ID; also see paragraph [0052], the engagement field can indicate a type of user engagement that is required to return a result; also see paragraph [0053], the returned type field can indicate the data to be returned and/or a format of data to be returned; the use can indicate that the content of an article and/or specific metadata of article (author, publisher, length data of publication, etc.) is to be returned; also see pargraph [0022]); in combination of the teaching of Vaitheeswaran, paragraph [0073]-[0074], [0078], [0098], line 10-13, teaches: matching ‘Sales Revenue’ and ‘Sale Person’ with term ‘sales’, matching ‘store name’ with ‘Store Name’, matching ‘Bangalore’ with column ‘City’, generating tuples as ‘Sales Revenue, Store Name, City’, ‘Sales Revenue, Store Name’, ‘Sales Revenue, City’; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; the business object data sources can be searched to identify data items that satisfy the tuples, it reads on as claimed).
Regarding claim 7, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 6, further teach: wherein performing the targeted data action comprises: utilizing the third data value from the first data source and the fourth data value from the third data source as the targeted data for the data subject (Vaitheeswaran, paragraph [0073]-[0074], [0078], [0098], line 10-13, matching ‘Sales Revenue’ and ‘Sale Person’ with term ‘sales’, matching ‘store name’ with ‘Store Name’, matching ‘Bangalore’ with column ‘City’, generating tuples as ‘Sales Revenue, Store Name, City’, ‘Sales Revenue, Store Name’, ‘Sales Revenue, City’; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified; the business object data sources can be searched to identify data items that satisfy the tuples; also see paragraph [0084], executing on multiple business objects data sources through the data source connection to fetch data items represented by the tuples).
As per claims 8 and 16, these claims are rejected on grounds corresponding to the same rationales given above for rejected claim 1 and are similarly rejected.
As per claim 13, this claim rejected on grounds corresponding to the same rationales given above for rejected claim 3 and is similarly rejected.
Claims 4-5, 14-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vaitheeswaran et al. (U.S. Pub. No. 2013/0166573 A1) in view of Atkins et al. (U.S. Patent No. 6,240,422 B1) and Li et al. (U.S. Pub. No. 2016/0210327 A1), further in view of KABRA et al. (U.S. Pub. No. 2021/0081435 A1).
Regarding claim 4, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 1, further teach wherein determining, based on the first graph data structure by the computing hardware, that the first data source stores data of the second data type (Vaitheeswaran, paragraph [0007], line 14-21, Fig. 6A, 6B1-6B2, illustrates the mapping of data fields that storing targeted data in one or more business object data sources; identifying one or more columns in which the identified one or more data items are stored) but do not explicitly disclose: utilizing a machine learning model to process features of data fields of the first data source to generate a prediction that the data fields are used for storing data of the second data type.
KABRA teaches: utilizing a machine learning model to process features of data fields of the first data source to generate a prediction that the data fields are used for storing data of the second data type (paragraph [0032], using machine learning, for instance, aspects can determine which of the candidate data classes of the collection are more likely to match the data of the target column; when a particular class matches with a threshold level of confidence, further comparison could be avoided; potentially be mapped to data classes in the collection of candidate data class so that data classes in the available collection can be correlated to target dataset columns; also see paragraph [0025], the data classification system further processes and classified data by storing it to database, possibly after applying modifications, transformations, or the like based on the data classes assigned to the various columns of the received data; also see Fig. 2A-2B, paragraph [0026]).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include utilizing a machine learning model to process features of data fields of the first data source to generate a prediction that the data fields are used for storing data of the second data type into data retrieval of Vaitheeswaran.
Motivation to do so would be to include utilizing a machine learning model to process features of data fields of the first data source to generate a prediction that the data fields are used for storing data of the second data type to reduce the number of data classes to attempt to match against; when a particular class matches with a threshold level of confidence, further comparison could be avoided (KABRA, paragraph [0032], line 8-11).
Regarding claim 5, Vaitheeswaran as modified by Atkins, Li and KABRA teach all claimed limitations as set forth in rejection of claim 4, further teach wherein utilizing the machine learning model to process the features of the data fields of the first data source to generate the prediction that the data fields are used for storing data of the second data type comprises: utilizing a classification neural network to generate a confidence indicator that the data fields are used for storing data of the second data type; and determining that the confidence indicator satisfies a threshold level of confidence (KABRA, paragraph [0032], using machine learning, for instance, aspects can determine which of the candidate data classes of the collection are more likely to match the data of the target column; when a particular class matches with a threshold level of confidence, further comparison could be avoided; potentially be mapped to data classes in the collection of candidate data class so that data classes in the available collection can be correlated to target dataset columns; also see paragraph [0025], the data classification system further processes and classified data by storing it to database, possibly after applying modifications, transformations, or the like based on the data classes assigned to the various columns of the received data; also see paragraph [0040], any class with a confidence level above some threshold (say 50%) in classifying columns associated with a given term may be selected for comparison to value(s) in the target column; also see Fig. 2A-2B, paragraph [0026], [0038]; noted, it is noted that one of the ordinary skill in the art would know that machine learning model comprising neural network; see FUKUMOTO et al. (U.S. Pub. No. 2021/0397598 A1)).
As per claims 14 and 15, these claims are rejected on grounds corresponding to the same rationales given above for rejected claims 4 and 5 respectively and are similarly rejected.
As per claims 19 and 20, these claims are rejected on grounds corresponding to the same rationales given above for rejected claims 4 and 5 respectively and are similarly rejected.
Claims 9-11, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vaitheeswaran et al. (U.S. Pub. No. 2013/0166573 A1) in view of Atkins et al. (U.S. Patent No. 6,240,422 B1) and Li et al. (U.S. Pub. No. 2016/0210327 A1), further in view of ISHERWOOD et al. (U.S. Pub. No. 2018/0357333 A1).
Regarding claim 9, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 8, further teach: wherein the operations further comprise generating metadata for the first data source by: determining that the third data type is eligible to query the first data source in response to scanning a plurality of data types comprising the first data type, the second data type, and the third data type in the first data source (Vaitheeswaran, table 7, paragraph [0030], [0044], [0058], [0069], for each query term, the business object engine also identifies metadata associated with the identified one or more business object data sources by searching the multiple master tables; the search engine can identify a match for query term by identifying the type of data that the query term represented, the search engine can search index document storage and metadata that satisfies the converted query format, upon identifying columns that match the search query, the search engine can generate a query that includes the identified metadata; also see paragraph [0078], [0080], [0082], [0085]-[0086], generating tuples that use for searching with various combination; validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; validating the tuples based on relationship between vertex; the validated tuples as follow: {City, Sales Revenue}, {Store Name, Sales Revenue}, {City, Store name, Sales Revenue}) but do not explicitly disclose: generating the metadata of the first data source to include the third data type within a set of known queryable data types for the first data source.
ISHERWOOD teaches: generating the metadata of the first data source to include the third data type within a set of known queryable data types for the first data source (paragraph [0058], the name 502 in this example is ‘doctormail’ which may be a user specified unique name for the content property, and which is a human meaningful name that can be used for a search query; also see paragraph [0057], extracting a specific metadata field or other data value from objects, index the extract data value under a user-defined name, and make that data value multi-dimensional queryable via a search query; also see paragraph [0024], the data may be indexed with added, changed, or otherwise enhanced metadata that make the data easier to find, regardless of the type of data or the storage location of data).
Vaitheeswaran and ISHERWOOD are analogous art since they are in the same field of endeavor: querying data object, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include generating the metadata of the first data source to include the third data type within a set of known queryable data types for the first data source to make data easier to find, regardless of the type of data or the storage location of the data (ISHERWOOD, paragraph [0024], line 11-12).
Regarding claim 10, Vaitheeswaran as modified by Atkins, Li and ISHERWOOD teach all claimed limitations as set forth in rejection of claim 9, further teach: wherein the operations further comprise: determining that the first data type is not eligible to query the targeted data from the first data source; and excluding the first data type from the set of known queryable data types for the first data source from the metadata (Vaitheeswaran, paragraph [0085]-[0086], [0098], line 10-13, validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; determining the ‘Review group’ may not have relationship with other, and consequently disregard all tuples containing ‘Review Group’, noted, tuples that are not passed validation check, which are considered “not queryable”; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified).
Regarding claim 11, Vaitheeswaran as modified by Atkins, Li and ISHERWOOD teach all claimed limitations as set forth in rejection of claim 10, further teach: wherein the operations further comprise: determining that the set of known queryable data types from the metadata of the first data source does includes a third data type (ISHERWOOD, paragraph [0058], the name 502 in this example is ‘doctormail’ which may be a user specified unique name for the content property, and which is a human meaningful name that can be used for a search query; also see paragraph [0057], extracting a specific metadata field or other data value from objects, index the extract data value under a user-defined name, and make that data value multi-dimensional queryable via a search query; also see paragraph [0024], the data may be indexed with added, changed, or otherwise enhanced metadata that make the data easier to find, regardless of the type of data or the storage location of data); and in response to determining that the third data type is eligible to query the first data source, modifying the metadata to include the third data type in the set of known queryable data types (ISHERWOOD, paragraph [0058], the name 502 in this example is ‘doctormail’ which may be a user specified unique name for the content property, and which is a human meaningful name that can be used for a search query; also see paragraph [0057], extracting a specific metadata field or other data value from objects, index the extract data value under a user-defined name, and make that data value multi-dimensional queryable via a search query; also see paragraph [0024], the data may be indexed with added, changed, or otherwise enhanced metadata that make the data easier to find, regardless of the type of data or the storage location of data).
Regarding claim 17, Vaitheeswaran as modified by Atkins and Li teach all claimed limitations as set forth in rejection of claim 8, but do not explicitly disclose: determining that the first data type is eligible for querying the second data source by: accessing a set of known queryable data types for the second data source from metadata of the second data source; determining that the set of known queryable data types comprises the first data type.
ISHERWOOD teaches: determining that the first data type is eligible for querying the second data source by: accessing a set of known queryable data types for the second data source from metadata of the second data source (paragraph [0058], the name 502 in this example is ‘doctormail’ which may be a user specified unique name for the content property, and which is a human meaningful name that can be used for a search query; also see paragraph [0057], extracting a specific metadata field or other data value from objects, index the extract data value under a user-defined name, and make that data value multi-dimensional queryable via a search query); determining that the set of known queryable data types comprises the first data type (paragraph [0058], the name 502 in this example is ‘doctormail’ which may be a user specified unique name for the content property, and which is a human meaningful name that can be used for a search query; also see paragraph [0057], extracting a specific metadata field or other data value from objects, index the extract data value under a user-defined name, and make that data value multi-dimensional queryable via a search query; also see paragraph [0024], the data may be indexed with added, changed, or otherwise enhanced metadata that make the data easier to find, regardless of the type of data or the storage location of data).
Vaitheeswaran and ISHERWOOD are analogous art since they are in the same field of endeavor: querying data object, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include determining that the first data type is eligible for querying the second data source by: accessing a set of known queryable data types for the second data source from metadata of the second data source; determining that the set of known queryable data types comprises the first data type to make data easier to find, regardless of the type of data or the storage location of the data (ISHERWOOD, paragraph [0024], line 11-12).
Regarding claim 18, Vaitheeswaran as modified by Atkins, Li and ISHERWOOD teach all claimed limitations as set forth in rejection of claim 17, further teach: determining that the set of known queryable data types from the metadata of the second data source does not include the second data type; and in response to determining that the second data type is ineligible to query the second data source, modifying the metadata to exclude the second data type in the set of known queryable data types (Vaitheeswaran, paragraph [0085]-[0086], [0098], line 10-13, validating the tuples to check whether the generated tuple is valid, a valid path can exist if one of the following conditions is true- (1) if both the object belong to same relational table, (2) if object belong to two different tables and there exists a direct/indirect join relationship between the two different tables; determining the ‘Review group’ may not have relationship with other, and consequently disregard all tuples containing ‘Review Group’, noted, tuples that are not passed validation check, which are considered “not queryable”; business objects data sources that are each associated with associated with metadata at least partially represented by the identified query term can be identified).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Vaitheeswaran et al. (U.S. Pub. No. 2013/0166573 A1) in view of Atkins et al. (U.S. Patent No. 6,240,422 B1), Li et al. (U.S. Pub. No. 2016/0210327 A1), and ISHERWOOD et al. (U.S. Pub. No. 2018/0357333 A1), further in view of McCormick (U.S. Pub. No. 2020/0057781 A1).
Regarding claim 12, Vaitheeswaran as modified by Atkins, Li and ISHERWOOD teach all claimed limitations as set forth in rejection of claim 9, but do not explicitly disclose: wherein the operations further comprise: determining that a new field corresponding to an additional data type is added to a first graph data structure for the first data source after generation of the metadata for the first data source.
McCormick teaches: determining that a new field corresponding to an additional data type is added to a first graph data structure for the first data source after generation of the metadata for the first data source (Fig. 3, paragraph [0049]-[0050], paragraph [0072], paragraph [0035], the retrieval method may be a ‘scan’ and ‘get’; compacted multiple fields using delimiter to generate compacted metadata, for example, first name concatenated with last name using a period as delimiter; also see paragraph [0023]-[0024], paragraph [0034], paragraph [0038], line 12-15).
Vaitheeswaran and McCormick are analogous art since they are in the same field of endeavor: object data retrieval, therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include determining that a new field corresponding to an additional data type is added to a first graph data structure for the first data source after generation of the metadata for the first data source to build a mapping; this mapping is used when retrieving objects from the key-value data store (McCormick, paragraph [0030], line 14-19).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEN HOANG whose telephone number is (571)272-8401. The examiner can normally be reached M-F 7:30am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached at (571)272-4085. 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.
/KEN HOANG/ Examiner, Art Unit 2168
Prosecution Insights