DETAILED ACTION
This office action is in response to amendment filed on 8/12/2026.
Claims 1, 17 and 19 are amended.
Claims 1 – 20 are pending.
35 USC 101 rejection of claims 1 – 16 are withdrawn in view of the amendment.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
Claim(s) 1 – 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Periyaeluvan et al (US 20220030300, hereinafter Periyaeluvan), in view of Elliot et al (US 20210271500, hereinafter Elliot), and further in view of Tsai et al (US 20100161803, hereinafter Tsai).
As per claim 1, Periyaeluvan discloses: A computer program product comprising a non-transitory computer readable medium and non-transitory program instructions embodied therein, the program instructions being configured to be executable by a service processor of a server to cause the service processor to perform operations comprising:
receiving a stream of serial data directed to be output through service processor, wherein the stream of serial data identifies a plurality of parameters and a value for each of the parameters; (Periyaeluvan [0033]: “The STB 220 reserves (at step 4) a streaming session context and may also start the AV transcoding Media engine and start sending data to the client-1 (210). At step 6, the streaming data is sent continuously from the STB (220) to the client-1 (210).”; [0023]: “During a given streaming video session, streaming media server 22 encodes, packetizes, and transmits streaming video content over communications network 26 to client media receiver 24. The streaming video content will typically, but need not necessarily include accompanying audio content.”. Examiner note that STB 220 is mapped to the claimed service processor, and streaming video content would inherently include the claimed “a plurality of parameters and a value for each of the parameters”.)
maintaining a virtual terminal state based on the stream of serial data in the absence of an active connection of a client computer to the [service processor], wherein the virtual terminal state includes a most-recently received value for each of the plurality of parameters; storing and updating the virtual terminal state in a screen buffer of the service processor; (Periyaeluvan [0033]: “Next, the client at step 7, the client app exits, for example, this can occur for a number of reasons including the client “kills” the session or there is a forced disconnect caused by a stoppage of the streaming data, a crash of the app, reset of the app, etc. At step 8, the STB identifies the client app has exited the reserved session. Still, the STB continues to produce the AV transcode data (i.e., the backfill data) in the same manner for a limited time with the presumption that the client is available for a timeout (in this case, as an example a “15” minute timeout).”)
and outputting the virtual terminal state stored in the screen buffer through the virtual serial port to a client computer in response to detecting that the client computer has formed a new connection to the [service processor]. (Periyaeluvan [0033]: “At step 9, the client initiates a connect back type of request for the control connection to execute a replay of the streamed content. At step 10, the STB creates another session and links the existing connection request. At step 11, the STB 220 sends a control connection request success notification to the client-1 (210). The client, in response at step 13, initiates another streaming request. At step 12, the STB continues to send the streaming data from the previous streaming session (without pausing or stoppage of the transcoding engine, which reduces the latency that would normally occur at the start when the client app exits and resumes again). In other words, by storing the prior streaming segment that occurs in the exit and resumption steps of the client app, the delay, or latency in the time to restart and reconnect or resume, the streaming is either reduced or eliminated.”)
Periyaeluvan did not explicitly teach:
wherein the service processor comprises a virtual serial port;
wherein the stream of serial data reflecting the operation of the server;
However, Elliot teaches:
wherein the service processor comprises a virtual serial port; (Elliot figure 1A, [0015] and [0019]: “virtual serial port”.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Elliot into that of Periyaeluvan in order to have the service processor comprises a virtual serial port. Periyaeluvan figure 3 and [0033] teaches the STB performs the decoding and communication on behalf of client. Elliot figure 1A, [0015] and [0019] has shown that the concept of virtualize a data communication device is commonly known and used in the field as the advantage of virtualization, such as being underlying hardware agnostic, can be easily applied to improve similar technologies such as streaming video content, thus applicant have merely claimed the combination of known parts in the field to achieve the predictable results of virtualize the communication system and is therefore rejected under 35 USC 103.
Tsai teaches:
wherein the stream of serial data reflecting the operation of the server; (Tsai [0009])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Tsai into that of Periyaeluvan and Elliot in order to have the service processor comprises a virtual serial port. Periyaeluvan figure [0023] teaches the streaming data to be video streaming data, however, one of ordinary skill in the art can easily see that other form of stream of serial data may be applied here to reap the benefit of the scheduling system, such as monitoring data of the server, thus applicant have merely claimed the combination of known parts in the field to achieve the predictable results of virtualize the communication system and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, the operations further comprising: after outputting the virtual terminal state, forwarding any additional serial data received in the stream to the client computer through the connection to the virtual serial port in the order received without updating the virtual terminal state. (Periyaeluvan [0033]: “At step 9, the client initiates a connect back type of request for the control connection to execute a replay of the streamed content. At step 10, the STB creates another session and links the existing connection request. At step 11, the STB 220 sends a control connection request success notification to the client-1 (210). The client, in response at step 13, initiates another streaming request. At step 12, the STB continues to send the streaming data from the previous streaming session (without pausing or stoppage of the transcoding engine, which reduces the latency that would normally occur at the start when the client app exits and resumes again). In other words, by storing the prior streaming segment that occurs in the exit and resumption steps of the client app, the delay, or latency in the time to restart and reconnect or resume, the streaming is either reduced or eliminated.”)
As per claim 3, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, the operations further comprising: buffering additional serial data directed to the virtual serial port while the virtual terminal state stored in the screen buffer is being output to the virtual terminal program of the client computer; and then providing the virtual terminal program of the client computer with the buffered serial data in the order received. (Periyaeluvan [0033]: “Next, the client at step 7, the client app exits, for example, this can occur for a number of reasons including the client “kills” the session or there is a forced disconnect caused by a stoppage of the streaming data, a crash of the app, reset of the app, etc. At step 8, the STB identifies the client app has exited the reserved session. Still, the STB continues to produce the AV transcode data (i.e., the backfill data) in the same manner for a limited time with the presumption that the client is available for a timeout (in this case, as an example a “15” minute timeout). At step 9, the client initiates a connect back type of request for the control connection to execute a replay of the streamed content. At step 10, the STB creates another session and links the existing connection request. At step 11, the STB 220 sends a control connection request success notification to the client-1 (210). The client, in response at step 13, initiates another streaming request. At step 12, the STB continues to send the streaming data from the previous streaming session (without pausing or stoppage of the transcoding engine, which reduces the latency that would normally occur at the start when the client app exits and resumes again). In other words, by storing the prior streaming segment that occurs in the exit and resumption steps of the client app, the delay, or latency in the time to restart and reconnect or resume, the streaming is either reduced or eliminated.”)
As per claim 4, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 3, wherein the additional serial data is buffered in a separate buffer other than the screen buffer. (Elliot [0076])
As per claim 5, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, the operations further comprising: temporarily ceasing to maintain the virtual terminal state for the duration of the active connection of the client computer to the virtual serial port. (Periyaeluvan [0033]: “Next, the client at step 7, the client app exits, for example, this can occur for a number of reasons including the client “kills” the session or there is a forced disconnect caused by a stoppage of the streaming data, a crash of the app, reset of the app, etc. At step 8, the STB identifies the client app has exited the reserved session. Still, the STB continues to produce the AV transcode data (i.e., the backfill data) in the same manner for a limited time with the presumption that the client is available for a timeout (in this case, as an example a “15” minute timeout). At step 9, the client initiates a connect back type of request for the control connection to execute a replay of the streamed content. At step 10, the STB creates another session and links the existing connection request. At step 11, the STB 220 sends a control connection request success notification to the client-1 (210). The client, in response at step 13, initiates another streaming request. At step 12, the STB continues to send the streaming data from the previous streaming session (without pausing or stoppage of the transcoding engine, which reduces the latency that would normally occur at the start when the client app exits and resumes again). In other words, by storing the prior streaming segment that occurs in the exit and resumption steps of the client app, the delay, or latency in the time to restart and reconnect or resume, the streaming is either reduced or eliminated.”)
As per claim 6, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, the operations further comprising: continuing to maintain the virtual terminal state during the active connection of the client computer to the virtual serial port. (Periyaeluvan [0033])
As per claim 7, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein outputting the virtual terminal state stored in the screen buffer includes converting the virtual terminal state stored in the screen buffer into a serial port byte stream. (Elliot [0048])
As per claim 8, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the service processor is a baseboard management controller. (Elliot figure 1A, [0015] and [0019])
As per claim 9, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the virtual terminal state that is output from the screen buffer enables the client computer to display a user interface accurately reflecting the stream of serial data. (Periyaeluvan [0033]: “At step 9, the client initiates a connect back type of request for the control connection to execute a replay of the streamed content. At step 10, the STB creates another session and links the existing connection request. At step 11, the STB 220 sends a control connection request success notification to the client-1 (210). The client, in response at step 13, initiates another streaming request. At step 12, the STB continues to send the streaming data from the previous streaming session (without pausing or stoppage of the transcoding engine, which reduces the latency that would normally occur at the start when the client app exits and resumes again). In other words, by storing the prior streaming segment that occurs in the exit and resumption steps of the client app, the delay, or latency in the time to restart and reconnect or resume, the streaming is either reduced or eliminated.”)
As per claim 10, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the virtual terminal stores data in the screen buffer as if the virtual terminal was a physical terminal that had been connected to the virtual serial port to receive the stream of serial data. (Periyaeluvan [0033])
As per claim 11, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the virtual terminal state includes values necessary to render one or more frame of a screen without storing stale values that will not be rendered on the screen. (Periyaeluvan [0033])
As per claim 12, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the client computer runs a virtual terminal program that receives the virtual terminal state through the new connection with the virtual serial port to render a user interface as if the client computer had been connected to the virtual serial port for an arbitrarily long period of time. (Periyaeluvan [0033])
As per claim 13, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the operation of maintaining a virtual terminal state based on the stream of serial data includes: identifying a parameter and a new value for the parameter in the stream of serial data; and overwriting a previously stored value for the parameter in the screen buffer with the new value for the parameter. (Periyaeluvan [0033])
As per claim 14, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the virtual terminal continuously updates the values of each of the parameters stored in the screen buffer to only store the most-recently received value for each of the parameters. (Periyaeluvan [0033])
As per claim 15, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the service processor includes memory that is used for the screen buffer. (Periyaeluvan figure 1.)
As per claim 16, the combination of Periyaeluvan, Elliot and Tsai further teach:
The computer program product of claim 1, wherein the stream of serial data includes data sent to the serial port by the operating system of the baseboard management controller, an operating system of the server, an application running on the baseboard management controller and/or an application running on the server. (Elliot figure 1A, [0015] and [0019])
As per claim 17, it is the system variant of claim 1 and is therefore rejected under the same rationale. (Periyaeluvan figure 1.)
As per claim 18, it is the system variant of claim 2 and is therefore rejected under the same rationale.
As per claim 19, it is the method variant of claim 1 and is therefore rejected under the same rationale.
As per claim 20, the combination of Periyaeluvan, Elliot and Tsai further teach:
The method of claim 19, wherein outputting the virtual terminal state stored in the screen buffer includes converting the virtual terminal state stored in the screen buffer into a second stream of serial data, further comprising: a virtual terminal program that is running on the client computer receiving the second stream of serial data through the new connection to the virtual serial port and causing a user interface containing the virtual terminal state to be displayed. (Periyaeluvan [0033])
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 – 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196