Discovery, access control, and communication with networked services

Abstract
Particular embodiments permit a computer program running within a security sandbox to discover and communicate with networked services for example print servers, or remote control programming interfaces for TVs, stereos, and game boxes. The sandbox allows the computer program to originate unicast connections to a limited set of hosts but otherwise provides no access to the network. Particular embodiments may require no prior install, zero configuration, no account names or passwords, and yet resists spam. This is achieved by using centralized global infrastructure to coordinate the communications rather than local multicast, anycast, or datalink broadcast.
Description
BACKGROUND

Particular embodiments are in the technical field of networking technology. More particularly, particular embodiments are in the technical field of computer and embedded device communications.


The Internet and home entertainment devices usually do not communicate with one another. Attempts have been made to bridge these two: game consoles communicate over the Internet so allowing many players to engage in the same game, Apple TV downloads videos from iTunes, Microsoft media extenders play media housed on a user's personal computer. The dominant paradigm is to extend the home entertainment device so that users can search the Internet or nearby computers from the device. Less has been done to extend the PC to push content to the entertainment device.


Set-top boxes exist that stream videos from websites to the TV. The set-top boxes all assume the user sits in front of the TV when navigating between videos. Due to the limitations of TV remote controls, no acceptable user interface has been devised to enable users to hunt through catalogs of thousands of titles. Computers have the advantage of a keyboard and mouse: rich input devices that have performed well for inputting queries to web search engines and video web sites. An entertainment system might exploit the advantages of the computer to push the most relevant content to the TV leaving the home entertainment user interface to handle the smaller problem of hunting through tens or hundreds of titles.


In the case of a joint venture between Amazon and TiVo, a user of Amazon Unboxed can click on a purchased video and it is then downloaded to the user's TiVo Internet-equipped digital video recorder. The TiVo then plays the video directly to the user's TV. NetFlix has a similar arrangement with Roku. However, both products require user configuration and a pre-existing user registration, e.g., for Amazon/TiVo the user must have an account that is linked to the user's TiVo account which is associated with the user's TiVo. The Amazon-TiVo relationship is explicit and does not extend beyond Amazon to other websites. The “click to send” to your TiVo functionality is an example of extending the computer to push content to a device over a network.


SUMMARY

Particular embodiments provide a building block enabling any website to send video to an entertainment device within the user's home without requiring user configuration or account registration, and without exposing the user's device unduly to spam, i.e., unsolicited content pushed from websites or other users.


Particular embodiments enable the following scenario: Alice uses her laptop to browse a website foo.com that serves video. The website contains an Adobe Flash-based video player. Alice watches a video v for a few seconds and decides it is interesting and would like to view the video on her television. Below the video is a button that says. “Send to your living room TV.” Alice clicks the button, and a dialog box appears, “foo.bar is attempting to send V to your living room TV. Do you want to allow foo.bar to send videos to your TV?” She clicks “yes.” and video V starts playing on her living room TV.


The next day Alice goes to work. While browsing the web she stumbles on a video on bar.com that she would like to watch when she gets home. Even though bar.com and foo.com are not the same website, she sees the name of her television in a button on the website. She clicks on the button, the same message “bar.com is attempting . . . ” appears to which she again clicks “yes.” When she gets home that night, the program is available on her television.


The discovery of the TV did not require Alice to install anything on her laptop; it did not require her to provide any configuration on her laptop; it did not require her to have any account with foo.com, bar.com or any third party; and it did not require her to configure her television other than to provide it with a human-friendly name when she first purchased the TV. If the TV is manufactured with a reasonable human-friendly name (e.g., Company X 36″ TV) then even this step can be skipped. This allows minimal configuration or a truly zero-configuration solution. All of this is achieved within the security constraints imposed by the web browser, and in a manner that resists spam, i.e., particular embodiments resist web sites and other users sending unsolicited content to Alice's TV.


Alice's forays are compelling example uses of particular embodiments. More generally the television could be any device: a stereo, game console, another computer. The communication between the website and the device need not be a message telling the device to play a video but could be any communiqué. Adobe Flash could be replaced with Microsoft Silverlight or any runtime environment imposing a security sandbox that meets the constraints described in Section 0. Lastly the dialog prompting the user for permission to send the message could be replaced with any user interface component that requests a policy decision from the user regarding the communication to take place. Or default or previously established policy might forgo the policy prompt.


Particular embodiments specify how devices are discovered and how messages are conveyed to these devices without revealing any unique identifiers for the devices to web sites. Particular embodiments also specify how policy can be implemented with little or no local persistent storage on the user's personal computer, without requiring the user to make policy decisions repeatedly for the same website when there is non-zero persistent storage, and without permitting the website to modify or subvert the policy.


A further understanding of the nature and the advantages of particular embodiments disclosed herein may be realized by reference of the remaining portions of the specification and the attached drawings.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 illustrates the terminology “private networks” and “public networks” used in describing the present invention.



FIG. 2 illustrates a discoverable service using the centralized embodiment announcing its existence to the discovery service.



FIG. 3 illustrates a sandboxed program using the centralized embodiment discovering and communicating with the discoverable service.



FIG. 4 illustrates sandboxed program using the centralized embodiment to forward communications via central infrastructure called the discovery service to a discoverable service when both the sandboxed program and the discoverable service reside on the same private network;



FIG. 5 illustrates how a sandboxed program implementing the centralized embodiment forwards communications to a discoverable service when the discoverable service and the sandbox reside on separate private networks.



FIG. 6 presents a minimalist state machine for the announce functionality of a discoverable service implementing the centralized embodiment.



FIG. 7 presents a minimalist state machine for a sandboxed program implementing the centralized embodiment to discover discoverable services.



FIG. 8 presents a minimalist state machine for a discovery service implementing the centralized embodiment to store state for announcements from discoverable services and to answer discovery requests from sandboxed programs.



FIG. 9 illustrates a discoverable service using the direct embodiment announcing its existence to the discovery service.



FIG. 10 illustrates a sandboxed program using the direct embodiment discovering and then communicating directly with a discoverable service residing in the same private network.



FIG. 11 presents a minimalist state machine for the announce functionality of a discoverable service implementing the direct embodiment.



FIG. 12 presents a minimalist state machine for a sandboxed program implementing the direct embodiment to discover discoverable services within its private network.



FIG. 13 presents a minimalist state machine for a discovery service implementing the direct embodiment to store state for announcements from discoverable services and to answer discovery requests from sandboxed programs.



FIG. 14 presents a minimalist state machine for a sandboxed program implementing the direct embodiment to lookup a discoverable service's public address and other service information for a discoverable service believed to reside in a remote private network.



FIG. 15 provides an example of an embodiment where the security sandbox is Adobe Flash running within a web browser. The sandboxed program discovers a device running a discoverable service.



FIG. 16 illustrates the separate discovery agent extension to the direct embodiment.



FIG. 17 illustrates the separate discovery agent extension as exemplified using Adobe Flash embedded in a web page.



FIG. 18 illustrates the policy extension as used with the direct embodiment.



FIG. 19 illustrates announcing and discovery with the remote extension to the direct embodiment.



FIG. 20 illustrates direct communication between a sandboxed program and a discoverable service on different private networks.



FIG. 21 illustrates the retractable access extension to the direct embodiment.





In all figures, this document adopts notation with syntax identical to that of the programming language Python. Brackets [ ] surround a list; curly brackets { }surround a dictionary; and commas separate elements in a dictionary, elements in a list, or arguments in a call. Lists appearing in figures sometimes contain a single element, but this should be taken to mean that there can be zero or more elements in the list. In some cases the semantics of a zero element list may be ill-defined. For example, there is no reason and no possibility for a device with zero network interfaces to announce itself to the network. Dictionaries contain key-value pairs. Keys are unique, but values need not be so. The key and value are separated by a colon. In a call, particular embodiments present variable name and value separated by the assignment operator ‘=’. Values are represented using italics. Values are provided for purposes of illustration with the understanding that they should be replaced for each real-world scenario, e.g., replace “name” with the actual name of some entity.


DETAILED DESCRIPTION OF EMBODIMENTS

When the Internet was first designed in the late 60's and early 70's all nodes were provided with static IP address assignments and all packets were routed only based on IP address. IP addresses were hard to remember so nodes were assigned names, but not until the Domain Name System (DNS) was there a single scalable distributed database for translating domain names to IP addresses.


The DNS uses domain names not only to name nodes but also to specify administrative boundaries and has been overloaded to locate nodes serving a particular function and to locate services running on particular ports. For example www.example.com refers to the nodes providing World Wide Web services in the administrative domain example.com. If a user working at the example company wishes to find a printer he or she might look up ipp.example.com where ipp stands for “Internet Printing Protocol.” However, to do so would require the user to know he or she is on a network under the same administration as example.com. When a computer boots for the first time, it has no IP address and it does not know its administrator's domain. If a computer moves its IP address might change and the administrator of the network in which the computer finds itself might have changed. The printer ipp.example.com may no longer be the appropriate printer or may no longer be accessible.


To allow users to boot or move their computers into networks without requiring any a priori knowledge or user configuration, most computers implement some form of Zero Configuration networking (Zeroconf). All modern Apple computers implement a form of Zeroconf called Multicast DNS (MDNS) and DNS-based Service Discovery (DNS-SD) as parts of Bonjour. Multicast DNS is similar to the Internet's Domain Name System (DNS) except every node in the network acts as a server. When a computer multicasts a query for the IP address of the node with domain name “foo,” if “foo” is on the network then “foo” responds with its IP address. As with DNS, the query need not be for a node's IP address, but may be a query for a named service. PoinTeR (PTR) resource records point from one domain name to another. With DNS-SD, the user looking for service “bar” queries for a PTR record for domain name bar.example.com, where “bar” and “example.com” can be replaced with any service and domain name respectively. The PTR record maps to a domain name of the form

    • <instance>.<service>.<domain>


      where <instance> is replaced with a human-friendly name and <domain> can be any domain name, but for discovering services on the local network, the domain name is “local.” For example, to discover the printers on the local network, a client queries for the PTR record for _ipp.tcp.local. Assume there are two printers in the network named “1st floor” and “mezzanine.” These two printers return PTR resource records to the respective domain names:


1st floor._ipp._tcp.local


mezzanine._ipp._tcp.local


Assume the client wants to print to the printer named “1st floor,” the querying client then sends a second query for the service (SRV) record for “1st floor.” The SRV record contains the port number and canonical domain name for the printer. Now that the client has uniquely identified the printer and the port number on which the printer's print service application is running, the client sends the job to the printer.


Apple's MDNS and DNS-SD work when the application has access to multicast. However, the security sandbox as described in Section 0 does not allow access to multicast: Adobe Flash employs such a sandbox and thus a flash-based application running in the browser cannot directly discover a printer, TV, or other local networked peripheral. When a user wishes to print a web page, the browser rather than a sandboxed program initiates the print process. The browser has access to multicast or indirectly has access to MDNS via the Bonjour system service provided by OS X or as an installed service on nodes running Unix or Microsoft Windows.


Microsoft's competing discovery mechanism Simple Service Discovery Protocol (SSDP) relies on UDP unicast and multicast. Neither UDP unicast nor multicast is available within the security sandbox described in Section 0.


Similarly the IETF's Service Location Protocol (SLP)(4), UPnP (which is based on SSDP), and uTorrent's Local Service Discovery (LSD) use multicast to discover services within the local area network and thus share the same problem with MDNS/DNS-SD and SSDP.


A node on the Internet is a computer or device that has an Internet Protocol (IP) address. Nodes include but axe not limited to laptops, printers, desktop computers, and IP-equipped televisions, stereos, and game consoles. When a node communicates with another node it sends a packet that like an envelope in the postal mail system contains a message and bears a source and destination address. Messages, especially lengthier messages, may span multiple packets. With a packet, the addresses are IP addresses. The IP address is a numeric address not generally intended for human consumption, but rather is used by nodes inside the Internet to forward packets toward the destination node. Many nodes on the Internet also have a human-friendly domain name that uniquely names the node. A domain name may also refer to a set of nodes. For example www.google.com refers to the set of computers that provide the human-facing portion of google's web search service.


A server refers to a node or set of nodes that respond to queries from clients. A node may be both a server and a client depending on the role the node takes in processing a particular query/response. Google's nodes running at www.google.com are servers and the nodes that query google.com with web searches are clients.


Particular embodiments refer to devices or discovering services offered by a device. For illustration, this is appropriate since embodiments are applicable to discovering services offered by televisions, digital video recorders, printers, or other special-purpose electronics that consumers usually refer to as “devices.” For example, the service provided by a printer is to print a document while the service offered by a networked TV may be to play a video. More generally this document describes mechanisms to discover services within a network. Any service which can be discovered using embodiments of the discovery service is a discoverable service.


The Internet may be divided into public and private networks (as illustrated in FIG. 1). All nodes in the public network have IP addresses that any other node in the public Internet can use as a destination IP address, and the public Internet will try its best to forward any packet so addressed to the appropriate destination node. Each node on a private network has an IP address that is only guaranteed unique within its private network. This document refers to each node in a private network as a private node. FIG. 1 illustrates a collision between IP address assignments meaning two private nodes 103, 104 in different private networks 101, 102 have the same IP address. Private IP addresses can be used to route packets within their respective private networks 101, 102, but due to the ambiguity resulting from collisions in address assignments, private IP addresses cannot be used to route packets on the public Internet 107. Home users and corporations often have their own private networks on which multiple nodes can communicate with each other using their private IP addresses.


To communicate with nodes over the public Internet, private nodes communicate via a Network Address Translator (NAT) 105, 106. A NAT straddles private and public networks and has both a public IP address and a private IP address. The NAT replaces the source address on each packet destined for the public Internet with the NAT's public IP address. A response to the packet is addressed for the NAT. The NAT translates the destination address from packets arriving from the public Internet to the appropriate private IP address within its private network. In FIG. 1, all given IP addresses are examples that serve for the following illustration: a packet from private node 103 destined for private node 104 would start with source address 192.168.1.10 and destination address 128.213.6.8. Private node 103 may not even be aware of private node 104's private IP address. When the packet leaves private network 101, the NAT 105 translates the source address from 192.186.1.10 to 69.106.234.74. As the packet transits the public Internet 107, the packet has source address 69.106.234.74 and destination address 128.213.6.8. When the packet arrives at NAT 106, the NAT replaces the destination address with the appropriate private IP address 192.168.1.10 and then forwards the packet to private node 104.


To address a packet to a specific application running on a node, packets also contain source and destination port numbers. Any given application may send from or listen on any number of ports, but a port belongs to only one application at any given time. As a shorthand this document often refers to a sender's or receiver's IP address x and port number y as the address pair (x,y). The pair is denoted as a sender's or receiver's address. When the IP address in an address pair is a private IP address, this is denoted the private address. When a packet passes through a NAT from a private network to a public network, the sender's private address is mapped to a port on the NAT's public-facing network interface. The port number on a NAT mapped to a private address and the NAT's public IP address together constitute a sender's or receiver's public address. Many NATs attempt to preserve port numbers when mapping from private to public IP addresses, but this is not always possible. Assume two packets destined for www.goole.com port 80 arrive from the private network: packet 1 has sender private-IP and port (x,y), packet 2 has sender private-IP and port (w,y). Both packets have the same sender port. A NAT often has only 1 public IP address here denoted n. If the NAT maps packet 1 to (n,y) and maps packet 2 to (n,y) then both packets appear to come from the same private node. Instead the NAT maps either packet 1 or packet 2 onto a sender port other than y so that when responses arrive from google, the NAT can forward those responses back to the correct private nodes. The ambiguities and limitations imposed by NATs may influence the design of certain embodiments.


When a user visits a web site, the web browser downloads a number of web pages often containing one or more scripts written in Javascript or Actionscript. Such scripts or anything that executes in a web page are usually constrained in the types of operations they can perform. These constraints protect the user's privacy and the security of the user's computer. These constraints together comprise a security sandbox or more tersely a sandbox. Hereafter anything that executes in a security sandbox is referred to as a sandboxed program. The sandboxed program may be a script, binary executable, intermediate bytecode, abstract syntax tree, or anything that can be executed with the appropriate runtime environment. A security sandbox may or may not run inside a web browser.


Particular embodiments assume a user runs a sandboxed program. This program wishes to communicate with services running on devices that reside in the same private network. The program calls a discovery agent that finds discoverable services within the same private network and updates contact information (addresses) for services that were previously contacted but may now reside in another private network. The discovery agent tells the sandboxed program about the discovered services. Section 0 details the constraints imposed by the security sandbox. Subsequent sections describe the discovery process, and several variations that permit direct communication when the sandboxed program and discoverable service reside in different private networks.


Security Sandbox


Particular embodiments operate within a security sandbox that imposes the following restrictions:

    • Sandboxed programs may have no storage that persists between executions of the sandboxed program.
    • Sandboxed programs may have no access to the network other than to open unicast connections to the origin server and no access to any other server unless the server explicitly permits the communication. The communications may be further constrained to using TCP and/or UDP, or even further to HTTP or a subset of application-layer unicast protocols.
    • Sandboxed programs may not have access to any local resources (file system, devices, etc.) other than memory, computation, and space to render a user interface on the user's screen.
    • Sandboxed programs may not be permitted to communicate with other programs running on the local system.
    • Sandboxed programs may not be permitted to communicate with other programs running within other security sandboxes except via a limited, mutually agreed programming interface enforced by the sandboxes.


Particular embodiments may also work in security sandboxes that impose a subset of these restrictions or weaker versions of these restrictions.


Particular embodiments may not require substantial computation or memory and reasonable constraints on computation or memory usage will not affect the proposed embodiments.


In the case of Adobe Flash, the explicit permission to communicate with a server comes in the form of a crossdomain.xml file that specifies permissions to access a domain x and is stored at URL http://x/crossdomain.xml. After the crossdomain.xml file has been communicated, further communication with existing Adobe Flash 8 through 10 libraries occurs over HTTP. With Adobe Flash 8 through 10, sandboxed programs can communicate with each other via LocalConnection objects or via Javascript calls exported via the ActionScript ExternalInterface. LocalConnection and ExternalInterface mechanisms are provided as examples, other mechanisms may exist for sandboxed programs to communicate with each other, and other mechanisms may be introduced in future versions of Adobe Flash.


A service that is designed to communicate with sandboxed programs is called a sandbox-reachable service. A service designed to communicate with a program running in an Adobe Flash sandbox is called aflash-reachable service. Specifically, a flash-reachable service speaks HTTP and returns a sufficiently permissive crossdomain.xml file.


Centralized Embodiment


Traditionally a program multicasts or broadcasts to its local network to discover available networked services. Because sandboxed programs cannot use multicast or broadcast, they discover services via some intermediary. This intermediary is referred to as the discovery service. Services announce themselves to the discovery service, and discovery agents running with the sandboxed program query the discovery service to discover previously announced devices.


In the centralized embodiment of this invention, as shown in FIG. 2, a device 201 announces its existence to the discovery service 207.


Each discoverable service running on device 201 has a globally unique id (GUID) denoted g. The GUID is provided only to the discovery service 207 and to nodes on the same private network. The GUID is valuable in that it identifies the device even when the device's public or private addresses change. e.g., the user's service provider may reallocate the customer's public IP address(es), the device owner may change Internet service providers, or the private network's Dynamic Host Configuration Protocol (DHCP) may reassign IP addresses. In practice the GUID can be assigned during manufacture, or the GUID can be a random number drawn from a large enough space that the resulting number is unique with high probability. The latter allows the GUID to be changed at any time without contacting a central authority. An owner might wish to change a device's GUID if he or she believes the GUID has been compromised. e.g., as might be evidenced by a sudden increase in spam appearing on her TV.


The discoverable service on device 201 also has a human-friendly name denoted by the key “human name” with value “name.” The human name is not intended to be globally unique and possibly not even locally unique, but rather to be meaningful to the users of a service. Example names include “living room TV” and “bedroom printer.” Device 201 also has at least one IP address 202 in order for it to communicate to the network. Device 201 may have more than one IP address. If the device 201 sits inside a private network that is connected to the public Internet via a NAT 204 then all of the device's IP addresses are private IP addresses. Any communication sent or received by this device must originate or be destined to a program with a port number. Thus device 201 has a both a private IP and port pair 202, hereafter called the address pair and illustrated as (x,y) in FIG. 2. Quite often the port number(s) assigned to a service are the same across the node's IP addresses, but this is not a requirement imposed by the Internet Protocol and thus the address and port are oft considered an indivisible pair when announcing, discovering, or communicating with a device.


When announcing, device 201 sends its service information: its GUID, and its human name 203. As the announce message propagates from the private network via the NAT 204 to the public Internet, the NAT 204 translates the device's announce message's private address (x,z) to its public address (u,w) 205 where u is the public IP address of the NAT 204. (x,z) differs from (x,y) because the connection over which the device announces may use an ephemeral source port, i.e., a port allocated for use by a single connection. Ephemeral ports are described in any textbook on TCP/IP. The end result of this translation is the message 206, which the Discovery Service 207 receives. The Discovery Service stores the service information for later lookup 208 during the discovery process.


In the centralized embodiment, the connection used for announcing is also used for forwarding all communications between sandboxed programs and the discoverable services. Thus the table 208 also contains connection state such as a socket file descriptor. Since a connection is initiated by the discoverable service to the discovery service, it is likely that such connections will be permitted by any NAT, especially if those connections use HTTP. Since the connection between the discoverable service and the discovery service is maintained, it can probably be used to route messages back through any number of intervening NATs so long as those NATs permit long-run HTTP connections to the discovery service. To prevent NAT mappings from timing out, the discoverable service, sends periodic keep-alive messages.


If only infrequent and small communications take place between sandboxed programs and any given discoverable service then the centralized embodiment is the best solution due to its simplicity.


When a user runs a sandboxed program that queries the discover service, the discovery service returns the GUID and any human names for the services behind the same NAT. The GUID ensures that the sandboxed program can distinguish between devices that have identical human names.



FIG. 3 illustrates the discovery process. A sandboxed program 304 running in security sandbox 303 sends a discovery message 306 to the discovery service 309. The discovery message 306 is addressed from the sandboxed program's 304 private address r,s 305. When the discovery message transits the Network Address Translator 307, the private address is translated to the sandboxed program's public address u,d 308 creating an otherwise identical discovery message but addressed from u,d. As with z in FIG. 2, d is most likely an ephemeral port allocated by the operating system on which the sandboxed program runs for use by this discovery message's connection. The discovery service 309 performs a lookup based on the message's public IP address u. If one or more devices are found that have the same public IP address u as the sandboxed program then the device(s) are assumed to reside in the same private network with the sandboxed program. This illustration follows from the illustration in FIG. 2 where there is a device 201, 301 with the same public IP address u. Thus the discovery service responds with the service information 310 for device 301.


Once the sandboxed program 304 has obtained device 301's service information, the sandboxed program has the necessary information to contact 301. When the sandboxed program 304404 decides to communicate with the discoverable service 301401, it forwards the desired payload to communicate with the destination service's guid 406409 through the NAT 407 to the discovery service 410. The discovery service looks up the connection state such as a file descriptor from the table shown in 208 and forwards the payload through this connection 411412 to the discoverable service 401.


By virtue of passing all communications through central infrastructure and having devices maintain connections to the central infrastructure, the centralized embodiment can penetrate commercially available NATs. FIG. 5 illustrates the centralized embodiment enabling communication between the sandboxed program 504 and the discoverable service 501 when they reside behind different NATs 507 and 513 respectively.



FIGS. 6 through 8 show state-transition diagrams for the centralized embodiment.


If there is no user configuration and devices and the sandboxed program come from disparate organizations, e.g., the device manufacturer and a website respectively, then the discovery service may be known to both a priori. In practice, this means the discovery service is global.


Variations on the Centralized Embodiment


In another embodiment, the announce message omits the human name. The human name would then not appear in the mappings maintained by the discovery service, and would not be communicated from the discovery service to the sandboxed program. The guid is all that is necessary to route packets through central infrastructure to the sandboxed program and device reside on the same private network. The human name could thus be obtained from further communication between the sandboxed program and the discovered service. The no-human-name embodiment has the drawback that the human name cannot be presented to the user until after at least the first call between the sandboxed program and the device has completed. Thus there would be no human name to present a meaningful error message when the sandboxed program cannot communicate with the discovered service. This may not be deemed a drawback if the sandboxed program calls the services to confirm they are reachable before their human names in the user interface.


For the centralized embodiment, the term “discovery service” is a bit of a misnomer. Central infrastructure provides both discovery and application-layer routing between the sandboxed programs and the discoverable services. The discovery service is logically centralized, but may be distributed across multiple servers to provide scale and robustness. The IP address space and the guid address space may be partitioned across these servers and/or replicated across subsets of the servers to provide failover.


For reasonable performance the service information for the two queries based on GUID or based on IP address may be stored in separate mappings (a.k.a., indices): from GUID to service information 208 and from public IP to service information 209. The traditional data structure for such lookups is a hash table though the mappings can be stored with different trade-offs in time and space complexity using a variety of data structures (e.g., tries, balanced trees, radix trees).


With some cost in lookup time, a Distributed Hash Table (DHT) permits a physically decentralized lookup data structure and associated message routing where the data structure can be spread across a wide number of nodes including the devices themselves. However DHTs introduce occasional NAT traversal problems, since many of the nodes in the DHT may be behind NATs. Furthermore, the nodes in a decentralized data structure are less trustworthy and thus using a DHT introduces potential spam problems (see Section 0).


Embodiment that Allows Direct Communication


With the centralized embodiment, all communications between sandboxed programs and discoverable services pass through the discovery service. The centralized embodiment requires an amount of infrastructure linear to the volume of communications between sandboxed programs and discovered services. Communicating without passing packets through central infrastructure is denoted as direct communications. By this definition, directly communicated packets may transit between two nodes on a Local Area Network (LAN) or may pass through multiple routers and NATs between two nodes on disparate networks. This section presents an embodiment wherein central infrastructure is still used to discover services, but once a service has been discovered all further communications takes place directly between the sandboxed program and the discoverable service. The embodiment that enables direct communications is hereafter called the direct embodiment.


With the direct embodiment, the central infrastructure requirement scales linearly with the number of announces and discovery requests it must process as opposed to linearly with all communications transiting between sandboxed programs and discovered services.


TVs, DVRs, and set-top boxes are usually not considered mobile devices. Non-mobile nodes may retain IP address assignments for days or longer even when repeatedly turned off. Discoverable services running on those nodes can choose to reuse the same port numbers whenever possible, thus making ip and port stable values worthy of caching. If the sandboxed program caches ip-port pairs as long as the ip-port pairs remain valid, the sandboxed program may communicate with the device hundreds of times for each time the sandboxed program must contact the discovery service.


To achieve direct communications between the sandboxed program and the discoverable service, the system communicates more information via the discovery service: the sandboxed program must at least know the private address of the discoverable service. For remote access the sandboxed program also needs the discoverable service's public address. Once a sandboxed program knows the discoverable service's addresses, it can attempt to establish communications. If the sandboxed program resides on the same private network with the discoverable service then opening a connection to the private address likely succeeds. Establishing direct communication between private networks and thus through one or more NATs is more complicated. Related discussion is thus deferred until Section 0.


When announcing, discoverable service 901 sends its service information: a list of all of its known addresses, the service's port v mapped on the NAT, its GUID, and its human name 903. In the centralized embodiment, the known addresses are the IP addresses of the discoverable service's device's network interfaces with their respective ports on which the discoverable service listens. In FIG. 9, the device has private IP address x and listens on port y 902.


As the announce message propagates from the private network via the NAT 904 to the public Internet, the NAT 904 translates the device's announce message's private address (x,z) to its public address (u,w) 905 where u is the public IP address of the NAT 904. (x,z) differs from (x,y) because the connection over which the device announces may use an ephemeral source port. i.e., a port allocated for use by a single connection. Ephemeral ports are described in any textbook on TCP/IP. The end result of this translation is the message 906, which the Discovery Service 907 receives. The Discovery Service stores the service information for later lookup during the discovery process.



FIG. 10 illustrates the discovery process. A sandboxed program 1004 running in security sandbox 1003 sends a discovery message 1006 to the discovery service 1009. The discovery message 1006 is addressed from the sandboxed program's 1004 private address r,s 1005. When the discovery message transits the Network Address Translator 1007, the private address is translated to the sandboxed program's public address u,w 1008 creating an otherwise identical discovery message but addressed from u,d. As with z in FIG. 2, d is most likely an ephemeral port allocated by the operating system on which the sandboxed program runs for use by this discovery message's connection. The discovery service 1009 performs a lookup based on the message's public IP address u. If one or more devices are found that have the same public IP address u as the sandboxed program then the device(s) are assumed to reside in the same private network with the sandboxed program. This illustration follows from the illustration in FIG. 2 where there is a device 901, 1001 with the same public IP address u. Thus the discovery service responds with the service information 1010 for discovered service 1001. The service information contains the known private 1002 and public addresses of the discovered service 1001.


Once the sandboxed program 1004 obtains device 1001's service information, the sandboxed program has the necessary information to contact 1001. When the sandboxed program 1004 decides to communicate with device 1001, to satisfy the requirements of the security sandbox, the sandbox queries the discovered service to obtain permission 1012 to communicate. Assuming the discovered service grants permission 1013, the sandboxed program 1004 proceeds to communicate with the discovered service 1014.



FIGS. 11 through 14 provide state-transition diagrams for the direct embodiment.



FIG. 11 shows the state machine for a discoverable service implementing the direct embodiment that periodically announces itself to the discovery service. The discoverable service starts 1101 by announcing 1102 to the discovery service and then periodically 11051106 thereafter. If the announcing service cannot establish a connection to the discovery service or the discovery service does not acknowledge the announce message then the announce times out 1107. Timeouts and other errors result in the announcing device delaying before attempting another announce. Variations on this state machine include exponentially backing off after a timeout or load-related error condition to avoid overwhelming the discovery service. The wait interval 1105 can be a system constant or the discovery service can suggest a wait interval just as BitTorrent trackers return an announce interval to BitTorrent clients.



FIG. 12 shows the state machine for a sandboxed program attempting to discover a service in the local private network then connecting to one selected by the user. Since more than one address may be reported for a given service, the sandboxed program attempts each in succession. Although this state machine shows each attempt to open a connection to the discoverable service occur in series, it is a trivial modification to the centralized embodiment's state machine to permit the connection attempts to proceed in parallel to reduce lookup time at the expense of potentially performing unnecessary queries.


The discovery state machine completes once the connection has been established 1211 because what is communicated over the connection is orthogonal to the discovery process.



FIG. 13 shows the state machine for a sandboxed program looking up the current public address of a previously discovered service that is believed to not reside on the current private network, e.g., because it was returned in a preceding request to the discovery service for services on the same private network. If a timeout or error occurs while waiting for a response 1303 to a lookup on a GUID the state machine moves 1313 to the error 1314 state and stops: since there is only one public address once a request fails the centralized embodiment provides no further recourse for this service. Section 0 discusses embodiments that employ NAT traversal techniques and/or fallback to a global message queue.



FIG. 15 shows a specific example of the direct embodiment. A web user surfs to a website 1501 downloads 15041505 a file x.html 1506 into his web browser 1502. The web page x.html 1506 contains markup that instantiates an instance of the Adobe Flash Player browser plugin passing “Sandboxed.swf.” The Flash Player downloads 15071508 the Adobe Shockwave File (.swf) named “Sandboxed.swf” 1509 from the content provider's web site 1501. The “Sandboxed.swf” is written in Adobe ActionScript. The Adobe Flash Player runs “Sanboxed.swf” 1509 in a security sandbox 1503. To find devices in its network, “Sandboxed.swf” calls the discovery service 1513, e.g., using an ActionScript XMLSocket or URLRequest. Since the discovery service 1513 resides across the network, the security sandbox 1503 requests permission to call the discovery service by requesting the discovery service's crossdomain.xml file 1510151215141515. If the discovery service permits any website to query it then it has a crossdomain.xml file semantically identical to the following:

















<?xml version=“ 1.0”?>



<cross-domain-policy>



<site-control permitted-cross-domain-policies=“all”/>



<allow-access-from domain=“*” />



</cross-domain-policy>










Once the security sandbox 1503 interprets the crossdomain.xml file, assuming access is permitted the sandbox allows “Sandboxed.swf” 1509 to send a Discovery( ) query 15161517 to the Discovery Service 1513. Assuming device 1523 has previously announced to the Discovery Service and resides behind the same NAT 1511, the Discovery Service returns a list of discovered devices 15181519 containing the service information for device 1523.


Assuming the device 1523 has address (x,y). “Sandboxed.swf” 1509 references device 1523 as if it were a server using an URL

    • http://x:y/ . . .


Before permitting any communication with device 1523, the Flash security sandbox 1509 performs an HTTP GET 1520 for the URL

    • http://x:y/crossdomain.xml


      and interprets returned crossdomain.xml file 1521. If the device allows communication from any website then the crossdomain.xml file 1521 is semantically identical to the crossdomain.xml file returned from the Discovery Service 1513.


Once the security sandbox 1509 has determined that communications are permitted, communication between the “Sandbox.swf” and the device commences.


Variations of the Direct Embodiment


As with variations of the centralized embodiment, a variation of the direct embodiment could omit the human name from the announce message with the same drawbacks.


In another variation, the announce message may omit the GUID, but when the GUID is omitted the sandboxed program lacks any identifier by which to lookup services on previously visited private networks. If no device communicates its GUID then there is no reason for the discovery service to maintain the mapping from GUID to service information and GUIDs may be omitted from all other communication.


A variation that omits both GUID and human name in announce messages is also possible with the drawbacks of both the variations that omit only one of the two.


Security and Spam Prevention: The Two Sandbox Extension


In the embodiments discussed so far, the sandboxed program is given the known addresses and/or the GUID of the discoverable service. Although the sandboxed program is limited regarding what it can do to its local node, the sandboxed program is allowed to communicate across the Internet. Any information given to the sandboxed program could become public knowledge including the public address and the GUID: potentially anyone can forever communicate with the discoverable service. This section extends the direct embodiment to limits access to the GUIDs and addresses of discoverable service.


One traditional way to prevent undesired access is to introduce usernames and/or passwords. This is a reasonable solution, however usernames and passwords are examples of user configuration-in this case the configuration is often called user registration. Particular embodiments are provided that avoid user registration.


For purposes of illustration this section hereafter limits the scope of the services addressed to those offered by entertainment devices. However, this does not preclude using any embodiments with other types of services.


A prominent example use of the proposed embodiments is to allow video web sites to find televisions in the user's home and then tell the TV to play a video. This TV has enough persistent storage to store content metadata: information about videos, such as titles, descriptions, and URLs from which the videos can be streamed. The IP-enabled, on-demand TV exports a discoverable service by which a caller can list, add or remove metadata. What are the threats posed by an attacker from somewhere on the Internet?


An attacker could

    • add unsolicited metadata.
    • delete metadata, or
    • steal metadata the user has added to the TV thereby revealing viewing preferences.


IP-enabled Digital Video Recorders (DVRs) differ from IP-enabled on-demand TVs in that they have substantial persistent storage. If an IP-enabled DVR exports functions to the IP interface to list downloaded/recorded videos, download/record video, delete video, and share video then the attacker could

    • steal a list of the videos a user has downloaded or recorded,
    • consume storage with unsolicited videos,
    • remove videos the user wishes to keep, or
    • steal videos the user wishes to not share.


For most entertainment devices there appear to be three classes of attack: deletion, privacy invasion, and spam. The prior two could be damaging; the last is mostly annoying. In the worst case spam attacks could use up all storage on a DVR preventing desired recording.


A way to protect against deletion is to not export any deletion functions as part of the discoverable service. The easiest way to protect against privacy invasions is to not expose any metadata already in the device via the discoverable service. This leaves only spam attacks. The most damaging form of spam attacks can be mitigated by imposing resource restrictions. Do not allow newly added items to the device to consume more than allotted resources.


To address these threats consider a two-level security model for functions implemented by a device: protected and local. A local function is only available via interfaces that require the user's physical proximity to the device, e.g., buttons on the TV or on an infrared remote control. A protected function is available via IP as a discoverable service but only to programs running on nodes in the same private network, programs that know the device's public address, or programs that know the device's GUID. Functions that perform critical activities like deleting files would probably be local. Functions that add content or metadata, or that tell the device to play content are still sensitive to spam and are thus deemed protected.


Spam is prevented to the extent the system protects the GUID and public address of the device from untrusted, visited websites. Fortunately these pieces of information can be well protected using the constraints imposed by the security sandbox. As stated in Section 0:


Sandboxed programs may not be permitted to communicate with other programs running within other security sandboxes except via a limited, mutually agreed programming interface enforced by the sandboxes.


A program running in a separate sandboxed program downloaded from a trusted website performs service discovery. Devices then only expose service information to the trusted website. This example assumes that the discovery service and the website delivering the discovery sandboxed program work together as a trusted entity. Particular embodiments hereafter refer to the discovery sandboxed program as the discovery agent.


Particular embodiments hereafter refer to this as the two sandbox extension. The two sandbox extension can be applied to the centralized and direct embodiments though this section presents it in the context of the direct embodiment.



FIG. 16 illustrates the two sandbox extension and FIG. 17 illustrates the TV example discussed in the previous paragraphs.


In FIG. 16, there are two sandboxed programs: untrusted 16041605 and the discovery agent 16021603. The two sandboxed programs communicate via a mutually agreed programming interface. The discovery service 1608 and discoverable service 1601 act the same as in prior embodiments and with any of the discussed extensions. The discovery agent 1603 calls Discover( ) 1606 on the discovery service 1608. The discovery service returns a set of discovered services 1609. The discovery agent remembers then strips everything from the discovery service response except the human names of each service. It then associates a locally unique identifier id 1610 with each human name. If the human names are ordered then the index in this ordering is a unique identifier. The purpose of including a separate id is to allow consistent identifiers while human names appear or disappear from the list across updates sent from the discovery agent during the lifetime of the untrusted sandboxed program.


Since the untrusted sandboxed program 1604 only has access to human names and local identifiers and those local identifiers are only meaningful to the discovery agent, the untrusted sandboxed program can only communicate with discovered services via the discovery agent. When the untrusted sandboxed program wishes to communicate some arbitrary payload to a discovered service, it sends the payload 1612 to the discovery agent with the id of the sandboxed program to which the payload should be sent. The discovery agent then forwards the payload 1613 to the discoverable service with or without the id and likewise the discovery agent forwards any response from the discoverable service to the sandboxed program.


If the untrusted sandboxed program leaks the human names to a third-party this does not compromise any address or global identifier that the third party could exploit to communicate with the discovered service.



FIG. 17 provides an example instantiation of the direct embodiment with the two sandbox extension. The example uses Adobe Flash using two SWFs: “Player.swf” 1707 and the discovery agent here named “Discovery.swf” 1707. “Player.swf” represents an untrusted sandboxed program as are all sandboxed programs downloaded from any server other than the discovery service. The user visits web page 1705, containing references to both SWF's causing the browser to start the flash player plug-in 1703. The flash player plug-in 1703 constructs a separate security sandbox 17041708 for each SWF. The flash player then loads 1706 “Player.swf” 1707 from the content provider website 1701, and then the flash player 1703 loads the discovery agent from the discovery service 1713. Once instantiated, the discovery agent 1707 queries 1711 the discovery service 1713. The discovery service then returns 1714 references to any devices residing behind the same NAT 1712 as the discovery agent, i.e., the discovery services return references to devices announcing from within the same private network.


The discovery service and the content website have different domain names and thus the flash player prevents the two sandboxed programs from communicating with one another except via a programming interface explicitly exported by each SWF. For example, the two SWFs can export JavaScript call interfaces using ActionScript's ExternalInterface:

















ExternalInterface.addCallback( “play”, play );



function play( tv_id : int, video_metainfo : Object ) : void {...}










The discovery agent might use the above code to export a call named “play” that allows “Player.swf” 1707 to tell the device to play content described by the video_metainfo argument. The video metainfo is represented as an URL in a “play” call 1716 passed from “Player.swf” identifying service with id=0 and then forwarded by “Discovery.swf” to the TV service 1717. The TV then downloads 1718 the video from foo.com's video server.


Similarly “Player.swf” 1707 might export a JavaScript call via which the discovery agent communicates references to newly discovered devices:

















ExternalInterface.addCallback( “tv_update”, tv_update );



function tv_update( tv : Array ) : void { ... }










Because all communications between the untrusted sandboxed program and the discovered service, e.g., the TV, pass through the discovery agent, the discovery agent stands in the unique position to enforce policy: preventing or modifying communications between the untrusted sandboxed program and the discovered service according to rules imposed by the user.



FIG. 18 illustrates a policy extension to the direct embodiment with the two-sandbox extension. Once the discovery agent 1806 has obtained references 180718081809 to discoverable services announcing from within the same private network, the discovery agent 1806 sanitizes the discoverable service references by replacing the globally unique identifiers with local identifiers and by removing all network routing information including each service's public and private IP addresses and ports. The discovery agent then passes the sanitized references to the untrusted sandboxed program 1803. Since the untrusted sandboxed program only knows locally unique information, it cannot directly open connections to the referenced devices and thus must forward all communications 1811 to discoverable service 1815 through the discovery agent 1806.


Upon receiving a communiqué the discovery agent 1806 determines the sender of the communication. For example with ActionScript, the discovery agent can determine the URL of http://foo.com/x.html 1804 via the ExternalInterface:


var page_url=ExternalInterface.call(“eval”, “window.location.href”);


From page_url, the discovery agent 1806 extracts the domain name of the content provider website foo.com. The discovery agent then queries a policy database for access restrictions for foo.com. When there is no policy present in the database, the discovery agent may prompt the user. For example if the discovery agent 1806 is a SWF, the discovery agent could use ActionScript's ExternalInterface to prompt the user with a confirm modal dialog box asking whether a website is allowed to send a video to a TV:

















var allow : Boolean = ExternalInterface.call(“confirm”,







“Allow” + domain_name(page_url) + “ to send video to your TV?” );


update_policy(domain_name(page_url), allow);


if ( allow ) send_to_tv( ...);









In the code snippet above, update_policy stores policy for domain_name(page_url), domain_name(page_url) returns the domain name portion of page_url.


The policy database can reside in persistent storage on the computer running the discovery agent or the policy database can reside in the device on which the discovery agent runs or the policy database can be distributed across both. When the policy device is in the computer running the discovery agent, the policy moves with the personal computer (e.g., a laptop) and can be applied across devices. When the policy is stored in the device running the discoverable service, the policy can apply to all users of that device. Furthermore policy stored in the personal computer is available before communication with the device is achieved and can thus be used to rapidly remove unavailable user options, but a policy database on the personal computer is also limited to the constraints imposed by the sandbox. Adobe Flash, by default, limits each website to 100 KB. This is sufficient to locally store domain names and a few associated Boolean access flags for thousands of web sites. Unfortunately if the user clears Adobe Flash website storage then all policy is lost. A device may have much larger storage for policy and is less likely to allow a user to accidentally delete all policy.


“Player.swf” 1707 may be replaced with any sandboxed program including those not running in Adobe Flash. Likewise the discovery agent 17091806, may be written in any language and run-time environment that imposes a security sandbox meeting the constraints specified in Section 0. The device references 17141809 returned from the discovery service 17131808 contain all of the information illustrated in FIG. 3 (see messages labeled 310 and 311), or subsets of this information as described in Section 0. In this example, the discovery service communicated references to TVs, but the device can be any device. Furthermore, the communications need not be limited to communicating “play” messages but rather anything that can be communicated over a network.


Sharing Discovery State Across Web Pages and Domains


In the example in FIG. 17, the discovery agent 1709 is a SWF downloaded from the discovery service 1713. SWFs run in an Adobe Flash sandbox. Adobe Flash allows Discovery.swf to access state stored by Discovery.swf regardless of which website embedded Discovery.swf. Disocovery.swf could thus store a query result from foo.bar and reuse it at bar.com. Since Discovery.swf may be cached, the user may be able to surf the web without contacting the discovery service on every page load that contains Discovery.swf.


Sharing state between page loads also enables a user to visit a network once and be able to communicate with a discovered service when the service is no longer in the same private network and thus does not appear in a response from the discovery service. Remote communications is discussed in Section 0.


Variations on the Two Sandbox Extension


The discovery agent may have its own UI for selecting discoverable services. The sandboxed program may communicate what it wants to communicate to the discovery agent, which then forwards to the discoverable service. In this variation the untrusted sandboxed program is not even told a locally unique id or human name of any discoverable services.


As another Adobe Flash example of the two sandbox extension, the limited, mutually agreed programming interface between the two sandboxes could use the LocalConnection class rather than JavaScript. However, any limited, mutually agreed programming interface suffices.


Remote Communications


Problems related to communicating between nodes with one or more intervening NAT are generally known as NAT traversal problems. This section describes how the direct embodiment enables a client that previously discovered a service to communicate with that service when the client and service no longer reside in the same private network. Such communication by the definition of private network implies traversing one or more NATs. This section then discusses embodiments that handle a wider array of NAT traversal problems.


When contacting a service's known addresses fails and the service does not appear in the response to a query for local private network services, the sandboxed program assumes the previously discovered service resides in another private network or is no longer operational.


In the direct embodiment presented in Section 0 and as illustrated in FIG. 3, the service information returned in response to Discover( ) 310311 contains each service's GUID. The GUID is a globally unique identifier that persists across time and across network changes, and thus can be used to identify a service even when the service is no longer in the same private network. Because the identifier persists across network changes, its value is independent of network routing, and thus to route packets to a service not on the same private network requires mapping the GUID onto the service's public address. As shown in FIG. 2, the discovery service maintains a mapping from GUID to service information that includes the service's public address 208.



FIG. 19 illustrates the process used by the direct embodiment of discovering service information based on GUID. The device 1901901 announces using the same process as illustrated in FIG. 9. The discoverable service 1901 communicates its service's private addresses 1902902, the public port mapping setup in the NAT (discussed momentarily), the GUID and the human name 19031906 to the discovery service. As the packets communicating this information pass through the NAT 1904, the private IP and port 1902 that were placed in the IP headers are mapped onto the public IP of the NAT and a port mapped for the service's announce 1905. The discovery service 1908 then stores the service information including the GUID in the two mappings 908 and 909. When the sandboxed program 1910 queries passing the GUID 191219151916, the discovery service maps 908 from GUID to the service information and returns the service's public address and human name 191719181919. Once the sandboxed program has the service's public address, it may open a connection to that address over which it communicates with the service.


A port mapping is the mapping between a private ip-port to one of the NAT's public IP addresses and one of the NAT's public ports. A NAT usually sets up a port mapping automatically when a program inside the NAT's private network initiates a TCP connection or starts a UDP packet exchange with any node outside the private network. However when a packet arrives on one of the NAT's public network interfaces bearing a port number for which there exists no mapping, the NAT typically discards the packet. There is one exception: some NATs implement a way to designate a single node within the private network to handle all packets that arrive on a public port for which there exists no port mapping. Forwarding all packets addressed to unmapped ports to a particular private node is sometimes called placing the private node in the DeMilitarized Zone (DMZ). Some NATs support mechanisms for explicit port mapping, whereby an application running within the NATs private network can tell the NAT to establish a port mapping without initiating a connection to any particular node outside the private network. NAT-PNP and uPNP specify mechanisms for explicit port mapping. NAT-PNP and uPNP are preferable to placing a node in the DMZ since placing a node in the DMZ opens that node up to various security threats.


Because a user trying to communicate with a service running on a different private network is initiating a connection via a NAT, the NAT must either be particularly unrestrictive (e.g., implementing a DMZ) or it must provide explicit port mapping. This section later describes embodiments that do not require explicit port mapping.


If a NAT does not support NAT-PNP or uPNP, most NATs provide a web user interface by which user's can manually set up port mappings or designate a device responsible for all packets to unmapped ports. NAT-PNP or uPNP are obviously preferable since they do not require any user configuration.



FIG. 20 illustrates a sandboxed program opening a TCP connection to and then communicating with device 2014 on another private network assuming a port mapping exists in NAT 19042011 from the device's public address (p,q) to its private address (x,y). The sandboxed program 2002 obtains the public address of the device 2014 from the discovery service 2005. The sandboxed program establishes a connection by sending a packet containing a TCP SYN 2006 addressed from the sandboxed program's node's private address (r,s) to (x,y). Since the connection initiator is within NAT 2007's private network, the NAT automatically creates a port mapping from the connection's private address (r,s) to the NAT's public IP address u and a newly allocated public port w. NAT 2007 then replaces the sandboxed program's private address (r,s) with (u,w) in the SYN's IP and TCP headers. The NAT then forwards the newly addressed SYN packet 2009 across the Internet to NAT 2010.


Assume prior to the events depicted in FIG. 20, explicit port mapping or user manual configuration was used to setup up a port mapping in the NAT between public address (p,q) and the service's private address (x,y). Because a port mapping exists when the SYN arrives at NAT 2010, the NAT replaces the destination address (p,q) with the discovered service's private address (x,y) and forwards the SYN 2011 to the private network and on to device 2012. The discovered service running on device 2012 responds with a SYN/ACK 20132014 addressed to the source address (u,w) taken from the received SYN. When SYN/ACK 2014 reaches NAT 2007, the NAT uses the mapping that had been created by the initial SYN 2006, to forward the SYN/ACK packet 2015 back to the sandboxed program 2002 running at (r,s).


Once the SYN/ACK arrives, the sandboxed program acknowledges the SYN/ACK. The ACK to the SYN/ACK follows the same path through the illustration as the initiating SYN. At this point, the connection has been established between the sandboxed program and the discovered service on device 2012.


Once the connection has been established, communication commences. What is communicated is orthogonal to the discovery process.



FIG. 20 illustrates how the direct embodiment with the addition of explicit port mapping handles NAT traversal across two NATs: one sits between the sandboxed program and the public Internet and the other between the discoverable service and the public Internet. The cases where 1 or both NATs are omitted are degenerate cases that are easily handled: when there is no intervening NAT between a party and the public network, the party's private address and public address become one.


Multiple NATs between the sandboxed program and the public Internet represents little difficulty in practice since the sandboxed program initiates communications 2008. However, explicit port mapping may fail when there are multiple NATs between the discoverable service and the public Internet.


The direct embodiment without explicit port mapping often requires some form of manual user configuration to permit remote access over TCP.


The next section considers embodiments that can traverse a wider variety of NAT scenarios.


Advanced Nat Traversal


NATs implement port translation in various ways. For all descriptions consider the case when a private node initiates communications by sending a packet bearing private source address (x,y) and publicly routable destination address (a,b). The most restrictive NATs are sometimes called symmetric NATs. With symmetric NATs, the mapping exists only between (x,y) and (a,b). Packets arriving at the NAT from the public network with destination (x,y) but with source address other than (a,b) are discarded. Symmetric NATs are the most difficult to traverse and we propose only one embodiment that can traverse such NATs: the global message queues embodiment.


The global message queues embodiment extends the direct embodiment as well as any of the other embodiments discussed with a message queue for each service that announces to the discovery service. A message can contain arbitrary information and the message can span a single packet or multiple packets. The message queue stores the message for at least long enough for a normally operating discoverable service to poll the queue and download any pending messages. The message queue solution casts both the sandboxed program and the discoverable service in the role of communication initiator, the sandboxed program initiates communication to push the message; the service initiates communications when it polls. Thus the NAT traversal will succeed for almost any NAT including symmetric NATs by virtue of NAT's automatically establishing port mappings for communications initiated from within any of a NAT's private networks.


Providing a global message queue per discoverable service has unique benefits that make it useful in combination with all of the NAT traversal techniques we discuss:

    • It gracefully handles devices that are periodically unavailable, e.g., powered off part of the day.
    • It works with almost every NAT.


However, the global message queues embodiment has a number of drawbacks that make it the logical last resort when attempting to communicate with a device:

    • If the global message queue is to provide reliable message delivery then the global message queues require storage of messages for all otherwise unreachable devices until a time has passed that is substantially longer than the typical time that devices remain unpowered. This introduces the need for systems with reliable persistent storage.
    • It introduces a new piece of central infrastructure that must be maintained.
    • The global message queue service must scale to handle periodic polls from every discoverable service, i.e., every device running at least one discoverable service, even for devices for which no messages have been pushed.
    • The global message queue introduces latency in delivering messages as long as the poll period for devices that are active (e.g., powered on), and longer for devices that are temporarily inactive.


Some of these drawbacks are no worse than the drawbacks of a global discovery service, since it represents central infrastructure that too must scale to handle periodic announces from all discoverable services. However the global discovery service can be completely implemented with soft state and thus does not require persistent storage.


As an example, global message queues can be implemented using Internet electronic mailboxes. a.k.a. email mailboxes. Global message queues have not previously been designed for use with a sandboxed program, and thus to work global message queues are extended to return “explicit permission to communicate” (see Section 0). For Adobe Flash, this means the global message queue must return a crossdomain.xml file. Extending a global message queue to return “explicit permission to communicate” and in particular return a crossdomain.xml file is novel.


Consider a less restrictive NAT that forwards all packets addressed to public address (x,y) regardless of each packet's public source address. Such NATs are sometimes referred to as full cone NATs. In another embodiment, the discoverable service announces to the discovery service with a source port that is bound to the same port on which the discoverable service listens, i.e., port y=z in FIG. 20. z is no longer ephemeral, and v=w. By doing this, the announce to the discovery service establishes the port mapping that is used by remote sandboxed programs to initiate communications with the discoverable service.


In yet another embodiment, the discovery service periodically sends a SYN to a random maybe unreachable or nonexistent public IP address but from the port on which the service listens, i.e., port y in FIG. 2, in order to establish the port mapping.


Additional embodiments can incorporate any subset or all of the following NAT traversal mechanisms: Simple Traversal of UDP over NATs (STUN). “STUN and TCP too” (STUNT), port prediction, and TURN.


With STUN, a STUN client on a private node contacts an a priori known STUN server. The STUN server interrogates the private node to determine what kind of NAT(s) might reside in the path between the server and the private node. By this means, a service running on a private node can learn its public address on its outermost NAT and whether it is likely that other nodes would be able to communicate with the service via this public address. Via some external mechanism, the service communicates the public address to peers that might want to contact the service, e.g., our proposed discovery service could be used. The discovery service by virtue of returning the public address already provides much of the relevant functionality provided by STUN. However, an embodiment that uses STUN to discover the public address and then communicates the public address via our discovery service is novel.


STUN by itself does not provide any mechanism for traversing more restrictive NATs like symmetric NATs. STUN is also not designed for use with TCP. Even if the discoverable service speaks UDP, the sandboxed program is limited to HTTP over TCP. There is no guarantee that a public address returned by STUN correlates to a public address available for incoming TCP connections from remote sandboxed programs.


With STUNT, the client uses UDP and TCP to communicate with a server sitting on the public network. This server implements STUN plus it listens for TCP connections. The server communicates back to the client the client's public addresses for the TCP and UDP exchanges with the server. The client then communicates via an external mechanism typically the Session Initiation Protocol SIP to tell a peer to attempt to establish communication. The client and the peer simultaneously or near simultaneously send packets to each other using each other's respective public addresses. This initial exchange sets up mappings in the intervening NAT(s): the process is sometimes called hole punching. Sometimes the hole punch succeeds and further bidirectional communication can commence. When a hole punch attempt fails, the client and peer may attempt communicating on port numbers neighboring the public port numbers to exploit port allocation patterns in many NATs: this is called port prediction.


A STUNT embodiment combines the TCP-part of STUNT with the direct embodiment. STUN and STUNT are not designed to communicate with sandboxed programs, as such in the STUNT embodiment, the STUNT server provides the sandbox with explicit permission to communicate. A flash-reachable STUNT server speaks HTTP and returns a sufficiently permissive crossdomain.xml file (see Section 0). Extending STUNT to communicate with a sandboxed program is novel.


Although STUNT can sometimes penetrate NATs, it depends on the effectiveness of port prediction. STUNT will not work with symmetric NATs that have random port allocation patterns. The only way to ensure communication can take place is to fall back to a global message queue or to a relay. A relay sits on the public network forwarding packets back and forth between a private node and private or public nodes anywhere on the network.


A TURN server acts as a relay. Assume a private node P with private address P′ sits behind a NAT that does not allow public nodes to establish connections to P. Assume also that a TURN client runs on P. The TURN client initiates communication with the TURN server thereby establishing a mapping in the NAT between the private node and the TURN server. The TURN server can now talk to P whenever it wants so long as the TURN client maintains the mapping by periodically talking to the TURN server. The TURN server then listens on a public address P″ on behalf of P. P′ and P″ differ in that packets address to P″ are routable over the public Internet. The TURN server forwards any packet sent to P″ to P via the existing mapping in the NAT. Relay solutions such as TURN can traverse even symmetric NATs with random port assignments; however, all relay solutions are quite heavyweight and should only be used as a last resort, or as a second-to-last-resort if global message queues are also employed in the system. Message queues (as defined) differ from relays such as TURN servers in that message queues are polled by the discoverable service whereas a relay forwards packets or messages as soon as they have been received. Message queues may store messages until they can be delivered and are thus better at reaching temporarily-powered-off discoverable services.


In a TURN embodiment of the proposed invention, a slightly-extended TURN server relays communications between a sandboxed program and the discoverable service. As with STUN, a TURN server must be sandbox-reachable, and with Adobe Flash this implies that a flash-reachable TURN server must return a crossdomain.xml file and must be able to perform all communications over HTTP. Extending TURN to communicate with a sandboxed program is novel.


Interactive Connectivity Establishment (ICE) (21) combines STUN and TURN. It is trivial to consider an embodiment that combines both the STUNT embodiment and the TURN embodiment and call this the ICE embodiment. Extending ICE to function within the constraints imposed by the security sandbox is extending STUNT and TURN in the aforementioned ways and thus is novel in the same ways.


STUNT, TURN, and ICE provide no mechanisms for discovering STUNT or TURN servers. STUNT or TURN servers could announce to the discovery service in the same manner as discoverable services.


TURN is a specific kind of relay and may be more complicated than is needed for communication establishment in some embodiments. A scalable simple relay embodiment in which each simple relays has a sandbox-reachable interface and optionally a TCP interfaces is provided. When a simple relay has a TCP interface that is less restrictive than the sandbox-reachable interface then it is called the simple relay TCP interface. TCP is distinguished from sandbox-reachable (e.g., HTTP for Flash) because the sandbox reachable interface may be more restrictive than TCP.


In the simple relay embodiment and the simple TCP relay embodiment, the discoverable service opens a connection to the relay and sustains mappings in intervening NATs by periodically sending keep-alive messages in the connection. When a message arrives on the sandbox-reachable interface from a sandboxed program, the message is forward via the TCP connection to the discoverable service. The simple relay embodiment and the simple TCP relay embodiments are similar to the TURN embodiment except that they do not limit the scope to the specifics of TURN.


In the simple UDP relay embodiment, the discoverable service communicates with the relay using UDP rather than TCP or falls back to TCP when UDP fails. As with the simple relay and simple TCP relay embodiments, the discoverable service periodically sends keep-alive message to maintain mappings in any intervening NATs. When a sandboxed program queries the discovery service the returned service information contains the discovered service's public address and the picked relay's IP and port, i.e., all state related to the mapping in the relay. The sandboxed program then can communicate the state in each message thereby eliminating the need for the relay to retain any per-discoverable-service-state. Stateless systems also typically have simpler failover. When a simple relay fails, the discoverable service sees the failover at the end of the next keep-alive period and can switch to a different relay without needing to reestablish any state.


With the TURN, simple relay, and simple TCP relay embodiments, the relay keeps TCP connections open to each discoverable service, and thus the relay must maintain TCP-related state such as retransmission timers and send windows for each such discoverable service. State maintenance overhead can grow quite large compared to the simple UDP relay embodiment.


In the GUID-relay embodiment, the discovery service is combined with the relay service: discoverable services announce to the relay, the relay maintains a mapping from each GUID to the associated discovery service's public address, sandboxed programs then send messages bearing the discoverable service's GUID as the destination address, and the GUID-routing-relay immediately forwards the messages to the discoverable service's public address. Using the GUID as a destination address is orthogonal to whether discoverable service announce using UDP or TCP, thus there are TCP GUID-routing-relay and UDP GUID-routing-relay embodiments.


The GUID-relay must maintain discoverable-service state, but in the case of UDP this is no more state then would have to be maintained for the GUID mapping any of the discover service embodiments that maintain a GUID mapping.


Using a sandbox-reachable interface on one side to talk to sandboxed programs, and using UDP to talk to discoverable services is novel.


Retractable Access without User Accounts


In embodiments discussed so far, the GUID is sufficient to identify and establish communications with a discoverable service. However, there may be nothing to identify the user or the sandboxed program to the discoverable service.


For example. Alice owns a discoverable television. Alice's TV provides a discoverable service that allows sandboxed programs to tell the TV to download a video. Spammy visits Alice's house with his laptop. He visits a web site that loads Discovery.swf. Spammy discovery agent now has the GUID of Alice's TV. After Spammy leaves the Alice's home, much to Alice's disappointment. Spammy proceeds to litter her TV with unsolicited content.


One solution to this problem is to require password-protected user accounts for anyone with access to a discoverable service. This however introduces the burden of setting up accounts. Imposing user account registration for something as harmless as occasional visits from spammers seems like overkill. A less burdensome solution allows anyone to communicate with the discoverable service, and then allows the discoverable service to identify and exclude those that abuse the access.


With the access-token-extension, the discoverable service requires the sandboxed program to pass an access token in any message excepting messages soliciting access tokens. An access token may be an opaque bitstring from the view of the sandboxed program, but to the discoverable service it uniquely identifies the message sender. The access-token-extension may be used with any embodiment discussed so far. FIG. 21 illustrates a sandboxed program requesting and obtaining an access token 2104. In subsequent communications 2105, the sandboxed program 2102 passes along the access token. FIG. 21 shows the sandboxed program and the discoverable service on the same private network, but the decision of when to offer access tokens is a matter of policy. In FIG. 21 when the sandboxed program 21022106 communicates remotely 2109 with the discoverable service 2108, the sandboxed program passes the along the access token.


In one extension to the access-token-extension, the sandboxed program employs the policy of only granting access tokens to sandboxed programs running on nodes in the same private network. i.e., as illustrated in FIG. 21. Thus Spammy could obtain an access token when he is in Alice's home, but not before. This is called the private-grant access-token extension and is an instance of the access-token extension.


The local-grant access-token extension further restricts granting access tokens only to sandboxed programs running on nodes in the same local area network as the discoverable service. In home environments there is often one NAT and one local area network behind the NAT, in such cases the local area and private networks are the same. Because the discoverable service and the sandboxed program communicate over a single local area network, any frame from the sandboxed program arriving at the discoverable service's node contains the hardware address of the sandboxed program's node. Since hardware addresses are generally assigned by the manufacturer, are often left unchanged by users, and in many cases are not changeable, the hardware address may be used as a long-term pseudonym for a user, albeit the hardware address is an imperfect pseudonym as it conflates multiple users on the same node. When the discoverable service grants an access token, it may derive the token from the hardware address or it may remember the token granted to each hardware address. If a node loses its token, whether due to mischief or happenstance, the discoverable service can reissue the same access token to the sandboxed program(s) on that node thereby maintaining the pseudonym for a user (or users) across browsers, system crashes, browser cache erasures, and reboots into different operating systems.


With the local-grant access-token extension, not only is Spammy's laptop only able to send spam once it has operated in Alice's home, but Alice can also retract Spammy's laptop's access to her TV forever even if Spammy happens to clear his access tokens before revisiting Alice's home.


The access token may not only uniquely identify the user or his sandboxed program(s), but must also not be guessable or derivable by other sandboxed programs; else any sandboxed program could hijack access tokens or could generate its own access tokens outside the scope of the discoverable service's access control policy. Preventing hijacking means the token should be kept reasonably private by the sandboxed program: assuming attackers do not have access to intervening network hardware, the access token could be stored locally to the sandboxed program and transmitted only in packets from the sandboxed program destined to the discoverable service. If the intervening network is considered untrustworthy then the access could be encrypted whenever transmitted using shared key. The shared key would only be known only to the sandboxed program and the discoverable service. There are many ways to generate access such that the discoverable service can verify that they were previously issued by the discoverable service. The various methods for token generation are orthogonal to this proposed extension, although two example techniques are provided: 1) the discoverable service draws tokens from a long highly random pseudorandom sequence seeded with a secret known only to the discoverable service, 2) the discoverable service uses a key-Hashed Message Authentication Code (HMAC) as the access token where the key used in generating the HMAC is known only to the discoverable service and the input message to the HMAC algorithm is the sandboxed program's node's hardware address.


To ensure users include the access token, the policy is imposed that the discoverable service discards, reclassifies, or otherwise applies policy to all remote communications without an accompanying access token 1309 issued by the discoverable service 13031308. Another policy that the discoverable service only issues access tokens to sandboxed programs on the same private network may also be used.


Exploiting User Accounts


In lieu of or in addition to access tokens, the discoverable service could choose to offer access only to authenticated, registered users. Many mechanisms exist to authenticate users. In the context of service discovery, with an account all policy and knowledge of discovered services can follow the user between machines. For example, Alice's laptop at home discovers her TV. From the laptop she registers with the discovery service. The sandboxed program on her laptop associates her TV with her discovery service user account. When she goes to work, she visits a website that runs a sandboxed program that uses the discovery service. She provides her login information to the sandboxed program and the sandboxed program then downloads from the discovery service the reference to her TV at home.


Remote access scenarios discussed with previous embodiments assumed that the user took the computer with him or her. If Alice takes her laptop to work then no user registration is necessary to reach her TV at home because her laptop already knows the TV's GUID and its public address if the address has not changed.


Multiple NATs


A node might be behind the same NAT that connects to the public Internet, but reside on a different private network from other discoverable services. Embodiments that include a relay or message queue can handle multiple private network behind the same public address by using the relay whenever direct communication fails.


Using Ranges or Prefixes Rather than Nat Public IPs


Not all discoverable services are behind a NAT. When a discoverable service's private and public addresses are identical, a discoverable service knows it resides on the public Internet, i.e., not behind a NAT. In most proposed embodiments in this application, a discoverable service can learn its public address by querying the discovery service.


With the ip-range-extension, when a discoverable service finds itself on the public Internet, the discoverable service announces itself to a range of public IP addresses by sending an address range or address prefix in its subsequent announces. With this extension, in query responses the discoverable service returns all discoverable services that announced to a range or prefix including the requestor's public address. The ip-range-extension can be combined with any embodiment or extension discussed in this application.


Deciding on the appropriate range may be left up to a user configuration in order to allow the device to be discovered across arbitrary IP address prefixes or ranges.


Advertisement Targetting, Recommender Systems, and Exposed Addresses


With embodiments derived from the direct embodiment, if the sandboxed program and the discoverable service run on nodes in the same local area network then the discoverable service can have access to the sandboxed program's node's hardware address. As discussed in Section 0, the hardware address may be used as a pseudonym for the user. This pseudonym could be used not only for imposing access control policy, but also to identify the user to recommender and advertisement targeting systems. With the world wide web, browsers hide the hardware address as well as any other form of permanent or semi-permanent pseudonym from web sites in order to protect user privacy. However, there is no way to protect a user's node's hardware address from other nodes on the same local area network. Thus discoverable services thus have an advantage not available to the world wide web for targeting advertising.


For example, when Alice visits a video website and pushes a video to her discoverable TV from her laptop in her home's local area network, the hardware address as pseudonym gives the TV an indicator of that Alice as opposed to her husband will watch the pushed video. This identification mechanism is not available to existing Internet TV platforms.


Capability-Based Discovery


In all embodiments discussed so far, the possibility that there may be many different kinds of services coexisting in the same network has not been mentioned. As such a user may wish to query for just those discoverable services that offer certain capabilities. With the capability-based extension, the discoverable service and sandboxed programs provide service descriptions to the discovery service. To each query, the discovery service returns only those discoverable services within the same private network that also match the service description. The service description may take the form of a logical predicate or just a list of keywords. The capability-based extension can be used in conjunction with any other embodiment or extension in this application.


Only One Per Private Network


Only one discoverable service in each private network need announce to the discovery service. By definition each private network has its own routable private network address space in which nodes within the same private network can communicate with each other. With the only-one extension, discoverable services within the same private network elect one device at any given time to act as the announcer to the global discovery service and all discoverable services announce to the elected discoverable service. The elected discoverable service either passes all discovery information for the private network to the discovery service or it acts itself as the private discovery service for its private network. When acting as the private discovery service for its private network, the discoverable service can answer discovery queries for sandboxed programs running on nodes in the private discovery service's private network.


The only-one extension is not safe on networks that exhibit the hidden terminal problem, i.e., networks in which visibility is not guaranteed to be transitive. This sometimes occurs in wireless networks, e.g., node A has strong enough signal to communicate with node B, node B can communicate with node C, but A and C are too far apart for their signals to reach each other and B is not configured to act as a router between A and C. Fortunately, the discoverable service can know if it is on a network that exhibits the hidden terminal problem and choose to not implement the only-one extension.


With the only-one extension, load on the central discovery service from announces grows linear in the number of private networks rather than linear to the number of discoverable services. Furthermore, with the only-one extension, if a sandboxed program already knows the elected discovery service from a prior discovery query then it need not contact the central discovery service at all as long as the elected discovery service remains operational and remains the elected discovery service.


With the referral extension to the only-one extension, a discoverable service that was previously the private discovery service is queried it either redirects the requestor or forwards the request (like with DNS iterative vs recursive name resolution) to the current private discovery service if known. If no private discovery service can be found then the sandboxed program falls back to the central discovery service.


Discovering Undiscoverable Services


Discoverable services as defined in this application are discoverable because they implement one of the many embodiments described. In particular embodiments, discoverable services announce either to the central discovery service or a private discovery service (see only-one extension).


There may exist services within the network that are undiscoverable as defined in this application but are discoverable by other means such as DLNA (via UPnP AV). Such services are not discoverable directly from within sandboxed programs because they do not implement sandbox-reachable interfaces. However a discoverable service implementing the gateway-extension acts as a gateway to other undiscoverable services by announcing on their behalf to the central (or private) discovery service and by providing a sandbox-reachable interface on their behalf.


With the only-one gateway extension, the discoverable services implementing the gateway extension elect a single discoverable service to act as the gateway.


In this manner, a discoverable TV could allow flash players to push video to a user's “undiscoverable” NAS device.


Extending Sandbox to Support Discovery


An alternative solution is to extend an existing system that implements a sandbox to perform any traditional discovery method including those that involve multicast, such as MDNS/DNS-SD, SSDP, or SLP.


Although the description has been described with respect to particular embodiments thereof, these particular embodiments are merely illustrative, and not restrictive.


Any suitable programming language can be used to implement the routines of particular embodiments including C, C++. Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single processing device or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different particular embodiments. In some particular embodiments, multiple steps shown as sequential in this specification can be performed at the same time.


Particular embodiments may be implemented in a computer-readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or device. Particular embodiments can be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.


Particular embodiments may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of particular embodiments can be achieved by any means as is known in the art. Distributed, networked systems, components, and/or circuits can be used. Communication, or transfer, of data may be wired, wireless, or by any other means.


It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above.


As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.


Thus, while particular embodiments have been described herein, latitudes of modification, various changes, and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of particular embodiments will be employed without a corresponding use of other features without departing from the scope and spirit as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit.


Finding devices behind the same NAT by querying central infrastructure and returning all previously announced service's sharing the same public IP address is novel.


There has previously been no configuration-free and software installation-free way of finding devices in the same network that didn't rely on broadcast or multicast.


A security model that is permissive to applications that reside behind the same NAT but that are otherwise constrained by a sandbox is novel.


Having a service providing a GUID to later allow a sandboxed program to lookup and then connect to a service on a previously visited private network is novel.


Separating the sandboxed program into two or more sandboxed program where one is loaded from trusted infrastructure is novel. It creates a trustable policy enforcement point inside the browser, whereas a similar component outside the browser would require an installation. Thus all policy enforcement mechanisms based on this separation are also novel.


Protecting a service from spam by obscuring the service's IP and port via a trusted sandboxed program acting as an intermediary is novel. Previous techniques involve some kind of configuration like account registration or administrator-configured IP-based access control lists.


Exposing only a locally unique ID and an unroutable but human-friendly name to untrusted sandboxed programs that is then translated by the trusted sandboxed program to routable information is novel.


Extending TURN, STUN, or STUNT to return “explicit to communicate” is novel. In particular having any of these return crossdomain.xml files to permit communication between the server and the programs running within a Flash sandbox is novel.


Using a TCP-to-UDP reflector to get around the TCP-only constraint imposed by the security sandbox (of which Flash employs a qualifying security sandbox) is novel. Before the existence of such sandboxes, such reflectors would have been useless since applications running on any IP node would likely have sent UDP directly.


Instead of requiring the user to create an account with each service, each service may generate random unique ids that are handed out freely to sandboxed programs on the same private network. Inclusion of a uid is not required for local private network access but is required for any remote access. Thus once the node running a sandboxed program leaves the private network containing the service in question, the service can continue to identify the user by the uid pseudonym. If the device so desires, it can retract access at any time by disallowing requests that contain a given user id. This is the first time someone has proposed a configuration-free mechanism that permits free local access and retractable remote access.


A discovery mechanism that is configuration free but allows extended functionality when a user provides account information is novel.


Using a metadiscovery service to find an appropriate discovery service is also novel.


TCP Reflectors


Global message queues (electronic mailboxes are global message queues)

Claims
  • 1. A system comprising: a television executing a discoverable service thereon to provide a communication;a device residing in a same private network of Internet as the television, the device executing a sandboxed program thereon, and the device configured to use a pseudonym of a user and to call a discovery agent to find the discoverable service of the television within the same private network, wherein the pseudonym of the user is a hardware address of a node of the sandboxed program within the same private network, andwherein the device and the television are associated using at least the communication from the discoverable service within the same private network, the communication comprising an announcement of the discoverable service to a discovery service;a server executing the discovery service thereon to: receive the announcement of the discoverable service,translate, through a network address translator straddling both a public network and the same private network of the Internet, a private address of a message related to the announcement of the discoverable service to a public address thereof,perform, through the discovery service, a lookup based on the public address of the message to determine at least one device comprising the television assumed to be in the same private network as the sandboxed program in accordance with the public address being shared therebetween,respond, in accordance with the determination of the shared public address, with service information of the television obtainable through the sandboxed program, the service information comprising a globally unique identification (GUID) and a human-friendly name of the television, andforward, through the discovery service, a desired payload to the discoverable service of the television based on the sandboxed program obtaining the service information to communicate with the GUID of the discoverable service of the television through the network address translator to the discovery service; anda targeting system to: receive the pseudonym,identify the user of the device using the pseudonym, andtarget advertising to the identified user of the device using at least one of the sandboxed program and the discoverable service.
  • 2. The system in claim 1, wherein the discovery service of the server is further configured to: determine that the discoverable service of the television is available, andreply to a query from any of the device, the targeting system and another device to find the discoverable service of the television.
  • 3. The system in claim 1, wherein the communication of the television comprises at least one of the GUID, the human-friendly name, a private address data and a public address data of the discoverable service.
  • 4. The system in claim 3, wherein the public address data is provided by the network address translator.
  • 5. The system in claim 1, wherein: the pseudonym of the user is a long-term unique identifier of the sandboxed program of the device that is unlikely to change.
  • 6. The system in claim 1, wherein the device is further configured to: construct a security sandbox with an associated constrained runtime environment, andexecute the sandboxed program in the associated constrained runtime environment of the security sandbox.
  • 7. The system in claim 1, further comprising: a media device to send a video to at least one of the television and the device within a home of the user without requiring user configuration and account registration.
  • 8. The system in claim 6, wherein the sandboxed program is at least one of an embedded object, a script, a binary executable, an intermediate bytecode, an abstract syntax tree, and anything that can be executed with an appropriate runtime environment.
  • 9. The system in claim 1, wherein: a media payload is communicated between the server and the sandboxed program of the device.
  • 10. A system comprising: a television executing a discoverable service thereon to provide a communication;a device residing in a same private network of Internet as the television, and executing a sandboxed program thereon to use a pseudonym of a user and to call a discovery agent to find the discoverable service, wherein the pseudonym of the user is a hardware address of a node of the sandboxed program within the same private network, andwherein the device and the television are associated using at least the communication from the discoverable service within the same private network, the communication comprising an announcement of the discoverable service to a discovery service;a server executing the discovery service thereon to: receive the announcement of the discoverable service,translate, through a network address translator straddling both a public network and the same private network of the Internet, a private address of a message related to the announcement of the discoverable service to a public address thereof,perform, through the discovery service, a lookup based on the public address of the message to determine at least one device comprising the television assumed to be in the same private network as the sandboxed program in accordance with the public address being shared therebetween,respond, in accordance with the determination of the shared public address, with service information of the television obtainable through the sandboxed program, the service information comprising a GUID and a human-friendly name of the television, andforward, through the discovery service, a desired payload to the discoverable service of the television based on the sandboxed program obtaining the service information to communicate with the GUID of the discoverable service of the television through the network address translator to the discovery service; anda targeting system to: receive the pseudonym,identify the user of the device using the pseudonym, andtarget advertising to the identified user of the device.
  • 11. The system of claim 10, wherein the discovery service of the server is further configured to: determine that the discoverable service of the television is available, andreply to queries from at least one of the device and the targeting system to find the discoverable service of the television.
  • 12. The system in claim 10, wherein the communication of the television comprises at least one of the GUID, the human-friendly name, a private address data and a public address data of the discoverable service.
  • 13. The system in claim 10, wherein the pseudonym of the user is a long-term unique identifier of the sandboxed program of the device that is unlikely to change.
  • 14. The system in claim 10, wherein the device is further configured to: construct a security sandbox with an associated constrained runtime environment, andexecute the sandboxed program in the associated constrained runtime environment of the security sandbox, andwherein the sandboxed program of the device is at least one of an embedded object, a script, a binary executable, an intermediate bytecode, an abstract syntax tree, and anything that can be executed with an appropriate runtime environment.
  • 15. The system in claim 10, further comprising: a media device to send a video to at least one of the television and the device within a home of the user without requiring user configuration and account registration.
  • 16. The system in claim 10, wherein: a media payload is communicated between the server and the discoverable service of the television.
  • 17. The system in claim 12, wherein the public address data is provided by the network address translator.
  • 18. A method comprising: initiating a discoverable service executing on a television to provide a communication;executing a sandboxed program on a device residing in a same private network of Internet as the television to use a pseudonym of a user and to call a discovery agent to find the discoverable service of the television within the same private network, wherein the pseudonym of the user is a hardware address of a node of the sandboxed program within the same private network, andwherein the device and the television are associated using at least the communication from the discoverable service within the same private network, the communication comprising an announcement of the discoverable service to a discovery service;receiving, through a server executing the discovery service thereon, the announcement of the discoverable service;translating, through a network address translator straddling both a public network and the same private network of the Internet, a private address of a message related to the announcement of the discoverable service to a public address thereof;performing, through the discovery service, a lookup based on the public address of the message to determine at least one device comprising the television assumed to be in the same private network as the sandboxed program in accordance with the public address being shared therebetween;responding, in accordance with the determination of the shared public address, with service information of the television obtainable through the sandboxed program, the service information comprising a GUID and a human-friendly name of the television;forwarding, through the discovery service, a desired payload to the discoverable service of the television based on the sandboxed program obtaining the service information to communicate with the GUID of the discoverable service of the television through the network address translator to the discovery service;receiving the pseudonym from the sandboxed program using a targeting system;identifying, through the targeting system, the user of the device using the pseudonym; andtargeting, through the targeting system, an advertisement to the identified user of the device using at least one of the sandboxed program and the discoverable service.
  • 19. The method of claim 18, further comprising: determining, through the discovery service, that the discoverable service of the television is available; andreplying, through the discovery service, to a query from at least one of the device and the targeting system to discover the discoverable service of the television.
  • 20. The method in claim 18, wherein the communication of the television comprises at least one of the GUID, the human-friendly name, a private address data and a public address data of the discoverable service.
  • 21. The method in claim 20, comprising providing, through the network address translator, the public address data.
  • 22. The method in claim 18, further comprising: constructing a security sandbox with an associated constrained runtime environment in the device; andexecuting the sandboxed program in the associated constrained runtime environment of the security sandbox,wherein the sandboxed program of the device is at least one of an embedded object, a script, a binary executable, an intermediate bytecode, an abstract syntax tree, and anything that can be executed with an appropriate runtime environment.
  • 23. The method in claim 18, further comprising: sending, through a media device, a video to at least one of the television and the device within a home of the user without requiring user configuration and account registration.
  • 24. The method in claim 18, wherein the pseudonym of the user is a long-term unique identifier of the sandboxed program of the device that is unlikely to change.
  • 25. The method in claim 18, comprising: communicating a media payload between the server and the sandboxed program of the device.
CLAIM OF PRIORITY

This patent application is a Continuation-In-Part of, and hereby incorporates the entirety of the disclosures of and claims priority to each of the following cases: (1) Provisional patent application 62/183,756 titled SECOND SCREEN NETWORKING, TARGETING, AND COMMUNICATION METHODOLOGIES AND SYSTEMS and filed on Jun. 24, 2015.(2) Co-pending U.S. Continuation-in-Part patent application Ser. No. 14/018,408 titled EXPOSURE OF PUBLIC INTERNET PROTOCOL ADDRESSES IN AN ADVERTISING EXCHANGE SERVER TO IMPROVE RELEVANCY OF ADVERTISEMENTS filed on Sep. 4, 2013, a. which further claims priority to U.S. Provisional Patent Application 61/696,711 titled SYSTEMS AND METHODS OF RECOGNIZING CONTENT filed on Sep. 4, 2012.b. on which a Petition has been filed, but not yet granted, which requests to further claim priority to U.S. Provisional Patent Application 61/803,754 titled APPLICATIONS OF ZEROCONF BIDIRECTIONAL COMMUNICATIONS BETWEEN A NETWORKED DEVICE AND A SECURITY SANDBOX COMPRISING TARGETED ADVERTISEMENT, ENVIRONMENT AWARENESS, USER MAPPING, GEOLOCATION SERVICES, AND CONTENT IDENTIFICATION filed on Mar. 20, 2013.(3) Co-pending U.S. Continuation-in-Part patent application Ser. No. 14/744,045 titled TARGETED ADVERTISING AND ATTRIBUTION ACROSS MULTIPLE SCREENS BASED ON PLAYING GAMES ON A GAME CONSOLE THROUGH A TELEVISION filed on Jun. 19, 2015. a. which further claims priority to U.S. Provisional Patent Application 62/026,017 titled AUTOMATIC GAMING ADVERTISEMENT IDENTIFICATION, TIME STAMPING. AND CATALOGING BASED ON VIEWING HISTORY OF A USER OPERATING A MOBILE DEVICE COMMUNICATIVELY COUPLED WITH A NETWORKED TELEVISION, AND DELIVERY OF A TARGETED ADVERTISEMENT TO THE MOBILE DEVICE BASED ON THE IDENTIFICATION AND CATALOGING WITHIN A THRESHOLD AMOUNT OF TIME FROM A TIME STAMP OF AN IDENTIFIED ADVERTISEMENT DISPLAYED ON THE NETWORKED TELEVISION filed on Jul. 17, 2014.(4) Co-pending U.S. Continuation-in-Part patent application Ser. No. 14/981,938 titled RELEVANCY IMPROVEMENT THROUGH TARGETING OF INFORMATION BASED ON DATA GATHERED FROM A NETWORKED DEVICE ASSOCIATED WITH A SECURITY SANDBOX OF A CLIENT DEVICE filed on Dec. 29, 2015, a. which itself is a U.S. Continuation-in-Part patent application of Ser. No. 14/274,800 titled MONETIZATION OF TELEVISION AUDIENCE DATA ACROSS MULTIPLE SCREENS OF A USER WATCHING TELEVISION filed on May 12, 2014, i. which itself is a U.S. Continuation patent application of Ser. No. 13/943,866 titled RELEVANCY IMPROVEMENT THROUGH TARGETING OF INFORMATION BASED ON DATA GATHERED FROM A NETWORKED DEVICE ASSOCIATED WITH A SECURITY SANDBOX OF A CLIENT DEVICE filed on Jul. 17, 2013 and issued as U.S. Pat. No. 8,819,255 on Aug. 26, 2014, 1. which further is a U.S. Continuation patent application of Ser. No. 13/904,015 titled REAL-TIME AND RETARGETED ADVERTISING ON MULTIPLE SCREENS OF A USER WATCHING TELEVISION filed on May 28, 2013 and issued as U.S. Pat. No. 9,026,668 on May 5, 2015. a. which further claims priority to U.S. Provisional Patent Application 61/652,153 titled CONTENT RECOGNITION SYSTEM filed on May 26, 2012,2. which further is a U.S. Continuation-in-Part patent application of Ser. No. 13/736,031 titled ZERO CONFIGURATION COMMUNICATION BETWEEN A BROWSER AND A NETWORKED MEDIA DEVICE filed on Jan. 7, 2013 and issued as U.S. Pat. No. 9,154,942 on Oct. 6, 2015. a. which further claims priority to U.S. Provisional Patent Application 61/584,168 titled CAPTURING CONTENT FOR DISPLAY ON A TELEVISION and filed on Jan. 6, 2012.3. which further is a U.S. Continuation-in-Part patent application of Ser. No. 13/470,814 titled GENERATION OF A TARGETED ADVERTISEMENT IN AN UNTRUSTED SANDBOX BASED ON A PSUEDONYM filed on May 14, 2012 and granted into U.S. Pat. No. 8,539,072 of Sep. 17, 2013. a. which itself is a Continuation patent application of Ser. No. 12/592,377 titled DISCOVERY, ACCESS CONTROL, AND COMMUNICATION WITH NETWORKED SERVICES FROM WITHIN A SECURITY SANDBOX, filed on Nov. 23, 2009 and granted into U.S. Pat. No. 8,180,891 on May 15, 2012, i. which claims priority to U.S. Provisional patent application 61/118,286 titled DISCOVERY. ACCESS CONTROL, AND COMMUNICATION WITH NETWORKED SERVICES FROM WITHIN A SECURITY SANDBOX filed on Nov. 26, 2008.

US Referenced Citations (1098)
Number Name Date Kind
3849760 Endou et al. Nov 1974 A
3919479 Moon et al. Nov 1975 A
4025851 Haselwood et al. May 1977 A
4230990 Lert, Jr. et al. Oct 1980 A
4258386 Cheung Mar 1981 A
4420769 Novak Dec 1983 A
4450531 Kenyon et al. May 1984 A
4574304 Watanabe et al. Mar 1986 A
4677466 Lert, Jr. et al. Jun 1987 A
4697209 Kiewit et al. Sep 1987 A
4739398 Thomas et al. Apr 1988 A
4833449 Gaffigan May 1989 A
4843562 Kenyon et al. Jun 1989 A
4888638 Bohn Dec 1989 A
4918730 Schulze Apr 1990 A
4955070 Welsh et al. Sep 1990 A
4967273 Greenberg Oct 1990 A
4993059 Smith et al. Feb 1991 A
5014125 Pocock et al. May 1991 A
5019899 Boles et al. May 1991 A
5105184 Pirani Apr 1992 A
5155591 Wachob Oct 1992 A
5223924 Strubbe Jun 1993 A
5319453 Copriviza et al. Jun 1994 A
5321750 Nadan Jun 1994 A
5436653 Ellis et al. Jul 1995 A
5481294 Thomas et al. Jan 1996 A
5522077 Cuthbert et al. May 1996 A
5539658 McCullough Jul 1996 A
5557334 Legate Sep 1996 A
5572246 Ellis et al. Nov 1996 A
5612729 Ellis et al. Mar 1997 A
5636346 Saxe Jun 1997 A
5724521 Dedrick Mar 1998 A
5732219 Blumer et al. Mar 1998 A
5742768 Gennaro et al. Apr 1998 A
5745884 Carnegie et al. Apr 1998 A
5761601 Nemirofsky et al. Jun 1998 A
5761648 Golden et al. Jun 1998 A
5761655 Hoffman Jun 1998 A
5774170 Hite et al. Jun 1998 A
5774673 Beuk et al. Jun 1998 A
5805974 Hite et al. Sep 1998 A
5815665 Teper et al. Sep 1998 A
5822525 Tafoya et al. Oct 1998 A
5838301 Okamoto et al. Nov 1998 A
5838317 Bolnick et al. Nov 1998 A
5848396 Gerace Dec 1998 A
5850517 Verkler et al. Dec 1998 A
5892900 Ginter et al. Apr 1999 A
5903729 Reber et al. May 1999 A
5905942 Stoel et al. May 1999 A
5907279 Bruins et al. May 1999 A
5940073 Klosterman et al. Aug 1999 A
5948061 Merriman et al. Sep 1999 A
5966705 Koneru et al. Oct 1999 A
5977962 Chapman et al. Nov 1999 A
5978835 Ludwig et al. Nov 1999 A
6002393 Hite et al. Dec 1999 A
6002443 Iggulden Dec 1999 A
6009409 Adler et al. Dec 1999 A
6009410 LeMole et al. Dec 1999 A
6026368 Brown et al. Feb 2000 A
6026369 Capek Feb 2000 A
6032181 Bedgedjian et al. Feb 2000 A
6043817 Bolnick et al. Mar 2000 A
6055510 Henrick et al. Apr 2000 A
6064980 Jacobi et al. May 2000 A
6084628 Sawyer Jul 2000 A
6105122 Muller et al. Aug 2000 A
6112181 Shear et al. Aug 2000 A
6118864 Chang et al. Sep 2000 A
6119098 Guyot et al. Sep 2000 A
6137892 Powell et al. Oct 2000 A
6141010 Hoyle Oct 2000 A
6157941 Verkler et al. Dec 2000 A
6167427 Rabinovich et al. Dec 2000 A
6169542 Hooks et al. Jan 2001 B1
6188398 Collins-Rector et al. Feb 2001 B1
6192476 Gong Feb 2001 B1
6195696 Baber et al. Feb 2001 B1
6216141 Straub et al. Apr 2001 B1
6219696 Wynblatt et al. Apr 2001 B1
6247077 Muller et al. Jun 2001 B1
6286104 Buhle et al. Sep 2001 B1
6304523 Jones et al. Oct 2001 B1
6304852 Loncteaux Oct 2001 B1
6308327 Liu et al. Oct 2001 B1
6310889 Parsons et al. Oct 2001 B1
6332127 Bandera et al. Dec 2001 B1
6349289 Peterson et al. Feb 2002 B1
6351467 Dillon Feb 2002 B1
6360254 Linden et al. Mar 2002 B1
6381362 Deshpande et al. Apr 2002 B1
6400265 Saylor et al. Jun 2002 B1
6400996 Hoffberg et al. Jun 2002 B1
6438594 Bowman-Amuah Aug 2002 B1
6463585 Hendricks et al. Oct 2002 B1
6469749 Dimitrova et al. Oct 2002 B1
6481010 Nishikawa et al. Nov 2002 B2
6484148 Boyd Nov 2002 B1
6505169 Bhagavath et al. Jan 2003 B1
6526491 Suzuoki et al. Feb 2003 B2
6530082 Del Sesto et al. Mar 2003 B1
6532218 Shaffer et al. Mar 2003 B1
6536041 Knudson et al. Mar 2003 B1
6546554 Schmidt et al. Apr 2003 B1
6564260 Baber et al. May 2003 B1
6564263 Bergman et al. May 2003 B1
6574793 Ngo et al. Jun 2003 B1
6577346 Perlman Jun 2003 B1
6597405 Iggulden Jul 2003 B1
6622171 Gupta et al. Sep 2003 B2
6628801 Powell et al. Sep 2003 B2
6631523 Matthews, III et al. Oct 2003 B1
6651251 Shoff et al. Nov 2003 B1
6718551 Swix et al. Apr 2004 B1
6728784 Mattaway Apr 2004 B1
6738978 Hendricks et al. May 2004 B1
6757685 Raffaele et al. Jun 2004 B2
6769009 Reisman Jul 2004 B1
6771316 Iggulden Aug 2004 B1
6799196 Smith Sep 2004 B1
6804659 Graham et al. Oct 2004 B1
6832239 Kraft et al. Dec 2004 B1
6834308 Ikezoye et al. Dec 2004 B1
6836888 Basu et al. Dec 2004 B1
6845452 Roddy et al. Jan 2005 B1
6907458 Tomassetti et al. Jun 2005 B2
6946715 Hong Sep 2005 B2
6959288 Medina et al. Oct 2005 B1
6959320 Shah et al. Oct 2005 B2
6978470 Swix et al. Dec 2005 B2
6981022 Boundy Dec 2005 B2
6983478 Grauch et al. Jan 2006 B1
6983481 Fellenstein et al. Jan 2006 B2
6990453 Wang et al. Jan 2006 B2
6993326 Link, II et al. Jan 2006 B2
7020304 Alattar et al. Mar 2006 B2
7028033 Bright Apr 2006 B2
7028327 Dougherty et al. Apr 2006 B1
7043524 Shah et al. May 2006 B2
7051351 Goldman et al. May 2006 B2
7064796 Roy et al. Jun 2006 B2
7080400 Navar Jul 2006 B1
7088687 Ayyagari et al. Aug 2006 B2
7089575 Agnihotri et al. Aug 2006 B2
7089585 Dharmarajan Aug 2006 B1
7100183 Kunkel et al. Aug 2006 B2
7111230 Euchner et al. Sep 2006 B2
7113090 Saylor et al. Sep 2006 B1
7116661 Patton Oct 2006 B2
7117439 Barrett et al. Oct 2006 B2
7136875 Anderson et al. Nov 2006 B2
7139882 Suzuoki et al. Nov 2006 B2
7146627 Ismail et al. Dec 2006 B1
7158666 Deshpande et al. Jan 2007 B2
7162539 Garcie-Luna-Aceves Jan 2007 B2
7167857 Roberts Jan 2007 B2
7181415 Blaser et al. Feb 2007 B2
7185353 Schlack Feb 2007 B2
7194421 Conkwright et al. Mar 2007 B2
7210157 Devara Apr 2007 B2
7228280 Scherf et al. Jun 2007 B1
7243362 Swix et al. Jul 2007 B2
7243364 Dunn et al. Jul 2007 B2
7296091 Dutta et al. Nov 2007 B1
7299195 Tawakol et al. Nov 2007 B1
7308489 Weast Dec 2007 B2
7328448 Eldering et al. Feb 2008 B2
7330875 Parasnis et al. Feb 2008 B1
7346606 Bharat Mar 2008 B2
7346649 Wong Mar 2008 B1
7349967 Wang Mar 2008 B2
7349980 Darugar et al. Mar 2008 B1
7359889 Wang et al. Apr 2008 B2
7360173 Tuli Apr 2008 B2
7366975 Lipton Apr 2008 B1
7373381 Rust May 2008 B2
7380258 Durden et al. May 2008 B2
7383243 Conkwright et al. Jun 2008 B2
7421723 Harkness et al. Sep 2008 B2
7437301 Kageyama et al. Oct 2008 B2
7444658 Matz et al. Oct 2008 B1
7444660 Dudkiewicz Oct 2008 B2
7444666 Edwards et al. Oct 2008 B2
7454515 Lamkin et al. Nov 2008 B2
7472398 Corell et al. Dec 2008 B2
7486827 Kim Feb 2009 B2
7500007 Ikezoye et al. Mar 2009 B2
7509402 Moorer et al. Mar 2009 B2
7516074 Bilobrov Apr 2009 B2
7516213 Cunningham et al. Apr 2009 B2
7525955 Velez-Rivera et al. Apr 2009 B2
7529659 Wold May 2009 B2
7545940 Alessi et al. Jun 2009 B2
7546619 Anderson et al. Jun 2009 B2
7552228 Parasnis et al. Jun 2009 B2
7555165 Luo et al. Jun 2009 B2
7559017 Datar et al. Jul 2009 B2
7565158 Aholainen Jul 2009 B1
7574723 Putterman et al. Aug 2009 B2
7584491 Bruckner et al. Sep 2009 B2
7590998 Hanley Sep 2009 B2
7593988 Oreizy et al. Sep 2009 B2
7596620 Colton et al. Sep 2009 B1
7602748 Sinnreich et al. Oct 2009 B2
7623823 Zito et al. Nov 2009 B2
7624142 Jungck Nov 2009 B2
7631325 Rys et al. Dec 2009 B2
7634533 Rudolph et al. Dec 2009 B2
7639387 Hull et al. Dec 2009 B2
7650616 Lee Jan 2010 B2
7653008 Patrick et al. Jan 2010 B2
7664081 Luoma et al. Feb 2010 B2
7665082 Wyatt et al. Feb 2010 B2
7672003 Dowling et al. Mar 2010 B2
7689920 Robbin et al. Mar 2010 B2
7690006 Birnbaum et al. Mar 2010 B2
7694319 Hassell et al. Apr 2010 B1
7698165 Tawakol et al. Apr 2010 B1
7701882 Jones et al. Apr 2010 B2
7711748 Bright et al. May 2010 B2
7711838 Boulter et al. May 2010 B1
7716161 Dean et al. May 2010 B2
7720914 Goodman et al. May 2010 B2
7729366 Mok et al. Jun 2010 B2
7734624 Anderson et al. Jun 2010 B2
7739140 Vinson et al. Jun 2010 B2
7769756 Krikorian et al. Aug 2010 B2
7774348 Delli Santi et al. Aug 2010 B2
7774715 Evans Aug 2010 B1
7789757 Gemelos et al. Sep 2010 B2
7793318 Deng Sep 2010 B2
7797433 Kennedy et al. Sep 2010 B2
7805740 Gilboa et al. Sep 2010 B2
7822809 Dhupelia et al. Oct 2010 B2
7831426 Bennett Nov 2010 B2
7856644 Nicholson et al. Dec 2010 B2
7861260 Shkedi Dec 2010 B2
7870592 Hudson et al. Jan 2011 B2
7870596 Schackow et al. Jan 2011 B2
7873716 Maes Jan 2011 B2
7877461 Rimmer Jan 2011 B1
7877774 Basso et al. Jan 2011 B1
7890957 Campbell Feb 2011 B2
7904503 Van De Sluis Mar 2011 B2
7904925 Jiang Mar 2011 B2
7907211 Oostveen et al. Mar 2011 B2
7908273 DiMaria et al. Mar 2011 B2
7908618 Bruckner et al. Mar 2011 B2
7912822 Bethlehem et al. Mar 2011 B2
7921037 Hertling et al. Apr 2011 B2
7929551 Dietrich et al. Apr 2011 B2
7930207 Merriman et al. Apr 2011 B2
7930546 Rhoads et al. Apr 2011 B2
7933451 Kloer Apr 2011 B2
7937405 Anderson et al. May 2011 B2
7941197 Jain et al. May 2011 B2
7941816 Harkness et al. May 2011 B2
7950055 Blinn et al. May 2011 B2
7962007 Abe et al. Jun 2011 B2
7966309 Shacham et al. Jun 2011 B2
7978876 Powell et al. Jul 2011 B2
7979570 Chapweske et al. Jul 2011 B2
7995503 Yu Aug 2011 B2
8001124 Hugh Svendsen Aug 2011 B2
8020000 Oostveen et al. Sep 2011 B2
8035656 Blanchard et al. Oct 2011 B2
8041643 Mukerji et al. Oct 2011 B2
8046839 Lo Oct 2011 B2
8055784 Kalama et al. Nov 2011 B2
8060399 Ullah Nov 2011 B2
8060912 Sato Nov 2011 B2
8065700 Lee Nov 2011 B2
8069247 Ruiz-Velasco et al. Nov 2011 B2
8069348 Bacon Nov 2011 B2
8071869 Chen et al. Dec 2011 B2
8079045 Krapf et al. Dec 2011 B2
8087047 Olague et al. Dec 2011 B2
8090706 Bharat Jan 2012 B2
8091031 Evans Jan 2012 B2
8122484 Karjoth et al. Feb 2012 B2
8126963 Rimmer Feb 2012 B1
8131585 Nicholas et al. Mar 2012 B2
8131705 Chevalier et al. Mar 2012 B2
8131734 Austin et al. Mar 2012 B2
8140965 Dean et al. Mar 2012 B2
8141111 Gilley et al. Mar 2012 B2
8145645 Delli Santi et al. Mar 2012 B2
8145705 Rust Mar 2012 B1
8150729 Wilhelm Apr 2012 B2
8150985 Nakamura Apr 2012 B2
8155696 Swanburg et al. Apr 2012 B2
8161511 Kwak et al. Apr 2012 B2
8171030 Pereira et al. May 2012 B2
8171510 Kamen et al. May 2012 B2
8175413 Ioffe et al. May 2012 B1
8180708 Hurtado et al. May 2012 B2
8180891 Harrison May 2012 B1
8189945 Stojancic et al. May 2012 B2
8191091 Harvey et al. May 2012 B1
8195689 Ramanathan et al. Jun 2012 B2
8195692 Baek et al. Jun 2012 B2
8201080 Basson et al. Jun 2012 B2
8209397 Ahn et al. Jun 2012 B2
8209404 Wu Jun 2012 B2
8214256 Riedl et al. Jul 2012 B2
8219411 Matz et al. Jul 2012 B2
8225347 Flickinger et al. Jul 2012 B1
8229227 Stojancic et al. Jul 2012 B2
8229751 Cheung Jul 2012 B2
8239340 Hanson Aug 2012 B2
8244707 Lin et al. Aug 2012 B2
8245270 Cooperstein et al. Aug 2012 B2
8255949 Bayer et al. Aug 2012 B1
8260665 Foladare et al. Sep 2012 B2
8261341 Stirbu Sep 2012 B2
8271649 Kalofonos et al. Sep 2012 B2
8275791 Raffaele et al. Sep 2012 B2
8281288 Spencer Oct 2012 B1
8285880 Ye et al. Oct 2012 B2
8290351 Plotnick et al. Oct 2012 B2
8296763 Peercy et al. Oct 2012 B1
8301596 Lin et al. Oct 2012 B2
8301732 Chapweske et al. Oct 2012 B2
8302170 Kramer et al. Oct 2012 B2
8307093 Klemets et al. Nov 2012 B2
8316450 Robinson et al. Nov 2012 B2
8326872 Zwilling et al. Dec 2012 B2
8332885 Williamson et al. Dec 2012 B2
8335786 Pereira et al. Dec 2012 B2
8339991 Biswas et al. Dec 2012 B2
8341242 Dillon et al. Dec 2012 B2
8352980 Howcroft Jan 2013 B2
8355711 Heins et al. Jan 2013 B2
8358966 Zito et al. Jan 2013 B2
8364541 Roth Jan 2013 B2
8364703 Ramanathan et al. Jan 2013 B2
8364959 Bhanoo et al. Jan 2013 B2
8365217 Legrand Jan 2013 B2
8375131 Rogers et al. Feb 2013 B2
8381026 Talla et al. Feb 2013 B2
8385644 Stojancic Feb 2013 B2
8406607 Nesvadba et al. Mar 2013 B2
8407240 Denton Mar 2013 B2
8418191 Honishi et al. Apr 2013 B2
8433306 Rodriguez Apr 2013 B2
8433574 Jablokov et al. Apr 2013 B2
8443420 Brown et al. May 2013 B2
8451762 Liu et al. May 2013 B2
8452864 Vendrow May 2013 B1
8463100 Tse et al. Jun 2013 B2
8468357 Roberts et al. Jun 2013 B2
8472289 Scherf et al. Jun 2013 B2
8473575 Marchwicki et al. Jun 2013 B2
8479246 Hudson et al. Jul 2013 B2
8488838 Sharma Jul 2013 B2
8489701 Manion et al. Jul 2013 B2
8494907 Lerman et al. Jul 2013 B2
8495611 McCarthy et al. Jul 2013 B2
8495675 Philpott et al. Jul 2013 B1
8495746 Fissel et al. Jul 2013 B2
8504551 Anderson et al. Aug 2013 B2
8510317 Boetje et al. Aug 2013 B2
8510661 Dharmaji et al. Aug 2013 B2
8510779 Slothouber et al. Aug 2013 B2
8516533 Davis et al. Aug 2013 B2
8520909 Leung et al. Aug 2013 B2
8527594 Lahaix Sep 2013 B2
8533192 Moganti et al. Sep 2013 B2
8537157 Adimatyam et al. Sep 2013 B2
8539025 Husain et al. Sep 2013 B2
8539072 Harrison Sep 2013 B1
8539523 Philpott et al. Sep 2013 B2
8548820 Matz et al. Oct 2013 B2
8549052 Miles Oct 2013 B2
8549066 Donahue et al. Oct 2013 B1
8549110 Jerbi et al. Oct 2013 B2
8549550 Lopatecki et al. Oct 2013 B2
8566154 Merriman et al. Oct 2013 B2
8566158 Cansler et al. Oct 2013 B2
8566867 Yang et al. Oct 2013 B1
8577996 Hughes et al. Nov 2013 B2
8595781 Neumeier et al. Nov 2013 B2
8607267 Shkedi Dec 2013 B2
8611701 Zhang Dec 2013 B2
8613045 Shigapov Dec 2013 B1
8621585 Danieli et al. Dec 2013 B2
8635106 Sarukkai et al. Jan 2014 B2
8635316 Barnhill, Jr. Jan 2014 B2
8639826 Slothouber et al. Jan 2014 B2
8645209 Mandyam et al. Feb 2014 B2
8645992 Russell et al. Feb 2014 B2
8645994 Vemparala et al. Feb 2014 B2
8646063 Dowlatkhah Feb 2014 B2
8655716 Barnes et al. Feb 2014 B1
8656422 Kumar et al. Feb 2014 B2
8661010 Lin et al. Feb 2014 B2
8666168 Stojancic et al. Mar 2014 B2
8667142 Takei et al. Mar 2014 B2
8677253 Duquene et al. Mar 2014 B2
8694656 Douillet et al. Apr 2014 B2
8695032 Shkedi Apr 2014 B2
8700699 Shen et al. Apr 2014 B2
8700795 Boulter et al. Apr 2014 B2
8701134 Whinmill et al. Apr 2014 B2
8707351 Dharmaji Apr 2014 B2
8712833 Quach et al. Apr 2014 B2
8719396 Brindley et al. May 2014 B2
8719870 Davies et al. May 2014 B1
8732182 Bethlehem et al. May 2014 B2
8736764 Amundsen May 2014 B2
8738779 Binding et al. May 2014 B2
8739208 Davis et al. May 2014 B2
8751942 Lopez et al. Jun 2014 B2
8756686 Plattner et al. Jun 2014 B2
8763033 Dittus Jun 2014 B2
8763097 Bhatnagar et al. Jun 2014 B2
8745272 Casalaina et al. Jul 2014 B2
8769584 Neumeier et al. Jul 2014 B2
8775391 Kalavade Jul 2014 B2
8776112 Roberts et al. Jul 2014 B2
8776154 Kim et al. Jul 2014 B2
8776244 Kroeger et al. Jul 2014 B2
8793730 Mowrey et al. Jul 2014 B2
8799357 Clift et al. Aug 2014 B2
8804039 Kim et al. Aug 2014 B2
8804721 He et al. Aug 2014 B2
8805657 Wells et al. Aug 2014 B2
8805854 Chen et al. Aug 2014 B2
8812451 Shukla et al. Aug 2014 B2
8813232 Sreedharan et al. Aug 2014 B2
8817757 Luo Aug 2014 B2
8819249 Harrison Aug 2014 B2
8819255 Harrison Aug 2014 B1
8825526 Peters et al. Sep 2014 B2
8826327 Adimatyam et al. Sep 2014 B2
8832729 Nussel et al. Sep 2014 B2
8838149 Hasek Sep 2014 B2
8838556 Reiner et al. Sep 2014 B1
8838808 Addala et al. Sep 2014 B2
8843584 Arini et al. Sep 2014 B2
8847994 Choi Sep 2014 B2
8849821 Schloter Sep 2014 B2
8855796 Otsuka et al. Oct 2014 B2
8855798 DiMaria et al. Oct 2014 B2
8856028 Yang et al. Oct 2014 B2
8856087 Greene et al. Oct 2014 B2
8856874 Pieczul et al. Oct 2014 B2
8863165 Gordon Oct 2014 B2
8863168 Craner Oct 2014 B2
8863174 Neil et al. Oct 2014 B2
8875178 Cansler et al. Oct 2014 B2
8898714 Neumeier et al. Nov 2014 B2
8904021 Harrison Dec 2014 B2
8910199 Slaney et al. Dec 2014 B2
8930980 Neumeier et al. Jan 2015 B2
8949872 Slaney et al. Feb 2015 B2
8966525 Mehta et al. Feb 2015 B2
8972485 French et al. Mar 2015 B1
8996538 Cremer et al. Mar 2015 B1
8997164 Gordon et al. Mar 2015 B2
9009066 Long et al. Apr 2015 B2
9015741 Gordon Apr 2015 B2
9026668 Harrison May 2015 B2
9032451 Cansino et al. May 2015 B2
9036083 Zhu et al. May 2015 B1
9043712 Santoro et al. May 2015 B2
9049496 Raesig et al. Jun 2015 B2
9055309 Neumeier et al. Jun 2015 B2
9106804 Roberts et al. Aug 2015 B2
9113107 Jolna et al. Aug 2015 B2
9118945 Rudman et al. Aug 2015 B2
9131279 Raveendran et al. Sep 2015 B2
9143718 Nagorski et al. Sep 2015 B2
9146990 Scherf et al. Sep 2015 B2
9152727 Balducci et al. Oct 2015 B1
9154942 Harrison et al. Oct 2015 B2
9160837 Jeffrey et al. Oct 2015 B2
9167419 Harrison Oct 2015 B2
9183560 Abelow Nov 2015 B2
9185462 Das et al. Nov 2015 B2
9204275 Johnson et al. Dec 2015 B2
9213747 Cremer et al. Dec 2015 B2
9215217 Abu-Hakima et al. Dec 2015 B2
9232279 Beeson et al. Jan 2016 B2
9258383 Harrison Feb 2016 B2
9271052 Holden Feb 2016 B2
9286902 Han et al. Mar 2016 B2
9300996 Jeong et al. Mar 2016 B2
9323840 Harron et al. Apr 2016 B2
9356914 Jeffrey et al. May 2016 B2
9361606 Hertel et al. Jun 2016 B2
9372531 Benson et al. Jun 2016 B2
9378512 Singh et al. Jun 2016 B2
9380383 Brenner et al. Jun 2016 B2
9386356 Harrison Jul 2016 B2
9398262 Li et al. Jul 2016 B2
9465995 Harron et al. Oct 2016 B2
9495451 Harron Nov 2016 B2
9501568 Rafii Nov 2016 B2
9510044 Pereira et al. Nov 2016 B1
9510057 Harron et al. Nov 2016 B2
20010001160 Shoff et al. May 2001 A1
20010011226 Greer et al. Aug 2001 A1
20010016501 King Aug 2001 A1
20010016947 Nishikawa et al. Aug 2001 A1
20010029583 Palatov et al. Oct 2001 A1
20010036224 Demelloet et al. Nov 2001 A1
20010039658 Walton Nov 2001 A1
20010049620 Blasko Dec 2001 A1
20010054155 Hagan et al. Dec 2001 A1
20020012347 Fitzpatrick Jan 2002 A1
20020015105 Abe et al. Feb 2002 A1
20020019769 Barritz et al. Feb 2002 A1
20020026635 Wheeler et al. Feb 2002 A1
20020032906 Grossman Mar 2002 A1
20020042914 Walker et al. Apr 2002 A1
20020044659 Ohta Apr 2002 A1
20020044683 Deshpande et al. Apr 2002 A1
20020052965 Dowling May 2002 A1
20020059633 Harkness et al. May 2002 A1
20020066100 Hoang May 2002 A1
20020069100 Arberman Jun 2002 A1
20020072966 Eldering et al. Jun 2002 A1
20020072982 Barton et al. Jun 2002 A1
20020078456 Hudson et al. Jun 2002 A1
20020083435 Blasko et al. Jun 2002 A1
20020083441 Flickinger et al. Jun 2002 A1
20020083443 Eldering et al. Jun 2002 A1
20020087401 Leapman et al. Jul 2002 A1
20020087545 Bright et al. Jul 2002 A1
20020087975 Schlack Jul 2002 A1
20020087976 Kaplan et al. Jul 2002 A1
20020087978 Nicholson et al. Jul 2002 A1
20020091763 Shah et al. Jul 2002 A1
20020104083 Hendricks et al. Aug 2002 A1
20020116195 Pitman et al. Aug 2002 A1
20020116549 Raffaele Aug 2002 A1
20020120498 Gordon et al. Aug 2002 A1
20020120925 Logan Aug 2002 A1
20020123928 Eldering et al. Sep 2002 A1
20020133490 Conkwright et al. Sep 2002 A1
20020133534 Forslow Sep 2002 A1
20020138842 Chong et al. Sep 2002 A1
20020143782 Headings et al. Oct 2002 A1
20020144262 Plotnick et al. Oct 2002 A1
20020147611 Greene et al. Oct 2002 A1
20020151992 Hoffberg et al. Oct 2002 A1
20020152474 Dudkiewicz Oct 2002 A1
20020161741 Wang et al. Oct 2002 A1
20020162117 Pearson et al. Oct 2002 A1
20020162118 Levy et al. Oct 2002 A1
20020174197 Schimke et al. Nov 2002 A1
20020178447 Plotnick et al. Nov 2002 A1
20020196789 Patton Dec 2002 A1
20030001883 Wang Jan 2003 A1
20030009538 Shah et al. Jan 2003 A1
20030023489 McGuire et al. Jan 2003 A1
20030028433 Merriman et al. Feb 2003 A1
20030030752 Begeja et al. Feb 2003 A1
20030031176 Sim Feb 2003 A1
20030036949 Kaddeche et al. Feb 2003 A1
20030070167 Holtz et al. Apr 2003 A1
20030079226 Barrett Apr 2003 A1
20030097426 Parry May 2003 A1
20030097657 Zhou et al. May 2003 A1
20030101451 Bentolila et al. May 2003 A1
20030101454 Ozer et al. May 2003 A1
20030121037 Swix et al. Jun 2003 A1
20030121046 Roy et al. Jun 2003 A1
20030135513 Quinn et al. Jul 2003 A1
20030135853 Goldman et al. Jul 2003 A1
20030145323 Hendricks et al. Jul 2003 A1
20030149975 Eldering et al. Aug 2003 A1
20030154475 Rodriguez et al. Aug 2003 A1
20030163583 Tarr Aug 2003 A1
20030163828 Agnihotri et al. Aug 2003 A1
20030172374 Vinson et al. Sep 2003 A1
20030188318 Liew et al. Oct 2003 A1
20030188321 Shoff et al. Oct 2003 A1
20030226141 Krasnow et al. Dec 2003 A1
20030229765 Suzuoki et al. Dec 2003 A1
20040006693 Vasnani et al. Jan 2004 A1
20040006706 Erlingsson Jan 2004 A1
20040025034 Alessi et al. Feb 2004 A1
20040025174 Cerrato Feb 2004 A1
20040031052 Wannamaker et al. Feb 2004 A1
20040045020 Witt et al. Mar 2004 A1
20040059708 Dean et al. Mar 2004 A1
20040078809 Drazin Apr 2004 A1
20040088348 Yeager et al. May 2004 A1
20040143349 Roberts et al. Jul 2004 A1
20040148625 Eldering et al. Jul 2004 A1
20040158858 Paxton et al. Aug 2004 A1
20040163101 Swix et al. Aug 2004 A1
20040207719 Tervo et al. Oct 2004 A1
20040210630 Simonnet et al. Oct 2004 A1
20040215509 Perry Oct 2004 A1
20040215515 Perry Oct 2004 A1
20040216171 Barone, Jr. et al. Oct 2004 A1
20040225686 Li et al. Nov 2004 A1
20040226035 Hauser Nov 2004 A1
20040237102 Konig et al. Nov 2004 A1
20040240562 Bargeron et al. Dec 2004 A1
20040260791 Jerbi et al. Dec 2004 A1
20040267723 Bharat Dec 2004 A1
20050002640 Putterman et al. Jan 2005 A1
20050015795 Iggulden Jan 2005 A1
20050015796 Bruckner et al. Jan 2005 A1
20050021670 Maes Jan 2005 A1
20050028200 Sardera Feb 2005 A1
20050028201 Klosterman et al. Feb 2005 A1
20050028206 Cameron et al. Feb 2005 A1
20050071224 Fikes et al. Mar 2005 A1
20050080876 Peiffer et al. Apr 2005 A1
20050080878 Cunningham et al. Apr 2005 A1
20050091301 Oreizy et al. Apr 2005 A1
20050108213 Riise et al. May 2005 A1
20050108745 Linzer May 2005 A1
20050120391 Haynie et al. Jun 2005 A1
20050165696 Jakobsson et al. Jul 2005 A1
20050183143 Anderholm et al. Aug 2005 A1
20050204381 Ludvig et al. Sep 2005 A1
20050210502 Flickinger et al. Sep 2005 A1
20050232411 Srinivasan et al. Oct 2005 A1
20050235318 Grauch et al. Oct 2005 A1
20050251491 Medina et al. Nov 2005 A1
20050251577 Guo et al. Nov 2005 A1
20050251820 Stefanik et al. Nov 2005 A1
20050259819 Oomen et al. Nov 2005 A1
20050267896 Goodman et al. Dec 2005 A1
20050283796 Flickinger Dec 2005 A1
20060029368 Harville Feb 2006 A1
20060031381 Van Luijt et al. Feb 2006 A1
20060064299 Uhle et al. Mar 2006 A1
20060064583 Birnbaum et al. Mar 2006 A1
20060072144 Dowling et al. Apr 2006 A1
20060072542 Sinnreich et al. Apr 2006 A1
20060085383 Mantle et al. Apr 2006 A1
20060085642 Multerer et al. Apr 2006 A1
20060092834 Honishi et al. May 2006 A1
20060133414 Luoma et al. Jun 2006 A1
20060136964 Diez et al. Jun 2006 A1
20060143188 Bright et al. Jun 2006 A1
20060149624 Baluja et al. Jul 2006 A1
20060153296 Deng Jul 2006 A1
20060156362 Perrot Jul 2006 A1
20060168291 van Zoest et al. Jul 2006 A1
20060168616 Candelore Jul 2006 A1
20060195860 Eldering et al. Aug 2006 A1
20060212908 Hunter et al. Sep 2006 A1
20060218617 Bradstreet et al. Sep 2006 A1
20060230130 Cho et al. Oct 2006 A1
20060245724 Hwang et al. Nov 2006 A1
20060247011 Gagner Nov 2006 A1
20060247937 Binding et al. Nov 2006 A1
20060248558 Barton et al. Nov 2006 A1
20060253330 Maggio et al. Nov 2006 A1
20060265493 Brindley et al. Nov 2006 A1
20060287912 Raghuvamshi Dec 2006 A1
20070047781 Hull et al. Mar 2007 A1
20070050832 Wright et al. Mar 2007 A1
20070050854 Cooperstein et al. Mar 2007 A1
20070056008 Nagamoto et al. Mar 2007 A1
20070061724 Slothouber et al. Mar 2007 A1
20070061831 Savoor et al. Mar 2007 A1
20070072676 Baluja Mar 2007 A1
20070073581 Kempe et al. Mar 2007 A1
20070078706 Datta et al. Apr 2007 A1
20070083908 McCarthy et al. Apr 2007 A1
20070088801 Levkovitz et al. Apr 2007 A1
20070088852 Levkovitz Apr 2007 A1
20070089158 Clark et al. Apr 2007 A1
20070100690 Hopkins May 2007 A1
20070106405 Cook et al. May 2007 A1
20070106721 Schloter May 2007 A1
20070108721 Bayne et al. May 2007 A1
20070109449 Cheung May 2007 A1
20070113243 Brey May 2007 A1
20070113263 Chatani May 2007 A1
20070116365 Kloer May 2007 A1
20070124756 Covell et al. May 2007 A1
20070129108 Swanburg et al. Jun 2007 A1
20070143796 Malik Jun 2007 A1
20070156726 Levy Jul 2007 A1
20070157231 Eldering et al. Jul 2007 A1
20070168389 Lipscomb Jul 2007 A1
20070174059 Rhoads et al. Jul 2007 A1
20070180459 Smithpeters et al. Aug 2007 A1
20070186240 Ward et al. Aug 2007 A1
20070192450 Lewis Aug 2007 A1
20070198339 Shen et al. Aug 2007 A1
20070208619 Branam et al. Sep 2007 A1
20070208711 Rhoads et al. Sep 2007 A1
20070220024 Putterman et al. Sep 2007 A1
20070220575 Cooper et al. Sep 2007 A1
20070234382 Swix et al. Oct 2007 A1
20070244750 Grannan et al. Oct 2007 A1
20070250590 Flannery et al. Oct 2007 A1
20070250716 Brunk et al. Oct 2007 A1
20070253594 Lu et al. Nov 2007 A1
20070260520 Jha et al. Nov 2007 A1
20070266403 Ou et al. Nov 2007 A1
20070271300 Ramaswamy Nov 2007 A1
20070274537 Srinivasan Nov 2007 A1
20070283384 Haeuser et al. Dec 2007 A1
20070283402 Yu Dec 2007 A1
20070288985 Candelore et al. Dec 2007 A1
20070291747 Stern et al. Dec 2007 A1
20070291761 Kauniskangas et al. Dec 2007 A1
20070300264 Turner Dec 2007 A1
20070300273 Turner Dec 2007 A1
20070300280 Turner et al. Dec 2007 A1
20080004957 Hildreth et al. Jan 2008 A1
20080010133 Pyhalammi et al. Jan 2008 A1
20080040666 Wang et al. Feb 2008 A1
20080040767 McCarthy et al. Feb 2008 A1
20080046945 Hanley Feb 2008 A1
20080052195 Roth et al. Feb 2008 A1
20080059285 Hamoui Mar 2008 A1
20080060002 Noll et al. Mar 2008 A1
20080066080 Campbell Mar 2008 A1
20080066098 Witteman et al. Mar 2008 A1
20080089551 Heather et al. Apr 2008 A1
20080109307 Ullah May 2008 A1
20080109376 Walsh et al. May 2008 A1
20080109844 Baldeschwieler et al. May 2008 A1
20080109888 Ullah May 2008 A1
20080127263 Klosterman et al. May 2008 A1
20080140476 Anand et al. Jun 2008 A1
20080154678 Botelho Jun 2008 A1
20080155588 Roberts et al. Jun 2008 A1
20080155591 Mahajan et al. Jun 2008 A1
20080155627 O'Connor et al. Jun 2008 A1
20080172243 Kelly Jul 2008 A1
20080172747 Hurtado et al. Jul 2008 A1
20080174570 Jobs et al. Jul 2008 A1
20080181225 Zampiello Jul 2008 A1
20080186933 Willman et al. Aug 2008 A1
20080189757 Schackow et al. Aug 2008 A1
20080195457 Sherman et al. Aug 2008 A1
20080195749 Krig Aug 2008 A1
20080201222 Lahaix Aug 2008 A1
20080201734 Lyon et al. Aug 2008 A1
20080221987 Sundaresan et al. Sep 2008 A1
20080222045 Mukerji et al. Sep 2008 A1
20080222711 Michaelis Sep 2008 A1
20080228581 Yonezaki et al. Sep 2008 A1
20080229335 Robbin et al. Sep 2008 A1
20080243535 Binding et al. Oct 2008 A1
20080244418 Manolescu et al. Oct 2008 A1
20080263600 Olague et al. Oct 2008 A1
20080268828 Nagaraja Oct 2008 A1
20080276265 Topchy et al. Nov 2008 A1
20080276266 Huchital et al. Nov 2008 A1
20080276270 Kotaru et al. Nov 2008 A1
20080288631 Faisal et al. Nov 2008 A1
20080300011 Rhoads et al. Dec 2008 A1
20080306820 Passmore Dec 2008 A1
20080307460 Knudson et al. Dec 2008 A1
20080310731 Stojancic et al. Dec 2008 A1
20080313140 Pereira et al. Dec 2008 A1
20080313648 Wang et al. Dec 2008 A1
20080317278 Lefebvre et al. Dec 2008 A1
20090006207 Datar et al. Jan 2009 A1
20090011744 Daley et al. Jan 2009 A1
20090044223 Jiang et al. Feb 2009 A1
20090049384 Yau Feb 2009 A1
20090052784 Covell et al. Feb 2009 A1
20090055537 Takei et al. Feb 2009 A1
20090061841 Chaudhri Mar 2009 A1
20090063691 Kalofonos et al. Mar 2009 A1
20090070473 Baum et al. Mar 2009 A1
20090076821 Brenner et al. Mar 2009 A1
20090077580 Konig et al. Mar 2009 A1
20090083417 Hughes et al. Mar 2009 A1
20090088878 Otsuka et al. Apr 2009 A1
20090089251 Johnston et al. Apr 2009 A1
20090094093 Phan Apr 2009 A1
20090100361 Abello et al. Apr 2009 A1
20090100460 Hicks, III Apr 2009 A1
20090119576 Pepper et al. May 2009 A1
20090147718 Liu et al. Jun 2009 A1
20090153289 Hope et al. Jun 2009 A1
20090163227 Collins Jun 2009 A1
20090164483 Miles Jun 2009 A1
20090164641 Rogers et al. Jun 2009 A1
20090164904 Horowitz et al. Jun 2009 A1
20090165140 Robinson et al. Jun 2009 A1
20090172728 Shkedi et al. Jul 2009 A1
20090172746 Aldrey et al. Jul 2009 A1
20090185723 Kurtz et al. Jul 2009 A1
20090197524 Haff et al. Aug 2009 A1
20090199236 Barrett et al. Aug 2009 A1
20090199283 Jain Aug 2009 A1
20090210899 Lawrence-Apfelbaum et al. Aug 2009 A1
20090210902 Slaney et al. Aug 2009 A1
20090216768 Zwilling et al. Aug 2009 A1
20090231485 Steinke Sep 2009 A1
20090232305 Alessi et al. Sep 2009 A1
20090234738 Britton et al. Sep 2009 A1
20090235312 Morad et al. Sep 2009 A1
20090240821 Juncker et al. Sep 2009 A1
20090248736 Adelman et al. Oct 2009 A1
20090254554 Hicken Oct 2009 A1
20090254572 Redlich et al. Oct 2009 A1
20090259612 Hanson Oct 2009 A1
20090271398 Scherf et al. Oct 2009 A1
20090276313 Wilhelm Nov 2009 A1
20090292610 Quach et al. Nov 2009 A1
20090298480 Khambete et al. Dec 2009 A1
20090299817 Fok et al. Dec 2009 A1
20090299843 Shkedi Dec 2009 A1
20090300109 Porter Dec 2009 A1
20090307048 Grossman Dec 2009 A1
20090327076 Sinyagin et al. Dec 2009 A1
20090327496 Klemets et al. Dec 2009 A1
20100007797 Stojancic Jan 2010 A1
20100022231 Heins et al. Jan 2010 A1
20100023392 Merriman et al. Jan 2010 A1
20100023499 Johnson et al. Jan 2010 A1
20100023582 Pedersen et al. Jan 2010 A1
20100049711 Singh et al. Feb 2010 A1
20100050220 Rys et al. Feb 2010 A1
20100058380 Yu et al. Mar 2010 A1
20100063970 Kim Mar 2010 A1
20100071070 Jawa et al. Mar 2010 A1
20100083303 Redei et al. Apr 2010 A1
20100094897 Sumrall et al. Apr 2010 A1
20100099359 Lee et al. Apr 2010 A1
20100107189 Steelberg et al. Apr 2010 A1
20100119208 Davis et al. May 2010 A1
20100121891 Zampiello May 2010 A1
20100131973 Dillon et al. May 2010 A1
20100145938 Boetje et al. Jun 2010 A1
20100146552 Hassell et al. Jun 2010 A1
20100158391 Cunningham et al. Jun 2010 A1
20100161424 Sylvain Jun 2010 A1
20100174605 Dean et al. Jul 2010 A1
20100175078 Knudson et al. Jul 2010 A1
20100180216 Bates et al. Jul 2010 A1
20100185513 Anderson et al. Jul 2010 A1
20100199188 Abu-Hakima et al. Aug 2010 A1
20100205166 Boulter et al. Aug 2010 A1
20100205562 de Heer Aug 2010 A1
20100205628 Davis et al. Aug 2010 A1
20100226582 Luo et al. Sep 2010 A1
20100228611 Shenfield Sep 2010 A1
20100228625 Priyadarshan et al. Sep 2010 A1
20100251278 Agarwal et al. Sep 2010 A1
20100251289 Agarwal et al. Sep 2010 A1
20100257052 Zito et al. Oct 2010 A1
20100269138 Krikorian et al. Oct 2010 A1
20100287026 Smith Nov 2010 A1
20100287049 Rousso et al. Nov 2010 A1
20100306193 Pereira et al. Dec 2010 A1
20100306773 Lee et al. Dec 2010 A1
20100306805 Neumeier et al. Dec 2010 A1
20100306808 Neumeier et al. Dec 2010 A1
20100311345 Santori et al. Dec 2010 A1
20100318628 Pacella et al. Dec 2010 A1
20100318917 Holladay et al. Dec 2010 A1
20100319062 Danieli et al. Dec 2010 A1
20100324992 Birch Dec 2010 A1
20100325495 Talla et al. Dec 2010 A1
20100325552 Sloo et al. Dec 2010 A1
20110010737 Bouazizi et al. Jan 2011 A1
20110029555 Gao et al. Feb 2011 A1
20110029666 Lopatecki et al. Feb 2011 A1
20110032334 Raveendran et al. Feb 2011 A1
20110043652 King et al. Feb 2011 A1
20110061073 Nicholson et al. Mar 2011 A1
20110078753 Christianson et al. Mar 2011 A1
20110082939 Montemurro et al. Apr 2011 A1
20110082940 Montemurro et al. Apr 2011 A1
20110088075 Eyer Apr 2011 A1
20110099065 Georgis et al. Apr 2011 A1
20110099609 Malhotra et al. Apr 2011 A1
20110107385 Hudson et al. May 2011 A1
20110119139 Dean et al. May 2011 A1
20110122836 Kim May 2011 A1
20110125586 Evans May 2011 A1
20110131597 Cera et al. Jun 2011 A1
20110136539 Jain et al. Jun 2011 A1
20110138059 Schleifer et al. Jun 2011 A1
20110145926 Dalcher et al. Jun 2011 A1
20110154498 Fissel et al. Jun 2011 A1
20110179010 Lin et al. Jul 2011 A1
20110179447 Harkness et al. Jul 2011 A1
20110191178 Newberg et al. Aug 2011 A1
20110191352 Jones et al. Aug 2011 A1
20110213881 Stavenow et al. Sep 2011 A1
20110219322 Ramamurthy et al. Sep 2011 A1
20110238379 Misra et al. Sep 2011 A1
20110247044 Jacoby Oct 2011 A1
20110251987 Buchheit Oct 2011 A1
20110251992 Bethlehem et al. Oct 2011 A1
20110265114 Legrand Oct 2011 A1
20110265116 Stern et al. Oct 2011 A1
20110270672 Hillard et al. Nov 2011 A1
20110273625 McMahon et al. Nov 2011 A1
20110274179 Holden Nov 2011 A1
20110279445 Murphy et al. Nov 2011 A1
20110283322 Hamano Nov 2011 A1
20110289114 Yu et al. Nov 2011 A1
20110289524 Toner et al. Nov 2011 A1
20110289532 Yu et al. Nov 2011 A1
20110289544 Goosen et al. Nov 2011 A1
20110296303 Duquene et al. Dec 2011 A1
20110304771 Blanchard et al. Dec 2011 A1
20110310100 Adimatyam et al. Dec 2011 A1
20110314051 Cavet et al. Dec 2011 A1
20110317885 Leung et al. Dec 2011 A1
20110321003 Doig et al. Dec 2011 A1
20110321109 Hudson et al. Dec 2011 A1
20120011541 McCarthy Jan 2012 A1
20120017240 Shkedi Jan 2012 A1
20120023522 Anderson et al. Jan 2012 A1
20120047277 Keidar et al. Feb 2012 A1
20120054300 Marchwicki et al. Mar 2012 A1
20120054440 Doig et al. Mar 2012 A1
20120069131 Abelow Mar 2012 A1
20120072291 Bharat Mar 2012 A1
20120072420 Moganti et al. Mar 2012 A1
20120076049 Rudolf et al. Mar 2012 A1
20120084814 Olague et al. Apr 2012 A1
20120086857 Kim et al. Apr 2012 A1
20120089700 Safruti et al. Apr 2012 A1
20120101907 Dodda Apr 2012 A1
20120102515 Ramaswamy Apr 2012 A1
20120109755 Birch et al. May 2012 A1
20120124498 Santoro et al. May 2012 A1
20120130822 Patwa et al. May 2012 A1
20120130825 Evans May 2012 A1
20120131095 Luna et al. May 2012 A1
20120144416 Wetzer et al. Jun 2012 A1
20120150944 Steelberg et al. Jun 2012 A1
20120151015 Plastina et al. Jun 2012 A1
20120151521 Gilley et al. Jun 2012 A1
20120159542 Minwalla Jun 2012 A1
20120163770 Kaiser et al. Jun 2012 A1
20120163776 Hassell et al. Jun 2012 A1
20120167001 Ortiz et al. Jun 2012 A1
20120167132 Mathews et al. Jun 2012 A1
20120174155 Mowrey et al. Jul 2012 A1
20120191716 Omoigui Jul 2012 A1
20120207402 Stojancic et al. Aug 2012 A1
20120209706 Ramer et al. Aug 2012 A1
20120209726 Dean et al. Aug 2012 A1
20120210224 Wong et al. Aug 2012 A1
20120215622 Ramer et al. Aug 2012 A1
20120233163 Kirkpatrick Sep 2012 A1
20120240151 Tapper Sep 2012 A1
20120245722 Yamamura Sep 2012 A1
20120257110 Amundsen Oct 2012 A1
20120260184 Dawes et al. Oct 2012 A1
20120265616 Cao et al. Oct 2012 A1
20120272134 Steelberg et al. Oct 2012 A1
20120278825 Tran et al. Nov 2012 A1
20120280908 Rhoads et al. Nov 2012 A1
20120284746 Evans et al. Nov 2012 A1
20120284757 Rajapakse Nov 2012 A1
20120297406 Bartholomay et al. Nov 2012 A1
20120303710 Roberts et al. Nov 2012 A1
20120311074 Arini et al. Dec 2012 A1
20120311629 Zaslavsky et al. Dec 2012 A1
20120311702 Krstic et al. Dec 2012 A1
20120315014 Shuster Dec 2012 A1
20120317175 Husain et al. Dec 2012 A1
20120317178 Husain et al. Dec 2012 A1
20120317181 Husain et al. Dec 2012 A1
20120324495 Matthews et al. Dec 2012 A1
20120324566 Baum et al. Dec 2012 A1
20130013665 Sng et al. Jan 2013 A1
20130019262 Bhatia et al. Jan 2013 A1
20130019268 Fitzsimmons et al. Jan 2013 A1
20130036434 Shkedi et al. Feb 2013 A1
20130041664 McKoen et al. Feb 2013 A1
20130042262 Riethmueller Feb 2013 A1
20130045681 Dua Feb 2013 A1
20130051300 He et al. Feb 2013 A1
20130055309 Dittus Feb 2013 A1
20130060905 Mickens et al. Mar 2013 A1
20130061259 Raman et al. Mar 2013 A1
20130061267 Cansino et al. Mar 2013 A1
20130078946 Pecen et al. Mar 2013 A1
20130080242 Alhadeff et al. Mar 2013 A1
20130085865 Zhou et al. Apr 2013 A1
20130094423 Wengrovitz et al. Apr 2013 A1
20130104160 Beeson et al. Apr 2013 A1
20130104232 Johnson et al. Apr 2013 A1
20130117782 Mehta et al. May 2013 A1
20130139209 Urrabazo et al. May 2013 A1
20130139210 Huang et al. May 2013 A1
20130151728 Currier Jun 2013 A1
20130185153 Howcroft Jul 2013 A1
20130185422 Rogers et al. Jul 2013 A1
20130202150 Sinha et al. Aug 2013 A1
20130205317 Sinha et al. Aug 2013 A1
20130205319 Sinha et al. Aug 2013 A1
20130205348 Hudson et al. Aug 2013 A1
20130238702 Sheth et al. Sep 2013 A1
20130254884 Dalcher et al. Sep 2013 A1
20130263166 Fleischman Oct 2013 A1
20130290502 Bilobrov et al. Oct 2013 A1
20130297727 Levy Nov 2013 A1
20130311168 Lehmann Li Nov 2013 A1
20130318157 Harrison Nov 2013 A1
20130326554 Shkedi Dec 2013 A1
20130340011 Rodriguez Dec 2013 A1
20130340050 Harrison Dec 2013 A1
20140002247 Harrison et al. Jan 2014 A1
20140007155 Vemparala et al. Jan 2014 A1
20140007156 Harrison et al. Jan 2014 A1
20140007157 Harrison et al. Jan 2014 A1
20140007162 Harrison Jan 2014 A1
20140007187 Harrison Jan 2014 A1
20140007262 Metsäpelto et al. Jan 2014 A1
20140029847 Frye et al. Jan 2014 A1
20140032286 Lansford et al. Jan 2014 A1
20140040027 Anderson et al. Feb 2014 A1
20140040443 Sheng-Jie Syu et al. Feb 2014 A1
20140047480 Knudson et al. Feb 2014 A1
20140074621 Chai et al. Mar 2014 A1
20140074839 Popp et al. Mar 2014 A1
20140082663 Neumeier et al. Mar 2014 A1
20140090008 Li et al. Mar 2014 A1
20140130076 Moore et al. May 2014 A1
20140141714 Ghosh et al. May 2014 A1
20140143043 Wickramasuriya et al. May 2014 A1
20140150006 Vemparala et al. May 2014 A1
20140181856 Lewis Jun 2014 A1
20140184827 Chartrand Jul 2014 A1
20140195584 Harrison Jul 2014 A1
20140195620 Srinivasan et al. Jul 2014 A1
20140195649 Harrison Jul 2014 A1
20140195690 Harrison et al. Jul 2014 A1
20140195934 Harrison Jul 2014 A1
20140196085 Dunker et al. Jul 2014 A1
20140201645 Mo et al. Jul 2014 A1
20140201769 Neumeier et al. Jul 2014 A1
20140201772 Neumeier et al. Jul 2014 A1
20140201773 Neumeier et al. Jul 2014 A1
20140201774 Neumeier et al. Jul 2014 A1
20140201787 Neumeier et al. Jul 2014 A1
20140218620 Griffin et al. Aug 2014 A1
20140229271 Clapp et al. Aug 2014 A1
20140237496 Julian Aug 2014 A1
20140244351 Symons Aug 2014 A1
20140244863 Bradley et al. Aug 2014 A1
20140280304 Scherf et al. Sep 2014 A1
20140282673 Neumeier et al. Sep 2014 A1
20140282735 Davis et al. Sep 2014 A1
20140289315 Harrison Sep 2014 A1
20150003799 Oostveen et al. Jan 2015 A1
20150074526 Brenner et al. Mar 2015 A1
20150074703 Cremer et al. Mar 2015 A1
20150082331 Neumeier et al. Mar 2015 A1
20150089526 Gordon Mar 2015 A1
20150095972 Sharma et al. Apr 2015 A1
20150178280 DiMaria et al. Jun 2015 A1
20150181263 Gordon Jun 2015 A1
20150181268 Harrison et al. Jun 2015 A1
20150181311 Harrison et al. Jun 2015 A1
20150194151 Jeyachandran et al. Jul 2015 A1
20150195597 Gordon Jul 2015 A1
20150228306 Roberts et al. Aug 2015 A1
20150229690 Raesig et al. Aug 2015 A1
20150245090 Davis et al. Aug 2015 A1
20150262229 Brenner et al. Sep 2015 A1
20150302086 Roberts et al. Oct 2015 A1
20150331660 Kalampoukas et al. Nov 2015 A1
20150331661 Kalampoukas et al. Nov 2015 A1
20150331938 Kalampoukas et al. Nov 2015 A1
20150332669 Kalampoukas et al. Nov 2015 A1
20150332687 Kalampoukas et al. Nov 2015 A1
20150350725 Zhu et al. Dec 2015 A1
20150356178 Scherf et al. Dec 2015 A1
20150365456 Harrison Dec 2015 A1
20160007083 Gurha Jan 2016 A1
20160019598 Harrison Jan 2016 A1
20160019876 Jeffrey et al. Jan 2016 A1
20160110537 Harrison Apr 2016 A1
20160112770 Harrison Apr 2016 A1
20160124953 Cremer et al. May 2016 A1
20160139756 Benson et al. May 2016 A1
20160140122 Harrison May 2016 A1
20160182971 Ortiz Jun 2016 A1
20160196105 Vartakavi et al. Jul 2016 A1
20160196270 DiMaria et al. Jul 2016 A1
20160196344 Cremer et al. Jul 2016 A1
20160217799 Han et al. Jul 2016 A1
20160241540 Jeffrey et al. Aug 2016 A1
20160267180 Harron et al. Sep 2016 A1
20160323533 Nagorski et al. Nov 2016 A1
20160373197 Brenner et al. Dec 2016 A1
Foreign Referenced Citations (164)
Number Date Country
2553159 Oct 1998 CA
2413944 Jun 2003 CA
2884534 Mar 2014 CA
1726489 Jan 2006 CN
101147378 Mar 2008 CN
101622599 Jan 2010 CN
101909201 Jun 2013 CN
69815695 Jun 2004 DE
602004008936 Jun 2008 DE
1010098 Jun 2000 EP
1010098 Jun 2003 EP
1324567 Jul 2003 EP
1324567 Aug 2003 EP
1347661 Sep 2003 EP
1410380 Apr 2004 EP
1421521 May 2004 EP
1573462 Oct 2005 EP
1592198 Nov 2005 EP
1605416 Dec 2005 EP
1779659 May 2007 EP
1803270 Jul 2007 EP
1934828 Jun 2008 EP
1362485 Aug 2008 EP
1934828 Oct 2008 EP
2001583 Dec 2008 EP
1550297 Mar 2009 EP
2100216 Sep 2009 EP
1314110 Oct 2009 EP
2100216 Dec 2009 EP
2136306 Dec 2009 EP
1324567 Jan 2010 EP
2145411 Jan 2010 EP
2169854 Mar 2010 EP
1410380 Apr 2010 EP
1797552 Apr 2010 EP
2206114 Jul 2010 EP
2001583 Sep 2010 EP
2226757 Sep 2010 EP
2206114 Jul 2012 EP
1887754 Dec 2012 EP
2541961 Jan 2013 EP
2136306 Mar 2013 EP
2541961 Apr 2013 EP
1969810 Aug 2013 EP
2520084 Nov 2013 EP
2285066 May 2014 EP
2747370 Jun 2014 EP
2200258 Nov 2014 EP
2895971 Jul 2015 EP
2944051 Nov 2015 EP
2895971 May 2016 EP
3084646 Oct 2016 EP
2944051 Nov 2016 EP
3090330 Nov 2016 EP
3090429 Nov 2016 EP
3117390 Jan 2017 EP
2457694 Aug 2009 GB
2007220137 Aug 2007 JP
2007257820 Oct 2007 JP
2007280382 Oct 2007 JP
2009075603 Apr 2009 JP
2013013092 Jan 2013 JP
20030005279 Jan 2003 KR
20040021684 Mar 2004 KR
20040024870 Mar 2004 KR
20040029452 Apr 2004 KR
20040086350 Oct 2004 KR
20050046815 May 2005 KR
20050061566 Jun 2005 KR
20050061594 Jun 2005 KR
20050086470 Aug 2005 KR
20050113614 Dec 2005 KR
20050117558 Dec 2005 KR
20070095282 Sep 2007 KR
20080043358 May 2008 KR
100961461 Jun 2010 KR
20150054861 May 2015 KR
20150106904 Sep 2015 KR
1020160101979 Aug 2016 KR
20160135751 Nov 2016 KR
1995012278 May 1995 WO
2000052929 Sep 2000 WO
2000054504 Sep 2000 WO
2001044992 Jun 2001 WO
2001082625 Nov 2001 WO
2001089213 Nov 2001 WO
2001089217 Nov 2001 WO
200231742 Apr 2002 WO
2003009277 Jan 2003 WO
2003012695 Feb 2003 WO
2003019560 Mar 2003 WO
2003025762 Mar 2003 WO
2003009277 Sep 2003 WO
2003019560 Jan 2004 WO
2003012695 Mar 2004 WO
2004040416 May 2004 WO
2004044820 May 2004 WO
2005041455 May 2005 WO
2005050620 Jun 2005 WO
2004040416 Aug 2005 WO
2005125198 Dec 2005 WO
2006018790 Feb 2006 WO
2006041928 Apr 2006 WO
2007022533 Feb 2007 WO
2007022533 Jun 2007 WO
2007103583 Sep 2007 WO
2007114796 Oct 2007 WO
2008029188 Mar 2008 WO
2007103583 May 2008 WO
2008052205 May 2008 WO
2008086104 Jul 2008 WO
2008112858 Sep 2008 WO
2008131247 Oct 2008 WO
2008137756 Nov 2008 WO
2009023647 Feb 2009 WO
2009042858 Apr 2009 WO
2009091338 Jul 2009 WO
2009114622 Sep 2009 WO
2009131861 Oct 2009 WO
2009132084 Oct 2009 WO
2008137756 Dec 2009 WO
2009150425 Dec 2009 WO
2010046123 Apr 2010 WO
2010072986 Jul 2010 WO
2010129693 Nov 2010 WO
2010151421 Dec 2010 WO
2011011002 Jan 2011 WO
2011030231 Mar 2011 WO
2011090540 Jul 2011 WO
2011090541 Jul 2011 WO
2012005994 Jan 2012 WO
2012013893 Feb 2012 WO
2012021538 Feb 2012 WO
2012028976 Mar 2012 WO
2012051115 Apr 2012 WO
2012109666 Aug 2012 WO
2012120253 Sep 2012 WO
2012154541 Nov 2012 WO
2013028899 Feb 2013 WO
2013032787 Mar 2013 WO
2013068619 May 2013 WO
2013089674 Jun 2013 WO
2013147587 Oct 2013 WO
2014042826 Mar 2014 WO
2014052015 Apr 2014 WO
2014042826 May 2014 WO
2014107311 Jul 2014 WO
2014142758 Sep 2014 WO
2014145929 Sep 2014 WO
2014145938 Sep 2014 WO
2014145947 Sep 2014 WO
2015094558 Jun 2015 WO
2015102921 Jul 2015 WO
2015103384 Jul 2015 WO
2015138601 Sep 2015 WO
2015167901 Nov 2015 WO
2015183914 Dec 2015 WO
2016018472 Feb 2016 WO
2016018472 Mar 2016 WO
2016109500 Jul 2016 WO
2016109553 Jul 2016 WO
2016109682 Jul 2016 WO
2016109553 Aug 2016 WO
2016109682 Sep 2016 WO
Non-Patent Literature Citations (94)
Entry
“Secure Browsing with Ceedo”, Ceedo Flexible computing (pp. 2).
“Sandboxes and Silver Bullets: Vendors Promote New/Old Detection Techniques to Stop Zero-Day Threats”, IT Current Analysis Connection Blogs, Mar. 29, 2013 by Paula Musich (p. 1) http://itcblogs.currentanalysis.com/2013/03/29/sandboxes-and-silver-bullets-vendors-promote-newold-detection- techniques-to-stop-zero-day-threats/.
“Introduction to security” (pp. 8) http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf6167e-7fff.html#WS2db454920e96a9e51e63e3d11c0bf6167e-7ff9.
“Screenshot of Wikipedia page of Samba TV”, Jan. 5, 2015 (pp. 2) http://en.wikipedia.org/wiki/Samba_TV.
“Screenshot of Wikipedia page of Smart TV”, Jan. 5, 2015 (pp. 4) http://en.wikipedia.org/wiki/Smart_TV.
“Screenshot of Wikipedia page of Interactive television”, From Wikipedia, Jan. 5, 2015 (pp. 8) http://en.wikipedia.org/wiki/Interactive_television.
“Screenshot of Wikipedia page of Social television”, From Wikipedia, Jan. 5, 2015 (pp. 3) http://en.wikipedia.org/wiki/Social_television.
“Screenshot of Wikipedia page of Enhanced TV”, From Wikipedia, Jan. 5, 2015 (p. 1) http://en.wikipedia.org/wiki/Enhanced_TV.
“Screenshot of Wikipedia page of Digital video fingerprinting”, From Wikipedia, Jan. 5, 2015 (pp. 4) http://en.wikipedia.org/wiki/Digital_video_fingerprinting.
“Screenshot of Wikipedia page of Second screen”, From Wikipedia, Jan. 5, 2015 (pp. 3) http://en.wikipedia.org/wiki/Second_screen.
Reverse Sandboxing with SafeCentral, SafeCentral (pp. 3) http://www.safecentral.com/pdfs/ReverseSandboxing.pdf.
“Collect, Manage, and Analyze everything occurring on your network”, RSA Security Analytics, Detect & Investigate Threats. (pp. 5) http://www.emc.com/collateral/data-sheet/security-analytics-infrastructure-ds.pdf.
“Metazen—metadata capture for metagenomes”, Standards in Genomic Sciences, by Jared Bischof et al. (pp. 6) http://www.standardsingenomics.com/content/pdf/1944-3277-9-18.pdf.
“Semantic Annotation of Images and Videos for Multimedia Analysis”, by Stephan Bloehdorn et al. (pp. 15) http://image.ntua.gr/papers/345.pdf.
“Architecture for Interoperability of Services between an ACAP Receiver and Home Networked Devices”, Jan. 15, 2006, by Yu-Seok Bae et al. (pp. 6).
“Smart SoftPhone Device for Networked AudioVisual QoS/QoE Discovery & Measurement”, Digital Media Laboratory, Information and Communications University, Republic of Korea, by Jinsul Kim, (pp. 23) http://cdn.intechopen.com/pdfs-wm/5446.pdf.
“Market Potential for Interactive Audio-visual Media”, IEEE Xplore, by Andra Leurdijk et al., (p. 1) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1592082&url=http%3A%2F%2Fieeexplorejeee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1592082.
“Design of a multi-sender 3D videoconferencing application over an end system multicast protocol”, '03 Proceedings of the eleventh ACM international conference on Multimedia, New York, NY, USA, 2003 by Mojtaba Hosseini et al., (p. 1) http://dl.acm.org/citation.cfm?id=957119.
“Cisco Medianet Data Sheet”, Cisco 3900 Series Integrated Services Routers, (pp. 8) http://www.cisco.com/c/en/us/products/collateral/routers/3900-series-integrated-services-routers-isr/data_sheet_c78-612429.html.
“Delivery of Personalized and Adaptive Content to Mobile Devices: A Framework and Enabling Technology”, Communications of the Association for Information Systems (vol. 12, 2003)183-202, by D. Zhang, (pp. 22) http://aisel.aisnet.org/cgi/viewcontent.cgi?article=3178&context=cais.
“Single Sign-On for Java Web Start Applications Using MyProxy”, by Terry Fleury et al. (pp. 7) http://grid.ncsa.illinois.edu/papers/sws-myproxy-jws.pdf.
“MonALISA : A Distributed Monitoring Service Architecture”, CHEP03, La Jolla, California, Mar. 24-28, 2003 by H.B. Newman et al. (pp. 8) http://monalisa.caltech.edu/documentation/MOET001.pdf.
“Exploratory geospatial analysis using GeoVISTA Studio: from a desktop to the Web”, IEEE Xplore, Dec. 3-6, 2001, by M. Takatsuka et al. (p. 1) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=996715&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D996715.
“Comprehensive Multi-platform Collaboration”, Department of Computer Science, Columbia University, by kundan Singh et al. (pp. 36) http://www.cs.columbia.edu/˜library/TR-repository/reports/reports-2003/cucs-027-03.pdf.
“Privacy-Preserving Remote Diagnostics”, The University of Texas at Austin, by Justin Brickell et al. (pp. 10) https://www.cs.utexas.edu/˜shmat/shmat_ccs07.pdf.
“Supporting Dynamic Ad hoc Collaboration Capabilities”, LBNL, Berkeley, CA 94720, USA, by D. Agarwal et al. (pp. 6) http://arxiv.org/ftp/cs/papers/0307/0307037.pdf.
“A Framework for Classifying Peer-to-Peer Technologies”, IEEE Xplore, May 21-24, 2002, by K. Kant et al. (p. 1) http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1540491&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5% 2F10335%2F32898%2F01540491.pdf%3Farnumber%3D1540491.
“Cognitive Radio Technology”, from The Guest Editor in IEEE Signal Processing Magazine on Nov. 2008 by Maria Gabriella di Benedetto et al. (p. 1) http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4644050.
“Automated Content Recognition creating content aware ecosystems”, in CSI Magazine in Sep. 2012 (pp. 16) http://www.csimagazine.com/csi/whitepapers/ACR%20Creating%20%20content-aware%20ecosystems%20-Civolution%20White%20Paper%20-%20Sept%202012.pdf.
“A Confidence Based Recognition System for TV Commercial Extraction”, in 2008 by Yijun Li et al. (pp. 8) http://crpit.com/confpapers/CRPITV75Li.pdf.
“TV Retargeting”, Market View, wywy—Maximizing TV Advertising ROI, Dec. 31, 2015 (pp. 2) http://wywy.com/market-view/tv-retargeting/.
“The New Age of Second Screen: Enabling Interaction”, admonsters webpage, Jun. 5, 2013, Joshua R. Weaver (pp. 3) https://www.admonsters.com/blog/second-screen-enabling-interaction.
“Complaint for Patent Infringement”, Case 2:15-cv-01725-RWS Document 1, Nov. 6, 2015 (pp. 7).
“OpenX Ad Server: Beginner's Guide”, Packt Publishing by Murat Yilmaz (pp. 26) https://www.packtpub.com/sites/default/files/0202_OpenX%20Ad%20Server%20Beginner's%20Guide_SampleChapter.pdf.
“HTML & CSS: The Complete Reference”, The McGraw-Hill Companies, 2010 by Thomas A. Powell (pp. 857) http://www.pdfiles.com/pdf/files/English/Web_Apps_Programming_&_Internet/HTML_&_CSS_The_Complete_Reference.pdf.
“Web Services Essentials”, O'Reilly, Feb. 2002 by Ethan Cerami (pp. 286) http://spurrier.gatorglory.com/PDFs/O'Reilly%20-%20Web%20Services%20Essentials.pdf.
“UPnP Device Architecture 1.0”, UPnP Forum, Oct. 15, 2008 (pp. 81) http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf.
“Mac OS X Snow Leopard: The Missing Manual”, O'Reilly Media, Inc., 2009 by David Pogue (pp. 903) http://crypto.cs.mcgill.ca/˜simonpie/webdav/ipad/EBook/MacOSX/Mac%20OS%20X%20Snow%20Leopard%20The%20Missing%20Manual.pdf.
“The Common Object Request Broker: Architecture and Specification Revision 2.0”, Feb. 1997 (pp. 634) http://www.omg.org/spec/CORBA/2.0/PDF.
“Internet: The Complete Reference”, Tata McGraw-Hill Education Pvt. Ltd., 2002 by Margaret Levine Young http://www.abebooks.com/Internet-Complete-Reference-Second-Edition-Margaret/5122896620/bd.
“HTML 4.0 Sourcebook”, John Wiley & Sons, Apr. 1998 by Ian S. Graham (pp. 656) http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471257249.html.
“Zero Configuration Networking: The Definitive Guide”, O'Reilly Media, Dec. 2005 by Daniel H Steinberg et al. (pp. 254) http://shop.oreilly.com/product/9780596101008.do#tab_04_2.
https://web.archive.org/web/20110722022038/http://www.flingo.tv/.
https://web.archive.org/web/20120616002448/http://www.flingo.tv/.
https://web.archive.org/web/20130423033122/http://flingo.tv/.
https://web.archive.org/web/20101015033305/http://flingo.org/.
https://web.archive.org/web/20110609062427/http://www.flingo.org/.
“Security in the Large: Is Java's Sandbox Scalable?”, HP Hewlett Packard Apr. 1998, by Qun Zhong et al.(pp. 9) http://www.hpl.hp.com/techreports/98/HPL-98-79.pdf.
“For Developers”, Flingo Article, Oct. 2010, by Flingo https://web.archive.org/web/20101028221214/flingo.org/developers.html.
“Anomaly Detection in Dynamic Execution Environments”, NSPW 2002, by Hajime Inoue et al. (pp. 9) http://www.nspw.org/papers/2002/nspw2002-inoue.pdf.
“iPhone Security Analysis”, Department of Computer Science San Jose State University, May 2008, by Vaibhav Pandya. (pp. 44) http://www.cs.sjsu.edu/faculty/stamp/students/pandya_vaibhav.pdf.
“I, Me and My Phone: Identity and Personalization using Mobile Devices”, HP Invest, Nov. 2007 by Riddhiman Ghosh et al. (pp. 14) http://www.hpl.hp.com/techreports/2007/HPL-2007-184.pdf.
“Extending the web to support personal network services”, SAC '13, Mar. 2013, by John Lyle et al, (pp. 6) https://www.cs.ox.ac.uk/files/5273/sac2013.pdf.
“Java and Java Virtual Machine Security Vulnerabilities and their Exploitation Techniques”, Black Hat Briefings, Singapore, Oct. 2002, by Delirium. (pp. 91) http://www.blackhat.com/presentations/bh-asia-02/LSD/bh-asia-02-lsd.pdf.
“Shazam Announces Application for iPhone”, by Shazam, Jul. 2008. http://news.shazam.com/pressreleases/shazam-announces-application-for-iphone-890432.
“Shazam Launches Android Application Integrated with MySpace and Amazon MP3”, by Shazam, Oct. 2008. http://news.shazam.com/pressreleases/shazam-launches-android-application-integrated-with-myspace-and-amazon-mp3-890456.
“The Shazam music recognition service” ,Communications of the ACM—Music information retrieval, Aug. 2006, by Shazam. https://www.researchgate.net/publication/220423945_The_Shazam_music_recognition_service.
“An Industrial-Strength Audio Search Algorithm”, International Conference on Music Information Retrieval, 2003, by Avery Wang. https://www.ee.columbia.edu/˜dpwe/papers/Wang03-shazam.pdf.
“It Just Works: UPnP in the Digital Home”, The Journal of Spontaneous Networking, Oct. 2004, by Michael Jeronimo. http://www.artima.com/spontaneous/upnp_digihome.html.
“Data-Confined HTML5 Applications”, European Symposium on Research in Computer Security, London Mar. 2013, by Devdatta Akhawe (pp. 18) http://devd.me/papers/dcs-esorics.pdf.
“A Component-based Software Infrastructure for Ubiquitous Computing”, Parallel and Distributed Computing, 2005, by Areski Flissi et al. (pp. 22) http://www.lifi.fr/ispdc2005/presentations/flissi_ispdc_slides.pdf.
“A robust image fingerprinting system using the Radon transform”, Signal Processing: Image Communication 19 (2004) 325-339, May 2004, by Jin Seo et al. http://www.123seminarsonly.com/Seminar-Reports/027/60224236-Finger-Printing.pdf.
“An Authentication and Authorization Architecture for Jini Services”, CiteSeer, by Oct. 2000, by Thomas Schoch et al. http://www.vs.inf.ethz.ch/publ/papers/da-schoch.pdf.
“Analysis and Prediction of Set-Top-Box Reliability in Multi-Application Environments using Artificial Intelligence Techniques”, Spring Technical Forum, 2004,Louis Slothouber et al. (pp. 9) file:///C:/Users/User/Downloads/2004-analysis-and-prediction-of-set-top-box-reliability-in-multi-application-environments-using-artificial-intelligence-techniques%20(1).pdf.
“Artificial Intelligence in Cable TV Applications”, Advancing Technology's Agends, Louis Slothouber et al., 2003, (pp. 8) file:///C:/Users/User/Downloads/2003-artifcial-intelligence-in-cable-tv-applications%20(2).pdf.
“Exploiting Cross Context Scripting Vulnerabilities in Firefox”, Security-Assessment.com Addendum, Apr. 2010, by Nick Freeman et al. (pp. 8) http://www.security-assessment.com/files/whitepapers/Exploiting_Cross_Context_Scripting_vulnerabilities_in_Firefox.pdf.
“Design and Implementation of Fingerprinting-based Broadcasting Content Identification System”, Creative Content Research Laboratory, ETRI(Electronics and Telecommunications Research Institute), Feb. 2014, by Jihyun Park et al. http://www.icact.org/upload./2014/0249/20140249_biography.pdf.
“Efficient Software-Based Fault Isolation”, SOSP '93 Proceedings of the fourteenth ACM symposium on Operating systems principles, Dec. 1993, by Robert Wahbe et al. (pp. 14) https://crypto.stanford.edu/cs155/papers/sfi.pdf.
“Java and .NET Security”,Secure Computer Systems, Oct. 2005 by Martin Russold et al. (pp. 6) https://www.it.uu.se/edu/course/homepage/sakdat/ht05/assignments/pm/programme/Java_and_NET.pdf.
“Java™ Web Start Overview”, White Paper, May 2005, by Sun Microsystems, Inc. (pp. 14) http://www.oracle.com/technetwork/java/javase/ws-white-paper-150004.pdf.
“Programming the Grid with gLite”, Enabling Grids for E-Science, Mar. 2006, by Laure et al. (pp. 18) http://cds.cern.ch/record/936685/files/egee-tr-2006-001.pdf.
“Shazam Turns Up the Volume on Mobile Music”, Nov. 2007, by Shazam. http://news.shazam.com/pressreleases/shazam-turns-up-the-volume-on-mobile-music-890300.
“The Evolution of the JAVA Security Model”, International Conference on Computer Systems and Technologies—CompSysTech' 2005, by Nikolaj Cholakov et al. (pp. 6) http://ecet.ecs.uni-ruse.bg/cst05/Docs/cp/SIII/IIIB.12.pdf.
“The iPhone Developer's Cookbook—Building Applications with the iPhone SDK”, Developer's Library, 2008, by Erica Sadun. (pp. 360) http://www.ebooksbucket.com/uploads/itprogramming/iosappdevelopment/The_iPhone_Developers_Cookbook.pdf.
“Towards Distributed Service Discovery in Pervasive Computing Environments”, IEEE Transactions on Mobile Computing, vol. 5, No. , pp. 97-112, Feb. 2006, by Dipanjan Chakraborty. https://www.computer.org/csdl/trans/tm/2006/02/h0097-abs.html.
“Twisted Python and Bonjour”, Indelible.org, Jan., 2009, by Parise. http://www.indelible.org/ink/twisted-bonjour/.
“UPnP in Digital Home Networking”, QuEST, by Quest Global Services, 2015. (pp. 7) https://www.quest-global.com/wp-content/uploads/2015/08/UPnP-in_Digital_Home_Networking.pdf.
“Cross Context Scripting with Firefox”, Security-Assessment.com White Paper, Apr. 2010, by Roberto Liverani. (pp. 24) http://www.security-assessment.com/files/documents/whitepapers/Cross_Context_Scripting_with_Firefox.pdf.
“Vulnerabilities and Threats to Mobile Device Security From a Practitioner's Point of View”, Issues in Information Systems, vol. XII, No. 2, pp. 181-193, 2011, by Joseph Laverty et al.. (pp. 13) http://iacis.org/iis/2011/181-193_AL2011_1693.pdf.
“Android (operating system)”, Sep. 2008, by Spice. (pp. 9) “http://www.si2imobility.com/spicemobiles/pdf/Support-%20FAQs/Android.pdf”.
“Flingo is about to make your smart TV even smarter”, Jul. 7, 2011, by Ryan Lawler (pp. 6) https://gigaom.com/2011/07/07/flingo-launch/.
“The TV That Watches You”, Aug. 19, 2011, by Tom Simonite (pp. 5) https://www.technologyreview.com/s/425081/the-tv-that-watches-you/.
“WAP Architecture” by Wireless Application Protocol Forum, Published on Jul. 12, 2001 (pp. 24) http://www.openmobilealliance.org/tech/affillates/wap/wap-210-waparch-20010712-a.pdf.
“EFI Framework” by wireless Application Protocol Forum, Published on Dec. 17, 2001 (pp. 50) http://www.openmobilealliance.org/tech/affiliates/wap/wap-231-efi-20011217-a.pdf.
“Push OTA Protocol” by Wireless Application Protocol Forum, Published on Apr. 25, 2001 (pp. 44) http://www.openmobilealliance.org/tech/affillates/wap/wap-235-pushota-20010425-a.pdf.
“Pandora on the iPhone” uploaded on YouTube on Jul. 14, 2008 by Radiopandora, found online on May 24, 2017 (pp. 28) https://www.youtube.com/watch?v=tNMSntXtPc0.
“Pioneer Brings Pandora into Your Car” uploaded on YouTube on Aug. 4, 2010 by Pioneerelectronics, found online on May 24, 2017 (pp. 16) https://www.youtube.com/watch?v=HdyOKPhBoi4.
“iDA-X305S: Control Pandora from your dash” uploaded on YouTube on Mar. 26, 2010 by AlpineTV, found online on May 24, 2017 (pp. 14) https://www.youtube.com/watch?v=8TkWI_ILVzU.
“Sync + Retarget, Extend your TV campaign to all screen in real-time” by Samba TV, found online on May 24, 2017 (pp. 4) https://samba.tv/advertising/sync-retarget/.
“Pandora system everywhere”, by Pandora, found online on May 24, 2017 (pp. 9) https://www.pandora.com/everywhere.
Title: Content Interaction Methods and Systems Employing Portable Devices, U.S. Appl. No. 61/112,573, Name of inventor: Bruce L. Davis, filed Nov. 7, 2008.
Title: Second Screen Methods and Arrangements, U.S. Appl. No. 61/152,226, Name of inventor: Bruce L. Davis, filed Feb. 12, 2009.
Title: Second Screen Methods and Arrangements, U.S. Appl. No. 61/160,660, Name of inventor: Bruce L. Davis, filed Mar. 16, 2009.
Title: Second Screen Methods and Arrangements, U.S. Appl. No. 61/167,828, Name of inventor: Bruce L. Davis, dated Apr. 8, 2009.
Related Publications (1)
Number Date Country
20160227265 A1 Aug 2016 US
Provisional Applications (6)
Number Date Country
62183756 Jun 2015 US
61696711 Sep 2012 US
62026017 Jul 2014 US
61652153 May 2012 US
61584168 Jan 2012 US
61118286 Nov 2008 US
Continuations (4)
Number Date Country
Parent 13943866 Jul 2013 US
Child 14274800 US
Parent 13904015 May 2013 US
Child 13943866 US
Parent 13736031 Jan 2013 US
Child 13943866 US
Parent 12592377 Nov 2009 US
Child 13470814 US
Continuation in Parts (6)
Number Date Country
Parent 14017445 Sep 2013 US
Child 15011696 US
Parent 14744045 Jun 2015 US
Child 14017445 US
Parent 15011696 US
Child 14017445 US
Parent 14981938 Dec 2015 US
Child 15011696 US
Parent 14274800 May 2014 US
Child 14981938 US
Parent 13470814 May 2012 US
Child 13943866 Jul 2013 US