Patent Grant
11665509
The present application is generally related to the subject matter of co-pending and co-owned U.S. patent application Ser. No. 15/002,232 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK SERVICES IN MOVING VEHICLES” and filed Jan. 20, 2016, Ser. No. 14/959,948 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK EXTENSIBILITY AND ENHANCEMENT” and filed Dec. 4, 2015, Ser. No. 14/534,067 filed Nov. 5, 2014 and entitled “METHODS AND APPARATUS FOR DETERMINING AN OPTIMIZED WIRELESS INTERFACE INSTALLATION CONFIGURATION”, and Ser. No. 14/302,313 filed Jun. 11, 2014 and entitled “METHODS AND APPARATUS FOR ACCESS POINT LOCATION” each of the foregoing incorporated herein by reference in its entirety.
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
The present disclosure relates generally to the field of wireless networks, and specifically in one or more embodiments, to apparatus and methods for enabling a wireless access point to host, exchange, and transfer data to/from other wireless devices, such as mobile client devices. Other various disclosed embodiments provide practical commercial uses and network services.
Wireless networking technologies enable wireless devices to connect to one another. One common application for wireless technology is to provide network access to devices that are within a coverage area of a wireless network that is connected to the Internet. One such technology is Wi-Fi® (IEEE Std. 802.11), which has become the de facto standard for wireless networking in consumer electronics. Wi-Fi enables multiple interconnected access points (APs, also colloquially referred to as “hotspots”) to provide coverage areas ranging from those as small as local establishments (such as stores or coffee shops) or residences, to entire corporate and academic campuses.
Typical wireless APs have an effective connectivity range on the order of one hundred (100) feet, depending on factors such as the presence or absence of buildings or other structures (and their materials of construction), and other interfering emitters. Although large coverage areas can be formed by grouping together a number of APs with overlapping coverage, individual (or grouped) wireless APs may provide opportunities to deliver unique or tailored services or information of particular interest to clientele by virtue of their limited range.
Commercially, Wi-Fi provides high-value services to consumers in establishments outside of home, for example, airports, hotels, and restaurants. Businesses and/or promotional events often provide Internet service as a way to attract customers. Today, consumers of all ages have access to the Internet on, e.g., mobile devices; however, mobile devices remain a largely untapped source of nurturing a relationship for potential business “in the moment”, or in the future. For example, public environments usually lack ready means for electronic dialogue with potential clientele e.g., via their mobile devices. Instead, most businesses use traditional solutions for outreach, such as sending emails, contextual or other Internet advertising, distributing flyers, making radio, podcast, etc. announcements.
One problem with using Wi-Fi (or other wireless technologies) for initiating the aforementioned consumer dialogues, is that Wi-Fi connectivity has a cumbersome process to establish a Wi-Fi connection to deliver information (e.g., advertisements, emails). More pointedly, typical APs burden businesses and customers with unnecessary information, risks, and/or manual steps for connection, which may prevent potentially positive or profitable interaction between a business and a customer. Such burdens include e.g., difficulty in identifying the correct Wi-Fi AP from multiple available networks, password based access, exposure of sensitive information on a “public” network, or even forcing unwanted advertisements or other content to a customer before a connection is offered (so as to offset costs). Additionally, the users or devices may not know that certain functions are or are not supported by the Wi-Fi AP until a connection is established (i.e., there is limited visibility by the user or device into available functions or content prior to connection).
To these ends, improved methods and apparatus are needed to foster a more direct and dynamic way to communicate with consumers via ubiquitous client devices, e.g., smartphones, tablets, laptops, or even their vehicles (e.g., a vehicle equipped with Wi-Fi) by way of existing AP infrastructure, e.g., routers, modems, and hotspots associated with public establishments. Hence, solutions are needed to provide an open-access network that can automatically start an electronic dialogue between a client device and an AP.
The present disclosure addresses the foregoing needs by providing, inter alia, methods and apparatus for providing dynamic open-access networks.
In one aspect of the present disclosure, a method of providing a dynamic open-access network to at least one client device is provided. In one embodiment, the method includes: receiving information; packaging at least a portion of the information related to the proximate context into a plurality of data structures (e.g., Wi-Fi beacons); and broadcasting the plurality of structures comprising the at least the portion of the information. In one variant, the information includes information related to a proximate context (e.g., for the transmitting device, receiving device, or user of the receiving device).
In another aspect of the present disclosure, a method of participating in a dynamic open-access network is provided. In one embodiment, the method includes: receiving and acknowledging one or more data structures (e.g., beacons) comprising information that is contextually relevant to a client device, when the client device is located within a range of an access point; assembling the one or more data structures; identifying the contextually relevant information; and when the contextually relevant information is identified, performing an action related to a context.
In another aspect, an apparatus for use within a dynamic open-access network is provided. In one embodiment, the apparatus includes: a processor in data communication with one or more network interfaces; and a non-transitory computer-readable storage apparatus in data communication with the processor and comprising one or more computer programs, the one or more computer programs comprising a plurality of instructions. In one variant, the instructions are configured to, when executed on the processor: receive at least information associated with one or more proximate contexts; embed at least the information associated with the proximate context (s) into one or more data structures (e.g., beacons); and transmit the one or more data structures via the one or more network interfaces. In one implementation, the proximate context(s) is/are related to at least one event within a range of connectivity of the apparatus.
In another aspect, a system for use within a wireless open-access network is provided. In one embodiment, the system comprises a cloud-based controller in operative communication with one or more wireless access points disposed at various locations. The controller is managed by a service provider network operator (e.g., cable or satellite MSO), and configured to coordinate delivery of information to the various delivery nodes (e.g., Wi-Fi APs) based on local and/or broader network contexts and considerations.
In a further aspect, a non-transitory computer-readable apparatus is disclosed. In one embodiment, the apparatus includes a storage medium having at least one computer program disposed thereon, the at least one computer program configured to, when executed, implement dynamic open wireless network access for one or more proximate client devices. In one variant, the at least one computer program is rendered as an application program (“app”) downloadable to a user mobile device and compatible with the operating system thereof; the app enables the mobile device to extract information from “open network” beacons or other data structures for use (e.g., display, storage, later transmission). In one variant, the app comprises a virtual wallet wherein virtual coupons, rewards, points, currency, etc. can be stored and later negotiated with e.g., merchants, such as for goods or services.
In a further aspect an application programming interface (API) useful with a mobile wireless device is disclosed. In one embodiment, the API comprises an interface that can be called by e.g., an app on the mobile device in order to access “bit-stuffed” beacon data received via the 802.11 interface of the mobile device.
In another aspect, a method of utilizing Wi-Fi probe requests and probe responses for communication of open network content is disclosed.
In yet a further aspect, a wireless-enabled client device is disclosed. In one embodiment, the client device comprises a Wi-Fi-enabled smartphone or tablet or laptop computer with an application program operative to run thereon. The application computer program is configured to enable the device to extract data from one or more data structures (e.g., Wi-Fi AP beacons, probe requests, or probe responses) received by the Wi-Fi interface of the device, and render the extracted data in a useful form; e.g., for display and/or audio playout on the client device. In another embodiment, the application program comprises computerized logic configured to enable the client device to selectively (and even autonomously) determine the relevance or suitability of extracted data for the client device/user thereof, such as based on geographic location/context.
These and other aspects shall become apparent when considered in light of the disclosure provided herein.
All figures © Copyright 2015-2016 Time Warner Enterprises LLC. All rights reserved.
Reference is now made to the drawings wherein like numerals refer to like parts throughout.
As used herein, the term “access point” refers generally and without limitation to a network node which enables communication between a user or client device and another entity within a network, such as for example a Wi-Fi AP, or a Wi-Fi-Direct enabled device acting as a Group Owner (GO).
As used herein, the term “application” refers generally and without limitation to a unit of executable software that implements a certain functionality or theme. The themes of applications vary broadly across any number of disciplines and functions (such as on-demand content management, e-commerce transactions, brokerage transactions, home entertainment, calculator etc.), and one application may have more than one theme. The unit of executable software generally runs in a predetermined environment; for example, the unit could include a downloadable Java Xlet™ that runs within the JavaTV™ environment.
As used herein, the term “client device” includes, but is not limited to, set-top boxes (e.g., DSTBs), gateways, modems, personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise, and mobile devices such as handheld computers, PDAs, personal media devices (PMDs), tablets, “phablets”, smartphones, and vehicle infotainment or similar systems.
As used herein, the term “codec” refers to a video, audio, or other data coding and/or decoding algorithm, process or apparatus including, without limitation, those of the MPEG (e.g., MPEG-1, MPEG-2, MPEG-4/H.264, etc.), Real (RealVideo, etc.), AC-3 (audio), DiVX, XViD/ViDX, Windows Media Video (e.g., WMV 7, 8, 9, 10, or 11), ATI Video codec, or VC-1 (SMPTE standard 421M) families.
As used herein, the term “computer program” or “software” is meant to include any sequence or human or machine cognizable steps which perform a function. Such program may be rendered in virtually any programming language or environment including, for example, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ (including J2ME, Java Beans, etc.) and the like.
As used herein, the terms “context” or “contextually” refer without limitation to an environment and/or circumstance of the access point and/or client device. Common examples of context include: one or more events, geographic or spatial contexts, service availability, relation to other types of content, and/or characteristics of an area or establishment (which may be e.g., commercial, military, government, academic, etc.) associated with an access point or service node from which a client device may receive information. A context may be associated with information that is relevant to users of a client device, who may consume or interact with the environment or circumstance based on the contextual information.
As used herein, the term “display” means any type of device adapted to display information, including without limitation CRTs, LCDs, TFTs, plasma displays, LEDs (e.g., OLEDs), incandescent and fluorescent devices, or combinations/integrations thereof. Display devices may also include less dynamic devices such as, for example, printers, e-ink devices, and the like.
As used herein, the term “DOCSIS” refers to any of the existing or planned variants of the Data Over Cable Services Interface Specification, including for example DOCSIS versions 1.0, 1.1, 2.0, 3.0 and 3.1.
As used herein, the term “headend” refers generally to a networked system controlled by an operator (e.g., an MSO) that distributes programming to MSO clientele using client devices. Such programming may include literally any information source/receiver including, inter alia, free-to-air TV channels, pay TV channels, interactive TV, and the Internet.
As used herein, the terms “Internet” and “internet” are used interchangeably to refer to inter-networks including, without limitation, the Internet. Other common examples include but are not limited to: a network of external servers, “cloud” entities (such as memory or storage not local to a device, storage generally accessible at any time via a network connection, and the like), service nodes, access points, controller devices, client devices, etc.
As used herein, the term “memory” includes any type of integrated circuit or other storage device adapted for storing digital data including, without limitation, ROM. PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), and PSRAM.
As used herein, the terms “microprocessor” and “processor” or “digital processor” are meant generally to include all types of digital processing devices including, without limitation, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurable computer fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components.
As used herein, the terms “MSO” or “multiple systems operator” refer to a cable, satellite, or terrestrial network provider having infrastructure required to deliver services including programming and data over those mediums.
As used herein, the terms “network” and “bearer network” refer generally to any type of telecommunications or data network including, without limitation, hybrid fiber coax (HFC) networks, satellite networks, telco networks, and data networks (including MANs, WANs, LANs, WLANs, internets, and intranets). Such networks or portions thereof may utilize any one or more different topologies (e.g., ring, bus, star, loop, etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeter wave, optical, etc.) and/or communications or networking protocols (e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay, 3GPP, 3GPP2, WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).
As used herein, the term “network interface” refers to any signal or data interface with a component or network including, without limitation, those of the FireWire (e.g., FW400, FW800, etc.), USB (e.g., USB2), Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E, etc.), MoCA, Coaxsys (e.g., TVnet™), radio frequency tuner (e.g., in-band or OOB, cable modem, etc.), Wi-Fi (802.11), WiMAX (802.16), Zigbee®, Z-wave, PAN (e.g., 802.15), power line carrier (PLC), or IrDA families.
As used herein, the term “QAM” refers to modulation schemes used for sending signals over cable networks. Such modulation scheme might use any constellation level (e.g. QPSK, 16-QAM, 64-QAM, 256-QAM, etc.) depending on details of a cable network. A QAM may also refer to a physical channel modulated according to the schemes.
As used herein, the term “server” refers to any computerized component, system or entity regardless of form which is adapted to provide data, files, applications, content, or other services to one or more other devices or entities on a computer network.
As used herein, the term “storage” refers to without limitation computer hard drives, DVR device, memory, RAID devices or arrays, optical media (e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), or any other devices or media capable of storing content or other information.
As used herein, the term “Wi-Fi” refers to, without limitation and as applicable, any of the variants of IEEE-Std. 802.11 or related standards including 802.11 a/b/g/n/s/v/ac or 802.11-2012/2013, as well as Wi-Fi Direct (including inter alia, the “Wi-Fi Peer-to-Peer (P2P) Specification”, incorporated herein by reference in its entirety).
As used herein, the term “wireless” means any wireless signal, data, communication, or other interface including without limitation Wi-Fi, Bluetooth, 3G (3GPP/3GPP2), HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20, Zigbee®, Z-wave, narrowband/FDMA, OFDM, PCS/DCS, LTE/LTE-A, analog cellular, CDPD, satellite systems, millimeter wave or microwave systems, acoustic, and infrared (i.e., IrDA).
Overview
In an exemplary embodiment of the present disclosure, an open-access network is configured to provide simple and instantaneous delivery of data wirelessly to a nearby client device (e.g., smartphones, laptops, tablets, mobile devices, vehicles and the like). The data may be received from e.g., a centralized control manager at an access point (e.g., a WLAN AP), and may also be transmitted through an intermediary entity (e.g., at least one AP controller). It may also be generated locally via an AP (or its controller), or even another client. The data includes for example information of interest to the device or a user thereof, such as: promotions from a nearby store (e.g., advertisements, offers, and/or discount coupons, etc.); roaming engagements; location information, e.g., directions to a particular location (e.g., via maps, and in some cases avoiding triangulation and/or GPS usage, etc.); information relating to services on-demand (e.g., streaming); and/or network parameters, addresses, and capabilities of nearby APs enabling the device to select a connection likely to provide a better user experience.
In one variant, the data is selected to be relevant to one or more contexts (e.g., geography, demographics or psychographics of the user, hardware/software platform, etc.), such data being dynamically and intelligently selected and delivered to client devices and users within range of the AP(s) (or other network entities) that serve the information. For example, information retained in a service provider's client or subscriber database can be used by the exemplary processes described herein to dynamically customize or tailor content delivery and experience via the AP(s) in order to enhance relevance or utility to the subscriber, all in a completely “open” fashion.
In one exemplary embodiment, the contextually relevant information is embedded into one or more Wi-Fi beacons, via a bit stuffing process. Beacons have sufficient capacity to include small data, such as a service set identifier (SSID), medium access control (MAC) header, metadata, and the like. Furthermore, if/when a dedicated connection is established, the AP may enable further delivery of more “data heavy” content, such as video files, games, audio, books, etc., via the direct connection.
Other examples of actions which may be taken once a connection is established include e.g., handovers between APs, enhancement of the network by extending network coverage of an AP via other APs, and even peer-to-peer connections between client devices (such as via so-called “Wi-Fi Direct” or similar protocols).
The AP periodically broadcasts the beacons including the information received from the centralized manager (received via its AP controller). Client devices within range of the coverage of the AP may then receive the beacons. Client devices that have an enabled client application (e.g., a downloadable software application from and/or associated with the service provider, network and/or infrastructure), may then unpack and/or decode the received beacons. The client application may further enable the client device to rearrange, decrypt, or otherwise coordinate the received beacons using a common protocol used within the network (and disseminated via e.g., the centralized manager, AP(s), data center(s), and/or AP controller(s)).
In one variant, the management of various supported protocols is managed by a discrete beacon manager process within the AP (and a corresponding application program in the client device). The AP and/or client devices may also have the capacity to protect the beacons via user authentication, data encryption, or other means of access control.
In another peer-based embodiment, probe requests and/or responses transacted between two or more “Wi-Fi Direct” enabled clients can be “stuffed”, as can the beacons ultimately issued by the “group owner” or GO in such transactions, so as to obviate the need for any AP or centralized controller.
Various other embodiments of the disclosed open-access networks expand upon the capabilities of current networks by providing efficient access to information in a convenient, non-intrusive manner, and contextually responsive.
Detailed Description of Exemplary Embodiments
Exemplary embodiments of the apparatus and methods of the present disclosure are now described in detail. While these exemplary embodiments are described in the context of the previously mentioned Wi-Fi WLAN(s) associated with a managed network (e.g., hybrid fiber coax (HFC) cable architecture having a multiple systems operator (MSO), digital networking capability, IP delivery capability, and a plurality of client devices), the general principles and advantages of the disclosure may be extended to other types of networks and architectures that are configured to deliver digital media data (e.g., text, images, video, and/or audio). Such other networks or architectures may be broadband, narrowband, wired or wireless, or otherwise, the following therefore being merely exemplary in nature.
It will also be appreciated that while described generally in the context of a network providing service to commercial/retail or enterprise domain (e.g., businesses), the present disclosure may be readily adapted to other types of environments including, e.g., a customer or consumer or end user (i.e., residential), and government/military applications. Myriad other applications are possible.
Also, while certain aspects are described primarily in the context of the well-known Internet Protocol (described in, inter alia, Internet Protocol DARPA Internet Program Protocol Specification, IETF RCF 791 (September 1981) and Deering et al., Internet Protocol, Version 6 (Ipv6) Specification, IETF RFC 2460 (December 1998), each of which is incorporated herein by reference in its entirety), it will be appreciated that the present disclosure may utilize other types of protocols (and in fact bearer networks to include other internets and intranets) to implement the described functionality.
Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.
Service Provider Network—
As opposed to an unmanaged network, the managed service-provider network of
Advantageously, the service provider network 100 also allows components at the service location (e.g., Wi-Fi APs and any supporting infrastructure such as routers, switches, etc.) to be remotely reconfigured by the network MSO, based on e.g., prevailing operational conditions in the network, changes in user population and/or makeup of users at the service location, business models (e.g., to maximize profitability), etc. In certain embodiments, the service provider network also advantageously permits the aggregation and/or analysis of subscriber- or account-specific data (including inter alia, particular mobile devices associated with such subscriber or accounts) as part of the provision of services to users under the exemplary delivery models described herein.
The various components of the exemplary embodiment of the network 100 include (i) one or more data and application origination sources 102; (ii) one or more content sources 103, (iii) one or more application distribution servers 104; (iv) one or more VOD servers 105, and (v) client devices and/or Customer Premises Equipment (CPE) 106, (vi) one or more routers 108, (vii) one or more wireless access point controllers 110, and/or (viii) one or more access points 112. The distribution server(s) 104, VOD servers 105 and CPE/client device(s) 106 are connected via a bearer (e.g., HFC) network 101. A simple architecture comprising one of each of certain components 102, 103, 104, 105, 108, 110 is shown in
The exemplary architecture 150 of
Content (e.g., audio, video, data, files, etc.) is provided in each downstream (in-band) channel associated with the relevant service group. To communicate with the headend or intermediary node (e.g., hub server), the client devices/CPE 106 may use the out-of-band (OOB) or DOCSIS channels and associated protocols. The OCAP 1.0, 2.0, 3.0, 3.1 (and subsequent) specification provides for exemplary networking protocols both downstream and upstream, although the present disclosure is in no way limited to these approaches.
In addition to “broadcast” content (e.g., video programming), the systems of
Referring again to
The edge switch 194 forwards the packets received from the CMTS 199 to the QAM modulator, which transmits the packets on one or more physical (QAM-modulated RF) channels to the CPE/client devices. The IP packets are typically transmitted on RF channels (e.g., DOCSIS QAMs) that are different that the RF channels used for the broadcast video and audio programming, although this is not a requirement. The client devices/CPE 106 are each configured to monitor the particular assigned RF channel (such as via a port or socket ID/address, or other such mechanism) for IP packets intended for the subscriber premises/address that they serve. For example, in one embodiment, a business customer premises obtains its Internet access (such as for a connected Wi-Fi AP) via a DOCSIS cable modem or other device capable of utilizing the cable “drop” to the premises (e.g., a premises gateway, etc.).
While the foregoing network architectures described herein can (and in fact do) carry packetized content (e.g., IP over MPEG for high-speed data or Internet TV, MPEG2 packet content over QAM for MPTS, etc.), they are often not optimized for such delivery. Hence, in accordance with another embodiment of the disclosure, a “packet optimized” delivery network is used for carriage of the packet content (e.g., Internet data, IPTV content, etc.).
It will be appreciated that the foregoing MSO or managed network can advantageously be leveraged for easy installation of the various APs (and/or any lower-level “children APs” as described in co-owned and co-pending U.S. patent application Ser. No. 15/002,232 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK SERVICES IN MOVING VEHICLES” and filed Jan. 20, 2016, incorporated herein by reference in its entirety) within a geographic region. Consider, for example, a MSO network that is already pervasive throughout a given area (i.e., the MSO has numerous customers, both business and residential and otherwise); in such networks, the MSO already has significant infrastructure deployed, at a very high level of granularity. Hence, if an AP needs to be placed at a given location in order to effect the coverage/operation for the Wi-Fi network described herein, the MSO can easily “tap off” the existing infrastructure in that area to enable the AP placement. This may take the form of e.g., placement of an AP coincident with a given customer's extant equipment, and/or placement of new equipment that taps off a local service node. The present disclosure further contemplates provision by the MSO (or other parties) of consideration to the customer for allowing the placement of the equipment on their premises (e.g., payments, credits on their bill, special services or features, etc.).
It is also contemplated that the service provider may utilize or “piggyback” off the infrastructure of other service providers, utilities, etc. For instance, a third party service provider may have a high-bandwidth backhaul “drop” near a location desired by the MSO; the MSO can then lease, pay, rent, etc. that third party for use of the drop. Similarly, traffic signal poles, lighting, bridges, tunnels, etc. all contain a wide variety of cabling, conduits, and other infrastructure which the (host) MSO could make use of so as to obviate having to perform a new installation (and all of the attendant costs and delays thereof). Hence, consumers' ubiquitous access to the Internet via e.g., APs existing or installed within an existing infrastructure and/or other means described herein, can provide additional opportunities for businesses and other entities to communicate with or expand their reach to consumer devices, while advantageously reducing the workload on the network backend (e.g., centralized server).
Bit Stuffing Beacon Frames—
Various types of information may be included within a beacon frame. A 28-octet MAC header includes a control field 202 (depicting 802.11 protocol version, indicators, etc. to assist in delivery of data), a duration 204, a destination address 206, a source address 208, a sequence control field 212 (containing, e.g., a sequence number useful for assembly of multiple beacons carrying information fragmented in parts), and/or a high throughput control field 214. A frame check sequence (FCS) field 218 checks for cyclic redundancy to validate the received frames.
A notable element within the beacon frame 200 is a service set identifier (SSID, e.g., basic SSID 210). Practically speaking, one or more SSIDs associated with an AP can be used to identify the AP (from a consumer perspective) and/or embed information about the AP (location information, roaming information, etc., at the AP or controller side). SSIDs are particularly effective in delivering information for other devices to “see” because many existing devices are already configured to receive and display SSIDs to users as beacons are broadcast from the AP(s). A variable-length frame body 216 includes fields 220 that are not information elements and fields 222 that are information elements (e.g., 2241, 2242, 224n), which may contain information separate from that contained in SSIDs.
As shown in the diagram of an exemplary information element 224 of
So-called “bit stuffing” may be used to insert bits comprising data or information into a beacon frame (including SSIDs). Bit-stuffed beacons can be broadcasted to receiving devices, which may then be able to unpack and display the data contained in the beacons. It will be appreciated that the beacons are transmitted directly to a receiver, e.g., from an AP to nearby client devices, which does not require a preexisting connection between the AP and client device (as described elsewhere herein). Even though beacons may reach a client device within range of the AP, the client device may disregard the beacons or otherwise not interact with the data contained therein.
Referring back to the exemplary information element 224 shown in
The present disclosure contemplates a number of different paradigms for effecting bit-stuffing, including e.g.: (i) “local” bit-stuffing by the AP at its own direction or that of its immediate controller; (ii) local bit-stuffing at the direction of a remote or cloud-based controller with content, metadata to be stuffed cached locally; and (iii) local bit-stuffing based on content, metadata, etc. transmitted from the remote entity or cloud (which may or may not be pre-formatted for stuffing). For example, in one variant, the AP controller 406 may transmit bit-stuff data to the APs 402 ahead of time for local caching (i.e., to pre-position any data necessary to complete the stuffing operation). Doing so can be used to, inter alia, reduce or spread out the transmission load when sent to the APs, particularly if numerous APs that receive the same data exist. As noted, information about a video stream (i.e., metadata such as title, length, genre, etc.) may be transmitted to the APs in a format amenable to being stuffed into the AP beacons (e.g., in appropriately sized packets).
In another variant, downstream devices, such as top-level APs and/or lower-level APs (e.g., children APs as noted supra), may bit-stuff provisioned data in a hierarchical distribution scheme (e.g., the child AP updates its beacons based on how parent AP beacons arc configured).
In some embodiments, intelligent APs with robust processing capabilities can be used to shift bit-stuffing away from the backend/headend. For example, information about a video stream may be transmitted to the AP to be bit-stuffed at the AP before being broadcasted to client devices in the vicinity. Such local bit-stuffing allows the AP to locally prioritize, manage, and/or tailor bit stuffed beacons for its service population.
In one or more exemplary embodiments of the system, one or more SSIDs are associated with each AP that services an area, as described supra. Each AP broadcasts a beacon that identifies itself, and a corresponding specific SSID. For example, Table 1 shows APs 4021, 4022 and their respective SSIDs. Each beacon may contain information about the corresponding AP or the network, including information regarding available services, network capabilities, roaming information, advertisement details, location information, etc. SSIDs broadcasted to compatible client devices (i.e., can interpret the information included in the beacons, e.g., by communicating within a preset protocol used by the AP controller, AP, and client device, as further discussed below) can allow the client device to identify a service or access information of interest. In one variant, this process is automatic; i.e., the AP is capable of pushing the information onto the client device. In another variant, the information may be unique to one or more particular devices (e.g., information about lost and found items or persons may be directed to specific client devices, etc.). In a different embodiment, the beacon may merely trigger a notice that requires a user response to receive further information at the client device.
It will also be appreciated that the system can be configured for “prompt” or broadcast stuffing; e.g., information to be sent (such as an advertisement or coupon for a local business) is sent without any further response, request, or communication with any receiving client, and any device capable of reading the stuffed data (e.g., that has the appropriate API or application software disposed thereon) will receive the “payload” immediately.
In another embodiment, each AP separates advertised information into different SSIDs. For example, a first SSID includes one set of information, e.g., location information, advertisements; a second SSID includes another set of information, e.g., on-demand services (such as a list of games, books, song tracks, or movie titles available for streaming with ratings from a service node); a third SSID includes different information, e.g., bandwidth information, quality of service (QoS) information, roaming information, and so on. In the exemplary system of Table 1, AP1 broadcasts SSID1 and SSID2, which consumer devices within range can receive either SSID transmission (and in multi-radio capable clients, potentially both SSIDs). Thus, various end applications can be pushed to end users. The SSIDs are based on virtual LAN configuration (i.e., one virtual LAN per SSID), which involves additional virtual LANs within the AP controller.
Referring again to the exemplary embodiment of the system illustrated in
In one embodiment, mobile devices (e.g., smartphones, tablets, laptops) may install a downloadable application or “app” (comprising, e.g., an application programming interface (API), as discussed elsewhere herein) that allows the devices to interpret the received beacons by virtue of a beacon-unpacking protocol or language. That is, a common protocol or compatible API (enabled by, e.g., an application available from the service provider operating the AP/controller, the user's “host” service provider (e.g., an MSO) who has access to the AP/controller, etc.) among the client devices, AP(s), and/or controller allows effective transmission of data embedded in beacons and/or unpacking the data from the beacons when received. While the present disclosure envisions a common protocol that is recognized across each of the AP controller, AP, and client device, those of ordinary skill in the related arts will readily appreciate, given the contents of the present disclosure, that recognition of various information embedded in beacons (e.g., those described above such as advertisements, network capabilities, services on demand, etc.) may not require such a shared protocol framework; for example, proprietary or “closed” protocols may be used between a 3rd party service and 3rd party client-side application. For instance, in one variant, only active subscribers of an MSO can negotiate access to the bit-stuffed beacons by virtue of a protocol, scrambling, an “entitlement”; e.g., by authenticating the user device as a registered MSO-authorized device via MAC address, password, etc.
Wireless Network Architecture and Methods—
In one or more embodiments, the combined coverage of the wireless connectivity provided by APs is configured to provision network access to a so-called “open” Internet or intranet. More generally, artisans of ordinary skill in the related arts will readily appreciate that the so-called “open” combined coverage of the wireless networks and peer-to-peer sub-networks provides uncontrolled (but limited) network access to any client device. In one embodiment, such open access does not require authorization or authentication for the provision of the limited services. For example, the limited access (if any) can be restricted based on the bit-stuffed beacon information. Such open models advantageously allow mobile device users to opportunistically receive limited amounts/types of information without having to identify themselves, negotiate connections, etc. normally associated with WLAN or similar access protocols.
In one or more embodiments, each AP 504 is located within and/or services a designated area (e.g., a building, room, or plaza for commercial, corporate, academic purposes, and/or any other space suitable for Wi-Fi access). Each AP is configured to provide wireless network coverage 510, and broadcast bit-stuffed beacons within its coverage or connectivity range 510. For example, a coffee shop may have a wireless modem installed within the premises for prospective customers to connect to, including those in the parking lot via inter alia, their Wi-Fi enabled vehicles.
In some embodiments, the bit stuffing of beacons is directly managed by the AP 504 based on indigenous logic that considers various local conditions or considerations (e.g., network management criteria, etc.). In other embodiments, bit stuffed payloads may be provided to the AP, by the AP controller or centralized server 502 based on e.g., broader network wide considerations (e.g., network flow considerations), or particular intelligence present at the controller/server which the APs do not possess. For example, a given local area (e.g., shopping mall) may have a local AP controller and a number of APs at different points throughout the mall; while the local controller is aware of the operation, status, etc. of each AP, and can push locally cached data to each AP for stuffing (such as from a local cache of coupons for stores in the mall), the local controller logic may not be state-aware as to any conditions external to the mall, whether environmental, operational, event-driven, etc. So, a hypothetical tornado or other severe weather event in the general geographic area containing the mall would only be known to a more centralized, situation-aware entity (e.g., the server 502) such as via an EAS (emergency alert) system maintained by the MSO, and EAS alerts for the users of the mall would need to be pushed from the server 502 (or another, such as an EAS server) to the local controller for insertion into beacons broadcast by each AP in the mall.
Moreover, updates to cached content maintained by the AP controller or APs can be pushed from the centralized location. For example, institution or modification of coupons for a given franchise operation (e.g., fast food restaurant) can be coordinated more globally, rather than having each franchise managing such information individually.
Still other preset or dynamic content selection and insertion schemes between the AP, AP controller, and central manager may be implemented with equal success, given the contents of the present disclosure.
As described supra, the broadcast beacons are indiscriminate and contain information which enables a receiving client device 506 to detect and receive the beacon (e.g., beacon 200), unpack and optionally acknowledge its contents, and/or perform an action. In various embodiments, a client device may receive contextually relevant information in its raw format (from, e.g., an AP 504, centralized manager 502, another AP 504, an upstream AP controller, another client device, and/or another 3rd party server, etc.), or encapsulated or obfuscated in some manner (e.g., encrypted according to an out-of-band shared secret, etc.). In some embodiments, the context may be related to an event, a business, a general area (business district, academic campus, food court, shopping mall, a building, etc.), etc. and may be of interest to nearby device users (clientele, pedestrians, customers, etc.), as will be described in more detail below.
Once device 506 receives the beacon, the device reads the SSID (e.g., 210). The SSID may contain information that is e.g., relevant to the establishment associated with the AP 504 (e.g., identifying it as a “Joe's Coffee Shop” AP. The beacon may also carry information in its frame body (e.g., 216), which in various embodiments carries information elements (e.g., within information field 306). In other embodiments, information to be unpacked by the receiving device may be embedded in other portions of the beacon as well, as well as successive beacon frames or other data structures.
Information delivered via the beacons may or may not be “contextual” in nature. For instance, non-contextual information can include information which is not selected or provided based on any given context (e.g., without regard to a particular location, user, user device, etc.). An advertisement or coupon for Joe's Coffee Shop might be provided in an indiscriminant manner within e.g., a mall where no such “Joes Coffee Shop” is located, to users who may or may not like coffee, etc. Contextually relevant information, on the other hand, may be “passively” contextual (e.g., its context is determined without regard to users who may receive it, such as the foregoing coupon for Joe's Coffee Shop being broadcast via APs in a mall within which the coffee shop is actually located, but without regard to whether any users receiving it like coffee, whether the mall/shop is open or not, etc.), and/or “actively” or dynamically contextual (e.g., the aforementioned coupon being served only during hours when Joe's Coffee Shop is actually open, at greater frequency during cold/rainy weather or certain times of day, etc.).
The information broadcast via bit-stuffed beacons in one embodiment may include advertisement information (e.g., store promotion, coupons), roaming information, available services on-demand (such as videos accessible via the AP, backend, or elsewhere), location information, or network parameters for the AP or other APs connected thereto). In one variant, a store may offer coupons to promote its products or services to prospective customers entering the premises (and therefore definitely within the connectivity range of the AP(s) corresponding to the store). The coupon may include a discount offer (e.g., a percentage or amount off generally or for a particular item), limited quantity, and/or an expiration date (e.g., a set time or relative to the time the beacon was received), which may be dynamically adjusted (e.g., via information contained in subsequent beacons).
In one variant, the advertisement or coupon received by the device is indiscriminately pushed to users; that is, the content of the advertisement is unpacked by the device and shown to the user (e.g., via a display on their mobile device) with no acknowledgement, response or other communication from the user/client.
In another variant, delivery and/or viewing the advertisement or coupon requires a response from the user, e.g., by first accepting the notification and choosing to view the advertisement or coupon. In one particular aspect, the advertisement information may be partially pushed and partially held until approved; for example, general canvassing or alert information may be pushed directly to the user device, while additional details may be viewed when the user indicates interest (e.g., via a UI “click” on the push notification) which then causes delivery of the remaining or more detailed data via subsequent beacons, or establishment of a connection with the AP to receive the content.
In another embodiment, the AP may provide “roaming” information or host-network notification. For example, an airport may be serviced by multiple network service providers (for access to the Internet, cellular connectivity, streaming, etc.); e.g., a cable MSO, cellular service provider, etc. Users of the airport associated with a particular provider (e.g., subscribers) may receive information via the bit-stuffed beacon broadcast at their user devices from an AP associated with the provider; they can then subsequently establish a connection to a given SSID, log into their account, and thereby receive Internet connectivity via their host service provider.
In another embodiment, an AP may also have media on demand (music, text, photos/thumbnails, animations, TV channels, video files, etc. cached on the AP, backend, or another media server or cache with an IP address). Beacons may provide information about available and/or unavailable media (e.g., cache IP address, metadata) without a connection to the AP or elsewhere, such that a user of the device can browse and select on-demand content based on the information or metadata.
In another embodiment, location information provided by the AP via bit-stuffed beacons may also provide useful geographical information (e.g., store name, directions, maps, GPS coordinates, city name, weather, time of day), which may be stored on the AP and/or acquired and maintained from e.g., an AP controller, another AP, a centralized manager, client devices, and/or the Internet. For instance, each AP in a multi-AP installation such as a large mall or airport may cache a map of the facility (including “you are here” type data and directions) such that users with the appropriate app installed on their mobile device can access this information without having to establish a connection to the AP.
In another embodiment, network parameters or capabilities may be included in beacons broadcast by APs. Such parameters may include e.g., maximum and/or average data rates of an AP (e.g., downlink/uplink), number of devices associated/being served, network or IP address thereof, etc. Furthermore, a device may receive parameters via beacons from more than one AP, which allows the device to determine which one to connect to, e.g., during a high-connectivity or peak periods such as in a stadium featuring a sports game, where a device may be serviced by multiple APs. In some embodiments, network parameters may be adjusted (statically or dynamically) to optimize network management. As a result of adjusted network parameters, an AP may advertise greater or lower network capabilities and/or initiate handover to another AP. Techniques for mobility management supporting handovers are described in co-owned and co-pending U.S. patent application Ser. No. 14/959,948 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK EXTENSIBILITY AND ENHANCEMENT” and filed Dec. 4, 2015, incorporated supra. With respect to the foregoing, various specific measures of link quality may be utilized (including in tandem or in a confirmatory fashion) with equal success. Other examples of link quality include, without limitation: received signal strength (RSS), signal-to-noise ratio (SNR), carrier-to-noise ratio (CNR), signal-to-interference plus noise ratio (SINR), carrier-to-interference plus noise ratio (CINR), bit error rate (BER), block error rate (BLER), packet error rate (PER), etc.
In other embodiments, the beacon may be dynamically configured with literally any type of information. For example, consider a scenario in which a child or a valuable item is lost within a mall. If the mall gains custody of the child or item, the mall operator may configure the AP and/or AP controller to generate beacons that include information about the lost item or child, as well as information about likely owner(s) or guardian(s) (such as likely or known name, gender, location, etc.). So-called “Amber alerts” or other emergency messages may be pushed via the beacons as well.
In other examples, notifications for e.g., a patient waiting for a prescription pickup at a pharmacy, a customer waiting in queue for a table at a restaurant, and other similar approaches may be used. As such, tailored information within the beacon can make the information specific to one or more users who are known or likely to meet certain criteria, and devices associated with some or all of the criteria according to the information can respond to receiving the beacon by notifying the users who are likely or who welcome such information.
In each of the above embodiments and examples, various ways to indicate receipt or desire to receive the information (e.g., pushing or requiring a response) as described supra are equally applicable. Furthermore, in each of the above cases, the AP provisioning the information transmits beacons which contain information generated and/or bit stuffed at the AP 504 or upstream (e.g., at another AP, an AP controller (not shown), the Internet 111, a centralized manager 502, etc.). Any client device capable of Wi-Fi communication may thereafter receive the beacons before establishing any required or optional connection with the AP.
In one exemplary embodiment, the only network connectivity required for reception is the ability to receive an AP beacon. Artisans of ordinary skill in the related arts will readily appreciate that mere reception of a broadcasted beacon can be performed without requiring registration, authentication, authorization, negotiation, etc. between the client and the AP. Thus, an open-access network is formed, which intelligently caters to the context of events, establishments, and/or surrounding areas, as well as devices and users that may be sensitive to the context, as described supra.
In various embodiments, each AP has a virtual limited connectivity range or area (contrast, a physical range or area as determined by e.g., RSSI at the receiver) in which devices 506 may only receive beacons and/or connect to the AP. More directly, the beacon may have limitations in addition to and above the physical limitations of reception (e.g., so-called “geofencing”, etc.), such as that established via a GPS receiver on the client, or even physical boundaries of a structure or the like. For example, a device outside a geofence (as determined by their GPS coordinates, or having entered a structure as determined by e.g., scanning of a bar code or other such “check in” which is communicated to the AP/controller) may not act on beacons or connect to an AP 504, even if the AP is known to a user of the device, because APs 504 may only service devices within the geofence. In alternative embodiments, a device 506 may still act on beacons for a geofenced AP, whose service range does not encompass that device (i.e., cannot directly service the device), as described below and elsewhere herein. Such embodiments may be useful to pull potential customers from a broader area, while still limiting network resource utilization to the geofenced area.
An AP controller assists in managing multiple edge APs (e.g., those considered children APs as described supra) as well as storing information (e.g., caching content that may be inserted via beacon-stuffing), playing a middleman role that shifts processing load away from the backend but not entirely to the edge of the network. The controller 604 may be located within the same premises as the edge APs (e.g., within an intranet, or a network in which the controller and APs are all located within a common area such as a food court of a mall), or away from the premises and disposed elsewhere within a larger infrastructure (e.g., a data center).
In one variant, controller 604 is capable of performing all the tasks of an AP as described with respect to
Referring back to
In one or more embodiments, APs of different types, such as downstream APs 706, 708 (i.e., children APs) and upstream APs 702, 704 may transmit bit stuffed beacons to a client device (e.g., 712) within their connectivity range as is described in, e.g., co-pending and co-owned U.S. patent application Ser. No. 15/002,232 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK SERVICES IN MOVING VEHICLES” and filed Jan. 20, 2016, and that described in U.S. patent application Ser. No. 14/959,948 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK EXTENSIBILITY AND ENHANCEMENT” and filed Dec. 4, 2015, each of the foregoing having been incorporated herein by reference supra. As shown, client device 712 is in range of an upstream AP 704 as well as a downstream AP 706. The device 712 may be serviced by and receive information embedded in beacons originating from either AP 704 or 706. The client device 714 is within range of AP 706. In one variant, information intended for device 714 may originate from AP 704 but be broadcast via beacons from AP 706 (i.e., via a daisy-chained delivery). In this case, information is delivered from AP 704 to AP 706 via direct data connection 718 established therebetween (e.g., over Wi-Fi) and/or by sending beacons to AP 706. That is, the data received at AP 706 (from its upstream parent AP 704) may be bit stuffed at AP 706 for broadcast to its devices (e.g., 712, 714).
As shown in
Methods—
At step 802 of method 800, an AP receives information (e.g., that related to a proximate context) for insertion. In one or more embodiments, the information is received from other network entities or nodes, e.g., (i) a centralized manager or managed operator in the backend or headend of the network, (ii) another AP (e.g., edge AP or AP controller or intermediate router between the AP and the backend), (iii) a client device, and/or (iv) other 3rd party servers via e.g., the Internet. The information may be received from more than one node, via one or more connections, and/or simultaneously from multiple nodes. The information may be in raw format (e.g., unencoded video data, unencrypted text), encrypted, or already packaged (e.g., pre-formatted for bit-stuffing). In some embodiments, the information is received in “real time” for immediate delivery or broadcast (i.e., the AP is used as a conduit), including streaming delivery via a plurality of beacons in sequence, or subsequent delivery to another network entity, or for caching for later use.
In various embodiments, the information is associated with a proximate context; e.g., logically proximate or related to certain concepts, products, services, etc., physically proximate to e.g., locations, temporally proximate to past, future, or ongoing events, etc. For example, the event may include promotions, available services on demand, roaming or connection information, network parameters, location information etc. as described supra.
In one variant, the context may relate to products or services bearing a logical relation to a given circumstance (e.g., an advertisement for flight insurance at an airport, or for car insurance at a car dealer).
In another variant, a place of business partnered with or serviced by multiple providers (for access to the Internet, cellular connectivity, streaming, etc.) may provide connection information to devices associated with users/subscribers of the provider. In particular, a client device that recognizes an Internet service provider by receiving SSID information from a beacon broadcasted by an AP serviced by that provider, may then opt to connect to the service.
In another variant, a type of context may be informational or entertainment content (audio, video, images, text, books, games, etc.) available for streaming or distribution. A user interface or display associated with one or more AP(s) (or other entities in communication therewith, such as an AP controller, central server, the Internet, etc.) may show available titles or preview of various content that is accessible near the AP.
In yet another variant, a context may be network parameters for managing device connections to multiple APs. For example, one AP may be overloaded with multiple devices attempting to connect at once; the AP may broadcast network conditions of other APs with better data rate, fewer current connections, better range, etc. within the network in order to offload connections to alleviate the congestion.
In still other variants, the context may be location, time, date, weather, and/or other geographic attributes useful for nearby users.
In yet further variants, the context may be one or more individual users (or classes or types of users) themselves, whether determined “passively” or “actively” as discussed supra. For instance, a class comprising only MSO subscribers may be “passively” accessed by virtue of the subscribers having the MSO-supplied application program on their portable device; any time any one of them is within range of an AP broadcasting MSO-pushed data or information (e.g., a promotion for a first-run movie now available to subscribers of the MSO), their client “app” will unpack any stuffed data from the received beacons, and alert the user in any number of ways (e.g., immediately, via a screen display, later when the user scrolls through their received texts/notifications, etc.).
In another embodiment, the user may be notified via an email to the user's MSO email account issued by a central message server in response to an acknowledgement by the user or other response from the client device indicating that the particular subscriber or device was in fact proximate to a given AP (and hence by inference, a given location, event, etc.). As one example, an MSO subscriber that has the MSO app loaded onto their smartphone, after attending a concert sponsored by the MSO, might receive coupons or advertisements for other concerts via their MSO email account based on their incidental contact (which may be totally passive or blind) with an AP broadcasting an MSO-sponsored beacon, to which the user's smartphone app responds indicating that the user is an MSO subscriber and their identity (or e.g., device identity such as MAC address, to which the MSO can correlate the user from e.g., backend subscriber account databases).
In yet another embodiment, other apps operative to run on the client device are used to determine context, whether remotely or on the client itself. For instance, one variant uses search terms gleaned from e.g., an Internet browser application (e.g., Google Chrome® or the like) running on the client to determine one or more relevant device or user contexts. In one implementation, a routine in effect similar to a “key logger” running within the MSO app accesses UI input data (e.g., capacitive touch screen) or an API on the client device operating system (OS) to compile search terms of the user, and either use them locally, or send them to another entity (which may be the AP, or other entities further upstream) as indicators of context. For example, a user who types in or verbally enters the query “Nearest Coffee Shop” on their browser UI would be used by the local or remote process to indicate e.g., a high probability that the user likes or routinely consumes coffee, and hence Joe's Coffee Shop advertisements or coupons might be particularly applicable. In one variant, these gleaned search terms are maintained within a database of the MSO app on the user's mobile device, and used in effect to prioritize broadcast beacon content received by the device, such as by filtering or lowering the priority of non-associated content, or even calculating a logical proximity (e.g., since the user ostensibly likes coffee, other logically proximate beverages or substances such as tea, energy drinks, coffee flavored ice cream, etc. might also be of interest to the user, and hence ads or promotions for such “correlated” products or services would remain unfiltered or elevated in order of priority of display).
In another variant, the gleaned terms are communicated to the AP logic via e.g., a response to the beacon, message after connection has been established, or other communication) for either use thereby in selecting/filtering subsequent beacon-stuffed content, or for passing upstream to an associated controller, content server process, etc.
In these and other variants, any type of information that is relevant to surrounding events or characteristics of an establishment, area, location, product, service, user, etc. (i.e., the context) may be determined by the AP, the centralized manager, other APs in the network (e.g., upstream APs, children APs, AP controllers), and/or client devices within range. In other variants, such proximate context may be determined dynamically, depending on needs that arise during operation of the AP.
At step 804, the received information is packaged into one or more beacons. In various embodiments, the beacons are bit stuffed according to the discussion supra with respect to
In other embodiments, other portions of a beacon frame may be utilized to transmit information. For instance, information intended for a particular field, e.g., a source address, may be included in other fields, e.g., information field 306. Numerous beacons containing the same information may be created, as beacons are broadcast at regular intervals.
In some embodiments, the contextually relevant information is fragmented into multiple beacon frames to be assembled after receipt. In this case, a sequence number can be embedded in each beacon frame to allow a receiving device to arrange in the correct sequence. Sequence control field 212 may be useful for assembling multiple fragmented beacons, as previously referenced supra.
In some embodiments, the information may have already been embedded into one or more beacons received. In one variant, the received information may be changed upon receipt, depending on changed environments, needs, etc. For example, a change in destination address (e.g., 206) or source address (e.g., 208) of, e.g., content on other nodes, may occur at the receiving AP after a beacon containing the outdated address is received. Any other type of information is mutable once the beacon is received. In one or more embodiments, the received beacons may also be encrypted and/or verified for integrity (e.g., hash check, verify checksum with FCS field 218) and/or accuracy of the information (e.g., customer name, coupon discount percentage).
At step 806, the AP broadcasts the beacon(s). In various embodiments, beacons are announced via wireless means, e.g., over Wi-Fi. Beacons may have range or other limitations other than physical limitations (e.g., virtual geofences, etc.). Client devices within range which are capable of receiving beacons and recognizing them by virtue of a common protocol enabled by, e.g., a mobile application, a program, native capability, may read the information embedded in the broadcast beacons. While in some embodiments the beacons may be broadcasted in any order without regard to fragmentation, size of beacons, order, etc., the AP may queue beacons in a particular order in other embodiments. For example, the beacons may be queued to be broadcast in order of size (e.g., smallest beacons first) or in sequence or so as to minimize any fragmentation issues upon receipt, or according to any other prioritization scheme, such as contextual relevance. Queuing of beacons may also be used to minimize the burden on the network, optimize the transmission rate, and/or optimize the later receipt of beacons.
At step 812, the AP receives information to be inserted into the beacons. In some embodiments, the information is received for immediate, or alternatively subsequent delivery to another network entity or caching.
At step 814, the received information is packaged into one or more beacons at the AP. In some embodiments, some or all of the received information is already packaged into beacon-friendly formats or data structures (e.g., packets or bit streams of prescribed length or format).
At step 816, beacons with portions or all of the received information are broadcast from the AP. Client devices within range of the AP may receive and recognize the beacons that are broadcast.
At step 818, the AP waits to determine whether the beacon that is broadcast is recognized by a client device. In one embodiment, the beacon may contain information which a user of the client device may respond to. In another embodiment, the beacon may contain information which the device may automatically act upon (e.g., network statistics used to decide on which AP to connect to). In one or more embodiments, the client device initiates a connection with an AP based on a received beacon. In another embodiment, if the client device or a user thereof is specifically known and targeted (i.e., beacons were tailored for one or more pre-identified client devices or users), the AP may anticipate a connection request from that client device. In other variants, the AP may attempt to establish a connection with the client device.
At step 820, the AP establishes a dedicated connection with the client device. In various embodiments, the connection is made over Wi-Fi, although any other means of wireless connectivity may be used to implement the present disclosure. The SSID embedded within the broadcast beacon (in the SSID field or other fields that may contain data) may allow the receiving client device to recognize and connect to the AP where the beacon originated from. Associating a connection with one or more client devices within range may allow e.g., the AP to render the available services (e.g., provide additional data or content via the established connection, e.g., video or audio streaming, updating map information at intervals, additional graphics).
In one or more embodiments, authentication is required before connecting. Credentials may be known by the device or a user thereof (e.g., authentication, authorization, accounting, etc.) or they may be included in the beacon itself, allowing an automatic connection upon user approval (e.g., click on a notification, accept the terms of connection, acknowledge and approve the pending connection, etc.)
At step 822, such content is then provided to the client device using the established connection. In one embodiment, the connection persists until the AP or the client device disconnects manually or moves out of range. If the AP or client device moves into range, the connection may be automatically reestablished or require a reconnection using the steps above. In another embodiment, the connection may be temporary and end even if the client device remains within range, e.g., by timing out. In some variants, the connection may be conditional, e.g., by meeting one or more predetermined criteria (e.g., coupon is used, video has ended). In some embodiments, the content is encrypted at the AP and/or an upstream entity before being delivered to the client device. The content may also be checked for integrity (e.g., verify checksum with FCS field 218, hash check) and/or accuracy of the information to be provided (e.g., customer name, coupon discount percentage).
In some embodiments, at least part of the content or contextual information is displayed on the client device or a display screen associated with the device (including, e.g., a user interface (UI) or a graphical user interface (GUI)). In some variants, a response from the client device is required before displaying the information. In another embodiment, the connection established between an AP and the client device may establish the AP as a conduit, where content is sourced upstream (e.g., another AP, an AP controller, a centralized manager) or from another client device within range of the AP. In some variants, the connection between client devices may be transitioned to a peer to peer connection via e.g., handover. For example, the AP may allow exchange of IP addresses or client identification (e.g., MAC address) between two or more client devices, which may reduce latency and improve connectivity. In peer-to-peer implementations, the client devices may directly exchange information such as location or data. Various other uses and modifications of the aforementioned schema and combinations thereof are possible.
At step 902 of method 900, a client device receives one or more beacons from an entity within the network, such as an AP providing wireless network coverage that overlaps with the location of the client device. In various embodiments, the client device receives and detects beacons via a Wi-Fi protocol. Moreover, the device is able to read the contents of the beacons, including the frame body and its components as previously described with reference to
At step 904, the client device interprets each received beacon, in context with other received beacons or on an individual basis. In one embodiment, the client device assembles each received beacon according to known protocol (such as those established by an API, application, or native function within the device, as described elsewhere herein). The received beacon may be encrypted, fragmented, out of order, etc. Thus, the client device may assemble beacons at predetermined intervals (i.e., wait until an appreciable quantity of beacons registers at the device) or attempt to reconstruct them as they arrive. Certain fields within the beacon frame (e.g., sequence control field 212) may be useful in reassembling beacons that have partial information embedded therein, e.g., data exceeding the 255-octet capacity of a beacon frame. In essence, the client device attempts to “read” the beacons that it receives from APs within range. Nonetheless, in some embodiments, a client device may be limited to its capabilities, e.g., to decrypt, reassemble and/or rearrange beacons. That is, a device that is unable to decrypt an encrypted beacon may not be able to interpret the information.
In some embodiments, an MSO-provided API (such as that enabled by a downloadable application and/or native functionality within device, etc.) may define the necessary bit fields and/or field codes that are necessary to unpack and/or assemble the received beacons and information contained therein. The central manager may provide updated definitions, legends, tables, protocol information, etc. to allow the device to communicate and coordinate with the central manager, other client device(s), and/or AP(s), and reconstruct the beacons.
At step 906, the client device identifies and interprets the desired information (e.g., the contextually relevant information) embedded in the received beacon(s). In various embodiments, the relevant information is pulled out of information field 306, although the information may also have been bit stuffed in other fields within the beacon, as discussed in connection with
In one variant, such identification may be predetermined by the centralized manager according to a pre-defined common protocol that is disseminated to client devices. In some variants, the common protocol is interpreted by a client-side API or client-side application. In other embodiments, the common protocol may be fixed as a native capability of the modem itself (e.g., via compliance with a standard, or other compliance body). In some variants, the identification of relevant information may be dynamic and/or based on rules, e.g., the centralized manager may provide criteria or rules as discrete updates (e.g., application packages, downloadable applications) or via an established connection per, e.g., step 820 or step 918 (discussed below). As a result, the client device receives and interprets information that is associated with the proximate context, which may be used for quick and open access to nearby networks to e.g., enable engagement with events, offers and services that may be relevant to a user of the device. The contextually relevant information may require further action from the device or its user (e.g., it may request acceptance of one or more choices such as an AP to connect to based on disparate network parameters, choose content to be delivered on demand). Alternatively, the contextually relevant information may be a notification which requires no action (e.g., indicate a location of nearby store, scroll advertisement content, display a discount amount). Still other variations thereof may be appreciated by those of ordinary skill in the related arts, given the contents of the present disclosure.
At step 912, the client device enters the coverage region of one or more APs, and receives and detects beacons broadcast from the AP(s).
At step 914, the client device interprets each received beacon, including assembling any fragmented, out-of-order, encrypted, etc. beacons. The client device may assemble the received beacons at predetermined intervals or as they are received. In essence, the client device attempts to “read” the beacons that it receives from APs within range. In various embodiments, the client device is able to unpack and understand the embedded information in the beacons via a common protocol provided by, e.g., an MSO-distributed application or API, or a native functionality within the device.
At step 916, the client device identifies relevant information from the beacons, including but not limited to information related to proximate context. The contextually relevant information may require no further action. For example, it may simply require information to be read by a user of the device (e.g., indicate a location of nearby store, scroll advertisement content, display a discount amount). Alternatively, the identified information may require a further action from or interaction with the device or the user (e.g., it may request acceptance of one or more choices such as an AP to connect to based on disparate network parameters, choose content to be delivered on demand, deliver content or further information). In the case where further interaction is needed between the AP and the client device, a dedicated connection is required.
Optionally, at step 918, the client device initiates a connection with the AP which served the beacons. In various embodiments, the connection comprises a dedicated Wi-Fi connection; however, other types of appropriate wireless signal, communication or interface may be used to establish a connection between the AP and client device. In one embodiment, a connection between the AP and client device allows the client device to connect to other client devices within range of the AP or the network, thereby enabling peer-to-peer connection as further discussed elsewhere herein.
In another embodiment, once the client device initiates a connection, the AP acknowledges the request for connection and establishes the connection. Such “public” connections are advantageous for allowing a quick, instantaneous mechanism for content delivery. In another embodiment, the AP requires credentials or conditional rules to be met before establishing the connection. In one variant, the credentials include user-inputted information, such as a password. In some variants, the credentials include a certificate residing on the client device, a unique identifier (e.g., MAC address, serial ID), or a type of device (e.g., only either one of phones or laptops may connect to the AP, or only devices running iOS® or Android™ may connect to the AP). In other variants, compatibility (by virtue of, e.g., software versions or common protocol among client device, AP(s), centralized manager, and/or other network entities) is assessed by the client device or the AP before establishing the connection.
At step 920, the client device receives additional content via the established connection. In one embodiment, the content may be related to the proximate context (related to information previously embedded in beacons). Typically, this type of content is too large to carry over beacons. For example, the user of the device may choose to further receive the full advertisement including any discount offers and participating locations. The AP may then deliver the content, including any images, animations, videos, text, and any other type of promotional content of interest to the user. In another embodiment, the content is unrelated to the proximate context although the connection may be established for contextual reasons. For example, a user may approach a nearby AP (e.g., a service node) and receive metadata related to services on demand, such as video streaming. The fact that the user is aware of the node is relevant to the context that the receiving device is near the node; however, the actual content (e.g., a movie) is unrelated to the context. In another embodiment, handing over of the connection may be done by multiple APs. Once the client device connects with an AP and moves out of range or detects another AP offering a higher-quality connection (with fewer connected devices, higher data rate, etc.), the AP may initiate a handover to another AP. Various mobility management techniques supporting handovers are described in co-owned and co-pending U.S. patent application Ser. No. 14/959,948 entitled “APPARATUS AND METHOD FOR WIRELESS NETWORK EXTENSIBILITY AND ENHANCEMENT” and filed Dec. 4, 2015, incorporated herein by reference supra.
It can be appreciated that any type of data, information or content, including additional beacons, may be received by the client device after a connection is established with the AP. Moreover, the client device may communicate back to the AP (or other APs and/or other client devices present in the network, the mechanism for which is described supra as well as in co-owned and co-pending U.S. patent application Ser. No. 14/959,948, and send data as allowed by the AP. Various other uses and modifications of the aforementioned schema and combinations thereof are possible.
While the aforementioned methods have been discussed within the context of beacon-based discovery and initiation of wireless connections and/or delivery of content, artisans given the present disclosure will readily appreciate that a variety of other techniques may be used with equal success, without departing from the principles described herein. Other discovery techniques include, without limitation: pilot signal search, assisted discovery (e.g., via other AP(s), AP controller, other client devices, and/or other network entities), out-of-band discovery services, use of alternate interfaces (e.g., Bluetooth) to initiate handshake or service connection, network registration services, etc.
Apparatus—
In one exemplary embodiment, the processor 1002 may include one or more of a digital signal processor, microprocessor, field-programmable gate array, or plurality of processing components mounted on one or more substrates. The processor 1002 may also comprise an internal cache memory. The processing subsystem is in communication with a memory subsystem 1004, the latter including memory which may for example comprise SRAM, flash, and/or SDRAM components. The memory subsystem may implement one or more of DMA type hardware, so as to facilitate data accesses as is well known in the art. The memory subsystem of the exemplary embodiment contains computer-executable instructions which are executable by the processor subsystem.
The processing apparatus 1002 is configured to execute at least one computer program stored in memory 1004 (e.g., a non-transitory computer readable storage medium). The computer program may include a plurality of computer readable instructions configured to perform the complementary logical functions of a peer controller (PC) 1006. Other embodiments may implement such functionality within dedicated hardware, logic, and/or specialized co-processors (not shown). For instance, the peer controller (or portions of the functionality thereof) can be located in one or more MSO data centers, and/or in other “cloud” entities (whether within our outside of the MSO network).
In one embodiment, as shown, the AP includes a discrete beacon manager module 1012. The beacon manager 1012 is a hardware or software module that is in data communication with the processor 1002, memory 1004 and/or one or more interfaces 1008, 1010 to the external network. In some embodiments, the beacon manager 1012 is internal to the processor, memory, or other components of the AP 1000. The beacon manager is configured to pack information that resides on the AP or received from another network entity (such as another AP, an AP controller, centralized manager, and/or one or more client devices). At the beacon manager (and/or other components of the AP, e.g., processor 1002), information is embedded in beacons by way of bit stuffing, as discussed supra. In some variants, the beacon manager accesses the memory module 1004 to retrieve stored data. The data or information relates to open-access features such as available services, promotions offered by an establishment associated with the AP, network conditions, quality of service, location information, etc. Such features are accessible by nearby client devices that are within the connectivity range of the AP. In one variant, the beacon manager adds a layer of protection to beacons by encrypting them
In some embodiments, the beacon manager 1012 includes an internal cache or memory configured to temporarily hold a number of beacons before transmission via the network interfaces, rather than accessing an external memory module (e.g., 1004). In other embodiments, application program interfaces (APIs) such as those included in an MSO-provided application or those natively available on the AP (e.g., as part of the computer program noted supra or exclusively internal to the beacon manager module 1012) may also reside in the internal cache or other memory 1004. Such APIs may include common network protocols or programming languages configured to enable communication with other network entities as well as use of bit stuffing procedures that a receiving device may interpret for extracting information from the beacons.
In one embodiment, the complementary PC 1006 is configured to register wireless client devices and centrally control the broader wireless network (and constituent peer-to-peer sub-networks). Such configuration include, e.g., providing network identification (e.g., to APs and client devices within range), managing network congestion, and managing capabilities supported by the wireless network. In some variants, the PC 1006 may be configured to push (or respond to pull requests) for other APs or client devices so as to augment and/or enhance the coverage area.
In one embodiment, the complementary PC 1006 is further configured to communicate with one or more authentication, authorization, and accounting (AAA) servers of the network. The AAA servers are configured to provide services for, e.g., authorization and/or control of network subscribers for intelligently controlling access to computer resources, enforcing policies, auditing usage, and providing the information necessary to bill for services.
In some variants, authentication processes are configured to identify a client device or a user, such as by having the user enter valid credentials (e.g., user name and password) before access is granted, or other methods as described supra. The process of authentication may be based on each subscriber having a unique set of criteria or credentials (e.g., unique user name and password, challenge questions, entry of biometric data, entry of human-verification data such as “CAPTCHA” data, etc.) for gaining access to the network. For example, the AAA servers may compare a user's authentication credentials with user credentials stored in a database. If the authentication credentials match the stored credentials, the user may then be granted access to the network. If the credentials are at variance, authentication fails and network access may be denied.
Following authentication, the AAA servers are configured to grant a subscriber authorization for certain features, functions, and/or doing certain tasks. After logging into a system, for instance, the subscriber may try to issue commands. The authorization process determines whether the user has the authority to issue such commands. Simply put, authorization is the process of enforcing policies, i.e., determining what types or qualities of activities, resources, or services a user is permitted. Usually, authorization occurs within the context of authentication. Once a user is authenticated, they may be authorized for different types of access or activity. A given user may also have different types, sets, or levels of authorization, depending on any number of aspects. For instance, a given user may be authorized to access the AP and/or other network entities, operate as a network entity or node (e.g., for peer-to-peer connections), access a WNC, prevent access to the client device by other client devices.
The AAA servers may be further configured for accounting, which measures the resources a user consumes during access. This may include the amount of system time or the amount of data a user has sent and/or received during a session, somewhat akin to cellular data plans based on so many consumed or available GB of data. Accounting may be carried out by logging of session statistics and usage information, and is used for, inter alia, authorization control, billing, trend analysis, network resource utilization, and capacity planning activities. It will be appreciated that in other examples, one or more AAA servers may be linked to a third-party or proxy server, such as that of an event management entity.
In one embodiment, one or more backend interfaces 1008 are configured to transact one or more network address packets with other networked devices according to a network protocol. Common examples of network routing protocols include for example: Internet Protocol (IP), Internetwork Packet Exchange (IPX), and Open Systems Interconnection (OSI) based network technologies (e.g., Asynchronous Transfer Mode (ATM), Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Frame Relay). In one embodiment, the backend network interface 1008 operates in signal communication with the backbone of the content delivery network (CDN), such as that of
In one embodiment, one or more network interfaces 1010 are utilized in the illustrated embodiment for communication with other network entities, e.g., client devices, AP controllers and/or other APs, such as via Ethernet or other wired and/or wireless data network protocols. In some embodiments, the AP 1000 allows irregular access to beacons. For example, if the AP enters a “sleep” mode that has disabled one or more functions including broadcasting beacons, a client device may still seek beacons (e.g., with own beacons or attempts to establish a connection) from APs known to announce beacons that carry certain information. It will also be appreciated that the two interfaces 1008, 1010 may be aggregated together and/or shared with other extant data interfaces, such as in cases where the controller entity function is virtualized within another component, such as an MSO network server performing other functions.
In one exemplary embodiment, the processor 1102 may include one or more of a digital signal processor, microprocessor, field-programmable gate array, or plurality of processing components mounted on one or more substrates (e.g., printed circuit board). The processor subsystem 1102 may also comprise an internal cache memory. The processor subsystem is in communication with a memory subsystem 1104, the latter including memory which may for example comprise SRAM, flash, and/or SDRAM components. The memory subsystem may implement one or more of DMA-type hardware, so as to facilitate data accesses as is well known in the art. The memory subsystem of the exemplary embodiment contains computer-executable instructions which are executable by the processor subsystem.
In this and various embodiments, the processor subsystem 1102 is configured to execute at least one computer program stored in memory 1104 (e.g., a non-transitory computer readable storage medium). The computer program may include a plurality of computer readable instructions configured to perform the functions described supra, e.g., unpacking, assembly, and/or interpretation of beacons, identification of contextually relevant information from the beacons, processing of data and other delivered content, peer control management, and various assorted functions useful for and typical in consumer electronics.
In one embodiment, the beacon manager 1110 is a hardware or software module in communication with processor 1102, memory 1104 and/or receive module 1116. The beacon manager module 1110 is configured to receive beacons via a receive module 1116 and perform various functions related to interpreting the beacons (in conjunction with processor subsystem 1102 in some embodiments). For example, the beacons arriving at the client device 1100 may be out of order, fragmented, encrypted, having missing information, etc. In some embodiments, the beacon manager 1110 handles the received beacons to rearrange the beacons or determine a sequence of fragmented beacons. The beacon manager can extract information that was bit stuffed in various portions of the beacon frame. The beacon manager may also include capabilities to decrypt any encrypted beacons before unpacking the beacons and extracting information embedded therein.
In one or more embodiments, the beacon manager includes an internal cache or memory configured to hold data associated with one or more beacons. In some cases, the processor 1102 or the beacon manager 1110 may not be able to be interpret certain beacons (at least immediately). For instance, in some cases, the received beacons may have incomplete information (e.g., with respect to content fragmented across multiple subsequent beacon frames), or be encrypted or scrambled with a scheme unknown to the client device. In one variant, beacons that have shown no correlation with any known information or with other beacons may be discarded from memory immediately or after a period of time. In some embodiments, application program interfaces (APIs) such as those included in an MSO-provided mobile application or those natively available on the client device 1100 (e.g., as part of the computer program noted supra or exclusively internal to the beacon manager module 1110) may also reside in the internal cache or other memory 1104. Such APIs may include common network protocols or programming languages configured to enable communication with other network entities as well as interpretation of information embedded in the beacons (e.g., may possess decryption keys, decoding algorithms, assembly instructions for the data, etc.) that enable subsequent use by the application or other higher layer processes within the client.
In one embodiment, the radio frequency network interface 1108 is configured to transact one or more network address packets with other networked devices according to a network protocol. In particular, the network interface 1108 enables the device to receive beacons broadcasted by other network entities in the area, in accordance with the present disclosure. In one embodiment, a separate receive module 1116 is used in conjunction with the interface(s) 1108.
Network addressing may provide each node of a network with an address that is unique to that network; the address can be used to communicate (directly via peer-to-peer communications, or indirectly via a series of “hops”) with the corresponding device. In more complex networks, multiple layers of indirection may be used to assist in address exhaustion (e.g., one address is logically divided into another range of network addresses). Common examples of network routing protocols include for example: Internet Protocol (IP), Internetwork Packet Exchange (IPX), and OSI-based network technologies (e.g., Asynchronous Transfer Mode (ATM), Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Frame Relay).
A radio/modem subsystem of the client device 1100 comprises a TX transmit module 1114 and RX receive module 1116, which communicate with the RF network interface 1108. The network interface 1108 generally incorporates an assembly of filters, low noise amplifiers (LNAs), power amplifiers (PAs), and antenna assemblies that are configured to transmit a modulated waveform via an air interface. As shown, the radio/modem subsystem may be configured to support MIMO (multiple input, multiple output) antenna technology in which multiple antennas are used to transmit and receive signaling. With MIMO, multiple independent data streams can be transmitted in parallel using the same time-frequency resource. To distinguish the data streams sharing this same time-frequency resource, spatial division multiplexing is applied. Those of ordinary skill in the related arts will readily appreciate that SISO (single in, single out), SIMO (single in, multiple out), and MISO (multiple in, single out) antenna schemes may be substituted with equivalent success.
The client apparatus 1100 of the present disclosure is primarily directed to mobile consumer electronics devices, such as, but not limited to mobile devices such as handheld computers, PDAs, personal media devices (PMDs), smartphones, tablets, and “phablets,” vehicle infotainment or similar systems, and personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise. Artisans of ordinary skill will readily appreciate that consumer electronics devices may incorporate various other assorted components necessary to support typical functions of such devices, including power modules, peripherals modules, display modules (associated with, e.g., a display screen, UI, GUI), camera modules, voice codec modules, etc.
While the foregoing examples and implementations are described explicitly in the context of beacon frames transmitted from e.g., a Wi-Fi (802.11) enabled access point (AP), other modalities for delivery of “stuffed” information (and/or for upstream communication, if utilized) will be recognized by those of ordinary skill given the present disclosure.
As one example, as is known, so-called “Wi-Fi Direct” enabled devices can communicate in a peer-to-peer (P2P) fashion, irrespective of an AP. Once one of the peers has been designated “Group Owner” (GO), beacons of the type previously described herein are transmitted by the GO. Hence, the present disclosure contemplates both that (i) one STA or peer (e.g., mobile device) can communicate bit-stuffed beacons to one or more other of the peers, irrespective of any fixed AP or other network connectivity, such as where the MSO app running on the GO contains routines to stuff beacons that its host device transmits similar to the APs described above; and (ii) that two or more mobile devices can “ladder” or “daisy chain”, thereby extending delivery of the stuffed content beyond a given single device (e.g., one in wireless range of an AP or GO). For example, consider the case where a Wi-Fi Direct enabled mobile device (e.g., smartphone) of an MSO subscriber that is equipped with the aforementioned application program (the latter which can both extract stuffed bits from beacons, and stuff bits for transmission in its beacons as with the AP) receives one or more content elements (e.g., coupon) from an AP while in proximity thereto. After the smartphone of that user dissociates from the providing AP, it later encounters another smartphone of another MSO subscriber (whether incidentally or intentionally or otherwise), this other smartphone also having the aforementioned MSO app operative thereon and being Wi-Fi Direct capable. The two smartphones execute the P2P protocols according to Wi-Fi Direct operation, and one of the peers is designated as GO (here, the first smartphone). That peer then utilizes the MSO app to stuff its beacons with the content element received previously from the AP, thereby passing the coupon on to the second MSO subscriber. This approach in effect allows the coupon (or EAS message or text or picture or whatever) to propagate within at least the population of mobile device users who are MSO subscribers and who have downloaded the MSO app. Such propagation can be permissive or “open” (such as by corollary in Bluetooth pairing); in the latter option, any MSO subscriber phone or mobile device incidentally or otherwise encountering another MSO device with its association permissions disabled can immediately propagate the content element to others, and so forth.
Likewise, two STAs under 802.11 can communicate via so-called “probe requests” and “probe responses”. Such probe requests have facility for inclusion of various types of information, including e.g., one or more “vendor specific” elements disposed at the end of the frame (see e.g., IEEE Std. 802.11-2012 and 2013(802.11ac)). Probe request frames also may include “Request Information” elements. Similarly, probe responses can contain multiple types of information, including the aforementioned “requested information” in the probe request frame. Hence, the present disclosure contemplates use of other types of frames, whether alone or in conjunction with beacon frames, for transferring information between two or more Wi-Fi enabled devices.
It will be recognized that while certain aspects of the disclosure are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods of the disclosure, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the disclosure disclosed and claimed herein.
While the above detailed description has shown, described, and pointed out novel features of the disclosure as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the disclosure. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the disclosure. The scope of the disclosure should be determined with reference to the claims.
It will be further appreciated that while certain steps and aspects of the various methods and apparatus described herein may be performed by a human being, the disclosed aspects and individual methods and apparatus are generally computerized/computer-implemented. Computerized apparatus and methods are necessary to fully implement these aspects for any number of reasons including, without limitation, commercial viability, practicality, and even feasibility (i.e., certain steps/processes simply cannot be performed by a human being in any viable fashion).
This application is a divisional of and claims the benefit of priority to co-owned U.S. patent application Ser. No. 15/063,314 filed Mar. 7, 2016 and entitled “APPARATUS AND METHODS FOR DYNAMIC OPEN-ACCESS NETWORKS”, the foregoing being incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5313454 | Bustini et al. | May 1994 | A |
| 5369707 | Follendore, III | Nov 1994 | A |
| 5528284 | Iwami et al. | Jun 1996 | A |
| 5577209 | Boyle et al. | Nov 1996 | A |
| 5708961 | Hylton et al. | Jan 1998 | A |
| 5715403 | Stefik | Feb 1998 | A |
| 5774170 | Hite et al. | Jun 1998 | A |
| 5787172 | Arnold | Jul 1998 | A |
| 5818438 | Howe et al. | Oct 1998 | A |
| 5828832 | Holden et al. | Oct 1998 | A |
| 5862312 | Mann et al. | Jan 1999 | A |
| 5870474 | Wasilewski et al. | Feb 1999 | A |
| 5878324 | Borth et al. | Mar 1999 | A |
| 5897635 | Torres et al. | Apr 1999 | A |
| 5926205 | Krause et al. | Jul 1999 | A |
| 5935206 | Dixon et al. | Aug 1999 | A |
| 5982412 | Nulty | Nov 1999 | A |
| 6002393 | Hite et al. | Dec 1999 | A |
| 6009103 | Woundy | Dec 1999 | A |
| 6092178 | Jindal et al. | Jul 2000 | A |
| 6128316 | Takeda et al. | Oct 2000 | A |
| 6134532 | Lazarus et al. | Oct 2000 | A |
| 6148400 | Arnold | Nov 2000 | A |
| 6154844 | Touboul et al. | Nov 2000 | A |
| 6157719 | Wasilewski et al. | Dec 2000 | A |
| 6167432 | Jiang | Dec 2000 | A |
| 6167521 | Smith et al. | Dec 2000 | A |
| 6169728 | Perreault et al. | Jan 2001 | B1 |
| 6181697 | Nurenberg et al. | Jan 2001 | B1 |
| 6211901 | Imajima et al. | Apr 2001 | B1 |
| 6212636 | Boyle et al. | Apr 2001 | B1 |
| 6219710 | Gray et al. | Apr 2001 | B1 |
| 6219840 | Corrigan et al. | Apr 2001 | B1 |
| 6233341 | Riggins | May 2001 | B1 |
| 6233687 | White | May 2001 | B1 |
| 6240553 | Son et al. | May 2001 | B1 |
| 6249680 | Wax et al. | Jun 2001 | B1 |
| 6256393 | Safadi et al. | Jul 2001 | B1 |
| 6259701 | Shur et al. | Jul 2001 | B1 |
| 6266421 | Domyo et al. | Jul 2001 | B1 |
| 6330609 | Garofalakis et al. | Dec 2001 | B1 |
| 6353626 | Sunay et al. | Mar 2002 | B1 |
| 6378130 | Adams | Apr 2002 | B1 |
| 6434141 | Oz et al. | Aug 2002 | B1 |
| 6456716 | Arnold | Sep 2002 | B1 |
| 6463585 | Hendricks et al. | Oct 2002 | B1 |
| 6498783 | Lin | Dec 2002 | B1 |
| 6519062 | Yoo | Feb 2003 | B1 |
| 6523696 | Saito et al. | Feb 2003 | B1 |
| 6590865 | Ibaraki et al. | Jul 2003 | B1 |
| 6601171 | Carter et al. | Jul 2003 | B1 |
| 6640145 | Hoffberg et al. | Oct 2003 | B2 |
| 6657991 | Akgun et al. | Dec 2003 | B1 |
| 6687735 | Logston et al. | Feb 2004 | B1 |
| 6694145 | Riikonen et al. | Feb 2004 | B2 |
| 6711148 | Hills | Mar 2004 | B1 |
| 6718551 | Swix et al. | Apr 2004 | B1 |
| 6738978 | Hendricks et al. | May 2004 | B1 |
| 6742116 | Matsui et al. | May 2004 | B1 |
| 6760768 | Holden et al. | Jul 2004 | B2 |
| 6763391 | Ludtke | Jul 2004 | B1 |
| 6782550 | Cao | Aug 2004 | B1 |
| 6785810 | Lirov et al. | Aug 2004 | B1 |
| 6788676 | Partanen et al. | Sep 2004 | B2 |
| 6799047 | Bahl et al. | Sep 2004 | B1 |
| 6807573 | Saito et al. | Oct 2004 | B2 |
| 6813505 | Walley et al. | Nov 2004 | B2 |
| 6842783 | Boivie et al. | Jan 2005 | B1 |
| 6859535 | Tatebayashi et al. | Feb 2005 | B1 |
| 6891841 | Leatherbury et al. | May 2005 | B2 |
| 6898708 | Hori et al. | May 2005 | B2 |
| 6910064 | Astarabadi et al. | Jun 2005 | B1 |
| 6925257 | Yoo | Aug 2005 | B2 |
| 6944150 | McConnell et al. | Sep 2005 | B1 |
| 6948183 | Peterka | Sep 2005 | B1 |
| 6954632 | Kobayashi | Oct 2005 | B2 |
| 6957261 | Lortz | Oct 2005 | B2 |
| 6957328 | Goodman et al. | Oct 2005 | B2 |
| 6973576 | Giobbi | Dec 2005 | B2 |
| 6975730 | Kuroiwa et al. | Dec 2005 | B1 |
| 6985355 | Allirot | Jan 2006 | B2 |
| 6986156 | Rodriguez et al. | Jan 2006 | B1 |
| 6996544 | Sellars et al. | Feb 2006 | B2 |
| 7006881 | Hoffberg et al. | Feb 2006 | B1 |
| 7007170 | Morten | Feb 2006 | B2 |
| 7009972 | Maher et al. | Mar 2006 | B2 |
| 7016963 | Judd et al. | Mar 2006 | B1 |
| 7017189 | Demello et al. | Mar 2006 | B1 |
| 7027460 | Iyer et al. | Apr 2006 | B2 |
| 7039048 | Monta et al. | May 2006 | B1 |
| 7054443 | Jakubowski et al. | May 2006 | B1 |
| 7054902 | Toporek et al. | May 2006 | B2 |
| 7055040 | Klemba et al. | May 2006 | B2 |
| 7065216 | Benaloh et al. | Jun 2006 | B1 |
| 7068639 | Varma et al. | Jun 2006 | B1 |
| 7069449 | Weaver et al. | Jun 2006 | B2 |
| 7069573 | Brooks et al. | Jun 2006 | B1 |
| 7072950 | Toft | Jul 2006 | B2 |
| 7073199 | Raley | Jul 2006 | B1 |
| 7075945 | Arsenault et al. | Jul 2006 | B2 |
| 7086077 | Giammaressi | Aug 2006 | B2 |
| 7092397 | Chandran et al. | Aug 2006 | B1 |
| 7099308 | Merrill et al. | Aug 2006 | B2 |
| 7103181 | Ananth | Sep 2006 | B2 |
| 7106382 | Shiotsu | Sep 2006 | B2 |
| 7107326 | Fijolek et al. | Sep 2006 | B1 |
| 7143431 | Eager et al. | Nov 2006 | B1 |
| 7149772 | Kalavade | Dec 2006 | B1 |
| 7154912 | Chong et al. | Dec 2006 | B2 |
| 7165268 | Moore et al. | Jan 2007 | B1 |
| 7174126 | McElhatten et al. | Feb 2007 | B2 |
| 7174127 | Otten et al. | Feb 2007 | B2 |
| 7174371 | Elo et al. | Feb 2007 | B2 |
| 7174385 | Li | Feb 2007 | B2 |
| 7194756 | Addington et al. | Mar 2007 | B2 |
| 7209458 | Ahvonen et al. | Apr 2007 | B2 |
| 7225333 | Peinado et al. | May 2007 | B2 |
| 7228427 | Fransdonk | Jun 2007 | B2 |
| 7228555 | Schlack | Jun 2007 | B2 |
| 7237112 | Ishiguro et al. | Jun 2007 | B1 |
| 7242960 | Van et al. | Jul 2007 | B2 |
| 7248694 | Husemann et al. | Jul 2007 | B2 |
| 7254608 | Yeager et al. | Aug 2007 | B2 |
| 7257227 | Chen et al. | Aug 2007 | B2 |
| 7266726 | Ladd et al. | Sep 2007 | B1 |
| 7289534 | Bailey et al. | Oct 2007 | B1 |
| 7299502 | Schmeling et al. | Nov 2007 | B2 |
| 7305460 | Park | Dec 2007 | B2 |
| 7308415 | Kimbrel et al. | Dec 2007 | B2 |
| 7313611 | Jacobs et al. | Dec 2007 | B1 |
| 7324531 | Cho | Jan 2008 | B2 |
| 7325073 | Shao et al. | Jan 2008 | B2 |
| 7330483 | Peters, Jr. et al. | Feb 2008 | B1 |
| 7330967 | Pujare et al. | Feb 2008 | B1 |
| 7334044 | Allen | Feb 2008 | B1 |
| 7340759 | Rodriguez | Mar 2008 | B1 |
| 7346688 | Allen et al. | Mar 2008 | B2 |
| 7353543 | Ohmori et al. | Apr 2008 | B2 |
| 7363371 | Kirby et al. | Apr 2008 | B2 |
| 7373506 | Asano et al. | May 2008 | B2 |
| 7376386 | Phillips et al. | May 2008 | B2 |
| 7376976 | Fierstein et al. | May 2008 | B2 |
| 7379494 | Raleigh et al. | May 2008 | B2 |
| 7409546 | Platt | Aug 2008 | B2 |
| 7453844 | Lee et al. | Nov 2008 | B1 |
| 7457520 | Rosetti et al. | Nov 2008 | B2 |
| 7464179 | Hodges et al. | Dec 2008 | B2 |
| 7472280 | Giobbi | Dec 2008 | B2 |
| 7477621 | Loc et al. | Jan 2009 | B1 |
| 7486869 | Alexander et al. | Feb 2009 | B2 |
| 7487363 | Alve et al. | Feb 2009 | B2 |
| 7506367 | Ishibashi | Mar 2009 | B1 |
| 7551574 | Peden et al. | Jun 2009 | B1 |
| 7567565 | La | Jul 2009 | B2 |
| 7577118 | Haumonte et al. | Aug 2009 | B2 |
| 7592912 | Hasek et al. | Sep 2009 | B2 |
| 7602820 | Helms et al. | Oct 2009 | B2 |
| 7673004 | Sherstinsky et al. | Mar 2010 | B1 |
| 7690020 | Lebar | Mar 2010 | B2 |
| 7693171 | Gould | Apr 2010 | B2 |
| 7707644 | Choi et al. | Apr 2010 | B2 |
| 7721314 | Sincaglia et al. | May 2010 | B2 |
| 7730321 | Gasparini et al. | Jun 2010 | B2 |
| 7742074 | Minatogawa | Jun 2010 | B2 |
| 7752617 | Blinick et al. | Jul 2010 | B2 |
| 7757101 | Nonaka et al. | Jul 2010 | B2 |
| 7783891 | Perlin et al. | Aug 2010 | B2 |
| 7809942 | Baran et al. | Oct 2010 | B2 |
| 7860507 | Kalika et al. | Dec 2010 | B2 |
| 7865440 | Jaquette | Jan 2011 | B2 |
| 7870599 | Pemmaraju | Jan 2011 | B2 |
| 7925592 | Issa et al. | Apr 2011 | B1 |
| 7930558 | Hori | Apr 2011 | B2 |
| 7930715 | Hendricks et al. | Apr 2011 | B2 |
| 7954131 | Cholas et al. | May 2011 | B2 |
| 7983418 | Oyama et al. | Jul 2011 | B2 |
| 8041785 | Mazur et al. | Oct 2011 | B2 |
| 8084792 | Lehmann et al. | Dec 2011 | B2 |
| 8166508 | Mitsuji et al. | Apr 2012 | B2 |
| 8181262 | Cooper et al. | May 2012 | B2 |
| 8234387 | Bradley et al. | Jul 2012 | B2 |
| 8280982 | La et al. | Oct 2012 | B2 |
| 8306634 | Nguyen et al. | Nov 2012 | B2 |
| 8332370 | Gattegno et al. | Dec 2012 | B2 |
| 8341242 | Dillon et al. | Dec 2012 | B2 |
| 8442265 | Bosworth et al. | May 2013 | B1 |
| 8583484 | Chalawsky et al. | Nov 2013 | B1 |
| 8713623 | Brooks | Apr 2014 | B2 |
| 8842615 | Kalbag et al. | Sep 2014 | B1 |
| 8862155 | Stern et al. | Oct 2014 | B2 |
| 8866911 | Sivertsen | Oct 2014 | B1 |
| 8898270 | Stack et al. | Nov 2014 | B1 |
| 9003436 | Tidwell et al. | Apr 2015 | B2 |
| 9027062 | Patel et al. | May 2015 | B2 |
| 9071859 | Lajoie | Jun 2015 | B2 |
| 9115997 | Poduri et al. | Aug 2015 | B2 |
| 9215423 | Kimble et al. | Dec 2015 | B2 |
| 9264861 | Arastafar et al. | Feb 2016 | B1 |
| 9300919 | Cholas et al. | Mar 2016 | B2 |
| 9609617 | Arslan et al. | Mar 2017 | B2 |
| 9648466 | Aström et al. | May 2017 | B2 |
| 9906838 | Cronk et al. | Feb 2018 | B2 |
| 9918345 | Gunasekara et al. | Mar 2018 | B2 |
| 9935833 | McAllister | Apr 2018 | B2 |
| 9986578 | Gunasekara | May 2018 | B2 |
| 10164858 | Gunasekara et al. | Dec 2018 | B2 |
| 10327187 | Yeddala et al. | Jun 2019 | B2 |
| 10368255 | Gunasekara et al. | Jul 2019 | B2 |
| 10560772 | Gunasekara | Feb 2020 | B2 |
| 10638361 | Gunasekara et al. | Apr 2020 | B2 |
| 10952118 | Yeddala et al. | Mar 2021 | B2 |
| 20010004768 | Hodge et al. | Jun 2001 | A1 |
| 20010014946 | Ichinoi et al. | Aug 2001 | A1 |
| 20010019614 | Madoukh et al. | Sep 2001 | A1 |
| 20010029581 | Knauft | Oct 2001 | A1 |
| 20010030785 | Pangrac et al. | Oct 2001 | A1 |
| 20010053223 | Ishibashi et al. | Dec 2001 | A1 |
| 20010053226 | Akins et al. | Dec 2001 | A1 |
| 20010056541 | Matsuzaki et al. | Dec 2001 | A1 |
| 20020013772 | Peinado | Jan 2002 | A1 |
| 20020026575 | Wheeler et al. | Feb 2002 | A1 |
| 20020027883 | Belaiche | Mar 2002 | A1 |
| 20020032754 | Logston et al. | Mar 2002 | A1 |
| 20020049902 | Rhodes | Apr 2002 | A1 |
| 20020054589 | Ethridge et al. | May 2002 | A1 |
| 20020055978 | Joon-Bo et al. | May 2002 | A1 |
| 20020056125 | Hodge et al. | May 2002 | A1 |
| 20020059619 | Lebar | May 2002 | A1 |
| 20020062440 | Akama | May 2002 | A1 |
| 20020063621 | Tseng et al. | May 2002 | A1 |
| 20020066033 | Dobbins et al. | May 2002 | A1 |
| 20020077984 | Ireton | Jun 2002 | A1 |
| 20020087976 | Kaplan et al. | Jul 2002 | A1 |
| 20020123928 | Eldering et al. | Sep 2002 | A1 |
| 20020126654 | Preston et al. | Sep 2002 | A1 |
| 20020129358 | Buehl et al. | Sep 2002 | A1 |
| 20020129378 | Cloonan et al. | Sep 2002 | A1 |
| 20020147771 | Traversat et al. | Oct 2002 | A1 |
| 20020152299 | Traversat et al. | Oct 2002 | A1 |
| 20020152393 | Thoma et al. | Oct 2002 | A1 |
| 20020183985 | Hori et al. | Dec 2002 | A1 |
| 20020188744 | Mani | Dec 2002 | A1 |
| 20020188869 | Patrick | Dec 2002 | A1 |
| 20020199105 | Ishiguro et al. | Dec 2002 | A1 |
| 20030002862 | Rodriguez et al. | Jan 2003 | A1 |
| 20030003909 | Keronen | Jan 2003 | A1 |
| 20030005453 | Rodriguez et al. | Jan 2003 | A1 |
| 20030007516 | Abramov et al. | Jan 2003 | A1 |
| 20030009681 | Harada et al. | Jan 2003 | A1 |
| 20030021421 | Yokota et al. | Jan 2003 | A1 |
| 20030041336 | Del et al. | Feb 2003 | A1 |
| 20030046560 | Inomata et al. | Mar 2003 | A1 |
| 20030046704 | Laksono et al. | Mar 2003 | A1 |
| 20030048380 | Tamura | Mar 2003 | A1 |
| 20030056217 | Brooks | Mar 2003 | A1 |
| 20030061619 | Giammaressi | Mar 2003 | A1 |
| 20030069965 | Ma et al. | Apr 2003 | A1 |
| 20030071117 | Meade | Apr 2003 | A1 |
| 20030074571 | Fujiwara et al. | Apr 2003 | A1 |
| 20030084003 | Pinkas et al. | May 2003 | A1 |
| 20030097340 | Okamoto et al. | May 2003 | A1 |
| 20030099212 | Anjum et al. | May 2003 | A1 |
| 20030114162 | Chheda et al. | Jun 2003 | A1 |
| 20030115267 | Hinton et al. | Jun 2003 | A1 |
| 20030139980 | Hamilton | Jul 2003 | A1 |
| 20030140227 | Asano et al. | Jul 2003 | A1 |
| 20030163697 | Pabla et al. | Aug 2003 | A1 |
| 20030163739 | Armington et al. | Aug 2003 | A1 |
| 20030165241 | Fransdonk | Sep 2003 | A1 |
| 20030166401 | Combes et al. | Sep 2003 | A1 |
| 20030174838 | Bremer | Sep 2003 | A1 |
| 20030179773 | Mocek et al. | Sep 2003 | A1 |
| 20030187799 | Sellars et al. | Oct 2003 | A1 |
| 20030205763 | Park et al. | Nov 2003 | A1 |
| 20030208763 | McElhatten et al. | Nov 2003 | A1 |
| 20030208767 | Williamson et al. | Nov 2003 | A1 |
| 20030210710 | Odman | Nov 2003 | A1 |
| 20030217137 | Roese et al. | Nov 2003 | A1 |
| 20030217365 | Caputo | Nov 2003 | A1 |
| 20040019691 | Daymond et al. | Jan 2004 | A1 |
| 20040024688 | Bi et al. | Feb 2004 | A1 |
| 20040034877 | Nogues | Feb 2004 | A1 |
| 20040045032 | Cummings et al. | Mar 2004 | A1 |
| 20040045035 | Cummings et al. | Mar 2004 | A1 |
| 20040045037 | Cummings et al. | Mar 2004 | A1 |
| 20040078602 | Rothbarth et al. | Apr 2004 | A1 |
| 20040088558 | Candelore | May 2004 | A1 |
| 20040106403 | Mori et al. | Jun 2004 | A1 |
| 20040109569 | Ellison et al. | Jun 2004 | A1 |
| 20040117836 | Karaoguz et al. | Jun 2004 | A1 |
| 20040123129 | Ginter et al. | Jun 2004 | A1 |
| 20040128499 | Peterka et al. | Jul 2004 | A1 |
| 20040133907 | Rodriguez et al. | Jul 2004 | A1 |
| 20040133923 | Watson et al. | Jul 2004 | A1 |
| 20040137918 | Varonen et al. | Jul 2004 | A1 |
| 20040146006 | Jackson | Jul 2004 | A1 |
| 20040181800 | Rakib et al. | Sep 2004 | A1 |
| 20040187159 | Gaydos et al. | Sep 2004 | A1 |
| 20040193609 | Phan et al. | Sep 2004 | A1 |
| 20040193680 | Gibbs et al. | Sep 2004 | A1 |
| 20040224425 | Gjerde et al. | Nov 2004 | A1 |
| 20040240478 | Goren et al. | Dec 2004 | A1 |
| 20040250273 | Swix et al. | Dec 2004 | A1 |
| 20040260798 | Addington et al. | Dec 2004 | A1 |
| 20040261093 | Rebaud et al. | Dec 2004 | A1 |
| 20040268386 | Logan et al. | Dec 2004 | A1 |
| 20050005287 | Claussen | Jan 2005 | A1 |
| 20050007278 | Anson et al. | Jan 2005 | A1 |
| 20050015810 | Gould et al. | Jan 2005 | A1 |
| 20050021985 | Ono et al. | Jan 2005 | A1 |
| 20050022227 | Shen et al. | Jan 2005 | A1 |
| 20050034171 | Benya | Feb 2005 | A1 |
| 20050039205 | Riedl | Feb 2005 | A1 |
| 20050039212 | Baran et al. | Feb 2005 | A1 |
| 20050049886 | Grannan et al. | Mar 2005 | A1 |
| 20050055220 | Lee et al. | Mar 2005 | A1 |
| 20050058112 | Lahey et al. | Mar 2005 | A1 |
| 20050060742 | Riedl et al. | Mar 2005 | A1 |
| 20050060745 | Riedl et al. | Mar 2005 | A1 |
| 20050065888 | Benaloh | Mar 2005 | A1 |
| 20050086683 | Meyerson | Apr 2005 | A1 |
| 20050086691 | Dudkiewicz et al. | Apr 2005 | A1 |
| 20050091173 | Alve | Apr 2005 | A1 |
| 20050097006 | Nyako | May 2005 | A1 |
| 20050108763 | Baran et al. | May 2005 | A1 |
| 20050111844 | Compton et al. | May 2005 | A1 |
| 20050114686 | Ball et al. | May 2005 | A1 |
| 20050114900 | Ladd et al. | May 2005 | A1 |
| 20050125832 | Jost et al. | Jun 2005 | A1 |
| 20050138357 | Swenson et al. | Jun 2005 | A1 |
| 20050168323 | Lenoir et al. | Aug 2005 | A1 |
| 20050169468 | Fahrny et al. | Aug 2005 | A1 |
| 20050172127 | Hartung et al. | Aug 2005 | A1 |
| 20050176444 | Tanaka | Aug 2005 | A1 |
| 20050177740 | Athaide et al. | Aug 2005 | A1 |
| 20050177741 | Chen et al. | Aug 2005 | A1 |
| 20050177855 | Maynard et al. | Aug 2005 | A1 |
| 20050182931 | Robert et al. | Aug 2005 | A1 |
| 20050188210 | Perlin et al. | Aug 2005 | A1 |
| 20050190912 | Hopkins et al. | Sep 2005 | A1 |
| 20050195975 | Kawakita | Sep 2005 | A1 |
| 20050198693 | Choi et al. | Sep 2005 | A1 |
| 20050268107 | Harris et al. | Dec 2005 | A1 |
| 20050271133 | Waxman et al. | Dec 2005 | A1 |
| 20050273629 | Abrams et al. | Dec 2005 | A1 |
| 20050278259 | Gunaseelan et al. | Dec 2005 | A1 |
| 20050289618 | Hardin | Dec 2005 | A1 |
| 20050289619 | Melby | Dec 2005 | A1 |
| 20060002551 | Brown et al. | Jan 2006 | A1 |
| 20060004662 | Nadalin et al. | Jan 2006 | A1 |
| 20060008256 | Khedouri et al. | Jan 2006 | A1 |
| 20060020786 | Helms et al. | Jan 2006 | A1 |
| 20060020950 | Ladd et al. | Jan 2006 | A1 |
| 20060021004 | Moran et al. | Jan 2006 | A1 |
| 20060036750 | Ladd et al. | Feb 2006 | A1 |
| 20060041903 | Kahn et al. | Feb 2006 | A1 |
| 20060047801 | Haag et al. | Mar 2006 | A1 |
| 20060047957 | Helms et al. | Mar 2006 | A1 |
| 20060064583 | Birnbaum et al. | Mar 2006 | A1 |
| 20060095940 | Yearwood | May 2006 | A1 |
| 20060130099 | Rooyen | Jun 2006 | A1 |
| 20060130107 | Gonder et al. | Jun 2006 | A1 |
| 20060130113 | Carlucci et al. | Jun 2006 | A1 |
| 20060136964 | Diez et al. | Jun 2006 | A1 |
| 20060137005 | Park | Jun 2006 | A1 |
| 20060137015 | Fahrny et al. | Jun 2006 | A1 |
| 20060148362 | Bridges | Jul 2006 | A1 |
| 20060149850 | Bowman | Jul 2006 | A1 |
| 20060154674 | Landschaft et al. | Jul 2006 | A1 |
| 20060161635 | Lamkin et al. | Jul 2006 | A1 |
| 20060165090 | Kalliola et al. | Jul 2006 | A1 |
| 20060165197 | Morita et al. | Jul 2006 | A1 |
| 20060168219 | Ahluwalia et al. | Jul 2006 | A1 |
| 20060171390 | La | Aug 2006 | A1 |
| 20060171423 | Helms et al. | Aug 2006 | A1 |
| 20060179138 | Van et al. | Aug 2006 | A1 |
| 20060184972 | Rafey et al. | Aug 2006 | A1 |
| 20060187900 | Akbar | Aug 2006 | A1 |
| 20060200856 | Salowey et al. | Sep 2006 | A1 |
| 20060206712 | Dillaway et al. | Sep 2006 | A1 |
| 20060209799 | Gallagher et al. | Sep 2006 | A1 |
| 20060212400 | Kamperman et al. | Sep 2006 | A1 |
| 20060218604 | Riedl et al. | Sep 2006 | A1 |
| 20060218632 | Corley et al. | Sep 2006 | A1 |
| 20060236131 | Vauclair | Oct 2006 | A1 |
| 20060248553 | Mikkelson et al. | Nov 2006 | A1 |
| 20060248555 | Eldering | Nov 2006 | A1 |
| 20060253328 | Kohli et al. | Nov 2006 | A1 |
| 20060253864 | Easty | Nov 2006 | A1 |
| 20060259927 | Acharya et al. | Nov 2006 | A1 |
| 20060277569 | Smith | Dec 2006 | A1 |
| 20060291506 | Cain | Dec 2006 | A1 |
| 20070011335 | Burns et al. | Jan 2007 | A1 |
| 20070019645 | Menon | Jan 2007 | A1 |
| 20070022459 | Gaebel, Jr. et al. | Jan 2007 | A1 |
| 20070022469 | Cooper et al. | Jan 2007 | A1 |
| 20070033531 | Marsh | Feb 2007 | A1 |
| 20070046791 | Wang et al. | Mar 2007 | A1 |
| 20070049245 | Lipman | Mar 2007 | A1 |
| 20070067851 | Fernando et al. | Mar 2007 | A1 |
| 20070076728 | Rieger et al. | Apr 2007 | A1 |
| 20070079381 | Hartung et al. | Apr 2007 | A1 |
| 20070086383 | Watanabe et al. | Apr 2007 | A1 |
| 20070089127 | Flickinger et al. | Apr 2007 | A1 |
| 20070094691 | Gazdzinski | Apr 2007 | A1 |
| 20070098178 | Raikar | May 2007 | A1 |
| 20070113243 | Brey | May 2007 | A1 |
| 20070115900 | Liang et al. | May 2007 | A1 |
| 20070121678 | Brooks et al. | May 2007 | A1 |
| 20070124488 | Baum et al. | May 2007 | A1 |
| 20070157295 | Mangalore et al. | Jul 2007 | A1 |
| 20070174888 | Rubinstein | Jul 2007 | A1 |
| 20070192615 | Varghese et al. | Aug 2007 | A1 |
| 20070195727 | Kinder et al. | Aug 2007 | A1 |
| 20070204314 | Hasek et al. | Aug 2007 | A1 |
| 20070206799 | Wingert et al. | Sep 2007 | A1 |
| 20070209059 | Moore et al. | Sep 2007 | A1 |
| 20070217436 | Markley et al. | Sep 2007 | A1 |
| 20070219910 | Martinez | Sep 2007 | A1 |
| 20070220024 | Putterman et al. | Sep 2007 | A1 |
| 20070233857 | Cheng et al. | Oct 2007 | A1 |
| 20070237077 | Patwardhan et al. | Oct 2007 | A1 |
| 20070250872 | Dua | Oct 2007 | A1 |
| 20070250880 | Hainline | Oct 2007 | A1 |
| 20070261116 | Prafullchandra et al. | Nov 2007 | A1 |
| 20070263818 | Sumioka et al. | Nov 2007 | A1 |
| 20070266395 | Lee et al. | Nov 2007 | A1 |
| 20070276925 | La et al. | Nov 2007 | A1 |
| 20070276926 | Lajoie et al. | Nov 2007 | A1 |
| 20070294178 | Pinder et al. | Dec 2007 | A1 |
| 20080008321 | Gagnon et al. | Jan 2008 | A1 |
| 20080008371 | Woods et al. | Jan 2008 | A1 |
| 20080021836 | Lao | Jan 2008 | A1 |
| 20080022012 | Wang | Jan 2008 | A1 |
| 20080037493 | Morton | Feb 2008 | A1 |
| 20080046542 | Sano et al. | Feb 2008 | A1 |
| 20080059804 | Shah et al. | Mar 2008 | A1 |
| 20080066112 | Bailey et al. | Mar 2008 | A1 |
| 20080091805 | Malaby et al. | Apr 2008 | A1 |
| 20080091807 | Strub et al. | Apr 2008 | A1 |
| 20080098212 | Helms et al. | Apr 2008 | A1 |
| 20080101460 | Rodriguez | May 2008 | A1 |
| 20080103976 | Read et al. | May 2008 | A1 |
| 20080103977 | Khosravy et al. | May 2008 | A1 |
| 20080104634 | Gajdos et al. | May 2008 | A1 |
| 20080109307 | Ullah | May 2008 | A1 |
| 20080112405 | Cholas et al. | May 2008 | A1 |
| 20080117920 | Tucker | May 2008 | A1 |
| 20080123862 | Rowley | May 2008 | A1 |
| 20080133551 | Wensley et al. | Jun 2008 | A1 |
| 20080134274 | Derrenberger et al. | Jun 2008 | A1 |
| 20080141317 | Radloff et al. | Jun 2008 | A1 |
| 20080141353 | Brown | Jun 2008 | A1 |
| 20080148362 | Gilder et al. | Jun 2008 | A1 |
| 20080155059 | Hardin et al. | Jun 2008 | A1 |
| 20080155614 | Cooper et al. | Jun 2008 | A1 |
| 20080162353 | Tom et al. | Jul 2008 | A1 |
| 20080165460 | Whitby-Strevens | Jul 2008 | A1 |
| 20080177998 | Apsangi et al. | Jul 2008 | A1 |
| 20080182591 | Krikorian | Jul 2008 | A1 |
| 20080183705 | Shivaji-Rao et al. | Jul 2008 | A1 |
| 20080188253 | Chong et al. | Aug 2008 | A1 |
| 20080192820 | Brooks et al. | Aug 2008 | A1 |
| 20080212945 | Khedouri et al. | Sep 2008 | A1 |
| 20080222684 | Mukraj et al. | Sep 2008 | A1 |
| 20080229354 | Morris et al. | Sep 2008 | A1 |
| 20080235746 | Peters et al. | Sep 2008 | A1 |
| 20080244667 | Osborne | Oct 2008 | A1 |
| 20080256510 | Auerbach | Oct 2008 | A1 |
| 20080270307 | Olson et al. | Oct 2008 | A1 |
| 20080273591 | Brooks et al. | Nov 2008 | A1 |
| 20080281979 | Keeler | Nov 2008 | A1 |
| 20080282299 | Koat et al. | Nov 2008 | A1 |
| 20080288618 | Vardi et al. | Nov 2008 | A1 |
| 20090007234 | Birger et al. | Jan 2009 | A1 |
| 20090013210 | McIntosh et al. | Jan 2009 | A1 |
| 20090025027 | Craner | Jan 2009 | A1 |
| 20090025075 | Chow et al. | Jan 2009 | A1 |
| 20090028182 | Brooks et al. | Jan 2009 | A1 |
| 20090031371 | Munsell et al. | Jan 2009 | A1 |
| 20090064251 | Savoor et al. | Mar 2009 | A1 |
| 20090077620 | Ravi et al. | Mar 2009 | A1 |
| 20090083813 | Dolce et al. | Mar 2009 | A1 |
| 20090094648 | Patel et al. | Apr 2009 | A1 |
| 20090098861 | Kalliola et al. | Apr 2009 | A1 |
| 20090100459 | Riedl et al. | Apr 2009 | A1 |
| 20090102983 | Malone et al. | Apr 2009 | A1 |
| 20090116587 | Kwasinski et al. | May 2009 | A1 |
| 20090119751 | Koga | May 2009 | A1 |
| 20090125374 | Deaton et al. | May 2009 | A1 |
| 20090151006 | Saeki et al. | Jun 2009 | A1 |
| 20090170479 | Jarenskog | Jul 2009 | A1 |
| 20090182815 | Czechowski, III et al. | Jul 2009 | A1 |
| 20090185576 | Kisel et al. | Jul 2009 | A1 |
| 20090187939 | Lajoie | Jul 2009 | A1 |
| 20090201917 | Maes et al. | Aug 2009 | A1 |
| 20090210899 | Lawrence-Apfelbaum et al. | Aug 2009 | A1 |
| 20090210912 | Cholas et al. | Aug 2009 | A1 |
| 20090225760 | Foti | Sep 2009 | A1 |
| 20090244290 | McKelvey et al. | Oct 2009 | A1 |
| 20090265750 | Jones et al. | Oct 2009 | A1 |
| 20090282241 | Prafullchandra et al. | Nov 2009 | A1 |
| 20090282449 | Lee | Nov 2009 | A1 |
| 20090292922 | Park | Nov 2009 | A1 |
| 20090293101 | Carter et al. | Nov 2009 | A1 |
| 20100014496 | Kalika et al. | Jan 2010 | A1 |
| 20100020683 | Gummalla et al. | Jan 2010 | A1 |
| 20100030578 | Siddique et al. | Feb 2010 | A1 |
| 20100031299 | Harrang et al. | Feb 2010 | A1 |
| 20100042478 | Reisman | Feb 2010 | A1 |
| 20100070867 | Lemmers | Mar 2010 | A1 |
| 20100081416 | Cohen | Apr 2010 | A1 |
| 20100082983 | Shah et al. | Apr 2010 | A1 |
| 20100083329 | Joyce et al. | Apr 2010 | A1 |
| 20100088236 | Karabulut et al. | Apr 2010 | A1 |
| 20100088292 | Tirpak et al. | Apr 2010 | A1 |
| 20100106846 | Noldus et al. | Apr 2010 | A1 |
| 20100122288 | Minter et al. | May 2010 | A1 |
| 20100131973 | Dillon et al. | May 2010 | A1 |
| 20100138900 | Peterka et al. | Jun 2010 | A1 |
| 20100144340 | Sudak | Jun 2010 | A1 |
| 20100150027 | Atwal et al. | Jun 2010 | A1 |
| 20100151816 | Besehanic et al. | Jun 2010 | A1 |
| 20100159951 | Shkedi | Jun 2010 | A1 |
| 20100167743 | Palanki et al. | Jul 2010 | A1 |
| 20100169977 | Dasher et al. | Jul 2010 | A1 |
| 20100185855 | Margolus et al. | Jul 2010 | A1 |
| 20100198888 | Blomstedt et al. | Aug 2010 | A1 |
| 20100217837 | Ansari et al. | Aug 2010 | A1 |
| 20100232355 | Richeson et al. | Sep 2010 | A1 |
| 20100251305 | Kimble et al. | Sep 2010 | A1 |
| 20100287609 | Gonzalez et al. | Nov 2010 | A1 |
| 20100309051 | Moshfeghi | Dec 2010 | A1 |
| 20100312826 | Sarosi et al. | Dec 2010 | A1 |
| 20100313225 | Cholas et al. | Dec 2010 | A1 |
| 20100313226 | Cholas et al. | Dec 2010 | A1 |
| 20110015989 | Tidwell et al. | Jan 2011 | A1 |
| 20110034179 | David et al. | Feb 2011 | A1 |
| 20110071841 | Fomenko et al. | Mar 2011 | A1 |
| 20110078721 | Wang et al. | Mar 2011 | A1 |
| 20110093900 | Patel et al. | Apr 2011 | A1 |
| 20110098076 | Kim et al. | Apr 2011 | A1 |
| 20110103374 | Lajoie | May 2011 | A1 |
| 20110107389 | Chakarapani | May 2011 | A1 |
| 20110112717 | Resner | May 2011 | A1 |
| 20110116428 | Seong et al. | May 2011 | A1 |
| 20110138064 | Rieger et al. | Jun 2011 | A1 |
| 20110158095 | Alexander et al. | Jun 2011 | A1 |
| 20110163888 | Goedde | Jul 2011 | A1 |
| 20110164753 | Dubhashi et al. | Jul 2011 | A1 |
| 20110167440 | Greenfield | Jul 2011 | A1 |
| 20110169977 | Masuda | Jul 2011 | A1 |
| 20110179184 | Breau et al. | Jul 2011 | A1 |
| 20110182250 | Shin | Jul 2011 | A1 |
| 20110197070 | Mizrah | Aug 2011 | A1 |
| 20110206136 | Bekedam et al. | Aug 2011 | A1 |
| 20110213688 | Santos et al. | Sep 2011 | A1 |
| 20110219229 | Cholas et al. | Sep 2011 | A1 |
| 20110225619 | Kesireddy et al. | Sep 2011 | A1 |
| 20110235577 | Hintermeister et al. | Sep 2011 | A1 |
| 20110247029 | Yarvis et al. | Oct 2011 | A1 |
| 20110252236 | De et al. | Oct 2011 | A1 |
| 20110252243 | Brouwer et al. | Oct 2011 | A1 |
| 20110285542 | Amsterdam | Nov 2011 | A1 |
| 20110286437 | Austin et al. | Nov 2011 | A1 |
| 20110299411 | Chen et al. | Dec 2011 | A1 |
| 20110299422 | Kim et al. | Dec 2011 | A1 |
| 20120008786 | Cronk et al. | Jan 2012 | A1 |
| 20120011567 | Cronk et al. | Jan 2012 | A1 |
| 20120023535 | Brooks | Jan 2012 | A1 |
| 20120030716 | Zhang et al. | Feb 2012 | A1 |
| 20120046049 | Curtis et al. | Feb 2012 | A1 |
| 20120054785 | Yang et al. | Mar 2012 | A1 |
| 20120079531 | Hasek et al. | Mar 2012 | A1 |
| 20120079546 | Kalidindi et al. | Mar 2012 | A1 |
| 20120115501 | Zheng | May 2012 | A1 |
| 20120151549 | Kumar et al. | Jun 2012 | A1 |
| 20120159603 | Queck | Jun 2012 | A1 |
| 20120167173 | Nadalin et al. | Jun 2012 | A1 |
| 20120202447 | Edge et al. | Aug 2012 | A1 |
| 20120203822 | Floyd et al. | Aug 2012 | A1 |
| 20120222081 | Schaefer et al. | Aug 2012 | A1 |
| 20120230193 | Fang | Sep 2012 | A1 |
| 20120278654 | Shen et al. | Nov 2012 | A1 |
| 20120291062 | Pearson et al. | Nov 2012 | A1 |
| 20120302259 | Busch | Nov 2012 | A1 |
| 20120330759 | Aggarwal et al. | Dec 2012 | A1 |
| 20130016648 | Koskela et al. | Jan 2013 | A1 |
| 20130017794 | Kloper et al. | Jan 2013 | A1 |
| 20130045681 | Dua | Feb 2013 | A1 |
| 20130046623 | Moritz et al. | Feb 2013 | A1 |
| 20130081097 | Park et al. | Mar 2013 | A1 |
| 20130095848 | Gold et al. | Apr 2013 | A1 |
| 20130100818 | Qiu et al. | Apr 2013 | A1 |
| 20130132789 | Watford et al. | May 2013 | A1 |
| 20130145152 | Maino et al. | Jun 2013 | A1 |
| 20130176885 | Lee et al. | Jul 2013 | A1 |
| 20130235774 | Jo et al. | Sep 2013 | A1 |
| 20130242812 | Khoryaev et al. | Sep 2013 | A1 |
| 20130254787 | Cox et al. | Sep 2013 | A1 |
| 20130260820 | Schmandt et al. | Oct 2013 | A1 |
| 20130308622 | Uhlik | Nov 2013 | A1 |
| 20130317892 | Heerboth | Nov 2013 | A1 |
| 20130322415 | Chamarti | Dec 2013 | A1 |
| 20130342710 | Kanma | Dec 2013 | A1 |
| 20130347089 | Bailey et al. | Dec 2013 | A1 |
| 20140010219 | Dor et al. | Jan 2014 | A1 |
| 20140010225 | Puregger | Jan 2014 | A1 |
| 20140019635 | Reznik et al. | Jan 2014 | A1 |
| 20140046624 | Miettinen | Feb 2014 | A1 |
| 20140056209 | Park | Feb 2014 | A1 |
| 20140066098 | Stern et al. | Mar 2014 | A1 |
| 20140105061 | Kannan | Apr 2014 | A1 |
| 20140106779 | Arslan et al. | Apr 2014 | A1 |
| 20140177611 | Corrales | Jun 2014 | A1 |
| 20140213256 | Meylan et al. | Jul 2014 | A1 |
| 20140215506 | Kalmes et al. | Jul 2014 | A1 |
| 20140242991 | Yanover et al. | Aug 2014 | A1 |
| 20140274110 | Mehta et al. | Sep 2014 | A1 |
| 20140280901 | Balachandran et al. | Sep 2014 | A1 |
| 20140281489 | Peterka et al. | Sep 2014 | A1 |
| 20140282721 | Kuncl et al. | Sep 2014 | A1 |
| 20140283137 | Rebaud et al. | Sep 2014 | A1 |
| 20140287778 | Jones | Sep 2014 | A1 |
| 20140288980 | Lee et al. | Sep 2014 | A1 |
| 20140308923 | Faulkner et al. | Oct 2014 | A1 |
| 20140309868 | Ricci | Oct 2014 | A1 |
| 20140328257 | Kamlani | Nov 2014 | A1 |
| 20140359649 | Cronk et al. | Dec 2014 | A1 |
| 20150009869 | Clegg | Jan 2015 | A1 |
| 20150036514 | Zhu et al. | Feb 2015 | A1 |
| 20150058883 | Tidwell et al. | Feb 2015 | A1 |
| 20150058909 | Miller et al. | Feb 2015 | A1 |
| 20150094098 | Stern et al. | Apr 2015 | A1 |
| 20150103685 | Butchko et al. | Apr 2015 | A1 |
| 20150106501 | Malets et al. | Apr 2015 | A1 |
| 20150106846 | Chen et al. | Apr 2015 | A1 |
| 20150140981 | Balasaygun | May 2015 | A1 |
| 20150146537 | Panaitopol et al. | May 2015 | A1 |
| 20150156129 | Tsuruoka | Jun 2015 | A1 |
| 20150189377 | Wheatley et al. | Jul 2015 | A1 |
| 20150215367 | Hayes et al. | Jul 2015 | A1 |
| 20150288617 | Dasher et al. | Oct 2015 | A1 |
| 20150288732 | Phillips et al. | Oct 2015 | A1 |
| 20150305082 | Elliott et al. | Oct 2015 | A1 |
| 20150334625 | Banks | Nov 2015 | A1 |
| 20150350820 | Son | Dec 2015 | A1 |
| 20150365833 | Stafford et al. | Dec 2015 | A1 |
| 20160019103 | Basra | Jan 2016 | A1 |
| 20160057794 | Morita | Feb 2016 | A1 |
| 20160066234 | Cho et al. | Mar 2016 | A1 |
| 20160066313 | Sun | Mar 2016 | A1 |
| 20160105691 | Zucchetta | Apr 2016 | A1 |
| 20160119939 | Himayat et al. | Apr 2016 | A1 |
| 20160127185 | McAllister et al. | May 2016 | A1 |
| 20160143005 | Ghosh et al. | May 2016 | A1 |
| 20160204934 | Smith | Jul 2016 | A1 |
| 20160242071 | Chen et al. | Aug 2016 | A1 |
| 20160261596 | Khello et al. | Sep 2016 | A1 |
| 20160261986 | Nord et al. | Sep 2016 | A1 |
| 20160301525 | Canard et al. | Oct 2016 | A1 |
| 20160315672 | Patwardhan et al. | Oct 2016 | A1 |
| 20170099327 | Negalaguli et al. | Apr 2017 | A1 |
| 20170164378 | Gunasekara et al. | Jun 2017 | A1 |
| 20170164416 | Yeddala et al. | Jun 2017 | A1 |
| 20170208632 | Gunasekara et al. | Jul 2017 | A1 |
| 20170223536 | Gupta et al. | Aug 2017 | A1 |
| 20170257750 | Gunasekara et al. | Sep 2017 | A1 |
| 20170265084 | Clegg | Sep 2017 | A1 |
| 20170366983 | Gunasekara et al. | Dec 2017 | A1 |
| 20180132060 | Dhulipalla et al. | May 2018 | A1 |
| 20180279391 | Gunasekara et al. | Sep 2018 | A1 |
| 20190149443 | Gunasekara et al. | May 2019 | A1 |
| 20190373301 | Gunasekara et al. | Dec 2019 | A1 |
| 20200252712 | Gunasekara | Aug 2020 | A1 |
| 20200329398 | Gunasekara et al. | Oct 2020 | A1 |
| 20210227440 | Yeddala et al. | Jul 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 3066622 | Dec 2018 | CA |
| 1139198 | Oct 2001 | EP |
| 2113860 | Nov 2009 | EP |
| 3635990 | Apr 2020 | EP |
| 2381709 | May 2003 | GB |
| H08263440 | Oct 1996 | JP |
| 2000156676 | Jun 2000 | JP |
| 2000332746 | Nov 2000 | JP |
| 2001243707 | Sep 2001 | JP |
| 2001274786 | Oct 2001 | JP |
| 2001274788 | Oct 2001 | JP |
| 2001285821 | Oct 2001 | JP |
| 2002163396 | Jun 2002 | JP |
| 2002352094 | Dec 2002 | JP |
| 2003058657 | Feb 2003 | JP |
| 2003162600 | Jun 2003 | JP |
| 2003233690 | Aug 2003 | JP |
| 2003248508 | Sep 2003 | JP |
| 2003296484 | Oct 2003 | JP |
| 2003348508 | Dec 2003 | JP |
| 2004030111 | Jan 2004 | JP |
| 2004072721 | Mar 2004 | JP |
| 2004120736 | Apr 2004 | JP |
| 2004120738 | Apr 2004 | JP |
| 2004303111 | Oct 2004 | JP |
| 2005506627 | Mar 2005 | JP |
| 2005519365 | Jun 2005 | JP |
| 2005519501 | Jun 2005 | JP |
| 2005339093 | Dec 2005 | JP |
| 2006185473 | Jul 2006 | JP |
| 2006311267 | Nov 2006 | JP |
| 2007020144 | Jan 2007 | JP |
| 2008005047 | Jan 2008 | JP |
| 2008015936 | Jan 2008 | JP |
| 2008021293 | Jan 2008 | JP |
| 2008507905 | Mar 2008 | JP |
| 2008167018 | Jul 2008 | JP |
| 2008186272 | Aug 2008 | JP |
| 2008206039 | Sep 2008 | JP |
| 2009071786 | Apr 2009 | JP |
| 2009515238 | Apr 2009 | JP |
| 2009176060 | Aug 2009 | JP |
| 2009211632 | Sep 2009 | JP |
| 2010502109 | Jan 2010 | JP |
| 2010079902 | Apr 2010 | JP |
| 2012505436 | Mar 2012 | JP |
| 2012523614 | Oct 2012 | JP |
| WO-0103410 | Jan 2001 | WO |
| WO-0110125 | Feb 2001 | WO |
| WO-0137479 | May 2001 | WO |
| WO-0169842 | Sep 2001 | WO |
| WO-0177778 | Oct 2001 | WO |
| WO-0213032 | Feb 2002 | WO |
| WO-0221841 | Mar 2002 | WO |
| WO-0242966 | May 2002 | WO |
| WO-02080556 | Oct 2002 | WO |
| WO-03038704 | May 2003 | WO |
| WO-03087799 | Oct 2003 | WO |
| WO-03093944 | Nov 2003 | WO |
| WO-2004027622 | Apr 2004 | WO |
| WO-2005015422 | Feb 2005 | WO |
| WO-2006020141 | Feb 2006 | WO |
| WO-2008080556 | Jul 2008 | WO |
| WO-2009020476 | Feb 2009 | WO |
| WO-2012021245 | Feb 2012 | WO |
| WO-2018226486 | Dec 2018 | WO |
| Entry |
|---|
| 5C Digital Transmission Content Protection White Paper, Hitachi, Ltd., et al., dated Jul. 14, 1998, 15 pages. |
| Cantor, et al., Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, Mar. 15, 2005. Document ID: saml-core-2.0-os (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). |
| Cantor, et al., Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, Mar. 2005, Document ID saml-bindings-2.0-os ,(http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf). |
| Cisco Intelligent Network Architecture for Digital Video—SCTE Cable-Tec Expo 2004 information page, Orange County Convention Center, Jun. 2004, 24 pages. |
| DCAS Authorized< gwmw class=“ginger-module-highlighter-mistake-type-3” id=“gwmw-15487095474138963691403”>Service Domain</gwmw>, Version 1.2, dated Nov. 4, 2008, 58 pages. |
| DCAS Licensed Specification Abstracts, CableLabs Confidential Information, Jan. 12, 2006, 4 pages. |
| Deering et al., Internet Protocol, Version 6 (IPv6) Specification, Dec. 1998, 39 pages. |
| DVB (Digital Video Broadcasting), DVB Document A045 Rev. 3, Jul. 2004, “Head-end Implementation of SimulCrypt,” 289 pages. |
| DVB (Digital Video Broadcasting); DVB SimulCrypt; Part 1: “Head-end architecture and synchronization” Technical Specification—ETSI TS 101 197 V1.2.1 (Feb. 2002), 40 pages. |
| Federal Information Processing Standards Publication, US FIPS PUB 197, Nov. 26, 2001, “Advanced Encryption Standards (AES),” 47 pages. |
| Gomez, Conserving Transmission Power in Wireless Ad Hoc Networks, 2001, Network Protocols. |
| Griffith, et al.,Resource Planning and Bandwidth Allocation in Hybrid Fiber-Coax Residential Networks, National Institute of Standards and Technology (NIST), 10 pages, no date. |
| Gupta V., et al., “Bit-Stuffing in 802.11 Beacon Frame: Embedding Non-Standard Custom Information,” International Journal of Computer Applications, Feb. 2013, vol. 63 (2), pp. 6-12. |
| High-bandwidth Digital Content Protection System, Revision 1.091, dated Apr. 22, 2003, Digital Content< gwmw class=“ginger-module-highlighter-mistake-type-3” id=“gwmw-15487095483507149357216”>Protection LLC</gwmw> Draft, 78 pages. |
| Internet Protocol DARPA Internet Program Protocol Specification, Sep. 1981, 51 pages. |
| Kanouff, Communications Technology: Next-Generation Bandwidth Management—The Evolution of the Anything-to-Anywhere Network, 8 pages, Apr. 1, 2004. |
| Marusic, et al., “Share it!—Content Transfer in Home-to-Home Networks.” IEEE Melecon 2004, May 12-15, 2004, Dubrovnik, Croatia. |
| Media Server; 1 Device Template Version 1.01 Jun. 25, 2002. |
| Miao , et al., “Distributed interference-aware energy-efficient power optimization,” IEEE Transactions on Wireless Communications, Apr. 2011, vol. 10 (4), pp. 1323-1333. |
| Motorola DOCSIS Cable Module DCM 2000 specifications, 4 pages, copyright 2001. |
| OpenCable Application Platform Specification, OCAP 2.0 Profile, OC-SP-OCAP2.0-I01-020419, Apr. 19, 2002. |
| OpenCable Application Platform Specifications, OCAP Extensions, OC-SP-OCAP—HNEXT-I03-080418, 2005-2008. |
| OpenCable Host Device, Core Functional Requirements, OC-SP-HOST-CFR-I13-030707, Jul. 7, 2003. |
| OpenCable, HOST-POD Interface Specification, OC-SP-HOSTPOD-IF-113-030707, Jul. 7, 2003. |
| OpenCable Specification, Home Networking Protocol 2.0, OC-SP-HNP2.0-I01-08418, 2007. |
| OpenCable Specifications, Home Networking Security Specification, OC-SP-HN-SEC-D01-081027, draft (Oct. 27, 2008). |
| OpenVision Session Resource Manager—Open Standards-Based Solution Optimizes Network Resources by Dynamically Assigning Bandwidth in the Delivery of Digital Services article, 2 pages, (copyright 2006), (http://www.imake.com/hopenvision). |
| OpenVision Session Resource Manager features and information, 2 pages, no date, (http://www.imake.com/hopenvision). |
| Primergy BX300 Switch Blade user's manual, Fujitsu Corp., Sep. 30, 2002, first edition, pp. 1 to 20. |
| Real< gwmw class=“ginger-module-highlighter-mistake-type-3” id=“gwmw-15487095583627948787141”>System Media</gwmw> Commerce Suite (Technical White Paper), at http://docs.real.com/docs/drm/DRM.sub-WP1.pdf, 12 pages, Nov. 2001. |
| Van Moffaert, A., et al.< gwmw class=“ginger-module-highlighter-mistake-type-3” id=“gwmw-15487095623201874158750”>(</gwmw>“Digital Rights Management: DRM is a key enabler for the future growth of the broadband access market and the telecom/networking market in general”, Alcatel Telecommunications Review, Alcatel, Paris Cedex FR, Apr. 1, 2003, XP007005930ISSN; 8 pages. |
| Zhang, et al., “A Flexible Content Protection System for Media-On-Demand” Multimedia Software Engineering, 2002 Proceedings. Fourth International Symposium on Dec. 11-13, 2002, Piscataway, NJ, USAA, IEEE, Dec. 11, 2002, pp. 272-277, XP010632760ISBN: 978-0-7695-1857-2. |
| Number | Date | Country | |
|---|---|---|---|
| 20200162853 A1 | May 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15063314 | Mar 2016 | US |
| Child | 16692542 | US |
