DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1-2, 5-22
The following claim(s) is/are amended: 1, 6-7, 9, 11, 15, 16, 20
The following claim(s) is/are cancelled: 3-4
The following claim(s) is/are new: 21-22
Claim(s) 1-2, 5-22 is/are rejected. This rejection is FINAL.
Response to Arguments
Applicant’s arguments filed in the amendment filed 9/4/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 9 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 9 of U.S. Patent No. 12206722 in view of Cutaia (US Pub. 2004//0190700). Examiner maps Claim 9 of the patent to Claim 1 of the instant claimset and the other claims are similarly situated.
Claim 9 of ‘722
Instant Claim 1
Notes
9. A method, comprising: determining audio and/or video content of a virtual meeting is being shared;
1. A method, comprising: transmitting, from the first UE and to a second UE, the audio and/or video data;
Being shared requires transmitting
storing audio and/or video data corresponding to the audio and/or video content in a temporary storage buffer;
storing, by a first user equipment (UE), audio and/or video data associated with audio and/or video content associated with a virtual meeting;
Storing is broader than storing in a temporary storage buffer
receiving a request for a portion of the audio and/or video data, wherein the portion of the audio and/or video data is identified by a beginning time stamp and an ending time stamp associated with a temporary disruption of a network being used for the virtual meeting;
receiving, by the first UE, after transmitting the audio and/or video data, from a network device, a message comprising a request for a portion of the audio and/or video data associated with a network disruption of the second UE, wherein the message indicates a first time stamp, associated with a beginning of the network disruption, and a second time stamp, associated with an end of the network disruption;
Both claims require receiving a message with beginning and ending timestamps for a network disruption that define a portion. With respect to the request coming from a network device, see Cutaia, paras. 16-19; Replay module may be in a device and conference bridge provides audio and presents a replay UI to participating devices, which would make the requests to replay audio be requests that are received by a first UE (participating device’s replay module) from a network device (conference bridge). It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Claim 9 with the conference bridge requesting replay in Cutaia to allow the conference bridge to distribute the audio to the participant that missed the audio.
and transmitting the portion of the audio and/or video data at an accelerated playback rate, wherein the accelerated playback rate is based on a duration of the temporary disruption.
and retransmitting, by the first UE, to the network device, and based on receiving the message, only the portion of the audio and/or video data associated with the network disruption.
Both claims require retransmission of the data missed because of the disruption, but the instant claims are broader in that they do not require an accelerated playback.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 1-2, 5, 8-22 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claims 1, 6 and 7 together are sufficient to evidence the indefiniteness. Claim 1 requires “a request for a portion of the audio and/or video data associated with a network disruption” and “retransmitting [] only the portion of the audio and/or video data associated with the network disruption.” The boundaries of the term “retransmitting only the portion” is indefinite when placed in conjunction with “a portion of the audio and/or video data associated with a network disruption.” Claim 6 defines the portion as “the audio and/or video data is identified based on the first time stamp and the second time stamp” where the first/second time stamps are the beginning/end of the network disruption. Claim 7 defines the portion as “retransmission from the temporary buffer to the network device until the second UE is caught up to real-time audio and/or video data.” As a simple example of indefiniteness, suppose a virtual meeting participant experiences a network disruption one minute into a meeting and the disruption ends two minutes into the meeting. The system has, for example, an accelerated playback rate of 2x. Claim 6 would identify “only” “the portion” for retransmission as replaying the audio from seconds 60-120. Claim 7, however, would identify “only” “the portion” for retransmission as seconds 60-120, plus another 30 seconds (from 121-150) that is required to playback seconds 60-120 at an accelerated rate to catch up to real-time. Under one person of skill’s reasonable interpretation of “only the portion” in Claim 1 (one consistent with Claim 6) the transmission of the 121st second of conference audio would render the system noninfinging of Claim 1. But under another person of ordinary skill’s reasonable interpretation (one consistent with Claim 7) the transmission of the 121st second would still be infringing, provided the other limitations were met. Consequently, the boundary of “only the portion” is ambiguous.
Claims not specifically mentioned are rejected by virtue of their dependency.
Claim Rejections - 35 USC § 103
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 of this title, 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 1-2, 5-11 and 15-22 are rejected under 35 U.S.C. 103 as being unpatentable over Cutaia (US Pub. 2004/0190700) in view of Tiwari (US Pub. 2022/0286312).
With respect to Claim 1, Cutaia teaches a method, comprising: storing, by a first user equipment (UE), audio and/or video data associated with audio and/or video content associated with a virtual meeting; (Fig. 1, paras. 13-19, 26, 29; Devices such as computers have an audio conference. Replay module stores audio from the conference to be replayed later. Replay module may be its own element, part of the conference bridge, or part of the devices themselves. Para. 24; system also applicable to video conference.)
transmitting, by the first UE and to a second UE, the audio and/or video data; (para. 17; participant audio is sent to other participants via the conference bridge.)
receiving, by the first UE, after transmitting the audio and/or video data, from a network device, (para. 29; replay module monitors from commands from other system devices such as the network bridge. Fig. 3, para. 32; conference bridge presents user interface to devices to receive input, including a rejoin-with-replay button. Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
a message comprising a request for a portion of the audio and/or video data associated with a network disruption of the second UE, (A network disruption will be taught later. para. 19; If a participant misses portions of a conference the participant can request replay of portions of the buffered audio. Para. 19-20, 29, 35, 41; rejoin conference with replay function to replay audio at an increased speed to catch them up.)
and retransmitting, by the first UE, to the network device, (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
and based on receiving the message, only the portion of the audio and/or video data associated with the network disruption. (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio. paras. 19, 32-33, 35; replay of conference is transmitted to requested participant. Para. 19; replay module may “replay a predetermined amount of buffered audio or an amount indicated by the request,” therefore the retransmission may be only the portion requested.)
But Cutaia does not explicitly teach a network disruption.
Tiwari, however, does teach a network disruption (para. 19; system determines a client is disconnected from an active meeting.)
wherein the message indicates a first time stamp, associated with a beginning of the network disruption, and a second time stamp, associated with an end of the network disruption; (paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Para. 29; user A is disconnected from 9:10 to 9:13. See also Cutaia, paras. 19, 29-30; replay request.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Cutaia with the network disruption in order to allow for a user to get caught up on the meeting regardless of whether the lack of attendance was intentional or not. (Tiwari, para. 17; disconnected user can recapture lost content.)
With respect to Claim 2, modified Cutaia teaches the method of claim 1, and Cutaia also teaches further comprising: recording the audio and/or video content. (para. 16, 19, 27; buffering/storage of audio.)
With respect to Claim 5, modified Cutaia teaches the method of claim 1, and Tiwari also teaches further comprising: determining a duration of the network disruption based on receiving the message. (para. 24; system calculates length of disconnect period. Para. 29; User A is disconnected from 9:10 to 9:13, which renders determining a duration obvious.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 6, modified Cutaia teaches the method of claim 1, and Tiwari also teaches wherein the portion of the audio and/or video data is identified based on the first time stamp and the second time stamp. (First see Cutaia, para. 19; If a conference participant steps out or for any other reason misses portions of a conferences, they can request replay for a particular amount of audio. Then see Tiwari, paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Therefore, it would have been obvious to one of ordinary skill prior to the effective filing date to make the portion based on the first/second time stamps because those time stamps identify a disconnect period where a participant has missed a portion of the conference.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 7, modified Cutaia teaches the method of claim 1, and Cutaia also teaches wherein the audio and/or video data is stored in a temporary buffer of the first UE, (para. 16, 19, 27; buffering/storage of audio. Paras. 16, 26; replay module may be part of devices. para. 19; buffer may be previous five minutes.)
And wherein the portion is retransmission from the temporary buffer to the network device until the second UE is caught up to real-time audio and/or video data. (para. 41; rejoin-with-replay function retransmits missed audio at an accelerated rate until it reaches real-time with the conference and the real-time audio is played.)
With respect to Claim 8, modified Cutaia teaches the method of claim 1, and Cutaia also teaches wherein the message is received after a resolution of the network disruption of the second UE. (Para. 19-20, 29, 35, 41; rejoin conference with replay function to replay audio at an increased speed to catch them up. See also Tiwari, para. 19; system detects when a reconnect occurs including time of disconnection.)
With respect to Claim 9, Cutaia teaches a method, comprising: storing, by a first user equipment (UE), audio and/or video data associated with audio and/or video content; (Fig. 1, paras. 13-19, 26, 29; Devices such as computers have an audio conference. Replay module stores audio from the conference to be replayed later. Replay module may be its own element, part of the conference bridge, or part of the devices themselves. Para. 24; system also applicable to video conference.)
transmitting, by the first UE and to a second UE, the audio and/or video data; (para. 17; participant audio is sent to other participants via the conference bridge.)
determining, by the first UE, a network disruption after the network disruption resolves; (A network disruption will be taught later. para. 19; If a participant misses portions of a conference the participant can request replay of the buffered audio. Para. 19-20, 29, 35, 41; rejoin conference with replay function to replay audio at an increased speed to catch them up. See also Tiwari, para. 19; system detects when a reconnect occurs including time of disconnection.)
receiving, by the first UE and from a network device (para. 29; replay module monitors from commands from other system devices such as the network bridge. Fig. 3, para. 32; conference bridge presents user interface to devices to receive input, including a rejoin-with-replay button. Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
a request for a portion of the audio and/or video data associated with the network disruption (A network disruption will be taught later. para. 19; If a participant misses portions of a conference the participant can request replay of portions of the buffered audio. Para. 19-20, 29, 35, 41; rejoin conference with replay function to replay audio at an increased speed to catch them up.)
and retransmitting, by the first UE, to the network device, (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
and based on receiving the request, only the portion of the audio and/or video data associated with the network disruption. (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio. paras. 19, 32-33, 35; replay of conference is transmitted to requested participant. Para. 19; replay module may “replay a predetermined amount of buffered audio or an amount indicated by the request,” therefore the retransmission may be only the portion requested.)
But Cutaia does not explicitly teach a network disruption.
Tiwari, however, does teach a network disruption (para. 19; system determines a client is disconnected from an active meeting. paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Para. 29; user A is disconnected from 9:10 to 9:13. See also Cutaia, paras. 19, 29-30; replay request.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Cutaia with the network disruption in order to allow for a user to get caught up on the meeting regardless of whether the lack of attendance was intentional or not. (Tiwari, para. 17; disconnected user can recapture lost content.)
With respect to Claim 10, modified Cutaia teaches the method of claim 9, and Cutaia also teaches wherein the audio and/or video data is stored in a temporary buffer of the first UE. (para. 16, 19, 27; buffering/storage of audio. Paras. 16, 26; replay module may be part of devices. para. 19; buffer may be previous five minutes.)
With respect to Claim 11, modified Cutaia teaches the method of claim 10, and Tiwari also teaches further comprising: overwriting, based on retransmitting the portion of the audio and/or video data, the portion of the audio and/or video data with additional audio and/or video data when the temporary buffer is full. (para. 23; system may delete the catch up recording once the user catches up in order to save memory. See also Cutaia, para. 19; buffer may buffer the previous five minutes of audio.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 15, Cutaia teaches a first user device (UE), comprising: cause audio and/or video data, associated with audio and/or video content associated with a virtual meeting, to be stored; (Fig. 1, paras. 13-19, 26, 29; Devices such as computers have an audio conference. Replay module stores audio from the conference to be replayed later. Replay module may be its own element, part of the conference bridge, or part of the devices themselves. Para. 24; system also applicable to video conference.)
transmit, to a second UE, the audio and/or video data; (para. 17; participant audio is sent to other participants via the conference bridge.)
receive, from a network device (para. 29; replay module monitors from commands from other system devices such as the network bridge. Fig. 3, para. 32; conference bridge presents user interface to devices to receive input, including a rejoin-with-replay button. Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
a request for a portion of the audio and/or video data associated with the network disruption; (A network disruption will be taught later. para. 19; If a participant misses portions of a conference the participant can request replay of portions of the buffered audio. Para. 19-20, 29, 35, 41; rejoin conference with replay function to replay audio at an increased speed to catch them up.)
and retransmit, by the first UE, to the network device, (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio.)
and based on receiving the request, only the portion of the audio and/or video data associated with the network disruption. (Paras. 17, 29; conference bridge receives audio and presents it to participants. Participants can contact replay module directly or via conference bridge to request replay of buffered audio. paras. 19, 32-33, 35; replay of conference is transmitted to requested participant. Para. 19; replay module may “replay a predetermined amount of buffered audio or an amount indicated by the request,” therefore the retransmission may be only the portion requested.)
But Cutaia does not explicitly teach a network disruption.
Tiwari, however, does teach one or more processors, configured to: (para. 43; processor)
determine, by the first UE, a network disruption between the first UE and the second UE; (para. 19; system determines a client is disconnected from an active meeting. paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Para. 29; user A is disconnected from 9:10 to 9:13. See also Cutaia, paras. 19, 29-30; replay request.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the UE of Cutaia with the network disruption in order to allow for a user to get caught up on the meeting regardless of whether the lack of attendance was intentional or not. (Tiwari, para. 17; disconnected user can recapture lost content.)
With respect to Claim 16, modified Cutaia teaches the first UE of claim 15, and Tiwari also teaches wherein the one or more processors are further configured to: determine that the network disruption has resolved; (paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Para. 29; user A is disconnected from 9:10 to 9:13. See also Cutaia, paras. 19, 29-30; replay request.)
The same motivation to combine as the independent claim applies here.
And Cutaia also teaches and transmit additional audio and/or video content after retransmitting the portion of the audio and/or video data and determining that the network disruption has resolved. (para. 35; live audio stream after playing out the audio buffer. para. 23; layering to transmit live conference and replay audio. See also Tiwari, para. 22; replay at an accelerated pace until synchronizing with the live meeting.)
With respect to Claim 17, modified Cutaia teaches the first UE of claim 15, and Tiwari also teaches wherein the one or more processors are further configured to: determine a time stamp associated with a beginning of the network disruption. (paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. Para. 29; user A is disconnected from 9:10 to 9:13.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 18, modified Cutaia teaches the first UE of claim 15, and Cutaia also teaches wherein the one or more processors are further configured to: record the audio and/or video content. (para. 16, 19, 27; buffering/storage of audio.)
With respect to Claim 19, modified Cutaia teaches the first UE of claim 15, and Cutaia also teaches wherein the audio and/or video data is to be stored in a temporary buffer of the first UE. (para. 16, 19, 27; buffering/storage of audio. Paras. 16, 26; replay module may be part of devices. para. 19; buffer may be previous five minutes.)
With respect to Claim 20, modified Cutaia teaches the first UE of claim 19, and Tiwari also teaches wherein the one or more processors are further configured to: overwrite, based on retransmitting the portion of the audio and/or video data, the portion of the audio and/or video data with additional audio and/or video data when the temporary buffer is full. (para. 23; system may delete the catch up recording once the user catches up in order to save memory. See also Cutaia, para. 19; buffer may buffer the previous five minutes of audio.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 21, modified Cutaia teaches the method of Claim 1, and Tiwari also teaches wherein the request is received by the first UE based on the network device receiving, from the second UE, a disruption notification indicating the network disruption. (para. 19; disconnect detector/tracker that detects when a client device is disconnected. Para. 26; ping latency used to predict disconnections. See also Cutaia, paras. 34-35; hold and rejoin-with-replay buttons. A hold is a notification of an upcoming disruption, and a rejoin-with-replay is a notification of a past disruption.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 22, modified Cutaia teaches the method of Claim 21, and Tiwari also teaches wherein the disruption notification indicates the first time stamp and the second time stamp. (paras. 26-27; system determines a disconnect and reconnect and saves timestamp data of the disconnect period. See also Cutaia, para. 19; request with an indication of an amount of buffered audio to replay.)
The same motivation to combine as the independent claim applies here.
Claims 12-14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Cutaia (US Pub. 2004/0190700) in view of Tiwari (US Pub. 2022/0286312), and further in view of Li (US Pub. 2016/0337510).
With respect to Claim 12, modified Cutaia teaches the method of claim 9, but does not explicitly further comprising: receiving a setting to determine the network disruption.
Li, however, does teach further comprising: receiving a setting to determine the network disruption. (para. 53, 111-116; machine learning used to measure QoS and link failure by weighing both human dynamics and physical parameters such as packet loss. Weights and models selected are settings.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Cutaia with the network disruption settings in order to improve user quality of service by detecting call performance. (Li, para. 26)
With respect to Claim 13, modified Cutaia teaches the method of claim 9, but does not explicitly teach wherein the network disruption is determined based on a connection failing to satisfy at least one of a speed threshold, a bandwidth threshold, a data packet loss rate threshold, or a transmitting signal strength threshold.
Li, however, does teach wherein the network disruption is determined based on a connection failing to satisfy at least one of a speed threshold, a bandwidth threshold, a data packet loss rate threshold, or a transmitting signal strength threshold. (para. 53, 111-116; machine learning used to measure QoS and link failure by weighing both human dynamics and physical parameters such as packet loss. Weights and models selected are settings.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Cutaia with the network disruption based on data packet loss in order to improve user quality of service by detecting call performance based on metrics. (Li, para. 26)
With respect to Claim 14, modified Cutaia teaches the method of claim 9, but does not explicitly teach wherein the network disruption is determined using a machine learning model associated with at least one of a bandwidth, a data packet loss rate, a transmission signal strength, or a connection speed.
Li, however, does teach wherein the network disruption is determined using a machine learning model associated with at least one of a bandwidth, a data packet loss rate, a transmission signal strength, or a connection speed. (para. 53, 111-116; machine learning used to measure QoS and link failure by weighing both human dynamics and physical parameters such as packet loss. Weights and models selected are settings.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Cutaia with the machine learning model in order to improve user quality of service by detecting call performance. (Li, para. 26)
Remarks
Applicant does not meaningfully argue against the Double Patenting rejection and therefore it is maintained with amendments as above.
Applicant argues at Remarks, pgs. 8-11 that Claim 1 has been amended, and that all claims depend from Claim 1 or claims similar to Claim 1. Applicant argues the amended receiving and retransmission steps of Claim 1 are not taught by the cited references, but then appears to admit that Cutaia teaches a request which causes a replay. (Remarks, pgs. 8-9 citing Cutaia, paras. 19, 29)
Applicant further discusses Tiwari (Remarks, pg. 9) and states that Tiwari records content in response to a disconnect and that Tiwari “further describes using disconnect and reconnect timestamps to identify portions of the server-side recording that were missed by a disconnected client device. The missed portion of the recording is then provided by the server to the reconnected client device.”
Applicant does not explain how Cutaia fails to teach the features. Applicant argues with respect to Tiwari that “rather than disclosing the recited first-UE operations, Tiwari relies on the server-side recording to recover content missed by the disconnected client device.” (Remarks, pg. 9) But Examiner had already cited Cutaia for a replay module that may exist within a participating client. Examiner recognizes that the “network device” and the signaling between the network device and the first UE is new to the claims, but Applicant presents no argument as to why a network device is nonobvious when Cutaia has a conference bridge and Tiwari has a server that oversees the conference.
Applicant further argues that Examiner’s cited motivation for combination “does not supply the missing request-and-transmission arrangement.” Examiner does not view this as an argument against the motivation per se, but rather that the motivation also does not supply the features of the amended claims.
Consequently, Examiner cites teachings for the conference bridge as a network device and that the conference bridge can send commands to the replay module. The new claims are also taught above.
Additionally, Applicant amends to include a negative limitation. The claims previously allowed for retransmitting “at least a portion of the audio [] associated with the network disruption” but now require retransmitting “only the portion,” where the portion is defined by “a request for a portion of the audio and/or video data associated with a network disruption,” therefore making a system that sends more than “the portion” a noninfringing scope. The noninfringing carve-out has an ambiguous boundary because the same request may apparently result in “a portion” being defined as only the audio/video from the time of the disconnect (Claim 6), or alternatively being additional audio/video (Claim 7). “At least a portion” of audio was broad but definite – it meant transmitting anything less than the full amount of audio/video data satisfied the claim. “Only the portion” is indefinite because it is unclear if the amount of audio sent constitutes an infringing “only the portion” transmission or if it includes “the portion” as well as additional data that would be a noninfringing transmission.
All claims are rejected.
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 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
