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 technology]

[0001] Casting devices allow users to stream content from their mobile devices or computers onto larger screens, such as televisions. With these devices, users can easily watch their favorite TV shows, movies, or other content on a larger display without having to physically connect their devices to a 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 problem]

[0002] The embodiments described herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference symbols indicate similar elements. [Brief description of the drawings]

[0003] [Figure 1] FIG. 1 illustrates a network implementation according to an aspect of the present disclosure.

[0004] [Diagram 2] FIG. 2 illustrates a cross-section of various access points in the context of a multi-dwelling unit (MDU) in accordance with an aspect of the disclosure.

[0005] [Diagram 3] FIG. 3 illustrates a network environment including a casting server for controlling user access to casting and display devices in accordance with an aspect of the present disclosure.

[0006] [Figure 4] FIG. 4 illustrates a network environment including another casting server for controlling user access to casting and display devices in accordance with an aspect of the present disclosure.

[0007] [Diagram 5] FIG. 5 illustrates the general architecture of a computing device or system that provides casting management services according to an aspect of the present disclosure.

[0008] [Figure 6] FIG. 6 illustrates a network environment including another casting server for controlling user access to casting and display devices in accordance with an aspect of the present disclosure.

[0009] [Figure 7] FIG. 7 illustrates a manner in which a casting server according to an aspect of the present disclosure may operate.

[0010] [Figure 8] FIG. 8 illustrates a manner in which a guest according to an aspect of the present disclosure may interact with a casting server to connect a user device to a casting device.

[0011] [Figure 9] FIG. 9 illustrates how a casting server according to an aspect of the present disclosure may create rules and pair devices.

[0012] [Figure 10] FIG. 10 illustrates how pairings according to aspects of the present disclosure may be created and removed.

[0013] [Figure 11] FIG. 11 illustrates a network environment including a proxy ARP configured to control user access in accordance with an aspect of the present disclosure.

[0014] [Figure 12] FIG. 12 illustrates a network environment including a default gateway configured to implement client isolation in accordance with an aspect of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0016] However, in a hospitality setting, such as a hotel, connecting all guests to the same Wi-Fi network as the casting devices available to them would mean that all guest devices could see all casting devices connected to the Wi-Fi network, and potentially take over the TV of another guest in another hotel room.

[0017] These and other problems can be addressed in accordance with embodiments of the present disclosure, in which the casting devices and the user computing devices (also referred to herein as guest devices) that access the casting devices are connected to separate wireless networks, and network communications between the user computing devices and the casting devices are facilitated by a casting server that is connected to both wireless networks. By keeping the casting devices on a separate network from the guest devices from which casting may be initiated, the discoverability problems described above can be addressed without having to set up 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] With a casting server that can pair specific user devices with appropriate corresponding casting devices and control network communications between the user devices and the casting devices, only the casting or display devices that the user is authorized to access are made visible to the user via the user's device, and the user is prevented from accessing or casting the user's content to other casting and display devices in other users' rooms.

[0019] These and other aspects of the disclosure will now be described with respect to certain examples and implementations that are intended to illustrate, but not limit, the disclosure. While the examples and implementations described herein will focus on specific calculations and algorithms for purposes of illustration, those skilled in the art will understand that the examples are for illustration purposes only and are not intended to be limiting.

[0020] (Network Access System) FIG. 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, 155. The user devices may include, for example, laptops, desktop computers, smartphones, PDAs, and any other wired or wireless network-enabled communication devices, etc. The user devices 141, 143, 145, 147, 149, 151, 153, 155 communicate with access points 121, 123, 125, 127, 129. The access points 121, 123, 125, 127, 129 provide wired or wireless communication with a network management device 103. The network management device 103 controls network communication between the access points and between the 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, repeaters, etc., can also be used to help provide communication between the access points 121, 123, 125, 127 and the network management device 103. The network 101 can be, for example, a public network such as the Internet. The network management device 103 (also referred to herein as a network management system) can include a network gateway, such as, for example, a network access gateway commercially available from Nomadix, Inc. (Woodland Hills, Calif.). Other network management devices can also be used, as would be understood by one of ordinary skill in the art from this disclosure.

[0021] A device is generally programmed to automatically select between access points, for example, by determining the access point that provides the strongest signal. A device may be between three different access points and be able to communicate with all of them, but may ultimately choose one access point with which to communicate. In some cases, an access point may not allow the 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 may 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 appreciated, a user device may be configured to select an access point based on any number of different selection options, including, for example, signal strength, bandwidth availability, access rights, access points corresponding to a particular SSID, etc. 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 realize that he or she has switched access points.

[0022] As illustrated in Figure 1, the network includes multiple physical areas, including apartment lobbies 107, apartment business centers 109, and apartment units 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 a service set identifier (SSID), extended service set identifier (ESSID), and / or basic service set identifier (BSSID), collectively referred to herein as SSID. In some implementations, the same SSID is assigned to all access points in the network. In other implementations, a different SSID is assigned to each access point or group of access points (or each region or group of regions) in the network. In still other implementations, multiple SSIDs can be assigned to the same set of access points. In this regard, virtual SSIDs can be configured corresponding to different groupings of access points. The network management device 103 can 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 based on permanent and / or non-permanent identifiers associated with the user's user device, such as a MAC address and / or a user profile (or one or more parameters included in the user profile) stored on the user device. Although a MAC address is used as an example identifier in describing one or more embodiments of the present disclosure (e.g., in the context of creating pairings that provide customized services, etc.), in other embodiments, an IP address or other permanent or non-permanent identifiers can be used instead. Similarly, although an IP address is used as an example identifier in describing one or more embodiments of the present disclosure, in other embodiments, a MAC address or other permanent or non-permanent identifiers can be used instead.

[0024] (Multi-Dwelling Unit (MDU)) FIG. 2 illustrates a cross-section of various access points in the context of an MDU. Residence hall 201 includes rooms 203, conference rooms 205, restaurant 207, and lobby 209. Rooms 203, conference rooms 205, restaurant 207, and lobby 209 include various access points 221. While illustrated as having one or more access points in each room, it should be understood that fewer or more access points may be used. For example, in some implementations, a single access point may be used for multiple rooms. Also, as will be appreciated by those skilled in the art, many different types of facilities may benefit from the present disclosure. For example, although described primarily with respect to residence halls, other facilities may also use the present network management system, including apartment buildings, schools, colleges, universities, hospitals, hotels, government buildings, businesses, or any other public or private networking system.

[0025] (Casting Management System) 3 illustrates an embodiment of a networking environment 300 that includes a casting server 302. The casting server 302 is part of a guest network 304 and a cast network 306. A casting server connected to both the guest network and the cast network may provide a secured or controlled connection between the two networks (e.g., between a user device 308 (also referred to herein as a guest device 308) on the guest network 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 accessibility to guests' mobile devices (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 devices. 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 a guest joins the guest network and provides information and / or payment requested by the hotel, the guest may be enabled 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 that is 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 to 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 device may know the password to 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 a captive portal gateway. For example, the gateway may be a router that provides unimpeded access to the Internet. When a guest accesses a casting device on the cast network and instructs it to stream media on a display device in communication with the casting device, the casting device may access the Internet through the gateway to 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 still other embodiments, the gateway device in the guest network and the gateway in the cast network use the same gateway device. In some of such 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., one in the guest network is configured to operate as a captive portal gateway and 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 his or her smartphone, the app may send out discovery packets on the guest network to look for casting devices. For example, the app may send out multicast DNS requests or queries to look for casting services. Typically, these requests are multicast or broadcast on the Wi-Fi network, and any casting devices that happen to be on the network may respond. However, because the guest devices are not on the same network as the casting devices, in a typical situation, there may not be any response to their mDNS queries.

[0031] Now, software on the casting server may listen for any such discovery requests coming from the guest device and make a determination of whether to allow the guest device to see any of the casting devices on the cast network. In some embodiments, this determination is made based on whether there is a pairing that 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 no such pairing exists, 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 think that there are no casting devices available to talk to. On the other hand, if such pairing exists, the casting server may send a response impersonating a casting device that is on the cast network and 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 impersonates. 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 in network communication with) the casting device.

[0033] (casting) Once a casting device has been discovered, the second step is to actually perform the casting. For example, a guest may open a media application on his or her smartphone, search for any available casting devices, and select a casting device that appears in a list of available casting devices (the discovery process described above generates this list). In response to the selection, a TCP connection is formed with the IP address that the smartphone believes belongs 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 packets received from the smartphone to the appropriate casting device on the cast 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 a packet forwarding rule) Once the pairing is created, the casting server may create packet forwarding rules that stipulate that when a guest device with a particular MAC address tries to open a TCP connection with this particular proxy IP, the packets may be forwarded to the appropriate casting device using destination NAT. There may be a flow of packets coming from the guest network, and the casting server may translate them to a different destination IP address to the casting device on the cast network. This would allow the guest device to connect to the casting device. In addition, there may be a reverse rule that allows such traffic from the casting device back to the guest device. Thus, the casting server may create and / or install bidirectional rules for packet forwarding that allow that type of TCP connection to be made. 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 there is a pairing, so that the mDNS handler knows to or not to respond to mDNS queries from the guest device.

[0035] (Establishing a control connection (TCP)) The casting device may have a special receiver application for downloading the content to be cast on the display device. Such a receiver application may be registered on the casting device by the content creator so that the casting device is shipped with the receiver application or so that the receiver application may be downloaded onto the casting device. Once a control connection (e.g., TCP) is established between the guest device and the casting device via the casting server, the guest may provide control commands, such as play or pause the content, over the TCP connection. When requested, the receiver application on the casting device may connect to the Internet and fetch the requested content without requiring the content to be streamed from the guest device.

[0036] (Installation of casting device) In addition, the casting server may facilitate the installation of the casting device. When a casting device is installed, it may be placed in a room, and the casting server may detect new casting devices that appear on the cast network that the casting server does not yet know about. The casting server may then register that casting device with a cloud service (e.g., communicating with the casting server 302 via the Internet 318), which may be configured to permanently store the pairing information so that the pairing information may be re-downloaded onto the casting server after the casting server is reset or restarted. Furthermore, the casting server may periodically send a report (e.g., a current list of casting devices that are online) to the cloud service, which may analyze the report and flag any issues (e.g., if a casting device that is expected to be on the list is missing, or if there is a casting device on the list that is not recognized by the cloud service, etc.). 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 cause the casting device to display information that can be used by the installer on a display device connected to the casting device. The information may include a QR code or link that the installer can use to link the casting device to a particular room number or location. Once the location of an unrecognized casting device is identified, the casting server may cause the casting device to be entered into records and configure the casting device for future use (e.g., cause the casting device to display pairing instructions for future guests).

[0037] (Packet handling using rules) In some embodiments, the casting server may read packets from a network connection on the guest network and output the same packets on the cast network, where the casting server software is an application that runs outside the operating system. In some cases, such an approach may be too CPU intensive and may not scale 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 is no specific rule to allow the packet to be transmitted to the other side, the packet may simply be dropped. To prevent that, a packet forwarding rule that specifies that guest device X may talk to casting device Y on the other network may be installed in the packet forwarding engine, which will allow packets from guest device X to flow to casting device Y and back.

[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 the packet forwarding rules are configured to direct packets to the appropriate destination rather than having to rely on the casting server software to process them, the packets do not have to leave the operating system; they are received by the casting server network interface, processed by the operating system, and transmitted through the casting server network interface, bypassing the casting server software and eliminating the need to store packets to be read by the casting server software (thereby reducing the amount of data duplication). For example, packet forwarding rules can specify whether a given guest device is enabled to communicate with a given casting device (or vice versa), and if the operating system determines that such communication is enabled, the IP address is translated and the packet is conveyed to the recipient, otherwise the packet is dropped.

[0039] (Multicast DNS response) In some embodiments, when the casting server receives a multicast DNS packet, it will forward the packet to the casting device. In other embodiments, the casting server does not forward any mDNS queries, and instead spoofs the response from the casting device without actually forwarding the mDNS query to the casting device (e.g., by caching the response from the casting device). For example, when there is an mDNS query, the casting server may understand if a guest device is paired to the casting device, and then the casting server may spoof only the response from that particular paired casting device.

[0040] (Pairing process) When a guest checks into their room and turns on the TV (if it is not already on), the guest may see a welcome screen with casting instructions. This may include a QR code that, upon activation, will cause the guest's smartphone to contact a casting server over the guest network (or via the Internet). The casting server captures the guest's IP address and / or MAC address and creates and stores (e.g., in the cloud or local storage) a pairing between the guest's smartphone and one or more casting devices in the guest's room. Once the pairing is created, the casting server may create one or more packet forwarding rules to enable 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 packet forwarding rules for the pairing and enable mDNS discovery for the pairing.

[0041] (Room with multiple casting devices) Larger hotels may have suites that may have multiple casting and / or display devices. Once a pairing is created 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 create additional pairings accordingly. Multiple proxy IP addresses (e.g., Proxy IP 302A) would allow a guest to distinguish between the multiple casting devices to which they have access within their own room and to specify the casting device they wish to use.

[0042] (Remove pairing) When a pairing should be removed, the casting server simply removes the packet forwarding rule. For example, a table of rules (which may be a whitelist of packets, or source and destination pairs that are allowed to pass) is maintained in a storage device 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 delete the rule that allows forwarding between this guest device and the casting device for which the pairing was created. The pairing may be removed when the guest checks out, or according to a schedule (e.g., every day at 1 p.m.).

[0043] (Automatic pairing) In some embodiments, when a guest wants to connect to a Wi-Fi network, the guest is directed to a captive portal system on the guest network. Once that captive portal system learns about the guest's location (e.g., room 105), it can send that information to a casting server, which can then automatically create a pairing and allow 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 pairing instructions (e.g., along with a QR code), other content and / or an indication that a pairing has been created may be displayed.

[0044] (Alternative approach) FIG. 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 FIG. 4, the cast side of the network may be a subset of the total network address range of the guest side of the network. For example, if the guest network has an IP range of 10.2.0.0, that would be a 16-bit netmask. Now, 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, to an outside observer, apart from the casting server, it may appear as if the casting device and the guest device are part of the same network.

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

[0046] However, when a casting server is introduced, the casting server gets in the way and may return its own MAC address. When a guest device requests the MAC address of a casting device with which the guest device may communicate, the guest device may receive a response from the casting server that includes the MAC address of the casting server (instead of the MAC address of any casting device). Thus, all communications going to any device on the cast side of the network are effectively sent through the casting server. Proxy ARP may cause any traffic that is configured to reach a computer on the other side of the network (e.g., the casting device) to be forced to go through the casting server (proxy ARP may do the same for traffic in the reverse direction). Now, when the casting device wants to communicate with the guest device, it provides an ARP request and is provided with the MAC address of the cast side of the server, which forces any traffic that the casting device has for the guest side of the network to go through the casting server.

[0047] (difference 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 MAC address but two different IP addresses of 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, a real IP is used (with a proxy MAC) to communicate with the different casting devices. 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 directed 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 through the casting server to the other side. In other embodiments, discovery requests are passed through the casting server to the other side, and the casting device can respond. The casting server may then determine, based on the pairing, whether the response should be allowed to reach back to the guest device. When one guest device tries to discover a casting device in a room, the casting server may send a discovery response to all of the guest devices in the same room, so that all of the guest devices have access to all of the casting devices, which makes the room look like 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 a hotel room, when the guest opens a streaming application and looks for a casting device to connect to, a discovery packet from the available casting device may be sent to the smartphone, indicating that the casting device is available for casting. In addition, a 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 off, the discovery packet cannot be transmitted. The local AP would receive the discovery packet, but the AP would determine that no devices are listening on the MAC address associated with the guest's tablet. If the guest's tablet is on, the tablet may store (e.g., in a cache) the information contained in the discovery packet (e.g., information about the casting devices that are available for use), so that when the guest later wishes to cast content onto one of the casting devices, the cached information about the available casting devices may be A mobile application would allow them to be quickly populated 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 go through 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 will obtain information about available casting devices through such periodic notifications from the casting server.

[0051] (Example architecture of a casting server) FIG. 5 depicts an example architecture of a computing system (referred to as a casting server 500) that may be used to implement one or more of the techniques described herein or illustrated in FIGS. 1-4 and 6-12. The general architecture of the casting server 500 depicted in FIG. 5 includes an arrangement of computer hardware and software modules that may be used to implement one or more aspects of the present disclosure. The casting server 500 may include many more (or fewer) elements than those depicted in FIG. 5. However, it is not necessary that all of these elements be depicted to provide an enabling disclosure. As depicted, 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 a connection to one or more networks or computing systems. The processor 190 may thus receive information and instructions from other computing systems or services via one or more of the networks depicted in FIGS. 3 and 4.

[0052] The processor 190 may also be in communication with the memory 180. The memory 180 may include computer program instructions (grouped in modules, in some embodiments) that the processor 190 executes to implement one or more aspects of the present disclosure. The memory 180 may include RAM, ROM, and / or other persistent, auxiliary, or non-transitory 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 include 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 therefor) for display on a user computing device (e.g., the user computing device 308 of FIG. 3), e.g., 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 include (or be in communication with) one or more data stores.

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

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

[0055] (Client isolation) The 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, the guest devices may be allowed to communicate only with a 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 may communicate directly with the casting server.

[0057] (default gateway) When a guest device joins a network, it may issue a DHCP request indicating that an IP address is needed, and the network will respond with a DHCP offer, providing an IP address. The guest device can then accept the IP address in another DHCP request, and the network will respond with a DHCP ACK. The network also tells the guest device the DNS server and default gateway.

[0058] (Casting solution without whitelist) To support casting on certain types of wireless networks, a default gateway (e.g., a captive portal gateway) may double as a casting service gateway. This may be applicable when a network is configured to enforce client isolation such that guest devices communicate only with their default gateway and cannot communicate with any other devices connected to the network. An example is shown in FIG. 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 FIG. 6, a default gateway (e.g., a captive portal gateway) doubles as a 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 guests and Chromecasts or other casting devices.

[0060] In some cases, the 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 to discover available casting devices and / or services may be for the guest devices to passively listen for periodic notifications issued by the casting devices and / or services.

[0061] In some embodiments, the casting services and techniques described herein can be built into the same server as that of the gateway (e.g., a captive portal gateway). In other embodiments, it may be difficult to build 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 built into the gateway (e.g., with a firmware update on the gateway device), which may enable a separate casting server (e.g., a casting server separate from the gateway) to receive and process casting traffic from subscribers that are allowed 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 a casting service. These IP addresses may be from the subscriber VLAN (i.e., the same subnet) or may be on another subnet to which the gateway may 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 can 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 through another intermediary device, such as a switch or collection of switches).

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

[0065] A casting packet from a guest device may be structured as follows: L2:src=guest MAC, dst=NSE MAC L3:src=guest IP, dst=casting IP L4: May or may not be considered (e.g., could be UDP or TCP) Here, L2 refers to layer 2 of the ISO networking model, which is responsible for migrating data between adjacent network nodes, L3 refers to layer 3 of the ISO networking model, which is responsible for routing data between different networks using IP addresses, and L4 refers to layer 4 of the ISO networking model, which is responsible for enabling communication between processes or applications running on different hosts.

[0066] Assuming TCP, the guest device will think that it has opened a connection to the casting IP address, which is 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 the subscriber VLAN, the NSE may retransmit the packet on the casting Ethernet port (e.g., the default gateway reads the destination MAC address and forwards the MAC address directly to the specific port where the MAC address is plugged in, e.g., the Ethernet port to which the casting server is connected).

[0067] Here, packets can 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 the casting IP. On retransmission, the SRC MAC can be preserved to be that of the guest device. By doing so, the guest device can be tracked by MAC address. Tracking by IP instead is possible, but IP addresses may change much more frequently than MAC addresses, so tracking guest devices by MAC may be more reliable.

[0068] The retransmitted packet may therefore be structured as follows: L2: src = guest MAC, dst = casting server MAC L3:src=guest IP, dst=casting server IP L4: Conserved

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

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

[0071] Here, the DST MAC would typically be 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 a subscriber table to ensure that the subscriber (e.g., guest device) is known, and then respond with its own MAC. Thus, the NSE may act as a proxy for the subscriber guest device.

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

[0073] Thus described, the NSE can be thought of as providing routing services for specific IPs that are 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, guest devices may attempt to route them normally via their default gateway IP.

[0074] The mechanisms described above provide handling of control traffic used for casting (e.g., Chromecast control traffic). However, means of facilitating casting discovery may also be provided, which may involve the following two components: (1) Receiving mDNS queries from guest devices (2) Sending unsolicited notifications (e.g., Chromecast notifications) from the casting server to the guest device.

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

[0076] Regarding (2), an mDNS notification may involve a packet structured as follows: L2:src=casting server MAC, dst=guest MAC 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 may allow the system to answer guest device multicast queries with unicast responses (so other guest devices do not see the response). If a multicast DST MAC is used, all guest devices on the network may see the notification.

[0078] In some embodiments, the NSE MAC is used as the DST MAC and the packet is forwarded to the guest device as is done for normal control traffic, if any. However, in the case of a multicast IP, the DST IP may not be able to be used to look up the MAC address in the subscriber table. To solve this problem, if any, the packet may be transmitted to the NSE as follows: L2:src=guest MAC, dst=NSE MAC 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 one would normally expect. The NSE can handle these packets by noting that the DST IP is multicast and using the inbound SRC MAC as the DST MAC for retransmissions. The NSE can set its own MAC as the SRC MAC. This solution may result in non-standard packets, but it may solve the problem identified above.

[0080] Another solution could be to always set the DST IP to be the intended guest IP and L2 address as one would normally expect. When the NSE receives the packet, it can use the L4 header to detect that the packet is equipped with an mDNS notification. The NSE can 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 can be replaced to be 224.0.0.251 (but only if the mDNS packet 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, there may be a flag in the mDNS response that indicates whether it is answering a unicast or multicast query. If applicable, that flag can be used to determine whether to replace.

[0082] (Dual network casting system) FIG. 7 illustrates how a casting server 302 according to aspects of the present disclosure may operate in a dual network casting system. The casting server 302 is in network communication with a casting device 310 via a cast network 306, and the casting server 302 is in network communication with a guest device 308 via a guest network 304 that is separate from the cast network 306. When a guest attempts to connect his / her 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 the TV), the casting server 302 receives location information associated with the guest device 308 and a MAC address associated with the guest device 308. For example, the location information may be an indication of a current location of the guest device 308. As another example, the location information may be an indication of a display device that displays a QR code scanned by the guest. As another example, the location information may be embedded within a QR code or link that is scanned and / or activated by the guest device 308.

[0083] The casting server 302 then determines whether the guest device 308 is co-located with the casting device 310 based on the location information. In some embodiments, the casting server 302 may determine the room to which the guest or guest device is assigned and determine whether the room matches the room in which the casting device 310 and / or the display device 312 are located. If the guest device 308 and the casting device 310 are co-located, the casting server 302 generates a pairing between the guest device 308 and the casting device 310 using the MAC address of the guest device 308 (or, in some other cases, the IP address of the guest device). 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 pairings generated by the casting server 302.

[0084] After the pairing is stored, the casting server 302 generates a packet forwarding rule 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 a bidirectional packet forwarding rule that enables the guest device 308 to communicate with one or more of the casting devices 310. In some other embodiments, the packet forwarding rule may be a unidirectional packet forwarding rule or a pair of unidirectional packet forwarding rules configured to operate as a bidirectional packet forwarding rule. The packet forwarding rule may then be stored in a storage device (such as a cloud service, a hard disk drive, or RAM) accessible by the casting server 302.

[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, including a proxy IP address usable by the guest device 308 to communicate with the casting device 310, based on packet forwarding rules, with or without communication with the casting device 310, and the casting server 302 then receives a casting request from the guest device 308 indicating the proxy IP address, and the casting device 310 can then download the requested content from the Internet and cast the requested content on a display device 312 in communication with the casting device 310, for example, using the information transmitted by the casting server to the casting device. Such information may include, among other things, the location of the content, required authentication information, etc.

[0086] (Communication between guest devices, casting devices, and casting servers) FIG. 8 illustrates a process of how a guest 800 communicates with a casting device 801 through a casting server 802. When a guest 800 opens a video streaming app on his / her guest device 803 (e.g., a smartphone), the app may send out a discovery packet on the guest network to look for a casting device 801. For example, the app may send out a multicast DNS request or query to look for a casting service. Typically, these requests are multicast or broadcast on a Wi-Fi network, and any casting devices that happen to be on the network may respond. However, since the guest device 801 is not on the same network as the casting device, in a typical situation, there may not be any response to their mDNS query.

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

[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 available casting devices to talk to. On the other hand, if such pairing 804 exists, the casting server 802 may send a response impersonating a casting device on the cast network and providing an IP address that the guest device 803 may 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 impersonating. 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) that is connected to (or in network communication with) the casting device 801.

[0089] Once a casting device 801 has been discovered, the second stage is to actually perform the casting. For example, a guest 800 may open a media application on his / her guest device 803 (e.g., a smartphone), search for any available casting devices, and select a casting device that appears in a list of available casting devices (the discovery process described above generates this list). In response to the selection, a TCP connection is formed with an 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 packets received from the guest device 803 to the appropriate casting device 801 on the cast 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 generation) FIG. 9 illustrates the process of generating packet forwarding rules 902 by the casting server 901 to form TCP connections between guest devices 907, 908 and casting devices 904, 905, 906. Once the pairing is created, the casting server 901 may create packet forwarding rules 902 that stipulate that when a guest device 907, 908 with a particular MAC address attempts to open a TCP connection with this particular proxy IP 903, the packets may be forwarded to the appropriate casting device 904, 905, 906 using destination NAT. There may be a flow of packets coming 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 will allow the guest devices 907, 908 to connect to the casting devices. In addition, there may be a reverse rule that allows such traffic from the casting devices back to the guest devices. Thus, the casting server 901 may create and / or install bidirectional rules for packet forwarding that allow that type of TCP connection to occur. 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 the pairing exists so that the mDNS handler knows whether to respond to mDNS queries from the guest device.

[0091] The casting devices 904, 905, 906 may have a special receiver application for downloading the content to be cast on the display device. Such a receiver application may be registered with the casting device by the content creator so that the casting devices 904, 905, 906 are shipped with the receiver application or the receiver application may be downloaded onto the casting device. Once a control connection (e.g., TCP) is established between the guest devices 907, 908 and the casting devices 904, 905, 906 via the casting server 901, the guest may provide control commands, such as play or pause the content, via the TCP connection. When requested, the receiver application on the casting devices 904, 905, 906 may connect to the Internet and fetch the requested content without requiring the content to be streamed from the 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 on the cast network, where the casting server software is an application that runs outside the operating system. In some cases, such an approach may be too CPU intensive and may not scale. In other embodiments, the packet forwarding rules 902 are installed on the operating system (e.g., Linux) of the casting server 901, 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 a packet is received by the casting server 901 and there is no specific rule to allow the packet to be transmitted to the other side, the packet may simply be dropped. To prevent that, a packet forwarding rule 902 that specifies that guest device X may communicate to casting device Y on the other network may be installed in the packet forwarding engine, which will allow packets from guest device X to flow to casting device Y and back.

[0093] In some embodiments, using the 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 the packet forwarding rules 902 are configured to direct packets to the appropriate destination rather than having to rely on the casting server software to process the packets, the packets do not have to leave the operating system; they are received by the casting server network interface, processed by the operating system, and transmitted through the casting server network interface, bypassing the casting server software and eliminating the need to store packets to be read by the casting server software (thereby reducing the amount of data duplication). For example, packet forwarding rules 902 can dictate whether a given guest device 907 / 908 is allowed to communicate with a given casting device 904 / 905 / 906 (or vice versa); if the operating system determines that such communication is allowed, the IP address is translated and the packet is conveyed to the recipient; otherwise, the packet is dropped.

[0094] In some embodiments, when the casting server 901 receives a multicast DNS packet, it will forward the packet to the casting devices 904, 905, 906. In other embodiments, the casting server 901 does not forward any mDNS queries, and instead spoofs responses from the casting devices 904 / 905 / 906 without actually forwarding the mDNS queries to the casting devices 904 / 905 / 906 (e.g., by caching the responses from the casting devices 904 / 905 / 906). For example, when an mDNS query is present, the casting server 901 may understand if a guest device 907 / 908 is paired to the casting device 904 / 905 / 906, and then the casting server 901 may spoof responses only from that particular paired casting device.

[0095] (Creating and removing pairings) FIG. 10 illustrates the pairing process of the casting system, including pairing creation and removal. 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 casting instructions. This may include a QR code that, upon activation, will cause the guest's guest device 1001 (e.g., a smartphone) to contact the casting server 1000 over 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 (e.g., in cloud or local storage) a pairing between the guest device 1001 and one or more casting devices 1002 in the guest's room. Once the pairing 1003 is created, the casting server 1000 may create one or more packet forwarding rules to allow mDNS discovery for the guest device 1001 to occur. In some embodiments, in response to receiving the 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, deny 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 packet forwarding rules for the pairing 1003 and enable mDNS discovery for the pairing 1003.

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

[0097] When pairing 1003 should be removed, casting server 1000 simply removes the packet forwarding rule. For example, a rule, essentially a packet whitelist 1004, or table of source and destination pairs that are allowed to pass, is maintained in storage accessible by 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 cloud service 1005 to casting server 1000 to remove this pairing 1003. Casting server 1000 may then delete the rule that allows forwarding between this guest device 1001 and that casting device 1002 with which pairing 1003 was. Pairings may be removed when a guest checks out or according to a schedule (e.g., every day at 1 p.m.).

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

[0099] (Proxy ARP) 11 illustrates the workflow of proxy ARP, including embodiments with or without a casting server 1100. A guest device 1101 may originate an ARP request requesting the MAC address of a computer on the network with a particular IP address; typically, if a casting server 1100 was not present, the casting device 1102 would respond directly, indicating that it has that IP address and providing its MAC address; the two computers would then be able to communicate directly.

[0100] However, when a casting server is introduced, the casting server 1100 gets in the way and the casting server 1100 may return its own MAC address. When a guest device 1101 requests the MAC address of a casting device 1102 with which the guest device 1101 may communicate, the guest device 1101 receives a response from the casting server 1000 that includes the MAC address of the casting server 1000 (instead of the MAC address of any casting device). Thus, all communications going to any device on the casting side of the network are effectively sent through the casting server 1000. Proxy ARP can force any traffic wanting 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 for traffic in the reverse direction). Now, when the casting device wishes to communicate with the guest device, it provides an ARP request and is told the MAC address of the casting side of the casting server, and the casting server forces any traffic the casting device has for the guest side of the network to go through the casting server.

[0101] When a 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 MAC address but two different IP addresses of the respective casting devices 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, a real IP (with a proxy MAC) is used to communicate with the different casting devices 1102. 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 1101 in two different rooms may be directed to two different casting devices 1102.

[0102] (Communication between guest devices, casting devices, and casting servers) FIG. 12 illustrates a network environment including a default gateway for implementing client isolation according to aspects of the disclosure. The diagram shows the workflow of the 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 the casting device 1202, which is 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 the subscriber VLAN, the NSE may retransmit the packet on the casting Ethernet port (e.g., the default gateway reads the destination MAC address and forwards the MAC address directly to the 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 then respond to the ARP request by providing its own MAC (e.g., NSE MAC, below) in the reply packet. If the guest device 1201 provides its MAC address on the ARP request, the default gateway may reply with its own NSE MAC address in the reply packet sent to the guest device 1201. The default gateway may also reply with the MAC address of the casting server 1203 in the reply 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 on 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 the casting server 1203 can accept packets for the casting IP.

[0105] Upon retransmission, the SRC MAC can be preserved to be that of the guest device. By doing so, the guest device 1201 can be tracked by MAC address. Alternatively, tracking by IP is possible, but IP addresses may change much more frequently than MAC addresses, so tracking guest devices by MAC may be more reliable.

[0106] (Enumerated Implementations (EI)) Some examples of Enumerated Implementations (EI) 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 cause the accessed content to be cast on the display device; and a casting server comprising computer hardware, the casting server in network communication with the casting device via a cast network, the casting server in network communication with the guest device via a guest network separate from the cast network, the casting server receiving location information associated with the guest device and a MAC address associated with the guest device, determining based on the location information that the guest device is co-located with the casting device, generating a pairing between the guest device and the casting device using the MAC address of the guest device, and transmitting the pairing to a cloud service configured to manage and monitor a plurality of pairings on behalf of the casting device. receiving an indication from the cloud service that the cloud service has successfully stored the pairing; generating packet forwarding rules usable 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, causing the packet forwarding rules to be stored for later access by the casting server; receiving a discovery request from the guest device to discover a casting device usable by the guest device; forwarding a discovery response back to the guest device based on the packet forwarding rules, the discovery response including a proxy IP address usable by the guest device to communicate with the casting device, with or without communication with the casting device; receiving a casting request from the guest device, the casting request indicating the proxy IP address; downloading the requested content from the Internet to the casting device;and transmitting information usable by the casting device to cast the requested content on a display device in communication with the casting device.

[0108] EI 2: A system of any other EI provided herein or any combination of two or more EIs provided herein, wherein the casting device is configured to download 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.

[0109] EI 3: A system of any other EI provided herein or any combination of two or more EIs provided herein, wherein upon receiving a multicast DNS packet from a guest device, the casting server is configured to spoof a response from the casting device without forwarding the multicast DNS packet to the casting device.

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

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

[0112] EI 6: The casting server is configured to remove the pairing in response to a request to remove the pairing received from the cloud service, any other EI provided herein or any combination of two or more EIs provided herein.

[0113] EI 7: A system of any other EI provided herein or any combination of two or more EIs provided herein, wherein the packet forwarding rules are stored in random access memory (RAM) and in response to the pairing being removed, the packet forwarding rules are deleted from the 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 configured to force packets from a guest device or casting device through a casting server instead of through a default gateway of a local network associated with the guest device or casting device.

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

[0116] EI 10: A method of casting, the method including: receiving location information associated with a guest device and a MAC address associated with the guest device; determining that the guest device is co-located with the casting device based on the location information; generating a pairing between the guest device and the casting device using the MAC address of the guest device; transmitting the pairing to a cloud service configured to manage and monitor a plurality of pairings on behalf of the casting device; receiving an indication from the cloud service that the cloud service successfully stored the pairing; and generating a packet forwarding rule usable by a 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: causing packet forwarding rules to be stored for later access by a casting server; receiving a discovery request from a guest device to discover a casting device usable by 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, the discovery response including a proxy IP address usable by the guest device to communicate with the casting device, with or without communication with the casting device; receiving a casting request from the guest device, the casting request indicating the proxy IP address; and transmitting to the casting device information usable by the casting device to download requested content from the Internet and cast the requested content on a display device in communication with the casting device.

[0117] EI 11: A method of any other EI provided herein or any combination of two or more EIs provided herein, further comprising 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.

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

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

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

[0121] EI 15: A method of any other EI provided herein or any combination of two or more EIs provided herein, further comprising forcing packets from the guest device or casting device to pass through a casting server instead of a default gateway of a 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 from the guest device associated with an IP address and responding by returning a MAC address associated with the casting server.

[0123] EI 17: A non-transitory computer storage medium having stored thereon computer-executable instructions that, when executed by one or more computing devices, may include receiving location information associated with a guest device and a MAC address associated with the guest device, determining that the guest device is co-located with a casting device based on the location information, generating a pairing between the guest device and the casting device using the MAC address of the guest device, transmitting the pairing to a cloud service configured to manage and monitor a plurality of pairings on behalf of the casting device, receiving an indication from the cloud service that the cloud service successfully stored the pairing, and determining a packet forwarding route usable 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 casting server configured to receive a discovery response from a guest device based on the packet forwarding rules, the discovery response including a proxy IP address usable by the guest device to communicate with the casting device based on the packet forwarding rules; receiving a casting request from the guest device, the casting request indicating the proxy IP address; and transmitting to the casting device information usable by the casting device to download requested content from the Internet and cast the requested content on a display device in communication with the casting device.

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

[0125] EI 19: A non-transitory computer storage medium of any other EI provided herein or any combination of two or more EIs provided herein, the operations further including, upon receiving a multicast DNS packet from the guest device, spoofing a response from the casting device without forwarding the multicast DNS packet to the casting device.

[0126] EI 20: A non-transitory computer storage medium of any other EI provided herein or any combination of two or more EIs provided herein, the operations further including responding to a multicast DNS request from a guest device by returning different proxy IP addresses to represent different casting devices.

[0127] (Terminology) All of the methods and tasks described herein may be performed and fully automated by a computer system. The 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 multiple processors) that executes program instructions or modules stored in memory or other non-transitory computer-readable storage media or devices (e.g., solid-state storage devices, disk drives, etc.). Various functions disclosed herein may be embodied in such program instructions or may be implemented in the computer system's application-specific circuitry (e.g., ASIC or FPGA). When a computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by converting physical storage devices, such as solid-state memory chips or magnetic disks, to different states. In some embodiments, the computer system may be a cloud-based computing system whose processing resources are shared by multiple different business entities or other users.

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

[0129] Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein may be performed in a different order, added, merged, or omitted entirely (e.g., not all described acts or events are necessary to practice an algorithm). Furthermore, in some embodiments, acts or events may be performed simultaneously rather than sequentially, for example, through multithreading, interrupt processing, or multiple processors or processor cores, or on other parallel architectures.

[0130] The various illustrative logic blocks, modules, routines, and algorithm steps described in connection with 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 connection with the embodiments disclosed herein can be implemented or performed 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, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor device may be a microprocessor, but in the alternative, the processor device may be a controller, microcontroller, or state machine, combinations thereof, and the like. The processor device may include electrical circuitry 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. A processor device may 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 in conjunction with a DSP core, or any other such configuration. Although described herein with respect to primarily digital technology, a processor device may also include primarily analog components. For example, some or all of the rendering techniques described herein may be implemented in analog circuitry or combined analog and digital circuitry.The computing environment may include any type of computer system, including, but not limited to, a microprocessor-based computer system, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within a consumer electronics device, to name a few.

[0131] Elements of the methods, processes, routines, or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable storage medium. An exemplary storage medium may be coupled to the processor device such that the processor device may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor device. The processor device and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor device and the storage medium may reside as discrete components in a user terminal.

[0132] In particular, conditional language used herein, such as "can," "could," "might," "may," "eg," and the like, is intended to generally convey that one embodiment includes a feature, element, or thing, while other embodiments do not include it, unless specifically stated otherwise or understood otherwise within the context as used. Thus, such conditional language is generally not intended to imply that the feature, element, or thing is in any way required for one or more embodiments, or that one or more embodiments necessarily include logic for determining whether those features, elements, or things should be included or implemented in any particular embodiment, with or without other input or prompts. The terms "comprising," "including," "having," and the like, are synonymous and used inclusively in a non-limiting manner and do not exclude additional elements, features, acts, operations, etc. Additionally, the term "or," when used, for example, to connect a list of elements, is used in its inclusive sense (not in its exclusive sense) to mean one, some, or all of the elements in the list. The term "set" is used to include "one or more." For example, a set 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 otherwise understood in the context as it is commonly used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, or Z), unless specifically stated otherwise. Thus, such disjunctive language is not intended, and should not generally imply, that an embodiment requires that at least one of X, at least one of Y, and at least one of Z each be present.

[0134] Any process illustrations, elements, or blocks in the flow diagrams described herein and / or depicted in the accompanying figures should be understood as potentially representing modules, segments, or portions of code that comprise one or more executable instructions for implementing specific logical functions or elements in the process. Alternative implementations are included within the scope of the embodiments described herein, where elements or functions may be omitted, performed substantially simultaneously, or in reverse order, or in other orders than those shown or discussed, depending on the functionality involved, as would be understood by one of ordinary skill in the art.

[0135] Unless expressly stated otherwise, articles such as "a" or "an" should be construed generally to include one or more of the described items. Thus, phrases such as "a device configured to" are intended to include one or more of the listed devices. Such one or more listed devices may also be collectively configured to perform the listed enumeration. For example, "a processor configured to perform enumerations A, B, and C" can 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 above detailed description shows, describes and points out novel features as applied to various embodiments, it should be understood that various omissions, substitutions and changes in the form and details of the illustrated devices or algorithms may be made without departing from the scope of the present disclosure. As can be recognized, certain embodiments described herein may be embodied in forms that do not provide all of the features and benefits described herein, since some features can be used or practiced separately from others. All changes that come within the meaning and range of equivalency of the claims are intended to be embraced within their 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, 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 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