METHODS AND SYSTEMS FOR IMPLEMENTING APPLICATION CHAINING AND FOR DISPLAYING CUSTOMIZED CONTENT IN A WELCOME SCREEN
20180098181 ยท 2018-04-05
Inventors
- Derin Michael Zerr (Kahului, HI, US)
- Shaun Eugene Marko (Oak Park, IL, US)
- Daniel A. Dirks (Vancouver, WA, US)
- Joel Walter Zdepski (Mountain View, CA, US)
Cpc classification
H04L67/06
ELECTRICITY
H04L67/51
ELECTRICITY
H04L67/52
ELECTRICITY
H04W4/70
ELECTRICITY
International classification
H04W4/00
ELECTRICITY
H04W88/00
ELECTRICITY
Abstract
Systems and methods directed to a communication system in a hospitality environment are provided. The communication system may include a server, an output device, and a local player in communication with the server and configured to provide display information to the output device. The local player is configured to provide a status message to the server, 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.
Claims
1. A communication system in a hospitality environment, the communication system comprising: a server; an output device, and a local player in communication with the server and configured to provide display information to the output device, wherein the local player is configured to provide a status message to the server, receive application identification information 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.
2. The communication system of claim 1, wherein the status message indicates that the local player is in an inactive state.
3. The communication system of claim 1, wherein the status message indicates an amount of time that the local player has been inactive.
4. The communication system of claim 3, wherein the additional content is guest-related information including at least one guest name.
5. The communication system of claim 4, further comprising: a first network connecting the server to the local player; and a second network connecting the local player to the content source.
6. The communication system of claim 5, wherein the content source is physically located at a site other than a site at which the local player is physically located.
7. The communication system of claim 4, wherein the additional content includes location information related to a location in which the local player is located.
8. A method for displaying content at an output device, the method comprising: 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.
9. The method of claim 8, wherein the status message indicates that the local player is in an inactive state.
10. The method of claim 8, wherein the status message indicates an amount of time that the local player has been inactive.
11. The method of claim 8, wherein the additional content is guest-related information including at least one guest name.
12. The method of claim 11, further comprising retrieving location information related to a location in which the local player is located, wherein the assembled display information includes the guest-related information and the location information.
13. A method for chaining two or more applications together, the method comprising: 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, second application identification information, the second application identification information identifying the second application to launch; and launching the second application.
14. The method of claim 13, further comprising adding the second application identification information to an application list.
15. The method of claim 14, further comprising removing third application identification information identifying a third application from the application list.
16. The method of claim 14, wherein the application list includes application identification information for a plurality of applications.
17. The method of claim 14, wherein the application list is received from a system network controller.
18. The method of claim 14, wherein the second application identification information is added to the application list at a device other than the local player.
19. The method of claim 13, further comprising determining that the second application is to be launched prior to the first application completing execution.
20. The method of claim 19, further comprising providing a notification to a device other than the local player that first application has completed execution.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
DETAILED DESCRIPTION
[0026]
[0027] The system 100 also includes one or more output devices 120, for example televisions, each of which may be associated with a local player 124, such as a Chromecast device. The local player 124 can be connected to the output device 120 via an HDMI port. Power may be supplied to the local player 124 through a USB port associated with the output device 120. The USB port may be one that supplies power when the output device 120 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 124 through other means. For example, the local player 124 can be connected to a wall outlet. Alternatively, or in addition, the local player 124 may reside within the output device 120. That is, the output device 120 may include the functionality of the local player 124. In accordance with embodiments of the present disclosure, the local player 124 may be connected to the SNC 108 through a second, communication network 128 which may be hidden. The second communication network 128 may be provided by the same or a different access point 116 as is used to provide the first communication network 112.
[0028] The SNC 108 may perform registration functions with respect to devices, including but not limited to, mobile devices 104, output devices 120, and local players 124. More specifically, the SNC 108 may maintain a table of information identifying such devices 104, 120 and 124, and associations between such devices. Moreover, upon the completion of registration, the SNC 108 may pair a mobile device 104 to a local player 124 and an associated output device 120, enabling the mobile device 104 to deliver content to the local player 124, and to have that content output through the output device 120.
[0029] A system 100 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 120. For example, a local premises or hotel head end system 130 may be provided that includes the SNC 108 and a local area network switch, router, and/or Internet access core 132, 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) 136 can be provided as part of the head end system 130 for controlling and authorizing access to the first wireless network 112 by mobile device 104, or other devices. The head end system 130 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 130 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 120, local players 124, and other devices and services a guest of a hospitality establishment may use. Various other devices may be connected to the head end system 130 via the Internet 140. Examples of such systems include a local player app and asset server 144, a remote communication interface (RCI) server 148, and an information services provider server 152 residing at location 156. Location 156 may be remote from the head end system 130, within the head end system 130, on the hospitality or hotel premises, or distributed between multiple physical locationsincluding where all are resident in the headend 130, or distributed amongst several locations 156. In general, the app and asset server 144 may handle communications with an app running on a local player 124. The RCI server 148 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 120 and a mobile device 104, directly or through a local player 124. The information services provider server 152 may provide information, such as but not limited to, hospitality-related, guest-related, and/or locally-related content to the local player 124 and/or the SNC 108.
[0030] In accordance with at least some embodiments of the present disclosure, pairing between a mobile device 104 and an output device 120 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 120 that is operated in connection with an on-site host provided as part of the head end system 130. For example, a particular implementation of an SNC 108 or an additional head end server, which is operable to provide on-demand or other programming and interactive television functions via an output device 120, 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 104 of the user and the output device 120, the head end system 130 makes a request for a pairing code that is created by a web service call to the RCI server 148. The information sent to the RCI server 148 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 148 to the head end system 130, which displays it to the guest via the television (i.e., the output device 120).
[0031] The displayed code is then entered by the guest into a connectivity app that is running on the mobile device 104 that provides connectivity to the RCI server 148. More particularly, the connectivity app on the user device 104 transmits the code along with the IP/MAC address information needed for association of the mobile device 104 with the output device 120 and the associated local player 124 by the SNC server 108. The mobile device 104 is then registered with the SNC server 108, including an association between the mobile device 104 and the output device 120. Alternatively, or in addition, the SNC server 108 may use the room number and IP/MAC address of the mobile device 104 to create a pairing between the local player 124 in the guest room and the mobile device 104. The pairing is dissolved when the head end system 130 receives a checkout message from the site's property management system (PMS). That is, when the checkout message is received, the head end system 130 may make a web service call to the SNC server 108 to dissolve all device pairings in a room. If a PMS system is not sending messages to the head end system 130, the head end system 130 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.
[0032] 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 130. Instead, pairing can be performed in connection with an application running on a local player 124 interacting with the RCI server 148.
[0033] The app on the local player 124 can be launched via a command from the SNC server 108 when the SNC server 108 detects that a local player 124 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 108 to get information regarding in what room and site it is installed. The information from the local SNC server 108 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 144, the information services provider server 152, the SNC 108, and/or another server providing or otherwise serving an app to the local player 124. The app running on the local player 124 then communicates, via a web service call for example, with the RCI server 148 to generate a pairing code. The information sent to the RCI server 148 to generate the pairing code includes a site identifier and room number where the code was requested from. The RCI server 148 generates the pairing code and returns it to the local player app.
[0034] The local player app then displays the received pairing code on the output device 120 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 104. The connectivity app transmits the pairing code entered by the user, along with the IP/MAC address information needed to allow the SNC server 108 to associate the mobile device 104 with the local player 124 to the RCI server 148. The RCI server 148 makes a web service call to the SNC server 108, passing the information from the mobile device 104 to the SNC server 108. The SNC server 108 uses the room number and IP/MAC address of the mobile device 104 to create a pairing between the local player or players 124 in the guest room and their mobile device 104. Optionally, the app running on the local player 124 can continue to display the pairing code after a mobile device 104 has been paired, to enable other devices 104 to be paired to the local player or players 124. In addition, the app running on the local player 124 can provide an indication to the user that pairing has been successfully completed.
[0035] A flag can be set in the SNC server 108 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.
[0036] In accordance with other embodiments of the present disclosure, pairings can be completed in association with an app running on a mobile device 104 that is not associated with the head end system 130 or the RCI server 148. That is, a third-party app running on the mobile device 104 can be configured to provide necessary information to the RCI server 148 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 148 makes a web service call to the SNC server 108, passing the information from the mobile device 104 to the SNC server 108. The SNC server 108 uses the room number and IP/MAC address of the mobile device 104 to create a pairing between the local player 124 in the guest room and the mobile device 104. 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 120 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 148. The RCI server 148 makes a web service call to the site's SNC server 108 passing the room number information. The SNC server 108 uses the room number to cancel all pairing associations between a room and all user devices 104 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.
[0037] 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 136, that system is aware of the user device's 104 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 136 sends site identifier, room number, and guest device Wi-Fi IP and/or MAC address to the RCI server 148, via a web service call/API. The RCI server 148 in turn makes a web service call to the correct site's SNC server 108, passing the information about the guest's device 104 from the GIA server 136 to the SNC server 108. The SNC server 108 uses the room number and IP/MAC address of the user device 104 to create a pairing between the local player 124 in the guest room and the user device 104. In addition to providing convenient pairing of a user device 104 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 120.
[0038] A user device 104 association with a room can be provided to the RCI server 148 by the GIA system 136 upon guest checkout or dissolution of a user device's 104 association with a room. The RCI server 148 makes a web service call to the SNC server 108 for the site, passing the room number information. The SNC server 108 uses the room number to cancel all pairing associations between the room and user devices 104 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.
[0039] 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 108 detects that a local player 124 is being powered on, to determine if there are any user devices 104 currently assigned to that room. Information regarding such user devices 104 returned by the GIA system 136 can be used by the SNC server 108 to match the user devices 104, by room number, to the appropriate local player or players 124. This polling could be performed periodically, for example where local players 124 are powered on continuously. Pairings can be dissolved when validation checks, for example performed when a local player 124 boots up, determine that a formerly valid user device 104 is no longer associated with the GIA system 136.
[0040] In accordance with at least some embodiments of the present disclosure, the SNC server 108 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 120. 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 108 can include a field identifying, for each local player 124, 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 104, or to implement protocols to charge a fee before casting can be initiated.
[0041] In accordance with still further embodiments of the present disclosure, the system 100 can implement app blocking. In particular, the system 100 can control or limit the apps that can be run in connection with a pairing between a user device 104 and a local player 124. 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 104 to launch those apps. This prevents the user from changing the local player 124 settings, or from running potentially unfriendly apps. In accordance with at least some embodiments, blocking can be implemented by having the SNC 108 block the ability to send web calls to the local player 124 via a specific TCP port on the local player 124 that is used by a configuration app. In addition, or alternatively, white lists, black lists, and the like can be used.
[0042]
[0043]
[0044] The default or welcome display 304 may include local information 324 that is local to the hospitality services provider. For example, the local information 324 may include, but is not limited to, weather information. The local information 324 may be provided from the SNC 108, the information services provider 152, the application and asset server 144, and/or another server accessible to the SNC 108 and/or local player 124. As previously discussed, the guest information may include a guest schedule 332 and the guest schedule 332 may include information provided from the SNC 108, the information services provider 152, the application and asset server 144, and/or another server accessible to the SNC and/or local player 124. The guest schedule 332 may additionally include information obtained from or provided by the user device 104. For example, the user device 104 may grant access to the information services provider server 152 for example. Calendar events, contacts, and other information may then be requested by the local player 124 via a web services call such that the local play 124 can assemble and then display such information at the output device 120. In some instances, the schedule 332 may include links, such as a link 336 that provides additional information associated with one or more information content pieces within the schedule 332. Importantly, the default or welcome display 304 is launched and displayed on the output device 120 with no guest interaction. That is, when the local player 124 is not in use and/or when the local player 124 is powered on, the default or welcome display 304 is displayed at the output device 120.
[0045]
[0046] The OTT/local player 124 may then receive such information from the application and asset server 144, the information services provider server 152, and/or the SNC 108 at steps 428 and 432 and assemble and render the resulting default or welcome display to the output device 120 at step 436. Noticeably absent from the flow messaging diagram of
[0047]
[0048] At step 520, the OTT/local player 124 receives the application list and then stores the application list at step 524. The application list may be stored locally at the OTT/local player 124, at the SNC 108 as depicted in
[0049]
[0050] At step 528, the OTT/local player 124 may assemble and render content to be displayed at the output device 120 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 548 and 532 may be performed multiple times.
[0051] At step 536, and at the completion of the currently running app, the OTT/local player 124 may message the SNC 108 to indicate that the current app has completed and the next app in the list should be executed. Accordingly, at step 540, the SNC 108 may message the OTT/local player 124 with the next application identifier in the application list. Thus, the process may repeat at step 504 until all applications in the list have been executed and/or have completed execution.
[0052]
[0053] The component 612 may be the programing instructions which execute the functionality of the app 604. In some instances, the app 616 may include instructions to update the previously mentioned application list based on one or more conditions encountered when executing the app 604. 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 620 may be an exit procedure. Similar to the entrance procedure 608, the OTT/local player 124 may communicate with one or more sources of information, for example the SNC 108, the application and asset server 144, and/or the information services provider server 152 to indicate that the app 604 has finished execution. Accordingly, if another app is to be executed without user interaction, at least one of the SNC 108, the application and asset server 144, and/or the information services provider server 152 may provide the next app in the application list, via an application identifier, to the OTT/local player 124 to execute such app.
[0054]
[0055] The SNC 108 can also include data storage 712. In accordance with embodiments of the present invention, data storage 712 can contain program code or instructions implementing various applications or functions executed by the SNC server 108. Like the memory 708, the data storage 712 can comprise a solid-state memory device. In addition, in certain applications, the data storage 712 can be integrated with and/or indistinguishable from the memory 708. Alternatively, or in addition, the data storage 712 may comprise a hard disk drive or other random access memory and/or can be interconnected to the communication server 112, for example as network-attached storage. Programming or modules stored in the data storage 712 and executed by the processor 704 can include, as examples and without limitation, various pairing rules 720, various OTT/local player configurations 724, and/or one or more application lists 716. For example, the OTT/local player configurations 724 may include mapping information associating one or more OTT/local players 124 to one or more specific apps or URLs, such as the welcome screen 304.
[0056] The SNC server 108 may also include one or more communication interfaces 728A-B. For example, a first communication interface 728A can provide a connection to the first communication network 116 or guest virtual local area network (VLAN); a second communication interface 728B can provide a connection to a device network, such as the second communication network 128 or the device VLAN.
[0057]
[0058]
[0059] As further depicted in
[0060]
[0061]
[0062] As further depicted in
[0063]
[0064]
[0065] As further depicted in
[0066] As depicted in
[0067] Further still, if the user selects a tile 1220-1232, for example 1232, the application responsible for display 1216 may exit and the application responsible for display 1236 may be entered/initiated. For example, the application responsible for displaying the display 1216 may be added to an application list 924 and a new application may be initiated by the SNC 108 for example, and executed by the local player 124. As an example, a new application may be initiated, executed, and a different display, such as display 1236, may be provided to the output device 120 and thus the user. One or more entrance and exit procedures may be performed; for example, when entering the application responsible for display 1236, the application identifier for the application responsible for display 1216 may be provided to the SNC 108 in an exit procedure and an application identifier for the application responsible for display 1236 may be provided to the SNC 108 in an entrance procedure. As further depicted in
[0068] 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.