Dual network casting system

Abstract

Generally described, one or more aspects of the present application relate to providing a casting server that can pair specific user devices with appropriate corresponding casting devices and control network communications between user devices and casting devices such that only those casting or display devices that a given user is authorized to access are made visible to the user via the user's device. By doing so, users are prevented from accessing or casting their content to other casting and display devices to which they may not have access, such as those in other users' rooms.

Description

Background Art

[0001] Casting devices enable users to stream content from their mobile devices or computers onto a larger screen such as a TV. Using these devices, users can easily watch their favorite TV shows, movies, or other content on a larger display without the need to physically connect their devices to the TV. Thus, casting devices provide a convenient and flexible way to enjoy entertainment on a larger screen.

Summary of the Invention

Means for Solving the Problems

[0002] The embodiments described herein are illustrated by way of example, and not as limitations, in the figures of the accompanying drawings in which like reference numerals refer to similar elements. The present invention provides, for example, the following items: (Item 1) A casting system, wherein the casting system is Display devices and, A casting device configured to access content and to cast the accessed content onto the display device, Casting servers equipped with computer hardware and Equipped with, The casting server communicates with the casting device via the cast network, and the casting server communicates with the guest device via a guest network separate from the cast network. The aforementioned casting server, The system receives location information associated with the guest device and the MAC address associated with the guest device. Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, Generating packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to cast the requested content onto the display device that communicates with the casting device. A casting system configured to perform the following actions. (Item 2) A system of any item provided in the claims or any combination of two or more items provided in the claims, wherein the casting device is configured to download the requested content without passing network traffic to the casting server, so that the download of the requested content does not impose any additional network load on the casting server. (Item 3) A system of any item provided in the claims or any combination of two or more items provided in the claims, wherein, upon receiving a multicast DNS packet from the guest device, the casting server is configured to falsify a response from the casting device without forwarding the multicast DNS packet to the casting device. (Item 4) The casting server is further configured to output a captive portal to the guest device, and the system comprises any item provided in the claims or any combination of two or more items provided in the claims. (Item 5) A system of any item provided in the claims or any combination of two or more items provided in the claims, wherein the casting server is configured to respond to multicast DNS requests from guest devices by returning different proxy IP addresses to represent different casting devices. (Item 6) The casting server is configured to remove the pairing in response to a request to remove the pairing received from the cloud service, and is a system of any item provided in the claims or any combination of two or more items provided in the claims. (Item 7) A system of any item provided in the claims or any combination of two or more items provided in the claims, wherein the packet forwarding rules are stored in random access memory (RAM), and in response to the removal of the pairing, the packet forwarding rules are removed from the RAM. (Item 8) A proxy ARP is a system of any item provided in the claims or any combination of two or more items provided in the claims, configured to force packets from the guest device or the casting device to pass through to the casting server instead of the default gateway of the local network associated with the guest device or the casting device. (Item 9) A system of any item provided in the claims or any combination of two or more items provided in the claims, wherein the casting server is further configured to receive an ARP request associated with an IP address from the guest device and to respond by returning the MAC address associated with the casting server. (Item 10) A casting method, wherein the method is Receiving location information associated with the guest device and the MAC address associated with the guest device, Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, Generating packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to a display device that communicates with the casting device in order to cast the requested content onto the display device. Methods that include... (Item 11) A method of any item provided in the claims or any combination of two or more items provided in the claims, further comprising downloading the requested content without passing network traffic through the casting server, such that the download of the requested content does not impose any additional network load on the casting server. (Item 12) A method of any item provided in the claims or any combination of two or more items provided in the claims, further comprising receiving a multicast DNS packet from the guest device and falsifying a response from the casting device without forwarding the multicast DNS packet to the casting device. (Item 13) A non-transient computer storage medium storing computer executable instructions, wherein the computer executable instructions are executed by one or more computing devices. Receiving location information associated with the guest device and the MAC address associated with the guest device, Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, Generating packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to a display device that communicates with the casting device in order to cast the requested content onto the display device. A non-transient computer storage medium that causes one or more computing devices to perform an operation including the above. (Item 14) Non-transient computer storage medium of any item provided in the claims or any combination of two or more items provided in the claims, wherein the operation further includes downloading the requested content without passing network traffic to the casting server, such that the download of the requested content does not impose any additional network load on the casting server. (Item 15) The operation further comprises responding to multicast DNS requests from a guest device by returning different proxy IP addresses to represent different casting devices, for any item provided in the claims or any combination of two or more items provided in the claims, on a non-transient computer storage medium. [Brief explanation of the drawing]

[0003] [Figure 1] Figure 1 illustrates the implementation of the network according to the aspects of this disclosure.

[0004] [Figure 2] Figure 2 illustrates cross-sections of various access points in the context of a multi-unit living space (MDU) according to the aspects of this disclosure.

[0005] [Figure 3] Figure 3 illustrates a network environment including a casting server for controlling user access to casting devices and display devices as described in this disclosure.

[0006] [Figure 4] Figure 4 illustrates a network environment that includes a separate casting server for controlling user access to the casting device and display device as described in this disclosure.

[0007] [Figure 5]Figure 5 illustrates a typical architecture of a computing device or system that provides casting management services according to the aspects of this disclosure.

[0008] [Figure 6] Figure 6 illustrates a network environment that includes a separate casting server for controlling user access to the casting and display devices according to the aspects of this disclosure.

[0009] [Figure 7] Figure 7 illustrates how the casting server may operate according to the aspects of this disclosure.

[0010] [Figure 8] Figure 8 illustrates how a guest may interact with a casting server to connect a user device to a casting device, according to an aspect of this disclosure.

[0011] [Figure 9] Figure 9 illustrates how a casting server, according to the aspects of this disclosure, can create rules and pair devices.

[0012] [Figure 10] Figure 10 illustrates how pairings can be created and removed according to the aspects of this disclosure.

[0013] [Figure 11] Figure 11 illustrates a network environment including a proxy ARP configured to control user access according to the aspects of this disclosure.

[0014] [Figure 12] Figure 12 illustrates a network environment including a default gateway configured to implement client isolation as described in this disclosure. [Modes for carrying out the invention]

[0015] (Introduction) Typically, casting devices such as Google Chromecast® and Apple TV® are designed to be on the user's home Wi-Fi network, and all user devices expected to use them are expected to be on the same Wi-Fi network. In such home scenarios, the user of the casting device (as used herein to also refer to the user's user computing devices, such as smartphones, laptops, and tablets) is expected to be on the same Wi-Fi network as the casting device itself.

[0016] However, in hospitality settings such as hotels, connecting all guests to the same Wi-Fi network as any casting devices available to them would mean that all guest devices could see all casting devices connected to the Wi-Fi network, potentially allowing them to hijack another guest's TV in another hotel room.

[0017] These and other issues can be addressed according to embodiments of the present disclosure, in which the casting device and user computing devices (also referred to herein as guest devices) that access the casting device are connected to separate wireless networks, and network communication between the user computing devices and the casting device is facilitated by a casting server connected to both wireless networks. By keeping the casting device on a separate network from guest devices from which casting can be initiated, the discoverability issues described above can be addressed without requiring the setup of separate wireless networks for each room or unit, or for each casting device, or for each set of casting devices in such a unit, as is typically done in a home environment.

[0018] By pairing a specific user device with an appropriate corresponding casting device and using a casting server capable of controlling network communication between the user device and the casting device, only casting devices or display devices that the user is permitted to access are visible to the user through the user's device, and the user is prevented from accessing or casting their content to other casting and display devices in other users' rooms.

[0019] These and other aspects of the Disclosure will be described herein in relation to examples and implementations intended for illustration, rather than limiting the Disclosure. While the examples and implementations described herein will focus on specific computations and algorithms for illustrative purposes, those skilled in the art will understand that the examples are for illustrative purposes only and not intended to be limiting.

[0020] (Network access system) Figure 1 illustrates an implementation of a network access system that may be used to implement one or more of the techniques described herein. The system includes various user devices 141, 143, 145, 147, 149, 151, 153, and 155. User devices may include, for example, laptops, desktop computers, smartphones, PDAs, and any other wired or wireless network-enabled communication devices. User devices 141, 143, 145, 147, 149, 151, 153, and 155 communicate with access points 121, 123, 125, 127, and 129. Access points 121, 123, 125, 127, and 129 provide wired or wireless communication with a network management device 103. The network management device 103 controls network communication between access points and between access points and the network 101. In some implementations, the network management device 103 is operated by a single entity. In one implementation, the network management device 103 creates a single network. Optionally, intermediate network devices 105, including, for example, routers, switches, hubs, and repeaters, may also be used to assist in providing communication between access points 121, 123, 125, and 127 and the network management device 103. The network 101 may be, for example, a public network such as the Internet. The network management device 103 (also referred to herein as the network management system) may include a network gateway, such as a network access gateway commercially available from, for example, Nomadix, Inc. (Woodland Hills, CA). Other network management devices may also be used, as will be understood by those skilled in the art from this disclosure.

[0021] Devices are generally programmed to automatically select between access points, for example, by determining which access point provides the strongest signal. A device may be between three different access points and capable of communicating with all of them, but ultimately select one access point to communicate with. In some cases, an access point may not allow a device to communicate through it, in which case the user device may attempt to communicate with another access point. For example, a user device may have the strongest signal with access point A, but can only be authenticated with access point B. In this case, the user device may communicate with access point B despite the weaker signal. As will be understood, a user device can be configured to select an access point based on any number of different selection options, including, for example, signal strength, bandwidth availability, access rights, and access points corresponding to a specific SSID. When an access point is out of range, the user device may no longer be able to communicate with it and may attempt to find another access point. In some implementations, switching between access points is seamless, for example, without any loss of network session, and the user may not even be aware that they have switched access points.

[0022] As illustrated in Figure 1, the network includes multiple physical areas, including the apartment lobby 107, the apartment business center 109, and the apartment unit 111. Although not shown in Figure 1, the network may include additional apartment lobbies, apartment business centers, and / or apartment units. Each physical area may include one or more access points. In some cases, two or more physical areas may share a single access point.

[0023] In some implementations, access points advertise their presence by broadcasting service set identifiers (SSIDs), extended service set identifiers (ESSIDs), and / or basic service set identifiers (BSSIDs), etc., collectively referred to herein as SSIDs. In some implementations, the same SSID is assigned to all access points in the network. In other implementations, different SSIDs are assigned to each access point or group of access points (or each area or group of areas) in the network. In yet another implementation, multiple SSIDs can be assigned to the same set of access points. In this regard, virtual SSIDs can be configured to correspond to different groupings of access points. The network management device 103 may provide different levels of service to different users across multiple SSIDs or across the same SSID based on the user's pre-shared key (e.g., Wi-Fi password) and / or on permanent and / or non-permanent identifiers associated with the user's user device, such as the MAC address and / or the user profile (or one or more parameters contained in the user profile) stored on the user device. While MAC addresses are used as exemplary identifiers to describe one or more embodiments of the Disclosure (for example, in the context of creating pairings that provide customized services), in other embodiments, IP addresses or other permanent or non-permanent identifiers may be used instead. Similarly, while IP addresses are used as exemplary identifiers to describe one or more embodiments of the Disclosure, in other embodiments, MAC addresses or other permanent or non-permanent identifiers may be used instead.

[0024] (Mass Living Unit (MDU)) Figure 2 illustrates cross-sections of various access points in the context of an MDU. Dormitory 201 includes rooms 203, a conference room 205, a restaurant 207, and a lobby 209. Rooms 203, conference room 205, restaurant 207, and lobby 209 include various access points 221. While each room is illustrated as having one or more access points, it should be understood that fewer or more access points may be used. For example, in one implementation, a single access point may be used for multiple rooms. Also, as will be understood by those skilled in the art, many different types of facilities may benefit from this disclosure. For example, although primarily described in relation to dormitories, other facilities including apartment buildings, schools, colleges, universities, hospitals, hotels, government buildings, corporations, or any other public or private networking systems may also use this network management system.

[0025] (Casting management system) Figure 3 illustrates an embodiment of a networking environment 300 including a casting server 302. The casting server 302 is part of the guest network 304 and the cast network 306. The casting server, connected to both the guest network and the cast network, can provide a protected or controlled connection between the two networks (for example, between a user device 308 on the guest network (also referred to herein as guest device 308) and a casting device 310 on the cast network).

[0026] In the hotel example, there may be a guest network (e.g., guest network 304) that provides internet access to the guest's mobile device (e.g., user device 308). There may be one or more access points (e.g., AP 314A) that provide the guest network to the guest device. There may be a gateway (e.g., gateway 316A) that provides access to other networks, such as the internet (e.g., internet 318). The gateway may be a captive portal gateway, such as a Nomadix gateway. Thus, once the guest joins the guest network and provides the information and / or payment requested by the hotel, the guest may be able to connect to the internet.

[0027] To deploy casting, a separate wireless network may be created (e.g., cast network 306). The cast network may have a separate wireless SSID different from that of the guest network. For example, all casting devices deployed in a guest bedroom may be instructed to connect to that special cast network SSID. The password for the cast network may not be provided to guests to prevent them from joining the cast network. For example, only the installer of the casting devices may know the password for the cast network. Thus, the cast network may be a secure network that only casting devices are allowed to connect to.

[0028] The cast network may also include a gateway device (e.g., Gateway 316B). This gateway device may be a standard IP gateway and not necessarily a captive portal gateway. For example, this gateway could be a router that provides uninterrupted access to the Internet. When a guest accesses a casting device on the cast network and commands it to stream media onto a display device that communicates with the casting device, the casting device may access the Internet via the gateway and access the media, and IP traffic may flow out through the cast network to a storage location associated with the media (e.g., a cloud storage server, where "cloud" refers to a pool of network-accessible computing resources) and back to the casting device.

[0029] In some embodiments, the guest network and the cast network use two different wireless SSIDs. In other embodiments, the guest network and the cast network use the same wireless SSID. In some embodiments, the gateway device in the guest network is a captive portal gateway device, and the gateway in the cast network is a standard IP gateway device. In other embodiments, both the gateway device in the guest network and the gateway in the cast network are standard IP gateway devices. In yet another embodiment, the gateway device in the guest network and the gateway in the cast network use the same gateway device. In some of these embodiments, the same gateway device is configured in the same way (e.g., both as standard IP gateways, both as captive portal gateways, etc.). In other cases, the same gateway device is configured differently (e.g., the one in the guest network is configured to operate as a captive portal gateway, and the one in the cast network is configured to operate as a standard IP gateway).

[0030] (discovery) When a guest opens a video streaming app on their smartphone, the app may send discovery packets on the guest network to search for casting devices. For example, the app may send multicast DNS requests or queries to search for casting services. Typically, these requests are multicast or broadcast over the Wi-Fi network, and any casting device that happens to be on the network may respond. However, since the guest device is not on the same network as the casting device, in typical circumstances, there may be no response to their mDNS queries.

[0031] Here, software on the casting server may listen for any such discovery requests coming in from the guest device and make a decision on whether to allow the guest device to discover any of the casting devices on the cast network. In some embodiments, this decision is based on whether a pairing exists for the guest device with one or more casting devices on the other side of the network (e.g., on the cast network).

[0032] If such a pairing does not exist, the casting server may simply ignore the packet, and nothing may happen. In such a case, there may be no response to the discovery request, and the guest device will assume that there are no casting devices available to talk to. On the other hand, if such a pairing exists, the casting server may send a response that impersonates a casting device on the cast network, providing an IP address that the guest device is expected to use to talk to the casting device. In some embodiments, this IP address is the actual IP address assigned to the casting device that the casting server is impersonating. In other embodiments, the IP address is a proxy IP generated by the casting server (and is not identical to any actual IP address of the casting device on the cast network). The guest device then uses the IP address to cast content onto a display device (e.g., a TV in the guest's hotel room) that is connected to (or network-communicates with) the casting device.

[0033] (casting) Once a casting device is discovered, the second step is to actually perform the casting. For example, a guest may open a media application on their smartphone, search for any available casting device, and select a casting device that appears in the list of available casting devices (the discovery process described above generates this list). In response to the selection, a TCP connection is formed using the IP address that the smartphone considers to belong to the selected casting device, and any control commands, such as playing or pausing content, may be sent to the IP address. In response, the casting server forwards the packets received from the smartphone to the appropriate casting device on the casting network. In some embodiments, the casting server may do so using Destination Network Address Translation (DNAT). In other embodiments, the casting server may forward packets from one network to another without translation.

[0034] (Creating packet forwarding rules) Once a pairing is created, the casting server may create packet forwarding rules that specify that when a guest device with a particular MAC address attempts to open a TCP connection with this particular proxy IP, the packet may be forwarded to the appropriate casting device using the destination NAT. There may be a flow of incoming packets from the guest network, and the casting server may translate them to different destination IP addresses to casting devices on the cast network. This would allow the guest device to connect to the casting device. In addition, there may be reverse rules that allow traffic to return from the casting device to the guest device. Thus, the casting server may create and / or install bidirectional rules for packet forwarding that enable that type of TCP connection. In addition, the casting server may discard rules when they are no longer needed (e.g., when a given pairing is removed). The casting server may indicate to the mDNS handler that a pairing exists, thereby allowing the mDNS handler to know whether or not it should respond to mDNS queries from the guest device.

[0035] (Establishment of a control connection (TCP)) A casting device may have a special receiving application for downloading content to be cast onto a display device. Such a receiving application may be registered with the casting device by the content creator so that the casting device is shipped with the receiving application, or so that the receiving application can be downloaded onto the casting device. Once a control connection (e.g., TCP) is established between the guest device and the casting device via a casting server, the guest may provide control commands, such as playing or pausing content, via the TCP connection. Upon request, the receiving application on the casting device may fetch the requested content without requiring an internet connection and the content to be streamed from the guest device.

[0036] (Installation of casting device) In addition, the casting server may facilitate the installation of casting devices. When a casting device is installed, it may be placed in a room, and the casting server may detect new casting devices appearing on the cast network that the casting server is not yet aware of. The casting server may then register its casting device with a cloud service (e.g., communicating with the casting server 302 via the internet 318), the cloud service is configured to permanently store the pairing information so that the pairing information can be redownloaded onto the casting server after the casting server is reset or restarted. Furthermore, the casting server may periodically send reports to the cloud service (e.g., a current list of casting devices that are online), the cloud service may analyze the reports and flag any problems (e.g., if a casting device that is expected to be on the list is missing, or if a casting device that is not recognized by the cloud service is on the list). When a casting device is not recognized by the casting server or cloud service, the casting server may send a command to the casting device to display information that can be used by the installer on a display device connected to the casting device. This information may include a QR code® or link that the installer can use to link the casting device to a specific room number or location. Once the location of the unrecognized casting device is identified, the casting server may enter the casting device into the records and configure the casting device for future use (for example, to display pairing instructions for future guests on the casting device).

[0037] (Packet handling using rules) In some embodiments, a casting server may read packets from a network connection on a guest network and output the same packets onto a cast network, and the casting server software is an application launched outside the operating system. In some cases, such an approach may be overly CPU-intensive and may not scale as well. In other embodiments, packet forwarding rules are installed on the casting server's operating system (e.g., Linux®), and operating system-level packet forwarding rules are used instead to control which packets are forwarded from one network to the other. Here, the casting server may not route anything by default. If a packet is received by the casting server and there are no specific rules to allow the packet to be transmitted to the other side, the packet may simply be dropped. To prevent this, a packet forwarding rule may be installed within the packet forwarding engine that stipulates that a guest device X can talk to a casting device Y on the other network, which would allow packets from guest device X to flow to and back to casting device Y.

[0038] (OS packet forwarding rules and improved scaling) In some embodiments, using operating system packet forwarding rules does not reduce the amount of traffic to and from guest devices and casting devices through the casting server, but because packet forwarding rules are configured to direct packets to appropriate destinations rather than requiring reliance on casting server software to process them, packets do not need to leave the operating system; they are received by the casting server network interface, processed by the operating system, transmitted through the casting server network interface, bypassing the casting server software and eliminating the need to remember packets that should be read by the casting server software (thus reducing the amount of data duplication). For example, packet forwarding rules can stipulate whether a given guest device is allowed to communicate with a given casting device (or vice versa), and if the operating system decides that such communication is allowed, the IP address is translated and the packet is propagated to the receiving end; otherwise, the packet is dropped.

[0039] (Multicast DNS response) In some embodiments, when a casting server receives a multicast DNS packet, it will forward the packet to a casting device. In other embodiments, the casting server will not forward any mDNS queries, but instead will spoof responses from the casting device without actually forwarding the mDNS queries to the casting device (for example, by caching responses from the casting device). For example, given an mDNS query, the casting server may determine whether a guest device is paired with a casting device, and then the casting server may spoof responses only from that particular paired casting device.

[0040] (Pairing process) When a guest checks into their room and turns on the TV (if it's not already on), they may see a welcome screen with a casting instruction. This may include a QR code, which, upon activation, will cause the guest's smartphone to contact the casting server via the guest network (or the internet). The casting server captures the guest's IP address and / or MAC address and creates and stores a pairing between the guest's smartphone and one or more casting devices in the guest's room (e.g., in the cloud or local storage). Once the pairing is created, the casting server may create one or more packet forwarding rules to allow mDNS discovery to occur for the guest's smartphone. In some embodiments, in response to receiving a new pairing from the casting server, the cloud service may check whether the new pairing already exists in the current pairings and, if so, reject the request to add the pairing. If the new pairing does not currently exist, the cloud service may instruct the casting server to create a packet forwarding rule for the pairing and enable mDNS discovery for the pairing.

[0041] (A room with multiple casting devices) Larger hotels may have suites that have multiple casting devices and / or display devices. Once a pairing is made with one of such casting devices, the casting server may determine that the guest device should also be paired with other casting devices in the same room / unit / suite and, accordingly, create additional pairings. Multiple proxy IP addresses (e.g., proxy IP 302A) would allow a guest to distinguish between multiple casting devices they have access to within their own room and specify which casting device the guest wishes to use.

[0042] (Removing pairing) When a pairing should be removed, the casting server simply removes the packet forwarding rule. For example, a table of rules (which could be a whitelist of packets, or source and destination pairs that are allowed to pass through) is maintained in storage accessible by the casting server. If a packet arrives and there is no whitelist rule for it, the packet is dropped. To remove a pairing, an administrator may send a message from the cloud system to the casting server to remove this pairing. The casting server may then remove the rule that allowed forwarding between this guest device where the pairing was created and the casting device. Pairings may be removed when the guest checks out or according to a schedule (for example, at 1 p.m. every day).

[0043] (Automatic pairing) In some embodiments, when a guest wishes to connect to a Wi-Fi network, the guest is directed to a captive portal system on the guest network. Once the captive portal system learns the guest's location (e.g., room 105), it may transmit that information to a casting server, which can then automatically create a pairing, enabling the guest's mobile device to connect to a casting device in the guest's room. In such a case, when the guest turns on the TV, instead of a pairing command (e.g., with a QR code®), other content and / or an indication that a pairing has been created may be displayed.

[0044] (Alternative approach) Figure 4 shows an alternative embodiment in which proxy ARP and proxy MAC addresses are used by the casting server. In some embodiments, the guest network and the cast network may have completely different IP subnets. In the embodiment shown in Figure 4, the cast side of the network may be a subset of the entire network address range of the guest side of the network. For example, if the guest network has the IP range 10.2.0.0, it would be a 16-bit netmask. Here, about half of the addresses in that address space may be allocated to guest devices, and the other half may be allocated to the cast side of the network. Thus, apart from the casting server, to an external observer it may appear as if the casting device and guest devices are part of the same network.

[0045] (Proxy ARP) The example in Figure 4 may use a technique called proxy ARP, which means that when a device on one side of a network wants to communicate with another device on the other side of the network, the device may need to figure out how to address one of those IP addresses on the other side. The guest device may send an ARP request requesting the MAC address of a computer on the network that has a particular IP address, and usually, if there is no casting server, the casting device will respond directly, indicating that the casting device has that IP address and providing the casting device's MAC address, after which the two computers will be able to communicate directly.

[0046] However, once a casting server is introduced, it can become an obstacle, as it may return its own MAC address. If a guest device requests the MAC address of a casting device with which it can communicate, the guest device may receive a response from the casting server containing the casting server's MAC address (instead of the MAC address of any casting device). Thus, all communication destined for any device on the cast side of the network is effectively sent through the casting server. Proxy ARP can be used to force any traffic configured to reach a computer on the other side of the network (e.g., a casting device) to go through the casting server (proxy ARP can do the same with respect to traffic in the reverse direction). Now, when a casting device wants to communicate with a guest device, the casting device makes an ARP request, and the casting device is provided with the server's cast-side MAC address, which forces any traffic the casting device has for the guest side of the network to go through the casting server.

[0047] (Differences between requirements) When a guest device sends a request to cast to a TV in the living room and another request to cast to a TV in the bedroom, the two requests may have the same guest-side MAC address but two different IP addresses for the respective casting devices connected to the two TVs. In some embodiments, a proxy IP is used to communicate with the different casting devices. In other embodiments, the actual IP is used to communicate with the different casting devices (using a proxy MAC). For example, a proxy IP may be reused for each room in a hotel, and requests sent to the same proxy IP address from two different guest devices in two different rooms may be routed to two different casting devices.

[0048] (Sending discovery packets to multiple guest devices) In some embodiments, discovery occurs directly between the guest device and the casting server, and discovery packets are not allowed to flow to the other side through the casting server. In other embodiments, discovery requests are passed to the other side through the casting server, and the casting device can respond. The casting server can then determine, based on pairing, whether the response should be allowed to reach the guest device and return. If one guest device attempts to discover a casting device in the room, the casting server may send discovery responses to all guest devices in the same room, thereby allowing all guest devices to access all casting devices, making the room appear as a small network where everything in the room can see everything else.

[0049] For example, if a guest has a smartphone and a tablet in their hotel room, and the guest opens a streaming application and searches for a casting device to connect to, a discovery packet from an available casting device may be sent to the smartphone, indicating that the casting device is available for casting. In addition, the discovery packet may also be sent to the guest's tablet (assuming the guest's tablet is already paired with the casting device and is currently turned on), essentially letting the tablet know that the casting device is available for casting. For example, if the guest's tablet is turned off, the discovery packet cannot be transmitted. The local AP will receive the discovery packet, but the AP will determine that no device is listening on the MAC address associated with the guest's tablet. If the guest's tablet is turned on, the tablet may store (for example, in a cache) the information contained in the discovery packet (e.g., information about casting devices available for use), so that when the guest later wants to cast content onto one of the casting devices, the cached information about the available casting devices can be used. The mobile application will allow them to be quickly deployed for guest selection via the tablet. In addition, the tablet may automatically transmit another discovery request to the casting server to obtain an updated list of casting devices available for use.

[0050] In some embodiments, the casting server may periodically check all pairings and notify each paired guest device of a list of all casting devices available to that paired guest device. For example, in some cases, multicast DNS queries may be blocked by the network for security reasons. In such cases, the guest device would obtain information about available casting devices through such periodic notifications from the casting server.

[0051] (Example architecture of a casting server) Figure 5 depicts an exemplary architecture of a computing system (referred to as the casting server 500) that may be used to implement one or more of the techniques described herein or illustrated in Figures 1-4 and 6-12. The general architecture of the casting server 500 depicted in Figure 5 includes an arrangement of computer hardware and software modules that may be used to implement one or more aspects of this disclosure. The casting server 500 may include more (or fewer) elements than those shown in Figure 5. However, it is not necessary to show all of these elements in order to provide a practical level of disclosure. As illustrated, the casting server 500 includes a processor 190, a network interface 192, and a computer-readable medium 194, all of which may communicate with each other using a communication bus. The network interface 192 may provide connectivity to one or more networks or computing systems. The processor 190 may therefore receive information and instructions from other computing systems or services via one or more of the networks shown in Figures 3 and 4.

[0052] The processor 190 may also communicate with the memory 180. The memory 180 may contain computer program instructions (grouped as modules in some embodiments) that the processor 190 executes to implement one or more aspects of the present disclosure. The memory 180 may contain RAM, ROM, and / or other persistent, auxiliary, or non-transient computer-readable media. The memory 180 may store an operating system 184 that provides computer program instructions for use by the processor 190 in the general management and operation of the casting server 500. The memory 180 may further contain computer program instructions and other information for implementing one or more aspects of the present disclosure. For example, in one embodiment, the memory 180 includes a user interface module 182 that generates a user interface (and / or instructions for it) for display on a user computing device (e.g., user computing device 308 in Figure 3) via a navigation and / or browsing interface such as a browser or application installed on the user computing device. In addition, the memory 180 may contain (or communicate with) one or more data stores.

[0053] In addition to the user interface module 182, and / or in combination therewith, the memory 180 may include a casting management module 186 which can be executed by the processor 190. In one embodiment, the casting management module 186 implements various aspects of the present disclosure, for example, those illustrated in or described with reference to Figures 1-4 and 6-12.

[0054] A single processor, a single network interface, a single computer-readable medium, and a single memory are illustrated in the example in Figure 5, but in other implementations, the casting server 500 may have one or more of these components (e.g., two or more processors and / or two or more memories).

[0055] (Client isolation) A network may implement client isolation (e.g., L2 client isolation), which means that if a wireless network has multiple guest devices, the guest devices are not allowed to talk to each other, and the network blocks or drops any packets sent directly between them. In such cases, guest devices may only be allowed to communicate with the default gateway.

[0056] (Whitelist) The network may also maintain a whitelist that would allow guest devices to communicate directly with any device on the whitelist other than the default gateway. In the context of casting, a casting server, implemented separately from the gateway, can be added to the whitelist so that guest devices can communicate directly with the casting server.

[0057] (Default gateway) When a guest device joins the network, it can issue a DHCP request indicating that it needs an IP address, and the network responds with a DHCP offer, providing an IP address. The guest device can then accept an IP address in another DHCP request, and the network responds with a DHCP ACK. The network also informs the guest device of the DNS server and default gateway.

[0058] (Casting solutions without a whitelist) To support casting on a certain type of wireless network, the default gateway (e.g., a captive portal gateway) may also function as the casting service gateway. This may be applicable when the network is configured to enforce client isolation, preventing guest devices from communicating only with their default gateway and not with any other devices connected to the network. An example is shown in Figure 6, which includes a network 601, a guest device 602, an access point 604, a switch 606, a firewall / router 608, a captive portal gateway / casting server 612, and the internet 614. As shown in Figure 6, the default gateway (e.g., a captive portal gateway) also functions as the casting service gateway, and vice versa.

[0059] As a result, the default gateway may be configured to respond to mDNS queries from guest devices and facilitate bridging or routing of control connections between the guest and Chromecast® or other casting devices.

[0060] In some cases, a network may be configured to block multicast mDNS messages from guest devices attempting to discover available casting devices and / or services. In such cases, in some implementations, the only way for a guest device to discover available casting devices and / or services may be for it to passively listen for periodic notices issued by the casting devices and / or services.

[0061] In some embodiments, the casting services and techniques described herein can be integrated into the same server as that of the gateway (e.g., a captive portal gateway). In other embodiments, it may be difficult to integrate such casting services and techniques into the same server as the gateway (e.g., a Nomadix service engine or NSE). In some of such embodiments, bridging or routing features can be integrated into the gateway (e.g., using a firmware update on the gateway device), and these bridging or routing features may enable a separate casting server (e.g., a casting server separate from the gateway) to receive and process casting traffic from subscribers permitted to connect to the network (e.g., via a virtual LAN or VLAN).

[0062] On the subscriber side of the gateway, the gateway can be configured to recognize one or more IP addresses as providing casting services. These IP addresses may be from the subscriber VLAN (i.e., the same subnet) or on a different subnet to which the gateway can route traffic.

[0063] When a guest device on a subscriber VLAN sends traffic to one of the configured casting IP addresses (also referred to herein as casting IPs), the gateway may bridge or route those packets to a casting server directly connected to the gateway on an Ethernet® port (or, alternatively, to a casting server connected via another intermediary device such as a switch or a cluster of switches).

[0064] In such an embodiment, the gateway may respond to ARP requests (e.g., from a guest device) for a casting IP address and provide its own MAC (e.g., the NSE MAC shown below) in the response packet.

[0065] Casting packets from a guest device can be structured as follows: L2: src=guestMAC, dst=NSEMAC L3: src=guest IP, dst=casting IP L4: May or may not be considered (e.g., it could be UDP or TCP) Here, L2 refers to Layer 2 of the ISO Networking Model, which is involved in transferring data between adjacent network nodes; L3 refers to Layer 3 of the ISO Networking Model, which is involved in routing data between different networks using IP addresses; and L4 refers to Layer 4 of the ISO Networking Model, which is involved in enabling communication between processes or applications running on different hosts.

[0066] Assuming TCP is used, a guest device would perceive that it has opened a connection to the casting IP address represented (or proxied) by the NSE. Furthermore, assuming that an available Ethernet® port on the NSE is configured as a casting bridge, when traffic to the casting IP address is received by the NSE on a subscriber VLAN, the NSE may retransmit the packet over the casting Ethernet® port (for example, the default gateway reads the destination MAC address and forwards it directly to a specific port to which the MAC address is plugged, e.g., the Ethernet® port to which the casting server is connected).

[0067] Here, packets may have their DST MAC (destination MAC address) changed to that of the casting server. It is assumed that the casting server can accept packets for casting IP. During retransmission, the SRC MAC can be preserved to be that of the guest device. In this way, the guest device can be tracked by its MAC address. Alternatively, it is possible to track it by IP, but IP addresses can change much more frequently than MAC addresses, and therefore tracking the guest device by MAC may be more reliable.

[0068] The retransmitted packets can therefore be structured as follows: L2: src=guest MAC address, dst=casting server MAC address L3: src=guest IP, dst=casting server IP L4: Preserved

[0069] In this example, L3 and above are protected. The NSE may perform ARP for the casting IP on the bridge port to discover the appropriate casting server MAC.

[0070] When a casting server has response traffic to return to a guest device, it may transmit packets structured as follows: L2: src=casting server MAC address, dst=?? (e.g., NSE MAC address or proxy MAC address) L3: src=casting server IP, dst=guest IP L4: Sometimes it is considered, sometimes it is not.

[0071] Here, the DST MAC is typically the result of performing an ARP for the guest IP. In this case, the NSE may respond to these ARP requests by looking up the subscriber IP in its subscriber table to ensure that the subscriber (e.g., the guest device) is known, and then respond with its own MAC. Thus, the NSE can function as a proxy for the subscriber guest device.

[0072] When the NSE receives a packet from the casting server, it can use its subscriber table to look up the guest device's MAC address and, using the stored MAC address, forward the MAC address to the guest device. Layers 3 and above can be preserved.

[0073] As described above, an NSE can be thought of as providing routing services for specific IPs configured as casting IPs. If the IPs are on the same subnet, the NSE may proxy ARP for them. If they are not on the same subnet, the guest device may attempt to route them through their default gateway IP.

[0074] The mechanism described above provides handling of control traffic used for casting (e.g., Chromecast® control traffic). However, means to facilitate casting discovery may also be provided, which may involve the following two components: (1) Receiving mDNS queries from the guest device (2) Sending an unsolicited notification (e.g., a Chromecast® notification) from the casting server to the guest device.

[0075] Regarding (1), the NSE may be configured to listen on UDP port 5353 for mDNS packets addressed to either 224.0.0.251 (and multicast MAC) or one of the configured casting IPs (and the NSE's MAC). These packets can be retransmitted to the casting server, which only modifies the DST MAC to match that of the casting server. Thus, the handling may be the same as control traffic from the guest device to the casting IP.

[0076] Regarding (2), the mDNS notification may be accompanied by a packet structured as follows: L2: src=casting server MAC address, dst=guest MAC address L3: src=casting server IP, dst=224.0.0.251 L4:UDP src / dst=5353 mDNS: A record = Casting Server IP

[0077] In this example, packets are multicast at L3 but unicast at L2. This allows the system to respond to guest device multicast queries with unicast responses (thus other guest devices not to see the response). If multicast DST MAC is used, all guest devices on the network can see the notification.

[0078] In some embodiments, the NSE MAC is used as the DST MAC, and packets are forwarded to the guest device as is done, in some cases, for normal control traffic. However, in the case of multicast IP, the DST IP may not be available for looking up MAC addresses in the subscriber table. To solve this problem, in some cases, packets may be forwarded to the NSE as follows: L2: src=guestMAC, dst=NSEMAC L3: Same as above L4: Same mDNS: Same

[0079] Here, the SRC MAC is set to the intended guest MAC, not the casting server's MAC, as would normally be expected. The NSE can handle these packets by noticing that the DST IP is multicast and using the inbound SRC MAC as the DST MAC for retransmission. The NSE can set its own MAC as the SRC MAC. This solution may generate non-standard packets but can resolve the issues identified above.

[0080] Another solution might be to always set the DST IP to be the intended guest IP and L2 address, as you would normally expect. When the NSE receives the packet, it can use the L4 header to detect that the packet has an mDNS notice. The NSE can then use the DST IP to find the intended recipient and look up the correct DST MAC for retransmission.

[0081] In some cases, the DST IP may be replaced so that the mDNS packet is 224.0.0.251 (only if it indicates that it is a multicast response). In other cases, this replacement is performed regardless of whether the packet is unicast or multicast. In some cases, whether the replacement is performed depends on detecting whether the DST PORT is not 5353. In other cases, a flag may exist in the mDNS response indicating whether it is responding to a unicast or multicast query. If applicable, that flag can be used to determine whether to replace.

[0082] (Dual Network Casting System) Figure 7 illustrates how a casting server 302 may operate in a dual-network casting system according to an aspect of this disclosure. The casting server 302 communicates with the casting device 310 via the cast network 306, and the casting server 302 communicates with the guest device 308 via a separate guest network 304. When a guest attempts to connect its guest device 308 (e.g., a smartphone) to one or more of the display devices 312 (e.g., a TV) (e.g., by activating a QR code® displayed on a TV), the casting server 302 receives location information and a MAC address associated with the guest device 308. For example, the location information may indicate the current location of the guest device 308. Alternatively, the location information may indicate a display device that displays a QR code® scanned by the guest. Alternatively, the location information may be embedded within the QR code® or link scanned and / or activated by the guest device 308.

[0083] The casting server 302 then determines, based on location information, whether the guest device 308 is in the same location as the casting device 310. In some embodiments, the casting server 302 may determine the room to which the guest or guest device is assigned and whether that room matches the room where the casting device 310 and / or display device 312 are located. If the guest device 308 and the casting device 310 are in the same location, the casting server 302 uses the MAC address of the guest device 308 (or, in some other cases, the IP address of the guest device) to initiate a pairing between the guest device 308 and the casting device 310. The casting server 302 then transmits the pairing to a cloud service which may be configured to manage and monitor multiple pairings on behalf of the casting device 310. The cloud service then stores the pairing initiated by the casting server 302.

[0084] After the pairing is stored, the casting server 302 generates packet forwarding rules for transmitting one or more network packets from the guest device 308 to the casting device 310 and / or from the casting device 310 to the guest device 308. Thus, the casting server 302 may generate bidirectional packet forwarding rules that enable the guest device 308 to communicate with one or more of the casting devices 310. In some other embodiments, the packet forwarding rules may be one-way packet forwarding rules or a pair of one-way packet forwarding rules configured to operate as bidirectional packet forwarding rules. The packet forwarding rules may then be stored in a storage device accessible by the casting server 302 (such as a cloud service, hard disk drive, or RAM).

[0085] When the casting server 302 receives a discovery request from the guest device 308 to discover the casting device 310, the casting server 302 forwards a discovery response back to the guest device 308, based on packet forwarding rules, which includes a proxy IP address available to the guest device 308 for communicating with the casting device 310, with or without communication with the casting device 310. The casting server 302 then receives a casting request from the guest device 308 indicating the proxy IP address. The casting device 310 then downloads the requested content from the internet and, for example, casts the requested content onto a display device 312 that communicates with the casting device 310 using the information transmitted to the casting device by the casting server. Such information may include, among other things, the location of the content, the required authentication information, etc.

[0086] (Communication between guest devices, casting devices, and casting servers) Figure 8 illustrates the process by which guest 800 communicates with casting device 801 via casting server 802. When guest 800 opens a video streaming app on its guest device 803 (e.g., a smartphone), the app may send discovery packets on the guest network to find casting device 801. For example, the app may send multicast DNS requests or queries to find casting services. Typically, these requests are multicast or broadcast over the Wi-Fi network, and any casting device that happens to be on the network may respond. However, since guest device 801 is not on the same network as the casting device, in typical circumstances there may be no response to their mDNS queries.

[0087] Here, the software on the casting server 802 may listen for any such discovery requests coming in from the guest device 803 and make a decision on whether to allow the guest device to discover any of the casting devices on the cast network. In some embodiments, this decision is based on whether there is a pairing 804 with one or more casting devices on the other side of the network (e.g., on the cast network) present for the guest device.

[0088] If no such pairing 804 exists, the casting server 802 may simply ignore the packet, and nothing may happen. In such a case, there may be no response to the discovery request, and the guest device 803 will determine that there are no casting devices available to talk to. On the other hand, if such a pairing 804 exists, the casting server 802 may send a response spoofed as a casting device on the cast network, providing an IP address that the guest device 803 can use to talk to the casting device 801. In some embodiments, this IP address is the actual IP address assigned to the casting device that the casting server is spoofing. In other embodiments, the IP address is a proxy IP generated by the casting server (and is not the same as any actual IP address of a casting device on the cast network). The guest device then uses the IP address to cast content onto a display device 806 (e.g., a TV in the guest's hotel room) connected to (or network communicating with) the casting device 801.

[0089] Once a casting device 801 is discovered, the second step is to actually perform the casting. For example, a guest 800 may open a media application on its guest device 803 (e.g., a smartphone), search for any available casting devices, and select a casting device that appears in the list of available casting devices (the discovery process described above generates this list). In response to the selection, a TCP connection is formed using the IP address that the smartphone determines belongs to the selected casting device 801, and any control commands, such as playing or pausing content, may be sent to the IP address. In response, the casting server 802 forwards the packets received from the guest device 803 to the appropriate casting device 801 on the casting network. In some embodiments, the casting server 802 may do so using Destination Network Address Translation (DNAT). In other embodiments, the casting server 802 may forward packets from one network to the other without translation.

[0090] (Packet forwarding rule is generated) Figure 9 illustrates the process by which the casting server 901 generates packet forwarding rules 902 to form TCP connections between guest devices 907, 908 and casting devices 904, 905, 906. Once pairing is established, the casting server 901 may create packet forwarding rules 902 that stipulate that when guest devices 907, 908 with a specific MAC address attempt to open a TCP connection with this specific proxy IP 903, packets may be forwarded to the appropriate casting devices 904, 905, 906 using the destination NAT. There may be a flow of incoming packets from the guest network 900, and the casting server 901 may translate them to different destination IP addresses on the casting devices 904, 905, 906 on the cast network. This would enable guest devices 907, 908 to connect to the casting devices. In addition, there may be reverse rules that allow traffic to return from the casting devices to the guest devices. Therefore, the casting server 901 may create and / or install bidirectional rules for packet forwarding that enable that type of TCP connection. In addition, the casting server 901 may discard rules when they are no longer needed (e.g., when a given pairing is removed). The casting server 901 may also indicate to the mDNS handler that a pairing exists, so that the mDNS handler knows whether to respond to an mDNS query from the guest device.

[0091] Casting devices 904, 905, and 906 may have a special receiving application for downloading content to be cast onto a display device. Such a receiving application may be registered with the casting device by the content creator so that the casting device 904, 905, and 906 are shipped with the receiving application, or so that the receiving application can be downloaded onto the casting device. Once a control connection (e.g., TCP) is established between guest devices 907, 908 and casting devices 904, 905, and 906 via the casting server 901, the guests may provide control commands, such as playing or pausing content, via the TCP connection. Upon request, the receiving application on casting devices 904, 905, and 906 may fetch the requested content without requiring an internet connection and the content to be streamed from guest devices 907, 908.

[0092] In some embodiments, the casting server 901 may read from a network connection on the guest network 900 and output the same packets onto the cast network, and the casting server software is an application launched outside the operating system. In some cases, such an approach may be overly CPU-intensive and may not scale. In other embodiments, packet forwarding rules 902 are installed on the operating system of the casting server 901 (e.g., Linux®), and operating system-level packet forwarding rules are used instead to control which packets are forwarded from one network to the other. Here, the casting server 901 may not route anything by default. If there are no specific rules to allow a packet to be received by the casting server 901 and transmitted to the other side, the packet may simply be dropped. To prevent this, packet forwarding rules 902 may be installed within the packet forwarding engine that stipulate that a guest device X may communicate with a casting device Y on the other network, which would allow packets from guest device X to flow to and back to casting device Y.

[0093] In some embodiments, using operating system packet forwarding rules does not reduce the amount of traffic to and from guest devices 907, 908 and casting devices 904, 905, 906 through the casting server 901, but because packet forwarding rules 902 are configured to guide packets to appropriate destinations rather than relying on the casting server software to process them, packets do not need to leave the operating system; they are received by the casting server network interface, processed by the operating system, transmitted through the casting server network interface, bypass the casting server software, and eliminate the need to store packets that should be read by the casting server software (thus reducing the amount of data duplication). For example, packet forwarding rule 902 may specify whether a given guest device 907 / 908 is allowed to communicate with a given casting device 904 / 905 / 906 (or vice versa), and if the operating system decides that such communication is allowed, the IP address is translated and the packet is forwarded to the receiving end; otherwise, the packet is dropped.

[0094] In some embodiments, when casting server 901 receives a multicast DNS packet, it will forward the packet to casting devices 904, 905, and 906. In other embodiments, casting server 901 will not forward any mDNS queries, but instead will spoof responses from casting devices 904 / 905 / 906 without actually forwarding the mDNS queries to them (for example, by caching the responses from casting devices 904 / 905 / 906). For example, when an mDNS query exists, casting server 901 may determine whether guest devices 907 / 908 are paired with casting devices 904 / 905 / 906, and then casting server 901 may spoof responses only from that particular paired casting device.

[0095] (Creating and removing pairings) Figure 10 illustrates the pairing process of a casting system, including the creation and removal of pairings. When a guest checks into their room and turns on the TV (if the TV is not already on), the guest may see a welcome screen with a casting instruction. This may include a QR code, which, upon activation, will cause the guest's guest device 1001 (e.g., a smartphone) to contact the casting server 1000 via the guest network (or via the internet). The casting server 1000 captures the guest's IP address and / or MAC address and creates and stores a pairing between the guest device 1001 and one or more casting devices 1002 in the guest's room (e.g., in the cloud or local storage). Once the pairing 1003 is created, the casting server 1000 may create one or more packet forwarding rules, allowing mDNS discovery for the guest device 1001 to occur. In some embodiments, in response to receiving a new pairing from the casting server 1000, the cloud service 1005 may check whether the new pairing already exists in the current pairings, and if so, reject the request to add the pairing. If the new pairing does not currently exist, the cloud service 1005 may instruct the casting server 1000 to create a packet forwarding rule for pairing 1003 and enable mDNS discovery for pairing 1003.

[0096] Larger hotels may have suites that may have multiple casting devices 1002 and / or display devices. Once pairing 1003 is created with one of such casting devices 1002, the casting server 1000 may also determine that guest device 1001 should be paired with other casting devices in the same room / unit / suite and, accordingly, create additional pairings. Multiple proxy IP addresses (e.g., proxy IP 302A) would allow a guest to distinguish between multiple casting devices 1002 that they have access to within their own room and specify which casting device the guest wishes to use.

[0097] When pairing 1003 should be removed, the casting server 1000 simply removes the packet forwarding rule. For example, a rule, essentially a whitelist of packets 1004, or a table of source and destination pairs that are allowed to pass through, is maintained in a storage device accessible by the casting server 1000. If a packet arrives and there is no whitelist rule 1004 for it, the packet is dropped. To remove a pairing, an administrator may send a message from the cloud service 1005 to the casting server 1000 to remove pairing 1003. The casting server 1000 may then remove the rule that allowed forwarding between this guest device 1001 and the casting device 1002 where pairing 1003 was located. Pairings may be removed when the guest checks out or according to a schedule (for example, at 1 p.m. every day).

[0098] In some embodiments, when a guest wishes to connect to a Wi-Fi network, the guest is directed to a captive portal system on the guest network. Once the captive portal system learns the guest's location (e.g., room 105), it may transmit that information to a casting server 1000, which can then automatically create a pairing, enabling the guest device 1001 to connect to a casting device 1002 in the guest's room. In such a case, when the guest turns on the TV, instead of a pairing command, other content and / or an indication that a pairing has been created (e.g., along with a QR code) may be displayed.

[0099] (Proxy ARP) Figure 11 illustrates a proxy ARP workflow, including embodiments with and without a casting server 1100. A guest device 1101 may initiate an ARP request requesting the MAC address of a computer on the network having a specific IP address. Typically, if the casting server 1100 is not present, the casting device 1102 will respond directly, indicating that it has the IP address and providing its MAC address, after which the two computers will be able to communicate directly.

[0100] However, once a casting server is introduced, the casting server 1100 becomes an obstacle and may return its own MAC address. When guest device 1101 requests the MAC address of a casting device 1102 with which guest device 1101 can communicate, guest device 1101 receives a response from casting server 1000 containing the MAC address of casting server 1000 (instead of the MAC address of any casting device). Thus, all communication destined for any device on the casting side of the network is effectively sent through casting server 1000. Proxy ARP can force any traffic wishing to reach a computer on the other side of the network (e.g., a casting device) to go through the casting server (proxy ARP can do the same with respect to traffic in the reverse direction). Here, when a casting device wishes to communicate with a guest device, the casting device provides an ARP request and is given the MAC address of the casting server on the casting side, and the casting server forces any traffic that the casting device has for the guest side of the network to pass through the casting server.

[0101] When guest device 1101 sends a request to cast to a TV in the living room and another request to cast to a TV in the bedroom, the two requests may have the same guest-side MAC address but two different IP addresses for each casting device 1102 connected to the two TVs. In some embodiments, a proxy IP is used to communicate with the different casting devices 1102. In other embodiments, the actual IP is used to communicate with the different casting devices 1102 (using a proxy MAC). For example, a proxy IP may be reused for each room in a hotel, and requests sent from two different guest devices 1101 in two different rooms to the same proxy IP address may be routed to two different casting devices 1102.

[0102] (Communication between guest devices, casting devices, and casting servers) Figure 12 illustrates a network environment including a default gateway for implementing client isolation as described in this disclosure. This figure shows the workflow of interaction between a guest device 1201 and its corresponding default gateway 1200. In TCP, the guest device would think it has opened a connection to the IP address of a casting device 1202, but the casting device 1202 is represented (or proxied) by an NSE. Furthermore, assuming that an available Ethernet® port on the NSE is configured as a casting bridge, when traffic to a casting IP address is received by the NSE on a subscriber VLAN, the NSE may retransmit the packet over the casting Ethernet® port (for example, the default gateway reads the destination MAC address and forwards the MAC address directly to a specific port to which the MAC address is plugged, e.g., the Ethernet® port to which the casting server is connected).

[0103] In this embodiment, the guest device 1201 may send an ARP request for the IP address of the casting device 1202. The default gateway 1200 may respond to the ARP request by providing its own MAC address (e.g., the NSE MAC address described below) in the response packet. If the guest device 1201 provides its MAC address in the ARP request, the default gateway may respond with its own NSE MAC address in the response packet sent to the guest device 1201. The default gateway may also respond with the MAC address of the casting server 1203 in the response packet, assuming that the casting server 1203 can accept packets for the casting IP.

[0104] The default gateway 1200 may also provide the IP address of the casting device 1202 in the reply packet. If the guest device 1201 provides its IP address in the ARP request, the default gateway may reply with the IP address of the casting device 1202 in the reply packet sent to the guest device 1201. The default gateway may also reply with the IP address of the casting server 1203 in the reply packet, assuming that the casting server 1203 can accept packets for casting IP.

[0105] During retransmission, the SRC MAC can be preserved to be that of the guest device. In this way, the guest device 1201 can be tracked by its MAC address. Alternatively, it is possible to track it by IP, but IP addresses can change much more frequently than MAC addresses, and therefore tracking the guest device by MAC may be more reliable.

[0106] (Enumerated implementations (EI)) Several examples of the listed implementations (EIs) are provided in this section without limitation.

[0107] EI 1: A casting system comprising a display device, a casting device configured to access content and cast the accessed content onto the display device, and a casting server equipped with computer hardware, wherein the casting server communicates with the casting device via a cast network, and the casting server communicates with guest devices via a separate guest network from the cast network, and the casting server receives location information and a MAC address associated with the guest device, determines that the guest device is in the same location as the casting device based on the location information, initiates pairing between the guest device and the casting device using the guest device's MAC address, and transmits the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device. The process involves: receiving an instruction from the cloud service that the cloud service has successfully remembered the pairing; generating a packet forwarding rule that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device; ensuring that the packet forwarding rule is stored for later access by the casting server; receiving a discovery request from the guest device to discover a casting device available to the guest device; forwarding a discovery response back to the guest device, based on the packet forwarding rule, with or without communication with the casting device, including a proxy IP address available to the guest device to communicate with the casting device; receiving a casting request from the guest device, the casting request indicating a proxy IP address; and instructing the casting device to download the requested content from the internet.A casting system configured to transmit information available to a casting device in order to cast requested content onto a display device that communicates with the casting device.

[0108] EI 2: A casting device is a system of any other EI provided herein or any combination of two or more EIs provided herein, configured to download the requested content without passing network traffic to the casting server, so as not to impose any additional network load on the casting server.

[0109] EI 3: A system of any other EI provided herein or any combination of two or more EIs provided herein, configured such that when a casting server receives a multicast DNS packet from a guest device, the casting server spoofs the response from the casting device without forwarding the multicast DNS packet to the casting device.

[0110] EI 4: The casting server is a system of any other EI provided herein or any combination of two or more EIs provided herein, further configured to output a captive portal to a guest device.

[0111] EI 5: A system of any other EI or any combination of two or more EIs provided herein, configured to respond to multicast DNS requests from guest devices by returning different proxy IP addresses to represent different casting devices.

[0112] EI 6: A casting server is a system of any other EI provided herein or any combination of two or more EIs provided herein, configured to remove pairings in response to requests to remove pairings received from cloud services.

[0113] EI 7: A system of any other EI provided herein or any combination of two or more EIs provided herein, in which packet forwarding rules are stored in random access memory (RAM) and, in response to the removal of a pairing, the packet forwarding rules are removed from RAM.

[0114] EI 8: Proxy ARP is a system of any other EI provided herein or any combination of two or more EIs provided herein that is configured to force packets from a guest device or casting device to pass through to a casting server instead of the default gateway of the local network associated with the guest device or casting device.

[0115] EI 9: A system of any other EI or any combination of two or more EIs provided herein, further configured to receive ARP requests associated with an IP address from a guest device and respond by returning the MAC address associated with the casting server.

[0116] EI 10: A casting method comprising: receiving location information and a MAC address associated with a guest device; determining, based on the location information, that the guest device is in the same location as a casting device; using the MAC address of the guest device, initiating a pairing between the guest device and the casting device; transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device; receiving an instruction from the cloud service that the cloud service has successfully remembered the pairing; and generating packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device. A method comprising: storing packet forwarding rules for later access by a casting server; receiving a discovery request from a guest device to discover a casting device available to the guest device; forwarding a discovery response back to the guest device, with or without communication with the casting device, based on the packet forwarding rules, which includes a proxy IP address available to the guest device for communicating with the casting device; receiving a casting request from the guest device, the casting request indicating a proxy IP address; and transmitting to the casting device information available to the casting device for downloading the requested content from the Internet and casting the requested content onto a display device that communicates with the casting device.

[0117] EI 11: Any other EI provided herein or any combination of two or more EIs provided herein, further including downloading the requested content without passing network traffic to the casting server, so as not to impose any additional network load on the casting server.

[0118] EI 12: Any other EI provided herein or any combination of two or more EIs provided herein, further comprising receiving a multicast DNS packet from a guest device and forging a response from the casting device without forwarding the multicast DNS packet to the casting device.

[0119] EI 13: Any other EI provided herein or any combination of two or more EIs provided herein, further comprising responding to multicast DNS requests from a guest device by returning a different proxy IP address to represent a different casting device.

[0120] EI 14: A method of any other EI provided herein or any combination of two or more EIs provided herein, further comprising removing a pairing in response to a request to remove a pairing received from a cloud service.

[0121] EI 15: Any other EI provided herein or any combination of two or more EIs provided herein, further comprising forcing packets from a guest device or casting device to pass through to a casting server instead of the default gateway of the local network associated with the guest device or casting device.

[0122] EI 16: A method of any other EI provided herein or any combination of two or more EIs provided herein, further comprising receiving an ARP request associated with an IP address from a guest device and responding by returning the MAC address associated with the casting server.

[0123] EI 17: A non-transient computer storage medium storing computer executable instructions, which, when executed by one or more computing devices, receives location information and a MAC address associated with a guest device; determines, based on the location information, that the guest device is in the same location as the casting device; uses the MAC address of the guest device to initiate a pairing between the guest device and the casting device; transmits the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device; receives an instruction from the cloud service that the pairing has been successfully stored; and transmits one or more network packets from the guest device to the casting device and / or from the casting device to the guest device using a packet forwarding route available to the casting server. A non-transient computer storage medium that causes one or more computing devices to perform an operation including generating a packet forwarding rule, storing the packet forwarding rule for later access by the casting server, receiving a discovery request from the guest device to discover a casting device available to the guest device, forwarding a discovery response back to the guest device, which includes a proxy IP address available to the guest device to communicate with the casting device, with or without communication with the casting device, based on the packet forwarding rule, and receiving a casting request from the guest device, the casting request indicating a proxy IP address, and transmitting information available to the casting device to download the requested content from the Internet and cast the requested content onto a display device that communicates with the casting device.

[0124] EI 18: Operation further includes downloading the requested content without passing network traffic to the casting server, such that the download of the requested content does not impose any additional network load on the casting server, on any other EI provided herein or any combination of two or more EIs provided herein, on a non-transient computer storage medium.

[0125] EI 19: Operation of any other EI provided herein or any combination of two or more EIs provided herein, further comprising receiving a multicast DNS packet from a guest device and forging a response from a casting device without forwarding the multicast DNS packet to the casting device, on a non-transient computer storage medium.

[0126] EI 20: Operation further includes responding to multicast DNS requests from a guest device by returning different proxy IP addresses to represent different casting devices, for any other EI provided herein or any combination of two or more EIs provided herein on a non-transient computer storage medium.

[0127] (Technical terminology) All methods and tasks described herein can be performed by a computer system and may be fully automated. A computer system may, in some cases, include multiple different computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the functions described. Each such computing device typically includes a processor (or more processors) that executes program instructions or modules stored in memory or other non-transient computer-readable storage media or devices (e.g., solid-state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions or implemented in application-specific circuits of the computer system (e.g., ASICs or FPGAs). If the computer system includes multiple computing devices, these devices may be jointly installed, although this is not required. The results of the disclosed methods and tasks may be permanently stored by converting physical storage devices, such as solid-state memory chips or magnetic disks, into different states. In some embodiments, the computer system may be a cloud-based computing system in which its processing resources are shared by multiple different enterprise entities or other users.

[0128] The processes described herein or illustrated in the diagrams of this disclosure may be initiated on demand by a user or system administrator, or in response to an event, such as in response to some other event, on a predetermined or dynamically determined schedule. Once such a process is initiated, a set of executable program instructions stored on one or more non-transient computer-readable media (e.g., hard drives, flash memory, removable media, etc.) may be loaded into the memory (e.g., RAM) of a server or other computing device. The executable instructions may then be executed by the hardware-based computer processor of the computing device. In some embodiments, such a process or part thereof may be executed sequentially or in parallel on multiple computing devices and / or multiple processors.

[0129] Depending on the embodiment, any action, event, or function of any of the processes or algorithms described herein may be performed in a different order, added, merged, or omitted entirely (for example, not all described actions or events are necessary for the practice of the algorithm). Furthermore, in some embodiments, actions or events may be performed not sequentially, but concurrently, for example, through multithreading, interrupt handling, or across multiple processors or processor cores, or on other parallel architectures.

[0130] The various illustrative logic blocks, modules, routines, and algorithmic steps described in relation to the embodiments disclosed herein can be implemented as electronic hardware (e.g., ASIC or FPGA devices), computer software running on computer hardware, or a combination of both. Furthermore, the various illustrative logic blocks and modules described in relation to the embodiments disclosed herein can be implemented or executed by machines such as processor devices, digital signal processors ("DSPs"), application-specific integrated circuits ("ASICs"), field-programmable gate arrays ("FPGAs") or other programmable logic devices, discrete gate or transistor logic, separate hardware components, or any combination thereof designed to perform the functions described herein. The processor device may be a microprocessor, but alternatively, the processor device may be a controller, microcontroller, or state machine, or a combination thereof. The processor device may include an electrical network configured to process computer-executable instructions. In another embodiment, the processor device includes an FPGA or other programmable device that performs logical operations without processing computer-executable instructions. Processor devices can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Although this specification primarily describes digital technologies, processor devices may also include primarily analog components. For example, some or all of the rendering techniques described herein can be implemented in analog networks or composite analog and digital networks.A computing environment can include, but is not limited to, any type of computer system, including microprocessor-based computer systems, mainframe computers, digital signal processors, portable computing devices, device controllers, or computing engines in consumer electronics.

[0131] Elements of methods, processes, routines, or algorithms described in connection with embodiments disclosed herein may be embodied directly in hardware, in software modules executed by a processor device, or in a combination of both. The software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of non-transient computer-readable storage medium. Exemplary storage media may be coupled to the processor device so that the processor device can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor device. The processor device and storage medium may reside within an ASIC. The ASIC may reside within a user terminal. Alternatively, the processor device and storage medium may reside as discrete components within a user terminal.

[0132] In particular, conditional language used herein, such as “can,” “could,” “might,” “may,” and “e.g.,” is generally intended to convey that one embodiment includes a certain feature, element, or thing, while another embodiment does not, unless otherwise specifically stated or understood in the context in which it is used. Therefore, such conditional language is generally not intended to imply that a feature, element, or thing is required in any way for one or more embodiments, or that one or more embodiments necessarily include logic for determining whether these features, elements, or things should be included or implemented in any particular embodiment, with or without other inputs or prompts. The terms “equipped with,” “include,” and “have” are synonymous and used in a non-restrictive manner to be inclusive and do not exclude additional elements, features, actions, behaviors, etc. Furthermore, the term "or" is used in its inclusive sense (not its exclusive sense) when, for example, it is used to connect a list of elements, so that the term "or" means one, some, or all of the elements in the list. The term "tux" is used to include "one or more things." For example, a tux of objects may include a single object or multiple objects.

[0133] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is understood differently in the context in which it is commonly used to indicate that an item, term, etc., may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, or Z), unless specifically otherwise noted. Therefore, such disjunctive language is generally not intended, or should not, imply that a particular embodiment requires the presence of at least one of X, at least one of Y, and at least one of Z, respectively.

[0134] Any process description, element, or block in the flowcharts described herein and / or depicted in the accompanying diagrams should be understood as potentially representing a module, segment, or portion of code containing one or more executable instructions for implementing a specific logical function or element in the process. Alternative implementations are included within the scope of the embodiments described herein, and elements or functions may be removed, included substantially simultaneously, or in reverse order, and executed in an order other than those shown or discussed, depending on the functionality involved, as will be understood by those skilled in the art.

[0135] Unless otherwise explicitly stated, articles such as "a" or "an" should generally be interpreted as including one or more items being described. Therefore, phrases such as "devices configured to do..." are intended to include one or more enumerated devices. Such one or more enumerated devices may also be collectively configured to perform the enumerated items. For example, "processors configured to perform enumerations A, B, and C" could include a first processor configured to perform enumeration A in cooperation with a second processor configured to perform enumerations B and C.

[0136] While the detailed descriptions above illustrate, describe, and point out novel features applicable to various embodiments, it should be understood that various omissions, substitutions, and modifications in the form and details of the illustrated devices or algorithms may be made without departing from the scope of this disclosure. As can be recognized, some embodiments described herein may be embodied in a form that does not provide all of the features and benefits described herein, since some features can be used or practiced separately from others. All modifications that fall within the meaning and scope of equivalence of claims are encompassed within that scope.

Claims

1. A casting system, wherein the casting system is Display devices and, A casting device configured to access content and to cast the accessed content onto the display device, Casting servers equipped with computer hardware and Equipped with, The casting server communicates with the casting device via the cast network, and the casting server communicates with the guest device via a guest network separate from the cast network. The aforementioned casting server, To receive location information associated with the guest device and the MAC address associated with the guest device, Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, Generating packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to cast the requested content onto the display device that communicates with the casting device. A casting system configured to perform the following actions.

2. The system according to claim 1, wherein the casting device is configured to download the requested content without passing network traffic to the casting server, so that the download of the requested content does not impose any additional network load on the casting server.

3. The system according to claim 1, wherein when the casting server receives a multicast DNS packet from the guest device, it is configured to falsify a response from the casting device without forwarding the multicast DNS packet to the casting device.

4. The system according to claim 3, wherein the casting server is further configured to output a captive portal to the guest device.

5. The system according to claim 1, wherein the casting server is configured to respond to multicast DNS requests from guest devices by returning different proxy IP addresses to represent different casting devices.

6. The system according to claim 1, wherein the casting server is configured to remove the pairing in response to a request to remove the pairing received from the cloud service.

7. The system according to claim 6, wherein the packet forwarding rule is stored in random access memory (RAM), and in response to the removal of the pairing, the packet forwarding rule is deleted from the RAM.

8. The system according to claim 1, wherein the proxy ARP is configured to force packets from the guest device or the casting device to pass through the casting server instead of the default gateway of the local network associated with the guest device or the casting device.

9. The system according to claim 1, wherein the casting server is further configured to receive an ARP request associated with an IP address from the guest device and respond by returning the MAC address associated with the casting server.

10. A casting method, wherein the method is Receiving location information associated with the guest device and the MAC address associated with the guest device, Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, To generate packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to a display device that communicates with the casting device in order to cast the requested content onto the display device. Methods that include...

11. The method according to claim 10, further comprising downloading the requested content without passing network traffic to the casting server, wherein the download of the requested content does not impose any additional network load on the casting server.

12. The method according to claim 10, further comprising receiving a multicast DNS packet from the guest device and then spoofing a response from the casting device without forwarding the multicast DNS packet to the casting device.

13. The method according to claim 10, further comprising responding to a multicast DNS request from a guest device by returning a different proxy IP address to represent a different casting device.

14. The method of claim 10, further comprising removing the pairing in response to a request to remove the pairing received from the cloud service.

15. The method according to claim 10, further comprising forcing packets from the guest device or the casting device to pass through a casting server instead of the default gateway of the local network associated with the guest device or the casting device.

16. The method according to claim 10, further comprising receiving an ARP request associated with an IP address from the guest device and responding by returning the MAC address associated with the casting server.

17. A non-transient computer storage medium storing computer executable instructions, wherein the computer executable instructions are executed by one or more computing devices. Receiving location information associated with the guest device and the MAC address associated with the guest device, Based on the location information, it is determined that the guest device is in the same location as the casting device, Using the MAC address of the guest device, a pairing is initiated between the guest device and the casting device. Transmitting the pairing to a cloud service configured to manage and monitor multiple pairings on behalf of the casting device, The cloud service receives an instruction from the cloud service that it has successfully stored the pairing, To generate packet forwarding rules that can be used by the casting server to transmit one or more network packets from the guest device to the casting device and / or from the casting device to the guest device, The packet forwarding rules are stored for later access by the casting server, The guest device receives a discovery request from the guest device to find a casting device that is available to the guest device, Based on the packet forwarding rules, a discovery response containing a proxy IP address usable by the guest device to communicate with the casting device is forwarded back to the guest device, with or without communication with the casting device. Receiving a casting request from the guest device, wherein the casting request indicates the proxy IP address, The casting device downloads the requested content from the internet and transmits information usable by the casting device to a display device that communicates with the casting device in order to cast the requested content onto the display device. A non-transient computer storage medium that causes one or more computing devices to perform an operation including the above.

18. The non-transient computer storage medium according to claim 17, wherein the operation further includes downloading the requested content without passing network traffic to the casting server, so that the download of the requested content does not impose any additional network load on the casting server.

19. The non-transient computer storage medium according to claim 17, wherein the operation further comprises, upon receiving a multicast DNS packet from the guest device, faking a response from the casting device without forwarding the multicast DNS packet to the casting device.

20. The non-transient computer storage medium according to claim 17, further comprising responding to multicast DNS requests from a guest device by returning different proxy IP addresses to represent different casting devices.

Images