Patent Description:
Document <CIT> describes an information processing apparatus including: an estimation section configured to, when it is determined that a user is able to receive vocal information presentation, estimate a duration for which it is possible to receive the information presentation; and an adjustment section configured to adjust an amount of information to be presented to the user in accordance with the estimated duration.

Document <CIT> describes techniques for building customized media programs for a specified duration. An example media-playback device for generating customized media programs for a route to a specified duration includes a user preferences engine to determine a user's listening preferences, a duration engine to determine a duration of the route, and a duration-based media program engine for building a playlist of news and entertainment media content based on the duration of the route and the preferences of the user.

Document <CIT> describes recommending one or more content items for consumption during travel based on one or more travel times associated with one or more travel routes is described. A content item recommendation platform determines one or more travel routes associated with at least one device, at least one user of the at least one device, or a combination thereof. The content item recommendation platform further causes, at least in part, a recommendation of one or more content items based, at least in part, on one or more travel times associated with the one or more travel routes.

Digital devices are designed to facilitate delivery of content to a user. Multitasking with digital devices is often encouraged with the utilization of advanced hardware with increased memory and fast processors in devices. These digital devices-e.g., computers, telephones, smartphones, tablets, smartwatches, microphones (e.g., with a virtual assistant), activity trackers, e-readers, voice-controlled devices, servers, televisions, digital content systems, video game consoles, and other internet-enabled appliances-are part of not only the digital world, as the devices can help simplify, expedite, or supplement real-world tasks, e.g., upon a user's voice, touch, or other input.

Tasks and activities that are conducive to multitasking with a device may allow content consumption throughout the duration of an activity. Content like video, animation, music, audiobooks, playlists, podcasts, images, slideshows, games, text, and other media may be consumed by users at any time, as well as nearly in any place and during almost any activity (for better or worse). It is not uncommon to use a device to watch videos, read an article, or look at photographs while participating in another separate activity.

A user may stream a portion of broadcast news during her breakfast. Another user may listen to part of a podcast during her morning commute. A user might watch last night's episode of his favorite fantasy TV show while riding an exercise bicycle. A family may sit down to dinner and enjoy watching a trivia-based game show on DVR. Content contemporaneously delivered and consumed, via a device, during an activity can entertain, educate, and enhance an activity, as well as save time.

A duration of an activity does not always match a runtime of content. A user's aerobic exercise is not complete whenever an episode happens to finish. The cut-off portion of a news program is not valueless because a breakfaster did not eat her daily orange on a particular day. Unfortunately, an evening bus ride home does not finish just because a true-crime podcast identifies the culprit.

Additionally, activities may not always take an identical, fixed length of time and may, in fact, have a variable duration. For example, fitting daily exercise into a busy schedule may cause the activity duration to fluctuate from day to day. Lunch may run longer one day versus another. A commuter train trip duration may vary based on weather.

A user may watch segments of sports and/or business news during her <NUM>-minute breakfast. Another user may listen to two or three podcasts during her <NUM>-minute morning commute. A user might catch up on his favorite fantasy TV show and then watch funny pet videos while exercising on a treadmill for <NUM> minutes. A family may sit down to dinner and enjoy listening to <NUM> songs from their favorite four artists each night. Content contemporaneously delivered and consumed, via a device, during an activity can entertain and educate users, and enhance an activity, as well as save time, however, having to manually cue up content or create a media playlist to consume during a variable-duration activity may diminish any benefits. Identifying appropriate new, interesting, and/or unseen content to fill the time of the variable-duration activity no longer must be based on guesswork and does not have to be identified manually. An embodiment of the present invention can learn to recognize a variable-duration activity and provide content for consumption for the duration of that activity.

One alternative approach to providing content during an activity may constantly deliver content without ever knowing if or when a variable-duration activity ends. For instance, portions of radio or television broadcasts might be consumed during an activity where a user is apathetic about content substance or duration. A user may tune in to a portion of a <NUM>/<NUM> news network during breakfast or watch a syndicated rerun while working out on a rowing machine. Consuming this content may be more of a distraction from a variable-duration activity or merely observed out of habit. When a variable-duration activity ends the user might turn off the device, but such content may continue. While certain examples of such content may be valued highly by some, these may be considered unnecessary "background noise" to many others. Such content may also be delivered regardless of user preference and/or activity duration. Even narrow distinctions in content may make a difference to a user. For instance, a user might choose to listen to live sports talk radio discussing football during a drive to work when she might prefer to hear a podcast about her favorite soccer team if it were as convenient as tuning the radio. There are more potential benefits, such as higher entertainment value, more learning opportunities, and more efficient use of time when the content is highly valued or tailored to a user and activity duration. Content providers can benefit too from delivering content to receptive audiences more efficiently.

One alternative approach may require user input of a duration of a variable-duration activity and match a video runtime to that estimated duration. Such an approach requires the precise input of a time duration by a user and is oblivious to the nature of the activity and the history of activity durations.

One approach may identify a variable runtime video with a duration similar to a variable-duration activity and cut or extend the variable runtime video to fit within the duration. Such an approach may compel the user to watch an undesired or inappropriate video merely because the runtime matches the duration. Such an approach may provide content that annoys a user with additional commercials or may deprive a user of many scenes when a video is cut too much.

There exists a need for learning a variable-duration activity and its duration in order to identify one or more content items with a total runtime similar to the duration so content may be provided for consumption during the next occurrence of the activity. Moreover, there exists a need to continuously or regularly update a duration for a variable-duration activity so that one or more content items with a total runtime similar to an updated duration may be identified for subsequent performances of the variable-duration activity.

According to one aspect, there is provided a method according to claim <NUM> and/or a system according to claim <NUM>. Accordingly, a system is taught or able to learn a duration of a variable-duration activity by observing and recording the start and stop of a variable-duration activity and calculating an average duration. The average duration is then used to estimate durations for subsequent performances of the variable-duration activity.

The start and stop of a variable-duration activity is signaled by a start cue and a stop cue, respectively. A cue may be identified as incorporated in or associated with an input. A cue may be explicit or implicit. For instance, an explicit start cue may be found in sound input with a user telling the system that the variable-duration activity is beginning. An explicit start cue may also be a found in touch input or visual/gesture input similarly signaling the start. An implicit start cue may be a found in sound input such as the sound of a cereal box pouring breakfast into a bowl. An implicit start cue for starting an exercise bike activity by the sound of the bicycle pedals or an initialization beep, or via visual input identifying a user is in position and/or started. Using swimming as an example activity, an implicit start cue could be detection of water. While an explicit stop cue may be a voice command to stop an activity timer, an implicit stop cue may be the absence of the sound from a treadmill or a camera or sensor measuring movement away from the stationary bicycle seat.

Once a duration of a variable-duration activity is learned, and the duration of the next performance of the activity can be estimated, content items can be identified and provided for consumption during the activity by, e.g., a content curation engine. The content items, such as video, animation, music, audiobooks, playlists, podcasts, images, slideshows, games, text, and other media, can be played back-to-back for multitask viewing while performing the variable-duration activity. Content may come from various sources including broadcast television and radio, cable, satellite, IPTV, over-the-top streaming services, video on demand, DVR, video sharing sites, social media, podcasts, blogs, live feeds, and other multimedia streams. Content typically has associated metadata or other information to identify whether a potential content consumer may be interested in the content. A content curation engine may be used to search for one or more programs that align with a user's interests. A user generally has preferences as to types, sources, substantive content, actors, producers, and other content descriptions that can be used to identify potential content items to provide during an activity if the content items fit in the expected activity duration. For instance, a user may be shown videos of a sports news recap and a segment of the weather report while exercising on a stationary bicycle, and the total runtime of the videos matches the duration of the exercising activity. Watching two videos, in this case totaling <NUM> minutes, may be beneficial to the user over watching the first part of one <NUM>-minute episode of a cable drama television program (and later finding at least seven minutes to finish the program) especially if the user indicates a preference for sports and weather updates in a profile or other settings. A user may have preferences to consume certain content, e.g., particular television programs or segments of videos, during specific variable duration activities.

Shorter-duration content, such as video clips, may be becoming more readily available, as anyone with a phone can become a content creator. Audiences' attention spans may be getting shorter. It may be more beneficial to a user to play a dozen video clips-e.g., updates on news, sports, fashion, health, comedy, cooking, etc.-than to watch only a portion of a longer television program. It is not reasonable or efficient for a user to manually create a playlist with desired content prior to each performance of a variable-duration activity. Once a duration of a variable-duration activity is learned or can be accurately estimated, one or more content items with a total runtime similar to the learned duration can be provided.

Embodiments of the invention may still shorten or lengthen content but doing so is not always necessary. Variable runtime content items may be used in conjunction with other content items in order to better match a learned duration of a variable-duration activity so that portions are not, e.g., unnecessarily cut, or lengthened with additional advertisements. Additional content can be provided to reach an estimated average duration for a variable-duration activity. Rather than provide one long television program for incomplete consumption during an activity, providing a shorter a shorter television program followed by other videos or segments may be completed within a learned duration for a variable-duration activity.

There may be situations where a user chooses a particular program or content for consumption during a specific time period or activity. There may be situations where a user consumes undesired content merely out of convenience. By offering content personalized to a user, and tailored to a variable-duration activity and its expected duration, entertainment, education, and efficiency of time may increase.

Methods and systems disclosed herein may use an activity engine to learn a duration of an activity by receiving input with a start cue indicating a start of an activity and receiving input with a stop cue indicating an end of the activity. The activity engine determines an average duration for the activity based on the time difference between the start cue and the stop cue, so that when the activity engine receives a third input and identifies the start cue, a content curation engine may be used to identify one or more content items with a total runtime substantially similar to the average duration for the activity and provide the content for consumption.

<FIG> depicts an illustrative scenario and user interface for learning a duration of a variable-duration activity and providing content during a variable-duration activity, in accordance with some embodiments of the disclosure.

An exemplary embodiment is depicted in <FIG> as scenario <NUM> with smartphone <NUM>. Any other suitable device such as a personal computer, laptop, tablet, media center, video console, or any device as depicted in <FIG> and <FIG>, may be used instead of smartphone <NUM>, as long as the device has capabilities to receive input and provide content for consumption.

Exemplary scenario <NUM> of <FIG> depicts an embodiment that learns a duration of an activity <NUM> in order to subsequently provide content for the duration of activity <NUM>, such as in scenario <NUM> of <FIG>. Scenario <NUM> depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In one or more embodiments, input <NUM> may be a voice command received by smartphone <NUM> from user <NUM>. In an embodiment, input <NUM> may be a button press or a gesture by user <NUM> received by smartphone <NUM>. In one or more embodiments, input <NUM> may include information identifying user <NUM>. Input <NUM> comprises begin cue <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising a begin cue <NUM>, a begin timer <NUM> initiates. An embodiment may record a timestamp for the begin cue <NUM> and begin timer <NUM> may be a calculated real-time difference from the timestamp for begin cue <NUM> calculated. In an embodiment, begin cue <NUM> may identify activity <NUM>, e.g., "Begin 'Exercise Bike' activity. " and begin cue <NUM> and activity <NUM> may be recorded.

Scenario <NUM> also features an exemplary display screen of smartphone <NUM> with a content delivery application depicted as user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, that may be displayed during activity <NUM>. In scenario <NUM>, where the system may be training or learning a duration, video <NUM> may be chosen in many different ways. In an embodiment, video <NUM> may be, e.g., a television program from VOD, DVR, or OTT. The video <NUM> is selected based on matching a runtime to an average activity duration retrieved from a database. An embodiment may use, e.g., an anonymized database of times from other users to estimate or predict an average activity duration or a default activity duration. The average activity duration is updated via learning or training as depicted in scenario <NUM>. An embodiment may estimate an initial or default activity duration based on the runtime of video <NUM> selected by, e.g., a user or a content provider.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in video <NUM>. The position of marker <NUM> on video progress bar <NUM> also indicates a relative progress time and a remaining time of a video. An embodiment may use microphone icon <NUM> to indicate a potential for input, such as a voice command, that could, e.g., pause, resume, or end an activity. Activity identifier <NUM> may provide feedback that the system has identified activity <NUM> correctly and/or an estimated duration for activity <NUM>. An embodiment may hide or move one or more features of user interface <NUM>, such as counter <NUM>, video progress bar <NUM>, or others so as not to distract from video <NUM>.

Scenario <NUM> further depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may likewise be a voice command received by smartphone <NUM> from user <NUM>. In an embodiment, input <NUM> may be a button press or a gesture by user <NUM> received by smartphone <NUM>. Input <NUM> comprises stop cue <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising a stop cue <NUM>, stop timer <NUM> is recorded as a duration. An average activity duration is updated. An embodiment may record a timestamp for stop cue <NUM>, and stop timer <NUM> may be a calculated real-time duration from a timestamp for begin cue <NUM>. In an embodiment, stop cue <NUM> may identify activity <NUM>, e.g., "Stop 'Exercise Bike' activity. " and stop cue <NUM> and activity <NUM> may be recorded.

In scenario <NUM>, video <NUM> has a runtime of <NUM>:<NUM>, as depicted by progress time <NUM>, but stop timer <NUM> indicates a duration of <NUM>:<NUM>. Scenario <NUM> indicates an embodiment that learns, updates, or is trained for a new activity duration. An average activity duration is updated by calculating a new average activity duration for activity <NUM>, e.g., using analysis such as an arithmetic mean, mode, median, weighted average, or other statistical calculations or algorithms.

Exemplary scenario <NUM> of <FIG> depicts an embodiment that has learned a duration of an activity <NUM>, e.g., in scenario <NUM>, and provides content for the duration of activity <NUM>. Scenario <NUM> depicts an embodiment in which two videos are provided after learning or updating an average activity duration, such as in scenario <NUM>.

Scenario <NUM> depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may be a voice command received by smartphone <NUM> from user <NUM>. In an embodiment, input <NUM> may be the same or similar to input <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising or associated with a begin cue <NUM>, a begin timer <NUM> initiates. An embodiment may record a timestamp for the begin cue <NUM> and begin timer <NUM> may be a calculated real-time difference from the timestamp for begin cue <NUM>. In an embodiment, begin cue <NUM> and activity <NUM> may be recorded.

Scenario <NUM> also features an exemplary display screen of smartphone <NUM> with a content delivery application depicted as user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, that may be displayed during activity <NUM>. In scenario <NUM>, where the system has been trained or has learned an activity duration, video <NUM> may be chosen in many different ways.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in the total runtime. The position of marker <NUM> on video progress bar <NUM> also indicates a relative progress time and a remaining time. An embodiment may use microphone icon <NUM> to indicate a potential for input such as a voice command. Activity identifier <NUM> may provide feedback that the system has identified activity <NUM> correctly and/or an average duration for activity <NUM>. In scenario <NUM>, an update of a new activity duration from scenario <NUM> is used. For instance, in scenario <NUM>, activity identifier <NUM> depicts "<NUM> minutes (average)" as a learned average activity duration for "Exercise Bicycle" as compared to activity identifier <NUM>, in scenario <NUM>, which depicts "<NUM> minutes (average)" as a prior average activity duration for "Exercise Bicycle. " An embodiment may hide or move one or more features of user interface <NUM>, such as counter <NUM>, video progress bar <NUM>, or others so as not to distract from video <NUM>.

Scenario <NUM> also features another exemplary display screen of smartphone <NUM> with a content delivery application depicted as user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, that may be displayed during activity <NUM> subsequently to a display of video <NUM> in user interface <NUM>. In scenario <NUM>, where the system has been trained or has learned an activity duration, video <NUM> may be chosen in many different ways.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in total runtime. The position of marker <NUM> on video progress bar <NUM> also indicates a relative progress time and a remaining time. An embodiment may hide or move one or more features of user interface <NUM>, such as counter <NUM>, video progress bar <NUM>, or others so as not to distract from video <NUM>. An embodiment may allow further input to receive, e.g., a stop cue similar to stop cue <NUM>. An embodiment may use microphone icon <NUM> to indicate a potential for input such as a voice command.

An embodiment may select video <NUM> and video <NUM> in many ways. A difference between scenario <NUM> and scenario <NUM> may be that scenario <NUM> provides video <NUM> and video <NUM> with a runtime of <NUM>:<NUM> while scenario <NUM> provides video <NUM> with a runtime of <NUM>:<NUM>. In an embodiment like scenario <NUM>, video <NUM> may be a television program from VOD, DVR, or OTT originally produced for broadcast in an hour-long spot, however, because stop timer <NUM> of scenario <NUM> indicates a duration of <NUM>:<NUM>, activity <NUM> finished prior to completion of video <NUM>.

In scenario <NUM>, video <NUM> and video <NUM> are selected as "Video <NUM> of <NUM>" and "Video <NUM> of <NUM>," as depicted in banner <NUM> and banner <NUM>, respectively. In an embodiment like scenario <NUM>, video <NUM> and video <NUM> are selected in part because the total runtime of both videos, as indicated by progress time <NUM> and progress time <NUM>, is similar to a learned average activity duration of "<NUM> minutes (average)" as depicted in activity identifier <NUM>. In an embodiment, video <NUM> and video <NUM> may be selected instead of a television program with a runtime similar to video <NUM> because the runtime exceeds an average activity duration for activity <NUM> by a predetermined threshold. In an embodiment, the selection of video <NUM> and video <NUM> may be further based on substantive content in each of video <NUM> and video <NUM>. For example, video <NUM> and video <NUM> may be selected from a pool of potential content items because of associated metadata matching a profile of user <NUM> as well as fitting a runtime similar to a learned average activity duration.

An exemplary embodiment is depicted in <FIG> as scenario <NUM> with smartphone <NUM>. Any other suitable device such as any device as depicted in <FIG> and <FIG> instead of smartphone <NUM>.

Exemplary scenario <NUM> of <FIG> depicts an embodiment that learns a duration of an activity <NUM> in order to subsequently provide content for the duration of activity <NUM>, such as in scenario <NUM> of <FIG>. Scenario <NUM> depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may be any form of input, e.g., a voice command or a button press or a gesture, by user <NUM> and received by smartphone <NUM>. In exemplary scenario <NUM>, input <NUM> comprises begin cue <NUM>. Upon smartphone <NUM> receiving input <NUM> and begin cue <NUM>, a begin timer <NUM> initiates. An embodiment may record a timestamp for begin cue <NUM>, and begin timer <NUM> may be a calculated real-time difference from the timestamp for begin cue <NUM>. In an embodiment, begin cue <NUM> may identify activity <NUM>, e.g., "Begin 'Breakfast' activity. " and begin cue <NUM> and activity <NUM> may be recorded in an activity duration database.

Scenario <NUM> also features an exemplary display screen of smartphone <NUM> with a content delivery application depicted as user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, that may be displayed during activity <NUM>. In scenario <NUM>, where the system is training or learning a duration, video <NUM> is selected based on matching a runtime to a similar predetermined average activity duration.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in video <NUM>. The position of marker <NUM> on video progress bar <NUM> also indicates a relative progress time and a remaining time of a video. An embodiment may use microphone icon <NUM> to indicate a potential for input such as a voice command. Activity identifier <NUM> may provide feedback that the system has identified activity <NUM> correctly and/or an estimated duration for activity <NUM>.

Scenario <NUM> further depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may likewise be a voice command received by smartphone <NUM> from user <NUM>. In exemplary scenario <NUM>, input <NUM> comprises stop cue <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising stop cue <NUM>, stop timer <NUM> is recorded as a duration. The average activity duration is then updated. An embodiment may record a timestamp for stop cue <NUM> and stop timer <NUM> may be a calculated real-time duration from a timestamp for begin cue <NUM>. In an embodiment, stop cue <NUM> may identify activity <NUM>, e.g., "Stop 'Breakfast' activity. " and stop cue <NUM> and activity <NUM> may be recorded. An embodiment may update a new activity duration by calculating a new average activity duration for activity <NUM>.

In scenario <NUM>, video <NUM> has a runtime of <NUM>:<NUM>, as depicted by progress time <NUM>, but stop timer <NUM> indicates a duration of <NUM>:<NUM>. Scenario <NUM> indicates an embodiment that learns, updates, or is trained for a new activity duration-an activity duration longer than the provided content during the training scenario. An embodiment that is training or learning, such as depicted in at least part of scenario <NUM>, may have to fill time after video <NUM> finishes and completion of activity <NUM> is not signaled by input <NUM> and end cue <NUM>. Such time could be filled with additional content, repeated content, random content, or no content.

Exemplary scenario <NUM> of <FIG> depicts an embodiment that has learned a duration of an activity <NUM>, e.g., in scenario <NUM>, and provides content for the duration of activity <NUM>. Scenario <NUM> depicts an embodiment in which nine videos are provided after learning or updating an average activity duration, such as in scenario <NUM>.

Scenario <NUM> depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may be a voice command received by smartphone <NUM> from user <NUM>. In an embodiment, input <NUM> may be the same or similar to input <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising a begin cue <NUM>, a begin timer <NUM> initiates.

Scenario <NUM> also features an exemplary user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, displayed during activity <NUM>. In scenario <NUM>, where the system has been trained or has learned an activity duration, video <NUM> may be chosen in many different ways. In scenario <NUM>, there are nine videos selected to be provided during activity <NUM>.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in the total runtime. Similarly, on user interface <NUM> appears banner <NUM>, which indicates that an activity is "in progress" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in the total runtime. On user interface <NUM> appears banner <NUM>, which indicates that an activity is "complete" and the displayed video is "<NUM> of <NUM>. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM> out of a runtime of <NUM>:<NUM>. Remaining time <NUM> indicates that <NUM>:<NUM> remains in the total runtime.

The position of markers <NUM>, <NUM>, and <NUM> on video progress bar <NUM> also indicates a corresponding progress time and a remaining time. An embodiment may use microphone icon <NUM> to indicate a potential for input such as a voice command. Activity identifier <NUM> may provide feedback that the system has identified activity <NUM> correctly and/or an average duration for activity <NUM>. An embodiment may use in scenario <NUM> an update of a new activity duration from scenario <NUM>. For instance, in scenario <NUM>, activity identifier <NUM> depicts "<NUM> minutes (average)" as a learned average activity duration for "Breakfast" as compared to activity identifier <NUM>, in scenario <NUM>, which depicts "<NUM> minutes (average)" as a prior average activity duration for "Breakfast. " An embodiment may hide or move one or more features of user interface <NUM>, <NUM>, and/or <NUM>.

An embodiment may select content such as video <NUM>, video <NUM>, and video <NUM> in many ways. A difference between scenario <NUM> and scenario <NUM> may be that scenario <NUM> provides content with a total runtime of <NUM>:<NUM> while scenario <NUM> provides video <NUM> with a runtime of <NUM>:<NUM>. In an embodiment like scenario <NUM>, video <NUM> may be a segment of a television program from VOD, DVR, or OTT, however, because stop timer <NUM> of scenario <NUM> indicates a duration of <NUM>:<NUM>, activity <NUM> finished after completion of video <NUM>.

In scenario <NUM>, content, including video <NUM>, video <NUM>, and video <NUM>, is selected as part of nine videos, as depicted in banners <NUM>, <NUM>, and <NUM>. In an embodiment like scenario <NUM>, content is selected in part because the total runtime of all videos, as indicated by progress time <NUM> and progress time <NUM> and <NUM>, is similar to a learned average activity duration of "<NUM> minutes (average)" as depicted in activity identifier <NUM>. In an embodiment, video <NUM> and video <NUM> may be selected instead of a television program with a runtime similar to video <NUM> because the runtime exceeds an average activity duration for activity <NUM> by a predetermined threshold. In an embodiment, the selection of content, including video <NUM>, video <NUM>, and video <NUM>, may be further based on substantive content in each video and then adjusted to fit an appropriate total runtime by adding more content, e.g., short video clips. In an embodiment, video <NUM>, video <NUM>, and video <NUM> may be selected from a pool of potential content items, for instance, because of associated metadata matching a profile of user <NUM> as well as fitting in a playlist with a total runtime similar to a learned average activity duration.

An exemplary embodiment is depicted in <FIG> as scenario <NUM> with smartphone <NUM>. Any other suitable device, such as any device as depicted in <FIG> and <FIG>, may be used instead of smartphone <NUM>.

Exemplary scenario <NUM> of <FIG> depicts an embodiment that learns a duration of an activity <NUM> in order to subsequently provide content for the duration of activity <NUM>, where there is a plurality of content items provided during initial training for an activity <NUM>. Scenario <NUM> depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may be any form of input, e.g., a voice command or a button press or a gesture, by user <NUM> and received by smartphone <NUM>. In exemplary scenario <NUM>, input <NUM> comprises begin cue <NUM>. Upon smartphone <NUM> receiving input <NUM> and begin cue <NUM>, a begin timer <NUM> initiates. An embodiment may record a timestamp for begin cue <NUM>, and begin timer <NUM> may be a calculated real-time difference from the timestamp for begin cue <NUM>. In an embodiment, begin cue <NUM> may identify activity <NUM>, e.g., "Begin 'Morning Commute' activity. " and begin cue <NUM> and activity <NUM> may be recorded in an activity duration database.

Scenario <NUM> also features an exemplary display screen of smartphone <NUM> with a content delivery application depicted as user interface <NUM>. User interface <NUM> may feature content, e.g., video <NUM>, that may be displayed during activity <NUM>. In scenario <NUM>, where the system is training or learning a duration, video <NUM> may be chosen in many different ways. An embodiment depicted in <FIG> may sequentially identify and provide a content item on an as needed basis until activity <NUM> is complete and an expected duration may be calculated. For instance, an embodiment may select video <NUM> based on matching interests, metadata, or a profile.

On user interface <NUM> appears banner <NUM>, which indicates that an activity is "started. " Counter <NUM> is depicted showing a time <NUM>:<NUM> and progress time <NUM> indicates that the progress is <NUM>:<NUM>. The position of marker <NUM> on video progress bar <NUM> may indicate a relative progress time of the activity or a remaining time of a video, e.g., as the total activity duration is unknown. An embodiment may use microphone icon <NUM> to indicate a potential for input such as a voice command to pause, resume, and/or end the activity and content. Activity identifier <NUM> may provide feedback that the system has identified activity <NUM> correctly and/or identify an estimated duration for activity <NUM>.

Scenario <NUM> further depicts video <NUM> in user interface <NUM> and video <NUM> in user interface <NUM> to demonstrate that a training scenario, such as scenario <NUM>, may provide multiple content items during activity <NUM>. Each of video <NUM> and video <NUM> are depicted with corresponding counter <NUM> and counter <NUM> indicating a relative progress time. Scenario <NUM> further depicts video <NUM> in user interface <NUM>; video <NUM> may be stopped or paused after a stop cue and/or end of the activity <NUM>.

Scenario <NUM> further depicts smartphone <NUM> receiving input <NUM> from user <NUM>. In an embodiment, input <NUM> may likewise be a voice command or other input received by smartphone <NUM> from user <NUM>. In exemplary scenario <NUM>, input <NUM> comprises stop cue <NUM>. Upon smartphone <NUM> receiving input <NUM> comprising a stop cue <NUM>, stop timer <NUM> is recorded as a duration. An average activity duration is then updated. An embodiment may record a timestamp for stop cue <NUM> and stop timer <NUM> may be a calculated real-time duration from a timestamp for begin cue <NUM>. In an embodiment, stop cue <NUM> may identify activity <NUM>, e.g., "Stop 'Morning Commute activity. " and stop cue <NUM> and activity <NUM> may be recorded. The average activity duration is updated by calculating a new average activity duration for activity <NUM>. In subsequent performances of activity <NUM> the new average activity duration for activity <NUM> based on recorded stop timer <NUM> is used as an estimated duration.

<FIG> depicts illustrative tables for activity data structures, in accordance with some embodiments of the disclosure. <FIG> depicts an illustrative table for an activity duration data structure, in accordance with some embodiments of the disclosure. An embodiment may store one or more activity duration data structures in an activity duration database.

An embodiment that may be used to track activity data incorporates an activity duration data structure as depicted in <FIG>. An embodiment may record start and stop times for an activity within such a data structure. There are many data structures suitable for tracking and storing conversations such as an array, matrix, stack, linked list, tree, queue or string. Hierarchical data structures such as a tree may be beneficial for organization based on different types of activities. Data structures may be stored in several ways, including in one or more databases. Data structures can be stored both locally on the device and remotely in a network. An embodiment may utilize an activity engine and/or a content curation engine, stored and executed by one or more of the processors and memory depicted in <FIG> and <FIG>, to store and track activity data as well as curate and provide content during each activity.

An embodiment may include an activity engine storing start and end times and calculating activity durations and average activity durations, as well as storing times and durations in an activity duration data structure such as an activity duration data structure <NUM> depicted in <FIG>. Activity duration data structure <NUM> may depict data recorded for a user performing an activity such as exercising on a treadmill. Activity duration data structure <NUM> includes fields such as entry field <NUM>, begin cue field <NUM>, end cue field <NUM>, duration field <NUM>, and updated average field <NUM>. In an embodiment as depicted in activity duration data structure <NUM>, each cell in duration field <NUM> includes a duration as calculated from a difference between end cue field <NUM> and begin cue field <NUM>. For instance, a duration of <NUM>:<NUM>:<NUM> in cell <NUM> is calculated as a difference between <NUM>:<NUM>:<NUM> PM from cell <NUM> and <NUM>:<NUM>:<NUM> PM from cell <NUM>, both occurring on <NUM>/<NUM>/<NUM>. An embodiment may include cell <NUM>, an updated average field <NUM> cell, as an arithmetic mean calculated from prior entry durations. Such an embodiment may be learning with each iteration of an activity and entry in activity duration data structure <NUM>.

In activity duration data structure <NUM>, for example, entry <NUM> in row <NUM> includes a duration field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> and an updated average field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM>. Entry <NUM> in row <NUM> includes a duration field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> and an updated average field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> based on, e.g., the arithmetic mean of <NUM>:<NUM>:<NUM> and <NUM>:<NUM>:<NUM>. Entry <NUM> and entry <NUM> are calculated as, e.g., an arithmetic mean of prior entries, to yield <NUM>:<NUM>:<NUM> in cell <NUM> and <NUM>:<NUM>:<NUM> in cell <NUM>.

One or more content items are provided for the expected duration of an activity, e.g., data in a cell from updated average field <NUM> from a most recent entry. For instance, an embodiment using an updated average field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> selects and provides one or more content items with a total runtime similar to <NUM> minutes and <NUM> seconds. An embodiment may use one or more content items with a runtime that is similar but different from an expected activity duration, e.g., when the content substance is known to be of interest to a user. Depending on the actual one or more content items provided and their corresponding runtimes, a subsequent entry may have a duration field <NUM> either shorter or longer than the updated average field <NUM> of the prior entry. For instance, a duration field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> is longer than an expected duration based on updated average field <NUM> of <NUM>:<NUM>:<NUM> in cell <NUM> which could indicate, e.g., variability in activity duration or that a provided content item ran longer than expected.

An embodiment may provide a video on business news despite a user's preference for sports news because the runtime may fit a portion of an activity better, but a user who dislikes business news may prefer a video clip of sports news even if the segment runtime may not fit the duration or may run longer. An embodiment that may provide a sports clip even though its inclusion may increase a runtime beyond an expected duration may yield data similar to entry <NUM> in row <NUM> and may trigger an adjustment to increase updated average <NUM>, such as in cell <NUM>. Likewise, an embodiment that may provide preferred weather content even though its inclusion may decrease a runtime from an expected duration may yield data similar to entry <NUM> in row <NUM>, which may trigger an adjustment to lower an updated average <NUM>, such as in cell <NUM>.

<FIG> depicts an illustrative flowchart of a process for learning a duration of a variable-duration activity and providing content during a variable-duration activity in accordance with one or more embodiments. An embodiment may include, for instance, an activity engine and a content curation engine carrying out the steps depicted in the flowchart of <FIG>.

In step <NUM>, an activity engine receives input with the start cue for an activity. In step <NUM>, the activity engine accesses an activity duration database. In step <NUM>, the activity engine determines if there is an average duration for the activity stored in the activity duration database. If there is not an average duration for the activity previously stored, then in step <NUM>, an activity timer is started and, in step <NUM>, the content curation engine provides one or more content items for consumption during the activity. The content curation engine provides content for consumption until a stop cue for the activity is received, in step <NUM> the activity engine determines if a stop cue is received. In step <NUM>, if there is not a stop cue received by the activity engine, the content curation engine keeps providing content and waiting for input with a stop cue. If a stop cue is received by the activity engine, then the content curation engine, in step <NUM>, stops providing content.

If there is an average duration stored for the activity, as determined in step <NUM>, then, in step <NUM>, the activity engine uses the average time as the activity duration. In step <NUM>, an activity timer is started. In step <NUM>, the content curation engine identifies one or more content items with a total runtime substantially similar to the activity duration. In step <NUM>, the content curation engine provides one or more content items for consumption during the activity until it stops providing content in step <NUM>.

When the content curation engine stops providing content in step <NUM>, either after step <NUM> or step <NUM>, the activity engine, in step <NUM>, stops the activity timer. In step <NUM>, the activity engine records the end time and duration in the activity duration database and updates the average duration and then waits to receive input with a start cue for the subsequent instance of the activity, in step <NUM>.

<FIG> depicts an illustrative flowchart of a process for learning a duration of a variable-duration activity and providing content during a variable-duration activity in accordance with one or more embodiments. An embodiment may include, for instance, an activity engine and/or a content curation engine carrying out the steps depicted in the flowchart of <FIG>.

In step <NUM>, an activity engine receives input with the start cue for an activity. In step <NUM>, the activity engine accesses an activity duration database. In step <NUM>, the activity engine determines if there is an average duration for the activity stored in the activity duration database. If there is an average duration for the activity previously stored, then, in step <NUM>, the activity engine uses the stored average time as an activity duration. If there is not an average duration for the activity previously stored, then in step <NUM>, the activity engine identifies a reasonable duration, e.g., from an external database or a default time, and uses the identified reasonable duration as the activity duration.

Then in step <NUM>, an activity timer is started and, in step <NUM>, the content curation engine identifies one or more content items with a total runtime substantially similar to the activity duration determined from step <NUM> or step <NUM>. In step <NUM>, the content curation engine provides one or more content items for consumption during the activity. The content curation engine provides one or more content items for consumption until the end of the total runtime of the one or more content items or a stop cue is received by the activity engine. For instance, in step <NUM> the activity engine determines if input with a stop cue is received. If a stop cue is not received, then, in step <NUM>, the activity engine keeps waiting to receive input with a stop cue and the content curation engine keeps providing content until the end of the total runtime. If a stop cue is received by the activity engine then, in step <NUM>, the content curation engine stops providing the content items. Once the content items are not provided in step <NUM> or the total runtime of the content items is reached, the activity engine stops the activity timer in step <NUM>. Then, in step <NUM>, the activity engine records the end time and duration in the activity duration database and updates the average duration and then waits to receive input with a start cue for the subsequent instance of the activity, in step <NUM>.

<FIG> shows a generalized embodiment of illustrative device <NUM>. As referred to herein, device <NUM> should be understood to mean any device that can receive input and provide content for consumption. As depicted in <FIG>, device <NUM> is a smartphone. However, device <NUM> is not limited to smartphones and may be any computing device. For example, device <NUM> of <FIG> can be implemented in system <NUM> of <FIG> as device <NUM> (e.g., a smartphone, a smart television, a tablet, a microphone (e.g., with a virtual assistant), a computer, or any combination thereof).

Media device <NUM> may receive data via input/output (hereinafter I/O) path <NUM>. I/O path <NUM> may provide received data to control circuitry <NUM>, which includes processing circuitry <NUM> and storage <NUM>. Control circuitry <NUM> may be used to send and receive commands, requests, and other suitable data using I/O path <NUM>. I/O path <NUM> may connect control circuitry <NUM> (and specifically processing circuitry <NUM>) to one or more communication paths (described below). I/O functions may be provided by one or more of these communication paths, but are shown as a single path in <FIG> to avoid overcomplicating the drawing.

Control circuitry <NUM> may be based on any suitable processing circuitry such as processing circuitry <NUM>. As referred to herein, processing circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores) or supercomputer. In some embodiments, processing circuitry may be distributed across multiple separate processors or processing units, for example, multiple of the same type of processing units (e.g., two Intel Core i7 processors) or multiple different processors (e.g., an Intel Core i5 processor and an Intel Core i7 processor). In some embodiments, control circuitry <NUM> executes instructions for an activity engine and/or a content curation engine stored in memory (i.e., storage <NUM>).

An activity engine may be a stand-alone application implemented on a device or a server. A content curation engine may be a stand-alone application implemented on a device or a server. An activity engine and/or a content curation engine may be implemented as software or a set of executable instructions. The instructions for performing any of the embodiments discussed herein of the activity engine and/or a content curation engine may be encoded on non-transitory computer-readable media (e.g., a hard drive, random-access memory on a DRAM integrated circuit, read-only memory on a BLU-RAY disk, etc.) or transitory computer-readable media (e.g., propagating signals carrying data and/or instructions). For example, in <FIG>, the instructions may be stored in storage <NUM>, and executed by control circuitry <NUM> of a device <NUM>.

In some embodiments, an activity engine may be a client-server application where only the client application resides on device <NUM> (e.g., device <NUM>), and a server application resides on an external server (e.g., server <NUM>). For example, an activity engine and/or a content curation engine may be implemented partially as a client application on control circuitry <NUM> of device <NUM> and partially on server <NUM> as a server application running on control circuitry. Server <NUM> may be a part of a local area network with device <NUM>, or may be part of a cloud computing environment accessed via the internet. In a cloud computing environment, various types of computing services for performing searches on the internet or informational databases, providing storage (e.g., for the keyword-topic database) or parsing data are provided by a collection of network-accessible computing and storage resources (e.g., server <NUM>), referred to as "the cloud. " Device <NUM> may be a cloud client that relies on the cloud computing capabilities from server <NUM> to determine times, identify one or more content items, and provide content items by the activity engine and/or content curation engine. When executed by control circuitry of server <NUM>, the activity engine may instruct the control circuitry to generate the activity engine output (e.g., the average duration) and transmit the generated output to device <NUM>. When executed by control circuitry of server <NUM>, the content curation engine may instruct the control circuitry to generate the content curation engine output (e.g., content items) and transmit the generated output to device <NUM>. The client application may instruct control circuitry of the receiving device <NUM> to generate the activity engine and/or content curation engine output. Alternatively, device <NUM> may perform all computations locally via control circuitry <NUM> without relying on server <NUM>.

Control circuitry <NUM> may include communications circuitry suitable for communicating with an activity engine server, a content curation engine server, or other networks or servers. The instructions for carrying out the above-mentioned functionality may be stored and executed on server <NUM>. Communications circuitry may include a cable modem, an integrated services digital network (ISDN) modem, a digital subscriber line (DSL) modem, a telephone modem, an Ethernet card, or a wireless modem for communications with other equipment, or any other suitable communications circuitry. Such communications may involve the internet or any other suitable communication network or paths. In addition, communications circuitry may include circuitry that enables peer-to-peer communication of devices, or communication of devices in locations remote from each other.

Memory may be an electronic storage device provided as storage <NUM> that is part of control circuitry <NUM>. As referred to herein, the phrase "electronic storage device" or "storage device" should be understood to mean any device for storing electronic data, computer software, or firmware, such as random-access memory, read-only memory, hard drives, optical drives, solid state devices, quantum storage devices, gaming consoles, or any other suitable fixed or removable storage devices, and/or any combination of the same. Nonvolatile memory may also be used (e.g., to launch a boot-up routine and other instructions). Cloud-based storage (e.g., on server <NUM>) may be used to supplement storage <NUM> or instead of storage <NUM>.

A user may send instructions to control circuitry <NUM> using user input interface <NUM> of device <NUM>. User input interface <NUM> may be any suitable user interface touch-screen, touchpad, stylus and may be responsive to external device add-ons such as a remote control, mouse, trackball, keypad, keyboard, joystick, voice recognition interface, or other user input interfaces. Display <NUM> may be a touchscreen or touch-sensitive display. In such circumstances, user input interface <NUM> may be integrated with or combined with display <NUM>. Display <NUM> may be one or more of a monitor, a television, a liquid crystal display (LCD) for a mobile device, amorphous silicon display, low temperature poly silicon display, electronic ink display, electrophoretic display, active matrix display, electro-wetting display, electro-fluidic display, cathode ray tube display, light-emitting diode display, electroluminescent display, plasma display panel, high-performance addressing display, thin-film transistor display, organic light-emitting diode display, surface-conduction electron-emitter display (SED), laser television, carbon nanotubes, quantum dot display, interferometric modulator display, or any other suitable equipment for displaying visual images. A video card or graphics card may generate the output to the display <NUM>. Speakers <NUM> may be provided as integrated with other elements of user equipment device <NUM> or may be stand-alone units. An audio component of content displayed on display <NUM> may be played through speakers <NUM>. In some embodiments, the audio may be distributed to a receiver (not shown), which processes and outputs the audio via speakers <NUM>.

Control circuitry <NUM> may allow a user to provide user profile information or may automatically compile user profile information. For example, control circuitry <NUM> may monitor the words the user inputs in his/her messages for keywords and topics. In some embodiments, control circuitry <NUM> monitors user inputs such as texts, calls, conversation audio, social media posts, etc., to detect keywords and topics. Control circuitry <NUM> may store the detected input terms in a keyword-topic database and the keyword-topic database may be linked to the user profile. Additionally, control circuitry <NUM> may obtain all or part of other user profiles that are related to a particular user (e.g., via social media networks), and/or obtain information about the user from other sources that control circuitry <NUM> may access. As a result, a user can be provided with a unified experience across the user's different devices.

As depicted in <FIG>, device <NUM> may be coupled to communication network <NUM>. Communication network <NUM> may be one or more networks including the internet, a mobile phone network, mobile voice or data network (e.g., a <NUM> or LTE network), cable network, public switched telephone network, Bluetooth, or other types of communication network or combinations of communication networks. Thus, device <NUM> may communicate with server <NUM> over communication network <NUM> via communications circuitry described above. In should be noted that there may be more than one server <NUM>, but only one is shown in <FIG> to avoid overcomplicating the drawing. The arrows connecting the respective device(s) and server(s) represent communication paths, which may include a satellite path, a fiber-optic path, a cable path, a path that supports internet communications (e.g., IPTV), free-space connections (e.g., for broadcast or other wireless signals), or any other suitable wired or wireless communications path or combination of such paths.

Claim 1:
A method of learning a duration of a variable-duration activity for a user and providing media content for the duration of the variable-duration activity, the method carried out by an electronic device and comprising:
receiving a plurality of start cues (<NUM>) each indicating a start of a variable-duration activity (<NUM>) for the user, wherein each of the start cues is based on a detected sound input which is not generated by a user voice telling the electronic device that the variable-duration activity (<NUM>) is beginning;
receiving a plurality of respective stop cues (<NUM>) indicating an end of the variable-duration activity (<NUM>) for the user;
determining an average duration for the variable-duration activity (<NUM>) based on time differences between the start cues (<NUM>) and the respective stop cues (<NUM>);
receiving a third input (<NUM>) including a second start cue (<NUM>) indicating another start of the variable-duration activity (<NUM>); identifying one or more media content items (<NUM>, <NUM>, <NUM>, <NUM>) to provide during the further variable-duration activity (<NUM>), having a total runtime that is substantially the same as the average duration for the variable-duration activity (<NUM>); and providing the one or more media content items (<NUM>, <NUM>, <NUM>, <NUM>) for consumption during the further session of the variable-duration activity; and
receiving a fourth input (<NUM>) including a second stop cue (<NUM>) indicating another end of the variable-duration activity (<NUM>), identifying the second stop cue (<NUM>) and updating the average duration for the variable-duration activity (<NUM>) based on a second time difference between the second start cue (<NUM>) and the second stop cue (<NUM>).