DETAILED ACTION
Status of Claims:
Claims 1 – 22 are pending.
Claims 1, 12, and 20 – 21 are amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments in the amendments, filed 12/10/2025, have been fully considered but they are not persuasive. The reasons set for the below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 12, 20 – 22 are rejected under 35 U.S.C. 103 as being unpatentable over Relyea (US 9191431), in view of Boyer (US 20110225248), and further in view of Sarkar (US 10250914).
As per claim 1, Relyea discloses a computer-implemented method comprising:
receiving an indication by a broadcasting user to initiate a broadcast of an invite-to-join status for a livestream at a community hosting service (Media subsystem 104 may include a point-to-multipoint server device configured to receive a live video feed (indication of a broadcast) from a source user device 102 and to establish one or more connections between the source live video feed and one or more distribution live video feeds (invite-to-join) that media subsystem 104 transmits to one or more other user devices, See Col. 4, Lines 27 - 54);
receiving selected users in the community hosting service to receive the invite-to-join status, wherein the selected users are selected by the broadcasting user at a broadcasting user client device (A user device 102 may be configured to share the data with one or more other user devices 102 in conjunction with inviting the one or more other devices 102 to access shared media content. To illustrate, media subsystem 104 may assign a unique identifier to a live video included in source video feed 202 received from user device 102-1. Media subsystem 104 may provide data representative of the unique identifier to user device 102-1 for use by user device 102-1 to facilitate sharing of the live video with one or more other user devices 102-2 through 102-3, See Col. 6, Line 50 – Col. 7, Line 12);
sending a presence update including the invite-to-join status to the selected users (Media sharing facility 610 may access and use the presence information to send an invite message to one or more user devices 102 associated with user 112-2. The presence information may include any information potentially indicative of one or more user devices 102 being used or accessible by a user 112, See Col. 14, Lines 24 - 39) …
receiving a viewer selecting the invite-to-join status to join the livestream (When user device 102-2 receives the invite message, user device 102-2 may utilize the unique identifier and other information included in the message to access the live video from media subsystem 104, See Col. 6, Line 50 – Col. 7, Line 12), …
Relyea however does not expressly disclose:
sending a presence update using a presence channel.
Boyer discloses:
(sending a presence update) … using a presence channel (According to one embodiment, the state of the endpoints may be shared within the system through presence channel … The endpoints may receive the information from server 360 through subscribing to self-presence updates, See ¶32);
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Boyer’s teaching of sending a presence update using a presence channel, along with sending a presence update including the invite-to-join status to the selected users to improve Relyea’s system. Both Relyea and Boyer disclose systems for determining user presence via a presence update. Boyer’s system includes sharing the state of endpoints through a presence channel to receive presence updates. The combination is an improvement upon the existing system because a presence update including the invite-to-join status can be sent to selected users as taught by Relyea, where the presence update can be sent using a presence channel as taught by Boyer, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
The combination of Relyea and Boyer however does not expressly disclose:
wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet.
Sarkar discloses:
… wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet (The live video broadcast system determines whether the audience causes a triggering event to occur, to which the system responds by beginning the broadcast and providing the live video stream to the viewer client devices, See Col. 8, Lines 11 – 17 … The triggering event is a threshold audience size, where, upon a threshold number of viewers (threshold can include only first viewer) joining (e.g., being added to) the audience, the triggering event is satisfied, See Col. 4, Lines 18 - 47); and
after the receiving the first viewer selecting the invite-to-join status, creating and initiating the livestream of a display at a first viewer client device (In particular, the broadcast manager 704 manages the initialization of the live broadcast. For example, when the broadcaster 110 selects an option to begin a live broadcast, the broadcaster client device 106 begins transmitting a video stream, and the social networking system 101 receives the video stream by way of the video manager 702 as discussed above. However, in embodiments where the audience does not satisfy the triggering event, the social networking system 101 does not begin transmitting the video stream to the viewer client device 114a. The broadcast manager 704 maintains the live broadcast as a communication channel (creates and initiates the livestream only after a viewer has joined) between the broadcaster client device 106 and the viewer client device 114a but with no live video stream, See Col. 24, Lines 25 – 46).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Sarkar’s teaching of only a first viewer and no other viewers have selected to join a livestream and Boyer’s teaching of sending a presence update using a presence channel, along with a viewer selecting to join the livestream to improve Relyea’s system. Both Relyea, Boyer, and Sarkar all disclose systems for determining user presence. Sarkar’s system includes a triggering event to begin broadcasting of a live video steam where the triggering event is based on an audience size which can include a threshold of only a first viewer joining the livestream to initiate the livestream. The combination is an improvement upon the existing system because a viewer can select to join a livestream as taught by Relyea, where the viewer’s presence can be updated using a presence channel as taught by Boyer, and the viewer can further be a first viewer where no other viewers have selected to join the livestream as taught by Sarkar, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
As per claim 12, Relyea discloses a system comprising:
one or more processors; and
at least one computer readable medium storing computer readable instructions that, when executed by the one or more processors are effective to cause the system to:
receive an indication by a broadcasting user to initiate a broadcast of an invite-to-join status for a livestream at a community hosting service (Media subsystem 104 may include a point-to-multipoint server device configured to receive a live video feed (indication of a broadcast) from a source user device 102 and to establish one or more connections between the source live video feed and one or more distribution live video feeds (invite-to-join) that media subsystem 104 transmits to one or more other user devices, See Col. 4, Lines 27 - 54);
receive selected users in the community hosting service to receive the invite-to-join status, wherein the selected users are selected by the broadcasting user at a broadcasting user client device (A user device 102 may be configured to share the data with one or more other user devices 102 in conjunction with inviting the one or more other devices 102 to access shared media content. To illustrate, media subsystem 104 may assign a unique identifier to a live video included in source video feed 202 received from user device 102-1. Media subsystem 104 may provide data representative of the unique identifier to user device 102-1 for use by user device 102-1 to facilitate sharing of the live video with one or more other user devices 102-2 through 102-3, See Col. 6, Line 50 – Col. 7, Line 12);
send a presence update including the invite-to-join status to the selected users (Media sharing facility 610 may access and use the presence information to send an invite message to one or more user devices 102 associated with user 112-2. The presence information may include any information potentially indicative of one or more user devices 102 being used or accessible by a user 112, See Col. 14, Lines 24 - 39) …
receive a viewer selecting the invite-to-join status to join the livestream (When user device 102-2 receives the invite message, user device 102-2 may utilize the unique identifier and other information included in the message to access the live video from media subsystem 104, See Col. 6, Line 50 – Col. 7, Line 12), …
Relyea however does not expressly disclose:
send a presence update using a presence channel.
Boyer discloses:
(send a presence update) … using a presence channel (According to one embodiment, the state of the endpoints may be shared within the system through presence channel … The endpoints may receive the information from server 360 through subscribing to self-presence updates, See ¶32);
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Boyer’s teaching of sending a presence update using a presence channel, along with sending a presence update including the invite-to-join status to the selected users to improve Relyea’s system. Both Relyea and Boyer disclose systems for determining user presence via a presence update. Boyer’s system includes sharing the state of endpoints through a presence channel to receive presence updates. The combination is an improvement upon the existing system because a presence update including the invite-to-join status can be sent to selected users as taught by Relyea, where the presence update can be sent using a presence channel as taught by Boyer, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
The combination of Relyea and Boyer however does not expressly disclose:
wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet.
Sarkar discloses:
… wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet (The live video broadcast system determines whether the audience causes a triggering event to occur, to which the system responds by beginning the broadcast and providing the live video stream to the viewer client devices, See Col. 8, Lines 11 – 17 … The triggering event is a threshold audience size, where, upon a threshold number of viewers (threshold can include only first viewer) joining (e.g., being added to) the audience, the triggering event is satisfied, See Col. 4, Lines 18 - 47); and
in response to the receiving the first viewer selecting the invite-to-join status, create and initiate the livestream of a display at a first viewer client device (In particular, the broadcast manager 704 manages the initialization of the live broadcast. For example, when the broadcaster 110 selects an option to begin a live broadcast, the broadcaster client device 106 begins transmitting a video stream, and the social networking system 101 receives the video stream by way of the video manager 702 as discussed above. However, in embodiments where the audience does not satisfy the triggering event, the social networking system 101 does not begin transmitting the video stream to the viewer client device 114a. The broadcast manager 704 maintains the live broadcast as a communication channel (creates and initiates the livestream only after a viewer has joined) between the broadcaster client device 106 and the viewer client device 114a but with no live video stream, See Col. 24, Lines 25 – 46).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Sarkar’s teaching of only a first viewer and no other viewers have selected to join a livestream and Boyer’s teaching of sending a presence update using a presence channel, along with a viewer selecting to join the livestream to improve Relyea’s system. Both Relyea, Boyer, and Sarkar all disclose systems for determining user presence. Sarkar’s system includes a triggering event to begin broadcasting of a live video steam where the triggering event is based on an audience size which can include a threshold of only a first viewer joining the livestream to initiate the livestream. The combination is an improvement upon the existing system because a viewer can select to join a livestream as taught by Relyea, where the viewer’s presence can be updated using a presence channel as taught by Boyer, and the viewer can further be a first viewer where no other viewers have selected to join the livestream as taught by Sarkar, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
As per claim 20, Relyea discloses a non-transitory computer-readable medium comprising instructions stored thereon, the instructions effective to cause one or more processors to:
receive an indication by a broadcasting user to initiate a broadcast of an invite-to-join status for a livestream at a community hosting service (Media subsystem 104 may include a point-to-multipoint server device configured to receive a live video feed (indication of a broadcast) from a source user device 102 and to establish one or more connections between the source live video feed and one or more distribution live video feeds (invite-to-join) that media subsystem 104 transmits to one or more other user devices, See Col. 4, Lines 27 - 54);
receive selected users in the community hosting service to receive the invite-to-join status, wherein the selected users are selected by the broadcasting user at a broadcasting user client device (A user device 102 may be configured to share the data with one or more other user devices 102 in conjunction with inviting the one or more other devices 102 to access shared media content. To illustrate, media subsystem 104 may assign a unique identifier to a live video included in source video feed 202 received from user device 102-1. Media subsystem 104 may provide data representative of the unique identifier to user device 102-1 for use by user device 102-1 to facilitate sharing of the live video with one or more other user devices 102-2 through 102-3, See Col. 6, Line 50 – Col. 7, Line 12);
send a presence update including the invite-to-join status to the selected users (Media sharing facility 610 may access and use the presence information to send an invite message to one or more user devices 102 associated with user 112-2. The presence information may include any information potentially indicative of one or more user devices 102 being used or accessible by a user 112, See Col. 14, Lines 24 - 39);
receive a viewer selecting the invite-to-join status to join the livestream (When user device 102-2 receives the invite message, user device 102-2 may utilize the unique identifier and other information included in the message to access the live video from media subsystem 104, See Col. 6, Line 50 – Col. 7, Line 12), …
Relyea however does not expressly disclose:
send a presence update using a presence channel.
Boyer discloses:
(send a presence update) … using a presence channel (According to one embodiment, the state of the endpoints may be shared within the system through presence channel … The endpoints may receive the information from server 360 through subscribing to self-presence updates, See ¶32);
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Boyer’s teaching of sending a presence update using a presence channel, along with sending a presence update including the invite-to-join status to the selected users to improve Relyea’s system. Both Relyea and Boyer disclose systems for determining user presence via a presence update. Boyer’s system includes sharing the state of endpoints through a presence channel to receive presence updates. The combination is an improvement upon the existing system because a presence update including the invite-to-join status can be sent to selected users as taught by Relyea, where the presence update can be sent using a presence channel as taught by Boyer, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
The combination of Relyea and Boyer however does not expressly disclose:
wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet.
Sarkar discloses:
… wherein the viewer is a first viewer, and no other viewer has selected the invite-to-join status to join the livestream yet (The live video broadcast system determines whether the audience causes a triggering event to occur, to which the system responds by beginning the broadcast and providing the live video stream to the viewer client devices, See Col. 8, Lines 11 – 17 … The triggering event is a threshold audience size, where, upon a threshold number of viewers (threshold can include only first viewer) joining (e.g., being added to) the audience, the triggering event is satisfied, See Col. 4, Lines 18 - 47); and
in response to the receiving the first viewer selecting the invite-to-join status, initiate the livestream of a display at a first viewer client device (In particular, the broadcast manager 704 manages the initialization of the live broadcast. For example, when the broadcaster 110 selects an option to begin a live broadcast, the broadcaster client device 106 begins transmitting a video stream, and the social networking system 101 receives the video stream by way of the video manager 702 as discussed above. However, in embodiments where the audience does not satisfy the triggering event, the social networking system 101 does not begin transmitting the video stream to the viewer client device 114a. The broadcast manager 704 maintains the live broadcast as a communication channel (creates and initiates the livestream only after a viewer has joined) between the broadcaster client device 106 and the viewer client device 114a but with no live video stream, See Col. 24, Lines 25 – 46).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Sarkar’s teaching of only a first viewer and no other viewers have selected to join a livestream and Boyer’s teaching of sending a presence update using a presence channel, along with a viewer selecting to join the livestream to improve Relyea’s system. Both Relyea, Boyer, and Sarkar all disclose systems for determining user presence. Sarkar’s system includes a triggering event to begin broadcasting of a live video steam where the triggering event is based on an audience size which can include a threshold of only a first viewer joining the livestream to initiate the livestream. The combination is an improvement upon the existing system because a viewer can select to join a livestream as taught by Relyea, where the viewer’s presence can be updated using a presence channel as taught by Boyer, and the viewer can further be a first viewer where no other viewers have selected to join the livestream as taught by Sarkar, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
As per claim 21, the method of claim 1, wherein the indication by the broadcasting user does not create or initiate the livestream (Boyer, In particular, the broadcast manager 704 manages the initialization of the live broadcast. For example, when the broadcaster 110 selects an option to begin a live broadcast, the broadcaster client device 106 begins transmitting a video stream, and the social networking system 101 receives the video stream by way of the video manager 702 as discussed above. However, in embodiments where the audience does not satisfy the triggering event, the social networking system 101 does not begin transmitting the video stream to the viewer client device 114a. The broadcast manager 704 maintains the live broadcast as a communication channel (creates and initiates the livestream only after a viewer has joined and not just from indication by broadcasting user) between the broadcaster client device 106 and the viewer client device 114a but with no live video stream, See Col. 24, Lines 25 – 46).
As per claim 22, the method of claim 1, wherein the invite-to-join status triggers a graphical update indicating that the broadcasting user is ready to initiate a broadcast (Relyea, Window 906 may also include a custom message provided by the sending user. In the illustrated example, the custom message indicates the child's game (e.g., Amy's soccer game) has started and is the content of the shared live video that will be presented if the user actuates the “OK” button.).
Claim(s) 2, 5 – 6, 9 – 11, 13 and 16 – 17 are rejected under 35 U.S.C. 103 as being unpatentable over Relyea (US 9191431), in view of Boyer (US 20110225248), in view of Sarkar (US 10250914), and further in view of Bernstein (US 10455291).
As per claim 2, the combination of Relyea, Boyer, and Sarkar discloses all limitations of claim 1.
The combination of Relyea, Boyer, and Sarkar however does not expressly disclose
wherein the selected users include a selection of a community server that includes a plurality of community users that are also included in the selected users.
Bernstein discloses:
the computer-implemented method of claim 1, wherein the selected users include a selection of a community server that includes a plurality of community users that are also included in the selected users (An interactive streaming application 132 may be configured to enable a user of the computing device 102 to start a real-time video stream and share the real-time video stream via a social media platform … A private broadcast may be viewable only by those selected by the broadcaster. For example, the broadcaster may select some or all of those directly connected to the broadcaster in a connection graph (e.g., connection graph 142 or 168), See Col. 6, Lines 1 - 36 … The interactive streaming application 132 may be configured to provide the real-time video stream from a broadcasting computing device 102 to a server … the server 160 is a social media platform server (community server), See Col. 9, Lines 42 - 57).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Bernstein’s teaching of a selection of a community server that includes selected users, Sarkar’s teaching of only a first viewer and no other viewers have selected to join a livestream, and Boyer’s teaching of sending a presence update using a presence channel, along with a viewer selecting to join the livestream to improve Relyea’s system. Relyea, Boyer, Sarkar, and Bernstein all disclose systems for broadcasting live streaming video. Bernstein’s system includes selecting users by a broadcaster based on the selection of a social media platform. The combination is an improvement upon the existing system because a viewer can select to join a livestream as taught by Relyea, where the viewer’s presence can be updated using a presence channel as taught by Boyer, and the viewer can be a first viewer where no other viewers have selected to join the livestream as taught by Sarkar, where the viewer can further be a selected user included in the selection of a community server as taught by Bernstein, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
As per claim 5, the computer-implemented method of claim 1, wherein prior to the receiving the viewer selecting the invite-to-join status, the broadcasting user continues to engage at the broadcasting user client device for a period of time after the invite-to-join status is available to the selected users (Bernstein, Media subsystem 104 may receive source video feed 202 from user device 102-1 associated with user 112-1, identify one or more other users 112 and/or user devices 102 associated with user 112-1 and/or user device 102-1 (e.g., users 112 and/or user devices 102 that have shared live video with user 112-1 and/or user device 102-1 in the past and/or that are part of a defined group of users that includes user 112-1), and process the live video received in source video feed 202 to prepare for distribution of the live video to one or more other user devices 102 if requested by the one or more other user devices 102, See Col. 5, Line 63 – Col. 6, Line 17).
As per claim 6, the computer-implemented method of claim 1, wherein the presence update including the invite-to-join status includes metadata that correlates to the selected users (Bernstein, The interactive streaming application 132 may also be configured to receive engagement indications as well as metadata about the real-time video stream from the servers 160, 161. The engagement indications may be in a data stream that is associated with the video stream. The metadata may include information such as how many viewers have joined the real-time video stream and are currently viewing the video stream, See Col. 7, Lines 12 - 36).
As per claim 9, the computer-implemented method of claim 1, further comprising:
prior to the receiving the viewer selecting the invite-to-join status, capturing a preview of the display of the broadcasting user client device (Bernstein, The video discovery engine 174 may initiate a user interface that shows the location of the real-time video streams and enables a user to select one of the real-time video streams for preview of viewing, See Col. 12, Lines 38 - 55); and
storing the preview in association with the invite-to-join status (The user may navigate in a map that includes an icon representing the location of live video streams and the user may select an icon to join or preview the live video stream associated with the location, See Col. 12, Lines 38 - 55).
As per claim 10, the computer-implemented method of claim 9, wherein the captured preview is updated at a predefined time interval (Bernstein, The system may select a few live video streams for the head of the list with a large preview of the broadcast and the remainder may have thumbnail views. In some implementations, the preview may include a few seconds of video (predefined intervals) from the live video stream, e.g., a few seconds of the video that are associated with a large quantity of signals of appreciation. The previews may be selectable, so that the user can join a live video stream by selecting the preview or thumbnail in the area 405, See Col. 20, Lines 24 - 57).
As per claim 11, the computer-implemented method of claim 1, further comprising: receiving permissions from the broadcasting user to allow the selected users to invite other users in their respective networks to see the invite-to-join status for the livestream and join the livestream (Bernstein, One of the viewers may also share the real-time video stream. Sharing may occur for public broadcasts and can occur with broadcaster permission in a private broadcast. When sharing occurs, the system may send a push notification to followers of the viewer who initiated the share (740), See Col. 25, Line 52 – Col. 26, Line 13).
As per claim 13, the system of claim 12, wherein the selected users include a selection of a community server that includes a plurality of community users that are also included in the selected users (Bernstein, An interactive streaming application 132 may be configured to enable a user of the computing device 102 to start a real-time video stream and share the real-time video stream via a social media platform … A private broadcast may be viewable only by those selected by the broadcaster. For example, the broadcaster may select some or all of those directly connected to the broadcaster in a connection graph (e.g., connection graph 142 or 168), See Col. 6, Lines 1 - 36 … The interactive streaming application 132 may be configured to provide the real-time video stream from a broadcasting computing device 102 to a server … the server 160 is a social media platform server (community server), See Col. 9, Lines 42 - 57).
As per claim 16, the system of claim 12, wherein prior to the receiving the viewer selecting the invite-to-join status, the broadcasting user continues to engage at the broadcasting user client device for a period of time after the invite-to-join status is available to the selected users (Bernstein, Media subsystem 104 may receive source video feed 202 from user device 102-1 associated with user 112-1, identify one or more other users 112 and/or user devices 102 associated with user 112-1 and/or user device 102-1 (e.g., users 112 and/or user devices 102 that have shared live video with user 112-1 and/or user device 102-1 in the past and/or that are part of a defined group of users that includes user 112-1), and process the live video received in source video feed 202 to prepare for distribution of the live video to one or more other user devices 102 if requested by the one or more other user devices 102, See Col. 5, Line 63 – Col. 6, Line 17).
As per claim 17, the system of claim 12, wherein the presence update including the invite-to-join status includes metadata that correlates to the selected users (Bernstein, The interactive streaming application 132 may also be configured to receive engagement indications as well as metadata about the real-time video stream from the servers 160, 161. The engagement indications may be in a data stream that is associated with the video stream. The metadata may include information such as how many viewers have joined the real-time video stream and are currently viewing the video stream, See Col. 7, Lines 12 - 36).
Claim(s) 7 – 8 and 18 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over Relyea (US 9191431), in view of Boyer (US 20110225248), in view of Sarkar (US 10250914), and further in view of Boyd (US 20230412553).
As per claim 7, the combination of Relyea, Boyer, and Sarkar discloses all limitations of claim 1.
The combination of Relyea, Boyer, and Sarkar however does not expressly disclose
wherein a client device associated with the viewer is equipped with audio input capabilities to participate in the livestream by contributing their own audio.
Boyd discloses:
the computer-implemented method of claim 1, wherein a client device associated with the viewer is equipped with audio input capabilities to participate in the livestream by contributing their own audio (FIG. 3B illustrates that the gamer/streamer 200 may stream the gameplay through the server(s) 240 to a friend 300 so that the friend 300 (client device with audio input capabilities) can help or coach the gamer 200 and, if the friend 300 is also playing the same game instance, so that the gamer 200 can also help or coach the viewer 300. Thus, it is to be understood that audio of the gamer 200 speaking as detected by a local microphone proximate to the gamer 200 may be streamed to the viewer 300, and vice versa, See ¶36).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Boyd’s teaching of a viewer equipped with audio input capabilities to participate in the livestream, Sarkar’s teaching of only a first viewer and no other viewers have selected to join a livestream, and Boyer’s teaching of sending a presence update using a presence channel, along with a viewer selecting to join the livestream to improve Relyea’s system. Relyea, Boyer, Sarkar, and Boyd all disclose systems for broadcasting live streaming video. Boyd’s system includes a viewer who’s speaking can be detected via microphone during a stream. The combination is an improvement upon the existing system because a viewer can select to join a livestream as taught by Relyea, where the viewer’s presence can be updated using a presence channel as taught by Boyer, and the viewer can be a first viewer where no other viewers have selected to join the livestream as taught by Sarkar, where the viewer can further be viewer equipped with audio input capabilities to participate in the livestream as taught by Boyd, to allow a seamless system of broadcasting a livestream based on the number of viewers who have joined using an invite.
As per claim 8, the computer-implemented method of claim 7, further comprising:
receiving an indication by the broadcasting user to include quiet viewers, wherein the quiet viewers join the livestream without audio capabilities (Boyd, FIG. 14 then shows another situation where certain viewers might be muted from audio chat or simply cannot speak for whatever reason, ¶77); and
receiving one or more quiet viewers during the livestream (Boyd, Again a group of friends are playing a game together while others might just be viewing the collective gameplay of the gamers and hanging out. If some viewers do not have microphone access, are muted, etc., then those viewers can still participate in the fun by throwing some reactions 1400 on the screen 1410, ¶77).
As per claim 18, the system of claim 12, wherein a client device associated with the viewer is equipped with audio input capabilities to participate in the livestream by contributing their own audio (Boyd, FIG. 3B illustrates that the gamer/streamer 200 may stream the gameplay through the server(s) 240 to a friend 300 so that the friend 300 (client device with audio input capabilities) can help or coach the gamer 200 and, if the friend 300 is also playing the same game instance, so that the gamer 200 can also help or coach the viewer 300. Thus, it is to be understood that audio of the gamer 200 speaking as detected by a local microphone proximate to the gamer 200 may be streamed to the viewer 300, and vice versa, See ¶36).
As per claim 19, the system of claim 18, further comprising:
receiving an indication by the broadcasting user to include quiet viewers, wherein the quiet viewers join the livestream without audio capabilities (Boyd, FIG. 14 then shows another situation where certain viewers might be muted from audio chat or simply cannot speak for whatever reason, ¶77); and
receiving one or more quiet viewers during the livestream (Boyd, Again a group of friends are playing a game together while others might just be viewing the collective gameplay of the gamers and hanging out. If some viewers do not have microphone access, are muted, etc., then those viewers can still participate in the fun by throwing some reactions 1400 on the screen 1410, ¶77).
Allowable Subject Matter
Claims 3 – 4 and 14 – 15 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.
Remarks
Applicant s arguments, with regards to independent claim 1 filed on 12/10/2025 have been fully considered but they are not persuasive. The current arguments are based on independent claim 1 which are present in the remarks by the applicant.
With respect to independent claim 1, Applicant argues that Reylea does not disclose “sending a presence update including the invite-to-join status to the selected users using a presence channel.” Examiner responds that the combination of Reylea and Boyer discloses the claimed limitation. Reylea teaches accessing presence information to send a broadcast invite to users (Col. 14, Lines 24 - 39) and Boyer teaches sending presence updates via a presence channel (¶32). The combination of the systems allows presence information of users invited to join a broadcast to be determined as taught by Reylea where the that presence information can further be determined using a presence channel as taught by Boyer. Hence the combination of Reylea and Boyer teaches the claimed limitation in entirety.
Applicant also argues that Reylea does not disclose “after the receiving the first viewer selecting the invite-to-join status, creating and initiating the livestream of a display at a first viewer client device.” Examiner responds that while Reylea may only disclose initiating a livestream, Sarker discloses creating and initiating a livestream after receiving a first viewer. For example, Sarker teaches that when a triggering event occurs based on a threshold number of viewers joining the livestream, only then is the livestream created and initiated for broadcast. Until then, the system simply creates a communication channel without any live video (Col. 24, Lines 25 – 46). Hence, Sarker discloses the claim limitation as required.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAZIA NAOREEN whose telephone number is (571)270-7282. The examiner can normally be reached M-F: 9:00 - 6:00.
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, Umar Cheema can be reached at 571-270-3037. 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.
/NAZIA NAOREEN/Primary Examiner, Art Unit 2458