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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 1, 2025 has been entered.
Response to Amendment
Applicant’s Amendments, filed December 1, 2025, have been entered. Claims 1, 8 and 15 have been amended and claims 1, 3-8, 10-15 and 17-20 are currently pending.
Response to Arguments
Applicant’s arguments, see Remarks pp. 8-11, filed December 1, 2025, with respect to the rejections of claims 1, 3-8, 10-15 and 17-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Halstead et al. (Pub. No. US 2021/0165786 A1, hereinafter “Halstead”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 4, 6, 7, 8, 11, 13, 14, 15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al. (Patent No. US 8,954,412 B1, hereinafter “Zhao”) in view of Halstead et al. (Pub. No. US 2021/0165786 A1, hereinafter “Halstead”) in view of Vuong et al. (Pub. No. US 2014/0280201 A1, hereinafter “Vuong”).
Regarding claim 1, Zhao teaches:
identifying a plurality of fact tables from a data source, each fact table having one or more respective attributes (Zhao – the documents stored by a host 102 (i.e. data source) are typically held in a file directory, a database, or other data repository. Data processing system 106 includes one or more janitors, a build engine, a service engine, and a fact repository. Importers operate to process documents received from the document hosts, read the data content of documents, and extract facts from such documents [Col. 2 lines 49-65]. Some or all of documents hosts 102 (i.e. data source) are located on the data processing system 106 instead of being coupled to data processing system 106 by a network. For example, importer may import facts from a database that is part of the data processing system 106 [Col. 3 lines 65-67, Col. 4 lines 1-2]. Janitors operate to process facts extracted by importer, which may include data cleansing and object merging [Col. 3 lines 4-7]. Various janitors act on facts to normalize attribute names and values (i.e. one or more respective attributes), and delete duplicate information so an object doesn’t have redundant information [Col. 3 lines 20-23]. Repository contains one or more facts, and each fact is associated with exactly one object [Col. 4 lines 45-46]. Examiner interprets that objects, which contains one or more facts, disclose a plurality of fact tables (see Applicant’s Specification [00111], where a table may be considered a fact object or data object). Examiner interprets that the document host is part of the data processing system.)
for each of the plurality of fact tables, generating a respective fact key, and for each attribute of each fact table, generating a respective attribute key based on attribute information associated with the respective attribute; storing the fact keys and attribute keys at a plurality of storage locations in a data catalog, wherein each storage location corresponds to unique one of fact keys (Zhao – build engine builds and manages the repository (i.e. data catalog) [Col. 3 line 34]. Repository contains one or more facts [Col. 3 line 45]. Each fact includes a unique identifier (i.e. fact key) for that fact. Each fact includes at least an attribute and a value (i.e. attribute key). For example, a fact associated with an object representing George Washington may include an attribute of “date of birth” and a value of “Feb. 22, 1732” [Col. 5 lines 11-16]. Also, see Fig. 2A, 204, where each fact is stored as a tuple with a unique identifier (i.e. storage location corresponds to unique one of fact keys) [Col. 5 lines 8-36, where tuple is mentioned in lines 31-36].)
stored in the data catalog (Zhao – build engine builds and manages the repository (i.e. data catalog) [Col. 3 line 34].)
Zhao does not appear to teach:
receiving a query that specifies a join operation between a first fact table and one or more attribute tables
and in response to receiving the query, generating and executing a membership query, wherein the membership query specifies the first fact table and one or more attributes of the one or more attribute tables; and generating a query fact key based on the membership query, wherein the query fact key corresponds to the first fact table specified in the membership query; generating one or more query attribute keys based on the membership query, where the one or more query attribute keys correspond to the one or more attributes of the first fact table specified in the membership query
in accordance with a determination that the query fact key matches a respective fact key stored in the data catalog, comparing the one or more query attribute keys with an attribute vector associated with the respective fact key, where the attribute vector includes one or more attribute keys identifying attributes of the first fact table stored in the data catalog
and providing a query result whether or not the one or more query attribute keys match the one or more attribute keys in the attribute vector stored in the data catalog
However, Halstead teaches:
receiving a query that specifies a join operation between a first fact table and one or more attribute tables (Halstead – see [0266-0271], where Fig. 9a illustrates the fact that a dataset comprising more than one key attribute can be broken down in several single-key attribute datasets (i.e. attribute tables). Dataset Z (i.e. fact table) is taken as an example, as it contains both name and email key data. From dataset Z, three new datasets can be formed. These new “child” datasets (attribute table) can be used separately. Also see [0276], Fig. 5, which is a schematic architectural diagram which gives one example of a join process. As shown in Fig. 5, a query is received at the controller. The controller splits the query into three separate queries, a first query with a first filter expression X1, a second query with a second filter expression X2, and a third target query with a target expression TARGET. As an example, the first filter expression could be an age range, the second filter expression could be income and the target expression could be gender. The first query with the first filter expression X1 is sent to the first database 12a of a financial organization labelled Financial DB1 (i.e. attribute table).)
and in response to receiving the query, generating and executing a membership query, wherein the membership query specifies the first fact table and one or more attributes of the one or more attribute tables; and generating a query fact key based on the membership query, wherein the query fact key corresponds to the first fact table specified in the membership query; generating one or more query attribute keys based on the membership query, where the one or more query attribute keys correspond to the one or more attributes of the first fact table specified in the membership query (Halstead – see [0266-0271], where Fig. 9a illustrates the fact that a dataset comprising more than one key attribute can be broken down in several single-key attribute datasets (i.e. attribute tables). Dataset Z (i.e. fact table) is taken as an example, as it contains both name and email key data. From dataset Z, three new datasets can be formed. These new “child” datasets (attribute table) can be used separately. Also see [0277-0278], where a bloom filter can be applied to test whether an element is a member of a set (i.e. membership query). It consists of a set of positions which can be set to ‘1’ or ‘0’ depending on whether the position is occupied. In the present context, the positions represent identifiers (i.e. query attribute keys), and each identifier identifies one or more rows of the database.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao and Halstead before them, to modify the system of Zhao with the teachings of Halstead as indicated above. One would have been motivated to make such a modification to join data from databases and determining the intersection between those datasets (Halstead - [0014-0016]).
Zhao modified by Halstead does not appear to teach:
in accordance with a determination that the query fact key matches a respective fact key stored in the data catalog, comparing the one or more query attribute keys with an attribute vector associated with the respective fact key, where the attribute vector includes one or more attribute keys identifying attributes of the first fact table stored in the data catalog
and providing a query result whether or not the one or more query attribute keys match the one or more attribute keys in the attribute vector stored in the data catalog
However, Vuong teaches:
in accordance with a determination that the query fact key matches a respective fact key stored in the data catalog, comparing the one or more query attribute keys with an attribute vector associated with the respective fact key, where the attribute vector includes one or more attribute keys identifying attributes of the first fact table stored in the data catalog (Vuong – at operation 340, disambiguation module compares a hash of the matched search query string (i.e. query attribute key) to concepts in the hash table database (i.e. attribute vector) to determine if the matched attribute should be interpreted as an attribute or non-attribute concept by testing if the string is found with the set in the Bloom filter table [0025]. Bloom filter module is adapted to create a Bloom filter table corresponding to a set of non-attribute concepts. Bloom filter module can process text strings representing non-attribute concepts through a hash function and enter the result into a Bloom filter table at hash table dataset [0020].)
and providing a query result whether or not the one or more query attribute keys match the one or more attribute keys in the attribute vector stored in the data catalog (Vuong – at operation 350, if the matched attribute value is found to not be a member of the set mapped onto the Bloom filter table, the string may be deemed to not represent a non-attribute concept. Accordingly, the matched attribute value is determined to be an actual attribute value. At operation 360, if the matched attribute is found to possibly be contained in the hash table database, then that matched attribute is deemed to make up part of a non-attribute concept. At operation 370, the matched attribute value that comprises an item attribute is evaluated to identify relevant objects to the user. Relevant objects comprise items that have qualities or attributes specified by the user. At operation 380, search results (i.e. query result) corresponding to keywords and/or attributes are returned to the user [0025].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead and Vuong before them, to modify the system of Zhao and Halstead with the teachings of Vuong as indicated above. One would have been motivated to make such a modification to detect attributes in a search query or other text string and return search results most relevant to the query (Vuong - [0008]).
Claims 8 and 15 correspond to claim 1 and are rejected accordingly.
Regarding claim 4, Zhao teaches:
in the data catalog (Zhao – build engine builds and manages the repository (i.e. data catalog) [Col. 3 line 34].)
stored in the data catalog (Zhao – build engine builds and manages the repository (i.e. data catalog) [Col. 3 line 34].)
Zhao does not appear to teach:
generating a Bloom filter for one or more fact tables based on the one or more attribute keys
storing the Bloom filter at each storage location [in the data catalog] associated with the one or more fact tables; and using the Bloom filter to determine whether the one or more query attribute keys match the one or more attribute keys [stored in the data catalog]
However, Halstead teaches:
generating a Bloom filter for one or more fact tables based on the one or more attribute keys (Halstead – see [0266-0271], where Fig. 9a illustrates the fact that a dataset comprising more than one key attribute can be broken down in several single-key attribute datasets (i.e. attribute tables). Dataset Z (i.e. fact table) is taken as an example, as it contains both name and email key data. From dataset Z, three new datasets can be formed. These new “child” datasets (attribute table) can be used separately. Also see [0277-0278], where a bloom filter can be applied to test whether an element is a member of a set. It consists of a set of positions which can be set to ‘1’ or ‘0’ depending on whether the position is occupied. In the present context, the positions represent identifiers, and each identifier identifies one or more rows of the database.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead and Vuong before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Halstead as indicated above. One would have been motivated to make such a modification to join data from databases and determining the intersection between those datasets (Halstead - [0014-0016]).
Zhao modified by Halstead does not appear to teach:
storing the Bloom filter at each storage location [in the data catalog] associated with the one or more fact tables; and using the Bloom filter to determine whether the one or more query attribute keys match the one or more attribute keys [stored in the data catalog]
However, Vuong teaches:
storing the Bloom filter at each storage location [in the data catalog] associated with the one or more fact tables; and using the Bloom filter to determine whether the one or more query attribute keys match the one or more attribute keys [stored in the data catalog] (Vuong – hash table database comprises a Blook filter table, and comprises a data structure adapted to indicate if selected attribute values cannot be found in one or more knowledge bases, including external knowledge bases. Bloom filter module is adapted to create a Bloom filter table corresponding to a set of non-attribute concepts. Bloom filter module can process text strings representing non-attribute concepts through a hash function and enter the result in a Bloom filter table at hash table database [0016, 0020]. See [0025], where at operation 340 disambiguation module compares a hash of the matched search query string to concepts in hash table database to determine if the matched attribute should be interpreted as an attribute or a non-attribute concept by testing if the string is found with the set in the Bloom filter table (i.e. using the Bloom filter).)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead and Vuong before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Vuong as indicated above. One would have been motivated to make such a modification to detect attributes in a search query or other text string and return search results most relevant to the query (Vuong - [0008]).
Claims 11 and 18 correspond to claim 4 and are rejected accordingly.
Regarding claim 6, Zhao teaches:
generating an alternate fact key for each of the plurality of fact tables based on information associated with each fact table; and in accordance with a determination that a location in the data catalog corresponding to the query fact key is unavailable, storing the one or more attribute keys and the alternate fact key for each fact table at a storage location in the data catalog, wherein the storage location corresponds to the alternate fact key (Zhao – a hypothesis generation module generates a set of hypothetical facts that satisfy the query [Col. 9 lines 1-2]. The hypothesis generation module analyzes the set of corresponding documents to identify a set of terms corresponding to the query [Col. 9 lines 8-10]. The hypothesis generation module identifies a set of common terms related to the query. In response to these results, the hypothesis generation modules creates an object having any real facts from the repository that matches the query, and a set of hypothetical facts (i.e. alternate fact key) based on the attributes from the repository that matches the query and the identified common terms [Col. 9 lines 16-29]. The fact presentation module presents the fact by storing it in the repository. If the object does not already exist (i.e. query fact key being unavailable because the object does not exist), an embodiment of the fact presentation module creates a new object having the true and likely correct facts from the object created by the hypothesis generation module [Co. 10 lines 14-24].)
Claims 13 and 20 correspond to claim 6 and are rejected accordingly.
Regarding claim 7, Zhou teaches:
in the data catalog (Zhao – build engine builds and manages the repository (i.e. data catalog) [Col. 3 line 34].)
Zhao modified by Halstead does not appear to teach:
the attribute vector for the first fact table is stored at a storage location [in the data catalog] based on a number of one or more attributes associated with the first fact table and a capacity of the attribute vector
However, Vuong teaches:
the attribute vector for the first fact table is stored at a storage location [in the data catalog] based on a number of one or more attributes associated with the first fact table and a capacity of the attribute vector (Vuong – hash table database comprises a Blook filter table, and comprises a data structure (i.e. attribute vector) adapted to indicate if selected attribute values cannot be found in one or more knowledge bases, including external knowledge bases. Bloom filter module is adapted to create a Bloom filter table corresponding to a set of non-attribute concepts (i.e. based on a number of one or more attributes). Bloom filter module can process text strings representing non-attribute concepts through a hash function and enter the result in a Bloom filter table at hash table database [0016, 0020]. See [0025], where at operation 340 disambiguation module compares a hash of the matched search query string to concepts in hash table database to determine if the matched attribute should be interpreted as an attribute or a non-attribute concept by testing if the string is found with the set in the Bloom filter table.)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead and Vuong before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Vuong as indicated above. One would have been motivated to make such a modification to detect attributes in a search query or other text string and return search results most relevant to the query (Vuong - [0008]).
Claims 14 corresponds to claim 7 and is rejected accordingly.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of Halstead in view of Vuong further in view of Talagala et al. (Pub. No. US 2016/0203053 A1, hereinafter “Talagala”).
Regarding claim 3, Zhao modified by Halstead does not appear to teach:
providing the query result comprises: in accordance with a determination that attribute keys stored in the data catalog do not match the one or more query attribute keys,
repeatedly shifting [the attribute vector] from a storage location associated with the respective fact key to accommodate inserting the one or more query attribute keys
the attribute vector
However, Vuong teaches:
providing the query result comprises: in accordance with a determination that attribute keys stored in the data catalog do not match the one or more query attribute keys, (Vuong – at operation 350, if the matched attribute value is found to not be a member of the set mapped onto the Bloom filter table, the string may be deemed to not represent a non-attribute concept. Accordingly, the matched attribute value is determined to be an actual attribute value. At operation 360, if the matched attribute is found to possibly be contained in the hash table database, then that matched attribute is deemed to make up part of a non-attribute concept. At operation 370, the matched attribute value that comprises an item attribute is evaluated to identify relevant objects to the user. Relevant objects comprise items that have qualities or attributes specified by the user. At operation 380, search results (i.e. query result) corresponding to keywords and/or attributes are returned to the user [0025].)
the attribute vector (Vuong – at operation 340, disambiguation module compares a hash of the matched search query string to concepts in the hash table database (i.e. attribute vector) to determine if the matched attribute should be interpreted as an attribute or non-attribute concept by testing if the string is found with the set in the Bloom filter table [0025].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead and Vuong before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Vuong as indicated above. One would have been motivated to make such a modification to detect attributes in a search query or other text string and return search results most relevant to the query (Vuong - [0008]).
Zhao modified by Halstead and Vuong does not appear to teach:
repeatedly shifting [the attribute vector] from a storage location associated with the respective fact key to accommodate inserting the one or more query attribute keys
However, Talagala teaches:
repeatedly shifting [the attribute vector] from a storage location associated with the respective fact key to accommodate inserting the one or more query attribute keys (Talagala – Fig. 17 is a flow diagram for managing key-value storage operations. Step 1710 may comprise identifying a conflict, which may comprise a name and/or key conflict pertaining to a stored key-value pair. Step 1720 may comprise resolving the conflict by modifying the logic interface of the stored key-value pair. Modifying the logical interface of the key-value pair may comprise: a) identifying a different, alternative key for the key-value pair; and b) moving (i.e shifting) the data to the alternative key in a range move operation. Step 1720 may further comprise providing access to the stored key-value pair through the alternative key and/or informing one or more storage clients of the change to the key-value pair [0256-0257].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead, Vuong and Talagala before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Talagala as indicated above. One would have been motivated to make such a modification to manage key-value storage operations (Talagala - [0001, 0041]).
Claims 10 and 17 correspond to claim 3 and are rejected accordingly.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of Halstead in view of Vuong further in view of Watkins et al. (Pub. No. US 2018/0322062 A1, hereinafter “Watkins”).
Regarding claim 5, Zhao modified by Halstead and Vuong does not appear to teach:
generating the data catalog based on a cuckoo filter, wherein each cuckoo filter key is a fact key or an alternate fact key associated with the first fact table
However, Watkins teaches:
generating the data catalog based on a cuckoo filter, wherein each cuckoo filter key is a fact key or an alternate fact key associated with the first fact table (Watkins – a cuckoo filter operates as a hash table with displacement hashing, storing a portion of the originating key [0039]. Object records can be arranged with a hash table. Cuckoo hashing can be used to resolve collisions. When cuckoo hashing is used, a direct mapping can be established between a slot in the cuckoo filter and an object record slot within the page [0043].)
Accordingly, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed, having the teachings of Zhao, Halstead, Vuong and Watkins before them, to modify the system of Zhao, Halstead and Vuong with the teachings of Watkins as indicated above. One would have been motivated to make such a modification to test whether an object is present in the page (Watkins - [0037]).
Claims 12 and 19 correspond to claim 5 and are rejected accordingly.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANJIT P DORAISWAMY whose telephone number is (571)270-5759. The examiner can normally be reached Monday-Friday 9:00 AM - 5:00 PM.
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, Sanjiv Shah can be reached at (571) 272-4098. 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.
/RANJIT P DORAISWAMY/ Examiner, Art Unit 2166
/SANJIV SHAH/ Supervisory Patent Examiner, Art Unit 2166