text:
This document describes, inter alia, techniques for configuring or setting up a wireless device. As an example of the features described herein, a first wireless device may be used to configure a second wireless device as follows: the first wireless device may detect that the second wireless device is available and is configurable; the first wireless device may connect to the second wireless device and transmit configuration information to the second wireless device, where the configuration information includes credentials that may be used to access a wireless network (e.g., a password to access a Wi-Fi network); the first wireless device and the second wireless device may then both connect to the wireless network, using the credentials; once both devices are connected to the wireless network, the first wireless device may verify that the second wireless device has been correctly configured.
8073972 December 2011 Jansen et al.
2005/0273790 December 2005 Kearney et al.
2011/0075589 March 2011 Bradley et al.
2012/0099476 April 2012 Mahaffy et al.
2012/0163215 June 2012 Kim et al.
2012/0207056 August 2012 Ree et al.
2013/0014232 January 2013 Louboutin et al.
2014/0222688 August 2014 Haggerty et al.
Samuel Master, "Solved: Wifi connection to router disconnection during Screen Mirroring with Netgear P . . . --Support forum," , May 2, 2013, pp. 1-9. cited by examiner .
Se Gi Hong et al., "Accelerating Service Discovery in Ad-hoc Zero Configuring Networking," IEEE, 2007, pp. 961-965. cited by examiner .
Sumi Helal et al., "Konark--A Service Discovery and Delivery Protocol for Ad-Hoc Networks," IEEE, 2003, pp. 2107-2113. cited by examiner .
PCT Application No. PCT/US2014/039701--International Search Report and Written Opinion dated Sep. 24, 2014. cited by applicant .
Taiwanese Patent Application No. 103118683--Office Action dated Jul. 27, 2016. cited by applicant .
Wi-Fi Simple Configuration Protocol and Usability Best Practices for the Wi-Fi Protected Setup.TM. Program; Version 2.0.1; Wi-Fi Alliance; Apr. 2011; 30 pgs. cited by applicant .
European Patent Application No. 14811686.6--Search Report dated Dec. 20, 2016. cited by applicant .
Taiwanese Patent Application No. 103118683--Office Action dated Aug. 21, 2015. cited by applicant .
Taiwanese Patent Application. No. 106113229--Office Action and Search Report dated Aug. 30, 2018. cited by applicant .
European Patent Application No. 14811686.6--Examination Report dated Jan. 11, 2018. cited by applicant .
Chinese Patent Application No. 201480032829.8--First Office Action issued dated Feb. 26, 2018. cited by applicant.
This application claims the benefit of U.S. Provisional Application No. 61/833,382, filed Jun. 10, 2013 and entitled "CONFIGURING WIRELESS ACCESSORY DEVICES," and which is incorporated by reference herein in its entirety for all purposes.
1. A method for configuring a second wireless device by a first wireless device, the method comprising: by the first wireless device: receiving first information, including a beacon message, from the second wireless device via a first wireless network, wherein the beacon message includes a first identifier of the second wireless device and a configuration state of the second wireless device; determining that the second wireless device is in a configurable state based on the beacon message; receiving from the second wireless device a first configuration counter value via the first wireless network; communicating configuration information to the second wireless device via the first wireless network, the configuration information including credentials for connecting to a second wireless network; connecting, subsequent to communicating the configuration information, to the second wireless network using the credentials; transmitting a service discovery message; receiving, in response to the service discovery message, second information from the second wireless device via the second wireless network, wherein the second information comprises a second configuration counter value; and verifying whether configuration of the second wireless device is configured successfully based on the second information by at least comparing the first configuration counter value to the second configuration counter value, wherein configuration counter values of the second wireless device change when the configuration of the second wireless device changes.
2. The method as recited in claim 1, further comprising: by the first wireless device: displaying, to a user of the first wireless device, a configuration status of the second wireless device based on the first information; and obtaining a user input indicating whether to configure the second wireless device.
3. A wireless device comprising: a wireless interface; a data storage device; and a processor, coupled to the wireless interface and the data storage device and configured to execute instructions stored in the data storage device that cause the wireless device to: receive from an accessory device a beacon message including a first identifier of the accessory device and a configuration state of the accessory device via a first wireless network; determine that the accessory device is in a configurable state based on first information included in the beacon message; receive from the accessory device a first configuration counter value via the first wireless network; communicate configuration information to the accessory device, the configuration information including credentials for connection to a second wireless network; join, subsequent to the communication of the configuration information to the accessory device, the second wireless network using the credentials; transmit a service discovery message; receive, in response to the service discovery message, second information from the accessory device via the second wireless network, wherein the second information comprises a second configuration counter value; and verify whether configuration of the accessory wireless device is configured successfully based on the second information by at least comparing the first configuration counter value to the second configuration counter value, wherein configuration counter values of the accessory device change when the configuration of the accessory device changes.
4. The wireless device as recited in claim 3, wherein the first identifier comprises a medium access control (MAC) address of the accessory device.
5. The wireless device as recited in claim 3, wherein the instructions when executed by the processor further cause the wireless device to: display, to a user of the wireless device, a configuration status of the accessory device based on the configuration state received from the accessory device; and obtain a user input indicating whether to configure the accessory device.
6. A controller device comprising: a wireless interface; a memory; and one or more processors, wherein the memory includes instructions that, when executed by a processor of the one or more processors, cause the controller device to perform operations comprising: receiving, via the wireless interface, (i) a beacon message from an accessory device, wherein the beacon message comprises a medium access control (MAC) address identifying the accessory device, and (ii) a first configuration counter value, determining that the accessory device is in a configurable state; sending, via the wireless interface, a credential to the accessory device in a configuration message, wherein the credential includes an access point password for a wireless local area network access point (AP), connecting with the AP using the credential, subsequent to sending the credential to the accessory device; transmitting a service discovery message, and verifying, based on information received in response to the service discovery message, whether the accessory device has been configured successfully by at least comparing the first configuration counter value to a second configuration counter value included in the information, wherein configuration counter values of the accessory device change when the configuration of the accessory device changes.
7. The controller device of claim 6, wherein the operations further comprise: prior to the receiving the beacon message: receiving, via a user interface, a user password input including the access point password; and associating with the AP using the access point password.
8. The controller device of claim 7, wherein the operations further comprise: prior to the sending the credential and after receiving the beacon message: displaying, to a user of the controller device, a name of the accessory device or a service set identifier (SSID) of the accessory device, wherein the beacon message includes the name and the SSID; and receiving a user direction input directing the controller device to configure the accessory device.
9. The controller device of claim 8, wherein the operations further comprise: prior to the sending the credential and after the receiving the user direction input: dissociating from the AP.
10. The controller device of claim 9, wherein the operations further comprise: prior to the sending the credential and after the dissociating from the AP: receiving a resource record from the accessory device, wherein the resource record includes a second MAC address; determining that the second MAC address matches the MAC address identifying the accessory device; and establishing a transmission control protocol (TCP) session with the accessory device.
11. The controller device of claim 10, wherein the operations further comprise: prior to the sending the credential and after establishing the TCP session: establishing an encryption scheme using asymmetric key exchange, wherein the sending the credential comprises sending the credential using the encryption scheme during the TCP session.
12. The controller device of claim 11, wherein the operations further comprise: prior to the sending the credential and after the establishing the encryption scheme: generating the configuration message, wherein the configuration message includes, in addition to the access point password, one or more of: i) an administrative password used to change settings of the accessory device, ii) a firmware revision of the accessory device, iii) a hardware revision of the accessory device, iv) a language identifier, v) a manufacturer identifier associated with the accessory device, vi) a model identifier of the accessory device, vii) a name value that the accessory device is to use in advertising itself, viii) a password used to access media streaming, and/or ix) a serial number of the accessory device.
13. The method of claim 1, wherein the second information further includes a medium access control (MAC) address, a hostname, and a port.
14. The method of claim 1, wherein the service discovery message is a multicast domain name system (mDNS) query message or a simple service discovery protocol (SSDP) message.
15. The method of claim 1, wherein the second information includes a resource record.
16. The method of claim 15, further comprising: by the first wireless device, when the resource record indicates that the second wireless device has been configured: providing a configuration success indication on a display of the first wireless device.
17. The method of claim 15, wherein the verifying further comprises: determining that a medium access control (MAC) address read from the resource record matches the first identifier.
18. The method of claim 15, wherein the verifying further comprises: resolving an internet protocol (IP) address of the first wireless device using a hostname read from the resource record.
The described embodiments generally relate to wireless networking technology, and more particularly, to methods and apparatus to configure wireless accessory devices.
Many wireless devices require a configuration in order to access a wireless network. For example, when a user wishes to use a wireless device (such as a wireless speaker) on a Wi-Fi network for the first time, the user may be required to provide a password in order for the device to connect to the Wi-Fi network. A number of different approaches have been developed to address how wireless devices are configured; despite the considerable efforts spent in designing and implementing these approaches, further improvements in this area (and related areas) are desired.
This document describes, inter alia, techniques for configuring a wireless device.
As an example of the features described herein, a first wireless device may be used to configure a second wireless device as follows: the first wireless device may detect that the second wireless device is available and is configurable; the first wireless device may connect to the second wireless device and transmit configuration information to the second wireless device, where the configuration information includes credentials that may be used to access a wireless network (e.g., a password to access a Wi-Fi network, where the password may have been provided to the first wireless device via input from a user); the first wireless device and the second wireless device may both connect to the wireless network, using the credentials; once both devices are connected to the wireless network, the first wireless device may verify that the second wireless device has been correctly configured.
FIG. 1 shows an example network architecture where features described herein may be implemented in accordance with some embodiments.
FIG. 2 shows an example method for configuring a wireless device in accordance with some embodiments.
FIG. 3A and FIG. 3B show a more specific implementation of the method of FIG. 2 in accordance with some embodiments.
FIG. 4 shows an example hardware configuration for a wireless device that may be used to implement features described herein in accordance with some embodiments.
Representative examples of dynamically selecting antenna tuner settings in a mobile wireless communication device based on a combination of downlink operating conditions, uplink operating conditions, or both is provided herein. These examples are provided to add context to, and to aid in the understanding of, the subject matter of this disclosure. It should be apparent that the present disclosure may be practiced with or without some of the specific details described herein. Further, various modifications and/or alterations can be made to the subject matter described herein, and illustrated in the corresponding figures, to achieve similar advantages and results, without departing from the spirit and scope of the disclosure.
Throughout this document, terms such as "may," "may include," "in an instance," "in some instances," "in some implementations," "can," and related/similar terms will be used; these terms should be understood to indicate that, while details of an element are present in at least one embodiment, other embodiments may differ in the details of one or more elements. In other words, when it is described in this document that an element "may" be present or that an action "may" be performed (or that an element is present "in an instance" or that an action is performed "in an instance," and so on), it should be understood that the element is present or that the action is performed in at least one embodiment, but not necessarily in all embodiments.
Throughout this document, reference will be made to some features that are specific to Wi-Fi (i.e., IEEE 802.11 wireless technology); this is done for ease of description, and it should be understood that the features described herein may be used, mutatis mutandis, in the context of any wireless technology.
FIG. 1 shows an example network architecture 110 wherein features described herein may be implemented. The network architecture 110 includes a controller device 100, an accessory device 102, and an access point 104.
The controller device 100 may be, for example, a desktop or laptop computer, a smartphone, a tablet computer, or any other type of wireless device.
The accessory device 102 may be, for example, a device such as: a speaker; a docking station; a printer; a mouse; a keyboard; a headset (i.e., headphone combined with a microphone); a track pad; a joystick; a headphone; a scanner; a media player; a display device; a thermostat controller; a garage door opener; an automobile or other vehicle; a refrigerator or other type of home appliance; and/or any other type of wireless device. The accessory device 102 may also be referred to as a peripheral device. The accessory device 102 may be configured to operate in a number of different ways, and the configuration of the accessory device 102 may be determined by settings for parameters. For example, the accessory device 102 may have a configurable name that can be set (that may be used, among other circumstances, when the accessory device 102 broadcasts that it is available to connect to), have an administrative password that may be set to control access to configuration parameters, and/or other parameters that the accessory device 102 uses when operating. The accessory device 102 may store information regarding services that it implements, including a configuration service whereby the accessory device 102 device may establish a wireless connection to another device (such as the controller device 100) in order for the accessory device 102 to be configured.
The controller device 100 may include components including but not limited to a processor (which may run/execute an operating system and applications for the controller device 100, and/or perform other functionality), a memory device and/or data storage device (which may be coupled to the processor and which may store the operating system, applications, and related data), a wireless interface (for communicating wirelessly with the accessory device 102 and/or the access point 104, using Wi-Fi and/or other wireless technologies), and/or one or more antennas. The controller device 100 may also include and/or be connected to a display device (e.g., a Liquid Crystal Display (LCD) or Light-Emitting Diode (LED) display, or other type of display device).
The accessory device 102 may include components such as those described above as included and/or connected to the controller device 100. Alternatively or additionally, in some instances, the accessory device 102 may include an authentication coprocessor, and/or other components. Further, in some instances (e.g., when the accessory device 102 is a device such as a speaker, thermostat, or other type of device), the accessory device 102 may not include a user interface, or include a limited user interface.
The access point 104 is a wireless device that, among other functionality, may act as a central connection point for IEEE 802.11 infrastructure mode operation, providing a Wi-Fi network to which other wireless devices (such as the controller device 100 and/or the accessory device 102) may connect. The access point 104 may also include components such as those described above as included and/or connected to the controller device 100.
The controller device 100, the accessory device 102, and the access point 104 may communicate in a number of different ways. As one example, the controller device 100 and the accessory device 102 may both associate with the access point 104, and then data may be communicated between the controller device 100 and the accessory device 102 via the access point 104. Alternatively or additionally, the controller device 100 and the accessory device 102 may communicate directly with each other; this may be performed using technology such as but not limited to IEEE 802.11 ad hoc mode technology, Wi-Fi Direct Technology, Apple Wireless Direct Link (AWDL) technology, and/or any other appropriate technology, and/or the accessory device 102 may be configurable to act as an access point (i.e., act as a central connection point for IEEE 802.11 infrastructure mode operation), and the controller device 100 may act as a client station (STA) and connect to the accessory device 102.
In some instances, the access point 104 may implement a security/authentication framework, such as Wi-Fi Protected Access II (WPA2), WPA, and/or other security/authentication frameworks. In such an instance, in order to successfully connect to the wireless network provided by the access point 104, wireless devices that want to connect to the wireless network must provide security/authentication credentials, such as a password.
The controller device 100 may implement one or more service discovery protocols. One such protocol that may be implemented by the controller device 100 is Bonjour, which is based on technologies such as Domain Name System (DNS), Multicast Domain Name System (mDNS), and Domain Name System-Service Discovery (DNS-SD). In order to discover services using Bonjour, the controller device 100 may exchange DNS-SD/mDNS messages (on multicast address 224.0.0.251:5353 for IPv4 or on multicast address [FF02::FB]:5353 for IPv6) with other devices.
The accessory device 102 may, similarly, also implement Bonjour and/or other service discovery protocols. As mentioned above, the accessory device 102 may implement a configuration service; in some instances, the accessory device 102 may use a service discovery protocol (such as Bonjour) to advertise information regarding its configuration service.
The accessory device 102 may store information about its configuration service in a number of different ways. In an instance where the accessory device 102 implements Bonjour (or a similar protocol), the accessory device 102 may store information such as the following: (a) the accessory device 102 may store a DNS Service (SRV) resource record, which may be named according to a <Instance Name>.<Service Type>.<Domain> format (e.g., "AccessoryOne._mfi-config._tcp.local," and/or which may include information such as the hostname for the accessory device 102 and a port at which the configuration service offered by the accessory device 102 is implemented; and (b) the accessory device 102 may store a DNS Pointer (PTR) resource record, which may be named according to a <Service Type>.<Domain> format (e.g., "_mfi.config._tcp," and which may point to the DNS SRV resource record mentioned above (i.e., the RDATA field in the PTR resource record may include the value "AccessoryOne._mfi-config._tcp.local"); and (c) the accessory device 102 may store a DNS Text (TXT) resource record, which may have the same name as the DNS SRV resource record mentioned above, and which may include information such as but not limited to: a "deviceid" field, which may include a globally unique identifier for the accessory device 102, and which may (in some instances) be the primary Media Access Control (MAC) address for the accessory device 102; a "features" field that indicates one or more of whether there is an application associated with the accessory device 102, whether the accessory device 102 supports an accessory configuration protocol over Wi-Fi, and whether the accessory device 102 supports type-length-value (TLV) based configuration; a "flags" field that indicates one or more of whether a problem with the accessory device 102 has been detected and whether the accessory device 102 has been configured; a "protovers" field that indicates the version of the configuration service that the accessory device 102 supports (formatted in a <major>.<minor> (e.g. "1.0") format); and a "seed" field that indicates a configuration seed number (which can be characterized as a "configuration counter," and which is updated by the accessory device 102 each time the configuration in the accessory device 102 is changed).
The accessory device 102 may also implement a Hypertext Transfer Protocol (HTTP) server. In such an instance, when the HTTP server is running on the accessory device 102, the controller device 100 and the accessory device 102 may communicate using HTTP messages (e.g., HTTP POST message, HTTP GET messages, and so on), with the controller device 100 acting as the HTTP client.
Although the controller device 100 is referred to herein as a "controller" and though the accessory device 102 is referred to as an "accessory," these terms are used only for ease of description and should not be understood to be limiting; the features described herein as performed by the controller device 100 and/or the accessory device 102 may be performed by any type of wireless device.
FIG. 2 shows an example method that may be performed to configure some attributes and/or aspects of the operation of the accessory device 102.
As the method of FIG. 2 begins, the controller device 100 may be connected to (or may have connected to in the past) a wireless network provided by the access point 104. The controller device 100 may store information regarding the wireless network, such as credentials (e.g., a password) for accessing the wireless network, information that identifies the wireless network (such as a Service Set Identifier (SSID) for the wireless network), and/or other information.
At block 200, the controller device 100 may receive information from the accessory device 102 and determine that the accessory device 102 is available to be configured. As one example of how this may be performed, the accessory device 102 may act as an access point and may transmit beacon messages (or other messages) that include information that, when processed by the controller device 100, indicate to the controller device 100 that the accessory device 102 is available for configuration. The beacon messages (or other messages) may include information such as a device identifier (e.g., a MAC address, or other type of unique identifier) for the accessory device 102.
At block 202, the controller device 100 may display information in a graphical user interface, indicating that the accessory device 102 is available for configuration. The controller device 100 may receive user input from a user of the controller device 100, indicating that the accessory device 102 should be configured. The controller device 100 may also receive user input that indicates configuration parameters for the accessory device 102, such as a name for the accessory device 102, an administrative password for the accessory device 102, and so on.
At block 204, the controller device 100 may establish a connection to the accessory device 102. In an instance where the accessory device 102 acts as an access point, this may include the controller device 100 joining the wireless network provided by the accessory device 102. Once connected to the accessory device 102, the controller device 100 may receive information from the accessory device 102, such as a configuration counter (a "configuration seed" number) and a device identifier. The controller device 100 may verify that the device identifier (which may be, for example, a MAC address) is the same as the device identifier received at block 200. If the controller device 100 determines that the device identifier is the same, the controller device 100 may then initiate an authentication procedure with the accessory device 102, to establish an encrypted link to the accessory device 102.
At block 206, the controller device 100 may transmit configuration information to the accessory device 102 via the encrypted link. The configuration information may include information regarding the wireless network provided by the access point 104 (such as credentials (e.g., a password) and an identifier for the network), and/or other information received via user input at block 202.
At block 208, the accessory device 102 may update its configuration using the configuration information received at block 206. Additionally, the controller device 100 and the accessory device 102 may both move to the wireless network provided by the access point 104, using the above-mentioned credentials that were transmitted to the accessory device 102 at block 206. This may also include the accessory device 102 updating its configuration counter/configuration seed number (by incrementing it and/or otherwise changing its value), and/or the accessory device 102 updating stored configuration status information to reflect that the accessory device 102 has been configured.
At block 210, both the accessory device 102 and the controller device 100 may be connected to the wireless network provided by the access point 104, and the accessory device 102 may transmit information to the controller device 100 via the wireless network provided by the access point 104. The information may include the incremented/changed configuration counter/configuration seed number, the MAC address for the accessory device 102, and configuration status information for the accessory device 102. The controller device 100 may verify the received information, which may include determining whether the value for the configuration counter/configuration seed number has been incremented/changed (versus its value as received at block 204), determining whether the device identifier is the same as received previously (at block 204 and block 200), and determining that the configuration status information indicates that the accessory device 102 has been configured. If the controller device 100 verifies that the configuration counter has been incremented/changed, that the device identifier is the same as had been received previously, and that the configuration status information indicates that the accessory device 102 has been configured, then the controller device 100 may determine that configuration of the accessory device 102 has been successful. Then, the accessory device 102 may communicate data on the wireless network provided by the access point 104, to/from the controller device 100 and/or other devices that may be connected to the wireless network.
FIG. 3A/FIG. 3B show a method that may be viewed as a more specific version of the above-described method of FIG. 2. In the following description, it will be described that the controller device 100 and the accessory device 102 implement Bonjour; however, this is done for ease of description, and it should be understood that, in different implementations, any other appropriate service discovery protocol(s) may be used.
As shown in FIG. 3A, at block 300, the controller device 100 may connect to the access point 104. This may include, for the example, the controller device 100 and the access point 104 performing a Wi-Fi association procedure, and/or may include an authentication procedure to authenticate the controller device 100, using e.g., WPA2 authentication. Block 300 may include the controller device 100 receiving a password via user input from a user of the controller device 100, and may include the controller device 100 transmitting the password to the access point 104 as part of the authentication procedure. The controller device 100 may store information regarding the access point 104, including but not limited to the SSID for the access point 104, the password used to connect to the access point, and/or other information.
At block 302, the accessory device 102 may be configured to act as an access point (or a "soft access point"), and/or to otherwise implement IEEE 802.11 infrastructure mode access point functionality (or some subset thereof). This may include the accessory device 102 providing a Wi-Fi network, and periodically transmitting beacon messages to advertise its Wi-Fi network. A beacon message transmitted by the accessory device 102 may include one or more Information Element (IEs) that indicate information such as the following: a name (or "friendly name") for the accessory device 102; a name of the manufacturer of the accessory device 102 (e.g., "Apple Inc."); a name of the model of the accessory device 102 (e.g., "Speaker System 9000"); an Organizationally Unique Identifier (OUI) for accessory device 102; a device identifier (or "Device ID"), which may be the MAC address of the accessory device 102; whether the accessory device 102 supports AirPlay (and/or similar technologies); whether the accessory device 102 is configured or "not configured"; whether the accessory device 102 supports one or more configuration protocols (such as Made For iPhone/iPod/iPad (MFi) Configuration v1 and/or Association Control Protocol (ACP) Configuration v1); and/or other information regarding the accessory device 102. The above-mentioned information may be included in one or more vendor-specific IEs in the beacon messages and/or in other IEs in the beacon messages broadcast by the accessory device 102.
The controller device 100 may receive one or more beacon messages transmitted by the accessory device 102, and/or otherwise discover the accessory device 102. The controller device 100 may store the information indicated in the beacon message(s), including the device identifier (which may be a MAC address) for the accessory device 102, and the other information mentioned above. Based on the information included in the beacon message(s) (in particular, the information indicating whether the accessory device 102 is configured/"not configured" and/or the information indicating whether the accessory device 102 implements one or more configuration protocols, such as MFi Configuration v1), the controller device 100 may determine that the accessory device 102 is in a state where it is configurable and/or that the controller device 100 should attempt to configure the accessory device 102.
At block 304, in response to the determination that the accessory device 102 is in a state where it is configurable and/or that the controller device 100 should attempt to configure the accessory device 102, the controller device 100 may display information regarding the accessory device 102 on a graphical user interface, e.g., on a display of the controller device 100. The information may indicate, e.g., the name of the accessory device 102, whether the accessory device 102 is currently configurable and/or has been discovered, the SSID for the accessory device 102, and/or other information about the accessory device 102. The controller device 100 may receive user input that is responsive to the displayed information and that indicates that action should be taken to configure the accessory device 102.
At block 306, in response to the user input that indicates that action should be taken to configure the accessory device 102, the controller device 100 may disconnect from the access point 104. This may include the controller device 100 performing a disassociation procedure with the access point 104, and/or otherwise disconnecting from the access point. As mentioned previously, the controller device 100 may store information regarding the access point, such as the password that was used to connect to the access point 104 and the SSID being used by the access point; here, even though the controller device 100 is disconnecting from the access point 104, the controller device 100 may continue to store the above-mentioned information regarding the access point 104.
At block 308, the controller device 100 and the accessory device 102 may establish a wireless connection (i.e. the controller device 100 may perform a Wi-Fi association process to associate to the accessory device 102), to establish physical layer and data link layer connectivity between the controller device 100 and the accessory device 102.
Following establishment of the wireless connection, the controller device 100 and the accessory device 102 may perform a Bonjour service discovery procedure, in order for the controller device 100 to connect to the configuration service implemented by the accessory device 102. This may include the controller device 100 and the accessory device 102 exchanging one or more DNS-SD/mDNS messages. Alternatively or additionally, this may be performed as follows: (a) the controller device 100 may transmit a DNS-SD/mDNS query message (with a query type of PTR) requesting information regarding the configuration service implemented by the accessory device 102; in an example where the service is an MFi configuration service, the Query Domain Name (QNAME) field in the Question Entry field in the DNS-SD/mDNS query message may include text such as "_mfi-config._tcp" or "_airplay._tcp"; (b) in response to the query message, the accessory device 102 may transmit a DNS-SD/mDNS query response message with information that points to a SRV resources record that describe services implemented by the accessory device 102 that match the service queried for in the initial query message; in an example where the accessory device 102 has the name "AccessoryA" and supports MFi configuration, the query response message may be of type PTR and may include an RDATA field that includes text such as "AccessoryA._mfi-config._tcp.local," thereby pointing to the SRV resource record named "AccessoryA._mfi-config._tcp.local" stored by the accessory device 102; (c) in response to the query response message, the accessory device 102 may transmit one or more additional DNS-SD/mDNS query messages to obtain the SRV resource record mentioned above and/or the DNS TXT resource record that associated with the SRV resource record; (d) in response to the one or more query messages from (c), the accessory device 102 may transmit DNS-SD/mDNS response messages that include the queried-for SRV and TXT resource records; the SRV resource record may include information such as the hostname of the accessory device 102 and the port at which the configuration service implemented by the accessory device 102 can be reached; and the TXT resource record may include information such as the device ID for the accessory device 102 (e.g., the MAC address for the accessory device 102), the configuration seed number, and/or any of the other types of information mentioned above in the description of FIG. 1 as stored by the accessory device 102 in the DNS TXT resource record.
The controller device 100 may check to verify that the device identifier (MAC address) received in the TXT resource record is the same as the device identifier (MAC address) received in the beacon in block 302. Additionally, the controller device 100 may store the information received in the DNS SRV and TXT resource records, including but not limited to the device ID (MAC address), hostname, port, and configuration seed number.
Upon completing the Bonjour service discovery procedure, the controller device 100 may use DNS to resolve the Internet Protocol (IP) address for the accessory device 102, using the hostname received in the SRV resource record. Following this, the controller device 100 may then establish a Transmission Control Protocol (TCP) connection to the accessory device 102, using the resolved IP address and the port as specified in the received SRV resource record. Establishing the TCP connection may include the controller device 100 and the accessory device 102 performing a TCP handshake procedure (i.e., communicating Synchronize (SYN)/Synchronize-Acknowledge (SYN-ACK)/Acknowledge (ACK) messages, and so on).
At block 310, the controller device 100 and the accessory device 102 may perform an authentication and/or encryption establishment procedure (using the TCP connection established at block 308), to establish secure/encrypted communications between them. The authentication/encryption establishment procedure may involve an asymmetric key exchange, and/or be based on other mechanisms. Alternatively or additionally, the authentication/encryption establishment procedure may be performed according to the MFi Secure Authentication Protocol (MFI-SAP), and/or any other appropriate protocol. In an instance where the accessory device 102 includes an authentication co-processor, the authentication co-processor may be used during the procedure. Subsequent communications between the controller device 100 and the accessory device 102 (i.e., communications performed, in block 312 and beyond, in the remaining portions of FIG. 3A/FIG. 3B) may be performed using the encryption scheme established at block 310.
At block 314, the controller device 100 may transmit the generated configuration request message to the accessory device 102. Upon receiving the configuration request message, the accessory device 102 may validate the configuration request message, and may store the information described above as included in the configuration request message. Then, the accessory device 102 may generate a configuration response message, and transmit the configuration response message to the controller device 100. The configuration response message may include information such as whether there is an application associated with the accessory device 102, a uniform resource locator (URL) or other identifier of a web resource/location to obtain the associated application, and/or other information. As mentioned above, the communication that takes place here (i.e., the communication of the configuration request/response) may take place using the encryption mechanism established at block 312.
Then, the controller device 100 and accessory device 102 may close their TCP connection. This may include the controller device 100 transmitting a TCP message to the accessory device 102, where the finish (FIN) flag of the message is set; upon receiving this TCP message, the accessory device 102 determines that the controller device 100 has closed the connection. Similarly, this may include the accessory device 102 transmitting a TCP message to the controller device 100, where the FIN flag is set; upon receiving this message, the controller device 100 determines that the accessory device 102 has closed the connection.
Following closing of the TCP connection, the controller device 100 and accessory device 102 may close their wireless connection. This may include the controller device 100 performing a disassociation procedure from the accessory device 102, and/or otherwise disconnecting from the Wi-Fi network provided by the accessory device 102.
At block 316, in response to the closing of the TCP connection and/or wireless connection, the accessory device 102 may update its configuration and/or other information that it is storing. This may include, for example, de-registering its Bonjour service, incrementing (and/or otherwise changing) the configuration seed value stored in its TXT resource record, and/or updating the "flags" field stored in its TXT resource record to indicate that the accessory device 102 has been configured. Alternatively or additionally, this may include the accessory device 102 updating other information that was received in the configuration request message--for example, if the configuration request message including a new name and/or administrative password, the accessory device 102 may update its configuration data accordingly.
Next, at block 318, the accessory device 102 searches for and connects to the access point 104. To search for the access point 104, the accessory device 102 may perform active scanning (i.e., transmitting Probe Request messages on different Wi-Fi channels, each of the Probe Requests with the SSID of the access point 104 as received in the configuration request message received from the controller device 100 at block 314, and receiving a responsive Probe Response message from the access point 104), and/or may perform passive scanning (i.e., may listen for beacons on different Wi-Fi channels); in either case, the accessory device 102 may compare the SSIDs in the received Probe Response messages and/or beacons against the SSID received in the configuration request message from block 314, to determine whether the access point 104 has been found/discovered. Once the accessory device 102 has found/discovered the access point 104, the accessory device 102 and the access point 104 may perform a Wi-Fi association procedure (which may be initiated by the accessory device 102 using information received in the above-mentioned Probe Response and/or beacon messages). Additionally, the accessory device 102 and the access point 104 may perform an authentication procedure to authenticate the accessory device 102, e.g., using WPA2 authentication. For the authentication procedure, the accessory device 102 may use the password (or a version thereof) received in the configuration request message from block 314 (i.e., the accessory device 102 may transmit the password to the access point 104 in one or more messages as part of the authentication procedure).
After the peripheral connects to the access point 104, it updates its DNS resource records (e.g., updates the hostname in the SRV resource record, if necessary) to reflect any new state/status information that results from being connected to the Wi-Fi network provided by the access point 104. In the updated DNS records, the configuration seed value in the TXT resource record may be incremented (or otherwise changed) and the "flags" field in the TXT resource record may be adjusted to indicate that the accessory device 102 has been configured.
At block 320, the controller device 100 may connect to the access point 104. This may include, for the example, the controller device 100 and the access point 104 performing a Wi-Fi association procedure, and may include the accessory device 102 authenticating to the access point 104 using the password stored at the accessory device 102 (which is the same password, as mentioned above, as used by the accessory device 102 at block 318).
At block 322, the controller device 100 and the accessory device 102 may perform a Bonjour service discovery procedure via the Wi-Fi network provided by the access point 104. This procedure may proceed in a similar/analogous fashion as that described above with respect to block 308; in other words, similar/analogous messages may be exchanged (as described above with respect to block 308), with updated values, as appropriate. As part of this procedure, the controller device 100 may receive the TXT resource record (in an DNS-SD/mDNS message) from the accessory device 102, with the updated configuration seed and "flags" fields.
The controller device 100 may then verify the information received from the accessory device 102 during the Bonjour service discovery procedure. This may include one or more of the following: (a) the controller device 100 may compare the stored configuration seed number received during the first Bonjour discovery procedure (at block 308) against the updated configuration seed number; if the updated value is not different from the configuration seed number from the first Bonjour discovery procedure (i.e., if the accessory device 102 has not incremented/changed the seed number), the controller device 100 may determine that the configuration procedure is unsuccessful, and/or may terminate the method of FIG. 3A/FIG. 3B; (b) the controller device 100 may analyze the "flags" field in the TXT resource record; if the updated "flags" field indicates that the accessory device 102 has not been configured, the controller device 100 may terminate the method of FIG. 3A/FIG. 3B; and (c) the controller device 100 may analyze the device ID (MAC address) received in the TXT resource record; if the device ID (MAC address) received in the TXT resource record at block 322 does not match the stored device ID (MAC address) from earlier, then the controller device 100 may terminate the method of FIG. 3A/FIG. 3B.
Also at block 322, the controller device 100 may receive information about services (such as audio streaming services, and so on) that the accessory device 102 implements, in other SRV and/or TXT resource records that it receives from the accessory device 102. The information may include, e.g., ports to connect to for the services and/or other configuration information related to initiating the services and/or communicating according to the services.
Then, when the controller device 100 successfully verifies the information received at block 300, the controller device 100 sends a configuration complete message to the accessory device 102.
At block 324, the controller device 100 may display information in the user interface of the controller device 100, indicating that the accessory device 102 has successfully been configured. In an instance where the controller device 100 has received information (in, for example, block 314) indicating that there is an application that is associated with the accessory device, the controller device 100 may display information that, e.g., prompts the user of the controller device 100 to download the associated application.
At block 326, the accessory device 102 may perform services. This may be done, for example, using service-related information received by the controller device 100 at block 322. For example: the accessory device 102 may be a speaker and may implement an audio streaming service (such as AirPlay, a service based on Remote Audio Output Protocol (RAOP), and/or any other audio streaming service); in this example, the controller device 100 may have received information regarding the service (hostname for the accessory device 102, port to connect to for the service, and so on) during the Bonjour discovery procedure at block 322; further to this example, at block 326, the controller device 100 may connect to accessory device 102 using the received information, and then may stream audio data to the accessory device 102; the accessory device 102 may receive the streamed audio data and generate corresponding audible sound waves.
Additionally, once the accessory device 102 has been successfully configured as shown in FIG. 3A/FIG. 3B, other wireless devices (not shown in FIG. 3A/FIG. 3B or FIG. 1) that are connected to the Wi-Fi network provided by the access point 104 may discover the accessory device 102, and the accessory device 102 may provide services to those other wireless devices.
The above-mentioned configuration request, configuration response, and configuration complete messages (from blocks 312, 314, 316, and 322) may be communicated between the controller device 100 and the accessory device 102 in a number of different ways. As one example, the accessory device 102 may run an HTTP server program and the controller device 100 may run an HTTP client program, and these messages may be transmitted within HTTP messages (e.g., the configuration request and configuration complete messages may be and/or be included in HTTP POST messages, and the configuration response may be and/or be included in an HTTP response message, and so on). Alternatively or additionally, one or any combination of these messages may be formatted using a Type/Length/Value (TLV) format.
As a variation on the features described above, instead of the accessory device 102 acting as a wireless access point as described above at block 302, the controller device 100 and the accessory device 102 may communicate at block 302 using a technology such as Wi-Fi Direct, AWDL, or some other peer-to-peer or similar wireless technology. In such an instance, instead of the controller device 100 receiving a beacon that include the information mentioned above with respect to block 302, the controller device 100 may receive similar/analogous information in other messages (e.g., Generic Advertisement Service (GAS) messages) received from the accessory device 102; in such an instance, the controller device 100 may determine that the accessory device 102 is in a state where it is configurable and/or that the controller device 100 should attempt to configure the accessory device 102 in response to the information received in these other messages.
Although FIG. 3A/FIG. 3B show distinct blocks, this is done for ease of description, to convey the different types of actions that the controller device 100, accessory device 102, and access point 104 may perform with respect to each other; the blocks of the method of FIG. 3A/FIG. 3B may, in various implementations, be performed in any order (including concurrently), and/or in any particular combination, as appropriate. Further, each or any of the actions described above as taking place as part of a particular block may be temporally interleaved with each or any of the actions described above as being included as part of a different block. As just one example of this, although it was described above that the accessory device 102 may update its configuration seed and "flags" values upon closure of the TCP and/or wireless connections in block 314, that is only one point at which the accessory device 102 may update those values; in a variation on this, the accessory device 102 may update these values instead after successfully connecting to the access point 104 at block 318.
FIG. 4 shows an example hardware configuration 400 that may be used to implement the controller device 100, the accessory device 102, and/or the access point 104.
As shown in FIG. 4, the hardware configuration 400 may include a wireless interface 402, memory device 404, storage memory 406, and processor 408, which are connected via system bus 410. The hardware configuration 400 may also include an antenna 412, coupled to the wireless interface 402.
The processor 408 may be a component such as an integrated circuit that may include logic circuitry configured to perform data processing and related actions. The processor 408 may be or include, for example, a single- or multi-core processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller or microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGA) circuits, an application processor (AP), or a system-on-a-chip (SOC). Alternatively or additionally, the processor 408 may be configured to use an instruction set architecture such as x86, ARM, and/or any other instruction set architecture.
The memory device 404 may be or include a device such as a RAM (such as a D-RAM or S-RAM), or other type of memory device. The data storage device 406 may be or include a hard disk, a flash memory, a magneto-optical medium, an optical medium, or other type of data storage device.
The wireless interface 402 may be or include one or more integrated circuits (or portion of thereof) or other type of circuit (or portion of thereof), or other type of component for implementing wireless communications and related functionality. The wireless interface 402 may include: a memory module; a processor and/or specific-purpose DSP circuitry for implementing functionality such as but not limited to baseband signal processing, physical layer processing, data link layer processing, and/or other functionality; one or more digital to analog converters (DACs) for converting digital data to analog signals; one or more analog to digital converters (ADCs) for converting analog signals to digital data; and radio frequency (RF) circuitry (e.g., one or more amplifiers, mixers, filters, phase lock loops (PLLs), and/or oscillators); and/or other components. The wireless interface 402 may communicate using Wi-Fi technology, and/or any other wireless technology.
As mentioned above, the wireless interface 402 may be coupled to the antenna 412 in the hardware configuration 400. It should be understood that, whenever it is described in this document that the wireless data is transmitted using the hardware configuration 400, the transmitting may include the wireless interface 402 providing one or more signals to the antenna 412, which may then be transmitted by the antenna 412 as radio frequency (RF) or other electromagnetic (EM) signals; similarly, whenever it is described in this document that the wireless data is received using the hardware configuration 400, the receiving may include the antenna 412 receiving RF (or other EM) signals, and providing the signals to the wireless interface 402 for processing.
Although not shown in FIG. 4, the hardware configuration 400 may be connected to a display device (such as a liquid crystal display (LCD) monitor, light emitting diode (LED) monitor, or organic light emitting diode (OLED) monitor) and/or include a display device (such a touchscreen based on LCD or LED/OLED technology). In such an instance the hardware configuration 400 may include additional components (such as but not limited to a Graphics Processing Unit (GPU)) that may be connected to the system bus 410 and which may play a role in the display of data via the connected/included display device(s).
Alternatively or additionally, the hardware configuration 400 may be connected to and/or include an input device, such as a keyboard, mouse, touchpad, touchscreen, or motion sensor device; when it is described herein that user input is received by the hardware configuration 400, it may be performed via a connected/included input device. Alternatively or additionally, the hardware configuration 400 may also include and/or be connected to any number of other components not shown in FIG. 4, including but not limited to one or more additional wireless interfaces, interfaces for wired (e.g., Ethernet) communications, and/or components for other functionality.
In an instance where the hardware configuration 400 is used to implement the controller device 100, the memory device 404 and/or the data storage device 406 may store instructions which, when executed by the processor 408, cause the processor 408 to perform (in conjunction, as appropriate, with the wireless interface 402, memory device 404, data storage device 406, a display device, and/or an input device) any feature or any combination of features described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the controller device 100. Alternatively or additionally, each or any of the different types of data described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as generated and/or processed by the controller device 100 may be processed/generated by the processor 408 and may be stored in the memory device 404 and/or data storage device 406. Alternatively or additionally, the wireless communications (and related actions) described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the controller device 100 may be performed using the wireless interface 402 (in conjunction with, as appropriate, the processor 408, memory device 404, data storage device 406, and/or antenna 412).
In an instance where the hardware configuration 400 is used to implement the accessory device 102, the hardware configuration 400 may also include and/or be connected to other components related to the functionality of the accessory device 102. For example, in an instance where accessory device 102 is a wireless speaker, the hardware configuration 400 may also be connected to components such as a speaker enclosure, a crossover network, and one or more drivers (e.g., woofers, tweeters, and/or mid-range drivers). Alternatively or additionally, the hardware configuration 400 may include an authentication co-processor. In an instance where the hardware configuration 400 is used to implement the accessory device 102, the memory device 404 and/or the data storage device 406 may store instructions which, when executed by the processor 408, cause the processor 408 to perform (in conjunction, as appropriate, with the wireless interface 402, memory device 404, data storage device 406, a display device, an authentication co-processor, and/or other components related to the functionality of the accessory device 102) any feature or any combination of features described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the accessory device 102. Alternatively or additionally, each or any of the different types of data described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as generated and/or processed by the accessory device 102 may be processed/generated by the processor 408 and may be stored in the memory device 404 and/or data storage device 406. Alternatively or additionally, the wireless communications (and related actions) described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the accessory device 102 may be performed using the wireless interface 402 (in conjunction with, as appropriate, the processor 408, memory device 404, data storage device 406, and/or antenna 412).
In an instance where the hardware configuration 400 is used to implement the access point 104, the memory device 404 and/or the data storage device 406 may store instructions which, when executed by the processor 408, cause the processor 408 to perform (in conjunction, as appropriate, with the wireless interface 402, memory device 404, data storage device 406, a display device, and/or an input device) any feature or any combination of features described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the access point 104. Alternatively or additionally, each or any of the different types of data described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as generated and/or processed by the access point 104 may be processed/generated by the processor 408 and may be stored in the memory device 404 and/or data storage device 406. Alternatively or additionally, the wireless communications (and related actions) described in this document (including but not limited to with reference to FIG. 1 through FIG. 3B) as performed by the access point 104 may be performed using the wireless interface 402 (in conjunction with, as appropriate, the processor 408, memory device 404, data storage device 406, and/or antenna 412).
Although the wireless interface 402, memory device 404, and so on are shown as singular components, in various implementations, the hardware configuration 400 may include any number of instances of the different components 402, 404, 406, 408. Further, it should be understood that the hardware configuration 400 shown in FIG. 4 is only one example, and that the controller device 100, accessory device 102, and/or access point 104 may be implemented using any appropriate hardware configuration capable of performing the actions described herein as performed by the controller device 100, accessory device 102, and/or access point 104, respectively.
Although examples are provided in this document that relate to Wi-Fi wireless technology, it should be understood that the features described herein may also be used, mutatis mutandis, with any other wireless technology (or combination of wireless technologies), including but not limited to one or more of: Bluetooth (including Bluetooth Classic, Bluetooth Low Energy, and/or other Bluetooth technologies); WirelessHDTV (WiDi); Wireless Home Digital Interface; Wireless HDMI; IEEE 802.11ad (WiGig); GSM/EDGE; UMTS (FDD or TDD); CDMA2000; LTE; LTE-A; and/or other wireless technologies.
Although examples are provided herein with reference to technologies such as Bonjour, DNS, DNS-SD, mDNS, and DNS-LLQ, the features described herein are also applicable, mutatis mutandis, to any technology that may be used for service discovery and/or similar functionality. For example, the features described herein may used with technologies such as Universal Plug and Play (UPnP)/Simple Service Discovery Protocol (SSDP), Service Location Protocol (SLP), Jini/River, Lightweight Directory Access Protocol (LDAP), and/or other technologies. Alternatively or additionally, although specific example message formats are described herein (i.e., particular DNS-SD/mDNS messages that include particular resource records, and so on), these message formats should be understood as being illustrative, and any other messages that include identical, similar, or analogous data (whether formatted according to DNS/DNS-SD/mDNS technology and/or other technologies such as but not limited to SSDP, SLP, or LDAP) may, mutatis mutandis, also be used.
Although features and elements are described herein in particular combinations, each feature or element can be used alone or in any combination with or without the other features and elements. For example, each feature or element as described above with reference to FIG. 1 through FIG. 4 may be used alone without the other features and elements or in various combinations with or without other features and elements. Sub-elements of the methods and features described above with reference to FIG. 1 through FIG. 4 may be performed in any arbitrary order (including concurrently), in any combination or sub-combination.
The following terms are used in this document: Wi-Fi: As used herein, the term "Wi-Fi" refers to wireless technologies such as but not limited to Institute of Institute of Electrical and Electronics Engineers (IEEE) 802.11 technologies, such as but not limited to IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11-2012, and/or other IEEE 802.11x technologies. Non-transitory computer-readable medium: A device for data storage, such as a hard disk, an optical medium (such as a CD-ROM, a DVD, or a BluRay disc), a magneto-optical medium, a memory device (such as a Dynamic Random Access Memory (D-RAM), Static RAM (S-RAM), or other type of Random Access Memory (RAM)), a register, a cache memory, a Read Only Memory (ROM), a flash memory (based on, e.g., Electrically Erasable Programmable Read Only Memory (EEPROM) flash memory technology or "Negated AND or NOT AND" (NAND) flash memory technology), or other type of non-transitory device for electronic data storage. The memory device 404 and the data storage device 406 of FIG. 4 are two examples of non-transitory computer-readable media. A non-transitory computer-readable medium is distinguishable from a transitory computer-readable medium, such as a transitory signal.
The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Further, some aspects of the described embodiments may be implemented by software, hardware, or by a combination of hardware and software. The described embodiments can also be embodied as computer program code stored on a non-transitory computer-readable medium. The computer readable-medium may be associated with any data storage device that can store data, which can thereafter be read by a computer or a computer system. Examples of the computer-readable medium include read-only memory, random-access memory, CD-ROMs, Solid-State Disks (SSD or Flash), HDDs, DVDs, magnetic tape, and optical data storage devices. The computer-readable medium can also be distributed over network-coupled computer systems so that the computer program code may be executed in a distributed fashion.

matches:
Application No. 103118683
Application No. 14811686
Application No. 103118683
Application No. 14811686
Application No. 201480032829
Application No. 61


A COUPLE OF NEW SLAY-THE-MONSTER-BY-REMOTE-CONTROL silver-bullet fantasies are on the market, assuring the gullible that they can be permanently immunized against the "income" tax by some clever "election", "revocation" or "rescission" procedure-- for a fee, of course.
The purveyors of these "plans" exploit the unfortunately pervasive erroneous notion that fundamental liability for the "income" tax is citizenship or residency based. They advocate some process by which something about one's citizenship or residency can be entered into the official record, after which one will be presumed "non-taxable".
However, the applicability of the taxing power has nothing to do with citizenship or residency. The tax is an excise (a tax on the exercise/benefits of a privilege granted by the taxer), and it applies to anyone, natural or artificial, and of any citizenship or residency whatever, who engages in that exercise.
The nature, function and applicability of the tax is clear per the relevant statutes, which extend the tax to those resident in the "United States" and those who are citizens thereof, AND to those who are neither, as well. The statutes reflected at 26 USC § 1 imposes the tax upon the "taxable income" of every individual. Period. "Taxable income" is "gross income" less allowable deductions, etc.. Period. "Gross income" includes "income" of all kinds and from any source whatsoever. Period.
No distinctions are drawn in these statutes as a whole as to residency or citizenship, other than the specification that the "income" of non-resident aliens is taxed under special rules (which arise due to considerations of tax treaties generally providing that recipients of "income" in, and from within, foreign jurisdictions will be taxed by, and per the tax structure of, the foreign jurisdiction); and the rules concerning the availability of the personal exemption at 26 USC § 6013 (g) or (h).
26 CFR § 1.1-1 Income tax on individuals.
(1) Section 1 of the Code imposes an income tax on the income of every individual who is a citizen or resident of the United States and, to the extent provided by section 871(b) [below] or 877(b) [relating to special treatment of those deemed expatriates for the purpose of tax-avoidance, and thus not presented here -PH], on the income of a nonresident alien individual.
A nonresident alien individual engaged in trade or business within the United States during the taxable year shall be taxable as provided in section 1 [regular tax rates and rules] or 55 [alternative minimum tax rates and rules] on his taxable income which is effectively connected with the conduct of a trade or business within the United States.
26 CFR § 1.871-1 Classification and manner of taxing alien individuals.
(a) Classes of aliens. For purposes of the income tax, alien individuals are divided generally into two classes, namely, resident aliens and nonresident aliens. Resident alien individuals are, in general, taxable the same as citizens of the United States; that is, a resident alien is taxable on income derived from all sources, including sources without the United States. See §1.1–1(b). Nonresident alien individuals are taxable only on certain income from sources within the United States and on the income described in section 864(c)(4) from sources without the United States which is effectively connected for the taxable year with the conduct of a trade or business in the United States. However, nonresident alien individuals may elect, under section 6013 (g) or (h), to be treated as U.S. residents for purposes of determining their income tax liability under Chapters 1, 5, and 24 of the code. Accordingly, any reference in §§1.1–1 through 1.1388–1 and §§1.1491–1 through 1.1494–1 of this part to non-resident alien individuals does not include those with respect to whom an election under section 6013 (g) or (h) is in effect, unless otherwise specifically provided. Similarly, any reference to resident aliens or U.S. residents includes those with respect to whom an election is in effect, unless otherwise specifically provided.
26 CFR § 1.871-2 Determining residence of alien individuals.
(a) General. The term nonresident alien individual means an individual whose residence is not within the United States, and who is not a citizen of the United States. The term includes a nonresident alien fiduciary. For such purpose the term fiduciary shall have the meaning assigned to it by section 7701(a)(6) and the regulations in part 301 of this chapter (Regulations on Procedure and Administration). For presumption as to an alien's nonresidence, see paragraph (b) of §1.871–4.
In sum, the tax applies to "U.S. citizens", those who are NOT "U.S. Citizens" but are resident within the "United States", and those who are not "U.S. citizens" and ARE NOT resident within the "United States". The common denominator is the receipt of "income"-- a profit from the exercise of federal privilege. Citizenship and/or residency have nothing to do with it-- not even on the creative notion that "citizenship" is some kind of privilege.
the income tax cannot apply or be construed so as to amount to a capitation, whether on "US citizens" or anyone else, and therefore cannot be a tax on "all that a "citizen" does" or "all gains of a "citizen"..." or anything like that, even if "citizenship" were creatively imagined to be a privilege.
SO, BECAUSE THE TAX IS WHAT IT IS-- conduct based, and not "status"-based, no assertion entered into some record today can immunize one from the tax. Creating an affidavit declaring oneself to be of one kind of citizenship, or not of another, or resident one place or not another, or not "citizen" or "resident" at all, for that matter, does nothing.
Run, don't walk, away from anyone promoting "revocation" or "untaxing" or "14th Amendment citizen" or "non-resident alien" or "only corporate status" arguments (or any variation thereon). All are nonsense; all will do nothing good, and on the contrary, all will simply obscure the reality of the tax, and prevent you from dealing with that reality properly and productively.
And for goodness sake, just look at this, every single instance of which was accomplished without any attention paid by filer or tax agency to citizenship or residency.


It’s an unfortunate fact of life that there are a lot of prescription drugs out there that people can also use to get high. We’re not just talking about cocaine, barbiturates, and methamphetamines, or even the long lists of drugs found at 21 U.S.C.A. §812. The truth of the matter is that just about any painkilling drug, and most drugs sold indicated for the treatment of psychosocial conditions such as depression, can be abused.
We’re product liability lawyers, not prosecutors. Our interest in this topic comes from those situations – and there’ve been more of these than we care to think about – where discovery leads us to suspect that the injuries a plaintiff is suing over were in fact caused by recreational, rather than therapeutic use of the product.
While stoner plaintiffs often like to think that they’re being slick, in reality they’re usually not as smart as their doctors – nor are they much of a match for determined discovery. Docs are pretty smart. Unless they’re actually in cahoots with the plaintiff (unfortunately we’ve run into a few of those, too) they tend to note such things as “drug seeking behavior” or excessive consumption in their records. Most docs don’t hesitate to cut off prescriptions to suspected abusers. Also, with the increasing computerization of prescription records, it’s easier than ever to compile evidence of overuse and other abuse even where a plaintiff tries to cover his or her tracks by getting prescriptions from multiple sources and filling them at multiple pharmacies.
So, you’ve got a plaintiff that you’re convinced is responsible for his or her own injuries due to excessive (or other illegal) use of the drug. This plaintiff has violated the prescriber’s usage limitations – not to mention anything and everything that your client says in its package insert. What can you do to blow this doper out of court?
Well, in addition to the usual causation and adequacy as a matter of law defenses, there’s a special legal doctrine that’s been crafted to deal with precisely this situation. It’s called the “wrongful conduct rule” or the “in pari delicto” doctrine, and it invokes public policy to preclude anyone who injures him or herself in the course of criminal activity from recovering in tort for those injuries. It’s tailor made for the addict plaintiff – and more than that, its invocation can cause a lot of lawyers on the other side to reconsider their involvement in any given case.
So what is this doctrine? It’s a variant of the longstanding general rule that intervening criminal conduct cuts off liability, but it’s more than that, because it has a moral aspect to it as well. It’s discussed in Restatement (Second) of Torts §889, comment b (1979), which states “if the injured person has violated a statute designed to prevent a certain type of risk, he is barred from recovery for harm caused by violation of the statute if, but only if, the harm resulted from a risk of the type against which the statute was intended to give protection.” The Restatement also uses as an illustration an accident where the plaintiff was driving illegally at night without lights. Id. at Illustration 5.
[T]he wrongful-conduct rule [is] rooted in the public policy that courts should not end their aid to a plaintiff who founded his cause of action on his own illegal conduct. If courts chose to regularly give their aid under such circumstances, several unacceptable consequences would result. First, by making relief potentially available for wrongdoers, courts in effect would condone and encourage illegal conduct. Second, some wrongdoers would be able to receive a profit or compensation as a result of their illegal acts. Third, and related to the two previously mentioned results, the public would view the legal system as a mockery of justice.
Id. at 213. See also Ortolano v. BDI Marketing, 930 So.2d 192, 196 (La. App. 2006) (affirming summary judgment against plaintiff who abused OTC athsma by taking excessive quantities “to lose weight and gain energy”); Pappas v. Clark, 494 N.W.2d 245, 246-48 (Iowa App.1992) (drug addict could not recover on claim that the defendant pharmacy should have warned other pharmacies that the plaintiff was attempting to procure prescription drugs by using fraudulent prescriptions).
No court will lend its aid to a man who founds his cause of action upon an immoral or an illegal act. . . . If a plaintiff cannot open his case without showing that he has broken the law, a court will not aid him. It has been said that the objection may often sound very ill in the mouth of the defendant, but it is not for his sake the objection is allowed; it is founded on general principles of policy which he shall have the advantage of, contrary to the real justice between the parties. The principle of public policy is that no court will lend its aid to a party who grounds his action upon an immoral or illegal act.
Kentucky. . .public policy. . .den[ies] recovery for illegal acts, [so] the seven plaintiffs that procured and used OxyContin illegally may not recover in this action. . . . Because they must inevitably rely on their illegal actions to establish their claims, their claims should be denied in the first instance.
Foister v. Purdue Pharma, L.P., 295 F.Supp.2d 693, 705 (E.D. Ky. 2003).
[P]laintiff is barred from seeking damages stemming from his wife’s death, under New York’s public policy against allowing individuals to profit from their own wrongdoing. Plaintiff states that. . .“there were two victims that night of the murder, (my wife and myself). That may be his sincere belief, but a criminal jury found otherwise. Under New York public policy, therefore, this action must be dismissed.
Id. at 422-23. Compare Patten v. Raddatz, 895 P.2d 633, 637-38 (Mont. 1995) (plaintiff’s knowing receipt and ingestion of illegally prescribed tranquilizers barred any claim for injury arising from her illegal drug use).
As these cases indicate, while the wrongful conduct rule applies to abuse of prescription drugs, this is only a specialized indication of a much broader rule. Thus defense counsel who are not litigating in one of the states where there is directly on point drug precedent should not hesitate to put the drug abusing plaintiff where he or she belongs – out of court. As a public service, to help purge the courts of cases brought by criminal plaintiffs, here’s a list of general wrongful conduct rule precedent.
Alabama: Ex parte W.D.J., 785 So.2d 390, 393 (Ala. 2000); Oden v. Pepsi Cola Bottling Co., 621 So.2d 953, 954 (Ala. 1993).
Alaska: Lord v. Fogcutter Bar, 813 P.2d 660, 663-664 (Alaska 1991); Adkinson v. Rossi Arms Co., 659 P.2d 1236, 1240 (Alaska 1983).
California: Kashani v. Tsann Kuen China Enterprise Co., 13 Cal. Rptr.3d 174, 194-95 (Cal. App. 2004); Goldstein v. Enoch, 57 Cal. Rptr. 19, 23 (Cal. App. 1967); Goodwin v. Anheuser-Busch Cos., 2005 WL 280330, at *4 (Cal. Super. Jan. 28, 2005).
Colorado: Sender v. Kidder Peabody & Co., 952 P.2d 779, 782 (Colo. App. 1997).
Florida: Leo’s Gulf Liquors v. Lakhani, 802 So.2d 337, 342-43 (Fla. App. 2001); Cabrerizo v. Fortune International Realty, 760 So.2d 228, 230 (Fla. App. 2000).
Illinois: Vine Street Clinic v. HealthLink, Inc., 856 N.E.2d 422, 436-37 (Ill. 2006).
Indiana: Rimert v. Mortell, 680 N.E.2d 867, 876 (Ind. App. 1997).
Kansas: Parker v. Mid-Century Insurance Co., 962 P.2d 1114, 1116 (Kan. App. 1998).
Massachusetts: Nisselson v. Lernout, 469 F.3d 143, 151-52 (1st Cir. 2006); Choquette v. Isacoff, 836 N.E.2d 329, 334 (Mass. App. 2005).
Minnesota: Christians v. Grant Thornton, LLP, 733 N.W.2d 803, 814-15 (Minn. App. 2007).
Missouri: Dobbs v. Dobbs Tire & Auto Centers, Inc., 969 S.W.2d 894, 897-98 (Mo. App. 1998); Clouse v. Myers, 753 S.W.2d 316, 319 (Mo. App. 1988).
New Jersey: Tryanowski v. Lodi Board of Education, 643 A.2d 1057, 1062 (N.J. Super. Law Div. 1994); Amato v. United States, 549 F. Supp. 863, 867 (D.N.J. 1982), aff’d without opinion, 729 F.2d 1445 (3rd Cir. 1984).
New York: Alami v. Volkswagen of America, Inc., 766 N.E.2d 574, 576-77 (N.Y. 2002); Barker v. Kallash, 468 N.E.2d 39, 42 (N.Y. 1984).
North Carolina: Carver v. Carver, 314 S.E.2d 739, 744-45 (N.C. 1984).
Oklahoma: Tillman v. Shofner, 90 P.3d 582, 584-85 (Okla. Civ. App. 2004).
Pennsylvania: Minnesota Fire & Casualty Co. v. Greenfield, 855 A.2d 854, 868-69 (Pa. 2004); Holt v. Navarro, ___ A.2d ___, 2007 WL 2326870, at *7 (Pa. Super. Aug. 16, 2007).
South Carolina: Myatt v. RHBT Financial Corp., 635 S.E.2d 545, 548 (S.C. App. 2006).
South Dakota: Quick v. Samp, 697 N.W.2d 741, 747 (S.D. 2005).
Tennessee: Nashville Ford Tractor, Inc. v. Great American Insurance Co., 194 S.W.3d 415, 428 (Tenn. App. 2005); Moss v. Mid-South Hospital, 1989 WL 134666, at *2 (Tenn. App. Nov. 7, 1989).
Texas: Sharpe v. Turley, 191 S.W.3d 362, 369 (Tex. App. 2006); Jones v. Hyman, 107 S.W.3d 830, 831-32 (Tex. App. 2003).
Virginia: Martin v. Ziherl, 607 S.E.2d 367, 371 (Va. 2005); Lee v. Nationwide Mutual Insurance Co., 497 S.E.2d 328, 329-30 (Va. 1998).
West Virginia: Gray v. Fraley, 1992 WL 564130, at *3 (S.D.W. Va. Oct. 26, 1992).
Wyoming: Feltner v. Casey Family Program, 902 P.2d 206, 208-09 (Wyo. 1995).


text:
I only process personal data of my users if this is necessary to provide functional websites and online services as well as my contents and services. The processing of personal data of my users takes place regularly only after consent of the user. An exception applies in those cases where prior consent cannot be obtained for effective reasons and processing of the data is permitted by law.
Insofar as I obtain the consent of the data subject for the processing of personal data, Art. 6(1)a GDPR serves as the legal basis.
In the processing of personal data required for the performance of a contract to which the data subject is a party, Art. 6(1)b GDPR serves as the legal basis. This also applies to processing operations that are necessary to carry out pre-contractual measures.
As far as a processing of personal data is necessary for the fulfilment of a legal obligation to which I am subject, Art. 6(1)c GDPR serves as legal basis.
If processing is necessary to maintain a legitimate interest on my part or that of a third party and if the interests, fundamental rights and freedoms of the data subject do not outweigh the former interest, Art. 6(1)f GDPR serves as the legal basis for processing.
The personal data of the person affected will be deleted or blocked as soon as the purpose of storage ceases to apply. Furthermore, data may be stored if this has been provided for by the European or national legislator in EU regulations, laws or other provisions to which the person responsible is subject. The data will also be blocked or deleted if a storage period prescribed by the aforementioned standards expires, unless there is a need for further storage of the data for the conclusion or fulfilment of a contract.
According to legal requirements in Germany, the storage takes place in particular for 10 years according to § 147(1) AO and for 6 years according to § 257(1) HGB.
In accordance with Art. 32 GDPR, I take appropriate technical and organisational measures to ensure a level of protection appropriate to the risk, taking into account the current state of technology, the costs of implementation and the nature, scope, circumstances and purposes of processing as well as the different probability of occurrence and severity of the risk to the rights and freedoms of natural persons.
You will find my technical and operational data protection measures in this PDF file.
If, in the course of my data processing, I disclose personal data to other persons and companies (contract data processors or third parties), transfer them to them or otherwise grant them access to the personal data, this will only take place on the basis of a legal permission pursuant to Art. 6(1)b GDPR, your consent pursuant to Art. 6(1)a GDPR, a legal obligation pursuant to Art. 6(1)c GDPR or on the basis of my legitimate interest pursuant to Art. 6(1)f GDPR.
If third parties are commissioned by me with the processing of personal data, this is done on the basis of Art. 28 GDPR within the framework of a contract on data processing.
Every time you visit my websites and every time you use my online services, my systems automatically collect data and information from the computer system of the calling user.
The legal basis for the temporary storage of data is Art. 6(1)f GDPR.
The temporary storage of the IP address by the system is necessary to enable delivery of the web pages and online services to the user's computer. For this the IP address of the user must remain stored for the duration of the session. These purposes are also my legitimate interest in data processing according to Art. 6(1)f GDPR.
The data will be deleted as soon as they are no longer necessary to achieve the purpose for which they were collected. In the case of the collection of data for the provision of websites and online services, this is the case when the respective session has ended.
The collection of data for the provision of websites and online services is absolutely necessary for the operation of the websites and online services. Consequently, there is no possibility of objection on the part of the user.
My systems do not create log files for every single access to web pages (so-called access logs), but there is an evaluation of the calls using Matomo, which you can contradict here.
For security reasons, to avert danger and to correct errors, certain actions triggered by the user are logged, including in particular failed login attempts at services and websites that allow a login.
All websites and online services provided by me log any internal errors that occur in log files. These entries do not contain an IP address, but may contain user names of the user whose action caused the error in order to find errors.
If the contact form classifies an input as spam, the IP address of the user is logged in order to be able to better ward off cases of repetition.
In case of failed login attempts at the Matomo administration interface, the IP address and the entered user name of the requesting user are logged in order to prevent misuse.
In case of failed login attempts at the Nextcloud interface, the IP address and the entered user name of the requesting user are logged in order to prevent misuse.
When logging on to the Skaffari administration interface, the IP address and the user name entered by the requesting user are logged in order to prevent misuse.
For security reasons, all administrative actions performed by administrators are logged. The user name of the executing administrator is logged, but no IP address.
With each login to the web mail interface, the entered user name and the IP address of the requesting user are logged in order to prevent misuse.
During every communication with the e-mail system at huessenbergnetz.de via the protocols SMTP, IMAP, POP3 and Sieve, the user name and IP address of the requesting user are logged.
The legal basis for the temporary storage of data and log files is my legitimate interest in the secure operation of my information technology systems in accordance with Art. 6(1)f GDPR.
The storage of login information, fraud attempts and security-critical actions in log files ensures the security of my information technology systems. An evaluation of the data for marketing purposes does not take place in this context. My legitimate interest in data processing in accordance with Art. 6(1)f GDPR also lies in these purposes.
Data in log files will be deleted after seven days at the latest.
Logging of security-critical actions in log files is absolutely necessary for a secure operation of my systems. Consequently, the user has no right of objection.
Further information on the data collected by Matomo can be found in the corresponding section, where you can also object to the collection for the future.
The legal basis for the processing of personal data using cookies is Art. 6(1)f GDPR.
Matomo's analysis cookies are used to improve the quality of my website and its content. Through the analysis cookies I learn how the websites are used and can thus constantly optimise my offer. Further information on analysis with Matomo can be found in the corresponding section.
The usage of cookies fo this purposes is my legitimate interest in accordance with Art. 6(1)f GDPR.
Alternatively, it may be possible to contact me via an e-mail address provided. In this case, the user's personal data transmitted by e-mail will be stored.
The legal basis for the processing of the data is Art. Art. 6(1)a GDPR, if the user has given his or her consent.
The legal basis for the processing of data transmitted in the course of sending an e-mail is Art. 6(1)f GDPR. If the e-mail contact is aimed at the conclusion of a contract, then additional legal basis for the processing is Art. 6(1)b GDPR.
The processing of the personal data from the input mask serves me alone for the treatment of the establishment of contact. In the event of contact by e-mail, this also constitutes the necessary legitimate interest in the processing of the data.
The other personal data processed during the sending process serve to prevent misuse of the contact form and to ensure the security of my information technology systems.
The user has the possibility to revoke his consent to the processing of personal data at any time. If the user contacts me by e-mail, he can object to the storage of his personal data at any time. In such a case, the conversation cannot be continued.
To revoke your consent and/or to object to the storage, please simply send a corresponding request via the contact form to me or send an e-mail to .
All personal data stored in the course of contacting me will be deleted in this case.
The software runs exclusively on my servers. The personal data of users is only stored there. A passing on to unauthorized third parties does not take place. Customers of my service only have access to the data of their own website(s).
The software is configured so that the IP addresses are not completely stored, but 2 bytes of the IP address are masked (e.g. 192.168.0.0). In this way it is no longer possible to assign the shortened IP address to the calling computer.
No data is merged across the boundaries of domains. In particular, no data from websites of different customers will be combined or passed on to other customers.
The legal basis for processing the personal data of the users of my websites is Art. 6(1)f GDPR.
The legal basis for the processing of commissioned data for my customers is a contract concluded with the respective customer in accordance with Art. 28 GDPR on commissioned data processing.
The processing of users' personal data enables me, or my customer, to analyse the surfing behaviour of our users. We are able to compile information about the use of the individual components of our websites and online services by evaluating the data obtained. This helps us to constantly improve our online offer and its user-friendliness. For these purposes, it is also in our legitimate interest to process the data in accordance with Art. 6(1)f GDPR. By anonymizing the IP address, users' interest in protecting their personal data is sufficiently taken into account.
In the case of commissioned data processing for customers, the purpose is to fulfil my business activities and to enable the respective customer to safely analyse his websites. For this purpose there is a contract between me and the respective customer who uses the service of statistik.huessenbergnetz.de in accordance with Art. 28 GDPR on commissioned data processing.
The data will be deleted as soon as they are no longer needed for our recording purposes. This is always the case after 367 days.
Since the collected data is stored pseudonymised, no personal reference can be made from it. It is therefore not possible to delete specific data of individual users.
We also offer our users the possibility of an opt-out from the analysis procedure on all websites analysed by statistik.huessenbergnetz.de, including this one. To do this, simply click on the corresponding box in the next section. In this way, another cookie is set which signals the Matomo installation at statistik.huessenbergnetz.de not to store the user's data in the future. If the user deletes the corresponding cookie from his own system in the meantime, he must set the opt-out cookie again. The opt-out applies to all websites and online services analyzed by statistik.huessenbergnetz.de.
The legal basis for the processing of personal data is my legitimate interest pursuant to Art. 6(1)f GDPR in an efficient and secure provision of my websites and online services.
The processing of personal data by Hetzner Online GmbH enables me to provide my own websites and online services. Only the purchase of infrastructure and server services makes my websites and online offers possible.
If Hetzner Online GmbH creates log files to protect its own infrastructure and information technology systems, these will be made anonymous after 7 days at the latest — which means that a personal reference can no longer be established.
The processing of data by Hetzner Online GmbH is absolutely necessary for the operation of the websites and online services. Consequently, there is no possibility of objection on the part of the user.
Legal basis for the processing of personal data are contractually offered services and preliminary work according to Art. 6(1)b GDPR.
The processing of personal data for third parties enables me to conduct my business and provide services to third parties.
As far as personal data are not stored anonymously, they will be deleted by me after 7 days at the latest.
The collection of data for third parties is mandatory for the provision of my services and for the maintenance of my business operations. Consequently, there is no possibility of objection on the part of the user.
If the processing of personal data concerning you has been restricted, these data may only be processed - apart from being stored - with your consent or for the purpose of asserting, exercising or defending rights or for the protection of the rights of another natural or legal person or on grounds of an important public interest of the European Union or a member state.
You revoke your consent, on which the processing was based pursuant to Art. 6(1)a GDPR or Art. 9(2)a GDPR, and there is no other legal basis for the processing.
You file an objection to the processing pursuant to Art. 21(1) GDPR and there are no overriding legitimate reasons for the processing, or you file an objection to the processing pursuant to Art. 21(2) GDPR.
If you have made use of your right of rectification, erasure or restriction of the processing towards the controller, the controller is obliged to inform all recipients to whom the personal data concerning you have been disclosed of this rectification or erasure of the data or restriction of the processing, unless this proves impossible or involves a disproportionate effort.
The person concerned has the right to be informed of these recipients.
The right to transferability does not apply to the processing of personal data necessary for the performance of a task in the public interest or in the exercise of official authority conferred on the controller.
You have the right to object at any time, for reasons arising from your particular situation, to the processing of your personal data in accordance with Art. 6(1)e or f GDPR.
The supervisory authority to which the complaint has been lodged will inform the complainant of the status and results of the complaint, including the possibility of a legal remedy under Art. 78 GDPR.

matches:
Art. 6
Art. 6
Art. 6
Art. 6
§ 147
§ 257
Art. 32
Art. 6
Art. 6
Art. 6
Art. 6
Art. 28
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 6
Art. 28
Art. 6
Art. 28
Art. 6
Art. 6
Art. 6
Art. 9
Art. 21
Art. 21
Art. 6
Art. 78