Patent Description:
Graphical user interfaces (GUIs) are the predominant type of interfaces available to users for interacting with computer systems. A GUI includes selectable icons to launch applications. Typically, upon a launch of a first application, the first application is presented in a first window. Upon a launch of a second application, a second window is used and the user control shifts from the first window to the second one. In addition, dynamic content (e.g., interactive media content) presented in the first window may be paused. If the user desires to interact with the first application, additional user input is needed to shift the control from the second window back to the first one.

To illustrate, consider an example of a GUI of a video game system hosting a video game application and a music streaming application. The GUI presents a home page that includes a video game icon and a music streaming icon. From this home page, a video game player selects the video game icon to launch the video game application. Video game content is then presented in the GUI. To stream music, the video game player may need to pause the execution of the video game application, switch back to the home page, and select the music streaming icon. Upon this selection, the music streaming application is launched and music can be played over speakers of the video game system. To resume the video game, the video game player may need to minimize the window of the music streaming application, switch back to the home page, expand the window of the video game application, and un-pause the video game content.

Hence, although a GUI can be an effective user interface, switching between applications may not be seamless and the presentation of information may be limited to an active window. There is a need for an improved GUI that allows better information sharing and control switching.

<CIT> discloses an application management interface on an electronic device. An implementation contemplates controlling a display to generate at least one installed application identifier in conjunction with at least one active application identifiers which can be selected for invocation of a corresponding application.

Embodiments of the present disclosure relate to techniques for better information sharing and control switching in a graphical user interface (GUI). In an example, a computer system for presenting a dynamic menu for different applications of the computer system, a method implemented by the computer system, and one or more non-transitory computer-readable media storing computer-readable instructions executable on the computer system are described. In particular, a menu application of the computer system determines active computing services and inactive computing services available from the different applications. The menu application determines a first order of presentation of first windows within the dynamic menu. Each of the first windows corresponds to one of the active computing services. The first order indicates an arrangement of the first windows based on at least one of: (i) timing of activating the active computing services, or (ii) timing of interacting with the active computing services. The menu application determines a context of at least one of: a user application of the computer system, a system application of the computer system, or a user of the computer system. The menu application determines, based on the context, a second order of presentation of second windows within the dynamic menu. Each of the second windows corresponds to one of the inactive computing services. The second order is predefined for the context, indicates an arrangement of the second windows according to application types, and is different from another order predefined for another context. The menu application presents the first windows within the dynamic menu according to the first order and the second windows within the dynamic menu according to the second order. One or more of the first windows and one or more of the second windows are presented in a first presentation state. One of the first windows or one of the second windows is presented in a second presentation state. The second presentation state presents more information relative to the first presentation state.

Generally, systems and methods for better information sharing and control switching in a graphical user interface (GUI) are described. In an example, a computer system presents a GUI on a display. Upon user input requesting a menu, the menu is presented in the GUI based on an execution of a menu application. The menu includes a dynamic area that presents a plurality of windows. Each of the windows corresponds to a target application and can be included in the dynamic menu area based on whether the target application is active or inactive, and depending on a context if the target application is inactive. The dynamic menu area shows the windows in a first presentation state (e.g., glanced state), where each window presents content in this presentation state. Upon user interactions with the dynamic menu area, the presentation of the windows can change to a second presentation state (e.g., focused state), where a window in the second state and its content are resized and where an action performable on the content can be selected. Upon a user selection of the window in the second state, the presentation of the window changes to a third presentation state (e.g., selected state), where the windows and its content are resized again and where an action performable on the window can be further selected.

In a further example, implementing the above UI functions via the GUI is a computer system executing one or more applications for generating and/or presenting windows in one of the presentation states in the menu (referred to herein as a dynamic menu as it includes a dynamic menu area). For instance, the computer system executes the menu application to, upon a user request for the dynamic menu, present windows in the first or second states and populates windows in the dynamic menu with content associated with either active or inactive applications of the computer system. In particular, the menu application determines a first order of windows and a second order of windows, associated with active applications and inactive applications, respectively. Each order may include multiple sub-groupings of windows, based on criteria including, but not limited to, relevance, timing, and context, to improve user accessibility and promote interaction with applications of the computer system. The menu application may generate and/or present the dynamic menu to include the first order of windows arranged horizontally adjacent to the second order of windows in a navigable UI. User interaction with the dynamic menu may permit the user to view one or more windows in the first order and/or the second order in the focused state.

To illustrate, consider an example of a video game system. The video game system can host a menu application, a video game application, a music streaming application, a video streaming application, a social media application, a chat application (e.g., a "party chat" application), and multiple other applications. A video game player can login to the video game system and a home user interface is presented thereto on a display. From this interface, the video game player can launch the video game application and video game content can be presented on the display. Upon a user button push on a video game controller, a menu can be presented in a layer at the bottom of the display based on an execution of the menu application. The menu includes a dynamic area, presenting multiple windows, each associated with an application of the video game system (e.g., the video game application, the music streaming application, etc.) The windows within the dynamic area of the menu are shown in a glanced state, providing sufficient information to the video game player about the applications (e.g., to perceive the car race invitation and to see a cover of the music album). By default, only one of the windows is shown in a focused state at a time and remaining windows are shown in the glanced state. Focus is shifted within the dynamic menu by navigating between windows, for example, by using a video game controller to scroll through the dynamic menu. For instance, upon the user focus (e.g., the user scroll) being on the music window, that window is expanded to show a partial list of music files and to present a play key. By default, windows associated with the video game application are arranged to the left of the dynamic menu in a horizontal arrangement, where each window presents content from a different service of the video game application. For example, the first window, presented in the focused state, could present content related to the video game player's recent accomplishments in the video game application (e.g., trophies, replays, friend or fan reactions, etc.). Similarly, another window to the right in the dynamic menu could include additional and/or newly available levels for the video game player to choose from. A third window could present content related to online gaming communities and/or sessions to join. In this way, the dynamic menu can provide multiple points of access to different services available in the video game platform in a single organized menu of horizontal windows. Additionally, the dynamic menu may present windows from inactive applications, for example, to the right of those associated with active applications. Inactive applications could be related to the game, for example a chat that took place in the game, or could be unrelated, for example, a music player application. The menu application may organize the two sets of windows differently. For example, the windows to the left, for active application services, may be organized by timing, such as the most recently accessed service is at the far left and by default in the focused state. The windows to the right, associated with inactive application services, may be organized by relevance to the video game application and/or by context of the user and the system.

Embodiments of the present disclosure provide several advantages over existing GUIs and their underlying computer systems. For example, by selecting windows for presentation in a dynamic menu, relevant application information can be surfaced to a user. In this way, the user may access multiple application services for an active application and may be presented with services from multiple inactive application services in the same UI element. By presenting the dynamic window in a horizontal linear arrangement of windows including both active application services and inactive application services, based on the user focus, navigation of UI menus and menu trees is reduced to a single linear menu that determines content dynamically for presentation to the user. Such techniques reduce system computational demands, arising from repeatedly rendering menus, and improve user experience by reducing frustration and fatigue caused by inefficient menu navigation.

In the interest of clarity of explanation, the embodiments may be described in connection with a video game system. However, the embodiments are not limited as such and similarly apply to any other type of a computer system. Generally, a computer system presents a GUI on a display. The GUI may include a home user interface from which different applications of the computer system can be launched. Upon a launch of an application, a window that corresponds to the application can be presented in the GUI.

<FIG> illustrates an example of a menu with selectable actions, according to an embodiment of the present disclosure. As illustrated, a graphical user interface <NUM> of a computer system (e.g., a video game system) is presented on a display. The GUI <NUM> presents video game content <NUM> of a video game application of the computer system (e.g., one executed by the video game system) and a menu <NUM> of a menu application of the computer system (e.g., one executed by the video game system). The menu <NUM> can be presented over at least a portion of the video game content <NUM> such that to appear in the foreground of the GUI <NUM> while the video game content <NUM> appears in the background of the GUI <NUM>. For instance, the menu <NUM> and the video game content <NUM> are displayed within a menu window and a content window, respectively, where the menu window is shown in a layer that is over the content window and that overlaps with only a portion of the content window.

In an example, the menu <NUM> can occlude the portion of the video content <NUM> behind it or can have some degree of transparency. Additionally or alternatively, the texturing and/or brightness of the menu <NUM> and the video game content <NUM> can be set such that the menu <NUM> appears in the foreground and the video game content <NUM> appears in the background.

As illustrated, the menu <NUM> includes a dynamic menu area <NUM> and a static menu area <NUM>. The dynamic menu area <NUM> presents a plurality of windows 132A, 132B,. , <NUM>, each of which corresponds to an application of the computer system. The static menu area <NUM> presents icons 142A, 142B,. , <NUM>, each of which corresponds to a system function (e.g., power on, volume control, mute and unmute, etc.) or an application of the computer system. For brevity, each of the windows 132A, 132B,. , <NUM> is referred to herein as a window <NUM> and each of the icons 142A, 142B,. , <NUM> is referred to as an icon <NUM>. By containing the two areas <NUM> and <NUM>, the menu <NUM> represents a dashboard that shows contextually relevant features and relevant system functions without necessitating the user to exit their game play.

Generally, a window <NUM> is added to the dynamic menu area <NUM> based on a determination of potential relevance to the user of the GUI <NUM>, as described in more detail in reference to the following figures, below. A window <NUM> is added to the dynamic menu area <NUM> according to an order, where windows within the dynamic menu area <NUM> can be arranged based on the potential relevance to the user. In comparison, the static menu area <NUM> may not offer the dynamicity of the dynamic menu area <NUM>. Instead, the icons <NUM> can be preset in the static menu area <NUM> based on system settings and/or user settings. Upon a selection of an icon <NUM>, a corresponding window (e.g., for a system control or for a particular background application) can be presented. The menu <NUM> can be dismissed while the window is presented, or alternatively, the presentation of the menu <NUM> persists.

The content, interactivity, and states of the windows <NUM> are further described in connection with the next figures. Generally, upon the presentation of the menu <NUM>, the execution of the video game application and the presentation of the video game content <NUM> continue. Meanwhile, user input from an input device (e.g., from a video game controller) can be received and used to interact with the menu <NUM> in the dynamic area <NUM> and/or the static area <NUM>. The dynamic area interactions allow the user to view windows <NUM> in different states, and select and perform actions on the content of the windows <NUM> or the windows <NUM> themselves. The static area interactions allow the user to select any of the icons <NUM> to update the system functions (e.g., change the volume) or launch a preset window for a specific application (e.g., launch a window for a music streaming application). Once the interactions end, the menu <NUM> is dismissed and the user control automatically switches to the video game application (e.g., without input of the user explicitly and/or solely requesting the switch). Alternatively, the switch may not be automatic and may necessitate the relevant user input to change the user control back to the video game application. In both cases, user input received from the input device can be used to interact with the video game content <NUM> and/or the video game application.

Although <FIG> describes a window as being presented in a dynamic menu area or can be launched from an icon in a static menu area, other presentations of the window are possible. For instance, user input from the input device (e.g., a particular key push) can be associated with the window. Upon receiving the user input, the window can be presented in a layer over the video game content <NUM>, without the need to present the menu <NUM>.

<FIG> illustrates a computer system that presents a menu, according to an embodiment of the present disclosure. As illustrated, the computer system includes a video game console <NUM>, a video game controller <NUM>, and a display <NUM>. Although not shown, the computer system may also include a backend system, such as a set of cloud servers, that is communicatively coupled with the video game console <NUM>. The video game console <NUM> is communicatively coupled with the video game controller <NUM> (e.g., over a wireless network) and with the display <NUM> (e.g., over a communications bus). A video game player <NUM> operates the video game controller <NUM> to interact with the video game console <NUM>. These interactions may include playing a video game presented on the display <NUM>, interacting with a menu <NUM> presented on the display <NUM>, and interacting with other applications of the video game console <NUM>.

The video game console <NUM> includes a processor and a memory (e.g., a non-transitory computer-readable storage medium) storing computer-readable instructions that can be executed by the processor and that, upon execution by the processor, cause the video game console <NUM> to perform operations relates to various applications. In particular, the computer-readable instructions can correspond to the various applications of the video game console <NUM> including a video game application <NUM>, a music application <NUM>, a video application <NUM>, a social media application <NUM>, a chat application <NUM>, a menu application <NUM>, among other applications of the video game console <NUM> (e.g., a home user interface (UI) application that presents a home page on the display <NUM>).

The video game controller <NUM> is an example of an input device. Other types of the input device are possible including, a keyboard, a touchscreen, a touchpad, a mouse, an optical system, or other user devices suitable for receiving input of a user.

In an example, the menu <NUM> is similar to the menu <NUM> of <FIG>. Upon an execution of the video game application <NUM>, a rendering process of the video game console <NUM> presents video game content (e.g., illustrated as a car race video game content) on the display <NUM>. Upon user input from the video game controller <NUM> (e.g., a user push of a particular key or button), the rendering process also presents the menu <NUM> based on an execution of the menu application <NUM>. The menu <NUM> is presented in a layer over the video game content and includes a dynamic area and a static area. Windows in the dynamic area correspond to a subset of the applications of the video game console.

Upon the presentation of the menu <NUM>, the user control changes from the video game application <NUM> to the menu application <NUM>. Upon a receiving user input from the video game controller <NUM> requesting interactions with the menu <NUM>, the menu application <NUM> supports such interactions by updating the menu <NUM> and launching any relevant application in the background or foreground. The video game player <NUM> can exit the menu <NUM> or automatically dismiss the menu <NUM> upon the launching of an application in the background or foreground. Upon the exiting of the menu <NUM> or the dismissal based on a background application launch, the user control changes from the menu application <NUM> to the video game application <NUM>. If a foreground ground application is launched, the user control changes from the menu application <NUM> to this application instead. In both cases, further user input that is received from the video game controller <NUM> is used for controlling the relevant application and/or for requesting the menu <NUM> again.

Although <FIG> illustrates that the different applications are executed on the video game console <NUM>, the embodiments of the present disclosure are not limited as such. Instead, the applications can be executed on the backend system (e.g., the cloud servers) and/or their execution can be distributed between the video game console <NUM> and the backend system.

<FIG> illustrates an example of a context-based selection of windows, according to an embodiment of the present disclosure. As illustrated, based on timing data <NUM> and a context <NUM>, a menu application <NUM> includes windows <NUM> for a dynamic area of a menu. The menu application <NUM> determines a first order <NUM> for arranging one or more of the windows <NUM> in the dynamic menu associated with active computing services <NUM>. Similarly, the menu application <NUM> determines a second order <NUM> for arranging one or more of the windows <NUM> in the dynamic menu associated with inactive computing services <NUM>. The first order <NUM> may arrange windows <NUM> based on the timing data <NUM> as a measure of potential relevance to the user. Additionally, the menu application <NUM> may use the context <NUM> and the user setting <NUM> to determine an arrangement of windows <NUM> for inclusion in the second order <NUM> such that the second order <NUM> is of relevance to the user.

In an example, the context <NUM> generally includes a context of a user of the computer system (e.g., a video game player) and/or a context of an application being executed on the computer system, as described in more detail, below. The context <NUM> may be received over an application programming interface (API) of a context service, where this context service may collect contexts of the user from different applications of a computer system or a network environment, or from an application (e.g., a video game context can be received from a corresponding video game application). The user setting <NUM> may be received from a user account or from a configuration file.

<FIG> illustrates an example of a window in different states, according to embodiments of the present disclosure. Here and in subsequent figures, an action card is described as an example of a window and corresponds to an application. Generally, a window represents a GUI object that can show content and that can support an action performable on the content and/or window. In an example, the action card is a specific type of the window, where the action card includes a container object for MicroUX services, and where the action card contains content and actions for a singular concept. Action cards included in a menu facilitate immediate and relevant actions based on contexts of what the users are engaged with and the relationships of people, content, and services within a computer environment. Action cards included in the menu may be arranged horizontally and/or vertically in the GUI, and may be interactive. The menu may be dynamic and may include an arrangement of action cards that is responsive to the user interaction with the menu and a context.

As illustrated in <FIG>, the action card can be presented in one of multiple states. Which state is presented depends on the user input, as further described in the next figures. One of the states can be a glanced state <NUM>, where the action card provides a glance to the user about the application. The glance includes relevant information about the action card, where this information should help the user in deciding in taking an action or not. For example, in the glanced state <NUM>, the action card has a first size, and presents content <NUM> and a title <NUM> of the content <NUM> or the action card based on the first size. To illustrate, an action card for a music application can be presented in the first state as a rectangle having particular dimensions, showing a cover and a title of a music album.

Another state can be a focused state <NUM>, where the action provides relevant information to the user and one or more options for one or more actions to be performed (e.g., for one or selectable actions on content of the application or the action card itself). In other words, the action card can surface quick actions for the user to select in response to the user's focus being on the action card. For example, in the focused state <NUM>, the action card has a second size (which can be larger than the first size), resizes the presentation of the content <NUM> and the title <NUM> based on the second size, and presents one or more selectable content actions <NUM> (e.g., play content, skip content, etc.) and one or more selectable card actions (e.g., move the action card to a position on the display, resize the action card, pint the action card, present the action card as a picture-in-picture, etc.). Referring back to the music action card illustration, in the focused state <NUM>, the music cover and album title are enlarged and a play button to play music files of the music album is further presented.

Yet another state can be a selected state <NUM>, where the action continues to provide relevant information to the user in a further enlarged presentation format, and provides one or more options for one or more actions to be performed on the connect and/or the action card itself (e.g., for one or selectable actions on content of the application or the action card itself). In other words, the action card becomes the primary modality for interacting with the MicroUX and displays the relevant visual interface. For example, in the selected state <NUM>, the action card has a third size (which can be larger than the second size), resizes the presentation of the content <NUM> and the title <NUM> based on the third size, continues the presentation of the content action <NUM>, presents additional content <NUM> of the application, and presents one or more options <NUM> for one or more content actions or card actions that can be performed on the action card. Upon a user selection of the option <NUM>, the card actions are presented and can be selected. Referring back to the music action card illustration, in the selected state <NUM>, the music cover and album title are further enlarged and the presentation of the play button continues. Additional music files of the music album are also identified. In the above states, the content <NUM>, title <NUM>, content action <NUM>, and additional content <NUM> can be identified from metadata received from the application.

As illustrated in <FIG>, the action card can include a static presentation and a dynamic presentation area, each of which can be resized depending on the state. For instance, the title <NUM> is presented in the static area, identifies the underlying application associated with the action card and does not change with the state. In comparison, the content <NUM> can be presented in the dynamic area and can change within each state and between the states. In particular, the content itself may be interactive (e.g., a video) and its presentation can by its interactive nature change over time. Additionally or alternatively, the content <NUM> can also be changed over time depending on the user context and/or the application context.

As illustrated in <FIG>, the action card in the glanced state <NUM>, the action card in the focused state <NUM>, and the action card in the selected state <NUM> each include an icon <NUM>. The icon <NUM> may be an image representative of one or more things including, but not limited to, the user (e.g., a profile picture), the computer system (e.g., a system logo or image), a target application (e.g., a badge or icon from the application), and a system icon representing the type of target application (e.g., a general symbol for the type of content being presented, for example, a music note for an audio player, a camera for an image gallery, a microphone for a chat application, etc.).

As illustrated in <FIG>, in an action card in the focused state (e.g., focused state <NUM>) one or more command options <NUM> are included. While <FIG> shows the command options <NUM> in a panel positioned lower than the content, the command options <NUM> could be positioned as an overlay in front of the content, in a side panel, and/or positioned above the content near the title <NUM>. The command options <NUM> may include textual or image-based instructions or may include one or more interactive elements <NUM> such as buttons or other virtual interactive elements. For example, the interactive elements <NUM> may include a button configured to receive a user-click. In some embodiments, the command options <NUM> and the interactive elements <NUM> facilitate interaction with content <NUM> and/or additional content <NUM>. For example, the command options may provide additional and/or alternative function control over content beyond what is provided by content action <NUM>. To illustrate, the content action <NUM> may provide a play/pause function for an audio or video player, while one of the command options <NUM> may include a mute/unmute function for a party chat application. As a further example, the command options <NUM> may be context-specific, based on the current state of the content in the action card. For example, when an action card is playing audiovisual content, the command options <NUM> may include only a mute button, rather than a mute/unmute button, and a stop button, rather than a play button.

In reference to the figures, below, the term action card is used to describe a window in one or more of the presentation states. For example, a window presenting content in the dynamic menu that is associated with an application on the computer system that is different from the menu application is referred to as an "action card. " Further, the action cards are illustrated as being presented sequentially next to each other along a horizontal line. However, the embodiments are not limited as such and can include other arrangements based on different orders of inactive and active service. For instance, the action cards can be presented sequentially along a vertical line.

<FIG> illustrates an example of a computer system <NUM> that presents a dynamic menu <NUM> populated with action cards, according to an embodiment of the present disclosure. As illustrated in <FIG>, the computer system <NUM> includes a menu application <NUM> (e.g., menu application <NUM> of <FIG>), which includes a service determining unit <NUM>, a context determining unit <NUM>, and an order determining unit <NUM>. These are described as sub elements of the menu application <NUM>, but may also be different applications of the computer system <NUM>, providing data to the menu application <NUM> for the menu application <NUM> to perform operations. For example, the menu application <NUM> may determine active computing services <NUM> and inactive computing services <NUM>. Services may refer to functionality available to a user <NUM> and/or the computer system <NUM>, from different applications. For example, a song, playable using a media player application, may be available to the user <NUM> as an inactive computing service <NUM>. In this way, multiple inactive computing services <NUM> may be available from multiple applications 526a-n. As illustrated in <FIG>, the active computing services <NUM> may be provided from the applications 524a-n that are already running the respective active computing services <NUM>. For example, an active computing service <NUM> may be a video game service available from a video game application (e.g., game navigation or mission selection). As another example, a chat application may be running a chat service as an active computing service <NUM>.

As illustrated in <FIG>, the menu application <NUM> determines a first order <NUM> and a second order <NUM> for presenting action cards in a dynamic menu <NUM> via a display <NUM>. As described in more detail in reference to <FIG>, the dynamic menu <NUM> may form a part of a larger menu (e.g., menu <NUM> of <FIG>) overlaid on other content, such as a user application <NUM>, in response to input received by computer system <NUM> from user <NUM>. The first order <NUM> includes one or more action cards 522a-n (also referred to as action cards <NUM> for simplicity), where "a," "b," and "n" represent integer numbers greater than zero and "n" represents the total number of action cards <NUM>. As illustrated, by default an action card 552a of the action cards <NUM> is presented in the focused state, as described in more detail in reference to <FIG>. In the focused state (e.g., focused state <NUM> of <FIG>) the action card 552a includes content <NUM> (e.g., content <NUM> of <FIG>) received by the computer system <NUM> from one or more content sources <NUM> and a content action <NUM> (e.g., content action <NUM> of <FIG>) associated with content <NUM>. Content sources <NUM> may include a content network <NUM>, including, but not limited to, a cloud-based content storage and/or distribution system. The content sources <NUM> may also include system content <NUM> provided by a data store communicatively coupled with the computer system (e.g., a hard drive, flash drive, local memory, external drive, optical drive, etc.). The first order <NUM> may be determined based on at least one timing factor for each active computing service of the active computing services <NUM>. For example, the menu application <NUM> may determine the first order <NUM> based on arranging the action cards <NUM> in order of most recent interaction with the user <NUM> (e.g., last-played). Similarly, the first order <NUM> may be based on how frequently the user <NUM> interacts with applications <NUM> from which active computing services <NUM> are available (e.g., most-played, favorites, etc.). Alternatively, the first order <NUM> may be based on timing of activation of the active computing services <NUM>, for example, which active computing service <NUM> was most recently activated by the user <NUM>. Activating a computing service may include initiating, executing, and/or running an application on the computer system <NUM> based on a request by the user <NUM> and/or by a background process operating on the computer system <NUM>. As such, the first order may arrange the action cards <NUM> according to a "most recently opened" arrangement.

As illustrated in <FIG>, the second order <NUM> describes an arrangement of the action cards 554a-n on the dynamic menu <NUM> presented on the display <NUM>. The action cards 554a-n (also referred to as action cards <NUM> for simplicity) may be presented in the glanced state (e.g., glanced state) by default. In some embodiments, at least one action card of the action cards <NUM> may be presented in the focused state (e.g., focused state) by default. The arrangement of action cards <NUM> in the second order <NUM> may be based on a context, determined by the menu application <NUM> (e.g., using order determining unit <NUM>). The context may be based on a user application <NUM> of the computer system <NUM>, a system application <NUM> of the computer system, and/or the user <NUM>. A context of the user <NUM> (user context) generally includes any of information about the user <NUM>, an account of the user, active background applications and/or services, and/or applications and/or services available to the user <NUM> from the computer system <NUM> or from other network environment (e.g., from a social media platform). A context of the application (user application <NUM> and/or system application <NUM> context) generally includes any information about the application, specific content shown by the application, and/or a specific state of the application. For instance, the context of a video game player (user context) can include video game applications, music streaming applications, video streaming applications, social media feeds that the video game player has subscribed to and similar contexts of friends of the video game player. The context of a video game application includes the game title, the game level, a current game frame, an available level, an available game tournament, an available new version of the video game application, and/or a sequel of the video game application. In some embodiments, context may be determined by the menu application <NUM> from data describing features, aspects, and/or identifiers of the user application <NUM>, the system application <NUM>, and the user <NUM> for which context is being determined. For example, the computer system <NUM> may maintain a profile of the user <NUM> in system content <NUM> that includes data describing biographic information, geographic location, as well as usage patterns. From that profile, the menu application <NUM> may derive one or more elements of user context (e.g., user context <NUM> of <FIG>). To illustrate the example, biographical information of the user <NUM> may indicate that the user <NUM> is a legal minor. This information may be used in determining a user context based upon which the second order <NUM> may exclude any inactive computing services <NUM> restricted to other users over the age of legal majority. In this way, the second order <NUM> is defined for a given context and the order of action cards <NUM> is also pre-defined based on the context. For other user, system application, or user application contexts, however, the second order <NUM> may differ. Furthermore, the second order <NUM> may include action cards <NUM> for inactive computing services <NUM> from multiple application types, for which the second order <NUM> indicates an arrangement of the action cards <NUM> according to application type. For example, second order <NUM> may include multiple action cards <NUM> for media-player services, two for video game services, and one for a party-chat service. The second order may, in some embodiments, determine the second order <NUM> such that the media player action cards are grouped together and the video game action cards are grouped together.

In some embodiments, the dynamic menu may present windows that include active windows and suggested windows. Such windows can be presented dependently or independently of presentation orders related to recency and contexts. An active window corresponds to an active computing service. A suggested window corresponds to an inactive computing service, where the inactive computing service has not been previously used by a user of the computer system, such as one that have not been previously accessed, activated, inactivated, closed, removed, deleted, and/or requested by the user. Such an inactive computing service is referred to herein as a new inactive computing service. For instance, a new inactive computing service of a video game application may include a newly unlocked level in the video game application or a new downloadable level content (DLC) available from a content server. In an example, the menu application may determine a number of active windows corresponding to active computing services and a number of suggested windows corresponding to new inactive computing services for presentation within the dynamic window. In determining that a suggested window is to be presented within the dynamic menu, new inactive services may additionally and/or alternatively be ranked or otherwise compared based on relevance to the user and/or a computing service(s) (whether active or inactive). In some cases, relevance may be determined based on a context of the user or the computing service(s). As described above, context includes system context, application context, and/or user context. For example, a newly unlocked video game level may be included in the dynamic menu as a suggested window based on the relevance to an active video game application, determined by user profile information indicating that the user typically launches unlocked video game levels.

As illustrated in <FIG>, the first order <NUM> and the second order <NUM> indicate a horizontal arrangement of the action cards <NUM> and the action cards <NUM> in the dynamic menu <NUM>. For example, the action cards <NUM> may be arranged in the dynamic menu <NUM> to the left of the action cards <NUM> in a linear horizontal arrangement. In this example, the action cards may be arranged in the dynamic menu <NUM> such that the right-most action card will be the action card 552n, which is positioned adjacent and to the left of the action card 554a, forming a linear arrangement of action cards making up the first order <NUM> and the second order <NUM> in the dynamic menu <NUM>. In some embodiments, the arrangement of action cards according in the dynamic menu may differ from the linear and horizontal arrangement illustrated in <FIG>. For example, the arrangement may be circular, vertical, curved, etc. In some embodiments, the dynamic menu may switch between first and action cards by exchanging positions on the display, putting the action cards <NUM> in, for example, the left-most position in the arrangement.

<FIG> illustrates an example of a display that presents a dynamic menu including interactive action cards, according to an embodiment of the present disclosure. As illustrated in <FIG>, a first order <NUM> and a second order <NUM> defines the arrangement of action cards in a dynamic menu <NUM> presented via a display <NUM>. Multiple action cards 652a-n are arranged horizontally according to the first order <NUM>, further organized in sets of action cards. For example, <FIG> includes a first set <NUM>, a second set <NUM>, and a third set <NUM>. The sets may divide the action cards <NUM> by application type, for example, video game, social media application, web browser, etc. As an example, the action cards <NUM> arranged in the first set <NUM> may all present content of video games, while the action cards <NUM> arranged in the second set <NUM> may all present content of social media applications. Furthermore, the first order <NUM> may define a limit on a number of the action cards <NUM> in each set. For example, the first set <NUM> may be limited to three action cards <NUM>, while the second set <NUM> may be limited to only two action cards <NUM>, as illustrated in <FIG>. The first order <NUM> may define more than three sets, and the number of sets and the maximum number of action cards for each set may be pre-defined and/or dynamic, to reflect context and usage of the computer system (e.g., computer system <NUM> of <FIG>). When the number of possible action cards exceeds a predefined limit, particular action cards may be selected to meet this limit. Various selection techniques are possible. In one example technique, the selection is random. In another technique, the selection is based on a relevance to a user or an application. For instance, a user context and/or an application context can be used to rank the possible action cards and the highest ranked action cards are selected to meet the predefined limit.

<FIG> further illustrates a second order <NUM> defining multiple subsets. For example, a first subset <NUM>, a second subset <NUM>, and a third subset <NUM> divide the action cards <NUM> making up the second order <NUM>. In some embodiments, the second order <NUM> may include additional or fewer subsets. The second order <NUM> may define subsets based on relevance to the first order <NUM>. For example, the first subset <NUM> may include action cards <NUM> presenting content for inactive services of active applications (e.g., applications for which an active service is presented in an action card <NUM>). In another example, the second subset <NUM> may include action cards <NUM> presenting content for inactive services for applications from the same application type as those presented in the first subset <NUM>. In another example, the third subset <NUM> may include second action cards <NUM> presenting content for inactive services of a different application type from those presented in the first subset <NUM> and/or the second subset <NUM>. As with the first order <NUM> sets, each subset of the second order <NUM> may include action cards <NUM> of a single application type, and the second order <NUM> may define a maximum number of action cards <NUM> of each application type to be included in the second order <NUM>. For example, as illustrated in <FIG>, the first subset <NUM> includes three action cards <NUM>, while the second subset <NUM> includes two action cards <NUM>. As with the first order <NUM>, the second order may be pre-defined and/or dynamic, changing relative to the context.

<FIG> illustrates an example of a display presenting a dynamic menu <NUM> in response to user interaction, according to an embodiment of the present disclosure. As illustrated in <FIG>, the dynamic menu <NUM>, presented via display <NUM>, includes a horizontal arrangement of multiple action cards 752a-n from active computing services and multiple action cards 754a-n from inactive computing services. By default, the dynamic menu <NUM> presents only action card 752a in the focused state <NUM>, and all other action cards in the glanced state <NUM>. In response to a user interaction <NUM> (e.g., by a user input via input device <NUM> of <FIG>), the action card states may be adjusted in the dynamic menu <NUM> to shift the action card 752a from the focused state <NUM> to the glanced state <NUM>, while adjusting the action card 754a from the glanced state <NUM> to the focused state <NUM>. In this way, the dynamic menu <NUM> facilitates interactions with the content present in the action cards, and provides a user (e.g., user <NUM> of <FIG>) with access to applications and content.

<FIG> illustrates another example of an action card in a dynamic menu <NUM>, according to an embodiment of the present disclosure. As illustrated in <FIG>, by default, the dynamic menu <NUM> presented via a display <NUM> includes multiple actions cards in a glanced state <NUM> and only one action card 852a in a focused state <NUM>, as described in more detail in reference to <FIG>. In response to a user interaction <NUM>, for example via a user input device (e.g., user input device <NUM> of <FIG>), to select the action card 852a in the focused state <NUM>, the computer system (e.g., computer system <NUM> of <FIG>) may generate and/or present via display <NUM> an action card <NUM> in the selected state <NUM> (e.g., selected state <NUM> of <FIG>). As illustrated in <FIG>, the selected state includes a selectable action <NUM> that permits a user to control dynamic content presented in the selected state <NUM>, as described in more detail in reference to <FIG>.

<FIG> illustrates an example of interaction with a dynamic menu <NUM>, according to an embodiment of the present disclosure. As illustrated in <FIG>, the dynamic menu <NUM> presented via a display <NUM> may be entered and exited through user interaction using an input device (e.g., input device <NUM> of <FIG>). When the dynamic menu <NUM> is active, at least one action card is in the focused state. As illustrated in <FIG>, action card 952a is in the focused state, while all remaining action cards are in the glanced state. In response to a user interaction <NUM>, for example, a user request to exit, hide, minimize, or collapse the dynamic menu <NUM>, the computer system (e.g., computer system <NUM> of <FIG>) may adjust the action card 952a from the focused state to the glanced state via the action of a menu application (e.g., menu application <NUM> of <FIG>). Similarly, in response to a user interaction <NUM> to enter, show, maximize, or erect the dynamic menu <NUM>, the computer system, via the menu application, return the same action card 952a to the focused state from the glanced state. In some embodiments, the user interaction <NUM> and the user interaction <NUM> are the same action on the input device (e.g., press a single button successively to both hide and show the dynamic menu <NUM>). Alternatively, the user interaction <NUM> and the user interaction <NUM> may be different actions, and reentering the dynamic menu <NUM> may not return action card 952a to the focused state, depending on a change in context between exiting and reentering the dynamic menu <NUM>. For example, if the user exited the dynamic menu <NUM> to make some changes to active applications and/or processes via a different avenue of user interaction (e.g., static menu area <NUM> of <FIG>), the ordering of action cards in the dynamic menu <NUM> may change, such that the action card <NUM> in the focused state may be different upon reentry, as described in more detail in reference to <FIG>, below.

<FIG> illustrates an example of a computer system <NUM> that adjusts a dynamic menu <NUM> in response to activation of an application 1026a, according to an embodiment of the present disclosure. As illustrated in <FIG>, while the dynamic menu <NUM> is being presented via a display <NUM>, multiple applications <NUM> on the computer system may be running active computing services <NUM>, while other applications <NUM> may be inactive. For example, a video game may be running, along with a party chat application, a web browser application, and a live-stream video application. As illustrated in <FIG>, the application 1026a initializes while the dynamic menu <NUM> is presented. In response, a menu application <NUM> running on the computer system <NUM> determines when the application 1026a activates, and generates and/or presents an additional action card <NUM> as part of a first order <NUM> in the dynamic menu <NUM>. As such, the additional action card <NUM> appears in the dynamic menu <NUM> in a horizontal arrangement of action cards <NUM> as described in more detail in reference to <FIG>. While <FIG> shows the additional action card <NUM> in the left most position, it may appear in another position in the first order <NUM>. The process of adding the additional action card <NUM> to the dynamic menu may occur in real time and without any user interaction as a default process of the menu application <NUM>. Alternatively, the menu application may generate and/or present a notification of a new active computing service <NUM> corresponding to the application 1026a, for which the user (e.g., user <NUM> of <FIG>) may select to add the additional action card <NUM> to the dynamic menu <NUM>. In some embodiments, the additional action card <NUM> may be presented in the focused state initially. Alternatively, the additional action card <NUM> may be presented in the glanced state initially, as illustrated in <FIG>.

<FIG> illustrates an example of a dynamic menu <NUM> adjusting in response to a deactivated application 1124n, according to an embodiment of the present disclosure. As illustrated in <FIG>, an active application <NUM> running on a computer system <NUM> deactivates, as determined by a menu application <NUM> running on the computer system <NUM>, while the computer system <NUM> is presenting the dynamic menu <NUM> via a display <NUM>. The deactivated application 1124n is different from the menu application <NUM>. As illustrated in <FIG>, the dynamic menu presents action cards <NUM> for each active application <NUM>, and actions cards <NUM> for inactive applications <NUM>, as described in more detail in reference to <FIG>. As described in more detail in reference to <FIG>, at least one action card is presented in the focused state, while the remaining action cards are shown in the glanced state. As illustrated in <FIG>, an action card 1152a is in the focused state, while a different action card <NUM> is associated with the deactivated application 1124n. Unlike what was described in reference to <FIG>, the menu application <NUM> does not reorganize and/or adjust the dynamic menu <NUM> after determining that the deactivated application 1124n is no longer active. Instead, the menu application <NUM> continues to present the different action card <NUM> in the dynamic menu <NUM>, until the computer system receives user input <NUM>, including, but not limited to, a user request to remove the dynamic menu from the display. For example, as described in more detail in reference to <FIG>, the dynamic menu <NUM> may be included in a user interface (e.g., user interface <NUM> of <FIG>) presented on the display <NUM>. In this way, as described in <FIG>, the user interaction <NUM> may prompt the menu application <NUM> to remove or minimize the dynamic menu <NUM>. Upon receiving a second user interaction <NUM>, for example, by repeating the same command to reverse the change, menu application <NUM> repopulates the dynamic menu <NUM> without the different action card <NUM> and with the same action card 1152a in the focused state.

<FIG> illustrates an example of a menu application <NUM> determining an inactive application <NUM> and adding a corresponding action card <NUM> to a dynamic menu <NUM>, according to an embodiment of the present disclosure. As illustrated in <FIG>, a computer system <NUM> runs a menu application <NUM> that has determined one or more applications 1226a-n are inactive, and has generated and/or presented action cards 1254a-n corresponding to the one or more applications <NUM> in the dynamic menu <NUM> via a display <NUM>. The action cards <NUM> are presented according to a second order (e.g., second order <NUM> of <FIG>), as described in more detail in reference to <FIG>. The inactive application <NUM> may have become inactive while the dynamic menu was presented, as described in more detail in reference to <FIG>. While the dynamic menu <NUM> is presented, the menu application <NUM> does not adjust the dynamic menu <NUM>, nor does it populate additional action cards for inactive computing services <NUM> for which action cards are not already presented, until the computer system <NUM> receives user input <NUM> requesting to remove the dynamic menu <NUM> from the display <NUM>. When the computer system <NUM> receives a second user input <NUM> prompting the menu application <NUM> to generate and/or present the dynamic menu <NUM>, the menu application <NUM> populates the dynamic menu <NUM> including the corresponding action card <NUM> for the inactive application <NUM>.

<FIG> illustrates an example of a computer system <NUM> for presentation of content in an interactive menu and an action card, according to an embodiment of the present disclosure. As described in more detail in reference to <FIG>, the computer system <NUM> may be a videogame system, a backend system, or any other system configured to store and present content on a display. As illustrated, the computer system <NUM> includes multiple target applications 1302a-n (hereinafter also referred to as target application <NUM>, target applications <NUM>, target app <NUM>, or target apps <NUM>, for simplicity), where "a," "b," and "n" are positive integers and "n" refers to the total number of target applications. As illustrated, the computer system <NUM> further includes a menu application <NUM>, a cache <NUM>, and an action card application <NUM>. Each of the target apps <NUM> may correspond to a different application running on the computer system (e.g., video game console <NUM> of <FIG>) or on a backend system, as described in more detail in reference to <FIG>. The target application <NUM> may be a system application or a user application, and is different from the menu application <NUM>. Generally, a system application is an application that does not interact with a user of the computer system <NUM>, while a user application is an application configured to interact with a user of the computer system <NUM>.

The cache <NUM> may include a local memory on the computer system (e.g., a hard disk, flash drive, RAM, etc.) configured for rapid storage and retrieval of data to minimize latency. As illustrated, the menu application <NUM> includes a determining unit <NUM>, one or more data templates <NUM>, and a computing service <NUM>. The determining unit <NUM> may be implemented as software and/or hardware, such that the menu application <NUM> may determine a data template <NUM> that is defined for a specific target application <NUM>. The data templates <NUM>, at least in part, identify the types of content for the computer system <NUM> to store in the cache <NUM> for the target application <NUM> based on the association of a data template <NUM> with a target application <NUM>. In some cases, each data template <NUM> further associates a type of content (e.g., audio, video, video game content, etc.) with one or more presentation states.

The menu application may store data <NUM> in the cache <NUM>, where the data <NUM> may include multiple types of content including, but not limited to, first content <NUM> and second content <NUM>. For example, as described in more detail in reference to <FIG>, the content may include video content, audio content, video game content, party chat information, etc. The data <NUM> may also include a first uniform resource identifier (URI) of the first content <NUM>, where a URI typically is characterized by a string of characters identifying a resource following a predefined set of syntactical rules. For example, a URI may identify a resource to facilitate interaction involving that resource between networked systems. Similarly, the data <NUM> may include URI information for each type content, for example, a second URI of the second content <NUM>. The first content <NUM> and the second content <NUM> may be identified in one or more data templates <NUM> and associated in the data templates <NUM> with a glanced state, a focused state, and/or a selected state, as described in more detail in reference to <FIG>. For example, the first content <NUM> may be associated with a glanced state and with a focused state, and the second content <NUM> may be associated only with the focused state, as defined in a given data template <NUM>. In this way, the cache <NUM> may store multiple types of content associated with multiple data templates <NUM>, making up data for different target applications <NUM>.

As illustrated, the computer system <NUM> is communicatively coupled with one or more content sources <NUM> from which the computer system may fetch and/or receive data <NUM>. For example, the content sources <NUM> may include a content network <NUM>, including, but not limited to, a cloud-based content storage and/or distribution system. The content sources <NUM> may also include system content <NUM> provided by a data store communicatively coupled with the computer system (e.g., a hard drive, flash drive, local memory, external drive, optical drive, etc.).

As illustrated, the computer system <NUM> is communicatively coupled to an input device <NUM>, which may include, but is not limited to a user input device as described in more detail in reference to <FIG> (e.g. video game controller <NUM> of <FIG>). The input device <NUM> may provide user input to the computer system <NUM> to facilitate user interaction with data <NUM> stored in the cache <NUM>. As described in more detail below, the interaction may take place via one or more menus and/or windows in a UI. For example, the computer system <NUM> may generate user interface data to configure a user interface including a static menu and a dynamic menu, as described in more detail in reference to <FIG> (e.g., static menu area <NUM> and dynamic menu area <NUM> of menu <NUM> of <FIG>).

As illustrated, the computer system <NUM> is communicatively coupled with display450. Display <NUM> may include any general form of display compatible with interactive user interfaces (e.g., display <NUM> of <FIG>). Display <NUM> may include an augmented reality and/or virtual reality interface produced by a wearable and/or portable display system, including but not limited to a headset, mobile device, smartphone, etc. In response to input provided by the input device <NUM>, received as user input by the computer system <NUM>, the computer system <NUM> may present a dynamic menu <NUM> via display <NUM> (e.g., dynamic menu area <NUM> of <FIG>). As described in more detail in reference to <FIG>, the display <NUM> may present a static menu and the dynamic menu <NUM>, where the dynamic menu <NUM> includes one or more action cards <NUM>. As illustrated, the action cards <NUM> are presented in the glanced state, and each may correspond to different target applications <NUM>, and each may be populated with different data <NUM> according to a different data template <NUM> associated with the different target applications <NUM>. For example, the action cards <NUM> may include an action card <NUM> that corresponds to a first target application <NUM>, such that the action card <NUM> presents first content <NUM> based on data from the cache <NUM> and according to a data template <NUM> defined for the first target application <NUM>. As described in more detail in reference to <FIG>, user interaction with the computer system <NUM> via the dynamic menu <NUM> may switch one or more of the action cards <NUM> from the focused state to the glanced state, and vice versa. As illustrated in <FIG>, action card 1354b is in the focused state, but interaction with the dynamic menu <NUM> permits a user (e.g., user <NUM> of <FIG>) to switch the focused state presentation, for example, from the action card 1354b to the action card 1354a.

As described in more detail in reference to <FIG>, the computer system <NUM> may receive one or more types of user interaction via the input device <NUM> taking the form of a request for the selected state associated with the target application of the action card <NUM>, as described in more detail in reference to <FIG>. This may include a user button press on the action card <NUM> and/or another form of user interaction via the input device <NUM> that constitutes a command option (e.g., command option <NUM> of <FIG>). The computer system <NUM> may respond to the user input by generating a copy of the data associated with the first target application <NUM> from the cache and sending the copy of the data associated with the first target application <NUM> to the action card application <NUM>. As illustrated, the action card application <NUM> is different from the menu application and the first target application <NUM>. The action card application <NUM> may be configured to generate user interface data, such that a user interface generated using the user interface data may present, via display <NUM>, an action card <NUM> that corresponds to the first target application <NUM> presented in the selected state. The action card <NUM>, in the selected state, may include both first content <NUM> and second content <NUM> presented based on the data template <NUM> associated with the target application <NUM>. The first content <NUM> and the second content <NUM> may be populated in the action card <NUM> by the action card application <NUM> using the copied data sent to the action card application <NUM> by the menu application <NUM>, in response to user input received by the computer system <NUM> via the input device <NUM>.

<FIG> illustrates an example flow for presenting content in an interactive menu, according to embodiments of the present disclosure. The operations of the flow can be implemented as hardware circuitry and/or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as a video game system. As implemented, the instructions represent modules that include circuitry or code executable by a processor(s) of the computer system. The execution of such instructions configures the computer system to perform the specific operations described herein. Each circuitry or code in combination with the processor represents a means for performing a respective operation(s). While the operations are illustrated in a particular order, it should be understood that no particular order is necessary and that one or more operations may be omitted, skipped, and/or reordered.

In an example, the flow includes an operation <NUM>, where the computer system determines active applications and inactive applications. As described in more detail in reference to <FIG>, applications on a computer system (e.g., computer system <NUM> of <FIG>) may be active or inactive, and the computer system may run a menu application (e.g., menu application <NUM> of <FIG>) to determine which applications are active and inactive.

In an example, the flow includes operation <NUM>, where the computer system determines a first order of presentation of action cards corresponding to the active applications (e.g., active computing services <NUM> of <FIG>). As described in more detail in reference to <FIG>, the menu application determines a first order (e.g., first order <NUM> of <FIG>) describing the number, order, and arrangement of action cards (e.g., action cards <NUM> of <FIG>) to present in a dynamic menu (e.g., dynamic menu <NUM> of <FIG>). The action cards may be associated with the active applications and each may be associated with a different application. As described in more detail in reference to <FIG>, the first order may be divided into sets, and the action cards may be arranged in order of most recent interaction and/or most frequent interaction. As described in more detail in reference to <FIG>, the sets may include only action cards for a single application type, and may be limited in the number of action cards in each set, depending on the application type.

In an example, the flow includes operation <NUM>, where the computer system determines a context of at least one of a user application, a system application, or a user. As described in more detail in reference to <FIG>, context includes a system application context, a user application context and/or a user context. User context generally includes any of information about the user, an account of the user, active background applications and/or services, and/or applications and/or services available to the user from the computer system or from other network environment (e.g., from a social media platform). User application and/or system application context generally includes any information about the application, specific content shown by the application, and/or a specific state of the application. For instance, the context of a video game player (user context) can include video game applications, music streaming applications, video streaming applications, social media feeds that the video game player has subscribed to and similar contexts of friends of the video game player. The context of a video game application includes the game title, the game level, a current game frame, an available level, an available game tournament, an available new version of the video game application, and/or a sequel of the video game application.

In an example, the flow includes operation <NUM>, where the computer system determines a second order of presentation of action cards corresponding to the inactive computing services. As described in more detail in reference to <FIG>, the second order (e.g., second order <NUM> of <FIG>) may include multiple action cards (e.g., action cards <NUM> of <FIG>) arranged horizontally by relevance to the action cards included in the first order. For example, relevance may be determined by dividing the second order into multiple subsets (e.g., subset <NUM> of <FIG>) corresponding, for example, to action cards presenting content for inactive services of active applications (e.g., applications for which an active service is presented in an action card). Alternatively, a subset may be presented including action cards presenting content for inactive services for applications from the same application type as those in the first order. Alternatively, a subset may be presented including action cards presenting content for inactive services of a different application type from those presented in the first order.

In an example, the flow includes operation <NUM>, where the computer system presents, in a dynamic menu, the action cards according to the first order and the action cards according to the second order, with only one of the action cards in a focused state and the remaining action cards in a glanced state. As described in more detail in reference to <FIG>, the menu application (e.g., menu application <NUM> of <FIG>) may generate and/or present by default a dynamic menu (e.g., dynamic menu <NUM> of <FIG>) with a single action card (e.g., action card 554a of <FIG>) in the focused state, with the remaining action cards in the glanced state. In some embodiments, multiple action cards may be presented in the focused state. As described in more detail in reference to <FIG>, the focused state may be shifted from one action card to another by user interaction with the computer system. As described in more detail in reference to <FIG>, an action card may be expanded into the selected state by a different user interaction and/or by repeating the same interaction with the computer system. As described in more detail in reference to <FIG>, navigating away from the dynamic menu within a user interface may switch all action cards to the glanced state, whereupon the action card having been in the focused state is returned to the focused state when the user returns to the dynamic menu. As described in more detail in reference to <FIG> the menu application (e.g., menu application <NUM> of <FIG>) may add additional action cards (e.g., additional action card <NUM> of <FIG>) to the first order (e.g., first order <NUM> of <FIG>) when an application activates (e.g., application 1026a of <FIG>). As described in more detail in reference to <FIG>, the menu application may determine that an application has deactivated (e.g., application 1124n of <FIG>), and may continue to present the corresponding action card (e.g., action card <NUM> of <FIG>) in the dynamic menu until the user interacts with the computer system to remove the dynamic menu from the user interface and/or display. For example, the user may interact with the static menu (e.g., static menu area <NUM> of <FIG>) to close the dynamic menu. Upon reopening the dynamic menu, the menu application may remove the action card associated with the deactivated application from the dynamic menu. As described in more detail in reference to <FIG>, the dynamic menu similarly may add an action card (e.g., action card <NUM> of <FIG>) to the second order only upon reopening the dynamic menu after navigating away and/or closing the dynamic menu by the user.

<FIG> illustrates an example of launching an application module and terminating a menu application, according to embodiments of the present disclosure. In particular, the menu application is used to present a menu that includes a plurality of windows. As illustrated, a menu application <NUM> supports the presentation of a window <NUM> in a glanced state <NUM>, a focused state <NUM>, and a selected state <NUM> depending on user input from an input device as explained herein above. The window <NUM> corresponds to an application (referred to herein as an "underlying application" in the interest of clarity). Metadata of the underlying application may be received by the menu application to populate, by the menu application <NUM>, the content and selectable actions on the content in the window <NUM> as relevant to each state (the content and selectable actions are shown as "action card component <NUM>").

In an example, when the window <NUM> is added (along with other windows corresponding to different underlying applications) to the menu, the menu application <NUM> also instantiates an application module <NUM>. The application module <NUM> can be a logical container for coordinated objects related to a task (e.g., to present an interfacing window) with optional programming window. The application module <NUM> can have parameters common to the different underlying applications (e.g., common objects), whereby it represents a shell from which any of these applications can be quickly launched. When the window <NUM> is in the glanced state <NUM> or the focused state <NUM>, the menu application <NUM> does not pass content or application-related information to the application module <NUM> (this is illustrated in <FIG> with blank area of the application module <NUM>).

When the window <NUM> starts transitioning from the focused state <NUM> to the selected state <NUM> in response to a user selection of the window <NUM>, the size, content, and selectable actions of the window <NUM> start changing. The menu application passes information about this change along with parameters specific of the underlying application (that corresponds to the window <NUM>) to the application module <NUM> (e.g., state information, programming logic, etc.). Accordingly, the application module <NUM> would have the same action card component <NUM> as the action card component <NUM> presented in the window <NUM> during the transition to and in the selected state <NUM>. In addition, the application module <NUM> corresponds to an instantiation of the underlying application given the specific parameters of this application.

During the transition and in the selected state <NUM>, the application module <NUM> supports an overlay window <NUM> that has the same size and includes the same content and actions as the window <NUM>. A rendering process presents the overlay window <NUM> over the window <NUM>, such that both windows completely overlap during the transition and in the selected state <NUM>. Hence, from a user perspective, the user would only perceive one window (e.g., the overlay window <NUM>), while in fact two windows are presented on top of each other.

Upon the end of the transition or upon user input requesting action, the window <NUM> may be dismissed (e.g., closed) and the overlay window <NUM> may be used instead. From that point, the overlay window <NUM> becomes the interface to the underlying application and the menu application <NUM> can be terminated (or run in the background).

<FIG> illustrates an example flow for launching an application module and terminating a menu application, according to embodiments of the present disclosure. The operations of the flow can be implemented as hardware circuitry and/or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as a video game system. As implemented, the instructions represent modules that include circuitry or code executable by a processor(s) of the computer system. The execution of such instructions configures the computer system to perform the specific operations described herein. Each circuitry or code in combination with the processor represents a means for performing a respective operation(s). While the operations are illustrated in a particular order, it should be understood that no particular order is necessary and that one or more operations may be omitted, skipped, and/or reordered. The example flow in <FIG> can be performed in conjunction with or separately from the example flow in <FIG>.

In an example, the flow includes an operation <NUM>, where the computer system presents video content of a video game application (e.g., first content of a first application) on a display. The video game application can be executed on the computer system and the video game content can be presented based on the game play of a user of the computer system (e.g., a video game player).

In an example, the flow includes an operation <NUM>, where the computer system receives user input requesting a menu. For instance, the user input is received from an input device (e.g., a video game controller) and corresponds to a user push of a key or button on the input device (e.g., a particular video game controller button) or any other type of input (e.g., a mouse click). An event may be generated from the user input indicating a command. The command can be for the presentation of the menu. Otherwise, the command can be for other controls (e.g., the display of a home user interface, an exit from the video game application, etc.) depending on the type of the user input.

In an example, the flow includes an operation <NUM>, where the computer system presents the menu, where this menu includes a plurality of windows (e.g., action cards) displayed in a dynamic area of the menu and a plurality of icons displayed in a static area of the menu. For instance, the menu is presented in response to the command for the presentation of the menu. In addition, a user context and an application context can be determined and used to select particular application or remote computing services that are likely of interest to the user. Each window within the dynamic menu area corresponds to one of these applications. The windows can also be presented in a glanced state. In one illustration, the window of likely most interest to the user given the user context and application context can be shown in another state (e.g., the focused state). In another illustration, if one of the windows was selected or was in a focused state upon the most previous dismissal of the menu, that window can be presented in the focused state.

In an example, the flow includes an operation <NUM>, where the computer system instantiates an application module. The application module can have parameters common to the different applications that correspond to the windows of the menu.

In an example, the flow includes an operation <NUM>, where the computer system receives a user scroll through the windows within the dynamic menu area (or any other types of interactions within the dynamic menu area indicating a focus of the user). The user scroll can be received based on user input from the input device and a relevant event can be generated based on this input.

In an example, the flow includes an operation <NUM>, where the computer system presents a window (e.g., an application window corresponding to one of the applications where the user focus is currently on) in the other state (e.g. the focused state). For instance, if the user scroll is over the window, that window is presented in the focused state, while the presentation of the remaining windows is in the glanced state.

In an example, the flow includes an operation <NUM>, where the computer system receives a user selection of the window. The user selection can be received based on user input from the input device and while the window is presented in the focused state. A relevant event can be generated based on this input.

In an example, the flow includes an operation <NUM>, where the computer system presents the window in a different state (e.g. a selected state). For instance, the window's size is changed from the focused state to the selected state, while the presentation of the remaining windows remains in the glanced state.

In an example, the flow includes an operation <NUM>, where the computer system updates the application module to include parameters specific to the corresponding application of the selected window and to present an overlay window. For instance, the size, content, and actions of the window and the state information and programming logic of the application are passed to the application window, thereby launching an instance of the application from the application module, where this instance can use the information about the size, content, and actions of the window for the presentation of the overlay window.

In an example, the flow includes an operation <NUM>, where the computer system presents the overlay window. For instance, as the window transitions from the focused state to the selected state or once in the selected state, a rendering process also presents the overlay window over the window.

In an example, the flow includes an operation <NUM>, where the computer system dismisses the presentation of the window. For instance, upon the presentation of the overlay window or upon the transition to the selected state, the window is closed. In addition, the menu application can be termination or can be moved to the background.

In an example, the flow includes an operation where the computer system presents an option to perform an action (e.g., a selectable action) on the overlay window (e.g., to pin to side or to show as a picture in picture). For instance, the option is presented as an icon within the overlay window upon the transition to the selected state.

In an example, the flow includes an operation where the computer system receives a user selection of the option. The user selection can be received based on user input from the input device and a relevant event can be generated based on this input.

In an example, the flow includes an operation where the computer system performs the action. For instance, a pin-to-side operation or a picture-in-picture operation are performed on the overlay window, resulting in a pinned window or a picture-in-picture window.

In an example, the flow includes an operation where the computer system changes user control from the menu to the video game content. For instance, the presentation of the menu is dismissed, while the presentation of the content continues in the pinned window or the picture-in-picture window. User input received subsequently can be used to control the video game application or to request the menu again. In an illustration, a subset of the buttons, keys, or gestures on the input device are mapped to and usable for controlling the video game application, while another subset of the buttons, keys, or gestures are mapped to and usable for controlling the pinned window or picture-in-picture window. In this way, the user can have simultaneous control over both the video game application and the other application (that interfaces with the user through the pinned window or picture-in-picture window) depending on the buttons on the input device.

<FIG> illustrates an example of a hardware system suitable for implementing a computer system, according to embodiments of the present disclosure. The computer system <NUM> represents, for example, a video game system, a backend set of servers, or other types of a computer system. The computer system <NUM> includes a central processing unit (CPU) <NUM> for running software applications and optionally an operating system. The CPU <NUM> may be made up of one or more homogeneous or heterogeneous processing cores. Memory <NUM> stores applications and data for use by the CPU <NUM>. Storage <NUM> provides non-volatile storage and other computer readable media for applications and data and may include fixed disk drives, removable disk drives, flash memory devices, and CD-ROM, DVD-ROM, Bluray, HD-DVD, or other optical storage devices, as well as signal transmission and storage media. User input devices <NUM> communicate user inputs from one or more users to the computer system <NUM>, examples of which may include keyboards, mice, joysticks, touch pads, touch screens, still or video cameras, and/or microphones. Network interface <NUM> allows the computer system <NUM> to communicate with other computer systems via an electronic communications network, and may include wired or wireless communication over local area networks and wide area networks such as the Internet. An audio processor <NUM> is adapted to generate analog or digital audio output from instructions and/or data provided by the CPU <NUM>, memory <NUM>, and/or storage <NUM>. The components of computer system <NUM>, including the CPU <NUM>, memory <NUM>, data storage <NUM>, user input devices <NUM>, network interface <NUM>, and audio processor <NUM> are connected via one or more data buses <NUM>.

A graphics subsystem <NUM> is further connected with the data bus <NUM> and the components of the computer system <NUM>. The graphics subsystem <NUM> includes a graphics processing unit (GPU) <NUM> and graphics memory <NUM>. The graphics memory <NUM> includes a display memory (e.g., a frame buffer) used for storing pixel data for each pixel of an output image. The graphics memory <NUM> can be integrated in the same device as the GPU <NUM>, connected as a separate device with the GPU <NUM>, and/or implemented within the memory <NUM>. Pixel data can be provided to the graphics memory <NUM> directly from the CPU <NUM>. Alternatively, the CPU <NUM> provides the GPU <NUM> with data and/or instructions defining the desired output images, from which the GPU <NUM> generates the pixel data of one or more output images. The data and/or instructions defining the desired output images can be stored in the memory <NUM> and/or graphics memory <NUM>. In an embodiment, the GPU <NUM> includes 3D rendering capabilities for generating pixel data for output images from instructions and data defining the geometry, lighting, shading, texturing, motion, and/or camera parameters for a scene. The GPU <NUM> can further include one or more programmable execution units capable of executing shader programs.

The graphics subsystem <NUM> periodically outputs pixel data for an image from the graphics memory <NUM> to be displayed on the display device <NUM>. The display device <NUM> can be any device capable of displaying visual information in response to a signal from the computer system <NUM>, including CRT, LCD, plasma, and OLED displays. The computer system <NUM> can provide the display device <NUM> with an analog or digital signal.

In accordance with various embodiments, the CPU <NUM> is one or more generalpurpose microprocessors having one or more processing cores. Further embodiments can be implemented using one or more CPUs <NUM> with microprocessor architectures specifically adapted for highly parallel and computationally intensive applications, such as media and interactive entertainment applications.

The components of a system may be connected via a network, which may be any combination of the following: the Internet, an IP network, an intranet, a wide-area network ("WAN"), a local-area network ("LAN"), a virtual private network ("VPN"), the Public Switched Telephone Network ("PSTN"), or any other type of network supporting data communication between devices described herein, in different embodiments. A network may include both wired and wireless connections, including optical links. Many other examples are possible and apparent to those skilled in the art in light of this disclosure. In the discussion herein, a network may or may not be noted specifically.

In the foregoing specification, the invention is described with reference to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. Various features and aspects of the above-described invention may be used individually or jointly. Further, the invention can be utilized in any number of environments and applications beyond those described herein without departing from the scope of the appended claims. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive.

It should be noted that the methods, systems, and devices discussed above are intended merely to be examples. It must be stressed that various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, it should be appreciated that, in alternative embodiments, the methods may be performed in an order different from that described, and that various steps may be added, omitted, or combined. Also, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. Also, it should be emphasized that technology evolves and, thus, many of the elements are examples and should not be interpreted to limit the scope of the invention.

Specific details are given in the description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the embodiments.

Also, it is noted that the embodiments may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure.

Moreover, as disclosed herein, the term "memory" or "memory unit" may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices, or other computer-readable mediums for storing information. The term "computer-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, a sim card, other smart cards, and various other mediums capable of storing, containing, or carrying instructions or data.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a computer-readable medium such as a storage medium. Processors may perform the necessary tasks.

Claim 1:
A method for presenting a dynamic menu for different applications of a computer system (<NUM>), the method implemented by the computer system, the method comprising:
determining (<NUM>), by a menu application, active computing services and inactive computing services available from the different applications, wherein the inactive computing services include one or more functionalities available from an application with an active computing service;
determining (<NUM>), by the menu application, a first order of presentation of first windows within the dynamic menu, each of the first windows corresponding to one of the active computing services, the first order indicating an arrangement of the first windows based on at least one of: (i) timing of activating the active computing services, or (ii) timing of interacting with the active computing services;
determining (<NUM>), by the menu application, a context of at least one of: a user application of the computer system, a system application of the computer system, or a user of the computer system;
determining (<NUM>), by the menu application and based on the context, a second order of presentation of second windows within the dynamic menu, each of the second windows corresponding to one of the inactive computing services, the second order predefined for the context, indicating an arrangement of the second windows according to application types, and being different from another order predefined for another context; and
presenting (<NUM>), by the menu application, the first windows within the dynamic menu according to the first order and the second windows within the dynamic menu according to the second order, one or more of the first windows and one or more of the second windows presented in a first presentation state, and one of the first windows or one of the second windows presented in a second presentation state, the second presentation state presenting more information relative to the first presentation state.