DETAILED ACTION
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 .
Response to Arguments
Applicant's arguments filed 10/23/2025, with respect to claim rejections under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Beginning on page 8, Applicant states that the claims recite a practical application in that "the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller," and "the requesting entity being implemented as a computing device remote to the data processing system". This is not persuasive because, although structure is recited for the various processors/controllers, they are additional elements not considered significantly more. The claim as written, describes a distributed computing network, where the processing is initiated from a central device connected to a plurality of peripheral devices that perform the processing or further relay the request, and respond, as means of moving some of the processing and memory out of the central/main processor. These additional elements are considered mere instructions to apply an exception (see MPEP 2106.05(f) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more) and can be considered to be well-understood, routine, conventional activity (see MPEP 2106.05(d) The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ) (see Bigelow1 p. 1, para. 4, edge computing moves some portion of storage and compute resources out of the central data center and closer to the source of the data itself.).
On page 9, Applicant states that the claimed invention is an improvement to technology and an improvement to computer functionalities of the claimed requesting entity. This is not persuasive because although the overall system is improved through distributing the processing system, so that the individual and main computers are less limited, the processors themselves are not improved as they are still performing in their expected capacities of receiving, analyzing, and processing data (see MPEP 2105.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more.). Additionally, as previously stated, the purpose of a distributed computing system is to ease the processing and storage load from any single processor within the system.
Applicant’s arguments, beginning on page 10, filed 10/23/2025, with respect to nonstatutory double patenting rejections have been fully considered and are persuasive. The rejections of claims 1, 8, and 15 under nonstatutory double patenting have been withdrawn.
Applicant’s arguments, see page 11, filed 10/23/2025, with respect to claim rejections under 35 U.S.C. 102 have been fully considered, along with amendments, and are persuasive, insofar that the cited prior art does not seem to explicitly teach the amended language, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system. The rejections of claims 1, 8, and 15 under 35 U.S.C. 102 have been withdrawn.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-19 and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Specifically, representative Claim 1 recites:
A method for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system, the method comprising:
obtaining, by a management controller of the data processing system and from a requesting entity that manages operations of the data processing system and the DDCEDs, a request for diagnostic data for a DDCED of the DDCEDs, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller;
making a determination, by the management controller, regarding whether the DDCED presents an interface for retrieval of the diagnostic data (Note that the remaining limitations are contingent within the method claim on whether the DDCED presents an interface for retrieval and therefore do not carry patentable weight.);
in a first instance of the determination where the DDCED presents the interface:
bridging, by the management controller, the request to a guest management controller of the DDCED;
obtaining, by the management controller, a response to the request from the guest management controller; and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data, the requesting entity being implemented as a computing device remote to the data processing system.
The claim limitations in the abstract idea have been highlighted in bold above; the remaining limitations are “additional elements”.
Under the Step 1 of the eligibility analysis, we determine whether the claims are to a statutory category by considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: Process, machine, manufacture, or composition of matter. The above claim is considered to be in a statutory category (process).
Under the Step 2A, Prong One, we consider whether the claim recites a judicial exception (abstract idea). In the above claim, the highlighted portion constitutes an abstract idea because, under a broadest reasonable interpretation, it recites limitations that fall into/recite an abstract idea exceptions. Specifically, under the 2019 Revised Patent Subject matter Eligibility Guidance, it falls into the grouping of subject matter when recited as such in a claim limitation, that covers mental processes – concepts performed in the human mind including an observation, evaluation, judgement, and/or opinion.
For example, steps of “obtaining a request for diagnostic data for a DDCED of the DDCEDs (viewing a request);
making a determination regarding whether the DDCED presents an interface for retrieval of the diagnostic data (making a determination based on an observation);
in a first instance of the determination where the DDCED presents the interface (Remaining limitations not given patentable weight due to contingency as stated above):
bridging the request to a guest management controller of the DDCED (transferring information);
obtaining a response to the request from the guest management controller (viewing a response); and
providing the response to a requesting entity to service the request for the diagnostic data (transferring information)” are treated by the Examiner as belonging to mental process grouping.
Similar limitations comprise the abstract ideas of Claims 8 and 15 (Examiner notes that the contingency does not apply).
Next, under the Step 2A, Prong Two, we consider whether the claim that recites a judicial exception is integrated into a practical application.
In this step, we evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
The above claims comprise the following additional elements:
Claim 1: A method for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system, obtaining, by a management controller of the data processing system, a request for diagnostic data for a DDCED of the DDCEDs; obtaining, by the management controller, a response to the request from the guest management controller, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller; and the requesting entity being implemented as a computing device remote to the data processing system;
Claim 8: A non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system, obtaining, by a management controller of the data processing system, a request for diagnostic data for a DDCED of the DDCEDs; obtaining, by the management controller, a response to the request from the guest management controller, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a second processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the second processor and are also physically installed internally within the data processing system, and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller; and the requesting entity being implemented as a computing device remote to the data processing system;
Claim 15: A data processing system, a first processor coupled to first memory, diagnostic data collection enhanced devices (DDCEDs); and a management controller comprising: a second processor; and a second memory; obtaining, by the management controller of the data processing system, a request for diagnostic data for a DDCED of the DDCEDs, wherein the management controller is physically installed internally within the data processing system and is distinct and separate from the first processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the first processor and are also physically installed internally within the data processing system, and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller; and obtaining, by the management controller, a response to the request from the guest management controller; and the requesting entity being implemented as a computing device remote to the data processing system.
The additional element in the preamble of “A method for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system” is not qualified for a meaningful limitation because it only generally links the use of the judicial exception to a particular technological environment or field of use. Although considered mental steps above, obtaining, by a management controller of the data processing system, a request for diagnostic data for a DDCED of the DDCEDs; and
obtaining, by the management controller, a response to the request from the guest management controller also represent mere data gathering steps and only adds an insignificant extra-solution activity to the judicial exception. A non-transitory machine-readable medium and memory (generic memory) and a data processing system, DDCEDs, and a processor (generic processors) are generally recited and are not qualified as particular machines.
The additional element in the preamble of “A method for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system” is not qualified for a meaningful limitation because it only generally links the use of the judicial exception to a particular technological environment or field of use. Although considered mental steps above, obtaining, by a management controller of the data processing system, a request for diagnostic data for a DDCED of the DDCEDs; and
obtaining, by the management controller, a response to the request from the guest management controller also represent mere data gathering steps and only adds an insignificant extra-solution activity to the judicial exception. A non-transitory machine-readable medium and first and second memory (generic memory), and a data processing system, DDCEDs, and a first and second processor (generic processors) are generally recited and are not qualified as particular machines. The management controller being physically installed internally within the data processing system and is distinct and separate from the first processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the first processor and are also physically installed internally within the data processing system, and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller is considered insignificant extra-solution activity because a distributed computing network, where the processing is initiated from a central device connected to a plurality of peripheral devices that perform the processing or further relay the request, and respond, as means of moving some of the processing and memory out of the central/main processor is receiving and transmitting data over a network, which is considered mere instructions to apply an exception. Under broadest reasonable interpretation, the claim recites the claim really just a computer/processor/controller network for processing requests for information, and the “processor of the data processing system” is a generic processor with no description other than its “distinctness” from the management controller and DDCEDs (see MPEP 2106.05(f) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more.).
In conclusion, the above additional elements, considered individually and in combination with the other claim elements do not reflect an improvement to other technology or technical field, and, therefore, do not integrate the judicial exception into a practical application. Therefore, the claims are directed to a judicial exception and require further analysis under the Step 2B.
However, the above claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception (Step 2B analysis). As stated above for step 2A prong II, the additional elements are considered mere instructions to apply an exception as the claim recites computers performing in their expected capacities of receiving and transmitting data. Additionally, as stated above in the response to arguments, the claimed additional elements can also be considered well understood, routine, and conventional as devices receiving an transmitting data over a network.
The claims, therefore, are not patent eligible.
With regards to the dependent claims, claims 2-7, 9-14, 16-19, and 21 provide additional features/steps which are part of an expanded algorithm, so these limitations should be considered part of an expanded abstract idea of the independent claims.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1, 8, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over BeSerra et al. (US 10489232 B1), hereinafter “BeSerra”.
Regarding Claim 1, BeSerra teaches a method for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system, the method comprising:
obtaining, by a management controller of the data processing system and from a requesting entity that manages operations of the data processing system and the DDCEDs, a request for diagnostic data for a DDCED of the DDCEDs (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ), and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller (BeSerra Col. 4, Line 11, FIG. 1 also illustrates a communications network 120 that may include one or more computers accessible by users 110. According to one embodiment, resources executing on servers 130 may be configured to provide computing services to users 110 via network 120. See Fig. 1 120. There is a central processor that handles communication between users and the systems they are sending requests to);
making a determination, by the management controller, regarding whether the DDCED presents an interface for retrieval of the diagnostic data (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. The determination that the management controller can interface with the data engine’s processor must necessarily be made in order for the two to interact.).;
in a first instance of the determination where the DDCED presents the interface:
bridging, by the management controller, the request to a guest management controller of the DDCED (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140). Fig. 3 320. The processor that sends the request communicates with the processor of the diagnostic data engine to relay the request);
obtaining, by the management controller, a response to the request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.), the requesting entity being implemented as a computing device remote to the data processing system (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ).
BeSerra, does not explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system.
However, BeSerra teaches receiving and executions can be local or remote (BeSerra Col. 4, Line 25, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140) Also see Col. 10, Line 6, In a distributed computing environment, program modules may be located in both local and remote memory storage devices.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra to explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, because the purpose of the system is to allow devices to communicate and share data and analysis more efficiently, whether local or remote (BeSerra Col. 2, Line 22, this disclosure describes methods and systems for scalably accessing and collecting diagnostic information for a plurality of devices in a data center. […] The diagnostic information may be accessed and collected from devices across an entire data center or multiple data centers.).
Regarding Claim 8, BeSerra teaches a non-transitory machine-readable medium having instructions stored therein, which when executed by a first processor of a management controller of a data processing system, cause the first processor to perform operations for managing diagnostic data collection enhanced devices (DDCEDs) hosted by a data processing system (BeSerra Col. 15, Line 9, (82) Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computers or computer processors. The code modules may be stored on any type of non-transitory computer-readable medium or computer storage device), the operations comprising:
obtaining, by a management controller of the data processing system and from a requesting entity that manages operations of the data processing system and the DDCEDs, a request for diagnostic data for a DDCED of the DDCEDs (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ), and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller (BeSerra Col. 4, Line 11, FIG. 1 also illustrates a communications network 120 that may include one or more computers accessible by users 110. According to one embodiment, resources executing on servers 130 may be configured to provide computing services to users 110 via network 120. See Fig. 1 120. There is a central processor that handles communication between users and the systems they are sending requests to);
making a determination, by the management controller, regarding whether the DDCED presents an interface for retrieval of the diagnostic data BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. The determination that the management controller can interface with the data engine’s processor must necessarily be made in order for the two to interact.);
in a first instance of the determination where the DDCED presents the interface:
bridging, by the management controller, the request to a guest management controller of the DDCED (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140). Fig. 3 320. The processor that sends the request communicates with the processor of the diagnostic data engine to relay the request);
obtaining, by the management controller, a response to the request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.), the requesting entity being implemented as a computing device remote to the data processing system (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ).
BeSerra, does not explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system.
However, BeSerra teaches receiving and executions can be local or remote (BeSerra Col. 4, Line 25, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140) Also see Col. 10, Line 6, In a distributed computing environment, program modules may be located in both local and remote memory storage devices.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra to explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, because the purpose of the system is to allow devices to communicate and share data and analysis more efficiently, whether local or remote (BeSerra Col. 2, Line 22, this disclosure describes methods and systems for scalably accessing and collecting diagnostic information for a plurality of devices in a data center. […] The diagnostic information may be accessed and collected from devices across an entire data center or multiple data centers.).
Regarding Claim 15, BeSerra teaches a data processing system, comprising:
a first processor coupled to first memory (BeSerra Col. 6, Line 60, Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. Fig. 2 220. The original inputs are facilitated through the user interface then to the server components, the user interface, and must have some form of memory in order to record and transmit the user requests);
diagnostic data collection enhanced devices (DDCEDs) (BeSerra Fig. 1 100 Diagnostic Data Engine); and
a management controller (BeSerra Col. 6, Line 62, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. Fig. 2 230-260. The original inputs are facilitated from the user interface and through the server components) comprising:
a second processor (BeSerra Col. 6, Line 63, (45) the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. See Fig. 2 230); and
a second memory coupled to the second processor to store instructions, which when executed by the processor, cause the processor to perform operations for managing the DDCEDs (BeSerra Col. 6, Line 63, (45) the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. The requested metric data may be provided to a data store writer 250 that may store the diagnostic information. A data store reader 240 may be configured to access the data store 260 and retrieve diagnostic information based on requests from the users 210 or for other purposes.), the operations comprising:
obtaining, by a management controller of the data processing system and from a requesting entity that manages operations of the data processing system and the DDCEDs, a request for diagnostic data for a DDCED of the DDCEDs (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ), and the management controller is configured as a unified interface for communications between the requesting entity and the DDCEDs such that all of the communications from the requesting entity that are meant for the DDCEDs are first received by the management controller (BeSerra Col. 4, Line 11, FIG. 1 also illustrates a communications network 120 that may include one or more computers accessible by users 110. According to one embodiment, resources executing on servers 130 may be configured to provide computing services to users 110 via network 120. See Fig. 1 120. There is a central processor that handles communication between users and the systems they are sending requests to);
making a determination, by the management controller, regarding whether the DDCED presents an interface for retrieval of the diagnostic data (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. The determination that the management controller can interface with the data engine’s processor must necessarily be made in order for the two to interact.);
in a first instance of the determination where the DDCED presents the interface:
bridging, by the management controller, the request to a guest management controller of the DDCED (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140). Fig. 3 320. The processor that sends the request communicates with the processor of the diagnostic data engine to relay the request);
obtaining, by the management controller, a response to the request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.), the requesting entity being implemented as a computing device remote to the data processing system (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. ).
BeSerra, does not explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system.
However, BeSerra teaches receiving and executions can be local or remote (BeSerra Col. 4, Line 25, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140) Also see Col. 10, Line 6, In a distributed computing environment, program modules may be located in both local and remote memory storage devices.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra to explicitly teach wherein the management controller is physically installed internally within the data processing system and is distinct and separate from a processor of the data processing system, all of the DDCEDs are distinct and separate from both the management controller and the processor and are also physically installed internally within the data processing system, because the purpose of the system is to allow devices to communicate and share data and analysis more efficiently, whether local or remote (BeSerra Col. 2, Line 22, this disclosure describes methods and systems for scalably accessing and collecting diagnostic information for a plurality of devices in a data center. […] The diagnostic information may be accessed and collected from devices across an entire data center or multiple data centers.).
Regarding Claim 21, BeSerra does not explicitly teach wherein the requesting entity is unaware of native functionalities of the DDCEDs, and the management controller is configured to, as the unified interface, invoke the native functionalities of the DDCEDs for the requesting entity or use supplemental functionalities of the management controller to process the communications from the requesting entity that are meant for the DDCEDs.
However, BeSerra teaches a distributed computing environment (Col. 10, Line 6, In a distributed computing environment, program modules may be located in both local and remote memory storage devices.), where the requesting entity or user device is not in direct contact with the devices it is requesting from, as the requests are processed and communicated through a network device or servers (See Figs. 1 and 2). Therefore, the user interface itself does not need to know how the peripheral devices operate, only how to communicate to the gateway.
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra to explicitly teach wherein the requesting entity is unaware of native functionalities of the DDCEDs, and the management controller is configured to, as the unified interface, invoke the native functionalities of the DDCEDs for the requesting entity or use supplemental functionalities of the management controller to process the communications from the requesting entity that are meant for the DDCEDs, because the only device that necessarily must communicate with all devices on the network is network device/server that is receiving the request and relaying it to the proper peripheral device for a response.
Claim(s) 2, 3, 9, 10, 16, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over BeSerra (as stated above) in view of Adriani (US 20230156032 A1).
The Examiner notes that claims 2 and 3 are contingent on whether the DDCED presents an interface for retrieval of the diagnostic data, and therefore do not carry patentable weight.
Regarding Claim 2, BeSerra (as stated above) further teaches in a second instance of the determination where the DDCED does not present the interface:
sending, by the management controller, a data request based on the request for the diagnostic data to a logic device of the DDCED (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. );
obtaining, by the management controller, data that is responsive to the data request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.);
obtaining, by the management controller, a response using the data (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Making the results available to be provided.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.).
BeSerra (as stated above) is not relied upon to teach a synthesized data request; and
a synthetic response using the data.
Adriani teaches a synthesized data request (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204.); and
a synthetic response using the data (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204. Also see [0267] 6. Typically, the coordination device 220 collects information from the coordination agents 222. […] Combined information from the coordination device 220 can then be passed to the monitor controller 200 and/or the simulator controller 204.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra (as stated above) in view of Adriani to explicitly teach a synthesized data request; and
a synthetic response using the data, to describe how to the monitoring system of BeSerra communicates with the diagnostic data engine when there is no direct connection (BeSerra (26)), so that the two devices can work together (Adriani [0267] The coordination device 220 can communicate with both the simulator controller 204 and the monitor controller 200.). The intermediary device needs to be able to communicate with both devices, in order to facilitate instructions and data flow between them.
Regarding Claim 3, BeSerra in view of Adriani (as stated above) further teaches wherein the guest management controller is operably connected to the logic device, and the logic device is operably connected to components of the DDCED for which the request for the diagnostic data is directed (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. Also see Col. 15, Line 50, (84) some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc.).
Regarding Claim 9, BeSerra (as stated above) further teaches in a second instance of the determination where the DDCED does not present the interface (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. There are scenarios where there are remote processors not directly interfacing with each other.):
sending, by the management controller, a data request based on the request for the diagnostic data to a logic device of the DDCED (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. );
obtaining, by the management controller, data that is responsive to the data request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.);
obtaining, by the management controller, a response using the data (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Making the results available to be provided.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.).
BeSerra (as stated above) is not relied upon to teach a synthesized data request; and
a synthetic response using the data.
Adriani teaches a synthesized data request (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204.); and
a synthetic response using the data (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204. Also see [0267] 6. Typically, the coordination device 220 collects information from the coordination agents 222. […] Combined information from the coordination device 220 can then be passed to the monitor controller 200 and/or the simulator controller 204.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra (as stated above) in view of Adriani to explicitly teach a synthesized data request; and
a synthetic response using the data, to describe how to the monitoring system of BeSerra communicates with the diagnostic data engine when there is no direct connection (BeSerra (26)), so that the two devices can work together (Adriani [0267] The coordination device 220 can communicate with both the simulator controller 204 and the monitor controller 200.). The intermediary device needs to be able to communicate with both devices, in order to facilitate instructions and data flow between them.
Regarding Claim 10, BeSerra in view of Adriani (as stated above) further teaches wherein the guest management controller is operably connected to the logic device, and the logic device is operably connected to components of the DDCED for which the request for the diagnostic data is directed (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. Also see Col. 15, Line 50, (84) some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc.).
Regarding Claim 16, BeSerra (as stated above) further teaches in a second instance of the determination where the DDCED does not present the interface (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. There are scenarios where there are remote processors not directly interfacing with each other.):
sending, by the management controller, a data request based on the request for the diagnostic data to a logic device of the DDCED (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. );
obtaining, by the management controller, data that is responsive to the data request from the guest management controller (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Results are obtained based on the request.);
obtaining, by the management controller, a response using the data (BeSerra Col .4, Line 32, (26) In response to receipt of the request, diagnostic data engine 100 may log the request and provide updates as to the status of the request. The diagnostic data engine 100 may communicate with other services to facilitate: (1) processing of the request, (2) collection of data pertaining to request, and (3) generating interfaces to provide results of the request. The diagnostic data engine 100 may, for example, provide a user interface for facilitating submission of the request. The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. Making the results available to be provided.); and
providing, by the management controller, the response to the requesting entity to service the request for the diagnostic data (BeSerra Col. 4, Line 39,(26) The diagnostic data engine 100 may further provide a user interface for viewing the results of the request, modifying the request, or cancelling the request. (27) The diagnostic data engine 100 may be made accessible to a user or to an external service via an application programming interface (API) or a user interface that may be accessed via a Web browser or other input mechanisms. The results obtained in response to the request are provided.).
BeSerra (as stated above) is not relied upon to teach a synthesized data request; and
a synthetic response using the data.
Adriani teaches a synthesized data request (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204.); and
a synthetic response using the data (Adriani [0262] 1. The coordination device 220 is primarily a data collector (e.g., of operation data including packets of traffic/mirrored traffic having traversed some or all of the internal network 120) for the monitor controller 200. In some cases, the coordination device 220 may interact with elements other than the monitor controller 200, for example, the coordination agents 222 such as coordination agent 222A or simulator controller 204. Also see [0267] 6. Typically, the coordination device 220 collects information from the coordination agents 222. […] Combined information from the coordination device 220 can then be passed to the monitor controller 200 and/or the simulator controller 204.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra (as stated above) in view of Adriani to explicitly teach a synthesized data request; and
a synthetic response using the data, to describe how to the monitoring system of BeSerra communicates with the diagnostic data engine when there is no direct connection (BeSerra (26)), so that the two devices can work together (Adriani [0267] The coordination device 220 can communicate with both the simulator controller 204 and the monitor controller 200.). The intermediary device needs to be able to communicate with both devices, in order to facilitate instructions and data flow between them.
Regarding Claim 17, BeSerra in view of Adriani (as stated above) further teaches wherein the guest management controller is operably connected to the logic device, and the logic device is operably connected to components of the DDCED for which the request for the diagnostic data is directed (BeSerra Col. 4, Line 24 (26) In some embodiments, the diagnostic data engine 100 comprises a processor executing software instructions (e.g., on a computer local to or remote from the servers 130 and/or the resources 140. Also see Col. 15, Line 50, (84) some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc.).
Claim(s) 4-7, 11-14, 18, 19 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over BeSerra in view of Adriani (as stated above) further in view of Plesky (REST – All You Have To Know About Representational State Transfer, plesk.com/blog, blog, 13 April 2020).
The Examiner again notes that claims 4-7 are also contingent on whether the DDCED presents an interface for retrieval of the diagnostic data, and therefore do not carry patentable weight.
Regarding Claim 4, BeSerra in view of Adriani (as stated above) is not relied upon to teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller.
Plesky teaches wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller (Plesky p. 5, Uniform Interfaces, para. 1, Perhaps one of the most fundamental aspects of RESTful systems is the uniform interface, […] Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra in view of Adriani (as stated above) further in view of Plesky, to explicitly teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller, because REST is a type of software architecture that was designed to ensure interoperability between different Internet computer systems, and services that conform to the REST architecture can more easily communicate with one another, especially in cases when clients and servers are acting independently but communicating through API as done in BeSerra.
Regarding Claim 5, BeSerra in view of Adriani and Plesky (as stated above) further teaches wherein the REST interface presents a portion of all available telemetry data available for the components, and does not present a second portion of the all available telemetry data available for the components (BeSerra Col. 7, Line 56, (49) A transmit component 350 may send some or all of the stored data to a requesting system. Only sending “some” data means there is data not sent. Also see Col. 5, Line 37, (36) In some cases, diagnostic data engine 100 may not have access to all available data for the relevant devices because obtaining all of this data would take too much time, would require too much storage space, or because some of the data has been determined to have a low likelihood of being relevant to the device of interest.).
Regarding Claim 6, BeSerra in view of Adriani and Plesky (as stated above) further teaches prior to obtaining the request:
identifying presence of the DDCED (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. The diagnostic data engine must be identified as present prior to obtaining a request, in order to ensure the request is reaching the proper destination);
enumerating universal resource identifiers presented by the REST interface (BeSerra Col. 6, Line 30, (43) In some embodiments, an application programming interface (API) may be provided to facilitate requests for diagnostic information. For example, an API can be called with information such as a device identifier, event type, and time frame that pertains to the diagnostic information. Also see Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. REST works by having its own self-contained identifiers); and
establishing a bridging interface for the DDCED based on the universal resource identifiers (Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. Note that. conceptually. resources are distinct from the results that are returned to a client. For example. no matter what the server's own method of storing data is. the data sent in answer to a request could be sent as anything from XML to HTML or even JSON. Also see p. 6, para. 2, Note that developers sometimes describe the APls that they create as complying with REST architecture even if these APls sometime skirt around the constraints imposed by RESTful architecture. REST is meant to work with the API to facilitate data transfer.).
Regarding Claim 7, BeSerra in view of Adriani and Plesky (as stated above) further teaches wherein bridging the request comprises:
making a second determination that the request specifies one of the universal resource identifiers (Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. The request must be understood, and is constrained to contain the identifier of the resource of interest.); and
based on the second determination, forwarding the request to the guest management controller (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. The request one forwarded as dictated by the REST architecture is still eventually sent to the device interfacing processor.).
Regarding Claim 11, BeSerra in view of Adriani (as stated above) is not relied upon to teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller.
Plesky teaches wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller (Plesky p. 5, Uniform Interfaces, para. 1, Perhaps one of the most fundamental aspects of RESTful systems is the uniform interface, […] Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra in view of Adriani (as stated above) further in view of Plesky, to explicitly teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller, because REST is a type of software architecture that was designed to ensure interoperability between different Internet computer systems, and services that conform to the REST architecture can more easily communicate with one another, especially in cases when clients and servers are acting independently but communicating through API as done in BeSerra.
Regarding Claim 12, BeSerra in view of Adriani and Plesky (as stated above) further teaches wherein the REST interface presents a portion of all available telemetry data available for the components, and does not present a second portion of the all available telemetry data available for the components (BeSerra Col. 7, Line 56, (49) A transmit component 350 may send some or all of the stored data to a requesting system. Only sending “some” data means there is data not sent. Also see Col. 5, Line 37, (36) In some cases, diagnostic data engine 100 may not have access to all available data for the relevant devices because obtaining all of this data would take too much time, would require too much storage space, or because some of the data has been determined to have a low likelihood of being relevant to the device of interest.).
Regarding Claim 13, BeSerra in view of Adriani and Plesky (as stated above) further teaches prior to obtaining the request:
identifying presence of the DDCED (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. The diagnostic data engine must be identified as present prior to obtaining a request, in order to ensure the request is reaching the proper destination);
enumerating universal resource identifiers presented by the REST interface (BeSerra Col. 6, Line 30, (43) In some embodiments, an application programming interface (API) may be provided to facilitate requests for diagnostic information. For example, an API can be called with information such as a device identifier, event type, and time frame that pertains to the diagnostic information. Also see Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. REST works by having its own self-contained identifiers); and
establishing a bridging interface for the DDCED based on the universal resource identifiers (Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. Note that. conceptually. resources are distinct from the results that are returned to a client. For example. no matter what the server's own method of storing data is. the data sent in answer to a request could be sent as anything from XML to HTML or even JSON. Also see p. 6, para. 2, Note that developers sometimes describe the APls that they create as complying with REST architecture even if these APls sometime skirt around the constraints imposed by RESTful architecture. REST is meant to work with the API to facilitate data transfer.).
Regarding Claim 14, BeSerra in view of Adriani and Plesky (as stated above) further teaches wherein bridging the request comprises:
making a second determination that the request specifies one of the universal resource identifiers (Plesky p. 5, Uniform Interfaces, para. 2, Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified. The request must be understood, and is constrained to contain the identifier of the resource of interest.); and
based on the second determination, forwarding the request to the guest management controller (BeSerra Col. 4, Line 21, (26) A request may be sent to a diagnostic data engine 100 for requesting, monitoring, accessing, receiving, storing, and analyzing diagnostics data pertaining to one or more of the servers 130 or resources 140. Also see (45) Users 210 of the service provider may access a user interface 220 for requesting diagnostic information. In some embodiments, the user interface 220 can be generated by functions implemented in software executing on one or more servers 230. The request one forwarded as dictated by the REST architecture is still eventually sent to the device interfacing processor.).
Regarding Claim 18, BeSerra in view of Adriani (as stated above) is not relied upon to teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller.
Plesky teaches wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller (Plesky p. 5, Uniform Interfaces, para. 1, Perhaps one of the most fundamental aspects of RESTful systems is the uniform interface, […] Requests must contain resource identifiers. As an example. a URI can be contained in a request to enable the resource to be identified.).
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the instant application, to modify BeSerra in view of Adriani (as stated above) further in view of Plesky, to explicitly teach wherein the interface is a universal resource identifier of a Representational State Transfer (REST) interface presented by the guest management controller, because REST is a type of software architecture that was designed to ensure interoperability between different Internet computer systems, and services that conform to the REST architecture can more easily communicate with one another, especially in cases when clients and servers are acting independently but communicating through API as done in BeSerra.
Regarding Claim 19, BeSerra in view of Adriani and Plesky (as stated above) further teaches wherein the REST interface presents a portion of all available telemetry data available for the components, and does not present a second portion of the all available telemetry data available for the components (BeSerra Col. 7, Line 56, (49) A transmit component 350 may send some or all of the stored data to a requesting system. Only sending “some” data means there is data not sent. Also see Col. 5, Line 37, (36) In some cases, diagnostic data engine 100 may not have access to all available data for the relevant devices because obtaining all of this data would take too much time, would require too much storage space, or because some of the data has been determined to have a low likelihood of being relevant to the device of interest.).
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 CHRISTIAN T BRYANT whose telephone number is (571)272-4194. The examiner can normally be reached Monday-Thursday and Alternate Fridays 7:00-4:30.
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, CATHERINE RASTOVSKI can be reached at 571-270-0349. 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.
/CHRISTIAN T BRYANT/Examiner, Art Unit 2863
1 Bigelow (What is edge computing? Everything you need to know, TechTarget, Search Data Center, Dec 08 2021)