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 .
DETAILED ACTION
This communication is responsive to Amendment filed 1/22/2026.
In Amendment, no claims are cancelled and no claims are added. Thus, claims 1-21 are pending in this application. This Office Action is made final.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 8-10 and 15-17 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Andrews (US 2015/0019199).
As per claim 1, Andrews discloses a computer-implemented method, comprising:
receiving, by a command line interface (CLI) backend and from a client CLI on a client computing device, a generic command request including a command and command input data from the client computing device (Fig. 6B, 612)
determining, by the CLI backend and based on command metadata associated with the command, a platform service for the command (Paragraph 89 “At step 614, the user command line instruction is converted into a device management instruction and further customized based on device attributes. In some embodiments, the conversion may be performed by a converter similar to converters 194, 220, 320, and 420 of FIGS. 1-4, respectively. In some embodiments, as described herein, the user command line instruction may be converted to a device management command type, such as into SNMP instructions, XML instruction or some other proprietary CLI instruction type, which may be further customized based on device attributes. In some embodiments, as described in FIGS. 1-4, the user command line instruction may be converted by querying a database, as described in FIG. 3.”);
mapping, by the CLI backend and based on the command metadata associated with the command, the command input data to a platform service application programming interface (API) associated with the platform service (Fig. 6B, 614);
calling, by the CLI backend, the platform service API based on the mapping (Fig. 6B, 616); and
returning, by the CLI backend and to the client CLI for execution in a local script engine, a client-side script defined for the generic command request together with response data received from the platform service API (Fig. 6B, 618).
As per claim 2, Andrews further discloses wherein mapping, by the CLI backend and based on the command metadata associated with the command, the command input data to a platform service API associated with the platform service, comprises:
using a platform-service-specific plugin of the CLI backend that provides functionality to transform command line input/output to/from the platform service application programming interface (Paragraph 3 “In some embodiments, the command line instructions disclosed herein may be a specific type of command line instructions that may, nevertheless be used to manage different devices in a network (e.g., manage devices that utilize the specific type of command line instructions and devices that do not utilize the specific type of command line instructions).
As per claim 3, Andrews further discloses comprising:
determining that the client-side script is defined for the generic command request (Paragraph 43).
As per claims 8-10, they are medium claims having similar limitations as cited in claims 1-3 and are rejected under the same rationale.
As per claims 15-17, they are system claims having similar limitations as cited in claims 1-3 and are rejected under the same rationale.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4-7, 11-14 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Andrews in view of Chheda (US 9,785,486).
As per claim 4, Andrews further discloses comprising:
receiving, by the client CLI and from the CLI backend, a client-side script defined for the generic command request together with response data received from the platform service API.
Andrews does not expressly disclose but Chheda discloses executing the client-side script in the local script engine, wherein the local script engine is sandboxed in the CLI on the client computing device (Column 12, lines 9-34).
Therefore it would have been obvious to one of ordinary skill in the art at the time of filing to modify the method of Andrews to include the teachings of Chheda because it provides a secure environment for scripts to run in isolation. In this way, the combination increases the security of the application.
As per claim 5, Andrews does not expressly disclose but Chheda discloses comprising:
providing, by the client CLI, two channels as input to the client-side script: 1) an input/output channel to a terminal of the client computing device and 2) an open channel to the CLI backend (Column 12, lines 35-55).
As per claim 6, Andrews does not expressly disclose but Chheda discloses wherein providing, by the client CLI, two channels as input to the client-side script: 1) an input/output channel to a terminal of the client computing device and 2) an open channel to the CLI backend, comprises:
using a connection manager on the CLI backend to provide a gateway to the platform service called for in the generic command request (Column 12, lines 35-55).
As per claim 7, Andrews does not expressly disclose but Chheda discloses wherein the open channel to the CLI backend allows the client-side script to continue communications with the platform service to forward additional user input, fetch additional data, or launch further actions (Column 12, lines 35-55).
As per claims 11-14, they are medium claims having similar limitations as cited in claims 4-7 and are rejected under the same rationale.
As per claims 18-21, they are system claims having similar limitations as cited in claims 4-7 and are rejected under the same rationale.
Response to Arguments
Applicant's arguments filed 1/22/2026 have been fully considered.
On pages 8-9, Applicant argues:
Applicant asserts that Andrews has also not been shown to disclosure a "local script engine," as in claim 1. Claim 1 requires the returned script to be "for execution in a local script engine." This limitation requires a specific structural component on the client device capable of parsing and executing code (e.g., a JavaScript engine), distinct from a standard display terminal. Andrews discloses a "session emulator module 192" (e.g., para. [0044], among others) that "creates a terminal session that emulates a login and connection-based session" (para. [0046]). This session emulator module 192 displays an "alphanumeric prompt" (paras. [0052] and [0087]) and acts as a dumb terminal interface for sending commands and receiving text. However, Andrews has not been shown to teach or to suggest a "script engine" or anything corresponding to a script engine on the client side, as in claim 1. Applicant asserts that a "terminal emulator" that displays text characters is not a "local script engine" capable of executing code, as in claim 1.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “a specific structural component on the client device capable of parsing and executing code (e.g., a JavaScript engine),”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The examiner respectfully submits that Andrews that Fig. 6B, 618 was cited to show the claimed returning step with less emphasis on the claimed local script engine. The local script engine can be fairly equated to the session emulator module 192 as it performs the steps required by the claim which are that client-side script defined for the generic command request together with response data received from the platform service API. See paragraph 89 “In some embodiments, the conversion may be performed by a converter similar to converters 194, 220, 320, and 420 of FIGS. 1-4, respectively. In some embodiments, as described herein, the user command line instruction may be converted to a device management command type, such as into SNMP instructions, XML instruction or some other proprietary CLI instruction type, which may be further customized based on device attributes.”
On pages 9, Applicant argues:
Andrews also has not been shown to determine a platform service based on command metadata, as in claim 1. Claim 1 requires "determining, by the CLI backend and based on command metadata associated with the command, a platform service for the command." Applicant asserts that Andrews appears directed to a fundamentally different mechanism where the target device is pre-selected by a user. As shown in FIG. 7, the user must explicitly "IDENTIFY DEVICES TO MANAGE DURING A TERMINAL SESSION" (e.g., selecting "All Devices" or a specific device) The backend in Andrews then appears to use a database (FIG. 3) merely to translate the command into the specific protocol (e.g., SNMP VS. XML) required by that user-selected device (see, e.g., paras. [0066] and [0067]). In other words, Andrews appears to show protocol translation for a known, user-selected hardware device, but not "determining a platform service based on command metadata," as in claim 1. Andrew's routing logic appears to be user-driven (e.g., device selection), whereas claim 1 requires a metadata-driven service determination.
The examiner respectfully submits paragraph 89 discloses that in “some embodiments, as described herein, the user command line instruction may be converted to a device management command type, such as into SNMP instructions, XML instruction or some other proprietary CLI instruction type, which may be further customized based on device attributes.” This shows that the received instruction may be converted based on the device attributes required by the message (ie, claimed determining).
Conclusion
THIS ACTION IS MADE FINAL. 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 TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central Time.
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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198 3/05/2026