BACKGROUND

[0001] This disclosure generally relates to live streams, and more specifically, to generating anchors in a live stream to enable users that are joining or rejoining the live stream to enter at an opportune time.

[0002] Stream hosting servers, serve as a platform for stream creators to provide live streams to users of the stream hosting server. In many scenarios, a user uses a client device to access and join the live stream. For popular streams, a creator of a stream may achieve large numbers of viewers who are interested in the information being presented by the creator.

100031 However, a problem unique to live streams is that viewers may join at various, suboptimal times. For example, the creator may be in the middle of a discussion when a viewer joins and thus, the viewer may not have the proper context to fully understand the ongoing discussion. This scenario may occur when a user is newly joining the live stream or when the user is rejoining the live stream after previously having been diverted away. Joining a live stream at a suboptimal moment leads to a poor user experience and may even demotivate users from partaking in future live streams.

SUMMARY

[0004] A stream hosting server generates anchors in a live stream that enables users that are newly joining to begin consuming the streaming content at an opportune time point, even if the userjoins at a suboptimal time. The stream hosting server provides a platform for a creator to transmit live streams. At various time points during the live stream, the server provides user interface elements that receive creator input indicating that a time point is appropriate for the generation of a live stream anchor. For example, the user interface elements receive an input to create an anchor when the creator is moving on to discuss a new subject matter. In another example, the live stream is a streaming video game and the user interface elements receive an input to generate an anchor corresponding to a timestamp in the live stream when a new game is starting. Each anchor specifies a timestamp of the live stream as well as a validity duration. The validity duration of the anchor describes how long the anchor remains valid such that users that join can start watching the live stream at the anchor if the anchor is valid.

100051 A viewer client device provides a request to the stream hosting server to join a live stream. The request sent by the client device is sent at a particular time and is therefore, associated with a timestamp of the live stream. In one embodiment, the stream hosting server analyzes the list of generated anchors and identifies an appropriate anchor from which the viewer client device will begin accessing the live stream. The appropriate anchor is selected based on the timestamp of the live stream specified by the anchor and the validity duration associated with the anchor. The stream hosting server prov ides the live stream to the viewer client device beginning at the timestamp specified by the identified anchor. Thus, the present disclosure addresses the technical problem of viewer navigation within the live stream, and may achieve the technical effect that a viewer is able to locate and view interesting content more rapidly than if the anchors were not present. Furthermore, the disclosure may achieve the technical effect of making it unnecessary for the user to view content which is uninteresting to him or her, or even incomprehensible, due to the viewer not having viewed the immediately preceding portion of the live stream.

[0006] The stream hosting server may also be capable of generating video on demand (VOD) content derived from a completed live stream. Additionally, the generated anchors associated with the completed live stream are also included in the created VOD. The anchors in the VOD serve multiple purposes. In one scenario, the VOD can be presented by a viewer client device to a user. Upon receiving user inputs, the viewer client device can display the VOD at different timestamps that are specified by the anchors associated with the VOD. This is desirable in gaming streams where conversational scenes of a VOD can be rapidly skipped over. Thus, the VOD with associated anchors enables skipping to the beginning of the next game.

[0007] Additionally, the anchors in a VOD may be tagged with a subject matter tag such as a keyword. When the stream hosting server receives a query including a keyword (or subject matter tag more generally), the stream hosting serv er returns a list of anchors that are relevant to the provided keyword. Thus, the server enables a viewer client device to access a VOD beginning at an anchor with a particularly relevant subject as opposed to hav ing to display the VOD from the beginning.

[0008] The disclosure provides computer-implemented methods, computer systems for implementing the methods, and computer program products comprising computer program instructions for implementing the method. Each computer program product is typically a non-transitory computer readable medium. However, in principle the computer program product may also be a signal transmitted over a communication network. 1000 1 Some computer-implemented methods contained in the di sclosure are expressed by claims 1 and 13, and some computer programs products contained in the disclosure are expressed in claims 1 2 and20.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 is a system environment of a stream hosting server, in accordance with an embodiment.

[0011] FIG. 2 depicts the architecture of the live stream module, in accordance with an embodiment.

[0012] FIG. 3 A depicts the architecture of a software module of the creator client device, in accordance with an embodiment.

[0013] FIG. 3B depi cts the architecture of a software module of the viewer client device, in accordance with an embodiment.

[0014] FIG. 4 is an example flow chart of providing, by the stream hosting server, a live stream based on a generated anchor, in accordance with an embodiment.

[0015] FIG. 5 is an example flow chart of playing back, by a viewer client device, a live stream according to a generated anchor, in accordance with an embodiment.

[0016] The figures depict various embodiments for purposes of illustration only. One skil led in the art will readily recognize from the fol lowing discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the di sclosure described herein.

DETAILED DESCRIPTION OVERVIEW OF SY STEM ENVIRONMENT

[0017] FIG. 1 depicts a system environment 100 of a stream hosting server 1 50 for prov iding a live stream, in accordance with an embodiment. The system environment 100 includes a creator client device 108, a viewer client device 1 10, a network 130, and a stream hosting server 150.

[0018] Turning to the individual entities illustrated in FIG. 1, the creator client device 108 and the viewer client device 1 10 generate a l ive stream and accesses a live stream, respectively. As used herein, a "live stream" relates to any streamed media content distributed between creators and viewers (or li steners, in the case of audio content), regardless of whether that content is broadcast, multicast, or directly exchanged between a creator and a single viewer. [0019] Each of the creator client device 108 and the viewer client device 1 10 is a computing device with a software module 300A/B that transmits and/or receives data via the network 130. Examples of the creator client devices 108 and viewer client devices 1 10 include desktop computers, laptop computers, tablet computers (pads), mobile phones, personal digital assi stants (PDAs), gaming devices, or any other electronic device including computing functionality and data communication capabilities. The creator client device 108 and viewer client device 1 10 may each use a web browser, such as Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Apple Safari and/or Opera, as an interface to connect with the network 130. Additionally or alternatively, specialized application software that runs nativ ely on a mobile dev ice is used as an interface to connect to the network 130. The creator 108 and viewer client devices 110 typically include a processor, a display dev ice (or output to a display dev ice), a local storage, such as a hard driv e or flash memory dev ice, to whi h the creator 108 and viewer client dev ices 1 10 store data used by the user in performing tasks, and a network interface for coupling to the stream hosting serv er 1 50 via the network 130. Although FIG. I depicts one creator client dev ice 108 and one viewer client dev ice 1 10, one skilled in the art may appreciate that any number of creator client dev ices 108 and viewer client dev ices 1 10 may exist in the system architecture in communication with the network 130 and the stream hosting server 150.

100201 The creator client dev ice 108 is used by a creator to generate a liv e stream . The creator client device 108 receives user inputs through the user interface 1 80. For example, creator client dev ice 108 (e.g. a laptop) receives inputs that instruct the creator client device 108 to use software or hardware to continuously capture video and audio in real time or near-real time for generating the live stream. In various embodiments, the creator client dev ice 108 also includes a software module 00 A that appropriately processes the video and audio of the liv e stream as it is recorded. The creator client dev ice 108 then continuously transmits the stream to the stream hosting server 1 50 until the stream ends. 100211 The viewer client dev ice 1 10 sends a request to access the liv e stream and upon receiv ing the liv e stream, begins to access the liv e stream at a timestamp specified by an anchor associated with the liv e stream. The viewer client dev ice 1 10 includes a user interface 1 80 and a software module 300B that together handle the interaction between a user of the viewer client dev ice 1 10 and content provided by the stream hosting server 150.

[0022] For example, the user interface 1 80 of the viewer client dev ice 1 10 receives a user input (e.g. a click, a touch input) to join a live stream. The software module 30QB sends a join request to the stream hosting server 150 for the live stream. At a time subsequent to sending the join request, the software module 300B receives the live stream with an identified anchor that specifies a timestamp of the live stream. Upon receiving the live stream, the software module 300B appropriately decodes the video and audio of the live stream for playback on the user interface 180 of the viewer client device 1 10. The viewer client device 1 0 proceeds to display the live stream beginning at the timestamp specified by the anchor.

[0023] The stream hosting server 150 i s responsible for receiving live streams from creator client devices 108, generating anchors associated with the live stream under a variety of circumstances, for example in response to an anchor generation request from a creator client device 108, and providing the liv e stream for playback on a number of different viewer client devices, each possibly starting and progressing forward from di ferent timestamps within the stream as specified by one or more anchors. In an example embodiment, the stream hosting server 150 includes a live stream module 200, content server 104, ingest server 106, content store 120.

10024] The live stream module 200 handles live streams. On the server side, the live stream module 200 receiv es a stream to be transmitted to viewer client dev ices 1 10 and also receives anchor generation requests. As introduced above, each anchor specifies a timestamp in the live stream such that the liv e stream module 200 can provide the liv e stream to a viewer client device 1 10 beginning at the timestamp. On the viewer side, the live stream module 200 receiv es join requests from one or more viewer client devices 1 10 tojoin the live stream. The live stream module 200 analyzes and identifies an appropriate anchor associated with the live stream for each join request. The live stream module 200 prov ides the viewer client device 1 0 with the live stream and the anchor specifying a timestamp in the live stream such that the viewer client device 1 10 can begin playing the live stream beginning at the ti mestamp. Further details regarding the live stream module 200 is described below i n regards to FIG. 2.

[0025] The live stream module 200 is also responsible for providing content items (e.g. video advertisements) to viewer client devices 1 10. For example, the content item may be originally provided by a third party system (e.g. an advertiser) and receiv ed by the ingest server 106. The ingest server 106 handles the prov ided content item and stores the content item in the content store 120. The content server 104 retrieves a content item that is located in the content store 120 and serv es the content item to a viewer client device 1 10 to be displayed on the user interface 1 80 of the viewer client device 1 10. As one example, the content item is to be displayed on the viewer client device 1 1 0 to temporarily replace the live stream . Once the viewer client dev ice 1 10 plays the content item for its duration, the viewer client device 1 10 returns to playing the live stream at a generated anchor.

[0026] The network 130 facilitates communications amongst one or more client devices 1 10 and the stream hosting server 150. The network 1 30 may be any wired or wireless local area network (LAN) and/or wide area network ( WAN), such as an intranet, an extranet, or the Internet. In various embodiments, the network 1 30 uses standard communication technologies and/or protocols. Examples of technologies used by the network 1 30 include Ethernet, 802. 1 1, 3G, 4G, 802. 16, or any other suitable

communication technology. The network 130 may use wireless, wired, or a combination of wireless and wired communication technologies. Examples of protocols used by the network 130 include transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), file transfer protocol (TCP), or any other suitable communication protocol .

LI V E STREAM MODULE

[0027] FIG . 2 depicts the live stream module 200 and its associated modules, in accordance with an embodiment. In this example embodiment, the live stream module 200 incl udes an anchor generation module 2 1 0. a stream communication module 220, an anchor analyzer module 230. an anchor l ist 240, a video on demand (VOD) generator module 250, and a search module 260. In some embodiments, the live stream module 200 has different modules and/or logical structures than the ones described herein, and the functions can be distributed among the modules and/or logical structures in a different manner than described here.

100281 The anchor generation module 2 1 0 generates one or more anchors to be associated with a live stream. Each anchor represents an opportune timestamp in the live stream for the viewer cl ient dev ice 1 10 to access the live stream . For example, in a gaming stream, an anchor may be associated with a time point corresponding to the beginning of a new game. As another example, a creator may switch from a first subject to a second subject during a live stream.

100291 The anchor generation module 2 1 0 permits a creator to create an anchor through the graphical user interface 1 80 presented on the creator client device 1 08. The creator can choose to place an anchor at the current timestamp of the ongoing live stream at his/her discretion. For example, the creator provides a user inp t ( e.g. a click on a button or a drag and drop ) on the graphical user interface. As another example, the creator may, at a later time, manually specify a timestamp occurring earlier in the live stream to generate an anchor. This is useful for a creator that may have forgotten to generate anchors in real-time. In response to a user input to generate an anchor in the live stream, the creator client device 1 08 sends an anchor generation request to the anchor generation module 2 10 which then proceeds to generate the anchor. In various embodiments, the anchor generation module 2 10 may provide notifications to viewer client devices 1 10 that are currently accessing the live stream when the new anchor is generated.

100301 Each anchor is associated with the live stream and specifies: 1) a timestamp within the duration of the live stream and 2) a validity duration. For example, the timestamp of the live stream corresponds to the time point in the live stream that coincided with when the creator prov ided the input to create the anchor. As another example, the timestamp corresponds to the time that is manually specified by the creator.

100311 The validity duration of an anchor describes a period of time that the anchor is valid for after being generated. Once the validity duration of an anchor expires, a viewer client dev ice 1 10 can no longer access the live stream beginning at that anchor. In some embodiments, the validity duration of an anchor i s predetermined by the anchor generation module 2 10. In other embodiments, the validity duration of each anchor may be manually specified by the creator. For example, before the live stream begins, the anchor generation module 210 may prompt the creator to enter a default validity duration (e.g. 5 minutes) for each anchor that is to be generated during the live stream. Additionally, the anchor generation module 210 may prompt the creator to enter a validity duration for each generated anchor in real-time (e.g. immediately after the creator specifies the creation of an anchor).

100321 The generation of an anchor may also be performed automatically by the anchor generation module 2 10 without intervention from the creator. The anchor generation module 2 10 may implement a machine learning model that analyzes the preferences and/or characteristics of the creator to understand the likely position of an appropriate anchor. For example, a creator may be prone to a moment of silence that lasts beyond a threshold time as the creator contemplates what to say for the next subject matter.

Therefore, the machine learning model may choose to embed an anchor in the live stream when a longer than threshold silence duration occurs in the stream. As another example, a creator may use a particular phrase that indicates that a new topic is starting (e.g. "Okay, shifting gears . . . "). The machine learning model may be specifically trained to recognize the tendencies or used phrases of the creator and generates anchors accordingly.

100331 Each generated anchor is stored in the anchor list 240. The anchor list 240 may be a readable data file or database table that stores an associated stream, an identifier of the anchor (e.g. anchor 1, anchor 2, etc. ), the timestamp, and the validity duration associated with each anchor.

100341 The stream communication module 220 receives the live stream from the creator client device 108 and is responsible for processing, storing and/or buffering, and transmitting the stream to one or more viewer client devices 1 10. One example for processing the stream includes transcoding the live stream receiv ed from the creator client device 108. For example, the video and audio may have been prev iously encoded by the creator client dev ice 108. The video may be in a H .264 format and the audio in an advanced audio coding (AAC) format. The stream communication module 220 may transcode the v ideo to a different format, video resolution, and/or frame rate and transcode the audio to a different format or different bit rate. The transcoded video and audio are transmitted by the stream communication module 220 to the viewer client device 1 10 according to standard protocols (e.g. real-time transport protocol (RTP), real-time messaging protocol (RTMP), user datagram protocol (UDP), transmi ssion control protocol (TCP)).

100351 The stream communication module 220 handles communications with the various viewer client devices 1 1 0. For example, the stream communication module 220 receives requests from various viewer client devices 1 1 0 to access the liv e stream and additionally provides the live stream beginning at a timestamp specified by a generated anchor. One type of request is a join request that originates from a viewer client dev ice 1 1 0 that is newly accessing the l ive stream . Another type of request is a rejoin request from a viewer client device 1 1 0 that was previously accessing the live stream, temporarily exited, and is now attempting to rejoin the stream.

100361 In a use case where a join request is received, responsive to receiving the join request from a v iewer client dev ice I 1 0, the stream communication module 220 provides the timestamp associated with the join request to the anchor analyzer module 230. The anchor analyzer module 230 selects an anchor from the anchor list 240 depending on the provided timestamp associated with the join request. Detai ls regarding the analysis and selection of an anchor are described further below.

[0037] The stream communication module 220 receives, from the anchor analyzer module 230, an identified anchor from the anchor list. The identified anchor specifies a timestamp of the live stream from when the viewer client device 1 1 0 is to begin accessing the l ive stream . Therefore, the stream communication module 220 provides the live stream to the client device 1 1 0 beginning at the timestamp specified in the selected anchor.

10038] A use case where a rejoin request is received includes where the viewer client device 1 1 0 accesses the live stream, is diverted from the l ive stream to play a content item, and then attempts to rejoin the live stream upon finishing the content item. As an example, a content item is an advertisement that is intended to temporarily replace the live stream di splayed on a v iewer client device 1 10. The advertisement can be a True View advertisement which allows a user to skip the advertisement after a threshold period of time (e.g. 5 seconds). Therefore, a user may finish with a content item by providing a user input (e.g. a click) to skip it after the threshold amount of time. When the content item finishes playing, the viewer client device 1 10 sends a rej oin request to the stream communication module 220. Thus, the anchors of the live stream are advantageous as they enable the viewer client device 1 10 to rejoin the live stream at an opportune timestamp after having watched a content item.

100391 To enable the viewer client device 1 10 to appropriately depart the live stream and play the content item, the stream communication module 220 prov ides further instructions to the viewer client device 1 10 in addition to the content item. As one example, the instructions including encoding/decoding information of the content item such that the viewer client device 110 can adequately playback the video and audio data of the content item. As another example, the stream communication module 220 further delivers a departure time interval . The departure time interval represents a length of time that the viewer client device 1 10 can access the live stream before being diverted away from the live stream to the content item. Upon expiration of the departure time interval, the viewer client device 1 10 temporarily exits the live stream to display the content item. When the viewer client device 1 10 exits the live stream, it records a timestamp of the live stream that corresponds to when it exited (e.g. a departure timestamp ).

100401 While the content item is temporari ly played by the viewer client device 1 10 (i.e., coinciding with or after the departure timestamp ), the anchor generation module 2 10 may generate additional anchors for the live stream . When the stream communication module 220 receives a rejoin request after the playing of the content item is terminated, the stream communication module 220 also receives the departure timestamp from the viewer client device 1 10. The stream communication module 220 passes the received departure timestamp to the anchor analyzer module 230 such that an appropriate anchor can be identified given the rejoin request. When the stream communication module 220 receives the identified, appropriate anchor from the anchor analyzer module 230, the stream communication module 220 provides the live stream beginning at the timestamp specified by the appropriate anchor. Thus, the stream communication module 220 allows the viewer client device 10 to rejoin the live stream by providing the live stream beginning at the identified anchor. More generally, the implementation of the generated anchors allows the user of the viewer client devi ce I 10 to miss none or a very minimal amount of the live stream or rejoin at an appropriate anchor point when being diverted to watch a content item.

100411 The stream communication module 220 is capable of providing informati on to the viewer client device 1 10 indicating that the live stream is currently in a "semi-live" state. That is, the live stream (consisting of content which is being generated in real-time (e.g. by being captured by a camera)) is displayed to the viewer with a (deliberate) delay which depends upon the identified anchor; this delay may be chosen to be greater than a delay in displaying a live stream which the system would use for buffering purposes. For example, the viewer client device 1 10 displays on the user interface 1 80, to the viewing user, an indication of the semi -liv e state on a graphical user interface (GU I ). The indication may be a colored button or indicator. Additionally, the viewer client device 1 10 may also present a selectable option on the GUI to the user. When the GUI receives a user input, the viewer client device 1 10 sends a request to the stream communication module 220 to access the live segment of the live stream . Thus, thi s provides the user of the v iewer client device I 10 the control in regards to watching the live stream in a live or semi -liv e state. In response to the request, the stream communication module 220 provides the liv e segment of the liv e stream to the viewer client device 1 10. The viewer client dev ice 1 10 can change the indication on the GUI to display a different indicator (e.g. a different color or a different button) such that the user can readily understand that the live stream is now in a live state.

[0042] The anchor analyzer module 230 selects an appropriate anchor from the anchor list 240 such that the viewer client d evice 1 10 can join or rejoin the live stream at an opportune timestamp specified by the anchor. The anchor analyzer module 230 selects an anchor as the appropriate anchor based on the timestamp specified by the anchor, the validity duration specified by the anchor, and the timestamp associated with the join or rejoin request sent by the client device 1 10. The anchor analyzer module 230 may default to a scenario where no anchor is selected. In this case, the anchor analyzer module 230 instructs the stream communication module 220 to provide the l ive stream to a viewer client device I 1 0 at its current live moment as opposed to beginning at an anchor.

100431 The anchor analyzer module 230 identifies an appropriate anchor from an anchor list 240 through a process that is dependent on the type of request (e.g. a join or rejoin request) that was sent by the viewer client d evice 1 10. For example, if the viewer client d evice 1 10 is newly joining the live stream (e.g. join request), the anchor anal y zer module 230 retrieves an anchor list 240 that includes all generated anchors associated with the live stream. Alternatively, if the viewer client device is rejoining the live stream (e.g. rejoin request), the anchor analyzer module 230 retriev es an anchor list that only includes anchors that were generated while the content item was playing on the vi ewer client device 1 10 (or which were generated during a short, predetermined time before the content item began playing on the viewer client dev ice).

[0044] Of the anchors in the retrieved anchor list 240, t he anchor analyzer nidJj 230 determines which anchors remain valid based on the validity duration associated w ith each anchor. To do this, the anchor analyzer module 230 calculates the difference between the time stamp specified by the anchor and a timestamp associated with when the join or rejoin request was sent (the "current time ^" ). The difference is com pared to the v alidity duration associated with the i dentified anchor. If the difference falls below the validitv duration, i ndicating that the anchor i s val id, then the anchor analyzer module 230 tags the anchor as valid. Alternatively, if the difference between the current time and the timestamp specified by the identified anchor is above the validity duration, then the anchor is tagged as invalid. The invalid anchors are disregarded from further consideration whereas the v alid anchors are further analyzed. In the scenario that all the anchors i n the anchor list 240 are inval id, the anchor analyzer module 230 proceeds with the default case and instructs the stream communication module 220 to provide the live stream in the l ive state.

[0045] Having identified the valid anchors, the anchor analyzer mod le 230 i dentifies an anchor depending on whether the viewer client device 1 10 has sen t a join req est or a rejoin request to the stream communication module 220. If the viewer client device 110 is newly joining the l ive stream, the anchor analyzer module 230 id entifies and selects the most recent anchor in the anchor list 240. The most recent anchor specifies a timestamp in the live stream that is more recent than tiniest amps specified by all other anchors in the anchor list 240.

[0046] If the viewer client device 1 10 is rejoining the live stream after having been temporarily diverted away (e.g. diverted to watch a content item), the anchor analyzer module 230 id entifies when the viewer client device 1 10 exited the live stream (e.g. departure time). The d eparture time can be previously sent by the viewer client d evice 1 10 along with the rejoin request. The anchor analyzer module 230 selects the anchor with a timestamp that is nearest to the identified departure time. The timestamp of an anchor nearest to the identified departure time may occur prior to the identified departure time, meaning that upon rejoining the live stream at that anchor, the viewer client device 1 1 0 would replay a portion of the l ive stream. I n this scenario, the viewer cl ient device 1 1 0 avoids skipping over any portion of the l ive stream. Alternatively, the ti mestamp of an anchor nearest to the identified departure ti me may occur subsequent to the identified departure time. Therefore, the viewer cl i ent device 110 can rejoin the live stream at the opportune timestamp of the anchor while having missed very little of the live stream.

100471 Once the anchor analyzer module 230 has iden tified the appropriate anchor, the anchor anal y zer module 230 instructs the stream communication module 220 to send the li ve stream to a viewer client device I 10 beginning at the selected anchor. The stream communication module 220 may do this by transmitting the live stream together with the identified anchor.

[0048] After a live stream is completed, the VOD generator module 250 obtains the stream and generates a video on demand (VOD) to be stored in the content store 120. Thus, the viewer client device 1 10 can access the VOD at a subsequent time and display the live stream even though it is no longer live-streaming. In generating the VOD, the VOD generator module 250 associates the generated anchors that were originally created during the live stream with the VOD. For example, the VOD generator module 250 encodes the dropped anchors along with the stream. Additionally, the VOD generator module 250 creates an associated data file (or database table) that includes the timestamp specified by each anchor in the stream as well as a tag (e.g. descriptive keyword) that describes each anchor. For example, an anchor may indicate that the creator switched from talking about a topic of dogs to a topic of cats at a timestamp in the

stream . Therefore, the data file may tag the anchor at the timestamp with the particular subject matter regarding cats. The data file may i nclude more than one tag for each anchor.

100491 The search module 260 enables users of viewer client devices 1 10 to effectively search through VOD' s for an anchor that is of interest. Therefore, the search module 260 provides improv ed search granularity s o t h a t a viewer client device 1 10 can access specific anchors within a VOD instead of having to access the VOD from the beginning. For example, the search module 260 receives a search query and parses the query for keywords. The search module 260 searches the content store 120 for an anchor in a VOD that matches the query or a keyword in the query . For example, if a query from a cl ient dev ice searches for "puppies," the search module 260 searches the metadata file associated with each VOD to identify anchors that are tagged with the subject matter of "puppy" or "puppies. " The match may be a text string match between the search query and the keyword associated with the anchor. The search module 260 returns the search result of anchors that are tagged with the matching subject matter to the v iewer client dev ice 1 1 0 that sent the query . I f a user of the v iewer client dev ice 1 1 0 selects an anchor, indicating that he she is interested in watching a VOD starting at that anchor, the search module 260 retrieves, from the content store 1 20, the appropriate v ideo segment in the VOD beginning at that anchor and prov ides it to the v iewer client dev ice 1 10. This enables a user to view relevant clips of a VOD file as opposed to hav ing to v iew the entire VOD that may not be entirely relev ant to the prov ided query.

SOFTWARE MODULE

100501 FIG. 3 A depi cts the software module 300A on the creator cl ient device 108 and its associated modules, in accordance with one embodiment. The software module 300 A incl udes a stream generator module .305 and a stream processing module 3 1 0.

[0051 ] The stream generator module 305 generates the video and audio of the stream obtained from a hardware ( e.g., a camera ) or software ( e.g., a video game ) source communicatively coupled to, a part of, or operating on the viewer cl ient device 1 10. The generated stream is stored in the stream store .3 1 5. The stream generator module 305 sets the characteristics of the live stream including the v ideo resolution, v ideo frame rate, and audio bit rate. Alternatively, the characteristics of the live stream can be set by the creator to provide the opti mal live-stream viewing experience for his/her viewers. 10052] The stream generator module 305 passes along portions of the live-stream as they are captured to the stream processing module 310. Therefore, the stream processing module 310 can process and transmit the stream while the stream generator module 305 conti nues to record new portions of the live stream . The stream processing module 310 encodes the video and audio according to characteristics (e.g. resolution, frame rate, bit rate) of the video and audio. As an example, the video is encoded using a H.264 encoder while the audio i s separately encoded using an A AC encoder. Once encoded, the stream processing module 310 proceeds to transmit the encoded video and audio to the stream hosting server 1 50.

100531 The stream processing module 310 uses standard protocols (e.g. RTP, RTMP, UDP, TCP) to transmit the encoded video and audio of the live-stream to the stream hosting server 150. For example, RTP over UDP is preferred for a live stream to ensure that the viewers can watch the stream with limited delay.

100541 FIG. 3B depicts the software module 300B on the view er client device 1 1 0 and its associated modules, in accordance with one embodiment. The software module 3 00 B enables the viewer client d evice 1 10 to access the live stream. In various embodiments, the software module 300B includes a user in terface manager 350, a request module 355, and a play back module 365. In some embodiments, the software module 300A/300B of either the creator client device 108 or the viewer client device 1 10 has different modules and/or logical structures than the ones described herein, and the functions can be di stributed among the modules and/or logical structures in a different manner than described here.

[0055] The user interface manager 350 receives from and prov ides i n formation through the user interface 1 80 to the user of the client dev ice 1 10. For example, the cli ent dev ice may be a mobile client dev ice (e.g. cell phone) with a touch di spl ay interface. Therefore, the user interface manager 350 receiv es touch inputs and also displays the liv e stream for view ing through the user interface 180. The user interface manager 350 may prov ide information during the liv e stream . As prev iously men tioned, the user interface manager 350 prov ides a GUI on the user interface 1 80 of the viewer cl ient dev ice 1 10. The GUI may prov ide an indication (e.g. a yellow button) that current stream is in a semi-liv e state as opposed to a liv e state (e.g. a green button). As another example, the user interface manager 350 may provide notifications whenev er a new anchor has been generated in the live stream.

100561 The user interface manager 350 presents VOD with anchors to the viewer client device 1 10. In displaying a VOD, the user interface manager 350 may present, through the user interface 180, additional selectable options. For example, selectable options may be forward or back arrows displayed on the user interface 1 80. When a user input is received on the fonvard arrow, the user interface manager 350 identifies the subsequent anchor (e.g. anchor specifying the next tiniest amp in the VOD) and displays the VOD at that anchor. Similarly, if a user input is received on a back arrow, the user interface manager 350 identifies the previous anchor (e.g. anchor specifying the previous timestamp in the VOD) and displays the VOD at the previous anchor. The operation of identifying the subsequent or previous anchor may be performed by the user interface manager querying the stream hosting server 1 50.

[0057] The user interface manager 350 may maintain a counter that tracks the number of times that users start or skip from an anchor in a VOD. The counter represents the popularity of the anchor in the VOD. The updated counter information may be provided to the stream hosting server 1 50 to further improve search functionality. For example, viewer client devices 1 10 may transmit a search for the term "puppies" and then subsequently receive a particular anchor in a VOD that is associated with "puppies. " If the majority of viewer client devices 1 10 that had provided the "puppies" search query end up displaying the VOD starting at the anchor (e.g. not skipping the anchor), that information may be provided back to the stream hosting server 1 50. Alternatively, if a majority of viewer client devices 1 10 that had provided the "puppies" search query briefly di splay the VOD starting at the anchor, but quickly stop watching, the keyword of "puppies" may be a poor topic association with the anchor. The stream hosting server 1 50 can use the information to adjust the keyword labels that are associated with the anchor and further update ranking algorithms for running search queries that identify anchors in the VOD content.

[0058] The ser interface manager 350 recognizes when the viewer client device 1 10 is displaying the VOD and when the viewer client device 1 10 stops displaying the VOD. At a subsequent time, if the viewer client device 1 1 0 is instructed to begin displaying the VOD again, the viewer client device 1 10 can begin displaying at a relevant point of the VOD specified by the anchor. In an example scenario, the user interface manager 350 may present the VOD on a webpage and the user decides to scroll up or down on the webpage such that the VOD is no longer in view. Thus, the user interface manager 350 records a timestamp that indicates when the viewer client device 1 10 stopped displaying the VOD. The VOD will stop playing if the VOD is no longer in view. At a subsequent time, the user may scroll back to the VOD. Therefore, the user interface manager 350 receives an indication that the viewer client device 110 is continuing to display the VOD. The user interface manager 350 may begin playing the VOD at the nearest anchor which may be either before or after the timestamp that indicated when the viewer client device 110 stopped displaying the VOD.

[0059] The user interface manager 350 receives an input indicating that the user would like to access a live stream . The user interface manager 350 provides this input to the request module 355. The request module 355 is configured to provide a variety of di fferent requests from the viewer client device 1 10 to the stream hosting server 150. .As a first example, in response to receiving the user input from the user interface manager 350, the request module 355 sends a join or rejoin request (depending on whether the user is newly joining or rejoining) to the stream hosting server 150. In a second example, the request module 355 can send user queries to the stream hosting server 150 to search through anchors of VODs that may be relevant to the user query. Each of these exam ples are described further below.

[0060] Referring to the first example, when a viewer client device 110 desires to access the live stream, the request module 355 determines whether to send a join request or a rejoin request. For exam pie, if the viewer cli ent device 10 is newly accessing the live stream, then the request module 355 chooses to send ajoin request. If the viewer cl ient device 110 had previously accessed the live stream and was temporarily diverted away (e.g. 1 -5 minutes), the request module 355 chooses to send a rejoin request. In some cases, the request module 355 chooses to send ajoin request as opposed to a rejoin request even if the viewer client has previously accessed the stream. For exam ple, the request module 355 determines that the viewer cl ient device had previously accessed the live stream, but exited the stream over a threshold amount of time ago (e.g. 30 minutes, 1 hour). Therefore, the request module 355 treats this viewer client device 1 10 as a new join request.

[0061] The request module 355 may send a rejoin request to the stream hosting server 150 along wi th a timestamp retrieved from the timestamp store 370. The included timestamp is helpful for the stream hosting server 150 to determine when the viewer client device 110 previously left the live stream. For example, a viewer client device 110 may be previously accessing the live stream and was subsequently diverted to watch a content item at a departure timestamp of the live stream. Therefore, when the viewer client device 1 10 attempts to rejoin the stream, the request module 355 sends the departure time along with the rejoin request to the stream hosting server 150. The stream hosting server 150 determines the anchors that were generated while the client device 1 10 ^« \ as playing the content item based on the departure time.

100621 Referring now to a second example, the request module 355 also handles submitted user queries to search through VODs for anchors that are associated with a particular topic of interest. The request module 355 transmits the search request to the search module 260 of the stream hosting server 1 50. For example, the request module 355 may send a search request for "puppies. " In return, the viewer client d evice 1 10 receives a list of anchors that are associated with the subject matter of "puppies." The list of anchors may be presented in an ordered ranked according to a search algori thm utilized by the search module 260. Therefore, a user can select and play a VOD from an anchor that pertains to the particular topic of interest included in the search query.

100631 In some embodiments, the software module 300B of the viewer client device 1 10 further includes the anchor analyzer module 2 0 and is responsible for identifying the appropriate anchor to begin accessing the live stream . Therefore, instead of the anchor analyzer module 230 being a module of the stream hosting server 1 50, this embodiment includes the anchor analyzer module 230 in the viewer client device 1 10.

10064] The anchor analyzer module 230 on the viewer client device 1 10 receives the anchor list 240 from the stream hosting serv er 150. As one example, the anchor analyzer module 230 automatically identifies the appropriate anchor based on the timestamp of each anchor in the anchor list 240 and the timestamp associated with the join or rejoin request. As described previously, if the request is a join request, the anchor analyzer module 230 selects the anchor that specifies the most recent timestamp. If the request is a rejoin request, the anchor analyzer module 230 selects the anchor that speci ies a timestamp that is nearest to the departure time.

[0065] As a second example, the anchor anal yzer module 230 may ask a user of the vi ewer client device 1 10 for a user input in id entifying the appropriate anchor. The anchor analyzer module 230 presents the anchors in the anchor list 240 on the user in terface 180 of the viewer client device 1 10 and receives a user input specify i ng the appropriate anchor to join or rejoin the stream at. In this example, the anchor analyzer module 230 provides the user with the final control over where to begin watching in the live stream.

10066] The playback module 365 receives, from the stream hosting server 150, the liv e stream to be played on the viewer client device 1 10 based on the identified anchor. The l iv e stream may contain addi tional instructions in a metadata fi le as to how the playback module 365 is to play the live stream (e.g. decoder, video resolution, and audio bitrate). For exam ple, the playback module 365 may receive the live stream and associated audio files and may decode them separately before playing them on the user i nterface manager 350 of the viewer client device 1 10.

[0067] The playback module 365 a! so receives content items from the stream hosting server 1 0 to be played on the client device 1 10. The content items may be stored in the client content store 375. Additionally, the content item may have associated instructions (e.g. stored in a metadata fil e associa ted wi th the con tent item) that instruct the client device 1 1 0 to play the content item at a departure timestamp of the live stream. Thus, the client device 1 10 automatically diverts to playing the content item at the departure timestamp. This departure timestamp may be stored in the timestamp store 70 and used for further analysis by the anchor analyzer module 360 when the client device 1 10 is to rejoin the live stream.

PROVIDING A LIVE STREAM

[0068] FIG. 4 depicts an example flow chart of the stream hosting serv er 150 prov iding a live stream to be played on a client dev ice 1 10 based on a generated anchor, in accordance with an embodiment. The stream hosting serv er 1 50 receiv es 405 a live stream from a creator client dev ice 1 08. The stream hosting server 1 50 receives 410 a request to generate an anchor from the creator client device 1 08 at a timestamp of the live stream.

[ 00691 The stream hosting server 150 generates 4 1 5 anchors while the liv e stream is ongoing. As described abov e, each anchor is generated with a timestamp and a validity duration . The stream hosting server 1 50 receives 420 a request (e.g. join request or rejoin request) from a client device and determines 425 anchors that are valid based on the validity duration associated with each anchor. From the li st of anchors that are v alid, the stream hosting server 1 50 identifies 430 an anchor. For example, if the received request was a join request, the stream hosting serv er 1 50 identifies the anchor that specifies the most recent timestamp. If the received request was a rejoin request, the stream hosting server 1 50 identifies the anchor that speci fies a timestamp closest to the departure timestamp. Once the stream hosting server 150 has identified the anchor, the stream hosting server 1 50 provides 435 the live stream to the viewer client d ev ice 1 10 for playback beginni ng at the timestamp specified by the identified anchor.

REQUESTING AND PLAYBACK OF A LIVE STREAM

100701 FIG. 5 depicts an example flow chart of playing back, by a viewer client device 1 10, a received li ve stream based on a generated anchor, in accordance wi th an embodiment. A viewer cl i ent device 1 10 receiv es 505 user input specifying a desire to access a live stream. For example, a user may provide a touch input through the user interface 1 80. The viewer cli ent d evice 1 10 determines 510 the type of request to send on behalf of the u ser. For example, the viewer client device 1 10 determines whether the view er cl ient device 1 10 i s newly accessing the live stream or if it is returning to the live stream after hav ing been div erted. Thus, the request may be a join request or a rejoin request. The viewer client dev ice sends 515 the request to access a liv e stream to the stream hosting server 1 50. If the v iewer client d ev ice 1 1 0 is sending a rejoin request, the request further incl udes a departure timestamp associated with the viewer cl ient dev ice 1 1 0 previously departed the l iv e stream.

100711 The viewer cli ent dev ice 1 1 0 receives 520 the l ive stream along w ith an identified anchor that specifies a timestamp of the l iv e stream . If the viewer client d evice 1 1 0 is newly joining the l iv e stream, the identified anchor is the most recently genera ted anchor associated with the 1 i ve stream, if the v iewer client device 1 10 is rejoining the l ive stream, the identified anchor specifies a ti mestamp that is nearest to the departure time corresponding to when the viewer cl ient dev ice 1 10 departed the liv e stream. The v iewer client d ev ice 1 10 plays back 525 the liv e stream for the user beginning at the timestamp speci fied by the identified anchor.

GENERAL

[0072] The foregoing description of the embodiments of the disclosure has been presented for the purpose of ill ustration; it is not intended to be exhaustive or to l imit the disclosure to the precise forms disclosed. Persons skilled in the relev ant art can appreciate that many modifications and variations are possi ble in light of the above disclosure.

[0073] Some portions of this description describe the embodiments of the disclosure in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logical ly, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also prov en conv enient at times, to refer to these arrangements of operations as modules, w ithout loss of generality. The described operations and their associated modules may be embodied in software. firmware, hardware, or any combinations thereof. In one embodiment, a software module is implemented with a computer program product. The computer program product may comprise a com puter-readabl e medium containing computer program code, which can be executed by a computer processor for performing any or all of the steps, operations, or processes described. Alternatively, the computer program product may be a signal encoding the computer program code, and transmitted over a signal path (e.g. a radio path, an electric signal path, or an optical path) without being recorded onto a non-transitory recording medium.

[0074] Embodiments of the di sclosure may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0075] Embodiments of the disclosure may al so relate to a product that i s produced by a computing process described herein. Such a product may comprise information resulting from a computing process, where the information i s stored on a non-transitory, tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein.

100761 Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the disclosure be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the disclosure is intended to be i l lustrative, but not limiting, of the scope of the disclosure, which i s set forth in the following claims.