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 .
This office action is responsive to a response filed on April 23rd, 2026. In this office action:
Claims 1-11, 15-16, and 19-25 are pending.
Claims 1-11, 15-16, and 19-25 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on January 23rd, 2026,
Claims 1-11 were objected to because of informalities.
Claims 1-8, 10-11, 15-16, and 19-25 were rejected under 35 U.S.C. 103 as being unpatentable over Baker (Pub. No. US 2021/0250195); in view of Kunieda (Pub. No. US 2018/0052837).
Claim 9 was rejected under 35 U.S.C. 103 as being unpatentable over Baker (Pub. No. US 2021/0250195); in view of Kunieda (Pub. No. US 2018/0052837); and further in view of Maistri et al. (Pub. No. US 2017/0237784), hereinafter Maistri.
Response to Amendment
The Amendments filed on April 23rd, 2026 have been entered.
Claims 1-11 have been amended.
The previously raised claim objections are withdrawn in light of the amendments.
Response to Arguments
Applicant’s arguments/remarks filed on April 23rd, 2026 have been considered but are moot in view of the new ground(s) of rejection, as presented in this office action. The Examiner’s interpretation has changed based on the Applicant’s amendments, see 35 USC § 103 below.
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 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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-8, 10-11, 15-16, and 19-25 are rejected under 35 U.S.C. 103 as being unpatentable over Baker (Pub. No. US 2021/0250195); in view of Tzeng et al. (Pub. No. US 2015/0063375), hereinafter Tzeng.
Claim 1. Baker discloses [a] multi-user multimedia control method, applied to a first client, the multi-user multimedia control method (See Parag. [0030]; enables video content that is being shared during the communication session 128 to be played synchronously (e.g., at substantially the same playhead position 122) across numerous different client devices 114 that are being used to participate in the communication session 128) comprising:
sending time information to the second client, such that the second client aligns its time with that of the first client (“presenter”) based on the time information, wherein there is at least one second client, and the multimedia sharing is an interactive function among a plurality of clients (See Parag. [0087]; transmits latency play instructions to the client devices based on the latency data; the manner in which the latency play instructions are transmitted to the client devices (at least one second client/ a plurality of clients) may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data (multimedia sharing) to begin synchronously (aligns the time) across the plurality of client devices. For example, the individual latency play instructions may include a latency delay value (time information) that prescribes an amount of time that the individual client devices are to wait, after receiving the corresponding latency play instruction, before initiating playback of the media content that is obtained via the media streams. See Parag. [0110-0115] and Fig. 6; “screen sharing data;” “imitates an environment experience that the presenter and the individual may be sharing.” See also Parag. [0081]);
in response to receiving at least two control instructions carrying instruction times within a preset time, determining a target control instruction based on each instruction time, wherein the at least two control instructions are configured to perform control operations on the multimedia, and the instruction times are sending times of the at least two control instructions (See Parag. [0047-0048]; By adhering to the latency delays 126 indicated within their respective latency play instructions 134, each of the first client device 114(1) through the Nth client device 114(N) are caused to begin playing the video content at the appropriate playback position 122 at precisely the same moment notwithstanding the different networking latencies experienced at the different client devices 114. To convey this point illustratively, each of the first media status 120(1) through the Nth media status 120(N) are shown to have been toggled to “play” at precisely the fifth time T.sub.5. Thus, in contrast to conventional screen sharing techniques as described above, the playback position 122 at which the video content is being played is constant across all the client devices 114 (rather than being out-of-sync due to variations of networking latency) ... scenario of a pause instruction 136 being generated at an individual client device 114 to cause playback of the video content that is being shared during the communication session 128 to be paused at precisely the same playhead position 122 across all of the client devices 114 being used to participate in the communication session 128. In the illustrated scenario, the pause instruction 136 is initially generated at a sixth time T.sub.6 based on user input that is received at the Nth client device 114(N) when the video content is at a second playhead position 122(2). For purposes of the present discussion, presume that that second playhead position 122(2) (e.g., at which a participant whom is using the Nth client device 114(N) pauses the video content) corresponds to “Frame 100” of the video content. Thus, at the sixth time T.sub.6 the Nth media status 120(N) toggles from “play” to “pause” precisely at the second playhead position 122(2). Furthermore, at the sixth time T.sub.6, the Nth client device 114(N) transmits the pause instruction 136 to the server devices 102. It will be appreciated that since T.sub.6 corresponds to the moment at which the pause instruction 136 is sent from the Nth client device 114(N) but is prior to the pause instruction 136 being relayed to either of the first client device 114(1) or the Nth client device 114(N), at the sixth time T.sub.6 the video content will still be being played at the first and second client devices. See also Parag. [0083-0084]. Examiner’s interpretation: The Examiner has interpreted the claimed “at least two control instructions” to be equivalent to play and pause instructions);
performing a corresponding control operation on a target multimedia corresponding to the target control instruction, and sending the target control instruction to the second client, such that the second client synchronously performs the same corresponding control operation on the target multimedia (See Parag. [0086-0087]; ... the user may adjust the playhead position of the media content at the particular client device to a desired playhead position before providing user input to cause all of the other client devices to begin playback of the media content at the desired playhead position (a target multimedia); the user play instruction (control operation) may include an indication of the desired playhead position at which the media content is to begin playing synchronously across all of the client devices 114 (the second client) ... in response to the user play instruction, the system transmits latency play instructions to the client devices based on the latency data. As described above, the manner in which the latency play instructions are transmitted to the client devices may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data to begin synchronously across the plurality of client devices (the second client synchronously performs the same control operation on the target multimedia)).
Baker discloses that time alignment is performed in response to a multimedia sharing joining operation (See Parag. [0080-0081] and Fig. 5), but Baker doesn’t explicitly disclose acquiring a time alignment request, which is sent by a second client, and wherein the time information is a time when the time alignment request is received by the first client.
However, Tzeng discloses acquiring a time alignment request, which is sent by a second client (See Parag. [0018-0019]; peer-to-peer message exchange involves two nodes: a first peer node 102.1 having a first clock (CLOCK1) and a second peer node 102.2 having a second clock (CLOCK2) to be synchronized with the first clock of the first peer node 102.1 ... the second peer node 102.2 generating and transmitting a delay request (DELAY_REQ) packet 116 (a time alignment request) to the first peer node 102.1 ...), and sending time information to the second client, such that the second client aligns its time with that of the first client based on the time information, and wherein the time information is a time when the time alignment request is received by the first client (See Parag. [0022-0026]; When the DELAY_REQ packet 116 reaches the first peer node 102.1, the first peer node 102.1 can be configured to generate a timestamp T2 (time information) upon ingress of the DELAY_REQ packet 116. The timestamp T2 represents the ingress start of packet time for the DELAY_REQ packet 116 at the first peer node 102.1 ... the peer node 102.1 can be configured to generate and transmit a delay response packet "DELAY_RSP packet” 120 to the peer node 120.2. The DELAY_RSP packet 120 can be generated in response to the receipt of the of DELAY_REQ packet 116. In operation, the peer node 102.1 can be configured to generate a timestamp T3 upon the egress of the DELAY_RSP packet 120 from the peer node 102.1 to the peer node 102.2. The timestamp T3 represents the egress start of packet time of the DELAY_RSP packet 120. The DELAY_RSP packet 120 can include the timestamp T3 and/or timestamp T2 ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the time alignment, taught by Baker, to include acquiring a time alignment request, which is sent by a second client, and wherein the time information is a time when the time alignment request is received by the first client, as taught by Tzeng. This would be convenient to improve network performance (Tzeng, Parag. [0012]).
Claim 2. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 1,
Baker further discloses wherein determining the target control instruction based on each instruction time comprises:
comparing the instruction times of the at least two control instructions, and determining a control instruction with the latest instruction time as the target control instruction based on the comparison result (See Parag. [0047-0048]; By adhering to the latency delays 126 indicated within their respective latency play instructions 134, each of the first client device 114(1) through the Nth client device 114(N) are caused to begin playing the video content at the appropriate playback position 122 at precisely the same moment notwithstanding the different networking latencies experienced at the different client devices 114. To convey this point illustratively, each of the first media status 120(1) through the Nth media status 120(N) are shown to have been toggled to “play” at precisely the fifth time T.sub.5. Thus, in contrast to conventional screen sharing techniques as described above, the playback position 122 at which the video content is being played is constant across all the client devices 114 (rather than being out-of-sync due to variations of networking latency) ... scenario of a pause instruction 136 being generated at an individual client device 114 to cause playback of the video content that is being shared during the communication session 128 to be paused at precisely the same playhead position 122 across all of the client devices 114 being used to participate in the communication session 128. In the illustrated scenario, the pause instruction 136 is initially generated at a sixth time T.sub.6 based on user input that is received at the Nth client device 114(N) when the video content is at a second playhead position 122(2). For purposes of the present discussion, presume that that second playhead position 122(2) (e.g., at which a participant whom is using the Nth client device 114(N) pauses the video content) corresponds to “Frame 100” of the video content. Thus, at the sixth time T.sub.6 the Nth media status 120(N) toggles from “play” to “pause” precisely at the second playhead position 122(2). Furthermore, at the sixth time T.sub.6, the Nth client device 114(N) transmits the pause instruction 136 to the server devices 102. It will be appreciated that since T.sub.6 corresponds to the moment at which the pause instruction 136 is sent from the Nth client device 114(N) but is prior to the pause instruction 136 being relayed to either of the first client device 114(1) or the Nth client device 114(N), at the sixth time T.sub.6 the video content will still be being played at the first and second client devices. Examiner’s interpretation: The Examiner has interpreted the claimed “at least two control instructions” to be equivalent to play and pause instructions).
Claim 3. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 1,
Baker further discloses wherein, after the time of the second client is aligned with that of the first client, the instruction times of the at least two control instructions are located on a same timeline (See Parag. [0047-0048]; By adhering to the latency delays 126 indicated within their respective latency play instructions 134, each of the first client device 114(1) through the Nth client device 114(N) are caused to begin playing the video content at the appropriate playback position 122 at precisely the same moment notwithstanding the different networking latencies experienced at the different client devices 114. To convey this point illustratively, each of the first media status 120(1) through the Nth media status 120(N) are shown to have been toggled to “play” at precisely the fifth time T.sub.5. Thus, in contrast to conventional screen sharing techniques as described above, the playback position 122 at which the video content is being played is constant across all the client devices 114 (rather than being out-of-sync due to variations of networking latency) ... scenario of a pause instruction 136 being generated at an individual client device 114 to cause playback of the video content that is being shared during the communication session 128 to be paused at precisely the same playhead position 122 across all of the client devices 114 being used to participate in the communication session 128. In the illustrated scenario, the pause instruction 136 is initially generated at a sixth time T.sub.6 based on user input that is received at the Nth client device 114(N) when the video content is at a second playhead position 122(2). For purposes of the present discussion, presume that that second playhead position 122(2) (e.g., at which a participant whom is using the Nth client device 114(N) pauses the video content) corresponds to “Frame 100” of the video content. Thus, at the sixth time T.sub.6 the Nth media status 120(N) toggles from “play” to “pause” precisely at the second playhead position 122(2). Furthermore, at the sixth time T.sub.6, the Nth client device 114(N) transmits the pause instruction 136 to the server devices 102. It will be appreciated that since T.sub.6 corresponds to the moment at which the pause instruction 136 is sent from the Nth client device 114(N) but is prior to the pause instruction 136 being relayed to either of the first client device 114(1) or the Nth client device 114(N), at the sixth time T.sub.6 the video content will still be being played at the first and second client devices. Examiner’s interpretation: The Examiner has interpreted the claimed “at least two control instructions” to be equivalent to play and pause instructions).
Claim 4. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 1,
Baker further discloses wherein, after determining the target control instruction based on each instruction time, the multi-user multimedia control method further comprises:
in response to a sending end of the target control instruction being the first client, sending a rejection instruction to the second client among clients corresponding to the at least two control instructions (Parag. [0043]; the latency delays 126 that are defined within the individual latency play instructions 134 may indicate amounts of time that the receiving client devices 114 are to wait (e.g., after receiving the latency play instruction 134) before playing the video content. In this way, individual client devices 114 which are experiencing less networking latency than other client devices 114 may be instructed to wait an appropriate amount of time before playing the video content in order to allow enough time for all of the client devices 114 to receive a corresponding media stream 132. Thus, rather than each individual client device 114 starting to play the video content immediately upon receiving the video content (which would likely result in asynchronous playback of the video content), the individual client devices 114 may be caused to wait until all of the other client devices have also received the video content).
Claim 5. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 1,
Baker further discloses wherein the preset time is a time period for the first client to determine the target control instruction (See Parag. [0083-0084]; ... the latency monitor 110 may be configured to periodically transmit pings to the individual client devices according to some predefined interval such as, for example, 1 second, 2 seconds, or any other suitable interval of time. Then, as the pings are echoed back to the latency monitor 110 by the individual client devices, the most recently calculated latency values may be added to the LIFO Database while the oldest values may be deleted. See Parag. [0047-0048]).
Claim 6. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 1,
Baker further discloses wherein the control operation includes at least one of a play operation, a pause operation, a progress control operation and an interactive operation (See Parag. [0086-0087]; ... the user play instruction (control operation) may include an indication of the desired playhead position at which the media content is to begin playing synchronously across all of the client devices 114), and the multimedia includes a video, a media file composed of at least one of images or texts and supporting playback (See Parag. [0110]; media streams can comprise a video feed, audio data which is to be output with a presentation of an avatar of a user, text data (e.g., text messages), file data and/or screen sharing data (e.g., a document, a slide deck, an image, a video displayed on a display screen, etc.), and so forth. See Parag. [0009]; the user may select a “play” or “share” command in association with the video to cause all of the other client devices to begin playback of the video at the desired playhead position).
Claim 7. Baker discloses [a] multi-user multimedia control method, applied to a second client, the multi-user multimedia control method (See Parag. [0030]; enables video content that is being shared during the communication session 128 to be played synchronously (e.g., at substantially the same playhead position 122) across numerous different client devices 114 that are being used to participate in the communication session 128) comprising:
acquiring time information returned by the first client; aligning time of the second client with that of the first client based on the time information (See Parag. [0087]; transmits latency play instructions to the client devices based on the latency data; the manner in which the latency play instructions are transmitted to the client devices (second client) may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data to begin synchronously (aligns the time) across the plurality of client devices. For example, the individual latency play instructions may include a latency delay value (time information) that prescribes an amount of time that the individual client devices are to wait, after receiving the corresponding latency play instruction, before initiating playback of the media content that is obtained via the media streams. See Parag. [0110-0115] and Fig. 6; “screen sharing data;” “imitates an environment experience that the presenter and the individual may be sharing.” See also Parag. [0081]);
sending a control instruction carrying instruction time to the first client in response to a control triggering operation, such that the first client, in response to receiving at least two control instructions carrying instruction times within a preset time, determines a target control instruction based on each instruction time, and performs a corresponding control operation on a target multimedia corresponding to the target control instruction, wherein the control instruction is configured to perform a control operation on the multimedia, and the instruction time is a sending time of the control instruction (See Parag. [0047-0048]; By adhering to the latency delays 126 indicated within their respective latency play instructions 134, each of the first client device 114(1) through the Nth client device 114(N) are caused to begin playing the video content at the appropriate playback position 122 at precisely the same moment notwithstanding the different networking latencies experienced at the different client devices 114. To convey this point illustratively, each of the first media status 120(1) through the Nth media status 120(N) are shown to have been toggled to “play” at precisely the fifth time T.sub.5. Thus, in contrast to conventional screen sharing techniques as described above, the playback position 122 at which the video content is being played is constant across all the client devices 114 (rather than being out-of-sync due to variations of networking latency) ... scenario of a pause instruction 136 being generated at an individual client device 114 to cause playback of the video content that is being shared during the communication session 128 to be paused at precisely the same playhead position 122 across all of the client devices 114 being used to participate in the communication session 128. In the illustrated scenario, the pause instruction 136 is initially generated at a sixth time T.sub.6 based on user input that is received at the Nth client device 114(N) when the video content is at a second playhead position 122(2). For purposes of the present discussion, presume that that second playhead position 122(2) (e.g., at which a participant whom is using the Nth client device 114(N) pauses the video content) corresponds to “Frame 100” of the video content. Thus, at the sixth time T.sub.6 the Nth media status 120(N) toggles from “play” to “pause” precisely at the second playhead position 122(2). Furthermore, at the sixth time T.sub.6, the Nth client device 114(N) transmits the pause instruction 136 to the server devices 102. It will be appreciated that since T.sub.6 corresponds to the moment at which the pause instruction 136 is sent from the Nth client device 114(N) but is prior to the pause instruction 136 being relayed to either of the first client device 114(1) or the Nth client device 114(N), at the sixth time T.sub.6 the video content will still be being played at the first and second client devices. Examiner’s interpretation: The Examiner has interpreted the claimed “control instructions” to be equivalent to play and pause instructions);
receiving the target control instruction and performing the same corresponding control operation as the first client on the target multimedia (See Parag. [0086-0087]; ... the user may adjust the playhead position of the media content at the particular client device to a desired playhead position before providing user input to cause all of the other client devices to begin playback of the media content at the desired playhead position (a target multimedia); the user play instruction (control operation) may include an indication of the desired playhead position at which the media content is to begin playing synchronously across all of the client devices 114 (the second client) ... in response to the user play instruction, the system transmits latency play instructions to the client devices based on the latency data. As described above, the manner in which the latency play instructions are transmitted to the client devices may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data to begin synchronously across the plurality of client devices).
Baker discloses that time alignment is performed in response to a multimedia sharing joining operation (See Parag. [0080-0081] and Fig. 5), but Baker doesn’t explicitly disclose sending a time alignment request to a first client, and wherein the time information is a time when the time alignment request is received by the first client.
However, Tzeng discloses sending a time alignment request to a first client (See Parag. [0018-0019]; peer-to-peer message exchange involves two nodes: a first peer node 102.1 having a first clock (CLOCK1) and a second peer node 102.2 having a second clock (CLOCK2) to be synchronized with the first clock of the first peer node 102.1 ... the second peer node 102.2 generating and transmitting a delay request (DELAY_REQ) packet 116 (a time alignment request) to the first peer node 102.1 ...), acquiring time information returned by the first client; aligning time of the second client with that of the first client based on the time information, and wherein the time information is a time when the time alignment request is received by the first client (See Parag. [0022-0026]; When the DELAY_REQ packet 116 reaches the first peer node 102.1, the first peer node 102.1 can be configured to generate a timestamp T2 (time information) upon ingress of the DELAY_REQ packet 116. The timestamp T2 represents the ingress start of packet time for the DELAY_REQ packet 116 at the first peer node 102.1 ... the peer node 102.1 can be configured to generate and transmit a delay response packet "DELAY_RSP packet” 120 to the peer node 120.2. The DELAY_RSP packet 120 can be generated in response to the receipt of the of DELAY_REQ packet 116. In operation, the peer node 102.1 can be configured to generate a timestamp T3 upon the egress of the DELAY_RSP packet 120 from the peer node 102.1 to the peer node 102.2. The timestamp T3 represents the egress start of packet time of the DELAY_RSP packet 120. The DELAY_RSP packet 120 can include the timestamp T3 and/or timestamp T2 ... See Parag. [0040]; upon receiving the DELAY_RSP_FOLLOW_UP packet 122, the peer node 102.2 has received timestamps T2 and T3, and has the previously generated timestamps T1 and T4. Based upon these timestamps, the peer node 102.2 can be configured to synchronize (e.g., sync clock 124) the second clock (CLOCK2) of the peer node 102.2 with the first clock (CLOCK1) of the peer node 102.1 ... See also Fig. 1A).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the time alignment, taught by Baker, to include sending a time alignment request to a first client, and wherein the time information is a time when the time alignment request is received by the first client, as taught by Tzeng. This would be convenient to improve network performance (Tzeng, Parag. [0012]).
Claim 8. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 7,
Tzeng further discloses:
wherein the time alignment request includes a first time when the request is sent (See Parag. [0019]; the message exchange begins with the second peer node 102.2 generating and transmitting a delay request (DELAY_REQ) packet 116 to the first peer node 102.1. The DELAY_REQ packet 116 can include a timestamp T1 that represents the time that the DELAY_REQ packet 116 was transmitted by the second peer node 102.2 onto the network (e.g., the egress start of packet time). The timestamp T1 can be included in, for example, the body of the DELAY_REQ packet 116), and the time information includes a second time when the first client receives the time alignment request; aligning the time of the second client with that of the first client based on the time information comprises: determining a delay between the second client and the first client based on the first time, the second time, a third time when the time information is received, and a delay formula; adding the delay to a real time of the second client to achieve time alignment with the first client (See Parag. [0022-0026]; When the DELAY_REQ packet 116 reaches the first peer node 102.1, the first peer node 102.1 can be configured to generate a timestamp T2 (time information) upon ingress of the DELAY_REQ packet 116. The timestamp T2 represents the ingress start of packet time for the DELAY_REQ packet 116 at the first peer node 102.1 ... the peer node 102.1 can be configured to generate and transmit a delay response packet "DELAY_RSP packet” 120 to the peer node 120.2. The DELAY_RSP packet 120 can be generated in response to the receipt of the of DELAY_REQ packet 116. In operation, the peer node 102.1 can be configured to generate a timestamp T3 upon the egress of the DELAY_RSP packet 120 from the peer node 102.1 to the peer node 102.2. The timestamp T3 represents the egress start of packet time of the DELAY_RSP packet 120. The DELAY_RSP packet 120 can include the timestamp T3 and/or timestamp T2 ... See Parag. [0040]; upon receiving the DELAY_RSP_FOLLOW_UP packet 122, the peer node 102.2 has received timestamps T2 and T3, and has the previously generated timestamps T1 and T4. Based upon these timestamps, the peer node 102.2 can be configured to synchronize (e.g., sync clock 124) the second clock (CLOCK2) of the peer node 102.2 with the first clock (CLOCK1) of the peer node 102.1 ... See also Fig. 1A).
Claim 10. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 7,
Baker further discloses wherein aligning the time of the second client with that of the first client is executed a preset number of times every set time (See Parag. [0083-0084]; determining the latency values for individual ones of the client devices includes periodically pinging the individual client devices and measuring an amount of time that it takes for the pings to be returned to (e.g., echoed back to) the sending device from the receiving device ... the latency monitor 110 may repeatedly calculate and re-calculate the latency values for the individual client devices based on a sequence of latency values that are stored in a Last-In-First-Out (LIFO) Database. For example, the latency monitor 110 may be configured to periodically transmit pings to the individual client devices according to some predefined interval such as, for example, 1 second, 2 seconds, or any other suitable interval of time).
Claim 11. Baker discloses [a] multi-user multimedia control method, applied to a system including a first client and at least one second client (See Parag. [0030]; enables video content that is being shared during the communication session 128 to be played synchronously (e.g., at substantially the same playhead position 122) across numerous different client devices 114 that are being used to participate in the communication session 128), the multi-user multimedia control method comprising:
sending time information to the second client; aligning, by the second client, time of the second client with that of the first client based on the time information (See Parag. [0087]; transmits latency play instructions to the client devices based on the latency data; the manner in which the latency play instructions are transmitted to the client devices (second client) may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data to begin synchronously (aligns the time) across the plurality of client devices. For example, the individual latency play instructions may include a latency delay value (time information) that prescribes an amount of time that the individual client devices are to wait, after receiving the corresponding latency play instruction, before initiating playback of the media content that is obtained via the media streams. See Parag. [0110-0115] and Fig. 6; “screen sharing data;” “imitates an environment experience that the presenter and the individual may be sharing.” See also Parag. [0081]), and sending a control instruction carrying an instruction time to the first client in response to a control trigger operation, wherein the control instruction is configured to perform a control operation on the multimedia, and the instruction time is a sending time of the control instruction; determining, by the first client in response to receiving at least two control instructions carrying instruction times within a preset time, a target control instruction based on each instruction time, and performing a corresponding control operation on a target multimedia corresponding to the target control instruction, sending the target control instruction to the second client (See Parag. [0047-0048]; By adhering to the latency delays 126 indicated within their respective latency play instructions 134, each of the first client device 114(1) through the Nth client device 114(N) are caused to begin playing the video content at the appropriate playback position 122 at precisely the same moment notwithstanding the different networking latencies experienced at the different client devices 114. To convey this point illustratively, each of the first media status 120(1) through the Nth media status 120(N) are shown to have been toggled to “play” at precisely the fifth time T.sub.5. Thus, in contrast to conventional screen sharing techniques as described above, the playback position 122 at which the video content is being played is constant across all the client devices 114 (rather than being out-of-sync due to variations of networking latency) ... scenario of a pause instruction 136 being generated at an individual client device 114 to cause playback of the video content that is being shared during the communication session 128 to be paused at precisely the same playhead position 122 across all of the client devices 114 being used to participate in the communication session 128. In the illustrated scenario, the pause instruction 136 is initially generated at a sixth time T.sub.6 based on user input that is received at the Nth client device 114(N) when the video content is at a second playhead position 122(2). For purposes of the present discussion, presume that that second playhead position 122(2) (e.g., at which a participant whom is using the Nth client device 114(N) pauses the video content) corresponds to “Frame 100” of the video content. Thus, at the sixth time T.sub.6 the Nth media status 120(N) toggles from “play” to “pause” precisely at the second playhead position 122(2). Furthermore, at the sixth time T.sub.6, the Nth client device 114(N) transmits the pause instruction 136 to the server devices 102. It will be appreciated that since T.sub.6 corresponds to the moment at which the pause instruction 136 is sent from the Nth client device 114(N) but is prior to the pause instruction 136 being relayed to either of the first client device 114(1) or the Nth client device 114(N), at the sixth time T.sub.6 the video content will still be being played at the first and second client devices. Examiner’s interpretation: The Examiner has interpreted the claimed “control instructions” to be equivalent to play and pause instructions);
receiving, by the second client, the target control instruction and performing the same corresponding control operation as the first client on the target multimedia (See Parag. [0086-0087]; ... the user may adjust the playhead position of the media content at the particular client device to a desired playhead position before providing user input to cause all of the other client devices to begin playback of the media content at the desired playhead position (a target multimedia); the user play instruction (control operation) may include an indication of the desired playhead position at which the media content is to begin playing synchronously across all of the client devices 114 (the second client) ... in response to the user play instruction, the system transmits latency play instructions to the client devices based on the latency data. As described above, the manner in which the latency play instructions are transmitted to the client devices may prescribe intentional latency delays on some subset of the client devices to cause playback of the media data to begin synchronously across the plurality of client devices).
Baker discloses that time alignment is performed in response to a multimedia sharing joining operation (See Parag. [0080-0081] and Fig. 5), but Baker doesn’t explicitly disclose sending, by the second client, a time alignment request to the first client in response to a multimedia sharing joining operation; acquiring, by the first client, the time alignment request, wherein the time information is a time when the time alignment request is received by the first client.
However, Tzeng discloses sending, by the second client, a time alignment request to the first client in response to a multimedia sharing joining operation; acquiring, by the first client, the time alignment request (See Parag. [0018-0019]; peer-to-peer message exchange involves two nodes: a first peer node 102.1 having a first clock (CLOCK1) and a second peer node 102.2 having a second clock (CLOCK2) to be synchronized with the first clock of the first peer node 102.1 ... the second peer node 102.2 generating and transmitting a delay request (DELAY_REQ) packet 116 (a time alignment request) to the first peer node 102.1 ...), sending time information to the second client; aligning, by the second client, time of the second client with that of the first client based on the time information, wherein the time information is a time when the time alignment request is received by the first client (See Parag. [0022-0026]; When the DELAY_REQ packet 116 reaches the first peer node 102.1, the first peer node 102.1 can be configured to generate a timestamp T2 (time information) upon ingress of the DELAY_REQ packet 116. The timestamp T2 represents the ingress start of packet time for the DELAY_REQ packet 116 at the first peer node 102.1 ... the peer node 102.1 can be configured to generate and transmit a delay response packet "DELAY_RSP packet” 120 to the peer node 120.2. The DELAY_RSP packet 120 can be generated in response to the receipt of the of DELAY_REQ packet 116. In operation, the peer node 102.1 can be configured to generate a timestamp T3 upon the egress of the DELAY_RSP packet 120 from the peer node 102.1 to the peer node 102.2. The timestamp T3 represents the egress start of packet time of the DELAY_RSP packet 120. The DELAY_RSP packet 120 can include the timestamp T3 and/or timestamp T2 ... See Parag. [0040]; upon receiving the DELAY_RSP_FOLLOW_UP packet 122, the peer node 102.2 has received timestamps T2 and T3, and has the previously generated timestamps T1 and T4. Based upon these timestamps, the peer node 102.2 can be configured to synchronize (e.g., sync clock 124) the second clock (CLOCK2) of the peer node 102.2 with the first clock (CLOCK1) of the peer node 102.1 ... See also Fig. 1A).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the time alignment, taught by Baker, to include sending, by the second client, a time alignment request to the first client in response to a multimedia sharing joining operation; acquiring, by the first client, the time alignment request, wherein the time information is a time when the time alignment request is received by the first client, as taught by Tzeng. This would be convenient to improve network performance (Tzeng, Parag. [0012]).
Claim 15 is taught by Baker in view of Tzeng as described for claim 1.
Claim 16 is taught by Baker in view of Tzeng as described for claim 1.
Claim 19 is taught by Baker in view of Tzeng as described for claim 7.
Claim 20 is taught by Baker in view of Tzeng as described for claim 2.
Claim 21 is taught by Baker in view of Tzeng as described for claim 3.
Claim 22 is taught by Baker in view of Tzeng as described for claim 4.
Claim 23 is taught by Baker in view of Tzeng as described for claim 7.
Claim 24 is taught by Baker in view of Tzeng as described for claim 2.
Claim 25 is taught by Baker in view of Tzeng as described for claim 3.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Baker (Pub. No. US 2021/0250195); in view of Tzeng et al. (Pub. No. US 2015/0063375), hereinafter Tzeng; and further in view of Maistri et al. (Pub. No. US 2017/0237784), hereinafter Maistri.
Claim 9. Baker in view of Tzeng discloses [t]he multi-user multimedia control method according to claim 8,
Baker in view of Tzeng doesn’t explicitly disclose further comprising: in response to the delay being greater than or equal to a delay threshold, displaying an alignment failure notification.
However, Maistri discloses in response to the delay being greater than or equal to a delay threshold, displaying an alignment failure notification (See Parag. [0047]; if the upload bandwidth is suddenly reduced and the RTT exceeds a RTT threshold value, an alert may be generated notifying the video conferencing system that the RTT threshold value has been exceeded).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the latency measuring using RTT, taught by Baker in view of Tzeng, to include in response to the delay being greater than or equal to a delay threshold, displaying an alignment failure notification, as taught by Maistri. This would be convenient to change one or more parameters affecting the upload bandwidth, such as frame size, frame rate, or other encoder settings) to reduce the bandwidth usage (Maistri, Parag. [0047]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Deutschmann et al. (Patent No. US 11,706,477) – Related art in the area of sharing multi-media content among a plurality of users, (Abstract; The invention relates to a system and a corresponding method for sharing multi-media content among a plurality of users. The invention further relates the corresponding devices and a corresponding computer program for conducting the sharing of multi-media content. The system comprises a first device comprising means for generating an invitation and a play time stamp and the system further comprises means for transmitting the play time stamp and the invitation to at least one second device. The system also comprises a third device that may generate a system time and distribute the system time. The at least one second device may play multi-media content synchronous to playback of the same multi-media content at the first device).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights