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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-11, 14, 16-18, and 20-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 18, and 20 contain amended subject matter stating:
“sending the log query result to the log request device via a network, so as to integrate the log query result and the engine log to obtain an integrated log by the log request device, wherein in response to the log request device being the data engine, the log request device accesses a local memory through the request identification information to obtain the engine log, in response to the log request device being other devices except the metadata server or the data engine, the log request device remotely accesses the data engine via a network to obtain the engine log,”
It is noted that the element “a network” is introduced twice. It is unclear whether the same network is being used each time or a different network is being used the second time.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-2, 4-11, 14, and 16-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 18, and 20 contain the amended limitation “sending the log query result to the log request device via a network, so as to integrate the log query result and the engine log to obtain an integrated log by the log request device, wherein in response to the log request device being the data engine, the log request device accesses a local memory through the request identification information to obtain the engine log, in response to the log request device being other devices except the metadata server or the data engine, the log request device remotely accesses the data engine via a network to obtain the engine log,”
Applicant’s remarks dated 31 Decent 2025 indicate that support for the amendments can be found in paragraphs [0198], [0209]-[0211], [0222], and Figure 2.
Examiner has reviewed these paragraphs and cannot find reference to the claimed element of “in response to the log request device being the data engine, the log request device accesses a local memory through the request identification information to obtain the engine log.”
Specifically, in the cited paragraph, there does not appear to be an analysis step that determines whether “the log request device [is] the data engine” or “the log request device being other devices except the metadata server or the data engine,” and, in response to a result of this determination, performing different actions.
Paragraph [0198] does discuss how “in some application scenarios, the log request device may refer to a data engine that can perform data communication with the foregoing metadata server. For another example, in some application scenarios, the log request device may refer to another device other than the metadata server and the data engine, and the other device can obtain some log content from the metadata server and the data engine.” Thus, there is support for “the log request device being a data engine or another device except the data server and the data engine.”
However, paragraph [0198] does not discuss any idea of checking whether the log request device is the data engine or another device except the data server and the data engine and responding differently depending on the check.
It is additionally noted that Examiner can find no support for the idea of “the log request device accesses a local memory through the request identification information to obtain the engine log.”
“Local memory” is not referred to in the specification, nor is there any discussion of accessing memory – local or not – “through the request identification information.”
In view of the above findings, it does not appear as if the specification as originally filed has support for this amendment.
Examiner also requests that Applicant identify the support in the originally filed specification for the amended limitation of “accessing the log record stored in the memory of the metadata server by using the second request identification information, and directly reading the log corresponding to the request processing logic carrying the first request identification information from the memory as a log query result corresponding to the log query request.”
Examiner searched for the concept of directly reading a log from memory as a log query result corresponding to a log query request, but could not find any discussion of “directly” reading a log from memory as claimed and as characterized as distinctive over the art of record in the remarks filed 31 December 2025.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-8, 14, 16-18, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Chan et al. (US Pre-Grant Publication 2022/0179730), in view of Bindal et al. (US Pre-Grant Publication 2024/0004898), further in view of Bigdelu et al. (US Pre-Grant Publication 2024/0143612), in view of Brahmadesam et al. (US Patent 11,455,290).
As to claim 1, Chan teaches a method of generating a lakehouse metadata service log, wherein the method is applied to a metadata server … and the method comprises:
receiving a data processing request sent by a data engine (see Chan paragraph [0029]. Chan receives multiple data processing requests including history logs and new logs);
in response to the data processing request carrying request identification information, determining first request identification information based on the request identification information carried in the data processing request, wherein the first request identification information is used for identifying the data processing request (see Chan paragraphs [0029]-[0030] and Figures 3-5. Each of the requests include request identification information); and
when the data engine provides a log identifier and generates a request tracking identifier for the data processing request, the request identification information comprises the log identifier and the request tracking identifier (see Chan paragraphs [0029]-[0030] and Figures 3-5. It is noted that requests received include multiple types of data that are translated into fields. These types of data may include Job_ID and Message_ID. However, as noted in Figure 5, some jobs may have both identifiers);
when the data engine does not provide a log identifier and generates a request tracking identifier for the data processing request, the request identification information comprises the request tracking identifier (see paragraphs [0029]-[0030] and Figures 3-5. Some of the requests only include a “Job ID,” or request tracking identifier),
an engine log generated by the data engine for the data processing request carries the first request identification information (see paragraphs [0029]-[0030]. The data engine may generate history and new logs that contain log data that contain data such as the job IDs and message IDs. This data is queried to from the structured log and log sequences. It is noted that both JOB_ID and Message_ID may be relied upon, or queried, to perform this generation); and
…
Chan does not explicitly show:
… the metadata server is used to perform data management on metadata in a data lakehouse …
executing request processing logic corresponding to the data processing request and generating an execution log corresponding to the request processing logic, and
generating a log corresponding to the request processing logic carrying the first request identification information based on the execution log and the first request identification information, and
storing the log corresponding to the request processing logic into a log record of a memory of the metadata server,
wherein the execution log refers to a log generated when the request processing logic is executed, and
the log corresponding to the request processing logic comprises the execution log, and
the method further comprises:
in response to a query operation on a log related to the data processing request:
receiving a log query request sent by a log request device;
in response to the log query request carrying the request identification information corresponding to the data processing request,
taking the request identification information carried by the log query request as a second request identification information, wherein the first request identification information and the second request identification information are the same, the request identification information comprises at least one of the log identifier and the request tracking identifier;
accessing the log record stored in the memory of the metadata server by using the second request identification information, and
directly reading the log corresponding to the request processing logic carrying the first request identification information from the memory as a log query result corresponding to the log query request,
sending the log query result to the log request device via a network, so as to integrate the log query result and the engine log to obtain an integrated log by the log request device, wherein in response to the log request device being the data engine, the log request device accesses a local memory through the request identification information to obtain the engine log, in response to the log request device being other devices except the metadata server or the data engine, the log request device remotely accesses the data engine via a network to obtain the engine log,
the integrated log is used for obtaining a process executed by the data engine and the metadata server for the data processing.
Bindal teaches:
… the metadata server is used to perform data management on metadata in a data lakehouse … (see paragraphs [0012]-[0014]. Bindal teaches wherein data, including logs, may be managed in a data lakehouse);
…
wherein in response to the log request device being the data engine, the log request device accesses a local memory through the request identification information to obtain the engine log (see Bindal paragraph [0047]. Bindal shows wherein transaction logs may be local to a computing device or remote to a computing device).
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Chan by the teachings of Bindal because both references are directed towards managing logs. Bindal simply offers a user of Chan the ability to manage logs in an additional context, such as a data lakehouse, which will improve the user’s ability to manage computing in Chan.
It is noted that the “lakehouse” is only recited in as an intended use of “data management.” No functions, features, or properties specific to the lakehouse as a lakehouse are claimed in the body of the claim.
Bigdelu teaches executing request processing logic corresponding to the data processing request and generating an execution log corresponding to the request processing logic (see Bigdelu paragraphs [0137]-[0138]. The system generates server access logs that records requests from executing processing logic. These are execution logs), and
generating a log corresponding to the request processing logic carrying the first request identification information based on the execution log and the first request identification information, storing the log corresponding to the request processing logic into a log record of a memory of the metadata server, wherein the execution log refers to a log generated when the request processing logic is executed (see Bigdelu paragraphs [0137]-[0138]. The system creates a table based on the execution log and information about the requests. It is noted that each execution log refers to logs that are generated when the processing logic is executed. As noted in paragraphs [0057]-[0058], host devices may include memory that stores logs including metadata. Paragraph [0054] indicates that host devices may be servers), and
the log corresponding to the request processing logic comprises the execution log (see Bigdelu paragraphs [0137]-[0138]. The table comprises the execution logs), and
It would have been obvious to one of ordinary skill in the art before the earliest filing date of the invention to have modified Chan by the teachings of Bigdelu because both references are directed towards managing logs. Bigdelu simply offers a user of Chan the ability to for users to gain insights from log data, which will increase the utility of logging requests for a user.
Brahmadesam teaches:
the method further comprises:
in response to a query operation on a log related to the data processing request:
receiving a log query request sent by a log request device (see Brahmadesam 16:11-57. A user may query change and transaction log tables by identifying transactions or ranges of time);
in response to the log query request carrying the request identification information corresponding to the data processing request,
taking the request identification information carried by the log query request as a second request identification information, wherein the first request identification information and the second request identification information are the same, the request identification information comprises at least one of the log identifier and the request tracking identifier (see Brahmadesam 16:11-57. A user may query change and transaction log tables by identifying transactions or ranges of time. The query value is determined to match other values in the log);
accessing the log record stored in the memory of the metadata server by using the second request identification information, and directly reading the log corresponding to the request processing logic carrying the first request identification information from the memory as a log query result corresponding to the log query request (see Brahmadesam 16:11-57. Results may be returned to the user based on results present both transaction logs and change log tables. It is noted that the logs may be directly accessed in Brahmadesam),
sending the log query result to the log request device via a network, so as to integrate the log query result and the engine log to obtain an integrated log by the log request device, … , in response to the log request device being other devices except the metadata server or the data engine, the log request device remotely accesses the data engine via a network to obtain the engine log (see Brahmadesam 16:11-57. Results may be returned to the user based on results present both transaction logs and change log tables),
the integrated log is used for obtaining a process executed by the data engine and the metadata server for the data processing (see Brahmadesam 16:11-57).
It would have been obvious to one of ordinary skill in the art before earliest filing date of the invention to have modified Chan in view of Brahmadesam because both references are directed towards managing transactions, and because Brahmadesam provides to Chan the ability search transactions. This will give a user or manager of Chan the ability to identify and request information about transactions as they desire, increasing the usability of Chan in understand transaction history.
As to claim 4, Chan as modified teaches the method according to claim 1, wherein the request identification information is located in a preset field in the data processing request (see Chan paragraphs [0029]-[0030] and Figures 3-5); and/or
the request identification information is written by an SDK in the data engine into the preset field in the data processing request.
As to claim 5, Chan as modified teaches the method according to claim 1, further comprising:
In response to the data processing request not carrying the request identification information, determining the first request identification information based on at least one piece of request parameter information of the data processing request, wherein the at least one piece of request parameter information comprises at least one of engine description information of the data engine and interface description information corresponding to the data processing request (see Chan paragraphs [0029]-[0030] and Figures 3-5).
As to claim 6, Chan as modified teaches the method according to claim 5, wherein the first request identification information comprises at least one of the at least one piece of request parameter information and a request tracking identifier generated by the metadata server for the data processing request (see Chan paragraphs [0029]-[0030] and Figures 3-5); and/or
the in response to the data processing request not carrying the request identification information, determining the first request identification information based on at least one piece of request parameter information of the data processing request, comprises:
when the data engine does not provide a log identifier and does not generate a request tracking identifier for the data processing request, determining the first request identification information based on the at least one piece of request parameter information of the data processing request.
As to claim 7, Chan as modified teaches the method according to claim 5, wherein the engine description information comprises at least one of an engine identifier of the data engine and a user identifier of the data engine (see Chan paragraphs [0029]-[0030] and Figures 3-5); and/or
the interface description information comprises at least one of an interface identifier corresponding to the data processing request and an interface parameter corresponding to the data processing request.
As to claim 8, Chan as modified teaches the method according to claim 1, wherein the metadata server is a metadata service system (see Chan paragraphs [0029]-[0030] and Figures 3-5).
As to claim 14, Chan as modified by Brahmadesam teaches the method according to claim 1, further comprising:
When the log query request does not carry the request identification information corresponding to the data processing request and the log query request carries a log query time range and at least one piece of request parameter information of the data processing request (see Brahmadesam 16:11-57. The request may include a time range),
generating the second request identification information based on the at least one piece of request parameter information carried in the log query request (see Brahmadesam 16:11-57); or
determining the second request identification information from the log record of the metadata server based on the log query time range and the at least one piece of request parameter information carried in the log query request, wherein the at least one piece of request parameter information comprises at least one of engine description information of the data engine and interface description information corresponding to the data processing request (see Brahmadesam 16:11-57); and
determining the log query result corresponding to the log query request based on a log that exists in the log record of the metadata server, that meets the log query time range (see Brahmadesam 16:11-57), and
that carries the first request identification information (see Brahmadesam 16:11-57).
As to claim 16, Chan as modified by Brahmadesam teaches the method according to claim 1, wherein when the log query request carries the request identification information corresponding to the data processing request, the log recorded in the data engine for the data processing request is a log carrying the request identification information and existing in a log record of the data engine (see Brahmadesam 16:11-57).
As to claim 17, Chan as modified teaches the method according to claim 1, wherein the log request device is the data engine (see Brahmadesam 16:11-57 for searching a log. See Chan paragraphs [0003] and [0037] for how the data engine may search itself).
As to claims 18 and 20, see the rejection of claim 1, along with Chan paragraphs [0021] and [0076] for the processor, memory, and computer readable medium.
As to claim 21, Chan as modified teaches method according to claim 1, wherein the request tracking identifier is used for uniquely identifying the data processing request (see paragraphs [0029]-[0030] and [0036]. Job_IDs identify particular jobs. It is noted that job entities comprise multiple messages, which are also identified with unique identifiers); and/or
the request tracking identifier is generated by an SDK in the data engine.
Response to Arguments
Applicant's arguments filed 4 August 2025 have been fully considered but they are not persuasive.
35 USC 103 Response to Rejections
Applicant argues that “the query method in Brahmadesam is totally different from that of the present invention.”
Applicant then summarizes Brahmadesam and argues that “Brahmadesam does NOT use the transaction or range of time as the second request identification information to access the CHANGE LOG TABLE and directly read the log carrying such transaction or range of time. Moreover, the objective of Brahmadesam is to narrow the query scope and avoid filtering directly from the full change log table.”
Applicant concludes, arguing that “thus, Brahmadesam fails to disclose the feature “in response to the log query request carrying the request identification information corresponding to the data processing request, taking the request identification information carried by the log query request as a second request identification information, wherein the first request identification information and the second request identification information are the same, the request identification information comprises at least one of the log identifier and the request tracking identifier; accessing the log record stored in the memory of the metadata server by using the second request identification information, and directly reading the log corresponding to the request processing logic carrying the first request identification information from the memory as a log query result corresponding to the log query request.”
In response to this argument, it is noted that Brahmadesam explicitly discloses how the change log tables are queried directly to identify relevant records (see 16:11-32). These change log tables are stored in the memory of the various servers. Thus, they are directly accessed from memory corresponding to a request. By showing that change log tables may be queried directly according to a variety of parameters, Brahmadesam teaches the claimed subject matter.
Applicant continues, arguing that Brahmadesam “fails to disclose or suggest the log request device as recited in amended claim 1.”
Applicant elaborates, arguing that “Brahmadesam relies on the streaming storage server itself to collate the data – it does not disclose that the client accesses the local memory or remotely accesses other devices via request parameters (e.g., transaction or range of time) to obtain part of the query result, and then collates the data by itself. Thus, Brahmadesam fails to disclose the log request device of the amended claim 1, let alone the process of obtaining the integrated log via the log request device.”
In response to this argument, it is noted that Brahmadesam does disclose when a client may make a request from a server and receive results from the server (see 16:11-32 and 14:1-12). Thus, Brahmadesam does show the idea of sending a query result to a requesting device via a network wherein the requesting device may remotely access a data engine via a network to obtain any desired engine logs.
It is noted that Bindal, paragraph [0047], teaches wherein transaction logs may be local to a computing device or remote to a computing device. Thus, Bindal suggests that a client may perform accessing of transaction logs via local memory and any subsequent processing activities in a local device.
The combination of references teaches the subject matter as claimed.
Applicant argues that Brahmadesam fails to disclosure the data engine and other devices as recited in the amended claim 1, nor does it disclose the process of obtaining the engine log [in the amended subject matter].”
In response to this argument, it is noted that the combination of cited art teaches the limitations as claimed for the reasons set forth in the rejection above.
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 CHARLES D ADAMS whose telephone number is (571)272-3938. The examiner can normally be reached M-F, 9-5:30 EST.
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, Aleksandr Kerzhner can be reached at 5712701760. 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.
/CHARLES D ADAMS/Primary Examiner, Art Unit 2165
Prosecution Insights