DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is sent in response to Applicant's Communication received on July 28, 2025 for application number 19/281,866. This Office hereby acknowledges receipt of the following and placed of record in file: Specification, Drawings, Abstract, Oath/Declaration, and Claims.
Priority
This application discloses and claims only subject matter disclosed in prior application no 14/632,236, filed February 26, 2015, and names the inventor or at least one joint inventor named in the prior application. Accordingly, this application may constitute a continuation or division. Should applicant desire to claim the benefit of the filing date of the prior application, attention is directed to 35 U.S.C. 120, 37 CFR 1.78, and MPEP § 211 et seq.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/24/2025 is noted. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Richter et al. (US 2024/0028590) (hereinafter Richter) in view of Malfit et al. (US 2022/0005558) (hereinafter Malfit).
Regarding claim 1, Richter teaches a system comprising: at least one hardware processor (see para [0102], discloses processors); one or more communication paths configured to enable communication with one or more clusters of real or virtual computing devices (see Fig. 3, Fig. 5, para [0046], discloses clusters and virtual machines); and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the system to: obtain, for a first cluster of the one or more clusters, a first schema (see Fig. 3, Fig. 5,para [0043, 0049], discloses obtaining a first schema for clusters), wherein the first schema comprises a first protocol for representing, in a second format, information relating to the first cluster (see Fig. 3, Fig. 5, para [0036], discloses data conversion expressions (first protocol) and data query formats (second format)), wherein the information relating to the first cluster is of a first format in accordance with a first application programming interface (API) specification associated with a first API of the first cluster (see Fig. 3, Fig. 5, para [0036], para [0047], discloses first cluster in a first format with API services associated with a API of a first cluster).
Richter does not explicitly teach wherein the first format comprises a cluster-specific API format, wherein the second format comprises a cluster interface-specific format, and wherein the first protocol includes a translation layer for converting data of the cluster-specific API format to data of the cluster interface- specific format; transmit, using the first API via a first communication path of the one or more communication paths, an API request for a dynamic stream of real-time data associated with the first cluster; in response to the API request, receive a first dataset that is of the first format and is associated with the first cluster; based on the first dataset and using the first protocol, generate a second dataset of the second format ; extract, from the second dataset, a first data stream using the first protocol; and transmit the first data stream to a client device.
Malfait teaches wherein the first format comprises a cluster-specific API format (see Fig. 1, para [0054], para [0058], discloses Kubernetes environment). wherein the second format comprises a cluster interface-specific format (see Fig. 1, para [0060], discloses GraphQL API across microservices), and wherein the first protocol includes a translation layer for converting data of the cluster-specific API format to data of the cluster interface- specific format (see Fig. 1, para [0062-0063], discloses transmitting to MDR124 according to defined protocol model and transformation rules); transmit, using the first API via a first communication path of the one or more communication paths, an API request for a dynamic stream of real-time data associated with the first cluster (see para [0061], para [0078], discloses user specified dynamically retrieved attributes from external sources to MDR); in response to the API request, receive a first dataset that is of the first format and is associated with the first cluster (see Fig. 1, para [0058-0060], discloses receiving a cluster from cluster of runtime containers configured with Kubernetes); based on the first dataset and using the first protocol, generate a second dataset of the second format (see Fig. 1, para [0060], generating GraphQL microservices); extract, from the second dataset, a first data stream using the first protocol (see Fig. 1, Fig. 3, para [0070], para [0074], discloses extracting suggestions for schedule study activities); and transmit the first data stream to a client device (see para [0077], discloses returning query results to API consumers).
Richter/Malfait are analogous arts as they are each from the same field of endeavor of database systems.
Before the effective filing date of the invention it would have been obvious to a person of ordinary skill in the art to modify the system of Richter to convert data of the cluster-specific API format to data of the cluster interface- specific format from disclosure of Malfait. The motivation to combine these arts is disclosed by Malfait as “provide specific improvements to the computer-related field of database management that have practical applications” (para [0015]) and converting data of the cluster-specific API format to data of the cluster interface- specific format is well known to persons of ordinary skill in the art, and therefore one of ordinary skill would have good reason to pursue the known options within his or her technical grasp that would lead to anticipated success.
As to claims 8 and 17, the limitations of these claims have been noted in the rejection above. They are therefore rejected as set forth above.
Regarding claims 2, 9 and 18, Richter/Malfait teach a system of claim 1, medium of claim 8 and a method of claim 17.
Richter further teaches wherein the instructions cause the system to: receive, using the first API via the first communication path, an updated API specification associated with the first cluster, wherein the updated API specification includes metadata associated with an update to the first format (see Figs. 4-5, para [0047], para [0052], discloses updates to API and format); and update the first schema based on the updated API specification (see para [0065], discloses updating graph based on user input).
Regarding claims 3, 10, and 19, Richter/Malfait teaches a system of claim 1, medium of claim 8 and a method of claim 17.
Richter further teaches wherein the instructions for updating the first schema based on the updated API specification cause the system to: determine that the updated API specification associated with the first cluster includes database metadata associated with a database extension for the first API (see para [0065], discloses updates based on user input and user query); and update the first schema based on determining that the updated API specification includes the database metadata, wherein the first schema includes a representation of the database metadata in the second format (see para [0065], discloses graph updates).
Regarding claims 4, 11, and 20, Richter/Malfait teaches a system of claim 1, medium of claim 8 and a method of claim 17.
Richter further teaches wherein the instructions cause the system to: receive a cluster addition notification, wherein the cluster addition notification indicates an initiation, of a second cluster of the one or more clusters, and an endpoint for a second API associated with the second cluster (see para [0065], discloses updates to graph data upon detection of change in infrastructure); based on receiving the cluster addition notification, generate a second schema, wherein the second schema comprises a second protocol for representing, in the second format, information of a third format, and wherein the third format comprises a second API specification associated with the second API (see para [0065], discloses updates that reflect user query); and transmit data, based on the second schema, associated with the second cluster to the client device via a network interface (see para [0071], discloses sending package information regarding installation).
Regarding claims 5 and 12, Richter/Malfait teach a system of claim 1 and medium of claim 8.
Richter further teaches data stream cause the system to: determine a data stream mapping based on the first schema for the first cluster (see para [0065], discloses graph generator determining graphs to map resource relationships); and extract the first data stream based on the data stream mapping (see para [0059], discloses extracting data based on relationships and user query).
Regarding claims 6 and 13, Richter/Malfait teach a system of claim 1 and medium of claim 8.
Richter further teaches wherein the instructions for extracting the first data stream cause the system to: determine, based on the first schema, an indication of a field associated with a real- time data stream (see para [0065], discloses multi-dimensional relational graph in real-time); determine, based on the indication of the field, an associated portion of the second dataset (see para [0065], discloses automatic graph updates based on detection of change in infrastructure); and extract the first data stream from the associated portion of the second dataset (see para [0059, 0065], discloses extracting graph detected changed graph data).
Regarding claims 7 and 14, Richter/Malfait teach a system of claim 1 and medium of claim 8.
Richter further teaches wherein the instructions cause the system to: transmit an authentication request to the client device via a network interface (see para [0032], discloses administrative access, user logins); in response to the authentication request, receive device credentials from the client device via the network interface (see para [0032], discloses user logins); based on the device credentials, generate a validation status for the client device (see para [0032], discloses user logins for administrative access); and based on the validation status, determine to transmit the first data stream to the client device via the network interface (see para [0032], discloses user logins and connectivity within a systems infrastructure).
Regarding claim 15, Richter/Malfait teach a medium of claim 8.
Richter further teaches wherein the instructions for generating the first schema cause the system to: determine that the first API specification includes a first watch function, wherein the first watch function comprises a first resource for dynamically tracking events associated with the first cluster (see para [0072], discloses real-time tracking of changes to machine’s platform and list of packages), and wherein the events associated with the first cluster are of the first format (see para [0045], discloses Kubernetes platform format).
Richter does not explicitly teach generate a translation layer for conversion of dynamic streams of real-time data of the first watch function to dynamic streams of real-time data of the second format; and generate the first schema, wherein the first schema comprises the translation layer.
Malfait teaches generate a translation layer for conversion of dynamic streams of real-time data of the first watch function to dynamic streams of real-time data of the second format (see Fig. 1, para [0062-0063], discloses transmitting to MDR124 according to defined protocol model and transformation rules); and generate the first schema, wherein the first schema comprises the translation layer (see Fig. 1, para [0060], generating GraphQL microservices).
Regarding claim 16, Richter/Malfait teach a medium of claim 8.
Richter further teaches wherein the instructions for generating the second dataset cause the system to: determine, based on the first dataset, a first dynamic stream of real-time data from the first watch function ,wherein the first dynamic stream of real-time data is associated with the first format (see para [0045], para [0072], discloses real-time tracking of changes to machine’s platform and list of packages); generate, via the translation layer, a second dynamic stream of real-time data, wherein the second dynamic stream of real-time data is associated with the second format (see para [0050], discloses muliti-dimensional relational graph with real-time updates); and generate the second dataset, wherein the second dataset includes the second dynamic stream of real-time data (see para [0051], para [0065], discloses generating real-time graph data with multi-dimensional views).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Panikkar et al. US Publication No. 2024/0146816.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY HARMON whose telephone number is (571)270-5861. The examiner can normally be reached M-F 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, Ann Lo can be reached at 571-272-9767. 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.
/Courtney Harmon/Primary Examiner, Art Unit 2159
Prosecution Insights