DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the Amendment filed on May 27, 2026, in which claims 1, 4, 8, 11, 15 and 18 have been amended. Accordingly, claims 1-20 remain pending for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims 1-5, 8-12 and 15-19 are rejected under 35 U.S.C. 103.
Claim Rejections - 35 USC § 103
4. 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.
5. 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.
6. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
7. Claims 1-5, 8-12 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Briggs et al. (United States Patent No. US 12,519,905 B1), hereinafter “Briggs” in view of Philippe Vandermersch (United States Patent Application Publication No. US 2003/0063573 A1), hereinafter “Vandermersch” in view of Cohen et al. (United States Patent No. US 11,606,553 B1), hereinafter “Cohen”.
As to claim 1, Briggs discloses a system comprising: one or more computer processors (system including at least one processor programmed to carry out computer-executable instructions (also CPU 106 - See FIG. 1)) (Briggs, FIG. 1, col. 2, ll. 4-42, col. 5, ll. 51-52); one or more computer memories ((one or more random-access memory (RAM) modules 108, also local storage 122 - See again, FIG. 1 - which may be any form of computer-readable media)) (Briggs, FIG. 1, col. 5, ll. 54-55, col. 6, ll. 3-4); a set of instructions stored in the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations, the operations comprising (executable instructions executed by at least one processor) (Briggs, col. 1, ll. 42-43, col. 2, ll. 41-42, col. 5, ll. 51-53): receiving one or more real-time communication streams, at a conferencing service, from one or more participants in a conference (wherein one or more users may participate in a video conference, and the video streams for each user may be recorded locally, with a composite recording being generated therefrom. In particular, with reference to FIG. 2A, media servers 206 receive and transmit various video streams associated with studios 204, to and from a number of users 202. For clarity, Examiner maps the recited “conferencing service” to the disclosed single instance of media server 206, as Briggs clearly teaches that a single instance of media server 206 is adequate to receive from and transmit various video streams associated with studio 204. Briggs further teaches that multiple video streams 280, 282, 284 may be received at media server 206 (See also FIG. 2C) and processed in connection with browser instance 274 running within video processing service 272) (Briggs, FIGS. 2A and 2C, col. 5, ll. 33-37, col. 6, ll. 58-62, col. 9, ll. 59-62); independently forking each of the one or more real-time communication streams to a recording media sink configured to process and store the one or more real-time communication streams (See in particular, FIG. 2C, illustrating multiple independent live streams 280, 282 and 284. Again, the multiple video streams 280, 282, 284 may be received at media server 206 and processed in connection with browser instance 274 running within video processing service 272. As well, the multiple video streams 280, 282, 284 may be composited and rendered in memory of browser instance 274. As well, and also as highlighted by Applicant in page 10 of Remarks, Briggs teaches that where users 202 are on a relatively low-bandwidth connection, a lossy compression may be employed so that a particular video stream is able to keep up within the constraints of the low-bandwidth connection. In some such embodiments, where lossy compression is employed for the live stream, a lossless version of the recording is persisted locally, e.g., on a storage medium associated with a client device of one of users 202 that has only a low-bandwidth connection. In such embodiments, once the live streaming has concluded, or in the case where a high-bandwidth connection is encountered, the lossless recording of the recorded video is uploaded to media server 206 and subsequently forwarded on to capturing server 208. In some embodiments, the lossless recording of the recorded video is transmitted directly to capturing server 208. In alternative embodiments, where the one of users 202 has a high-bandwidth connection, the lossless recording may be streamed substantially simultaneously with the compressed stream that is used to render a composite video stream. As can be appreciated by one of ordinary skill in the art, “forking” in this context means simply reading [a stream] from one topic or source and routing the stream to multiple different consumers, paths or sinks, and as can further be appreciated and understood by the skilled artisan, the streams themselves are inherently independent flows rather than exact replicas of the data payloads) (Briggs, FIG. 2C, col. 9, ll. 59-62, col. 9, ll. 64-66); and making a multi-track recording accessible via an application programming interface (API) to one or more downstream tools for further processing or analysis at a conclusion of the conference (wherein each of a browser rendering engine such as Chromium, as well as a voice chat mixing service such as OPENTALK (as part of encoding browser 240) utilize a number of REST-based APIs, as readily understood by the skilled artisan. The output from encoding browser 240 is provided to subsequent downstream encoders 244, which can provide an output in a real-time messaging protocol (RTMP) format as needed by social media platforms or other distribution servers, and for distributing to other users) (Briggs, col. 8, l. 64-col. 9, l. 12, col. 9, ll. 23-36). Briggs does not explicitly disclose converting each of the one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams; and the multi-track recording composed by synchronizing the one or more real-time communication streams based on the one or more metadata items. However Vandermersch discloses converting each of one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams (wherein with reference to FIG. 8, Vandermersch teaches that a conference call of “N” participants may utilize a multipoint control unit (MCU) which utilizes the “X” number of prominent inputs, such as the three loudest. In contemplated embodiments, Vandermersch teaches that during setup of a conferencing session, a multicast IP address and user datagram protocol (UDP) port may be negotiated (See FIG. 8, at step 802). Thus, each participant in the conference may send its voice stream to the IP address of the MCU, whereas the MCU sends its output to this multicast IP address. Vandermersch further teaches that periodically during the conference, such as every 20 to 30 ms, “X” prominent participants are selected (See FIG. 8, at step 804) and an “X+1” output stream is constructed (See FIG. 8, at step 806). From the output streams, a UDP packet is constructed (See FIG. 8, at step 808) which encapsulates “X+1” RTP sub-packets. The first RTP sub-packet is formed by mixing all of the prominent participants (See FIG. 8, at step 810). A field titled “contributing sources” (CSRC) of the RTP header is filled with identifiers indicating the originating participants of the prominent inputs (See FIG. 8, at step 812). A synchronization source (SSRC) field is filled with an identifier of the multipoint control unit (See FIG. 8, at step 814). The other sub-packets are formed by mixing the prominent inputs minus one prominent input. The field CSRC of the RTP header is filled accordingly with identifiers indicating the prominent participants mixed in this packet (See FIG. 8, at step 816). A timestamp field may also be provided in each RTP sub-packet with the same timing information. Then, the combined packet, including the sub-packets, is sent to the endpoints for output to a user by utilizing a multicast address (See FIG. 8, at step 818)) (Vandermersch, FIG. 8, paragraphs [0046] and [0047]). Briggs and Vandermersch are analogous art because they are from the same field of endeavor, namely, management of media streams during a conference. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Briggs and Vandermersch before him or her, to modify the conferencing system of Briggs to include the additional limitation of converting each of one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams, as disclosed in Vandermersch, with reasonable expectation that this would result in a conferencing system that significantly reduced the number of packets sent over a network and as a result, reduced global network traffic and increased bandwidth, regardless of conference size (See Vandermersch, paragraph [0022]). This method of improving the conferencing system of Briggs was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Vandermersch. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Briggs with Vandermersch to obtain the invention as specified in claim 1. Briggs-Vandermersch does not explicitly disclose the multi-track recording composed by synchronizing the one or more real-time communication streams based on the one or more metadata items. In an analogous art, however, Cohen discloses a multi-track recording composed by synchronizing one or more real-time communication streams based on one or more metadata items (wherein with reference to FIG. 8, Cohen discloses a process 800 which can be a process performed by a media sync module 244 of example system 200 (See also FIG. 2), or by any other suitable element. In process 800, timestamps (which Examiner has equated/mapped to recited “metadata items”) are used to synchronize one or more segments of a live media stream 801 (which may correspond to server-side recording 214) with a corresponding one or more segments of a local media stream 802 (which may correspond to client-side recording 212). According to some embodiments, in process 800, Cohen teaches that timestamps aligned with a server clock 803 are applied to segments of live media stream 801 (e.g., by media server 220). At stage 804, the server-aligned timestamps are applied to segments of local media stream 802. At stage 805, the timestamps are used to identify segments of live media stream 801 that correspond to segments of local media stream 802. For example, it can be determined at stage 805 that a segment of live media stream 801 that has a particular timestamp corresponds to a segment of local media stream 802 that has the same timestamp) (Cohen, FIGS. 2 and 8, col. 13, ll. 24-44). Briggs-Vandermersch and Cohen are analogous art because they are from the same field of endeavor, namely, management of media streams during a conference. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Briggs-Vandermersch and Cohen before him or her, to modify the conferencing system of Briggs-Vandermersch to include the additional limitation of a multi-track recording composed by synchronizing one or more real-time communication streams based on one or more metadata items, as disclosed in Cohen, with reasonable expectation that this would result in a conferencing system that ensured local media streams were synchronized with live media streams using timestamps, thereby ultimately efficiently enabling the replacement of faulty/corrupted media streams (See Cohen, col. 1, l. 60-col. 2, l. 5). This method of improving the conferencing system of Briggs-Vandermersch was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Cohen. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Briggs-Vandermersch with Cohen to obtain the invention as specified in claim 1.
Claim 15 is directed to a “non-transitory computer-readable storage medium storing a set of instructions that,” when executed by one or more computer processors, causes the one or more computer processors to perform operations substantially as recited in independent “system” claim 1, and does not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, as Briggs-Vandermersch-Cohen discloses such a “non-transitory computer-readable storage medium” (wherein Briggs discloses one or more non-transitory computer-readable media storing computer executable instructions that, when executed by at least one processor, perform the inventive solution) (Briggs, col. 1, ll. 40-43, col. 6, ll. 6-22), claim 15 is rejected under the same rationale.
In addition, claim 8 includes a “method” claim that performs limitations substantially as recited in independent “system” claim 1, and does not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, it is rejected under the same rationale.
Regarding claim 2, Briggs-Vandermersch-Cohen discloses the system of claim 1, wherein the one or more metadata items include one or more timestamps indicating exact timing of each audio packet within each of the one or more real-time communication streams or one or more participant identifiers uniquely associating each of the one or more real-time communication streams with a corresponding participant (again, field CSRC of the RTP header is filled accordingly with identifiers indicating the prominent participants mixed in the packet) (Vandermersch, paragraph [0047]). As discussed and shown above, Briggs and Vandermersch are analogous art because they are from the same field of endeavor, namely, management of media streams during a conference. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Briggs and Vandermersch before him or her, to modify the conferencing system of Briggs to include the additional limitation of wherein the one or more metadata items include one or more timestamps indicating exact timing of each audio packet within each of the one or more real-time communication streams, or one or more participant identifiers uniquely associating each of the one or more real-time communication streams with a corresponding participant, as disclosed in Vandermersch, with reasonable expectation that this would result in a conferencing system that pinpointed each participant’s contribution to the conference (See Vandermersch, paragraph [0047]). This method of improving the conferencing system of Briggs was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Vandermersch. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of Briggs with Vandermersch to obtain the invention as specified in claim 2.
Regarding claim 3, Briggs-Vandermersch-Cohen discloses the system of claim 2, wherein the synchronizing of the one or more real-time communication streams includes aligning audio from different participants according to a sequence of conversation events indicated by the one or more timestamps or the one or more participant identifiers (wherein a timeline may be generated that comprises each event occurring within the video live stream. Each event on the timeline may be associated with a timestamp, a user(s), a category, or the like) (Briggs, col. 15, ll. 20-24). The motivation regarding the obviousness of claim 1 is also applied to claim 3.
Regarding claim 4, Briggs-Vandermersch-Cohen discloses the system of claim 1, wherein the composing of the multi-track recording includes detecting a specific audio event from the one or more metadata items, wherein the specific audio event includes at least one of: a first participant of the one or more participants speaking while a second participant of the one or more participants is speaking, a participant of the one or more participants starting to speak, or a participant of the one or more participants stopping speaking (wherein events include detection of a participant speaking (or a participant finishing speaking)) (Briggs, col. 13, ll. 42-43). The motivation regarding the obviousness of claim 1 is also applied to claim 4.
Regarding claim 5, Briggs-Vandermersch-Cohen discloses the system of claim 4, wherein the composing of the multi-track recording includes adding annotations identifying the specific audio event to facilitate enhanced analysis by the one or more downstream tools (wherein detected events are logged, categorized, timestamped or any combination thereof) (Briggs, col. 12, l. 66-col. 13, l. 1). The motivation regarding the obviousness of claim 1 is also applied to claim 5.
Claims 16-19 are directed to a “non-transitory computer-readable storage medium” claims that perform limitations substantially as recited in “system” claims 2-5, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
In addition, claims 9-12 include “method” claims that perform limitations substantially as recited in “system” claims 2-5, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
Allowable Subject Matter
8. Claims 6, 7, 13, 14 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
9. Applicant’s arguments, see page 8, filed May 27, 2026, with respect to Rejections of Claims 4, 5, 11, 12, 18 and 19 under 35 U.S.C. 112(b) have been fully considered and are persuasive. The Rejections of Claims 4, 5, 11, 12, 18 and 19 under 35 U.S.C. 112(b), as set forth in the previous Office action, have been withdrawn.
10. Applicant’s arguments, see pages 9-16, filed May 27, 2026, with respect to Rejections of Claims 1-5, 8-12 and 15-19 under 35 U.S.C. 103 have been fully considered but they are not persuasive.
(A) Applicant argued on pages 9-11 of Remarks, “The Examiner relies on Briggs as the primary reference for the recited ‘independently forking each of the one or more real-time communication streams to a recording media sink.’ (Office Action at 7, citing Briggs FIG. 2C and col. 9, lines 59-66.) That reliance is misplaced. ‘Forking,’ as used in the present application and as would be understood by a person of ordinary skill in the art in the context of real-time communications, denotes the duplication of a single signal into two equivalent copies, such that one copy may be used for one purpose (e.g., live conference mixing) while the other copy is concurrently used for another purpose (e.g., recording). The specification is explicit on this point, describing that ‘each stream is duplicated through a sophisticated forking mechanism’ such that ‘[o]ne copy of each forked stream is directed towards ongoing live conference mixing, while the other is routed to a designated recording media sink.’ (Spec., Detailed Description, discussion of FIGS. 2, 3, 4, and 8.) The two copies are equivalent - they are duplicates of the same stream - and are produced at the mixer service of the conferencing platform that receives the streams and handles the live conference” (Recited from page 9 of Remarks). “Briggs describes nothing of the sort. To the contrary, Briggs describes - both in its Background and in its Detailed Description - the precise opposite architecture: the participant’s original signal is captured and stored at the participant’s client device as a lossless local recording, while a separate, reduced-bandwidth (lossy) version of the same content is generated at the source and transmitted over the network for live streaming. The Background section of Briggs frames the entire invention around this distinction: ‘Video live streams are generally recorded at a cloud server. Accordingly, the recordings are made at a degraded quality relative to a native quality of the video data generated by a client device due to bandwidth restrictions. To preserve the native quality of the video data, recordings may be generated locally on the client device.’ (Briggs, col. 1, lines 16-21 (Background) (emphasis added).) “Briggs’s Detailed Description confirms this two-track-at-source approach. Briggs discloses that, ‘[i]n some embodiments, where users 202 are on a relatively low-bandwidth connection, a lossy compression may be employed so that a particular video stream is able to keep up within the constraints of the low-bandwidth connection. In some such embodiments, where lossy compression is employed for the live stream, a lossless version of the recording is persisted locally, for example, on a storage medium associated with a client device of one of users 202 ....’ (Briggs, col. 6, line 65 to col. 7, line 6.) Briggs then makes clear that the lossless local recording is, at most, uploaded after the fact: ‘[O]nce the live streaming has concluded, or in the case where a high-bandwidth connection is encountered, the lossless recording of the recorded video is uploaded to media server 206 ....’ (Briggs, col. 7, lines 7-10.) That is plainly not forking. “Two architectural facts about Briggs are therefore dispositive. First, the live stream and the so-called ‘local recording’ in Briggs are not equivalent copies of the same signal: they are different - one is a lossy, compressed live broadcast version; the other is a separately generated, lossless recording at the source. They diverge in fidelity, in encoding, and in temporal use. They are not duplicates. They are two purpose-built, non-equivalent versions of the participant’s content. As such, Briggs cannot, by definition, be ‘forking,’ which requires the duplication of a single signal into two equivalent copies. Second, the place where Briggs’s two versions are produced is the participant’s client device - not at the conferencing service that receives the participants’ streams. The local recording is, by Briggs’s own express words, ‘persisted locally’ on ‘a storage medium associated with a client device of one of users 202.’ (Briggs, col. 7, lines 4-6.) The amended independent claims expressly require that the one or more real-time communication streams be received ‘at a conferencing service’ and then independently forked to a recording media sink. Briggs does the opposite: the lossless local recording in Briggs is captured and stored at the client device independent of any reception at a server” (Recited from pages 10-11 of Remarks).
As to point (A), Examiner respectfully disagrees. To begin with, in response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the duplication of a single signal into two equivalent copies, such that one copy may be used for one purpose (e.g., live conference mixing) while the other copy is concurrently used for another purpose (e.g., recording), that each stream is duplicated through a sophisticated forking mechanism such that one copy of each forked stream is directed towards ongoing live conference mixing, while the other is routed to a designated recording media sink, and that the one or more real-time communication streams are forked at the conferencing service) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Examiner respectfully points out that while the “one or more real-time communication streams” are recited as being received “at a conferencing server,” nevertheless, the claims are silent with regard to what performs the “independently forking” limitation, much less when and where this occurs. As for Applicant’s argument that “the place where Briggs’s two versions are produced is the participant’s client device - not at the conferencing service that receives the participants’ streams,” Examiner wishes to point out that the limitation in question merely recites, “receiving one or more real-time communication streams, at a conferencing service, from one or more participants in a conference,” which Examiner has already shown Briggs to disclose 1) the participants are not necessarily participating in a live stream, but may rather be participating in a video conference that is not live streamed to any external destination, whereby the video streams for each user may be recorded locally and a composite generated therefrom (See Briggs, col. 5, ll. 32-37), and 2) Examiner has mapped the recited “conferencing service” to the disclosed single instance of media server 206 of Briggs, shown at FIG. 2, as the media server 206 receives the stream of video (See Briggs, col. 6, ll. 60-65). Examiner respectfully points out that the limitation fails to expressly recite that the “versions are produced at the conferencing service,” which Applicant appears to argue is required of Briggs - “Second, the place where Briggs’s two versions are produced is the participant’s client device - not at the conferencing service that receives the participants’ streams”. Indeed, there is no recitation of any “version” any place within the limitation in question or any place whatsoever within the independent claims. With respect to the “independently forking” limitation, Examiner has already shown that the lossless recording is “forked” to the capturing server 208, after having first been received at media server 206. Indeed, Briggs teaches that in the case where a high-bandwidth connection is encountered, the lossless recording of the recorded video can first be uploaded to media server 206 and subsequently forwarded on to capturing server 208 (See again, Briggs, FIG. 2A, col. 7, ll. 8-11). Examiner notes that this will occur for every participant having a low bandwidth connection, or by extension, every studio having low bandwidth. As such Briggs teaches “independently forking each of the one or more real-time communication streams to a recording media sink configured to process and store the one or more real-time communication streams”. In addition, Examiner wishes to point out that the above language quoted from the referenced paragraph from Applicant’s instant Specification (i.e., ¶ [0050]) is not an explicit and deliberate definition, but rather that of an example embodiment (emphasis added). Indeed, paragraph [0050] recites, “In example embodiments, each real-time communication stream received from conference participants is independently processed to ensure precise handling and storage. Upon receipt at the mixer service, each stream is duplicated through a sophisticated forking mechanism. This mechanism establishes a dedicated data path for each stream, thereby isolating the handling and processing of individual streams. One copy of each forked stream is directed towards ongoing live conference mixing, while the other is routed to a designated recording media sink. This ensures that live conference interactions are maintained without interruption, while simultaneously preserving a separate copy for recording purposes” (Recited from paragraph [0050] of Applicant’s instant Specification, with added emphasis). While paragraph [0050] gives an example of “forking,” in the context of the disclosed embodiments, nevertheless, this is not an explicit and deliberate definition of “forking,” and Examiner is not precluded from using only the material in paragraph [0050] for mapping the claimed “forking” limitation to the functions of the media server 206 of Briggs. Examiner has performed a simple Google® search of the term “forking” in the context of streaming media, (i.e., “forking a stream” See attached search notes), and has found the term to involve simply “taking a single source of data (like a file, network request, or functional collection) and routing it simultaneously into multiple destinations or processes” (as per the AI Overview). Examiner notes that Briggs teaches that the same content is being streamed - one lossy, compressed version, one lossless version, though the content itself is the same “duplicated” content. This clearly reads on the sections highlighted above at page 10 of the Remarks, and equally cited by Examiner at the rejection of independent claim 1. Furthermore, again, Examiner respectfully reminds Applicant that although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). To the contrary, claims are to be given the broadest reasonable interpretation (the BRI), and the only exceptions to giving the words in a claim their ordinary and customary meaning in the art are (1) when the applicant acts as their own lexicographer; and (2) when the applicant disavows or disclaims the full scope of a claim term in the specification. To act as their own lexicographer, the applicant must clearly set forth a special definition of a claim term in the specification that differs from the plain and ordinary meaning it would otherwise possess. The specification may also include an intentional disclaimer, or disavowal, of claim scope. In both of these cases, “the inventor’s intention, as expressed in the specification, is regarded as dispositive.” Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (en banc). See also Starhome GmbH v. AT&T Mobility LLC, 743 F.3d 849, 857, 109 USPQ2d 1885, 1890-91 (Fed. Cir. 2014) (holding that the term “gateway” should be given its ordinary and customary meaning of “a connection between different networks” because nothing in the specification indicated a clear intent to depart from that ordinary meaning); Thorner v. Sony Computer Entm’t Am. LLC, 669 F.3d 1362, 1367-68, 101 USPQ2d 1457, 1460 (Fed. Cir. 2012) (The asserted claims of the patent were directed to a tactile feedback system for video game controllers comprising a flexible pad with a plurality of actuators “attached to said pad.” The court held that the claims were not limited to actuators attached to the external surface of the pad, even though the specification used the word “attached” when describing embodiments affixed to the external surface of the pad but the word “embedded” when describing embodiments affixed to the internal surface of the pad. The court explained that the plain and ordinary meaning of “attached” includes both external and internal attachments. Further, there is no clear and explicit statement in the specification to redefine “attached” or disavow the full scope of the term.) With regard to the teachings of Briggs, while Examiner agrees that Briggs fails to expressly teach that a forking mechanism is used to duplicate each of the one or more real-time communication streams upon receipt at a mixer service, directing one copy to ongoing live conference mixing and another copy to the recording media sink; and maintaining separate processing queues for each forked stream at the recording media sink to prevent data loss and ensure integrity of recorded data (indeed, Examiner objected to dependent claims 6, 13 and 20 as allowable), nonetheless, Briggs does disclose “forking” given the broadest definition of the concept. That is, Briggs does teach, and Applicant has freely admitted, creating two separate versions of the same content (albeit not exact duplicates, as a lossless version and a compressed version are each different versions of the same payload/content), and streaming both versions [substantially] simultaneously, which fits the commonly accepted definition of “forking”. Moreover, Examiner notes that MPEP 2131.01 III, provides for situations for showing that a characteristic not disclosed in a reference is inherent: “To serve as an anticipation when the reference is silent about the asserted inherent characteristic, such gap in the reference may be filled with recourse to extrinsic evidence. Such evidence must make clear that the missing descriptive matter is necessarily present in the thing described in the reference, and that it would be so recognized by persons of ordinary skill.” Continental Can Co. USA v. Monsanto Co., 948 F.2d 1264, 1268, 20 USPQ2d 1746, 1749-50 (Fed. Cir. 1991). Thus, to support Examiner’s position that the limitation of “independently forking each of the one or more real-time communication streams to a recording media sink configured to process and store the one or more real-time communication streams,” is necessarily (at least inherently) present within Briggs, Examiner has cited the additional reference to Kang et al., an NPL reference entitled “A Method of Forking Stream Using IP Multicast in HDTV Media Gateway,” hereinafter “Kang”. Importantly, Examiner notes however that the original thrust of the rejection remains the same, and again, rather than relying on the reference as a new ground of rejection, Examiner is merely relying on the reference to show support for the original rejection made in the Non-Final Office Action. Examiner now draws Applicant’s attention to Kang. In particular, Kang teaches that an HDTV live stream is “forked” into multiple duplicate versions, though the versions themselves are not exact duplicates. That is, as shown in FIG. 4, an HDTV live stream (1) is received into HDTV Media Gateway, which comprises four transcoding modules and a multicast switch. Kang teaches that the source stream (i.e., the HDTV live stream) needs to be forked using the several transcoding modules, and proposes IP multicast for the HDTV original live stream through the media gateway system. Kang specifically teaches that the forked output streams from the media gateway system have different stream rates (and thus are not exact duplicates). Indeed, output stream (3) has a rate of 19.2 Mbps, output stream (4) has a rate of 10 Mbps, output stream (5) has a rate of 1 Mbps, and output stream (6) has a rate of 500 Kbps (See Kang, Figure 4 - “Streaming Forking using Local Multicast” - Section 3.2 - “Local Multicast”). Again, Examiner relies of the extrinsic reference to Kang to support the original position taken by the Office, that “forking” does not necessarily mean “exact duplicates, equivalent copies, matching in fidelity, in encoding, and in temporal use,” as Applicant appears to assert. Examiner respectfully disagrees with this assertion, noting the teachings of Kang, which clearly demonstrate that a forked media stream can absolutely differ in bit rate and encoding. Thus, if “the duplication of a single signal into two equivalent copies, such that one copy may be used for one purpose (e.g., live conference mixing) while the other copy is concurrently used for another purpose (e.g., recording), that each stream is duplicated through a sophisticated forking mechanism such that one copy of each forked stream is directed towards ongoing live conference mixing, while the other is routed to a designated recording media sink, and that the one or more real-time communication streams are forked at the conferencing service” are in fact considered by Applicant to be critical features of the invention, then they should be present in the claim language. Therefore, Examiner respectfully submits, Briggs does disclose, teach and/or suggest “independently forking each of the one or more real-time communication streams to a recording media sink configured to process and store the one or more real-time communication streams,” as currently recited in independent claim 1. Due to the response, however, Examiner has updated citations to more accurately reflect claim mappings, and has elaborated on interpretation of the claim language, as well as application of the reference, to assist the reader in understanding the rejection.
(B) Applicant argued on page 12 of Remarks, “Even setting aside the foregoing - which is dispositive - the Examiner’s rejection independently fails because the claimed ‘multi-track recording composed by synchronizing the one or more real-time communication streams based on the one or more metadata items’ is structurally and conceptually distinct from anything Briggs describes. Each independent claim, as amended, requires that the system receive the one or more participants’ real-time communication streams at a conferencing service, independently fork each received stream to a recording media sink, and preserve each forked stream as an independent track of a single multi-track recording. The output is one recording with N tracks - one track for each forked participant stream - synchronized to one another based on metadata items such as timestamps and participant identifiers. (See, e.g., Spec., Summary; Spec., Detailed Description, discussion of FIGS. 2, 3, 4, and 8.) Each individual participant’s contribution remains separately addressable and analyzable by downstream tools - for example, by transcription engines, voice analytics, and AI-driven customer support tooling. (See, e.g., Spec., Detailed Description, introductory discussion of downstream applications.)” (Recited from page 12 of Remarks).
As to point (B), Examiner once again respectfully submits that in response to Applicant’s argument that the reference to Briggs fails to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., that the system preserve each forked stream as an independent track of a single multi-track recording; The output is one recording with N tracks - one track for each forked participant stream - synchronized to one another based on metadata items such as timestamps and participant identifiers; Each individual participant’s contribution remains separately addressable and analyzable by downstream tools - for example, by transcription engines, voice analytics, and AI-driven customer support tooling) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim language of the independent claims says nothing to the effect of any type of preservation whatsoever, much less preserving each forked stream as an independent track of a single multi-track recording. Nor do the independent claims recite anything remotely resembling an output having one recording with N tracks - one track for each forked participant stream - synchronized to one another based on metadata items such as timestamps and participant identifiers, or even that each individual participant’s contribution remains separately addressable and analyzable by downstream tools - for example, by transcription engines, voice analytics, and AI-driven customer support tooling. Rather, each of independent claims 1, 8 and 15 merely recite, “converting each of the one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams; and making a multi-track recording accessible via an application programming interface (API) to one or more downstream tools for further processing or analysis at a conclusion of the conference, the multi-track recording composed by synchronizing the one or more real-time communication streams based on the one or more metadata items” (emphasis added). Thus the claims require that the streams are encapsulated with one or more metadata items, that at best, are “usable” (emphasis added), for synchronizing the one or more streams, and that a multi-track recording is made accessible, via an API, to one or more downstream tools for further processing or analysis at a conclusion of the conference, whereby the multi-track recording is composed by synchronizing the streams based on the metadata items. While the claim language sets forth the requirement that a multi-track recording is composed by synchronizing streams based on the metadata items, the claim language is nonetheless entirely silent with respect to an output having one recording with N tracks - one track for each forked participant stream, or preserving each forked stream as an independent track of a single multi-track recording, or even that the tracks are synchronized to one another based on metadata items such as timestamps and participant identifiers, or even that each individual participant’s contribution remains separately addressable and analyzable by downstream tools - for example, by transcription engines, voice analytics, and AI-driven customer support tooling. To the contrary, the claims merely require that a multi-track recording is composed by synchronizing streams based on the metadata items, which again, are used to synchronize the streams, and that the recording is accessible via an API for further processing or analysis at the conclusion of the conference. In response to Applicant’s arguments against the references individually, Examiner respectfully reminds Applicant that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In the instant case, Examiner has relied upon Briggs for disclosing a portion of the limitation, namely, making a multi-track recording accessible via an application programming interface (API) to one or more downstream tools for further processing or analysis at a conclusion of the conference, as Briggs teaches utilizing platforms such as Chromium and OPENTALK (as part of encoding browser 240) each of which utilize a number of REST-based APIs. Briggs further teaches that the output from encoding browser 240 is provided to subsequent downstream encoders 244, which can provide an output in a real-time messaging protocol (RTMP) format as needed by social media platforms or other distribution servers, and for distributing to other users (See again, Briggs, col. 8, l. 64-col. 9, l. 12, col. 9, ll. 23-36). Examiner relied upon Vandermersch for disclosing converting each of one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams. As discussed and shown above, Vandermersch teaches that a conference call of “N” participants may utilize a multipoint control unit (MCU) which utilizes the “X” number of prominent inputs, such as the three loudest. In contemplated embodiments, Vandermersch teaches that during setup of a conferencing session, a multicast IP address and user datagram protocol (UDP) port may be negotiated (See FIG. 8, at step 802). Thus, each participant in the conference may send its voice stream to the IP address of the MCU, whereas the MCU sends its output to this multicast IP address. Vandermersch further teaches that periodically during the conference, such as every 20 to 30 ms, “X” prominent participants are selected (See FIG. 8, at step 804) and an “X+1” output stream is constructed (See FIG. 8, at step 806). From the output streams, a UDP packet is constructed (See FIG. 8, at step 808) which encapsulates “X+1” RTP sub-packets. The first RTP sub-packet is formed by mixing all of the prominent participants (See FIG. 8, at step 810). A field titled “contributing sources” (CSRC) of the RTP header is filled with identifiers indicating the originating participants of the prominent inputs (See FIG. 8, at step 812). A synchronization source (SSRC) field is filled with an identifier of the multipoint control unit (See FIG. 8, at step 814). The other sub-packets are formed by mixing the prominent inputs minus one prominent input. The field CSRC of the RTP header is filled accordingly with identifiers indicating the prominent participants mixed in this packet (See FIG. 8, at step 816). A timestamp field may also be provided in each RTP sub-packet with the same timing information. Then, the combined packet, including the sub-packets, is sent to the endpoints for output to a user by utilizing a multicast address (See FIG. 8, at step 818)) (See again, Vandermersch, FIG. 8, paragraphs [0046] and [0047]). In addition, Examiner relied upon Cohen for disclosing a multi-track recording composed by synchronizing one or more real-time communication streams based on one or more metadata items, as Cohen teaches a process 800 (See again, FIG. 8) which can be a process performed by a media sync module 244 of example system 200 (See also FIG. 2), or by any other suitable element. In process 800, timestamps (which Examiner has equated/mapped to recited “metadata items”) are used to synchronize one or more segments of a live media stream 801 (which may correspond to server-side recording 214) with a corresponding one or more segments of a local media stream 802 (which may correspond to client-side recording 212). According to some embodiments, in process 800, Cohen teaches that timestamps aligned with a server clock 803 are applied to segments of live media stream 801 (e.g., by media server 220). At stage 804, the server-aligned timestamps are applied to segments of local media stream 802. At stage 805, the timestamps are used to identify segments of live media stream 801 that correspond to segments of local media stream 802. For example, it can be determined at stage 805 that a segment of live media stream 801 that has a particular timestamp corresponds to a segment of local media stream 802 that has the same timestamp) (See again, Cohen, FIGS. 2 and 8, col. 13, ll. 24-34). As the independent claims fail to specify how the metadata items are being used to synchronize the one or more real-time communication streams, Examiner is not precluded from applying the teachings of Vandermersch and Cohen to the teachings of Briggs, in so long as the references not ‘criticize, discredit, or otherwise discourage’ investigation into the invention claimed. Finally, if the system preserves each forked stream as an independent track of a single multi-track recording; The output is one recording with N tracks - one track for each forked participant stream - synchronized to one another based on metadata items such as timestamps and participant identifiers; Each individual participant’s contribution remains separately addressable and analyzable by downstream tools - for example, by transcription engines, voice analytics, and AI-driven customer support tooling are in fact critical features of the invention, then they should be present in the claim language. Accordingly, Examiner respectfully submits that Briggs, Vandermersch and Cohen does disclose, teach and/or suggest the features of the claim language, as currently recited in the independent claims. Due to the amendment, however, Examiner has expanded on interpretation of the claim language and has elaborated on application of the references to assist the reader in understanding the rejection.
(C) Applicant argued on pages 13-14 of Remarks, “The Examiner relies on Vandermersch for the limitation of ‘converting each of the one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams.’ (Office Action at 8, citing Vandermersch FIG. 8 and[0046]-[0047].) Vandermersch teaches in the opposite direction. Vandermersch describes a multipoint control unit (MCU) that selects the ‘X’ most prominent inputs (e.g., the three loudest) from N participants, mixes those prominent inputs together into combined output packets, and broadcasts those combined output packets to the conference endpoints. The CSRC header of each RTP sub-packet merely identifies which participants’ audio was mixed into that combined output. (Vandermersch [0046]-[0047].) The output of Vandermersch’s MCU is, by design, a mixed signal the individual participant streams are destroyed (merged) in the process of creating the combined output packets. The CSRC label is merely a post-mix bookkeeping entry that identifies what was mixed. It does not preserve any individual stream in a format that encapsulates that individual stream with metadata for later synchronization with the other individual streams; the individual streams no longer exist as such” (Recited from pages 13-14 of Remarks). “Indeed, Vandermersch’s entire stated motivation is to reduce network traffic by transmitting a single combined packet stream rather than N independent participant streams. (Vandermersch ¶ [0022].) That motivation - reducing bandwidth by mixing streams together - teaches squarely away from the claimed requirement that each individual stream be converted into a format that encapsulates each stream with metadata items usable for synchronizing the streams. A skilled artisan reading Vandermersch would understand it to teach mixing, not encapsulation of individual streams. “The Examiner’s stated motivation to combine Vandermersch with Briggs likewise rests on ‘reduc[ing] global network traffic.’ (Office Action at 9.) That rationale, however, is fundamentally inconsistent with the claimed invention’s purpose, which is to preserve each participant’s individual stream as an independent track of a multi-track recording for downstream analysis - not to mix participant streams together to save bandwidth. There is no apparent reason a skilled artisan reading Briggs and Vandermersch would arrive at the claimed invention; the references push in different directions” (Recited from page 14 of Remarks).
As to point (C), Examiner respectfully disagrees, again, pointing out that Applicant argues features that are not claimed. In particular, in response to Applicant’s argument that the reference fails to show certain features of Applicant’s invention, it is noted that the features upon which Applicant relies (i.e., preserve individual streams in a format that encapsulates that individual stream with metadata for later synchronization with the other individual streams) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Again, the claim language of the independent claims says nothing to the effect of any “preservation” of any kind, moreover expressly recites “converting” (emphasis added), which apart any express definition in the instant Specification (which is silent in this regard) or indication in the claim language itself (also equally lacking), does not require that individual streams are preserved in any way. One of ordinary skill in the art would even readily appreciate that “conversion” would actually entail the lack of preservation, or otherwise, that streams are converted from one form to another. Moreover, while the limitation in question does recite “converting each of the one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items,” nevertheless, this in no way implies that there is any preservation of any kind. For this particular limitation, all that is required is that the streams are converted into a format that encapsulates the streams with at least one metadata item (i.e., one or more metadata items), and wherein the metadata items are “usable” (emphasis added), for synchronizing the one or more real-time communication streams. Examiner respectfully points out that 1), this is merely an intended use of the recited “metadata items,” as no actual synchronization is taking place in this particular limitation, and 2), the limitation (and the entirety of the claim) is completely silent as to exactly how the streams are being synchronized. Examiner respectfully reminds Applicant that a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. Examiner has shown Vandermersch to teach that from each of the X+1 UDP output streams that are constructed (See again, FIG. 8, at 806) every 20-30 milliseconds (ms), a corresponding UDP packet is constructed (See again, FIG. 8, at 808) which encapsulates “X+1” real-time protocol (RTP) sub-packets. Thus, if a conference hosts 5 participants, and the three loudest, or most prominent participants, are 3 out of the 5, then 3+1 = 4 RTP sub-packets are constructed. The first sub-packet is constructed by mixing all of the prominent participants (so all 3 loudest), while the remaining three sub-packets are formed by mixing all of the prominent participants, minus one. So in the given example, if the three loudest participants are participant “A,” participant “B,” participant “C,” then the first RTP sub-packet is constructed as “ABC,” the second as “AB,” the third as “AC,” and the fourth as “BC”. Each of the RTP sub-packets are encapsulated with metadata items, one of which includes a synchronization source (SSRC) field filled with an identifier of the multipoint control unit 814 (See again, Vandermersch, FIG. 8, paragraph [0047]). Vandermersch clearly teaches that the SSRC field provides for ensuring the streams are synchronized, as further evidenced in paragraph [0024], where Vandermersch discloses that the present invention may combine a minimal number of RTP streams with the same timestamp, but with different payloads, in the same UDP stream in order to reduce overhead and avoid synchronization issues (See Vandermersch, paragraph [0024]). For clarity, Examiner respectfully submits, it is the “X+1 UDP output streams” that are converted and encapsulated, which Examiner maps to the recited “one or more real-time communication streams”. Again, if preserving individual streams in a format that encapsulates that individual stream with metadata for later synchronization with the other individual streams is in fact a critical feature of the invention, then it should be present in the claim language. Accordingly, Examiner respectfully submits that the combination of Briggs, Vandermersch and Cohen does disclose the features of the claim language, as recited in the independent claims. Furthermore, Examiner respectfully reminds Applicant that a prior art reference does not teach away from the claimed subject matter unless the prior art reference criticizes, discredits, or otherwise discourages the solution claimed. See In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004); see also DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 567 F.3d 1314, 1327 (Fed. Cir. 2009) (“A reference does not teach away, however, if it merely expresses a general preference for an alternative invention but does not ‘criticize, discredit, or otherwise discourage’ investigation into the invention claimed.”) (citing Fulton). In response to Applicant’s argument that the Examiner’s rationale is fundamentally inconsistent with the claimed invention’s purpose, the fact that the inventor has recognized another advantage which would flow naturally from following the suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985). Therefore, Examiner respectfully submits, Vandermersch does disclose, teach and/or suggest, “converting each of the one or more real-time communication streams into a format that encapsulates each stream with one or more metadata items, the one or more metadata items being usable for synchronizing the one or more real-time communication streams,” as currently recited in the independent claims. Due to the amendment, however, Examiner has expanded on interpretation of the claim language and has elaborated on application of the references to assist the reader in understanding the rejection.
(D) Applicant argued on pages 15-16 of Remarks, “The Examiner relies on Cohen for ‘a multi-track recording composed by synchronizing one or more real-time communication streams based on one or more metadata items.’ (Office Action at 10, citing Cohen FIGS. 2 and 8 and col. 13, lines 24-34.) Cohen does not teach the claimed multi-track recording either. Cohen’s media sync module 244 is directed to the wholly different problem of synchronizing a server-side recording 214 of a particular participant’s content with a client-side recording 212 of the same participant’s content, for the purpose of replacing faulty or corrupted server-side segments with higher-quality client-side segments. (Cohen, col. 1, line 60 - col. 2, line 5; col. 13, lines 24-34.) That is a two-source, same-content quality remediation problem. “The claims require something architecturally and functionally different: synchronizing multiple different participants’ forked streams into a multi-track recording in which each participant’s contribution is preserved as an independent track. Cohen does not address that problem and provides no teaching of composing a multi-track output from multiple distinct participants. The Examiner’s stated motivation for combining Cohen - ‘enabling the replacement of faulty/corrupted media streams’ (Office Action at 11) - confirms the mismatch: that motivation addresses quality remediation of a single participant’s content, not composition of a multi-track recording from multiple participants. The combination, even if made, would not arrive at the claimed invention” (Recited from page 15 of Remarks). “An obviousness rejection must establish that the references, properly understood and combined for a sufficient and articulated reason, would have led a person of ordinary skill to the claimed invention. See MPEP § 2143; KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007). Here, each of the three references is being relied upon for a limitation that the reference does not in fact teach: Briggs is relied upon for forking, which it does not describe; Vandermersch is relied upon for individual-stream metadata encapsulation, while it teaches mixing of multiple streams into combined packets; and Cohen is relied upon for multi-participant multi-track composition, while it teaches quality remediation between two recordings of a single participant’s content. The stated rationales for combination - reducing bandwidth (Vandermersch) and replacing corrupted segments (Cohen) - point in directions opposite to the claimed invention’s purpose, which is the preservation of each participant’s individual stream as an independent, synchronized track of a multi-track recording made accessible to downstream tools at a conferencing service. Even assuming the three references could be combined for the reasons stated, the resulting system would not arrive at the claimed invention. The § 103 rejection should be withdrawn” (Recited from pages 15-16 of Remarks).
As to point (D), Examiner respectfully disagrees. Once again, in response to Applicant’s argument that the references (this time the reference to Cohen) fail to show certain features of Applicant’s invention, it is noted that the features upon which applicant relies (i.e., synchronizing multiple different participants’ forked streams into a multi-track recording in which each participant’s contribution is preserved as an independent track) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim language of the independent claims says absolutely nothing to the effect of any preservation of any kind, nor do the claims highlight individual contributions made by each participant. Indeed, the claims even fall completely silent with respect to exactly what the recited “multi-track recording” actually is. Importantly, the claims absolutely do not recite that the “multi-track recording” is comprised of individual tracks, whereby the tracks themselves are the individual “real-time communication streams”. Rather, with respect to the limitation in question, all the claims convey is that a “multi-track recording” is made accessible to one or more downstream tools for further processing or analysis at a conclusion at the conference - without going into any detail whatsoever as to what the downstream tools are or how they further process and/or analyze the “multi-track recording”. As well, while the claims do recite that the “multi-track recording” is composed by synchronizing the “one or more real-time communication streams,” nevertheless, the claims are equally silent as to exactly how the metadata items are used to perform such synchronization, and how the synchronization results in the recited “multi-track recording”. There is absolutely no indication whatsoever that the recited “metadata items” are being used “to preserve each participant’s contribution as an independent track” (emphasis added), much less how synchronization of the streams “preserves each participant’s contribution as an independent track”. To the contrary, the claims merely recite that the “multi-track recording” is composed by synchronizing the one or more real-time communication streams “based on” (emphasis added), the one or more metadata items, without going into any detail as what that means or entails. Again, Examiner respectfully reminds Applicant that claims are to be given the broadest reasonable interpretation, and that while claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Regarding the prior art, Examiner has shown Cohen to disclose composing a multi-track recording by synchronizing one or more real-time communication streams based on one or more metadata items. Examiner has cited FIG. 8 of Cohen, which illustrates an example process 800 of synchronizing media segments. In particular, process 800 illustrates an example method for synchronizing a segment of a live media stream with a segment of a local media stream. As discussed and shown at the rejection above, in process 800, timestamps (which Examiner has equated/mapped to the recited “metadata items”) are used to synchronize one or more segments of a live media stream 801 (which may correspond to a server-side recording 214 - See also FIG. 2) with a corresponding one or more segments of a local media stream 802 (which may correspond to client-side recording 212). As further shown above, Cohen teaches that timestamps aligned with a server clock 803 are applied to segments of live media stream 801 (e.g., by media server 220). At stage 804, the server-aligned timestamps are applied to segments of local media stream 802, thereby synchronizing the streams. At stage 805, the timestamps are used to identify segments of live media stream 801 that correspond to segments of local media stream 802. For example, it can be determined at stage 805 that a segment of live media stream 801 that has a particular timestamp corresponds to a segment of local media stream 802 that has the same timestamp (See again, Cohen, FIGS. 2 and 8, col. 13, ll. 24-44). Again, Examiner respectfully points out that the claims are silent as to what the “multi-track recording” is, and the claims fail to positively recite that the “multi-track recording” contains individual streams preserved as each participant’s contribution. Finally, if synchronizing multiple different participants’ forked streams into a multi-track recording in which each participant’s contribution is preserved as an independent track is in fact a critical feature of the invention, then it should be present in the claim language. Accordingly, Examiner respectfully submits that Cohen does disclose the features of the claim language, as currently recited in the independent claims. Furthermore, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Examiner has shown Briggs to incorporate the teachings of Vandermersch, (Briggs and Vandermersch both being analogous art as being directed to management of media streams during a conference), in order to result in a conferencing system that significantly reduced the number of packets sent over a network and as a result, reduced global network traffic and increased bandwidth, regardless of conference size (See again, Vandermersch, paragraph [0022]). Examiner has also shown the combination of Briggs-Vandermersch to further be modified by the teachings of Cohen (which is also directed to recording live media and conferencing) to enable the replacement of faulty/corrupted media streams (See Cohen, col. 1, l. 60-col. 2, l. 5). Examiner respectfully submits that all throughout the Remarks, Applicant has argued against unclaimed features. As such, Applicant’s arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Therefore, Examiner respectfully submits, the combination of Briggs, Vandermersch and Cohen does disclose, teach and/or suggest the claimed limitations as currently amended. Due to the amendment, however, Examiner has expanded on interpretation of the claim language and has elaborated on application of the references to assist the reader in understanding the rejection.
Conclusion
11. Applicant’s arguments, as well as request for reconsideration, filed May 27, 2026, have been fully considered, but they are not deemed to be persuasive.
12. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. 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, Kamal B. Divecha can be reached at 571-272-5863. 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.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2453
Prosecution Insights