DETAILED ACTION
Claim 1-20 are pending in the application and claims 1-20 are rejected.
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 .
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0021], Line 1: “registry 206” must have been --registry 204--
Appropriate correction is required.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1, line 9, “the ingested definition” lacks proper antecedent basis.
Claim 11, line 1, “the one or more sub-fields” lacks proper antecedent basis.
Claim 12, line 1, “the one or more sub-fields” lacks proper antecedent basis.
Claim 13, line 11, “the ingested definition” lacks proper antecedent basis.
Claim 19, lines 4 and 6, “the counter message” lacks proper antecedent basis.
Claims 2-10, 14-18, and 20 depend on the objected claims and inherit the same issues.
Appropriate correction is required.
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 4 and 8-12 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.
Regarding claim 4, lines 3-4, “the counter data record type” is unclear whether it refers to “the counter data record type” in line 9 of claim 1 or “a counter data record type” in line 2 of claim 4. For the examination purposes, “the counter data record type” in lines 3-4 of claim 4 will be treated as -- the counter data record type in the metadata file--.
Regarding claim 8, lines 4-5, “counter data records corresponding to the counter data record type” is unclear how it differs from “one or more counter data record corresponding to the one or more counter data record types” in lines 6-7 of claim 1. For the examination purposes, “counter data records corresponding to the counter data record type” in lines 4-5 of claim 8 will be treated as -- the counter data record corresponding to the counter data record type --.
Regarding claim 10, “a value field” in line 3 and “a list of sub-fields” in lines 3-4 are unclear how they differ from “a value field” and “a list of sub-fields” in line 4 of claim 8. For the examination, “a value field” in line 3 and “a list of sub-fields” in lines 3-4 of claim 10 will be treated as --the value field-- and –the list of sub-fields--.
Regarding claims 9, 11, and 12, they depend on the rejected claim 8 and inherit the same issue.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed toward an abstract idea without significantly more.
Regarding claims 1 and 13:
Step 1:
Claims 1-12 and 19-20 are directed toward a process, and claims 13-18 are direct toward a machine. Therefore, they fall into statutory categories.
Step 2A, Prong 1:
Claim 1 recites:
ingesting definitions of one or more counter data record types used by the application image
receiving, from the FPGA, a counter message that includes one or more counter data records corresponding to the one or more counter data record types;
retrieving the ingested definition of the counter data record type corresponding to the counter data record
and parsing the counter data record using the ingested definition
Steps (a), (b), (c), and (d) are mental processes that can be performed in the human mind or by a human using pen and paper.
Claim 13 recites:
ingest definitions of one or more counter data record types used by the application image
receive, from the FPGA, a counter message that includes one or more counter data records corresponding to the one or more counter data record types
retrieve the ingested definition of the counter data record type corresponding to the counter data record
and parse the counter data record using the ingested definition
Steps (a), (b), (c), and (d) are mental processes that can be performed in the human mind or by a human using pen and paper.
Claim 19 recites:
receiving a counter message output by a field-programmable gate array (FPGA) of a network device, wherein the FPGA is programmed with an application image, and wherein the counter message includes one or more counter data records corresponding to one or more counter data record types used by the application image
retrieving metadata for a counter data record type corresponding to the counter data record
and parsing the counter data record using the retrieved metadata
Steps (a), (b), and (c) are mental processes that can be performed in the human mind or by a human using pen and paper.
Step 2A, Prong 2:
Claims 1 and 9 recite the additional elements “application image”, “FPGA”, “counter data record”. Claim 19 recites the additional elements “field-programmable gate array (FPGA)”, “network device”, “application image”, “counter data record”, “counter data record type”. However, the additional elements are recited at a high level of generality. Therefore, the claims as a whole do not integrate the judicial exception into a practical application.
Step 2B:
The additional elements, considering them both individually and in combination,
do not amount to significantly more than the judicial exception itself.
Regarding claim 2, the claim recites: storing a result of the parsing in a database of the network device. The limitation “storing a result” is a function that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional elements “database” and “network device” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 3, the claim recites: wherein the ingesting comprises: receiving a metadata file including the definitions of the one or more counter data record types, the metadata file being associated with the application image; and ingesting the metadata file into a registry of the network device. The limitations “receiving a metadata file” and “ingesting the metadata file” are nothing more than insignificant extra solution activities. Furthermore, the additional elements “definitions of the one or more counter data record types”, “application image”, “registry”, and “network device” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 4, the claim recites: wherein ingesting the metadata file into the registry comprises, for each definition of a counter data record type included in the metadata file: creating a registry entry that includes a key field comprising an identifier of the counter data record type and a value field comprising contents of the definition; and storing the registry entry in the registry. The limitations “creating a registry entry” and “storing the registry entry in the registry” are functions that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional elements “key field”, “value field” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 5, the claim recites: wherein the metadata file is generated at a time of creating the application image. There are no additional elements recited. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 6, the claim recites: wherein the metadata file is generated by an FPGA application image creation toolchain that creates the application image. The additional element “FPGA application image creation toolchain” is recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 7, the claim recites: wherein the ingesting is performed at a time of installing the application image on the network device. There are no additional elements recited. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 8, the claim recites: wherein the ingested definition of the counter data record type includes: an identifier of the counter data record type; and a list of sub-fields that appear in a value field of counter data records corresponding to the counter data record type. The additional elements “identifier of the counter data record type” and “list of sub-fields” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 9, the claim recites: wherein retrieving the ingested definition of the counter data record type corresponding to the counter data record comprises: matching a type identifier found in a type field of the counter data record to the identifier of the counter data record type included in the ingested definition. The limitations “matching a type identifier” is a function that can be performed in the human mind or by a human using pen and paper. Furthermore, the limitation does not recite additional elements. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 10, the claim recites: wherein parsing the counter data record using the ingested definition comprises: parsing data found in a value field of the counter data record using a list of sub-fields included in the ingested definition. The limitation “parsing data” is a function that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional element “list of sub-fields” is recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 11, the claim recites: wherein the one or more sub-fields include a counter name sub-field and a counter value sub-field. The additional elements “counter name sub-field” and “counter value sub-field” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 12, the claim recites: wherein the one or more sub-fields include a sub- field indicating an identifier of a physical interface of the FPGA. The additional element “identifier of a physical interface of the FPGA” is recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 14, the claim recites: wherein the ingested definition of the counter data record type includes: an identifier of the application image; an identifier of the counter data record type; and a list of sub-fields that appear in a value field of counter data records corresponding to the counter data record type. The additional elements “identifier of the application image”, “identifier of the counter data record type”, and “list of sub-fields” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 15, the claim recites: wherein retrieving the ingested definition of the counter data record type corresponding to the counter data record comprises: determining an identifier of the application image; matching the determined identifier of the application image to the identifier of the application image included in the ingested definition; and matching a type identifier found in a type field of the counter data record to the identifier of the counter data record type included in the ingested definition. The limitations “determining” and “matching” are functions that can performed in the human mind or by a human using pen and paper. Furthermore, the additional elements “type field”, “counter data record”, and “ingested definition” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 16, the claim recites: wherein determining the identifier of the application image comprises: providing an identifier of the FPGA to a component of the OS; and receiving the identifier of the application image from the component in response to the providing. The limitation “providing an identifier” is nothing more than an insignificant extra solution activity. The limitation “receiving the identifier” is a function that can performed in the human mind or by a human using pen and paper. Furthermore, the additional element “OS” is recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 17, the claim recites: wherein parsing the counter data record comprises: determining an identifier of a physical interface of the FPGA to which the counter data record pertains. The limitation “determining” is a function that can performed in the human mind or by a human using pen and paper. Furthermore, the additional elements “FPGA” and “counter data record” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 18, the claim recites: wherein the OS is further configured to: translate the identifier of the physical interface of the FPGA into an identifier of a functional or virtual interface of the network device; and store the identifier of the functional or virtual interface with a result of the parsing in a database of the network device. The limitations “translate” is a function that can be performed in the human mind or by a human using pen and paper. Furthermore, the additional elements “network device” and “database” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Regarding claim 20, the claim recites: wherein the method is performed by a computer system distinct from the network device. The additional elements “computer system” and “network device” are recited at a high level of generality. Therefore, the claim does not integrate the judicial exception into a practical application at Step 2A Prong 2, or recite additional elements that amount to significantly more than the judicial exception at Step 2B.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Oshins et al. (US20210133069, Oshins hereinafter).
Regarding claim 1, Oshins teaches: A method performed by a network device including a field-programmable gate array (FPGA) (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”), (see Oshins et al. paragraph [0015], “…Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”); the FPGA being programmed with an application image (see Oshins et al., paragraph [0046], “Some implementations may comprise… a tangible storage medium (a memory device) to store… various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.”); the method comprising: ingesting definitions of one or more counter data record types (“telemetry record”) used by the application image (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”), (see Oshins et al., paragraph [0046]); receiving, from the FPGA, a counter message (“digital signal information”) that includes one or more counter data records (“telemetry event”) corresponding to the one or more counter data record types (see Oshins et al., paragraph [0033], “…In one example implementation, the hardware logic 212 defines a FIFO that receives digital signal information associated with a defined telemetry structure each time the associated telemetry event occurs. The hardware logic 212 may also define the hardware logic for writing a record into memory (e.g., RAM) that contains data that is placed in the FIFO.”), (see Oshins et al., paragraph [0037]), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”); and for each counter data record in the counter message: retrieving the ingested definition of the counter data record type corresponding to the counter data record (“telemetry event”) (see Oshins et al., paragraph [0033]), (see Oshins et al., paragraph [0024], “…The IC driver 110 parses the telemetry buffer 106 and populates fields in the telemetry event schema 120 based on identified corresponding digital values parsed from the digital telemetry stream 128.”), (see Oshins et al., paragraph [0031]); and parsing the counter data record (“telemetry bit stream”) using the ingested definition (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream…”), (see Oshins et al., paragraph [0029]);
Regarding claim 13, Oshins teaches: A network device comprising: a central processing unit (CPU); a field-programming gate array (FPGA) implementing a data plane of the network device (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”), (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”); the FPGA being programmed with an application image (see Oshins et al., paragraph [0046], “Some implementations may comprise… a tangible storage medium (a memory device) to store… various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.”); and an operating system (OS) running on the CPU (see Oshins et al., paragraph [0042], “…An operating system 510, such as the Microsoft Windows® operating system, the Microsoft Windows® Phone operating system or a specific operating system designed for a gaming device, resides in the memory 504 and is executed by the processor unit(s) 502, although it should be understood that other operating systems may be employed.”); that is configured to: ingest definitions of one or more counter data record types (“telemetry record”) used by the application image (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”), (see Oshins et al., paragraph [0046], “Some implementations may comprise… a tangible storage medium (a memory device) to store… various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.”); receive, from the FPGA, a counter message (“digital signal information”) that includes one or more counter data records (“telemetry event”) corresponding to the one or more counter data record types (see Oshins et al., paragraph [0033], “…In one example implementation, the hardware logic 212 defines a FIFO that receives digital signal information associated with a defined telemetry structure each time the associated telemetry event occurs. The hardware logic 212 may also define the hardware logic for writing a record into memory (e.g., RAM) that contains data that is placed in the FIFO.”), (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”); and for each counter data record in the counter message: retrieve the ingested definition of the counter data record type corresponding to the counter data record (“telemetry event”) (see Oshins et al., paragraph [0033]), (see Oshins et al., paragraph [0024], “…The IC driver 110 parses the telemetry buffer 106 and populates fields in the telemetry event schema 120 based on identified corresponding digital values parsed from the digital telemetry stream 128.”), (see Oshins et al., paragraph [0031]); and parse the counter data record (“telemetry bit stream”) using the ingested definition (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream…”), (see Oshins et al., paragraph [0029]);
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 2 is rejected under 35 U.S.C. 103 as being unpatentable over Oshins in view of Kalikivayi et al. (US20140032263, Kalikivayi hereinafter).
Regarding claim 2, Oshins does not appear to distinctly disclose: storing a result of the parsing in a database of the network device.
However, Kalikivayi teaches: storing a result of the parsing in a database of the network device (see Kalikivayi et al., paragraph [0047], “…Database 135, which may store the Parse Result 325…”), (see Kalikivayi et al., paragraph [0046], “FIG. 1 is a network and device diagram illustrating exemplary computing devices…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data as taught by Oshins, to include the storing the result of parsing in a database, as taught by Kalikivayi, for the result of allowing the data to be retrievable.
Claims 3-6 are rejected under 35 U.S.C. 103 as being unpatentable over Oshins, Ulatoski et al. (WO2023204943, Ulatoski hereinafter) and Burns et al. (US20170093867, Burns hereinafter).
Regarding claim 3, Oshins teaches: wherein the ingesting comprises: (“telemetry record”) (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”);
Oshins does not appear to distinctly disclose: receiving a metadata file
However, Ulatoski teaches: receiving a metadata file (see Ulatoski et al., paragraph [0017], “…In certain embodiments, each application package can include a virtual disk file (e.g., a VMDK or VHD file) and a metadata file (e.g., a JavaScript Object Notation (JSON) file). The virtual disk file can hold the installed content (e.g., executable program code/files and configuration data such as OS registry' entries) of the remote applications packaged therein, and the metadata file can hold metadata attributes for those applications (e.g., application name, vendor, version, executable path, application identifier (ID), entry points, etc.).”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include receiving a metadata file associated with an application image, as taught by Ulatoski, for the result of providing meaning to received data.
Oshins as modified does not appear to distinctly disclose: ingesting the metadata file into a registry of the network device.
However, Burns teaches: ingesting the metadata file into a registry of the network device (see Burns et al. paragraph [0017], “The file uploader 114 is a software component that receives a file from a client device 120… The file uploader 114 can in turn store the metadata (e.g., a description) of the file in the file metadata database 138, and associate with the metadata with the file stored in the files database 140.”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include receiving a metadata file into a registry, as taught by Burns, for the result of allowing the metadata to be retrievable.
Regarding claim 4, Oshins teaches: wherein ingesting the metadata file into the registry comprises, for each definition of a counter data record type included in the metadata file: creating a registry entry (“write a telemetry record”) that includes a key field comprising an identifier of the counter data record type (“tag indicating the type of telemetry event”) and a value field comprising contents of the definition (“telemetry record structure definition”) (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”), (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”); and storing the registry entry in the registry (see Oshins et al., paragraph [0015]);
Regarding claim 5, Oshins does not appear to distinctly disclose: wherein the metadata file is generated at a time of creating the application image.
However, Ulatoski teaches: wherein the metadata file is generated at a time of creating the application image (see Ulatoski et al., paragraph [0028], “…each application package can include a virtual disk file that holds the contents of the remote applications installed therein and a metadata file that holds metadata attributes of the installed applications (e.g., application package ID, application name, application ID, application executable path, application entry points, etc.). In one set of embodiments, enhanced app remoting management platform 202 can install/package each remote application into its own application package…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a metadata file generated at the time of the creation of the application image, as taught by Ulatoski, for the result of being able to interpret data prior to processing it.
Regarding claim 6, Oshins teaches: (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”);
Oshins does not appear to distinctly disclose: wherein the metadata file is generated by an
However, Ulatoski teaches: wherein the metadata file is generated by an (see Ulatoski et al., paragraph [0028], “…each application package can include a virtual disk file that holds the contents of the remote applications installed therein and a metadata file that holds metadata attributes of the installed applications (e.g., application package ID, application name, application ID, application executable path, application entry points, etc.). In one set of embodiments, enhanced app remoting management platform 202 can install/package each remote application into its own application package…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified system for processing data, as taught by Oshins, to include a metadata file generated by an application image creation toolchain, as taught by Ulatoski, for the result of automatically generating consistent metadata.
Claim 7, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Oshins in view of Ulatoski et al. (WO2023204943, Ulatoski hereinafter).
Regarding claim 7, Oshins does not appear to distinctly disclose: wherein the ingesting is performed at a time of installing the application image on the network device.
However, Ulatoski teaches: wherein the ingesting is performed at a time of installing the application image on the network device (see Ulatoski et al., paragraph [0028], “…each application package can include a virtual disk file that holds the contents of the remote applications installed therein and a metadata file that holds metadata attributes of the installed applications (e.g., application package ID, application name, application ID, application executable path, application entry points, etc.). In one set of embodiments, enhanced app remoting management platform 202 can install/package each remote application into its own application package…”), (see Ulatoski et al., paragraph [0038], “…The various embodiments described herein can be practiced with other computer system configurations including handheld devices, microprocessor systems, microprocessorbased or programmable consumer electronics, minicomputers, mainframe computers, and the like.”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a metadata file generated at the time of the creation of the application image, as taught by Ulatoski, for the result of being able to interpret data prior to processing it.
Regarding claim 19, Oshins teaches: A method comprising: receiving a counter message output (“digital signal information”) by a field-programmable gate array (FPGA) of a network device (see Oshins et al., paragraph [0033], “…In one example implementation, the hardware logic 212 defines a FIFO that receives digital signal information associated with a defined telemetry structure each time the associated telemetry event occurs. The hardware logic 212 may also define the hardware logic for writing a record into memory (e.g., RAM) that contains data that is placed in the FIFO.”), (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”), (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”); wherein the FPGA is programmed with an application image (see Oshins et al., paragraph [0037]), (see Oshins et al., paragraph [0046], “Some implementations may comprise… a tangible storage medium (a memory device) to store… various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.”); and wherein the counter message includes one or more counter data records corresponding to one or more counter data record types used by the application image (see Oshins et al., paragraph [0033]), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”), (see Oshins et al., paragraph [0046]); and for each counter data record in the counter message: (see Oshins et al., paragraph [0033]), (see Oshins et al., paragraph [0031]); and parsing the counter data record (see Oshins et al., paragraph [0015]);
Oshins does not appear to distinctly disclose: retrieving metadata
However, Ulatoski teaches: retrieving metadata (see Ulatoski et al., paragraph [0031], “…Finally, at block 316, portal service can create… the metadata maintained in the application inventory…”); and (see Ulatoski et al., paragraph [0031]);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include retrieving metadata, as taught by Ulatoski, for the result of being able to interpret data.
Regarding claim 20, Oshins teaches: wherein the method is performed by a computer system distinct from the network device (see Oshins et al., paragraph [0068], “The implementations described herein are implemented as logical steps in one or more computer systems…”), (see Oshins et al., paragraph [0015], “…hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”);
Claim 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Oshins in view of Monier et al. (US20220201101, Monier hereinafter).
Regarding claim 8, Oshins teaches: wherein the ingested definition of the counter data record type includes: an identifier of the counter data record type; and a(“telemetry event”) (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”);
Oshins does not appear to distinctly disclose: and a list of sub-fields that appear in a value field of counter data records corresponding to the counter data record type.
However, Monier teaches: a list of sub-fields that appear in a value field (see Monier et al., paragraph [0054], “...The RSSI and SNR fields are sub-fields of the value field in the TLV element.…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a list of sub-fields in a value field, as taught by Monier, for the result of increasing the efficiency of processing and retrieving data.
Regarding claim 9, Oshins teaches: wherein retrieving the ingested definition of the counter data record type corresponding to the counter data record comprises: matching (“parse the hardware bitstream symbol table… to autogenerate code… that interprets the digital telemetry stream”) a type identifier found in a type field (tag indicating the type of telemetry event) of the counter data record to the identifier of the counter data record type included in the ingested definition (see Oshins et al., paragraph [0034], “The hardware bitstream symbol table 210 stores names and related logical state information (e.g., function names, objects, classes etc.) for all defined telemetry structures acted upon when the template 220 is instantiated. A telemetry schema generator 214 is executed by a processor to parse the hardware bitstream symbol table 210 to autogenerate code (e.g., an FPGA driver 216) that interprets the digital telemetry stream generated by the FPGA 208 as the hardware logic 212 is executed.”), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”), (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”), (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”);
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Oshins and Monier as applied to claim 8 above, and further in view of Bess et al. (US20200066392, Bess hereinafter).
Regarding claim 10, Oshins teaches: wherein parsing the counter data record using the ingested definition comprises: record (“telemetry record”) (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”);
Oshins does not appear to distinctly disclose: parsing data found in a value field
However, Bess teaches: parsing data found in a value field (see Bess et al., paragraph [0046], “…The correct interpretation of the messages, which is described in more detail below, can involve parsing the fields and the subfields of the HL7 messages and then matching the data values in the fields and the subfields to a data type associated with the field of the subfield.”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include parsing a value field using a list of subfields, as taught by Bess, for the result of associating the data with corresponding system components and allowing meaningful interpretation of the parsed data.
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Oshins and Monier as applied to claim 8 above, and further in view of Chkodrov et al. (US20180285396, Chkodrov hereinafter).
Regarding Claim 11, Oshins as modified does not appear to distinctly disclose: wherein the one or more sub-fields include a counter name sub-field and a counter value sub-field.
However, Chkodrov teaches: a counter name (“primitive type”) sub-field and a counter value sub-field (see Chkodrov et al., paragraph [0017], “…in a first schema a primitive type such as a counter name is represented as a character string…”), (see Chkodrov et al., paragraph [0018], “The first schema includes fields for a time stamp, an instance identifier, an object descriptor, a primitive type, and a primitive value…”), (see Chkodrov et al., paragraph [0019], “…a primitive type may be counter data wherein the primitive value is the actual counter value in the form of integers.”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a counter name sub-field and a counter value sub-field, as taught by Chkodrov, for the result of increasing the efficiency of processing and retrieving data.
Regarding claim 12, Oshins teaches: wherein the one or more sub-fields include a sub- field (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”), (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”);
Oshins does not appear to distinctly disclose:
However, Chkodrov teaches: (see Chkodrov et al., paragraph [0024], “…The object descriptor column 210 includes interface identifiers...”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a sub- field for an identifier of a physical interface, as taught by Chkodrov, for the result of increasing the efficiency of processing and retrieving data.
Claim 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Oshins in view of Ulatoski et al. (WO2023204943, Ulatoski hereinafter) and Monier et al. (US20220201101, Monier hereinafter).
Regarding claim 14, Oshins teaches: wherein the ingested definition of the counter data record type includes: (“tag indicating the type of telemetry event”) (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”); (see Oshins et al., paragraph [0031]).
Oshins does not appear to distinctly disclose: wherein the ingested definition of the counter data record type includes: an identifier of the application image;
However, Ulatoski teaches: an identifier of the application image (see Ulatoski et al., paragraph [0036], “…app delivery agent 226 can extract the application package ID…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include an application image identifier, as taught by Ulatoski, for the result of allowing the system to accurately associate incoming data with the correct application image.
Oshins as modified does not appear to distinctly disclose: and a list of sub-fields that appear in a value field
However, Monier teaches: and a list of sub-fields that appear in a value field (see Monier et al., paragraph [0054], “...The RSSI and SNR fields are sub-fields of the value field in the TLV element.…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include a list of sub-fields in a value field, as taught by Monier, for the result of increasing the efficiency of processing and retrieving data.
Regarding claim 15, Oshins teaches: wherein retrieving the ingested definition of the counter data record type corresponding to the counter data record comprises: (“parse the hardware bitstream symbol table… to autogenerate code… that interprets the digital telemetry stream”) (see Oshins et al., paragraph [0034], “The hardware bitstream symbol table 210 stores names and related logical state information (e.g., function names, objects, classes etc.) for all defined telemetry structures acted upon when the template 220 is instantiated. A telemetry schema generator 214 is executed by a processor to parse the hardware bitstream symbol table 210 to autogenerate code (e.g., an FPGA driver 216) that interprets the digital telemetry stream generated by the FPGA 208 as the hardware logic 212 is executed.”) (see Oshins et al., paragraph [0029], “During an initial design operation, a developer drafts one or more telemetry record structure definitions 202 defining telemetry structures of interest… By example and without limitation, the telemetry record structure definitions 202 include telemetry structures 204, 206 that are each further defined by fields such as fields 222 and 224…”); and matching a type identifier found in a type field of the counter data record to the identifier of the counter data record type included in the ingested definition (see Oshins et al., paragraph [0034]), (see Oshins et al., paragraph [0031], “...the telemetry structures 204, 206 each include a number of fields (e.g., fields 222, 224) that include the current cycle count, a tag indicating the type of telemetry event that has occurred (e.g., “IoOperationStart”), the type of I/O operation (e.g., write, read, flush), the LBA start of the operation, and the length of the operation.…”), (see Oshins et al., paragraph [0029]);
Oshins does not appear to distinctly disclose: determining an identifier of the application image;
However, Ulatoski teaches: determining an identifier of the application image; (see Ulatoski et al., paragraph [0036], “…app delivery agent 226 can extract the application package ID…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include an application image identifier, as taught by Ulatoski, for the result of allowing the system to accurately associate incoming data with the correct application image.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Oshins, Ulatoski, and Monier as applied to claim 15 above, and further in view of Hoppert et al. (US20180205553, Hoppert hereinafter).
Regarding claim 16, Oshins does not appear to distinctly disclose: wherein determining the identifier of the application image comprises: providing an identifier of the FPGA to a component of the OS; and receiving the identifier of the application image from the component in response to the providing.
However, Ulatoski teaches: wherein determining the identifier of the application image comprises: (see Ulatoski et al., paragraph [0017], “…This single master software image can include the installation of an OS 212, an app remoting agent 214, and an app delivery agent 216…”); and receiving the identifier of the application image from the component in response to the providing (see Ulatoski et al., paragraph [0036], “…app delivery agent 226 can extract the application package ID…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include an OS and identifier of the application image, as taught by Ulatoski, for the result of allowing the system to accurately associate incoming data with the correct application image.
Oshins as modified does not appear to distinctly disclose: providing an identifier of the FPGA.
However, Hoppert teaches: providing an identifier of the FPGA (see Hoppert et al., paragraph [0016], “…in this example the virtual machine may simply provide a unique identifier of the FPGA program in the request…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include an identifier for an FPGA, as taught by Hoppert, for the result of accurately associating data with the hardware that generated it.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Oshins in view of Chkodrov et al. (US20180285396, Chkodrov hereinafter).
Regarding claim 17, Oshins teaches: wherein parsing the counter data record comprises: (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”), (see Oshins et al., paragraph [0015], “…When loaded into memory of a processing device including the hardware component, the driver may be executed by a processor to interpret the output telemetry stream, populate data fields (e.g., telemetry event data) of a telemetry database schema with values parsed from the telemetry bit stream, and write a telemetry record including the field tags and the associated populated field values. Due to the preservation of semantic information (e.g., a database schema that gives structure and meaning to the digital values captured within the output telemetry stream), hardware telemetry for a single configuration of the hardware device can be collected from multiple (e.g., thousands) of different devices and aggregated, statistically processed, and used to further design efforts.”);
Oshins does not appear to distinctly disclose: determining an identifier of a physical interface
However, Chkodrov teaches: determining an identifier of a physical interface (see Chkodrov et al., paragraph [0024], “…The object descriptor column 210 includes interface identifiers...”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include an identifier for a physical interface, as taught by Chkodrov, for the result of accurately associating data with the hardware that generated it.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Oshins and Chkodrov as applied to claim 17 above, and further in view of Li et al. (US20130064201, Li hereinafter), Lekontsev et al. (US20160337846, Lekontsev hereinafter), and Kalikivayi et al. (US20160337846 Kalikivayi).
Regarding claim 18, Oshins teaches: wherein the OS is further configured to: (see Oshins et al., paragraph [0037], “…The system 300 includes a user computing device 302 that includes an FPGA 314 programmed with hardware logic for emitting a digital telemetry stream 310…”);
Oshins does not appear to distinctly disclose: translate the identifier of the physical interface
However, Li teaches: translate the identifier of the physical interface (see Li et al., paragraph [0034], “…the ubiquitous network gateway converts the identifier of the device of the extension network of the ubiquitous network to the identifier of the communication network device…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include the translation of the identifiers of interfaces and devices, as taught by Li, for the result of allowing the correct interpretation of data between the hardware and software.
Oshins as modified does not appear to distinctly disclose: store the identifier of the functional or virtual interface with a result of the parsing in a database of the network device.
However, Lekontsev teaches: store the identifier of the functional or virtual interface (see Lekontsev et al., paragraph [0008], “The first feature of the present invention provides a method for labeling wireless network devices herein called ‘device labeling’ that includes… storing the device identifier in the database”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include the storing of identifiers in a database, as taught by Lekontsev, for the result of allowing the identifiers to be retrievable.
Oshins as modified does not appear to distinctly disclose: store
However, Kalikivayi teaches: store (see Kalikivayi et al., paragraph [0047], “…Database 135, which may store the Parse Result 325…”), (see Kalikivayi et al., paragraph [0046], “FIG. 1 is a network and device diagram illustrating exemplary computing devices…”);
It would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified a system for processing data, as taught by Oshins, to include the storing of a parsing result in a database, as taught by Kalikivayi, for the result of allowing the parsing to be retrievable.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Joshua Tran whose telephone number is (571)272-5460.
The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s
supervisor, Hyung Sough can be reached on (571)272-6799. The fax phone number for the
organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be
obtained from either Private PAIR or Public PAIR. Status information for unpublished
applications is available through Private PAIR only. For more information about the PAIR
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you
would like assistance from a USPTO Customer Service Representative or access to the
automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOSHUA TRAN/
Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights