Methods and systems for implementing application chaining and for displaying customized content in a welcome screen

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/402,762, filed Sep. 30, 2016, and U.S. Provisional Patent Application Ser. No. 62/452,165, filed Jan. 30, 2017, the entire disclosures of which are hereby incorporated herein by reference in their entirety. This application is related to U.S. Provisional Patent Application Ser. No. 62/308,442, filed Mar. 15, 2016, the entire disclosures of which are hereby incorporated herein by reference in their entirety.

FIELD

Systems and methods for displaying customized content and further executing a series of applications on output devices are disclosed.

BACKGROUND

Increasingly, video entertainment, such as movies and television shows, is delivered to users on demand over digital networks. In addition, the distribution of content has expanded to include user devices, such as smart phones. These user devices have the ability to interface with content delivery systems and to output video and other content to users and various output devices. However, because of the need for mobility, the output capabilities of user devices are necessarily limited. Therefore, it is desirable to direct content streams associated with a user device to televisions or home theater systems.

Systems and methods currently available include those that involve establishing a dedicated connection between a user device and an output device. However, such dedicated connections can be limited by controls put in place by digital rights management systems in addition to processor and memory utilization of the user device. Moreover, the user device, and thus the user, control the content delivered to such output devices. In some environments, such as hospitality settings, the user may control what content is displayed and when it is to be displayed and therefore limit control of the hospitality provider.

Further, in many hospitality settings, there is a desire to provide entertainment services to guests using applications and devices that are familiar to guests. Accordingly, making such entertainment services, such as Netflix®, available to guests while maintaining security and implementing device isolation, which prevents user devices from discovering other devices, has proved to be difficult. For example, Wi-Fi clients may be restricted from seeing other Wi-Fi devices. A requirement of device isolation thus conflicts with the desire to allow a user device to discover and make use of other Wi-Fi devices in the vicinity of the user device and further allow a user to use video entertainment applications familiar to the user. Moreover, when not in use by a user device, output devices generally sit idle and provide little functionality even though such output devices exist as part of a network and are otherwise accessible.

SUMMARY

Embodiments of the present disclosure are directed to systems and methods for providing entertainment services to users using applications and devices that are familiar to guests while customizing and expanding functionality of such devices. Further, embodiments of the present disclosure may be directed to delivering customized content to the output devices when such output devices are not in use by other user devices. Embodiments of the present disclosure enable a user device to operably connect to an output device through a selected local player, such as an over-the-top (OTT) device. In accordance with at least some embodiments of the present disclosure, a local player includes an app, or application, that is operable to display customized content at the direction of a user device and generally after being paired or otherwise associated with the user device. For example, the app may be operable to request a pairing code from a network authority. The pairing code obtained by the local player can be displayed on an output device connected to the local player. A user can then enter the displayed pairing code into the user device, and send that code to a verification and/or authorization server using an app.

In a hospitality setting, for a user device to send content, or cast content, to an output device, a user's device must be registered with a system network controller (SNC). Once the registration is complete, the user's device is paired with their current room and casting may be enabled for any television in that room for compatible applications. The registration and pairing require certain pieces of information to be transmitted to the SNC server. The SNC server gets this information transmitted to it via web service calls/APIs from different external sources depending on registration method and site configuration. The SNC server maintains the pairing association between a user's device, room, and local players (e.g., Chromecast devices or “over-the-top” (OTT) devices) in that room until instructed to destroy that association. The SNC server may require identification information, such as a room number and/or IP and/or MAC address of the user's device in order to register that device and pair it with the user's (e.g., the guest's) room. The SNC server, once paired, forwards the correct network traffic between a user's device and the local player in the guest room, allowing casting of content to the local player. The SNC server may maintain a table of local players in each room and create a lookup table of device MAC addresses paired with local players in each room at any given time. All web service calls to or from the SNC server may contain basic information such as date, time, a sequence/packet identifier, etc.

In accordance with embodiments of the present disclosure, when an output device is not in use, for example when the OTT device is not being used in connection with an output device to display content at the output device, the SNC may cause the OTT device to send customized content to be displayed at the output device; such customized content may be in the form of a default or welcome screen. The default or welcome screen may display user (guest) related information, where such information is obtained from various information sources. For example, the default or welcome screen may include specific operator branding information, such as a logo, and may further include information about a guest's schedule, conference schedule, guest experience, and/or local information for example.

In accordance with embodiments of the present disclosure, when an OTT device is being used in connection with an output device to display content at the output device, the OTT device may launch a series, or chain, of other apps. Such series, or chain, of apps may be determined based on a current app that is running, user information, user location, hospitality requirements, and/or at random. As one non-limiting example, an app may be running which is generally associated with a checkout process. At the conclusion of the checkout process, the OTT device may execute one or more apps requesting guest or user feedback and/or comments.

In accordance with embodiments of the present disclosure, a communication system in a hospitality environment may include a server, an output device, and a local player in communication with the server. The local player may be configured to provide display information to the output device and further provide a status message to the server. The local player may be configured to receive application identification from the server identifying one or more applications to execute, retrieve additional content from a content source, and execute the one or more applications thereby providing the display information including the additional content to the output device for display at the output device. In accordance with one or more aspects of the above embodiment, the status message may indicate that the local player is in an inactive state. In accordance with one or more aspects of the above embodiment, the status message may indicate an amount of time that the local player has been inactive. In accordance with one or more aspects of the above embodiment, the additional content may be guest-related information including at least one guest name. In accordance with one or more aspects of the above embodiment, the communication system may include a first network connecting the server to the local player and a second network connecting the local player to the content source. In accordance one or more with aspects of the above embodiment, the content source may be physically located at a site other than a site at which the local player is physically located. In accordance with one or more aspects of the above embodiment, the additional content may include location information related to a location in which the local player is located.

In accordance with embodiments of the present disclosure, a method for displaying content at an output device is provided. The method includes providing, by a local player connected to the output device, a status message to a system network controller indicating that the local player is inactive, receiving, at the local player, application identification information, the application identification information identifying one or more applications to launch, retrieving additional content from a content source, assembling display information that includes the additional content received from the content source, and providing the assembled display information to the output device. In accordance with one or more aspects of the above embodiment, the status message may indicate that the local player is in an inactive state. In accordance with one or more aspects of the above embodiment, the status message may indicate an amount of time that the local player has been inactive. In accordance with one or more aspects of the above embodiment, the additional content may be guest-related information including at least one guest name. In accordance with one or more aspects of the above embodiment, the method may include retrieving location information related to a location in which the local player is located, where the assembled display information includes the guest-related information and the location information.

In accordance with embodiments of the present disclosure, a method for chaining two or more applications together is provided. The method may include receiving, at a local player, first application identification information, the first application identification information identifying a first application to launch, launching the first application, after launching the first application, determining that a second application is to be launched, receiving, at the local player, the second application identification information, the second application identification information identifying the second application to launch, and launching the second application. In accordance with one or more aspects of the above embodiment, the method may further include adding the second application identification information to an application list. In accordance with one or more aspects of the above embodiment, the method may further include removing third application identification information identifying a third application from the application list. In accordance with one or more aspects of the above embodiment, the application list may include application identification information for a plurality of applications. In accordance with one or more aspects of the above embodiment, the application list may be received from a system network controller. In accordance with one or more aspects of the above embodiment, the second application identification information may be added to the application list at a device other than the local player. In accordance with one or more aspects of the above embodiment, the method may further include determining that a second application is to be launched prior to the first application completing execution. In accordance with one or more aspects of the above embodiment, the method may further include providing a notification to a device other than the local player that the first application has completed execution.

Additional features and advantages of embodiments of the present disclosure will become more readily apparent from the following description, particularly when taken together with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram depicting components of a system in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting components of a second system in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 3</figref> depicts a display of customized content in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 4</figref> depicts a process for selecting and delivering content in response to an idle condition in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIGS. 5A-5B</figref> depict processes for chaining multiple applications in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 6</figref> depicts components of an application in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 7</figref> depicts aspects of a system network controller (SNC) in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 8</figref> depicts aspects of an over-the-top device (OTT) in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 9</figref> depicts a first application chain in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 10</figref> depicts a second application chain in accordance with embodiments of the present disclosure;

<figref idref="DRAWINGS">FIG. 11</figref> depicts a third application chain in accordance with embodiments of the present disclosure; and

<figref idref="DRAWINGS">FIGS. 12A-12C</figref> depict a series of displays that may be presented to an output device in accordance with embodiments of the present disclosure.

DETAILED DESCRIPTION

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a system <b>100</b> for enabling connectivity in accordance with embodiments of the present disclosure. The system <b>100</b> generally includes one or more user devices <b>104</b>. As an example, but without limitation, a user device <b>104</b> may comprise a mobile device, such as a smart phone. As further examples, a user device <b>104</b> may comprise a tablet or a laptop computer. A user device <b>104</b> can connect to a system network controller (SNC) <b>108</b> through a first or guest communication network <b>112</b>. As an example, but without limitation, the first communication network <b>112</b> may comprise a Wi-Fi network provided through one or more access points <b>116</b>. For instance, an access point <b>116</b> may be provided for a particular and/or specific guest room <b>102</b> or group of guest rooms. Access to the first communication network <b>112</b> by user device <b>104</b> can require entry of a valid room number, guest name, or other credential.

The system <b>100</b> also includes one or more output devices <b>120</b>, for example televisions, each of which may be associated with a local player <b>124</b>, such as a Chromecast device. The local player <b>124</b> can be connected to the output device <b>120</b> via an HDMI port. Power may be supplied to the local player <b>124</b> through a USB port associated with the output device <b>120</b>. The USB port may be one that supplies power when the output device <b>120</b> is itself powered on, or can be configured to supply power continuously. In accordance with other embodiments, power may be supplied to the local player <b>124</b> through other means. For example, the local player <b>124</b> can be connected to a wall outlet. Alternatively, or in addition, the local player <b>124</b> may reside within the output device <b>120</b>. That is, the output device <b>120</b> may include the functionality of the local player <b>124</b>. In accordance with embodiments of the present disclosure, the local player <b>124</b> may be connected to the SNC <b>108</b> through a second, communication network <b>128</b> which may be hidden. The second communication network <b>128</b> may be provided by the same or a different access point <b>116</b> as is used to provide the first communication network <b>112</b>.

The SNC <b>108</b> may perform registration functions with respect to devices, including but not limited to, mobile devices <b>104</b>, output devices <b>120</b>, and local players <b>124</b>. More specifically, the SNC <b>108</b> may maintain a table of information identifying such devices <b>104</b>, <b>120</b> and <b>124</b>, and associations between such devices. Moreover, upon the completion of registration, the SNC <b>108</b> may pair a mobile device <b>104</b> to a local player <b>124</b> and an associated output device <b>120</b>, enabling the mobile device <b>104</b> to deliver content to the local player <b>124</b>, and to have that content output through the output device <b>120</b>.

A system <b>100</b> in accordance with embodiments of the present disclosure can include various other devices and network nodes, located locally or remotely with respect to the output devices <b>120</b>. For example, a local premises or hotel head end system <b>130</b> may be provided that includes the SNC <b>108</b> and a local area network switch, router, and/or Internet access core <b>132</b>, which may be associated with a wireless or wireline (e.g., Ethernet) network or networks. As a further example, a guest Internet access controller (GIA) <b>136</b> can be provided as part of the head end system <b>130</b> for controlling and authorizing access to the first wireless network <b>112</b> by mobile device <b>104</b>, or other devices. The head end system <b>130</b> may generally include a control center in an entertainment system where various signals are brought together and monitored before being introduced into the local entertainment network. Accordingly, the reference to head end system <b>130</b> is not limited to video entertainment providers, such as cable tv systems, but may also include various monitoring and control features associated with Internet access, wireless Internet access, output devices <b>120</b>, local players <b>124</b>, and other devices and services a guest of a hospitality establishment may use. Various other devices may be connected to the head end system <b>130</b> via the Internet <b>140</b>. Examples of such systems include a local player app and asset server <b>144</b>, a remote communication interface (RCI) server <b>148</b>, and an information services provider server <b>152</b> residing at location <b>156</b>. Location <b>156</b> may be remote from the head end system <b>130</b>, within the head end system <b>130</b>, on the hospitality or hotel premises, or distributed between multiple physical locations—including where all are resident in the headend <b>130</b>, or distributed amongst several locations <b>156</b>. In general, the app and asset server <b>144</b> may handle communications with an app running on a local player <b>124</b>. The RCI server <b>148</b> may comprise a cloud server that creates pairing codes that are returned in response to a request to initiate a pairing between an output device <b>120</b> and a mobile device <b>104</b>, directly or through a local player <b>124</b>. The information services provider server <b>152</b> may provide information, such as but not limited to, hospitality-related, guest-related, and/or locally-related content to the local player <b>124</b> and/or the SNC <b>108</b>.

In accordance with at least some embodiments of the present disclosure, pairing between a mobile device <b>104</b> and an output device <b>120</b> is performed in connection with a request for a pairing code that is entered through interaction of a guest or other user with a menu system displayed by the output device <b>120</b> that is operated in connection with an on-site host provided as part of the head end system <b>130</b>. For example, a particular implementation of an SNC <b>108</b> or an additional head end server, which is operable to provide on-demand or other programming and interactive television functions via an output device <b>120</b>, can provide the menu system that enables a user to request a pairing code. When the user selects a menu item in the interactive television system to request a pairing between the mobile device <b>104</b> of the user and the output device <b>120</b>, the head end system <b>130</b> makes a request for a pairing code that is created by a web service call to the RCI server <b>148</b>. The information sent to the RCI server <b>148</b> to generate the pairing code may include a site identifier, a guest ID, and/or a TV terminal ID where the code was requested from. The pairing code is returned from the RCI server <b>148</b> to the head end system <b>130</b>, which displays it to the guest via the television (i.e., the output device <b>120</b>).

The displayed code is then entered by the guest into a connectivity app that is running on the mobile device <b>104</b> that provides connectivity to the RCI server <b>148</b>. More particularly, the connectivity app on the user device <b>104</b> transmits the code along with the IP/MAC address information needed for association of the mobile device <b>104</b> with the output device <b>120</b> and the associated local player <b>124</b> by the SNC server <b>108</b>. The mobile device <b>104</b> is then registered with the SNC server <b>108</b>, including an association between the mobile device <b>104</b> and the output device <b>120</b>. Alternatively, or in addition, the SNC server <b>108</b> may use the room number and IP/MAC address of the mobile device <b>104</b> to create a pairing between the local player <b>124</b> in the guest room and the mobile device <b>104</b>. The pairing is dissolved when the head end system <b>130</b> receives a checkout message from the site's property management system (PMS). That is, when the checkout message is received, the head end system <b>130</b> may make a web service call to the SNC server <b>108</b> to dissolve all device pairings in a room. If a PMS system is not sending messages to the head end system <b>130</b>, the head end system <b>130</b> can operate such that the guest is checked out at a specific time each day, at which time all device pairings for the room may be dissolved.

In accordance with still other embodiments of the present disclosure, pairing can be performed without requiring an interactive television system running through a local head end system <b>130</b>. Instead, pairing can be performed in connection with an application running on a local player <b>124</b> interacting with the RCI server <b>148</b>.

The app on the local player <b>124</b> can be launched via a command from the SNC server <b>108</b> when the SNC server <b>108</b> detects that a local player <b>124</b> has powered up. A local player app or application, such as a default app at power up, makes a web service call to the local SNC server <b>108</b> to get information regarding in what room and site it is installed. The information from the local SNC server <b>108</b> also contains the URL for what app, such as a second app, to launch. Once this information is retrieved, the local player app calls the specified URL and loads the requested application from a server. The URL for the requested application may point to the application and asset server <b>144</b>, the information services provider server <b>152</b>, the SNC <b>108</b>, and/or another server providing or otherwise serving an app to the local player <b>124</b>. The app running on the local player <b>124</b> then communicates, via a web service call for example, with the RCI server <b>148</b> to generate a pairing code. The information sent to the RCI server <b>148</b> to generate the pairing code includes a site identifier and room number where the code was requested from. The RCI server <b>148</b> generates the pairing code and returns it to the local player app.

The local player app then displays the received pairing code on the output device <b>120</b> to the user. The pairing code can be generated on a timed basis, refreshed by an API call, or other criteria. The user then enters the code into the connectivity app running on the mobile device <b>104</b>. The connectivity app transmits the pairing code entered by the user, along with the IP/MAC address information needed to allow the SNC server <b>108</b> to associate the mobile device <b>104</b> with the local player <b>124</b> to the RCI server <b>148</b>. The RCI server <b>148</b> makes a web service call to the SNC server <b>108</b>, passing the information from the mobile device <b>104</b> to the SNC server <b>108</b>. The SNC server <b>108</b> uses the room number and IP/MAC address of the mobile device <b>104</b> to create a pairing between the local player or players <b>124</b> in the guest room and their mobile device <b>104</b>. Optionally, the app running on the local player <b>124</b> can continue to display the pairing code after a mobile device <b>104</b> has been paired, to enable other devices <b>104</b> to be paired to the local player or players <b>124</b>. In addition, the app running on the local player <b>124</b> can provide an indication to the user that pairing has been successfully completed.

A flag can be set in the SNC server <b>108</b> to dissolve all pairings at the site at a scheduled time each day. Alternatively, a property management system can make a call to a web service to dissolve a pairing for a particular room at a selected time.

In accordance with other embodiments of the present disclosure, pairings can be completed in association with an app running on a mobile device <b>104</b> that is not associated with the head end system <b>130</b> or the RCI server <b>148</b>. That is, a “third-party” app running on the mobile device <b>104</b> can be configured to provide necessary information to the RCI server <b>148</b> in order to start the device registration and pairing process. The information provided by the app can include a site identifier, room number, guest device Wi-Fi IP, and/or MAC address. The RCI server <b>148</b> makes a web service call to the SNC server <b>108</b>, passing the information from the mobile device <b>104</b> to the SNC server <b>108</b>. The SNC server <b>108</b> uses the room number and IP/MAC address of the mobile device <b>104</b> to create a pairing between the local player <b>124</b> in the guest room and the mobile device <b>104</b>. Accordingly, the user never has to enter a pairing code. In a typical implementation, the third-party app is an app provided by the hotel offering connectivity to televisions or other output devices <b>120</b> in guest rooms. In accordance with at least some embodiments, a user is required to enter items of information, such as room number, hotel rewards program login credentials, or other information. A pairing thus established can be dissolved through a web service call/API. For example, upon check out from the room, the third-party app can pass a site identifier in the room number to the RCI server <b>148</b>. The RCI server <b>148</b> makes a web service call to the site's SNC server <b>108</b> passing the room number information. The SNC server <b>108</b> uses the room number to cancel all pairing associations between a room and all user devices <b>104</b> assigned to that room and previously paired. If the third-party app does not implement the web service call to dissolve pairing, the pairing can be dissolved through a message sent from a property management system, the pairing can be dissolved at a specific time each day, or pairing can be dissolved manually through a command entered by the user.

In accordance with still other embodiments of the present disclosure, pairing can be completed in association with a guest Internet access (GIA) login. In particular, when a user signs on to a hotel's guest Internet access system <b>136</b>, that system is aware of the user device's <b>104</b> IP and MAC addresses. Most GIA systems are also aware of the guest room number for identity validation or property management system integration purposes. At the time of signing in, the GIA system <b>136</b> sends site identifier, room number, and guest device Wi-Fi IP and/or MAC address to the RCI server <b>148</b>, via a web service call/API. The RCI server <b>148</b> in turn makes a web service call to the correct site's SNC server <b>108</b>, passing the information about the guest's device <b>104</b> from the GIA server <b>136</b> to the SNC server <b>108</b>. The SNC server <b>108</b> uses the room number and IP/MAC address of the user device <b>104</b> to create a pairing between the local player <b>124</b> in the guest room and the user device <b>104</b>. In addition to providing convenient pairing of a user device <b>104</b> in the form of a smart phone, such embodiments also enable laptop computers, tablets, or other devices that may support casting through the chrome browser or other applications to an output device <b>120</b>.

A user device <b>104</b> association with a room can be provided to the RCI server <b>148</b> by the GIA system <b>136</b> upon guest checkout or dissolution of a user device's <b>104</b> association with a room. The RCI server <b>148</b> makes a web service call to the SNC server <b>108</b> for the site, passing the room number information. The SNC server <b>108</b> uses the room number to cancel all pairing associations between the room and user devices <b>104</b> assigned to that room. Alternatively, a checkout message from a PMS, automatic dissolution at a scheduled time each day, manual guest dissolution, or other options for dissolving a pairing can be implemented.

In accordance with still other embodiments, a web service/API to request all devices currently registered for a guest Internet system can be polled when the SNC server <b>108</b> detects that a local player <b>124</b> is being powered on, to determine if there are any user devices <b>104</b> currently assigned to that room. Information regarding such user devices <b>104</b> returned by the GIA system <b>136</b> can be used by the SNC server <b>108</b> to match the user devices <b>104</b>, by room number, to the appropriate local player or players <b>124</b>. This polling could be performed periodically, for example where local players <b>124</b> are powered on continuously. Pairings can be dissolved when validation checks, for example performed when a local player <b>124</b> boots up, determine that a formerly valid user device <b>104</b> is no longer associated with the GIA system <b>136</b>.

In accordance with at least some embodiments of the present disclosure, the SNC server <b>108</b> can be configured to point at a defined Web service and broadcast helpful messages to that service. A “casting started” and “casting ended” method may be broadcast when a user starts casting content and when they stop casting. This would allow a third-party provider or system to appropriately tune the television, or set-top box associated with an output device <b>120</b>. A user can then perform casting through selecting a casting icon in a selected content app. Upon making such a selection, a DRE server or set-top box listening for such events could perform the necessary tuning to the appropriate HDMI input. In such embodiments, information maintained by the SNC server <b>108</b> can include a field identifying, for each local player <b>124</b>, a unique identifier for an associated set-top box or tuner. This information can be passed as part of the broadcast messages. Alternatively, or in addition, a master flag can be set on a per room basis to indicate whether a room is available for casting, locked to a currently paired device <b>104</b>, or to implement protocols to charge a fee before casting can be initiated.

In accordance with still further embodiments of the present disclosure, the system <b>100</b> can implement app blocking. In particular, the system <b>100</b> can control or limit the apps that can be run in connection with a pairing between a user device <b>104</b> and a local player <b>124</b>. For example, apps that may be disruptive, such as a local player configuration app or an unspecified Torrent app, can be blocked by refusing to answer a request by a user device <b>104</b> to launch those apps. This prevents the user from changing the local player <b>124</b> settings, or from running potentially unfriendly apps. In accordance with at least some embodiments, blocking can be implemented by having the SNC <b>108</b> block the ability to send web calls to the local player <b>124</b> via a specific TCP port on the local player <b>124</b> that is used by a configuration app. In addition, or alternatively, white lists, black lists, and the like can be used.

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an alternate system <b>200</b> for enabling connectivity in accordance with embodiments of the present disclosure, and, in particular, a system <b>200</b> that enables the user device <b>104</b> to selectively connect to an output device <b>120</b> through a device <b>204</b>, such as a set-top box (STB) or other system configured to work with the head end system <b>130</b>. Accordingly, this system <b>200</b> differs from the system <b>100</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref> in that this system <b>200</b> operates in association with a device <b>204</b> that may control content displayed to the output device <b>120</b> using existing configurations. Therefore, the OTT device, including the local player <b>124</b>, may be connected to an HDMI port for example, and the device <b>204</b> may selectively control the local player <b>124</b> to enable/disable content to be displayed at the output device <b>120</b>. In that the device <b>204</b> may already exist and implement or otherwise be part of an already existing configuration/setup, the device <b>204</b> may connect with the head end system <b>130</b> via a third communication network <b>208</b>, which may be wireless, Ethernet, coaxial, or other wireline connection.

<figref idref="DRAWINGS">FIG. 3</figref> is an example of a default or welcome display <b>304</b> displayed at the output device <b>120</b> in accordance with embodiments of the present disclosure. As previously discussed, in instances where the local player <b>124</b> is not being used, and/or in instances when the local player <b>124</b> is powering on, the welcome screen <b>304</b> may be the first, or otherwise give an impression of being the first, content displayed to the output device <b>120</b>. The welcome screen <b>304</b>, also referred to as a default display and/or welcome display, may include hospitality branding content <b>308</b>, such as a logo. The hospitality branding content <b>308</b> may be provided from the SNC <b>108</b>, the information services provider <b>152</b>, the application and asset server <b>144</b>, and/or another server accessible to the SNC and/or local player <b>124</b>. The default or welcome display <b>304</b> may include guest information <b>312</b>, such as a guest name and/or guest schedule <b>332</b>. The guest information <b>312</b> may be provided from the SNC <b>108</b>, the information services provider <b>152</b>, the application and asset server <b>144</b>, and/or another server accessible to the SNC <b>108</b> and/or local player <b>124</b>. The default or welcome display <b>304</b> may include an interactive content section <b>316</b>, which may allow a user to interact with, control, or otherwise participate in the welcome display <b>304</b>. For example, a guest may move a selection box from a first position to pairing information <b>320</b>; selecting pairing information <b>320</b> may display pairing information associated with the user device <b>104</b>, and/or the room <b>102</b>. The guest may use a remote or an app to move the selection box in <figref idref="DRAWINGS">FIG. 3</figref>. Alternatively, or in addition, the entirety of or portions of the interactive content section <b>316</b> may not be interactive at all; instead, the interactive content section <b>316</b> may display actual pairing information and/or an actual listing of guest devices. The guest information <b>312</b> may be provided from the SNC <b>108</b>, the information services provider <b>152</b>, the application and asset server <b>144</b>, and/or another server accessible to the SNC <b>108</b> and/or local player <b>124</b>.

The default or welcome display <b>304</b> may include local information <b>324</b> that is local to the hospitality services provider. For example, the local information <b>324</b> may include, but is not limited to, weather information. The local information <b>324</b> may be provided from the SNC <b>108</b>, the information services provider <b>152</b>, the application and asset server <b>144</b>, and/or another server accessible to the SNC <b>108</b> and/or local player <b>124</b>. As previously discussed, the guest information may include a guest schedule <b>332</b> and the guest schedule <b>332</b> may include information provided from the SNC <b>108</b>, the information services provider <b>152</b>, the application and asset server <b>144</b>, and/or another server accessible to the SNC and/or local player <b>124</b>. The guest schedule <b>332</b> may additionally include information obtained from or provided by the user device <b>104</b>. For example, the user device <b>104</b> may grant access to the information services provider server <b>152</b> for example. Calendar events, contacts, and other information may then be requested by the local player <b>124</b> via a web services call such that the local play <b>124</b> can assemble and then display such information at the output device <b>120</b>. In some instances, the schedule <b>332</b> may include links, such as a link <b>336</b> that provides additional information associated with one or more information content pieces within the schedule <b>332</b>. Importantly, the default or welcome display <b>304</b> is launched and displayed on the output device <b>120</b> with no guest interaction. That is, when the local player <b>124</b> is not in use and/or when the local player <b>124</b> is powered on, the default or welcome display <b>304</b> is displayed at the output device <b>120</b>.

<figref idref="DRAWINGS">FIG. 4</figref> depicts aspects of the operation of a system for selecting and delivering default content, such as a default or welcome screen <b>304</b> in accordance with embodiments of the present disclosure. That is, <figref idref="DRAWINGS">FIG. 4</figref> generally illustrates a messaging flow diagram. Initially, at step <b>404</b>, the OTT/local player <b>124</b> provides status information to the SNC server <b>108</b> using a status information message for example. Such status information message may include information related to the OTT/local player <b>124</b> having not been in use for a predetermined period of time, or a measurement of time that the OTT/local player <b>124</b> has not been in use. Alternatively, or in addition, the status information message may include information indicating that the OTT/local player <b>124</b> has just powered on. The SNC <b>108</b> then determines that the OTT/local player <b>124</b> has not been in use or has been powered on at step <b>408</b> and as a result, sends the OTT/local player <b>124</b> an application ID related to the default or welcome display <b>304</b> that the OTT/local player <b>124</b> is to run. Accordingly, at step <b>412</b>, the OTT/local player <b>124</b> contacts the application and asset server <b>144</b> and provides the application ID. The application and asset server <b>144</b> may then provide a Uniform Resource Locator (URL) to the OTT/local player <b>124</b> at step <b>416</b>. After launching the application associated with the URL, at step <b>420</b>, the OTT/local player <b>124</b> may request information from the application and asset server <b>144</b>. The information requested may pertain to hospitality branding information, such as the logo <b>308</b>. Alternatively, or in addition, the OTT/local player <b>124</b> may contact the information services provider server to obtain guest information such as name <b>312</b>, schedule <b>332</b>, and local information <b>324</b> at step <b>424</b>. Alternatively, or in addition, the OTT/local player <b>124</b> may contact the SNC <b>108</b> and retrieve pairing information and/or other device information. Such contacts by the OTT/local player <b>124</b> to the application and asset server <b>144</b>, the information services provider server <b>152</b>, and the SNC <b>108</b> may be made by a web services connection.

The OTT/local player <b>124</b> may then receive such information from the application and asset server <b>144</b>, the information services provider server <b>152</b>, and/or the SNC <b>108</b> at steps <b>428</b> and <b>432</b> and assemble and render the resulting default or welcome display to the output device <b>120</b> at step <b>436</b>. Noticeably absent from the flow messaging diagram of <figref idref="DRAWINGS">FIG. 4</figref>, is any interaction from the user. That is, the default or welcome display <b>304</b> is provided to the output device with no user interaction. Rather, the SNC <b>108</b> essentially tells the OTT/local player <b>124</b> which application to launch, such as the application presenting the welcome screen <b>304</b>.

<figref idref="DRAWINGS">FIG. 5A</figref> depicts aspects of the operation of a system for initiating a controlling application chaining of selected apps or applications in accordance with embodiments of the present disclosure. That is, <figref idref="DRAWINGS">FIG. 5A</figref> generally illustrates a messaging flow diagram. Initially, at step <b>504</b>, an application identifier is received at the OTT/local player <b>124</b>; the application identifier may identify an application that is to be initially launched. The application identifier may be received from a user device <b>104</b>, the SNC <b>108</b>, and/or another server in communication with the OTT/local player <b>124</b>. The OTT/local player <b>124</b> may then contact the application and asset server <b>144</b> at step <b>508</b> to receive the Uniform Resource Locator (URL) associated with the received application ID. In some instances, the OTT/local player <b>124</b> may contact an intermediate server or service to obtain an address of the application and asset server <b>144</b> based on the application ID. At step <b>512</b>, the OTT/local player <b>124</b> receives the application URL and launches the application at step <b>516</b>. Further, at step <b>516</b>, the app may contact one or more of the SNC <b>108</b>, the application and asset server <b>144</b>, and/or the information services provider <b>152</b> and request a list of applications to be launched. Such contact may be in the form of a web services call. The list of applications may be in the form of application identifiers and/or URLs.

At step <b>520</b>, the OTT/local player <b>124</b> receives the application list and then stores the application list at step <b>524</b>. The application list may be stored locally at the OTT/local player <b>124</b>, at the SNC <b>108</b> as depicted in <figref idref="DRAWINGS">FIG. 5A</figref>, or at another accessible location. At step <b>528</b>, the OTT/local player <b>124</b> may assemble and render content to be displayed at the output device <b>120</b> while executing and/or launching the application. Further, based on the launching and execution of the application associated with the application identifier, an updated application list may be needed. For instance, if a portion of the application is executed based on one or more conditions that indicate another app should be launched and/or executed, the application list may be updated to include such app, at step <b>532</b> for example. Likewise, if a portion of the application is executed based on one or more conditions that indicate an application in the current list should not be launched and/or executed the application list may be updated to exclude such app. Moreover, in that the application list may be stored locally at the OTT/local player <b>124</b>, at the SNC <b>108</b>, at the application and asset server <b>144</b>, and/or at the information services provider <b>152</b>, OTT may utilize a web services call to update such list. At step <b>536</b>, and at the completion of the currently running app, the OTT/local player <b>124</b> may message the SNC <b>108</b> to indicate that the current app has completed and the next app in the list should be executed. Accordingly, at step <b>540</b>, the SNC <b>108</b> may message the OTT/local player <b>124</b> with the next application identifier in the application list. Thus, the process may repeat at step <b>504</b> until all applications in the list have been executed and/or have completed execution.

<figref idref="DRAWINGS">FIG. 5B</figref> depicts aspects of the operation of a system for initiating a controlling application chaining of selected apps or applications in accordance with embodiments of the present disclosure. That is, <figref idref="DRAWINGS">FIG. 5B</figref> generally illustrates a messaging flow diagram. <figref idref="DRAWINGS">FIG. 5B</figref> differs from <figref idref="DRAWINGS">FIG. 5A</figref> in that the SNC <b>108</b> maintains an application list and causes the OTT/local player <b>124</b> to launch the applications in the list. That is, at step <b>504</b>, an application identifier is received at the OTT/local player <b>124</b>; the application identifier may identify an application that is to be initially launched. The application identifier may be received from a user device <b>104</b>, the SNC <b>108</b>, and/or another server in communication with the OTT/local player <b>124</b>. The OTT/local player <b>124</b> may then contact the application and asset server <b>144</b> at step <b>508</b> to receive the Uniform Resource Locator (URL) associated with the received application ID. In some instances, the OTT/local player <b>124</b> may contact an intermediate server or service to obtain an address of the application and asset server <b>144</b> based on the application ID. At step <b>512</b>, the OTT/local player <b>124</b> receives the application URL and launches the application at step <b>544</b>. At step <b>548</b>, the SNC <b>108</b> determines if there are additional applications to be launched. This determination may be based on the currently running application, and/or information from the application and asset server <b>144</b> and/or the information services provider server <b>152</b> indicating that one or more apps should be launched. Alternatively, or in addition, the SNC <b>108</b> may determine that another app should be launched at the conclusion of the existing app. Accordingly, at step <b>532</b>, the SNC <b>108</b> may receive an application list and then store or otherwise update an existing application list located at the SNC <b>108</b>.

At step <b>528</b>, the OTT/local player <b>124</b> may assemble and render content to be displayed at the output device <b>120</b> while executing and/or launching the application. Further, based on the launching and execution of the application associated with the application identifier, an updated application list may be needed. For instance, if a portion of the application is executed based on one or more conditions that indicate another app should be launched and/or executed, the application list may be updated to include such app. Likewise, if a portion of the application is executed based on one or more conditions that indicate an application in the current list should not be launched and/or executed the application list may be updated to exclude such app. Accordingly, steps <b>548</b> and <b>532</b> may be performed multiple times.

At step <b>536</b>, and at the completion of the currently running app, the OTT/local player <b>124</b> may message the SNC <b>108</b> to indicate that the current app has completed and the next app in the list should be executed. Accordingly, at step <b>540</b>, the SNC <b>108</b> may message the OTT/local player <b>124</b> with the next application identifier in the application list. Thus, the process may repeat at step <b>504</b> until all applications in the list have been executed and/or have completed execution.

<figref idref="DRAWINGS">FIG. 6</figref> depicts one or more components of an app, or application, <b>604</b> to be launched at the OTT/local player <b>124</b> in accordance with embodiments of the present disclosure. In instances where multiple apps are desired to be launched in a serial order, also referred to herein as application chaining, and where each app may include components, modules, and/or programming code to execute such app chaining, the app <b>604</b> may include an entrance procedure <b>608</b> and an exit procedure <b>620</b>. The entrance procedure <b>608</b> may determine how the app <b>604</b> is to behave when initially launched. For example, the app <b>604</b> may message the SNC <b>108</b> at launch to inform the SNC <b>108</b> that it is launching an application; the application identifier may be included in such a message. Further, the entrance procedure <b>608</b> may require that the app <b>604</b> check with one or more sources of information, for example the SNC <b>108</b>, the application and asset server <b>144</b>, and/or the information services provider server <b>152</b> to determine if an application list already exists or needs to be created. Such contact may be in the form of a web services call for example. In some instances, the application list may exist on a device other than the OTT/local player <b>124</b>. For example, the application list may be maintained at the SNC <b>108</b>, the application and asset server <b>144</b>, and/or the information services provider server <b>152</b>.

The component <b>612</b> may be the programing instructions which execute the functionality of the app <b>604</b>. In some instances, the app <b>616</b> may include instructions to update the previously mentioned application list based on one or more conditions encountered when executing the app <b>604</b>. For example, if, based on a determination that a user wished to launch an application associated with a checkout procedure, the application list may be updated to execute an app directed to guest feedback and comments. Moreover, such app may be different depending on a length of stay, a frequency of stay, and/or certain services utilized by said guest. Component <b>620</b> may be an exit procedure. Similar to the entrance procedure <b>608</b>, the OTT/local player <b>124</b> may communicate with one or more sources of information, for example the SNC <b>108</b>, the application and asset server <b>144</b>, and/or the information services provider server <b>152</b> to indicate that the app <b>604</b> has finished execution. Accordingly, if another app is to be executed without user interaction, at least one of the SNC <b>108</b>, the application and asset server <b>144</b>, and/or the information services provider server <b>152</b> may provide the next app in the application list, via an application identifier, to the OTT/local player <b>124</b> to execute such app.

<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram illustrating components of a system network controller (SNC) <b>108</b> in accordance with embodiments of the present disclosure. In general, the SNC controller <b>108</b> includes a processor <b>704</b> and memory <b>708</b>. The processor <b>704</b> may comprise a general purpose programmable processor or controller for executing application programming or instructions. As a further example, the processor <b>704</b> may comprise a specially configured application specific integrated circuit (ASIC). The processor <b>704</b> generally functions to run programming code or instructions, such as applications or programs, implementing various functions of the SNC <b>108</b>. The memory <b>708</b> is generally used in connection with the execution of application programming by the processor <b>704</b> and for the temporary or long-term storage of program instructions and/or data. As examples, the memory <b>708</b> may comprise removable secure digital storage, RAM, SDRAM, or other solid-state memory.

The SNC <b>108</b> can also include data storage <b>712</b>. In accordance with embodiments of the present invention, data storage <b>712</b> can contain program code or instructions implementing various applications or functions executed by the SNC server <b>108</b>. Like the memory <b>708</b>, the data storage <b>712</b> can comprise a solid-state memory device. In addition, in certain applications, the data storage <b>712</b> can be integrated with and/or indistinguishable from the memory <b>708</b>. Alternatively, or in addition, the data storage <b>712</b> may comprise a hard disk drive or other random access memory and/or can be interconnected to the communication server <b>112</b>, for example as network-attached storage. Programming or modules stored in the data storage <b>712</b> and executed by the processor <b>704</b> can include, as examples and without limitation, various pairing rules <b>720</b>, various OTT/local player configurations <b>724</b>, and/or one or more application lists <b>716</b>. For example, the OTT/local player configurations <b>724</b> may include mapping information associating one or more OTT/local players <b>124</b> to one or more specific apps or URLs, such as the welcome screen <b>304</b>.

The SNC server <b>108</b> may also include one or more communication interfaces <b>728</b>A-B. For example, a first communication interface <b>728</b>A can provide a connection to the first communication network <b>116</b> or guest virtual local area network (VLAN); a second communication interface <b>728</b>B can provide a connection to a device network, such as the second communication network <b>128</b> or the device VLAN.

<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram illustrating components of the OTT/local player <b>124</b> in accordance with embodiments of the present disclosure. Like the SNC server <b>108</b>, the OTT/local player <b>124</b> can include a processor <b>704</b>, memory <b>708</b>, and/or data storage <b>712</b>. Program code or instructions that can be stored in data storage <b>712</b> and executed by the processor <b>704</b> in connection with the memory <b>708</b>, which can include, but is not limited to, a browser/graphical user interface (GUI) <b>804</b> and a locally stored application list <b>716</b>. In addition, the OTT/local player <b>124</b> may include one or more communication interfaces, such as a communication interface <b>808</b>A connecting to a first network and a connection interface <b>808</b>B, such as HDMI, connecting the OTT/local player <b>124</b> to the output device <b>120</b>.

<figref idref="DRAWINGS">FIG. 9</figref> depicts an application chain <b>900</b> in accordance with embodiments of the present disclosure. As depicted in <figref idref="DRAWINGS">FIG. 9</figref>, a first application <b>908</b> may be initiated by a starting step <b>904</b>. In some embodiments, the first application <b>908</b> may be launched at the direction of the SNC <b>108</b>. Alternatively, or in addition, the first application <b>908</b> may be launched at the direction of the user device <b>104</b>. As further depicted in <figref idref="DRAWINGS">FIG. 9</figref>, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has been launched. In some embodiments, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has completed execution. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may run in parallel. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may be run in series. After the second application <b>912</b> has been launched, a third application <b>916</b> may be launched. That is, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has been launched. In some embodiments, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has completed execution. Of course, the second application <b>912</b> and the third application <b>916</b> may be executed in parallel or in series. The application chain may then end at <b>920</b>.

As further depicted in <figref idref="DRAWINGS">FIG. 9</figref>, changes to an application list <b>924</b> are illustrated over time. That is, at a first time, the application list <b>924</b>A may include the first, second, and third applications. At a second time, the application list <b>924</b>B may include the second and third application since the first application has completed execution. At a third time, the application list <b>924</b>C may include the third application since the first and second applications have completed execution. Each of the application lists <b>924</b>A-<b>924</b>C may be stored in a memory <b>928</b>, which may be the same as or similar to the memory <b>708</b>.

<figref idref="DRAWINGS">FIG. 10</figref> depicts an application chain <b>1000</b> in accordance with embodiments of the present disclosure. As depicted in <figref idref="DRAWINGS">FIG. 10</figref>, a first application <b>908</b> may be initiated by a starting step <b>904</b>. In some embodiments, the first application <b>908</b> may be launched at the direction of the SNC <b>108</b>. Alternatively, or in addition, the first application <b>908</b> may be launched at the direction of the user device <b>104</b>. As further depicted in <figref idref="DRAWINGS">FIG. 10</figref>, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has been launched. In some embodiments, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has completed execution. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may run in parallel. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may be run in series. After the second application <b>912</b> has been launched, a third application <b>916</b> may be launched. That is, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has been launched. In some embodiments, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has completed execution. Of course, the second application <b>912</b> and the third application <b>916</b> may be executed in parallel or in series.

<figref idref="DRAWINGS">FIG. 10</figref> differs from <figref idref="DRAWINGS">FIG. 9</figref> in that the execution of the second application <b>912</b> for example, may cause the application list <b>924</b> to change. That is, the execution of the second application <b>912</b> may cause a fourth application <b>1004</b> to be added to the application list <b>924</b>. As further depicted in <figref idref="DRAWINGS">FIG. 10</figref>, after the second application <b>912</b> has been launched, the application list <b>924</b>D includes the third and fourth applications. Accordingly, the fourth application <b>1004</b> may be chained or otherwise launched after the third application <b>916</b> has been launched. The application chain may then end at <b>1008</b>.

As further depicted in <figref idref="DRAWINGS">FIG. 10</figref>, changes to the application list <b>924</b> are illustrated over time. That is, at a first time, the application list <b>924</b>A may include the first, second, and third applications. At a second time, the application list <b>924</b>B may include the second and third application since the first application has completed execution. At a third time, the application list <b>924</b>D may include the third application <b>916</b> and the fourth application <b>1004</b> since the fourth application <b>1004</b> was added to the application list <b>924</b>. At a fourth time, the application list <b>924</b>E may include the fourth application. Each of the application lists <b>924</b>A-<b>924</b>B and <b>924</b>D-<b>924</b>E may be stored in a memory <b>928</b>, which may be the same as or similar to the memory <b>708</b>.

<figref idref="DRAWINGS">FIG. 11</figref> depicts an application chain <b>1100</b> in accordance with embodiments of the present disclosure. As depicted in <figref idref="DRAWINGS">FIG. 11</figref>, a first application <b>908</b> may be initiated by a starting step <b>904</b>. In some embodiments, the first application <b>908</b> may be launched at the direction of the SNC <b>108</b>. Alternatively, or in addition, the first application <b>908</b> may be launched at the direction of the user device <b>104</b>. As further depicted in <figref idref="DRAWINGS">FIG. 11</figref>, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has been launched. In some embodiments, the second application <b>912</b> may be chained or otherwise launched after the first application <b>908</b> has completed execution. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may run in parallel. In some embodiments, the second application <b>912</b> and the first application <b>908</b> may be run in series. The second application <b>912</b> may add a fourth application <b>1104</b> to the application list <b>924</b>F. After the second application <b>912</b> has been launched, a third application <b>916</b> may be launched. That is, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has been launched. In some embodiments, the third application <b>916</b> may be chained or otherwise launched after the second application <b>912</b> has completed execution. Of course, the second application <b>912</b> and the third application <b>916</b> may be executed in parallel or in series.

<figref idref="DRAWINGS">FIG. 11</figref> differs from <figref idref="DRAWINGS">FIG. 9</figref> and <figref idref="DRAWINGS">FIG. 10</figref> in that the execution of the third application <b>916</b> for example, may cause the application list <b>924</b> to change. That is, the execution of the first application <b>908</b> may cause a fourth application <b>1104</b> to be added to the application list <b>924</b>F. The second application <b>916</b> may cause the fourth application <b>1104</b> to be removed from the application list <b>924</b>G.

As further depicted in <figref idref="DRAWINGS">FIG. 11</figref>, changes to the application list <b>924</b> are illustrated over time. That is, at a first time, the application list <b>924</b>A may include the first, second, and third applications. At a second time, the application list <b>924</b>F may include the second, third, and fourth applications since the first application added the fourth application <b>1104</b> to the application list <b>924</b>F. At a third time, the application list <b>924</b>G may include the third application <b>916</b> since the fourth application <b>1104</b> was removed from the application list <b>924</b>G after the launch of the second application <b>912</b>. Each of the application lists <b>924</b>A and <b>924</b>F-<b>924</b>G may be stored in a memory <b>928</b>, which may be the same as or similar to the memory <b>708</b>.

As depicted in <figref idref="DRAWINGS">FIGS. 12A-12C</figref>, a series of displays may be presented to the output device <b>120</b> in response to user interaction with the local player <b>124</b>. That is, as a user navigates and interacts with a display presented to the output device <b>120</b>, a series of one or more applications may be passively maintained in an application list such that an application chain, or chain of applications, is assembled based on one or more selections of the user. As depicted in <figref idref="DRAWINGS">FIGS. 12A-12C</figref>, the displays <b>1204</b>, <b>1216</b>, and <b>1236</b> may correspond to different applications executed and running on the local player <b>124</b>. As initially depicted in <figref idref="DRAWINGS">FIG. 12A</figref>, a user may be presented with an interactive display <b>1204</b> as part of a welcome screen, for example. A user, using an in-room remote control, a mobile device <b>104</b>, and/or a laptop for example, may navigate through a selectable list of menu choices <b>1208</b>. If the user selects a particular menu choice, for example, guest services <b>1212</b>, the application displaying the display <b>1204</b> may be added to an application list <b>924</b> and a new application may be initiated by the SNC <b>108</b>, for example, and executed by the local player <b>124</b>. A new application may be initiated, executed, and a different display, such as display <b>1216</b>, may be provided to the output device <b>120</b> and thus the user. In accordance with some embodiments, and as previously discussed, one or more entrance and exit procedures may be performed. For example, when entering the application responsible for display <b>1216</b>, the application identifier for the application responsible for display <b>1204</b> may be provided to the SNC <b>108</b> during an exit procedure and an application identifier for the application responsible for display <b>1216</b> may be provided to the SNC <b>108</b> during an entrance procedure. The display <b>1216</b> may include one or more selectable tiles <b>1220</b>-<b>1232</b> of which the user may select.

Further still, if the user selects a tile <b>1220</b>-<b>1232</b>, for example <b>1232</b>, the application responsible for display <b>1216</b> may exit and the application responsible for display <b>1236</b> may be entered/initiated. For example, the application responsible for displaying the display <b>1216</b> may be added to an application list <b>924</b> and a new application may be initiated by the SNC <b>108</b> for example, and executed by the local player <b>124</b>. As an example, a new application may be initiated, executed, and a different display, such as display <b>1236</b>, may be provided to the output device <b>120</b> and thus the user. One or more entrance and exit procedures may be performed; for example, when entering the application responsible for display <b>1236</b>, the application identifier for the application responsible for display <b>1216</b> may be provided to the SNC <b>108</b> in an exit procedure and an application identifier for the application responsible for display <b>1236</b> may be provided to the SNC <b>108</b> in an entrance procedure. As further depicted in <figref idref="DRAWINGS">FIG. 12C</figref>, the user may select another menu choice such as the “View Bill” <b>1240</b> menu choice; such menu choice selection may launch another application as previously discussed. One or more advertisements <b>1244</b>-<b>1248</b>, which may or may not be hyperlinked and selectable, may be displayed in the display <b>1236</b>. Further, an application, such as a survey application, may be added to an application list during an entrance and/or exit procedure.

Accordingly, the present invention has been described with some degree of particularity directed to the exemplary embodiments of the present invention. It should be appreciated though that modifications or changes may be made to the exemplary embodiments of the present invention without departing from the inventive concepts contained herein.