On-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 .
Detailed Action
This is an Office Action for application 17/167,631 in response to arguments and amendments filed on 11/05/2025. Claims 1, 10 and 16 are currently amended. Claims 6, 9 and 11-12 are cancelled. Claims 1-5, 7-8, 10 and 13-20 are pending and examined below.
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 11/05/2025 has been entered.
Response to Arguments
Applicant's arguments filed 11/05/2025 have been fully considered but they are not persuasive.
Applicant argues that newly added claim 1 language
determining that at least one of the one or more reference-type identifiers of the first data matches at least one entity identifier of an existing graph node;
establishing, in response to the determining, a graph edge between the first graph node and the existing graph node of the first data graph based on the one or more reference-type identifiers of the first data; is not taught by currently applied arts Ravid and Zang. Applicant argues that Zang does teach that the establishment of the graph edge is in response to the determination that the reference-type identifiers match an entity identifier of an existing graph node.
However, previously uncited portion of Ravid (Col. 25 [Lines 48-67]) teaches matching ID data with the incoming data structure with ID data (i.e. reference-type identifiers) in the existing data structure (i.e. of an existing graph node). Examiner notes that the graph elements are taught by Zang as previously explained, and when combined, teach all of this new claim language. Therefore, argument is unpersuasive.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-8, 10 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ravid et al. (US Pat. 10,831,509) in view of Zang et al. (US Pat. 11,442,920).
Regarding claim 1, Ravid teaches
A method comprising: identifying, from a plurality of input document streams received from a plurality of data sources, a first document having a first schema comprising first data associated with a first user system and a second document having the first schema comprising second data associated with a second user system, wherein the first data comprises one or more reference-type identifiers; (Fig. 1 #107; Fig. 4 (Col. 6 [Lines 30-2]; Col. 27 [Lines 6-38]) collection unit (#610) correlates incoming data records coming from different sources and streams (i.e. document streams from first and second systems, #106-7) by key of the data record, some of which have same schemas (e.g. #602, 604; #605, 607) and include ID information (i.e. reference-type identifiers))
transforming, by a processing device, the first document from the first schema to a second schema associated with the first user system to generate a first transformed document comprising at least a portion of the first data; (Fig. 4; (Col. 27 Lines 6-38) collection unit correlates incoming data records by key of the data record (i.e. first schema) and merges them into a single data record (i.e. a second schema associated with the first user system) while still retaining some portions of the original (i.e. first) data)
identifying a first graph key associated with the first transformed document; (Col. 21 [Line 57] Col. 21 [Line 14] a single key (i.e. a first graph key) can be associated with different graphs)
determining that at least one of the one or more reference-type identifiers of the first data matches at least one entity identifier of an existing graph node; (Col. 25 [Lines 48-67] ID data is matched with the incoming data structure with ID data (i.e. reference-type identifiers) in the existing data structure (i.e. of an existing node))
transforming the second document from the first schema to a third schema associated with the second user system to generate a second transformed document; (Fig. 4 #630; an incoming data record (e.g. #602, 603 where 602 is first document and 603 is second) is first converted to a second schema (e.g. #620) and then into a third schema (e.g. #630), but still retains traits associated with (i.e. associated with the second user system) of the original second document (e.g. #630a-d)
identifying first updated data resulting from one or more updates to the first data; (Col. 10 [Lines 39] – Col. 11 [Line 26] an act module (#118) acts based on triggers from the detect (i.e. identifying) module (#116))
determining that the first updated data relates to a first field of a first output schema associated with the first user system; (Col. 10 [Lines 39] – Col. 11 [Line 26] an act module (#118) acts based on triggers (e.g. determining that updated data relates to a field) from the detect module (#116))
Ravid does not explicitly teach
matching the first graph key to a graph node key associated with a first graph node of a first data graph associated with the first user system stored in a graph database;
merging the at least the portion of the data of the transformed first document into a first data graph associated with the first user system stored in a graph database
establishing, in response to the determining, a graph edge between the first graph node and the existing graph node of the first data graph based on the one or more reference-type identifiers of the first data;
merging the second transformed document into a second data graph associated with the second user system
generating a first output document comprising the first data and the first updated data from the first data graph in accordance with the first output schema associated with the first user system, the first output schema describing how to compose the first output document;
publishing the first output document to the first user system;
generating a second output document comprising second data from the second data graph in accordance with a second output schema associated with the second user system, the second output schema describing how to compose the second output document;
and publishing the second output document to the second user system.
However, from the same field Zang teaches
matching the first graph key to a graph node key associated with a first graph node of a first data graph associated with the first user system stored in a graph database;
(Col. 5 Lines 1-10 upsert inserts vertices into the graph via key operation (i.e. matching the first graph key to a graph node key))
merging the at least the portion of the data of the transformed first document into a first data graph associated with the first user system stored in a graph database. (Fig. 4 #404; (Col. 2 [Lines 37-42], Col. 7 [Line 54] - Col. 8 [Line 3]) real-time graph database (i.e. containing first and second graphs) is updated based on received events (e.g. receiving merged first and second documents))
establishing, in response to the determining, a graph edge between the first graph node and the existing graph node of the first data graph based on the one or more reference-type identifiers of the first data; (Fig. 4 #404; (Col. 2 [Lines 37-42], Col. 3 [Lines 3-20], Col. 5 [Lines 1-10], Col. 7 [Line 54] - Col. 8 [Line 3]) real-time graph database is updated based on received events, including edges based on the properties and attributes between vertices)
merging the second transformed document into a second data graph associated with the second user system (Fig. 4 #404; (Col. 2 [Lines 37-42], Col. 7 [Line 54] - Col. 8 [Line 3]) real-time graph database (i.e. containing first and second graphs) is updated based on received events (e.g. receiving merged first and second documents)))
generating a first output document comprising the first data and the first updated data from the first data graph in accordance with the first output schema associated with the first user system, the first output schema describing how to compose the first output document;
(Fig. 2; Col. 5 [Line 65] – Col. 6 [Line 9] the API module (#206) contains various APIs, including metadata API (#226) that provides an interface that retrieves and displays (i.e. generates and publishes) metadata of one (i.e. a first output schema) or more graph schemas)
publishing the first output document to the first user system; (Fig. 2; Col. 5 [Line 65] – Col. 6 [Line 9] the API module (#206) contains various APIs, including metadata API (#226) that provides an interface that retrieves and displays (i.e. generates and publishes) metadata of one (i.e. a first output schema) or more graph schemas)
generating a second output document comprising second data from the second data graph in accordance with a second output schema associated with the second user system, the second output schema describing how to compose the second output document; (Fig. 2; Col. 5 [Line 65] – Col. 6 [Line 9] the API module (#206) contains various APIs, including metadata API (#226) that provides an interface that retrieves and displays (i.e. generates and publishes) metadata of one or more (i.e. a first output schema) graph schemas)
and publishing the second output document to the second user system. (Fig. 2; Col. 5 [Line 65] – Col. 6 [Line 5] the API module (#206) contains various APIs, including metadata API (#226) that provides an interface that retrieves and displays (i.e. generates and publishes) metadata of one or more (i.e. a first output schema) graph schemas)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the graph database of Zang into the document transformation system of Ravid. The motivation for this combination would have been to improve the speed of large-scale dataset queries in a real-time environment as explained in Zang (Col. 1 Lines 12-21) .
Regarding claim 2, Ravid and Zang teach claim 1 as shown above, and Ravid further teaches
The method of claim 1, further comprising parsing the first document to identify a graph key portion comprising the first graph key. ((Col. 27 Lines 6-38) data records are correlated based on records associated with the same key)
Regarding claim 3, Ravid and Zang teach claim 2 as shown above, and Zang further teaches
The method of claim 2, further comprising identifying the first graph node in the first data graph comprising a first graph node key matching the first graph key of the first transformed document. ((Col. 4 Lines 55-63, Col. 5 Lines 1-10) graph database is a key-value (e.g. matching graph node with incoming data key) system for matching and storing data in terms of graph structures)
Regarding claim 4, Ravid and Zang teach claim 2 as shown above, and Ravid further teaches
The method of claim 3, further comprising parsing the first document to identify a first data portion comprising one or more data field-value pairs comprising updated data, a second data portion comprising one the or more reference-type identifiers, and third data portion comprising metadata corresponding to a first data source of the first document. ((Col. 1 Line 55- Col. 2 Line 14, Col. 22 Lines 15-45) processing keyed data items includes specifications relating to key, data item and data source for obtaining data (i.e. metadata corresponding to first data source))
Regarding claim 5, Ravid and Zang teach claim 4 as shown above, and Zan
g further teaches
The method of claim 4, further comprising merging the first data portion, second data portion, and third data portion into the first graph node of the first data graph stored in the graph database. (Fig. 4 #404; (Col. 7 Line 54 - Col. 8 Line 14) real-time graph database is updated based on data contained (i.e. Ravid's data portions) in received events)
Regarding claim 7, Ravid and Zang teach claim 1 as shown above, and Zang further teaches
The method of claim 1, further comprising: identifying a label comprised within the metadata of the third data portion; (Fig. 1B #114; (Col. 3 Lines 3-20) graph edges are based on a relationship between nodes (e.g. keys, data items, source, edge metadata, edge properties, etc.))
Ravid further teaches
storing a set of output document specifications, wherein each of the set of output document specifications is associated with a specification label; ((Col. 25 Lines 48-67) collection unit (#610) stores data structure (#617) in memory)
and determining the label matches a first specification label corresponding to a first output document specification of the set of output document specifications. ((Col. 25 Lines 48-67) collection unit matches ID data in data structure (#620) with data structure (#617) for generating enriched data (i.e. output document))
Regarding claim 8, Ravid and Zang teach claim 7 as shown above, and Ravid further teaches
The method of claim 7, further comprising: identifying the first output schema associated with the first output document specification; ((Col. 25 Lines 48-67) collection unit matches ID data in data structure (#620) with data structure (#617) for generating enriched data (i.e. output document))
Regarding claim 10, see at least the rejection for claim 1. Ravid further teaches
A system comprising: a memory to store instructions (Fig. 11 #1106); and a processing device (Fig. 11 #1104), operatively coupled to the memory, to execute the instructions to perform operations
Regarding claim 13, Ravid and Zang teach claim 10 as shown above, and Zang further teaches
The system of claim 10, the operations further comprising identifying a second graph node of the first data graph associated with the user system, wherein the second graph node comprises a second label and second data in a second data field. (Fig. 4 #404; (Col. 7 Line 54 - Col. 8 Line 3) real-time graph database contains nodes which are updated (i.e. identified))
Regarding claim 14, Ravid and Zang teach claim 13 as shown above, and Ravid further teaches
The system of claim 13, the operations further comprising: determining a second output specification associated with the first user system does not include a specification label that matches the second label of the second graph node; (Fig. 4 #623, #630; (Col. 26 Lines 1-17) all non-Boston (i.e. does not include matching specification label) records (e.g. #623) are filtered out of the correlated, enriched, filtered data (#630))
and suppressing generation of an output document corresponding to the second graph node. (Fig. 4 #623, #630; (Col. 26 Lines 1-17) all non-Boston records (e.g. #623) are filtered out (i.e. suppressed) of the correlated, enriched, filtered data (#630))
Regarding claim 15, Ravid and Zang teach claim 13 as shown above, and Ravid further teaches
The system of claim 13, the operations further comprising: determining a second output specification associated with the first user system comprises a second specification label that matches the second label of the second graph node; ((Col. 26 Lines 1-17) any number of a parameter names (i.e. second specification labels) can be used for correlated aggregation)
identifying a second output schema associated with the second output specification; ((Col. 26 Lines 1-17) in a variation, correlated records 602 and 603 are merged into a single record (i.e. second output schema))
determining the second output schema does not comprise the second data field associated with the second data; (Fig. 4 #623, #630; (Col. 26 Lines 1-17) all non-matching records are filtered out of the correlated, enriched, filtered data (#630))
and suppressing generation of an output document corresponding to the second graph node. (Fig. 4 #623, #630; (Col. 26 Lines 1-17) all non-matching records are filtered out (i.e. suppressed) of the correlated, enriched, filtered data (#630))
Regarding claim 16, see the rejection for claim 10.
Regarding claim 17, see the rejection for claim 2.
Regarding claim 18, see the rejection for claim 3.
Regarding claim 19, see the rejection for claim 4.
Regarding claim 20, see the rejection for claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to J MITCHELL CURRAN whose telephone number is (469)295-9081. The examiner can normally be reached M-F 8:00am - 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, Sherief Badawi can be reached at (571) 272-9782. 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.
/J MITCHELL CURRAN/Examiner, Art Unit 2169
/YU ZHAO/Primary Examiner, Art Unit 2169