U.S. Pat. No. 10,140,271

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerous examples and details are set forth in order to provide an understanding of various embodiments. It will be evident, however, to one skilled in the art that certain embodiments can be practiced without some of these details, or can be practiced with modifications or equivalents thereof.

Embodiments of the present disclosure provide techniques for dynamically adapting the presentation of a narrative to a user across different types of digital media (e.g., a video game, a digitally-streamed film or episodic series, an electronic book, a web site, a virtual reality (VR) world, etc.). More specifically, these techniques can modify what portions of, and/or the manner in which, the narrative is conveyed to the user via one digital medium based on the narrative portions that have already been consumed by the user via one or more other digital mediums. With this solution, the user can experience the narrative in a cohesive, connected, and consistent manner across the various media types through which the narrative is made available.

These and other aspects of the present disclosure are described in further detail in the sections that follow.

1. System Environment

FIG. 1depicts a system environment100in which embodiments of the present disclosure may be implemented. As shown, system environment100includes a number of client devices102(1)-(N) that are owned and/or operated by a user104. Each client device102is an electronic device or system (e.g., a desktop/laptop computer, a game console, a smartphone, a tablet, etc.) that incorporates a digital medium client106. Each digital medium client106is, in turn, a software and/or hardware-based component that is configured to provide a platform through which narrative content, encoded in the form of a particular digital medium, can be delivered to and consumed by user104. By way of example, digital medium client106(1) may be a video player that is configured to deliver a narrative in the form of a digital video (e.g., a film or episodic series) for viewing by user104, digital medium client106(2) may be a video game application that is configured to deliver a narrative in the form of a video game for playing by user104, digital medium client106(3) may be an e-book reader that is configured to deliver a narrative in the form of an electronic book for reading by user104, and so on.

While digital narratives are often conveyed via a single medium, in some cases a content creator may produce a hybrid-media narrative that spans multiple different types of digital media. For instance, returning to the example above, a content creator may produce a hybrid-media narrative whose plot is developed/advanced through a combination of the digital video delivered via the video player of client device102(1), the video game delivered via the video game application of client device102(2), and the electronic book delivered via the e-book reader of client device102(3). However, as noted in the Background section, existing approaches for implementing such hybrid-media narratives generally fail to tie together the user's interaction with each media type into a singular and cohesive user experience.

To address this deficiency, system environment100includes a novel server system108that is communicatively coupled with client devices102(1)-(N) (via, e.g., one or more networks110) and is configured to maintain an overall narrative state112for a hybrid-media narrative to be presented to user104via digital medium clients106(1)-(N). In addition, each digital medium client106is configured to include a novel narrative adaptation component114.

As described in further detail below, when user104consumes or modifies the hybrid-media narrative via a first digital medium client, server system108can update its stored narrative state112to reflect the consumed/modified portion. At a later time, when user104attempts to access the same narrative via a second digital medium client different from the first digital medium client, the narrative adaptation component of the second digital medium client can retrieve the most recent version of narrative state112from server system108(which includes the updates caused by the user's consumption of the narrative via the first digital medium client), inspect the retrieved state, and then dynamically adapt, using one or more rules, the second digital medium client's presentation of the narrative to user104in view of the retrieved state. For instance, if user104previously viewed a particular plot point via the first digital medium client, the second digital medium client may modify the subsequent presentation of the narrative to user104in a way that avoids repeating that same plot point, or assumes that user104is aware the plot point has already transpired. In this manner, user104can be provided a sense of continuity when consuming the hybrid-media narrative across the various media types.

It should be appreciated that system environment100ofFIG. 1is illustrative and not intended to limit the embodiments described herein. For example, although each client device102is shown as including a single digital medium client106, in some embodiments a particular client device102may include several different digital medium clients (e.g., a video player and a video game application).

Further, although a single instance of narrative state112(specific to user104) is shown as being maintained by server system108, in practice server system108will typically maintain multiple instances of narrative state112, each being associated with a different registered user (or group of users) of the system. One of ordinary skill in the art will recognize other variations, modifications, and alternatives.

2. Workflows

FIGS. 2 and 3depict high-level workflows200and300that may be performed by server system108and client devices102ofFIG. 1for dynamic adapting the presentation of a hybrid-media narrative to user104across different types of digital media according to an embodiment.

Starting with block202of workflow200(FIG. 2), server system108can initialize narrative state112, which reflects the state of the hybrid-media narrative for user104, with initial or default values indicating that the state is “clean” (i.e., untouched by user104). This step will typically be performed when user104first registers himself or herself with server system108and thus has not yet consumed any portion of the narrative via digital medium clients106(1)-(N).

In one set of embodiments, narrative state112can be implemented as a key-value store comprising key-value pairs, where each key identifies a unit of content in the hybrid-media narrative (e.g., a conversation exchange between actors, a plot point or scene, etc.), and where each value indicates whether the content unit identified by the corresponding key has been presented to, and thus consumed by, user104. In these embodiments, the initialization performed at block202can involve setting the value of each key-value pair in narrative state112to “FALSE” (or an equivalent value such as “NO,” 0, etc.), thereby indicating that these units of content have not yet been consumed.

In alternative embodiments, narrative state112can be implemented using any other type of data structure known in the art (e.g., a relational database, etc.) that is capable of representing the narrative as a collection of content units and is capable of storing metadata for each content unit that reflects the unit's “consumed” status. In these alternative embodiments, the initialization performed at block202can involve setting this metadata with initial/default values using a mechanism that is appropriate for the data structure.

At block204, user104can login to a first digital medium client106(X) in order to access the narrative through the digital medium delivered via that client. For example, if digital medium client106(X) is a video player, user104can login to client106(X) in order to access the narrative as a digital video that is delivered through that video player application. In various embodiments, the login process can be implemented using a conventional approach whereby user104provides an indication of his/her identity (e.g., a registered user ID, email address, etc.) and security credentials (e.g., a password, PIN, etc.) to digital medium client106(X), and client106(X) subsequently authenticates user104's identity using the supplied credentials. This authentication can be performed locally on the client device hosting client106(X) or via communication with server system108(or a separate authentication server).

At blocks206and208, digital medium client106(X) can retrieve a copy of narrative state112from server system108based on user104's logged-in identity and can inspect the retrieved state via its narrative adaptation component114(X). As part of block208, narrative adaptation component114(X) can determine which content units of the narrative have been consumed by user104by virtue of the metadata associated with each content unit in narrative state112. In this particular example, since narrative state112is still “clean,” narrative adaptation component114(X) can determine that no content units have yet been consumed.

Then, at block210, narrative adaptation component114(X) can dynamically adapt the presentation of the narrative to user104via client106(X) based on the inspection performed at block208and one or more predefined rules specific to client106(X). Generally speaking, this adaptation can take into account what portions of the narrative have already been consumed by user104(as indicated in narrative state112) and can determine what portions of, and/or how, the narrative should be presented next to user104in order to provide a sense of story continuity. As mentioned previously, in this particular example narrative state112is still clean, and thus narrative adaptation component114(X) may determine that the narrative should be presented from the very beginning of its story arc (since user104has not yet consumed any portion of the narrative).

At block212, digital medium client106(X) can present the narrative, in the form of its associated digital medium, to user104in accordance with the adaptation performed at block210. For example, if digital medium client106(X) is a video player application, client106(X) may stream one or more video clips corresponding to the narrative's opening scene or episode. In response, user104can consume the presented content (block214).

Finally, at blocks216and218, digital medium client106(X) can update its local copy of narrative state112based on the content consumed by user104and can transmit the updated copy to server system108for storage on that system. With these steps, server system108can be made aware of the consumed portions so that this information can be exploited by the other digital medium clients operated by user104. In one set of embodiments, the updating of narrative state112at block216can comprise identifying the specific content units consumed by user104and setting the metadata associated with those content units to indicate a “consumed” status. For instance, in embodiments where narrative state112is implemented as a key-value store, this step can comprise identifying the key-value pairs corresponding to the consumed content units and setting the value of each identified key-value pair to “TRUE” or an equivalent value.

Further, the transmission of the updated narrative state at block218can comprise identifying the specific content units whose state has been updated per block216and sending those content units (and their associated metadata) to server system108. This transmission may occur upon, e.g., user logout from digital medium client106(X), and/or on a continuous basis as user104is consuming the presented narrative content. For example, digital medium client106(X) may send updated state information to server system108each time user104consumes a content unit or passes a predefined checkpoint.

Turning now to workflow300(FIG. 3), at a later point in time, user104can login to a second digital medium client106(Y) that is different from first digital medium client106(X) in order to access the narrative through the digital medium delivered via client106(Y) (block302). For example, if digital medium client106(Y) is a video game application, user104can login to client106(Y) in order to access the narrative as a video game that is delivered through that application. Like block204of workflow300, this login process can be implemented using a conventional user ID and credentials-based authentication approach.

At block304, digital medium client106(Y) can retrieve the most recent copy of narrative state112from server system108based on user104's logged-in identity. Note that since user104has already accessed the narrative via digital medium client106(X) per workflow200, this retrieved copy of narrative state112will reflect the narrative content units that have been consumed by user104via that first client.

At block306, narrative adaptation component114(Y) of digital medium client106(Y) can inspect the retrieved narrative state, thereby identifying the content units already consumed by user104. Narrative adaptation component114(Y) can then dynamically adapt the presentation of the narrative in view of that knowledge and one or more predefined rules specific to client106(Y) (block308). As mentioned previously, this adaptation step can specifically determine what portions of, and/or how, the narrative should be presented next to user104in order to provide a sense of story continuity. For instance, assume that user104viewed opening scene S1 via digital medium client106(X) at block214of workflow200. In this scenario, narrative adaptation component114(Y) can modify client106(Y)'s presentation of the narrative to, e.g., convey a subsequent piece of narrative content that follows from scene S1, or otherwise adapt the narrative in a manner that assumes user knowledge of S1.

In many cases, the adaptation rules applied at block308(as well as at analogous block210of workflow200) will be tied in some fashion to the type of digital medium supported by the digital medium client. For example, if digital medium client106(Y) is a video game application as mentioned above, the adaptation may involve modifications that are specific to the video game context (e.g., changing the game level the user may play, changing the attributes of the player character or environment, changing the attributes of non-player characters (NPCs), etc.). However, in certain alternative embodiments, the adaptation rules applied at blocks308/210may also comprise rules that are more generally applicable to a range of different digital media.

At block310, digital medium client106(Y) can present the narrative, in the form of its associated digital medium, to user104in accordance with the adaptation performed at block308. In response, user104can consume the presented content (block312).

Then, in a manner similar to blocks216and218of workflow200, digital medium client106(Y) can update its local copy of narrative state112based on the content consumed by user104(block314) and can transmit the updated copy to server system108for storage on that system (block316).

Finally, at block318, user104can subsequently access the narrative via additional digital medium clients and workflow300can be repeated for those additional clients. In this way, narrative state112can be continually updated by each digital medium client based on what has been consumed by user104via that client, and this evolving narrative state can be exploited by each client to dynamically determine the narrative content that is presented next to the user. The end result of this overall process is that the narrative is conveyed in a cohesive and seamless manner to the user across the plurality of clients/mediums.

It should be appreciated that workflows200and300ofFIGS. 2 and 3are illustrative and various modifications are possible. For example, although workflows200and300indicate that the act of updating narrative state112is performed on the client side (i.e., by digital medium clients106), in certain embodiments server system108may also directly modify/update narrative state112based on one or more server-side rules. This can be useful in scenarios where the logic for modifying narrative state112is dependent on aggregate user behavior (which is known only to server system108and not to clients106), and/or scenarios where the narrative states for multiple users need to updated simultaneously based on some non-user-driven trigger. For instance, server system108may maintain a rule indicating that “the first 1000 users that consume content unit X will result in consequence Y; for any users after the 1000th user, consuming content unit X will result in consequence Z.” In this case, since server system108maintains the narrative states of all registered users, it can determine when 1000 users have consumed X and can inject information into the narrative state of each user as appropriate (e.g., to reflect the occurrence of consequence Y or Z).

Further, although narrative state112has been generally described as comprising a collection of narrative content units (e.g., keys) and associated metadata for each content unit (e.g., values) reflecting the unit's consumed status, in certain embodiments, narrative state112may also include additional data/metadata relevant to the overall state of the narrative with respect to user104. For example, in one embodiment, narrative state112can also include temporal information indicating the order in which certain content units have been consumed by user104. This temporal information can be embodied in the form of, e.g., a timestamp that is associated with one or more content units. In another embodiment, in cases where the consumption of a particular content unit implies that user104did not consume one or more alternative content units (e.g., the user chose path A instead of mutually exclusive paths B or C), narrative state112can also include information identifying the relationships between these consumed and “unconsumed” content units. Narrative adaptation components114of digital medium clients106can take into account all, or any subset, of these additional pieces of data/metadata at the time of adapting narrative content for presentation to user104.

3. Example Narrative State and Adaptation Rules

To further illustrate the techniques described herein, Table 1 below depicts a simplified example of a narrative state that may be maintained by server system108according to an embodiment. In this example, the narrative is a murder mystery and the narrative state is composed of four content units relevant to the murder, each of which is associated with a GUID (globally unique identifier), a description, and a bit flag indicating its consumed status (e.g., 1 for consumed, 0 for not consumed). These bit flags are initially set to 0, indicating that none of the content units have yet been consumed by the user.

TABLE 1GUIDDescriptionBit Flag1001Murder has occurred01002Body has been found01003Suspect ran away01004Murder investigation initiated0

In addition, Listings 1 and 2 below provide example adaptation rules that may be implemented by a video player and a video game application respectively for dynamically adapting the presentation of the narrative in view of the narrative state. It should be appreciated that these rules are presented in an exemplary pseudo-code format and, in practice, can be structured according to any programming or rule language known in the art.

Listing 1IF bit flag(1001) == 0Show scene(s) leading up to, and including, murderELSE IF bit flag(1002) == 0Show scene of user discovery of bodyELSE show scene of murder investigation being initiated

Listing 2IF bit flag(1001) == 0Play interactive game level preceding the murderELSE IF bit flag(1002) == 0Show noninteractive scene of user discovery of bodyPresent user choice of staying at murder location or running awayIF bit flag(1003) == 1Play interactive game level of escape sequenceShow noninteractive scene of murder investigation being initiated

With the foregoing in mind, assume the user first logs into the video player. In response, the video player will download the narrative state associated with the user (as depicted in Table 1) and apply this state information to its adaptation rules (as depicted in Listing 1). Since the bit flag for content unit 1001 (i.e., “murder has occurred”) is initially set to 0, video player will show the video scene(s) leading up to, and including, the murder to the user. In addition, the video player will update its local copy of the narrative state to change the bit flag for 1001 from 0 to 1 (since the user has now consumed this content unit).

Assume that the user subsequently logs off of the video player and logs into the video game application. In this case, the video player will transmit its updated copy of the narrative state to the server system, and the video game application will thereafter download the updated narrative state for the user to local storage. The video game application will then apply the updated state information to its adaptation rules as depicted in Listing 2. Since the bit flag for content unit 1001 is now set to 1, the video game application will skip the interactive game level preceding the murder and instead check whether the bit flag for content unit 1002 (i.e., “body has been found”) is set to 0 (which it is). In response, the video game application will show a noninteractive scene of the user's discovery of the body (thereby updating the bit flag for 1002 from 0 to 1) and provide the user a choice to stay at the murder location or to run away.

If the user decides to run away, the video game application will update the bit flag for content unit 1003 (i.e., “suspect ran away”) from 0 to 1, and as a result allow the user to play an interactive game level of an escape sequence. At the conclusion of this game level (or if the user decided not to run away), the video game application will show a noninteractive cutscene of the murder investigation being initiated. Then, the video game application will update its local copy of the narrative state to change the bit flag for 1004 from 0 to 1 (since the user has now consumed this content unit).

Finally, if the user subsequently logs off of the video game application, the video game application will transmit its updated copy of the narrative state to the server system. Thus, the updated narrative state can be further used/exploited by the video player, the video game application, and/or other digital medium clients the next time the user decides to access the narrative via one of those clients.

4. Example Computing Device/System

FIG. 4depicts an example computing device/system400according to an embodiment. Computing device/system400may be used to implement, e.g., server system108or any of client devices102(1)-(N) described in the foregoing sections.

As shown, computing device/system400can include one or more processors402that communicate with a number of peripheral devices via a bus subsystem404. These peripheral devices can include a storage subsystem406(comprising a memory subsystem408and a file storage subsystem410), user interface input devices412, user interface output devices414, and a network interface subsystem416.

Bus subsystem404can provide a mechanism for letting the various components and subsystems of computing device/system400communicate with each other as intended. Although bus subsystem404is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses.

Network interface subsystem416can serve as an interface for communicating data between computing device/system400and other computing devices or networks. Embodiments of network interface subsystem416can include wired (e.g., coaxial, twisted pair, or fiber optic Ethernet) and/or wireless (e.g., Wi-Fi, cellular, Bluetooth, etc.) interfaces.

User interface input devices412can include a keyboard, pointing devices (e.g., mouse, trackball, touchpad, etc.), a scanner, a barcode scanner, a touch-screen incorporated into a display, audio input devices (e.g., voice recognition systems, microphones, etc.), and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into computing device/system400.

User interface output devices414can include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices, etc. The display subsystem can be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from computing device/system400.

Storage subsystem406can include a memory subsystem408and a file/disk storage subsystem410. Subsystems408and410represent non-transitory computer-readable storage media that can store program code and/or data that provide the functionality of various embodiments described herein.

Memory subsystem408can include a number of memories including a main random access memory (RAM)418for storage of instructions and data during program execution and a read-only memory (ROM)420in which fixed instructions are stored. File storage subsystem410can provide persistent (i.e., non-volatile) storage for program and data files and can include a magnetic or solid-state hard disk drive, an optical drive along with associated removable media (e.g., CD-ROM, DVD, Blu-Ray, etc.), a removable flash memory-based drive or card, and/or other types of storage media known in the art.

It should be appreciated that computing device/system400is illustrative and not intended to limit embodiments of the present disclosure. Many other configurations having more or fewer components than computing device/system400are possible.

The above description illustrates various embodiments of the present disclosure along with examples of how certain aspects may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present disclosure as defined by the following claims. For example, although certain embodiments have been described with respect to particular process flows and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not strictly limited to the described flows and steps. Steps described as sequential may be executed in parallel, order of steps may be varied, and steps may be modified, combined, added, or omitted. As another example, although certain embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are possible, and that specific operations described as being implemented in software can also be implemented in hardware and vice versa.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense. Other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as set forth in the following claims.