DETAILED ACTION
This Office action is responsive to the following communication: Amendment filed on 14 April 2026.
Claim(s) 1-20 is/are pending and present for examination. Claim(s) 1, 10, and 15 is/are in independent form.
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 .
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.
Claim(s) 1, 2, 6, 8-10, 12, 14, 15, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wu et al, USPGPUB No. 2013/0318070, filed on 22 May 2012, and published on 28 November 2013, in view of Gutierrez et al, USPGPUB No. 2023/0252233, filed on 20 April 2023, claiming priority to 21 May 2021, and published on 10 August 2023.
As per independent claims 1 and 10, Wu, in combination with Gutierrez, discloses:
A data sharing method, comprising:
receiving, by a first data management system, a first query statement that is a query statement based on a first query language {See Wu, [0039], wherein this reads over “As shown, protocol 1B00 commences when an instance of an enterprise application 1A10 (e.g., enterprise application 1A10.sub.1) forms a native query such as a non-SPARQL query (see message 1B02), and passes the native query to the SPARQL gateway (see message 1B04)”};
obtaining, by the first data management system and based on the first query statement, a second query statement by using a software development kit of a second data management system, wherein the second query statement is a query statement based on a second query language {See Wu, [0039], wherein this reads over “The SPARQL gateway 1A70 receives the non-SPARQL query (see operation 1B06) and proceeds to perform a conversion on the received query (see operation 1B08). Having completing converting the non-SPARQL query into a SPARQL query, the SPARQL gateway submits the SPARQ query to a SPARQL endpoint 1A30 (see message 1B10), and the SPARQL endpoint 1A30 proceeds to process the submitted SPARQL query (see operation 1B12)”}; and
accessing, by the first data management system and based on the second query statement, a unified open access service of the second data management system to read logical metadata of the second data management system and to obtain proprietary-format data in the second data management system {See Gutierrez, [0334], wherein this reads over “To do so, a Standard SDK may query for and read SKL Schemas from, for example, an SDKS. A Standard SDK may use SKQL as a convenient way to query for Schemas from a user's SKDS using its simplified ORM style interface. Alternatively, a Standard SDK may not use SKQL and instead submit queries in the native query language of the user's SKDS.”; [0335], wherein this reads over “Alternatively, as illustrated by SKL framework 1300, the developer may use a Standard SDK 1350, which has a standardized set of functions that facilitate interactions with a variety of Integration APIs and then use certain Schemas to determine exactly how to interact with a given Integration API 1320 in order to perform a certain operation, as represented by Verb 1301”; and [0337], wherein this reads over “In this embodiment, the Schemas 1418 included in the application's codebase 1416 may represent data and capabilities 1412 according to the application's needs (e.g., the application might need a data type for a person, and it may therefore define the Schema for a person and include whatever fields are needed, or it could use a copy of a commonly used data model for a person such as FOAF:person)”; and [0347], wherein this reads over “Eighth, the Standard SDK may assert the validity of the outputs according to the Verb's configuration.”}.
Wu fails disclose the claimed feature of “accessing, by the first data management system and based on the second query statement, a unified open access service of the second data management system to read logical metadata of the second data management system and to obtain proprietary-format data in the second data management system.” Gutierrez is directed to the invention of a system for shared language framework utilizing a standard SDK for simplifying application building. Specifically, Gutierrez discloses that “a Standard SDK may query for and read SKL Schemas from, for example, an SDKS” wherein “[the] Standard SDK may use SKQL as a convenient way to query for Schemas from a user's SKDS using its simplified ORM style interface.” See Gutierrez, [0334]. Additionally, Gutierrez discloses that “the developer may use a Standard SDK 1350, which has a standardized set of functions that facilitate interactions with a variety of Integration APIs and then use certain Schemas to determine exactly how to interact with a given Integration API 1320 in order to perform a certain operation, as represented by Verb 1301.” See Gutierrez, [0335]. Under the broadest reasonable interpretation, the querying and reading of schemas, as disclosed by Gutierrez, would read upon the claimed feature of “accessing… a unified open access service… to read logical metadata.” Gutierrez further discloses that “the Schemas 1418 included in the application's codebase 1416 may represent data and capabilities 1412 according to the application's needs (e.g., the application might need a data type for a person, and it may therefore define the Schema for a person and include whatever fields are needed, or it could use a copy of a commonly used data model for a person such as FOAF:person).” See Gutierrez, [0337]. Under the broadest reasonable interpretation, the “schema” disclosed by Gutierrez would read upon the claimed feature of “logical metadata” which may be read. Lastly, as per the claimed feature of “obtain proprietary-format data in the second data management system,” Gutierrez discloses that “the Standard SDK may assert the validity of the outputs according to the Verb's configuration.” See Gutierrez, [0347]. It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the instant application to improve the prior art of Wu with that of Gutierrez such that the SPARQL query of Wu may be further utilized in conjunction with the SDK system of Gutierrez to read logical metadata (such as schemas) to obtain proprietary-format data (such as mapped SDK query data). One of ordinary skill in the art would have been motivated to make the aforementioned combination such that developers may more easily build queries for data retrieval.
As per dependent claim 2, Wu, in combination with Gutierrez, discloses:
The method according to claim 1, wherein the logical metadata is read by using a metadata interface in the unified open access service {See Wu, [0032], wherein this reads over “Processing within the SPARQL gateway (including processing within the web service engine 1A62) allows applications to consume semantic data in formats other than the specific XML defined for any particular SPARQL response.”}; and
wherein reading the logical metadata using the metadata interface comprises:
reading the proprietary-format data in the second data management system based on the logical metadata {See Wu, [0035], wherein this reads over “As can be understood, the SPARQL gateway receives a SPARQL response from a SPARQL endpoint, and proceeds to process the SPARQL response into a format native to the database engine, or at least in such a format that the database engine can use the semantic data retrieved from the SPARQL endpoint”}.
As per dependent claims 6 and 12, Wu, in combination with Gutierrez, discloses:
The method according to claim 1, further comprising:
presenting, by the first data management system, a sharing operation interface to a user {See Wu, Figure 4}, wherein the sharing operation interface supports an operation of sharing data within a system, an operation of sharing open-format data with an external system, and an operation of accessing proprietary-format data by an external system {See Wu, [0070], wherein this reads over “As shown, a SPARQL query extractor engine can extract information from an RDF dataset. In the specific example shown, the RDF dataset describes a set of mutual funds. The extracted information includes series name, mutual fund ticker, state, address, etc. The extracted information from the SPARQL query response is presented in a tabular form 410, presented below the query.”}; and
when based on the operation of accessing the proprietary-format data by the external system being triggered, returning, by the first data management system, proprietary-format data in the first data management system {See Wu, [0039], wherein this reads over “Having processed the SPARQL query, the SPARQL endpoint 1A30 sends the results as a SPARQL response (see message 1B16). The SPARQL response is received by the SPARQL gateway (see operation 1B18) and commences to apply a transform to the SPARQL response (see operation 1B20). The protocol as shown concludes upon sending the transformed SPARQL query results to the application, thus ending the shown protocol phase when the transformed results are passed to the enterprise application (see message 1B22)”}.
As per dependent claims 8, 14, and 20, Wu, in combination with Gutierrez, discloses:
The method according to claim 1, wherein the first data management system and the second data management system are different data management systems among a database, a data warehouse, a lakehouse or a big data engine, and an artificial intelligence development platform {See Wu, Figure 1A}.
As per dependent claims 9 and 18, Wu, in combination with Gutierrez, discloses:
The method according to claim 2, wherein the reading the proprietary-format data in the second data management system based on the logical metadata comprises:
accessing, in an abstract table format, the proprietary-format data in the second data management system based on the logical metadata {See Wu, [0035], wherein this reads over “As can be understood, the SPARQL gateway receives a SPARQL response from a SPARQL endpoint, and proceeds to process the SPARQL response into a format native to the database engine, or at least in such a format that the database engine can use the semantic data retrieved from the SPARQL endpoint”}.
As per independent claims 15, Wu, in combination with Gutierrez, discloses:
A second data management system comprising at least one processor and a memory, wherein the memory is configured to store instructions and a software development kit, and the at least one processor is configured to execute the instructions in the memory to cause the second data management system to:
receive a second query statement from a first data management system {See Wu, [0039], wherein this reads over “The SPARQL gateway 1A70 receives the non-SPARQL query (see operation 1B06) and proceeds to perform a conversion on the received query (see operation 1B08). Having completing converting the non-SPARQL query into a SPARQL query, the SPARQL gateway submits the SPARQ query to a SPARQL endpoint 1A30 (see message 1B10), and the SPARQL endpoint 1A30 proceeds to process the submitted SPARQL query (see operation 1B12)”},
wherein the first data management system obtains the second query statement by using the software development kit of the second data management system {See Gutierrez, [0334], wherein this reads over “According to one decentralized embodiment of SKL, wherein an application does not need to have preexisting knowledge of what Schemas (e.g., Noun, Verb, and Mappings) a user has installed, Standard SDKs may dynamically respond to a developer's execution of a standard Verb. To do so, a Standard SDK may query for and read SKL Schemas from, for example, an SDKS. A Standard SDK may use SKQL as a convenient way to query for Schemas from a user's SKDS using its simplified ORM style interface. Alternatively, a Standard SDK may not use SKQL and instead submit queries in the native query language of the user's SKDS.”};
read, by a unified open access service of second data management system and based on the second query statement, logical metadata by using a metadata interface in the unified open access service {See Gutierrez, [0337], wherein this reads over “In this embodiment, the Schemas 1418 included in the application's codebase 1416 may represent data and capabilities 1412 according to the application's needs (e.g., the application might need a data type for a person, and it may therefore define the Schema for a person and include whatever fields are needed, or it could use a copy of a commonly used data model for a person such as FOAF:person)”; and [0347], wherein this reads over “Eighth, the Standard SDK may assert the validity of the outputs according to the Verb's configuration.”}; and
read, by a unified open access service, proprietary-format data in the second data management system based on the logical metadata {See Gutierrez, [0337], wherein this reads over “In this embodiment, the Schemas 1418 included in the application's codebase 1416 may represent data and capabilities 1412 according to the application's needs (e.g., the application might need a data type for a person, and it may therefore define the Schema for a person and include whatever fields are needed, or it could use a copy of a commonly used data model for a person such as FOAF:person)”; and [0347], wherein this reads over “Eighth, the Standard SDK may assert the validity of the outputs according to the Verb's configuration.”}.
Claim(s) 5, 7, 11, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wu, in view of Official Notice.
As per dependent claims 5 and 11, it is noted that Wu discloses that a query may be a SQL query, which would read upon the claimed feature of “wherein the first query language is a structured query language.” See Wu, [0026]. As per the claimed feature of “the second query language is a lightweight markup language,” the Examiner takes Official Notice that the feature of a lightweight markup language is widely-known in the art, as it is merely any markup system with simple, unobtrusive syntax. It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the instant application to improve the prior art of Wu with the aforementioned lightweight markup language such that the SQL query may be converted to another markup language. One of ordinary skill in the art would have been motivated to make the aforementioned combination such that the SQL may be more readable in its raw format as well as the rendered output.
As per dependent claims 7, 13, and 19, the Examiner takes Official Notice that the feature of columnstore unit data is widely-known within the art, as it is merely a database storage format that organizes data by column instead of by row. It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the instant application to improve the prior art of Wu with the aforementioned columnstore feature such that the stored data of Wu may be further formatted into columnstore unit data. One of ordinary skill in the art would have been motivated to make the aforementioned combination such that data compression and faster query performance may be provided.
Allowable Subject Matter
Claims 3, 4, 16, and 17 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s arguments with respect to claim rejections under 35 U.S.C. 102 have been considered but are moot in view of the newly cited rejections under 35 U.S.C. 103 made in response to Applicant’s Amendment.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL KIM whose telephone number is (571)272-2737. The examiner can normally be reached Monday-Friday, 9AM-5PM.
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.
/Paul Kim/
Primary Examiner
Art Unit 2166
/PK/
Prosecution Insights